UNIX greybeards threaten Debian fork over systemd plan

A group of “Veteran Unix Admins” reckons too much input from GNOME devs is dumbing down Debian, and in response, is floating the idea of a fork. As the rebel greybeards put it, “... current leadership of the project is heavily influenced by GNOME developers and too much inclined to consider desktop needs as crucial to the …

[Ole Juul]

Go for it

“If systemd will be substituting sysvinit in Debian, we will fork the project and create a new distro. We hope this won't be necessary, but we are well prepared for it,”

I hope they do it. I look forward to Debian being turned around and getting back on track.

[Anonymous Coward]

Re: Go for it

Lennart Poettering is a Microsoft mole.

But seriously, I think Poettering has good intentions but is implementing the wrong solution.

Binary coupling is the wrong way to tackle the problem of tidying up the Linux system infrastructure.

Interface standards like DBus are how you achieve this, not the sprawling, all-encompassing mess that is presented to us at the moment.

A fork might be the only solution to this. So many distributions are seduced by the cosy feeling of convenience. The tight encompassing of systemd to so many distinct system components will stifle innovation.

Poettering would do to learn from the teachings of experience from some very clever people in Unix history. Do one thing and do it very well.

[andreashappe]

Re: Go for it

> Interface standards like DBus are how you achieve this,

> not the sprawling, all-encompassing mess that is presented

> to us at the moment.

You mean like those: http://www.freedesktop.org/wiki/Software/systemd/dbus/

Please check you facts first, the systemd documentation (including all those dbus interfaces) is actually way better than the "normal" init stuff that I've encountered in the couple of years.

[Anonymous Coward]

Re: Go for it

> You mean like those: http://www.freedesktop.org/wiki/Software/systemd/dbus/

If only it would stop there.

The number of other system components that are link-reliant on systemd is growing. This in itself is the problem. More and more it is becoming practically impossible to not have systemd in the ecosystem somewhere.

http://gimpforums.com/thread-why-is-systemd-required-to-run-gimp

[t.est]

Re: Go for it

Well, get a mac and u are in the future already :D

[Gene Cash]

Re: Go for it

> Poettering would do to learn from the teachings of experience

Poettering doesn't learn. And he doesn't listen to anybody. That's the problem.

[h3]

Re: Go for it

Another part of it is the fact that nobody else is contributing large amounts of manpower to the desktop other than Redhat. When there was SuSE and Sun as well it wasn't so bad.

He is almost single handedly responsible for me being back on Windows. (The fact that Alsa can never get ice1712 correct for more than one -rc of alsa-driver at a time is another part).

Freebsd or OSS4 is perfect for my card.

I have one old Thinkpad that still has Linux but most of it was built from source (No Alsa / Pulseaudio / systemd / avahi - XiG X (r200) / OSS4 / pkg-src).

I have a pretty powerful Netbsd VPS and I just use that.

[t.est]

Re: Go for it

Well yeah, he should have used launchd form the beginning instead.

But ditch the init already and get out of the cave u cavemen.

[Anonymous Coward]

Re: Go for it

Poettering IS A MOLE! His "secret handler" : CORPORATE AMERICA! He even has a little panegyrist/catamite running a fanboy site with a name a lot like "MORONIX." Forking is the ONLY thing which will save Debian. As for saving GNU/Linux, I've a Modest Proposal below...

The ugly FACT is that SWARMS of mediocre little dweebs like Chamber-Pottering have been excreted into the american software mills; conditioned from primary school to the M$ paradigm. DeadCat stopped upholding REAL software Freedom in the fall of 1999, a year which Chamber-Pottering or Michelle Tinkerbell doubtless only recall for their toilet training about then.

So, some Big Buck$ has hired this little shill and suddenly pumped a LOT of effort behind his poison code? GRAB HIM! HURT HIM REAL BAD, THEN KILL HIM! Neat, and sends a clear message to the timid sorts in corporate offices. A twisted Lennart-corpus on their front steps upsets their delicate digestions. They'll See Reason then.

I've tried one of the modern distros, Arch, a real loser thanks to their knee-jerk adoption of systemd, and 1 year of it has been quite enough. Show this little epistle to "Lennart" as his sweet-heart Tinkerbell at Moronix so fondly calls him. I'm a little far away to make the Hit, but creative minds closer to his nest may get cracking...

and Now, a Little Homily TO Lennart,

When you sell your soul so cheaply, to do such evil as you have, Lennart Dear Heart, don't wet your bed when Real People decide you need to stop exhaling into our atmosphere. I suggest YOU take a LONG Vacation. Pack your bags Little Man, NOW. Visit Tibet. Learn basket weaving. Keep your sticky little protuberances OFF all computer inputs though, or know Real People will be looking to correct some SERIOUS FLAWS in the WWW. Reflect on what you've done and why, but STOP IT NOW AND DON'T DO IT AGAIN!

[ElReg!comments!Pierre]

Re: Go for it

Yup, same here. Go ahead and get rid of that systemd shit. I sure did go back to sysv on all my debian machines, systemd is just... not up to the job on a real machine. I can see how it can be useful on a "reboot-every minute" tablet, but on a proper computer it just doesn't work (on top of slapping all the UNIX principles in the face, repeteadly)

[Not That Andrew]

Re: Go for it

So far the only good idea of Poetterings that I'm aware of is /etc/os-release . As someone said on another forum, he should stick to hacking text files.

[t.est]

Re: Go for it

Hmm, OSX is certified UNIX and it runs lauchd the very thing systemd wants to imitate.

[h3]

Re: Go for it

The Solaris SMF is the best it doesn't really have any downsides. (And you don't have to use it.)

[MarkSitkowski]

Re: Go for it

I agree.

I run Solaris and CentOS, which are the only things that work like real Unix.

I can port the same code from one to the other, without changing a single line, and the administration is almost identical.

If I wanted a desktop that looked like BillyWare, I'd run BillyWare or Ubuntu....

[h4rm0ny]

Re: Go for it

I totally agree with not going the systemd route. There are a number of really good arguments against it.

However, I also think it's a battle that has been lost. I respect those wanting to fork and good luck to those trying give systemd the shove - I'd be happy to be proven wrong. But Debian is just the latest distro to fall before it. CentOS and SuSE use it so now that main Debian has gone this way, it's pretty much got control of all the castles. Slackware and others may be beautiful distros, but these three have all the enterprise presence between them Ubuntu has reversed position on systemd too, so that's the newbie / casual demographic as well (that's not a criticism of Ubuntu - it's just the most accessible distro so favoured by large numbers of these crowds).

Everything else is just islands in the sea.

[TimeMaster T]

Re: Go for it

"Go for it"

Amen.

I've been with Debian 12 years, at home and work, but if they go to systemd I'll switch to any distro that doesn't have systemd. I've been looking at slackware but a Debian fork would be better. All my scripts would still work.

[Denarius]

about time

someone stood up to the barrage of theory idealists who disdain practical simplicity. Even KDE has become crap. I was afeared I may have to move to a BSD.

[MadMike]

systemd to incorporate a shell too!!!

Yes it is true, systemd will have it's own shell soon. Google this.

For the systemd, it is actually heavily inspired by Solaris SMF. Just as BTRFS is inspired by Solaris ZFS, systemtap is inspired by Solaris DTrace, Linux Docker/LX containers are inspired by Solaris Containers, Open vSwitch is inspired by Solaris Crossbow, etc.

SMF is useful in Solaris because it parallesizes startup and it also handles services that is to be running all the time. For instance, it takes 90minutes to boot a IBM P570 server because it boots sequentially, not in parallell. Solaris boots way faster thanks to SMF.

SMF and systemd is useful in large servers with many services and long boot times. They are useless in desktops. They are a server thing. Apparently, systemd failed in several important aspects copying from Solaris - why do you add a shell?? And systemtap is also a failed copy - it might crash the server!! DTrace is completely safe and can not crash the server. systemtap is therefore useless. systemd as well. BTRFS seems to have missed several aspects from ZFS too.

