Well, I needed that beep-tastic AY sound chip! The 128K model is what the Speccy demo scene kinda gravitated towards, although there are some VERY impressive demos that run on a 48K machine - see https://www.youtube.com/watch?v=W7PX7YBac8k for what you can do with just a beeper!
When I said "stock" I really meant a basic 128K/+2/+3 machine and not one of the interesting Soviet/Eastern European clones with advanced capabilities that some portions of the demoscene adopted.
Holy CRAP. That is some ground-breaking stuff - One can only imagine what people would have made of it, had they seen something like that back in the Speccy's heydey.
This is it exactly! I wrote this back in 2019 on my "Back To The Floppy" post[1]:
I’ve been thinking a lot recently about what it is exactly about the Amiga that captures me in a way that no other computer ever did. Part of it is I think because the Amiga was the last system that was simple enough that one person could reasonably hold the entire machine in their head.
It was complex, true, but with enough studying and time you could know pretty much everything about every single bit of the Amiga’s memory space, workbench, the custom chips and so on. That’s what makes it so special and endearing.
That simply doesn’t exist on other platforms. I mean modern systems are amazing - and I’ve worked on some serious big-iron hardware in my time - but you could spend an entire lifetime now simply becoming an expert in one tiny piece of the whole system. Modern computers just don’t have the accessibility that the Amiga had, and it straddled the divide perfectly between being simple enough to know it and love it, yet powerful enough to do things you’d never dreamed possible.
For a perfect blend of the old & new, take a look at https://youtu.be/Lw4W9V57SKs?si=MAHCYx0X9luu6fwu&t=5719 - Razor 1911s 40-year retrospective, starting from the C64, and progressing through Amiga, DOS, and the modern PC scene. I've heard old sceners were literally in tears during the live competition with all the throwbacks, music morphing from C64 SID chiptune to Amiga MOD and onwards, inside references... It's pretty much a love letter to all the phases of the scene's life to date.
Hi! This hit HN after I had gone to bed so only picking up on it now. Thanks for finding that link and letting me know, I've updated the article with a note and your link.
One of the uncomfortable realities I've encountered being involved in the retro scene is that so many of the resources are slowly disappearing, either because the original authors age out of the scene or loose interest (or sadly, many are approaching that age where natural causes are taking them from us), old companies are long since defunct and resources slowly disappear into a legal quagmire or no-one ever thought to archive them in the first place.
I'd never want to jump in and steal your thunder, Mark - but that's partly why I'm building Code Like It's 198x over at https://code198x.com, and the sibling projects that form the rest of the 198x family, including emulators, assemblers and other build tools.
Too many of these resources are gone already, or require particular combinations of old operating systems and libraries to run at all. And in many cases, blog posts, articles, even books, are becoming hard to find. I decided to try to collate as much information as possible in one place.
Caveat: I've used AI extensively to do the research and writing, but I've attempted to cite all material from primary sources and every code sample gets tested not just in my own tooling but in existing third-party tooling too (just in case I made a mistake).
I mean, I'd love it if the wider community got behind my effort and helped me improve it directly, but the important thing is that the material is out there.
Strangely enough, that's one of the big draws for me. I'm "on the spectrum" and often find face-to-face socialisation and making new contacts very draining. I tend to prefer systems to people - although as time went on, I realised one of the things I really enjoy about DN42 is making the human contacts!
After getting started with the various "auto peering" systems, I've been making much more of an effort to find individual operators[1], and add myself to the peerfinder and hang out on IRC.
It really does feel like the "old internet" and while the technology and learning opportunities are great, it's the people that really make the network.
Thanks for sharing, your projects look really neat!
Reading your page I realize I know very little about networking at that level of the stack.
That might be a good thing to dig into as a way to work around my "AI dread" (or whatever we call the feeling of "what's the point working on that project when an LLM can make it faster" I've been feeling too much lately).
That was where I started, too. I was fine with VLANs, routing in general and so on from datacenter/DevOps/Sysadmin work, but BGP and how the wider internet fitted together beyond the basics was mostly beyond me.
DN42 is a great playground for this thing - as long as you're prepared to put the effort in, it's a very friendly and helpful community. It's fun to build things for the heck of it and there's a lot of weird and wonderful stuff being worked on there.
I have also uploaded it to my TNFS site[1], which you can also access through an emulated Speccy in a browser (or a real Spectrum if you have a Spectranet/Spectranext card fitted):
Press option 4 on the main menu when it loads for recent uploads.
It's really cool and very, very smooth. I wasn't quite sure what to categorise it as on my site, so I filed it under "demos" as I think it's a very impressive bit of code :)
Thanks for sharing!
-Mark
[1]=More details at https://tnfs.markround.com or on my "DevOps for the Sinclair Spectrum" series of articles which are linked from both sites.
"We have been made aware of a potential incident and are shutting down all issuance" seems to lean towards the latter and not simply a technical issue :(
You don't get kicked out of trusted roots for non-compliance, you get kicked out for continuing to knowingly issue non-compliant certs, failing to revoke non-compliant certs in a timely fashion once discovered, etc.
Pausing issuance immediately upon discovery of a compliance issue is the absolute correct response so as long as they do their followup appropriately there is absolutely zero risk of being distrusted.
You didn't actually respond to what the preceding comment argued. They were just pointing out the distinction between Symantec and WoSign and ordinary compliance events.
That's really not good. Fortunately I'm not using any short-lived certificates like the recently announced 6 day certs, so have some breathing room. Without further details, I'd imagine anyone with a short-lived cert is getting a bit sweaty right now.
Let's Encrypt has become one of those pieces of critical Internet infrastructure that just quietly hums away in the background, the fact that they've stopped ALL issuance is deeply concerning.
Stopping all issuance is an pretty standard response if a CA thinks what they are issuing might be non-compliant in any way. It's an action we're required to take. It's not necessarily a sign of a more dramatic failure mode or key compromise. That said, the impact is the same for as long as the downtime lasts so it is unfortunate and we're sorry for the disruption.
I don't think the premise behind short lived (six day) certificates being viable is that CA issuance never goes down. Sure, the runway is shorter, but not that short. Most down time is a few hours or less, which is not a problem for six day certificates that should be renewed every three days.
Short lived certificates are optional though, so if it's not worth it to you there are longer lifetime options.
Considering the open source nature of Letsencrypt, I wonder what the barriers/costs would be (theoretically) to a wealthy benefactor who wanted to duplicate its server side infrastructure and a core staffing level of persons, and fund a "parallel" equally trusted, alternative entity with a solid governing board. Same general idea how Acton funded the Signal foundation.
Somewhere that none of the physical infrastructure/hosting environment overlapped with existing Letsencrypt stuff so that the failure of one entity would have zero blast radius affecting the other.
I know there's a long and complicated process to go through to become a trusted root CA and get your CA public cert auto-installed in every OS and browser trust store. Indeed in the early days of letsencrypt I recall their root CA certs were signed by other older root CAs.
I understand there's probably a big thorny problem of duplicating the corporate process/policies on the human level that ensure compliance, but is the back-end software pipelining stuff to CT logs not also something that can be replicated? Or is it not part of the server side stuff which has been open sourced?
Our code for sending stuff to CT logs is fully open source. But that's the tiniest slice of our compliance regime -- the vast majority of it is things like audit logging certain events, preserving audit logs in specific ways for certain amounts of time, ensuring dual-controls on all systems, being both audited and penetration tested annually, maintaining firewalls and vulnerability scanning tools, etc.
It's absolutely possible to spin up another new CA; lots of folks have done so over the years. But having time, and money, and prior experience all help a lot.
They implied it used a GCP account. It would require to give Google personal information, a phone number, and automatic payment permission. And Google not disable your account because your spouse uploaded images for your child's doctor.
I just find it incredible that in 30+ years the industry hasn't adapted one bit to the brittle failure modes of certificates. I did some subcontract work with Verisign to deploy their CA infrastructure back in the early oughties and it felt like a solution was overdue way back then. I was at Google in the teensies when gmail broke due to expired SMTP certs. WAAAY overdue by then. Here we are, a decade later and it's still the same lol.
The number one thing for me would be to standardize methods to implement soft failures. Minimally in standard clients and libraries the ability to warn when certs are nearing expiration. Cert extensions to declare lifecycle expectations and possibly even warning endpoints for notification. Basically some way to empirically look at a valid cert and know something is wrong before it fails.
There are all sorts of potential privacy/security issues with any feature built in this area so it would have to be done carefully, but I think useful improvements could easily be made.
I'd like to see better support for networks that aren't connected to the broader internet, or moving away from X.509. Note that these are contradictory. X.509 was intentionally designed to support offline verification and has a lot of elaborate ceremony to support it (like all the rest of the OSI stack). The industry just doesn't, so we get the worst of both worlds.
The NSA needed some certs to expire, so you can send plain text. Just to test it. They already have access to the CA, but, if it works easier, why not. /s
When I said "stock" I really meant a basic 128K/+2/+3 machine and not one of the interesting Soviet/Eastern European clones with advanced capabilities that some portions of the demoscene adopted.
reply