_d7dt

Hi Amjad, thanks for taking the time to respond. Can you please talk to Radon and work with him to remove the offending "unique and invisible" aspects, to make it so he can put his project back up? There must be some way to make it so that these projects can co-exist without causing any trouble, and it can probably done in a way that is much cheaper than bringing a lawsuit.

Overlays and GL/Vulkan extensions aren't strictly necessary, though support ultimately depends on the driver. For example, glamor does the conversion for some formats in a shader: https://gitlab.freedesktop.org/xorg/xserver/-/blob/8274dd664...

I disagree, the shell is in the best situation to do something about it. Or at least it would be, if there was a consistent way for programs to report to the shell how their argument parsing works.

I don't think that is correct, there are plenty of Mastodon instances with a very low number of users (1-5 users).

This is not really a problem for open source games with an active Debian/Fedora maintainer. If there are interested packagers and you give them source code to work with, I've noticed they will be happy to build and test your package and try to keep it updated. The point of using deb/rpm is to integrate with the distro. If you want to go directly to customers and you have no intention of tying your package to the distro release cycle and working with their package maintainers, then yes, it seems it would always be a bad fit.

Something else that doesn't often get brought up here is that kill(2) itself is an unfixable race condition waiting to happen. It's only safe to use that to signal direct child processes. In Linux, programs should be using the newer pidfd_send_signal syscall in almost every case where they would otherwise use kill(2).

Edit: waitpid is also similarly broken and unfixable for a lot of the same reasons as signals, pidfds and waitid(P_PIDFD, ...) should be replacing most uses of that as well.

>the wrong people claimed ownership of the subsystem

That's... not what's happening at all? The issue is there _wasn't_ any of the right people around to claim ownership of the bug. It's not like someone in the know can't just look at the systemd bug tracker, it's all public. Like, I get what your complaint is, but at the end of the day, do you really care who's name is on the commit that fixes the bug? I usually don't, and most maintainers I know probably don't either -- they're usually happy to delegate to someone who's more knowledgeable in the problem area. If you have some other solution you'd like to suggest here then I'd love to hear it, let's move beyond the criticism and start thinking about solutions. And I don't even mean this as a solution in systemd, I mean this as a "helps anything that interacts with hardware and has bugs that could potentially be caused by hardware" solution.

Just to be clear: the alternative there is that nobody looks at the bug at all because nobody but the bug reporter has the hardware. I don't think that's what you want, I assume you would just prefer the bug to be fixed.

I think they are aware of what they signed up for. Linux has continued to grow year after year, the reality for them is that they can afford it.

No, it seems the specific hardware causing the issue was mentioned in the bug report.

That is throwing the baby out with the bathwater though, people who want large scale projects will continue to make projects with large scopes.

From what you were saying earlier, from the perspective of the bug triager, it sounds like there were multiple areas that maybe this could have been fixed in, not necessarily udev. So still that comes back to: the correct people to triage that bug really would have been the distro maintainers, who have total visibility over the whole system and who are better equipped to pinpoint where the bug should be fixed. And then from there they can pass it off to a systemd person or an OEM person, or both, or whatever (Again disclaimer, I don't know anything about this particular SATA hardware or whether this is normal behavior for a host node, this is just my experience from trying to triage this type of bug).

I see people saying this kind of thing often in open source and I think you are missing the point here: who is going to fix this bug? You can say systemd developers shouldn't triage it, and then you're left with nobody to triage the bug at all. So what will you do? The point is, they don't own the hardware, they can't fix the bug. You have to find somebody who actually does own the hardware who knows what is going on, which seems to be exactly what happened. But if you get unlucky and if zero of those people are contributing to udev or any of its forks, then the bug probably won't ever get fixed.

That's what I mean though, all of that seems to be just wild guessing as to what will actually work and sending random emails out to random people who may or may not be able to fix it (Disclaimer: I don't know anything about this specific bug or the specific hardware). Wouldn't someone who actually owns the device and knows who to contact on the kernel side be a better person to lead the effort on that?

I'm just curious, how would you suggest they debug and maintain support for that hardware, without even owning that particular device? It seems like anything they do would just be a wild guess as to whether it actually works or not. In my experience with this specialized datacenter hardware, if people want any of this stuff fixed (in userspace or in the kernel) it usually falls on the hardware vendor to hire some developers to fix it and upstream it, or at the very least donate some hardware to the upstream project so they can test properly.

I don't see why you couldn't do that in systemd (or any other init), it's not hard to make a small unit that simply runs a shell script.

That seems like a strange interpretation. That post says he is owed a debt of gratitude.

Inclusion in wayland-protocols means that it had enough support without opposition. It doesn't mean that all the members are interested in implementing the feature. According to the members list, Weston and Mir are still important enough to have a vote: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/b...

>application have to explicitly ask for compositor to decorate the window.

My reading of the protocol is that even when the application asks for that, the compositor can still reject it, and the application must always provide a fallback to CSD.

What's next, will they prove how easy it is to break into kernel developers' houses and rob them? Or prove how easy it is to physically assault kernel developers by punching them in the face at conferences? Or prove how easy it is to manipulate kernel developers to lose their life savings investing in cryptocurrency? You can count me out of those...

Sarcasm aside, pentesting/redteaming is only ethical if the target consents to it! Please don't try to prove your point the way these researchers have.

>keep all my code

Huh? Grafana isn't your code, it's someone else's code that you'd be using. Unless I misinterpreted, and you are a Grafana contributor. If you are, you could dual license your contributions under AGPL and MIT, if you wanted.