[xenny]

Re: systemd to incorporate a shell too!!!

To be contrarian, I can see an argument for systemd on a desktop, where I may reboot it often. I typically don't reboot servers frequently, so I'm unconcerned about a fast boot, but I value being able to debug the startup process of a broken server with a shell and a text editor, which I can do with sys V init scripts, but can't do with systemd.

[t.est]

Re: systemd to incorporate a shell too!!!

Why would you not, we on Mac OS X can do that with launchd, and launhcd is what systemd tries to be.

Get out of the init cave already, OSX is did it in version 10.4 and 10.10 is out now, it's quite many years of proven functional UNIX yes not *nix.

[Jim 59]

Re: systemd to incorporate a shell too!!!

Not sure systemd is a reflection of Solaris SMF. SMF is text file based, and would please the Debian elders in that regard. In accordance with unix philosophy, SMF is limited in scope, modular, constrained into one role and does that role transparently and (fairly) simply.

systemd is a windows-esque, monolithic, black box solution. ie. the opposite of Unix design. It is also p*sspoor by all accounts.

[Gary Bickford]

Re: systemd to incorporate a shell too!!!

> "I've long gotten used to the fact that software is getting steadily worse, and it's mostly down to crappy design decisions, rather than poor coding. "

Oliver, you'll be interested to note that as far back as the early 1980s it was recognized that given a good software engineering process, over 70% of all bugs were built in to the original design.

To make things worse, IIRC only 20% of bugs in production release code could be found by "black box" testing. The other 80% are the bugs that are found by the users in the field.

Source - this data was from published analyses done on enterprise and government/defense code bases - I used to teach a SW QA workshop.

[Solmyr ibn Wali Barad]

Re: systemd to incorporate a shell too!!!

Get off the Kool-Aid, kiddo. Might kill ya someday.

[Anonymous Coward]

Or they could just do what long-bearded hippies have always done...

root@slackware:/# setup

[MacroRodent]

So fork, then

What's the big deal? Freedom to go your own way is one of the great things about free software.

In this case it is a good thing, as it sets a nice experiment about which approach is better. Let the best init win!

Personally I have never liked sysv init much with its huge pile of little shell scripts sequenced by a funny naming rule. The systemd can hardly be worse. Haven't used it much yet, but it appears to be well-documented, and brings up my personal OpenSuse spin snappily. Investigations continue...

[Raumkraut]

Re: So fork, then

Personally I have never liked sysv init much with its huge pile of little shell scripts sequenced by a funny naming rule. The systemd can hardly be worse. Haven't used it much yet, but it appears to be well-documented, and brings up my personal OpenSuse spin snappily.

Ah, you've fallen into the same trap as Debian did. You've mistaken systemd for a sysvinit replacement. It's not. It's a replacement for just about the entire operating system stack (the clue is in the name). Where currently the argument is about "GNU/Linux", it may soon be better phrased "systemd/Linux".

The fear is that once you adopt systemd, it will be unreasonably difficult to replace it with anything better in the future, thanks to its all-encompassing nature, and the encouragement of *explicit* dependencies by user-facing software. There's no reason why the Gnome DE should strictly require one particular init system, but it does.

[ElReg!comments!Pierre]

Re: So fork, then

Spot on Raumkraut.

There's also the little detail that the permission tree in systemd ("the user doesn't own the process, each process owns its children") is making a fragging permission mess very quickly which means that after a while you have to run a whole lot of shit as root, à la Windows pre-RT, or reboot to clean the mess up.

Systemd is a toy, not a proper tool. I say burn it. Burn it with fire.

[Anonymous Coward]

Re: So fork, then

Ahh yeah, sysvinit was fine until Debian devs came along and broke out all those tiny scripts and symlinks in order to build a service configurator GUI that real sysadmins never bother with. All that needless indirection was enough to keep me away from Debian for 10+ years. ArchLinux is a breath of fresh are but unfortunately way too bleeding edge for me; package updates usually break things. So I use Debian-stable because it's relatively stable and doesn't force me to use dbus, pulseaudio, etc.

Dependency hell is my biggest fear with systemd. If there are dependencies like nginx>systemd>dbus that's a problem. Every unnecessary daemon is just wasting resources and opening up gaping security holes. Yup, there was a big one in dbus a couple months go...

I really don't care about all these efforts to improve Linux/*nix. It'll never be a good OS for desktops, servers, phones, drones, or anything. NEVER. I just make do with it until something better comes along.

[ElReg!comments!Pierre]

Re: So fork, then

http://www.muylinux.com/wp-content/uploads/2014/08/funny-systemd.gif

[Chika]

Re: So fork, then

I agree with that, mostly because I fell into the same trap years ago with openSUSE 12.2 (12.1 was a waste of time as systemd was so buggy on that version and replacing it with sysvinit was the only solution). Since then systemd has crept like a huge slug-like creature into so many parts of the system including a mid-release change in oS 12.3 which killed a number of applications without notice. To this day I still keep 11.4, the last version of openSUSE not to have systemd in it and a bloody good version IMHO going in various places and may well do so beyond the death of its Evergreen support demise seven months hence rather than Poettering about with the broken dross I see more recently.

[Peter Gathercole]

"Haven't used it much yet"

And there is your problem.

You really know that it's not the right approach when you find your first system that either does not complete the boot process, or even worse, sometimes does but sometimes does not.

You then have this impenetrable black hole to try and debug, which may "appear to be well-documented", but does not tell you what is happening.

Once you've seen it, the "huge pile of little shell scripts" is easy in comparison. The naming convention is only funny if you don't understand how the shell performs globbing.

[Cipher]

Re: So fork, then

You probably liked Poettering's Pulse Audio as well, correct? How many years did it take good coders to fix that clusterfuck?

[Anonymous Coward]

Re: So fork, then

> You probably liked Poettering's Pulse Audio as well, correct? How many years did it take good coders to fix that clusterfuck?

We're still counting. The fucking thing still does not work properly.

The problem however is not Poettering with his (on the face of it) good ideas and (in all evidence) incompetent and careless execution. The problem are those who listen to him and end up packaging up his stuff in our distros.

