XDC2014 - Quo vadis

[CrimsonKing]

er hätte anders als wir BSDler die reale Möglichkeit gehabt es besser zu machen

Aber DragonFly BSD tut doch genau das, oder?

Ein Mikrokernel scheint andererseits eine von der Zahl der Entwickler unabhängige Komplexität zu besitzen, wenn man mal auf HURD guckt. Vielleicht besser so.

 

[CrimsonKing]

unglaublich aber wahr und eine wahnsinnige Neuerung für Windows-Anwender, es beherrscht virtuelle Desktops!

Eine Neuerung war das seit den 90ern schon nicht mehr. Anders als unter *ix kommt das unter Windows 10 aber als Systemteil und nicht als reingefrickelte Drittanbietersoftware.

 

[Yamagi]

Echte Mikrokernel sind theoretisch eine tolle Sache. Praktisch haben sie aber eine ganze Reihe Probleme, die man nie so wirklich in den Griff bekommen hat. Der Kernel setzt sich dort aus diversen Services zusammen, die für sich komplett eigenständig arbeiten, aber ineinander greifen und orchestriert werden müssen. Simpel gesagt zieht es eine Unmenge Schnittstellen nach sich, was die Komplexität explodieren lässt. Außerdem sind diese Schnittstellen (kopieren der Daten zwischen Privilegstufen, einzelnen Prozessen und so weiter) oftmals bedeutend langsamer als direkte Funktionsaufrufe.
In praktisch eingesetzten, bzw. nicht akademischen Kernel findet sich daher - wenn überhaupt - ein hybrider Ansatz. Ein monolithischer Kernel, der die performancekrititsche Basisfunktionalität bereitstellt. Weitere Funktionalität wird dann als große Blöcke auf den Ebenen darüber implementiert. Bei Windows beinhaltet ntoskrnl.exe als "echter" Kernel zum Beispiel virtuelle Speicherverwaltung, das virtuelle Dateisystem und so weiter. Der Grafikstack war in NT3 ein eigener Dienst auf Ring1(?), anschließend aus Performancegründen in Windows NT4 bis einschließlich XP innerhalb des eigentlichen Kernels, um nach diversem technischen Fortschritt mit Vista wieder herausgelöst zu werden.

Zu XNU kann ich kaum etwas sagen, ich habe mich nie damit beschäftigt. Aber meinem Verständnis nach ist IoKit eine große Abstraktionsebene, welche die MACH- und BSD-Schnittstellen des eigentlichen Kernels auf eine generische Schnittstelle abstrahiert und laut Wikipedia auch aus dem Userland zugreifbar macht. Natürlich kann man sowas für BSD oder Linux bauen. Aber man würde sich halt einen riesigen Batzen Code einhandeln, der oben über dem Kernel liegt und durch längere Call-Pfade die Performance beeinflusst. Und es ist ganz sicher nicht trivial die Eigenheiten der Systeme zu verdecken. Alle Eingaben in den Layer müssten auf die systemeigenen, internen Strukturen gewandelt werden.
Was ist mit Features, die nicht alle Systeme haben? FreeBSD hat z.B. Capsicum, Linux hoffentlich auch bald. NetBSD und OpenBSD aber noch nicht. Umgekehrt gibt es unter Linux SeLinux, aber unter FreeBSD MAC. Im Ziel ähnlich, aber komplett anders konzeptioniert. Man würde als zwangsläufig die gemeinsame API unterteilen müssen, sei es durch Feature Level, Plugins oder was auch immer. Das tut aber wiederum der Komplexität ganz und gar nicht gut... Pragmatischer (aber auch nicht umsetzbar) fände ich daher, wenn Linux als Platzhirsch einfach eine Treiber-API definieren würde und alle anderen implementieren sie so weit wie möglich, mit eigenen Features angereichert. Dann wäre Code zwar nicht per Copy and Paste portabel, aber der Portierungsaufwand würde schon mal deutlich sinken.

 

[bofh_hannibal]

