Readit News logoReadit News
brendangregg commented on 3 Years of Remote Work   brendangregg.com/blog/202... · Posted by u/SerCe
raudette · 3 months ago
I love the photo... what appears to be a Commodore C64C given permanent desk space off to the right, the familiar Stewart Calculus textbook sitting on the shelf...
brendangregg · 3 months ago
I actually only just got the C64C and was surprised I could get it to fit on my desk. C64Cs are massive. Now to connect it to some display...
brendangregg commented on 3 Years of Remote Work   brendangregg.com/blog/202... · Posted by u/SerCe
out-of-ideas · 3 months ago
i think he does, but chooses to not complain. according to:

> Upset stomaches. One early meeting every two weeks doesn't sound too bad. The worst problem is that it can leave me with an upset stomach that can last for days. I'm still working fine, it's just uncomfortable. I don't know if other people suffer this or why it happens. Maybe it's just the extra coffee.

There should be a mutual understanding of expected hours for any jobs, and compensation and respect for timezones and work life and health balances. your body needs sleep, feeling tired when you try to wakeup, is your body telling you to not wakeup yet...

but if he volunteered that its okay with em, fine.. but hope he does not expect others to have the 'suck it up' mentality

edit: formating

brendangregg · 3 months ago
Right, this kind of job can improve, and should improve. But right now there's talk of ending remote work entirely, without considering that people have been making the effort for years, hence sharing an anecdote. The bigger point is that remote workers are more accommodating than is assumed, and my anecdote is an example of that (even if it is too much).

One other factor I'm curious what people think: If you were offered 7-figures USD to do these kind of hours from anywhere in the world, would that make a difference?

brendangregg commented on Show HN: Using eBPF to see through encryption without a proxy   github.com/qpoint-io/qtap... · Posted by u/tylerflint
tylerflint · 4 months ago
Great idea!

On an unrelated note, your work has inspired most of my career in Solaris/Illumos/Linux systems and honestly this project likely wouldn't have happened if it wasn't for all of your books/blogs/projects to help me along the way. Thank you!

brendangregg · 4 months ago
Thanks, glad it's useful!
brendangregg commented on Show HN: Using eBPF to see through encryption without a proxy   github.com/qpoint-io/qtap... · Posted by u/tylerflint
brendangregg · 4 months ago
To everyone building these things: Please add a disclaimer to say something like:

"This is not a vulnerability: eBPF currently requires root access to do this. Also, eBPF makes this easy but does not make it possible, as debuggers, interposers/shims, and other tools can also attach to pre-encryption points, and therefore banning eBPF (as some people want to do after seeing projects like this) would not actually improve security, but it would instead _reduce_ security as it would prevent eBPF-based security solutions from being used."

brendangregg commented on Doom GPU Flame Graphs   brendangregg.com/blog/202... · Posted by u/zdw
forrestthewoods · 4 months ago
Correct. Which means that every 20ms pixel slices two or three frames. Which is a really really bad way to profile!
brendangregg · 4 months ago
I could just regenerate these heat maps with 60 rows instead of 50. I'm limited by the sampling rate that was captured in the profile data file. To provide even more resolution (so you had many samples within a game frame) I'd need to re-profile the target with a higher frequency.

When Martin, my colleague at Netflix at the time, built a d3 version of FlameScope, he put a row selector in the UI: https://github.com/Netflix/flamescope

brendangregg commented on Doom GPU Flame Graphs   brendangregg.com/blog/202... · Posted by u/zdw
forrestthewoods · 4 months ago
Neat.

I’ll be honest, I kinda don’t get flame graphs. I mean I understand what they are. I have just always strictly preferred a proper timeline view ala Superluminal or Tracy.

Using 20ms chunks for a game is fine but also super weird. Ain’t no game using 20ms frames! So if you were using this for real you’d get all kinds of oddities. Just give me a timeline and call it a day plz.

brendangregg · 4 months ago
The origin problem for flame graphs was MySQL server performance involving dozens of threads: as a timeline view you need dozens of timelines, one for each thread, since if you render it on one (I know this is probably obvious) then you have samples from different threads from one moment to the next turning the visualization into hair. Flame graphs scale forever and always show the aggregate: any number of threads, servers, microservices, etc.

