Who cares about 110V? Even crazy americans use 120V and anyone sane would use around 230V.
The density of gasoil is lower than 1 so 1 liter of gasoil contains 41MJ, not 45MJ.
I'm sure you can find some industrial burner that will burn 1 liter of gasoil in under 150 seconds but that corresponds to a power of 300kW, way more than what a common home oil boiler can do.
For a 100m2 house 20kW would be a more typical power and that's quite achievable with a electricity: I expect residential electricity plans go up to 36kVA in most developed countries, though you'll save on the subscription price by picking a lower plan. So it's really that last point that may cause electric heating to be slower.
Actually no, it's because heating is one of the few things electricity does really, really badly. It takes long to heat up (which wastes energy) and it does so inefficiently.
No that's completely wrong. There are many forms of electric heating: radiant, convection, fan heaters, underfloor heating, heat pumps, etc., each with their characteristics. For instance radiant heaters are very fast and an electric underfloor heater will be no slower than a gas powered one.
What's inefficient is not the electric heating it's most forms of electricity production.If you burn stuff (coal, oil, gas) to produce electricity you lose two thirds of the calories, whereas you could use more than 70% of them if you were burning the same stuff directly for heating. But that does not apply if your electricity source is photovoltaic panels, wind turbines or hydroelectric power. Also electricity makes it possible to use heat pumps which can let you recoup most of the losses incurred when generating said electricity by burning stuff.
Eh? Well, the way I was taught to calculate a percentage increase was:
(a) 26.3 - 25.6 = 0.7
(b) 0.7/25.6 = 0.02734
It's not a percentage increase in the first place. When the power of the incident light was 100W the old solar cells would produce 25.6W of electrical power. In the same conditions the new cells provide 26.3W. So that's an increase in the delivered power of (26.3 - 25.6) / 25.6 = 2.7%. See none of the numbers being compared are percentages.
>Intel's claims are rather exaggerated. Their claims have already been torn apart on numerous tech forums.
Because people on tech forums always know more than the people who who actually design the process and products right?
Maybe not but they may know more than the people writing the marketing brochures or the commercials selling the things. That said, the technology looks to be different enough from everything that came before that it's quite likely a lot of people are incorrectly applying irrelevant knowledge of how past products worked to this new one. It also feels like disk drives are a bad fit for the technology, but also the only one in the short term. Things will truly get interesting when/if they move to the 'large memory' / 'persistent memory' stage.
According to the court, however, the hacking in this case didn't occur entirely in the U.S. "Ethiopia's placement of the FinSpy virus on Kidane's computer, although completed in the United States when Kidane opened the infected email attachment, began outside the United States,"
So based on this decision a foreign government can also send letter bombs to get rid of dissidents and be safe from lawsuits by any relatives since, in the words of the court, "although the bomb exploded in the United States when the recipient opened the booby trapped letter, the attack began outside the United States".
So besides squashing this lawsuit will the US do anything?
> Germany and Brazil, with at least two more happening in May in Paris and Zurich
That part concerns me. It sounds like to me that they now care more about being PC than producing good software.
Wow! It just shows how prejudiced you are. First have a look at the Debian developers world map. Most of them are in Europe so this is the most logical location for Debian conventions.
Second, America has the best programmers? Really? That's not what HackerRanksays. But more importantly you have to know that most everyone is going to think their country has the best programmers so starting with such a statement speaks a lot about you and discredits the rest of your post.
Likewise, you can use KeepassX on macOS, and Keepass Droid on Android devices.
I tested KeePassX for all of 20 minutes but quickly ran away when I discovered they did not even know how to generate proper random passwords! (interestingly this bug now has a virus attached to it!) After find such an obvious bug I just couldn't trust the rest of the code base. Plus it took them 4 years to fix that security bug which denotes a clear lack of concern about security. And the "fix" was "let's remove the feature". Four years to just remove the feature! Given that KeePassX is a port of KeePass I cannot recommend it either.
I agree that the article is not very clear on that. To me it seemed to complain that "people who pay the most for an artist's music count for the least when sales are tallied" because streaming a song 1500 times costs less than an album but counts as much for the charts. To me that's a bit like complaining that democracy does not make sense because the rich don't have more votes than the poor (technically). Really the charts should be based on how many times people willfully listened to a song, though that's obviously very hard to measure.
The Oxford dictionary definition of storm wave-base implies that storms affect the seabed only to a depth of up to 40m, but two other sources say submarines can be impacted to a depth of roughly 100m rather than 50, at least for hurricane-strength storms. So since this project plans to operate at depths of 100 to 700m so they should be safe.
The system described in the article relies on the pressure difference between the inside and the outside of the sphere. A sphere is ideal for resisting such pressure differences. If the pump was shared it would have to be connected to the spheres via pipes which are essentially cylinders. Cylinders are fine for containing pressure differences as long as the high pressure is inside. But in this case the high pressure environment is outside so the pipe would just flatten. You could certainly use thick walls to avoid that but I guess it would increase cost too much or be fragile.
The system described in the article uses the pressure difference between the inside of the sphere (low pressure to near vacuum) and the water outside. What's interesting is that the deeper you get the higher the pressure difference and thus the more potential energy you get.
In contrast your mechanism only relies on the density difference between your spheres and the water so that no matter what depth they're at the force they exert on the cable is the same. If you place your spheres at a depth of 700m, to extract the same amount of energy as the system in the article you'd have to let them float all the way to the surface. Even staying well under the surface, having the spheres move up and down hundreds of meters seems much more fragile.
ok, so you're going to require manufacturers to make repair manuals and parts available to the general public. What's to stop them from writing in the manual, "purchase and install Comprehensive Assembly #012934" and selling that part which is basically a replacement for the entire unit?
Then according to the article that's the only part they are allowed to provide to their authorized repair centers : "Bills [...] will require manufacturers to sell replacement parts and repair tools to independent repair companies and consumers at the same price they are sold to authorized repair centers." In other words if they do that they can no longer repair any device and can only perform replacements.
So now it's getting interesting. NASA forbids him to reveal the PIN code (and let's assume there's a law in place that underpins this).
With NASA being a government agency it's possible there is a law but it still seems unlikely. I'd rather expect it to be part of his employment contract or a related NDA (non-disclosure agreement). Then it's not two laws being at odds, it's a contract and a law. It seems like the law should prevail, but should it really?
Let's say a Boeing employee travels to France and a border officer there requires that he provides the password for his professional phone. Should he hand it over? Wouldn't every American accuse the French government of being in cahoots with Airbus and thus argue that the Boeing employee's NDA trumps (the hypothetical) French law?
I think what this shows is that we don't want border officers to have unlimited search powers.
It's been seven years since Tesla has gone public. And almost as long since it has shipped product.
No profit - except for the quarter of some accounting tricks. None.
Which only makes sense. Tesla needs to grow fast to profit from their first-mover advantage and achieve a scale that lets them compete with other car manufacturers on a more equal footing. That means taking risks (yes, they may still fail) and investing as much of their income as possible to fuel that growth, profits be damned. But that's okay because it's not like anyone would be dumb enough to invest in a fledgling manufacturing company in a field dominated by giants expecting it to play it safe and immediately serve fat dividends.
Ford - started by an actual brilliant engineer and entrepreneur was profitable in its FIRST QUARTER of doing business.
Yeah. Not only have times changed in a century, but Tesla's competitors have had 100 years to prepare and put up barriers against new entrants! Who could have guessed?
Musk is an incompetent CEO and must step aside for Tesla to survive.
So if you were Tesla's CEO you'd cripple its growth so as to give enough time for its competitors to catch up and then run Tesla into the ground through a price war? It's a good thing you're not in command then.
And even they did use #import, it's easy to fix since #import generates the source code for itself so just compile that instead.
That's just not workable. First it means you still need the Windows toolchain to generate the source that you will then have to transfer to Linux to compile. But then it means your Linux developers will not be able to modify the code they compile because it's auto-generated code and any change they make will be lost the next time around. So if they find a bug or need to make a change they will have to find the matching original source file, make the change there, use the Windows toolchain to regenerate the source code, transfer to the Linux build machine and rebuild. It's too cumbersome.
No it isn't. A Win32 application running over wine involves more context switching and memory contention due to wineserver and other libraries eating up resources.
It is the wineserver that handles all accesses to the registry. For that reason and many others, there is no way you're going to start a Wine or WineLib process without it. So it really makes no difference either way.
Once compiled there is no more difference between a WineLib process and a Wine one than between an a.out process and an elf one. Probably even less since in both cases you have all the PE structures (since some applications access them directly), only in the Windows executable file the PE-stuff is all alone, while in the WineLib case there's an extra ELF wrapper.
In theory a natively compiled Win32 exe might be more optimal if MSVC ran more efficiently than gcc / clang but these days that's unlikely.
Another point for just running the regular Windows executable.
So the rest of the Wine runtime is superfluous bloat. Compiling and linking against winelib saves space on disk because the code that is unused will not be linked into the executable.
WineLib is not something distinct from Wine. Rather it's just the source-level compatibility aspects of Wine: are the functions definitions in the right C header files, do they use the right types, can we produce PE executables, etc. WineLib does not have its own libraries: it uses the Wine dlls. So if you package your application with a self-contained Wine environment you can of course pick and choose which Wine dlls you want to package it with. That requires a non trivial amount of work though and it's not going to impact performance, just disk usage which nobody care much about these days. The latter is particularly true for games since they are typically multi-GB beasts these days while a full Wine is under 0.15GB.
It also means the game can ship only things that it needs to work and can tested to within an inch of its life against those things instead of some random Wine on someone's machine.
The things you care about for games are the X and OpenGL libraries, and graphics driver (including the Linux kernel part) and you cannot package those with your game. Also, as stated before there's no difference between Wine and WineLib there.
Thirdly, a game running on Linux might have to disable or modify its copy protection, change or remove certain texts and assets, interact with Linux in certain ways (e.g. disable screensaver, input devices), interact with other software such as Steam on Linux, or use different file paths.
True. The ISV would typically do that by modifying the source code and producing a Linux-specific Windows binary thus side-stepping all of the toolchain changes. He would then package the resulting Windows executable with Wine as stated before (or have someone like CodeWeavers package with CrossOver). In some extreme cases he may end up developing a Wine dll (i.e. a WineLib dll as all Wine dlls) to interface in some way with Linux and use the API provided by that dll in his game. That's pretty rare though.
Yes you could run a game on Linux through Wine and that's the fallback situation you'd still be running the Windows game. You wouldn't even register as a Linux user on some spreadsheet of the company that produced it.
You're mixing up buying the standard Windows game and running it through Wine with no involvement on the part of the game studio, and buying a Linux or Mac game that has been ported using Wine rather than WineLib. Of course in the first case the game studio is not going to know you're running their game in Linux or Mac since, as far as they know, it only runs on Windows. But if they made a port with Wine it's up to them to decide
Wine is an emulator and it's not an emulator. You can run a Windows executable on the runtime or you can compile Windows source code and run it as a native executable. The latter would be more useful for things like porting games.
The performance of an application ported through WineLib is going to be identical to the performance of the Windows binary running through Wine. So WineLib is no more and no less useful for games than it is for any other application.
What WineLib does buy you however is lots of complications with the compilation toolchain as soon as your code depends on Microsoft-specific C++ features like the omnipresent #import directive, Visual C++ project files (even with winemaker), or the MFC, etc. Things get complex pretty quickly if you also have third-party libraries or use other languages like Visual Basic or even C#.
I recall long ago (2003 maybe?) one of the Wine developers showed up on Tech TV and Leo Laporte asked him something like "if wine isn't an emulator, then what is it?" and the dude answers back "it's an emulator".
The dude in question was Alexandre Julliard, Wine's project leader. The goal of the show was to present Wine so there was a sort of rehearsal during which the journalist said he was going to say something like "so Wine is an emulator" to which Alexandre would object. But during the live interview the journalist actually said "so Wine is not an emulator" which caused Alexandre to take the opposite stance as per the rehearsal. I'd say he a better as a tech leader than as a PR guy and I certainly wouldn't want it any other way.
Even so he did not say that Wine would emulate CPUs which was the common understanding of the word 'emulator' at the time. It's still true that Wine will not deal with CPU emulators or virtual machines. Both of these aspects are best dealt with independently of Wine. So anyone who needs that should run Wine and their application inside their VM or CPU emulator. Except in pathological cases, if the VM / CPU emulator is fast enough to run the application it's still going to be fast enough if you add Wine to the mix.
Wine is a reimplementation of the Win32 and Win64 APIs on top of the Unix (and X, OpenGL, Cocoa) APIs. It's not all that different from Glib and GTK+ which provide their own system and graphics APIs on top of the underlying system APIs, be that Unix or Windows. Of course the Windows APIs were not meant for this so there are some extra complications and side effects (e.g. %fs register usage conflicts on some platforms), but not so much for the general case.
Slashdot Mirror
Your calculations and values are all way off.
Actually no, it's because heating is one of the few things electricity does really, really badly. It takes long to heat up (which wastes energy) and it does so inefficiently.
No that's completely wrong. There are many forms of electric heating: radiant, convection, fan heaters, underfloor heating, heat pumps, etc., each with their characteristics. For instance radiant heaters are very fast and an electric underfloor heater will be no slower than a gas powered one.
What's inefficient is not the electric heating it's most forms of electricity production.If you burn stuff (coal, oil, gas) to produce electricity you lose two thirds of the calories, whereas you could use more than 70% of them if you were burning the same stuff directly for heating. But that does not apply if your electricity source is photovoltaic panels, wind turbines or hydroelectric power. Also electricity makes it possible to use heat pumps which can let you recoup most of the losses incurred when generating said electricity by burning stuff.
E = 0.5 * m * v^2
This is exactly GP's point. If E(25) >= catastrophic bodily harm,
Which it isn't whereas E(50) obviously is.
But if a car is doing 25 mph and hits a kid, it's just going to tickle?
E = 0.5 * m * v^2
Enough said.
Eh? Well, the way I was taught to calculate a percentage increase was:
(a) 26.3 - 25.6 = 0.7 (b) 0.7/25.6 = 0.02734
It's not a percentage increase in the first place. When the power of the incident light was 100W the old solar cells would produce 25.6W of electrical power. In the same conditions the new cells provide 26.3W. So that's an increase in the delivered power of (26.3 - 25.6) / 25.6 = 2.7%. See none of the numbers being compared are percentages.
>Intel's claims are rather exaggerated. Their claims have already been torn apart on numerous tech forums.
Because people on tech forums always know more than the people who who actually design the process and products right?
Maybe not but they may know more than the people writing the marketing brochures or the commercials selling the things. That said, the technology looks to be different enough from everything that came before that it's quite likely a lot of people are incorrectly applying irrelevant knowledge of how past products worked to this new one. It also feels like disk drives are a bad fit for the technology, but also the only one in the short term. Things will truly get interesting when/if they move to the 'large memory' / 'persistent memory' stage.
According to the court, however, the hacking in this case didn't occur entirely in the U.S. "Ethiopia's placement of the FinSpy virus on Kidane's computer, although completed in the United States when Kidane opened the infected email attachment, began outside the United States,"
So based on this decision a foreign government can also send letter bombs to get rid of dissidents and be safe from lawsuits by any relatives since, in the words of the court, "although the bomb exploded in the United States when the recipient opened the booby trapped letter, the attack began outside the United States".
So besides squashing this lawsuit will the US do anything?
Since America has the best programmers...
> Germany and Brazil, with at least two more happening in May in Paris and Zurich
That part concerns me. It sounds like to me that they now care more about being PC than producing good software.
Wow! It just shows how prejudiced you are. First have a look at the Debian developers world map. Most of them are in Europe so this is the most logical location for Debian conventions.
Second, America has the best programmers? Really? That's not what HackerRanksays. But more importantly you have to know that most everyone is going to think their country has the best programmers so starting with such a statement speaks a lot about you and discredits the rest of your post.
Not really. My meter is inside my house, so a meter reader needs to knock on my door and ask for permission to enter.
On the flipside, I let anybody wearing some random badge come in and check the meter, so just knock if you want to take a look.
And you have to take half a day off whenever the meter reader comes by.
Likewise, you can use KeepassX on macOS, and Keepass Droid on Android devices.
I tested KeePassX for all of 20 minutes but quickly ran away when I discovered they did not even know how to generate proper random passwords! (interestingly this bug now has a virus attached to it!) After find such an obvious bug I just couldn't trust the rest of the code base. Plus it took them 4 years to fix that security bug which denotes a clear lack of concern about security. And the "fix" was "let's remove the feature". Four years to just remove the feature! Given that KeePassX is a port of KeePass I cannot recommend it either.
I agree that the article is not very clear on that. To me it seemed to complain that "people who pay the most for an artist's music count for the least when sales are tallied" because streaming a song 1500 times costs less than an album but counts as much for the charts. To me that's a bit like complaining that democracy does not make sense because the rich don't have more votes than the poor (technically). Really the charts should be based on how many times people willfully listened to a song, though that's obviously very hard to measure.
The Oxford dictionary definition of storm wave-base implies that storms affect the seabed only to a depth of up to 40m, but two other sources say submarines can be impacted to a depth of roughly 100m rather than 50, at least for hurricane-strength storms. So since this project plans to operate at depths of 100 to 700m so they should be safe.
if it were near where I live I'd say they also need to be testing it in winter storms, but perhaps they're planning on using it in a sheltered area.
Winter storms have no effect at depths of 50 m and more.
Well, for one thing we'd be able to fight off any alien invasion by uploading a virus to their ship!
The system described in the article relies on the pressure difference between the inside and the outside of the sphere. A sphere is ideal for resisting such pressure differences. If the pump was shared it would have to be connected to the spheres via pipes which are essentially cylinders. Cylinders are fine for containing pressure differences as long as the high pressure is inside. But in this case the high pressure environment is outside so the pipe would just flatten. You could certainly use thick walls to avoid that but I guess it would increase cost too much or be fragile.
The system described in the article uses the pressure difference between the inside of the sphere (low pressure to near vacuum) and the water outside. What's interesting is that the deeper you get the higher the pressure difference and thus the more potential energy you get.
In contrast your mechanism only relies on the density difference between your spheres and the water so that no matter what depth they're at the force they exert on the cable is the same. If you place your spheres at a depth of 700m, to extract the same amount of energy as the system in the article you'd have to let them float all the way to the surface. Even staying well under the surface, having the spheres move up and down hundreds of meters seems much more fragile.
For as long as the seemingly prevailing opinion is that global warming is a Chinese conspiracy?
ok, so you're going to require manufacturers to make repair manuals and parts available to the general public. What's to stop them from writing in the manual, "purchase and install Comprehensive Assembly #012934" and selling that part which is basically a replacement for the entire unit?
Then according to the article that's the only part they are allowed to provide to their authorized repair centers : "Bills [...] will require manufacturers to sell replacement parts and repair tools to independent repair companies and consumers at the same price they are sold to authorized repair centers." In other words if they do that they can no longer repair any device and can only perform replacements.
So now it's getting interesting. NASA forbids him to reveal the PIN code (and let's assume there's a law in place that underpins this).
With NASA being a government agency it's possible there is a law but it still seems unlikely. I'd rather expect it to be part of his employment contract or a related NDA (non-disclosure agreement). Then it's not two laws being at odds, it's a contract and a law. It seems like the law should prevail, but should it really?
Let's say a Boeing employee travels to France and a border officer there requires that he provides the password for his professional phone. Should he hand it over? Wouldn't every American accuse the French government of being in cahoots with Airbus and thus argue that the Boeing employee's NDA trumps (the hypothetical) French law?
I think what this shows is that we don't want border officers to have unlimited search powers.
It's been seven years since Tesla has gone public. And almost as long since it has shipped product.
No profit - except for the quarter of some accounting tricks. None.
Which only makes sense. Tesla needs to grow fast to profit from their first-mover advantage and achieve a scale that lets them compete with other car manufacturers on a more equal footing. That means taking risks (yes, they may still fail) and investing as much of their income as possible to fuel that growth, profits be damned. But that's okay because it's not like anyone would be dumb enough to invest in a fledgling manufacturing company in a field dominated by giants expecting it to play it safe and immediately serve fat dividends.
Ford - started by an actual brilliant engineer and entrepreneur was profitable in its FIRST QUARTER of doing business.
Yeah. Not only have times changed in a century, but Tesla's competitors have had 100 years to prepare and put up barriers against new entrants! Who could have guessed?
Musk is an incompetent CEO and must step aside for Tesla to survive.
So if you were Tesla's CEO you'd cripple its growth so as to give enough time for its competitors to catch up and then run Tesla into the ground through a price war? It's a good thing you're not in command then.
And even they did use #import, it's easy to fix since #import generates the source code for itself so just compile that instead.
That's just not workable. First it means you still need the Windows toolchain to generate the source that you will then have to transfer to Linux to compile. But then it means your Linux developers will not be able to modify the code they compile because it's auto-generated code and any change they make will be lost the next time around. So if they find a bug or need to make a change they will have to find the matching original source file, make the change there, use the Windows toolchain to regenerate the source code, transfer to the Linux build machine and rebuild. It's too cumbersome.
No it isn't. A Win32 application running over wine involves more context switching and memory contention due to wineserver and other libraries eating up resources.
It is the wineserver that handles all accesses to the registry. For that reason and many others, there is no way you're going to start a Wine or WineLib process without it. So it really makes no difference either way.
Once compiled there is no more difference between a WineLib process and a Wine one than between an a.out process and an elf one. Probably even less since in both cases you have all the PE structures (since some applications access them directly), only in the Windows executable file the PE-stuff is all alone, while in the WineLib case there's an extra ELF wrapper.
In theory a natively compiled Win32 exe might be more optimal if MSVC ran more efficiently than gcc / clang but these days that's unlikely.
Another point for just running the regular Windows executable.
So the rest of the Wine runtime is superfluous bloat. Compiling and linking against winelib saves space on disk because the code that is unused will not be linked into the executable.
WineLib is not something distinct from Wine. Rather it's just the source-level compatibility aspects of Wine: are the functions definitions in the right C header files, do they use the right types, can we produce PE executables, etc. WineLib does not have its own libraries: it uses the Wine dlls. So if you package your application with a self-contained Wine environment you can of course pick and choose which Wine dlls you want to package it with. That requires a non trivial amount of work though and it's not going to impact performance, just disk usage which nobody care much about these days. The latter is particularly true for games since they are typically multi-GB beasts these days while a full Wine is under 0.15GB.
It also means the game can ship only things that it needs to work and can tested to within an inch of its life against those things instead of some random Wine on someone's machine.
The things you care about for games are the X and OpenGL libraries, and graphics driver (including the Linux kernel part) and you cannot package those with your game. Also, as stated before there's no difference between Wine and WineLib there.
Thirdly, a game running on Linux might have to disable or modify its copy protection, change or remove certain texts and assets, interact with Linux in certain ways (e.g. disable screensaver, input devices), interact with other software such as Steam on Linux, or use different file paths.
True. The ISV would typically do that by modifying the source code and producing a Linux-specific Windows binary thus side-stepping all of the toolchain changes. He would then package the resulting Windows executable with Wine as stated before (or have someone like CodeWeavers package with CrossOver). In some extreme cases he may end up developing a Wine dll (i.e. a WineLib dll as all Wine dlls) to interface in some way with Linux and use the API provided by that dll in his game. That's pretty rare though.
Yes you could run a game on Linux through Wine and that's the fallback situation you'd still be running the Windows game. You wouldn't even register as a Linux user on some spreadsheet of the company that produced it.
You're mixing up buying the standard Windows game and running it through Wine with no involvement on the part of the game studio, and buying a Linux or Mac game that has been ported using Wine rather than WineLib. Of course in the first case the game studio is not going to know you're running their game in Linux or Mac since, as far as they know, it only runs on Windows. But if they made a port with Wine it's up to them to decide
Only if the libraries are as fast or as feature-rich as they are under Windows.
That's true when comparing Wine to Windows. But this thread is comparing Wine to WineLib and they both use the same libraries.
Wine is an emulator and it's not an emulator. You can run a Windows executable on the runtime or you can compile Windows source code and run it as a native executable. The latter would be more useful for things like porting games.
The performance of an application ported through WineLib is going to be identical to the performance of the Windows binary running through Wine. So WineLib is no more and no less useful for games than it is for any other application.
What WineLib does buy you however is lots of complications with the compilation toolchain as soon as your code depends on Microsoft-specific C++ features like the omnipresent #import directive, Visual C++ project files (even with winemaker), or the MFC, etc. Things get complex pretty quickly if you also have third-party libraries or use other languages like Visual Basic or even C#.
I recall long ago (2003 maybe?) one of the Wine developers showed up on Tech TV and Leo Laporte asked him something like "if wine isn't an emulator, then what is it?" and the dude answers back "it's an emulator".
The dude in question was Alexandre Julliard, Wine's project leader. The goal of the show was to present Wine so there was a sort of rehearsal during which the journalist said he was going to say something like "so Wine is an emulator" to which Alexandre would object. But during the live interview the journalist actually said "so Wine is not an emulator" which caused Alexandre to take the opposite stance as per the rehearsal. I'd say he a better as a tech leader than as a PR guy and I certainly wouldn't want it any other way.
Even so he did not say that Wine would emulate CPUs which was the common understanding of the word 'emulator' at the time. It's still true that Wine will not deal with CPU emulators or virtual machines. Both of these aspects are best dealt with independently of Wine. So anyone who needs that should run Wine and their application inside their VM or CPU emulator. Except in pathological cases, if the VM / CPU emulator is fast enough to run the application it's still going to be fast enough if you add Wine to the mix.
Wine is a reimplementation of the Win32 and Win64 APIs on top of the Unix (and X, OpenGL, Cocoa) APIs. It's not all that different from Glib and GTK+ which provide their own system and graphics APIs on top of the underlying system APIs, be that Unix or Windows. Of course the Windows APIs were not meant for this so there are some extra complications and side effects (e.g. %fs register usage conflicts on some platforms), but not so much for the general case.