As someone has said above, it would appear (and I say appear because I haven't met him in person) that this young man still has a lot to learn, especially from the many mistakes the rest of us have done in the past.

As for systemd itself, it went alright on the workstations it's been running for about five months. Then I upgraded a couple servers recently... and then the Scheiße hit der Ventilator. Not a happy customer here. :(

[Chika]

Re: So fork, then

How many years did it take good coders to fix that clusterfuck?

You mean they fixed it?!? I normally switch it off for the sake of my own sanity at least.

[FatGerman]

Re: So fork, then

You probably liked Poettering's Pulse Audio as well, correct? How many years did it take good coders to fix that clusterfuck?

Very pertinent point I think. Pulseaudio was, in theory, fantastic. It had all sorts of things that were very good and very useful. It was one of the things that made me decide I could realistically use a Linux desktop - It was about making Linux easier for the desktop users.

Unfortunately it was implemented so badly, by someone with no apparent ability to listen or take suggestions, and was so frequently broken that in the end it was one of the main reasons I shelled out for a Mac.

Good ideas poorly implemented and largely untested seems to be the story of Pulseaudio and possibly systemd, but then it seems to be the entire Gnome (and KDE for that matter) philosophy these days. I blame the parents.

[wayward4now]

Re: So fork, then

Thank you. Systemd has been on my machines since it was announced for Debian Jessie. I'm liking it. I sure don't see sweating bullets over it as wheezy sysv has a long shelf life ahead of it.

[Denarius]

Re: So fork, then

@MacRodent: What pile of scripts ? usually a few in /etc/init.d with links to start/stop/do_something in the appropriate /etc/rc[0-5].d directories. What is hard about simple scripts that can stop, start,reload a specifc set of binaries ? On some servers with a lot of dependancies spawning shells to run scripts can have a brief high load. Which is why Debian has dash shell, small, fast, light to do start/stop with minimal load and even less attack surface. Replace this well understood set of design and process with binary blobs controlling a black box with a huge attack surface. Pity OpenSolaris is dead. Later releases looked OK, even if I prefer btrfs to ZFS.

[Long John Brass]

Some good ideas in systemd ... but

I really don't like the one large monolithic monster app approach

I also miss being able to just tweak an init script to make it do what I want

I'd be willing to give that up if the flexibilty was provided some other way

Like many others I've only started looking at systemd

Like a new Doctor Who, I'm not sure if I'm going to like it or not, time will I guess tell

[Mad Chaz]

the "fun" part about systemd

Is how much it wants to do. Explain to me why an init system needs (yes, it's required) an http server running?

Systemd is basically trying to take over the entire software stack. The attitude of the devs speaks volumes about this too. You find a lot of gems in the kernel mailing lists. The Gentoo Linux forum as been rather alive about this topic, as the maintainers of the distribution refuse to make systemd the default (it's an option, but not default) and a lot of the users agree with the choice.

Systemd is a lot like the windows registry. Lots of binary blobs you can't read or fix if things go wrong. Most linux users would rather the system took 10 more seconds to boot and be sure they can fix it if something goes wrong. It's not like we reboot our machines all the time.

[tom dial]

Re: the "fun" part about systemd

Well, I have noticed that since I set up a couple of systems on Jessie and systemd I wind up booting them a lot more often than the Wheezy ones that still use sysv. I'm not sure whether to blame that on the slight instability that goes with a testing release or on systemd. The do seem a bit more unstable than my past experience given the announced freeze date of 5 Nov, only two weeks from now.

[Anonymous Coward]

Re: the "fun" part about systemd

Again - if you want to install Gnome under Gentoo then systemd is the default, and really the only way to install it without doing some serious mucking around under the hood. To just say "systemd is not the default on Gentoo" kind of twists that fact.

[Mad Chaz]

Re: the "fun" part about systemd

You make it sound like installing gnome is a must. If you want gnome, yea, you are stuck with systemd. That's systemd and gnome's fault, not gentoo. A lot of people who run gentoo are also likely to use something else then gnome (if they have a GUI) and the default installation manual still recommends using openRC.

[MacroRodent]

Re: the "fun" part about systemd

"It's not like we reboot our machines all the time."

Servers, no. But PCs and laptops do get booted, because they are turned off. Some people claim they are capable of "suspending", but I have found it far too often results in a crash or odd behaviour (like wlan connection not getting restored) when the machine is supposed to wake up, no matter if it is is running Linux or Windows. So now I don't even bother to try, and use a proper shutdown.

I have come to the conclusion that suspending works reliably only in systems where the computer and OS have been designed together with power management in mind, as is the case with smartphones and pads.

[Mario Becroft]

Re: the "fun" part about systemd

Not sure where you got that idea from. I hadn't rebooted my laptop (running Gentoo Linux) in more than a year, until last week when I had to shut it down to upgrade the RAM. I'm not sure why anyone would choose to shut down their laptop when they could just close the lid and suspend, open lid and continue working where they left off. If your wlan connection fails after suspend maybe your system is misconfigured?

Back on topic, I loathe systemd. Alas, it's in RHEL 7 so I now have to deal with it in Enterprise environments. That said, it has spread its tentacles far wider since the version in RHEL 7, which essentially just functions as a poor init replacement. I suppose I should be thankful for small blessings.

[Destroy All Monsters]

Re: the "fun" part about systemd

I'm not sure why anyone would choose to shut down their laptop when they could just close the lid and suspend, open lid and continue working where they left off.

Autism.

Ever upgrade the kernel?

[Anonymous Coward]

Re: the "fun" part about systemd

> Ever upgrade the kernel?

Yes, of course. Then I carefully overwrite whichever bits of memory from the old kernel need overwriting.

:)

[NumptyScrub]

Re: the "fun" part about systemd

quote: "I'm not sure why anyone would choose to shut down their laptop when they could just close the lid and suspend, open lid and continue working where they left off."

I have a low-power Mint box that stays on 24/7 and only gets rebooted for updates and upgrades, but everything else spends more time unused than used, so it gets shut down. The standby power draw for 18 hours out of 24 equates to more inconvenience for me (in the form of electricity bills) than the inconvenience of an extra 10 second wait while the machine boots.

YMMV, of course, as everyone weights inconvenience differently. As long as you are aware that a laptop on standby is still discharging the battery (at a reduced rate) and act accordingly, then it is entirely your choice to use standby instead of shutting it down.

Tangential aside: almost every laptop I pull off the shelf at work for a rebuild is discharged, so I suspect most people at work also use standby in preference to a shutdown, and return laptops in a suspended state. If they were shut down they shouldn't be flat inside of a week of storage ^^;

[frank ly]

@Numpty Scrub Re: the "fun" part about systemd

Why do you reboot after an update? I thought that wasn't needed with Linux generally. My MINT system never asks me to reboot after an update and I've seen no documentation or advice anywhere to say that I should.

[itzman]

Re: @Numpty Scrub the "fun" part about systemd

You do need to if the kernel is up[graded. And you actually want to USE the upgraded kernel.

If you are happy to run the existing kernel until you do a boot, well fine.

Parts of Mint that wont get upgraded in the live machine without a boot include the kernel, most things to do with grub, and most things to do with Plymouth, since these are involved in the boot process. Plus a few scripts that are involved at boot time.

Most of us who do upgrade kernels religiously do so because we hope to fix some problem and so we tend to try it out by rebooting immediately.

[wikkity]

Re: @Numpty Scrub the "fun" part about systemd

Maybe the update included a new kernel? I've meant to try ksplice on mint but never got round to it, rebooting takes my (home) server machines less than 5secs and with no SLA requirements (assuming no prompts for saving stuff) .

[NumptyScrub]

Re: @Numpty Scrub the "fun" part about systemd

quote: "Why do you reboot after an update? I thought that wasn't needed with Linux generally. My MINT system never asks me to reboot after an update and I've seen no documentation or advice anywhere to say that I should."

As mentioned by others, it's only kernel / boot related updates (basically version updates if you use the main build), everything else doesn't require (or ask) for it. The last time it got rebooted was due to a physical relocation that required disconnecting the power, other than that I'm struggling to remember the previous one. Probably when I went from Mint 12 to the Debian rolling build (less updating required) ^^;

[Peter Gathercole]

Re: the "fun" part about systemd

Unfortunately, laptops in particular vary quite a lot in the chipsets that are included. There is a lot of tuning required to get a Linux stable when suspending and resuming.

There is a whole subsystem called pm-utils (ironically modelled on sysv init) which allows you to tweak the suspend and resume system for the particular model of laptop. I tend to run IBM/Lenovo Thinkpads, for which there are a significant numbers of profiles which work quite well.

Where I've had problems are with the models with Radion Mobility graphics adapters when KMS is enabled, and I've also had a problem with the sample rate of pulseaudio not getting restored properly.

But with KMS turned off (Ubuntu releases between 8.04 and 12.04), if you can ignore the audio issues, suspend works quite well. 14.04 appears to have fixed the sound sampling issue.

Hibernate is more problematic, as on Thinkpads it is necessary to have a FAT primary partition on the hard disk to contain the hibernate file. Before I upgraded my Windows partition to Win2K, it used to work fine, but all those years ago, when I upgraded to NTFS I found that the hibernate code in the Phoenix BIOS could not handle the newly formatted NTFS partition. The 'old' boot record format cannot have more that 4 primary partitions (WinXP now, current Ubuntu, last/next Ubuntu and an extended partition containing the rest), I don't have a spare primary partition just for a FAT filesystem.

[Anonymous Coward]

Re: the "fun" part about systemd

> There is a lot of tuning required to get a Linux stable when suspending and resuming.

Is that borne out of recent experience? For me, I haven't had any issues with suspend or hibernate on any machines for at least six years.

The FAT primary partition for hibernation must be a Thinkpad (is that IBM?) specific thing. As far as I knew (although I haven't looked at the code), hibernate writes to swap (which is of course a problem is both your RAM and your swap are full).

[keithpeter]

Re: the "fun" part about systemd

"Hibernate is more problematic, as on Thinkpads it is necessary to have a FAT primary partition on the hard disk to contain the hibernate file."

X60, Trisquel Linux, no FAT partition at all just a few gig of swap (Linux swap / Solaris) and a / partition that is ext4.

Hibernates and suspends fine.

[Zolko]

Re: the "fun" part about systemd

"PCs and laptops do get booted, because they are turned off"

my uptime currently is 46 days, with Debian stable on a MacBook Pro, launching heavy-dute 3D CAD in Windows virtual machine, external monitor sometimes, kids playing Minecraft or Dofus, put to sleep each evening.

Self-compiled kernel, goes without saying.

No, really, booting is for sissies. But even then, with an SSD, boot-time is less than 10 seconds, KDE takes more time to load than the boot process. And in the boot process, rEffit and GRUB take up most of the time. So what is the gain of 2-3 seconds boot ?

[Matt Piechota]

Re: the "fun" part about systemd

"No, really, booting is for sissies. But even then, with an SSD, boot-time is less than 10 seconds, KDE takes more time to load than the boot process. And in the boot process, rEffit and GRUB take up most of the time. So what is the gain of 2-3 seconds boot ?"

I tend to reboot even after non-kernel updates if the system isn't critical. The last thing you want is to have an unplanned reboot in the middle of the day to find out that the patch you installed a couple weeks ago broke something.

[Stevie]

Re: a crash or odd behaviour ... when the machine is supposed to wake up

Well, not for nuthin' my Windows 7/64 bit/Dell Inspiron lappy has been suspending and hibernating and coming around in a working, stable and predictable fashion for the four years I've owned it. This behavior has survived an O/S re-installation (so I could fit a clean install on a much larger hard drive), a simple memory upgrade and the carving out of the registry by hook and crook of McAffee, which doesn't go away even if you refuse to pay for it and tell it to fuck off in as many words.

My wide's laptop has never had an issue waking up either. Same OS/Model. Smaller hard drive and memory allocation.

My old XP desktop never hung when waking from sleep either. Nor did the one I had at work.

[Vic]

Re: the "fun" part about systemd

I have come to the conclusion that suspending works reliably only in systems where the computer and OS have been designed together with power management in mind, as is the case with smartphones and pads.

The laptop I'm typing this on is a Packard-Bell TJ45[1]. It is the current in a long line of laptops I've had that suspend & hibernate just fine...

Vic.

[1] My next-door neighbours threw it out when it had become too broken for their use. I've been using it happily[2] for a couple of years now.

[2] Well, as happily as you can use such a pile of crap...

[Fatman]

Re: the "fun" part about systemd

"It's not like we reboot our machines all the time."

Where I once worked, it occurred DAILY.

Manglement, in its zeal to save money did the cost calcs for 148 hours of non business hours, and decided that we should shut them down at the end of the day.

Now, considering that those machines ran WindblowZE that Global Monopoly Operating System, which was (and still is) a prime target of miscreants; it made sense to shut them down at the end of the day.

One day, I had to deal with a whining (L)USER who bitched and moaned about having to wait for the machine to boot each morning. I reminded him that a shutdown machine can't:

1) be hacked (while it is shut down),

2) be used to send spam,

3) be used as a launching point for network infiltration,

4) put power on hours on the hard drive (at that time they did not power down the hard drives, again due to (L)USER complaints)

