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."
They have access to the source... (Score:5, Insightful)
...so instead of just complaining, they could fix it and offer the patch back to Oracle.
I do believe that people who complain about problems in the Linux kernel and other open source products are often told to do just that. Why expect others to do as you say, if you won't do the same?
So fix it! (Score:4, Insightful)
VirtualBox is open source. Instead of name-calling and whining, how about fixing the underlying problem?
Re:So fix it! (Score:5, Insightful)
The driver is not in the linux kernel tree and distributed separately. So name calling is quite appropriate.
Re:uugh. overblown story (Score:3, Insightful)
I love how the submitted title was exactly that, and the editors decided it wasn't sensational enough
Re:Can that tag ... (Score:3, Insightful)
My intro CS prof always told us that "The first rule of programming is.... the user is an idiot."
And so far that rule has served me well. :)
Re:So fix it! (Score:3, Insightful)
But since the driver is open and distributed under the GPL, perhaps someone should fix it up and integrate it into the kernel, the less third party drivers you need to build and install the better - in kernel drivers always seem more stable and are a lot less hassle to deal with.
Crap? (Score:3, Insightful)
I used vbox for several straight months doing quite a bit of Linux development using it, hosted on a Win7 machine. Other than missing a few nice to have features I could have used, like drag and drop that VMware has, I had zero issues with it. A lot of the features VMware has I didn't need, so stuck with what was working. The "crap" drivers made the VM as seemless as possible for me, and in full screen mode, was no different than booting into Ubuntu in classic mode (which is what I prefer anyway).
I'd really like to know how many people are genuinely affected by these issues. I can't imagine I'm the only one that had zero issues.
Re:So fix it! (Score:3, Insightful)
Sounds like a good idea. Would you like to work on this?
Re:Good job, wants some cheese for your whine? (Score:5, Insightful)
Um, did you even read the article?
Someone released a driver for Virtual Box, said driver causes instability and crashes.
Do you think it's the job of the Linux Kernel devs to re-tool the kernel to work around this, or do you think it's just easier to push it back to the people who wrote the driver?
I mean, seriously, from TFA:
So, if you start off with a working, stable kernel, apply this patch, and then end up with a broken, flaky kernel ... what is the conclusion other than the driver is crap?
I'm not a Linux kernel developer ... but I have had someone try to write some badly written code on top of some systems I supported, only to have them come back and start filing large amounts of bug reports ... and by the time you waste your own time to realize this has nothing to do with your own code, it's too late. Hell, I even had one occasion where someone ignored the explicit statement that it wasn't thread safe, and definitely didn't implement transactions ... only to submit a bug report whining that the transactions didn't work like he wished them to. Of course it didn't, it said right up front it didn't and never would ... but he figured if he just pretended that it did, he'd be able to force us to make it do so. How was that my fault?
If this module is leading to support issues, I can see why they'd draw the line and say "not our fault or problem".
If I wrote crappy code for a Windows app, do you think Microsoft would be willing to listen to me submitting bug reports in Windows if it was becoming readily apparent that the problem wasn't in their code? Because, that's really what this is about from the sounds of it.
I mean, really, Oracle throws poor code over the fence into production and makes the user be the beta tester ... that's not exactly new. Anyone ever seen Beehive? [oracle.com] When I first saw it, it was a freshly steaming turd. No idea what it's like now, but at the time it was largely broken.
I don't see this so much about NIH as "WTF makes this my problem".
Re:They have access to the source... (Score:4, Insightful)
You do understand you are making his point for him, right?
So, explain again why users should use FLOSS instead closed-source when they have "better things to work on than someone else's code" and can buy something that works?
Re:Can that tag ... (Score:5, Insightful)
The second rule is that the programmer is an idiot, especially if they don't believe in the second rule.
Re:They have access to the source... (Score:5, Insightful)
...so instead of just complaining, they could fix it and offer the patch back to Oracle.
I do believe that people who complain about problems in the Linux kernel and other open source products are often told to do just that. Why expect others to do as you say, if you won't do the same?
I think you have it exactly backward. It's reasonable to tell someone to fix something himself if he wants it fixed. The people marking the Virtualbox driver as "crap" probably have no interest in using it themselves. The reason for the tag is to avoid being bothered by other people who want it fixed. Now, the Linux developers who don't care about the driver can more easily tell people who do want it fixed to do so themselves or bitch to Oracle, which seems entirely reasonable.
Re:They shouldn't. (Score:2, Insightful)
I'm not sure what other problems people are going to be concerned about with closed source software that is of a higher priority than 'it doesn't fucking work'.
I don't care how 'open' something is, if its broken, its not going to be something I use and its value is 0 if it doesn't do what I want.
You can make the argument you're making with features and feature sets, it becomes a really fucking stupid argument however when you're trying to say 'well just because this OSS software doesn't do what you want, it still is useful because you have the source ... to something that doesn't do what you want'.
So what would I want to avoid more than 'it doesn't work' that OSS offers me?
Re:They have access to the source... (Score:3, Insightful)
Bingo! This is my biggest single gripe with FLOSS developers/projects in the nearly 15+ years I've used such software. The arrogance of developers to say, "It's open source -- go fix it yourself" is just astonishing, and they don't begin to see the problem. In fact, I saw an exchange exactly like this regarding a very popular e-book reader/conversion program. Some user asked why the top and bottom page margin settings were ignored when converting to PDF format, and the response was that no one cares about PDF format, and the person should grab the source and fix it himself.
The bottom line is that when developers say that they know there's almost zero chance the person will actually do it and fork the project. It's nothing more than a euphemism for, "Go the fuck away and let me play with my toy."
Re:Can that tag ... (Score:5, Insightful)
My intro CS prof always told us that "The first rule of programming is.... the user is an idiot."
He's wrong. Totally, 180 degrees, wrong.
Users know what they want. They may not know all the of steps to get there, and they usually don't know all of the implications and side-effects of those steps. But they do know where they want to end up. It's the software's job to help them get there, in fact that is the one and only job of software. When a user screws up the root cause is a failure of the software to help them take the correct steps to accomplish their goals.
One might argue that there is no practical difference between a user that makes a mistake because they are an idiot and a user that makes a mistake because the application didn't help them enough. But there is a huge difference - you can't fix an idiot, but you can fix your software.
I'm not saying it's easy, in fact user interface stuff is really hard. Which, I think is one of the reasons a lot of developers take the attitude of your prof -- it is so much easier to put the responsibility somewhere else because then the developer is only responsible for "idiot-proofing" their software rather than the much harder job of designing it to enable the user.
Re:So fix it! (Score:5, Insightful)
I don't think name calling is ever really appropriate. It does not create an environment where people are willing to cooperate and work with each other. All it creates is a sense of hostility and defensiveness amongst developers.
"tainted crap" is not helpful as a term or a category in any way shape or form. All it does is send the message that you have nothing but contempt for the other contributors. That can never be helpful.
Perhaps another term, or any other term, would have been better. Terms like critical, serious, unstable, etc. They get the point across without injecting vitriol into the discussion or environment.
Re:Can that tag ... (Score:5, Insightful)
My intro CS prof always told us that "The first rule of programming is.... the user is an idiot."
He's wrong. Totally, 180 degrees, wrong.
Users know what they want..
Whoah, let's just stop right there. In what universe do you live in that users know what they want. Side effects and complexity aside, I have never seen a project (infrastructure OR coding) where the users didnt come in halfway through and ask for things to change because they did not understand their own damn requirements.
I have seen business process people actually break down and start yelling on the phone because Suzie and Tom insist that they said the EXACT oppisite of what they really said during the vetting of the processes to be built into the ERP software. I have personally lost sleep because a user changed the requirements for the sizing of a data warehouse a week before go live..
Users ARE idiots. So are developers and administrators, but at least most of us realize it and admit to it.
Sorry, what? (Score:4, Insightful)
I have been using Virtualbox for years and never had any of those issues. This is the first notice I have about it not being just awesome.
Re:So fix it! (Score:4, Insightful)
Whatever. I don't know the standardized terms and fully admit that.
Funny is one thing, and what I am saying has nothing to do with being politically correct at all and I think most people know that.
"tainted crap" is not a politically charged term. Whether or not it is humorous is going to be a hit or miss depending on the receiver. Or are you really trying to tell me that "tainted crap" is such a well used term in open source that everybody would understand it to be humorous and not to be taken personally?
Even if it is, new developers are coming around all the time and might not understand it for what it allegedly is. I certainly did not, and I am just getting involved with open source to the point where I can start contributing. If somebody marked my contribution as "tainted crap" I would not immediately take it lighthearted and would more than likely see it as non constructive, combative, and hostile.
Open source needs as many contributors as possible and to do so, just maybe, maybe, it might not be such a good idea to be throwing around attributions to other people's contributions like that. Just sayin'.
In any case, you are only supporting my main point. That civilized discourse is the best option in such communities and your point you are trying to make to me, is that it should not have been taken personally and was "civilized" because I should have understood it to be humorous.
Re:They have access to the source... (Score:5, Insightful)
Being a responsible open-source developer means you confirm the bug lies elsewhere before assuming so. The "mark tainted" approach does no such thing. Hmm, I wonder does redhat have a hypervisor of choice?
https://www.redhat.com/virtualization/rhev/desktop/hypervisor/ [redhat.com]
Well call me Uncle Eddit they do. And it's not Virtualbox. Try FreeBSD as your host, it and Virtualbox will be rock solid and and faster networking.
Re:They have access to the source... (Score:5, Insightful)
It's the usual scenario, you pick the idiot:
1. OSS evangelist throws sales pitch at newbie
2. Newbie starts using OSS, tries to file a bug
3. "Scratch my own itch" developer tells him to get lost
You can't on the one side say "Hey, [OSS software] is just as good as [closed payware] and it's free if one will get you "Thanks we're always interested in the bugs our (paying) customer are experiencing" and the other "You got what you paid for, go fix it yourself". And if they say "Well I don't know how to code, could I pay someone to fix it?" then they'll be quoted custom development prices that'll scare anyone right back to COTS software because they're used to that cost being spread over thousands of users. Remember most people are used to getting the whole MS Office suite for $100-150, that's 15-20 hours at minimum wage.
This isn't just some temporary situation, there's a great many people in the FLOSS community that literally don't want users, they just want more developers and anyone who isn't going to contribute anything isn't worth giving the time of day. Then there's the people who says it's so easy your Grandma could use it, but in practice it only works as a tech geek keeps fixing whatever broke in the last upgrade of Ubuntu. Because you don't get help, and if you do get help it's like 10% of the way pointing you in the right direction. You're seeing a regression? Can you bisect it down to what commit caused it? To a person who just use the binary packages on the system you might as well speak alien. Not to mention it's literally hours of work for someone who maybe wanted to take 5 minutes of their time to tell someone there's a bug. That's one of the things I learned, in 95% of the cases it's meaningless to just file a bug because very few developers bother to go around fixing bugs they don't experience themselves, and if they do they're likely to fix it on their own. Oh yes, and unlike any closed source software I've worked with OSS software makes you the steward of the bug. If there's a reproducible test case, it's still easier to file off a "is this still a problem?" than testing it yourself.
Do I blame them? Not really, I do enough work at work to know I don't want to do free work at home as well. But some are setting users off on the completely wrong foot, giving them completely wrong expectations. It really should come with a warning label "For technical users only. You don't have to be a coder, but it helps. You did not pay for this software, so any person you ask for help is likely a volunteer. Your problems are not their problems, so it's not certain anyone wants to help. Don't expect any bugs to fix themselves just because you report it. The more help you can provide developers, the more likely it might get fixed. Getting angry because nobody can or will help will get you nowhere. In short, you're on your own."
It isn't exactly an OSS sales pitch though.
Re:They have access to the source... (Score:1, Insightful)
It's the usual scenario
Ooh ooh, I love a good strawman. Go on...
1. OSS evangelist throws sales pitch at newbie
2. Newbie starts using OSS, tries to file a bug
3. "Scratch my own itch" developer tells him to get lost
Hmm... this almost exactly mirrors my own experience with closed source software... except for the "developer tells" part. 'Cause, see, the closed source guys generally don't tell you shit. They fucking ignore your ass.
You can't on the one side say "Hey, [OSS software] is just as good as [closed payware] and it's free
This, by definition, can't be true since it would only take one example of closed source software being better to disprove it. So, the real problem is people saying and other people being stupid enough to believe unrealistic shit. And it goes both ways. Microsoft shouts from the rooftops how IE is better than Chrome and by extension open source Chromium. Bull fucking shit. And IE ain't free as it requires a Winders license.
"Thanks we're always interested in the bugs our (paying) customer are experiencing" and the other "You got what you paid for, go fix it yourself".
So, you're going to sit there and tell that Goddamned lie that this doesn't work both ways. There are closed source shops that will tell you to stick it where the sun don't shine and there are open source people that will try to move heaven and earth to solve your problem. And that's the truth.
I'm not even going to respond to the rest of your bullshit as it's just more of the same tripe. I hope you're getting paid well and if you really are naive enough to believe this shit, I hope you're still having wet dreams, sonny.
Re:Good job, wants some cheese for your whine? (Score:4, Insightful)
Linux already has two major alternatives to VirtualBox built in (KVM and Xen).
And both of those "alternatives" are stinking, rotting donkey turds from and end-user perspective. VirtualBox is VERY easy to get up and running, while both KVM and Xen are terribly complex (with the latter being almost pointless). From any sane perspective, VirtualBox is the only viable Open Source virtualization software for Linux.
I tried getting my company running on KVM, but gave up after days of frustration.
Xen is a non-starter since it requires the OS to be specifically modified.
It took me all of half an hour to do all the research I needed to get VirtualBox installed and running. My company, and my company's clients, are using VirtualBox.
So yes, VirtualBox is far more important than any other virtualization system for Linux. Maybe if the KVM developers made it user-friendly, it would obsolete VirtualBox. But KVM isn't anywhere even remotely close.
Re:Can that tag ... (Score:4, Insightful)
Problem is, you are the professional software developer, the user isn't. The user is a professional whatever they are. If they are not good at their job, you can call them idiots. If they are not good at stating software requirements, that's your problem.
You must be a user :)
All joking aside, the user is the domain expert. The user may be a professional teacher, or doctor, or architect, or whatever. A developer cannot possibly determine what a good teaching or medical or CAD program should do inside a vacuum. In order for a program to be a success, the users' goals must be extracted somehow and requirements formed from them.
The problem is: getting the user to effectively communicate their goals is hard. Most of the time, users don't even really know what their real goals are, and when they do, they often times express them not as goals, but as ways to achieve that goal.
One of the largest reasons why agile has become so popular is that users only truly know what they don't want.
Sometimes the user gets too specific with the requirements, and ends up slipping in details that make the function less desirable. When discussing the requirements, though, they will absolutely insist they want it exactly the way they described. It isn't until you hand them an app that does it that the user finally realizes they don't like it that way after all. If you're lucky, users will notice it right away and get it changed early in the process. If you're unlucky, they won't notice until full roll-out of your product. If you're especially unlucky, they won't ever fully notice the problem - they will just end up hating your product for reasons they cannot really put their finger on.
Other times, users will come up with what they believe to be a really great idea for something fresh and new they think they want. It will be something they have never had before, but they are convinced it will revolutionize their lives. In some cases, things end up like the overly-detailed feature - it kinda does what the user wants, but maybe not 100% the way they want, or it is something they will use and brings value, but doesn't quite get them all the way to their real goal. Other times, they will take one look at the prototype or finished feature and realize that it was really a dumb idea after all.
In a true antithesis of impossible requirements there are other times when a user will overlook something because they don't even realize what is possible.
You mean if you scan through our records for the last few years, you can extrapolate out when we'll need to buy our supplies? Great! Now we can more effectively plan our budgets. If we scan our billing system's log files, you mean we can find all cases where our transactions from the Foo system have been dropped? You just saved us hundreds of thousands of dollars of lost charges!
It is the business analyst's job to try and direct the users in a way to best gather requirements, sure. Unless you want to require all developers become experts not only in their field, but also in their users' professions, there is still quite a bit of responsibility on the users to figure out what it is they want.