20 ms·

The Unix-Haters Handbook (1994) [pdf]

• valarauca1 10y ago
  This is a good read. Especially if you use Linux/BSD/OSX on a fairly regular basis. While it is mostly long usenet rants about the _failure_ of Unix. There is some grains of truth buried in 80's-esque proto-shit-posting.
• grabcocque 10y ago
  If I ever need to feel good about myself as a software developer, I only ever need to read this book's chapter about the X window system.
  • xyzzy123 10y ago
    Yeah but try and figure out how you'd do better... efficient.ly. Over the network...
    • _pmf_ 10y ago
      Yes; the chapter actually made me admire the design.
      • tdsamardzhiev 10y ago
        The whole book was like that for me. I think that's what it's all about - our love/hate relationship with Unix(-like systems).
    • panic 10y ago
      The contemporary windowing system NeWS is worth a look: https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS Its architecture was more similar to modern web apps, with the UI running code and processing events on the client machine.
      • xyzzy123 10y ago
        Ohhhhhhh good answer. One day it'll win :) Actually I think we could do NEWS in JS. Somehow I don't feel that would make you happy tho :P
        • DonHopkins 10y ago
          Does AJAX make you happy? https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently: used PostScript code instead of JavaScript for programming. used PostScript graphics instead of DHTML and CSS for rendering. used PostScript data instead of XML and JSON for data representation.
      • reacweb 10y ago
        I remember it. It was far prettier than motif at that time. And Framemaker was so pleasant to use compared to Word. Both NeWS and NeXT were using Display Postscript (https://en.wikipedia.org/wiki/Display_PostScript https://en.wikipedia.org/wiki/Display_PostScript). Do you know if NeWS was an inspiration for NeXT ?
        • arethuza 10y ago
          Other than using PostScript for 2D rendering I don't think NeWS and Display Postscript had much in common. In NeWS you could write your client applications completely in PostScript (or something compiled down to PostScript) and it had its own object-oriented, multi-threaded environment with event handling etc. NeWS was more of a predecessor for Java than NeXT.
          • david-given 10y ago
            Here's the source code for the classic PizzaTool demo (BTW, I've just looked on Google Maps, and I think that Tony & Alba's pizza place in Mountain View no longer exists): http://donhopkins.com/home/archive/NeWS/pizzatool.txt http://donhopkins.com/home/archive/NeWS/pizzatool.txt ...and here's a link to a HN thread a few months ago where Don Hopkins talks about Postscript and windowing systems; lots of good links there: https://news.ycombinator.com/item?id=13196983 https://news.ycombinator.com/item?id=13196983
    • bjourne 10y ago
      You can't do opengl efficiently over the network. At least xorg can't. Most applications uses opengl these days. For me, I've been using Linux fulltime for the last 15 years and I have never, not even once, had the need to connect to a remote X11 server. ssh has always been enough for me.
      • pmontra 10y ago
        Maybe you used Synergy to share a mouse and a keyboard over multiple machines. It's a use case that partly overlaps with running remote desktop applications on your display. Or VNC.
      • zeptomu 10y ago
        > Most applications uses opengl these days. Now 'most' is a relative term, but I do not think that's true at all. There are very few applications that use OpenGL. Obviously games are an exception, but if you count in all GUIs I would say mostly target X11 (via Gnome or KDE).
        • bjourne 10y ago
          GNOME and KDE can also use opengl for some tasks if it is available. But right, most applications doesn't directly use opengl. I believe if it weren't such a pita to integrate opengl in desktop appliations (thanks to X11's bad design), many more applications would be using it. To give you an example, think about desktop effects. On Windows, several applications such as Explorer makes parts of their windows semi-transparent. It's a nice simple effect that is impossible (without tons of hackery) to replicate using X11.
          • dfox 10y ago
            https://www.x.org/releases/current/doc/compositeproto/compositeproto.txt https://www.x.org/releases/current/doc/compositeproto/compos... I don't think that this qualifies as "tons of hackery" given the fact that other contemporary UI systems with truly transparent windows implement it in same way (IIRC in pre-Vista Windows truly transparent windows are supported on the OS level but the implementation involves hacks with backing buffer and synthesized expose events).
    • DonHopkins 10y ago
      As it turns out, the web eventually came around to using NeWS's extensible client/server architecture, once they rediscovered it 20 years later and called it "Ajax". (2005 [1] - 1985 [2] = 20) [1] https://en.wikipedia.org/wiki/Ajax_(programming)#History https://en.wikipedia.org/wiki/Ajax_(programming)#History [2] http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm http://www.chilton-computing.org.uk/inf/literature/books/wm/...
      • gonzo 10y ago
        Ha! Yello, Don. Howzit?
        • DonHopkins 10y ago
          Hi Jim! As it turns out, AJAX is immensely popular in Amsterdam, because it's the name of the local soccer team [1]. But they pronounce AJAX like "ah yax", and JavaScript like "ya va schkript"! ;) [1] http://english.ajax.nl/streams/ajax-now.htm http://english.ajax.nl/streams/ajax-now.htm
    • jff 10y ago
      Plan 9 did it in an interesting way. You draw to the screen by writing to files under /dev. On Plan 9, all file operations take place over 9P, a networked file protocol. So if you are connecting to a remote machine and want to run a graphical program, you mount your local /dev/draw files on the remote end (this is actually taken care of automatically by cpu(1)) and just run the program. Its graphical functions access your local machine's /dev/draw and it all Just Works. Hard to explain but very neat when you use it.
      • mej10 10y ago
        How was it efficient?
        • jff 10y ago
          I don't have numbers but in general I'd call it no less usable than X forwarding over ssh. For a long time I used to connect to a Japanese Plan 9 server using drawterm (a Windows/Linux application which essentially emulates the /dev/draw infrastructure) and it was pretty decent considering the latency--I used it to read email, follow IRC, and write code. Over a LAN, it's so fast as to be indistinguishable from something running on your local machine.
      • DonHopkins 10y ago
        Plan 9's "everything is a file" philosophy never worked for me, because it's far too low level, and I don't believe Unix's file I/O API itself is very pleasant: open, read, write, ioctl and select (gag). I'd much rather have a real API with rich app-specific functional or event interfaces to call, and to be able to pass actual typed parameters instead just a stream of bytes, including structured data like json, s-expressions or PostScript data, or even (gasp) Turing complete programs, like PostScript code! NeFS, as defined in 1990 in the infamous NFS3 proposal aka "Network extensible File System Protocol Specification" did just that, and it was actually a great idea too early for its time. So it went over like a lead balloon, and was never actually adopted. NeFS should not have been framed as a successor to NFS, because it required a revolution in how programs interacted with the file system. And of course there are the security and stability implications of running downloaded code in the kernel, which hadn't been properly addressed. ;) Take for example (shown below) the act of copying a file to a backup file in the same directory. With traditional NFS, the server would have to send each block of the file to the client, which would then send it back to the server, which would then write it to disk. That required a lot of network traffic, as well as many context switches between user and kernel space on both the client and the server (at a time in history where they were extremely expensive). Instead, the client could just send a simple PostScript program to the server (or call one that was loaded from a library or sent previously -- see the example below), which copied the file in the kernel of the server, without sending it over the network, or requiring any context switches on either the client or server. That's several orders of magnitude more efficient in terms of both CPU and network usage, and just the simplest and easiest to explain example possible of what you could do. Just imagine how much more efficient, powerful and tightly integrated together other utilities like "find" and "grep" could be, tightly woven together procedurally in the kernel instead of communicating with a stream of bytes over a pipe! http://www.donhopkins.com/home/nfs3_0.pdf http://www.donhopkins.com/home/nfs3_0.pdf Introduction The Network Extensible File System protocol(NeFS) provides transparent remote access to shared file systems over networks. The NeFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This document is the draft specification for the protocol. It will remain in draft form during a period of public review. Italicized comments in the document are intended to present the rationale behind elements of the design and to raise questions where there are doubts. Comments and suggestions on this draft specification are most welcome. 1.1 The Network File System The Network File System (NFS™*) has become a de facto standard distributed file system. Since it was first made generally available in 1985 it has been licensed by more than 120 companies. If the NFS protocol has been so successful why does there need to be NeFS ? Because the NFS protocol has deficiencies and limitations that become more apparent and troublesome as it grows older. 1. Size limitations. The NFS version 2 protocol limits filehandles to 32 bytes, file sizes to the magnitude of a signed 32 bit integer, timestamp accuracy to 1 second. These and other limits need to be extended to cope with current and future demands. 2. Non-idempotent procedures. A significant number of the NFS procedures are not idempotent. In certain circumstances these procedures can fail unexpectedly if retried by the client. It is not always clear how the client should recover from such a failure. 3. Unix®† bias. The NFS protocol was designed and first implemented in a Unix environment. This bias is reflected in the protocol: there is no support for record-oriented files, file versions or non-Unix file attributes. This bias must be removed if NFS is to be truly machine and operating system independent. 4. No access procedure. Numerous security problems and program anomalies are attributable to the fact that clients have no facility to ask a server whether they have permission to carry out certain operations. 5. No facility to support atomic filesystem operations. For instance the POSIX O_EXCL flag makes a requirement for exclusive file creation. This cannot be guaranteed to work via the NFS protocol without the support of an auxiliary locking service. Similarly there is no way for a client to guarantee that data written to a file is appended to the current end of the file. 6. Performance. The NFS version 2 protocol provides a fixed set of operations between client and server. While a degree of client caching can significantly reduce the amount of client-server interaction, a level of interaction is required just to maintain cache consistency and there yet remain many examples of high client-server interaction that cannot be reduced by caching. The problem becomes more acute when a client’s set of filesystem operations does not map cleanly into the set of NFS procedures. 1.2 The Network Extensible File System NeFS addresses the problems just described. Although a draft specification for a revised version of the NFS protocol has addressed many of the deficiencies of NFS version 2, it has not made non-Unix implementations easier, not does it provide opportunities for performance improvements. Indeed, the extra complexity introduced by modifications to the NFS protocol makes all implementations more difficult. A revised NFS protocol does not appear to be an attractive alternative to the existing protocol. Although it has features in common with NFS, NeFS is a radical departure from NFS. The NFS protocol is built according to a Remote Procedure Call model (RPC) where filesystem operations are mapped across the network as remote procedure calls. The NeFS protocol abandons this model in favor of an interpretive model in which the filesystem operations become operators in an interpreted language. Clients send their requests to the server as programs to be interpreted. Execution of the request by the server’s interpreter results in the filesystem operations being invoked and results returned to the client. Using the interpretive model, filesystem operations can be defined more simply. Clients can build arbitrarily complex requests from these simple operations. [...] Example: Copy a File Make a copy of file (foo) called (bar). Both files exist in the same directory dfh. The request starts by looking up the filehandle for the file to be copied and creates a filehandle for the copy. The loop operator executes a procedure that copies the file using 1K reads and writes. It maintains a running count of the number of bytes yet to be copied. % Copy a file % dfh (foo) lookup /foofh exch def % get filehandle for (foo) dfh (bar) create /barfh exch def % create filehandle for (bar) /bytes foofh getattr /fsize get def % get size of (foo) so we know how much to copy /offset 0 def % initialize offset for (bar) { /data foofh offset 1024 read def % read up to 1K from (foo) barfh offset data write % write up to 1K to (bar) /bytes bytes 1024 sub def % decrement byte count by 1024 bytes 0 le { exit } if % if it’s < 0 then we’re done /offset offset 1024 add def % increment offset by 1024 } loop barfh getattr 1 encodereply sendreply % return the attributes of the new file to client.
  • tatoalo 10y ago
    "If the designers of X Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles—but you’d be able to shift gears with your car stereo. Useful feature, that."
  • pjmlp 10y ago
    Everyone that dislikes Win32 should program directly with Xlib and Athena, and rejoice of the experience.
    • gruez 10y ago
      Why?
      • pjmlp 10y ago
        I doubt there is any worse UI tooling available.
        • noobermin 10y ago
          Than win32!? Are you serious? Xlib is pretty bad but win32 is absolute bonkers. Or are you saying the opposite?
          • pjmlp 10y ago
            Of course I am serious. I do UI coding since Amiga 500 days and never found so borked API, with more parameters and configuration structures than Xlib, without any support for printing or proper use of fonts. The amount of wasted hours of my life using xlsfonts.... And those bare bones widgets, yet another headache.
            • tankenmate 10y ago
              And yet Xlib ran happily on machines with 4MB of RAM and would only use 512K of that; mind you that was X11R3. I used to run this very config on Apollo Domain/OS machines in 1990.
              • pjmlp 10y ago
                The Amiga had 512KB for the whole OS, including a GUI stack way better than X. For us targeting desktop computing, the network features of X were never relevant, what mattered was GUI toolkits for workstation usage, running on the same computer.
  • tragomaskhalos 10y ago
    An office I worked in in the early 90's had a shelf with a ten(?) volume set of X windows books - and each individual book was a thick bugger. I'd only had fleeting experience of it, but remember thinking "how complex can this thing be ?!"
    • pmontra 10y ago
      I remember them. Those were both the guides and the references for the whole X11 ecosystem. I guess many modern pieces of software would be that large if properly typesetted and printed on paper. Luckily we fit them on the web and some thousands of blog posts, stackoverflow and more.
    • arethuza 10y ago
      I think a lot of those books covered stuff that most people writing applications never really had to worry about - I'm pretty sure I got by with one on Xlib and maybe one on Xt?
    • david-given 10y ago
      I remember them --- they were really good. The architecture was layered, too, so you typically only ever used one book at a time. Doing raw graphics operations? All you need is the Xlib book. Xt/Xaw? There's a book for that. Motif? There's a book for that, too, but it wasn't in our set. The raw X protocol was, IIRC, documented in volume 0.
    • mcguire 10y ago
      Much of the mass was printed man pages for every single API call.
    • DonHopkins 10y ago
      I was on Sun's X11/NeWS beta program, and each time they came out with a new release, they'd send me an entire whole new set of X11 and Adobe PostScript manuals! I appreciated it, but had those manuals coming out of my ears! It was great having all those Red Books to pass out at parties, but nobody ever wanted the XView manuals. ;)
