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). :p
Regards. |
Quote:
|
Quote:
|
Quote:
|
Quote:
Not every post that doesn't align 100% to your opinions requires your response. |
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! Quote:
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. |
Quote:
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. |
Quote:
Quote:
Quote:
Quote:
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. Quote:
Quote:
In reality there are no inter-distro standards. Quote:
Quote:
- 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. Quote:
|
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. |
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? |
Quote:
Quote:
Quote:
|
Quote:
|
Quote:
|
Quote:
Since you don't bother to address the other points I assume that you don't have anymore to say about that. |
All times are GMT -5. The time now is 07:57 AM. |