uselessd: Brought to you by boycottsystemd.org

astrogeek · 09-23-2014, 03:56 PM

Maybe we could just change the name of the best existing method to SysVinitd and stick with the proven winner? Sure would save wasting everyone's time chasing the biggest loser-d!

jtsn · 09-23-2014, 05:45 PM

Quote:

Originally Posted by randompie

But, the question is "What are the subdirectories that one can continue to have on separate partitions to
be able to comply with the new diktat of One Big /usr?"
1) Not /usr any more
2) /home - thank God for that

/home is just a replacement for /usr, where the user directories resided (i. e. /usr/home), before they got moved to /home.

Quote:

3) /var - given the crap that goes into it package cache, mail spool putting it on a separate partition makes a ton of sense, but
wait! It has /var/log on it.

There are even setups, where /var/log is a separate partition mounted with different flags. And /tmp, of course.

Quote:

4) /boot - yes that is still possible

/boot is just a workaround for separating the boot files from a cluttered /, when / = /usr

Quote:

So, by adding /usr and /var - my / goes from < 100 MB to 16 GB+! Why can't we continue to have small binaries, possibly self-contained and statically linked in the old /bin and /sbin? I have still not understood the rationale of the Big /usr? Avoiding duplication?

AFAIK the "UsrMove" was a design decision to make the BSD jails copycat "docker" work. But I didn't look into the details and I'm not interested.

szboardstretcher · 09-25-2014, 07:04 PM

Quote:

Originally Posted by ReaperX7

Journald is dead.

They removed it out. You'll still need rsyslog, sysklogd, etc.

I don't see this mentioned anywhere official. Is it just one distro you are talking about? Or is it a rumor?

Have a link?

ReaperX7 · 09-25-2014, 08:48 PM

http://uselessd.darknedgy.net/

Quote:

No journald. Consequently, this also means no libqrencode and libmicrohttpd integration, nor hooking coredumps to the journal. The default log target for auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG.

The main case against binary logs is their corruptibility. This happens more often than you’d think, due to not having any transaction consistency, as an RDBMS would. The advice of the systemd developers on handling this? Ignore it.

Otherwise, the main legitimate case for binary logs (but actually journald in particular) is Forward Secure Sealing. This is no longer a dealbreaker, since rsyslog supports log signing through GuardTime since 3.7.9 now. You can also use a combination of OpenSSL or the NSS signtool plus logrotate jobs to verify log authenticity, though this is more intricate.

Secondary concerns include /var/log/journal fragmentation (though this can be mitigated through the SystemMaxUse option in journald.conf and log rotation) and lack of a standard way to log to a database backend (though we speculate that some hacking with systemd-cat, FIFOs and shell script glue might do something similar, this has been untested and is rather fragile in theory).

The uselessd maintainer was able to remove the journald code completely from the codebase and after more stripping down the code, all he was left with was the bare bones init system, the part of the project that actually is the init system itself, no more, no less.

systemloc · 10-01-2014, 01:19 PM

Gradually, many bits and pieces of software that sit between the kernel and userspace are all hoovered up into one monolithic code block controlled by a single company. Because of the loss of all those various bits, there is only a single player that all other distros must adopt, as the alternative will no longer be developed or supported.

Now that's happened, a single company will be able to unilaterally dictate further GNU/linux development, or break other distros, maybe purposely, while advancing its own distro.

This is a clear "Embrace, extend, extinguish" strategy.

jtsn · 10-07-2014, 05:49 PM

Quote:

Originally Posted by systemloc

This is a clear "Embrace, extend, extinguish" strategy.

https://lkml.org/lkml/2014/10/7/254

ReaperX7 · 10-07-2014, 11:13 PM

No more systemd-shim then.

Guess it's back to reviving ConsoleKit somehow...