• _pmf_ 10y ago
  The question is: what would the ideal non-POSIX API look like?
• appleflaxen 10y ago
  can anyone give a first-hand historical perspective on this, regarding what was going on and how this was seen in 1994?
  • ddebernardy 10y ago
    It was written in an age where there were still plenty of computer options to go around with. On the consumer and small business end, there were DOS/Windows boxes, WindowsNT boxes, and Macs, of course. But OS/2 was still a thing, Win95 was around the corner, and, while on the decline by 1994, Atari and Amiga devices were still somewhat sensible options for e.g. music or gaming a few years earlier. On the corporate end, and more saliently for this specific book, you still had plenty of mainframes and such around, and an equally rich variety of options. Some of these computers were called Lisp machines, and built around Lisp rather than Unix/C. They had started to lose traction after the onset of AI Winter: https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/AI_winter https://en.wikipedia.org/wiki/AI_winter The authors of the book basically are Lisp aficionados who mourn the good old days when they could get by using elegant Lisp machines instead of clunky, user hostile Unix boxes. The book itself is an entertaining read insofar as I can remember. (My memory might be playing tricks on me though; I read it 10-15 years ago.) The authors obviously cherry pick to maximize Unix bashing. The authors make a number of very valid points - some of which still apply today. The tone is usually playful. But then, at times, contempt with a pinch of self-importance emerges, and you're left wondering why you're bothering to continue reading a 300+ page long rant... only to realize that the points made are so obnoxiously valid (or, at least, were when I read it) that you continue. Dennis Ritchie's anti-forward passage return the favor, too: > Your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.
    • appleflaxen 10y ago
      I saw the anti-forward, but missed that quote. Thanks for pointing it out, and for the thoughtful blurb. Great context!
