Ask HN: Has anybody built search on top of Anna's Archive?
289 points by neonate 6d ago 146 comments
Ask HN: Is there any demand for Personal CV/Resume website?
6 points by usercvapp 1d ago 16 comments
The Xerox Alto, Smalltalk, and rewriting a running GUI (2017)
74 rbanffy 23 6/9/2025, 9:25:44 PM righto.com ↗
After sweating a bit, we found a perfect answer and I think it's still valid today. What you do with something as precious as an original Xerox Alto, is you find someone as good as kens to entrust it to.
Here's me describing the effort at the time: https://news.ycombinator.com/item?id=11930198.
Ken ended up pulling in a brilliant bunch of volunteers (loosely grouped around the Computer History Museum, IIRC), and they eventually got the Alto working. Not only that but they made an incredible series of videos and posts along the way, so the rest of us could follow along.
Once they'd gotten it working, we had a new challenge: what do you do with a working Alto? Again, the answer didn't take too long to figure out. What you do in such a case is you give it to the people who actually knew (and cared) enough to successfully resuscitate it.
Fixing the Ethernet Board from a Vintage Xerox Alto - https://news.ycombinator.com/item?id=15636863 - Nov 2017 (29 comments)
The Xerox Alto, Smalltalk, and Rewriting a Running GUI - https://news.ycombinator.com/item?id=15527726 - Oct 2017 (56 comments)
Inside the vintage Xerox Alto's display, a tiny lightbulb keeps it working - https://news.ycombinator.com/item?id=15472747 - Oct 2017 (50 comments)
Bitcoin mining on a vintage Xerox Alto: very slow at 1.5 hashes/second - https://news.ycombinator.com/item?id=14683326 - July 2017 (41 comments)
Improvements to the Xerox Alto Mandelbrot drop runtime from 1 hour to 9 minutes - https://news.ycombinator.com/item?id=14637763 - June 2017 (63 comments)
One-Hour Mandelbrot: Creating a Fractal on the Vintage Xerox Alto - https://news.ycombinator.com/item?id=14587915 - June 2017 (53 comments)
Xerox Alto Restoration – Ethernet pioneers/founders of 3Com visit [video] - https://news.ycombinator.com/item?id=13138977 - Dec 2016 (35 comments)
Restoring YC's Xerox Alto day 10: New boards, running programs, mouse problems - https://news.ycombinator.com/item?id=12714358 - Oct 2016 (13 comments)
Restoring YC's Xerox Alto day 9: tracing a crash through software and hardware - https://news.ycombinator.com/item?id=12685593 - Oct 2016 (27 comments)
Restoring YC's Xerox Alto day 8: it boots - https://news.ycombinator.com/item?id=12583554 - Sept 2016 (95 comments)
Restoring YC's Xerox Alto day 7: experiments with disk and Ethernet emulators - https://news.ycombinator.com/item?id=12557777 - Sept 2016 (14 comments)
YC's Xerox Alto restoration Part 7: disk exerciser trial [video] - https://news.ycombinator.com/item?id=12520795 - Sept 2016 (8 comments)
Restoring YC's Xerox Alto: how our boot disk was trashed with random data - https://news.ycombinator.com/item?id=12507361 - Sept 2016 (50 comments)
Restoring YC's Xerox Alto, Day 6: Fixed a chip, data read from disk - https://news.ycombinator.com/item?id=12482209 - Sept 2016 (31 comments)
Xerox Alto restoration day 5: Smoke and parity errors - https://news.ycombinator.com/item?id=12437018 - Sept 2016 (1 comment)
Xerox Alto Restoration Part 5 [video] - https://news.ycombinator.com/item?id=12427341 - Sept 2016 (13 comments)
Restoring Y Combinator's Xerox Alto, day 4: What's running on the system - https://news.ycombinator.com/item?id=12197591 - July 2016 (35 comments)
Restoring Y Combinator's Xerox Alto, day 3: Inside the disk drive - https://news.ycombinator.com/item?id=12072827 - July 2016 (21 comments)
Xerox Alto Restoration Part 3: drive ok and First boot attempt [video] - https://news.ycombinator.com/item?id=12035108 - July 2016 (20 comments)
Restoring Y Combinator's Xerox Alto, day 2: Repairing the display - https://news.ycombinator.com/item?id=12017354 - July 2016 (38 comments)
“Hello world” in the BCPL language on the Xerox Alto simulator - https://news.ycombinator.com/item?id=11987324 - June 2016 (59 comments)
Xerox Alto Restoration Part 2: Firing up the monitor [video] - https://news.ycombinator.com/item?id=11977215 - June 2016 (24 comments)
Restoring YC's Xerox Alto, day 1: Power supplies and disk interface - https://news.ycombinator.com/item?id=11954920 - June 2016 (23 comments)
Y Combinator's Xerox Alto: restoring the legendary 1970s GUI computer - https://news.ycombinator.com/item?id=11929396 - June 2016 (105 comments)
cf. https://squeak-dev.squeakfoundation.narkive.com/Rs0CrNOk/fon...
No comments yet
Modern software frameworks are so shockingly bad and uninteractive that we now have to rely another layer of bullshit with LLMs just to get us to be half as productive as these envs. : (
(okay okay REPL-based things are getting better, but still nowhere close to what Lisp even w/ Emacs can do.)
It would work if you had strict access control to each feature in a common code base. But Git hadn't been invented yet.
The other issue is performance. Compiled ST isn't particularly slow, but you lose the modifiability. Interpreted ST has a mixed profile - some features are slow, some are fast - but generally it was slow compared to C.
Today that doesn't matter so much, but it was a drawback at the time.
It's a seductive model and I totally get the appeal. But it's not quite as straightforwardly superior as it might appear to be.
Git isn't the first or oldest DVCS. Smalltalk actually had multiple DVCSs, including ENVY (VA/Cincom), which dates back to the mid 90s, and Monticello (Squeak/Pharo), which dates to the early 2000s--both of which predating git.
I don't know that you need 'strict access control' as proposed, but you do need coordination, and a source code repository is a way to manage coordination.
Erlang doesn't have a different mode for fixed vs loadable code, although you may need to write code differently in order to be able to hotload changes, and that could affect performance; some code naturally fits the idioms needed though.
I find it amazingly valuable to be able to change the program without having to lose the program state; but it requires different thinking, and it is easy to mess things up in exciting ways that are different than many other systems. It's amazing to fix a bug and deploy it in seconds into a live system with millions of active connections; it's also amazing when you try to fix a bug and break millions of active connections in seconds, but in a negative way, because now you and your users have to pay the costs of reestablishing all of those connections.
OTOH, the key issue is interchange of state and messages between versions, and that's an issue that comes up in almost all distributed systems that update without downtime, so most people have to deal with that issue anyway, just usually not within the much smaller scope of a single task.
I think it's generally better to aim for what the old C2 wiki called "Alternate-Hard-And-Soft-Layers": substrates that are less malleable with dynamic layers floating on top. We can do much better in terms of malleability than mainstream operating systems without descending into the complete insecurity and fragility of a classical Lisp Machine or Smalltalk environment.
Distributed version control and CI makes it way more tractable to work on even a small team IMO.
I would be very curious to see someone stream a "real" workflow using something like Pharoh or other smalltalk-like envs though. There's a bunch of short clips showing "beginner" demos but for such a visual system I would expect there to be more detailed presentations of the actual workflow.
Git is also much more confusing than Monticello.
That seems odd, they seem easy enough to map to each other?
> Git is also much more confusing than Monticello.
Not my experience. Uni had us use Smalltalk for a bunch of courses, and Monticello was universally hated (and people caused their to-be-expected number of messes with Git too, but still got on with that much better)
Not unless you treat every method-level modification as a separate commit.
Discussion then: https://news.ycombinator.com/item?id=15527726