19 ms·

A BSD person tries Alpine Linux

280 points by Tomte 3y ago

LeFantome 3y ago
I wonder what they would think of Chimera Linux: https://chimera-linux.org/ https://chimera-linux.org/
ggm 3y ago
I am also also a bsd person and also coincidentally ran my first alpine as a vm on bhyve this week. It's busybox. If you don't need explicitly discrete binaries of the /bin and /sbin utils it is a tiny user-space and fast to boot. Tmux, zsh and I was done for most unix purposes. To get to my endpoint I wound up doing a lot of apk installs (node. More node dependencies. Stuff) but overall I found it the best Linux experience I've had in a long time. I wish zfs was baked in, and more overt virtio bindings to things for bhyve zfs backed run.
- chillfox 3y ago
  ZFS works great with Alpine. Alpine + ZFS has been my default server setup for years.
- AndrewDavis 3y ago
  > zfs was baked in How baked in? I think Alpine is one of the few distros to ship a binary zfs kernel module. So it's just a quick apk command away from getting it. There's some pretty decent documentation to install zfs on root on the alpine wiki too https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_encryption https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
  - ggm 3y ago
    Right, but the steps aren't scripted or integrated into the mainline. You're of the main path, albeit a damn sight simpler than some distros. Easy, but not 'simple'. Don't get me wrong, it's entirely doable. But it's a distinct, non-standard pattern. And virtio..
    - wkat4242 3y ago
      Yeah "apk add ZFS" is very scary and off the beaten path :) That's all you need to use ZFS data drives on alpine. On root is admittedly a lot more complex though.
      - ykonstant 3y ago
        Is it particularly helpful to use ZFS on root?
        yjftsjthsd-h 3y ago
        I've actually used snapshots to roll back an upgrade that got messed up. Of course, Alpine is stable enough that it doesn't exactly come up a lot:)
        Modified3019 3y ago
        ZFS on root (and setting up automatic snapshots) is great for rollbacks if a system update turned out bad, and also allows for being certain there’s no corruption after a power failure or a disk starts getting flaky. It also makes sending off snapshots for a backups a breeze. So it’s not really for day to day issues, it’s more for turning a rare “day of pain” into something much less.
        ssl-3 3y ago
        AFAIK, for events like unexpected power failure, ZFS is always consistent to the point of the last complete TxG. No snapshot required (and it wouldn't provide more-recent data, either) to deal with power failure-induced data corruption, because there isn't any. And also AFAIK, ZFS snapshots don't protect against data corruption from flaky disks: An online snapshot doesn't make a copy of anything. (That's more like what RAIDZ or copies=2 are for.) Snapshots do make great rollback methods, even for fixing dumb day-to-day mistakes. (I mean, I'm sure none of us have ever done something stupid with a computer, but it probably happens to someone sometimes.) And they are indeed easy to send elsewhere to be used as complete backups of a dataset's state at a single point in time. And there's other good stuff about daily use of ZFS root, too: Datasets. Like other filesystems, ZFS does occupy an entire disk (or a partition on that disk) -- in this case a "pool". But within that pool can be many, many datasets that are independent of one-another, just sharing space in the pool. One linux distro's root might occupy one dataset, and another more-experimental (or major breaking upgrade) distro's root might occupy another dataset. /home can be on a third dataset that both distros use. This is a very wonderful thing for those with limited hardware budgets -- gone are the days of resizing/paring down disk partitions just to try something different. (Datasets can also be copied or moved to different pools and those pools can be different sizes.) Or: Caching. Now that persistent l2arc is a thing, a snappy-feeling system can be built with big (redundant!) spinning disks, and a relatively small (fast!) SSD as a read cache. It's not really just for "day of pain" issues -- ZFS is pretty slick in all kinds of useful ways, as a root filesystem and elsewhere.
  - vermaden 3y ago
    > How baked in? Like in FreeBSD - to be as available option in installer. In FreeBSD You just select 'Auto (ZFS)' - then select disk(s) on which it should happen - hit [ENTER] - and it happens. That level of integration I would expect ... and all that with ZFSBootMenu integration for ZFS Boot Environments.
- dazzawazza 3y ago
  I've used/deployed FreeBSD for over 20 years and I have to admit I dread connecting to a GNU/Linux box. It's just such a mess of a system with so many variations in inconsistencies. Even connecting to a Windows server makes more 'sense' to me. Anyway, I'm glad to hear that there might be a sane Linux distro out there. I will give it a go if I need a linux box which is pretty rare tbh.
  - aeonik 3y ago
    Everyone who uses BSD says the same thing, but it's still unclear to me what you mean. What inconsistencies does Linux have that BSD does not? I've looked for an explanation, but I only get high level explanations, or specific features like jails. You wouldn't happen to have more information, would you?
    - kstrauser 3y ago
      My Debian server has a mix of systemd and /etc/init.d startup scripts. That’s the sort of thing where a BSD would be likely to say, ok, as of version N due in 3 months, we’re migrating everything and going from 100% old way to 100% new way.
      - cesarb 3y ago
        > My Debian server has a mix of systemd and /etc/init.d startup scripts. [...] ok, as of version N due in 3 months, we’re migrating everything and going from 100% old way to 100% new way. You'll be happy to know that this is going to happen. Quoting https://github.com/systemd/systemd/blob/v255/NEWS https://github.com/systemd/systemd/blob/v255/NEWS > Support for System V service scripts is now deprecated and will be removed in a future release. Please make sure to update your software now to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases.
        kstrauser 3y ago
        Eh, I don’t really care either way. The ones I really care about are in my shell history. I meant that more as an example of where the BSD way would be different. Since they manage all of the software together, it’s much easier for them to do wholesale migrations like that.
blueflow 3y ago
Alpine has come cool perk: When a Nix user is flexing about declarative package management, live-edit your /etc/apk/world and run `apk fix` to show them how to do it without Nix.
- mbrock 3y ago
  I can reinstall Alpine from scratch in around the time it takes Nix to evaluate my system flake
- lambdaba 3y ago
  That's cool but Nix/OS does much more than declarative package installs.
  - intelVISA 3y ago
    my fave Nix feature is telling people I use it
    - MaKey 3y ago
      The new "I use Arch btw".
      - vaylian 3y ago
        I use the nix package manager on Arch btw
      - aodonnell2536 3y ago
        Arguably the original one, too.
    - cqqxo4zV46cp 3y ago
      If it were easier to use, it wouldn’t be as big a flex. So we can’t be having that!
      - orbat 3y ago
Faelian2 3y ago
Just my two cents about the security aspect. All Linux binaries are compiled with PIE nowadays. You can run `checksec` on any binaries on Ubuntu, and it will have those properties. (You can install checksec with `pip install pwntools`). On the other hand, GLIBC has, to my knowledge, the most hardened heap implementation out there. And there are more mitigations for double-free and other heap exploits on GLIBC. So in that regard, Alpine is less secure by using musl. Having a small, understandable system is a real advantage when it comes to security.
- blueflow 3y ago
  > Having a small, understandable system is a real advantage when it comes to security. How did that look like in your mind that it is a point for (and not against) glibc?
  - balder1991 3y ago
    That got me confused too.
    - segfaultbuserr 3y ago
      It was pretty clear to me that the comment was a description of the respective characteristics of glibc and musl in terms of security, while avoiding any conclusion: glibc has heap hardening, which is good for security, but a complex codebase, which is bad for security. Meanwhile, musl is small and understandable, which is good for security, but with a naive codebase that lacks hardening, which is bad for security. Which is better is intentionally left to the reader to avoid flamewars.
      - lolinder 3y ago
        That's a charitable reading but it doesn't track with what they actually said. The first paragraph says that all modern Linux binaries are compiled with PIE, so Alpine has no advantage there. The second paragraph says that glibc is more secure than musl heap-wise. The third paragraph is the conclusion, which is that Alpine is less secure because it uses musl. A sentence thrown on to the end of the conclusion should normally be read as reemphasizing the reasons for the conclusion unless it starts with a word like "though" or "however".
_joel 3y ago
I found Alpine to be a lot slower than glibc based distros.
- rany_ 3y ago
  In terms of what? Boot times?
  - frankjr 3y ago
    Musl's memory allocator is (was?) subpar compared to glibc's, especially in multi threading contexts. https://news.ycombinator.com/item?id=23080290 https://news.ycombinator.com/item?id=23080290
    - rwaksmunski 3y ago
      It's a bit better now, but still nowhere near FreeBSD's jemalloc.
  - _joel 3y ago
    Usage, I converted a bunch of containers to it from debian-slim in our fairly large CI/CD setup and it processed workloads noticably slower, despite booting slightly quicker as it's a smaller pull. However, with network speeds nowadays, it was negligible difference and not worth it. Rolled it back to debian-slim.
    - cduzz 3y ago
      Would these performance concerns be an issue if you were using alpine "on the metal" and debian containers? When running complex applications I find it's simplest to "compile" the application into a container thus rendering some tedious complex runtime to a static binary that's trivial to run without worrying about tedious dependency management. It burns a bit of storage but that's not a big deal these days. If someone suggested to me "hey I want to run a big PHP / nginx / mysql workload for my startup; should I use alpine?" I'd suggest they find a doctor.
qweqwe14 3y ago
BSD users might also like Void Linux, which was developed by xtraeme (a NetBSD developer). It has glibc and musl versions and uses runit as an init system. You can also build packages from source using xbps-src. https://voidlinux.org/ https://voidlinux.org/
- BSDobelix 3y ago
  And CRUX, a granddaddy of Archlinux.
- ykonstant 3y ago
  I am loving Void; my main system is Arch because of the large package selection and systemd ergonomics, but I have installed Void on three boxes for relatives and myself, and it's been wonderful. Warning though: I have only used the xfce installation with minimal tweaks. Also, a complex multi-user setup with void might be a bit more tedious to setup because runit is less batteries-included than systemd.
  - deleted 3y ago
    [deleted]
- jackhalford 3y ago
  I had issues with voidlinux+musl for using rust but that was a couple years back. Thankfully you can easily reinstall void with glibc
- stock_toaster 3y ago
  Maybe Chimera? Probably very friendly for BSD folks since it has a mostly FreeBSD set of core tools (userland).
  - ethagnawl 3y ago
    This initially threw me but it appears to be distinct from ChimeraOS, which is described as a, "Steam Big Picture based couch gaming OS".
ilhuadjkv 3y ago
I've been disto hopping since, i guess the beginning (mid '90s). Have been on Alpine for around 18 months now and it's the first time i've EVER thought 'this is my forever distro'
- maayank 3y ago
  What did you especially like in it?
