JdeBP

rswail said ASCII, which definitely pre-dated Unix, not the other way around. And there was some to and fro about the equivalence of LineFeed and NewLine in the 1960s.

The people in the FediVerse discussions have also looked at the book contents.

* https://mastodonapp.uk/@JdeBP/116788511790947929

* https://hachyderm.io/@ariels/116788498255660876

That's a generalization from 1 book. I went and looked at ten or so. This is not actually the case. There's something more complex going on.

* https://mastodonapp.uk/@JdeBP/116788511790947929

You can read at least the first chapter or so if you do the Amazon search. I did, and made some discoveries.

* https://mastodonapp.uk/@JdeBP/116788436560592117

Indeed. The U.S.A. is currently well above the U.K. in the APNIC statistics hyperlinked-to by the headlined article.

* https://stats.labs.apnic.net/ipv6

Just to add to the 'but the ISPs do not' anecdotes, it has been six months since someone last commented so it is probably time to mention this again on Hacker News:

* https://havevirginmediaenabledipv6yet.co.uk/

A major ISP in the U.K., that said in a public statement on World IPv6 Day in 2011 that

> As well as our core and access networks being capable of supporting IPv6, we're rigorously testing our entire network to ensure that all customers have a smooth and simple transition when the time comes to flick the switch and turn IPv6 on. We're really pleased with how our tests are advancing and are happy to say that by the end of 2012, we'll be able to fully support customers looking to switch to IPv6.

has not managed to actually flick that switch in 15 years.

* https://ispreview.co.uk/story/2011/06/08/uk-isp-fluidata-hai...

In Unix Seventh Edition, ls and others read directory entries with fread() and parsed the struct direct themselves in application-mode code. The C library and application mode matter, here.

On the gripping hand, there is no strncpy in the Spinellis 7th Edition source code; 4.2BSD was using strncpy() inside readdir() in 1982, though.

A more accurate re-phrased version of the original is that they are the biggest mistake in the C language.

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

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

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

No. The poster didn't communicate the bug per the posted instructions at https://github.com/lobsters/lobsters/blob/main/SECURITY.md ; the poster actually exploited the flaw to scrape personal data of users which xe then threatened to post; and the company being promoted was nothing to do with Hacker News at all, but was a company that sells software security stuff, with which which two lobste.rs accounts were connected.

No. In such organizations the money goes towards all of the usual things such as tax, building rental, utilities, and licences, as well as employee salaries and social security contributions.

BSI Group, for example, paid 26.1% tax (25% corporation tax plus some other stuff) according to its 2025 financial statement.

In my direct experience, the people who write the standard texts get a room to sit in, power for laptops, a whiteboard, and tea/coffee and biscuits, a few days per year.

The headlined article is a press release. The actual paper, with the explanation, is hyperlinked in a box on the right.

Also: https://news.ycombinator.com/item?id=48594724

No. As I said, that's really a secondary niggle with the paper itself misrepresenting its reference, which as you can see already provides patches to paper over such stuff, as through the problem with XNU were redaction, which it isn't per that reference.

The primary reason not to use XNU is what the paper goes into in detail; which is the architecture of XNU simply getting in the way, just as the architecture of NetBSD would for the same reasons. If XNU being incomplete were the primary problem, NetBSD, a complete operating system that supports loadable kernel modules and provides a coherent development toolchain out of the box, would be the answer. But it is not.

The design of the font is quite interesting, but it's not universally applicable for text art work of course. Making ordinary punctuation and alphanumeric characters have the same connection properties as the line drawing and box characters comes at the expense of distorting text art that relies on conventional glyph shapes to make sub-cell slopes and whatnot work. There's stuff out there that relies on (say) the symmetry of opening and closing single quotes or the visual similarity of the dollar symbol and the capital letter S.

You might enjoy https://int10h.org/oldschool-pc-fonts/ .

The paper's reference to https://github.com/blacktop/darwin-xnu-build does not support the statement made by the paper. It's not redaction or obfuscation that makes building XNU difficult. It's having the right toolchain; modifying makefiles and code to accommodate a slightly different toolchain; and needing a load of extra stuff that isn't pre-supplied with XNU. A lot of the patches and issues there are about compiler differences, language standard differences, and plain missing stuff.

