Re: [gentoo-dev] last rites: sys-fs/eudev

["Eddie Chapman" <eddie@ehuk.net>]

Eli Schwartz wrote:
> 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

Dear Eli,

Putting completely aside for a moment the issues being debated in this
thread, I first need to address the tone of your response as a whole,
which is shocking to me.

These are some parts of your response I strongly take issue with:

"This isn't a fallacy -- it has progressed onwards and is now a
mendacious, twisting attempt at deception."

"it just doesn't end"

"I think it's very easy to throw around terms like "slippery slope"
without having any real backing to it."

"Comparing this to Microsoft Office vs. LibreOffice is... not an honest
attempt to engage in mailing list discussion."

I would like to politely ask you to stop using this type of language,
which is completely unacceptable, if you address me again. These are all
examples of ridiculing other people's arguments, and of statements which
are insulting, and in my view are all unacceptable in public debate. I
have deliberately avoided those things in my responses which have all
remained courteous to everyone I have addressed. You should be ashamed of
letting yourself stoop so low!

It's a pity as I would have loved to actually engage in a good discussion
with you on the points you've made about the issues in this thread, all of
which you've argued very well and intelligently, some of which I agree
with, but most I disagree strongly with. I would have gladly responded to
all of your points, but when you started being insulting I lost all
respect for you so I won't. However, I'd be happy to engage with you again
if you were to apologise, privately off-list if you prefer, for being so
discourteous and assured me you are going to be polite in your responses
going forwards. If you are not prepared to do that, no problem, you are
perfectly entitled to  post whatever you like in whatever way you see fit
but I don't consider it a serious attempt to debate and won't engage in it
further.