There is a rare but repeatable bug in all versions of OpenZFS that silently corrupts data. This includes the pre- releases. 2.2.1 seems to reduce the odds of it happening but does not fix the issue.

From the reports I'm seeing, it would appear that nobody actually understands how ZFS (or Btrfs, for that matter) actually works, they're limited to whatever component they've specialised in.

Linux has a kernel mechanism for improving data reliability on filing systems that support it - dm-integrity.

I've no idea how well tested this component is. I don't recall ever having heard of it before. A quick Google suggests that it works but is very slow, though I would inagine it will improve with time.

Phoronix, OpenZFS Data Corruption Battle
TRUENAS, Corruption with OpenZFS ongoing
YCombinator, OpenZFS silent corruption bug
Level 1 Techs, OpenZFS silent corruption bug

OpenZFS is not included in the Linux kernel by default dud to licensing issues, but I believe it is currently developed on Linux and ported to other OS'. (Wikipedia says that this has been the case since 2013.) It now runs in the kernel, so it's a lot faster than it was when it worked with Fuse.

Wikipedia, OpenZFS

This is a high performance, high reliability filing system, so data corruption is really bad news. It's designed for the enterprise and outclasses Microsoft's RefFS on essentially every stat. Irs main disadvantage is that it is resource-intensive, although the license is another important issue.

One drawback with OpenZFS is that it doesn't currently support RAID. Which is odd, given the intended market.

Interestingly, I don't know of any cloud providers or corporations that actually use OpenZFS. Ext4 tends to be more popular, at the expense of enterprise features.

Oracle has re-closed Solaris' ZFS, so the two filesystems are no longer compatible. But as effectively nobody uses Oracle Solaris, this doesn't matter much.

I guess the main takeaways with the current OpenZFS bug are that filing systems are becoming too complex for the hunt-and-peck approach often used in both commercial and open source projects, and that the popularity of other filing systems in OpenZFS' own domain suggests that feature-rich filesystems might actually be the wrong approach.

https://arstechnica.com/security/2023/11/developers-cant-seem-to-stop-exposing-credentials-in-publicly-accessible-code/amp/
https://www.theregister.com/2023/11/13/royal_mail_cybersecurity_still_a/
https://www.itgovernance.co.uk/blog/list-of-data-breaches-and-cyber-attacks-in-2023
https://www.securityweek.com/tens-of-thousands-of-cisco-devices-hacked-via-zero-day-vulnerability/

It would appear, on the face of the above links, that developers still take shortcuts and don't program defensively, and that IT departments avoid applying security fixes and are not taking other protective measures (such as encrypting databases).

Cybersecurity, from the looks of things, is something that is simply never taken seriously. An optional extra that poses no consequences if not applied.

The consequences can be severe. The number of people at risk In Maine from identity theft runs into the millions. The loss of privacy from the intensive care ward that was recently hacked may have severe financial and employment consequences.

And yet neither programmers nor IT managers are altering their behaviour, despite the potential for enormous consequences to those they are responsible for.

Libertarians would argue that people can switch providers, but some providers are either de facto monopolies or natural monopolies. In other cases, there's no evidence that any of the alternatives are any better. Market forces don't function when there's no functional market.

But what's the alternative? There's no evidence regulation is helping, where regulations exist and are meaningfully enforced. It's just considered the cost of doing business.

What, then, would actually help?

I got a big fat BLOCKED screen today trying to post a comment. It had no links, no profanity, and I didn't even use the b!zx word or the Naz! word. Pack your shit, folks

You can tell this place has really gone to shit because the people trolling me keep coming up with dumber and dumber arguments.

Awaiting Netcraft confirmation of its demise.

The High-Performance Conjugate Gradient benchmark shows Supercomputer Fugaku top of the list, with Frontier as second place. This is, of course, the reverse order of the Top 500 list.

The stats?

Fugaku:

