Yep. One reason why those situations become less frequent over time is that one learns to avoid such designs. Thought process: “Sharing data across threads is annoying. So I’d rather avoid it. Maybe message passing can solve the same problem as well?”

I now have run into the issue that I myself cannot play Minecraft on my Linux laptop, which is an ARM machine and the ARM Mali GPU does not support the OpenGL version that Minecraft requires. (It also needs some hackery, as the Java-written Minecraft uses some native code libraries.)

I’m now playing VoxeLibre instead, which runs mostly fine on my laptop.

What is stopping you from playing Minecraft itself on Linux?

I haven’t played it in a while, but it did work perfectly fine last time I tried it. It is written in Java, after all.

This is so fucking stupid, I can’t even.

For your mental health, have some reasonable arguments about Rust: https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html

Since it’s in German, here are the key points of the article (written from memory - the article is quite old, so I might misremember - best read the article yourself):

• Software development is stuck in a vicious cycle regarding project budgets.
  • Some competitors don’t know better and just budget the “happy path”, that assumes that everything during development goes right.
    • The author uses a term for this which I like a lot: “Hybris of the programmer”
  • Other competitors know better, but still have to lie in order to remain competitive when it comes to prices
  • Therefore almost all software projects end up with a way too low budget
    • So we get buggy software
• Rust might be a way out of this misery, because
  • it is understood that it takes longer to develop something with Rust
  • but on the flip-side the safety-guarantees rule out a lot of bugs
  • so customers who choose to have their project implemented using Rust are fully aware of the higher costs, but also the higher quality
  • and developers have a well known argument for the higher costs, and also have data that shows how this higher investment will yield a better quality product.

I fully second the sentiment that there is no good reason to switch distribution once you have found one that you like.

However, if your goal is to learn something new, and you don’t care about having to nuke the install and start over, then you could go the crazy route and install Linux From Scratch. It is unlikely to yield a maintainable result at first try, but if learning is your goal, this is your best shot at it.

Or you could go the not-that-crazy route and use Gentoo, which is basically Linux From Scratch, but automated. Setting it up is way quicker (couple of hours - except if you configure the kernel by hand), and you will with near certainty get a maintainable system on first try, but it is also far less educational, given that the automation does most of the work for you. (I have switched from Debian to Gentoo 10 years ago, after trying it on my netbook for some time, and I could not be happier. It only does what it should, is rolling release, and only very rarely has issues.)

I would only recommend those two approaches on a second PC though, without immediately switching the main PC over. Linux From Scratch is, as said, unlikely to yield a maintainable installation on first try, so you will likely nuke the install again. Gentoo, while perfectly usable as a daily driver, is certainly not everyone’s beer, and you might simply want to switch away again because you don’t like it.

I guess this was being sarcastic, but just in case it wasn’t:

If you launch the game through Steam that probably won’t matter, because Steam brings along its own libraries for games to use. That collection of libraries is called “Steam Runtime”, and if the game only uses libraries from the Steam Runtime, it will run on any distribution that the Steam Runtime is compatible with (what afaik means basically all distributions).

There are some exceptions though. Graphics drivers for instance are not bundled in the Steam Runtime.

And last, but not least: Even if you don’t run the game through Steam, it’s probably just a bunch of libraries that need to be installed. They only need to be the same or a newer version than those used on the developers’ build server.

I am now at the point where I think there are two things happening.

• Actual technological progress.
• Marketing bullshit pushed by dazzlers.

Examples for the first one would be new battery tech for electric vehicles, new ways to harvest renewable energy, new tools that allow to make software more stable,… Examples for the second would be NTFs, Crypto-Currencies, “AI”, e-Fuels,…

No solution, but I have a similar issue with the higher crate.

There the /prelude/src/lib.rs file lets rust-analyzer lose its mind and allocate gigabytes upon gigabytes of memory, even though the file compiles just fine and nearly instantaneous…

I think this has something to do with recursive macros. Doesn’t iced also have such? I have faint memories of a column! macro?

• cargo install is for installing rust programs for your user, not for adding dependencies to your Rust project. Many cargo subcommands can be installed this way, for instance cargo bloat.
• The file you are talking about is called Cargo.toml, because it is the file you need to write in order to configure cargo for your Rust project. TOML is the name of the file format. For details, please see the introductory chapter to Cargo in the Rust book.
• Cargo recently got a new subcommand called cargo add, which allows to add dependencies directly on the command line. However, all it does is to add/edit/remove the respective lines in Cargo.toml. (Personal opinion: I have found it way easier to just edit the file directly than to learn yet another command…)

