Wandering Thoughts archives

My varied types of Firefox windows

When I wrote about what I want out of my window manager, I mentioned that I have a plethora of Firefox windows, generally iconified to my desktop. This may sound like things are out of control (and in a way they are), but there is some method to my madness. I actually have a number of different sorts of Firefox windows.

In no particular order, I have Firefox windows for:

• things that I'm actively working on or using. These are the windows that are most likely to be open, instead of iconified; I tend to iconify them only if I'm running out of space.

• things that I'm relatively actively reading. I'm one of those people who gets distracted or just doesn't want to read one thing for too long (and sometimes I get interrupted), so I tend to have several things that I'm reading through at any given time.

• things that I refresh and look at on a regular basis, either temporarily or on a regular basis. Now that I'm writing this, I've realized that I should shift some of these to my browser start page, because that's part of what it's there for.

• things that I'm holding around as references for other things I'm doing. In theory these aren't permanent; in practice, sometimes the other thing falls down my priority list and its reference windows wind up sitting around for a long time.

  A related category is web pages I'm going to mention in email, a Wandering Thoughts entry, or something like that; here I have the web page still around as a way of both keeping its URL and reminding me of it.

• things that I have aspirations of reading (or getting to) but in practice I'm not going to get to any time soon, or perhaps ever. This includes things that I've stopped being that interested in (but I can't admit it to myself and close the window), and things that I feel I should be interested in but, well, I'll read them later, someday.

Sometimes these windows have multiple tabs; this is especially common for references and things I'm actively working on.

I can't pile all of these different types of windows together in one clump (such as a bunch of tabs in a single window), even sorted by title, because I need to keep what type of window they are straight. Right now I keep track of that primarily based on where each window is iconified on my screen; some areas and some arrangements are for one purpose, other arrangements and areas are for others.

Some of these (the 'aspirations of reading' windows) could be dealt with better if I had a good way to archive a window and list and track my archived windows. This would probably take a Firefox addon; the ideal one would archive the entire window state (what Firefox currently saves in its session store, that's used to restore all your windows when restarting Firefox) and be able to completely return it to life, as if I'd never closed that window and all its tabs.

(Right now I have a little local HTML file where I sort of do this by hand. You can guess how often this happens, and it just has URLs and titles (and the date when I put them there), so it's less convenient than 'just give me the window back'.)

Some method to group and then de-group specific Firefox windows on demand would also help, because then I could have a group for each sort of thing and put windows into it that I'm not actively looking at right now. I'm not sure if I'd want this to be the same 'archive' mechanism as for things I don't expect to look at for some time, because that would probably put these other web pages a bit too far out of my mind. That probably means it's not something that should be done by Firefox but instead by my window manager somehow.

(It's quite possible that there are some good Firefox addons for dealing with this sort of thing. I haven't looked into the area very much, or even really thought about what might be possible to do inside Firefox.)

Some thoughts on us overlooking Illumos's syseventadm

In a comment on my praise of ZFS on Linux's ZFS event daemon, Joshua M. Clulow noted that Illumos (and thus OmniOS) has an equivalent in syseventadm, which dates back to Solaris. I hadn't previously known about syseventadm, despite having run Solaris fileservers and OmniOS fileservers for the better part of a decade, and that gives me some tangled feelings.

I definitely wish I'd known about syseventadm while we were still using OmniOS (and even Solaris), because it would probably have simplified our life. Specifically, it probably would have simplified the life of our spares handling system (2, 3). At the least, running immediately when some sort of pool state change happened would have sped up its reaction to devices failing (instead, it ran every fifteen minutes or so from cron, creating a bit of time lag).

(On the whole it was probably good to be forced to make our spares system be state based instead of event based. State based systems are easier to make robust in the face of various sorts of issues, like dropped events.)

At the same time, that we didn't realize syseventadm existed is, in my mind, a sign of problems in how Illumos is organized and documented (which is something it largely inherited from Solaris). For instance, syseventadm is not cross referenced in any of the Fault Manager related manpages ( fmd, fmdump, fmadm, and so on). The fault management system is the obvious entry point for a sysadmin exploring this area on Illumos (partly because it dumps out messages on you), so some sort of cross reference would have led me to syseventadm. Nor does it come up much in discussions on the Internet, although if I'd asked specifically back in the days I might have had someone mention it to me.

(It got mentioned in this Serverfault question, for example.)

A related issue is that in order to understand what you can do with syseventadm, you have to read Illumos header files (cf). This isn't even mentioned in the syseventadm manpage, and the examples in the manpage are all for custom events generated by things from a hypothetical third party vendor MYCO instead of actual system events. Without a lot of context, there are not many clues that ZFS events show up in syseventadm in the first place for you to write a handler for them. It also seems clear that writing handlers is going to involve a lot of experimentation or reading the source to determine what data you get and how it's passed to you and so on.

(In general and speaking as a sysadmin, the documentation for syseventadm doesn't present itself as something that's for end sysadmins to use. If you have to read kernel headers to understand even part of what you can do, this is aimed at system programmers.)

On the whole I'm not terribly surprised that we and apparently other people missed the existence and usefulness of syseventadm, even if clearly there was some knowledge of it in the Illumos community. That we did miss it while ZFS on Linux's equivalent practically shoved itself in our face is an example of practical field usability (or lack thereof) in action.

At this point interested parties are probably best off writing articles about how to do things with syseventadm (especially ZFS things), and perhaps putting it in Illumos ZFS FAQs. Changing the structure of the Illumos documentation or rewriting the manpages probably has too little chance of good returns for the time invested; for the most part, the system documentation for Illumos is what it is.