> 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
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?
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!
"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."
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
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.
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.
See [1], and many others.
1: https://web.archive.org/web/20091124115438/https://graphics....
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).
# 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.
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?
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...
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."