F-Droid blog post on the topic: https://f-droid.org/en/2025/09/29/google-developer-registration-decree.html

It was posted before Google backpedalled somewhat, if I remember correctly.

100
⤷

Yeah, it’s especially funny to me, because the word “AI” has been used in gaming to describe the behavior code for NPCs since forever. And in this case, they actually even happen to refer the same thing in the end. At best, it’s a different strategy for getting to that same end result.

I’m guessing, those people are worried that it will be removed. It’s already somewhat on the line since Wayland started replacing X11, because individual desktop environments can now decide to implement it or not.

Yeah, it feels like those consoles would be more expensive, for hardware that’s not going to be terribly stronger, to play games which don’t need the visual upgrade, and all of that wants to be paid by players with less money to spend.

Yeah, Rust is a lot better in those regards. You are still in more direct control of memory, but if you fuck up, that’s a compiler error, not a runtime error, and the compiler error messages even give you pretty helpful suggestions for making it work.

Unfortunately pretty common for game development…

Fuck Microsoft

I always just do ss -ltnp | grep <port-number>, which filters well enough for my purposes and is a bit easier to remember…

I’m on NixOS for my personal laptop, too. I just tried it and well, #!/bin/bash apparently does not work, but #!/bin/sh does.

The file /bin/sh does also exist as a symlink for me:

> ls -l /bin/sh
lrwxrwxrwx 1 root root 73 14. Dez 19:50 /bin/sh -> /nix/store/35yc81pz0q5yba14lxhn5r3jx5yg6c3l-bash-interactive-5.3p3/bin/sh*

Does that point into the bash package for you, too?

Edit: And for #!/bin/bash, the output was:

> ./test
exec: Failed to execute process './test': The file specified the interpreter '/bin/bash', which is not an executable command.

That is definitely not right. That sounds like you don’t have a shebang or it isn’t defined correctly. The shebang has to be the very first thing in the script, with no whitespace before it. It gets read out by the kernel, which very dumbly checks the first few bytes.

And well, such a shebang should also work for Python or the like. If you copy the first script in this link into a file script.py, then run chmod +x script.py and finally run ./script.py, does that print Hello, World! ?

I have fish set as the default command to run when my terminal emulator starts, but my system-wide default shell is bash and I always throw a #!/bin/sh or #!/bin/bash shebang at the top of my scripts either way.

With that setup, I hardly notice fish’s syntax differences. Are you using it like that, too?

I guess, those don’t work for hidden/minimized windows.

Perhaps worth considering a bspwm-like workflow. Rather than minimizing windows, you put them onto another workspace. Just absolves you from dealing with the whole concept of minimized windows…

Lots of “modern” languages don’t interop terribly well with other languages, because they need a runtime environment to be executed.
So, if you want to call a Python function from Java, you need to start a Python runtime and somehow pass the arguments and the result back and forth (e.g. via CLI or network communication).

C, C++, Rust and a few other languages don’t need a runtime environment, because they get compiled down to machine code directly.
As such, you can call functions written in them directly, from virtually any programming language. You just need to agree how the data is laid out in memory. Well, and the general agreement for that memory layout is the C ABI. Basically, C has stayed the same for long enough that everyone just uses its native memory layout for interoperability.

And yeah, the Rust designers weren’t dumb, so they made sure that Rust can also use this C ABI pretty seamlessly. As such, you can call Rust-functions from C and C-functions from Rust, with just a bit of boilerplate in between.
This has also been battle-tested quite well already, as Mozilla used this to rewrite larger chunks of Firefox, where you have C++ using its C capabilities to talk to Rust and vice versa.

Yeah, the headline makes it sound like he’s insulting AI, but he’s just illustrating a fairly basic fact…

If you enjoy pinball, this one is decent: https://f-droid.org/packages/com.dozingcatsoftware.bouncy

Ah yeah, it does auto-save regularly, too. But I don’t think, I’ve ever seen it crash without me doing some out-of-game fuckery. 🙃

Well, and of course, losing progress is baked into the gameplay of a roguelike, so whether your savegame corrupts or you die yet another stupid death, you just start another run and you’re right back into the action.

I also think ANY game should have a “full potato” mode capable of running in older computers with NONE of the fancy graphics stuff that we have access to today, despite having a decent computer now.

Problem is that the fancy graphics stuff isn’t just additive.
For example, raytracing is actually relatively simple to implement, since you just make light behave like it does in real-world physics, according to a couple relatively straightforward rules and material properties.
Lighting without raytracing involves tons of smokes and mirrors hacks and workarounds. For example, mirrors were often faked by building the same room behind the wall, with everything inverted, including the player character’s animations.
So, making a game with potato graphics typically requires building a second version of the game.

Of course, there can be a mode that does just turn off the additive stuff, so only that which does not require changing the game implementation. But that can just be one of the graphics presets…

There’s a roguelike I play, which combats save-scumming by only giving one save slot per character. And so the only reason to save the game, is when you’re done playing. So, you hit Ctrl+S to save, and it instantly quits as well. 🙃

The description in the ticket isn’t too bad:

allows users to make a window disappear and keep only its title bar visible.

It really just hides the window contents. In effect, it is similar to minimizing a window, except that it doesn’t spring into your panel and rather stays in place as just the window title bar without the contents.

It is a niche feature, if you couldn’t tell. But it isn’t some KDE specialty feature; various other desktops and window managers also support it. I think, it was more popular in the early days of graphical user interfaces, when we were still working out, how we want to do panels and such.

And conversely, I do think it makes more sense as a feature on big screens like you can have today, where your panel might be quite a bit away.
Don’t think, window shading will make a big comeback just yet, but yeah, probably enough existing users that use it, so that it would be cool to support that workflow.