It was not possible with consolekit, great that there was progress with consolekit2.
There is no way to refute conspiration theorists. It is a self-contained believe system, that functions outside of the real world. I won't bother to argue with that.
What got vdev/udev to do with running xorg as non-root? Yes, that does initial setup of device nodes, but all the rest is handled by systemd-logind.
You are brandishing the wing stick:-)
That person is bitching that everybody and their dog start to depends on systemd. That is your evidence right there.
Of course you have to do the dating assumption that devs do whatever they like... It kind of crumples if you assume that there are systemd hitmen traveling the world, forcing developers to depend on systemd.
That consultation mongering in that link is indeed laughable.
The absense of CVEs can mean the absense of people looking, and with the x11 being a quagmire of protocols, often contradicting each other as new stuff gets added over the decades, there are very few people that can even understand the code. One guy started to look last a while back and he is finding appalling bugs, check the recent CVEs and his presentation at last years chaos communication congress (30C3).
Making this swamp a bit dryer by not having it have root priviledgea is something that was work in progress ever since xfree started to run on Linux.
Now you come here and tell me that this sour spot for the last thirty years is better to keep around than having a much smaller, much cleaner codebase where almost all parts run in their own security context -- usually with privileges way lower than those you have as a user. Right.
Mid term devuan has just one chance: Make it easy for developers to provide solutions that work with multiple int systems. Systemd does bring quite a few improvements for developers. That is the reason why systemd becomes entrenched: Developers like it and start to depend on it since it makes their live easier.
If devuan wants to keep a manageable distribution they need to make it similarly easy to tackle issues in a convenient and reliable way when using multiple init systems. If they manage that, then I am pretty sure developers will support their interfaces in favor of systemd. No developer wants needless ties.
Unfortunately it is much harder to provide generic solutions than it is to provide a specific one. So devuan is in a very challenging position to make things easier for developers.
Is they blow this, then they will have more and more software that depends on systemd-only interfaces and more and more work to remove those dependencies.
The fork is called "Devuan", pronounced "DevOne". A website is up on https://devuan.org/ with more information."
Link to Original Source
Link to Original Source
"Dear Init-Freedom lovers, the Veteran Unix Admin collective salutes you!
Our project is called "Devuan".
Devuan is spelled in Italian and it is pronounced just like "DevOne" in English.
Devuan developers can be reached with an e-mail to vua at debianfork dot org.
OK guys, nevermind the names, but what's the plan?
We started setting up the first bits of a core infrastructure to host a website, mailinglists and a Dak based package repository.
We are uploading materials on the https://github.com/devuan group which we plan to use as a development platform, at least in this initial phase.
We are going to setup a BTS allowing us to inherit many useful Debian development tools and we plan to have a continuous integration system for our packages going from GitHub to a Jenkins builder and then to our repositories.
We plan to innovate many of the tools that were historically used in Debian development, still mainaining stable, testing and unstable package repositories that users and downstream can use.
Soon we will be ready to welcome package maintainers and then we will focus on refining the continuous integration pipeline and the communication and decision architecture informed by research projects as D-CENT. Besides the package-specific BTS we are going to use GitHub issues to coordinate tasks.
The first package of Devuan is devuan-baseconf: a Debian installer with preseed of sysvinit-core and a couple of devuan packages containing a keyring, repository list files and pinnings. Once installed and updated this package avoids the requirement of systemd as PID 1 and adopts systemd-shim when strictly needed.
What Devuan should be then? is it really a fork?
This is just the start of a process, as bold as it sounds to call it a fork of Debian. This exodus is ultimately being a relief for some of us and should lead to the creation a peaceful space for work we are well able to do. To help with this adventure and its growth, we ask you to get involved, but also to donate money so that we can cover the costs of setting the new infrastructure in place.
Devuan aims to be a base distribution whose mission is protect the freedom of its community of users and developers. Its priority is to enable diversity, interoperability and backward compatibility for existing Debian users and downstream distributions willing to preserve Init freedom.
Devuan will derive its own installer and package repositories from Debian, modifying them where necessary, with the first goal of removing systemd, still inheriting the Debian development workflow while continuing it on a different path: free from bloat as a minimalist base distro should be. Our objective for the spring of 2015 is that users will be able to switch from Debian 7 to Devuan 1 smoothly, as if they would dist-upgrade to Jessie, and start using our package repositories.
Devuan will make an effort to rebuild an infrastructure similar to Debian, but will also take the opportunity to innovate some of its practices. Devuan developers look at this project as a fresh new start for a community of interested people and do not intend to enforce the vexation hierarchy and bureaucracy beyond real cases of emergency. We are well conscious this is possible for us mostly because of starting small again; we will do our best to not repeat the same mistakes and we welcome all Debian Developers willing to join us on this route.
The Devuan distribution will make an effort to improve the relationship with both upstream and downstream and, particularly in its gestational phase, will do its best to accomodate needs of those downstream distributions willing to adopt it as base. We look forward to statements of interest from such distributions, as well involvement in this planning phase.
Devuan will do its best to stay minimal and abide to the UNIX philosophy of "doing one thing and doing it well". Devuan perceives itself not as an end product, but a starting point for developers, a viable base for sysadmins and a stable tool for people who have experience of Debian. Devuan will never compromise for more efficiency at the cost of the the freedom of its users, rather than leave such concerns to the independent choices made by downstream developers."
Well there it is. Discuss."
So is systemd-the-initsystem and systemd-networkd. Both are independent tools, where systemd-networkd uses an API provided by systemd-the-initsystem. Distributions routinely replace systemd-networkd. They replace other parts of systemd as well. So I fail to see the difference. There are about 60 different binaries, each doing one thing. They all communicate using a standard and even scriptable method that is widely used in unix desktop environments.
The BSDs tend to develop kernels and tools together, too, precisely to have a better integrated userland and I am pretty sure those count as unix:-) So that is not (only) the windows way. The systemd project is about providing similar plumbing for Linux. The developers clearly say so for a long time now. With the stated goal of being the plumbing layer the project tackles a lot of problems that were ignored. That is a good thing(TM). And that more and more developers of applications start to depend on the plumbing is proof to me that they are doing a good job. Actually that is where the value of systemd is, not in the init system.
Process management the core task of any init system, so I am not sure how that ended up in your list. Not sure what notifications does there either, since I am not aware of systemd actually doing that, but maybe I am missing something. The kernel devs have tried to clean up the console code repeatedly and have expressed interest in moving that code to userland. A brave soul stepped up and started to implement that. Putting it into systemd is the logical step for him to take: That is what all the major distributions are using. That there is finally some common ground makes projects like this possible in the first place! Or do you seriously think he would have written the code and then have bothered to integrate it into a dozen different distributions? Nope, no chance. Yes, there are packagers that help with the packaging, but he would still have a shitload of integration work to do to handle the different setups, init systems and whatnot.
- A complete disregard for precedent.
There are precedents to changing init systems on unixy systems: Mac has launchd, Solaris has SMF. Sysvinit itself was called an aberation when it was introduced, too, doing away with the much simpler BSD-style init.
I would consider systemd very unixy: It has lots of small tools, each designed to do something well. These work in concert to accomplish complex tasks. This whole "unix philosophy" thing is basically in the eye of the beholder.
- An uncompelling value proposition. I don't much care about boot time
Boot time is a side-effect.
Better hardening options for services is a value systemd brings to the table. Process management is another big one. Better logging, too. A more robust boot free of races is hard to argue with too (provided you have been bitten by such a race condition before:-). Finally socket activation greatly simplifies dependency management.
- Poor architecture.
Systemd uses DBus, an established, well understood and well tested protocol to communicate in favor of rolling its own. That can be considered a huge plus: Or have you never seen custom protocol parsers explode before, especially those written in C?
- Lack of concern for the server use case, and sysadmins in particular.
I wonder where you got that from. Systemd is particularly well suited for server systems: It makes for a more reliably boot process, it provides easy ways to harden services run, it can monitor running services, it collects way more log entries and enriches them with a lot of information directly from the kernel.
- Tying perfectly-good cross platform programs to Linux. Why my window manager or graphics program has to depend on init, I don't know.
Systemd is designed to make all the features of Linux available to admins. Those features are not available elsewhere, so of course systemd is neither. Blame that on the kernel developers, not on systemd.
Why does it your desktop environment depend on systemd? Because the developers of your desktop environment have decide that the services provided by systemd are valuable to them. Note that the desktop environment technically does not depend on systemd running as PID1, just on some of the daemons that are developed in the systemd repository. Those do in turn depend on systemd being PID1, but that is a different story:-)
If you do not know something, then maybe you should spend your time trying to understand the issue at hand before commenting in a public forum?
- Most importantly, the community is extremely toxic.
My experience with the systemd community was positive all the way. Any questions I had were answered in a friendly and helpful way. My patches were reviewed in a direct but friendly fashion and applied after all parties were happy with them. That is more that I can claim about many other projects I had contact with.
And I have seen several comments that have been well refuted but are brought up again and again. Well, I am happy with the answers to those comments, obviously the people making those comments are not.
And the most troubling aspect of this toxic community are the attacks on opponents.
There are rather a lot of opponents attacking proponents as well. That is no excuse for anybody to misbehave, but at this point *both* sides need to step back and take a deep of breath.
[...] No, there was outcry all those other times (in the PulseAudio case, quite rightly), but this is by far the most severe I've seen. And do any of these proponents think to ask - why? No, they decide it must just be change aversion and claim they're all just trying to set up a guild to keep their practices secret.
The outcry when the complex monster known as sysv init was introduced to replace the beautiful and simple BSD-style init was rather loud, too. Of course we were a much smaller group of people caring about Linux back then.
I have seen quite a few of the people arguing against systemd admit freely that they have never used it. That did give me the impression that much of the fuss ultimately results from a resistance to change, but I might be wrong.
Also I am convinced that there are actually only very few opponents that just manage to raise a lot of noise. E.g. the uselessd site consistently speaks about "we" and "our", but when you check the source code repository the whole thing was written by one person. I suspect other sites are doing the same. Maybe they are ultimately all run by one person with way too much time on their hands. Who knows?
[...] For the most part I don't have to think about booting - just like when I used to run Windows. But now when I have to, it's much, much easier than it was on Windows, because there's no complexity - it's just some folders with symlinks to shell scripts that get run![...]
Checking for a file in
You seem to be more intelligent than me if you have no trouble with those scripts! And you also must be a better programmer than most of the authors of init scripts, which are often racy and even buggy.
All of you reading this: Think about it. I'm sure you've read attacks by each side about the other. But for the most part, I've seen systemd opponents attacking technical, philosophical, and architectural choices (which includes "we don't want to look like Windows with svchost.exe"), while systemd proponents are attacking their intended users. Which side seems more dangerous?
I have seen way more name calling in systemd discussions than arguments, be they technical, philosophical or architectural. And that is from *both* sides.
Systemd is monolithic - not built into a single binary blob, but split into several tightly-dependant binary blobs.
Follow the Unix philosophy: Do one thing and do it well and work with other tools to implement complex tasks.
With your definition "ls -alF | grep "^drwxrwxrwx " is monolithic: The grep statement depends on ls formatting its output in a certain way. That makes them tightly-dependent binary blobs.
It is actually pretty simple: The systemd init system provides cgroups, which do solve a lot of problems that tools close to the kernel have. So those tools start to use systemd-the-init-system. These tools then in turn provide solutions to problems that application developers face. They do so in a better way than other tools addressing the same problem -- because they can leverage systemd-the-initsystem. So application software starts to depend on the tools lower down in the stack.
There is no one piece of software that depends on systemd-the-init-system directly: They all depend on things one level lower in the stack, all the way down to systemd-the-initsystem. That is actually considered to be good software design.
You are free to replace any level with another implementation (providing the same interface). Those interfaces are not all stable at this time, which is a bit of a stumbling block. But systemd actually promises stability for some interfaces while listing others as still under active development. That is more than many other projects do!
To me a faster boot-up time are just a nice side-effect of running systemd. I also do not see where well-established init system vestiges are abandoned. PID1 is pretty small -- yes, it is bigger as sysv-init, but then it does quite a few new and useful tricks.
Logs can be binary or you can forward them to whatever syslog implementation you care for (some of them then storing them in their own binary format;-). Why is that considered an issue at all? SuSE and RedHat apparently do that in their default configuration (I have not tried those though).
And no, adding more stuff to sysv-init is definitely not the right approach. It had out-grown its usefulness about a decade ago: That is when all the "real" unixes moved away from it, using service managers similar to what systemd tries to do now on Linux.
Abandoning sysv init is not happening to standardize on a new file format. It is happening because shell scripts are a horrible way to configure a system. A 10 line systemd file does a better job at starting a service than a 200 line sysv-init file. Systemd does apply a bunch of hardening features (e.g. make
About "Unix principle": I personally do not see why systemd is supposed to violate those. It is a lot of small binaries -- each doing some specific task -- working in concert.