This is a secondary niggle in the larger scheme of things, though. Not using something like XNU in the first place is the way, for the reasons that the paper goes into. (Whilst 'of course it runs NetBSD' applies to the M1, one wouldn't use NetBSD for this for the same reasons that one wouldn't use XNU.) People experienced in this sort of thing likely nodded along at decisions like coöperative rather than preëmptive multitasking.

I wonder whether they considered the Watanabe shell rather than the Debian Almquist shell. They picked vim instead of nvi2, after all.

Rusted Cu surely makes that, rather, verdigrURL. (-:

The terminal firmware is VT132 from TheHighNibble. It claims to support more than a VT100, but from looking at the reference doco that is not very much actually added (a handful of SCO and XTerm control sequences, and colour), and nowhere near what one had with the later DEC VT models.

* https://thehighnibble.com/vt132/

* https://thehighnibble.com/vt132/operation/vt100/programmer/

That's not really an explanation of why the people who have made synthesizable 8086/8086 processors haven't done the same thing for the 8087, because modern FPGAs aren't limited by the cutting edge of 1980 technology. (-:

My educated guess is that primarily simply no-one has needed this, and secondarily it's hard. They're running softwares that can do all of their floating point in software anyway and they just don't need an 8087 on an FPGA. And floating point on an FPGA uses a lot of area, if one is taking the easy route of just emulating the external behaviour rather than the much harder task of emulating the clever microarchitecture that reduces it all to just 1 adder.

And largely irrelevant if the goal is synthesizing something that can be put onto an FPGA to be a workalike for the 8087. It's almost never about synthesizing the exact original hardware to be fabricated. See CPU86 and Zet, for examples:

* https://github.com/nsauzede/cpu86/wiki

* https://github.com/marmolejo/zet

The adder is not clocked. You can see from the diagrams that there are no clock inputs. The clock cycles comment is more an expression of the length of time that it takes before all of the carry rippling and whatnot settles down.

It is interesting that over the years people have produced synthesizable RTL HDL for the 8086/8088 and later, with varying degrees of fidelity, but no-one seems to have produced similar for the 8087.

Yes there should, and the maximum size of what fits into a 512-octet DNS/UDP query packet, less header and EDNS0 and whatnot, is going to be that limit, ultimately. Because SMTP-based Internet MTSes that do not look up MX resource record sets in the DNS, and do not begin at DNS/UDP, do not currently exist. (-:

Even if they magically all switched to starting at DNS/TCP, that is still only 64KiB less header and EDNS0 and whatnot. And in that case one also has to allow space for sending the actual resource record set back in the response, DNS/TCP not having DNS/UDP's luxury of truncation, so it's not even as large as that.

Actually, there are a number of full-screen editors that pre-dated vi. They were for mainframe operating systems, or were confined to some university or other, or were commercial products for something like CP/M made by some tiny company somewhere, and are largely forgotten; with the last magtapes or floppy discs that had copies of them long since thrown away. Unix and vi, and what escaped UCB, got remembered. But there was other stuff around.

I tend to go for keyboards that don't need all of that messing about with the Fn key, too.

By the way: It's a lot more than 100 keys. People tend to accept that because they have what is called a '105-key' keyboard that it actually has 105 keys. One of my '105-key' keyboards has 124 physical keys. For approaching a decade now, I've wanted a 127-key keyboard from Brazil. Formally, that's a '107-key' keyboard.

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

I agree about the special keys. There are so many HID usages on the Consumer page for keyboards covering so many things, from application launchers to extra editing functions, and it is absurd how often almost none of them are used in favour of vendor-private usage numbers that then require vendor-specific software support.

I'm surprised that this has not triggered all of the reminiscences of sitting running mailq at intervals for hours to watch mail that hasn't even left the local sending machine yet.

Realistically, the length of the domain part is likely ultimately constrained by how large a domain name can fit into a DNS/UDP query packet (alongside EDNS0).

Even that's not the true length limit of a label in the Domain Name System. (RFC 1034 § 3, for the curious.) So someone is likely going to be fixing that, years down the line. Then of course there's the fact, as called out earlier, that there can be more than 2 labels in a domain name.

These seem related:

* https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)

* https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)

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

* https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)

> I do not use a graphics driver.

Yes you do. It's the one that your in-kernel terminal emulator talks to in order to splat its bitmap fonts onto the screen. It is whatever wsdisplay has attached to, which can be one of a range of things from genfb through voodoofb and machfb to radeonfb. There was even a vesafb about 20 years ago.