XDC2014 - Quo vadis

darktrym

darktrym

Fahnenträger
Die Videos von diesjährigen Treffen sind online, irgendwie ernüchern.

Nicht nur das BSDs weit hinterherhinken, ja OpenBSD ist da am weitesten, aber alles ist ziemlich gammelig und voller Baustellen.
OpenBSD hängt noch relativ dicht am Linux DRM Code, ohne den Code mal reviewed zu haben, Hauptsache aktuell. Herb schreibt gerne mal Fetzen wie Systemd auf die Folien und wird draufhin von den Fragenden zurecht gerückt, ein wenig unprofessionell/peinlich/Fremdscham.
FreeBSD darf bald wieder von neuen anfangen zu portieren oder die fehlenden Bits massiv nachliefern, haben den Code angepasst(KNF), da scheint sich auch langsam sehr wenig zu tun .Die benutzen nicht nur die alten DRM Code auch die Treiber bspw. Intel sind recht alt(kein 3er Zweig).
Dazu kommen große Änderungen auf die BSD zu, Systemd-logind damit X bzw Wayland ohne Root Rechte läuft und Wayland(unerforschtes Land) und wieder eine Änderung der Treiberinfrastruktur.
Nvidia pusht Infrastruktur damit verschiedene DRM Libs parallel betrieben werden können, Zweck Nouveau parallel zu prop Nvidia. Immerhin soll die Struktur Unixartig sein, mal schauen wie die Lizenz ausschaut.
AMD zieht sich aus Radeon zurück um ihr immerhin MIT/X lizenzierten AMDGPU Treiber als Basisversion zu propagieren, Glamor wird Standard bei 2D Beschleunigung und Bestandteil von X. AMDGPU macht da einen harten Cut, kein Support alter Asics, keine doppelte Arbeit. Der Aufwand für einen prop. FreeBSD Treiber wird theoretisch kleiner. Viel Treiber Kram ist ohnehin nun GPL(was soll diese blöden Zwischenfragen ob es GPL ist, BSDL erlaubt ohne mehr) - frag mich was man mit Matrox will. Die Mega Treiber sind wohl auch noch nicht integriert genauso wie DRI3(ab 3.12)
Kein LLVM für den Grafikstack und damit auch kein Gallium, toll das man hier immer die aktuellste LLVM Version braucht. Damit ist vor allem Nouveau, RadeonSI derzeit nicht möglich. Schaut man sich die TODO Liste an(bei OpenBSD), hat Nouveau ohnehin keine Priorität(die Entwickler raten von der Hardware ab), FreeBSD ist ja ohnehin nicht darauf angewiesen.

Dazu noch ein Vortrag von Mgraesslin was eindrucksvoll belegt, X benutzt C, ist voller Bugs und Code der vielleicht funktioniert. Ja, nicht mal die Dokumentation scheint ordentlich gepflegt und verlinkt zu sein. 125K LOC für ein Fenstermanager wie Kwin, Grübel Dwm braucht 2K.

Und GLSL ist recht beeindruckend, scheint das es hier endlich mal in Richtung OpenGL 4 geht. Nicht nur die Features auch die Optimierungen werden immer besser.
 
Kib hat einen ersten patch fuer drm2, was es auf den Stand von Linux 3.8 heben soll.
https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052628.html
Zwischen 3.8 und 3.17 liegen auch noch Welten, aber das bringt einem immerhin schon mal weiter. Leider laeuft es noch nicht rund. Er will erst mal das soweit debuggen, das es wieder auf dem Stand der alten Version ist.

Rudimentaerer Haswell support ist auch schon drin, aber erst nach hardcoden der pipe und hinzufuegen meiner device ID hat es bei meinem Laptop funktioniert, aber nur mit vt. X konnte ich damit noch nicht starten. Allerdings arbeitet kib dran und bei den unzaehligen anderen Dingen, die er um die Ohren hat, finde ich es schon ziemlich erstaunlich ueberhaupt was zu sehen und das es an der Front weiter geht.
 
Auf die Gefahr hin, mir erboste Kommentare und Watschen einzufangen:

Da lache ich laut und fröhlich (OK, etwas gequält auch).
Ich erzähle seit 20 Jahren, was meiner Erfahrung nach eine Art Naturgesetz zu sein scheint:

Code für OS ist in der Regel von recht guter Qualität. Server, console und TUI Applikationen sind auch mehr oder weniger brauchbar. Sowie's in Richtung Audio, GUI, Graphik geht, lässt die Qualität sehr stark nach und abstruses (non-)Design greift um sich und man hat das Gefühl, so manches wurde von 14-Jährigen auf Crack "designed" und gehackt.

