Is it time to fork Debian?

by
in linux on (#2TFM)
The grumbles over systemd and its ramifications are well known and have even been discussed on Pipedot [links below]. But it's taken on a new urgency. The members of the Debian community are set to vote on an init system, and if by any chance the "give preference to systemd" option wins, this group of angry sysadmins is organized, willing, and prepared to fork Debian. Their argument is measured and calm, but they've got their finger on the trigger. Here is just a portion of their argument.
Who are you?!
We are Veteran Unix Admins and we are concerned about what is happening to Debian GNU/Linux to the point of considering a fork of the project.

And why would you do that?
Some of us are upstream developers, some professional sysadmins: we are all concerned peers interacting with Debian and derivatives on a daily basis.We don't want to be forced to use systemd in substitution to the traditional UNIX sysvinit init, because systemd betrays the UNIX philosophy. We contemplate adopting more recent alternatives to sysvinit, but not those undermining the basic design principles of "do one thing and do it well" with a complex collection of dozens of tightly coupled binaries and opaque logs.

Are there better solutions than forking?
Yes: vote Ian Jackson's proposal to preserve freedom of choice of init systems. Then make sure sysvinit stays the default for now, systemd can be optional. Debian leaders can go on evaluating more init systems, just not impose one that ignores the needs of most of its users.

Why is this happening in your opinion?
The current leadership of the project is heavily influenced by GNOME developers and too much inclined to consider desktop needs as crucial to the project, despite the fact that the majority of Debian users are tech-savvy system administrators.

Can you articulate your critique to systemd?
To paraphrase Eric S. Raymond on the issue, we see systemd being very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term. We like controlling the startup of the system with shell scripts that are readable, because readability grants a certain level of power and consciousness for those among us who are literate, and we believe that centralizing control services, sockets, devices, mounts, etc., all within one daemon is a slap in the face of the UNIX philosophy.
Also see:
Kernel hacker's rant about systemd
Boycott Systemd movement takes shape
Uselessd, an alternative to systemd
Debian to vote on init system again
Reply 49 comments

The Good Fight (Score: 1, Informative)

by Anonymous Coward on 2014-10-19 16:15 (#2TFN)

Thank you for keeping tabs on this, Zafiro. I probably would not otherwise know about it.

It seems like a losing cause as systemd is some kind of brain prion infecting distro devs, but here's hoping for traction.

Good for them (Score: 2, Insightful)

by skarjak@pipedot.org on 2014-10-19 17:13 (#2TFS)

As an arch user, you know what I feel about the "evil" of systemd. :p

Still, it's good that these people are willing to put their money where their mouth is. If you don't like the way things are going, the right thing to do in the FOSS world is to just fork.

Re: Good for them (Score: 2, Informative)

by skarjak@pipedot.org on 2014-10-19 17:52 (#2TFT)

I'd add, though, that the complaint about preferring easily readable shell scripts is not really warranted. It is trivial, in systemd, to set up a service that just executes a bash script. In fact that's one of the first things a tutorial would show you.

Still, if they have a better alternative, they are welcome to work on it and make it available.

Bravo for sysadmins - and pipedot! (Score: 2, Insightful)

by Anonymous Coward on 2014-10-19 18:35 (#2TFV)

Sysadmins take 'WAY too much crap from developers.

Almost every dot-com I have worked at or the past twenty-plus years listened 'WAY too much to developers, and allowed things to be rolled out, that shouldn't have been.

Almost every dot-com I've worked in the past ten years was started up by developers who called me in when things got too complicated for them to administer, and develop code, at the same time.

Almost every dot-com I have communicated with in the past two or three years seems hell-bent upon moving everything into 'The Cloud'. WHICH cloud? That changes about once every eighteen months, it seems.

Recruiters are now looking for these new-fangled 'devops' - these would be software developers, who do hardware operations - or is it hardware operators, who do software development? - to do twice the work, at half the price.

By my count, the average number of programming languages, technologies, vendor product lines, networking protocols, etc that one is now expected to master exceeds that of the average UN polyglot translator by a factor of ten.

It's pretty clear the people making up these job descriptions are only counting the money they will save by hiring one person to do two jobs and have NO CLUE what goes into either software development OR hardware operations.

We sysadmins need to start pushing back more!

And so it's great to see collective some movement against systemd.

Even if I am a BSD guy, at home, I still wrestle with Linux, at work - and so I share all of your concerns.

Re: Bravo for sysadmins - and pipedot! (Score: 2, Insightful)

by scotch@pipedot.org on 2014-10-19 22:27 (#2TG4)

I'm a professional sysadmin on debian boxes starting from potatoes (I started as a developper). I'm now investigating alternatives for all servers my shop manages because I see too many desktop'ish stuff on fresh install done by my coworkers coming to our servers. I cannot stand to have much in pid 1 and need to reboot when some package updates. Our customer are start-up in early stages and most of the time they come to us when they encounter their first hickup somewhere "in the cloud"... Therefore I can just totally agree with your statement! And thank you Zafiro for this news as I don't read google+...

Re: Bravo for sysadmins - and pipedot! (Score: 3, Informative)

by caseih@pipedot.org on 2014-10-21 14:35 (#2TJ7)

Maybe you should read up a bit on systemd before you post this kind of untrue stuff, or maybe run it and see just what it does. Systemd does *not* cram everything in pid 1! To say it does is false, plain and simple. You'd know this if you took some time to examine a system that runs systemd. It also does not require a reboot for most updates to systemd. Everything that can possibly be done outside of pid 1 is done outside of pid 1. If you do an update, the package manager issues systemctl daemon-reexec and all the systemd subsystems restart with the new binaries. If something was changed in pid 1 then, like upstart or system v, a reboot is required. But that just doesn't happen very often. I've installed maybe 2 updates to the systemd packages on RHEL 7, and did not need a reboot.

I don't mind actual arguments being made against systemd, but I rarely find any in these discussions! Just mumblings about philosophy and theoretical problems, completely ignoring the very real and ongoing problems with system v and the like, which are impacting a lot of sysadmins. Which is pretty crazy. We've had maybe a half dozen stories on it in the last month on the other sites, and no one can say anything other than FUD it appears.

I'm not arguing for systemd so much as taking issue with the way people are spreading this sort of misinformation, and taking issue with the idea that system v wasn't broken (it is broken, especially with modern, hot-plugged server hardware).

Re: Bravo for sysadmins - and pipedot! (Score: 1)

by billshooterofbul@pipedot.org on 2014-10-22 17:20 (#2TKA)

Agreed. Too much FUD and two second sound bites. Not enough substantial debate on the merits.

Benefits servers and system admins the most (Score: 2, Informative)

by evilviper@pipedot.org on 2014-10-19 18:38 (#2TFW)

I object to the frequently repeated assertion that system admins don't want systemd, and that it only benefits desktop users.

SysVinit scripts don't have any way to restart services that have quit/crashed. That is EXTREMELY important on servers, and it's absence is a notable missing feature on Linux. There are various add-ons that do this, like daemontools, but they can't replace SysVinit, so you're stuck maintaining two mutually incompatible methods for running services.

I don't care about boot-up times, but not being able to have all system services automatically restarted (without human intervention at 3am), should anything happen to them, is a glaring failure on Linux, putting it a couple decades behind its competitors.

Debugging a system, and/or rebooting it every time it comes up but a network file system didn't mount in-time... Getting paged at 3AM every day, because after 2 years of uptime, crond happened to crash and across hundreds of servers that's a daily occurrence... etc. These are all very important to any server admins, and hardly matter to desktop users.

And to preempt the common responses:

You would NOT want to be paged at 3am just because crond crashed after 2 years of uptime. It's crazy to claim someone needs to investigate every such happenstance. It's also crazy to claim you should rewrite all your startup scripts so every system service is run out of daemontools. After all.. ANY service that you need running is "critical" and failure can't be ignored. Right now, these system restarts are typically performed by poorly-paid NOC personnel, who understand less about the services in question than systemd does. And needing to have NOC folks working around the clock is prohibitive for small shops (who have system admins who would like to sleep through the night) and increases the TCO for large shops, who made need a large number of NOC employees because restarting services becomes a full-time job to the exclusion of other job duties, given enough servers.

Automatic service restarts are perfectly safe. If there was any such issue, it would be looming over daemontools since forever, and the widespread adoption of systemd by every distro out there just serves to show the experts just might know something. Those claiming systemd is bad and useless have to come up with vast conspiracy theories to explain away the enthusiastic and widespread adoption.

I hate to jump into the systemd flame war yet again, where typically the least-informed and least affected shout the loudest. After all, there's no benefit to interrupting the detractors, because every distro out there is already on the side of systemd, and the ranting and moaning on sites like this won't change that.

Re: Benefits servers and system admins the most (Score: 4, Insightful)

by zafiro17@pipedot.org on 2014-10-19 19:56 (#2TFY)

Evilviper, I think you're at risk of treating this as a duopoly, which is not. This isn't an issue of sysV vs. systemd. In fact, from what I'm reading, most people start off their argument by saying "we agree system V init needs to be replaced with something better. But this isn't it." Your criticisms of system v are on the mark, but many people - me included - would argue that systemd solves those problems but gives you a whole bunch of new problems. That uselessd looks pretty interesting, for example. I dunno.

On my desktop systemd is probably not a big issue, and I'd appreciate the faster boot time. On my servers though I want something that resembles system v init scripts. And while I'd like solutions to the weaknesses you describe here accurately, I don't want systemd to be that solution. I think these fork guys are of the same philosophy - they don't want systemd to become an imposed new standard, and to continue looking around while things evolve. Committing to systemd is a big jump it's hard to back out of.

Lastly, when you think about how much work it is to maintain Debian, threatening to fork it is a BIG undertaking: the hardware support, the enormous package repository, etc. That is a huge project and it's the foundation to Ubuntu, which is the foundation to hundreds of other things. What's that Hindu concept of the universe where there are turtles standing on top of monkeys who are on top of alligators ... all the way down to the elephants? This is like changing out the elephants - no simple feat!

Re: Benefits servers and system admins the most (Score: 3, Informative)

by evilviper@pipedot.org on 2014-10-20 00:43 (#2TGA)

This isn't an issue of sysV vs. systemd
No, upstart is in there, too, and that's about all... It got voted down in favor of systemd across the board.
most people start off their argument by saying "we agree system V init needs to be replaced with something better. But this isn't it.
Open source software doesn't start with executives espousing grandiose ideas. Distros choose from what's out there. Somebody needs to churn out some code, and they needed to do it 20 years ago. This has been needed for a long time, and distros can't take a wait-and-see attitude when their big customers needed these features years ago and aren't going to continue waiting.
Committing to systemd is a big jump it's hard to back out of.
Big jumps, that get redone later, are pretty common in Linux. Big initrd changes, devfs to udev, dcop and dbus, oss with esd and arts to alsa and pulse, KMS, lilo grub and grub2, LVM, etc., they're always painful, and often stupid and pointless, but not world-ending.
Lastly, when you think about how much work it is to maintain Debian, threatening to fork it is a BIG undertaking
Actually, it's easy to make the threat. That's the problem with all these discussions... Talk is cheap, and every random misinformed random user can make lots of talk.

Many people are just buying-in to many of the unfounded rumors.

Re: Benefits servers and system admins the most (Score: 0)

by Anonymous Coward on 2014-10-20 20:50 (#2THA)

Forking Debian would be quite a bit of work, I'll have to agree. Easier would be to take the ALREADY supported sysV init packages, along with other compatible packages that Debian has kept around as optional, and roll a forked installer that still provides Debian as maintained by Debian. This seems like it'd be a bit more of a sane way to handle the undertaking, and avoid splitting the labor pool unnecessarily.

Systemd's existence isn't a problem. Poettering's statement of "Linux is still too fragmented...[and] needs to be streamlined..." (Wikipedia reference due to original source being in German) is however a bit of a worrisome attitude, as it seems to have a monoculture for Linux as the aim such a sentiment espouses. That the rollout of systemd has seen established software losing cross compatibility with minimal benefit is also troubling, and appears to be a sharp move in the wrong direction.

When systemd can learn to play better with others, I think you can expect the uproar to die down a bit. Expecting a community made up of people who go out of their way to use a system that has heretofore been one of the least one-size-fits-all in its philosophy to be thrilled by software (however functional for what it aims to do) that breaks that trend is a bit foolish if you ask me.

Seems like a matter of trying to bring in the masses at the expense of alienating one's already established user base. Perhaps we should go ask Slashdot how well that works.

Re: Benefits servers and system admins the most (Score: 1)

by fnj@pipedot.org on 2014-10-21 04:30 (#2THP)

No, upstart is in there, too, and that's about all
Is there some genuine reason for dismissing OpenRC?

Re: Benefits servers and system admins the most (Score: 1)

by evilviper@pipedot.org on 2014-10-21 13:14 (#2TJ0)

Just lumped-in with SysV, as there isn't a lot of difference there.

Re: Benefits servers and system admins the most (Score: 3, Insightful)

by Anonymous Coward on 2014-10-19 20:29 (#2TG1)

SysVinit scripts don't have any way to restart services that have quit/crashed. That is EXTREMELY important on servers, and it's absence is a notable missing feature on Linux.
When a daemon crashes on a production server, we want to know why. We investigate and fix the problem before restarting.
ANY service that you need running is "critical" and failure can't be ignored. Right now, these system restarts are typically performed by poorly-paid NOC personnel, who understand less about the services in question than systemd does
Funny... the only time I ever needed data center staff to intervene was after a botched systemd "upgrade".
Automatic service restarts are perfectly safe
Simple minded nonsense that will be easily countered by the first 0day exploit that takes advantage of it.

Re: Benefits servers and system admins the most (Score: 0)

by Anonymous Coward on 2014-10-19 22:08 (#2TG3)

That's what I was wondering. If a service is restarting itself all the time, how would you know? Oh, by monitoring logs and fixing the problem? How about you do that when it breaks and stops running the first time or two, when you actually notice because you DIDN'T have a Windows style service manager restarting it for you?

Re: Benefits servers and system admins the most (Score: 3, Insightful)

by evilviper@pipedot.org on 2014-10-19 23:24 (#2TG6)

If a service is restarting itself all the time, how would you know?
Because you have monitoring systems in place that report such status information, and because any decent admin will configure a service manager to only restart the process a few times in a short period, before giving-up. "Monitoring logs" is only something you do at home... It doesn't scale. You can't do system monitoring that way.
How about you do that when it breaks and stops running the first time or two
Already addressed this, TWICE, in my post. Look for 'crond'. The most rock-solid stable and reliable service will crash, on occasion, in ways that do not need nor would benefit from investigation. Across many hundreds of servers running numerous services, this is a daily occurrence.

Re: Benefits servers and system admins the most (Score: 0)

by Anonymous Coward on 2014-10-20 15:44 (#2TGZ)

Because you have monitoring systems in place that report such status information, and because any decent admin will configure a service manager to only restart the process a few times in a short period, before giving-up. "Monitoring logs" is only something you do at home... It doesn't scale. You can't do system monitoring that way.
You don't directly monitor logs on production machines past a certain number. Most companies get by with just 2 or 3 email servers and these machines are often monitored manually.
The most rock-solid stable and reliable service will crash, on occasion, in ways that do not need nor would benefit from investigation
Nor from automatic restart since it only happens "on occasion" and anything critical will be monitored. And because we are talking "critical", an administrator will be on call anyway.

Re: Benefits servers and system admins the most (Score: 2, Interesting)

by evilviper@pipedot.org on 2014-10-20 17:44 (#2TH4)

"On occasion" across many hundreds of servers quickly becomes a daily occurance.

Of course I've already said that a dozen times now... Willful obstinance and ignorance doesn't make you look smarter.

Re: Benefits servers and system admins the most (Score: 1, Interesting)

by fnj@pipedot.org on 2014-10-21 04:32 (#2THQ)

And repetition does not magically make an argument persuasive.

Re: Benefits servers and system admins the most (Score: 3, Informative)

by evilviper@pipedot.org on 2014-10-21 13:16 (#2TJ1)

It happens to be a fact, and nobody has even attempted to refute it, so apparently everyone agrees, and just wants to pretend they didn't hear it due to how badly it destroys their world-view.

Re: Benefits servers and system admins the most (Score: -1, Flamebait)

by Anonymous Coward on 2014-10-21 14:29 (#2TJ6)

Great, so let's accept your position that the tiny number of organizations who rely on "hundreds" of like servers and can't be bothered to write their own restart scripts are to benefit from an all-encompassing process controller like systemd.

Okay, so why burden the rest of the world with the same monstrosity when they (a) DON'T need it and (b) might actually prefer to prevent process crashes and maintain their own systems to restart them?

Also, I note that an actual real-live registered user chimed in and you are now powerless to complain about ACs this time. :)

Re: Benefits servers and system admins the most (Score: 2, Interesting)

by caseih@pipedot.org on 2014-10-21 14:51 (#2TJA)

Feel free to continue to use what works for you.

It's not just a tiny number of organizations though. More and more organizations are deploying virtual machines and containers. In a more dynamic server system like this, the old way of doing things shows its limits. I have written my own restart scripts on many occasions, but it sucks and I'm tired of the hacks. Even in a small organization, I've had race conditions with NFS, openldap, and network connectivity stop booting in its tracks on many occasions. I used to change inittab to start a getty right at the beginning of the init process so I could log in and kick things when necessary (requiring physical access to the server, which sucked big time, but virtualized consoles improved that dramatically). So even for small organizations of one or two servers, the init script system does have problems still.

Re: Benefits servers and system admins the most (Score: 2, Insightful)

by evilviper@pipedot.org on 2014-10-19 23:15 (#2TG5)

When a daemon crashes on a production server, we want to know why. We investigate and fix the problem before restarting.
Already addressed this nonsense, TWICE, in my post. Try again.
Funny... the only time I ever needed data center staff to intervene was after a botched systemd "upgrade".
A NOC isn't datacenter staff.

Re: Benefits servers and system admins the most (Score: 0)

by Anonymous Coward on 2014-10-20 00:15 (#2TG7)

No, but a NOC is the sysadmins' software "Hands and Eyes". If they're too stupid to do the work necessary, maybe you should pay them more?

If something is crashing on a production server you have fucked up. The end. Production isn't for testing, it's for stable code. The only exemption is if your production network is *so* big that it allows you to segment parts of it for testing, in which case you're accepting that things might break, so you can't really complain about being woken up at 3am to fix a broken service.

Re: Benefits servers and system admins the most (Score: 3, Insightful)

by evilviper@pipedot.org on 2014-10-20 00:21 (#2TG8)

If something is crashing on a production server you have fucked up
Utter nonsense. You're just a kid with a linux box who has no large-scale experience but wants to pretend to be an expert on the internet. EVERYTHING crashes over a long enough time-frame. The most uber-stable and basic simple system software will eventually crash. Across enough servers, you'll see it happening daily.

Re: Benefits servers and system admins the most (Score: 0)

by Anonymous Coward on 2014-10-20 01:14 (#2TGB)

ep, you do know we're not all the same AC, right?

Re: Benefits servers and system admins the most (Score: 2, Insightful)

by evilviper@pipedot.org on 2014-10-20 01:29 (#2TGC)

I am referring to the claims of that specific AC, yes.

I tend to disregard ACs in general. Back on /. I'd set my preferences to not see their comments unless significantly modded-up, nor ever get notifications about replies from them.

Even a pseudonym keeps people much more honest and polite, and certainly makes for a better community. It's unfortunate that ACs make up such a big proportion of commentators here... People not willing to even minimally stand behind what they say.

Re: Benefits servers and system admins the most (Score: 3, Funny)

by bryan@pipedot.org on 2014-10-20 02:27 (#2TGE)

What?! You mean Evil Viper isn't your real name?!

Re: Benefits servers and system admins the most (Score: 1)

by evilviper@pipedot.org on 2014-10-20 03:32 (#2TGG)

Not terribly happy with the name, but had it forever so I keep using it on /. spin-off sites.

I certainly wouldn't want all my late night (and possibly drunken) rants and shouting matches, or all the times I've played devils advocate in a discussion over the past 20 years, to show up (out of context) in a job interview, ALL needing to be explained. So using a real name on most discussion sites just doesn't work for me.

Re: Benefits servers and system admins the most (Score: 2, Insightful)

by Anonymous Coward on 2014-10-20 08:12 (#2TGM)

So you've nicely explained EXACTLY why some of us choose to be ACs some, or in my case, all the time. Surely you see that? In your case your handle is you online. Establishing a record that can be easily linked back to you through a single slip isn't much better than not using a handle at all. Might as well succumb to Facebook style real names.

Again, I think the ACs here are particularly polite and cogent (or at least the moderation has made it seem that way), whereas I've found the registered posters less so.

Also, for some reason I have thought until just now that your name was "evilPiper" for some reason, which makes even LESS sense than your actual handle that bryan just pointed out. :)

Re: Benefits servers and system admins the most (Score: 1)

by evilviper@pipedot.org on 2014-10-20 13:10 (#2TGP)

Establishing a record that can be easily linked back to you through a single slip isn't much better than not using a handle at all.
You don't need to keep the same one for 20+ years like me, the barrier is quite low. Besides, it's extremely easy not to let personally identifying information slip... Unless you're Hodor.
Again, I think the ACs here are particularly polite and cogent
Ugg... Polite and cogent like him?:

https://pipedot.org/comment/2TD2

I'd go at it from the opposite direction, and say it's rare to see real information or insights from ACs. There isn't a lot of trolling and flaming in general because |. is still a small site. As it gets bigger, I have no doubt the ACs will be just as irritating as on other sites.

Re: Benefits servers and system admins the most (Score: 0)

by Anonymous Coward on 2014-10-20 16:42 (#2TH0)

I guess we're not reading the same site. You found the one really worthless troll post that I can recall seeing here in the last couple of months. And due to the overall low participation many threads consist of half or more ACs, and yet the conversation to my mind has been pretty damn good. (Certainly better than Soylent, which I haven't actually visited in weeks now.) Crank up your settings to make us 0-scorers disappear and tell me just what kind of content is left here.

For the record I've enjoyed talking to you in several threads.

Re: Benefits servers and system admins the most (Score: 3, Interesting)

by skarjak@pipedot.org on 2014-10-20 17:25 (#2TH2)

I'm not sure when it started, but I feel that pipedot comments have gotten more venomous over the past weeks... And I see a lot of ACs replying in a really rude way, who still get modded up somehow.

I don't care how right you may be. You don't have to be an asshole about it.

Re: Benefits servers and system admins the most (Score: 1, Insightful)

by Anonymous Coward on 2014-10-20 14:20 (#2TGW)

Ironically impolite, given your other comments here.

In any case, are you saying that a process should restart whenever it fails, for whatever reason? A server can go down for a lot of reasons, anything from a dead harddrive to a CPU overheating because the heatsink got dirty. Or even more "weird" reasons like cosmic rays, in fact, I bet that a large enough cluster of servers could work reasonably well as a cosmic ray detector, just watch for ECC errors in RAM. If you're getting crashed processes because of hardware errors you can't just restart the process. You need to fix the hardware error, which is probably a long, drawn out process since you need to get someone on site first.

If on the other hand your processes are crashing because of stupid stuff, like you forgot to rotate logs, or you've got a memory leak, or some software-only issue, then you're kind of an idiot for letting that get to a production server.

Re: Benefits servers and system admins the most (Score: 2, Insightful)

by evilviper@pipedot.org on 2014-10-20 14:45 (#2TGY)

Ironically impolite, given your other comments here.
Just calling it like I see it. A spade is still a spade.
If you're getting crashed processes because of hardware errors you can't just restart the process.
A service crashing isn't evidence of a hardware error, and when that does happen, trying to restart it a couple times won't hurt your efforts in any way.

Services will and do crash for no reason... All kinds of strange timing issues will suddenly cause services like crond to just quit after a few hundred days of operation, and continue to work perfectly after being restarted. Go ask someone running a compute cluster how much time they put into investigating every single service crash on their hundreds of thousands of servers...

Re: Benefits servers and system admins the most (Score: 1)

by fnj@pipedot.org on 2014-10-21 04:39 (#2THR)

Services will and do crash for no reason
Appeal to magic? I think if you give the matter even a tiny bit more thought you will agree that it is never "no reason". It may be an extreme low-runner software bug or a hardware glitch, but those are reasons. We may not always be able to figure out the reason, but it is always there. Heck, even an alpha particle in a memory cell is not "no reason:.

Re: Benefits servers and system admins the most (Score: 1, Insightful)

by Anonymous Coward on 2014-10-20 14:14 (#2TGV)

What you do when a service fails usually depends on your setup. If its a single Apache server out of 500 thats behind a loadbalancer that can detect the failure and route around, then yeah let it stay dead. If you only have a single webserver, then yeah save the relevant logs, and auto restart that thing pronto.

I think too many people assume that there setup is the best for every situation when discussing systemd. Well, its not. There are a lot of cases where it makes everything much easier, others where it makes things possible, others where it makes little difference.

Most complainers have setups where it makes little difference.

I think everyone who complains about it should join in with uselessd and see that through. That approach makes sense to me. Forking Debian seems like a waste of time and energy.

Re: Benefits servers and system admins the most (Score: 1)

by evilviper@pipedot.org on 2014-10-20 14:32 (#2TGX)

If its a single Apache server out of 500 thats behind a loadbalancer that can detect the failure and route around, then yeah let it stay dead.
Not actually a good plan... If you have 500 instances of Apache, it's because you NEED 500 instances of Apache, and a couple of them going down is likely to cause measurable slowdowns at peak times. If you have many more servers than you need, you're wasting money to compensate for software limitations.
I think everyone who complains about it should join in with uselessd and see that through. That approach makes sense to me. Forking Debian seems like a waste of time and energy.
I think most everyone can agree on that point.

Re: Benefits servers and system admins the most (Score: 0)

by Anonymous Coward on 2014-10-20 17:35 (#2TH3)

You have 500 servers for the same reason you have raid: Redundancy.

Re: Benefits servers and system admins the most (Score: -1, Troll)

by Anonymous Coward on 2014-10-20 18:05 (#2TH6)

Or because being perfectly matched to your workload would mean 499 servers one day (or hour, or minute), 503 the next, 32 on weekends, etc. It really sounds like this guy is arguing from a position of ignorance, and assuming that a big company with lots of servers has frequent failures that they don't care about.

Re: Benefits servers and system admins the most (Score: 1)

by evilviper@pipedot.org on 2014-10-20 18:15 (#2TH7)

You have 500 servers for the same reason you have raid: Redundancy.
And if you let a few of them stay down for no reason, you've got that much less redundancy.

And when your contract with a big company calls for 30% excess capacity, and those couple servers being down during high traffic happened to let it fall under that level, you get to explain exactly why you don't feel the need to properly monitor and maintaining those servers...

Re: Benefits servers and system admins the most (Score: 1)

by scotch@pipedot.org on 2014-10-21 02:20 (#2THH)

I should say that when a service crash I prefer to have it restarted as soon as possible on another spare server in order to be able to investigate the crash before reusing the server hosting the crashed service.
Therefore, I dunno want systemd.
Boot time are irrelevant as a spare server should always be available and a new spare provisionned as soon as the one is used. (hopefully the crashed machine can be bringed back as spare).

Re: Benefits servers and system admins the most (Score: 2, Insightful)

by bryan@pipedot.org on 2014-10-20 02:22 (#2TGD)

Some daemons are built to recover from crashes and restart their own worker processes. For example, Apache's main pid is mainly in charge of spawning new child processes to do the actual work. The children can even be configured to terminate themselves after serving X number of requests.

However, some daemons, such as mysql end up relying on a shell script to do this task. I've always thought of the mysqld_safe script as being an ugly hack. Wouldn't a real program be a better fit for this? And if you make a generic enough service monitor, couldn't you use it for more than just one program?

The traditional inetd process is another example. The post-fork method of operation is just too slow for modern tasks such as web page serving. But systemd does have some interesting ideas on how to fix it.

May the Gods save us from systemd (Score: 4, Insightful)

by bsdguy@pipedot.org on 2014-10-20 05:02 (#2TGJ)

I started out in Unix in the very early 1980s. I was drawn to it because of the toolbox approach and the readability of the configs and startup scripts. I started with BSD 4.2 on PDP 11s, then dualport OSX from Pyramid, followed by some Xenix and Suns running SunOS 3.x (BSD based). Over the years I have worked with pretty much every flavor of Unix, BSD, or GNU/Linux you can think of. Most of them were simple to deal with when moving from one to the other because the configs and startups were readable by anyone with even moderate skill in the art. I could teach a newbie how to understand the startup system and troubleshoot startup problems in very short order.

At some point commercial Unix vendors decided to "make things easier" and we started to get things like SCO Unix overwriting startup files and configs from it's GUI admin tool. It stored stuff in a private DB and just over wrote changes put in files by hand. NOT GOOD. Then of course with Solaris 10, which brought us the great ZFS, Sun decided to go to a monolithic startup database, which if corrupt means the system will not boot. Other commercial vendors have done similar stupid things over the last 10 years.

I think if the Debian core team wants to go against 30+ years of good solid proven engineering then they need to find a surgeon to give them a Rectal craniotomy.

If non-systems administrators can not figure out how to administer a system who the hell cares? Every time I have been called in by startups where the programmers tried to develop code and figure out system administration as well as design how the programs interact with the system it has been a total FUBAR.

The problem these days is everyone who has walked past a computer thinks they are a systems administrator or systems engineer, and vendors as well as, it appears, Team Debian , are feeding that fantasy and in the process destroying the versatility, agility, and maintainability of current POSIX systems. It is exactly this kind of stupidity that makes it more difficult all the time to properly administer systems as well as move between POSIX systems from different vendors.

JUST SAY NO TO FORCED INIT SYSTEM CHANGES.

Re: May the Gods save us from systemd (Score: 2, Insightful)

by fnj@pipedot.org on 2014-10-21 04:44 (#2THS)

Strongly agree.

It happens to civilizations and countries and corporations, and it can happen to linux distros too. It's perfectly possible for them to get corrupted from the inside. Humans are at the controls, and no humans are perfect.

I would welcome a fork (Score: 4, Insightful)

by engblom@pipedot.org on 2014-10-20 06:55 (#2TGK)

I really hate what has happened with Linux the latest decenium.

The truth is that we had a more functional desktop in the days of kernel 2.4. During that time even kernel versions meant stable and uneven meant development kernels. With 2.6 Linus broke this scheme as he considered it to slow down the development. We had really many broken kernels. Picking a working kernel was like a gamble. The latest years however he has managed to get some kind of stability back. Just when other things are beginning to get messed up in the whole community.

Then came the whole KDE messing with KDE4. And for those prefering a full blown DE, KDE3 was the only serious option. GNOME was not having enough of features and it was slow. Opening one folder full of pictures caused GNOME to crawl. KDE had a thumbnail cache and behaved a lot better. GNOME crashed often and had all kind of strange bugs.

Also, while most cherish the xorg fork from xf86, I am not happy with it. We had working graphics for many years. Sure the development was very slow comparing to what it is now for xorg, but it was stable. Now many times I have to fight quite a bit to get the graphics to work on even standard computers.

Slowly GNOME became quite useable. Then it was time to mess up that one too in the worst way splitting the already splitted Linux community even more. Now we have GNOME3, Cinnamon, Mate and many other DEs.

Then also came the Pulse audio change. Suddenly, having a working sound system was nothing to take for granted. Still, even today adjusting microphones, selecting recording sources and other settings are non-trivial. All this worked a decade ago. Meanwhile the BSDs never did the OSS->ALSA->Pulse conversion. They continued to develop on OSS and now OSS is able to play from multiple sources and everything works as it should.

Granted SystemV is not perfect. I have seen nasty race conditions with SystemV but I seldom have seen a system having trouble to get to a working condition. Now when systemd got introduced things began to break and things are more difficult to debug.

I hope they fork and bring back some sanity. Do as the BSDs did with OSS: Improving on what you have rather than throwing out and beginning from scratch. Do we want many years of experimentation with the init system rather than improving what we have in a stable pace?

How to avoid systemd (Score: 2, Interesting)

by zafiro17@pipedot.org on 2014-10-21 16:50 (#2TJH)

Interesting post here:
http://www.vitavonni.de/blog/201410/2014102101-avoiding-systemd.html

Guy makes a couple of good points. Here are two clips:
Avoiding systemd isn't hard

Don't listen to trolls. They lie.
Debian was and continues to be about choice. Previously, you could configure Debian to use other init systems, and you can continue to do so in the future.
In fact, with wheezy, sysvinit was essential. In the words of trolls, Debian "forced" you to install SysV init!
With jessie, it will become easier to choose the init system, because neither init system is essential now. Instead, there is an essential meta-package "init", which requires you to install one of systemd-sysv | sysvinit-core | upstart. In other words, you have more choice than ever before.
Again: don't listen to trolls.
He goes on to point out, however, that you will get systemd installed if you use the gdm Gnome login manager or any part of the Gnome desktop, so for the moment, not only is systemd optional, but you can avoid it if you also avoid Gnome.
On a server, there shouldn't be any component actually depending on systemd at all. systemd is mostly a GNOME-desktop thing as of now.
As you can see, the trolls are totally blaming the wrong people, for the wrong reasons... and in fact, the trolls make up false claims (as a fact, systemd-shim was updated on Oct 14). Stop listening to trolls, please.
If you find a bug - a package that needlessly depends on systemd, or a good way to remove some dependency e.g. via dynamic linking, please contribute a patch upstream and file a bug. Solve problems at the package/bug level, instead of wasting time doing hate speeches.

Re: How to avoid systemd (Score: 0)

by Anonymous Coward on 2014-10-21 20:35 (#2TJW)

Repeatedly using a label tends to (a) diminish the impact of the label and (b) diminish your own argument. All I read there was "trolls, trolls, trolls, trolls". I get it, he thinks those against systemd on principle have their allegiances and logic misplaced. Terrible way to tell it though.