On Tue, 16 Nov 2004 15:13:43 -0800, Per Bjornsson wrote: > Well, it could well be part of a migration path: if there are some > legacy apps stuck on Windows for now, it could be useful to be able to > run those in a VM while the rest of the desktop is Linux. Hey, > apparently some companies use VMware to run crufty old versions of > Windows in a protected setting to keep crap legacy apps alive. What does that get you? Why is running Linux for email/web + Windows for the apps you use to get your work done better than running Windows for email/web/apps you use to get work done? If you run Windows in a VM you still have to maintain it, keep it up to date, free of viruses and make sure it can log onto the network so random-business-app can read your $HOME etc, so you're effectively maintaining two computers instead of one. > Of course it's not a long-term solution, it's a migration band-aid. Do > you think that Wine is the correct long-term solution in the situation > though? I'd say that one would hope for the long-term fix to be a sane > combination of native apps and web apps etc. Depends on the type of app. For retail apps like Photoshop yep of course I want to see native versions. There are advantages to doing this. Of course, native and free-speech software is even better. For random custom VB apps and the like yeah, I think Wine is the long term solution. It's really a matter of philosophy. What does making an app native (or a portable web app) get you? Well ... it makes it integrate better with the host environment, uses native file pickers and themes etc. Wine has some basic theming support, maybe one day it'll be complete, but still native apps will usually integrate better. It means you're less likely to hit tricky bottlenecks or hard to map features. Native libraries are wider used so more likely to be bug free. What else? A bit faster, I guess, though subjectively I can't tell the difference between Wine apps and GTK2 apps these days, except in a few pathological cases. Word still starts in a few seconds relative to ~30 for OpenOffice, so Wine doesn't mean slow. IE still starts and renders pages as fast as Firefox, to my eye. So there are advantages. Where the ratio of developers:users is really huge, like for retail software, it makes sense. You can get a leg-up in the marketplace by giving your app that extra polish implied by going native. But most software isn't sold on shop shelves. Are these advantages so great that they justify humanity collectively rewriting thousands of man-years of work to use the API du-jour? Is this a useful way for the human race to spend its time? Or should we simply continue to run legacy apps like we always did, and write new software to use newer/better/more free APIs, maybe migrating old apps slowly over time, as it makes sense to do so? Well, this position is definitely arguable, but I'd say the latter. I can't think of a single compelling reason why everybody should rewrite *all* their software. It just doesn't make economic nor social sense. We could be spending that time writing *better* software that actually moves society forward in some meaningful way, rather than simply changing CreateWindowEx() -> gtk_window_new() which for the effort expended achieves very little. > Why are you trying to convince Red Hat to pick up CodeWeavers' business > model? ;) Heh. I'd be happy for them to support free software as a Windows migration path. Even if they decide to compete with CodeWeavers (unlikely), I haven't noticed the presence of SuSE or IBM in the market hurting Red Hat any. Currently the RH "What do we do about Windows?" strategy seems to involve hand-waving, web apps and VMware. This isn't surprising, RH have always been a Linux company so they have little experience with large desktop migrations, entrenched users, unwilling 3rd party vendors etc. Novell are getting this experience now. I'd *love* for RH management to give their backing to the Wine project, but I suspect they'll first spend some years nicely asking vendors to rewrite their software as web apps, or nicely asking existing web app vendors to please not depend on ActiveX/IE specific DHTML/ASP etc. Unfortunately, some apps will probably never even be ported. Why? Sometimes it's because it's not economically viable, sometimes the source code has been lost (this is more common than you might think!), sometimes it's so heavily dependent upon Windows APIs a port would imply starting from scratch (see Open Workbench for an example), and sometimes it's simply been abandoned by its creators: the shelf-life of a game for instance before the developers stop caring about it is about 6-12 months. After that time is up they're unlikely to even patch it, let alone do ports. Oh yes, and some of it is made by Microsoft, see eg BizTalk or MS Project which have no native (free or non-free) equivalents. I'm sure lots of programs will become web apps or be ported to native APIs in future. But saying it *all* will just makes me realise how little experience our community has with large-scale desktop migrations. thanks -mike
