Devuan Releases Beta of Systemd-Free 'Debian Fork' Base System (devuan.org)

jaromil writes: Devuan beta is released today, following up the Debian fork declaration and progress made during the past two years. Devuan now provides an alternative upgrade path to Debian, and switching is easy from both Wheezy and Jessie. From The Register: "Devuan came into being after a rebellion by a self-described 'Veteran Unix Admin collective' argued that Debian had betrayed its roots and was becoming too desktop-oriented. The item to which they objected most vigorously was the inclusion of the systemd bootloader. The rebels therefore decided to fork Debian and 'preserve Init freedom.' The group renamed itself and its distribution 'Devuan' and got work, promising a fork that looked, felt, and quacked like Debian in all regards other than imposing systemd as the default Init option."

Comments

SystemD = Bolsheviks

[Anonymous Coward]

Devuan = White Army

Re:SystemD = Bolsheviks

[WarJolt]

Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.

A beautiful thing about open source is you have the choice to go against the flow. Sometimes it pays off. Often times it doesn't. If someone stops you then fork, but I really don't see what the big deal is. Let's keep our egos in check and hopefully we can see maintainers working together even if they have slightly different methodologies.

Re:SystemD = Bolsheviks

[NotInfinitumLabs]

So, doomed to failure, then?

Re:SystemD = Bolsheviks

[Anonymous Coward]

To me, systemd is a solution looking for a problem. Ego has little to do with it; rather, trying to get shit done is what the issue is all about.

Also, systemd reminds me of the time I got soap suds up my pee-pee hole.

Re:SystemD = Bolsheviks

[Anonymous Coward]

Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together.

Found the guy that has never dealt with Debian developers.

Re:SystemD = Bolsheviks

[Ol Olsoc]

So, doomed to failure, then?

Well , as much failure as any Linux distro has. The best thing about this is it's one more solution for those who really hate systemd.

However, this dislike has a life of it's own, so I don't expect any diminishment of the complaining.

Re:SystemD = Bolsheviks

[Darinbob]

You say it's a beautiful thing to go against the flow, then tell the people who go against the flow to keep their egos in check. So are egos are a beautiful thing?

Re:SystemD = Bolsheviks

[Anonymous Coward]

The interesting thing is that, it seems that systemd developers seem more ego-centered that other FOSS developers.

Re:SystemD = Bolsheviks

[Anonymous Coward]

OpenRC and quite a few other init systems does this equally well, if not better (most importantly, with much less indeterminism).
Now what about systemd's "features" other than dependency resolution?

Re:SystemD = Bolsheviks

[buchner.johannes]

Oh the problem is there alright.

See here for example: https://www.youtube.com/watch?...

You want to replace sysvinit with something.
Now whether that is upstart, OpenRC, systemd or something else is the question.

systemd's service dependency tree and triggering is definitely attractive, and you can do some cool server configurations with it. For example, assign resources to a service, and that restriction applies to all sub-processes. Or find all processes launched by a service.

Re:SystemD = Bolsheviks

[MrKaos]

The problem was service inter-dependency in startup/shutdown was quite awkward in SysV, plus the opportunity to increase service startup/shutdown speeds by handling unrelated services in parallel.

People who have this perception aren't using inittab properly. We are yet to see a use case presented that init cannot deal with and these two are already covered. Dependancies are meant to be initialized via rc scripts and services are maintained via inittab.

People seem to be hung up on using runlevel scripts to do everything. It's this mis-use case of red hat's runlevel scripting system that is being used as an excuse to replace initd with systemd. It's pretty reasonable for people to be skeptical about these efforts to replace initd when the issue is not functionality but education.

I sometimes wonder if their is a perception issue with the use of inittab files, like the server will explode if you do something wrong in an inittab script. However it's quite simple once you get you head around three key things:

Use a combination of run level scripts and scripts executed from inittab to acheive a system configuration. Runlevels are available to inittab entries when the rc scripts complete or execute in the background. Make sure your inittab shell scripts don't exit if your service is running properly.

That's pretty much all you need to remember to create very powerful and elegant patterns to manage the activities of any *ix system.

Re:SystemD = Bolsheviks

[RabidReindeer]

The problem with systemd isn't its replacement for scripts.

Well, kind of it is, since they arrogantly didn't bother to provide any way of getting certain things done that scripts were doing, but that's only where the outrage begins.

The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.

Re:SystemD = Bolsheviks

[Anonymous Coward]

that should be the case
unfortunetely systemd is way more then just an init system these days
it's deliberately attempting to get reimplement and get tightly coupled to everything under the sun

Re:SystemD = Bolsheviks

[Barsteward]

"systemd is a solution looking for a problem." - if that was the case, it would have withered and died.

Re:SystemD = Bolsheviks

[Barsteward]

There is a very small percentage of cases where systemd cannot make use of the scripts. You could check here to see if any of your problems are listed https://www.freedesktop.org/wi... Logging is one of the fantastic bits about systemd, its far more comprehensive than anything else. Its just a matter of learning about the new features and tools.

Re:SystemD = Bolsheviks

[Anonymous Coward]

If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.

The Devuan guys didn't even try that. It's mostly an ego thing for them.

Re:SystemD = Bolsheviks

[Anonymous Coward]

Logging is one of the fantastic bits about systemd, its far more comprehensive than anything else. Its just a matter of learning about the new features and tools.

In other words, "... the worst part of systemd by far is the insane binary logging crap, and I would not be surprised if you have scrogged logs. Quite frankly, everything else in systemd at least has an _excuse_ for it. The binary logging is a pile of unadulterated shit."?

Re:SystemD = Bolsheviks

[thegarbz]

Except for its ability to happily hand over to scripts, it's ability to happily log to a syslog daemon, and happily hand over networking, NTP, and all other functions to another system of your choice.

Key word "choice". Configure it how you want to. This may require you to read a manual or do a Google search but that's hardly a new thing in Linux.

Re:SystemD = Bolsheviks

[Anonymous Coward]

I currently have an issue on a Fedora 23 install where journalctl will only log kernel messages after ~6s. Basically if i don't write a bash script to dump dmesg after every boot I'm losing this information. I've tried everything I could think of, default journald settings, setting the logging level to DEBUG for everything, removing my journal. Nothing worked.

dmesg shows all the kernel messages, /dev/kmsg shows the early portion of the boot process but it also lacks everything after 0.00 seconds. I've looked at every bugzilla under the sun, either I'm the only person on the planet with this issue or nobody cares enough to report it.

Re:SystemD = Bolsheviks

[Sique]

The problem comes with hot plugging devices. Depending on the device you plug in, you have to start different services to serve them, and you should correctly stop them when the device is unplugged. While for a single device, this is no problem, it totally screws up the original init concept where each runlevel means a predefined set of services running, and each combination of hot plugging devices would mean a new init runlevel. With 10 different devices, you would already be at 11! = 39916800 different runlevels, depending on the sequence you plug them in.

So either you get a new hotplug environment within runlevel 5, which then handles all the temporarily running services, or you just accept that the hotplug environment does nothing else than init (starting and stopping services depending on a set of constraints), just in a more flexible and granular manner, and init with runlevels 1, 2, 3 and 5 is just a special case of the hotplug environment, which just duplicates the functionality of the hot plugging environment in a more clumsy and less flexible manner.

Re:SystemD = Bolsheviks

[Anonymous Coward]

“..At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way -and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.” – C.A.R. Hoare

Re:SystemD = Bolsheviks

[Anonymous Coward]

Yeah, so comprehensive it will barf all over kmesg if journald is for some reason down...

Re:SystemD = Bolsheviks

[0100010001010011]

And LaunchD

Re:SystemD = Bolsheviks

[mvdwege]

systemd logs perfectly fine to rsyslog. Stop acting like a parrot by repeating FUD.

Re:SystemD = Bolsheviks

[squiggleslash]

systemd is about getting stuff done. sysvinit basically became obsolete around 20-25 years ago, at around the time network services became a thing and when security required more than just deciding who could log into your box from a network you largely controlled.

I've had to recover too many boxes using boot CDs because a faulty network card has prevented some resource from starting that the existing sysvinit scripts rely upon causing sysvinit to just hang to think sysvinit is the utopian ideal systemd opponents portray it as. And, before anyone mentions the various rivals, most don't solve the same problems, and none support Linux's security model. Starting services in boxes using cgroups, for example, which ought to be the default for any network facing service, requires manual hacking together of shell scripts to create something that can't easily be managed by a centralized service manager.

systemd is a good idea. It's not perfect, but judging by the fact its opponents insist on using "faults" that are misleading, minor, or irrelevant, I don't think we're likely to get anything better than systemd for a very long time.

Re:SystemD = Bolsheviks

[Anonymous Coward]

I'm curious. What sort of devices are you hot-plugging that each involve a system-level "service" being started or stopped automatically?

Re:SystemD = Bolsheviks

[sjames]

Servers sitting in a light's out facility rarely have things plugged ind unplugged.

The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening.

Poof, no controversy, no objections.

Re:SystemD = Bolsheviks

[MrKaos]

initd starts the event manager in that use case.

Re:SystemD = Bolsheviks

[Peter H.S.]

Systemd scripts and other init scripts can coexist peacefully in the same package, so I don't see why maintainers can't work together. If there is a willing team of people who want to maintain these scripts I see no reason why the Debian team should stop them.

The problem isn't the init-scripts, the problem is supporting two different init-systems at the same time, including replicating and fixing bugs.
That is why Devuan is removing systemd from their Debian fork, even though Debian Jessie at present can support both SysVinit and systemd.

Re:SystemD = Bolsheviks

[Peter H.S.]

The problem with systemd is that it doesn't want to coexist peacefully. It wants to own everything. Not just resource control, but logging and other things as well.

I don't think you have actually studied the design of systemd; it is exactly designed to co-exist peacefully with other components. It is a major reason why it was adopted so successfully and fast:
You can use any syslog daemon like Rsyslog or syslog-ng with systemd's journald.
You can use you own homegrown resource manager using cgroups instead of systemd's. systemd uses cgroups for two things; tracking and grouping services, and resource control. But the latter use is entirely optional and you can compile systemd without such support.

Really, people are so misinformed about systemd. It is like they never even read a systemd man-page, but just uncritically iterate whatever some random blog guy once wrote.

Re:SystemD = Bolsheviks

[Sique]

But why keeping init, if a system is in place anyway that does the same thing as init, just with more control and much higher flexibility? It doesn't have to be systemd, but if you want to be able to reconfigure on the fly without rebooting the whole system, you need something more versatile than a few runlevels. For instance, systems that power parts of the hardware down if not needed to save power would need something more granular than init 3 vs. init 5.

Re:SystemD = Bolsheviks

[Sique]

And if the system in case has several power save modes, does then the event manager power down services whose hardware was just put to sleep? And if so, how does init react of some services it has started, are shut down without init's involvement? Or should those services should be started from the event manager instead of init? And what's the point of init, if most services are started by the event manager anyway, because otherwise, the event manager could not manage them?

Re:SystemD = Bolsheviks

[Anonymous Coward]

Every choice but the choice not to install it.

Re:SystemD = Bolsheviks

[sjames]

Just stuff that into the event handler and let it be responsible for it. That's the beauty of such a modular system, it's versatile. The new parts can come in early, late, or not at all depending on need. There can even be more than one so they can specialize in subsystems or special cases.

I am not in principle opposed to a replacement init so long as it plays well with others, but I would need a compelling reason to do it that couldn't be otherwise accomplished

Re:SystemD = Bolsheviks

[Eunuchswear]

It's not perfect, but judging by the fact its opponents insist on using "faults" that are misleading, minor, or irrelevant

This, a thousand times this. I gave up worrying about systemd when I noticed that most of the anti-systemd campaigners spanned the spectrum from exageration, via lying, to insanity.

Re:SystemD = Bolsheviks

[Eunuchswear]

Bug report?

Re:SystemD = Bolsheviks

[Eunuchswear]

Sorry? You can run Debian without systemd.

Just try running Devuan with it.

So much for "init system freedom".

Re:SystemD = Bolsheviks

[MrKaos]

And if the system in case has several power save modes, does then the event manager power down services whose hardware was just put to sleep?

