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...
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!
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.
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.
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.
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.
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.
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...
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!
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
Hier lesen!
http://www.gnu.org/licenses/license-list.html
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.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.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 16. Feb 2018 um 00:07.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.
hart an der Realität, denn nicht Oracle leidet unter Entwicklerschwund sondern BSD seit langem und ziemlich massiv.
Du machen Kommasetzung.
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.
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.