3 ms·
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
by 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 agoMany 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.