3 ms·

There aren't "licensing issues" with DTrace -- you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. But it is de

There aren't "licensing issues" with DTrace -- you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. But it is definitely true that they are not seeking to solve the same problems! Safety is very core to DTrace[0]; the difference here is entirely deliberate. [0] https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/ https://bcantrill.dtrace.org/2005/07/19/dtrace-safety/

ta8645 3y ago
AFAIU, it goes beyond safety; eBPF is designed to run entirely in the kernel rather than requiring a user-space bridge. So it's able to operate at line speeds in networking scenarios etc. > you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. Not really. I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. > not seeking to solve the same problems! Exactly. eBPF has a much broader and more significant problem set, not just tracing, but also security modules, software defined networking, and an almost unlimited future potential as well.
- bcantrill 3y ago
  A few points of clarification: - DTrace does execute entirely in the kernel. Indeed, anonymous tracing is instrumenting the system without any corresponding user process whatsoever - DTrace exists on quite a few systems, including (with caveats) Windows, MacOS and Linux. - The unbounded nature of eBPF very much runs contrary to the safety that DTrace assures; DTrace isn't seeking to augment the system, but merely to understand it
  - tdullien 3y ago
    eBPF has only recently become less bounded, at 4.15 for example it was still very bounded ;). (I assume you mean maximum # of instructions etc?)
- bch 3y ago
  > I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. I don’t know if there’s some qualification I’m missing in your statement, but does this not count? https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/dtrace https://learn.microsoft.com/en-us/windows-hardware/drivers/d... https://opensource.apple.com/source/dtrace/ https://opensource.apple.com/source/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://github.com/dtrace4linux/linux https://github.com/dtrace4linux/linux
  - ta8645 3y ago
    > https://github.com/dtrace4linux/linux https://github.com/dtrace4linux/linux Last commit, 5 years ago. While you're correct to say that DTrace is available on Linux, it is so restricted as to be much less capable than eBPF. It is the reason it will become a footnote, and eBPF will become ubiquitous.
    - bcantrill 3y ago
      It may become a footnote on Linux, but Linux isn't the only system out there -- and DTrace remains alive and well in many systems (not least in its reference implementation in illumos[0]). [0] https://github.com/illumos/illumos-gate https://github.com/illumos/illumos-gate
      - ta8645 3y ago
        You're discounting the network effects. Also, eBPF provides many more capabilities beyond dTrace, and it will be ubiquitous across all OS, without having to make the exception for Linux. Anyone targeting full cross-platform capabilities will be better served by eBPF. The unfortunate history that crippled dTrace on Linux, will lead to its ultimate sidelining.
        bcantrill 3y ago
        I don't really know what you mean by network effects, but perhaps we're just talking about two different things: you are looking at eBPF as a substrate to deliver arbitrary software (?!) whereas I view DTrace exclusively as a diagnostic tool. As to their relative capabilities: its other potential advantages aside, eBPF (and the tooling built upon it like bcc) lacks much of the functionality and polish of DTrace when attempting to accurately instrument the system. Its lack of robustness makes even basic instrumentation challenging,[0] let alone the richer (and admittedly, more esoteric) features of DTrace that it's missing entirely. [0] https://oxide-and-friends.transistor.fm/episodes/mr-nagles-wild-ride https://oxide-and-friends.transistor.fm/episodes/mr-nagles-w...

ta8645 3y ago

AFAIU, it goes beyond safety; eBPF is designed to run entirely in the kernel rather than requiring a user-space bridge. So it's able to operate at line speeds in networking scenarios etc. > you are merely referring to the fact that it is licensed under the MPL-derived CDDL and not the GPL. Not really. I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. > not seeking to solve the same problems! Exactly. eBPF has a much broader and more significant problem set, not just tracing, but also security modules, software defined networking, and an almost unlimited future potential as well.

bcantrill 3y ago
A few points of clarification: - DTrace does execute entirely in the kernel. Indeed, anonymous tracing is instrumenting the system without any corresponding user process whatsoever - DTrace exists on quite a few systems, including (with caveats) Windows, MacOS and Linux. - The unbounded nature of eBPF very much runs contrary to the safety that DTrace assures; DTrace isn't seeking to augment the system, but merely to understand it
- tdullien 3y ago
  eBPF has only recently become less bounded, at 4.15 for example it was still very bounded ;). (I assume you mean maximum # of instructions etc?)
bch 3y ago
> I'm referring to the fact the eBPF will be available across Microsoft, Apple, and Linux, and there is no other technology that will be able to offer that. I don’t know if there’s some qualification I’m missing in your statement, but does this not count? https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/dtrace https://learn.microsoft.com/en-us/windows-hardware/drivers/d... https://opensource.apple.com/source/dtrace/ https://opensource.apple.com/source/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://docs.freebsd.org/en/books/handbook/dtrace/ https://github.com/dtrace4linux/linux https://github.com/dtrace4linux/linux
- ta8645 3y ago
  > https://github.com/dtrace4linux/linux https://github.com/dtrace4linux/linux Last commit, 5 years ago. While you're correct to say that DTrace is available on Linux, it is so restricted as to be much less capable than eBPF. It is the reason it will become a footnote, and eBPF will become ubiquitous.
  - bcantrill 3y ago
    It may become a footnote on Linux, but Linux isn't the only system out there -- and DTrace remains alive and well in many systems (not least in its reference implementation in illumos[0]). [0] https://github.com/illumos/illumos-gate https://github.com/illumos/illumos-gate
    - ta8645 3y ago
      You're discounting the network effects. Also, eBPF provides many more capabilities beyond dTrace, and it will be ubiquitous across all OS, without having to make the exception for Linux. Anyone targeting full cross-platform capabilities will be better served by eBPF. The unfortunate history that crippled dTrace on Linux, will lead to its ultimate sidelining.
      - bcantrill 3y ago
        I don't really know what you mean by network effects, but perhaps we're just talking about two different things: you are looking at eBPF as a substrate to deliver arbitrary software (?!) whereas I view DTrace exclusively as a diagnostic tool. As to their relative capabilities: its other potential advantages aside, eBPF (and the tooling built upon it like bcc) lacks much of the functionality and polish of DTrace when attempting to accurately instrument the system. Its lack of robustness makes even basic instrumentation challenging,[0] let alone the richer (and admittedly, more esoteric) features of DTrace that it's missing entirely. [0] https://oxide-and-friends.transistor.fm/episodes/mr-nagles-wild-ride https://oxide-and-friends.transistor.fm/episodes/mr-nagles-w...