On Wed, Aug 6, 2014 at 5:54 AM, Slavko <li...@slavino.sk> wrote: > Dňa Tue, 5 Aug 2014 16:33:23 -0400 Tom H <tomh0...@gmail.com> napísal: >> On Tue, Aug 5, 2014 at 9:50 AM, Slavko <li...@slavino.sk> wrote: >>> Dňa Tue, 5 Aug 2014 08:58:47 -0400 Tom H <tomh0...@gmail.com> >>> napísal:
>>>> If tomh-init is faster than htom-init, whether there's just ssh >>>> running or 100 daemons running, I want to use tomh-init. >>>> >>>> I can understand that there are people who don't want to adopt >>>> systemd simply because it boots faster because they dislike some >>>> other aspect(s) of systemd, but attacking systemd because it boots >>>> faster is silly. >>> >>> I know, that you are not responding to me, but i have one note: >>> >>> The boot speed is often used as argument for the systemd. But no all >>> users are interested on boot time, then there are reaction as this >>> (and as my). IMO, there aren't a lot information about other >>> aspects of systemd and then people (include me) don't know about >>> them. >>> >>> Until will be boot time again and again used as argument, then here >>> will be responses as these. >>> >>> To be precise, i often read about these things: monolitic, binary >>> files and boot speed. I don't like first two and i am not >>> interested in latest. >> >> I thought that I'd answered you. >> >> I'm objecting to this line of reasoning: I'm not interested in boot >> speed therefore I'm not interested in systemd. >> >> Since you're not interested in boot speed, you shouldn't care that >> boot's faster with systemd! You don't have to dislike everything that >> systemd claims that it provides. >> >> But if you want to say "boot speed isn't enough of an argument for me >> to like/use systemd", fine. > > Yes, that is what i mean, thanks for help - writing my thinks in > English is sometime terrible for me. You're welcome. I'm glad that we cleared this up. > Yes, you have rsyslog for storing logs in text files. Now you have two > deamons for one thing. Nice, but where is the advantage? > > I understand that sometime there is time to change, e.g. from text to > binary files, it is OK. But to i (and perhaps others too) can accept > this change, it must give something, what is useful for me. Imagine if the systemd maintainers proposed to replace rsyslog with journald. I'd unsubscribe for a month or two in order to let the outrage die down. :) At my $day_job, as part of our future RHEL 7 rollout, we're looking into using journald for local logs and configuring rsyslog to send our logs to a dedicated syslog server without storing any of the usual "/var/log/" files locally. This is from an email by Lennart: /var/log/messages is *very* badly designed: The timestamps do not contain a year The timestamps do not contain a timezone The timestamps are accurate to the second only PID information is optional, not implied PID information is fakeable, because user supplied The file "tag" part is completely optional, free-form, and fakeable by unpriveed clients The files do not carry any information about the log priority The files do not carry any information about who is logging (service, process name, argv, binary path..) The files do not carry any information about the credentials of who is logging (uid, gid, selinux context, audit, ...) And so on and so on. It's so bad, that rsyslog upstream even suggests not to use these files anymore, but write them in a more modern formatting that leaves a bit more information in (such as iso timestamps). But you know what? If you do that than all your compatibility is gone too. The interesting things is that "journalctl" is *better* at generating the same text stream that is normally contained in /var/log/messages than /var/log/messages itself is. "journalctl" can stuff more information into it then /var/log/messages. And how does that happen? Because we have more data around. We can agument the ouput with colors (indicating priorities), we can add additional informational separator lines (indicating reboots), we can add add in fields that aren't there (such as the tag from the comm field, or the PID). We can timezone correct the timestamps (because we have UTC times). And we can filter by any of the fields, securely. So, yeah, /var/log/messages sucks, and journalctl is better at generating a compatible output that that file ever was in itself. I didn't save the URL :( And another: > So maybe we (Fedora) should go with XML instead of binary or some > dedicated RDMBS for storing system logs? I'm not against binary log > format but try to understand why it's superior to text and also why > something more sophisticated isn't used if we really need this > additional meta data that could not be included in plain text? XML and text files are not sanely indexable. Real database are large packages that we cannot pull into minimal systems. Beyond that, and that's most important: the specific requirements are different from what those systems provide. We want something minimal, C-based, that can work without any service around, that can be mmapped by multiple processes at the same time. Something that indexes implicitly by all keys without any pre-defined schema. Something that is primarily append-only (for robustness reasons). Something that is indexed by time, and interleavable. Something that can store binary blobs, that can optionally compress larger blobs. Something that can be rotated. Something that supports Unix access controls natively. Something that provides us with the right complexity guarantees. And more... I didn't save the URL either. Sorry. > Then what are advantages of the systemd? I see only disadvantages... I've saved one or two relevant URLs from debian-devel@ pre-CTTE bug thread. I can dig them up and post them if you're interested. Personally, I don't care. It's what I have to use so I've learned about it and I'm using it. End of story. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAOdo=sy3xr5srawfpywnjy_x3lmv-vq605ydewftk6ia7qr...@mail.gmail.com
