Nachdem wine quasi alle 2 Wochen eine neue Version raus bringt und in dieser wohl auch nichts wesentliches Verbessert wurde frage ich mich ob das nicht wirklich langsam unnötige News sind. Mein Vorschlag für solche ANkündigungen/neue Versionen u.ä. News wäre eine eigene kleine Box auf der Startseite.
Stimmt, diese Wine-Version sticht nicht durch bemerkenswerte Neuerungen heraus und da hier eh nicht alle (der sehr häufigen) Wine-Versionen angekündigt werden, fragt man sich, wieso dieser Artikel gerade jetzt bei Pro-Linux erscheint. So ein Mangel an Linux-Nachrichten, dass man jeden x-beliebigen eingesandten (Werbe-)Artikel auf die Startseite stellen muss, besteht ja nicht.
Ich finde es schon beeindruckend, was da gefixed und ergänzt wurde. Leider sind aber alle wine-release vom changelog her irgendwie "beeindruckend"... Große Änderungen an der Ausführung von Programmen konnte ich aber bisher nicht feststellen. Für den Großteil der gängigen Programme braucht man immer noch Windows-libs statt der wine-eigenen - falls die Programme denn überhaupt laufen. Ich probiere jetzt schon jahrelang, sporadisch jedes Halbjahr mal wine. Richtig *praktikabel* war das Teil aber noch nie. Leider. Mein letzter Versuch ist gut 8 Monate zurück... soll ich's nochmal probieren?
Wie gut ist wine denn jetzt eigentlich schon? Ist Cedega besser, oder gar nötig?
Verwendet ihr denn wine dauerhaft für irgendwelche Programme?
Wine ist Käse, aber für den Notfall tut es gelegentlich - oder auch nicht. Es ist trotzdem immerhin erstaunlich, daß sie es überhaupt so weit gebracht haben
Nicht Wine ist kein Käse sondern solche Pauschalurteile. Es gibt eine Menge Programme die (nahezu) fehlerfrei unter Wine funktionieren. Dies ist auch nicht erst seit einigen Monaten schon so, sondern seit etlichen Jahren und in zunehmender Anzahl. Das es daneben auch eine Menge von Programmen gibt, für die Wine bislang keine Lösung darstellt, mindert nicht den grundsätzlichen Wert von Wine.
Es gibt auch welche, die plötzlich nicht mehr mit neueren Versionen von Wine laufen. 10 Versionen später gehts dann plötzlich wieder..... auf der Website war öfter mal von Regressionen die Rede ....
Wine dürfte eigentlich nie die Version 1.0 erreichen; wenn die etwas in den Griff bekommen haben, ist MS schon 3 Meilen weiter. Auch wenn manche Windows- Programme halbwegs laufen, ist Wine eine sehr wackelige Angelegenheit.
Die kommerziellen Versionen (Crossover, Cedega) sind sicherlich verläßlicher, aber zumindest für Office- Anwendungen wird die Luft für Crossover immer dünner, weil die echten Emulatoren mittlerweile preiswert und stabil sind und meist genügend Rechenleistung da ist.
Doof nur das cedega auf eine ganz alte wine version setzt und wine nicht unterstützt.
Crossover basiert auf die aktuelle wine version und unterstütz die entwickler ;). Wine ist sicherlich kein Käse. Ohne wine gäbe es kein cedega und kein crossover.
Wenn Ich mir ansehe, was für Programme oder gar 3d-Spiele sich teilweise damit ausführen lassen, ohne daß deren Entwickler auch nur einen Finger für Lauffähigkeit unter unix krummgemacht haben, ist das Wort "Käse" wohl das letzte, was mir als Charakterisierung des Projekts in den Sinn kommt...
Full Ack! Wine ist wirklich ein gutes Programm und eine noch viel bessere Idee. Wer hat schon Lust für die kurze Nutzung eines Programmes jedesmal ne VM zu starten. Für 3D Spiele sowieso nicht möglich. Und solange die Entwickler immernoch nicht so wie EpicGames oder ID Stoftware denken und alles nur für Windows produzieren, ist dieses Projekt auch weiterhin sehr wichtig.
Die meiste Büro- bzw. "Alltagssoftware" könnte man auch einfach in Java schreiben und könnte somit 99% des Portierungsaufwandes eleminieren. Aber nö VBasic oder C# ist ja das einzige was manche in dem Bereich kennen.
> VBasic und C# sind ja dank Mono immer weniger problematisch.
Die von Microsoft warten nur darauf, dass sich die Linuxer davon abhängig machen - und dann, wenn die Zeit reif ist, kommen die mit ihren (US-)Patenten an und machen alles platt.
P.S.: Der Deal mit Novell läuft meines Wissens nach über 5 Jahre... (Novell sind die, die Mono so puschen)
Sogar in amerika ist es nicht erlaubt zukünftige patentverletzungen zu pushen genau das macht aber novell und ms jetzt....in zukunft wird also ms gar nichts anzuklagen haben.
Von Anonymous Coward am Mo, 30. April 2007 um 11:21 #
Bullshit, wie soll man jemanden wegen Implementierung eines offenen Standards verklagen? Schlimmstenfalls fliegt halt Windows.Forms raus, das unter Linux eh kein Mensch nutzt.
Ich will W2K ein Schnippchen schlagen und den IE7 installieren. Dazu ist es meine Absicht, nach der Cygwin Installation Wine zu installieren und dann darin den IE7. Oder vergewaltige ich die Software?
Müsste gehen. Würdest du aber den Unterbau weglassen und stattdessen gleich Linux nehmen, ginge es noch besser und dann wäre es auch moralisch vertretbarer.
hmm entweder versteh ich dein Problem (LinuxEsel) nicht richtig oder ich sehe das anders ^^.
also du willst unter windows in cygwin wine installieren um da dann ie7 drüber zu starten?? Das halte ich für moralisch kein problem aber ich verstehe den Sinn dahinter nicht?
Ist doch ganz klar. IE7 = Nix laufen unter Win2000. Ursprungsposter braucht aber aus irgendeinem Grund exakt diese Kombination. (Wir gehen jetzt mal davon aus, dass der Grund ein guter ist, anstatt überheblich auf ihn herabzublicken, und von irgendwelchen "moralischen" Implikationen zu faseln.) Jetzt versucht er sie halt per unter Windows emulierten Wine, welches wiederum dem IE7 ein neueres Windows vorgaukelt, ans laufen zu kriegen. Ich finde die Idee hat was von einem netten Hack.
Zitat: "Overview A VPC hard disk image containing a pre-activated Windows XP SP2, and either IE6 or IE7 and the IE7 Readiness Toolkit. This VPC image will expire on 08/17/2007." -> Klick Das dürfte eventuell etwas in diese Richtung sein.
Meine Empfehlung: nehme XP, installiere den MSIE7, lasse den MSIE6 unter wine/cygwin laufen... theoretisch machbar - aber mit einigen Problemen verbunden, da XP/2000 nicht voll Posix-kompatibel sind (Device-Struktur, etc.)...
es gibt unter linux sonen dings, ie4wine oder ie4linux weiss nicht mehr genau. das installiert unter wine automatisch ie7. vieleicht kannst du das script ja unter cygwin zum laufen bekommen (habe noch nie cygwin verwendet). sonst kannst du ja immernoch eine virtuele maschine mit linux installieren (dank virtual box nun auch open source gut machbar) und darauf ie7 installieren. irgendwie traurig das ganze...
Von Anonymous Coward am Mo, 30. April 2007 um 11:23 #
Das ist blödsinnig, WINE läuft auch unter Windows, Du brauchst cygwin also gar nicht. http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=112520
Also, erstmal ist glaub der Newswert eher gering, weil wine regelmäßig alle 2 Wochen releases rausbringt.
Das gaanz große Problem von Wine ist imho, dass sie einem sehr chaotischen Entwicklungsmodell folgen und bspw. komplett auf Regression tests verzichten. Reportet man eine Regression, sollten eigentlich bei jedem Entwickler die Alarmglocken läuten. Bei Wine werden selbige geflissentlich ignoriert. Und genau deswegen ist es oft unbrauchbar: Funktioniert etwas einmal, heißt das noch lange nicht, dass es ein halbes Jahr später immer noch tut.
Weist man Wineentwickler darauf hin, bekommt man oft die Antwort "Crossover". Danke. Erinnert an cdrtools. Ist auch irgendwann gescheitert. Das Entwicklungsmodell "wir machen ein freies projekt, das wir künstlich schlecht halten, damit unser kommerzielles Produkt besser verkauft wird", leider glauben immer noch einige daran, sollte man entgültig mal beerdigen.
Das hat meines Wissens einfach was damit zu tun, dass da viele Ecken große Baustellen sind, und wenn dann da dran gearbeitet wird, ist vielleicht etwas sauberer implementiert und es gibt neue Dinge, die laufen und andere Dinge dafür gehen dann halt erstmal nicht mehr, bis man da weiter gebaut hat.
Stell dir vor du sitzt in einer Wohnung und willst aus dem Fenster schauen.
Im ersten Jahr geht das wunderbar. Im zweiten Jahr kommen die Entwickler und streichen und isolieren das Haus neu, dein Fenster ist von einem Baugerüst und Abdeckfolien verdeckt, du kannst also nicht rausschauen.
Jetzt hast du zwei Möglichkeiten, damit du wieder rausschauen kannst:
1. Du verlangst, daß man das Gerüst wieder abbaut, aber dann kann das Haus nicht mehr neu verputzt und isoliert werden, was bedeutet daß du im Winter wie bisher wieder viel für die Heizung zahlen mußt und kein schönes Haus hast. oder 2. Du wartest solange, bis die Entwickler mit dem Isolieren und Anstreichen fertig sind, erst danach können sie das Gerüst vor deinem Fenster wieder abbauen, so damit du wieder eine freie Sicht hast.
Und genau so ist das auch bei Wine.
So, und jetzt sagt mir wie entscheidest du dich bzw. was wäre dir lieber?
Von EinNichtGanzUnbeteiligter am Sa, 28. April 2007 um 23:41 #
"komplett auf Regression tests verzichten". Ja sicher. Ganz klar. Muss ja auch so sein. Hat sich der werte Mensch ueberhaupt ein einziges Mal mit Wine naeher beschaeftigt? Man kann sofort daran Kritik ueben, dass noch viel zu wenig getestet wird, aber die Test Suite in Wine war schon vor Jahren halbwegs brauchbar und ist garantiert nicht kleiner geworden. Wieviele andere Projekte haben ueberhaupt Testcode?? Von wichtigen Infrastruktur-Projekten (gcc, glibc, ..., und eben Wine) abgesehen wohl nicht allzuviele.
"Das Entwicklungsmodell ... sollte man entgültig mal beerdigen." Ja SUPERTOLL! Meinst Du, es waere besser, wenn CodeWeavers einfach niemanden einstellen wuerde und stattdessen die Wine-Entwickler einen voellig anderen Tages-Programmierjob machen wuerden (weil sie ja mit *irgendwas* ihr Geld verdienen muessen), damit sie dann abends noch frisch und ausgeruht und mit Frau und Kind(ern) im Haus frohgemut an Wine arbeiten? Na das wuerde Qualitaet und Umfang von Wine dramatisch erhoehen, klasse!
Ich kann mir sehr gut vorstellen, dass CrossOver Office in Installation und Bedienung speziell aufgebohrt wurde, aber das aendert nix daran, dass Unmengen von Arbeit in Wine zurueckfliessen.
Abgesehen davon kann ich mich nicht erinnern, dass hier jede Wine-Version angekuendigt wurde, insofern ist es gut, dass das immer wieder mal alle paar Halbjahre passiert.
>Man kann sofort daran Kritik ueben, dass noch viel zu wenig getestet wird, aber die Test Suite in Wine war schon vor Jahren halbwegs brauchbar und ist >garantiert nicht kleiner geworden.
Ok, existent ist sie. Allerdings, so wirklich durchlaufen sehen hab ich die noch nie und hab mir sagen lassen (ok, das ist kein gutes argument, ich weiss), dass das interesse, da zu fixen, nicht sonderlich hoch ist. Falls Du Gentoo installiert hast, versuch mal, die Zeile RESTRICT="test" zu entfernen und FEATURES="test" anzumachen und guck ma was passiert.
Und es ist schlicht die Erfahrung, die ich gemacht hab, dass es fast regelmäßig so ist, wenn ich mich grad freue, dass etwas geht, dass es ziemlich sicher in einer der nächsten versionen wieder nicht geht. Das ärgerliche finde ich immer, ich hab den Eindruck, das Projekt hätte eigentlich riesen Potential. Wenn man mal nicht mehr nach der methode "ach, wir ersetzen subsystem a durch x, dann bricht erstmal alles, aber das fixen wir dann im nächsten release, wo dann allerdings subsystem b durch y ersetzt wurde" entwickeln würde.
Achja, und das Argument zwecks "die armen entwickler, wer zahlt die denn", kannst Du das bitte den Microsoft-apologethen überlassen? Es gibt zig freie Softwareprojekte da draußen, mit haufenweise bezahlten entwicklern und den verschiedensten Geschäftsmodellen. Aber ein erfolgreiches, welches darauf baut, "freie version ist hoffnungslos instabil und eh für otto-normal-user kaum benutztbar, der darf die stabile kommerzielle kaufen", ist mir noch nicht begegnet. cdrtools ist zum Glück endlich geforkt worden.
Hanno hat (leider) zm großteil recht ! Neue Features einbauen schö nund gut, aber wenn dafür andere dann icht gehen...das Entwicklungsmodell ist recht wüst, aber ich denke mal ab 1.0 (wofür es ja ne recht feste TODO Liste gibt) entscheiden die sich ach für sowas wien "stable" und "testing" zweig, wo im stable die testsuit auf den meisten testsystemen durchläuft, und bei testing halt neues implementiert wird was noch nich ganz rund läuft usw. Das wäre IMHO der richtige weg, noch nennt Wine sich selbst BETA und da sollte man nicht immer so viel erwarten. Das Projekt macht sehr wohl sehr gute fortschritte aber die Regressionen usw. hinterlassen bei den meisten Usern (wo mal was geht, mal nicht) schon keinen guten Eindruck, was man auch verstehen muss da viele das BETA auch nicht mehr so ernst nehmen da vieles im OpenSource Bereich schon unter den Titel "1.0" stabil und zuverlässig läuft. Die wenigsten Projekte dadrunter haben die komplexität von wine ...
Also, das mit der 1.0 glaub ich erst wenn sie da ist. Hab eben beim googeln eine meldung gefunden, von 2002 (!) dass die 1.0 quasi kurz bevorsteht: http://www.oszine.de/node/366
Hat sich leider etwas verzögert. Es stellte sich heraus, dass Duke Nukem Forever unter Hurd 1.0 nur mit WINE geht. Von daher wird das gesamte Paket als Bundle erscheinen, man munkelt von irgendeinem Wochentag in der nächsten Zeit.
Von EinNichtGanzUnbeteiligter am So, 29. April 2007 um 20:37 #
Zum Thema Testsuite waere hiermit wohl alles gesagt; sie ist eben stark ausbaufaehig.
Aber dieses "die armen entwickler, wer zahlt die denn"-Argument kann ich so keinesfalls stehen lassen. Es ging mir NICHT darum, dass Entwickler am Hungertuch nagen muessen, sondern um die Belange des Projekts: schlicht und einfach darum, dass ich durch brauchbaren kommerziellen Einsatz einer Firma (zumindest wenn die Firma nicht stark gegen das Projekt arbeitet, z.B. durch Abzug eines Grossteils der Entwicklerresourcen von Projektarbeit und hin zu anderen Projekten oder Verwaltungskram) die Aktivitaet in einem Projekt erhoehen kann, da Leute genau das auch hauptberuflich machen koennen statt in andere Arbeitsplaetze abzuwandern. Ich glaube ausserdem kaum, dass (wie oben quasi behauptet) CXO so waaaahnsinnig stabiler als das "normale" Wine ist, das kann es schon prinzipbedingt eigentlich nicht sein... Wine ist einfach ein verdammt aufwendiges Projekt (mindestens > 50 verschiedene System-DLLs mit durchschnittlich vielleicht 150 Funktionen pro DLL, die ALLE perfekt stabil implementiert sein wollen); mit so wenig Manpower kann man somit nur begrenzt/langsamer Erfolg erreichen. Jede weitere Diskussion ueber diesen Sachverhalt ist ganz schnell Herumlamentiererei. Andererseits muesste Wine sich natuerlich permanent fragen, wie man durch systematischere Vorgehensweise Erfolg und Stabilitaet des Projekts erhoehen kann.
Wine ist ein wahnsinnig interessanted Projekt, aber natürlich skaliert es nicht so richtig. Wie sollten auch die Programmierer von Wine das auf die Beine stellen, was tausende Programmierer fabriziert haben. Aber es ist auf jeden Fall inzwischen möglich, Programme perfekt zum Laufen zu bekommen.
Eigentlich fehlt nur der große Sponsor, der richtig Geld drauf kloppt. Corel hat das mal versucht, aber zu der zeit war es noch nichts wirklich. Irgendwie fehlt da einer, der mal Spenden eintreibt...
Siege VMWare, Connectix,... die zeigen wie man der Komplexität ein Schnippchen schlägt. Wine wird immer 2 Schritte hinter MS her hecheln. Besser man emuliert gleich die ganze Maschiene und kloppt dort das native System drauf, spart viel Arbeit und läuft am Ende auch sauberer, die Wartbarkeit auch einfacher. So sehen richtige Lösungen aus. Wine? -> Überflüssig.
Ist 'n netter Hack, dieses Wine, aber da das Funktionieren und Nichtfunktionieren eines Programmes in Wine irgendeinem nicht deterministischen Rhythmus folgt, ist es bestenfalls für Frickler, die sich mehrere Versionen davon parallel halten können.
Da dies in den meisten Paketverwaltungen nicht vorgesehen ist, ist das nicht jederDAUs Sache und scheidet als Vorgehensweise aus.
Was bleibt ist eher von Democharakter.
Wenn ich ernsthaft Windows brauchen würde, würde ich daher auch eher über VMware und Co nachdenken oder über die Anschaffung eines für die Aufgabe hinreichenden Rechners. Letzteres liegt dann eventuell auf dem Gebrauchtmarkt auch nur bei ca VMware-Preis und dank VNC und Kollegen ist auch nur einmal die Humanschnittstelle nötig.
Also abgesehen davon, daß Wine interessant ist und es vielleicht auch manchem Entwickler einfach Spaß macht, daran zu wurschdeln, sehe ich mangels Zuverlässigkeit die Zielgruppe nicht.
1. wine ist kein hack! 2. benutze ich seit jahren wine und hatte nur selten hier und da mal ein problem 3. >Wenn ich ernsthaft Windows brauchen würde, würde ich daher auch eher über VMware mir z.B. geht es darum KEIN win aufm rechner zu haben(hatte mal eins und hatte damit mehr probs als mit ner alten wine version) und hast du überhaupt schonmal probiert win mit VM-ware oder änlichem zum laufen zu bekommen(ich meine mit spielen und co.) ich habs mal probirt und es lief nich beser als ein schlechter emu also schlag dir das mit VM-ware ausm kopf is eh nich besser als winXP aufm 300MHz Rechner laufen zu lassen
Also dass VMWar XP nur wie auf einem 300MHz Rechner läuft kann ich NICHT bestätigen, vielleicht solltest du mal den Hauptspeicher auf mehr als 512 MB aufrüsten, bevor du solch unqualifizierte Aussagen tätigst! Zum spielen ist VMWare nicht geeignet, schon wegen der mangelnden 3D-Beschleunigung. Und die Harddisk sollte man auch nicht als Datei anlegen, wen man mit Datenbanken oder ähnlichem in der VM arbeiten will.
"Also dass VMWar XP nur wie auf einem 300MHz Rechner läuft kann ich NICHT bestätigen" ich verstehe deinen satz nich ganz aba ich deute mal das du meunst das winXP auf VMware nich mit 300MHz läuft. ja das stimmt (hab dan bissel übertriben) aber al ich das letzte mal winXP auf ner VM(ok es war nich VMware sondern Virtual-box) gestartet hab (btw ich hab nich nur 512MB-Ram) lief alles so s*umassig langsam das ich mühe hatte das teil noch ordentlich runter zu fahren(is aba wie gesagt schon ein weilchen her also hat sich da ja vieleich was dran getan aber es laufen selbst dann keine spiele(nich nur keine 3D-spiele) also was soll ich dann mit WinXP??)
> 2. is das chatt sprache Glaub' mir, viel cooler sind die Jungs, die auf so etwas verzichten. Ich bin etwa doppelt so alt wie Du und habe in den letzten 12 Jahren Internet mehrere dieser Auswüchse gesehen. Du wirst in - sagen wir - 10 Jahren selbst den Kopf darüber schütteln. ;)
Wer startet für ein kleines mini Programm schon unnötig eine virtuelle Maschine?
Wine ist definitiv nicht überflüssig. Dank wine kann man ohne virtueller Maschine Windows Programme und spiele ausführen. Dank wine gibt es auch bald eine alternative zu windows namens reactos...
Dank wine läuft starmoney ohne virtueller Maschine unter Linux. Dank wine....
Dank wine kann ich als Homepage Ersteller ganz einfach auch seiten unterm IE6 und IE7 testen.
Ich wüsste nicht wozu ich eine virtuelle Maschine bräuchte. Die windows software die ich brauche läuft unter wine. Und wenn nicht läuft die ank dem großen ressourcen Verbrauch auch nicht unter vmware und co.
Schonmal ressourcen fressende progs unter vmware ausprobiert? Counterstrike und co lässt sich damit jedenfalls nicht zocken.
Ubuntu legt's ja offensichtlich drauf an, Windows direkte Konkurrenz zu machen, Microsoft hilft dem mit DRM nach, und ReactOS und Wine machen schön weiter auf gerader Linie.
Ich bin mal gespannt, ob Windows tot ist, wenn Wine 1.0 rauskommt.
So schnell wirds garantiert nicht gehen. Sie müßten nur mal eines Machen. Ein Wine 1.0 definieren. Das braucht (und wird) nicht 100% zu Windows kompatible sein, aber es stelle eine "1.0" dar, an welche sich Softwarehersteller orientiern können. Diese Könne dagegen testen und evtl mit kleinen Ändereung ihre Sotere dazu kompatible machen (Mach die zumindest eher al ihren quelltext auf linux/mac zu portieren. Diese 1.0 erhält dann eine feste API be der nur noch Fehlerkorekturen durchgeführt werden. Gleichzeitig kann bei einem 1.9er-Zweig weiter daran gearbeitet werden die Kompatiblität zum Rest zu erhöhen.
So funzt das nicht. Das wäre das Konzept für die Winelib.
Grundsätzlich muss man wenn der Rahmen steht nur noch API implementieren. Wenn du also eine Version hast, die nicht läuft, dann implementierst du jene Teile der API auf die sie angewiesen ist.
Wine 1.0 was längst definiert ist, heisst, dass das framework steht.
Leider sind aber alle wine-release vom changelog her irgendwie "beeindruckend"...
Große Änderungen an der Ausführung von Programmen konnte ich aber bisher nicht feststellen. Für den Großteil der gängigen Programme braucht man immer noch Windows-libs statt der wine-eigenen - falls die Programme denn überhaupt laufen.
Ich probiere jetzt schon jahrelang, sporadisch jedes Halbjahr mal wine. Richtig *praktikabel* war das Teil aber noch nie. Leider.
Mein letzter Versuch ist gut 8 Monate zurück... soll ich's nochmal probieren?
Wie gut ist wine denn jetzt eigentlich schon? Ist Cedega besser, oder gar nötig?
Verwendet ihr denn wine dauerhaft für irgendwelche Programme?
Es gibt auch welche, die plötzlich nicht mehr mit neueren Versionen von Wine laufen. 10 Versionen später gehts dann plötzlich wieder..... auf der Website war öfter mal von Regressionen die Rede ....
Wine dürfte eigentlich nie die Version 1.0 erreichen; wenn die etwas in den Griff bekommen haben, ist MS schon 3 Meilen weiter. Auch wenn manche Windows- Programme halbwegs laufen, ist Wine eine sehr wackelige Angelegenheit.
Die kommerziellen Versionen (Crossover, Cedega) sind sicherlich verläßlicher, aber zumindest für Office- Anwendungen wird die Luft für Crossover immer dünner, weil die echten Emulatoren mittlerweile preiswert und stabil sind und meist genügend Rechenleistung da ist.
Crossover basiert auf die aktuelle wine version und unterstütz die entwickler ;).
Wine ist sicherlich kein Käse. Ohne wine gäbe es kein cedega und kein crossover.
Die Idee oder die Umsetzung?
Wenn Ich mir ansehe, was für Programme oder gar 3d-Spiele sich teilweise damit ausführen lassen, ohne daß deren Entwickler auch nur einen Finger für Lauffähigkeit unter unix krummgemacht haben, ist das Wort "Käse" wohl das letzte, was mir als Charakterisierung des Projekts in den Sinn kommt...
Ich finds top!
Wine ist wirklich ein gutes Programm und eine noch viel bessere Idee. Wer hat schon Lust für die kurze Nutzung eines Programmes jedesmal ne VM zu starten. Für 3D Spiele sowieso nicht möglich. Und solange die Entwickler immernoch nicht so wie EpicGames oder ID Stoftware denken und alles nur für Windows produzieren, ist dieses Projekt auch weiterhin sehr wichtig.
Die meiste Büro- bzw. "Alltagssoftware" könnte man auch einfach in Java schreiben und könnte somit 99% des Portierungsaufwandes eleminieren. Aber nö VBasic oder C# ist ja das einzige was manche in dem Bereich kennen.
Die von Microsoft warten nur darauf, dass sich die Linuxer davon abhängig machen - und dann, wenn die Zeit reif ist, kommen die mit ihren (US-)Patenten an und machen alles platt.
P.S.: Der Deal mit Novell läuft meines Wissens nach über 5 Jahre...
(Novell sind die, die Mono so puschen)
genau das macht aber novell und ms jetzt....in zukunft wird also ms gar nichts anzuklagen haben.
Kannst Du mir einen entsprechenden Gesetzes- oder Satzungspassus mal zeigen?
Faktum: Standards können problemlos durch Patente gedeckt werden.
Oder ist MPEG2 kein Standard? Ist GSM kein Standard? Klar gibt es hier zu Hauf Patente, aber Standards sind es.
also du willst unter windows in cygwin wine installieren um da dann ie7 drüber zu starten??
Das halte ich für moralisch kein problem aber ich verstehe den Sinn dahinter nicht?
oder hab ich dich falsch verstanden ?
Übrigens Jungs: Klasse, daß ihr antwortet.
Ich verstehe hier nicht, was du meinst.
2.) Ich habe son WGA-Ding für W2K, das gibt mir immer ein
Passwort aus, reicht das zur IE7 Installation?
3.) wieso werde ich bei meinen Postings mal gesperrt, mal nicht?
Die Version für Windows natürlich.
A VPC hard disk image containing a pre-activated Windows XP SP2, and either IE6 or IE7 and the IE7 Readiness Toolkit.
This VPC image will expire on 08/17/2007." -> Klick
Das dürfte eventuell etwas in diese Richtung sein.
Gruß, Alex
irgendwie traurig das ganze...
http://sourceforge.net/project/showfiles.php?group_id=6241&package_id=112520
Das gaanz große Problem von Wine ist imho, dass sie einem sehr chaotischen Entwicklungsmodell folgen und bspw. komplett auf Regression tests verzichten. Reportet man eine Regression, sollten eigentlich bei jedem Entwickler die Alarmglocken läuten. Bei Wine werden selbige geflissentlich ignoriert. Und genau deswegen ist es oft unbrauchbar: Funktioniert etwas einmal, heißt das noch lange nicht, dass es ein halbes Jahr später immer noch tut.
Weist man Wineentwickler darauf hin, bekommt man oft die Antwort "Crossover". Danke. Erinnert an cdrtools. Ist auch irgendwann gescheitert. Das Entwicklungsmodell "wir machen ein freies projekt, das wir künstlich schlecht halten, damit unser kommerzielles Produkt besser verkauft wird", leider glauben immer noch einige daran, sollte man entgültig mal beerdigen.
Im ersten Jahr geht das wunderbar.
Im zweiten Jahr kommen die Entwickler und streichen und isolieren das Haus neu, dein Fenster ist von einem Baugerüst und Abdeckfolien verdeckt, du kannst also nicht rausschauen.
Jetzt hast du zwei Möglichkeiten, damit du wieder rausschauen kannst:
1. Du verlangst, daß man das Gerüst wieder abbaut, aber dann kann das Haus nicht mehr neu verputzt und isoliert werden, was bedeutet daß du im Winter wie bisher wieder viel für die Heizung zahlen mußt und kein schönes Haus hast.
oder
2. Du wartest solange, bis die Entwickler mit dem Isolieren und Anstreichen fertig sind, erst danach können sie das Gerüst vor deinem Fenster wieder abbauen, so damit du wieder eine freie Sicht hast.
Und genau so ist das auch bei Wine.
So, und jetzt sagt mir wie entscheidest du dich bzw. was wäre dir lieber?
Sorry, couldn't resist.
Ja sicher. Ganz klar. Muss ja auch so sein.
Hat sich der werte Mensch ueberhaupt ein einziges Mal mit Wine naeher beschaeftigt?
Man kann sofort daran Kritik ueben, dass noch viel zu wenig getestet wird, aber die Test Suite in Wine war schon vor Jahren halbwegs brauchbar und ist garantiert nicht kleiner geworden.
Wieviele andere Projekte haben ueberhaupt Testcode?? Von wichtigen Infrastruktur-Projekten (gcc, glibc, ..., und eben Wine) abgesehen wohl nicht allzuviele.
"Das Entwicklungsmodell ... sollte man entgültig mal beerdigen."
Ja SUPERTOLL!
Meinst Du, es waere besser, wenn CodeWeavers einfach niemanden einstellen wuerde und stattdessen die Wine-Entwickler einen voellig anderen Tages-Programmierjob machen wuerden (weil sie ja mit *irgendwas* ihr Geld verdienen muessen), damit sie dann abends noch frisch und ausgeruht und mit Frau und Kind(ern) im Haus frohgemut an Wine arbeiten?
Na das wuerde Qualitaet und Umfang von Wine dramatisch erhoehen, klasse!
Ich kann mir sehr gut vorstellen, dass CrossOver Office in Installation und Bedienung speziell aufgebohrt wurde, aber das aendert nix daran, dass Unmengen von Arbeit in Wine zurueckfliessen.
Abgesehen davon kann ich mich nicht erinnern, dass hier jede Wine-Version angekuendigt wurde, insofern ist es gut, dass das immer wieder mal alle paar Halbjahre passiert.
Praedikat Kommentar: Unbrauchbar (tm).
>garantiert nicht kleiner geworden.
Ok, existent ist sie. Allerdings, so wirklich durchlaufen sehen hab ich die noch nie und hab mir sagen lassen (ok, das ist kein gutes argument, ich weiss), dass das interesse, da zu fixen, nicht sonderlich hoch ist. Falls Du Gentoo installiert hast, versuch mal, die Zeile RESTRICT="test" zu entfernen und FEATURES="test" anzumachen und guck ma was passiert.
Und es ist schlicht die Erfahrung, die ich gemacht hab, dass es fast regelmäßig so ist, wenn ich mich grad freue, dass etwas geht, dass es ziemlich sicher in einer der nächsten versionen wieder nicht geht.
Das ärgerliche finde ich immer, ich hab den Eindruck, das Projekt hätte eigentlich riesen Potential. Wenn man mal nicht mehr nach der methode "ach, wir ersetzen subsystem a durch x, dann bricht erstmal alles, aber das fixen wir dann im nächsten release, wo dann allerdings subsystem b durch y ersetzt wurde" entwickeln würde.
Achja, und das Argument zwecks "die armen entwickler, wer zahlt die denn", kannst Du das bitte den Microsoft-apologethen überlassen? Es gibt zig freie Softwareprojekte da draußen, mit haufenweise bezahlten entwicklern und den verschiedensten Geschäftsmodellen. Aber ein erfolgreiches, welches darauf baut, "freie version ist hoffnungslos instabil und eh für otto-normal-user kaum benutztbar, der darf die stabile kommerzielle kaufen", ist mir noch nicht begegnet. cdrtools ist zum Glück endlich geforkt worden.
Das wäre IMHO der richtige weg, noch nennt Wine sich selbst BETA und da sollte man nicht immer so viel erwarten.
Das Projekt macht sehr wohl sehr gute fortschritte aber die Regressionen usw. hinterlassen bei den meisten Usern (wo mal was geht, mal nicht) schon keinen guten Eindruck, was man auch verstehen muss da viele das BETA auch nicht mehr so ernst nehmen da vieles im OpenSource Bereich schon unter den Titel "1.0" stabil und zuverlässig läuft. Die wenigsten Projekte dadrunter haben die komplexität von wine ...
http://www.oszine.de/node/366
Aber dieses "die armen entwickler, wer zahlt die denn"-Argument kann ich so keinesfalls stehen lassen.
Es ging mir NICHT darum, dass Entwickler am Hungertuch nagen muessen, sondern um die Belange des Projekts: schlicht und einfach darum, dass ich durch brauchbaren kommerziellen Einsatz einer Firma (zumindest wenn die Firma nicht stark
gegen das Projekt arbeitet, z.B. durch Abzug eines Grossteils der Entwicklerresourcen von Projektarbeit und hin zu anderen Projekten oder Verwaltungskram)
die Aktivitaet in einem Projekt erhoehen kann, da Leute genau das auch hauptberuflich machen koennen statt in andere Arbeitsplaetze abzuwandern.
Ich glaube ausserdem kaum, dass (wie oben quasi behauptet) CXO so waaaahnsinnig stabiler als das "normale" Wine ist, das kann es schon prinzipbedingt eigentlich nicht sein...
Wine ist einfach ein verdammt aufwendiges Projekt (mindestens > 50 verschiedene System-DLLs mit durchschnittlich vielleicht 150 Funktionen pro DLL, die ALLE perfekt stabil implementiert sein wollen); mit so wenig Manpower kann man somit nur begrenzt/langsamer Erfolg erreichen. Jede weitere Diskussion ueber diesen Sachverhalt ist ganz schnell Herumlamentiererei.
Andererseits muesste Wine sich natuerlich permanent fragen, wie man durch systematischere Vorgehensweise Erfolg und Stabilitaet des Projekts erhoehen kann.
Eigentlich fehlt nur der große Sponsor, der richtig Geld drauf kloppt. Corel hat das mal versucht, aber zu der zeit war es noch nichts wirklich. Irgendwie fehlt da einer, der mal Spenden eintreibt...
Wine wird immer 2 Schritte hinter MS her hecheln. Besser man emuliert gleich die ganze Maschiene und kloppt dort das native System drauf, spart viel Arbeit und läuft am Ende auch sauberer, die Wartbarkeit auch einfacher. So sehen richtige Lösungen aus.
Wine? -> Überflüssig.
Da dies in den meisten Paketverwaltungen nicht vorgesehen ist, ist das nicht jederDAUs Sache und scheidet als Vorgehensweise aus.
Was bleibt ist eher von Democharakter.
Wenn ich ernsthaft Windows brauchen würde, würde ich daher auch eher über VMware und Co nachdenken oder über die Anschaffung eines für die Aufgabe hinreichenden Rechners. Letzteres liegt dann eventuell auf dem Gebrauchtmarkt auch nur bei ca VMware-Preis und dank VNC und Kollegen ist auch nur einmal die Humanschnittstelle nötig.
Also abgesehen davon, daß Wine interessant ist und es vielleicht auch manchem Entwickler einfach Spaß macht, daran zu wurschdeln, sehe ich mangels Zuverlässigkeit die Zielgruppe nicht.
2. benutze ich seit jahren wine und hatte nur selten hier und da mal ein problem
3.
>Wenn ich ernsthaft Windows brauchen würde, würde ich daher auch eher über VMware
mir z.B. geht es darum KEIN win aufm rechner zu haben(hatte mal eins und hatte damit mehr probs als mit ner alten wine version) und hast du überhaupt schonmal probiert win mit VM-ware oder änlichem zum laufen zu bekommen(ich meine mit spielen und co.) ich habs mal probirt und es lief nich beser als ein schlechter emu
also schlag dir das mit VM-ware ausm kopf is eh nich besser als winXP aufm 300MHz Rechner laufen zu lassen
Zum spielen ist VMWare nicht geeignet, schon wegen der mangelnden 3D-Beschleunigung. Und die Harddisk sollte man auch nicht als Datei anlegen, wen man mit Datenbanken oder ähnlichem in der VM arbeiten will.
ich verstehe deinen satz nich ganz aba ich deute mal das du meunst das winXP auf VMware nich mit 300MHz läuft. ja das stimmt (hab dan bissel übertriben) aber al ich das letzte mal winXP auf ner VM(ok es war nich VMware sondern Virtual-box) gestartet hab (btw ich hab nich nur 512MB-Ram) lief alles so s*umassig langsam das ich mühe hatte das teil noch ordentlich runter zu fahren(is aba wie gesagt schon ein weilchen her also hat sich da ja vieleich was dran getan aber es laufen selbst dann keine spiele(nich nur keine 3D-spiele) also was soll ich dann mit WinXP??)
Du solltest evtl. weniger von dem namensgebenden Getränk zu dir nehmen, wenn du etwas posten möchtest.
2. is das chatt sprache
3. wo hab ich bitte diesen datz verwendet???
Glaub' mir, viel cooler sind die Jungs, die auf so etwas verzichten. Ich bin etwa doppelt so alt wie Du und habe in den letzten 12 Jahren Internet mehrere dieser Auswüchse gesehen. Du wirst in - sagen wir - 10 Jahren selbst den Kopf darüber schütteln. ;)
lg
Erik
Wer startet für ein kleines mini Programm schon unnötig eine virtuelle Maschine?
Wine ist definitiv nicht überflüssig. Dank wine kann man ohne virtueller Maschine Windows Programme und spiele ausführen. Dank wine gibt es auch bald eine alternative zu windows namens reactos...
Dank wine läuft starmoney ohne virtueller Maschine unter Linux. Dank wine....
Dank wine kann ich als Homepage Ersteller ganz einfach auch seiten unterm IE6 und IE7 testen.
Ich wüsste nicht wozu ich eine virtuelle Maschine bräuchte. Die windows software die ich brauche läuft unter wine. Und wenn nicht läuft die ank dem großen ressourcen Verbrauch auch nicht unter vmware und co.
Schonmal ressourcen fressende progs unter vmware ausprobiert? Counterstrike und co lässt sich damit jedenfalls nicht zocken.
als erklär mal bitte
Ich bin mal gespannt, ob Windows tot ist, wenn Wine 1.0 rauskommt.
http://www.reactos.org/
Eigentlich geht es nur darum, dass man etwas hat, was funktioniert. Der Rest wächst dann von alleine.
Grundsätzlich muss man wenn der Rahmen steht nur noch API implementieren. Wenn du also eine Version hast, die nicht läuft, dann implementierst du jene Teile der API auf die sie angewiesen ist.
Wine 1.0 was längst definiert ist, heisst, dass das framework steht.