Ubuntu 15.04 Released, First Version To Feature systemd

jones_supa writes: The final release of Ubuntu 15.04 is now available. A modest set of improvements are rolling out with this spring's Ubuntu. While this means the OS can't rival the heavy changelogs of releases past, the adage "don't fix what isn't broken" is clearly one 15.04 plays to. The headline change is systemd being featured first time in a stable Ubuntu release, which replaces the inhouse UpStart init system. The Unity desktop version 7.3 receives a handful of small refinements, most of which aim to either fix bugs or correct earlier missteps (for example, application menus can now be set to be always visible). The Linux version is 3.19.3 further patched by Canonical. As usual, the distro comes with fresh versions of various familiar applications.

Comments

SystemD added?

[Anonymous Coward]

Then it's simple.

"We changed everything."

No wonder it was short.

Re:SystemD added?

[TWX]

I don't see how the summary's, 'don't fix what isn't broken,' statement applies in this case.

Re:SystemD added?

[Calabacin]

It wasn't added. It has been there for a while. What's changed is that this time it's the default init.

Re: SystemD added?

[Anonymous Coward]

If I had mod points ...

PERHAPS someone could define what was broken so badly in init that the whole lot was replaced. I so dearly would like to know.

Re:SystemD added?

[dreamchaser]

It reminds me of those 'That's now how this works. That's not how any of this works' commercials.

Re: SystemD added?

[Anonymous Coward]

It's not that a single thing was broken, it's that the combined deficiencies were impacting software management. It's an evolutionary dead end. Systemd is being actively maintained and documented and implemented in ways that allow it to better interact with the free software ecosystem.

At its core, it includes a lot of fixes for classic init that you would have to implement separately if you use classic init.

Services are easily manageable.
Booting is compartmentalized to allow for easy debugging(Items report success or failure individually, in order, and with consistency).
Intrinsic functions and customizations are separated.
Items do not necessarily rely on other items' dependency lists to configure themselves in the startup queue.

System management is easier if services are manageable through a homogeneous interface. This effect trickles down to service creation, and then to package management. The distribution manages the packages, so it's in their best interest to pick an init that will help everything run smoothly.

If the qualities of classic init are critical to your use-case, there are always other distributions available.

Re: SystemD added?

[Anonymous Coward]

I just had a bootup of a laptop after what must have been a crash. Rather than fsck and check as under traditional init, it halted in systemd, because it had something to tell me. Which it didn't. So you log in to the single-user mode with a poor prompt (really, if you're asking me to log in, maybe you should *look* like a login). Then to see anything you need to run journalctl -xb. Nothing wrong with the disks as far as I could see. It seemed upset that there were a lot of logs in this boot. OK, so I reboot. And back to the same thing. You have to tell *it* to be OK that you've read the warnings. Then tell it to reboot. It being systemd.

      So it's a regression, just extra layers of failure to get through when you already have an issue. All the same tools still have to run, but someone has to tie them together, and no one has. That's plebwork apparently.

Re: SystemD added?

[Anonymous Coward]

Danger: systemd marketing droid detected..only line of worth in the twaddle spouted is ;

..there are always other distributions available.

To which you may also add, there are also other OSes available - you can directly thank the BS that is systemd for the fact that our management has migrated our servers from Debian to Win2k8..despite my pleading the case for Slackware and the *BSDs, so let me just congratulate you systemd zealots and say ;

'fsck you, fsck you very much..'

Re: SystemD added?

[Anonymous Coward]

Have you *reported* this regression? Has it received attention? Is there any indication if many others are suffering from this regression? (etc. etc.)

