Unterschied wine - Freebsd/Linux

fanatic

fanatic

Well-Known Member
Woran liegt es eigentlich dass wine unter Linux soviel besser funktioniert als unter FreeBSD? Ich bekomm regelmässig unter Linux Winprogramme auf Anhieb zum Laufen und unter FreeBSD geht dann meist garnix( wine natürlich aus Ports installiert). Schade, zumal die Ports-Version immer sehr aktuell ist(momentan 0.9.16). Oder mache ich was falsch? Es wurde einmal erwähnt dass es von Vorteil ist Standardhardware zu besitzen. Nun, das habe ich, macht aber für mich keinen Unterschied. Vielleicht hat jemand Ahnung von den Internals, für mich sieht das so aus, dass wine sehr linux-zentrisch implementiert ist.

Auf eure Antworten freut sich

Fanatic
 
Zum Beispiel ist Securom und Device Hinting nur für den Linux Kernel implementiert. Das ist wohl hauptsächlich eine Frage der Entwicklerzahlen. Außerdem wird gerade das Threading für FreeBSD umgemodelt, was dafür sorgt, das vieles was mal lief, nicht mehr läuft. Bisher konnte man mit wine-kthread diese Probleme umgehen, allerdings scheint es, das wine-kthread im neusten Port kaputt ist.
 
fanatic schrieb:
...., für mich sieht das so aus, dass wine sehr linux-zentrisch implementiert ist.

Auf eure Antworten freut sich

Fanatic
Zum Vergrößern anklicken....
Das empfinde ich genauso, und nicht nur bei wine!
Da im grunde genommen praktisch (fast) sämtliche freie Software für und auf Linux programmiert wird
und dann erst (von wieder anderen Entwicklern) auf alle anderen OSe portiert wird,
läuft natürlich (fast) alles auch Linux besser. Aus diesem Grunde habe ich, nach 5 Jahren FreeBSD auf dem Desktop, auch kapituliert und setze (Net)BSD nur noch auf dem Server ein und fahre jetzt seit in paar Monaten Fedora und CentOS auf dem Desktop.
 
OK, danke für die Antworten! Werde mal wine-kthread probieren, vielleicht bringt das Besserung
 
[OT] Nitpicking

Yoda schrieb:
Da im grunde genommen praktisch (fast) sämtliche freie Software für und auf Linux programmiert wird
und dann erst (von wieder anderen Entwicklern) auf alle anderen OSe portiert wird,
läuft natürlich (fast) alles auch Linux besser.
Zum Vergrößern anklicken....

Das mag so aussehen, aber meine bescheidene Erfahrung als jemand, der ein paar kleinere Ports fuer (Open)BSD geschrieben hat, ist die, dass Software, die auf Linux "besser" zu laufen scheint, sehr oft schlicht und ergreifend fehlerhaft ist.

Typische Fehler (die wirklich am laufenden Band auftreten): Use after free(3), Zugriffe ausserhalb einer mit malloc(3) allozierten Region, Schreiben von n+1 Bytes in ein Array mit nur n Bytes, Verwendung von Filedescriptoren nach close(2), Oeffnen von Files ohne dass diese wieder geschlossen werden.
 
kili schrieb:
Das mag so aussehen, aber meine bescheidene Erfahrung als jemand, der ein paar kleinere Ports fuer (Open)BSD geschrieben hat, ist die, dass Software, die auf Linux "besser" zu laufen scheint, sehr oft schlicht und ergreifend fehlerhaft ist.

Typische Fehler (die wirklich am laufenden Band auftreten): Use after free(3), Zugriffe ausserhalb einer mit malloc(3) allozierten Region, Schreiben von n+1 Bytes in ein Array mit nur n Bytes, Verwendung von Filedescriptoren nach close(2), Oeffnen von Files ohne dass diese wieder geschlossen werden.
Zum Vergrößern anklicken....
Da gebe ich Dir recht, die "Reinheit" des Codes ist wahrlich nicht wie von *BSD gewohnt. Aber das ist ja sogar schriftlich festgehalten. Zum Beispiel braucht man sich nur mal die Linuxquellen zu saugen und dort die Kommentare zu lesen (am besten sucht man nach den geläufigsten engl. Schimpfwörtern). Was da für Flüche über den Code drin steht, läst das Vertrauen in die Codequallität nicht gerade wachsen. Und das sieht mit anderem Code für Linux sicher auch nicht besser aus.

