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

51–60 of 91 posts

Re: Alpine Linux 3.15

#51

Post by lonjil »

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?

As long as you're OK with the limitations imposed by using musl, I think it's great on the desktop. I recently switched from Void Linux (glibc variant) and it's working very well. I run proprietary applications like Spotify, Steam, and Discord in Flatpak, and most of the rest from Alpine's repos.

One thing that surprised me is that KDE's software center gives package update notifications for Alpine packages OOTB, and the GUI Just Works(tm) for installing and upgrading.

Re: Alpine Linux 3.15

#53

Post by senknvd »

scandinavian wrote: post #26
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…

> 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/-/issues/13227 [2]: https://bugs.python.org/msg406939

Re: Alpine Linux 3.15

#54

Post by dotancohen »

masklinn wrote: post #49
dotancohen wrote: post #44

Earlier quoted context omitted.

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.

> What is wrong with `sudo vim /etc/foo`? Aside from forcing vim onto innocent users? > I feel that it's better than `sudo -e`, but would love to see an example where `sudo -e` is better. It is way worse than `sudo -e`, because it runs the entire editor as root, whereas `sudo -e` runs a few file copies / move as root. So `sudo -e` has a significantly lower amount of stuff in the "secure zone", and thus, much in the s…

  > Aside from forcing vim onto innocent users?
Actually, `sudo -e` forces VIM onto innocent users. You are free to `sudo nano` if that's your preference.

  > `sudo -e` runs a few file copies / move as root.
Interesting, thank you, I did not know that the editor is not run as root with -e. So presumably that means that it will have my environment, e.g. will run my .vimrc? Though that could be an attack vector too.

Re: Alpine Linux 3.15

#55

Post by rcarmo »

qwertox wrote: post #21
pionar wrote: 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.

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 :)

Re: Alpine Linux 3.15

#56

Post by throwaway984393 »

kingofclams wrote: post #31
xxpor wrote: post #29

Earlier quoted context omitted.

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

Smaller, less features, ideally less vulnerabilities.

On the one hand, I get that not everybody needs all the features of sudo, but on the other.... Sudo is way more useful than doas. If you really go through all its functionality, you start using it in ways you didn't think to before.

You can have a custom AuthZ solution and automatically inherit sudo permissions based on groups. It supports a configurable askpass. You can background jobs, change working directory, selectively pass or set environment variables, set $HOME, use a login shell, preserve origin groups, use a chroot, read a password from STDIN, override the shell, set a timeout. And of course the sudoedit features.

I know we all like programs that "do one thing well", but sometimes the best way to support all the use cases we want is a big honking program.

Re: Alpine Linux 3.15

#57

Post by rcarmo »

scandinavian wrote: post #26
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…

> 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.

This still works for me:

https://github.com/insightfulsystems/alpine-python/blob/5a34...

But I haven’t tested today’s version yet.

Re: Alpine Linux 3.15

#58

Post by dotancohen »

josepmdc wrote: post #46
dotancohen wrote: post #44

Earlier quoted context omitted.

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 vim` will not load your user's vimrc, sudoedit will

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.

Re: Alpine Linux 3.15

#59

Post by rcarmo »

nick238 wrote: post #34
El_RIDO wrote: post #11

Earlier quoted context omitted.

The packages are either python3 or python2 for the language, and prefixed py2- or py3- for any of the packaged modules. https://pkgs.alpinelinux.org/ does support wildcards so you should find the packages using "python?" or "py?-*".

There is a pretty good set of maintainers/packagers that compile Python libs for Alpine, but if you stumble across one that doesn't have a binary built, you're going to have to install the whole build toolchain and get all the headers yourself. The pre-compiled manylinux* binary packages on PyPI aren't compatible with Alpine.

Try this:

https://github.com/insightfulsystems/alpine-python/blob/5a34...

Re: Alpine Linux 3.15

#60

Post by masklinn »

dotancohen wrote: post #54
masklinn wrote: post #49

Earlier quoted context omitted.

> What is wrong with `sudo vim /etc/foo`? Aside from forcing vim onto innocent users? > I feel that it's better than `sudo -e`, but would love to see an example where `sudo -e` is better. It is way worse than `sudo -e`, because it runs the entire editor as root, whereas `sudo -e` runs a few file copies / move as root. So `sudo -e` has a significantly lower amount of stuff in the "secure zone", and thus, much in the s…

> Aside from forcing vim onto innocent users? Actually, `sudo -e` forces VIM onto innocent users. You are free to `sudo nano` if that's your preference. > `sudo -e` runs a few file copies / move as root. Interesting, thank you, I did not know that the editor is not run as root with -e. So presumably that means that it will have my environment, e.g. will run my .vimrc? Though that could be an attack vector too.

> Actually, `sudo -e` forces VIM onto innocent users

No, it does not. It runs whatever EDITOR is set to (technically the first set of SUDO_EDITOR, VISUAL, and EDITOR).

> So presumably that means that it will have my environment, e.g. will run my .vimrc?

That is correct.

> Though that could be an attack vector too.

Only on the specific file, which would usually be a lot more noticeable unless the attack specifically manages to recognise and target sudoedited files while closing the buffer.

Post reply on HN