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

381–390 of 478 posts

Re: An Unbelievable Demo

#381

Post by bcantrill »

sam_lowry_ wrote: post #95
thundergolfer wrote: post #16

Thankfully the "DTrace expert" didn't turn out to be Bryan Cantrill. He's a big fan of Scott McNealy's engineering principles for Sun Microsystems, which includes "Don't Cheat", and the behaviour in this story very much seems not in the spirit of that principle. I wonder if this bit of 'cheating' ended up getting someone at Sun in trouble.

You do not know.

It definitely (obviously?) wasn't me. I had introduced Brendan to DTrace in 2004 (over e-mail) when I discovered his earlier psio work[0] (which was based on TNF, a tracing facility that predated DTrace that was better than nothing -- but not by much). I knew that he was going to be very excited to learn about DTrace, and it wasn't long before he was delighting us with some really creative scripts. (His shellsnoop.d[1], in particular, really got people's attention as to what what could do with DTrace!)

While he and I had corresponded a bunch, ironically the first time I met Brendan was in 2005, it was in Sydney, and I was on a tour of Australia talking about Solaris 10 -- but it followed this incident by several months (if I recall correctly). I was excited to meet Brendan, and he was excited to meet me -- especially so after his poor experience several months prior!

[0] http://www.brendangregg.com/psio.html

[1] http://www.brendangregg.com/DTrace/shellsnoop.d

Re: An Unbelievable Demo

#382

Post by derefr »

marcan_42 wrote: post #334
derefr wrote: post #307

Earlier quoted context omitted.

Different things. Games are directories/packfiles containing many individual files, mostly binary art assets, plus one executable that takes up a negligible proportion of the total size. When binary art assets in the directory/packfile are updated between versions, they don't really "change" in the sense that a source-code file might be changed a git commit; instead, they get replaced. (I.e. every file change is esse…

XOR+RLE is almost useless for binaries, because almost any change will cause instructions to be added or deleted, offsetting the entire binary after the first change, making the xor fail to converge. On top of that, these changes cause changes in addresses in the first part of the binary, so you end up with a zillion similar-looking xor deltas in the first part of the file that won't compress well with RLE. In fact,…

Pedantic point: it's not "almost useless for binaries." It's almost useless for compiled, PIC binaries in modern executable formats like PE or ELF that allow for lots of load-time address-space rearrangement.

XOR-and-RLE works well for binaries from non-HLL languages (assembler, mostly) where — due mostly to early assemblers' lack of support for forward-referencing subroutine labels from the data section — subroutines tend to ossify into having defined address-space positions.

You can observe this by the fact that IPS-patchfile representations (which, while a different algorithm, is basically equivalent to XOR-and-RLE in its results) of the deltas between different versions/releases of old game ROMs written in assembly, are actually rather small relative to the sizes of the ROM images themsleves. The v1.1 ROMs are almost always byte-for-byte identical in ROM-image layout to the v1.0 versions, except for where (presumably) explicit changes were made in the assembler source code. Translated releases are the same (sometimes, but not always, because they were actually done by the localization team bit-twiddling the original ROM, because they didn't have access to the original team's assembly code.)

(This is also why archives that contain all the various versions/releases of a given game ROM, are highly compressible using generic compressors like LZMA.)

Re: An Unbelievable Demo

#383

Post by loup-vaillant »

brendangregg wrote: post #138
bilalhusain wrote: post #99

> I've learned ... instead to simply say "I have a lot of experience with that technology" and leave it at that. Shows Brendan's maturity. I am not sure what should be the appropriate reaction or corrective measure in these situations. We should talk more about handling these unfair situations. Someone else can become more successful building on top of one's open source project. On a resume, a top contributor and a m…

Thanks. There was a time when many observability products were adding latency heat maps, and at one conference expo floor there were three companies with latency heat maps on their screen at the same time, pitching them as a flagship feature. If I walked near them they'd start trying to explain them to me, and I never figured out an appropriate response. If I said "hey, great to see you added them, I invented these b…

> If I said "hey, great to see you added them, I invented these back at Sun" I'd get funny looks.

I don't understand. What kind of funny looks were they? Disbelief? Distrust? Fear of your mental health? Realization of having been lied to by their bosses (oops it wasn't really an internal tool)?

Also, what were the impact of those funny looks? How did they make you feel? Was there any longer term consequences of telling them you wrote the thing?

Re: An Unbelievable Demo

#384

Post by bcantrill »

Timothycquinn wrote: post #11

I wonder if @bcantrill was aware of this at the time it happened?

Definitely not -- see my earlier comment[0], but when I met Brendan in person later that year (and he relayed this incident to me), I didn't even recognize the name. Certainly, it wasn't someone who should have been claiming to be a DTrace expert! And honestly, by that time, any actual DTrace expert inside of Sun definitely knew of Brendan -- and likely vice versa.

