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.
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