I found that the simpler, early BASIC dialects were a good primer for assembly language. You had to create all the structure from jumps to numeric values. Goto and gosub mapped on to jump and call instructions.
Using labels in assembly was a step up from line numbers!
And they spectacularly fucked up the release. Doesn't compile, and they hurriedly edited stuff including comments calling the original DOS creator "brain-dead".
This was a fascinating read. It’s funny to think that 50 years ago western engineers would’ve been very interested in reverse engineering this unit, whereas nowadays it’s purely for historical interest.
It’s also interesting that its limitations were being felt fairly quickly and the cosmonauts were pushing for a replacement but that didn’t come until 2002. I suspect that’s a reflection of the financial situation of the Soviet space program in the 1970s and especially the 1980s, and then the dissolution of the Soviet Union.
I suspect that’s a reflection of the financial situation of the Soviet space program in the 1970s and especially the 1980s, and then the dissolution of the Soviet Union.
Probably something like that, but you have to keep in mind it was a weird economy, so the concept of a budget doesn't neatly translate.
Microsoft mangled arrays and code comments with ASCII extended characters into UTF-8 encoding, which makes building many of these files impossible without a lot of extra work. This was mistakenly attributed to Git.
The timestamps for each file are also not preserved, which is debatably a valid criticism of Git (original file timestamps can technically be preserved on an archive like this, but it requires a large amount of work to line up those times and the correct commit times programmatically).
Several Microsoft employees involved in this project appeared in the comments and offered to work directly with the author to correct the character encoding issues. One Microsoft employee indicated that historical timestamps could likely not be included due to Microsoft corporate policy around personally identifiable information.
Secure Scuttlebutt is (was?) a protocol for high-latency communication between occasionally-networked humans. Pro: https://scuttlebutt.nz/; con (not read in detail): https://derctuo.github.io/notes/secure-scuttlebutt.html. I think it was supposed to be able to spread messages over Bluetooth, assuming a sufficiently connected web of nodes between person A and person B. Public keys were identities, and were bound to devices; unfortunately people may have multiple devices, or change devices over time, so this was a hindrance.
IPFS was supposed to be the Interplanetary File System. I think that was just because whatever pieces of content you ask for, you also cache, as part of the design: you keep a copy on the near side of the small high-latency pipe. But that's mostly about file transfer, not interactivity.
UUCP was definitely made in a time where a latency of days for delivery of email or netnews was common.
In the early days of CGI, the Web was just one way people imagined interacting with applications; another way was email. RFC 3834 has some recommendations for people who are going to automate email responses. There used to be services you could email a URL to, and receive the web page back as an email.
Using ed (in my experience) involves looking up the screen, or up the roll of paper on your teletype, to see what the lines of your file were, and imagine what they are now, given the changes you've wrought to them since they were printed, and then turn them into what they should be. With Mars rovers you have a simulation that you issue your command to, before sending it off to Mars. With correspondence chess you might keep a physical chessboard for each game you have going, and/or send a form back and forth that keeps track of several moves.
People used to do computation at universities and businesses by writing programs at their desks, submitting them to be typed on punchcards, and receiving printouts some time later. They would "desk check" their programs before sending them in, because each compute job took a couple days to come back.
I mention all these because, in an extreme censorship environment, any local state (session history on paper, an app on a smartphone, an odd device) might not be good to have around. So usability may require reducing the total amount of state that a command carries. The current working directory at the time a command is run changes the meaning and outcome of the command; you may not remember that directory in a day or two. The vocabulary and syntax of command-line switches are easy to look up in online manuals - but are there offline manuals? I don't know if this avenue of inquiry helps you, but it's interesting to think about for a moment.
As long as you're using TCP (what SSH uses) or a similar protocol, you should be able to deal with a situation like that. You'd mainly need to ensure that your client and server are tuned to meet your needs. With TCP, every packet is considered important and if the receiver does not acknowledge receipt, the sender will resend.
I'm not talking a lot of latency, I'm talking snail-mail levels. Hours probably won't even be unusual, because hops will happen partly by sneakers net as people move around with their nodes. The concept is distributed burst radio for extreme censorship environments.
The point of the containers in the first place is to make as much as possible work offline, without the user having to be in the loop.
Oh that's interesting. I might suggest looking at implementations of IP Over Avian Carrier (IPoAC). And I do mean that seriously. The idea started as an April Fools RFC but some people have actually implemented it. Basically, just using a different physical layer.
Yeah, that's probably worth a look. Good suggestion. There's also delay-tolerant protocols for space and similar, but I don't know if any of them define an endpoint, as opposed to just a transport layer.
Indeed. I'd really suggest going for something based upon Internet Protocol, with any software that you need at endpoints to read and/or transmit. I might poke about at some ideas on the weekend (long holiday). What languages are you thinking to use?
Probably Rust, although I'm not married to it. I'm just at the planning stage right now, though.
One open question is if you can use a fairly standard transceiver like a Bluetooth chip, or if you need an SDR. Obviously they weren't designed with this in mind, by maybe there's a profile that's close enough.
Packets should have a few kilobytes of payload so you can fit a postquantum cryptographic artifact. Thankfully, even with a BCH code, it seems doable to fit that much in a 1-second burst in a standard amateur radio voice channel, for testing. (In actual clandestine use I'd expect you'd want to go as wide as the hardware can support)
As envisioned there would be someone operating a hub, which might have actual network access through some means, and on which the containers run. They would send out runners to collect traffic from busy public spaces which might serve as hubs for burst activity, and dump outgoing packets, all without giving up any locations.
Accounts with their own small container would be opened by sending in a public key, and then further communication would be by standard symmetric algorithm - except in testing, because that's an amateur radio no-no, so just signed cleartext. ID would be derived from signature fingerprint, as I have been thinking about it. I have a lightweight hash scheme in mind that would allow awarding of credit for retransmitting packets in a way that couldn't be cheated.
You'd want to have some ability to detect and move around jamming, or just other people's bursts. That's more hardware research, basically.
Encarta seems so quaint to me now, but it really was a well curated encyclopedia that had a designed charm to it.
I admit when I saw this headline I thought "but what about music" and for me, CD's lived long after the 90's due to small music players and cars having audio CD players but not yet being able to read MP3's. Decks with that feature and cars with that feature were not much later.... but we still burnt them to CDRs.
retrocomputing
Top
This magazine is not receiving updates (last activity 0 day(s) ago).