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 ;-)