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?"
When? (Score:5, Insightful)
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.
Re:When? (Score:5, Insightful)
To be honest, Forking is only really possible once enough of the right people get mad enough with the project, and, by that time, it's probably about time to fork anyway.
Take Amarok, for example. That situation practically begs for a fork, but it hasn't happened yet (AFAIK) because people aren't motivated or organized enough to bother with maintaining a new version, so the project remains unforked.
If you can get enough people organized enough to start and maintain a separate version, especially of something as large and difficult as WINE, that's probably reason enough to go forward.
Re:When? (Score:5, Insightful)
Even then, maintaining momentum is of critical importance. When X.org forked from the XFree86 tree, a great deal happened very quickly. However, in the latter half of 2007, development stagnated, something that was mentioned on at least one mailing list (I can't find it now for some reason). IIRC, part of the reason was simply that not enough development time was being spent on it, because people had other things on their plates.
It made for some frustrating times for Fedora 9 users, as nVidia refused for a while to release a driver for beta version of X, and F9 was released in May 2008 without a proper release version of X.org, that project still being stuck at 1.4.99, with the 1.5.0 release not happening until September, by which time the Fedora 10 beta had already been released. F9's development plan had been built in part around the expected timing of the X.org 1.5 release expected in the very early months of 2008, and I'm sure that the failure to make that timing made for some interesting discussions inside of the Fedora camp.
I understand that the 1.5 release was an enormous undertaking as part of the attempt to get rid of cruft left over from so many years of legacy support, but it still illustrates the perils of dealing with a large, complex codebase, even with an enthusiastic community backing the fork, and even if it is the reference implementation.
(I should mention that I don't come from a coding background, but I've worked with enough programmers to understand the issues of code maintenance and enhancement. Even in a corporate environment with lots of money and people behind a project, schedules don't always stay put.)
Re: (Score:3, Interesting)
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)?
You don't move versions by reducing functionality. (Score:4, Insightful)
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.
Re:You don't move versions by reducing functionali (Score:5, Insightful)
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.
Re:When? (Score:5, Insightful)
The real advantage will be after feature parity with 1.4. Amarok 2.x is far superior 'under the hood'.
Do you know what I liked most in Amarok? The UI. A playlist, a file browser to drag stuff from, and a play button. That's it. I don't need a more complicated UI. I don't want one. Now there's a button for Wikipedia?
Do I have to go back to XMMS just because everyone's so fucking Web 2.0 now? In fact, the whole KDE4 thing looks like they want to deliberately lose every user who wants a simple, clean, responsive, effective UI. They overhyped the API changes so much, they forgot about the users. Why do you force me to use Fluxbox? I've already given up on Azureus, they did the same thing with Vuze.
Fun fact: even Vista still has the classic UI.
Re: (Score:3, Informative)
Re:When? (Score:5, Informative)
Re:When? (Score:4, Informative)
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Amarok 2 is still in development. Give it time. Report bugs. Submit code if you can.
If it is still in development.... (Score:4, Insightful)
What the heck is it doing in Ubuntu?
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: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:If it is still in development.... (Score:4, Insightful)
That question could be applied to a lot of things, and not just the whole KDE4 mess. Xfce 2.6 should never have made it into Jaunty, with no menu editor and vertical panels totally broken.
I use Linux because, with a bit of hacking and some command-line wizardry, I can turn it into a better OS for my purposes than anything else. But I don't recommend it to anyone less geeky than myself. There's simply no way it's going to be a suitable platform for the average user, as long as upgrades routinely lead to major regressions.
Re:When? (Score:4, Insightful)
I don't understand this. I'm not to into the community for either project (I use Linux more for servers), but apparently KDE has done the same thing. If it's "still in development", why is it Amarok 2.0? Why isn't it Amarok 2.0.BETA1 or something? A .0 release is supposed to be (mostly) feature complete and (largely) bug free. Obviously bugs will still exist and features will be added (software is released by humans), but the big bugs are supposed to be out, and the features are supposed to be mostly where the spec document said they'd be. This sounds more like a development version of the code, akin to the odd number kernel minor revision numbers.
Re:When? (Score:4, Interesting)
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
Re:When? (Score:4, Funny)
Well, that appears to be an old [kde.org] sin.
red and white wine? (Score:5, Funny)
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!
Re:red and white wine? (Score:5, Funny)
Re: (Score:3, Funny)
Not even if the Merlot is free as in beer?
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: (Score:3, Funny)
That Lambrusco stuff is brilliant pantie remover.
Re: (Score:3, Funny)
At first I read this and saw "paint" remover ... although with a few minutes cogitation, I think yours is probably more accurate.
Re:red and white wine? (Score:5, Funny)
Maybe if there is a fork, it can be White Wine and the original can be Red Wine.
Only a drunk man tries to eat wine with a fork then quibbles about the colour.
Re:red and white wine? (Score:4, Insightful)
Why would a drunk man try to eat wine with a fork? Shouldn't he be fairly good at drinking wine correctly?
Re:red and white wine? (Score:4, Funny)
Re:red and white wine? (Score:4, Funny)
He obviously overloaded the && operator for the Troll and Flamebait classes
Re: (Score:3, Funny)
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.
Re:The secret is to not care (Score:5, Interesting)
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.
Re: (Score:3, Funny)
3 ... 2 ... 1 .... for the M$ WINE Poisoning Conspiracy Theories.
Who killed WINE ? It was Steve Ballmer, in Seattle, with the poison ... or possibly with a chair.
Re:The secret is to not care (Score:4, Insightful)
Re: (Score:3, Insightful)
Seriously, Microsoft have got other things to do than worry about a tin-pot emulation project. .NET advances are good in themselves for the developers who use those technologies. Microsoft don't have to stop advancing the technology just because Mono needs to catch up. If they cared about Linux support, they'd release .NET for Linux, but the don't and neither do the vast majority of Windows developers.
Re: (Score:3)
Actually Mono serves as an excellent foil for Microsoft. If somebody points out that Java is write-once, run-anywhere (and it generally is), they can point to Mono and say "us too". Except of course it isn't. It's always behind and fails ha
Re: (Score:3, Interesting)
Re:The secret is to not care (Score:5, Interesting)
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
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?
Re: (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
"Not pretty" is not technical critique. (Score:5, Insightful)
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".
Re:Seems to be a separation issue (Score:5, Insightful)
In which case, why was the reason for rejection not given as the concrete and rectifiable "wrong coding style"?
As it stands, "not pretty" could refer to just about anything. When I read that post I assumed it was referring to algorithmic elegance, not coding style. And that's the problem: the critique is so vague as to be utterly worthless.
Re: (Score:3, Insightful)
Well operating on the assumption that Sun is not lying flat out (because why would he?), doesn't it seem that a comment like "You"re using C++ style comments and we'd prefer C style (or whatever style is preferred), can you change them?" would be more useful than "It's not pretty enough". Probably resulting in a corrected and resubmitted patch rather than a frustrated developer. I mean, that's a really specific and easy to fix problem. "Code style" is a bit more arbitrary, but assuming we're talking abou
Re:Seems to be a separation issue (Score:5, Funny)
Re: (Score:3, Interesting)
I have had quite a bit of code go into Wine. The entire BiDi support was done by me, as well as some other parts (I did a rewrite of wineboot, for example). It is very hard to claim I don't know how Wine works, or how to submit patches. I even used to appear in Wine's "who's who" page, and have an interview with me [winehq.org] for WWN.
Not only that, but Alexandre knows me. The last time we met (wineconf in Germany, a few years ago) we had a (good humor) conversation that went something along those lines. I mentioned
Re: (Score:3, Insightful)
"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."
"Short and to the point" would be understandable and probably preferable in almost all cases.
But I got the impression people where complaining the reasons given often where being "short and vague".
Re:The secret is to not care (Score:4, Interesting)
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
Re: (Score:3)
Problem is ego, the bigger they are, the harder....they don't listen!
If someone at the top management of this project were to get their heads out of their asses,
and realize that WINE is the only thing stopping many from switching from Windows to Linux,
they might make a serious mental note to include certain fixed as critical on their to do list!
WINE is the only thing that makes a windows app work on linux, so why not make it
as best as you can, because the higher the people coming over because WINE lest them
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?
Re: (Score:3, Insightful)
Wine has a GIT repository and if package managers take the patch on board it is in, they are willing to do, now the warning was raised: don't do that because then we would have "invalid" bugs in bugzilla (that are not in the official release). So currently, very strange, all related bugs are discussed on the dib engine bug page and unlike the rest of wine bugs they actually get fixed. Everybody seems to be very enthusiatic about Max' work. So the natural next move is to get a "beer" project which is more co
DIB engine (Score:3, Insightful)
you should probably look into using X-render, which is designed for this (check cairo for instance)
"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
Comment removed (Score:5, Interesting)
Re:"disgruntled core developer"? (Score:4, Insightful)
Yes, this is why Max did follow the rules in a slavish manner. His engine is optional and needs to get activated, so it won't break anything and could also be removed if it was found obsolete. The typical contribution troll is that in technical discussions you always find reasons to reject a patch. What you should never do is to move the goal post. If Wine had a professional maintainer he would communicate what he wants and set realistic goals. Look at the history: Max does it. Someone tells him that Huw was supposed to work on that. And of course it is never perfect, so in the situation of dictatorial silence the palatines make up their own explanaitions.
Re: (Score:3, Funny)
I flashed back to evolution arguments when I read that.
"Hey, here's an eye!"
"Well, okay. Here's a single photosensitive cell."
Re: (Score:3, Insightful)
Prime time TV in China beats both, bandwidth-wise.
But what do I care? My wine emulator is sold by a company named Microsoft - and they do a brilliant job running Windows software.
And with discussions like these, you wonder why Linux on Desktop isn't as popular as you'd want to?
No fork is gonna happen (Score:5, Informative)
Re:No fork is gonna happen (Score:4, Funny)
Let's fork slahdot!
Wine mouse bug kept unfixed (Score:5, Interesting)
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.
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.
Re: (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:Wine mouse bug kept unfixed (Score:5, Insightful)
And then a numbnut promptly crawls out of the woodwork to respond with "errr, but didn't you hear that DGA is obsolete because it allows apps to write directly to the framebuffer".
And mods happily mod it up to 5 Insightful, rather than 5 Funny (or -1 Reading Comprehension).
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: (Score:3, Insightful)
"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."
To use DGA? That's not an acceptable solution. Last time I've used DGA was in 2004, and it required the application (not just the X server) to run as root because it writes directly to the video hardware. If the app crashes, the video RAM is
Re: (Score:3, Informative)
Please read the fine bugreport comment thread [winehq.org].
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: (Score:3)
You see!
"So yes, it "passes all the tests", but that's only because there aren't enough tests."
Sounds like a joke. Apply these standards to the rest of Wine!
It is all about moving the goal post. I can't see why an *optional* dib engine would have to be perfect.
So we will see a wine-dib version which package managers will ship, a fork, and the community will rally about it to make it perfect and test it.
There are many fields where it is like that. "You're not ready" is a classical management problem. Whoever
What is more frustrating... (Score:5, Insightful)
...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.
Re:What is more frustrating... (Score:4, Insightful)
Yes, Java accomplishes that, and I use that solution sometimes. Qt is ok if you want to ship multiple binaries and installers. And of course a source distribution is great if you can do it. But having a native (in terms of no VM or interpreter) API available everywhere with no recompilation is also a useful tool.
I think the biggest problem with Wine is that Windows developers don't test in it. If you could get people thinking about Wine as a cheap way to achieve cross-platform compatibility, it would be much more useful.
Re:What is more frustrating... (Score:5, Interesting)
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.
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...
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: (Score:3, Interesting)
If that is the case, why then are they then so eagerly giving out a license to legally decompile their program?
That is a disingenuous or ignorant statement. Reverse engineering is not restricted to decompiling.
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: (Score:3, Informative)
Re: (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 sm
Re: (Score:3, Funny)
For my dad (an avoved computer illiterate, with no intention to learn more than the absolute bare minimum), KDE 4.0 is a sleek looking "new and better Windows" that doesn't pester him with crazy popups (no AV suit, and adblocker installed) while he does "his stuff" (read email).
Whether Linux is an alternative in the home user market depends on a few things. Most of all, on what they want to do. If their goal is reading email, using IM, browsing the net and doing essentially what a fair lot of the "older gen
Re: (Score:3, Insightful)
Most of the Windows software out there is not pre-packaged from major software houses but written by businesses in-house or a niche app that will never see a Linux version.
What should we tell them? "Switch to Linux - all you have to do is rewrite all your applications"? Why is it that Linux advocates repeatedly forget that the majority of Windows desktops are in the workplace and that interoperability with their business systems is essential if Linux is to make any inroads.
The barrier to entry is not Phot
Re:What is more frustrating... (Score:5, Insightful)
Odd. I got the distinct impression that the GP was advocating that people spend their own money on software that was written to run natively on their OS of choice. That's your basic free market capitalism in a nutshell.
And yet, from this you manage to infer that the GP supports forcible state seizure of all privately owned property?
You took the words right out of my mouth.
Re: (Score:3, Insightful)
In this world, I'd rather be a communist than a capitalist manager. Those commie leaders could run a country while wasting a lot less money than some of today's managers do while merely running a bank.
About forking (Score:5, Insightful)
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?
Re:About forking (Score:4, Funny)
Are we just afraid of negative feedback from anti-forking people?
Or maybe we are afraid of some knifing (backstabbing) by the pro-knife people?
Re:About forking (Score:4, Interesting)
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.
MS Office support (Score:4, Interesting)
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.
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.
Longstanding bugs means no interest (Score:3, Funny)
You're doing it wrong (Score:5, Insightful)
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?
Slashdot MOTD Says It Well IMHO... (Score:3, Insightful)
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
Microsoft sabotage? (Score:4, Informative)
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
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:Wow. What a load of crap. (Score:5, Insightful)
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
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: (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).
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.
In my experience (Score:5, Funny)
Re:In my experience (Score:5, Funny)
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: (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