Naja es gibt ja schon einen Unterschied zwischen der Verschlüsselung und der Authentifizierung bei TLS.

Die Zertifikate sind für die Prüfung der Authentizität notwendig (also dass der Server tatsächlich der ist, der er behauptet zu sein) und da kann man durchaus berechtigt diskutieren, dass nicht alle Organisationen, die solche Zertifikate ausstellen, auch vertrauenswürdig sind.

Die Verschlüsselung, um die es hier geht, ist aber trotzdem eine gute Sache und hat nichts mit Sicherheitstheater zu tun. Die sorgt nämlich dafür, dass niemand mitlesen kann, was zwischen dir und dem Server am anderen Ende hin und her geschickt wird. Ist zwar nur begrenzt sinnvoll, wenn man besagtem Server ohne o.g. Authentifizierung nicht immer trauen kann, aber das tut der Nützlichkeit der Verschlüsselung selbst keinen Abbruch.

is sort of essentially blockchain without the decentralized ledger part

So a [Merkle tree](http://www..com/ https://en.wikipedia.org/wiki/Merkle_tree)?

Als sie das letzte Mal an einer Regierung beteiligt waren, waren sie danach für 4 Jahre nicht im Bundestag. Vielleicht gibt's ja doch ein bisschen Hoffnung, vor denen dann erstmal Ruhe zu haben.

Many debuggers (at least in the Java world, which is what I'm working with for a living) support more advanced features like only triggering the breakpoint if a certain condition is reached or only every X hits of the breakpoint.

Also, if you try and debug using print in the main game loop, wouldn't that write so much to console/log that it's effectively unreadable?

Native Applikationen sind ja auch weiterhin ne gute Sache für bestimmte Anwendungsfälle, in denen Docker die Sache einfach schwieriger macht. Beispiel von mir: für's Management meiner Access Points betreibe ich einen Unifi Controller in einem Docker, was an sich kein Problem ist. Wenn man dann aber anfängt, mit VLANs und Konsorten zu hantieren, muss man einige Verrenkungen machen, damit der relevante Traffic auch im Container ankommt. Wenn man den Controller nativ betreibt, hat man sich quasi einen Mittelsmann gespart.

Ich muss aber dazu sagen, dass ich grundsätzlich aus der Schleife bin und deswegen vielleicht auch träge bei neuen (hab ~2014 davon gelesen gehabt) Entwicklung.

Ist ja nicht verkehrt, manche Trends verschwinden ja nach ein paar Jahren auch wieder :D

Für viele nützliche Dienste gibt es inzwischen auch häufig direkt vom Entwickler docker-compose Files, die es echt trivial machen, eine Anwendung inklusive aller benötigten anderen Dienste hochzufahren und somit einen guten Startpunkt liefern, sich mal näher mit der Materie zu beschäftigen.

Aber Docker ist wirklich super praktisch. Ich hatte die "Idee" hinter Docker mal irgendwo als Meme gesehen, was in Textform ungefähr so geht: "But it works on my machine!" - "Well, then we'll just ship your machine"

Interestingly, the guy who made the referenced post, 'avis', is allegedly the new name of 'birdie', a well-known troll on the forums who was banned a while back. Basically everyone there agrees that it's him and no action is taken against this new account.

It's important in science (but also in general) to verify things that are thought to be obvious or "common sense", since not everything that the broad public agrees on is true after all.

Aber essen willst du schon was, oder?

It was underpowered when the Switch released, yes, but I'd wager that it was a good choice for the application when Nintendo started designing the Switch. Couple that with the (not unreasonable IMO) expectation that there would be successors to the X1 that they could hypothetically put into the Switch and release a higher-perf revision with minimal changes, I can see why they chose it. Unfortunately, Nvidia dropped the X1 line and that (again, purely speculative) scenario never manifested.

Du könntest ja auch das ganze in Rust bauen (**) und das C FFI verwenden, um die Bibliothek anzubinden und dir quasi einen eigenen kleinen Wrapper für raylib bauen. Dann kannst du wie gehabt Cargo zum bauen und für die dependencies verwenden.

The heavy stuff would be things like shader compilation and state management for multiple different graphics APIs (OpenGL and Vulkan mostly).

AFAIK Linux graphics drivers are usually separated into a userspace and a kernel space component, like amdgpu on the kernel side and RADV/RadeonSI within Mesa on the userspace side. So you do not need to do a full reboot to e.g. benefit from performance optimizations within Mesa to get things like faster shader compilation or more efficient draw call submission, which I think most people care about when doing driver updates. In fact you don't even need to soft reboot, because once Mesa is updated, all following uses of it already run the new version, all without a reboot. However if your GPU is not yet supported by the kernel side, then Mesa is of no use to you.

That being said, yes the kernel side is a very important part of the driver, but it's such a low-level driver that very few people would be able to do much of anything with it, which is why I made that distinction.

Man kann certbot auch mehrere Domains geben, damit er ein einziges Zertifikat für alle (Sub-)Domains generiert. Und man braucht auch kein Zertifikat für eine HTTPS-Verbindung zum Server, aber wenn man keins hat meckert der Browser berechtigterweise rum, weil dann das Risiko eines Man-in-the-middle-Angriffs besteht.

Hier auch ein gutes Tutorial für einen Nginx reverse proxy: https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-on-ubuntu-22-04