As an aside since your comment seems reasonable. The main reason for binary logs is that systemd logs have machine readable features. For example the daemon can be asked questions about what happened and read the logs. They also are indexed. The indexing allows for much larger numbers of messages to be useful.
Does SystemD eliminate POSIX? It would be a shame. A lot of people worked hard for POSIX, and I think POSIX does have a purpose.
The purpose of POSIX was to support a standard for application design at a time when there was a huge variety of Unixes written by competing vendors. It was a key part of the open systems movement. Today
a) There aren't a huge variety of Unixes. Linux killed most of them and most of the remaining ones are niche. b) POSIX is massively outdated.
What is needed is a way to run across multiple IaaSes which is the meaningful equivalent. Which is the PaaS movement. Systemd is a key component of making that happen by creating cross platform process low level process management. So arguably it advances the goals of POSIX updates for the 2010s.
Maybe someone can explain why it writes binary logs? On modern systems, a text file can be opened and read as fast as can a binary file (or so I read somewhere). So why obfuscate log files?
Because the log files aren't designed to be primarily read by humans but rather by other systems. Moreover the systemd log format has indexing so the logs can answer questions about their state or activities. Human readers reading the entire log are a secondary use case, supported but likely not well going forward.
It has many components, but no alternatives to any of them.
Actually no. Every component I know has alternatives in use in large production systems.
It encrypts (writes binary) logs and offers only itself as a way to read them.
No there are already multiple libraries which understand the binary format and several editors making use of those libraries to read the binary format.
How long can (Open)BSD and Slackware hold out against this perversity?
OpenBSD forever. Slackware a few more years.
But don't worry it is a bad fit for some embedded use cases. So there will be embedded distributions that don't use systemd and it will be easy to extend those to create a "traditionalist Linux" distribution.
Feature-creep is the real problem. For the cost of slightly faster bootup, I lose an awful lot of old functionality that's been around forever, for no reasonable reason.
Forgot about bootup times. Address the real issue. Full featured process management. That's a major shift. A complete replacement of the userspace plumbing with something much more feature rich, and thus much more complex. This isn't feature creep it is the natural evolution of a central system management daemon.
Make SysVInit cgroup-aware and things could be an awful lot nicer.
That's OpenRC which the anti-systemd people didn't work to support either.
But the only people who care about that are the programmers and geeks, not the "so long as it just works" desktop users (of which Linux apparently has a surprising amount nowadays).
The programmers, developers love the systemd features. That's where the dependencies are coming from. They are thrilled to be able to be able to depend on complex runtime dependencies the way the Linux package management system let's them depend on complex chains of library dependencies. The opposition is a small group of administrators who like traditionalist administration.
If you want to run without systemd you have to map all those dependencies back into run levels for sysv init to run. I'm not really sure what you're asking for because it simply isn't reasonable to pick your own init system, any more than you pick a package management system.
It is reasonable for a distribution. Systemd will be a bad choice for many types of embedded distributions and Linux is big on embedded. So there will be non-systemd distributions. It won't be hard to fork those to create a "traditionalist Linux". So yes I think it will exist. It wouldn't shock me if some are child distributions of Debian.
That being said, initd shouldn't be the default for mainstream distributions like Debian. So what's happening is the right thing.
but the fact is that Unix has worked for a very, very long time.
Z-OS has worked for an even longer time and that has always had complex process management.
An uncompelling value proposition. I don't much care about boot time If I'm running a server, I don't even care about boot time at all.
boot time is just one of many advantages. Process management does matter for server.
What I do care about is simplicity of understanding and management.
The direction is server administration is the exact opposite. Extremely complex systems which offer a rich set of services to developers and and administrators. Your view of what is valuable is the minority view because of its proven costs especially in the area of pushing the complexity into deployment complexity.
Poor architecture.... Discrete components that are loosely-coupled
You do understand there is a difference between someone disagreeing with you and someone being ignorant. For example you run the Linux kernel which is monolithic and tightly coupled rather than a kernel like QNX's which meets your criteria. Why?
Lack of concern for the server use case, and sysadmins in particular
The major server vendors and distributions are all in favor of it. OpenShift, Cloud Foundry, Heroku, Helion... are not exactly ignorant about the server use case.
Here's a hint: when a group of competent professional acting in good faith doesn't understand why something is a good idea, it's your fault for having explained it poorly.
OK and how does that not apply to the anti-systemd people who have failed to explained why initd's lack of process management is a good idea?
Why my window manager or graphics program has to depend on init, I don't know.
Because it isn't an init system. It is a process management system. initialization is just one of the states it manages.
People voice concerns about systemd, and if they seem recycled it's because they haven't been well refuted!
Of course they have been refuted. It is being used in production in some of the largest most complex systems out there.
I've seen systemd opponents attacking technical, philosophical, and architectural choices
Bullshit. They are attacking fantasy by quoting propaganda. The Linux community generally called that FUD when it was applied on other issues.
while systemd proponents are attacking their intended users.
No they aren't. Their intended users on the server side are the admins who control hundreds to tens of thousands of servers. The opposition is coming from system admins who generally administer a 1/2 dozen boxes. And I will tell you as someone who strongly supports systemd's direction, for server, I get attacked personally all the time by anti-systemd people.
the most universally relevant reason being that systemd has a HUGE attack surface. the other reasons all feed into this one issue, it's a blaring and blindingly bright security issue.
Do you really believe that IBM, Oracle, RedHat, HP, CenturyLink,... are not going to be addressing security problems if and when they emerge?
btw, if you are GNOME2/MATE holdout trying to escape systemd like me, consider using LxQt [lxqt.org]. it's still a work in progress but it's usable as an everyday desktop environment.
LXDE is a great choice of a lightweight desktop. And will be a great choice for distributions that don't make use of systemd as well.
One thing I don't understand is how in the hell it is considered ok to have this in Debian STABLE? Maybe, in Fedora or OpenSuse but Debian stable???!
OK I'll assume this is a genuine question. Most certainly over the life of the next Debian stable there is going to be a situation where hundreds of packages make use of systemd process management or depend on lower level systems that do. They are going to be mostly untested and unmaintained against other init systems. Their own application specific process management features will be buggy or non existent. More importantly when their are security problems they may not be patched because nobody in upstream cares. That is a completely unacceptable situation.
So Debian must by their next version be converted over. They may have that problem over the next 2 years. So at best they could do one more version, Jessie on initd and even for that it is likely to be a hassle. So given:
a) The switch has to happen. b) RHEL will guarantee that systemd is going to be well maintained
Would be a good theory except: Suse, CoreOS, Ubuntu, Oracle.... are also going systemd. If that were RedHat's plan you don't think they would have an interest in stopping it. And for that matter let's not forget things like IBM and Linux on Azure.
Either process management becomes part of the mainstream Linux ecosystem or it doesn't. The choice was made that it will by upstream developers. That's not something that Debian can control. So the choice for distributions is:
1) Stop being a broad distribution 2) Engage in a massive and exponentially increasing porting operation 3) Use systemd
(3) is obviously the best option for Debian. That's why your side should have to fork.
the end of the use of System V init means that Linux is starting to head away from the UNIX operating systems.
What Unix operating systems? Linux killed most of them. OSX has been using launchd for a decade. AIX has all sorts of process cluster control features for almost 20 years. Same with Solaris. So who are they diverging from other than Free/Open BSD which weren't on SysV to begin with?
That's not true. The issue was an architectural one. The systemd people felt the dependency management problem had to be solved by the process manager not left to the admin to resolve. When Upstart refused to take this on, systemd was born.
I wouldn't be so sure. Gamergate people made the same claim when they were using terrorism as a tactic. They were successful in getting what they thought they wanted which was mainstream media exposure. And the mainstream media exposure portrayed them as anti-social quasi criminals. It is entirely possible that the anti-systemd arguments get associated with the campaign of harassment which most neutral people are going to be repulsed by. So rather than merely being disagreed with the anti-systemd crowd may find themselves entirely "beyond the pale".
Of course it is going to be forked. There will most likely be child distributions of Debian that don't use systemd. There certainly will be embedded distributions that don't use systemd and those can be built up with current software.
All this makes me wonder why someone can't build some other piece of software which would perform the required session management in this particular case?
What do you mean? Systemd does process management. That's what's introducing the dependencies it is a process manager. Why would you fork process management away from the process manager?
Actually resistence did form a few years back with both OpenRC and Upstart. The problem is those two projects failed to keep up. So the Linux community is confronted with the weird situation where they don't have choice. Normally there is chaos for years with competing standards this time there is 1 option. Sort of like if either Gnome or KDE had failed in the late 1990s.
Hairyfeet. That's what happened. Systemd has been in testing for over a year. That happened. The bugs are mostly ironed out. At least ironed out enough that other extremely stable distributions like RHEL use it. There isn't a bug problem. Of course a brand new piece of software that does lots of things is more buggy than a 30 year old piece of software that only does a few things. But that will always be the case with any upgrade.
The reason for the conspiracy is that there isn't one. First off the distributions didn't all move at the same time. Early adopting distributions like Arch moved first. Ubuntu and Gentoo both had their own alternative approaches. Late adopting distributions like Debian moved near the end. The reason the late adopters are moving now is more and more upstream software are created dependencies on systemd. Distributions can either:
a) Do exponentially increasing amounts of porting and support work b) Limit their software c) pick systemd
Who wants to maintain a traditionalist distribution with ancient software. That's exactly why systemd is dividing !
OK then yes this is the division, if there is a division. But that's not Debian who is doing it. That's the developers. Debian is simply reacting to the reality. Debian cannot change the world. They don't want to maintain a traditionalist distribution with ancient software so they are standardizing on systemd.
This is what you hope and this is YOUR vision of the future. All the process management consolidated in systemd.
This isn't exactly the future. It is already happened on desktop. On server it isn't a vision it is the working reality. Docker already has a hard dependency on process management: upstart, systemd or supervisor. OpenShift via. GearD is building in systemd dependencies.
This isn't political. The developers made their choice. Developers like PaaS deployment models. PaaS want to run on IaaS. IaaS requires process management. which means some standard must exist, the only realistic candidate today is systemd. This is open source if you don't like the direction people are going in, write code. That's always been the rule. If the anti-systemd people want to start offering alternatives they need to stop petitioning and start coding.
OpenRC was far closer to initd. In 2006 when these discussions were going on, and in 2007 when the OpenRC project started why didn't the anti-systemd get to work on OpenRC and make sure it kept up with systemd? Had they likely we wouldn't be here.
There is no huge groundswell of support for initd. It doesn't exist. The anti-systemd people never cared initialization... They didn't fix the problems when the discussions were taking place. And now almost a decade later they are saying "we want everyone else to wait even though we don't have a viable solution". A group motivated frankly by laziness about learning new technologies and fear of proven technologies might be successful if they were going to contribute lots of code. But if they aren't in the open source world is not going to be given equal voice. If you want traditionalist distributions they should exist. But there is no reason the rest of the Linux community should be held back.
Who are the ones that need to grok the init system ? Yes the sysadmins
The system admins don't have problems groking systemd. Systemd is pretty easy to use. Some don't like it but that's very different from them not being able to learn how to use it.
not the developers unless they develop systemd.
No you don't get it. The fact that this is false is precisely the problem that Debian faces. Many applications need process management functionality. Under initd that's implemented on a per application basis as a one-off adhoc function. That's what is disappearing. The developers are no longer going to be created or maintaining that code. Which means that Debian if they don't default to systemd will have to write and maintain huge chunks of upstream code. That is port. Debian has always allowed people who want to port to port. But they themselves have never before been asked to take on a major porting project. That's what the anti-systemd people are demanding, a major porting project. Not necessarily by 2014 but very soon thereafter. Many think one that is simply going to be impossibly big during the lifespan of Jessie.
But please don't take this big dividing stance in a community distribution by makiing it the default
I've never understood how choosing initd is not dividing while systemd is. I think there likely is a division between people who want a rich ecosystem and people who want simpler smaller. That's the division. It already exists. What you are saying is "screw those people over there and give me what I want". Which is a reasonable political position, but once your interests conflict the division exists.
Making it the default in Debian won't matter. For example embedded distributions even 10, 15 years from now may still be using initd or OpenRC or some much lighterway init system. There are possibly a group of admins who want simpler systems though and they can work off of those. Linux already has a diverse group of distributions it has that culture. That's not division. There will be some non-systemd ones, most likely some will be child distributions of Debian. It is not going to be hard to just drop most newer software and maintain a traditionalist distribution.
It's still in its baby phase growing all sort of organs and appendices (dhcp server, ntp daemon, eating udev,...), let the feature creep first dissipate.
Let me make this clear. The feature creep will never dissipate. systemd is a process manager. It's aim is to become the system plumbing for Linux userspace. It will take on more and more and more functionality that is going to be more and more complex. One needs only look at mainframe OSes (from which systemd takes it philosophy) to see how far process management (2014) needs to go to get to even current 2014 demands.
The Linux kernel continues to improve and add new functionality yet you run it.
Slashdot Mirror
As an aside since your comment seems reasonable. The main reason for binary logs is that systemd logs have machine readable features. For example the daemon can be asked questions about what happened and read the logs. They also are indexed. The indexing allows for much larger numbers of messages to be useful.
The purpose of POSIX was to support a standard for application design at a time when there was a huge variety of Unixes written by competing vendors. It was a key part of the open systems movement. Today
a) There aren't a huge variety of Unixes. Linux killed most of them and most of the remaining ones are niche.
b) POSIX is massively outdated.
What is needed is a way to run across multiple IaaSes which is the meaningful equivalent. Which is the PaaS movement. Systemd is a key component of making that happen by creating cross platform process low level process management. So arguably it advances the goals of POSIX updates for the 2010s.
Because the log files aren't designed to be primarily read by humans but rather by other systems. Moreover the systemd log format has indexing so the logs can answer questions about their state or activities. Human readers reading the entire log are a secondary use case, supported but likely not well going forward.
Actually no. Every component I know has alternatives in use in large production systems.
No there are already multiple libraries which understand the binary format and several editors making use of those libraries to read the binary format.
OpenBSD forever. Slackware a few more years.
But don't worry it is a bad fit for some embedded use cases. So there will be embedded distributions that don't use systemd and it will be easy to extend those to create a "traditionalist Linux" distribution.
Forgot about bootup times. Address the real issue. Full featured process management. That's a major shift. A complete replacement of the userspace plumbing with something much more feature rich, and thus much more complex. This isn't feature creep it is the natural evolution of a central system management daemon.
That's OpenRC which the anti-systemd people didn't work to support either.
The programmers, developers love the systemd features. That's where the dependencies are coming from. They are thrilled to be able to be able to depend on complex runtime dependencies the way the Linux package management system let's them depend on complex chains of library dependencies. The opposition is a small group of administrators who like traditionalist administration.
It is reasonable for a distribution. Systemd will be a bad choice for many types of embedded distributions and Linux is big on embedded. So there will be non-systemd distributions. It won't be hard to fork those to create a "traditionalist Linux". So yes I think it will exist. It wouldn't shock me if some are child distributions of Debian.
That being said, initd shouldn't be the default for mainstream distributions like Debian. So what's happening is the right thing.
Excellent comment. If I hadn't already commented I'd mod you up and if I hadn't already friended you I would. Very well put.
OK I'll address those:
Z-OS has worked for an even longer time and that has always had complex process management.
boot time is just one of many advantages. Process management does matter for server.
The direction is server administration is the exact opposite. Extremely complex systems which offer a rich set of services to developers and and administrators. Your view of what is valuable is the minority view because of its proven costs especially in the area of pushing the complexity into deployment complexity.
You do understand there is a difference between someone disagreeing with you and someone being ignorant. For example you run the Linux kernel which is monolithic and tightly coupled rather than a kernel like QNX's which meets your criteria. Why?
The major server vendors and distributions are all in favor of it. OpenShift, Cloud Foundry, Heroku, Helion... are not exactly ignorant about the server use case.
OK and how does that not apply to the anti-systemd people who have failed to explained why initd's lack of process management is a good idea?
Because it isn't an init system. It is a process management system. initialization is just one of the states it manages.
Of course they have been refuted. It is being used in production in some of the largest most complex systems out there.
Bullshit. They are attacking fantasy by quoting propaganda. The Linux community generally called that FUD when it was applied on other issues.
No they aren't. Their intended users on the server side are the admins who control hundreds to tens of thousands of servers. The opposition is coming from system admins who generally administer a 1/2 dozen boxes. And I will tell you as someone who strongly supports systemd's direction, for server, I get attacked personally all the time by anti-systemd people.
Do you really believe that IBM, Oracle, RedHat, HP, CenturyLink, ... are not going to be addressing security problems if and when they emerge?
LXDE is a great choice of a lightweight desktop. And will be a great choice for distributions that don't make use of systemd as well.
OK I'll assume this is a genuine question. Most certainly over the life of the next Debian stable there is going to be a situation where hundreds of packages make use of systemd process management or depend on lower level systems that do. They are going to be mostly untested and unmaintained against other init systems. Their own application specific process management features will be buggy or non existent. More importantly when their are security problems they may not be patched because nobody in upstream cares. That is a completely unacceptable situation.
So Debian must by their next version be converted over. They may have that problem over the next 2 years. So at best they could do one more version, Jessie on initd and even for that it is likely to be a hassle. So given:
a) The switch has to happen.
b) RHEL will guarantee that systemd is going to be well maintained
why not switch now?
Would be a good theory except: Suse, CoreOS, Ubuntu, Oracle.... are also going systemd. If that were RedHat's plan you don't think they would have an interest in stopping it. And for that matter let's not forget things like IBM and Linux on Azure.
That it is just a replacement for initd with a lot of extra stuff thrown in.
The kernel, XWindows, GCC, ... No it is heard of.
It is an A or B choice.
Either process management becomes part of the mainstream Linux ecosystem or it doesn't. The choice was made that it will by upstream developers. That's not something that Debian can control. So the choice for distributions is:
1) Stop being a broad distribution
2) Engage in a massive and exponentially increasing porting operation
3) Use systemd
(3) is obviously the best option for Debian. That's why your side should have to fork.
There are going to be some embedded distributions that won't switch. They can't afford the RAM usage.
What Unix operating systems? Linux killed most of them. OSX has been using launchd for a decade. AIX has all sorts of process cluster control features for almost 20 years. Same with Solaris. So who are they diverging from other than Free/Open BSD which weren't on SysV to begin with?
You can configure systemd to not restart /etc/systemd/system/unit.d/restart.conf
That's not true. The issue was an architectural one. The systemd people felt the dependency management problem had to be solved by the process manager not left to the admin to resolve. When Upstart refused to take this on, systemd was born.
I wouldn't be so sure. Gamergate people made the same claim when they were using terrorism as a tactic. They were successful in getting what they thought they wanted which was mainstream media exposure. And the mainstream media exposure portrayed them as anti-social quasi criminals. It is entirely possible that the anti-systemd arguments get associated with the campaign of harassment which most neutral people are going to be repulsed by. So rather than merely being disagreed with the anti-systemd crowd may find themselves entirely "beyond the pale".
Of course it is going to be forked. There will most likely be child distributions of Debian that don't use systemd. There certainly will be embedded distributions that don't use systemd and those can be built up with current software.
What do you mean? Systemd does process management. That's what's introducing the dependencies it is a process manager. Why would you fork process management away from the process manager?
Actually resistence did form a few years back with both OpenRC and Upstart. The problem is those two projects failed to keep up. So the Linux community is confronted with the weird situation where they don't have choice. Normally there is chaos for years with competing standards this time there is 1 option. Sort of like if either Gnome or KDE had failed in the late 1990s.
Hairyfeet. That's what happened. Systemd has been in testing for over a year. That happened. The bugs are mostly ironed out. At least ironed out enough that other extremely stable distributions like RHEL use it. There isn't a bug problem. Of course a brand new piece of software that does lots of things is more buggy than a 30 year old piece of software that only does a few things. But that will always be the case with any upgrade.
The reason for the conspiracy is that there isn't one. First off the distributions didn't all move at the same time. Early adopting distributions like Arch moved first. Ubuntu and Gentoo both had their own alternative approaches. Late adopting distributions like Debian moved near the end. The reason the late adopters are moving now is more and more upstream software are created dependencies on systemd. Distributions can either:
a) Do exponentially increasing amounts of porting and support work
b) Limit their software
c) pick systemd
They choose (c) because it is the obvious choice.
OK then yes this is the division, if there is a division. But that's not Debian who is doing it. That's the developers. Debian is simply reacting to the reality. Debian cannot change the world. They don't want to maintain a traditionalist distribution with ancient software so they are standardizing on systemd.
This isn't exactly the future. It is already happened on desktop. On server it isn't a vision it is the working reality. Docker already has a hard dependency on process management: upstart, systemd or supervisor. OpenShift via. GearD is building in systemd dependencies.
This isn't political. The developers made their choice. Developers like PaaS deployment models. PaaS want to run on IaaS. IaaS requires process management. which means some standard must exist, the only realistic candidate today is systemd. This is open source if you don't like the direction people are going in, write code. That's always been the rule. If the anti-systemd people want to start offering alternatives they need to stop petitioning and start coding.
OpenRC was far closer to initd. In 2006 when these discussions were going on, and in 2007 when the OpenRC project started why didn't the anti-systemd get to work on OpenRC and make sure it kept up with systemd? Had they likely we wouldn't be here.
There is no huge groundswell of support for initd. It doesn't exist. The anti-systemd people never cared initialization... They didn't fix the problems when the discussions were taking place. And now almost a decade later they are saying "we want everyone else to wait even though we don't have a viable solution". A group motivated frankly by laziness about learning new technologies and fear of proven technologies might be successful if they were going to contribute lots of code. But if they aren't in the open source world is not going to be given equal voice. If you want traditionalist distributions they should exist. But there is no reason the rest of the Linux community should be held back.
The system admins don't have problems groking systemd. Systemd is pretty easy to use. Some don't like it but that's very different from them not being able to learn how to use it.
No you don't get it. The fact that this is false is precisely the problem that Debian faces. Many applications need process management functionality. Under initd that's implemented on a per application basis as a one-off adhoc function. That's what is disappearing. The developers are no longer going to be created or maintaining that code. Which means that Debian if they don't default to systemd will have to write and maintain huge chunks of upstream code. That is port. Debian has always allowed people who want to port to port. But they themselves have never before been asked to take on a major porting project. That's what the anti-systemd people are demanding, a major porting project. Not necessarily by 2014 but very soon thereafter. Many think one that is simply going to be impossibly big during the lifespan of Jessie.
I've never understood how choosing initd is not dividing while systemd is. I think there likely is a division between people who want a rich ecosystem and people who want simpler smaller. That's the division. It already exists. What you are saying is "screw those people over there and give me what I want". Which is a reasonable political position, but once your interests conflict the division exists.
Making it the default in Debian won't matter. For example embedded distributions even 10, 15 years from now may still be using initd or OpenRC or some much lighterway init system. There are possibly a group of admins who want simpler systems though and they can work off of those. Linux already has a diverse group of distributions it has that culture. That's not division. There will be some non-systemd ones, most likely some will be child distributions of Debian. It is not going to be hard to just drop most newer software and maintain a traditionalist distribution.
Let me make this clear. The feature creep will never dissipate. systemd is a process manager. It's aim is to become the system plumbing for Linux userspace. It will take on more and more and more functionality that is going to be more and more complex. One needs only look at mainframe OSes (from which systemd takes it philosophy) to see how far process management (2014) needs to go to get to even current 2014 demands.
The Linux kernel continues to improve and add new functionality yet you run it.