It's interesting to see which parts of the handbook are dated, and which are not. Surely nobody these days would criticize Unix for crashing every few days, or complain that copy and paste doesn't work in X, or about a "massive 3/4 megabyte binary", or `ed`... but `rm` is still an irreversible operation (and versioned filesystems still esoteric). Pipes still suck, even if all the alternatives are worse. C programmers still have to deal with manual memory management...
It does what it's supposed to; it gets rid of the file while freeing up space. If you don't like it, then use "git rm" instead of "rm".
C programmers still have to deal with manual
memory management...
Manual memory management is still required because of our current reality. A garbage collector for instance creates a fake reality, one in which you deal with memory as if it is unlimited and extremely fast. This simply does not work for system software. It is possible and it's a romantic notion too, but just as with micro-kernels, people kind of fake it (as in, putting lipstick on a pig) otherwise you're not getting anything useful done.
I do hate Unix operating systems, but the alternatives are much worse. I also liked this quote from the article:
sometimes one wonders why you just don't
shut up and tell people to buy a PC with Windows
or a Mac. No Gulag or lice, just a future whose
intellectual tone and interaction style is set
by Sonic the Hedgehog.
> A garbage collector for instance creates a fake reality, one in which you deal with memory as if it is unlimited and extremely fast.
Actually no, GC does not suggest that memory is unlimited let alone imply anything about its speed. Systems with GC will happily punish anyone who makes those assumptions, just like any other memory management scheme.
GC merely says that a given address may become available for reuse after the last identifiable reference goes away.
I think he meant that GC is a "solution" to the problem of memory management only if you consider memory to be unlimited and fast; in other cases, it incurs a penalty and isn't really a "solution". You took is comment far too literally.
Manual memory management isn't "required" - it's merely the best option in some cases. However, GC is the best option in some others. (Every memory managment mechanism, including manual and even static, has costs.)
Yes, GC can be the best option for system software.
I would really like `rm` to just deprioritize the space taken by the file, so if enough time passes and space is needed, old deleted files are reclaimed.
That is, institutionalize the idea of "undelete" -- but still allow `rm` to make a good trade-off between space reclamation and irreversibility.
Manual memory management is still useful for some things, but it seems you're implying GC is wrong in every situation? I'd say the vast majority of software today is better served by GC'd languages (That does not include many forms of systems programming, however).
I actually like the fact that rm deletes files permanently. But then again I'm the kind of person who HATES the recycle bin/trash can system with a passion, and disable it wherever I can.
When I delete something, I want it GONE. Not later when the system runs out of space. Not after I do a second "empty trash" operation. NOW. If something's important to me, I'll make a backup.
I founded the unix-haters mailing list that the book was based on, and these days I like to say that Unix went from being the worst available operating system to the best available operating system without getting significantly better. (and yes, in the spirit of the list this is no doubt unfair, biased, mean, etc.)
Security ("Oh, I'm sorry, sir, go ahead. I didn't realise you were root") still reads pretty well today. Vi might no longer read its conf file from the CWD, but the standard toolkit has plenty of SUID=0 programs: this vanilla Debian has 17 of them in /bin:/usr/bin. Of these, only sudo really benefits from being architected in this way. Cf. http://lwn.net/Articles/199004/ for another approach.
Comments
It's interesting to see which parts of the handbook are dated, and which are not. Surely nobody these days would criticize Unix for crashing every few days, or complain that copy and paste doesn't work in X, or about a "massive 3/4 megabyte binary", or `ed`... but `rm` is still an irreversible operation (and versioned filesystems still esoteric). Pipes still suck, even if all the alternatives are worse. C programmers still have to deal with manual memory management...
I do hate Unix operating systems, but the alternatives are much worse. I also liked this quote from the article:
Well, DMR definitely preferred the bazaar.> A garbage collector for instance creates a fake reality, one in which you deal with memory as if it is unlimited and extremely fast.
Actually no, GC does not suggest that memory is unlimited let alone imply anything about its speed. Systems with GC will happily punish anyone who makes those assumptions, just like any other memory management scheme.
GC merely says that a given address may become available for reuse after the last identifiable reference goes away.
I think he meant that GC is a "solution" to the problem of memory management only if you consider memory to be unlimited and fast; in other cases, it incurs a penalty and isn't really a "solution". You took is comment far too literally.
Manual memory management isn't "required" - it's merely the best option in some cases. However, GC is the best option in some others. (Every memory managment mechanism, including manual and even static, has costs.)
Yes, GC can be the best option for system software.
No mechanism is best in all circumstances.
The UNIX-HATERS Handbook is oft refuted, but I think you're missing the point of the GP.
Many of it's sections criticism what were at the time implementation limitations or bugs, only some of it really criticises Unix itself.
I would really like `rm` to just deprioritize the space taken by the file, so if enough time passes and space is needed, old deleted files are reclaimed.
That is, institutionalize the idea of "undelete" -- but still allow `rm` to make a good trade-off between space reclamation and irreversibility.
Manual memory management is still useful for some things, but it seems you're implying GC is wrong in every situation? I'd say the vast majority of software today is better served by GC'd languages (That does not include many forms of systems programming, however).
I actually like the fact that rm deletes files permanently. But then again I'm the kind of person who HATES the recycle bin/trash can system with a passion, and disable it wherever I can.
When I delete something, I want it GONE. Not later when the system runs out of space. Not after I do a second "empty trash" operation. NOW. If something's important to me, I'll make a backup.
You're misunderstanding what he is saying. As well you're not understanding how rm (unlinking) works.
http://en.wikipedia.org/wiki/Unlink_(Unix)
I founded the unix-haters mailing list that the book was based on, and these days I like to say that Unix went from being the worst available operating system to the best available operating system without getting significantly better. (and yes, in the spirit of the list this is no doubt unfair, biased, mean, etc.)
> complain that copy and paste doesn't work in X
I do complain that copy and paste don't work very well in X. There seem to be several incompatible intermediates stores for the cutted texts.
...and once you know how to use them (and why they exist), that's a good thing
I've gotten around to using the instead of cursing them.
But it's still strange, that marking text does a different copy than Ctrl-C in Chrome, which gives a different thing than M-W in Emacs.
So, how do I use them, and why do they exist?
Security ("Oh, I'm sorry, sir, go ahead. I didn't realise you were root") still reads pretty well today. Vi might no longer read its conf file from the CWD, but the standard toolkit has plenty of SUID=0 programs: this vanilla Debian has 17 of them in /bin:/usr/bin. Of these, only sudo really benefits from being architected in this way. Cf. http://lwn.net/Articles/199004/ for another approach.