Greg KH wrote: > On Fri, May 04, 2012 at 03:50:24PM +0100, Steven J Long wrote: >> >> To confirm again, that this is about without initramfs:
>> > systemd and udev are being merged into one tarball. For the >> > "foreseeable future", it will still build 2 separate binaries. >> > What happens down the road if/when it all becomes one combined >> > binary? <snip> >> (It's much easier to introduce coupling between software in the same >> package. GregKH has also mooted a tightly-coupled "core" Linux distro, >> which afaict is the same reasoning as GnomeOS, and /that/ sounds like a >> clusterfsck waiting to happen.) > > "mooted"? > Yes, in the sense of "raised it as a possibility" or in this case a future direction[1] as discussed on debian-dev[2]. I'll assume you're just not familiar with the word 'moot' as a verb; originally the adjective meant 'on the agenda' or 'on the table', and 'to moot' means to raise an item for discussion. Its modern meaning of 'no longer worth discussing' comes from the judiciary: for it to be dismissed, it had to be under discussion in the first place, and so usage evolved. > And since when does having a set of tightly coupled base libraries and > systems that work well together somehow turn into "GnomeOS"? Reaching > like that is just foolish on your part. > When did I say that it's the same thing? I simply said it sounds like "the same reasoning." Compare: "There are a number of folk in the Linux ecosystem pushing for a small core of tightly coupled components to make the core of a modern linux distro. The idea is that this 'core distro' can evolve in sync with the kernel, and generally move fast. This is both good for the overall platform and very hard to implement for the 'universal' distros [such as Gentoo or Debian]." [1] ..with: "The future of GNOME is as a Linux based OS. It is harmful to pretend that you are writing the OS core to work on any number of different kernels, user space subsystem combinations, and core libraries.. Kernels just aren't that interesting. Linux isn't an OS. Now it is our job to try to build one - finally. Let's do it."[3] They sound like very similar reasoning to me. You misinterpreted what I said, which is one thing: there was no need to be discourteous. Let me be clear: I don't personally have an issue with udev talking to dbus (a requirement for it sounds wrong to me, but that's by-the-by.) It would annoy me no end, however, if udev required systemd, since I don't want to switch to it. And that is what we were discussing: possible future coupling between the two, which is much easier to do when the sources are part of the same package. Everything I need done on a desktop or a laptop in terms of hotplug, acpid events and wifi, the current udev has been able to do for years. I'd find it odd (read: the design smells) if those use-cases suddenly required new external dependencies. AFAIC vertical integration is supposed to mean closer downward coupling, typically skipping a layer or two; if it also means upward coupling, then the design is flawed ime. *shrug* What you do with your time, is your business. I'll evaluate any coupling that does or doesn't come up as and when, and make my own decisions then. That it's been mooted by you ;) means I'm glad others are doing work on busybox and mdev integration into openrc (I've read tonight that mdev works fine for simple hotplug like USB sticks) especially the applet to fsck and mount /usr early. OFC you could just assure us that udev will never rely on systemd as a design decision. I can understand that systemd might need close integration with the underlying udev implementation[PS]. SteveL. [1] https://plus.google.com/u/0/111049168280159033135/posts/V2t57Efkf1s [2] http://lists.debian.org/debian-devel/2012/04/msg00649.html [3] http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00439.html [PS] Though it reminds me of packages distributing libraries, and I'd question why one git repo can't be used to make two tarballs, with beta testing of udev alone by distros like Gentoo or Debian. A separate tarball would mean automated tests can be done, which is useful as a basis for systemd et al: another benefit of no upward coupling. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
