4 ms·
I realize that I don't really have any right to complain about this. I don't contribute to either project, and I think that maintainers should feel free to do w
by ohazi 5y ago
I realize that I don't really have any right to complain about this. I don't contribute to either project, and I think that maintainers should feel free to do whatever they think is best for their projects, including things that help reduce burdensome things that they find annoying.
However, as a heavy user of both projects, I see what those decisions have led to in practice, and have opinions about what this might mean for the community in the medium/long term. The reality on the ground today is that you either run systemd+udev, or you run OpenRC/something else + eudev. And having observed other projects that went down the "we forked, but merge regularly to try and keep the forks in sync" rabbit hole (e.g. ffmpeg and libav), this almost always ends badly.
The goal may be to keep the two separate projects compatible, but inevitably environment differences, bugs, refactors, etc. cause the two projects to diverge. This sucks for everybody, but it sucks a lot more for people using the less popular fork, and this can eventually kill the fork. I worry about eudev long-term.
- zxzax 5y agoSo that really seems to be the core of the problem to me: nobody really wants to seriously maintain udev as an individual project. It's not a fun or glamorous project to work on, it's boring, nobody will notice it unless it breaks, and nobody really seems to care that it depends on libsystemd. For most people this is just an implementation detail. For an embedded distro I can't see why you would use udevd or eudev, you probably want a much simpler device manager without the giant hwdb.
- throw0101a 5y ago> I realize that I don't really have any right to complain about this. I don't contribute to either project This is a strange mindset. Do Star Wars fans not have a right to complain about bad movies just because they weren't part of the cast or crew?