- yard2010 3y ago
  What other distros you went through and what were they like? When do you decide to move? Did you ever go back?
- adamomada 3y ago
  I’m curious if you tried out Void Linux and later switched to Alpine? I hear similar comments from void users
Arch-TK 3y ago
I honestly have no idea why people find OpenRC and such things appealing. Literally any supervision based option is better than leaking your PIDs, storing them in PID-files and hoping that the value in the PID file still refers to the daemon you ran after 3 weeks. To top it off, in some cases some service management tasks are handled by pgrepping for a specific process name. I can somewhat sympathise with the idea that not everything should be auto-restarted by default but that's literally the only thing these kinds of things have going for them. Also, inevitably these things heavily rely on syslog, which is the most 80s technology ever invented. I agree that multilog/svlogd/whatever could be improved to add an easy centralised view (when you need to know the sequence of events from multiple tools) but grouping logs by some vaguely defined category which you always get wrong, and letting anyone log anywhere with any name are such strange features.
- traverseda 3y ago
  Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. There's just way too much going on in PID1, written in a memory unsafe language. I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. Aside from it making it possible to run systemd inside a docker container, which I presume redhat/IBM is strongly against, preferring you to use their in-house containerization tools like systemd-nspawn. It's just never going to be viable from a security point of view with how it's architected.
  - blueflow 3y ago
    > I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. More detailed: Systemd conflates the init system (PID1) and service supervisor. And as a service supervisor, it isn't really that reliable.
  - Arch-TK 3y ago
    There are literally at least 3 well designed and featureful alternatives to OpenRC which are not systemd: daemontools, runit, and s6-rc. There are also other lesser known options. For a real world in-situ use of runit, see voidlinux. It could be handled better but at this present moment it is at least no more clunky than using OpenRC.
philjohn 3y ago
Doesn't musl still not support pthread_attr_setaffinity_np, which means you can't run some software on it. PyTorch being the biggest.
- cduzz 3y ago
  I imagine if you've got some performance sensitive workload that relies on glibc for that performance you would "just" run that application in a container. For many situations, performance is a secondary concern relative to simplicity or security.
rjst01 3y ago
Huge Alpine fanboy myself. I love that a clean install has less than ten processes and I know what they all do. The community is also very good at building packages that "just work" - the article points out ZFS, but also docker, podman, libvirt are trivially installable. > Perhaps the package I was most surprised about was zfs. ... What that would look like after an upgrade I’d have to see, but thus far I’m impressed. I can confirm it works smoothly. I've observed that the ZFS package is updated whenever the kernel is updated.
vermaden 3y ago
Its all nice and small, etc. but its Apples to Oranges comparison. On FreeBSD You have ZFS with ZFS Boot Environments - which gives GREAT flexibility and protection against all kind od updates, changes and even accidental files deletion in the system. Moving to 'oldschool' LVM and EXT4 is just a huge downgrade. Especially without any advanced features such as compression or snapshots or clones or ... all the other wonders from ZFS. As from the busybox ... You can also use it on FreeBSD - its under 'sysutils/busybox' port ... and FreeBSD has 'kinda' itself busybox-like solution - its called FreeBSD Rescue System and its located at /rescue. It contains one executable file 17 MB in size (and ZFS lz4 makes that 11 MB) with hardlinks as commands - including all needed ZFS commands - which BusyBox obviously does not have. FreeBSD % % du -sm /rescue 11 /rescue FreeBSD % du -smA /rescue 17 /rescue FreeBSD % ls /rescue [ dhclient gbde kldstat mt rmdir umount bectl dhclient-script geom kldunload mv route unlink bsdlabel disklabel getfacl ldconfig nc routed unlzma bunzip2 dmesg glabel less newfs rrestore unxz bzcat dump gpart link newfs_msdos rtquery unzstd bzip2 dumpfs groups ln nextboot rtsol vi camcontrol dumpon gunzip ls nos-tun savecore whoami cat echo gzcat lzcat pgrep sed xz ccdconfig ed gzip lzma ping setfacl xzcat chflags ex halt md5 ping6 sh zcat chgrp expr head mdconfig pkill shutdown zdb chio fastboot hostname mdmfs poweroff sleep zfs chmod fasthalt id mkdir ps stty zpool chown fdisk ifconfig mknod pwd swapon zstd chroot fetch init more rcorder sync zstdcat clri fsck ipf mount rdump sysctl zstdmt cp fsck_4.2bsd iscsictl mount_cd9660 realpath tail csh fsck_ffs iscsid mount_msdosfs reboot tar date fsck_msdosfs kenv mount_nfs red tcsh dd fsck_ufs kill mount_nullfs rescue tee devfs fsdb kldconfig mount_udf restore test df fsirand kldload mount_unionfs rm tunefs The MUSL also limits some things - but that is topic for another discussion. ... and do not get me wrong - I like Alpine (same as Void or Gentoo or Devuan) - its just not the same thing. ... and its even possible to setup Alpine with root on ZFS - https://openzfs.github.io/openzfs-docs/Getting%20Started/Alpine%20Linux/Root%20on%20ZFS.html https://openzfs.github.io/openzfs-docs/Getting%20Started/Alp... - it will just take a quite large amount of work while on FreeBSD you just select 'Auto (ZFS)' installer option and hit enter. Hope that helps.
vermaden 3y ago
I also liked how the '[ok]' moved to the right after GPU drivers have been loaded :) - https://rubenerd.com/files/2024/alpine-openrc.png https://rubenerd.com/files/2024/alpine-openrc.png Of course its OpenRC related and not Alpine. IMHO it would looked more 'nice' if the '[ok]' stayed where they were - at least till 'login:' prompt - but I know that its just implemented in a way that 'write [ok] after space from right side of the screen' and as resolution increased - it happened what happened. They could just move the '[ ok ]' or '[fail]' to the left - beginning of the message - that would 'solve' that problem also.
- Sharlin 3y ago
  Technically, they could keep track of where each ok/fail was printed and erase and repaint them after the resolution change – if your terminal supports ANSI color it is essentially certain to support cursor movement commands too (inb4 someone counters that they have a color hardcopy terminal!) But I doubt anyone cares enough to implement that. I used to think these screenfuls of scrolling diagnostics were super cool and felt like a real hacker when I was 16 years old and first started playing with Linux, a feeling likely shared by many. These days I prefer a minimalistic boot, as long as the diagnostics are easily accessible when there’s a need to debug something. And in that case it doesn’t matter much ehether everything lines up neatly or not.