Cores: 7,630,848
Linpack Performance (Rmax) 442.01 PFlop/s
Theoretical Peak (Rpeak) 537.21 PFlop/s
Nmax 21,288,960
HPCG [TFlop/s] 16,004.5

Frontier:

Cores: 8,730,112
Linpack Performance (Rmax) 1,102.00 PFlop/s
Theoretical Peak (Rpeak) 1,685.65 PFlop/s
Nmax 24,440,832
HPCG [TFlop/s] 14,054.0

This is interesting because Frontier has two and a half times the Rmax and 1.1 million more CPU cores to play with. That's not a trivial figure. Of course, Fugaku is running Linux, whereas Frontier is running an OS from some upstart called Cray, so one might expect Fugaku to do better on those grounds.

For those wanting to compare their own PCs to these computers, here's the source code:

Linpack Source
HPCG Source

Yes, an actual WW2 Mosquito is being sold.

A DH98 Mosquito, bomber variant, is being restored (and a good chunk rebuilt from scratch). It'll be the only bomber of this type of plane that is airworthy, on completion.

The current owners also want to sell it. At NZ$11 million plus, it's not cheap. (But it'd be a hell of a way to commute to work.)

I've only ever seen one other Mosquito sold, they're that rare - especially in flying condition. It's this last bit that worries me, as collectors have bought flying Mosquitos purely to let them deteriorate in the open. This is partly why only something like three still fly

This is an amazing plane and, no, I don't honestly thing a whip-round of Slashdotters would get the money needed to but it and keep it in running condition.

This journal entry, then, is more about salivating at this truly geeky aircraft. If anyone has a TARDIS handy, and next week's lottery numbers, this would be a cool toy to have.

Some time ago, I put forward an idea for an improved schooling system. It would cost more than a regular school for the same number of students, but should - in theory - result in students getting the education they need rather than some low-grade default that will end up causing harm. But how would you estimate the benefit of such an idea, given that it would be impossible to persuade anyone of the merit of trying it out without some evidence that it would actually generate more value than the extra it would cost?

I've also got some ideas for inventions, but they run into a similar problem - it would cost a fair bit of cash to go from idea to something solid that could be sold, but how do you estimate how much you could make off such inventions without actually investing the money and trying it out? (I don't have the money, so it would take an investment by someone and that would require that I persuade that someone that there'd be a worthwhile return. Which is going to require some sort of estimate and a plan of how to achieve that.)

This is something that big companies can afford to play around with, but if you're starting off from scratch, you don't get play money to throw at such things. You have to know what is likely to work before trying it out. The reason that most start-ups fail is that they have the ideas but either very, very bad estimates or no estimates at all.

If it's impossible to know if an idea is worth pursuing, then only those who are willing to take massive risks will ever pursue their ideas, but those are likely to be the ideas not worth pursuing. The intelligent, rational ideas that are worth chasing up won't ever happen because those are the people who won't have the resources to try the ideas out.

It's slow as fuck and it doesn't work worth one.

The source code for MUD-1 has been released under GPL-3. This includes the two adventures - MUD and Valley - that the server originally supported. A third, based on Essex University memes and a genocidal interpretation of Fraggle Rock, no longer exists anywhere, regrettably. Instructions for building the game on an emulator running under Linux is provided, but I'd still rather do a proper port to a modern language and not have to run emulators. Essex BCPL is the dialect of BCPL needed to compile the MUD1 sources for the DEC10.

Machine-independent BCPL will compile most of the code and would be the place to start if wanting to run on a Linux box. Be warned, as MUD-1 doesn't use sockets, the networking code would have to be rewritten or emulated if the engine was to be ported.

