Tried for half the weekend to get elementary to work, it just refused to install for reasons unknown.
Gone with Mint for now.
I like the hardware (an old Intel MacBook Air) and didn’t want it to go to waste.
I’ll see how I get on with this desktop. Went feet first straight to bare metal because I couldn’t be bothered with dual boot. It was too much faff. Would value any insight from others who’ve found a lovely distro/DE combo with these tiny machines.
Making my first moves away from proprietary software. Thanks largely to being inspired by you delightful folk.
In my limited understanding (beyond the ‘Arch btw’ memes), Arch is an OS that’s quite fully featured, suited to veteran/power users, because it has regular updates/highly mutable. It has its own repo too by the looks of it?
Is that correct?
Not entirely sure what you mean with that.
The gist is that Arch pretty much comes with little to no defaults. So, you are literally put into the position to make all the important decisions. Which, as you might have imagined already, basically requires you to be pretty knowledgeable on Linux in the first place. Thus making it mostly unsuitable for new users. Though, I won’t dismiss a special breed of newb that somehow manages to rawdog it quite ‘successfully’.
We refer to its release cycle as rolling release. Which basically alludes to the absence of a point release.
The version of Linux Mint you were on is 21.2 and you’ll soon be on 22.3. After some time, you’ll be on 23.x etc. These are referred to as point releases. So, whenever a new point release update hits, you’ll receive a couple of months’ worth of updates. And between two consecutive point releases, you’ll receive little to no updates. So, basically, Linux Mint deliberately chooses to hold updates of. By doing so, it ensures you’ll only receive updates that have undergone thorough testing.
Arch, on the other hand, has a much leaner testing phase. Heck, as pointed out earlier, it doesn’t even wait for a certain moment to reach before it outputs an update. Instead, after the packages have had some testing, it pushes the updates out for its users to receive it. As such, you’ll receive constant updates. And you’re somewhat expected to at least perform daily updates. By doing so, it ensures you’ll always have access to the latest and greatest.
Note that Arch is not the only rolling release distro. But, out of the ‘Big 3’[1], it’s the only one that is rolling release by default.
Its release cycle does indirectly contribute to Arch being less newbie-friendly. Basically, any update comes with the risk of causing breakage. On Debian, this risk is partly mitigated by the infrequency of updates and by pushing out very well-tested updates to begin with. On Arch, you just have to deal with it every once in a while.
Note, however, that it’s most often your fault and not Arch’s. Secondly, after dealing with this a couple of times, you’d have acquired some excellent skills in troubleshooting.
Traditional distros are basically equally mutable. So, Arch doesn’t (necessarily) outdo e.g. Debian or Fedora in this regard.
It does. But that’s a thing with independent distros. Linux Mint is a derivative of Ubuntu. Which, itself is a derivative of Debian. Debian, however, is independent. Similarly, Arch isn’t derived from anything else; hence, it’s an independent distro.
The list of independent distros isn’t huge or anything, but I suppose there are at least a couple of dozens of 'm.
As for the own repository part, both pkgs.org and repology.org feature some resources on that.
The others being Debian and Fedora*. ↩︎
As an Arch user of a decade by now, I tell you all, you most certainly do not need to update every day, I repeat, you do not need to update every day. That is absolutely not necessary, and will cause much undue stress. I would not recommend that at all. I update maybe once a week. And I find that to be quite consuming as it is.
Thanks for the elaboration!
The reply was already becoming quite long, so I deliberately chose to cut some corners here and there. I was hoping that the “somewhat” qualifier would do the heavy-lifting 😜.
😁 no worries, yeah. If I see an Arch user recommend updating daily, I would definitely question their experience. 😅
Interesting.
So, as I kinda alluded to elsewhere, I don’t daily Arch nor have I ever done so in the past. I did have it as a dual boot earlier in my Linux journey. However, after breaking it for the second time, I just called it quits 😅.
Anyhow, with that out of the way, I am interested in your perspective w.r.t update frequency on Arch.
It has basically been my head canon that updating daily is (at least) reasonable on Arch. And while its excellent wiki doesn’t dictate any number, I’m inclined to believe that -by updating once a week- one is acting by the lower bound in terms of frequency; I’d argue the default settings of paccache suggest as such.
I think the frequency with which you update your computer is highly subjective. I have gone everywhere from weekly, to daily, to hourly, to yearly. All equally fine for the machine in question, and updates carried out without a hitch.
If it isn’t broken and does what you need, why update, you know what I mean? Especially if it isn’t connected to the internet in some cases. 😁
Regarding what you linked to paccache, which setting(s) were you referring to specifically? I don’t think I was able to understand that it is directly suggesting or indirectly insinuating any type of update frequency. But I probably am just too tired to process. 😅
I agree with that assessment whenever it’s not connected to the internet. But, if it is, I actually find it hard to justify for myself to not (at least) receive the security updates. Which, in the case of non-frozen packages, suggests applying regular updates.
But yeah, more than anything, I think this touches on threat models. Which are very subjective by themselves and thus probably not very interesting to discuss 😜.
My apologies, perhaps I should have been more elaborate. So,
paccache’smanpage mentions a systemd timer it refers to as paccache.timer. With it, package cache can be cleaned periodically. And, by default, it does so weekly.As to why this suggests weekly updates as a lower bound,
paccacheremoves old packages. Thus, from my understanding,paccachegoes hand in hand with updates; updates yield the old packages which will be deleted bypaccache. As such, for two consecutivepaccaches to do anything, an update has to have occurred in between. Thus, if paccache.timer defaults to weekly cleanups, then it has to be accompanied with at least a weekly update.Of course,
paccachewill handle higher update frequencies without any problem. Thus, updating only once a week becomes a lower bound for paccache.timer’s default functionality.To be clear, I only said “suggest” :P . I can’t do any stronger claims 😅.
This is a hugely informative reply thank you!
It has been my pleasure :) . Thanks for the kind words!
… not if you just postpone updating to the same schedule as Debian, lol. By spacing your updates out, you reduce the risk of catching breaking changes in just the same manner as Debian. Although Debian probably has more rigorous human testing as part of its release strategy, granted.
At any rate, I haven’t had Arch break on me due to an update in all of the years I’ve used it. Over a decade by now. And I update very regularly.
LOL, indeed.
About the breaking part, kudos to you for doing a great job at maintaining Arch. But I assume/think[1] most people don’t enjoy ‘babysitting’[2] their OS 😅.
Please feel free to push back on this. ↩︎
This term isn’t meant derogatory or anything. But it’s what comes up to me whenever I see how involved this is. By contrast, I actually do apply daily updates on my semi-rolling daily driver. But I never have to give it any thought. Heck, it even happens automatically. ↩︎
Yeah, that’s a very common misconception, that you constantly have to “maintain” Arch, as if something happens to it just by having your computer running.
I do very little “maintenance” other than issue these commands:
$ paru ... $ flatpak update ...Before I upgrade the system, I check archlinux.org in order to see if there are any breaking changes that need manual handling. (Has happened maybe 2 times with packages that I have actually had installed, in 10+ years.)
Then, when paru has invoked pacman and upgraded native packages (from the Arch repo) and starts to upgrade foreign packages (from the AUR), I check the diffs in the package files (paru displays them) to make sure nothing looks fishy. Obviously upgrading Flatpak packages needs no maintenance.
This all takes about 5 minutes each time I do it, including downloading of new package versions, which is very little time per week. Even less if you do it less frequently, which you definitely can.
So when you say I do a good job maintaining Arch, is not really me. 😅 The Arch developers have done a superb job for me. And the maintainers of the Arch wiki are also true heroes. I just use it. 👍
The page you linked to is slightly FUD and yet simultaneously true because theoretically anything can happen and that serves as a disclaimer that the developers shouldn’t be to blame, and nobody is owed support if something were to potentially break.
Ubuntu broke loads of times for me back in the day. Had to reinstall it several times. And all I did was issue the command for upgrading to a new Ubuntu point release. 😅
Thank you for sharing that!
Your approach to updating contains only a subset of what was found on the wiki, but I’m glad to hear that it has proven to be sufficient 🙂.
I’ve heard many horror stories of upgrading on Ubuntu 🤣🤣🤣. Thankfully, Arch has been good to ya 🙂.
I see people using the term “rawdogging” a lot and I don’t think they actually know what it means. 🫣
I used it in this sense. But yeah, I admit it’s not the traditional dictionary meaning. Unsure if it would be right to qualify it as a semantic change, though.
Fair enough 😆