Wine Project Frustration and Forking 470
Elektroschock writes "Wine attempts to implement the Windows API layer on Linux. There are some limitations and an important one is the missing DIB engine, bug 421. Chris Howe comprehends the dissatisfaction of core developers with the arbitrary project governance: 'Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches disappear down a hole because they're "not right." Someone document what "would be right," or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions.' The latest attempt of Massimo Del Fedel satisfied all requirements set previously for the long standing bug 421, and his optional engine seems to work fine by all Wine quality standards. He seems to be extraordinary stubborn and insusceptible to mobbing. Usually it is extremely frustrating for developers when the goalpost is constantly moved. When is the right time for project members to fork when their chief maintainer does not respond anymore or pursues an adverse commercial agenda?"
The secret is to not care (Score:5, Informative)
Just submit your patches and do any fix ups that they request.. if you submit too much, they won't review it at all.. so don't do that!
After that, if they don't want your code, it's their loss. The great thing about git hosted projects is that anyone can merge in your changes with ease. In the case of WINE, the best way to get your patches noticed is to say FIXES [APP NAME] in the subject line and actually address a real bug witnessed in a real program that people actually use.
Other than that, hey, welcome to the politics of open source development.
Sounds a like a storm in a teacup (Score:5, Informative)
Massimo Del Fedele seems to be working towards a solution [winehq.org]. Which of the devs is calling for this fork on the mailing list?
"disgruntled core developer"? (Score:5, Informative)
As someone who have been following the wine developer list for a couple of years now, I think this post is more likely to be written up by a disgruntled user rather than a disgruntled "core developer" :p
That said, to get a patch accepted in wine can be somewhat frustrating. Which is good on the one hand, as bad patches are unlikely to get in, but on the other hand it's also kind of detrimental for new developers to just have their patches dropped without a comment. Which happens from time to time. :p
No fork is gonna happen (Score:5, Informative)
Re:No fork is gonna happen (Score:2, Informative)
Slashdot sensationalizing something for cheap page hits? Say it ain't so.
Re:Wine mouse bug kept unfixed (Score:5, Informative)
Another long-standing issue is "Bug 6971: Mouse "escapes" window or is confined to an area in the full screen program [winehq.org]", which affects A LOT of games out there. The developers in charge insists that it could only be fixed by making changes in the code all the way down to X.org layers and perhaps even in the kernel mouse handling. However, this is demonstrably false, because: A) there is no such issue in Wine's fork Cedega; and B) some "outside" developers pointed out that there is a way to deal with this problem without asking for personal favors from X.org and the Linux kernel, namely, to use the DGA subsystem [winehq.org] to achieve the required mouse behavior. But that's not going to be accepted either, because someone somewhere decided that DGA was "deprecated" and never mind that the deprecation was ONLY concerning its graphic component. The bug was reported almost three years ago, and it's almost like it's kept "in" on purpose, so that Wine never works properly with many games, and so that users will always have a need for the proprietary Crossover Games product.
XInput 2 is coming to the next X Release, and the support for relative mouse movements means that this bug will be fixed "the right way" shortly thereafter. There are already Wine devs testing out the latest X alphas to make sure XInput2 does what we need.
Look deeper (Score:5, Informative)
While I can understand the frustration, and sympathise with Chris, this is only part of the story:
1. Massimo has been invited to the IRC to discuss the architecture with Alexandre, but hasn't;
2. Conversely, Alexandre hasn't commented on any of the DIB threads - but other people (such as Roderick Colenbrander) have made comments summarising what Alexandre has been saying on IRC;
3. One of the reasons that Alexandre doesn't like the design is that it is a mix of 3 architectural designs;
4. Massimo's engine does not currently pass all the Wine tests (a requirement to get in) -- but is getting there;
5. A recent report from Steve Edwards says that, yes the DIB engine is faster, but it has rendering glitches.
Massimo's work is great, but even if it had Alexandre's approval needs more work. It's like rewriting Firefox's CSS support to allow for CSS3, but regressing on the Acid2 tests and not rendering pages correctly.
Getting code into Wine is difficult. I know because some of my stuff took 5 attempts to get in. When it did get in, the code was a lot better for it.
Wine has a quality bar that is required for code to be committed. This especially goes for something that is at the core of the project (which in this case is the gdi32 code, but also applies to DirectX and other areas).
Is Wine perfect? No. but a fork here will not help.
Re:porting to WINE? (Score:5, Informative)
It exists. It's called libwine. It's among others how Picasa and Google Earth work on Linux.
Also, if Wine isn't very compatible with your app, you can pay CodeWeaver to make it compatible, they are very cheap. Given this, it's surprising that apps like for instance Photoshop aren't available for Linux already (Photoshop CS2 do work on Wine but only because Google paid CodeWeavers to make it compatible).
Re:Wine mouse bug kept unfixed (Score:3, Informative)
a way to deal with this problem without asking for personal favors from X.org and the Linux kernel, namely, to use the DGA subsystem [winehq.org] to achieve the required mouse behavior
DGA sucks. It's a painful kludge. When you use DGA, you are asking both X and the kernel to stand back and respect your right to draw whatever you like on the framebuffer. This is a hell of a lot harder than it sounds, and is just simply fail in modern setups.
Re:red and white wine? (Score:5, Informative)
And then if they merge back together, it'll be a blush!
Parent had me confused. I'm European and love to drink wine -- apparently 'blush' means rosee wine [wikipedia.org].
Re:When? (Score:5, Informative)
Re:MS Office support (Score:4, Informative)
Add a little Samba gui integration into Ubuntu (share folders and drives point and click) and I am ready to roll out Linux in my companies. Seriously. Myself I have been a Debian desktop user since Slink.
This is already in Ubuntu for folders. I haven't tried drives yet.
Re:red and white wine? (Score:2, Informative)
*Woosh!*
The comment is a reference to the movie Sideways. You have to imagine Paul Giamatti, frustrated, shouting, "Whatever happens, I'm not drinking any fucking Merlot!" Probably the best line from that movie.
Re:When? (Score:4, Informative)
Seems to be a separation issue (Score:5, Informative)
Reading the bug (yes; I know; but I'm the RTFA troll. I'm allowed to do that) it seems that the issue is that this would be better not in Wine core, but in a DLL. So it's not being accepted because it doesn't need to be. Did I misunderstand?
Microsoft sabotage? (Score:4, Informative)
Re:I love Linux and all, blah, blah, blah (Score:3, Informative)
Re:When? (Score:3, Informative)
Re:What is more frustrating... (Score:3, Informative)
I've been using Linux for 10 years now. During that time I've seen several small business that I've supported with purchases rise with Linux on the desktop and fall as the whims of Linux users move towards pretendulation of Windows software.
Small Businesses are almost the worst place to convert to Linux, because they largely depend on the millions of vertical/custom Windows applications out there. Most of these applications aren't actively developed and aren't portable anyway. (VB, etc.)
In fact, the only place worse that Small Business for Linux marketshare gains would be Home users. Poor hardware compatibility, still no software. And for your mom, it's just a slow, brown clone of Windows.
That is why I propose that Linux should focus on the small Computer Science Student market.
Re:What is more frustrating... (Score:4, Informative)
Most commercial software houses of any size are extremely loathe to release source for their products,
If that is the case, why then are they then so eagerly giving out a license to legally decompile their program?
Indeed, in the European Union, according to articles 5.3 and 6 of the European "copyright" directive of May 14th 1991 [europa.eu], it is allowable to reverse engineer a program in circumstances where this is necessary to achieve interoperability.
Right now, decompilation is a pretty rare occurrence due to lack of appropriate tools, but this is changing...
Re:porting to WINE? (Score:3, Informative)
Google Earth has been a natively cross-platform Qt application for a while now. If it sometimes looks like a Wine app, it's because they insist on using a static compiled-jn Qt with a stupid looking theme. I know it's a small thing, but Linux users (at least the ones with KDE) would instantly think much better of the application if it used the system's theme (and didn't load duplicate libraries).
Re:Seems to be a separation issue (Score:3, Informative)
I've submitted many patches to wine and Alex has always given me good feedback. Without a link to the parent's patches so we can judge for ourselves I would have to say that what Sun is saying is false.
There's a couple of reasons why patches get rejected:
- The code style doesn't match what's in the file
- No test cases are submitted with a function implementation
- The patche's test cases fail on windows
I am subscribed to the mailing list and often see people get frustrated that they have to do more work then just throw code over the fence.
In the case of Sun's patch it sounds like "not pretty" means he either did something like put in C++ style comments or didn't match the coding standard on the file he was editing. However, without giving us the link to his patch on the mailing list we have no way of telling.
Re:Virtual Boxes (Score:5, Informative)
I asume that with vm you mean a vm such as vmware/Xen running a full Windows XP/Vista install.
Then there are 3 Reasons:
1: Hardware acceleration of graphics - Might not be needed for all applications but any graphics heavy application will be slow in a vm due to lag of graphics hardware acceleration support.
2: Desktop integration - applications running in wine will open a normal window along the rest of my desktop applications. So you can cut/paste between them, and put them in a beside each other and so on. With a vm, the vm take over the entire screen.
3: I don't want to maintain windows with all that include of patches, setup and av software, just to run a single oddball application.
Think of wine as something that allow you to run the few applications you need, that don't have a linux version, not something that will turn linux into a windows bootloader.
Re:Wine mouse bug kept unfixed (Score:3, Informative)
Please read the fine bugreport comment thread [winehq.org].
Re:Wine mouse bug kept unfixed (Score:2, Informative)
It is true that the framebuffer part was deprecated, however DGA also includes a mouse handling extension. Please read the bug report comments [winehq.org].
Decompilation doesn't give you source code... (Score:3, Informative)
It's hard enough to translate source code from one language to another and end up with a maintainable code base, and there you have all comments, high level control structures, classes, and templates or macros intact. Decompilation, even if you reverse-engineer the low level control structures and detect unrolled loops and other optimizations, doesn't leave you with something that you can take forward long term... and I don't see that changing.
Re:If it is still in development.... (Score:5, Informative)
That's a good question, but not quite the right question. What the heck is it doing in _Debian_, which is the codebase for Ubuntu? Debian publishes a lot of fundamentally poor quality, badly merged and mutually incompatible versions of tools which one person or another finds of interest. If the product gets some interest, then people work with it and develop it into something more usable. But many of them are completely outmoded and dangerous to other component operations. (Apache 1.3, which is nominally installed in parallel with HTTPD 2, is a prime example of this.)
It's a fair way to do things, since it makes the tools available to developers and interested users. But the resulting tool quality is often poor or poorly integrated.
Re:Virtual Boxes (Score:3, Informative)
I don't know about other VMs, but FYI Sun's "VirtualBox" (which runs on Windows/Linux/etc - it's not a Solaris-only thing) has recently added accelerated OpenGL support via a driver installed in the VM that basically provides a tunnel through to the real hardware driver on the host OS. They've also added accelerated Direct3D support via code taken from WINE that translates DIRCET3D calls into OpenGL ones.
I highly recommend VirtualBox - much faster and better integrated into the host OS than VMWare, for sure. Very easy to setup and use.
http://www.virtualbox.org/ [virtualbox.org]
Re:The secret is to not care (Score:2, Informative)
Do you have any idea of the sheer volume of code that gets submitted to wine everyday? Of course rejections are going to be short and to the point.
Wine is a huge project and it is only natural that code should be perfect before it's allowed in.
BTW, if you submit your code to the developer list before you send it to the patch list you can usually get comments from a few people telling you what to fix.
Re:When? (Score:3, Informative)
Re:What is more frustrating... (Score:4, Informative)
the majority of Linux users aren't going to be interested in purchasing a product that doesn't abide by their political views by including source code or otherwise abiding by the GPL.
Bullshit.
Imagine the uptick in sales for Photoshop if Linux took it in. Sure, you'd have maybe, what, FIVE nerds yelling frantically into their monitors "Its teh not free softwarez" but then you'd get well, well over that in sales.
This stigma that the Linux community doesn't like anything that's not free has to go. We're all using nVidia drivers, and we all have those non-free blogs installed right next to our kernels. Let's get it on, people.
Re:If it is still in development.... (Score:5, Informative)
That's a good question, but not quite the right question. What the heck is it doing in _Debian_, which is the codebase for Ubuntu?
While Ubuntu usually draws from Debian Unstable, that isn't the case with Amarok. Debian Stable, Testing, and Unstable all have Amarok 1.4.10 * [debian.org]. The Experimental repository has 2.0.96. According to the Debian Wiki [debian.org], Experimental "contains packages and tools which are still being developed, and are still in the alpha testing stage. Users shouldn't be using packages from here, because they can be dangerous and harmful even for the most experienced people."
Re:You don't move versions by reducing functionali (Score:2, Informative)
The distros are stopping us. I gave up Kubuntu precisely because they were dropping KDE3.5. Then I began distro-hopping, which turned out to be a good thing because I found Arch Linux and the KDEMod repositories. It turned out fine for me, after a few months of trying out different distros, but I found myself unable to recommend a good linux distro to my friends anymore.
Suddenly all distros were dropping the good and stable 3.5 version for the 4.0 and 4.1 KDE versions which would only convince my friends to stick (or go back) to Windows. Yes, of course, the new versions needed users that could report bugs and test drive the new functionality, and I understand that was the reason why all distros started including it. But what about those who just wanted to keep using our systems like we did just 6 months before? Most distros just dropped KDE 3.5 without leaving much of a choice. Yes, there is gnome, but there are some people who can't stand it.
I realize most distros has some form of independent repo which allows you to install KDE-3.5, but those shouldn't have to exist at all. We should have had the choice all along.
Was it the fault of the KDE devs? I don't think so, it was the choice of the distro devs who decided users should be their alpha/beta testers without offering them a choice, other than using more advanced distros, or keep using the older versions.
No winelib in Picasa. Earth is native. Chill. (Score:5, Informative)
I'm one of the Picasa for Linux developers (though I work on Chrome for Linux now), and I was also the release manager for Wine 1.0.
Picasa for Linux does not use Winelib, it uses Wine. We run the exact Windows binary without recompilation. There is very little reason to use winelib when porting a Windows app to x86 Linux.
Earth for Linux is a native app, it does not use Wine at all.
And while we're on the subject of Wine: two big reasons Wine is still important are:
Now, on to Max's DIB engine: he's doing a great job, and I have faith that the Wine maintainer is also doing a great job at keeping Wine healthy. The bar for inclusion of a patch in Wine is very high, and that's a good thing. Many developers get frustrated by Alexandre's relative lack of feedback, but imagine yourself in Alexandre's shoes; he would get overwhelmed if he held everybody's hands. Max's DIB engine is a great prototype. If he can get it to the point where it passes all tests, doesn't cause performance regressions, and does yield large performance improvements for important apps, the core Wine devs *will* take it, clean it up (which might involve rewriting large parts of it), and integrate it -- once they get time/funding to do so. They want a good DIB engine very badly, but not badly enough to do a rush job or neglect their paying customers. Writing and/or integrating a DIB engine is a huge job. We owe Max and those who went before him (Jesse, Huw, ...) a lot for getting things
this far. There's lots left to do, and I hope Max keeps plugging
away, and that others join in.
I am really looking forward to seeing what happens.
Wow. What a load of crap. (Score:5, Informative)
I find this story spin deeply offensive and highly misleading.
Let's start at the bottom, because that's the one that offends me so mightily. My blog is pointed to, with a caption 'adverse commercial agenda'. In that self same blog post, I refer to the energy we put into the DIB engine - I paid Huw to work on the DIB engine for six months. In fact, CodeWeavers has had the highly unenviable job of doing the long, hard dirty jobs that no one else wants to do, because they're not fun. (Can you say "COM", boys and girls). CodeWeavers contributes all of its patches to Wine first, and if you look at the top contributors to the Wine project throughout its lifetime, you will find a stunning number of CodeWeavers people. I find it personally insulting to the many people at CodeWeavers that have worked so very hard on Wine, often for very little pay, to imply that we have an evil agenda. We don't. We do want to make a living. We do put our customers ahead of shills on mailing lists. We do sometimes focus on making CrossOver better for specific tasks, but at all times our core mission remains making Wine better.
The proposed 'wonder' patch is based upon solid work by Jesse Allen, along with some of the work we paid Huw to do. And, in fact, it does some nifty things, because the author went after the fun cool part of the task, and ignored the long, hard, nasty part of the task. Indeed, the author repeatedly refuses to consider Alexandre's requirements for doing it right. Max has not 'satisfied all requirements set'. In fact, if you read this post [winehq.org], you'll see that Max has no interest in implementing the DIB Engine in the fashion that Alexandre has requested - it's too much work.
Wine has come a long way in the past 8-10 years - anyone who has used Wine lately can tell you how amazing it is becoming. This is largely driven by the ever increasing standard that Alexandre is using - the bar for patches, particularly against stable and well tested code - is becoming very high. This is a Good Thing (TM).
And finally, up to the top, this phrase is troubling: 'the dissatisfaction of core developers with the arbitrary project governance'. Once a year, the core Wine developers get together at WineConf [winehq.org]. We often have a topic called 'Wine governance', where we have great fun lampooning Alexandre. (He certainly is terse, and can be incredibly maddening). But the overwhelming and unanimous consensus, year over year, is that he does a damn fine job and that the Wine project is lucky to have him.
Change that to be 'the dissatisfaction of a bunch of vocal people on the mailing list, who don't really understand the technical issues at hand, but think they're missing out on a cool shiny' and now you have an accurate statement.
Cheers,
Jeremy
This is probably the single reason that Adobe won (Score:3, Informative)
At the end of the day, the difference between Aldus and Adobe products and everything else on Windows, and Even Macs back then, was the handling of graphics. Windows and Macs needed to be fast enough to work on screen, and printing had to be good "enough".
For Aldus and Adobe, Printing had to be perfect and predictable even for non-composited printers. Everything about WMF, DIB, GDI, and BMP, and the engines that manipulated them (all other companies programs), failed for largely the same core reasons that they fail here. This was also true for Mac lightweight graphics, but they were less practically important.
There was a speed, technology, and practicality hill that had to be eventually overcome. That happened through Next, and ultimately got there slightly before OSX. Use your own imaging system, based on PDF (Postscript derivative). Have, input drivers for system graphics. But everything becomes and is PDF. Quartz is based on it, Quartz is in Java, it is in Flash, it is in Photoshop, Illustrator, PDF, After effects, OSX, InDesign, Printers, and if worse comes to worse, it can output a DIB on the fly, which can be printed and displayed by ANY non-ps device. In a predictable and fast manner.
I feel for wine, because DIB never fundamentally works, and fundamentally always has flaws. But that is what Windows 16 is based on.
It is a problem for windows, because it means the imaging system continues and always is fundamentally difficult to deal with. (Colors are fundamentally RGB rather than Independent of colorant, or specific to a given colorant, like say metallic ink).
But this is what remains good for Adobe. This is not an easy problem to scope and solve. It is not being provided for free to developers (except on OSX, a bit). And means that if you want to design for print, or film, and essentially any predictable media, it is easier to use Adobe products. And they get paid handsomely for that.
Re:Wine mouse bug kept unfixed (Score:4, Informative)
DGA requires root. X is currently going towards being able to run unprivileged. Believe it or not, the mouse cursor is, in fact, a graphical element, and DGA still talks to the DDX when negotiating its HW cursor access.
If you want DGA, use KMS. It's the same style of direct-to-kernel access, and now with new features that DGA doesn't have, like "doesn't lock up your box due to kernel not liking your face."
And I'm not some numbnut, I'm an X.org developer. Or is that not enough qualification? I'm sure I can dig up mailing list posts from more senior devs that will confirm my original statement; namely, "DGA sucks."
Re:Wine mouse bug kept unfixed (Score:4, Informative)
Please see the header for the X.org SI DGA protocol [freedesktop.org]. The parts that say "THIS IS THE OLD DGA API AND IS OBSOLETE. PLEASE DO NOT USE IT ANYMORE," I think, are really the best part.
DGA1, that header, is the one with mouse handling. DGA2 does not include it (check here [freedesktop.org] if you're in an untrusting mood.)
Re:Wow. What a load of crap. (Score:5, Informative)
One clarification: in my last paragraph, I implied that I was upset with people on the Wine mailing list. That was poorly written on my part; my anger is almost entirely directed at the original poster. Max has written some nifty code. Alexandre won't take it, for reasons that most folks are clear on. So folks are working to find ways to make that code available for folks to try. That's all good; it in fact makes good pressure for getting it done 'right', and makes it a great tool to test the usefulness of a DIB engine. So it's all good, and healthy, and for this to somehow be spun up the way it was really bugged me.
Cheers,
Jeremy
Re:No winelib in Picasa. Earth is native. Chill. (Score:2, Informative)
You're absolutely right that Wine would benefit from more developers.
Would you like to help? See winehq.org/devel [winehq.org] for info on how to get started.