Not very well. Xen with PCI pass-through might work here, but that requires having a dedicated graphics card for each OS. 3D video generally involves some amount of writing directly from userspace to hardware, without any kernel interaction after initial setup. This is difficult to do right in all cases with virtualization, but they are working on it.
I do. It's delightfully convenient if you do development work, because you can run tests in something a lot more realistic than a chroot build directory. It's particularly nice if you're doing kernel work. For cluster testing, the only alternative involves $20k worth of hardware.
So, Joe user may not need this, but it's a major feature for the people who work on improving the Linux kernel. That alone justifies including these features.
Xen has all the features that KVM and lguest have. That's the problem. Xen is extremely complex, and the patches to support it are very invasive. This is why KVM beat it getting merged. LWN infamously predicted Xen could get merged as early as 2.6.10, whereas lguest was only created a few months ago, weighing in at a mere 5000 lines of code.
Xen does some really cool things, but it has a lot of human overhead in terms of management and maintenance that the other two don't have. Now you get to pick the right tool for the job, which is how it should be.
You're thinking of a microkernel. Most modern operating systems have a monolithic virtual memory model, in that a large number of system services run in the kernel memory space, but they use dynamic linking to achieve a degree of modularity. That said, the Linux kernel internal API is fairly fluid, so any code that runs in kernelspace has to be maintained quite regularly to keep up with the changes. Merging your code into the main tree makes this much easier.
Bash and ls are still userspace. All of these virtualization implementations have userspace tools that control them, but they need some help in kernelspace to set up the virtual memory mappings, and that's the code that's been merged.
These aren't even close to the same solution. KVM provides hardware-assisted virtualization, with Linux as the hypervisor. Lguest provides linux-in-linux paravirtualization (no hardware support), and is extremely lightweight (5000 lines of code, total), but lacks many advanced features. Xen provides both paravirtualization and full virtualization, runs under a custom hypervisor intended to run multiple different OSes (Linux, Solaris, Windows, etc.) simultaneously, and has a plethora of sophisticated features, such as live migration (and all the maintenance headache of the correspondingly huge codebase).
They each fill very different niches, so there are very good reasons for having all 3 in the kernel.
Look at their versions. The latest release is 2.4.26-based, with a 2.6.15 beta. Clearly it's an invasive patchset, which must be difficult to maintain. Back when the project started, this was probably a worthwhile effort, but the HPC world has changed.
My guess is that the advent of commodity NUMA hardware (Opteron) motivated more development of MPI applications and libraries, since HPC workloads often perform better on NUMA hardware using MPI between the NUMA nodes. If all your applications are MPI-aware, there's a lot less motivation to use an SSI solution that's a couple years behind on hardware support and a pain to maintain.
...they wouldn't need to convince anyone. They could just sell the energy, use that money to make a bigger device, sell more energy, lather, rinse, repeat. You don't need investors when you can print money.
This is really perfect for my needs. I already use my neighbors' wireless and high-speed cable connection for things like bittorrent anyway. I just need something that's always on that I can configure for port forwarding so I can ssh in to my desktop when I need to.
If Nvidia is committed to making the 2D nv driver work, then why the @#$% doesn't dual-monitor support work? It's not that hard, it just requires knowing the hardware. There's not a shred of OpenGL involved.
The poster's proposal sounds like a nice NAS, and a lousy SAN. A NAS saves you money by keeping your important data in a centrally-managed system with automated backups so that lay users cannot easily lose it, and so that it can be shared easily between multiple systems. A SAN saves you money by packing a big chunk of high-performance storage behind extremely-high-redundancy hardware and provisioning dedicated slices out to your servers so that you don't need dual redundant RAID controllers with mirrored write caches in each box that's dealing with critical data. They solve different problems.
Since a NAS centrally manages all of its storage, it can take advantage of fancy filesystem tricks to boost performance on SATA drives with good sequential access speeds. When you're physically provisioning chunks of disk on a SAN, you just can't do that, and you really need the 15k RPM drives with the 3 ms seek times, since you'll have numerous independent operations on physically discontiguous sectors on the platter, if performance matters at all. This is why SANs have enormous write caches.
Of course, since power failures or controller failures can knock out a write cache, high-end SANs have dual controllers with mirrored battery-backed write caches. This is specialized hardware, not something you can hack together from parts on Newegg.
The poster's idea is interesting for solving certain problems, but I don't think it's a panacea.
Parallel programming is hard, but I'm not sure that's really such a bad thing. I don't mean that I like inadequate tools, but there *is* a fundamental human limit, and overcoming it requires discipline and training or experience. If the rise of multi-core machines results in greater stratification to distinguish Software Engineers from Computer Programmers, I won't shed a tear. There's a lot of bad software in this world, and simple economics dictates that this will always be true. If we can push that niche towards less important, marginal tasks that are happy being single-threaded, and away from the primary workloads of our increasingly SMP machines, maybe software on the whole will suck a tiny bit less.
I don't think you're off the mark there. During the lifetime of Vista, > 64 GB configurations will become common. During the lifetime of the next version, they'll become routine, and 32-bit will be bumping its head on the ceiling even with PAE.
I use Thunderbird for work and Gmail for my personal mail. Each is ideal for its designated task. If I was forced to use webmail for work and Thunderbird for personal mail, I would go nuts.
So, enough with these "foo is better than bar" declarations. Both exist and are popular because they are the best solution for *some* problem.
Microsoft gives their interns dual 21" monitors, and Google and Yahoo give their interns dual 24" monitors. These are not dotcom bubble companies. They are fiscally responsible, profitable technology companies. They employ lots of engineers, and have made an informed decision that giving a huge amount of screen real estate to even their interns is good for the business.
I work for a profitable tech company, and I have dual 19" LCDs. I can also help myself to our collection of old CRTs if I want to hook up one of my test boxes, but with dual-input monitors and ssh, I haven't needed to.
10 minutes, start to finish, most of which is spent getting a snack while the install runs. Keeping/home on a separate partition or an NFS share works wonders. I spent many hours tweaking my configuration to death a long time ago, and it keeps working with newer distros.
For tweaking the system software configuration, virtualization is really nice. I have a bunch of stock install images I can copy and boot up in a few seconds and customize from there.
If you do frequent OS installations, it's definitely worth investing a little bit of time with/home over NFS or on a separate partition, NIS/LDAP, VMware/Xen/KVM, kickstart, etc. The investment will pay off very quickly.
You don't need a "Workstation", you need a "Test Box". A workstation is an overpriced desktop used to make trouble. A test box is an inexpensive server used to prevent trouble. Aside from the label, they are identical, but it makes all the difference to the bureaucrats.
An off-by-one error in some edge detection code I wrote caused blurry parts of an image to remain unchanged, but enhanced every detail on in-focus parts several times over. As a result, if you took a picture of someone up close, and there were people in the background, applying this filter would enhance the finest of wrinkles and make the person look about 100 years old, with no change to the rest of the image.
The sun's radiation is distributed evenly in 2 dimensions. Thus, algae effectively grows in a 2D space as well. There's really no way around that.
Switchgrass has a strong potential to be much more economical than either oil corn, and we have the technology to do it now. All we need is the investment (probably from the government) to cover the initial refinery costs and 3 years of growth until the first crop is ready for harvest, and then we'll have a self-sustaining switchgrass industry. The problem is that farmers can't afford to go 3 years without crop revenue, and nobody will invest in them without the confidence that there's going to be a buyer, which requires a centralized large-scale effort to get that economic system jump-started.
These days, most people don't write assembly after college, but reading assembly is still a critical skill. You need to understand how the computer works at a low level if you're going to do OS, compiler, performance, or security work; or expertly debug anything written in a compiled language. The assembly I wrote in school was an important experience to prepare me for the assembly I now read on a weekly basis.
The Client and Server channels do not contain all of the same packages. The compiz window manager is not in the Server channel, so this is a non-issue.
HP sells laptops with freeDOS. Presumably everyone who purchases one of these ends up installing something else, as the intersection of the set of freeDOS users and the set of new laptop users is basically empty. All I want is a laptop without the Windows tax. With freeDOS, they can run minimal hardware diagnostics (from a bootable floppy, even) to determine if the hardware needs servicing, and leave me to mess with the software on my own.
I worked front line support all the way through college. It was this, not my degree, that got me my a job doing front line support in a rather fast-growing organization with plenty of opportunity for advancement. I've been promoted twice in as many years, and now I'm working at a technical level that regularly uses the stuff I went to college for.
If your current job is a dead end, find a job that's not going to be a dead end, even if it's doing the same thing at first. In my case it was a fast-growing company. University IT departments are also a good option, because it gets your foot in the door for any other job at the whole university, and they tend to be quite accommodating if you want to take classes on campus.
Not very well. Xen with PCI pass-through might work here, but that requires having a dedicated graphics card for each OS. 3D video generally involves some amount of writing directly from userspace to hardware, without any kernel interaction after initial setup. This is difficult to do right in all cases with virtualization, but they are working on it.
Just buy Cedega and be done with it.
I do. It's delightfully convenient if you do development work, because you can run tests in something a lot more realistic than a chroot build directory. It's particularly nice if you're doing kernel work. For cluster testing, the only alternative involves $20k worth of hardware.
So, Joe user may not need this, but it's a major feature for the people who work on improving the Linux kernel. That alone justifies including these features.
Xen has all the features that KVM and lguest have. That's the problem. Xen is extremely complex, and the patches to support it are very invasive. This is why KVM beat it getting merged. LWN infamously predicted Xen could get merged as early as 2.6.10, whereas lguest was only created a few months ago, weighing in at a mere 5000 lines of code.
Xen does some really cool things, but it has a lot of human overhead in terms of management and maintenance that the other two don't have. Now you get to pick the right tool for the job, which is how it should be.
You're thinking of a microkernel. Most modern operating systems have a monolithic virtual memory model, in that a large number of system services run in the kernel memory space, but they use dynamic linking to achieve a degree of modularity. That said, the Linux kernel internal API is fairly fluid, so any code that runs in kernelspace has to be maintained quite regularly to keep up with the changes. Merging your code into the main tree makes this much easier.
Bash and ls are still userspace. All of these virtualization implementations have userspace tools that control them, but they need some help in kernelspace to set up the virtual memory mappings, and that's the code that's been merged.
These aren't even close to the same solution. KVM provides hardware-assisted virtualization, with Linux as the hypervisor. Lguest provides linux-in-linux paravirtualization (no hardware support), and is extremely lightweight (5000 lines of code, total), but lacks many advanced features. Xen provides both paravirtualization and full virtualization, runs under a custom hypervisor intended to run multiple different OSes (Linux, Solaris, Windows, etc.) simultaneously, and has a plethora of sophisticated features, such as live migration (and all the maintenance headache of the correspondingly huge codebase).
They each fill very different niches, so there are very good reasons for having all 3 in the kernel.
Look at their versions. The latest release is 2.4.26-based, with a 2.6.15 beta. Clearly it's an invasive patchset, which must be difficult to maintain. Back when the project started, this was probably a worthwhile effort, but the HPC world has changed.
My guess is that the advent of commodity NUMA hardware (Opteron) motivated more development of MPI applications and libraries, since HPC workloads often perform better on NUMA hardware using MPI between the NUMA nodes. If all your applications are MPI-aware, there's a lot less motivation to use an SSI solution that's a couple years behind on hardware support and a pain to maintain.
...they wouldn't need to convince anyone. They could just sell the energy, use that money to make a bigger device, sell more energy, lather, rinse, repeat. You don't need investors when you can print money.
If the iPhone is as big as a PDP-11, I think I'll stick with my Treo.
e ssor
http://en.wikipedia.org/wiki/Programmed_Data_Proc
This is really perfect for my needs. I already use my neighbors' wireless and high-speed cable connection for things like bittorrent anyway. I just need something that's always on that I can configure for port forwarding so I can ssh in to my desktop when I need to.
If Nvidia is committed to making the 2D nv driver work, then why the @#$% doesn't dual-monitor support work? It's not that hard, it just requires knowing the hardware. There's not a shred of OpenGL involved.
The poster's proposal sounds like a nice NAS, and a lousy SAN. A NAS saves you money by keeping your important data in a centrally-managed system with automated backups so that lay users cannot easily lose it, and so that it can be shared easily between multiple systems. A SAN saves you money by packing a big chunk of high-performance storage behind extremely-high-redundancy hardware and provisioning dedicated slices out to your servers so that you don't need dual redundant RAID controllers with mirrored write caches in each box that's dealing with critical data. They solve different problems.
Since a NAS centrally manages all of its storage, it can take advantage of fancy filesystem tricks to boost performance on SATA drives with good sequential access speeds. When you're physically provisioning chunks of disk on a SAN, you just can't do that, and you really need the 15k RPM drives with the 3 ms seek times, since you'll have numerous independent operations on physically discontiguous sectors on the platter, if performance matters at all. This is why SANs have enormous write caches.
Of course, since power failures or controller failures can knock out a write cache, high-end SANs have dual controllers with mirrored battery-backed write caches. This is specialized hardware, not something you can hack together from parts on Newegg.
The poster's idea is interesting for solving certain problems, but I don't think it's a panacea.
Parallel programming is hard, but I'm not sure that's really such a bad thing. I don't mean that I like inadequate tools, but there *is* a fundamental human limit, and overcoming it requires discipline and training or experience. If the rise of multi-core machines results in greater stratification to distinguish Software Engineers from Computer Programmers, I won't shed a tear. There's a lot of bad software in this world, and simple economics dictates that this will always be true. If we can push that niche towards less important, marginal tasks that are happy being single-threaded, and away from the primary workloads of our increasingly SMP machines, maybe software on the whole will suck a tiny bit less.
I don't think you're off the mark there. During the lifetime of Vista, > 64 GB configurations will become common. During the lifetime of the next version, they'll become routine, and 32-bit will be bumping its head on the ceiling even with PAE.
...except slower and more expensive.
I use Thunderbird for work and Gmail for my personal mail. Each is ideal for its designated task. If I was forced to use webmail for work and Thunderbird for personal mail, I would go nuts.
So, enough with these "foo is better than bar" declarations. Both exist and are popular because they are the best solution for *some* problem.
According to this guy:
http://tastyresearch.wordpress.com/work-stories/
Microsoft gives their interns dual 21" monitors, and Google and Yahoo give their interns dual 24" monitors. These are not dotcom bubble companies. They are fiscally responsible, profitable technology companies. They employ lots of engineers, and have made an informed decision that giving a huge amount of screen real estate to even their interns is good for the business.
I work for a profitable tech company, and I have dual 19" LCDs. I can also help myself to our collection of old CRTs if I want to hook up one of my test boxes, but with dual-input monitors and ssh, I haven't needed to.
10 minutes, start to finish, most of which is spent getting a snack while the install runs. Keeping /home on a separate partition or an NFS share works wonders. I spent many hours tweaking my configuration to death a long time ago, and it keeps working with newer distros.
/home over NFS or on a separate partition, NIS/LDAP, VMware/Xen/KVM, kickstart, etc. The investment will pay off very quickly.
For tweaking the system software configuration, virtualization is really nice. I have a bunch of stock install images I can copy and boot up in a few seconds and customize from there.
If you do frequent OS installations, it's definitely worth investing a little bit of time with
You don't need a "Workstation", you need a "Test Box". A workstation is an overpriced desktop used to make trouble. A test box is an inexpensive server used to prevent trouble. Aside from the label, they are identical, but it makes all the difference to the bureaucrats.
An off-by-one error in some edge detection code I wrote caused blurry parts of an image to remain unchanged, but enhanced every detail on in-focus parts several times over. As a result, if you took a picture of someone up close, and there were people in the background, applying this filter would enhance the finest of wrinkles and make the person look about 100 years old, with no change to the rest of the image.
The sun's radiation is distributed evenly in 2 dimensions. Thus, algae effectively grows in a 2D space as well. There's really no way around that.
Switchgrass has a strong potential to be much more economical than either oil corn, and we have the technology to do it now. All we need is the investment (probably from the government) to cover the initial refinery costs and 3 years of growth until the first crop is ready for harvest, and then we'll have a self-sustaining switchgrass industry. The problem is that farmers can't afford to go 3 years without crop revenue, and nobody will invest in them without the confidence that there's going to be a buyer, which requires a centralized large-scale effort to get that economic system jump-started.
These days, most people don't write assembly after college, but reading assembly is still a critical skill. You need to understand how the computer works at a low level if you're going to do OS, compiler, performance, or security work; or expertly debug anything written in a compiled language. The assembly I wrote in school was an important experience to prepare me for the assembly I now read on a weekly basis.
"So, what do you do?"
"I'm a parasite that lives on larger parasites."
"Well, it was nice meeting you. I've got to get going."
The Client and Server channels do not contain all of the same packages. The compiz window manager is not in the Server channel, so this is a non-issue.
HP sells laptops with freeDOS. Presumably everyone who purchases one of these ends up installing something else, as the intersection of the set of freeDOS users and the set of new laptop users is basically empty. All I want is a laptop without the Windows tax. With freeDOS, they can run minimal hardware diagnostics (from a bootable floppy, even) to determine if the hardware needs servicing, and leave me to mess with the software on my own.
I worked front line support all the way through college. It was this, not my degree, that got me my a job doing front line support in a rather fast-growing organization with plenty of opportunity for advancement. I've been promoted twice in as many years, and now I'm working at a technical level that regularly uses the stuff I went to college for.
If your current job is a dead end, find a job that's not going to be a dead end, even if it's doing the same thing at first. In my case it was a fast-growing company. University IT departments are also a good option, because it gets your foot in the door for any other job at the whole university, and they tend to be quite accommodating if you want to take classes on campus.