• omginternets 10y ago
  While entertaining, I'm left with the following question: if not UNIX, then what? Are there any successful non-UNIX-y OSes that are worth checking out? I may embarrass myself here, but I was under the impression that BSD, Plan 9, Solaris and HP-UX were all UNIX-y ...
  • CJefferson 10y ago
    I think the important thing to accept is just because something is the best option we have, doesn't mean it couldn't be significantly improved -- I feel each of bash, vim and Emacs fall into this category, in their own way.
    • deleted 10y ago
      [deleted]
  • throwanem 10y ago
    They all are, but this book dates from a time when Unix had nothing like the absolute dominance of paradigm it does now. True, by the early-mid 90s, the Unix model had effectively won - but there remained a very large number of people with fond memories of other platforms, many of which did at least some things better than any contemporary or even modern Unix.
    • omginternets 10y ago
      >there remained a very large number of people with fond memories of other platforms, many of which did at least some things better than any contemporary or even modern Unix. Yeah, that's what I'm curious about. Could you name names? :)
      • walshemj 10y ago
        ITS is often mentioned and I suppose PR1MOS (which was descended from ITS)
        • 10y ago
• 0x264 10y ago
  This book is one of my top three books on how to become a good software dev :)
  • zingplex 10y ago
    Could you name the other two?
    • fao_ 10y ago
      They're for good developers to know and every one else to find out /jk Seriously though, I think almost everyone has a pick of different books that influenced them the most and helped them to become the best developer that they could be, and while most of the time they are contained within a single set of books, it's kind of fruitless to buy books you might not find interesting with the promise of "They will make you a good developer". I have a fair amount of books I find difficult to read because of the style, etc. that I bought with that promise, and none of them improved my programming ability significantly more than a bunch of coding + an internship has. [What I would recommend is finding authors that you like reading andor tend to get a lot from]
    • 0x264 10y ago
      "The Art of Unix Programming" and "Structure and Interpretation of Computer Programs"
