That's just confusion by the writer of the story. This reactor is a scientific experiment, intended only to be the first to demonstrate getting more energy out of a fusion reactor than you have to put into it, not to be a commercially viable power plant. So it's just one step towards the long hoped-for goal of commercially viable fusion.
Re:Note that Mapmakers make intentional mistakes..
on
Open US GPS Data?
·
· Score: 1
OK, I feel stupid for asking this, but are you serious about those being intentional alterations? They sound more like screwups of some kind.
I had an interesting experience a few weeks ago. I was driving a 9th-grader, the son of some friends, to camp. I asked him to hop out and mail some letters for me in a USPS street corner mailbox -- and he didn't know how to open the box to put the letters in! He's an A student, so it kind of reminded me of the Far Side cartoon "Midvale School for the Gifted", where the kid is pushing on the door clearly marked "pull". Humor aside, though, he'd obviously never used a mailbox before.
Essentially, VMware Server is a continuation of the GSX line, with Server 1.0 being the followon to whatever the last version of GSX was (3.x.y -- I forget what exactly). The name change and version number reset was to celebrate the product line becoming free.
One difference from previous practice is that GSX 4 (if it existed) would probably have had full feature parity with Workstation 5. But Server 1.0 didn't get all the WS 5 features added, since we still want people to buy Workstation! However, everything that was in GSX 3 is still in Server 1.0, plus many improvements.
[I work for VMware but am not speaking officially. This is just my understanding.]
The guest OS can't see the FireWire bus, but there's no reason you couldn't put a VM on a FireWire drive as long as the drive works with the host OS. VMware hosted products (i.e., products other than ESX) go through the host OS to read/write virtual disks, configuration files, etc.
Any USB device you plug into the host can be connected to either the guest or to the host. But if you are putting a VM on a USB drive, you'd connect it to the host.
Actually, I think we would really like to see a standard benchmark for VMs that multiple vendors could agree on. I'm not in our performance group, but I've heard rumblings. Your points about how such a benchmark should work to be fair are very well taken.
Since our EULA didn't allow benchmarks to be published, most likely the only benchmarks you've seen are some that the Xen folks did for their SOSP paper, taken on a version of VMware Workstation from several years ago before the EULA was changed to forbid publishing benchmarks.
I understand that recently we changed the EULA back to allow benchmarking again. Let's see if the Xen folks redo their benchmarks or keep making hay by comparing with the old VMware Workstation 3.1 benchmarks...
[Standard disclaimer: I work for VMware, but I'm not speaking officially.]
Google for beos vmware and you'll find lots of reports from people who have gotten it to work. The degree of success depends on what versions of BeOS and VMware products are used. I know we run BeOS here as one of our regression tests.
VMware contributed a driver for our virtual video card to X, and it's part of the XFree86/Xorg tree, so you should be able to use that and get decent video performance on BSD. I haven't tried it myself though -- I'm not a BSD guy.
It's fairly foolish for companies that are techinically exempt from DNC lists to go ahead and make telemarketing calls to people who are on a list. I (and I'm sure most others) put myself on the list because I don't want telemarketers to call me, period. It wasn't my idea to exempt some random selection of industries; if it were my choice, those industries wouldn't be allowed to call and bug me either. I also don't want companies to make fresh sales calls to me just because I've bought something from them in the past.
So calling someone on the list is counterproductive; it will get you nothing but ill-will. A smart company would respect the DNC list even if they're in an industry that's exempt. Smart companies also should be sparing about making dinnertime sales calls to existing customers who are on the DNC list, lest they drive them away.
Mandr{ake,iva}'s printer admin thingie actually runs nmap to sniff your network and find all printers exported by all machines using any protocols it knows how to talk. It's pretty amazing, but it took 10 minutes or more to run on the building network here, during which time the GUI didn't repaint and appeared hung.
I would have killed it in disgust, thinking it really was hung, but first I did a "top" to see if I could tell what it was doing. Then my jaw dropped when I saw it running nmap and starting and stopping many other processes to try to connect to the open ports it was finding, so I let it finish and was fairly impressed. It really needs a progress bar, or better, to have printers pop up in the GUI as they are found.
> Face it -- all of the 'great' scientific and > engineering miracles of our time came from project > managers.
Are you sure it's not that the managers grabbed the credit? Even when they aren't active, Dilbert-style credit-grabbers, managers are the spokesmen for their people and end up being given the credit for the technical work by the media. Some may deserve it -- maybe they were technical leads too -- but some don't.
Not so insightful. If you read the article, you'll notice that Bruce set the output to 100 mW. There was a reason for that: unlicensed transmitters at 100 mW or less are legal in the FM broadcast band.
Google for "beos vmware" (without the quotes) and you'll find messages from lots of people who have tried it, some successfully, and what they did to get it to work. I've seen it run, though I'm not sure which version of BeOS it was.
You're largely (though not entirely) mistaken about how VMware virtual machines work. User code runs in direct execution up to where it tries to make a system call or takes a page fault (etc.) and traps into privileged code. Privileged code is *dynamically* translated at runtime; we don't have big tables that tell us exactly where all the instructions in each supported operating system need to be patched. That would be totally impractical.
We ask what guest OS you're running because we have certain OS-specific optimizations, things that help one OS a lot while hurting others. Most OSes will run fine (though more slowly) on the "other" OS setting. A small number need specific workarounds that are enabled only if you select the right OS setting.
Checked Windows builds work fine AFIAK. If you have one that doesn't work, file a bug report. New OS versions usually work without VMware changes, though not always. Sometimes they'll exercise a system feature that is slow until we optimize it more in the next release, or sometimes their drivers will try to use a device in a new way that our emulation of it doesn't yet support.
We do supply some device drivers for guest OSes, not to work around any shortcomings in our CPU virtualization, but because for performance reasons some of the virtual hardware we implement is not the same as any real hardware that the guest has its own drivers for. The only such devices are the virtual display card (which works as a standard VESA device even if you don't install our driver, albeit slowly), one of the two virtual ethernet cards we support (the other is a standard though elderly AMD card), and one of the two pointing devices (the other is a standard PS/2 mouse). Hmm, I think we also supply some SCSI drivers, but only because some guest OSes don't have good drivers for either of the two standard SCSI cards we emulate (one from BusLogic and one from LSI Logic).
As you can guess from the above, I work for VMware -- in engineering if that makes me more believable to you, although I haven't encountered our marketing folks lying. Standard disclaimer: I'm speaking only for myself here, not officially for VMware.
There is more than one kind of enthusiast. Some folks are enthusiastic about writing emulators. It's fun to get to know the old machines well enough to emulate them, and to see the old software run again on them.
I could argue (overstating my case) that emulator writers are the true enthusiasts for the old machines. Those who merely (;-) collect old hardware and perhaps get it running may have little understanding of how it works inside. Those who emulate it know it intimately.
DOS itself doesn't have sound drivers. DOS games drive the sound hardware directly. (Well, I guess some newer sound cards have initialization software that you have to run to set them up and/or turn on their emulation of older sound cards for DOS programs to use, but that's still not exactly a driver...)
In a VMware VM, the virtual sound card can either be one that's compatible with the old Soundblaster 16, or one that's compatible with the newer Soundblaster Ensoniq AudioPCI (aka es1371). The newer card is used by default in new VMs. You can get the older card if you need it by setting sound.virtualDev = sb16 in your.vmx file.
I've heard the sb16 emulation isn't quite complete enough for some utilities that autodetect the card to find it (sorry, I don't have the details), but it's there if you can tell the software to just go ahead and use it.
Slashdot Mirror
That's just confusion by the writer of the story. This reactor is a scientific experiment, intended only to be the first to demonstrate getting more energy out of a fusion reactor than you have to put into it, not to be a commercially viable power plant. So it's just one step towards the long hoped-for goal of commercially viable fusion.
OK, I feel stupid for asking this, but are you serious about those being intentional alterations? They sound more like screwups of some kind.
If so, it was clever(?) of whoever did it to capitalize the company name wrong.
I had an interesting experience a few weeks ago. I was driving a 9th-grader, the son of some friends, to camp. I asked him to hop out and mail some letters for me in a USPS street corner mailbox -- and he didn't know how to open the box to put the letters in! He's an A student, so it kind of reminded me of the Far Side cartoon "Midvale School for the Gifted", where the kid is pushing on the door clearly marked "pull". Humor aside, though, he'd obviously never used a mailbox before.
Isn't everyone tired of the phrase "perfect storm" yet? Why do people keep using it?
Essentially, VMware Server is a continuation of the GSX line, with Server 1.0 being the followon to whatever the last version of GSX was (3.x.y -- I forget what exactly). The name change and version number reset was to celebrate the product line becoming free.
One difference from previous practice is that GSX 4 (if it existed) would probably have had full feature parity with Workstation 5. But Server 1.0 didn't get all the WS 5 features added, since we still want people to buy Workstation! However, everything that was in GSX 3 is still in Server 1.0, plus many improvements.
[I work for VMware but am not speaking officially. This is just my understanding.]
The guest OS can't see the FireWire bus, but there's no reason you couldn't put a VM on a FireWire drive as long as the drive works with the host OS. VMware hosted products (i.e., products other than ESX) go through the host OS to read/write virtual disks, configuration files, etc.
Any USB device you plug into the host can be connected to either the guest or to the host. But if you are putting a VM on a USB drive, you'd connect it to the host.
Actually, I think we would really like to see a standard benchmark for VMs that multiple vendors could agree on. I'm not in our performance group, but I've heard rumblings. Your points about how such a benchmark should work to be fair are very well taken.
Since our EULA didn't allow benchmarks to be published, most likely the only benchmarks you've seen are some that the Xen folks did for their SOSP paper, taken on a version of VMware Workstation from several years ago before the EULA was changed to forbid publishing benchmarks.
I understand that recently we changed the EULA back to allow benchmarking again. Let's see if the Xen folks redo their benchmarks or keep making hay by comparing with the old VMware Workstation 3.1 benchmarks...
[Standard disclaimer: I work for VMware, but I'm not speaking officially.]
Google for beos vmware and you'll find lots of reports from people who have gotten it to work. The degree of success depends on what versions of BeOS and VMware products are used. I know we run BeOS here as one of our regression tests.
VMware contributed a driver for our virtual video card to X, and it's part of the XFree86/Xorg tree, so you should be able to use that and get decent video performance on BSD. I haven't tried it myself though -- I'm not a BSD guy.
It's always tough for the present to compete with the glorious future.
Try sending dd a SIGUSR1. At least with the current version of GNU dd, this prints the current progress. See the man page.
It's fairly foolish for companies that are techinically exempt from DNC lists to go ahead and make telemarketing calls to people who are on a list. I (and I'm sure most others) put myself on the list because I don't want telemarketers to call me, period. It wasn't my idea to exempt some random selection of industries; if it were my choice, those industries wouldn't be allowed to call and bug me either. I also don't want companies to make fresh sales calls to me just because I've bought something from them in the past.
So calling someone on the list is counterproductive; it will get you nothing but ill-will. A smart company would respect the DNC list even if they're in an industry that's exempt. Smart companies also should be sparing about making dinnertime sales calls to existing customers who are on the DNC list, lest they drive them away.
Mandr{ake,iva}'s printer admin thingie actually runs nmap to sniff your network and find all printers exported by all machines using any protocols it knows how to talk. It's pretty amazing, but it took 10 minutes or more to run on the building network here, during which time the GUI didn't repaint and appeared hung.
I would have killed it in disgust, thinking it really was hung, but first I did a "top" to see if I could tell what it was doing. Then my jaw dropped when I saw it running nmap and starting and stopping many other processes to try to connect to the open ports it was finding, so I let it finish and was fairly impressed. It really needs a progress bar, or better, to have printers pop up in the GUI as they are found.
gandi.net is good, and inexpensive: 12 euros/year.
I orginally found it on a site that rated registrars, but I can't find that site anymore. Sigh.
> Face it -- all of the 'great' scientific and
> engineering miracles of our time came from project
> managers.
Are you sure it's not that the managers grabbed the credit? Even when they aren't active, Dilbert-style credit-grabbers, managers are the spokesmen for their people and end up being given the credit for the technical work by the media. Some may deserve it -- maybe they were technical leads too -- but some don't.
I didn't read djplurvert's post a few down. Well, at least Bruce was trying to be legal.
Not so insightful. If you read the article, you'll notice that Bruce set the output to 100 mW. There was a reason for that: unlicensed transmitters at 100 mW or less are legal in the FM broadcast band.
Google for "beos vmware" (without the quotes) and you'll find messages from lots of people who have tried it, some successfully, and what they did to get it to work. I've seen it run, though I'm not sure which version of BeOS it was.
You're largely (though not entirely) mistaken about how VMware virtual machines work. User code runs in direct execution up to where it tries to make a system call or takes a page fault (etc.) and traps into privileged code. Privileged code is *dynamically* translated at runtime; we don't have big tables that tell us exactly where all the instructions in each supported operating system need to be patched. That would be totally impractical.
We ask what guest OS you're running because we have certain OS-specific optimizations, things that help one OS a lot while hurting others. Most OSes will run fine (though more slowly) on the "other" OS setting. A small number need specific workarounds that are enabled only if you select the right OS setting.
Checked Windows builds work fine AFIAK. If you have one that doesn't work, file a bug report. New OS versions usually work without VMware changes, though not always. Sometimes they'll exercise a system feature that is slow until we optimize it more in the next release, or sometimes their drivers will try to use a device in a new way that our emulation of it doesn't yet support.
We do supply some device drivers for guest OSes, not to work around any shortcomings in our CPU virtualization, but because for performance reasons some of the virtual hardware we implement is not the same as any real hardware that the guest has its own drivers for. The only such devices are the virtual display card (which works as a standard VESA device even if you don't install our driver, albeit slowly), one of the two virtual ethernet cards we support (the other is a standard though elderly AMD card), and one of the two pointing devices (the other is a standard PS/2 mouse). Hmm, I think we also supply some SCSI drivers, but only because some guest OSes don't have good drivers for either of the two standard SCSI cards we emulate (one from BusLogic and one from LSI Logic).
As you can guess from the above, I work for VMware -- in engineering if that makes me more believable to you, although I haven't encountered our marketing folks lying. Standard disclaimer: I'm speaking only for myself here, not officially for VMware.
This month's Dr. Dobb's Journal has the Google Labs aptitude test too.
I guess they had to delete that to make room for all the security fixes.
There is more than one kind of enthusiast. Some folks are enthusiastic about writing emulators. It's fun to get to know the old machines well enough to emulate them, and to see the old software run again on them.
I could argue (overstating my case) that emulator writers are the true enthusiasts for the old machines. Those who merely (;-) collect old hardware and perhaps get it running may have little understanding of how it works inside. Those who emulate it know it intimately.
DOS itself doesn't have sound drivers. DOS games drive the sound hardware directly. (Well, I guess some newer sound cards have initialization software that you have to run to set them up and/or turn on their emulation of older sound cards for DOS programs to use, but that's still not exactly a driver...)
.vmx file.
In a VMware VM, the virtual sound card can either be one that's compatible with the old Soundblaster 16, or one that's compatible with the newer Soundblaster Ensoniq AudioPCI (aka es1371). The newer card is used by default in new VMs. You can get the older card if you need it by setting sound.virtualDev = sb16 in your
I've heard the sb16 emulation isn't quite complete enough for some utilities that autodetect the card to find it (sorry, I don't have the details), but it's there if you can tell the software to just go ahead and use it.