Devuan's Systemd-Free Linux Hits Beta 2 (theregister.co.uk)

Long-time Slashdot reader Billly Gates writes, "For all the systemd haters who want a modern distro feel free to rejoice. The Debian fork called Devuan is almost done, completing a daunting task of stripping systemd dependencies from Debian." From The Register: Devuan came about after some users felt [Debian] had become too desktop-friendly. The change the greybeards objected to most was the decision to replace sysvinit init with systemd, a move felt to betray core Unix principles of user choice and keeping bloat to a bare minimum. Supporters of init freedom also dispute assertions that systemd is in all ways superior to sysvinit init, arguing that Debian ignored viable alternatives like sinit, openrc, runit, s6 and shepherd. All are therefore included in Devuan.
Devuan.org now features an "init freedom" logo with the tagline, "watching your first step. Their home page now links to the download site for Devuan Jessie 1.0 Beta2, promising an OS that "avoids entanglement".

Comments

Init alternatives

[ArmoredDragon]

Do any of these alternatives offer the same speed benefit of systemd? Serious question as I've never tried to replace the init system on any linux distro.

Re:Init alternatives

[drinkypoo]

Do any of these alternatives offer the same speed benefit of systemd?

No, your system might boot two, or even three seconds slower than with systemd.

Re:Init alternatives

[Anonymous Coward]

And your non-systemd boot process will also be comprehensible and easy to troubleshoot.

Re:Init alternatives

[Anonymous Coward]

Do any of these alternatives offer the same speed benefit of systemd?

No, your system might boot two, or even three seconds slower than with systemd.

Actually, that's not necessarily true. I don't know if Devuan supports it, but OpenRC is an alternative init system that started with Gentoo (pre-systemd), but is now also available in other distros. It is written in C, and supports parallel startup processes, but it is *just* an init system, and sysvinit-style bash startup scripts need only very minimal modification to work with it. (You don't determine a fixed load order; you specify "depends" and "provides", which OpenRC uses to decide on a load order and parallel startup.)

Re:Init alternatives

[Anonymous Coward]

No, your system might boot two, or even three seconds slower than with systemd.

I find my system boots infinitely faster without Pottering because craptonne.d gets its shit all twisted more often than not and then sits there for some arbitrary and hard-coded length of time before retrying the operation that failed in the first place.

But hey, what do I know about the benefits of systemd? I only use my Linux machines to get real work done and not for inflating my ego.

Re:Init alternatives

[Sarten-X]

I'm not sure if that's a serious question or an attempt to troll, but regardless...

Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?

In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.

Re:Init alternatives

[Sarten-X]

Since my day job involves comprehending and troubleshooting init scripts, I'm going to assume that's sarcasm.

There are some good non-systemd boot processes, with nice clean service definitions... there have to be... please tell me there are...

Re:Init alternatives

[ArmoredDragon]

Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?

Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.

In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.

I personally don't have a problem with systemd. The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place. And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case? Furthermore, with the way I hack my Android smartphone, I'd love it if it booted faster.

Re:Init alternatives

[drinkypoo]

The truth is that the boot speed improvements of systemd are effectively notional. The boot process is so fast now that starting in parallel only saves you time when something goes wrong. If you regularly have a problem during boot, then you should think about fixing that regardless of what your init system is.

Re:Init alternatives

[I4ko]

Are you seriously asking such a deranged question or just trolling? We don't live in the 90s any more.

There is no reason, even with the price of electricity in Europe to shut your computer down, hence boot time is moot. And considering since 2005 or the whereabouts most people are on laptops, and it is relatively not so hard to find one with a working ACPI, hibernation to disk is what people do. Actual startup should only be performed after kernel patching (and not in all cases necessary) or hardware changes. Which is about 2-3 times a year at most.

Re:Init alternatives

[Anonymous Coward]

There are some good non-systemd boot processes, with nice clean service definitions...

Agreed. There are plenty of them.

Re:Init alternatives

[Anonymous Coward]

Well, on my systems, runit boots faster than systemd, and does not run into those corner cases systemd encounter that cause it to hang forever ;)

Re:Init alternatives

[Sarten-X]

Well, on my home rolled NAS appliance, I really like the ability to reboot all of my VMs very quickly when applying security updates, because I'm not the only one that uses it.

A fair point.

The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place.

Typically sysvinit or mostly-compatible equvalents. From my perspective, they don't want to learn something new, and they don't see the existing system as broken.

And why are some people going to go out of their way to say "you don't need a faster boot time" when they don't know my use case?

The obligatory XKCD applies. Most boot processes are fast enough now that it's not really worthwhile for an end user to shave a few seconds off the time. On the other hand, doing something as a hobbyist is entirely about wasting time, so I won't hold that against you.

The biggest improvement over antique boot systems is going to parallel boot chains. Rather than running scripts one at a time, in order, a tree is built to determine what services are dependent on what other services. For example, it doesn't make sense to start the SSH server until the network is live. There are several init systems that do this, differing mostly in how they define dependencies. Some rely on specific services ("openssh-server relies on network") while others work on more generic capabilities ("remote-shell relies on network, and openssh-server is what we'll use for remote-shell").

After parallelism, it gets tricky and subtle. Maybe we don't need all of a service to start before its dependencies. For example, we don't necessarily need all of our DHCP leases assigned before we know which network interfaces are connected. That requires a more granular service definition, but provides a lot more power, especially for systems with very complicated startup procedures. With that power, we can shave a few more seconds off the boot time, because we aren't required to wait while services settle, improving our overall parallelism. That's useful for me (professionally, I build systems that boot with a strict time limit, and may reboot every few hours), but most folks don't really benefit with the added complexity.

Furthermore, with the way I hack my Android smartphone, I'd love it if it booted faster.

I don't know much about Android init, but I think it uses its own system unrelated to systemd, sysvinit, or any of the alternatives listed in TFS.

Re:Init alternatives

[Sarten-X]

With all due respect, that comparison is awful.

In the effort to make an "apples to apples" comparison, it uses only the bare minimum of functionality from each toolset. There's no illustration of dependencies or capability control. It is useful for getting a rough idea of how the init systems' config files look, but not really as the basis for any kind of comparison, especially with regard to advanced features.

Re:Init alternatives

[Billly Gates]

I'm not sure if that's a serious question or an attempt to troll, but regardless...

Speed is not why you should want (or not) systemd. It's Linux. How often do you expect to reboot the thing, anyway?

In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies". To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving. In my opinion, them, I don't really see the point in changing one's distro (including support lifecycles, development trust, and organization philosophy) just to swap out init. It's just not that big a deal.

It most certainly is if you manage servers!

Most performance evaluations include an uptime requirement. Most businesses it is 99.97% uptime while some Slashdot readers it might be as high as 99.99% or 99.9999% if they work at Amazon or a Wall Street trading firm where any downtime costs millions a minute.

If servers randomly do things behind your back or you restart one during a standard change and it doesn't come back up and your change window is between 1am - 3am (like my employer) you can be in hot water if you can't get it back up if something weird happens during a patch or other activity. SystemD's benefit is it's downfall which is that is event driven. Let's say theoretically you can have SystemD launch tasks or do something in the event your network is hacked or if one of the NIC teaming cards fail. That sounds cool. Problem is if it fails and does something that crashes it.

I am learning FreeBSD now more after I stopped touching it in awhile. Sometimes boring but predictable non event oriented boot only procedures are bah but predictable and nice. You know what you are going to get. It's in that ugly RC script hack but hey you can debug it!

Re:Init alternatives

[Anonymous Coward]

There's no illustration of dependencies or capability control.

Well, you need no more than a dependency file for dependencies, and chainloading for capability control (including cgroup support):

#/bin/sh -e
exec \
s6-softlimit -c 10000000 -p 100 \
your_prog your_args ...

Re:Init alternatives

[Sarten-X]

It sounds like you should be looking into your high-availability architecture, not your init system.

Re:Init alternatives

[Anonymous Coward]

> just to swap out init.

That's not what you're doing when using or not using systemd.
The init becomes another systemd dependency and all interactions with services go through systemd (to the same extent they do with the Windows Task Manager), but you already knew that:

> "Since my day job involves comprehending and troubleshooting init scripts" ....you sucking at your job probably has a lot to do with why you don't understand the problems with systemd and how it hobbles your mediocre talent.

Re:Init alternatives

[cfalcon]

This makes a lot of assumptions. You sound like you are talking about a pizzabox server in a rack. My home box gets rebooted whenever I update, which is every couple months, and it also gets rebooted if it gets dicked up, which is about every few weeks, and almost always related to some game that hates my video driver. It also gets turned off if I go on travel. Sometimes I turn it off to save power (especially during the summer, when running a heater in an air conditioned home just bothers me). And what if I lose power? I have a UPS, but I lose all home power at least four times a year, which is shitty, but hey, what are you gonna do? Replace the one bad transformer? I'm sure there's a few more years in it, and where would the repair dudes hang out if not for their seasonal meet-and-greet green box?

I think boot time is worth being concerned about on a main rig. It's definitely worth being concerned about on a laptop. Maybe you have the one laptop that always and without fail restores from hibernate, but I'd call coming up from hibernate about a 90% success rate, and sometimes you need that to happen faster. Plus, since this is a conversation about Linux, it should be pointed out that Linux's support for hibernate and suspend is all over the fucking map still- if you have a mainstream distro on a top tier lappie, sure, it's perfect. If you have something, uh, vintage, maybe not.

Re:Init alternatives

[Sarten-X]

So let me get this straight... in order to say "Foo depends on some kind of bar, which happens to be baz on this system", I need to write a "bar" definition that actually runs "baz", and go modify a completely separate dependency file to add "foo".

...and you're suggesting this is clean?

Re:Init alternatives

[Rhapsody Scarlet]

I don't know if Devuan supports it, but OpenRC is an alternative init system...

...viable alternatives like sinit, openrc , runit, s6 and shepherd. All are therefore included in Devuan.

Not to be a dick, but the answer is right there in the description. You could take just a few more seconds before rushing to reply.

Re:Init alternatives

[fnj]

[OpenRC] supports parallel startup processes

Except for one little problem. Gentoo Bug 391945: "boot can hang when rc_parallel=yes".

Reported 2009. Current status 5 years later: "CONFIRMED".

Re:Init alternatives

[fnj]

In the spirit of "Do one thing and do it well", systemd's goal ...

BWAHAHA!

Re:Init alternatives

[fnj]

There is no reason, even with the price of electricity in Europe to shut your computer down

I'd say security-patching the kernel is a pretty goddam good reason.

Re:Init alternatives

[phantomfive]

I think if it were just an init system, most people would be ok with it (or gripe a little and then move on, like with other alternative init systems that have existed in the past).

The major issue people are concerned about is that things will be built on top of systemd (and they have been built on top of systemd), and then you have a huge unrelated dependency on this init system which makes it hard to swap out in the future if you want to use containers.

Re:Init alternatives

[Anonymous Coward]

The correct way is create services foo, baz and a bundle bar, and then

$ echo baz >> bar/dependencies
$ echo bar >> foo/dependencies

You need to read the page more patiently. It's not the never-ending systemd documentation, and does not require much time to read in its entirety ;)

Re:Init alternatives

[johannesg]

How come there is so much noise and heat about a small piece of software that runs maybe 2-3 times per year?

All of this is anger, just to be angry. It serves no purpose other than giving you that heady rush of Socially Justified Rage. And as the great master said, it only leads to suffering...

Re: Init alternatives

[Anonymous Coward]

hardware wise to a point you wont notice a diff with either init.

Re:Init alternatives

[gweihir]

What "speed benefit"?

Re:Init alternatives

[gweihir]

Ok, that may waste time. Everybody knows that reinstalling is the way to go on boot-problems, right?

Re:Init alternatives

[Hognoxious]

it is *just* an init system

Goog. An init system shouldn't be a music player, ftp server & toaster.

Re:Init alternatives

[Threni]

> In the spirit of "Do one thing and do it well",

That's generally a good idea but it's wise to consider whether sometimes a better solution is arrived at via integration of multiple pieces of functionality. One of the things I've really enjoyed lately is neovim. It's essentially vim, but amongst the improvements is a built in terminal. Why not use vim (or neovim) and tmux? Because having the terminal built in is just better, that's why. No need to install and configure the apps separately, and when you're using neovim on multiple platforms, that saves me time.

It has to be said that most major distros are using systemd. If you want to use this one, better hope it's supported for the lifetime of whatever project you're using it for.

Re:Init alternatives

[donaldm]

If servers randomly do things behind your back or you restart one during a standard change and it doesn't come back up and your change window is between 1am - 3am (like my employer) you can be in hot water if you can't get it back up if something weird happens during a patch or other activity.

I would assume you would have raised a change request and had it signed by all parties before you even considered applying a change and/or rebooting a system?

In the case of a critical or even minor changes to any production machine an IT professional must consider the following:

1) Is this change a recommended one from the operating and/or application system vendor?
2) Has this change been tested and if so where and what was it tested on?
3) What is the projected time frame to make the change and if required reboot the system?
4) What are the pros and cons of this change?
5) What are the rollback procedures in case of unforeseen issues?

I could go on but by now you should realize that you are also protecting yourself in case the unforeseen happens. Making a change before getting permission is really asking to get fired.

What I have said does not apply to personal machines and if you have a problem with any changes that you have made then it is entirely your fault and you should do something about it. Whinging ain't going to cut it.

BTW. When I say a production machine I mean any computer that could result in loss of revenue in the case of extended downtime and this can include development as well as testing machines.

Re:Init alternatives

[donaldm]

The major issue people are concerned about is that things will be built on top of systemd (and they have been built on top of systemd), and then you have a huge unrelated dependency on this init system which makes it hard to swap out in the future if you want to use containers.

I have been running Fedora before systemd (2010) was introduced and have never had an issue with it. I am now running Fedora 25 without any issues. Since my OS is on an SSD I can power up then login in then start my applications within less than one minute.

Just for you I started up my systemd configuration GUI and you can for "Units" and "User Units" see the following "Load State", "Active State", "Unit State" and "Unit". If I want I can "stat", "stop", "restart" and "reload" a unit as well as being able to "edit" and "isolate" a unit. There are plenty of other options available for you but I would suggest reading up on them.

