10 ms·

The Debian init system general resolution returns

66 points by mariuz 12y ago

Shish2k 12y ago
So the impression that I'm getting is that some people just want Jessie to be released, even if some packages only run correctly under systemd; others wish for debian to enforce "every package must run correctly under every init system" (excluding things like init-system management tools, which are clearly tied to their system). I wonder, how much difference does it make either way? What packages which only support systemd are we actually talking about, and how much work would it be to untie them?
- pantalaimon 12y ago
  > What packages which only support systemd are we actually talking about Gnome, Wayland, KDE > how much work would it be to untie them? a lot
  - KayEss 12y ago
    That sounds like a pain for my desktop, but implies there's still hope to use a simpler init on my servers so long as the coupling doesn't increase.
    - ultramancool 12y ago
      My advice: consider a move to FreeBSD on servers. I know it might seem drastic, but if you're looking for a simpler init system, they've probably got a closer philosophy to you anyways. That's what I've found at least, their rc system is dead simple, like Arch used to be before they started making changes to allow for systemd. I miss the day's of arch's rc.conf.
      - KayEss 12y ago
        I clearly need to learn a lot more about FreeBSD (and it's cousins) but unfortunately we're committed to Docker for server deployments.
    - efaref 12y ago
      Debian's sysvinit script wrappers were not in any way simple.
    - lucian1900 12y ago
      But servers is precisely where systemd is particularly useful. Having tools to interact with the init system and proper logging are invaluable.
      - edwintorok 12y ago
        Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).
        pessimizer 12y ago
        >Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.
        felixgallo 12y ago
        Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.
        EmanueleAina 12y ago
        I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise. Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
  - VLM 12y ago
    There is an architectural failure if your desktop environment depends deeply and inseperably (product tying) on how you spawn processes at boot. systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.
    - pantalaimon 12y ago
      systemd provides a lot more than spawning processes at boot. It aims to provide all essential operating system deamons and a common userspace interface for them.
      - vertex-four 12y ago
        Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Is it going to end up that if I want configurable logins (a la PAM), or to access a SMB file server, I need to use systemd as my init system, log management system, and whatever else?
        pessimizer 12y ago
        >Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Farther than that, I bet. It's pretty safe to assume that all of those things are already written on a few informal systemd roadmaps.
        Shish2k 12y ago
        I really hope that that's a joke that didn't translate well into text, as taking it literally, I would suggest seeing a doctor about that paranoia :S
        Xylakant 12y ago
        If at some point that is considered as "essential" as in "I can't boot a system without", then maybe. However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd. All that systemd does is offer a service. It seems to pay off for gnome and kde to rely on that.
  - edwintorok 12y ago
    I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work. That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again. The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too. So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect: * policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement * upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now. Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/ http://callfortesting.org/gnome3/
    - smosher_ 12y ago
      > I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. I'm having a similar experience with systemd. I had problems with USB storage (seems fixed now) and I'm still having problems with networking. DBus went haywire, not sure if it's in a sensible state yet or not. I haven't been using VPN connections or suspend. This isn't exactly a nightmare scenario. Most of the evident problems with systemd seem to be fixable. I can't say I'm impressed. I'm also having a hard time remembering why it was so important to move away from sysv init in the first place.
- edwintorok 12y ago
  IANADD, but actually I like this alternate proposal better: http://article.gmane.org/gmane.linux.debian.devel.vote/17248 http://article.gmane.org/gmane.linux.debian.devel.vote/17248 "Debian's standard requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit." I think that is a sensible requirement as upgrading from sysvinit-core to systemd-sysv was quite problematic (wouldn't boot if you had some entires in ftab, etc.), and some may want to stay on sysv at least for an initial reboot.