Und weil das nicht reicht, greift auch noch das Ferengi-Gesetz. Will heissen: Klicki Bunti lässt sich verkaufen und was sich verkaufen lässt wird mit einer Mischung aus featuritis, extreme-bloating und vendor oder Gremium lock-in kaputt gesch...

Und weil auch das noch nicht reicht, liegt, was man bei den amis "leadership nennt, als relativ ahnungslos aber mit krudem Führungsanspruch, bei linux, bei den Leuten also, die Unix nie kapier haben aber fest entschlossen sind, alles, was sich nicht via gpl verhackstücken lässt, mit Plan- und Ahnungslosigkeit in Richtung Müllhalde zu "entwickeln" und sich dabei religiös gut zu fühlen.

Ich glaube nicht, dass es ein Zufall ist, dass mit redhat ein erzkommerzielles ami-Unternehmen die Finger in so ziemlich allem tief drin hat, was stinkt. Siehe freedesktop oder systemd.

Und klar, dass die BSD's, die ja nicht mit Millionen und Millionen überhäuft werden und zudem vorm Entwickeln erst noch ausgiebig nachdenken, weit abgeschlagen zurück liegen.

So what? Was wir brauchen, läuft ja, schlimmstenfalls eben ohne hardware supported 3D und Mouse-Klicks mit Dolby surround Klicks. Und, mit Verlaub, mit jeder Menge Sicherheitsproblemen an der Backe interessiert mich Buntzeuch nur sehr, sehr nachrangig. Spätestens in dem Kontext sollte sich sowieso die Frage aufdrängen, ob Buntmist und Buntmist Treiber wirklich in den kernel oder auch nur in kernelnähe gehören. Nur am Rande: Eine der zuverlässigsten Bug-Sammlungen und ziemlich zuverlässig besch... Code? Treiber. Vor allem für Buntzeuch.

Und für Spiele kann man ja das zwangsmitgelieferte windows nutzen.

Not having up-to-date graphics support isn't a lack; it's a quality feature!
 
3.8 ist eben nicht 3.12 und damit auch kein DRI3, gelinde gesagt ist 3.8 ebenso völlig veraltet. Und wenn jede Linux Kernel Version 6 Wochen auseinander liegt, müsste man überlegen ob sich es lohnt da Zeit noch zu versenken und vorallem auf Intel 2.21 noch zu setzen oder gar was eigenes zu fahren. Verdammt nochmal ich will Auswahl und solange es noch MIT lizenzierte Treiber gibt, dann sollten die auch genutzt werden und wenn es nur 2D ist, damit die volle Auflösung ohne Nachziehen der Fenster möglich ist. Man hat doch mittlerweile genug Erfahrungen mit LLVM bei allen dreien. Wie groß ist der Aufwand mal RadeonSI und Nouveau nachzuziehen?
 
rmoe schrieb:
So what? Was wir brauchen, läuft ja, schlimmstenfalls eben ohne hardware supported 3D und Mouse-Klicks mit Dolby surround Klicks.
Zum Vergrößern anklicken....
Sollte man hier nicht bald auf den Stand von Linux kommen, so wird man in absehbarer Zeit überhaupt nichts mehr zum laufen bringen was GUI angeht. Wayland wird kommen und das noch stärker als systemd meiner Meinung. X ist völlig kaput. Das wird mit einer Macht in den Markt gedrückt. Sollte man hier nicht mitziehen, so hat man vielleicht 4-6 Jahre aber dann geht nichts mehr ohne.

Dann sind die *BSD wirklich nur noch ein ServerOS.

@darktrym
Danke für den Link :)
 
FreeBSDs Ziel ist es im Moment das sehr linuxzentrische DRM in eine Art Kasten zu sperren, der die notwendigen Schnittstellen bereitstellt. Anstatt jedes Mal komplett neu zu portieren, soll es ermöglichen, dass man nur an wenigen Stellen Änderungen vornehmen muss. Den alten 3.8-Kernel hat man genommen, da er Long-Term-Support hat es vielleicht die Chance gibt, dort auch nach inzwischen recht langer Zeit noch Aktualisierungen zu bekommen... Darüber hinaus sehe ich als Foren-Optimist die Sache allerdings auch eher schwarz:
- Wayland und / oder Mir werden kommen. Vielleicht nicht heute, aber irgendwann. Wayland an sich ist nicht mal ein Problem, denn das lässt sich wohl recht gut auf FreeBSD und damit wahrscheinlich auch auf den anderen BSDs zum Laufen bekommen. Mir allerdings ist dem Hören nach nicht mal in Ansatz portabel.
- Darunter liegt der Grafikstack, der im Moment alle 6 Monate umgebaut und alle 24 Monate neu geschrieben wird. Schon jetzt ist es den BSDs kaum möglich Schritt zu halten, in Zukunft wird es sehr wahrscheinlich noch deutlich schwerer werden. Der ganze Mist ist extrem linuxzentrisch, weitgehend undokumentiert und ständig im Fluss. Die Chancen dauerhaft mitzuhalten sind gering.
- Darüber liegen die Compositoren, zumindest Weston soll kaum portabel sein. Die alten X11 Window Manager kann man (das X11-Modul vom Wayland mal außen vor gelassen) wegschmeißen, man muss sie neu implementieren. Zu Beginn wird es daher wahrscheinlich nur die schwer zu portierenden, großen Desktopumgebungen geben, ob die kleineren Window Manager jemals nachziehen werden, ist fraglich. Nicht nur, dass damit jede Menge Vielfalt verloren geht, ein "Dann gibt es eben kein Gnome!" wird aufgrund der sehr begrenzten Anzahl Alternativen viel schwerer zu begründen sein.
Ich spiele jetzt schon mit dem Gedanken, für mein nächstes Laptop wieder auf den sympathischen Weltmarktführer aus dem sonnigen Redmont zu setzen. Ich hoffe noch es nicht zu müssen. Noch weniger hoffe ich, in 5 Jahren Windows 11 auf dem Desktop installiert zu haben. Wenn sich die Dinge allerdings so wie vermutet entwickeln, ist es zumindest nicht unwahrscheinlich.
 
foxit schrieb:
Sollte man hier nicht bald auf den Stand von Linux kommen, so wird man in absehbarer Zeit überhaupt nichts mehr zum laufen bringen was GUI angeht. Wayland wird kommen und das noch stärker als systemd meiner Meinung. X ist völlig kaput. Das wird mit einer Macht in den Markt gedrückt. Sollte man hier nicht mitziehen, so hat man vielleicht 4-6 Jahre aber dann geht nichts mehr ohne.

Dann sind die *BSD wirklich nur noch ein ServerOS.

@darktrym
Danke für den Link :)
Zum Vergrößern anklicken....

Da hast du schon recht.

Nur:

Was bitte sollen die BSDs denn machen? Den Chaoten von linux hinterherrrennen? Das wird nicht klappen, denn die haben Milliardenkonzerne (inkl. deren weniger öffentliche und manchmal gar nicht schönen Interessen) hinter sich und Gazillionen "Entwickler" und können es sich leisten, alle paar Monate größere Brocken wieder umzuwerfen.

Ich denke, der schlimmste Teil der Abhängigkeit sind die Treibergeschichten. Das ist es, was die BSDs mehr oder zwingt, sich zumindest zum Teil an Linux auszurichten. Aber das Dumme ist, dass das - wie so vieles bei linux - ein floating target ist.

Ich denke, dass auch die linuxe noch einige Jahre brauchen werden, bis das mal wirklich halbwegs fertig und überall implementiert ist. Anders ausgedrückt: Dringend ist es noch nicht. Ehe anjetzt überstürzt oder gar panisch losprescht und einige Runden nonsense mitmacht, sollte man genau beobachten, was sich da tut, ausgiebig nachdenken, wie man's besser machen und unabhängiger werden kann und dann loslegen, ein gutes Konzept umzusetzen. Und bis dahin kaben wir genau wie manche linuxe auch erst mal noch X. Ist ja nicht so, dass das demnächst abgeklemmt wird.

Mein wichtigster Wunsch ist, dass die BSDs aus der Vergangenheit lernen (sowohl aus X als auch aus linux nachrennen) und *richtig* machen, was linux fummelt.
Ich bleibe dabei. Sorgen habe ich keine. linux hat die Markt- und Firmenmacht, die Richtung zu bestimmen (und dabei haufenweise Mist zu produzieren). Und die BSD Entwickler haben das Hirn, die Kompetenz und das Können, es richtig zu machen.
 
Eventuell sollte die FreeBSD Foundation mal etwas Geld in die Hand nehmen und bei AMD/Intel anklopfen und nach einem LTS Binary Treiber anfragen.
Das ständige Linux hinterher gefrickel wird auf dauer fehlschlagen.
Der Schmerz ist leider noch nicht groß genug, das genug Entwickler bei FreeBSD am Grafikstack arbeiten.
 
