Diskussion:ReactOS/Archiv/2016
Vergleich ROS-Explorer mit [Windows-]Datei-Manager und W.-Explorer
Ich hab mal einen Fehler korrigiert, der durch einen untauglichen Link auf foxplanet.de "belegt" war. Abgebildet war die alte Benutzeroberfläche, die an Windows 2000 angelehnt war, die Rede war aber vom Vergleich mit dem uralten Dateimanager, dessen Aussehen an Windows 3.x/NT 3.x angeleht war. Der andere Beleg von ReactOS selbst stimmt allerdings. Den Unsinn mit dem Dateimanager habe ich deshalb korrigiert. Wer es nicht glaubt, möge sich bitte die betreffenden ROS-Versionen selbt ansehen und mit Win 3.x und Win2k vergleichen. Ich denke, das ist deutlich genug! --H7 (Diskussion) 15:40, 11. Dez. 2016 (CET)
- Was wohl Auslegungs- oder Ansichtssache sein dürfte aber kein Grund ist die betreffende(n) Bearbeitung(en) als „Unsinn“ abzutun und hier (auf dieser Besprechungsseite) sowie dort (in den Zusammenfassungen) so überzureagieren. Im Übrigen wurde dort (im betreffenden Abschnitt) etwas von „angelehnt“ (im Sinne von „annähernd“ oder „ähnlich“) geschrieben, was im Allgemeinen wohl etwas anderes ist als „deckungsgleich“.[1] Zudem erinnerte mich das Bild (→ vom sogenannten ‚ROS explorer‘[2]) nunmal sehr stark an den (alten Windows-)Datei-Manager (aus 3.x-Zeiten, vergleiche auch mit Bild:Wfw.PNG und bspw. die Ordnerbäume [jeweils im linken Unterfenster] oder die im Windows-Explorer nicht mehr zufindenden Doppelpunkte [..], um im [jeweils rechten] Haupt[unter]fenster [also dort wo alle Dateien und Ordner, eben der Hauptinhalt angezeigt wird] den jeweils übergeordneten Ordner zu erreichen) – jedenfalls erschien mir Dieser (Datei-Manager, zum ‚old explorer‘) [auf den ersten Blick(en)] sehr viel ähnlicher als der (u.a. auch erst mit Windows 95 weiter eingeführte) Windows-Explorer – bei näherer Betrachtung scheinen aber im ROS-Explorer mehrere (Explorer-)Unterfenster geöffnet zu sein, von denen wohl zwei eine alte (2D-)Darstellung (eher wie im Datei-Manager) und Eines eine schon etwas modernere Ansicht hat (also auch mit anderen/neueren Ordner-Bildchen, eben eher wie im W-Explorer). -- 4osuvfa, am 11.12.2016, 17:12 (MEZ)
- Ja, die Umschreibung „mit Elementen des noch älteren Dateimanagers“ scheint ein guter Kompromiss[3] oder (besser) Mittelweg zu sein. Danke, H7. -- 4osuvfa, am 11.12.2016, 19:06 (MEZ)
- Dass ist sämtlich unbelegt und scheint nach den Ausführungen hier Theoriefindung zu sein. 4osuvfa, bitte arbeite stärker mit Quellen. In der aktuellen Form könnten / müssten eigentlich weite Teile des Artikels als unbelegt gestrichen werden. Auch bei deinen letzten Änderungen hast du keine Quellen angegeben. [4] --Häuslebauer (Diskussion) 10:40, 15. Dez. 2016 (CET)
- @4osuvfa: Danke, dass du einige Quellen nachträgst: [5] Leider ist dies in der aktuellen Form nicht ausreichend. Um bei dem Beispiel dieses Absatzes zu bleiben, benötigen wir dafür eine Quelle, die überhaupt die Thematik ReactOS und Treiber diskutiert, als Beispiel für eine Lösung Snappy Driver Installer benennt und die Entscheidung des Entwicklerteams diesen Weg nicht zu gehen damit erklärt, dass "die bisherigen vorzeigbaren VM-ReactOS-Laufzeiteffekte und den Alpha-Status" nicht gefährdet werden soll. Ohne eine entsprechende Quelle ist der Absatz als Theoriefindung zu löschen. --Häuslebauer (Diskussion) 10:54, 15. Dez. 2016 (CET)
- Was ist hier bitte sämtlich unbelegt? – siehe auch nebenan, im Abschnitt „Einzelnachweise“[6] oder noch deutlicher ebenda, am 16.4.2016, als ich hier (vor allem nebenan) noch garnichts angefaßt hatte. Kann es sein, daß du hier zum Einen die falsche Person ansprichst und zum Anderen auch völlig aus dem Zusammenhang heraus einfach (ohne den Betreff hier [im gegenwärigen Abschnitt] zu lesen) in die Besprechungsseite hingeschrieben hast? Womöglich beziest du dich aber auf den Abschnitt hier drüber, der (nebenan) tatsächlich (nach wie vor) sämtlich unbelegt ist, zudem aber auch nicht von mir stammt (siehe auch der betreffende Abschnitt vor und nach
meinenunseren Änderungen). Sei doch bitte künftig so nett, und schau erstmal in Ruhe (in der sogenannten „Versionsgeschichte“, siehe dazu ggf. auch allgemein unter Hilfe:Versionsgeschichte) nach, wer was wann wo[hin] geschrieben hat und spreche die Dinge dann bitte auch mit einem zutreffenden (ggf. sogar schon genannten) Betreff an (siehe dazu ggf. auch unter Hilfe:Abschnitt hinzufügen mit „Betreff“). -- 4osuvfa, am 15.12.2016, 11:47 (MEZ)
- Was ist hier bitte sämtlich unbelegt? – siehe auch nebenan, im Abschnitt „Einzelnachweise“[6] oder noch deutlicher ebenda, am 16.4.2016, als ich hier (vor allem nebenan) noch garnichts angefaßt hatte. Kann es sein, daß du hier zum Einen die falsche Person ansprichst und zum Anderen auch völlig aus dem Zusammenhang heraus einfach (ohne den Betreff hier [im gegenwärigen Abschnitt] zu lesen) in die Besprechungsseite hingeschrieben hast? Womöglich beziest du dich aber auf den Abschnitt hier drüber, der (nebenan) tatsächlich (nach wie vor) sämtlich unbelegt ist, zudem aber auch nicht von mir stammt (siehe auch der betreffende Abschnitt vor und nach
- Ich habe dies hier angesprochen, weil es auch hier ein Problem ist. Die Debatte hier an was sich der ROS explorer graphisch anlehne, basierte - soweit ich die Argumente verstanden habe - auf Theoriefindung. Konkret der eigenen Interpretation eines Screenshots des selben. Vielleicht war es unglücklich in meinem letzten Post auch auf andere Probleme hinzuweisen. Niemand bestreitet, dass der Artikel in einem schlechten Zustand ist. Aber dies begründet nicht, warum neuere Einfügungen diesen schlechten Zustand mit Blick auf die Belege fortführen sollten. --Häuslebauer (Diskussion) 12:05, 15. Dez. 2016 (CET)
- Zum Einen solltest du mal (ganz grundsätzlich das Wiki hier betreffend) langsam damit beginnen, auch die sogenannte „Zusammenfassung“ zu nutzen (siehe dazu ggf. auch unter „Hilfe:Zusammenfassung und Quellen“). Es gibt nämlich Einige, welche Diese (Zusammenfassung) auch für Belege (oder Quellen) und ggf. auch nur für einfache Begründungen nutzen (etwa in Einzelfällen, wie etwa Diesen [wo es lediglich um die Rechtschreibung oder hier genauer um die Zeichensetzung geht], in denen ein Einzelbeleg wohl kaum weiter nötig ist).
- Und zum Anderen (die eigentliche Sache hier, im Abschnitt betreffend): Soweit ich sehe habe ich oben als einzige Person Belege angefügt (bevor du kamst) und muß mir hier auch weiterhin deinen Einwurf der Theoriefindung (siehe dazu auch unter Wiktionary:de:Theoriefindung, was das Wort hier – im Deutschen – eigentlich bedeutet[7]) vorwerfen lassen? Es reicht langsam! Dann lösche eben den ganzen Abschnitt, wenn du dir nicht einmal die Mühe machst, den Ausführungen oben und auch den dort angegebrachten Belegen zu folgen. .. im Übrigen auch nebenan von mir u.a. mit einem (mit lediglich einem Bild) bebilderten Nachweis belegt (mit der englischsprachigen ROS Explorer FAQ, auf Foxplanet.de),[8] wo vorher noch (unbelegt) etwas vom Windows-Explorer stand,[9] wobei der zweite (nun, nur noch hier oben genannte) Beleg dann (eben da) wieder entfernt wurden. -- 4osuvfa, am 15.12.2016, 12:37 (MEZ)
Virtuelle Maschinen und Treiber
Ich habe mir wegen den aktuellen Debatten den Abschnitt Virtuelle Maschinen und Treiber nochmal genauer angeschaut und parallel versucht zu recherchieren. Ich habe an den Behauptungen in weiten Teilen des Abschnitts mittlerweile erhebliche Zweifel. Hier die zentralen Punkte:
- Es wird behauptet, ReactOS sei nur lauffähig innerhalb einer Virtuellen Maschine. Das Projekt bietet eine Live-CD und eine Boot-CD (als Installationsmedium) auf ihrer Download-Seite an. [10] In den FAQs für Tester wird explizit der Start auf nicht-virtualisierter Hardware per Live-CD oder Installation auf dieser per Boot-CD beschreiben, auch wenn virtuelle Maschinen als bevorzugte Möglichkeit dargestellt werden. [11] In der Gesamtschau ergeben sich erhebliche Zweifel an der Behauptung, dass ReactOS ausschließlich in virtualisierten Umgebungen lauffähig sei.
- Die Ausführung zu virtuellen Maschinen und Hardware sind unverständlich. Es bleibt unklar, ob die virtuelle Hardware beschränkt sei oder die Hardware, auf der die Virtualisierungssoftware läuft. An beiden Behauptungen habe ich erhebliche Zweifel. Selbstverständlich läuft die genannte Virtualisierungssoftware auf moderner Hardware und sie ist auch in der Lage moderne Hardware zu virtualisieren. Z.B. virtualisiert VirtualBox einen xHCI-USB-Controller (USB 3.0) seit Version 5, sowie Intel HD Audio und einen ICH9-Chipsatz seit Version 4. Um nur mal einige Beispiele zu nennen.
- Es ist unklar, warum ReactOS die Neuentwicklung freier Treiber erfordern solle. In der ReactOS-Dokumentation wird die Installation propietärer Treiber beschrieben. Bereits auf der Startseite des Projekts wird mit der Vorstellung geworden "favorite Windows applications and drivers in an open-source environment" auszuführen. Das Open-Source bezieht sich offensichtlich nicht auf die Treiber. Dass ein Open Source-Projekt in der Regel sich freut andere Open Source-Software nutzen zu können, steht auf einem anderen Blatt. Bei Mesa 3D und einem USB-Stack handelt es sich nicht um Treiber.
Ich würde mich freuen, wenn mir an Hand von Quellen aufgezeigt werden könnte, dass ich mich bei dieser Schnellrecherche irre. Sollten wir keine Belege für die Behauptungen finden, werde ich den Abschnitt in absehbarer Zeit löschen. --Häuslebauer (Diskussion) 13:34, 15. Dez. 2016 (CET)
- Zu deinem 1., also was den (Ab)Satz mit der angeblichen Lauffähigkeit nur auf virtuellen Maschinen angeht. Dieser Teil ist wohl einfach nur schon etwas älter (gewesen). Habe ihn daher eben mal auch so überarbeitet (siehe auch vorher, nachher und die Änderungen insgesamt mit Quelltext), daß er nun hoffentlich verständlicher geworden ist, wobei modernere Rechenwerke (oder auch sogenannte Prozessoren) wohl durchaus auch mal (mit Belegen versteht sich) genannt werden könnten. Zudem sollte dabei bitte auch einfach mal (weiter) bedacht werden, daß es sich hier noch immer um eine sogenannte Alpha-Version (ursprünglich, nach dem ersten griechischen Buchstaben, wohl eigentlich mal als „Erstausgabe“ gedacht) oder (im hier angewendeten Sinne) wohl genauer um eine frühe Entwicklungsstufe handelt. Jedoch gehe ich einfach mal davon aus, daß (auch) die ReactOS-Entwicklung erstmal auf irgendeiner virtuellen Maschine begonnen und erst danach die Unterstützung u.a. für die nebenan genannten 486er und einser Pentiums beschrieben (oder einprogrammiert) wurden.
- Zu 2.: Unter anderem den Satz mit den Unverträglichkeiten (oder sogenannten Inkompatibilitäten) hab ich nun einfach mal rausgenommen da so ein Satz in jede Betriebsgebilde- oder ..system-Abhandlung (also auch bei Windows oder Linux) reingeschrieben werden könnte und daher eher in die allgemeine Betriebssystem-Abhandlung oder genauso gut in die allgemeine Abhandlung zu virtuellen Maschinen rein gehört. In ähnlicher Weise, was die Einflußmöglichkeit(en) der Entwickler (oder den angeblich nicht vorhandenen Einfluss des Projektes) angeht, habe ich auch diesen ganzen Absatz nun entfernt, (hauptsächlich) da auch die ROS-Entwickler (so wie jeder Andere, der Englisch kann) sich wohl auch frei an anderen Projekten oder Unternehmungen beteiligen kann.
- Zu 3.: Stimmt OpenGL (sowie auch dieses Mesa 3D) sind ganz genau genommen wohl keine (echten Geräte-)Treiber (die unmittelbar bis auf die Geräte- oder Hardware-Ebene durchgreifen) sondern Schnittstellen die wohl (üblicherweise) nur bis zur Betriebssystemebene reichen und gehören, so wie auch virtuelle Maschinen, eher zur sogenannten Middleware – vor allem wenn es (im Sinne von Mittelware oder deutlicher Vermittlungsware) Plattformübergreifende sind.
- -- 4osuvfa, am 30.12.2016, 11:31 (MEZ)
- Erstmal vielen Dank für deine Arbeit. Ich habe immer noch Bauchschmerzen zu der Aussage bzgl. Prozessoren. Aus dem ReactOS-Wiki entnehme ich, dass die Hauptarchitektur x86-Prozessoren sind. Ein Port auf AMD64 ist wohl in Arbeit, aber noch nicht abgeschlossen. Ein AMD64-Prozessor sollte abwärtskompatibel sein zu einer x86-Architektur. Von daher habe ich nach wie vor Bauchschmerzen mit der Aussage. Leider fehlt dafür auch eine Quelle. --Häuslebauer (Diskussion) 12:21, 30. Dez. 2016 (CET)
- Ist es so jetzt besser? (siehe auch jetzige Fassung) Die AMD64- oder x86-64er-Plattform hab ich dabei erstmal weggelassen, da sie erstens schon oben (also nebenan, im Übersichtskasten, mit ‚AMD64‘) genannt ist und zweitens dem genannten Wiki nach (soweit ich das sehe) es wohl eine gesonderte ReactOS-amd64.iso[12] geben soll, wenn die Entwickler soweit sind. -- 4osuvfa, am 30.12.2016, 13:32 (MEZ)
- Ich bin zwar nicht angesprochen, aber ich finde, die Formulierung hat jetzt hinsichtlich OMA-Verständlichkeit einen großen Fortschritt gemacht. (Zumindest PC-affine "Omas" werden das sicherlich verstehen.) --H7 (Diskussion) 13:39, 30. Dez. 2016 (CET)
- Ich finde es auch einen deutlichen Fortschritt. Denke der Abschnitt passt jetzt so. Nochmals vielen Dank für deine Arbeit! --Häuslebauer (Diskussion) 14:40, 30. Dez. 2016 (CET)
- Ist es so jetzt besser? (siehe auch jetzige Fassung) Die AMD64- oder x86-64er-Plattform hab ich dabei erstmal weggelassen, da sie erstens schon oben (also nebenan, im Übersichtskasten, mit ‚AMD64‘) genannt ist und zweitens dem genannten Wiki nach (soweit ich das sehe) es wohl eine gesonderte ReactOS-amd64.iso[12] geben soll, wenn die Entwickler soweit sind. -- 4osuvfa, am 30.12.2016, 13:32 (MEZ)
ReactOS ist nicht ohne VMs lauffähig da es einfach keine freien Treiber für moderne Mainboards gibt, die Installations CD erfordert in jedem Fall eine VM. Die ursprüngliche Aussage wurde also stark verfälscht. Auch der Hinweis das ReactOS überhaupt kein Einfluss auf die Entwicklung der Oracle Virtualbox hat, fehlt plötzlich. Der spärliche Hinweis in https://www.reactos.org/wiki/ReactOS_ports auf eine beabsichtigte Intel x86 (i586) Unterstützung, ist doch kein Gegenindiz. ReactOS läuft faktisch nicht on-the-fly mal eben auf einem PC!
Die mutmaßlichen Errungenschaften von ReactOS basieren in Wahrheit immer noch zumeist nur auf der Fähigkeit der Oracle Virtualbox. Das war die Kernaussage damals. Also ich bitte darum, die ältere Version vom 15. Dezember (https://de.wikipedia.org/w/index.php?title=ReactOS&diff=160666953&oldid=160666686) wieder herzustellen und die Unterstützung für den Intel HD Audio Chipssatz nur zusätzlich zu erwähnen.
Auch das mit dem quelloffenen Snappy Driver Installer steht jetzt in einem völlig falschen Zusammenhang, der kann unter ReactOS überhaupt nicht benutzt werden! Der "wäre" nur eine Alternative zur aktuellen ReactOS Treiber-Installation durch die nicht-offene Oracle-VM, wenn ReactOS auf die Verwendung einer VM auch verzichten würde. Das ist aktuell aber nicht der Fall!
Jeder selbst installierte Treiber würde sich heute mit der Oracle Virtualbox beißen. Man darf nicht vergessen das ein nachinstallierter Treiber "innerhalb der Oracle Virtualbox" selbst wen er funktionieren sollte, auch nur virtualisiert ist.
Das ist so als wenn man eine virtuelle Picasso IV Grafikkarte unter dem Amiga-Emulator WinUAE installiert. Das kostet als Softemulation erheblich mehr CPU-Leistung als wie für das Original und kann man doch kaum eine echte Treiberunterstützung durch ReactOS nennen! --Tilt001 (Diskussion) 01:02, 3. Jan. 2017 (CET)
- Kannst du bitte noch Quellen für die Behauptungen nachliefern? Fehlende Belege war der Hauptgrund für die umfangreichen Streichungen. --Häuslebauer (Diskussion) 11:44, 3. Jan. 2017 (CET)
Also, ich will ja nicht behaupten, dass ich Experte bin, aber irgendeine Unterversion von ReactOS (so vor etwa 2 Jahren) hab ich mal auf einem echten PC installiert. Ein älteres Modell, das ich als Testrechner übrig hatte. Es haben zwar haufenweise Treiber gefehlt, es gab kein Netzwerk, keinen Ton und vieles andere nicht, aber es war erkennbar, was mal eines Tages daraus werden soll. --H7 (Diskussion) 12:37, 3. Jan. 2017 (CET)
- ReactOS wird seit der Version 0.4.0 für die Oracle VirtualBox ausgeliefert: https://www.reactos.org/project-news/reactos-040-released bzw. mit dem: "VirtualBox and VirtualPC support" Es gibt einfach keine freien Mainboard-Treiber für aktuelle Mainboards. Ohne den Vorbau einer Virtualmachine würde es nicht mehr laufen.
- Die VirtualBOX darf aber vom ReactOS Team aber auch in keinster Weise verändert werden, das geht hieraus hervor 5. Reservation of Rights: https://www.oracle.com/legal/terms.html
- Das ist also eine neue bedeutende Abhängigkeit die der Artikel darstellen sollte. Es gibt Menschen die haben es geschafft ReactOS auf einem originalen Pentium 100 ohne VM zu installieren, das kann man diversen YouTube Videos entnehmen. Die sind zusammen mit den Pentium 100 aber wirklich eine aussterbende Art, das sollte man nicht als den Normalfall darstellen.
- Es bringt auch nichts wenn jemand auf biegen und brechen einen proprietären Treiber ohne VM zum laufen bringt. Die werden ab Werk nicht mit den offiziellen ISOs mitgeliefert und auch kein freier Installer dafür. Das heißt die Fehlermeldungen aus solchen Experimenten erreichen die Entwickler auch nicht, da es eben keinerlei Standardisierung proprietärer Treiber gibt und die Art und Weise wie sie installiert werden. --Tilt001 (Diskussion) 13:34, 3. Jan. 2017 (CET)
- Zugegeben, ich habe die ReleaseNotes zu 0.4.0, die du oben verlinkt hast, gerade nur überflogen. Aber soweit ich das verstanden habe, wurde dort nur Unterstützung von VirtualBox ergänzt: „User-Centric Improvements [...] VirtualBox and VirtualPC support“. Außerdem gibt es einen Hinweis, dass das VirtualBox Image zu diesem Zeitpunkt noch nicht öffentlich verfügbar war: „Please also note that the VirtualBox image is not yet live at the time of this release.“ Kannst du bitte nochmal zitieren, auf welche Stelle du dich konkret beziehst? --Häuslebauer (Diskussion) 13:48, 3. Jan. 2017 (CET) P.S.: Niemand bezweifelt, dass die Unterstützung von Chipsätzen sicherlich noch ein Problem darstellt. Deine weitergehenden Aussagen zur Koppelung des Projekts an ein VirtualBox bringe ich aber einfach nicht in Deckung mit den von dir angeführten Quellen und den Aussagen in der Faq für Tester, die sich genau um diese Fragestellungen dreht.
- Es bringt auch nichts wenn jemand auf biegen und brechen einen proprietären Treiber ohne VM zum laufen bringt. Die werden ab Werk nicht mit den offiziellen ISOs mitgeliefert und auch kein freier Installer dafür. Das heißt die Fehlermeldungen aus solchen Experimenten erreichen die Entwickler auch nicht, da es eben keinerlei Standardisierung proprietärer Treiber gibt und die Art und Weise wie sie installiert werden. --Tilt001 (Diskussion) 13:34, 3. Jan. 2017 (CET)
- Man muss die Aussage dort: "Installing ReactOS will format your hard drive, so don't use in a PC which have valuable data in it! That's one of the reasons we really encourage to use a Virtual Machine", hier einfach etwas wörtlicher nehmen. Die Formatierung der Platte ist nur ein Problem, das andere ist einfach ReactOS könnte mit sämtlichen bereits installierten proprietären Windowstreibern auch nichts anfangen, da man proprietäre Treiber auch in jeder Form ablehnt.
- Oder wie auch schon ein Entwickler im Forum schrieb: "Ein Treiber besteht aus einem bisschen mehr als nur dem drivers Ordner... Dlls, exe, inf etcetera. Und wie schon im englischen Forums breitgetreten.... offizielle ISOs sind kompilierter Quellcode und das wird sich NICHT ändern. Wer mehr will wartet entweder auf ne Betaversion oder lädt sich seine Treiber selbst." https://www.reactos.org/forum/viewtopic.php?f=6&t=14729&start=15
- In der Praxis macht das natürlich keiner, da ja logisch ist, was nicht offiziell unterstützt wird (proprietäre Treiber) weder durch die ISOs noch freie Installer dafür, wird höchstwahrscheinlich auch nicht laufen. Also wieder back zur Oracle Virtualbox! --Tilt001 (Diskussion) 14:40, 3. Jan. 2017 (CET)
- Ich kann deinen Ausführungen leider nicht folgen. In meinen Augen schmeißt du da verschiedene Sachen zusammen. Die Warnung, dass bei der Formatierung einer Festplatte alle Daten gelöscht werden, ist so ziemlich der Standard. Mit "sämtlichen bereits installierten proprietären Windowstreibern" kann ReactOS schlicht nichts anfangen, weil es während und direkt nach der Installation schlicht keine "bereits installierten [...] Windowstreiber" gibt - schließlich wurde das System ja neu aufgesetzt. Das hat nichts damit zu tun, ob ReactOS jetzt "propiertäre Treiber [...] in jeder Form ablehnt" oder nicht. Der von dir verlinkte Thread aus dem Forum scheint mir übrigens in keinster Form ein hilfreicher Beitrag zur Klärung zu sein. Ich hoffe für die ReactOS-Community, dass der dort gepflegte Umgang nicht Standard ist. --Häuslebauer (Diskussion) 14:52, 3. Jan. 2017 (CET)
- In der Praxis macht das natürlich keiner, da ja logisch ist, was nicht offiziell unterstützt wird (proprietäre Treiber) weder durch die ISOs noch freie Installer dafür, wird höchstwahrscheinlich auch nicht laufen. Also wieder back zur Oracle Virtualbox! --Tilt001 (Diskussion) 14:40, 3. Jan. 2017 (CET)
Status
@Tilt001: Vielen Dank für deine Ergänzungen. Leider hast du für diese Einschätzungen keine Quellen angeführt und sie auch nicht als Position gekennzeichnet. Es drängt sich der Verdacht der Theoriefindung auf. Gleichzeitig werden auch noch in Bezug auf andere Themengebiete weitreichende Einschätzungen getroffen - insbesondere, dass Linux bei der Entwicklung von Treibern nicht ernsthaft mit Microsoft Windows konkurrieren könne. Ich würde dich daher bitten entsprechende Quellen nachzureichen. Mir ist bewusst, dass der Abschnitt auch bereits zuvor nur dürftig belegt war. Deine Änderungen haben das aber nicht gerade besser gemacht. Viele Grüße und vielen Dank --Häuslebauer (Diskussion) 11:56, 17. Nov. 2016 (CET)
- Hier eine Quelle zur schweren Entwicklung der Linuxtreiber:
- "Linux-Treiber stehen bei vielen Hardwareherstellern nach wie vor ganz unten auf der Prioritätsliste, nur bei Grafikkarten, Mainboard-Chipsätzen und Raid-Controllern haben die Anbieter den Linux-Trend erkannt. So bleibt die Arbeit der Treiberentwicklung meist an der Linux-Gemeinde hängen. Erschwerend ist dabei, dass die Ansteuerung von Spezialchips oder die Funktionen der Firmware zum Geschäftsgeheimnis erklärt werden, sodass die Linux-Entwickler keinerlei Informationen bekommen, wie die Geräte überhaupt arbeiten."[1]
- Der Artikel ist aber von 2005, vielleicht findet jemand noch eine bessere Quelle. Das Problem ist einfach die Verspätung, wenn neue Geräte nur mit Windowstreibern erscheinen kann das bis zu 10 Jahre dauern bis es einen brauchbaren Linuxtreiber dafür gibt, voraus gesetzt das Teil ist halbwegs Massenware geworden. Die Installation davon ist aber oft auch kein Kinderspiel. Genau das drückt Linux bis heute auch unter 2% Marktanteil.
- Deswegen geht in diesem Zusammenhang ReactOS auch einen sehr ineffizienten Weg, wenn man jetzt wieder nur auf neue und alternative freie Treiber setzt anstatt proprietäre normale Windowstreiber. Das ist bei dem Budget des ReactOS-Projektes nach allen Betriebswirtschaftlichen Kriterien einfach nicht zu stemmen. --Tilt001 (Diskussion) 08:29, 2. Dez. 2016 (CET)
- Dass hat sich schon lange geändert. Siehe z.B. bei den Grafikkarten die rege Treiberentwicklung aller drei relevanter Hersteller (AMD, Nvidia und Intel) für Linux, um nur ein zentrales Beispiel zu nennen. --Häuslebauer (Diskussion) 15:37, 2. Dez. 2016 (CET)
Ich verstehe noch nicht ganz (und das ist meine Kritik am momentanen Stand des Artikels), weshalb das überhaupt eine so große Rolle spielt. Ich dachte, dass ReactOS grundsätzlich binärkompatibel zu Windows sein soll. Also sollte es - wenn das so ist - genügend Treiber geben, weil ja fast alle Hardware unter Windows läuft. Sollte es so sein, dass Microsoft generische Treiber für gängige Hardware zur Verfügung stellt und genau diese Hardware nicht mehr mit eigenen Gerätetreibern unterstützt wird und eben dies dazu führt, dass Treiber für ReactOS nicht vorhanden sind, dann fehlt dieser Zusammenhang momentan noch völlig im Artikel. Was ich damit sagen will: Egal was das Problem ist: Bitte auch im Artikel erklären! --H7 (Diskussion) 17:56, 2. Dez. 2016 (CET)
- Wenn ich den Artikel richtig verstehe, geht es darum, dass ReactOS auch bei den Treibern auf freie Software setzen will und bisher die Installation proprietärer Treiber nicht unterstützt. Zumindest verstehe ich folgenden Satz so: „Da das ReactOS-Projekt [...] ähnlich wie Linux auch nicht auf proprietäre Windows-Treiber setzt besteht hier eine große Abhängigkeit der anderen Hersteller und der kompletten Neuentwicklung von freien Windowstreibern. [...] Eine Alternative würden automatische Treiberinstaller bieten die selber wie z. B. der 'Snappy Driver Installer' Open Source sind und eine eigene Hardwareerkennung besitzen. Das ReactOS Projekt setzt zur Zeit allerdings weder auf proprietäre Windowstreiber noch einen freien Installer dafür um die bisherigen vorzeigbaren VM ReactOS-Laufzeiteffekte bzw. den Alpha-Status von ReactOS nicht zu gefährden.“ --Häuslebauer (Diskussion) 13:59, 3. Dez. 2016 (CET)
- Zumindest die eindeutig falsche Aussage zu Linux und Treibern habe ich gestrichen. [13] --Häuslebauer (Diskussion) 14:03, 3. Dez. 2016 (CET)
- Das Problem ist nicht Microsoft und die Verfügbarkeit der Windowstreiber. Das Problem ist die Oracle VM VirtualBox ohne die man ReactOS nicht installieren kann. Diese Vitualbox bietet tatsächlich nur sehr wenige Treiber die eine alte x86 Umgebung simulieren.
- Daran kann das ReactOS Team auch nichts ändern, denn Oracle verbietet jede Modifikation der Oracle Virtualbox, jeden Versuch es zu dekompilieren oder über Reverse Engineering die Funktionen nachzuvollziehen. Das steht hier im "§ 3 Restrictions and Reservation of Rights" https://www.virtualbox.org/wiki/VirtualBox_PUEL
- ReactOS hat sich in gewisser Hinsicht also selber aus der Windowswelt zurückgezogen und sich in die rein virtuelle Umgebung der Oracle Virtualbox eingesperrt, die es aber nicht erweitern kann. Damit ist ReactOS auf praktisch jedem Rechner lauffähig, allerdings produziert es keine Fehlermeldungen mehr die Rückschlüsse auf schlecht implementierte Treiber bieten oder Rückschlüsse auf Fehler im ReactOS Kernel selber. Man hat sich quasi selber an die Kette gelegt, im Vertrauen darauf die Personalunion aus Microsoft und Oracle wird sich um weitere Treiber schon irgendwie kümmern oder eben die Community die weiter freie Treiber programmiert die man in den ReactOS Kernel einbauen kann, genau wie schon unter Linux.
- Das ganze beißt sich aber auch wieder mit der Virtualbox, wie will man einen freien USB 2 Treiber einbauen den es vielleicht sogar gibt, wenn die Virtualbox selber nur USB 1.1 unterstützt? Dieses Körperfremde Implantat verhindert zwar keine Weiterentwicklungen aber es gibt natürlich gewisse Abstoßungsreaktionen. Dazu kommt noch WINE aus der Linuxwelt das auch schon weit fortgeschritten ist und sich in Teilen einbinden lässt aber ursprünglich auch nur für den Linux Kernel geschrieben wurde.
- Das Konglomerat aus der Oracle Virtualbox-Entwicklungshilfe, dem Codeklau aus WINE und der gleichzeitigen Windows-Treiber Inquisition hat das ReactOS-Projekt im Grunde längst sterben lassen.
- Das hat auch Auswirkungen auf den Artikel, wenn etwas nach 18 Jahren nicht aus dem Alpha-Status raus kommt, dann sollte man vielleicht auch mal fragen wie relevant der überhaupt noch ist. Im Endeffekt ist es ja nicht unsere Aufgabe etwas dauerhaft zu dokumentieren, das nicht funktioniert, auf Grund welcher Einflüsse auch immer. --Tilt001 (Diskussion) 19:53, 3. Dez. 2016 (CET)
- Dass stimmt so nicht, u.a. unterstützt VirtualBox schon seit einiger Zeit neben OHCI (USB 1.1) auch EHCI und xHCI. Darüber hinaus gibt es bei Linux Host gar die (experimentelle) Option PCI-Geräte durchzureichen. Aber bevor das hier zu einer allgemeinen Diskussion ausartet, möchte ich einfach mal auf WP:Belege verweisen. Auf Basis valider Quellen können wir dann gerne über Änderungen am Artikel weiterreden. --Häuslebauer (Diskussion) 21:26, 3. Dez. 2016 (CET)
- Gleich die Relevanz des Themas ReactOS in Frage zu stellen, nur weil es bis heute keine Produktivversion davon gibt, ist aber ganz schön destruktiv! Vielleicht sind die Entwickler etwas betriebsblind geworden, weil sie hauptsächlich auf der VirtualBox entwickeln und testen und daher alles, was die VirtualBox nicht bietet, komplett vergessen. Und was Windows-Treiber angeht: Binärkompatibilität bedeutet leider noch lange nicht, dass sich HW-Treiber vom «Original» auf den «Klon» verpflanzen lassen. --Jacek79✇✇ 23:09, 3. Dez. 2016 (CET)
Ich habe mal dem Abschnitt einen Belege fehlen-Baustein verpasst. Hab nach wie vor bei vielen Aussagen das Gefühl, dass es sich um Theoriefindung handelt. --Häuslebauer (Diskussion) 13:25, 10. Dez. 2016 (CET)
- Mach's mal. Fraglich ist aber, ob es überhaupt genügend passende Quellen gibt (mal abgesehen von Infos aus dem ReactOS-Universum selbst, aber die wären dann Primärquellen). Trotzdem dürfen wir jetzt nicht die Flinte ins Korn werfen. Relevant ist das Thema ja durchaus. --Jacek79✇✇ 15:32, 10. Dez. 2016 (CET)
Habe die beiden verbliebenen Absätze nunmehr entfernt: So ist das schlicht Theoriefindung. Ein Belege-Baustein ändert daran nichts und behebt die Problematik der Textergänzung nicht. "Meinungen der Entwickler und ReactOS Community" etc. pp. sind wenn schon denn schon neutral anhand zuverlässiger Quellen darzustellen. Die Belegführung für die Ausführungen ist in der bisherigen Diskussion nicht erfolgt, die Nachvollziehbarkeit umseitig nicht gegeben, Zweifel sind angebracht (vgl. u.a. Häulsebauer), dementsprechend ist zu verfahren... --GUMPi (Diskussion) 06:16, 24. Jan. 2017 (CET)