Linux Kernel Developer Declares VirtualBox Driver "Crap" 357
An anonymous reader writes "Linux kernel developers have decided to mark the VirtualBox kernel driver as tainted crap for the significant number of problems this open-source driver has caused. The VirtualBox kernel driver reportedly causes memory corruption and other problems. With the driver being flagged as tainted crap, bug reports caused by the driver will be taken less seriously."
Good job, wants some cheese for your whine? (Score:3, Interesting)
Really, you should just refuse to provide any help or consideration for people using virtual box like you guys do if anyone is using a binary driver. I mean lets face it, thats what you're doing here. This is just another form of NIH syndrome.
As a developer, I understand the frustration of dealing with someone elses shitty software that you have absolutely no control over.
This however is one of those situations where there is no doubt what so ever that rather than just whining about it, he could have done something useful about it. The drivers aren't THAT complex in the first place. If he is so confident that it has these problems then surely he has documented when they occur as proof, which means fixing them should be fairly trivial as well.
Instead of being so high and mighty ... oh never mind, whats the point, its not your fault, its someone elses, your code is awesome and everyone will bow down to you guys. I know you guys like to think Linux is ruling the world, but you're still no where near big enough to start trying to pull an Apple/Google/Microsoft and force people to do it your way. You've tried this before and again, you'll lose.
Re:So fix it! (Score:4, Interesting)
VirtualBox is open source. Instead of name-calling and whining, how about fixing the underlying problem?
Parts of VirtualBox are open source. If you want to network boot your VM by PXE, you need to pony up the cash for the closed source version maintained by Oracle. The open source version supposedly supports PXE boot, but I was never able to make that version work with our environment.
As with MySQL, open source contributions to dual licensed software are not frequent nor great. With someone like Oracle at the helm, community cooperation with their free and open version is even further diminished.
Re:They shouldn't. (Score:4, Interesting)
The intent is not "in open source, the burden is on users to fix issues." Rather, the intent is "in open source, frustrated users have a potential recourse other than relying on the developers."
Unfortunately, the usual phrasing does not make this clear.
In the closed source world, it's perfectly normal when filing a bug report to get back a polite "we acknowledge that issue, but it isn't affecting much of the user community. In the interest of prioritizing our scarce development resources, we will not be addressing that issue on our current roadmap, unless it impacts a significantly larger fraction of our paying customer base."
In the open source world, I think the intent of "use the source, Luke" is to be shorthand for something similar:
"We acknowledge that issue, but it has not been reported by much of our user community. In the interest of prioritizing our scarce development resources, we will not be addressing that issue on our current roadmap, unless it impacts a significantly larger fraction of our user base. Please continue to report other bugs; all bug reports are valuable feedback, and we do fix many user-reported bugs based on our triage and prioritization processes. Note that, if this bug is sufficiently problematic for you, and you have the necessary skills and resources, you have the source! So you are welcome to fix this for yourself, should you be so inclined."
Unfortunately, frazzled developers are far more likely to give a curt response rather than spending the time to write up something more polite. FWIW, I'd be happy for anyone who wishes to use the wording I just used.
Again FWIW, my own experience is that both closed source and open source developers vary widely in their support level. As a for-instance, I found a problem with a certain closed-source device vendor's product not being RFC compliant, and therefore failing to properly inter-operate with an open-source management program. A coworker contacted the vendor as a (paying) customer, while I contacted the mailing list for the open-source software. The author of the open-source software emailed me a workaround within hours. My coworker is still waiting for a useful response from the vendor.
Conversely, we had several interoperability problems between a different vendor and a different open-source program. The vendor actually had already made a patch for one of the issues, but we couldn't deploy it. The maintainer of the open-source program refused to workaround one of the issues on their end, because the vendor had patched it, and we should just install the patch. While I didn't like the situation, this was a major problem for us, so I was motivated to hit the source. Because I had source, I was able to write my own patch.
Obviously, YMMV.