[systemBuilder]

This is a tongue in cheek but also piece of shit MIT propaganda piece mostly written by the clowns who created the abortions that were Multics and LISPMs. Like as if every software engineer should start their next project by warming up their soldering irons to add obscure new features to their CPU's!

I know because I attended that school and worked with the fathers of Multics. The sad fact is that MIT produces extreme bloatware that nobody understands nor needs (gnu emacs cough cough). MIT has almost ruined unix with bloatware like 'configure' and gcc 'extensionettes'. The repeated rant about memory mapped files (a Multics bedrock feature) has been refuted as showboating hundreds of times by OS designers like my manager at Xerox OSD, the designer of Pilot, and an ex-MIT professor who never drank that Kool aid!

What's happening in OS's right now is that European bloatware is strangling Linux ... The reason Unix got people so thrilled is that it could 'terminate and stay resident' in one single human mind!

[musicale]

Nice rant, systemBuilder. ;-)

Say what you will about Multics, but it had essentially "no buffer overflows" [1], simply because it was written in a more memory-safe language (PL/I). (The stack also grew upward rather than downward iirc.)

It also had several nice features that I wish UNIX/Linux hadn't forgotten, even simple ones such as long names for commands (e.g. list-segments in addition to the 'ls' abbreviation.)

"Thirty Years Later: Lessons from the Multics Security Evaluation (2002)", https://news.ycombinator.com/item?id=16956386

[delish]

> This is a tongue in cheek but also piece of shit MIT propaganda piece mostly written by the clowns who created the abortions that were Multics and LISPMs.

Sure--the people who wrote systems with opposing philosophies to the "unix philosophy" are going to be the ones who write this book. And that they failed-in-the-market ("abortions") is already evident by the fact that HN is probably majority unix (mac) or unix-like (linux).

I confess I'm one of those people who has never used a lisp machine, and admires them greatly. I'd love to hear specific reasons I shouldn't admire them.

[systemBuilder]

LISPms, Multics, Symbolics machines all run instances of software that depended upon custom instructions, tailored precisely for the languages which they executed, and could not be ported to any other machine.

[vermilingua]

Given that you're so opposed to custom instructions, I'm sure you also abstain from using x86, ARM, etc. which all now include custom in silico instructions for decoding, crypto, etc.

Keep fighting the good fight, comrade.

[mruts]

OpenGenera was ported to ALPHA64. Also, a VM exists for Linux/OSX. It works pretty okay.

https://github.com/ynniv/opengenera

you first have to get the opengenera sources, though. But they aren't hard to find.

[pjmlp]

That abortion called Multics was assessed by DoD as not having any of the memory corruption security exploits that plague UNIX to this day.

[cyberpunk]

I'll assume you're talking about systemd here? How is linux being strangled? How is it Europe's fault? As far as I can see linux is booming and almost ubiquitous as far as backend OS's go...

[systemBuilder]

Operating systems reflect the cultures that created them. UNIX was a reaction to the enormous overcomplexity of Multics and other operating systems (OS/360) of its day. One file type, one record type ("THE BYTE"),one device driver model, NFA research (~1 pattern language vs zero in other operating systems) and a way to plug together pipeline programs on the command line not seen before.

UNIX succeeded precisely because it was powerful and yet so simple a person could read any part of it and change it.

However, the kernel of UNIX is now beyond ken for most developers precisely because the developers pursued complexity and marginal features for marginal benefits, something very common in European governments and a part of that culture.

The shell commands went from maybe 50kloc to millions of lines precisely because the Linux developers were desperate for contributions and let MIT bloatware people control that part of the source code, strangling Linux with MIT culture.

[cyberpunk]

Kernels do a lot now that they didn't used to. I'm not sure what marginal features you're talking about, can you share some with us? The ABI may look the same as it was in the 1990's but thing under the hood have gotten a lot smarter, and that smarts requires more code.

As for userland.. Even OpenBSD, my personal preference of operating system and one which is known for its 'lean'ness of base userland has 10x this kloc in /bin/ and /usr/bin:

  # find bin usr.bin | egrep '\.c$|\.h$' | xargs wc -l | tail -1
    689562 total

Coreutils, by comparison:

   coreutils$ find . | egrep '\.c$|\.h$' | xargs wc -l | tail -1
     91991 total

(The difference is because coreutils doesn't contain everything obsd's /bin and /usr/bin does I suppose, openssh, tmux etc)

Either way, that's not a mad amount of code imo... Which parts of this are 'MIT bloatware' ?

[darkpuma]

> "How is [systemd] Europe's fault?"

The only way that makes sense is if they're referring to Lennart being German, but that's kind of a bullshit argument because SystemD was not some novel idea; launchd was around first and came from the American west coast.

[f2f]

counterpoint: launchd works.

[dbdjfjrjvebd]

What doesn't work about systemd?

[0w4u2a]

I liked the idea of systemd because I love launchd and I always thought it was the best approach.

After years of dealing with systemd, I've finally given up on it, and I'm back on openrc.

(Yes, I know I'm not answering your question, but I'm not up to the task... ;P)

[systemBuilder]

No this is not a rant about systemd. The idea behind UNIX was a small set of lego building blocks that could be plugged together to construct something way larger than the parts themselves. The idea in Linux is that once you become an open source contributor more software is always better and more features is always better and hey why doesn't everyone build a monolith with 150 subcommands, which does not interoperate with any other software, and this describes most of the software built for Linux in the past 10 years.

[systemBuilder]

I once worked on a project at Qualcomm and wondered if the head had any idea what he was doing. I went to him and asked what is the complexity of a change you are willing to put up with for a 1% increase in cellular sector throughput. He had no idea. I should have quit the next day. The project was a commercial failure (802.20). Too big and late to market. Same problem that killed CISC machines. Most Linux developers never think in these terms and hence, long term, Linux is dead.