really unix philosophy, isn't it?
Not that I agree, but I believe that's what they said.
What is it that makes uselessd attractive? And why do you consider systemd to be bloated?
- journal
- networkd
- console
Linux has become a victim of it's own success. It's popularity has brought in a new generation of people that learned about computers from Microsoft and Apple and they are bringing the "design" ideas of that world with them because they usually have never learned the basics of what unix is and why so many people use it.
Don't get me wrong - if they want to make a community-developed OS in the windows-style, they should! If that solves their problems better than a unix, then I wish them well and hope the project succeeds. The problem I have is that instead of starting/forking their own project, they are trying to trying to redirect Linux at the expense of those of us that have been here since the kernel 1.2.13 days[2] because it was a unix. Instead of being a separate project, we get to deal with misinformation and bad design, while being labeled a "hater" for wanting to use a working unix instead of the systemd vision of the future[3].
/Sigh/
"Those who do not understand Unix are condemned to reinvent it, poorly." (Henry Spencer)
[1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html
[2] Slackware was already on version 3.0!
GNU/Linux, although historically mostly abiding by Unix principles, has always had syncretic aspects as early as the desktop environments experimenting with various fat RPC protocols over 15 years ago, and likely other precedents earlier.
The introduction of the various storage abstraction layers like devfs and HAL, plus all the other monolithic subsystem daemons in the form of the *kits that emerged early on, foreshadowed what would come today, even if they were mostly manageable back then.
This seems strangely backwards -- a lot of the "let's make this into files" philosophy like devfs, /proc, et. al. borrows from Plan 9, which is arguably more Unix than Unix; systemd on the other hand...
Possibly you are unhappy with binary logs - I'm not very enamoured with them either. Perhaps you don't like the name of that executable. But you can't say it isn't doing the one thing - your issue is not around the Unix philosophy but rather the design decisions of systemd.
> Write programs to handle text streams, because that is a universal interface.
ESR expanded on this in the "Unix Philosophy" chapter of The Art of Unix Programming:
> Unix tradition strongly encourages writing programs that read and write simple, textual, stream-oriented, device-independent formats.
> Before devising a tricky binary format to pass data around, it's worth experimenting to see if you can make a simple textual format work and accept a little parsing overhead in return for being able to hack the data stream with general-purpose tools.
(And no, journalctl and systemd-cat don't fully replace the ability to run text-processing programs like grep, head, tail, etc. directly on the stored data.)
grep, head, tail, etc. work great when you have a small amount of logs. But if you have a production system with lots of logging data, processing plain text can become too slow and/or icky parsing-wise.