Systemd 214 Comes "Stuffed With Great New Features"

[Truth]

I don't work for MSFT if that's what you mean. But I do work for a company that uses mostly MS stuff (Windows/Office/Exchange/Sharepoint) and I don't call the shots there. Now, I hate to break the news to you but we're not in a magical fairy land - in this world one has to work for a living. So, in a sense, I can't quit MS no matter how much I want to.

Come now, it's not nice to lie. It's quite clear you're a MSFT shill being paid to troll systemd threads.

I bet the MSFT exec that thought this policy up is rubbing his greedy little hands with glee, pay some amoral shills to infiltrate FOSS communities and spread FUD and mislead na?ve users into thinking projects that improve the FOSS ecosystem are "harmful" according to an ideology they don't even understand properly.

A FOSS platform is evolving out of the dark ages of kludgy shell scripts? Troll it, it's a threat to Windows!!!1111

[pixo]

Back from weekend and have questions for prodigy_

Too bad the implementation is deliberately broken.

I dont find it broken but than again i am not digging too deep into it as the only thing why i use systemd is that it has better support for multiseat than OpenRC

You forgot to mention that "digging" here means "issuing one command."

Can you show me that one command which points me to what rc script died and which others didnt come up due to it or come up funny?
That reminds me that i should see if systemd has equivalent of 'svcs -xv'

Welcome to LSB.

Can you please elaborate? I dont use BSD so the only thing that comes to me is that the scritps are executed in order of their S<nn> or K<nn>
If it is the S<nn> or K<nn> i would like to ask how does my service knows let say if e.g. ntp client is working before starting my services which needs to by time synced across servers?
And i dont mean doing "ps -ef | grep <whatever>" as i may need to replace that with another daemon and i will need to check all rc scripts.

[prodigy_]

I dont find it broken but than again i am not digging too deep into it as the only thing why i use systemd is that it has better support for multiseat than OpenRC.

If an init replacement that breaks every UNIX principle and tries to make everything to depend on it doesn't look like a broken design to you than what does?

Can you show me that one command which points me to what rc script died and which others didnt come up due to it or come up funny?

Again, there's LSB:

http://en.wikipedia.org/wiki/Linux_Standard_Base

https://wiki.debian.org/LSBInitScripts

The LSB has nothing to do with BSD. It's a Linux standardization initiative that, among other things, defines how you can have dependencies for init-based daemons. In short, daemon provides a facility (or a set of facilities) and, in turn, may require one or more facilities to be present in order to start and operate. If your init scripts follow the LSB guidelines, the command you need (to see what's missing) is simply a grep on the system log.

[psychoticmeow]

The LSB has nothing to do with BSD. It's a Linux standardization initiative that, among other things, defines how you can have dependencies for init-based daemons. In short, daemon provides a facility (or a set of facilities) and, in turn, may require one or more facilities to be present in order to start and operate. If your init scripts follow the LSB guidelines, the command you need (to see what's missing) is simply a grep on the system log.

What an outstandingly short sighted idea. Thankfully we don't have to deal with that mistake any more.

[oleid]

If an init replacement that breaks every UNIX principle and tries to make everything to depend on it doesn't look like a broken design to you than what does?

Hm... what Unix principle does it break? Didn't notice that....

[Truth]

Don't bother responding to Prodigy, he's a paid Microsoft troll attempting to sabotage FOSS.

Microsoft wants to keep FOSS in the dark-ages, with the failure of above-the-board FUD campaigns like "get the facts" they've resorted to hiring goons to infiltrate FOSS communities and pretend to be members and post warped internal-FUD to try and deceive you. Don't believe it.

Cast out Prodigy, the Microsoft rapist.

The Truth has spoken, nothing but the Truth.

[finalzone]

If an init replacement that breaks every UNIX principle and tries to make everything to depend on it doesn't look like a broken design to you than what does?

So you ask for a status quo based on the outdated 1970's UNIX principles due to the limit of hardware at that era?

A reminder from real UNIX administrators themselves:

