Ephera

Yeah, have not heard about any of these problems before this post…

Back in 2010, the OpenOffice devs had to abandon that name for trademark reasons¹, so they renamed to LibreOffice and continued developing under that name.

OpenOffice theoretically also still exists, but it’s hardly getting updates. Unless you specifically like software from 2010 (including some security vulnerabilities, I believe), you want to use LibreOffice.

¹) The OpenOffice trademark was owned by Sun Microsystems, which got bought by Oracle. Oracle has a very bad reputation, so the devs did not care to wait around for Oracle to fuck everything up.

What country is it from?

Ah, I thought you mixed them up, because they both look Windows-y in their default configuration. 🙃

Mint doesn’t use KDE out of the box. They have an own DE called Cinnamon.

The crush probably had some incriminating evidence they needed to be disposed of for sure.

By “unit”, you probably mean a SystemD unit, right?

Hmm, interesting, thanks!

Yeah, I get called a tankie on the regular now, just because my user account is on .ml and I still don’t actually know what it’s supposed to mean. Apparently, I’m supposed to have political opinions on topics that I’m significantly more ignorant on than the people who call me that.

Yeah, but anyone willing to implement shaders for Luanti can just contribute it to the game itself. Then you wouldn’t need to do anything to get the support.

The Rust compiler is more sophisticated than most compilers, so it can be slower at the same kind of tasks. But it also just does a different task here.

One of the tradeoffs in Rust’s design is that libraries get compiled specifically for a concrete application. So, whereas in most programming languages, you just download pre-compiled libraries, in Rust, you actually download their source code and compile all of it on your machine.

This isn’t relevant, if you get a pre-built binary. And it’s not particularly relevant during development either, because you get incremental compilation. But yeah, if someone wants to compile a Rust codebase from scratch, then they have to sit through a long build.

Yeah, the good tooling also means it isn’t even terribly difficult for the dev to provide builds, but it isn’t quite as automated as publishing to crates.io, so many don’t bother with automating or manually uploading…

Originally, they were made from the marshmallow plant, by the way: https://en.wikipedia.org/wiki/Marshmallow#History

But yeah, the modern-day formula is quite different and rather highly processed…

2. ß isnt used when you have a pair of s letters next to each other. Its most commonly used if you have long vowels beforehand. See “Trasse” vs “Straße”.

Perhaps worth adding that we had a spelling reform in 1996, which kind of put this rule in place.
If you learned German before then or had a teacher who learned it before then, it’s possible that you got taught it the old way…

Usually, the desktop environment devs come together and standardize on something. But yeah, someone has to drive that effort. Open-source isn’t really something you plan, you just need someone to push for it.

Since no one mentioned it yet, this is the classic card game “Klondike”.

KPatience is a program that implements multiple such card games…

Hmm, good question. I know of one such implementation, which is Delta RPM, which works the way I described it.
But I’m not sure, if they just designed it to fit into the current architecture, where all their mirrors and such were set up to deal with package files.

I could imagine that doing it rsync-style would be really terrible for server load, since you can’t really cache things at that point…

Had to search for a bit, too, but finally found the relevant keyword: Delta RPMs
(Which also explains why it’s a Red Hat / SUSE thing. 😅)

Here’s a decent article, which links to some more in-depth explanations: https://www.certdepot.net/rhel7-get-started-delta-rpms/

This doesn’t work too well for rolling releases, because users will quickly get several version jumps behind.

For example, let’s say libbanana is currently at version 1.2.1, but then releases 1.2.2, which you ship as a distro right away, but then a few days later, they’ve already released 1.2.3, which you ship, too.
Now Agnes comes home at the weekend and runs package updates on her system, which is still on libbanana v1.2.1. At that point, she would need the diffs 1.2.1→1.2.2 and then 1.2.2→1.2.3 separately, which may have overlaps in which files changed.

In principle, you could additionally provide the diff 1.2.1→1.2.3, but if Greg updates only every other weekend, and libbanana celebrates the 1.3.0 release by then, then you will also need the diffs 1.2.1→1.3.0, 1.2.2→1.3.0 and 1.2.3→1.3.0. So, this strategy quickly explodes with the number of different diffs you might need.

At that point, just not bothering with diffs and making users always download the new package version in full is generally preferred.

openSUSE Leap does have differential package updates. Pretty sure, I once saw it on one of the Red-Hat-likes, too.

But yeah, it makes most sense on slow-moving, versioned releases with corporate backing.