Allerdings habe ich jetzt nichtmal mehr halb soviel Admin-Aufwand um meinen Desktop (wie man so schön sagt) "Multimediafähig" und aktuell zu halten. Natürlich ging es auch unter FreeBSD aber das bedeutete oft Handarbeit um z.B. viele Plugins rein zu friemeln und dann hat es oft mit den Browserplugins gehapert. Unter NetBSD konnte ich das Browser-Problem mit dem Unbeliebten Netscape umgehen, der schon alles drinn hatte, nur leider konnte man den praktisch nie in deutsch kompilieren, da bei NetBSD für alle Sprachen immer die selbe Versinsnummer für das PKG angenommen wird und das deutsche Quell-PKG ist aber immer älter und nie in der aktuellen Version zu bekommen!
Dafür habe ich die Probleme gegen andere eingetauscht. Mal sehen wann die meine Nerven weich geklopft haben...
 
Zuletzt bearbeitet:
ich glaube die meisten probleme kommen von rumgefrickel mit dem neuen und alten threading modell.
ich hoffe stark dass die das endlich dauerhaft klarkriegen.
 
soul_rebel schrieb:
ich glaube die meisten probleme kommen von rumgefrickel mit dem neuen und alten threading modell.
ich hoffe stark dass die das endlich dauerhaft klarkriegen.
Zum Vergrößern anklicken....

Ein Auszug auf freebsd-ports.
Gerald Pfeifer schrieb:
GNU/Linux systems using the pthread variant,
there is little hope anyone is ever going to fix the kthread variant. I
have included the kthread variant as an added benefit, but all development
and bug fixing really should go into the pthread variant.
Zum Vergrößern anklicken....
 
mhm ich weiß ich habe auch drauf geantwortet.
wenn kthreads jetzt auch kaputt ist heißt das wohl das wine dauerhaft im arsch ist :@
finde ich auch toll, wine-kthread als deprecated zu erklären obwohl anscheinend noch niemand die wine-pthread überhaupt mal getestet hat.
SUPER :daumenhoch:
 
Es gibt einen port, der linuxthreads heißt. Würde das vielleicht weiterhelfen, oder wofür ist der?
Mit wine habe ich auch nur Probleme.
Beispielsweise schmieren einige Spiele (Rune, DeusEx, Call of Duty Multiplayer, aber Singleplayer absolut stabil hingegen) immer ab mit der Meldung: "segmentation fault: core dumped". Was bedeutet das?
Wäre besser, jemand würde einen FreeBSD-speziefischen Windows-Emulator entwickeln.
 
fanatic schrieb:
@cabriofahrer

Da liegt das Problem: wine macht nicht von linuxthreads Gebrauch.
Zum Vergrößern anklicken....

Stimmt zwar so nicht, aber wer mehr zu Threading und wine erfahren moechte:

http://www.winehq.org/site/docs/winedev-guide/threading

In dem Fall kann man sogar den Wine-Entwicklern nicht wirklich einen Vorwurf machen, da das Threading unter FreeBSD a) noch voll in Entwicklung ist und b) pthread nicht vollstaendig implementiert.

Von den extremen Unterschieden zwischen dem Windows-Threading und pthread mal ganz abgesehen.

@cabriofahrer

Ein "segmentation fault" ist ein Sicherrungsmechanismus der dann zuschlaegt, wenn ein Program auf Speicherstellen zugreift, auf keinen Zugriff erlauben. Da damit andere Anwendungen durch so eine Aktion in einen undefinierten Zustand geraten koennen, ebenso wie die Anwendung, die das Problem verursacht, wird stattdessen das Programm mit einem SIGSEGV abgeschossen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben