Am 03.03.2017 um 20:58 schrieb Anton Aylward:
On 03/03/17 11:35 AM, Stefan Seyfried wrote:
I really could not care less who writes a piece of software. If it works well.
That's a it simplistic. Its simplistic on a number of counts.
First and foremost, "works well" .. for who (or is it 'whom'? Are there any Grammar-nazis around?) ... and under what conditions and constraints?
Lennart pointed out that SysVinit could fail and break the system under quite a number of conditions.
I think nobody really disputes that. But the implication that systemd is different is... not what I'm experiencing. In my experience, and I have seen quite a number of productive machines of all sizes, those sysv tfailure cases were rare and easily worked around. At least on the systems "where the money is", as you liked to put it. In practice, systemd works best on hobby systems. Less than 128GB of RAM, not much stuff going on, but some dynamic stuff (USB sticks being plugged and unplugged, WIFI connections, fast SSD storage). Unfortunately those are not the machines "where the money is". The bugs / problems I'm finding in everyday usage are on other types of machines, where it becomes absolutely clear that this stuff was obviously not heavily tested besides some hobby-class machines. And then people tend to think "what problems does systemd really solve for us, and are those worth the new troubles we have now?" And while I'm still advocating systemd (even though you might not believe that, but I'm as realistic that I don't think it is going away soon, so we definitely need to cope with it), I'm not going to tell anyone it's a great piece of software / engineering work when it isn't. What I like about it is, for example, that you no longer need to care if you are on a SLES or RHEL machine -- the concepts and procedures are the same now. The biggest problems we had before with old sysv init was -- mostly due to bad init scripts -- "oh, the service wants to start but $DEPENDENCY is not yet there". This was often solved -- ugly, but working -- with a "sleep 60" in the services init scripts and the machine ran happily ever after. And on servers that need 10 minutes to even run through the BIOS, 5 minutes to start up their disks, then (already in the Kernel) another 5 minutes to online all their processors and initialize memory, nobody could care less about that 60 seconds delay. But people do care, if the task is "get the logs out, then reboot ASAP" if dumping 4GB of journal to stdout takes more than 8 hours. And no, the forwarding to syslog does not forward everything. So you need both, syslog and journal.
Then there are issue to do with what I'd term 'communication'. Is the code clear? That begins with not in-line comments or a man page, but with a clear statement of architecture and objectives. On that count, systemd wins hands down over SysVInit, which has no formal design, no defined protocols, is all 'informal' and 'just grew'. In fact that's its problem, some code did things that were not very good, for reasons that were unclear.
Well, if I look at systemd, there is also some code that does things that are not very good :-) And I only can guess the reasons why it does them bad instead of good.
Which gets into the issue of 'maintainability.' If you've ever been a maintenance programmer you'll know that having a clear statement of architecture and objectives, what the code is doing (or not doing) what it is, over and above the in-line comments, is vitally important. If you don't understand this then any changes you might make could end up being damaging.
Some programmers do take this care. Some programmers make sure that their work is 'resilient', that is that "it works well - even when abused".
And you have the feeling that systemd programmers do?
So yes, I do care who writes it.
Yes, and in this regard, I have a certain opinion about systemd, from experience and past bugs. But I would think (not being a native english speaker) that this is considered "ad hominem". If I'm expressing "I'm not going to trust software from Bob, because the last 5 years his stuff had a constant history of stupid bugs", then this is something slightly differnt than if I would be saying "I dont trust Bob's software, because I don't like him".
[...]
There are a few other programs I use that were built by people with a vision and with a discipline. All are incredibly well designed, well architected and well documented.
And that relates to systemd how exactly? ;-P
VIM? Yes, its like systemd in many ways. And trust me, Bill Joy's original VI code was bloody awful! The designers of VIM threw it away and went back and worked on a properly architected editor that just happened to have the same UI. But because it was well architected from the start it became extensible in ways that Joy's wasn't, all without breaking it.
A compiler is probably the most complicated piece of software you'll use, but GCC is, like systemd, like vim, very modular and extensible. Again, vision and architecture and coding discipline.
I DO care about who writes the code I use.
Yes, in this sense I do, too. But I wouldn't dismiss code on ground of who wrote it (which is what I understood you wanted to express with accusing me of ad hominem attacks). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org