buster 12y ago
Not again... I think this was already decided.. Can we just move on? I've switched to systemd on my laptop months ago and had not a single problem. Boot times are noticably faster. Does Linux have to stay at software from the sixties forever? Can't we just move on to systemd and wayland and whatever fits better into the 21st century?! I really feel this is all too political and FUD after months and months of senseless complaining about systemd and particularly far too personal regarding Lennart Poettering. If people like SysV init so much there will always be alternatives but this shouldn't hinder the majority of users to move forward with systems that just work with systemd (e.g. Debian+Linux). Nobody really uses Debian/kFreeBSD anyway, for example. Yet, it's a common statement that is brought up.
- untothebreach 12y ago
  I would be thrilled if Debian gave users the choice of init systems. I switched to systemd a couple months ago as well, and had nothing _but_ problems. My laptop never turns off, so boot times are irrelevant to me, and I would like to have a linux system that actually allows me to listen to audio, obtain an IP address, etc. I would gladly switch back to Debian if I could swap systemd out for something else.
  - pantalaimon 12y ago
    systemd in Debian is still in testing, it's expected to be buggy at this point. Have you tried a distribution which already comes with systemd preconfigured, such as Fedora, Suse or CentOS?
    - untothebreach 12y ago
      Yea, I didn't actually try systemd on Debian because of the unstable-ness. I actually tried it on Fedora, and like I said, had nothing but trouble. Normally I would fight through it, file bug reports, etc, but the benefits of switching to systemd didn't seem to be worth it. When I see debates about systemd, I rarely see compelling technical reasons from _either_ side. The only technical reason I can see to move to systemd is improved boot times, which doesn't seem worth it when (like someone else in this thread mentioned) most of your systems are either always on, or suspended to disk. EDIT: I should probably also say, my desktop GUI setup is rather sparse. I usually run a debian server edition with SLiM & XMonad, which starts up ridiculously fast no matter which init system I am using. So, systemd seems a bit like overkill for my usecase.
vezzy-fnord 12y ago
From what I can tell, all this means is that Debian packagers will have to drop hard dependencies on components of systemd in many cases. I see nothing objectionable with this, as there have been some absolutely inane things going on at the packaging sphere. For example, treating the fact that upstream provides a systemd unit file as a dependency on systemd. To some extent, this can also be blamed on inherent weakness in most contemporary package managers that lack the ability to easily express multiple classes of dependencies, and treat everything as a hard one. That said, we still keep saying the same shoddy sentiments from systemd proponents. "Can't we just move on?" "systemd hasn't had any problems for me. Don't like it? Leave it!", "This must be Canonical.", so on and so forth. The /r/linux thread is a depressing clusterfuck of uninformed proponents, as always.
- _delirium 12y ago
  One thing that is not making the discussion clearer is that many people are failing to distinguish between two different kinds of dependencies. Depending on a systemd library versus depending on the systemd daemons running are quite different scenarios. It would be ideal for the latter to be minimized, but the former is not a problem at all. To take an analogy, plenty of Debian packages depend on libselinux1, because they feature optional selinux functionality, and not depending on libselinux1 would result in broken symbol tables. But most of these packages work perfectly fine without SELinux configured (as you might guess, since very few people actually have SELinux configured). Having libselinux1 on your system does not require you to use SELinux, and imo it would be unreasonable to complain that your system is now "infected" by SELinux because you can't uninstall libselinux1. It's just a library, like many others, and having it on your system doesn't impose policy requirements on you as administrator or user. Yet people are making exactly that argument with systemd, complaining that some systemd library or another is on their system and thereby "infecting" it. Rather than focusing on the more legitimate issue of which packages actually require systemd daemons to be configured/running.
  - digi_owl 12y ago
    Do systemd even have such a "inert" lib? Best i can tell everything happens via dbus (to be replaced with kdbus), and that again requires that systemd is running as pid 1 (as it will refuse to run as anything else, unless it is inside a namespace governed by another systemd as pid 1).
ausjke 12y ago
To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think. New changes are good or bad, let's give people more choices, the better one will eventually win, or they just co-exist, that's how the nature works, systemd is no different.
- Morgawr 12y ago
  >To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think. Oh, it's an amazing idea. So I assume you candidate to be a fulltime maintainer of the whole software stack and packages, right? Why don't we support OSS4 too, while we're at it! After all, support for everything is just free of man hours!
  - ausjke 12y ago
    How about merging all linux flavors into one so we have one system like MacOS? or Windows? hi they each have lots of different versions to maintain, what a waste of resources. systemd by all means is still new, how can you convince all of us that it is _the_ init system all of a sudden? It's good to have options, for each apps(email,web server,database,you name it) in Linux there are normally a few options too, why is systemd that different?
