I've been the Ubuntu developer responsible for Wine's packages for almost a decade now.
Over the years I've encountered a lot of skepticism about Wine, with some people even wondering if we'd be better off without it existing. I've never been convinced.
I hear an incredible number of stories about people who wanted to use Ubuntu, but couldn't because of one Windows app. Increasingly, I hear the inverse -- people who are happily using Ubuntu now because Wine works well enough.
Data is hard to come by, but my best estimates put Wine's install base at something on the order of 10-25% of Ubuntu users. That means millions of users of my packages. Most are running games. Some use it for some sort of critical business function like a legacy app.
I've contracted with a good number of companies who use Wine for critical business purposes. Wine is quickly becoming the porting tool of choice for making Mac and Linux versions of Windows software -- often times the game will work without modification, and when it doesn't these days it is dramatically cheaper to improve Wine than to rewrite applications.
I do understand some of the skepticism though. A single bug can render an application completely unusable, so from a user's perspective it's very hard to tell whether Wine is 99% done or 5% done. But in the future, you won't even know you're using Wine -- it'll silently be powering your steam games.
>I've been the Ubuntu developer responsible for Wine's packages for almost a decade now.
Many thanks! +40 or so machines run LTSpice (and other apps) via WINE in my lab. A good portion of my students install and run Linux on their personal computers, then using WINE for Windows application support.
Thanks for your great effort. I've used Wine quite a bit, and have benefited so much from it that I bought CrossOver, just to support it.
I've been a fan on Wine since I tried it, but I think this article on OS/2 from Arstechnica argues very well, on a historical basis, for why Wine unfortunately won't be helping getting people to use Linux on a large scale.
"OS/2 ran Windows apps really well out of the box, so they could just write a Windows app and both platforms would be able to run that app. On the other hand, writing a native OS/2 application was a lot of work for Windows developers."
"The second lesson of OS/2—to not be too compatible out of the box with rival operating systems—is a lesson that today’s phone and tablet makers should take seriously. Blackberry once touted that you could easily run Android apps on its BB10 operating system, but that ended up not helping the company at all. Alternative phone operating system vendors should think very carefully before building in Android app compatibility, lest they suffer the same fate as OS/2."
I've heard this claim a lot. The reason I think it's hogwash is that, application compatibility being equal, people would actually prefer to run Linux over Windows. That absolutely wasn't the case with OS2 and Blackberry.
Linux is free. OS/2 was strictly more expensive than Windows, and required you to buy a copy of Windows to run the Windows apps.
Like it or not, Linux was effectively second to the party. We faced a chicken and egg problem, and had no first-mover advantage. We simply weren't strong enough to cajole users into defaulting with us because we could hold all their favorite apps hostage if they didn't. We had no apps, legacy or otherwise.
We tried to get people to want to migrate badly enough by excelling in other areas (like being free). But our biggest problem was that they couldn't come even when they wanted to: 80% never heard of us, 80% of those left had hardware issues, 80% of those who remained had an application with no native equivalent. 20% of 20% of 20% is 0.8%, which incidentally is the exact market share we had.
But we're solving those issues now. People are becoming more aware of the viability of the platform. Distributions with commercial backing and their hardware partners have been solving the hardware issues. But there's still that application barrier for migration. Wine is a huge part of the solution to that.
Exactly. OS/2 was compatible only in the sense that with a vastly more expensive computer you could run windows, dos and os/2 apps.
There were lots of DOS apps. A few windows apps. And no OS/2 apps.
Windows always had compatibility AND reasonable system demands. On a windows 3.0 supporting machine you could not run OS/2. On a windows 3.1 machine you could -badly- run OS/2, but not OS/2 2.0. And on a windows 95 supporting machine you could maybe run OS/2 2.1.
OS/2 is an example of why design by committee loses out to a technical person really controlling the development of an application. OS/2's code, I'm betting, is far more flexible than the windows code, and has support for all sorts of weird features that no-one but academics care about, and massively increase demands on hardware. They also constantly require rewrites to actually make use of these features.
OS/2's failure had nothing to do with application support. If anything that was one of OS/2's redeeming features.
I like to think that the first thing you should do to make something succeed is to make it possible for said thing to succeed. OS/2 did not make it possible for itself to succeed, because nobody could run it. Somebody should have stopped the software architects and forced them to change until that happened. Nobody did.
The academic community was really proud. They even pushed it into the huge IT environments, like banks. No-one ran OS/2 for fun, because that was a $5k proposition. Running a windows 95 was a $500 proposition, that also got you access to duke nukem 3d and loads of other games.
Vastly more expensive? I think it run well on a 386 with 8MB of RAM, and if you got rid of the Workplace Shell as the original MS OS/2 2.0 SDK betas from 1990 did, it would run well in 4MB.
If we're going to quote official hardware requirements, then I'd say that Windows 3.0, the version that imho is comparable to OS/2 2.0) ran on a 286 with 384 kb of ram. Windows 3.1 ran on a 286 with 1 megabyte of ram.
Both ran well enough to run wordperfect on a 286 with 1 meg of ram. OS/2 wouldn't even boot under 4 megabytes of ram, or with a 286 processor.
So yes, vastly more expensive hardware requirements is certainly a valid criticism. In 1992 nobody had 386 machines. Some even say IBM purposefully designed it like that, to sell more machines. But if they did indeed intend that, why not release the OS for free ?
In 1992? I think this was after for example the infamous AMD 386DX-40 was released. Granted there probably still were a lot of 286s out there back then of course, which is one of the reasons why I never suggested abandoning DOS/Win3.x immediately. Of course, as mentioned before this would cause some pain for application developers, but this would last only a few years, and even PX00307 mentioned "Porthole" (aka WLO).
Seems like Wine will actually be even more relevant if increasing Steambox support allows more people to ditch windows (I still have a windows gaming only box).
Thoughts on integration? Wine can run steam but I wonder how far this could be taken in having a clean dual installation of native and wine based.
I would really like it if Wine steam and Linux steam played better together. At the moment you have to log out of Linux steam, open Wine steam, and then launch a Windows game. It would be much more straightforward to just have the Linux steam be aware of the Wine install of the Windows game.
One solution is to just port all the old apps with Wine wrappers so that Windows steam isn't needed. Another solution is to just have both steams open together (Valve has promised multiple simultaneous login support in the near future, as it's a requirement of home streaming).
Another option would be to have full-on support for detecting Wine within Linux steam and offering to run your windows games using community-derived Wine settings (akin to playonlinux or winetricks). That would be kind of radical, but I don't think they'd be gutsy enough to go that route.
Yet another option would be to simply endorse porting with Wine and tell developers how easy it is and how much money they could make by porting the back catalog. Last time I asked Valve didn't want to endorse a particular porting technology, but perhaps they'd change their minds if one was good enough and it meant developers would be more willing to port games with it.
I wish wine could do a bit on the visual integration side - enabling themes makes it quite slow, maybe you could have a word with Mr Shuttleworth and get him to bundle and ubuntu wine theme, and fund the last bit of work to get themes rendering quickly.
Including a proper wine theme (and matching it to the system themes) is something that's been on my todo list for the greater part of 5 years now. Hah.
Trying (and failing) to get my own mp3s playing consistently on the radio in the mac appstore version of GTA SA, I had occasion to peek in the installed directory structure.
I was pretty surprised to see a familiar-looking wine style layout there.
I didn't really look into it, so I don't know what the exact situation is, but looks like the future might have already happened in that case.
Yes, this is what I meant. Cider does suck, because Cider is based on a proprietary fork of a 7 year old branch of the Wine code and couldn't keep pace with the open source version. There's a reason Transgaming abandoned Cedega as a consumer product, and it's been that free Wine has been vastly superior for a while.
Codeweavers has already moved into the porting space using their expertise around free Wine, and perhaps not surprisingly Transgaming has begun to pivot into completely different areas.
Over the years I've encountered a lot of skepticism about Wine, with some people even wondering if we'd be better off without it existing. I've never been convinced.
I hear an incredible number of stories about people who wanted to use Ubuntu, but couldn't because of one Windows app. Increasingly, I hear the inverse -- people who are happily using Ubuntu now because Wine works well enough.
Data is hard to come by, but my best estimates put Wine's install base at something on the order of 10-25% of Ubuntu users. That means millions of users of my packages. Most are running games. Some use it for some sort of critical business function like a legacy app.
I've contracted with a good number of companies who use Wine for critical business purposes. Wine is quickly becoming the porting tool of choice for making Mac and Linux versions of Windows software -- often times the game will work without modification, and when it doesn't these days it is dramatically cheaper to improve Wine than to rewrite applications.
I do understand some of the skepticism though. A single bug can render an application completely unusable, so from a user's perspective it's very hard to tell whether Wine is 99% done or 5% done. But in the future, you won't even know you're using Wine -- it'll silently be powering your steam games.