Linked by snydeq on Wed 16th Dec 2009 20:13 UTC
OSNews, Generic OSes InfoWorld's Randall Kennedy takes an in-depth look at VMware Workstation 7, VirtualBox 3.1, and Parallels Desktop 4, three technologies at the heart of 'the biggest shake-up for desktop virtualization in years.' The shake-up, which sees Microsoft's once promising Virtual PC off in the Windows 7 XP Mode weeds, has put VirtualBox -- among the best free open source software available for Windows -- out front as a general-purpose VM, filling the void left by VMware's move to make Workstation more appealing to developers and admins. Meanwhile, Parallels finally offers a Desktop for Windows on par with its Mac product, as well as Workstation 4 Extreme, which delivers near native performance for graphics, disk, and network I/O.
Thread beginning with comment 400202
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: I've given up on Parallels
by gilboa on Fri 18th Dec 2009 00:42 UTC in reply to "RE: I've given up on Parallels"
gilboa
Member since:
2005-07-06

I could point out that the Linux kernel was never designed to support out-of-tree modules - let alone proprietary modules.
I could also point out that a large number of proprietary kernel driver developers have learned to live with this by-design limitation, and by designing their modules with distinct kernel-interfacing-layer (as opposed to calling the kernel API from 10,000 different places), managed to reduce the changes required after each new upstream release. *

... But given that fact that your short comment had more-or-less nothing to do with the subject at hand (the problem might have had nothing to do with upstream kernel API changes and everything to do with sloppy package maintainer in the Ubuntu side or problematic driver building script on parallel's side - I have no idea [but neither do you...]), I can only assume that were simply trolling. Oh well...

- Gilboa
* Personal experience.

Edited 2009-12-18 00:58 UTC

Reply Parent Score: 2

boldingd Member since:
2009-02-19

I could point out that the Linux kernel was never designed to support out-of-tree modules - let alone proprietary modules.


This does not mean that it would either be impossible to add, or unreasonable to request.

The lack of a external-driver-loading interface is still one of the greater (completely unnecessary) hassles that face Linux users on a regular basis. Whatever the reasons for the situation are, and there may be good ones, it's still a significant annoyance that doesn't have to be there. And it's also a risk; I've had it happen where re-installing the same driver dozens of times eventually left the system in an unusable state.

I could also point out that a large number of proprietary kernel driver developers have learned to live with this by-design limitation, and by designing their modules with distinct kernel-interfacing-layer (as opposed to calling the kernel API from 10,000 different places), managed to reduce the changes required after each new upstream release. *


That solution is not perfect, and still causes a lot of unnecessary hassle to many users. It was something of a revelation to the literal rocket-scientists where I work that they where going to have to re-install their graphics drivers every time they let the Red Hat update agent install a new kernel version: after installing an update and then re-installing the ATI binary driver left X unusable on my system, some decided that, as a rule, they should never install updates at all, because it was both too much of a disruption, and too risky! Think about that for a minute: there is very obviously a problem there.

... But given that fact that your short comment had more-or-less nothing to do with the subject at hand (the problem might have had nothing to do with upstream kernel API changes and everything to do with sloppy package maintainer in the Ubuntu side or problematic driver building script on parallel's side - I have no idea [but neither do you...]), I can only assume that were simply trolling. Oh well...

- Gilboa
* Personal experience.


This much is true: whinging about Linux is becoming a popular past-time around here. I do notice that I'm doing it too.

Reply Parent Score: 2

gilboa Member since:
2005-07-06

This does not mean that it would either be impossible to add, or unreasonable to request.


Unless kernel.org completely changes their development model, a cross version stable API is impossible to achieve.
Such an interface can only be maintain by the distributions themselves within a certain release. (Read: RHEL)

The lack of a external-driver-loading interface is still one of the greater (completely unnecessary) hassles that face Linux users on a regular basis. Whatever the reasons for the situation are, and there may be good ones, it's still a significant annoyance that doesn't have to be there. And it's also a risk; I've had it happen where re-installing the same driver dozens of times eventually left the system in an unusable state.


Again, driver-loading-API has nothing to do with it. The -intended- lack of a cross-release stable API is the main issue is.

However, if you use - say, nVidia and DKMS-riding distribution (E.g. Fedora + FreshRPMs) the recompile part is more-or-less invisible to you. At least as long as nVidia makes sure it follows the latest upstream kernel release changes (and they do).

That solution is not perfect, and still causes a lot of unnecessary hassle to many users. It was something of a revelation to the literal rocket-scientists where I work that they where going to have to re-install their graphics drivers every time they let the Red Hat update agent install a new kernel version: after installing an update and then re-installing the ATI binary driver left X unusable on my system, some decided that, as a rule, they should never install updates at all, because it was both too much of a disruption, and too risky! Think about that for a minute: there is very obviously a problem there.


End user should not install out-of-distribution drivers. At least unless they really, really, really knows what they are doing.
Again, the Linux kernel was never designed to support proprietary kernel modules.
If someone -chooses- to use out-of-tree driver, he better make sure he uses the right distribution.

This much is true: whinging about Linux is becoming a popular past-time around here. I do notice that I'm doing it too.


:)

- Gilboa

Reply Parent Score: 2