Adrian Vovk

@bragefuglseth@sunny.garden "Enthusiastification"? :p

@zeenix @pid_eins I think there are valid things to criticize Rust for, and std's filesystem APIs is one of those things. Rust also eliminates a massive category of vulnerabilities and significantly improves security posture. Both can be true at once. Pretending that it's not a problem isn't going to help push projects like systemd towards a direction where we start using Rust. In fact, probably the opposite.

@GerryT@mastodon.social @gnome@floss.social It has not been included at all. I was aiming to get it out in GNOME 50 but it wasn't ready so I won't set any expectations. It'll be released when it's ready

@mhoye tmpfiles just needs to be renamed. It hasn't been just for temporary files for a very long time. Yes this is a foot gun /home is not a temporary file. And it has never been seen as one by systemd. In fact, systemd has tools like homed that are designed explicitly to give more control of your home dir to you, the user, with more flexibility over it than with traditional home dirs. I think that's as clear as it gets. So no, systemd is not only for landlords. Quite the opposite.

@FineFindus @thibaultamartin @hbons I suspect there may be some commonalities in the protocols because many headphones actually share their firmware vendor. Interesting somewhat relevant talk: https://youtu.be/TK5Tz4Bt94Y Is the code pushed anywhere to play with?

@dalias @mhoye Nothing happens automatically here... It's a command you have to run. Yeah it was poorly documented that it's essentially a factory reset and that has since been corrected. By your own argument, the presence of rm makes your system exclusive to landlords, whatever that means. Which is silly. tmpfiles is not a conspiracy to secretly run rm -rf /home on your system when you're not looking. It's a tool that creates /home on first boot, told by user to delete everything it created

@LaF0rge The law makes no distinction between employees of banned companies working on their own time versus on company time. That's the legal basis of the move. And frankly, I wouldn't want that distinction. The companies on the list are there for a reason: they're the ones building the tech used to commit the war crimes. The drones and missiles used run Linux. They can, b/c it's FOSS. But allowing the same people who make the weapons killing Ukrainians participate in our communities is on us.

@LaF0rge Companies pay their employees to contribute to FOSS if and only if it benefits the companies in some way. Russian defense contractors don't contribute to Linux out of the goodness of their hearts. Letting them keep contributing means they keep benefiting The people that work for these companies but contribute in their free time don't have my sympathy too. Their day job is still building the tools to kill innocent people, and if all that costs them is their hobby then they got off easy

@LaF0rge The freedom to use for any purpose is not the same as the freedom to participate in development.

@LaF0rge Yeah the announcement could have been handled better

@matt@toot.cafe Case in point: the Orca package In Debian stable they're shipping Orca 48.1. Upstream, the latest release of Orca 48 is 48.7. You can see the change log to read through which bug fixes Debian isn't shipping: https://gitlab.gnome.org/GNOME/orca/-/blob/gnome-48/NEWS Orca is also available in the Backports repo, up to 49.5! However, there's no backport of gnome-shell so we'd still be missing half the solution. If we look at Debian 12 Backports: Orca is 48.1 but gnome-shell is on 43.9. And thus: no working Wayland keybinds

@matt@toot.cafe (and of course, Backports isn't Stable. So by using it you're starting to mix and match new packages with old packages. This is why I say it's a can of worms: it's perfectly possible to run a new Orca on an old GNOME and things like this Wayland accessibility fix will simply not function) Anyway, all this to say that LTS distros are bad in many dimensions, and accessibility is one of them. Especially if there's not a company with compliance requirements standing behind the LTS

@matt@toot.cafe I've asked about this internally, but I think it's quite likely that it has been backported

@matt@toot.cafe Debian is just as susceptible to the usual "LTS shipping ancient software" problem. It just happened to release late enough that it got a new enough GNOME version to include this one change you're focusing on. As far as I understand Debian's policies, if Debian had shipped GNOME 47 they wouldn't backport this accessibility fix to Debian Stable like RH did for RHEL 10. Users would be waiting for Debian 14 and GNOME 51/52, or messing with the Debian Backports repo, which is a can of worms