Basically screwing up in systemd is pretty much the same as screwing up in an init system and instead of whinging about it, fix it.

Re: Init alternatives

[Anonymous Coward]

I'm with you on almost all points but let's be fair, the vast majority of Linux system admins suck at their jobs and make changes until things appear to work. Says unit is by far friendlier to hack and slash says admins. I work primarily in the Cisco world and have spent thousands of hours making powershell desired state configuration scripts for Cisco hardware because I want structure in my environment. I am beginning to do the same with Linux systemd. I also have a huge number of unit tests and have built a huge unit test framework for end to end system administration. Systemd let's me have a single API for managing all phases of Linux boot and writing unit tests. Says unit is a drifting disaster.

Re:Init alternatives

[thegarbz]

And your non-systemd boot process will also be comprehensible and easy to troubleshoot.

+5 Funny. Now if you'll excuse me I have to go back through hundreds of log files and filter through init scripts with 1000s of lines to find out why something's not working.

Re:Init alternatives

[Anonymous Coward]

Sure, there may be copious logs that require filtering, *but at least the information is there* to find eventually. With systemd, there is no guarantee your diagnostic log message even exists.

Re:Init alternatives

[Anonymous Coward]

The initial improvement in boot speed seems to have been removed in my more recent tests. I'd suggest you do a side by side comparison before believing systemd offers that any more.

Re:Init alternatives

[Anonymous Coward]

Except that in reality there is no log of early boot messages with sysvinit. So the information to find issues is actually not there.

So with sysvinit, there is a *guarantee* that the diagnostic log messages do *not* exist. On the other hand, systemd logs these as well: this makes debugging boot failures way easier.

Re:Init alternatives

[Anonymous Coward]

Use bootchart2 to know whats going on. The speed usually comes down to what your starting and the order you start it. The advantage of knowing this far out ways the alleged speed increases of doing it another way.

Re:Init alternatives

[ruir]

With live kernel patching, not for long.

Re:Init alternatives

[Anonymous Coward]

There is no reason, even with the price of electricity in Europe to shut your computer down

I shut computers down when they are not being used not because I can't afford to pay for the electricity but because I don't want to waste it.

Re: Init alternatives

[Anonymous Coward]

Meh, ksplice or kernelcare, no reboots. job done.

Re:Init alternatives

[Anonymous Coward]

The fact you don't have issues (which isn't a surprise if you're using a mostly unaltered fedora) doesn't mean there aren't issues.

Re:Init alternatives

[Anonymous Coward]

A lot of SystemD's benefits come from being able to start VMs very quickly.

If you're a cloud provider that's very important.

I'm not defending SystemD because, frankly, I'm not qualified, but many of the whiners seem to be complaining that they might have to learn something new.

Re:Init alternatives

[Anonymous Coward]

There is no reason, even with the price of electricity in Europe to shut your computer down, hence boot time is moot.

Great way to deal with issues: just pretend it is not something useful to do and one should just waste energy instead of improving the system.

But hey, some of use do care about improving things ;)

Re:Init alternatives

[Anonymous Coward]

How come there is so much noise and heat about a small piece of software that runs maybe 2-3 times per year?

Point is, it is neither small nor it runs only 2 to 3 times a years. It's starting to be a giant squid of interdependant parts (gnome depends on systemd now) that runs constantly (the init is always running, not just at boot), that is basically a kernel on top of the kernel, trying to control everything in userspace and "be the glu" between everything, and from which most people can't run from.

Re:Init alternatives

[Anonymous Coward]

But hey, what do I know about the benefits of systemd?

Not much, apparently.

I only use my Linux machines to get real work done and not for inflating my ego.

And yet here you are, inflating your ego.

At least you are entertaining.

Re:Init alternatives

[Barsteward]

There is tons more information in the journal and a lot less work to search it

Re:Init alternatives

[Anonymous Coward]

"Do one thing and do it well", systemd

Ha. haha, hhahhhahhhh

Re:Init alternatives

[Barsteward]

Only 3 dependencies. The fact that gnome depends on systemd is the gnome devs fault, its the choice they made. There were other options, including a bypass written by LP for them, but they chose actively maintained systemd-logind over the un-maintained consolekit.

Re:Init alternatives

[Anonymous Coward]

It was reported 2011, and marked CONFIRMED a day later.
Your point still stands but I assume Gentoo has higher priorities. IMHO, saving 3 seconds on boot is not a pragmatic investment of time.

Re:Init alternatives

[Anonymous Coward]

This is actually a bit misleading. Comparing just the init-intrinsic parts per se, yes, systemd is faster than sysvinit. However, in practice, in a modern distro that loads up a gazillion of systemd unit files, and being mostly dbus based, so it loads up logind, sessions and whatnots to get going, the whole process is at the end much slower.

And when you hit occasional hiccup where it THINKS there's something wrong with something, it literally sits there for 90 seconds with a count down retrying that one thing...

So, no.

Re:Init alternatives

[Anonymous Coward]

LOL! With the current security landscape of Linux (the kernel), it's more like 2-3 times a month....

Captcha: errors. QED! :)

Re:Init alternatives

[Anonymous Coward]

Boot _can_ hang, yeah. systemd does the very same thing, except that it restarts things that it "thinks" have hung the boot. This gets _really_ fun sometimes.

Re:Init alternatives

[Anonymous Coward]

I shut down my computer every day in the evening and start it up every day in the morning. It seemed to work fine for me so far but apparently I'm doing it wrong, and would like to apologize for this. Sorry!

Re:Init alternatives

[pz]

The biggest improvement over antique boot systems ...

That there is the heart of the problem, an attitude that anything old is necessarily bad. That your otherwise calm and reasoned presentation allowed this pejorative to slip in belies the psychological bias that underlies the wide arguments on the subject.