No. An event manager (or controller) should reconfigure the service via inittab and signal init to change that service's state because init is a *process* manager for system processes.

And if so, how does init react of some services it has started, are shut down without init's involvement?

It restarts them, as it should. init should be responsible for maintaining system services that require root permissions. An event manager is a good candidate because

Or should those services should be started from the event manager instead of init?

user level services that terminate at the end of their sessions should be managed by an application controller that interacts with the event controller.

And what's the point of init, if most services are started by the event manager anyway, because otherwise, the event manager could not manage them?

It should be managing events and not processes. It should be passing messages about them to various processes that perform the reaction. It should not even capture them, that functionality should be abstracted into an input or device controller that generates messages for the EM.

Re:SystemD = Bolsheviks

[inode_buddha]

"The whole controversy could have been avoided if systemd was properly designed as a plug-in component. System starts up under the old init. At some point (after the basic system has been brought up), an rc script or inittab starts systemd (a series of event listeners) to deal with hot-plugging and such. Make sure it doesn't block others from listening."

Just like inetd has been doing since time began. Borrowing a few tricks from years past, there is absolutely no reason why inetd needs to be used *only* for starting inet servers. Inetd can be used to start and manage anything. Most folks just don't get that creative with their systems -- I sure don't! I saw that trick in an O'Reilly book yrs ago.

So, to make your point even stronger, the capability that you speak of has already been around for decades. But nobody actually seems to play with it.

Re:SystemD = Bolsheviks

[sjames]

That's a good point, and it's even event driven. I haven't done much with it in a long time but it demonstrates how to add event driven behavior and still play nicely.

Re:SystemD = Bolsheviks

[thegarbz]

Huh? Are you agreeing with me or trying to say that I'm not running my system the way I'm running it which is that EVERYTHING is logged to rsyslog in text including things that weren't possible before?

Re:SystemD = Bolsheviks

[thegarbz]

http://www.without-systemd.org... I count 64 distributions* without systemd. Install one of those. Oh you want to run without systemd on another distribution? Then why not become a senior maintainer and actually get your voice heard in discussions on where the distribution should head or better still fork it and run it the way you want.

*I'm on a bouncy train so make that 64 +/- 5 for difficulty in counting.

Re:SystemD = Bolsheviks

[thegarbz]

We are yet to see a use case presented that init cannot deal with and these two are already covered.

Then you're not looking. Especially not looking at the whole host of tools that exist to implement functionality that sysvinit doesn't allow.

Sysvinit wasn't replaced for shits and giggles, and systemd is far from the first package that tried to do more to handle all those use cases that sysvinit doesn't allow.

Re:SystemD = Bolsheviks

[thegarbz]

There were already programs that did exactly as you describe.

Systemd offered more functionality by taking control earlier in the boot process. e.g. logging before the syslog daemon is even up and running as PID1.

The only problem with systemd is that Debian moved to it and that hurt everyone's feelings. Debian was forked and now there's an alternative. People didn't migrate servers en-mass to BSD, the world kept spinning, and I am told the sun will rise tomorrow just like it did yesterday, despite what people said when Debian initially announced they are moving to systemd.

Linux is about choice. Not your choice, but the choice what the developers present to you. Pick a distro that suits your needs and you'll be just fine.

Re:SystemD = Bolsheviks

[sjames]

Many chose to stick where they were to give time to find an option. CentOS/RHEL 6 are still in support as is Wheezy. Many saw that while systemd can't be totally stripped from (Debian) Jessie, it can be stubbed out for a server or if you switch to XFCE. Of course, Slack and Gentoo are options.

So the tale won't be told at least until Wheezy and Centos 6 go EOL. The final chapter won't be written until Debian Jessie goes EOL.

Re: SystemD = Bolsheviks

[Anonymous Coward]

Don't you even care enough to report it?

BTW, moaning on /. does not count as a bug report.

Re: SystemD = Bolsheviks

[Anonymous Coward]

He doesn't because it would probably be futile, and alerting others of bugs that would eventually be labelled as NOTABUG / WONTFIX certainly helps them avoid the crapware and its developers.

Re: SystemD = Bolsheviks

[Anonymous Coward]

Well, this is a very good website (without-systemd.org):

* Controlling nightmares

Restarting samba in sysvinit:

root@xxx:~# /etc/init.d/samba restart
[ ok ] Stopping NetBIOS name server: nmbd.
[ ok ] Starting NetBIOS name server: nmbd.
[ ok ] Stopping SMB/CIFS daemon: smbd.
[ ok ] Starting SMB/CIFS daemon: smbd.
[ ok ] Stopping Samba AD DC daemon: samba.

Restarting samba in systemd:

root@xxx:~# service samba restart
Failed to restart samba.service: Unit samba.service is masked.
root@xxx:~# service samba stop
root@xxx:~# service samba start
Failed to start samba.service: Unit samba.service is masked.

Oooo look, SystemD cannot (re)start a [masked] service!!!1!!1!!1

fucking idiots

Re:SystemD = Bolsheviks

[Anonymous Coward]

This site is full of shit.

Re:SystemD = Bolsheviks

[mvdwege]

Sorry, I misread your post for sarcasm, implying that systemd did not log to syslog.

Re:SystemD = Bolsheviks

[thegarbz]

hahaha. You can never tell the FUD from the sarcasm in a systemd debate. It's much easier having a discussion on religion on here :-)

In Other News: People Hate Change

[Olipro]

I'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.

What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.

The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.

Re: In Other News: People Hate Change

[Anonymous Coward]

Nobody is against systemd just because it's change. People are against systemd because it is change that causes them many problems, including computers that don't boot.

Re:In Other News: People Hate Change

[inode_buddha]

Seriously, who cares how fast it boots? Unless you're on some tablet type device I see no reason why boot speed should even be a thing. The old initscripts are plenty fast enough for my laptop even.

The issue that I have with Lennarts work is that it goes completely against the design philosophy of *nix that made it so great in the first place. It also broke a bunch of stuff that relied on the old behavior - a big no-no and an instant turn-off.

Re:In Other News: People Hate Change

[Anonymous Coward]

What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.

The same could be said about runit/perp/nosh/s6, with the additional benefit of non-intrusiveness, much smaller memory and disk footprint, debug-ability, and reliability :)

Re: In Other News: People Hate Change

[FrankHaynes]

You must mean computers that don't boot because the people who configured them couldn't bother themselves to read the f@cking manual and follow instructions.

I did it and I'm no genius. You can too.

Re: In Other News: People Hate Change

[the_povinator]

Our Linus,
Who art in Portland, OR
Hallowed by thy name...
deliver us from systemd
For thine is the kernel
The power and the glory
Forever and ever
Amen

Re: In Other News: People Hate Change

[i.r.id10t]

Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"

But then I chilled out 'cause it seems Debian is configured to double log, ot the same old comfortable places it has always logged in plain text.

Emergency over.

Re:In Other News: People Hate Change

[somenickname]

What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.

The init capabilities of systemd aren't too bad. The "scripts" look pretty similar to many other init system alternatives and, for basic stuff, are fine. The problem is that systemd isn't an init system anymore. It has become a layer between the kernel and traditional userspace. *That* is why people hate it. Basically, RedHat has gained too much control over the Linux ecosystem and so has started ramming their agenda down the throats of all Linux users. If the systemd/PulseAudio/etc abominations were just confined to RedHat, no one would even vaguely care (except RedHat users). But, it's become increasingly difficult to avoid the garbage coming out of RedHat because, as I stated before, they have gained too much control and influence over Linux.

Re:In Other News: People Hate Change

[Anonymous Coward]

The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing. Fortunately, it doesn't bar me from running a post-network-up script to do command-line based route installation, so until it develops that functionality, that's what I'm doing.

Linus is challenging you:
> the worst part of systemd by far is the insane binary logging crap, and I would not be surprised if you have scrogged logs. Quite frankly, everything else in systemd at least has an _excuse_ for it. The binary logging is a pile of unadulterated shit.

Re: In Other News: People Hate Change

[Anonymous Coward]

Or alternatively, after the sysadmin dived into the voluminous systemd documentation and still cannot get systemd to fulfil the machine's requirement?
It must be runit's fault to never have this problem, while being equally powerful, much more configurable and much less intrusive.

Re:In Other News: People Hate Change

[Anonymous Coward]

Just wait until you have a problem that isn't logged in the journal despite being a clear error message to stderr if you run the command by hand. That makes it very hard to troubleshoot start-up problems with systemd.

Re: In Other News: People Hate Change

[Anonymous Coward]

Every time I do an update (One that updates the kernel) the system comes up with a screen that says "OOPS something went wrong!"

What kind of a f**king error message is that? No logging of what the problem was, not indication as to what went wrong, just "OOPS something went wrong!"

I expect that kind of crap out of windows, I do not expect it out of Linux. I spent a full day tracking down the problem. Seems the vendor provided driver for the video card did not load. Once I tracked it down it was just a matter of downloading the current driver and updating it. Normally, I would have a log or something that indicated the driver did not load, but in systemd I get a f**king "OOPS something went wrong!"

Re: In Other News: People Hate Change

[slazzy]

My logs got scrogged

Re: In Other News: People Hate Change

[Anonymous Coward]

Hey look, another "systemd horror story" with no distro, no release, no hardware specifics and no bug#
0/8, lrn2troll.

Re:In Other News: People Hate Change

[Gravis Zero]

The only place where I feel it falls somewhat short is in systemd-networkd which currently lacks good support for policy routing.

no, that's the only place that you have seen it fall short, there is a difference. i'd go on to list all the ways it falls short but it would only fall on deaf ears.

Re: In Other News: People Hate Change

[donaldm]

Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"

But then I chilled out 'cause it seems Debian is configured to double log, ot the same old comfortable places it has always logged in plain text.

Emergency over.

Err what do you call utmp and wtmp since they have been around in Unix since pretty much, well forever.

You have obviously not played with AIX which is a real Unix system and actually uses a database for administration purposes. Try any of the other Unix systems and they all have different flavours although there is allot of similarity.

As for Linux not being Unix. Well it isn't although it does have the look and feel of a Unix system. Oh and what do you call a text file? Strictly speaking it is a binary with a specific structure and can only be read with tools that can read that type of file.

Basically Linux and also Unix do change over time. If you want to call yourself a professional get over it.

Re: In Other News: People Hate Change

[Anonymous Coward]

What are bug report good for if the developers simply close them as NOTABUG and WONTFIX?

Re: In Other News: People Hate Change

[Anonymous Coward]

Some of the unit files redirect stderr to /dev/null. It is annoying.

Re: In Other News: People Hate Change

[donaldm]

What are bug report good for if the developers simply close them as NOTABUG and WONTFIX?

And what use is winging if you won't give out information that can help developers fix the problem.

Re: In Other News: People Hate Change

[Anonymous Coward]

Certainly useful in warning other users or user wannabes, if giving out helpful information is repeatedly shown to be futile.

Re:In Other News: People Hate Change

[cas2000]

yep.

systemd's init functionality is fine, as good as (or better than) most other alternatives.

it even makes sense to have the control group manager as part of the init process (although even that should be optional if someone wants to run something else to manage control groups).

absolutely everything else that systemd does, though, (network setup, logging, crappy cron imitation, consolekit login services, etc etc etc) should be entirely separate, completely optional programs with good documentation (incl. API and protocol docs).

if systemd confined itself to just init services, nobody would bother hating it because there would be nothing to hate - it would be just one init option amongst many. probably a very popular option because, as init, it's pretty good.

Re: In Other News: People Hate Change

[Anonymous Coward]

Oh and what do you call a text file? Strictly speaking it is a binary with a specific structure and can only be read with tools that can read that type of file.

Tools such as the human brain?

Re:In Other News: People Hate Change

[Anonymous Coward]

The whole thing runs a lot lighter in memory too. Does this mean there is quite a bit of capability missing?

Re: In Other News: People Hate Change

[Ol Olsoc]

Hey look, another "systemd horror story" with no distro, no release, no hardware specifics and no bug# 0/8, lrn2troll.

This should be modded up. Meanwhile, I have installed and used Ubuntu and Mint, and Lubuntu and and UMate and Xubuntu on a lot of computers (I didn't keep count) with only one problerm - which turned out to be a dd bug that was fixed in a couple days.

Including my latest personal project, a Raspberry Pi that I'm on right now, with Ubuntu Mate running happily, systemd and all.

Re:In Other News: People Hate Change

[sjames]

So you learned to do the easiest part and called good. 'grats. Now, consider my use case. I build a btrfs using RAID1 in a VM. I dettached one of the virtual drives to test things and rebooted the VM. Systemd dumped me to an emergency shell with the network down. Try as I might, even digging through the 100 or more low level config files kept under the rug I could see no way to show systemd the error of it's ways. And yes, I specified mount option degraded on the kernel command line and fstab, but systemd ignored it. All it knew is that it was prepared to wait forever for that no longer connected disk to come online and was not going to be made to see reason.

Naturally, I hit up google. Turns out many people had a similar problem with RAID1 volumes as root. No solution there, even from LP. Furthermore, the devs were stumped as to an approach to fix the problem. They considered it intractable and so WONTFIX. It never did get fixed as far as I can tell. The best solution on offer is to use SCRIPTING in the initfs to mount the RAID volume before systemd gets to run. Yes, SCRIPTING.

THAT is why I object to systemd. It's just too damned easy to find something is simply won't do as soon as you use a system in any manner that LP doesn't. I guess he doesn't do much with servers.

Now, if they would just keep their fingers out of all the pies I wouldn't care. You can use systemd and I'll stick to scripts. Alas, they insist on sticking their fingers in every pie through a pernicious knot of dependencies. For a while it seemed that the stronger the objections, the more things became dependent on it. That's why it took Devuan so long to purge it from Jessie.

Very ugly.

Re: In Other News: People Hate Change

[Anonymous Coward]

Glad that you admit you do not care about corner cases.
However, if systemd was just an init system and no more, why would there would be so many corner cases?

Re:In Other News: People Hate Change

[Wyzard]

The best solution on offer is to use SCRIPTING in the initfs to mount the RAID volume before systemd gets to run. Yes, SCRIPTING.

You can use systemd and I'll stick to scripts.

Just not in your initramfs, I guess?

Really, though, distros use sophisticated scripts in initramfs anyway, which should handle this sort of thing. Mounting the root filesystem is initramfs's job, not /sbin/init's. My root filesystem is on LVM on top of dm-crypt on top of bcache on top of RAID1, and Debian makes it work just by running "update-initramfs -u" -- which happens automatically whenever a kernel package is installed or upgraded. What you're describing sounds like more of a distro thing than a systemd thing.

Re:In Other News: People Hate Change

[Anonymous Coward]

Any chance you could link the bug? I searched (admittedly no more than 5 or 6 minutes) - I see bugs for this marked as wontfix but only because the OS release they were reported against were superceded. Searching "raid1" on SystemD's bug tracker brings up only this one: https://github.com/systemd/sys... ... and it's not for the issue you described. Do you happen to recall around when you encountered this bug?

Re:In Other News: People Hate Change

[Anonymous Coward]

So systemd developers made a half-baked mouting subsystem because they can, but did not add decent raid/lvm support because they can't, though this wouldn't even be an issue if they just keep away from the way of mounting?
Now you realize they do something with systemd because "they can" instead of "doing that is technical correct"? In other words, if budget permits, they can integrate the kernel into systemd, and let us happily end up with ntoskrnl + svchost?

Re:In Other News: People Hate Change

[sjames]

Here's one of a few discussions

Also google on: systemd degraded btrfs

The hell of it is that once it dropped to the emergency shell, simply entering the needed mount command by hand mounted it right up. Had it been a script based system, I could just stuff the mount command in as an imperitive and moved on to the next issue.

This is interesting. How about issue the mount command? If it is complete enough to succeed then it will succeed. Otherwise it will fail. That was obvious enough that SysV init got it right. Note how "let the admin decide" wasn't apparently even a consideration.

Since that wasn't the only issue, I found a way to mostly defang systemd in Jessie (Debian) so I left it at that. I fave the Devuan beta downloading now. I may very well go that route.

Re:In Other News: People Hate Change

[sjames]

You know systemd was supposed to run in the initramfs, right?

Since scripts made it easy and systemd made it hard, I'd say scripts win. I have enough to do without handicapping myself.

Re:In Other News: People Hate Change

[Anonymous Coward]

What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is. My systemd machines are ready to go much faster than any bash-script based init system and writing a new unit file for some daemon that lacks one already is easy peasy.

Let me share some wealth of knowledge with you about systemd in the real world. I urge you (and anyone else) "not having a problem" with systemd to please read this actual bug (which a colleague of mine has experienced on bare-metal systems running Debian). Respectfully, read all the replies (there aren't that many). This bug contains a gold mine of insights (into thought processes, beliefs, and actual usability concerns) that should make any worthwhile systems administrator (or developer, for that matter) start shake uncontrollably followed by an outburst of "Are you fucking kidding me?!?!"

Now ask yourself if this is really what you want re-inventing and controlling everything. If you choose "yes", that's OK (really!), but I choose "no".

Re: In Other News: People Hate Change

[Anonymous Coward]

> Nobody is against systemd just because it's change

nobody? I would make that 'not everybody'.

Re: In Other News: People Hate Change

[Anonymous Coward]

While a dedicated person could indeed read ASCII text in binary or hex form, *all* data is stored on the medium as binary. It's all computers understand. A program (be it `less`, `vim`, `cat`, whatever) still has to know how to deal with ASCII text at a minimum to read a text file. Thankfully, most libcs provide good support for that and make it easy to implement. So much so that text is considered the universal interface in *nix land.

Re:In Other News: People Hate Change

[Anonymous Coward]

> What I will say, however, is that after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is

It's not the init management, which was done better and much more cleanly in user space by "daemontools", written by Dan J. Bernsteain and published over 15 years. The problem is its relentless attempt to incorporate every other part of system configuration, such as DHCP, system logging, and automounting, and to deliberately throw out existing standards with *every single expansion*. Let's embed initialization and system logging in the kernel!!! Let's make the logs *binary*, for petes's sake!!

None of those changes were part of initialization management, and they all required extensive re-engineering of entire suites of software and tools. and *none* of them work on anything but Linux, because of the systemd kernel requirements. It is vendor lockin on a *ridiculous* scale.

Re:In Other News: People Hate Change

[Anonymous Coward]

People hate change for the sake of change. Particularly when the change breaks (and refuses to support) existing use cases.

But lets just keep going with this childish "These people just hate change" label/narrative that is always rolled out, it's much easier than addressing the points raised.

Re: In Other News: People Hate Change

[RabidReindeer]

Oh and what do you call a text file? Strictly speaking it is a binary with a specific structure and can only be read with tools that can read that type of file.

Of which there are vastly more for plain ASCII text. In fact, Unix/Linux is famous for them. And people can read, search, and manipulate them under foreign OS's using tools common to those OS's.

Also, you don't have as much breakage with text files as you do with binary files. A binary file can become effectively unreadable very easily even on its native OS if a new OS version with a new file format comes out. A text file can be streamed straight to the hardware on virtually any printer.

It's also much, much easier to recover fragments of a broken text file than it is for a broken binary file. Something that's very valuable when a system is damaged and you need all the information you can get as fast as you can get it.

Re:In Other News: People Hate Change

[mvdwege]

Turns out many people had a similar problem with RAID1 volumes as root. No solution there, even from LP. Furthermore, the devs were stumped as to an approach to fix the problem. They considered it intractable and so WONTFIX.

Since the last time you whined about Lennart not fixing bugs you were lying, you wouldn't mind backing this up with a link, now would you?

Re: In Other News: People Hate Change

[Anonymous Coward]

to read the f@cking manual and follow instructions.

The f@cking official stance on interrupting a several hour long fscheck on startup is a) a balant lie about that being unsafe , b) a waterfall of shit containing the word "vision" and c) the claim that you should not depend on filesystems using fscheck in the first place. So going by the manual I either have to spend several days reformating and reinstalling every system I manage or risk getting blocked by fscheck kicking in at an inconvenient time. All because systemd is apparently badly enough designed that it apparently cannot forward the interrupt to fscheck.

Re:In Other News: People Hate Change

[marcello_dl]

> after spending the time reading up on systemd and learning how to use it, how to write unit files and all that jazz, I really fail to understand what the furore over it is

Spending time to learn doing the same things in another way for marginal gains is never a good sign. Systemd, gnome, kde devs got their share of flames for that, and they are deserved.
Windows devs are so used to that they do not even realize it happens.

Re:In Other News: People Hate Change

[Anonymous Coward]

systemd's init functionality is fine, as good as (or better than) most other alternatives.

Yeah totally.

Posting from my Windows 7 machine, since my Debian system is stuck on its monthly, no longer interruptible, fcheck.

Re: In Other News: People Hate Change

[Anonymous Coward]

Computers that don't boot? Never seen those. Did you break something?

Re: In Other News: People Hate Change

[Barsteward]

yawn... thats a dead troll argument

Re: In Other News: People Hate Change

[Barsteward]

that has been the case for all distros, you were able to forward logs to syslog and rsyslog, it just needed a config. but now syslog does its own extraction from the journal.

Re: In Other News: People Hate Change

[Barsteward]

whether a file is text or binary you still need a tool to read it so its a meaningless argument.

Re:In Other News: People Hate Change

[Barsteward]

its targeted more at VMs etc that get torn down and restarted many times a day when speed is needed, its just a nice feature for the rest of us which you may or may not see as a benefit.

Re: In Other News: People Hate Change

[Barsteward]

perhaps you and the poster above should RTFM, its generally all down to configuration. this might help http://www.kibinlabs.com/syste...

Re:In Other News: People Hate Change

[AmiMoJo]

While you might not care about faster boot times, clearly many people do. PC manufacturers and Microsoft have been improving boot times for years now, with UEFI and Windows 8 really speeding things up. Personally I like that my laptop goes from off to ready to use in 4 seconds.

And stuff breaks because it relies on specific, unspecified behaviour? Sounds to me like that stuff is broken, not systemd. In any case, the logical thing seems to be to fix the broken stuff so that it is more reliable and more compatible.

Re: In Other News: People Hate Change

[dinfinity]

Unless you can convert your binary to a stream of text, forget grepping it or doing any of the transformations everybody with a modicum of experience of *nix is very familiar with.

On the commandline, binary files are going to require a custom built interface for that specific type of binary. That custom built interface needs to have all the features you want for easy searching etc.: no regular expression search built-in? Then forget about it. If you're lucky, there is another tool that understands your specific binary flavour which may or may not do what you want.
A text file does not have those problems because it can be interpreted using a standard that is ridiculously simple, old as dirt and supported by and ingrained in pretty much fucking everything that displays letters.

I'm not saying a binary format cannot have its advantages (databases obviously have many), but to dismiss the difference between binaries and text files with 'you still need a tool to read them' is absolutely fucking idiotic.

Re: In Other News: People Hate Change

[Anonymous Coward]

More than 10000 tools can be used to process plain text, but very few tools can read systemd's binary log, so this is more than meaningful. Otherwise, in a line of reasoning similar to yours, "whether source code is published or not, you can still get an idea of how it runs by looking at the code, assembly or source, so free software is pointless".

Re: In Other News: People Hate Change

[Anonymous Coward]

That is another design flaw with systemd: is there any technical argument for mandating the journald roundabout for system logs?

Re:In Other News: People Hate Change

[Anonymous Coward]

Wheres the instructions / documentation, and have they been updated to reflect this weeks syntax change?

Re:In Other News: People Hate Change

[Anonymous Coward]

Precisely. Redhat needed it, and thus they campaigned to force feed it down through your throat.

Re:In Other News: People Hate Change

[inode_buddha]

The specific unspecified behavior is called text logging to stderr which has been around for *decades* aong other trhings. Yeah I suppose I could rewrite ~15 yrs worth of scripts to check for an exit status of 127, but that still doesn't give me a *reason* why it tanked. Which night be real handy for an if-then-else situation. So yes, the point stands.

Re:In Other News: People Hate Change

[inode_buddha]

This is one of the main things that bugs me so much. You could have systemd and emacs for a complete desktop solutuion.

Re: In Other News: People Hate Change

[Anonymous Coward]

No, the systemd has broken existing systems just by introducing a update. On my Debian machines this has happened at least twice.

Re:In Other News: People Hate Change

[inode_buddha]

Maybe if the VM is being used for dev work, but not for a server or a desktop. The way I learned *nix is, if you have to reboot more than 1x or 2x a year, yer doing it wrong.

Re: In Other News: People Hate Change

[Anonymous Coward]

So before I do a dist upgrade on my Debian Wheezy, (which has worked for years on Debian since version 5 netinstall i originally used).
I need to RTFM to check if my system will boot at all? In fact I did that and there was no mention of SystemD potentially leaving my system in an unusable state. I backed up, and did the upgrade. It mucks about installing systemd replaces my init system then refuses to boot.
I ask for help on debian forums and get responses like you should have RTFM. My response is you shouldn't enforce an upgrade that could potentially fail to boot with no warning.

Right so roll back to the backup.
Spend ten minutes reading about systemd and what could possibly stopped the boot. Perhaps something in the logs might tell me why. Oh now I need to try a whole new load of commands to read the logs! Decide not to bother and stay with Wheezy till Devuan beta is available and try that.

Systemd may be wonnderful the imposition of it, is most definitely not.

The whole debate before the devuan fork was to keep sysvinit as default and upgrade to systemd if people wanted, to try to keep debian boot-system agnostic. This was decided against and left some people blindly doing dist-upgrades because the new version is out and having problems.

Attempts to work in parallel with Debian were refused BY DEBIAN. Hence the fork.

Re:In Other News: People Hate Change

[Anonymous Coward]

Maybe if the VM is being used for dev work, but not for a server or a desktop.

We use Auto-Scaling for several different platforms in AWS. Servers get torn down and booted up, all the time, based on actual traffic and load.

This saves us boatloads of money by not having to have too much spare capacity (and pay for it) when we don't actually need it.

Fast boot-times matter a great deal for us in the server-context, so that our platform can adapt quickly, which it does.

The way I learned *nix is, if you have to reboot more than 1x or 2x a year, yer doing it wrong.

That's the way I learned it as well. That was more than 20 years ago. Things change.

Re:In Other News: People Hate Change

[s4m7]

I'm not going to bother saying anything about Lennart or other core systemd developers since it's been widely established that they have proven to be disagreeable on numerous occasions.

Yeah, why can't they be professional, courteous and agreeable at all times like other prominent linux developers?

Re:In Other News: People Hate Change

[s4m7]

Seriously, who cares how fast it boots?

People who pay for your time by the hour.

Re:In Other News: People Hate Change

[Anonymous Coward]

I heard in an interview once where Lennart Pottering say that the goal of systemd was to "own everything between the kernel and the application layer." I believe he said this when he was interviewed by Chris Fisher on the Linux Action Show.

This is also my problem with systemd...That and the fact that so many distributions are including it by default, not giving users a choice. The only major distros that don't include it are Slackware, Gentoo, and Devuan. And I can see in the future, systemd forcing a kernel change where these distributions will have to adopt or die.

Currently, the only port in this storm is BSD. Of course, Lennart claims that BSD "isn't relevant anymore" and kFreeBSD is "a toy OS" apparently because they don't implement systemd, putting them out of his reach.

Re:In Other News: People Hate Change

[gweihir]

Naaa, that would be solid engineering, as opposed to anything Poettering can do. This person must not even have heard of KISS or he is to stupid to recognize what it means and why it is at the core of solid engineering.

Re: In Other News: People Hate Change

[Barsteward]

its only roundabout if you insist on still using syslog instead of journalctl output so thats your decision to make.

Re: In Other News: People Hate Change

[Barsteward]

You might think its idiotic, i see it as being accurate. Every single way you read or inspect a file, it is done by using a tool whether it be 'cat' or 'grep' or journalctl. What you can do with journalctl and a few parameters, you'll need a lot of coding and testing to generate the same output via the "old" way. You can also pipe the text output from journalctl to any text parser you like.

Re:In Other News: People Hate Change

[Anonymous Coward]

Cloud.. The custommer might want to spin up 500 new VMs to do some tasks. The VMs finish their tasks and shutdown again.
More and more applications use cloud and orchestrating in such way. Containers is also often used in minimal OS installations inside a VM. Example http://www.projectatomic.io/

Re:In Other News: People Hate Change

[Barsteward]

everybody who runs those types of systems needed it and thats why they all use it and contribute to it, not just Red Hat.

Re:In Other News: People Hate Change

[Barsteward]

i think you need to get out more and see whats out in there beyond your scope of server use.

Re: In Other News: People Hate Change

[Anonymous Coward]

Which is irrelevant to the question about technical merits of journald. And I see nothing but crap in journald.

Re: In Other News: People Hate Change

[Anonymous Coward]

you'll need a lot of coding and testing to generate the same output via the "old" way.

Any competent Unix system administrator can achieve much more than what journalctl can do with combination of several simple commands.
Maybe by "you" you mean just yourself?

Re: In Other News: People Hate Change

[Barsteward]

if you follow that lkml, they are discussing a patch, read a little further in the thread. "This is on Debian testing, with sysvinit and a systemd-shim to allow other parts to work." - i ignored the other 2 links as unverifiable anecdotes.

Re:In Other News: People Hate Change

[Anonymous Coward]

Fast boot time? Yes.
Lots of arbitrary corner cases? No.
Runit? Yes.
Systemd? No.

Re: In Other News: People Hate Change

[Anonymous Coward]

if you follow that lkml, they are discussing a patch

Which is irrelevant to Linus' summary of what he feels about journald, even it's said "by the way".

i ignored the other 2 links as unverifiable anecdotes.

Users are not even morally obligated to submit bug reports to an upstream if it is hostile.

Re:In Other News: People Hate Change

[mvdwege]

And indeed, that discussion:

1. Does not say what you say it does.
2. Concerns an outdated systemd (208).

Like I said, you're lying. Again.

Re: In Other News: People Hate Change

[dinfinity]

I wasn't talking about journalctl. I was responding to this: "whether a file is text or binary you still need a tool to read it so its a meaningless argument."
That is still an idiotic way to dismiss the difference between text(ASCII) files and some binary format.

You can also pipe the text output from journalctl to any text parser you like.

That is a great feature. To me this pretty much settles the argument over binary logging vs. text logging and deserves being stated often and immediately when it comes up.

Re: In Other News: People Hate Change

[yithar7153]

Ah, good old Slackware. I used to use Slackware. I currently use Xubuntu 14.04 on my Chromebook, but I might be going back. Turns out the packages in universe are not maintained by Canonical and may have security issues.

Re:In Other News: People Hate Change

[Anonymous Coward]

From Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise:

Despite its overarching abstractions, it is semantically non-uniform and its complicated transaction and job scheduling heuristics ordered around a dependently networked object system create pathological failure cases with little debugging context that would otherwise not necessarily occur on systems with less layers of indirection. The use of bus APIs complicate communication with the service manager and lead to duplication of the object model for little gain.

Further, the unit file options often carry implicit state or are not sufficiently expressive. There is an imbalance with regards to features of an eager service manager and that of a lazy loading service manager, having rusty edge cases of both with non-generic, manager-specific facilities. The approach to logging and the circularly dependent architecture seem to imply that lots of prior art has been ignored or understudied.

In my own words: it is an undebugable piece of shit spaghetti project. I'm pretty sure Cthulhu is in some way involved.

Re: In Other News: People Hate Change

[phantomfive]

If you can't tell the difference between a text file and a binary file, and the reasons some people prefer one over the other (and vice versa), then you're not experienced enough to discuss systemd knowledgeably.

Re:In Other News: People Hate Change

[sjames]

If you're going to call someone a liar, you need to back it up. So back it up or STFU.

Do the google, you'll find the same problem reported a year later. I pointed to that one because it best described the problem.

Re: In Other News: People Hate Change

[Anonymous Coward]

Err what do you call utmp and wtmp since they have been around in Unix since pretty much, well forever.

A nightmare which I have thankfully never needed to rely on for debugging, as I don't have any untrusted users permitted to log in to my systems. I'll run 'w' and 'last' from time to time, but only for convenience; if those programs fail it's not a problem to walk down the hall and ask "hey dude, did you change anything on such-and-such server yesterday?"

If I had to worry about large numbers of users I don't know logging in from who-knows-where - and if I had reasons for needing to keep track of who logged in and when - then yeah, I'd be pretty nervous trusting those logs to a cryptic binary format.

Re: In Other News: People Hate Change

[drjones78]

Hmm, you must not have experienced unicode hell before.

Re:In Other News: People Hate Change

[drjones78]

You ought to reboot your system every time there's a security update to the kernel or some other core package like glibc, at the very least, whether thats 1-2x per year, 20x per year.

Re: In Other News: People Hate Change

[goose-incarnated]

whether a file is text or binary you still need a tool to read it so its a meaningless argument.

No, I don't need a *special* tool to read it. I need a tool to read the disk and a tool to display to screen. I don't need a tool that goes in-between those two tools jut to read a text file. Those two tools are just fine. It's intellectually dishonest to claim what you claimed above.

You are basically making the claim that, because one needs a tool to decrypt ciphertext, that *proves* that everything is ciphertext. Sorry, no it isn't. Using dd to read a text file is not in any way the same as needing an executable with multiple libraries.

Re:In Other News: People Hate Change

[HiThere]

When systemd is in use, installing on one partition makes the other partitions unbootable...unless they can be booted with SysV. This has been known for over a year, and, IIUC, has been marked "won't fix".

So I find systemd to be unusable. I like to test new systems without rendering my current system unusable.

Re: In Other News: People Hate Change

[Peter H.S.]

> Maybe. But my initial reaction was "binary logs?!? on a *nix system? WTF?"

Besides the POSIX utmp and wtmp binary logs, there is also the Kernel ring-buffer on Linux; Without the ring-buffer collecting and storing messages from /dev/ksmg there would be no boot-logs at all, or even any logs until the rootfs has been mounted and the syslog daemon started.
systemd's "journald" service is the Kernel ring-buffer equivalent, and "dmesg" similar to systemd's "journalctl" tool; they both extract binary log-info and convert it to text.

Also, consider that log collectors and analyzers like "Splunk" etc all does exactly the same thing as "journald", namely hammering the log-info into a binary structure with an index.
systemd's format is Free software with a stable and documented API and format (so eg. Rsyslog can read it natively), while many other log-analyzers are close source with proprietary formats.

If you remember when Rsyslog was started a decade ago, you should remember that one of its main goals was to overcome the many inherent limitations of flat file text logs; it's solution was to place the logs in a DB (binary format).
systemd's binary format is much, much simpler than running a full DB, while getting access to many of the advantages of having an indexed log.

Re: In Other News: People Hate Change

[Aighearach]

If you're not experienced enough to pipe somebinaryfile.foo through footobar so that you can use it with other command line files, then you're fibbing about having any use for such a difference. ;)

Re:In Other News: People Hate Change

[Anonymous Coward]

Our business-critical web server needs to reboot for a kernel update. Don't worry, we're not on some tablet type device, you see no reason why boot speed should even be a thing. The old initscripts are plenty fast enough for this critical infrastructure that loses us several people's annual salaries when it's off. Who cares if it takes more time to reboot our servers if we get to pretend we're UNIX because our shit doesn't work?

Re: In Other News: People Hate Change

[Aighearach]

You can cut that down further.

"Users are not morally obligated."

Just use which one you want. If you're hating on things you don't use, after you realized you didn't want to use them, that is an unrelated non-technical problem.

Users are not morally obligated. They're just users.

Re:In Other News: People Hate Change

[Aighearach]

Seriously, who cares how fast it boots?

*raises hand*

Given booting faster, or booting slower, I'll take faster.

Re:In Other News: People Hate Change

[Aighearach]

And stuff breaks because it relies on specific, unspecified behaviour? Sounds to me like that stuff is broken, not systemd. In any case, the logical thing seems to be to fix the broken stuff so that it is more reliable and more compatible.

Yeah, but if they actually made a specific claim about something being broken, one of those know-it-all systemd users would just go and fix it for them, and they'd lose the whole complaint. You're trying to ruin perfectly good straw men.

When people whine to me about systemd in person, I tell them straight up; find a real bug or problem and I will personally slay it for you. Nobody has ever been able to cite a real bug, that they actually had, though all of them have a cousin's friend's brother's wife's friend's cousin who has a box in a closet that no longer boots because it visited the wrong network and contracted systemditis.

Re:In Other News: People Hate Change

[Anonymous Coward]

Our business-critical web server needs to reboot for a kernel update.

No it doesn't. You're not qualified to manage this supposed critical server.

Re:In Other News: People Hate Change

[Aighearach]

LOL there are often some non-ASCII chars in the logs, and there are always were.

All you have to do is type "bar" instead of "foo" and you'll be reading the text-only log, because that is how the tools work.

Your idea that you'd need to rewrite something to find an exit code from a log because the log is binary is hilarious; it shows that you don't actually use logs that way, don't understand what the word "binary" means here, and you don't actually have the problem that you claim exists.

The absolute worst case would be going from:

foo | grep baz

to

bar | grep baz

Modern web frameworks often spew ANSI color codes into the logs. And people who don't like that... turn them off. ZOMG end of the world, you had to learn the very basics of using the command line for things, to use the command line for something.

In the old days we didn't even have libreoffice; people would send us microsoft word files and we'd have to type

catdoc foo.doc | less

Meanwhile some jerk was telling us, "you can't even read a word document, because its binary!"

And BTW, I'm on a systemd distro right now and I can still say

sudo tail /var/log/messages

and nothing has changed. One thing that has changed, dmesg output is colored these days; if I just say

sudo dmesg

and then press control-C, my poor terminal might have colored text because of the ANSI color codes. Oh, no, destroyed by binary! Oh, wait, I just needed to type reset to fix the terminal. Or remember to do dmesg | tail in the first place.

Re: In Other News: People Hate Change

[Peter H.S.]

Unless you can convert your binary to a stream of text, forget grepping it or doing any of the transformations everybody with a modicum of experience of *nix is very familiar with.

Well there are many ways to do that with systemd, including various language bindings to eg. Python, allowing you to directly query the journal.

It would also be trivial to tech "grep" etc to learn to read the journal, just like "zgrep" can read binary files. There is no point to that however, since the concept of piping works so well: All the standard text tools like grep, awk, tee, wc etc. works with the systemd journal through piping.

On the commandline, binary files are going to require a custom built interface for that specific type of binary. That custom built interface needs to have all the features you want for easy searching etc.: no regular expression search built-in? Then forget about it. If you're lucky, there is another tool that understands your specific binary flavour which may or may not do what you want.

No, that is wrong. Through the Unix concept of piping all standard text tools work with systemd's binary journal, so you can use any grep regex on the journal.

A text file does not have those problems because it can be interpreted using a standard that is ridiculously simple, old as dirt and supported by and ingrained in pretty much fucking everything that displays letters.

I'm not saying a binary format cannot have its advantages (databases obviously have many), but to dismiss the difference between binaries and text files with 'you still need a tool to read them' is absolutely fucking idiotic.

I think you make text files much simpler than they really are; multi-language files, UTF vs ASCII, Unicode and even simple CRLF vs LF can make dealing with text files a major hassle.
People are often surprised by the Posix definition of a text file (which causes eg. grep to treat "text" files as binary data.

Anyway, having worked with systemd's journal for quite some time I can only say it is major benefit to use and that practically all concerns I have seen raised against it seems to be based on wrong and often contrived speculations.
Stuff like "journalctl -b -1 -p err" and "journalctl --since -10m" is just great. And I really like that even log-entries can be tab-completed, so you just type "jou(tab) -u sma(tab)" to type "journalctl -u smartd.service"

Re:In Other News: People Hate Change

[Aighearach]

You lied, he called you on it, you tried to defend, the documentation you pointed at shows you had a problem with your distro, and are lying about it to blame systemd.

Learn how to set up your raid next time. Take responsibility for your mistakes. There are lots of sysadmins here, you can't avoid being a liar just by calling names afterwards.

Re:In Other News: People Hate Change

[sjames]

And you apparently can't read. I posted a representative message from the systemd list (not a particular distro) where LP himself admitted to not having a solution (you did actually read it, didn't you).

I did indicate that a number of distros solved the immediate problem for RAID by doing an end run around systemd.

You didn't even read well enough to understand that I was testing with BTRFS. I solved the problem (that is, configured the system correctly) by disabling systemd and putting SysV back in charge of booting. Suddenly it all worked.

Summary, your favorite shiny got dissed and now you're all butthurt and lashing out impotently. You'll no doubt be whining about micro-aggressions next.

Re:In Other News: People Hate Change

[Anonymous Coward]

I like it when my login screen is already showing before I could move my fingers to my keyboard. You might prefer pushing the button and then go grab a coffee like I did in the past. But really, booting in seconds instead of minutes is a step forward. You seem to be one of those who is against systemd only because it is faster, while that was never the purpose of systemd, it was just a consequence of the design decisions.

Re:In Other News: People Hate Change

[Aighearach]

Right, distros solved the problem without systemd's help... because it was their bug, not systemd's! duh. Stop lying about it.

Re:In Other News: People Hate Change

[mvdwege]

That's not how it works, kiddo.

You stated there was a problem, you need to put up the evidence. The link you put up did nowhere near state what you said it did. Ergo, you're a liar. You backed that up yourself.

Re:In Other News: People Hate Change

[sjames]

Sorry, no. I put up a reference and a google search you could use. If you don't want to believe it, fine. But if you want to call people a liar, you'd better have a better reason than "I can't read so I don't acknowledge your evidence."

Sorry about goring your sacred cow and that you have so much butthurt over it. I suggest you retreat to your safe space and seek counselling.

Re:In Other News: People Hate Change

[sjames]

No, they worked around it because the systemd team were running around in circles with their pants around their ankles.

Re: In Other News: People Hate Change

[Anonymous Coward]

Interesting, but why can't either Debian or Red Hat get it right? It's a pain to troubleshoot when log messages are lost. At what point do you just give-up on systemd? If Debian and Red Hat can't get it right with their own included packages, what hope do I have of playing whack a mole on logging bugs?

Re:In Other News: People Hate Change

[Anonymous Coward]

The debate is over. Those that want what systemd is and will become have it and those that don't now have an alternative. Odd that so many are upset by this.

Re:In Other News: People Hate Change

[Celarent Darii]

And yet these VM's, like those in docker, are simply not using systemd. They use the simplest init services possible. Systemd is not even useful in a docker image.

Re: In Other News: People Hate Change

[phantomfive]

Well, it's true that systemd can log to a text file, so the logging issue is really a non-issue in terms of systemd - but claiming that a text file is a binary file is just purposely being obtuse.

Re:In Other News: People Hate Change

[Anonymous Coward]

I manage a fleet of services that run on (virtual) servers that rarely live more than 48hrs. Thanks to systemd's shortened boot times (amongst other things), each time an application is updated we can mint an entirely fresh machine image and respin the whole cluster. Our systems are also able to quickly add new servers when there is CPU/memory/disk pressure on the existing servers, and shrink the cluster once a load spike passes.

In this kind of environment, systemd's socket activation is awesome. Since these machines are short-lived and we only directly log into them in emergency situations, stuff like sshd will often never be started at all for the lifetime of the machine... but if we happen to need it, systemd is listening on port 22 and will fire up sshd the first time an SSH client shows up.

Personally I'm pretty glad to no longer be maintaining "pet" servers that each develop a unique personality due to all those little tweaks people do even though they know they shouldn't because "the site is down so I will just do a quick hack to get it back up again". We certainly have some longer-lived servers running stuff like relational databases, and systemd's benefit there is definitely weaker, but it doesn't seem to have any drawbacks and so it works out easier for us to just use systemd everywhere so we can share unit definitions between the two different server classes.

Re:In Other News: People Hate Change

[Anonymous Coward]

MORE SPEED!!!!!!!!!!!!11!!!!!!1

Opinion invalidated, didn't really see any difference between Debian and Fedora

Re:In Other News: People Hate Change

[Anonymous Coward]

The worst part is how hard it is to track down that it is Red Hat thats behind it.

Canonical get a lot of flack for the way they manage projects, but at least they are up front about who is running the show.

Recently there as a posting on blogs.gnome.org about Fedora Workstation (already mixing the projects), made by a guy working for Red Hat (though you have to search the name to learn that), thanking two other people doing projects apparently under Freedesktop and Wayland for their efforts. But once you start searching the names you find that both of them are also Red Hat employees.

They may well have the best of intentions, but it has a very high echo chamber factor building. They may have the best of intentions in mind, but never stopping to ask if just because they can that they should.

Re:In Other News: People Hate Change

[Anonymous Coward]

That's because you're doing it wrong. A Docker image is not a VM, it's a virtualized application. SystemD starts Docker containers like a champ and those containers run Apache, Node.JS, Java, Python, etc just fine without running their own SystemD instances.

Re:In Other News: People Hate Change

[mvdwege]

Yes, I actually did read it. And the reason why Lennart admitted there was no systemd solution, was because it wasn't a systemd problem, and the rest of the particpants backed him up on that..

Really, if you are going to lie, pick a better link, not one that actually proves you are lying.

Re: In Other News: People Hate Change

[Olipro]

You're right insofar as changing from a SysV-style init to SystemD obviously presents opportunity for boot failure.

However, to me that would logically mean that you have broken/unimplemented SystemD unit files. So either fix them or wait until someone else does. It's not an argument against SystemD, it's an argument against bugs and/or poor transition implementation. I would point to the Windows XP x64 switchover as a prime example of that. Despite which, x86-64 is ubiquitous now.

Re: In Other News: People Hate Change

[Eunuchswear]

What chacter set is your "text" file in? ascii, iso-xxxx, utf-8? ucs-16? EBCDIC? sixbit? (and which sixbit) 5 bit telex code? Does it include shift characters?

Does it have lines? Pages? Chapters? Fixed length or variable length?

How are those lines, pages, chapters delimited? Length prefixes? EOL/EOP/EOC markers? Are the EOx single byte or multiple byte? What does a bare LF, or a bare CR mean on a DOS/Windows system?

Are your text files RLE compressed? 1D or 2D compressed?

Do they have embedded line numbers? Are those line numbers integer or fixed point?

People who only know Unix know very little about the possible fun you can have with "text" files.

Re: In Other News: People Hate Change

[Eunuchswear]

If anybody actualy cared about this it would be less than one days programming work to make a version of journald that wrote to a text file.

Since nobody has I think nobody actualy does care, it's just a subject for endless whining.

Re: In Other News: People Hate Change

[Anonymous Coward]

Except that when he/she knows, but realises clearly that:
* The binary format is easily corrupted in a way that is much worse than a text file can be corrupted.
* The producer of the binary format does not even work reliably.
* The producer cannot be disabled even if one only needs text output.

Re: In Other News: People Hate Change

[Anonymous Coward]

Just use which one you want. If you're hating on things you don't use, after you realized you didn't want to use them, that is an unrelated non-technical problem.

Which has nothing to do with users that do not hate, but have used and have already been harmed by the product in question, and know from the developers' repeated behaviour that bug reports are a waste of time. And by the way, it seems that it's above-mentioned developers who actually hate ;)

Re: In Other News: People Hate Change

[Anonymous Coward]

Do remember Linus Torvalds' commentary on Kay Sievers, child: he who created the problem is responsible to fix it ;)

Re:In Other News: People Hate Change

[Anonymous Coward]

Maybe you're just selectively blind?

Re:In Other News: People Hate Change

[Anonymous Coward]

Wow, another troll who can't differentiate between text format and binary format. CS101 welcomes you, dear.

Re:In Other News: People Hate Change

[Anonymous Coward]

Mounting the root filesystem is initramfs's job, not /sbin/init's.

All kernels don't use an initramfs. I've been running a decade and a half without an initramfs. My kernel mounts the root filesystem with the root= argument, read-only though.

