If you have been an apple costumer for a long time you should recognize this pattern.
Once the product gets too complex and competitors start closing in attention to details will be replaced by bugs. It's like apple can't do agile development of their life dependent on it.
If only Debian had the documentation that Arch does. I know there's man and help, but the Debian wiki seems sparse and out of date, where the Arch wiki is incredibly thorough. Sometimes I find myself at the Arch wiki to do things in Debian, but that doesn't always work. So I generally stick to Fedora, which at least sticks close to upstream.
This used to be a thing! I remember the first time I installed Debian (back in the 2.0 days, I think) and it came with the "HOWTO" packages, which were essentially precursors to the semi free-format Arch wiki. That's how I learned how to configure kernel modules, what the difference between installing Linux using UMSDOS vs. a real partition, and even how ReiserFS worked.
I really feel like easy internet access has taken good documentation away from us. It's too easy to Google for something, find some crappy blog with barely enough instructions to fix the problem. We've become reactive, rather than pro-actively educating ourselves.
Most packages have pretty good documentation about anything Debian-specific installed in /usr/share/doc/<packagename>/README.Debian[.gz] and /usr/share/doc/<packagename>/NEWS.Debian[.gz].
Arch is very stable when using mainline packages, which are the default packages...
This is "Arch is unstable" thing is very much a myth pushed forward by people who only dabbled with Arch once or twice then had it break, then completely dismissed it as unstable. Without first learning how to use it even at an intermediate level - not even expert.
I too had Arch break when I was a newbie but I learned quickly how not to and it's been incredibly stable ever since. Not worse than Debian and more so than Fedora in my experience.
In retrospect my actions which had broke it originally had little to do with ArchLinux itself but a general inexperience with Linux and over-eagerness when using beta software (which you have to opt in to, it's not default with Arch).
The end result is that I've come out of it a far better Linux user with skills highly applicable to Debian and other distros. It's a far easy place to learn Linux/Unix properly and become familiarized with the OS/dir structure/config than any other distro.
My experience as an experienced user of e.g. NixOS is that if you leave an Arch system alone for a couple of months and then try to update it, something will break horribly, because something will have changed in a non-backwards-compatible way and so I have to go and try to figure out what the new configuration should be, without good error messages. At least with NixOS, it’ll probably fail during the rebuild stage, rather than once you’ve restarted some random service or decided to reboot. I don’t really want to be doing that - I don’t have a love for system administration, I want a system which gets out of my way for me to do my work.
I don’t have to be careful about opting in to beta software or anything else with NixOS. If I want to try something, I can do so, and roll right back if it doesn’t work out. The destructive nature of Arch package installs and updates is its biggest flaw.
It is very much a matter of perspective. Arch is more than stable enough for personal use, but is highly unstable in the context of enterprise servers, especially compared with the likes of Debian and RHEL.
Meh. Debian user of at least 15 years here. I found Arch quite refreshing, in that the setup felt like a modern Slackware (eg Wicd back when NetworkMangler was super-opaque). But the updates still made me queasy.
> This is "Arch is unstable" thing is very much a myth pushed forward by people who only dabbled with Arch once or twice then had it break, then completely dismissed it as unstable.
This accurately describes my experience. I stopped using Arch around the time git broke when I updated. I'm not clear what mistake I made. What level of Arch intermediate or expert level Arch knowledge is required to keep git working?
Not really. Arch has a strict upstream rule, they avoid patching or maintiain dead shit. So when the hellish time when KDE4.0 came out, they released it immediately. Anyone upgrading on a 3.5 system was severely disadvantages
I used Arch for years and years, and it would just break sometimes on regular package updates. Nothing that couldn't be fixed with a live CD, but still annoying.
Not enough data points to really count, but I have had a lot of bad experiences with Debian updates failing or suddenly deciding that vim conflicts with something so it has to remove half my packages... Arch, however, has always been dependable in the five-odd years I've run it full time. Including machines that don't get upgraded for many months at a time. I don't know if I'd put in on a "server" that I ran for other people, but personally I have yet to see problems arising from the rolling release model.
I always found it odd that one "needed" a large amount of software (Windows, IDE) to program something so small.
Additionally, the IDE is often under the control of the manufacturer. I understand there are good reasons why this means there will be "bloat". Manfacturers are acting sensibly in their own self-interest.
As a hobbyist, I prefer chips that I can program using a UNIX-like OS that I can compile from source.
I prefer to program from VGA textmode, i.e., no GUI. I am not going to run Windows just to program a tiny microcontroller.
"Handling" dependencies automatically is fantastic when it works. But it reaches varying degrees of anarchy and hopelessness when it doesn't.
The more ambitious the framework, the more you have to wade through to figure out what it's actually doing when something breaks...I'd much rather have to deal with some cross-compilation headaches and dependencies than to be at a dead end when the 'black magic' stops working.
I see a possible problem with that statement: starting from a poorly secured sellers site, users can't really be sure if he ends up on the real PayPal page anyway.
This might be an unpopular opinion here, but I have the same problem with rust.
There are often multiple ways to do something remotely complex and out of all perfectly valid solutions I can come up with at most one is accepted by the compiler.
Go on the other hand has a compiler that reads your mind. or maybe its simply a really well designed language...
Those utf8 bugs that kill your phone on the other hand... How many of those had Apple had by now?
https://www.youtube.com/watch?v=HUE9mCN7sek