Re: Being part of a community and behaving
]] Raphaël Halimi
> > I didn't read the code. Depending on where and how this happens, I can
> > understand that someone doesn't want to make a call that blocks
> > arbitrary long. So if you get a timeout, what else could you do?
>
> I don't know, like I said, I'm no developer. But the comment was clear
> on the fact that the developer deliberately chose not to wait on the
> syslog. For a piece of code which is supposed to feed the syslog, I find
> that choice illogic, to say the least.
You have two choices: you can drop the oldest or the newest log entries
if syslog doesn't keep up. Apparently, you prefer to ditch the newest
ones, the code ditches the oldest ones.
> > I also find it hasty to judge systemd's code quality from a single
> > example. The analysis of Russ and several others suggest that actually,
> > systemd has a fairly high code quality. That's not something I can
> > comment on; but they do seem to be eager to get rid of old cruft (many
> > say, too eager), which certainly helps keeping your code clean.
>
> Sorry, english isn't my native language so maybe I wasn't clear. I
> didn't *judge* all of systemd's code to be of poor quality; but as for
> the little piece I looked at, I have a bad hunch about it. And the
> general "wontfix" attitude of the developers just add to that hunch.
Have you actually interacted with any systemd developers? Your
experience doesn't match mine at all.
> But again, we pull away from my first point - as a sysadmin, what I can
> see is that my systemd box has crippled text logs, and the point is
> that's not worthy of the quality that we're all accustomed to, and which
> made me choose Debian 15 years ago.
How do you know that your old setup didn't lose logs too, but just
failed to record it?
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: