JATtho

BioShock infinite was ok experince on linux, I have completed it twice. (The native binary runs via its own internal translation scheme, so I suggest running via dxvk/proton instead for more speed.) I would say however that it'll be a lot more hollow and straight forward "pipe run" than its predecessors. I own bioshock 2, but it's dead, obsolete M$hit only version that i haven't played since it eated my save files three times.

1st problem is that the mercury will highly likely poison the fusion plasma. The blanket is already a hard engineering problem to have it work in a "regular fusion reactor". 2nd problem nobody has said anything about is that you get a mixture of radioactive isotopes out of (a supposedly working) a transmutation reactor. This adds to required enrichment processes: to get 100% mercury-198 (from 10%) and possibly a purification of the freshly radioactive gold.

I'd imagine radioactive gold is pretty much worthless. The Au-197 is metastable, and to my flaky understanding will emit gamma-rays, not to mention the other isotopes generated around Au-197.

Can I have some default juice? I think I glitched the matrix (again) today.

Sure it's terrifying, but you can start a sparky plasma show in a resilient enough container and keep it going for hours and the microwave won't break. (except maybe overheat.) The microwave will be fine as long as the arcs don't reach the waveguide cover. (which would risk burning/shorting the magnetron.)

I have done the microwave grape plasma trick myself and started an arc in a microwave. The current between the two objects goes through a very narrow point, which is enough vaporize the contact point to plasma. This then can grow as the microwave continues to pump more energy into the spark.

hardmode: I did a fresh install on a HDD that is on verge of being dead. Every-time this thing boots it's a miracle. Somehow dd blanking the disk, plenty of smartctl offline disk surface scans and finally putting btrfs with data in DUP profile resurrected the HDD. I have run btrfs scrub daily or else the os install may bitrot and well.. expire. :D

Edit: Todays catch, I was too late and now I have fix 3 files:

Error summary:    read=112
  Corrected:      109
  Uncorrectable:  3
  Unverified:     0

Two new hobbies to keep me in the reality^tm^.

So this is it. The enshittification has reached slowlorris levels.

I spent solid 10min writing an useful answer and then looked up. Now I want my 10mins back.

Oh, this is a good one.

No mention of KDevelop? ;__;

I like it because it is the pretty much only FOSS graphical IDE where the edit-compile-debug cycle works. I'm been using it for last 10y for C/C++/Python, and it recently gained LSP support. (ported from Kate)

The \EFI\BOOT\BOOTX64.EFI is the only file the UEFI standard says it is required automatically lookup from an EFI system partition. There can many EFI partitions but the UEFI is only required to find a single file per such a partition.

efibootmgr -u can show all bios auto created boot entries (don't touch those, the bios can/will reset them at whim) and the manually created entries that don't launch a BOOTX64.EFI named file.

I intended this an sarcastic example; I think it's worse than putting the main outside of the branch because of the extra indent-level. It does have an upside that the main() doesn't exist if you try import this as an module.