Cue...
...masses of rage quit statements.
systemd
on Monday The Ubuntu Project is set to move forward with a plan to make a controversial system management tool a key part of Ubuntu Linux. On Monday, March 9, the Ubuntu maintainers will reconfigure code base for the forthcoming version of the OS so that it uses the much-debated systemd suite of tools to handle core initialization tasks …
I'm gonna rage-quit in style: torrenting "Win ME" right now. Once those old-skool installer splash billboards start popping up I can relax a little, put a rant about "Lucas just raped my childhood" on my GeoCities site, and start planning my millennium party (obviously NOT inviting anyone who looks bored when I re-re-reiterate that it's on December 31 2000 because there was no "A.D. 0"...)
"Debian uses it"
At present only in testing. Anyone who is using the current Debian is still using SysV.
The difference between upstart & systemd might not be reckoned as big as that between SYsV & upstart depending on what you're trying to do. I recall trying to work out why a Ubuntu box I was setting up to run MythTV worked fine on a monitor but went into extreme letter box mode to display live & recorded TV on my real TV. I wanted to put debugging statements into the graphics start-up script to find out what the hell was happening but due to upstart the entire script was removed. It's one of the reasons why I left Ubuntu for Debian.
> Don't forget to email corrections@theregister if you spot anything wrong - you'll experience massively lower post-publication correction latency.
Well, they do not want you to fix it or they would have sent the correction request. They want to appear knowledgeable in the forums. This again means that it is in their best interest for you to fix the issue as late as possible ... most other people who spot the issue will jump to the forums, see the post and upvote ... ;-)
"Debian uses it"At present only in testing. Anyone who is using the current Debian is still using SysV.
Not actually true.
Systemd (and even upstart) have been available since at least Debian Wheezy (stable). It's just the default that changes in Jessie. (You can run Jessie with sysvinit or upstart if you want).
Even though the distro I use doesn't use systemd the main DE it uses is moving to have a systemd dependency in around 5 months, as we as a distro are trying to avoid systemd like the plague, and we can't use gnome for the same reason, it seems we'll use any DE/WM that doesn't need it as a dependency.
The distro: PClinuxOS, the DM, KDE.
Disclaimer, I am a tester for PClinuxOS
Ah, Edmundson from Telepathy. If someone within KDE was going to be sympathetic to s*****d, it had to be someone like him.
Telepathy is actually a good example of what's wrong with a certain new breed of "developers":
"Let's do this really fancy communication tool that can send all kinds of data everywhere."
"Cool. What encryption methods does it support?"
"Encryption? No, listen, this is really cool. You can communicate..."
"...in plain text, for everyone to see?"
"Look, we have plenty of stuff on our hands right now, if you want encryption you going to have to do it yourself!"
Sorry, I'm off to build a new house. I think I'll start with the roof.
As someone who's only dabbled in Ubuntu, and Ubuntu being my only real exposure to Linux, I'm not familiar with the ins and outs of it.
How does this change affect users like me who aren't likely to be overly concerned about what's going on in the background as long as it does what it's supposed to?
it'll make booting a little faster because it uses an optimized and centralized binary configuration in lieu of the old init scripts and runlevels. if you're not running a desktop and you want to tightly control the services on a server, their runlevels, and their start order, then that binary configuration will, at least initially, have a higher learning curve than the older, more comfortable init scripts.
"if you're not running a desktop and you want to tightly control the services on a server, their runlevels, and their start order, then that binary configuration will, at least initially, have a higher learning curve than the older, more comfortable init scripts."
I thought that was the reverse of the case. The init scripts (using a Turing-complete programming language) are too much like hard work for the windows-trained admins so they have init scripts. And it's all dependency based so start order is automatically looked after. Don't tell me it's not really like that.
If, of course, you have some arbitrarily complex processes to run at boot the init scripting option is still there. For the present. Until somebody potters about and removes it. Then what started out as an open source Unix-like system finally becomes an open source Windows-like system.
no, the init scripts are not too hard but they are all basically the same content so there is a lot of files with duplicated code which seems daft. Plus the SysV init systems on Redhat, opensuse, arch debian etc were all slightly different in implementation and file locations so you couldn;t just move use one script across all systems without modification or learning new stuff. with systemd the startup with be common to all distros that use it i.e. making life easier for the admin that has various OS's to maintain. Plus, if you want to still use your init scripts within systemd, you can just configure to to use them.
My booting was slowed actually. I ran a bunch of services on my desktop system: mysql, postgresql and Apache. The default behaviour of Debian was to start things in parallel and X came up when it came up. With the move to systemd, every service had to be running before X was started. That was like me waiting for every server on the Internet being up before I could get a working desktop... It took twice as long to get a working desktop, just like the days of XP...
It turns out, I had to tell Debian's sysvinit scripts not to run my services and to tell systemd to start those services after my desktop was up. Otherwise, any tweak I did to systemd was ignored as systemd created virtual configurations based on the sysvinit scripts. This was not really a problem of systemd but Debian's implementation of it. On Debian, systemd creates a bunch of *.service files based on what it finds in sysvinit stuff. Many hours of my life was wasted finding this which was revealed to me in a discussion on the web. As the flagship consumer-distro, I hope Ubuntu does better. A lot of people run databases and such to support complex applications and this will slow their booting.
I had the same problem (2 minutes waiting for iSCSI , WTF?), but being patient is part of being an experienced user!!!
I am also using Ubuntu (dell xps 11) and so far it has a much more "apple" feel to it.
This is not a troll, but I see where they are going with it...
P.
"How does this change affect users like me who aren't likely to be overly concerned about what's going on in the background as long as it does what it's supposed to?"
Mostly not at all. You may notice the improved boot speeds, which are one of the main reasons it's being adopted, but otherwise the transition is effectively seamless and most of the other effects (whether you consider them to be harmful or not) are invisible to the end user.
"Mostly not at all. You may notice the improved boot speeds, which are one of the main reasons it's being adopted, but otherwise the transition is effectively seamless and most of the other effects (whether you consider them to be harmful or not) are invisible to the end user."
This is my experience with clean installs of Debian Sid and of CentOS 7 on a testing laptop. I've not tried an upgrade from a non-systemd os to a systemd version yet. I would be interested to hear from those that have tried a distribution version upgrade in .deb land
>>I would be interested to hear from those that have tried a distribution version upgrade in .deb land
I have been running Debian testing for years now. I made the switch to systemd when Gnome would no longer shut down my PC.
Switching to systemd is as easy as installing the systemd-sysv package and rebooting. Migration done. (For those who feel less adventurous: install systemd and add "init=/sbin/systemd" to the kernel command line.)
What has changed? I can shut down from the Gnome/GDM menu again. Booting might be a bit faster (I never timed it) and I'm still adjusting to doing things the systemd way.
> How does this change affect users like me who aren't likely to be overly concerned about what's going on in the background as long as it does what it's supposed to?
As long as it does what it's supposed to, it probably does not affect you. It may even make start up a little faster, should you care about that.
The first problem though is that the sorry thing has suboptimal design (whatever little design has gone into it in the first place) and when it breaks (which it does) it breaks spectacularly, with little chance of getting things back on track by a normal user or administrator.
The second problem is that, looking at the code in the light of one's experience, it is going to become a giant mess and a maintainability nightmare down the line, very much à la Adobe Flash et al.
The third problem are the names: that Pottering guy is the perpetrator of PulseAudio--an audio system that promised kitchen sink and everything, which he released years ago and to this day it still doesn't fucking work. From what I've seen of the guy, if I were to call someone I don't know an idiot, I reckon he'd be near the top of the list. Another of the devs behind this, that Sievers bloke mentioned in the article, is indeed rather infamous for the rather deficient quality of his contributions to the kernel (when he was still allowed to send patches).
So in short, this change affects you in that you are receiving an inferior product.
>>"How does this change affect users like me who aren't likely to be overly concerned about what's going on in the background as long as it does what it's supposed to?"
It may well not affect you directly as an end-user (though it would make debugging your system yourself much more tricky). But it drags everything in that it touches making itself a requirement for more and more every month. It's now pretty much reached the point where it's a core and unremovable component. And that's dangerous. I forsee it becoming a big and ugly tangle that does GNU/Linux considerable harm in the long-run.
The thing to keep in mind is that this is going into 15.04 which is a development release, not an LTS (long term service) release. If you are just a user who wants his desktop to work, stick with 14.04. The next regular LTS release will be 16.04, which is more than a year away. By then, it will either be working properly or Ubuntu will know to put off the change over for another LTS release cycle.
In addition, I read a few days ago that upgrades to 15.04 will stay with Upstart, and unless there is a change in plan Systemd will only get enabled if you do a clean install. I suspect the combination of both 15.04 being a development release and, only clean installs getting Systemd means that only a small proportion of the Ubuntu user base will be getting Systemd in the near future. I suspect that result is intentional in order to get a larger but still limited number of testers who can provide useful feedback for any problems.
The Systemd developers (basically, Red Hat) threw their toys out of the pram a couple of years ago when Canonical (Ubuntu) wouldn't agree to be the first commercial enterprise distro to use Systemd as their default init system. Instead, Ubuntu have waited until Red Hat have eaten their own dog food and released it to their own customers themselves. Ubuntu got a lot of hate directed at them from the Systemd fanbois for that, but personally I'm quite pleased to take a conservative approach to this. I'll stick with 14.04 for now, and by next year we'll hear if RHEL 7.0 users are having problems with Systemd. If not, then the risk for Ubuntu 16.04 should be pretty low. If there are problems, well I'll be happy to let Red Hat customers be the ones to deal with them.
I'm not a big fan of Systemd, and I'm even less of a fan of how the Systemd developers operate. However, if they follow their usual path, those original developers will drop out of Systemd work to pursue something else that is newer and shinier, and the project will be taken over by others who do a major overhaul of the whole thing, toss out the crap that shouldn't be there, and make the rest work properly. So, the long term prospects are that things will all work out in the end.
"If you are just a user who wants his desktop to work, stick with 14.04"
Sure thing, as long as you're not foolish enough to try to install a simple thing like, say, libgtkglext1-dev on your reassuringly safe 14.04.2 - hint: it will either flat out refuse to do it or trash and dismantle half of your distro if you try to push the issue using aptitude..
"I'm not a big fan of Systemd, and I'm even less of a fan of how the Systemd developers operate. However, if they follow their usual path, those original developers will drop out of Systemd work to pursue something else that is newer and shinier, and the project will be taken over by others who do a major overhaul of the whole thing, toss out the crap that shouldn't be there, and make the rest work properly. So, the long term prospects are that things will all work out in the end."
Wow. It's funny to see someone say exactly what I've been thinking about systemd for a while now (actually I pretty much agree that the lack of captalization is rather stupid as well, so it should be Systemd).
Basically it's the Borg. Intent on spreading its tentacles into all areas of the Linux system, even when there is no need for it to do so.
Secondly Poettering and co. seem to have taken a liking to the Windows registry and are hell bent on imposing that way of working. i.e. the binary logs and so on.
Thirdly as has been said, systemd shares a nasty trait with Pulse audio, it needs a reboot after installation, just like Windows stuff. I always thought that Linux was better than this and in my opinion is a huge step backwards.
I'll stick to PCLos thanks.
>>"Secondly Poettering and co. seem to have taken a liking to the Windows registry and are hell bent on imposing that way of working. i.e. the binary logs and so on."
Ha! It's far worse than that. What systemd does is create an inferior version of the Windows registry. Top that for a bad idea! :D
MS have had two decades to hammer the registry into something serviceable. It ties into Windows ACLs for security and it's also optional for developers as .NET applications have an XML format for their configuration that is (I think) preferred. Poettering is trying to create a Windows XP version of the registry! Think about that for a moment and feel afraid.
To me it's like Saruman looking across to Mordor in envy and trying to create his own little dark tower in emulation. The only difference being one continues to wear the white robes of Open Source whilst they lock everything down and breed orcs. "One startup process to rule them all, one startup process to find them..."
Secondly Poettering and co. seem to have taken a liking to the Windows registry and are hell bent on imposing that way of working. i.e. the binary logs and so on.
Do you know the difference between your arse and your elbow?
If so, why don't you seem to be able to understand the difference between a log file and a configuration file.
systemd does not have a binary registry. All its configuration files are simple text.