Echte Mikrokernel sind theoretisch eine tolle Sache. Praktisch haben sie aber eine ganze Reihe Probleme, die man nie so wirklich in den Griff bekommen hat. Der Kernel setzt sich dort aus diversen Services zusammen, die für sich komplett eigenständig arbeiten, aber ineinander greifen und orchestriert werden müssen. Simpel gesagt zieht es eine Unmenge Schnittstellen nach sich, was die Komplexität explodieren lässt. Außerdem sind diese Schnittstellen (kopieren der Daten zwischen Privilegstufen, einzelnen Prozessen und so weiter) oftmals bedeutend langsamer als direkte Funktionsaufrufe.
In praktisch eingesetzten, bzw. nicht akademischen Kernel findet sich daher - wenn überhaupt - ein hybrider Ansatz. Ein monolithischer Kernel, der die performancekrititsche Basisfunktionalität bereitstellt. Weitere Funktionalität wird dann als große Blöcke auf den Ebenen darüber implementiert. Bei Windows beinhaltet ntoskrnl.exe als "echter" Kernel zum Beispiel virtuelle Speicherverwaltung, das virtuelle Dateisystem und so weiter. Der Grafikstack war in NT3 ein eigener Dienst auf Ring1(?), anschließend aus Performancegründen in Windows NT4 bis einschließlich XP innerhalb des eigentlichen Kernels, um nach diversem technischen Fortschritt mit Vista wieder herausgelöst zu werden.

Ob Microkernel oder nicht, eine funktionierene Portable Lösung der Grafikkartentreiber muss doch möglich sein.
Bei den Netzwerkkartentreibern funktioniert es doch auch (zumindest Teilweise) (oder kommt mir das nur so vor ?).
Ich steck leider nicht so tief in der X11/GL Programmierung, aber wieso setzten sich die Entwickler nicht zusammen hin und entwickeln ein Konzept was sowohl f. Linux als auch f. andere Unix(-ähnliche) Systeme funktioniert. Und wenn es erstmal nicht so performant ist (Userspace).

Ich vermute sowieso das in >10 Jahren niemand mehr einen Desktop haben wird.
Weil:
- Software virtualisiert in VMs/Containern nur noch läuft unter Linux / Windows
- 2D/3D Software nur noch gestreamt werden über die Cloud (wie vielleicht dann jede Software)
- Es möglich sein wird, Boot over WAN zu haben, bzw.: Nur noch ein Browser+minimal OS brauchen.
- Redhat es schafft einen Vendor Lock in Linux zu bringen und damit X und co. kontrolliert (siehe Systemd).

 

[foxit]

...wieso setzten sich die Entwickler nicht zusammen hin und entwickeln ein Konzept was sowohl f. Linux als auch f. andere Unix(-ähnliche) Systeme funktioniert.

Weil es die Linux- Entwickler einen Scheiss interessiert, was auf anderen Systemen benötigt wird oder verlangt wird.

 

[rmoe]

... allen ist gemeinsam, dass theoretisch jeder Code im Kernel auf jede Funktion zugreifen kann und der Erfahrung nach auch tut.
... monolitisch vs weniger monolitisch ...

Ja!

Treiber sind bekannermaßen Drecksäue. Nirgendwo sonst gibt es so schlechten code, vor allem im kernel.
Das mit dem Aufsplitten könnte aber auch BSD, wenn auch mit einigem Aufwand. Das Miese bei Treibern ist das produktspezifische Know-How - aber das haben wir mittlerweile und können es notfalls auch bei linux Treibern nachsehen. Der andere Teil ist de von dir angesprochene, nämlich letztlich die Rechte-Frage (wer darf was und wieviel?).
Die ist bei Microkerneln brutal und elegant gelöst, indem der Treiber komplett im userspace läuft und lediglich einige Sonderrechte hat, die ihm ermöglichen, den kernel mit lowest level jobs zu beauftragen bzw. via zero copy interfaces effizient Daten zu verschieben.
Aber das könnten auch BSDs, wenn auch weniger brutal. Und dabei könnten die BSD trotz aller Unterschiede in den Innereien (VM, ...) sich auf eine gemeinsame Schnittstelle in Richtung treiber-userspace einigen. Na ja, theo-(de R.)-retisch *g

 