sebtron 3y ago
I was expecting some comment on the fact that man pages, a point of pride for the BSDs, are not included by default in Alpine. That's one of the reasons that kept me from using it on my travel laptop (now running OpenBSD). Alpine users, am I missing some configuration option to make sure all documentation is always installed when getting a package? Or is manually installing the -doc package every time the only way?
- stock_toaster 3y ago
  If you always want docs, you just install the `docs` meta package that will pull in any `*-doc` package for anything else you install.
  - sebtron 3y ago
    Thanks, that's exactly what I needed!
  - chupasaurus 3y ago
    It works similarly in i.e. Debian, so it's not really a quirk of Alpine.
    - oarsinsync 3y ago
      Can you elaborate on what you mean here? I’ve never seen a Debian install packages without docs in 20 years. What have I been doing right/wrong?
      - hedora 3y ago
        If you use a `-slim` debian docker image variant, it won't have the manpages (or most locales, and apt will be stripped down, etc, etc). I think you can achieve the same thing on bare metal by being careful to tell it not to install a bunch of base package sets. Alpine is more container-focused than debian, so I imagine they default to something closer to `-slim`, but I haven't tried installing it on bare metal or in a VM.
robertlagrant 3y ago
> It’s (OpenRC) a breath of alpine air, and has legitimately made Linux fun again. I sort of understand this instinctively, but what actually makes it fun?
- klysm 3y ago
  People love applying arcane knowledge like writing shells scripts to do things. The hard and complex way is fun.
  - deleted 3y ago
    [deleted]
  - robertlagrant 3y ago
    Is that really it? I use systemd at work and still have plenty of scripts to write getting my Debian packages to configure themselves correctly :)
    - klysm 3y ago
      I think it’s definitely a contributing factor. Folks conflate simplicity with familiarity. It also just feels good to apply knowledge you worked hard to gain.
  - tarxvf 3y ago
    Wait, shell scripts are "arcane"?
    - Sharlin 3y ago
      They definitely are.
    - klysm 3y ago
      Absolutely. Anything like bash is not a good language IMO.
      - 3y ago
jayde2767 3y ago
Original Article: "was booting it on a VM at work, before realising I misread Dom0 as DomU...former refers to a Xen hypervisor, not a guest...it booted and installed the same as a standard ISO." For so many of us that would be an automatic fireable offense. I hope OP has the autonomy to do that and remain unscathed. *Edit: Reformatted
- Symbiote 3y ago
  Can you elaborate? I'm not familiar with Xen, and I don't see the connection to getting fired for making the 'wrong' VM.
  - crote 3y ago
    Running personal toy VMs on work servers is generally frowned upon.
    - tmottabr 3y ago
      it is not always frowned upon. It is a big NO in prod servers. But most companies have less critical or testing environments available where people have some more space to play with. And some teams like support, QA, Dev, etc usually have their own vm servers available to play with. Where i work support analysts even had their personal servers they could do whatever they wanted, within reason of course. They still have access to VMs at AWS that they can start and destroy at will, but now there is just a few base images to choose from.
- Sharlin 3y ago
  Not sure what that means either, but boy American firing culture sure is crazy.
  - msla 3y ago
    It certainly is if you're motivated to take random Internet comments seriously.
- 3y ago
itsmartapuntocm 3y ago
Slackware is the happy medium I've found between BSD and Linux. It's unashamedly unix-like and uncomplicated, and has its own rich ports tree through Slackbuilds.
- qzx_pierri 3y ago
  I respect anyone who uses Slackware, but the lack of dependency management seems tedious.
  - Bluecobra 3y ago
    I’ve used Slackware for years and slackpkg was pretty handy for this.
    - galangalalgol 3y ago
      It was my first linux, but I haven't used it in ages. I never found installing from source tgz to be that bad, but dep trees have gotten much deeper over time. I don't think windowmaker had clipboard support when I left it. There is something nice about knowing what every file in your system is for, and being able to read most of them with ed. Alpine scratches that itch for me. I try to sub in anything with a rust equivalent I can. Building rust may have deep trees, but with musl the only runtime dep is usually the kernel itself.
- DEADMINCE 3y ago
  Slackware lost it's way when it tried to comepte with desktop distros but didn't really commit to it. I used to like it as a minimal distro that just stayed out of my way and considered it oriented towards slightly more technical folk. Then the community would be hostile if you were digging in to an issue and didn't do a full install because that's the recommended way. And not doing so would also result in stupid issues due to stupid dependencies like mplayer not working because samba was not installed. Alpine is an improvement over Slackware in every way.
lucabs 3y ago
[dead]
trustno2 3y ago
Hah, Alpine Linux is actually not GNU/Linux! I didn't know that. It's .... Busybox/Linux?
- ssl-3 3y ago
  It's fine to just call it Alpine Linux, since (AFAIK) BusyBox isn't associated with the kind of self-aggrandizing assholery that sometimes leaks out of RMS.
  - DEADMINCE 3y ago
    RMS had a very strong point that GNU should have been getting some credit and was arguably more responsible for the 'linux' experience that linux itself is.
    - ssl-3 3y ago
      It's a weak argument that resembles bullying more than it does anything else. If that kind of crediting was necessary for something like the GNU project to be known and to thrive, then it should have been solved eons ago by including it as a requirement the terms of the GPL instead of by being indignantly recalcitrant about it later on.
      - DEADMINCE 3y ago
        It's not bullying to fight for deserved credit IMO.
