pm215

Even if there isn't any 3rd party code, the whole process of going through the codebase to confirm there really isn't any 3rd party code, and generally getting the legal department to sign off on it, is a lot of work in itself. My impression is that this kind of "historic source" release typically only happens if somebody sufficiently senior in the company cares enough to actively push it through. The default is that nobody does care that much, and it doesn't happen.

"Do nothing" has essentially zero downside for a big company that happens to have something of niche interest like this in its vaults.

I think Coccinelle is a really cool tool, but I find its documentation totally incomprehensible for some reason. I've read through it multiple times, but I always end up having to find some preexisting script that does what I want, or else to blunder around trying different variations at random until something works, which is frustrating.

On the tangential question in the post:

"The specification describes bits as combinations of 0, 1, and x, but also sometimes includes (0) and (1). I’m not sure what the parenthesized versions mean"

the answer is that the (0) and (1) are should-be-zero and should-be-one bits: if you set them wrongly then you get CONSTRAINED UNPREDICTABLE behaviour where the CPU might UNDEF, NOP, ignore that you set the bit wrongly, or set the destination register to garbage. In contrast, plain 0 and 1 are bits that have to be that way to decode to this instruction, and if you set them to something else then the decode will take you to some other instruction (or to UNDEF) instead.

This is an important ISA feature -- an instruction encoding that is wasteful of its encoding space is one that has no room for future new instructions (or which has to encode the new instructions in complicated ways to fit in whatever tiny "holes" are left in the encoding space).

The old 32-bit Arm encoding had this problem, partly because of the "all instructions are conditional" feature. Even after the clawback of the "never" condition that wasted 1/16 of the available instruction encoding space as NOPs, it was tricky to find places to put new features.

This is a result of the market and its demands, not something specific to the architecture. In desktop and server, customers demand that they can buy a new machine and install a previously released stable OS on it. That means the vendors will implement the necessary standards and cross compatibility to make that happen. In the embedded market, customers don't demand that, and so vendors have no incentive to provide it. Instead what you get is that the specific combined hardware-and-software product works and is shipped with whatever expedient set of hacks gets it out of the door. Having a new cool hardware feature that works somehow or other is more important for sales than whether that driver is upstream or there's a way to describe it in ACPI.

Where Arm is in markets that do demand compatibility (i.e. server) the standards like UEFI and ACPI are there and work. Where it's in markets like embedded, you still see the embedded profusion of different random stuff. Where other architectures are in the embedded market, you also see a wide range of different not very compatible hardware: look at riscv for an example.

It's not a completely non special character: for instance in bash it's special inside braces in the syntax where "/{,usr/}bin" expands to "/bin /usr/bin". But the need to start that syntax with the open brace will remind you about the need to escape a literal comma there if you ever want one.

Ah, thanks for that correction -- I jumped straight from "depends on the history of conditional branches" to "branch predictor" without stopping to think that that would have been unlikely in the 386.

Yeah, I think random-instruction-sequence testing is a pretty good approach to try to find the problems you didn't think of up front. I wrote a very simple tool for this years ago to help flush out bugs in QEMU: https://gitlab.com/pm215/risu

Though the bugs we were looking to catch there were definitely not the multiple-interacting-subsystems type, and more just the "corner cases in input data values in floating point instructions" variety.

Some of the 386 bugs described there sound to me like the classic kind of "multiple different subsystems interact in the wrong way" issue that can slip through the testing process and get into hardware, like this one:

> For example, there was one bug that manifested itself in incorrect instruction decoding if a conditional branch instruction had just the right sequence of taken/not-taken history, and the branch instruction was followed immediately by a selector load, and one of the first two instructions at the destination of the branch was itself a jump, call, or return.

Even if you write up a comprehensive test plan for the branch predictor, and for selector loads, and so on, it might easily not include that particular corner case. And pre silicon testing is expensive and slow, which also limits how much of it you can do.

I wasn't arguing that getting LLMs to do this is necessarily bad -- I just think it really is different from having in the past been able to ask other humans for help, and so that past experience isn't a reliable guide to whether we might find we have problems with unexpected effects of this new technology.

If you are concerned about possible harms in "outsourcing thinking and writing" (whether to an LLM or another human) then I think that the frequency and completeness with which you do that outsourcing matters a lot.

I think there are a couple of differences here:

Firstly, when you ask a friend or colleague you're asking a favour that you know will take them some time and effort. So you save it for the important stuff, and the rest of the time you keep putting in the effort yourself. With an LLM it's much easier to lean on the assistance more frequently.

