Matt (madalu)

Is Android the Future of Linux?

Tue, 06 Sep 2011 00:00:00 -0400

By now, several weeks ago, in correspondence madalu wrote that he thought Android was probably future of Linux," mostly as a throw away line. This feels like a really bold statement,1 and I've enjoyed thinking about Android and "the future of Linux."

On the face of it, Android is the future of Linux. Android is the Linux that most people will interact with before all others in a concrete manner. In all likelihood The future of Linux is probably mostly in running web servers, virtualization hosts, and any other server that matters. At this point, Linux's platform support and use cases is far less interesting than its prevalence: the ubiquity of Linux, GNU, and BusyBox, is more import an that the fact that Linux runs everywhere in hundreds of different usage profiles.

And really, "desktop Linux" or even "Linux for end-users," is something of a distraction. We don't all have to use Linux on the machines beneath our fingers for Linux to be successful. I'm a desktop Linux user because it's the right system for the work I do, and I can't work the way I need to with any other kind of system. But I use my systems in a very peculiar way and the thing that makes Linux ideal for me (and the people who are good at building Linux systems,) is not necessarily the qualities that make the best Linux distributions for most users.

As someone who cares about Linux adoption and the use of free software, I don't want my argument to lead to the very common "let non-technical users use Macs" argument. Although it's true that OS X can be a convincing introduction to power and use of having a full UNIX-like system on your lap: this was my root (as it were.) Rather, I think that the way to encourage Linux adoption is to increase computer literacy until users respect and value and power that Linux-based systems offer.

Easier said than done, of course.

If this is the case, then Android isn't a very good introduction to Linux-based operating systems. Not because it's bad software, but because the kernel is pretty irrelevant to the overall user experience, or the interface that most users have.

Regardless, while madalu is probably right, I don't think it matters. Android is largely orthogonal to the adoption of Linux. The bigger questions are:

Does Microsoft have a tablet strategy? Really? The last time Linux made headway into users' hands (i.e. netbooks,) Microsoft changed strategies, and not only pushed Linux-based systems out of the market, but they also basically killed the device class. Netbooks really aren't a thing anymore.
How close are we to tablet-like (or tablet-derived) devices from replacing general purpose computers for some classes of day to day activity. I suspect corporate machines will be the first to fall (more constrained/specific use cases; tablet systems give IT administrators more control, and increasingly work happens in web apps.)

If corporate fleets are the first to fall, the first question becomes much more important. In any case, stay tuned, I'm working on collecting the rest of my thoughts on these questions. In the mean time, I'd look forward to hearing from you.

Onward and Upward!

I would like to fully apologize ahead of the time if I'm characterizing the argument unfairly. [^v3]:Though mostly ceremonial to mark the 20th anniversary, and because there have been 39 releases of the 2.6.x series kernel which is absurd to keep track of after a while, Linux is getting a version boost to version 3.x. ↩

Update Rhythm

Tue, 30 Aug 2011 00:00:00 -0400

I wonder if, at some point, this constant state of overload and flux in my world will begin to seem normal and I'll just adjust to that normal. In the mean time, exciting things are happening and I'm not quite sure of the best way to write about them. Perhaps soon. For now, I'm trying to get better about updating more regularly and I have a bunch of links of stuff that have happened on the wiki in the past couple of weeks that I'd like to share. Here we go:

Discussion of Rhizomes

jfm and I had a good exchange about an old post that I wrote on "Ideology and Systems Administration." Basically the posts says, "systems administrators have a unique approach to solving technological problems," and discussed the implications of systems administrators background on technology development. I think our clarifications were useful.

There are a couple of comments on my recent series on a productivity. First, I wrote a post about task planning and creating task items, and madalu posted a comment. Second, a number of us had an ongoing conversation on mobile productivity in response to the "Mobile Productivity Challenges" post (link,) that touched on emacs (of course!) input, and context switching.

Site Tweaks

This is a pretty minor point, but I've been subtly tweaking the design a little in the site. There are now links to the tags page and the site-map in the upper right hand corner. I've also made links to as-of-yet-uncreated wiki pages red (according to wiki-convention.) I think (and hope) that red links are easier to spot when they're red. Feedback on the design would be most welcome. My goal is to make the site welcoming, easy to use, and to minimize the amount of "fussiness." It might be time for a full refresh, but ?feedback on the subject might be good.

Critical Futures and Wiki Fiction

As a build on top of my"Wiki Fiction" post, I've moved the pages that had been located on the critical-futures page to previous/critical-futures. Eventually the story will move to the Critical Futures domain, but that's a bit down the road. Right now I'd rather focus my time/energy on writing some stories, for now (on this wiki.) Infrastructure can come next.

I hope to work on a series of posts that explore collaborative fiction organizing over the next few weeks. If people are interested, that is.

External Links

I came across a blog from the comments on the make emacs better post that I wanted to offer as a link The Babbage Files is a great cyborg/emacs/free software blog.

This is probably not news to anyone, but from John Wiegley I learned about the following two emacs gems that merit mention:

paredit which makes handling all of the parentheses in Lisp coding much easier.
redshank, which basically adds a number of tempting systems and associated tools for

And in another direction, I've been playing with pylookup. This emacs add on makes it possible to access python documentation from within emacs, from a local copy. The interface is a little bit fiddly but it's pretty much heaven. More things should work like this.

Onward and Upward!

Making Emacs Better Discussion

Wed, 22 Jun 2011 11:02:40 -0400

Madalu and tychoish