cplli 3y ago
Alpine is a solid distro for servers from my experience. The only bad experiences I've had with it, come from the lack of parity between the x86_64 and aarch64 virt images. So our x86_64 setup doesn't work without building our own image with kernel params and addons. Even ZFS I don't think is built into the virt-aarch64 image. All in all, I would recommend more devs/sysadmins to try alpine outside the container world, and run it in test VMs, host servers, etc.
- hedora 3y ago
  I haven't had that experience with the aarch64 / x86_64 container images. It's good to know it gets a little wobbly in heterogeneous bare metal environments.
  - cplli 3y ago
    Yes, when using Alpine in a container context you're getting the "MINI ROOT FILESYSTEM" [1] experience; the parity differences are in the kernel (they're easily ""fixable"" and the team is open to enabling things that people actually use, I've opened such issues on their GitLab and they're very active and friendly) [1]: https://alpinelinux.org/downloads/ https://alpinelinux.org/downloads/
NelsonMinar 3y ago
Alpine is a joy. I use it as a very small and lightweight distro for various containers on my Proxmox server. I do wish there were a glibc-based Linux that had an emphasis on being small. Not as small as Alpine, of course, but something without systemd and snap and 100MB of files for locales I'll never use.
- bradfa 3y ago
  You can always build your own with a distro build system like OpenEmbedded, if you want to have ultimate control. But a minbase Debian install is reasonably small by today's standards. Doing this using the Debian installer is not as easy as doing it using a tool like debos if you're trying to build a disk image or file system tarball to make a container (then you don't need the kernel). A Debian bookworm minbase container (no kernel or locales, with ca-certificates, does have systemd) works out to about 71MB gzip compressed or 212MB uncompressed (about 78MB compressed and 235MB uncompressed if you add 1 locale). That's definitely not small but it is *reasonably* small in my book today.
  - NelsonMinar 3y ago
    oh interesting. The Debian you get using the Proxmox LXC template installs to 540MB. (Compare 10MB Alpine, 178MB OpenSUSE). But I don't think they put any effort into making it a small container. Getting down to 235MB is pretty good. (Hilariously, 4MB of Alpine's 10MB is libcrypto.)
    - bradfa 3y ago
      Busybox replaces a LOT of much larger apps if you’re ok with a much reduced feature set. That’s probably much of the savings.
- UncleSlacky 3y ago
  Maybe antiX?
geek_at 3y ago
Totally in love with Alpine Linux as well. I wrote a few guides how to use it, including making a minimal file server [1] or hoow to PXE boot Alpine Linux with NFS storage and even Desktop Environments [2] Also in my homelab I have a Docker Swarm system on multiple Lenovo Tiny nodes which all run Alpine Linux because it has much less overhead compared to Ubuntu or even Debian [1] https://blog.haschek.at/2020/the-perfect-file-server.html https://blog.haschek.at/2020/the-perfect-file-server.html [2] https://blog.haschek.at/2019/build-your-own-datacenter-with-pxe-and-alpine.html https://blog.haschek.at/2019/build-your-own-datacenter-with-...
- generalizations 3y ago
  ...your links don't seem to be workng.
  - geek_at 3y ago
    should work now, thanks
omani 3y ago
Alpine Linux is my daily driver on my workstation and laptop. All my machines look the same thanks to chezmoi. I think about switching to FreeBSD though, because of bhyve (vm-bhyve). Want to give it a try. Curious if it can replace my LXD environment.
- seabrookmx 3y ago
  As a happy LXD user, I'm curious what your draw is to bhyve? If you don't need the strict security boundary, Linux containers have drastically better memory management than any VMM I've played with.
  - omani 3y ago
    I heard that bhyve has GPU passthru support now. would be fun to have a rock solid freebsd base system and still be able to use my alpine linux environment within a VM (with X) if needed.
0xbadcafebee 3y ago
I use Alpine as my personal laptop OS. There's a lot of unfortunate things, like the fact that a package upgrade or install will often uninstall other packages which your system needs, and you spend half a day fixing it. Package/config backup and restore is a PITA and I still don't quite understand it. Getting a full GUI desktop set up is also a PITA and requires a lot of research and trial and error. Things like Bluetooth Audio seem unnecessarily buggy/difficult. And it takes a while to figure out what isn't going to work with libmusl, and the workarounds thereof. It's also pretty hard to try to contribute to the community. But overall, I prefer it to the more bloated modern distros. There's less complexity, it's snappier (I use an old laptop), and nothing gets shoved down your throat. Flatpak makes using 3rd party or bigger glibc apps a breeze. To get 1Password GUI to work using Docker took quite a bit of experimenting but it worked out in the end.
chrisweekly 3y ago
A couple days ago an HN commenter suggested that use of Alpine is by definition a supply-chain security problem: > "Alpine is not full-source-bootstrapped, often imports and trusts external binaries blindly, has no signed commits, no signed reviews, no signed packages, and is not reproducible. It is one phished git account away from a major supply chain attack any day now. Alpine chooses low security for low contribution friction. It is the Wikipedia of Linux distros, which granted it a huge package repository fantastic for experimental use and reference, but it is not something sane to blindly trust the latest packages of in production." I'd be grateful to hear other expert opinions.
- fullspectrumdev 3y ago
  Getting all those things right costs money to pay developers. Alpine aren’t exactly drowning in money, despite so much container shit being built off their backs.
- DEADMINCE 3y ago
  > Alpine is not full-source-bootstrapped, often imports and trusts external binaries blindly, has no signed commits, no signed reviews, no signed packages, and is not reproducible. Are Void or Chimera any better?
  - q66 3y ago
    the above is not entirely correct, alpine does have and always had signed packages in the other aspects most distros are generally not much or at all better, since all that stuff is hard and takes extra infrastructure in chimera we try to make source bootstrap possible and in general not rely on third party executables, but it's not always possible (e.g. some language toolchains were bootstrapped from official binaries originally) and we try to respect best practices for reproducibility (pretty sure alpine does too) but actually verifying it would need dedicated infra/resources, so we don't do it
jackbravo 3y ago
I remember there were some performance-related posts a while ago, about alpine running in docker, recommending people to use debian/ubuntu instead: Slow alpine posts: - https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/ - https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image https://superuser.com/questions/1219609/why-is-the-alpine-do... Pro alpine post: - https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine-as-a-base-docker-image https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine... I wonder if this still holds water.
- yjftsjthsd-h 3y ago
  At least a significant chunk of the specific complaints have been fixed. As your first link admits at the very bottom, Alpine-compatible wheels are a thing now, and the DNS thing was fixed a while back. But yes, it would be interesting to benchmark and get actual numbers on the perf side.
deleted 3y ago
[deleted]
CoolCold 3y ago
> dmesg(1) informs you you’re running OpenRC! ... > At the risk of embellishing my feelings about this, it is such a relief that there are Linux distros like Devuan, Gentoo, and Alpine using this. It’s a breath of alpine air, and has legitimately made Linux fun again. What kind of fun I'm missing by using systemd as init system? Couple examples of those who used it, would be interesting to see
ersoft 3y ago
I've been playing in my homelab in the past year with Illumos (OpenSolaris). After decades of using linux, everything is much simpler, all the linux constant changes are inexistent. Everything which was working in Solaris 10 (15-20y ago), still applies with small modifications today. Has support for zones, which in my opinion are 10 steps above docker containers, has builtin ZFS support for root/zones/etc and so on. Services are managed using SMF which has the only downside that services are configured using XML but usually if using only the builtin services it is not a problem. SmartOS also has a script to automatically configure the XML file. I'm running OmniOS on a couple servers having a few zones each and I also run a SmartOS server for VMs. Launching a VM is a lot easier than on Linux. I can switch between Bhyve and KVM and use a single JSON file to configure all the VM properties and then launch the VM using a single command: vmadm create -f file.json. All the networking is done using simple commands such as dladm and ipadm which are using the standard UNIX way.

280 points by Tomte 3y ago

