What have we lost? – Demo of exotic OSes (2021) [video]
youtube.com
youtube.com
How times have changed.
IBM i is fascinating, and in a world of ever-changing tech-stacks I sometimes yearn for a stable environment where you don't have to fight with 10,000 node.js dependencies every other month just to keep that payroll website going. I've never came in contact with IBM i or POWER tech in a professional capacity, but have purchased an RS/6000 and, more recently, a TalosII system to play around with ppc64le :)
So even if the computer was actually quite slow, if you knew what you were doing you could "type ahead" a few screens into the system, and then wander off and do something else.
That just doesn't work on GUIs (some rarely are well designed so that it can) and certainly has zero chance of working on webpages.
17 year old me scoffed at the dumb terminals. When we converted users and they hated it, I learned SO MUCH. They could fly through the TUI. They’d have a form filled out before the screen could paint.
The thick client didn’t even have keyboard shortcuts for most things. But the company had bought a ton of PCs and was moving everyone to the first iteration of Exchange. So I got the VAX up on the LAN and set them up with telnet.
The users liked that. White text on a blue background became the most popular color combo. The internet was becoming a more popular thing, so they could begin the proud tradition of screwing off at work staring at a browser.
Eventually the original package was retired and keyboard navigation was added to the thick client. But you couldn’t go “ahead” of it. And flipping between the keyboard and mouse is just slow for “real” work. They adjusted but I learned a lot about how a computer can best augment someone’s abilities. It’s not always the cool or most intuitive way.
That exercise forced me to learn VMS, then I touched Solaris and fell in love. I couldn’t afford a pizza box as a college kid, so installed RedHat 4.1 from a CD in a book.
Now I get mad when I have to edit text without vi.
Same as it ever was.
Of course the screens had rudimentary markup to support this including client-side validation of sorts.
I used to do this in Macintosh System 7, since Macintosh System Software used a similar keyboard buffer. Of course, the UI heavily encouraged the mouse, and often required it. But I miss being able to tell apps "Do these 17 things, because I know what you're going to ask me and I know you're gonna be busy, and I can't be bothered to script it right now.".
I.e., select a window, type ahead a few screens/commands, switch to another window and continue work - the keyboard buffer would stick with the previous window.
That sometimes works now with Terminal, etc, but sometimes it doesn't. I think it's a question if the OS is buffering, or the application, and/or if the application tracks which window was in focus when it buffered.
Gmail does provide some hotkeys and I think even those "few" ones really help, also Atlassian applications yet most web pages I have interacted with have none
It's still somewhat in there with / triggering the menu on Windows Excel.
Image a piano played by touchscreen or mouse.
A different tool I made ran in the PASE [1] environment on the same system -- compiling & running C++ in IBM's AIX runtime environment. Really interesting experience.
[1]: https://www.ibm.com/docs/en/i/7.3?topic=programming-pase-i
Single files often were made of multiple data streams “resource forks”, and this was actually utilized heavily (NTFS has a similar concept but it’s almost never used). Files had “creator codes” as metadata rather than file extensions. They were directly and firmly associated with the application that created them rather than a description of their content.
Files in and of themselves were a very different concept in MacOS Classic.
In my eyes a big part of what killed this was the Internet. To the Internet, a file is clearly only a single stream of data. Files are typed by content via mime and file extension, not what created it. Anything with resource forks need to be bundled in a .sit file. This is clearly inconvenient, and made MacOS files second-class citizens.
Mind you, resource fork still exist in macOS today, they’re just used for custom icons, tags and file comments. Metadata. Nothing to the extent that MacOS Classic used them for, and all things users don’t mind losing on uploading to the web.
- https://www.macintoshrepository.org/articles/152-what-is-a-s...
If you do these resource streams, how do you copy those to various other mediums, like physical drives, tapes, pipes, sockets... All consist only of a single stream at a low level, because why make it harder than that? Now that means that instead of "cat" your standard way to read such a multi stream file would be a command that serializes it to the "sit" format as you mentioned, making that format almost the canonical representation. So what was he point of implementing these resoure forks in the filesystem again?
Critizicing Unix often comes back to the "reinventing poorly" phrase, the simplicity of not having some features at every layer is a virtue.
* multiple resource forks can be presented as files in a directory, the directory having the name of the multi-stream file and the files in it named after the stream, e.g. "resources"
* for transfering data to other mediums/computers etc you can use container formats such as zip or tar, but with the unpacker having the ability to unpack them properly to a multi-stream file
* since on modern systems such as windows you can seamlessly file-browse into container formats such as zip so this is even less of a problem
* actually OS X to this day uses something like this for "Apps" as they are a special container/directory that you can browse into when you know the magic incantation
Not only apps, but many other types as well. And the organization technique is nothing magical, they’re just directories with an extension in the name, and usually some standardized structure. They’re officially referred to as “bundles.”
Apps are bundles, various plugins are bundles (audio units, pref panes for System Preferences), and if Finder didn’t treat them specially, you’d never think they were. In a shell, they’re just like any other directory.
The problem with the Unix lowest-common-denominator model is that it pushes complexity out of the stack and into view, because of stuff other designs _thought_ about and worked to integrate.
It is very important never to forget the technological context of UNIX: a text-only OS for a tiny, already obsolete and desperately resource-constrained, standalone minicomputer. It was written for a machine that was already obsolete, and it shows.
No graphics. No networking. No sound. Dumb text terminals, which is why the obsession with text files being piped to other text files and filtered through things that only handle text files.
While at the same time as UNIX evolved, other bigger OSes for bigger minicomputers were being designed and built to directly integrate things like networking, clustering, notations for accessing other machines over the network, accessing filesystems mounted remotely over the network, file versioning and so on.
I described how VMS pathnames worked in this comment recently: https://news.ycombinator.com/item?id=32083900
People brought up on Unix look at that and see needless complexity, but it isn't.
VMS' complex pathnames are the visible sign of an OS which natively understands that it's one node on a network, that currently-mounted disks can be mounted on more than one network nodes even if those nodes are running different OS versions on different CPU architectures. It's an OS that understands that a node name is a flexible concept that can apply to one machine, or to a cluster of them, and every command from (the equivalent of) `ping` to (the equivalent of) `ssh` can be addressed to a cluster and the nearest available machine will respond and the other end need never know it's not talking to one particular box.
50 years later and Unix still can't do stuff like that. It needs tons of extra work with load-balancers and multi-homed network adaptors and SANs to simulate what VMS did out of the box in the 1970s in 1 megabyte of RAM.
The Unix was only looks simple because the implementors didn't do the hard stuff. They ripped it out in order to fit the OS into 32 kB of RAM or something.
The whole point of Unix was to be minimal, small, and simple.
Only it isn't any more, because now we need clustering and network filesystems and virtual machines and all this baroque stuff piled on top.
The result is that an OS which was hand-coded in assembler and was tiny and fast and efficient on non-networked text-only minicomputers now contains tens of millions of lines of unsafe code in unsafe languages and no human actually comprehends how the whole thing works.
Which is why we've build a multi-billion-dollar industry constantly trying to patch all the holes and stop the magic haunted sand leaking out and the whole sandcastle collapsing.
It's not a wonderful inspiring achievement. It's a vast, epic, global-scale waste of human intelligence and effort.
Because we build a planetary network out of the software equivalent of wet sand.
When I look at 2022 Linux, I see an adobe and mud-brick construction: https://en.wikipedia.org/wiki/Great_Mosque_of_Djenn%C3%A9#/m...
When we used to have skyscrapers.
You know how big the first skyscraper was? 10 floors. That's all. This is it: https://en.wikipedia.org/wiki/Home_Insurance_Building#/media...
The point is that it was 1885 and the design was able to support buildings 10× as big without fundamental change.
The Chicago Home Insurance building wasn't very impressive, but its design was. Its design scaled.
When I look at classic OSes of the past, like in this post, I see miracles of design which did big complex hard tasks, built by tiny teams of a few people, and which still works today.
When I look at massive FOSS OSes, mostly, I see ant-hills. It's impressive but it's so much work to build anything big with sand that the impressive part is that it works at all... and that to build something so big, you need millions of workers, and constant maintenance.
If we stopped using sand, and abandoned our current plans, and started over afresh, we could build software skyscrapers instead of ant hills.
But everyone is too focussed on keeping our sand software working on our sand hill OSes that they're too busy to learn something else and start over.
I hate many things about Linux, but there is a lot of development work where Linux is much stronger. A lot about the "minimal design" approach is still valid today, and I don't mean Dbus or Docker or Kubernetes or whatever, which I likely would hate if I actually knew them.
In my view, the main problem about (Desktop) Linux is fragmentation and lack of standardization. A strong suit of Windows development is the APIs, at least the older ones that don't get deprecated after a year. There are useful APIs for everything related to a Desktop experience, and you can count on their existence as a developer.
The lack of standardization is what makes it feel like sand. Apart from the simpler stuff (POSIX), there isn't a trustworthy authority that maintains stable APIs for a solid user experience, at least not APIs that I feel like using personally.
> VMS' complex pathnames are the visible sign of an OS which natively understands that it's one node on a network, that currently-mounted disks can be mounted on more than one network nodes even if those nodes are running different OS versions on different CPU architectures. It's an OS that understands that a node name is a flexible concept that can apply to one machine, or to a cluster of them, and every command from (the equivalent of) `ping` to (the equivalent of) `ssh` can be addressed to a cluster and the nearest available machine will respond and the other end need never know it's not talking to one particular box.
Are you sure you understand how the Unix filesystem (VFS) works? On Unix, a filepath is exactly what you say: a name that can identify a resource. There are distributed filesystem protocols that are of course portable, not dependent on CPU architecture or anything.
I don't get what is your point about these Drive-Letter paths, they often create annoying complexity. I believe even NTFS has developed extensions to get rid of them. So, not that I think filepaths are beautifully easy to use on Unix, but they're much better than on Windows in my experience.
I mean, yes, I agree with you, Plan 9 is the true successor to Unix.
But Inferno is the true successor to Plan 9.
And yet, both are obscure and relatively rarely used anywhere, whereas VMS Software Inc. just shipped OpenVMS version 9.2, the first production-ready release of native x86-64 OpenVMS.
Here's a news story I wrote on it: https://www.theregister.com/2022/05/10/openvms_92/
VMS has now run on 4 different CPU architectures, migrated 3 times, and it is still out there, still in production, still being used by enough organisations to pay for another port and a new native version in 2022.
1. VAX → Alpha
2. Alpha → IA64 (Itanium)
3. IA64 → X86-64
It's doing well for something "obsolete".
Plan 9, sadly, has not even managed to replace Unix enough to hinder the vast uptake of an original 1970s-style monolithic FOSS version: Linux. I'm typing on it right now.
OFC not even close to a Linux or BSD support, but everything works like magic. No ssh, no enforced VTs, no POSIX (coding in C it's pure love here), no crapware.
On Linux, meh. I prefer OpenBSD, my main OS. Meanwhile I am using Alpine for, well, that ecosystem bound to the penguin with Linux-only software. But not for long...
Personally, as someone who's used xNix OSes for >30 years out of pragmatism not any love, I find Plan 9 completely inscrutable and unusable.
Years ago there was an Inferno ISO available -- gone now, AFAICT -- and I managed to run it. I mentioned Inferno here:
"Fed up with Windows? Linux too easy? Get weird, go ALTERNATIVE" https://www.theregister.com/Print/2013/11/01/25_alternative_...
I found the Inferno desktop a lot more navigable and comprehensible than 8½, Rio, Acme etc.
I still wonder if it might be possible to merge Plan 9 (and derivatives) and Inferno. Give the choice of C compiled to a native binary, or Limbo compiled to Dis.
There's a classical file manager:
https://pspodcasting.net/dan/blog/2019/images/filemng.png
With "bar" for 9front, and "winwatch", you just have to write some title bar in order to manage the windows with ease.
You could argue that your resources instead should be multiple files in a folder so we don't have to treat a fork specially, and you'd be right, and you'd also have invented the NeXT/OSX .app bundle.
I... kinda want to see how this could be done with ELF now. It seems totally possible.
.rtfd is quite nice and it's easy to re-use all the elements of a document.
FWIW, there's previous discussion over here: https://news.ycombinator.com/item?id=26723886
What have we lost? [video] - https://news.ycombinator.com/item?id=26723886 - April 2021 (83 comments)
IBM i is completely different in many ways. It has a unified 128bit address space. It does not have the same concept of a hierarchical filesystem (by default, you can bolt one on, but it clearly does not "fit"), and it does not even strongly have the concept of having everything in "streaming" files (or their equivalent) to begin with. It also has a completely different "command line" concept for example, and countless other aspects that are hard to explain succinctly.
It is a bit like learning Haskell, where it used to feel like you thought you could learn every language in an afternoon (after C, C++, Java, JS, Pascal, perl, python, awk, shells, BASIC, and countless others), but then discover you have to relearn the very basics, and that what you thought of as universal actually isn't.
A lot of these concepts work really well. They are at a level of abstraction that I would not have thought possible in practice. They allow the system to be incredibly stable and low maintenance, and elegant. The underlying architecture was changed at least once (maybe twice, not sure), and it was entirely seamless for customers.
It made me sad because I discovered a computing world that could be widespread reality, but in all likelihood won't be. That's thanks to UNIX being so pervasive that it's now basically woven into the very fabric of computing, but that is of course in no small part thanks to IBM's extreme closeness. I once thought UNIX was the way to go, but I'm not so sure anymore. And now that it's everywhere, too many of its concepts are considered a "ground truth". UNIX won because it was hard to avoid getting exposed to it, while for IBM i you had and still have to fight for even just trying it out.
Interestingly, the IBM mainframe world, i.e. z/OS and its predecessors, do feel the same in terms of "you have to relearn everything", but with the opposite outcome. Where IBM i is presenting you with unique abstractions from the very base of the OS, it's amazing how little abstraction there is in the mainframe world. You clearly get a sense that mainframes come from a time where a lot of common concepts simply had not been invented yet, while on the other hand IBM i (or rather its predecessors) reimagined OSes at a much later time.
"everything is a file" is brilliant, but UNIX didn't take that as far as it should have, Plan 9 is much further along that road and I would consider it to be even more elegant than UNIX.
The way in which things work is just like you would expect them to work, including being able to compose stuff (for instance: in Plan 9 to run a new version of the window manager in a window in the old one) is what I really like about that particular system.
Between Plan 9 and Erlang we missed a bus somewhere.
Agreed. The interface between applications and the operating system is not sufficiently abstracted. If it were software would be vastly better; faster, more secure, easier to manage, scale, migrate, troubleshoot, etc.
There is a lot of attention paid to programming language design and too little paid to the environment in which software has to operate. I think the low hanging fruit is improving operating systems and their abstractions. Solving this at the programming language level is not feasible; all that produces is a virtual machine that adds overhead, complexity and valueless diversity.
In terms of abstraction, almost the opposite in some sense, as I've noted in my last paragraph. In terms of usage as well: IBM i's command line model I also mentioned helps a lot in using the system even without external documentation (more than the UNIX shell does), which seems to be the opposite in the mainframe world.
That's still 'only' 32 MB of RAM which may seem tiny by today's standards but that machine happily served a few hundred branch offices of a fairly major bank all by its lonesome, so that's 1000's of concurrent users (https://en.wikipedia.org/wiki/CICS).
Love it. Added to https://github.com/globalcitizen/taoup
That's your second pithy wisdom tidbit. (The first was The idea that data is a corporate asset needs to die. Data is a corporate liability.)
It took me literally years until I stumbled upon an affordable machine with licenses. The machine I got is decades old and was decommissioned in 2008, after a long life.
IBM created something revolutionary and did everything to keep the public away from it.
What I'm curious, though, is in the world of a random back office developer, how much of the, well, "inner beauty" of the machine would I have encountered.
Most of the cool Unix-y stuff happened mostly through ad hoc integrations with random Stuff as circumstances presented themselves, and I don't know how much of the AS/400 a random (likely) COBOL programmer would have delved into.
I was heading into some UNIX zealotry path, and then started diving into everything that happened before UNIX, what was going on at Xerox, DEC, Olivetti, ETHZ, and so forth, sunddenly UNIX wasn't that interesting as I once thought.
Too bad it never made it to the wild. In its last days it was ported to an IBM AIX System (RS6000?), but the company went bankrupt before that port made it out.
Yes. The System/38 - AS/400 - iSeries - IBM i (the lineage) resulted from a project called the "Future Systems" project which started in the late 1960s and tried to imagine computers as appliances, while recognising that hardware was changing fast.
Hardware architecture independence, encapsulation of software objects, a highly regular, helpful user interface, and minimal administration labor were all design goals of that project.
It succeeded too well. User-written programs were stored with their "intermediate representation" (think assembler). They could be, and were, retranslated automaitcally when moved to a new architecture.
Upgrades from a 36-bit processor with 20-bit addressing to a 48-bit processor with 32-bit addressing to POWER (64-bit / 64-bit) were essentially just a backup and restore[1] for customers.
As probably mentioned in the video, the system could be configured with a modem and would phone home to IBM if it detected a fault.
It was common that after a few years with turnover of accounting personnel, offices would not even know that they had an iSeries - this is probably still the case.
This lack of mindshare is probably what killed the i. That and IBM not wanting to sell it, to protect their mainframe business.
---
1. On backups: The OS stored a backup history (dates of the last 20 or so backups, from memory) with each object. It also stored each object's date of creation and the name and serial number of the system it was created on, as well as the dates of metadata modification (changes to access rights, for instance).
Not surprisingly with all the bookkeeping it was much harder on disk drives than IBM's comparable systems. Disk drives that lasted for many years when used with a 4300 series (cut-down mainframe) tended to die in 18 months used with the System/38. RAID-1 and RAID-3 (2 stripes plus a dedicated parity drive) was implemented in the early 80s, from memory. RAID-5 came a bit later IIRC.
Programs and files were objects. So were user profils and group profiles. Access control lists, objects that contained lists of users and groups and permission lists for each entry, were used to control access rights to other objects. They themselves were objects at the same level as these - created, manipulated, and backed up in just the same way.
It tried out a lot of things. It had a unified concept of "message queues". There were permanent ones like the QSYSOPR (system operator) queue, the equivalent of syslog. Processes each got a message queue. Programs within a process each got a message queue, so a program could tell its grandparent something and continue. As a programmer you could create your own message queues, the analog of named pipes in Unix. Message templates were predefined and stored in "message files", which allowed you to write "second level text" --esentially detailed help--for each message. The shell's built-in command prompting and menu system was built around message files and queues as well.
I was also using Norse Data systems with some OS specific to them, which was basically Job Control Language uplifted from cards to a terminal. It sucked. If memory serves me right it had a problem similar to early Tops-10: you could walk down directory trees but there was no "up" function, just 'go back to root' or 'home' -the Unix creation of . and .. as links in the current directory was just phenomenal to me, in terms of simplicity and outcome. From memory, Norse Data moved to a Unix variant.
When CP/M ruled the 8086 world, MS-DOS was to some extent "exotic" -That didn't last, nor did CP/M in the end.
Burroughs mainframes had the kernel integrated into a CI/CD system: if you entered kernel editable code in an editor with write permission, save and exit went to compile-deploy in a very few steps.
KA9Q was pretty much a multi-tasking OS, running "inside" DOS. if you had it on a floppy, you could "run" it on almost any PC, dial up, connect, have TCP/IP and then have your mostly almost asynchronous SMTP process be connected to and receive your email. I had a disgustingly heavy 486 laptop I lugged around the world on a work trip doing this. I wrote nothing to local disk in DOS, I lived in KA9Q. Phil Karn had written the OS we really wanted, inside DOS. Amazing. My main problem was buying the correct Telco approved connector for the modem and wiring it up to plug into my device each time.
I don't think RSTS or RTE or any of the different OS which ran on pdp11 were "exotic" at the point they were being put into deployment running radar and missile systems, but they were pretty different to how we view an OS these days. A lot of things in RSTS or George (the OS for UK Mainframes in banking) were uplifted into the future as encapsulated/emulated systems.
In the mid 00s I had a large set of C source dumped at my desk, absent build-system, and was asked to get it going across a few different OS. I found #ifdefs for a bunch of architectures I'd never even heard of, and #ifdef ND5000 was only resolved when I had a chat with one of the original authors and asked WTF??
A quick look at ndwiki.org (because of course that exists) tells me they had NDIX, which was a custom UNIX, and SINTRAN which might be what you're describing.
I was given a very precious CD-R(!) with about a million lines of C on it, that we had bought from the vendor of some crucial middleware we were using. Included with it were the build files for a proprietary build system that we hadn't bought alongside the source license. My task was to understand it and produce a new build system for it that would work on Solaris/Sparc, HP-UX/PA-RISC and HP-UX/Itanium, AIX/Power, Linux/x64 and z/Linux, and Windows Server 2003.
It's funny how only about half of those are a going concern now!
Because Linux (and you can throw in the BSDs here if you want) is so capable as is, the chance someone will write an OS from scratch is pretty low. They'll much more likely base it off of Linux and go from there, which means that it'll just be another Unix clone.
Even things like Fuchsia are heavily influenced by it, and end up feeling "similar". As someone else mentioned, Unix won so hard most everything else is dead; even Windows is very "unix-like" in ways people don't even realize.
Writing an OS from scratch is hard work, and without complying with pre-existing standards, the new OS won't be able to take advantage of existing software or communicate with computers running different operating systems, making it a non-starter for most users. Even supporting a wide range of hardware is very challenging, especially given the fact that many hardware devices lack documentation sufficient to write drivers, which results in challenging reverse-engineering projects or relying on the hardware manufacturer to create drivers for the new OS; this is a challenge even for Linux, which has the best driver support outside of Windows. Most people who want to experiment with new ideas for computer systems end up building on top of Linux since they can leverage Linux's existing hardware support and its implementation of a wide range of standards allowing interoperability.
I'm working on an experimental desktop computing project that ironically uses Plan 9 as its base platform since Plan 9's everything-is-a-file interface and its overall simplicity allows me to build my project with less effort than dealing with Linux/X11/Wayland/dbus/etc., but a big part of me is tempted to eventually write some 9P services to emulate enough of the underlying Plan 9 architecture to run my project on Linux and the BSDs in order to take advantage of these operating systems' better driver support.
It does not have to be completely isolated. You can still have support for some common communication protocols and maybe some client software running on a mainstream system to do various things.
https://git.sr.ht/~ft/npe/tree/master/item/include/npe
But not with a TTY UI. With libdraw:
This stings since I really like Alan Kay and have been influenced by his ideas, but am also working on a Linux-based VR headset as a thinking tool[1]. I think Alan would approve of the hardware but not the software, perhaps ultimately saying something like "you can spend your whole life dicking around in Linux, but still not understand anything about computing".
I'm pretty sure commodity hardware, standards like POSIX, and the fact Unix-like OSes being taught in operating systems classes really did more than just Linux alone.
> Unix won so hard most everything else is dead; even Windows is very "unix-like" in ways people don't even realize.
I'm not so sure. I learned to code on VMS and then AT&T Unix, and I see a lot more VMS in Windows than anything. VMS was actually pretty interesting itself.
Microsoft hired the main architect of VMS, Dave Cutler, away from DEC to design Windows NT. (VMS++ = WNT!) I haven't worked on any in-depth Windows programming projects. I did read an article some years ago about Cutler, VMS, and WNT. The author pointed out an insightful distinction between VMS and Unix with regard to I/O operations: VMS tells you when an operation completes, whereas Unix tells you when you can begin an operation. As a result, I think, asynchronous I/O under VMS was there and available from the git-go, but always seemed like some odd thing grafted onto Unix, making it more painful than it should have been. I have never used it, but I believe WNT's overlapped I/O was patterned after the VMS model?
Not sure why you mice words. Cutler developed NT at Digital. That's better. In 1988, Cutler took his work (the literal data, the MICA OS code from DEC's cancelled Prism RISC project) and his engineering team at DEC with him to Microsoft. I believe it was much less like poaching and much more like defecting. DEC ultimately forced Microsoft into an alliance under threat of lawsuit for the IP theft to migrate the VMS user base to NT, with Microsoft paying quite a lot, $180M, to avoid lawsuit, for, get this... training DEC engineers to use NT. In 1995, someone at MIT found large chunks of DEC MICA code unaltered, including comments, in Windows NT.
https://www.goodreads.com/en/book/show/1416925.Show_Stopper_
I'm not really sure that is the case at all. VMS had versioning file system that had support for multiple file types including stream, sequential, indexed and relative. It had a very different security model, four levels of processor access (unix there's kernel and userland) and it had very different networking capabilities, including clustering baked in (in 1983).
> Because Windows is very close to UNIX compared to either of those.
There's deep VMS heritage in Windows NT: both VMS and NT were written by David Cutler.
I believe this major design difference came from VMS.
WSL is a tacit acceptance of UNIX dominance.
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
There are VMS-inspired parts also, but even that is somewhat in the Unix sphere of things.
The inspiration rather came from CP/M.
"Various aspects of CP/M were influenced by the TOPS-10 operating system of the DECsystem-10 mainframe computer, which Kildall had used as a development environment."
This is an urban myth of computing, and it needs to die.
CP/M commands did not accept command-line switches in any standard way. You are trying to "correct" people who are telling the real story by repeating a myth.
http://www.os2museum.com/wp/why-does-windows-really-use-back...
1: http://fsv.sourceforge.net/ 2: https://www.youtube.com/watch?v=dxIPcbmo1_U
It was kinda easy to get your head around the OS just navigating through the system folder. The UI was also more consistent than anything we have these days.
———
I think we're talking about different things here. The UI might have been superior in MacOS, but the technical foundations of Unix clearly were. Something OSX tried to (belatedly) reconcile. Nothing stops you from adding an awesome UI on top of Linux (although I'd say UI will always be a matter of personal taste and prior experience).
Serenity is far more interesting.
To this day, Haiku has been dragging its feet on the Pi (and yes, I know it’s a community effort, that it requires sponsorship, suitable volunteers, etc. - I’m just pointing out that they dropped the ball in even acknowledging the need for a port).
For the rest there are some interesting native tools such as video editors.
But Haiku needs 3 things to get more real life use cases:
- GL/Vulkan for older Intel (both old and new)
- Async USB
- UVC webcams
"I'm not a big fan of unix myself and so 'essence' is designed without any sort of unix influence"
Essence OS demo (2021): https://www.youtube.com/watch?v=aGxt-tQ5Bt
I had an older coworker at one of my first jobs who would go on and on about VMS all day and how UNIX sucks. I never used VMS so I wouldn't know :)
Edit: vms was used for my college's firewall/gateway. It was fine. I've used it professionally as well. I don't recall anything that stood out about it.
setopt auto_cdACME[1], a text editor, is a great starting point.
A Unix-WINE for Plan 9, so we could run legacy Linux apps on a more modern OS.
And never forget: Plan 9 was just a stage and not the end of the developmental line. That was Inferno.
Plan 9 abstracts the network away into the filesystem.
Inferno does all that too and abstracts away CPU architectures as well, so the same compiled binary runs on x86 and ARM and RISC-V and whatever you happen to have.
https://9lab.org/plan9/virtualisation/
On Linuxemu, you need 9front for i386.
WINE isn't a VM or an emulator: it "just" translates Win32 API calls to Linux ones. Getting that working has required implementing a load of DLLs and things, but it works surprisingly well now.
An environment to let Linux binaries launch on Plan 9 (or insert preferred derivative here: 9front, Harvey, Jehanne OS, whatever), akin to the Linuxulator in FreeBSD or the Linux Zone on Solaris, would make the OS much more usable.
https://fqa.9front.org/fqa8.html#8.7.1
Old and outdated. You might be able to run some statically linked browser from elsewhere.
Linuxemu works with i386 ELF binaries, so maybe an Alpine i386 chroot could work.
I actually do have one keyboard in my archive of things (aka "stuff" ;-), but I have no idea how to interface it to modern hardware, sigh.
It seems that Xerox PARC's work on Lisp is less known than its work on Smalltalk, despite the fact that a Lisp heavyweight, Gregor Kiczales of "The Art of the Metaobject Protocol" and aspect-oriented programming fame, worked there. Xerox PARC in its heyday was quite a fount of innovation, and the work done from the 1970s through roughly the 1990s (I don't know much about Xerox PARC beyond the 90s) remain a treasure trove of ideas that should be reexamined in today's world.
I proposed an idea about it a year ago that got some traction here on HN:
https://news.ycombinator.com/item?id=28366292
Interlisp/Medley is the only rich graphical LispM type environment that's open source. OpenGenera isn't and probably won't be, which is tragic, but there are many tragic things in this world.
What many of the commenters to my blog post in that link don't get is that it is not a good thing that there are commercial graphical Lisp IDEs.
For comparison: when there were multiple commercial Unix implementations, the result was increased fragmentation and slower development.
Linux, as a FOSS, PC-native Unix, has propelled Unix forwards more in the last 25Y or so than the previous 25Y of work on commercial Unix ever did.
Old Lisp hands tell people to learn Emacs and install SLIME or something. Well, Emacs is about as appealing as other kinds of slime, like slug mucus, are: to most younger types, it's repellent and disgusting.
Emacs is a horrible crusty old 1970s editor.
To make Lisp look appealing and interesting, then it needs a rich modern GUI, a rich set of libraries to call upon and ways to access others. It needs a fancy graphical editor to show off its power.
The world has a FOSS Common Lisp: it's SBCL.
Find some way to run Medley under SBCL, however ugly the hack. Linux was an ugly hack once. UNIX itself was an ugly hack once. There's nothing wrong with ugly hacks. They are to be encouraged. They are the keystone of FOSS.
Get Medley running under SBCL somehow so there's a 1980s graphical FOSS Lisp environment, not a 1970s text-based one.
You're probably more or less on your own in terms of figuring it out, though, because not many people have those keyboards!
Sure, but as I'm not a good hardware tinkerer, ... but maybe I should visit some local self-repair community group and learn.
Symbolics produced a nubus(?) coprocessor with their Ivory chip in their final days, which used a box to interface the keyboard to Apple's ADB, but I never got hold of either the coprocesor nor the box.
If you're in the Bay Area, I would build the adapter for you just to have the opportunity to check out a Symbolics keyboard first-hand :)
It's still not completely documented, but it's better than most "Here's the docs for the basic I/O peripherals but we only provide closed drivers for Linux" SoCs.
Otherwise there's still just the regular old x86 PC everyone has lurking in their modern PC.
I wouldn't dare call seL4, haiku, genode or managarm toys.
They had the keys to the future in their hands and wasted their opportunity.
http://www.codersnotes.com/notes/a-constructive-look-at-temp...
It's things like this that we need more of - and eschewing networking is a great way to work out what you can actually do with a computer. I feel everything just kind of develops until it has a TCP stack and then becomes another "basically just a blob on the internet".
That's not even to get into the various things we just assume about networking that are actually just accidents of TCP, IP, or more and more HTTP.
Another thing we haven't really dug deep into is the "everything is a file" paradigm which basically has been interpreted as "everything is a text file" - the hatred for binary data runs deep, but binary data is most likely the best for computers. XML, HTML, etc are perhaps NOT the best representation for various complex forms of data that we want to use.
There are other tiny OSes which are FOSS and are much more capable.
Oberon is my personal favourite, in terms of how much it does with how little. http://ignorethecode.net/blog/2009/04/22/oberon/
Terry Davies left it out intentionally, AFAICR, due to the complete lack of any security in TempleOS. Putting it back in seems a bit irresponsible, but nonetheless, it's impressive.