Wäre es eigentlich möglich, einen Linux-Kernel so zu patchen, dass er nur das tut, was Hurd braucht? Das wäre in meinen Augen zumindest für den Moment ein Ansatz, wenn auch etwas oversized.
Was das für Probleme bei der Architektur mit sich bringt, kann ich natürlich nicht einschätzen.
Wäre man dann effektiv wieder bei null mit der Paketportierung etc. oder hätte das dann kaum Auswirkungen?
Es sollte gar keine Auswirkungen haben. Anwendungen kommunizieren nur indirekt (z.B. über libc) mit dem Kernel. Aber auch libc dürfte sich kaum ändern, denn die Kernel-Schnittstelle ist weitgehend in Stein gemeißelt (POSIX + Erweiterungen) und wird auch nicht im Microkernel, sondern von den »Translatoren« (systemnahen Prozessen) realisiert. In letzterem Punkt spekuliere ich etwas, da ich Hurd nicht so gut kenne.
Ich habe mich zwar mit den Wikipedia-Artikeln auseinandergesetzt aber ich komme da nicht ganz hinter. Hurd selbst war doch als Kernel geplant, dieser Hurd verwendet aber nun einen "non-free-Software", also BSD lizensierten Kernel? Oder ist Hurd nun gar kein richtiger Kernel sondern nur die Device Treiber, oder gar ein Port?
Es wäre wirklich toll wenn jemand diese Situation ein wenig erhellen könnte. Danke!
Bei Microkernels ist die Situation ein bisschen anders als man es etwa von Linux gewohnt ist.
Es gibt einen "Kernel", der quasi nur verwaltet, und darum alle Funktionalität in modularer Form. Ersteres ist soweit ich das verstanden hab MACH, zweiteres HURD.
Wobei BSD-lizensiert nicht non-free heißt. Ist ein anderes Konzept von Lizensierung, aber entspricht dennoch eindeutig der Definition freier Software. BSD-Lizenzen werden etwa von der FSF auch als "frei" anerkannt und Du kannst BSD-Code jederzeit nehmen und unter GPL relizensieren. Der Unterschied ist nur, dass Du mit BSD-Code mehr machen darfst: Nämlich ihn auch in proprietären Projekten weiterverwenden.
"und Du kannst BSD-Code jederzeit nehmen und unter GPL relizensieren"
Da erhebe ich energischen Einspruch. Jeder, der das auch nur versucht, ohne im Besitz des Copyrights bzw. ohne der Urheber/Verfasser der betreffenden BSD-Software zu sein, wird von bsd-violations.org gnadenlos verklagt.
> BSD-Lizenzen werden etwa von der FSF auch als "frei" anerkannt und Du kannst BSD-Code jederzeit nehmen und unter GPL relizensieren.
Da war ich dann wohl falsch informiert. Ich nahm an, ohne es weiter zu überprüfen, dass die BSD-Lizenz laut FSF als "unfrei" gelte, weil eben das Copyleft fehlt. Habe es aber gerade eben nachgeschaut und auf der GNU-Webseite und sie wird dort tatsächlich mit aufgenommen.
Nun ja, wenn Mach nun aber nicht weiterentwickelt wird, werden sie entweder auf etwas eigenes umsteigen müssen, wechseln müssen oder Mach selber weiterentwickeln. Ich frage mich dabei nur: Ist es überhaupt sinnvoll diesen Aufwand zu betreiben? Könnte die Energie und Zeit dann nicht besser in andere Projekte gesteckt werden? Vor allem dürfte bei dieser Entwicklungsgeschwindigkeit das Hurd niemals aktuell genug sein um wirklich von echten Endanwendern genutzt zu werden, die sich gerade mal einen PC kaufen. Auch für Firmen dürfte hier wenig Reiz liegen; diese würden wenn sie etwas kostengünstig haben wollen, auch eher nach Linux greifen, nicht zuletzt ist dieser Kernel ja auch GPL'ed.
Es gibt wohl mehr Konzepte und Algos als es Softwareprojekte gibt. Manchmal ist es einfach notwendig das Rad neu zu erfinden. Sei es weil eine Idee so noch nicht umgesetzt wurde, aus Studienzwecken oder einfach weil man gerade Lust dazu hat. Ohne dem gibt es nur Stillstand. Wozu KDE? Es gab doch schon lange FVWM.
Nicht jeder hat den Anspruch Rechnerparks mit seiner Software laufen zu sehen. Was sich durchsetzt ist manchmal auch einfach nur Glück.
und glaubst du wirklich, wenn man alle Kernelentwickler der Welt (Hurd, Linux, ...BSD, ReactOS, Minix, ...) auf ei gemeinsames Projekt los lässt würde irgendwas entstehen, was halbwegs brauchbar ist?
Wäre man dann effektiv wieder bei null mit der Paketportierung etc. oder hätte das dann kaum Auswirkungen?
Wäre es eigentlich möglich, einen Linux-Kernel so zu patchen, dass er nur das tut, was Hurd braucht? Das wäre in meinen Augen zumindest für den Moment ein Ansatz, wenn auch etwas oversized.
Was das für Probleme bei der Architektur mit sich bringt, kann ich natürlich nicht einschätzen.
Es sollte gar keine Auswirkungen haben. Anwendungen kommunizieren nur indirekt (z.B. über libc) mit dem Kernel. Aber auch libc dürfte sich kaum ändern, denn die Kernel-Schnittstelle ist weitgehend in Stein gemeißelt (POSIX + Erweiterungen) und wird auch nicht im Microkernel, sondern von den »Translatoren« (systemnahen Prozessen) realisiert. In letzterem Punkt spekuliere ich etwas, da ich Hurd nicht so gut kenne.
Ich habe mich zwar mit den Wikipedia-Artikeln auseinandergesetzt aber ich komme da nicht ganz hinter. Hurd selbst war doch als Kernel geplant, dieser Hurd verwendet aber nun einen "non-free-Software", also BSD lizensierten Kernel? Oder ist Hurd nun gar kein richtiger Kernel sondern nur die Device Treiber, oder gar ein Port?
Es wäre wirklich toll wenn jemand diese Situation ein wenig erhellen könnte. Danke!
Bei Microkernels ist die Situation ein bisschen anders als man es etwa von Linux gewohnt ist.
Es gibt einen "Kernel", der quasi nur verwaltet, und darum alle Funktionalität in modularer Form. Ersteres ist soweit ich das verstanden hab MACH, zweiteres HURD.
Wobei BSD-lizensiert nicht non-free heißt. Ist ein anderes Konzept von Lizensierung, aber entspricht dennoch eindeutig der Definition freier Software. BSD-Lizenzen werden etwa von der FSF auch als "frei" anerkannt und Du kannst BSD-Code jederzeit nehmen und unter GPL relizensieren.
Der Unterschied ist nur, dass Du mit BSD-Code mehr machen darfst: Nämlich ihn auch in proprietären Projekten weiterverwenden.
"und Du kannst BSD-Code jederzeit nehmen und unter GPL relizensieren"
Da erhebe ich energischen Einspruch. Jeder, der das auch nur versucht, ohne im Besitz des Copyrights bzw. ohne der Urheber/Verfasser der betreffenden BSD-Software zu sein, wird von bsd-violations.org gnadenlos verklagt.
Die url gibt's gar nicht.
Und warum sollte man verklagt werden, wenn man den Code selbst für propritäre Projekte verwenden kann.
Vielen Dank für die Klärung
> BSD-Lizenzen werden etwa von der FSF auch als "frei" anerkannt und Du kannst BSD-Code jederzeit nehmen und unter GPL relizensieren.
Da war ich dann wohl falsch informiert. Ich nahm an, ohne es weiter zu überprüfen, dass die BSD-Lizenz laut FSF als "unfrei" gelte, weil eben das Copyleft fehlt. Habe es aber gerade eben nachgeschaut und auf der GNU-Webseite und sie wird dort tatsächlich mit aufgenommen.
Nun ja, wenn Mach nun aber nicht weiterentwickelt wird, werden sie entweder auf etwas eigenes umsteigen müssen, wechseln müssen oder Mach selber weiterentwickeln. Ich frage mich dabei nur: Ist es überhaupt sinnvoll diesen Aufwand zu betreiben? Könnte die Energie und Zeit dann nicht besser in andere Projekte gesteckt werden? Vor allem dürfte bei dieser Entwicklungsgeschwindigkeit das Hurd niemals aktuell genug sein um wirklich von echten Endanwendern genutzt zu werden, die sich gerade mal einen PC kaufen. Auch für Firmen dürfte hier wenig Reiz liegen; diese würden wenn sie etwas kostengünstig haben wollen, auch eher nach Linux greifen, nicht zuletzt ist dieser Kernel ja auch GPL'ed.
Es gibt wohl mehr Konzepte und Algos als es Softwareprojekte gibt. Manchmal ist es einfach notwendig das Rad neu zu erfinden. Sei es weil eine Idee so noch nicht umgesetzt wurde, aus Studienzwecken oder einfach weil man gerade Lust dazu hat. Ohne dem gibt es nur Stillstand. Wozu KDE? Es gab doch schon lange FVWM.
Nicht jeder hat den Anspruch Rechnerparks mit seiner Software laufen zu sehen. Was sich durchsetzt ist manchmal auch einfach nur Glück.
und glaubst du wirklich, wenn man alle Kernelentwickler der Welt (Hurd, Linux, ...BSD, ReactOS, Minix, ...) auf ei gemeinsames Projekt los lässt würde irgendwas entstehen, was halbwegs brauchbar ist?
Gutes Argument. Wahrscheinlich würde da nichts raus werden.
OSI-Modell vs. TCP/IP