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?"
When is the right time for project members to fork when their chief maintainer does not respond anymore or pursues an adverse commercial agenda?
I think you may have your answer. If a couple people agree with you, why don't you draft an email to the project maintainer with your concerns and the signatures of the other people? If he doesn't answer or you're not satisfied with his answer, I think forking the project should definitely be on the table.
Maybe if there is a fork, it can be White Wine and the original can be Red Wine.
And then if they merge back together, it'll be a blush!
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?
you should probably look into using X-render, which is designed for this (check cairo for instance)
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.
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"
In my experience, wine makes it easier to fork
...is that people continue to purchase software for Windows and waste their time attempting to make it run perfectly in Linux with a Windows API reimplementation, pretendulator, or whatever you want to call it.
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.
As long as it is acceptable to ship a product for Windows without seeing a drop-off in sales, people will continue to develop for Windows instead of Linux. Do not buy Windows products if you want to see them in Linux.
Learn from the unions, buy software made for Linux native if you want more of it. Continue to support businesses who do not support you and see desktop support for your operating system dwindle.
Check out ioquake3.org for a great, free, First-Person Shooter engine!
Not necessarily commenting this particular case, just wondering in general...
Why is it that when someone is pondering on forking a project, quite often we see these questions asked? Is the OSS community so polite that we have to ask permission from peers to fork a project? Why not just fork it and see, if the project takes off? Or is it about insecurity? Are we just afraid of negative feedback from anti-forking people?
In the blog post the project lead is talking about working on better MS Office support. I would love that. Especially MS Office 2007 SP2.
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.
Comment removed based on user account deletion
If a popular FOSS project like Firefox can have a 10+ years bug on the core HTML rendering, why should we be picky on a 7+ years old on a less popular application? The bottom line is: none has (enough) interest in it.
Maybe Computers will never be as intelligent as Humans.
For sure they won't ever become so stupid. [VR-1988]
Fork, then announce it on Slashdot. Or is it obvious that this wouldn't be taken seriously? Hmm. Think hard about why you feel that way. Seeking affirmation from John Q. Geek for your fork is not how this has been done. Perhaps there is a reason.
I imagine that from the perspective of the Wine developer community what you've just done is set the drama fan to 11 and fire a giant shit cannon at it. You playing politics by leveraging whatever pressure you can gin up. That behavior, by itself, puts me on whatever side of the fence you're not.
Fork. If anyone notices and follows then good for you. Otherwise STFU.
'Adverse commercial agenda'... How much thought did you put into those weasel words before you hit submit?
Lurking at the bottom of the gravity well, getting old
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 post a comment about careful consideration before forking, but found the /. MOTD at the bottom of the page already did my work for me:
"Be sure to evaluate the bird-hand/bush ratio."
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
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.
There's no double talk here. Sounds like someone's just feeling a bit threatened by someone saying that the sun doesn't rise and set on Linux, and that the rest of the world couldn't give two shits which OS they use, as long as they can get done what they need to get done..
Please stand clear of the doors, por favor mantenganse alejado de las puertas
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).
# cat
Damn, my RAM is full of llamas.
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.
It is unforgivable.
If drastic changes needed to be be made you should go as far as creating a new product, so people stick to the old one that works while devs polish the new product.
When I saw how incomplete and different v. 2 is from v. 1.4 I could simply not believe it.
No podcasts? No support for music players? (if there is any it isn't working) and a complete redesign of the user interface (a complete no,no when it comes to user interface design).
Sorry, I am very grateful for what has been provided before, but it would be a disservice to say that the new version is anything but something to be ashamed about in the planning of the transition and the execution.
A text book case of how *not* to transition to a new version of a product.
IANAL but write like a drunk one.
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.
What the heck is it doing in Ubuntu?
IANAL but write like a drunk one.
So you're happy to have something like the Gnome session manager issues http://np237.livejournal.com/22014.html?thread=113662?
I don't know how the Windows GDI and DDB/DIB logic work in great detail, nor do I understand how it is implemented in Wine or works with DirectX. What I do know is that doing something this big is extremely difficult to get right. You need a decent migration strategy and someone who understands the architecture (both how it currently works and how it is intended to work).
I suspect that there are interesting DIBDDB and DIBEngineWineX11X11 and DIBEngineWineD3DOpenGL issues that make it more of a challenge.
I would fire somebody telling me that is their reason not to accept some piece of code.
Why? Because that is a subjective judgement, and in big programming projects one should be as objective as possible. Oh yes, and because it says nothing about any perceived issues, so the person being judged has no way to "correct" the "problem".
IANAL but write like a drunk one.
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/
WTF? Did you not check the *rest* of KDE in the same timeframe? KDE 4.X is not feature-complete when compared to 3.5, nor even half as stable. They did a ground-up rewrite with a new version of Qt, taking advantage of all sorts of eye-candy that Qt 4 provided. The rewrite of the GUI under the release-early-release-often motto is exactly what the entire KDE culture was undergoing through that time.
Sure, I use it. I provide many bug reports. I ensure I enable the debugging stuff to help with said bug reports. But I sure as heck don't anticipate it being at the same level as the 3.5 version.
Now, if you simply want to disagree with the release-early-release-often manifesto, that's fine, that's your prerogative. But let's at least call it for what it is. It's not just Amarok, it's the entire KDE 4 movement.
Now, if *no one* transitioned to the new version, then we'd be stuck. Without those users testing, we'd simply never get to the next version.
Provide your feedback, but please be civil about it. If you don't like the new version, by all means, stick with the old version. No one is stopping you. It's not like you paid for this.
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.
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
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.
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
This is honestly not intended as flamebait. Simply swap some of the variables as I did above, and we see some of the same dynamics, and similar upset, as we saw with Vista.
It seems the Amarok folks haven't taken the time to learn from Microsoft's expensive lessons, which is a genuine shame. Love them or hate them, Microsoft *does* give us all a lot, in terms of vicarious experiences and case studies for how, or how not, to undertake software development.
Let them spend the billions, fine. The punchline is that we too can learn from what they do.
Cheers,
"What in the name of Fats Waller is that?"
"A four-foot prune."
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.
If the project has a choke point where one lead developer doesn't have enough time to properly review all patches coming through and reply with meaningful feedback (which is an important part of any code review), then it needs more people working on this, not just one.
Surely a project as old as Wine would have more experienced developers capable of handling this?
You're absolutely right that Wine would benefit from more developers.
Would you like to help? See winehq.org/devel for info on how to get started.
Well, I was thinking to not to enter inside this discussion, but... just to be precise :
1) I asked *many*, but really *many* times to Alexandre, on mailing lists, on IRC and to many other people about what would be the "right" design for an engine, but *never* got an answer.
Well, to pe precise, I just got *one* people answering me kindly, and it was Dan Kegel, whom I thank very much for its support. I tried also to ask Huw both in irc AND by mail, but no answer at all, even not a simple "sorry, no time for that".
So, please, don't tell me that I didn't ask or I didn't want to follow the right way, that's plain wrong, and you'll see it if you loose some time reading *all* posts on wine-devel about.
2) My design started with Jesse's one, right, then tried to merge Huw's one, because somebody told me that Huw's was the "right accepptable" design.
After loosing some time on it, and "without any feedback" from Huw nor Alexandre, besides one laconic "I don't think a multi-author stuff is accepptable", and after loosing most of time to keep my ongoing driver in sync with wine, I had to give up with that solution and think about a new one.
The *only* people involved with former designs that spoke to me was Jesse Allen, and I appreciated that really. After the laconic comment above, I lost about one week splitting the engine by author's commits. That was a large work, because I rewrote most of the code, but, as that was the *only* comment got so far, I was hoping that doing so I could rise the hope to see the engine inside wine.
Keep in mind that also in previous works I DID KEEP the original copyrights inside code, even when there was just a code line from original author.
3) At the end, tired of having to loose 80% time to rebase the engine and 20% time to improve it, and after getting to the conclusion that Huw's approach wasn't the best one (also well explained in mailing lists), I decided to start over with a brand new design.
So, again, please don't tell me that I ignored the long, hard part of the job.
It I should say that all, your "long, hard part of the job" contained almost as many bugs as code lines.
So, please again, *before* look at code, *then* comment.
The only part I kept from original Huw's design is the line drawing functions, and also those hardly patched and corrected.
4) If you'd be honest, you'd have reported ALL the content of my "too much work" comments. Those were referred to "too much work in hopeless tasks", which was the true stuff.
I don't code for job, nor I want to do it. I code for fun, because I like Linux and I like wine.
I've made small contributions since many years. That said, I, and I guess I'm not alone, don't like to loose my time, even if it's for fun. If I make a patch which is rejected with a *good* reason, I can try to improve it and to repost it; if the patch gets rejected because "it's not right", "it's a pain to review", "it's too commented" (yep, I got also that one.....), I simply keep it on my tree and go on.
5) The DIB engine was an effort for a stuff I needed, and taken further because it seemed to me that many people were interested about. It's not a "wonder patch" (never said that, but, again, you should just read mailing lists...), it's not perfect, it's not complete.
But, it works. On most apps, and is passing all (well, all -1 because lack of time lately) tests of wine suite.
It makes some apps simply usable, point. It's not a code masterpiece, nor it wants to be.
it's fixing a long standing bug to some extent, and it will do it 100% given enough time.
It's an *unpaid* work of 1 people for some monthes. If I should value it's time on my current's job time, you'd be surprised by the amount.
6) I don't know much about Codeweavers, just that they offer good compatibility for many important apps, and I appreciate it... And I find it right that thay earn money on it. Opensource doesn't mean "for free", of course.
I don't even know if a DIB engine is embedded in crossover products, nor it's important to me.
NOR I hope about a fork of wine project. We've got enough forks on Linux/unix, sometimes that's good, most times it's a bad stuff, too many resources are lost on it.
Ciao Max
Hey Max,
I am totally a fan of your DIB engine work. It's been
wonderful watching you attack this difficult job.
I do hope you're able to see it through to the end!
- Dan