Facebook does not share information with advertisers. Facebook's ad system acts as a broker: an advertiser submits an ad, a demographic they wish to see the ad (e.g., gender, age, geographic locale), and a bid. Facebook pairs those ads with users that match the criteria.
Sorry to be coming to the game so late here. Disclaimer/credentials: I've worked in VMware's virtual machine monitor group since 2000.
AFAIK, virtualizing 64 bit guests does still require Intel VT or AMD Pacifica support on the CPU regardless on all products that support 64 bit guests.
You're close. AMD Opterons rev-D and higher can support 64-bit virtual machines without any specific virtualization hardware. They provide 64-bit segment limit checking, which enables our binary translator to work in a way similar to our pre-VT and -Pacifica products. See, e.g., http://communities.vmware.com/message/289914
Even if Pacifica technology is present, we don't default to using it for performance reasons unless "RVI", nee NPT, is also present. These came along with AMD's Barcelona chips in '07. Intel's response, EPT, is in Nehalem.
Here's a perhaps simpler explanation. CPU benchmarks need to parse CPUID output to decide which instructions to implement. Most likely, the benchmark had never heard of these VIA CPUs that implement hot new SSE12 (or whatever) instructions; by claiming to be another vendor, the benchmark used a different instruction mix. I don't know for certain that this is what happened, but I'd bet solid money something like this is the story; we've seen analogous performance degradations at VMware when we fiddle with CPUID too aggressively.
Or at least, supervision by people who know how computers work? 4GB is perfectly sensible for a 32-bit x86; the virtual address space is only 4GB, but the physical address spaces is larger (at least 36 bits on all popular processors). Yes, that means it's awkward to use more than 4GB in a single application, but so what? Using more than 4GB across the system is perfectly transparent.
Also, what's with slamming Microsoft over the "slow" transition to 64-bit? 64-bit XP has been out for, like, three years now. It runs 32-bit applications, because the x64 architecture makes it so ridiculously easy you'd have to intentionally break it. 64-bit Linux does the same, because it takes, like, a line of code to do so. If software makers aren't producing 32-bit apps, it's probably because their customers haven't demanded they do so yet; and the customers probably haven't demanded it because it's unusual for a single application to need 4GB of RAM. Finally, those applications that can frequently use gigondo amounts of RAM in a single virtual address space (e.g., Oracle) for the most part had 64-bit binaries available right out of the gate.
...for those who have/use VMWare ESX Server, you prolly already know it, but for those who do not, you may be surprised to know that VMWare uses Linux at the very heart of it's flagship product.
Common misconception, that. ESX runs on the vmkernel, a proprietary kernel that has no purpose in life other than running VMs. The RHEL 4 image is essentially a "privileged guest" that provides a user interface to the vmkernel, and a platform for tools and user-written utilities.
Stuff like this will make VMWare, Parallels, and others improve their product so it becomes difficult (if not impossible) to detect that the host is virtual.
Why would it be an improvement on our (I work for VMware) products to make them undetectable? To the extent that malware disables itself in the presence of a VMM, VMMs only become more attractive for production use. Not all PCs are alike, and we make no effort to hide it, and yet the world continues in peace. We don't make any effort to hide the chipset, the vendor/model/stepping of the CPU you're using, the particular version of the vendor's BIOS, or the version and patches of the kernel. Why should a VMM be any different? I think we should just consider the virtual machine monitor another piece of the hardware/software stack on which you happen to find yourself running. In the long run, the arms race between "stealthy" VMMs and VMM detectors is hopelessly skewed in favor of the detectors, anyway.
I'm a performance tester who has had to completely reinvent how we do business thanks to virtualization. How do you give assurances to an application that they will perform adequately in a virtual environment when by definition performance will always be dynamic?
VMware ESX Server provides proportional-share guarantees for CPU, memory, network and storage performance. I.e., if you always want 50% of a CPU, or 200% of 2 CPUs, or 75% of the bandwidth of a gigE nic, etc., that can be arranged.
Also has to shovel whole guest images to transfer state between systems, which can incur significant bandwidth usage and latency issues.
Ever heard of a SAN? It's not as if whole vmdk's are flying across the wire. We use paging techniques to reduce the latency for transferring the running guest's memory, so typical server "snoozes" during a VMotion over 1G ethernet are measured in milliseconds. And yes, customers do need to plan for the bandwidth needs of VMotion. Many run a separate network; they're willing to pay for an extra gigE card per hardware server for the flexibility of being able to take the hardware down without interrupting any of its services (which is what VMotion gives them, remember).
Plus you have to limit most of your guest requirements ahead of time (example: virtual memory cannot be dynamically resized in an active guest).
I'm not even sure what you think you're talking about here. "Virtual memory" can be overloaded in this context. While the "virtual physical ram" in a guestis not resizable, it doesn't matter, because ESX can transparently shrink or grow the physical ram backing the VM as needed. If you're curious why what you think is a problem isn't, read up a little.
So, ignoring obvious overhead that VMWare's partial emulation technique incurs, you have serious resource distribution issues.
I work in VMware's virtual machine monitor group. You obviously don't know the first thing about the first thing about how our VMM works, but, at the risk of answering a fool in his folly: what does the supposed CPU overhead you're mislabellling a "partial emulation technique" have to do with the present discussion, anyway? Remember, you' comparing to java-based solution; are you implying that JVMs introduce lower overheads? As for "resource distribution issues": name one. Just one. It has to be real, though. No fair using a mish-mash of plausible sounding "issue" keywords like "latency", "bandwidth", "resource", etc., as you've been doing so far.
Recent versions of Workstation are more than a GSX subset. They include features that are targeted specifically at developers and desktop users, that tend to be less useful for servers. E.g., workstation offers "teams" of associated VMs that power on together, and share a virtual private network connection, for software developers. It has a richer set of lightweight-cloning operations, which makes it more tractable to deploy applications inside VMs. And so on...
Not claiming we're always going to sell workstation forever and ever, just saying it's not necessarily an absurdity to go on charging for it. Not speaking for my employer, etc.
VMware uses various techniques to get around this, including full simulation and binary re-writing.
I know I'm coming to this a little late, but the "binary re-writing" part is Xen/hardware vendor FUD. We translate supervisor-level x86 binaries into user-level x86 binaries, dynamically, on-demand, and adaptively. I.e., VMware's VMM never just branches willy-nilly into the guest OS's kernel code; it dynamically produces an unprivileged binary that has the same effect as the supervisor-level code, only on a software model of the CPU. Saying we "rewrite binaries" makes it sound like we either do so on the guest filesystem, or smash loaded in-memory code. Neither of these happens. Self-inspecting and -modifying privileged code works just fine in the VMware VMM. And "full simulation" is just plain misleading.
Sorry to get all "meta" on this topic right out of the box, but what's with the "Inc." suffix? Does slashdot plan on referring to RedHat as "RedHat Inc.", now? Is there, e.g., a charitable organization named "VMware Outreach for Urban Poverty" with which we are trying to prevent confusion?
Yes, the other virtual machine programs spoof the hosted OS by emulating the interrupt controller and some other hardware. This code for the most part already exists in other Open Source projects, and if someone wants it enough, it could be added to Xen.
Reality check, Bruce. You have absolutlely no idea what you're talking about here, ok? If it were all this easy, somebody would have gotten around to it by now. Go ask the Xen guys what's involved in running unmodified OS'es, and they'll tell you that porting PIC emulation code from Bochs is a pimple on the ass of this bull of a problem.
What on earth makes you think IBM, SGI, et al. don't make unreasonable demands of the Linux kernel folks they hire? They still want to sell machines, and they'll still claim that those machines can walk on water and travel through time to make a buck...
What do you mean, "how that architecture REALLY" responds?" The whole point of an "architecture" is that there can be more than one implementation of said architecture. AMD and Intel provide hardware implementations of the x86; VirtualPC, bochs, et al. provide software implementations of it. Differences amongst those different implementations come down to either unspecified parts of the architecture, or bugs, be those bugs in hardware or software.
Bochs is every bit as real an implementation of the x86 as a Pentium 4. In the outrageously unlikely event that bochs doesn't run this guy's assembly code correctly, he should report a bug, just as he would do in the even more outrageously unlikely event that an Intel processor runs his code wrong.
An actual technical comparison between SVR4 and some of its derivatives with Linux would be interesting. However, this guy is utterly incompetent to perform such a comparison. His babblings about the x86 and threads are just word salad. Consider:
Indeed, I'm starting to believe that threading doesn't have a legitimate role in the Intel (Nasdaq: INTC) x86 hardware environment because the hardware defeats the goal of true concurrency between threads -- and if you can't achieve concurrency, what point is there in threading?
Confused? That's what Paul Murphy hoped. He's just as confused as you are. Ignore him.
None taken, and thanks for the compliment. While I've been hard on plex86 here and in the past, the difficulties that project faced may be instructive in why a free VMware workalike has been slow to emerge.
Does VMware's license forbid its use for comparison purposes?
The blanket license does, though we've made exceptions when researchers ask nicely. See, for example, Marko Zec's OASIS workshop paper from ASPLOS XI, which includes benchmark comparisons against a reasonably recent version of VMware Workstation (that show Workstation in a pretty unfavorable light, I might add). I can only speculate as to why the Xen folks don't get treated as well as Marko did; I don't even know for a fact whether they've asked.
Regardless, it's quite possible they asked and we turned them down, in which case, our bad. I'm not really objecting to the substance of the Xen comparisons; if Workstation 3 is all they can compare to, fine. What I object to is the tone with which the Xen guys usually make this comparison. They strive to leave the impression that they've clobbered the best the industry has to offer, when they're really beating up a straw man. No sane customer would use workstation 3 for the uses the Xen folks are measuring.
I'm not sure where you're getting this. Is it just because he's trying to create a free emulator which is *really* a useful emulator in the sense that it doesn't require you to modify guests that you think he's after revenge?
Kevin threw up his hands a year or two ago and turned Plex86 into a Xen-like pseudo-VMM. Xen is now what plex86 aspires to be.
Disclaimer: I work for VMware, but they don't pay me to post on slashdot.
There are a lot of replies of the form, "Wait a minute, Xen requires that you hack up your guests! What a crock! Typical slashdot hype!" It's true that Xen is more limited than VMware's products, in that you do need to modify guests. However, this doesn't mean that Xen is a joke. (Plex86, for instance, really is a joke, because Kevin Lawton seems to pursue it only in fulfillment of an elaborate VMware-centered revenge fantasy.)
The Xen folks, on the other hand, are smart and mostly serious people. Xen, along with appropriately modified guests, solves some of the problems that our products solve, and for those areas where it fits the bill, it does so in a way that should have lasting performance advantages over full x86 virtualization. What Xen is not, in my opinion, is a virtual machine monitor, for any reasonable definition of VMM. Xen is a microkernel. They don't call it that, because it's hard to get papers about microkernels published these days, but if you think about it, the process of porting an OS to run as a guest under Xen isn't cocnceptually distinct from porting it to run as a personality under Mach or Chorus or whatever. The L4 people didn't even bother renaming their microkernel before repurposing it as a paravirtualization platform.
I think the microkernel analogy helps clarify ones thinking about the promises and limitations of so-called "paravirtualization." Hypervisors are microkernels. In the mid-90's, there was a hope that the whole world would be able to settle on the Mach microkernel. It never happened. Anybody hoping to become the only 'para-hypervisor' will face the same political and commercial challenges.
So to recap: Xen is not a replacement for VMware's products. Xen will probably not take over the world to the degree that its creators would like. Xen is not, however, a joke. The Xen researchers are mostly conscientious, smart people who, fairly enough, would like to see their work have some commercial impact. I really wish they'd stop beating their chests over benchmarks that show them beating a three year old version of our desktop product, though.
It's a myth that C/C++ is particularly fast or efficient for those applications: in the absence of language-provided features like garbage collection, runtime safety, or dynamic typing, people end up reinventing those features over time, badly and less efficiently.
Nice paraphrasing of conventional wisdom, and you're 100% right for anything that runs at user-level. The OP said "operating system kernel," though, and like it or not, kernels run on bare metal. Anything that low-level requires that you write in a language that closely approximates the naked hardware. Unless your CPU has a "new" instruction, that means writing your own memory allocation facilities, typing, etc., no matter what.
So, while it's a "myth" that C is "especially efficient," anybody writing an actual OS will be writing a heck of a lot of C and assembler. Even if you want to write your OS in C# or Haskell or whatever, you'll only get to do so after you write a runtime for your language in something more low-level.
Slashdot Mirror
Facebook does not share information with advertisers. Facebook's ad system acts as a broker: an advertiser submits an ad, a demographic they wish to see the ad (e.g., gender, age, geographic locale), and a bid. Facebook pairs those ads with users that match the criteria.
I work for Facebook, as an engineer in search.
Sorry to be coming to the game so late here. Disclaimer/credentials: I've worked in VMware's virtual machine monitor group since 2000.
AFAIK, virtualizing 64 bit guests does still require Intel VT or AMD Pacifica support on the CPU regardless on all products that support 64 bit guests.
You're close. AMD Opterons rev-D and higher can support 64-bit virtual machines without any specific virtualization hardware. They provide 64-bit segment limit checking, which enables our binary translator to work in a way similar to our pre-VT and -Pacifica products. See, e.g., http://communities.vmware.com/message/289914
Even if Pacifica technology is present, we don't default to using it for performance reasons unless "RVI", nee NPT, is also present. These came along with AMD's Barcelona chips in '07. Intel's response, EPT, is in Nehalem.
Obviously a conspiracy! Where's Ralph Nader?!?!
Here's a perhaps simpler explanation. CPU benchmarks need to parse CPUID output to decide which instructions to implement. Most likely, the benchmark had never heard of these VIA CPUs that implement hot new SSE12 (or whatever) instructions; by claiming to be another vendor, the benchmark used a different instruction mix. I don't know for certain that this is what happened, but I'd bet solid money something like this is the story; we've seen analogous performance degradations at VMware when we fiddle with CPUID too aggressively.
Or at least, supervision by people who know how computers work? 4GB is perfectly sensible for a 32-bit x86; the virtual address space is only 4GB, but the physical address spaces is larger (at least 36 bits on all popular processors). Yes, that means it's awkward to use more than 4GB in a single application, but so what? Using more than 4GB across the system is perfectly transparent.
Also, what's with slamming Microsoft over the "slow" transition to 64-bit? 64-bit XP has been out for, like, three years now. It runs 32-bit applications, because the x64 architecture makes it so ridiculously easy you'd have to intentionally break it. 64-bit Linux does the same, because it takes, like, a line of code to do so. If software makers aren't producing 32-bit apps, it's probably because their customers haven't demanded they do so yet; and the customers probably haven't demanded it because it's unusual for a single application to need 4GB of RAM. Finally, those applications that can frequently use gigondo amounts of RAM in a single virtual address space (e.g., Oracle) for the most part had 64-bit binaries available right out of the gate.
Oh, fine. What the heck. Represent to the fullest.
...for those who have/use VMWare ESX Server, you prolly already know it, but for those who do not, you may be surprised to know that VMWare uses Linux at the very heart of it's flagship product.
Common misconception, that. ESX runs on the vmkernel, a proprietary kernel that has no purpose in life other than running VMs. The RHEL 4 image is essentially a "privileged guest" that provides a user interface to the vmkernel, and a platform for tools and user-written utilities.
Have fun,
Keith (engineer at VMware)
Stuff like this will make VMWare, Parallels, and others improve their product so it becomes difficult (if not impossible) to detect that the host is virtual.
Why would it be an improvement on our (I work for VMware) products to make them undetectable? To the extent that malware disables itself in the presence of a VMM, VMMs only become more attractive for production use. Not all PCs are alike, and we make no effort to hide it, and yet the world continues in peace. We don't make any effort to hide the chipset, the vendor/model/stepping of the CPU you're using, the particular version of the vendor's BIOS, or the version and patches of the kernel. Why should a VMM be any different? I think we should just consider the virtual machine monitor another piece of the hardware/software stack on which you happen to find yourself running. In the long run, the arms race between "stealthy" VMMs and VMM detectors is hopelessly skewed in favor of the detectors, anyway.
I'm a performance tester who has had to completely reinvent how we do business thanks to virtualization. How do you give assurances to an application that they will perform adequately in a virtual environment when by definition performance will always be dynamic?
VMware ESX Server provides proportional-share guarantees for CPU, memory, network and storage performance. I.e., if you always want 50% of a CPU, or 200% of 2 CPUs, or 75% of the bandwidth of a gigE nic, etc., that can be arranged.
HTH,
Keith (vmware employee)
Also has to shovel whole guest images to transfer state between systems, which can incur significant bandwidth usage and latency issues.
Ever heard of a SAN? It's not as if whole vmdk's are flying across the wire. We use paging techniques to reduce the latency for transferring the running guest's memory, so typical server "snoozes" during a VMotion over 1G ethernet are measured in milliseconds. And yes, customers do need to plan for the bandwidth needs of VMotion. Many run a separate network; they're willing to pay for an extra gigE card per hardware server for the flexibility of being able to take the hardware down without interrupting any of its services (which is what VMotion gives them, remember).
Plus you have to limit most of your guest requirements ahead of time (example: virtual memory cannot be dynamically resized in an active guest).
I'm not even sure what you think you're talking about here. "Virtual memory" can be overloaded in this context. While the "virtual physical ram" in a guestis not resizable, it doesn't matter, because ESX can transparently shrink or grow the physical ram backing the VM as needed. If you're curious why what you think is a problem isn't, read up a little.
So, ignoring obvious overhead that VMWare's partial emulation technique incurs, you have serious resource distribution issues.
I work in VMware's virtual machine monitor group. You obviously don't know the first thing about the first thing about how our VMM works, but, at the risk of answering a fool in his folly: what does the supposed CPU overhead you're mislabellling a "partial emulation technique" have to do with the present discussion, anyway? Remember, you' comparing to java-based solution; are you implying that JVMs introduce lower overheads? As for "resource distribution issues": name one. Just one. It has to be real, though. No fair using a mish-mash of plausible sounding "issue" keywords like "latency", "bandwidth", "resource", etc., as you've been doing so far.
So, back to the VMWare thing, yes I suppose you could hack a cluster of ESX servers up to do this.
Or, you could even call it VMotion and ship it three years ago. Hmm...
Recent versions of Workstation are more than a GSX subset. They include features that are targeted specifically at developers and desktop users, that tend to be less useful for servers. E.g., workstation offers "teams" of associated VMs that power on together, and share a virtual private network connection, for software developers. It has a richer set of lightweight-cloning operations, which makes it more tractable to deploy applications inside VMs. And so on...
Not claiming we're always going to sell workstation forever and ever, just saying it's not necessarily an absurdity to go on charging for it. Not speaking for my employer, etc.
Uhh. No.
Poppycock.
e dictable-and-complete_21.html
http://x86vmm.blogspot.com/2005/11/vt-coverage-pr
VMware uses various techniques to get around this, including full simulation and binary re-writing.
I know I'm coming to this a little late, but the "binary re-writing" part is Xen/hardware vendor FUD. We translate supervisor-level x86 binaries into user-level x86 binaries, dynamically, on-demand, and adaptively. I.e., VMware's VMM never just branches willy-nilly into the guest OS's kernel code; it dynamically produces an unprivileged binary that has the same effect as the supervisor-level code, only on a software model of the CPU. Saying we "rewrite binaries" makes it sound like we either do so on the guest filesystem, or smash loaded in-memory code. Neither of these happens. Self-inspecting and -modifying privileged code works just fine in the VMware VMM. And "full simulation" is just plain misleading.
(Disclaimer: I work on VMware's VMM.)
Sorry to get all "meta" on this topic right out of the box, but what's with the "Inc." suffix? Does slashdot plan on referring to RedHat as "RedHat Inc.", now? Is there, e.g., a charitable organization named "VMware Outreach for Urban Poverty" with which we are trying to prevent confusion?
Yes, the other virtual machine programs spoof the hosted OS by emulating the interrupt controller and some other hardware. This code for the most part already exists in other Open Source projects, and if someone wants it enough, it could be added to Xen.
Reality check, Bruce. You have absolutlely no idea what you're talking about here, ok? If it were all this easy, somebody would have gotten around to it by now. Go ask the Xen guys what's involved in running unmodified OS'es, and they'll tell you that porting PIC emulation code from Bochs is a pimple on the ass of this bull of a problem.
There's no problem using SSE3 from within a VM, by the way, assuming your host supports it.
What on earth makes you think IBM, SGI, et al. don't make unreasonable demands of the Linux kernel folks they hire? They still want to sell machines, and they'll still claim that those machines can walk on water and travel through time to make a buck...
What do you mean, "how that architecture REALLY" responds?" The whole point of an "architecture" is that there can be more than one implementation of said architecture. AMD and Intel provide hardware implementations of the x86; VirtualPC, bochs, et al. provide software implementations of it. Differences amongst those different implementations come down to either unspecified parts of the architecture, or bugs, be those bugs in hardware or software.
Bochs is every bit as real an implementation of the x86 as a Pentium 4. In the outrageously unlikely event that bochs doesn't run this guy's assembly code correctly, he should report a bug, just as he would do in the even more outrageously unlikely event that an Intel processor runs his code wrong.
Confused? That's what Paul Murphy hoped. He's just as confused as you are. Ignore him.
None taken, and thanks for the compliment. While I've been hard on plex86 here and in the past, the difficulties that project faced may be instructive in why a free VMware workalike has been slow to emerge.
Does VMware's license forbid its use for comparison purposes?
The blanket license does, though we've made exceptions when researchers ask nicely. See, for example, Marko Zec's OASIS workshop paper from ASPLOS XI, which includes benchmark comparisons against a reasonably recent version of VMware Workstation (that show Workstation in a pretty unfavorable light, I might add). I can only speculate as to why the Xen folks don't get treated as well as Marko did; I don't even know for a fact whether they've asked.
Regardless, it's quite possible they asked and we turned them down, in which case, our bad. I'm not really objecting to the substance of the Xen comparisons; if Workstation 3 is all they can compare to, fine. What I object to is the tone with which the Xen guys usually make this comparison. They strive to leave the impression that they've clobbered the best the industry has to offer, when they're really beating up a straw man. No sane customer would use workstation 3 for the uses the Xen folks are measuring.
I'm not sure where you're getting this. Is it just because he's trying to create a free emulator which is *really* a useful emulator in the sense that it doesn't require you to modify guests that you think he's after revenge?
Kevin threw up his hands a year or two ago and turned Plex86 into a Xen-like pseudo-VMM. Xen is now what plex86 aspires to be.
Disclaimer: I work for VMware, but they don't pay me to post on slashdot.
There are a lot of replies of the form, "Wait a minute, Xen requires that you hack up your guests! What a crock! Typical slashdot hype!" It's true that Xen is more limited than VMware's products, in that you do need to modify guests. However, this doesn't mean that Xen is a joke. (Plex86, for instance, really is a joke, because Kevin Lawton seems to pursue it only in fulfillment of an elaborate VMware-centered revenge fantasy.)
The Xen folks, on the other hand, are smart and mostly serious people. Xen, along with appropriately modified guests, solves some of the problems that our products solve, and for those areas where it fits the bill, it does so in a way that should have lasting performance advantages over full x86 virtualization. What Xen is not, in my opinion, is a virtual machine monitor, for any reasonable definition of VMM. Xen is a microkernel. They don't call it that, because it's hard to get papers about microkernels published these days, but if you think about it, the process of porting an OS to run as a guest under Xen isn't cocnceptually distinct from porting it to run as a personality under Mach or Chorus or whatever. The L4 people didn't even bother renaming their microkernel before repurposing it as a paravirtualization platform.
I think the microkernel analogy helps clarify ones thinking about the promises and limitations of so-called "paravirtualization." Hypervisors are microkernels. In the mid-90's, there was a hope that the whole world would be able to settle on the Mach microkernel. It never happened. Anybody hoping to become the only 'para-hypervisor' will face the same political and commercial challenges.
So to recap: Xen is not a replacement for VMware's products. Xen will probably not take over the world to the degree that its creators would like. Xen is not, however, a joke. The Xen researchers are mostly conscientious, smart people who, fairly enough, would like to see their work have some commercial impact. I really wish they'd stop beating their chests over benchmarks that show them beating a three year old version of our desktop product, though.
operating system kernel or core library,
It's a myth that C/C++ is particularly fast or efficient for those applications: in the absence of language-provided features like garbage collection, runtime safety, or dynamic typing, people end up reinventing those features over time, badly and less efficiently.
Nice paraphrasing of conventional wisdom, and you're 100% right for anything that runs at user-level. The OP said "operating system kernel," though, and like it or not, kernels run on bare metal. Anything that low-level requires that you write in a language that closely approximates the naked hardware. Unless your CPU has a "new" instruction, that means writing your own memory allocation facilities, typing, etc., no matter what.
So, while it's a "myth" that C is "especially efficient," anybody writing an actual OS will be writing a heck of a lot of C and assembler. Even if you want to write your OS in C# or Haskell or whatever, you'll only get to do so after you write a runtime for your language in something more low-level.