5) subject the machine to overnight/weekend weather related power disruptions.

So, yeah, some people DO reboot their systems on a regular basis.

[jbuk1]

Re: the "fun" part about systemd

How did management calculate that electricity cost them more than the lost man hours and additional wear and tear to the servers?

Madness.

[david 12]

Re: the "fun" part about systemd

>an init system needs (yes, it's required) an http server running ... Systemd is a lot like the windows registry...

I take it you know very little about the windows registry?

[Mad Chaz]

Re: the "fun" part about systemd

Having spent the last 10 years supporting Windows machine(server, desktop, you name it), I know entirely too much about it for my own taste.

[Silviu C.]

They actually advocate for SystemV init. Wow! This makes their "manifesto" look more like parody or a laughable trolling attempt.

Good luck with forking it and finding someone to sponsor you with (at least) infrastructure. I highly doubt they even have the required man power to run a forked project.

Btw, if they are Debian developers why don't they say who they actually are. Why lurk in the shadows?

[Anonymous Coward]

>I highly doubt they even have the required man power to run a forked project.

They wouldn't need to fully fork Debian. They could just provide a installer images that install with sysv init and then a repo that provides versions of packages that depend on systemd in standard Debian.

[Destroy All Monsters]

Btw, if they are Debian developers why don't they say who they actually are. Why lurk in the shadows?

Have you SEEN youtube videos where Poettering "discusses" things?

[certainquirk]

Maybe your beard's a little too short to remember how the Internet was once a rather anonymous place.

[Lyle Dietz]

Such hatred

Why do I get the feeling that a lot of the people that want to keep sysvinit have never tried to read a service script, let alone write one.

Believe me, when you're trying to figure out why your service isn't starting, systemd looks mighty nice, and upstart is pretty cute too.

I for one welcome our systemd overlords.

[Paul Crawford]

Re: Such hatred

I think upstart is a bit more sane, but even then it has its dumb aspects.

Why, for example, is upstart not calling the traditional scripts in order as well? That way you could at least use its dependency capabilities with non-upstart processes, just like the "service wibble start|stop" sort of command suggests you could.

[Destroy All Monsters]

Re: Such hatred

Believe me, when you're trying to figure out why your service isn't starting, systemd looks mighty nice, and upstart is pretty cute too.

To paraphrase a saying from OO programming...

People had a serious problem with properly managing service startups under the increasingly creaky SysV approach.

They thought systemd would be a nice idea.

Now they had two problems.

[Roo]

Re: Such hatred

"Why do I get the feeling that a lot of the people that want to keep sysvinit have never tried to read a service script, let alone write one."

Speaking for myself I have read a fair few of them and written a couple and I didn't find it very hard the first time around when I was a PFY either, they're just shell scripts after all. The nice thing is with init.d/* is that you could swap the shell scripts for something else if you really hate them, binaries, makefiles, or even roll your own special init.d shell if that is too easy.

[Vic]

Re: Such hatred

The nice thing is with init.d/* is that you could swap the shell scripts for something else if you really hate them, binaries, makefiles, or even roll your own special init.d shell if that is too easy.

And when you're really screwed - you can instrument them to see what's going on...

Vic.

[JEDIDIAH]

Re: Such hatred

> "Why do I get the feeling that a lot of the people that want to keep sysvinit have never tried to read a service script, let alone write one."

Not only have I read and written service scripts but I have done so quite successfully. They're just standard shell scripts.

On the other hand, my first attempt to alter Upstart scripts resulted in an unbootable system.

Individual init scripts can be as simple or as complex as you want them to be. Init itself is very simple and difficult to sabotage without a lot of highly focused effort.

[disgruntled yank]

Re: Such hatred

I don't know why you get the feeling. I've pored through a number, and written one or two, and I am far from a hard-core sort.

As for trying to figure out why the service isn't starting, /var/log/messages usually had a hint or two.

[MSLiermann]

Re: Such hatred

Funny; I've been administering Linux servers for over a decade and never had issues reading, writing, using, or understanding SysV init scripts. The complexity of SysV init scripts is very much overstated by the systemd advocates, who of course benefit from that perception.

[T. F. M. Reader]

Re: Such hatred

"Believe me..."

Sorry, but I am not prepared to. Having dealt with sysvinit, systemd, and upstart in both development and production environments I must say I am not at all impressed by the last two. In my experience, upstart is too flaky and systemd is just too complex and opaque.

Reading or writing sysvinit scripts is not difficult at all if you are literate. I myself banged up a fair number of upstart->sysvinit replacements for custom daemons without any significant effort (main distros provide libraries of very useful shell functions out of the box, and once you familiarize yourself with a few of those any difficulties go away). In every single case the switch led to much improvement in reliability and to much reduction in the frequency of puzzled WTF expressions on the faces of developers and QA folks, which was the main purpose of the exercise to start with.

[Anonymous Coward]

Re: Such hatred

> Believe me, when you're trying to figure out why your service isn't starting, systemd looks mighty nice, and upstart is pretty cute too.

Believe me, it fucking doesn't. And my fucking servers wouldn't have fucking crashed if it hadn't been for that sorry piece of wank. I couldn't give a flying shite whether it looks "nice" and "cute" or whatnot. Stable and predictable is what does it to me.

If Unix has not just survived but also outlived every other operating system out there they might have got something right. And if there is one thing that defines Unix, that would be the "do just one thing, and do it very well" philosophy. Let's not fuck with that, shall we?

It might be that sysinit needs a replacement, but systemd is totally not the answer.

[Bronek Kozicki]

Re: Such hatred

If Unix has not just survived but also outlived every other operating system out there they might have got something right. And if there is one thing that defines Unix, that would be the "do just one thing, and do it very well" philosophy. Let's not fuck with that, shall we?

this +1

sorry, just had to post.

[Anonymous Coward]

Re: Such hatred

> Why do I get the feeling that a lot of the people that want to keep sysvinit have never tried to read a service script, let alone write one.

And don't now why. Maybe you should discuss that with your therapist.

Like the many others who have replied, I too have written, debugged, and tweaked service scripts (last time two days ago). Hardly takes a rocket scientist--they are pretty straightforward shell scripts after all.

[forquare]

Linux != UNIX. If you want the UNIX philosophy, go use UNIX!

Not some cheap knockoff (winkie, joke, etc.)

[Anonymous Coward]

> (winkie, joke, etc.)

Word of advice: keep your day job.

[Anonymous Coward]

Thank you!

Yes. Indeed. Thank you for helping me to decide on this.

FreeBSD it is then, at least for me.

True story. Back at the turn of the century after my landline service had been down for a few days I called Ma Bell (well, they were calling themselves Verizon at that point) to complain. The service rep was very polite, but when I aked her what my family was supposed to do if they needed to call the police in an emergency she innocently replied, "don't you have a cell phone?".

Dropped the land line service the next day and got a pair of cell phones to replace it, serviced by CIngular.

The moral of the story is, sometimes people will listen to good advice -- even if it wasn't intentional.

[southpacificpom]

Gimpd

Well i thought it was April 1st when I heard Gimp was getting systemd integration, this is just one big fucking piss take IMHO.

You have Mr Pottyring saying systemd is perfect and that any faults are with downstream implementation. Well I spent several days wondering why the fuck my Cups server had broken in Debian Sid, only to find out that systemd requires both IPv4 and 6 to be active else Cups will not work - I had disabled IPv6 due to previous issues. I would expect Cups not to work if both stacks were non-functional.

Now I have a Samba server on my main desktop that hangs at shutdown due to fact that systemd appears to be killing Samba before it dismounts the networked shares properly - no sane fix so far from what I see.

Yes I know Debian Sid is "unstable" but it was rock solid before this systemd shit came along. My impression of Sid and Debian itself are now one of turmoil and I can only hope that Debian reverses its original decision and boots systemd into touch also, I hope they seriously have a look at their leaders because they have allowed this mess to happen.

If Debian stay with systemd then I will go elsewhere. I have already started playing with FreeBSD and FreeNAS along with OpenBSD too as I'm quite familiar with these systems anyway and their leaderships are not prone to follow like sheep at a whim.

Personally I wouldn't want a Debian fork but if that's what it takes then so be it but the Linux ecosystem is already too fragmented in my opinion. If there was a fork then sure I'd look into it but whats really needed is a weed out of the Debian leaders that have got us to this point, they are setting the distro up for its potential downfall.

[MacroRodent]

Re: Gimpd

You can always use Slackware if you prefer an old-school init. Haven't run it for years, but it was one of my first Linux distributions. As the Slackware philosophy is doing things the Unix way (see http://www.slackware.com/info/), they are unlikely to adopt systemd anytime soon.

A good distro, but not for newbies.

[southpacificpom]

Re: Gimpd

Thanks for that.

Yes I'm testing Slackware too at the minute but I believe they are currently sitting on the fence regarding this. The thing is that if systemd gets too invasive (which it already is) then core services and apps may require more effort than what its worth to run as non-systemd versions.

From what I know, the only non-systemd committed distros (at this moment in time) are Slackware, Gentoo, Crux and Alpine Linux. I think out of those I would go with Alpine Linux, a distro which is very much underrated IMHO.

[keithpeter]

Re: Gimpd

"Yes I'm testing Slackware too at the minute but I believe they are currently sitting on the fence regarding this."

The slackers are a pragmatic bunch not given to drama. I run it on my typing box (a boat anchor Dell E5240 laptop). As you say, Volkerding will roll in systemd if it becomes unavoidable when attempting to provide a decent desktop experience.

"From what I know, the only non-systemd committed distros (at this moment in time) are Slackware, Gentoo, Crux and Alpine Linux."

There are a couple of 'one dev and a git repo' Linuxes like Dragora (runnit).

Of course, there is CentOS 6 and the other EL clones (support until 2020).

[ElReg!comments!Pierre]

Re: Gimpd

There are also non-Linux Debian ports, if you like Debian's userland... I'm told the freeBSD one is pretty good, and FreeBSD is not on the systemd team's radar.

http://www.debian.org/ports/kfreebsd-gnu/

[southpacificpom]

Re: Gimpd

"http://www.debian.org/ports/kfreebsd-gnu/"

AFAIK it's in danger of being dropped.

Next?

[ElReg!comments!Pierre]

Re: Gimpd

> "http://www.debian.org/ports/kfreebsd-gnu/" AFAIK it's in danger of being dropped.

haven't heard these rumours but it may well be. On the other hand, if adoption grows (perhaps driven by the systemd ruckus), then it won't be dropped... vote with your popularity-contest.deb!

[keithpeter]

Re: Gimpd

"http://www.debian.org/ports/kfreebsd-gnu/"

AFAIK it's in danger of being dropped.

Next?

OK, OpenBSD (Gnome 3.10 installable) and the other BSDs, and OpenIndiana (party like it is 2006).

[t.est]

Well they are closer to the origins of systemd :)

https://wiki.freebsd.org/launchd

[James 132]

Re: Gimpd

I had a similiar problem with an NFS mount in /etc/fstab; systemd was attempting a mount before network was up and was therefore failing. There's an 11 month old Bugzilla ticket for this very problem.

The solution was to use a systemd.mount, and this worked. I've had dhcpcd and udev misbehave as well, in the most basic of configurations, and I can't troubleshoot it other than seeing in journalctl that it isn't working.

It works okay for desktop, but you'll see odd things on servers that have service quirks (the very thing systemd is supposed to make easy...) like the Samba shutdown issue you have seen.

One could argue these are teething troubles, but Lennart just doesn't seem to care. That, combined with the increasing sprawl of systemd gives me great concern.

[ElReg!comments!Pierre]

Re: Gimpd

It works okay for desktop, but you'll see odd things on servers that have service quirks (the very thing systemd is supposed to make easy...)

I've seen intermittent (like, every other boot) problems with laptops too, mostly trackpad and/or WiFi chipset*. So much for the "faster boot" argument when you have to reboot immediatly after every other boot...

*problem gone after a revert to sysvinit, so definitely a systemd issue

[jb99]

Excellent!

I was seriously thinking of giving up on Linux due to systemd.

Not because it couldn't mostly be ignored but because it's really really awful and just not what linux should have and because the developers seem to want to impose it on everyone anyway.

Frankly if I want that I might as well use windows.

Hopefully this will go somewhere and kill the nonsense that is systemd before it ends linux.

[ElReg!comments!Pierre]

Hopefully this will go somewhere and kill the nonsense that is systemd before it ends linux.

Oh, systemd won't end Linux, it will always need the kernel. It may however end GNU (that's the long-term goal when you listen to Lennard P.)

Actually I'm half-surprised that Stallman hasn't said anything yet...

[jillesvangurp]

I'm hearing criticism but I'm not hearing pragmatic solutions to real problems. Systemd may not be perfect but I for one have seen just a little bit too many poorly crafted init.d scripts lately. So, I totally buy that something needed to be done. If systemd sucks so much, what's a real competitve alternative (as opposed to sticking with the horrible script hairball that is init.d)? Upstart might have been it but it seems Ubuntu is walking away from that. This might be a bad case of the before mentioned grey beards being part of the problem instead of the solution. Incidentally, the linux way has always been to quit moaning and start coding. If you don't like something: get organized and fix it. This has always clashed with the if it aint broke don't fix it mentality but it seems that enough people agree init.d is broken enough that it is worthy of fixing now (finally). I've not bought in to Systemd yet either but I won't be sorry to see init.d go. I'll shed no tears over that one.

[Paul Crawford]

Systemd won't fix poorly implemented services either. Anyone who is not able to write/test/test-again something for init.d won't magically have it all work perfectly under another scheme. Upstart seems to be the least-worst option for something that permits dependency resolution and parallel starting, but its not perfect either and really should be extended to include managing the init.d scripts as well, as realistically there is a lot of stuff that won't get converted to native jobs any time soon.

At one point the Ubuntu project was doing a really good job of making a Linux distro that worked, and was fairly sane, but sadly from about 10.04 seems to have lost its way. It really needs someone like that who is interested in PC use, and not the tablets they fixated upon, to drive a project sanely.

And never listen to the GUI developers either: look how many stupid changes have been made to Gnome and Firefox, etc, etc.

[Alan_Peery]

Poorly crafted init.d scripts can be worked around very simply by not installing that *particular* package. systemd breakage can't be worked around.

[John Sanders]

Pragmatic options

Pragmatic solution:

Use systemd just as an init replacement and polish it, http://freshcode.club/projects/uselessd make everything else really optional. (like all the crap with the binary logs)

Give the boot to Gnome until they get their act together again, and tell the Gnome developers they can not dictate shit.

To understand Gnome's attitude go to this link, and read the comments https://trac.transmissionbt.com/ticket/3685

The fun begins at comment n4 from the top

[Anonymous Coward]

> (as opposed to sticking with the horrible script hairball that is init.d)

Ah, yes. Let's have one big opaque binary blob instead, shall we?

[Dr. Mouse]

There are many possible approaches to the system init process. SysV init is certainly not the best solution. It has many advantages, including how simple it is (I have written many init scripts for my own use), but it is quite messy, and pretty slow.

I have used upstart a bit. This seems just as messy, not as simple, but the parallelisation does speed things up a fair whack. This is very welcome on a desktop machine.

I haven't used systemd yet, so I won't comment.

However, when it comes to a server, I want tried and tested solutions which are simple to administer. I don't care if it takes longer to boot up, because it will rarely be shut down. My home Debian server, running on desktop-class hardware, has been running continuously for nearly a year, and was only shut down then for a hardware upgrade. Business servers get shut down only when absolutely necessary. A change from 1min to 30s to boot up makes no difference in most server environments.

What Debian need to do is preserve the choice. Allow people to use systemd if they want, but leave SysV init available too. I know this is a more complicated way to do it, but systemd is not suitable for everyone, especially a lot of their core users.

[JEDIDIAH]

Pottering just doesn't get it.

Yes. This is something that the "progress for the sake of progress" crowd just doesn't seem to get. In the domains where Unix has it's most powerful stronghold, the one overriding consideration is reliability. It doesn't have to be fast It doesn't have to be fancy. It doesn't have to be usable by a trained monkey. It needs to be reliable.

It's simply insane that it's a server vendor that's pushing this crap.

[Anonymous Coward]

Re: Pottering just doesn't get it.

...It doesn't have to be usable by a trained monkey. It needs to be reliable.

Aye...and I'm fighting a futile rear guard action to keep our linux servers (current uptimes 26 and 89 days - memory upgrades - prior to that, uptimes over a year) from being replaced by a system that will be run by a trained monkey...as it's a half trained monkey that's in charge of our IT.

Risible thing, I'm running these servers on salvaged desktop hardware that couldn't run Win7 (and was pretty shitty at running XP, come to think of it...)

[Fatman]

Re: Pottering just doesn't get it...It needs to be reliable.

prior to that, uptimes over a year) from being replaced by a system that will be run by a trained monkey...as it's a half trained monkey that's in charge of our IT.

$DEITY, I feel for you, under the thumb of another graduate from your typical "School of Damagement".

[BitDr]

Re: Pottering just doesn't get it.

Insane? No. Dumb like a fox? Perhaps.

We can pretty much all agree that server environments really don't benefit from a quicker boot time simply because they are rarely rebooted.

Given that the above is true, and given that systemd is being pushed by server vendor we can say that the actual purpose systemd is NOT because we need faster boot times.

Given that systemd is beginning to control almost everything, and holds forward that it makes life easier to tweak when it comes to services. I postulate that the real purpose of systemd is to grab GNU/LINUX by the throat and dictate terms to any and all who use it.

All good is hard. All evil is easy.

Dying, losing, cheating and mediocrity are easy.

Stay away from easy.

--Scott Alexander

[Anonymous Coward]

Re: Pottering just doesn't get it.

"We can pretty much all agree that server environments really don't benefit from a quicker boot time simply because they are rarely rebooted."

Unless it's a CONTAINER. These can come and go on a moment's notice, and in THESE instances, you want them up ASAP, usually in less then a second because there's a demand triggering the startup.

Plus outside servers, other environments can be complicated or dynamic, such as hotplugging in an HDMI monitor or a wireless network adapter. These break the normal conventions of hardware that presents itself at startup (during the init), so this changes the game. A modern system has a lot of hotplugging, and handling highly-interrelated things that come and go with no notice means sysvinit's slipping out of its operable environment. So that raises a very important question. If init's remite of initializing hardware is anachronistic in a world of dynamic hardware, what should replace it?

[Anonymous Coward]

Re: Pottering just doesn't get it.

> what should replace it?

Something far less bloated than systemd.

[Charles 9]

Re: Pottering just doesn't get it.

Like what? And what about systemd's resemblence to OS X's launchd?

And going back to the idea of using text files for everything, that would be all well and good if there was a universal grammar for these files. But each program seems to do its own thing, and this can produce complicated problems with multiple dependencies. Essentially, one tiny slip could throw worse an error; it can produce incorrect-but-valid data, which can then cascade to programs after it and so on, and because each program uses its own grammar, it can be hard to find just where it went wrong because both the file and the problem chain are non-obvious. Plus there's the matter of unstructured data like raw streams where formatting cannot be a given. Or sources that are non-English (and non-Unicode to boot) from places that may not grok English.

[Mage]

sysvinit & systemd

We need something better than sysvinit

But systemd obviously isn't it as it seems to create problems.

[Charles 9]

Re: sysvinit & systemd

Serious discussion. Sysvinit doesn't work on modern systems where hardware is not static and buses are not hard-set (slot 1 gets assigned x and y, etc.). But if we want to adhere better to the UNIX philosophy, can't the differerent buses be delegated to dedicated subsystem programs, with whatever's at PID1 being just the coordinator, only needing to internally handle the baseline buses presented at bootup? It would still need to be able to handle events and so on, yes, but at least this way it compartmentalizes the control structure logically, say one program handles the PCI Express bus, which may have the USB controller attached so would in turn start up a USB handler, and so on.

PS. It's been a bit since I've dug into the innards, so if this is how it's done now, just mention it. But last I checked, a lot of the hardware support, including hotplugging, is still done in the kernel.

[Nick Kew]

Slackware?

I've got Debian on this box, and aspects of it are indeed (surprisingly) painful.

I may revert to Slackware next time. See if that's still honest.

[John Sanders]

Re: Slackware?

Just say it proper, sytemd is shit because it has too many problems, because it does way too much.

I would not have a problem with it (I like the idea of systemd) if it wasn't trying to reimplement, cron, anacron, iptables, rsyslog, xinetd, and more.

Seriously somebody has to stop the madness.

[disgruntled yank]

Re: Slackware?

Upvoted for iptables. Who knew how much one could come to love, and then miss, cryptic little text files?

[jake]

Whatever.

Slackware on the desktops, BSD on the servers.

It's been that way for 20+ years, at least here.

Everything else is chasing shadows, near as I can tell.

[BitDr]

Re: Whatever.

The way things are going in the LINUX world I'm probably going to migrate my servers to BSD.

[Will Godfrey]

Tried it - Hate it.

I've been a debian user for years, and gave Sid a spin when I heard all the fuss. To me it was a total disaster. I like to run very slim, fast installs. Well this was fast to boot... sometimes, then failed to boot other times and random stuff didn't work or wouldn't connect.

I think I'll stay on squeeze as long as possible, and then if this insanity hasn't ended I'll go elsewhere.

[southpacificpom]

Re: Tried it - Hate it.

Sid was truly good before systemd. I may be forced back to Wheezy while I decide what my future is with Debian, if any.

[Anonymous Coward]

Re: Tried it - Hate it.

I'm running sid without systemd. This install I think has existed from just after woody was released...

If you do a new install just replace and remove systemd once the install is over and everything is mostly back to normal except if you want Gnome.

I think what will eventually happen is that even people in the Gnome camp that have no idea about what people want will realise that rolling tens of daemons that have worked just fine for 30+ years into systemd was a bad idea and everything will get split back out again while retaining the fancy IPC via dbus stuff.

You would have thought with the freedesktop group etc that someone would have come up with a standard so that Gnome etc could depend on a standard (even if it only had one implementation at the time) instead of a massive ball of stuff.

I would have also thought that DDs would have realised that switching over to systemd as the default should have been left until it had been optional in at least one release. Apparently far too many of them have spent more time on their excessively long "I've spent all of my adult life at university" boasting signatures than actually thinking about the problem at hand.

[Gene Cash]

Re: Tried it - Hate it.

No, it's NOT back to normal. They break udevd,dbus, cups, and other things to live with systemd. For example, you can no longer run fsck if you need to on automounted volumes from udevd because it now uses process groups to detect children and kills anything running over 20 seconds.

[Anonymous Coward]

start ups

No experience of systemd and, on Solaris, having to use svcs - not all bad.

But advantages of the older init.d approach are

1. Transparency (all scripts are readable and, provided they follow the usual organisation and options, clear).

2. Order of startup and shutdown and at what run level are obvious and easy to control.

3. Trivial to port between OS releases and to other UNIXes

4. Light weight.

5. Should one need to stop/start/restart an application, it is easy to do so correctly by running the same script as the system (most important if it concerns, for instance, PID files or other locking mechanisms).

Still, for the real traditionalists, what is all this nonsense about separate scripts? It was even nicer with one, monolithic script that started everything. It was enormous fun writing applicaiton installation scripts to edit this script to add or delete the start/stop instructions to the file (ed(1)). Now that was absolutely fine grained control.

So many Linux variants are just the new Windows, without the maturity, casual user useability or breadth of popular (private and business) applications.

[Kurgan]

Death to systemd

I am one of the anti-systemd rebels, and all I can say is that I can confirm that I like the init system that I currently use, and that I don't want systemd to be mandatory in a Linux distro that's aimed at servers.

[Alistair]

Thank you Patrick V.

At least there are some sane folks left in the pool.

And yes, I will be moving back to my first distro.

[agricola]

There goes the Linux touchstone.

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better"

-- Edsger W. Dijkstra

[oh_cfc]

This might be pedantic, but what makes this a 'fork' rather than just another debian based derivative out there?

[channel extended]

My Fun!!

I'm using Jessie on a Latitude E6400 laptop. I have had some problems with systemd doing a proper shutdown, it wants to save the current state of the sound card and check for unattened upgrade. If it was just ckecking to see what was running I could understand. BUT it hangs and will not shutdown, Does it not understand I requested a shutdown NOW. I take full responseability for it's use. Still systemd won't shutdown! I have had to resort to issuing a "systemctl poweroff -f" command. I will give up a superfast boot to get a readable boot system. I don't need 90 percent of the cruft that most desktops use.

[Yardape]

alone at last!

More power too yea! If you want to fork, go ahead! But be aware, you will be alone in the future! That means alot, Fewer and fewer pkgs, developers, and in the end very users. Good Luck Grey Beards your on your again! Nothing like starting over once again!

[southpacificpom]

Re: alone at last!

Don't you fucking forget that the Grey Beards have got Linux to the point where its usable by the masses. If you want binary logs and a single point of failure (and compromise) then enjoy your future - while it lasts. Just don't expect a warm welcome when you return to the fold...

[dlc.usa]

Fork != Starting Over Again

You are clearly no greybeard (and I gather proud of it, too).

[ElReg!comments!Pierre]

Re: alone at last!

But be aware, you will be alone in the future!

Yup, that's totally what happened when OpenOffice was forked to LibreOffice for example...

If there is a systemd-less fork, all the sysadmins will switch to it in a split second. We shall see then how desktop monkeys manage to maintain a huge distro on their own, and who will feel alone. I'm sure we'll miss you and your m4dz sk1775 immensely.

[Henry Wertz 1]

systemd

I have fragments of systemd on my Ubuntu 14.04 system, but it still seems to be using upstart. It seems to work OK. But, design-wise? It truly is an abomination. Overcomplicated, buggy*, and opaque**. I support this decision for Debian to fork; at the very least, they can make sure other software that gets distorted to assume systemd exists*** will still function properly without systemd, so when other distros come to their senses they will have much less pain doing so.

*I'm not hitting bugs as set up in Ubuntu 14.04, but I've seen (in "in-between" Ubuntu versions) and read about just how fragile it is. Things have to be set up *JUST SO* to avoid hitting bugs.

**Opaque meaning there's just bits of config file scattered about, but nothing to actually make it apparent just what is supposed to happen when one uses systemd. Documentation is necessarily poor, because it bugs out if not treated just so.

***Riddle me this -- why would software need any changes whatsoever for systemd, when systemd is just supposed to affect the bootup process?

[Jonathan Richards 1]

Re: systemd

> Riddle me this -- why would software need any changes whatsoever for systemd, when systemd is just supposed to affect the bootup process?

I think this is part of the confusion. Systemd *can* be used to replace SysV init, and Debian has decided to do so. There are also *parts* of systemd on which applications may depend: this is what has happened with the GIMP.

I'm running KDE 14.04 on my desktop PC, and it's working with Upstart, though I have 65 scripts in /etc/init.d.

PID 1 is still called init, but I nevertheless have systemd packages installed (systemd-services and systemd-shim, plus libraries) and systemd processes running:

jonathan@Odin:~$ ps -ef | grep systemd

root 349 1 0 Oct09 ? 00:00:00 /lib/systemd/systemd-udevd --daemon

root 1335 1 0 Oct09 ? 00:00:00 /lib/systemd/systemd-logind

root 2630 1 0 Oct09 ? 00:00:00 /usr/lib/x86_64-linux-gnu/systemd-shim

So, it's not the case that "systemd is just supposed to affect the bootup process". Systemd has tentacles, and some people don't like 'em. I'm one, from what I read at the moment. Doubter, that is, not tentacle!

There's a good diagram here [wikimedia commons], which shows the full horror, et aussi en français.

[ElReg!comments!Pierre]

Re: systemd

Riddle me this -- why would software need any changes whatsoever for systemd, when systemd is just supposed to affect the bootup process?

Ha, but that's the point. systemd is not just an init system, it aims at becoming the entire system. It has it's own re-implementation of rather a lot of base GNU utils, for the sake of low PID count as I gather. Rather idiotic and dangerous for no good reason if you ask me, especially as the whole clusterfuck doesn't actually work very well -perhaps unsurprisingly.

[Jes.e]

Apples launchd?

I'm almost over my head here, but Apple seems to have a nice system which they open sourced and Google did a summer of code on.

Here's the relevant bit from Wikipedia:

*****

A port to FreeBSD was done as part of Google Summer of Code Project in 2005 by R. Tyler Croy. However, it can not be run as PID 1 (only a session init), and it is not commonly used on that platform.[6]

The Ubuntu Linux distribution considered using launchd in 2006. However, launchd was rejected as an option because it was released under the Apple Public Source License – which at the time was described as an "inescapable licence problem".[7] Ubuntu instead developed and switched to Upstart, its own service management tool.

In August 2006, Apple relicensed launchd under the Apache License, Version 2.0 in an effort to make adoption by other open source developers easier.[8] However, most Linux distributions use systemd or Upstart, or continue with init, and the BSDs also continue with init.

In December 2013, R. Tyler Croy announced his intent to begin work on his port of launchd to FreeBSD once again, and his "openlaunchd" Github repo subsequently rose in activity.[9]

[Anonymous Coward]

Remember that Quality Polis sketch from Burnistoun?

When one of the lead systemd developers gets his patches rejected from the kernel, you know you should probably be worrying about the stuff he can commit into.

[Anonymous Coward]

Big mistake!

Making things complicated is exactly why I dropped Windows and MacOSX. The geekish route is not the way to go, no matter the dictates of current politics.

[jeffstokes72]

" “We don't want to be forced to use systemd in substitution to the traditional UNIX sysvinit init, because systemd betrays the UNIX philosophy.”"

As in the Fellowship of the Ring, like Gandalf in Rivendell uttering the black speech, I can see a graybeard saying this shit and everyone around is wincing and computers in the background are kernel panicing.

[Solmyr ibn Wali Barad]

An apt comparison. There's an ominous power rising, one *d to rule them all.

While dark speech may not be the best way to handle the threat, as very few can wield it without becoming a prey to it, sometimes it's a necessary evil. Like using Beelzebul to drive out Beelzebul. But that was another tale.

[Steve Graham]

Resistance is useful

I use the current Debian unstable, and I had to install systemd to satisfy some dependency or other, but I then deleted the files it dropped into /etc/dbus-1/system.d/ so none of its processes ever get started. (And it still has sysv init scripts.) Everything is working fine.

I will be moving to another distro (after nearly 20 years) if/when Debian makes systemd the required init tool.

[ripratm1]

The argument on fast booting always amazes me. If I boot debian on a VM it takes seconds to boot up. So clearly it is possible to boot that fast with traditional SysV init. If I put Debian on a physical machine 3/4 of the boot time is posting, IPMI, and RAID initialization, none of which systemd will be able to improve.

[Anonymous Coward]

That's not fast. Fast is less than ONE second, and there IS a need for that with containers that are started on demand.

[Chazling]

I'm with the greybeards on this. I'm all for Ubuntu desktops, but in my job, we use Linux machines for servers. As far as I am concerned, all I want is a command line and simple text scripts for configuration. GUIs just get in my way. I understand that Ubuntu wants to move into desktops more, so there should be a split. And for our purposes here, I will go with the greybeards.

[Matt Piechota]

Surprise

I hadn't been paying enough attention to Linux development in the past few years (it's defiantly become my job and not my hobby), but I was surprised when I started hearing about systemd recently that essentially all the tools that I hate and are pushing Linux in the "wrong" direction are coming from one small group.

[Anonymous Coward]

To grey beards everywhere...

You shall not pass... go back to the abyss

[Jonathan 27]

Actually with the Greybeards for Once

I always thought the point of Debian was to build a Linux distro for greybeards and the reason Ubuntu exists at all is that Mark Shuttleworth wanted to take that and make something for the masses. Debian doesn't need to be user friendly, that's what Ubuntu is for. Forking is not really a good idea.

[ortunk]

Fork systemd or stick a fork in it just get it out of here

Just shutdown my USB3 ports (again) as it borks every few reboots and does it.

And I hate rebooting...

[John Crisp]

Re: Fork systemd or stick a fork in it just get it out of here

Ah but at least it reboots quickly with systemd... Allegedly ;-)

[commiecam]

Debian? Gnome???

As a serious user in a small environment I gave go, using up on Gnome several versions ago, choosing instead XFCE. Several serious problems caused by faulty upgrades led me to move away from Debian and I am now enjoying more solid performance using Slackware and its derivative, VectorLinux. True, being retired, I am no longer working in a production environment, but then I never did, using RTE-A, Ultrix and HP-UX in a scientific environment.

I am appalled by the so-called developers' attitudes in their race toward whatever they are attempting to create and I long for thr days when systems were not rebooted for several YEARS at a time, and software applications were sufficiently straightforward that office personnel could actually run them. I have only seen excessive complication from useless features and ever more bugs in what USED to be nearly pristine Unix systems and their Linux clones. It reminds me of the automobiles of my childhood,, hulking monstrosities weighed down with chrome and skyscraper-like tail fins, built upon chassis used since the late 1930s.

I forget who it was that said that "Software gets slower faster than hardware gets faster." But it seems a shockng waste to me ttht opening a window on a PC currently requires more effort and machine slices than the IRS used to compute the nation's taxes fifty years ago.

Sorry if my venting offends, but all of my work involved around data analysis and networked data transfers, and I can't help but wonder when I look at current software, then reflect that I wrote a novel in 2006 using vi as my word processor. Guess that makes me a (very low grade) greybeard...

[James 132]

Re: Debian? Gnome???

The trouble is, what you're saying is totally true, but nobody remembers.

There's a strange Groundhog Day cycle of pointless reinvention (with little innovation) in Linux that I've never fully understood.

I've seen mentions in a few places that the current problem is one of success: Windows users are flocking to Linux and bringing that culture with them, which is in term driving development, so what's getting developed is an analogue of Windows but at an unbeatable price...

People don't need to go to UNIX summer school to understand the good design practice found there, but it would be helpful to understand why certain practices - tight coupling, no portability, for example - are frowned upon.

[Waffa]

invading human cultures and eliminating them by mixing and dividing is old tool "they" use...

Try not to for instead take authority and if needed in group of 30 old geeks packed by some youth rebels weaponiźed with old hardware go and physically take over main center points to secure future of the development... the ones who surrender and join with cause or retreat... they are okey, the ones who attempt to show resistance shall be eliminated.

Seriously WHY these who are in the core of knowing where we come and where we go should go and find a new place and hope on peoples psychology to fallow them .. no these people who ruin software they will use all the needed politics from other arias of life to recirculate and block enough that goal is not reached.

Protect your ground. All as one organize on your own virtual war base start 24/7 as an team working out on these names and people who need to be excluded from the development, make clean house.. rather less good then few bad.

Seriously, this what is done in plant, politics, education, media, literature and other worlds is not different what happens in computer world, we our-self did not realize the size and importance of the happening for future generations (how many hundreds of years you think ahead...)

Work on fork prototype, work on making self backup virtual world.. from where you might need to remove some of your friends as well... but if they are real friends they will still help and mot attacking you for it. ... but most of all work on exposing these names in that aria who do not need to be in there.. there is so much other all in one solutions they can go and help with ... WHY in there where they not needed as the aim is something else ?

Does it make any sense am talking ?

... this is what they expect from us.. to separate... to separate.. to only retreat.. naah, we lovers, we look big picture and daddy is on our side in the end!

[Rob Gr]

Linux greybeards surely!

After all "Linux Is Not Unix"

[zelea2]

Keep systemd at bay

Just put in /etc/apt/preferences the following:

Package: systemd*

Pin: version *

Pin-Priority: -1

That will keep all systemd and related packages away (for a while at least)

I'm running unstable and had no issues so far.