Would it be safe to say that it is difficult to make a tool like Emacs suitable for mass adoption because there are so many advanced users who have invested a great deal of time in mastering it in its current form? The emacs-devel mailing list sees frequent debates about integrating Emacs into the conventions of the modern desktop (e.g., turning on cua-mode by default). But usually emacs conventions win out because so many seasoned Emacs users are used to C-w, C-y, etc. instead of copy and paste. In addition, Emacs users as a group take some pride (perhaps unwarranted) in using a tool whose conventions predate the modern desktop.

Would it be an exaggeration to Emacs is not an efficient tool unless one is willing to master the steep learning curve? But it is precisely the ability to customize Emacs in every respect--to mold it into whatever one wants--that makes it such a wonderful tool for power users. I would argue that gedit is a better editor for users who prefer GUI tools that work out of the box than Emacs could ever be. Emacs, by contrast, is a tool for users who want highly individualized (even eccentric) work-flows.

-- madalu

I think you present the conventional view, here. And largely, I don't disagree: emacs developers largely serve the needs of (and are themselves) the core users of the software. These users should be served by the software, and I think it's everyone's hope that all users of emacs eventually become "power users" of the software.

But there's no reason that emacs can't be usable by everyone. The modifications are mostly minor: create a build-distribution function that lets folks setup and configure emacs, and use that to dump a core image and create an emacs system that other people can easily install. That would, solve most of these issues.

I think the problem with saying that "emacs is only for people who want something that they can customize fully," is that I don't think people realize that this is something that they need or want. We're so used to editing technology that doesn't have these features that we don't know to ask for it.

While emacs (and vim too, let's be honest) are still light years ahead of everything else, there are a bunch of tools that aren't, effectively, that bad. Gmail does email pretty well. Eclipse/NetBeans are open source IDEs that people know pretty well. Things like Scrivener provides non-word processor structured writing tools. Piece by piece, the world is catching up. Emacs should continue to play ball too, that's all.

-- tychoish

Thanks for this thoughtful response. My experience of emacs is a bit different. If I were to choose an editor as an editor, I would choose vim. It is easier to learn and has a saner set of defaults. What keeps me with Emacs is elisp --- i.e., its usefulness as a fully programmable editor. In fact, I find emacs to be a fully programmable computing environment, in which I can use the same keyboard shortcuts and same scripting language for hacking at code, writing books and articles (via AUCTeX), reading email and news, chatting on irc, planning my day, etc.

Now vim folks will respond that vim has vim-script (and python and ruby extensions) or that elisp is an ancient, inadequate lisp. Which would not be false. But it is the ecosystem---the organic context in which elisp is embedded---that makes all the difference. For all its warts as a language, elisp has evolved to do one thing very well: to make every behavior of emacs malleable. Its singleness of purpose is what makes it so useful. Other languages may process text better; elisp, however, excels at allowing users to interact with plain text in every conceivable way.

So, for me, emacs would not be emacs without some knowledge of elisp. This is why I am not entirely convinced that an opaque, user-friendly distribution of emacs would be more useful than gedit or vim.

-- madalu

I mean to be fair, emacs is an editing paradigm (stackable control key navigation, modeline, M-x prompt, etc.) the emacs-lisp extensible is just an MIT AI lab/rms variant, that has happened to really catch on.

Elisp, is a fine language, as many programming languages are, but I think that it's strength in the context of emacs has less to do with the fact that the language has any particular capability and more that it's been used to write so much existing code. The fact that emacs itself is largely implemented in elisp along with, is really the selling point for emacs lisp and the drive to write more elisp code.

-- tychoish

TC and tychoish

Commenting on this wiki isn't all that intuitive, so forgive me if I'm doing it wrong...

Emacs, by contrast, is a tool for users who want highly individualized (even eccentric) work-flows.

I'm relatively new to Emacs (I'm a writer, not a programmer), so while it's a useful tool, it's also been a steep climb, much of which has to do with making sense of even simple customizations.

On my writer's blog I champion powerful text editors (notably Emacs) as the rightful heirs to paper-metaphor-based word processors in the online age. They're fast, automated (snippets, macros and a wad of other programming functions), and they don't clutter your text with troublesome codes or saddle you with proprietary file formats.

Since 90% of paid writing ends up online (I made that up), there are a lot of reasons for writers to use Emacs (project management, Org-Mode, Magit, language modes, keyboard shortcuts that keep your hands away from productivity-sapping arrow keys, syntax highlighting, etc).

Sadly, while it's powerful, making it dance is not easy, and it's far from useful right out of the box. Customization? I invested several hours just figuring out visual line wrap (v.23), and installing Identica.el mode chewed up two more. Buffers? Really?

I really like the suggestion of custom-built distributions; a writer-ready distribution offers at least a faint shot at converting writers--most of whom take one look at "Buffers" and "Enter debugger on error" menus and walk away.

Even better is how it might function in the "eccentric" workflow sense; Emacs could be the linchpin of a complete writer's system (compose in Markdown or ReStructuredText; manage versions with Git; fire copy right onto a blog; output .rtf files (for import into LibreOffice or MS Word when clients demand it or the situation warrants formatting); and use Latex to create formatted .pdf documents to print.

All this can be assembled now on a piecemeal basis, but not by mortal writers.

I'd suggest highly leveraged workflows--"individualized" to meet the needs of an entirely new class of Emacs users--might actually be the key to further Emacs adoption, not a reason to see it relegated solely to power users.

-- TC/Writer Underground

You're doing a great job at commenting on the wiki. This is the exactly right way to do it. Thanks for jumping in and offering this contribution.