[0] https://news.ycombinator.com/item?id=27396911

Re: An Unbelievable Demo

#385

Post by yaur »

squarefoot wrote: post #248

Almost been there. I was once hired and given some sources to work on by a company, and those were the same exact sources I wrote at another company years before, although my name and all recognizable comments were stripped, save for a few almost invisible traces I left like my initials paired with reserved words to make them appear like directives, pragmas, etc. The guy who had given me the "new" sources was without…

I personally wouldn't work on code that I knew was stolen from a previous employer, especially if its code I worked on directly. Ethics aside, if you ever get caught you are personally going to be subjected to entirely to many questions and its the kind of thing that could follow you around for the rest of your career even if you really did nothing wrong.

Re: An Unbelievable Demo

#386

Post by derefr »

gowld wrote: post #374
derefr wrote: post #346

Earlier quoted context omitted.

I guess I've never needed "support" in that sense. I almost always solve problems with the products/services we use myself — up to and including forking the vendor's codebase to fix their shit for them — because it's almost always the fastest way to do things. I've already been working with their product for a while, and I already know exactly what my own problem is. Provided I also know the language their code is wr…

> forking the vendor's codebase to fix their shit for them How well does that work for a hosted cloud service?

I mean, if I know that some service is using e.g. Redis under the covers, and the problem is in Redis itself, then submitting a patch upstream to Redis; waiting for it to get upstreamed; and then telling the cloud host to update their Redis version to solve the problem — is usually a pretty reliable path.

But otherwise, like I said, that's when "the problem surface is inaccessible."

Re: An Unbelievable Demo

#387

Post by derefr »

deanCommie wrote: post #371
derefr wrote: post #288

Earlier quoted context omitted.

Also, people who say so-and-so company (usually Google) is hard to contact for support, or that they require expensive support contracts before they'll talk to you, have likely never tried sending email to the appropriate mailing list for the product. It's amazing how often doing this completely bypasses any corporate first-line-support structure in the way, and just puts the email right into the inbox of the line en…

It's a great concept in theory, but in practice...find me the email list for Google Photos. Or Google Keep. These are two Google products that I use daily (including paying for one!)

Well, yeah, there does have to be a public mailing list.

My point was that there are often public mailing lists, where engineers with real engineering problems could discuss those problems with the engineers responsible for the product/service; and yet the engineer with the problem nevertheless doesn't even think of using the mailing list to reach out, but instead decides to go through regular customer-service support channels to get their problem solved.

Re: An Unbelievable Demo

#388

Post by stevebmark »

bilalhusain wrote: post #99

> I've learned ... instead to simply say "I have a lot of experience with that technology" and leave it at that. Shows Brendan's maturity. I am not sure what should be the appropriate reaction or corrective measure in these situations. We should talk more about handling these unfair situations. Someone else can become more successful building on top of one's open source project. On a resume, a top contributor and a m…

I didn't read maturity from this. I read timidness, conflict aversion, lack of standing up for oneself. Someone touring the world making hundreds of thousands of dollars, demoing your own software and claiming its their own? Violating your license setup, the foundation of OSS? I would have spelled it out as clearly as possible, including the legal implications, spelled out my assumption this person was claiming they worked hard on these tools when instead they did minimal stealing, and either talked about legal follow-up action or financial follow-up action. This is a time where anger, frustration, and being stern are justified.

Re: An Unbelievable Demo

#389

Post by bcantrill »

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".…

I have said this elsewhere on this thread, but just to reemphasize: the person that Brendan met had absolutely nothing to do with DTrace -- to the point that when he told this story to me, I didn't even recognize the name. (And can't now remember it.) The DTrace team was very small (there were three of us), and the community of early DTrace users inside of Sun -- the earliest folks who could rightfully call themselves DTrace experts -- can be seen in the acknowledgements section of our 2004 USENIX paper.[0]

[0] https://www.usenix.org/legacy/publications/library/proceedin...

Re: An Unbelievable Demo

#390

Post by TimPC »

lowbloodsugar wrote: post #360
TimPC wrote: post #348

Earlier quoted context omitted.

Your favourite question has some cultural gaps as in many countries in interview settings people downplay weaknesses and flaws. It’s why a lot of weakness questions are often ineffective. Unless you are acutely aware of when a person is doing this BECAUSE it’s an interview you’re going to get some answers that might lead you to reject good candidates.

Amazon thinks otherwise. This is their Earn Trust Leadership Principal: "Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best." [1] [1] https://www.amazon.jobs/en/principles

There is a difference between being self-critical once employed (where I agree it's a useful practice) and being self-critical during an interview (which is often viewed as the process of selling yourself in order to get a job).
Post reply on HN