[Azazyel]

Ob Microkernel oder nicht, eine funktionierene Portable Lösung der Grafikkartentreiber muss doch möglich sein.

Natürlich, mit einer - aus dem Bauch heraus geschätzt - ordentlich zweistelligen Anzahl Mannjahre könnte man vielleicht etwas Ausbaufähiges auf die Beine stellen. Das Risiko, das dabei gar nichts rauskommt, ist allerdings relativ hoch.

Welchen Anteil der benötigten paar Millionen Euro trägst du bei?

Ich steck leider nicht so tief in der X11/GL Programmierung, aber wieso setzten sich die Entwickler nicht zusammen hin und entwickeln ein Konzept was sowohl f. Linux als auch f. andere Unix(-ähnliche) Systeme funktioniert. Und wenn es erstmal nicht so performant ist (Userspace).

Wie Yamagi schon beschrieben hat, sind im fraglichen Bereich die Unterschiede zwischen den Betriebssystemen gewaltig. Wie soll das Konzept aussehen, das diese Unterschiede unter eine Haube bringt? Das ist kein triviales Problem, wenn es denn überhaupt möglich ist.

Selbst wenn es möglich sein sollte: wer soll das deiner Meinung nach organisieren, koordinieren, finanzieren und die laufend notwendigen Anpassungen sicherstellen?

Ich vermute sowieso das in >10 Jahren niemand mehr einen Desktop haben wird.

Mit Prognosen über die Zukunft wäre ich vorsichtig. Bedenke, wie du dir vor zehn Jahren die Welt im Jahre 2014 vorgestellt hast und wie wenig davon eingetroffen ist.

Weil es die Linux-Entwickler einen Scheiss interessiert, was auf anderen Systemen benötigt wird oder verlangt wird.

Entwicklerkapazität ist begrenzt; Portabilität bedeutet in diesem Fall zusätzlichen Aufwand und Komplexität. Wenn du als Hersteller oder Entwickler die Wahl hättest, mit den vorhandenen Resourcen entweder

• einen passablen Linux-Treiber oder
• einen unbrauchbaren portablen Treiber

zu entwickeln - wie würdest du dich entscheiden?

 

[abeginner]

Hab ich gerade Linux und Videoschnitt gelesen? Niemals wuerde sich ein Polohemdtragender Designer ein Linux installieren. Die benutzen ganz klassisch einen Mac.

Klar, in der Regel ist das so. Doch, da wären ja Cinelerra & Lightworks welches sich ja auf dem Sprung zu OpenSource befindet. Hinsichtlich Videoschnitt sind mindestens so potente - wenn nicht gar noch mächtigere - Programme als GIMP für die Fotografie, aber seitdem LightZone nun auch OpenSource ist, hat GIMP (zumindest technhisch, aber leider nicht "mainainerisch" ) mächtig Konkurrenz bekommen.

Bezüglich der Treiber ist's bestens nachvollziehbar. Immerhin geht's darum ob verbaute Hardware angesprochen & genutzt werden kann.
Ich frag' mich aber oft, weshalb dieses Problem in erster Linie ausgerechnet Grafikkarten betrifft.

Bisher hatte ich offenbar mit all meinen Geräten offenbar Glück.
Ok, da steht in meiner Openbsd dmesg soetwas wie drm radeon ring test failed und es folgen ein paar weitere error-Meldungen bezüglich Radeon. Aber irgendwie funktioniert's dann halt doch.

Manchmal frage ich mich aber auch um die Ansprüche von Nutzer unixoider OS (mit Ausnahme OS X, versteht sich). Geht's vornhemlich darum, einen chicen Desktop zu haben?
Der Vorteil von X ist halt auch wiederum der Nachteil. Zu wenige Entwickler für zu viele Ansprüche die dann in viele Projekte münden. Schlussendlich hat dann so jedes OS-Projekt so seine Ausrichtung, seine Rezeption.
Bei Linux wo unter GPL massiv viele Projekte schlussendlich im jeweiligen OS/Distri irgendwie zusamenkommen müssen, beginnt's halt nun mal mit einer zusehends ausgeprägter Monopolisierung . vorsichtiger ausgedrückt - Standardisierung. systemd wäre da so ein Fall.