I wonder what they would think of Chimera Linux: https://chimera-linux.org/ https://chimera-linux.org/

ggm 3y ago

I am also also a bsd person and also coincidentally ran my first alpine as a vm on bhyve this week. It's busybox. If you don't need explicitly discrete binaries of the /bin and /sbin utils it is a tiny user-space and fast to boot. Tmux, zsh and I was done for most unix purposes. To get to my endpoint I wound up doing a lot of apk installs (node. More node dependencies. Stuff) but overall I found it the best Linux experience I've had in a long time. I wish zfs was baked in, and more overt virtio bindings to things for bhyve zfs backed run.

chillfox 3y ago
ZFS works great with Alpine. Alpine + ZFS has been my default server setup for years.
AndrewDavis 3y ago
> zfs was baked in How baked in? I think Alpine is one of the few distros to ship a binary zfs kernel module. So it's just a quick apk command away from getting it. There's some pretty decent documentation to install zfs on root on the alpine wiki too https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_encryption https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
- ggm 3y ago
  Right, but the steps aren't scripted or integrated into the mainline. You're of the main path, albeit a damn sight simpler than some distros. Easy, but not 'simple'. Don't get me wrong, it's entirely doable. But it's a distinct, non-standard pattern. And virtio..
  - wkat4242 3y ago
    Yeah "apk add ZFS" is very scary and off the beaten path :) That's all you need to use ZFS data drives on alpine. On root is admittedly a lot more complex though.
    - ykonstant 3y ago
      Is it particularly helpful to use ZFS on root?
      - yjftsjthsd-h 3y ago
        I've actually used snapshots to roll back an upgrade that got messed up. Of course, Alpine is stable enough that it doesn't exactly come up a lot:)
      - Modified3019 3y ago
        ZFS on root (and setting up automatic snapshots) is great for rollbacks if a system update turned out bad, and also allows for being certain there’s no corruption after a power failure or a disk starts getting flaky. It also makes sending off snapshots for a backups a breeze. So it’s not really for day to day issues, it’s more for turning a rare “day of pain” into something much less.
        ssl-3 3y ago
        AFAIK, for events like unexpected power failure, ZFS is always consistent to the point of the last complete TxG. No snapshot required (and it wouldn't provide more-recent data, either) to deal with power failure-induced data corruption, because there isn't any. And also AFAIK, ZFS snapshots don't protect against data corruption from flaky disks: An online snapshot doesn't make a copy of anything. (That's more like what RAIDZ or copies=2 are for.) Snapshots do make great rollback methods, even for fixing dumb day-to-day mistakes. (I mean, I'm sure none of us have ever done something stupid with a computer, but it probably happens to someone sometimes.) And they are indeed easy to send elsewhere to be used as complete backups of a dataset's state at a single point in time. And there's other good stuff about daily use of ZFS root, too: Datasets. Like other filesystems, ZFS does occupy an entire disk (or a partition on that disk) -- in this case a "pool". But within that pool can be many, many datasets that are independent of one-another, just sharing space in the pool. One linux distro's root might occupy one dataset, and another more-experimental (or major breaking upgrade) distro's root might occupy another dataset. /home can be on a third dataset that both distros use. This is a very wonderful thing for those with limited hardware budgets -- gone are the days of resizing/paring down disk partitions just to try something different. (Datasets can also be copied or moved to different pools and those pools can be different sizes.) Or: Caching. Now that persistent l2arc is a thing, a snappy-feeling system can be built with big (redundant!) spinning disks, and a relatively small (fast!) SSD as a read cache. It's not really just for "day of pain" issues -- ZFS is pretty slick in all kinds of useful ways, as a root filesystem and elsewhere.
- vermaden 3y ago
  > How baked in? Like in FreeBSD - to be as available option in installer. In FreeBSD You just select 'Auto (ZFS)' - then select disk(s) on which it should happen - hit [ENTER] - and it happens. That level of integration I would expect ... and all that with ZFSBootMenu integration for ZFS Boot Environments.
dazzawazza 3y ago
I've used/deployed FreeBSD for over 20 years and I have to admit I dread connecting to a GNU/Linux box. It's just such a mess of a system with so many variations in inconsistencies. Even connecting to a Windows server makes more 'sense' to me. Anyway, I'm glad to hear that there might be a sane Linux distro out there. I will give it a go if I need a linux box which is pretty rare tbh.
- aeonik 3y ago
  Everyone who uses BSD says the same thing, but it's still unclear to me what you mean. What inconsistencies does Linux have that BSD does not? I've looked for an explanation, but I only get high level explanations, or specific features like jails. You wouldn't happen to have more information, would you?
  - kstrauser 3y ago
    My Debian server has a mix of systemd and /etc/init.d startup scripts. That’s the sort of thing where a BSD would be likely to say, ok, as of version N due in 3 months, we’re migrating everything and going from 100% old way to 100% new way.
    - cesarb 3y ago
      > My Debian server has a mix of systemd and /etc/init.d startup scripts. [...] ok, as of version N due in 3 months, we’re migrating everything and going from 100% old way to 100% new way. You'll be happy to know that this is going to happen. Quoting https://github.com/systemd/systemd/blob/v255/NEWS https://github.com/systemd/systemd/blob/v255/NEWS > Support for System V service scripts is now deprecated and will be removed in a future release. Please make sure to update your software now to include a native systemd unit file instead of a legacy System V script to retain compatibility with future systemd releases.
      - kstrauser 3y ago
        Eh, I don’t really care either way. The ones I really care about are in my shell history. I meant that more as an example of where the BSD way would be different. Since they manage all of the software together, it’s much easier for them to do wholesale migrations like that.

blueflow 3y ago

Alpine has come cool perk: When a Nix user is flexing about declarative package management, live-edit your /etc/apk/world and run `apk fix` to show them how to do it without Nix.

mbrock 3y ago
I can reinstall Alpine from scratch in around the time it takes Nix to evaluate my system flake
lambdaba 3y ago
That's cool but Nix/OS does much more than declarative package installs.
- intelVISA 3y ago
  my fave Nix feature is telling people I use it
  - MaKey 3y ago
    The new "I use Arch btw".
    - vaylian 3y ago
      I use the nix package manager on Arch btw
    - aodonnell2536 3y ago
      Arguably the original one, too.
  - cqqxo4zV46cp 3y ago
    If it were easier to use, it wouldn’t be as big a flex. So we can’t be having that!
    - orbat 3y ago

Faelian2 3y ago

Just my two cents about the security aspect. All Linux binaries are compiled with PIE nowadays. You can run `checksec` on any binaries on Ubuntu, and it will have those properties. (You can install checksec with `pip install pwntools`). On the other hand, GLIBC has, to my knowledge, the most hardened heap implementation out there. And there are more mitigations for double-free and other heap exploits on GLIBC. So in that regard, Alpine is less secure by using musl. Having a small, understandable system is a real advantage when it comes to security.

blueflow 3y ago
> Having a small, understandable system is a real advantage when it comes to security. How did that look like in your mind that it is a point for (and not against) glibc?
- balder1991 3y ago
  That got me confused too.
  - segfaultbuserr 3y ago
    It was pretty clear to me that the comment was a description of the respective characteristics of glibc and musl in terms of security, while avoiding any conclusion: glibc has heap hardening, which is good for security, but a complex codebase, which is bad for security. Meanwhile, musl is small and understandable, which is good for security, but with a naive codebase that lacks hardening, which is bad for security. Which is better is intentionally left to the reader to avoid flamewars.
    - lolinder 3y ago
      That's a charitable reading but it doesn't track with what they actually said. The first paragraph says that all modern Linux binaries are compiled with PIE, so Alpine has no advantage there. The second paragraph says that glibc is more secure than musl heap-wise. The third paragraph is the conclusion, which is that Alpine is less secure because it uses musl. A sentence thrown on to the end of the conclusion should normally be read as reemphasizing the reasons for the conclusion unless it starts with a word like "though" or "however".

_joel 3y ago

I found Alpine to be a lot slower than glibc based distros.

rany_ 3y ago
In terms of what? Boot times?
- frankjr 3y ago
  Musl's memory allocator is (was?) subpar compared to glibc's, especially in multi threading contexts. https://news.ycombinator.com/item?id=23080290 https://news.ycombinator.com/item?id=23080290
  - rwaksmunski 3y ago
    It's a bit better now, but still nowhere near FreeBSD's jemalloc.
- _joel 3y ago
  Usage, I converted a bunch of containers to it from debian-slim in our fairly large CI/CD setup and it processed workloads noticably slower, despite booting slightly quicker as it's a smaller pull. However, with network speeds nowadays, it was negligible difference and not worth it. Rolled it back to debian-slim.
  - cduzz 3y ago
    Would these performance concerns be an issue if you were using alpine "on the metal" and debian containers? When running complex applications I find it's simplest to "compile" the application into a container thus rendering some tedious complex runtime to a static binary that's trivial to run without worrying about tedious dependency management. It burns a bit of storage but that's not a big deal these days. If someone suggested to me "hey I want to run a big PHP / nginx / mysql workload for my startup; should I use alpine?" I'd suggest they find a doctor.

qweqwe14 3y ago

BSD users might also like Void Linux, which was developed by xtraeme (a NetBSD developer). It has glibc and musl versions and uses runit as an init system. You can also build packages from source using xbps-src. https://voidlinux.org/ https://voidlinux.org/

BSDobelix 3y ago
And CRUX, a granddaddy of Archlinux.
ykonstant 3y ago
I am loving Void; my main system is Arch because of the large package selection and systemd ergonomics, but I have installed Void on three boxes for relatives and myself, and it's been wonderful. Warning though: I have only used the xfce installation with minimal tweaks. Also, a complex multi-user setup with void might be a bit more tedious to setup because runit is less batteries-included than systemd.
- deleted 3y ago
  [deleted]
jackhalford 3y ago
I had issues with voidlinux+musl for using rust but that was a couple years back. Thankfully you can easily reinstall void with glibc
stock_toaster 3y ago
Maybe Chimera? Probably very friendly for BSD folks since it has a mostly FreeBSD set of core tools (userland).
- ethagnawl 3y ago
  This initially threw me but it appears to be distinct from ChimeraOS, which is described as a, "Steam Big Picture based couch gaming OS".

ilhuadjkv 3y ago

I've been disto hopping since, i guess the beginning (mid '90s). Have been on Alpine for around 18 months now and it's the first time i've EVER thought 'this is my forever distro'