- acdha 12y ago
  How much are you willing to pay for those choices? Each init system doubles your testing load, which is already a concern, but more importantly it also means that there are features which are either need to be dropped or which will require time developing abstraction layers for multiple init systems. That might still be worth doing but this is a lot more than saying “Oh, if you don't like vim don't install it”. All of that will require time, effort and be a source of bugs / UI clunkiness which no other operating system has to deal with – I'd much prefer that people pick 1 system and spend time getting closer to the “it just works” level which OS X and Windows have been at for years rather than maintaining a stable of patches and extra code.
felixgallo 12y ago
The fundamental problem here is that desktop Linux users, who have absolutely had a bad experience over the decades, have gotten so tired of incompetently executed half-assed solutions that they now grab at any other solution with the fervor of a drowning victim. Why have they gotten to this point? Because the people working on desktop have generally been the D-team. The A-team is working on kernels and infrastructure, the B-team turns out packaging, and the D-team has been coming up with hair-raising stuff like gnome, 'desktop bus', pulseaudio, enlightenment. So this weird little monoculture has emerged in which no other concern matters except that they get rescued from drowning -- that their boot times (!?!?) go to 5 seconds from 10, that hot-plugging USB drives (!?!?!?!) be wrapped in with the init system if it helps at all, that DHCP (!!??!?!?!?!!) and core files (!!!!!!!!) and all logging (!!!!?!?!?!?!?!?!) be taken over in the name of helping even 1% on the core experience. But at the same time, two basic axioms of reality still bear: 1. Linux on the desktop is irrelevant and will never win, both in terms of the Linux story and in absolute terms; and every scrap of effort that goes into it has been objectively wasted for two decades and will continue to be wasted. 2. Linux everywhere else has been working fine for longer than most of the desktop people have been alive. following from (2), the people who run servers recognize that although systemd has some good ideas, it forcibly bundles together a grip of super bad ones too, and is clearly implemented by people who don't understand systems outside of the desktop. The attempt to turn Debian back into a distribution for everyone, rather than a small collection of desktop people, is completely valid and sensible. That said, it's totally clear why the desktop people want it this way, and why they have such a misguided emotional investment in their terrible new windows emulator.
- pyre 12y ago
  > pulseaudio To be fair, some of the ideas behind pulseaudio are good: - Unify all of the different audio systems that existed: OSS, ALSA, esound daemon, etc... - Network accessible sound. Years ago I was able to setup pulseaudio to stream audio from my HTPC to my laptop where I had headphones plugged in. The process to do this wasn't entirely user-friendly, but prior to pulseaudio, people would setup yet another audio subsytem that every app would then need to support on a case-by-case basis.
- EmanueleAina 12y ago
sandGorgon 12y ago
Systemd has been trying to drag desktop linux into a world that is as seamless as OSX and it is so sad that most people blast it as "not the linux way". And even sadder that people type this on Macbooks. The truth is that the West has moved on from Linux - Apple has won. Linux is most relevant in Asia, where we want to run it on cheap, locally assembled desktops. SystemD is bringing so much to improve the state of desktop linux - it is enabling fundamental security like XWindows-without-root[1], service dependency management ,etc. there is a lot of fud around binary logs (which incidentally are append only and have a grep like interface built around it) and hard dependencies on systemd for any cgroup access. The second is actually kernel mandated - all cgroups have to have a single arbitrator for external applications. Direct access to cgroups will be dropped in the future. AFAIK, as on today systemd is the ONLY arbitrator that complies with the kernel-dev requirements. I'm keen to see where desktop Linux can go to - I believe that it is going to be transformative for India. I strongly believe desktop Linux initiatives like SystemD and Mir/Wayland is going to take us there That said, if you have worked with Docker - I find myself wishing very frequently for SystemD as pid 1. Right now I use supervisord as PID 1 (for a multiprocess container) and it is definitely more difficult to use than SystemD. Plus the ease of imposing resource limits (using systemd.resource-control) is simply unparalleled [1] http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
- Zardoz84 12y ago
  Have you any information about that with systemd, updates of some software that run as service on the machine, would need now to reset the machine ?? For my, it is the only big issue that I see for my personal usage.
  - sandGorgon 12y ago
    Actually, that is another systemd FUD. SystemD enables stateless systems - now that I think of it, very similar to Docker - by clearing out the /var and /etc directories. Which means that when you reboot the system, it acts as a system reset. This is actually, pretty hard to actually implement and systemd is trying really hard to do this. Imagine being able to build your own private DigitalOcean and able to have pristine machines for a new fleet deployment (possibly even avoiding the stale confidential data issues plaguing DigitalOcean). http://0pointer.net/blog/projects/stateless.html http://0pointer.net/blog/projects/stateless.html

66 points by mariuz 12y ago

So the impression that I'm getting is that some people just want Jessie to be released, even if some packages only run correctly under systemd; others wish for debian to enforce "every package must run correctly under every init system" (excluding things like init-system management tools, which are clearly tied to their system). I wonder, how much difference does it make either way? What packages which only support systemd are we actually talking about, and how much work would it be to untie them?

pantalaimon 12y ago
> What packages which only support systemd are we actually talking about Gnome, Wayland, KDE > how much work would it be to untie them? a lot
- KayEss 12y ago
  That sounds like a pain for my desktop, but implies there's still hope to use a simpler init on my servers so long as the coupling doesn't increase.
  - ultramancool 12y ago
    My advice: consider a move to FreeBSD on servers. I know it might seem drastic, but if you're looking for a simpler init system, they've probably got a closer philosophy to you anyways. That's what I've found at least, their rc system is dead simple, like Arch used to be before they started making changes to allow for systemd. I miss the day's of arch's rc.conf.
    - KayEss 12y ago
      I clearly need to learn a lot more about FreeBSD (and it's cousins) but unfortunately we're committed to Docker for server deployments.
  - efaref 12y ago
    Debian's sysvinit script wrappers were not in any way simple.
  - lucian1900 12y ago
    But servers is precisely where systemd is particularly useful. Having tools to interact with the init system and proper logging are invaluable.
    - edwintorok 12y ago
      Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. Sure there is some additional information that systemd stores in logs that syslog wouldn't, but implementing that could've been done while keeping the main log text-only (eg: have an id for each logline in your human-readable text logs, and have the binary/index etc separate that refer to that id).
      - pessimizer 12y ago
        >Some may disagree that binary logs or putting coredumps into your journal are the "proper" way to handle logging. No need to be quite so weaselly: 'Many disagree...' is something I'm pretty sure you could provide references for if pressed.
        felixgallo 12y ago
        Hi, I've run infrastructure and software projects involving thousands of machines for companies with over a trillion dollars in asset under management. Binary logs and putting coredumps in your journal are stupid and anyone who does that doesn't understand the first thing about running systems.
        EmanueleAina 12y ago
        I'm not a professional sysadmin (at least not at your level) seriously curious why a binary log is so bad. I guess in big deployment logs are collected to a central location, so I don't understand the "corruption" issue many people usually raise. Also, what's so bad about coredumps? You can disable storing them in the journal, discarding them or saving them in a separate location (which is the default). Where coredumps are rare (which I guess it's the case in most of the deployments) it seem nice having a clean, standardized way to manage them.