Aber wie sieht's in der Praxis - also mal ganz ausserhalb cooler & chicer Desktops aus die zudem noch flüssig laufen? Also den grafischen Anwenderprogrammen?
Eher düster würde ich meinen - und das gilt ebenso für Platzhirrsche wie RedHat/Fedora, Ubuntu, Debian, OpenSUSE und wie sie alle heissen.
Denn auch bei all diesen hinken Treiber für entsprechende Geräte und auch Akualisierungen hinter her.
RAW-Code für einigermassen aktuelle Kameras? Treiberunterstützung für umgekehrt alte SCSI -Scanner?
Einbindung auf ArgyllCMS gestützte Monitorkalibrierung oder das ewige Maleur mit Cups?
Ok, es gibt ein paar mehr Anwenderprogramme als für die BSD's, aber für jene die Code auch direkt aus den Port's holen, dürfte da der Unterschied nicht allzugross sein. Auch OpenBSD und PC-BSD erkannten meinen Nikon Coolscan, für beide gäbe es binär GIMP & argyllCMS. Aber was nützt das ohne anständiges ScanProgramm, von welchen es aber auch für Linux gerade mal nur eines - und zudem nicht mal kostenlos, geschweige openssource ist.

Die Vielfältigkeit an opensource darf nicht darüber hinwegtäuschen, dass bei sehr komplexen Anwendungen sowieso mal schnell die Gefahr der Monopolisierung besteht - ganz generell und daher auch für die proprietären OS.
Ob es also nur an den technischen Unterschieden der BSD's und insgesamt unixoider OS liegt?
Alleine schon daher, dass die sogenannte "Free Software Foundation" eher ein GPL -und PinguinSprachrohr als tatsächlich generelles für OpenSource veranlasst mich zur Vermutung, dass diesbezüglich etwas verpasst wurde.

Die gut 25jährige Phase der Desktop-Hochkonjunktur neigt sich allmählich dem Ende zu. Die Augen sind auf MobileDevices gerichtet und auf mit HomeEntertainment verknüpfte Geräte. WLan verindet . . .
Auch den Proprietären stellen sich damit Probleme - die sie natürlich "Herausforderungen" nennen.
Aber damit auch den Hersteller "konventioneller" PC's/Laptops bzw deren Zulieferer um die es hier ja teilweise geht.
Da mag ein augestreckter Mittelfinger vom Pinguin-König natürlich spektakulär anmuten. Aber langfristig wird das nur dann wirkungsvoll sein, wenn es diesbezüglich eine gemeinsame Koordination der Betreffenden gibt.
Von den RotHut Indianern bis hin zu GNU/GPL Chefetage.
Ich finde, gerade in der sich nun abzeichnenden Entwicklung hätte man mehr Argumente als "Die Welt ist schlecht", um den Geräteherstellern etwas abzuverlangen. Und je gemeinsamer das geschieht, desto weniger Konkurrenz unter den verschiedenen OS Projekten wäre künftig auch zu befürchten.

 

[rmoe]

Vielleicht bin ich blauäugig, aber ich sehe es optimistischer.

Immerhin müssen es ja nicht nur bezahlte Entwickler sein. Gerade die BSDs haben, ob man das nun für erfreulich oder traurig hält, doch viele Profis, die benevolent und kostenfrei mit arbeiten. Eine weitere Erleichterung sehe ich darin, dass, ein gutes Konzept vorausgesetzt, schon vieles BSD-übergreifend gemeinsam und so mit verteilter Last gemacht werden kann.

Und auch die Situation ist eine andere als früher, wo man bei jedem Hersteller betteln, kämpfen oder tricksen, oder eben mit irrem Aufwand reverse engineeren musste. Wir haben heute im wesentlichen 3 Player (intel, AMD, nvidia) und reichlich Doku und Code zum nachsehen, würden das Thema also unter erheblich besseren Umständen als früher angehen.

