Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Kommt DTrace für den Linux-Kernel?

13 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
mehr GPL
1
Von WackelDackel am Do, 15. Februar 2018 um 18:39 #

Womit sich wieder einmal zeigt, dass die ach so viel freieren Non-Copy-Left Lizenzen eben auch leicht zu mehr Unfreiheit führen können. Siehe Apples Klau des BSD-Kernels. Oracle hätte das mit DTrace im Kernel sicher auch gerne gemacht. Ging eben nicht und so war es dann doch einfacher...

  • 1
    Von Anonymous am Sa, 17. Februar 2018 um 07:33 #

    Siehe Apples Klau des BSD-Kernels.

    Moment, der BSD Kernel besitzt zwar eine offene, aber auf keinem Fall eine freie Lizenz.
    Vielleicht solltest du dich informieren, bevor du hier Blödsinn schreibst!

    • 0
      Von blablabla233 am Mo, 19. Februar 2018 um 21:32 #

      Tzzz...BSD ist sehr wohl frei oder was schränkt dich mit der BSD ein? Zudem hat Apple keinen BSD-Kernel geklaut....halbwissen in geballter Form :up:

    0
    Von djaxa am Sa, 17. Februar 2018 um 11:21 #

    Apples Klau des BSD-Kernels? Dir ist schon bewusst, dass der Unterbau vom macOS noch immer frei ist ? Nennt sich übrigens Darwin. "Nur" die GUI ist proprietär. Außerdem gibt es "den" BSD-Kernel nicht sondern mehrere Kernel unter BSD-Lizenz, die zugegebener Maßen von einander abstammen. Im Falle Apple handelt es sich zudem um eine Kombination aus FreeBSD, Mach und NeXT.

    Hier gibt 's überall (Re-)Sourcen:

    https://developer.apple.com/opensource/
    https://www.macosforge.org/
    https://opensource.apple.com/

    ...kann fortgesetzt werden.

    Speziell macOS ist hier:

    https://opensource.apple.com/release/macos-10133.html

    Genügt das?

    Und noch etwas:
    DTrace stand bisher unter der CDDL. Die CDDL _ist_ eine Copy-Left Lizenz, wie die GPL auch. Somit kann in Abwandlung gesagt werden: Womit sich wieder einmal zeigt, dass die ach so viel freieren Copy-Left Lizenzen eben auch leicht zu mehr Unfreiheit führen können.

    Abgesehen davon verstehe ich bis heute nicht, wo das Problem im Mix von CDDL und GPL liegen soll. Vielleicht 2x copyleft passt halt nicht.

    Djaxa

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 17. Feb 2018 um 11:29.
1
Von doe am Fr, 16. Februar 2018 um 00:06 #

Es wäre schön gewesen wenn man seinen Artikel mehr an der Realität ausgerichtet hätte statt irgendein Blog wiederzugeben. Vor 2 Wochen war die FOSDEM, welch' Wunder lief da ein Vortrag zu DTrace in Linux von einem offiziellen Oracle Mitarbeiter.
Da wird doch hervorgehoben das man eben nicht linuxzentrisch sein will, was soll da die Anbindung an Ebpf bringen?
DTrace findet ja auch noch in NetBSD und FreeBSD Einsatz, die aktive Entwicklung ist bei Illumos-Derivaten.
Oracle hat gerade noch die Manpower den Code zu warten.

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Feb 2018 um 00:07.
  • 0
    Von Antiquities am Fr, 16. Februar 2018 um 07:58 #

    hart an der Realität, denn nicht Oracle leidet unter Entwicklerschwund sondern BSD seit langem und ziemlich massiv.

    0
    Von BSD-Horst am Sa, 17. Februar 2018 um 12:37 #

    Ich hätte zu der immer und immer wieder wiederholten Aussage, dass die BSDs unter einem massiven Entwicklerschwund leiden, gerne mal eine belastbare Quelle gesehen.

0
Von Felix Schwarz am Fr, 16. Februar 2018 um 11:07 #

Lohnen würde sich das allemal, da die ähnlichen Projekte SystemTap und Dynamic Probes sowie das im Linux-Kernel selbst entstandene Perf-Subsystem trotz aller Fortschritte immer noch deutlich hinter DTrace rangieren und nicht gut miteinander integriert sind.

Mit der obigen Aussage habe ich so meine Schwierigkeiten. Aus Sicht der DTrace-Entwickler/-Fans stimmt das sicherlich. Andererseits war die Reaktion "der" Linux-Kernelentwickler eher verhalten.

Grundtenor war fast immer "too little, too late". Vor 10 Jahren wäre demnach es eine sehr wertvolle Ergänzung für Linux gewesen, aber inzwischen wären eBPF/perf so viel besser geworden, dass DTrace kaum noch Mehrwert bringen würde. Die userspace-Anwendungen seien wohl besser, aber bei diesen ist GPL-Kompatibilität nicht so wichtig und man hätte den userspace-Teil auch bislang schon auf Linux-spezifische Mechanismen anpassen können.

Gegen einen schnellen Merge spricht zudem, dass DTrace in gewisser Weise vorhandene tracing-Funktionalität dupliziert und das wird nicht gerne gesehen, zumal tracing ja auch alle Teile des Systems betrifft, sodass auch alle Maintainer dort mitreden wollen.

Natürlich ist es aus Solaris-/BSD-Adminsicht schön, wenn man das gleiche Werkzeug "überall" verwenden kann, aber das war ja noch nie ein Argument für die Linux-Entwickler.

Das größte Problem sehe ich aber darin, dass deklarierte tracepoints als Teil der "userspace ABI" angesehen werden können. Das ist im Zusammenhang mit powertop vor einigen Jahren schon passiert. Daraufhin mussten die entsprechenden tracepoints beibehalten werden. Daher reagieren viele Maintainer sehr ablehnend auf tracepoints in ihren Subsystem und das wiederum verringert den Wert eines tracing-Frameworks doch erheblich.

Wie es der Zufall so will, gibt es aber gerade heute einen LWN-Artikel über einen Vorschlag (https://lwn.net/Articles/747262/), wie man das Problem "tracepoints werden Teil der Kernel-ABI" vermeiden könnte:
https://lwn.net/Articles/747256/ (sorry Paywall für 1-2 Wochen, LWN-Abo lohnt sich aber)

Aus diesen Gründen finde ich den oben zitierten Satz des Artikels irreführend bzw. ich hätte mir eine Einordnung der Aussage gewünscht.

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Feb 2018 um 11:08.
Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung