7 ms·

Old Unix programs running on modern computers

126 points by mfrw 3y ago

pjmlp 3y ago
> Research Unix Sixth Edition (V6) simulator. It is a port of the V6 kernel logic to Go.... I guess Go is a systems programming language after all.
- mseepgood 3y ago
  Who claims it isn't? Also, the word "systems" in "systems programming" doesn't stand for "operating systems".
  - guappa 3y ago
    In my experience go developers have no clue about signals, the concept that you shouldn't output colours when piped to a file, and a number of other things. It's all possible to do, but the practitioners don't know how.
  - pjmlp 3y ago
    Plenty of people on the Internet, as for the meaning of systems, that is your interpretation. In the 1980's writing a compiler and linker would be considered systems as in operating systems, as it would targeting bare metal workloads, all of which available in Go today, via the way it is bootstrapped, gccgo, TinyGo and TamaGO.
- signa11 3y ago
  was there _ever_ a doubt about that ?
  - anttiharju 3y ago
    It might be surprising to one to find a garbage collected language being used for an operating system or something like it
- anttiharju 3y ago
  You might be surprised to find that Talos os (linux distro for kubernetes) mostly uses Go: https://github.com/siderolabs/talos https://github.com/siderolabs/talos
  - pjmlp 3y ago
    Not really, I belong to those dreamers of systems programming languages with automatic memory management support. Even though I don't really like most of Go's design decisions, I appreciate it can perfectly fine being used as C replacement, regardless of that anti-GC/RC folks say about it.
    - anttiharju 3y ago
      What of Go's design decisions do you not like? Perhaps a somewhat off-topic question but I'm early in my career and have found Go to be a rather pleasant language to work with so I'm really curious. For example when I was working in a large microservice system, some of the java/typescript repos were a pain to work in because some of the developers had written crazy-looking oneliners. I mean it's possible to write difficult-to-read Go code as well, but I wasn't seeing it anywhere near as much.
      - amenghra 3y ago
        Not the GP, but the error handling mechanism for one. You are less likely to silently/accidentally drop an exception vs Go's tuple return values. Thankfully, there’s linters for Go to catch some common mistakes, still feels fragile imho.
        jacobr1 3y ago
        My experience has been the opposite. The idiomatic patterns is to have errors handled at the callsite, rather than bubble up. In java codebases I've worked on, you tend to have catch-everything parts of the code that are unable to address the specific problem, and mitigate it by restarting work, or just logging largely because they don't know what went wrong. Not that can't address the issue with exceptions more specifically (it happens all the time) but that often it is easier not to, and just to group all exceptions by their class and move on. In go codebases, In production go-codebases I've tended to see if/else logic for every case. This makes the code horrible to read IMHO, to get a general sense of what is happening, but make much more of specific logic explicit and directly handled.
tw1984 3y ago
where is the go port for pdp-11/v6 kernel?
- typical182 3y ago
  If I understand the question, I think that is rsc.io/unix/v6unix, which is at https://github.com/rsc/unix/tree/main/v6unix https://github.com/rsc/unix/tree/main/v6unix: "Research Unix Sixth Edition (v6) kernel written in Go and using rsc.io/unix/pdp11 to run user-mode code" For example, you can see the process struct definition starting here: https://github.com/rsc/unix/blob/main/v6unix/proc.go#L25-L67 https://github.com/rsc/unix/blob/main/v6unix/proc.go#L25-L67
  - tw1984 3y ago
    I was trying to figure out whether I can run golang on that unix environment.
Borg3 3y ago
Yeah, they usually compile fine. And if not, its not that hard to port them most of the time. Now try something reverse, like using modern language on old Unix. Good luck :)
- shortrounddev2 3y ago
  Idk about Unix but I sometimes see people port modern languages or programs to freedos
  - Borg3 3y ago
    Yeah, thats the achivement too. I guess they are stick to 32bit protected mode of DOS, using DOS extender.
- rileymat2 3y ago
  I have had some bad experiences with pre-99 dialects of C.
  - asveikau 3y ago
    I would say pre-c89 is a bigger difference.
- helpfulContrib 3y ago
  [dead]
cpach 3y ago
See also https://news.ycombinator.com/item?id=38056476 https://news.ycombinator.com/item?id=38056476
deleted 3y ago
[deleted]
hasmanean 3y ago
Well math is eternal. Maybe printf will be eternal. But no window library is universal and eternal. Perhaps we need eternal User interfaces and APIs to go along with them.
- kalleboo 3y ago
  If we decided on an eternal user interface in 1999 then what would we do? Forbid capacitive touch screen? If we decide on one now, are we forbidding any development into VR/AR?
  - dimitrios1 3y ago
    The terminal is a UI, but it didn't forbid the development of GUIs and IDEs.
- ThrowAway1922A 3y ago
  Xeyes, Xcalc, and the like are probably the closest we'll get to eternal GUI programs.
- nxobject 3y ago
  What was the slogan - "Win32 is the only stable ABI on Linux"?
- deleted 3y ago
  [deleted]