Ich hoffe, dass die BSDler sich auf ihre Stärke besinnen, eben nicht jede Zuckung der Woche bei linux mitzumachen, sondern sich hinzusetzen und das Thema professionell und besonnen anzugehen.

Wir müssen weder (professionelles) CAD/CAM unterstützen, noch high-end Multimedia, noch gaming, zumindest nicht gleich und nicht zentral. Was wir brauchen ist ein sinnvolles, anbaufähiges Konzept, das uns "Alltagsgraphik" ermöglicht. Wenn das anfangs ohne GPU Unterstützung ist, so what. Und auch in Wayland sehe ich eher eine Gelegenheit als eine große Hürde; der irrwitzige Aufwand, X mit all seinen Marotten, Exotismen und seltsamen Ecken durchzuschleppen ist schlicht nicht mehr vertretbar.

Nicht zuletzt: Das Ganze ist ja kein optionaler Schnickschnack sondern unumgängliche Notwendigkeit.

 

[foxit]

Entwicklerkapazität ist begrenzt; Portabilität bedeutet in diesem Fall zusätzlichen Aufwand und Komplexität.

Das ist richtig aber ich denke dies muss ein Hersteller wohl gewillt sein zu bezahlen, möchte er diesen Vorteil, auf mehreren OS Nutzen zu ziehen haben.

 

[abeginner]

Das ist richtig aber ich denke dies muss ein Hersteller wohl gewillt sein zu bezahlen, möchte er diesen Vorteil, auf mehreren OS Nutzen zu ziehen haben.

Mh, da fragt sich mir : wie hoch steht der Entwicklungsaufwand mehrere Treiber zu schreiben in Relation der gesamten Entwicklung eines Geräts?

 

[Azazyel]

Immerhin müssen es ja nicht nur bezahlte Entwickler sein. Gerade die BSDs haben, ob man das nun für erfreulich oder traurig hält, doch viele Profis, die benevolent und kostenfrei mit arbeiten.

Offensichtlich hat man aber nicht genug unbezahlte Entwickler, die dieses Feld beackern können oder wollen.
Sonst sähe die Situation heute anders aus.

Eine weitere Erleichterung sehe ich darin, dass, ein gutes Konzept vorausgesetzt, schon vieles BSD-übergreifend gemeinsam und so mit verteilter Last gemacht werden kann.

Wie Yamagi schon geschrieben und ich schon einmal zitiert habe - viel Last lässt sich nicht verteilen, der Großteil der Arbeit findet an Stellen mit massiven Unterschieden statt.

Wir müssen weder (professionelles) CAD/CAM unterstützen, noch high-end Multimedia, noch gaming, zumindest nicht gleich und nicht zentral.

Die mangelnde Unterstützung sorgt aber dafür, das die BSDs insgesamt als Desktop-OS unattraktiv sind. Der daraus resultierende geringe Marktanteil sorgt auch dafür, dass nicht einmal die elementare Unterstützung von neuen Grafikkarten ordentlich klappt (siehe unten).

Machen wir uns keine Illusionen: hätte Nvidia nicht schon vor eineinhalb Jahrzehnten die Grundlagen für breiten *nix-Support im Treiber gelegt - als der Unix-Markt noch anders aussah -, es sähe auch für FreeBSD dort heute schlecht aus.

Wäre Linux nicht traditionell auf dem HPC-Markt schon so stark gewesen, als die GPUs dort aufkamen, sähe es auch für Linux im Bezug auf GPUs insgesamt deutlich schlechter aus.

Und auch in Wayland sehe ich eher eine Gelegenheit als eine große Hürde; der irrwitzige Aufwand, X mit all seinen Marotten, Exotismen und seltsamen Ecken durchzuschleppen ist schlicht nicht mehr vertretbar.

In der aktuellen c't ist ein guter Artikel zum Thema, was die katastrophale Architektur von X11 für Winkelzüge erfordert.

