Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

web.mit.edu

141–150 of 163 posts

Re: The Unix-Haters Handbook (1994) [pdf]

#141

Earlier quoted context omitted.

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...

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 becau…

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' ?

Re: The Unix-Haters Handbook (1994) [pdf]

#142
post #38

I founded the mailing list the book was based on. These days I say, Unix went from being the worst operating system available, to being the best operating system available, without getting appreciably better. (which may not be entirely accurate, but don't flame me). And still miss my Lisp Machine. It's not that Unix is really that bad, it's that it has a certain model of computer use which has crowded out the more am…

Do you have any suggested reading to learn more about the more ambitious visions from the 70s and 80s, and why they didn't pan out?

There hasn't been much written on the Lisp Machines that I know of. Alan Kay's History of Smalltalk might be a good place to start, the LispM owed a lot to earlier work done at PARC: http://worrydream.com/EarlyHistoryOfSmalltalk/

Re: The Unix-Haters Handbook (1994) [pdf]

#144

Earlier quoted context omitted.

Do you have any suggested reading to learn more about the more ambitious visions from the 70s and 80s, and why they didn't pan out?

Well in some cases it was because conventional hardware caught up. When I arrived at my first job in 1998 we were using Symbolics Lisp machines. Two years later we were using TI microexplorer Lisp cards that were hosted in a Mac IIFx (something like [0]). When I left, two years after that, we were running Procyon Common Lisp on the IIFx itself, with no Lisp co-processor. The old Symbolics machine was booted up occasi…

Too late to edit - 1998 should be 1988.

Re: The Unix-Haters Handbook (1994) [pdf]

#145

Earlier quoted context omitted.

> But UNIX is so embedded now it would be a purely academic exercise I guess I'm less pessimistic, because I don't think that's true. I think there are quite a few people like me who are fed up with the shit that exists today and really want a good alternative. I think we'd be willing to make quite a few sacrifices for something with a whole lot of potential. What seems to be true is that there are very few people bo…

Do you blog much? I've been lurking here a lot and have seen your posts. Would be interested in long-form essays or the like on what you would like to see.

I blog a little under my actual name, but I'd rather not tie that to this identity lest it make me less willing to express my stupidest and least popular opinions here, which I feel need to be exposed to criticism so I can better judge their merit. There's a reason my handle is what it is.

Re: The Unix-Haters Handbook (1994) [pdf]

#146

I think the success of Unix is much better explained by "Worse is Better" than the modularity/composability of little utilities called the Unix philosophy.

And DOS was a lot worse than Unix.

I love DOS and how utterly terrible it is :)

Re: The Unix-Haters Handbook (1994) [pdf]

#147
post #125

Earlier quoted context omitted.

Rereading the section on NFS again, I suddenly realize that I was foolish to have skipped it as out of date. Since my last read I have encountered some incarnation (heh) of every single one of the problems listed in that chapter. I'm betting v4 isn't much better either. Is there a good network file system solution!?

Lustre.

Any thoughts re: the comments here [0] about usability for smaller workloads?

0. https://news.ycombinator.com/item?id=14165785

Re: The Unix-Haters Handbook (1994) [pdf]

#148
post #139
post #85

Earlier quoted context omitted.

> And still miss my Lisp Machine[...] This all happened before my time, but having read a lot about the Lisp Machine I'm as interested in the what-ifs of history if it had won out as the next guy. I wonder though how much of the legitimate sentiment in this book is simply raging against a machine that's successful and installed in production. Given widespread commercial use a system where you could modify the running…

I really like the concept of Lisp, but just plain find it too hard to read. Part of the problem is that small-scale groupings too closely resemble large-scale groupings. In most production languages, "big blocks" are visually different than "small blocks" (or groupings). For example, in C, parameter statements are grouped within parenthesis. Large scale groupings are done with curly braces. This provides visual cues…

> This provides visual cues about scope and intention without first reading each token.

There isn't even a token to read in C. You have to infer what it is by parsing the thing in your head. Well, our visual systems have no problems doing this.

The C function definition doesn't have an operator which would help me to identify what it actually is.

  float square ( float x )
  {
    float p ;
    p = x * x ;
    return ( p ) ;
  }
Where in Lisp we have this operator based prefix syntax:

  (defun square (x)
    (* x x))
Oh, DEFUN, short for DEFine FUNction, it's a global definition and it defines a global function.

Or with types/classes:

   (defmethod square ((x float))
     (the float (* x x)))
Oh, DEFMETHOD, DEFine METHOD, so it's a global definition of a method (kind of a function).

The names and lists may not tell you much, but to a Lisp programmer it signals the operation and the structure of the code, based on typical code patterns.

Once we learned basic Lisp syntax this is the usual pattern for definitions:

    
    
Most definitions in Lisp follow that pattern. Function definitions extend/refine this:

    
    
    
    

Code then has a layout which is always similar - since the layout is hardwired/ supported in editors and Lisp itself (via the pretty printer, which prints code to the terminal according to layout rules).

> block structures (if, while, try, etc.) are pretty much hard-wired into the language so they stay consistent

These are also hardwired in something like Common Lisp. But the general language is differently designed. Common Lisp has relatively few built-in basic syntactic forms (around 30) and the other syntax is implemented as macros.

> It's great if you are the lone reader: you can customize it to fit your head

Over the decades of Lisp usage a bunch of conventions and some language support for common syntactic patterns have emerged. It is considered good style to follow those patterns.

> But, other readers may not agree with your head's ideal model, or learning it adds to the learning curve of a new shop.

That's the same problem everywhere: the new control structure implemented as a Lisp macro is the new control structure in any other language implemented by a bunch of different tools (macros, preprocessor macros, embedded languages, external languages, a web of classes/methods, a C++ template, ...).

If you add a new abstraction, there is always a price to pay. In Lisp the new language abstraction often gets implemented as a new macro and may hide the the implementation behind a more convenient form.

Re: The Unix-Haters Handbook (1994) [pdf]

#149
post #38

I founded the mailing list the book was based on. These days I say, Unix went from being the worst operating system available, to being the best operating system available, without getting appreciably better. (which may not be entirely accurate, but don't flame me). And still miss my Lisp Machine. It's not that Unix is really that bad, it's that it has a certain model of computer use which has crowded out the more am…

Do you have any suggested reading to learn more about the more ambitious visions from the 70s and 80s, and why they didn't pan out?

Book: The Architecture of Symbolic Computers. Peter M. Kogge.

From Symbolics (Overview + Technical Summary):

http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/h...

http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/3...

Texas Instruments, Technical Summary

http://bitsavers.informatik.uni-stuttgart.de/pdf/ti/explorer...

Xerox Interlisp-D Friendly Primer

http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/inter...

Re: The Unix-Haters Handbook (1994) [pdf]

#150

Earlier quoted context omitted.

Do you have any suggested reading to learn more about the more ambitious visions from the 70s and 80s, and why they didn't pan out?

Well in some cases it was because conventional hardware caught up. When I arrived at my first job in 1998 we were using Symbolics Lisp machines. Two years later we were using TI microexplorer Lisp cards that were hosted in a Mac IIFx (something like [0]). When I left, two years after that, we were running Procyon Common Lisp on the IIFx itself, with no Lisp co-processor. The old Symbolics machine was booted up occasi…

Lots of people used Macintosh Common Lisp on Macintosh IIFX machines and later. The 68030 in the FX also enabled a better garbage collector for MCL.
Post reply on HN