Slackware thumbs it's nose at upstream.

If you want upstream in Slackware, you're sh*t out of luck. Our upstream is Patrick, Eric, and Robby and -Current is the public repository.

Slackware is dead, at least to the mainstream, but that very well could change.

As far as DBus violating the UNIX principles, yes it does, but DBus is an optional package not required for the core of the OS.

Well, lets then keep calm and trust Bob. Or may be our old ninja priest Pat should call his friends at BSD yet again(Taken from Here).

Regards.

Statements like these show that you are still not able to distinguish between systemd the initsystem and systemd the project.

You may have misunderstood my question. My question wasn't about DBUS, but about systemd. Since it comes up over and over again, which parts of systemd, except communication over DBUS instead of text streams, violates the Unix principles in your opinion. Please no link to sited like boycottsystemd.org, but your opinion on it and why you have that opinion.

Indeed, and I'm proud of it.

What does this even mean? Slackware has been one of the distros that adheres to upstream packages most. Now you're just spewing random words and hoping they make you sound cool. When 50% of all systemd-related posts are from you (and often relate little if any new information or even opinions), maybe sometimes you should just make a conscious decision not to post once in a while. If you posted 50% less, you would be less obnoxious, less disruptive, and come across as much more intelligent. Selectivity in sharing is for the wise. A few good posts are much more influential than many poor ones.

Not every post that doesn't align 100% to your opinions requires your response.

8 members found this post helpful.

Systemd... Let's see...

System Init
Login manager
Daemon manager
Version control system
Kernel loader
Journal logger
Device manager
Network manager
Cgroups manager

Is that enough or must anyone else continue onward Tobi? Seriously? Boycottsystemd listed every fact possible and most are cited DIRECTLY from every blog, post, email, etc. Lennart and Kay have written or contributed. There are no OPINIONS on that site. That site lists facts and they are CITED. Do you want APA or MLA formatted citations?

Of the lowest level you still need system init, daemon manager, and journal logger. That's still too much for JUST an init system. Daemon management is part of init, but the logger system?! No. The logger system should NOT be part of init, and it should not require DBus, expat, XML-parser, or any other optional package to support the init system. The logging system should not be writing in binary only. It should write in plaintext that is open to ANY system to read. DOS, Windows, Linux, BSD, etc. if it's unreadable... It's USELESS!

Oh so someone should shut up and bow down like a sheep? Me especially? I don't see you doing anything important to contribute to Linux or any distribution for that matter, so I have a right to be vocal as me and several others aren't bowing down, shutting up, and being silent on a serious matter.

So instead of telling me to shut up, why don't you get off your butt, contribute to at least 50% of the projects out there that are being deprecated by force due to systemd, give 100% to those projects of your intelligence, and maybe at least 50% of those projects would not need to be replaced.

1 members found this post helpful.

Systemd wants to replace MANY systems that run just fine, and are/were standard across many distros, Unix and BSD. SystemD is currently not posix compliant, so you'll be using systemd on linux and sysv init on Unix and BSD. You'll have to remember both.

I'm also not a fan of binary logging. I want to be able to grep the syslog. I don't want to rely on yet another utility to do something as simple as that. Also, if part of a text file corrupts, guess what: I can still grep it. But if the systemd binary file corrupts even a little, journalctl straight up says: Nope, sorry about your luck, that log is corrupted.

In the end, systemd has forced itself into the world of GNU/Linux via Red Hat. And the dude that did it is a notable person now according to wikipedia because he started systemd in 2011. He has no other previous notable achievements(the article was written in 2011, only mentioning systemd).

So that's who is spearheading the new init system, and we will conform to Red Hat's wishes, so there is literally no use in complaining about it.

So you also still mix systemd init with systemd the project. What is wrong with having several components in one source tree, if any of those components is a "do one thing and do it good" component (you know, UNIX principle). By the way, where does that ´"Version Control System" from? AFAIK, there is nothing like Git in systemd.
So having a mandatory logger component is against the UNIX principle?
Where does the UNIX principle state that dependencies are not allowed? I can't see any of that.
So because you think that a log always has to be plain text (and I am not even opposed to that) writing binary logs is suddenly against the UNIX principle? And how exactly is the log unreadable? You can use journalctl to read it.

