Naja es stellt sich die frage in wie weit beide entwicklergruppen von dem jeweils anderen projekt wussten. Bei Ubuntu ist das damals ja ein wenig was anderes gewesen, weil sie erst wayland propagiert haben und dann trotzdem (hinter verschlossenen türen) etwas anderes gemacht haben. Aber ich möchte hier das window manager thema nicht aufgreifen.
erst mal abwarten: Ich erwarte, dass sich die Suse+Red Hat-Entwickler zusammensetzen und auf eine Lösung einigen. Alternativ wird nur eine der beiden Varianten in den Kernel kommen und die anderen lassen daraufhin ihre Lösung sterben.
Unterschied Canonical: Es ist klar ersichtlich, welche Lösung das Rennen machen wird, Canonical hält aber trotzdem am eigenen Code fest und ändert trotz aller Kritik (z.B. CLA) nichts am eigenen Kurs.
Von Bernhard M. am Do, 13. Februar 2014 um 21:51 #
Ich weiß, dass darüber zuvor absichtlich nicht viel geschrieben wurde.
Wenn die Technik so wie kSplice funktioniert, muss gar kein Code in den Kernel kommen. Natürlich kann man immernoch beim User-space code sich die Arbeit teilen.
Debian wohl nicht selber als Projekt, da sind die Ressourcen meist eher knapp, eher noch Canonical.
Trotzdem begrüsse ich es, dass nun von Seiten SuSE und RH neue Anstrengungen gemacht werden, um den Kernel live zu patchen, nachdem Oracle Ksplice leider quasi-proprietär gemacht hat.
Mit Ego hat das nichts zu tun, es geht um alleinstellungsmerkmale um Geld zu verdienen. Ich sehe da allerdings, inbesondere bei solchen Enterprise Geschichten wie Laufzeit Patching, auch keine echten Probleme.
Und bitte, was hat das jetzt wieder mit Android zu tun?
Fehlt noch das Ubuntu und Debian an was eigenes frickeln.
Was tatsächlich fehlt, ist der Mob mit Fackeln und Mistforken, der RedHat dafür die Scheune anzünden will. So misst man eben mit zweierlei Maß.
Ich Ubuntu würde genügen und alle Ticken hier wieder aus... Das Red Hat wieder hier sein eigenes Ding macht... wird wenige stören
Naja es stellt sich die frage in wie weit beide entwicklergruppen von dem jeweils anderen projekt wussten. Bei Ubuntu ist das damals ja ein wenig was anderes gewesen, weil sie erst wayland propagiert haben und dann trotzdem (hinter verschlossenen türen) etwas anderes gemacht haben. Aber ich möchte hier das window manager thema nicht aufgreifen.
erst mal abwarten: Ich erwarte, dass sich die Suse+Red Hat-Entwickler zusammensetzen und auf eine Lösung einigen. Alternativ wird nur eine der beiden Varianten in den Kernel kommen und die anderen lassen daraufhin ihre Lösung sterben.
Unterschied Canonical: Es ist klar ersichtlich, welche Lösung das Rennen machen wird, Canonical hält aber trotzdem am eigenen Code fest und ändert trotz aller Kritik (z.B. CLA) nichts am eigenen Kurs.
Ich weiß, dass darüber zuvor absichtlich nicht viel geschrieben wurde.
Wenn die Technik so wie kSplice funktioniert, muss gar kein Code in den Kernel kommen.
Natürlich kann man immernoch beim User-space code sich die Arbeit teilen.
Debian wohl nicht selber als Projekt, da sind die Ressourcen meist eher knapp, eher noch Canonical.
Trotzdem begrüsse ich es, dass nun von Seiten SuSE und RH neue Anstrengungen gemacht werden, um den Kernel live zu patchen, nachdem Oracle Ksplice leider quasi-proprietär gemacht hat.
Du meinst so proprietär wie Android?
Ich würde mir wünschen die Firmen würden ihr Ego einmal hintenanstellen und gemeinsam an einem Strang ziehen.
Mit Ego hat das nichts zu tun, es geht um alleinstellungsmerkmale um Geld zu verdienen. Ich sehe da allerdings, inbesondere bei solchen Enterprise Geschichten wie Laufzeit Patching, auch keine echten Probleme.
Und bitte, was hat das jetzt wieder mit Android zu tun?
Hm. Und welche der drei Möglichkeiten kommt bei Parallels Virtuozzo/Parallels Cloud Server zum Einsatz?
Oder gibt es noch eine vierte?