• raverbashing 10y ago
  Unix is weird because it evolved organically and without a unified direction. But it remains because power and familiarity beat user experience. Yes, the "pure" Unix tools are awful, GNU improved on their usability a lot. But they're still a simple command that does something. Except Autotools. Those should burn in eternal damnation.
  • pjmlp 10y ago
    Except that GNU is Not UNIX and many companies still have UNIX boxes without GNU on them.
    • dijit 10y ago
      that's not necessarily true as much as you think. I worked in a Solaris shop that had gnu coreutils and packages installed everywhere with a <g> prefix, and another place running openbsd which had the same. gecho, gcat, gln etc; I'm pretty sure gnu coreutils can be built on any Unix-like OS.
      • pjmlp 10y ago
        It depends on the IT guys, I have occasionally sshed into boxes where that wasn't the case and compiling wasn't an option.
        • SSLy 10y ago
          - compile stuff statically on your own hw - base64encode it - paste the encoded text over ssh to a file - base64decode it - chmod +x the decoded file - … - profit
          • pjmlp 10y ago
            - Mount $HOME as noexec - Disable execution bit for all directories for home - If the UNIX variant allows it, jail/contain home for each user session - Punish users or their employer if a consulting firm severely that bypass IT regulations
• open-source-ux 10y ago
  It's interesting that no one blinks twice at the thought of using a decades-old operating system - it's "mature", "battle tested", "proven over time" or some other phrase. On the other hand, programming languages that are decades old are looked upon as antiquated and not fit for modern problems, so we create new languages and discard the old ones, including forgetting useful ideas those languages contained. Sometimes, we come back to some of those ideas. So a dynamic language decides that types are in fact quite useful, and a single exe file is so much simpler to distribute than endless tiny script files, and maybe speed does matter after all. Not passing judgement, just saying that's how it is. And it is rather odd isn't it?
  • PLenz 10y ago
    That's the fundamental difference between infrastructure folks - inherently conservative, keep it running, 9 9s of uptime - and developers - restless, ohhhhh shiny, seekers of the new and novel.
  • tbrake 10y ago
    I think most programming languages that are decades old aren't looked at as 'not fit for modern problems' so much as 'inefficient for modern* development'. Is it possible to do the same things in C that we can in Ruby, PHP or Node? Absolutely. But can it be written in the same time frame? While I'm sure there are HNers out there who can - or who at least claim they can ;) - let's ask ourselves if that's really broadly truthful outside of trivial example applications. I'd wager 'no'. Those higher level languages might 'forget' something in the past and 'rediscover' it but I feel like that's kind of a very minor sub-plot in the larger story of the usefulness of their abstraction and ability to represent more powerful ideas in less lines of code. * - read 'web'. Old and low level languages are still obviously used in a wide variety of projects and industries.
    • di4na 10y ago
      Meanwhile, erlang...
  • problems 10y ago
