7 ms·

Wine Staging

78 points by ivank 11y ago

jarnix 11y ago
The url of the link seems incorrect : https://news.ycombinator.com/from?site=wine-staging.com https://news.ycombinator.com/from?site=wine-staging.com
- viraptor 11y ago
  See https://news.ycombinator.com/item?id=10223645 https://news.ycombinator.com/item?id=10223645 (click the name, not the domain name)
  - jarnix 11y ago
    ok thank you for the answer and explanation :)
geuis 11y ago
Curious, why does the link show as green on HN?
- viraptor 11y ago
  See https://news.ycombinator.com/item?id=10223645 https://news.ycombinator.com/item?id=10223645 (first link submitted from that domain)
haddr 11y ago
Wine is hell of a project. Having all those windows programs running on linux/os x is really a huge achievement. I know that there is still a way to go, but I really admire this herculean effort put into this project.
- jpolitz 11y ago
  I'm always really impressed when things just work in Wine. I started using YNAB this year and sure enough, it worked in Wine _with Dropbox integration_. Pretty cool.
metasean 11y ago
For those who are wondering what exactly "a special wine version" is, it isn't some new version of the drink, it is "a free and open source compatibility layer software application that aims to allow applications designed for Microsoft Windows to run on Unix-like operating systems". "Wine" stands for "Wine Is Not an Emulator". https://en.wikipedia.org/wiki/Wine_%28software%29#Pipelight.2Fwine-compholio https://en.wikipedia.org/wiki/Wine_%28software%29#Pipelight....
dingdingdang 11y ago
I wonder what it would take to create/put-together a minimal window manager and stripped down version of Linux wired to run Windows software as its default mode or purpose. Would it rival ReactOS or is Wine simply too unstable to truly serve as a "whole" OS?
- frozenport 11y ago
  The hallmark Windows apps dont run in WINE: Office, VS, Photoshop. The only advantage of the distro would be for games.
  - voltagex_ 11y ago
    Help me submit bug reports for them then - first, which versions are you targetting?
  - voltagex_ 11y ago
    Visual Studio 2015 - https://appdb.winehq.org/objectManager.php?sClass=version&iId=32486 https://appdb.winehq.org/objectManager.php?sClass=version&iI..., needs more investigation Office 2013 - https://appdb.winehq.org/objectManager.php?sClass=version&iId=26323 https://appdb.winehq.org/objectManager.php?sClass=version&iI... - at least this has a backtrace in the bug report Photoshop - https://appdb.winehq.org/objectManager.php?sClass=version&iId=25607 https://appdb.winehq.org/objectManager.php?sClass=version&iI... - CS6 might work!
- bananaoomarang 11y ago
  This is something I have thought about before. Perhaps more useful would be a desktop shell/WM that automatically manages bottling, plugs into PlayOnLinux when it makes sense etc. Building a usability and automated layer over Wine could compete with RiskOS I think.
- bkeroack 11y ago
  Google "Lindows". A company tried to do exactly this circa 2001.
ianlevesque 11y ago
Interesting project, it's almost like they searched through the WineHQ bug tracker for unmerged fixes and made a huge branch with all of them. There are certainly a lot of fixes that never make it to mainline Wine. The handful I've been watching have gone nearly 5 years without any meaningful progress past the initial patch. Occasionally someone will comment that the issue still affects them. I'm not sure what the solution is, it's an unpaid project.
- ZenoArrow 11y ago
  > "There are certainly a lot of fixes that never make it to mainline Wine." Out of interest, why is that?
  - IshKebab 11y ago
    Lack of manpower. Improving, merging and testing a fix isn't zero-effort.
    - stuaxo 11y ago
      Alexandre Juliarde keeps a very high quality threshold for patches, which makes sense as it's such a complicated project. This can make the conversations quite interesting from the outside if you're into this sort of thing.