(Btw, why is "journalctx -xb" massively different from and worse than "guess-the-relevant-log-file-for-your-distro-and-hope-you-got-all-the-relevant-ones-and-do-grep-on-{something,something2,..}.log"? That's not to cast aspersions on your problem. The "journalctl" thing just stuck out.)

Re: SystemD added?

[warrax_666]

> Danger: systemd marketing droid detected

Oh, fuck off. Seriously, just fuck off.

(People are getting real value out of systemd vs. $whatever. It's fine if you don't perceive that value and you are free to articulate those concerns, but don't immediately accuse happy users of being shills, please.)

Re: SystemD added?

[Anonymous Coward]

I'll use systemd when it actually works. I certainly won't be using the first, second, or even third releases, since it's such a massive monolithic piece that puts tendrils everywhere. One of the nice things about init is that init driven services can also be run exactly the same way outside of init. This is not true of systemd type services. So, by that token, systemd is already a fail.

popcorn time as "people dropping ubuntu like " becomes the new hot meme for a month.

Re: SystemD added?

[Eunuchswear]

If I had mod points ...

PERHAPS someone could define what was broken so badly in init that the whole lot was replaced. I so dearly would like to know.

Ubuntu doesn't use init you moron, they abandoned it years ago.

It even says that in the summary.

Re: SystemD added?

[hitmark]

>Booting is compartmentalized to allow for easy debugging(Items report success or failure individually, in order, and with consistency).

Only to have it go "here is a login promp, you're on your own" because of vestigial line in fstab that the traditional mount would just present you with a error for and move on.

Re: SystemD added?

[Anonymous Coward]

What's there to report?

The regression is that systemd is being used.

The only fix is to remove systemd, and to revert back to the previous init system that worked.

Re: SystemD added?

[ZorinLynx]

A recent of example I had that made me dislike systemd was a prototype RHEL7 system here that has ZFS-on-Linux support installed on it.

When you boot it up, there's around a 50/50 chance whether the ZFS filesystems will be mounted after boot. This is an inconsistency that, as a long time sysadmin, REALLY BOTHERS ME.

Yes, I realize the root cause. ZFS has some dependency that is not starting before it. The dependency has to be declared in the appropriate service. However, with systemd we introduce the concept of "just because it came up correctly on this boot doesn't mean it will on the next one."

And that is supremely frustrating. What if it weren't 50/50? What if the likelyhood it didn't come up was 1/100? Suddenly a routine reboot becomes a debugging mission, and I reboot again and it works. "Eh, must have been a transient problem." No it wasn't.

With classic init you were fairly sure that the system's state was the same on every boot. Now it's a gamble. Good luck with that! This is why we're sticking with RHEL6 for the moment on production systems.

Re: SystemD added?

[hairyfeet]

Uhhhh...yeah dude? The post he is referring to used "compartmentalized", "intrinsic" and "homogeneous" in less than 3 sentences....normal folks and IT guys? yeah they don't talk like that. So the poster is either 1.- A shill, or 2.- Works in PR or marketing, because those guys DO talk like that.

Frankly I was shocked he didn't roll out "synergy" but I think they wised onto it thanks to Dilbert ragging on it so many times.

Re: SystemD added?

[Anonymous Coward]

I like that you correctly identified the problem as being with the ZFS dependency and then immediately blame systemd for that fault.

If you had a bad init script would you blame initd?

Re: SystemD added?

[emacs_abuser]

> One of the nice things about init is that init driven services can also be run exactly the same way outside of init. This is not true of systemd type services

How do I know, you haven't got a clue?
Any of the services can be run with or without systemd.
Systemd is just a launcher.

Re: SystemD added?

[cdwiegand]

No, it's NOT JUST A LAUNCHER. It's a logging daemon, a console input daemon, it's much, much more than just a launcher. So if for some reason (like power outage) your computer reboots, you can't just tail /var/log/* (or even specific logs, if you're familiar with your distro which most of us are). You have to use another computer to lookup some arcane command that's non-obvious (sorry, "tail /var/log/* IS obvious for anyone who has ever been a UNIX-world sysadmin), then you can proceed to fix the problem.

Now, personally, I'm willing to try it out on my laptop for awhile, and maybe, just maybe, I will consider deploying this in servers, in like 6 months after daily use by myself and my alternate. Otherwise we'll keep using 14.10 for now.

Re: SystemD added?

[cdwiegand]

No, because you would have already fixed the /etc/init.d/zfs file. And then you'd move on with your life, instead of googling "systemd dependancies editor" and going from there..

Re: SystemD added?

[Anonymous Coward]

it's just another Do What I Mean tool that doesn't let you manually repeat the steps. Just like NetworkManager - remember when you could use command line tools to get information about and manually configure your WiFi?

Re: SystemD added?

[Anonymous Coward]

So the problem is that you don't *know* systemd then - not with systemd. It's not like what you want can't work properly right?

Re: SystemD added?

[Anonymous Coward]

> Danger: systemd marketing droid detected

Oh, fuck off. Seriously, just fuck off.

(People are getting real value out of systemd vs. $whatever. It's fine if you don't perceive that value and you are free to articulate those concerns, but don't immediately accuse happy users of being shills, please.)

Looks like a member of the genus Oxyura, walks like a member of the genus Oxyura...

As someone else pointed out below, the language in the post I was responding to doesn't look like the typical ravings of a Unix/Linux server admin, it is more akin to management-speak drivel than anything else. Mind you, this is exactly the problem with the systemd brigade..

Oh, Btw 'happy users'? really?

y'know, the use of that phrase also speaks volumes..
I don't think I've ever sat in front of any system and said to myself;
' man, it's great to be a happy user of {insert any bit of systems software you care to name here}..'

Maybe, just maybe, on a good day I might be coerced into admitting that I'm moderately contented with the operations of kthread, I might, if plied with alcohol, admit to a small degree of pleasure in the (sometimes obscure) machinations of khungtaskd, but, I'm sorry, admitting to being a 'happy user' of an init system?
No, I think I'll just pass on that, that's just plain wrong and sounds a wee bit too 'cultish' for my liking..

Mind you, I'm a grumpy old bastard at the best of times...

Re: SystemD added?

[Eunuchswear]

Now, personally, I'm willing to try it out on my laptop for awhile, and maybe, just maybe, I will consider deploying this in servers, in like 6 months after daily use by myself and my alternate. Otherwise we'll keep using 14.10 for now.

You use Ubuntu on servers?

Re: SystemD added?

[gfxguy]

You use Ubuntu on servers?

We do. So what? Ubuntu has a server distribution... it works great, is easy to maintain, and we use it for internal (behind firewall) use. And?

Re: SystemD added?

[thegarbz]

in like 6 months after daily use by myself and my alternate

Far more importantly in like 6 months when the LTS release comes out.

Re: SystemD added?

[thegarbz]

I do. The minimal standard Ubuntu Server release is simple, clean, CLI driven, and for all intents and purposes looks and acts no different than any other distribution that uses apt for package management.

Oh and getting things working is really well documented. Fixing complex problems is better left to the arch wiki, but for the basics of trying to do something on a server you're almost guaranteed to find an Ubuntu specific guide somewhere.

Re: SystemD added?

[thegarbz]

Oh hate to double post but I have to say if your definition of arcane is "something I didn't grow up and become an expert in" then the argument falls flat on its face. Any UNIX admin should be perfectly comfortable with having to learn a few new commands. Especially since your idea of arcane is:

journalctl ---vs--- tail /var/log/*
journalctl -u apache.service ---vs--- tail /var/log/apache/* that is if apache has put it's logs there, otherwise you can have fun in the world of pipes and greps digging for apache entries in the general clusterfuck that is Linux text logs.

Re: SystemD added?

[thegarbz]

Ahhh the old fix something the maintainer should have fixed so that next time zfs gets a slight update my fix breaks and I go through the frustration yet again trick.

Editing an init script is never the solution to a problem unless you ARE the maintainer of the distribution. Your fix is just as likely to reoccur and result in a debugging session with init as it is with systemd.

Re: SystemD added?

[dbIII]

PERHAPS someone could define what was broken so badly in init that the whole lot was replaced. I so dearly would like to know.

Apparently not enough of linux userspace had Lennart's name on it.
It's being widely adopted because he's convinced a few gnome people to make their stuff rely on it and the gnome stuff is popular.
I really don't know what RedHat was thinking when they put someone who thought it would be a nice joke to call a frequently running process "rtkit" in a position of responsibility.

Re: SystemD added?

[dbIII]

The above can really just be summed up as "it wasn't all a single project, but it is now with systemd". Progress certainly did happen before systemd started and there was no actual problem to be solved like there was with pulseaudio or NetworkManager (the old system was clunky with laptops - of course the new one now sucks with everything else).

Re: SystemD added?

[dbIII]

It's a moving target, so you can know what systemd wants this month but it's not the same six months later.

Re: SystemD added?

[dbIII]

I complained about that on an earlier systemd article - the official fanboy response seems to be that because Lennart didn't write it ZFS on linux sucks while systemd is wonderful despite not working properly yet.
So I went back to RHEL6 and an init system that's been tested enough before release.
My home system is a recent Fedora - I just gave up and I've been starting ZFS from the command line on login after about the third change where systemd went from being able to start ZFS to not.

Re: SystemD added?

[Anonymous Coward]

Do you suck Pottering dick how does it feel?

Re: SystemD added?

[Anonymous Coward]

This :(

We just had an entire government department move shy of 500 full sized racks from RHEL to windows server because upgrading would have involved systemd.

I'd similarly like to congratulate whoever made this decision for crippling linux adoption because they "needed" to fix init so bad they jumped on the first bloated piece o shit that met the bill... What a joke.

Re: SystemD added?

[Anonymous Coward]

The other day I had to reconnect a HD I was going to remove because systemd refuses to boot unless every single disk is plugged in. You can't take a fucking step without systemd shitting down your throat.
I have yet to decide which way I'll take, but I recommend you move to *BSD or Gentoo. It's unlikely Theo will suck Poettering's disease-ridden dick so I think that's safer, but the downside is it isn't Linux.

Re: SystemD added?

[Ol Olsoc]

Danger: systemd marketing droid detected..only line of worth in the twaddle spouted is ;

Systemd haters are becoming computing's version of the Mesothelioma lawsuit commercials on TV, and seriously, you need to get back to getting those fucking kids off your lawn. Or maybe bitching about them taking lead out of gasoline.

Don't like it? Don't use it. If you do not understand that by now, why would anyone pay attention to your stupid rants about it? Go to distrowatch, find a systemd version that is acceptable, visit the associated site, download and install a Linux version you like, there are over 200 distros there, or if you are really concerned that nothing bad gets on your computer, roll your own Linux distro. If you actually know Linux, it's not hard.

Re: SystemD added?

[Ol Olsoc]

No, it's NOT JUST A LAUNCHER. It's a logging daemon, a console input daemon, it's much, much more than just a launcher.

It's also a great dessert topping.

Re: SystemD added?

[Barsteward]

its next release is 220 so you should be fine

Re: SystemD added?

[Anonymous Coward]

And it's exactly this reason why linux/Unix will always remain a niche for the desktop.

Re: SystemD added?

[Anonymous Coward]

Just use a Mac or a Windows based PC. They don't require a CS degree from the 90's in order to use them. I'd rather pay a few hundred bucks more and actually be able to use a computer than fuck around for hours on end trying to get a computer to work .....

Re: SystemD added?

[buchanmilne]

No, because you would have already fixed the /etc/init.d/zfs file

If you can fix it in /etc/init.d/zfs, you can just as easily copy /usr/lib/systemd/system/zfs.service to /etc/systemd/system and fix /etc/systemd/system/zfs.service

instead of googling "systemd dependancies editor"

Surely you have vi or emacs or nano or pico or something available, with which to add a Requires entry (see systemd.unit(5)) to the zfs service unit?

Re: SystemD added?

[Anonymous Coward]

I am too stupid to mark mounts nofail

FTFY

Re: SystemD added?

[Anonymous Coward]

err... yes, you can. journalctl only uses its internal pager if stdout is a tty. just pipe it into whatever pager you want.

Re: SystemD added?

[Anonymous Coward]

Danger: systemd marketing droid detected..only line of worth in the twaddle spouted is ;

Systemd haters are becoming computing's version of the Mesothelioma lawsuit commercials on TV, and seriously, you need to get back to getting those fucking kids off your lawn. Or maybe bitching about them taking lead out of gasoline.

kids off lawn: first they'll have to negotiate the wall, then there's the boat...and once they finally find the smallish patch of grass which might, at a stretch, be called a lawn..they're most welcome to play there.
Lead & Gasoline: I use a steam powered car, you insensitive sod..

Don't like it? Don't use it. If you do not understand that by now, why would anyone pay attention to your stupid rants about it? Go to distrowatch, find a systemd version that is acceptable, visit the associated site, download and install a Linux version you like, there are over 200 distros there, or if you are really concerned that nothing bad gets on your computer, roll your own Linux distro. If you actually know Linux, it's not hard.

Yes, it's currently not that hard, and at home , I'm not using it on any of my Linux boxes.
As to rolling my own, sure, I've done that for my firewall at home, sure, I could extend that work to a whole tailored desktop setup, alas, I do have a life outside computing/software nowadays, so I'll go for the path of least resistance here, whatever that ends up being.

At work , however, it's a different matter.
As we were running Debian, and as the next release will feature systemd, this impending change was flagged at an IT meeting, so the management got our testers to fire up the current 'testing' release on our test server. (Note here: I was not involved in this, its SEP..and as someone on the anti side, I was known to be biased..) Upshot of a months testing, a box which ran wheezy and our services without issue for months previously, fell over every two-three days under simulated load testing. The testers couldn't get to the bottom of the issues, reported back to the management, management made a decision to migrate core services currently running on Debian servers over to win2k8 (we've always had a parallel windows based setup in place, eggs in one basket, and all that.)

Yes, we explained the concept of LTS, we tried convincing them that Slackware was a viable option and that two non-core servers already run it, their eyes glazed over when we mentioned the *BSDs, and as for Devuan..their view was that from the problems the testers were having, compounded by their reading of the developing schisms and future uncertainties regarding the currently systemd-free distros eventually having no choice in implementing it due to dependency poisoning, they'd rather opt to deal with the certainties of the devil they once knew (and the one we'd spent years weaning them off..).
Apropos the *BSDs, despite the fact that it is a trivial matter to port the software and services over, and we showed them, *BSD != Linux..so here be dragons as far as they're concerned.

The edict now is that *all* linux systems (including desktops) are to be replaced with either their MS equivalents, or appliances (e.g. firewalls - fun fact, the firewall appliance they chose runs a heavily customised Linux variant). And it's going to cost.

As someone once said ' And when you get your freedom, don't pish in the water supply'
The water itself tastes mighty funny right now, but I suppose with all the Kool-Aid that's being added, you can't tell.

Re: SystemD added?

[ncc74656]

Frankly I was shocked he didn't roll out "synergy" but I think they wised onto it thanks to Dilbert ragging on it so many times.

Too many people would've completed their Marketing Bullshit Bingo cards on that.

Re: SystemD added?

[hitmark]

Sounds ironic given that systemd (and the rest of the fd.o cohort) seem hell bent on reproducing Windows (or at least Active Directory and Group Policy).

Re: SystemD added?

[hitmark]

The overarching problem is that systemd can decide to rearrange the boot sequence at any moment.

If a admin has set a sequence to be XYZ they have a very good reason for doing so. So why should the init suddenly decide that YZX is the way to go?

Re: SystemD added?

[fisted]

Editing an init script is never the solution to a problem unless you ARE the maintainer of the distribution.

Or, you know, when there's a way to identify and communicate with said maintainer.

Re: SystemD added?

[Anonymous Coward]

If the qualities of classic init are critical to your use-case, there are always other distributions available.

Can you name one?

To qualify, the distribution MUST have:
- With minimum of 5 years guaranteed support
- Commercially available professional support
- Apt-get (or equivalent) and 30 000+ package repository
- Documentation available to next to anything
- Guaranteed compatibility for support lifetime (versions MUST stay the same, security only, no rolling releases allowed)

First RHEL got ruined, then Suse, now both Ubuntu and Debian, there really isn't anything in the Linux world left.

Re: SystemD added?

[rdnetto]

The overarching problem is that systemd can decide to rearrange the boot sequence at any moment.

If a admin has set a sequence to be XYZ they have a very good reason for doing so. So why should the init suddenly decide that YZX is the way to go?

Because parallelism is good for performance, or so the argument goes.

The real issue is that there's no way to reproduce that partial-ordering. IMO, there should be some kind of debug facility to restrict it to sequential startup, then try all possible orders. (Yes, factorial complexity is never fun, but at least it would provide a means to debug this kind of problem. Making open source software easy to debug (or at least capture logs for) is hugely important, because that's where most of your drive-by patches come from.)

Re: SystemD added?

[Megol]

I use those words (though not often in the same post). I'm not a shill and don't work in marketing (or PR - but I repeat myself).

Those word have real meaning and strangely enough the post you are complaining about uses them in the correct manner. I'd phrase it a bit different but still, this is real words with real meaning used correctly to communicate a coherent point.

And that is much better than the standard anti-systemd rantings that generally are wrong, non-technical and arrogant in a manner that creates a synergistic bullshit.

Re: SystemD added?

[Anonymous Coward]

This POS broke my system. "Oh its so wonderful!" Bullshit! First I get "Systemd failed to start Load Kernel Modules", then I get "Systemd failed to start user service: unknown unit: user@0.service". And not just in the new version of ubuntu but the old version too. And after a week of trying to the the computer to do anything, I go to using mint. Fuck Systemd. This little piggy arrived DOA. If you want to turn a perfectly good computer into a brick, use systemd.

Unity next

[szmccauley]

Hopefully they'll dump unity and go back to gnome shell as the default. Unity is completely unnecessary bit of technological desktop hubris.

Re:Unity next

[Anonymous Coward]

Unity is the metro of the linux world. It doesn't look like it, it just sucks like it.

Re:Unity next

[Threni]

Agree but i've had problems with Mint for a while, and the official forums for it are dead; you're much more likely to get help on AskUbuntu or UbuntuForums, so I've gone back to Ubuntu then upgraded the ui to xfce. Problem solved! (I tried briefly but unity is still a mixture of awful and buggy).

Re:Unity next

[Anonymous Coward]

Gnome Shell is no better than Unity. Both are unusable user interfaces. Shame on those self-appoint user interface experts (more like non-experts) for taking a dump on its existing users.

Long live Ubuntu MATE! Ubuntu MATE has made Linux actually enjoyable to use again.

Re:Unity next

[Tim the Gecko]

I've been using Unity for a few years and I like it. Typically I might have several browser windows, several terminals, and other windows like WireShark open. In the older UI these would have all been accessible from the bottom bar, and there might be twenty or so tabs there. Unity changes it around so you go to the side (a good place to put things on a 16:9 monitor) and select the browser, terminal, or another icon. With the muscle memory in place it has worked very well. Alt-tab also works as you might expect. I also have Mac laptops, and it's not especially annoying to go from one UI to the other.

Re:Unity next

[jcdr]

Debian Jessie with MATE is very good too. Should be released tomorrow AFAIK.

Re:Unity next

[Anonymous Coward]

You know that you can do that right?
https://wiki.ubuntu.com/VividV...

Pick your flavor - GNOME, KDE, etc. What do you care if it's the "default" - are you too stupid to pick something else?

Re:Unity next

[Blaskowicz]

I remember how Ubuntu 10.04 came out, I installed it from the network (no need for a DVD or USB drive!) and I thought that great, the linux desktop is done. Stable, great looking. Then just a year later, it's back to a mess, great user fragmentation among distros and DEs, and then in a continual state of transition (and I need to buy USB drives to install linux mint).

Ubuntu MATE possibly is a very good idea, but it's now an also-ran. It feels to me sort of like it's downstread from Mint, too. Too bad that if I install a 9-month version, I know I'll have to come back shortly thereafter (perhaps in six months or less if I install it later) to do the reinstall or upgrade.

Re:Unity next

[Anonymous Coward]

The UI for Unity/Gnomeshell are fine. The problem with Unity is that the dash is annoyingly unresponsive. When I type "virtualbox" it should show me the application, not wait around for 20 minutes twiddling it's thumbs before showing some ridiculously irrelevant web searches. I mean, other OSes have done the "unified search" concept without breaking the ability to search the application launcher. It's not a bad design, the implementation needs a lot of polish.

Ubuntu has been using upstart for a while and systemd isn't too particularly different from it, so it shouldn't be an issue. In fact, I don't get why everyone complains about it... I tried Arch in a VM a month ago and I noticed... systemd! Yes! Even though you guys don't even have an installer, you have systemd on your smug hipster Linux OS.

Re:Unity next

[jcdr]

Gnome 2, MATE, XCFE, and maybe other desktops allow vertical toolbars too if you like it (not my case).
Alt-TAB window switching work equally well on all of them too.
I personally found both Gnome 3 and Unity catastrophic in term of productivity. I actually work with close to 40 virtual desktops and over 100 windows. I configured to switch around them using right CTRL+arrow keys, without any animation or effect. Blazing fast and simple.

Re:Unity next

[JRV31]

I think Unity would be great if they would get rid of the dash. The Launcher is good, and the quiicklists are the only reason I still use Unity.

Re:Unity next

[Anonymous Coward]

No problems with Unity here.

As it developed, it got better and most problems I have with it now are extremely minor. Some here compare it to Windows Metro, but that just doesn't stand. I use both Windows and Ubuntu everyday (Windows for business apps and Ubuntu for technical work). Within two weeks of using Metro, I could no longer take it and got the third party utilities that make the experience much like prior versions. With Unity the first version wasn't so painful that I stopped, and by the second iteration (as I recall) they corrected enough that I really warmed up to it. At this point, I wouldn't want them to change to anything else. There are incremental improvements I'd like to see... but it's perfectly usable.

Re:Unity next

[higuita]

for small workloads (eg: home users), unity is good. Mate is also good
for high workloads, with many windows open, openbox, fluxbox, awesome, dwm, ratpoison, etc are better
KDE is not bad too, as it is very flexible and lighter today than gnome ... Their major problem is that it still have that "not free enough!" or "it uses C++!!" shadow, that scared many to start gnome. Since then many things changed, but Redhat/fedora still run from it like hell and ubuntu always hide kubuntu from most people.
Gnome shell, IMHO is trash, even worst because of the same model as sytemd ( "Take over everything, do it my way, don't care about what people say, they are all idiots anyway")

Re:Unity next

[DrXym]

Unity changes it around so you go to the side (a good place to put things on a 16:9 monitor)

It's a good place on a 16:9 monitor. Not so good if you have a 4:3 monitor, or multiple monitors or simply want an option to change it to the bottom, right or some other behaviour.

Re:Unity next

[armanox]

Try the unity-tweak-tool (I've been giving Ubuntu a run for the past week or so) (apt-get install unity-tweak-tool) - under "Unity" click "Search" and uncheck "Check Online Sources"

Re:Unity next

[Anonymous Coward]

Exactly my thoughts. Unity is much better than current Gnome but there are quite a few annoyances like can't re-map keys with 'Super', can't get rid of top bar, dash search is slow etc.

Re:Unity next

[Anonymous Coward]

Unity is the metro of the linux world. It doesn't look like it, it just sucks like it.

Unity sucks, and badly. We've been using Ubuntu since the beta of Ubuntu 5.05 Dapper (early 2005). At first, we used Gnome, largely because it was understandable and quite good. When the beta for Ubuntu 11.10 Oneiric was released in the second half of 2011, and installed on a VM, I was appalled.

All of our Ubuntu Lucid 10.04 LTS installations were switched to Xubuntu with the xfce desktop before Ubuntu Precise 12.04 LTS was spewed forth. They're all running Xubuntu 14.04 LTS now, and are the better for it (the switch from Unity to xfce).

When Gnome "upgraded" from v2 to v3, even a fallback to Gnome 2 became difficult. The early versions of Mate were a bit buggy, and somewhat unsatisfactory. Mate is now a better product, but in the meantime, we've got used to doing things the xfce way.

Re:Unity next

[Grishnakh]

No, Gnome shell is no better than Unity, and probably worse. They both suck.

Ubuntu should just switch to a customized version of KDE. KDE has a far better underlying architecture than Gnome, and it's not that hard to make a different version of Plasma if you're a distro that wants to do things a bit differently.

Re:Unity next

[jonnyj]

I've been using Unity for a few years and I like it...

Me, too. And my wife, my kids, my father, my mother in law. But most people who enjoy using Ubuntu aren't the kind of people who post on /. But power users who need advanced features not offered by Unity are presumably also sufficiently sophisticated, knowledgeable and competent to effortlessly install an alternative desktop.

Problem solved. Simpletons like me and my family can use the dumbed-down nursery-school, colour-by-numbers default desktop interface. Clever, technical people can type a few commands starting with 'sudo apt-get install'. I don't get why everyone isn't happy?

Re:Unity next

[fahrbot-bot]

With the muscle memory in place it has worked very well.

The same can be said about masturbation. Doesn't mean it's better than actual sex w/someone else.

Re:Unity next

[Blaskowicz]

me there again, I forgot or didn't take the time to add some positive tone in my post, now dl'ing Ubuntu Mate 15.04 for i386 anyway!

Re:Unity next

[Anonymous Coward]

Long live Cinnamon! would be nice to have a Ubuntu edition (not Mint)

Re: Unity next

[Anonymous Coward]

But Debian Jessie is unusable because it uses systemd. I've had so many problems with systemd that I refuse to use it and any distro that uses it.

I had been running Debian unstable for years, which contrary to its name was very stable (more stable than the stable releases of many other distros I'd tried, even). But once systemd was installed during an update, it was one broken thing after another. Sometimes my computer wouldn't boot properly, and I'd have to waste time fixing some problem with systemd, after doing updates to fix earlier systemd problems.

I know I'm not alone. The Debian mailing lists and bug tracker are full of reports about problems due to systemd. We just didn't experience so many stupid problems prior to systemd!

I've moved on to FreeBSD. It just works, and I don't think that its devs would ever adopt something as problematic as systemd. To hell with systemd, and to hell with Debian.

Re: Unity next

[Knuckles]

I had been running Debian unstable for years, which contrary to its name was very stable (more stable than the stable releases of many other distros I'd tried, even). But once systemd was installed during an update, it was one broken thing after another.

Development branch of a distro, which is called unstable, sees breakage when switching the init system. A TOTAL SHOCKER.

Re:Unity next

[Knuckles]

Or use the switch built into the settings (under Security and Privacy)

Re:Unity next

[lgw]

I use both Ubuntu and Red Hat daily at work. I really don't like the current Ubuntu desktop - it seems inspired by good ideas, but it doesn't deliver them. Red Hat's very old school desktop is straightforward and intuitive, if limited and ugly. But I'll take limited and ugly and can get work done over the alternative! (This is also my argument against systemd, of course).

I haven't seen XFCE in forever, but I remember it being really fast anf lightweight. XFCE with a taskbar would be my dream.

Re: Unity next

[Eunuchswear]

If you don't want to use systemd with jessie then use init, or even upstart if you want.

Re: Unity next

[Anonymous Coward]

Debian unstable is a misnomer. Before systemd was introduced, Debian unstable was very stable. Ubuntu's packages are based on the Debian unstable packages, as far as I know.

Before systemd, "stable" in the Debian lexicon referred to an extraordinarily high degree of stability, unmatched by other Linux distros. Even extreme stability appears to be "unstable" when compared to Debian's (former?) overachieving definition of "stable".

Somebody like yourself, who obviously has never used a truly stable Linux distro, probably couldn't understand this.

Re: Unity next

[Knuckles]

Debian unstable is a misnomer. Before systemd was introduced, Debian unstable was very stable. Ubuntu's packages are based on the Debian unstable packages, as far as I know.

Before systemd, "stable" in the Debian lexicon referred to an extraordinarily high degree of stability, unmatched by other Linux distros. Even extreme stability appears to be "unstable" when compared to Debian's (former?) overachieving definition of "stable".

Somebody like yourself, who obviously has never used a truly stable Linux distro, probably couldn't understand this.

I ran Debian 15 years ago, you don't need to explain the fundamentals. The point stands that a development branch can break any time by definition, and the introduction of a new init system leading to boot failures here and there comes as part of your decision to run unstable. It's your fault if you upgrade without checking first, it's not systemd's fault. I've lost X or couldn't boot after an upgrade more than once.

Re:Unity next

[epyT-R]

xfce has a taskbar..

Re:Unity next

[Anonymous Coward]

Welcome to slashdot. It's like a stitch and bitch only with neckbeards recalling their glory days in the 80's hacking on an Amiga.

Re:Unity next

[Anonymous Coward]

And they could call it something funky like "kubuntu" to indicate that it uses KDE rather than Unity!

Re:Unity next

[lgw]

xfce has a taskbar..

Wow, cool! Time to check out out again. Thanks.

Re: Unity next

[Anonymous Coward]

One Debian unstable breakage due to systemd is understandable.

Two Debian unstable breakages due to systemd is disgraceful.

A Debian unstable installation that will likely not boot properly after each update due to systemd, month after month, is unacceptable.

Re: Unity next

[jcdr]

I use Debian since Bo, and I delivered this week to a customer my first embedded system based on Jessie with systemd. From this background, I say that Jessie is probably the best Debian release since his creation. For me, Jessie make SB2, WRT, Buildroot, OpenEmbedded, Yocto and all the others totally obsolete. Never was so happy to work building embedded systems than with Debian Jessie. Multiarch, systemd and MATE are exactly what I need.

I updated from system V init to systemd on the embedded system during the development and this was surprisingly smooth. Backward compatibility with system V init worked out of the box and the few minors issues was usual part of a first deployment or specific to my target.

Re: Unity next

[Anonymous Coward]

Before systemd was introduced, Debian unstable was very stable.

Odd, I could've sworn the amd64 multiarch transition completely fucked up 3 sid systems here.
Guess I was simply imagining that.

Re:Unity next

[Grishnakh]

No, you're entirely missing the point. Kubuntu gets next-to-no-usage because it's not a prime-time distro, it's just a small obscure variant of one. Not only that, Kubuntu is just a vanilla KDE setup (which is fine if you like regular KDE Plasma).

My proposal is that Ubuntu dump Unity and the GTK3 plumbing it sits on and adopt KDE instead. People already complain a lot about Unity being slow, and all evidence points to KDE being lighter weight and better performing than Gnome or Unity, due to superior architecture. However, Ubuntu likely doesn't just want to be a KDE distro for whatever reason; obviously they're trying to explore and push different UI concepts with Unity. That's OK: KDE lets you do that, when you have the development resources that Ubuntu enjoys. KDE already has several different versions of Plasma for different devices (desktop, netbook, mobile); the architecture allows you to have a completely different UI sitting on top of KDE's infrastructure. So Canonical wouldn't have such a difficult time developing their own UI (just another version of Plasma) which sits on top of KDE and benefits from its excellent under-the-hood architecture and performance, while letting them easily explore whatever new UI trends they want to try out. And then, anyone who doesn't like that can *trivially* just switch back to plasma-desktop and get a vanilla KDE experience if they want, without needing a whole new distro (or distro variant).

Re: Unity next

[Anonymous Coward]

MATE works for me, it fixed some longstanding GNOME 2 bugs. Cinnamon is what Gnome 3 might have been but wasn't, and is supposed to be part of the gobject-introspection future.

Re:Unity next

[bledri]

...

Problem solved. Simpletons like me and my family can use the dumbed-down nursery-school, colour-by-numbers default desktop interface. Clever, technical people can type a few commands starting with 'sudo apt-get install'. I don't get why everyone isn't happy?

Oddly enough, some people want to spend all weekend customizing their desktop while simultaneously resenting the fact that they "have to."

Maybe it's mostly an ego thing. Building oneself up by looking down on people with different strengths and interests. Or now that I think about it, I bet it's mostly that people need something or someone to blame for their own frustrations. "I'm not happy, it must be your fault!"

Re:Unity next

[RabidReindeer]

Hopefully they'll dump unity and go back to gnome shell as the default. Unity is completely unnecessary bit of technological desktop hubris.

Considering what Gnome 3 did to the desktop experience, that's the equivalent of trading having Bob hit you over the head repeatedly to having Fred hit you over the head repeatedly.

WTF is it with software developers these days that they can only replace existing systems with new systems that omit important and commonly-used features from the systems they replaced?

Re:Unity next

[Anonymous Coward]

Welcome to slashdot. It's like a stitch and bitch only with neckbeards recalling their glory days in the 80's hacking on an Amiga.

I spent the early - mid 80's hacking on a DEC-20, a Vaxcluster and various Gould mainframes ..then got bored and became a Musician for a while.

I laugh derisively at your risible Amiga assertion..

Re: Unity next

[Knuckles]

One Debian unstable breakage due to systemd is understandable.

Two Debian unstable breakages due to systemd is disgraceful.

A Debian unstable installation that will likely not boot properly after each update due to systemd, month after month, is unacceptable.

Unacceptable according to whom? The description says:

'"sid" is subject to massive changes and in-place library updates. This can result in a very "unstable" system which contains packages that cannot be installed due to missing libraries, dependencies that cannot be fulfilled etc. Use it at your own risk!'

Re:Unity next

[Eunuchswear]

Comment needs funny+insightful, slashidiots give troll...

Re:Unity next

[Anonymous Coward]

KDE ftw. It is completely customizable, flashy effects or plain and simple.

Re:Unity next

[Anonymous Coward]

I installed Unity once. I was making sure all the sound drivers worked so I powered up the default media player, found some preloaded demo song and started to play it. I clicked around a bit and then decided that the song was terrible and I didn't want to listen to it. So I tried to get the media player open again to stop the playback, but COULDN'T GET IT BACK. My exact words were "Oh god, how do I make it stop?"
I am not exactly a slouch on computers. I have to learn new UIs regularly for my job. I effortlessly intuit my way through unfamiliar interfaces that scare my mother even though she has read the manual. I could not make the music stop.

I liked Linux DEs back when they realised that aping Windows 9x was a good thing. No modern mouse-oriented Linux DEs compare favourably to Windows 7, which is an improvement on the same basic ideas.

Re:Unity next

[fahrbot-bot]

Comment needs funny+insightful, slashidiots give troll...

Thanks. Seems "troll" is sometimes used when someone simply doesn't like what you say (or doesn't under stand it). I don't know whether to be sad or annoyed in those situations. In *this* case "off topic" might have been appropriate, as I was intending it as a funny comment to something in anther post, but not related to the main story, though people sometimes use that mod because they, apparently, simply have a stick up their ass.

In any case, I wasn't slamming systemd, even though I'm pretty sure it's a bad idea or, at least, a bad implementation - hmm, Lennart wrote it, so probably both. (see, that's a slam) :-)

Re:Unity next

[Ol Olsoc]

xfce has a taskbar..

Wow, cool! Time to check out out again. Thanks.

I've used Lubuntu on some repurposed netbooks it has LXDE desktop. Pretty clean. http://lubuntu.net/ Otherwise Mint with Xfce is nice : http://blog.linuxmint.com/?p=2...

Re:Unity next

[AntiSol]

I've been using xfce daily for over 3 years, it's great, I don't miss gnome at all.
I do tend to use "alternate" taskbars though - cairo dock and avant window navigator. :)

Re: Unity next

[Anonymous Coward]

It's your fault if you upgrade without checking first, it's not systemd's fault.

Just to be 100% clear, you're saying is that bugs in systemd are not systemd's fault?

And you people wonder why us "haters" don't like your attitude...

Re: Unity next

[Barsteward]

FreeBSD are looking into an "init" replacement in next few years as well so you'll have to change again.

"The Debian mailing lists and bug tracker are full of reports about problems due to systemd. " - i bet they are full of reports of problems that are not systemd as well, especially an UNSTABLE release

Re: Unity next

[jonnyj]

So you found a bug that's almost certainly now fixed. Do you write off an entire desktop environment because one programming has a bug?

In any case, Unity offers a great way of controlling music that I wish all desktops shared. Simply click on the speaker icon and you get playback controls for all active music players - Spotify, Rhythmbox, Totem, etc.

Re: Unity next

[Knuckles]

No, what I'm saying is that your complaint about sid breaking is misplaced. systemd's problems in sid, if they exist, may be systemd's or Debian's bugs, I wouldn't know and you or the other AC just wrote a general unspecific complaint so it would be difficult to say. But even so, yes, software has bugs, this is why sid exists.

systemd rules!!!

[bazmail]

I don't know what all the fuss is about. If you approach it with an open mind it makes perfect sense.
The unreasonable spoilt tubby pasty basement dwellers who spew poison over systemd need to live in the real world for a while.

We've adopted it on an increasingly large scale and we are seeing the rewards already.

Re:systemd rules!!!

[Viol8]

"We've adopted it on an increasingly large scale and we are seeing the rewards already."

List them. And be specific - no vague handwaving waffle please.

Re:systemd rules!!!

[Anonymous Coward]

One more requirement: explain how to debug/trace exactly what systemd is doing without recompiling systemd and adding specific printf() statements everywhere.

Because that's what's missing from systemd at the moment.

Re: systemd rules!!!

[Anonymous Coward]

sounds made up. well I've switched to openbsd and I can tell you I haven't looked back. it is rock solid and the security stuff they have built in is darn impressive. as far as I'm concerned systemd=high complexity=high chance of serious exploits

Re: systemd rules!!!

[udippel]

Sure you post as AC!
Nobody takes you serious with this statement of yours. Not that OpenBSD has anything to be said against it. But OpenBSD is not a desktop-everyday-OS. Only an AC could declare it as such.

Re: systemd rules!!!

[ookaze]

sounds made up. well I've switched to openbsd and I can tell you I haven't looked back. it is rock solid and the security stuff they have built in is darn impressive. as far as I'm concerned systemd=high complexity=high chance of serious exploits

You haven't looked back, and yet here you are looking back at a linux distro that uses systemd.
Basically, you make no sense : lying to yourself is not a solution.
It's obvious you crave for what is happening in the Linux systemd world, which is the contrary to "not looking back".
Or perhaps you're right, which would mean you think that you have gone back by going openbsd, and you are now looking forward to Linux distro using systemd.

Re:systemd rules!!!

[Anonymous Coward]

journalctl -f

Unless you have chosen not to use journald, then read 'tfm' from your syslog.
What more debug do you need that other inits are providing?

Can't believe I am answering to an idiotic troll.

Re: systemd rules!!!

[thaylin]

So posting in a thread about a feature he does not like is somehow looking back at the systems? So once you change systems you cannot ever look or post on the previous techs threads or you are looking back?

Re:systemd rules!!!

[ruir]

I would prefer to answaer to a non AC...but then. sysdig or dtrace

Re: systemd rules!!!

[ruir]

I have not read a single time desktop above.

Re: systemd rules!!!

[ruir]

I guess you post in slashdot because being an idiot in real life is not enough for you?

Re:systemd rules!!!

[jcdr]

I actually found systemd reporting, status and analysis tools pretty verbose compared to the corresponding system V init scripts.
What kind of bug did you try to catch ?

Re:systemd rules!!!

[Anonymous Coward]

> journalctl -f

Which simply does not help. systemd doesn't usually save stderr so the journal is more often than not useless for troubleshooting. If you had actually used systemd, you'd realize those guys don't grok UNIX. They simply don't get it. They don't understand why stderr is so important. Instead, they just toss it away. If you had actually used systemd, instead of just trolling, you'd realize why it is fundamentally broken.

Re: systemd rules!!!

[jcdr]

systemd service files are far less complex that the stack of init scripts need on top of system V init. The status and reporting is incomparably better than anything before it.

Re:systemd rules!!!

[Anonymous Coward]

What more debug do you need that other inits are providing?

System V init scripts don't have a policy against syslog and stdout. If a process outputs to stderr with a standard init script, then you see it on the screen. You can debug problems. With systemd's policy against stderr, it is swallowed and not shown on the screen and not logged. It is simply sent to /dev/null. The creator of systemd admitted he doesn't get the concept of stderr. It is an important one, and his policy makes it nearly impossible to debug startup problems. That is why systemd is useless for systems with nontrivial startup scripts, which is exactly what it is being sold as solving so that makes it broken by design. It does not do what it is being sold to do.

Here's a script that reproduces this flaw in systemd that was originally posted to a systemd bug that was of course deleted and ignored:

# cat /etc/redhat-release
CentOS Linux release 7.0.1406 (Core)

# cat /etc/systemd/system/broken_systemd.service
[Unit]
Description=Broken systemd example
After=network.target

[Service]
User=root
Group=root
ExecStart=/root/broken_systemd.sh

[Install]
WantedBy=multi-user.target
EOF

# cat /root/broken_systemd.sh
#!/bin/bash
echo "Example systemd service"
echo "Error that should not be thrown away" >&2
exit 1
EOF

# chmod +x /root/broken_systemd.sh

# systemctl start broken_systemd ; echo $?
0

# journalctl -u broken_systemd

Feb 12 17:59:32 redhat7test systemd[1]: Started Broken systemd example.
Feb 12 17:59:32 redhat7test systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 17:59:32 redhat7test systemd[1]: Unit broken_systemd.service entered failed state.

Re:systemd rules!!!

[ookaze]

> journalctl -f

Which simply does not help. systemd doesn't usually save stderr so the journal is more often than not useless for troubleshooting. If you had actually used systemd, you'd realize those guys don't grok UNIX. They simply don't get it. They don't understand why stderr is so important. Instead, they just toss it away. If you had actually used systemd, instead of just trolling, you'd realize why it is fundamentally broken.

You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head.
Besides, systemd is not based on Unix, it's heavily tied to the Linux kernel, the same Linux kernel that already doesn't grok UNIX if you want to go that way.
Actually, systemd uses a lot of Linux features not present on Unix. If you wanted to complain, you'd have complained about Linux primarily.
systemd would not even be possible on any Unix, that's why portability of systemd to other Unix was thrown away.

Re: systemd rules!!!

[ookaze]

So posting in a thread about a feature he does not like is somehow looking back at the systems? So once you change systems you cannot ever look or post on the previous techs threads or you are looking back?

No, once you said "I am not looking back", and then you come to a thread of the thing you weren't supposed to be looking at, I call you on your BS.
Besides, this serves no purpose at all, this doesn't help people in the thread, and doesn't help him either.
I see a poor person looking for validation because of his/her insecurity of having changed OS, which doesn't help his/her cause actually.

Re: systemd rules!!!

[armanox]

And anything but portable to other operating systems. We also have an example above of systemd ignoring output to stderr. Not cool.

Re:systemd rules!!!

[gmack]

Who keeps modding these posts up? Using "journalctl -f" to view output from stderr to debug why daemons aren't starting is a feature I use often as part of my job. If there was ever a version of systemd that didn't log stderr, it was a short lived bug.

Re: systemd rules!!!

[Anonymous Coward]

"Not looking back" is a colloquial phrase indicating that one is happy with a decision they have made. It on no way implies that they have decided to scrub their life of all trace of something they used to do or use.

But a nuanced understanding of what people say is beyond a blunt intellect like yours.

Re: systemd rules!!!

[Anonymous Coward]

Holy shit, INI files? This really is the PHP of init systems....

Re:systemd rules!!!

[Anonymous Coward]

What fucking idiot modded this informative?

Apr 24 10:52:06 u1504 systemd[1]: Starting Broken systemd example...
Apr 24 10:52:06 u1504 systemd[1]: Started Broken systemd example.
Apr 24 10:52:06 u1504 broken_systemd.sh[31375]: Example systemd service
Apr 24 10:52:06 u1504 broken_systemd.sh[31375]: Error that should not be thrown away
Apr 24 10:52:06 u1504 systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 24 10:52:06 u1504 systemd[1]: Unit broken_systemd.service entered failed state.

Re:systemd rules!!!

[Anonymous Coward]

This is still a problem with the most recent version of Red Hat. It's running:

$ systemctl --version
systemd 208
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ

Not only does Poettering ignore users, he is also ignoring his employer. He works for Red Hat, and these serious bugs are not being fixed.

Re: systemd rules!!!

[Anonymous Coward]

You mean the example that's a FUCKING BLATANT LIE? Try it yourself before spreading FUD.

Re: systemd rules!!!

[jcdr]

I really don't care of any others operating system since at least 20 years. Fine for me. There still have system V init, and system V init is still running on Linux. What the problem ? Linus didn't ask others OS before making system calls that are unique to Linux. Why systemd (or any applications for that matter) should be prevented to use them ?

Remember me how the Node.js team reacted to my proposition to use Linux timerfd to improve the repeatable timer precision: there removed the repeatable timer from the API because Windows would have nothing to match the Linux timerfd precision.

Re:systemd rules!!!

[Anonymous Coward]

I think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console. systemd hides the information you need. Instead of taking thirty seconds to fix this problem, it took us most of a day and required using strace to see the stderr output that systemd hides.

Even worse is trying to troubleshoot SELinux-related problems. SELinux is very sophisticated so anything that hides stderr or deletes syslog messages makes life very difficult.

Re: systemd rules!!!

[armanox]

I did try it, and reproduced the his results on Fedora 21.

Re:systemd rules!!!

[Anonymous Coward]

was of course deleted and ignored:

And that is the even bigger problem with systemd. Ignoring exit statuses, deleting stderr, and swallowing syslog messages are all bad, but those are problems that can be fixed if Poettering would start listening to people that have much more experience with UNIX especially wrt managing servers. But since he, as Linus Torvalds has pointed out several times, ignores users and bug complaints, this problem will most likely not be fixed. It is a flaw in the culture of systemd. As so often happens in organizations, the culture at the top filters down all of the way to the product in the end. The product so often mirrors the leaders.

Re: systemd rules!!!

[Anonymous Coward]

You are reaching and making yourself look stupid.

Re:systemd rules!!!

[Anonymous Coward]

Great test script. It demonstrates the flaws in systemd very clearly.

Now imagine instead of troubleshooting a simple problem where the exit status is ignored, trying to debug an SELinux problem. That is nearly impossible with systemd. When Red Hat 6 was released, it took me about three weeks to get our entire application stack working on the new version. Most of the problems were due to the fact we store files in nonstandard places which causes SELinux to block access. With Red Hat 7, it took two people more than four months to get everything working. That's more than ten times as long. systemd, despite hiring guys with 20+ years experience and having expensive support contracts with Red Hat, took more than ten times as long to get work as without something that ignores syslog messages, stderr, and exit statuses.

systemd makes the lives of professional sysadmins a living hell.

Re:systemd rules!!!

[Anonymous Coward]

I posted that to reddit! Posting that got my account banned. The guys at /r/linux hate people that understand UNIX. They hate us. They ban people if they show they understand concepts like stderr. They don't understand stderr, syslog, or exit statuses so they lash out and attack people that do. They're proud of their ignorance, and that is why they love systemd. It is down at their level.

Re:systemd rules!!!

[Anonymous Coward]

Nice attempt to blame the victim. Poettering works for Red Hat, and it is still a bug with the version of systemd he ships with the newest version of Red Hat. Maybe it is fixed in some alpha version that no one uses, but in the real world, the journal is useless since it doesn't log stderr and often drops syslog messages.

It is trivial to reproduce this serious problem with systemd. Pick any script in /usr/lib/systemd/*.service:

# append --broken to ExecStart line
vi /usr/lib/systemd/system/named.service
systemctl stop named
systemctl start named

Notice that the exit status from the start is 0. That is broken.

Also, look at the journal using "journalctl -u named" to see that the output doesn't log the expected error "named: unknown option '--'". It is not logged. That makes it very difficult to find the problem with the startup script.

It is obvious that Poettering simply doesn't grasp how important stderr and exit statuses are for those of us that manage servers. He comes from the background of an end-user that cares about things like sound cards. That is why he has spent so much of his career working with sound cards. Start-up scripts are something that he obviously doesn't understand.

Re:systemd rules!!!

[MSG]

With systemd's policy against stderr, it is swallowed and not shown on the screen and not logged.

A lot of this criticism is coming from AC.

I tested your script on CentOS 7 and Fedora 21 a moment ago. Both logged your "Error that should not be thrown away" to both the journal and to the syslog messages file. Both detected that the service failed, and did not "throw away" its exit status.

And as another user pointed out, the old init system did not save stderr to the logs. systemd is an improvement in this aspect.

Re:systemd rules!!!

[Anonymous Coward]

These are getting modded up because morons like you are failing at reading comprehension.

We need to see what *systemd* is doing. We know that we can see what the controlled processes are doing. Which unit files is systemd using? Which environment variables are being set prior to the controlled process execution? As far as I'm aware journalctl doesn't output this information.

There is a specific issue with setting static IP addresses on a CoreOS image that results in systemd deciding to execute both the DHCP and static IP address unit files in parallel - a clear race condition on startup. The best way to have figured this out would be for systemd to emit exactly what it's doing and when it's doing it. There seems to be no facility for this; in fact, looking over the systemd sources suggests that there aren't even any logging statements to enable to trace this sort of problem.

Re:systemd rules!!!

[MSG]

Also, look at the journal using "journalctl -u named" to see that the output doesn't log the expected error "named: unknown option '--'". It is not logged

I don't know what to tell you, AC. You're wrong. I test every "example" of systemd problems that ACs post in this thread and they're all wrong. systemd logs daemon stderr to both the journal and to the syslog messages file.

Re:systemd rules!!!

[MSG]

There is a specific issue with setting static IP addresses on a CoreOS image that results in systemd deciding to execute both the DHCP and static IP address unit files in parallel - a clear race condition on startup.

What are you talking about? systemd doesn't set up network interfaces.

Do you mean that you can start both NetworkManager and the "network" service? Because in that case, both of them use the same configuration files for an interface (/etc/sysconfig/network-scripts/ifcfg-), so an interface can't have BOTH DHCP and static addresses. The network service also detects whether NetworkManager is handling an interface and will not configure it if so.

Finally, NetworkManager provides much better logging of its process than the network service does. If you want to debug the latter, you'd do it basically the same way you always have. "set -x" in the ifup scripts and look at the logs (which you have now with systemd, and did not in the past).

Re:systemd rules!!!

[Anonymous Coward]

system did not save stderr to the logs. systemd is an improvement in this aspect.

But how is hiding stderr and not logging it an improvement? At least with Sys V init scripts I had a chance of seeing the error message on the terminal. With systemd, I'm left in the dark unless I use strace to see the output strings that systemd is swallowing.

Re: systemd rules!!!

[MSG]

Well, I also tried it and could not reproduce those results on either Fedora 21 or CentOS 7. Both systems logged stderr to both the journal and the syslog messages file.

The old init system did not log stderr. If you didn't see an error printed to a tty, it was lost. systemd is actually an improvement in exactly the aspect that ACs complain about through this thread.

Re:systemd rules!!!

[MSG]

Because stderr isn't being hidden under systemd. It's logged to both the journal and the syslog messages file.

Re:systemd rules!!!

[Gr8Apes]

You didn't use systemd either : it has step by step execution, debug option which is very verbose, emergency shell, debug shell (on vt9), all of this off the top of my head.

Oh my, I want to step through 3000 steps manually before I get to my program of interest, and I also want to see 1000 lines of spurious crap for things I don't care about.

Besides, systemd is not based on Unix, ... that's why portability of systemd to other Unix was thrown away.

That sound you hear is a collective sigh of relief mingled with drives spinning up as new downloads of various Unix flavors start in earnest.

Re:systemd rules!!!

[Eunuchswear]

Lying troll detected -- systemd does, unlike sysvinit, save stderr to the journal.

Re:systemd rules!!!

[Eunuchswear]

You lie, troll. That works as documented in all versions of systemd in use.

Re:systemd rules!!!

[Anonymous Coward]

I don't know what all the fuss is about. If you approach it with an open mind it makes perfect sense.
The unreasonable spoilt tubby pasty basement dwellers who spew poison over systemd need to live in the real world for a while.

We've adopted it on an increasingly large scale and we are seeing the rewards already.

Ah, a nebulous reference to 'rewards'...

remind me again, is there an official physical church where one can go worship, or are you all still at the early 'where two or three gather in Poettering's name..' stage?

Re:systemd rules!!!

[maestroX]

Who keeps modding these posts up? Using "journalctl -f" to view output from stderr to debug why daemons aren't starting is a feature I use often as part of my job.

Don't know about your job, years of running init rarely needed to debug or check why/if/when daemons aren't starting. on production systems. with users. with usb thingies. with eth failover.
Honestly, you fucking seriously mean to say THE FIRST PROCESS STARTED UPON BOOT NEEDS DEBUGGING and claim systemd is an improvement?!?!?

Re:systemd rules!!!

[maestroX]

What fucking idiot modded this informative?

Hello Lennart, meet software deployment 101;
shit follows.

Re:systemd rules!!!

[gmack]

I can't tell if you are stupid or just a troll but I'll respond anyways. One of Systemds improvements is that it handles process (apache etc)reloads. One advantage to this, is that things are now restarted in the exact same environment (path, variables, CWD etc) as when the system is booting. The next advantage is that networking restart no longer needs to be run with nohup when done remotely, it just works now instead of dropping the interface and then dying.

This means that if say, a webdev or a junior admin makes a typo in a daemon and it fails to start you can now just use journalctl to see the output that previously went to console.

Less often(usually when I'm doing the initial setup), are things like iscsi, glusterfs etc that choked hard under the old init system and still need a bit (although easier) tweaking with systemd.

Re:systemd rules!!!

[Eunuchswear]

was of course deleted and ignored:

And that is the even bigger problem with systemd.

No, it's a big problem with your insanity.

This bug, since it doesn't exist, was never reported.

Re:systemd rules!!!

[Anonymous Coward]

DIAF.

[vagrant@localhost system]$ sudo systemctl start broken_systemd; echo $?
0
[vagrant@localhost system]$ sudo journalctl -u broken_systemd
-- Logs begin at Fri 2015-04-24 20:19:20 UTC, end at Fri 2015-04-24 20:30:46 UTC. --
Apr 24 20:30:41 localhost.localdomain systemd[1]: Starting Broken systemd example...
Apr 24 20:30:41 localhost.localdomain systemd[1]: Started Broken systemd example.
Apr 24 20:30:41 localhost.localdomain broken_systemd.sh[3928]: Example systemd service
Apr 24 20:30:41 localhost.localdomain broken_systemd.sh[3928]: Error that should not be thrown away
Apr 24 20:30:41 localhost.localdomain systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 24 20:30:41 localhost.localdomain systemd[1]: Unit broken_systemd.service entered failed state.

Re:systemd rules!!!

[Eunuchswear]

I think this is the same problem that stumped Red Hat's support for a while when we first upgraded to 7. MongoDB refuses to start after an unclean shutdown. It detects that by placing its PID in a file named mongod.lock on start and then clearing the PID on clean shutdown. When you start MongoDB with the lock file in place, it gives you an immediate and clear error message on stderr that this is the problem. When starting with systemd, because it swallows stderr and syslog messages, there is no indication whatsoever what is causing it to not start. There is nothing in the journal or the console.

And, as I've already pointed out: http://slashdot.org/comments.pl?sid=6953777&cid=49050025

This is a bug in the mongodb init script, it directs stderr to /dev/null.

If the mongodb init script sends stderr to /dev/null how can systemd log it to the journal?

Re:systemd rules!!!

[Anonymous Coward]

But you have to agree, the reason why you could find this bug was that it was a script which you could easily read through and debug line by line.

Re: systemd rules!!!

[Anonymous Coward]

Sorry - where did initd log stderr to again?

Re:systemd rules!!!

[Eunuchswear]

I can find the bug in an overly complex init script, yes. If they had a simple systemd unit there would be no bug to find.

(I found the bug in the init script in 10 minutes, the GP claims it took his crew of elite developers and Redhat support a whole day. Either he is an idiot or he is lying -- I suspect both).

Re:systemd rules!!!

[Anonymous Coward]

Now the real questions: Did anyone ever fix the bug in NetworkManager that caused it to turn off the network on exit without bothering to check if anyone was using it? Did anyone ever fix the bug in SystemD that made it incapable of resolving the dependency order of NFS? Does Lennart just hate iSCSI and network filesystems and everyone who uses them?

Re:systemd rules!!!

[Anonymous Coward]

Why spend so much effort defending something broken? It seems like if the same amount of time was spent working on fixing systemd, then people wouldn't be complaining so often about these serious issues. By ignoring bug reports with good reproduction steps, you're proving Linus correct that systemd ignores bugs.

I've had to to train all of my junior admins on how to use strace. That took me quite a bit of time, and it takes them a lot of time to go through the huge log files that creates just to find the error string that systemd swallowed. I don't dispute that systemd is better when you have complex dependencies, but it sucks when a unit won't start and it gives you no clue as to why.

I'll also admit that the binary logs are very nice. Being able to look at just the specific unit you care about is very nice. Also, "systemd-analyze blame" is awesome. I was able to quickly find the troublesome services that were causing slow boot times on several servers, but until the other problems are fixed, systemd causes more problems than it solves.

Re: systemd rules!!!

[fisted]

The other day I had a spare machine sitting around, and decided to install some "modern" Linux distro, just to get some first-hand experience with systemd. I decided to install Arch. Halfway through the installation, I arrived at the network interface configuration. I do run a dhcpd, but for this test machine, I decided to set it to a static IP address (in 192.168.1.0/24).
For a first quick reference, this is how you would do it on *BSD (the interface being xyz0):

printf 'up\n192.168.1.42/24 media autoselect\n' >/etc/ifconfig.xyz0
printf 'defaultroute=(gateway addr)' >>/etc/rc.conf

I also faintly remember how to do that on non-systemd Linux, for instance in Debian it's adding 2-3 lines to /etc/network/interfaces.

So far, so good. Now, let's see how this is done when systemd is involved, the following is copypasted right from the Arch wiki

Persistent configuration on boot using systemd
First create a configuration file for the systemd service, replace interface with the proper network interface name:

/etc/conf.d/net-conf-interface

address=192.168.1.2
netmask=24
broadcast=192.168.1.255
gateway=192.168.1.1

Create a network start script:
/usr/local/bin/net-up.sh

#!/bin/bash
ip link set dev "$1" up
ip addr add ${address}/${netmask} broadcast ${broadcast} dev "$1"

[[ -z ${gateway} ]] || {
ip route add default via ${gateway}
}
Network stop script:
/usr/local/bin/net-down.sh

#!/bin/bash
ip addr flush dev "$1"
ip route flush dev "$1"
ip link set dev "$1" down

Make both scripts executable:
# chmod +x /usr/local/bin/net-{up,down}.sh

systemd service file:
/etc/systemd/system/network@.service

[Unit]
Description=Network connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/net-conf-%i
ExecStart=/usr/local/bin/net-up.sh %i
ExecStop=/usr/local/bin/net-down.sh %i

[Install]
WantedBy=multi-user.target
Enable and start the unit network@interface, replacing interface with the name of your interface.

Source
Hilarious, right? It's so simple! And it totally does away with those pesky shell script, yet in order to do something as simple as configuring a static IP, the user is told to create two shell scripts, apart from the systemd "unit file" and the file that contains the actual address.
At that point I nuked the machine and called myself lucky for not having to cope with this shit.

Your comment has too few characters per line (currently 24.9).
Please ignore everything below; /. wouldn't let me comment without it

The log file is expected to reside in the /var/run directory, which may not be writable very early in the boot sequence, and which is erased a little later in the boot sequence. We therefore avoid writing to the file until we believe it's safe to do so. We also assume that it's reasonable to always append to the file, never truncating it. Optional argument $1 may be "OK" to report that writing to the log file is expected to be safe from now on, or "FORCE" to force writing to the log file even if it may be unsafe. Returns a non-zero status if messages could not be written to the file. rc_postprocess Post-process the output from the rc_real_work() function. For each line of input, we have to decide whether to print t

Re:systemd rules!!!

[Anonymous Coward]

> systemd doesn't set up network interfaces.

As of version 209, networkd does. I used it for both static address and bridging setup. As of version 215, it adds a DHCP server. That change caused major grief for us when a junior admin upgraded systemd, and the server suddenly started answering DHCP requests with wrong values. That took us a couple of hours to find while our network was mostly down for employees because who in the heck expects a server that doesn't have a DHCP server installed to start acting as a DHCP server?

Fortunately, Red Hat is still on version 208 so the systemd-created network problems don't exist yet for most people.

Re:systemd rules!!!

[buchanmilne]

If you had correctly used Type=oneshot, you wouldn't have been in the dark and would have seen this on the terminal:

# systemctl start broken_systemd
Job for broken_systemd.service failed. See 'systemctl status broken_systemd.service' and 'journalctl -xn' for details.
# systemctl status broken_systemd -l
broken_systemd.service - Broken systemd example
      Loaded: loaded (/etc/systemd/system/broken_systemd.service; disabled)
      Active: failed (Result: exit-code) since Sat 2015-04-25 07:53:07 SAST; 26s ago
    Process: 7880 ExecStart=/root/broken_systemd.sh (code=exited, status=1/FAILURE)
  Main PID: 7880 (code=exited, status=1/FAILURE)

Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Example systemd service
Apr 25 07:53:07 HOST broken_systemd.sh[7880]: Error that should not be thrown away
Apr 25 07:53:07 HOST systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Apr 25 07:53:07 HOST systemd[1]: Failed to start Broken systemd example.
Apr 25 07:53:07 HOST systemd[1]: Unit broken_systemd.service entered failed state.

Just because sysvinit couldn't do anything useful with stderr from a one-short service (and leave it to the controlling terminal to do something with it) doesn't mean systemd shouldn't. Logging it, and informing the user that the job didn't start and where to see more information is much more useful.

Re:systemd rules!!!

[buchanmilne]

I've had to to train all of my junior admins on how to use strace. That took me quite a bit of time, and it takes them a lot of time to go through the huge log files that creates just to find the error string that systemd swallowed. I don't dispute that systemd is better when you have complex dependencies, but it sucks when a unit won't start and it gives you no clue as to why.

You may have been better off reading systemd.service(5), but junior admins should be taught how to use strace regardless ...

I think part of the problem is that sysvinit is basically feature-less, and for a running system actually does nothing (it is initscripts that does this), and so people are used to just having the entire system run by scripts with no useful features (e.g.doing something different with stderr than leaving it to the controlling terminal, letting the current user pollute the environment and thus never have consistent starting of services etc. etc.).

Re:systemd rules!!!

[Barsteward]

" I want to step through 3000 steps manually before I get to my program of interest," - what are those 3000 steps?

Re:systemd rules!!!

[Barsteward]

thats probably more down to your lack of experience with systemd than with systemd itself (if its true, i don;t tend to believe ACs). better get reading about systemd and its capabilities

Re:systemd rules!!!

[Barsteward]

look up how to use "journalctl", i'm sure even you could use it

Re: systemd rules!!!

[Eunuchswear]

I did try it, and reproduced the his results on Fedora 21.

That's very interesting, you're the first non-ac to report this.

Care to show me exactly what you did?

If you took the recipe given by the ac:

It is trivial to reproduce this serious problem with systemd. Pick any script in /usr/lib/systemd/*.service:

# append --broken to ExecStart line
vi /usr/lib/systemd/system/named.service
systemctl stop named
systemctl start named

Then maybe you missed the fact that systemd doesn't re-read unit files for existing services, you have to do a "systemctl reload" after stopping the service and before restarting it. (You should have got a message warning you of this, but many people seem to misunderstand the message).

Re:systemd rules!!!

[Eunuchswear]

"shit" does happen. What is interesting about the whole systemd thing is that there are a class of people, all posting AC, why lie about what happens.

I'd love to know why. I can understand that people don't like some software, but why would they flat out lie about what that software does?

How do I know these claims are lies? Because they are all posted AC, because nobody has ever claimed to have reported these defective behaviours as bugs, because I can't reproduce them even when using exactly the same environments and commands as the claimant.

Re: systemd rules!!!

[jcdr]

Well, there is probably a lot of even more complicated methods.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

I hope this one is simple enough for your use case.

Re: systemd rules!!!

[Eunuchswear]

you have to do a "systemctl reload" after stopping the service and before restarting it.

Sorry, I mean "systemctl daemon-reload" of course.

Re: systemd rules!!!

[fisted]

Well, there is probably a lot of even more complicated methods.

I'm sorry to hear it.

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I hope this one is simple enough for your use case.

No, it's not; and more to the point, I don't have a real "use case". As said:

The other day I had a spare machine sitting around [.........] [and then] I nuked [it]

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

Re: systemd rules!!!

[jcdr]

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all. The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Re: systemd rules!!!

[fisted]

Now if you just need a simple static address I would suggest to use systemd-networkd: https://wiki.archlinux.org/ind...

Oh, neat. So instead of writing two scripts (all w/ bashisms), a configuration file and a unit file, the "next best" way is to run yet another 13.000-lines C program (cat src/network/network[cd]*.[ch] | wc -l).

I can't even tell if you're trolling or just a good example of demonstrating what's wrong with systemd mindset.

I don't understand you, really. The procedure you mentioned was the bare minimum if you don't want to use any helper scripts or applications

Except for the mentioned helper scripts and the whole bloated infrastructure of systemd, sure.

and is almost identical to what you need with system V init to get the same functionality: the configuration file and the two scripts are absolutely not related to systemd at all.

How aren't they related to systemd? I'm not following, I think.

The difference is that with system V init you need to write a script with a start) and stop) method while with systemd you have to write a service file. At the end this is exactly the same number of files, so what your problem ?

So you see how pointless it is?

systemd-networkd is only an alternative. Personally I largely prefer C code over scripts, mainly because C code projects tend to be adopted by many distributions while scripts tend to remain specific to each distribution. The systemd vs system V story is an very good illustration of this difference.

Disclaimer: I have a ton of experience in C; i really like the language. But would you please think of debugability? Quickly analyzing and fixing a bug in a script means editing that script. Fixing a bug in a component that is written in C, means a) identifying what part failed in the first place, checking out the entire project, getting it to compile (which tends to include a ton of build time dependencies), of course don't forget to compile with debug symbols. Then either install the debug version, which sucks, or put it somewhere else and hope the part you're fixing doesn't use the non-debug version. And that is even ignoring the actual effort about fixing the actual bug...
A shell script? add a ``set -x'' to find out what's going wrong, edit to fix, which is usually no problem for someone who knows their shell.

You see, I already have two good solutions and this little experimental journey into the Arch world just made clear that if I hadn't moved to the BSDs back in the day, I'd do it now. Thanks, though.

So why did you post on a Ubuntu systemd specific discussion if you use *BSD and have only tried Arch ? AFAIK Debian still provides support for /etc/network/interfaces with systemd so basically nothing changed for the users.

Perhaps because I had some impressions with a journey into the systemd world to share? I do manage a few hundred Debian machines at work, so i'm not a complete stranger in the linux world.

Why do you put whitespace in front of question marks?

Re: systemd rules!!!

[jcdr]

1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files, exactly the same amount of file on system V init.

2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts. The fact that this 2 scripts use a configuration file is neither relater to systemd.

3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.

4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.

5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English. http://fr.wikipedia.org/wiki/P...

Re: systemd rules!!!

[fisted]

1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files

...two of which are helper scripts...

, exactly the same amount of file on system V init.

Not quite, but whatever.

2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.

...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script. So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.

The fact that this 2 scripts use a configuration file is neither relater to systemd.

Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.

3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.

I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..

4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package

You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote.

, the fact that it require a compilation is a detail, especially given how ubiquitous is a C compiler on a maintainer machine. Well written scripts or C applications must log debug messages to help tracing problems. Now take a look at the reality: there is very few scripts that are well written, mainly because the authors assume that it's easy to read the script. On the contrary many C applications a well written because the authors know that the users will have nothing to show in case of a problem. The 'set -x' is not a magic trick that allow to find any problem a stack of scripts might have. The dependencies problem of the init scripts is one of them.

(I mostly agree with this, but it's beside the point)

5) Because I usually wrote French and in that language we put a whitespace in front of question marks. I did not notice that it's not the same in English.

Fair enough. So a twisted parallel universe it indeed is! (just kidding)

Re: systemd rules!!!

[jcdr]

1) The procedure you mentioned precisely do not use any helper script. This why it take 4 files

...two of which are helper scripts...

No, by definition helper scripts must already be part of the distribution.

, exactly the same amount of file on system V init.

Not quite, but whatever.

Exactly the same amount, if you don't use the system V init helper scripts.

2) The /usr/local/bin/net-up.sh and /usr/local/bin/net-down.sh are absolutely not related to systemd at all. You will use exactly the same scripts with system V init if you don't use helper scripts.

...except for those two helper scripts, yes... They are /not/ required in sysvinit. There's nothing to stop you from doing something like that on system V, but the canonical way would be to do that in the init script.

At least you recognize that (almost) the same procedure will apply to system V init if someone don't want to use his helper script. Please understand that the normal way to configure a simple static IP address with systemd is to use either systemd-networkd or the distribution specific file to do this like /etc/network/interfaces in Debian.

So regarless of whether the helper scripts are an unrelated or an integral part of systemd, using systemd in Arch for the highly complex use-case "static IP address" apparently means one way or another, they have to appear. Stop trying to excuse that away.

The fact that Arch Linux don't provides anything is strange. Think what would be the usability of a system V init without all the scripts on top of it. This is not an excuse, others distributions that use systemd simply don't require the procedure you mentioned, and event Arch document how to use systemd-networkd for a simple static IP.

The fact that this 2 scripts use a configuration file is neither relater to systemd.

Sure, there's nothing wrong with a configuration file. What you're trying to say here, not so sure.

Simply: this is not because of systemd.

3) Yes this is pointless to compare systemd over system V init by showing an example that is nothing related to systemd.

I don't even know what to reply to this ... odd ... statement. I'll grant you the benefit of the doubt and assume you live in some twisted sort of parallel universe where 'nothing related' means 'entirely related' or so..

You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration. Now think is you have found the same procedure that use a system V init /etc/init.d/* script to call the very exact same scripts that use the very exact same configuration file, I beat that you will instantaneously found this procedure too complex because you can simply configure a static IP by just edit an already existing configuration file dedicated for this purpose in you distribution of choice.

4) I also claim to have ton of experience in C. From the distribution maintainers point of view, scripts or C applications are exactly the same problem: when there have to fix something, there need to publish a new package

You're missing the point. I wasn't talking about the point of view of distro maintainers, but the case when you, a sysadmin, first encounter a problem with a script or program. Please, with that in mind, reconsider that part of what i wrote

Re: systemd rules!!!

[fisted]

We're obviously using "helper script" to refer to different things.

No, by definition helper scripts must already be part of the distribution.

I completely disagree, but I wasn't aware of that there's an accepted definition. Mind sharing the source?

[...] system V init helper scripts.

I'd hesitate to call the sysV init scripts "helper" scripts, because they are the central mechanism (apart from lil' init itself). The "central element" of systemd are the parts witten in C, of which there (apart form init itself) is no such equivalent in system V init.

You have perfectly understand me. You find, maybe by hazard, a very strange and unusual procedure to setup a static IP interface. The procedure use a systemd service file to call two scripts that use a configuration file and you make it a point about claiming that systemd require too complex procedure for a such simple static IP configuration.

No. I knew you'd bring up something like this, but, no.
The manual way to configure an interface is one execution of the ifconfig(8) program (or whatever is currently hip in the linux world). This is the part that has to be "learned"; you have to remember that the program's name is ifconfig, and that it accepts an interface name, followed by an address family, followed by an address. Or else, that there's a man page. That's the "hard" part, and it's the same (modulo constant NIH-ing of the interface configuration programs due to what probably is an underlying design flaw) on both sysVinit and systemd machines
Now, system V runs that command in a shell script and that's it. If now you feel like objecting "but it means i need to learn the shell!", then here's the important piece you're missing: If you're using a unix-like OS, and you don't know how to handle a shell, then there's your problem. It's the primary user interface. It's not only for running init scripts but provides a direct value for almost every other task imaginable.

Now, in systemd, one has to additionally learn systemd. It doesn't mean you can forget your shell. It does mean, however, that you have to invest significant time to understand and learn the huge piece of shit that is systemd. Apart from professional sysadmins, whose time would be better spent administering their systems, I don't realistically see anyone else going to do that. It's video tutorials and just-do-this-special-trick wiki articles all the way.
Speaking of, is proper documentation at least theoretically available now?

Sysadmin are not the only users of Linux. Real sysadmin already known that leading distributions support the usual way of configuring a static IP address even with systemd. Proactive sysadmin already have learned systemd and are ready to manage it if it's not already the case. There is just a noise from a minority of 'sysadmin' that are neither maintainers, nor proactive, nor willing accepting that systemd will not be the end of the universe, and so frustrated that there can only wrote there distress in the forums.

Hahahahah.

Re: systemd rules!!!

[jcdr]

1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.

2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts. Just take a look at the reality:
https://packages.debian.org/je...
https://packages.debian.org/je...
https://packages.debian.org/je...
If you list the source patch archive http://http.debian.net/debian/... you will see that ALL the initscripts are Debian specific and not part of the original sysvinit http://http.debian.net/debian/... .
Configuring the network is not the same in Fedora an in Debian. On of the long term goal of systemd is to normalize the situation.

3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.

4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.

5) You can laugh as you want, this will not change the reality:
* Sysadmins are a minority of Linux users.
* Distributions like Debian support /etc/network/interfaces with systemd.
* There are sysadmin already using systemd.
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
* Still, a lot of forum get post from 'sysadmin' complaining.

Re: systemd rules!!!

[fisted]

1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.

I was asking for a source on your definition, not for you repeating your belief.

2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts.

Okay, init scripts are not a central part of the sysV init system. Today i learned. (Hint: init scripts /are/ the central element, conceptually, of system V init.)

3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here.

I suggest you practice reading comprehension, because you're so utterly missing the point, it's not even funny anymore. Hint: I claimed nothing about any of the straw man you're tearing down here. In particular I didn't suggest that users ought to ifconfig manually, or configure there IPs statically. If your attention span is too short to just read and follow the reasoning in order to understand what point i was trying to make, i can't help you.

sysadmin is not the dominant specie in the Linux world.

Another straw man, I didn't claim any of this. But now that you say it, yes, they actually are. People running linux at home essentially are their own sysadmins, people who run linux at work tend to rely on a sysadmin to do all the adminstrative crap for them.

The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.

It being ignored by users does not mean it's not the primary user interface anymore. You simply cannot completely admin/fix your system with a shiny GUI. So strictly speaking, the shell is the *only* real user interface.

4) Systemd is really simpler to learn that shell script.

I'm starting to wonder whether you're missing the point on purpose, or whether it's actual bad reading comprehension. I'll repeat myself, once more: Learning systemd helps you at doing systemd-specific stuff. Learning shell helps you at using your OS. Those two things have a large difference in scope of applicability.

* Sysadmins are a minority of Linux users.

Yet, they are fully exposed to all the shitstorm, and their job is to shield the users from that. So quite an important minority, if at all.

* Distributions like Debian support /etc/network/interfaces with systemd.

So what?

* There are sysadmin already using systemd.

So what? There are even more sysadmins running Windows networks and big monolothic "networking appliances"

* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.

That's only if you're ignoring existing solutions.

* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.

So what? Also, what does "there are still there" mean?

* Still, a lot of forum get post from 'sysadmin' complaining.

Yes. Do you really believe this would be the case if there was nothing wrong with systemd?

Note that all questions are of rhetorical nature, i'm not going to feed you any more.

Re: systemd rules!!!

[jcdr]

1) This is my definition is the context of this discussion. If you don't like it we can agree to name it differently. This will not change the reality that the procedure you mentioned did not use the usual infrastructure found on distribution to setup a static IP address.

2) Fine that we agree on this. But system V init in a C code that do exec(). The fact that it's usually a script is not required by system V init. But the main problem is not really script vs binary, the main problem is precisely the lack of normalization because anything on top of the bare minimal original system V init code is distribution specific.

3) The fact is that on most leading modern Linux distribution, this is not a script that call a command that setup the IP address of a network interface, because there use the NetworkManager package. Again you might not like it, but this will not change this reality. If you think that I don't understand your point, please try a least to repeat it. Actually you only deny some point.

4) Certainly not the system administrator according to http://training.linuxfoundatio... . I don't see the point calling a user system administrator regarding network operation when there simply let the dhcp client automatically configure an interface. Nor in the case where there select a SSID and enter a key. Nor when there use the NetworkManager GUI to select the Manual method on the IPv4 tab of an interface. In all those examples there is no scripts and no command involved.

5) It's perfectly possible to manage a very large number network situations with NetworkManager GUI without using any shell, script, or command. This is the primary interface for most of the users, including myself, even after working for years in a company that build routers. As a side note, this kind of GUI was all the customers constantly asked for, liked and used. Only the engineer and support used command to verify the state of the system. In the embedded systems I build today, the customer ask to configure the network from a web UI that push the configuration on a SQL database on the target, to illustrate how far is you idea of script and command.

6) Agree on the fact that scripts cover a more generic knowledge. Sadly this is not so useful on a system that use less and less scripts. I understand that you regret this evolution, but as the complexity of the system increase, scripts that are different in each distributions have reach a limit for many maintainers. Thing could have been different if the original system V init package would have normalized the script stack early. There failed to do that, now the time is probably over for them as systemd not only normalize the situation across the distributions but also bring a lot of new features on the table.

7) I wonder what's your work environment to be exposed to such 'shitstorm'. I have see time to time worker having to ask there superior to have the right to install a Linux system, but I never see the network administrator complaining.

8) All the last points is to show that your laugh are strange because all points can be independently verified true. There is no rhetorical nature in any of them, this is just a list of facts.

Re: systemd rules!!!

[fisted]

Okay i said i would not continue feeding you, but here's one last bite:

1) which is irrelevant to the topic because i picked the 'do it manually' example just for the purposes of illustrating how knowing the shell is useful in a generic way, while knowing systemd does not. Stop pretending that i had proposed everybody ran ifconfig to do things manually. If you really think that was the gist of my statement, then you must have missed the point (which is odd because you agreed with it that particular part later on)

I cannot really parse 2), especially the first sentence, but i agree that "normalization" (which i take for 'writing POSIX shell scripts instead of stuff riddled with bashisms') might have been a good idea, but then again, this is linux and the distro diversity is, apparently, a feature. (you can see the (rough) concept working very well on the BSDs (which don't do system V init, but rc is also script-driven (with configuration separate))).

3-5: Hilariously naive. This is all assuming that everything works, which is circular reasoning of the most ridiculous kind in a discussion directly related to the question whether things do or do not work. When something fails, you better hope that your GUI allows you to fix it, because if it doesn't, or if the GUI itself fails, you're left with the shell. I don't see how you can deny that that is the primary user interface.

6. Yeah, we call this 'integration' and 'feature creep'. It's a direct conflict with the principles that have led unix to its current success. We've seen how the integrated way turns out to work on other platforms. If you're in for a car analogy, this is like trying to tell bikers that they really ought to add another set of wheels, and replace their handlebar with a steering wheel, because it works so well with their cars.

7. the 'shitstorm' is implicit in the trouble and apparent pointlessness of 'just-because' migrating a larger set of computers to use the shiny new system. you might be used to just installing using a live cd and after that it more or less works, but in a bigger (and at my workplace that isn't even big, a mere ~200 machines) setup it's not that simple. (to get ahead of the obvious response: yes, installation, configuration etc is completely automated, the workload is not the installation itself, but ensuring "everything" the users are exposed to continues to work as expected. fixing a dozen self-maintained patches to components which have been upgraded (yes, we always submit the patches upstream, some maintainers don't care). I don't even want to imagine what would happen if the servers were linux based, too. For comparison, the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined. The former's uptime tends to be measured in days, the latters' in years...

8. I think I know better which of *my* questions are of rhetorical nature and which are actual questions, because, you know, i'm the one typing them. Or did reading comprehension get into your way again?

Re: systemd rules!!!

[jcdr]

1) So you admit to have purposely chosen the procedure that use shell scripts only to complain that it, err... use 2 shell scripts???

2) Diversity is an advantage up to the point where the added complexity is not too big. Sometimes it better to normalize to a common parts to simplify.

3) While making a good an complete enough GUI is fare from simple, this don't imply that this is impossible. NetworkManager is now mature enough to be used in a very large use case. This is the primary user interface for a lot of users. Most of them don't have a clue about shell script, so it's impossible to say to them that a shell script is there primary user interface. This is very factual: nor users, nor NetworkManager use script. I can only concede that commands in a shell (no script) are a possible fallback solution in case of problem impossible to solve with the GUI. But I disagree that a possible fallback that most users will never use is defined as a primary user interface.

6) Linux is not so UNIX anymore in the sense that it integrate more and more features compared than any others UNIX kernel. More and more Linux syscalls are not related to any UNIX standards. This is a new world emerging from UNIX but not bound to it anymore. Goodbye to anyone that like to stay with the UNIX way. This can make a lot of sens for some situations, and nobody will prevent them to do so. This is there respectable choice, and there could make an effort to respect the choice of others that want to follow the Linux way, unbound to the UNIX limitations. udev and systemd are required evolution steps to solve problems that have found no better solution using the UNIX traditional way.

7) Then I don't understand why you still use a Linux machine if BSD is so better for you. Really strange that your uptime is so small. I usually only reboot for hardware maintenance. One of the Linux servers actually show a uptime of 2121 days has soft RAID-1 and several virtual machines running on it. I plan to change it this year because some hardware parts are over 10 years old, but from the software point of view it run just fine.

8) As you have said to me 'Hahahahaha'...

Re: systemd rules!!!

[fisted]

1) God dammit, no. I give up trying to explain this to you since it looks like you're intentionally trying to miss the point.

2) That statement is meaningless and pulled out of your ass.

3) So there are two interfaces, one allows you to do some stuff, the other allows you to do all stuff, including fixing the first mentioned interface. BTW I'm not saying that a shell script is the primary interface, but that the shell is. The command line shell in particular. Do you understand the difference? (Rhetorical question; clearly you don't otherwise you wouldn't say something as ridiculous).

6) Yes, no shit, linux is not unix. That doesn't invalidate my point that the success came from adhering to the unix philosophy. There are already successful OSs that adhere to the opposite, so trying to turn linux into one is futile and stupid.

7) What in the actual fuck makes you believe I'd run Linux machine other than at work? I've made it clear 2 or 3 times, seeing how much you're missing or skipping here, is this language barrier?

You're not rebooting for security related fixes to the kernel or core components like libc? That figures.

8) The fact that this makes you laugh only shows that there really must be some sort of language barrier...

Re: systemd rules!!!

[jcdr]

8) Yes there is kind of language barrier as I usually speak French. Now the fact that you react with so much emotions and use rhetorical question don't help either our mutual understanding.

We obviously have each confidence in a different model of what the architecture of a distribution must look like. Probably that the use case we assume each for our analysis are very different too, and that could explain why we have some contradictions. If for you the shell very important, for me this is not the case.

3) I don't want to open an other conflict but I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users. This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.

6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init. After all, a lot of unix tools are written in C. I also don't think that the distributions make futile and stupid choice especially regarding the challenge of the experience there try to give to users without any shell knowledge.

7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.

Re: systemd rules!!!

[fisted]

I do observe that the leading Linux distributions make effort to make users able to manage there machine as much as possible without required to display a shell to the users.

Yes, that's basically been (at least) ubuntu's goal ever since it was first released. And, in my eyes, that's pretty pointless an idea, because running a GUI-only Linux gives you the worst of both worlds: GUIs that look and feel somewhat "bolted on", don't integrate nice with the system (due to the fundamental mismatch of paradigms) and are prone to frequent and major hiccups ranging from "just a short lag" to crash-and-burn. While getting the shit end of the GUI landscape (both Microsoft and Apple have that part worked out *much* better), you're also missing out on the efficiency and flexibility offered by the shell and the standard toolset. So what's left?
Ah right, a ton of free GUI programs a few of which even remotely usable (though generally inferior to their commercial counterparts). So, honestly, I don't get it. The use-case for GUI-only Linux, that is. To put it as a car analogy, it's as if you'd buy a shiny new car, then put in reverse and from then on completely ignore the gearbox, because reverse kind of works and it still takes you everywhere with 20 km/h. Only in the rare occasions where you accidentally break your rear window from reversing into something, you'd for a short moment shift into a forward-gear to get you out of the mess, then continue reversing.

This story is about Ubuntu first release with systemd, a distribution that is popular for peoples that have no clue about the shell. On this distribution a typical user will let NetworkManager try to configure the network automatically as much as possible, and if a manual setting is to be enter, the user most likely will do it using the NetworkManager GUI. The Arch procedure you looked at is hard to fit in the same users context.

Yes, that's right.

6) I don't think that Linux try to adhere to the opposite of the 'unix philosophy' and I don't observe that shell scripts play an important role in unix outside of the stack on top of system V init.

I've just sampled a few Linux machines i have access to (running debian stable and -oldstable, respectively), a quick look at /bin, /sbin, /usr/bin and /usr/sbin turned up around 300 shell scripts completely unrelated to system V init. Most of them simply don't have a .sh extension so when listing the directory they don't stand out. YMMV, would be interesting to see if that number goes down on systemd-enabled distros to see if your statement is true or not.

After all, a lot of unix tools are written in C.

Yes, but don't forget that "programs" are the building-blocks of shell scripts; it's one level of abstraction higher. The tools itself are written in C for good reasons (efficiency, mainly), the shell itself too, of course. It would be quite difficult to come up with the standard toolset completely written in shell, including the shell itself :)

7) I referred to you text: "the one Linux server that we do have (for automated installation of the desktops, nightly maintenance etc) needs more hand-holding than basically the remaining two dozen BSD servers need combined." I still wonder why you use Linux for this particular task if Linux cause so much problem for you and that you are happy with BSD.

The purpose of this server is to deal with all the desktop/office machines which run Linux. One half of the user base are (mostly surprisingly computer-illiterate) mathematicians, the other half is entirely computer-illiterate non-scientific personnel; secretarians, a janitor, etc. They're all expecting computers that work, are GUI-only driven, and, obviously, they're users, not root. Since it's quite a number of users, we discover quite a numb

Re: systemd rules!!!

[jcdr]

I understand that you find the GUI-only Linux ubuntu's goal pointless, but at the same time I read that you have many users asking for precisely this kind of systems. While your are doing the admin work instead of them within the company, it's logical that those peoples will select a distribution with GUI outside of the company related work. After all when those people use a smartphone, a router or a TV, all potentially running Linux, there don't expect to see anything other than GUI.

If we talk about the admin work, it's not fair to count /usr/*. On a typical Debian Jessie I have:
file /bin/* /sbin/* | egrep ELF | wc -l
233
file /bin/* /sbin/* | egrep script | wc -l
36
And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter. Actually I think there is still some binary that expect a shell evaluation at some point, but this is probably doable to work around them.

But as you have noticed, using command on a shell don't imply shell script. The NetworkManager project for example is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI. This allow to make some clean implementation not related to the preference of the user/admin regarding the CLI or GUI. This also help to make the GUI a relatively simple project that only query data, display them, allow fill form and send them. With this kind of project, you can use CLI and script if you want, as you can use GUI if you want. The trend is to apply this design to more and more parts of the systems, and systemd is a way to go forward in that direction. Personally I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.

If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed. You don't have to reboot to update the libc and you are free to decide if you like to update you kernel depending on the risk that apply to your situation. BSD kernel are released less often it seem, this don't make it less buggy as your RAID experience has show, but simply a consequence that his community of developers is smaller than Linux.. I really wonder what you can find so unstable in the Linux kernel because it's rock stable for me even on embedded systems where the workload and driver set is quite different to anything usually tested in the cycle of a kernel release.

Re: systemd rules!!!

[fisted]

If we talk about the admin work, it's not fair to count /usr/*. On a typical Debian Jessie I have: file /bin/* /sbin/* | egrep ELF | wc -l 233 file /bin/* /sbin/* | egrep script | wc -l 36

I don't understand why it wouldn't be fair to count /usr. There's no clean separation between what goes into /*bin and what goes into /usr/*bin in Linux; you find many elementary programs in /usr for twisted, for historical and for essentially no particular reason. Even having /usr be a separate partition is not recommended anymore, unless you're into building your own initrd (which non-admins wouldn't ever do, by (your) definition).

And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter.

Wow, hold on. Realize what you're saying, please. You're not exactly going to click on the programs provided by busybox in a GUI, are you? Or most of the other programs for that matter.
It's the very point of busybox to provide a set of programs which /only/ make sense in a shell, and by extension, are get used in scripts. Why provide busybox at all, otherwise??

NetworkManager [...] is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI.

Okay, I wasn't aware of that split. If it's indeed a clean separation, then it's not so bad, indeed.

I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.

*vomits*

If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed.

Not sure how a GUI application is related here, FAI clearly is not a GUI and the Linux server obviously doesn't run X11.
But you're right, it was an unfair comparison, let's see:
The Linux server run: a) PXE/thttpd for network booting, b) nightly cronjobs to do maintenance on the desktops, c) a Debian repository.
The BSD servers are: fileserver, redundant mailservers (smtp(s)/pop3(s)/imap(s)), redundant nameservers, DHCP, httpd, sshd, redundant LDAP, print server, a captive portal for one of three wireless networks, firewalls, NAT gateways, svn server, you-name-it. Probably a few other common services that currently don't come to mind. Essentially a full-fledged, rather traditional production network, with amazing availability. (You know, the kind of thing people mistakenly believe "the cloud" to provide ;)).
So, unfair a comparison indeed, but not really the way you meant it, i guess.

You don't have to reboot to update the libc

Don't be ridiculous. Every userspace process directly or indirectly uses libc, so yes, instead of rebooting you could indeed manually stop all the services and kill all remaining tasks until the system is essentially single-user, and then get all the services going again. But no, only a complete idiot would actually do that. For all practical purposes, it would equal a reboot (and underlines my point of high degrees of hand-holding)

and you are free to decide if you like to update you kernel depending on the risk that apply to your situation.

Sure, but there's only one policy here that makes sense, and it equally applies to all

Re: systemd rules!!!

[jcdr]

dpkg --get-selections | wc -l
3423

dpkg -L $(dpkg-query -Wf '${Architecture;-20}${Priority;-40}${Package}:${Architecture}\n' | egrep "all|amd64" | cut -b21- | egrep "required|important" | cut -b41-) | grep "/usr/s*bin/.*" | xargs file | egrep " script, " | wc -l
56

And 17 of them are perl scripts. The rest are mostly not so used commands. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.

I mentioned busybox to show that binary commands is enough to admin a box (outside of system V init), not about a supposed busybox GUI.

I have see a lot of Linux boxes with load like the one you describes on your BSD box, this is not impressive at all. Now, did your Linux kernel really crash ? I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.

About the libc update, you might find more simple to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade, how did you do with your BSD boxes ? Or the BSD libc is so perfect that no upgrade is required ? Hint: https://www.freebsd.org/securi...

You call me ridicule, but I largely prefer restarting some services on a remote machine., and even more when the machine also act as a NFS server, or a router, or a firewall, or have virtual machines. It's a choice, and I will not call you ridicule for your own choice.

If you are so conservative to reboot each boxes as soon as a libc or kernel upgrade exists, then I wonder how your BSD boxes could have uptime a "few orders of magnitude less shitty".

I do tests on the system I deliver, and my customers do tests too, I just say that this is tests not usually done in the cycle of a kernel release [by the kernel maintainers] (last part added for you understanding).

You can't usually buy the systems we design as there are not for consumers. What I can tell you is that we have build systems where conformity to part of aerospace, or railway, or automotive, or civil engineering standards are required. Nothing highly critical, but still with a good chunk of audit and conformity tests. Customers are happy enough with our work to allow, to setup our own company 4 years ago.

But I would like to remain you the this discussion is about the fact hat Ubuntu has released his first version with systemd :-)

Re: systemd rules!!!

[fisted]

I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.

And I still call bullshit because scripts are every admin's (and that doesn't even stop with systemd) best and most valuable tool. I don't presume you're seriously going to claim that even admins could completely forgo of the shell? Or would want to do that in the first place? (Hint: automation). If a sys- and network admin entirely using GUIs to do their job is what you imagine, then you're so far away from reality, it's not even funny anymore...

I mentioned busybox to show that binary commands [are] enough to admin a box

And what do you think is the execution environment for literally every single of those tools? Seriously if you were even slower, you'd go backwards.

I have see[n] a lot of Linux boxes with load[s] like the one you describe[d] on your BSD box[es], this is not impressive at all.

That wasn't mean to impress, i was merely responding to your claim about unfair comparisons. Nice try, but it would help if you would consider the parts you reply to in their actual context, instead of trying to create and tear down straw men like this.

Now, did your Linux kernel really crash[]?

Yes, I've seen uncountable instances of linux panicing.

I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.

I didn't say the reboots required by updates were a stability problem; they are an availability problem, however.

About the libc update, you might find [it] simple[r] to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade[s], [what] [do] you do with your BSD boxes[]? Or [is] the BSD libc [] so perfect that no upgrades [are] required[]? Hint: https://www.freebsd.org/securi...

Hint: It's not FreeBSD, and Hint: if the BSD servers receive a libc update that fixes a security issue we're affected by, then the server gets rebooted. Not that i hadn't already said that in the post before.

You call me ridicul[ous], but I largely prefer restarting some services

if it's a libc fix, "some" services will not cut it.

It's a choice, and I will not call you ridicul[ous] for your own choice.

Well if you choose to go for a reboot-less libc security upgrade just to keep uptime (yet losing availability), then i'd actually ridicule you for that, because it'd be a moronic waste of time. If you get paid by the hour, maybe.

If you are so conservative to reboot each box[] as soon as a libc or kernel upgrade [appears], then I wonder how your BSD boxes could have uptime[s] a "few orders of magnitude less shitty".

See above.

aerospace, or railway, or automotive, or civil engineering standards

So, let's assume you're designing some aerospace-grade embedded system, linux based no less. Would you make it use systemd? Why not?

But I would like to rem[ind] you th[at] this discussion is about the fact [t]hat Ubuntu has released [their] first version with systemd :-)

Sure. Let's see how it works out.

Re: systemd rules!!!

[jcdr]

The fact that a sysadmin use a shell command interpreter did not imply that the command he call are shell script. I think that I have show enough prove that shell scripts are not as essential outside of system V init as you used to claim. Now, this don't prevent anyone to use a shell to get a CLI and to write some scripts if he like to do so. You seem to forget that the maintainers decision to switch to systemd is not to remove power to the users, but to make the maintainers work more easy and reliable across multiples systems. I never stated that sysadmin should be forced to use GUI, and projects like systemd or NetworkManaged take care to provides very good CLI, so I don't understand how stressed you are about the systemd architecture.

About the comparison between Linux and BSD kernel, you still failed to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes. At some point you have to admit that the Linux box do something that your BSD boxes can't do. You never explain the part of the Linux kernel that cause the supposed crash, and I am very curious about this because triggering a kernel crash is usually not so easy.

A reboot for a upgrade will not affect to much the availability because it only affect the users for a minute or so, contrary to a stability problem like crash that could affect the users as long as someone take to reset the machine. So I think we can at least agree that the upgrade on Linux is no affecting your operation more that your BSD boxes. It you really have a particular problem with your Linux boxes, than must be something as severe as a kernel crash, not because of upgrade. And if you can really crash a up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause the crash.

I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...

Restarting services take less time than rebooting (especially with systemd), this is less risky on a remote machine, and this affect the availability far less than a reboot because many services are capable to handle restart very fast, and others services are unaffected. In industrial systems there are situation where we just want to upgrade some part of the system while still let running others realtime parts unaffected. You might be in a context where you can just reboot, but there exists others contexts with more constrains than in your environment. You can ignore this fact, as you can continue to insult me, this will simply change nothing to the reality of the facts. And no, our company don't charge per hour.

I would be more than happy to design any futures systems with systemd into it. I delivered my first design with systemd last week and given the success I see no reason to go backward. A mission/life critical aerospace system with not use a Linux kernel anyway. But for less critical functions, even in aerospace, this could done. In fact there is already exists systems running Linux in aerospace environment, it's not hard to find on the internet.

Re: systemd rules!!!

[fisted]

The fact that a sysadmin use[s] a shell command interpreter d[oes] not imply that the command[s] he call[s] are shell script[s].

So your idea of a sysadmin is someone who keeps typing the same commands over and over again, every day or week, rather than automating them in a script? Good grief.

I think that I have show[n] enough pro[of] that shell scripts are not as essential outside of system V init as you [] claim.

So you don't understand what a proof is, besides not having a faint clue of real-world systems administration. Duly noted.

Now, this do[es]n't prevent anyone [fr]o[m] us[ing] a shell to get a CLI [lol what] and to write some scripts if [they] like to do so. You seem to forget that the maintainers['] decision to switch to systemd is not to remove power [fr]o[m] the users, but to make the maintainers['] work [] eas[ier]

Ah, okay, maybe that's the issue then. Because so far i had assumed systemd would provide immediate benefits to the users, because that's kind of what a million pimply-faced systemd fanboys claim.

s[o] I don't understand how stressed you are about the systemd architecture.

I thought i had made that clear. Anyway, the recent 3-4 comments were more about shell scripting in general than about systemd in particular.

About the comparison between Linux and BSD kernel, you still fail[] to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes.

You clearly are a complete idiot and not paying attention, if you would actually follow this moronic discussion you'd have ran across:

I'd love to have them run *BSDs, but since they're even less meant for the 'GUI-only desktop' use case, the amount of work required to support that would require more than four admins (good ones of which are hard enough to find for linux already).

A reboot for a upgrade will not affect [???] the availability because it only affect[s] the users for a minute or so

Thanks for another demonstration of how all your sysadmin "knowledge" is purely theoretical and pulled out of your ass. Read this.

So I think we can at least agree that the upgrade on Linux is no[t] affecting your operation more that your BSD boxes.

That's only because the Linux server sits around idle unless it's 4am or an office machine is reinstalling.

And if you can really crash a[n] up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause[s] the crash.

I have already realized you're not paying attention, or mentally incapable of doing so, that was in a timespan of at least 5 years. And when talking about "Linux machines i've seen crashing", I'm not specifically referring to that one particular single FAI server. That's not to say that it hadn't had its share of problems, but the bulkload of Linux machines i've seen panicing happened in private contexts. I'm still not sure if you're seriously trying to say that Linux would be free of problems. But you're a troll or a raging zealot, so whatever.

I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...

I (obviously) know that p age, and had you cared to actually take a look at it, most of those SAs are userspace related, and we have evaluated every kernel-related one for whether it affects us or not. The user-accessible ssh login gateway was affected to some, and subsequently got rebooted.
Why am i explaining this to an armchair sysadmin?

Restarting services take[s] less time than rebooting (especially with systemd), this is less risky on a remote machine, and

Re: systemd rules!!!

[jcdr]

You can use shell scripts to automate your work if you like and use systemd commands into your scripts without any problems. The point is that systemd don't require scripts to work and is not based on scripts, as for the large majority of commands used for basic administration. You can keep trying to avoid to recognize the reality of the facts by just saying that I an idiot or ignorant., this again and again does not change the facts.

Yes systemd provides benefits to the users. What I have say id that systemd don't remove power to the users.

No, you have not make clear what real and factual problem systemd might have for your. You have show a poor knowledge of what systemd really is actually and you react with far too much emotions to be able to generate a simple list of facts.

4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...

If you like definition: http://en.wikipedia.org/wiki/A... Clearly restarting a services take less time than a reboot, and a crash that require a manual reset is the work case. If you reboot like you like to do, the fact that the machine is idle or full loaded will change nothing. You still fail to provides real facts that explain why you find Linux so inferior compared to BSD.

You have say many time that BSD is superior to Linux (by order of magnitude), but you allay failed to prove your claim. Now you are spanning the time and includes private use into the context. Just saying that something is crap is not going to convince anyone, especially if after so many messages you are still incapable to details a single factual example.

What prevent you to do the same security management on Linux as you do on BSD? This do not depend on the OS, nor on systemd / sysvinit. A libc security fix very rarely affect the security of all the processes in a system. Free to you to degrade the availability of the servers by rebooting them if you want, but again this has nothing to do with Linux or systemd. And for your knowledge: Debian and Ubuntu automatically restart systemd/sysvinit in case of libc upgrade (and the services listed as affected). It's not a mental challenge to verify this fact. The procedure you describes seem to imply that netBSD is not able to do the same.

Yes this is a success because multiples devices was tested across very different operating conditions transitions, and systemd not only did fully work as expected, but this was a pleasure to operate remotely since all the status and management are more simple and coherent than with sysvinit. I named all the custom applications with the same prefix, so a simple 'systemctl status prefix*' show everything at once.

You still show irrational stress about systemd. The reality is that all majors distributions have adopted it, so yes it will go into embedded systems, and yes it will go into aerospace environment over time but certainly not into critical grade application (nor sysvinit anyway).

Bye,

Re: systemd rules!!!

[fisted]

4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...

Try reading instead of gibbering like a drooling idiot. That was not about supporting a linux server, but supporting a desktop GUI-only installation base for clueless users, you clueless twat.

Re: systemd rules!!!

[jcdr]

I have read you, and I have not used the word "server" in the context of this "4 admins more" paragraph. I have perfectly understand that you are talking about your users that you fail to convince to use BSD as you fail to convince me to use BSD. Despite all your angry comments about Linux and systemd, at some point you should have to agree that actual Linux distribution bring a more usable system for for more users than BSD. Wherever you dislike this situation will change absolutely nothing.

Easy escape of all others point?

Re: systemd rules!!!

[fisted]

I'm not trying to convince the users to use BSD (hilarious thought, like the users a) had a say in it or b) could tell the difference anyway), neither am i trying to convince you to use BSD. Why do you keep making up stuff like this?

Easy escape of all others point?

I don't feel like wasting more time with you by deciphering your incoherent gibberish and giving long-ish answers just to find you aren't reading them anyway.

Re:systemd rules!!!

[Megol]

How about you go fuck yourself? Fucking idiot...

Upstart or Systemd?

[Viol8]

Its like asking whether you'd preferred to be mauled by a rottweiler or a pitbull.

Both are just change for changes sake and neither bring much new to the table. Sure the scripts for init could get messy but they worked, everyone was familliar with them and if no major issues have cropped up since 1991 (or 1970 for unix) then its a fair bet its a reliable sub system.

But no , the "Not Invented Here" meme popped up its ugly head again and some know it alls decided they could reinvent the wheel better. Well so far the jury is still out on that.

Re:Upstart or Systemd?

[Threni]

> But no , the "Not Invented Here" meme popped up its ugly head again and some know it alls
> decided they could reinvent the wheel better. Well so far the jury is still out on that.

You say that, but why have nearly all distros moved to systemd? You're saying there's not a sound technical reason for it? NIH makes sense as a criticism in a few areas, but linux distros, largely run for free by hobbiests? They're imposing it on themselves for no good reason? Really?

Re:Upstart or Systemd?

[Viol8]

Never underestimate the power of the herd mentality.

"but linux distros, largely run for free by hobbiests?"

Its not 1995 anymore.

Re: Upstart or Systemd?

[Anonymous Coward]

Linux distros are *not* run by hobbyists. all the ones worth any salt are run by large corporations.

Re:Upstart or Systemd?

[Dutch Gun]

You say that, but why have nearly all distros moved to systemd? You're saying there's not a sound technical reason for it?

Sure, there's a good reason. It makes things a lot easier for *them*.

Whether it makes things better or worse for everyone else remains to be seen.

Re: Upstart or Systemd?

[Anonymous Coward]

Arch Linux is kick ass, and is run by about 30 developers who have full time jobs elsewhere.

Re:Upstart or Systemd?

[ookaze]

Its like asking whether you'd preferred to be mauled by a rottweiler or a pitbull.

Both are just change for changes sake and neither bring much new to the table. Sure the scripts for init could get messy but they worked, everyone was familliar with them and if no major issues have cropped up since 1991 (or 1970 for unix) then its a fair bet its a reliable sub system.

But no , the "Not Invented Here" meme popped up its ugly head again and some know it alls decided they could reinvent the wheel better. Well so far the jury is still out on that.

Actually, what you say just says a lot about your knowledge of these sysadmin issues : you know nothing at all and you are spewing nonsense, which perhaps will fool people that aren't interested in these issues, or will be brushed off as ignorance by people affected by these issues.
The outcome will be the same in both cases : what you say won't have any credence and is completely useless.
I don't know in which world you live where "so far the jury is still out on that", you must have missed the last 6 months at least : it's over.
And your vision of systemd is wrong by the way : educate yourself please.

Re:Upstart or Systemd?

[Viol8]

"And your vision of systemd is wrong by the way : educate yourself please."

How about you tell me then. Apparently you're such an uber admin that surely it'll be no problem to list the advantages of systemd compared to init. Right?

Re:Upstart or Systemd?

[gmack]

It worked.. except when it didn't. I should not have to hack my init scripts just because I have iSCSI or Clustered Fileystem mounts. Init was made in a time when the boot dependencies are more flat and don't do well at all when your setup requires network+daemon before the filesystem can be mounted.

Re:Upstart or Systemd?

[thaylin]

SystemD helps distro developers, there is no denying that. the denying is that it helps the systems themselves and the administrators who manage them.

Re:Upstart or Systemd?

[Anonymous Coward]

Whether it makes things better or worse for everyone else remains to be seen.

But lets not that stop the wild speculation!

Re:Upstart or Systemd?

[ookaze]

You say that, but why have nearly all distros moved to systemd? You're saying there's not a sound technical reason for it?

Sure, there's a good reason. It makes things a lot easier for *them*.

Whether it makes things better or worse for everyone else remains to be seen.

No it doesn't remains to be seen, it's pristine clear that it's better for everyone else, as the "them" you're talking about are the only people affected by this change.
Which is exactly the reason why everyone else don't understand what the change is about, they were never aware of this part of the system, except when they were affected by a bug in it (and there are tons of bugs still present today in upstart, bandaids and the like).
It's striking to see that when Debian had sysvinit, Ubuntu made Upstart because sysvinit was such a pain. But the switch of Debian to systemd was enough of a step forward compared to managing Upstart alone, that Ubuntu decided to switch to systemd.

Re:Upstart or Systemd?

[ruir]

It is quite well known in Debian the decision was politically motivated and backed by several ex-RH elements of the board.

Re:Upstart or Systemd?

[Viol8]

Oh right. Because the systemd config is sooo simple in a situation like that.

Re: Upstart or Systemd?

[jcdr]

Are you certain that Debian fit your definition ?

Re: Upstart or Systemd?

[higuita]

slackware is kick ass for a long time and have the same 1 full time developer since ever.
but there is also a brigade of (part-time) hackers helping him behind the shadows

Re:Upstart or Systemd?

[gmack]

It is actually. Systemd has mount unit files that can specify before and after dependencies so I can tell it I want it to load after the network and daemons they depend on but before things like ftp, apache etc.

This is actually a problem I needed to solve.

Re:Upstart or Systemd?

[Anonymous Coward]

I guess the dream of an open source community composed of volunteers typing code with a laptop next to a fireplace still lives on. :)

Unfortunately software is so complex these days that it requires large professional teams from big companies.

Re:Upstart or Systemd?

[present_arms]

I;m so grateful that I use a distro that doesn't use systemd :D I can't even get the bastard to install on this machine, instant kernel panic on all systemd distro's

Re:Upstart or Systemd?

[armanox]

When you understand that Red Hat controls the Linux world, and what they do everyone will follow (with the exception of Slackware and Gentoo), you will understand.

Re:Upstart or Systemd?

[ookaze]

"And your vision of systemd is wrong by the way : educate yourself please."

How about you tell me then. Apparently you're such an uber admin that surely it'll be no problem to list the advantages of systemd compared to init. Right?

I won't do your work for you, and you must be a pretty bad one to talk about things you don't even know about.
If reading skills and understanding skills are so challenging to you, you won't understand a thing, which is probably what happened already, given the copious amount of documentation available on systemd. There never were any for sysvinit and its scripts, and a very bad one for Upstart.
Besides, you need experience with sysvinit or Upstart to understand the biggest advantages of systemd.
Given my experience, I just don't take people that say sysvinit (or Upstart) had no problem seriously, less of my time lost this way.

Re:Upstart or Systemd?

[ookaze]

It worked.. except when it didn't. I should not have to hack my init scripts just because I have iSCSI or Clustered Fileystem mounts. Init was made in a time when the boot dependencies are more flat and don't do well at all when your setup requires network+daemon before the filesystem can be mounted.

Exactly! When you have several layers on top of your block devices, like RAID and LVM, it's even worse.
It was such a pain before, despite the LVM or multipath daemons, I was never sure the servers would reboot correctly, or the config freeze or corrupts itself.
Such a nightmare before systemd tackled the problems and sometimes the bugs in kernel or daemons, now it just works.

Re:Upstart or Systemd?

[LordLimecat]

Im sure RedHat engineers have no frigging clue what theyre doing, they should troll the slashdot boards more often for the grains of wisdom found here,.

Re:Upstart or Systemd?

[LordLimecat]

And the RedHat decision was motivated by...?

Re:Upstart or Systemd?

[Anonymous Coward]

What they bring, you thick headed luddite, is programmatic/automated control and upgradeablity.

Do you know what using arch and gentoo taught me?

Init scripts, config files are fine when you set them up.. But a fucking lovecraftian nightmare of otherworldly pain when it comes to the basic, ordinary task of updating your software.

Your lovingly handcrafted, custom, tailored, special snowflake init script house of cards shits itself royally when it needs to be treated like a modern OS.

Fork, do what you want, and shut the fuck up. The rest of the world is moving on.

Re:Upstart or Systemd?

[BobSwi]

Slackware4Life

Re:Upstart or Systemd?

[armanox]

I'm down with that.

Re:Upstart or Systemd?

[nabsltd]

And the RedHat decision was motivated by...?

Money

The more opaque and difficult you make the system, the more likely people will pay for support.

Re:Upstart or Systemd?

[Anonymous Coward]

then you didn't know what you were doing.

Re:Upstart or Systemd?

[armanox]

I'm pretty sure they know what they're doing - but that doesn't mean they are acting in everyone's best interest either.

Re:Upstart or Systemd?

[nabsltd]

Systemd has mount unit files that can specify before and after dependencies so I can tell it I want it to load after the network and daemons they depend on but before things like ftp, apache etc.

When this works, it's great, but when even mounting NFS (what used to be quite a simple thing) can cause the system to hang because of errors, it's not really a step forward.

On previous init systems, if your NFS mount wasn't available before the subsystem that needed it, then that subsystem might not start up correctly, but the system would finish booting and give you a login prompt A little tweak to a startup script to add a check and the problem is solved for the next boot, with only a little time when the service isn't available (after a manual start). But, I've seen systemd just stop the boot process when it can't fulfill a dependency like this, and the only solution was to reboot into single user mode, tweak config files, and try the boot again.

Re:Upstart or Systemd?

[CronoCloud]

What, you trying to run 64-bit on 32-bit hardware or something?

Or trying to run Fedora 21 on a desktop from 1999?

Re:Upstart or Systemd?

[Anonymous Coward]

Given what I've heard about some of the RH engineers from other RH engineers, I'm quite sure that more than half of them have no fucking idea what they are doing.

Re:Upstart or Systemd?

[Anonymous Coward]

You might consider running your network script before your heavy file system mounts. Don't need gigbytes of Fascistware to do that.

Re:Upstart or Systemd?

[gmack]

What is happening is that Systemd is waiting for either the daemon to come up, or a timeout before it continues. If you wait about 5 minutes, the boot will resume. (which I agree is an annoyingly long default) The downside of doing things the way they were before was that if something was slow to mount, the system would blindly continue which is why I've seen a ton of boot scripts with sleep statements in them.

Re:Upstart or Systemd?

[gmack]

So all of the distros use the same network config as Redhat? Same /etc/sysconfig path? Same RPM package manager?

Re:Upstart or Systemd?

[Eunuchswear]

It is quite well known in Debian the decision was politically motivated and backed by several ex-RH elements of the board.

Name them?

Re:Upstart or Systemd?

[Anonymous Coward]

Wow, just wow.

There's plenty of documentation for Sys V init, although mostly once you got the very simple conventions down, just reading the init scripts is fine. It's just a bloody init system after all, not trying to be an all-singing, all-dancing uber software fuehrer.

If something requires a "copious amount of documentation" such as systemd, it's way too complicated.

And you still didn't answer his question, so I doubt you have real experience with sys V init. (Me, I've been using Unix systems since before there was a System V, or even a System III.)

Re:Upstart or Systemd?

[armanox]

Most distros use GNOME. Most distros use PulseAudio. Most distros use NetworkManager And now, most distros use systemd. I'll let you guess who pushed most of these? Guess who is responsible for PulseAudio, NetworkManager, systemd, libxml, gnulib, and very large portions of the GNOME project? And who is the only player that matters for commercial Linux (Oracle doesn't count since OEL is rebuilt RHEL)? Keep telling yourself Red Hat is just /etc/sysconfig and RPM (actually, RPM IS the standard package manager for Linux based on the Linux Standard Base)

Re:Upstart or Systemd?

[eriqk]

Both are just change for changes sake [...]

Can people please stop regurgitating that nonsense?

Re:Upstart or Systemd?

[Anonymous Coward]

I'm sure they know exactly what they are doing.

RH Management: We will start laying off engineers due to lower than expected revenue.
RH Engineer: How so?
RH Management: The OS is too stable and companies are getting by with CentOS and Scientific Linux. Do you have any solutions to this predicament?
RH Engineer: We will create something unstable, force it upon everyone, and call it Systemd!
RH Management: Sounds like a plan. Let's green light this!

Re:Upstart or Systemd?

[maevius]

Yeah, because I'm sure that the engineering costs are small in order to build a new system and win 2-3 years of "opaqueness" until everybody gets accustomed to systemd.

obligatory...

Re:Upstart or Systemd?

[jcdr]

Complete lie. If you have read the debian-devel mailing-list you will find many many many times the demonstration that the move to systemd was done by technical motivation only, and started many years before a minority (of auto-proclaimed representative of the majority of the users) make an over-sized big mess up to the point a multiple vote was done to go back to real work. The claimed gigantic dependency implication of systemd proved to be a full hoax that destroyed thousand of workday by itself alone.

Re:Upstart or Systemd?

[Eunuchswear]

Well, that was a failure then, in comparison to sysvinit systemd is limpid.

Re:Upstart or Systemd?

[geoskd]

Sure, there's a good reason. It makes things a lot easier for *them*.

By definition, "they" have to solve all of the same problems you do, and the same problems eevryone else has to who uses it. They have the same learning curve that you do, only they have the challenge of going first, before there are 10 billions hits on google explaining how to fix xyz idiosyncrasy. "They" did not make this decision lightly, as it means just as much work for them as it does for everyone else. "They" made the decision because it was the right decision. There are far too many people I have run into who claim to be Linux zealots who cant handle the DIY aspect of the system. If it bothers you that much, do what I do. wait a while before adopting the latest release. Give them a few months to work out the cruft, and establish all the how-tos for some of the more obscure stuff. In short, let the early adopters do the heavy lifting, and then enjoy the benefits that systemd does provide. Let the people who enjoy being on the bleeding edge do what they do best. In the end, if all the init systems had shown up on the scene at the same time, systemd would have won out hands down. I have seen two arguments against systemd. The first is that it doesn't do XYZ. This *always* turns out to be that it *does* do XYZ, the complainer just didn't know how to find what they were looking for because it had moved from the place they were used to looking for it. The second complaint is that systemd is new, and will have bugs. By that argument, we should have stopped making technological improvements with the invention of the wheel because any new technology will have bugs.

Re:Upstart or Systemd?

[RabidReindeer]

Systemd config files ARE simple.

The problem is, some of that simplicity comes from discarding certain commonly-used features of SysV systems.

I really could learn to appreciate systemd. If they'd stop trying to make it the emacs of the OS nucleus and let it JUST manage system initialization instead of bring in its own non-replaceable logging system and other unrelated adjuncts.

And, of course, if they'd address returning the functionality that they took away.

Re:Upstart or Systemd?

[jcdr]

System V init was simpler because it was designed at his time to satisfy the demand of the system user at that time. We are talking about the early 1980 here. Since then a quarter of century passed and now the computer technology have evolved in a gigantic scale. The most simplest smartphone sold today is many more complex that anything imaginable at the system V time. This complexity have to be managed by some code in the system. The system V init idea was that it only have to provides the absolute minimal and that all the complex stuff should be managed by something external of the init project. So many incompatible scripts emerged up to the point that it's now impossible to normalize the situation. Project maintainers and distributions maintainers get more and more annoyed, especially since users ask for more and more dynamic systems. System V init failed to evolve and the layer on top of it became a unsustainable mess that even the system V init fail to support in a better way in there anemic reactionary projects.

Upstart proved that something way better can be build to replace system V init and his ugly stack of scripts, and now systemd is good enough to definitively turn the page of system V init for the eternity.

I used system V init on embedded system since late 1990 and I just delivered my first system using systemd this week. This was a easy move that saved me days of works because systemd service file are way simpler than any init script and far more reliable. I can right now remotely monitor the system in production using systemctrl and journalctrl command like never before with system V init.

Re:Upstart or Systemd?

[dbIII]

You say that, but why have nearly all distros moved to systemd?

RedHat staffroom politics and Gnome club politics. It's addressing the non-problem of a bunch of things being under the control of a lot of different people instead of just under Lennart's control. The "faster boot" never happened and was never a big deal outside of systems too small to sanely consider systemd anyway - the old init not doing much is faster than starting the systemd "cathedral" to not do much.

Re:Upstart or Systemd?

[dbIII]

Since some of them in high positions have been working a lot less time than Slashdot has been around that is far less of a joke than you think.

Re:Upstart or Systemd?

[dbIII]

I used system V init on embedded system since late 1990 and I just delivered my first system using systemd this week.

You are a brave man to go in blind. I've been using systemd stuff on test boxes for more than six months and I've seen and worked around far too many fuckups to want to use it on an important production system, but at least I'm prepared to do some workarounds if I actually do.

Re:Upstart or Systemd?

[Anonymous Coward]

It wasn't to make the OS opaque therefore generate sales of support, but it makes the *system builder*'s life easier. Not the system maintainer, but the one making the OS package.

RH don't have to debug running systems that YOU deploy. YOU do. What RH have to do is make an OS that combines multiple systems that have different configuration paradigms and make it work under their System Manager GUI.

And THAT is made much easier if they write their System Manager to deal with systemd and them make every package write to systemd design.

It works for Apple for the same reason: if you're the only one making decisions on how things work, you can mandate how things are configured and therefore make it easier for the system tools you write to maintain or configure the entire system. It means too that you get to write how systems in the future will go.

And THAT point is why so many people, myself included, DO NOT WANT systemd.

Sans-systemd, configurations were more like Windows installers or Printer configurations: each installer used their own. And it meant that because there were so many different types of installer or printer configurators (cromulent word made up there!) you had a high likelihood of something not going to plan.

Which meant that de-installation on windows would say "This doesn't seem to be used any more. Can I delete it? I can't tell" which is as annoying as fuck, but when you understand that the problem is that all those installers merely *look* like they're all Windows System products, they're not and could be doing something odd, then you understand why.

SystemD makes RH's life writing a GUI to set up and configure the system easier. Even the journal logging system, especially in binary form, makes parsing log files *with what metadata RH thinks they need* much easier. At the cost of making it impossible to do without following RH's needs. Even if

a) you don't need that or
b) you need something different

The two problems that make me avoid systemd are that this now becomes "What RH wants, not what the package needs". RH becomes the Apple of Linux. Telling everyone what to do or fuck off out of Linux. This is antithetical to the FOSS and even Linux community. The second problem is that once written, this will not shift except to nearby possibilities. This will be more inefficient, bug prone and delay improvements to the system and progress in the future. Since you'd have to do without all the systemd stuff, because it's an all-or-nothing deal. Or getting so. It's still at Extend, Extinguish is a way off, but not far.

systemd makes making a distribution easier if you're RH, and easier if you use RH tools rather than your own. KDE and GNOME will have to chase RH and ape their toolchain to get it in their window manager systems, or just hand off to RH, making them less able to configure non-RH compliant systems using the RH toolchain. Enlightenment and other smaller windowing systems will have to play ball and won't be able to avoid just handing off to the RH chain. Smaller distros not wanting RH and wanting a lighter, leaner or just different configuration will be removed because they will have to change hundreds of packages in their internals, or use systemd. Which means chasing RH changes to systemd and duplicated effort for the PRECISE SAME result.

That latter point means that your end result will not be the same result, but the exact same output. Unlike gcc/intel/other compilers that implement the same standard but get different code that should, canonically, have the same result, you'd get the exact same output, but have to write your own software to write it out. With the same bugs in the output. The same constraints. The same pitfalls and the same force to comply. Dampening out innovation and experimentation in any package that touches anything that the extending spread of the various parts of systemd decides to replace.

Re:Upstart or Systemd?

[Eunuchswear]

crickets

Which of:

Bdale Garbee
Russ Allbery
Steve Langasek
Don Armstrong
Keith Packard
Colin Watson
Ian Jackson
Andreas Barth

Is an "ex-RH element"?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729

Re:Upstart or Systemd?

[Barsteward]

"systemd is a system and session manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit."

journal - captures Syslog messages, Kernel log messages, initial RAM disk and early boot messages as well as messages written to STDOUT/STDERR of all services, indexes them and makes this available to the user. It can be used in parallel, or in place of a traditional syslog daemon, such as rsyslog or syslog-ng.

for more info http://www.freedesktop.org/wik...

Re:Upstart or Systemd?

[maevius]

Just sayin'

Re:Upstart or Systemd?

[ruir]

i guess there are many lunatics of a "minority" then out there. And it is not a lie. As for technical reasons given the Debian insistence in stable and true and tried packets, is still quite a mystery how systemd was used as the default so soon.

Re:Upstart or Systemd?

[jcdr]

is still quite a mystery how systemd was used as the default so soon.

You call it a mystery because you ignore the fact that all the process has been discussed openly, voted, and archived in a way anyone can access it.

Re:Upstart or Systemd?

[ruir]

Being "democratic" does make it better.

Re:Upstart or Systemd?

[LordLimecat]

But if theyre the ones making the packages, they sort of have the say in how those packages are built. That is to say, if you dont like it, build your own packages. It seems perfectly legitimate to me for a software developer to make choices that may have tradeoffs in order to reduce the complexity of the development; this is a pretty common thing in fact.

And if it turns out that the things RedHat is designing their software to do dont meet your needs, I would wonder why you would use Red Hat.

Fuck systemd.

[Anonymous Coward]

oh, and double fuck beta too.

SystemD

[Anonymous Coward]

Ubuntu Linux 15.04 is NOT the first release of Ubuntu Linux to include the clusterfsck called systemd. I have it installed as part of an update to Ubuntu Linux 14.04. It has even infected prior versions running in VMs on my computer causing the performance to degrade to early 1990s era PC. Incredible!

CAPTCHA: miseries (oh so appropriate)

Re:SystemD

[ruir]

pint systemd to -1 as I did with my Debian 8. At least it will buy me two year more without systemd.

Re:SystemD

[jcdr]

And by posting here with your infected machine you spread even more your disaster... Now my shinny new 4K screen degraded to early Archean in a stack of mineral.

systemd, eh?

[serviscope_minor]

Systemd, eh? I predict that this thread will be filled with sensible and rational comments.

Personally, I'm not a fan. It's overly complex to the point of being nearly undebuggable which makes it much harder to fix than the older system. Frankly it's also written by Pottering and given the awful experience I've had in the past and still sometimes have with PulseAudio, I don't really trust it. It's fine to have PA crap itself and require a restart (well, kind of annoying in the middle of watching TV, but survivable). I rather hope he's written systemd somewhat better.

I know the distribution makers like it because packaging stuff is easier, but the end user experience (the end user being me) is IME inferior. But I care about debuggability, hackability and simplicity over having a very heavily intetegrated desktop "experience".

Re:systemd, eh?

[TWX]

Requiring a restart is a Windows trait. I was hoping that my Linux installations would be better than that.

Re:systemd, eh?

[serviscope_minor]

Requiring a restart is a Windows trait. I was hoping that my Linux installations would be better than that.

Er quite, though I was specifically referring to restarting PulseAudio, which takes a second not the entire computer. If the base underlying init process needs a restart, well, that's a different kettle of fish.

Re:systemd, eh?

[Dutch Gun]

I'm still amazed that anyone still falls for the Dice-sanctioned systemd-related trolling at this point. Everyone seems to have made up their minds, and the debates have long since ended. Systemd won, and anyone who doesn't like it has to go looking for alternatives.

Re:systemd, eh?

[Rich0]

Requiring a restart is a Windows trait. I was hoping that my Linux installations would be better than that.

Er quite, though I was specifically referring to restarting PulseAudio, which takes a second not the entire computer. If the base underlying init process needs a restart, well, that's a different kettle of fish.

FWIW, the only time I restart systemd is to update the kernel, or I guess systemd itself (though the kernel changes more often and thus I can usually lump the latter in with the former). If you do live-patch your kernel, then you can do the same with systemd - it has a command to re-exec itself while preserving state.

I'm sure it isn't perfect, but it is as robust as anything else I've used on Linux. There are fairly few daemons that I've never seen need a restart sometime in the last 10 years.

Re:systemd, eh?

[serviscope_minor]

There are fairly few daemons that I've never seen need a restart sometime in the last 10 years.

Pulse Audio. On one machine it's fine. On another it needs regular restarts.

Re:systemd, eh?

[Anonymous Coward]

Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage. Somehow it's not surprising that systemd itself (the software) operates in a similar top-down manner, forcing adoption by creating new dependency issues.

Re:systemd, eh?

[thaylin]

As robust is not following the if it aint broke dont fix it model.

Re:systemd, eh?

[Anonymous Coward]

> overly complex to the point of being nearly undebuggable

Even worse is the fact that it ignores exit statuses and swallows stderr which makes it impossible to troubleshoot problems. While starting a process fails, systemd typicaly deletes all traces of why it happened.

Re:systemd, eh?

[ruir]

Pulse audio in my server farm? Right... Many of us are using Linux for servers, you know?

Re:systemd, eh?

[ruir]

If you say so. Apparently is not true, but then.

Re:systemd, eh?

[ookaze]

Systemd, eh? I predict that this thread will be filled with sensible and rational comments.

Personally, I'm not a fan. It's overly complex to the point of being nearly undebuggable which makes it much harder to fix than the older system. Frankly it's also written by Pottering and given the awful experience I've had in the past and still sometimes have with PulseAudio, I don't really trust it. It's fine to have PA crap itself and require a restart (well, kind of annoying in the middle of watching TV, but survivable). I rather hope he's written systemd somewhat better.

I know the distribution makers like it because packaging stuff is easier, but the end user experience (the end user being me) is IME inferior. But I care about debuggability, hackability and simplicity over having a very heavily intetegrated desktop "experience".

It's obvious you're not a fan of systemd, you can't even manage a Linux OS properly, restarting because of a PA crap (which would normally show a audio Linux module bug) that you're unable to handle correctly and then talking about debugging the init of your system which is far harder to do.
Actually, debugging systemd startup is easier (or I should say faster) than debugging Upstart, especially the dependencies, there are tools included in systemd that do nearly everything for you.
Besides, a sound server has nothing in common with an init system, so making comparisons between the two shows no technical knowledge at all.
The end user experience of Ubuntu is not about the self-contradictory "debuggability, hackability and simplicity", it's about simplicity which contradicts your "hackability" statement.
I don't see how the end-user experience is inferior, this makes no sense. When you change your timezone in the graphical UI and it is now synchronized automatically with the underlying OS, and the change is visible in the command line, when it was not the case before with Upstart (or sysvinit), that's an improvement in my book.

Re:systemd, eh?

[higuita]

Won?! no, i just checked... my slackware is still working fine here!!

Re:systemd, eh?

[serviscope_minor]

I have no idea why on earth you made that comment.

Re:systemd, eh?

[Anonymous Coward]

True.

Just annoying that the alternatives are a little bit thin on the ground.

BSD or Slackware or whatever-that-debian-fork-was-called?

Re:systemd, eh?

[Anonymous Coward]

Rational comment. What a mistake. I'm trying to build a initramfs to pxe boot. I studied the way the init script launches systemd and after building the proc, dev, sys, pulling in all of the arguments from the cmdline, setting up all of the environment variables and paths, it gets to last steps and performs a switch_root /NEWROOT /sbin/init. /sbin/init is symlinked to /usr/lib/systemd/systemd. That launches and proceeds to immediately disables the usb keyboard. I'm left to wonder what the heck is systemd is doing? It's so freaking wonderful knowing that systemd is doing it's initialization in parallel and so quickly yet have no way to see what it's actually doing. What do all of the 50+ binaries really do (and why isn't anyone complaining about the bloat). SysVinit was barely 100k of scipts. Systemd is 5MB, it acts slower and requires reboots to fix. Thanks for the UPGRADE!!!

Re:systemd, eh?

[Anonymous Coward]

systemd didn't "win" anything. It is being shoved down people's throats.

It's going to turn out like pulseaudio: a complex piece of crap that is great in theory (and I DO like most of the theory behind systemd and pulseaudio), but causes so many problems* that most of the times you're better off just using ALSA. It was made by the same people, it was also shoved down people's throats despite much wailing and gnashing of teeth, and it STILL doesn't work properly after like 10 years in development.

* I have 5 different machines that suffer from random audo bugs, from distortion to the mic not working. Restarting pulseaudio fixes the problem...until it happens again. Just to give an example.

Re:systemd, eh?

[serviscope_minor]

I like how you don't know me, don't know what problems I'm having or what they symptoms are, but obviously you know best. Out of interest, do you grow a beard all the way down your neck while brushing cheeto dust off your ample belly and shouting at n00bs? From a dwelling in your mother's basement? Because your smug, condesending attitude, combined with your complete lack of knowledge or ability to read sure feels like it.

restarting because of a PA crap (which would normally show a audio Linux module bug)

Then tell me why (a) restarting PA fixes a module bug and (b) why ALSA works perfectly?

Actually, debugging systemd startup

You know, I can almost feel the smugness exuding from your pores when you said that. Tell me where I mentioned startup? Oh wait, I didn't. Because I wasn't talking about startup was I now?

Maybe mr smug, you can tell me where on earth the ACPI events from the sleep key are going and why SystemD refuses to pass them on anywhere sensible.

Besides, a sound server has nothing in common with an init system

Apart from, the person who wrote them. Which is the point I was making if you bothered to read my post through your mointain-dew induced nerdrage.

The end user experience of Ubuntu is not about the self-contradictory "debuggability, hackability and simplicity", it's about simplicity which contradicts your "hackability" statement.

Nope.

I don't see how the end-user experience is inferior, this makes no sense.

Because I can't debug problems when they arise easily. That makes it pretty inferior to me.

When you change your timezone in the graphical UI

When I do which with the what? I never change the timesone in the "graphical UI". Not really sure why I should care about that.

Re:systemd, eh?

[Anonymous Coward]

I'm curious to know what you are doing with audio that requires restarting PA? I haven't had a single problem with PA is years.

Re:systemd, eh?

[jcdr]

I first used systemd on a complex custom embedded project that dynamically switch between multiple loads and it have saved me days of work compared to previous designs. Dependencies are managed the right way, and status+analysis tools are very good.

PulseAudio is unstable I agree (I juste deleted a ~1.5GB .xsessionerror filled with insanity from it, and it crash at least one a day), but not so systemd, even if journald need some more work to fix some minor issues.

Re:systemd, eh?

[Anonymous Coward]

I have since stopped using Redhat, Fedora, and Ubuntu or debian. I recommend to all my colleagues not use them either and most agree. We'll see what happesn to the ecosystem in next 5-10 years as those distros slowy die off.

Re:systemd, eh?

[ookaze]

Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage. Somehow it's not surprising that systemd itself (the software) operates in a similar top-down manner, forcing adoption by creating new dependency issues.

Was that an exercise in truth inversion?
The Linux ecosystem is exactly what made systemd "win". And the rise of systemd occurred in a bottom-up manner actually.
systemd actually didn't win anything, it just allowed the streamlining of using the Linux kernel specific features that nobody used because of catering to the lowest denominator. I was not surprised at all at how fast true admins got rid of sysvinit or even Upstart.
On the machines I control, I've done this more than 15 years ago, going with simpleinit-msb for most of this time, before having to switch to an alternative because maintaining it was leaving me sometimes with security vulnerabilities to fix alone.

Re:systemd, eh?

[Lumpy]

Actually better than normal. a slackware install is at least two orders of magnitude faster than Ubuntu.

I've moved back to slackware for ham radio use, I got tired of fighting with the 6 different audio systems, 40 different places to put config files, etc...

OSS and /etc with a custom kernel. Boot time on my field Ham radio PSK31 CF-18 toughbook is 6 seconds (Yes to an Xf86 login). with Xubuntu it was 45 seconds.

Re:systemd, eh?

[Anonymous Coward]

don't restart after a glibc update?

Re:systemd, eh?

[LordLimecat]

Because comparing an end-user facing daemon to a core system dependency is a little nuts. One will be tested to a much higher level than the other.

Re:systemd, eh?

[LordLimecat]

not the choices of linux users or the linux ecosystem.

Great news, you can pick your ball up and go home to roll your own distro. You dont have to care what RedHat does.

Obviously if package makers start targetting SystemD, that will affect you, but then again you can also make your own packages if you dont like their decision.

Re:systemd, eh?

[Anonymous Coward]

Er you mean bottom-up, as in people who actually do the work get to choose. That is what open source is all about.

Re:systemd, eh?

[Anonymous Coward]

And the rise of systemd occurred in a bottom-up manner actually.

You'd make a good politician -- not afraid to state the absurd as if it were the truth. It's obvious to everyone here that systemd was simply dumped on the linux userbase (top-down), rather than the userbase asking for it (bottom-up). Most linux users (even sysadmins) didn't even know about the project until the surprise dependencies started popping up. That's something that I can't recall ever happening before in my 18 years of linux experience.

Re:systemd, eh?

[Anonymous Coward]

Really, my first thought was that the chum was in the water as more clickbait.

Re:systemd, eh?

[caseih]

Linux audio sucked before pulseaudio. I would never go back to the old days.

What is undebuggable about systemd? What problems are you having? It's modular and verifiable, and it's quite a bit easier to debug service problems than init scripts (am I the only one to have to turn on set -x in an init script to find out what is going on with hacked scripting logic?). There are lots of reasons to dislike systemd particularly with how it deals with syslog, but your arguments seem a bit tired.

Re:systemd, eh?

[Dutch Gun]

Hrm, yeah, I should have put quotes around "won", because what I meant was "most major distros are using it", nothing more. Let's look at some of the top Linux distros:

systemd camp:
Mint
Ubuntu
Debian
Mageia
Fedora
openSUSE
Arch
centOS

Non systemd camp:
PCLinuxOS
Slackware
Gentoo

How many in that list do NOT use systemd? For those folks who don't want to use it, it may be increasingly difficult to avoid it without jumping ship to BSD, because it's very possible you're going to be seeing more and more dependencies on it. That's all I was getting at.

Re:systemd, eh?

[MSG]

it ignores exit statuses and swallows stderr

No, it doesn't. Exit statuses are the means by which it detects and reports that a service started successfully or failed. Stderr is recorded in both the journal and syslog messages file. I verified both on CentOS 7 and Fedora 21 a moment ago.

Re:systemd, eh?

[Anonymous Coward]

This! systemd makes my job nearly impossible. I work on a team of four that manages about 250 servers for an MSP. Our customers create problems on the servers constantly when installing new software or making configuration changes. Not having access to the exit status or syslog messages makes life difficult. It's so bad that we modified our ticketing system to automatically block off four times as much time if the server is running Red Hat 7 versus 6. So, a group of guys with more than seventy years of UNIX experience between us takes four times as long on average to fix problems. I have the data. I imagine that someone who doesn't do this for a living would simply just be screwed with systemd. If you don't know strace, it's impossible to track down problems when using systemd.

Re:systemd, eh?

[serviscope_minor]

What problems are you having?

It's eating the ACPI events from the ACPI sleep button and refuses to acknowledge that they exist and won't send them anywhere. I flat-out cannot get anything hooked up to them.

and it's quite a bit easier to debug service problems than init scripts

This is the thing. Everyone here seems to assume the problem is init scripts/service scripts. Systemd does an awful lot more than that now and so it has opportunities for a much, much wider range of problems than starting services.

but your arguments seem a bit tired

How on earth is the argument that it doesn't work, I can't figure out what's going on, and no one else has been able to figuire either "tired"? Unless you're tired of hearing that systemd isn't the be-all perfect system?

Re:systemd, eh?

[Anonymous Coward]

..I was not surprised at all at how fast true admins got rid of sysvinit or even Upstart.

Jings. crivvens, help ma boab!, 'tis the 'No true Scotsman' in aw his glory!

Re:systemd, eh?

[MSG]

The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage

Do you think Free Software was historically a democracy in which everyone voted and a team of developers slavishly set to work, granting their every wish?

No. Free Software systems were developed by people who needed the features that they wrote. Or wrote the features that they needed. Same thing. However you phrase it, the people who did the work made the decisions about what work was done.

And who is implementing systemd? The people doing the work. People who are willing to do the work to maintain a system which uses a different init will have a system with a different init. It's as simple as that. Slackware is such a system.

Re:systemd, eh?

[Thanatiel]

If only I had mod points ...
I think the first time I got angry at systemd was trying to debug what was going wrong on a test system.

Re:systemd, eh?

[Anonymous Coward]

ignores exit statuses and swallows stderr

Which makes me want to pick-up my signed copy of Advanced Programming in the UNIX Environment by W. Richard Stevens, and beat some sense into Lennart Poettering. He has no respect for what made UNIX great. He just doesn't get it.

Re:systemd, eh?

[Anonymous Coward]

I have since stopped using Redhat, Fedora, and Ubuntu or debian. I recommend to all my colleagues not use them either and most agree. We'll see what happesn to the ecosystem in next 5-10 years as those distros slowy die off.

Stopped recommending Redhat/derivatives about 15 years ago.
Stopped recommending Ubuntu after 10.10. (five years ago, give or take, ISTR that was a fun month )
Stopped recommending Debian as of last month.

At work, my Debian desktop and servers days are numbered (they were supposed to be gone by the end of this month). The Slackware server will survive for a month or so longer than the Debian ones, Management have spoken.

I'm currently still running Debian on my home desktops and Slackware on my servers, but as there is still a possibility
that Slackware may have to go down the systemd route as it continues to poison the rest of the open source tree life a nasty software equivalent of Scolytus scolytus, I'm currently looking at both NetBSD and OpenBSD to replace them, as well as installing a new version of Windows on a home machine for the first time in over a decade.

If it does happen to Slackware and I have to go down this road, then this will be a sad day, and I will toast the happy memories of 22+ years with a decent single malt, then proceed to get royally drunk on absinthe and/or rum.

Re:systemd, eh?

[Anonymous Coward]

Many of us are using Linux for daily desktops, you know? Your server farm's existence doesn't make PulseAudio any less junk.

Re:systemd, eh?

[hitmark]

And distro maintainers had to pick it or forgo "the" desktop for Linux, Gnome. And even if you don't use Gnome directly, more and more of its internals are likely to depend on something that depends on Systemd, thanks to everything from Freedesktop.org is being scarfed up.

That old Mafia line about a deal you can't refuse comes to mind...

Re:systemd, eh?

[Anonymous Coward]

"Systemd "won" because of the choices of distibution maintainers, not the choices of linux users or the linux ecosystem. The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage."

Truth.

Systemd/Fedora used "embrace & extend" tactic that Microsoft became so known for. Your average distribution has a suprisingly small amount of people whose job is to integrate packages into a cohesive whole and ship it out. Systemd/Fedora put them in a position where they either adopt everything they want, or fork & develop/maintain a growing number of packages -- all while not living up to their lipservice.

e.g., first it was udev, which is pretty important if you use removable media. Sure, you could build systemd and then only use the udev binary, but then that started getting harder. Then Poettering even started lobbying things like GIMP of all things to depend on systemd. Now, if you want to use Gnome3 -- or even ship it for your users -- it depends on logind, etc. It was pretty brutal and effective, all while they could go "you're getting this for free, you don't have to use it!"

Mark my AC words: we're heading for a corporate endgame where the GPL is run-around due to systemd. It's the goal of pushing kdbus into the kernel as well as sucking in everything from dns to a time server into systemd. Their corporate clients have the issue of shipping proprietary software & the LGPL on linux, but if it's just communicating with all the libraries as a service, well....

Re:systemd, eh?

[Eunuchswear]

So where is the bug report?

Re:systemd, eh?

[LinuxIsGarbage]

Just like how Open SSL would be a core functionality for many servers, yet there there are only 11 developers working on it.

Re:systemd, eh?

[Anonymous Coward]

"Developers slavisly set to work, granding their every wish"

Historically, noone did anything slavisly in Free Software. Users used what fit their technical and political needs. Programmers didn't and don't work on projects simply and solely because they 'needed the features', they worked on projects for a variety of reasons, including scraching a technical need, advancing a larger project (like the GNU system), curiosity and learning, as well as having the greatest impact on the greatest number of users. To claim all Free Software programmers work for pure short-sighted selfish interest is a bald-faced lie.

Users didn't take what they were giving slavisly, either. Users chose software for a variety of reasons, including learning, ease of use, difficulty of use, utility, size of userbase, friendliness of community, and attitude of developers. And us stupid uses who aren't part of your assaholic 'do-ocracy' helped you, too, by giving you a userbase (see above), submitting bug reports, doing all the shit-shovelling of writing documentation and maintianing wikis and tech support, and all the other crap that the programming 'do-oracy' gods don't want to sully their hands with.

Systemd isn't the same as other changes. The way it blatently and intentionally creates dependencies, and the clear trajectory it is on to gain equal footing with the kernel as an essental part of what defines a 'Linux' operating system, is completely unlike the modular nature of Free software on GNU/Linux systems to date.

Fuck your do-ocracy. Us stupid lusers count too and you ignore us at your peril.

Re:systemd, eh?

[Anonymous Coward]

My systemd ArchLinux install with Cinnamon boots in 17 seconds on a $350 Thinkpad with a $40 SSD

Re:systemd, eh?

[Anonymous Coward]

Maybe he thinks it's inappropriate for any distribution to be useful as both a server and a home media server.

Re:systemd, eh?

[Eunuchswear]

Another moderation that demonstrates the insanity of the anti-systemd trolls.

Even if you hate systemd for valid reasons, what kind of moron is going to mod up a comment that is a straight out lie just because it is anti-systemd?

Re:systemd, eh?

[Eunuchswear]

Maybe mr smug, you can tell me where on earth the ACPI events from the sleep key are going and why SystemD refuses to pass them on anywhere sensible.

Works for me. Maybe you could describe your environment in more detail?

Re:systemd, eh?

[jcdr]

Recommendation from an Anonymous Coward...

Re:systemd, eh?

[Anonymous Coward]

So iTunes and Photoshop and games in a systemd container communicating with the rest of system and other libraries with kdbus? Is that really possible?

Re:systemd, eh?

[Anonymous Coward]

I have no real preference as far as systemd. I could do without it but I'll give it a chance. I am a Kubuntu user though and some of the "known issues" look like real show stoppers for me at the moment

Re:systemd, eh?

[Anonymous Coward]

I don't understand what you hope to gain by claiming that it doesn't. Multiple people here have posted good repro steps in order to demonstrate that it does. I've seen it happen with at least three different services (MySQL, MongoDB, and Elasticsearch and maybe others). For the Elasticsearch one, if you don't have JAVA_HOME set and `which java` doesn't work, then it exits with a message and an exit status of 1. That message is not saved in the journal and systemd still returns a zero exit status. It is broken. Rather than defending something that is broken, it seems like it would take less energy to just fix the problem.

Again, people posted repro steps, and I gave another example of a systemd bug so why you defending systemd?

Re:systemd, eh?

[thegarbz]

The rise of systemd occurred in a top-down manner, which is the exact opposite of how traditional open source software gains acceptance and widespread usage

Wow. I never met someone who actually uses Linux From Scratch.

Re:systemd, eh?

[dbIII]

Sometimes it turns up on servers with a relatively lean RHEL/Centos install and starts running when you don't even have X going - I have killed it on servers when they were running short on memory.

As an aside, a really weird side effect of pulseaudio is that if you block the port it uses it can really speed up remote X - got no idea what Lennart was thinking with that bug/feature. It's things like that which make me wonder why he's being allowed near an init system.

Re:systemd, eh?

[MSG]

Again, people posted repro steps, and I gave another example of a systemd bug so why you defending systemd?

Because I copied and pasted those steps into both CentOS 7 and Fedora 21 systems. Exit status was reflected in a "failed" state as expected, it wasn't thrown away. Messages written to stderr were recorded in both the journal and the syslog messages file. The steps described to reproduce the problem do not reproduce the problem on any system I have access to.

Re:systemd, eh?

[Anonymous Coward]

Alright, so it doesn't ignore exit statuses or swallow stderr, but it does cause autism.

Re:systemd, eh?

[Anonymous Coward]

"So iTunes and Photoshop and games in a systemd container communicating with the rest of system and other libraries with kdbus? Is that really possible?

Yup, it's why systemd... an init system... is so focused on getting systems running in containers along with communicating via services for functionality instead of libraries/etc. If you want xyz library, you can install it on the host linux machine, and communicate with it via systemd as the interface. iTunes and Photoshop can have whatever they want without pulling in lgpl code with their binary shipped as a container. It's going to be really bad when people wake up to this.

Re:systemd, eh?

[Anonymous Coward]

CLOSED:WONTFIX - It's a feature, not a bug.

Re: systemd, eh?

[Anonymous Coward]

You don't open bug reports for shitty software with fundamental design deficiencies, and, is broken by definition.

Or shall I create that systemd patch I've been dreaming of? The patch that removes all lennart code and replaced with sysvinit.

Re:systemd, eh?

[buchanmilne]

Not having access to the exit status or syslog messages makes life difficult.

1)Don't omit Type=, or use Type=simple, in the case of a non-simple process, you probably want Type=forking
2)Surely you're learned how to use 'systemctl status foo' or journalctl ?

Re:systemd, eh?

[buchanmilne]

Maybe mr smug, you can tell me where on earth the ACPI events from the sleep key are going and why SystemD refuses to pass them on anywhere sensible.

The sleep button works perfectly here on a system running systemd and KDE. Maybe you have a problem somewhere else.

Because I can't debug problems when they arise easily. That makes it pretty inferior to me.

The only seemingly valid complaint I have seen is that systemctl doesn't provide the exist process. But, this is only the case for Type=simple (yes, the default type), where you probably want Type=forking or Type=oneshot.

Re:systemd, eh?

[Eunuchswear]

I asked for the bug report number, not the resolution.

Nobody will provide one because no such bug has never been opened.

Which tells you all you need to know about the reality of these wierd claims.

Re: systemd, eh?

[Eunuchswear]

Bug report:

      * What led up to the situation?

I tried to talk to a troll

      * What exactly did you do (or not do) that was effective (or
          ineffective)?

I asked a question, hoping for an informative answer

      * What was the outcome of this action?

The troll gibbered at me

      * What outcome did you expect instead?

The same thing.

Oh, drat, it's not a bug, the troll is working as expected.

Re:systemd, eh?

[Anonymous Coward]

So start writing and maintaining the system you want to see. Don't complain that Redhat are writing systems that Redhat wants to see while you sit around complaining that Red Hat are writing software.

Re:systemd, eh?

[Anonymous Coward]

The GPL is run around because of systemd? How does that work? As far as I know, every version of systemd has the source code available for everybody to see.

Re:systemd, eh?

[Barsteward]

no, he's correct. its amazing that some sysadmins think that its okay for a computer to simplify other peoples lives but as soon as a system comes along that threatens their cosy little domain by making admin easier (once learnt) they get the shit-fits.

Re:systemd, eh?

[Barsteward]

"Now, if you want to use Gnome3 -- or even ship it for your users -- it depends on logind, etc" - i guess your typical troll pig ignorance is showing. poettering actually wrote a bit of software so Gnome didn't have to use logind but Gnome decided not to use it. http://www.linuxvoice.com/inte...

i'll mark your AC words as Trolling based on ignorance

Re:systemd, eh?

[Barsteward]

don't hold your breath too long

Re:systemd, eh?

[Barsteward]

don;t make stupid comments on the word of ignorant trolls, it makes you look stupid

Re:systemd, eh?

[Barsteward]

systemd does not use those 50+ binaries unless you configure systemd to use them - sounds like you don;t know what you are talking about

Re:systemd, eh?

[Barsteward]

"It's eating the ACPI events from the ACPI sleep button and refuses to acknowledge that they exist and won't send them anywhere." - have you done anything about reporting as it not every computer labels ACPI events in the same way? have a read of this https://wiki.archlinux.org/ind... - configuration section to see if helps

Re:systemd, eh?

[serviscope_minor]

Works for me. Maybe you could describe your environment in more detail?

Yeah, it works for most people. It's an arch laptop running on an eee 900. Its an otherwise fairly stock install. It boots in commandline mode and I start graphics using "startx". I run FVWM, not any of the big "desktop" environments.

Sleep works fine, using both writing to /sys/state/mem and issuing a command over dbus. Also the sleep key works fine (well, the underlying key works, and the Fn button works), so I assume the combination does, as it did before the reinstall with dbus.

I'm completely stumped, so I welcome any suggestions at this point.

Re:systemd, eh?

[serviscope_minor]

Nope. Sleep over dbus works. The keys are fully operational and it worked prior to reinstalling a dbus system.

The only seemingly valid complaint I have seen is that systemctl doesn't provide the exist process.

So my point that when something that ought to work doesn't and I can't figure out how to debug it is simply not valid? I can see why dbus-haters get all riled up. Apparently reasonable complaints are met with complete dismissals.

Seriously, how on earth is my complaint not valid?

Re:systemd, eh?

[Anonymous Coward]

Recommendation from an Anonymous Coward...

Oh, FFS!
As to experience: 22 yrs Linux, 30+ yrs Unix variants (and if we want to talk assembly, 35 yrs.)
As to Slashdot: the system I first registered on Slashdot from was a Sun 3/60, god knows exactly when - the earliest account that I can remember having here has a 5 digit UID, the last, used as late as 2011, was a 7 digit one (and there were a couple both betwixt and before these).

So, why am I AC here? two main reasons,
firstly, these are open forums, there is no requirement for me to register to post

secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)

As to recommendations: the people I recommend the systems to know who I am, the fact that you don't know me is neither here nor there, and doesn't seem to bother them.

Having an active username here doesn't magically make you somehow right, and ACs wrong. The system allows for ACs to post, much as it seems to bother you, some of us ACs have been in the game for a long time. As a registered user, you don't even need to see my postings as an AC, you can filter them out, so you see them at your choice.

Re:systemd, eh?

[Anonymous Coward]

i guess your typical troll pig ignorance is showing. poettering actually wrote a bit of software so Gnome didn't have to use logind but Gnome decided not to use it. http://www.linuxvoice.com/inte...

i'll mark your AC words as Trolling based on ignorance

Well, it's showing for one of us. :) Maaaaybe don't believe everything Poettering is misrepresenting in these types of cases.

You can go check the Gentoo and other bug reports for yourself: Gnome3 made logind a mandated dependency. I'm sorry if this is hard for you, but it's simply the reality of the situation and what has gone down. It was eventually worked around so that you could use it without it, so long as you didn't want any power management and other things... It's straight from the horses mouth.

This is a classic example where you're told something technically true, but the important bits are left out so you're misled. And sadly, Poettering is known for that at this point.

Re:systemd, eh?

[Eunuchswear]

Also the sleep key works fine

By which you mean? What happens when you press the sleep key?

Re:systemd, eh?

[Eunuchswear]

I'm completely stumped, so I welcome any suggestions at this point.

I suppose you've checked out https://wiki.archlinux.org/index.php/Power_management

Re:systemd, eh?

[jcdr]

What did you try to prove by showing that you are just a few years older than me ?

secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)

How can I trust your recommendations if you are not even able to administrate your very own accounts ?

Maybe there is a reason why you find any leading modern Linux distribution too complicated for you.

Re:systemd, eh?

[ruir]

Interesting. i am using a highly customised, very lean Debian 8. I block/uninstall everything I dont need, including kernel modules. Might start making my own package of the kernel once kernel 4.1 comes out. As for systemd, I have pinned it and some other "niceties" to -1, no "turning up" by accident.

Re:systemd, eh?

[Anonymous Coward]

What did you try to prove by showing that you are just a few years older than me ?

Err, I think you were originally questioning the right of me, as an AC to give recommendations, I was pointing out that I'm more than qualified to do so (and I didn't even put in any of the Microsoft systems stuff, nor the hardware design)

secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)

How can I trust your recommendations if you are not even able to administrate your very own accounts ?

Because, unlike the accounts I have kept going for a long time (e.g. the email address I've had for 22 years) these accounts are trivial/transient..the universe didn't ouzelum the day I could no longer log in using any of them, there was not a wailing and gnashing of teeth..
There's this thing called 'sense of proportion'.

Maybe there is a reason why you find any leading modern Linux distribution too complicated for you.

Oh, for sure...leading...modern..complicated...
dotage is a wonderful thing..

Re:systemd, eh?

[serviscope_minor]

Now? Nothing.

However, the F1 key works and the FN key works, so in other words, the physical key works perfectly. And the sleep key worked perfectly before the upgrade to systemd. So, it seems overwhelmingly likely that systemd is the problem since it subsumed control over ACPI events from acpid.

Re:systemd, eh?

[jcdr]

I was pointing out that I'm more than qualified to do so (and I didn't even put in any of the Microsoft systems stuff, nor the hardware design)

I can pretend to be equally qualified than you. You don't impress me, nor you add credit to your recommendations.

secondly, I can't be bothered either recovering the old accounts (email addresses - even servers, associated with them are long gone, figments of history..)

How can I trust your recommendations if you are not even able to administrate your very own accounts ?

Because, unlike the accounts I have kept going for a long time (e.g. the email address I've had for 22 years) these accounts are trivial/transient..the universe didn't ouzelum the day I could no longer log in using any of them, there was not a wailing and gnashing of teeth..
There's this thing called 'sense of proportion'.

So if it's not proportional enough, why did you mention it is the first place ?

Maybe there is a reason why you find any leading modern Linux distribution too complicated for you.

Oh, for sure...leading...modern..complicated...
dotage is a wonderful thing..

Wonderful to avoid the word "too" "for" and "you". This show how you ignore what you don't like.

Re:systemd, eh?

[Wolfrider]

--You can add Linux Mint Debian Edition to the non-systemd camp:

http://www.linuxmint.com/downl...

Sigh...

[Anonymous Coward]

/...reads headline.......this crap again???...... goes back to work

All I'm going to say here, is that I'm not beholden to 1 dist or another at this point. Nor am I 'committed', to Linux. There are alternatives. Nothing is off the table at this point!

Ahhh Systemd and Ubuntu

[Anonymous Coward]

I know how much Slashdot loves Systemd and Ubuntu. Pairing them together? Wonderful. Can't wait to see your responses!

Systemd...raped me last night.

[Anonymous Coward]

I struggled to get away but it held me down. it kept saying "systemd-modules-load.service loaded failed failed Load Kernel Modules" while it thrusted in and out. Why did this happen to me? Why!?!?!

Re:Systemd...raped me last night.

[Anonymous Coward]

Did you dress all slutty?

Welcome to the party

[ttyX]

Welcome to the party Canonical :)

So, then there we are.

[udippel]

Fools rush in where Angels fear to tread.
The world is coming down.
At least the world of Free Software that was so close to my heart for the last 15+ years.
The simplicity of U--nix has reached the EOL. So has modularity.
Welcome, to new shores, the new U--s, full of mischievous monolithic blocks that accompany us from after PID 1 to shutdown and start our daemons, log us on, guide, lead, help, protect our systems and its users throughout the lifespan of their sessions. And beyond. From cradle to the grave - from boot to halt.

This is not my world any longer.

Re:So, then there we are.

[Anonymous Coward]

Jesus Christ you neckbeards go all f'ing hyperbolic over the most mundane shit...

Re:So, then there we are.

[Anonymous Coward]

Jesus Christ you neckbeards go all f'ing hyperbolic over the most mundane shit...

Except, in this case I'd say it isn't pure hyperbole, more elegaic than anything else..maybe a mite dirgeful?

Re:So, then there we are.

[Megol]

...

This is not my world any longer.

Welcome to the real world. Welcome to adulthood. Here we have to learn new things, try it.

Contradictory summary?

[wonkey_monkey]

the adage "don't fix what isn't broken" is clearly one 15.04 plays to.

Uh huh...

systemd [...] replaces the inhouse UpStart init system.

Hmm.

Re:Contradictory summary?

[Anonymous Coward]

upstart was broken by design, not that I think systemd is that much better

Re:Contradictory summary?

[Anonymous Coward]

You liked upstart?

Re:Contradictory summary?

[Anonymous Coward]

the adage "don't fix what isn't broken" is clearly one 15.04 plays to.

If Ubuntu followed that it would not exist. It gives no improvements over Debian just a buggy experience an ugly interface and a bad reputation for Linux

Re:Contradictory summary?

[netvaibhav]

the adage "don't fix what isn't broken" is clearly one 15.04 plays to.

Uh huh...

systemd [...] replaces the inhouse UpStart init system.

Hmm.

I think it meant "If you're happy with 14.04, don't upgrade."

SWEET

[Khyber]

Can't wait for the vulnerabilities I found and gave to some nice hacker friends to hit systemd right as it's hitting 'prime time' and beats it back into obscurity.

Re:SWEET

[Anonymous Coward]

So your l33t hax0r friends are gonna bring down systemd? I hope they're behind at least *12* proxies.

Re:SWEET

[ookaze]

Can't wait for the vulnerabilities I found and gave to some nice hacker friends to hit systemd right as it's hitting 'prime time' and beats it back into obscurity.

So you found vulnerabilities but don't even know how to exploit them ?
People talking about things they don't even understand...

Re:SWEET

[Anonymous Coward]

He might not want to risk going to jail himself.

Re:SWEET

[Anonymous Coward]

Wipe your chin off, you're dribbling again. (hint: Your comment makes no sense and was responding to a joke).

Ubuntu: The End

[Chas]

Systemd? No thanks.

Re:Ubuntu: The End

[oodaloop]

So you suffered through Unity, but systemd is what turns you away? Huh.

Re:Ubuntu: The End

[Anonymous Coward]

I actually *clapped* after reading this. Mod parent up!!

Re:Ubuntu: The End

[Thanatiel]

I cannot speak for the original poster, but I discarded Ubuntu for the desktop because of Unity.
And now I'll discard it for the servers because of systemd.

If we were 20 years ago, I'd joke about systemd being a pet project of Microsoft to ruin the Linux ecosystem.

If needs to be, I'll go so far as making my distro myself to avoid systemd.

Re:Ubuntu: The End

[Eunuchswear]

So you suffered through Unity, but systemd is what turns you away? Huh.

No, he suffered through upstart and systemd is what turns him away?

Re:Ubuntu: The End

[Anonymous Coward]

KDE > Unity

Re:Ubuntu: The End

[Chas]

Nah. Unity was the first stab of seppuku.
Systemd was the jumonji giri.

Re:Ubuntu: The End

[Anonymous Coward]

This. I've been using xubuntu on the desktop and ubuntu server on servers.

Time for a new distro.

Re:Ubuntu: The End

[Barsteward]

"If needs to be, I'll go so far as making my distro myself to avoid systemd." - you could join the periphery and try the debian fork devuan, not sure if its got any traction yet.

comment

[Anonymous Coward]

Systemd? Has it spawned Satan yet?

Ubuntu vs Mint

[Sir_Eptishous]

In the last year and a half I have tried several different Linux desktops to run on a small form factor Dell pc connected to my TV via HDMI.
I settled on Ubuntu for a variety of reasons and was reasonably pleased with it.
However, after a few weeks things started to go wrong.
Errors, lockups and other things cropped up that started to really get old.
I read forum posts, blogs, "kb" articles to fix the various issues I had with Ubuntu.

Eventually I wiped it and reloaded it, and the same sorts of problems came back.

I was ready to install Windows when I read someone mention Linux Mint.
So I gave that a try.

Like a cool spring breeze on a warm afternoon, Linux Mint was refreshing and met all my needs without problems.

To this day I wonder why Mint works so well when Ubuntu Desktop was such a POS.

Re:Ubuntu vs Mint

[Anonymous Coward]

Simple, they don't use Unity.

Re:Ubuntu vs Mint

[ruir]

because mint is fresher? You should investigate a little about system optimisation. There are also specific distros for what you are doing if you are not that technically oriented.

Re:Ubuntu vs Mint

[Anonymous Coward]

To this day I wonder why Mint works so well when Ubuntu Desktop was such a POS.

Simple, they don't use Unity.

And they don't use systemd, yet.

Re:Ubuntu vs Mint

[Sir_Eptishous]

because mint is fresher? You should investigate a little about system optimisation. There are also specific distros for what you are doing if you are not that technically oriented.

To refresh your reading comprehension, what I said was, "Linux Mint was refreshing and met all my needs without problems."
That means that Mint was "pleasantly fresh and different". That means with after all the crap I put up with using Ubuntu Desktop(multiple versions) that when I tried Mint I was pleasantly surprised how good it works, and continue to be impressed to this day.

Regarding which distros to use, I did do quite a bit of research before trying Ubuntu Desktop, and I also tried about 3-4 others before Ubuntu. Like I said, I actually liked it but it had too many issues.

Also, I did do system optimization on Ubuntu to no avail. It was like I would fix one thing then something else would go wrong.
I work with computers all day long, and when I go home I don't want to have to constantly troubleshoot my media pc.

Re:Ubuntu vs Mint

[ruir]

Ditto, that is why I have Linux server farms at work, and Apple stuff at home. And even then, often in a while ;)

Re:Ubuntu vs Mint

[BobSwi]

Linux Mint is an Ubuntu-based distribution. Personally, I prefer Linux Mint Debian or Slackware.

Re:Ubuntu vs Mint

[Anonymous Coward]

WTF was the point of your post? One distro didn't work on one particular machine?

If you'd found some problem, or found some patter, then yeah, it might have been useful, but as it is, you say nothing yet manage to slag off a whole distro at the same time.

Geeze! You sound like a typical whining luser. It's friday, have a beer and install GNU/HURD.

Re:Ubuntu vs Mint

[Eunuchswear]

Why not just use Debian?

Re:Ubuntu vs Mint

[Blaskowicz]

I tried Linux Mint Debian and it feels slightly better, but my sound card is less well recognised out of the box. It has that debian feature of Alsamixer only showing one stereo output and nothing else, which I could live with but in some media players changing the volume changes the global sound volume. I don't want to tweak every app and/or write Alsa or pulseaudio config files. Also tried the Cinnamon desktop at the same time : it's a better desktop than Mate but eats a ton of CPU (up to making video feel a bit jerky, and that's just xvid files). So back to Ubuntu Mint with Mate. If I wanted a stable and light OS with a 3D desktop, I would have to install Windows 8.

Phone Home

[tommeke100]

If I upgrade, will all the "phone home" processes to Canonical that I've disabled still stay disabled? 'cause my packet sniffer caught at least a couple of pings a minute before the purge. Same goes for all the Amazon / Cloud stuff. I hope that crap stays off my machine.

Re:Phone Home

[ruir]

You could always pray to the sysadmin god. Or find an use to a novel concept, a firewall.

Re:Phone Home

[Lumpy]

Or an even more novel concept, use a Distro that doesnt shovel all that crap into it. If you really like Ubuntu, go to Debian. All the goodness and none of the ads or phone home junk.

Re:Phone Home

[Anonymous Coward]

You should not have to install a fireall to prevent your OS from spying on you.

Re:Phone Home

[Anonymous Coward]

You should not have to install a fireall to prevent your OS from spying on you.

True, but, without an external (to your OS of choice) firewall, how would you know?
Do you really trust the logs on your OS of choice to report 'the truth' as to what's really happening on your box(es)?
Then again, where do you stop?
Do you really trust your firewall box? (especially if it's an appliance)
Quis custodiet ipsos custodes?

systemd is a bad joke

[TheGratefulNet]

if I had mod points, I'd mod you as troll.

its not the 'basement dwellers' - those guys have zero experience in unix, given that they are alive less than 20 years, usually, and they know only what they've learned during the obama years and not much before that.

the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.

see, the value of a craftsman is in his knowledge and experience of his tools. some people spend decades learning how to use their tools and work in their trade and the time shows; experience is worth having and paying for!

what happened now: some newbie decided the old way was not good enough and decided to change it all out, for no good reason at all (I have not yet seen a good reason to reinvent a wheel that has been working for longer than most of you have been ALIVE). faster startup is not a reason; this isn't a media player and linux still does not startup in 3 seconds or less, so what's the point of 'faster startup' when its really not fast enough to justify this forklift upgrade of sorts?

basically, the linux distros have been 'google-fucked'. I use that term to mean that some young snotnose didn't have anything better to do with his time and decided to royally break things and redo them, just because he thought it was a 'good idea'. but clearly didn't think it all the way thru and just wanted it because he just wanted it! typical google style; break things and trash all the old history of how things WERE done because, well, we just CANT LEAVE WORKING THINGS ALONE!

Re:systemd is a bad joke

[smooth wombat]

and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.

So Linux is adopting the Microsoft way of doing things (Vista, W8 and the butchered Start menu since W7)?

Re:systemd is a bad joke

[Anonymous Coward]

Blah blah blah 80's blah blah blah forced blah blah blah I'm a neckbeard blah blah blah whahhhhhhhhh!

Re:systemd is a bad joke

[ruir]

If you say so. I pinned in Debian 8 systemd and a couple of other niceties to -1.

Re:systemd is a bad joke

[squiggleslash]

the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.

SystemD replaces components that Ubuntu already replaced long ago. The question here for the Ubuntu team was:

1. Do they keep LaunchD, when it offers few, if any, advantages over SystemD, and they're the only people using it and thus they have to maintain it, and Ubuntu stays non-standard.
2. Do they switch back to "init" because it used to be the standard, and it kinda works, except it's kind of convoluted and a huge source of problems, which is why LaunchD was written in the first place.
3. Do they look at what everyone else is switching to (ie SystemD), see if it does the same job as LaunchD just as effectively, and switch to it?

They chose 3. I'd chose 3 too. There's nothing wrong with SystemD, it's just the developers have no PR skills, and some old Unix people are harking back to a past that was never actually that great to begin with. SysV init sucked. It didn't sendmail.cf suck, but it definitely CNEWS sucked. Complicated, over-burdened by shell scripts and hacks to try to keep it going. SystemD isn't perfect, but it's undeniably an improvement.

Re:systemd is a bad joke

[pak9rabid]

see, the value of a craftsman is in his knowledge and experience of his tools. some people spend decades learning how to use their tools and work in their trade and the time shows; experience is worth having and paying for!

Perhaps the fast-moving industry that is technology isn't for you?

Re:systemd is a bad joke

[squiggleslash]

I don't know why I wrote LaunchD when I meant Upstart, too little brain activity this morning. But in any case, read Upstart there. Of course, LaunchD is also evidence that virtually nobody in operating system design thinks SysV (or BSD) init is a good, thing in 2015.

Re:systemd is a bad joke

[ilsaloving]

As someone who, apart from continually getting the verb and daemon name backward, actually likes systemd, I'd like to know what issues you are talking about. So far the only issues I've had, has been having to learn some new commands.

Forewarned is forearmed 'n all that.

Re:systemd is a bad joke

[Anonymous Coward]

The people that know the difference between AT&T and BSD flavors, especially after the 4.4 Tahoe lawsuit know that you don't just add stuff for politics's sake. For example, Sendmail took a ton of revisions before it was secure.

And we are all going to relearn this lesson with systemd, with one large code blob running as root (breaking the philosophy from decades of UNIX state that you run stuff as root as little as possible), so this means one large remote root exploit waiting to happen... and all it takes is a weakness on the ports systemd listens to.

So, production systems now have this major chunk of nascent code that is going to be a bonanza for the blackhats. All we have is to cross fingers and hope that the systemd coders at least paid lip service to security... but if something as mature as OpenSSL can fall, it only is a matter of time before systemd gets hit and hit hard, since AFAIK, there are no experts familiar with secure/defensive programming coding systemd.

Oh well. Oracle Solaris can be easily moved to, and it isn't open source... but it has stood the test of time when it comes to security.

Re:systemd is a bad joke

[buchner.johannes]

You can't just leave things alone, because computers have also changed. Today we do not work on mainframes or desktop computers, but increasingly on laptops and mobile phones, which constantly change state, in terms of network connections, devices plugged in, location, hibernation.

I think there is consensus that these things did not work well on the old init system, although band-aids were found. I remember that changing the hostname stopped X from working, which can occur when DHCP gives you a new hostname. That is 80s design for you. Or changing the time messes up the logfiles.

Now you can choose which modern init system you want, and there are a couple out there: OpenRC, upstart and systemd are the most well-known ones.

OpenRC is the familiar runlevel based approach, which runs scripts which may or may not succeed.

Upstart is a triggering framework, that takes pre-defined actions (but does not work with goals). That means you have to write tasks for how to get from A to B with your system.

systemd is a dependency resolution program, that knows what to activate next to get to a certain state (goal). It handles services, mount points and network connections in the same framework. It is essentially an overseer of a services tree.

There are some upsides to systemd, besides parallelizing the tasks of a dependency tree to reach a goal. One is for every process it is known which service launched it (there are some Linux-specifics that allow marking those processes). Also, each service can be assigned resources (memory, number of processes), which it can not exceed (again, modern Linux supports that). And, obviously, you are not limited to a set number of runlevels.

Yes, systemd is annoying, because it is a new thing to learn. And it is annoying, because the maintainers are inconsiderate. But in the end, it is just a program to start other programs, with one particular way to do it. I don't get what the big deal is. If it is feature bloat -- Linux also has a lot of features, so does VLC -- there we consider them a good thing. Technically, the dependency resolution approach of systemd seems like a good thing (as in progress for Linux) to me.

Re:systemd is a bad joke

[Paradise Pete]

given that they are alive less than 20 years

I believe you considerably underestimate the basement-dwelling demographic.

Re:systemd is a bad joke

[Anonymous Coward]

No kidding. Jumped on Linux early but now that they've aged and got set in their ways like grandpa, they're afraid of change.

Re:systemd is a bad joke

[ookaze]

if I had mod points, I'd mod you as troll.

its not the 'basement dwellers' - those guys have zero experience in unix, given that they are alive less than 20 years, usually, and they know only what they've learned during the obama years and not much before that.

the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.

Stop making fool of these veteran good unix sysadmins please. I will not associate with some fool like you. You people that know nothing love to give yourself a false authority by saying this nonsense everytime. But a good sysadmin will see through you without any problem.
You trolls are so nonsensical that you say Upstart WORKED WELL and was available in the 80. Linux is not Unix BTW, if you were a seasoned Unix sysadmin, you would loathe Linux more than systemd, systemd is only possible because of Linux.
You are wrong on all counts, so blinded by your hatred for something you don't even understand, it's pathetic.
I've encountered very few admins that even understand how a Unix-like boots anyway, lots of seasoned admins just have no ideas.
I've encountered far more Linux sysadmins that had this knowledge than anything else.
At best you're one of them.

see, the value of a craftsman is in his knowledge and experience of his tools. some people spend decades learning how to use their tools and work in their trade and the time shows; experience is worth having and paying for!

what happened now: some newbie decided the old way was not good enough and decided to change it all out, for no good reason at all (I have not yet seen a good reason to reinvent a wheel that has been working for longer than most of you have been ALIVE).

You're wrong, plain and simple!
Upstart was trying to solve lots of problems of sysvinit that a seasoned Unix admin should know about, it even used dbus.
And the decision to use systemd by default in Ubuntu was the distro maintainers choice.
No good reason to make better than sysvinit? I've seen reasons 16 years ago, that's why since then I never installed sysvinit init anymore on my own made Linux OS. And yet, in my work environment, I'm still to this day the most knowledgeable around about how all this sysvinit crap works, be it SYSV or BSD style.

faster startup is not a reason; this isn't a media player and linux still does not startup in 3 seconds or less, so what's the point of 'faster startup' when its really not fast enough to justify this forklift upgrade of sorts?

If that's the only reason you know about, it just confirms you know nothing about systemd. This is not even one of the main advantage of systemd since years.
The dynamic nature of the Linux kernel and its devices is one main reason.

Re:systemd is a bad joke

[armanox]

Except, with so many init alternatives availible (upstart, launchD, SMF) why did we need to add another? And, there is absolutely nothing wrong with BSD init.

Re:systemd is a bad joke

[squiggleslash]

Ubuntu isn't adding another. They're switching from Upstart, which they were pretty much the only user of left, to SystemD.

BSD init isn't remotely scalable, and requires knowledge of shell scripting from any admin configuring their system or installing software the OS's maintainers didn't plan for. It's actually a worse choice than Sys V init. Hence Apple's (absolutely right) decision to do LaunchD.

You'll have to ask the maintainers of SystemD as to why specifically they saw the other solutions as lacking, but at a guess LaunchD is too tied to Mac OS X and BSD, SMF to Solaris/BSD, and Upstart doesn't solve all the problems SystemD is designed to solve.

Re:systemd is a bad joke

[Anonymous Coward]

its a fucking peice of shit end of story!

Re:systemd is a bad joke

[Anonymous Coward]

blah blah blah millenial, blah blah blah no respect for elders, blah blah blah hipster fedora hat-tip blah blah whahhhhh!

Re:systemd is a bad joke

[Anonymous Coward]

Always that one fucking doctor!

Re:systemd is a bad joke

[Uecker]

I think the big deal is how decisions are made: In the past, somebody would write a new software and people who liked or needed it would start to migrate to it. Then later it may become the default, but other software would still continue to work and be supported for a long time. Nowadays, a decision is made somewhere and changes are pushed to users who do not want it, while support for alternatives is dropped quickly. So in the end, I think it is a question of software freedom in a very real and practical sense.

Re:systemd is a bad joke

[Anonymous Coward]

the rest of us who have used and managed unix since the 80's have to dump WHAT WORKED WELL and move to some new shit that clearly has issues, does not fit in or belong very well and is being forced on us.

Funny, that's what I thought about the UNIXes in the 80's when they started getting popular. Now get off my lawn.

Re:systemd is a bad joke

[Anonymous Coward]

Just what your friendly neighborhood NSA hacker will love.

Re: systemd is a bad joke

[Anonymous Coward]

LOL keep making stuff up to make yourself feel better.

Re:systemd is a bad joke

[Anonymous Coward]

I switched to NetBSD from Gentoo and Fedora because I got sick of the churn. Systemd is vile, no doubt, but the Linux kernel is just as bad. Configuring and building it after each release is Russian Roulette. Both Linux and Systemd are recklessly developed and buggy. The *BSD people value OS stability. You want a 'modern' operating system in Linux. Have at it.

Re:systemd is a bad joke

[armanox]

As a UNIX admin, I actually do very much dislike the Linux world these days. Working with IRIX, Solaris, and HP-UX made me that way.

Re:systemd is a bad joke

[MSG]

the value of a craftsman is in his knowledge and experience of his tools

...and Linux had a bunch of non-POSIX features that went unused because the old init system was meant to be portable.

The people with knowledge of their tools (Linux, in this case) are quite happy to actually be using it rather than letting its features sit idle.

Re:systemd is a bad joke

[gmack]

The people that know the difference between AT&T and BSD flavors, especially after the 4.4 Tahoe lawsuit know that you don't just add stuff for politics's sake. For example, Sendmail took a ton of revisions before it was secure.

Sendmail took a ton of revisions before it was secure because it wasn't written with security in mind. Qmail, Postfix and Exim haven't had any near the number of problems sendmail had.

And we are all going to relearn this lesson with systemd, with one large code blob running as root (breaking the philosophy from decades of UNIX state that you run stuff as root as little as possible), so this means one large remote root exploit waiting to happen... and all it takes is a weakness on the ports systemd listens to.

This is just FUD.
1 Systemd is modular with components running with each componant running with the least amount of privilate to do it's job.
2. The network components not a part of the core project and are very optional.
3. I have yet to see any distro enable the network components at all, let alone by default.

So, production systems now have this major chunk of nascent code that is going to be a bonanza for the blackhats. All we have is to cross fingers and hope that the systemd coders at least paid lip service to security... but if something as mature as OpenSSL can fall, it only is a matter of time before systemd gets hit and hit hard, since AFAIK, there are no experts familiar with secure/defensive programming coding systemd.

As far as you know? I have already seen audits of the code for both correctness and security.

Oh well. Oracle Solaris can be easily moved to, and it isn't open source... but it has stood the test of time when it comes to security.

The same Solaris who dumped sysv bootup scripts a few years back in favor of their shiny new system that's very similar to systemd? Good plan!

Re: systemd is a bad joke

[tom229]

So basically if I'm understanding you right... those damn kids just won't stay off your lawn?

Re:systemd is a bad joke

[hublan]

Since when have you, as a user, had any say in what goes into a particular distro? This has never been the case. Unless there's some highly democratic distro that I must have missed, it's always been top-down.

Re:systemd is a bad joke

[Anonymous Coward]

People who actually use (let alone administer) systems on a daily basis don't give a rat's ass what anyone "in operating system design" thinks (emphasis added).

Ask Linux Torvalds what he thought of what people in operating system design (namely, Andrew Tanenbaum, who famously called Linux "obsolete") thought.

I want something that works, reliably and well, not something that is designed to some theoretical abstraction but in practise sucks dead donkey balls through a garden hose.

Re:systemd is a bad joke

[squiggleslash]

Ask Linux Torvalds what he thought of what people in operating system design (namely, Andrew Tanenbaum, who famously called Linux "obsolete") thought.

I think Linus (not Linux) Torvalds is actually an operating system designer. He's also one of many who disagrees with Tanenbaum. Neither of which has anything to do with anything at this point, he's not the one designing the whole of Ubuntu or Fedora, his work is on a small part of it that doesn't handle the userland start up process.

The people who are designing Ubuntu, Fedora, etc, are saying init, both in its bad System V version, and in its "Scales for everything you need a 386 to do" BSD variant, is not up to the job in a world that has USB, Bluetooth, e-SATA, et al, in it. I think they're right, personally. And to be honest, I think they've been right since the early 1990s, when Internet service protocols were kinda grafted on, moved to inetd, augmented by Sun RPC services, NFS, blah, etc, and the phenomenon of a Unix system that wouldn't boot up due to anything other than hardware failure or disk corruption suddenly became very real and very common.

"We" haven't done much about it since then largely due to a combination of inertia and the fact an average Unix admin was skilled in shell scripting. The latter hasn't been true, however, for a good ten years, which is why Apple has LaunchD, and why Ubuntu also threw out init in favor of modern alternatives, initially Upstart, and now SystemD.

Re:systemd is a bad joke

[Anonymous Coward]

Oh well. Oracle Solaris can be easily moved to, and it isn't open source... but it has stood the test of time when it comes to security.

The same Solaris who dumped sysv bootup scripts a few years back in favor of their shiny new system that's very similar to systemd? Good plan!

This is what I love about systemd discussions.

See also: "Linux was about choice! I'm moving to BSD!"

Re:systemd is a bad joke

[Anonymous Coward]

AND GET OFF MY LAWN!!!

Re:systemd is a bad joke

[jcdr]

It look like we are from the same generation, but contrary to you I absolutely like the systemd move. This situation is not new: Git faced the same kind of critics for example, as udev has also over the static /dev.

The basic of systemd is learned in a single day of work, really. For all the others issue, you will find the answer in a minute on the internet. Maybe you have to learn hard to understand system V init and his reluctant stack of script at his time, and that experience make you feel like you are an expert about it. But today way of learning something like systemd is accessible to a very big amount of peoples.

Or maybe you are too old to understand that system V init have absolutely no way to provides so much features that systemd bring on the table.

Re:systemd is a bad joke

[armanox]

We don't work on mainframes, servers, and desktops anymore? Sorry, didn't get that memo (and neither did my paycheck). Laptops are largely treated the same as desktops.

Re:systemd is a bad joke

[jcdr]

Actually, this is precisely because the upstart project successfully proved most of his goals that something far better than system V init can be build that the systemd project was started. Even more, at the early stage the idea was rather to fix the upstart inverted dependency logic by a more natural one. But upstart license was an unavoidable limitation for external contributors, so there started an other project called systemd with a more standard license.

Re:systemd is a bad joke

[Anonymous Coward]

[Citation Needed]. I'd love to see something about a systemd code audit, other than hearsay. This is important stuff here, and not because we IT people are just "anti-change fossils". In number of businesses, IT people have to deal with audits, and I am certain it will be asked about why systemd is used on any system internally of any significance when it has not been tested, nor certified by any independent party.

Solaris is EAL4+ certified. RHEL 7.x is not, even though it is in the process of being reviewed. This is quite important, especially if a business values regulatory compliance.

Re:systemd is a bad joke

[Anonymous Coward]

It seems to me this decision made "somewhere" was in fact made by the various distribution maintainers, to switch to systemd. Some portion of the userbase of those distributions is all butt hurt over THEIR views not winning. Well too damn bad, just switch distros to another one that lets you pick whatever startup system you want. "software freedom" doesn't mean "the way I personally agree with".

Re:systemd is a bad joke

[buchner.johannes]

For Gentoo, I can switch between systemd and OpenRC at boot time. Also for Ubuntu 15.04, you can switch between systemd and upstart. So I don't think your argument that the user does not have a choice holds, this is just about which package is installed by default.

Re:systemd is a bad joke

[thegarbz]

I think the big deal is how decisions are made: In the past, somebody would write a new software and people who liked or needed it would start to migrate to it. Then later it may become the default, but other software would still continue to work and be supported for a long time. Nowadays, a decision is made somewhere and changes are pushed to users who do not want it, while support for alternatives is dropped quickly. So in the end, I think it is a question of software freedom in a very real and practical sense.

The nature of how decisions are made haven't changed in the slightest. The only difference here is that some fundamental items have been changed over the years which were complex enough to draw a line through the maintenance of packages. As some Redhat maintainer many years ago posted, Linux is not about choice. In general your choice ends at the distribution you chose and from then on your choice becomes far more limited without having to maintain and resolve many issues. If the implementation of something is easy, choice is provided to the user. If the implementation is hard and would result in a lot of work for maintaining different streams then the choice is made for the user, and it's the user's choice to continue using the system given the choices which were made.

Re:systemd is a bad joke

[Anonymous Coward]

it is a fucking big deal you asshole. I am not using it ever!!!!! I will not use it where i work. I will not use it at home. I will not use it on my phone!!!! GO fucking die systemd already!!!!!!

Re:systemd is a bad joke

[Barsteward]

and systemd works with the linux only Cgroups

Re: systemd is a bad joke

[Anonymous Coward]

Solaris invented SMF which systemd has later copied (just as btrfs later copied ZFS, systemtap copied Dtrace, etc) Poettering talks lot about SMF.

Re:systemd is a bad joke

[The Finn]

Illumos is still under active development, so you can still get your solaris fix.

Re:systemd is a bad joke

[ilsaloving]

I see that I've been modded troll for asking a legitimate question.

I think says more about systemd haters than it does about me.

Maybe if those of you who hate systemd spent less time frothing at the mouth, and more time giving genuine, practical arguments, then maybe the distro people would take you more seriously.

And then you people wonder why systemd is taking the world by storm, despite your angry chest-beating.

Re:systemd is a bad joke

[Anonymous Coward]

That's running on fumes, old chap, because Debian Leading Comitee agreed upon dropping SysV init compatibility; they just didn't manage to do it by the time Jessie got released.

They did break at least one thing...

[Anonymous Coward]

For some reason, they're stuck at Squid 3.3.8 which is two years old. squidGuard is very recent, 1.5-4, to the point that it isn't compatible with the squid 3.3.x branch. It's broken out of the box and they don't work together. Changelog says the squid base is now 3.4 for squidGuard, but they package squid 3.3.8... I had a config working on 14.10 with squid 3.3.8 and squidGuard 1.5-2. Spin it up in 15.04 and copy the conf files over and I get a "ERROR: URL-rewrite produces invalid request: GET ERR HTTP1.1" error. Pffft!

Unity problem and systemd "issue"

[antiperimetaparalogo]

I don't care about systemd (i understand some of the criticism, but not the "riot" against it, usually from people that don't understand any of the criticism...) - i care about the Unity desktop... so much that i change it immediately to Gnome Classic !

I had enough last month

[Anonymous Coward]

Of the pointless Linux churn. I switched to NetBSD. Couldn't be happier.

My Take on Ubuntu (as if anyone cares)

[Tempest_2084]

I'll never understand why Unity gets so much hate, I actually like it. My only complaint is the stupid 'search' feature that you're forced to use when you want to find something that's not in the dock. Even though I've managed to filter out all the Amazon crap, it's still slow as molasses (and I'm running a Core i7 with 6GB of RAM). Other than that I've been pretty happy with Ubuntu and Unity although I've considered moving to Mint and using a 3rd party dock of some sort (Cairo or Docky) to mimic the Unity dock.

I can't really weigh in on the Systemd vs Upstart debate since I'm not enough of a power user to really have it affect me. I suppose the only thing that comes to mind is that the 'If it's not broke, don't fix it' argument has merit, it can also hold back innovation. Change is scary, but it's not always bad (although sometimes it does go horribly wrong). This sort of reminds me of when Apple went from 13 to 16 sector disks or even the whole CP/M vs DOS debate.

Re:My Take on Ubuntu (as if anyone cares)

[Anonymous Coward]

It's slow from all your data being shipped back to home base.

Re:My Take on Ubuntu (as if anyone cares)

[Tempest_2084]

Then they're in for a quite shock. They'll probably have to burn the server when they're done.

Re:My Take on Ubuntu (as if anyone cares)

[tepples]

What does Xubuntu 15.04 leak back to Canonical or any other "home base"?

Re:My Take on Ubuntu (as if anyone cares)

[Anonymous Coward]

>I'll never understand why Unity gets so much hate, I actually like it.

Pod people will just never understand humans.

What does it even matter?

[Anonymous Coward]

For a server administrator SystemD brings a bag of neat management features.

For a desktop user SystemD quietly does its job in the background without interfering with the usage of the computer.

Re:What does it even matter?

[Barsteward]

ooo an AC thats NOT ignorant... nicely put. shame the anti-systemd trolls modded you down

Cannot reproduce your test case

[Anonymous Coward]

# cat /etc/systemd/system/broken_systemd.service
[Unit]
Description=Broken systemd example
After=network.target

[Service]
User=root
Group=root
ExecStart=/root/broken_systemd.sh

[Install]
WantedBy=multi-user.target
EOF

Note that you are using the default Type=simple, where systemd considers the program started as soon as the child process has execve()d. So the exit code of systemctl start will naturally be 0, because Type=simple by definition doesn't wait for the process.

Depending on what you want to achieve, you will want to set a different Type=. For example, if you set Type=oneshot, systemctl start will return a proper error exit code (because it will wait for the process to finish before considering the unit's status).

But even in your example, when the process exits later on, the unit's status (see systemctl status or systemctl --failed) will be considered failed, because then systemd will detect the error exit.

This is all nothing new and documented.

# journalctl -u broken_systemd

Feb 12 17:59:32 redhat7test systemd[1]: Started Broken systemd example.
Feb 12 17:59:32 redhat7test systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
Feb 12 17:59:32 redhat7test systemd[1]: Unit broken_systemd.service entered failed state.

I don't know about RHEL7, never useed that, but on Debian 8 your exact unit gives me the following (anonymized) output:

DATE TIME HOSTNAME broken_systemd.sh[PID]: Example systemd service
DATE TIME HOSTNAME broken_systemd.sh[PID]: Error that should not be thrown away
DATE TIME HOSTNAME systemd[1]: broken_systemd.service: main process exited, code=exited, status=1/FAILURE
DATE TIME HOSTNAME systemd[1]: Unit broken_systemd.service entered failed state.

And in contrast to sysvinit, where the output of init scripts might flash on the console before being replaced by something else (too fast to see), systemd actually logs them and they are now available for later viewing. I consider the handling of stdout/stderr of services by systemd a huge step up compared to sysvinit - I've seen TONS of init scripts that start daemons with >/dev/null 2>&1 or so, because otherwise the daemon would clutter the console with messages, and those messages just got thrown away before. Now they can actually be logged.

Re:Cannot reproduce your test case

[Anonymous Coward]

That's not what I see on RHEL7 or the Ubuntu beta that uses systemd. The exit status is 0, and the journal doesn't contain the error. That makes it very hard to troubleshoot problems.

> Type=oneshot

Where is this documented? I didn't see it in the man page for systemd, systemd.unit, systemctl, etc. or any other commands listed in the "SEE ALSO" sections of those commands.

I will admit that "systemd-analyze verify [unit-name]" sounds very nice. My junior admins too often screw-up an init script and are then not be able to restart the service which leads to mad customers.

Re:Cannot reproduce your test case

[Eunuchswear]

That's not what I see on RHEL7

But it is exactly what I see on CentOS 7. How odd.

Type=oneshot

Where is this documented? I didn't see it in the man page for systemd, systemd.unit, systemctl, etc. or any other commands listed in the "SEE ALSO" sections of those commands.

man systemd.service

In man systemd I see:

The following unit types are available:

                1. Service units, which start and control daemons and the processes
                      they consist of. For details see systemd.service(5).

  [...]

SEE ALSO
              The systemd Homepage[9], systemd-system.conf(5), locale.conf(5),
              systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-
              daemon(3), systemd.unit(5), systemd.special(5), pkg-config(1), kernel-
              command-line(7), bootup(7), systemd.directives(7)

And in systemd.directives there is:

Type=
                      systemd.mount(5), systemd.service(5)

14.04 LTS

[Anonymous Coward]

Thank goodness 14.04 LTS is going to be supported for another 4 years. And it comes in a MATE variant.

Time to properly test systemd

[Theovon]

There are systemd haters who just think the design is fundamentally broken. There are others who just don't want to have to deal with an immature, buggy system for years upon end. By putting it into a distro as popular as Ubuntu, there's going to be a ton of practical fallout, where more and more people hit the corner cases and experience system crashes, many of which are directly the result of systemd bugs. Now, if Canonical are really smart (who knows), they'll be logging these crashes and make it easy to push stack traces upstream.

Eventually, the bugs will be worked out, and all we'll be arguing about is the architecture.

Systemd may be a joke -- but you don't get it

[Anonymous Coward]

You're clearly getting recalcritant in your dotage. SysV init was unportable (esp. between distros) and unmaintainable, and founded upon bad hacks like pidfiles. Systemd is fundamentally not about faster boot, that's just a strawman you've set up. The road to systemd began with a need for process tracking. To work well, this has to be done in cooperation with the kernel, and such projects have a long history: cgroups are merely the most recent / most successful. I'd give you a history lesson, gramps, but you should probably either give this one up for want of intellect, or get it from the horse's mouth.

Re:Systemd may be a joke -- but you don't get it

[daveime]

> The road to systemd began with a need for process tracking.

And seemingly, throwing away the information a failing process gives you assists in this tracking ?

Re:Systemd may be a joke -- but you don't get it

[Anonymous Coward]

Repeating lies doesn't make them true.

What about speed?

[Lumpy]

Will systemd increase or reduce performance? I cant get any straight answers out of the gigantic whinefest that is the systemd controversy.

Re:What about speed?

[Anonymous Coward]

It's a complex question to fully answer, but generally a performance increase is seen as native binary blobs are used in place of interpreted scripts (which fork a massive amount of subprocesses as well, adding to the overhead). Many people still prefer scripts though, as the SystemD discussions have shown.

Re:What about speed?

[Anonymous Coward]

In my experience, reduce. Although it's remotely possible that the increased system latency I'm seeing is due to something other than systemd (also downgraded from KDE3.5 to KDE4), the hangs I get about 1/3 the time when it boots (hangs when entering graphic mode) are almost certainly systemd related.

I'm about ready to go Slackware or Debian GNU/BSD or something.

Re:What about speed?

[Anonymous Coward]

I just installed 15.04, it definitely starts up faster, seems crisp, but only one day of use so far. I went with Ubuntu Gnome instead of Unity, and added gnome-flashback as I wanted a traditional desktop. Also installed Nemo, as Nautilus is still fucked up for power users. Can't have everything, unless you customize it to suit your needs.

Re:What about speed?

[Eunuchswear]

Neither. Why would you imagine it would?

Re:What about speed?

[jcdr]

systemd-analyze and his commands will give you the answers very quickly. I found that systemd by itself is blazing fast and play an insignificant role in the performance as all depend on the services you require to be started.

Devuan

[GodWasAnAlien]

In the past, I would install the release of Ubuntu a month before it was officially released.

Now, I'm sticking with 14.04, and will likely next try Devuan when released.

Anyone Else Get Errors When Updating?

[Tempest_2084]

I updated from 14.10 to 15.04 last night but now I'm getting some weird errors on the start up screen. Stuff like 'sse/media not found', 'ssf/media not found', 'ssg/media not found'. It keeps going on like that for a bit but it eventually boots into Ubuntu. It looks like the system is looking for non-existant drives or something, but I'm not sure how to fix that.

Ubuntu seems to become unstable after updating. The last few times I've updated to the newest version I had weird errors on boot up, but none of them ever seemed to affect the functionality of the system. It makes me wonder how well they test the update feature, or do they think that everyone is going to do a fresh install each time?

Time to find another distribution I guess ...

[Anonymous Coward]

I like my all log files to be all text.

Link for Mint

[BrendaEM]

http://www.linuxmint.com/

Systemd is a huge can of worms

[Anonymous Coward]

We have now Ubuntu (and other distributions) full of bugs like this:
https://bugs.launchpad.net/ubuntu/+source/mosh/+bug/1446982
https://bugzilla.redhat.com/show_bug.cgi?id=1141137

When will these be fixed and what their impact will be?

My opinions are better

[Bathroom Humor]

I disagree, and therefore I am correct. Check MATE.

I know that was a stupid pun, but I promise I had a real point to prove. Unity is fantastic for people who's preferences may not mirror your own.

Managability

[arth1]

Services are easily manageable.

A bunch of us who actually manage systems tend to disagree.
Hundreds of DOS ini files, having to compile things instead of just modding a script, and not being able to step through a startup or shutdown process is not what we all consider easily manageable.

If it really were easily manageable, it would not have caught so much flak.

Sometimes you're the octopus, sometimes you're the girl.

Re:Managability

[RabidReindeer]

Thanks to systemd, every time I get a kernel update, I can look forwards to spending 4 hours trying to get the box to boot again. EVERY freaking time!

In Fedora 21, "single" boot mode doesn't even present a the filesystem you need to repair. I finally had to resort to a rescue CD. Not all my machines have CD drives attached anymore.

Re:Managability

[Eunuchswear]

Hundreds of DOS ini files, having to compile things instead of just modding a script,

"having to compile things"? Like what for example?

Re:Managability

[Ol Olsoc]

Thanks to systemd, every time I get a kernel update, I can look forwards to spending 4 hours trying to get the box to boot again.

Suck to be you man - you are definitely doing something wrong, and blaming it on Ubuntu.

I've never ever had a Linux machine fail to reboot after an update. And I've been running systemd since it came out because I needed pulse audio, which despite some early problems, is now rather nice for my needs.

Re:Managability

[Barsteward]

"Hundreds of DOS ini files, having to compile things instead of just modding a script, and not being able to step through a startup or shutdown process is not what we all consider easily manageable." - what system are we talking about here?

Re:Managability

[Anonymous Coward]

Perhaps you should keep a rescue USB as part of your general IT toolkit.

Re:Managability

[RabidReindeer]

I don't blame it on Ubuntu. It's a Fedora 21 box.

I have problems with certain network filesystems coming online at boot time and have had occasional issues with the kernel module for VirtualBox. On my machines running CentOS 6 these issues can cause the system to boot with warnings and reduced functionality. CentOS 6 doesn't use systemd.

On the Fedora machine, I get dumped into the recovery mode, where I have minimal ability to actually repair anything much beyond running fsck, which won't help these sort of problems.

Some may say that it's better not to boot than to boot a defective machine, but they're operating in a theoretical world. I cannot afford to have production servers down while I play the reboot game. I have monitors that will tell me when I have services in need of attention - I don't need a complete halt for that.

Re:Managability

[Anonymous Coward]

this. 1000x this.

Re:Managability

[Megol]

fantasyd.

Re:Managability

[Anonymous Coward]

agreed systemd is a pita

Also Xubuntu: The End?

[tepples]

I suffered through Ubuntu Unity on my laptop for one month until I did sudo apt-get install xubuntu-desktop. I wonder what'll break in a year once I upgrade from what amounts to Xubuntu 14.04 LTS to 16.04.

-1 Troll

[tom229]

I switched to arch Linux about a year ago which comes with systemd and I have to say I absolutely love it. Before services and logs were always confusing. Is there a start up script? Had it been converted to an upstart job? Where are the log files? Etc. Once you learn how to use systemctl and journalctl there no more mystery... You always know where to look. Just my 2c.

Re:-1 Troll

[Barsteward]

wise words for the anti-systemd'ers but probably lost on them. they seem to expect to have the knowledge of a new system without learning about it.

Fine

[Anonymous Coward]

1) What did they break this time that won't get fixed for several releases?
2) What did they finally fix that has been broken for several releases?

Ubuntu looking more and more like Windows

[Anonymous Coward]

Soon the only advantage will be that one does not have to pay for Ubuntu. Other than that, it's becoming as obnoxious, dogmatic, intrusive and controlling as Windows.

Systemd is not a concern for end users

[Anonymous Coward]

Systemd is the least of my concern. As a business user who wants a reliable desktop environment, I still struggle with 15.04 due to its inability to work with multiple monitors and a docking station. Customization of Unity is also a pain the rear, as it is nearly impossible to get a theme that works with all the aspects of the graphical interface.Finally, you know things are off to a wrong start when you have to disable the Amazon shenanigans.

Ubuntu 15.04 thoughts (user since 4.10)

[phinnvr6]

1) Systemd works great on the several machines I've tried, from an 8 year old home-built rig to my newer ThinkPad Carbon 2. Booting and shutting down are lightning quick.
Unity specific:
2) Place an option for Click-to-Minimize with the taskbar. This fundamental feature shouldn't require Unity-Tweak-Tools.
3) Get rid of the ugly boxes around the taskbar icons: https://askubuntu.com/question...
4) Really a new icon set is needed. Yes there are some great ones out there, which again seems to require Unity-Tweak-Tools e.g.: http://www.noobslab.com/2015/0...
5) Why not just include Unity-Tweak-Tools and call it Advanced or something, since basically everything requires it.
6) The Unity top bar is not useful. Honestly Windows 7 and newer has more efficient use of space since the taskbar, notifications and clock are all on the same bar. All it all it's a nice enough UI though.
7) After just the few tweaks above, I think Unity is excellent and no problems using it over any other Linux DE/WM.

So clear reproduction steps...

[Anonymous Coward]

are marked as a troll by the systemd fanbois. This is the core, as Linus pointed out, problem with systemd. They ignore bug reports. I was able to reproduce the problem on version 208, which is the newest version with Lennart Poettering's distribution, Red Hat 7.

Translation...

[Viol8]

"I don't have a fucking clue and hope to bluff my way out"

Nice try. No cigar. Not even a butt end.

The more you hide

[Anonymous Coward]

And the more information you hide from the hapless user, the more 'modern' you are. systemd may be the most ill designed major OS component I've seen in a long time.

Debian v8 stable is tomorrow!

[antdude]

I think it has systemd IIRC too. I'll not upgrade mine to it for a while.

I don't really see the issue-

[Anonymous Coward]

I have Slackware running just fine on an old Macbook Pro, and my photo editing system is going to be upgraded to Slack soon as well.
And then there is my main home use machine which currently runs Mint, the Ubuntu derivative that used to fix most of the problems in Ubuntu: that will be upgraded before long as well.

Not really worried about Ubuntu 15- it will never get closer to a computer I have to deal with than a link on a webpage.
At work we have BEEN using Ubuntu 10.04 LTS for everything and are currently rolling out 12.04.

We are already discussing what we replace Ubuntu with if sanity has not returned to Canonical by the time 12.04 is EOL.

Angry at Ubuntu

[hcs_$reboot]

They release a major update while 14.04 is supposed to be LTS = Long time support (3 years, 15.04 is 1 year). Some bugs have been fixed in 14.10 (and 15.04) that are still live on 14.04. Annoying.

I'm the opposite

[Anonymous Coward]

I am switching away from Mint 17.1 to either Kubuntu 14.10 or Windows 7 because of the numerous bugs and frustrations Mint has offered me.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Some truths

[Anonymous Coward]

Time to debunk many of the lies.

1. Modularity. It isn't. See --user.
2. Mature? Look at mailing list to see it isn't.
3. Logging is a fucking joke. Lennart is a seriously dumb cunt who seriously things http and json are better for logging than syslog. I'm not even making that up.
4. Secure? No fucking way.
5. Not portable? Who even cares when systemd doesn't even run on linux in most cases. Think phone tablet embedded non glibc. The biggest use case for linux already excludes systemd.

All the proported benefits are pointless when design decisions are taken by a luddite who's use case is differs from everyone else. Eg lennarts laptop vs the server use case.

Man hostnamectl. Go on. Do it.

I fucking lolled at lennart's laptop. Who needs this other way to give a nice windows style name to your laptop?

Proof that the person Doing the job is far from the best, most qualified person for the job.

This lennart cunt does not get linux or Unix.

That's the trouble with linux developers these days. They only use linux for work. Otherwise they use Apple products. And sit there playing with their pathetic, tiny, penises, high fiving themselves on how they are turning linux into os x.

Re:Some truths

[Eunuchswear]

Not portable? Who even cares when systemd doesn't even run on linux in most cases. Think phone tablet embedded non glibc. The biggest use case for linux already excludes systemd.

My phone runs systemd fine.

But then my phone runs Linux, not Android.

Finally, one init again

[Craig Ringer]

Finally we're back where we were before Ubuntu upended everything with upstart. We have one init system across major distros. Except now it solves all sorts of issues that were problematic on sysvinit.

Great to see we can make progress and solve problems, even if it takes an astonishing amount of wailing and gnashing of teeth. (You'd think half Slashdot was born before 1960 and learned some traditional UNIX before there even was a Linux, the way they carry on whenever anything changes).

Re:Finally, one init again

[Eunuchswear]

You'd think half Slashdot was born before 1960 and learned some traditional UNIX before there even was a Linux, the way they carry on whenever anything changes

I was born before 1960 and started to use Unix around SVR3.0 before there even was a Linux.

I quite like systemd.

Comment removed

[account_deleted]

Comment removed based on user account deletion

This far I'm liking it

[Anonymous Coward]

I just updated my laptop and HTPC from 14.10. My first impressions: start/shutdown are insanely faster. I don't know exactly what the fuss is about with systemd, but this far I have only seen a positive change user experience wise.

ESXi problems?

[Anonymous Coward]

I'm trying to get desktop to run under ESXi 5, and it is less than cooperative so far. Anyone else having issues with this?

Worth it to upgrade from 14.04?

[Archladon]

Anyone with a more qualified opinion want to chime in as to whether it's worth it to go for the 'CUTTING EDGE' version 15 for a guy using 14.04 atm? I am using this machine for some light gaming, word processing, internet & basic software development