Hi Ian, Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > My point was that someone who is writing an init system for concurrent > startup and dynamic service management needs to have a good > understanding of concurrent system design, and in particular of race > hazards. I wouldn't expect a person or people who had such an > understanding to make many mistakes of the kind seen here. Neither do I, but there is no evidence for _many_ of these problems.
>> Personally, I don’t know about every little detail in fd passing >> either. If I read you correctly, you seem to be saying one needs to be >> an expert in a given area before being allowed to write code in it. I >> think it works the other way around: by writing code in that area, you >> become an expert in it. > > What a startling statement. This is not some desktop toy we are > talking about; this is critical core system infrastructure. > > I would prefer my pid 1 to have been written by experts. It appears > that you are saying that systemd wasn't and that this isn't important! To clarify: I do think (most?) systemd authors are experts. I am also saying that experts can make mistakes, and that having the expectation that software has 0 bugs is unreasonable. I also stand by my statement that one cannot be an expert in a subject area before having experience in that subject area. Sure, one can prepare, but there is the proverb “practice makes perfect”. >> Instead of focusing on the actual security issues, what I’d much rather >> look at is the process with which such bugs are fixed. I.e. are security >> problems acknowledged as such, are they fixed clearly and in a timely >> manner? Are there enough eyes looking at the project to uncover, report >> and collaborate in fixing the issues? > > I don't think having a functioning security response process is a > substitute for good system design, and a high initial code quality. No argument there. I think having all three of them is better, and that’s my opinion of systemd, at least of pid 1, which I have looked at more closely than at the other parts of the larger system. >> Also, and I think that should go without saying, if this branch of the >> discussion is considered as reasoning against systemd in the decision >> process, I’d like to see similar data on the other init systems :). > > You are of course welcome to go and find that information. I may be misunderstanding how this works, but I strongly believe that if the ctte looks at the security track record of systemd, it MUST also look at the security track record of the other contenders. I.e., I consider it unfair to say “we’re not using systemd because it had security bugs, we’ll chose X instead, but we didn’t look at its security at all”. That said, I’d love to help, but I don’t have the time to look at the security track record of other init systems in detail. Sorry. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
