

I guess rsync can be told to remove removed files on the destination, too?
Yes. The --delete
family of options are relevant here.
I guess rsync can be told to remove removed files on the destination, too?
Yes. The --delete
family of options are relevant here.
This is a huge win for the open source community!!
The headline alone? No, I don’t think so, because AMD’s driver had a reputation for working in some situations (mostly non-gaming IIRC) where Mesa didn’t.
However, this bit quoted from the release notes might make up for it:
“The Mesa Vulkan driver will be officially supported, along with Mesa OpenGL and Multimedia support.”
Assuming they mean that AMD will work with Mesa to get the remaining edge cases fixed, so that the proprietary driver is no longer needed at all, this does seem like good news.
Git is for text files and retaining a history of every change and every state that has ever existed. It is the wrong tool for what you want, because it would be wasteful of resources.
I suggest automating lossy encodings locally (there are quite a few approaches you could use here, such as a cron job with the encoder of your choice), and automating an rsync job to keep your server updated.
It would be interesting to see the annual global power consumption from design choices like this.
You’re not asking too much. In a text forum like this one, at least a brief summary or minimal discussion really ought to accompany any video-only post that lacks obvious importance to most readers.
If I wanted to do this, I think I would start by getting to know the IT staff. This would:
I suggest taking your time, and saving Linux for later so that it doesn’t create more friction against moving to LibreOffice.
Looks like a promising effort. I just wish their notion of “first-class Qt support” included Qt Widgets.
Or, if they’re unwilling to do that, exposing in Qt Quick the missing functionality that has been available in Qt Widgets for ages.
Current web browser engines generally support JavaScript and WebAssembly, and no others (unless via a plugin, as with Java).
So, if I understand you correctly, your options are to find a language that transpiles down to one of those two (several such languages exist), or find an engine that isn’t precisely a web engine but supports some alternative language(s). I don’t know any useful examples of the latter, but perhaps someone else will chime in with something like that.
This is outstanding work. Putting one together looks far from trivial, though. I wonder if the creator will make pre-built boards available for sale.
I’ve seen fewer failures in their stand-alone laser printers than their all-in-one printer/scanners, but yeah, I second Brother.
Sure, but most YouTube streams aren’t delivered as a single webm or mp4 file, and the language & subtitle selection you’re referring to aren’t implemented by the browser (but instead by a JavaScript application downloaded from Google). So it’s not what OP asked about.
I’m not suggesting that it’s outrageous. Merely that it’s probably not a high priority.
Maybe webm and mp4 files with multiple language tracks are usually played with a media player, not a web browser?
Let’s not make things complicated when they don’t have to be.
All the more reason to call attention to an easily overlooked alternative, especially if it’s able to serve a blind person’s needs better.
Running ALSA as root had one huge benefit
Huh? ALSA is not a sound server, but a collection of kernel components and libraries. You don’t run it.
With PipeWire or PulseAudio, audio is bound to a user session.
PipeWire has a system-wide mode of operation. It wasn’t well-tested when I last asked about it, but it might be worth a try.
GTK3 broke accessibility for years.
GTK4 released with no accessibility support at all.
This whole article is focused on GNOME and other GTK-based desktops. The only mention of KDE Plasma at all is to say that a certain GNOME fork (MATE) isn’t like it. This seems like a rather large oversight given that Qt, upon which Plasma is built, has accessibility features built in.
So, nearly every criticism here is not about Linux after all, but about a specific desktop family. I hope the author eventually notices that others exist, tries them, and discovers things that work better in them. (And it would be nice if they were to post a more comprehensive follow-up article, or at least rephrase this one so that it doesn’t mislead people into thinking it represents the Linux desktop ecosystem as a whole.)
Is Incus the community-maintained fork of LXD, post-takeover by Canonical?