Lest we forget, Linux as a whole turned 25 recently. That's antique. Are you giving up the entirety because it's old? Your favorite editor is probably (just based on popularity) is either emacs or vi / vim. They are very, very old (heck, I've been using emacs since the early 1980s!). Are you dumping them because they are old? I hope you see why calling something "antique" is ill-conceived.

Now to make sure that my point is being made clear, allow me to be explicit: old does not necessarily mean bad, but it does not necessarily mean good, either. Things that are old now were once shiny and new, and weren't necessarily an improvement when they were introduced. But change merely for the sake of change -- which seems to be what was behind debacles in KDE, Gnome, systemd, and Wayland to name a handful -- is wasted effort. For systemd in particular, the primary argument for using it seems to be parallel init, something that as many others have pointed out really isn't much of an issue these days since (a) Linux is generally stable enough that reboots are rare (although there are specific use-cases that benefit, like demand-based VM creation), and (b) computers have become generally fast enough that reboots are inherently speedy.

Re:Init alternatives

[Anonymous Coward]

Gnome and systemd are controlled by RedHat, making Gnome depend on systemd is just a way to impose systemd on distros.

Re: Init alternatives

[Anonymous Coward]

No it's not. If you boot from an SSD, then reading from disk is not the bottleneck anymore, and you do get a factor 3-4x speedup of the boot process.

Re:Init alternatives

[Antique Geekmeister]

> To that end, the only real interaction you normally have with systemd is to start or stop a service, and view the associated logs if some service is misbehaving.

Systemd has also taken over network configuration with an unnecessary DHCP service, which it should _not_ have touched, automounting, and is now attempting to manage user processes with misfeatures that kill user processes silently, such as the default enabled "KillUserProcess" command. Please be clear that systemd is not attempting to _manage_ processes. It is attempting to directly manage almost _all_ system services, many of them by direct replacement with dangerously incompatible and modified systems.

Re:Init alternatives

[Antique Geekmeister]

> There is no reason, even with the price of electricity in Europe to shut your computer down, hence boot time is moot

There is with Virtual Machines. You pay for uptime, a reboot is often necessary to add more storage or memory successfully to an existing VM, and even for local development VM's they take significant server RAM for their active kernels. For many VM's, proper nightly backup snapshotting also requires a short shutdown. Also, after activation of new services, it's often useful to reboot the system to ensure complete activation of services when and if they *are* rebooted unattended.

Re:Init alternatives

[Anonymous Coward]

Yes, I'm sure grep makes that take a real long time.

Re:Init alternatives

[Anonymous Coward]

what do you mean systemd spend years doing it and wrecking everything in it's path to shave some of that time!

Re:Init alternatives

[flyingfsck]

In my experience, Slackware is a lot (very noticeably) faster than Fedora on the same HW. I don't know whether it is due to systemd or SELinux or something else entirely, but if you need raw speed, then you seriously should consider going back to basics.

Re: Init alternatives

[Anonymous Coward]

Your argument does not hold water: sysv-rc init and sysv-rc have not evolved with the times at all. Underneath it the Linux kernel has changed from a very static set hardware configuration to something that is entirely dynamic.

Linux did change a lot in the last 25 years. The only constant is the name.

Re:Init alternatives

[Anonymous Coward]

On the systems I use systemd is actually slower at booting that init. It's pretty close though, only a few seconds here or there.

systemd sucks ass when you need to adjust things though and adds a lot of cruft to something that was already prone to cruft.

Re:Init alternatives

[flyingfsck]

"Any program grows until it can send email" - Ancient American Proverb, circa 1980. So systemd clearly still has a ways to grow.

Re:Init alternatives

[FrankHaynes]

Corner cases such as...??

Re:Init alternatives

[Anonymous Coward]

Systemd has no such purpose, it actually have several purposes:

1. Inflate Potterings already overbearing ego
2. Turning Linux into an opaque mess just like Windows because
   1. Pottering grew up with Windows and just doesn't know better
   2. and/or because Redhat wants Linux to be like that so they can sell more support.
3. Create an evermoving target nobody else really can keep up with, thereby making.
4. Thereby make Redhat Linux something completely different from "standard" Linux.
5. Enable Redhat to make more money via training and "certifications" through all this.

Re: Init alternatives

[Zero__Kelvin]

Where did you get such a ridiculous idea?

Re: Init alternatives

[Zero__Kelvin]

That is what is known in this context as a distinction without a difference.

Re: Init alternatives

[Zero__Kelvin]

You are lost in Microsoft land. You don't reboot after applying updates unless they are kernel updates.

Re:Init alternatives

[Sarten-X]

You're reading far too much into one word. You should try reading the rest of that paragraph.

The first init systems were damned little more than just a shell. After that, we moved to running a single script at startup, and eventually went to runlevels with some common conventions. That's where development stagnated for a decade or two, and that's where I'm drawing my "antique" line. At the time, systems couldn't handle multitasking very well (mostly in terms of race conditions and programmers' sanity), and the massive university systems didn't really need to boot quickly, either, so there wasn't much development in parallel initialization.

Since then, Linux has been created and moved to the desktop, and we have a whole slew of new init systems, most of which natively support modern perceptions of parallelism, security, configuration, hardware, and other new developments since their predecessors moved out of the design phase. It isn't so much that "old is bad" as that the new is more likely to have been designed with modern paradigms in mind. Despite your dismissal, parallelism in particular is important, especially as Linux has taken a role as the embedded OS of choice for smart devices and cheap laptops.

While "change for the sake of change" may be wasted effort, it must be compared against the effort of keeping the old system. For example, how much effort is required of a distro maintainer to write and maintain init scripts for all their packages, including functionality for checking that dependencies started correctly and that scripts follow current best practices? How much effort is required to even make sure that the scripts are numbered in order to start correctly? In an age where building a dependency tree is only a few milliseconds of work, I would say it is wasted effort to make a sysadmin figure it out.

On the side of systemd proponents, I don't think the argument has ever been that "old means bad". Rather, the argument has been that we've learned a few lessons over the past thirty years, and we ought to put those lessons into our software.

Re: Init alternatives

[Zero__Kelvin]

If you are not using clustering so that the downtime of a single server is completely insignificant/irrelevant don't come here and pretend to be a big time player.

Re: Init alternatives

[Zero__Kelvin]

If you do a complete shutdown rather than sleep or hibernate then yes, yes indeed, you are in fact doing it wrong.

Re: Init alternatives

[ArmoredDragon]

You are lost in Microsoft land. You don't reboot after applying updates unless they are kernel updates.

If I shell in and the Ubuntu login banner says "system restart required", then what do you suppose I do?

(yes, automatic security updates are enabled)

Re: Init alternatives

[Zero__Kelvin]

I suggest that you reboot, but with the understanding that the reboot is not required because there were security updates, but for a different reason.

Re:Init alternatives

[Anonymous Coward]

Do any of these alternatives offer the same speed benefit of systemd?

No, your system might boot two, or even three seconds slower than with systemd.

Pfft, that's such a waste of time... I'll take the temperamental version to shave a few seconds off every month I reboot and then steal a few hours of my life in debugging one day when it doesn't quite boot properly.

Re: Init alternatives

[Anonymous Coward]

I do not think there are enough resources to support any init system in devuan, let alone several.

Re:Init alternatives

[Ol Olsoc]

Do any of these alternatives offer the same speed benefit of systemd?

No, your system might boot two, or even three seconds slower than with systemd.

As well, the people who want to whine about systmed want to be able to whine about systemd. There are other distros before this one that were free of systemd. They didn't stop the whining. Because the whining, the line in the sand, and the declared target was systemd.

Re:Init alternatives

[FrankHaynes]

The FreeSWITCH bunch have a useful saying: "Don't glue the Lego pieces together".

A modular system is best enjoyed as a modular system. This is one of the most powerful things about unix systems, you can pipe the output of cat to the input of sed and feed that to a text file for editing by vi.

I don't have a dog in this systemd fight, and I agree with another poster who thinks this is much drama over not much. It is a sea change in how to think about things, but I certainly do not miss hunting down a missing sysvinit script and slogging through it to see why it doesn't work because of one silly line in it. Building a unit file is child's play by comparison. As long as the damned thing works I'm fine with it.

Re:Init alternatives

[angel'o'sphere]

Bad comparison.
Apples don't use systemd. Neither on the BSD nor on the BootCamp Site ...

yeah ... just kidding.

Re: Init alternatives

[angel'o'sphere]

You obviously log off immediately!

Man, that was easy!

Re:Init alternatives

[Anonymous Coward]

In the spirit of "Do one thing and do it well", systemd's goal ...

BWAHAHA!

You just don't understand the one thing that systemd is aspiring to do: replace.

Re:Init alternatives

[dbIII]

Since the parallel thing is a lie (I've had stuff hang which would never happen if it was true, and after looking around, sure enough, not parallel) it's likely that the alternatives are still faster than systemD on the same hardware.

Re: Init alternatives

[Anonymous Coward]

You are lost in Microsoft land. You don't reboot after applying updates unless they are kernel updates.

Or glibc. Or any other commonly used system libraries that are used by nearly everything.
Between the kernel and glibc, RedHat seems to publish a security fix about every week or two.
Or, you manage more than one desktop Linux install, like say a thousand special butterfly servers running different things, you're not going to restart every process using libz.

Plus this is Linux, and if I find a server running for a length of time I immediately begin to suspect fstab and current mounts to be out of sync, or any of a hundred other things where "do this, then do THAT to make it permanent" was not done correctly or tested. The number of things that could be wrong when it reboots just grows as time goes in because of that design everywhere. Not something desirable for even 100+ servers or probably much less.

Re:Init alternatives

[Anonymous Coward]

Winner.

Re:Init alternatives

[dbIII]

A wireless USB mouse dongle is plugged in :(
I'm not joking.
Something so incredibly trivial hung the thing consistently as it attempted to start a systemD service to handle it, failed and did nothing - on several machines after an "upgrade" to a distro with systemD.
Where is the parallel init that Lennart promised?
No second thread doing stuff and no giving up and going onto the next thing like a production quality init system.

I've seen others but that was the most recent

Re:Init alternatives

[dbIII]

In the spirit of "Do one thing and do it well"

Doesn't fit, systemD is an octopus that grabs hold of something new before the old bits are stable. Didn't you see the article about how it is going to fuck about with shells and kill background jobs just because the user has closed their shell? That's not doing it's thing and it's definitely not doing it well.

Re: Init alternatives

[Anonymous Coward]

I suggest that you reboot, but with the understanding that the reboot is not required because there were security updates, but for a different reason.

No... the security updates need to overwrite things that are currently in use.

Windows delays this until the next boot, Linux just does it.
There's no special sauce magic to the way Linux does this, it just leaves behind a tangled mess of processes running different versions of the same libraries. Just as insecure as they were before the patch, and questionably stable. The larger the batch of updates being applied before rebooting, the more inconsistent the system becomes.

In theory you can restart every process that has a deleted file open, but this is non-trivial under most circumstances or when multiple servers are involved. It's also not without risk. From an engineering point of view, what Unix allows is scary, but all unix vendors recommended rebooting after a patch and patching from single user mode. Windows just automated that best practice, and Linux users don't seem to get the same advice from their OS vendor that every unix user did, because I don't know, faith based engineering?

Re: Init alternatives

[t_hunger]

Let's rephrase that: Linux finally has an init system that does something devleopers find useful enough to make their software use that functionality.

How dare systemd be useful? It should stay as useless as all the rest, so that we can have more useless init systems and switch back and forth between those.

Re:Init alternatives

[dbIII]

The thing is, there's so much damn drama over it that I'm curious what its detractors want to use in its place

The old stuff still works better than the new thing in rapid development so the question is the other way around. The detractors (I'm halfway to being one despite or maybe because of using it on some systems) either think it isn't ready or think various parts are doing things the wrong way, plus the newbie level bugs are a bit offputting. A binary log unprotected from race conditions - what fun!

Re:Init alternatives

[dbIII]

I had a lot of issues with systemD not working well with ZFS on Fedora. I've also had issues with things like ntp dying and systemD being convinced that it is still running.

Re:Init alternatives

[Anonymous Coward]

Live patching is not a panacea. You still need to reboot the server because every live patch degrades performance. In some cases, depending on the call graph, it can be multiple orders of magnitude slower with just a handful of live patches patching a handful of functions.

Re:Init alternatives

[afgam28]

99.9999% (six nines!) is 31.5 seconds of downtime per year. If you get an outage, it's not reasonable to expect anyone to be able to investigate anything in 31.5 seconds, let alone fix it. So any system with six nines of availability must be architected so that it is a cluster of servers, with automatic failover. If a single server crashing can take out your availability SLA, then the system needs to be rearchitected.

With 99.99% (52.56 minutes per year) of availability, having a backup server will still help. Even on a sysvinit-based system, there are so many things that could go wrong that cannot be fixed in 52.56 minutes. What if the hard disk crashes? You've barely got time to replace it and reinstall the OS, so you really need one that's already set up and ready to go.

If meeting your uptime requirement depends on having easy-to-debug boot scripts, then something is very wrong.

Re: Init alternatives

[Zero__Kelvin]

The fact that you would mention Windows at all is a pretty big red flag that you don't understand Linux, but thanks for going further and making it explicitly clear!

Re:Init alternatives

[Anonymous Coward]

Yeah, uh try runit combined with runsvdir? Void Linux uses it, and I guarantee Void will start up faster than any system using systemd.

Re:Init alternatives

[Anonymous Coward]

Wait a minute there! I was working on those 20+ year old systems. It wasn't a bed of roses then either, and I'd rather not trade in my iron age tools for the bronze age tools of back then.

Want to go back to CDE, the common desktop enviornment? Tom's window manager? Shells without history support? No auto-completion on the CLI? The primary software installation mechanism of stuffing it all in a directory under /opt? Unix systems that locked up if /var filled? Enough said.

Personally I love systemd, not because it's fast, but because it completely prevents boneheads from putting stuff in init.d scripts that never should have been there.

Re:Init alternatives

[Bing Tsher E]

So using systemd with parallel means you can ignore problems in the boot process indefinitely as long as it doesn't immediately affect your system.

Very good. A kludge can remain a kludge indefinitely.

Re:Init alternatives

[Pentium100]

While I did not have a lot of problems with SysV or Systemd, I wish I could make Systemd boot sequentially. Once I spent quite a bit of time troubleshooting a problem where a zpool would not mount at boot time. It turned out that the controller for the zfs hard drives was initialized too late for the boot process (system drives were on a different controller). This never happened with SysV and I wish I could set Systemd to mimic this as well, even if it adds some seconds to the boot time of a server I reboot once a year.

Debian jessie does well to hide Systemd. The usual commands work and I usually forget Systemd is even there, unless there is a race condition or I forget to do a "systemd daemon-reload" after editing some files in /etc/default/

Re:Init alternatives

[Bing Tsher E]

that's where development stagnated

More flippant handwaving in usage of words that shows a lot about weakness in your argument.

Development 'stagnated' only implys development needed to continue. Now, we all know that everybody wants their email address in important headers in the software project, so everything needs to be ripped out and replaced at whim on a regular basis.

But things aren't 'stagnant' unless there's a reason for something newer to replace them. Has the development of new cinder block designs 'stagnated' because nobody has designed a new cinder block for probably a century? No, the existing design is fine and doesn't need replacement.

I don't think the argument has ever been that "old means bad".

In the case of people like the Lentard, the argument is 'I wasn't in charge when it was put in place.' Obviously the dude knows better than anybody else.

Re: Init alternatives

[Anonymous Coward]

That is why systemd is moving grep to pid 1.

Re: Init alternatives

[phantomfive]

I've addressed your point here (and I'll ignore that you just attacked a strawman instead of my main point, except for mentioning: please learn to read before commenting).

Re:Init alternatives

[phantomfive]

Just for you I started up my systemd configuration GUI

Wow, thanks. Why would you do that for me? How does it at all relate to my post?

Re:Init alternatives

[Anonymous Coward]

If systemd would stay as an init service that would be fine with me (although I think that it could be designed much simpler/better).
However is swallowed other rather unrelated libraries/services, so eventually everything now depends on it. Devuan does good jon splitting those and giving us back those swallowed functionalities so when shit hits the fan we can take a step back without breaking all detendent software. And yes, Lennart is an arogant, asshole, incopet for designing API/interfaces.

Re:Init alternatives

[Anonymous Coward]

On disk? Sure. But it has always seemed to me that there is plenty of output on console in case of early boot failures under sysv. You should ALWAYS have remote console access available in case of servers (serial console, IP KVM, Intel's AMT, or VNC console for virtual machines).

Re:Init alternatives

[Pentium100]

I have Linux servers that I rarely reboot (and they usually spend more time booting the BIOS than booting Linux with SysV or Systemd).

My main PC is a Windows PC and I reboot it less frequently than the servers, because I cannot back up the "state" (that is, open programs, open files, window positions, open connections), while the servers reboot and autostart all that I need, I just have to ssh to them again when I need to.

I have a HTPC that I shut down when not in use, and I installed an SSD after its hard drive started acting up, but it doe not really speed up the boot process (that is, that PC is already at the login prompt when my TV "bots" and my amplifier warms up), but it makes it a bit faster after that.

I have UPS power for about an hour (more if I shut down a couple of the server in an effort to preserve the main PC running), but even if I need to reboot my main PC, I really do not care that it takes 5 minutes to boot as opposed to 1 minute, because I then spend 30 minutes restoring the "state".

For a laptop, the boot time is a bit more important, but I usually hibernate it and as such do not particularly care how long it takes to reboot (as long as it is under, say, 5 minutes).

Re:Init alternatives

[TechyImmigrant]

>Personally I love systemd, not because it's fast, but because it completely prevents boneheads from putting stuff in init.d scripts that never should have been there.

This.

I used to go in to troubleshoot a service problem to find page after page of dense impenetrable bash script with no obvious purpose. That doesn't happen much any more.

Re: Init alternatives

[Anonymous Coward]

Diff AC here, but I had to move from Debian to FreeBSD because systemd would frequently stop working (especially after routine updates) and there would be no helpful log or journal entries.

I ran into more problems with systemd after just a few months of using it than I had experienced during almost two decades of using Debian with its pre-systemd init systems.

Re: Init alternatives

[Zero__Kelvin]

So prey tell ... With no logs (bullshit) how is it that you determined it was systemd that was at fault again? ROTFLMAO

Re:Init alternatives

[Anonymous Coward]

It doesn't automatically email logs?

Though it's SMTP service which is a buggy reimplimentation of half of sendmail?

Which is based on a buggy reimplementation of half of a TCP/IP stack (we may be running before the network gets configured, so on most modern Intel cards, we're going to write raw ethernet frames for an https request to the mothership to find out what server to smtp the logs to).

Re: Init alternatives

[Anonymous Coward]

Yes, it does. The opposite isn't.

What a distro distributes is supported, what's not included isn't.

Re: Init alternatives

[Anonymous Coward]

Calling him Lentard shows how immature and outright stupid you must be. If you want to address the gp, fine. Otherwise, stfu.

Re: Init alternatives

[Anonymous Coward]

s/ROTFLMAO/CLOSED WONTFIX/ and you too could be a systemd dev.

Re: Init alternatives

[Anonymous Coward]

Read what I wrote:

... no helpful log or journal entries.

See the word "helpful"?

There were typically log entries from systemd, they just weren't useful, other than to make it clear that systemd was responsible for the problems.

Helpful log entries tell me exactly what went wrong, why it went wrong, and how I can fix or avoid the problem. Just knowing that systemd was running when it screwed up is not helpful.

But systemd isn't a concern of mine any longer. Now that I'm using FreeBSD, debugging init problems just doesn't happen. FreeBSD is very stable and reliable.

Re: Init alternatives

[Anonymous Coward]

diff ac - because it worked prior to systemd and not afterwards? Because logs were not able to be investigated because, well, they're not guaranteed, or they're corrupted? Also, what problem was systemd solving with its binary logger? syslog already existed, and was perfectly adequate. If systemd would have sent everything to syslog, I'm sure few people would have had an issue with it.

Re:Init alternatives

[Anonymous Coward]

Can be trouble-shot does not mean *easy* to troubleshoot, but point taken.

Re:Init alternatives

[Anonymous Coward]

Are you serious? The only reason I never shut down my computer in the 90s was the whole perverse "how long can your computer stay up" obsession - you know, back when reliability was a mark of pride rather than a given. Like most people I've long since stopped with that: I expect my computers to just work for as long as required.

I don't leave my car idling in the drive just because I can. Nor do I leave the tap running and just take out the plug when I don't need a sink full of water. No: I shut them down when not in use. Why would I treat my computer any different?

Re: Init alternatives

[Anonymous Coward]

Systemd does actually do one thing very well: it does a great job of driving users away from Linux to the *BSDs.

Re: Init alternatives

[Anonymous Coward]

So, Debian includes and supports OpenRC, sysvinit, runit, ... (Otherwise Devuan wouldn't include them either.)

What is the point of Devuan again? :)

Re: Init alternatives

[Anonymous Coward]

CDE is a much more usable desktop environment than GNOME 3 is, despite being relatively old and neglected.

Re:Init alternatives

[Sarten-X]

Has the development of new cinder block designs 'stagnated' because nobody has designed a new cinder block for probably a century? No, the existing design is fine and doesn't need replacement.

That's a very interesting analogy, since I'm currently in a Japanese hotel overlooking a construction site.

Rather than the typical cinder blocks, the bottom two floors are being built from large reinforced concrete slabs, about 1 meter by 3 meters, which interlock and periodically have apparently-plastic pieces. It definitely has increased the speed of construction over laying cinder blocks, and I suspect the slabs and plastic provide some means of safety in an earthquake.

Elsewhere on the technological spectrum, several years ago I volunteered in Africa, where buildings were built with more traditional cinder blocks. The blocks, though, were formed with poor-quality cement, and crumbled when put under load. In America in the 1980s, I was involved in a remodeling project that had to replace some 50-year-old blocks because they were falling apart. Modern blocks (30 years ago) have much more consistent quality, because manufacturers can now chemically test the quality of cement before using it.

In short, construction techniques and technology have indeed improved in the last century. Not even the traditional block dimensions are "fine" for all cases, as I see across the street, though in other areas compatibility is necessary. The requirements have changed, but you seem blissfully unaware. Fortunately, your ignorance of technological progress does not negate its existence.

Re:Init alternatives

[Anonymous Coward]

Oh great, so then one needs something connected to the KVM 24/7 in case something interesting happens?

With sysvinit, not only are boot messages only shown there (and not logged), but also background services might decide to write to std{out,err} something of interest. And that doesn't get logged with sysvinit...

Re:Init alternatives

[Anonymous Coward]

Fake bug report no doubt planted by one of the potter-cunts shills. You are going to have to work harder to fake things if you want them to look believable.

Re: Init alternatives

[Anonymous Coward]

Uhh, the problem isn't that something went wrong. The problem is that it is easier to switch to FreeBSD than to root cause trivial issues on systemd boxes.

Oh, now that I typed that, I see the "Now just...." sentence is probably the missing systemd log message.

Re:Init alternatives

[Anonymous Coward]

Interactions also include installing and uninstalling services, building services, figuring out how to get services to start and stop in a required order.

I was supprised to find that with systemd taking over logging, a simple 'tail -f /var/log/messages' is not so simple anymore.

Re: Init alternatives

[drinkypoo]

hardware wise to a point you wont notice a diff with either init.

The place I believe it makes sense is in short-lived virtual machines. But that's no excuse for making it the default in other forms of OS.

Re:Init alternatives

[skids]

There's tons more *useless* information in the systemd journal, and all the useful logging daemons usually do tends to be turned off by whoever wrote the default service file.

I really can't see how a system where a failed service doesn't bother to tell you it failed when started by hand from the command-line got anywhere popularity-wise. Seriously. Doing a "systemctll start blah" when blah enters a failed state doesn't say anything different than when blah starts successfully. What. The. Hell.

Also, I don't appreciate having to learn a bunch of directives only useful inside systemd unit files, named apparently by someone with really bad instincts for naming things. With a shell script, I can see a command being used, and if I do not know it yet, I can read the manpage for it, and here's the trick: I can then use that command for other stuff, not just running daemons.

Granted systemd is better at "structuring" the init scripts... is you need to manipulate them programmatically that's handy. Almost. Everyone. Does. Not. Need. To.

Re:Init alternatives

[deek]

Until the error message that appears on bootup quickly scrolls out of view, and then out of the virtual console buffer. I've been burnt by this before. It's incredibly frustrating! For all its perceived faults, systemd definitely has an advantage here over sysv init.

Re: Init alternatives

[skids]

This has happened to me as well. How did I determine it? By spending an hour figuring out something that would normally take me 5 minutes to figure out.

Re: Init alternatives

[Anonymous Coward]

Different AC here.

Why bother? The best part of switching to BSD is leaving the Linux community behind. Seriously.

Is systemd the end of the world? No but it sure as hell is convoluted and has too much responsibility. I personally don't like binary logs and that's enough for me to not like using systemd. More so I don't like redoing my system for something that gives me no additional value. The effort to start using systemd and migrate my machines and clusters over was... not worth it. Not for a second, it's a waste of time and money.

What I like even less than anything systemd has done is the Linux community acting like a bunch of petulant children. Your hyperbole is exactly what makes Linux suck.

I switched to BSD because fuck it, if I've got to learn something new that fucks up my day it might as well have a value add for me (ZFS and Jails). Along with a more mature and I believe, academic, community.

Please go back under your rock troll.

Re:Init alternatives

[Eravnrekaree]

Wrong. It can manage things if you want it to. I have configured my own scripts to mount things on systemd just fine. Just more FUD. systemd has worked well here, with simplifying administration. systemd just randomly kills process? What are you talking about. It only kills them if thats what you ask it to do.

Re:Init alternatives

[skids]

many of the whiners seem to be complaining that they might have to learn something new.

No, I like learning new things. Learning crappy things that have no reason to be so crappy, however, is not fun, and spending a bunch of time dealing with deficiencies in systemd is not what I like to do with my time. Next time I have a reason to install on something (rare, these days) I'll definitely be checking out devuan.

Re:Init alternatives

[deek]

And I suppose my mail server shouldn't play the opening to Carmina Burana on bootup, while I'm busy buttering up my piece of toast? Would kill for systemd to support grilled cheese. ;)

Re:Init alternatives

[Etcetera]

It isn't so much that "old is bad" as that the new is more likely to have been designed with modern paradigms in mind. Despite your dismissal, parallelism in particular is important, especially as Linux has taken a role as the embedded OS of choice for smart devices and cheap laptops.

Linux was succeeding quite well in the non-RTOS embedded space and with cheap hardware long before systemd came around. And an embedded device (aka, an appliance) is precisely where you want the MOST deterministic functioning. You don't just randomly through a bunch of parallelized shit in there and hope systemd all figures it out for you.

The fact remains that the previous init harness was perfectly reasonable. People that needed service management, socket launching, and other functions had options in daemontools, inetd/xinetd, runit, and myriad other tools out there, while rc (on BSD) or the chkconfig-controlled symlinks in rc.d gave structured sanity to the set of deterministic instructions a machine needed at boot.

Systemd's writers forcefully shoved all that aside in favor of a one-size-fits-all strategy that people had to accept whether they liked it or not, and once it was in place, they did everything they could to burn the bridges back to other paradigms.

Re:Init alternatives

[Etcetera]

In my experience, Slackware is a lot (very noticeably) faster than Fedora on the same HW. I don't know whether it is due to systemd or SELinux or something else entirely, but if you need raw speed, then you seriously should consider going back to basics.

Fedora would have been well served by following Debian's DashAsBinSh project back in the day. Post-kernel boot times might have been cut by up to a half or so, thus dulling the argument for systemd to begin with.

Re: Init alternatives

[crhylove]

Except in practice. Debian 8 was utter fail in all 3 of the data centers I manage. So many bizzare crashes we gave up after 3 days of testing. Wheezy and earlier had never had any issues. So for us anyway, as a longtime Debian shop, we've just been sticking with wheezy until something sensible came along. So far, in testing, Devuan had been incredibly sensible, stable, and reliable. Exactly like wheezy has been.

Re: Init alternatives

[crhylove]

For many of our servers, Debian 8 was a speed regression. And a huge stability regression.

Re: Init alternatives

[Zero__Kelvin]

Great job making up numbers. Someone who actually knew what they were doing and understood systemd would have found it in 5 minutes no doubt. You seem to think your ignorance is systemds fault.

Re:Init alternatives

[Anonymous Coward]

nigga please, hibernating your shit when you are not a BEAR might kill your hardware. This nigga has never seen a hard drive fail, ever, but the thing is, i dont use hibernation, because im not a bear. Even the shit i have from notoriously faulty models still works perfectly fine decades later, stuff that i have thats decades old that was supossed to be faulty and fail the first fucking year

all because im not a bear and i dont hibernate

Re:Init alternatives

[Anonymous Coward]

Are you describing systemd or Windows 10?

Re: Init alternatives

[ArmoredDragon]

Are you that guy from emutalk?

Re: Init alternatives

[Anonymous Coward]

You didn't address his comment, and telling people to "learn to read" is a common sign of someone who doesn't argue honestly.

Re: Init alternatives

[skids]

You fail to realize that discoverability is a desireable software attribute, and systemd does not have it.

I've had very few discoverability problems working in unfamiliar territory before systemd. Mostly, I just had to ferret out the right env flags to stop debug output from being suppressed from within init.d scripts... that was less discoverable than it could have been. On systemd, discoverability is for shit.

Re:Init alternatives

[ausekilis]

It's probably the most cost-effective way to get back in the game. Back when it took 45 minutes to install and another few hours to configure the OS, it made sense to try to troubleshoot. Now it takes 5 minutes to install the OS, and with package managers (and assorted partition setup), you can be up and running in 10 minutes. Will it take 10 minutes to fix? no? re-install.

Re: Init alternatives

[Zero__Kelvin]

I don't fail to realize shit. You are a douchebag that doesn't understand how the system works and then blames the system for your incompetence and ignorance. Off you go now ...

Re:Init alternatives

[WorBlux]

Race conditions are a bi+ch.

Re:Init alternatives

[WorBlux]

It's a potential issue, admitted right in the configuration file.

From Gentoo's rc. conf >>
# Set to "YES" if you want the rc system to try and start services
# in parallel for a slight speed improvement. When running in parallel we
# prefix the service output with its name as the output will get
# jumbled up.
# WARNING: whilst we have improved parallel, it can still potentially lock
# the boot process. Don't file bugs about this unless you can supply
# patches that fix it without breaking other things!
#rc_parallel="NO"

Re: Init alternatives

[skids]

Off you go now ...

Off to devuan...

BTW I'm apparently competent enough to patch shit now and then. That shit won't be anything systemd related, so that's one less contributer to your mess. Have fun with that.

Re: Init alternatives

[Zero__Kelvin]

Yes it's a complete clusterfuck mess that every major distribution chose to use. Later dumbshit.

Re:Init alternatives

[gweihir]

And fail. Reinstalling will not fix the issue.

Re: Init alternatives

[Anonymous Coward]

pro-systemd-person is the first one who starts calling the other names. what a shock!

Re: Init alternatives

[Zero__Kelvin]

I'm not pro or anti systemd, and dumbshit is too stupid to understand systemd and can't figure out name calling has nothing to do with it. Huge surprise there!

Re:Init alternatives

[TechnoJoe]

Ok, so you're trying to call 911 on your android phone (which runs Linux), but you have to wait for it to boot. You're ok with it taking 3 minutes to boot, instead of 10 seconds?

Re:Init alternatives

[Anonymous Coward]

and when some awesome new feature is invented for terminal programs you'll have to wait for it to be included in neovim or include it yourself. Me? I'll just press ctrl-z in vim and get the new feature immediately.

Re:Init alternatives

[Anonymous Coward]

Working on embedded Linux devices for over a decade, and trust me: OOM conditions have been killing random processes way before systemd entered the field.

Can't really fault the systemd architecture either - it's pretty similar to what I did for a military project. Of course, our "device removal" events tended to be a bit more violent than a simple USB removal, but the idea of dynamically figuring out what's (still) available is not at all new.

Re:Init alternatives

[Anonymous Coward]

to be honest ive not seen any boot time improvments from systemd in debian the only difference is systemd gives a blank screen during bootup whereas init told you what was going on. and they call it progress

Re: Init alternatives

[crhylove]

Many, many years ago. Yes. LOL. Since then I've been the IT director for 13 school districts, ran a data center that processed millions of mails per hour for ISPs all across the country, and also built dozens of dental offices in Arizona and California. I'm a very experienced Debian admin, and have moved most of our newer servers and services over to Devuan already. Works great!

Re:Init alternatives

[lsatenstein]

Please unconfuse me, is the "it" in your opening sentence referring to Systemd or the Init system.

Like all new replacement functionalities, there are teething problems. Already, systemd is stable and easy to use as a system management tool.

I find systemd just fantastic, considering it's age and the progress made.

I guess, thats why SUSE' RedHat, Ubuntu and Debian have evaluated systemd against their existing init system and made the switch. Resistance to change reminds me of the expression.

When the only tool you have is a hammer, everything looks like a nail.

Re:Init alternatives

[I4ko]

If you have done your VMs right, with an LVM and a sane file system with online resize (e.g. XFS) you don't need to shut down a VM to add a new disk. You just attach a new virtual disk, add it to the LVM, extended the volume, extend the file system and you are on. With ZFS you get all that plus live snapshots so you can do your consistent backups. Those things have been invented years ago, but again I'm surprised that some "devops masters" (point a finger at some colleagues) are not aware of them.
Regarding the new services, why would you reboot instead of just going to runlevel 1, or using properly your service management stack? E.g. djb deaemontools - those run in userland on top of init, though I don't like them particularly so usually manage other ways.

Re:Init alternatives

[Anonymous Coward]

Seeing as how I can't find an OP from you stating the problem to be fixed, I'm gonna conclude you're just some kind of poser. I have had plenty of success where a reinstall fixed a boot issue.

Re: Init alternatives

[Zero__Kelvin]

systemd certainly has that capability. The fact that you don't know about it is immaterial.

Re:Init alternatives

[Bing Tsher E]

That's updated concrete chemistry. Not really updated cinder blocks.

The xterm code that ran on a SparcStation 1 is essentially the same code as the xterm I can run on a modern 64 bit Intel box. The 'cement' is updated but the design of the 'binary' remains nearly the same.

My 'ignorance of technological progress'?

The Windows NT registry repurposed as a binary registry to blight Linux is 'technological progress?? I think this whole discussion topic would only have two or three comments on it if that were true.

Re:Init alternatives

[Ol Olsoc]

As well, the people who want to whine about systmed want to be able to whine about systemd. There are other distros before this one that were free of systemd. They didn't stop the whining. Because the whining, the line in the sand, and the declared target was systemd.

Ah. lookks like I hit a real nerve with someone calling my post flamebait.

Risk losing yur mod point dear moderator, and tell me exactly why simply noting that people complaining about systemd might make themselves much happier by using any of the fine systemd free distros out there. t's not a requirement to use systemd Linux on your computer.

Re:Init alternatives

[Bigon]

Well the goal of systemd is to be a base system for GNU/Linux distributions to reduce the gaps between them.

such as the default enabled "KillUserProcess" command

No distribution that I know enable that by default

Re:Init alternatives

[maharvey]

You mean I'll lose a whole second every two, maybe three months? That's a second of my life I'll never get back.

Re:Init alternatives

[gweihir]

Well, if it was Windows (which has a somewhat unpredictable and randomized installation process), or you broke it yourself and forgot what you broke, sure. But otherwise no. You need to find the root-cause of the problem and fix that. Re-installation is not going to do that and is basically a system-administration "worst practice" (meaning you are a bloody amateur if that is your idea of fixing things).

As to "poser", as an AC, you have zero standing calling anybody anything.

Re:Init alternatives

[Anonymous Coward]

Any time something with dependencies are done in parallel one risk deadlocks.

Nothing unique to openrc.

Re:Init alternatives

[Anonymous Coward]

It seems to have skipped email and gone straight to web server.

https://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.html#

Re:Init alternatives

[Antique Geekmeister]

> Well the goal of systemd is to be a base system for GNU/Linux distributions to reduce the gaps between them.

Please note the "Linux only" focus. It's not compatible with _any_ other free software or open source based operating system. And "reducing the gaps between them" has been breaking many stable, long-working tools without significant benefit.

>> such as the default enabled "KillUserProcess" command

> No distribution that I know enable that by default

The default was changed to enabled in the systemd source code in release 230. Unless distributions or developers manually patch their configurations, this unrequested behavior is now on by default.

Re:Init alternatives

[Bigon]

> Well the goal of systemd is to be a base system for GNU/Linux distributions to reduce the gaps between them.

Please note the "Linux only" focus. It's not compatible with _any_ other free software or open source based operating system. And "reducing the gaps between them" has been breaking many stable, long-working tools without significant benefit.

Nothing is preventing anybody to re-implement the external API's of systemd on any OS (well need D-Bus).
Regarding the benefits, I'll let you be the only judge, for my use cases it's a nice improvement

>> such as the default enabled "KillUserProcess" command

> No distribution that I know enable that by default

The default was changed to enabled in the systemd source code in release 230. Unless distributions or developers manually patch their configurations, this unrequested behavior is now on by default.

There is a configure flag. Anyway, systemd needs to be integrated inside the distributions, it's definitely not advised for random users to compile it themselves without using the distro patches.

Re:Init alternatives

[Anonymous Coward]

Thats like saying Windows is secure if you turn of 99% of the services it comes with out of the box.

Linux used to be about building from the kernel up. With Freedesktop, and particularly systemd, it has become more and more a case of the desktop down. Likely because so much of Gnome and freedesktop happens to be developed for Fedora by Red Hat employees (so that RH can file off the serial numbers and repackage it as RHEL ever so often).

Re:Init alternatives

[Anonymous Coward]

What F-ing gap?!

Only people i see complaining about gaps are the very same that can't grok a shell script if their life depended on it.

If they want to avoid gaps, they should focus their effort on making sure libs don't break their APIs between minor revisions (hello Gnome glib).

systemd is a severe case of "only have a hammer, every problem is thus a nail"!

Re:Init alternatives

[Antique Geekmeister]

> Nothing is preventing anybody to re-implement the external API's of systemd on any OS (well need D-Bus).

D-Bus does not exist for any other kernel. Attempting to replicate the API's of such a constantly growing, expanding, and feature increasing API that replaces stable internal daemon, network, mounting, and security features would be far more destabilizing that systemd's own growth.

The result is that cross-platform support now requires publication of several sets of init tools, typically SysV scripts for other platforms and systemd for modern Linux distributions. I'm afraid it's discouraging cross-platform work, which is unfortunate.

>> The default was changed to enabled in the systemd source code in release 230. Unless distributions or developers manually patch their configurations, this unrequested behavior is now on by default.

> There is a configure flag. Anyway, systemd needs to be integrated inside the distributions, it's definitely not advised for random users to compile it themselves without using the distro patches.

The default for the configure flag was changed. Previously working builds would now actively break common user tools, such as screen, tmux, and nohup, without leaving any systemd log of when they were killing such processes.

Like many other systemd architectural changes, this broke numerous long stable tools for no particular benefit. The normal way to kill long-running processes belonging to absent users is a cron job that emails the adminisator. Such tasks normally also allow exceptions for adminstrative users, and have even been written with alternative policies for unattended use or with warning notes to the particular users before killing their tasks, along with a log of the worst offenders.

Re:Init alternatives

[Bigon]

> Nothing is preventing anybody to re-implement the external API's of systemd on any OS (well need D-Bus).

D-Bus does not exist for any other kernel.

dbus-daemon exists on FreeBSD...

Re:Init alternatives

[Antique Geekmeister]

Thank you for the correction. I admit to not having personally used FreeBSD in quite a long time.

Re:Init alternatives

[Antique Geekmeister]

On review, the D-Bus in FreeBSD is not compatible with systemd. It looks like there have been some attempts to create "systembsd", but none of them successfully support the core logging or daemon management which were systemd's original reason for existence.

Re:Init alternatives

[deek]

Or, y'know, if the message disappears too fast for ScrLk (Pause doesn't work), and you happen to have systemd installed, you can just read the logs.

Re:Init alternatives

[Anonymous Coward]

SystemD brings nothing new to the table. Literally nothing new.

Well, that isn't entirely correct, it breaks longstanding POSIX standards and other applications like nohup.

Nohup is a marker that the process should survive the session. systemdick shuts it down anyway unless you explicitly tell systemd not to, except that is what nohup is for.

It is run by epic fucknuts who thinks Linux is a laptop only system.

Re: Init alternatives

[Anonymous Coward]

You are a fucking dumbass.

It is trivially easy to know if a log isn't helpful.

Systemdouchebag commonly swallows error messages as easily as you swallow Poeterings tiny, tiny cock.

Re: Init alternatives

[Anonymous Coward]

You are so far up the pathetic systemdickhead "devs" ass, your feet aren't even hanging out.

You are frothing at the mouth insane over legit grievances, it is obvious you are not only pro-systemdickwad, you are emotionally attached to it.

Stop swallowing jizz.

Pro-tip: Most leaders of distros are blubbering morons. Go to opensuse's reddit page and see their numbnuts "chairman" in action.

Completely clueless to everyone's use cases other than his own. Just like the systemdouche fucklenuts.

Re: Init alternatives

[Anonymous Coward]

Listen fuckhead, instead of running a single logger, syslog, to get what was lost in the systemdicklicker shuffle, you need two loggers.

That's right, two fucking loggers just to make your system usable. That is what systemdipshit does, it takes away perfect functionality and makes you jump through hoops to get it back. It is a monolithic piece of shit. An init system doesn't need to know all shit that systemcunt needs to just to operate. A useful init system doesn't know or care about nohup, cgroups, login, logging(outside itself), sessions, network status or all of other the worthless shit it does.

It is 30 bloated processes all which depend on each other, that is no different that a single massive process.

You think that is okay? Well you already displayed your ignorance and love of poettering already. I know you love licking his ass, but have the common decency to do it in private.

Re: Init alternatives

[Anonymous Coward]

You are truly stupid.

They are completely different things.

Re:Init alternatives

[Anonymous Coward]

When something goes wrong systemshithead sits around for 90 seconds doing nothing

Re:Init alternatives

[Anonymous Coward]

Tex is stagnant and that is fucking great, it doesn't need new features and a bug or two is found every couple of years. It is feature complete and as bug free as humanly possible.

What runs in PID1 is a very simple program. It doesn't need to do much or know much about the system. It has been a solved problem for decades. There is nothing new today that created new problems that were not already addressed, bug fixed and working smooth as shit for 10+ years. Nothing

Those fuck heads over at BloodyShitHat think that Linux is a laptop OS, and systemdouche is alright for that. Everywhere else it sucks, it does too much, it takes away functionality and control. There is a reason why RH7 isn't seeing the same numbers as previous versions and I will give you three guess why that is.

And of course, when something goes wrong it has to time out for 90 seconds for reasons.

Linux is on more devices that any OS on 2 planets. systemshit is not the reason for any of it.

Re: Init alternatives

[Anonymous Coward]

A program should not give a shit how it gets started or what starts it.

Tying your application to an init system is sheer idiocy.

OpenRC for life!

[Anonymous Coward]

OpenRC isn't a choice, its just something you feel.

Fedora Core 25

[cfalcon]

Lets talk about Fedora Core 25, and the upsides and downsides of defaul Wayland in some of the desktops.

I mean, it's only fair. Every Fedora release thread is filled with people whining about SystemD. Works both ways, right?

logging

[johnjones]

My one question is logging....

what did they replace SystemD with and how does it log ?

the FAQ and the rest of the site is VERY bare...

Re:logging

[drinkypoo]

what did they replace SystemD with and how does it log?

Unless they tell you so, you should assume they did something sensible like use something syslogd compatible, and if you don't like it, you can switch to another one. From googling I get the idea it's rsyslog.

Re:logging

[sjames]

Basic install uses SysV and rsyslog, at least that's what I got from the first Beta.

Re:logging

[Anonymous Coward]

rsyslog is still the default for Debian, I see no reason why they should change it.

contrary to what LP wants you to think, *nix systems were successfully logging for decades before systemd came along

Re:logging

[ruir]

The key phrase is for decades. I am using Jessie and Stretch *without* system, and *without* Devuan. Apparently, it works...I am using FreeBSD too now. Thanks for nothing, RedHat.

Re:logging

[Barsteward]

i don't think anyone argues that it didn't. Its now being done a lot better with more information and logging earlier and later in the startup/shutdown processes.

Re:logging

[Anonymous Coward]

rsyslog is still the default for Debian, I see no reason why they should change it.

contrary to what LP wants you to think, *nix systems were successfully logging for decades before systemd came along

They sure were logging, you just couldn't find anything.

Re:logging

[Anonymous Coward]

Binary log files are better? Gobbling up core dumps and mangling them together with actual log messages is better? That is, if the core dump even fits the log. If not, because your program was trying to do some acutal work on a couple of GBs of data when it crashed, you're SOL because the dump went straight to /dev/null. Great.

Re:logging

[Anonymous Coward]

After knowing for many years little old lady "prayer warriors", I can firmly state that your sig

"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)

is not wise. Prayers of the righteous are very effective.

Re:logging

[Barsteward]

not being deluded by a imaginary friend, i disagree

Re:logging

[Barsteward]

Yes, binary is faster for a journal. The core dump in the journal is optional, configure it to be written to a file or a journal.

superspeed

[Anonymous Coward]

If you can run sinit, openrc, runit, s6 and shepherd all at the same time, imagine the speed benefits!

Re:superspeed

[Anonymous Coward]

lol That's the funniest post of the day. Thanks for the good laugh.

Based Gentoo

[Anonymous Coward]

yay gentoo! Its very easy to avoid that systemd garbage. I'm not just bandwagoning here, I have to setup RHEL7 for a very large company because they wanted to stay with RedHat. It was hell on wheels. RHEL7.1 was a slight improvement but still not enough to ever consider it again.

Re:Based Gentoo

[Anonymous Coward]

I am not sure if you're serious. Because according to this page: http://distrowatch.com/table.php?distribution=gentoo
Gentoo was also infected by systemD.

Re:Based Gentoo

[cfalcon]

> yay gentoo! Its very easy

no

Re:Based Gentoo

[Kazymyr]

SystemD is available as an option on Gentoo. It is however not the default. If you really want it, you can have it.

Re:Based Gentoo

[Dan Ost]

Gentoo lets you use systemD if you want to, hence the availability of systemD packages for Gentoo.

However, OpenRC is the default.

Re:Based Gentoo

[Etcetera]

yay gentoo! Its very easy to avoid that systemd garbage. I'm not just bandwagoning here, I have to setup RHEL7 for a very large company because they wanted to stay with RedHat. It was hell on wheels. RHEL7.1 was a slight improvement but still not enough to ever consider it again.

I would kill for a systemd-free rebuild of RHEL, but it doesn't seem like there's enough of a push to be able to make it happen with some sort of plausible enterprise ability. It wouldn't be that hard -- basically take RHEL7 and stick RHEL6's initscripts and startup system onto it -- but it wouldn't be "EL7", which is important.

A systemd-free version of Fedora is tricker, if only because LP and friends have succeeded in burning as many bridges as possible within the base install away from any other init paradigm. Good job, guys. I hope you rot.

Re:Based Gentoo

[Anonymous Coward]

Check out Amazon Linux. It's the default option when you ask for linux AWS EC2 instance. They forked Centos 6 with updated packages and without systemd. Guess they know very well why.

Re:Based Gentoo

[Anonymous Coward]

One of the many reasons I'm sticking with Gentoo, OpenRC being the default. Was sorry to see Gnome go, but KDE Plasma is useable.

finally, a linux my Grandma can use

[Anonymous Coward]

"Grandma", I asked, "Which init system do you prefer? sinit, openrc, runit, s6 or shepherd?"

"Sonny", she replied, "That would be why Linux has not even 1 percent of the desktop OS market share."

XKCD.

Re:finally, a linux my Grandma can use

[phantomfive]

When talking about Grandmas, this xkcd is better.

Re:When will people wake up to the truth?

[slashrio]

Yes, Microsoft agreed to take over Linux, but only on the condition there would be a registry-like mother-process.
By the way, how is it even possible that one person got so much power in the linux open source community?

lol! "entanglement" is right!

[tlambert]

lol! "entanglement" is right!

What did Einstein call quantum entanglement?

"Spooky action at a distance".

What better way to talk about systemd...

Re: What's in a name?

[Anonymous Coward]

Yep, I personally won't even consider an OS unless it sounds at least 125% homosexual.

www.indukbola88.com

[yoona lim]

INDUKBOLA88.COM - AGEN JUDI BOLA CASINO TOGEL TANGKAS POKER TERPERCAYA INDONESIA Agen Judi Bola Casino Togel Tangkas Poker Terpercaya Indonesia. Pelayanan yang Ramah, Cepat dan Online 24 Jam. ==> Pasaran Sportsbook Terbaik Se-Indonesia Live Casino Ditemani Dealer Seksi Diskon Togel Terbesar BONUS NEW MEMBER BONUS CASHBACK TERTINGGI BONUS ROLLINGAN BONUS REFERRAL MINIMAL DEPOSIT 25RB DAN WITHDRAWAL 50RB JACKPOT POKER RATUSAN JUTA RUPIAH KENYAMANAN TRANSAKSI Didukung Oleh Bank Ternama di Indonesia == Transaksi dapat dilakukan melalui BANK BCA, BNI, Mandiri & BRI. Transaksi dapat dilakukan 24 Jam, sesuai jadwal Online Bank yang bersangkutan. Untuk Info Pendaftaran, silakan kunjungi : www.indukbola88.com Line : INDUKBOLA88 BBM : D61BA406 Whatsapp : +85517337689

So almost up to Slackware standards?

[Anonymous Coward]

Slackware still works great, and has never had systemd.

Re:So almost up to Slackware standards?

[Anonymous Coward]

> Slackware
Correct

> Slackware still
VERY correct

> Slackware still works
MOSTLY correct

> Slackware still works great
For certain values of "great"

> Slackware still works great, and has never had systemd.
True, but they aren't on record saying that they won't.

Re:So almost up to Slackware standards?

[Anonymous Coward]

> Slackware still works great
For certain values of "great"

Slackware still works better than a never-released distribution that only barely manages to keep running.

Libre

[ShakaUVM]

Is there an option to install it with all non-free repositories disabled by default? As my man RMS says, Debian is better than Ubuntu because it at least segregates packages into free and non-free repositories, but still enables both by default. If the non-free repositories were disabled by default, GNU might finally have a modern distribution it could throw its weight behind.

https://www.gnu.org/distros/fr...

My goal in running a GNU/Linux box is to not run a GNU/Linux box, and Debian and Ubuntu are really nice at that, but I'd like more confidence I'm running only free software than what I have now.

Re: Libre

[RLaager]

Ubuntu separates non-free stuff into restricted and multiverse (as opposed to main and universe).

Main and restricted are the supported packages. Universe and multiverse are unsupported packages. Here, "support" means paid technical support from Canonical and a security update promise (as opposed to best effort) from the Ubuntu developers.

Re:Libre

[cfalcon]

The fact that Debian doesn't meet Stallman's standards is a problem with Stallman's standards. Trisquel gives you what you are looking for, but when you can't use your hooble-dooble because the company is a bunch of apes that never made a FOSS driver, you'll be angry at the company, and a little angry that you didn't bend for just that one thing. You can run Debian as a fully free software Linux build, why is that not good enough? Because you could, if you wanted, not do that?

Their rationale on not including some of these- which dot a bunch of "i"s and cross a bunch of "t"s- is just very rms:
https://www.gnu.org/distros/co...

Basically, if there's a clearly labelled option to use nonfree / proprietary dudes, that disqualifies you. I have never met a single soul in person who finds that distinguishment useful, and outside of the FSF I suspect it is a rare opinion indeed, even among folks who jump through the requisite hoops to run only free software.

Re:Libre

[fnj]

The fact that Debian doesn't meet Stallman's standards

Says who?

Re:Libre

[ShakaUVM]

>Trisquel gives you what you are looking for, but when you can't use your hooble-dooble because the company is a bunch of apes that never made a FOSS driver, you'll be angry at the company, and a little angry that you didn't bend for just that one thing.

I guess. I run a headless server, device drivers aren't much of a concern for me. My main concern is minimizing the amount of work I have to do maintaining the server, including security patches and updates to the latest version of source code. I hate wasting my time.

>The fact that Debian doesn't meet Stallman's standards is a problem with Stallman's standards.

I think there's a certain amount of truth to that, but at the same time he makes some pretty good points and so I try to use free software everywhere in my business efforts. I'm not a purist, but I always choose a free (or freer) alternative over a non-free one.

Hence my question if Devuan makes it easy to install free-only software.

Re: Libre

[Anonymous Coward]

Best effort, or often no effort. Lots of security holes in universe. As a wise muppet once said, never put packages from universe on a server.

Re:Libre

[FrankHaynes]

I hate wasting my time.

Oh, I LOVE it! Why, just now I find myself sitting on my butt reading this whole thread, for example.

Re:Libre

[Anonymous Coward]

It does not help that even in the Unix community, we see Stallman as a raving lunatic.

Re:Libre

[unixisc]

Check the link he posted - it states why they don't endorse Debian

there is a lot of resistance

[Anonymous Coward]

first it was arch then debian. this system is becoming integrated in the linux system that this resyatance is only going to become harder. things like gento where the user normally builds everything thing are better.

Re: there is a lot of resistance

[Anonymous Coward]

Where do you see that resistance?

What?

[Anonymous Coward]

Who cares? Nobody ...

Re:What?

[Anonymous Coward]

I do bloody care my Linux system may be infected with systemd some day.

Good news !

[Anonymous Coward]

This is great news because "systemd" is total, utter, non *NIX, shit.

The terminal "d" in the name is actually short for "disease".

Putting "systemd(isease)" on a *nix machine is about as good as putting HIV virus into a human body.

Re:When will people wake up to the truth?

[gweihir]

Unfortunately, that is very likely.

Re:When will people wake up to the truth?

[Stormwatch]

Not Microsoft. Red Hat.

It's a question of mindsets

[Casandro]

In the spirit of "Do one thing and do it well", systemd's goal is "manage services and dependencies".

If it was it wouldn't include its own DNS server, or it's own timeserver, or it's own logging infrastructure.

The problem with systemd and the whole Freedesktop crowd is that they are trying to solve problems that do not exist anymore. For example you now have hugely complex systems just to make sure your soundcard will only be usable by users logged in locally. While this is, in theory, a great security benefit, most machines today are single user. So in effect it's lots of code that's useless at best and a potential security problem at worst.

Everybody goes through a phase where they think they can re-invent the world and design something cool and complex with the technologies they have just heard of. In the past only large companies could afford such an effort. Microsoft, for example, implemented many of the "new" ideas in Windows. This is why you have things like OLE with it's offspring of OLE automation, or a logging system nobody uses because it's essentially unusable. Windows being so unusable, particularly in the 1990s, was a big push for Linux for "serious" applications.

Now we have a new situation, it's "fancy" to have some work on a Open Source project on your CV, that's why there's a huge pressure for mediocre and bad developers to do something with Open Source. Those mostly are people who still having gone past their "coimplexity is good" phase and don't understand yet, that it's not a good idea to require 5 daemons in the background just to have a GUI running.

Ideally we should take a step back and look at what we _really_ need. Do we really have to have such a complex service management system? Shouldn't it be enough for a desktop system to just have a single shell script booting up X and the window manager and setting up the network? Why do we have a wireless subsystem that needs a "wpa-manager" just to set up the keys to encrypted networks? Why do we have a modem manager that reliably is unable to access your cellular card after a upgrade?

Have you ever tried to write your own minimalistic init-system? I once turned an old SuSE installation into an X-Terminal. It took a shell script of 5 lines and it booted in a few seconds... on an Pentium 90! You can get much faster if you cut all that crap you don't need.

Re: It's a question of mindsets

[Anonymous Coward]

> If it was it wouldn't include its own DNS server, or it's own timeserver,
> or it's own logging infrastructure.

Systemd-he-init-system die not have any of that. Systemd-the-proect does have all at in s repository though, all in their own little executables. Distributions are e free to use those or prefer other implementations. That seems to work fine: No distribution uses all systemd includes, and safely any uses nothing out of the systemd repository. Even devuan needs stuff from there (e.g. udev).

> The problem with systemd and the whole Freedesktop crowd is that they > are trying to solve problems that do not exist anymore.

Maybe not for you.

> For example you now have hugely complex systems just to make sure
> your soundcard will only be usable by users logged in locally. While this
> is, in theory, a great security benefit, most machines today are single
> user. So in effect it's lots of code that's useless at best and a potential
> security problem at worst.

Check /etc/password. I would bet there is more than one user in there, on all if your machines.

Re:It's a question of mindsets

[ruir]

> If it was it wouldn't include its own DNS server, or it's own timeserver, or it's own logging infrastructure. Make it having a web server, a SQL server, containers, and poneis...OGM poneis!!!! and we have a seller.

Re:It's a question of mindsets

[Barsteward]

The systemd binary and the systemd project are 2 different beasts, (they should have renamed the project to stop the confusion) once that is understood most of the anti-systemd comments vanish. The system does have 3 dependencies systemd, journal and udev. All the other binaries in the systemd project are optional.

Re:It's a question of mindsets

[Casandro]

I may be wrong, but isn't it that systemd also depends on things like dbus?

And again the problem is the mindset. Even though it might be possible to run systemd in a sane way, distributions now package it with all sorts of crap. The opposition against systemd is not about systemd itself, it's about people who constantly try to re-invent the wheel while not having understood the problem or how to solve problems in general. Just look at alsa and pulseaudio which were both attempts at fixing the previous state of the art... and making it somewhat worse. (i.e. Alsa created unfathomable device names which were written differently in every application instead of the simple /dev/dsp OSS provided, or pulseaudio added crap like software mixing so you'll enjoy the fun of quantisation noise while it won't allow you to automatically switch the number of output channels based on the number of channels your software outputs)

Re: It's a question of mindsets

[Anonymous Coward]

The opposition to systemd has a similar problem with its mindset: "This has been good enough for decades" is not helping to improve anything!

And the most opposition is from the sysadmin side of things. That also shows in devuan by the way: Proudly claiming "sysadmin focus" while being entirely ignorant about the problems of unix, many of which have been documented for decades.

Re:It's a question of mindsets

[Kiwikwi]

I may be wrong, but isn't it that systemd also depends on things like dbus?

Systemd uses the D-Bus protocol for communication (e.g. between the systemctl client and the PID 1 daemon), but a minimal systemd install does not require the D-Bus daemon. That said, you'll be hard pressed to find a Linux desktop systems or server without the D-Bus daemon (no matter what init system is in use), but it'd certainly be possible to build an embedded Linux system with systemd init, and no D-Bus daemon.

Even though it might be possible to run systemd in a sane way, distributions now package it with all sorts of crap.

Really? Ubuntu now ships with systemd service management and the journal (and, yes, udev and the D-Bus daemon, though those have been included for a decade or so). AFAIK, Ubuntu also uses systemd-logind (though it used that even before it switched to systemd init), and doesn't use systemd-networkd (but sticks to NetworkManager), nor does it use systemd's DHCP or NTP services.

Re:It's a question of mindsets

[Anonymous Coward]

> The opposition against systemd is not about systemd itself, it's about people who constantly try to re-invent the wheel

Those "people" are called Lennart Poettering. Take a good look at the "KillUserProcess" fiasco for an example of the problem.

Re: It's a question of mindsets

[Zero__Kelvin]

Wow. Just Wow! I can't even believe how many ridiculous falsehoods I just read. If systemd was about managing services it would include them? Or didn't you know that NTP, etc are services? You shouldn't have 5 daemons running to support GUI? Why the hell not? You don't seem to understand that under the hood it's background processes all the way down. There is NOTHING wrong with using them what with the fact that the system is designed that way from the ground up. I could go on, but you have made it clear that you have no understanding of the topics about which you are speaking.

Re: It's a question of mindsets

[Anonymous Coward]

It should fucking manage services. Not create its own new services to replace ones that work and are proven. .

Re:It's a question of mindsets

[skids]

For example you now have hugely complex systems just to make sure your soundcard will only be usable by users logged in locally.

Ironically, trying to work around that to allow a system daemon to use sound was one of the first things that pissed me off against the new session-based model, and in a separate incident, working around the awful stuff that has been done to audio by pulseaudio's session-based mixer management started to sour my stomach on just about anything LP has touched (well OK, prior to all that I did initially get mildly pissed until avahi finally became optional in Debian.) Now I find myself occasionally delayed dealing with systemd crap that would never have been a problem under the previous system.

It's just funny that example was chosen.

Re: It's a question of mindsets

[Anonymous Coward]

If systemd was about managing services it would include them?

And if Windows is about letting you run things like Excel, why shouldn't Windows include Excel by default? Err...

Re: It's a question of mindsets

[Zero__Kelvin]

It does either one. You are not locked in the way you think you are. Your distribution choose to use that feature. It isn't mandatory.

Re:It's a question of mindsets

[Barsteward]

Thats a distro issue so have a go at them if its not to your liking. If the wheel was not reinvented and improved, i'd be stuck with Wordstar on DOS. pulseaudio works fine and has done for a while, sometimes you end up going backwards a few steps to eventually go forward.

Re: It's a question of mindsets

[Anonymous Coward]

Sorry, I gave up trying to parse your argument at the fourth typo. Ever heard of spellcheck?

Re:It's a question of mindsets

[Anonymous Coward]

pulseaudio works fine and has done for a while

Awesome! I must be imagining the choppy sound I start getting after half an hour or so. While we're on the subject of pulseaudio, how do I tell it to use the hardware I have rather than doing software mixing?

FreeBSD

[Anonymous Coward]

...no systemd to be found.

Re:FreeBSD

[Anonymous Coward]

Sadly that's the only thing it's got going for it.

Rebuilding world, in 2016? Really? Not to mention having hardware support lagging even further in the past than Linux? Hanging out with people who constantly go yaddayadda, frothing around the mouth about an over-designed, resource eating piece of software (zfs) that few except the syncopates really care about?

Yeah.. that's some really enticing points, when I can install a Linuxdist sans systemd instead.

Re: FreeBSD

[Billly Gates]

Yep dtrace, jails, high uptime, and ZFS oh and init have no appeal at all!

Re: FreeBSD

[Anonymous Coward]

Uptime? That's the best you can come up with? LOL. I guess it's good in a way, because that means I don't have to waste any time on you, just go back to rebuilding world again, like good little nerd. Bye.

A worthy initiative - but their website is AWFUL

[Anonymous Coward]

I think a systemd-free Debian is the right way to go; systemd does have a lot of issues, enough to not have it be the default in a distribution that's more committed to software freedon and is managed democratically, like Debian. So, I support Devuan.

However, their website is just scary awful. Not that it isn't aesthetic, but they have some too-smart-for-their-own good website system. I haven't seen it anywhere else - perhaps it was developed by people related to the project itself? But, honestly - it's baroque; it's confusing; you can't figure out how to post what and where, and it lets you believe you might be able to post something only to be disappointed when it's not accepted. So not only is documentation lacking but it's also close to impossible to discuss anything (specifically problems you might be having with installation etc.)

So, dear Devuaners - stick to one major earth-shattering norm change, don't try to force your weird website management ideas onto us. If you had something like AskUbuntu.com or even the less-polished ask.libreoffice.org - that would be awesome.

BTW - It's interesting to note just how many packages you need to fork in order to make your Debian run without systemd.

Seriously?

[Viol8]

Issues of systemd aside, all those computers switched on doing nothing use up a boatload of electricity when you total the amount. Not only that, but leaving a machine on allows plenty of time for potential hackers to have a crack at it - unless you specifically switch off networking when you leave it - plus counter to what people think, computer components do wear out when left on, not just fans and spinning disks but also the electronics. If you only use your machine once or twice a day its actually better for it in the long term to switch it off. Sure, of you're only going to keep it for a few years anyway who cares. But I've got a 17 year old linux file server still going that gets used once or twice a week and spends the rest of its time off. And aside from motherboard battery changes its had nothing done to it and its in as good condition now as it was in 99 when I bought it.

Re: Seriously?

[Zero__Kelvin]

Somebody should invent Sleep and Hibernate modes and other power management tools so that your claim would be an obvious attempt to manufacture a use case!

Re:Seriously?

[I4ko]

One of my routers is a 19 or 20 year old box, Pentium 233-MMX overclocked to 250MHz, with 4 fast Ethernet cards, 128 SD ram. All of the components even the PSU are original (only fans have been replaced) and I replaced the IDE HDD with a flash card circa 2007. Now, that runs pfsense (BSD), but again, boot time is not the issue. It has been on for about 60% of that time, the last 10 years 24/7.
One of my file servers is a 2007 Mac Mini, that I just got a new fan for, but it is still not in a dire need of replacement. That machine has ran 24/7 all of the almost 10 years I've had it (with 18 month replacement of the HDD to a larger model).

Consumer grade hardware is good enough most of the time.

Re: A worthy initiative - but their website is AWF

[Anonymous Coward]

Most of the changes packages are just about removing libsystemd. That library is there to enable systemd support while staying compatible with other init systems.

Debian needs that since they are committed to support systemd and other inits. Devuan on the other hand does not trust anything with systemd in its name, so they decided to remove that library.

Re: What's in a name?

[ruir]

Hello Tim Cook, we know it is you, no use posting under AC.

I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

These self propelled horseless carriages are the devil's work. We must stop all forms of modernization and advancement and regress to a simpler time because our minds can't cope with change.

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

Jan 21 is when we do that.

Re:I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

Our minds have coped with changes continually since the beginning of GNU/Linux, you may want to think a bit more about why people don't want this specific change. Tip: it may be in part because once you use it, you can't change some of its part anymore, as we used to.

And your analogy is wrong, if you want to compare sysvinit with a carriage pulled by horses, then ok, systemd is a car with a motor. Great, but don't forget you can't swap the motor for another one, you can't change any part of the car actually. Oh, and there is a driver that does everything, you can't remove it. And it depends on specific roads that hurt horses' hooves and require them to use horseshoes, and road signs and fuel, etc.

I'll keep my horse and carriage for now, it doesn't hurt the GNU/Linux ecosystem, and I can swap out any part, including the horse and the carriage themselves, without breaking my system.

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

> [...] you may want to think a bit more about why people don't want this specific change.

Which people do not want the change to systemd? Systemd is basically universally adopted by now! I have been using Linux since the early 1990s and rarely seen such a wide consensus.

A small band of opponents is still clinging on somewhere working on fringe distros that nobody cares about much. Occasionally they make some fuss in some form somewhere, but usually they band together in out-of-the-way corners of the internet (on IRC and mailing lists, not this modern web,-stuff) where they go over real and perceived slights again and again, dreaming of the good old times when the world was better.

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

Well, devuan has a proven track record of missing its own deadlines. I will not hold my breath.

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

Which people do not want the change to systemd? Systemd is basically universally adopted by now! I have been using Linux since the early 1990s and rarely seen such a wide consensus.

You're wrong here. systemd has not been adopted universally. It has been adopted by many distros, of course, but let's take a closer look.

First, most derivatives don't have a choice, if the distro they are based on go systemd, they have too, or they have to put in quite a big amount of work, continually, with no guarantee that they'll succeed, see devuan.

Of the major non derivative distros, we have (correct me if I'm wrong), debian, redhat, suse, arch, which went systemd only supported, gentoo, slackware which didn't. And if you look even closer, in the case of debian, the vote about the default init was a split 4-4.

And even then, those who adopted it are the distribution maintainers, not the users.

And finally, since when is the marketshare a proof that something is good?

A small band of opponents is still clinging on somewhere working on fringe distros that nobody cares about much. Occasionally they make some fuss in some form somewhere, but usually they band together in out-of-the-way corners of the internet (on IRC and mailing lists, not this modern web,-stuff)

Reading that part, I'm wondering if your whole post wasn't sarcastic, actually. In case it wasn't, let me give you some info: gentoo and slackware aren't "fringe distros that nobody cares about", and those "out-of-the-way corners of the internet (on IRC and mailing lists)" are the places where even your beloved system devs and proponents go to discuss their modern systemd.

Re:I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

The purposes of systemd:

1. Inflate Potterings already overbearing ego
2. Turning Linux into an opaque mess just like Windows because
3. 1. Pottering grew up with Windows and just doesn't know better
   2. and/or because Redhat wants Linux to be like that so they can sell more support.
4. Create an evermoving target nobody else really can keep up with.
5. Thereby make Redhat Linux something completely different from "standard" Linux.
6. Enable Redhat to make more money via training and "certifications" through all this.

What's in it for me that isn't either completely irrelevant or just flat out overhyped uselessness like "ziomg, your computer boots 1.5 seconds faster!"?

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

> systemd has not been adopted universally. It has been adopted by many distros, of course,

That is what counts.

> but let's take a closer look.
>
> First, most derivatives don't have a choice,

I am petty sure any upstream distribution will take their downstream into account when making decisions. E.g. in Debian Ubuntu developers are present in all kinds of committees.

If upstream does not care for having downstreams, then you are fucked as downstream anyway.

> if the distro they are based on go systemd, they have too, or
> they have to put in quite a big amount of work, continually,
> with no guarantee that they'll succeed, see devuan.

And there is your choice! There is the option to pick a different upstream, too. You missed to mention that choice.

No distribution has a guarantee for success. Devuan did have a head start over other distributions though: they had a lot of media attention when they started out. Unfortunately their press- and community management skills are non-existing, so they did not manage to benefit from that publicity.

> Of the major non derivative distros, we have (correct me if I'm wrong),
> debian, redhat, suse, arch, which went systemd only supported,
> gentoo, slackware which didn't.

Gentoo and Slackware are already fringe, sorry:-)

> And if you look even closer, in the case of debian, the vote
> about the default init was a split 4-4.

I'd argue that there was no vote on the default init but on whether or not to support several. But anyway, Debian is defaulting to systemd while keeping the rest as an option.

> And even then, those who adopted it are the distribution
> maintainers, not the users.

The maintainers make decisions on a lot of things: Packaging formats, file system layout, init system, graphics system, and a thousand other things.

Users either accept those decisions or they move elsewhere. I have not seen a mass exodus yet, and interest in things like devuan seems minimal and shrinking, too. So my impression is that users are either happy or most likely do not even care one way or the other.

> And finally, since when is the marketshare a proof that
> something is good?

Indeed, it is not market share that is important.

Systemd has convinced the maintainers of all major distributions. Those people know a lot about their distributions and Linux in general. I do trust their collective expertise.

Systemd also convinced a lot of developers in gnome, KDE and elsewhere. As long as devs will require systemd for their programs all of us are stuck with systemd. Or we can stick with outdated software or write our own.

Re:I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

You forgot the part about being a NSA bitch and the real objective of systemd is weakning Linux security.

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

I'd argue that there was no vote on the default init but on whether or not to support several. But anyway, Debian is defaulting to systemd while keeping the rest as an option.

That looks to me like a vote on the default init: https://lists.debian.org/debian-ctte/2014/02/msg00281.html

The vote was 4-4 and since the casting vote was held by the chairman who already voted systemd, systemd won: https://lists.debian.org/debian-ctte/2014/02/msg00405.html

Also, while I can't find the page anymore, I definitely saw on debian's website that they do not support other inits anymore. You can still install them, but you have no guarantee your system will still work.

Users either accept those decisions or they move elsewhere. I have not seen a mass exodus yet, and interest in things like devuan seems minimal and shrinking, too. So my impression is that users are either happy or most likely do not even care one way or the other.

Or resigned, because where do you move? To Gentoo or Slackware, which aren't for everyone

Systemd has convinced the maintainers of all major distributions. Those people know a lot about their distributions and Linux in general. I do trust their collective expertise.

The fact that systemd is now a dependency of gnome and that a systemd based distro is easier to maintain is a reason that can outweigh other considerations. And again, what is good for the maintainers isn't necessarily good for the users or the linux ecosystem in general.

As long as devs will require systemd for their programs all of us are stuck with systemd.

And you don't think it's an issue that software starts to depend on an init system?

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

Maybe they meant January 2021? That might barely be doable by Devuan's VUAs.

Re: I'm still waiting for Horse Buggy beta 2

[t_hunger]

Debian never gave guarantees for anything but their default init. That has always been like that, it is just the init that changed. How could a responsible distribution make claims that init systems it never made am effort to test is supported?

I think users are mostly happy (or blissfully ignorant about init systems) with systemd. If they were not, then users would storm devuan. That distribution has seen lots of press when it started, so people did know about what is happening there, yet interest does seem slow.

I also think that maintainers would not have gone for systemd if they did not think it had benefits for their users. Contrary to what you think maintainers do care for having people use their distribution. The fact that systemd had convinced developers did also factor into the maintainers decisions. So did advantages for the packagers: Getting rid of init scripts was a big part of that. There were lots of factors considered at Debian, check the CTTE discussion you liked to earlier for more.

I do not think it matters whether software depends on an init system. Software depends on other software all the time and will adapt once some better option comes along.

Actually I find it reassuring that things start to depend on systemd: It means that it is reasonably simple to interact with the system and that it provides something worth the effort to talk to it. Never seen that before on Linux.

Re: I'm still waiting for Horse Buggy beta 2

[Anonymous Coward]

> Debian never gave guarantees for anything but their default init. That has always been like that, it is just the init that changed. How could a responsible distribution make claims that init systems it never made am effort to test is supported?

You could have reasonnable expectations other init systems would work, now you know your distribution will break with anything but systemd.

> I think users are mostly happy (or blissfully ignorant about init systems) with systemd. If they were not, then users would storm devuan. That distribution has seen lots of press when it started, so people did know about what is happening there, yet interest does seem slow.

Or they are resigned because they like the distros they were using and don't want to jump to gentoo, slackware or devuan because they would lose functionnalities they like. Doesn't mean they are happy with it.

> Contrary to what you think maintainers do care for having people use their distribution

When nearly every distro uses systemd, you won't lose many users by using it too.

> So did advantages for the packagers: Getting rid of init scripts was a big part of that
> Actually I find it reassuring that things start to depend on systemd: It means that it is reasonably simple to interact with the system and that it provides something worth the effort to talk to it.

It means lock in. No more init scripts and dependency on systemd means substancial parts of your system will break if you try to use something else. That's plain and simple lock in, and it's quite frightening for the future of liunx to see people like you celebrating it.

Re: When will people wake up to the truth?

[Anonymous Coward]

It's an easy mistake to make. Redhat have so obviously wanted to be Microsoft for ages now, and are worryingly getting there. In my experience the majority of Redhat employees seldom understand the systems they're dicking with, take geological ages to fix issues (even critical security issues) and often refuse to fix things they've broken.

Re:When will people wake up to the truth?

[Anonymous Coward]

Gnome 3, freedesktop, gtk+, systemd, flatpack, wayland, all controlled by RedHat, all having the purpose of unifying the GNU/linux ecosystem (thus under RedHat's control). It's not "very likely", it's actually happening right now, RedHat is currently doing a massive power grab, and most distros seem happy to fall in line

That's understandable from RedHat point of view, the fragmentation is probably GNU/Linux's worse weakness. But it's also it's greatest strength, and I think it is extremely dangerous for the rest of us if RedHat gets its way.

Slackware is still systemd free.

[Anonymous Coward]

Slackware is still systemd free and you don't need to be genius to use it. Being a subgenius is good enough. All hail Bob!

Re:Slackware is still systemd free.

[mark-t]

Although no official statements (to the best of my knowledge) to the effect that Slackware will never have systemd have been made, it's a pretty safe bet that if Slackware ever does start using systemd, Bob will be leaving Slackware and forking it into another systemd-free distro so fast that I expect nobody else will be able to tell which was the cause and which was the effect.

Re:lol! "entanglement" is right!

[GuB-42]

We can say that of abstraction layers in general.

Re:When will people wake up to the truth?

[gweihir]

Well, yes. Fortunately I use not one of the technologies in your list (with the exception of a small number of applications using gtk+, all of them replaceable by others), but the "normal" Linux user begins to be screwed almost as badly as a Windows-user.

And this...

[Anonymous Coward]

Is yet another reason Linux is stuck in the past and will never be a mainstream OS. Stupid neckbeards who are against change(which are for the better).

Re:And this...

[Anonymous Coward]

The neckbeards you are referring have been using well linux since for 4 decades and amazingly enough, it worked before systemd...hard to believe how for one day to another, it only works with systemd and everything has to be changed, instead of having a real choice, which was always the power and soul of Linux and opensource. Fucking idiot.

Re:And this...

[Anonymous Coward]

The neckbeards you are referring have been using well linux since for 4 decades

You really should stop making stuff up so obviously...

If you want to lie about how long you have used something, at least check how long said thing exists. But that would require too much of an attention span of today's teenagers I suspect.

void Linux for the win!

[Anonymous Coward]

If you want to have a systemd-free Linux, then take a look at void Linux. They actually have a clue over there.

http://www.voidlinux.eu/

Re:When will people wake up to the truth?

[Anonymous Coward]

Because DJB, aka Dan J. Bernstein, screwed up the licensing on daemontools.

There was very similar init structure that worked quite well, at https://cr.yp.to/daemontools/. Dan's tools, like his work with djbdns and qmail, was quite robust and appreciated by many developers willing to build their own versions from source. They also worked quite well on all the UNIX systems. However, Dan invented his own "special" licensing, one where you were not allowed to publish binaries with any patches applied. If you wanted to include patches, such as for example taking this tools out of the top of the file system where they did *not* belong, you had to publish his source and patches for others to apply.

No one, not Red Hat, Fedora, Debian, Gentoo, nor any of the UNIX distributions, could work with this nutty licensing. So *no one* could use it by default nor devote production time to it for operating system releases, so it languished. Eventually Dan gave up and made it completely public domain, but the damage was done. Systemd gained popularity in the meantime.

I like Systemd

[Anonymous Coward]

I am not a sysadmin, just a regular developer who set up and is maintaining my own workstation(s) with Arch Linux. Am I the only one who finds the traditional way of creating scripts to start and stop services an utter mess? Managing the PID, dependencies, reacting to events, there was no standardized way of doing things and every script author did it a bit differently. And I was honestly wary of creating my own services, as it involved getting a template from somewhere whose intent and purpose was not clear unless you were a guru with bash or sh script.
In systemd, now, creating my little startup scripts for any kind of binary daemon is a breeze - 6 lines or so, save at the right place and start it up. Everything just works as expected, no custom logic involved, in a way that is portable across distributions. Documentation is also very understandable and accurate.
systemd(-networkd) has completely taken over my network configuration as well, where it is able to manage wired and wireless interfaces on my laptop, including seamlessly roaming between different SSIDs. I run into various issues using the Arch native tools (netctl, ifplugd) and others (networkmanager with various GUI incarnations) - using systemd I just got rid of them all. Config is based on a few simple text files - no network manager, no GUI, nothing, just as I like it. journalctl as well is a godsend compared to the old way of storing random files in a log directory, with rotations etc.
Is it a big framework which does a lot of things? Yes, absolutely. Did I fare better using it that with previous (script-based) implementations? Yes. Does it work? Absolutely. To all the haters, get over it, use it or not, but don't ignore that systemd provides specific advantages for people who value easy configuration.

Re:I like Systemd

[Anonymous Coward]

You are a shill, and not quite good at it as you think you are.

Re:I like Systemd

[DrXym]

You're not alone. Most Linux users are entirely happy with systemd.

Re:I like Systemd

[Anonymous Coward]

Shut the fuck up Lenny Pothead.

CAPTCHA: OPISAFAGGOT

Re:I like Systemd

[Eravnrekaree]

You see the fact that it makes things easy to use is a problem for some Linux people, who seem to think Linux needs to be difficult and complex to use. In many ways the old way of doing init was backwards , you are right the declarative style of systemd is far more intuitive and with less wheel reinventing.

Free at last!

[Anonymous Coward]

First Trump wins the presidency and now SystemD has been ripped root and stem from debian! I am finally truly FREE!

Re: When will people wake up to the truth?

[Zero__Kelvin]

It isn't possible. Your claim is in fact ridiculous. RH and Pottering have nothing to do with Debian or any of the 100s+ distributions that choose to use it.

Re: When will people wake up to the truth?

[Zero__Kelvin]

You can't "Power Grab" GPL code, but I suspect you knew that before you posted that ridiculous drivel.

Let's roll!

[Ol Olsoc]

We need a good vim versus emacs war here!

Re: hibernation vs shutting down

[FrankHaynes]

As one who has been burned by the inability of Windows to recover properly from hibernation, I just go right ahead and shut down. Next time I need it I know I'm getting a clean boot, not some corrupted version of the OS with funky looking screen and partially working subsystems.

I assume from context that you all are describing linux, but for those coming from the Windoze world it's once bitten, twice shy.

Re: When will people wake up to the truth?

[Anonymous Coward]

Please don't play dumb, you're probably intelligent enough to understand what I mean.

RedHat controls systemd, gnome, wayland, flatpak, freedesktop, gtk+. They control the direction of the projects, they decide what functionality and code goes in or not. And they push those projects upon other distros as much as possible, trying to unify the ecosystem.

But indeed, they can't prevent anyone from using their code, but what difference does it make? You can fork systemd, except you don't have a team to help you and a company to pay you, so in practice, you can't really. And even if you can, or if you create your own init (using systemd code or not), good luck making distros use it. They don't support other inits that already exist and work, they won't support your fork, RedHat will continue to control init and more and more of the userspace.

Similarly, you can fork or use code from the kernel to make your own. Good luck doing that, and making distros use it. Or you can propose patches to the kernel, but then, like how RedHat can refuse your patches for systemd, Linus can tell you to fuck off and that your idea will never make it in linux, and he will continue to control the kernel.

Re: hibernation vs shutting down

[Zero__Kelvin]

You must have missed the fact that we are indeed talking only about Linux. Yes.

Greybeards?

[dbIII]

Greybeards?
We may have been programming for longer than Lennart but there are plenty of people younger than him that don't make the same arrogant newbie mistakes about *nix.
Somebody should give Lennart "The Cathedral and the Bazaar" to read since he missed it the first time. It's not difficult but for some reason he does not understand or care and wishes to change linux entirely.

Re: Greybeards?

[Anonymous Coward]

Greek women have bears and moustaches

Re: When will people wake up to the truth?

[gweihir]

You can fork systemd, except you don't have a team to help you and a company to pay you, so in practice, you can't really.

I do not need to. I can use sysIV init. It is finished, reliable, reasonable fast. No need for maintenance. And in the same venue, I find that packaged that need boot-scripts but do not support sysIV init are not worth using anyways.

Re: When will people wake up to the truth?

[Anonymous Coward]

You can't "Power Grab" GPL code, but I suspect you knew that before you posted that ridiculous drivel.

RedHat shill

antix & MX

[Anonymous Coward]

antiX and MX Linux are Systemd-free Debian based distributions. Latest based on Jessie. Nobody ever mentioned them. They have made a release long time ago, yet no one ever mentions them. Everyone talks about Devuan. Why ?

Re:antix & MX

[Anonymous Coward]

Devuan optimizes press communication, but puts less emphasis on technical work (so little gets done).

Re: When will people wake up to the truth?

[Anonymous Coward]

Eh, I recall reading somewhere at the time that a large portion of the Debian Technical Committee were "former" Red Hat employees. Can't find it at the moment though.

Greybeards?

[Anonymous Coward]

"The change the greybeards objected to most " Nice way to imply that most young people and women are not computer proficient.

Re: When will people wake up to the truth?

[Zero__Kelvin]

Thousands of projects do what you claim to be impractical every day actually. Maybe you have never heard of distrowatch?

Re: When will people wake up to the truth?

[Zero__Kelvin]

Lots of people who used to work for company A now work for competitor B. It is ludicrous to suggest that their loyalty lies with their former company rather than the one at which they currently work.

Apple has the same problem with launchd

[tlambert]

Apple has the same problem with launchd.

In Apple's case, the trigger messages are not entirely asynchronous, as with systemd, but they may as well be, since the Mac ports being used most frequently do not have peer information available, and are (effectively) just integers.

This leads to what I call the "on behalf of" problem.

Something starts running. And you want to know *why*. Clearly, it;s running because someone requested one or more of the services it provides -- but there's no way to know who it is running "on behalf of" to provide that service.

Say, however, you figure out that service 'C' is running "on behalf of" service 'M'.

Who is service 'M' running "on behalf of"?

In Mac OS X, it's *almost* possible to get the information as to where every thread in everything is pending a response from something else in its stack. But it's not possible to figure out the entity relationship, because you can't trace the other end of a connection.

So I can perhaps figure out that an application is pinwheeling -- that's the cursor that the display server puts up on a Mac OS X application when it's not responding to "are you alive?" chatter from the display server within it's main app loop. It happens when someone does a blocking operation in the main app loop, instead of packaging up the operation that might block, and giving it to a thread delegate instead: it means someone made a coding error, because they expected an operation to never block ...and then it blocked.

So I actually want to see where it's blocked (which I can) and see who it's trying to get work from, that's not responding to the work request -- which I can't, because I can't see "the service on the other end".

Both launchd/Mach ports, and systemd suffer from this problem.

But if I were permitted to ask the question... then I could find the next entity in the chain... and I could ask "what are you waiting on?", and follow the chain down to the actual problem.

Automatically.

The display server puts up the pinwheel, I option-click it (or whatever), and a dialog pops up and says:

MagicDraw is hung waiting for RemoteFilerPro,
which is hung waiting for access to "remote_filter_cache_file.ca",
which is hung in the kernel on a permissions check,
which is hung, waiting on DirectoryServices,
which is hung, waiting on mDNSResponder,
which is hung waiting on a network response from "VPN.bob.net",
which is hung waiting on a response from network interface "Wi-Fi2" ...which would be frigging useful. Because then I could say to myself "Oh. The VPN is down because the Wi-Fi is out. Better reset the router again."

But I can't do that.

Re:A worthy initiative - but their website is AWFU

[Anonymous Coward]

I think part of the problem of Devuan is that it's just focused on removing systemd. Because the people in favor of systemd have a lot of good points when comparing it to sysvrc. It's not as easy when the comparison is between say, daemontools and systemd.

Re: When will people wake up to the truth?

[Anonymous Coward]

You mean like Steven Elop?

Besides, people being people, they tend to not change their points of view or modous operandi very much over time. If you're once steeped in a certain way, Redhat or other, you're probably always going to tackle any problem from that angle or otherwise gravitate towards what you know. You don't necessarily have to get paid to do it, it's how people work.

Re: When will people wake up to the truth?

[Zero__Kelvin]

And that constitutes a "Power Grab" how, exactly?

Re: When will people wake up to the truth?

[unixisc]

Beyond the top 5-10, how popular are all those projects?

For all the systemd haters

[Anonymous Coward]

There are always the *BSDs

Re: When will people wake up to the truth?

[Zero__Kelvin]

Better question: "What the hell does that have to do with anything?". In fact the lack of popularity just proves that for the vast majority of people systemd is a complete non issue.

Re: When will people wake up to the truth?

[Bing Tsher E]

It's one of those things that doesn't matter to the average user until it's too big to not matter, and even then it still doesn't matter because the average user doesn't develop the software that s/he runs. The total environment just gets a little more controlled and the applications coming out just are a little more centrally directed, and Red Hat becomes the new Microsoft.

Re: When will people wake up to the truth?

[Zero__Kelvin]

You really don't realize how much of an uninformed douchebag you are to compare Red Hat to Microsoft, do you?

systemd seems like a solution in search of ....

[Anonymous Coward]

systemd still seems like a solution of in search of a problem to me. The gain for using it is non obvious. How much time is actually consumed (post boot) with systemd vs. Non-systemd for various services. I'm not impressed....

Re:systemd seems like a solution in search of ....

[Anonymous Coward]

It only looks like that because you're looking at it from your own point of view. Look at it from the point of Red Hat, and the picture becomes much clearer.

Re: When will people wake up to the truth?

[gweihir]

And in a nutshell, that is the problem. The other problem is that systemd really has some bad design-decision in there, because its creators lack experience and insight. The same is true in spades for Windows, but that does not make it fine in Linux.

Re: When will people wake up to the truth?

[Anonymous Coward]

How many of them are of a good enough quality? Of those, how many of them aren't using systemd? Most of those distros are derivatives that reuse most of the work done by their origin distro, with a few tweaks and patches here and there and some different configuration.

The one distro I know that isn't using the same init as its origin is devuan, and they apparently struggle quite a bit.

I stand by what I said and please stop playing dumb.

Re: When will people wake up to the truth?

[Zero__Kelvin]

You should probably take a hint from the competent. All the great distributions are using systemd according to you. Maybe you should take that as a clue?

Wishing for an RHEL-child minus systemd

[Anonymous Coward]

Oh! Oh! It shuts down so fast, and boot *so* fast!!!

And this is relevant to *anything* other than a laptop or some kind of mobile device *how*? My servers at work, and our workstations, and mine at home, aren't brought down except for a kernel update in a month or more. Hell, I've got a bloody HP DL560 GL5 that when you hit power on, sits there for, and I timed it, about 70 seconds before the logo ever shows up, much less its five minutes or so of initialization.

Justify a binary logfile. In any way. Or why you should move configuration files out of /etc, which was defined for configuration files. Or adding new commands which require more typing, and in a different syntax order than the old ones.

Your bloody UI? So, how's that on a headless server? And it runs *so* fast, much faster than command line I can do more with one command line while waiting for you to do the same, clicking through 15 menu selections.

Command line is *so* old fashioned, and only graybeards use it? Or shall I say that you have lousy typing skills, and don't actually want to know how to use your tools, the way a good craftsman does?

And debugging the damn this is a *royal* pain, because since you can't follow the sequence, you've got too many possible things that failed.

But, since M$ bought something like 20% of RH, and Mr. Systemd Poettering is there, trying to make Linux look like Windows, the motivation for systemd is obvious.

              mark "and I've been on slashdot since before some of you were born"

Incipinit.

[Anonymous Coward]

Freedom innit.

Choices

[Anonymous Coward]

Since supposedly the whoha is about choices, does this allow me to use systemd? :-)

Re:Choices

[Anonymous Coward]

Of course not!

Devuan implements Soviet-style freedom: you are free to choose what they want, not anything else!

Re: When will people wake up to the truth?

[Bing Tsher E]

I ran Slackware for years, and tried Red Hat at 4.3. It was fairly good. Then they released 5.0. I started using NetBSD shortly thereafter and really haven't looked back. Slackware is a good way to learn enough unix to bootstrap up into a BSD.

I don't hate Red Hat, nor do I hate Microsoft. They are both companies, with a product or two they sell.

I first ran Linux on a computer in my apartment in 1994. A '486 with a 300MB ESDI drive.

Re: When will people wake up to the truth?

[Zero__Kelvin]

If you don't hate Microsoft then you really are a clueless douchebag. Please kindly go fucking kill yourself and do the world a favor. Thank you.

Waste of resources

[Anonymous Coward]

Why do this? The whole point was to improve it, which systemd did. They could have spent this time doing something worth while, like eliminating gnome.

Re: When will people wake up to the truth?

[Anonymous Coward]

Wow ... Slashdot really has jumped the shark. Some clothes douchebag actually modded you down? I swear that the majority of those who post here are sucking Bill Gates dick so hard they can't get enough O2 to think.