Product Launch
anonymous
156 points
75 comments
Posted6d agoActive23h ago
Unix v4 Live
unixv4.devlaunchedweb_appdevelopers
Key Features
interactive terminalUnix v4 emulationhistorical Unix experience
Tech Stack
JavaScript
Key Features
Tech Stack
> By using this service, you acknowledge that terminal sessions may be logged for educational and debugging purposes. No personal data is collected beyond your IP address.
Is this all open source and is the code available? So that we know where the data is truly going?
Hard to trust it if it isn't fully OSS.
This is a cool demo though.
It's an emulated PDP-11, could you elaborate on the threat model here?
I get that companies are being gross about logging everything online, but come on. It's okay to have fun.
Who in their right mind is using this for anything other than curiosity's sake?
Maybe you'd get too many retirees ...
Now you just need
You aren’t getting downvoted enough.
Session Error
Rate limit exceeded: 10 per 1 minuteGotta stick the "This product includes software developed or owned by Caldera International, Inc." notice on it though.
But the license they provided (http://www.lemis.com/grog/UNIX/ancient-source-all.pdf) explicitly names versions 1, 2, 3, 4, 5, 6, and 7 of UNIX for the 16-bit PDP-11. Yes, these versions originated at AT&T (Bell Labs) but are distinct legally from SysIII and SysV UNIX, also from AT&T, which are explicitly not covered by the Caldera license.
Yeah, everyone knows Unix is owned by SCO, just like C++, Linux, and the look on your face, which is priceless.
(So help me, SCO claimed to own C++ at one point:
https://lwn.net/Articles/39227/
> C++ is one of the properties that SCO owns today and we frequently are approached by customers who wish to license C++ from us and we do charge for that. Those arrangements are done on a case-by-case basis with each customer and are not disclosed publicly. C++ licensing is currently part of SCO's SCOsource licensing program.
Maybe they claimed to own an implementation of C++ but it would be typical of them to claim to own the moon and sun and be sublicensing the stars to God.)
In the sense that the company I work for would be financially harmed if copyright infringement of software was freely allowed. I benefit from the ability of people being able to sell rights to use software. It's one thing to digitize it in order to archive it, it's another thing to allow people to freely use it without licensing it.
Because the media was no longer in the rights holder's possession. This is a dangerous line of reasoning where someone can steal a copyrighted work and then be allowed to profit off of it because the artist has no way to do so.
Being able to see a long lost UNIX version is interesting and I could imagine it being worth paying to see it or play with it similar to how people pay money to see things at a museum.
But your line of reasoning says that since the artist is unable to make money from the print, then there is nothing wrong with someone else doing so as the artist isn't missing out on any profit since they have no way to sell prints.
Also please note that I have not said that the copyright is not valid. However, a case for fair use is not unfounded here.
Hardline stances usually cause more harm than good anyhow. I remember collecting Apple II gear in the late 1990's and early 2000's. The people saying that any form of copyright infringement was bad were either ignored or flamed since a lot of people just looked at their collection of software from the late 1970's and early 1980's and said, "we're at risk of losing this if we don't make it available, and the copyright holders won't lose anything if we do make it available." Which wasn't strictly true since there were some software developers who created software in the early 1990's who were still selling it. Unfortunately their absolutist attitude did not earn them many allies, so it became a lost cause.
0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345678901234567890123456789012345root:p3Y0ydAx:
This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.
Meaning, people hadn't figured that out, or it wasn't a commonplace technique? They must have seen buffer overflows crash running software; it doesn't take much imagination to think about the next steps.
Perhaps the most "adversarial" context would be: undergraduate timeshare use. So the mainframes of the day, which would be the typical platform for undergrad programming (if timeshare was even offered to undergrads in 1973) might be expected to be somewhat hardened to attacks of various kinds since undergrads trying to hack their grade higher, get more CPU time, etc, was a known thing.
But Unix machines, and minicomputers in general, were not used for undergrad purposes. They were only available to be used by PhD candidates and other higher order beings. Those dudes had the root password anyway, so no need to harden the machine against their potential attacks. There was no networking to speak of, so no malicious traffic to worry about. The first worm didn't appear until the late 1980s.
So if you had talked to a Unix sysadmin in 1973 (all...1 of them) they probably would understand the general concept of someone running a program that crapped onto kernel memory with the result they could have root privileges, but there would have been no plausible adversary around with any reason to mount that attack. Plus every cycle and every byte counted, so there would have been many more fish to fry before worrying about buffer overflow problems.
Would student records even be stored on an unix system at the time? I am under the impression that Unix was very much a research operating system in the 1970's (either the subject of or a tool for). Administrative functions were more likely to be conducted with an IBM mainframe. (At least that is how it was when I arrived at university a couple of decades later, which I always took to be a legacy thing.)
Not in 1973, but still during the 1970's.
Malicious attempts at exploiting would require physical access.
This was 1970's running on a PDP hardware. These were not normally connected to the internet so the attack vector of attacking would be have literal.
Any bugs would probably been of been fixed and isn't this the first alpha of unix so probably patched later in versions.
> By supplying addresses outside of the space allocated to the users program, it is often possible to get the monitor to obtain unauthorized data for that user, or at the very least, generate a set of conditions in the monitor that causes a system crash.
> In one contemporary operating system, one of the functions provided is to move limited amounts of information between system and user space. The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine.
(Volume 1 is at https://apps.dtic.mil/sti/citations/AD0758206 .) However general awareness of the security implications seems to have been very limited before the Morris worm, and then even for several years after that. Even in late 1996 an article which in its own words "attempt[ed] to explain what buffer overflows are, and how their exploits work" could still be published in Phrack magazine, and in fact even be quite a milestone https://en.wikipedia.org/wiki/Buffer_overflow#History .
Fun fact: The VT-52 didn't have a loudspeaker for the bell sound. Instead, it had a electromechanical relay which was set up to self-oscillate.
"Typing a character produced a noise by activating a relay. The relay was also used as a buzzer to sound the bell character, producing a sound that "has been compared to the sound of a '52 Chevy stripping its gears."
Things that are working: `cal 2026`, coredumps
Things that might be broken or aren't working as expected: ps (only returns "No mem")
And utmp is in /tmp?
And no /usr/sbin or /sbin? And nothing in /usr/local?
The messages from `write root` are only in uppercase.
And they still had coredumps at the time if you press ctrl-\
I went to bed last night with a couple of people poking around… woke up to a whole lot more. Appreciate the load test!!
I’ve fixed the rate-limit issues people were hitting. There’s still a global cap of 100 concurrent sessions + per-user limits to keep things stable during spikes.
I’ve also added an “Attributions & Acknowledgements” section.
The backstory is wild: UNIX v4 being recovered from a ~1973 tape at the University of Utah after being effectively “lost” for decades. Reading about the recovery and then poking around in it under SIMH on my PC is what pushed me to wrap it up as a public, browser-based terminal that other people could take a look at - and hopefully get as much out of it as I did.
Have fun exploring it all (especially all the primitive bits — remember: use "chdir" instead of "cd", and "#" is backspace).
- Daniel
But it's lacking some features available in newer versions of ed, such as using 'n' to print line numbers.
Thank you for this, I enjoy digital archaeology. :)
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.