Notices by Neal Gompa (ニール・ゴンパ) :fedora: (conan_kudo@fosstodon.org), page 4

An awesome hot 🔥 take at @fosdem: @fedora is great for small scale server deployments!

I am now convinced that many Linux kernel developers cannot handle Rust. Dealing with this one thing by a kernel developer using C and Rust has made me cry for the fate of the universe...

Forked crates, patched crates, forced online builds, ignores build flags, and more. This is absolutely horrible and it's so dangerous with code like this. Even quite complex Rust stuff from other places has better hygiene than this. 😭

@hp @marcan If Godot runs on Fedora Asahi Remix (I believe @akien packages it for Fedora and it builds for AArch64 there, so it should be available to Asahi users), then there's nothing special to do.

Most AArch64 applications don't need to worry about the 4K/16K kernel memory management page size difference.

@elly @marcan No mandate = no fucks given = no implementation

@10leej @BrodieOnLinux @probono Right, I'm aware of the philosophy that wlroots (and xdg-desktop-portal-wlr) holds, and it is unlikely that x-d-p-wlr will gain complete portal services coverage because of it.

@probono @BrodieOnLinux The thing is, I don't see it being a bad thing that it's a complete departure. That would imply I thought X11 is good. We all know it's not good.

But replacing 40+ years of baggage is hard, and as @thisweekinkde put it: "shell-shocked X developers" went completely in the opposite direction of X11. It's taken 15 years, but we're finally here in terms of parity in capabilities and desktop environment support.

But it's still different, and that's okay.

@lkundrak @kernellogger `Co-authored-by:` is a great tag for situations like this. I don't see it super-often in the kernel though.

@jamesh @mcepl @blandford Sure. But it was nipped in the bud, and they've grown to embrace open source in a way that few corporate-driven open source products do.

Meanwhile, GTK has always been under the LGPL, but the community around that has been... contentious, to put it mildly.

There are plenty of examples on the internet, even in the GNOME GitLab of this.

Open Source alone does not protect you from toxic people. Caring about the community and stakeholders does.

@jamesh @mcepl @blandford Qt is far less susceptible to this because they have the ultimate poison pill underpinning the project: forced relicensing to a permissive license (BSD-2-Clause, IIRC).

GTK has no such poison pill forcing them to serve the larger community. It shows.

@jamesh @mcepl @blandford You don't need to be under a company to through "enshittification". The number of external stakeholders that increasingly have problems with GTK and have been pivoting away from it has demonstrated that there are problems with GTK today too.

The real issue is that when a group of people get comfortable with their dominance, they stop caring about their stakeholders. Even in tiny ponds like Linux desktop GUI toolkits.

Well, life happened and now I'm currently independent.

So, that opens up a new opportunity! If you've benefited from my work in the Linux and open source world (especially in @fedora, @centos, and @opensuse), now is your opportunity to help supercharge my efforts by sponsoring me via GitHub Sponsors! 💖

https://github.com/sponsors/Conan-Kudo

@chamomile In my experience the primary reasons often boil down to two cases:

1. The only environment they're familiar with is Debian, and *whoo boy* standard Debian packaging is an *adventure*.

2. The knowledge of the tooling and documentation just simply isn't there.

I should note that Arch users tend to actually write PKGBUILDs for their stuff, and ever since the introduction of COPR by @mirek ten years ago, arbitrary packaging of things as RPMs has been on the rise.

@krh @gfxstrand It's easy enough to see Rust is actively hostile to external build systems, though. It's really difficult to use Rust in a non-Cargo context and they don't have nice things to say when you ask for help trying to do it.

That being said, I was soured on Meson for different reasons (mostly the unstable behavior/API from version to version) and generally prefer to use CMake.

@gregkh @tylersaunders Yeah, you're right. And yes, I sadly *do* know about the SoC monopoly issue that is the underlying cause of all this. In theory, there are lots of ARM vendors. In practice, there's just one that everyone buys from.

@tylersaunders @gregkh It's only insane because Android doesn't enforce an upstream-first policy for drivers as part of Android certification.

Regular Linux distributions are able to support a wide range of devices and form factors because it's all part of the upstream kernel, which drastically simplifies things. Android doesn't have that yet.

Maybe someday, who knows...

@fuzzychef Maybe it should just get renamed to `Boost-1.0` in SPDX. The Apache and Python licenses had similar treatment...

(Renaming identifiers sucks, especially for SPDX. But if the confusion keeps happening...)

@mairin I'd like to see more about the intersection of design philosophies, HCI, and open source software.

Today is a day of vegging out. Movies at my local cinema with food and drinks! 🍕🥛🎬🎥

@nirik > We found the typo that was preventing chromium from using all cpus when building on aarch64. Builds now take 3.5 hours again instead of like ~45hours

Thank God! I was dreading having to do a rebuild of Chromium due to ffmpeg updates... I'm glad this is fixed!

@cameronbosch @fedora @AsahiLinux The primary flagship variant is the @kde one. 😉