Where systemd Came From & Where It's Going
Phoronix: Where systemd Came From & Where It's Going
Lennart Poettering recently spoke at a BarCamp in Warsaw, Poland where he talked about systemd. In the 100+ minute presentation, he covered where systemd came from, where it's going, and other details...
Very interesting talk, clears a lot.
I still hate systemd's logging.
ya ok, that guy on the right side that kept talking.
i hate him.
there wasnt anything really particularly new or groundbreaking in this talk, its all been said and done before in his blogs and previous interviews, everything he use to say systemd will do, he is now saying systemd is doing, and now we just have to wait for all the distros to suport it (he had a focus on mentioning how hes trying to "sell" systemd to various possible users). also i guess the other kernels out there should look into how to suport systemd, but thats pretty dificult because of the heavily used linux specific kernel functions. but they could do somehting similar to what openssh does where they have a openbsd specicific version, and then a general version. just split the code base. systemd is low level enough that as long as you kept the higher level stuff the same like the api and the user interface i dont think anyone will care if its a linux or hurd or bsd specific version. honestly i think thats what would have already happened if the otehr kernels were still relevent enough for that to matter. over the past 5 years everything not linux in the unix community has gained less and less spotlight. solaris is not dead but may as well be. hurd was never really born, just people talked about it because it was something to do, and bsd is falling behind because of its fragmentation and not keeping up with desktop inovations.
Maybe you perfer regex hell over searchable feilds?
Originally Posted by balouba
A bad binary format can be really bad, but a good one is at least tolerable. In addition it does things that a text format simply cannot (such as stroing firmware dumps) and being searchable in less than linear time.)
For I deal with structured logs daily, and gigs or teras of them, HELL YEAH fields sucks balls.
You see, first of all that's breaking all pipes. cat binary_shit | some commands..nope that does not work. That's the worse thing about it, by very, very far.
Then, fields don't match up. Like, one program decide "user" means something. Another program decides it means something else. THAT is what i call hell.
Then, searching isn't even really faster, and you got a database behind all this to index all the fields, to fix the speed (then its actually faster)
Then, fields are, guess what, SIZE LIMITED. Oh great, so you want to log a 1025 char command? Bad luck, it's going to be truncated. What, syslog doesn't truncate this anymore since 10 years? Too bad, that's not syslog.
Then finally, you write a program, and you just have no clue what fields to use. So you do like the others. You mess it up. You mix fields. Finally, you make a field called "message" and you put all the crap in it. Yay, thanks for nothing.
I reiterate. Systemd logging sucks. It sucks a lot. It's an error. Just like many other decisions, in the name of pushing your "product" and trying to be well known. Yay.
Note that the above rant, which also happen to be full of truth, is one of the reason why I like that Linus manages the Linux kernel. Such shit wouldn't happen at the kernel level, even when things are not perfect there, it just doesn't go to this level of crap. Linus will always speak up and trash the people who are interested into anything else than pragmatic solutions.
I wonder what will happen, when he'll be gone.
Originally Posted by balouba
Other than searching for specific data for diagnostics, what use cases require you to use log data in a script that are now horrible broken?