Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alpine Linux 3.15

alpinelinux.org

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Alpine Linux 3.15

#71

Post by samgranieri »

dougbarrett wrote: post #40
vmoore wrote: 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

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.

Yes, it's defintely used for Dockerizing apps. I've Dockerized several Ruby, Node and Elixir apps using Alpine at work.

Re: Alpine Linux 3.15

#72

Post by supergarfield »

joshklein wrote: post #70
xxpor wrote: post #29

Earlier quoted context omitted.

What's the 2 minute summary of why doas is better?

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.

Re: Alpine Linux 3.15

#73

Post by fmajid »

petercooper wrote: post #2

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

Not as a desktop but I use it on bare metal as my primary server. The main advantage is the absence of bloat, e.g. components like DBus or systemd that increase the attack surface. The use of musl vs. glibc does make some things more complicated, however.

Re: Alpine Linux 3.15

#74

Post by fmajid »

wahern wrote: post #27
qwertox wrote: 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…

OpenBSD went through a similar transition, except they didn't even try to maintain ABI compatibility. See https://www.openbsd.org/55.html and https://www.openbsd.org/faq/upgrade55.html , the latter describing the rare "flag day" event. Long term this was good for OpenBSD as it saved a ton of unnecessary cruft and complexity that would have haunted OpenBSD for years if not decades, endlessly taxing developers' time, e…

There is a lot of affinity between Alpine and OpenBSD. That's a good thing in my book.

I build my entire development stack from source and don't rely on OS packages for it, and I absolutely refuse to use binary compiled Python wheels, so Alpine's lack of them is actually a feature as far as I am concerned. I dealt with the musl quirks.

Re: Alpine Linux 3.15

#75

Post by masklinn »

fragmede wrote: post #64
dotancohen wrote: post #58

Earlier quoted context omitted.

Which is arguable an attack vector. Depending on how careless the user is, there is far more likely a chance that malicious code is found in .vimrc than is found in the VIM executable.

sudoedit runs your editor as you, not root, so unless I'm misunderstanding you, no such attack surface exists.

They’re probably referring to the attack surfaces of the extensions you have loaded in your normal configuration, as opposed to the probably empty environment of root.

Re: Alpine Linux 3.15

#76

Post by lonjil »

fmajid wrote: post #73
petercooper wrote: post #2

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

Not as a desktop but I use it on bare metal as my primary server. The main advantage is the absence of bloat, e.g. components like DBus or systemd that increase the attack surface. The use of musl vs. glibc does make some things more complicated, however.

> The main advantage is the absence of bloat, e.g. components like DBus

? Like most distros that start you off but nothing but a minimal base, you can choose whether to install DBus or not. Almost everyone using Alpine as a daily driver on their PC probably has DBus installed and enabled.

Re: Alpine Linux 3.15

#78

Post by lonjil »

senknvd wrote: post #53
scandinavian wrote: post #26

Earlier quoted context omitted.

> You can't use wheels musl wheel support was added some time ago: https://github.com/pypa/packaging/releases/tag/21.0 No idea how many packages actually build musl wheels though. From a quick glance at least cryptography and lxml has musl wheels.

Unfortunately, Alpine patched their version of Python in a way that is incompatible with musllinux wheels so we are back to where we started until Alpine Linux 3.16 in 2022[1]. EDIT: I spoke too soon. Apparently, they have decided to amend the patch in a way that is both backwards-compatible and compatible with musllinux wheels[2]. Hopefully, it will roll out soon. [1]: https://gitlab.alpinelinux.org/alpine/aports/-/…

The fix has now been pushed to the 3.15 branch.

Re: Alpine Linux 3.15

#79

Post by zbuf »

dotancohen wrote: post #44
masklinn wrote: post #33

Earlier quoted context omitted.

Although it is annoyingly and quite critically missing a replacement for `sudo -e` / sudoedit (or was last time I checked).

What is wrong with `sudo vim /etc/foo`? I feel that it's better than `sudo -e`, but would love to see an example where `sudo -e` is better.

"sudo -e" prevents you committing a file with a syntax error, because that instantly locks you out of all sudo access.

The replies about security are interesting, but I think they are over-complicating this!

Re: Alpine Linux 3.15

#80

Post by dotancohen »

masklinn wrote: post #48
josepmdc wrote: post #46

Earlier quoted context omitted.

`sudo vim` will not load your user's vimrc, sudoedit will

It will also run your entire editor as root, which may not be something you want.

I actually would prefer the editor binary to run as root, rather than have my VIM config available. Any malware that could replace my system VIM would already have access to do whatever it wants to anyway. But malware to alter my own VIM configuration has a much lower barrier to entry.
Post reply on HN