• deleted 10y ago
  • deleted 10y ago
    [deleted]
• fdupoo 10y ago
  Make sure to read the preface. It is the best preface I've ever read. Pay special attention to who wrote it.
  • scandox 10y ago
    I cannot find a distinct credit for the Preface. Where is it?
    • falsedan 10y ago
      I assume the OP was referring to the Anti-Foreword by Dennis Ritchie.
• Philipp__ 10y ago
  I like to cover myself with some crazy question and think about them. For example, what would look like the thing that would make people go "oh this looks good enough to replace UNIX". Don't get me wrong, I am big fan of UNIX, but I hope I will be alive around the time(but I doubt that) when we will see some new thing which will make UNIX feel dated. Now, some of you might jump and say "Oh, but UNIX already feels dated", and that would make conversation on it's own, but I think people say that more because they are bored with UNIX, or they dislike certain segments. And what breaks my heart is general disinterest in Operating systems with young developers/students (I am student too, but I find those things to be most interesting of all university courses). I see very little people doing OS work today. I wasn't there to see how it was in 80s & 90s, but from what I've read, you had much, much more choice, but their quality was debatable. Why we always consider Operating Systems to be "solved" thing? Is it because the way Von Neumann architecture works, we tend to abstract computer as an entity in the way that gave us UNIX and that we won't be able to discover and make something different but as capable as UNIX without changing our way of thinking about what computer is and how it works? Did we got used to computers as they are, especially newer generations, taking things for granted, and just going forward with what they inherited?
  • beefsack 10y ago
    I just hope that whatever replaces *NIX is still free software. Your computer OS is the last thing that should be controlled by corporate gatekeepers.
    • Philipp__ 10y ago
      That's not even a question.
  • gingerbread-man 10y ago
    Google's Fuschia OS project is intriguing. It's open source, but I haven't been able to find any whitepapers or conference talks about its design or Google's plans for it. The speculation is that they wanted an ultra-lightweight OS for future low-latency augmented-reality applications. (https://news.ycombinator.com/item?id=12271354 https://news.ycombinator.com/item?id=12271354)
• krylon 10y ago
  I think that quite a bit in this book is outdated by now, but it's still a fun read, even as Unix person. Especially the chapter on NFS was a fun read. When I first set up my home server, I had my desktop lock up completely a few times when the server became unavailable, because of NFS. (Then I found out one can mount NFS shares in interruptible mode so the requests will eventually time out... but it was so annoying up to that point.)
  • perbu 10y ago
    -o hard,intr is still in my fingers almost ten years after I quit being a sysadmin.
  • disconnected 10y ago
    Many parts of the book are outdated, and some parts are just pedantic and outright trollish, but other parts still painfully up to date. For example, mandatory file locking. I bumped into this in a project once. We wanted to prevent concurrent read/write access to a particular file (a serial device, actually). Unfortunately there was no simple and reliable way to do this on Linux. The "traditional way" of doing this is via lock files: you create a file "somewhere", and other applications are supposed to check if this file exists before operating on the locked file. But you have three problems here: 1) the location of the lock files is not standard 2) there are race conditions with checking for the existence of the lock files and creating lock files and, most critically, 3) applications can still ignore the lock file at their leisure. There is also flock() (not mentioned in the book, IIRC, I think it was added to Linux at a later date). But it still blows because it only solves (1) and (2). You can flock() all you want, if applications don't care for it, they can still do whatever they want. We just ended up accepting our losses, used flock() for our applications, and hoped for the best.