Nur leider hat die FreeBSD Foundation auch nicht endlos Geld. Eine Million (im letzten Jahr kam nicht mal die zusammen) klingt viel, aber nach zwei bezahlten Entwicklern und ein paar finanzierten Projekten freier Entwickler bleibt da nicht mehr viel nach. Dann noch ein paar zehntausend Dollar für Hardware und Infrastruktur, ein paar Travel Grants und schon ist das Budget ausgereizt. Wenn man jemanden für den Grafikstack bezahlen möchte, müsste also das Budget steigen. Und ehrlich gesagt sehe ich das nicht viel Raum nach oben, es sei denn man könnte Unternehmen dazu bringen mehr Geld zu geben... Aber die wiederum haben kein Interesse an Desktop-Funktionen, lassen sich mit dem Argument kaum zu mehr überreden. Ein klassisches Henne-Ei-Problem.
 
Yamagi schrieb:
Nur leider hat die FreeBSD Foundation auch nicht endlos Geld. Eine Million (im letzten Jahr kam nicht mal die zusammen) klingt viel, aber nach zwei bezahlten Entwicklern und ein paar finanzierten Projekten freier Entwickler bleibt da nicht mehr viel nach. Dann noch ein paar zehntausend Dollar für Hardware und Infrastruktur, ein paar Travel Grants und schon ist das Budget ausgereizt. Wenn man jemanden für den Grafikstack bezahlen möchte, müsste also das Budget steigen. Und ehrlich gesagt sehe ich das nicht viel Raum nach oben, es sei denn man könnte Unternehmen dazu bringen mehr Geld zu geben... Aber die wiederum haben kein Interesse an Desktop-Funktionen, lassen sich mit dem Argument kaum zu mehr überreden. Ein klassisches Henne-Ei-Problem.
Zum Vergrößern anklicken....

Das stimmt schon, jedoch muss man ja keine 6-stelligen Summen Zahlen.
Zum anderen müssten mehr anreize für FreeBSD/Desktop geschaffen werden.

Welche Vorteile hätte also Amd/Intel davon ?
Ich sehe da den Vorteil mehr im Industriesektor (Videoschnitt / Streaming / 3D Filme / Games / HPC)
Auch wenn das eventuell schon von Windows und Linux beherrscht wird, mehr Konkurrenz belebt das Geschäft.
Dann wäre da noch die BSD Lizenz. Viele Unternehmen schätzen diese Lizenz, das wäre ein Vorteil für BSD.
 
Wayland braucht bekanntlich auch einiges an Linux Kram, im Vortrag war von evdev die Rede. Die gesamte Entwicklung bei Wayland ist sehr linuxzentrisch. Etwas eigenes zu entwickeln auf Basis des Protokolls halte ich für schwierig wenn nicht gerade viele auf den Zug mitaufspringen, Oracle wird das sicher nicht mehr tun. Letztenendes läuft das auf die gleichen Schoße ab wie bei DRM und Systemd Kram. Zudem bin ich mir nicht mal sicher ob die Treiber derzeit überhaupt OpenGL ES unterstützen.
Gallium3D wäre es sicher wert etwas Geld zu investieren, neben den genannten Treibern werden auch so exotische wie 965g und einige ARM Treiber den Kram nutzen wie der Raspberry Treiber.

Nebenbei, die Körpersprache und Rhetorik würde ich davon ausgehen, dass nicht die Kunden AMD zum Umschwenk ihrer Strategie ermuntert hat sondern, die doppelte Arbeit und damit die Kosten. Wenigstens wollen die etwas zu Mesa beisteuern. Mich würde es nicht wundern, wenn der freie Teil nach und nach entkernt wird.
 
Hab ich gerade Linux und Videoschnitt gelesen? Niemals wuerde sich ein Polohemdtragender Designer ein Linux installieren. Die benutzen ganz klassisch einen Mac.

Die BSD sind nun mal auch in der Position, das sie meistens irgendwo versteckt laufen, in einer Waschmaschine, auf irgendeinem Router, oder Storage element, aber das ist ganz klar fuer den Anwender und die meisten Admins nicht sichtbar und wollen es auch nicht sehen. Die flashen ihre Firmware (falls ueberhaupt), was fuer die eine grosse schwarze Box ist und dann ist gut. Das ist wirklich ein PR Problem, aber das ist nicht zu loesen solange keine grosse Firma sagt: Komm wir bauen unser eigenes Desktop OS und das wird denke ich nicht passieren, dafuer ist der Markt auch einfach mit Mac und Windows zu gesaettigt. Linux zaehle ich nicht mal dazu, denn das ist wirklich auf dem Desktop ueberwiegend nur im wissenschaftlichen Bereich zu finden (denen verdanken sie wohl ueberwiegend ihre 1.6 Prozent).
Hinzukommt das der Desktop auch ueberwiegend an Bedeutung bei den meisten Anwendern verliert und der Bereich im Tablet und Smartphone ist auch schon gedeckt, dank Google, sonst haetten wir Linux auch da nicht gesehen.

