On 10/02/2016 05:08 AM, stakanov@freenet.de wrote:
His second point is that using interfaces that are only usable through systemd are like a vendor lock in. And in this I am quite able to follow the argument, things should stay modular.
That that sort of misses the point, doesn't it? First the old sysv-init parts were only usable with BASH. Not the original Bourne shell, not the enhanced 1988 model Bourne shell. Not the C shall and not some of the other alternative shells. Oh, and not with Windows, either. Or the Atari, the PlayStation or the X-Box. Or VMS. Or VM/CMS. And yes, I know, each of those does 'vendor lock-in' as well. So its a fundamentally irrelevant argument. The second this is that systemd *is* modular. That it depends on sending messages via the D-Bus or sockets to the init process doesn't make it any less modular than the dependency sysv-init has on the shell, and the original arguments about interactions and side effects that ere the origination of systemd are perfectly valid criticisms of the inconsistent and unstructured approach of sysv-init and arbitrary, ungoverned shell scripts. The 'unit' approach of systemd is modular, regular, consistent and governed. In Ancient of Days, UNIX prided itself on having a very few, regular and consistent interfaces and relying on what amounted to a few basic patterns of operation and governance. You leant to few patterns rather than dealing with the huge number of interfaces and the collection of 'sui generis' operations. I recall reading about a comparison with VMS in the 1980s. A VMS developer in California commented that the bookshelf of the VMS documentation was a major threat if it collapsed on him in an earthquake. The UNIX documentation of the time, even the bloated USG version which I still have, occupied less than half a shelf. UNIX became and in turn Linux became more complex and more complicated in its interfaces and gyrations, and more arbitrary and unstructured. Saying all of sysv-init was in one place and only used the shell totally misses the point about the lack of discipline and order in those scripts. Even the 'baseline' ones of a distribution were only as 'regular' are the packager was willing to make them, and that could never be guaranteed. Once you added in 3rd party initializations, and customizations, who knows what might happen. There were no constraints, no checks. That systems go though increases in complexity with size and then a ratification as they become unmanageable is as axiomatic aspect of General System Theory. So too is that people in any population, even where the change is for the best for the whole group, resist the change for emotional reasons. Perhaps they do have too much invested in the old way of doing things. But I don't think this is the case here. Computers, software, the whole IT business is about innovation rolling 'ever onwards'. The profit lies in change. -- http://m.likesuccess.com/quotes/27/1312072.png -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org