Slashdot Mirror
Wine Project Frustration and Forking
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?"
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.
How we know is more important than what we know.
Massimo Del Fedele seems to be working towards a solution. Which of the devs is calling for this fork on the mailing list?
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
This is all exaggeration by the submitter. At worst, I'll be integrating the DIB engine at the packaging level rather than getting Wine pure from upstream. No one in the Wine project has threatened a fork, not even Chris Howe.
Another long-standing issue is "Bug 6971: Mouse "escapes" window or is confined to an area in the full screen program", 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 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.
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.
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).
Slashdot anagrams to "Sad Sloth"
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 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.
~ C.
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.
8 of 13 people found this answer helpful. Did you?
They redid the UI for Amarok 2 and made a complete fucking mess. This pretty much says it all.
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.
I was skeptical with new ui too, but you can easily have the old one in amarok2, just hide the left panel and enlarge the right one, then you'll get something 90% similar to amarok 1.4
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?
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
I was going to make some joke about how Microsoft is hiring stooges to sabotage Wine, then I realised how plausible it is sounding.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
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, 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...
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.
Please read the fine bugreport comment thread.
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.
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.
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 *. The Experimental repository has 2.0.96. According to the Debian Wiki, 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."
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.
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, 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. 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
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."
~ C.
Please see the header for the X.org SI DGA protocol. 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 if you're in an untrusting mood.)
~ C.
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