The eudev project launches

Posted Dec 18, 2012 0:52 UTC (Tue) by gfa (guest, #53331)
In reply to: The eudev project launches by HelloWorld
Parent article: The eudev project launches

need to 's/eudev/redhat/' for your comment to make any sense

proof:

upstart is older than systemd
mkinitramfs is older than dracut
systemd+udev merge does not make any sense, they are just pushing systemd everywhere
/usr on a separate partition has worked for ages (and still works everywhere !fedora)

The eudev project launches

Posted Dec 18, 2012 2:16 UTC (Tue) by HelloWorld (guest, #56129) [Link] (8 responses)

upstart is older than systemd mkinitramfs is older than dracut

Whether a project makes sense or not has nothing at all to do with whether it's younger or older than some other project. systemd is a good and useful project despite having been started after upstart because it's technically superior and one couldn't have altered upstart to provide the same functionality without essentially rewriting it from scratch.

eudev otoh is useless. udev works perfectly fine without systemd, and while it's true that udev doesn't support old kernels, it doesn't really matter. Because why would you run a long-obsolete kernel, and yet require a brand-new version of udev?

systemd+udev merge does not make any sense

This is a development issue and thus should be left up to the systemd/udev maintainers.

they are just pushing systemd everywhere

How so? Udev works perfectly fine without systemd.

/usr on a separate partition has worked for ages (and still works everywhere !fedora)

The "separate /usr" thing has nothing, zilch, nada to do with systemd or udev, both work perfectly fine without /usr. The only difference between systemd and upstart/sysvinit in this regard is that systemd prints a warning (which you can choose to ignore).
There are things that break when /usr isn't mounted during early boot, though perhaps it doesn't affect your system. Do you really think Poettering makes that kind of stuff up just to piss people off?
Fedora supports a separate /usr partition just fine by mounting it inside the initramfs during early boot.

Get your facts straight next time before making random false accusations.

The eudev project launches

Posted Dec 18, 2012 2:50 UTC (Tue) by gfa (guest, #53331) [Link] (2 responses)

i won't reply all your comments, because is boring.

i will just say, Adam Jackson and Poettering on many ocation accused ubuntu (or other distros) to fragment the comunity, while they suffer from NIH sindrome. i haven't see any proof that systemd is better than upstart

the dracut documentation on freedesktop suggest not to implement another initrd maker because dracut is here, the same rationale could be applied to mkinitramfs which is older, extensible and better tested than dracut.

i don't care what fedora/rh guys think about how linux should be. just don't bother us with your bloat, many of us are very happy with sysinit, shell scripts and such. leave our tools alone

udev+systemd is not fine
http://lists.freedesktop.org/archives/systemd-devel/2012-...

bye, have a nice life (i do)

The eudev project launches

Posted Dec 18, 2012 3:03 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

You haven't provided any reference for your claims about Adam Jackson and I suspect you don't have any and just made that up. Also, you seem to misunderstand the link you have provided which has nothing to do with separate /usr and there isn't any Fedora specific issue here.

If you want to understand, the differences between mkinitramfs and dracut, refer to https://lwn.net/Articles/317793/. There is a reason why several distributions have adopted Dracut by default now

If you want to continue using a older init system and shell scripts, you are welcome to.

The eudev project launches

Posted Dec 18, 2012 3:09 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Ah, trolls. They just don't make them like they used to any more :(

The eudev project launches

Posted Dec 18, 2012 17:51 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

Because why would you run a long-obsolete kernel, and yet require a brand-new version of udev?

Because new versions of udev contain new libudev APIs, and applications can depend on those. Were it not for eudev, we'd be required to upgrade the kernel in order to run such applications. This sort of tight coupling is not good. (Well, OK, some people seem to think that the tighter the coupling, the better, but I very much hold with the traditional viewpoint that loose coupling is to be preferred.)

The eudev project launches

Posted Dec 18, 2012 18:29 UTC (Tue) by HelloWorld (guest, #56129) [Link] (3 responses)

> Because new versions of udev contain new libudev APIs, and applications can depend on those. Were it not for eudev, we'd be required to upgrade the kernel in order to run such applications.
You have a point, but I don't think that this is a good reason to fork udev. As Cyberax pointed out (https://lwn.net/Comments/529570/), that kind of thing can be done within a branch. Git makes this kind of work flow quite easy, and eglibc has shown that such an approach can work.

The eudev project launches

Posted Dec 18, 2012 19:14 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

There's no difference between a branch that's managed by different people and a fork.

The eudev project launches

Posted Dec 18, 2012 20:09 UTC (Tue) by nix (subscriber, #2304) [Link]

Quite. That is to say, there is no difference *at all* -- the version control system model is identical. The people behind this just think that saying 'eudev' is easier than saying 'the Gentoo udev git repository' all the time.

The eudev project launches

Posted Dec 18, 2012 22:21 UTC (Tue) by HelloWorld (guest, #56129) [Link]

I disagree. PREEMPT-RT is a branch, it's not maintained by Linus, but it's not what I'd call a fork either.

The eudev project launches

Posted Dec 18, 2012 7:02 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

It's OK to fork a project if it's dead or if its maintainers are too slow/abusive/unresponsive. Nobody really argued that forking glibc by Debian was a hostile move because glibc's maintainers were well known for their, shall we say, nice demeanor. However, in this case udev's upstream is responsive and mostly sane. I've been following udev's mailing lists and it appears that they have a normal working relationship with distributions.

Well, udev developers do appear a little bit unstable and it looks like they enjoy conducting cruel medical experiments on unsuspecting users. So maintaining official stable _branches_ of udev with backported fixes and updates would be great idea. Perhaps even a branch with some additional patches for a separate build system, etc.

But that's not what eudev does. Its developers basically took udev, made a few dumb changes (kmod revert), changed license and sticked their names all over the project.