Slashdot Mirror
Linux Kernel Developer Declares VirtualBox Driver "Crap"
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."
...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?
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
VirtualBox is open source. Instead of name-calling and whining, how about fixing the underlying problem?
There's no -1 for "I don't get it."
I love how the submitted title was exactly that, and the editors decided it wasn't sensational enough
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. :)
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.
WWJD -- What Would Jimi Do?
(Smash amp, burn guitar, take home the groupies)
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? 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".
Lost at C:>. Found at C.
The second rule is that the programmer is an idiot, especially if they don't believe in the second rule.
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?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
When information is power, privacy is freedom.
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.
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.
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.
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.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."