Phil Muldoon

I just finished reading Neil Gaiman’s American Gods. I really enjoyed it during my first reading several years ago, and more so this time around. I rarely read books over again anymore – I used to do it all the time. But I found I would bring a more critical eye on the second reading, and it would ruin the suspension of belief. There are very few books then, that can pull off a second reading that beats the first. So highly recommended.

So what’s going on with Frysk?

I thought I would write about what I am currently working on and been involved with in the last week. There are lots of other things that other team members are up to, but I thought I would let them blog about them (hint)

Right now, I’m puzzling out concurrent sessions. The architecture is there to allow for multiple sessions in the UI, but it needs some work. A concurrent session is just a way to allow multiple disparate sessions to run at once. Though these sessions are separate, they all still have to cooperate and communicate; they will still all be channeled through the one frysk-core, but using multiple core event loops. A likely first candidate is to refactor out the singleton Window Manager to a Factory. I’m not even sure if that is the right approach. So judicious diving into the Gang of Four Design Patterns book, is in order. I can only read the book a chapter or so at a time, as it is so deeply technical. Add to that the Smalltalk -> Java conversions, and the neurons whimper for relief after an hour. It’s a very good book. Anyway, the problem is not converting a singleton to a factory, but rather all the accesses throughout the code to Window Manager expect it to be a singleton, and expect the static instantiations of the windows it manages.

Another thing that has been on my mind for a long time, is a richer set of Actions to Custom Observers. A Custom observer is a UI concept where you can extend the core observers to do X action on Y observer fire, as long as it matches Z filter. It really allows some fine-grain control when an observer fires, and what to do when it fires. Mike took this one last week, and one of the first things we came up with was an additional action that would run a binary file. Once we thought about it for a bit longer, we realized we’d have to throttle this somehow. If the executable was a pager executable that would send a page to someone, and the observer action was “Fork” (or Clone) on httpd, we would not want to page the poor harried system admin a 1000 times in an hour, if httpd went crazy. Lots to think about. It’s going to be exciting see what Mike comes up with in the next few weeks.

Sessions. They’ve consumed me this week. And Dogtail. Have not written; blame them.

Sessions, Sessions, Session …

Sessions are tricky. And still not feeling right in the Frysk UI. Some work-flows seem to slot right in, and some require a lot of work. So you keep working at them, tracing down the disconnects with the other flows. And then sometimes after that, they still don’t feel right. It’s a good bet that if it does not feel right to the hackers, it will not feel right to the users, either.

I often think it is the case of the UI failing to bridge what the user wants, and what the system can/cannot provide. That can be in badly written error messages, clunky work-flows, bad prompting or a whole mixed-bag of reasons.

If the UI cannot provide what the user wants, as the system-functionality cannot provide it, how do we communicate that in non-obvious cases? On a functional level, the user might not realize that something is not possible. It might be that they did something that was exactly the same 2 minutes ago, and that worked. The reason might not be obvious. A media player is a good example. It plays music. Media players are good at that, and arguably, the user can expect it to do it well. It can play FOO files, but not BAR files. It can play FOO files as the system has an auxiliary plug-in that can do this. It might have shipped with this plug-in. It cannot play BAR files because the plug-in for that does not exist due to (insert reason here). The functional requirement is still the same: play music. And the work-flow is the same, but the outcome is different. And all the user really wants it to listen to some music.

Someday I might rewrite the above paragraph, as it seems muddled. But keep with me, I’ll slug right along. So what the devil does this have to do with Frysk? A little look at what a Frysk UI session is, might illuminate that a little.

As Frysk is part a forensic tool, it is often that you need to go through a very detailed set of tasks in the UI to get that environment just so. Setting up an environment manually over and over is frustrating. Also, you are very rarely interested in the the whole system, but just a subset. Frysk sessions allow you to narrow the focus of your forensic time to processes you are interested in, and also adds the observers you define to those processes.

So a Frysk UI session is just two steps:

• Pick the process groups that interest you, currently running on the host (IE Bash)
• Choose the observers that you wish to add to those processes when the sessions executes.

After that, the UI session setup is complete. You can run the session now, you can run the session next week – whenever. Sessions stick around; they allow you to do a setup chore once, and done. You can edit them of course, delete them, copy them and so on. But ultimately, once you create a session, it is there to stay until you decide to delete it.

The problem here is PIDs. Because a session can last forever, a session cannot allow you to choose Bash with a PID of 1234. It can only allow you to select all Bash, or no Bash. When you select Bash in a session, you are selecting all Bash processes. When you select Fork Observer to apply to that Bash, you are applying it to all Bash processes present. Why? Because if the UI were to allow PIDs to be seen, the PID you select now, and that stored PID in the session you run next week, is meaningless. So to make sure the Bash session you create now, will also run next week, it has to be generic in the selection of what is interesting to you, and what is not.

The interesting thing here is that user feedback seems to be polarized into two camps: people who hate it, and people who don’t. Some people don’t care what Frysk attaches too as long as it attaches to what they are interested in. The rest – to that group – is just implementation. However, some people really want to see PIDs up front, and don’t like the all or nothing approach.

The solution we thought about, and Mike coded up, was to have a session launcher. A session launcher receives a session you decide to run, and inspects it. Say session Foo had Bash in it, and to attach a Fork observer to Bash. The session launcher would look up all Bash instances running when the session launches, bring up a dialog showing all instances, and allow the user to pick what PIDs at session launch time to really attach too. This solved the all or nothing approach, but it still does not answer the question up front. Are we hiding data from users? They may want to see PIDs (even though a PID is not useful to a session). How do we answer the question?

That’s what I’m currently thinking on.

Happy Hacking!