I hear your frustration. You'd like Wine to work really well, and you are impatient with the current rate of progress. But implementing Win16/win32/win64 is a shitwad of work, so no matter how fast we go, you'll probably always be impatient. And so will I.
The best way to look at the current experimental DIB engine implementation is as a prototype.
If apps work well enough with it, it'll be easier to commit the resources to do a production-quality one.
If patches are rejected, it means there's something wrong with them; good, persistant developers who listen to the feedback and submit small, incremental patches can get them accepted. It's true that it can be frustrating at times, but that's not unique to Wine; gcc and the linux kernel are also frustrating for new contributors. And don't even get me started about gibc:-)
http://www.englishbreakfastnetwork.org/krazy looks great, but a lot of its checks are for C++ specific issues, which Wine doesn't have because it's based on C.
Wine is well aware of the benefits of automated testing and code analysis. We do have an automated build and test system, see http://test.winehq.org/ and we're slowly working on getting all the tests green.
And we pay attention to Coverity's scans of our source tree.
(We also have a patchwatcher, but it's out of action right now because I'm lame.)
If you want to go help raise funds from governmens stuck on win32, please do! I tried to make a little pitch for this at the end of my CeBIT talk last week,
see http://kegel.com/cebit
But it's hard to get their attention. First, they aren't impressed unless it can run all their apps, and second, the ones that are really serious about getting away from Windows tend to focus on native applications anyway.
So: the grapes really aren't that sour. Dive in and help - and be patient and persistent.
OK, *you* write an implementation of win32.
Without Codeweavers pushing Wine forward as they have been tirelessly doing lo these many years, Wine wouldn't be anywhere near where it is today.
Also, to anyone who complains about Crossover being stale compared to Wine:
it's because Crossover is like a stable version of Wine. OF COURSE it's going
to lag behind a little bit. Wine 1.0 is lagging way behind Wine 1.1.16, too. Big surprise!
I suppose I'm just jealous that their pet project got EU funding and mine didn't:-)
(Incidentally, I'm in a club with the president of the Open Grid Forum, and every so often I kid him about the state of grid software. I'm also the kind of guy who likes cars with no power anything, programming in C, and vi. I am *such* a luddite. Hence my preference for simple systems like Hadoop.)
I am not a cloud expert, but:
Anything with "grid" in it makes me think "designed by committee" and "sucks"... and the fact that the effort described in TFA was funded by the EU doesn't make me feel any better about it.
Maybe it would make more sense to wait until something like Hadoop takes over the world, then just standardize existing practice.
(Apologies to my friends in the grid world.)
Codeweavers was behind a lot of the patches that got it to the point you describe.
And, importantly, they went further and managed to get gmail working. If they hadn't insisted on getting that working, they could have packaged it in two days.
You might not have noticed their contributions because most of the improvements went straight into the public winehq tree.
That said, the wine community in general did contribute a lot to this, too.
I've been burned too many times by good resumes and sweet talk to hire anyone without seeing what they can do on the whiteboard.
As I wrote in http://www.kegel.com/academy/getting-hired.html:
A surprisingly large fraction of applicants, even those with masters' degrees and PhDs in computer science, fail during interviews when asked to carry out basic programming tasks. For example, I've personally interviewed graduates who can't answer "Write a loop that counts from 1 to 10" or "What's the number after F in hexadecimal?" Less trivially, I've interviewed many candidates who can't use recursion to solve a real problem. These are basic skills; anyone who lacks them probably hasn't done much programming.
Speaking on behalf of software engineers who have to interview prospective new hires, I can safely say that we're tired of talking to candidates who can't program their way out of a paper bag.
My pet peeve these days is diploma mills. A certain big, well-regarded university I know of seems to churn out unqualified masters students. I talked with the dean of CS there once about it, and he just said "We're already requiring so many courses, we can't require any more". Perhaps they need to be pickier about who they admit, but I've heard it speculated that the CS masters program is a profit center; and being pickier would hurt their bottom line.
Another useful data point is whether the person in question successfully gets lots of code into well-run open source projects like Wine or the Linux kernel.
Handy tools to search for commits include
http://ohloh.net/http://marc.info/ and http://cia.vc/ . (And yes, despite being a wine advocate for years, I have fewer than 100 patches in. Lame!:-)
Not to steal Jeremy & Alexandre's thunder, but it seems important to address this question promptly:
The way I look at the crossover vs. wine distinction is: wine is 100% pure "do it right" source code,
and crossover is wine plus some code that doesn't meet that standard yet, but does make Office (and other supported apps) run well.
(See http://www.codeweavers.com/products/source/ for the hacks in question.)
So really Wine is where the action is for developers, and Crossover is what end users who need Office to run well should run.
The only reason Wine doesn't run Office well yet is that nobody's figured out how to do it right yet, and the temporary bandaids that do it wrong but work for now are in Crossover.
If you figure out a clean replacement for any of the crossover hacks, they'll gladly commit them into the Wine tree.
In other words, from what I can see, Codeweavers' heart and actions are 100% where they should be from a free software point of view. All apps
are permitted to run under Wine. None are reserved for CX.
Does that help?
(Disclaimer: I'm a big Codeweavers customer,
occasional Wine contributor, and release manager for wine 1.0.)
I wear two hats, so let me shamelessly plug both projects I'm on:
Wine is in its fourth glorious year of the Summer of Code already
( http://wiki.winehq.org/SummerOfCode/PreviousProjects )
and each year has been fantastic. See our ideas page is at
http://wiki.winehq.org/SummerOfCode
Wine is going to hit 1.0 this summer, it's an exciting time to be involved.
Zumastor (a project to add better snapshots and remote replication
to Linux) is overjoyed to be participating in Summer of Code
for the first time this year. See our ideas page at
http://zumastor.org/soc.html or our home page at http://zumastor.org/
I look forward to working with y'all.
Yes, the work done on IExplore for Picasa benefitted all
apps that use embedded browsers.
Wine's quality is far higher now than it was back
when Corel tried it with Word Perfect; it's reasonable
to expect a Wine app to run smoothly and without crashes
these days -- if, that is, the vendor is willing to
do a little QA and get a few Wine bugs fixed, like
Google was.
More companies should use Wine to port their apps
to Linux, at least to get a toe in the water.
If sales take off, they can dive in and do the native port.
It's kind of like a homegrown subset of ZFS, but it already has online remote replication, which is one of the key features of Netapp NAS boxes. (People are starting to add that to zfs; see also http://milek.blogspot.com/2007/03/zfs-online-repli cation.html )
I'm a huge wine fan. I spend several hours a day doing Wine QA/triage, have some code in Wine myself, and have helped release a commercial app using Wine. And although I initially cringed when I saw that announcement, I do think Mark's right, at least for now. Wine can't run most Adobe apps without fiddling (see http://wiki.winehq.org/AdobeApps ), nor can it run the latest iTunes. Yet. When it can, it'll be time for Mark to reevaluate. Hopefully that'll be before the next release of Ubuntu...
My Dad was the first guy in Seattle to use the 4004, and I grew up surrounded by little boxes with 4004's and the requisite funky power supplies. I recently found the programmer's manual, and it's looking down at me from my bookshelf. Ah, the memories...
... when I was working on the Mars Observer Project, a side project of the team was to transcribe old Lunar Orbiter slow scan TV tapes. We had a bunch of the old tapes, and were refurbishing one of the old tape players. This was back in 1989. I'm not sure what came of it. Perhaps the folks at Malin Space Science Systems (http://msss.com) would know.
Picasa's EULA doesn't allow redistribution, so technically it can't be added to any distro's repositories. However, look carefully at the download URL, http://dl.google.com/linux/deb/pool/non-free/p/pic asa/picasa_2.2.2820-5_i386.deb you can probably just add Google's repository to your sources list... try it out and let me know if that does the trick for you.
(Disclaimer: I set up that repository, and I don't really know what I'm doing yet, so it might have some issues yet.)
Try turning on logging, e.g.
WINEDEBUG=+foo picasa > log.txt 2>&1 Then after it freezes next time, check the log. Maybe there'll be a stack dump you can report back to google. Or email it to me, dank at kegel.com.
Wine is a great opportunity to make a mark on the world. Wine is already production quality -- I'm posting this using Windows Firefox on Wine -- but many apps are just a few APIs away from running. Join the Wine project now and help us light the world on fire:-)
Slashdot Mirror
I hear your frustration. You'd like Wine to work really well, and you are impatient with the current rate of progress. But implementing Win16/win32/win64 is a shitwad of work, so no matter how fast we go, you'll probably always be impatient. And so will I.
The best way to look at the current experimental DIB engine implementation is as a prototype. If apps work well enough with it, it'll be easier to commit the resources to do a production-quality one.
If patches are rejected, it means there's something wrong with them; good, persistant developers who listen to the feedback and submit small, incremental patches can get them accepted. It's true that it can be frustrating at times, but that's not unique to Wine; gcc and the linux kernel are also frustrating for new contributors. And don't even get me started about gibc :-)
http://www.englishbreakfastnetwork.org/krazy looks great, but a lot of its checks are for C++ specific issues, which Wine doesn't have because it's based on C. Wine is well aware of the benefits of automated testing and code analysis. We do have an automated build and test system, see http://test.winehq.org/ and we're slowly working on getting all the tests green. And we pay attention to Coverity's scans of our source tree. (We also have a patchwatcher, but it's out of action right now because I'm lame.)
If you want to go help raise funds from governmens stuck on win32, please do! I tried to make a little pitch for this at the end of my CeBIT talk last week, see http://kegel.com/cebit But it's hard to get their attention. First, they aren't impressed unless it can run all their apps, and second, the ones that are really serious about getting away from Windows tend to focus on native applications anyway.
So: the grapes really aren't that sour. Dive in and help - and be patient and persistent.
OK, *you* write an implementation of win32. Without Codeweavers pushing Wine forward as they have been tirelessly doing lo these many years, Wine wouldn't be anywhere near where it is today. Also, to anyone who complains about Crossover being stale compared to Wine: it's because Crossover is like a stable version of Wine. OF COURSE it's going to lag behind a little bit. Wine 1.0 is lagging way behind Wine 1.1.16, too. Big surprise!
I suppose I'm just jealous that their pet project got EU funding and mine didn't :-)
(Incidentally, I'm in a club with the president of the Open Grid Forum, and every so often I kid him about the state of grid software. I'm also the kind of guy who likes cars with no power anything, programming in C, and vi. I am *such* a luddite. Hence my preference for simple systems like Hadoop.)
I am not a cloud expert, but: Anything with "grid" in it makes me think "designed by committee" and "sucks"... and the fact that the effort described in TFA was funded by the EU doesn't make me feel any better about it. Maybe it would make more sense to wait until something like Hadoop takes over the world, then just standardize existing practice. (Apologies to my friends in the grid world.)
I've been keeping tabs on it since about 1999. See http://kegel.com/corporate_ethics.html
That said, the wine community in general did contribute a lot to this, too.
If anyone has some free cycles, please come help get the Linux port going. There's lots to do. See http://dev.chromium.org/
Dangit, I wish people would stop spreading the false meme that Google Earth has anything to do with Wine! It's native!
My pet peeve these days is diploma mills. A certain big, well-regarded university I know of seems to churn out unqualified masters students. I talked with the dean of CS there once about it, and he just said "We're already requiring so many courses, we can't require any more". Perhaps they need to be pickier about who they admit, but I've heard it speculated that the CS masters program is a profit center; and being pickier would hurt their bottom line.
Another useful data point is whether the person in question successfully gets lots of code into well-run open source projects like Wine or the Linux kernel. Handy tools to search for commits include http://ohloh.net/ http://marc.info/ and http://cia.vc/ . (And yes, despite being a wine advocate for years, I have fewer than 100 patches in. Lame! :-)
http://wiki.winehq.org/Chrome https is not yet supported, but page loading speed isn't bad.
Google's looking into this issue now, thanks to everybody who reported it.
The way I look at the crossover vs. wine distinction is: wine is 100% pure "do it right" source code, and crossover is wine plus some code that doesn't meet that standard yet, but does make Office (and other supported apps) run well. (See http://www.codeweavers.com/products/source/ for the hacks in question.)
So really Wine is where the action is for developers, and Crossover is what end users who need Office to run well should run. The only reason Wine doesn't run Office well yet is that nobody's figured out how to do it right yet, and the temporary bandaids that do it wrong but work for now are in Crossover. If you figure out a clean replacement for any of the crossover hacks, they'll gladly commit them into the Wine tree.
In other words, from what I can see, Codeweavers' heart and actions are 100% where they should be from a free software point of view. All apps are permitted to run under Wine. None are reserved for CX.
Does that help?
(Disclaimer: I'm a big Codeweavers customer, occasional Wine contributor, and release manager for wine 1.0.)
I wear two hats, so let me shamelessly plug both projects I'm on: Wine is in its fourth glorious year of the Summer of Code already ( http://wiki.winehq.org/SummerOfCode/PreviousProjects ) and each year has been fantastic. See our ideas page is at http://wiki.winehq.org/SummerOfCode Wine is going to hit 1.0 this summer, it's an exciting time to be involved. Zumastor (a project to add better snapshots and remote replication to Linux) is overjoyed to be participating in Summer of Code for the first time this year. See our ideas page at http://zumastor.org/soc.html or our home page at http://zumastor.org/ I look forward to working with y'all.
Yes, the work done on IExplore for Picasa benefitted all apps that use embedded browsers. Wine's quality is far higher now than it was back when Corel tried it with Word Perfect; it's reasonable to expect a Wine app to run smoothly and without crashes these days -- if, that is, the vendor is willing to do a little QA and get a few Wine bugs fixed, like Google was. More companies should use Wine to port their apps to Linux, at least to get a toe in the water. If sales take off, they can dive in and do the native port.
The guys who put on those slides were talking
about Google Desktop, but couldn't mention it by
name yet.
Don't forget Zumastor (http://code.google.com/p/zumastor/).
i cation.html )
It's kind of like a homegrown subset of ZFS, but
it already has online remote replication, which
is one of the key features of Netapp NAS boxes.
(People are starting to add that to zfs; see also
http://milek.blogspot.com/2007/03/zfs-online-repl
I'm a huge wine fan. I spend several hours a day
doing Wine QA/triage, have some code in Wine myself,
and have helped release a commercial app using Wine. And although
I initially cringed when I saw that announcement,
I do think Mark's right, at least for now.
Wine can't run most Adobe apps without
fiddling (see http://wiki.winehq.org/AdobeApps ),
nor can it run the latest iTunes. Yet.
When it can, it'll be time for Mark to reevaluate.
Hopefully that'll be before the next release of Ubuntu...
My Dad was the first guy in Seattle to use the 4004,
and I grew up surrounded by little boxes with 4004's
and the requisite funky power supplies. I recently
found the programmer's manual, and it's looking down
at me from my bookshelf. Ah, the memories...
... when I was working on the Mars Observer Project,
a side project of the team was to transcribe old
Lunar Orbiter slow scan TV tapes. We had a bunch
of the old tapes, and were refurbishing one of the
old tape players. This was back in 1989. I'm not
sure what came of it. Perhaps the folks at Malin Space Science Systems
(http://msss.com) would know.
Picasa's EULA doesn't allow redistribution, so technicallyc asa/picasa_2.2.2820-5_i386.deb
it can't be added to any distro's repositories. However,
look carefully at the download URL,
http://dl.google.com/linux/deb/pool/non-free/p/pi
you can probably just add Google's repository to your sources list...
try it out and let me know if that does the trick for you.
(Disclaimer: I set up that repository, and I don't really know what I'm
doing yet, so it might have some issues yet.)
Try turning on logging, e.g.
WINEDEBUG=+foo picasa > log.txt 2>&1
Then after it freezes next time, check the log.
Maybe there'll be a stack dump you can report back
to google. Or email it to me, dank at kegel.com.
The Wine project is looking for students!
:-)
http://wiki.winehq.org/SummerOfCode
Wine is a great opportunity to make a mark on the world.
Wine is already production quality -- I'm
posting this using Windows Firefox on Wine --
but many apps are just a few APIs away from running.
Join the Wine project now and help us light the world on fire
One more: gmail was an email client written by Ed Miller (GMAIL@SLACTWGM.bitnet) in 1988; see http://www.listserv.dfn.de/cgi-bin/wa?A2=ind8804&L =jnet-l&T=0&F=&S=&P=60
gmail had releases until at least 2001; see http://web.archive.org/web/20010515203826/http://g mail.linuxpower.org/
And there was an earlier gmail by Richard Wiggins, released in 1993, which was a gopher-based
event calendar with some email integration;
See http://groups.google.com/group/comp.infosystems.go pher/msg/b51069df9005af1b
See http://web.archive.org/web/19991008021142/http://g mail.linuxpower.org/
So the name was already in common use
and not trademark-protected well before
the plaintiff's service launched, I bet.