Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dtrace for Linux

gnu.wildebeest.org

Post reply on HN
Print view View original

41–50 of 108 posts

Re: Dtrace for Linux

#41

Post by vetinari »

nordsieck wrote: post #39
Conan_Kudo wrote: post #18

Earlier quoted context omitted.

> Things would be much easier if every author would surrender their copyright to OpenZFS project, but some people might have problem with it since then you surrender all claims to the code. This is super-dangerous. There's a reason that copyright assignment agreements are rare. In a lot of jurisdictions, it's not even possible. Most copyright license agreements instead force unlimited sublicensing grants, which provi…

> There's a reason that copyright assignment agreements are rare. In a lot of jurisdictions, it's not even possible. How is a software development business possible under those circumstances? In the US one of the core pieces of every employment contract (for software developers) is IP assignment.

IP assignment itself is a bit of hand-wavy term, that hides a lot.

Those jurisdictions, where you cannot assign authorship, make distinction between being an author and being able to distribute a copyrighted work. It you wrote something, you will be forever the author and you cannot transfer the authorship. What you can transfer is the rights to distribution.

Re: Dtrace for Linux

#42

Post by vetinari »

rhinoceraptor wrote: post #35
rollcat wrote: post #26

Earlier quoted context omitted.

Running ZFS (boot&root) on both Ubuntu 17.10 on my home server and Debian Jessie on my laptop. The ZFS experience between the two is heaven and hell. Ubuntu just ships the zfs.ko and basically everything works 100% of the time, zero effort. Debian OTOH has to compile the module via DKMS for every minor kernel release... You better track those apt upgrades carefully, and run `dkms status` after each one, or you might…

I have a ZFS on root Arch setup, unfortunately Gnome 3 is such garbage nowadays that I hardly ever use it. It still doesn’t do display scaling correctly for 4K and it just crashes all the time.

There is something seriously wrong with your setup.

Re: Dtrace for Linux

#43

Post by gmueckl »

nordsieck wrote: post #39
Conan_Kudo wrote: post #18

Earlier quoted context omitted.

> Things would be much easier if every author would surrender their copyright to OpenZFS project, but some people might have problem with it since then you surrender all claims to the code. This is super-dangerous. There's a reason that copyright assignment agreements are rare. In a lot of jurisdictions, it's not even possible. Most copyright license agreements instead force unlimited sublicensing grants, which provi…

> There's a reason that copyright assignment agreements are rare. In a lot of jurisdictions, it's not even possible. How is a software development business possible under those circumstances? In the US one of the core pieces of every employment contract (for software developers) is IP assignment.

I can only speak for Germany. Here, we have a big exception to the normal rule that you own the rights and cannot reassign them: everything you create during work hours under a normal employment contract is automatically the property of your employer. Even if you create stuff outisde work that may be useful for the employer, the company has access and may get the rights (for a fair compensation according to the law).

Also, even though you cannot reassign ownership, you can grant exclusive rights. This is the closest analog to assignment of copyright.

Re: Dtrace for Linux

#44

Post by gribbly »

Annatar wrote: post #40
paride5745 wrote: post #3

Time for ZFS now! Even better yet, a new OpenSolaris under GPL instead of CDDL.

That day better never come; If the last thing I dearly love, illumos (there is no OpenSolaris any more) ever gets relicensed under that fascist GPL, I’ll never write another line of code again. That would be the last straw.

I can understand why someone does not like GPL, but calling a license which says you have to pass on the same rights you were given a 'fascist' license makes absolutely zero sense.

Re: Dtrace for Linux

#45

Post by HankB99 »

rollcat wrote: post #26
HankB99 wrote: post #20

Earlier quoted context omitted.

> ... but it would still be annoying to actually use ZFS in Linux for the same reason it is annoying to use it now. For those of us who are ignorant of what is annoying to use now (I raise my hand) can you elaborate? I'm fooling around with it on Debian Stretch and Ubuntu 16.04 LTS and haven't yet found it annoying (except for the challenge of finding where the various command line switches are documented...) I was p…

Running ZFS (boot&root) on both Ubuntu 17.10 on my home server and Debian Jessie on my laptop. The ZFS experience between the two is heaven and hell. Ubuntu just ships the zfs.ko and basically everything works 100% of the time, zero effort. Debian OTOH has to compile the module via DKMS for every minor kernel release... You better track those apt upgrades carefully, and run `dkms status` after each one, or you might…

