
There is only one OS, and it’s been obsolete for decades - juancampa
https://programmingmadecomplicated.wordpress.com/2017/08/12/there-is-only-one-os-and-its-been-obsolete-for-decades/
======
russellbeattie
There are two common situations for developers: Encountering a software
project for the first time, and the opposite, developing a project from
scratch and then maintaining it.

In the first situation, you start going through the sources and see all the
oddities, areas with questionable functionality, outdated techniques, and
places where there _must_ be better ways to implement a solution than the
crazy spaghetti code you're looking at. Many inexperienced developers think,
"Trying to figure this all out is a waste of time... I could write the whole
thing from scratch faster than modifying this monstrosity."

Then there are those developers who have created said projects and understand
the reasons behind all the craziness under the covers. Like a battle plan, no
software project encounters the real world unscathed and unchanged: Edge cases
pop up, bugs in other systems need to be worked around, features outside the
original scope were added, limitations of current hardware or libraries needed
to be accounted for, etc.

This article is written from the perspective of the former: "God, what a mess!
What is all this crap?? Text files and consoles and all this other junk is
horrible!" The fact is that every piece of software is filled with this stuff,
down through every layer in the stack, and that's never going to change until
humans are no longer involved in the process. If you sent this article to
Linus Torvalds, he'd read about four lines, realize the author doesn't know
what he doesn't know and dismiss it all out of hand.

------
smacktoward
_> Consider the three operating system families we are forced to choose from:
Windows, Apple, Other (which I shall refer to as “Linux” despite it
technically being more specific). All of these are built around the same
foundational concepts, those of Unix._

Wait, what?

Linux and macOS, OK, sure, they are based in varying degrees on Unix. But
_Windows?_ Windows has no appreciable Unix heritage. The DEC roots of the
people Microsoft hired to develop Windows NT mean that modern Windows has some
similarities to systems like VMS, but VMS isn't Unix and never was.

 _> Oh, wait a minute, this is still the only way we can get anything done in
the world of programming! Typing textual orders into a “terminal” or “console”
application—nothing more than an emulator for the teletype!!_

On _Windows_? What?

 _> 3\. “Everything is a file”_

...

 _> 4\. An obsession with unstructured text_

The only thing I can figure here is that the author is familiar with Macs and
Linux, where these assertions are all true, and is just assuming that they
must therefore be true on Windows as well. Where they very much _are not._

Windows has had some convenience features layered on top of it to make it more
comfortable for people familiar with Unix to use, but deep down in its lizard
brain it is very much _not Unix_ and was built around a completely different
set of assumptions. Windows doesn't assume everything is a file, interprocess
communication in Windows has never been about piping text between processes,
Windows has been GUI-first rather than terminal-first from Day Zero, et cetera
et cetera et cetera. It's just a completely different thing than Unix and
Unix-derived systems like Linux and macOS.

One can argue that this is a strategic weakness for Microsoft, as the world
(especially among developers) has more or less settled on Unix as the One True
Way to Write an Operating System, and thus the more different Windows is from
Unix the harder it becomes for them to sell Windows to people. But listing all
the legacy baggage that Unix-derived systems haul around with them and then
saying "oh yeah, Windows has all that junk too" is just incorrect on a
fundamental level. Windows carts around plenty of legacy baggage of its own,
but none of it has much to do with teletypes or text pipes.

~~~
JdeBP
The author got a number of things wrong, but the thing that has surprised you
is one of the few that xe actually got right. The handle-based API and
subdirectories, introduced in MS-DOS version 2, were both Unix concepts added
to MS-DOS that remained in DOS+Windows and in its successors OS/2 and Windows
NT. (This wasn't the only Unix concept to cross to the IBM+Microsoft world.
32-bit OS/2 even changed to keeping system time the same way that Unix did,
with a 64-bit count of seconds since the Epoch.) Command pipelines were right
there in MS-DOS 2, as well. Peter Norton wrote a chapter about them in his
_MS-DOS and PC-DOS Users Guide_ in 1984.

Ironically, the thing that _you_ have got wrong, in your turn, is your
assertion that "an obsession with unstructured text" is _actually true_ of
MacOS and Linux in the first place. Most textual data files in such operating
systems are in fact structured into records and fields; many data files
(especially on the BSDs with termcap, the account database, and various others
being Berkeley DB files) are _not_ text at all; and there has been one
particular database (the login database) that has not been text since 1BSD and
Research Unix version 7.

------
cwyers
> Consider the three operating system families we are forced to choose from:
> Windows, Apple, Other (which I shall refer to as “Linux” despite it
> technically being more specific).

> All of these are built around the same foundational concepts, those of Unix.

