Re: Documentation
For a long time I had a printout of the original source code, which was properly commented. If I ever find it it'll go to the Centre for Computing History to be reunited with the prototype.
52 publicly visible posts • joined 21 Sep 2018
There's a little-known piece of physics that says that above about 320 km/h the slipstream picks up the ballast, so you have to have concrete slab track, which is more expensive (though the cost of ballast has gone up a lot recently). Watch for the latest review of HS2 to reduce the speed to about 300 km/h (which is plenty for London to Birmingham anyway).
Trouble is, the rail industry likes stuff to go on working for several decades, preferably centuries, partly because the process of choosing a replacement, verifying it meets all the safety etc requirements, installing, and then switching over is so disruptive and expensive.
Whereas the IT industry considers stuff should be stripped out and replaced by the latest whizzy thing (with its own new set of bugs) several times a year.
Quite. In the 1980s we had a good business making a network that linked RS232s together. As one customer said, "we have N devices with serial ports and used to have N-squared problems linking any to any, now we just have N problems linking each one to the network." Later we made nodes with parallel interfaces and file-sharing software.
While the TCP/IP folks went connectionless to avoid having to keep information on flows, we went connection-oriented to avoid having to keep information on all the reachable addresses.
Back in the 1980s when we made what must have been one of the world's first remote file access systems we had a similar problem -- fetching stuff from the server took about the same time as from a local floppy, but without any indication that anything was happening. So we got the PC's speaker to produce click-clunk sounds whenever a network drive was being accessed.
It's not unknown for spam senders to spoof the "from"" address, in the same way that phone spammers spoof the calling number. For a while I got a lot of spam that apparently came from the person that preceded me in IANA's list of private enterprise numbers (a public list with e-mail addresses in clear).
With implanted devices such as pacemakers it's mostly magnetic fields that are the problem, because they're likely to put it into the engineering mode that's used when you have a check-up. As well as stopping it performing its usual function I suspect that drains the battery. And no, they're not rechargeable. You're told to keep at least 2 ft away from an induction hob (in a kitchen), and this system sound like a room-sized induction hob.
Back when computers were newer there was an exhibition (I think it was at the Science Museum) with an exhibit where you could type in a sentence and it would reply with something one of the earlier visitors had input. So it had to avoid parroting rude words, and had a file containing the forbidden words, in clear. Some enterprising person managed to get it to list the file.
There's a light switch in our garage like that, it's got a neon indicator so you can find it in the dark. The indicator goes off when you switch the lights on, probably the idea is that when the lights are on you can see where the switch is anyway. Of course, if the lights and the neon are both off you know there's a power cut.
The problem with Algol68 was that Aad van Wijngaarden treated it as an academic exercise, valuing elegance over practicality. He regarded Algol68-R as unclean, it having compromised on some of the more esoteric features to make it actually usable for real work.
People who used it told me one great feature was that most bugs were detected at compile time, i.e. once you got your program to compile it usually worked (unlike C).
"We truly believe that this transaction is good for all stakeholders because it allows PIR to invest in the registry and expand services for the benefit of all registrants"
If you own a domain name, you need to know it's globally unique. And from a registry that's all you need. So what exactly are these new "services"?
The idea was to give UK companies a head start in developing applications that use the new services 5G provides. Problems include:
- they wanted the testbeds to be built using off-the-shelf equipment (which by definition isn't the latest technology) on the assumption it's cheaper
- there are precious few applications that can be done with the current (3GPP Release 15) version of 5G that can't be done with 4G
- the way the calls for proposals are structured locks out micro-enterprises with really innovative (and cheaper and less power-hungry) technology which could have got the UK into a position where it wouldn't be dependent on China and the US for the equipment that implements the really interesting features of 5G
ITU has a nice triangular diagram that shows three main use cases for 5G: faster Internet, IoT, and applications (remote surgery is often cited) where latency matters. The first of these is LTE with a few tweaks, and is the only one being delivered, or even really supported by the 3GPP standards, as of now.
The main problem for IoT is battery life in devices that are so cheap you can have lots of them in different places; IPv6 over LTE is the problem there, not the solution, because of the amount of data to be transmitted to upload a couple of bytes-worth of information.
Critical applications that need low latency need something more than just a bit less contention for a best-effort service, and no, slicing is not a viable way of achieving it.