- VLM 12y ago
  There is an architectural failure if your desktop environment depends deeply and inseperably (product tying) on how you spawn processes at boot. systemd may or may not suck and I'm not discussing that aspect in this post. What definitely horribly sucks is product tying a desktop environment (you know, cut and paste, drag and drop, background images, window animations) deeply in with the earliest intricacies of the boot process.
  - pantalaimon 12y ago
    systemd provides a lot more than spawning processes at boot. It aims to provide all essential operating system deamons and a common userspace interface for them.
    - vertex-four 12y ago
      Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Is it going to end up that if I want configurable logins (a la PAM), or to access a SMB file server, I need to use systemd as my init system, log management system, and whatever else?
      - pessimizer 12y ago
        >Is systemd eventually going to contain Wayland, then? SSHd? PAM? Samba? How far does this go? Farther than that, I bet. It's pretty safe to assume that all of those things are already written on a few informal systemd roadmaps.
        Shish2k 12y ago
        I really hope that that's a joke that didn't translate well into text, as taking it literally, I would suggest seeing a doctor about that paranoia :S
      - Xylakant 12y ago
        If at some point that is considered as "essential" as in "I can't boot a system without", then maybe. However, there's a way to avoid that path: Write a better init system than systemd. Or contribute the extra effort to make sshd, pam, samba, wayland, gnome, kde work without systemd. All that systemd does is offer a service. It seems to pay off for gnome and kde to rely on that.
- edwintorok 12y ago
  I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. For example policykit was broken and things like mounting USB devices or managing VPN connections didn't work. That is finally fixed and with latest cgmanager from unstable, and policykit-1 from experimental those things work again. The only noticable loss compared to systemd is the lack of 'Suspend/Hibernate' in the KDE menu, but you can still use 'pm-suspend' from the cmdline, or even with 'qdbus' and the systemd specific dbus API, so in the end this should be fixable too. So I wouldn't put KDE into the same bucket as Gnome, its dependencies on systemd seem to be mostly indirect: * policykit, which started to depend on systemd-logind instead of consolekit. Works with cgmanager+systemd-shim as replacement * upowerd doesn't support suspend/hibernate anymore but apparently, so apparently systemd specific dbus methods have to be used now. Also Gnome3 works under OpenBSD (with consolekit?), and there is definitely no systemd there, although it might not be the latest version: http://callfortesting.org/gnome3/ http://callfortesting.org/gnome3/
  - smosher_ 12y ago
    > I am running Debian unstable with sysvinit-core and KDE, and while the loss of functionality was quite visible the situation is slowly getting back to normal. I'm having a similar experience with systemd. I had problems with USB storage (seems fixed now) and I'm still having problems with networking. DBus went haywire, not sure if it's in a sensible state yet or not. I haven't been using VPN connections or suspend. This isn't exactly a nightmare scenario. Most of the evident problems with systemd seem to be fixable. I can't say I'm impressed. I'm also having a hard time remembering why it was so important to move away from sysv init in the first place.
edwintorok 12y ago
IANADD, but actually I like this alternate proposal better: http://article.gmane.org/gmane.linux.debian.devel.vote/17248 http://article.gmane.org/gmane.linux.debian.devel.vote/17248 "Debian's standard requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit." I think that is a sensible requirement as upgrading from sysvinit-core to systemd-sysv was quite problematic (wouldn't boot if you had some entires in ftab, etc.), and some may want to stay on sysv at least for an initial reboot.

buster 12y ago

Not again... I think this was already decided.. Can we just move on? I've switched to systemd on my laptop months ago and had not a single problem. Boot times are noticably faster. Does Linux have to stay at software from the sixties forever? Can't we just move on to systemd and wayland and whatever fits better into the 21st century?! I really feel this is all too political and FUD after months and months of senseless complaining about systemd and particularly far too personal regarding Lennart Poettering. If people like SysV init so much there will always be alternatives but this shouldn't hinder the majority of users to move forward with systems that just work with systemd (e.g. Debian+Linux). Nobody really uses Debian/kFreeBSD anyway, for example. Yet, it's a common statement that is brought up.

untothebreach 12y ago
I would be thrilled if Debian gave users the choice of init systems. I switched to systemd a couple months ago as well, and had nothing _but_ problems. My laptop never turns off, so boot times are irrelevant to me, and I would like to have a linux system that actually allows me to listen to audio, obtain an IP address, etc. I would gladly switch back to Debian if I could swap systemd out for something else.
- pantalaimon 12y ago
  systemd in Debian is still in testing, it's expected to be buggy at this point. Have you tried a distribution which already comes with systemd preconfigured, such as Fedora, Suse or CentOS?
  - untothebreach 12y ago
    Yea, I didn't actually try systemd on Debian because of the unstable-ness. I actually tried it on Fedora, and like I said, had nothing but trouble. Normally I would fight through it, file bug reports, etc, but the benefits of switching to systemd didn't seem to be worth it. When I see debates about systemd, I rarely see compelling technical reasons from _either_ side. The only technical reason I can see to move to systemd is improved boot times, which doesn't seem worth it when (like someone else in this thread mentioned) most of your systems are either always on, or suspended to disk. EDIT: I should probably also say, my desktop GUI setup is rather sparse. I usually run a debian server edition with SLiM & XMonad, which starts up ridiculously fast no matter which init system I am using. So, systemd seems a bit like overkill for my usecase.

