Not if you want to make sure it compiles and works on Windows (which you don't have) or macOS (which you don't have and can't emulate). That's something github gives for free, and for me, it's the only reason to stay on github for small/tiny free software projects (at least as a secondary host).

My mind immediately went to this classic xkcd: https://xkcd.com/303/

For that, you'd want the list of requirements and hardware documentation to be written in a precise, formal language. That's no different than writing them in a programming language (though a declarative one, instead of the more common imperative ones).

I've in the past (way before LLMs existed) thought about automatically generating device drivers from hardware documentation. But besides the need for very precise documentation, hardware never works exactly as documented; a human-written device driver can avoid problematic areas (perhaps even by accident), while a computer-written device driver would end up exploiting every corner case of the documentation.

Then you'll have the same problem everyone who forks a piece of software ends up having, sooner or later: as the original evolves, keeping your fork up to date with the upstream changes becomes harder and harder. The bigger and more invasive the changes are, the harder synchronizing with newer releases become.

Playing devil's advocate: back when you still could use Java in the browser, you could use Javascript to script your Java applets.

Is "vibe-coded software" really going to be the "Open Source software of tomorrow"? The opinion stated in the blog post announcing this change is the opposite:

"We believe that LLMs endanger the free/libre software ecosystem as a whole." and this is expanded in more detail later in that blog post (starting at the "Collaboration at danger" section).

This reeks of the same FOMO strategy seen often in cryptocurrency projects (which, unsurprisingly, have also been banned from Codeberg at the same time): stating that their way is going to be the future, and that those who don't follow it will be left behind ("have fun staying poor").

Isn't this the plot of Endgame: Singularity? (https://packages.debian.org/bookworm/singularity)

Even beyond security issues: each update is a new opportunity for breakage, not only from bugs in the third-party package, but also from unexpected dependencies on the third-party package's behavior.

Playing devil's advocate: one reason I'm good at typing on computers is that I learned on typewriters, which need much more force for each key press, especially the little fingers. Someone who learned on computer keyboards won't have trained the muscles on their fingers as much, and will have a hard time pressing the outer keys strongly enough (and if you press the keys too lightly, the mechanism won't hit the ink ribbon with enough force to transfer the ink to the paper).

And that's when it's a legitimate Realtek chip. Many years ago, I bought a 100M Realtek Ethernet card, expecting it to work out of the box on Linux; but it was actually a counterfeit, using a Silan chip instead of a Realtek chip, and the out-of-tree Linux driver (for Linux 2.4) that came with it on the CD was actually a driver for the Silan chip with the numbers filed off. I ended up writing and submitting a Linux 2.6 driver for it, just to make people stop blaming the Realtek driver for not working with the unrelated Silan chip.

The threat model secure boot was actually designed to protect against is not someone else booting a different OS in your hardware; the real threat model it protects against is malware loading before the OS can start the antivirus. With UEFI, malware could in theory run even when you boot from your OS install media, making it much harder to detect and remove. That's the reason installing your own secure boot key requires a one-time confirmation through a physical input device (which malware can't fake).

Unfortunately, protecting against that threat model (persistent malware loading before the OS) created another threat model, which IMO is a bigger worry: that you could one day be forbidden from running your own OS in your own devices. AFAIK, there have already been a few devices where secure boot cannot be disabled, your own secure boot keys cannot be enrolled, and the "third party" (aka "non-Microsoft") key is not available.

Nice, I didn't know that was possible; I expected it to be unchangeable, since I heard that the whole taskbar is no longer customizable in newer Windows releases.

Except that... it's no longer in the bottom left corner! Recently, I had to help a relative with a Windows system, and what passes for the "Start" button has now moved to somewhere more in the center (and, of course, this completely confused my relative, who was used to the old place). I also had to rant about Fitt's law (without mentioning its name) and how things were better the way they were before. And I also had to find out and show them where the shutdown button ended up this time, so they could power off the computer normally (as they were used to) instead of having to use the power strip switch.

And the issue I had to help with? Windows was too slow (to the point of nearly unusable). They don't use the computer often (and obviously always power it down after each use), so it's always running some heavy background update (on a mechanical hard drive) whenever it boots up. My advice was to power it up and let it sit for about an hour before using, then it would be back to normal speed.

That has already been done in the past. Quoting the FAQ:

"[...] the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that."

IIRC, Debian has a command called "make-kpkg" which does nearly all the work for you, ending up with a installable package which works identically to the standard Debian kernel packages.