Diskussion:ReactOS/Archiv/2005
Archiv |
Wie wird ein Archiv angelegt? |
Ich hab scheiße gebaut
Ich hab aus versehen ein Bild mit dem gleichen Namen wie das Bild was hier vorher war hoch geladen (war/ist in den Commons). Naja war eh veraltet. Sonst hätte ich schnell löschung beantragt und es nocheinmal unteranderem Namen hochgeladen. --Maarten Bosma 16:01, 14. Jun 2005 (CEST)
Vorteile und Nachteile
Ich fände es besser, wenn der Abschnitt über Vor- und Nachteile durch eine Beschreibung ersetzt wird. Wozu soll man die GPL unbedingt als Vorteil darstellen? Es ist die Lizenz und damit basta. Und Spekulationen über das Gelingen des Projekts sind auch eher unnötig. --Torsten 19:04, 7. Aug 2004 (CEST)
- tja, da gibt's nur eins zu sagen: vergessen wir das einfach mit den vor- und nachteilen. sehe nicht was das für einen sinn machen soll. FreeDOS kann man stattdessen als Vorbild nehmen. --Pythagoras1 11:28, 8. Aug 2004 (CEST)
- Ich finde der Artikel ist nicht NPOV, die negativen Spekulationen in == Entwicklung == lässt man nämlich alle stehen und die Punkte aus == Vor und Nachteile == wurde überhaupt nicht überführt wie Torsten schrieb, sondern ersatzlos gelöscht. Die GPL wurde auch nicht als irgendeine Lizenz entwickelt, sondern hier für http://de.wikipedia.org/wiki/GNU_General_Public_License#Freiheiten ,das gilt ja dann für ReactOS nicht anders. -AshSert-
- dann gehört es aber nicht hier rein, sondern in GPL. TheK(?!) 17:23, 15. Aug 2004 (CEST)
Es standen dort keine aus der GPL bedingten Vorteile, ausser vielleicht (keine Abhängigkeit von einer einzelnen Firma) die anderen aber
1. spart den Preis einer Windows Lizenz
2. dank Windows NT Treiberkompatibilität können Herstellertreiber verwendet werden, und
3. kann Win32-Programme ohne Windows-Betriebssystem ausführen
sind typische Eigenarten von ReactOs, nicht der GPL, es gibt viele GPL Projekte die tun das nicht! -AshSert-
1. ist quatsch, denn auch GPL-Software darf Geld kosten 2. und 3. ist ein gemeinsamer Vorteil [wirklich? *fg*] (und gegenüber Linux der einzige). TheK(?!) 18:04, 15. Aug 2004 (CEST)
1. eben GPL-Software kosten hier und da auch Geld, ReactOs aber nicht, also ist das ein Vorteil von ReactOS, der von GPL sind andere (offender Sourcecode etc.)
2-3. Linux, Free-BeOS oder Aros können das nicht, da ist die Treiber-Erstellung viel schwieriger, also ist auch das ein Vorteil von ReactOs. Dieser (einzige) Vorteil gegenüber Linux ist ja der wessentlichste, Linuxfirmen geben dafür Millionen jedes Jahr aus.
-AshSert-
es gibt noch nichtmal eine Beta-Version und da willst du bis in alle Ewigkeit über die Kosten urteilen? Es bleibt dabei, GPL hat nichts mit den Kosten zu tun. TheK(?!) 18:27, 15. Aug 2004 (CEST)
Warum sollte ReactOs irgendwann Geld kosten. Das ist nicht sinnvoll und praktisch auch nicht realisierbar. --Maarten Bosma 20:58, 16. Jun 2005 (CEST)-- DrFred
Patente, Timeline
Ich habe den Artikel etwas gestrafft - vieles stand doppelt und dreifach in dem Artikel, dazu einige unnötige Bewertungen und Spekulationen.
Zum Thema Patente: sind es nur Patente von Microsoft, die das Projekt gefährden? Schließlich hat Microsoft viele Patente von Drittfirmen lizensiert. Des Aspekt Rechtssicherheit würde ich etwas klarer formuliert sehen.
Gibt es zur Geschichte auch eine Timeline? Wie lange war die Planungsphase und wann übernahm der neue Projektleiter das Szepter?--Torsten 13:09, 8. Aug 2004 (CEST)
- "Geschichte" ergänzt; patente, egal von wem, gefährden sämtliche freien betriebssystemprojekte, reactos mag zwar sehr anfällig für ms-patente scheinen, aber ein großteil von diesen gefährden ebenso das gnu-projekt. linux soll angeblich keine patentierten verfahren verwendet haben. --Pythagoras1 14:21, 10. Aug 2004 (CEST)
- Danke für die Weiterarbeit. Zu den Patenten: wenn es da keine konkreteren Gefahren gibt als bei anderen Software-Projekten, können wir den Aspekt im Artikel unter den Tisch fallen lassen. Stattdessen sollten wir auf einen Artikel innerhalb Wikipedia verweisen, der die Problematik ausführlicher und konkreter schildert. Falls es hingegen bei ReactOS diesbezüglich einen Aspekt gibt, der den Lesern verdeutlicht, wie solche Probleme im Einzelfall umgangen werden, sollte der benannt werden. --Torsten 22:40, 11. Aug 2004 (CEST)
- Ich schreibe mal rein das Software patetente kein größeres Problem ist als bei anderen Projekten. Und verlinke auf Softwarepatente wenn du einen anderen Artikel im Sinn hattest dann verlinke ihn bitte. --Maarten Bosma 21:01, 16. Jun 2005 (CEST)
Microkernel oder nicht microkernel...
The ReactOS architecture is based on that of Microsoft Windows NT 4.0. Although Microsoft claims that the architecture is a modified micro-kernel (combining aspects of both micro-kernels and layered operating systems), at ReactOS we have a different definition of the architecture. The NT, and therefore ReactOS architecture, is modular and layered. The small traces of microkernel architecture are not enough for it to be described as a modified micro-kernel.
At the lowest layer is the Executive. The executive includes everything that runs in kernel mode. Above the executive are the Protected Subsystems. These subsystems provide implementations of different Operating System personalities.
--Pythagoras1 23:43, 16. Aug 2004 (CEST)
- Es ist einfach eine Definitionsfrage. --Maarten Bosma 21:12, 16. Jun 2005 (CEST)
Zu unbekannten apis
unbekannte apis kann nur der os Hersteller einsetzen, da sie sonst wenn andere sie einsetzen würden ja bekannt wären. Mit anderen Worten nur MS Applikationen können unbekannte api Aufrufe enthalten.--Dirk33 20:20, 17. Aug 2004 (CEST)
- ausnahme 1: programme, deren entwickler die geheimen apis von microsoft – teuer – lizensiert haben.
- ausnahme 2: programme, die mit microsofts entwicklertools erstellt wurden könnten diese apis auch verwenden. --Pythagoras1 03:12, 18. Aug 2004 (CEST)
- Pythagoras1, kannst du mir irgendwelche quellen nennen ? Ich bezeifle doch stark, dass Microsoft Lizenzen für ihre Native API vergibt oder 2. das sie von Microsoft Entwicklungstools genutzt wird.
Dirk33, die Native API (die hier mit "geheimen apis" gemeint ist) ist eben doch dokumentiert (z.B. auf http://undocumented.ntinternals.net/) nur eben nicht offizell. MS könnte sie desshalb auch jederzeit wieder ändern. Auch wenn sie das nicht tun werden da sie von einigen Programmen genutz wird. Die Native API existiert aber nur unter NT. Wie der Name (mehr oder weniger) verrät ist auf ihr die WinApi implementiert. --Maarten Bosma 21:04, 16. Jun 2005 (CEST)
Einige Dinge entfernt
Ich habe mir erlaubt, ein paar Sätze zu streichen:
Softwarepatente sind kein größeres Problem als bei anderen OpenSource Projekten. Im vergangenen November tauchte ein recht dreister, unauthorisierter ReactOS-Klon auf. Auch dies zum Anlaß nehmend, entsteht derzeit ein "Legal Defense Fund", der alle juristischen Projektinteressen vertreten soll.
Der Hinweis mit den Softwarepatenten erscheint mir recht überflüssig und die Sache mit Ekush OS hat sich afaik geklärt. Ein Hinweis, wie das Projekt juristisch vertreten wird, ist m. E. nicht von Interesse in einem Enzyklopädieeintrag.
Bei Programmen darf man sich wohl an den jeweiligen Verpackungstexten orientieren.
Sagt m. E. nichts aus. Zumindest nichts, was einen Leser des Artikels, der das Projekt vermutlich nicht kennt, interessiert.
Für konstruktive Kritik jederzeit offen. Mr. Anderson 00:04, 19. Jul 2005 (CEST)
- Im Punkt der Softwarepatente: Zustimmung. Der andere Hinweis (Ekush und Defense Fund) erschien mir sinnvoll, da es auf die Frage eingeht, wer denn hier die Copyright-Sicherung bewahren soll. Bei Firmen gibt es Rechtsabteilungen, ROS hat zwar Lizenzbestimmungen, aber keine Anwälte bisher: Aufgrund Ekush's also Demonstrierung, wie sich ein OpenSource-Freizeitprojekt wie ROS rechtlich wehren kann.
- Und zu Bei Programmen darf man sich wohl an den jeweiligen Verpackungstexten orientieren. Damit wollte ich darauf hinweisen, daß man sich nicht versprechen sollte, das mit ROS die Anforderungen von Windows-Software halbiert wird, was einem nicht Eingeweihten ja in den Sinn kommen kann ("ein Windows 2000, lauffähig auf 486er, dann ist bestimmt alles doppelt so schnell").
- Copyleft wäre wohl treffender ;). Ekush wurde, soweit ich das gesehen habe, dann ja schließlich unter die GPL gestellt. Nunja, ich glaube Du hast Recht. Allerdings gefällt mir die Formulierung nicht. "Ein unauthorisierter ReactOS-Klon" klingt als müsste man sich erst eine Genehmigung holen, bevor man den Code weiterverarbeiten darf. Aber das ist ja ausdrücklich erlaubt und wohl auch erwünscht, solange man sich an die GPL hält. Die externen Links sollten m. E. besser nicht im fließenden Text stehen. (Wird irgendwo beim Thema Wikifizierung drauf hingewiesen)
- 'Bei Programmen...' - das hatte ich vollkommen anders verstanden. Dachte, es ginge um die Beschreibungen der RosApps. Dein Hinweis, dass Hardwarevoraussetzungen, die sich an Windows orientieren, nicht nennenswert abweichen, sehe ich auch als sinnvoll an.
- Wie wäre es mit Nachdem im November 2004 erstmals rechtliche Konflikte mit Ekush OS auftraten, wurde damit begonnen, den "Legal Defense Fund" einzurichten, mithilfe dessen alle juristischen Projektinteressen vertreten werden sollen.
- und Die Hardwarevoraussetzungen anderer Programme ändern sich dadurch nicht nennenswert Mr. Anderson 13:09, 20. Jul 2005 (CEST)
- Wie wäre Bei Programmen wird man sich jedoch auch weiterhin an den Verpackungstexten orientieren dürfen. und Nachdem im November 2004 erstmals rechtliche Konflikte mit Ekush OS... (Verlinkung hier wohl eher überflüssig - da das Projekt, wie ich verstanden habe, aufgelöst ist: merged to the ReactOS tree - um aber zu erkären was es ist, vielleicht ein Nebensatz, der die schlichte Kopie und deren 'Verkauf' als eigene Arbeit erwähnt. Etwa , das den Quelltext plagiierte Plagiat lt. Wörterbuch: Veröffentlichung eines urheberrechtlich geschützten Werkes (und das ist es ja schon) unter unrichtiger Autorenangabe.) ...auftraten, wurde damit begonnen, einen "Legal Defense Fund" einzurichten, mithilfe dessen alle juristischen Projektinteressen vertreten werden sollen.
- Ich bitte um Entschuldigung. War die letzten Tage offline. Wie ich sehe, haste's bereits eingebaut - also, ich bin damit zufrieden. Mr. Anderson 18:27, 28. Jul 2005 (CEST)
- Wie wäre Bei Programmen wird man sich jedoch auch weiterhin an den Verpackungstexten orientieren dürfen. und Nachdem im November 2004 erstmals rechtliche Konflikte mit Ekush OS... (Verlinkung hier wohl eher überflüssig - da das Projekt, wie ich verstanden habe, aufgelöst ist: merged to the ReactOS tree - um aber zu erkären was es ist, vielleicht ein Nebensatz, der die schlichte Kopie und deren 'Verkauf' als eigene Arbeit erwähnt. Etwa , das den Quelltext plagiierte Plagiat lt. Wörterbuch: Veröffentlichung eines urheberrechtlich geschützten Werkes (und das ist es ja schon) unter unrichtiger Autorenangabe.) ...auftraten, wurde damit begonnen, einen "Legal Defense Fund" einzurichten, mithilfe dessen alle juristischen Projektinteressen vertreten werden sollen.
Wtf ?
... sowie das Entfernen von Designschwächen des Windows NT Kernels,
die in das Design von ReactOS übernommen wurden.
Waran dachtet du/ihr da genau ? --Maarten Bosma 21:15, 16. Jun 2005 (CEST)
zb " Ab NT 4 läuft das Grafiksubsystem GDI aus Geschwindigkeitsgründen teilweise direkt im Betriebssystemkern, womit Fehler in Grafiktreibern moderne Windows-NT-Versionen zum Absturz bringen können." Quelle: http://de.wikipedia.org/wiki/Microsoft_Windows_NT
- Das ist, finde ich, eine gut nachvollziehbare Design-Entscheidung ("aus Geschwindigkeitsgründen"), und deshalb auch keine Schwäche. Die Bezeichnung im Artikel ist mMn daher zu wertend. --85.180.64.225 13:37, 12. Dez. 2007 (CET)
- Es war eben keine gute Design-Entscheidung, eher eine notwendige (aus damaliger Sicht). Selbstverständlich ist das vom Standpunkt des Betriebssystemdesigns eine Schwäche, allerdings hat man die damit einhergehenden Vorteile als schwerwiegender erachtet. Nicht ohne Grund konnte MS diesen Schritt erst gehen, nachdem der langjährige Chefentwickler und „Vater“ von Windows NT Dave Cutler nicht mehr die Projektverantwortung hatte. Cuttler wollte diesen grundlegenden Paradigmenwechsel in der NT-Architektur damals nicht mittragen. Es war eine firmenpolitische Entscheidung. --Ruscsi 18:43, 12. Dez. 2007 (CET)
- Cuttler und seine Vorgesetzten tun nichts zur Sache, ob man hier von Designschwächen sprechen kann, oder nicht.
- Man kann jedenfalls höchstens davon reden, dass die Entscheidung aus heutiger Sicht fragwürdig ist, damals war sie offenbar eine "gute Sache". Was mir an der Formulierung im Artikel auch nicht gefällt ist, dass von mehreren (eigentlich einer unbestimmten Anzahl) die Rede ist - bisher wird aber nur auf "Grafik läuft teilweise im Kernel" verwiesen. Wo sind die anderen Dinge, die die Formulierung rechtfertigen? Warum stehen keine weiteren im Artikel zu Windows NT oder anderswo? --85.180.65.215 20:23, 13. Dez. 2007 (CET)
- Aber selbstverständlich tut das was zur Sache. Denn selbst Cutler, dem man wohl kaum nachsagen kann, von Entwurf und Entwicklung eines Betriebssystems keine Ahnung zu haben, hielt es offensichtlich für keine gute Designentscheidung. Aus Sicht des Betriebssystemdesigns ist es unzweifelhaft auch keine gute Designentscheidung, das kannst Du in jeder Vorlesung zum Thema Betriebssysteme lernen. Nichtsdestotrotz ist es eine gewollte Dsignentscheidung. Aber „aus heutiger Sicht fragwürdig“ ist die Entscheidung keineswegs, sondern nachvollziehbar, wenn man es unter den damaligen Randbedingungen betrachtet. Die Entscheidung hat sich in der Folge auch nicht als so schwerwiegendes Problem erwiesen, Befürchtungen hinsichtlich schwindender Stabilität und Sicherheit haben sich in der Praxis kaum bewahrheitet. So gilt NT4 (bei dessen Entwicklung der Schritt gemacht wurde) heute rückblickend sogar als ein (zumindest in der Endphase) sehr robustes und stabiles NT-Betriebssystem. Nichtsdestotrotz ist das Problem verringerter Stabilität und Sicherheit bis heute latent vorhanden und hat sicher auch seine Spuren beim Vorgehen bei der Programmierung von Treibern gefunden. Ich bin mir deshalb nicht so sicher, ob es ein Ziel der ReactOS-Entwicklung ist, das zu ändern. Bleibt nämlich die Frage, ob das möglich ist, ohne sich inkompatibel zu bestehenden Treibern zu machen. --Ruscsi 06:04, 15. Dez. 2007 (CET)
- Cuttler tut nichts zur Sache, weil es egal ist, von welchem Oberguru ein Argument stammt. Das Argument steht oder fällt für sich, unabhängig von der Quelle. Deswegen ist der Verweis auf die "firmenpolitische Entscheidung" sinnfrei. So und nicht anders ist das gemeint. Und würdest du bitte aufhören, mal so, mal anders zu argumentieren? Fände ich gut. Die Designentscheidung sei nicht gut, sei nachvollziehbar, aber trotzdem meckerst du noch gegen die Formulierung "aus heutiger Sicht fragwürdig"? Super. Davon abgesehen war der ganze Tanz sowieso umsonst, es ging nicht um Pro oder Contra von Designentscheidungen, sondern rein darum, dass die Formulierung im Artikel zu stark wertet. -- 85.180.67.243 03:55, 30. Mär. 2008 (CEST)
- Und würdest Du bitte aufhören, in diesem Ton zu reden! Wir sind schließlich zivilisierte Menschen die miteinander über alles diskutieren könne, ohne gleich ausfallend zu werden. Und nun würde ich von Dir gerne wissen, wo ich denn mal so und mal so argumentiert habe. Was ist denn für Dich daran so unverständlich, dass eine Designentscheidung zwar nicht gut, aber nachvollziehbar und deshalb aus heutiger Sicht nicht fragwürdig sein muss? Oder hast Du etwa eine "aus heutiger Sicht nicht fragwürdige Designentscheidung" mit einer "für die heutige Zeit guten Designentscheidung" verwechselt? Ich fand die Entscheidung damals sogar fragwürdig, heute aber verständlich. Aber das ist doch kein Grund, beleidigend zu werden. Und Du kommst hier nach vier Monaten daher, machst genau die Änderungen, die Dir eigentlich schon vor Monaten vorschwebten und beweist damit, dass Dir an einer sachlichen Argumentation offensichtlich doch nie gelegen war. Und dann versteckst Du Dich noch hinter einer IP. Wirklich arm. Wenn Dir die Änderungen so wichtig waren, warum hast Du Deine jetzigen Änderungen nicht schon vor Monaten vorgeschlagen? Nun hast Du zwar eine neutrale Formulierung, aber eine, die sogar noch sinnleerer ist als die vorherige: "abweichende Architektur von ReactOS". Na toll. Welche abweichende Architektur soll das denn nun sein? Weicht die „Architektur“ gegenüber dem NT-Design wirklich schon ab? Zudem ist Architektur eigentlich ein ziemlich bedeutungsleerer Begriff, weil er beim Design (hier von Software) eine große Anzahl verschiedener Aspekte beschreiben kann. Aber dieser Fehler findet sich bei WP zu oft, als dass wir jetzt darüber streiten müssten. Aber wenn's Dir so gefällt: Mein Gott, dann werd' halt glücklich. *kopfschüttel* --Ruscsi 15:41, 30. Mär. 2008 (CEST)
Ähnliche Projekte
Ich ergänze Linux zu der Liste der ähnllichen Projekten weil es ebenfalls der GPL Kon eines Closed Source programmes ist!
- Dann sollten es aber auch ähnliche Projekte sein. Ich kann allerdings keine Ähnlichkeit erkennen. Und nur weil ein Projekt auch unter der GPL steht von Ähnlichkeit zu sprechen... naja. Wie wäre es mit "verwandte Projekte" oder "andere Betriebssystem-Projekte". --Ruscsi 14:28, 12. Apr 2005 (CEST)
Ich beziehe die änhlichkeit nicht alleine auf die Lizenz (Die liste wäre etwas lang ;) ) Sondern das Linux ein Klon von Unix (Closed source) wie ReactOS von Windows ( Closed Source) und ebenfalls ein Betribssystem ist. Sollte es einen MacOS Klonunter einer frein Lizent geben würde er auch dazugehören. --Pentiumforever 21:30, 12. Apr 2005 (CEST)
- Die meisten OSse sind Unix basiert. Und vom Kernel her hat Linux nicht alzu viel mit Unix gemein. --Maarten Bosma 21:07, 16. Jun 2005 (CEST)
- Das ist aber eine reine Verhältnisähnlichkeit, etwa in der Form Linux verhält sich zu UNIX wie ReactOS zu Windows; wenn man von Ähnlichkeiten schreibt, versteht der Leser, der diese Diskussion nicht gelesen hat, darunter naturgemäß etwas anderes. Also sind die Ähnlichkeiten von ReactOS, Linux & Co. zwar nicht falsch, aber für zu viele Leser irreführend. Sollte m.E. deshalb raus oder anders formuliert werden. (Vorschlag könnte sein: „Weitere Nachbauten von proprietären Betriebsystemen sind...“) -- Qhx 14:16, 15. Dez. 2007 (CET)
Wine als Kooperationspartner von ReactOS zu bezeichnen ist schlicht falsch. Wine akzeptiert wegen der unter "Rechtliche Fragen" aufgeführten Problematik keinen Code von ReactOS, also existiert de facto keine Kooperation. Siehe Alexandre Juilliards Antwort in http://www.nabble.com/1st-resend:-Can-we-import-MSConfig-from-ReactOS--(was:-autorun-perhaps-dangerous)-td19332453.html oder Dan Kegels Post http://www.winehq.org/pipermail/wine-devel/2006-September/050679.html KaiBlin 08:02, 25. Nov. 2008 (CET)