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!
The time is never, you pick the place. Stay thirsty, my friends.
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
I've wondered if the most useful application of WINE would not be necessarily its ability to sometimes sorta maybe run Windows apps on *nix systems as-is, but as a way for the developers of those Windows apps to more quickly and easily port them to other platforms (and thus an incentive for them to do so). Change everything about your program that doesn't already work with a given version of WINE so that it does, package the result with a copy of WINE (so that it won't be broken by later updates), and viola, you've got a Linux/OSX/whatever port of your software. Arguably inelegant, but in a lot of cases probably a lot more straightforward than porting from scratch.
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.
That was so not funny, I didn't consider laughing.
... if you write a piece of code for a project with a specific functionality that is requested and you finish it and the requested functionality for your piece of code has changed, then you have still written the code that was "asked" for.
..." and so on and then the projects evolve beyond the initial project goal... aka. "evolution".
:-) I'll gladly pay for wine (or the the possible fork) when it is supported to get rid of a virtual machine just to run that program.
If it is a problem with the fact that time changes, code changes, goals changes then fork the project, otherwise keep up the spirit and evolve with the project.
I don't think I've ever worked on a project where the end goal has been the same for anybody, small differences here and there and then the never ending "if we have this feataure, then we can do
I can't see what the problem is, yes the DBI's life in wine is a rather difficult thing, but the changes of the overall project be it open source or in the future a more commercially oriented organizational structure and environment, then it is still a piece of code in the project that is needed, from what I can understand. Commercial or not, then wine is a good thing and if the chief maintainer goes commercial, then a lot of developers would most likely abandon the project and move on to other tings or as you say fork the project.
Either way, I don't see the problem as being the maintainer, but rather an piece of evolutionary jump for the project. Wine has been very slow to gain momentum and for me the only program I use it for (or rather will) is VMWare Infrastructure Client, but not being a great hacker with the knowledge to hack wine, I'm waiting, more or less patiently
As it is now, I think it is way out in the future, open source or commercial, so either way the problem for me seems more like an evlutionary bump in the road than a time for a fork.
Is it early monday morning and I've missed the point or is it a minor problem?
Vegetarians eat Vegetables, Humanitarians frighten me...
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.
lol Call it Brandy or Skotch. Or something. Alchol always motivates someone out there. It would make for some intresting code. In all seriousness, a fork would is a two edged sword. It took 15 years for WINE to get where it is now. The fork would likley be slower in development even if it draws from the other code. OTOH it could be a good testing ground for better improvements for things that users might want like better DX support. While the core WINE project is working on that others could significantly improve it. I see alot of pros to a fork...but a good amount of cons too. It is worth a discussion tho :P
I too wonder who is calling for a fork. I've followed the mailing list but haven't seen anyone do that.The problem here however is that Massimo Del Fedele's DIB engine most likely won't get accepted into wine, as he have also said himself in an earlier post.
College-Pages.com - Online Colleges, Degrees, and Programs
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.
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
Do you remember Goneme? No? I thought so.
Would you like some Cheese with your Wine? ;)
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
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
and so's yer old man
Surely everyone here on slashdot know that Rosé is not simply a mix of red and white wines... Don't they...
Deleted
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 honestly read the title as "Wine Project Frustration and Sporking" and for a moment I thought developers finally stop being prejudice about their utensils.
~~ Behold the flying cow with a rail gun! ~~
Don't get me wrong, I love Linux more than my own mother, but Windows is where it's at baby.
I don't like Windows but it's great. You should try it. Really. Just bear in mind that I love Linux.
Honestly, Linux is great for the world, except there are just so many things it cannot do. Use Windows instead. Not that I am advocating Windows or anything, because Linux stuff is what I live for... except it's a million miles from being usable, even though it is very good. ...and so on.
God how I get sick of the slimy mess that keeps spewing out this double talk.
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.
Several projects are controlled by clinically narcissistic personalities and unfortunately there are few but the mentally unstable who want to run free software projects. We put up with them because they usually do ok but KDE, Gnome, Xorg, Ubuntu, GCC and others you get bizarre decisions that negatively effect a project sometimes to the point they get dumped from a distribution as Gnome was removed from Slackware.
I despise windows but I just need a system that works with the option of using advanced features if I choose to not defeaturing or blocking features. I can get that from Microsoft.
Hi,
Sorry to do this (I know the wine project has been around forever), but you know as well as I do, when the world of virtual machines is coming up so well & fast, why wine?
"You know you don't act like a scientist, you're more like a game show host." Dana Barret
1. Err... your not pretty enough, go home.
2. Err.. your voice is too winey, get loste.
3. Err.. your appetite is too much for me, you pay the bill.
4. Err.. Your moaning is too sickening, get TF outa here.
Liberty freedom are no1, not dicks in suits.
When it comes to a project like WINE, which is trying to re-implement another closed API, the most important thing is compatibility, period. If doing that means you have to duplicate some of the same crappy code, so be it.
The fact that senior members of the wine project, which is as old as the hills, are rejecting working code because it "is not done right", is both disappointing and frustrating. It seems they have forgotten one of the mantras of open source code - release early and release often. If someone has a working DIB engine, get it in there, so people can use it and report bugs on it! If some code-snob in the team thinks they can do a better job, fine, they are free to do so - but in the man time, leave the working "incorrect" copy in there, so people who actually USE the project can get more work done with it.
Bringing proprietary crud onto my desktop!
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.
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.
http://bugs.winehq.org/show_bug.cgi?id=10778
I hate having to cripple my system with mem=xxxx to make things run without crashing.
I meant Xfce 4.6, of course.
I'd never really used Amarok, sticking to things like SMPlayer. So I tried Amarok 2. That UI looks a lot better in one of the darker KDE4.2 desktop themes. I found it easy and intuitive to set up and use. Streaming works great, and there's a nice collection of channels to start with. I'm listening to one right now.
My Sun Virtualbox Windows VM lives in a resizable window just like any other window on my desktop, and I can cut and paste between it and my Linux apps, otherwise it would be fairly useless. I think I can set it to display apps in their own windows, but never felt like bothering. VMware Server worked the same way when I was running it.
Come to think of it, I rejected Xen when I was virtualization shopping because it doesn't do those things.
I also use Crossover Office to run Eudora. For that, having it run in its own window makes sense, just as well because it's always running.
I run Virtualbox/XP an hour or two a week.
I don't know about DIB but i know that i'm really missing USB support in wine.
When is the right time
To parody a commercial from the 80's for all the gray hairs out there....
"we will fork no wine, before it's time..."
Seven puppies were harmed during the making of this post.
Fork, then announce it on Slashdot. Or is it obvious that this wouldn't be taken seriously?
I'm not detecting much insight into game theory in your comment, unless you view forking as utility maximization. Call it "the merge is greater than the sum of its forks" position. Which, strangely, is often true, but not on principle.
The underlying position of the Whiner seems to be that a small change of behaviour on the part of the Wine overlord would provide the most benefit to everyone for the least additional effort.
You'd have to believe that there is an infinite supply of untapped development talent to put a value of $0 on the duplication of infrastructure that a fork implies, which I imagine in the case of Wine is more substantial than most projects.
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.
I approve of over the top language. I'm often guilty myself. However, after reading this thread, for a drama at 11 event, it was a bit of a snooze fest. Every second person was making a constructive comment. (Bear in mind in my use of the word "constructive" that on slashdot, posts are scored from 1 to 5 out of 10, to keep the bar accessible.)
'Adverse commercial agenda'... How much thought did you put into those weasel words before you hit submit?
Not nearly enough, I would say. Adverse to what? On the flip side, suspecting ulterior motives is the nearly universal human response to the inability to elicit direct communication.
Comments on this thread suggest that the Wine overlord prefers to conduct technical discussion on IRC. I'm of a certain age where IRC is viewed as the least tool for the job.
(Don't get me started on Twitter. The smallest unit of thought that causes me to lift hand to keyboard is the paragraph. The other day I was watching a presentation by Nouriel Roubini to the Perimeter Institute. He has become a consultant to power brokers. Poor man. His smallest unit of thought is now the PowerPoint slide. And he had so much potential.)
As benevolent dictator for life, should greatness be thrust upon me, I can't conceive of reading a serious patch submission that represents hundreds or thousands of hours of coding effort and not writing an email in return which at least details my concrete initial reaction: I'd be a lot happier if you did A, B, and C. I have some misgivings about X, Y, and Z which I don't have time to formally document, but (if I were possessed by aliens) I'd be willing to discuss in IRC.
I just think it's bad psychology not to give capable, hard working contributors a clear idea of where they stand. In my professional life, nothing undermines my psychological well being more than a vague finish line that constantly moves.
Just because you can say "sulk, fork, repeat" doesn't make it desirable game theoretic outcome.
http://en.wikipedia.org/wiki/Pareto_optimal
I'd be interested to get Adam Kahane's reaction to the "fork off" model of conflict resolution. (Wired did a feature article on this long ago.)
http://www.generonconsulting.com/publications/papers/pdfs/Mont%20Fleur.pdf
What kind of bird would he choose to represent the outcome where every disgruntled open source developer forks at the first sign of trouble?
Hmm, I never knew this: if you were lost at sea, the albatross was good eating.
Don't do a lot of on-line forums, do we? Most are a LOT worse than this.
Heck, Slashdot works almost as well as the Compuserve Forums did in 1990. A lot of us back then thought that the future was about improvement. Boy, were we in for a shock.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Here, I'll say it because I didn't see anyone else say it, so kinda like the emperor isn't wearing any clothes...
Is this REALLY an issue? For Real, if I want to run Windows apps, I launch a virtual box of the XP install.. Why bother with WINE. Besides, Wine IS NOT an Emulator, so why bother. I thought it would of been dead a while ago. If you can't find a license to run XP in a VBox, then DONT. Instead, Code the application you need for LINUX. I'm a nobody, but other people have got to be tired of hereing this "The Dark side is makeing me buy a license to run xxxx..." Then CODE "xxxx" for your own use! Or Pay someone! If it is REALLY good, turn it back into the community under the GPL and let everyone benifit.
Wine sucks, Vboxes are only slightly better, native code rules.
Nope, I don't code or contribute, but my code would be belonging to someone else, anyways. So only take these comments with whatever salt you may have.
--- Relax, that mass muderer is just trying to reduce our carbon footprint, one fetus at a time...
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.
Bummer, hopefully this post will shed some light on any problems that may exist.
What kind of humourless mod would give you Flamebait? That was funny.
you had me at #!
Another idiot that doesn't know anything about the subject he waffles on about.
Waste of bits.
Theo is fine. In my personal dealings with him I found him also extremely competent and polite, and stimulating company.
This myth "Theo is an a**hole" is just people repeating what they've heard - cargo cultism, that geeks seem prone to. 999,999 times in 1,000,000 it's someone who's never even exchanged an email with the guy.
To trace this myth back to proximate origins - The mailing list spat that erupted around the forking of NetBSD made other people look much sillier than Theo, but in any case it's ancient history and Theo has long ago proved that he's an outstanding developer and leader.
you had me at #!
Hi, can you contact me privately if you're interested in getting my plugins ported to 3.0 on IRIX (assuming it supports plugins)?
you had me at #!
And there's another neat thing I've been doing with WINE lately - run Win32 CLI tools transparently from Linux shell.
This is particularly handy for cross-building, as you can download Visual C++ Express Edition and get access to the x86, amd64, ia64 and I think even CLR toolchains. Eclipse makes a nice IDE for this, you can code, build and test for Win32 without Windows. (An all-free way to cross-build is of course MinGW.)
Any day I don't boot Windows is a good day!
you had me at #!
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 just note that VirtualBox has a "seamless" mode which makes (2) invalid. It still behaves differently than a native, e.g. when a windows app has focus I have a second panel. However I "can cut/paste between them, and put them in a beside each other and so on."
I don't know about that. I copy an image in Firefox native and I cannot paste it in PhotoFiltre under Wine on my daughter's Ubuntu box.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
What precisely holds this community of developers to this particular project manager? Did they interview and choose him? Does he have some sort of intellectual property he could take home if he were asked to leave? Or does he simply know more about the project than anyone else.
If most of the community really believes that he's holding the project back by claiming perfectly good code is "not pretty enough" and refusing to elaborate, why can't he be replaced? No need to fork the project if the problem is a personnel issue.
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 first I read this and saw "paint" remover ... although with a few minutes cogitation, I think yours is probably more accurate.
A few minutes?!? Dude, you need to get a girl-friend!
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
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.
I am actually quite happy that someone like CodeWeavers can work on an important Free Software project like wine, and is able to get funding to do so by having real customers!
And yes, wine is pretty amazing these days.
Keep up the good work!
99% of Windows users don't care about perfect, predictable printing. They don't care about RGB vs. CMYK. They are interested that when they put red text in a Word document that it comes out on the color printer in red. Anything more complicated than that is the graphic arts department's problem.
And they, probably, use Macs.
you're old. that's OK, because I'm old too.
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
It's not like you paid for this.
Exactly the kind of thinking that won't get FSF anywhere.
Testing, providing feedback, and otherwise contributing is great but if you don't set your aims high enough just because people don't pay for it dooms most of FSF to be substandard, marginally usable and relegated from the mainstream.
One thing we _must_ start doing more often is what Joel Spolsky refers to as hallway testing for usability (http://www.joelonsoftware.com/articles/fog0000000043.html).
Suddenly all distros were dropping the good and stable 3.5 version for the 4.0 and 4.1 KDE versions
You realize that nobody is forcing you to accept the software updates that move you away from 3.5, right?
You realize that you can still go download an older version of $distro and use KDE 3.5, right? Nobody is forcing you to upgrade to 2009.4 or 2009.10 (in the case of Kubuntu), that's your choice.
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."
They completely rewrite Amarok in QT4, with many other changes under the hood, and you expect the two point zero version to be equal to 1.4 (which had evolved not just from 1.0, but from the 0.x days)? Ridiculous.
Climate Progress - Hell and High Water
If only I had mod points today.
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.
Wine hasn't even implemented all the Win32 calls that existed before Linux. The simplest explanation is that duplicating the functionality of a complex and not fully documented OS that took years and many people to develop is difficult to do with part-time unpaid developers.
Way to ignore his point. He said the project needs more _lead_ developers, or at least developers who can accept submitted patches. Him helping Wine would accomplish none of that.
Wow, you're kind of mildly retarded aren't you?
Years ago, due to licensing issues...
It was even reported on slashdot: http://developers.slashdot.org/article.pl?sid=02/04/18/1812228
You can gather how well that fork went...
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
That seems a little unfair, as that post says that Max doesn't have time for the "trial and error" way of fixing patches, i.e. presenting them to Alexandre, resulting in little more feedback than "not good enough" (as corroborated in further detail by others in this discussion).
People seem willing to put in the work - paid or not - but I'm sure a little more support from the top to those who are trying to contribute would go a long way.
As one of the people involved in this particular discussion about the DIB engine (see Elektroschock's link "comprehends the dissatisfaction"; I'm the guy Massimo is quoting), I'd like to say that the comment "core developers with the arbitrary project governance" is grossly out of proportion. None of the people mentioned in this wine-devel post are "core developers", nor are we complaining about Alexandre Julliard's project leadership.
What is main the issue with Massimo's DIB engine is that AJ doesn't like the architecture. Chris was merely stating that there is no documented way for the architecture of the DIB engine to be developed.
In addition, Massimo does not maintain his patches in a git tree, which would make it easy for cherry-picking and testing. Instead, he chooses to update the patches on the bug #421 page.
As for forking the project, any *successful* fork would either have to have the level of dedication and manpower that AJ and the other core developers show (it can be argued that Cedega and ReactOS do not have this) or it would have to remain so close to Wine's source that it would just be "Wine with this patch I like" and end up leaching off the work of the Wine developers.
Of course, if someone wants to do that, there's nothing stopping you! Wine is opensource after all.
The original poster is essentially expressing frustration at the slow pace of Wine development. The direct antidote to that general problem is more wine developers.
For the specific case of the DIB engine, we need to free up quite a bit of e.g. Huw and/or Alexandre's time. I'm sure they'd love to work on this, but they have to eat. If you don't want to become a wine developer, perhaps you could raise the needed cash to get a DIB engine integrated. Jeremy White had Huw give it a shot with some support from Google. He had to stop after something like 10^5 $ because it wasn't an obvious win yet, and the end wasn't in sight.
Once Max has demonstrated code that has the needed performance, it'll be time to try to clean it up to Alexandre's standards. Since Max doesn't want to do that, and no developer is stepping up to the plate to try it (maybe somebody could convince Jesse?), it might be worth it for somebody to fund another push. If you aren't a developer, you could help by raising oh, say $50K to let Huw and Alexandre get started on this once it's time. It's not clear that would be enough to finish, but it would let them focus on it for a while.
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
You don't get it. 2.0 is a new product. Its new from the ground up. Its new in the sense that it is built for the future.
Also, 1.4 is the old one that works that you can stick to. Honestly, its as simple as that. 2.x could never become what it will become if they stuck with the 1.x codebase. Its a good thing. If you're uncomfortable with the state of 2.x, then stay with 1.4. Simple as that.
I find this story spin deeply offensive and highly misleading.
I saw this sentence, thought "this must be a kdawson story", scrolled up, and was proven right.
Welcome to slashdot!
The original poster is essentially expressing frustration at the slow pace of Wine development. The direct antidote to that general problem is more wine developers.
No he didn't. Read it again. He is also no specifically talking about the DIB engine.
There are two ways to solve a problem like this:
#1. More lead developers.
#2. Less developers.
I'd go for #1.
Or else, #2 will happen automatically.
I for one appreciate your effort on this thing. I've been watching the conversation on wine-devel since you started and it's unfortunate that there's been so many roadblocks. Best of luck in your future endeavors.
They are waiting for the right investor to pay them to implement it, then the code nazi will have his own "right" design to implement the engine.
Nonononono. 'WINE', not 'Whine'.
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