Mh, da fragt sich mir : wie hoch steht der Entwicklungsaufwand mehrere Treiber zu schreiben in Relation der gesamten Entwicklung eines Geräts?

Ich würde die Frage umgekehrt aufziehen: was müsste es bringen, dass sich die professionelle Treiberentwicklung für den Hersteller lohnt?

Rechnen wir es mal exemplarisch an AMD durch. AMD verkauft 2014 hochgerechnet etwa 20 Millionen Grafikkarten (Desktops und Laptops), APUs nicht mitgerechnet.

Die BSDs haben am Desktop 0,01% Marktanteil, d.h. statistisch wandern 2.000 dieser Grafikkarten in BSD-Desktops. Rechnen wir mal großzügig, aufgrund der neuen Treiber würden mehr BSD-Anwender AMD- statt Nvidia-Grafikkarten kaufen und diese Zahl würde sich verfünffachen und auf 10.000 pro Jahr hochschnellen.

Gehen wir jetzt mal von unrealistisch niedrigen 2 Millionen EUR pro Jahr aus für Entwicklung, Test, Qualitätssicherung, Support und sonstige Kosten. AMD müsste pro verkaufter Grafikkarte 200 EUR Profit (nicht Umsatz) machen, nur damit es kein Verlustgeschäft wird.

Man kann sich die ganze Angelegenheit jetzt natürlich noch mit den üblichen Verdächtigen wie Grenzkosten, Synergieeffekten und dergleichen etwas schönrechnen. Leider sind BSD-Anwender bei den lukrativen Geschäftsfeldern - Zocker und professionelle CAD-Anwender - hoffnungslos unterrepräsentiert, so dass bei den zusätzlich verkauften Exemplaren wohl fast nur Low-End-Modelle mit geringer Marge dabei wären.

Fazit: solange der Marktanteil der BSDs so niedrig ist, wären professionell gepflegte Treiber für AMD ein Verlustgeschäft.

 

[CrimsonKing]

Ach, die c't. Die Linuxautorin dort ist ein Fangirl sondergleichen. In der aktuellen c't ist eine Rezension zu OpenMandriva, in der ungefähr steht: "Das Adminzentrum ist - typisch für KDE - unklar und uneinheitlich. Fazit: Maximale Anwenderfreundlichkeit, unbedingt benutzen!!1". Und ihr letzter Artikel dazu - "Sie sollten alle Linux nutzen", fast wörtlich zitiert - war keineswegs besser.

 

[Azazyel]

Ach, die c't. Die Linuxautorin dort ist ein Fangirl sondergleichen. In der aktuellen c't ist eine Rezension zu OpenMandriva, in der ungefähr steht: "Das Adminzentrum ist - typisch für KDE - unklar und uneinheitlich. Fazit: Maximale Anwenderfreundlichkeit, unbedingt benutzen!!1". Und ihr letzter Artikel dazu - "Sie sollten alle Linux nutzen", fast wörtlich zitiert - war keineswegs besser.

Sofern der Autor des Artikels - Thorsten Leemhuis - nicht vor kurzem eine Geschlechtsumwandlung hatte und seinen Namen geändert hat, dürfte das den Artikel nicht tangieren.

 

[CrimsonKing]

Nee, ich meinte die andere, die mit der Rezension.

Es geht der c't nicht mehr um Informationen, es ist bloßes Buzzwordbingo.

 

[abeginner]

Ich würde die Frage umgekehrt aufziehen: was müsste es bringen, dass sich die professionelle Treiberentwicklung für den Hersteller lohnt?

Ok, verstehe

Und danke der Ausführung.


Ich frage mich da einfach : wird in diesen Konzernen denn nicht auch mit Systemen wie Linux & eben BSD's gearbeitet?
Kann mir kaum vorstellen, dass in solch' grossen Konzernen nicht das notwendige KnowHow bestände.

