4 ms·

> And BTW systems built "by hackers for hackers" are among the worst offenders (*nix clones in general and Linux distributions in particular are good examples.)

• _yosefk 11y ago
  "Been around for a long time" - yes, but that doesn't mean hair-pulling will not result from upgrading emacs and having files in .emacs stop working. (I have a very simple vim configuration so I never had a problem there, I don't know if it's because they break less or because I depend on less.) As to easily switching... erm... just the other day I fixed a script bundled with a hardware system costing around $1M/year to lease to use basename instead of /bin/basename because I wanted to run it, not on RHEL but on Ubuntu and the latter put basename in /usr/bin. Hell, even #!/bin/env bash will break because on another system it's #!/usr/bin/env!! Other scripts did not run because ksh was not installed. At other times scripts break because /bin/sh is (wrongly) assumed to be bash but Ubuntu uses dash, whatever that is. And this goes from trivial stuff like the above all the way down to gdb being broken by a kernel upgrade to a minor version, or kernel memory leaks caused by minor upgrades, or NFS-related kernel panics. As to "yet not obsolete" - only if you use the box as a server needing nothing but a CPU, some RAM, an Ethernet connection and some media to boot and serve files from. Try running or compiling an old KDevelop on a new Ubuntu or vice versa and tell me if it's "surprisingly long life yet not obsolete". Also I can assure you that most of my complaints about breakage are met, if the person is a Linux aficionado, with bewilderment at my desire to run such ancient software where "ancient" means "6-12 months old". Certainly the only part of Linux which gives a shit about compatibility is the kernel (you can still run statically linked binaries from 1993), however it doesn't help much because every userspace program outside the very useful but rather limited set of the original Unix tools (grep etc.) happily breaks compatibility at every turn. I have to say that Windows has far less variants and far less incompatibilities between variants than *nix, so you switch both more smoothly and less often in my experience. This is not to say that it's a lovely experience, just that it's not nearly as terrible as Linux.
  • thaumaturgy 11y ago
    I think you're both finding different things to appreciate and dislike when comparing Unix-like systems to Windows. Unix-like systems really are relatively stable, in terms of, once you get it working, it will generally continue to work. And, for the majority of superficial commands you might want to run -- ps, top, uptime, w, tcpdump, vi, pico, nano, mail, etc. -- there haven't been many big changes for decades. Somebody that was pretty handy with BSD or Linux in 1995 could still find their way around the commandline on most systems today. They'd have to figure out newer init systems and a few other things, and the popular windowing environments have changed a lot, but basic CLI stuff is pretty stable. But you're right, trying to get these systems to work in the first place, or trying to keep them up to date without incurring significant cost or downtime, can really be a pain. I've experienced the same. I think the worst offender to date was Samba; at one time, Samba 3 could do file shares with Winbios authentication but not talk ActiveDirectory, and Samba 4 could talk ActiveDirectory but not do file shares (or some such thing, it's been a few years), and they were both being released at the same time, so if you wanted a Samba server in an SBS 2008 environment you had to run both -- on two different systems. And configuring either one of them successfully was an absolute nightmare. I still have a text file under my Documents/sysadmin/ directory that has some shorthand notes on troubleshooting Samba installations and that thing is a gold mine. Every couple of years, after I've forgotten everything about Samba, I get a call to fix one that's not working. I'd never be able to do it without those notes. That's just one example; I've had lots of issues with Network Manager ("Network Mangler"), print drivers that require 32-bit OS support which, once installed, completely bones other software updates and installations; OS updates that irreversibly break a working Apache installation (that one required me to pull a 24-hour shift building a new server), and yes, trouble with systemd/journald. All kinds of fun stuff. It's a mixed bag. Windows-based systems usually just work, as long as you throw expensive enough hardware at them. They either do a job or they don't. But they aren't very fixable. There's no advanced logging system in the Windows environment, so whether you have any logs to work with in the event of trouble is entirely up to the individual software vendor, error messages are opaque, and I can't just go grep some source code to try to figure out what the hey is going on. Linux and BSD systems are a lot more fixable, I generally prefer working on them, but they have some of the worst quirky little bugs caused by software affecting other software, and documentation still leaves a lot to be desired.