But this thread is about getting net energy out of biofuels.
This statement doesn't make sense.
I said it elsewhere in the thread.
Energy on earth comes from one of four sources. Period.
A) "Fresh" Solar B) "Stored" Solar C) Nuclear D) Lunar (Tidal)
That's it. If you're using energy on this rock, you're using one of those 4 sources. Everything else is illusion.
As far as I'm concerned, BioFuel, like Hydrogen, is a portion of the fuel cycle that "stores" energy much better than electrochemical batteries. BioFuel, like Hydrogen, is a mobile form of power storage. Nothing else.
Tidal would be an obvious choice for desalination plants.
Bingo!
There are so many ways to use tidal energy for desalination that our company doesn't know which "branch" to take beyond the feasibility study stage. We're not a big company, more of small tech house, and our lab floor is littered with scale model prototypes for tidal desalinization. 10 years ago, none of these things made economic sense. Now, the developing Arab nations most in need of desalinization cannot afford to use their oil domestically (more $$ in selling it). They take their oil money and invest it into technologies like ours; and we'll sell it world wide.
We're working on solar desalinization using a passive lens system in order to irrigate crop fields. I imagine that we could grow biofuel crops, we're currently looking at citrus orchards.
Energy != Oil. Furthermore, Energy doesn't "come from" biofuel, either.
On this planet, energy is either a) stored solar, b) fresh solar, c) nuclear, or d) lunar (tidal). That's it. Everything else is a clever trick. Biofuel is about capturing solar energy; and that water you "feed" the biofuel has to come from somewhere.
Star Markets may be the only stores in the U.K., but in the U.S. the cub foods and Jewel/Osco chains both have deployed Pay By Touch. That's a fairly significant foot print, at least near Chicago.
Even though you've got the capitalization of the "giga" wrong, I'm interested in this 100 Mega-Gigabit Seconds per mile connection you speak of.
Will this enable me to transfer a set number of seconds based upon miles? I'm interested in your ideas, and would like to subscribe to your newsletter.
75% of people on Slashdot all tout the party line, "Don't believe everything you read in the mainstream media." It doesn't matter whether the discussion involves Iraq, Microsoft, SCO, Linux, IBM, the U.S. government, or CmdrTaco. If it's on CNN, don't believe it.
Well, here I am, to tell you, be skeptical of regular Joes, as well.
In this discussion, the only people not agreeing with the article said things like, "it was a 3rd party card." The thing is, I don't understand why you would believe ANY of it without some kind of proof, or evidence.
A video is easy to doctor. A video without any techniques and methods is monumentally stupid. I could have made the video in question in about 10 minutes.
Anyways, this is a big "FUCK YOU" to all the naysayers out there who continually announce that the end of OS X's relative security is on the horizon. I'm not saying that OS X is without flaw, and I'm not even saying there won't be widespread virus outbreak (however unlikely). But for godsakes, at least demand a shred of evidence before you proclaim the end of an era.
Not to mention that he could try something like Autopackage, or even klik://
The solutions are out there; they usually involve some additional software, and a focus on producing distribution neutral packages, but that really isn't a big deal; it's a small consideration one should make at the start of the project, not something you try to bolt on at the end of the project.
It's always going to be a pain to go back and fix bugs/locate distribution-specific tendancies and fool around with specific package managers. But you don't have to anymore; you just have to develop differently.
If you must call WINE something to support an all-or-nothing attitude, call it a simulator. That's what it does - simulates Windows behavior so that programs written for Windows will work on another operating system.
Even saying it's a simulator goes WAY too far.
Wine = reimplementation of Win32. It's an "emulator" in the same way that Compaq's reverse engineered PC BIOS was an "emulator" for IBM's BIOS. It's a "simulator" the same way that an airplane "simulates" bird flight.
Functionally, architecturally, and in practice, Wine is no different than OpenGL, BASH, or X. That's the long and the short of it.
In Computer Science, native code is machine code. However, in the context of an interpreted language, native code is the platform dependent implementation of language features and libraries.
Now, what does Wine/Cedega do? How do they fit in here?
Wine/Cedega does not: A) Perform Just-in-time compilation, B) Perform Dynamic recompilation, or C) Provide a VM environment.
What DOES Wine/Cedega do? Provide the WIN32 API and DLL environment on Unix-y systems. That's all; it provides the guts and hooks to run WIN32 code natively on Linux/OS X/Unix/BSD.
Wine is an emulator in the "coarse" sense of the word, in the same way that an automobile is emulation of a horse and buggy. (Horseless carriage, anyone?). Wine is just a Unix version of the WIN32 API; it's no more an emulator than an OS X OpenAL implementation, or X-Windows on Windows. That it runs Windows binaries _natively_, with no recompilation necessary, is a testament to the developers; it does not mean that it "emulates" anything.
Porting Wine to a platform is no different than porting ReiserFS, OpenGL, OpenAL,.NET, or Java to a platform. It's an API; nothing more. Using the word "emulation" to describe is misleading at best, and is usually done by folks with an agenda. Applications running under wine are most certainly running natively. Think about it; what about ReactOS? It "natively" uses WIN32 code for everything; but it's WIN32 implementation is pulled directly from Wine.
They've currently implemented much of SM 2.0. Adapating to OpenGL 2.0 has allowed them to speed up development substantially, particularly with OpenGL 2.0 being well supported by ATI and Nvidia. SM 3.0 should be along some time after that; before GLSL there was a lot more going on in reinterpresting shaders, but the direction that OpenGL is going has really helped them out.
AFAIK, most games that pick between SM 2.0 and 3.0 don't experience significant visual degredation, it's generally just performance. Either way, Transgaming is definitely picking up speed; and given that DirectX 10 is Vista only I don't expect any kind of rapid adoption.
By the time SM 4.0 or whatever, and DirectX 10 are requirements, Transgaming will already be there.
On my Linux box, I run World of Warcraft WIN32 using Cedega, and get native (or better than native) performance. Wine, and hence Cedega, a Wine fork, or NOT emulation. They are binary API compatiblity layers. They are an implementation of WIN32 for Linux.
It's a userspace app that runs WIN32 EXEs. That's all.
There's no emulation. It's wicked fast, and there's minimal overhead. The only "real" overhead is that you're paging code to run more types of binaries than are avaliable on Windows; XP only supports COM and EXE, while Linux (with a WINE-alike) support ELFs, A.OUTs, EXEs, and COMs. More APIs=more memory, and generally more paging.
There are some performance issues with particular titles, but this is not because of "emulation", and an architectural performance limitation. These issues are because of poor implementations of various DirectX/Direct 3D features, which Transgaming is constantly working on.
Furthermore, Cider, which is a rebadged Winelib, does much of the translation work before hand. There's no reason for Cider not to support the latest and greatest; in fact, Transgaming is positioning Cider as something you build into your project during development; when you compile, you can target either Windows or OS X, and Cider should handle all the work for you. Take a look at the Winelib documentation. I'll quote:
Compiling apps under Winelib should theoretically involve only makefile changes. In practice, you will encounter header problems, and the likes -- for these it is much better (and faster) to submit a patch, rather than document them. So for the remainder of the section, let's assume the Wine headers are good enough for the application in question.
So, why doesn't Valve, or Blizzard, or whoever, use Winelib to build games? Because Winelib has limited DirectX capabilities, and because it would require a fair amount of developer interaction with Codeweavers or Wine-dev mailing lists to get problems sorted out. Not to mention that Codeweaver's traditional focus has been on office applications, not gaming.
Enter Cider. Transgaming will offer, for a nominal fee, to deal with all those problems for you. Plus, Transgaming's already done much of the work regarding DirectX; they've currently implemented a substantial portion of SM 2.0, with 3.0 on the horizon. Direct Play, Direct Sound, Direct Input, yadda yadda, all work properly. Dollars to donuts Cider will utilize OpenAL, enabling EAX up to 5.0.
It's silly to think of Winelib, or Cider applications as "non-native". They use the WIN32 API, and they're probably not using QT/GTK2 widgets; but these are most definitely Linux/OS X applications. Heck, 99% of games use their own GUI setup anyways; it's not like your going to be look at MS widgets inside Doom 3.
It's just a different API. As the implementation improves, performance improves. Indeed, in certain regards the Wine (and Transgaming) people have actually surpassed Microsoft, and as such performance is better. For example, Linux's scheduler can perform vastly better than Microsoft's, and games load (and textures pop into place) quite a bit quicker. Comparing two similarly built systems (I have side-by-side desktops with my girlfriend), one on Windows, one on Linux, World of Warcraft loads textures faster, and experiences substantially less texture loading lag, on Linux. When I switch on Cedega's Windows Scheduler implementation, the behavior regresses to be similar to the Windows system.
There's no reason for WINE or Cider to be inferior to native Win32. There are plenty of issues in Win32 that can be "fixed", and run faster; and there are plenty of places that Linux's (and/or OS X) superior performance can be leveraged. It's not an "emulation" architectural issue, it's just a $$/Manpower engineering issue, and the gap has closed significantly. Working directly with developers while they are in the primary phases of development will enable high-quality, high-performance WIN32 applications on Linux/OS X.
I'm a moderate fan of Nintendo, I admire their business acumen, and I think the gamecube is a solid system.
But I most definitely think that the gamecube pad sucks. Horribly.
The buttons are all different sizes, for god sakes. And it does NOT fit in my hand. I like the Dual Shock controller, and I like the Xbox gamepad; but I hate the gamecube pad.
Honestly, I've had nothing but trouble with MS keyboards/mice.
They cannot be used in my office, since they don't last very long. We don't have similar problems with Kensington, or Logitech (by far the most reliable brand).
MS Wireless Keyboard/Mouse sets tend to last no more than 1-2 years before either the keyboard or mouse fails, which basically requires you to replace the set. I've never had a Logitech wireless set go bad, with the partial exception of one old, old wirless logitech (mechanical) mouse I have that tends to squeak a little bit when you right click.
As for use with any operating system, get real. Their hardware is the only type out there that doesn't "just work". It requires funky drivers that ignore certain outputs, and generally just sucks. One's listed here. I've never experienced a problem like that with a Logitech.
It's a couple extra dollars, but the Logitech stuff works better (vastly better), and lasts. Microsoft's crap breaks down (mechanically), or remains funky without software fixes. If you like, I'll send you a pile of broken, newish MS keyboards/mice.
I know I'm pulling up threads from the way past, but what I'm suggesting you seem to have missed.
I'm suggesting that you do L7 QoS on your own machine, and then handle that via one of the GUI utilities I've pointed you at.
It's not _quite_ as clear as doing it one application at a time, but if you think of it in terms of protocols it may actually make more sense.
Don't throttle Limewire.exe, throttle the Gnutella protocol. Don't throttle CuteFTP, throttle the FTP protocol. You don't need to do this global, as in on the network level. I just meant "globally" as in system wide.
It would seem to me that this would be more sophsticated, not less, than NetLimiter. Furthermore, you get a great deal more flexibilty, you could potentially set a maximum system wide bandwidth, with SSH on high priority, and FTP on low priority, with an FTP maximum usage of 90% of the main maximum usage. And you can do all this via GUI.
Things like that, things that wouldn't be possible in Netlimiter.
I guess we can agree to disagree; all I'm suggesting is that in certain instances the way that you are used to using Windows applications is fulfilled, by the most part, by a different sort of Linux solution, and as such no one really bothers to fill the remaining niche.
I cannot really think of any situation where you wouldn't be better off with L7 QoS and a nice Linux GUI than a simple inflexible hard bandwidth cap, but that's just me.
Apparently, Version 6.0 of Crossover Office intends to have significant support for Direct3D 9, and for gaming. They also intend to support Half Life 2 on OS X.
IIRC, there is one commercial fork. That's Cedega.
Crossover Office is Codeweaver's project, and the Codeweavers people are deeply tied into the WINE project. Many, many, many of the patches to Wine come from Codeweavers, and Codeweavers treats WINE as a trunk for development.
This doesn't mean that Wine has 100% of the codeweavers stuff at any given time; but it does all get back.
Transgaming already does translate DirectX and Direct3D to OpenGL with little overhead. If the rumors are true, they are currently working on Pixel Shaders 2.0 and up.
Cedega is a fork of Wine from back when Wine was BSD licensed. It's really cool; I play lots of Windows games on Linux with it.
Presumably Cider is a Winelib-style toolkit to generate OS X games from Windows games. I, for one, welcome our Cedega-lib powered OS X overlords;-)
There's no way to prove whether or not the are telling the truth. It will require further disclosure. They claim that they can target by Mac address, and that your machine merely has to be scanning for open APs, not actively associated.
1. It was done on Video, not Live. Show me the code. I want to see this "OS independent" remotely exploit any Wireless card in Promiscuous AP mode.
I want to see this work on Linux, for that matter.
2. It requires your system to be setup to automatically associate with all non-password protected APs. This is not a default setting, either; and none of the Mac users I know run their systems on this setting.
People DO tend to run their systems on "Alert me to all unprotected wireless access points", but that's all.
I don't see why everyone is so willing to accept this vulnerability. Their talking about attacking Atheros drivers on Windows, Linux, and OS X, with at least three independent driver teams working on them, with the Linux one being opensource (Madwifi). Furthermore, I don't see how you would get the same three driver stacks to exhibit the same buffer overrun to root-level excutable code, particularly a locked down Linux.
It's not protecting anyone to hide this vulnerability. Releasing the information now would prove whether or not this is real, and would permit quick resolution to this problem, particularly for the MadWifi people.
Until there's more information, I don't believe it. Even if I did believe it, without any details there's no effective way for me to protect myself. If the attack requires associating with an AP, most systems are not vulnerable. If the attack simple requires scanning avaliable APs, then every system out there is vulnerable unless Wireless is entirely disabled. Either way, it's stupid not to release the details, and reeks of more "Mac's aren't safe! See! Buy Norton Antivirus for the Mac!".
1. Crossover Office, a cheap, pay for product runs both Office 2003 (including Outlook) and iTunes. Not to mention Shockwave, as well. 2. Isn't Shockwave media handled by the Flash plugin now?
As for you, here are the games I play on Linux: Neverwinter Nights, Doom3, World of Warcraft, Eve Online, Half Life 2/CS:Source, Guild Wars, and Second Life. Of course, there are many other games I can play, but these are the ones I'm currently playing.
While I don't have access to the entire Windows game library on Linux, there are enough blockbusters that I can play to allow me to be happy. I'd rather my $15 go to Transgaming than Microsoft, so I've been Windows free for over 2 years.
If you're upset because you can't release a binary-only fork of GPL software, than you're an asshole for wanting to steal LICENSED, COPYRIGHTED software. Oddly enough, it sounds like you don't want other people to steal your code, so why would steal theirs?
GPL code is not public domain. GPL code is not a gift for you to use a you see fit. The GPL is a license that intends to force anyone who uses it to share and share alike.
On the other hand, if you don't use GPL (or other F/OSS code) in your projects, then go ahead and deliver your binary. There's nothing stopping you from binary distribution on Linux, plenty of companies do it. Take a look at VMware, or Oracle, or Apple, or IBM.
Slashdot Mirror
I think what he was trying to say is that even with a 99% success rate, you'll get 100 failures in 1,000,000.
And, as you can read in his other post, even with a 99.99% success rate, you'll get 1 failure in 1,000,000.
This doesn't prove it safe.
Would you rather see the occasional headline:
40,000 volunteer vaccine test ends in failure; 76% fatality rate.
Take a at this. That's what happens when a "Phase I" or earlier trial goes bad.
They now know that this vaccine won't immediately cause death in most cases. Now, they can continue to test it.
What's so cool about another Windows Mobile device?
Why wouldn't I want the latest and greatest symbian device, instead? Why do I even care about Palm?
But this thread is about getting net energy out of biofuels.
This statement doesn't make sense.
I said it elsewhere in the thread.
Energy on earth comes from one of four sources. Period.
A) "Fresh" Solar
B) "Stored" Solar
C) Nuclear
D) Lunar (Tidal)
That's it. If you're using energy on this rock, you're using one of those 4 sources. Everything else is illusion.
As far as I'm concerned, BioFuel, like Hydrogen, is a portion of the fuel cycle that "stores" energy much better than electrochemical batteries. BioFuel, like Hydrogen, is a mobile form of power storage. Nothing else.
Tidal would be an obvious choice for desalination plants.
Bingo!
There are so many ways to use tidal energy for desalination that our company doesn't know which "branch" to take beyond the feasibility study stage. We're not a big company, more of small tech house, and our lab floor is littered with scale model prototypes for tidal desalinization. 10 years ago, none of these things made economic sense. Now, the developing Arab nations most in need of desalinization cannot afford to use their oil domestically (more $$ in selling it). They take their oil money and invest it into technologies like ours; and we'll sell it world wide.
Think outside the box.
We're working on solar desalinization using a passive lens system in order to irrigate crop fields. I imagine that we could grow biofuel crops, we're currently looking at citrus orchards.
Energy != Oil. Furthermore, Energy doesn't "come from" biofuel, either.
On this planet, energy is either a) stored solar, b) fresh solar, c) nuclear, or d) lunar (tidal). That's it. Everything else is a clever trick. Biofuel is about capturing solar energy; and that water you "feed" the biofuel has to come from somewhere.
Star Markets may be the only stores in the U.K., but in the U.S. the cub foods and Jewel/Osco chains both have deployed Pay By Touch. That's a fairly significant foot print, at least near Chicago.
Even though you've got the capitalization of the "giga" wrong, I'm interested in this 100 Mega-Gigabit Seconds per mile connection you speak of.
Will this enable me to transfer a set number of seconds based upon miles? I'm interested in your ideas, and would like to subscribe to your newsletter.
I told you so
75% of people on Slashdot all tout the party line, "Don't believe everything you read in the mainstream media." It doesn't matter whether the discussion involves Iraq, Microsoft, SCO, Linux, IBM, the U.S. government, or CmdrTaco. If it's on CNN, don't believe it.
Well, here I am, to tell you, be skeptical of regular Joes, as well.
In this discussion, the only people not agreeing with the article said things like, "it was a 3rd party card." The thing is, I don't understand why you would believe ANY of it without some kind of proof, or evidence.
A video is easy to doctor. A video without any techniques and methods is monumentally stupid. I could have made the video in question in about 10 minutes.
Anyways, this is a big "FUCK YOU" to all the naysayers out there who continually announce that the end of OS X's relative security is on the horizon. I'm not saying that OS X is without flaw, and I'm not even saying there won't be widespread virus outbreak (however unlikely). But for godsakes, at least demand a shred of evidence before you proclaim the end of an era.
You say you are using Xgl/compiz in a production environment?
Do you get visual artifacts/glitches? 'cause I can't deploy it until I get those sorted out.
I use Xgl/compiz on KDE. Perhaps that's the problem.
I'd love some advice on an artifact free configuration for Xgl.
Not to mention that he could try something like Autopackage, or even klik://
The solutions are out there; they usually involve some additional software, and a focus on producing distribution neutral packages, but that really isn't a big deal; it's a small consideration one should make at the start of the project, not something you try to bolt on at the end of the project.
It's always going to be a pain to go back and fix bugs/locate distribution-specific tendancies and fool around with specific package managers. But you don't have to anymore; you just have to develop differently.
If you must call WINE something to support an all-or-nothing attitude, call it a simulator. That's what it does - simulates Windows behavior so that programs written for Windows will work on another operating system.
Even saying it's a simulator goes WAY too far.
Wine = reimplementation of Win32. It's an "emulator" in the same way that Compaq's reverse engineered PC BIOS was an "emulator" for IBM's BIOS. It's a "simulator" the same way that an airplane "simulates" bird flight.
Functionally, architecturally, and in practice, Wine is no different than OpenGL, BASH, or X. That's the long and the short of it.
What does "native" code mean?
.NET count as emulated or native? What about MONO code?
.NET stuff)
.NET, or Java to a platform. It's an API; nothing more. Using the word "emulation" to describe is misleading at best, and is usually done by folks with an agenda. Applications running under wine are most certainly running natively. Think about it; what about ReactOS? It "natively" uses WIN32 code for everything; but it's WIN32 implementation is pulled directly from Wine.
What does "emulated" code mean?
Does Java count as emulated or native? Does
I'm going to look on wikipedia:
Native Code
Jump to: navigation, search
In Computer Science, native code is machine code. However, in the context of an interpreted language, native code is the platform dependent implementation of language features and libraries.
Hmmm... what's emulated code?
I'd argue that emulation means one of three things:
1. Just-in-time compilation. (Perl?)
2. Dynamic recompilation. (Psycho, Rosetta)
3. A synthetic, virtual machine environment. (Virtual PC, Qemu,
Now, what does Wine/Cedega do? How do they fit in here?
Wine/Cedega does not:
A) Perform Just-in-time compilation,
B) Perform Dynamic recompilation, or
C) Provide a VM environment.
What DOES Wine/Cedega do?
Provide the WIN32 API and DLL environment on Unix-y systems. That's all; it provides the guts and hooks to run WIN32 code natively on Linux/OS X/Unix/BSD.
Wine is an emulator in the "coarse" sense of the word, in the same way that an automobile is emulation of a horse and buggy. (Horseless carriage, anyone?). Wine is just a Unix version of the WIN32 API; it's no more an emulator than an OS X OpenAL implementation, or X-Windows on Windows. That it runs Windows binaries _natively_, with no recompilation necessary, is a testament to the developers; it does not mean that it "emulates" anything.
Porting Wine to a platform is no different than porting ReiserFS, OpenGL, OpenAL,
Take a look at the Transgaming developer blog.
They've currently implemented much of SM 2.0. Adapating to OpenGL 2.0 has allowed them to speed up development substantially, particularly with OpenGL 2.0 being well supported by ATI and Nvidia. SM 3.0 should be along some time after that; before GLSL there was a lot more going on in reinterpresting shaders, but the direction that OpenGL is going has really helped them out.
AFAIK, most games that pick between SM 2.0 and 3.0 don't experience significant visual degredation, it's generally just performance. Either way, Transgaming is definitely picking up speed; and given that DirectX 10 is Vista only I don't expect any kind of rapid adoption.
By the time SM 4.0 or whatever, and DirectX 10 are requirements, Transgaming will already be there.
There is no performance hit. It's a myth.
On my Linux box, I run World of Warcraft WIN32 using Cedega, and get native (or better than native) performance. Wine, and hence Cedega, a Wine fork, or NOT emulation. They are binary API compatiblity layers. They are an implementation of WIN32 for Linux.
It's a userspace app that runs WIN32 EXEs. That's all.
There's no emulation. It's wicked fast, and there's minimal overhead. The only "real" overhead is that you're paging code to run more types of binaries than are avaliable on Windows; XP only supports COM and EXE, while Linux (with a WINE-alike) support ELFs, A.OUTs, EXEs, and COMs. More APIs=more memory, and generally more paging.
There are some performance issues with particular titles, but this is not because of "emulation", and an architectural performance limitation. These issues are because of poor implementations of various DirectX/Direct 3D features, which Transgaming is constantly working on.
Furthermore, Cider, which is a rebadged Winelib, does much of the translation work before hand. There's no reason for Cider not to support the latest and greatest; in fact, Transgaming is positioning Cider as something you build into your project during development; when you compile, you can target either Windows or OS X, and Cider should handle all the work for you. Take a look at the Winelib documentation. I'll quote:
Compiling apps under Winelib should theoretically involve only makefile changes. In practice, you will encounter header problems, and the likes -- for these it is much better (and faster) to submit a patch, rather than document them. So for the remainder of the section, let's assume the Wine headers are good enough for the application in question.
So, why doesn't Valve, or Blizzard, or whoever, use Winelib to build games? Because Winelib has limited DirectX capabilities, and because it would require a fair amount of developer interaction with Codeweavers or Wine-dev mailing lists to get problems sorted out. Not to mention that Codeweaver's traditional focus has been on office applications, not gaming.
Enter Cider. Transgaming will offer, for a nominal fee, to deal with all those problems for you. Plus, Transgaming's already done much of the work regarding DirectX; they've currently implemented a substantial portion of SM 2.0, with 3.0 on the horizon. Direct Play, Direct Sound, Direct Input, yadda yadda, all work properly. Dollars to donuts Cider will utilize OpenAL, enabling EAX up to 5.0.
It's silly to think of Winelib, or Cider applications as "non-native". They use the WIN32 API, and they're probably not using QT/GTK2 widgets; but these are most definitely Linux/OS X applications. Heck, 99% of games use their own GUI setup anyways; it's not like your going to be look at MS widgets inside Doom 3.
It's just a different API. As the implementation improves, performance improves. Indeed, in certain regards the Wine (and Transgaming) people have actually surpassed Microsoft, and as such performance is better. For example, Linux's scheduler can perform vastly better than Microsoft's, and games load (and textures pop into place) quite a bit quicker. Comparing two similarly built systems (I have side-by-side desktops with my girlfriend), one on Windows, one on Linux, World of Warcraft loads textures faster, and experiences substantially less texture loading lag, on Linux. When I switch on Cedega's Windows Scheduler implementation, the behavior regresses to be similar to the Windows system.
There's no reason for WINE or Cider to be inferior to native Win32. There are plenty of issues in Win32 that can be "fixed", and run faster; and there are plenty of places that Linux's (and/or OS X) superior performance can be leveraged. It's not an "emulation" architectural issue, it's just a $$/Manpower engineering issue, and the gap has closed significantly. Working directly with developers while they are in the primary phases of development will enable high-quality, high-performance WIN32 applications on Linux/OS X.
I'm a moderate fan of Nintendo, I admire their business acumen, and I think the gamecube is a solid system.
But I most definitely think that the gamecube pad sucks. Horribly.
The buttons are all different sizes, for god sakes. And it does NOT fit in my hand. I like the Dual Shock controller, and I like the Xbox gamepad; but I hate the gamecube pad.
Honestly, I've had nothing but trouble with MS keyboards/mice.
They cannot be used in my office, since they don't last very long. We don't have similar problems with Kensington, or Logitech (by far the most reliable brand).
MS Wireless Keyboard/Mouse sets tend to last no more than 1-2 years before either the keyboard or mouse fails, which basically requires you to replace the set. I've never had a Logitech wireless set go bad, with the partial exception of one old, old wirless logitech (mechanical) mouse I have that tends to squeak a little bit when you right click.
As for use with any operating system, get real. Their hardware is the only type out there that doesn't "just work". It requires funky drivers that ignore certain outputs, and generally just sucks. One's listed here. I've never experienced a problem like that with a Logitech.
It's a couple extra dollars, but the Logitech stuff works better (vastly better), and lasts. Microsoft's crap breaks down (mechanically), or remains funky without software fixes. If you like, I'll send you a pile of broken, newish MS keyboards/mice.
I know I'm pulling up threads from the way past, but what I'm suggesting you seem to have missed.
I'm suggesting that you do L7 QoS on your own machine, and then handle that via one of the GUI utilities I've pointed you at.
It's not _quite_ as clear as doing it one application at a time, but if you think of it in terms of protocols it may actually make more sense.
Don't throttle Limewire.exe, throttle the Gnutella protocol. Don't throttle CuteFTP, throttle the FTP protocol. You don't need to do this global, as in on the network level. I just meant "globally" as in system wide.
It would seem to me that this would be more sophsticated, not less, than NetLimiter. Furthermore, you get a great deal more flexibilty, you could potentially set a maximum system wide bandwidth, with SSH on high priority, and FTP on low priority, with an FTP maximum usage of 90% of the main maximum usage. And you can do all this via GUI.
Things like that, things that wouldn't be possible in Netlimiter.
I guess we can agree to disagree; all I'm suggesting is that in certain instances the way that you are used to using Windows applications is fulfilled, by the most part, by a different sort of Linux solution, and as such no one really bothers to fill the remaining niche.
I cannot really think of any situation where you wouldn't be better off with L7 QoS and a nice Linux GUI than a simple inflexible hard bandwidth cap, but that's just me.
Your wish is my command!
Done and Done!
Apparently, Version 6.0 of Crossover Office intends to have significant support for Direct3D 9, and for gaming. They also intend to support Half Life 2 on OS X.
IIRC, there is one commercial fork. That's Cedega.
Crossover Office is Codeweaver's project, and the Codeweavers people are deeply tied into the WINE project. Many, many, many of the patches to Wine come from Codeweavers, and Codeweavers treats WINE as a trunk for development.
This doesn't mean that Wine has 100% of the codeweavers stuff at any given time; but it does all get back.
Transgaming already does translate DirectX and Direct3D to OpenGL with little overhead. If the rumors are true, they are currently working on Pixel Shaders 2.0 and up.
;-)
Cedega is a fork of Wine from back when Wine was BSD licensed. It's really cool; I play lots of Windows games on Linux with it.
Presumably Cider is a Winelib-style toolkit to generate OS X games from Windows games. I, for one, welcome our Cedega-lib powered OS X overlords
Here's the video
There's no way to prove whether or not the are telling the truth. It will require further disclosure. They claim that they can target by Mac address, and that your machine merely has to be scanning for open APs, not actively associated.
I smell something funny, but whatever.
1. It was done on Video, not Live. Show me the code. I want to see this "OS independent" remotely exploit any Wireless card in Promiscuous AP mode.
I want to see this work on Linux, for that matter.
2. It requires your system to be setup to automatically associate with all non-password protected APs. This is not a default setting, either; and none of the Mac users I know run their systems on this setting.
People DO tend to run their systems on "Alert me to all unprotected wireless access points", but that's all.
I don't see why everyone is so willing to accept this vulnerability. Their talking about attacking Atheros drivers on Windows, Linux, and OS X, with at least three independent driver teams working on them, with the Linux one being opensource (Madwifi). Furthermore, I don't see how you would get the same three driver stacks to exhibit the same buffer overrun to root-level excutable code, particularly a locked down Linux.
It's not protecting anyone to hide this vulnerability. Releasing the information now would prove whether or not this is real, and would permit quick resolution to this problem, particularly for the MadWifi people.
Until there's more information, I don't believe it. Even if I did believe it, without any details there's no effective way for me to protect myself. If the attack requires associating with an AP, most systems are not vulnerable. If the attack simple requires scanning avaliable APs, then every system out there is vulnerable unless Wireless is entirely disabled. Either way, it's stupid not to release the details, and reeks of more "Mac's aren't safe! See! Buy Norton Antivirus for the Mac!".
The article is dumb.
1. Crossover Office, a cheap, pay for product runs both Office 2003 (including Outlook) and iTunes. Not to mention Shockwave, as well.
2. Isn't Shockwave media handled by the Flash plugin now?
As for you, here are the games I play on Linux: Neverwinter Nights, Doom3, World of Warcraft, Eve Online, Half Life 2/CS:Source, Guild Wars, and Second Life. Of course, there are many other games I can play, but these are the ones I'm currently playing.
While I don't have access to the entire Windows game library on Linux, there are enough blockbusters that I can play to allow me to be happy. I'd rather my $15 go to Transgaming than Microsoft, so I've been Windows free for over 2 years.
Don't steal code, asshole.
If you're upset because you can't release a binary-only fork of GPL software, than you're an asshole for wanting to steal LICENSED, COPYRIGHTED software. Oddly enough, it sounds like you don't want other people to steal your code, so why would steal theirs?
GPL code is not public domain. GPL code is not a gift for you to use a you see fit. The GPL is a license that intends to force anyone who uses it to share and share alike.
On the other hand, if you don't use GPL (or other F/OSS code) in your projects, then go ahead and deliver your binary. There's nothing stopping you from binary distribution on Linux, plenty of companies do it. Take a look at VMware, or Oracle, or Apple, or IBM.