• gerbilly 10y ago
  My copy came with a barf bag.
• ebbv 10y ago
  I remember when this was new and I've never found it as amusing as other people seem to. It's super easy to shit on software that's almost 50 years old. But where's the replacement? Windows is still worse as a web server platform than various Unix descendants (Linux and BSD) despite Microsoft's best efforts, and it's not free. Unix has its flaws but being a "Unix hater" is just dumb.
  • Gracana 10y ago
    UHH absolutely does not attack UNIX for being old. See "Who We Are" in the preface. The authors worked with systems they felt were superior in many ways, until industry/economic forces pushed them to UNIX. "This book is about people who are in abusive relationships with UNIX, woven around the threads in the UNIX-HATERS mailing list." They're not a bunch of angry outsiders, they're UNIX insiders who reject the idea of "Worse is Better." Worse is Worse, but we're stuck with it.
    • ebbv 10y ago
      I wasn't saying they were attacking it because it is 50 years old, I said it's easy to attack something that is 50 years old. Computer science and systems design has evolved a lot since then, so of course there were a lot of decisions made then that we wouldn't do now. And a lot of things evolved organically in UNIX, etc. Anyway, I'm not gonna rehash the same old arguments with you.
    • xorblurb 10y ago
      Worse is Worse negates the aspects that purity in the vacuum is very pure and very useless. There is (extreme) value in network effects, and network effects also exists in technology, not only in social networks... (and well, in technical fields, both are related). Also it's extremely easy to keep only good memories of extinct systems, and remain focused on past defaults, that for the most part have been largely corrected or at least compensated by dozen of years of refinement on still alive systems. I don't negate that there are some technical choices that are better than others in some context, or even in some cases in every aspects. But e.g. the PC loser-ing problem has in practice hardly caused much problems (and is even in some cases a superior approach even for the userspace), and judging systems by that kind of details can easily be compared to an hypothetical crazy mechanical engineer not buying a car because of an obscur mechanical technical detail in the engine, that has been made to work perfectly well by taking into account its peculiarities, but that he dislike by principle and in an absolute way. I'm also very aware of the enormously costly impact of some de facto industry choices. For ex: the C language and its derivative are shit and have arguably costed an absurd amount to the human kind -- compared to a technological-fiction world where safer languages would have been used. Does that mean that this is a case of "Worse is better"? Maybe, but then what would it mean? We have processors with MMU, we even have IOMMU that are becoming more and more common. Given some existing software stacks this does not need to be an intrinsically requirement -- but IMO this is vastly better. Can Worse sometimes win, and then Better also win on other subjects? What should we deduce from that then? What insight can we extract? If none, this whole categorization would be meaningless. So in some cases, "Worse" is actually just better, the "worse" in question only being in the eyes of the opponent. Or you need to be extremely precise about the criterion you are using. But I prefer to stick to consider all the advantages and drawbacks of what I'm talking about, the situation I want to apply it to, and avoid binary categorizations when they have no predictive value.
• kowdermeister 10y ago
  I've just found this subreddit looking for what else if not UNIX: https://www.reddit.com/r/EsotericOS/ https://www.reddit.com/r/EsotericOS/
• gingerbread-man 10y ago
  For all of the usability flaws pointed out here, to what would you ascribe Unix's proliferation and modern ubiquity? - Giving it away to universities? - The C programming language? What am I missing?
  • falsedan 10y ago
    The common explanation is "worse is better" (see The Rise of Worse is Better[0]) [0]: http://dreamsongs.com/RiseOfWorseIsBetter.html http://dreamsongs.com/RiseOfWorseIsBetter.html
    • jasonsync 10y ago
      tldr. The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
  • pjmlp 10y ago
    Giving it away to universities. All the alternatives had lots of zeros on their price tags. C just came along, like JavaScript on the browser. We already had better system programming languages since Burroughs B5000 in the 60's.
    • magentaboy 10y ago
      Get your Algol and MCP on: http://www.unisys.co.uk/offerings/high-end-servers/clearpath-forward-systems/clearpath-mcp-software/clearpath-mcp-express/Story/clearpath-mcp-express-id-2548 http://www.unisys.co.uk/offerings/high-end-servers/clearpath...
      • pjmlp 10y ago
        I know. :)
      • nickpsecurity 10y ago
