lambdaone

Our capacity for psychological projection of our unconscious desires onto inanimate objects is quite amazing. Given what is possible in terms of projection onto things as random as Ouija boards, tealeaves or Tarot cards, I'm surprised this sort of thing isn't more common with LLMs that sound just like conscious beings.

The (final version of the) physical Phoenix computer still exists, but the disks are missing - see https://www.computermuseum.org.uk/fixed_pages/IBM3084.html

A backup was taken before shutdown: https://web.archive.org/web/20041115131602/http://www.cam.ac...

I would be surprised if someone, somewhere, didn't still have a copy of what would nowadays be considered to be an absurdly small amount of data. If they do, I wouldn't be surprised if they read HN.

BCPL was great. Cambridge Lisp was written in BCPL, and I found BCPL really pleasant to work in.

I think you might find that the Teletubbies have already solved this problem, in a variety of different configurations, including the rigid and curly antenna you mention above. The benefits of the circular and triangular configurations are as yet unclear to me, but I'm sure the Voice Trumpets and Sun Baby know what they're doing.

There would probably be a Universal Common Embedding used as an intermediate representation between people's individual private neural representations. Likely the distant descendant of our open-source neural models.

And machines would of course also use the Universal Common Embedding to communicate, as man and machine meld into a seamless distributed whole.

It all seems a little bit too inevitable for my liking at this point.

Or they are a hive mind, like Alastair Reynolds' Conjoiners.

I find this simultaneously fascinating and disturbing; once you have someone using this, they become a hitherto-impossible human-AI hybrid, where their mind is now a fusion between the two, completely unnoticed to the user.

I think the Internet warriors are trying to build their own entirely self-sufficient network independent of the state or commercial worlds, which is, as you say, tricky to do only with resources legally available to the general public. Armed forces have had these things nailed down pretty much since the invention of radio.

You could just about squeeze voice down LoRa with a really low-bandwidth codec, as really aggressive codecs can manage < 0.5 kbps. If you want to sacrifice voice quality but use standard codecs, the military MELPe codec has 600 bits/s as one of its standard modes.

The ISPs also have a system that runs without power so long as their batteries (and gensets) last. Typically 1 or 2 days without refuelling.

The real "resilience teams" are going to be at the telcos/ISPs, and they will have dark fibre between their networks and autonomous backup power in their data centres. They will be able to do IRC, VoIP telephony, email, etc. between their networks over statically routed point-to-point IP between their local networks even if BGP and the transit networks go down so they can "black start" the Internet. (Back in my ISP days, I remember reading about there being a private telephone network just for AS operators' NOCs to talk to one another quite independenty of the PSTN.)

For anything that takes even those out (eg. a "Big One" quake in California), you fall back to radio hams and autonomous radio links for the disaster services.

I didn't know about the chip having separate TX and RX pins. There must be a gap in the market for rooftop-to-rooftop LoRa transceivers that don't cost a fortune. Even using something like a 24 dB gain antenna would push range up by a factor of 10 relative to a simple 4 dB antenna, or get a substantial improvement in bandwidth/reliability at the same range. For an even simpler design, you could just put a 20 dB attenuator between the transmit port and the antenna, reducing the effective forward gain of 4 dB, while getting the full 24 dB in the opposite direction. Proper RF engineering details an exercise for the student etc.

I've just realised I've talked my way into the idea of creating per-city club-operated backbone networks based on something like 100 Mbit point-to-point Ethernet-over-microwave links. With tall buildings as hubs, you might actually be able to build a decent mesh, with WiFi, LoRa or both acting as access networks. You'd definitely want to throttle per-client bandwidth to prevent people from abusing your very limited long-range mesh bandwidth. None of this would be cheap; decent microwave links cost thousands, and you'd need backup solar and battery power for every part of the network.

I'd also consider thinking about using the "big ears, small mouth" technique to push up bandwidth; if a fixed link using a technology such as LoRa could transmit at a legal EIRP level, but coupled this with a really high gain parabolic dish (I'm thinking re-purposed satellite dishes) and low-noise amplifier at each end on the receive side, you could get substantially higher end-to-end Eb/No, and thus much higher bandwidth and range than would otherwise be legally possible. At first glance, the necessary hardware to do this looks quite doable, either by active RF switching between antennae, or the use of a hybrid/circulator to do the necessary duplexing. I'd be interested to see if anyone has already built, or even manufactures, something like this, and what the practical and regulatory barriers are to implementation.

Mesh radio bandwidth is pretty poor. Firstly, you have to compete with many interferers (albeit this might get better if the power goes down), including other LoRa radios, but more to the point, long-distance connections consume bandwidth and aquire delay and delay variation at every intermediate hop. It might be reasonable to use it for text messaging, but with per-hop bandwidth ranging from 0.3 kbps to 27 kbps, which will get divided down further over shared multi-hop links it will be impractical to use it for anything else except perhaps very-low-bandwidth telephony over short distances or visiting minimalist text-only websites.

