The AC meant this to be sarcastic, but it's a lot more true than the AC realizes.
If I go to the Apple app store looking for, say, a text editor, I'll find 2-3 apps, each of which is sufficiently polished to serve my needs.
If I go to, say, freshmeat.net, I'll find 20-30 text editors. Ten will be half-completed abandonware, five will fail to install on my system until I also set up a dozen different (mostly unnecessary) library dependencies that the authors happened to have on their system, three will be components of giant software stacks (I'm looking at you, OOo), five have unintuitive user interfaces (emacs or vi, depending on your religious views), and five would satisfy my needs satisfactorily.
Is it worth paying an Apple tax to get a filtered list that, while it has less options, almost always serves my needs? My time is sufficiently valuable that I would rather pay that tax than get flooded with the open marketplace. And I am willing to sacrifice the one or two times Apple doesn't provide enough for the dozens or hundreds of times Apple does everything I need.
The single worst aspect of Google-as-documentation is how out-of-date most of Google's results are. This aspect will - permanently! - limit the ability of Google to provide effective Linux documentation.
Here's an example. My first attempt: google "install linux printer". Here are the results I get. Notice how HP provides good documentation by their 2nd link, but nothing else would actually solve my problem.
HP page talking about how HP supports writing code to make printing on Linux
RedHat page - dating from RedHat 8, that's ~2001 - that is too obsolete to be of any value.
A forum page where a newbie asks how to install a printer. One poster says look at the CUPs URL (gee, I hope the CUPs local webpage is 100% self-documenting!), another says use Samba. Both answers are fine for advanced users, but are far too sophisticated for beginner/intermediate.
A forum post describing exactly how to install an HP printer, using HP-specific packages.
Experts-Exchange, which won't even let you see what it says is the solution without paying.
Epson's instructions for installing a printer - using RedHat 9 as an example. Again, too obsolete.
A forum post that is unanswered. (Well, there's an illegible spam-looking answer, but that doesn't count).
A 2003 self-authored system manual. The screenshots look like Motif.
Linux foundation website listing available printer drivers. No instructions about how to actually, you know, INSTALL them.
In constrast, if I google "install printer windows", the first link is a Microsoft KB article, and the only useless link on the first page of results is a Windows 98 article. Yes, I admit I should probably google "install printer ubuntu" or "install printer redhat", but you see my point.
Depending on Google for documentation and documentation indexing is a great / cheap way to get the first 20% of the work done. Unfortunately, there's still 80% of the work left to be done. If you pay for an OS, a significant fraction of the cost is paying for somebody to write KB articles and such, paying for engineers to develop an easy-to-use (e.g. self-documenting) interface AND to keep that interface consistent over a period of years. Microsoft is tolerably good at doing those two; Apple is the best in the world. With Linux, open source contributors tend to not do that work - stable interfaces hinder freedom to innovate, you see. Individual distros do have staff to do it - but none of them have the resources (or revenues) of Microsoft or Apple, and all distros face a collection of Linux / open source components that change with breakneck speed.
Torvalds is absolutely correct, the whole issue is idiotic and isn't really an "exploit" because it doesn't result in ANY privilege escalation. (You must be root to run an exploit that gives you, um, root!) However, ego-starved security people get to jump up and down thumping their chests about how they h@x0r3d an extremely common Linux distribution and get their names splashed all over the press. Yeah, and instead of mmapping NULL, you can just 'insmod/my/evil.ko' and get the same effect. Sigh.
Those of us who know anything about security just ignore these "researchers". There are far more important bugs - even far more important security bugs - than a root-to-root non-issue. I'll happily patch my system with the next set of kernel updates, but I don't intend to grab it any sooner. It's more important to me that my system stay up and avoid regressions than fix a root-can-get-root non-exploit.
That article says AMD "Bulldozer" has 128-bit SSE5 extensions, which are really fancy ways of doing SIMD with multiple 64-bit, 32-bit, or 16-bit numbers and have nothing to do with 128-bit math or 128-bit addressing. Note that SSE's XMM0-7 registers are already 128-bit, so all this is nothing new (and I'm not really sure what AMD is so proud of, though Bulldozer does have some neat new features).
I'm a kernel guy, I work with a lot of kernel guys, and pretty much everybody I talk to just laughs at the idea of a 128-bit "architecture". Here's some back-of-the-envelope math: 2^64 addressable bytes / 4 GHz / 1024 cores = 6 months to even use that much memory. So unless you have a weird need to map the same memory thousands of times, a 64-bit architecture is going to last quite a while.
RHEL4 is 2.6.9, they are on RHEL4u8 (released earlier this year) and still has support through the end of this year. RHEL5 (2.6.18) has active development through 2011, and will be around until 2012 at least.
In all seriousness, if you aren't aware of these truly long-term support kernels, then you aren't dealing with enterprise class support/stability requirements. Linux itself prefers features over stabilization; a few distros do stabilize well (RHEL, SUSE, Ubuntu LTS) but they achieve this by spending over a year in beta at a fixed kernel version with some backports, which already puts their kernel a year behind when it goes out the door, and they keep the same (increasingly patched) kernel for 5 more years. Which, unsurprisingly, is a similar lifecycle to the BSDs.
This all isn't in keeping with their company line up to this point- and companies typically don't change this much this fast. Ever. I doubt that they're telling the truth here on this- as much because of what they've done in the past and how radically different it is from what that was.
Never forget that Microsoft does not act as a single, intelligent creature with one purpose. Microsoft is a large fiefdom. There is one king (Balmer) who doles out responsibility to a small army of dukes, earls, counts, and such (vice presidents), each of whom have their own agenda (amass the most resources, either by raising revenues or stealing from each other). Linux is a very annoying enemy to one of the dukes, and is a strategic ally of a count.
It is entirely possible for one part of Microsoft - probably the Windows Server marketing organization - to be spewing anti-GPL filth while at the same time another part of Microsoft - the hypervisor engineering team - is working very hard to interoperate with Linux because the lack of that integration is killing them in the marketplace against VMware. I would be more surprised if Microsoft didn't manage to act like a schizophrenic. Microsoft as a whole doesn't give a damn about Linux; it's one or two parts of the company that feel strongly one way or another.
This entire thing would be fine if it wasn't for Nintendo's rules about what can be used on their devices.
This entire thing would have been equally fine if it wasn't for ScummVM's rules about what platforms can be used to run their games.
I do think it's an absurd policy that Nintendo won't allow GPLed code on their console, probably a policy derived from lawyers concerned that if Nintendo allows GPLed code, they might end up being forced to open-source the whole console software stack.
I find it even more absurd that Slashdot screams bloody murder when a hardware vendor (Nintendo) disallows GPLed software, but bends over and asks for more when a software vendor (ScummVM) disallows non-GPLed hardware. ScummVM deliberately chose to exclude themselves from a significant fraction of the commercial market when they put a GPL license on the software. Which is their choice, I respect their reasons for making it, but they made a choice and now their end users (everyone who wants to buy these games) has to live with the consequences - that ScummVM-based games cannot legally run on the Wii.
There is no perfect software license. The GPL has tradeoffs. This is one of them.
My question is... what's to stop the small newspapers from firing the majority of their staff and operating like Internet newspapers with self-moderated volunteer staffs? All it'd take is to deploy Slashcode, buy-in from town administrators and business owners, and a critical mass of town residents to begin operating a near-free town news service.
Because you get what you pay for. Volunteer staffs invariably have their own agenda, and are less shy about pushing it. Just look around at Slashdot - a significant fraction of submissions are blatent slashvertizements, the editing and fact-checking rates somewhere between crap and non-existent, and a small but significant fraction of posts are trolls or don't-click-on-that-link griefers. Drudge is pushing a political agenda. Digg is looking for irrelevant-but-fun news to drive ad impressions. Wikipedia is increasingly full of entrenched administrators that are more interested in maintaining their control than in bringing in volunteers or editing out biases. Truth is, compared to internet newspapers, print newspapers have a sterling reputation for lack of bias and quality of reporting.
With a paid reporter staff and a paid editorial staff, a newspaper is paying for professionals who suppress their personal agendas (or, if you are FOX, push the company agenda) in exchange for money. So if you want a newspaper staffed by volunteer grandmas who believe news is about what Betty had for lunch yesterday (wikipedia: "In popular culture", all uses of the word "wood" in anime), a volunteer newspaper is fine, and not all that different from most of the blogosphere. If you want relevant news, you have to pay somebody.
Um... no. The exploit requires root mode to go and set MSR values to unexpected settings. VMMs do not expose these MSRs to the guest (or rather, they expose fake MSRs that do nothing, because a VM doesn't use cache-control MSRs). Writing to an MSR is a trapping operation, and the VMM will rightly discard these writes as nonsense.
Breaking out of a VM is like an alchemist transmuting lead to gold. It's a lot harder than it seems, and most of the claims to success are pretenders. I'm sure it will eventually be possible - but the researcher behind this paper is not clever enough to realize when she has failed. (VMware and KVM experts challenged her to write this "undetectable hypervisor" she keeps using as a payload for these "exploits"; she stated that such a thing was trivial academic exercise, yet the world's virtualization experts uniformly believe such a thing is all but impossible. Take anything Johanna Rutkowska says with a very large grain of salt.)
None of the courts (except the first) made any ruling whatsoever about whether Rambus' actions were illegal, despite most of the comments on this thread claiming the courts said that. And though I can't find the court opinions, I would be surprised if the Appellate Court challenged that at all. See, a case like this requires (A) proving that Rambus did a nasty thing, and (B) proving that the nasty thing is against the law. Part (A) belongs in the original court and is extremely hard to appeal; part (B) gets appealed everywhere. The Appellate Court found that the FTC didn't prove part (B), and the Supreme court agreed.
Believe it or not, the court system is pretty good at throwing out crappy lawsuits. The courts cannot just declare a company assholes, they can only rule upon the proof of assholeness brought before them. The FTC screwed up the case.
I think you misunderstand my position. If the Jury reasonably believes the evidence supports a guilty verdict, then I would have no case for the appeal. Only if I won, would I then proceed to file several civil lawsuits against the officers involved.
You seem to be under the assumption that you can sue yourself back to the position you were at before all this happens. Nope.
When you get yourself dragged into court on that speeding ticket, it's not Bob the Policeman against you, it's the City of Whatever - a sovereign government. You don't get to sue the individual - an individual acting with government authority is protected by that authority, you have to go sue the government.
The funny thing about suing the government is, you can only sue the government for reasons the government permits you to sue it. The government has made no law permitting you to sue for being wrongly accused. (The poor bastards in Guantanamo can and have sued the government for not obeying its own laws about habeus corpus, but were they charged with any crime at all, Guantanamo would be legal). The government doesn't have to apologize for charging an innocent man with a crime, the government doesn't have to admit it was wrong, and the government doesn't owe you a single cent for your time during that whole (hypothetical) trial you somehow managed to win.
If you feel that the government should owe you something if the government loses in court, please find a politician who feels that way and vote for him.
Popular wisdom has it that no product will have any support for any of these algorithms for years â" if ever. Of course, popular wisdom is ignoring all Open Source projects that support cryptography (including the Linux kernel) which could add support for any of these tomorrow. Does it really matter if the algorithm is found to be flawed later on, if most of these packages support algorithms known to be flawed today?
It matters a lot. Say OpenSSL added all of these algorithms tomorrow. Some idiot developer (hint: go read DailyWTF) will build on top of it. OpenSSL now has to maintain backwards compatibility - so they can never take out the algorithm. A month from now, the algorithm gets broken completely. But because OpenSSL shipped with it, they can never take it back out.
The "popular wisdom" standard for proliferating a new algorithm is not how shiny it looks at first glance. Popular wisdom waits months or years until algorithms seem good enough. MD5 (or even MD4), SHA1 - all are good enough for some purposes (generally, when attacker does not control input). And if the attacker does control the input, the only sure solution is to send the whole thing - anyone believing otherwise needs to review the meaning of the word "hash". A secure hash is merely an irreversible hash with a very low risk of collision.
Even this article is mostly "security theater". There are very, very few uses of secure hashes where SHA1 (or even MD5, for that matter) is not good enough.
VMware however does not intercept all cpuids. It can't because binary translation only applies to priviledged code (the kernel). VMware doesn't translate user programs and therefore cannot intercept all cpuids. This leads to the inconsistencies in applications you describe. Both Intel and AMD introduced a capability to mask some of the cpuid values to support VMware's enhanced migration but this is a far cry from completely spoofing cpuid's like kvm does.
And here I thought VMware employees were experts on how VMware software works!
You've actually run afoul of an extremely common misconception. VMware has been using VT (the same thing KVM uses) since 2005; the VMware hypervisors can run in either a binary translation mode, a VT/SVM mode, or a paravirtualized mode for Linux kernels 2.6.23 and above (or Ubuntu, who accepted the patches earlier), and do in fact switch modes depending on which guest OS, vMotion options, and other settings are configured. Configuring for a baseline CPUID value is ultimately an engineering choice: BT can only run with a passed-through CPUID, whereas VT/SVM can run either passed-through or emulated. Since the trapping overheads of most pre-EPT/NPT VT/SVM implentations are higher than the binary translation overheads, it's more efficient to run in BT mode (but VT mode is still very much supported). Thus, VMware defaults to not spoofing CPUID for a small performance win. For KVM, VT is the only option and adding the additional CPUID is a much lower marginal cost, so it makes engineering sense to always spoof. And both VMware and KVM folks are looking forward to the EPT/NPT future where VT overheads finally become lower than binary translation overheads.
Why isn't the same true for cross vendor CPU migration? I can see some obvious issues around sysenter in compatibility mode, some of the bit set instructions and FPU approximation series but none of those seem insurmountable technical challenges.
It's not insurmountable. See this VMware customer, who tweaked the vmotion compatibility settings enough to get Intel/AMD VMotions working two months ago. There's a world of difference between somebody doing this for fun / in RedHat's research lab and somebody calling this stable enough to use for production servers, however. Does VMware support it in that the software can be made to do it? Yes. Does VMware support it in that tech support will answer the phone if you break something trying this? No.
The new Intel/AMD CPU features that allow masking of CPUID bits while running virtualized also make processors recent enough that most of the interesting features are present - MMX, SSE up to ~3. The "common subset" ends up looking like an early Core2 or a Barcelona (minus the VT/SVM feature bits, of course) - Intel and AMD run about a generation behind on adding each other's instructions. Run on anything older than the latest processors, and you have to trap-and-emulate every CPUID instruction. Enough code still uses CPUID as a serializing instruction that this has noticeable overhead.
So there are two strategies. Pass directly through the CPUID bits (and on the newest processors, apply a mask), or remember a baseline value, trap-and-emulate every CPUID and always return that value. Sounds like KVM has picked the latter approach for a default; VMware's default is to expose the actual processor features and accept a mask as an optional override, which skews towards exposing more features at the expense of some compatibility. Equally valid choices, IMHO.
The Worst Case Scenario when not doing a trap-and-emulate of every CPUID is an app that does CPUID, reads the vendor string, then decides based on the vendor string which other CPUID leafs to read. (Like the 0x80000000 leafs, which are vendor-specific and would come back as gibberish if you get the processor wrong). If the app migrates during the dozen or so instructions between the first CPUID and the following ones, instant corruption. Good enough for a pretty demo, destined to make a guest kernel die a few times a year if actually used in production. And I'm 95% sure this is what the OP demo is doing - living dangerously by hoping mismatched CPUID results never get noticed.
I agree with Anthony Liguori here - on a production machine, an Intel/AMD migration is way too much of a stupid risk. All you have to do is reboot the VM, it's much safer.
(As a side note to everyone reading, the reason Linux timekeeping is such a problem is that TSC issue. Intel long ago stated TSC was NOT supposed to be used as a timesource. Linux kernel folks ignored the warning, made non-virtualizable assumptions, and today are in a world of hurt for timekeeping in a VM. And only now, many years later, are patching the kernel to detect hypervisors to work around the problem.)
In complete seriousness, this was my first Linux experience. I got everything installed, read about this thing called safelib which was supposed to replace libc with safer wrappers, and tried to set it up. "su; rm/lib/libc.so.5; cp/tmp/path/libsafe.so/lib/libc.so.5". Rebooting clearly didn't fix it either:-)
It's good enough for an apples-to-apples comparison - GP suggested comparing an in-VM setup w/o encryption versus an in-VM setup w/ encryption. I/O costs are higher, but the cost is in latency, not bandwidth; a large-data research number-cruncher depends more on bandwidth.
Not everybody has the budget or time to put together two identical systems for comparisons like this.
Sure, Android is more developer-friendly than the iPhone. Has Apple ever pretended otherwise?
Apple goes for something entirely different - being customer-friendly. Apple demands high-quality apps, and rejects substandard ones. Apple requires well-engineered user interfaces. Apple restricts the number of functionally equivalent apps and ways of doing something, to follow the well-known interface guideline of not overwhelming a user with choice.
I can already see how Google's Android is going to end up. Want a sneak peek? Go look at SourceForge today. Maybe 10% of the projects are extremely useful high-quality projects supported by a vibrant community. 90% of the projects are abandoned crap - but they're developer-friendly! You can get the source and fix it!
Being developer-friendly helps by making it easier to create software. That's a double-edged sword, however, because as much as developer-friendliness makes it easier to create good software, it also makes it two or three times easier to create crap software. Witness the plethora of Google apps that have never left beta, witness the gross proliferation of spyware and script-kiddie viruses, witness the rampant proliferation of me-too Linux distributions used by two people and their dog.
The Cathedral and the Bazaar. This is very simple - when I want something fun to play with, when I want to indulge my hobbyist sweet-tooth, I go to the Bazaar. When there's something I need to depend on and I don't have the time to tweak it myself, I go to the Cathedral. Now, in all seriousness, do you see a cell phone more as a fun toy or a necessary, must-work piece of your life? I imagine a lot of Slashdot readers want the cell phone to be a toy, but I also imagine most people in this world would prefer something to Always Just Work, even if it's less fun. It's the difference between driving a fun but high-maintenance sports car on the weekends and driving a reliable commuter car to work every day; everybody wants a sports car, but most people pick the commuter car.
Which means I don't buy the hype around Android. It's a fantastically wonderful toy, but Google's track record is that they do not have the discipline to enforce usability at the expense of their fun toys. And, to my great sorrow, that is Google's great weakness.
6 months ago we evaluated both vmware (which we had been using in dev and test for years) and the Citrix Xen product and decided to go for Xen for our production systems based upon performance we saw (yes yes YMMV) cost, and the open nature of the API. The problem was finding a strong partner/integrator to help us swing our server estate from physical to virtual in the time allotted.
Then you missed the GP's point. If XenSource (Citrix XenSource : VMware VI as Xen : ESX) satisfies your needs, then you aren't doing anything for which you need a datacenter OS. (And if you evaluated anything more expensive than the cheapest VMware offering, you botched your product search too.)
For server consolidation and bare-bones start/stop management, there is not much difference between VMware, Xen, and Hyper-V. They all have roughly the same performance; ESX degrades least when overloaded and there's a small premium for an ESX cluster because of it. Go to the next tier where you need automated load-balancing, automated availability solutions, and automated backup, and VMware is the only game in town. (Short of IBM mainframes.)
Server consolidation != datacenter OS, despite the "me too!" claims of MSFT and Citrix. MSFT's roadmap puts them in the same ballpark in 2-3 years, Citrix 3 years back on the VMware roadmap, and VMware is there right now.
So... disclaimer. I'm a VMware employee, so I do know all about both these benchmarks (even if I had nothing to do with them). Agree the first VMware benchmark was quite skewed, looking at Xen instead of XenSource. The XenSource benchmark showed up, it showed Xen ahead in system-call microbenchmarks (hardware virtualization does well there, but lots of system calls with no I/O isn't representative of the real world) and more or less even on everything else. VMware approved XenSource's whitepaper for publication about two weeks later (which, BTW, is no longer on Citrix's website and not visible on Google). The comparison was not apples-to-apples - XenSource switched from Xen 3.0 to Xen 3.2 in the comparison, and didn't make any software-virtualization/hardware-virtualization tweaks. In other words, XenSource's benchmark was just as skewed as VMware's. And everybody who knows anything about benchmarking knows it.
The summary of that whole mess: XenSource / Simon Crosby got more PR mileage out of making a big deal of EULA restrictions than from any actual performance comparison. They never cared about a performance comparison - it was all a PR stunt to get a great big/REDACTED/ document posted to news sites / blogs.
VMware does not forbid negative benchmarks; they do forbid stupid benchmarks. Usually, some amateur runs Passmark 2D, which is a system-call microbenchmark that doesn't even keep time correctly in a virtual machine. Every single person complaining about that EULA has never bothered submitting results - almost all submissions get approved.
In the last century, this conversation would be about craftsmen and assembly workers. The first worked on project to make something special - say a chair - the second makes parts that are assembled. The first each as a work of art, there can be little differences based on the wood. The second maked mass produced item all identical but weaker since the quaility of wood is not what the care about.
And go and try to argue about the programming is like the second. It is not. Once the original is created exact copies are made with no "effort" execpt placement on a disk in a box.
Keep following this line of reasoning... Slashdot as a whole won't like where it ends up.
The first instance of software is done by a for-profit company - they are usually the ones willing to take a risk for a financial reward, they go through the marketing and sales to create a market for that software, pay developers and QA to put together a good project. The second instance of software is the open-source clone. Open source sees a nice project, decides they can do it cheaper (free is cheaper!), makes a low quality knock-off and starts pushing it as equivalent (OpenOffice, anyone?). I know I'm not being fair - some open-source has surpassed the original in quality - but the generalization is true of much open-source software.
Now, before the open-source zealots show up pointing to the high-code-quality, easily-fixed code that makes up open source software, let me point out that software QUALITY is a much more holistic measure. It includes market research to figure out WHAT THE USERS WANT, instead of a horde of developers each doing what they feel like. Quality software has a large QA organization to verify that code works as designed, instead of pushing out releases and using end-users as first-round QA. (Hint: "it's fixed in source, you should update" indicates the end-user is first-round QA). Quality means keeping software stability so that long-term planning can depend upon the attributes of software (e.g. I can depend on an app working on Win32 5 years from now; anyone want to bet on whether GTK libraries will still be compatible?) and carefully designing extensible interfaces instead of glorifying idealized designs and rewrites. Open-source projects tend to have good code - and lousy customer interaction, lousy roadmaps and compatibility stories, and lousy QAing. Some open-source projects have very high quality (Linux, Apache, and others come to mind), and some outsourcing companies do great work, but the majority in both tends toward lower-quality knock-offs.
Open-source is the cheap labor of the programming world, for better or worse. The good places to be are either a for-profit company that is willing to spend market rates to get good labor, or open-source where the probable lack of quality is known but the costs are low (e.g. quality's costs are provided by distros). Being in the middle is simply the worst of both worlds.
To each and every person whining on this thread about how copy protection violates the spirit of Open Source - yeah, it does. And if you don't like it, don't touch the game. Don't buy it - and don't download it either. This noise about how you have some sort of entitlement to steal/pirate/"illegally download"/crack/
"screw-the-man!"/whatever a game simply because you have a political disagreement about copy protection is pathetic.
The difference between Richard Stallman / the FSF and half the posters on this article is that RMS avoids software he disagrees with entirely and ACTIVELY contributes to software he morally supports. In other words, he has principles, votes with his actions, and his patronage of free software DIRECTLY contributes to more and better free software. Whereas the "gimme my Linux games NOW and FREE and screw copy protection!" crowd is in it for a shiny new game, but by NOT paying for (or otherwise patronizing - e.g. with word-of-mouth advertising, filing good bug reports) Linux games they are killing the future of Linux gaming for a quick fix now. This isn't the behavior of rational individuals - this is the behavioral profile of drug addicts.
With apologies to all the honest Linux gamers out there. It's a shame the rotten apples are so enthusiastic about spoiling it for the rest of us.
Roberts' opinion scares me more.
The public will "lose a bit more control over the conduct of this nation's foreign policy to unelected, politically unaccountable judges," [Roberts] added. The Chief Justice of the Supreme Court on record stating he thinks judges are unaccountable and should not be trusted to apply judicial oversight to political decisions? Bollocks. The SCOTUS is the highest court, it has oversight over EVERYTHING not explicitly denied by the Constitution. (And judges are held accountable by impeachment proceedings - if G. W. Bush thinks the justices are wrong, he should introduce articles of impeachment. And watch them get laughed out of Congress). The courts are guardians of the Constitution, not guardians of democracy.
Linux STILL doesn't have DTrace, they use kprobes(?) instead because somebody claimed it was almost as good (DTrace users know the Linux equivalent is woefully inadequate and needs several years to even reach feature parity). Not-Invented-Here syndrome.
Look at kgdb, which Linus finally merged parts of after many years. Linux feels developers shouldn't be using debugging tools on the kernel. Any bets on whether he would merge DTrace at all?
Even if Linux had DTrace, this fix would be applied in source - which might be good enough for the few thousand people who always run the bleeding edge kernel, but has to trickle through a kernel release cycle (~3 months) or even wait for a distro upgrade cycle to pick up a newer kernel (~6 months for Ubuntu / Fedora, ~2 years for RHEL, maybe 4 years for Debian-stable?). No shortcuts, this isn't a backportable security fix.
For an average Ubuntu user (just picking a popular Linux distro here, no flamewars) and an average Mac OS X user, the 10.5.3 update came out a LOT sooner than the next Ubuntu 8.10 update. Sure the five people who actually care about this have the option of recompiling on Linux, but for everyone else, the closed-source product cycles are moving a lot faster. There's a world of difference between fixing in source and fixing on my local machine, a world open-source zealots conveniently omit when mouthing off about how fast open source can fix things. (Hint: I'll bet Apple fixed DTrace in source in a week also.)
Linux is quite good about cycling security fixes through very fast. Anything else - new features or non-security/stability fixes - tends to take many months or even years to percolate to the world at large. Which puts Linux-based OSes (e.g. distros) squarely between Apple (updates every few months) and Microsoft (SPx every few years) for slow product cycles. Note that this isn't the fault of Linux kernel people - it's the whole distro model, which should be a sign that an OS - even an open source OS - is a complicated beast that necessarily has long release cycles.
From TFA:
I can't figure out what any of those companies do Anyone doubt this? Let's take a tour through a few products that "make you more secure":
Antivirus: works by scanning files being written to/from disk, and by scanning I mean "run ~1 million instructions in an emulator then see if it matches a virus pattern". Requires weekly updates to latest definitions. One of the most successful "security" products
Static code analysis tools (e.g. Coverity). They take your source code, run a heavy-duty static analysis program on it, and point out memory leaks / double frees, uninitialized variables, and other flaws. My educated guess is that 1/3 of viruses involve such a problem. Useful, but to a manager, you can find a different 1/3 of flaws with a manual code audit that costs about as much.
Windows Vista (yeah, ha ha). Includes improved account control and privilage separation! Except that most users get so sick of the Allow box that is required for so many things on Windows that Vista has NOT fundamentally increased security.
Network intrusion detection appliance - you plug this into your network, and it does something when it detects a malicious access pattern - I dunno, maybe it bakes cookies? But detecting malicious access patterns makes you more secure!!!
The security product that takes off will be one that says "with product X, you will never experience security problem Y". Unfortunately, the security products out there are crap (product X decreases chances of problem Y from 1% to 0.01%) and security folks are the most paranoid about providing any guarantees. (Use the word "impossible" at a security conference and watch what the blogosphere does to you. I dare you.)
In other words: most security products provide a small marginal gain, while their vendors tout them as essential, must-have products.
The single most telling "security" trait I have seen is from the security group at my employer. They send out a feature proposal, and then flame anyone who disagrees with by saying "if you don't agree to this, we'll probably get hacked next year and it will be your fault for being against the security of our products!". Never mind the technical flaws (ASLR doesn't work when you map 1GB of contiguous memory in a 32-bit process) or performance implications. Security "sells" based on fear, and the security industry sales arm has yet to realize they have cried WOLF too many times for purchasers to take them seriously anymore.
Slashdot Mirror
If I go to the Apple app store looking for, say, a text editor, I'll find 2-3 apps, each of which is sufficiently polished to serve my needs.
If I go to, say, freshmeat.net, I'll find 20-30 text editors. Ten will be half-completed abandonware, five will fail to install on my system until I also set up a dozen different (mostly unnecessary) library dependencies that the authors happened to have on their system, three will be components of giant software stacks (I'm looking at you, OOo), five have unintuitive user interfaces (emacs or vi, depending on your religious views), and five would satisfy my needs satisfactorily.
Is it worth paying an Apple tax to get a filtered list that, while it has less options, almost always serves my needs? My time is sufficiently valuable that I would rather pay that tax than get flooded with the open marketplace. And I am willing to sacrifice the one or two times Apple doesn't provide enough for the dozens or hundreds of times Apple does everything I need.
The single worst aspect of Google-as-documentation is how out-of-date most of Google's results are. This aspect will - permanently! - limit the ability of Google to provide effective Linux documentation.
Here's an example. My first attempt: google "install linux printer". Here are the results I get. Notice how HP provides good documentation by their 2nd link, but nothing else would actually solve my problem.
In constrast, if I google "install printer windows", the first link is a Microsoft KB article, and the only useless link on the first page of results is a Windows 98 article. Yes, I admit I should probably google "install printer ubuntu" or "install printer redhat", but you see my point.
Depending on Google for documentation and documentation indexing is a great / cheap way to get the first 20% of the work done. Unfortunately, there's still 80% of the work left to be done. If you pay for an OS, a significant fraction of the cost is paying for somebody to write KB articles and such, paying for engineers to develop an easy-to-use (e.g. self-documenting) interface AND to keep that interface consistent over a period of years. Microsoft is tolerably good at doing those two; Apple is the best in the world. With Linux, open source contributors tend to not do that work - stable interfaces hinder freedom to innovate, you see. Individual distros do have staff to do it - but none of them have the resources (or revenues) of Microsoft or Apple, and all distros face a collection of Linux / open source components that change with breakneck speed.
Torvalds is absolutely correct, the whole issue is idiotic and isn't really an "exploit" because it doesn't result in ANY privilege escalation. (You must be root to run an exploit that gives you, um, root!) However, ego-starved security people get to jump up and down thumping their chests about how they h@x0r3d an extremely common Linux distribution and get their names splashed all over the press. Yeah, and instead of mmapping NULL, you can just 'insmod /my/evil.ko' and get the same effect. Sigh.
Those of us who know anything about security just ignore these "researchers". There are far more important bugs - even far more important security bugs - than a root-to-root non-issue. I'll happily patch my system with the next set of kernel updates, but I don't intend to grab it any sooner. It's more important to me that my system stay up and avoid regressions than fix a root-can-get-root non-exploit.
I'm a kernel guy, I work with a lot of kernel guys, and pretty much everybody I talk to just laughs at the idea of a 128-bit "architecture". Here's some back-of-the-envelope math: 2^64 addressable bytes / 4 GHz / 1024 cores = 6 months to even use that much memory. So unless you have a weird need to map the same memory thousands of times, a 64-bit architecture is going to last quite a while.
RHEL4 is 2.6.9, they are on RHEL4u8 (released earlier this year) and still has support through the end of this year. RHEL5 (2.6.18) has active development through 2011, and will be around until 2012 at least.
In all seriousness, if you aren't aware of these truly long-term support kernels, then you aren't dealing with enterprise class support/stability requirements. Linux itself prefers features over stabilization; a few distros do stabilize well (RHEL, SUSE, Ubuntu LTS) but they achieve this by spending over a year in beta at a fixed kernel version with some backports, which already puts their kernel a year behind when it goes out the door, and they keep the same (increasingly patched) kernel for 5 more years. Which, unsurprisingly, is a similar lifecycle to the BSDs.
This all isn't in keeping with their company line up to this point- and companies typically don't change this much this fast. Ever. I doubt that they're telling the truth here on this- as much because of what they've done in the past and how radically different it is from what that was.
Never forget that Microsoft does not act as a single, intelligent creature with one purpose. Microsoft is a large fiefdom. There is one king (Balmer) who doles out responsibility to a small army of dukes, earls, counts, and such (vice presidents), each of whom have their own agenda (amass the most resources, either by raising revenues or stealing from each other). Linux is a very annoying enemy to one of the dukes, and is a strategic ally of a count.
It is entirely possible for one part of Microsoft - probably the Windows Server marketing organization - to be spewing anti-GPL filth while at the same time another part of Microsoft - the hypervisor engineering team - is working very hard to interoperate with Linux because the lack of that integration is killing them in the marketplace against VMware. I would be more surprised if Microsoft didn't manage to act like a schizophrenic. Microsoft as a whole doesn't give a damn about Linux; it's one or two parts of the company that feel strongly one way or another.
This entire thing would be fine if it wasn't for Nintendo's rules about what can be used on their devices.
This entire thing would have been equally fine if it wasn't for ScummVM's rules about what platforms can be used to run their games.
I do think it's an absurd policy that Nintendo won't allow GPLed code on their console, probably a policy derived from lawyers concerned that if Nintendo allows GPLed code, they might end up being forced to open-source the whole console software stack.
I find it even more absurd that Slashdot screams bloody murder when a hardware vendor (Nintendo) disallows GPLed software, but bends over and asks for more when a software vendor (ScummVM) disallows non-GPLed hardware. ScummVM deliberately chose to exclude themselves from a significant fraction of the commercial market when they put a GPL license on the software. Which is their choice, I respect their reasons for making it, but they made a choice and now their end users (everyone who wants to buy these games) has to live with the consequences - that ScummVM-based games cannot legally run on the Wii.
There is no perfect software license. The GPL has tradeoffs. This is one of them.
My question is... what's to stop the small newspapers from firing the majority of their staff and operating like Internet newspapers with self-moderated volunteer staffs? All it'd take is to deploy Slashcode, buy-in from town administrators and business owners, and a critical mass of town residents to begin operating a near-free town news service.
Because you get what you pay for. Volunteer staffs invariably have their own agenda, and are less shy about pushing it. Just look around at Slashdot - a significant fraction of submissions are blatent slashvertizements, the editing and fact-checking rates somewhere between crap and non-existent, and a small but significant fraction of posts are trolls or don't-click-on-that-link griefers. Drudge is pushing a political agenda. Digg is looking for irrelevant-but-fun news to drive ad impressions. Wikipedia is increasingly full of entrenched administrators that are more interested in maintaining their control than in bringing in volunteers or editing out biases. Truth is, compared to internet newspapers, print newspapers have a sterling reputation for lack of bias and quality of reporting.
With a paid reporter staff and a paid editorial staff, a newspaper is paying for professionals who suppress their personal agendas (or, if you are FOX, push the company agenda) in exchange for money. So if you want a newspaper staffed by volunteer grandmas who believe news is about what Betty had for lunch yesterday (wikipedia: "In popular culture", all uses of the word "wood" in anime), a volunteer newspaper is fine, and not all that different from most of the blogosphere. If you want relevant news, you have to pay somebody.
Breaking out of a VM is like an alchemist transmuting lead to gold. It's a lot harder than it seems, and most of the claims to success are pretenders. I'm sure it will eventually be possible - but the researcher behind this paper is not clever enough to realize when she has failed. (VMware and KVM experts challenged her to write this "undetectable hypervisor" she keeps using as a payload for these "exploits"; she stated that such a thing was trivial academic exercise, yet the world's virtualization experts uniformly believe such a thing is all but impossible. Take anything Johanna Rutkowska says with a very large grain of salt.)
Believe it or not, the court system is pretty good at throwing out crappy lawsuits. The courts cannot just declare a company assholes, they can only rule upon the proof of assholeness brought before them. The FTC screwed up the case.
I think you misunderstand my position. If the Jury reasonably believes the evidence supports a guilty verdict, then I would have no case for the appeal. Only if I won, would I then proceed to file several civil lawsuits against the officers involved.
You seem to be under the assumption that you can sue yourself back to the position you were at before all this happens. Nope.
When you get yourself dragged into court on that speeding ticket, it's not Bob the Policeman against you, it's the City of Whatever - a sovereign government. You don't get to sue the individual - an individual acting with government authority is protected by that authority, you have to go sue the government.
The funny thing about suing the government is, you can only sue the government for reasons the government permits you to sue it. The government has made no law permitting you to sue for being wrongly accused. (The poor bastards in Guantanamo can and have sued the government for not obeying its own laws about habeus corpus, but were they charged with any crime at all, Guantanamo would be legal). The government doesn't have to apologize for charging an innocent man with a crime, the government doesn't have to admit it was wrong, and the government doesn't owe you a single cent for your time during that whole (hypothetical) trial you somehow managed to win.
If you feel that the government should owe you something if the government loses in court, please find a politician who feels that way and vote for him.
Popular wisdom has it that no product will have any support for any of these algorithms for years â" if ever. Of course, popular wisdom is ignoring all Open Source projects that support cryptography (including the Linux kernel) which could add support for any of these tomorrow. Does it really matter if the algorithm is found to be flawed later on, if most of these packages support algorithms known to be flawed today?
It matters a lot. Say OpenSSL added all of these algorithms tomorrow. Some idiot developer (hint: go read DailyWTF) will build on top of it. OpenSSL now has to maintain backwards compatibility - so they can never take out the algorithm. A month from now, the algorithm gets broken completely. But because OpenSSL shipped with it, they can never take it back out.
The "popular wisdom" standard for proliferating a new algorithm is not how shiny it looks at first glance. Popular wisdom waits months or years until algorithms seem good enough. MD5 (or even MD4), SHA1 - all are good enough for some purposes (generally, when attacker does not control input). And if the attacker does control the input, the only sure solution is to send the whole thing - anyone believing otherwise needs to review the meaning of the word "hash". A secure hash is merely an irreversible hash with a very low risk of collision.
Even this article is mostly "security theater". There are very, very few uses of secure hashes where SHA1 (or even MD5, for that matter) is not good enough.
VMware however does not intercept all cpuids. It can't because binary translation only applies to priviledged code (the kernel). VMware doesn't translate user programs and therefore cannot intercept all cpuids. This leads to the inconsistencies in applications you describe. Both Intel and AMD introduced a capability to mask some of the cpuid values to support VMware's enhanced migration but this is a far cry from completely spoofing cpuid's like kvm does.
And here I thought VMware employees were experts on how VMware software works!
You've actually run afoul of an extremely common misconception. VMware has been using VT (the same thing KVM uses) since 2005; the VMware hypervisors can run in either a binary translation mode, a VT/SVM mode, or a paravirtualized mode for Linux kernels 2.6.23 and above (or Ubuntu, who accepted the patches earlier), and do in fact switch modes depending on which guest OS, vMotion options, and other settings are configured. Configuring for a baseline CPUID value is ultimately an engineering choice: BT can only run with a passed-through CPUID, whereas VT/SVM can run either passed-through or emulated. Since the trapping overheads of most pre-EPT/NPT VT/SVM implentations are higher than the binary translation overheads, it's more efficient to run in BT mode (but VT mode is still very much supported). Thus, VMware defaults to not spoofing CPUID for a small performance win. For KVM, VT is the only option and adding the additional CPUID is a much lower marginal cost, so it makes engineering sense to always spoof. And both VMware and KVM folks are looking forward to the EPT/NPT future where VT overheads finally become lower than binary translation overheads.
Why isn't the same true for cross vendor CPU migration? I can see some obvious issues around sysenter in compatibility mode, some of the bit set instructions and FPU approximation series but none of those seem insurmountable technical challenges.
It's not insurmountable. See this VMware customer, who tweaked the vmotion compatibility settings enough to get Intel/AMD VMotions working two months ago. There's a world of difference between somebody doing this for fun / in RedHat's research lab and somebody calling this stable enough to use for production servers, however. Does VMware support it in that the software can be made to do it? Yes. Does VMware support it in that tech support will answer the phone if you break something trying this? No.
The new Intel/AMD CPU features that allow masking of CPUID bits while running virtualized also make processors recent enough that most of the interesting features are present - MMX, SSE up to ~3. The "common subset" ends up looking like an early Core2 or a Barcelona (minus the VT/SVM feature bits, of course) - Intel and AMD run about a generation behind on adding each other's instructions. Run on anything older than the latest processors, and you have to trap-and-emulate every CPUID instruction. Enough code still uses CPUID as a serializing instruction that this has noticeable overhead.
So there are two strategies. Pass directly through the CPUID bits (and on the newest processors, apply a mask), or remember a baseline value, trap-and-emulate every CPUID and always return that value. Sounds like KVM has picked the latter approach for a default; VMware's default is to expose the actual processor features and accept a mask as an optional override, which skews towards exposing more features at the expense of some compatibility. Equally valid choices, IMHO.
The Worst Case Scenario when not doing a trap-and-emulate of every CPUID is an app that does CPUID, reads the vendor string, then decides based on the vendor string which other CPUID leafs to read. (Like the 0x80000000 leafs, which are vendor-specific and would come back as gibberish if you get the processor wrong). If the app migrates during the dozen or so instructions between the first CPUID and the following ones, instant corruption. Good enough for a pretty demo, destined to make a guest kernel die a few times a year if actually used in production. And I'm 95% sure this is what the OP demo is doing - living dangerously by hoping mismatched CPUID results never get noticed.
I agree with Anthony Liguori here - on a production machine, an Intel/AMD migration is way too much of a stupid risk. All you have to do is reboot the VM, it's much safer.
(As a side note to everyone reading, the reason Linux timekeeping is such a problem is that TSC issue. Intel long ago stated TSC was NOT supposed to be used as a timesource. Linux kernel folks ignored the warning, made non-virtualizable assumptions, and today are in a world of hurt for timekeeping in a VM. And only now, many years later, are patching the kernel to detect hypervisors to work around the problem.)
In complete seriousness, this was my first Linux experience. I got everything installed, read about this thing called safelib which was supposed to replace libc with safer wrappers, and tried to set it up. "su; rm /lib/libc.so.5; cp /tmp/path/libsafe.so /lib/libc.so.5". Rebooting clearly didn't fix it either :-)
Not everybody has the budget or time to put together two identical systems for comparisons like this.
Sure, Android is more developer-friendly than the iPhone. Has Apple ever pretended otherwise?
Apple goes for something entirely different - being customer-friendly. Apple demands high-quality apps, and rejects substandard ones. Apple requires well-engineered user interfaces. Apple restricts the number of functionally equivalent apps and ways of doing something, to follow the well-known interface guideline of not overwhelming a user with choice.
I can already see how Google's Android is going to end up. Want a sneak peek? Go look at SourceForge today. Maybe 10% of the projects are extremely useful high-quality projects supported by a vibrant community. 90% of the projects are abandoned crap - but they're developer-friendly! You can get the source and fix it!
Being developer-friendly helps by making it easier to create software. That's a double-edged sword, however, because as much as developer-friendliness makes it easier to create good software, it also makes it two or three times easier to create crap software. Witness the plethora of Google apps that have never left beta, witness the gross proliferation of spyware and script-kiddie viruses, witness the rampant proliferation of me-too Linux distributions used by two people and their dog.
The Cathedral and the Bazaar. This is very simple - when I want something fun to play with, when I want to indulge my hobbyist sweet-tooth, I go to the Bazaar. When there's something I need to depend on and I don't have the time to tweak it myself, I go to the Cathedral. Now, in all seriousness, do you see a cell phone more as a fun toy or a necessary, must-work piece of your life? I imagine a lot of Slashdot readers want the cell phone to be a toy, but I also imagine most people in this world would prefer something to Always Just Work, even if it's less fun. It's the difference between driving a fun but high-maintenance sports car on the weekends and driving a reliable commuter car to work every day; everybody wants a sports car, but most people pick the commuter car.
Which means I don't buy the hype around Android. It's a fantastically wonderful toy, but Google's track record is that they do not have the discipline to enforce usability at the expense of their fun toys. And, to my great sorrow, that is Google's great weakness.
6 months ago we evaluated both vmware (which we had been using in dev and test for years) and the Citrix Xen product and decided to go for Xen for our production systems based upon performance we saw (yes yes YMMV) cost, and the open nature of the API. The problem was finding a strong partner/integrator to help us swing our server estate from physical to virtual in the time allotted.
Then you missed the GP's point. If XenSource (Citrix XenSource : VMware VI as Xen : ESX) satisfies your needs, then you aren't doing anything for which you need a datacenter OS. (And if you evaluated anything more expensive than the cheapest VMware offering, you botched your product search too.)
For server consolidation and bare-bones start/stop management, there is not much difference between VMware, Xen, and Hyper-V. They all have roughly the same performance; ESX degrades least when overloaded and there's a small premium for an ESX cluster because of it. Go to the next tier where you need automated load-balancing, automated availability solutions, and automated backup, and VMware is the only game in town. (Short of IBM mainframes.)
Server consolidation != datacenter OS, despite the "me too!" claims of MSFT and Citrix. MSFT's roadmap puts them in the same ballpark in 2-3 years, Citrix 3 years back on the VMware roadmap, and VMware is there right now.
Preaching to the choir :-). Not every American loves the antics of our President, not every employee loves the antics of their corporate overlords.
So... disclaimer. I'm a VMware employee, so I do know all about both these benchmarks (even if I had nothing to do with them). Agree the first VMware benchmark was quite skewed, looking at Xen instead of XenSource. The XenSource benchmark showed up, it showed Xen ahead in system-call microbenchmarks (hardware virtualization does well there, but lots of system calls with no I/O isn't representative of the real world) and more or less even on everything else. VMware approved XenSource's whitepaper for publication about two weeks later (which, BTW, is no longer on Citrix's website and not visible on Google). The comparison was not apples-to-apples - XenSource switched from Xen 3.0 to Xen 3.2 in the comparison, and didn't make any software-virtualization/hardware-virtualization tweaks. In other words, XenSource's benchmark was just as skewed as VMware's. And everybody who knows anything about benchmarking knows it.
The summary of that whole mess: XenSource / Simon Crosby got more PR mileage out of making a big deal of EULA restrictions than from any actual performance comparison. They never cared about a performance comparison - it was all a PR stunt to get a great big /REDACTED/ document posted to news sites / blogs.
VMware does not forbid negative benchmarks; they do forbid stupid benchmarks. Usually, some amateur runs Passmark 2D, which is a system-call microbenchmark that doesn't even keep time correctly in a virtual machine. Every single person complaining about that EULA has never bothered submitting results - almost all submissions get approved.
In the last century, this conversation would be about craftsmen and assembly workers. The first worked on project to make something special - say a chair - the second makes parts that are assembled. The first each as a work of art, there can be little differences based on the wood. The second maked mass produced item all identical but weaker since the quaility of wood is not what the care about.
And go and try to argue about the programming is like the second. It is not. Once the original is created exact copies are made with no "effort" execpt placement on a disk in a box.
Keep following this line of reasoning ... Slashdot as a whole won't like where it ends up.
The first instance of software is done by a for-profit company - they are usually the ones willing to take a risk for a financial reward, they go through the marketing and sales to create a market for that software, pay developers and QA to put together a good project. The second instance of software is the open-source clone. Open source sees a nice project, decides they can do it cheaper (free is cheaper!), makes a low quality knock-off and starts pushing it as equivalent (OpenOffice, anyone?). I know I'm not being fair - some open-source has surpassed the original in quality - but the generalization is true of much open-source software.
Now, before the open-source zealots show up pointing to the high-code-quality, easily-fixed code that makes up open source software, let me point out that software QUALITY is a much more holistic measure. It includes market research to figure out WHAT THE USERS WANT, instead of a horde of developers each doing what they feel like. Quality software has a large QA organization to verify that code works as designed, instead of pushing out releases and using end-users as first-round QA. (Hint: "it's fixed in source, you should update" indicates the end-user is first-round QA). Quality means keeping software stability so that long-term planning can depend upon the attributes of software (e.g. I can depend on an app working on Win32 5 years from now; anyone want to bet on whether GTK libraries will still be compatible?) and carefully designing extensible interfaces instead of glorifying idealized designs and rewrites. Open-source projects tend to have good code - and lousy customer interaction, lousy roadmaps and compatibility stories, and lousy QAing. Some open-source projects have very high quality (Linux, Apache, and others come to mind), and some outsourcing companies do great work, but the majority in both tends toward lower-quality knock-offs.
Open-source is the cheap labor of the programming world, for better or worse. The good places to be are either a for-profit company that is willing to spend market rates to get good labor, or open-source where the probable lack of quality is known but the costs are low (e.g. quality's costs are provided by distros). Being in the middle is simply the worst of both worlds.
To each and every person whining on this thread about how copy protection violates the spirit of Open Source - yeah, it does. And if you don't like it, don't touch the game. Don't buy it - and don't download it either. This noise about how you have some sort of entitlement to steal/pirate/"illegally download"/crack/ "screw-the-man!"/whatever a game simply because you have a political disagreement about copy protection is pathetic.
The difference between Richard Stallman / the FSF and half the posters on this article is that RMS avoids software he disagrees with entirely and ACTIVELY contributes to software he morally supports. In other words, he has principles, votes with his actions, and his patronage of free software DIRECTLY contributes to more and better free software. Whereas the "gimme my Linux games NOW and FREE and screw copy protection!" crowd is in it for a shiny new game, but by NOT paying for (or otherwise patronizing - e.g. with word-of-mouth advertising, filing good bug reports) Linux games they are killing the future of Linux gaming for a quick fix now. This isn't the behavior of rational individuals - this is the behavioral profile of drug addicts.
With apologies to all the honest Linux gamers out there. It's a shame the rotten apples are so enthusiastic about spoiling it for the rest of us.
- Linux STILL doesn't have DTrace, they use kprobes(?) instead because somebody claimed it was almost as good (DTrace users know the Linux equivalent is woefully inadequate and needs several years to even reach feature parity). Not-Invented-Here syndrome.
- Look at kgdb, which Linus finally merged parts of after many years. Linux feels developers shouldn't be using debugging tools on the kernel. Any bets on whether he would merge DTrace at all?
- Even if Linux had DTrace, this fix would be applied in source - which might be good enough for the few thousand people who always run the bleeding edge kernel, but has to trickle through a kernel release cycle (~3 months) or even wait for a distro upgrade cycle to pick up a newer kernel (~6 months for Ubuntu / Fedora, ~2 years for RHEL, maybe 4 years for Debian-stable?). No shortcuts, this isn't a backportable security fix.
For an average Ubuntu user (just picking a popular Linux distro here, no flamewars) and an average Mac OS X user, the 10.5.3 update came out a LOT sooner than the next Ubuntu 8.10 update. Sure the five people who actually care about this have the option of recompiling on Linux, but for everyone else, the closed-source product cycles are moving a lot faster. There's a world of difference between fixing in source and fixing on my local machine, a world open-source zealots conveniently omit when mouthing off about how fast open source can fix things. (Hint: I'll bet Apple fixed DTrace in source in a week also.)Linux is quite good about cycling security fixes through very fast. Anything else - new features or non-security/stability fixes - tends to take many months or even years to percolate to the world at large. Which puts Linux-based OSes (e.g. distros) squarely between Apple (updates every few months) and Microsoft (SPx every few years) for slow product cycles. Note that this isn't the fault of Linux kernel people - it's the whole distro model, which should be a sign that an OS - even an open source OS - is a complicated beast that necessarily has long release cycles.
- Antivirus: works by scanning files being written to/from disk, and by scanning I mean "run ~1 million instructions in an emulator then see if it matches a virus pattern". Requires weekly updates to latest definitions. One of the most successful "security" products
- Static code analysis tools (e.g. Coverity). They take your source code, run a heavy-duty static analysis program on it, and point out memory leaks / double frees, uninitialized variables, and other flaws. My educated guess is that 1/3 of viruses involve such a problem. Useful, but to a manager, you can find a different 1/3 of flaws with a manual code audit that costs about as much.
- Windows Vista (yeah, ha ha). Includes improved account control and privilage separation! Except that most users get so sick of the Allow box that is required for so many things on Windows that Vista has NOT fundamentally increased security.
- Network intrusion detection appliance - you plug this into your network, and it does something when it detects a malicious access pattern - I dunno, maybe it bakes cookies? But detecting malicious access patterns makes you more secure!!!
The security product that takes off will be one that says "with product X, you will never experience security problem Y". Unfortunately, the security products out there are crap (product X decreases chances of problem Y from 1% to 0.01%) and security folks are the most paranoid about providing any guarantees. (Use the word "impossible" at a security conference and watch what the blogosphere does to you. I dare you.)In other words: most security products provide a small marginal gain, while their vendors tout them as essential, must-have products.
The single most telling "security" trait I have seen is from the security group at my employer. They send out a feature proposal, and then flame anyone who disagrees with by saying "if you don't agree to this, we'll probably get hacked next year and it will be your fault for being against the security of our products!". Never mind the technical flaws (ASLR doesn't work when you map 1GB of contiguous memory in a 32-bit process) or performance implications. Security "sells" based on fear, and the security industry sales arm has yet to realize they have cried WOLF too many times for purchasers to take them seriously anymore.