Forgetting the history of Unix is coding us into a corner
theregister.com
theregister.com
Part of the problem is the sheer breadth of IT and software development today. 40 years ago, I felt like I understood nearly everything: I designed processors at the transistor level, programmed from machine code through assembly to Lisp, Prolog, Pascal and other languages. Worked on projects from tiny to huge.
That's just not possible today. There are too many areas of application, too many frameworks and languages. Too many tools and platforms. Any individual developer is going to be in a niche. Your web developer knows nothing of how to write ABAP, your SAP developer has no clue how to do embedded programming for a microcontroller, your real-time embedded programmer knows nothing of databases, your database admin thinks React is something to do with nuclear power plants.
Today, it's all you can do to stay abreast of developments in your own field. There is little time to look for lessons from the past, or across to ideas from other, parallel fields.
The saddest thing about the way this changed is that the barrier to learning is so much lower today, but what do you actually do once you've learned?
When I was a kid, there were no programming classes in school and I had to go buy books and magazines to learn how to code in BASIC or assembler or Pascal. But once I've learned a new trick, I could immediately do something with it and feel good about it. It didn't matter it wasn't something spectacular, it didn't matter it wasn't very useful, because it was mine and there weren't 1000 of other things just like it, available to me at a touch of a button.
Compare that to what my kid is going through. He wanted to try learning to code, so we signed him up for some classes where he learned some Python. Later, in high school, he took AP CS Principles and they taught him some rudimentary JavaScript. Now, in his junior year, he's taking AP CS A, where they're teaching him Java.
Thing is, what can he do with all that? He's surrounded by devices running code. Writing a toy program that fills the screen with "HELLO, I AM COMPUTER" does not feel like you just learned a magical incantation that makes this machine do your bidding. Writing some actually useful code is harder, and it feels pointless, because there's almost always an existing app you can have at a click of a button and it does what you thought of and probably better. Writing useful code that doesn't already exist -- like e.g. your own mod for such-and-such game -- is even harder than that.
> Any individual developer is going to be in a niche. Your web developer knows nothing of how to write ABAP, your SAP developer has no clue how to do embedded programming for a microcontroller, your real-time embedded programmer knows nothing of databases, your database admin thinks React is something to do with nuclear power plants.
To top off the irony, generalists are not being appreciated or sought much.
But there's joy to be found in writing pointless and abstract programs. It's more about the journey and less about the utility of the finished product. Writing, for example, an ASCII-art drawing system that works on a big rectangular 2D character array can teach you so many concepts – from OO and encapsulation, through linear algebra, to file IO.
Sure, and that's how you know you're really into programming. That's how I could tell my kid wasn't really into it, but rather wanted to try out this thing his dad loves to do so much ;)
I guess that hasn't really changed: if programming is something that "calls to you", it will still "call to you" despite all these changes.
I guess what I'm wondering is whether there's a "middle ground" we're missing. There are kids who will choose software development just because "it's a good career". I don't want my kid to take that path and risk ending up with a job that is absolutely devoid of joy, rather than trying to find something that would be more fulfilling. On the other extreme are the kids who are the way I was when I was a kid: programming is something that fascinates them regardless of whether it's useful or a good career, because they find joy in the act of programming itself.
Does the middle ground exist? Are there kids who would actually be happy writing software for reasons not so banal as "it's a good career", but aren't in the "holy shit, this totally abstract and pointless thing I did was so cool" category either?
No, but in the 80s, when the guy at Radio Shack didn't know how to stop it, it was still worth it somehow.
What can your kid do to assert some goofy kind of power in today's adult world?
In retrospect, I realize that the part you quoted might sound like I felt that toy programs like that weren't magical, when I was a kid. On the contrary, I'm trying to say that they don't feel like magic in today's world.
Well, there are a lot of people who enjoy cooking, or gardening, or carpentry, or making their own clothing, or playing in a local softball league, even though there are many professionals with professional-level skills and equipment who can do those jobs better than they can.
I think it's like you suggested in your later comment: you either have the bug for programming, or you don't. There are a lot of programmers nowadays who don't -- they just program to make a buck.
Not that there's anything wrong with making a buck, but it's like the guy who flips burgers at McDonalds. He does it to make a buck, not because it's speaking to his inner need to be a creative chef.
Find out what his favourite hobby or favourite game is, then demonstrate a little script... Suddenly the conditional branches and loops don't seem so abstract anymore !
What has been will be again,
what has been done will be done again;
there is nothing new under the sun.
10
Is there anything of which one can say,
“Look! This is something new”?
It was here already, long ago;
it was here before our time.
11
No one remembers the former generations,
and even those yet to come
will not be remembered
by those who follow them.
---
That's from Ecclesiastes 1 (NIV), and it was written at some point between 450BC and 180BC.
I find a lot of these tools and frameworks and languages and platforms are attempts to correct perceived problems in the original tools and methods. But these new things have their own issues which someone else will attempt to correct. Then you get your cliques and reddit subs that make fun of you for using X because it's old.
My point is that there is no back to basics--no grounding in the fundamentals we grew up with--or should have at least.
Moving slightly to mobile apps, what about Jetpack Compose for Android and the equivalent for iPhones? Electron? Or classic programming: How is your SQL, including stored procedures? Note that Oracle is different from Microsoft is different from MySQL. Want to learn ABAP? How about writing a back-end system in Java, with a front-end in JavaFX?
I'm just getting started...
No, you cannot learn all of this sufficiently to be even remotely productive. You may, like me, be aware of a lot of it. I'm sure you could pick any single new platform or technology, and become productive in it in a few weeks or months. But to be a real generalist, able to do it all? That is simply no longer possible.
There are entire niches in software development that you can dismiss wholesale.
Virtually everything in the web that isn't the web standards themselves or from the most popular libraries isn't worth learning because it's just regurgitation.
If you know CSS as an applicable professional level, any CSS framework you see is irrelevant. You can pick it up. Etc.
GP mentioned the two-part "jack of all trades", but there's a relatively modern third part to it that expresses this sentiment: "A jack of all trades is a master of none, but oftentimes better than a master of one"
I like that. I think that's an accurate statement.
I started programming in 1974, professionally since 1979, and I'm still working, mostly web sites and lots of system admin. I don't know most things at expert level, but I can learn and adapt quickly and start producing right away, because I have decades of experience with analogous or ancestor technologies (like C and C++, SQL, Unix) at least at a very proficient level, and I have lots of business domain expertise.
I have worked with true experts. No need to go head-to-head, there's no competition, just a great opportunity to learn. Mostly I have worked with people who have mediocre skills, and narrow skills, who can't adapt to change or come up to speed on new things. Most programmers live in the "expert beginner" zone Erik Dietrich described so well, not actual experts, and I wouldn't worry about going head-to-head with them if that was part of the job. But programming isn't competitive gymnastics, we don't have to perform better than the guy next to us, we only have to satisfy management or customers that usually have no idea what programmers do.
I think a lot of people underestimate just how much knowledge transfers between systems within the same domain. I have nowhere near your length of experience, but even in just my time I've been able to pick up plenty of languages and frameworks and get going right away because I already learned the underlying concepts when working with other similar systems.
No one should be starting from scratch every single time they start something new, and the larger your variety of experience the faster it's going to get each time you start with a new language/framework/system in that domain.
If you work on a team you can specialize in one of those but when you are learning you really need to use them all yourself.
When everything was a command-line application you didn't need to know more than C or Perl or Basic etc. But then you couldn't really do cool user-interfaces, with mouse and events fifty shades of color-gradients.
No, the problem is wholly human limitation. All humans start as an ignorant babe and have to both mentally develop and learn everything from scratch. This includes the rebellious teenage years and not listening to the wisdom of their elders (and for the adults around them, how to properly raise and mentor kids).
We have been doing this exact dance every dozen years for thousands of years for every single field and every single little task, from how to cook the best bread, the best way to saddle an ox, how to fix a toilet, etc. Learning and discovering, and relearning and rediscovering, ad infinitum.
NextJS always gives me a laugh too. I remember when it was newer in 2019/2020 and people raving about its file based routing and server-side rendering.
These new waves sometimes have new benefits to them, and sometimes they don't. I have to imagine that we won't ever seen an end to it, but at least it keeps some exciting new stuff on the table.
40 years ago: your physicist knows nothing of how to write RPG, your mainframe developer has no clue how to do embedded programming for a microcontroller, your real-time embedded programmer knows nothing of databases, your database admin wouldn't touch FORTRAN with a ten-foot pole.
... Which is to say, I don't really buy it. Or rather, I don't think that specialization is a recent phenomenon. It is true that the personal computing market consisted of comparatively simpler machines, which allowed for greater breadth of understanding.
But for the contemporary software coders the ingenious idea is of course rubbish. They would replace everything by node_modules.
The problem is the lack of innovation holds us back from solving complex use cases. The sockets API in particular is a gigantic mess, because the protocols are more complicated than people imagined forty years ago. For example it is simple to send a datagram. What if you want to get notified of the timestamp when the datagram hits the wire? Now you will 1) read a lot of man pages, 2) write 100s of lines of gross C code, 3) read the source code of the Linux kernel to figure out which parts of the manual were lies, then 4) fix your program with some different code and a long, angry comment. None of they would be necessary if the last quarter-century of network features hadn't been jammed into the ioctl and setsockopt hack interfaces.
In other words there's plenty of room for operating systems to reconsider interfaces in light of the systems and protocols we have now, instead of Space Age imaginary use cases.
Innovation is awesome, when it is in the pursuit of achieving something better. (Better, not just newer for the sake of rewriting everything Yet Again.)
What burns me out about this industry is that a huge amount of "innovation" is just a pursuit to create complexity for the sake of complexity and resume-driven development.
Thus we get to classics like the "Command-line Tools can be 235x Faster than your Hadoop Cluster" (a well-known one, but countless similar scenarios play out everywhere continuously).
To all of you setting up your 20 node cassandra cluster behind your enormous kubernetes setup, all just to serve your 100rps app: you're not innovating, you're doing it wrong.
(Not "you" you. The whole software engineering industry.)
Yes there are, but those 100k's of people doing that are working in a small handful of megacorporations.
For 99+% of the companies out there, they don't need the complexity. But it gets shoehorned in because resume.
Edit: I won't elevate the Unix model to a pedestal, but in his favour I will say that the relative simplicity of the model and it's inherent difficulties to extensibility helped limit scope creep and overengineering.
my daily job :(
Most recent horror I discovered: `mincore` is intentionally broken, always returns positive results when the calling task is running in a mount namespace. Because the hallowed unix file abstraction is fundamentally bad.
Because they're not just files. There are additional semantics and concerns that you cannot abstract away with read/write calls. You also need ioctls, you need send/recv, you need parsers on top to do something useful with the data, and so on.
The reason that the simple model dies out is because it's not as useful as it seems in practice.
It's a good framework for text-based computing, but nowadays we have so much more problems to cope with. This original idea never addressed networking, binary versioning and control, configuration management, async IO, multithreading, GUI, etc.
>Every increase in expressiveness brings an increased burden on all who care to understand the message.
There are plenty of new things that are largely compatible with unix philosophy. MQTT is one of my favorite examples, it's a message bus that follows a lot of unix philosophy and I find it a joy to work with compared to stuff like DBUS. Obviously it doesn't fill the same role as DBUS, but still.
http://doc.cat-v.org/bell_labs/utah2000/
At this point it's network effect, familiarity, and the free price tag, not a quasi-religious sacrament. Anyone can try to take that different approach, but that doesn't mean it will go anywhere. Some very smart people have worked on alternatives to Unix, or different directions for operating systems -- including the original Unix team with Plan 9, Wirth with Oberon, the Lisp machines. No Unix Inquisition shut those down, they just didn't offer a 10x improvement along enough axes.
I'm keen for any potential successor, but a lot things come back to effectively text, and anything we could build on top of it. Binary object formats seem like an alternative for faster parsing of structured data, so while that ability has always been it, it's a matter of people actually sticking to it. Maybe some coordination between the program and the shell?
Another approach is that the OS is basically a complete environment where everything is code. You can see the idea in the Smalltalk environments where you can theoretically interact with every object by sending messages. Lisp machines come to mind as well and one could even consider early personal computers that booted into BASIC as an idea of this (though in BASIC instead ov everything is a file everything is memory)
Anyone know how to add a new stdout-like interface to unix-like OSes?
https://man.freebsd.org/cgi/man.cgi?query=libxo&sektion=3&ap....
See ps(8) for example use: https://man.freebsd.org/cgi/man.cgi?query=ps&apropos=0&sekti...
Personally I like YAML, since you can add type-hints to data which you can use to turn simple text types into more complex types, but I can see why that standard wouldn't take off.
Most of the unix-philosophy people I know are interested in stuff like that, it just has to be implemented in a thoughtful way.
But that's sort of part of the problem, no one is going to agree on a common universal data-type.
You mean getting programs to ingest arbitrary data structures? OK, JSON is not arbitrary - it is limited to a certain overall format. But it can be used to serialize arbitrarily complex data structures.
JSON doesn't care so much about lines and doesn't necessarily represent an array of records, so it doesn't fit into this box.
Imagine a magical `ls` that can emit text/plain, application/json, what have you:
ls -f text
ls -f json
ls -f csv
ls -f msgpack
...
ls | jq # jq accepts application/json => ls outputs as json
ls | fq # fq accepts a ton of stuff => "best fit" would be picked
ls | fq -d msgpack # fq accepts only msgpack here => msgpack
ls # stdout is tty, on the other end is the terminal who says what it accepts => human readable output
We know how to do that:
- https://www.rfc-editor.org/rfc/rfc2616#page-71
- https://www.rfc-editor.org/rfc/rfc2616#page-100
And I mean, we really know: the last one we already do! Tons of programs check for stdin and/or stdout being tty via an ioctl and change their processing based on that.
It'd allow a bunch of interesting stuff, like:
- `cat` would write application/octet-stream and the terminal would be aware that raw binary is being cat'd to its tty and thus ignore escape codes, while a program aiming to control the tty would declare writing application/tty or something.
- progressive enhancement: negotiation-unaware programs (our status quo) would default to text/plain (which isn't any more broken that the current thing) or some application/unix-pipe or something.
- when both ends fail to negotiate it would SIGPIPE and yell at you. same for encoding: no more oops utf8 one end, latin1 on the other.
For me, this would mean an OS that supports both static and runtime reflection, and therefore code-generation and type generation. Strong typing should become a fundamental part of OS and system design. This probably means having an OS-wide thin runtime (something like .NET?) that all programs are written against.
UNIX's composability was a good idea, but is an outdated implementation, which is built on string-typing everything, including command-line options, environment variables, program input and output, and even memory and data itself ('a file is a bag of bytes').
The same thing has happened to C (and therefore C++) itself. The way to use a library in C (and C++) is to literally textually include function and type declarations, and then compile disparate translation units together.
If we want runtime library loading, we have to faff with dlopen/dlsym/LoadLibrary/GetProcAddress, and we have to know the names of symbols beforehand. A better implementation would use full-fledged reflection to import new types, methods, and free functions into the namespace of the currently-executing program.
James Mickens in The Night Watch[1] says 'you can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis'. Fair point. But the next-best thing would have been to define useful types around pointers as close to the hardware as possible, rather than just saying 'here, this is the address for the memory you want from HeapAlloc; go do what you want with it and I will only complain at runtime when you break it'. Pointers are a badly leaky abstraction that don't really map to the real thing anyway, given MMUs, memory mapping, etc.
There are so many ways we could make things a bit more disciplined in system and OS design, and drastically improve life for everyone using it.
Of the major vendors, I'd say only Windows has taken merely half-hearted steps towards an OS-wide 'type system'. I say half-hearted, because PowerShell is fantastic and handles are significantly more user-friendly than UNIX's file descriptors, thread pointers, and pipes. But this is still a small oasis in a desert of native programs that have to mess with string-typing.
[1]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf
Long time ago I asked my karate sensei how come I see some of the black belts doing katas in a different way. His answer was that to improve on something one must first have deep mastery of how it is done.
(i.e. "Shut up and do the katas correctly. If you ever get to black belt then you can improvise.")
Always found that answer to apply to everything. In particular it applies to a lot of the poor quality libraries and code we see today as a direct consequence of not understanding the past and what has been tried and failed and why.
The fact that we're talking in 2024 about using the file abstractions of Unix created in the 70s is proof of how extremely powerful they are. Nothing is perfect, but that's quite an achievement.
To write great code, I believe, means you have to be a domain expert of the domain for which your code solves problems.
https://www.theregister.com/2023/12/25/the_war_of_the_workst...
Note that this is loosely based on part of a FOSDEM talk I gave 4 years ago.
If you impose any structure, you're telling hackers what to do at the system level.
If that clashes with their favorite language run-time or whatever, you're effectively declaring war.
"Everything is a file" is not a lesson, it is an imposition that with some some things that are very different to files it is a very wrong thing.
The lesson is: Minimise as much as possible the different interfaces necessary and reuse them. Interlisp or Lisp machines used Expressions so everything could be read and written by everything.
Unix is a mess of binary formats, a mess of different console emulator formats, a mess of different text formats.
And the article is just about one guy who does not like Wayland not using files for everything, which is fine for me.
Very very strongly agree. As a corollary a small number of too simple interfaces is better than a larger number of more sophisticate interfaces.
"It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."
- Alan Perlis' Epigrams on Programming (1982).
So many silos and proprietary "cloud" systems, so much glue that needs to be constantly rewritten because there isn't any stability in an ecosystem composed of competing rather than cooperating actors.
There are great things that have come along, I would say k8s has been very successful at introducing a highly interoperable, composable API for abstracting over a bunch of machines.
But the trend towards hosted services that are incentivized to create lock-in and data-gravity isn't great.
Emblematic of this journey is Twitter, I think.
This is by me on El Reg, and it's part 2 of this year's FOSDEM talk. It will (I hope!) make more sense in context with the rest.
Maybe read “Worse is Better” before writing part 3.
And “Unix” is orthogonal with FLOSS.
Sorry to be such a downer — been reading el reg since it started.
Way ahead o' ya, kid.
https://www.theregister.com/2023/12/25/the_war_of_the_workst...
Note that this is loosely based on part of a FOSDEM talk I gave 4 years ago.
Your headings are
What is 'Unix' anyway?
Generations and the gaps between
Turn it up to 11
I believe your ultimate point is about Wayland and perhaps that it should follow everything-is-a-file. But that comes so late in the article that you barely give it a passing mention, and it isn't consistent with the premise of the article.
Nah. :-) I am not terribly interested in Wayland, myself, and I suspect that in the fullness of time it will turn out to be a not-very-interesting blind alley.
« This article is the second based on The Reg FOSS desk's talk at FOSDEM 2024 (part 1 was Drowning in code). »
That para contains hyperlinks to both.
The talk was a couple of weeks ago now and is already online:
https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-...
You can read the script if you want.
The title of the OP is "Forgetting the history of Unix is coding us into a corner." At no point do you explain who is forgetting what lessons, or why such forgetting is coding us into a corner.
In any case, the history is interesting and clearly well-researched. I offer as constructive criticism that your structure and clarity could benefit from continued editing.
I beg to differ. This is part 2 of an estimated 4. They are heavily interdependent; a talk is, of necessity, linear.
> nor does it excuse rambling.
Guilty as charged.
My plan was 3 parts, but this section would have been circa 3½ thousand words, which is way too long, so I cut it in approximately half. Currently I think there'll be 4 parts, probably published over the next 2 weeks.
And, as I said, if you want to skip to the end, the script is right there, but it's not as coherent as something intended to be read would be.
P.S. Thanks for the comments!
Sadly deadlines in online publishing come twice a day, and thus, on average, I only have 4 hours to bash an article into shape.
As Blaise Pascal wrote in 1657: “I have only made this letter longer because I have not had the time to make it shorter."
Or, as Churchill allegedly said:
"If you want me to speak for two minutes, it will take me three weeks of preparation. If you want me to speak for thirty minutes, it will take me a week to prepare. If you want me to speak for an hour, I am ready now."
So maybe the biggest problem here was just posting this on HN prematurely, maybe it would have worked better if you'd waited until the whole thing had been published.
A title that reflects the laundry list of topics:
Background Relevant to Revisiting Unix: The Tree of Unixes, Different Kernel Approaches, and the Baked But Broken "Everything is a File" Assumption
The talk was a couple of weeks ago now and is already online: https://fosdem.org/2024/schedule/event/fosdem-2024-3095-one-...
I linked to it in the first paragraph. You can read the script if you want.
Redox, OTOH, no: it does not even enter into it. Although I do not address it, if pressed, I might concede that if there is a Rust involvement, it's R9, the successor to Harvey OS.
Thanks!
I had some great feedback from some 9Front folks and ended up meeting up with a bunch of them after the event.
Given that I was half-expecting a lynch mob, this was a very pleasant surprise indeed... ;-)
When I was a kid learning how to code reading online, everyone was religiously defending the "UNIX philosophy" showing off their fancy and indecipherable one-liners (that don't work on my system bc I have GNU awk instead of whatever awk they have or whatever). This has basically died out year by year as so many people switch over to scripting languages with great standard libraries and super-powered easy to install libraries.
Now, I'm not really a fan of the super overkill object-oriented approach that systems like mac and smalltalk take, but I think our modern approach is a good compromise
The Python scripts takes them from 10 minutes to two hours, they're buggy, and they cannot process big files - everything is in RAM (with a monster dict) - without a crash/system freeze.
The power of UNIX, pipes and re-use.
import sys
from collections import Counter
L = Counter(
word
for line in sys.stdin
for word in line.casefold().split()
)
How many words are there in English? 1M? Huge text [Unicode] files.
Fancier tokenizer:
for word in re.findall(r"\w+", line.casefold())The way the Wayland section is included there, it seems like author is heavily implying that it is prime example of "spiralling software complexity and bloat", which to me sounds mostly like they do not know what they are talking about. Core Wayland is distinctly smaller and simpler than X11 ever was. Sure, modern graphics (etc) are intrinsically complex and Wayland exposes some that, but it does it mostly by keeping Wayland itself as simple and transparent as possible, instead of making Wayland (or rather its implementations) hugely complex and bloated.
But besides this Wayland thing, I'm really confused what the article is actually trying to say and how does the title relate in any way to the content? The intro implies that there are some lessons to be learned from UNIX history, but the article sure as hell doesn't cast any light on what those lessons might be. There is also this implication that we are somehow coding ourselves into a corner, but that is never actually expanded on what they are meaning with that?
In terms of lessons learned, the key observation maybe is that UNIX peaked somewhere around SysIII before BSD etc hippies set their grubby hands on it and messed everything up.
We are now reinventing a lot of concepts with regards to security, isolation, distributed computing.
Unix was probably a step backward, yet people keep on testing it is the pinnacle of how to organize and abstract computing.
It's linked twice in these comments already, so I won't add yet another.
Winston Churchill, 1948.
As can be seen, it equally well applies to history of computing. We keep reinventing the same things only because young coders don't learn from computing history and outright dismiss anything that's more than 1 year old.
Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it. -- George Santayana
I haven't used X11 in several years, and it's been well over a decade since I've had to put any serious thought into it, but I honestly don't remember being able to do this there.
What does it mean for the operating system to be “case sensitive”? Certainly APFS is case sensitive, so this must refer to something else?
My first introduction to a Unix system was Caldera Linux in 3 or 4 floppy disks.
What call me attention the most compared with other embedded OS was the transparency of the system. We all had our door-stop manuals 10 lbs weight manuals for our embedded OS documentation where a collection of tools like Tornado (In VxWorks) gave us a way to interact with the OS. But Unix, in my understanding, needed no added tool. A kernel, a filesystem a shell... go.
Many years a go a developer tried to introduce a patch in Linux to give graphics a leg up because Linux PC Desktop experience lagged behind Windows and Macs. The gate-keepers said no and the guy forked the kernel and went his own merry way.
Going back to embedded real-time systems and Unix/Linux efforts like MonteVista and HardHat created smaller leaner footprints that started competing in the embedded field. The OS evolves wells. My lasts embedded projects with Yocto make the point.
Unix/Linux, ideas that evolve.
You know what, although I experimented with Lasermoon Linux/FT on CD in ~1996, and tried and failed to install Slackware 3.0 around then, the first Linux I ran as my daily desktop OS for a while was Caldera OpenLinux 1.
Your memory deceives you: it came on a CD. It needed 3 or 4 boot diskettes to get to the point where it could find your CD drive and start the installation process.
It had the first graphical installation in the Linux world, and while it wasn't a live environment and had no desktop, it did multitask: you could play Tetris while it installed.
The Unix way is "in-band", where metadata (for telephony: signaling) is in the same stream (channel) as the data. It makes reinvention (upgrading) of the shell super difficult. Nobody can even agree precisely how to (for example) include column headers in a CSV stream.
The other way is "out-of-band", where metadata/signaling is done in a parallel channel. Newer shells can try to approximate this by using JSON when the pipeline is appropriate.
I kinda wish the latter (OOB) had taken hold back in the day.
I'm a little worried this encourages ignoring things that have been learned recently. But it is very hard to not be annoyed when you realize how much ground was covered early on.
This needs to be corrected. Two Chinese centOS distros passing the Unix test does not make all of Linux and its distros "Unix".
If one distro can pass the test, then in principle, any distro can.
If two distros passed, then it is case closed.
The entire point of the argument is not "can Linux pass?" but "will anyone pay to put Linux through the test?" And the answer is yes, repeatedly, although not any more, and who can blame them.
Unix has meant "passes the compatibility test" for ⅓ of a century. Linux passed. Once a Unix, always a Unix. It's Unix.
FWIW the time to protest was a year ago when I wrote the "Unix is dead" story. Here was the brief discussion:
https://www.opengroup.org/membership/forums/platform/unix
>The specification encompasses the base operating system environment, networking services, windowing system services, and internationalization aspects and programming languages.
I am not saying "all distros have passed." They haven't.
I am saying "all distros _could_ pass, if anyone cared enough to pay."
Do you think you can falsify that?
https://www.theregister.com/2024/02/21/successor_to_unix_pla...
But what I am proposing is a way to bring mainstream Unix apps to it, without bloating it with emulation.
No, not everything is a file. Having a somewhat standardised way of accessing certain features in a stream-like way is cool, but it's not the fundamental feature of any unix, it's just a cute piece of user-space. And there's better ways to evaluate a design than aesthetic appreciation.
https://www.theregister.com/2024/02/21/successor_to_unix_pla...
HN post (not mine, I was too slow):
As the saying once went: tune in next time for next week's exciting episode!