EmuandCo wrote:
- Propietäre Treiber sind ja schön und gut, aber was willst du denn mitliefern zur Installation? Treiber ohne Distribution License oder was? Joa, so kann man das ganze Projekt auch legalitätstechnisch an die Wand fahren... Und ja, SDI ist nicht das was ich als legal bezeichnen würde. Nutzen kann man es aber klar gerne. Tu ich auch.
Der Snappy Driver Installer ist ein SourceForge-Projekt, das hatte bisher keine Lizenz-Probleme. Alle aktuellen Windowstreiber liegen dort außerhalb in einem gut gepflegten ca. 14 GB Torrent. Der SDI-Sourcecode samt Torrent wäre von daher eine solide Basis für ReactOS. Dann muss man es auch nicht mit Treibern vollstopfen, ReactOS würde genauso nur nach fehlenden Treibern scannen und diese downloaden.
Mir scheint irgendjemand hat nicht nur die geniale Idee für ein freies ReactOS gehabt, sondern leider auch die völlig kontraproduktive, es müssen auch alle Windowstreiber unter einer freien Lizenz stehen, also etwas wovon man bei Linux schon lange träumt, doch völlig utopisch!
florian wrote:
Leider verstehe ich ebenso wenig wie EmuandCo, auf welche proprietären und urheberrechtlich geschützten Windowstreiber von Microsoft ein installiertes ReactOS zugreifen soll. Oder vielleicht nur, bei einer Installation von ReactOS in einer VM?
Das wäre nur die Notlösung, wenn ReactOS für die Treiber nur die einer alten Windowsinstallation nutzt samt aller Pfade dort, wäre man zumindest die VMs mit ihren Uralttreibern los, die noch viel weniger Freiheiten bieten! Das beste wäre natürlich ReactOS bekommt irgendwann mal sein eigenes aktuelles Treiberverzeichnis, keine Almosen aus der Oracle Virtualbox und keine Windowsrelikte!
florian wrote:
Wieviele Entwickler können allerdings NTFS oder einen NT-Kernel binärkompatibel auf legalem Wege programmieren? Bestehende Linuxfilesysteme hingegen aufzunehmen, dürfte einfacher sein.
Es gibt das freie NTFS-3G, das aktuelle NTFS in ReactOS basiert vermutlich darauf, allerdings muss man den Schreibzugriff erst über die Registry manuell aktivieren, soweit ich den letzten Changelog verstanden habe.
Das ist jedenfalls was wir brauchen, wenn wir die Masse unserer Windowsprogramme lesen und darauf schreiben wollen.
Was immer die Vorteile der Linuxfilesysteme sind, dafür sollte man besser keine Entwicklerkapazitäten opfern, ReactOS soll doch mehr als nur ein weiterer Linuxfork werden!
florian wrote:Ergänzend zu den bereits von gonzoMD und EmuandCo vorgetragenen Aspekten betrachte ich es genauso wie Du als "sehr schön": Nämlich als praktischen Service, dass ReactOS "out of the box" zum Beispiel Linuxfilesysteme lesen kann: Mein Satelliten-Receiver speichert seine Aufnahmen nämlich auf eine Ext2 oder Ext3 formatierte Festplatte - mit Bordmitteln kommt mein Windows 7 da nicht weiter!
Ja das ist schön, wenn die Nischenanwendungen die unter Linux besser laufen auch unter ReactOS laufen. Wenn man sich nur darauf konzentriert wird ReactOS aber nur ein weiterer Linuxfork!
Das Problem ist doch ReactOS muss dafür auch selber auf Ext2 oder Ext3 installiert sein, sonst funktioniert der Datenaustausch zwischen deiner Receiverfestplatte und ReactOS einfach nicht. Es gibt bis heute kein Programm das zuverlässig Ext2 oder Ext3 formatierte Daten, ins FAT32 oder NTFS Format zurück schreiben kann!
Du erkaufst dir deine funktionierende Receiverfestplatte also mit der Inkompatibilität jedweder Windowssoftware zur Filmbearbeitung! Genau für diese Kompatibilität ist ReactOS ursprünglich aber mal angetreten!
Ich werde den unangenehmen Eindruck nicht los, das ist wirklich mal jemand von Microsoft los gezogen, alle Ansprüche und Ideale der OpenSource Community in ReactOS zu verpacken, damit es wirklich zu schwerfällig für jede weitere echte Entwicklung wird. Hoffentlich entdeckt nicht noch jemand die Vorteile der RISC OS Filesysteme!