0x0 11y ago
Tracking fixes as .patch files in a git repository is.... an interesting way to go about things.
- roblabla 11y ago
  Not the first or only project to do this. Spigot, a fork of the CraftBukkit minecraft server, uses a similar approach [0]. It allows to easily collaborate with the upstream project (Just apply the feature's patch on current master). [0] : https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/browse https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/...
  - 0x0 11y ago
    Wouldn't it be better to just keep the changes in a branch in a fork off of the upstream master branch? I would think that git would do a better job at re-applying to newer releases (i.e. merging from upstream master) than what patch(1) can do?
    - btown 11y ago
      This makes me think that automatic rebasing and test running as a service would be an interesting product. Continuous integration of upstream changes into your possibly proprietary downstream fork (for features or ports), with Travis running each time.... You could avoid the problem of divergent forks!
      - voltagex_ 11y ago
        I think you could probably make Travis do this itself - the script would be a bit gnarly though.
      - viraptor 11y ago
        This is possibly the hardest version control problem I ever ran into. Especially in projects which have a large number of changes upstream (100+ commits daily), I've only seen bad and worse solutions. The bad one is trying to follow upstream on each commit, notifying you every time some patch either doesn't work or doesn't merge anymore so you have to fix it manually. This still doesn't stop the cases where the patch in itself works, but doesn't make sense in the project anymore (some code moved around, tests still pass, but the functionality is not reachable). You also need a fair bit of architecture to test each of your patches with on each upstream change. The worse solution is taking a few days off every time a bigger release is out and porting all patches. It saves on the continuous testing infrastructure, but takes unknown amount of time and you may discover some functionality simply cannot be migrated anymore. You're also likely to introduce many more bugs with rushed development. I've been through planning something like this on a number of projects before. It's a lot of effort and it should be avoided as much as possible. I think the product you describe could be actually a really good idea, but a lot of it would have to deal with as clever annotations as possible - what broke, when did it work the last time, who's responsible for porting, what functionality does it provide, is it critical/optional, etc.
rottyguy 11y ago
How does Wine, Mono, and Microsoft open source .Net play out?
- viraptor 11y ago
  http://wiki.winehq.org/Mono http://wiki.winehq.org/Mono "For Wine releases 1.5.3 and later, the Wine Mono package is recommended. For earlier versions, an official Windows release of Mono 2.10 is recommended. Wine 1.5.6 will install Wine Mono automatically as needed." "If you need to use Microsoft's implementation of the .NET framework, the Microsoft runtimes can partly run on Wine."
shmerl 11y ago
It's quite useful. I mostly use Wine staging instead of regular Wine. For instance support for PulseAudio is nice to have. Stock Wine still doesn't have it for some reason. And some other such things.
- leni536 11y ago
  Pulseaudio support is definitely nice. I use stock wine and it's the main reason I use alsa. The alsa sink of pulse and wine don't run well together for some reason.
tomphoolery 11y ago
What is the origin of "compholio"? I chuckled when I saw that for some reason.
- striking 11y ago
  It's a person's internet handle (http://www.compholio.com/ http://www.compholio.com/) who wrote custom patches for Wine that were popular before they were incorporated into the mainline project... and not a thinly veiled Beavis and Butthead reference.
kazinator 11y ago
> Please note that our Wine Staging repository does not contain the full Wine source, which would be very intransparent for our users and developers. Instead we're providing Wine Staging as a patchset which has to be applied on top of the corresponding upstream Wine version. Translation: we can't figure out how to use git, to actually make a transparent development stream that users can just pull: and check out to an arbitrary commit, etc. "Let's try this without the last three commits ... git checkout HEAD^^^ ... done".
resca79 11y ago
In the 90 ages, as linux user, I tried many times to use it, with not great result. But now with the virtualization I think that it lost its traction.
jd3 11y ago
This is awesome! building wine in pkgsrc is broken for me at the moment (clang problems), so having a working/up to date wine build on OS X is great!
- k8tte 11y ago
  brew install wine --devel or brew install wine --HEAD
  - jd3 11y ago
    a good point. I used to use homebrew but I've dedicated my time pkgsrc proselytization, so I don't have homebrew installed anymore. I have a fontforge patch that I need to submit upstream, and I think I just need to install a newer gcc to get the builds to pass with pkgsrc. In the mean time I haven't tried an i686 build, which in theory should work..
helb 11y ago
Gentoo users: there's an USE flag for that ;) [https://github.com/wine-compholio/wine-staging/wiki/Installation#-gentoo-portage https://github.com/wine-compholio/wine-staging/wiki/Installa...]

78 points by ivank 11y ago

The url of the link seems incorrect : https://news.ycombinator.com/from?site=wine-staging.com https://news.ycombinator.com/from?site=wine-staging.com

viraptor 11y ago
See https://news.ycombinator.com/item?id=10223645 https://news.ycombinator.com/item?id=10223645 (click the name, not the domain name)
- jarnix 11y ago
  ok thank you for the answer and explanation :)

geuis 11y ago

Curious, why does the link show as green on HN?

viraptor 11y ago
See https://news.ycombinator.com/item?id=10223645 https://news.ycombinator.com/item?id=10223645 (first link submitted from that domain)

haddr 11y ago

Wine is hell of a project. Having all those windows programs running on linux/os x is really a huge achievement. I know that there is still a way to go, but I really admire this herculean effort put into this project.

jpolitz 11y ago
I'm always really impressed when things just work in Wine. I started using YNAB this year and sure enough, it worked in Wine _with Dropbox integration_. Pretty cool.

metasean 11y ago

For those who are wondering what exactly "a special wine version" is, it isn't some new version of the drink, it is "a free and open source compatibility layer software application that aims to allow applications designed for Microsoft Windows to run on Unix-like operating systems". "Wine" stands for "Wine Is Not an Emulator". https://en.wikipedia.org/wiki/Wine_%28software%29#Pipelight.2Fwine-compholio https://en.wikipedia.org/wiki/Wine_%28software%29#Pipelight....

dingdingdang 11y ago

I wonder what it would take to create/put-together a minimal window manager and stripped down version of Linux wired to run Windows software as its default mode or purpose. Would it rival ReactOS or is Wine simply too unstable to truly serve as a "whole" OS?

frozenport 11y ago
The hallmark Windows apps dont run in WINE: Office, VS, Photoshop. The only advantage of the distro would be for games.
- voltagex_ 11y ago
  Help me submit bug reports for them then - first, which versions are you targetting?
- voltagex_ 11y ago
  Visual Studio 2015 - https://appdb.winehq.org/objectManager.php?sClass=version&iId=32486 https://appdb.winehq.org/objectManager.php?sClass=version&iI..., needs more investigation Office 2013 - https://appdb.winehq.org/objectManager.php?sClass=version&iId=26323 https://appdb.winehq.org/objectManager.php?sClass=version&iI... - at least this has a backtrace in the bug report Photoshop - https://appdb.winehq.org/objectManager.php?sClass=version&iId=25607 https://appdb.winehq.org/objectManager.php?sClass=version&iI... - CS6 might work!
bananaoomarang 11y ago
This is something I have thought about before. Perhaps more useful would be a desktop shell/WM that automatically manages bottling, plugs into PlayOnLinux when it makes sense etc. Building a usability and automated layer over Wine could compete with RiskOS I think.
bkeroack 11y ago
Google "Lindows". A company tried to do exactly this circa 2001.

ianlevesque 11y ago

Interesting project, it's almost like they searched through the WineHQ bug tracker for unmerged fixes and made a huge branch with all of them. There are certainly a lot of fixes that never make it to mainline Wine. The handful I've been watching have gone nearly 5 years without any meaningful progress past the initial patch. Occasionally someone will comment that the issue still affects them. I'm not sure what the solution is, it's an unpaid project.

ZenoArrow 11y ago
> "There are certainly a lot of fixes that never make it to mainline Wine." Out of interest, why is that?
- IshKebab 11y ago
  Lack of manpower. Improving, merging and testing a fix isn't zero-effort.
  - stuaxo 11y ago
    Alexandre Juliarde keeps a very high quality threshold for patches, which makes sense as it's such a complicated project. This can make the conversations quite interesting from the outside if you're into this sort of thing.

0x0 11y ago

Tracking fixes as .patch files in a git repository is.... an interesting way to go about things.

roblabla 11y ago
Not the first or only project to do this. Spigot, a fork of the CraftBukkit minecraft server, uses a similar approach [0]. It allows to easily collaborate with the upstream project (Just apply the feature's patch on current master). [0] : https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/browse https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/...
- 0x0 11y ago
  Wouldn't it be better to just keep the changes in a branch in a fork off of the upstream master branch? I would think that git would do a better job at re-applying to newer releases (i.e. merging from upstream master) than what patch(1) can do?
  - btown 11y ago
    This makes me think that automatic rebasing and test running as a service would be an interesting product. Continuous integration of upstream changes into your possibly proprietary downstream fork (for features or ports), with Travis running each time.... You could avoid the problem of divergent forks!
    - voltagex_ 11y ago
      I think you could probably make Travis do this itself - the script would be a bit gnarly though.
    - viraptor 11y ago
      This is possibly the hardest version control problem I ever ran into. Especially in projects which have a large number of changes upstream (100+ commits daily), I've only seen bad and worse solutions. The bad one is trying to follow upstream on each commit, notifying you every time some patch either doesn't work or doesn't merge anymore so you have to fix it manually. This still doesn't stop the cases where the patch in itself works, but doesn't make sense in the project anymore (some code moved around, tests still pass, but the functionality is not reachable). You also need a fair bit of architecture to test each of your patches with on each upstream change. The worse solution is taking a few days off every time a bigger release is out and porting all patches. It saves on the continuous testing infrastructure, but takes unknown amount of time and you may discover some functionality simply cannot be migrated anymore. You're also likely to introduce many more bugs with rushed development. I've been through planning something like this on a number of projects before. It's a lot of effort and it should be avoided as much as possible. I think the product you describe could be actually a really good idea, but a lot of it would have to deal with as clever annotations as possible - what broke, when did it work the last time, who's responsible for porting, what functionality does it provide, is it critical/optional, etc.

rottyguy 11y ago

How does Wine, Mono, and Microsoft open source .Net play out?

viraptor 11y ago
http://wiki.winehq.org/Mono http://wiki.winehq.org/Mono "For Wine releases 1.5.3 and later, the Wine Mono package is recommended. For earlier versions, an official Windows release of Mono 2.10 is recommended. Wine 1.5.6 will install Wine Mono automatically as needed." "If you need to use Microsoft's implementation of the .NET framework, the Microsoft runtimes can partly run on Wine."

shmerl 11y ago

It's quite useful. I mostly use Wine staging instead of regular Wine. For instance support for PulseAudio is nice to have. Stock Wine still doesn't have it for some reason. And some other such things.

leni536 11y ago
Pulseaudio support is definitely nice. I use stock wine and it's the main reason I use alsa. The alsa sink of pulse and wine don't run well together for some reason.

tomphoolery 11y ago

What is the origin of "compholio"? I chuckled when I saw that for some reason.

striking 11y ago
It's a person's internet handle (http://www.compholio.com/ http://www.compholio.com/) who wrote custom patches for Wine that were popular before they were incorporated into the mainline project... and not a thinly veiled Beavis and Butthead reference.

kazinator 11y ago

> Please note that our Wine Staging repository does not contain the full Wine source, which would be very intransparent for our users and developers. Instead we're providing Wine Staging as a patchset which has to be applied on top of the corresponding upstream Wine version. Translation: we can't figure out how to use git, to actually make a transparent development stream that users can just pull: and check out to an arbitrary commit, etc. "Let's try this without the last three commits ... git checkout HEAD^^^ ... done".

resca79 11y ago

In the 90 ages, as linux user, I tried many times to use it, with not great result. But now with the virtualization I think that it lost its traction.

jd3 11y ago

This is awesome! building wine in pkgsrc is broken for me at the moment (clang problems), so having a working/up to date wine build on OS X is great!

k8tte 11y ago
brew install wine --devel or brew install wine --HEAD
- jd3 11y ago
  a good point. I used to use homebrew but I've dedicated my time pkgsrc proselytization, so I don't have homebrew installed anymore. I have a fontforge patch that I need to submit upstream, and I think I just need to install a newer gcc to get the builds to pass with pkgsrc. In the mean time I haven't tried an i686 build, which in theory should work..

helb 11y ago

Gentoo users: there's an USE flag for that ;) [https://github.com/wine-compholio/wine-staging/wiki/Installation#-gentoo-portage https://github.com/wine-compholio/wine-staging/wiki/Installa...]