Scott Francis writes: > On Tue, Dec 30, 2008 at 2:21 PM, Peter da Silva <[email protected]> > wrote: > > > No further comment is needed. Bastards. > > boy, I've been wanting to expound upon this for years (and have, to > anybody who'd sit still and listen);
Your treating Peter's claim assertion of no comment being needed as an invitation to comment? Interesting! > in fact I was just beating somebody over the head with it on Twitter > earlier today (but that's a hate for another time). You were beating somebody over the head with "it" (the current hate, presumably?), yet that's a hate for another time? > rounding out the top 5 The top 5 what? This was apparently a tcsh hate, though I see you've changed the subject line into Linux. > (including auto-aliasing of mv(1) with the aforementioned rm(1) hate): So the top 5 includes seven items -- the prompting on mv, the prompting on rm, and the five items you then list? > * default setting of remote window title - if I wanted my terminal > windows to say bash, CWD, hostname, tty and process, I'd bloody well > set it myself. The sytems I've seen doing this set it as part of the Bash prompt. I'm not aware of Linux as a whole doing that -- many servers I've SSHed to don't, of various distributions of Linux. The default Bash prompt appears to just give the version of Bash being used, which is pretty hateful; do the Bash developers really think that I'm always so eager to make use of a feature only in the latest point release that the most important thing I need to know for every single command is precisely which version of Bash this is? So many people either have their own preferred PS1 (in .bashrc) which they deploy on all systems (in which case they are immune from any OS defaults, such as setting the title) or take advantage of the OS default being more useful than the Bash default. In the latter case, they clearly can't please everybody; if they did the opposite, some people could complain about it being missing -- remote Windows which are unhelpfully labelled with whichever directory on the local computer one happened to be in when SSHing. > This is a non-annoyance when using borderless, headless transparent > Eterms, but pathological on e.g. Terminal.app or other equivalents > where you have to manually open up prefs, clear some text and save > your changes every damn time. Gnome Terminal let's you configure (once, then remembers it) whether dynamically set titles override the initial title or are ignored. If Terminal.app doesn't have a similar feature then that's hardly Linux hate. > * (partially) replacing functional standards (e.g. man(1) with > info(1)) for the sake of ideology (this branches off into GNU hate) Your example, info instead of man, is definitely a Gnu thing, and at least some Linux distros, such as Debian, resist it, providing manpages where the upstream software doesn't, or only has a stub. What other standards that Linux ideologically ignores did you have in mind? > * documentation - even if there _is_ a man page, it more likely than > not either says "see http://some.url/which_has_moved for details" > and/or is 4 major releases out of date with the actual installed > software, or contains blatant factual errors Really? You're claiming that for more than half of Linux manpages? And that this problem doesn't exist on non-Linux Unices? Could you give a few examples? > * filesystem hierarchies that changes with the phases of the moon - > this situation has improved somewhat in the past few years, but the > related hate of package management systems that drop 3rd party > packages into system-level directories Surely that's caused by the 3rd-party packagers (with each package saying where it wants to be installed), not the OS? > (/usr/bin, /sbin, etc. should have nothing in them that can't be > restored by a wipe and a clean OS installation - packages should be > clearly segregated for ease of management. Again, principle of least > surprise.) That'd be one way of doing it, creating a division between "clean OS" and "packages". But another is to consider the OS merely to be a collection of packages (possibly with multiple variants as to what gets installed as the base), in which case the distinction can get nebulous. An alternative distinction is between files which have come from packages, and so are part of the OS's package management system, and those installed some other way, such as by hand from a tarball. That leads to it being possible to easily recreate /usr/bin/, etc just from the list of repositories and packages, leaving just things in /usr/local/ to be done manually. Surely that's also ease of management? Smylers