maayank 3y ago
What did you especially like in it?
yard2010 3y ago
What other distros you went through and what were they like? When do you decide to move? Did you ever go back?
adamomada 3y ago
I’m curious if you tried out Void Linux and later switched to Alpine? I hear similar comments from void users

Arch-TK 3y ago

I honestly have no idea why people find OpenRC and such things appealing. Literally any supervision based option is better than leaking your PIDs, storing them in PID-files and hoping that the value in the PID file still refers to the daemon you ran after 3 weeks. To top it off, in some cases some service management tasks are handled by pgrepping for a specific process name. I can somewhat sympathise with the idea that not everything should be auto-restarted by default but that's literally the only thing these kinds of things have going for them. Also, inevitably these things heavily rely on syslog, which is the most 80s technology ever invented. I agree that multilog/svlogd/whatever could be improved to add an easy centralised view (when you need to know the sequence of events from multiple tools) but grouping logs by some vaguely defined category which you always get wrong, and letting anyone log anywhere with any name are such strange features.

traverseda 3y ago
Sure, but the main alternative is systemd which is architected in a way that just isn't secure, and opens it up to a whole bunch of new and exciting CVEs. There's just way too much going on in PID1, written in a memory unsafe language. I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. Aside from it making it possible to run systemd inside a docker container, which I presume redhat/IBM is strongly against, preferring you to use their in-house containerization tools like systemd-nspawn. It's just never going to be viable from a security point of view with how it's architected.
- blueflow 3y ago
  > I don't see a technical reason why it couldn't have a minimal PID1, and a few setuid programs. More detailed: Systemd conflates the init system (PID1) and service supervisor. And as a service supervisor, it isn't really that reliable.
- Arch-TK 3y ago
  There are literally at least 3 well designed and featureful alternatives to OpenRC which are not systemd: daemontools, runit, and s6-rc. There are also other lesser known options. For a real world in-situ use of runit, see voidlinux. It could be handled better but at this present moment it is at least no more clunky than using OpenRC.

philjohn 3y ago

Doesn't musl still not support pthread_attr_setaffinity_np, which means you can't run some software on it. PyTorch being the biggest.

cduzz 3y ago
I imagine if you've got some performance sensitive workload that relies on glibc for that performance you would "just" run that application in a container. For many situations, performance is a secondary concern relative to simplicity or security.

rjst01 3y ago

Huge Alpine fanboy myself. I love that a clean install has less than ten processes and I know what they all do. The community is also very good at building packages that "just work" - the article points out ZFS, but also docker, podman, libvirt are trivially installable. > Perhaps the package I was most surprised about was zfs. ... What that would look like after an upgrade I’d have to see, but thus far I’m impressed. I can confirm it works smoothly. I've observed that the ZFS package is updated whenever the kernel is updated.

vermaden 3y ago

Its all nice and small, etc. but its Apples to Oranges comparison. On FreeBSD You have ZFS with ZFS Boot Environments - which gives GREAT flexibility and protection against all kind od updates, changes and even accidental files deletion in the system. Moving to 'oldschool' LVM and EXT4 is just a huge downgrade. Especially without any advanced features such as compression or snapshots or clones or ... all the other wonders from ZFS. As from the busybox ... You can also use it on FreeBSD - its under 'sysutils/busybox' port ... and FreeBSD has 'kinda' itself busybox-like solution - its called FreeBSD Rescue System and its located at /rescue. It contains one executable file 17 MB in size (and ZFS lz4 makes that 11 MB) with hardlinks as commands - including all needed ZFS commands - which BusyBox obviously does not have. FreeBSD % % du -sm /rescue 11 /rescue FreeBSD % du -smA /rescue 17 /rescue FreeBSD % ls /rescue [ dhclient gbde kldstat mt rmdir umount bectl dhclient-script geom kldunload mv route unlink bsdlabel disklabel getfacl ldconfig nc routed unlzma bunzip2 dmesg glabel less newfs rrestore unxz bzcat dump gpart link newfs_msdos rtquery unzstd bzip2 dumpfs groups ln nextboot rtsol vi camcontrol dumpon gunzip ls nos-tun savecore whoami cat echo gzcat lzcat pgrep sed xz ccdconfig ed gzip lzma ping setfacl xzcat chflags ex halt md5 ping6 sh zcat chgrp expr head mdconfig pkill shutdown zdb chio fastboot hostname mdmfs poweroff sleep zfs chmod fasthalt id mkdir ps stty zpool chown fdisk ifconfig mknod pwd swapon zstd chroot fetch init more rcorder sync zstdcat clri fsck ipf mount rdump sysctl zstdmt cp fsck_4.2bsd iscsictl mount_cd9660 realpath tail csh fsck_ffs iscsid mount_msdosfs reboot tar date fsck_msdosfs kenv mount_nfs red tcsh dd fsck_ufs kill mount_nullfs rescue tee devfs fsdb kldconfig mount_udf restore test df fsirand kldload mount_unionfs rm tunefs The MUSL also limits some things - but that is topic for another discussion. ... and do not get me wrong - I like Alpine (same as Void or Gentoo or Devuan) - its just not the same thing. ... and its even possible to setup Alpine with root on ZFS - https://openzfs.github.io/openzfs-docs/Getting%20Started/Alpine%20Linux/Root%20on%20ZFS.html https://openzfs.github.io/openzfs-docs/Getting%20Started/Alp... - it will just take a quite large amount of work while on FreeBSD you just select 'Auto (ZFS)' installer option and hit enter. Hope that helps.

vermaden 3y ago

I also liked how the '[ok]' moved to the right after GPU drivers have been loaded :) - https://rubenerd.com/files/2024/alpine-openrc.png https://rubenerd.com/files/2024/alpine-openrc.png Of course its OpenRC related and not Alpine. IMHO it would looked more 'nice' if the '[ok]' stayed where they were - at least till 'login:' prompt - but I know that its just implemented in a way that 'write [ok] after space from right side of the screen' and as resolution increased - it happened what happened. They could just move the '[ ok ]' or '[fail]' to the left - beginning of the message - that would 'solve' that problem also.

Sharlin 3y ago
Technically, they could keep track of where each ok/fail was printed and erase and repaint them after the resolution change – if your terminal supports ANSI color it is essentially certain to support cursor movement commands too (inb4 someone counters that they have a color hardcopy terminal!) But I doubt anyone cares enough to implement that. I used to think these screenfuls of scrolling diagnostics were super cool and felt like a real hacker when I was 16 years old and first started playing with Linux, a feeling likely shared by many. These days I prefer a minimalistic boot, as long as the diagnostics are easily accessible when there’s a need to debug something. And in that case it doesn’t matter much ehether everything lines up neatly or not.

sebtron 3y ago

I was expecting some comment on the fact that man pages, a point of pride for the BSDs, are not included by default in Alpine. That's one of the reasons that kept me from using it on my travel laptop (now running OpenBSD). Alpine users, am I missing some configuration option to make sure all documentation is always installed when getting a package? Or is manually installing the -doc package every time the only way?

stock_toaster 3y ago
If you always want docs, you just install the `docs` meta package that will pull in any `*-doc` package for anything else you install.
- sebtron 3y ago
  Thanks, that's exactly what I needed!
- chupasaurus 3y ago
  It works similarly in i.e. Debian, so it's not really a quirk of Alpine.
  - oarsinsync 3y ago
    Can you elaborate on what you mean here? I’ve never seen a Debian install packages without docs in 20 years. What have I been doing right/wrong?
    - hedora 3y ago
      If you use a `-slim` debian docker image variant, it won't have the manpages (or most locales, and apt will be stripped down, etc, etc). I think you can achieve the same thing on bare metal by being careful to tell it not to install a bunch of base package sets. Alpine is more container-focused than debian, so I imagine they default to something closer to `-slim`, but I haven't tried installing it on bare metal or in a VM.

robertlagrant 3y ago

> It’s (OpenRC) a breath of alpine air, and has legitimately made Linux fun again. I sort of understand this instinctively, but what actually makes it fun?

klysm 3y ago
People love applying arcane knowledge like writing shells scripts to do things. The hard and complex way is fun.
- deleted 3y ago
  [deleted]
- robertlagrant 3y ago
  Is that really it? I use systemd at work and still have plenty of scripts to write getting my Debian packages to configure themselves correctly :)
  - klysm 3y ago
    I think it’s definitely a contributing factor. Folks conflate simplicity with familiarity. It also just feels good to apply knowledge you worked hard to gain.
- tarxvf 3y ago
  Wait, shell scripts are "arcane"?
  - Sharlin 3y ago
    They definitely are.
  - klysm 3y ago
    Absolutely. Anything like bash is not a good language IMO.
    - 3y ago

jayde2767 3y ago

Original Article: "was booting it on a VM at work, before realising I misread Dom0 as DomU...former refers to a Xen hypervisor, not a guest...it booted and installed the same as a standard ISO." For so many of us that would be an automatic fireable offense. I hope OP has the autonomy to do that and remain unscathed. *Edit: Reformatted

Symbiote 3y ago
Can you elaborate? I'm not familiar with Xen, and I don't see the connection to getting fired for making the 'wrong' VM.
- crote 3y ago
  Running personal toy VMs on work servers is generally frowned upon.
  - tmottabr 3y ago
    it is not always frowned upon. It is a big NO in prod servers. But most companies have less critical or testing environments available where people have some more space to play with. And some teams like support, QA, Dev, etc usually have their own vm servers available to play with. Where i work support analysts even had their personal servers they could do whatever they wanted, within reason of course. They still have access to VMs at AWS that they can start and destroy at will, but now there is just a few base images to choose from.
Sharlin 3y ago
Not sure what that means either, but boy American firing culture sure is crazy.
- msla 3y ago
  It certainly is if you're motivated to take random Internet comments seriously.
3y ago

itsmartapuntocm 3y ago

Slackware is the happy medium I've found between BSD and Linux. It's unashamedly unix-like and uncomplicated, and has its own rich ports tree through Slackbuilds.

qzx_pierri 3y ago
I respect anyone who uses Slackware, but the lack of dependency management seems tedious.
- Bluecobra 3y ago
  I’ve used Slackware for years and slackpkg was pretty handy for this.
  - galangalalgol 3y ago
    It was my first linux, but I haven't used it in ages. I never found installing from source tgz to be that bad, but dep trees have gotten much deeper over time. I don't think windowmaker had clipboard support when I left it. There is something nice about knowing what every file in your system is for, and being able to read most of them with ed. Alpine scratches that itch for me. I try to sub in anything with a rust equivalent I can. Building rust may have deep trees, but with musl the only runtime dep is usually the kernel itself.
DEADMINCE 3y ago
Slackware lost it's way when it tried to comepte with desktop distros but didn't really commit to it. I used to like it as a minimal distro that just stayed out of my way and considered it oriented towards slightly more technical folk. Then the community would be hostile if you were digging in to an issue and didn't do a full install because that's the recommended way. And not doing so would also result in stupid issues due to stupid dependencies like mplayer not working because samba was not installed. Alpine is an improvement over Slackware in every way.

lucabs 3y ago

[dead]

trustno2 3y ago

Hah, Alpine Linux is actually not GNU/Linux! I didn't know that. It's .... Busybox/Linux?

ssl-3 3y ago
It's fine to just call it Alpine Linux, since (AFAIK) BusyBox isn't associated with the kind of self-aggrandizing assholery that sometimes leaks out of RMS.
- DEADMINCE 3y ago
  RMS had a very strong point that GNU should have been getting some credit and was arguably more responsible for the 'linux' experience that linux itself is.
  - ssl-3 3y ago
    It's a weak argument that resembles bullying more than it does anything else. If that kind of crediting was necessary for something like the GNU project to be known and to thrive, then it should have been solved eons ago by including it as a requirement the terms of the GPL instead of by being indignantly recalcitrant about it later on.
    - DEADMINCE 3y ago
      It's not bullying to fight for deserved credit IMO.

cplli 3y ago

Alpine is a solid distro for servers from my experience. The only bad experiences I've had with it, come from the lack of parity between the x86_64 and aarch64 virt images. So our x86_64 setup doesn't work without building our own image with kernel params and addons. Even ZFS I don't think is built into the virt-aarch64 image. All in all, I would recommend more devs/sysadmins to try alpine outside the container world, and run it in test VMs, host servers, etc.

