101–110 of 153 posts
It has been working pretty well for me, except for a couple of issues that I ran over these years (e.g. the transition to systemd in 2012/2013, or no pacman -Syu for several weeks).
Earlier quoted context omitted.
I'm afraid simple and easy don't go well together. You either have automation to make things easy to the user, but then it's no longer simple. Or you require the user to do everything manually, but then it's no longer easy.
True. Maybe there's a viable middle ground between Ubuntu & Arch. Perhaps with a focus on the audience (e.g. a web dev distro), it becomes viable to make sensible compromises on both (easiness & simplicity) that result in a good combination for the user.
pacman corrupted my installation twice in a year. Obviously I did something wrong but who knows.
I have been using it for 10+ years and it hasn't corrupted things for me. It can't corrupt. It could get a bit tricky if you update very rarely, like once a year, but not sure what else there is to do to break things. Please elaborate a bit more.
Been using Pop OS for a while for the It Just Works(tm) experience, but I'm missing Arch more and more. Mainstream Linux distros feel a lot more like Windows these days. Sure they require less condiguration, but they're also mich harder to mess around with. Starting up htop reveals a jungle of daemons and weird systemd shit I don't even know what does. Systemd is a terribly documented nightmare to configure, etc. It'…
Earlier quoted context omitted.
Not anymore. Archinstall, an easy-to-use installation script, now comes included in the ISO and so now anyone can install it and get a full-fledged OOTB distro ready within minutes.
Does archinstall let you luks encrypt without LVM? I've never understood why every distro feels these two are dependent on each other.
pacman corrupted my installation twice in a year. Obviously I did something wrong but who knows.
probably you installed something manually at some point, otherwise pacman does nothing wrong. Rarely you have to touch something manually because a mayor upgrade, but I think it has been like 4-6 times in 20 years for me. If you want to install something manually in arch it is better to create a package first (if it is not already in aur). That way pacman can check for corruptions before installing anything
> The installation process, and the documentation behind it, lead to the third virtue: a complete installation tends to be very small and simple, because you only install the bits you need. If you don't know what bits you need, the documentation will help you to work it out, and the result is something that is both fairly minimal and that, with luck, you understand. You know what's in there because you installed it.…
I love hearing that, because it was a goal of Arch from the very beginning: to stop fearing the commandline.
And I was the first alpha tester, in that I wanted to learn more about how the sausage was actually made, so to speak. I was comfortable using things like Linuxconf at the time, but its beginner-friendly veneer meant that I didn't really know what to do if it _wasn't_ there.
After tinkering with Crux and PLD for a bit, I wanted to go deeper and start from nothing. So I loaded up the LFS[1] docs and just started typing in the shell stanzas to start building my compilation toolchain. In an effort to DRY as much as possible, the work also got placed into shell scripts, which eventually became PKGBUILD modules.
I started having way too much fun with it, so I put up the world's ugliest webpage[2] to share my triumphs, and a couple people found it, somehow. That begat the immediate need for documentation, which eventually brought Arch into the forefront. I can't recall who spearheaded the Arch wiki, but we owe them a great debt, because it has become a valuable resource for Linux users, and not only the Arch users.
Arch is my happiest accident.
ps: btw, I run Arch (is this still a meme?)
[1] https://www.linuxfromscratch.org/
[2] https://web.archive.org/web/20020328043401/http://www.archli...
Earlier quoted context omitted.
They had multiple issues with opsec in the past. Something that when repeats, makes people skittish. Fool me once and al..
I am not aware of critical issues, but there was indeed a time of confusion, when the dev leadership changed. So sources please for current flaws?
Big ones are: shadiness with funding, letting their SSL certs expire 4 times, and the fact that their idea of stable isn't additional testing, but just letting the packages sit for a week.
There was also a recent kerfluffle not covered there where they shipped a broken kernel to Apple Sillicon users without contacting the Asahi devs: https://twitter.com/AsahiLinux/status/1576356115746459648
Earlier quoted context omitted.
They had multiple issues with opsec in the past. Something that when repeats, makes people skittish. Fool me once and al..
I am not aware of critical issues, but there was indeed a time of confusion, when the dev leadership changed. So sources please for current flaws?
The link for the post is dead, but they've let their SSL cert expire multiple times. While it happened a few years ago, I find that a hard thing to come back from.
Earlier quoted context omitted.
Can you elaborate? In what way is Alpine more minimal than Arch? (I really just don't know) Also are you suggesting that Debian netinstall is not minimal?
Alpine base rootfs is just a few megabytes, while Arch is like 100-200MB. I usually encounter Alpine in Docker containers when people want to wrap just one specific service and have save space on things that are not essential for it (it would be wasteful to ship your 20MB app in a 200MB Arch/Debian container). I didn't know Alpine was useful as a working machine though.
[0]https://hub.docker.com/_/archlinux/tags
[1]https://hub.docker.com/layers/library/debian/stable-slim/ima...