But I wonder from a reliability (or lack of cascading failures) point of view whether synchronous islands interconnected with DC interconnects is more robust than a large synchronous network?
6,422 karma · joined June 21, 2012
Server proudly running Cern httpd 3.0 since 1994 on Sun Sparc hardware. May be a little slow.
But I wonder from a reliability (or lack of cascading failures) point of view whether synchronous islands interconnected with DC interconnects is more robust than a large synchronous network?
I was 14 or 15 at the time. The first summer I wrote a whole load of games, mostly in Forth, but sometimes Forth just wasn't fast enough. I got a copy of "Mastering Machine Code on Your ZX81", and learned Z80 machine code. If there was an assembler available, I didn't have it, so this was all hand-assembled. Getting jumps right was a total pain, as was debugging. Generally, it either worked first time, or you started from scratch again. Usually I got there in the end.
I sold those games through a ad in "Your Computer" magazine, and earned back the price of the computer several times. But recording and shipping tapes one at a time got tedious really fast, so I didn't take that any further.
My Ace got modified quite a bit over the next couple of years. An extra 16KB RAM pack was an early addition, taking it to a whopping 19KB. Because Forth was so compact, I never filled that up.
My mother worked for Chubb cash dispensers (ATMs for Americans) at the time, and at some point they scrapped a lot of equipment. She tipped me off, and we went round there one evening and liberated lots of cash dispenser pieces from a skip. Amongst these were several numeric keypads with lovely mechanical keys. I dismantled several keypads to take out all the individual keys and made a proper keyboard to replace the original dead rubber monstrosity.
At school, I was taking O-level Technology, and you had to do a final year project. I'd seen articles in "Your Computer" about competitions where a micro-mouse robot would have to find its way through a maze. That seemed like a cool idea to me, so I decided to make one, despite not really having much idea how. I hadn't done any digital electronics at that time, but my friend Johnny Tombs (who later went on to be a Professor of Electronic Engineering) had decided to make a parallel I/O port for his ZX Spectrum using TTL logic for his Technology project. I'm not sure where Johnny learned about digital electronics, but he knew what he was doing, and designed a nice elegant circuit board and etched it at home. The Ace had the same Z80A CPU as the Spectrum, so I figured his design could be adapted. After a lot of pleading, he gave my his design and spent some time explaining to me how it worked and loaned me his copy of Watford Electronics catalog. A couple of weeks later all the components arrived, and I spent a busy few days soldering up my modified I/O port on veroboard. Compared to Johnny's professional looking version, mine looked like a mess of wires and chips, but it worked!
So then when it wasn't playing games, my Ace rode about on the top of a fairly flaky micromouse, made in the school metalwork shop out of aluminium sheet, some lego motors, and some light sensors to detect maze walls, exploring mazes. It didn't win any prizes but it did get me an A in O-level Technology.
My school was throwing out an old teletype, so I scavenged that. Then I modified the parallel I/O port to output +/- 12V on one pin, and wrote software to bit-bang RS232 at 110 baud. Back before the Internet, just finding the specs for RS232 was not so simple - our local library was a bit limited in that way - but I got there in the end. A lot of guesswork and trial and error. I don't think anyone made a printer for the Ace, so I may have had the only one. Being able to print code listings really helped, even though the teleprinter only printed capital letters.
Somewhere over the years, with my parents moving house multiple times, the Ace disappeared. Many years later, I found one on Ebay, and still have it. But somehow I never fell back in love with it - it just wasn't as good as I remembered my rather non-stock one being at that formative time in my life.
At the same time, I can't context-switch like I used to. Once I get into the zone, no problem, but interruptions affect me much more than when I was 20 (or even 40). I can almost feel the tape changer in the back of my head switching tapes and slowly streaming the new context into RAM (likely because all the staging disks have been full for years).
As for long coding sessions - I relish them when I get the chance, which isn't as often as I'd like. Once the tapes have finished loading and I'm in the zone, I can stay there half the night. So that hasn't changed with age.
https://www.theregister.com/2022/12/23/doe_fusion_ai/
https://openai.com/index/strengthening-americas-ai-leadershi...
https://dreamsongs.com/RiseOfWorseIsBetter.html
Gabriel was right in 1989, and he's right today, though sometimes the deciding factor is performance (e.g. vs security) rather than implementation simplicity.
https://tfl.gov.uk/campaign/tube-improvements/what-we-are-do...
My route home is via commuter rail so I don't have that luxury. I wouldn't possible know what it is like to wake up after a few beers and find myself on the last train of the night, four stations past my stop, but rumour has it that the night bus network is pretty good at getting me^H^Hpeople home, even if the wait can be cold, so long as you've not actually left London. Or Uber.
https://sucs.org/~cmckenna/maps/busspider/2012-14/west-londo...
But if you don't wake up til the end of the line, it's probably pretty much like in Japan, except less clean.
int array[10];
*(array+1) = 56;
array[2] = 4;
3[array] = 27;
The first two are obvious, but the third is also legal. It works because array indexing is just sugar for pointer arithmetic, so array[2]=4 is identical in meaning to *(array+2)=4. Therefore 3[array]=27 is identical to *(3+array)=27 and so is legal. But just because you can doesn't mean you should.If I recall correctly, the main workstation lab was B10A, where I spent a lot of time. Then there was a narrow room, B09 I think, that had mission control on the right hand side with a machine room behind it, and a second machine room on the left side. Can't remember which machine room the Pyramid was in.
And yes, Phil is still around.
Peter was also responsible for the UK using .uk instead of the ISO country code "gb" which it should have been according to "the rules". But Peter insisted on .uk, as the official name of the country was "The United Kingdom of Great Britain and Northern Ireland", and he thought GB was not properly inclusive of Northern Ireland. It took until 2021 for UK to replace GB on car number plates (and stickers for travelling abroad).
In the article Peter talks about the temporary import license for the original ARPAnet equipment. The delayed VAT and duty bill for this gear prevented anyone else taking over the UK internet in the early days because the bill would have then become due. But he didn't mention that eventually if the original ARPAnet equipment was ever scrapped, the bill would also become due.
When I was first at UCL in the mid 1980s until well into the 90s, all that equipment was stored disused in the mens toilets in the basement. Eventually Peter decided someone had to do something about it, but he couldn't afford the budget to ship all this gear back to the US. Peter always seemed to delight in finding loopholes, so he pulled some strings. Peter was always very well connected - UCL even ran the .int and nato.int domains for a long time. So, at some point someone from UCL drove a truck full of obsolete ARPAnet gear to some American Air Force base in East Anglia that was technically US territory. Someone from the US air force gave them a receipt, and the gear was officially exported. And there it was left, in the US Air Force garbage. Shame it didn't end up in a museum, but that would have required paying the VAT bill.