There are ontology editors, such as Protege, where there are a slew of logical reasoners that can tell you how information relates. This is a well-known weakness in LLMs, which know about statistical patterns but have no awareness of logical connections.

Is there a way to couple these together, so if you've a complex set of ideas, you could perhaps provide the ontological network plus some of the things that are reasoned from it, to supplement the prompt and give the LLM the information it can't in and of itself extract?

As with other technologies I've mentioned, there's a few of these. Intel uses a four bit number as a key, for example. ARM uses a different system, but I've not been able to quite fathom what that system was.

The advantage of strong memory protection is that you can't leverage memory management and page management limitations to read stuff you shouldn't have access to, but obviously the stronger it is, the slower it is and it doesn't shield you from cache exploits.

There's also the opposite problem, which is that if you're going to provide very high speed IPC, you've got to provide very fast security mechanisms and you've got to figure out how not to expose security keys to processes that shouldn't have them.

Any geeks here want to offer any thoughts on how to best do this?

I'd said in my last journal entry that there were many technologies for solving specific problems, but limited documentation outside of a simple description.

To cover thus further, I'd like to list packet dropping schemes. Just the packet dropping schemes, no other elements of quality of service such as the queueing mechanism that packet dropping is used with. This will help exemplify why proper undersranding is important.

Partial Packet Discard (PPD)
Early Packet Discard (EPD)
Age Priority Packet Discarding (APPD)
Preemptive Partial Packet Discard (pPPD)
Tail Drop
Random Early Detect (RED)
Weighted Random Early Detect (WRED)
Adaptive Random Early Detect (ARED)
Robust Random Early Detect (RRED)
Random Early Detect with Preferential Dropping (RED-PD)
Controlled Delay (CoDel)
Blue
Global Random Early Estimation for Nipping (GREEN)
Multi Global Random Early Estimation for Nipping (M-GREEN)
PURPLE
BLACK
WHITE
CHOose and Keep (CHOKe)
CHOKe-FS
CHOKe-RH
P-CHOKe
CHOKeD
gCHOKe

And this isn't even close to exhaustive. But it's absolutely guaranteed that no OS supports anything but a small fraction of this list, and equally guaranteed that no developer out there knows which unimplemented schemes would be useful in typical environments for, say, Linux or FreeBSD.

I can also be absolutely certain that no researcher out there working on new schemes knows what is currently out there, when it is useful, or how best to tune it to get a fair understanding of what a new scheme would need to do.

This should give people some idea of the scope of the problem. You often don't see AQM in the enterprise world because there's too many options and nothingnon how to effectively use them.

Pretty much the same reason enterprise systems will use Ext4 or XFS, if running a Ubuntu variant of Linux - there will be far better filesystems for specific needs, but there's way too many options, it's too complex to set up if you don't know exactly what you're doing, and no insights into what need goes with what filesystem.

Even the use of AI won't help much - LLM AIs can't learn from data that isn't out there.

A simple Neural Net could be trained on a range of schemes and workloads and then generate advice on optimal setup, but if no researcher is doing anything more than a cursory comparison, then there's nobody in a position to create such an AI. And, even then, it's only useful for comparing what's there, it still won't help developers figure out what they need to add.

(Although, it would be a great boost to network admins if they could push a button and have an AI figure out the best setup for their servers and network gear.)

There's an awful lot out there in the way of projects. Perhaps hundreds of filesystems, easily dozens of transport protocols (there's sonething like 9 or 10 for the IP protocol alone), there's maybe ten different packet dropping schemes and five or six packet queueing schemes. There's maybe ten of so wireless routing protocols. Linux alone has seen a vast range of schedulers and memory management systems, and three different threading models.

Even in encryption, the number of encryption modes submitted to NIST numbered in the dozens.

But all of these have one thing in common: there's essentially no literature describing what has been learned from any of these experiments.

Sue's, there's papers on each one individually, and sometimes you can find a top-level comparisons and benchmarks, but the level of deep understanding is, at best, limited. We use the tools that work well for us, but don't really understand why they work well.

This matters, because wheels get reinvented on a regular basis, mistakes are routinely repeated, and progress is frequently slowed down by the "Not Invented Here" syndrome that affects open and closed source worlds alike.

My question for Slashdotters, especially the academic ones - - why so little deep understanding? Theoretical work in computer technology exists, but I would not call it deep. Citeseerx and ArXiv have a vast amount of data on how, but nowhere near what I'd expect on why, and it's generally a very targeted why.

There is possible evidence that relativity may be incorrect. It would seem that gravity weakens more rapidly, at extreme distances, than are allowed for in GR.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fphys.org%2Fnews%2F2024-05-cosmic-glitch-gravity-strange-behavior.html

For some reason, this was discarded as spam from the main page, so I'm putting it in a journal instead.

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://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Farstechnica.com%2Fsecurity%2F2023%2F11%2Fdevelopers-cant-seem-to-stop-exposing-credentials-in-publicly-accessible-code%2Famp%2F
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.theregister.com%2F2023%2F11%2F13%2Froyal_mail_cybersecurity_still_a%2F
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.itgovernance.co.uk%2Fblog%2Flist-of-data-breaches-and-cyber-attacks-in-2023
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.securityweek.com%2Ftens-of-thousands-of-cisco-devices-hacked-via-zero-day-vulnerability%2F

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?

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.

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://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.british-legends.com%2FCMS%2F

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://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.theguardian.com%2Fscience%2F2022%2Fjun%2F13%2Fbiological-age-startups-why
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fclockfoundation.org%2F
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.mydnage.com%2F

Whole Genome Sequencing and search engines:
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fnebula.org%2F
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.gedmatch.com%2F
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fpromethease.com%2F
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fblast.ncbi.nlm.nih.gov%2FBlast.cgi

Miscellaneous articles:
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.today.com%2Fhealth%2Fdo-personalized-diets-work-t183387
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.self.com%2Fstory%2Fdna-diet
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.forbes.com%2Fsites%2Fbernardmarr%2F2021%2F02%2F26%2Fwhats-biohacking-all-you-need-to-know-about-the-latest-health-craze%2F
https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.webmd.com%2Fvitamins-and-supplements%2Ffeatures%2Fnootropics-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?

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fphysicsworld.com%2Fa%2Fweb-of-confusion%2F

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.