hashtag-til 3y ago
I look into all these old programs that work great after decades with lots of appreciation. At the same time, I look into this plethora of web-and-AI-stuff that needs rewrite almost every year... just a massive facepalm situation. We as a tech community really should go back to the basics when designing stuff, but it seems people just want to make on the highlights of the week for their startup to get some money to burn, and leave rubbish behind.
- deleted 3y ago
  [deleted]
- wmsmith 3y ago
  I think this speaks tremendous volumes to the legacy of these programs. Using this site, I fired up an old unix v6 on a simulated pdp11. I've never used a pdp 11 or unix v6. I was able, within a few seconds, navigate the system and find the 'moo' game in /usr/games/moo. In other words, I was functional with SECONDS. The staying-power of that kind of technology just blows my mind.
supportengineer 3y ago
Even when I got my first UNIX computer in 1992, it was fun to explore the bin directories and try running all the different programs found there. Even then there was old stuff whose purpose it was hard to discern.
- com 3y ago
  I remember typing “ss” at the shell (tcsh?!) in 1988 on a VAX running BSD 4.3+tahoe and being unable to exit the spreadsheet until someone opened the manpage or something and gave me some ideas. Probably made worse because I was on a monocoque adm3a and curses was … well, cursed … on that particular terminal type. Never did that again, ha ha.
mprovost 3y ago
I'm publishing a book which teaches Rust CLI programming by rewriting a BSD Unix utility in each chapter. I'm using the 4.4 release from 1992 but looking at the contemporary source from modern BSDs (Free/Open) they're totally recognisable and often basically unchanged. It's also amazing that some bugs persisted for 10-20 years before being fixed. I'm sure there are a few still to be discovered...
- nickdothutton 3y ago
  I have this crazy idea that you could rewrite finger/fingerd in rust, and perhaps jail it for extra peace of mind and revive the service with some new, modern, even dare-I-say futuristic features. Haven’t spent any time on it this year but you just reminded me.
  - mprovost 3y ago
    Not a crazy idea at all that sounds super fun! It would be much safer to write a server taking untrusted input from the network in Rust.
    - nickdothutton 3y ago
      If you have any good ideas for interesting and fun features let me know, should be enough contact info in profile here!
- superkuh 3y ago
  A hilarious juxtaposition. Generally Rust programs' source are forwards incompatible and a program written by a rust dev $now won't even be able to be compiled on a rustc from 3 months ago. This is not an exaggeration or hyperbole but something that happened to me multiple times in 2020-2022 before I stopped even attempting to use rust source code. Whereas a Perl program written today could be interpeted and executed on a perl interpeter from 1999.
  - mprovost 3y ago

126 points by mfrw 3y ago

> Research Unix Sixth Edition (V6) simulator. It is a port of the V6 kernel logic to Go.... I guess Go is a systems programming language after all.

mseepgood 3y ago
Who claims it isn't? Also, the word "systems" in "systems programming" doesn't stand for "operating systems".
- guappa 3y ago
  In my experience go developers have no clue about signals, the concept that you shouldn't output colours when piped to a file, and a number of other things. It's all possible to do, but the practitioners don't know how.
- pjmlp 3y ago
  Plenty of people on the Internet, as for the meaning of systems, that is your interpretation. In the 1980's writing a compiler and linker would be considered systems as in operating systems, as it would targeting bare metal workloads, all of which available in Go today, via the way it is bootstrapped, gccgo, TinyGo and TamaGO.
signa11 3y ago
was there _ever_ a doubt about that ?
- anttiharju 3y ago
  It might be surprising to one to find a garbage collected language being used for an operating system or something like it
anttiharju 3y ago
You might be surprised to find that Talos os (linux distro for kubernetes) mostly uses Go: https://github.com/siderolabs/talos https://github.com/siderolabs/talos
- pjmlp 3y ago
  Not really, I belong to those dreamers of systems programming languages with automatic memory management support. Even though I don't really like most of Go's design decisions, I appreciate it can perfectly fine being used as C replacement, regardless of that anti-GC/RC folks say about it.
  - anttiharju 3y ago
    What of Go's design decisions do you not like? Perhaps a somewhat off-topic question but I'm early in my career and have found Go to be a rather pleasant language to work with so I'm really curious. For example when I was working in a large microservice system, some of the java/typescript repos were a pain to work in because some of the developers had written crazy-looking oneliners. I mean it's possible to write difficult-to-read Go code as well, but I wasn't seeing it anywhere near as much.
    - amenghra 3y ago
      Not the GP, but the error handling mechanism for one. You are less likely to silently/accidentally drop an exception vs Go's tuple return values. Thankfully, there’s linters for Go to catch some common mistakes, still feels fragile imho.
      - jacobr1 3y ago
        My experience has been the opposite. The idiomatic patterns is to have errors handled at the callsite, rather than bubble up. In java codebases I've worked on, you tend to have catch-everything parts of the code that are unable to address the specific problem, and mitigate it by restarting work, or just logging largely because they don't know what went wrong. Not that can't address the issue with exceptions more specifically (it happens all the time) but that often it is easier not to, and just to group all exceptions by their class and move on. In go codebases, In production go-codebases I've tended to see if/else logic for every case. This makes the code horrible to read IMHO, to get a general sense of what is happening, but make much more of specific logic explicit and directly handled.

