It's unfortunate how some people will assume anyone whose opinion is different from theirs must be posting out of ignorance and not experience. If someone is critical of Linux and posts in a discussion where Windows is also relevant, you don't have to jump to the conclusion that they need to learn what chroot is or don't realise that su'ing to root on Linux is not directly analogous to allowing administrator access on Windows.

Let's consider a real world example I dealt with not so long ago, maintaining a system that is used for multimedia work. In such systems, FFMPEG is a commonly used component. You probably want some audio and video codecs to go with it. Those in turn might depend on various tools to build optimized code. And if you're running on a stable distro like Debian as your foundation, the distro-packaged versions of all of these tools will be old, so you almost certainly want to fetch and build recent versions manually instead.

Before we continue and I tell you what the actual maintenance problem I had to fix was, please tell me how you would set this up. That way we can easily see whether your "many, many ways to handle this" that I (or presumably, in this case, the guys who first installed the software) might "care to learn" would have worked out any better than what was actually done, and at least one of us will learn something.

But this is exactly the problem: There is no guarantee that any given package is reasonably maintained. From direct personal experience, a surprisingly large number of well-known packages don't quite work like most others in some little respect, or invoke magic (usually to do with detecting some other package(s) installed on the system) during their configure process that won't necessarily be repeatable if other software installed on your system changes, or do seem to want to be installed as root if they're intended to be available for all users from common directories even if as you say this shouldn't really be necessary in *nix world.

The major distributions do an excellent job of dealing with these little foibles in the packages they supply, but without that safety net things can get ugly disturbingly quickly. Because everything tends to rely on scripting that can do essentially arbitrary things modulo user permissions, there are no standard tools to answer should-be-simple questions like "Where did this executable file come from?" or "Does any software that is still installed depend on this library?" or "Where are the settings for this application kept so I can back them up?".

Obviously Windows suffers from analogous problems. It's silly that in 2013 any mainstream operating system doesn't lock installed software down much more tightly and provide robust mechanisms to upgrade or remove that software with or without its consent. All I'm saying is that people in glass houses shouldn't throw stones, and software installation/updating in Linux is... a residence built from transparent amorphous solid material.

My "anecdote" is widely reported on the Web, with various people having diagnosed the cause of the reproducible problem.

Your anecdote appears to be about a system that is configured a different way, presumably because you're only using RAID for your /root and not your boot partition, so it doesn't really have anything to do with what I was describing.

Why would you need to? Do you also want to take out a soldering iron to perform a bit of light surgery on your CPU?

Unfortunately, first you need to figure out which executables and libraries any given component actually provides, where it puts them, and what dependencies are involved. It is quite likely that the only way to do that reliably for a given component will be to manually read through extensive configuration/makefiles. As you say, in Linux there is some stuff that's hard.

If you're seeing problems almost every month, you should investigate your systems for malware and/or hardware failures. That simply isn't normal. MS aren't perfect, but their QA for automatic updates is way better than most large software companies, and seeing failures as often as you describe is highly unlikely without some other factor causing problems.

Except for the part where pretty much everyone's third party applications on Windows add a single uninstall entry in the standard place in Control Panel and can be removed with two clicks from that standard screen, you mean?

Also, if you start deleting random system files you don't think you'll need on any recent version of Windows, firstly you'll find yourself interrupted by various security measures, and secondly various recovery tools would rapidly restore your system to working order. It's 2013, not 1995.

Would you also like help getting Debian Potato running on your i7?

And how are you going to enforce that, exactly, short of complete overkill like running everything you build in a dedicated VM or at least some sort of chroot jail?

In any case, the problem isn't the default distro packages interfering with those you build yourself, it's the completely uncontrolled dependencies between packages that you do build yourself, because there's no standard way of installing anything. I was setting up one notoriously awkward bit of software on a Linux box recently and looking up HOWTOs, and I found about half a dozen different places that it was claimed to belong, from assorted placed under /usr/local to /opt via a dedicated user's /home directory and a couple of others I can't even remember now.

Even if you know where you want to install a single package, and whatever scripts or makefiles it comes with play nicely in that respect, I've had previous cases where so many multimedia tools/libraries could affect each other and had magic involved during their configure/build processes depending on what else was around that upgrading any of them in situ appeared to be impossible. The only way to reliably perform a clean upgrade was to remove four or five different components that had originally been downloaded and installed independently, and then reconfigure, rebuild and reinstall each of them from scratch in their preferred dependency order. It made the bad old days of DLL Hell look like a walk in the park.

I think the problem of hasty and bug-ridden updates is becoming endemic in the industry.

On my work computer, I have a detailed log of every piece of software and software update that has ever been manually installed since the very first time the machine was powered on, a lesson learned the hard way. Moreover, I am absolutely strict about installing only necessary software, no trials, install/uninstall cycles just to experiment, or anything like that.

Even so, among other applications to have become buggy or outright corrupt over the intervening three years are:

• Mozilla Firefox
• Google Chrome
• Mozilla Thunderbird
• Adobe Flash
• Adobe Acrobat
• Oracle Java
• Various Sublime Text 2 plug-ins
• LibreOffice

In many cases, a subsequent update then fixed the problem again, but the amount of time I've lost due to buggy updates that get in the way of doing normal work is just silly.

