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

An Unbelievable Demo

brendangregg.com

Post reply on HN
Print view View original

41–50 of 478 posts

Re: An Unbelievable Demo

#41

Post by ZephyrBlu »

BrissyCoder wrote: post #25
ZephyrBlu wrote: post #22

Earlier quoted context omitted.

Why do you find it cringe? In NZ I think it's even more true than Australia. It's a tiny, isolated country with a small population that isn't the hub of anything really. Aussie and NZ compared to the US are completely different worlds in my eyes. (I'm a Kiwi btw)

I think it's a myth that NZ "punches above it's weight" is all. Show me some empirical evidence if you disagree. I'm a Kiwi too - but living in Aus.

I think there are lower expectations of Aus/NZ because they're relatively small and out-of-the-way countries (Maybe less so for Aussie), so it's surprising how often they seem to excel in things.

The obvious examples that come to mind would be sports. NZ excels in Sailing, Cricket and Rugby against much larger countries.

Though it could be that in general, Aus/NZ have the same skill distribution as other countries, but they just stand out more because there are lower expectations or highly skilled people are rarer overall due to lower populations.

Re: An Unbelievable Demo

#42

Post by throwawaye3735 »

anyfoo wrote: post #39
throwawaye3735 wrote: post #35

Ok, maybe i'm too old or experienced with these type of things to really enjoy this article. The author might honestly be sincere as he wrote this but I felt it was a bit overblown and coming from negative feelings of being brushed off and rightfully so being upset that his code was stolen. It could just be there are some cultural misunderstandings as well. He mentioned this "VIP" is a "Developer and dtrace expert".…

Brendan Gregg has a lot of clout. Besides that, he did eventually work at Sun proper, and later Joyent. I have no reason not to believe his account.

I am not saying it's factually incorrect. My point is that it includes a lot of Gregg's personal feelings (and maybe was informed incorrectly about the situation) and I'm just not sold that the guy who was assigned to show off Dtrace was the bad guy here

Re: An Unbelievable Demo

#43

Post by brendangregg »

andi999 wrote: post #29
allurbase wrote: post #9

Great article. Disgusting behavior. Seems like the sort of experience that sticks with you for years.

Was there actually no follow-up? Change of header?

I never got a chance to see it again. I ended up spending more energy with another Sun project that wanted to switch the CDDL license to the GPL, only because they wanted to avoid going through the legal approval procedure to ship mixed-licensed products. Maybe I'll share that story one day: it was another eye-opening experience.

Re: An Unbelievable Demo

#45

Post by lukeh »

throwawaye3735 wrote: post #35

Ok, maybe i'm too old or experienced with these type of things to really enjoy this article. The author might honestly be sincere as he wrote this but I felt it was a bit overblown and coming from negative feelings of being brushed off and rightfully so being upset that his code was stolen. It could just be there are some cultural misunderstandings as well. He mentioned this "VIP" is a "Developer and dtrace expert".…

The example in the article is an exception but, companies (including Sun) are generally very careful about using open source, and using it without attribution would be the exception not the rule.

Large companies are slow, indeed. In the late 90s I wrote a few operating system plugins (nss_ldap, pam_ldap, GSS SASL plugin for the Netscape directory server) which were eventually obsoleted by native Solaris equivalents. The Sun versions were on the whole better engineered, if less flexible, because their OS team had a depth of experience that I didn't have at the time.

Re: An Unbelievable Demo

#46

Post by kortilla »

kbenson wrote: post #20
kortilla wrote: post #6

Can someone elaborate on why he takes a weird detour in the middle of the post to discourage forks? Is there some particular issue with supporting bpf tooling forks? As someone who has spent a lot of time in open source, forks are not a problem, they are indicative of a problem. Don’t cry when people fork and go a different direction, try to figure out why and see if you’re willing to change the project to accommodat…

> As someone who has spent a lot of time in open source, forks are not a problem, they are indicative of a problem. Forks because the main project is not responding to a need are not a problem. Forks just because some project or product believes it gives them more control and they don't interface with the original project usefully are a sort of a problem. Those aren't necessarily started because of a community need,…

Why? If someone wants more control their interests already aren’t aligned with the community. Developer resources aren’t just some faucet easily redirected.

It’s worse to have people trying to jam shit into the main project if they don’t actually care about the main project. That’s how you get contributions that are huge hacks and require more work to review and iterate on than is worth it to the community.

If some company forks for an observability product and doesn’t contribute back, they clearly don’t want to. Don’t try to force them.

git is an incredible tool for managing forks and this anti-fork mindset is right out of old school open source culture from the early 2000s.

Demanding people contribute to your project instead of forking just sounds like demands to pay homage more than anything.

Re: An Unbelievable Demo

#47

Post by kortilla »

brabel wrote: post #40
kortilla wrote: post #6

Can someone elaborate on why he takes a weird detour in the middle of the post to discourage forks? Is there some particular issue with supporting bpf tooling forks? As someone who has spent a lot of time in open source, forks are not a problem, they are indicative of a problem. Don’t cry when people fork and go a different direction, try to figure out why and see if you’re willing to change the project to accommodat…

The criticism is of forks that are done in order to re-brand and re-sell a project, and then never contribute anything back to the original, and likely, never pull improvements from the originally forked project (which can include critical bug fixes) after that.

Serious question, how does that hurt the original project? This has never been a concern in the projects I’ve worked on. Getting mad every time some developer writes code that didn’t go to your project is a good way to be mad all of the time.

Re: An Unbelievable Demo

#48

Post by brendangregg »

kortilla wrote: post #6

Can someone elaborate on why he takes a weird detour in the middle of the post to discourage forks? Is there some particular issue with supporting bpf tooling forks? As someone who has spent a lot of time in open source, forks are not a problem, they are indicative of a problem. Don’t cry when people fork and go a different direction, try to figure out why and see if you’re willing to change the project to accommodat…

Yes, there can be good reasons to fork (especially after making a fair effort to have things fixed), and bad reasons.

But also yes: There are two particular issues with bpf tooling forks. 1) They look deceptively simple, but those that are kprobes-based are really kernel-specific and brittle, and need ongoing maintenance to match the latest changes in the kernel. One ftrace(/kprobe) tool I wrote has already been ported a bunch of times, and I know it doesn't always work and one day I'll go fix it -- but how do I get all the ports updated? No one porting it has noticed it has a problem, and so the same problem is just getting duplicated and duplicated. Which is also issue 2) Unlike lots of other software, when observability tools become broken it may not be obvious at all! Imagine a tool prints a throughput that captures 90% of activity and no longer 100% (because there's now a fast-path taking 10%). So the numbers for some deep kernel activity are now off by 10%. It's hard to spot, and that increases the risk people keep deploying their old broken ports without realizing there's a problem.

Re: An Unbelievable Demo

#49

Post by cperciva »

Reminds me of when Apple started providing "smaller size updates" to OS X. I was curious about the details since my doctorate had touched on the topic, so I worked my contacts (I had a few in Apple engineering from the FreeBSD / OS X relationship) and after a few months I got back as answer: "We're using a tool called bsdiff, are you familiar with it?" I was indeed, since I was the author of said tool.

(Just to be clear, there was no license violation involved in this case; just a lack of awareness of the provenance of the open source software they were using.)

Post reply on HN