> Android sits atop the Linux kernel, with iOS (as well as Mac OS) atop Darwin
> (dunno about Windows Phone, but it doesn’t matter). Linux and Darwin are
> both descendants of Unix. _Windows also bears many similarities to Unix,
> possibly through it, but whether there is a dependency does not affect the
> point. To me, the key effects of this monopoly are as follows._

And we're done here. Thanks for playing, close the door on the way out.

~~~
IshKebab
Yeah he dismissed Windows way too easily, but some of his later points still
hold for Windows. The terminal still sucks (though Powershell at least tries
to modernise it a bit). It still uses processes and files in basically the
same way Unix does. The most common interface between programs is still the C
ABI.

It doesn't have the obsession with unstructure text, which is nice.

~~~
JdeBP
It is a mistake to call it "the terminal". Consoles are not terminals.

It is a regular thing for Linux/Unix people to talk about making a "better
terminal". The irony of your talking about Windows in terms of "the terminal",
is that pretty much all of the ideas that people put forward for making a
"better terminal" have actually been done, decades since, in the worlds of
MS/PC/DR-DOS, OS/2, and Windows NT. OS/2 version 1.0 had the MOU, KBD, and VIO
subsystems, which introduced device independent input event streams, 2D screen
buffer addressing, a handle-based API, and API calls rather than escape and
control sequences. Windows NT took this further into the Win32 concept of a
_console_.