For those who missed my earlier journal, MUD-1 is the original multi-user text adventure, originally written for a DEC-10 mainframe. For its time, the map is massive, and the full-sentence parser (although primitive) was more powerful than that of any PC adventures (including Infocom's) and, indeed, that of any of the later MUDs. although Discworld's custom game engine comes close.

Porting MUD-1 to a modern language would be tough - BCPL doesn't have many conversion programs out there - but I can't see it as being impossible. This would demonstrate the mad coding skills of people like Richard Bartle (who now writes such software professionally). The alternative would be to write a translator that converted the MUD-1 map and objects into a format suitable for FluffOS (the Discworld MUD game driver that has been publicly released) or one of the other MUD engines. Technically, this should be much easier, but still very challenging.

Also included in the archives released are the original Zork and Spacewar. Zork was converted from MDL to C, by way of Fortran. and one person's archive of this can be found here. MDL isn't BCPL, so I can't use the same code.

For those wanting to run the original original Zork, as opposed to the translated version, MUDDLE is the original name for MDL and this should work. At worst, it's another language for geeks to learn. :)

Thanks to Richard Bartle, I have the source code for the original multi-user adventure game MUD-1. Map included. The code is written in BCPL and is intended to run on the Essex DEC-10 mainframe. It sometimes ran on other DEC-10 mainframes, but could be temperamental.

There are essentially four options:

1. Debug the code so that it'll run smoothly in a DEC-10 emulator
2. Modify the BCPL code to run under Linux (there is a BCPL compiler for it)
3. Hack CircleMUD or some other LPMud descendent to re-implement the parser and other missing features, then port the map and puzzles over
4. Reimplement the entire game in a more modern language

So far, I've been pursuing option 1. It's not easy, those DEC-10 emulators are, in themselves, a bugbear. I'm now switching my attention to option 2. A BCPL interpreter by the same author as the original used by Roy Trubshaw and Richard Bartle to write MUD-1 does exist for Linux. The source is free. The restriction of private or academic might be an issue depending on what that restriction means in practice.

Although I'd normally prefer to go this route and preserve some wonderful historic code, clean-rooming the features may prove easier and would come with fewer entanglements. In either case, I'll need to improve my skills in BCPL, a language that now really only has this one purpose to justify its continued use.

I know there are a few out there who can remember either this specific game or MUDding in general. I'm curious as to what the popular view would be.

It's worth noting that MUD-1 is still actively running on British Legends at https://www.british-legends.com/CMS/

So why bother with trying to get the server up? Because I don't like being tied to an organization that can vanish at any moment, because there's too much PK-ing there, because new wizards/witches don't get added to the graveyard maze, and because they removed the berserker code. (Berserkers in MUD-1 could get twice the value from player killing and were the only ones who could use the broadsword, but could get no points from treasure, had to become berserkers before they reached level 4, and couldn't become wizards/witches.)

Also because there's some nasty bugs left in with NPCs and these really should be fixed.

Genetic Age:
https://www.theguardian.com/science/2022/jun/13/biological-age-startups-why
https://clockfoundation.org/
https://www.mydnage.com/

Whole Genome Sequencing and search engines:
https://nebula.org/
https://www.gedmatch.com/
https://promethease.com/
https://blast.ncbi.nlm.nih.gov/Blast.cgi

Miscellaneous articles:
https://www.today.com/health/do-personalized-diets-work-t183387
https://www.self.com/story/dna-diet
https://www.forbes.com/sites/bernardmarr/2021/02/26/whats-biohacking-all-you-need-to-know-about-the-latest-health-craze/
https://www.webmd.com/vitamins-and-supplements/features/nootropics-smart-drugs-overview

So many tools, so little useful guidance. For example, if you get guidance on diet via a genetics site or a biohacking site, how does that impact your biological age as measured under the Clock Foundation's measures? If at all? If we can objectively test claims, where are the studies showing the experiments?

And if the error bars are too high, then how do we know if the measurements are saying anything at all?

If none of this is known and it's all about doing the experiments, then who is doing those experiments? And what experiments are they doing?

