Live data from Hacker News

Alpine Linux 3.15

alpinelinux.org

81–90 of 91 posts

Re: Alpine Linux 3.15

#81

Earlier quoted context omitted.

Configuring sudo is such a footgun that it was deemed necessary to fork a text editor purpose-built for only modifying sudo configurations (visudo). So, that’s why not sudo. As for why doas, see: * https://flak.tedunangst.com/post/doas * https://flak.tedunangst.com/post/doas-mastery

visudo isn't a fork, it just locks the sudoers file against concurrent edits, runs whatever standard editor you want, waits for it to finish, and validate the new file before committing it to the real location. I can agree that process is too complex, but they're not maintaining a fork of vi for that purpose.

> and validate the new file before committing it to the real location

Controversial take: i think that it'd be really good to have EVERY configuration file have something like that. For example, if i'm working on a long bit of configuration for fstab, cron, Apache2, Nginx, Tomcat or any other pieces of software, i'd want to see whether everything i've written will be considered valid ahead of time, e.g. a "dry run" of sorts. A bit like we have language servers for VS Code, we could have validation servers as well, for configuration.

That said, i don't think we'll ever have that, since it's easier to just write code in an ad-hoc manner, as opposed to extracting validation of configuration as a separate bit of code that can be called from some CLI, not just at runtime, especially since many configuration files allow nested includes.

Regardless, thinking more about models and validation methods would be nice, e.g. XSD. If we leverage type systems in programming languages, we might as well do that at an operating system level - something like shellcheck built in. A validation handler for every file type.

Re: Alpine Linux 3.15

#82
post #55
post #21

Earlier quoted context omitted.

musl really becomes a pain if you work a lot with Python. You can't use wheels, which means you will have to compile everything yourself, which sometimes takes ages, and you're not guaranteed that it won't have unnoticeable errors. My biggest issue was with the 3.12 -> 3.13 transition, when musl got upgraded to 1.2 and with it "musl 1.2 uses new time64-compatible system calls". This broke so many things for me withou…

Actually, you can run most wheels just fine if you do this: https://github.com/insightfulsystems/alpine-python/blob/5a34... You just need to know how :)

I did know this, but it wasn't 100% reliable, see https://github.com/grpc/grpc/issues/18150

Regarding the "runs just fine", this is not guaranteed. I certainly do check if it is working, and if it is, and it is a small service or just a containerized tool, then I'll use it. Like using GDAL to perform some reprojections and renderings where a throwaway container is called from a shell script, if it works once, I'll keep using it, but I won't use it to run a Python server which also makes use of Matplotlib and other big dependencies.

Re: Alpine Linux 3.15

#83
post #36

Does anyone know where there are screenshots of this on the website? I like to see how a desktop looks before I try a new distro. Seems absent on the site

You can install any Desktop Environment you want.

You can do that in any distro. I think the OP refers to the fact that, usually the distro supplies some default config files for the DE which makes it look distro specific.

Re: Alpine Linux 3.15

#84
post #50
post #3

Earlier quoted context omitted.

Not really. It's not designed for that. It's designed to be as lightweight as possible. also, instead of Glibc, it uses musl, which although is supposed to be binary-compatible, does have some gotchas, so the larger the system, with more apps and libraries running on it expecting glibc, will have issues.

It is designed for desktop use, actually. Many of Alpine's developers use it as their primary PC distro :)

I never read anywhere that it was designed for desktop, but they've always included the packages. Firefox was pretty much the only browser available and was unusable for years because of some math issues with font rendering if I remember correctly. ( I have attempted to daily drive it from time to time). In this regards it's pretty obvious Void Linux is more desktop focused.

Alpine is supposed to be a small, stable and secure general purpose base.

Re: Alpine Linux 3.15

#86
post #20

Earlier quoted context omitted.

I use it on my desktop:) It's a nice experience after a slight learning curve; I'm particularly fond of it supporting ZFS well without being Ubuntu. Musl libc is a potential pain point; I get most software from official repos or build from source, but ex. to run Steam I resorted to flatpak (which just shoves glibc in the container with the application).

For an average user, I'd guess they'd hit more issues with busybox than musl.

I use it as a daily driver. Here is my setup. Coreutils is included.

https://lamda-chops.bearblog.dev/alpine-linux/

Re: Alpine Linux 3.15

#87

I'm familiar with Alpine in container scenarios, but is there any mileage to using it as a day-to-day desktop distro?

I'm using it on my laptop (Thinkpad X270) and it's great.

I don't think there's much credibility to saying it's not "meant to be used" as a desktop; since the packages available suggest to me there's clearly a bunch of people doing just that.

What you can expect is more manual setup (compared to say, OpenBSD, where things work really well out-of-the-box on this hardware). But I took this opportunity to set up an encrypted disk. This is with no "desktop environment", just a window manager and X.

I thought BusyBox would be a pain, but the GNU tools can be automatically installed. Same with musl, which was much less of a big deal than I thought. I can even suggest things feel faster with it, but it does mean staying within packages from the Alpine ecosystem.

I'd be interested if anyone is doing a glibc fork of Alpine (or a way to run the 'full fat' glibc seamlessly, like it does with the GNU tools). Also worth experimenting with Alpine's glibc emulation; I was amazed how good it was, as it runs almost all of a closed-source music production tool that I use.

Re: Alpine Linux 3.15

#88

Earlier quoted context omitted.

visudo isn't a fork, it just locks the sudoers file against concurrent edits, runs whatever standard editor you want, waits for it to finish, and validate the new file before committing it to the real location. I can agree that process is too complex, but they're not maintaining a fork of vi for that purpose.

> and validate the new file before committing it to the real location Controversial take: i think that it'd be really good to have EVERY configuration file have something like that. For example, if i'm working on a long bit of configuration for fstab, cron, Apache2, Nginx, Tomcat or any other pieces of software, i'd want to see whether everything i've written will be considered valid ahead of time, e.g. a "dry run" o…

Nginx does have a "dry run" mode for checking configs (unless that something external - like unresponsive servers - is experiencing problems).

Re: Alpine Linux 3.15

#89
post #83

Earlier quoted context omitted.

You can install any Desktop Environment you want.

You can do that in any distro. I think the OP refers to the fact that, usually the distro supplies some default config files for the DE which makes it look distro specific.

... except that it's command-line by default, so the DEs has whatever Gnome/KDE decided them to look (rather than adding wallpapers and such).

Re: Alpine Linux 3.15

#90
post #66

Earlier quoted context omitted.

From what I understand of alpine, it's commonly used for Docker images to provide a lightweight distro for your apps vs using something like ubuntu or debian which may include more than what's required. I don't believe it's intended to be used in a desktop environment, but I could be wrong.

This is false; you can install a variety of DEs from the repos.

Got it. Thanks for correcting me!
Post reply on HN