Ich finde ja die FreeBSD Foundation sollte nichts aendern, sondern weiter das foerdern, wo FreeBSD gut dasteht und das ist im Storage- und Netzwerkbereich. Fuer die Idealisten (ja ich bin auch so einer der FreeBSD auf dem Desktop nutzt) waere es schoen, wenn sie etwas Geld eruebrigen koennen, um den Laden einigermassen am Laufen zu halten, aber Prioritaet sollte es nicht sein, auch wenn ich es mir wuenschen wuerde. Es gibt ja durchaus immer noch Moeglichkeiten einen tauglichen Desktop ohne viel Aufwand unter FreeBSD zu bekommen, falls man nicht gerade so ein Sparbroetchen ist, und meiner Meinung nach ist das in den letzten Jahren trotz allem Gegenwind einfacherer denn je geworden.
 
Sooooo linux-abhängig ist Wayland gar nicht. Und die haben übrigens auch einige durchaus gute Ansätze.

Allerdings ist freedesktop mal wieder mit dabei. Und ergo auch xml, sogar als wesentliches Kernelement. Kein gutes Zeichen und jedenfalls technisch kläglich..

Weston ist letztlich nur ein größerer Klumpen oben drauf. Einen auf den ersten Blick übel wirkenden, auf den zweiten Block aber auch als Chance wahrnehmbaren Teil sehe ich eben im DRM Bereich, der vielen Sorge macht. Dann da könnte man wirklich andere Wege gehen. Zunächst mal ist es so, dass bei Wayland die clients oder compositing manager (von denen Weston nur 1 ist) das Rendern übernehmen. Das und der Umstand, dass FreeBSD durchaus brauchbare Grundlagen in Sachen GraKa Treibern geschaffen hat, sehe ich z.B. als einen Ansatz, eine recht ordentliche FreeBSD Wayland Version hinzukriegen. So ließe sich auch der große Brocken, bessere GPU Unterstützung zu implementieren erst mal verschieben. OK, damit wäre FreeBSD leistungsmäßig ein gutes Stück vom High-End Bereich entfernt, aber ich denke mal, dass die meisten BSDler eh nicht so grafiklastig sind; da geht es doch eher darum, dass gtk und qt wieder laufen, sprich, die üblichen GUI Desktop Applikationen weiter laufen und BSD voll einsetzbar bleibt (minus gaming, high-end Grafikkram und dergleichen).
Aber das ist in meinen Augen kein Problem, denn sowas läuft doch eh meist auf dezidierten Kisten (mit was auch immer drauf).

Nicht zuletzt muss man auch fairerweise sehen, dass nicht Wayland (das Konzept, die Technologie) ziemlich linux-zentrisch oder schlecht ist sondern die derzeitigen *Implementationen*. Ich bin ja so gar nicht der Grafik-Guru, aber mein Eindruck ist jedenfalls, dass Wayland auf BSD zu bringen nicht nur sinnvoller ist sondern auch weniger Arbeit und machbarer ist als ein "X21k". Und sinnvoller. Auch ist der Anspruch bei BSD erst mal niedriger, weil weniger Hype und weniger Multimedia und "wir können *alles*" Haltung (wie bei linux).

Ich denke, der Desktop war und ist durchaus ein wichtiger Teil von BSD, aber eben nur ein Teil und so können unsere Ansprüche und mithin der Aufwand kleiner sein.
 
Was die FreeBSD Foundation braucht sind Verkäufer - echte Verkäufer und keine Bedarfsdecker, dan klappt das auch mit den Einnahmen. Platz auf dem Desktoipmarkt für saubere Systeme auf ARBEITS-rechnern ist sicherlich da.
 
Ohne MS Office? Ohne CAD-/CAM-Anwendungen?

Wofür braucht man noch Arbeitsrechner? Oh ja, Simulationen. Ohne CUDA und OpenCL. Viel Glück.
 
Ich denke, man muss die Situation einfach mal ein bisschen abwarten und gucken, wann und ob "Linux" in eine bestimmte Richtung geht. Diesem Trend sollte man sich dann anschließen.

Irgendwas eigenes stricken ist mehr oder weniger sinnlos, wenn man sich nicht nVidia ins Boot holt. Deren Treiber sollten immer laufen und dann könnte man auch mal CUDA und so benutzen und könnte den wissenschaftlichen Bereich abdecken. Die arbeiten ja durchaus oft mit Linux! Gaming ist noch ne ganz andere Geschichte... Steam läuft unter Linux. Auch da könnte man vielleicht ansetzen.

Es ist und bleibt aber die Frage, in welche Richtung die BSDs gehen wollen. In alle Richtungen geht nicht und der Server Aspekt wird eben groß geschrieben.
 
zuglufttier schrieb:
Ich denke, man muss die Situation einfach mal ein bisschen abwarten und gucken, wann und ob "Linux" in eine bestimmte Richtung geht. Diesem Trend sollte man sich dann anschließen.
Zum Vergrößern anklicken....

Oder eben gerade nicht, IMHO lässt Red Hat das Linux, wie wir es heute kennen, volle Kanne gegen die Wand fahren.
Man sollte beobachten und bei Bedarf gegensteuern, damit BSD nicht mit ins Verderben gerissen wird.

zuglufttier schrieb:
Irgendwas eigenes stricken ist mehr oder weniger sinnlos, wenn man sich nicht nVidia ins Boot holt. Deren Treiber sollten immer laufen und dann könnte man auch mal CUDA und so benutzen und könnte den wissenschaftlichen Bereich abdecken.
Zum Vergrößern anklicken....

Hier würde ich dir prinzipiell zustimmen, nur leider unterstützt nVidia CUDA auf FreeBSD jetzt schon nicht.
Die Hoffnung stirbt zuletzt, aber ich befürchte der Marktanteil der Linuxrechner ist zu groß, als dass sie deren Blödsinn ignorieren und stattdessen auf FreeBSD setzen.

zuglufttier schrieb:
Es ist und bleibt aber die Frage, in welche Richtung die BSDs gehen wollen. In alle Richtungen geht nicht und der Server Aspekt wird eben groß geschrieben.
Zum Vergrößern anklicken....

Und das ist auch nicht schlecht, man sollte seine Kernkompetenzen nicht vergessen, siehe Microsoft, IMHO haben die in letzter Zeit Schwierigkeiten damit.
Ich halte soetwas für Risikoreich und wir werden sehen, was kommt.
 
Könnte man nicht ein driver pack für alle BSDs (außer vielleicht Mac) entwerfen und selbst unter den BSDs pflegen und weiterentwickeln, so dass man nicht mehr das ewige Leid der Portierung hätte. Das würde meiner Meinung nach nur einmal das Budget dermaßen beanspruchen, jedoch alle darauf folgende Jahre sollte das nicht mehr nötig sein.
 
Verkäufer? Seh ich nicht so. Ich sehe sowohl bei linux wie auch in Softwarefirmen, dass Verkäufer, zwar die sind, die für Einnahmen sorgen, aber auch die, die dafür sorgen, dass gebloateter featuritis Mist entsteht. Man mag mich da für ein A...loch halten, aber meiner Meinung nach sind die BSDs eben deshalb qualitativ gut, weil (und zwar erwachsene) Techniker das machen, was sie für richtig halten.

Ich teile "Desktop/Graphik" Daumen mal Pi in folgende Gruppen ein:
- A) gaming (nicht zu unterschätzen, wieviele das sind)
- B) Multimedia (semi bis voll professionelle. Nicht wenn unsereins mal n Film transcodiert)
- C) CAD/CAM
- D) "Nu je, irgendwie Gui braucht man halt"

Die ersten 3 dürften nahezu insignifikante Minderheiten auf BSD sein. Hobby- und Gelegenheitsgamer sind mit dual boot versorgt. Hardcore gamer dürften von BSD eh gelangweilt sein. Multimedia ist sogar nicht meine Welt, da hab ich wenig Ahnung, aber soweit ich das mitbekommen habe, sind das weitgehend Apple Kunden. Was übrigens gut für uns sein kann, weil es heisst, dass nicht nur die freien BSDs das Problem haben, Treiber für das nötige Equipment zu haben. Und vom Apple OS zu BSD ist es ja wohl nicht so weit. CAD/CAM läuft, soweit ich das mitbekommen habe, wohl weitgehend auf windows oder vielleicht noch Apple oder linux.

Und D) sind wir, so wie ich den Großteil von uns sehe. Also Leute, die im beruflichen Umfeld zuverlässige Maschinen brauchen, sei es für server, Entwicklung, etc. Ein Gui brauchen wir, weil man halt auch auf seiner Alltags- oder Schreibtischkiste gerne sein BSD und gängige Software haben will. Bei meiner GraKa war mir wichtig, dass sie lüfterlos ist und dass sie leidlich flott ist - nicht wegen Desktop sondern wegen 2 mal im Jahr n langes Wochenende gamen oder hie und da mal n movie transcoden, wobei zum Spielen windows via dual boot zum Einsatz kommt.
Anders ausgedrückt: Für das, was geschätzte 98% der BSDler brauchen (im Sinne von "das muss sein, ohne geht's nicht gut"), reicht eine Graka von 1995. Nur etwas wie X (iegitt) oder Wayland (schon deutlich besser, wenn's mal ans Laufen kommt) muss halt noch sein. Und da habe ich keine Sorge. Wayland selbst scheint durchaus portierbar zu sein und wenn Weston ein Drecksack ist, so what? Die Enlightenment Leute haben auch einen compositing manager entwickelt. Ich sehe erst mal keinen Grund, warum BSD das nicht auch können sollte; vielleicht halt nicht gut genug für die A-C Leute, aber allemal gut genug zum surfen, gtk und qt Anwendungen, also die Brot und Butter Sachen, die wir wirklich brauchen.
 
bofh_hannibal schrieb:
Das stimmt schon, jedoch muss man ja keine 6-stelligen Summen zahlen.
Zum Vergrößern anklicken....

Stimmt, 6-stellig wird in Summe von hinten bis vorne nicht reichen. Die entsprechenden Leute sind gefragt und haben ordentliche Stundensätze.

Selbst wenn man das Geld zusammenkriegen würde: wäre es an anderer Stelle nicht sinnvoller eingesetzt?

goblin schrieb:
Und das ist auch nicht schlecht, man sollte seine Kernkompetenzen nicht vergessen, siehe Microsoft, IMHO haben die in letzter Zeit Schwierigkeiten damit.
Zum Vergrößern anklicken....

Die Technical Preview von Windows 10 lässt vermuten, dass sie sich wieder besonnen haben (z.B. klassisches Startmenü).
Notiz am Rande: unglaublich aber wahr und eine wahnsinnige Neuerung für Windows-Anwender, es beherrscht virtuelle Desktops! ;)

spectre210 schrieb:
Könnte man nicht ein driver pack für alle BSDs (außer vielleicht Mac) entwerfen und selbst unter den BSDs pflegen und weiterentwickeln, so dass man nicht mehr das ewige Leid der Portierung hätte. Das würde meiner Meinung nach nur einmal das Budget dermaßen beanspruchen, jedoch alle darauf folgende Jahre sollte das nicht mehr nötig sein.
Zum Vergrößern anklicken....

Wie Yamagi schon geschrieben hat, dafür müsste man Unsummen in die Hand nehmen (die man nicht hat). Nicht nur einmal; bei jeder neuen Generation Grafikkarten.
 
Das ist nicht ganz richtig. Bspw. könnte AMD sein Interface so bauen, dass der Unterteil stabil ist und nicht wieder mit jeder Kernelversion bricht. Da tauscht man nur den oberen Teil aus, für AMD wäre das ohne Mehrkosten verbunden zus. noch FreeBSD mit dem prop. Treiber zu versorgen. Ich würde nicht behaupten dass sich derzeit AMDs Strategie auszahlt. Will man performante und brauchbare Hardware kommt man nicht an Nvidia vorbei, trotz CSS. Will man frühen Support und eine gewisse Planbarkeit eben Intel. Die Leute denen Image und Preis über allem steht(große Schnittmenge mit Android Nutzern ;)) nehmen AMD trotz besseren Wissen. Nvidia fährt damit ganz gut, würde mich nicht wundern wenn sie dafür bezahlt werden Solaris und FreeBSD zu unterstützen, sehr kostengünstig die gesamte Entwicklung.
An den Grundproblem ändert es aber nichts. Es ist teuer und kurzfristig gedacht einmal die Entwicklung anzustoßen. Entweder baut man einen eigenen DRM Zweig auf und bündelt die geringen Resourcen oder investiert das Geld breitflächig in die Köpfe. IT Consultants zu bezahlen und funktional aber ohne Maintainer einen Treiber zu hinterlassen sind zum scheitern verurteilt. Wo stehen denn die BSDs(FNO) derzeit, jeder hat eine unterschiedliche Version(3.4, 3.14, 3.8) von DRM bei jeden sind es vielleicht 2 Personen die sich damit beschäftigen und jeder aktualisiert sein Intel Treiber von neuem.
Und an die Machbarkeit eine Komp.-Schicht zweifle ich auch. Man sollte mal schauen wie breit Linux DRM aufgestellt ist von den Architekturen, wie oft grundlegende Änderungen vorgenommen werden. Vielleicht erinnert sich wer noch an den Vortrag über Security DRM und Wayland/X, viel hat sich da auch nicht getan. Unmöglich dass das Design ein Jahr überlebt, wir reden ja nicht von kleinen Änderungen, eine Unterstützung von DMA-BUF könnte das Design schon wieder zerstören.
 
