A Requiem for a Dying Operating System (1994)
Posted3 months agoActive3 months ago
user.eng.umd.eduTechstory
calmpositive
Debate
10/100
Operating SystemsRetrocomputingHistory of Technology
Key topics
Operating Systems
Retrocomputing
History of Technology
A humorous requiem for a dying operating system from 1994 is shared, sparking nostalgia and discussion about the evolution of technology.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
35m
Peak period
1
0-1h
Avg / period
1
Key moments
- 01Story posted
Sep 30, 2025 at 10:15 PM EDT
3 months ago
Step 01 - 02First comment
Sep 30, 2025 at 10:50 PM EDT
35m after posting
Step 02 - 03Peak activity
1 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 1, 2025 at 7:35 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45433619Type: storyLast synced: 11/20/2025, 5:11:42 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
A Requiem for a Dying Operating System (1994) - https://news.ycombinator.com/item?id=24372830 - Sept 2020 (276 comments)
To be fair, I discovered this article today, and I read it with passion.
Because, even though I'm 43yo, I'm too young to have worked professionally with other OSes than Windows and Linux. And it's super interesting for me to discover that astronomers had software solutions which were discarded and when they tried to protect what they had, they faced the "priesthood" mindset that is so well described in this article.
I'm not trying to troll, but I feel that this priesthood mindset is exactly the same as the one used when people destroy anyone who dares to criticize git. I think this quote from Douglas Adams and from that article fits perfectly: "their fundamental design flaws are completely hidden by their superficial design flaws".
"Unix and C however form a powerful deterrent to the average astronomer to write her or his own code (and the average astronomer's C is much, much worse than his Fortran used to be). The powers-that-be in the software world of course have always felt that "ordinary" users (astronomers in this case) should be using software and not writing it. The cynic might feel that since those same powers nearly all make their living by writing software, and get even more pay when they manage other programmers, then they have a vested interest in bringing about a state of affairs where the rest of us are reduced to mere supplicants, dependent on them for all our software needs. It is clear that Unix does not pose an insuperable barrier --- the ever-expanding armies of hackers out there are evidence enough that the barrier can be scaled given enough time and enthusiasm for the task. But hacking is not astronomy, and hackers are not astronomers, and it is astronomy and astronomers I worry about. We shouldn't have to scale the Unix barrier, and it is all the sadder because, since the advent of a VMS-based Starlink, ordinary astronomers have had something denied to most other scientists in this country --- readily accessible, reliable, user-friendly computing power that can be easily harnessed to a particular astronomical requirement. Maybe VMS does baby its users. Maybe we have paid more per Specmark so that we could use the Specmarks we had efficiently. But along with the rest of the world, we are now losing this nice friendly system. As with instrumentation and the National Observatories, we are having to teach our students how to fit their problems to facilities provided by others, whereas the UK reputation in astronomy was created by fitting the facilities to the problem."
On the flip side, my faded memories of VMS included regularly running ‘expunge’ to get rid of all the versioned files from edits when I wanted to stay under quota.