vezzy-fnord 12y ago

From what I can tell, all this means is that Debian packagers will have to drop hard dependencies on components of systemd in many cases. I see nothing objectionable with this, as there have been some absolutely inane things going on at the packaging sphere. For example, treating the fact that upstream provides a systemd unit file as a dependency on systemd. To some extent, this can also be blamed on inherent weakness in most contemporary package managers that lack the ability to easily express multiple classes of dependencies, and treat everything as a hard one. That said, we still keep saying the same shoddy sentiments from systemd proponents. "Can't we just move on?" "systemd hasn't had any problems for me. Don't like it? Leave it!", "This must be Canonical.", so on and so forth. The /r/linux thread is a depressing clusterfuck of uninformed proponents, as always.

_delirium 12y ago
One thing that is not making the discussion clearer is that many people are failing to distinguish between two different kinds of dependencies. Depending on a systemd library versus depending on the systemd daemons running are quite different scenarios. It would be ideal for the latter to be minimized, but the former is not a problem at all. To take an analogy, plenty of Debian packages depend on libselinux1, because they feature optional selinux functionality, and not depending on libselinux1 would result in broken symbol tables. But most of these packages work perfectly fine without SELinux configured (as you might guess, since very few people actually have SELinux configured). Having libselinux1 on your system does not require you to use SELinux, and imo it would be unreasonable to complain that your system is now "infected" by SELinux because you can't uninstall libselinux1. It's just a library, like many others, and having it on your system doesn't impose policy requirements on you as administrator or user. Yet people are making exactly that argument with systemd, complaining that some systemd library or another is on their system and thereby "infecting" it. Rather than focusing on the more legitimate issue of which packages actually require systemd daemons to be configured/running.
- digi_owl 12y ago
  Do systemd even have such a "inert" lib? Best i can tell everything happens via dbus (to be replaced with kdbus), and that again requires that systemd is running as pid 1 (as it will refuse to run as anything else, unless it is inside a namespace governed by another systemd as pid 1).

ausjke 12y ago

To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think. New changes are good or bad, let's give people more choices, the better one will eventually win, or they just co-exist, that's how the nature works, systemd is no different.

Morgawr 12y ago
>To make Debian init-neutral is a great idea in my opinion, just like Linux distro we have many flavors, there is no real reason for mandating systemd to be the sole init system I think. Oh, it's an amazing idea. So I assume you candidate to be a fulltime maintainer of the whole software stack and packages, right? Why don't we support OSS4 too, while we're at it! After all, support for everything is just free of man hours!
- ausjke 12y ago
  How about merging all linux flavors into one so we have one system like MacOS? or Windows? hi they each have lots of different versions to maintain, what a waste of resources. systemd by all means is still new, how can you convince all of us that it is _the_ init system all of a sudden? It's good to have options, for each apps(email,web server,database,you name it) in Linux there are normally a few options too, why is systemd that different?
acdha 12y ago
How much are you willing to pay for those choices? Each init system doubles your testing load, which is already a concern, but more importantly it also means that there are features which are either need to be dropped or which will require time developing abstraction layers for multiple init systems. That might still be worth doing but this is a lot more than saying “Oh, if you don't like vim don't install it”. All of that will require time, effort and be a source of bugs / UI clunkiness which no other operating system has to deal with – I'd much prefer that people pick 1 system and spend time getting closer to the “it just works” level which OS X and Windows have been at for years rather than maintaining a stable of patches and extra code.

felixgallo 12y ago