Secondly, I think when a friend is giving advice the responses are more likely to be advice, i.e. more often generalities like "you should emphasize this bit of your resume more strongly" or point fixes to grammar errors, partly because that's less effort and partly because "let me just rewrite this whole thing the way I would have written it" can come across as a bit rude if it wasn't explicitly asked for. Obviously you can prompt the LLM to only provide critique at that level, but it's also really easy to just let it do a lot more of the work.

But if you know you're prone to getting into conflicts in email, an LLM powered filter on outgoing email that flagged up "hey, you're probably going to regret sending that" mails before they went out the door seems like it might be a helpful tool.

You can have either completely separate hot and cold taps, each with their own spout, or you can have a setup with separate hot and cold knobs and a single spout.

For my bathroom sink I specified a two taps/one spout unit (similar to this one https://www.screwfix.com/p/swirl-traditional-chrome-104mm-cl... ) because I prefer to be able to get "this is definitely cold water with absolutely no hot water mixed in" when that's what I want. (My hot water comes from a combi boiler, so if you run the hot tap for a short time all that happens is you burn some gas when the boiler detects the water flow but you just get the cold water in the pipe.)

I like the combined handle type for showers, where you always want some hot water and are generally running the water for a long time.

The fun thing about those thunderbolt cables is they have two Arm cores in them, one at each end...

Tape save and load seemed pretty reasonable on our system. It does depend rather on the tape deck you're using and also on getting the volume and tone settings right, though. We had the official TI tape deck for it.

I'm pretty sure my Dad got ours because they were being sold off very cheaply after TI pulled out of the home computer market. Like you I ended up learning BASIC on it because as an abandoned system all we had was a few cartridge games, some user-group programs, and typed in BASIC. It worked out pretty well really. (Later we got an Amstrad CPC 6128, which had a much bigger commercial games market.)

Yes; this is why QEMU's user-space-emulation clone syscall handling restricts the caller to only those combinations of clone flags which match either "looks like fork()" or "looks like creating a new pthread", because QEMU itself is linked with the host libc and weird clone flag combinations will put the new process/thread into a state the libc isn't expecting.

I think rather than "laziness" I would say it's an instance of the widespread phenomenon of "shipping the orgchart". Because for Linux the kernel developers and the libc developers are separate communities, the boundary between those components becomes more meaningful, more visible to the end-user, and more likely to have lag where one side supports something and the other doesn't yet. (That goes both ways, incidentally -- the handling of POSIX threads was driven more from the libc side of the fence and it took a while before the kernel provided enough facilities to make it cleanly doable, and there are still corners like setuid() where there is a mismatch between what the standard wants and the primitives the kernel provides). Where an OS has a more tightly integrated development team the kernel/libc boundary is more likely to stay an internal one.

I think it's quite hard to talk about norms for reading quantity, because it varies so much between people. There are a lot of people (more than half the population) who read basically no books in a year, and a tiny slice who read a huge number: so your intuitive take on what's "normal" is going to depend a lot on whether your social circle happens to have voracious readers in it. I suppose you can statistically determine some point in between as the "norm" but I'm not sure that point would reflect many people's experience...

I suspect that a 1970s mower for UK garden use was typically not very beefy. Wikipedia thinks Larkin had some kind of Victa.

"suspiciously close" isn't close enough, unfortunately, though it might make the task less work:

If your uname output, compiler architecture ifdefs, etc, don't match the existing architecture then basically every program that does per architecture specialisation will need updating, even if fairly trivially so.

If you're not building and running identical binaries, then anybody who distributes binaries needs to be persuaded that it's worthwhile to get hold of build machines and devote archive space and maintenance time to your new architecture.

There may be political issues where neither the owners of the old architecture nor the owners of the new clone want to come out and admit that it's very similar. This may result in projects treating it as "genuinely new architecture" rather than "variant of an existing one", which is more work. (There are also technical concerns about future divergence that might argue for "not just a variant".)

If you have to have the code structure of a complete new architecture then this can also trigger more work where the old arch code got to get away with legacy practices and APIs but the newcomer is expected to reach any project standards for new code, so "copy, paste, rename" is insufficient. Sometimes this imposes constraints that make more work elsewhere: for instance a new architecture in Linux is expected to follow a modern syscall numbering scheme and set of syscalls, so it won't have a userspace ABI that's compatible with the arch it is cloning.

If the architecture you're cloning is a "declining" architecture now mostly in legacy setups, then modern projects you care about for your new architecture might not have good or any support for it. (If you cloned sh4 you won't have easy rust support, for example.)