• dsmithatx 10y ago
  When I read this 20 years ago I would never have believed I'd be typing this on a Mac laptop running yet another Unix variant. This line is now so funny... As for me? I switched to the Mac. No more grep, no more piping, no more SED scripts. Just a simple, elegant life: “Your application has unexpectedly quit due to error number –1. OK?”
  • ptero 10y ago
    You beat me to that respose! The book is a great fun to read. I read it in grad school 20 years ago (where Unix was the only option if you wanted to write your articles in TeX) and re-read it with much pleasure today (when 75% of my computer time is spent, by choice, on Linux variants)
  • problems 10y ago
    How does one use a Mac without grep or piping? I bought a macbook thinking I'd learn how to use it... but after 3 years, all I can do on a Mac is open a web browser and terminal.
    • Gracana 10y ago
      This book was written long before Mac OS X.
      • mcguire 10y ago
        I thought OSX was a weird Mach/BSD amalgam. In which case, not so much.
        • nwordsam3 10y ago
          I don't follow. When the book was written it was System 7 days. That's about as far removed from UNIX as you can get. This book was also before Linux was really on the radar outside of enthusiasts. You'd get 386BSD on a CD-ROM, FreeBSD was just released by Walnut Creek. This book was mostly a response to the absolutely atrocious landscape of commercial UNIX... the catalyst for Windows NT tremendous success.
• andai 10y ago
  Any thoughts on UNIX security? I've been wondering what the most secure OS is for a long time, and the answer seems to be "systems that stopped being developed before you were born."
  • jimktrains2 10y ago
    > I've been wondering what the most secure OS is for a long time Out of the box, most system with no public services running are usually decent (and that's hard to do with some systems). Beyond that it all comes down to configuration. There is no "most secure" OS. You can set them all up to be insecure or secure.
  • Ajedi32 10y ago
    Android, iOS, and Chrome OS all have security models that are fundamentally superior to what you get on a base *nix system: Fine-grained, application-level permissions which the user can grant or deny on a case-by-case basis. And before you say that all those operating systems are based on Unix; that's true but it's mostly just an implementation detail. There's no reason, for example, that Chrome OS couldn't be based on an entirely different kernel and still have the same permissions model, and most Unix-like systems don't have fine grained permissions like this out-of-the-box.
    • FroggyMan 10y ago
      Windows Phone 7 did fine grained security much earlier and with full device encryption as default. It's now also a standard on WinRT/UWP on Windows8/10. Android was very late to the party regarding fine grained security. Google knowingly put billions of consumers at risk for a long time. And even today its security a nightmare.
  • michrassena 10y ago
    If you're not aware of it already, have a look at these links as starting points. https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua... https://en.wikipedia.org/wiki/Security-evaluated_operating_system https://en.wikipedia.org/wiki/Security-evaluated_operating_s... A lot of the lower-level criteria require features present in operating systems we all use from day to day.
• ryanmarsh 10y ago
  OMG the anti-foreword by Dennis Ritchie. Pure gold.
  • pawadu 10y ago
    "Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag." Harsh words from Dennis, RIP.
• moomin 10y ago
  I love this book. Yes, it's now out of date, but it's a) still funny and b) is a great book for learning to think about the design of systems. The second point is sadly neglected. If you read it and your principal reaction is "Unix isn't like that anymore" you've completely missed the point.
• deleted 10y ago
  [deleted]
• fnordfnordfnord 10y ago
  see also: The Unix haters' UNIXUX server. It's pretty funny. http://www.art.net/~hopkins/Don/unix-haters/login.html http://www.art.net/~hopkins/Don/unix-haters/login.html
  • DonHopkins 10y ago
    It was more realistic back when the <BLINK> tag worked: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <TITLE>UNIXUX: Click on the cursor.</TITLE> <META NAME="Author" CONTENT="Don Hopkins"> <META NAME="GENERATOR" CONTENT="User-Agent: Mozilla/3.0Gold (Macintosh; I; PPC)"> </HEAD> <BODY TEXT="#7CFE5A" BGCOLOR="#191919" LINK="#FF0000" VLINK="#FF3333" ALINK="#00FEFA"> <P><B><TT><FONT SIZE=+1>UNIX HATERS Release 2.0 (unixux)</FONT></TT></B></P> <P><B><TT><FONT SIZE=+1>login: <BLINK><A HREF="password.html">_</A></BLINK></FONT></TT></B></P> </BODY> </HTML>
    • jcl 10y ago
      CSS to the rescue! :) https://jsfiddle.net/54bpngL3/ https://jsfiddle.net/54bpngL3/