Und eben : wie viel macht die Entwicklung eines Treiber's im Verhältnis zur gesamten technischen Entwicklung eines Geräts - und hier im speziellen einer Grafikkarte - aus?
Ich meine, die kennen doch ihre Geräte bis auf's Molekül. Einen Treiber zu schreiben wenn man das Gerät doch bis auf's letzte Bitchen kennt, wird ja wohl keine nennenswerte Investitionssummen verschlingen. Da wird wohl selbst ein BusinessClass Flug eines Managers nicht teurer sein.

Und es fragt sich mir : wie wird das bei den proprietären Hesteller gemacht? Zum Beispiel Apple.

 

[rmoe]

Ich bin da zuversichtlicher als manche. Zum Teil wohl auch, weil ich manche Faktoren anders gewichte oder überhaupt (als relevant) sehe.

Zunächst mal ist es ja so, dass bei (jedenfalls nicht trivialen) Treibern das Gros der Arbeit nicht im OS spezifischen Teil liegt. Dazu kommt, dass wir heute zu den meisten Sachen eine ganze Menge Infos haben, sei es, weil Hersteller einsichtiger sind oder sei es dank linux. Wenn ich mich nicht sehr irre, war das Problem bei linux (schon) damals nicht ein Mangel an Entwicklerzeit sondern einer an Infos, der irrwitzigen reverse-engineering Aufwand mit sich brachte und mitunter auch rechtliche Probleme.

Aber auch in Sachen Entwicklerzeit bin ich gelassener als viele. Weil die bei weitem weniger das Problem sein dürfte als etwas anderes, nämlich das, was amis "leader" nennen. Als Linus anfing hatte der ja auch nicht massenhaft Entwickler um sich. Obwohl sie ja offensichtlich existierten und auch offensichtlich die Bereitschaft hatten, (teils erhebliche) Teile ihrer Freizeit einzubringen.
Der Schlüssel ist etwas anderes, nämlich eben ein leader. Denn die sind es, die "anstecken" und verführen und Leute dazu bringen, sich fleissig mit einzubringen. Entscheidend sind da Faktoren wie Vision, technische Kompetenz, ein gutes Gespür für richtig und falsch. Auch Wayland fing als Vision eines Überzeugungstäters an.

Es gab damals Abertausende, auch viele Profis, die prinzipiell bereit waren, sich einzubringen und es gibt sie heute. Wir, die BSDler werden aus einer suboptimalen Position anfangen, weil nicht wir es waren, die die brauchbare und plausible X Alternative ersonnen und konzipiert - und damit viele Kollegen angesteckt - haben, sondern als me-too und später sogar unter schierem Druck *mit*laufen.
Der Zug ist also abgefahren. Was aber noch in unserer Hand liegt ist, ob wir nun fachlich kompetent, besonnen, aber auch attraktiv konzeptionieren und agieren oder ob wir weiter Gründe dafür nennen, warum das alles, hach, irgendwie unschön ist ... bis zu dem Punkt, wo wir später unter großem Druck "irgendwie portieren" müssen.

Oder wir können auf Millionenspenden warten ... und warten ... und warten.

Ein Anfang wäre es, sich mal zu entscheiden, *was* wir eigentlich wollen. Muss es auch (von Anfang an) hardwareunterstützt Multimedia, gaming und sonstnochwas können oder ist uns ein langfristig tragfähiges Konzept wichtiger, auch wenn BSD-wayland erst mal nur Desktop/Alltag kann?

Einen Trost habe ich noch: Die Faustregel nämlich, dass Software mit starker Tendenz beschi** und schwachsinnig designed wird, wenn Buntleute das Sagen haben. Wir haben bei FreeBSD viele sehr fähige und kompetente Leute und mithin eine wichtige Voraussetzung, um etwas wirklich gut erdachtes und gemachtes zu machen.

 

[Azazyel]

Ich frage mich da einfach : wird in diesen Konzernen denn nicht auch mit Systemen wie Linux & eben BSD's gearbeitet?
Kann mir kaum vorstellen, dass in solch' grossen Konzernen nicht das notwendige KnowHow bestände.

Zwischen "man arbeitet mit Linux & BSDs" und "man hat genug Know-How eines Kernel-Subsystems und angeschlossener Systeme, um einen entsprechenden Treiber zu entwickeln" liegen Welten.

