Rolling vs discrete release isn’t a factor here; both suffer from the same issue if the updating system isn’t designed and built to be atomic.
Why not?
If I wanted to look at something like Arch I would choose Artix as it advises not using Arch repos. There was an instance where AUR had been attacked. My daily driver is PCLOS Debian Plasma (“bookworm”) and my second option is Q4OS 5.8 Plasma, rolling release since I installed 5.5 and not had any issues.
To quote myself
My udev and Pipewire “mods”/additions survived rolling so far without issues, well
except the simultaneous audio output that technically still works but not so great with my new Monitor.
Can’t imagine to do these easily if things are locked behind the atomic layer. And at least with my current machine there is Nvidia/cuda that kept me away from KDE Linux.
It’s not bad at all. You can use a systemd extension to override files in /usr if needed (link to KDE Linux docs, but the general principle of using systemd extensions should work everywhere). And if your tweaks were to files in /etc, it’s even easier, just change them as normal.
2 Likes
Artix uses the same installer EOS does, afaik
@anonnetuser Let’s pump the brakes a bit here.
First, pointing out the objective fact that the AUR has a massive software selection isn’t “irresponsibly luring new users”—it’s simply answering a question about how the Arch ecosystem works.
Second, you seem to have completely glossed over the fact that the OP literally stated, “I’m quite comfortable with Ubuntu now.” They aren’t some helpless newcomer who needs to be shielded from the terminal; stop infantilizing them so you can roleplay as their savior.
Finally, it is incredibly ironic to call the Arch community “combative and elitist” while simultaneously jumping into a thread just to aggressively misrepresent other people’s words and act morally superior.
@aeleoglyphic As @ngraham already pointed out perfectly, use what works for you! If Kubuntu is doing the job, there is zero pressure to switch. If you ever do want to explore Arch though, you almost certainly have the requisite experience to do so, and the community is generally very welcoming to people willing to learn—despite what some anonymous commenters might claim.
2 Likes
@anonnetuser, this is a casual forum discussion, not a comprehensive technical manual. Arch has one of the most extensively documented Wikis in existence specifically so users don’t have to append a multi-paragraph safety disclaimer every time they simply mention the AUR. The OP is fully capable of doing their own basic research before switching their entire operating system. I’m not going in circles with you about this anymore. 
1 Like
If concerned with AUR (and general psa for arch users), I saw this about “traur” some weeks back and thought a great idea, but go figure wouldn’t compile from AUR (yay rust)… This thread spurred my memory, and nice enough they have a traur-bin package now that works without figuring out why rust won’t compile cleanly.
It did find I had 3 “sketchy” packages which I think are probably ok, but all random crap that accrued anyways from somewhere, so out they went, but certainly gives me some peace of mind about it now.
I mean, I feel like with traditional package based distros, as long as you don’t make any wild changes it’s usually fine. I’ve had Fedora KDE on my main workstation since Fedora 41, and it’s survived multiple upgrades since then no issues. In my case however, I’ve done my best to leave the made system as close to stock as possible. No random third party repos (I think I have one Copr repo enabled for some random thing I installed ages ago…) and I install most of my apps as Flatpak.
I’ve definitely had problems in the past with distro upgrades nuking themselves when my system was full of random undocumented nonsense.
So I definitely agree with your point about why atomic updates are simpler and more reliable. Immutable systems are designed so you don’t faff around with the base system and put it into a random un documented state, and make it super easy to roll back to a previous image. But like if you’re careful with a traditional distro it’s definitely still pretty reliable.
I mean I guess that goes for most things. The more you mess with it the more likely it is to break. If I decide to LS swap my Audi, its probably not going to be as reliable as if I left it alone (although it would be cool as heck). So yeah, Atomic is good because its harder to break, traditional is good for people who like to mess with things.
1 Like
Yeah I’m on an all AMD system so no NVIDIA shenanigans required.
I guess if AUR is unsafe or not depends on how you use it.
If you use it as it is intended to be used, it is arguably the safest 3rd party repository in existence. On the other hand, if you just blindly download software from it, treating like the repos, then, yeah, that would be unsafe.
AUR packages are built by you on your machine so you know exactly what is inside them and precisely where it comes from. AUR helpers provide assistance to make it very easy to see what part of a package has changed and identify areas of risk. You don’t need any deep technical knowledge to do this either. Just a small amount of care and a little bit of learning.
But this goes back to what Arch is and who it is for. Arch is best for someone who likes to learn and explore their system, or, as @ngraham stated above, someone who likes to tinker. Note, I didn’t say that you had to be an expert or someone with a high degree of technical proficiency. However, if you view your system as tool and simply want to use it without a lot of worry or knowledge, Arch is the wrong distro in my opinion. There are too many things you need to deal with.
It doesn’t even matter if you have separate disks or partitions. Even from within a single partition, btrfs subvolumes can be restored separately from your user data. There are even things like grub-btrfs that let you boot off of a snapshot if things go wrong.
2 Likes
I’ve always just copied my most important files to an external drive and hope for the best lol. Most of the data that accretes on my computer is junk. Easy wipe it every so often, and copy back the few actually important things.
Pretty much.
The thing I find intolerable is when inherent deficiencies in the system unconnected to messing with it cause problems, though.
A week ago my wife’s Fedora 42 system exploded because a disk controller defect with the hardware caused the Btrfs disk to detect this and go read only at the worst possible time: in the middle of an update. An update that would have otherwise worked fine. But, due to a lack of atomicity, hundreds of packages had already installed their new files on disk, while the remaining ones hadn’t. The system was then in a half-upgraded state that ultimately could not be repaired even by leaning on a professional contact: a technical expert who helps to build Fedora itself. I lost three days troubleshooting and debugging this before ultimately figuring out the problem, and my wife lost access to a working computer for the same amount of time.
An atomic update system would not have broken the update and destroyed the system. There would still have been a latent hardware issue to discover, but it could have been done without the pressure of the OS being destroyed, and then system could have booted into an older OS image for troubleshooting and usage in degraded mode until new hardware could be procured.
Yeah is def a big problem. That’s why I am running Fedora Kinoite on my laptop. Really don’t want it borking out on me in the field. One of these days when my Fedora install on my workstation craps out I’ll swap it over to an atomic distro as well. Probably Fedora Kinoite until KDE Linux has its stable branch ready.
This does sound very tempting, as for a long time - when any issues arise, we can think back to those old Nokia phones - you turn them on, they work…
‘Installed’ applications were simple downloadable files to be executed - not strictly ‘installed’ as such…
Then when the system updates, it’s a complete new system.
to drill down on the AUR question a bit more, since i’ve not used any of the arch variants out there and rely on the team at kubuntu for a clean relatively up to date repository for my linux applications.
my understanding was that the AUR was a repository of packages you could install using the package manager, so in other words, they were pre-compiled packages that the package manager knew what to do with in terms of resolving dependencies and placing the files on disk.
but now i’ve read here that its basically a pool of source code (much like github) where the user is expected to compile the package and then (what?) copy the files to their place on disk manual or let the package manager have it, hoping it complies with what is expected?
either way it does not sound like anything as simple or secure as the default repositories included with kubuntu.
Not really, strictly speaking it’s very open and less secure way folks can share pkgbuild scripts.
The emphasis is on the word ‘User’ - and understanding that many developers are ‘users’ just as many amateurs and also a few bad actors…
So if you grab plex-HTPC from the AUR, this is essentually what you get:
pkgbuild
# Maintainer: Michele Palazzi <sysdadmin@m1k.cloud>
pkgname=plex-htpc
pkgver=1.71.1.346
_pkghash=f62ce923
pkgrel=1
pkgdesc="Plex HTPC client for linux"
arch=('x86_64')
url='http://plex.tv'
license=('custom')
depends=(libgl
hicolor-icon-theme
alsa-lib
dbus
expat
ffmpeg
fontconfig
freetype2
gcc-libs
glib2
glibc
harfbuzz
lcms2
libdrm
libjpeg-turbo
libwebp
libx11
libxcb
libxcomposite
libxdamage
libxext
libxfixes
libxml2-legacy
libxkbcommon
libxkbfile
libxrandr
libxslt
libxtst
mesa
minizip
nspr
nss
opus
xcb-util-renderutil
pciutils
libxss
xcb-util-image
libxkbcommon-x11
libxinerama
xcb-util-keysyms
xcb-util-wm
zlib
snappy
libva
libpulse
libxrender
wayland
qt6-base
)
source=("https://artifacts.plex.tv/plex-htpc-stable/$pkgver-$_pkghash/linux/PlexHTPC-$pkgver-$_pkghash-linux-x86_64.tar.bz2"
"http://ftp.us.debian.org/debian/pool/main/libw/libwebp/libwebp6_0.6.1-2.1+deb11u2_amd64.deb"
"https://github.com/flathub/tv.plex.PlexHTPC/raw/master/tv.plex.PlexHTPC.desktop"
"https://github.com/flathub/tv.plex.PlexHTPC/raw/master/tv.plex.PlexHTPC.png"
)
sha256sums=('ea1baab13c406272ace83e9407c59f647b8367b6067ef3bf2983470b67a9eb9d'
'8abc2b1ca77a458bbbcdeb6af5d85316260977370fa2518d017222b3584d9653'
'b98d1ba9191e346a256f1c838051b2d547f638558d79898df8b1707c7cabe487'
'069cdf95608a46af4313bdffb281df37819e77c4e371c1e1667af889f0f325a2')
noextract=('Plex-$pkgver-$_pkghash-linux-x86_64.tar.bz2')
package() {
cd $srcdir
install -d "${pkgdir}/opt/${pkgname}"
tar --no-same-owner -xvf $srcdir/PlexHTPC-$pkgver-$_pkghash-linux-x86_64.tar.bz2 -C $pkgdir/opt/${pkgname}
tar -xvf $srcdir/data.tar.xz ./usr/lib/x86_64-linux-gnu/libwebp.so.6.0.2
install -Dm644 usr/lib/x86_64-linux-gnu/libwebp.so.6.0.2 ${pkgdir}/opt/${pkgname}/lib/libwebp.so.6
rm -rf $pkgdir/opt/${pkgname}/lib/dri
rm -rf $pkgdir/opt/${pkgname}/lib/libEGL.so*
rm -rf $pkgdir/opt/${pkgname}/lib/libdrm.so*
rm -rf $pkgdir/opt/${pkgname}/lib/libdrm_*.so*
rm -rf $pkgdir/opt/${pkgname}/lib/libpciaccess.so*
rm -rf $pkgdir/opt/${pkgname}/lib/libva.so*
rm -rf $pkgdir/opt/${pkgname}/lib/libva-*.so*
install -d ${pkgdir}/usr/bin
ln -s /opt/${pkgname}/Plex.sh ${pkgdir}/usr/bin/Plex
install -Dm644 "${srcdir}/tv.plex.PlexHTPC.desktop" -t "${pkgdir}/usr/share/applications"
install -Dm644 "${srcdir}/tv.plex.PlexHTPC.png" -t "${pkgdir}/usr/share/icons/hicolor/256x256/apps/"
}
So the emphasis is very much upon the user, and it is totally without guarantee.
However, the same can be said for anything you download outside your package manager…
Like fresh-editor-bin which is my new favourite text editor - so much nicer than micro/nano/etc
1 Like
All I know about it is trying to compile the AUR build of LibreWolf on a decade old intel celeron cpu and 16 gb of ram. You need like double the ram lol.
For AUR, most more popular software tend to have full source builds or -bin packages that are compiled binaries. Compiled by whom, and do you trust them? If there isn’t a mainstream repo package for it, what you gonna do? I prefer to build, but as mentioned, compiling something like librewolf might take hours.
As @ben2talk said above, it’s really just source plus the pkgbuild that makepkg uses to build it around arch, pull in dependencies, and any cleanup needed to make it work. Usually pretty basic stuff, I’ve had to make my own to package and install clean random source for myself on arch to install.
Some AUR packages grab ubuntu packages because that’s what is available (particularly when talking enterprise software from vendors like cisco, fortinet, etc), extract, and massage pushing binaries into arch to work cleanly.
I don’t see AUR being much different than freebsd ports, ubuntu 3rd party ppa’s, node npm, ruby gems, or python pip as it’s all somewhat unofficial glue to deliver some code best it can from somewhere, secure or not if you need/want something they have. It saves you having to figure out compiling and installing yourself from scratch, so as long as the AUR pkgbuilds aren’t malicious or pulling in something that is, that’s mostly as much as you can hope for.
I mentioned traur earlier to audit AUR packages, it was interesting to run and see what it found, here’s the worst snippet of mine here, as it seems to do reputation checks, validation how many hands and who’s are in the cookie jar, what their pkgbuild’s are doing if anything shady, etc, and after I removed the sketchy ones I wasn’t even sure where they came from. Better than nothing?
$ traur scan
Fetching package metadata for 230 installed packages...
Skipping 18 not on AUR: alpm_octopi_utils, appstream-qt5, calibre-installer, drm_info, js102, js115, js78, kcolorpicker-qt5, kimageannotator-qt5, kquickcharts5, llvm15, llvm15-libs, lmstudio-appimage, netstandard-targeting-pack-bin, python-argparse, rpcs3, sudachi-bin, wlroots0.16
Scanning 212 AUR packages...
Fetching maintainer data for 133 unique maintainers...
=== traur scan results ===
Scanned: 212 packages (0 errors)
TRUSTED: 169 OK: 40 SKETCHY: 3 SUSPICIOUS: 0 MALICIOUS: 0
=== 212 packages ===
traur: botan2 (trust: 46/100)
Trust: SKETCHY
Negative signals:
P-CHECKSUM-MISMATCH: checksum count mismatch: source has 2 entries but sha256sums has 3
B-SUBMITTER-CHANGED: Package maintainer (the-k) differs from original submitter (artafinde)
! B-ORPHAN-TAKEOVER: Adopted package with new git author (Ľubomír Kučera) — orphan takeover pattern
T-AUTHOR-CHANGE: Git history shows multiple different authors
! G-LD-LIBRARY-PATH: LD_LIBRARY_PATH manipulation (shared library injection)
traur: rapidyaml (trust: 58/100)
Trust: SKETCHY
Negative signals:
! P-PYTHON-INLINE: Python inline code execution
P-SKIP-ALL: All checksums are SKIP (no integrity verification)
M-VOTES-LOW: Package has very few votes (2)
B-SUBMITTER-CHANGED: Package maintainer (SecByShresth) differs from original submitter (abouvier)
T-AUTHOR-CHANGE: Git history shows multiple different authors
traur: cpupower-gui (trust: 60/100)
Trust: SKETCHY
Negative signals:
! P-INSTALL-PERSISTENCE: Persistence mechanism in install script
P-CHECKSUM-MISMATCH: checksum count mismatch: source has 3 entries but sha256sums has 1
M-OUT-OF-DATE: Package is flagged as out of date
B-MAINTAINER-SINGLE: Maintainer has only 1 package
T-AUTHOR-CHANGE: Git history shows multiple different authors
traur: youtube-viewer (trust: 65/100)
Trust: OK
Negative signals:
!! P-BASE64: Base64 decoding (possible payload hiding)
M-POP-ZERO: Popularity is 0 (no recent usage)
B-SUBMITTER-CHANGED: Package maintainer (trizen) differs from original submitter (arojas)
traur: lib32-libdbusmenu-gtk2 (trust: 66/100)
Trust: OK
Negative signals:
P-CHECKSUM-MISMATCH: checksum count mismatch: source has 1 entries but sha512sums has 2
B-SUBMITTER-CHANGED: Package maintainer (voxan24) differs from original submitter (City-busz)
! B-ORPHAN-TAKEOVER: Adopted package with new git author (Balló György) — orphan takeover pattern
T-AUTHOR-CHANGE: Git history shows multiple different authors
T-DIFF-MAJOR-REWRITE: 80% of PKGBUILD lines changed (unusual for version bump)
traur: nvidia-docker-compose (trust: 67/100)
Trust: OK
Negative signals:
P-WEAK-CHECKSUMS: Using weak checksums (md5/sha1) without stronger alternative
M-VOTES-LOW: Package has very few votes (1)
M-POP-ZERO: Popularity is 0 (no recent usage)
M-NO-LICENSE: No license specified
B-SUBMITTER-CHANGED: Package maintainer (ny-a) differs from original submitter (Teyras)
! B-ORPHAN-TAKEOVER: Adopted package with new git author (ny-a) — orphan takeover pattern
T-AUTHOR-CHANGE: Git history shows multiple different authors
traur: python-pyrsistent (trust: 68/100)
Trust: OK
Negative signals:
! P-PYTHON-INLINE: Python inline code execution
B-SUBMITTER-CHANGED: Package maintainer (taotieren) differs from original submitter (jelly)
T-AUTHOR-CHANGE: Git history shows multiple different authors
! T-DIFF-SOURCE-DOMAIN-CHANGED: Source URLs changed to new domain(s): github.com
traur: ungoogled-chromium-bin (trust: 68/100)
Trust: OK
Negative signals:
!! P-SUID-BIT: Setting SUID/SGID bit (privilege escalation)
Now that Valve is leveraging Arch extensively as their SteamOS underpinnings, they got annoyed enough with its package security to donate fairly extensively to fix that in terms of getting the Arch team a centralized build and signing infrastructure to fix some of the more wild-west of random gpg key trusts they use today, but not seen much lately on that.
1 Like
Basically this. On Distro A , you need to do A, B, and C to run things how you want.
On Distro B, you need to X, Y, and Z. Add in P, D, and Q for the immutables on top of all that 
The only thing is figuring out which things you prefer, is easier for your situation, etc.
1 Like