Because somebody or something has to start the syslogd too.
What the fuck is the relevance of that? syslogd gets started by magic in sysvinit?
No.
But as long as your shell doesn't randomly crashes, and one of the first lines in the rcS is something like 'rsyslogd &', and rsyslogd doesn't crash - the syslogd will be definitively and certainly started.
You can call it magic, though, if you want. Because that's not something systemd can guaranteee.
I may be naïve but I've been debugging problems in the sysv boot process since 1994.
Ditto, since 1997. Though, I have to admit, I have spent very little time debugging them: they 99.999% of time it just works. And it also work very well in edge cases like brining up a server from the dead, after catastrophic hardware failure or a simply broken upgrade.
As far as I'm concerned, the OpenBSD developers are as close to infallable as software developers could ever hope to get.
If they've decided to do this, then it's just the correct thing to be doing.
HP rep - a HP-UX sales guy - once told me that their kernel doesn't support loadable modules to prevent even the remote possibility of a malicious driver.
But why OpenBSD choose to do it, I have no idea. Frankly, I was under impression that OpenBSD didn't support loadable kernel modules at all.
To some the kernel drivers might seem a norm, but even 15 years ago they were still considered a novelty. And everybody was still making jokes about Microsoft's Plug-n-Play.
If you want a distro that develops, there's always Ubuntu or Fedora.
My point wasn't that Debian is being developed too slow. QA has never been fast.
My point is that Debian nearly always distances itself from the development and the developer community.
In other comment I also mentioned the APT. If Debian was today debating a packaging system, they would never ever opt to *develop* the APT like they did in the past, but they would take the RPM and try to live with it.
Otherwise, just look at two good examples of distros evolving: SUSE Studio and Ubuntu Launchpad. Lots of things which happen there rarely see the daylight - but they allow distro to play proactive role in bringing together the developers and users. (But of course, SUSE Studio and Launchpad are targeted at two different kinds of "developers" - first is for developers of distros and second is for the developers of the software.) That might seem superficial, but it allows distro to actually learn about the new trends and things people are doing with the software. They need much less guessing what/how to do in the next release. OTOH Debian, beside the heavily unreliable popcon, is very very much closed and unto itself.
That distance also plays role in how Debian's decisions are made. You can't roll-out something new and experimental in Debian and expect later it being adopted in Debian main. No. Because Debian wants to have a project with proven track record. And you can't get the "proven track record" *in* Debian - because the project will not be accepted without "proven track record". That is why the development happens in the Fedora, Ubuntu and SUSE. Rarely in Debian.
And why is this on-topic? Because Debian with migration to systemd would in some aspects become Red Hat, which is not something I'm particularly happy about. Because, though RH doesn't develop much of the systemd itself, it does quite a lot of work on systemd integration. Because they played role in its development. They gave the project fighting chance. And all it took for them was to say the developers: OK. At the same time, if you check history of attempts to bring upstart into Debian (which is much longer than the vs systemd discussion), Debian wasted literally years discussing, and mostly dismissing upstart because it was used by only one distribution, despite Canonical's pledge. Result? Red Hat has nurtured the systemd - and Debian has strangled the upstart.
That has nothing to do with the init system. That performance largely depends on the performance of the applications, and to some extent on the performance of the DE. The init system, after start-up, is mostly idle. The "biggest" job it has then is the reaping of the zombie processes.
Ubuntu uses upstart only to manage the early boot sequence. Majority of everything is still started by the traditional/etc/init.d scripts, with runlevels and whatnot. There are some services which have upstart jobs - but out-of-box they are minority.
I had an installation of vanilla Fedora 20 for couple of weeks. The release where it was said that systemd is properly and fully integrated.
On the same hardware, it did NOT boot or work faster compared to the vanilla Ubuntu.
On average, Fedora was 50-100% slower. Which was kind of surprising, because I thought nothing can beat the Unity desktop in poor interactivity. And that shell-scripted boot can't be faster than the systemd' C boot sequence. And yet...
Compare that to the Fedora. The immaturity of systemd hasn't prevented them from actually giving the users a chance to try the new init system. It actually helped to step up its development. And Red Hat isn't even the top contributor to systemd.
The Debian does lots of good things - but it fails at letting people to help them.
New things are always going to lack "tangible code and some track record". And the Debian is the wrong place for a project to try to get one. And that is the biggest problem of the project, IMO.
However, it is undesired by a vocal minority of users and sysadmins
FTFY.
It is not a minority. It would become a overwhelming majority when the systemd would actually be installed on the majority of the systems. But it would be too late then, of course.
I probably shouldn't care at all. Systemd would never appear on the systems I work with. For the simple virtue that it is, with the dozens of other "supervision" frameworks, is simply redundant, primitive junk, which is only capable of starting and restarting the Apache server (a.k.a. "hello world" type of service, with no real (distributed networked) dependencies and one bit of state (running/not running)).
I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.
The Ubuntu LTS releases, are pretty much what I always expected from the Debian.
The difference is that Ubuntu isn't afraid to put time of developers into the release.
While Debian insists on simple repackaging.
I'm sorry to say it, but Debian has already been a "whore" to lots and lots of other distros, even before Ubuntu hit it big. For the fact of having no distinctive technology of their own.
Recall the time when the APT was ruling. Back then, the Debian ruled. APT had set the bar for other package management systems. People followed the Debian. Now? Not so much. Debian is following and has been following for many many years now. They are not distro per se - they are the distro factory, other distros build up on. I gather that makes it a "whore" distro.
Blaming Ubuntu misses the point. Because Ubuntu does much more than just repackage the Debian. The bigger question is: why Debian hasn't evolved into something like Ubuntu is? Where's Debian's launchpad with the PPAs? where anybody can develop new things? where from users can easily access the new things?
To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.
After so many years, I have finally understood why Debian is constantly rises, hits the plateau, freezes for few years in shock and tumbles back down. They want to be just a distro. They do not lead - they follow. They do not create standards - they adopt them. They do not develop stuff - they just repackage someone else's stuff.
That again was one of the driving factor in picking the systemd over the rest. With systemd, somebody else is doing all the work, while Debian just repackages it.
Is fork a good idea? There is no fork, really. Debian is nothing but an organization, a community. One can clone the repo - but one can't clone the community.
Take out from all of this? There are no reasons to worry. Nothing really changed. Debian is simply following the rest of the distros. I'm simply hopeful that they would manage to integrate the systemd nicely. If not... It's not like it would be the first time Debian released something broken and unusable. (Oh, yes, there might no RC bugs - but the (too old/too new) versions of the software, or their configuration, simply make it useless. And trying to change it - breaks it.) That's why we have the Ubuntu, after all: it's like Debian, but not striving for some committee set goal - instead striving to be just useful.
It's tons of new code, tons of attack surface, tons of bullshit.
I take it then you are not admin - or a lowly paid one.
"new code" + "tons of bullshit" = reasons to ask management for more training, more hardware, larger IT budget. Then learn some the new obscure POS and become literally irreplaceable. Every new release - another new obscure POS - and people get a chance at a nice career.
And most importantly, since RH rewrites all the stuff every time, you do not actually need the Linux experience per se. Sometimes it is even counterproductive, since RH likes to patch stuff in some freaky way. It was for quite some time now with solutions where RH products were used: "People with extensive Linux experience don't need to apply."
Copyrighting APIs makes no techinical sense, while copyrighting maps and manuals does.
The only thing remotely plausible is patenting APIs. And even that I'm not sure technically feasible.
I've witnessed probably man/centuries of wasted efforts due to crappy APIs - and I've seen single-person projects springing to life and seamingly leveling mountains when the available APIs were good.
Some APIs fit the puzzle of any applications - some force projects as a whole back to the drawing board.
Slashdot Mirror
Because somebody or something has to start the syslogd too.
What the fuck is the relevance of that? syslogd gets started by magic in sysvinit?
No.
But as long as your shell doesn't randomly crashes, and one of the first lines in the rcS is something like 'rsyslogd &', and rsyslogd doesn't crash - the syslogd will be definitively and certainly started.
You can call it magic, though, if you want. Because that's not something systemd can guaranteee.
I may be naïve but I've been debugging problems in the sysv boot process since 1994.
Ditto, since 1997. Though, I have to admit, I have spent very little time debugging them: they 99.999% of time it just works. And it also work very well in edge cases like brining up a server from the dead, after catastrophic hardware failure or a simply broken upgrade.
Because somebody or something has to start the syslogd too.
You naive people do not even grasp how deep that jar or worms, known as the boot process, goes...
Wise men of old wrote it in shell for lots and lots of good reasons.
They are only cutting the subsidies.
The market has established itself: subsidies are not needed anymore.
Just like the article says in the third paragragh.
Most of our leaders, at least in Germany and Hungary, are in bed with the Russians and likely won't do anything about fuel security.
I do not know about Hungary, but Germany is heavily investing in the renewable energy.
Or you expected them to immediately cut the pipes? halt production and transportation? cut the forests to heat the homes?
systemd 204 is the last systemd release where some of its services can be used with the systemd-shim and without systemd as pid 1.
Ubuntu ships 204 for some time too, since GNOME requires the services.
I haven't used Plasma, but from the screenshots it appears to be as dysfunctional and castrated as the GNOME.
I hope Kubuntu would keep the full-blown KDE as an option.
I find it ironic that on one side they deny climat change, on the other - almost the same people build the ark.
Hey! My past employer willingly bought it!
...Oh. That's probably why they are "past".
As far as I'm concerned, the OpenBSD developers are as close to infallable as software developers could ever hope to get.
If they've decided to do this, then it's just the correct thing to be doing.
HP rep - a HP-UX sales guy - once told me that their kernel doesn't support loadable modules to prevent even the remote possibility of a malicious driver.
But why OpenBSD choose to do it, I have no idea. Frankly, I was under impression that OpenBSD didn't support loadable kernel modules at all.
To some the kernel drivers might seem a norm, but even 15 years ago they were still considered a novelty. And everybody was still making jokes about Microsoft's Plug-n-Play.
1)TO prove that you repay your debts
Sounds like a phrase from a western movie.
After living for so long in Germany, it also sounds absurd. (N.B. I've never lived in the US.)
Faith without evidence is toxic, faith with evidence isn't faith.
That makes sense only with this prepended:
Faith, in the religious sense,
But I feel you put those two far too apart.
Faith is something all people have naturally. People just have it.
Religion is simply a parasite which attaches to it. And that can make the faith toxic.
That's a feature, not a defect.
If you want a distro that develops, there's always Ubuntu or Fedora.
My point wasn't that Debian is being developed too slow. QA has never been fast.
My point is that Debian nearly always distances itself from the development and the developer community.
In other comment I also mentioned the APT. If Debian was today debating a packaging system, they would never ever opt to *develop* the APT like they did in the past, but they would take the RPM and try to live with it.
Otherwise, just look at two good examples of distros evolving: SUSE Studio and Ubuntu Launchpad. Lots of things which happen there rarely see the daylight - but they allow distro to play proactive role in bringing together the developers and users. (But of course, SUSE Studio and Launchpad are targeted at two different kinds of "developers" - first is for developers of distros and second is for the developers of the software.) That might seem superficial, but it allows distro to actually learn about the new trends and things people are doing with the software. They need much less guessing what/how to do in the next release. OTOH Debian, beside the heavily unreliable popcon, is very very much closed and unto itself.
That distance also plays role in how Debian's decisions are made. You can't roll-out something new and experimental in Debian and expect later it being adopted in Debian main. No. Because Debian wants to have a project with proven track record. And you can't get the "proven track record" *in* Debian - because the project will not be accepted without "proven track record". That is why the development happens in the Fedora, Ubuntu and SUSE. Rarely in Debian.
And why is this on-topic? Because Debian with migration to systemd would in some aspects become Red Hat, which is not something I'm particularly happy about. Because, though RH doesn't develop much of the systemd itself, it does quite a lot of work on systemd integration. Because they played role in its development. They gave the project fighting chance. And all it took for them was to say the developers: OK. At the same time, if you check history of attempts to bring upstart into Debian (which is much longer than the vs systemd discussion), Debian wasted literally years discussing, and mostly dismissing upstart because it was used by only one distribution, despite Canonical's pledge. Result? Red Hat has nurtured the systemd - and Debian has strangled the upstart.
That has nothing to do with the init system. That performance largely depends on the performance of the applications, and to some extent on the performance of the DE. The init system, after start-up, is mostly idle. The "biggest" job it has then is the reaping of the zombie processes.
Yes and no. Mostly no.
Ubuntu uses upstart only to manage the early boot sequence. Majority of everything is still started by the traditional /etc/init.d scripts, with runlevels and whatnot. There are some services which have upstart jobs - but out-of-box they are minority.
I had an installation of vanilla Fedora 20 for couple of weeks. The release where it was said that systemd is properly and fully integrated.
On the same hardware, it did NOT boot or work faster compared to the vanilla Ubuntu.
On average, Fedora was 50-100% slower. Which was kind of surprising, because I thought nothing can beat the Unity desktop in poor interactivity. And that shell-scripted boot can't be faster than the systemd' C boot sequence. And yet...
It is perilously close to an operating system - in stark contrast to the usual unix philosophy of small tools to do single jobs well.
GNU is not Unix. :)
Emacs is not based on the UNIX.
It is based on the lisp machines.
The lisp machine have died, but Emacs still lives on.
But systemd is written in C. I gather we would have to start by implementing C in elisp.
Emacs OS - I know it is missing a text editor - but does it support systemd?
Compare that to the Fedora. The immaturity of systemd hasn't prevented them from actually giving the users a chance to try the new init system. It actually helped to step up its development. And Red Hat isn't even the top contributor to systemd.
The Debian does lots of good things - but it fails at letting people to help them.
New things are always going to lack "tangible code and some track record". And the Debian is the wrong place for a project to try to get one. And that is the biggest problem of the project, IMO.
However, it is undesired by a vocal minority of users and sysadmins
FTFY.
It is not a minority. It would become a overwhelming majority when the systemd would actually be installed on the majority of the systems. But it would be too late then, of course.
I probably shouldn't care at all. Systemd would never appear on the systems I work with. For the simple virtue that it is, with the dozens of other "supervision" frameworks, is simply redundant, primitive junk, which is only capable of starting and restarting the Apache server (a.k.a. "hello world" type of service, with no real (distributed networked) dependencies and one bit of state (running/not running)).
I am beginning to be wary of systemd, but no. I am talking about anal-retentive policy wonks who believe they only make the distribution for themselves and have (perhaps without intending to) systematically marginalized Debiian and made the project a whore to Ubuntu.
The Ubuntu LTS releases, are pretty much what I always expected from the Debian.
The difference is that Ubuntu isn't afraid to put time of developers into the release.
While Debian insists on simple repackaging.
I'm sorry to say it, but Debian has already been a "whore" to lots and lots of other distros, even before Ubuntu hit it big. For the fact of having no distinctive technology of their own.
Recall the time when the APT was ruling. Back then, the Debian ruled. APT had set the bar for other package management systems. People followed the Debian. Now? Not so much. Debian is following and has been following for many many years now. They are not distro per se - they are the distro factory, other distros build up on. I gather that makes it a "whore" distro.
Blaming Ubuntu misses the point. Because Ubuntu does much more than just repackage the Debian. The bigger question is: why Debian hasn't evolved into something like Ubuntu is? Where's Debian's launchpad with the PPAs? where anybody can develop new things? where from users can easily access the new things?
To me the most enlightening - and saddest - moment of the init system selection discussion was when Debian leadership quite clearly stated that they are not interested in something being developed in-house, they are just distro which packages somebody's else work.
After so many years, I have finally understood why Debian is constantly rises, hits the plateau, freezes for few years in shock and tumbles back down. They want to be just a distro. They do not lead - they follow. They do not create standards - they adopt them. They do not develop stuff - they just repackage someone else's stuff.
That again was one of the driving factor in picking the systemd over the rest. With systemd, somebody else is doing all the work, while Debian just repackages it.
Is fork a good idea? There is no fork, really. Debian is nothing but an organization, a community. One can clone the repo - but one can't clone the community.
Take out from all of this? There are no reasons to worry. Nothing really changed. Debian is simply following the rest of the distros. I'm simply hopeful that they would manage to integrate the systemd nicely. If not... It's not like it would be the first time Debian released something broken and unusable. (Oh, yes, there might no RC bugs - but the (too old/too new) versions of the software, or their configuration, simply make it useless. And trying to change it - breaks it.) That's why we have the Ubuntu, after all: it's like Debian, but not striving for some committee set goal - instead striving to be just useful.
It's tons of new code, tons of attack surface, tons of bullshit.
I take it then you are not admin - or a lowly paid one.
"new code" + "tons of bullshit" = reasons to ask management for more training, more hardware, larger IT budget. Then learn some the new obscure POS and become literally irreplaceable. Every new release - another new obscure POS - and people get a chance at a nice career.
And most importantly, since RH rewrites all the stuff every time, you do not actually need the Linux experience per se. Sometimes it is even counterproductive, since RH likes to patch stuff in some freaky way. It was for quite some time now with solutions where RH products were used: "People with extensive Linux experience don't need to apply."
Just like it was in the good ol' UNIX times.
THE PROGRESS of science and useful arts
This fails the promoting progress requirement.
Not, if you measure "the progress" by the revenue/profit.
Copyrighting APIs makes no techinical sense, while copyrighting maps and manuals does.
The only thing remotely plausible is patenting APIs. And even that I'm not sure technically feasible.
I've witnessed probably man/centuries of wasted efforts due to crappy APIs - and I've seen single-person projects springing to life and seamingly leveling mountains when the available APIs were good.
Some APIs fit the puzzle of any applications - some force projects as a whole back to the drawing board.