AW: AW: Already Error while installing MS Office 2003

[Chris Robinson]

On Saturday 16 September 2006 10:54, Roland Kaeser wrote:
> >And break other Applications.
>
> Not urgently

Depends on the application, no? Try to get the latest and greatest programs 
working, you run a strong risk of breaking old programs and games. People 
still do play/use old games/programs, so you'd immediately alienate them. Try 
to fix/hack them to work, you run the risk of breaking newer programs. In the 
end, you'll need to do a proper implementation to get most stuff working 
anyway. Why waste time with hacks?

> Hey guys can't anybody see the reason? The wine project (or the finish of
> itself) could bring linux the breakthrough.

Not with code hacked up the yin-yang. That'd be a one-way ticket to giving 
Linux/Wine the big "Unstable" badge.

> I know a lot of people who asks 
> as first question: Is this or the other app working on linux? Then I will
> think about a migration.

And with a hacked-up code base, it'd be one or the other, or neither. But most 
likely not both.

> Yes, faster development is paid by a less of stability. But is wine
> currently stable?

Wine is (almost) perfectly stable. It's just incomplete. Wine itself has 
rarely ever crashed on me. The only problems have arisen from 
its /unfinished/ WinAPI implementation. When it's complete, it'll ideally 
make Windows apps behave just as if they were on Windows. Using hacked code 
to make some programs work will almost certainly make sure other programs 
don't (with that list ever changing as more and more hacks are introduced). 
Is that stable?

> We should make a weekly public list of currently working applications (out
> of the box).

That is what AppDB is really for. But there are tons of Windows apps, and very 
few people that can commit keeping up with the latest changes. And it's not 
as simple as what works out of the box. It depends on the hardware people 
have, their driver versions, kernel versions, etc. Then you have to figure 
that the different packages for different package managers can introduce 
their own problems/tweaks.

> I strongly think this is the measurement of the development 
> progress of wine. This is is also the only thing users are interested in!

Just because that's what users are interested in doesn't mean that's the most 
important thing. A proper, manageable codebase to get 90% of the apps working 
later is far more important for Wine than a hacked up codebase that gets 
maybe 40% of the apps working now (and causing a megaton of problems to try 
to make the rest work later).

Do you want most apps to work in a while, or some apps to work now and most 
apps to work a long time from now (if ever)? And don't forget, everyone will 
have a different idea of which apps should work /now/. You complain about 
Wine taking so long to get most apps working. It'll be easilly 5 to 10 times 
longer to get most apps working if the codebase is mostly hacks.