Eine gemeinsame Treiberentwicklung zwischen den BSDs kann man vergessen. Das Kind ist in der Vergangenheit gleich zweimal in den Brunnen gefallen und inzwischen ist es viel zu spät es wieder herauszuziehen:
  • Bereits Mitte der 90er entschloss sich NetBSD das Virtual Memory Subsystem neuzuschreiben, während FreeBSD das niemals vollständig in 4.4BSD integrierte MACH-VM weiterentwickelte. Beide hatten dafür gute Gründe, aber damit war dann auch gleich der erste tiefe Riss aufgebrochen. In Sachen Virtuellen Speicher sind NetBSD und OpenBSD zu FreeBSD und DrangonflyBSD heute weitgehend inkompatibel. Was alles, was direkt mit dem VM interagieren muss, nur schwer portabel macht. DRM ist einer dieser Kandidaten.
  • FreeBSD ging ab 1999 seinen SMPng-Weg und baute den Kernel grundlegend um. NetBSD zog später nach, baute ebenfalls um, wählte aber einen weniger invasiven Weg. DragonflyBSD hatte ganz eigene Vorstellungen. OpenBSD blieb recht klassisch. Durch diese Entwicklung divergierten die Kernel enorm. Beispielweise ist der Weg eines Treiber von OpenBSD zu FreeBSD heute kaum einfacher als von Linux zu FreeBSD.
Was man bräuchte, ist eine klare Schnittstelle nach unten, an welche Treiber andocken. Dazu eine klare Schnittstelle nach oben, die Treiber bereitstellen müssen. Eben genau das, was Windows macht. Das Problem dabei ist nur, dass Unix mit seinem streng monolithischem Aufbau einfach nicht genügend Architektur dafür hat. Einige Unix-Dialekte haben stabilere APIs (die BSDs) und einige instabilere (Linux), aber allen ist gemeinsam, dass theoretisch jeder Code im Kernel auf jede Funktion zugreifen kann und der Erfahrung nach auch tut. Weshalb jede Änderung an einem beliebigen Ort diversen Code brechen kann. Die einzige Lösung dafür ist, dass man einen definierten Teil der Kernel-Funktionen versucht stabil zu halten. Aber das ist bei weitem nicht alles, da man für alles dann Wrapper benötigen würde... Wie weh schon dieser definierte Teil tut, sieht man gut an den regelmäßigen Diskussionen auf z.b. FreeBSDs svn-src-all@ im Stil von "Würdest du BITTE auf die Kompatibilität achten und nicht nur einfach losfrickeln?!".

Vor diesem Hintergrund tut es mir auch bis heute weh (obwohl ich damals noch nicht mal wusste was ein Computer ist), dass Linus Anfang der 90er nicht hören wollte, als man versuchte zu verdeutlichen, dass monolithische Kernel bei weitem nicht der Weisheit letzter Schluss sind. Denn er hätte anders als wir BSDler die reale Möglichkeit gehabt es besser zu machen. Es verlangte ja niemand einen echten Mikrokernel, nur eine am damals gerade entstehenden Windows NT orientierte Architektur wäre umsetzbar gewesen und würde uns allen heute einiges an Schmerzen ersparen. Der eigentliche Kernel wäre schlank und in Ring0, die ganzen Frameworks und Treiber würden darüber in Ring1 und Ring2 schwimmen. Dadurch gäbe es eine klare Trennung der Zuständigkeiten, es würde nicht alles mit allem Zusammengreifen, man könnte viel einfacher saubere Schnittstellen implementieren und so weiter. Aber nein, man musste ja unbedingt das schon an die 25 Jahre alte Unix-Design nehmen...
 
So eine Schnittstelle wie Apple's I/O-Kit hälst du also für nicht realisierbar? Es muss ja nicht gleich C++ sein… ;)

Disclaimer: Ich hab keine Ahnung wie das tatsächlich aussieht, ich besitze keinerlei Apple-Produkte. Ich habe nur mal deren Architektur gesehen und fand das so ganz interessant.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben