Alpine Plans with Systemd
-
- Offline
- 2 years 11 months ago
- 2015-04-19
Hello all,
I have been looking at an alternate linux distribution after some in-depth research on systemd. I'd like to know the future plans of Alpine Linux -- I've been using it for a couple of days and I really think Alpine Linux has potential as a cloud OS / server OS and perhaps even a desktop OS. But I don't want systemd , heh.
Personally, I'm a systems architect. My concerns with systemd are real ones. I consider it an exceedingly poor design. I do not trust team involved , neither in their competency or intent. https://bugs.freedesktop.org/show_bug.cgi?id=76935
I also have serious security concerns for introduction of new exploits and backdoors deep within the OS .
Particularly what irks me is the inclusion of cryptdisks (which I've been using ever since it was just loop-aes) ... There is no reason to 'roll' this into systemd but they are doing it anyway because of their dreams of One Linux... I have read a document containing obvious plans to integrate systemd "all the way down to the firmware" which I read as code for "TPM verified bootloaders". That sounds alot like what Tivo did.
Systemd Presentation on Future Plans
http://0pointer.de/public/gnomeasia2014.pdf
I read another article that indicated SystemD devs planned to eventually use QR codes and your Smartphone as Cryptographic HMACs to secure their binary replacement for syslog. I find it a risky endevour for the end users, a fantastic give-away to a few commercial companies,, and I'm surprised the non-profit distros have agreed to it at all.
Anyway, these arguments have been beaten to death. . . I only bring them up to indicate my personal motivations and concerns.. So here's my actual question...
I noticed Alpine Linux was not using systemd , and I've been playing with Alpine in a virtual machine , and I really like it. I think the ditching of glibc is really an innovation. I love the Open RC system. The apk package manager is fantastic -- on par with Debian. There are lots of innovations in Alpine. I think it has massive potential.
Before I go further with Alpine, and move from a VM to hardware, customizing and installing the OS for the long-haul (18+ months), I was curious as to the *plans* regarding Systemd from Alpine . I know that the PuppyLinux and other distros are refusing Systemd, Slackware probably will refuse it, and Gentoo has made it optional already.... and I think that's great.
Even Debian expats have already forked jessie and are well into removing all traces of the thing...
http://lkcl.net/reports/removing_systemd_from_debian/
http://devuan.org/
Does Alpine plan to follow in the footsteps of these other distros and refuse systemd (or at least make it optional like Gentoo), or are there plans to eventually migrate Alpine over to systemd? Or are do you guys currently have plans to phase over to systemd as a policy?
I'd just like to know what the plans are at Alpine, the general philosophy and so forth, so I can make a decision . I notice the document here lists your position as 'neutral' ... what does that mean in practise?
http://www.gabordemooij.com/escape_from_systemd
Feel free to avoid the political and technical aspects of this discussion if you wish. I really just need to know whether Alpine is moving towards systemd, away from it, or whether it's sort of up in the air.
Last point: Supposing everything works out, are you guys interested in ZFS on linux? I've been making some progress getting it working on Alpine (the LLNL kernel code, not FUSE).
Thanks
We have no plans to implement/switch to systemd, and will try preventing it will ever happen.
We already have zfs in aports: http://git.alpinelinux.org/cgit/aports/tree/testing/zfs-grsec/APKBUILD it seems it currently doesn't build on edge.
I have a zfs iso here: http://dev.alpinelinux.org/~clandmeter/alpine-zfs-grsec-150225-x86_64.iso (didnt test it though)
Okay, great. That's a relief to know there's options with Alpine for my servers . Plus the gr-sec is icing on the cake.. Alpine will make a fantastic server OS and embedded OS. It might make a nice desktop as well on Alpine -- haven't tried that quite yet.
I'm relieved to hear your thinking. My position has been that the only really 'fair' course of action in the grand scheme is to give users' a choice on what they'd like to do (init, sysv, busybox inittab, whatever).... So that's really great that you guys are thinking outside the box along with Gentoo .
And I'm gllad you guys got ZFS working... that's really useful I find..
I'm currently deep into some investigations regarding Alpine, Gentoo, the Debian Fork (Devuan I think) ... and a few others. Alpine I think is by far the best of these for server and embedded linux applications. What I'd like to find though is a nice desktop OS as an alternative.
Side note -- Does anyway have a link to the Alpine Linux build / bootstrapping process like LFS w a cross-compiler on an ISO? i want to see if I can get a minimalist Alpine linux install to convert over to be managed by Nix package manage (for the kernel as wel). Barring this, I'll settle for control of Alpine thru Fabric, or Ansbile.
Keep up the good work guys. Thanks for your time.
Thanks for your balanced and honest feedback... I'll be looking carefully at Alpine and Nix for Linux server orchestrations.
Okay, I've though about this carefully and I think Alpine fits right in with my plans for a server/cloud OS to replace ubuntu.. I think the following makes sense...
1. Ubuntu is out (as much as I love it) because it got way too bloated (i had to start remastering it by hand for cloud stuff), and it's too lopsided to desktop side.
2. Debian is up in the air until the dust settles on whether it's really getting forked or not .
3. Gentoo is awesome but not fast enough to customize for a quick deployment...
Alpine I thnk makes a great server OS... I think of it like CoreOS or SmartOS , but Alpine is more powerful because it has mature packages. I think the ultimate cloud /sever OS would be Alpine + APK , but with additional security and management features like web-of-trust PKI for cloud orchestration... More crypto and maybe even a functional package manager for container module deduplication, with LXC optionally. Just a thought .. not a serious proposal. I am serious tho about installing Alpine as a firewall appliance and NAS appliance once I get ZFS on it.
(1) I plan to completely migrate out of Ubuntu Server 14.04 LTS over the next 24 months in any case. Most likely to Alpine Linux for server / cloud related stuff... If not alpine it will be some sort of my own 'server Gentoo'... One nice feature as a server OS would be incremental snapshots of LXCs and Alpine's native speed combined with ZFS (ie. i can take a zfs snapshot of alpine, have it recreate an ISO installer or AMI image of the exact state...).... All the benefits of solaris with the headache.... Also the more I think, I really like the gr-sec patch.
My only concern really with Alpine for servers is that my minimal install I couldnt compile or create packages i needed by compiling against the other ulibc or whatever it was. I'm sure I can fix that tho.... Where things could really get interesting would be A minimalist / modular distro like Alpine combined with a Functional package manager called Nix (it's like half deban apt-get, and half gentoo portage)...
Especially if nix gets a nice wrapper layer like apt was for dpkg, apk for Alpine, etc etc.
(2) For desktop and 'general' use cases , I personally would like to combine Alpine's precise and organized and precise ethos with a bootstrapped kernel and setup where everything is a package... I''d like to see that with a functional / declarative package ... AND a config manager... Just as a though experiment anyway.. .. I'm vaguely considering if it's a good idea to (in theory anyway) combine Alpine-as-Desktop (or even a LFS image) with the package manager from Nix .. You guys should have a look at Nix and NixOS if you haven't seen it. It's great source o ideas. \
https://nixos.org
So I don't think NixOS can be a good server OS at the moment (it's very large ecosystem out fo the box)... And for desktops, you are basically defaulted to KDE on install. But I love the functional packaging idea coupled with crypto + both source and binary packages... I think that was part of the whole rationale behind systemd (and that sysvinit was too old)... but in reality we already have technology for some very advanced innovations by combining the minimall /modular distros with the functional package/config management.
I'm with you ;)
I'm just in the same transition, comming to AL from Debian.
I had a bunch of servers and VM but with AL I know have an orchestrated mini private cloud ^^
I just use KVM instead of Xen but I guess this is a minor architectural detail...
I still have some Debian or Windows boxes running in KVM but all the rest is moving to AL.
I do minimal install trough PXE. One can easyly build your own ISO with needed packages. Then it's easy to build an usb stick from that ISO. Or to put the needed files in the right place in the tftp server for PXE boot. Now you can have minimal install with custom packages.
With a local repository on the LAN, one can have any package wanted without ressorting to internet connection. Usefull for more complicated local setup (repo is a boot option).
With a layer of interconnected OpenVSwitches on all boxes, (and soon consul,) we export hdd from nodes as vda to a KVM exposing them as NBD.
This way, it takes about 10 sec to spin a nem generic KVM up from scratch. Add a couple of seconds to customize it (by the way of running a post.install script) and you are done ;) We are also able to manually spinup KVM with any ISO installer for custom install.
I'm thinkering with the idea of an orchestration tool like ansible, salt, puppet or chef for last couple of weeks. Ansible or salt are favorite in this category. But I still do not seen the point precisely... With such a tool, one still has to write a precise description of the installation workflow on a specific machine.wich is a combination of blocks like "install package; configure package; register package; start package". If you have different underlying OS, The tool is in charge of adding a layer to abstract that specific OS. Otherwise, a couple of shell script lines will do the job.
As we did standardize on AL, such a tool was not needed (yet?) and ash scripts are still sufficient.
This is still a work in progress and quite fun ;)
I like your Nix ideas but I think this need some more reflexion to integrate nicely with the AL way of doing thing which is quite different of the Debian way (for instance).
All that said, you can prepare needed apk is a dev machine and add those apk to your custom ISO.
To automate that workflow is easy.
For what it's worth, I've just about finished the complete transition from every other distro on every device to Alpine Linux, my last being replacing raspbian on raspberry pies. I even have AL on my desktop at work, and love it. I use AL as a Dom0 for xen to host all those other distros people want, as an office desktop, as a server OS on all sorts of bare matel, as an LXC guest for app deployment in mini containers (and LXC host for thinner other-distros deployment) and everywhere else I can think of, as and when required. I have no regrests in making the transition to AL. I think of it as the first building block of anything linuxy that I want to do. And the community is one of the nicest and most helpful i've come across.
As for systemd, I don't need to have an opinion any more, at it's not part of the Alpine Linux's future plans to integrate it.
Perhaps the only concern is dependancies between systemd and things like X11 in the future, but we can worry about those later.
Officially our opinion on systemd is that some of the ideas are interesting, but the general development direction and attitude is something we don't really want to deal with. Broken down the following observations can really be made:
systemd as init
Systemd's init services are really not the direction we want to go in with Alpine. In some ways, they are compelling, but most likely we will eventually jump off the OpenRC train onto something that fits our philosophical concept. What we really want to do is have a collection of services and configuration for those services, and have a system which manages and supervises these services (restarting them if they crash and so on). If you've ever used Solaris, the SMF framework is quite similar in concept to what we would consider ideal. Systemd is a lot different than that, while OpenRC is kind of close in some ways. Right now it's not really seen as a huge problem because OpenRC is acceptable for now. And of course, anything we replace OpenRC with we would want to maintain compatibility with legacy OpenRC scripts for some time -- with Systemd, we don't really know how that would play out. So Systemd as an init system is really not interesting to us for those reasons.
systemd's login components (logind, timedated, etc.)
Systemd also has these components that manage logins, multiseat, time, hostname, etc. These are mostly just to provide d-bus APIs, which are boring. A software package called systembsd provides a reasonable compatibility layer that we can use.
systemd-nspawn / systemd-importd
This is just something that is built ontop of namespaces like LXC, new openvz, docker, etc. There are already solutions both free and commercial for alpine which provide this same functionality. So this is really boring to us. We would rather just let those vendors provide choice to our users, because having choice in an ecosystem is something we consider to be a good thing...
systemd-networkd
Alpine's network configuration at the moment is one of the more fragile parts. We are interested in the idea of using a daemon to manage network configuration and lifecycle, as does systemd, but we are not interested in systemd-networkd itself. It is possible that a preview of this functionality may appear in 3.3.
In short, systemd has some interesting features, but the implementations are not really compelling. If we want a unilateral approach, we feel it would be better to provide it ourselves as the workflow for systemd is so much different than what is presented in Alpine thus far.
I'm glad to hear Alpine is avoiding systemd.
I've been using Debian/Ubuntu for years + both have been rock solid.
After the recent change over to systemd, both OSes have become very fragile.
https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1468804 is a good example, of reboots no longer working because mysql stops no longer work.
Besides being fragile, trying to debug systemd problems is difficult. I've yet to find a way to do this easily.
Thanks for committing to avoiding systemd!
Any suggestions on how to remedy or workaround this issue:
https://github.com/containers/build/issues/207
I am experiencing a similar break, but I am not using Vagrant. Is it the case that the cause is #3 posed in the issue opening report?
Unless I've misunderstood, without a workaround, the official position is that AL won't support building AL packages inside a rkt container?
@hedgehog
You do know this post is over 2 years old, right?
If you make your on post, I am sure someone would help you.
Have you tried asking on the irc chats?
i think, systemd is much better with MS windows os.
linux is about freedom, systemd is not an option in my book.