The enevitable problem is that everyone has a different strategy. Visual line mode is probably the way to go, but I'm a big fan of auto-fill-mode (M-q twitch and all,) because it means that git diff has more to chew through. There are probably a thousand other little decision that could give rise to specific packages of emacs, and that could be as confusing to potential users as anything.

Maybe what we need is ELPA+shell script that will install an emacs configuration. Doesn't work for Windows and it isn't very seamless (probably.) An idea, though, for a start.

-- tychoish

I think writers are--as a group--more homogeneous in their needs than programmers, and a "standard" writer's distribution could be created that would at least get folks off the ground.

I like your idea for an Emacs configuration install that would allow customization yet install easily; Kieran Healy offers an Emacs starter kit for sociology students, yet the directions for getting it running are not insubstantial.

I have to admit a couple writers have tumbled for my rants about text editors and asked me to point them towards an editor, and while Emacs is mentioned, something like Komodo Edit or Gedit (which needs a fair amount of hot-rodding to make it truly productive) are safer--yet still fairly versatile--bets.

In a less-specialized vein, I understand a package manager is in the works for v.24, which should ease customization. My own success rate adding new ".el" files is only 50% or so, despite being one of those people who reads directions.

Thanks for the chance to comment. I would like to see Emacs continue moving forward, especially as it offers the only realistic chance of becoming a truly all-around writer's platform (as a working writer, I write in 5-6 different editors over the course of the week, and I'd like to cut that number down a bit).

--TC/Writer Underground

Thought it sometimes earns me a little bit of ire, I'm pretty keen to suggest that TextMate for Mac is probably the second best text editing software around. It's very customizeable, powerful, and easy to extend, but not overwhelmingly confusing, and the transition from TextMate to emacs is pretty seamless. I really only use 2-3 text-editing interfaces (Word, Emacs, Outlook) and four if you count web-based editing forms. I'm curious about the kind of work you're doing that requires so much editing software.

I wouldn't necessarily assume that writers were homogeneous. Though there are probably fewer modes needed (LaTeX, OrgMode, Mardown, ReStructured Text,) there is no real lack of diversity in usage patterns and preferences. Not that I think we should avoid making an emacs distro, but that it's not going to be a simple matter

I'm totally willing to help you with your loading extra emacs lisp code issue, as I think I know what you're doing, and there are some really full proof ways of structuring your emacs configuration that would make this a less crucial issue.