tw1984 3y ago

where is the go port for pdp-11/v6 kernel?

typical182 3y ago
If I understand the question, I think that is rsc.io/unix/v6unix, which is at https://github.com/rsc/unix/tree/main/v6unix https://github.com/rsc/unix/tree/main/v6unix: "Research Unix Sixth Edition (v6) kernel written in Go and using rsc.io/unix/pdp11 to run user-mode code" For example, you can see the process struct definition starting here: https://github.com/rsc/unix/blob/main/v6unix/proc.go#L25-L67 https://github.com/rsc/unix/blob/main/v6unix/proc.go#L25-L67
- tw1984 3y ago
  I was trying to figure out whether I can run golang on that unix environment.

Borg3 3y ago

Yeah, they usually compile fine. And if not, its not that hard to port them most of the time. Now try something reverse, like using modern language on old Unix. Good luck :)

shortrounddev2 3y ago
Idk about Unix but I sometimes see people port modern languages or programs to freedos
- Borg3 3y ago
  Yeah, thats the achivement too. I guess they are stick to 32bit protected mode of DOS, using DOS extender.
rileymat2 3y ago
I have had some bad experiences with pre-99 dialects of C.
- asveikau 3y ago
  I would say pre-c89 is a bigger difference.
helpfulContrib 3y ago
[dead]

cpach 3y ago

See also https://news.ycombinator.com/item?id=38056476 https://news.ycombinator.com/item?id=38056476

deleted 3y ago

[deleted]

hasmanean 3y ago

Well math is eternal. Maybe printf will be eternal. But no window library is universal and eternal. Perhaps we need eternal User interfaces and APIs to go along with them.

kalleboo 3y ago
If we decided on an eternal user interface in 1999 then what would we do? Forbid capacitive touch screen? If we decide on one now, are we forbidding any development into VR/AR?
- dimitrios1 3y ago
  The terminal is a UI, but it didn't forbid the development of GUIs and IDEs.
ThrowAway1922A 3y ago
Xeyes, Xcalc, and the like are probably the closest we'll get to eternal GUI programs.
nxobject 3y ago
What was the slogan - "Win32 is the only stable ABI on Linux"?
deleted 3y ago
[deleted]

hashtag-til 3y ago

I look into all these old programs that work great after decades with lots of appreciation. At the same time, I look into this plethora of web-and-AI-stuff that needs rewrite almost every year... just a massive facepalm situation. We as a tech community really should go back to the basics when designing stuff, but it seems people just want to make on the highlights of the week for their startup to get some money to burn, and leave rubbish behind.

deleted 3y ago
[deleted]
wmsmith 3y ago
I think this speaks tremendous volumes to the legacy of these programs. Using this site, I fired up an old unix v6 on a simulated pdp11. I've never used a pdp 11 or unix v6. I was able, within a few seconds, navigate the system and find the 'moo' game in /usr/games/moo. In other words, I was functional with SECONDS. The staying-power of that kind of technology just blows my mind.

supportengineer 3y ago

Even when I got my first UNIX computer in 1992, it was fun to explore the bin directories and try running all the different programs found there. Even then there was old stuff whose purpose it was hard to discern.

com 3y ago
I remember typing “ss” at the shell (tcsh?!) in 1988 on a VAX running BSD 4.3+tahoe and being unable to exit the spreadsheet until someone opened the manpage or something and gave me some ideas. Probably made worse because I was on a monocoque adm3a and curses was … well, cursed … on that particular terminal type. Never did that again, ha ha.

mprovost 3y ago

I'm publishing a book which teaches Rust CLI programming by rewriting a BSD Unix utility in each chapter. I'm using the 4.4 release from 1992 but looking at the contemporary source from modern BSDs (Free/Open) they're totally recognisable and often basically unchanged. It's also amazing that some bugs persisted for 10-20 years before being fixed. I'm sure there are a few still to be discovered...

nickdothutton 3y ago
I have this crazy idea that you could rewrite finger/fingerd in rust, and perhaps jail it for extra peace of mind and revive the service with some new, modern, even dare-I-say futuristic features. Haven’t spent any time on it this year but you just reminded me.
- mprovost 3y ago
  Not a crazy idea at all that sounds super fun! It would be much safer to write a server taking untrusted input from the network in Rust.
  - nickdothutton 3y ago
    If you have any good ideas for interesting and fun features let me know, should be enough contact info in profile here!
superkuh 3y ago
A hilarious juxtaposition. Generally Rust programs' source are forwards incompatible and a program written by a rust dev $now won't even be able to be compiled on a rustc from 3 months ago. This is not an exaggeration or hyperbole but something that happened to me multiple times in 2020-2022 before I stopped even attempting to use rust source code. Whereas a Perl program written today could be interpeted and executed on a perl interpeter from 1999.
- mprovost 3y ago