On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote: > On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote: > > > Well, systemd and udev are developed by the same developers. Both > > > daemons interact very closely and integration of the sources was the > > > natural consequence. > > > > udev and pulseaudio are developed by the same developers. Both daemons > > interact very closely and integration of the sources was the natural > > consequence. > > > > glibc and the kernel is developed by the same group of companies. Both > > interact very closely and integration of the sources was the natural > > consequence. > > > > Internet explorer and Windows are developed by the same company. Both > > interact very closely and integration of the two was the natural > > consequence. > > > > I'm not sure I agree with any of those arguments. > > Ok, I should have added that both udev and systemd are also very > closely related. So there are certainly benefits of merging the code.
Until their source repositories were combined, there was little "close relation" between the two. They might be more related now that they exist in the same git repo, but I remain highly sceptical of the technical and other benefits of this merge. A tool which is fundamentally geared to creating device nodes and other tasks related to that need not be tightly-coupled with /any/ init system. Even /with/ the merge, they still aren't that coupled, except to force them to appear so. > > > Yes, it makes it more difficult to use udev with a different init > > > system, but again most people don't care > > [citation needed] > > Well, it's obvious, isn't it? I mean, I am talking about the average > joe. I didn't hear anyone complain when Apple switched to launchd in > 10.4 and I have really never ever people arguing about what init > daemon is the best until systemd came up. I can't get rid of the > impression that the rejection of systemd is solely based on technical > merits. Let's make one thing clear here. The argument about which system is "the best" or has the "most features" or is "most modern", or whatever, is pointless. The Debian GNU/Linux system is used in many different ways, for many different purposes. There is not, and can never be, a "one size fits all" init system. file-rc, s6, sysvinit, upstart, systemd, and others all have their uses. None of them are suitable for all use cases, and each have use cases for which they are the optimal solution. The most important consideration is having an operating system which can meet the needs of our userbase. Retaining the flexibility to change init systems to suit those varied needs is a key part of this. Forcing our users to use the One True Init is not helpful, and reduces the flexibility and usefulness of the system, as well as hindering future development. > Well, but I would say Ubuntu is to be blamed here. As opposed to > upstart, systemd has many supporters and contributors in the industry > (Intel, ProFusion, SuSE, RedHat) while upstart is virtually only > actively developed by Canonical if am I not mistaken. Plus, you have > to sign a contributor's agreement with Canonical which leaves a bad > taste in my mouth. That shouldn't be the case with true free software, > should it? Enough. None of this rubbish has anything at all to do with Debian. You've taken your fanboyish advocacy of systemd to a ridiculous extreme over the last week or so. Please tone it down. Nothing done in Debian has anything to do with any of the above companies, and if anything, having all those "supporters and contributors" attempt to ram systemd down our throats whether we like it or not counts against it rather than for it. > Sure, I don't disagree on this point. But again, don't you think it > makes sense to got into that direction when the adoption rate of a > certain software is high? > > I mean, just look at the popcon numbers for systemd vs upstart: The popularity of the systems is meaningless. Neither are the default. upstart only became functional this last week. None of this has any bearing on anything. > > udev took quite some time to be accepted by the community too, but now > > it's probably fair to say that it has been. To try to couple that to > > systemd sounds like a bad form of systemd advocacy to me. > > Yes, I agree it leaves a bad taste for sure. But again, I am not so > sure if we really need to be able to choose our init system. I mean, > do we have this discussion over mdev vs udev? Or even devfs? Yes on all counts. Look very hard at what Wookey wrote. It's really quite important. Being able to swap out and replace the different low level components of our system is critical. These are just userspace components, not kernel interfaces. Replacing them should be relatively simple. If the new udev fork works, why /wouldn't/ we want to adopt it? It would have a friendlier upstream, it would be buildable without unwanted extra stuff, and it would have better future prospects. And it wouldn't be maintained by the systemd maintainers, so we wouldn't have to worry about them crippling or breaking it. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20121129235112.gm14...@codelibre.net
