Well, kinda. Feature list does look like basically random assortment of vaguely related things (or "toolbox" if you want to be nice).
But... things that are also just useful often and for what you'd need to spin off a separate service for, or make suboptimally in whatever (No)SQL you use to store your data.
So it is perfect if you just want to prototype whether given approach is viable, and "good enough" for many apps.
Pretty much. If it was just some guys project nobody would give a shit until it was actually well tested and proven.
But it was made by guy hired by Red Hat so instead of maturing and having to take actual user feedback before being used in anything significant it was pushed by a guy that vision is limited to "It works fine on my laptop".
Who then decided to reinvent everything along the way like log storage that still takes over hundred of file opens (and tens of seconds) to get "the last 5 log lines of a command" ( https://github.com/systemd/systemd/issues/2460 ), because why the fuck use say SQLite when you can have fun evening inventing your own shitty binary journal format.
I do find a lot of stuff behind systemd useful but the ever-present half-assness of its solutions is annoying. Half-assed logging here, half-assed dhcp client there, quarter-assed ntp client elsewhere, all while basic functionality is still riddled with edge cases.
Still a net positive over having to fix yet another fucked up init script...
This has not been my experience at all. The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be. The big controversy was when systemd-resolved implemented the spec to the letter and broke people’s assumption that listing DNS servers in order means they’ll be queried in that order.
> The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be.
Really, the issue here is that "how it used to work" is mostly unambiguous, but I have no clue what you mean by "the spec", and I suspect you're actually referring to a multitude of specs, several of which were only created in the process of writing the relevant systemd components.
the binary logs handled by the systemd journal can be "sealed" at regular time intervals. That seal is a cryptographic operation on the log data such that any tampering prior to the seal can be detected.
You probably will be getting at least one bit of randomness out of it if the input is not saturated (As in not below 0 or above reference voltage ADC is using), just because pretty much all ADC are noisy enough that the last bit will be flipping. Of course that doesn't excuse every other problem with it
> Meaning that there is no hardware security whatsoever and it's trivial to extract all your keys from the device if you ever lose it. Whoops.
Most micros, ones used in various Arduinos included have fuse bits so there is at least the minimal level of protection. Question whether they used it even...
> The only line I'd remove or finesse is "Yeah, this is complete garbage." Otherwise, I think this is a great example of how to convey anger without personally attacking anyone.
Strong words are best way to convey the issue in a way that leaves no room for inaccuracies.
Sugarcoating it helps no-one as some people might inaccurately think it was not a big fuckup. If you use words from the very end of the expressivenes range there is no room left to doubt
But... things that are also just useful often and for what you'd need to spin off a separate service for, or make suboptimally in whatever (No)SQL you use to store your data.
So it is perfect if you just want to prototype whether given approach is viable, and "good enough" for many apps.