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."
Can that tag ... (Score:4, Funny)
Can that tag be applied to users, too?
Re: (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: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:Can that tag ... (Score:4, Informative)
Sort of. The second rule was "You aren't nearly as clever as you think you are." Implying that you should always be trying to use tools/libraries/examples/asking_for_help rather than writing everything on your own in the dark. Because the alternative to following this rule was a fun little acronym my prof liked to use: "BFAI" - Brute Force And Ignorance. "You can solve anything with BFAI! But it's probably going to suck. Others will laugh at you."
I like that rule too. :)
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: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.
Re: (Score:3)
I resemble that comment, and let me counter yours with real life things that happen at my company.
It starts off with a requirement. Now, whether this requirement is real or not, is depending on who's asking for it, and if it contributes to sustained profitability in its execution.
Then you start to dig into it and ask users what they want. See what happened? It went from a need to a want when you start asking users more details.
Who's fault is that? No-one's. It's human nature to take requirements furthe
Re: (Score:3)
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.
That was the development team's failure, not the users'. The dev team didn't understand the users' needs and set to work fulfilling the wrong "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..
Then the requirement was wrong from the onset.
Users ARE idiots. So are developers and administrators, but at least most of us realize it and admit to it.
If the dev is letting the user set the requirements and then calling the user an idiot, then the dev doesn't realize where the problem is. The dev is an idiot and neither realizes it nor admits to it.
Part of the job of the dev team is to understand the purpose and needs of the user. Only with that under
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.
Re: (Score:2)
That's an interesting sentiment and I kind of agree. But you know? I have had some serious problems with VirtualBox and USB devices until recently. When I removed a USB device, whether connected to a VM or not, it would cause the whole computer to lock up hard.
Since 4.1.4, however, it seems okay again. I guess the problem was addressed.
But one problem that continues is performance. I can only run ONE guest OS at a time. If I want to create another guest OS, I have to stop the first one. Interestingly
Re: (Score:2)
I used to run 2 XP VMs on the same machine without problem (Ubuntu host). That machine doesn't have the latest VB on it though, probably still on 3.something.
Re: (Score:2)
But one problem that continues is performance. I can only run ONE guest OS at a time. If I want to create another guest OS, I have to stop the first one. Interestingly, while the performance of the second one drops to crap, the first OS runs just fine.
I've run four instances of Linux VMs at the same time without issue. Underlying host was a dual-core, 8GB (DDR2) machine.
Re: (Score:2)
I run Win7 and Linux Vms
Re:Can that tag ... (Score:5, Funny)
"User Error: Please replace user, and try again."
My favorite error message.
Re: (Score:2)
No, but you can apply the term "tainted" to love.
wonderful (Score:4, Informative)
Slashdot Readers Declare Articles "Crap" (Score:5, Funny)
An anonymous coward writes
Re:Slashdot Readers Declare Articles "Crap" (Score:5, Informative)
It is not possible for /. articles to be taken less seriously.
Re: (Score:2)
It is not possible for /. articles to be taken less seriously.
They could be re-posted on 4chan.
Re: (Score:3)
Re: (Score:2)
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?
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: (Score:3)
I think that by declaring the VirtualBox driver to be "tainted crap" they've basically said that it's not worth fixing, or at least that fixing it right would be a large undertaking.
If you're willing to put in the time, I'm sure everybody involved would be grateful ... just don't expect it to be a quick fix.
Re: (Score:3)
Because not everyone's a coder, and not being a coder doesn't preclude you from having requests or needs.
I'm sick and tired of the 'show me the code' mantra even as a coder. I write software for a living and I know what it means to pick up a piece of code I've never worked on before and try to find a bug. I've done it with device drivers and regular software. Digi's serial board drivers gave me a headache one year.
Picking up random pieces of code to fix an error is just asking for problems; aside from th
Re: (Score:2)
They are "Linux Kernel developers". They are (as a class) neither the developers of, nor users of, the Virtual Box driver.
They aren't complaining. They are saying "this is a known source of problems; if you report bugs that involve it, you either need to fix t
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?
They shouldn't. (Score:2)
If the free (like speech) system does not work for that person / company then there is no reason for them to use it.
If, as you postulate, there is a closed source system "that works" then they may want to use that.
UNLESS they want to avoid any of the OTHER problems with closed source software.
Re: (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
Re: (Score:2)
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.
Re: (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 abo
Re: (Score:3)
The arrogance of developers to say, "It's open source -- go fix it yourself" is just astonishing
How is that arrogant? They've given you software for free; you should be grateful. You can make suggestions if you want, but if they don't feel your suggestions are worthy of their time to implement, then you should be the one to fix it, since that feature is so important to you. If you don't like it, go use some other software, if you can even find any that does exactly what you want. Just because those deve
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: (Score:3)
if one will get you "Thanks we're always interested in the bugs our (paying) customer are experiencing"
I can't imagine which one you are talking about, but it's not one that I've ever seen.
Re: (Score:3)
Re: (Score:3)
The only people who care about changing APIs are people who want to make proprietary drivers. The Linux Kernel devs don't care about those people (companies). Making Linux drivers isn't any different from any other OS, except that when you're done you submit it to the kernel for inclusion. After that, the kernel devs do the maintenance for you, fixing things if there's any API changes.
Re: (Score:3)
Well in 2011, Oracle is the new boogeyman. They love to embrace, extend and extinguish open source projects - far more so than Microsoft.
Um, I don't think so, unless I'm missing something. Oracle still supports several open-source projects, such as OpenOffice. They haven't "extinguished" them, they haven't made them closed-source, they're still there. The problem is that they do a half-ass job of supporting their open-source projects. That's still better than MS, who hasn't stopped trying to extinguish
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.
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: (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.
Re: (Score:3, Insightful)
Sounds like a good idea. Would you like to work on this?
Re: (Score:3)
Yes, that's right. Dave Jones has made noteworthy contributions to the kernel, so he gets a free pass to complain about a third-party driver that breaks the kernel, and he is allowed to propose workarounds to correct said breakage, even if they use snarky variable names.
Re: (Score:2)
If he doesn't use it, why would he care about fixing it? He's busy working on the kernel.
That's how it's always worked.
Re: (Score:2)
It's always OK to whine. In fact, open source community has the most whiny folks (next to /.). The difference is whether anyone would care about your whining.
Re: (Score:3)
Perhaps Oracle or users who are impacted should do it? The kernel devs would be foolish to accept every janky piece of shit code and take on the task of fixing it.
Do it for a company with the deep pockets, like Oracle, and you'll have everyone else saying "WTF You did it for them and they can afford to fix it themselves!"
If this bites a user in the ass, let them fix it. If it bites Oracle, let them fix it.
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: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: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: (Score:2)
Or use a PXE boot disk. Not arguing with your point, just adding a work around for your point.
Re: (Score:2)
Oddly enough, I just did this about an hour ago. It wouldn't PXE (boot media not found or some crap), but if I generated an etherboot iso image from rom-o-matic.net and set that up in the virtual CDROM drive, it boots up just fine.
Now if I could just get it to give me something other than 4:3 ratio resolutions in the guest, I would be a happy camper. I want 1900x1200, dammit, not 1600x1200!
(For a bit of context -- Using VBox as a PXE-booted LTSP workstation client on my Mac. Works pretty well, after a signi
Re: (Score:2)
PXE boot worked for me just fine when I tried it.
Re:So fix it! (Score:5, Informative)
Parts of VirtualBox are open source.
Correct
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 non-open source parts of virtual box are free as in beer. That said, PXE isn't a part of it, USB peripherals are.
The open source version supposedly supports PXE boot, but I was never able to make that version work with our environment.
Have you tried getting PXE working with the proprietary virtualbox? I suspect it won't work either, and that the problem is that VirtualBox doesn't like your PXE setup, not that they're trying to force you into the proprietary version.
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.
As much as I would generally agree with you about Oracle, they really haven't screwed up VirtualBox at all since they bought Sun. In fact, it's been seeing pretty good development with the addition of some nice features.
Go ahead (Score:2)
Anyone who cares about fixing the code is welcome to it, but the kernel developers do not care. They just don't want to be bothered with bug reports anymore.
uugh. overblown story (Score:5, Informative)
One of the developers wanted to flag the vbox driver as tainted to keep bug submissions on it from going to kernel devs.
this is *way* overblown.
Re: (Score:3, Insightful)
I love how the submitted title was exactly that, and the editors decided it wasn't sensational enough
Re: (Score:2)
Re: (Score:2)
One of the developers wanted to flag the vbox driver as tainted to keep bug submissions on it from going to kernel devs.
this is *way* overblown.
It's been a while since we had a good flamewar over the kernel, don't be a wet blanket.
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: (Score:2)
As a developer, I understand the frustration of dealing with someone elses shitty software that you have absolutely no control over..... has documented when they occur as proof, which means fixing them should be fairly trivial as well.
If you truly believe that just having a large collection of triggers to a bug is all that is required to render fixing that bug "fairly trivial", then I sincerely hope I never find myself on the same dev team as you.
Denying support for binary-blob drivers is a perfectly reasonable thing to do. The kernel developers have finite time for support. If they choose to spend their time on investigating issues where they are not blocked by arbitrary restrictions on the tools they need to do their job, then fin
Re: (Score:2)
This isn't a binary blob driver. It is an Oracle-maintained open-source driver.
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:Good job, wants some cheese for your whine? (Score:5, Informative)
Re: (Score:2)
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.
So the kernel devs get bug reports for the VirtualBox driver?
Just forward the bug reports upstream to the VirtualBox devs. How hard is it to write a script to do that?
And if they don't get bug reports, how will they know their stuff is broken?
A little cooperation goes a long way.
Re:Good job, wants some cheese for your whine? (Score:4, Informative)
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.
If you're so sure that fixing the buggy driver is easy and a more reasonable approach, why don't you do it? Linux already has two major alternatives to VirtualBox built in (KVM and Xen). It doesn't terribly need Virtualbox, but if Oracle made the effort to improve the quality, I'm sure it could be accepted into the mainline. The reason for tagging the driver as "crap" is because it apparently causes ongoing, hard to diagnose bugs and some Linux developers are tired of dealing with them when they can use the superior built-in options like KVM and virtio. It's not reasonable to expect developers to maintain something they have no interest in themselves and aren't being paid for.
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: (Score:2)
The problem is that Linux will not settle on a stable ABI. The Linux driver model is tainted crap.
Re: (Score:2)
The problem is that Linux will not settle on a stable ABI.
The great thing about the Linux kernel is that it's not tied to a crusty old ABI which it has to support to stop people complaining when their old drivers no longer work. Instead it can throw out old crap when someone comes up with a better design.
Re: (Score:3)
That's not great. It's short sighted and causes considerable headaches for people with older devices.
If they'd sit down for a week and decide on a proper model, they wouldn't have to redesign it EVER. Solaris has kept the same ABI since the beginning, and pretty much every benchmark out there shows it equal to (sometimes slightly ahead, sometimes slightly behind) Linux on the same hardware.
The real reason that the Linux dictators decided not to settle on an ABI is so they can try to pressure and force man
Re: (Score:2)
The real reason that the Linux dictators decided not to settle on an ABI is so they can try to pressure and force manufacturers to release their drivers as GPL software.
The Linux community has been practically gleeful to get binary blob drivers.
The *BSD community is the one complaining about not getting source.
Re: (Score:2)
Thing is, as a Linux user I don't want third party drivers. They suck. They're written quickly, for whatever specific architecture is popular at the time, and quickly forgotten when the hardware gets old.
Hard to throw out a perfectly good laser printer because there's no 64 bit Windows driver for it. Which wasn't even that old.
What I look for is native Linux support. Native as in comes with the kernel. For that reason I don't care about all this whining about the ABI. I wouldn't use such a thing anyway. I w
Oh the irony! (Score:3)
An open-source developer calls an open-source driver "tainted crap", and recommend a commercial alternative instead. Obviously, Oracle has something to do with that, but I'm a bit curious: are there any good open-source (or even free) virtualization software, aside from VirtualBox? Or might it be an area where FOSS just doesn't work very well (there are a few, IMHO).
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
On that note, from someone who has used both Virtualbox and VMWare on Linux (Yes, Virtualbox is crap)
KVM felt really strange for a little bit, I was used to Xen but as our servers slowly moved to Ubuntu LTS, I made the jump.
1-2 days of studying and playing in a lab envornment was all it took to being able to script my own deployment scripts and be able to throw up servers into my lan with just a simple script call. I never had a single problem with KVM and the performance was amazing. I'm not discounting th
Re: (Score:2)
An open-source developer calls an open-source driver "tainted crap", and recommend a commercial alternative instead. Obviously, Oracle has something to do with that, but I'm a bit curious: are there any good open-source (or even free) virtualization software, aside from VirtualBox? Or might it be an area where FOSS just doesn't work very well (there are a few, IMHO).
It's the Phoronix article that mentions VMWare, not the "Linux developers." Oddly that article doesn't mention the two superior, mature alternatives to Virtualbox already part of mainline Linux, KVM and Xen. So, Free Software virtualization is doing just fine, thank you very much.
Re: (Score:2)
An open-source developer calls an open-source driver "tainted crap", and recommend a commercial alternative instead.
I didn't see a recommendation? Did I miss something?
I'm a bit curious: are there any good open-source (or even free) virtualization software, aside from VirtualBox? Or might it be an area where FOSS just doesn't work very well (there are a few, IMHO).
Xen has been around for quite a long time, but due to the different kernel was hard to use casually. Nowadays KVM with the libvirt + layered tooling is an excellent choice and it's in the stock Linux kernel. KVM will rely on hardware virt support, but that's pretty standard now and because of it, can get very close to baremetal for performance. GUIs such as virt-manager [virt-manager.org] are pretty good for desktop use - akin to VirtualBox. If you find it limiting, the
Re: (Score:2)
The recommendation was in the first link (well, it was more of an endorsement, but still). And I realized the second part of my comment was a mistake soon after making it, I just haven't looked at VMs in a while, and when I did, KVM and Xen both looked like fairly painful (I remember Xen a while back wouldn't work with my graphics card... but that was a few years ago) to set up for my casual interest, so I more or less forgot about them. Oh, and neither runs on Windows, which given the number of games I pla
Re: (Score:2)
If you're virtualizing Linux on Linux, KVM with libvirt seems to be the best-supported open source stack going forward. That's best for server apps, though; it doesn't have anything approaching the sort of desktop polish that both vbox and vmware offer.
vmware would appear to be the only really viable solution if both GUI integration and stability are important to you.
Re: (Score:2)
Re: (Score:3)
KVM is pretty comparable (well, if you have virtualization hardware extensions - on older CPUs it doesn't work unlike Virtualbox). I wouldn't call Xen comparable - it doesn't run unmodified guests. For running linux on linux it works fine, but if you don't have the OS source or a Xen-compatible guest OS you're not going to be able to use it.
Of course, if you are running linux on linux and don't mind messing around with it something like linux containers probably would be more efficient.
Re:Oh the irony! (Score:4, Informative)
That has not been true for years.
Xen 3.0 added the ability to run unmodified guests.
http://wiki.xensource.com/xenwiki/XenFaq [xensource.com]
It also depends on having VT. Running virtualbox on a cpu old enough to not have VT support would be an exercise in frustration.
Re:Oh the irony! (Score:4, Informative)
I have a CPU old enough to not have virtualization extensions, and runs a simple instance of Windows XP (to test stuff with Explorer 6, and to run some Win-only university software), and it works like a charm.
When I needed to have a Windows available ASAP, VirtualBox was a life saver. I set up everything through the graphical tool, and I had to read 0 manuals. It just worked in a matter of minutes, not hours or days. If in the future I have to replace everything by QEMU because VirtualBox is crap inside, then fine because I won't be in a hurry anymore.
But if anything, VirtualBox is the opposite of a frustrating experience to me.
Re: (Score:2)
Forgive my ignorance, but I thought both KVM and Xen were "Take over the whole box" kinds of VM. You install KVM or Xen as the host OS, then can create whatever guests you want. Virtualbox and VMware (at least the Player and Workstation), by contrast, are applications. You run the application on top of your host OS and create VMs in that.
I could be completely wrong.
Good idea (Score:2)
Better to be strict, a badly written kernel module in an hypervisor is a security nightmare. Also oracle doesn't seem very idealistic about FOSS and even shows little lip service to it, so I think that simply waiting for them to fix stuff would not have worked so much.
Host or guest? (Score:2)
Does this affect installations where VirtualBox is run on a Linux host? Or does it affect installations where Linux is run as a VirtualBox guest? Also, is the driver in question part of the kernel, or is it part of VirtualBox?
Re: (Score:3)
The driver is part of VirtualBox (you'll get a notification that it needs to be recompiled on launching VirtualBox after every kernel upgrade) and it affects installations where Linux is the host. That said I've had it in for years and haven't had any problems.
Re: (Score:2)
Thanks, I understand the situation better now. Hopefully this move provides some incentive for someone to improve the driver.
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: (Score:3)
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.
The driver in question "vboxdrv" is used on a Linux host, so you never used it running Vbox hosted on Windows. The drivers you're referring to are the guest drivers, which are totally different. Your experience may indicate that the Windows equivalent of vboxdrv is less buggy. It's not surprising if Sun/Oracle put a higher priority on Windows than Linux.
It's not necessarily their place to fix it. (Score:2)
The standard refrain of "it's FOSS! If you don't like it, fix it!" is retarded. As a long time FOSS developer, I have my own projects that use up my free time. Projects that I want to work on and contribute my own way. I don't have time to fix other code that, while qualified to fix it, is not related to my project... Sometimes you can look at another piece of code and say "this is crap, someone needs to fix this"...
For example, there are parts of mythtv that suck ass.. I've submitted a few bug reports, a
Re: (Score:2)
Does that mean I should shut up and not point out deficiencies in hopes that someone will fix them?
- If you don't use the software, we'll never know if it really works at all.
- If you don't submit bug reports, they may never know it's broken.
- If you can contribute code or a suggestion as to what the problem is or what a fix might be, that's even better.
- If it's critical for you and so you have developed a fix and are willing to share, that's better still.
The beauty of FOSS is that you have a wide range of opportunities to participate in making the code better from being an ent
Odd... (Score:2)
To those saying FOSS devs should fix it... (Score:2)
To those saying FOSS devs should fix it, fix it yourself.
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: (Score:2)
Considering that it is also on Windows AND Mac OSX, and is free, and is literally only a Google away, I don't feel the need to explain it to you what it does.
(Hint, the name "Virtual" is a huge giveaway)
Re:And? (Score:5, Funny)
Its a non-existant three dimensional cube
Re:I don't know..... (Score:4)
Ship it! In fact why did you bother with the "run" part?
Re: (Score:2)
I was thinking about making some snide remark about that being the case.
Except for the fact that the driver is custom written for the OS.