Microsoft have caused one serious problem too, but nothing that rebooting Windows into recovery mode and going back to the system restore point before the updates I'd just installed couldn't fix.

These days, I switch everything possible into "Tell me but don't install automatically" mode, but even that won't stop all problems. The sooner we have an operating system that forcibly restricts where applications can install and modify data, so at the very least we can cleanly and robustly remove and reinstall something that has become flaky, the sooner I'll have some confidence in the software I'm running again. It's amazing that even in 2013 it is still the norm for installers/updaters to just get permission to run as Administrator/root and then crap all over anything they feel like (unless they're browsers, in which case wilfully circumventing the normal security protocols so their updates don't even need to run as Administrator/root to crap all over stuff is apparently acceptable).

Have you ever used a Debian based system with Linux software RAID?

The standard installer will fail and you'll be straight back to hacking config files and manually playing with hard drive partitions, which is totally something you want to do because it's not error prone at all.

For extra credit, if you tried upgrading from 6 to 7 using the normal apt-based commands, don't forget to keep a spare live CD handy in case your system becomes unbootable because it didn't update the boot loader properly on all of your array's drives.

When Debian steps into this millennium by having basic install and update processes that support basic system management functionality, then maybe you're allowed to snipe at Microsoft for screwing things up like today, but not before.

(Serious moment: If the 6->7 GRUB problem does happen to anyone reading this, try switching to boot from one of the other drives in your BIOS. If you hit the usual problem here, probably one drive in your array did get updated properly but it wasn't your default boot drive. If you can figure out which one it was and boot from that instead, you can then fix up the others without resorting to a live CD or other heavyweight recovery mechanism.)

And with Linux, you get the free bonus that if you want to update anything that isn't part of your standard distribution, you're completely safe from unintended side effects. It's now been mathematically proven that no way exists to install out-of-band patches that does not also corrupt the known laws of physics, resulting in a subtle cascade effect that starts unnoticed but will ultimately invert the polarity of the sysadmin's cerebral cortex six months later and cause their brain to explode all over the nearest wall. Therefore no-one is actually foolish enough to try this any more, unless they really are planning to recompile their kernel, reformat their disks and recreate their LVM set-up, and then rebuild every other piece of software from scratch with the latest system libraries and a new GCC flag so it's all still compatible.

Seriously, please don't pretend Linux systems are somehow more maintainable than Windows ones because every now and then MS screw up. Linux systems are absurdly unmaintainable if you stray outside of the controlled environment of a well-managed distribution, and this is a direct result of the architectural foundations and established standards of Linux itself.

Only wimps use tape backup. Real deities just upload their important stuff on FTP and let the rest of the universe mirror it.

The trouble these days is that different types of hard drives have very different characteristics for when they park their heads. A Click of Imminent Death and a Crunch of Routine Head Parking on an enterprisey disk with a long wind-down delay can sound disturbingly similar. (Either that or almost every hard drive in the various machines in the rack in my office really is about to fail, even though none of them report anything disturbing via SMART etc. That would suck.)

And this is why privacy/data protection laws need to be updated to have far more teeth than they have today. When you have an organisation as influential as Facebook and it is actively encouraging other people to do things like providing your picture or your phone number with or without your knowledge or consent, any argument that some use of that data about you is permitted under their ToS has no weight if you're not a Facebook user yourself, but it seems clear that they're storing the data anyway. Actually, I'm not sure how that's not already illegal, at least within the EU, but the regulators don't seem in any hurry to take action and even if they do the penalties are little more than the change in Zuckerberg's pocket.

FWIW, I am similar to you, being well known among my friends as someone who doesn't want to share his personal details with Facebook. I feel sufficiently strongly about this that in the situation you described I would have made it very clear to my "friend" and his wife that I would no longer consider them friends if they thought it was funny to violate my privacy in that way, but then again I'm also confident that I would never have to go that far with anyone I consider a friend in the first place. I'm sorry if you're not always in such a happy position with the company you keep.

Assuming you're talking about the standard library rather than package management, unfortunately it's not just one problem. I'd estimate that I've found 20-25 significant library issues over the past few years of using Python on various projects.

Most of these issues aren't really bugs in the sense that the output is objectively wrong, though. It's more things like OS differences not quite being abstracted away completely so that sometimes running another process needs slightly different presentation of arguments on Linux vs. Windows or some minor detail of a library feature only works on one platform or another, or having a compression library that works but takes 6x as long as spawning a dedicated zip tool to do the same job, or the complexity of setting up a download manually when there are libraries like requests today that show how much simpler it could be.

None of these things are categorically wrong, but they all make the Python standard library less useful than it could be. Sometimes they make it less useful than a popular alternative, at which point there's little reason to have the standard library version around at all other than backward compatibility (hence my comment about if we were starting over).

Well, yes. Levelling the playing field is exactly what government and laws are supposed to do, when there is one party so much more powerful than another that the weaker one can't reasonably protect themselves. What else did you think governments were good for?

(OK, they also play a useful role in standardisation and co-ordination. But when you think about it, almost everything valuable that governments do ultimately comes down to helping people interact fairly and efficiently.)

Why, because I don't feel like living in coastal Somalia?