Grammar 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.
Uselessd
11–20 of 60 posts
Re: Uselessd
#12do not care.
i've lost interest in systemd stuff now. use it. don't use it. whatever
Re: Uselessd
#13Earlier 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.
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.
Sounds like you're running into some bug. I've never run into any perceptible lag.
Re: Uselessd
#14"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 because you can read the unbroken stuff.
Going by the bug tracker the journald approach is to make the reader work with broken files better.
Re: Uselessd
#15Earlier 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.
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.
That sounds odd. Did you try to strace it and see what it actually does?
Re: Uselessd
#16"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…
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.
Re: Uselessd
#17This is a very good initiative.
But linking "GNUisms" to the communist party website is just dumb.
Re: Uselessd
#18Earlier 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.
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.
Re: Uselessd
#19"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?
Re: Uselessd
#20"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…
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.