Samuel Thibault <sthiba...@debian.org> writes: > So you believe that systemd already implements all the important details > that readahead+inetd+udev+autofs+fsck+quota+swapon+kbd+getty+etc. have > polished over time?
I suspect there are corner cases that are not yet polished properly, which is why people run it and report bugs. That's already being done in Fedora, of course, similar to how upstart has been tested, debugged, and polished by use by thousands of Ubuntu users and corner cases were discovered and fixed in the process. I also think that it and upstart have an inherently better design than some of the components that they are replacing, and don't have to deal with as much historical cruft that, within the context of that design, is no longer necessary. That makes the code much less complex, which in turn makes it less buggy and makes ongoing maintenance better. Yes, well-tested historical code is rock-solid in the areas in which it's been well-tested; that doesn't mean that adding a new feature to a crufty old code base is much fun, nor does it mean that code is resistant against bugs introduced by necessary new modifications (and there are always some of those). Sure, I'm sympathetic to the idea that one shouldn't replace subsystems but just evolve the ones one already has. That's often the right approach. But it isn't *always* the right approach, particularly when other people have already done quite a lot of the work of developing a replacement subsystem and there are architectural reasons for doing something differently that are new from when the old subsystem was originally written. You can add GSS-API authentication, encryption, and a wide variety of other things to ftp. Yet, as it turns out, we're mostly all using sftp instead these days, which was a completely new implementation that didn't do a lot of the things ftp did (and, indeed, still doesn't; I don't think sftp has a TENEX mode) and didn't have all the bugs ironed out at first. But, in the long run, it's now what everyone uses. This happens in computing. It's part of the natural process. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878visjkij....@windlord.stanford.edu
