On 9/12/23 3:47 PM, Eddie Chapman wrote: > Andreas K. Huettel wrote: >> The eudev experiment has failed. >> * It was false labeling from the start.[*] >> * It's barely alive and not keeping up with udev upstream. > > Why does it have to? It is advertised as a fork after all.
It provides libudev.pc; this means that it is either engaged in deceptive and malicious false advertising, or... ... it is intended to provide compatibility with udev. Hint: it is intended to provide compatibility with udev. But, it does so with an OLD version of udev. Other projects throughout the Linux ecosystem may depend on libudev.pc to provide API services; they have the right to use the advertised API of libudev.pc (and depend on a suitable version of it), but eudev cannot fulfill this contract as used by projects which e.g. use the sticky-tags API. Thus, eudev is failing its goal to be a compatible replacement, because it is not keeping up with udev upstream. >> * It's effectively unmaintained in Gentoo. > > That could change. Isn't that why a last rite comes with 30 days notice? Your question is a fallacy. Why are you pretending that the person you are replying to has claimed it isn't going to change? The person you are replying to is describing the current state of affairs that led to the last rite. Who are you arguing against? >> * You don't gain anything from using it instead of udev. >> (Nobody does.) > > Is there only 1 tool for the job? Why do we have both the OpenIPMI and > ipmitool projects, both curl and wget, chrome and firefox. Wouldn't it be > better if we just choose one of each of those pairs and concentrate on it? This isn't a fallacy -- it has progressed onwards and is now a mendacious, twisting attempt at deception. For the benefit of other people reading this discussion -- Firefox and Chrome are vastly different programs, providing vastly different tools, that both share a fairly vague, general domain (open web pages). wget and curl, or openIPMI and ipmitool, are less extreme examples of this general concept: they are different tools taking different approaches to perform a somewhat more specific task, with pros and cons of each approach. eudev does not provide distinct functionality, which leads us on to... >> >> So why should anyone put up the effort to package it? > > Same question for the above choices and plenty of other examples. > > What's wrong with having an alternative purely for competition? > >> [*] Take something out of the systemd tarball, reapply every commit, >> make tiny changes so it looks different, > > That's basically how most forks start isn't it? There are two problems with this statement. The first is that it's wrong, that's not how most forks start. The second is that you used the word "start", without perhaps realizing that starts usually come with an afterwards that is distinguished from the start by not being the start. But let's discuss what it means to fork software. There's a few different reasons why a software project might fork: - the maintainers of the project lost (or never possessed) legal control over the trademark to some corporate interest, and "fork" their own project to a new name due to abuse against users by said corporate interest, in order to reform the community and carry on their operations as normal. Examples: Sun OpenOffice.org -> LibreOffice. In non-software, Freenode becoming Libera.Chat - a project dies because its sole maintainer(s) disappear and cannot be contacted or are unresponsive w.r.t. the project. The community forks, changes its name, and arranges a new development team to "carry on the torch" in memory of the old project. Example: TrueCrypt -> VeraCrypt - a project has some end-user functionality proposed, and rejected. The people who want that feature decide to make their own project, based on the first project but with all their favorite features instead of the first project's favorite features. They take the codebase and start making lots of changes to implement end-user functionality which they enjoy, and and the first project makes lots of changes that *they* enjoy. Rapidly, it becomes increasingly difficult to find changes from one that are relevant to the other. Example: gnome vs. cinnamon desktop - a project changes in ways that some users are unhappy about, and those users create a fork that's exactly the same as the first project, but "with X removed", and which regularly syncs with the first project to retrieve desired features while excluding undesired features. The third case is what most people think of when they talk about forks. eudev is the fourth case, as its stated goal is to be "a fork of systemd", with the motivation of "isolating udev from [...] systemd". eudev lacks mission independence, its driving goal is to accomplish the same aims as systemd-udev except modularizing it well enough that it is neutral regarding the init system you are running as pid1. To this end, it exposes the udev API, udev files, udev soname, udev programs and manpages... eudev is also *failing* to be a good example of the fourth case, because having achieved "with X removed" it went a bit into stasis. There's a few other issues to unpack here, it just doesn't end: On 9/12/23 5:23 PM, Eddie Chapman wrote: > You really are on a slippery slope if you're going to insist that someone > "ought" to use a certain software, that there is no advantage in using an > alternative and therefore you shouldn't. Also, people choose alternatives > for entirely non-technical reasons which are valid. These might be > political, license, or they just like the author or community of one > project better than another. Microsoft Office is probably a better office > suite technically and feature-wise than Libreoffice, yet many people use > Libreoffice instead. That doesn't mean Libreoffice users are "just plain > wrong". Why do we have so many Linux distributions if they all offer > largely the same set of software? Why use Ubuntu over Debian or vice > versa? What's the point of openrc? Which is better GCC or Clang/LLVM? I think it's very easy to throw around terms like "slippery slope" without having any real backing to it. The original objection that "there is no advantage" to an alternative was quite straightforward: the lack of advantage is because they are in fact the same codebase, except eudev is missing some commits. It is not "an alternative to udev", it is "an alternative git repo providing the same old udev". This makes a big, big difference. There's no technical reason to prefer eudev over systemd-utils[udev], they are the same technical codebase. There's no licensing reason, both use the same licensing. There... is a political reason to choose eudev, and that political reason is "the word systemd makes me mad, and I do not want to have a program on my system which has the word systemd in it, please fork the software in order to remove the word systemd so that I can use it". This is definitely a non-technical reason. It is not a *valid* non-technical reason. Comparing this to Microsoft Office vs. LibreOffice is... not an honest attempt to engage in mailing list discussion. Among the many technical reasons to choose between the two, Microsoft Office is not open source and it doesn't run on Linux, so you do not in fact have a choice to use Microsoft Office at all. Similarly, the differences between distros are vast, even the differences between Debian and Ubuntu. If nothing else, they provide different software, in addition to some common software. So are the differences between GCC and clang/LLVM, most pointedly when you consider dialect differences: some programs will only compile with one, some only with the other. Please. Explain to me what functionality only works with eudev. I already know what functionality only works with systemd-utils[udev]. On 9/12/23 6:35 PM, Eddie Chapman wrote: > Ok granted, as of right now eudev has not added any value as it has simply > forked, made some small changes but essentially does the same job. > However, again you're missing the point, there is a very significant > number of users who for subjective/political/whatever non-technical > reasons want eudev instead of udev. These are valid reasons, and before > you try and argue they are not examine your own software choices and ask > yourself if you always choose something entirely on technical merit. Okay, so now we all (hopefully) actually agree that eudev is strictly a subset of systemd-utils[udev] rather than an overlap, but... ... you're still arguing "it doesn't matter"? Why should *anyone* care about "a very significant number" (citation needed) of users that have political reasons? Why are political reasons to want the package atom called "eudev" without the "systemd" word inside, a valid grounds for imposing additional work on volunteers that haven't asked for it? I dispute your claim that "subjective/political/whatever non-technical reasons" are *valid* reasons. I challenge your challenge that I can only argue this after examining my own software choices: I don't choose my software based on whether the word name of a project I politically dislike appears in package atoms, therefore I am consistent and have the moral right to argue against doing so in the specific eudev case. I am not being two-faced and objecting to politically motivated shunning of the systemd-utils[udev] package due to personal biases in favor of systemd while engaging in my own politically motivated shunning. We good? > And, to be honest, eudev does not *have* to do anything different. If it > provides roughly the same functionality as udev (minus new APIs) then it > serves its purpose and is good enough for those users who use it. There > are many examples of alternatives of one software or another that provide > roughly the same functionality and yet we don't discard one of them simply > because it is not adding features that make it subjectively better than > the other one. Considering the large number of bad comparisons going on in this thread, I would like to highlight this "does not have to do anything different" with yet another comparison. I like ebooks and have frequently used the app-text/sigil program. It does build with cmake however. I dislike cmake and don't want it on my system, because something something politics and trying to force Windows workflows on developers. So I would like to fork the software and add an autotools or meson build system for it, and call the new package app-text/esigil. I demand that the Gentoo developers package it, so I can rid my system of the nasty "cmake" word. (If this proposal is successful I can extend it to other packages as well.) Note that esigil provides no functionality that sigil doesn't provide. It is older, because I have to manually cherry-pick commits and disentangle the "cmake" word, and I don't cherry-pick every commit because not all of them are relevant to my use case (there are some components I just dropped). Also sometimes it's hard to backport patches because I have to rework them to still apply, so I don't necessarily bother. However, it's totally valid software, choice is important and alternatives make for a healthy ecosystem, so please keep "esigil" available. There is a very significant number of users using it (sorry, I can't provide citations for this) and anyone who argues against the package is obviously a Microsoft shill because why else would they advocate for a *cmake* project? -- Eli Schwart