hedora 3y ago
I haven't had that experience with the aarch64 / x86_64 container images. It's good to know it gets a little wobbly in heterogeneous bare metal environments.
- cplli 3y ago
  Yes, when using Alpine in a container context you're getting the "MINI ROOT FILESYSTEM" [1] experience; the parity differences are in the kernel (they're easily ""fixable"" and the team is open to enabling things that people actually use, I've opened such issues on their GitLab and they're very active and friendly) [1]: https://alpinelinux.org/downloads/ https://alpinelinux.org/downloads/

NelsonMinar 3y ago

Alpine is a joy. I use it as a very small and lightweight distro for various containers on my Proxmox server. I do wish there were a glibc-based Linux that had an emphasis on being small. Not as small as Alpine, of course, but something without systemd and snap and 100MB of files for locales I'll never use.

bradfa 3y ago
You can always build your own with a distro build system like OpenEmbedded, if you want to have ultimate control. But a minbase Debian install is reasonably small by today's standards. Doing this using the Debian installer is not as easy as doing it using a tool like debos if you're trying to build a disk image or file system tarball to make a container (then you don't need the kernel). A Debian bookworm minbase container (no kernel or locales, with ca-certificates, does have systemd) works out to about 71MB gzip compressed or 212MB uncompressed (about 78MB compressed and 235MB uncompressed if you add 1 locale). That's definitely not small but it is *reasonably* small in my book today.
- NelsonMinar 3y ago
  oh interesting. The Debian you get using the Proxmox LXC template installs to 540MB. (Compare 10MB Alpine, 178MB OpenSUSE). But I don't think they put any effort into making it a small container. Getting down to 235MB is pretty good. (Hilariously, 4MB of Alpine's 10MB is libcrypto.)
  - bradfa 3y ago
    Busybox replaces a LOT of much larger apps if you’re ok with a much reduced feature set. That’s probably much of the savings.
UncleSlacky 3y ago
Maybe antiX?

geek_at 3y ago

Totally in love with Alpine Linux as well. I wrote a few guides how to use it, including making a minimal file server [1] or hoow to PXE boot Alpine Linux with NFS storage and even Desktop Environments [2] Also in my homelab I have a Docker Swarm system on multiple Lenovo Tiny nodes which all run Alpine Linux because it has much less overhead compared to Ubuntu or even Debian [1] https://blog.haschek.at/2020/the-perfect-file-server.html https://blog.haschek.at/2020/the-perfect-file-server.html [2] https://blog.haschek.at/2019/build-your-own-datacenter-with-pxe-and-alpine.html https://blog.haschek.at/2019/build-your-own-datacenter-with-...

generalizations 3y ago
...your links don't seem to be workng.
- geek_at 3y ago
  should work now, thanks

omani 3y ago

Alpine Linux is my daily driver on my workstation and laptop. All my machines look the same thanks to chezmoi. I think about switching to FreeBSD though, because of bhyve (vm-bhyve). Want to give it a try. Curious if it can replace my LXD environment.

seabrookmx 3y ago
As a happy LXD user, I'm curious what your draw is to bhyve? If you don't need the strict security boundary, Linux containers have drastically better memory management than any VMM I've played with.
- omani 3y ago
  I heard that bhyve has GPU passthru support now. would be fun to have a rock solid freebsd base system and still be able to use my alpine linux environment within a VM (with X) if needed.

0xbadcafebee 3y ago

I use Alpine as my personal laptop OS. There's a lot of unfortunate things, like the fact that a package upgrade or install will often uninstall other packages which your system needs, and you spend half a day fixing it. Package/config backup and restore is a PITA and I still don't quite understand it. Getting a full GUI desktop set up is also a PITA and requires a lot of research and trial and error. Things like Bluetooth Audio seem unnecessarily buggy/difficult. And it takes a while to figure out what isn't going to work with libmusl, and the workarounds thereof. It's also pretty hard to try to contribute to the community. But overall, I prefer it to the more bloated modern distros. There's less complexity, it's snappier (I use an old laptop), and nothing gets shoved down your throat. Flatpak makes using 3rd party or bigger glibc apps a breeze. To get 1Password GUI to work using Docker took quite a bit of experimenting but it worked out in the end.

chrisweekly 3y ago

A couple days ago an HN commenter suggested that use of Alpine is by definition a supply-chain security problem: > "Alpine is not full-source-bootstrapped, often imports and trusts external binaries blindly, has no signed commits, no signed reviews, no signed packages, and is not reproducible. It is one phished git account away from a major supply chain attack any day now. Alpine chooses low security for low contribution friction. It is the Wikipedia of Linux distros, which granted it a huge package repository fantastic for experimental use and reference, but it is not something sane to blindly trust the latest packages of in production." I'd be grateful to hear other expert opinions.

fullspectrumdev 3y ago
Getting all those things right costs money to pay developers. Alpine aren’t exactly drowning in money, despite so much container shit being built off their backs.
DEADMINCE 3y ago
> Alpine is not full-source-bootstrapped, often imports and trusts external binaries blindly, has no signed commits, no signed reviews, no signed packages, and is not reproducible. Are Void or Chimera any better?
- q66 3y ago
  the above is not entirely correct, alpine does have and always had signed packages in the other aspects most distros are generally not much or at all better, since all that stuff is hard and takes extra infrastructure in chimera we try to make source bootstrap possible and in general not rely on third party executables, but it's not always possible (e.g. some language toolchains were bootstrapped from official binaries originally) and we try to respect best practices for reproducibility (pretty sure alpine does too) but actually verifying it would need dedicated infra/resources, so we don't do it

jackbravo 3y ago

I remember there were some performance-related posts a while ago, about alpine running in docker, recommending people to use debian/ubuntu instead: Slow alpine posts: - https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/ - https://superuser.com/questions/1219609/why-is-the-alpine-docker-image-over-50-slower-than-the-ubuntu-image https://superuser.com/questions/1219609/why-is-the-alpine-do... Pro alpine post: - https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine-as-a-base-docker-image https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine... I wonder if this still holds water.

yjftsjthsd-h 3y ago
At least a significant chunk of the specific complaints have been fixed. As your first link admits at the very bottom, Alpine-compatible wheels are a thing now, and the DNS thing was fixed a while back. But yes, it would be interesting to benchmark and get actual numbers on the perf side.

deleted 3y ago

[deleted]

CoolCold 3y ago

> dmesg(1) informs you you’re running OpenRC! ... > At the risk of embellishing my feelings about this, it is such a relief that there are Linux distros like Devuan, Gentoo, and Alpine using this. It’s a breath of alpine air, and has legitimately made Linux fun again. What kind of fun I'm missing by using systemd as init system? Couple examples of those who used it, would be interesting to see

ersoft 3y ago

I've been playing in my homelab in the past year with Illumos (OpenSolaris). After decades of using linux, everything is much simpler, all the linux constant changes are inexistent. Everything which was working in Solaris 10 (15-20y ago), still applies with small modifications today. Has support for zones, which in my opinion are 10 steps above docker containers, has builtin ZFS support for root/zones/etc and so on. Services are managed using SMF which has the only downside that services are configured using XML but usually if using only the builtin services it is not a problem. SmartOS also has a script to automatically configure the XML file. I'm running OmniOS on a couple servers having a few zones each and I also run a SmartOS server for VMs. Launching a VM is a lot easier than on Linux. I can switch between Bhyve and KVM and use a single JSON file to configure all the VM properties and then launch the VM using a single command: vmadm create -f file.json. All the networking is done using simple commands such as dladm and ipadm which are using the standard UNIX way.