Oh, I see.
Well, I admit I feel a little better, knowing this guy is sweating under the barrel of Putin's gun, not cruising carefree on a yacht in the Gulf of Mexico.
Oh, I see.
Well, I admit I feel a little better, knowing this guy is sweating under the barrel of Putin's gun, not cruising carefree on a yacht in the Gulf of Mexico.
Nothing entertaining about this, I'm afraid. This guy is a menace to society, he has almost certainly caused the death of innocent people, he's still on the loose, and he's making our best law-enforcement agents look like amateurs.
When they slap him in handcuffs and televise his courtroom antics, *then* I'll reach for the popcorn.
Wow. What the hell for?
We already have thermonuclear weapons of apocalyptic power. I very seriously doubt that NIF is a weapons program. It would be pointless.
Solar has a hard upper limit on how much power it can produce. If you want any more than that, you'll have to look elsewhere. Fusion is an obvious candidate, assuming it can be made economical.
Pretty big assumption, I realize, but note that fusion doesn't have the huge safety and liability problems that make fission power plants obscenely expensive, so it may yet work out.
I know they're using heavy hydrogen, but I assume it has the same storage problems as light hydrogen.
Sounds good, but even small amounts of heavy hydrogen need to be stored somehow. Unless the extra neutrons remove its ability to escape from any container?
Side note: how many neutrons the reaction produces depends on the reaction. https://en.wikipedia.org/wiki/Aneutronic_fusion
This is not awesome, because hydrogen is also the fuel for the fusion reactors we're hoping to eventually build…
Energy density would be a fair bit higher, though, at least.
Maybe we can store it as water, and electrolyze it from the reactor's own energy output to feed it more hydrogen?
As far as I know, AES isn't vulnerable to quantum computers.
There was a time when all non-OTP encryption had a limited shelf life, and was to be treated as nothing more than a temporary stopgap against eavesdroppers until they obtain computers fast enough to break it.
I wonder if that's still valid, or if Moore's law is now sufficiently dead that it's no longer a concern. Will Moore's law be revived by a breakthrough in optical computing or something?
This worked, but not without the aforementioned occasional freezing. Frustrated, I did `btrfs check --repair` in hopes that it would clear whatever weird corruption I must have introduced.
This kills the volume. Had to mkfs, fetch the backup drive, and restore.
2/
Heh. Well, I did it out of frustrated anger.
Drive I/O would, at random, lock up until I power cycled the whole machine, ever since I installed these two SSDs.
The SSDs were replacements for a RAID1 pair of HDDs. I had migrated over by unplugging an HDD, mounting degraded, adding one SSD, unplugging the other HDD, and adding the other SSD.
1/
*Then* I remembered that I had pinched the SATA cables to the SSDs when I installed them. 🤦♂️ I bought a mounting bracket so I could move the SSDs such that the cables wouldn't pinch any more, along with restoring the backup.
No issues since.
I don't know whether unpinching or reformatting is what fixed it, but my guess is unpinching.
3/end
For what it's worth, I've been using btrfs RAID1 on 3 machines for a decade with no issues.
Except that one time I had the extraordinarily stupid idea of running `btrfs check --repair` on a pair of drives that were malfunctioning, due to what turned out to be pinched SATA cables. This semi-trashed the file system, exactly as the big fat warning message said it probably would. Stupid, like I said.
Side note: fun application of mdraid (the classic Linux software RAID, not dmraid): RAID1 for the EFI system partition! Use format version 1.0 to place RAID metadata at the end of the volume. (The default format places it at the beginning instead, which will confuse the BIOS.) That way, as long as nothing other than Linux ever writes to the partition, every drive in the array will be bootable.
@lispi314 @icedquinn @dushman @lanodan @a1ba
ZFS also has one issue that I consider show-stopping: it's not in-tree. ZFS has to be built separately. If it fails to build, and for some reason you don't notice that it has failed to build, your system won't boot. 😬
I can tolerate out-of-tree kernel modules for driving some exotic peripheral device or something, but the root file system? nope.avi
“You guys seriously want to expose the company's systems to whatever is on every random employee's personal unmanaged device?” Wonder how they'd respond to that.
This right here is why Rust compiles and executes example code in docs, to make sure that it actually works.
Sadly, it can only do this for code examples, not English prose…
You're going to want to s/Gitea/Forgejo/g there.
Gitea is under the control of a for-profit company. We have already learned that it is unwise to submit to such control.
Forgejo is a community fork of Gitea.
This right here is a highlights reel of medical incompetence. The existence of #LongCovid was well known almost as soon as the pandemic began…except, seemingly, to doctors.
When most patients know more about a widespread illness than most doctors do, there is something very, very wrong with doctors' training.
Also, a lot of doctors seem to have an intense aversion to admitting that they don't know what's causing a symptom, and instead accuse the patient of anxiety, laziness, or the like.
Nevermind that dire symptoms can easily *cause* anxiety and laziness. Because, y'know, they're scary and exhausting. Obviously.
What is that all about? Is med school teaching them to think that way?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.