Normally I'd post an article like this to my own blog, but since I've not bothered to bring it back up since my web host died this is, sadly, the most reasonable place for me to post. In the past I've done detailed howtos and this will not be that, because all I really need it to be is just a record of more or less what I did. To wit, I got Ubuntu installed and working correctly on my antique potatoe, an FX-8350, 990FX-based system with nvidia graphics, NVMe storage, and UEFI with BIOS compat.

I installed from vmware on Windows. Created my VM with 3 out of my 8 cores and 8GB RAM. I added the physical NVMe disk to the VM config as an NVMe disk specifically. Install went off smoothly. But after updating my Firefox snap was already broken, so I decided to blow away snap and install normal firefox. I also installed kde-plasma-desktop and kde-full in order to get away from Unity, and because gnome is in a snap too. I could have just installed kubuntu, but I wanted to see what the process would be like with the normal Ubuntu CD.

Unfortunately, after the install, the USB3 doesn't work. This turns out to be a problem with IOMMU settings. It also causes the boot to be extended while things fail. Short form, in /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_iommu=on iommu=pt"

On boot I was using Nouveau and needed to install nvidia drivers (sudo ubuntu-drivers autoinstall). Sadly these driver versions only support "Mosaic" "SLI", which is where your display spans monitors. I may try an older driver to get SLI working again. Getting nvidia-settings working required running nvidia-xconfig (as root) in order to produce a working xorg.conf, and also fixing a polkit permissions issue (sudo chmod u+x /usr/share/screen-resolution-extra/nvidia-polkit). Even worse, the screen stays dark after resume from suspend. This is of course because of systemd.

sudo systemctl stop nvidia-suspend.service
sudo systemctl stop nvidia-hibernate.service
sudo systemctl stop nvidia-resume.service
sudo systemctl disable nvidia-suspend.service
sudo systemctl disable nvidia-hibernate.service
sudo systemctl disable nvidia-resume.service
sudo rm /lib/systemd/system-sleep/nvidia

Finally, part of the use case is being able to boot Windows from Linux and Linux from Windows, both in vmware player. The Windows stuff is trivial, clicky clicky. The Linux stuff isn't because vmware doesn't bother to keep their vmnet and vmmon modules updated for modern kernels. After installing vmware but before launching vmplayer, install the right version from the above repo for your vmware and kernel versions. You have to be root in order to use physical devices on Linux (or maybe you can solve it with group perms? Haven't tried this yet.) Windows is on SATA on my system so I added the SATA full disk as a SATA disk and it works fine.

https://physicsworld.com/a/web-of-confusion/

A school teacher has written an excellent piece on how sites give misleading to blatantly incorrect information, even on very basic science.

The idea that people who are given bogus information on the majority of sites can do their own research on the Internet is increasingly dubious, but there's no easy solution as long as the interwebs are regarded as reliable, or better, than subject matter experts.

Someone suggested writing their own Linux distro. That's what I did, back in the day before decent distros. Now we're post-decent, that might not be such a bad idea. But how would you structure it?

My thinking is that you could have some basic, tested, packages that you're sure work fine, plus an automated test suite, plus some cross-compilers and some VM images.

Person X requests a distro and wants a basic. They get the basic, precompiled version.

Person Y requests a distro, wants it tuned and runs a tuning app. This gives a rundown on hardware present. The cross compilers then build optimised binaries for that platform, omitting unwanted drivers and including normally disabled options that can be exploited. This is tested on the VM using the automated tests. Anything that fails the test gets swapped for the basic binaries. Person Y gets emailed their distro is now available for download.

Person Z requests the distro for a normally unsupported platform for which the tuning binary has been built. Same as above, but features that fail the test don't get included.

This gives you the same sort of flexibility as gentoo, without having to mess with flags personally and without having to have the horsepower to compile everything at a decent speed, with the added bonuses that the site can serve the distro to multiple people with similar hardware (so build once, serve many), better testing to avoid hardware quirks, and with easier flag handling for such corner cases.

In principle, this means you have to write thorough automated test suites, but only have to produce a handful of validated releases to support a far wider range of situations.