50 Shades of System Calls | Hacker News Reader

50 Shades of System Calls

sysdig.com

72 pointssigna1118 comments

Summoning the spirit (and more importantly the expertise) of brendangregg here.

From the home page sysdig "capture[s] system state and activity", but by leveraging specifically what?

From https://sysdig.com/blog/sysdig-vs-dtrace-vs-strace-a-technic...:

"First, events are captured in the kernel by a small driver, called sysdig-probe, which leverages a kernel facility called tracepoints."

That makes it sound like it's quite similar to the ftrace kernel tracer by instrumenting the various event tracepoints (/sys/kernel/debug/tracing/available_events) conveniently strewn throughout the kernel source--is this indeed the case?

Alternatively, is sysdig doing something differently? {k,u}probes? Sampling similar to, perhaps say, perf's capabilities?

The Linux tracing/profiling landscape is murky enough (littered with tools like SystemTap, LTTng, and so forth) and I'd like to know where this tool fits into an analysis work-flow--and more importantly, what's it's using (at a low-level) to gather data.

I'd appreciate any and all clarification.

Cheers.

sysdig uses "tracepoints", a feature of the Linux Kernel documented here: https://www.kernel.org/doc/Documentation/trace/tracepoints.t...

The tracing capabilities are then tuned for monitoring and troubleshooting. So keeping the overhead as low as possible and making it usable on production environments.

This is really cool, though it seems a bit silly to present such high-resolution data using a command-line interface. I guess it's easier to use over SSH?

I find it brilliant, personally. Users of sysdig tend to be sysadmin or devops with a strong *nix background, so the CLI sounds like 'from the comfort of your command line" to them.

I second the "From the comfort of your command line" feeling. I feel like many tools today are unnecessarily tied to a web browser, which makes for harsh context switching; and often worse usability. Sysdig is a killer product, and (crucial to me) is open source. I'm sure the cloud service is excellent as well.

Yeah, that's a good point. It would be neat to have a way to draw full GUIs in the terminal without having to context-switch.

There are several options here, ncurses being a popular choice.

I found an example that creates a subwindow and moves it based on keyboard input:

http://www.paulgriffiths.net/program/c/srcs/curwin1src.html

By full GUIs I mean something with a full-resolution, full-color framebuffer, not just character-mode stuff.

And that works remotely? So the X protocol?

Sure, that's one option. You could also implement something like NeWS where the graphics code runs locally.

Most people would just use X or VNC today, but I agree having more graphic integration reliably available in the shell is interesting.

Apart from various experimental support for new mechanisms in various terminal apps, there are two old formats that is supported reasonably widely: ReGIS [1] and Sixel [2]

[1] https://en.wikipedia.org/wiki/ReGIS

[2] https://en.wikipedia.org/wiki/Sixel

The issue there is standards. How do your program talk to the kernel and hardware such that all this gets drawn? Especially in a modern multitasking environment, where no single binary, outside of the kernel, has complete control of the hardware.

We have full resolution full colour frame buffers. But instead of typing into them, we end up with grunt and poke interfaces.

FWIW, Bloomberg Terminals might be something in line with what you want.

I think the world missed an opportunity around about the '90s. Instead of evolving, command lines stagnated and got sidelined by terrible GUIs that are only now evolving to get out of people's way.

We should have developed command lines with graphics and hypertext. Thus you could do `ls` and double-click on one of the resulting files to open it. Browse the web with wget.

Of course users don't want to learn lots of commands. But notice how Windows 7 onwards and most linux desktops have a "fuzzy search" that really is a kind of command line.

There has been many attempts, but they've universally not gotten things "right enough" to gain much traction. E.g. Mozilla's XMLTerm [1] was one such experiment.

[1] http://www.xml.com/pub/a/2000/06/07/xmlterm/index.html

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

Anyways, if i am to speculate then GUI took over because of discoverability and ease of translation. A CLI is damn hard to translate. With a GUI you change the labels, and thats it. And finding something in a menu or similar was, before programs grew into massive behemoths, simpler than trying to guess what command, for most outside the english speaking world, named in a foreign language, to give to get something done.

Anyone else actually tried this? I was impressed with the video and thought I'd give it a stab, but the mouse drag to drill-down isn't working for me in 0.11.0.

Found a possibly-relevant issue but it's closed and the single clicking option doesn't work on my box either: https://github.com/draios/sysdig/issues/526

author here. Please take a look at the solution proposed in this issue https://github.com/draios/sysdig/issues/599. If it doesn't work for you, feel free to comment in the issue.

Reply on news.ycombinator.com