The Unix-Haters Handbook (1994) [pdf] • Hacker News Board

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

#151

Post by jdblair » Fri, Mar 03, 2017, 4:03 PM UTC

dsmithatx wrote: post #73

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

I switch back to Mac from Linux so I could have grep, pipes, sed and all the UNIX stuff alongside real commercial applications like Word, Excel and Photoshop.

The irony is now I run Linux in a VM because the toolchains for the embedded work I do all run there. In principle I can make it all work in MacOS, but it already works in Linux.

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

#152

Post by DonHopkins » Fri, Mar 03, 2017, 4:06 PM UTC

mcguire wrote: post #124

" 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 progr…

I'm the "et al." who wrote that chapter, and I don't understand what you're trying to say.

What do you think "client" and "server" mean, and what do you think is wrong with that paragraph-length footnote (besides its length)?

Could you please try to rewrite it more accurately or in fewer words?

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

#153

Post by dfox » Fri, Mar 03, 2017, 4:07 PM UTC

pjmlp wrote: post #24

hbex5 wrote: post #3

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.

Everyone that dislikes Win32 should program directly with Xlib and Athena, and rejoice of the experience.

I don't think that at the raw level there is that much of a difference. XCreateWindow() has mostly the same arguments as CreateWindowEx() except that the X11 API only handles creating window and does not mash it together with upper layer concepts like event handling (lpClassName) and widget sets (hMenu).

The X11 model is also easier to reason about because it is clear where the layer boundaries are and what is implemented in your process as opposed in the kernel/display server and what causes some kind of IPC (eg. what happens to lParam when you send message to window with WndProc implemented in different process?).

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

#154

Post by DonHopkins » Fri, Mar 03, 2017, 4:08 PM UTC

fnordfnordfnord wrote: post #109

see also: The Unix haters' UNIXUX server. It's pretty funny. http://www.art.net/~hopkins/Don/unix-haters/login.html

It was more realistic back when the tag worked:

    
    
    
       UNIXUX: Click on the cursor.
       
       
    
    
    UNIX HATERS Release 2.0 (unixux)
    login: _

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

#155

Post by dwheeler » Fri, Mar 03, 2017, 4:09 PM UTC

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

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

#156

Post by nickpsecurity » Fri, Mar 03, 2017, 4:10 PM UTC

andai wrote: post #83

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

re UNIX security

It was proven impossible to fully secure by high-assurance engineers back when INFOSEC was being invented. UNIX was much smaller back then. Project such as UCLA Secure UNIX and products such as Trusted Xenix were still unable to reach high assurance due to problems baked into the architecture and UNIX principles themselves. Even with API changes, they still had problems with covert channels. That led the inventors of INFOSEC to abandon UNIX for secure applications in favor of clean-slate, security kernels with user-mode or deprivileged layers for legacy, UNIX apps. Anything truly trustworthy runs directly on the security kernel.

re secure OS's

Probably INTEGRITY-178B or Turaya with Linux VM's for now. Maybe SourceT for network appliances. They're sold for nice sums of money to militaries, governments, and companies with nice budgets. GenodeOS is working toward a FOSS version of Nizza architecture.

http://www.ghs.com/products/safety_critical/integrity-do-178...

https://os.inf.tu-dresden.de/papers_ps/nizza.pdf

http://www.perseus-os.org/content/pages/Architecture.htm

https://secure64.com/secure-operating-system/

Two of the original, high-assurance systems are still around for OEM license from BAE (STOP) and Aesec (GEMSOS). We've learned a lot of ways to break stuff since then. Who knows what current level of assurance is. ;)

http://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf

There's also language-based approaches being investigated that could be done in something more trustworthy than Java:

http://www4.cs.fau.de/Projects/JX/

Finally, there's CPU's designed to do isolation, reliability, and so on at the gate level. Rockwell-Collins uses one in their guards and crypto appliances. Sandia has a high-assurance Java CPU. Industry also sells Java CPU's for embedded that might be converted into some safe execution platform combined with something like JX. Call these building blocks for secure OS rather than the OS itself.

http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf

https://www.ajile.com/index.php?option=com_content&view=arti...

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

#157

Post by mcguire » Fri, Mar 03, 2017, 4:10 PM UTC

pvg wrote: post #141

mcguire wrote: post #124

" 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 progr…

That's about as true and insightful as 'mcguire doesn't know how to read'.

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.

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

#158

Post by rileymat2 » Fri, Mar 03, 2017, 4:11 PM UTC

problems wrote: post #119

pjmlp wrote: post #112

Earlier quoted context omitted.

> How does one use a Mac without grep or piping? Using Finder, XCode, Objective-C and Swift frameworks,...

Bluh, don't get me started on Finder. Icons in directories would randomly be overlapping just because I hadn't been in them in a while and new files were added, they added this weird tagging system with colors that just doesn't make sense to me at all, it randomly thinks I want to view some sort of "recently used files and some random shit" list instead of my homedir. I don't know what the devs of it were thinking. E…

I completely agree with you, the "All My Files" view that it defaults to seems to not fit me very well.

The nice thing is that it is configurable.

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

#159

Post by DonHopkins » Fri, Mar 03, 2017, 4:12 PM UTC

mi100hael wrote: post #106

raverbashing wrote: post #11

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.

"Autotools is the worst form of build system, except for all those other forms that have been tried from time to time." -Churchill, probably In all seriousness, what's your preferred alternative? Seems like Autotools is a pain, but it gets the job done and is widely available. I haven't found a build system for C projects that is: - Less complicated - Available from default package repos so others who clone don't hav…

As if I needed to build the latest version of Gnu cat on a Microvax.

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

#160

Post by mcguire » Fri, Mar 03, 2017, 4:13 PM UTC

DonHopkins wrote: post #152

mcguire wrote: post #124

" 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 progr…

I'm the "et al." who wrote that chapter, and I don't understand what you're trying to say. What do you think "client" and "server" mean, and what do you think is wrong with that paragraph-length footnote (besides its length)? Could you please try to rewrite it more accurately or in fewer words?

Hi, Al!

The X use of "client" and "server" is correct. The "remote machine"/"local machine" thing isn't.

See my other reply: https://news.ycombinator.com/item?id=13783802

Edit: Forgot to refer to you as Al. (Dang it, this is why I can't have nice jokes.) Apologies!