Hey
Thats not nice to write such things. (also the things in the previous mails). Sounds more as Microsoft than opensource. The argument that everybody has its own goals is one of the current biggest problems of the opensource community (as also readt in the editorial of the professional computer magazine C't (in german area)). This namly means also that there is no coordination. You should better make a step back and see the whole picture. There is whole issue at the opensource community and everybody should not just ask what the can do to improve their own environment. Its the goal to improve the whole environment. So just look over the horizon. What made the PC to that allround machine it is today? Sorry to tell You hat, meight be a shock for You: It weren't the developers or scientific users. It were the small business users who wanted to run their excel and word. So if anybody here wan'ts Linux to get success the Linux tools MUST take care about this users because this users will make the decision about the future of Linux. And they will not go out business just because the use of MS Office. They rater will forward support microsoft by using their desktops. Just THINK: If we can provide them a Linux desktop with their ms office. Will they not rater switch later completely to opensource? How will you show them the benefits of opensource when they just know their virus contaminated windows desktop and make the admins crazy.
Roland
----- Ursprüngliche Mail ---- Von: Kuba Ober kuba@mareimbrium.org An: Roland Kaeser roli8200@yahoo.de Gesendet: Dienstag, den 11. Juli 2006, 15:40:19 Uhr Betreff: Re: AW: 0.9.17 and other issues
It's their problem that they like to waste money on MS Office. I'd say good for them, let them bleed money. Maybe they'll go out of business. Out of the business gene pool -- so much the better for everyone. I wish them what they deserve.
Cheers, Kuba
I think the basic point is, everbody here is doing what he *can* do. _For free!_
Also, it seems somewhat unfortunate for you, that "your" apps refuse to work, granted. But most of the Applications I'm trying to run /do run/. And by the time (within the last 6 months) they started doing so *without* having to install MSI, DCOM nor Internet Explorer. That's pretty much a good piece of work done. (What's up with MDAC, all you folks here, huh? XD)
Also, I see most of the installers became able to run and install their software *without* having to use a native Windows installation to run the setup. What is Office2003 under WINE good for, if you will be still in the need for Windows to install it?
That, plus there are _enough_ open source tools, utilities and applications having the same purpose as many Windows applications, e.g. OpenOffice which pretty much gives everything needed to the *average* Word/Excel/Access/Powerpoint user. Many customers I know tend to use such products instead of buying expensive Microsoft licenses, which is actually one of the goals of using /open source/ and /Linux/, right?
Heck, I always disliked MS Word interface via Visual Basic. I tried to do some pretty advanced document-generation with it and it just too cumbersome to my liking. Doable, but it just felt bed. I tried recently to implement the same thing with OO Basic and it was actually easier, even with sometimes inadequate documentation. So even for a non-average user OO.org has benefits (did for me).
CHeers, Kuba
Roland Kaeser wrote:
<snip silly messages going back and forth about opensource>
The following is not specific for you, but something I hope can help others out that are in your situation:
There are a number of things you can do to make your bugs more likely to be fixed by volunteer developers: 1 File a bug! 2. Describe the bug accurately. If it is not completely obvious, describe what the program should be doing and what actually happens. 3. Only describe one bug per bugzilla entry, unless you think they are related. Doing otherwise will probably cause your second problem to be ignored. 4. Provide debug messages printed when reproducing the bug. 5. Use a standard Wine configuration. This includes not mixing native and builtin DCOM dlls and not using WineTools. In fact, try to use as many builtin DLLs as possible. 6. Try to reproduce the bug in a freely downloadable version of the application (for example, a demo or trial version) and provide a link in the bug. (Note that having to fill in a form with details to download a program puts me off trying to fix a bug, but others' opinions may be different.) 7. If you suspect the bug is in a certain component due an error message in a dialog box or on the console and you know which debug channel it corresponds to then attach a log of that debug channel to the bug. 8. Be repsonsive to developers asking for you to retest, try different dlls and create debug logs. You can be pro-active, but be careful to not be annoying. Deriding Wine or Wine developers is likely to be seen as annoying and your bug will be ignored. Testing the bug on each release of wine (or on a less regular basis) and reporting its status is welcomed and will show that you care about the bug being fixed and that you will be responsive if a developer investigates the bug further.
Hello
Thanks. These are good ideas. I hope I have done my best yet to support the developpers. I had already good feedbacks with patches to test against a wine version for fixing a certain problem. But also sometimes I don't have the time (other things keep me really busy) to make that wide testes. As far as I see that I can file a useful bug report with less than a half day I see to get the time to make more intense tests to get a good quality bug report. On other side, I also see bugs which are completely (or no fix replay) untouched since they where reported. See Bugs #3599 #3611 #3800. The other part is (and I think I'm not alone with this) that I can only maintain a limited apps at a time. There whould be much more apps to maintain (the ones I know from my daily business) but currently I don't have the resources to do this. So I hoped that I can start with a "most important list" and work on this list as maintainer until they are completely working with wine to go forward for new ones to get them working. But I noticed that I working still on the same count of apps. Maybe i'ts not important for all but here a small list of the apps which are regulary requested to be working on Linux (out of the box):
- Corel Draw 9-13 (much often, not just by myself) - MS Office XP / 2003 (specially Outlook and Access) (sorry) - MS Project (sorry again) - Photoshop / Illustrator / InDesign - Adobe Premiere (I know its nearly impossible) - Lotus Notes (6.5.x / 7.0) - DentalLab XP (a small erp solution for Dental Technicans) - The Nokia Sync Software for their mobiles - Serveral Tools to feed GPS navigation PDA's - Adobe Acrobat (Professional) (I don't know why) - NavBox Pro Plan (Aviatics Application) (private pilots) - PCMet (Meteo app for aviatices (private pilots)) - AustroControl (Meteo app for aviatices (private pilots)) - Pocket FMS (Navigation Software etc.)
I know there are a lot of others which I cannot rember yet. It whould need to take a small survey but I know there are others. I also know that for the most of the listed apps are good linux equivalents avialable. As I said before, its (my) goal to bring the people frist to a linux desktop. switching from the windows apps to their linux alternatives can be made later when theyself recognize that the native linux app is more powerful than their windows version.
Roland
----- Ursprüngliche Mail ---- Von: Robert Shearman rob@codeweavers.com An: Roland Kaeser roli8200@yahoo.de CC: wine-devel@winehq.org Gesendet: Dienstag, den 11. Juli 2006, 17:17:55 Uhr Betreff: Getting Help With Bugs (was: Re: AW: 0.9.17 and other issues)
Roland Kaeser wrote:
<snip silly messages going back and forth about opensource>
The following is not specific for you, but something I hope can help others out that are in your situation:
There are a number of things you can do to make your bugs more likely to be fixed by volunteer developers: 1 File a bug! 2. Describe the bug accurately. If it is not completely obvious, describe what the program should be doing and what actually happens. 3. Only describe one bug per bugzilla entry, unless you think they are related. Doing otherwise will probably cause your second problem to be ignored. 4. Provide debug messages printed when reproducing the bug. 5. Use a standard Wine configuration. This includes not mixing native and builtin DCOM dlls and not using WineTools. In fact, try to use as many builtin DLLs as possible. 6. Try to reproduce the bug in a freely downloadable version of the application (for example, a demo or trial version) and provide a link in the bug. (Note that having to fill in a form with details to download a program puts me off trying to fix a bug, but others' opinions may be different.) 7. If you suspect the bug is in a certain component due an error message in a dialog box or on the console and you know which debug channel it corresponds to then attach a log of that debug channel to the bug. 8. Be repsonsive to developers asking for you to retest, try different dlls and create debug logs. You can be pro-active, but be careful to not be annoying. Deriding Wine or Wine developers is likely to be seen as annoying and your bug will be ignored. Testing the bug on each release of wine (or on a less regular basis) and reporting its status is welcomed and will show that you care about the bug being fixed and that you will be responsive if a developer investigates the bug further.
-
Kuba Ober -
Ray Jones -
Robert Shearman -
Roland Kaeser