The patterns are really the crux of the problem. Design patterns are an excellent tool, but applying the same design pattern to every problem doesn't make sense. They need to be selected to match the problem. That's where the frameworks go wrong. At least the ones I've seen attempt to wedge everything an MVC pattern on the server side, which really leads to a lot of confusion (and enough misunderstanding of what MVC means that the term no longer means anything).
If you can really use the Zend libraries without pulling in all the other cruft than that's great. Choose them if they suit the task. Then you're really just doing what I suggested to begin with - selecting the best libraries for the job. (My impression was that this wasn't possible, but I didn't dig very deeply into Zend - by the time I looked at it I'd already developed a deep hatred of frameworks.)
Apache is generic knowledge in that you can apply it to a wider range of problems, and since every installation needs a web server, it's not something "extra". You have the tool already - learn to use it. Same with Nginx or one of the SQL servers. Every component you add has a cost in maintenance and complexity, so don't add more components until you've fully exploited the existing ones.
My main complaint with frameworks isn't efficiency. But you have touched on another problem. I know one poor sucker whose life is now devoted to trying to optimize an all-php solution, when a few weeks of investment in a Jave or C component would speed up his application 100-fold. Alas, try convincing a project manager that you need to invest a few weeks optimizing without producing any new features. He'll be stuck tuning that app and trying to squeeze performance out of Memcache until he burns out.
As long as your application domain is very close to what the framework was built for, yes. That's why I made the exception for slapping together quick, form-based, database apps.
For other cases, you're trying to make a design that works well for one case fit another. Better to invest the time learning to apply more general tools that you can adapt to your problem.
... unless you're in the business of throwing together form-based database apps quickly.
That's really all they do well, and there area lot of form-based database applications in the real world, so that's not a small niche.
But for anything that's a little different, you end up spending a lot of time learning the framework, and then even more time working around its limitations. The better approach is to look at your problem and find a set of libraries that are well suited to the task at hand, well documented, well supported, and modular.
Also, take the time to learn your tools properly and exploit them to the fullest. Learning a framework takes time. So does learning about Apache modules and SQL stored procedures. The difference is that the time invested in the framework isn't generally applicable to other problem domains, while Apache and SQL are everywhere, and are worth learning well.
The global menu is the problem for a significant number of people.
I could learn to live with just about every other Unity change, but the global menu drives me bonkers. When my visual focus is on an app window on my second display, I expect to be able to go to that window in order to work with the app. I don't expect to have to click on the window first, then move my mouse to the other display in order to access a menu that (oddly ) isn't located anywhere near my application window.
I've never understood why Apple sticks with this setup. It made sense with the original Mac, which had a tiny screen and didn't really support multi-tasking. It's a huge usability problem for modern desktops with multiple, large displays.
You can also copyright header files that define these APIs. And the files would "enjoy" the same protection as books and such - mere renaming of everything, shuffling the order around or changing comments, without actually breaking the gist - the underlying concept - will be recognized as plagiarism.
This is the crux of the issue. My understanding (and I guess also Google's understanding) of copyright law is that the copyright is only for the "creative" element of the work, and explicitly excludes things required for interoperability.
So if you take out all the comments, organize the remaining header in a completely non-creative way (ie. sorted by subject area, and then alphabetically), and remove any lingering "private" parts that aren't strictly part of the API, what remains should not be subject to copyright.
It may be true that this has never been tested in court, so I don't know were I got the idea that this is how things worked, but if I'm wrong then I've been under this delusion for at least ten years or so.
I'm sorry you don't trust your government, but it's just a fact that they're the only organization that can verify your identity. A private third party (like Verisign or some hypothetical non-profit) will rely on government ID to establish your identity as well. Given that these private groups don't add any real value, it's silly to pay them money for something the government can do more efficiently.
If you don't trust your government to perform this service, then you've got bigger problems. If the government wants to impersonate you, they can make some fake ID, get credit cards, SSL certificates, etc. in your name, and even arrange it so that your real identity looks like the fake one.
And to be honest, I think even in the U.S., your government is more trustworthy than the likes of Verisign.
These are oganizations that we already deal with and are in the business of establishing our identities and securing transactions.
When you're paying money on-line, you (or your browser) should sign the payment authorization using your own bank account's private key (provided for free with your account) and the encrypted with the public key for the destination account. The recipient will submit the signed authorization to his bank for payment.
For SSL protection of your web site, the government should issue SSL certificates as a free option whenever they are confirming your identity anyway. For people the obvious touch-points are when you get a social security card, driver's license, passport, or birth certificate. For companies, the certificate should be part of your company registration.
I live in Finland and have friends/contacts/etc. who are involved in MeeGo both professionally and as a hobby.
Shortly after the Microsoft announcement, Intel spread the work among Nokia MeeGo people, and held a huge recruiting event. In the meantime, third-party subcontractors who were doing a lot of MeeGo work for Nokia are now getting contracts from Intel.
It makes sense, if you think about it. Intel desparately needs to make inroads into the mobile market. MeeGo was a part of that strategy, and suddenly it was undercut by Nokia. Hiring a few hundred developers to keep that strategy alive is peanuts for a company the size of Intel, and well worth the investment.
I don't have a strong opinion on the one/two-party law issue, but it doesn't appear to be much of a factor in this case anyway.
The ACLU pdf says that, even in Maryland, you only need permission if there is an expectation of privacy, and the Attorney General gave a legal opinion previously that people who are passing an arrest that is being recorded by the police don't have an expectation of privacy.
If an uninvolved passerby doesn't have an expectation of privacy, then it's hard to imagine how somebody directly involved in the incident has an expectation of privacy.
I seriously doubt anybody will get more than a slap on the wrist.
This is a problem pretty much everywhere. When law enforcement does nasty stuff they're rarely punished. If a private citizen pulled a gun on a motorist, then broke into his home, kidnapped him for 26 hours, and stole this computers, there would be serious prison time, but when cops do this there are no real consequences.
I think that it would probably help the majority of decent, competent cops to do their jobs if the bad ones (and their superiors) were fired and punished when they pulled this sort of crap, but whenever anybody calls for bad cops to be held accountable, police unions raise a stink.
Telling somebody what they've done to violate terms-of-service shouldn't be a problem. You don't need to give away how you caught them, just what it is you think they did wrong.
Surely a one-liner along the lines of "we believe you're using your Groups account for spam" should be ok, it would make the whole experience a lot less Kafkaesque.
I'm not sure if you're following this (as I'm slow to respond - different time zone and not online all day)... but...
Hmm. Can you point out the "constitutional preference for free markets" in the actual constitution? Actually, doesn't really matter. The consensus around the world is a preference for free markets, so that's not really unique to the U.S.
But most people (including most people in the U.S., as near as I can tell) acknowledge that free markets have limitations. In this case, the key elements for a well functioning market that are missing are competition and an informed consumer. People are simply very poor at judging risk, so they don't know what insurance is really worth to them. They also don't understand the legalese of insurance contracts, so they might not be purchasing what they think they are. A competitive market in insurance is difficult to maintain because economies of scale are so important in the insurance industry - the more customers you have, the better you can spread risk. So you can open up markets to interstate competition (not a bad idea as long as it's properly regulated), but that will just end up with consolidation - the insurance companies will just buy each other up until there are only two or three left.
I fail to see how any of the measures in the U.S. health care bill, or for that matter any of the real "socialized" health care systems in the world, affect incentives for R&D. You're making the assertion that the bill goes "WELL beyond just changing the way health care is delivered", but as I understand it, the bill doesn't change how health care is delivered at all. The change is limited to how health care is paid for (consumer-side rather than supply-side).
To make you case convincing you need to demonstrate that somehow the American health INSURANCE industry encourages R&D. The evidence that you brought before, that so much medical R&D happens in the U.S., doesn't really make your case.
I could just as easily argue the opposite. If the 30% or so (from memory - but I can try to find a link if you like) of overhead that goes to the insurance industry in the U.S. were spent on health care, then there would be more money for actual treatment and more of that money could go into research.
Ack. Hard to read your post because it's all one paragraph. But you start with an assertion that's demonstrably false, so it tends to undermine anything else you say that might have merit.
First, the biggest funder of medical research in the U.S. and throughout the world is government. That's not likely to change regardless of how health care is provided.
Second, even the Cato study (which you're probably referring to) found that 40 percent of what they termed "innovations" happened in countries with "socialized medicine". Now I haven't researched the details of the study (though I tend to be very suspicious of anything Cato writes), but I think it's plausible that the U.S. contributes more than its fair share to medical science. I would need evidence aside from Cato, but I wouldn't be all that surprised if it were true.
But even if I were to accept that, it doesn't follow that this is due to the American health care system. There are at least two confounding factors that I can think of right off the top of my head:
1. The market for medical research is global. American companies that do R&D sell their products all over the world. While the U.S. is a huge market, it's still only a fraction of the global market, so there's no reason to believe that Americans paying less for health care would significantly reduce investment in R&D.
2. While Americans do pay more than anybody else for health care, most of that goes into insurance industry overhead. It would be interesting to know how much of the additional money paid by Americans for health care actually goes into research, but it's clearly not a huge amount.
From what I gather following the debate from Europe, Americans seems to be unable to look at this issue realistically. Free markets are good, in general, but they have problems. If you assume that free markets are always the best solution then you're taking an idealogical position when what's really called for is a careful examination of the actual problem at hand.
RTFA -- he doesn't mean criticism == slagging off, he means criticism as is "critical evaluation". What Linux has is a lot of slaggers and very few critical evaluators. All the deconstruction of design decisions are carried out by the dev guys -- there is no detached observer.
Actually most criticism comes from users. True, they're not "detached observer"s, but I don't see a lot of that in any part of the industry. The people who bother to criticise something generally do so because they have some stake in it.
Maybe he's referring to journalists, who are paid to at least appear objective. But I've seen lots of reviews of Linux stuff (including Ubuntu), and they point out both the good and the bad.
Er, no, I really have no problem with criticism of Linux. The article is strange because he thinks there's a currently a lack of criticism, whereas I see tons of it everywhere.
Somehow the author seems to have missed the copious blog posts, mailing list messages, software reviews, and competitor astroturf all criticising Linux.
I would even go so far as to say that Linux (and the Free Software ecosystem that surrounds it) has a lot more critics than closed software - or at least more effective critics.
Large software companies pay PR departments to generate positive coverage. Most Open Source projects have no PR effort behind them at all. So criticism of the software is less likely to be drowned out by astroturf.
True enough, but... patterns can be pretty arbitrary, and also potentially quite long. Like: "qwer asdf zxcv fjfrmvu". Clearly not random, but still chosen from a very large space of similar patterns.
My PINs were given to me by the bank, so they weren't chosen for the pattern, but rather the pattern is what I ended up remembering, so not an issue there.
Have her make a pattern on the keyboard that she can remember. I've actually had a number of PIN codes that I didn't actually remember apart from the pattern they make on the numeric keypad.
I can't speak for the grandparent and his problems with Windows, but for me it's much easier and faster to be productive using Linux.
Ubuntu installs painlessly on all the hardware I care about (although I did have to take a live CD with me when buying my laptop to make sure everything worked, but that was pretty painless).
When I update my OS, all my other software is updated as well, so I'm always up-to-date with security patches for everything, with almost zero effort on my part.
I could probably find Windows equivalents of all the software I use, but it would take a lot of time, and probably I'd have to buy a lot of commercial packages. Even if the money weren't a factor, the hassle of ordering software, waiting for it to arrive, and then installing it on Windows is much more than just searching for what I want in Synaptic and clicking on 'install'.
I suppose if Microsoft someday comes with with a truly brilliant version of Windows I might try it out if I've got extra time on my hands, but until then Windows just isn't worth the hassle.
No amount of data can prove the assertion, but you can disprove it with a single counterexample. (But the test isn't whether or not it's GNU, but rather whether or not it has Free Software roots.)
The distributions and hardware vendors themselves.
It isn't 1995 anymore. There's no way a single vendor like Sun can put more resources into testing than the Linux distributions + all the major hardware vendors (IBM, HP, Dell, etc.).
Rather you should ask yourself, who tests each release of Solaris against all the different hardware out there?
Solaris has a couple of nice features, but the Linux driver issue isn't a problem on servers.
The drivers on Linux that are a problem are mostly on consumer hardware - accelerated video in particular - where manufacturers refuse to release specifications. On server hardware high quality Open Source drivers are available for just about everything so upgrades go very smoothly. Everything "just works". Plus, on Intel hardware, Linux has better driver support than Solaris.
That makes sense since nowadays no serious server hardware vendor can refuse to support Linux. It comes with being a "mainstream" operating system - the same advantage Windows has on consumer hardware. Linus dictated that the driver ABI is not stable, and he has enough clout in the server market that the hardware vendors just have to suck it up and release source.
ZFS and DTrace are areas where Solaris is legitimately ahead.
Are you sure about that? I confess that I haven't tried running old binaries on new systems (with source code available there doesn't seem to be much need) but I know that the Linus, at least, is dogmatic about making sure that the Linux system call interface is always backwards compatible. You can run binaries that were compiled against Linux < 1 unmodified today.
I'm not as confident that the same is true of userspace, but I bet it's not that different. Where there have been incompatible user-space ABI changes (glibc, gtk) the distributions I've used make the older versions available and useable alongside the newer versions.
Slashdot Mirror
The patterns are really the crux of the problem. Design patterns are an excellent tool, but applying the same design pattern to every problem doesn't make sense. They need to be selected to match the problem. That's where the frameworks go wrong. At least the ones I've seen attempt to wedge everything an MVC pattern on the server side, which really leads to a lot of confusion (and enough misunderstanding of what MVC means that the term no longer means anything).
If you can really use the Zend libraries without pulling in all the other cruft than that's great. Choose them if they suit the task. Then you're really just doing what I suggested to begin with - selecting the best libraries for the job. (My impression was that this wasn't possible, but I didn't dig very deeply into Zend - by the time I looked at it I'd already developed a deep hatred of frameworks.)
Apache is generic knowledge in that you can apply it to a wider range of problems, and since every installation needs a web server, it's not something "extra". You have the tool already - learn to use it. Same with Nginx or one of the SQL servers. Every component you add has a cost in maintenance and complexity, so don't add more components until you've fully exploited the existing ones.
My main complaint with frameworks isn't efficiency. But you have touched on another problem. I know one poor sucker whose life is now devoted to trying to optimize an all-php solution, when a few weeks of investment in a Jave or C component would speed up his application 100-fold. Alas, try convincing a project manager that you need to invest a few weeks optimizing without producing any new features. He'll be stuck tuning that app and trying to squeeze performance out of Memcache until he burns out.
As long as your application domain is very close to what the framework was built for, yes. That's why I made the exception for slapping together quick, form-based, database apps.
For other cases, you're trying to make a design that works well for one case fit another. Better to invest the time learning to apply more general tools that you can adapt to your problem.
... unless you're in the business of throwing together form-based database apps quickly.
That's really all they do well, and there area lot of form-based database applications in the real world, so that's not a small niche.
But for anything that's a little different, you end up spending a lot of time learning the framework, and then even more time working around its limitations. The better approach is to look at your problem and find a set of libraries that are well suited to the task at hand, well documented, well supported, and modular.
Also, take the time to learn your tools properly and exploit them to the fullest. Learning a framework takes time. So does learning about Apache modules and SQL stored procedures. The difference is that the time invested in the framework isn't generally applicable to other problem domains, while Apache and SQL are everywhere, and are worth learning well.
The global menu is the problem for a significant number of people.
I could learn to live with just about every other Unity change, but the global menu drives me bonkers. When my visual focus is on an app window on my second display, I expect to be able to go to that window in order to work with the app. I don't expect to have to click on the window first, then move my mouse to the other display in order to access a menu that (oddly ) isn't located anywhere near my application window.
I've never understood why Apple sticks with this setup. It made sense with the original Mac, which had a tiny screen and didn't really support multi-tasking. It's a huge usability problem for modern desktops with multiple, large displays.
You can also copyright header files that define these APIs. And the files would "enjoy" the same protection as books and such - mere renaming of everything, shuffling the order around or changing comments, without actually breaking the gist - the underlying concept - will be recognized as plagiarism.
This is the crux of the issue. My understanding (and I guess also Google's understanding) of copyright law is that the copyright is only for the "creative" element of the work, and explicitly excludes things required for interoperability.
So if you take out all the comments, organize the remaining header in a completely non-creative way (ie. sorted by subject area, and then alphabetically), and remove any lingering "private" parts that aren't strictly part of the API, what remains should not be subject to copyright.
It may be true that this has never been tested in court, so I don't know were I got the idea that this is how things worked, but if I'm wrong then I've been under this delusion for at least ten years or so.
I'm sorry you don't trust your government, but it's just a fact that they're the only organization that can verify your identity. A private third party (like Verisign or some hypothetical non-profit) will rely on government ID to establish your identity as well. Given that these private groups don't add any real value, it's silly to pay them money for something the government can do more efficiently.
If you don't trust your government to perform this service, then you've got bigger problems. If the government wants to impersonate you, they can make some fake ID, get credit cards, SSL certificates, etc. in your name, and even arrange it so that your real identity looks like the fake one.
And to be honest, I think even in the U.S., your government is more trustworthy than the likes of Verisign.
These are oganizations that we already deal with and are in the business of establishing our identities and securing transactions.
When you're paying money on-line, you (or your browser) should sign the payment authorization using your own bank account's private key (provided for free with your account) and the encrypted with the public key for the destination account. The recipient will submit the signed authorization to his bank for payment.
For SSL protection of your web site, the government should issue SSL certificates as a free option whenever they are confirming your identity anyway. For people the obvious touch-points are when you get a social security card, driver's license, passport, or birth certificate. For companies, the certificate should be part of your company registration.
Yup, this is happening.
I live in Finland and have friends/contacts/etc. who are involved in MeeGo both professionally and as a hobby.
Shortly after the Microsoft announcement, Intel spread the work among Nokia MeeGo people, and held a huge recruiting event. In the meantime, third-party subcontractors who were doing a lot of MeeGo work for Nokia are now getting contracts from Intel.
It makes sense, if you think about it. Intel desparately needs to make inroads into the mobile market. MeeGo was a part of that strategy, and suddenly it was undercut by Nokia. Hiring a few hundred developers to keep that strategy alive is peanuts for a company the size of Intel, and well worth the investment.
I don't have a strong opinion on the one/two-party law issue, but it doesn't appear to be much of a factor in this case anyway.
The ACLU pdf says that, even in Maryland, you only need permission if there is an expectation of privacy, and the Attorney General gave a legal opinion previously that people who are passing an arrest that is being recorded by the police don't have an expectation of privacy.
If an uninvolved passerby doesn't have an expectation of privacy, then it's hard to imagine how somebody directly involved in the incident has an expectation of privacy.
I seriously doubt anybody will get more than a slap on the wrist.
This is a problem pretty much everywhere. When law enforcement does nasty stuff they're rarely punished. If a private citizen pulled a gun on a motorist, then broke into his home, kidnapped him for 26 hours, and stole this computers, there would be serious prison time, but when cops do this there are no real consequences.
I think that it would probably help the majority of decent, competent cops to do their jobs if the bad ones (and their superiors) were fired and punished when they pulled this sort of crap, but whenever anybody calls for bad cops to be held accountable, police unions raise a stink.
Telling somebody what they've done to violate terms-of-service shouldn't be a problem. You don't need to give away how you caught them, just what it is you think they did wrong. Surely a one-liner along the lines of "we believe you're using your Groups account for spam" should be ok, it would make the whole experience a lot less Kafkaesque.
I'm not sure if you're following this (as I'm slow to respond - different time zone and not online all day)... but...
Hmm. Can you point out the "constitutional preference for free markets" in the actual constitution? Actually, doesn't really matter. The consensus around the world is a preference for free markets, so that's not really unique to the U.S.
But most people (including most people in the U.S., as near as I can tell) acknowledge that free markets have limitations. In this case, the key elements for a well functioning market that are missing are competition and an informed consumer. People are simply very poor at judging risk, so they don't know what insurance is really worth to them. They also don't understand the legalese of insurance contracts, so they might not be purchasing what they think they are. A competitive market in insurance is difficult to maintain because economies of scale are so important in the insurance industry - the more customers you have, the better you can spread risk. So you can open up markets to interstate competition (not a bad idea as long as it's properly regulated), but that will just end up with consolidation - the insurance companies will just buy each other up until there are only two or three left.
I fail to see how any of the measures in the U.S. health care bill, or for that matter any of the real "socialized" health care systems in the world, affect incentives for R&D. You're making the assertion that the bill goes "WELL beyond just changing the way health care is delivered", but as I understand it, the bill doesn't change how health care is delivered at all. The change is limited to how health care is paid for (consumer-side rather than supply-side).
To make you case convincing you need to demonstrate that somehow the American health INSURANCE industry encourages R&D. The evidence that you brought before, that so much medical R&D happens in the U.S., doesn't really make your case.
I could just as easily argue the opposite. If the 30% or so (from memory - but I can try to find a link if you like) of overhead that goes to the insurance industry in the U.S. were spent on health care, then there would be more money for actual treatment and more of that money could go into research.
Ack. Hard to read your post because it's all one paragraph. But you start with an assertion that's demonstrably false, so it tends to undermine anything else you say that might have merit.
First, the biggest funder of medical research in the U.S. and throughout the world is government. That's not likely to change regardless of how health care is provided.
Second, even the Cato study (which you're probably referring to) found that 40 percent of what they termed "innovations" happened in countries with "socialized medicine". Now I haven't researched the details of the study (though I tend to be very suspicious of anything Cato writes), but I think it's plausible that the U.S. contributes more than its fair share to medical science. I would need evidence aside from Cato, but I wouldn't be all that surprised if it were true.
But even if I were to accept that, it doesn't follow that this is due to the American health care system. There are at least two confounding factors that I can think of right off the top of my head:
1. The market for medical research is global. American companies that do R&D sell their products all over the world. While the U.S. is a huge market, it's still only a fraction of the global market, so there's no reason to believe that Americans paying less for health care would significantly reduce investment in R&D.
2. While Americans do pay more than anybody else for health care, most of that goes into insurance industry overhead. It would be interesting to know how much of the additional money paid by Americans for health care actually goes into research, but it's clearly not a huge amount.
From what I gather following the debate from Europe, Americans seems to be unable to look at this issue realistically. Free markets are good, in general, but they have problems. If you assume that free markets are always the best solution then you're taking an idealogical position when what's really called for is a careful examination of the actual problem at hand.
You say that as though you've read it.
Correct. I did read it.
RTFA -- he doesn't mean criticism == slagging off, he means criticism as is "critical evaluation". What Linux has is a lot of slaggers and very few critical evaluators. All the deconstruction of design decisions are carried out by the dev guys -- there is no detached observer.
Actually most criticism comes from users. True, they're not "detached observer"s, but I don't see a lot of that in any part of the industry. The people who bother to criticise something generally do so because they have some stake in it.
Maybe he's referring to journalists, who are paid to at least appear objective. But I've seen lots of reviews of Linux stuff (including Ubuntu), and they point out both the good and the bad.
Er, no, I really have no problem with criticism of Linux. The article is strange because he thinks there's a currently a lack of criticism, whereas I see tons of it everywhere.
Somehow the author seems to have missed the copious blog posts, mailing list messages, software reviews, and competitor astroturf all criticising Linux.
Indeed. What a strange article.
I would even go so far as to say that Linux (and the Free Software ecosystem that surrounds it) has a lot more critics than closed software - or at least more effective critics.
Large software companies pay PR departments to generate positive coverage. Most Open Source projects have no PR effort behind them at all. So criticism of the software is less likely to be drowned out by astroturf.
The newer ones all have AGPS.
True enough, but... patterns can be pretty arbitrary, and also potentially quite long. Like: "qwer asdf zxcv fjfrmvu". Clearly not random, but still chosen from a very large space of similar patterns.
My PINs were given to me by the bank, so they weren't chosen for the pattern, but rather the pattern is what I ended up remembering, so not an issue there.
Have her make a pattern on the keyboard that she can remember. I've actually had a number of PIN codes that I didn't actually remember apart from the pattern they make on the numeric keypad.
I can't speak for the grandparent and his problems with Windows, but for me it's much easier and faster to be productive using Linux.
I suppose if Microsoft someday comes with with a truly brilliant version of Windows I might try it out if I've got extra time on my hands, but until then Windows just isn't worth the hassle.
No amount of data can prove the assertion, but you can disprove it with a single counterexample. (But the test isn't whether or not it's GNU, but rather whether or not it has Free Software roots.)
So do you have a counterexample?
Don't let it get you down, young'n. ... Ami.
The distributions and hardware vendors themselves.
It isn't 1995 anymore. There's no way a single vendor like Sun can put more resources into testing than the Linux distributions + all the major hardware vendors (IBM, HP, Dell, etc.).
Rather you should ask yourself, who tests each release of Solaris against all the different hardware out there?
Solaris has a couple of nice features, but the Linux driver issue isn't a problem on servers.
The drivers on Linux that are a problem are mostly on consumer hardware - accelerated video in particular - where manufacturers refuse to release specifications. On server hardware high quality Open Source drivers are available for just about everything so upgrades go very smoothly. Everything "just works". Plus, on Intel hardware, Linux has better driver support than Solaris.
That makes sense since nowadays no serious server hardware vendor can refuse to support Linux. It comes with being a "mainstream" operating system - the same advantage Windows has on consumer hardware. Linus dictated that the driver ABI is not stable, and he has enough clout in the server market that the hardware vendors just have to suck it up and release source.
ZFS and DTrace are areas where Solaris is legitimately ahead.
Are you sure about that? I confess that I haven't tried running old binaries on new systems (with source code available there doesn't seem to be much need) but I know that the Linus, at least, is dogmatic about making sure that the Linux system call interface is always backwards compatible. You can run binaries that were compiled against Linux < 1 unmodified today.
I'm not as confident that the same is true of userspace, but I bet it's not that different. Where there have been incompatible user-space ABI changes (glibc, gtk) the distributions I've used make the older versions available and useable alongside the newer versions.