JdeBP

Duplicates https://news.ycombinator.com/item?id=45963780 and https://news.ycombinator.com/item?id=45963949 .

Also later at https://news.ycombinator.com/item?id=45963949 .

Duplicates https://news.ycombinator.com/item?id=45963780 and https://news.ycombinator.com/item?id=45963949 .

Ever since the Verisign coup in 2003, the world has had the idea of "delegation-only" and suchlike filtering on responses from superdomain servers. More recently, query minimization was invented. Both of these can militate against the root content DNS servers doing that.

Better still, one can run one's own private root content DNS server. I've been doing that (in several ways) for a couple of decades. If ICANN decided to blackhole (say) www.microsoft.com. tomorrow, my DNS lookups wouldn't be affected.

To affect them, the aforementioned "court action" would have to target Verisign.

More realistically, DNS blocking is no longer an issue unless "they" get to the registries for the top-level/second-level domains. It's easy to make yourself immune to things injected by the root content DNS servers, with at least two mechanisms for combatting this (the better one being just running your own private root content DNS server) having existed for most of this century.

The problem with clickbait and entirely uninformative headlines like this is that sometimes they are so egregious that they discourage reading further, as one balks at having been so obviously lured by the bait. It's only through the comments section that one discovers otherwise. This hyperlink would have remained entirely unfollowed.

It's not an interactive approval process, remember. It's a ruleset-matching process. There's not really a chicken-and-egg problem where one builds up from nothing by interactively approving things at device insertion time using a keyboard, here. One does not have to begin with nothing, and one does not necessarily need to have any keyboard plugged in to the machine to adjust the ruleset.

The first possible approach is to start off with a non-empty ruleset that simply uses the "old model" (q.v.) and then switch to "opt-in" before commissioning the machine.

The second possible approach is to configure the rules from empty having logged in via the network (or a serial terminal).

The third possible approach is actually the same answer that you are envisaging for the laptop. On the laptop you "know" where the USB builtin keyboard will appear, and you start off having a rule that exactly matches it. If there's a "known" keyboard that comes "in the box" with some other type of machine, you preconfigure for that whatever it is. You can loosen it to matching everything on one specific bus, or the specific vendor/product of the supplied keyboard wherever it may be plugged in, or some such, according to what is "known" about the system; and then tighten the ruleset before commissioning the machine, as before.

The fourth possible approach is to take the boot DASD out, add it to another machine, and change the rules with that machine.

The fifth possible approach is for there to be a step that is part of installation that enumerates what is present at installation time and sets up appropriate rules for it.

You're moving your own goalposts, by now restricting this to a storage device that is fitted into an adapter to make it USB. There is no requirement to limit this to USB, however.

They'll pick up the SD/TF card and put it into a card reader that they already have, and end up running something just by opening things out of curiosity to see what's on the card.

