OK, here's a radical thought for you: perhaps we don't need 'an internet of things'?
As it turns out, we also don't need to post our entire lives on Facebook or Twitter or whatever other "social network" is trendy right now. Nor is it necessary to supply them with metadata on every uploaded photo. I don't use these kinds of networks, and amazingly I haven't died yet, and neither has my social life. It'd be nice if they weren't so easily able to capture data about me anyway by encouraging people who know me to supply it against my will, though; there's something very shady about that kind of behaviour.
Something I've heard a lot recently that's interesting is that the younger generation are actually much less likely to use some of these tools, Facebook in particular, or at least to use it in the manner it wants (real name etc.). This is one of my few comforting thoughts when considering privacy in the age of modern communication and surveillance technologies: the idea that future generations will grow up without appreciating the value of privacy seems to be overstated.
A less comforting thought is that they might not get a choice anyway. If devices that have no need for this kind of intrusive technology start incorporating it routinely, you can't opt out without giving up a huge amount of quality of life. Worse, many useful tools can inherently be abused to track people: think of monitoring personal location via mobile phone connections or card payments or smartcards used to pay for public transport, or recording vehicle movements via ANPR cameras and automated systems for tolls etc.
IMNSHO, we need much stronger laws to prevent repurposing of these kinds of data or retaining it any longer than strictly necessary. I think a big part of the problem is that so many people don't even realise what can be done today and how much is being stored routinely without any good reason that there isn't enough political will to drive change, even though if you told people what was happening they might well object.
Recent Java updates, for around the past year or so, have been increasingly draconian in their security measures. We are now reaching the point where you can't run code that you know is perfectly safe, in ways that have worked for years, even if you are willing to turn down the security settings and accept any associated risk. Much of this is Java's fault, although well-intentioned but buggy browser updates have also broken essential functionality at various points within that time frame.
Security that actually stops you doing your job isn't an improvement, it's just broken.
Also, the idea that merely signing an applet significantly improves the safety of running it is rather strange. Which is really safer to run, an applet I just compiled right there on my own system from our own code using a tried-and-tested build process, or an applet downloaded from a web site I never visited before that could be anything but is signed with a certificate that anyone with a bit of cash and a bit of time can easily obtain?
blacklisting everything by default is the only way forward.
That's fine as long as I, as the user and sometimes developer of applets, can change that default when I want to.
Today I installed Java 7 update 40 and Firefox 24, and for the first time in several weeks I can test our web application running from a local disk without Firefox refusing to even load it, regardless of any lowering of security settings. I suspect this was actually Firefox's fault, because the same application worked fine, applet and all, in other browsers on the same system, but in any case it was a pain in the backside for testing.
However, we don't sign our applications, and for a good reason: they will ultimately be running on embedded systems where there is no way to update them, and the signing certificates you can buy from established CAs are all prohibitively time-limited. I notice that with this release of Java, the scary warning message has been changed to say that in a future release this will be completely blocked.
If that refers only to running from a local system without needing to fire up a web server, that will be an inconvenience for testing again, and helping no-one here. It's not as if an applet we just compiled from our own code is a security risk.
However, if it refers to blocking any unsigned applets, it's going to instantly and permanently break numerous existing installations on embedded systems. Applets are used more than a lot of people realise, and one significant use case is web-based control panels for network-accessible devices. Those devices probably have a working lifetime of many years and if they all stop working overnight because Oracle broke Java, it's not going to go down well.
I understand, and it must be a PITA for you if you absolutely must have the latest tech, bugs and all. But the software and even firmware industry now have a policy of "release THEN patch".
Apparently so, but the entire point of buying one of these expensive workstation cards is to not be in that category because the bugs and downtime really hurt. If the premium cards with "certified" drivers still have obvious serious flaws anyway then there is no point spending the cost of several gaming cards instead of just buying one of them. Really, you couldn't possibly miss the bug we're seeing all the time here with even a basic level of testing of the affected feature, and I've seen way too many similar reports now to believe we're just one isolated case.
So while it's not unreasonable to insist on getting value for your money, it is unreasonable to assume that the software industry responsible for your drivers will change habits that have been entrenched for many years, just to keep you happy.
That may be true, but if so, it is also unreasonable for that industry to expect such a large amount of my companies' money when we buy our professional workstations if they don't provide a professional level of quality control and support to match. For our next generation, if we still go with workstation cards at all, we'll surely switch to "Brand N" instead.
However, given the even greater premium they seem to charge for their workstation-class cards, I'd say it's more likely that we'll just buy "gaming" cards, spend the vast amount of saved budget on upgrading other parts of the systems instead, and take our chances. Relatively few of the major content creation applications actually use hardware acceleration for everyday effects or final renders anyway, even today, nor have any of the ones we use indicated that this will change with their next version, so the whole fast GPU pitch is looking like a dubious benefit anyway, at least for our purposes.
Alternatively, for the price of a high-end Brand N workstation card, we could upgrade everybody's workstation to a dual Xeon with increased RAM and fast storage to match, and probably still have money leftover to give everyone a couple of good 30" monitors as standard. Now if only Dell could make monitors that don't hang...:-/
Driver nightmares? I have zero driver problems on my PC. Of course I never buy the "bleeding edge" brand new "hot video-card for this year just in time for Christmas", either.
That's nice for you. This PC has a very expensive workstation-class card because it's used for content creation and high performance is necessary, and hardware from a generation or two ago couldn't do what we need to do. Maybe that makes us "early adopters", but in that case probably so are most people who buy this type of card, and when we're all paying so much extra for that kind of power, I don't think it's unreasonable to expect AMD to deliver on their most basic promises.
Actually there is more to it than just crippling them artificially. The pro cards go through more extensive testing to make sure that their output is pixel-perfect correct.
That's the sales pitch. I'm still waiting for any practical evidence that a meaningful amount of extra testing actually happens, or produces measurably better results if it does.
Historically, a lot of the practical difference between workstation and gaming cards has been in their floating point precision and performance, and that is definitely an area where major product lines have been artificially nerfed. Sometimes this has been embarrassingly obvious, for example when a new, high-spec gaming card that should clearly perform better in content creation applications than a predecessor from the last generation was in fact much slower.
Other than lamenting online, the users (no matter if they are casual gamers or professional users) have no other option but to wait for a newer version of the drivers, or roll back the drivers to one that worked.
No, I think we have at least one other option: next time we're specifying new workstations, we can just use (relatively) cheap gaming cards, instead of paying a factor-of-several premium for workstation cards. The latter are often the same basic hardware, but cost more because their "certified" drivers supposedly have better performance and guaranteed compatibility with major content creation applications. Why pay the premium if the reality is that the premium drivers are no better (or, in this case, much worse) than what you could get a few years ago with a basic gaming card?
AMD also seem to have some serious problems, which seem to be worsening with each new driver, on their premium workstation cards when driving multiple displays. We've seen numerous video playback issues, including glitches away from the video area itself, on multi-display configurations. The most likely culprit at the moment seems to be changes in the GPU memory timing. I really hope they fix this soon, because our "professional" workstations are giving our professionals headaches right now.
Indeed. The idea that someone would write some good code and then voluntarily just give it away to anyone who wants it is silly. If you want to get contributions back in return for your freely available code, GPL is the only viable strategy. That's why no-one ever gifted their code to others before the GPL was published, why there is no code out there today that uses dumb licences like BSD and there won't be tomorrow either, and why even if there were it would all come from single individual contributors without any kind of collaboration.
(And yes, the above is 100% sarcasm, so sorry if that offends anyone. I couldn't think of a serious way to respond to the absurd implication that the only people who use BSD are freeloaders who never contribute back.)
You shouldn't make assumption, that makes you look like an ass.
My "assumption" is based directly on what you wrote. Unless you want me to be telepathic, when you explicitly describe a different situation to what I described, I'm going to assume you did that for a reason.
You also seem to forget that there is a selection bias at work: you usually hear of the problems, not of the working installations.
Selection bias is about anecdotes or partial data, but I'm talking about a confirmed, reproducible problem that will affect anyone who tries to do the same thing. Selection bias is not an applicable concept here.
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.
On ‘nix systems, with any reasonably maintained package, it’s trivial
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.
Ok, so how do I install a third-party kernel patch for windows?
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?
When you update a component that doesn't change it's ABI then nothing needs done, If the ABI does change you can recompile just the binaries that try to link to the old library.
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.
That's like saying 'Windows is absurdly unmaintainable if you start randomly deleting system files you don't think you need'.
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.
BTW, maybe you could explain how to fix my old XP machine
Would you also like help getting Debian Potato running on your i7?
That is simply just not true. You keep the stuff you build separate from what the OS lays down, and ne'er the twain shall meet.
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.
And it's not just a Microsoft problem - I have also seen similar issues from Apple and Canonical.
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.
Spinning drives fail all the time, but at least you can hear the click of death starting.
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.)
So, I'm in their system, despite being really well known as the paranoid "they're out to get me" guy to pretty much everyone who knows me.
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).
Slashdot Mirror
OK, here's a radical thought for you: perhaps we don't need 'an internet of things'?
As it turns out, we also don't need to post our entire lives on Facebook or Twitter or whatever other "social network" is trendy right now. Nor is it necessary to supply them with metadata on every uploaded photo. I don't use these kinds of networks, and amazingly I haven't died yet, and neither has my social life. It'd be nice if they weren't so easily able to capture data about me anyway by encouraging people who know me to supply it against my will, though; there's something very shady about that kind of behaviour.
Something I've heard a lot recently that's interesting is that the younger generation are actually much less likely to use some of these tools, Facebook in particular, or at least to use it in the manner it wants (real name etc.). This is one of my few comforting thoughts when considering privacy in the age of modern communication and surveillance technologies: the idea that future generations will grow up without appreciating the value of privacy seems to be overstated.
A less comforting thought is that they might not get a choice anyway. If devices that have no need for this kind of intrusive technology start incorporating it routinely, you can't opt out without giving up a huge amount of quality of life. Worse, many useful tools can inherently be abused to track people: think of monitoring personal location via mobile phone connections or card payments or smartcards used to pay for public transport, or recording vehicle movements via ANPR cameras and automated systems for tolls etc.
IMNSHO, we need much stronger laws to prevent repurposing of these kinds of data or retaining it any longer than strictly necessary. I think a big part of the problem is that so many people don't even realise what can be done today and how much is being stored routinely without any good reason that there isn't enough political will to drive change, even though if you told people what was happening they might well object.
Am I the only person thinking that we used to call these social contracts "laws"?
(assuming that's what it does)
Unfortunately, it isn't.
Recent Java updates, for around the past year or so, have been increasingly draconian in their security measures. We are now reaching the point where you can't run code that you know is perfectly safe, in ways that have worked for years, even if you are willing to turn down the security settings and accept any associated risk. Much of this is Java's fault, although well-intentioned but buggy browser updates have also broken essential functionality at various points within that time frame.
Security that actually stops you doing your job isn't an improvement, it's just broken.
Also, the idea that merely signing an applet significantly improves the safety of running it is rather strange. Which is really safer to run, an applet I just compiled right there on my own system from our own code using a tried-and-tested build process, or an applet downloaded from a web site I never visited before that could be anything but is signed with a certificate that anyone with a bit of cash and a bit of time can easily obtain?
blacklisting everything by default is the only way forward.
That's fine as long as I, as the user and sometimes developer of applets, can change that default when I want to.
Today I installed Java 7 update 40 and Firefox 24, and for the first time in several weeks I can test our web application running from a local disk without Firefox refusing to even load it, regardless of any lowering of security settings. I suspect this was actually Firefox's fault, because the same application worked fine, applet and all, in other browsers on the same system, but in any case it was a pain in the backside for testing.
However, we don't sign our applications, and for a good reason: they will ultimately be running on embedded systems where there is no way to update them, and the signing certificates you can buy from established CAs are all prohibitively time-limited. I notice that with this release of Java, the scary warning message has been changed to say that in a future release this will be completely blocked.
If that refers only to running from a local system without needing to fire up a web server, that will be an inconvenience for testing again, and helping no-one here. It's not as if an applet we just compiled from our own code is a security risk.
However, if it refers to blocking any unsigned applets, it's going to instantly and permanently break numerous existing installations on embedded systems. Applets are used more than a lot of people realise, and one significant use case is web-based control panels for network-accessible devices. Those devices probably have a working lifetime of many years and if they all stop working overnight because Oracle broke Java, it's not going to go down well.
I understand, and it must be a PITA for you if you absolutely must have the latest tech, bugs and all. But the software and even firmware industry now have a policy of "release THEN patch".
Apparently so, but the entire point of buying one of these expensive workstation cards is to not be in that category because the bugs and downtime really hurt. If the premium cards with "certified" drivers still have obvious serious flaws anyway then there is no point spending the cost of several gaming cards instead of just buying one of them. Really, you couldn't possibly miss the bug we're seeing all the time here with even a basic level of testing of the affected feature, and I've seen way too many similar reports now to believe we're just one isolated case.
So while it's not unreasonable to insist on getting value for your money, it is unreasonable to assume that the software industry responsible for your drivers will change habits that have been entrenched for many years, just to keep you happy.
That may be true, but if so, it is also unreasonable for that industry to expect such a large amount of my companies' money when we buy our professional workstations if they don't provide a professional level of quality control and support to match. For our next generation, if we still go with workstation cards at all, we'll surely switch to "Brand N" instead.
However, given the even greater premium they seem to charge for their workstation-class cards, I'd say it's more likely that we'll just buy "gaming" cards, spend the vast amount of saved budget on upgrading other parts of the systems instead, and take our chances. Relatively few of the major content creation applications actually use hardware acceleration for everyday effects or final renders anyway, even today, nor have any of the ones we use indicated that this will change with their next version, so the whole fast GPU pitch is looking like a dubious benefit anyway, at least for our purposes.
Alternatively, for the price of a high-end Brand N workstation card, we could upgrade everybody's workstation to a dual Xeon with increased RAM and fast storage to match, and probably still have money leftover to give everyone a couple of good 30" monitors as standard. Now if only Dell could make monitors that don't hang... :-/
Driver nightmares? I have zero driver problems on my PC. Of course I never buy the "bleeding edge" brand new "hot video-card for this year just in time for Christmas", either.
That's nice for you. This PC has a very expensive workstation-class card because it's used for content creation and high performance is necessary, and hardware from a generation or two ago couldn't do what we need to do. Maybe that makes us "early adopters", but in that case probably so are most people who buy this type of card, and when we're all paying so much extra for that kind of power, I don't think it's unreasonable to expect AMD to deliver on their most basic promises.
Actually there is more to it than just crippling them artificially. The pro cards go through more extensive testing to make sure that their output is pixel-perfect correct.
That's the sales pitch. I'm still waiting for any practical evidence that a meaningful amount of extra testing actually happens, or produces measurably better results if it does.
Historically, a lot of the practical difference between workstation and gaming cards has been in their floating point precision and performance, and that is definitely an area where major product lines have been artificially nerfed. Sometimes this has been embarrassingly obvious, for example when a new, high-spec gaming card that should clearly perform better in content creation applications than a predecessor from the last generation was in fact much slower.
Other than lamenting online, the users (no matter if they are casual gamers or professional users) have no other option but to wait for a newer version of the drivers, or roll back the drivers to one that worked.
No, I think we have at least one other option: next time we're specifying new workstations, we can just use (relatively) cheap gaming cards, instead of paying a factor-of-several premium for workstation cards. The latter are often the same basic hardware, but cost more because their "certified" drivers supposedly have better performance and guaranteed compatibility with major content creation applications. Why pay the premium if the reality is that the premium drivers are no better (or, in this case, much worse) than what you could get a few years ago with a basic gaming card?
AMD also seem to have some serious problems, which seem to be worsening with each new driver, on their premium workstation cards when driving multiple displays. We've seen numerous video playback issues, including glitches away from the video area itself, on multi-display configurations. The most likely culprit at the moment seems to be changes in the GPU memory timing. I really hope they fix this soon, because our "professional" workstations are giving our professionals headaches right now.
BSD is great for wannabe Robber Barons.
Indeed. The idea that someone would write some good code and then voluntarily just give it away to anyone who wants it is silly. If you want to get contributions back in return for your freely available code, GPL is the only viable strategy. That's why no-one ever gifted their code to others before the GPL was published, why there is no code out there today that uses dumb licences like BSD and there won't be tomorrow either, and why even if there were it would all come from single individual contributors without any kind of collaboration.
(And yes, the above is 100% sarcasm, so sorry if that offends anyone. I couldn't think of a serious way to respond to the absurd implication that the only people who use BSD are freeloaders who never contribute back.)
You shouldn't make assumption, that makes you look like an ass.
My "assumption" is based directly on what you wrote. Unless you want me to be telepathic, when you explicitly describe a different situation to what I described, I'm going to assume you did that for a reason.
You also seem to forget that there is a selection bias at work: you usually hear of the problems, not of the working installations.
Selection bias is about anecdotes or partial data, but I'm talking about a confirmed, reproducible problem that will affect anyone who tries to do the same thing. Selection bias is not an applicable concept here.
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.
On ‘nix systems, with any reasonably maintained package, it’s trivial
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.
Ok, so how do I install a third-party kernel patch for windows?
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?
When you update a component that doesn't change it's ABI then nothing needs done, If the ABI does change you can recompile just the binaries that try to link to the old library.
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.
That's like saying 'Windows is absurdly unmaintainable if you start randomly deleting system files you don't think you need'.
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.
BTW, maybe you could explain how to fix my old XP machine
Would you also like help getting Debian Potato running on your i7?
That is simply just not true. You keep the stuff you build separate from what the OS lays down, and ne'er the twain shall meet.
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.
And it's not just a Microsoft problem - I have also seen similar issues from Apple and Canonical.
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:
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.
Spinning drives fail all the time, but at least you can hear the click of death starting.
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.)
So, I'm in their system, despite being really well known as the paranoid "they're out to get me" guy to pretty much everyone who knows me.
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).