~~~~ The MD5 checksum of this sig is ~~~~
af7118a625c2526851cc963963ed6068
That's the MD5 of your sig, including the newline, but wouldn't it make more sense to not include it?
neil@t40-n ~ $ echo -n "~~~~ The MD5 checksum of this sig is ~~~~" | md5sum
cd2dde55e58ec2a74f8a06698b30152a -
neil@t40-n ~ $ echo "~~~~ The MD5 checksum of this sig is ~~~~" | md5sum
af7118a625c2526851cc963963ed6068 -
There was no copy of Windows acquired, period. Wine is a reimplementation of the Windows API for Linux and family. It doesn't run Windows it runs Windows programs.
That was true in the past, but Wine will show up as Win2k by default now (or very soon, there has been quite a bit of discussion about it lately). My copy of Wine (20050111, I don't really have a use for it, but I like to keep up on it) shows up as Win2k, and I didn't pick that myself. Having said that, you can choose any of the versions of Windows from 3.0 to 2k3.
The article doesn't say which next version exactly that we can expect these improvements in. When I think "next Linux kernel" I think the next point release in the current version (in this case, 2.6.13), but these sort of sweeping changes seem awfully ambitious for such a short period of time, thus we should expect these changes in 2.8.0? But what happened to 2.8.0 not coming any time soon?
Anybody know what they're talking about when they refer to "next Linux kernel"?
The stock OpenGL on my linux boxen via Mesa pretty much sucks. But when you use NVidia's drivers, framerates are incredibly fast, even on my aging Athlon 900.
That's because without the NVidia drivers, you don't have 3D acceleration for your video card. Without it, everything is done in software, not hardware, hence the huge slowdown. Mesa provides an OpenGL implementation, not drivers for your video card.
If you look at the source code, you'll notice that they're using the IE hack to make transparent pngs work properly... so apparently even Microsoft hates that bug!
...that if the two teams worked together, they might make something superior to what they made on their own.
I doubt it. To make a comparison, if you have two trains facing opposite directions and you stick them together, what happens? No, they don't end up getting twice as far, they end up hindering eachother's progress, and the final combined result is less than what they could have accomplished on their own. While they may seem to do similar things on a very superficial basis, they have very different goals and very different ways of getting there.
I can't say I've shared your experience, the only dodgy part was getting DVDs to play while I was still using Mandrake, the (well known) trick is to install libdvdread and decss, after that it works perfectly. I'm now using Gentoo, and multimedia is absolutely zero effort to get working. Portage has pulled in all of the codecs (win32 + others) for me automagically and I have yet to find a video I can't play, the same goes for DVDs.
That may just be some verbage that makes sense in the context of init, but not as much in the general sense of processes. Even after changing runlevels for example, init still has pid 1, so it's certainly not a complete restart of init. I also don't have any (init) zombies, so I can't test it out, but I don't think that changing runlevel with get rid of an init zombie.
Which ebuild did you use? I'm using wine-20050111-r1, and while yes there is no desktop or K menu item added for Wine, it certainly is there at the command prompt. Unless you took/usr/bin out of your $PATH for some reason, I'm not sure why it wouldn't be there. What does
That would only kill zombie processes that got inherited to the X server, not init. Just zapping the X server with ctrl-alt-backspace is also a quicker solution for restarting your X server. To the best of my knowledge, init cannot be killed or restarted other than by rebooting. Having said that however, most any graphical applications for example will get inherited to the X server at worst if it zombifies, which then can indeed be fixed by zapping the X server that it was running on. There are very few instances where a zombie process will end being owned by init.
Well Wine certainly is moving forward in leaps and bounds, I'm not aware of any specific speed gains, the focus is usually on completeness and compatibility first, but then again I've never had speed issues with Wine, quite the opposite if anything. The one example you cite (notepad) launches in under a second on my relatively modest laptop with Wine. I can tell you about the Windows programs that I've run without issue (speed or otherwise) in Wine before, programs including Diablo II, Xnews, WinPar, Winamp, and Minitab for varying reasons, but I guess you're not interested in hearing about that. What I can repeat is that I've never had speed issues with Wine, it's more an issue of compatibility than anything, if something works, it works pretty quickly.
Interestingly enough, Minitab works better in Wine than in QEmu/Win98 or QEmu/Win2k, in some specific situations (triggered by things I was required to do for assignments) Minitab would crash under QEmu, and I was unable to find a workaround, but trying the same thing in Minitab under Wine produces no crash, so in the end it wasn't an issue for me.
But the fact that you have failed to mention even a single program that you had issues with, or even tried for that matter suggests to me that you either 1) Haven't bothered to try Wine recently enough to remember why you were trying it at all, or 2) Haven't tried Wine at all. Saying that "everything" you tried with Wine ran "slower than a Pentium 75" on your 3.2 Ghz machine seems dubious at best. Even an actual emulator will run things considerably faster than that, and Wine is considerably faster than an emulator. Add together an inflammatory attitude, baseless (rarely heard) complaints and a total lack of willingness to back up said complaints and I'm not at all surprised to see you get modded down, you shouldn't be either.
You're probably right, but I think the blame lies in the fact that Wine is still alpha software. The roughly monthly "releases" are just a snapshot of CVS, I'm relatively sure they're not tested beyond that, certainly not with the rigor you would expect for a 1.0 release or even a beta release, because they're not really a release at all. The fact that Wine is a rapidly moving target also doesn't help matters.
As to Fedora packages, there are RH7.3 through FC3 packages here, as well as numerous other binary packages. I won't claim I've used them as I haven't, but they do appear to be there. With regards to Mandrake and Gentoo packages (which I have used), they have nearly all worked quite well (the exception being one which had some issues with regards to wineserver, but I don't think the blame there lies in the packaging). Considering that Wine is still alpha software, I think it works pretty well the majority of the time, that or I've been very lucky. If you're looking for something that isn't quite as alpha, you should probably look at Crossover Office.
Installshield is the other main suspect in terms of Windows installers, and it was also specifically targeted in the new/fixed support for Wine. The fact that Wine would actually run a lot of programs, but couldn't install them properly without sometimes cryptic workarounds was a huge thorn in its side, and getting the installer out of the way is a huge step forward. Despite your pessimism about Wine, (Codeweavers) has spent roughly the last 9 months specifically developing all of the necessary components to make installers work (COM/OLE/etc). Often times these things aren't used at all in the programs themselves, hence them working before -- if you could get them installed.
This isn't a random publicity stunt, this is a genuine effort to get every installer working properly, and they have the right ammunition to back it up. The point is to shake out any bugs that may be present in their implementation, and the end result is (hopefully) the majority of Windows installers to work in Wine.
You'd be amazed the difference in response you'd get if you were even somewhat polite rather than hostile or mocking, especially when you present no more solid evidence than "OMFG WINE SUX0RSSS!!111111".
I realize this is Slashdot, but perhaps consider something along the lines of "Last time I tried Wine with (program) it had some pretty serious issues in terms of speed, hardware was definitely not the issue either. Has anyone tried (program) since? I didn't spend much time fiddling with it because it isn't really a big deal to me, but it'd be cool if it worked. Do all applications suffer from such a speed hit in Wine, I've been told that they don't but haven't seen any evidence of such. Can anyone suggest an alternative to (program) if it isn't likely to work in Wine?" next time, if you really are looking for information.
Any distro that includes Wine on the CDs or in it's repository (which I'd imagine is at least 95% of them) already does this. Open up your package manager, search for Wine and install it. How is that more difficult than searching on Google for Wine, downloading an installer and running it?
I think the real problem here is that people are stuck in the mindset of "must go download an installer and install it manually" rather than "let the package manager do the work for me". The reason for this of course is that Windows has no package management, so most people are used to doing things the painful and manual way, which is "easy". Using a package manager to install and manage your packages is exponentially easier and less headache inducing than the mess of installers and uninstallers that you face on Windows. The day there is an equivalent to "emerge --sync; emerge -uD world" for Windows is the day it might be worth the hassle of messing with the absolutely braindead method of installing and uninstalling software in Windows.
While I'm not aware of any open source 3D accelerated drivers for NVidia cards, there are the DRI drivers for Radeon cards 9200/9250 and under which are very good. I'm using them on my Radeon Mobility 7500 card and after enabling S3TC, speeds are very impressive, probably about equal to that of the Windows drivers. S3TC isn't enabled by default because of potential IP issues, but even without it, the drivers are still quite fast.
There currently is an active project to get the DRI drivers working on the R300 series of Radeons (ie, the rest of them), but I'm not aware of anyone who has tried them, and I don't have the hardware necessary to try them myself. The page itself strongly suggests that these drivers are not finished or stable at the moment however, so try at your own risk.
Zombie processes aren't quite the same situation at all. First of all, they can be killed, you just need to kill the parent process of whatever process created the zombie (though if this ends up being init, you're stuck with them). Not only that, but zombie processes effectively only take up the amount of memory it takes to represent them in the process table. Unless you're still limited to 2^15-1 processes and you've got a program that very rapidly spawns zombies, there is very little issue. Even then, you can limit the number of processes that a user or group can hold, etc.
Really, the point here is that 99.9% of the time a kill or kill -9 pid will kill a process dead, as quickly as possible. Which clearly isn't the case for Windows.
If you're looking for more information about this, Wine Weekly News for last week has two writeups on the issue. Basically the last of some very ugly and gritty DCOM work and related items has been finished in Wine. Installers are notorious for using these sorts of features and hence have generally been hit or miss in the past. This is a big step forward for Wine, sometime in the near future the vast majority of installers should work properly (hence the challenge).
I doubt you're serious, but to those reading this, Wine is quite fast regardless of whether or not you consider it an emulator or not (it is not). It isn't subject to the same kind of performance hit that an emulator like QEmu/VMWare/VirtualPC faces because Wine does not emulate hardware. I can for example play Diablo II under Wine at roughly 90% native speed, some applications are faster than this, some aren't quite as fast. Here's a few benchmarks if you don't believe me.
There are plenty of people who play new games like World of Warcraft and Half Life 2 under Wine without speed issues, so I'm not sure exactly where your claims are coming from.
On the contrary, Microsoft stands to lose huge amounts of money if they can't leverage their stranglehold on the browser market anymore. All of the sudden they sell less copies of Windows because people don't need IE to use poorly designed web sites or web applications, internal corporate sites in particular are notorious for this. That's only the beginning too. As a result of that, we would start seeing holes in the entire Microsoft monopoly as their two strongest shackles (IE and Office) weaken. Good news for everyone but Microsoft of course.
There are still tens of millions of users (like myself) still using these older versions of Windows, who don't feel like
"upgrading" to XP, and who won't have an updated Internet Explorer browser.
I find it's easier to just say "changing" when it involves Microsoft products. Things are rarely as black and white as "upgrade" or "downgrade" for them.
Slashdot Mirror
XP is included in "any version of Windows from 3.0 to 2k3".
I was thinking about suggesting that, as it would be very cool, but very very unlikely.
neil@t40-n ~ $ echo -n "~~~~ The MD5 checksum of this sig is ~~~~" | md5sum
cd2dde55e58ec2a74f8a06698b30152a -
neil@t40-n ~ $ echo "~~~~ The MD5 checksum of this sig is ~~~~" | md5sum
af7118a625c2526851cc963963ed6068 -
There was no copy of Windows acquired, period. Wine is a reimplementation of the Windows API for Linux and family. It doesn't run Windows it runs Windows programs.
That was true in the past, but Wine will show up as Win2k by default now (or very soon, there has been quite a bit of discussion about it lately). My copy of Wine (20050111, I don't really have a use for it, but I like to keep up on it) shows up as Win2k, and I didn't pick that myself. Having said that, you can choose any of the versions of Windows from 3.0 to 2k3.
Anybody know what they're talking about when they refer to "next Linux kernel"?
That's because without the NVidia drivers, you don't have 3D acceleration for your video card. Without it, everything is done in software, not hardware, hence the huge slowdown. Mesa provides an OpenGL implementation, not drivers for your video card.
If you look at the source code, you'll notice that they're using the IE hack to make transparent pngs work properly... so apparently even Microsoft hates that bug!
I can't say I've shared your experience, the only dodgy part was getting DVDs to play while I was still using Mandrake, the (well known) trick is to install libdvdread and decss, after that it works perfectly. I'm now using Gentoo, and multimedia is absolutely zero effort to get working. Portage has pulled in all of the codecs (win32 + others) for me automagically and I have yet to find a video I can't play, the same goes for DVDs.
That may just be some verbage that makes sense in the context of init, but not as much in the general sense of processes. Even after changing runlevels for example, init still has pid 1, so it's certainly not a complete restart of init. I also don't have any (init) zombies, so I can't test it out, but I don't think that changing runlevel with get rid of an init zombie.
That would only kill zombie processes that got inherited to the X server, not init. Just zapping the X server with ctrl-alt-backspace is also a quicker solution for restarting your X server. To the best of my knowledge, init cannot be killed or restarted other than by rebooting. Having said that however, most any graphical applications for example will get inherited to the X server at worst if it zombifies, which then can indeed be fixed by zapping the X server that it was running on. There are very few instances where a zombie process will end being owned by init.
Interestingly enough, Minitab works better in Wine than in QEmu/Win98 or QEmu/Win2k, in some specific situations (triggered by things I was required to do for assignments) Minitab would crash under QEmu, and I was unable to find a workaround, but trying the same thing in Minitab under Wine produces no crash, so in the end it wasn't an issue for me.
But the fact that you have failed to mention even a single program that you had issues with, or even tried for that matter suggests to me that you either 1) Haven't bothered to try Wine recently enough to remember why you were trying it at all, or 2) Haven't tried Wine at all. Saying that "everything" you tried with Wine ran "slower than a Pentium 75" on your 3.2 Ghz machine seems dubious at best. Even an actual emulator will run things considerably faster than that, and Wine is considerably faster than an emulator. Add together an inflammatory attitude, baseless (rarely heard) complaints and a total lack of willingness to back up said complaints and I'm not at all surprised to see you get modded down, you shouldn't be either.
As to Fedora packages, there are RH7.3 through FC3 packages here, as well as numerous other binary packages. I won't claim I've used them as I haven't, but they do appear to be there. With regards to Mandrake and Gentoo packages (which I have used), they have nearly all worked quite well (the exception being one which had some issues with regards to wineserver, but I don't think the blame there lies in the packaging). Considering that Wine is still alpha software, I think it works pretty well the majority of the time, that or I've been very lucky. If you're looking for something that isn't quite as alpha, you should probably look at Crossover Office.
This isn't a random publicity stunt, this is a genuine effort to get every installer working properly, and they have the right ammunition to back it up. The point is to shake out any bugs that may be present in their implementation, and the end result is (hopefully) the majority of Windows installers to work in Wine.
I realize this is Slashdot, but perhaps consider something along the lines of "Last time I tried Wine with (program) it had some pretty serious issues in terms of speed, hardware was definitely not the issue either. Has anyone tried (program) since? I didn't spend much time fiddling with it because it isn't really a big deal to me, but it'd be cool if it worked. Do all applications suffer from such a speed hit in Wine, I've been told that they don't but haven't seen any evidence of such. Can anyone suggest an alternative to (program) if it isn't likely to work in Wine?" next time, if you really are looking for information.
I think the real problem here is that people are stuck in the mindset of "must go download an installer and install it manually" rather than "let the package manager do the work for me". The reason for this of course is that Windows has no package management, so most people are used to doing things the painful and manual way, which is "easy". Using a package manager to install and manage your packages is exponentially easier and less headache inducing than the mess of installers and uninstallers that you face on Windows. The day there is an equivalent to "emerge --sync; emerge -uD world" for Windows is the day it might be worth the hassle of messing with the absolutely braindead method of installing and uninstalling software in Windows.
While I'm not aware of any open source 3D accelerated drivers for NVidia cards, there are the DRI drivers for Radeon cards 9200/9250 and under which are very good. I'm using them on my Radeon Mobility 7500 card and after enabling S3TC, speeds are very impressive, probably about equal to that of the Windows drivers. S3TC isn't enabled by default because of potential IP issues, but even without it, the drivers are still quite fast.
There currently is an active project to get the DRI drivers working on the R300 series of Radeons (ie, the rest of them), but I'm not aware of anyone who has tried them, and I don't have the hardware necessary to try them myself. The page itself strongly suggests that these drivers are not finished or stable at the moment however, so try at your own risk.
Really, the point here is that 99.9% of the time a kill or kill -9 pid will kill a process dead, as quickly as possible. Which clearly isn't the case for Windows.
I'd be apt to agree...
If you're looking for more information about this, Wine Weekly News for last week has two writeups on the issue. Basically the last of some very ugly and gritty DCOM work and related items has been finished in Wine. Installers are notorious for using these sorts of features and hence have generally been hit or miss in the past. This is a big step forward for Wine, sometime in the near future the vast majority of installers should work properly (hence the challenge).
There are plenty of people who play new games like World of Warcraft and Half Life 2 under Wine without speed issues, so I'm not sure exactly where your claims are coming from.
On the contrary, Microsoft stands to lose huge amounts of money if they can't leverage their stranglehold on the browser market anymore. All of the sudden they sell less copies of Windows because people don't need IE to use poorly designed web sites or web applications, internal corporate sites in particular are notorious for this. That's only the beginning too. As a result of that, we would start seeing holes in the entire Microsoft monopoly as their two strongest shackles (IE and Office) weaken. Good news for everyone but Microsoft of course.
I find it's easier to just say "changing" when it involves Microsoft products. Things are rarely as black and white as "upgrade" or "downgrade" for them.