On Wed, Dec 31, 2008 at 2:02 AM, Smylers <smyl...@stripey.com> wrote: [snip]
>> 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! perhaps not surprising, on a list devoted to rants and the exposition thereof. >> 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? twitter itself is a hate for another time, yes. >> 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. you caught the subject change - nice one! :) >> (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? mv/rm auto-alias are one item for the purposes of this hate, and I then listed five more - so yeah, 6 (not 5) in all, but I did indicate there were quite a few more. (Pedantic disassembly of hates is itself hateful.) >> * 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. it's the default behavior of the default system shell, which is grounds for hate in my book. > 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? agreed; if I want to know the version I'll ask - otherwise, the shell should just shut up and default to silence in the absence of an error. > 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. I'm of the opinion windows shouldn't be labeled at all (at least not unless said labels/titles are universally and consistently updated, including removing stale data when I logout of a remote system). >> 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. setting it in the first place is the hate in question; Terminal.app has a whole other set of hates. I'm attempting to keep my hates on-topic in a per-thread kind of manner. >> * (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. I'm of the opinion that if you ship a piece of software in your base, it must have a complete and up-to-date man page. No exceptions. If you can apply that policy to your packaging system, so much the better. > What other standards that Linux ideologically ignores did you have in > mind? not Linux so much as GNU (although they are by and large synonymous for everyone but the zealots) >> * 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? it's a problem that is non-existent on OpenBSD (and FreeBSD, as far as my experience goes, although I use it less frequently than Open), and I have not observed the problem on Solaris either (although Solaris' unique approach to man(1) has its own drawbacks). OS X has inherited some of the "documentation as an afterthought" tendency from Linux, unfortunately (although Apple seems to have been cleaning up their act Tiger and moreso with Leopard). And I thought this was a hate list, not an advocacy/apologetics list - if we're going to require rigorous documentation of all hates, it will at least cut down on list traffic ... >> * 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? the OS provides the packaging system and should be able to specify the default root for all packages in that system. If they choose not to do so and let 3rd party maintainers scatter binaries and config files around the filesystem willy-nilly, then that's hateful. >> (/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. sure, you _could_ do the OS as a collection of packages ... given that no other UNIX-like OS historically has done that, you could also adhere to the principle of least surprise and keep a clear segregation between core OS (kernel, base tools) and aftermarket packages. > 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? on OpenBSD, I can already instantly repopulate /usr/bin and friends with baseXX.tgz, etcXX.tgz, compXX.tgz, etc. (which I suppose qualifies as a sort of meta-package). The OS-as-packages approach is one I don't care for, but that I will admit does have its advantages (I just think that it's possible to gain those advantages while still maintaining a clear segregation between core OS and aftermarket packages). -- Scott Francis | darkuncle(at)darkuncle(dot)net | 0x5537F527 Less and less is done until non-action is achieved when nothing is done, nothing is left undone. -- the Tao of Sysadmin
