Uselessd
21–30 of 60 posts
Re: Uselessd
#22"like" (it happened to me) 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…
> 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. To be honest, if the format is done well there is no reason you cannot still read all the non corrupted records. textfiles corrupt too, you just generally live with them being broken be…
The binary logs are append only. The bug tracker entry says that they got "some corrupted logs" but not how. People get corrupted or truncated text logs all the time, they just ignore it because "oh the log ends midway through a line? eh".
The ridiculous "oh my god my logs will be always ruined thing" is a beat up by those who need to assassinate something about systemd, because it's always been devoid of any technical accuracy or discussion.
Re: Uselessd
#23Earlier quoted context omitted.
Not related to all binary logging, but journalctl is incredibly sluggish. Some combinations of slow (rotating) media, certain filesystems, and underpowered CPUs (ARM in my experience) and you get a barely usable logging system that makes you want to punch your box.
To be honest: that's kinda to be expected if you run it on a slow machine. However you can configure it to be in-memory only and forward to syslog and you have it as it was before.
I'm highly suspicious that syslog can actually be faster in such a situation. If you can't seek to the disk quickly, then it doesn't matter what you do - logging will be slow if you need to flush frequently.
Re: Uselessd
#24Grammar nit: I believe that "complementary kitchen sink" would mean that the kitchen sink goes really well with it, while "complimentary kitchen sink" would mean that the kitchen sink is included at no additional charge.
I believe it's the opposite. Compliment : positive quality. Complement : making a whole.
ps: not native english speaker.
Re: Uselessd
#25Grammar nit: I believe that "complementary kitchen sink" would mean that the kitchen sink goes really well with it, while "complimentary kitchen sink" would mean that the kitchen sink is included at no additional charge.
I believe it's the opposite. Compliment : positive quality. Complement : making a whole. ps: not native english speaker.
compliment (n.)
"An act, or expression of civility, usually understood to include some hypocrisy, and to mean less than it declares" [Johnson], 1570s, complement, via French compliment (17c.), from Italian complimento "expression of respect and civility," from Vulgar Latin *complire, for Latin complere "to complete" (see complete (adj.)), via notion of "complete the obligations of politeness." Same word as complement but by a different etymological route; differentiated by spelling after 1650.
complimentary (adj.)
1620s, "conveying a compliment," from compliment (n.) + -ary. In later use loosely meaning "free of charge."
complement (n.)
late 14c., "that which completes," from Old French compliement "accomplishment, fulfillment" (14c., Modern French complément), from Latin complementum "that which fills up or completes," from complere "fill up" (see complete (adj.)). Originally also having senses which were taken up c.1650-1725 by compliment.
Re: Uselessd
#26I do not want to spend the time to learn new things unless they are directly related to my work. So systemd was a PITA for me, but now I am fine with it (BTW, I have used UNIX since the late 60's so have seen a lot). This project looks great, but I do not have the energy to care, I will just deal with whatever comes with my distro. By the way, pick a better name. I suspect many OSS and home grown projects fail for the simple reason that the name, while clever, makes people either think the project is a joke, or some geeky thing, or unprofessional. Either pick an obvious descriptive name, or be prepared to spend a boatload of money building name recognition.
Re: Uselessd
#27Earlier quoted context omitted.
> 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. To be honest, if the format is done well there is no reason you cannot still read all the non corrupted records. textfiles corrupt too, you just generally live with them being broken be…
This is like saying. "I get shot going to work every day. But I bought a bullet proof vest, so life is okay." Iron bandages don't solve problems, they for a short time work around them. Except because nobody actually like writing systems level code, they stick- forever.
> "I get shot going to work every day. But I bought a bullet proof vest, so life is okay."
You get corruption if the machine shuts down incorrectly. In binary or text files. In that case journald/syslogd act like a black box. Syslogd will give you whatever garbage it has in those text files, journald will give you the surviving records and will tell you which ones are unreadable.
If you want to not get shot, shut down your machine properly. If you cannot shut down your machine properly because it crashed then you have data garbage if you want it or not. Drives work that way.
I'm not sure what you are arguing for.
Journald does not write broken records itself.
Re: Uselessd
#28"like" (it happened to me) 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…
I googled "libqrencode". Is it really QR code encoding?
Yep. It's because when you kernel panic most people do not feel like typing stuff off a screen. If you have a QR code on your monitor however you can easily scan it and it contains all the info about what is wrong.
That's a pretty good feature if you ask me.
Re: Uselessd
#29Earlier quoted context omitted.
I don't even have an esoteric setup and every time I want to read logs I'll have to wait 30 secs. Even though there is absolutely no activity.
Try "journalctl -e" or "journalctl --since today", it seems like by default it will load all available logs which leads to this slugishness.
it is slow because log is read written in a block binary format but pager accepts byte granular fseek feature to go forward without loading everything into $PAGER's buffers.
Re: Uselessd
#30Earlier quoted context omitted.
> 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. To be honest, if the format is done well there is no reason you cannot still read all the non corrupted records. textfiles corrupt too, you just generally live with them being broken be…
The binary logs are append only. The bug tracker entry says that they got "some corrupted logs" but not how. People get corrupted or truncated text logs all the time, they just ignore it because "oh the log ends midway through a line? eh". The ridiculous "oh my god my logs will be always ruined thing" is a beat up by those who need to assassinate something about systemd, because it's always been devoid of any technic…
A truncated text log can still be informative, and I've never had a corrupted text log hang or crash my text editor.