| In the article he asks why does less need a history file. Who says it does? It's an option. It can be disabled turned off. The question of why it's on by default is another matter. Manpage extract: LESSHISTFILE Name of the history file used to remember search
commands and shell commands between invocations of less. If set to "-" or "/dev/null", a history file is not used. The default is "$HOME/.lesshst" on Unix systems, "$HOME/_lesshst" on DOS and Windows systems, or "$HOME/lesshst.ini" or "$INIT/lesshst.ini" on OS/2 systems. Then the author complains about applications that write too much to disk. He has my sympathies. Has he ever heard of a ramdisk? mfs? tmpfs? This is the easy solution to the problem of braindead applications writing needlessly to disk. The simple rule is: If you don't want disk writes then don't use the disk. Mount your directories in RAM. Is this perfect solution with zero overhead? No. Is the cost very small? Is is exponentially faster than using the HDD? Try it and answer these questions for yourself. There are also the countless bloggers who write about installing an OS to a USB stick or SD card. They usually mention the issue of disk writes and how this impacts flash memory, but they almost always proceed to instruct their readers to "untar" several thousand files in the course of an install anyway. This is not very helpful. Did it ever occur to them that they could make an image of a
filesystem and transfer that to the media - requiring only a single write? Can you mount root read-only and other dirs like /var and /etc read-write? Yes, of course. How do tech support people in corporations deploy countless Windows installations? They use imaging. It is not rocket science. One commenter says you can't extract a single member from a tarball without reading the entire file. What version of tar is he using? Manpage extract: -q, --fast-read Select the first archive member that matches each pattern operand. No more than one archive member is matched for each pattern. When members of type directory are matched, the file hierarchy rooted at that directory is also matched. This means the entire archive is not read, unless the member to be extracted is at the very end. Similar to sed /pattern/q or grep -m1 pattern. Anyway pax is better than tar. Another commenter claims you cannot "stream download and decompress" tar.gz files "on-the-fly". What exactly does that mean? What if you do this:
(BSD/OSX only; Linux ftp is not the same) ftp -o"|gzip -dc" http://host.tld/file.tar.gz Or this { echo GET /file.tar.gz HTTP/1.0 ;echo ;} |nc -vv http://host.tld 80 | gzip -dc Then try the same with a .zip file and using unzip -c instead of gzip -d -c |