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?"
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.
After that, if they don't want your code, it's their loss.
Wrong. The loss is just as much yours and the users'. If I was an evil M$ overlord, I would definitely attempt to mess up projects like wine, and the easiest way to do this is to find that key people on whom everything relies and try to influence those in the wrong direction. Seen from this viewpoint, it is easy to see the loss is not "theirs" at all. And even if this is not the case, the point is the same.
Yeah, I'd like to know too.
I've only been hearing positive stuff coming from the Amarok devs.
Is the parent mixing up dev's actually getting fed up or just people being unhappy with the new interface? Is the parent also aware that in Amarok 2.2 and 2.3 the interface will become largely like Amarok 1.4 (with at least the possibility to fully customise the interface)?
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
Do not buy Windows products if you want to see them in Linux.
/etc/network/interfaces or /etc/sysconfig/network-scripts?").
That's easy to say, but computers are a tool to be used as a means to an end, and that's how most people use them. If I'm a graphic professional, I'm not going to boycott Adobe just because Photoshop isn't available on Linux. There are some great OSS solutions out there, and there are thousands of programmers that bust their ass every day to write and improve them, but the fact of the matter is that all that effort doesn't matter when someone has a need, and there's not a Linux solution that meets that need but there is one for Windows. It doesn't help when the OSS community refuses to listen to them and attempts to tell them otherwise (i.e. "GIMP is just as good as Photoshop!"). Given that, really the best you can hope for is that the person will run their Windows software under WINE instead of just discarding Linux altogether and using Windows itself. Most people don't care about what operating system they use - they just want to get their work done.
Learn from the unions, buy software made for Linux native if you want more of it.
As long as the general viewpoint of the Linux community diametrically opposes that of the majority of commercial software vendors, you're not going to see any appreciable amount of native software for general sale. Most commercial software houses of any size are extremely loathe to release source for their products, and I'd bet that 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. Not to mention the support headaches the software houses would have owing to the huge number of widely disparate distros out there ("is that config file in
Don't get me wrong - I have several Linux boxes here at home, one hosted in a data center several states away, and I work exclusively on Linux machines at my job. It's not that I don't like Linux. It's just that there's going to have to be a lot more that happens in the Linux world for it to get traction on the desktop, and thus to become more attractive for vendors regarding native implementations. Hopefully the recent licensing changes in Qt will grease the rails a bit.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
The problem is that Alexandre Juliard, the project's dictator, often rejects patches with reasons that contain no useful feedback except the patronizing statement "you can do better", or "it's not right".
I've had a patch I wrote for moving the wineserver code to epoll rejects because "it was not pretty". Michael Mccormak then made two more attempts at a rewrite that were rejected for precisely the same reason. In the end (several months later), Alexandre wrote his own version. At the time people explained this behavior to me as "wineserver is something he is very sensitive about".
Several years later I wrote a patch to something to do with the Window reordering being ignored (with no error message) in some cases. It is a pretty unbelievable piece of Windows mislogic, so I wrote a test case to prove this is, indeed, the behavior on Windows. The test case was rejected because it was not pretty enough. When I asked for more specific feedback, Alexandre responded with "If I can think of better ways to do it, so can you".
A project with as many contributers as Wine should have room for more than one programming styles than one. I thought it was only me for a while, but if it made it to slashdot, obviously it's not.
Shachar
Its been coming for a long time though, that's why its no longer the official kde media player. The Amarok developers don't bother with KDE ui conventions like (ctrl+m, or mac os x style menubars)! Unfortunately nobody in KDE wanted to compete with amarok so kde4 users are stuck with dragon or reverting to amarok1.4
IranAir Flight 655 never forget!
People might not like you taking their code and you risk alienating valuable assets if you proceed rashly.
So it is not socially acceptable to just fork the code?
I can understand the aspect of upsetting people and alienating the community, but the whole concept of "people might not like taking their code" confuses me here. I have always assumed that when something has been released under open source license, that act in itself is some kind of agreement that the code can be forked at some stage.
Personally I have never forked anything, but I have released few pieces of code to public and I have always assumed that if someone likes my work and wants to take it and improve it or take it to some new direction, then by all means, just take the code and start a new project. Granted, I don't have a thriving community behind me, so there isn't this social aspect to consider.
It's interesting to see that there can be this whole social protocol around the open source software development world. For me this is interesting, because I have always assumed that programmers in general seem to swear on following the OS licence literally regardless on social impact.
I will not go this far, no. Certainly not for the whole project. Certain areas within the project are more likely to get this type of response, yes.
Also, according to Alexandre himself in one of the wineconf, the patches he's likely to drop without a word are not those that are entirely bad (those get rejected), but those that he cannot make his mind whether they are or are not bad.
The problem is that this gets frustrating. When I was a regular Wine hacker, this wasn't so bad. I would persist long enough and in the end something would go in (not always because I made the patch better, mind you). The epoll case was a turning point, as far as I'm concerned, because of several reasons:
So, in answer to your question, this attitude SOMETIMES holds the project back.
I love working on Wine, and what I'm describing here is by no means the main reason I'm no longer active, but it does take some of the fun out of it. As you know, if you're not working on a free software project for fun, why work on it?
I don't know whether to point it out, as I have no idea whether it is relevant or not, but Mike, today, is also not an active Wine hacker. He wouldn't answer my question regarding what happened, but I got the impression it was something personal (he was a CodeWeavers employee, but he also did lots of pro-bono work on Wine). Let me assure you that losing him is a far greater loss for Wine than losing me.
Just to be clear - I'm not the one calling for a fork. Also, I know Codeweavers (both the company and the people running it) and do not tend to buy into the commercial/free conflict conspiracy theory. Still, I do think that Wines leadership has an attitude problem that affects the project.
Shachar