There has been some noise about the state of accessibility in Linux last year. Seems that things are improving and the Devs of major DEs are taking things more seriously. From a more recent blog post on the topic:

Developers Are Rising to the Challenge

Here’s the good news: I’ve talked to developers from GNOME, KDE, and Fedora.

They get it. And they’re taking it seriously.

GNOME’s Wayland session is now stable and usable with Orca. KDE is catching up — and has a legally blind developer leading accessibility improvements. COSMIC is building Wayland from scratch with accessibility and global hotkey support in mind. For once, accessibility isn’t just a postscript. It’s in the room where design happens.

This transition is happening — but we’re not being ignored anymore.

https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-doesnt-love-me-back-post-4-wayland-is-growing-up-and-now-we-dont-have-a-choice/

The other posts in that series gives a good overview of previous things as well. Seems that author has been successful in raising awareness about the subject which hopefully will help improve things.

I don't get it? They seem to be arguing in favor of bootc over systemd because bootc supports both split /usr and /usr merge? But systemd is the same. There is really nothing in systemd that requires it one way or another even in the linked post about systemd it says:

Note that this page discusses a topic that is actually independent of systemd. systemd supports both systems with split and with merged /usr, and the /usr merge also makes sense for systemd-less systems.

I don't really get his points for it either. Basically boils down to they don't like mutable root filesystem becuase the symlinks are so load bearing... but most distros before use merge had writable /bin anyway and nothing is stopping you from mounting the root fs as read-only in a usr merge distro.

And their main argument /opt and similar don't follow /usr merge as well as things like docker. But /opt is just a dumping ground for things that don't fir the file hierarchy and docker containers you can do what you want - like any package really nothing needs to follow the unix filesystem hierarchy. I don't get what any of that has to do with bootc nor /usr merge at all.

The Steamdeck was motivation for the collaboration - since it is based on Arch Linux. But as a desktop client they only support ubuntu officially which makes level 1 tech support easier as supporting every distro can be very complex.

The only time I see a rebase fail is due to a conflict. Which can be aborted with git rebase --abort no need for reflogs unless you really mess things up.

C is easier to get a program to compile. Rust is easier to get a program working correctly.

Almost. But with one key difference. PPAs are precompiled binaries where you cannot inspect the source - you have to trust the maintainer of the PPA. AUR is a repository of source packages which you can download and inspect yourself (or hope others have done this). This makes AUR more community focused than PPAs I feel. AUR is also a central repo managed by people that dont own the vast majority of the packages hosted on it and where packages can be taken down if found malicious. PPAs are lots of separate repositories all managed by different people that generally maintain all the packages for their PPA.

Though in both cases anyone can upload anything to them, so they are not 100% trustworthy. But I do think the way AUR works puts them ahead of PPAs.

Whatever language you chose you might want to also look at the htmx JS library. It lets you write in your html snippets better interactivity without actually needing to write JS. It basically lets you do things like when you click on an element, it can make a request to your server and replace some other element with the contents your server responds with - all with attributes on HTML tags instead of writing JS. This lets you keep all the state on the backend and lets you write more backend logic without only relying on full page refreshes to update small sections of the page.

For a backend language I would use rust as that is what I am most familiar with now and enjoy using the most. Most languages are adequate at serving backend code though so it is hard to go wrong with anything that you enjoy using. Though with rust I tend to find I have fewer issues when I deploy something as appose to other languages which can cause all sorts of runtime errors as they let you ignore the error paths by default.

Unpaid? A lot of kernel devs do get paid, especially the core ones that would be looking after this stuff.

75% – The share of all kernel development that is done by developers who are being paid for their work.

https://www.pingdom.com/blog/linux-kernel-development-numbers/

Flippantly insulating the Linux devs is not the way to improve things. It has evolved and continues to do so. There are far more GUI tools for managing things then there has ever been. The only thing you have mentioned in your post is AMD GPU overclocking - not something I would consider a novice task nor something most people are going to want to do. So the priority to get a GUI to do this is quite low. Hell, it looks like there are no userland tools at all - only raw kernel interfaces. So it is really something we are lacking any tooling at all - let along GUI tools.

Better to advocate for these tools than insult devs for not having yet created them.

If the resulting code looks like copyrighted code, then you’re in trouble. If it doesn’t look like copyrighted code then you’re fine.

^^ Very much this.

Loads of people are treating the process of AI creating works as either violating copyright or not. But that is not how copyright works. It applies to the output of a process not the process itself. If someone ends up writing something that happens to be a copy of something they read before - that is a violation of copy write laws. If someone uses various works and creates something new and unique then that is not a violation. It does not - at this point in time at least - matter if that someone is a real person or an AI.

AI can both violate copy write on one work and not on another. Each case is independent and would need to be legislated differently. But AI can produce so much content so quickly that it creates a real problem for a case by case analysis of copy write infringement. So it is quite likely the laws will need to change to account for this and will likely need to treat AI works differently from human created works. Which is a very hard thing to actually deal with.

Now, one could also argue the model itself is a violation of copyright. But that IMO is a stretch - a model is nothing like the original work and the copyright law also does not cover this case. It would need to be taken to court to really decide on if this is allowed or not.

Personally I don't think the conversation should be on what the laws currently allow - they were not designed for this. But instead what the laws should allow. So we can steer the conversation towards a better future. Lots of artists are expressing their distaste for AI models to be trained on their works - if enough people do this laws can be crafted to backup this view.

POSIX compliance for the most part. Which is meant to give you a consistent API you can write software against that will work on any UNIX system. At least that is the theory behind it. It basically acts as a lowest common denominator for UNIX systems. Want to write a script that will work on all systems - bash or a similar shell will almost certainly be present.

A new system can change this if they wanted to. But then they won't be able to take advantage of all the existing bash scripts out there that everyone is writing. Which adds a lot of friction to adoption.

So in a way we are locked into a bash like shell now. Unless you can get a lot of distros to change this shell it is very hard to change it for a single one. And changing something so fundamental across lots of distros will upset a lot of people that are used to bash.

And shells overall are preferred to general purpose programming languages as their main focus is executing other commands and piping input/output from one to another or to/from files. Something most programming languages make a bit awkward as that is not their focus.

There are a bunch of non-POSIX shells, like fish, nushell, ion etc but these will likely not become the default anytime soon due to the inertia that bash has. But luckjly you can install what ever shell or language you want in addition to bash and switch to that for your interactive shell or even scripting if you want to. They just won't become the defaults for a long time - if ever.

If you enjoy that, then let me introduce you you fzf - a fuzzy finder that has support for replacing ctrl + r in shells with fuzzy matching. Among other uses.

https://github.com/junegunn/fzf#key-bindings-for-command-line