The fundamental problem here is that desktop Linux users, who have absolutely had a bad experience over the decades, have gotten so tired of incompetently executed half-assed solutions that they now grab at any other solution with the fervor of a drowning victim. Why have they gotten to this point? Because the people working on desktop have generally been the D-team. The A-team is working on kernels and infrastructure, the B-team turns out packaging, and the D-team has been coming up with hair-raising stuff like gnome, 'desktop bus', pulseaudio, enlightenment. So this weird little monoculture has emerged in which no other concern matters except that they get rescued from drowning -- that their boot times (!?!?) go to 5 seconds from 10, that hot-plugging USB drives (!?!?!?!) be wrapped in with the init system if it helps at all, that DHCP (!!??!?!?!?!!) and core files (!!!!!!!!) and all logging (!!!!?!?!?!?!?!?!) be taken over in the name of helping even 1% on the core experience. But at the same time, two basic axioms of reality still bear: 1. Linux on the desktop is irrelevant and will never win, both in terms of the Linux story and in absolute terms; and every scrap of effort that goes into it has been objectively wasted for two decades and will continue to be wasted. 2. Linux everywhere else has been working fine for longer than most of the desktop people have been alive. following from (2), the people who run servers recognize that although systemd has some good ideas, it forcibly bundles together a grip of super bad ones too, and is clearly implemented by people who don't understand systems outside of the desktop. The attempt to turn Debian back into a distribution for everyone, rather than a small collection of desktop people, is completely valid and sensible. That said, it's totally clear why the desktop people want it this way, and why they have such a misguided emotional investment in their terrible new windows emulator.

pyre 12y ago
> pulseaudio To be fair, some of the ideas behind pulseaudio are good: - Unify all of the different audio systems that existed: OSS, ALSA, esound daemon, etc... - Network accessible sound. Years ago I was able to setup pulseaudio to stream audio from my HTPC to my laptop where I had headphones plugged in. The process to do this wasn't entirely user-friendly, but prior to pulseaudio, people would setup yet another audio subsytem that every app would then need to support on a case-by-case basis.
EmanueleAina 12y ago

sandGorgon 12y ago

Systemd has been trying to drag desktop linux into a world that is as seamless as OSX and it is so sad that most people blast it as "not the linux way". And even sadder that people type this on Macbooks. The truth is that the West has moved on from Linux - Apple has won. Linux is most relevant in Asia, where we want to run it on cheap, locally assembled desktops. SystemD is bringing so much to improve the state of desktop linux - it is enabling fundamental security like XWindows-without-root[1], service dependency management ,etc. there is a lot of fud around binary logs (which incidentally are append only and have a grep like interface built around it) and hard dependencies on systemd for any cgroup access. The second is actually kernel mandated - all cgroups have to have a single arbitrator for external applications. Direct access to cgroups will be dropped in the future. AFAIK, as on today systemd is the ONLY arbitrator that complies with the kernel-dev requirements. I'm keen to see where desktop Linux can go to - I believe that it is going to be transformative for India. I strongly believe desktop Linux initiatives like SystemD and Mir/Wayland is going to take us there That said, if you have worked with Docker - I find myself wishing very frequently for SystemD as pid 1. Right now I use supervisord as PID 1 (for a multiprocess container) and it is definitely more difficult to use than SystemD. Plus the ease of imposing resource limits (using systemd.resource-control) is simply unparalleled [1] http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights

Zardoz84 12y ago
Have you any information about that with systemd, updates of some software that run as service on the machine, would need now to reset the machine ?? For my, it is the only big issue that I see for my personal usage.
- sandGorgon 12y ago
  Actually, that is another systemd FUD. SystemD enables stateless systems - now that I think of it, very similar to Docker - by clearing out the /var and /etc directories. Which means that when you reboot the system, it acts as a system reset. This is actually, pretty hard to actually implement and systemd is trying really hard to do this. Imagine being able to build your own private DigitalOcean and able to have pristine machines for a new fleet deployment (possibly even avoiding the stale confidential data issues plaguing DigitalOcean). http://0pointer.net/blog/projects/stateless.html http://0pointer.net/blog/projects/stateless.html