Grab your pitchforks: Ubuntu to switch to 
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.
in some sense i've been on both sides of the "to systemd or not to systemd" fence in my own life. to wit: I used to only manually install windows updates and I used to slipstream the service packs on my own windows install CD-Rs. i felt like I could guarantee my computer's flawless operation by making a decision about each security patch and by reading its kb article. after about the 5th year and the 300th buffer overflow description I eventually said "fuck it" and went with automatic windows updates instead.
in a sense, an admin who is still grovelling through /etc/rc.d or init.d and adjusting runlevels with vi or the command line tools is already behind the 8-ball. better to do that for a bit, but then use cfengine, ansible, puppet, chef, or func to provision a VM based on its role and just nuke the VM if it comes out wrong. immutable infrastructure is where its at - or where its going to be for a while.
Basically the way I've worked since 2000 (VMware Workstation v1.0.x). Docker is headed that way and there's been some kicking and screaming (CoreOS people) already. Given that the general trend is towards (near) total automation, your admins are going to be spending time getting the VM/container specifications right and doing the same with Ansible/Puppet/Chef (ad nauseum).
Those of us that really, really love to get in there and tinker, much like the (classic) car buffs, are naturally going to kick and scream, down tools, and go off for a bottle of their least favorite alcoholic poison.
the reason systemd is being adopted by distributions is for compatibility and maintenance issues.
LP has a blog, if you can't stand to listen to him, try reading it.
The "vision" is the Linux - the kernel, systemd - the system interface and BTRFS the filesystem will allow per-process isolation and (with BTRFS snapshots) per-process binary dependency resolution.
My complaint is the opaque logs - I see the login, but this is my whine.
The distributions have realised that Linux needs to simplify its deployment profile (i.e. simpler), and believe it or not , systemd helps that.
P.
Good way of putting it without any of the evangelical bullshit that both the pro and anti systemd camps put out.
Personally, I stopped using Linux about a year ago in favor of *BSD for my UNIX-like environments, but systemd wasn't the reason. Hell, I liked systemd (as much as one can like an init system anyway), at least the way that Fedora had it implemented worked well and was easy to fix when something went stupid.
I never understood the irrational hatred for it except that it always seemed to be coming from bitter old neckbeards who are still debating emacs vs vi, still think Hurd will eventually work well, call anything to do with Linux "GNU/Linux", and are still waiting for Linux to displace Windows on the desktop because it'll really be any day month year decade now.
"My complaint is the opaque logs" I think this is most peoples problem but they invent lies about loads of other things around systemd to try and make the issue bigger. i've not got a problem with binary logs, if a file is corrupted, its unreadable no matter what format its in. The journal viewing program is brilliant.
"My complaint is the opaque logs" I think this is most peoples problem but they invent lies about loads of other things around systemd to try and make the issue bigger. i've not got a problem with binary logs, if a file is corrupted, its unreadable no matter what format its in. The journal viewing program is brilliant.
Unless the corruption is significant, text files are easily readable up to and after the corruption. You can corrupt 20% of a text file and easily read the remaining 80% (perhaps unless the corruption involves numbers you actually need - but the remaining 80% is still readable). You could corrupt 90% and still read it.
But a single bit being flipped in many binary files is enough to throw the whole thing out.
Another issue with the binary logs - where I live I don't currently have a landline. I have an ancient cell phone that is my main source of internet at home (tethered), so connection speeds are down. Much better at work of course. I maintain a small number of headless web, email and file servers - no graphical displays or anything like that - such probably would be a hinderance (scuse spelling, for some reason spell checking isn't working in FF for me on here!) as I do find it a lot easier to work without clutter. I also fix Windows systems for a living so I am well familliar with gui-based systems.
Being on a poor connection and not being able to easily read and search logs or configs would be a problem, and re-drawing the screen with large amounts of graphics is a waste even with todays bandwidth - what if the system that has a graphical interface has a runaway process that either is chewing up the CPU or the desktop is locked? At least with CLI on most Linux systems even if the keyboard is locked you can get in over the network with SSH in my experience.
(The logs and config may not be an issue with systemd if it has a decent text-mode viewing program - I honestly don't know!)
(The logs and config may not be an issue with systemd if it has a decent text-mode viewing program - I honestly don't know!)
journalctl gives you pretty much what catting the log file gives. It also has various options for filtering the output, or printing in reverse. Still learning my way around systemd, but it clearly seems to be the future: enough large distros have decided in favour of it, so one either has to get used to it, or switch to some other OS (if you want BSD, you know where to find it), or some niche Linux distro. (No doubt holdouts will remain for a long time).
(where is the Borg icon?)
> enough large distros have decided in favour of it
Err have they ?
AIUI Debian haven't decided in favour of it, more like determined that they don't have the resources to fight it ! Saying Debian have decided in favour of it is a bit like saying that Aron Ralston decided on having only one arm (cf 127 hours).
Debian have stated up front that they simply cannot reverse engineer out the dependencies of certain packages on systemd before the next major relase - but they plan to for the one after that. My worry is that once it's in there, more and more stuff will depend on it (because it's there) and the job of untangling the mess will just get harder and harder.
So far I've seen a lot of arguments both ways, still to see a reasonable argument as to what it fixes that actually needs fixing, and the more I get to know about it (and the devs behind it) the more I want my servers to remain free of it. I like my servers stable and reliable - and if they do fall over, fixable.
If I wanted Windows levels of bloat, complexity, opaqueness, etc then I'd run Windows. Hint, I don't run Windows.
If any of the packages I use gains a systemd dependency then it'll get a bug report - though I suspect I'd have to be really quick to get in first with that.
>> enough large distros have decided in favour of it
>Err have they ?
>AIUI Debian haven't decided in favour of it, more like determined that they don't have the resources to fight it !
I never said _all_ large distros, just _enough_ of them. Including the most commercially significant Red Hat (and its derivatives), and SUSE/OpenSUSE, and now it seems also Ubuntu. Sure there will be non-systemd distributions, which is fine, in fact desirable, to avoid monoculture. But it is now clear that those who work with Linux in their day job (like me) just have to learn the ins and outs of systemd.
journalctl gives you pretty much what catting the log file gives. It also has various options for filtering the output, or printing in reverse.
Well, that stuff could be useful occaisionally. Something to bring the relevant sections of various logs into order could also be nice (trying to track down a problem with the mail server, but is it the imap server, firewall, authentication or something else that is wrong? Would be cool to read the logs in one sequence! :)
However, what I know of it so far (and what I've read from it's main promoters own hands), Systemd (does the "D" stand for "disrupt" or "destroy" or somesuch?) still makes me quite nervous. Over the years many things (and people) have done that. Sometimes I've been proven right, others wrong. if it turns out to be good then my thanks to the writers. If not, then may the whole thing blow up in your faces ending your careers in computing, but not doing any real harm to anyone else.
"(The logs and config may not be an issue with systemd if it has a decent text-mode viewing program - I honestly don't know!)"
That's the point a lot of people are complaining about.
Why have to have a tool, which adds complexity, to do something that all the original needs is a pair of eyes and a bit of knowledge to see what the problem is.
This is all getting out of hand, both literally and figuratively. Complication piled on top of complication. A real mare's nest and here I was thinking that obfuscation in coding was something that only black hats or competitors in the the IOCCC Competition used!
I reckon that if Poeterring and Sievers were to enter the IOCCC they would be a shoo-in to win. They have good form.
The other thing that irritates me is the fact that systemd is being shoved down our throats, like it or not. Thank goodness for the likes of Slackware, Devuan and PCLinuxOS. They have so far avoided systemd like the plague but I do worry that the borg-like tendencies of systemd eventually mean that there will be no escape. 'Resistance is futile. You will be assimilated'
And I always comforted myself on knowing that if you disagreed with or did not like a particular distro there was always an alternative. This may not be the case in the future. Guess I will have to start learning the ins and outs of BSD. They are safe as systemd is very firmly "linux only".
i've not got a problem with binary logs, if a file is corrupted, its unreadable no matter what format its in. The journal viewing program is brilliant.
Jesus wept. What the fuck is wrong with grep and tail that they need to be re-invented in to specific single use programs?
GNUs Not Unix, and getting more not unix as time goes on. Where are the small sharp tools, the programs that do trivial things in isolation?
I mean something that handles UTF-8 but just boots off a simple shell script or a normal init. One that doesn't have Network Manager, but shell scripts for that.
Just something that works without all the crap that just takes up your nerves when it doesn't work and won't provide you any usefull functionality when it does.
That is the vision.
Look for everyone running Windows and MacOS they have the monkeys and gnomes at corporate central to keep the leaking ships floating.
GNU/Linux (to give it the proper title) is the most adaptable computational environment ever devised by humans. This causes a problem, hence distributions try and do the "bilge pumping" to keep things running together. I have have had most luck with OpenSuse, but I am running Ubuntu and Debian on different machines. The point is >90% of the software is identical, but has little tweaks caused by the inevitable "historical changes" problem - that git has largely solved, btw.
The vision that LP put forward makes sense when you understand the power of dedup technology that has been available in enterprise environments for 20 years (?), and ability to present unique views of data with large amounts of common material, but also copy-on-write saving just the changes.
This buys 2 major advancements. Debian/Redhat/Ubuntu/Opensuse/Arch/etc.. can all release their distributions that work as expected. But if ,say, Ubuntu has a version of a tool that is more advanced or solves a problem it would be possible to add *just* that tool to any other distribution and ALL of its dependencies by essentially mounting a "snapshot" of the correct components.
When you consider the recent addition of live-kernel patching it is apparent (to this amateur) that a great deal of stability is possible when solved problems can be retro-applied to distributions with out messing with package managers.
Hence, you will be able to instantly boot into ANY linux distro with ANY collection of tools of ANY patch-level and it will just work.
I had coffee this morning, not cool aid....
P.
"Look for everyone running Windows and MacOS they have the monkeys and gnomes at corporate central to keep the leaking ships floating."
Yes, but why should Linux get those leaks, too? I mean I'm sorry, but if your application is so complex it needs so many components you want to put it into a container, maybe you should reconsider your design.
Believe me, those things will be the "leaking ships" of tomorrow. Linux was only able to reach its current quality because people adhered to the Unix philosophy which reduced the effort to build and maintain an operating system.
"Look for everyone running Windows and MacOS they have the monkeys and gnomes at corporate central to keep the leaking ships floating."
"Linux was only able to reach its current quality because people adhered to the Unix philosophy which reduced the effort to build and maintain an operating system."
Have you tried Windows and Powershell 4 or 5? It's a lot more efficient and powerful than UNIX / Linux based shell scripting these days.
My point is I have seen those videos where people try and call him out and he is a very smart talker. But reading his blog and actually reading supporting material it is clear that there is an evolving "vision" and the detractors seem to be unable to comprehend this - it really is a dialog but the status quo is no longer sufficient.
I think (just my opinion, no evidence) that it is due to the nature of *nix. A great deal of baggage has been brought from the failed attempts to emulate Microsoft (I'm looking at you IBM/DEC/SGI/SUN for the deliberate obfuscation and attempts to nickel and dime customers for support - Oracle knows this).
The flame wars are because some people have the "it works for me" attitude to system maintenance. Distributions need to stay relevant and it is no accident that Redhat/Ubuntu and Opensuse have been using systemd for a while - keeping so many version of software working smells suspiciously like an NP complete problem!
I'm currently using Debian wheezy/jessie/testing and it works just fine, with one VERY annoying, stupid,crass bug that I found the solution to on the Arch wiki. Systemd apparently manages X sessions and if you don't set it up right, typing on the keyboard gets broadcast to all consoles.
See what I did there? I found something infuriating about systemd, found a solution from a completely different distro, and now the problem is solved.
Microsoft and Apple are not the enemy, they are just out for a profit at your expense.
Support for FOSS in whatever way you feel comfortable is the only way to bring the amazing advances in computing to benefit the world at large.
P.
I must say I kind of agree. Hence, I had to read on the Arch wiki that in fact it is a very cool feature.
This is all the files I had to change to configure a multi-seat system (I have 3 monitors, one is dedicated console). By default, systemd will generate consoles AS NEEDED. Hence, you need to tell it where to stick X.
###add to bash_profile or equiv
systemctl --user import-environment PATH
export XDG_VTNR=7
###Contents of user systemd config (yes that is PER USER!!!!)
ls -l ~/.config/systemd/user/
total 8
-rw-r--r-- 1 phil Feb 9 10:10 xorg@.service
-rw-r--r-- 1 phil Feb 9 10:08 xorg@.socket
### A look inside xorg@.service
[Unit]
Description=Phils Xorg server at display %i
Requires=xorg@%i.socket
After=xorg@%i.socket
[Service]
Type=simple
SuccessExitStatus=0 1
ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"
/home/phil/.config/systemd/user/xorg@.service (END)
##### END #####
My only complaint is the solutions to all these things are not major, but come under the heading of "fiddly". Not unlike configuring this first Android phone of mine.. (Moto-E 4G/LTE Android 5.0.2).....
For those not familiar with the init scripts way of doing this, this method gives each USER a specific method for setting up a session, connected to a specific input.
P.
RedHat has just starting systemd in version 7 and as far as I could tell from my experience, it will take a few good years before this version will get deployed in medium/large enterprises. In case you're not familiar, enterprises are used to standardize on a certain version of an OS in order to avoid maintenance headaches (this is why RedHat 5 is still supported) so you should know it takes a lot of courage to migrate hundreds of servers to the latest version just because it boots faster. Usually it's the end of support that forces the migration not the new features (as a clue, look at how much WindowsXP and Windows Server 2003 are in use right now and how keen are the enterprises to move to the latest platform).
The security implications of that sort of thing scares the s**t out of me. What else might it be trying to (mis)manage??
I'm old enough to have a very long grey beard. In fact I haven't. I'm relatively new to 'Nix, drawn, no driven, to it by the unreliability and obscurity of another well known system.
I'm not talking about open source code here - I've come to hate things that try to do everything and hide what they are doing and why. That's not simplification, it's obfustication. Which makes understanding what's going on and fixing it when it breaks more difficult.
"The security implications of that sort of thing scares the s**t out of me."
Whilst Linux still uses security bodges like SUDO, still uses text based config files which by nature can't have fine grained auditing and ACLs - and still doesn't support basic security features like constrained delegation, there are far bigger potential problems to worry about...
"But reading his blog and actually reading supporting material it is clear that there is an evolving "vision""
Having a vision is a good thing, otherwise you just go around with no idea of what you want to achieve.
Imposing that vision on everyone regardless of the arguments against it and intemperate rants about people who disagree with you is not.
Poeterring comes across as an arrogant know-it-all with a lot of growing up to do. He treats those who are not slavish followers with contempt and then has the brass-neck to call them names such as "assholes" when they demur. Not in my opinion the way to make friends and influence people.
Which ones did you try?
Mint and Manjaro seem to be just fine.
Seems to be especially ok if you use them with KDE as dekstop.
And you might be surprised that they have features you would not dream of if you still use Windows.
/Zane
I use both, not-so-new Debian without systemd and Arch with systemd. I like both, can't really say much bad about systemd (well, binary logs are one thing ...).
The trouble I have with systemd, is that finding and installing a distribution without it is becoming more and more difficult. Given that Debian is a root project for quite a few distributions, this has become even harder.
But then, I knew it was coming, which is why I'm sending money to devuan.
> It's trying to "improve" on Unix with things like Network Manager, or dbus which may be usefull for some very exotic applications, but just make lif harder in the most common situations.
Hey! Hang on! I actually sort of like DBus. OK, I'm not a big fan of it being non-network friendly but I understand it was a design decision to not have to deal with latency issues. And I'm sure it could be made a bit less obfuscated, but for the rest it's been useful to me.
So what is wrong with DBus from your point of view? And what would you recommend instead?
"So what is wrong with DBus from your point of view? And what would you recommend instead?"
Well first of all it uses libraries for something non essential. Which means that if the DBus daemon doesn't work, your system will behave in very odd ways.
Then I haven't been able to find any sensible reason for it. I mean why should desktop applications be able to send messages to each other? The only places I have seen that in use is those anoying "popups" telling me things I already know and USB MSDs being mounted without my consent.
So far the net benefit of any system like DBus for me as an end user seems to be negative, but particularly since it's implemented as a library applications link against, there is no easy way to get rid of it. If it was implemented as a set of separate programs which would be executed by the software wanting to send or receive messages, it would be a whole different game. Then you could just delete that dbus binary and programs would most likely still work.
> Then I haven't been able to find any sensible reason for it. I mean why should desktop applications be able to send messages to each other?
Are you really asking why a desktop environment should have inter-process communications (IPC), or did I just misunderstand you?
> since it's implemented as a library applications link against, there is no easy way to get rid of it. If it was implemented as a set of separate programs which would be executed by the software wanting to send or receive messages, it would be a whole different game.
That is exactly how DBus is implemented. The library that you mention (libdbus) is just there to abstract away the details of sending and receiving messages. You can most certainly still use DBus without it, would you be so inclined (you'll be in for some serious pain), and programs linking against libdbus will still work in the absence of a DBus session or daemon if they have been designed correctly and IPC is not a core requirement.
I should know as I have written software using DBus. Examples of what I have done are equipment monitoring clients (will tell anyone interested if certain equipment that your computer communicates with starts to fail or logs certain events), and also for an application that performs scientific computations--other programs can request the results directly from the application via DBus, saving the user from having to start a front-end, input the data, extract the results, and feed them back to the other app. More trivial things include logging out users from the intranet portal when the screensaver starts on a public kiosk (people will often forget or not have time to log out--this being at a fire station) and stuff like that.
It seems to me that your gripes are with how programs use IPC, rather than with DBus itself.
"But then, I knew it was coming, which is why I'm sending money to devuan."
If I thought it stood a chance I would too. But I think more & more package developers are simply going to assume that systemd & friends are there & use some of their APIs. Eventually so many packages will need adapting to run in a systemd-free environment that it won't be possible to cope unless, of course, devuan succeeds to the point where it becomes the main Linux distro. I think those of us who want to keep using a Unix-like environment will migrate to one of the BSDs so I doubt that that would happen.
Hackers will find a way to edit binary logs, or simply delete them. Remote logging is the proper solution for that.
Huge text logs are actually pretty manageable. If they're up in the gigabytes range, you're probably running a huge internet empire and already remote logging to a central cloud database. But that's overkill for the other 99.9999% of users.
The trouble I have with systemd, is that finding and installing a distribution without it is becoming more and more difficult.
Uh, it's pretty easy. It's called Debian.
systemd is the default init process for Debian Jessie. It is not the only init process. If you don't want use systemd you can use sysvinit, upstart or maybe even openrc.
But then, I knew it was coming, which is why I'm sending money to devuan.
Beware -- you can't send money to Devuan, they have no "official" existance. You can send money to Dyne.org, but some people consider then scammers.
How many times do you need to boot. Almost never, IME.
Laptop: I use whole drive encryption to avoid data theft if I leave this machine on the bus/train/ or under pub table. Therefore, I close down or hibernate to disk between work sessions. Several times a day. Can't say I notice a lot of difference between Wheezy and Sid though...
Servers: I gather virtualised servers can be spawned, configured and spun down when not needed more quickly with systemd. I have no experience in this area and would welcome views
I've heard the "improve boot speed" statement quite a few times, but I've never seen any real evidence that Systemd* does anything to improve boot speed. Indeed, when Fedora switched to Systemd, they still had the slowest boot speed of any of the major distros, slower than SysV init, Upstart, or anything else.
Boot scripts aren't really much of a bottleneck because you're normally just waiting for the peripheral hardware and disk IO anyway, not CPU or RAM execution speed. Lately, the Systemd proponents have been taking the line that "nobody really cares about boot speed anyway". The real benefits of Systemd supposedly revolve around simpler init configurations and better tracking of child processes.
* - In real English proper names are supposed to capitalized and marketroids who insist on 'edgy" spelling with lower case can stuff it in the same place they keep their heads.
>* - In real English proper names are supposed to capitalized and marketroids who insist on 'edgy" spelling with lower case can stuff it in the same place they keep their heads.
I agree with you up to that bit, where while I share your disdain for "marketroids" (is that as in "Heavens to ..." ?), I think it's a little misplaced here. The non-title-casing of programme names in the *nix world (the low-level, meat'n'potatoes ones anyway) is something that's been a general convention throughout the 11-some years I've been paying attention. It's more the desktop apps with enough status to have actual "branding" that tend to start demanding title-case or some other weird case rules or pointless stylistics. (Witness OpenOffice.org - ridiculous, and made it ten times harder to convince cash-strapped relatives that it was a serious thing.)
Believe me, I speak as one of the biggest Correct English Nazis you'll ever meet, but you can only carry that so far into the land of CS jargon. They still won't hear a word against "automagically" :(
To steer a wee bit back on topic, hunt around Phoronix a bit (Larabel has been milking the systemd clickbait more than anyone) and you'll see the proponents get terribly upset about people writing it as "SystemD" or such, mainly because they are sticklers for the very antilinguistic conventions you reference in reverse. And I assure you, these are not marketing types.
I seem to be under the erroneous impression that hardware was getting faster not slower ....
Most Linux distros are designed to "just work" in as many senarios and on as much hardware as possible. Which is generally a Good Thing (TM).
If you know what hardware you are using and what you want to do my understanding is that if you hack the unneeded stuff out of the kernel and limit what's going on in the background that you'll never need or use you'll shave quite a bit off boot time and get a faster system as well. Which is what some specialist distros do.
I think the boot time claim with systemd is a large red herring. It may have been an aspiration at the beginning, but the way this thing is bloating like a decomposing whale I wonder what the actual position is today. Anyone done any objective comparisons?
Anyways,I really don't want it near any of my systems when it explodes.
Correct
Is improved boot speed really something that most linux user wrer waiting. Most installs are for servers which are up 24/7. My ubuntu desktop is also up 24/7. Not quite sure what the big deal is on boot time, other than to sell this, in which case I scared this will end up windows.
More often with systemd than without, I think. My practice of upgrading to Testing a year or a bit more after a release hardly ever led to unplanned (e. g., kernel upgraded) reboots - until I enabled systemd after upgrading to Jessie. To be fair, it may be simply that this testing release is a bit less stable overall than previous ones. However, it has been much more of an annoyance than I expected based on past experience, and I suspect without being in position to prove it that it is due partly to systemd.
I suppose if current Linux developers bothered themselves to learn from properly engineered OS it would save lots and lots of time for inventing square wheels and spend years trying to make them work
Containers, game changer !!! Bah, had them in 2007 on Solaris.
BTRFS, instant snapshots, deduplication !!!! See above, ZFS.
Replace Sys V init, it's too old and slow !!! - Again see above, svc
Incompatible packages !!!! - Solaris binary compatibility since 20 years old version FFS.
What else was there ? Name it and I'll show you 10 years old much better implementation.
Linux n00b nazis down votes to follow in... 3..2..1
To clarify, I am using ZFS. I *was* using BTRFS but my luck picked a bug that did not survive on my system....
ZFS is fantastic. Really it is. But it is NOT part of the linux kernel. It is an external project and therefore takes effort to maintain.
Hence, it is wise for BTRFS to be developed in parallel so that the GNU-linux environment can be developed and published under the same GPL license.
You will get no argument from me that the DECADES of previous stuff was well tested and works sufficiently. But it is also falls in to the category of "ad hoc". The vast array of hardware that is now available makes it clear to have largely the same kernel running on a phone and a supercomputer shows that *something* needs to simplify the application stack.
P.
zfs-on-linux is not prime time, because the guys who run the zfs-on-linux project mainly care about storing vast amounts of archive data, they don't care much about performance, so caches aren't unified and other performance issues.
If you want to do interesting things with ZFS, you're using Indiana or BSD.
btrfs is a joke. It's been "the next thing" for many years, but it still doesn't match even what ZFS had 5 years ago.
Let me just say that I started working with ZFS in 2007 and every year since there were few major bugs with nasty consequences, mainly because how complex it is. Yes we probably do push it harder than 99.99% of other users but idea of trusting hundreds of terabytes of data to community of programmers with unknown skills, absent quality control, non-existent testing and zero responsibility terrifies me. Thanks, but no, thanks.
Ubuntu Touch won't switch because of the "ancient" kernel it uses? Well, there's a problem right there... pray tell, what special kernel services should you possibly need to start up various processes and daemons, resulting in a booted up system? This isn't a trick question, the answer should be "none".
To be honest, I'm not ready to flip out over systemd. The descriptions of it really do sound like it has significant boneheaded design decisions that directly contravene doing things "the UNIX way". The thing is though, if systemd performs well, and doesn't have loads of crippling bugs (which are usually misrepresented by proponents as "it's fine, you just have to set it up JUST SO for it to work"), then I guess it's not a big deal to me. The reports I've heard of it did not sound particularly positive in this regards; however, pulseaudio went from being effectively a steaming pile to being reasonably useable though, so I suppose systemd can get there too if it's not already there.
Edit: Binary config file? BURN IT, BURN IT WITH FIRE!!!
> pulseaudio went from being effectively a steaming pile to being reasonably useable
??? Reasonably usable??? Have you ever tried to route sound over the network, which was the whole selling point of that utter piece of shit.
> though, so I suppose systemd can get there too if it's not already there.
Let us just say, when people think of German engineering, they are most certainly not thinking of Lennard Fucking Pottering or whatever his name is.
What's your problem AC? I am routing sound right now over 2 networks. (Bluetooth and wifi).
There is a nice gui tool to help you called "PulseAudio Applet"
if you install padevchooser it should bring in the dependencies.
A word of warning, if you want to use your LAN to stream audio, you may need to open a port on the firewall.
P.
It's a bit pessimistic to assume that systemd will be bad for Ubuntu. What if Ubuntu ends up being good for systemd?
Sure, it's a dog's breakfast at the moment -- but so is most software when it starts out. If anybody can lick systemd into shape, the Ubuntu developers can.
Once Microsoft decided they wanted to improve boot speed, some Linux people started worrying about it too, not wanting Windows to be able to boot faster than Linux. It is ironic that by the time systemd was made the default in Fedora, SSDs had taken away the win for systemd, was there was no longer a seek or rotational latency penalty when accessing a bunch of little files.
Once Microsoft decided they wanted to improve boot speed, some Linux people started worrying about it too, not wanting Windows to be able to boot faster than Linux.
Boot speed is important in many cases. Think cloud where you might set up a server very frequently. Or an embedded system where you want the device to start working as soon as possible after being turned on. (I just hate it how my shiny new flat-screen TV takes more time to become viewable than the old B/W valve-based TV from my childhood! - that at least had a good excuse for being slow: all the valves had to warm up first). Yes, SSD makes handling lots of small files more tolerable, but not having them in the first place is faster still. Another problem with traditional init is the large number of process launches that happen while processing the scripts. Process set-up eats CPU. Systemd avoids this, too.
"Why should I give half a shit about whether systemd is used on the distro I use for my home computers?"
Same answer as to previous similar questions. Not at all until something goes wrong at boot time. Then you find the logs are binary (unless you adopt the keeping-a-dog-and-barking-yourself option of exporting them to ASCII and unless the something wrong included that bit not working). And you find, as I did with Upstart which is similar in this regard, that there's nowhere to insert debugging statements.
Essentially what we are seeing with Linux now, is probably a mirror image of what we have seen happening to browsers. During their existence browsers have turned from fairly simple systems to huge applications. Today Firefox is so large it needs a whole corporation around it. Such a corporation needs to get funds and it has its own interests. Most of you will probably have suffered from decisions that corporation made. Normally it would have been forked years ago, however since it's so incredibly complex (because of complex web standards) and changing rather quickly (because of changing web standards) that's near impossible.
The same is currently happening to the Linux Desktop. Instead of keeping it nice and simple, we add layer upon layer of complexity. Suddenly we have inter process communication, audio daemons, consolekit (whatever that's for) and now systemd. Each one of those sub systems adds complexity and dependencies.
The dependencies keep you from removing those parts (try installing even the simplest desktop system without D-Bus) and the complexity keeps you from maintaining a fork with reasonable efforts.
Who benefits from this? It's probably, at least in the short run, the enterprise Linux vendors. They have lots of resources and this will make it harder to use Linux professionally without service contracts.
To contrast this the BSDs have a lot less developers, sure you won't get any fancy features, but they are able to maintain a whole operating system, including daemons, with a fraction of the development cost.
Whilst I agree with you overall Firefox did start from a corporation: Netscape. And it was actually forked from the Netscape suite which has been continued in open source form as Seamonkey.
But let's be grateful to those who carried on with open source Unix in the form of BSD.
In many ways systemd is only a symptom that finally showed clearly how Linux is not Unix and now is not even pretending to be anymore. With systemd basically becoming the svchost of Linux, Linux is actually trying to pretend to be windows now. Good for RedHat's bottom line what with more FOSS to become Linux only but just makes one grateful that *BSD is still around even if less and less software will port to it over time.
Out of the impression that they switched to SystemD with Unchanging^H^H^H^H^H^H^H^H^H^HUtopic. So far, it has broke the statistics screen that's supposed to pop up when you log on as root. That, and a painful 5-minute freeze that occurs at random when shutting down the machine. Other than that it seems to be okay- although I expect that if I do a text-only install and install a desktop later, I'll be in for it later given my experiences with Arch and OpenSuSE.
It is no surprise RedHat and other commercial Linux distros integrated this so fast, this type of fundamental changes revives their course and certification circus.
Having witnessed succession of AT&T System VR3 by the failure System VR4, better known as Solaris after SUN abandoned SunOS, systemd gives me creeps like System VR4 did 25 years ago.
Having to use commands with the whole alphabet on options to achieve the same as using easy to understand startup scripts and config files. It does not make sense and is not Unix like. Linus should have stuck up two middle fingers to that guy who made this, instead of only one.
If it is good or bad, it does not matter anyway, now all the commercial distros have adopted it, people in the field get it shoveled through their throat.
Honestly - reading all this bickering, forking, fudging, struggling and hating makes you realise that the average desktop / laptop / tablet user would not want to touch Linux or its variants with a barge pole.
/ Cue 'Actually its much easier than Windows, realllly' and/or 'Niche? it's in every washing machine!' style comments
//Yes I'm trolling. You deserve it.
"Like Android as opposed to Windows Phone?"
Android is just a flaky Java VM that happens to use the Linux kernel. Linux distributions are still relatively niche.
Windows still has ~90% of the desktop and ~75% of the Server market (as per Forbes).
>Windows still has ~90% of the desktop and ~75% of the Server market (as per Forbes).
And how much of mobile? I guess that would be why Apple has almost twice the revenue and more than twice the profit of Microsoft these days and even their market share isn't a majority of mobile. Shows where the big money is heading.
The last reliable version of Ubuntu server was 9.10. 10.04, and all subsequent Ubuntu releases, have the most unreliable boot process imagineable -- known as "upstart." I was a huge Ubuntu advocate until 10.04, now I hate it with a passion thanks to all the times the boot process pauses forever without any indication why or any way to fix the problem (it is still painful 4 years later -- for example try adding an nfs mount to /etc/fstab where the nfs server is having a problem).
I upgraded my Debian system to a version that uses upstart, and it was quite a bit better thanks to the sysvinit compatibility option. Maybe in the future it will be possible to count on Ubuntu actually booting up all the way again.
Might I recommend a recipe I'm using, it's a headless server only thing, but it works for me.
It results in a bootable image that one could run with qemu/ turn into an iso etc.
This means, I setup my server how I like it once, and I just turn the handle when I want another one.
It sounds like a fair bit of work and it is a bit of a faff but it boils down to write long shell script, once
It's not clever, it just copy's some files into place and pops out an image, but it works and it's easy to keep working for normal linuxy folk.
1) Take a debootstrap into a directory currently using 12.04LTS but any version will do.
2) chroot into the directory and start sshd
3) copy over some template files or for extra credit, use ansible to push a basic configuration.
4) create an file to use a loopback, the size of the chroot on disk + some extra (i use 200MB)
5) format the file to ext2, make it bootable.
6) mount the file to a loopback and rsync all the data across
7) install grub + a kernel
8) unmount the image.
9) quick check with qemu to make sure it's all good
10) dd the image onto a usb stick
"It's not clever, it just copy's some files into place and pops out an image, but it works and it's easy to keep working for normal linuxy folk.
1) Take a debootstrap into a directory currently using 12.04LTS but any version will do.
2) chroot into the directory and start sshd
3) copy over some template files or for extra credit, use ansible to push a basic configuration.
4) create an file to use a loopback, the size of the chroot on disk + some extra (i use 200MB)
5) format the file to ext2, make it bootable.
6) mount the file to a loopback and rsync all the data across
7) install grub + a kernel
8) unmount the image.
9) quick check with qemu to make sure it's all good
10) dd the image onto a usb stick"
Windows version:
1) Right click on disk and select format
2) Tick make bootable
3) Click OK.
Job done.
I have two related problems with systemd. The first is that it's getting larger and more complex every day and taking over functions of other programs seemingly for no real reason. It's not that this goes against the Unix philosophy that bothers me; it's that it goes against the reason for the Unix philosophy, delegation of processing and interchangeable parts.
That leads me to my second problem with systemd. There are many init systems available for Linux, but they have never been that contentious because you can always pull one out and replace it with another. Systemd seems to be heading in the direction that you won't be able to just pull it out and replace it with another init system. I don't see anything so valuable about systemd that makes it worth losing interchangeability. I don't even really see why it needs to lose interchangeability to accomplish the other things it does. Let it become the standard init system on the merits of its advantages rather than because my system no longer works right without it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