“Not only is UNIX dead, it's starting to smell really bad”
“We really are using a 1970s era operating system well past its sell-by date.”

“[Linux] also certainly isn't "Unix" as that is fairly dead. It met needs in the 60s and 70s and even to some extent the 80s quite well. But the needs we have today are very different.”
“Lots of separate tools only do 90% of the work. To do really complete work, you need real purpose-built tools. "do one thing and do it well" is good for prototypes, not for final products.”

Detractors had four years to provide a real alternative for systemd umbrella only using needless insults and the fabled "UNIX philosophies" as arguments. Non-systemd projects like ConsoleKit are left dead because nobody stepped up to maintain them despite early warning.
Feel free to continue bashing systemd while majority on development already migrated to it including BSD apparently.

[pixo]

If an init replacement that breaks every UNIX principle and tries to make everything to depend on it doesn't look like a broken design to you than what does?

How does it break the principle? systemd as init is just init or so i understand. systemd as umbrella is a collection of tools/daemons in accordance with UNIX principles.
As for dependencies, i can easily switch between systemd and openrc and my system works the same except differences with seats support.
So how does everything depends on it?

Again, there's LSB:

http://en.wikipedia.org/wiki/Linux_Standard_Base

https://wiki.debian.org/LSBInitScripts

The LSB has nothing to do with BSD. It's a Linux standardization initiative that, among other things, defines how you can have dependencies for init-based daemons. In short, daemon provides a facility (or a set of facilities) and, in turn, may require one or more facilities to be present in order to start and operate. If your init scripts follow the LSB guidelines, the command you need (to see what's missing) is simply a grep on the system log.

Didnt know about that LSB standard, thanks. But it points to that the init system was broken in UNIX and must have been rewritten so why not systemd.
And you must be joking with the grep, that is what i was talking about digging trough logs.

For everyone else: well at least this troll taught me something new so maybe he will find for me other useful things.

[DrYak]

Didnt know about that LSB standard, thanks. But it points to that the init system was broken in UNIX and must have been rewritten so why not systemd.

And from that point of view systemd (the PID1 from systemd. Not the thousands of other different software which have entirely different purpose and which happen to be maintained by the same umbrella/project, like systemd's various NTP/DHCP/network/whatever daemons) makes entirely sense.

PID1's job (whether it is a script, a old-school linux's "init" style executable daemon, or the current systemd's replacement) has always been being in charge of starting-stoping things.
Except that, in the past, that function has been spread across several completely different daemons ("init" for startup/shutdown, "cron" & co for time schedule-based execution, "inetd" for network triggered, various esoteric solutions like tinydns' very own "/service" system, dbus' own sub-service spawning, various watchdogs, etc.) and would require extensive hacking (the introduction of isolations system like CGROUPS (which also enabled fun stuff like LXC) means that starting a new user-session while leveraging all this technologies would require massive non-standard hacking of the various X init script (cue in lots of crappy copy-pasta from users trying things found on google and which DO NOT work with their specific distribution) or even patching of the X server itself).

From that point of view, it's Unix itself which didn't follow the unix KISS principle ("software should do one thing and do it well"). Instead you had a single concept (starting/restarting) spread across dozen of software, none filling all needs, and maybe requiring a bunch of scripting if you use case doesn't fit any peculiar pre-existing solution.

So systemd is indeed a "less broken" Unix init system.

...Then of course, you have the hundreds of other separate deamon which are managed by systemd's project. Whether those are really that much useful remain to be seen. Although I understand systemd's rationale (they want to provide a self-sufficient set of building blocks "everything included". Other solutions are full blown multi-feature daemons, systemd want to provide minimalist alternative for those who only want the base function and nothing else, and systemd targets embed applications and lightweight virtualisation (like LXC) where the full blown daemon are overkill). But on the other hand there are ALREADY several good alternative (yup "dhcpd" is an overkill. But "dnsmasq" is a very successful DNS forwarder + DHCP server, which is successfully already used in routers and for containers. Was systemd project's own dhcp server necessary ?)

But that's another debate and those not interested in these daemon can simply keep using the full-featured one.