Overall, getting a new architecture from "we have a spec" to comprehensive open source ecosystem support is a heavy lift, and clone and copy doesn't get you out of all of it. (Look back at how long it took 32 bit Arm and then 64 bit Arm and now how riscv is following similar paths. These have all been years long efforts with a very long tail.)

I think there's two parts to this:

1) these historical source code releases really are largely historical interest only. The original programs had constraints of memory and cpu speed that no modern use case does; the set of use cases for any particular task today is very different; what users expect and will tolerate in UI has shifted; available programming languages and tooling today are much better than the pragmatic options of decades past. If you were trying to build a Unix clone today there is no way you would want to start with the historical release of sixth edition. Even xv6 is only "inspired by" it, and gets away with that because of its teaching focus. Similarly if you wanted to build some kind of "streamlined lightweight photoshop-alike" then starting from scratch would be more sensible than starting with somebody else's legacy codebase.

2) In this specific case the licence agreement explicitly forbids basically any kind of "running with it" -- you cannot distribute any derivative work. So it's not surprising that nobody has done that.

I think Doom and similar old games are one of the few counterexamples, where people find value in being able to run the specific artefact on new platforms.

This seems nuts and suggests maybe the people selling AI scrapers their bandwidth could get away with charging rather more than they do :)

I'm curious about whether there are well coded AI scrapers that have logic for "aha, this is a git forge, git clone it instead of scraping, and git fetch on a rescrape". Why are there apparently so many naive (but still coded to be massively parallel and botnet like, which is not naive in that aspect) crawlers out there?

I believe (per the stuff at the bottom of https://www.kernel.org/doc/Documentation/vm/overcommit-accou... ) that the kernel does the accounting of how much memory the new child process needs and will fail the fork() if there isn't enough. All the COW pages should be in the "shared anonymous" category so get counted once per user (i.e. once for the parent process, once for the child), ensuring that the COW copy can't fail if the fork succeeded.

Because the point of forbidding overcommit is to ensure that the only time you can discover you're out of memory is when you make a syscall that tries (explicitly or implicitly) to allocate more memory. If you don't account the COW pages to both the parent and the child process, you have a situation where you can discover the out of memory condition when the process tries to dirty the RAM and there's no page available to do that with...

You do relatively commonly see wastewater piping on the outside of a house in the UK, especially older stock (soil stack from the toilet, waste pipe from sink or bath running into it). This is fine in the UK climate where a normally empty pipe doesn't need insulation. I hear that it won't work in places that get extreme low winter temperatures, but the UK doesn't have winters that cold.

You don't see them on new builds, I think, probably because the pipe going from inside to outside would reduce insulation effectiveness.

The OED agrees about the Dutch idea, giving the etymology as:

"early modern Dutch maelstrom (now maalstroom) whirlpool < malen to grind, to whirl round (compare meal n.1) + stroom stream n"

and also thinks Dutch is the origin, with Swedish/Danish etc taking it from Dutch too:

"The use of maelstrom as a proper name (also in French) seems to come from Dutch maps, e.g. that in Mercator's Atlas (1595). There is little doubt that the word is native to Dutch (compare synonymous German regional (Low German) Maling). It is true that it is found in all the modern Scandinavian languages as a common noun, but in them it is purely literary, and likely to have been adopted from Dutch."

And I would guess that most of the kernel devs who are "working for free" are doing the stuff they personally enjoy and find satisfaction in working on, because it's a hobby -- so many of them are probably not interested in fixing random bugs for cash either.

I assumed the commonly cited 2x markup, so that would be a $100k salary, which is less than various websites say is the average US software dev salary. You could probably find cheaper elsewhere in the world, but even if you cut the salary in half that's still "bug must be doable in a week", which isn't going to cover many of the bugs people will care about.

For small stuff, the cost is just going to be too much for people to want to pay it. This bug had a $1900 bounty attached. Let's put the cost of one software engineer (salary plus overheads) at $200,000 a year, which I think is an underestimate. That's $3850 a week, so unless your bug can definitely be fixed (including getting any necessary hardware, investigation, fixing, code review overhead, etc) in two or three days it doesn't pay. And if it could obviously be done in two days then it's likely somebody would have already done that.

The above back of envelope maths ignores the overheads of interacting with the people who posted the bounties to get them to agree to pay up, and of the cost overruns on the class of bugs that look like two day fixes but take two weeks.