Ferner müsste die Unternehmen dann die Entwickler von lohnenswerten Projekten abziehen, was die Entwicklung eines BSD-Treibers für den Hersteller noch unattraktiver macht. Gute Entwickler mit derartigem Spezialwissen kriegt man nicht gerade günstig im Dutzendpack vom nächstbesten Personaldienstleister...

Und eben: wie viel macht die Entwicklung eines Treiber's im Verhältnis zur gesamten technischen Entwicklung eines Geräts - und hier im speziellen einer Grafikkarte - aus?

Mit den Zahlen wird kein Grafikkarten-Hersteller rausrücken. Ich kann nur aus eigener Erfahrung sprechen, schon bei einfacherer Hardware und simpleren Systemumgebungen wurde da schnell die Millionen-Grenze geknackt.

Ich meine, die kennen doch ihre Geräte bis auf's Molekül. Einen Treiber zu schreiben wenn man das Gerät doch bis auf's letzte Bitchen kennt, wird ja wohl keine nennenswerte Investitionssummen verschlingen.

GPUs sind heutzutage extrem komplexe Gebilde, die ein einzelner Mensch gar nicht mehr komplett durchdringen kann.

Da wird wohl selbst ein BusinessClass Flug eines Managers nicht teurer sein.

Den Entwickler möchte ich kennenlernen, der für den Gegenwert eines Business-Class-Flugs - also in ungefähr einer Arbeitswoche - sich in sämtliche Komplexitäten der GPU, X11 samt Extensions, eines Kernels und dem Zusammenspiel besagter Komponenten auch nur oberflächlich einarbeiten kann.

Bis sowas rund läuft, reden wir von Aufwänden in Mannjahren.

Und es fragt sich mir: wie wird das bei den proprietären Hesteller gemacht? Zum Beispiel Apple.

Apple verkauft jeden Tag mehr Macs als es überhaupt BSD-Desktops gibt. Apple hat genug eigene Entwickler, um in Zusammenarbeit mit den jeweiligen Hersteller die Treiber anzupassen. Bei den Summen arbeiten die Hersteller natürlich Apple auch gerne zu.

Ein Anfang wäre es, sich mal zu entscheiden, *was* wir eigentlich wollen. Muss es auch (von Anfang an) hardwareunterstützt Multimedia, gaming und sonstnochwas können oder ist uns ein langfristig tragfähiges Konzept wichtiger, auch wenn BSD-wayland erst mal nur Desktop/Alltag kann?

Make it work, make it fast, make it beautiful. Man kann natürlich ewig über einem Konzept brüten, während einem die Konkurrenz die Butter vom Brot und die interessierten Entwickler abgreift.

 

[zuglufttier]

Apple macht es sich ja auch relativ "einfach", indem sie nur bestimmte Hardware benutzen. Bei entsprechender Stückzahl plaudern die Hersteller sicher auch eher mal über irgendwelche Spezifikationen. Oder geben den Treiber oder irgendwelche fertigen Schnittstellen einfach fertig obendrein, weil bestimmte Mengen immer abgenommen werden. So läuft es ja auch mit den Konsolen...

Man könnte einen Fork von FreeBSD bauen, der nur auf amd64 sowie Nvidia Grafikkarten läuft. BlobBSD, das käme einem Mac OS schon recht nahe

 

[peterle]

"BlobBSD" klingt auf jeden Fall kultig!

 

[abeginner]

@ rmoe, Azazyel & zuglufttier :
Danke für eure Antworten. Offensichtlich hatte ich den Aufwand für solche Treiberentwicklung unterschätzt.

Was Apple/OSX betrifft : das hatte so vermutet.

 

[zuglufttier]

BlobBSD könnte auch ohne Probleme einen schönen Desktop mit 3D-Beschleunigung direkt mitbringen Dann würde sich bei allen Benutzern eine konsistenes Benutzererfahrung einstellen. Noch ein paar 3D Spiele installiert, Linux Emulation für Flash direkt installiert und schon ist der schicke Desktop fertig