Seriously, all what I can see here comes down to:
1. I have difficulties to distinguish between the systemd project and the systemd init system.
2. It does things other than I am used to it and it does only partially adhere to some holy UNIX principle.
3. Therefore I don't like it and post against it where ever I can.

Not meant for me, but here again that you actually don't get what systemd is all about: Providing one project that contains all components for building a basic Linux system, in one source tree. How would you do that with using external projects?

Part of that was already answered in my previous sentence, but I have a question about this: Name me the specific projects that systemd replaces that were standard across many distributions. Logger? sysklogd, syslog-ng, metalog, no standard. Time based starting of services? Dcron, anacron, vixie-cron, no standard.
In reality there are no inter-distro standards.
Actually no. The journal is only corrupted in that line that contains the corruption, all other lines are still readable.
Other projects from this unknown guy:
- Avahi: works fine for me to make it easy to interconnect my Virt-manager instances on different machines.
- Pulseaudio: works fine for me to have per-application volume settings, easy audio-routing, ... .

You can say many things about Lennart Poettering, but not that he is some unknown developer.

So what you are actually saying is: I have no clue about systemd, about how the project is organized, about how it is designed, about how it works, I am just against it. Thanks for clarifying, in the future I will only answer to your posts when there is actual content in them.

6 members found this post helpful.

TobiSGD, are you claiming that future bugs in the cited systemd components cannot cause pid1 to crash?

If not, then they're really not separate things.

1 members found this post helpful.

Tobi did you not even BOTHER to read this webpage?

http://0pointer.de/blog/projects/stateless.html

That's a Version Control System by textbook definition. Stateless systems, factory reset, reproduce-able, and verifiable systems...

That's version control down to the point. Controlling every aspect of the system to the point where anything going onto it can be installed, uninstalled, or updated, or even the system itself.

Worst case scenario:

What's to stop a distribution or a hacker of enforcing/invoking a factory reset at any given time?

Suddenly distribution-X says that because you have a non-distribution-X authorized package it will be uninstalled for license violation?

1 members found this post helpful.

I didn't tell you not to post, but to post smarter. That might not be within your ken.
While I'm nowhere near the LQ veteran that others can rightly claim to be, I've been hanging around here for a while. Seldom do I see such offensive posts. Apparently, not only have I never contributed anything important to Linux or any distribution (a claim which you make without any knowledge of me but that I will humbly acknowledge to be true), but I am less entitled to share my own opinions because of it, regardless of their merit. You claim to have a right to be vocal because you're doing something to prevent systemd adoption -- but you are working on another init system that does literally nothing to stop systemd adoption. The problem is going to be the deprecation of ConsoleKit in favour of logind, and the absorption of udev (mainly, anyway); these are the issues that force systemd onto users, not the mere existence of a popular but unwanted init system. If you created the best init system in the world, it wouldn't magically un-deprecate ConsoleKit. I'm happy enough with SysV init (for my purposes anyway) so I really don't care if you get Runit up and running. It does nothing to 'save us' from systemd adoption.
We all choose how we spend our time and how we contribute. Some code, some donate money, some write SlackBuilds, some write wiki entries or host blogs, some answer questions on LQ. None of us have infinite time, ability or knowledge. I like to think there is merit in each type of contribution, and it's what makes a community great.

10 members found this post helpful.

Don't you mean "Bob"?

Those components are not running in PID1, so the chance a bug in them causes PID1 to crash is exactly as high as the chance in any random daemon to crash a sysvinit PID1.

Then you are redifing Version Control System. Or would you say that my Android phone has a version control system because I can make a factory reset. Regarding your fear about hackers, chances that they do a factory reset are exactly as high as doing a rm- rf / or a dd if=/dev/zero of=/dev/sda.

Since you don't bother to address the other points I assume that you don't have anymore to say about that.