And of course I’m installing Linux on it. Install went well, even the fingerprint sensor built in to the laptop works.
Mostly this will be a school and DND machine but always nice to have a functional laptop for whatever else I may need it for.
And of course I’m installing Linux on it. Install went well, even the fingerprint sensor built in to the laptop works.
Mostly this will be a school and DND machine but always nice to have a functional laptop for whatever else I may need it for.
There seems to be a misunderstanding in the definition of “stable” for distros. Arch is solid, it’ll rarely break, when it breaks it’ll be mostly due to the users own interest in fiddling with the system in the first place. But Arch follows the rolling-release model, with incremental updates which may require manual intervention — again, happens on very rare occasions — it differs from the stable release model, where distros like Debian have small changes, more guided towards security rather than having the newest software.
So by definition I wouldn’t say Arch is stable, even if it’s not the common usage, it’s best to describe that it requires system management and maintenance, but it’s not brittle, unlike Windows.
This is also a myth, on both counts. This is assuming you always install every single update to all packages as soon as it’s released, and have to do so just because there’s a new version. That’s not how Arch operates. You are in charge of initiating an upgrade. It’s a manual command that you run, right.
If you upgrade often, you’re more likely to run into buggy releases. Just upgrade less often and reduce your likelihood of installing buggy latest releases. Just like Debian and other such distros do. You’re in charge on Arch.
This is only one way of mitigating risk that you can do, but I do concede that Arch does not take every precaution that other distros do to ensure that broken packages are not released. They do however follow up with news posts if there’s an issue, with info about what to do. This is an awesome thing.
But still, I haven’t had an issue in over a decade, upgrading packages probably once a week or so.
There’s no “maintenance” other than what you create for yourself. This Arch = “maintenance” (whatever that entails in everyone’s mind) nonsense has got to be put to bed.
If you update once or twice a week, chances are there are literally hundreds of packages to upgrade every time. There’s no chance someone will look into every single one of these packages to verify what could potentially ‘break’ their system or not. They just upgrade the whole thing and THEN, if something breaks, they work around it.
As someone who uses CachyOS daily as my main distro, I wouldn’t install it on a device for someone that doesn’t want to do some maintenance from time to time. Maybe I wouldn’t go as far to say that it is UNSTABLE, but point release distros such as Mint or Debian are definitely more stable and require much less maintenance. Rolling release distros are, naturally, much riskier.
That’s the thing though, what breaks? I haven’t had anything break in 10+ years. Guess I’m lucky? Or other people are really unlucky/careless? Where is the discrepancy coming from, between this notion of Arch breaking for everyone all the time and it not happening for me? Or is it just simply a legend of a bygone era? I hear it was worse like maybe 15 years ago. Maybe Arch hasn’t shaken that image, still.
I mean, Steam Deck is based on Arch ffs. You can have it “stable” if you like. Why choose that distro if there’s so much “inherent risk” with it. It’s a solid distro if you know how to control yourself and your actions IMO.
SteamOS uses an immutable filesystem, and Valve curates the snapshots of the packages before pushing them to the end user. That pretty much removes the entire issue we’re talking about, and is completely different than running rolling release distros.
It’s the same thing as postponing updates though, isn’t that right? I mean, essentially, it is. Right? You pick when you update the system. Minus the curation aspect, of course. But they don’t push updates very often, do they.
It wasn’t the best example though, of course. 👍
this is total bullshit. you need to update for security reasons. and every time you update, you get the latest version with allpossible incompatibilities. even if you are updating only a few times per month, you don’t update to a “known working state”, you update to the latest package version with all problems that might come with it.
also long times between updates can cause various other problems.
The whole point of a bleeding-edge and rolling-release distro is that you get the lastest packages available. If you wait longer for the buggy updates to get fixed, then it doesn’t make it any different from Mint and other stable distros. It might even be worse because even if you wait, every update would still include a package that may be buggy because of the nature of rolling releases.
That’s you projecting. I didn’t choose Arch because of that. I chose Arch because I got to decide what to install on my system, from basically nothing. I get to choose how lean or thicc my system is. That was my motivation. And pacman just seemed like such a sensible package manager after reading its manual. 😙👌
Sometimes I don’t upgrade my system for more than a week, e.g. during vacation when I’m not by my computer much. Still, no issues. You can upgrade as much as you want. You decide, just like you can decide not to upgrade to the latest point release from Debian if you don’t want to.
Not projecting, that is quite literally one of the features of a rolling release distro. I have used Arch and Antergos (rip) myself. If your reason for choosing Arch is that you get to pick and choose what you only want to install, then there are other non-rolling release distros that offer that too, and Arch isn’t any different from them from that perspective.
And we’re also talking about stability which the original OP was talking about. If you want to set up your system with only the packages you need and only want to update it with the same cadence as a non-bleeding edge distro, then you’re better off with the latter because it’s the same thing with a lower risk of getting buggy packages.
As for pacman, then yeah I can agree that it’s a good reason to use Arch simply because you like the package manager. But that’s not what we’re talking about here.
It’s one of the features, yes, but you can’t tell me what my point for choosing Arch is, as you did in the other reply. I decide that point. Not you, not even Arch. I chose Arch for its other features, which is my prerogative, since it’s free.
This is your argument that you brought up, that the “whole point” of a rolling release system is to have the latest software. I agree that “the point of a rolling release” is “to have the latest software”. But the rolling release thing is just a bonus for me, and it’s not why I chose Arch, so that argument doesn’t work in my case. It isn’t the only feature of the system.
Well I had to bring it up because it was to show you that I don’t use Arch for its rolling release feature. 🤷♂️ People just have different reasons for choosing a distro. And thus, you can choose 👏 your 👏 own 👏 upgrading 👏 frequency 👏. That is my point. You are free to do as you wish. Nobody is holding a gun to your head telling you to run a cron job of pacman every five minutes.
While it’s true you can do that, then why choose Arch in the first place? One of the key elements in the philosophy for Arch is: Modernity, i.e. to always have the latest version to be the stable version, aka the rolling release model. You can choose not to upgrade, but it can be a immense footgun. There’s a reason it’s harder to upgrade between release versions in distros like Debian.
Besides being a stable release doesn’t guarantee no bugs either, only that they don’t change. Meaning as long as the bugs are minor or can be bypassed, it’s still considered stable.
No doubt, but you do have to keep track of this. People non familiar with it may find their systems temporarily borked if they don’t. One good mention for those of interest is their incredible documentation, it can also be used as a reference for other distros too.
In over a decade using Arch, I have encountered bugs or changes when upgrading packages, following a similar upgrade cadence. I also used packages that have been deprecated from the official repository, and then maintaned by users in the AUR. These are things that break the users experience and require maintenance. Regardless if it’s a bug or not, or if it happens once or twice a year, the user has to pay close attention.
Everyone has their reasons for choosing the distro that they choose.
I’ll copy paste what I wrote in reply to someone else with this type of argument:
Now, regarding:
And that isn’t a hassle. You sign up to it when you install Arch. If you aren’t willing to do that thing that takes a shorter time (loading up the Arch homepage) than actually issuing the upgrade command 😄, then yeah, Arch isn’t for you. Let’s concede that much, I suppose.
Right, again, that’s you creating maintenance for yourself. AUR is considered separate from the distro itself. I stand by my main point. 😁
That’s fine I suppose, though there are other distros more fitting if latest version isn’t of concern.
I didn’t need to do that, I just used a RSS feed reader directly from the Arch news. Now, for an regular user, it would be a learning experience to actually be aware of possible manual interventions, especially since Arch makes upgrading a breeze, it’s not a thing in other distros.
Actually, installing from the AUR is what helped me at the time, since the official software package was deprecated — removed from the main arch repository —, and I didn’t have time to repackage it myself. The deprecated package without a viable official replacement is what created a need to do system maintenance. And installing from the AUR was fine as long as you read the PKGBUILD, at least at the time. Regardless if either installing from the AUR, repackaging or downgrading the software were the solutions, it created friction with the end user. Which is fine for this particular distro, but for others in stable releases, it would be a major flaw.
Nice, that’s a great solution!
Ah, I misunderstood what you were saying about installing that thing from the AUR then, in your example. I get it now.
But to think that the deprecation was caused by… upgrading! 😆
We’re very deep into this thread now and I’m sort of losing the plot, and it’s very late here. But these anecdotes I find are quite rare. Surely this would be happening in a non-rolling release as well. If Arch deprecated a package, and Debian were to do so for the same reason (seems likely, perhaps?), the only difference is the time frame in which you have to/choose to deal with it. If it disappeared from the Debian repo, you’d have to find some way of replacing it yourself, too.
I might be misunderstanding you again, I feel. But I hope you see what I mean, in case I’m understanding the situation correctly.