Thanks for the info. I don't recall if Stretch requires module rebuilds on kernel updates but that hasn't bothered me in the past. And I always reboot before removing old kernels just to make sure that I don't really need them.

I'm using ZFS on extra storage - not on /, /boot or /home. On one box I do have a ZFS volume mounted to my ~/Documents directory. I did try to install ZFS on the boot device and after thrashing a bit I decided to wait until the installer supports it. I have a file server and remote file server for backups and I'm preparing upgrades for both that put the served filesystem on ZFS and sends incremental snapshots to the remote to keep it synced. The existing system uses `rsync` to synchronize.

Re: Dtrace for Linux

#46

Post by aardvark291 »

AceJohnny2 wrote: post #28
brendangregg wrote: post #9

Unfortunately for DTrace, this is too late. Oracle should have done this years ago. Now Linux has a more powerful tracer builtin, eBPF, and it would be a backwards step to switch the kernel code to DTrace (assuming the DTrace port is completed, which it is not). I'm sure this will not be lost on the maintainers, who have the ultimate say as to what is included in Linux mainline. The only hope for DTrace is to have th…

Tangential, but I feel the need to quote Dan Colascione: "Ah Linux, in which a thread is a process, a semantic patch is a lint rule, and a packet filter is a system profiler." ;) (but seriously, your work in exploring and expanding it has been wonderful. Thank you!)

What does this mean? I don't really understand the quote.

Re: Dtrace for Linux

#47

Post by blinkingled »

aardvark291 wrote: post #46
AceJohnny2 wrote: post #28

Earlier quoted context omitted.

Tangential, but I feel the need to quote Dan Colascione: "Ah Linux, in which a thread is a process, a semantic patch is a lint rule, and a packet filter is a system profiler." ;) (but seriously, your work in exploring and expanding it has been wonderful. Thank you!)

What does this mean? I don't really understand the quote.

The Linux kernel treats threads no different than processes that share an address space which is unusual in UNIX land.

Semantic patch probably refers to coccinelle - look it up, it's pretty cool, makes it easy to deal with API changes, renames etc.

eBPF comes from extended Berkeley Packet Filter - where packet filter code is JITed to be fast. It's also used for dtrace like tracing along with kprobes to run profiling code in kernel safely.

Re: Dtrace for Linux

#48

Post by [deleted] »

aardvark291 wrote: post #46
AceJohnny2 wrote: post #28

Earlier quoted context omitted.

Tangential, but I feel the need to quote Dan Colascione: "Ah Linux, in which a thread is a process, a semantic patch is a lint rule, and a packet filter is a system profiler." ;) (but seriously, your work in exploring and expanding it has been wonderful. Thank you!)

What does this mean? I don't really understand the quote.

[deleted]

Re: Dtrace for Linux

#49

Post by d33 »

aardvark291 wrote: post #46
AceJohnny2 wrote: post #28

Earlier quoted context omitted.

Tangential, but I feel the need to quote Dan Colascione: "Ah Linux, in which a thread is a process, a semantic patch is a lint rule, and a packet filter is a system profiler." ;) (but seriously, your work in exploring and expanding it has been wonderful. Thank you!)

What does this mean? I don't really understand the quote.

"Linux uses a 1-1 threading model, with (to the kernel) no distinction between processes and threads -- everything is simply a runnable task."

https://stackoverflow.com/a/809049

"semantic patches" probably refer to Coccinelle:

http://coccinelle.lip6.fr/

eBPF is extended Berkeley Packet Filter":

https://en.wikipedia.org/wiki/eBPF

Re: Dtrace for Linux

#50

Post by bri3d »

aardvark291 wrote: post #46
AceJohnny2 wrote: post #28

Earlier quoted context omitted.

Tangential, but I feel the need to quote Dan Colascione: "Ah Linux, in which a thread is a process, a semantic patch is a lint rule, and a packet filter is a system profiler." ;) (but seriously, your work in exploring and expanding it has been wonderful. Thank you!)

What does this mean? I don't really understand the quote.

BPF started as the Berkeley Packet Filter, a language for declaring network packet filtering rules and eventually, a pretty good JITted virtual machine runtime for applying these rules quickly. However, it's since evolved to a generic filtering VM and been applied to system trace and other kernel-level filtering usecases.

Historically, threads on Linux were implemented as process-alike tasks and even had unique PIDs, which caused all sorts of hell for vanilla-POSIX threaded applications.

And, in Linux, code style differences in device drivers led to (rather than a codestyle enforced by an automatic formatter) "semantic patches" - patches that can apply to code regardless of its formatting.

Post reply on HN