Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

web.mit.edu

Post reply on HN
Print view View original

211–220 of 316 posts

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

#211

Post by tannhaeuser »

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…

Like the quote says.

Autotools sucks big time, and what it does has been largely unnecessary since around the turn of the millenium [1]; but since it's used almost everywhere in infrastructure (often decades-old) software you have to deal with it.

If you pull a 927 and make a grand unified build system, you get something like CMake which sucks even more (its own build process takes longer than that of the software it's supposed to build, need to deal with C++, have fun with CMakeLists build errors and customizations, etc.).

I believe git's build system is just a bunch of (or a single) Makefile. That's what an optimal build (but not mine, unfortunately) looks like. Though, pure (POSIX) make is insufficient for anything non-trivial IMHO.

phk's famous rant on libtool:

[1]: http://queue.acm.org/detail.cfm?id=2349257

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

#212

Post by seanp2k2 »

pjmlp wrote: post #50
raverbashing wrote: post #35

Earlier quoted context omitted.

Correct. And the last time I came across one of those I compiled and used modern tools. Because even 20 year old Linux versions had tab complete and a vi that worked with directional keys

Assuming one has the access rights for it. I do occasionally ssh into boxes were I am a lame user without compilers installed.

Wget or scp? Paste a binary into vi and save it?

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

#213

Post by cmrdporcupine »

david-given wrote: post #98
Philipp__ wrote: post #34

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

Really, though, Unix is just the UI over the top of the underlying operating system. Like, Minix and Linux work in radically different ways, but they both expose a Unixy/Posixy interface with file descriptors and pipes and the same execution model. Further out, Haiku is even more different; and then there are all the different Unixy front ends to Windows, which is very far from a traditional Unix inside. Then there's…

Honestly, even Haiku etc. have underneath very Unix-like assumptions about the services and nature of the things an operating system provides, and a lot of that goes with the Posix and ANSI lib-C slant that programmers expect everything to have now.

Basically every single mainstream OS out there has the assumption that there are files with filenames as binary/text blobs in a separate storage space from 'memory', and with that ... file descriptors, processes, threads, and sockets.

But it doesn't take much imagination to conceive of different models -- what if instead of a file system we have a relational model? Relations/relvars and tuples as fundamental storage units? What if instead of malloc/free and fopen/fclose (and mmap/msync) we have instead some unified notion of allocation/storage with hints/specifications of permanence requirements, performance requirements, type, and intended use and the OS takes care of where to put it (cache, main memory, flash, magnetic storage, network storage etc.)?

One can think of any number of possibilities. But the needs of the C-language semantics and the orthodoxy of 50 years of OS/language patterns keep us where we are.

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

#214

Post by raverbashing »

SSLy wrote: post #129
pjmlp wrote: post #51

Earlier quoted context omitted.

It depends on the IT guys, I have occasionally sshed into boxes where that wasn't the case and compiling wasn't an option.

- 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

It should be "a lot of fun" to try to cross compile an AIX or Solaris binary on a Linux machine

You'll probably go insane doing it

(Linux x86 compiling to Linux ARM/PPC/etc is doable and done quite frequently)

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

#215

Post by jff »

ori_b wrote: post #199
jff wrote: post #174

Earlier quoted context omitted.

You should be able to build well-written code on a variety of modern systems using nothing more than a Makefile, or even just a shell script. See plan9port for an example of the latter.

Plan9port shops with, and uses, mk.

You're right, but first the INSTALL script makes a few customizations based on what OS you're running (Solaris, OS X, Linux, *BSD), then bootstraps mk and finally runs mk on all the application source.

The script takes into account differences in operating systems, without including thousands of lines of weird little leftovers from 30 years ago when you needed to check if you were actually running on a 16-bit Data General machine or whatever (I'm looking at you, autoconf)

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

#216

Post by rspeer »

magentaboy wrote: post #133
gingerbread-man wrote: post #56

Earlier quoted context omitted.

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 )

For decades, I have challenged people with a dollar bet tha they cannot correctly spell "fuchsia" given five tries. Everybody thinks they can spell it, but I have never lost the dollar. Sometimes I pull out the same bet six months later and still win it.

Indeed, I seem to recall from the XKCD color survey that the correct spelling of "fuchsia" was not in the top five.

Which makes it a messy name for a project. Though maybe Google can change the spelling by brand-name fiat, just like they did with "googol".

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

#218

Post by mikelevins »

throwanem wrote: post #190
jff wrote: post #183

Earlier quoted context omitted.

Lisp machines were expensive, the early ones at least took a very long time to boot, and I think there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge. They're still extraordinarily cool machines.

> there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge I'd be interested to hear this expanded upon.

Old-fashioned Lisp and Smalltalk systems presented a programming model in which the language process is your running program, but it doesn't yet know how to do the right thing. Your job is to interactively teach it how to be your application. This you do by teaching it one little piece at a time until it is transformed into the application you want.

This process is facilitated by the ability to at any point save the state of the process for later resumption. These saved states are called "heaps" or "images" or "worlds". Start up one of them and you are more or less instantly returned to the last state you were in when the process was last running.

LispMs extended this model to the entire machine.

There are advantages and disadvantages. The advantages are legion, and they can enormously accelerate development in the hands of someone comfortable with that mode of working.

There are two main types of disadvantage. One is that, since you are interactively modifying a live, running system, if you make a mistake, the mistake becomes part of the running system. If you save the image with that mistake in it, it becomes part of the system in future sessions, too.

The second problem is that it becomes troublesome to separate your application from the scaffolding that you've used to build it. To take a very simple example, suppose you construct a few simple data structures for testing purposes. Those test structures then become part of the running system, and there is a risk that your application will inadvertently come to depend on their values, leading to obscure bugs if they change or if the application is deployed without them.

There are reasonably straightforward ways to deal with both classes of problem, and properly-designed Lisp and Smalltalk systems include tools that help solve these problems, but it's appropriate to acknowledge them as problems.

I like old-fashioned Lisp and Smalltalk systems, and I like image-based development. I prefer the programming model in which I am teaching the process to be my application, and I'm much more productive in such an environment than in the now more-mainstream, model where programming is more like building something from a blueprint than it is like teaching something to behave the way I want.

But that doesn't mean I don't acknowledge the problems of image-based development. They exist. They are solvable, but they do exist.

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

#219

Post by jackhammons »

dahart wrote: post #105
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?”

Ha! I switched to Mac so I could have pipes, grep and bash. I personally believe a big reason for the Mac resurgence has to do with the switch to UNIX. I was on Windows using Cygwin for years before anyone I knew was using a Mac. Then OSX came out, and all of a sudden all the academics I knew switched to Mac, and a couple years later most of the professional programmers I knew had switched. The great thing about a Ma…

Have you tried the Windows Subsystem for Linux?

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

#220

Post by mikelevins »

mamon wrote: post #58
throwanem wrote: post #42

Earlier quoted context omitted.

Lisp machines turn up pretty frequently in this context, and I understand why - some of their capabilities still haven't been replicated anywhere else, nor are they likely to be, and that's a real loss; in particular, there is a great deal to be said for a model in which changing the behavior of the running system, right down to the microcode, can be as simple as writing up the changes you want and evaluating them. N…

Live modifications of OS code sounds like a recipe for disaster. Unless you are an expert that codes himself an OS before breakfast

Bear in mind that LispMs had well-designed tools for supporting this kind of development. For example, they had version control that tracked all changes everywhere at all times, even changes that were not saved in any file.

Also bear in mind that they were designed by programmers for programmers. They were not intended for the general public.

Post reply on HN