Die Weiterentwicklung der Open-Source-Werkzeuge, welche die für Ksplice geeigneten Live-Patches generieren und in den Kernel einimpfen, kam sogar vollends zum Erliegen, nachdem Oracle die hinter Ksplice stehende Firma im Jahr 2011 übernommen hatte. In der Konsequenz funktioniert das Live-Patching mit Ksplice heute nur mit Oracle und seinem Ksplice Uptrack getauften Service, der aber z.B. für Red Hat Enterprise Linux kostenpflichtig und für Suse gar nicht verfügbar ist.
Ich glaube du hast nicht ganz verstanden - kGraft funktioniert anders als Ksplice also warum sollte der Code von Ksplice hilfreich sein??? Außerdem - nur weil ein Projekt bereits irgendwie so ähnlich umgesetzt wurde heißt es nicht dass man sich nun an diese Umsetzung klammern muss denn manchmal ist z.B der Code einfach nur wahnsinnig schlecht etc.
Abgesehen davon reden wir hier von Oracle und Oracle hat sowas wie den "Finger des Todes" - denn *vieles* was Oracle anfasst wird von Gold zu Stein oder zerfällt einfach zu Asche ;) Ich hoffe ich muss keine Beispiele aufzählen (weil allseits bekannt) - also dass man nicht mit etwas arbeiten möchte was von Oracle entwickelt wurde kann ich vollends nachvollziehen.
Bei
Die Weiterentwicklung der Open-Source-Werkzeuge, welche die für Ksplice geeigneten Live-Patches generieren und in den Kernel einimpfen, kam sogar vollends zum Erliegen, nachdem Oracle die hinter Ksplice stehende Firma im Jahr 2011 übernommen hatte
musste ich einfach nur lachen weils immer das gleiche alte Lied ist haha
Auf wen beziehst dich denn? Jedenfalls hab ich den Artikel nicht geschrieben. Ksplice funktioniert, steht unter GPL, ist offensichtlich leistungsfähiger. Deshalb entwickelt Suse etwas neues und baut seine Userland Tools unter GPLv3. Wieviel Tools kennst du denn die ähnlich restriktiv und eng verzahnt mit den Kernel sind? Völlig bescheuert ist auch die Argumentation mit Oracle weil demnach gäbe es auch kein LO. Oracle hat offensichtlich Kunden dafür.
"Servers protected with Ksplice Uptrack: 100,000+ at more than 700 companies"
Naja, der Suse Stern ist schon lange im Fall, das hier wird die Entwicklung auch nicht aufhalten können.
In der Konsequenz funktioniert das Live-Patching mit Ksplice heute nur mit Oracle und seinem Ksplice Uptrack getauften Service, der aber z.B. für Red Hat Enterprise Linux kostenpflichtig und für Suse gar nicht verfügbar ist.
Völlig bescheuert ist auch die Argumentation mit Oracle weil demnach gäbe es auch kein LO.
Nein....deine Argumentation ist bescheuert - sieh dir doch einfach mal die Historie von LO an...dann reden wir weiter. Warum ist denn LibreOffice entstanden?
Und nur weil 100,000 und mehr Server in über 700 Unternehmen damit versorgt sind heißt es nicht dass es super ist - du musst auch bedenken dass es Teil eines größeren Pakets sein kann welches das Programm einfach enthält.
Aber lassen wir das mal beiseite. Es geht hier um die *Benutzbarkeit* für *andere*! (Siehe erstes Zitat in dieser Antwort)
Also erstens sollte ohnehin jede Firma die Infrastruktur selbst stellen sonst braucht man irgendwann ein Abo von Oracle. Zweitens ist der Source verfügbar UND man hat Binaries für Ubuntu und Fedora zum herunterladen. Alleine für RHES wird eine 30Tage Demo angeboten.
Und an deiner Rhetorik muss du noch pfeilen. Wo ist denn der Unterschied zwischen Fork OO und Fork Ksplice? Die KSplice Lösung ist jedenfalls bewährt und verfügbar.
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.
Schon wieder dummes Geschwätz auf pro-linux, statt einfach mal Ksplice zu nehmen und das in den Kernel zu integrieren, ist doch schließlich GPL. Wie armselig vom Schwätzer.
Schon wieder, statt einfach mal Ksplice zu nehmen und das in den Kernel zu integrieren, ist doch schließlich GPL. Wie armselig von Suse.
Microsoft könnte auch einfach Android verbessern, anstatt die Windows 8 Extrawurst zu bauen.
Gut gesagt - dann hätte ich mir meinen Kommentar sparen können
Ich glaube du hast nicht ganz verstanden - kGraft funktioniert anders als Ksplice also warum sollte der Code von Ksplice hilfreich sein???
Außerdem - nur weil ein Projekt bereits irgendwie so ähnlich umgesetzt wurde heißt es nicht dass man sich nun an diese Umsetzung klammern muss denn manchmal ist z.B der Code einfach nur wahnsinnig schlecht etc.
Abgesehen davon reden wir hier von Oracle und Oracle hat sowas wie den "Finger des Todes" - denn *vieles* was Oracle anfasst wird von Gold zu Stein oder zerfällt einfach zu Asche ;)
Ich hoffe ich muss keine Beispiele aufzählen (weil allseits bekannt) - also dass man nicht mit etwas arbeiten möchte was von Oracle entwickelt wurde kann ich vollends nachvollziehen.
Bei
musste ich einfach nur lachen weils immer das gleiche alte Lied ist haha
Auf wen beziehst dich denn? Jedenfalls hab ich den Artikel nicht geschrieben.
Ksplice funktioniert, steht unter GPL, ist offensichtlich leistungsfähiger.
Deshalb entwickelt Suse etwas neues und baut seine Userland Tools unter GPLv3. Wieviel Tools kennst du denn die ähnlich restriktiv und eng verzahnt mit den Kernel sind?
Völlig bescheuert ist auch die Argumentation mit Oracle weil demnach gäbe es auch kein LO. Oracle hat offensichtlich Kunden dafür.
"Servers protected with Ksplice Uptrack:
100,000+ at more than 700 companies"
Naja, der Suse Stern ist schon lange im Fall, das hier wird die Entwicklung auch nicht aufhalten können.
Kannst du auch lesen?
Nein....deine Argumentation ist bescheuert - sieh dir doch einfach mal die Historie von LO an...dann reden wir weiter.
Warum ist denn LibreOffice entstanden?
http://de.wikipedia.org/wiki/LibreOffice#Abspaltung_von_Oracle
Und nur weil 100,000 und mehr Server in über 700 Unternehmen damit versorgt sind heißt es nicht dass es super ist - du musst auch bedenken dass es Teil eines größeren Pakets sein kann welches das Programm einfach enthält.
Aber lassen wir das mal beiseite. Es geht hier um die *Benutzbarkeit* für *andere*! (Siehe erstes Zitat in dieser Antwort)
Also erstens sollte ohnehin jede Firma die Infrastruktur selbst stellen sonst braucht man irgendwann ein Abo von Oracle. Zweitens ist der Source verfügbar UND man hat Binaries für Ubuntu und Fedora zum herunterladen. Alleine für RHES wird eine 30Tage Demo angeboten.
Und an deiner Rhetorik muss du noch pfeilen. Wo ist denn der Unterschied zwischen Fork OO und Fork Ksplice? Die KSplice Lösung ist jedenfalls bewährt und verfügbar.
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.
Schon wieder dummes Geschwätz auf pro-linux, statt einfach mal Ksplice zu nehmen und das in den Kernel zu integrieren, ist doch schließlich GPL.
Wie armselig vom Schwätzer.
guggst du da
Da hat ein SUSE Entwickler kSplice auf aktuelleren Kernels zum Laufen gebracht.