ELPA (the package manager that's being included in v24) is a useful piece of infrastructure, but I don't think it solves this problem outright for a few technical issues. First, ELPA doesn't easily support multiple repositories in the way that most Linux distribution package managers do. Second, the default package repository only includes software with copyright assigned to the FSF, which is probably the right strategy, but given the first limitation is very limiting. So we could probably make something work, but it's not as straightforward as it could be.

Be in touch!

-- tychoish

I've heard good things about TextMate, but I'm a Linux guy, and if I had to pick an editor (for writers) that wasn't Emacs, it would be Komodo Edit, which is cross-platform and wholly customizable in a way that even a writer can understand.

Gedit's nice, but requires some hot-rodding to really boost productivity, and lacks the top-end editing commands that can really save your day.

In terms of homogeneity, my point is that most writers are used to a fairly standard CUA interface, and where it gets messy is on the output end. I think Emacs could serve as a brilliant editor for writers generating words primarily for online use (and perhaps simply formatted printed documents like manuscripts, scripts, etc), but most will keep their word processors for heavily formatted documents.

Of course, this is whole thread wasn't about just writers, and suggesting a heavily altered version of Emacs -- with much of the programming stuff hidden, built-in sign-up-and-save version control via Github, with LaTex installed and ready to go... it feels like a lot, especially when you consider the whole thing would have to offer a sizable improvement in functionality to even get a sniff from the writing world, most of whom are comfortable with the paper-based metaphor for writing.

Thanks for the chance to air out some of this stuff. Once of these days I'm going to create a screencast or two demonstrating the benefits of text editors for online writers (featuring Emacs); I think Emacs and Vim have never been so far from the mainstream, but given how words are being published nowadays, they've never been so badly needed either...

--TC/Writer Underground

I'm a Linux guy too, so it's a bit of contrived situation for me to be recommending TextMate, but even if it's been a long time since it was update, and even if it's OS X-only, it's been able to do something better than the others, and it has a community, and like the best software there's not a lot of functionality there except some open and plain interfaces for people to build the functionality they want ontop of an existing framework. It's a proven model for good software, and it's kind of shame that we don't see more of it. Anyway, to each their own.

I think it's generally a bad idea to build too much dependency on hosted services, particularly in free software projects (i.e. github.) I don't quite think that people should avoid using services, but I think it's bad form to tie services to something like github without an easy escape plan. Also, the commercial relationships we make for ourselves shouldn't be foisted upon other users without at least giving them options.

I'm interested in working on projects that help people write and work better. That was the original intention behind the cyborg institute project, at least. Anyway, if you need resources or want to collaborate on stuff, I'm game to contribute if not actually manage the project.

-- tychoish

Peter and tychoish

I'm a weird mix in that I fiercely love Emacs, and see it as the single most influential tool in my productivity, but constantly find myself breaking things that cost me valuable time and create frustration.

For me, half of what I love about Emacs is what it doesn't do. It doesn't sit around indexing when I want to type. It doesn't (by default) look ahead and suggest what it thinks I want to type. It doesn't auto-complete things for me (forcing me to delete and fight with the auto-complete when I do something non-standard. It doesn't save my files in weird binary formats. Honestly most of the time I want something that just lets me type text really really quickly.

What makes emacs useful for me is that I'm always finding ways to have Emacs make me type and navigate faster. Things like M-/, yasnippets, bincremental search, rectangle editing, find-name-dired replaces, these are the things that make me faster than my NetBeans/TextMate/RubyMine/Vim compatriots. I've personally introduced about 10 people to emacs, but only maybe 4 of them have stuck with it.

I think for me, what made me stick with it was that I treated it as a game. I still don't really understand lisp. I can program in python, ruby, javascript, and even C and C++ to some extent, but there's something about lisp that doesn't click with me. Still, about once every week I go on a hunt to make Emacs do something that I want it to do.

I guess what I'm trying to say is that I'd like to make an Emacs game. The idea would be to distribute an emacs that has very very minimal keybindings and configuration. You have basic navigation, cut and yank, syntax highlighting and customizing colors. Then we make different classes for learning (writer, programmer, student, manager, accountant, etc.). Each one of the classes has a skill tree where they learn useful things and earn points for doing them. Maybe we distribute it with a set of fixtures that show how the emacs tools are useful.

I remember the thing that prevented me learning databases was not having data. Once you have data, SQL is a breeze to learn. Once you have a chunk of text that requires a macro to edit efficiently, macros become fun. Once you have a chunk of HTML that is all left flush, indent-region is impressively magical. As you gain new skills we make part of the game customizing the emacs.d directory, and they gradually learn about keybindings, settings, functions, etc,.

Maybe too extreme, but I think it would be fun.

-- Peter

Thanks for commenting Peter! I'm interested to learn how you learned about the site, and how I might find more about your work and your site. Perhaps consider making a folk page, or just dropping me an email garen@tychoish.com.

The overriding goal here is not to actually change the way emacs works, but to provide a framework to make the first 3-5 days of emacs usage better. There are a number of things about emacs that are just hard when you're new. The installation (potentially,) the lack of initial mode and configuration (fundamental mode, really?) and so much that I think everyone changes. Oh, and the font is universally bad. What's so hard about bundling Iconsolata?

I think phrasing emacs customization as a game is both an accurate characterization for many, and probably something that might make the process more understandable for the uninitiated. Having said that, I think would-be emacs users need to know that it's worth it and know where to start. Beyond that, we can assume that they're sold and then it becomes a game. Having said that, I think providing too much structure will for "the emacs development process" will only make things more confusing. Get people started, give them the tools and every chance to succeed, and then get back to work.

I really like the point that you need to be able to have a use for a tool before being able to effectively use that tool. The problem, perhaps with emacs is that they already have a need for a text editor, because most people do. So it's not something that they can walk into slowly (or would be prone to walking into slowly.) And really, while I think that people inevitably learn a little lisp by using emacs, I'm not sure that learning a lot of lisp is the right way to approach "learning emacs."

-- tychoish

mitch and tychoish: Customize Mode

I agree with sentiment of Tycho's point (2). I understand the need for the customize interface, helping novice users choose options from a menu, and even experienced ones who just want a quick change, but find it just plain user hostile. I often end up spending twice as long saying screw it, then reading the elisp docs and adding a few paragraphs of elisp instead of dealing with customize. I think part of it is the kludgey text based window/menu environment. Some suggestions for a friendlier replacement:

A simple question/answer menu driven perl/shell script that read/wrote the user's .emacs and .emacs.d files would be easier than what we have.
Like above but a question/answer mode inside emacs. No funny menu business, just answer questions.
I could also see a brand new full emacs widget implementation. This would probably be the nicest but would abandon text-only users.

Any ideas?

-- mitch

Thanks for commenting! Make a folk page, tell me how you found out about the site (Planet Emacsen, I presume?) and all that.

I always do the "C-h v" test and then insert a setq statement into a file in my config somewhere because that's so much easier. I think, probably, that customize is the best that it can be, while still keeping emacs "lisp from top to bottom." I think the initial installer or "distro-builder" would probably be best served by some sort of question and answer interface: e.g. "Do you want to build an installable emacs distribution?" "Do you want to dump your configuration into a script that others can install?" "Do you want to check all of your emacs lisp to ensure that it's distributable?"

I think the "emacs for beginners," package should probably stick to a lot of very well commented lisp files for configuration, which would give people the ability to create and customize their own files. Or at least a start!

-- tychoish

PCMantz and tychoish

Just a quick note, but there is a good starter kit that a lot of programmers have found to be a good base for Emacs customization. It is aptly named Emacs Starter Kit, and does a good job of giving first-time users a head start on using Emacs efficiently.

-- PCMatz

I was vaguely familiar with this project when I wrote the post, but I don't think that I have seen it since it moved to github. Or maybe I saw a similar project a few years ago. In any case I like the idea, though the "all your emacs configuration" in weird org-babel files isn't exactly intuitive. I'm not sure, it's probably a good starting place to start.

-- tychoish

"Lazy newb pack for Emacs"

This puts me in mind of the Lazy Newb Pack for Dwarf Fortress. And maybe an initial starting point could follow similar lines. Make one distribution which includes most frequently used/most universally useful packages.

While I agree that one of the great strengths of Emacs is its customisability (which involves a certain learning curve), I still think a "starter Emacs" would be a great idea - to show people what Emacs can do and at the same time break the learning curve into smaller, more manageable increments (sort of like training wheels for a bicycle).

I stumbled upon Emacs by accident (my main work doesn't involve programming) probably about a year ago, and persisted in using it partly from sheer pigheadness. But I'm immensely glad that I did. In the end Emacs has saved me more time than its cost me, and in the long haul that will be exponentially true. At this point I can't imagine not using Emacs.

I would suppose there are other people like me for whom Emacs would be incredibly useful. But not all of those people may be as stubborn as I, especially in a world where people increasingly expect everything to work "out of the box" (or, at least to appear to work "out of the box", in the case of Windows, iPhone etc.). A preconfigured starter Emacs would be great for showing people the usefulness of Emacs. Once they're convinced of that, presumably they may well be willing to invest time in tweaking, configuring, and even learning bits of elisp. But before they know how useful Emacs might be, many people may be unwilling to invest the initial time commitment.

There are certain packages which I think may be incredibly useful for all/most users, like "undo-tree" (in that context - it would be great to compile a list of cool features of Emacs uncommon elsewhere, like the "undo-within-a-region" command...). Maybe "CUA-mode" - just for the visible rectangular selection (I still use standard Emacs keybindings). "Flyspell" for anyone using Emacs to edit natural language text. And of course "orgmode" allows for all sorts of cool things.

Binding "dynamic abbreviation expansion" (dabbrev-expand) to some reasonable keys is desirable too, I think.

About 80% of my Emacs usage involves AUCTeX, simply because Emacs+AUCTeX(/RefTeX/Outline-mode) really is by far and away the most powerful (La)TeX editing environment. Setting up (La)TeX of course involves its own set of complexities, especially since it's best used in conjunction with an output viewer. And setting up Emacs/AUCTeX to allow for forward and inverse search between input TeX and output (pdf, dvi etc.) has probably accounted for the majority of my "time lost" using Emacs. And this is additionally complicated given that it will vary from OS to OS (under Linux, Okular seems to be supported best, though some people have managed to get Evince to work too). So a TeX-centric distribution of Emacs would be complicated (though, I think, worthwhile).

More random musing: the shell script could involve options like "Do you want standard Emacs keybindings or CUA keybindings?"

-- BeSlayed

I think we're nearing the point where this discussion is better served by a number of pages rather than just the one. In any case, BeSlayed, stay a while and make a folk page for your self ;).

I'll say a couple of things things: I didn't know about undo-tree, but I read the emacswiki page about it and when I'm in the tinkering mood I'll surely start looking for it. After a while, I finally figured out how emacs' native undo works, and the truth is that not only do I no longer screw things up with impossible to undo chains of events, but I'm disappointed when other applications don't mimic emacs. If nothing else let this be an example of how everyone's default configuration is wildly different and how needs vary. And then there are things like CUA which will never ever ever be in any release of emacs.

I guess my hope isn't to coddle people or fundamentally change anything about the way emacs works or is developed. I just want to be able to tell people: "you want to learn emacs, here's a sane configuration/installation to get started, learn from it." There's room for a TeX centric emacs version and latex-system would depend on such a thing, but I haven't a clue where to start, and how to get that into an installer that wasn't utterly massive to download.

By in touch!

-- tychoish

Better Task List Discussion

Tue, 19 Jul 2011 11:31:57 -0400

I think this classification of the different uses of task lists is pretty good, but I wonder if we can think a bit more about different contexts and different problems. My main use for task lists is certainly obligation management --- memory enhancement is important, but automatically falls out of obligation management in my experience. I have effectively no spare time, so task prioritization is important, but somehow, task priorities have never been very effective motivators for me.

In terms of software, I use org-mode, with a mix of GTD and Pomodoro methodologies. What I struggle with is mobile/offline usage. There doesn't seem to be anything both interoperable and functional for Android.

-- jfm

Look for a post in the next few days about the mobile/offline question: It's a problem that I am still interested in, and I'd say that the mobile problem is more about figuring out what the right kind of task list content is right for the phone, and less about the application design.

I think that we use task lists to prioritize tasks, even if the task prioritization features of most management software are somewhat... lacking. I think this is largely because prioritization happens quickly and automatically when reading a list, prioritization changes rapidly as tasks are added and completed (or at least more often than the task list is reviewed,) and in almost every other case it's more important to sort/filter/view task lists along another dimension (project-based, context-based, global next-steps, etc.) But having tasks written on a list makes it possible to do that kind of prioritization. So that's worth something.

-- tychoish

For me the mobile/offline issue comes down to:

How to get the necessary lists (and reference material) out of my trusted system and onto something on my mobile device that will present it in some useful fashion (and what's a useful fashion requires some thought, too).
How to propagate edits and status changes on those lists back to my trusted system.
How to do ubiquitous capture, and how to propagate captured items back to my trusted system.

Since my trusted system is org-mode, you'd think MobileOrg for Android would be ideal. Unfortunately, (1) only half-works (the presentation is perhaps not very useful), (2) does not work in the current version of the app, and (3) works adequately, but needs UI improvements, and the whole thing is slow enough to discourage me from using it when I need it most. I really would like to work on improving it, but I really don't have time.

Android Shuffle is, interface-wise, very nearly what I would like MobileOrg to be, but it only interoperates with a RoR webapp, and it's a little too focused on tasks, with no place for notes.

I find myself using Note Everything for all kinds of things that I'd certainly do in org-mode if I had a full org-mode everywhere. But it bugs me because it's not Free Software, and because syncing with org-mode amounts to mailing notes to myself and copying them out of the email to org during my morning review.

This little mobile-sideline is probably not exactly relevant to the issue of better task-lists, though.

Regarding prioritization, I've seen the argument made that priorities are such a complex, fluid thing, that there's no point in trying to manage them in software or in personal organization systems. I find that I do use priority tags in org-mode, but only in order to force sorting in org-agenda, which defaults to file order. I also use task dependencies, which may actually be the most important part of priorities.

-- jfm

I've bee playing with Epistle which I think is pretty much brilliant. Sort of the android equivalent of paragraft editor that got some buzz in the iOS sphere. Not "faif" and while I think that's important, at least for right now I want to think a bit more before I start deciding what software freedom, the use cases, and the economics of software development look like in terms of mobile technology.

I too only use prioritization to monkey with the way that things get sorted by org-agenda. Though I suppose I could use block commands to do that, what I have seems to work just fine.

My take on the mobile task management question is less that there isn't a good app, and more that no one really knows what the right way to plan tasks for mobile operation is. The problem isn't with the apps, it's with us.

-- tychoish

Re: mobile:

I've found the Nokia n900 to a nice mobile solution for org-mode. I run emacs in easy-debian (a debian chroot) and sync it with my linux boxes via git. With the keyboard, basic editing is not too bad. But it would be nice to have a workable solution on Android other than ssh'ing into server running emacs.

Re: prioritization:

Like tychoish, I use org-mode's priorities primarily to sort the agenda view --- i.e., to cause tasks I don't want to miss to float to the top. IMO the hierarchical structure of org outlines allows for more organic, natural prioritization of commitments than A, B, C, etc. My broader approach to goal-setting and prioritization is as follows:

If a commitment is going to last more than 3 months, it gets its own file. If it is going to last 1-3 months, it gets a GOAL keyword and a place in one of my existing files. If it is going to last less than one month, it gets a PROJECT keyword.

"what I have seems to work just fine" <--- Yes! This is really the only way to make org-mode work --- to find a basic routine and run with it, even if it's less than perfect.

-- madalu

Create Better Task Items Discussion

Mon, 01 Aug 2011 10:55:53 -0400

One hack I've found helpful is to write my tasks in the past tense. For me, at least, it makes it easier to envision what the task will look like when done --- and thus forces me to be more precise.

-- madalu

There are times that I need to get something out of my head, but I don't have the time (or brainpower) to break them out into discreet steps, so I'll log them as a somewhat vague or nebulous TODO item. If I can, I'll add some notes to help jog my memory later. If the "task" is really a "project" (as defined by GTD), then I'll make it an official layer in the appropriate Org file, and create TODO items for each "task" (step) to get done with the over-arching "project." I haven't looked too deeply into nesting TODO items, but that would be the ideal solution.

-- ?jst

Progress Reports

Fri, 08 Apr 2011 00:00:00 -0400

I wish there was a good way, in the context of a blog post or some other convenient digital media, to regularly say: "I've done some things, you may be interested in them," and "I'd like to do some things, here are some notes of what I think I'd like to be working on in the next little bit." I've yet to find a good way to get in the habit of writing this kind of post.

My instinct is to have something that I can template and automate pretty strongly so that I can mostly focus on doing things rather than writing blog posts about doing things. Or as is presently the case, blog posts blog posts about doing things. Oy. ?Ideas and suggestions on this topic would be most appreciated.

So what have I been up to? Well...

I got back into writing fiction this week after several weeks away. I was in a difficult part of the story and life got very... full... and I stopped writing regularly. These things happen, but it's good to be back at least some.

After the work I did just last night, I realize that I'm much closer to the end of this novel than I had thought. Even if things go very slowly for the next few months, I think I'll be able to get this thing done by the end of May. I just have to write about a thousand words to finish Chapter 11, and there are three to four little vignettes in chat per 12 to wrap the whole thing up. And it's going to be awesome.

I'm super excited to be done with this project and to be able to spend some time cleaning it up and making it an awesome text, but also being able to work on making other things I've written better, and to be able to write new things, with my undivided attention.
I've updated the ?anti-rodentia and the associated ?discourse page with some changes that I think make the system work much better.
I've upgraded to Firefox 4, which I really like a lot: it's much faster, it's much more minimal (visually) which is great. Also all of my plugins and extensions work without issue. Good job!
I went through a blast from my past when I pulled together the queer-theories page, which does some--at this point utterly redundant--definitional work about what it means to be queer, and potential limitations on queer identity/politics in the era of a broadly defined queer.
I've started adding recurring tasks to keep me on track with writing and posting entries to this post. This means I don't end up posting things months after I write them. As was the case with ?Mutt Sucks Less, a post I wrote many months ago and posted with some revisions last week.
I made a folk page for frequent comm enter and discourse participant matt that includes a snippet which makes a list (and RSS feed!) of all pages that link to "madalu" or are tagged with "madalu" (his handle). You can see this by editing the page, and use it when making your own folk pages. Which you should totally do.

Have a good weekend!

New Feeds, Habits, and Jobs

Sat, 07 May 2011 00:00:00 -0400

(I've been tinkering on this post all weekend, and I wanted to get it out of the door before it's next week. Here goes!)

I always forget, and there's no good reason for this, how difficult it is to establish new routines and new habits. Two weeks ago, I moved for the second time this year. this week I started a new job and even though I have more free time than I did before, I'm still coming up at loose ends and I find myself wondering why I have a hard time concentrating and getting into "the grove." There's so much to do, so many tasks collecting dust on my todo list, and I'm only half keeping ahead of everything.

I have two things to report that I missed on the last update: I have new full-text feeds for posts about org-mode and emacs. Hopefully these will get included in relevant planets soon for your reading pleasure.

There's also been some discussion on the "Bad Org Mode Habits" post. You may be interested.

As an aside: the astute among you will notice that matt and I have made a folk page that is automatically updated anytime there's a page that links to or is tagged with Matt's handle (i.e. "madalu.") This includes an RSS feed that he (or you) can use to track his updates and mentions. Use the edit page functionality to see how to make such a page for your own notification purposes.

Everything else on my list is pretty boring. I'm, slowly trying to follow my own advice in bad org mode habits.

The organization I was using for my lists and notes worked really well when I was commuting all of the time and working off of laptops on the go. Among other limitations, I think I basically had to give up any sort of really complex project. Now that I have more time, I can tend to more gnarly projects that I've wanted to tinker with that I just haven't had the time for. Without a train ride and "home time" to define my free time for fiction writing and other projects, it's been hard to adjust.

It has also been hard for me to get a real sense of how my free time remains limited (because that's the nature of free time,) even if there's a lot more of it to go around. Adjustment is always hard and changes, particularly big changes, have a ripple effect. Things I've been doing differently include:

I've made some big changes to the blog post writing tooling, so that new blog posts are written in my org-mode files rather than in their own directory. (I updated the above emacs code with some shell functions that make the publication process easier (if you're using that code.) This seems minor, but is pretty big in terms of how I'm using org I've never really used org for anything other than notes and one off projects. It's a good shift.
While I used to dock my laptop to the desk and use it with an external monitor, I'm switching to just using the laptop dock and working on the laptop on the desk. This might not be ergonomically ideal, but it feels better and is a bit more coherent. Particularly with the addition of a third laptop for work.
I caved and installed emacs on my work laptop (Windows.) Rather than adapt all of my emacs crap to work with Windows, I'm basically copying and pasting the important parts, and starting from scratch. It's not pretty, but it works. And being able to use emacs and do the things that I want to do there, is a good thing indeed.
With only a few thousand more words to go on the novel. I'm taking a bit of a break to rethink things, and hopefully this afternoon rewrite a few outlines so I have a good way of drawing this project to a close. Then writing, then lots of editing and lots of other writing.
A bit more than two weeks ago, I got a new cell phone. It's a HTC Inspire (ATT "4g,") and I like it rather a lot. I still think that Blackberry does email and messaging better. This is a better computer to have in your pocket. The Kindle App is really usable. I have a text editor/note program that works great, and all the other little incidentals just seem to work and be there. If only the messaging where a bit better. eh.
The new job is going well, though I'm still in the "I wonder what this will look like when I'm actually fully up to speed" phase. I expect that I'll write even less about this job than my last job, and retreat further into "tycho." I like this. I may, however, write some features of the new job: the fact that I'm using Windows on my work machine and various aspects of digital collaboration, which I still find fascinating.

That's all the news that's fit to print!

Moving the Furinture

Mon, 02 May 2011 00:00:00 -0400

A few weeks ago we moved the furniture around. The biggest objective was to get some desk space setup in a more usable fashion. I find myself doing this a couple times a year. It's easy for me to get in the habit of having everything a certain way without realizing that the chair I like to sit on is always in the sun during the mornings when I like to write, or that I never put the dishes away, because the cabinets were arranged backwards. The same sort of thing happens with computers and the way we use technology.

Matt and I were talking about this a couple of weeks ago. I think at the core of the issue is that the kind of work we do with computers, changes subtly: either what we do actually changes as a result of our progress, or we learn more about what we're doing and what we ought to be doing from completing work. Like the furniture, it's easy to get accustomed to doing things in one particular way and not realize that there's a better way.

It's useful then to spend a little time every now and then to do a little bit of digital spring cleaning. There are two major parts of this process:

Figure out if "what you do" has changed significantly. As our projects grow the work we do changes, sometimes in ways that make it hard to continue to organize our efforts and tools in the same way.
Looking for new tools that you can use to do what you do. This includes flat out new tools of which you weren't aware, little automations that you may be able to build, and tools that solve problem domains that you'd previously ignored. It's also sometimes useful to look at your tools and figure out what is more trouble than it's worth. Ideally these don't all change annually, but it's worth doing a review.

There's no guarantee, of course, that you'll find a solution to any issue that you come across but you might. You might also be able to gain new insights into issues that have nagged at you by approaching a number of issues and pain points all at once. It's also, I'm pretty sure, more productive to spend most of your time doing stuff (writing, coding, etc.) even if your world isn't perfectly optimized, than it is to spend all your time tinkering with things.

And the sofa really does look better over there.

Onward and Upward!

Discussion of Bad Org Mode Habits

Fri, 29 Apr 2011 23:55:42 -0400

Org-mode is the notebook I dreamed of when I was a kid. (I was the third-grader with a calculator watch in 1983.)

Nothing beats being able to embed some quick, on-the-fly spreadsheet calculations within an outline used for project planning. No other tool I've tried allows order to emerge from chaos quite so easily or intuitively.

Could you explain a bit more what you mean by "gaming" the agenda? Do you mean not to structure outlines as todo lists?

-- madalu

I like thinking of org-mode as being able to produce "emergent" todo lists and project plans from outlines and raw notes. I guess the point that I'm trying to make here, is that org-outlines need to be built as outlines: it doesn't work so well if the higher level organization of your notes and thoughts doesn't lend itself to hierarchies. I think it does for more people (particularly thoughts,) but sometimes the notes don't reflect this and can be too flat to really be useful in their own right. And it's not just "wouldn't it be nice if your notes were organized differently," but actually "org works better as a system when your notes form more coherent outlines."

What I mean by "gaming the agenda," is mostly a trap that I fall into a fair piece (and I think there's evidence on the listserv which points to the fact that other people may be doing this as well, but it's what happens when you construct outlines and use TODO headings not because it makes sense in context of the outline or your project, but becuase you know you're going to be working off of an agenda. I know org is breaking for me, when I don't interact with outlines directly, and just work off of the agenda and capture.

-- tychoish

discourse

Mon, 25 Apr 2011 12:57:49 -0400

Mutt is indeed elegant. I used it for a while a few years back. I would certainly use it again if I did not have such a heavy investment in the Emacs ecosystem.

Mutt is often held up as a sterling example of the UNIX philosophy, and rightfully so. When I used Mutt, I learned about all the differences between an MUA, an MTA, and an MDA. As they say, "do one thing and do it well."

The contrast here is Emacs, which violates the Unix philosophy at every turn. (Good grief, Emacs ships with two irc clients and three mail clients, and many more of each can be downloaded elsewhere). The mail client I use, Gnus, is about as messy and chaotic as they come. You can read almost anything in Gnus (nntp, rss, mail in many formats, directories, and even whole web pages via a crawler); you can download mail, split mail, archive mail, send mail, post to nntp servers, turn web pages into feeds, schedule reminders, and more. It's slower and less efficient than mutt; but integration with emacs means that one doesn't have to learn anything new and that all the Gnus data can be copied, edited, and clipped easily. And Emacs offers the distinct advantage of a scripting language that is tightly integrated with a UI, so you can change almost every aspect of how the program behaves.

Sometimes I wish I could enjoy the minimalist desktops I see on the archlinux forums. But I'm too addicted to the seamless integration that Emacs provides.

madalu

discurse on tychoish wiki

Sat, 02 Apr 2011 16:27:15 -0400

I like the changes. I'm glad to see that you are leading the way in the great wiki revival of the next decade. In my opinion, we need more curated, interlinked content on the web (wikis) and less ephemeral, serially published content (blogs).

-- madalu

Thanks!

Here's hoping it's a revival, but I won't count it as such for a while. The two things thing that I need sort out, (and you might be of help on some of these points:

I need to do something to try and automatically template these discourse pages. I'm most interested in figuring out a way to get good page titles added. Goal: make pages look awesome without anyone having to do work, particularly not new commenters.
Some sort of convention for threading, and conversational back and forth. I'm doing the horizontal rule thing, (and this wiki is all markdown, so that's good and easy at least.) I think the block quote thing is a bit annoying, but maybe has merit in terms of visual clarity and threading. But to be honest this is very much at the bottom of the list. I'm worried about saying "you should do xyz, when you comment," and having that discourage commenting rather than encourange
Some sort of notify system? Or way to efficiently track comments? I think I'll just send you a link to pages out of band, but something here, even if it's just a "recent discurse" page might be nice.

Cheers!

-- tychoish

Discussion of Open Source Inevitability

Sat, 02 Apr 2011 15:11:56 -0400

Could one perhaps argue that open-source has succeeded by making it cheaper for smaller companies and individuals to build things themselves? In other words, its most disruptive impact has been to democratize access to the means of production (web server infrastructure, scripting languages, compilers like GCC, etc.). It flourishes in distributed networks and among people who need a great, free digital toolbox.

I certainly do not think the success of open source is inevitable, at least not in all tech markets. It has not succeeded with end-users of personal computers and other consumer and enterprise devices. Obviously, you can't build a proprietary software bundle on top of shared GPL libraries. Thus, on Mac OS X you get gargantuan application packages because each vendor has to reinvent the wheel, packaging all their libraries inside the bundle. (So, in addition to getting expensive applications on OS X, you get bloat.)

When people need a "magical" box, the internals of which are kept hidden from the user, open source has struggled. And owners of intellectual property are understandably suspicious of open source, usually choosing closed platforms (witness Amazon's proprietary ebook format or the recent excitement of publishers about the possibility of using iPad apps to charge for content). In these instances, various open source internals are often hidden beneath a closed userspace (witness Netflix, which serves streaming movies from Linux servers and has provided a silverlight plugin for the Linux-based Roku player, but not for other Linux users.)

In other words, the Linux desktop is in a state of perpetual dysfunction, but the open digital toolbox that is GNU/Linux is one of the wonders of the digital world.

-- madalu

In no particular order:

I don't think static compilation (the bundling thing) is actually a huge problem for OS X. They decided that it was better that every application be able to run and contain everything that it needed to run in a single bundle, than it was to: save a little bit of RAM, or save a little bit of disk space. And its easier to statically compile things than it is to get package management right. In all I think it's a fair trade off.
The inevitability that I'm writing to here is basically: given enough time, open source alternatives will become so good and so comprehensive that it will become very difficult
I'm not particularly convinced that in the long run "Free Software" is actually a lot cheaper. You don't have to pay licensing costs, but it's not unreasonable to expect that you'd pay support costs, or that you'd need to have someone in house to administer, develop, and customize the open source product to the organization's needs. I mean, open source technology might come out a little bit cheaper, but that's probably at the accountant stage and not at the decision making stage. Having said that, I think the economic model where you use a piece of free software, and hire one of the developers to do work for your seems much more sustainable and desirable than the whole licensing-based model.
I don't think that the Licensing-based businesses and the proprietary source-code method of software development/creation is going to go anywhere, and I think that there are enough cases where institutional practices haven't caught up to open source models that there's a medium-term future there (at least for enterprises.) But there's a difference between work with existing products and work in existing ecosystems (divergence here about the Apple App Store) and greenfield projects that I think requires a little but more attention.
It's not even so much the "Linux Desktop," as it free/open source software for desktops regardless of platform. I'm counting Firefox and Libre/Open Office for Windows and OS X in this.

-- tychoish