Hahaha ich muss also an meiner Rhetorik "pfeilen"? Der war gut - das heißt "feilen". Es sei denn "pfeilen" hat auch eine Bedeutung die mir nicht geläufig ist....;)
Naja der Fork von OO war notwendig - das weiß jedes Kind...lies dir die Geschichte einfach mal irgendwo durch. Ich bin nicht hier um dich darüber aufzuklären.
Du redest von "bewährt" - woher weißt du das? Unter "bewährt" verstehe ich "allgemein anerkannt und häufig verwendet" und ich rede nicht von irgendwelchen Installationen bei Firmen die Kunden von Oracle sind. Das ist wie ich bereits gesagt habe kein Beweis und nicht mal ein Indiz für "bewährt".
Die Suse-Leute haben sich für eine andere Art der Umsetzung entschieden und dies auch begründet! Ksplice funktioniert anders.
Man habe sich bewusst für diesen Ansatz entschieden, um auf einige erst in den letzten Jahren entstanden Technologien des offiziellen Kernels zurückgreifen zu können und um ein einfaches Code-Design zu ermöglichen.
Diese Gründe kann ich als Entwickler gut nachvollziehen also ist es eher unwahrscheinlich dass Ksplice welches (wie gesagt) anders funktioniert für sie sinnvoll sein könnte.
Wenn ich ein Programm schreiben möchte dass es mit solchen Funktionalitäten bereits gibt z.B. ein Dateimanager aber sagen wir mal ich verwende ein völlig anderes Konzept um diesen Dateimanager zu programmieren, dann bringen mir Quelltexte von Dateimanagern die bereits existieren ziemlich wenig wenn ich eh 90% umschreiben müsste. Ich könnte vielleicht ein paar GUI-Elemente übernehmen wenn "nur" die Interna völlig anders sind.
Im Endeffekt entscheiden der Nutzer bzw. die Distributoren - war doch bei den Startsystemen unter Linux genauso und systemd hat gewonnen (kann man so sagen) also lass doch den Suse-Leuten wenigstens einen Versuch - vielleicht finden wir es nachher in vielen Distributionen standardmäßig
Wie gesagt: Wenn ich in der Lage der Suse-Entwickler wäre würde ich das Zeug von Oracle auch nicht übernehmen. Es hat Gründe warum nicht wenig Entwickler von denen weggerannt sind - Informieren hilft
Bei über 100000 Server im Einsatz, Alternativen kaum vorhanden, genau das entspricht der Definition von bewährt. Dein Zitat bestätigt geradezu das hier NIH die Hauptmotivation ist, nicht die techn. Unterlegenheit des aktuellen Ansatzes. Der akt. ist sogar minderwertiger. Erstens wäre dann dein Dateimanager nicht im Kernel, zweitens erzwingst du auch nicht das andere sich mit deinen Blödsinn auseinandersetzen müssen. Du kannst ja gerne dein Kram entwickeln, aber dann sollte es wenigstens Hand und Fuß haben und wieso muss das Teil vom off. Kernel sein. Als ob der nicht schon groß genug ist. Ich hab' nicht sonderlich viel Vertrauen, dass Suse noch in der Lage ist was sinnvolles zu produzieren.
Bei über 100000 Server im Einsatz, Alternativen kaum vorhanden, genau das entspricht der Definition von bewährt. Dein Zitat bestätigt geradezu das hier NIH die Hauptmotivation ist, nicht die techn. Unterlegenheit des aktuellen Ansatzes. Der akt. ist sogar minderwertiger. Erstens wäre dann dein Dateimanager nicht im Kernel, zweitens erzwingst du auch nicht das andere sich mit deinen Blödsinn auseinandersetzen müssen. Du kannst ja gerne dein Kram entwickeln, aber dann sollte es wenigstens Hand und Fuß haben und wieso muss das Teil vom off. Kernel sein. Als ob der nicht schon groß genug ist. Ich hab' nicht sonderlich viel Vertrauen, dass Suse noch in der Lage ist was sinnvolles zu produzieren.
Hahaha ich muss also an meiner Rhetorik "pfeilen"?
Der war gut - das heißt "feilen". Es sei denn "pfeilen" hat auch eine Bedeutung die mir nicht geläufig ist....;)
Naja der Fork von OO war notwendig - das weiß jedes Kind...lies dir die Geschichte einfach mal irgendwo durch. Ich bin nicht hier um dich darüber aufzuklären.
Du redest von "bewährt" - woher weißt du das?
Unter "bewährt" verstehe ich "allgemein anerkannt und häufig verwendet" und ich rede nicht von irgendwelchen Installationen bei Firmen die Kunden von Oracle sind.
Das ist wie ich bereits gesagt habe kein Beweis und nicht mal ein Indiz für "bewährt".
Die Suse-Leute haben sich für eine andere Art der Umsetzung entschieden und dies auch begründet!
Ksplice funktioniert anders.
Diese Gründe kann ich als Entwickler gut nachvollziehen also ist es eher unwahrscheinlich dass Ksplice welches (wie gesagt) anders funktioniert für sie sinnvoll sein könnte.
Wenn ich ein Programm schreiben möchte dass es mit solchen Funktionalitäten bereits gibt z.B. ein Dateimanager aber sagen wir mal ich verwende ein völlig anderes Konzept um diesen Dateimanager zu programmieren, dann bringen mir Quelltexte von Dateimanagern die bereits existieren ziemlich wenig wenn ich eh 90% umschreiben müsste. Ich könnte vielleicht ein paar GUI-Elemente übernehmen wenn "nur" die Interna völlig anders sind.
Im Endeffekt entscheiden der Nutzer bzw. die Distributoren - war doch bei den Startsystemen unter Linux genauso und systemd hat gewonnen (kann man so sagen) also lass doch den Suse-Leuten wenigstens einen Versuch - vielleicht finden wir es nachher in vielen Distributionen standardmäßig
Wie gesagt: Wenn ich in der Lage der Suse-Entwickler wäre würde ich das Zeug von Oracle auch nicht übernehmen. Es hat Gründe warum nicht wenig Entwickler von denen weggerannt sind - Informieren hilft
Bei über 100000 Server im Einsatz, Alternativen kaum vorhanden, genau das entspricht der Definition von bewährt. Dein Zitat bestätigt geradezu das hier NIH die Hauptmotivation ist, nicht die techn. Unterlegenheit des aktuellen Ansatzes. Der akt. ist sogar minderwertiger.
Erstens wäre dann dein Dateimanager nicht im Kernel, zweitens erzwingst du auch nicht das andere sich mit deinen Blödsinn auseinandersetzen müssen. Du kannst ja gerne dein Kram entwickeln, aber dann sollte es wenigstens Hand und Fuß haben und wieso muss das Teil vom off. Kernel sein. Als ob der nicht schon groß genug ist.
Ich hab' nicht sonderlich viel Vertrauen, dass Suse noch in der Lage ist was sinnvolles zu produzieren.
Bei über 100000 Server im Einsatz, Alternativen kaum vorhanden, genau das entspricht der Definition von bewährt. Dein Zitat bestätigt geradezu das hier NIH die Hauptmotivation ist, nicht die techn. Unterlegenheit des aktuellen Ansatzes. Der akt. ist sogar minderwertiger.
Erstens wäre dann dein Dateimanager nicht im Kernel, zweitens erzwingst du auch nicht das andere sich mit deinen Blödsinn auseinandersetzen müssen. Du kannst ja gerne dein Kram entwickeln, aber dann sollte es wenigstens Hand und Fuß haben und wieso muss das Teil vom off. Kernel sein. Als ob der nicht schon groß genug ist.
Ich hab' nicht sonderlich viel Vertrauen, dass Suse noch in der Lage ist was sinnvolles zu produzieren.