Sorry, but I can't see how this is related to the part of Arkerless' post that I have quoted:

I'm not sure exactly what you wanted me to elaborate on. Why text files are good?

This one, too:

http://www.lsdlinux.org/

No, what exactly do you mean with that statement? What do you want to edit and why does that not work anymore?

Well it's not just editing, it can also be reading, recovering, etc. Text files are mature tech, just about anything you could possibly need to do with a text file there is already a tool to do it. When you are working with a binary file, and it really doesnt matter that much if the format is open or not though of course open is at least theoretically better, but you dont get to choose from all of these tools that have already been built, no, you have to use a special tool just for this one file. If the tool you need has not already been created most of us are out of luck, open format or not.

And it's not me, I just avoid using it. But this guy for instance finds that the log files he needs become unreadable at just the moment he needs them which is just what I would expect from the design as I understand it. A single point of failure combined with a binary log sounds like a recipe for anti-slack to me. Googling the subject turns up a whole lot of similar complaints, bug reports, etc.

And yeah, it sounds very much like the windows registry to me. Both replaced a set of text files with a single binary file. The registry is definitely an improvement in some ways, but it is still probably the biggest single point of failure in the system. The vendor-specific tool has limited functionality and you just cant use standard tools on it. A fragile and non-repairable foundation does not make for a sturdy house.

3 members found this post helpful.

Now I get it, you mean the binary log file. Why not just saying that directly? Anyways, to address your points:

At first, any init system is and will always be a single point of failure, regardless if it is systemd, sysvinit, bsdinit, ... .
If binary logs bother you (and they definitely bother me) then simply don't use them. Install a classic syslog, it will even benefit from the extended logging capabilities of journald, since journald will pass through all the messages, even those that syslog doesn't catch normally.
The registry is for configuration, not for logging. systemd is still configured by text files, so the comparison with the registry is simply wrong. Even if you would compare the registry to logging, you cant just add text files to the registry, which can easily be done with systemd logging.

This is true in a sense but you are dodging the point. Normal init systems are not single points of failure for *logging* because a normal init system does not try to be a unified logging system as well.

If I understand that system correctly, you still have journald doing the same thing but exporting the datastream at the end, this does not sound more robust.

Obviously.

No it's not. They are both unified binaries that replaced a collection of text files. The comparison is apt and specific.


Actually you can. You can export the registry to a text file, and you can import entries from text files. Very useful capabilities but they still fail to ameliorate the basic fragility of the structure.

2 members found this post helpful.

If you want an alternative to systemd, our work in the LFS section on Runit is published and available. Translate it for Slackware (shouldn't be too hard) and you have a new init system.

It's standard UNIX scripting compliant, small, completely modular, fast, and very customizable. This isn't the only alternative so either get off your duffs and do some work to import Slackware a new init system that isn't systemd and can use either classic udev or eudev, or don't complain.

We worked hard to bring this forward on LFS. Do the work for Slackware, and you'll have your solution if you so choose.

2 members found this post helpful.

Making <foo>init like Runit work on Slackware is doable. Sure.

Making the DE's provided by Pat compatible with it is another task on its own.

Actually the DEs aren't an issue. You're referring to things like XDM, KDM, and GDM by chance?

All you have to with those is draft a run file to start the service, link it to the the runsv assigned desktop runlevel directory and make script executable.

Otherwise startx works all the same.

Well... gdm has dependencies on systemd - at least the current version does. gdm depends on logind which depends on systemd. gdm also depends on systemd for performing the cleanup that gdm should have been doing.

https://blogs.gnome.org/ovitters/201...temd-thoughts/

GDM does not depend on systemd. It only depends on having something in place which behaves exactly like systemd.

Seems a hair to split but it's not meaningless. IF GDM were important enough someone would just figure out precisely what functionality it relies on and implement that functionality in a sane standalone. With all the Gnome developers using systemd their requirements could easily change without notice or knowledge so someone would have to be pretty motivated to take that on and keep it up to date. Seems easier to me to just continue living without anything GNOME-related but YMMV.

I believe that is the definition of "dependency".
That is why it depends on systemd. The lack of documentation of what it "depends on".

Personally, I blew off gnome starting with gnome 3.

The PROBLEM that remains is that the gnome developers are forcing other desktops to adopt the dependencies too.

1 members found this post helpful.

I stopped using Gnome in Slackware when PV dropped it from -current.

Not only that, but KDM and XDM are included by default with Slackware, so truthfully, why bother with a DM that uses software that's unwanted or only a duplication? KDM can be used to launch Xfce, IceWM, Mate, KDE, OpenBox, FluxBox, etc. That makes GDM... USELESS!

Also, GDM's older version, as promoted on SlackBuilds.org, does not require systemd.

Your argument on that holds about as much water as a pot with no bottom.