The Development Pace Of Systemd Fell Sharply This Year

[unixfan2001]

Generally binary logs mean you get better read/query performance but they are vulnerable to file corruption on crashes or incorrect shutdowns. It's a trade-off.

But on the upside they're not vulnerable to malicious modification.
Text logs are kind of pointless in security conscious environments.

[ldo17]

Generally binary logs mean you get better read/query performance but they are vulnerable to file corruption on crashes or incorrect shutdowns. It's a trade-off.

We know how to handle problems like that with database files. Or indeed, entire filesystems.

You couldn’t use UTC timestamps with text-based logs--at least, not so conveniently.

[Guest]

I know it is an improvement in usability and security. It is something I appreciate. I can query the journal very quickly.
I just would like journald to somehow make sure journals don't get so easily corrupted on incorrect shutdowns or lockups. It's not urgent as they rarely happen unless I am experimenting with something but it would be nice if this is something that can be improved on.

[L_A_G]

Do you think it could be that, rather than not having guts, they might simply not agree with you? Afterall, it wasn't just one person who caused SystemD to spread throughout the Linux world - it was all the people who have contributed to the project itself, all the people who worked to get it into Fedora, into SuSe, into Debian...

If you haven't been living under a rock for the last couple of years you'd know that dislike of SystemD and the way it's trying to essentially become an OS in and of itself is pretty widespread in the Linux community with distro forks coming to being just to provide a non-SystemD alternative after the distro adopted SystemD.

Don't get me wrong, a replacement for init has been needed for a long time already, but SystemD is essentially what happens when you have an inability say no to feature requests.

[Brane215]

Don't get me wrong, a replacement for init has been needed for a long time already, but SystemD is essentially what happens when you have an inability say no to feature requests.

IMO feature creep is not a problem as much as half-assed implementation. Take journal, for example. It should be robust and fast, useable for many non-systemd applications.
What we have ended up is often very slow ( it can take quite a while for journalctl -b -s xxx to parse to the end of journal) and not that robust or reliable.


Or just about any feature theya decided to implement. systemd-networkd, for example. After bazillion of failed attempts with stupid bugs, what we ended up with can in some cases work for you. If it does, great. If it doesn't, use your own. There is basically no implemented tool that can replace original 1:1.

And that's even before we come to the argument that should be main point of systemd - fundamental infrastructure integration. Systemd should be an ideal place for tools that take care of:

- network topology and connectivity changes and propagation of changes to services ( nfs/smb mounts etc)
- locale and terminal management
- simplified intramd infrastructure for FS check and system rescue
- session control and integration with desktop management
-SW/system upgrade helpers and service restart etc


IOW, I would expect from tem much more modular approach, allowing much better customisation and higher quality of final tools. What we ended with is implementation that fits probably someone's needs with minor allowance for tweak here and there.

[carewolf]

You must be raving.

OSS in the kernel has been dead for years.

OSSv4/4Front has been dead for at least three years.

OSS is maintained only in various BSD distros.

I am making fun of the fact that ALSA development is also dead and have been for a decade.

[ldo17]

IMO feature creep is not a problem as much as half-assed implementation.

Feel free to show us how it’s done.

You know the old saying: lead, follow, or get out of the way.

[bkor]

IOW, I would expect from tem much more modular approach, allowing much better customisation and higher quality of final tools. What we ended with is implementation that fits probably someone's needs with minor allowance for tweak here and there.

I'm not using networkd. I did start to use the resolver, but I that was optional as well.

Your examples of not modular are poor. Journald you can configure it doesn't store its stuff. A lot of the rest is optional.