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

Alpine Linux 3.13

alpinelinux.org

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Alpine Linux 3.13

#21

Post by akvadrako »

gigel82 wrote: post #2

I want to like Alpine because it's so light, but realistically you can only ever use it in Docker / VMs or for very specific locked-down needs. The musl libc makes it a bad choice for general purpose desktop use (look at the number of hacks required to get some version of VSCode running on it for example).

musl is also sometimes much slower than glib, for example with some scripting languages. Even when your workload is compatible it's usually a good idea to use another distro in your docker container.

When performance doesn't matter I think it's great though.

Re: Alpine Linux 3.13

#22

Post by ddevault »

gigel82 wrote: post #2

I want to like Alpine because it's so light, but realistically you can only ever use it in Docker / VMs or for very specific locked-down needs. The musl libc makes it a bad choice for general purpose desktop use (look at the number of hacks required to get some version of VSCode running on it for example).

I use Alpine as my daily driver on desktops, and in production on bare metal servers (and in production VMs). musl libc is much easier to debug and understand, which pays off in spades regardless of compatibility with broken (i.e. non-portable) programs. The system is exceptionally stable and reliable, which I care about very much. It's also simple, in that it does everything I ask it to, and nothing I don't ask it to. I can fit the entire system in my head.

I use Vim as my editor, and yes, programmers who value bloated, un-Unixy tools like VSCode will not find the system accomodating.

Re: Alpine Linux 3.13

#23

Post by nenolod »

skrtskrt wrote: post #20
nenolod wrote: post #18

Earlier quoted context omitted.

What is it missing that makes you feel it is unrealistic?

I am thinking more about adoption - and things that come with adoption - than functionality. It's not an option for which OS to flash onto my DigitalOcean VM. Getting it going on Raspberry Pi is largely undocumented. For desktop, it doesn't (officially) support many window managers or desktops.

On desktop, we support KDE, GNOME and Xfce, which are the big ones, but yes, we could use more work there.

It is hoped that the cloud images project will get Alpine available in all of the main platforms, we've done AWS already starting with 3.13.

Re: Alpine Linux 3.13

#24

Post by ddevault »

skrtskrt wrote: post #20
nenolod wrote: post #18

Earlier quoted context omitted.

What is it missing that makes you feel it is unrealistic?

I am thinking more about adoption - and things that come with adoption - than functionality. It's not an option for which OS to flash onto my DigitalOcean VM. Getting it going on Raspberry Pi is largely undocumented. For desktop, it doesn't (officially) support many window managers or desktops.

An important philosophy to adopt as a user of Alpine is to take responsibility for the software you want to use on it. If you need a particular window manager or desktop environment, take responsibility for packaging it and making it available. The value of Alpine has little to do with package availability, and it's easy enough to package up anything you need yourself.

Re: Alpine Linux 3.13

#25

Post by nenolod »

akvadrako wrote: post #21
gigel82 wrote: post #2

I want to like Alpine because it's so light, but realistically you can only ever use it in Docker / VMs or for very specific locked-down needs. The musl libc makes it a bad choice for general purpose desktop use (look at the number of hacks required to get some version of VSCode running on it for example).

musl is also sometimes much slower than glib, for example with some scripting languages. Even when your workload is compatible it's usually a good idea to use another distro in your docker container. When performance doesn't matter I think it's great though.

We have started to extend musl with optimized routines like glibc does. But really, the performance difference is usually minimal.

Re: Alpine Linux 3.13

#26

Post by skrtskrt »

nenolod wrote: post #23
skrtskrt wrote: post #20

Earlier quoted context omitted.

I am thinking more about adoption - and things that come with adoption - than functionality. It's not an option for which OS to flash onto my DigitalOcean VM. Getting it going on Raspberry Pi is largely undocumented. For desktop, it doesn't (officially) support many window managers or desktops.

On desktop, we support KDE, GNOME and Xfce, which are the big ones, but yes, we could use more work there. It is hoped that the cloud images project will get Alpine available in all of the main platforms, we've done AWS already starting with 3.13.

Thanks for your response!

I am tempted to go try it on AWS, but I am sticking to DigitalOcean for personal projects for reasons. I will be very happy when it shows up on DO.

Re: Alpine Linux 3.13

#27

Post by skrtskrt »

ddevault wrote: post #24
skrtskrt wrote: post #20

Earlier quoted context omitted.

I am thinking more about adoption - and things that come with adoption - than functionality. It's not an option for which OS to flash onto my DigitalOcean VM. Getting it going on Raspberry Pi is largely undocumented. For desktop, it doesn't (officially) support many window managers or desktops.

An important philosophy to adopt as a user of Alpine is to take responsibility for the software you want to use on it. If you need a particular window manager or desktop environment, take responsibility for packaging it and making it available. The value of Alpine has little to do with package availability, and it's easy enough to package up anything you need yourself.

I feel I am far from enough Linux knowledge to contribute, but I am inspired to get there.

Re: Alpine Linux 3.13

#28

Post by nenolod »

skrtskrt wrote: post #27
ddevault wrote: post #24

Earlier quoted context omitted.

An important philosophy to adopt as a user of Alpine is to take responsibility for the software you want to use on it. If you need a particular window manager or desktop environment, take responsibility for packaging it and making it available. The value of Alpine has little to do with package availability, and it's easy enough to package up anything you need yourself.

I feel I am far from enough Linux knowledge to contribute, but I am inspired to get there.

If you don't mind using IRC, there's a lot of people willing to help you get started with this adventure in #alpine-devel on freenode.

Re: Alpine Linux 3.13

#29

Post by mcrute »

nenolod wrote: post #23
skrtskrt wrote: post #20

Earlier quoted context omitted.

I am thinking more about adoption - and things that come with adoption - than functionality. It's not an option for which OS to flash onto my DigitalOcean VM. Getting it going on Raspberry Pi is largely undocumented. For desktop, it doesn't (officially) support many window managers or desktops.

On desktop, we support KDE, GNOME and Xfce, which are the big ones, but yes, we could use more work there. It is hoped that the cloud images project will get Alpine available in all of the main platforms, we've done AWS already starting with 3.13.

I'm one of the maintainers of the cloud images and I can confirm that our goal is to release at least GCP and Azure images in addition to the AWS ones for the 3.14 release cycle. We're also looking for suggestions on other cloud providers for which people would like to see official Alpine images built.

https://github.com/mcrute/alpine-ec2-ami/issues/99

Re: Alpine Linux 3.13

#30

Post by arghwhat »

gigel82 wrote: post #2

I want to like Alpine because it's so light, but realistically you can only ever use it in Docker / VMs or for very specific locked-down needs. The musl libc makes it a bad choice for general purpose desktop use (look at the number of hacks required to get some version of VSCode running on it for example).

Alpine works quite well as a desktop OS.

Using pre-built proprietary applications is the only thing that requires a little trickery.

I imagine vscode could be built and packaged just fine if someone wanted to.

Post reply on HN