* [http://jdebp.eu./FGA/tui-console-and-terminal-paradigms.html](http://jdebp.eu./FGA/tui-console-and-terminal-paradigms.html)

Command-line interpreters are not terminals, either. Powershell doesn't
modernize "the terminal".

* [http://jdebp.eu./FGA/a-command-interpreter-is-not-a-console....](http://jdebp.eu./FGA/a-command-interpreter-is-not-a-console.html)

And the most common interface between programs has never actually been the C
ABI, not on DOS, not on OS/2, nor on Win32/Win64. The most commonly used
convention has to be the one used by applications softwares to make system
calls. Thus the most common calling convention on 16-bit OS/2 and Win16 was in
fact the (Microsoft) Pascal calling convention. 32-bit OS/2 and Win32 used
different calling conventions, APIENTRY and WINAPI, that still weren't the
ones used by plain C functions unadorned with calling convention specifiers.

* [http://jdebp.eu./FGA/function-calling-conventions.html](http://jdebp.eu./FGA/function-calling-conventions.html)

------
xfer
> Unstructured text is not the only way even to do language, let alone
> software construction

A language is not unstructured text, then it would not be called a language.

Seems like a article full of complaints(that is already well-known to be not
the ideal thing) and propose no alternatives.

------
jstewartmobile
This guy probably doesn't know hardware.

C succeeded in part because, in many problem spaces, it was easier to write
"portable assembly" than it was to bridge the semantic gap between higher
languages, like LISP, and typical ISAs.

All of this Bret Victor cultistry is a grandchild of B5000 design. Want better
software, need better hardware.

Maybe with the end of Moore's Law, we'll start making better hardware...

------
oneweekwonder
Why does his teletype comments miss TUI tools like tmux, vim, midnight
commander?

I feel if he acknowledge these tools some of his arguments fall flat.

There a reason why there is no real alternative to TUI's. Because all of them
suck. Even Microsoft back-peddled with powershell so that Windows have better
tui support.

I want to use TUI tools like ssh and tmux. For the power it gives me, and the
low usage of bandwidth, that gives a better response time then most GUI tools.

"UNIX is very simple, it just needs a genius to understand its simplicity." ~
Dennis Ritchie

~~~
xfer
gui doesn't necessarily mean you have to update bitmaps over network to be
responsive. It could be done in a protocol(just like ssh is) for low
bandwidth/latency usage.

~~~
qznc
That was X11. A minimal but extensible protocol which survived many decades
and successfully adapted through generations of hardware. Over time people
created abstractions over it (Gtk,Qt,etc) such that X11 was limited to update
bitmaps over network to be responsive. Now X11 will be replaced by Wayland on
Linux.

------
PaulHoule
The question of why text user interfaces are difficult is an interesting one,
but I think boils down to "Why can't you have a conversation with a computer
like you do with a person?"

Graphical user interfaces bypass some of those issues with direct manipulation
but I don't think people have an easy time learning how to use complex GUI
applications. Before the smartphone I remember 1000 page books about how to
use Microsoft Word and lately graphic designers are starting to realize that
"It's not just me, Photoshop really is hard to use."

The big difference between computers and humans is that computers tend to
require you to formulate inputs in a specific way and that they don't tolerate
ambiguity. Early programming languages such as COBOL and Perl had highly
complex grammars that most developers today have an aversion to. (For instance
almost everybody things that "unless" and "ACTION if CONDITION" in Perl is
stupid; even though natural languages are that way.)

Closely related to that is the "namespace problem" which boils down to an
inability to create a unique meaningful name for every concept (ex. function,
variable name, file, ...) that somebody might want to refer to. People let you
use ambiguous words and will usually guess what you mean correctly, if they
aren't sure they usually know they aren't sure and will ask clarifying
questions.

The trouble w/ making programs that can do that is now you are dealing with
something that doesn't necessarily have a right answer or we don't know what
it is. My experience is that (despite what many of bosses have thought) it can
be a lot harder to make something that has to be 99.9% right as opposed to
100% because you might find that there is some 0.001% case where you think you
can tolerate an error but no... If you work out the math for something to
where you can define what correct is, it might take a while to think through
and implement but the task is finite. On the other hand there is no limit to
how much time you can spend screwing around and going in circles.

~~~
perl4ever
The aspects of Perl you mention are trivial bits of syntactic sugar, that
don't add significantly to complexity and don't prevent you from using the
idiom other languages do. Saying "everybody" thinks they are stupid is begging
the question as much as if you dismissed the ternary operator that way.

Also, Perl and COBOL originated almost 30 years apart, so grouping them
together as "early" languages is peculiar. If Perl is "early", then are C,
C++, and Java also?

------
finnthehuman
There is no running from the context of what came before. Everything new will
be understood in context of the old paradigm.

The two will combine to create the paradigm we look at the next new thing.

You can propose your replacements, we can shed our vistigal features. No
matter how much things change, it’s impossible to make a clean break.

------
ecliptik
Reminds me of The Unix Haters Handbook, can't tell if this is serious or
modern-day-parody though.

\- [https://en.wikipedia.org/wiki/The_Unix-
Haters_Handbook](https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook)

------
undoware
The preëminence of the Unix Way did not arise in a vacuum. It arose by Unix
winning out, again and again, against better-funded, more 'modern' solutions,
each of which has aged a lot less well than Unix itself.

Simplicity is a positive virtue, not just a negative one. Having everything be
'just files', or compile to something that is C or C-like, and having an API
that is still mostly usable on an actual TTY, are actually great, wondrous
things to programmers dealing with cognitive load. Aside from projects that
are essentially refinements of Unix -- Plan 9 and Fuchsia, for example -- I
haven't seen anything that provides remotely as powerful an idiom. But then
again, I haven't been looking. Because Unix already meets my needs just fine.
It is Good Enough.

Yet there has been no shortage of attempts to do better, and they were almost
all unanimously terrible. Remember how much fun it was locking handles in
MacOS 7, before you could reliably play with stuff on the heap? Yeah, you
probably don't. But I do. It sucked. But TBTB told us Pascal and 'cooperative
multitasking' (ha!) were in; that it was gauche to touch a terminal; and that
the future was remote procedure calls. Shortly thereafter, the future was OLE,
or maybe CORBA, or maybe the JVM. It didn't really matter what the future
actually was -- the message was always, 'C is dead, UNIX is dead, long live
____'. And here I am, unironically typing you this message on El Capitan, atop
a Unix kernel, with about five terms behind the browser window, in the year of
our lord 2018.

What is dead can never die. :)

Thus I'd argue that unix, and all its anachronisms, comprise the little black
dress of informatics -- always in fashion.

I'd argue that is in fact deeper than that; it's an ideology; specifically, it
is what I would call 'anarchist', but you might call 'decentralist' or even
'libertarian'.

Either way, I'm keeping it. I'm probably still more in love with Unix than I
will ever be with any human.

P.S. also Vim called and reminded you visit Eclipse in the Old Prog's home.

~~~
oneweekwonder
> But TBTB told us Pascal and 'cooperative multitasking' (ha!) were in;

Sorry I searched for "TBTB told us Pascal" and no real info popped up, except
for some NSFW videos. What is TBTB?

Otherwise I agree with most of what you said; UNIX is dead, long live UNIX.

~~~
undoware
'The powers that be'. Even the abbreviations we use these days are different.
:) Younger people don't understand me when I say 'IANAL' or even 'IIRC', which
is a shame, IMHO.

Hot grits and Natalie Portman forever. _flashes Slashdot gangsign_

~~~
berbec
I think the confusion comes from not typing TPTB

~~~
undoware
oh snap!

------
api
Like most such critiques this is thick on criticism and thin on alternatives
or solutions.

~~~
tylershuster
See: Urbit

~~~
oneweekwonder
Urbit on github[0] with 90% of its code written in c?

C was one of the first problems the author had in the blog post.

[0]: [https://github.com/urbit/urbit](https://github.com/urbit/urbit)

~~~
tylershuster
Urbit currently runs on top of Unix, so yeah that repository will be mostly C.
If you look up the project on its website, you'll see it runs in three new
languages that solve the problems the author talks about.

------
maxk42
More C hate.

