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