The init system's responsibility is to remount the root fs read-write.

Re: In Other News: People Hate Change

[Anonymous Coward]

You are being a pedantic ass, bordering on being a troll. Your attempt to confuse text vs binary with analog vs binary is not funny.

Re: In Other News: People Hate Change

[Anonymous Coward]

The original version of 'cat' didn't know a damned thing about ASCII vs. binary, and would happily dump binary onto your terminal screen. You could still use it to read ASCII because the terminal does the work of interpreting the binary character codes.

Re: In Other News: People Hate Change

[Anonymous Coward]

You're a stupid cunt. Let's double log everything. In fact, let's just double everything - double packets, double keystroke, double files.

Re: In Other News: People Hate Change

[phantomfive]

What chacter set is your "text" file in?

Most likely utf-8, everyone's doing it now.

Re: In Other News: People Hate Change

[Blaskowicz]

Indeed I remember the .gz files to be quite a problem in /usr/share/doc : when you don't know yet about zcat and zless it's a pain, you may decompress a copy or decompress in place as root, unless trying to gunzip to stdout/in.
This makes getting help more difficult that it need be - and you rarely find help in there but sometimes there is.
Finding about zless may happen by chance after years of using linux/*nix. E.g. by watching a greybeard use it.
How about a file in /usr/share/doc named HOWTO or README.1ST, and more common documentation?

Re:In Other News: People Hate Change

[sjames]

WOW, you really read that into it?

There was discussion of it being in udevd, but guess what udevd is a part of these days? And, of course it was never a problem before because the other init systems would issue the command to start the RAID (or mount btrfs) as an imperative rather than in response to an event (central to the design of systemd) and so let the specialized code that actually knows if the array can be assembled under existing conditions make the go/no-go decision.

And that is why the distros were able to work around it by using scripting in intiramfs to assemble the RAIDs before letting systemd bumble it and in the case of btrfs I was able to get the desired behavior by dumping systemd for SysV (so the mount command would be issued as an imperative). It's not an implementation bug, it's a design flaw.

>p>So, no lie, just you desperately not wanting your precious to be tarnished. Had you been more interested in understanding than in yelling lie at the first opportunity, you might have understood the problem sooner.

Re: In Other News: People Hate Change

[Anonymous Coward]

Ah yes, the old "ignore him, he's just trolling I say" argument. Classy.

Re:In Other News: People Hate Change

[mvdwege]

Nope, still a lie. You accused Lennart of blithely saying NOTAFIX, and produced that linked, where he most certainly did not. If you sysadmin as well as you lie, I wouldn't want to touch your systems with a ten foot pole.

Re:In Other News: People Hate Change

[sjames]

Let's see, from that thread, we have from LP:

But for now I am pretty sure we should just leave everything in fully manual mode, that's the safest thing to do...

Where fully manual means it drops you to a shell and you manually assemble the RAID. In other words, WONTFIX

So go have someone give you a hug and calm down in your safe space while you desperately try to find some odd interpretation that fits your worldview, but don't bother to reply unless you lead with a big fat apology.

Meanwhile, I'll go on enjoying the availability benefits of a systemd free machine.

Re: In Other News: People Hate Change

[Anonymous Coward]

Fortunately none of these apply to journald.

Re:In Other News: People Hate Change

[Anonymous Coward]

Another troll who complains about systemd's awful binary log format while having no idea what that format is. Hint: it's still human-readable.

Re:In Other News: People Hate Change

[Anonymous Coward]

API and protocol docs would be great. They could stay in the SystemD project if they had API and protocol docs. The biggest problem I have with SystemD is trying to figure out what went wrong when the system doesn't boot, because SystemD doesn't report the error code or error message of the process that caused it to decide to stop booting.

Re:In Other News: People Hate Change

[Anonymous Coward]

A format that usually corrupts in a way that's much worse than a plain text file can usually be corrupted? ;)

Re:In Other News: People Hate Change

[mvdwege]

Ok, I'm taking it back, you're not a liar. You are just too stupid to recognise a design discussion for a bug report.

Re:In Other News: People Hate Change

[Anonymous Coward]

So by claiming he was a liar at first, and then admitting he is not a liar, you concede that you are the liar?

Re:In Other News: People Hate Change

[Anonymous Coward]

OK, you are just too stupid to tell apart "request for reference to a bug" from "request for a bug report" :)

Re: In Other News: People Hate Change

[thegarbz]

A text file does not have those problems

I take it you've not had a service dump garbage data in your text file before where an action as simple as grepping screws up the terminal to the point where it's simply easier to logout and login again to restore your ability to enter text?

But let's face it, this entire discussion is utterly pointless since systemd can be setup to dump to syslog and is infact setup so by default in the distributions I've used, AND there's an open source tool which you can run on another machine to take a journal file and convert it to plain text with the only difference that rather than feeding grep an input from cat or from journalctl.

It's all moot when you can convert any format to whatever the hell you want and don't even need to do it on the machine in question, as is the case here.

Re: In Other News: People Hate Change

[thegarbz]

Our Linus,

Is unfortunately as unjust as every other deity you pray to.

Linus: You can say the word "systemd", It's not a four-letter word. Seven letters. Count them.
I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.

Re:In Other News: People Hate Change

[thegarbz]

If the systemd/PulseAudio/etc abominations were just confined to RedHat, no one would even vaguely care (except RedHat users).

Yeah tell me about it. Pulseaudio is horrible, nearly as bad as the things which preceded it.

Re:In Other News: People Hate Change

[Anonymous Coward]

Naaa, that would be solid engineering, as opposed to anything Poettering can do. This person must not even have heard of KISS or he is to stupid to recognize what it means and why it is at the core of solid engineering.

"Killed Init, Sorry Suckers"?

Re: In Other News: People Hate Change

[Anonymous Coward]

That error message is from Gnome. It's probably an x.org driver issue, but you know what? You can log in on a vterm and query the log if you want to know what the problem is. There's a really neat tool that systemd provides called journalctl. Use it and stop bitching.

Re: In Other News: People Hate Change

[Anonymous Coward]

Right, because there's only one vendor of Linux.

Fuckwit.

Re:In Other News: People Hate Change

[mvdwege]

No, I've gone over to gratuitous insults. But thanks for proving that anti-systemd rhetoric correlates well with, uhm, being "challenged".

Re:In Other News: People Hate Change

[Anonymous Coward]

Because you are the beginner of those gratuitous insults? Anyway thanks for proving that pro-systemd rhetoric correlates well with being challenged.

Re:In Other News: People Hate Change

[mvdwege]

Oh, you shits are precious, aren't you? It's okay to call names, smear people and be an all-around shit, until someone calls you on it, and then you act all high and mighty.

You don't even have the courage to sign in.

Well, you can fuck off. And die, for all I care, but history will take care of that, so I can wait you out.

Re:In Other News: People Hate Change

[Anonymous Coward]

No, your inability to corroborate your original claim with a firm line of reasoning is so precious, that you have to quit holding that claim. And when indicated that losing your untenable claim left you in the position of THE liar, you resort to accuse the other side of insulting, which actually originated from yourself.
By the way, whether I was logged in has nothing to do with a summary of your behavior. Mind you child, anonymity is a right (even heard of EFF, son?): so by your standard that a claim without substance is a lie, and another unsubstantiated claim that I remained anonymous because of cowardice, you again give people the impression that "liar" is a description for you.

Re:In Other News: People Hate Change

[Anonymous Coward]

I started shaking uncontrollably. But not for the reasons you may think.
Are you fucking kidding me? Why the heck would YOU be a systems administrator and not agree with his thought process?

Please do not get anywhere near my servers!

Re:In Other News: People Hate Change

[squiggleslash]

I can't endorse the GP's language but I understand his frustration. He proved pretty much everything he needed to, and the idiots making the usual anti-systemd allegations failed in every way. You guys blamed a bug in a file system on systemd. He showed you where to look, you refused to do so.

You're like the GamerGators of the Linux world, inventing your own little reality and descending to smears when the rest of the world points out you're wrong.

Re:In Other News: People Hate Change

[Anonymous Coward]

You guys blamed a bug in a file system on systemd.

It's more than reasonable because the bug wouldn't even exist if systemd did not enforce its half-baked mounting subsystem.

He showed you where to look, you refused to do so.

So where to look?

Init Freedom

[Anonymous Coward]

What does Systemd have to do with "init freedom"?

Re:Init Freedom

[somenickname]

It prevents it. The init part of systemd is just a small part of it. It has started to replace many (and a growing number) of core Linux userspace subsystems. It has gotten to the point where you may not be able to run the desktop environment you want without systemd. The generic, modular bits that systemd has consumed are now components that more and more pieces of software are depending on. In the very near future, it may not be possible to run a modern Linux desktop without systemd.

And, for what benefit? None that I've ever seen. There is nothing that I can now do with my laptop that I couldn't do before. But, there are plenty of things that I can no longer do since the introduction of systemd.

Re:Init Freedom

[Anonymous Coward]

So who is taking the initiative to maintain the bits that "systemd has consumed and replaced"? What happened to "build it and they will come"? I'm asking for people to bring on the code and all I see are people bitching that "systemd is taking over everything".

Re:Init Freedom

[Anonymous Coward]

Wow, "I can do whatever I want, others have to clean up after me" once more?

Re:Init Freedom

[Anonymous Coward]

Wow, "I can do whatever I want, others have to clean up after me" once again?

Re:Init Freedom

[NotInHere]

You know i for one welcome our new systemd overlords. Part of why non-systemd users don't get supported anymore is because there are no non-systemd services anymore with a rich API as systemd. And very often unification is very good.

You know there have been multiple projects for standardisation among linux, and many of them have failed. Most of them just published a standard nothing more. systemd offered an implementation, without a standard, and it was successful, didn't fail.

Re:Init Freedom

[Anonymous Coward]

systemd offered an implementation, without a standard, and it was successful, didn't fail.

Or " We don't know what we're doing, you won't know what we're doing oh and the rich api will change with the breeze and debugging will be impossible but we're gonna shove this sandwich down your throat anyway.

Re:Init Freedom

[Barsteward]

"And, for what benefit? None that I've ever seen. There is nothing that I can now do with my laptop that I couldn't do before. But, there are plenty of things that I can no longer do since the introduction of systemd."

well, if nothing has changed then they've done such a good job as you carried on as normal. What can you no longer do?

Re:Init Freedom

[Anonymous Coward]

This for example?

Re:Init Freedom

[Anonymous Coward]

Is this enough?

Re:Init Freedom

[gweihir]

Indeed. No tangible benefits for many people and at the same time massive mission creep. If it were a sane design and just stuck to being an init-system, it would also be very easy to fully support other init-systems in parallel. The systemd developers have made that hard, and I think intentionally so. I call that one thing: "sabotage".

Re:Init Freedom

[Barsteward]

thats an unreliable anecdote, he can't find anyone else with the problem and seems like he's not even logged it as an error.

Re:Init Freedom

[Barsteward]

another load of anecdotal nonsense, he should have linked to a bug report

Re:Init Freedom

[Anonymous Coward]

he can't find anyone else with the problem

Or only you think he can't.

Re:Init Freedom

[Anonymous Coward]

Before dictating what a user should do, you should check whether it will be a waste of time.

Re:Init Freedom

[sjames]

Did you even read the summary? You know, the one about the group building and maintaining a systemd free distro who just released a beta?

What is wrong with systemd?

[Midnight Thunder]

I am new to this and I have seen a fair few "systemd is 3vil" posts, but with little indication as to why people dislike it, compared to the alternatives? Just to be clear I don't have a position here, rather I am looking for some insight.

Re:What is wrong with systemd?

[Anonymous Coward]

The first time your system goes down hard and you need to login to the systemd emergency console, run the command to review the binary-logs, and then set the system default to boot again, you'll hate systemd too.

If it's a remote system, you won't even know it's systemd that you hate.

If that system is your only internet access, you may not know what you have to type to bring it back to life (it's not informative).

These are fixable issues, but systemd doesn't have anyone technical enough to do so, and the rest of us won't touch it.

The usual response is to install another distribution and just play the systemd lottery again.

Re:What is wrong with systemd?

[Anonymous Coward]

The first time your system goes down hard and you need to login to the systemd emergency console, run the command to review the binary-logs, and then set the system default to boot again, you'll hate systemd too.

You mean the binary logs that don't exist on debian unless you manually edit the systemd config?

Re:What is wrong with systemd?

[Anonymous Coward]

This perhaps?

Re: What is wrong with systemd?

[Anonymous Coward]

Dropping stderr and syslog So you can't troubleshoot is pretty annoying. Also, they ignore bug reports about that problem. As Lonus pointed out, they ignore most bug reports.

Re:What is wrong with systemd?

[Anonymous Coward]

A very nice conclusion: "systemd does it the wrong way round precisely so that you cannot swap it out, the antithesis of the UNIX ecosystem-respecting approach."

Re:What is wrong with systemd?

[Anonymous Coward]

I'm in the same boat, and the water is very murky. Every time I see a bunch of technical claims, I see someone claiming the exact opposite point-for-point, and I don't know who to believe.

It is often claimed that it is not so bad for desktop but terrible for servers. I don't know if that is true or not.

One thing that keeps coming up is a philosophical point: "do one thing and do it well", with the implication that systemd takes on many responsibilities that used to be separate tools, for the worse. I don't have a dog in that fight.

There is a perception that it is a "borg" which keeps taking over more functionality and becoming a dependency for so many things that there is no choice but to use it, an example being Gnome. I don't know if this is fair or not.

I will note that maintainers of several unrelated distributions independently chose to adopt it, including Arch Linux. I mention Arch because A) they are famously in favour of a simple base system which you customise the way you want, B) I don't believe have anything to do with Red Hat (where the systemd creators come from), and C) they haven't been forced to switch by e.g. gnome because they don't require gnome or any other desktop.
Comments from an Arch developer on their forum: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Re:What is wrong with systemd?

[somenickname]

There is a perception that it is a "borg" which keeps taking over more functionality and becoming a dependency for so many things that there is no choice but to use it, an example being Gnome. I don't know if this is fair or not.

This is effectively the crux of it. Everything else is just a symptom of this. People will make detailed technical analysis of the inner workings of systemd and that's cool and some of them are correct. But, bad technical decisions aren't that big of a deal until they start spreading across the system like a virus. Once systemd has infected everything (and, we are rapidly approaching that), it will be difficult or maybe impossible to cut out that cancer. We are right on the verge of being stuck with systemd and that's a very bad situation to be in.

I will note that maintainers of several unrelated distributions independently chose to adopt it, including Arch Linux. I mention Arch because A) they are famously in favour of a simple base system which you customise the way you want, B) I don't believe have anything to do with Red Hat (where the systemd creators come from), and C) they haven't been forced to switch by e.g. gnome because they don't require gnome or any other desktop.
Comments from an Arch developer on their forum: https://bbs.archlinux.org/view...

This is the second problem with systemd. It has polarized people to such an extent that it resembles a religion or US politics. You must pick a side and you must rabidly defend that side no matter what. To be fair, it's an issue worth having an opinion on but, your opinion definitely doesn't matter. You have distros with very finite resources (like Arch) and distros with effectively unlimited resources (RedHat). The smaller distros kinda have to eat whatever shit sandwich the larger distros serve up because they don't have the resources to do anything else.

Re:What is wrong with systemd?

[Anonymous Coward]

You mean the text logs that are generated from binary logs produced by systemd? Which for some brainded reason cannot be produced in simple text (WONTFIX)?

Re:What is wrong with systemd?

[Anonymous Coward]

Is that the idiot who didn't realize why pacman overwriting config files is bad, until it bit him in the ass?

Re: What is wrong with systemd?

[Barsteward]

read how to configure systemd, your knowledge is lacking. or just stop rewriting other posters ignorant statements

Re:What is wrong with systemd?

[Barsteward]

Try finding out for yourself . You will find that most of the posts about what systemd can or can't do, are made from complete ignorance, lack of configuration knowledge or just plain trolling. Never trust a post until you've researched the issue yourself.

Re:What is wrong with systemd?

[Peter H.S.]

The first time your system goes down hard and you need to login to the systemd emergency console, run the command to review the binary-logs, and then set the system default to boot again, you'll hate systemd too.

The command to review the logs is called "journalctl" and it works perfectly from the emergency console or initrd. That means you have access to powerful log querying with systemd, even in a limited environment. So full service management and log querying even from the emergency console with systemd, which is much better than SysVinit/OpenRC based systems that just give you "cat" and a neutered version of "vi" to work with and often doesn't even have syslog in the initrd, but rely on the binary logging in the kernel ring-buffer (dmesg).

If it's a remote system, you won't even know it's systemd that you hate.

It is trivial to make systemd launch Dropbear (SSH) from initrd if the rootfs doesn't mount: that way you can ssh into the remote system to deal with the problem.

If that system is your only internet access, you may not know what you have to type to bring it back to life (it's not informative).

systemd is one of the best documented projects I know; there are man pages for everything and reverse indexes for every CLI option or config file option. Try "man systemd.index" and "man systemd.directives". Superior in every way to SysVinit etc. based systems by a long shot.

Really, systemd is the best thing that happened to Linux since package-management.

Re:What is wrong with systemd?

[Midnight Thunder]

This is why I was asking here. Sure I have been marked as a flamebait, since I apparently bothered some people, but the explanations above make sense.

Re:What is wrong with systemd?

[Anonymous Coward]

Can you provide a reference for how to run sshd when the root fs doesn't mount? Since sshd is usually available on the root fs (or another fs mounted under the root of course), then you need to build sshd into the bootloader (or a chained loader, etc.) so it is by definition NOT trivial.

Fuck systemd. But fuck Devuan, too.

[Anonymous Coward]

I really dislike systemd. It ruined my Debian installation. But I'm also really displeased with the Devuan project, too. I followed it briefly when it first started up, and I think it was a fucking joke. The smugness of the people involved was terrible. The first months of the project were constant accusations of people being "systemd trolls". I found everything about it to be shameful and amateurish. And it became clear pretty quickly that it wasn't going anywhere. So instead of waiting for it, I moved to FreeBSD. And you know what? I couldn't be happier! It brought me the best parts of the traditional Debian experience: stability, reliability, trustworthiness, and robustness. But it also didn't subject me to systemd. The more I use FreeBSD the more I regret not switching sooner. As far as I'm concerned, there's no need for a project like Devuan because FreeBSD is a full, systemd-less replacement for Debian, and Linux in general.

Re:Fuck systemd. But fuck Devuan, too.

[sjames]

Funny you post that it isn't going anywhere in an article about a significant milestone accomplished.

Re:Facts

[squiggleslash]

Yes, this, uh, adult, reasoned, calmly and rationally stated essay really instills confidence in the maturity and professionalism of the maintainers of this distribution.

(That son, I say that son, is a a a joke son, I say a joke.)

Re:Facts

[Anonymous Coward]

Citation needed.

I love the *idea* of Devuan

[Anonymous Coward]

Unfortunately its name sounds like a Puerto Rican ladyboy, which is likely to hinder enterprise adoption anywhere except at GitHub, Inc.

Re:I love the *idea* of Devuan

[Aighearach]

None of the companies I work with care if a person, place, or thing "sounds like a... ladyboy." If a person wants to be a ladyboy, that is fine with us. If they want to identify as a man or woman instead, that is fine too.

But if they make non-technical complaints about technical things, or have a passionate dislike for something that is merely not their first technical preference, then they're out the door, and if they don't want their desk contents in the mail, they'll sign the paperwork and leave promptly.

No, I've never worked at github. Yes, we prefer systemd. So that is the only reason not to use Devuan. It lacks important modern software.

One of my friends is a ladyboy. Some people think he should either stop wearing dresses, or at least shave his legs. I think, if he wants to have hairy legs and three days of stubble and wear a foofy dress, who cares? If it's warm out, I'm going to wear my cargo shorts and I'm not interested in people's opinions of it. Same.

Having run some CentOS 7 boxen...

[SIGBUS]

...my take on systemd is this: As an init system, I actually like it - far better than other SysV replacements, especially SMF on Solaris and friends. Where it goes off the rails, though, is the ever-expanding mission creep into things that really aren't an init system's purview.

If systemd would just be an init system and get out of the way, I'd cheer it on. But one of the first things I do when I set up a CentOS 7 server is to shut off firewalld and use iptables directly. Firewalld is OK on a laptop where you're connecting to a variety of different networks, but leave it off my servers, please.

Re:Having run some CentOS 7 boxen...

[Second_Derivative]

The firewalld project is completely unrelated to the systemd project.

Re:Having run some CentOS 7 boxen...

[kwalker]

Wait, wait, wait. So many people in this thread are saying systemd is taking over existing userspace utilities in undocumented and unremovable ways, but you can REMOVE firewalld and still use the old way (iptables) and the system doesn't melt down??? Then what are these people bitching about other than to read their own text?

systemd works perfect on 1020 node Cray XE6

[halfdan the black]

We run SUSE SLES 12 with systemd on our 1020 node Cray XE6 and it works just perfectly. What a joke, "veteran unix administrators", it doesn't get much more complex than a 1020 node, 21,824 processor Cray XE6 with Nvidia Tesla on each compute node. Node management and integration with the job scheduler is significantly simpler than older versions. The older system was a mess of shell scripts, perl scripts, and who knows what else, the new system is all streamlined in a simple config file and few modules.

Re:systemd works perfect on 1020 node Cray XE6

[Anonymous Coward]

Glad your have not been encountered with any corner case yet. And I'm pretty sure nosh would do the same thing better, without bloat either in scripts or in the init system itself (well, you really want to define "simplification" as replacing several MBs of debuggable scripts with several MBs of spaghetti C code?), and without the "you are not supposed to hold the phone that way" cases.

Rabid.

[westlake]

Foaming at the mouth. This is something I am supposed to take seriously as a SERVER distribution --- and as an alternative to Red Hat?

Re:Rabid.

[Anonymous Coward]

Well, the foaming still seems moderate to the daily heights of Devuan's IRC channels.

complicates life with unnecessary feature

[Anonymous Coward]

System V is enough, why complicate it and add another useless feature called systemd?
No other reason to add systemd except to encourage users to migrate to Win OS or OS X.

Re:systemd works perfect on 1020 node Cray XE6

[Anonymous Coward]

I agree. I have 100s of systemd machines to manage. It's all fine and sweet until there is a problem that requires more than a program launcher. Just try figuring out how to do something of your own daemon with systemd. Initd was trivial. SystemD is complex, bloated and incomprehensible. It's the worst joke ever hoisted on sysadmins.
 

Re:systemd works perfect on 1020 node Cray XE6

[Anonymous Coward]

MRW you said "our 1020 node Cray": What year is it?

unnecessary

[SkunkPussy]

I still have no idea why they needed to fork from debian, instead of just maintaining packages/patches required to provide a systemd alternative from within debian.

When choosing a distribution, why anybody choose a distribution whose only clear philosophy was that it is not something else? Unlike debian which is ultimate software freedom and stability or whatever.

Re:unnecessary

[thegarbz]

There's only so much you can do to maintain software packages for an alternative. When a core system component deviates the way systems did you would have to dedicate an incredible amount of testing and modifying of packages to ensure the system doesn't randomly break. If you need to retest much of the system then it's just easier to maintain your own distribution.

Re:unnecessary

[Anonymous Coward]

as to why fork it? well, not everyone will know how to change from a systemd init to another, for example new users

So Devuan is the distribution for people who can read manuals? That fits with them "discovering" standard mount options for vfat and being so proud of that.

Re:unnecessary

[Anonymous Coward]

You mean like Linux not being Windows? You mean like that?

Re:unnecessary

[Aighearach]

On the Fedora side, they have "spins" and it is really easy to maintain your own subset of packages without forking anything.

Maybe "fork and wither" is a Debian thing I just don't understand?

Re:unnecessary

[Anonymous Coward]

debian did not want that, they wish to become another redhat derivative at the expense of their original philosophy. Having a choice to stay with a distro that espouses the original philosophy and provides a seamless transition away from a diverging path is something that should have been available from the start. The degree of effort required to remove encroaching dependencies demonstrates clearly one of the major issues with the design/implementation of systemd.

But hopefull now the systemd threads can talk about systemd and the devuan threads can talk about getting work done in a gnu/linux environment.

Re:unnecessary

[Anonymous Coward]

I had been using debian steadily for about a decade until the systemd fiasco. I'm pretty disgusted by everything that happened and by a fair number of people involved with debian, so I moved most of my installs over to gentoo and figured I'd wash my hands of debian as much as possible. No personal usage, no maintaining packages, no recommendations to others for install. If the devuan guys didn't fork from debian then I wouldn't touch them.

"Unlike debian which is ultimate software freedom"
Not with systemd wedged into everything. debian lost credibility.

Re:unnecessary

[Anonymous Coward]

The spins don't usually contain core system components. They contain a set of userland applications.

Re:unnecessary

[thegarbz]

Hardly a Debian thing. There was a specific post by a Red Hat developer that I can't find right now which basically was a retort to why Red Hat won't give users the choice of not using something and instead asking them to fork their own distro. It was basically a summary of the amount of effort required to maintain a core package and interdependencies with other packages, and above all a system for installing and maintaining the user choice when requested. This wasn't about systemd but I think network-manager though I can't remember.

Either way there's some things that are when you change them the cost of maintenance is almost equivalent to the cost of running a distribution. At that point the fork approach is far better and introduces less bugs that get marked as upstream-won't-fix.

Incidentally without-systemd.org doesn't list any spins and I can't find any with a Google search either which did something as radical as pull systemd out and replace it with sysvinit. My guess is the spin system would be too hard in this scenario, but that's just a guess.

Re:unnecessary

[Aighearach]

You start out missing the part where on Fedora you don't need to fork to offer a different choice. Then later you talk about spins anyways, but you can't really address that intelligibly if you're also saying a fork would be required.

Maybe it isn't offered because nobody has a use case for it, and the whining is pure-non-technical-whining?

And no, there is no cause to speculate that you can't do this with the spin system. That is silly. Of course there isn't an official RedHat spin for this; nobody actually wants it. The anti-systemd trolls on slashdot, for example, are mostly windows users, and "can't switch" because "games."

Re:unnecessary

[thegarbz]

No you misunderstood what I was trying to say. Spins is a method of providing choice to end users through the efforts of other developers outside of the core, but they are still dependent on the upstream system. If you make a really fundamental change to the upstream system that is incompatible with the spin then the cost (maintenance, programming, testing, etc) of maintaining the spin is likely to be the equivalent of simply forking the project in the first place with the latter then not risking constant breakages from the upstream maintainers. I don't see how the spin system can magically solve this and how the spin system would be any different from a distribution based on an upstream one in this scenario.

In any case you're right about the use case thing. I am sure the systemd hate comes from an incredibly vocal minority of people who care more about complaining than they care about fixing the problem, otherwise they would be more supportive of Devuan and just get on with their lives. I disagree that these are mostly Windows users. There's no evidence of that, and in fact a bunch of people not running a system because of reason X complaining about a completely non relevant to them and their ability to run the system, doesn't really make any sense at all. I am firmly of the belief that most of the complaining is from grey neckbeards who grew up with one system complaining about having to once again read the manual.

Re:SystemD is like wiping yourself in buffalo shit

[Anonymous Coward]

Please send your testimonial to dng@lists.dyne.org or devuan-discuss@lists.dyne.org. Devuan would be proud to show it on their web site.

Re:Facts

[Barsteward]

Oi !!! sit down and give your mouth a chance

Re:SystemD is like wiping yourself in buffalo shit

[Barsteward]

you need to practice your trolling as that was painfully bad.

What problem did systemd solve?

[Anonymous Coward]

Any advance in technology can be measured by asking a simple question: what problem does it solve?

To this day, systemd failed to answer that. It did create al lot of problems, though.

Re:What problem did systemd solve?

[gweihir]

And that is just it: This thing does not exist to solve any exiting problem, it is a power-grab, plain and simple. That is also why it grows though Linux like a cancer and absorbs everything it can, so it cannot easily be ripped out. If it had stuck to being a better init-system, it may have had merit, but this way it is a huge threat to Linux, nothing else.

Re:Facts

[s4m7]

Yes, this, uh, adult, reasoned, calmly and rationally stated essay really instills confidence in the maturity and professionalism of the maintainers of this distribution.

It has always struck me that I can't seem to find a critique of systemd that lacks namecalling, cursing or at least one suggestion that Poettering do something that sounds anatomically unfeasable. It's as if the critics are largely middle-schoolers who don't actually have any skin in the game.

Re:Facts

[mushroom blue]

All my systems are now switched to Devuan.
The essay made people like me (linux-only since 1998) switch.

Re:Facts

[Anonymous Coward]

Perhaps because of your ignorance?

Whatever happened with having a choice?

[Anonymous Coward]

I thought this whole Linux thing was all about freedom to choose?

It does not bother me if someone uses or likes systemd - I personally did not like it after trying it. But, I wish to have an option to still use what I'm most familiar with, instead of being forced to use something else that someone else thinks is better. This is no different than all the other things happening around me where others are making choices for me that I'm quite capable of making myself.

Thus, I support Devuan effort and wish them to carry on, because they are presenting us with a choice.

Re:Whatever happened with having a choice?

[Anonymous Coward]

+1. Even though systemd fanboys pretend "Linux is not about choice" because "there is no choice", there are always choices: runit existed long before the inception of systemd; and now we also have nosh and s6, all of which are very lightweight, more configurable and reliable than systemd, and do not conflict with all kinds of technologies that always work well.

Re:Whatever happened with having a choice?

[Peter H.S.]

I thought this whole Linux thing was all about freedom to choose?

Not when it comes to Devuan; they won't let you choose systemd as init. No "init-freedom" there.

Re:Whatever happened with having a choice?

[Anonymous Coward]

you have a choice... install debian.

Whilst it is a goal to allow building in support for any init system, this has proven unworkable for systemd due to requiring so many parts to be built with systemd integration that interferes with non-systemd init systems, and no ability to build systemd with only init features turned on and none of the other cruft, therefore anyone that wants Devuan with systemd, is directed to install debian instead as that is the only place to get it.

Besides which systemd is not an init system as per it's creators own definition.

bootloader

[Anonymous Coward]

Systemd isn't a bootloader...

Re:bootloader

[Anonymous Coward]

Systemd isn't a bootloader...

Yet.

Re:Facts

[squiggleslash]

As someone who started with Slackware in 1997, and has been running GNU/Linux in some form or another ever since, his primary desktop GNU/Linux 90% of that time, I can tell you your "made people like me" statement is an exaggeration.

Frankly, this kind of essay is more or less standard fare from systemd opponents, and it's probably standard fare because it's actually hard to come up with a reasonable criticism of systemd, especially considering what it replaces. sysvinit should have died the moment the Internet became a thing, but it's soldiered on, a ghastly mess of hacks that results in virtually unrecoverable machines far too easily.

systemd is not perfect, but it's a hell of an improvement on what preceded it, and virtually every criticism of it is either overblown (OMG it has a 'sudo' command? How terrible! The world is going to end!) or downright misleading (binary logs... that can be dumped using the strings command. Yeah, big problem, not. stderr not logged? Perhaps you should fault your distro for turning it off, rather than systemd that happily logs stderr?)

Winging?

[Anonymous Coward]

And what use is winging

Well, birds use it to fly. So there's that.

Old farts that can't change

[xtronics]

I'm 61 - took me about an hour to figure out systemd - not that I asked for the change - but it wasn't a big deal. In the end I realized it fixed a few issues and all the hate-flame-bait crap was uncalled for.

I've come to realize it is must be only a minority of really old farts that complain about systemd - I get it - as people age they can't learn new things - can't see why the changes are happening - growing old sucks.

I suppose it is really the old guys over 70 just can't adapt to these changes - so I have some notes for them:

https://wiki.xtronics.com/inde...

Re:Old farts that can't change

[Anonymous Coward]

It's not about change. Even those 'old farts' welcome change. When it's useful. These are wise old men who see that there's conceptually much wrong with systemd. It's not about the init change, they mostly welcome that and can handle that. It's everything else that they, rightfully, abhorr.

Really old farts just can't change

[xtronics]

I'm 61 - took me about an hour to change over to systemd syntax. I didn't ask for it - thought it was a bother, but in the end I see it fixed some things and it is working fine - the hate-flame-bait-carp was uncalled for.

I have come to realize that it is only the really old guys over 70 or so that no longer can learn new things or see other points of view. Growing old and losing metal agility must really suck. I put up a page with notes for these guys that can't adjust on their own:

https://wiki.xtronics.com/inde...

I am really glad the Debian did not fold to the pressure of the geriatric community to become set-in-their-ways.

What a colossal waste of time and effort

[Anonymous Coward]

How about actually working towards something that actually benefits developers, like making a set of libraries with stable ABIs, binary compatibly across distros, instead of wasting everyone's time rewriting an init system that works on just about every distro and really affects nobody.

Seriously, who the hell actually interacts with the init system? Developers just want a way to write apps that's standard across all distros, and systemd helps with that by making a single stable framework instead of a thousands of fucking unintelligible shell scripts

Re:Facts

[Anonymous Coward]

Using your own words:

fucking clueless cunts

That's what you said.

highly immature

That's what you are, apparently.

It's possible, at least in theory, that you may have some actual points to make, but you fail so miserably it's almost comical, weren't it mostly just painful to watch. You have much to learn in life, whoever you are.

Re:Facts

[Anonymous Coward]

All my systems are now switched to Devuan.
The essay made morons like me (linux-only since 1998) switch.

Fixed that for you.

Systemd is desktop-centric?

[Anonymous Coward]

I agree with the sentiment of Devuan, except for the part about adoption of systemd indicating a trend toward desktop computing. I would never want systemd on any desktop machine. It's a trend toward broken, ill-advised, historically ignorant, and un-Unix-like computing.

Re:Facts

[Aighearach]

I value having frivolous boxes around that I can just "do whatever" with, but I value even more having root on boxes that I wouldn't alter frivolously.

Re:Facts

[Aighearach]

My first linux was slackware 3.0 which I got by buying a magazine that had the CD glued to the cover. Then I spent 3 days downloading a newer slackware over dialup. Before that I had to telnet into my ISP's SunOS 4 box if I wanted some *nix.

Throwing my hat in with, "a hell of an improvement [over SysV]."

The types of "technical complaints" people come up with... they aren't even enough of a challenge to make the daily list of sysadmin annoyances. They're all just small changes people would have to make in which program is in the first part of a long chain of piped commands. I mean, if getting ASCII logs is hard, what would happen if you needed to pipe the output through sed and on to xargs to do some work with it?

Re:systemd works perfect on 1020 node Cray XE6

[Peter H.S.]

What a joke, "veteran unix administrators",

The people behind Devuan aren't "veteran unix administrators". They are a bunch of unemployed or under-employed Italians. They also run "https://www.dyne.org/" . Think beggars with a GPL sign in hand; wherever the Dyne/Devuan folks are, the "please donate" sign is near by.

ugh...

[Anonymous Coward]

Either RH PR is rigging the voting, or /. has really gone devops...

peter goes to the pizzeria

[marcello_dl]

- waiter, a capricciosa without mushrooms please.
- here it is, sir.
- thank you, can you bring me some extra mushrooms for the capricciosa?
- whatever, sir. *turns to the cook who makes the international "he has a loose screw" sign*

DEPENDENCIES... thtat matters

[Anonymous Coward]

Nobody pointed the CRUCIAL point from both

DEPENDENCIES of systemd

THAT... changes a lot when customizing servers.

Servers don't really care about booting in 1 second - they do care on stable critical steps.

systemd is NOT for servers. That should settle soon...

Good for Devuan

[LichtSpektren]

I have no strong feelings about systemd. I do have strong feelings about the raving lunatics that infest message boards and article comments about how systemd is cancer--likely pushing hundreds or thousands of people away from free software, to Microsoft instead. So I'm happy that Devuan and Slackware still offer sysvinit, if for nothing but the PR of saying "you can use Linux without systemd."