pm215 · HackerTrans

3 dagen geledendiscuss

I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly to "do the simple thing", and there wasn't so much variation in where you might put important binaries like the shell), plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does), plus vague worries about potentially accidentally breaking existing #! lines that used to work.

pm215

12 dagen geledendiscuss

Mmm. This Q&A -- https://www.chicagomanualofstyle.org/qanda/data/faq/topics/M... -- suggests it's been kicking around as printing and journalism jargon since at least the 1980s, and I would expect probably earlier.

pm215

vorige maanddiscuss

The city government tracks data on public realm trees, and has a nice map based visualization of it: https://www.london.gov.uk/programmes-and-strategies/environm... and if you zoom in you'll see that many of these are streetside trees.

Personally I have always felt that most Japanese cities are very devoid of urban greenery compared to UK towns and cities.

pm215

2 maanden geledendiscuss

Yes, QEMU's JIT is a fairly easy target to beat. Notably if you are happy to specialize the design to "only x86 to aarch64" and "only usermode" there's quite a lot of gain to be made. QEMU's usermode support is a kind of "this happens to work" appendix to its system emulation support, and the overall JIT architecture is a "guest to intermediate representation to host" one that is great for supporting a dozen guest architectures and multiple host architectures, but means you can't really take advantage of properties of a specific guest/host pair like "x86 has fewer integer registers so we can hard allocate them" or "we know the fiddly floating point semantics always match if you put the aarch64 CPU into the right mode". Plus there's just more time put into "emulate new architecture feature X" in QEMU development than into "look at optimization opportunities to make it faster", because that's what the people who pay for development work care more about.

pm215

3 maanden geledendiscuss

For a long time in the dialup era my "answering machine" was a US Robotics voice-capable modem attached to my home Linux PC, with some scripts to make it pick up after N rings, play a message, record whatever the caller said, and then email me the resulting sound file. The Linux support for it included DTMF tone recognition, so I added in a quick hack so that if I sent it the right pin code during the "please leave a message" part it would wait for me to hang up and then dial my ISP, so I could ssh in to it from wherever I was...

pm215

3 maanden geledendiscuss

Unfortunately the 70% price rise on the JR pass back in 2023 made it much less likely to be economic for most people compared to just buying tickets as you go, even for trips that visit more than one city. Last time I was there I did a loop up from Tokyo to Hokkaido and back by rail, and it was still cheaper to buy individual tickets. (There are obviously still some itineraries where it works out cheaper, but it's much less of an "obviously good idea for most people" than it was back before 2023.)

pm215

4 maanden geledendiscuss

Also, "why these 5 in particular" is definitely not obvious -- there are a great many possible "obvious in some sense but also true in an important way" epigrams to choose from (the Perlis link from another comment has over a hundred). That Pike picked these 5 to emphasise tells you something about his view of programming, and doubly so given that they are rather overlapping in what they're talking about.

pm215

4 maanden geledendiscuss

If the team is that small and working on things that are that disparate, then it is also very vulnerable to one of those people leaving, at which point there's a whole part of the project that nobody on the team has a good understanding of.

Having somebody else devote enough time to being up to speed enough to do code review on an area is also an investment in resilience so the team isn't suddenly in huge difficulty if the lone expert in that area leaves. It's still a problem, but at least you have one other person who's been looking at the code and talking about it with the now-departed expert, instead of nobody.

pm215

4 maanden geledendiscuss

A fairly large category of the flaky CI jobs I see is "dodgy infrastructure". For instance one recurring type for our project is one I just saw fail this afternoon, where a gitlab CI runner tries to clone the git repo from gitlab itself and gets an HTTP 502 error. We've also had issues with "the s390 VM that does CI job running is on an overloaded host, so mostly it's fine but occasionally the VM gets starved of CPU and some of the tests time out".

We do also have some genuinely flaky tests, but it's pretty tempting to hit the big "just retry" button when there's all this flakiness we can't control mixed in there.

pm215

5 maanden geledendiscuss

That's why I said "somebody else, without looking at it". Clean-room reimplementation, if you like. The functionality is not forever unimplementable, it is only not implementable by merging this AI-generated PR.

It's similar to how I can't implement a feature by copying-and-pasting the obvious code from some commercially licensed project. But somebody else could write basically the same thing independently without knowing about the proprietary-license code, and that would be fine.

pm215

5 maanden geledendiscuss

If you're going to set a firm "no AI" policy, then my inclination would be to treat that kind of PR in the same way the US legal system does evidence obtained illegally: you say "sorry, no, we told you the rules and so you've wasted effort -- we will not take this even if it is good and perhaps the only sensible implementation". Perhaps somebody else will eventually re-implement it later without looking at the AI PR.

pm215

5 maanden geledendiscuss

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.

pm215

5 maanden geledendiscuss

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.

pm215

5 maanden geledendiscuss

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.

pm215

5 maanden geledendiscuss

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.

pm215

5 maanden geledendiscuss

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.

pm215

6 maanden geledendiscuss

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.

pm215

6 maanden geledendiscuss

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.

pm215

6 maanden geledendiscuss

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.

pm215

6 maanden geledendiscuss

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.

comments