That said: You still need to edit the Cargo.toml file, even if you solely use cargo add to manage your dependencies. That’s because that file contains a lot more information about your project than just the dependencies. For instance the current version, the feature-flags, your name, a link to the public repo,…

You have Debian experience? Then stick to it. It may be boring, but boring is good. That means it doesn’t need much maintenance, and that it just works.

They have done that already. It’s called Kylin.

I haven’t done much Rust coding this year yet, mainly because I am trying to learn Lean4 and spent the last couple of months writing a (partially) formally validated (but not very fast) Binary Heap in Lean4.

However, a few days ago I had an inspiration at night, that brought me back to my Rust spare time project: The visual novel engine I had started last year.

For now I only did a relatively small change, but it’s one that will save me a lot of time (and nerves) later on. I am using a Free Monad based embedded Domain Specific Language for writing the game logic. The change now was to wrap that Free Monad in a State Monad Transformer, which I use to store the game state in.

This idea seems to be working surprisingly well, and that has given me enough motivation to return to this project and to keep developing it further for now.

Long and boring explanation with way too much detail:

Sorry for going on a tangent, but there is a Rust-specific detail that makes this cool beyond the usual advantages of using a State Monad Transformer, and I cannot stop myself from sharing.

For composing a large Free Monad, do-notation is more or less a must-have. However, do-notation in Rust only works well with types that implement Copy. If you want to use any other type in do-notation, you can only access variables of it in the following two lines. An attempt to access the data later will lead to an ownership problem (explained here). I have tried to overcome this by adding additional syntax to do-notation, but that is a crutch at best.

So, this is where the State Monad Transformer comes in. It side-steps this problem by moving the state out of the do-notation block into the Free Monad’s Pure-nodes. That way it is readily available via the State Monad Transformer’s get()/put() functions, and the “use within two lines” limitation is not a big issue any more, as one can always get the value on one line, do something with it in the next line, and write the result back on the second line.

Need to enshittify it enough to make the AI features feel like an improvement.

I would be very surprised if they wouldn’t fix all 50 filesystems.

In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don’t compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.

That’s a very good point. I hadn’t considered potential lack of domain knowledge at all. In that case Rust might even help, because it’s easier to write interfaces that can’t be used wrong - so that even someone without the needed domain knowledge might be able to fix compile issues without breakage.

Behind all the negative tone there is a valid concern though.

If you don’t know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.

This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?

I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.

I don’t know if this applies to CLAW, but many games back then had their audio stored as CD Audio Tracks. If that is the case, you might want to actually emulate a CDROM drive instead of just extracting the files. There is a CDROM emulator for Linux, called CDEmu, which can read CUE/BIN CD Images.

Oh, and that game seems to have an ancient 16-bit installer, which might not work on modern systems. However, according to WineHQ Appdb one can just copy the files from the CD and it works.

In addition to LibreOffice I often use standalone tools.

If I want a high quality document, I use LaTeX. Same for presentation slides. However, writing stuff in LaTeX is only worth the effort if the quality is needed. For non-important stuff I just use LibreOffice.

For calculations it depends on what I want to have in the end. If I just want to play with the data a bit, then LibreOffice Calc it is. However, if it is for something serious, I tend to write script files, or even full programs, that do the processing. That way computation and data is in separate files, and the used formulas are clearly visible and easy to debug.

I have been a user since the 90s. Back then it was still called StarOffice.

Its feature set differs from that of MS Office, and its performance could be (a lot!) better, but I strongly prefer the LibreOffice user interface, and the features that matter to me (like CSV import) are way better in LibreOffice. However, LibreOffice does not have all the features of MS Office, and some are notably worse (for instance auto-fill in spreadsheets, where Excel is way better at guessing the next value).

Sadly it’s not only a matter of preference, because file exchange between different office suites is not flawless. MS Office and LibreOffice don’t agree 100% on how to load each other’s files…

Points that I would gladly agree upon - but it seems the Wikipedia authors don’t.

I am not knowledgeable enough to draw a definite line what counts as functional and what doesn’t - so I chose to go with whatever Wikipedia says… Even though I dislike it.