It might make more sense if augmented by fixed multi-megabit point-to-point microwave radio links to act as a backbone, with LoRa only functioning as an access network.

I'd be interested to hear what experiences people have had with doing this for real.

It's substantially harder than linear programming: it's equivalent to SAT, whereas linear programming is merely polynomial-time (and in practice weakly polynomial-time with current algorithms).

HyperCard was undoubtedly the inspiration for Visual Basic, which for quite some time dominated the bespoke UI industry in the same way web frameworks do today.

It allows the Mac to use far less RAM to display overlapping windows, and doesn't require any extra hardware. Individual regions are refreshed independently of the rest of the screen, with occlusion, updates, and clipping managed automatically,

They don't create contiguous surfaces, and GPUs are optimized to deal with sets of triangles that share vertices (a vertex typically being shared by four to six triangles), rather than not shared at all as with this.

"Watertight" is a actially a stronger criterion, which requires not only a contigous surface, but one which encloses a volume without any gaps, but "not watertight" suffices for this.

"Overly strict" only leads to ossification if the designers of the system forget to build extensibility into their system design from the beginning.

Postel's law is absolutely great if you want to make new things and get them going in a hurry, and I think it was one of the major reasons the TCP/IP stack beat the ISO model. But as you say, it's a disaster if you want to build large robust systems for the long term.

Not really, unless you have thousands of routes to manage across large numbers of gateways. Otherwise, running BGP inside your homelab is just a learning tool.

In the "real world", techically competent people understand decibels just fine.

But this is not arcane knowledge only known by a priesthood. Since you are clearly confused about what a decibel is and how and why it is used, you can read

https://en.wikipedia.org/wiki/Decibel

and all will be revealed.

It's a bit like hating numbers, and saying "What do you mean by 'three'; what is it - three volts, three amps, three metres? Clearly 'three' is meaningless, and we should stop using it and all the other numbers besides."

decibels are simply a dimensionless ratio, used as a multiplier for some known value of some known quantity.

In every context where decibels are used, either the unit they qualify is explicitly specified, or the unit is implicity known from the context. For instance, in the case of loudness of noise to human ears in air, the unit can be taken to be dBA (in all but rare cases which will be specified) measured with an appropriate A-weighted sensor, relative to the standard reference power level.

And similar (but different) principles apply to every other thing measured in dB; either theres an implicit convention, or the 0 dB point and measurement basis are specified.

People who assume that everyone is an idiot but themselves are rarely correct.

I look forward to the author discovering about (for example) the measurement of light, or colorimetry, and the many and various subtleties involved. The apparent excessive complexity is necessary, not invented to create confusion.

Why should floppy disks be a problem? Even if they are fantastically out of date, if they can be maintained as a niche legacy technology, they're not a problem. They won't suddenly stop working, it will just slowly get more and more expensive to get the parts. Supply chains are magic - at the right price, someone will always be willing to make more floppies or drives. Of course that price might be $500 per floppy and $50,000 per drive...

Even though it might seem unlikely, you absolutely can't eliminate the possibility of planes falling out of the air unless you have thoroughly audited and tested all their systems in advance. Not having planes in the air at the exact moment of rollover - just in case - might be a good idea too. Similarly financial markets and other key infrastructure.

13 years is plenty of time to make a start on all of this, and will allow the costs to be spread over that time period without undue hurry. It's also long enough that it will be possible for much software to be allowed to reach end-of-life without being audited, while applying rigorous testing to new software. Procrastination, though, is not a good option.

It means 'anywhere between being bricked and no problem at all, and we can't give you any idea of how severe or how likely any of those possiblities are'. The only way you can really know is to thorougly audit your system and/or test it. Preferably both.

Unironically giving that prime number routine as an example of clever code is not a great look. So bad on so many levels.

Most users don't know what io_uring is, nor would they have read any of thosee articles. They are not HN readers with low-level understanding of operating systems workingm and don't even remotely have the knowledge of how any of these technologies work, nor do they have the time to get it. With a very few exceptions, users have to rely entirely on software vendors and service providers to do this for them, and trust they know what they're doing.

A side-note: I have a friend who is an electronics genius who managed to construct a production system that combined a multi-kilowatt electric arc lamp and a CCD array. Microvolts of CCD signal at megahertz of bandwidth mixed with hundreds of watts of RFI all in the same chassis. Oh, and of course lots of low-jitter digital timing and sequencing electronics and wideband ADCs.

It all worked perfectly. He used every trick in the book, and some new ones he invented from scratch, to implement it - I've never seen anything like it, before or since.

Real environments have both mechanical bouncing and unavoidable EMI spikes, even when you have done your best to eliminate EMI; particularly when you're dealing with switches, which are typically on the end of long wires which are effectively antennae. Source: actual experience with crappy real-world systems.