• shakencrew 10y ago
  Previous discussion on Hacker News: https://news.ycombinator.com/item?id=7726115 https://news.ycombinator.com/item?id=7726115
  • dang 10y ago
    The current post is also a follow-up to https://news.ycombinator.com/item?id=13777077 https://news.ycombinator.com/item?id=13777077 from yesterday.
• mcguire 10y ago
  "We have tried to avoid paragraph-length footnotes in this book, but X has defeated us by switching the meaning of client and server. In all other client/server relation- ships, the server is the remote machine that runs the application (i.e., the server pro- vides services, such a database service or computation service). For some perverse reason that’s better left to the imagination, X insists on calling the program running on the remote machine “the client.” This program displays its windows on the “window server.” We’re going to follow X terminology when discussing graphical client/servers. So when you see “client” think “the remote machine where the appli- cation is running,” and when you see “server” think “the local machine that dis- plays output and accepts user input.”" Yes, Garfinkel, et al., don't know what a "client" and "server" are.
  • tankenmate 10y ago
    And yet if you are a programmer you'd be inclined to go with X's terminology.
  • zeveb 10y ago
    I remember back when I first started using X on a network: it was weird that I'd run an X client on the server and an X server on my client. It makes sense when one thinks about it, but it's still strange until one gets used to it.
  • pvg 10y ago
    That's about as true and insightful as 'mcguire doesn't know how to read'.
    • mcguire 10y ago
      The X server manages the physical display and provides a virtual display abstraction for clients. X clients connect to the server and make requests. The X server is called a server because it is a server and X clients are clients. It's excusable to be confused by the terminology, as in the quote, of course. Unless you claim to understand the whole "network" thing.
      • 10y ago
• bb88 10y ago
  I just pulled the book off my shelf and it still has the UNIX barf bag in the back. https://goo.gl/photos/gHvGwHpC3z5KxLv59 https://goo.gl/photos/gHvGwHpC3z5KxLv59 (edited link so that people don't need to login to google to see it.)
• dwheeler 10y ago
  Funny book, I have it in my hands (with the barf bag!). The anti-forward by Dennis Ritchie is awesome all by itself. Some of it is long obsolete. For example, Usenet/NNTP is rarely used today. And many of the specific implementation problems they mention are long-fixed on modern systems. Some of the problems they note are still valid. Some of the challenges of dealing with filenames are absolutely still true; because filenames are sequences of bytes (NOT sequences of characters), and allow stuff like leading dash, control characters, and non-characters, you can have a lot of problems. See the stuff on page 168-171. I talked about this in https://www.dwheeler.com/essays/fixing-unix-linux-filenames.html https://www.dwheeler.com/essays/fixing-unix-linux-filenames.... and https://www.dwheeler.com/essays/filenames-in-shell.html https://www.dwheeler.com/essays/filenames-in-shell.html That said, there are reasons that Unix-like systems took over everything. Many of their complaints are from lack of consistency. But some loss of consistency is inevitable when you have a marketplace of many people with many ideas. Many of the other systems they remember fondly were often tightly controlled by a small number of people - they were more consistent, sure, but they were also slow to implement newer ideas. When you're running a race, the one who runs faster usually wins.
  • pvg 10y ago
    Stop saying that! It's a foreword. Like 'foreplay' but with 'word'.
• verifex 10y ago
  Maybe there really wasn't such a thing as a "good" operating system long ago, just one that you could tolerate more than another. I remember using OS/2 Warp as a kid and thinking it was pretty neat. Although I couldn't really do much with it when I was a kid, since I wasn't interested in writing my own apps in OS/2.
• deleted 10y ago
  [deleted]
• kensai 10y ago
  I have to admit, I laughed at this: "C++ Is to C as Lung Cancer Is to Lung" :D
• deleted 10y ago
  [deleted]
• INTPenis 10y ago
  Hate all you want but I regularly have moments where I solve something using a string of commands and think to myself; gosh darn I love Unix! It's not really Unix, sometimes it's Macintosh with GNU tools installed but mostly it's CentOS or Debian servers where all this magic takes place. Sure I need to have a lot of stuff in that thick head of mine to do magic, but the joy of stringing together a series of commands to solve a problem my windows using co-workers would have to spend license money to solve is just amazing. Hating Linux is definitely right if you're looking from the perspective of universal user friendliness. But for true power users, the programmers, the scientists and the sysadmins; I can't picture life without it.