One could pull this same trick back in the days of floppy discs. Indeed, it was a standard caution three decades ago to reformat found or (someone else's) used floppy discs. Hell, at the time the truly cautious even reformatted bought-new pre-formatted floppy discs.

This isn't a USB-specific risk. It didn't come into being because of USB, and it doesn't go away when the storage medium becomes SD/TF cards.

They certainly still plug those SD/TF cards into USB card readers that present themselves as USB mass storage devices.

Mine. Not asking whoever happens to have local physical access interactively, strictly speaking, as that just papers over one of the problems; but controlling what Human Input Devices are allowed when plugged in, by applying rules (keyable on various device parameters) set up by the administrator.

Working thus far on NetBSD, FreeBSD, and Linux. OpenBSD to come when I can actually get it to successfully install on the hardware that I have.

* https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminal-...

In principle there's no reason that X11 servers or Wayland systems cannot similarly provide find-grained control over auto-configuration instead of a just-automatically-merge-all-input-devices approach.

The entirely opposite perspective is quite interesting:

The "natural numbers" are the biggest mis-nomer in mathematics. They are the most un-Natural ones. The numbers that occur in Nature are almost always complex, and are neither integers nor rationals (nor even algebraics).

When you approach reality through the lens of mathematics that concentrates the most upon these countable sets, you very often end up with infinite series in order to express physical reality, from Feynman sums to Taylor expansions.

More usually, people imagine the reverse of the advanced alien civilizations: that the thing that we and they are most likely to have in common is the concept of obtaining the ratio between a circle's circumference and its diameter, whereas the things that they possibly aren't even aware of are going to be concepts like economics or poetry.

You need to look at non-x86 architectures. It was common years ago on MIPS.

* https://jdebp.uk/FGA/function-perilogues.html#StandardMIPS

I wrote up the x86 equivalent of doing just two read-modify-write operations on the stack pointer over 16 years ago.

* https://jdebp.uk/FGA/function-perilogues.html#Standardx86

The irony of that example is that it is not the same as BlueSky here. There were huge parts of the FediVerse entirely untouched by what happened at Mastodon.LOL .

The protected mode drivers are already loaded in this scenario. The VMM and all of the VxDs are already up and running. All that's really happening here is the first VM (the "systemm VM") is running the DOS+Windows 95 kernel/user/gdi/system/network/display/keyboard and applications, and a second VM is running the DOS+Windows 3.1 kernel/user/gdi/system/network/display/keyboard and applications.

The former's VMM and VxDs were largely a superset of the latter's. The only real trick is that there was a secret handshake between the DOS program WIN and the Windows KRNL386 program that has to be satisfied by whatever tries to start it in that second VM, otherwise KRNL386 just exits immediately. One cannot use WIN to start KRNL386 in the second VM. WIN does too much other than running KRNL386. It has to be something else that does the secret handshake and only tries to run KRNL386.

Trying to find a technological fault is what people did at the time. There were long threads on Usenet trying to ascribe things anecdotally to hypotheses that even then did not hold water.

It's sad to see looking for technological reasons happening here in the replies to your question, because that means that subsequent history has been forgotten. The technology turned out later in the decade never to have been the deciding issue, when things like the "Halloween documents" came to light. It was business agreements and marketing that sunk such products (albeit that one can argue that one can find traces of NeXT around even to this day), not technology. There were exclusionary pre-loading agreements with Microsoft, infighting inside IBM between two divisions, some utterly self-destructive litigiousness by some companies, and a whole bunch of Apple politics.

Correct. But you didn't see that the source was one level up in the directory tree from the untrustworthy binary blob?

* https://github.com/kaushikgopal/dotfiles/blob/master/bin/usb...

Presumably there is a sensible way to do this in go by calling an API and getting the original machine-readable data rather than shelling out to run an entire sub-process for a command-line command and parsing its human-readable (even JSON) output. Especially as it turns out that the command-line command itself runs another command-line command in its turn. StackExchange hints at looking to see what API the reporter tool under /System/Library/SystemProfiler actually queries.

That's because it is in ports rather than in base. (-:

* https://freshports.org/textproc/highlight/

* https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/textproc/hi...

* http://ports.su/textproc/highlight

* https://ports.macports.org/port/highlight/

You read wrongly. The 2013 amendment merely allowed customers to consent to disclosure electronically via the Internet. Before then, it had to be in writing. It didn't change 18 USC § 2710's explicit application only to a "video tape service provider", and that is how the law still reads today.

Viewers thought of them as that, and in popular culture that is what cue dots are remembered as today, especially by the Map Men, but technically that is not what cue dots were.

They were a way for the network to cue the regions for when to insert their regional content. It was not necessarily advertisements. And for programmes that were already regional, there was no need for cues from the network for when to run advertisements.

With digital playout, such things became no longer in-band.

The actual title is A cartoonist's review of AI art.

I don't understand the deduction, either.

But it seems that no BusyBox bug-fixer has spotted an easy-to-fix error that is stopping the BusyBox Bugzilla from working, and causing the hyperlink in that e-mail to lead to an error message that dumps out a glob of SQL and stack trace in black on red. It has a table named groups, and Bugzilla is attempting to use the table without quoting the MySQL keyword.

* https://github.com/bugzilla/bugzilla/commit/08679016bd83d2b1...

This bug was fixed in Bugzilla over a year ago. BusyBox's instance of Bugzilla is still exhibiting it today. It makes Buzilla unusable. Thus I do wonder at all of the automated messages to that mailing list with hyperlinks to stuff that does not work. Perhaps no-one is reading the mailing list as well as no-one using the bug tracker.

Clippy has done a complete volte face when it comes to memes, in 2025. This is because of the right-to-repair people.

"Clippy never wanted to harvest you, turn you into the product, and clandestinely copy your stuff into some language model. Clippy only wanted to help."

* https://consumerrights.wiki/w/Clippy_Campaign

The situation with one major ISP in the U.K. is so chronic that someone even maintains a WWW site tracking its patent inability to progress any further than where it was on World IPv6 Day:

* https://havevirginmediaenabledipv6yet.co.uk

"Clippy did not want to harvest you with AI copilots. Clippy only wanted to help."

Four other still-open discussions of this:

* https://news.ycombinator.com/item?id=45400422

* https://news.ycombinator.com/item?id=45379840

* https://news.ycombinator.com/item?id=45303437

* https://news.ycombinator.com/item?id=45426221

Those two are already balanced by Zutty and Rio. So let's have a look around at some of the emulators that make using the GPU a marketing point.

DarkTile (https://github.com/liamg/darktile) accepts TTF and OTF, so presumably if you can get your bitmap font of choice converted into those formats you are alright.

GhosTTY (https://github.com/ghostty-org/ghostty) gained proper bitmap font support just last month, the issues list says, but is reliant upon what FreeType and CoreText can handle. It has an open issue discussing those vis-a-vis bitmap fonts.

Trap2 (https://github.com/tale/trap2) likewise relies upon FreeType.

Contour (https://github.com/contour-terminal/contour) at least appears to have bitmap font support. Alacritty, WezTerm, and Kitty get a lot of mentions in the issues list.

All of the talk of ROMs on the WWW site makes me wonder where the YouTubers who have just this year bought Commodore stand on the ROM copyright issue, and whether indeed the ROM copyrights were included in what they bought.

Here's a collection for dang/tomhow, as this is (as it always has in the past) going to collect duplicates as everyone posts their own news source's version:

* https://news.ycombinator.com/item?id=45423880 (NPR before the shutdown)

* https://news.ycombinator.com/item?id=45434179 (The Guardian, politically biased headline)

* https://news.ycombinator.com/item?id=45434441 (Reuters)

* https://news.ycombinator.com/item?id=45434146 (BBC News)

For some insight on bitmap font support on the "We use the GPU!" terminal emulators, see https://news.ycombinator.com/item?id=45354014 .

As I noted in https://news.ycombinator.com/item?id=45433715 , this is likely down to following Kitty's lead and agreeing with Kovid Goyal's rationale.

The world of terminal emulators is diverging and has been for some time. There are the terminal emulators that are designed to emulate prior real terminals, with one codepoint per cell, support for original bitmap fonts, support for conventional TUI effects with MouseText/block/line drawing characters, and so forth. And there are are conversely the terminal emulators that are heading towards having an entire WWW browser/wordprocessor-like Document Object Model, with embedded images, reflowed proportionally-spaced document lines instead of a strict cell matrix, arbitrary font scaling, hyperlinks, and so forth.