2016-12-31
I wish new editors thought about their overall ecology too
I have an enduring peculiar interest in new editors, or at least the nifty sounding ones. I tend to read about interesting sounding new ones like kakoune (via), and I keep track of a few here and there, like vis. But increasingly often when I do this I wind up feeling that I'm engaging in what is basically an intellectual exercise, not something that's ever going to have a practical outcome where I find a new editor I want to add to my environment.
There are probably a number of reasons for this, but one that I've become increasingly aware of is that what often matters is not the editor by itself but the editor's entire ecology. Emacs is the poster child for this; Emacs by itself is so-so, but add Magit, go-mode, flycheck, and so on, and it becomes extremely compelling. Even though I don't use them, Vim also has a similar ecology of add-ons that orbit around it and vastly extend the editor's power. Many serious users of an editor are going to end up caring quite a bit about this editor ecology, as a good one can kind of create a new editor (as with web browsers).
(There are people who like minimal editors, but my impression is that there aren't that many any more. Also, my bias is that this applies more to writing code than to writing prose, although it's handy to have things like in-editor spellchecking even for prose.)
Very few new editors seem to think very much about how to build up such an ecology around them. Their pitches and stories are about the new ways of editing that they're going to enable with their core features, typically with no mention about anything else. I understand why people do this (new core features are the sexy bit), but I also think that a modern editor that wants to have a real chance needs to think about how to build up that ecology from day one. In fact, I'll go further than that: I think it's high time we got a new editor that really made it easy to build out this ecology. I don't know what it would look like (although I suspect that Acme has some important ideas to pass on), but I want to see it.
(Atom is one new editor that has explicitly thought about this, but I can't really think of anything else.)
At this point, a new editor without much clear thought about its overall ecology feels like either a toy or an incomplete design (depending on how charitable I am). It's nice to look at, maybe it has some cute ideas, but as a toy it's nothing I'm ever likely to use. Maybe someday I'll stumble over an editor that has such a revolutionary core that I don't care about the rest, but it seems unlikely; we've had decades to work on editing ideas, and honestly at this point a lot of the 'new' ideas are rehashing variations of old ones. There is nothing wrong with a good rehash of well established ideas (that's arguably what Go is), but it's also generally limited in its fundamental appeal.
This does kind of make me sad. I've really loved a few editors I've stumbled over, like Sam and Acme, and they've really challenged and changed my ideas of what editing can be like. I'd like to think that there's a future editor out there that can still do the same thing, even if it seems unlikely. But I guess the possibility will keep me looking at new neat sounding new editors every so often, even if they do wind up making me shrug.
(This elaborates on some tweets of mine.)
Ubuntu's AppArmor system is reasonably and pleasantly non-obnoxious
I have historically not had much love for extra access control systems layered on top of Linux, such as SELinux. We don't have very high opinions of Ubuntu's AppArmor system either and have mostly avoided dealing with it, but after recently having to do things with it I have to say that it's at least not particularly obnoxious.
What drove us to having something to do with AppArmor at all was that it keeps getting restarted every so often on machines where we let users run MySQL daemons (for example for user-run web server setups). When users are running MySQL this way, the MySQL database files are of course not where the AppArmor profile expects them to be, so the moment AppArmor starts up, all user-run MySQL daemons fall over dead (or fail to start). Once this had happened a few times we both figured out what was going on and got sick of it, so we needed to permanently defang AppArmor here, which meant actually understanding at least part of AppArmor.
This, well, it wasn't too bad. It was even reasonably okay. Without too much trouble we were able to read the existing AppArmor profile and work out both a way of adding decently appropriate AppArmor access permissions for where our user MySQL databases should be and also a way of permanently disabling MySQL confinement even when AppArmor is running (we opted to do the latter). Figuring out the new rules necessary was a sufficiently pleasant experience that I can actually imagine working with AppArmor and writing AppArmor profiles without hating myself.
Two things that help a bunch are that AppArmor profiles are plain
text and they're generally written about paths in the filesystem.
Plain text makes them readable, and directly using filesystem paths
makes them easy to reason about; it is pretty obvious what allowing
the process owner to access their own files under '/w/*/*/**'
will do (for one example). AppArmor also has a relatively clean
model of site-specific additions and overrides for standard policies,
and as yet another plus, the AppArmor status reporting tool actually
has useful information about the overall state of your system.
(I will note that the other thing a good text format is good for is having comments. Comments are really good for understanding why something is in a policy. Even file naming can help here.)
I'm sure that AppArmor is strictly less powerful and capable than SELinux, both in theory and in practice based on how people write actual policies (since fine-grained policies are a problem). But it's a lot more usable in practice for a non-expert, sufficiently so that I would be willing to consider using it on one of my machines.
(Other handy links for AppArmor stuff include Ubuntu's page on debugging AppArmor and the quick guide to the profiling language as well as the documentation in general.)