Open-Source DRM Driver Sent Out For The "Good Old" Atari ST/TT/Falcon Systems

[CochainComplex]

God I how I hate all the Microsoft coders infiltering the peaceful Linux userland!

Rust this rust that... click n' playing while whining about good ol' tinkering.

I think you have mistaken Rust with C#.

[Developer12]

Somehow people still don't understand that linux isn't supposed to support niche and decades old hardware in modern releases.

Why the hell not? Who wrote that rule? you?

This hardware isn't just "not popular", it is VANISHED, that is, does not exist, does not function for most people who might find it in old storehouses cause it malfunctioned, cannot find it in stores... Even the guy who wrote the driver, wrote it for an emulator for fsck sake, he didn't have the real thing!

And yet people care enough to write and maintain and use the driver, so the fact that there isn't any hardware doesn't actually matter.

Hell you may have missed the fact that this is already too slow to run on real hardware, and that's just fine. People want to run linux on their emulated atari, so let them. The linux kernel already has plenty of drivrs for QEMU machines that have never existed at all.

There is no reason to inflate upstream kernel with useless code no one needs. No one is going to rush to buy ancient hopefully still functioning hardware on ebay, now that the modern kernel might have driver support. If anyone wants to run it on an emulator, he can just run a modified kernel version on his own, there is no reason to add BLOAT in the kernel in 2023 for ancient 90s hardware.

There is no reason NOT to upstream drivers people are using. People use these drivers, they're willing to maintain them, therefore they belong in the kernel.

It's not bloat, it's software people find useful that no way impacts the performance your generic x86 box. *You* might not personally find it useful, but that doesn't matter.

[zoomblab]

The official kernel should IMO be as lean as possible and then some more. Modules such as this for discontinued / exotic / niche machines can live perfectly fine on their own repositories and their authors can rightfully take on the responsibility of maintaining them.

[coder]

The official kernel should IMO be as lean as possible and then some more.

Modules like this aren't compiled in, by default. So, don't confuse the size of the source tree with the size of the default kernel or the time needed to build it.

Modules such as this for discontinued / exotic / niche machines can live perfectly fine on their own repositories and their authors can rightfully take on the responsibility of maintaining them.

That doesn't work very well, in practice. The main issue is that the kernel lacks a stable driver API. That incentivizes people to upstream hardware support (e.g. Tesla's FSD SoC, support for which will probably never see use by non-Tesla employees).

In many cases, that's a positive and has helped make Linux the de facto operating system by avoiding the need for users to hunt down and coax a bunch of proprietary drivers to install and work properly. The downside is that the kernel gets support for all sorts of oddball and proprietary hardware upstreamed, as well.

If the kernel adopted a "public interest" policy, for upstreamed drivers and features, then it would hurt commercial users as well as hobbyists. Many in each camp are big supporters of the project, meaning a change in the policy could be self-defeating. AFAIK, the current policy works well enough. As long as someone is willing to maintain it, it can stay in-tree.

[ayumu]

Oh, I also do that and it is currently the only modern OS to run on an Alpha 21264 (I got a ton of these nostalgia machines ... HP-PA 8900, POWER4+, fucking Itanium, though Amiga is most fun). NetBSD is odd, getting a properly working desktop is - uhm - also no fun, and if you end up using ports on your m68k machine, it is going to die the heat death. Actually NetBSD supports the CS Mk3/PPC (I have both) SCSI and the Fast-ATA controllers, but it is also horribly slow. I mean, comparing these several MiB big kernels to a max 24KiB Exec kernel just shows why. Hmm, Exec on AOS 3.1 is smaller, isn't it? 17-18KiB?

I'm actually a bit surprised noone questioned my post ... I mean, kernel 5.19 two years ago? My last attempt was about 2 months ago. I may give it a try again, this time Amiga, Alpha and Yocto.

If you try netbsd HEAD, it has 256 color AGA Xorg.