I think great UI should do both: have a toggle for switching between flame graphs (the summary) and timelines (aka "flame charts") for analyzing time-based patterns. I've encouraged this before and now some do provide that toggle, like Firefox's profiler (Flame Graphs and Stack Charts for timeline view).

As for 20ms, yes, we do want to take it down. A previous HN comment from years ago, when I first published FlameScope, was to put a game frame on the y-axis instead of 1 second, so now each column shows the rendering of a game frame, and you can see time-offset patterns across the frames (better than a time-series timeline). We started work on it and I was hoping to include it in this post. Maybe next one.

brendangregg commented on Doom GPU Flame Graphs   brendangregg.com/blog//20... · Posted by u/LorenDB
moralestapia · 4 months ago
brendangregg · 4 months ago
Nice tool. Looks like it uses what we now call a "flame chart" (not a flame graph). I don't know if it ever had an original name, but I've seen these in tools from at least the 1990's.
brendangregg commented on Doom GPU Flame Graphs   brendangregg.com/blog//20... · Posted by u/LorenDB
Veserv · 4 months ago
Flame graph, as in a display of sampled call stacks growing upward organized per level to aggregate like call stacks, is almost certainly their invention.

Why they chose that over the much more common visualization of downward call stacks that has been standard for decades is a mystery. That is the form most commonly used to display call stacks in trace visualizers since at least the early 2000s (though likely earlier).

brendangregg · 4 months ago
The answer has always been in the source of flamegraph.pl:

  # This was inspired by Neelakanth Nadgir's excellent function_call_graph.rb
  # program, which visualized function entry and return trace events.  As Neel
  # wrote: "The output displayed is inspired by Roch's CallStackAnalyzer which
  # was in turn inspired by the work on vftrace by Jan Boerhout". 
Neel's did upward "flames" and I think CallStackAnalyzer did as well from memory, so based on the ones I was familiar with this was the precedent. We were also dealing with stacks that were commonly less than 30 frames deep, so it tended to fit on the screen. Also in my original flamegraph.pl implementation was an option to invert the flame graph (--inverted), so I've always let people choose. But I guess I had to pick something as the default.

Neel's was the biggest direct inspiration. I changed it to put the alphabet on the x-axis and reduced the color hues, but they look similar.

brendangregg commented on No More Blue Fridays   brendangregg.com/blog/202... · Posted by u/moreati
surajrmal · a year ago
This assumes eBPF becomes the standard. It's not clear Microsoft wants that. They could create something else which integrates with dot net and push for that instead.

Also this problem of too much software running in the kernel in an unbounded manner has long existed. Why should Microsoft suddenly invest in solving it on Windows?

brendangregg · a year ago
Microsoft have been driving the work to make eBPF an IETF industry standard.
brendangregg commented on No More Blue Fridays   brendangregg.com/blog/202... · Posted by u/moreati
mrpippy · a year ago
> Once Microsoft's eBPF support for Windows becomes production-ready, Windows security software can be ported to eBPF as well.

This doesn’t seem grounded in reality. If you follow the link to the “hooks” that Windows eBPF makes available [1], it’s just for incoming packets and socket operations. IOW, MS is expecting you to use the Berkeley Packet Filter for packet filtering. Not for filtering I/O, or object creation/use, or any of the other million places a driver like Crowdstrike’s hooks into the NT kernel.

In addition, they need to be in the kernel in order to monitor all the other 3rd party garbage running in kernel-space. ELAM (early-launch anti-malware) loads anti-malware drivers first so they can monitor everything that other drivers do. I highly doubt this is available to eBPF.

If Microsoft intends eBPF to be used to replace kernel-space anti-malware drivers, they have a long, long way to go.

[1]: https://microsoft.github.io/ebpf-for-windows/ebpf__structs_8...

brendangregg · a year ago
Yes, we know eBPF must attach to equivalent events to Linux, but given there are already many event sources and consumers in Windows, the work is to make eBPF another consumer -- not to invent instrumentation frameworks from scratch.

Just to use an analogy: Imagine people do their banking on JavaScript websites with Google Chrome, but if they use Microsoft Edge it says "JavaScript isn't supported, please download and run this .EXE". I'm not sure we'd be asking "if" Microsoft would support JavaScript (or eBPF), but "when."

u/brendangregg

KarmaCake day4747September 27, 2011
About
http://www.brendangregg.com
View Original