April 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 2019

Expand Cut Tags

No cut tags
mdlbear: (technonerdmonster)

A few years ago I read an article about how to set up a Mac for distraction-free writing. I can't seem to find it anymore (okay, some rather large value of "a few"), but "there's an app for that" now. Many writers on my reading list are talking about distraction-free writing tools like iA Writer (seems to be the one people are most impressed by at the moment) and FocusWriter (free and cross-platform). There's even an Emacs mode.

These all work roughly the same way: run a text editor in full-screen mode, and write plain text with simplified markup in a fixed-width font. Worry about formatting later, if at all. Grey out everything but the sentence or paragraph you're working on. The article I can't find -- written before specialized writing programs and even before the web -- suggested getting the same effect by taking all of the icons off your screen and setting your default font to Courier.

If you're happily using one of these tools, you may want to skip ahead to the section on formatting, and maybe fill in the gaps later. If you're still using a word processor, or typing into a text field in a browser (even in "rich text" mode), you should probably stick with me.

What You See is All You Can Get

WYSIWYG (What You See Is What You Get) word processors are arguably the worst thing to have happened to writing in the last half-century. They have three huge problems:

The first is that they make a promise they can't deliver on. In fact, they should be called WYSIAYCG -- What You See Is All You Can Get. If your word processor doesn't support kerning, multiple fonts, paragraphs with hanging indents large initial capitals, mathematical notation, or internal cross-linking, you can't use them. If they make it difficult to use these features, you still won't use them unless you absolutely have to, and then you find yourself wasting time doing clumsy work-arounds. Think about how you'd go about formatting song lyrics with chords over them. Shudder. How about making the space between sentences equal to one-and-a-half times the space between words?

The second is related to the first: word processors target a specific page layout. If you want to make a printed book, a web page, and an eBook, you're going to have to do extra work to accommodate the differences, or settle for something that has about the same level of mediocrity in all of those environments.

At a lower level, word processors use proportional-spaced fonts. That means you have to peer over the tops of your glasses to see whether that character at the end of the sentence is a period or a comma, and if your hands are shaking from too much coffee you'll have trouble selecting it. Or putting the cursor in front of it without selecting it, if you want to add a few words.

The third is that they distract you from actually writing, tempting you to fiddle with fonts, reformat your footers, worry about word-wrapping and hyphenation, and place your page breaks to avoid widows and orphans, at a time when you should be concentrating on content.

There's a fourth, mostly unrelated, problem which is so pervasive these days that most people accept it as The Way Things Are: if you accidentally select something and then type, whatever you selected goes away. In almost all cases, even if your word processing has an "undo" feature, this can't be undone. So let's talk a little more about...

Editing

Anyone who's been hanging around me long enough is expecting me to mention GNU Emacs at some point, and I will. But there are plenty of other text editors, and most of them are perfectly usable. They're often called "programmers' editors".

I'm not going to tell you how to use a text editor here; I'm just going to tell you more about why, and point you at some resources. Michael Hartl's Learn Enough Text Editor to Be Dangerous is a pretty good introduction to most of them, though you may want to skip the chapter on Vim. It gives short shrift to Emacs, but fortunately the first thing on your screen after starting Emacs is the tutorial. Start there.

So, why would you, a writer, want to use a programmer's editor?

One reason is that programmers have been writing on computers for a quite a bit longer than writers have, so text editors have a considerable head start. More to the point, programmers use their own programs. This gives them a strong incentive to make their programs fast, efficient, and powerful. Not every programmer who has a problem with their text editor is going to fix it, but enough do to make them improve rapidly.

Word processors, on the other hand, are written by programmers, but they are usually written for ordinary users, not experts, and they're written to be products, not programming tools. As products, they have to appeal to their customers, which means that they have to be easy to learn and easy to use. They don't have to work well for people who spend their entire work day writing -- those are a tiny fraction of the customer base.

Another reason is that text editors use fixed-width fonts and encourage you to use comparatively short lines (typically 72 or 80 characters, for reasons that date back to the late 1880s). Paragraphs are separated by blank lines. Since line breaks inside of paragraphs are ignored by formatters, some authors like to start every sentence on a new line, which makes them particularly easy to move around, and makes it easier to spot differences between versions.

A text editor also makes you more efficient by giving you a wide range of keyboard commands -- you can write an entire book without ever taking your fingers off the keyboard. (This is, in part, due to their long history -- text editors predate graphical user interfaces by several decades.) And most modern text editors are extensible, so that if you want new commands or want them to behave differently for different kinds of markup, they're easy to add. (I have a set that I use for my band's lead sheets, for example, and another for my to-do files.)

Markup

Up until somewhere around 1990, everyone who did any serious writing knew how to edit a manuscript using proofreaders' marks. Manuscripts were typed double-spaced to leave room for insertions, corrections, and cryptic little marks between the lines and in the margins. This was, logically enough, called "marking up" the manuscript. You've probably heard of Markdown. You've certainly heard of HTML, which stands for "HyperText Markup Language". HTML, in turn, is a variant on SGML, "Standard General Markup Language". You may have heard of LaTeX, which is the standard for academic -- especially scientific -- writing.

Markup languages let you separate content writing from formatting. Semantic markup lets you add additional information about what the things you are marking up mean; it's up to a stylesheet to determine what they look like . In HTML, you don't have to <i>italicize</i> something, you can <em>emphasize</em> a talking point, or <cite>cite</cite> a book title. They usually look the same, so most people don't bother, until they decide to turn all the book titles in their two thousand blog posts into links.

You can see how using semantic markup can free you from having to think about formatting while you're writing. There's another, less obvious advantage: you aren't stuck with just one format. By applying different styles to your document you can make it a web page, a printed book, an eBook, a slide show, or an email.

Another advantage of markup languages is that all of the markup is visible. This week's xkcd: "Invisible Formatting", shows how you can accidentally make a boldface space in the middle of normal text, where it can distract you by making an insertion unexpecedly boldface. It may also make subtle changes in line and word spacing that are hard to track down down.

There are two main kinds of markup languages: ones like Markdown and Textile, that use simple conventions like **double asterisks** for strong emphasis, and the ones that use tags, like <cite>HTML</cite>. LaTeX and Restructured Text are somewhere in the middle, using both methods. You can be a lot more specific with HTML, but Markdown is far easier to type. Markdown and Textile let you mix in HTML for semantic tagging; Markdown, Textile, and Resturectured Text all use LaTeX for mathematical notation. Some formatters let you embed code with colored syntax highlighting.

These days, it looks as though Markdown is the most popular, in part thanks to GitHub; you can find it in static site generators like Hugo and Jekyll, and it's accepted by many blogging platforms (including Dreamwidth). Unfortunately they all accept different dialects of Markdown; there is an enormous number of Markdown-to-whatever converters. But the nice thing about markup languages is that you aren't stuck with just one. That brings us to...

Formatting

Once you have a file that says exactly what you want to say, the next thing you'll want to do is format it. Formatting programs (a category that includes LaTeX, web browsers, website generators like Jekyll and Hugo) all use some kind of style sheet that describes what each kind of markup is supposed to look like. You probably know about CSS, the "Cascading Style Sheets" that are used on the web. LaTeX has a different set, written in the typesetting language TeX.

If you wrote your file in HTML and you want to publish it on the web, you're done. You may want to make your own stylesheet or customize one of the thousands that are already out there, but you don't have to. Modern browsers do a perfectly reasonable job of formatting. CSS lets you specify a separate style for print, so when a reader wants a printed copy it actually looks like something you'd want to read on paper.

If you wrote your file in LaTeX and you want to publish it on paper, you're done -- it's safe to assume that LaTeX knows more about formatting and typesetting than you do, so you can just tell LaTeX what size your pages, pick one of the hundreds of available stylesheets (or write your own), and let it make you a PDF. You can change the page size or layout with just a few keystrokes.

If you wrote your file in Markdown or some other markup language, there are dozens of formatting programs that produces HTML, LaTeX, PDF, or some combination of those. (My favorite is Pandoc -- see below.) Markdown is also used by static website generators like Hugo or Jekyll, and accepted by everything from blogging sites to GitHub. If you're publishing on the web or in some other medium your formatter supports, you're done.

The advantage of separating content from format is that you're not stuck with one format. Web? Print? eBook? You don't have to pick one, you have all of them at your fingertips. There are hundreds of conversion programs around: html2latex, latex2html, kramdown (which GitHub uses),... For most purposes I recommend Pandoc. The subtitle of Pandoc's home page calls it "a universal document converter", and it is. It can convert between any of the the markup languages I've mentioned here, and more, in either direction. In addition it can output eBook, word processor, wiki, and documentation formats, not to mention PDF. As an example of what it can do, I write these posts in either HTML or Markdown as the mood takes me, and use Pandoc to convert them to HTML for Dreamwidth and plain text, stripping out the tags, so that I can get accurate word counts.

Version Control, etc.

Text files with short lines are ideal for other tools in the Linux (and Unix -- did you know that Unix was originally used by technical writers?) environment. When you compare two files, a line-by-line comparison (which is what diff gives you) is more useful than a paragraph-by-paragraph comparison (which is what diff gives you if you don't hard-wrap your text). Text editors can run formatters, spelling checkers, search tools, and others, and put the cursor on the exact line you're looking for. Want to search nearly 6500 blog posts for your favorite quote from G. K. Chesterton? Took me one line and a little over 4 seconds.

        time find . -type f -exec grep -nHi -e 'rules of architecture' {} +

Many formatting tools simply ignore single line breaks and use a blank line to separate paragraphs, examples include LaTeX and most (though not all) Markdown translators. HTML ignores line breaks altogether and relies on tags. I take advantage of that to make HTML more readable by indenting the text by four spaces, and using 80- or 90-character lines. If you want an example and you're reading this page in a browser, just hit Ctrl-U to look at the page source. Compare that to web pages made without hard-wrapped lines -- you may find yourself scrolling dozens, if not hundreds, of characters to the right because browsers don't do any wrapping when displaying source. Nor would you want them to.

The biggest advantage (in my not-so-humble opinion) is version control. (Those of you who've been around me were just waiting for me to mention git, weren't you?) Being able to find all the changes you made this week -- and why you made them -- can be incredibly useful. Being able to retrieve a file from three years ago that you accidentally deleted is priceless.

This post is already pretty long, so the next post in this series is going to be about version control (and the other things you can do with git and GitHub; it's not just version control) for writers. Stay tuned.

Resources

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

TL;DR: Patch your computer NOW! (Or as soon as you can, if you're running Windows or Ubuntu and reading this on Monday -- the official release date for this information was supposed to have been Tuesday January 9th.)

Unless you've been hiding under a rock all weekend, you probably know that Meltdown and Spectre have nothing to do with either nuclear powerplants or shady investments: they are, instead, recently-revealed, dangerous design flaws in almost all recent computers. Meltdown affects primarily Intel processors (i.e. most desktops, laptops, and servers), and will be mitigated (Don't you just love that word? It doesn't mean "fixed", it means "made less severe". That's accurate.) by the recent patches to Linux, Windows, and MacOS. Spectre is harder to exploit, but also harder to fix, and may well present serious problems going forward.

But what the heck are they? I'm going to try to explain that in terms a non-geek can understand. Geeks can find the rest of the details in the links, if they haven't already chased them down themselves. (And if you're in software or IT and you haven't, you haven't been paying attention.)

Briefly, these bugs are hardware design problems that allow programs to get at information belonging to other programs. In the case of Meltdown, the other program is the operating system; with Spectre, it's other application programs. The information at risk includes things like passwords, credit card and bank account numbers, and cryptographic keys. Scared yet?

Basically, it all comes down to something called "speculative execution", which means something like "getting stuff done ahead of time just in case it's needed." And carefully putting things back the way they were if it turned out you didn't. That's where it gets tricky.

Modern computers are superscalar, which means that they achieve a lot of their impressive speed by doing more than one operation at once, and playing fast-and-loose with the order they do them in when it doesn't matter. Sometimes they make tests (like, "is this number greater than zero?", or "is that a location the program doesn't have permission to read?"), and do something different depending on the result. That's called a "branch", because the program can take either of two paths.

But if the computer is merrily going along executing instructions before it needs their results, it doesn't know which path to take. So, in the case of Spectre, it speculates that it's going to be the same path as last time. If it guesses wrong (and Spectre makes sure that it will by going down the safe path first), the computer will get an instruction or two down the wrong path before it has to turn back and throw away any results it got. Spectre makes it do something with those results that leaves a trace.

In the case of Meltdown, the test that's going down the wrong path is to see whether the program is trying to read from memory that belongs to the operating system kernel -- that's the part of the OS that's always there, managing resources like memory and files, creating and scheduling processes, and keeping programs from getting into places where they aren't permitted. (There's a lot of information in the kernel's memory, including personal data and passwords; for this discussion you just need to know that leaking it would be BAD.) When this happens, the memory-management hardware interrupts the program before it receives its ill-gotten data; normally the result is that the program is killed. End of story. On Intel processors, though, there's a way the program can say something like "if this instruction causes an interrupt, just pretend it never happened." The illegally-loaded data is, of course, thrown away.

Meltdown works because the operating system's memory is -- or was -- part of the same "address space" as the application program. The application can try to read the kernel's memory; it just gets stopped if it tries. After Tuesday's patch, the two address spaces are going to be completely separate, so the program can't even try -- the kernel's address space simply isn't there. (There's a performance hit, because switching between the two address spaces takes time -- that's why they were together in the first place.)

At this point you know what Spectre and Meltdown do, but you may be wondering how they manage to look at data that simply isn't there any more, because the instruction that loaded it was canceled. (If you're not wondering that, you can stop here.) The key is in the phrase "any more". During the brief time when the data is there, the attacker can do something with it that can still be detected later. The simplest way is by warming the cache.

Suppose you go out to your car on an icy morning and the hood feels warm. Maybe one of the local hoodlums took it out for a joyride, or maybe one of the neighbor's cows was sitting on it. You can tell which it was by starting the engine and seeing whether it's already warmed up. (We're assuming that the cow doesn't know how to hotwire a car.) The attack program does almost the same thing.

The computer's CPU (Central Processing Unit) chip is really fast. It can execute an instruction in less than a nanosecond. Memory, on the other hand, is comparatively slow, in part because it's not part of the CPU chip -- electrical signals travel at pretty close to the speed of light, which is roughly a foot per nanosecond. There's also some additional hardware in the way (including the protection stuff that Meltdown is sneaking past), which slows things down even further. We can get into page tables another time.

The solution is for the CPU to load more memory than it needs and stash (or cache) it away in very fast memory that it can get to quickly, on the very sensible grounds that if it needs something from location X now, it's probably going to want the data at X+1 or somewhere else in the neighborhood pretty soon. The cache is divided into chunks called "lines" that are all loaded into the cache together. (Main memory is divided into "pages", but as I mentioned in the previous paragraph that's another story.)

When it starts a load operation, the first thing the CPU does is check to see whether the data it's loading is in the cache. If it is, that's great. Otherwise the computer has to go load it and the other bytes in the cache line from wherever it is in main memory, "warming up" the cache line in the process so that the next access will be fast. (If it turns out not to be anyplace the program has access to, we get the kind of "illegal access exception" that Meltdown takes advantage of.)

The point is, it takes a lot longer to load data if it's not in the cache. If one of the instructions that got thrown away loaded data that wasn't in the cache, that cache line will still be warm and it will take less time to load data from it. So one thing the attack program can do is to look at a bit in the data it's not supposed to see, and if it's a "1", load something that it knows isn't in the cache. That takes only two short instructions, so it can easily sneak in and get pre-executed.

Then, the attack program measures how long it takes to load data from that cache line again. (One of the mitigations for the spectre attack is to keep Javascript programs -- which might come from anywhere, and shouldn't be able to read your browser's stored passwords and cookies -- from getting at the high-resolution timers that would let them measure load time.)

Here under the cut are a basic set of references, should you wish to look further. Good stuff to read while your patches are loading.

Notes & links )

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

This is the start of an experiment.

Last night, N took me to task for wasting my retirement time puttering around the house, reading blogs, doing things for Colleen, and not doing any of the things I retired in order to have time for: recording, writing, and programming in particular, with a side of woodworking. She pointed out that if I'm going to spend my time doing stuff that we could hire a housekeeper or caregiver to do, the family would be better off if I went back to work and we hired people to do those things. (Or increased their hours, since in fact we already have a housekeeper and caregiver.)

So.

I realized that Colleen doesn't really need all that much help these days. Normally I've been teaching on the days when Colleen has a caregiver around, and spending more time with her on the days when she doesn't. But in fact, when I've switched (for whatever reason), Colleen does perfectly well with a little help around lunchtime and in the late afternoon. So if I switched, I'd have two large blocks of time completely to myself: 8:30 to 11:30 (my teaching time, but potentially expanded to 8:00 to noon) and 1:00 to 4:00. That's six or seven hours, at least two days a week and potentially three on weeks when I'm not needed Friday.

N. suggested that I start each block with 15 minutes of guitar practice, to get my fingers back in shape without hurting, then pick something from the project list (I'll get back to that) and keep going with it as long as I'm sufficiently engaged. Then switch to something else. Lather, rinse, repeat (like the programmer who died in the shower:). I could do guitar practice at 8:00 on teaching days, and I should probably schedule time for walking as well, say 4:00-4:30 or so.

So I did that this morning, starting out with guitar at 8am and continuing on to writing. It is now 9:09. I missed breakfast; I can squeeze in some cottage cheese between now and the next sub-project. Which should include working on the project list.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

A few days ago I got a comment on my weekly post that went Oohh, you're doing what looks to me like a bullet journal? Only online. So I wrote a quick explanation. And then I realized that I might be doing something unusual, that I ought to write up in more detail. So here you are:

The Legend

Let's start off with the file called Journals/Dog/legend.do:

			       ===legend.do===

= item flag notation for to.do and to.done files:

= notation for to.do and to.done items:
  = note: keep  o to do  * done  x abandoned  ~ modified  . in progress
  & added after completion  (recurring items get * when completed)
  $ financial transaction (flagged as  o before completion)
  ? query/decision...  - choice  + chosen  ->chosen
  @ link/research
  ! emotion noted at the time, or soon after.  NOT added the next morning; 
    I'm trying to pay more attention at the time
  | body sensation worthy of note: pain, noticable change...
    (more recently replaced by %; should maybe go back to |)
  : observation or external event.  Weather, news, etc
    + external observation with positive emotional content
    - external observation with negative emotional content
  % observation/insight about myself
  # meta - flags, flist, filters, ...
  <b>...something I feel good about...</b> (may be added next day)
  <i>...something I feel bad about...</i>
  [ ... ] delete from public posts
  ... ongoing items
  " quotation
  ' interior dialog

= Notation for meetings and conversations:
  <- point to bring up.  After meeting, point to bring up next time
  *- point brought up
  x- point not brought up
  ~- point partially brought up, or brought up in different form
  &- additional point raised  
  -> information/point raised by someone else/consequence/resolution
  => action item for me
  =* action item done
  <= action item for somebody else.

===

The History

My usage has shifted a little over the years. I first started posting "to.do" items around 2006, though I'd undoubtedly been using at least the o and * flags for years before that. At first, since I was part of a support group working on procrastination and avoidance, I used it as an accountability thing: I would post a list of open items, followed (hopefully) by the items as they got checked in. It was a little discouraging, until somebody suggested just posting about what I'd done. That led to &, and my expanded use of the file as more a log than a to-do list and calendar.

Whenever the list of "done" items got too long, I would move them into a ".done" file -- the first one I have is 2006.done. In 2009 I switched to quarterly archives; by 2009/q4.done the file had most of its present features. By 2011 I was archiving monthly. I don't remember offhand when I stopped making daily posts in LJ and switched to weekly.

Sometime in September of 2011 I decided that the set of unfinished and probably never-to-be-completed items had gotten too long, and moved it to wibnif.do, as in "Wouldn't It Be Nice If..." My present Makefile plugin reports the current number of unfinished items in to.do and wibnif.do; the current numbers are 70 and 126 respectively.

The Files

So there's that. The file is called to.do, and edited with emacs. There are a couple of important marker lines in it:

=========================================================================================+
Ongoing:                                                                             89->|
recurring items and long-term goals go here
=then===================================================================================>|
this contains entries from the first of the month to the present
=now===-^-===this-month-v-==============================================================>|
scheduled items for later this month
=later===-v-===this-month-^-============================================================>|
scheduled items after this month
=sometime===-V-===later-^-==============================================================>|
items with no specific due date
=Done-v-================================================================================>|

Dates, in the form mmddWw (e.g., 0122Su), start in the first column; flag characters are indented two spaces. The marker at column 89 makes it easy to properly size the editor window when I first open it after rebooting; it's where lines wrap.

I'll put approximately-scheduled items in the this-month and later sections after the dated entries, and a few of the more important ones above =now. That doesn't keep me from procrastinating them, but it does help keep them where they'll be noticed.

Note that, except for the breakpoint at =done, entries are in chronological order from top to bottom. That makes this a log, not a blog or feed. My to.do and its associated history (see below) are one of a handful of journal-like collections under my Journals directory; the to.Do lOG is kept in a a directory called Dog.

The Archives

By now, I have a fairly well-established routine:

  • I maintain the to.do file using emacs, of course.
  • Sometime on Sunday, I move the last week's worth of entries from the working location near the top of the file, to the end.
  • At this point I still have the week's entries in the Region (emacs terminology for the current selection). I move point down two lines to scoop up the HTML boilerplate that I'll need for my weekly post, and copy (M-w).
  • Then I run lj-update, currently bound to M-L, and yank into the body. The boilerplate is arranged so that all I have to do is move back up two lines, cut, down one, and yank.
  • From there it's an easy step to go back to the first line (which is invariably the start date) copy it, and yank it into the subject line.
  • Write my summary. Edit out any [...] sections, if necessary.
  • Post.

Then,

  • Every month -- actually, on the first Sunday of the month, after making my weekly post -- I move the month's entries to yyyy/mm.done.
  • Every so often I go through and pull out obsolete entries, marking them with * or x as appropriate, and put them after the preceeding week's entries at the end of the file.
  • Every year, on New Year's Eve, I gather up my list of goals and make my end-of-the-year post.
  • The next day, I cons up my new list of goals and make a New Year's post.

Variations

I keep other, project-specific, to.do files. Most of them are much simpler, with undated items above the =done line (which is usually just a line of equal signs), and dated items after it in what I now call a "work log". It's convenient, because I can just go to the end of the file and make an entry, but it wouldn't work nearly as well if I had to schedule things.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

This post covers most of my week-long vacation, so while it's not quite time for a wrap-up of my goals, I can say that I met about half of them. Which was about what I expected.

The big accomplishment for the week, without a doubt, was posting my one-line Linux setup/configuration package up on GitHub. (I then spent much of the rest of the week debugging and tweaking, but that's also to be expected.) It's called Honu, after the Hawaiian name for the green sea turtle, because a turtle carries its home around with it. The README starts off with this quote from my song, Windward, because I just couldn't resist:

Where the wind takes us next year no turtle can tell
But we'll still be at home, come high water or hell,
Because home is wherever you carry your shell.

The implied puns on $HOME and sh(1) are, of course, entirely intentional.

Honu is meant to be fairly general; it's expected that any user -- including me! -- is going to want to customize the heck out of it. To that end, there's a sample customization package, also on GitHub, called Myrtle. Of course. (My own customization package, which you will not find on GitHub, is called Mathilda, after LookingGlass Folk's name for the narrator of "Windward".)

It hasn't been all roses and rainbows, however. I've spent an inordinate amount of time coping with the bindweed (morning glory's evil twin) that has overgrown the walkway along the south side of the house, sorting a year or two's worth of mail, and recovering from last week's disk crash on the server. I've been doing quite a lot of writing, though a lot of that has been on Quora, so I'm not sure whether that counts toward my daily writing goal, or away from it.

I'll say one thing for Quora, though -- it makes me appreciate my own knowledge and social skills. Being able to answer questions is a real boost to my self-confidence in both those areas. Who knew?

Psychologically, well, ... mixed. I've definitely been less stressed out the last two days of the week than the first two -- I was able to handle a trip downtown that turned out to be a total write-off, due to things being closed/not where I expected, quite calmly and even with a little wry humor. The check from last week's stock sale arrived on Tuesday, which helped. On the other hand, it still apparently doesn't take much frustration to put me back over the edge.

I was a total wreck on Sunday. I seem to handle stress a lot better when I'm by myself. With Colleen around, especially, I get into a horrible feedback loop. By the time I got home I could probably have used an Ativan, but my prescription on those has long since expired. I settled for reading and gin. Low blood sugar may have contributed; I'm not sure I can tell the difference between anxiety and hunger. Alexithymia in action.

I am not ready to go back to work tomorrow. I may never be ready. I'll do it, but it won't be pretty. Notes & links, as usual )

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

Moderately productive. Two "publishing events".

  1. Sex and the Single Link is up on my "formal" website, Stephen.Savitzky.net. This is, despite the clickbait title, an article about the joy of singly-linked lists.
  2. MakeStuff is up on GitHub. This the first of several projects I intend to put up there; it's the collection of makefiles and scripts that powers all my websites. You can see it in action here.

Apart from that, and a bunch of Quora answers, not a whole lot going on. One my Quora answers led to a good discussion on the comment thread. Fairly prodctive at work, though as usual not quite as much as I wanted to be.

One particularly interesting article for the programmers in the audience, Developer Differences: Makers vs Menders, which seems to describe me fairly well.

Also of note, the first episode of the Lesbian Historic Motif Project Podcast: Ordinary Women by Heather Rose Jones ([livejournal.com profile] hrj on LJ) is up.

Notes & links, as usual )
mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

Moderately productive this week. And I've been doing quite a lot of writing, mostly on Quora. Which is seriously addictive. One of the reasons I like it, I think, is that it demonstrates to me that I know more about people and relationships than I give myself credit for. It also inspired me to get started on the article about singly-linked lists that I've been meaning to write for months. (The draft can be found here, but be advised that it's only about half finished. Look again on Tuesday or thereabouts, or wait for me to post it here.)

That raises a question: If it ends up being long (currently at a little over 1000 words), do you have a preference for long posts under cut tags, or shorter installments without cuts? What's a good length for installments? (For comparison, my current weekly posts seem to be running 250-500 words before the cut, and I haven't heard any complaints.)

I'm not even going to try posting my Quora answers here or on Facebook; I am cross-posting most of them to Twitter (@ssavitzky) -- the bandwidth there is so high that nobody is likely to feel as though I'm spamming their feed. I do link a few of the more interesting answers in the notes, so you can see for yourself.

Anyway... Moderately productive at work, though meetings have eaten up a lot more time than I allowed for. Only a couple of overloads at home. Blood pressure higher than I like, but my doctor isnt worried yet. More in the notes.

Notes & links, as usual )
mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

Fairly productive at work this week, though I lost Friday to an all-day training session. (I made up some of that yesterday in between lab work and my doctor's appointment. Went in early because the appointment wasn't until 1:40, and I wanted to be able to have my coffee before noon.) I appear to be in pretty good health; my blood pressure was 129/75; which is decent.

The training Friday was a workshop on Scrum. Tl;dr: we've been doing it wrong. Which is not unusual. My impression has always been that it works best for things that can be built incrementally -- the idea is to break things down into "features" (corresponding to "user stories") that can be built in one sprint -- typically two weeks -- and end up done, in production, and demonstrated to the customer at the end of that. The theory is that the team gets more and more familiar with their product and their process, so they get better at estimating. And there's an expectation that developers are mostly fungible -- anyone can pick up any of the tasks and finish it in a couple of days. (Specialists like QA, tech writer (we should be so lucky!), and maybe a web developer, don't count.)

So let's look at the project I'm currently on: We have four developers. One is building a new service, one is working on the web front end (and just came on board), and two are working in different, pre-existing services that they've never worked on before. The work being done in the latter case is such that a sizeable number of pieces have to be in place in order for anything to work. Meanwhile, other teams are working on other parts of the same services, with somewhat different requirements. Theoretically, each of the three main developers could work on any of the tasks, but in practice there's a lot of context in each of those sub-projects that it would take a long time for anyone else to ramp up on.

It doesn't help that the manager and web developer are in Vancouver, and that most of the design was done almost a year before the work started, under a different manager, by three developers one of whom got pulled off to work on a totally unrelated project. This leaves only two of us with any real context.

On the other hand, I've been having fun with configuration files and makefiles. The latest hack was adding color-coded labels to the workspaces in my xmonad setup. You say "ws 2 to.do", for example, and you get a color-coded label at the top of the screen in workspace 2. The labels use standard resistor color codes, and include a clock (because the quick thing was to base them on xclock). Here. (Need to get this onto github soon.)

Writing: met my minimum goal of 500 words two days a week, but just barely. Both were in PJ (short for Private Journal), so not on DW or the website where you can see them. Sorry about that.

Notes & links, as usual )
mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

You may want to start with Part 1

 

Xmonad is a tiling window manager. That means that, with very few exceptions, it lays out all of the windows in your workspace so that they completely fill the screen. You can have multiple layouts, and flip between them with a single keystroke. You can bring a workspace (there are 9 by default, but you can add more) to your screen with a single keystroke, or send a window to a workspace.

And the whole thing is configured using a text file that is actually a program, written in the functional language Haskell. I'll get to that later.

One of my main gripes about Gnome, etc., and one of the things I miss the most about CTWM, is that when you first start a program its window shows up at some random location on the screen, with whatever size the program thinks is appropriate. If you don't like those choices you have to move and resize the window yourself, and then do it all over the next time you log in. (There are some exceptions -- many newer programs remember where you put them last, and older programs, from the CTWM era, can be given a starting geometry.)

Xmonad's layouts are all deterministic, which is to say, predictable. When you start a program, you know exactly where it's going to be on the screen. When you change the layout, you know where everything is going to go. If you want to move a window into the main position (most layouts have one; e.g. the left-hand column) it's (as usual) just one keystroke to put it there.

But the best thing, and the reason I switched to xmonad in the first place, is the way it treats multiple monitors: it simply assigns one workspace to each monitor.

Undock your laptop, and its screen stays exactly the same. The workspaces that were shown on the other screens simply go back into hiding with all the others, and are still only a keystroke away. When you have multiple screens, you can move a window to another screen, or bring a workspace to a screen, or warp the pointer to another screen, all with single keystrokes.

When you go to a conference room and plug in a projector, a workspace immediately shows up there and its layout automatically adjusts to the projector's resolution and aspect ratio. When you get a new computer -- all the developers at work got new laptops just a month or two ago -- just copy your configuration files to it and everything will be exactly the same as it was on the old one. (Sometime later I'll write about my portable configuration, which makes it possible for me to set up my entire working environment in mere minutes.)

 

So let's go a little deeper into those magic keystrokes. First of all, you have to know that all of the commands (you can't really call them shortcuts) include a key that xmonad calls "Mod" (short for "modifier", of course). Mod is initially defined as Alt, but the first thing any Emacs user is going to do is redefine it as something else, usually the "logo" key. (That's the one on the left between Ctrl and Alt that usually has a Windows logo on it. If your keyboard has replaceable keys you may be able to get a penguin for it.) On old laptops that don't have a logo key I use Ctrl-Alt, but that's a matter of taste.

You also probably want to know that Mod-? gets you a list of all the commands. And that there's a fantastic collection of tutorials, documentation, and sample configuration files at xmonad.org.

When xmonad starts up, you see a totally empty, black screen. Most people, myself included, add a status/navigation bar at the top, but you don't have to. I'll get to that later. You can start a program by typing Mod-P, or open a terminal window with Mod-Shift-Enter. You will immediately notice that the first window you open fills the screen. If you open another, xmonad will tile the screen with them, showing them side by side.

If you start a third program, it will get added to the right-hand column. You can probably see where this is going. When you move the mouse pointer into a window, it gets a thin red border to show you that it has "focus".

If you decide that you started things in the wrong order, move the pointer into the window you want to put in the left-hand column (the "master" column) and hit Mod-Enter. You close a window you're done with using Mod-Shift-C.

Here's where it gets interesting: Mod-Space will switch you to a new layout, with the master column turning into a master row, and all the other windows across the bottom. Hit Mod-Space again, and the currently-focused window goes full-screen. (I reconfigure my full-screen layout to put a row of tabs across the top. Wondering how to see the hidden windows? Mod-Tab moves focus to the next window in the stack. It also works in other layouts, so you don't need the mouse to move focus around. If you spend most of your time in a terminal and an editor like vim or emacs, you can throw your mouse away and still be productive. Mod-Shift-Tab moves focus to the previous window.

Mod-2 puts you into a second workspace. There are nine of them. (I add two more -- 0 and -.) If you want to move a window, say from workspace 2 to workspace 1, use Mod-Shift-1. That's kind of a recurring theme in xmonad -- Mod-something does one thing, and Mod-Shift-something does something related.

You can see that in action if you add an(other) monitor. Now, workspace 1 is in the left-hand screen, and 2 is in the right-hand screen. Think of the two of them as West and East.

Now, Mod-w will move the focus (and the mouse pointer) into the West screen, and Mod-e will move the focus into the East screen. Mod-1 through Mod-9 will bring that workspace into whatever screen has the focus. If the other workspace was already visible, they trade places. (Some people don't like that, so you can change it so that it just moves focus into the other screen if you select a workspace that's already visible.)

Add a third screen to the right of East, and call it Right. Now, Mod-r and Mod-Shift-R do exactly what you would expect. (There are no bindings for T, so I suppose that if you have space for a fourth screen you could use it for that.)

There are more key bindings, to move focus (Mod-j and Mod-k focus the next and previous window, respectively; shifted, they swap the focused window with the next or previous window), to shrink and enlarge the master area (Mod-h and Mod-l respectively), or increase or decrease the number of windows in the master area (Mod-Comma and Mod-Period respectively).

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

As I mentioned about a week ago, I've been trying to write more. And since my current obsession is a program called xmonad, well, ...

This is incomplete: it's about the first day's worth (I've been trying to write about 500 words per day). Comments and suggestions are, of course, welcome.

 

My new 27" monitors arrived at work; I took advantage of the change to rearrange my work space. Before, it was the set-up I've had for most of the last three years -- monitor in front on a stand, second monitor on the right, and my laptop on the left. The new laptop, however, has a decent keyboard (with trackpoint and three buttons), and the monitors between them occupy about 2/3 of the desk.

The new arrangement has the laptop dock under the "middle" monitor; the laptop, being a business-class Dell, has both a pointing stick and a middle "mouse" button. The laptop's keyboard is decent enough that it can replace the thinkpad keyboard I've been using for the last couple of years -- it's a high-end Dell, and has both a pointing stick and a middle button. (The middle button has part of the Unix desktop environment since the mid 1980s; it means "paste", and I use it all the time.) The monitors are about 50% bigger, pixel-wise, than the laptop, and are arranged "traditionally" with the laptop on the left.

You can probably see the problem with this arrangement. The total workspace is about 7000 pixels wide, and it's not even arranged in a straight line -- to get from the laptop to the "middle" monitor you have to move the cursor to the right, but the natural direction would be straight up. What's more, when you undock the laptop the whole thing collapses down to a "mere" 1920x1080. It's no wonder that most of the programmers in my team have opted for a single 30" monitor, and keep their laptop (almost invariably a mac) closed while they're using it.

Fortunately, I anticipated this problem months ago, and started using a window manager called xmonad.

 

One of the things I love most about Linux is the fact that the program that manages the layout of the screen and the behavior and appearance of the windows on it is not part of the operating system. It's a separate program, sensibly called a "window manager", and it runs in user space as a perfectly ordinary application that just happens to have a couple of extra hooks into X, which is the (also ordinary) program that actually controls the display, the keyboard, and the mouse.

Being an ordinary program -- and not even a terribly complicated one -- anybody can write one, and many people have. For a long time I was using one called TWM (Tabbed Window Manager, but the T originally stood for Tom's). Later I started using CTWM (Claude's Tabbed Window Manager), because it introduced the then unfamiliar notion of multiple workspaces. (Before CTWM, these could only be found in an experimental system at Xerox where they were called "rooms". Apple introduced them decades later, as part of MacOS X.)

You've probably heard of Gnome, KDE, and Ubuntu's horrible Unity desktop environments. Down at the bottom, they're just window managers plus a couple of utilities for doing things like putting up the familiar bar (Gnome calls it a "panel") full of menus, launcher buttons, clocks and other widgets. You can, in fact, run gnome-panel under any window manager, and I did for a while. They also include a "session manager", which handles things like starting the panel and making sure that applications get notified when you log out, so that they can save their state and exit cleanly. I've been using Gnome for years, and loved it for its configurability.

But Gnome's configurability comes with a cost -- every time you move to a new computer, you have to spend an hour clicking around in control panels and property windows to get everything set up the way you like it. And every time there's a major upgrade, something is a little different. It's a cost I no longer have to pay.


Part 2

mdlbear: (lemming)

So... I've seen this several places. Snippets from three works in progress.

Here you go )
mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

Lots of puttering this week -- sorting unpaid bills, re-arranging shelves, a little cooking, a little cleaning, lots of mostly-uninteresting work.

Cat cuddles. I really think the cats are better antidepressants than my SSRI, which I've been cutting back on without noticable effects. So far.

And I wrote a poem! Go read: Shifts (also on DW and LJ; follow the linkies). It's already gotten some interesting reactions. I obviously need to update my Lit pages -- there are only three poems there, and I know I've written more than that!

Links, as usual, in the notes.

raw notes, with links )
mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

Another rough week. But I put out three posts with actual content -- one informative (The Justin Case file), one River post (Empathy) and one demifiction (Introducing the Melody/Rose 'verse). So I should be feeling accomplished. I'm not, particularly.

Mostly what I'm feeling is broke, and worried about money. The house in San Jose still hasn't sold, so I'm carrying two mortgages as well as a horrendous amount of other debt. Not good.

Links below, many of them depressing.

raw notes, with links )
mdlbear: (space colony)

So, I guess I'm finally going to do it. Things have come a long way since I wroteSilk and Steel in 1988, and The Rambling Silver Rose in 1992, and I'm going to have to change a lot of the earlier back-story to catch up. *sigh* So here I am, revising in realtime without a backup. We'll see how far that gets me.

 

From The Backworlds Guide to the Solar System, 2188 edition
The Golden Cockroach $$ ****

Assuming one can get to Hacktown (which, depending on the whims of its inhabitants and the configuration of the Interplanetary Transport Network, could easily be anywhere between the orbits of Venus and Jupiter), and assuming it is open to visitors (which is usually a reasonable assumption), the Golden Cockroach is not to be missed.

The 'Roach, as it's usually called, is the oldest restaurant in space, having opened for business in early 2039 shortly after Hacktown was founded. It is still run by descendents of Frank and Susie Wong, who originally ran the Golden Dragon in Sunnyvale. Their Hacktown Fry, still served the traditional way in the center of a sphere of guests with chopsticks, is justly famous, as are the Egg Foo Bar and Hacked Chicken. Note that living in zero G dulls the sense of taste, so don't be afraid to ask for "spicy".

 

Open Mike's $/$$$$$ ***

Across the main sphere from the 'Roach you'll find Open Mike's Saloon. Mike's is, of course, best known as the home of Lady Melody, who has been been running the joint -- and hosting its legendary song circles -- since the death of her partner Geoff Kalman in 2042. However, it is almost as legendary in other circles for its booze, a collection which ranges from the ordinary to the esoteric. The best of the everyday brews is undoubtedly the locally-made Hashtown Pale Ale, made from malted hemp seeds. The cellar, by appointment only, is the most extensive anywhere off Earth, mainly because Mike's accepts bottles in trade.

 

Notes:

Mike's is named after the fictional proprietor of the alt.callahans newsgroup, one of the earliest and most influential "virtual places".

The Interplanetary Transport Network is a network of gravitationally determined low-energy paths connecting the L1 and L2 Lagrange points of the planets and their satellites.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

(This bit of nonfiction is being written in response to recent events; it also seems to fit the "communication" part of the theme, "Community & Communication", of this month's Crowdfunding Creative Jam)

Someone died recently and left his widow with a problem: his computer's hard drive is encrypted, and he didn't leave the recovery key or his password anywhere that she can find.

Oops.

This is not unlike losing track of the key to the safe deposit box, forgetting the combination to the safe, or neglecting to make out a will. "But I have all that in a file on my computer!" I hear you cry.

Oh, right.

You need a JustIn Case file, someplace where it's safe but reasonably easy to find if anything happens to you. (I'm talking to myself here, too, by the way.) The bare minimum is whatever it takes to get into your computer (a FileVault recovery key, BitLocker PIN, or alternate admin password) and possibly into your password file, browser keychain, or whatever. *That* information needs to be in a couple of different places known to your family! At least one place should be outside your house, e.g. with a trusted relative, your lawyer, your safe deposit box, or the like. The other place should be in your house, e.g. in a locked filing cabinet (they're pretty easy to break into if necessary). Lable the file "Justin Case".

Even if almost everything is on your hard drive, there's a minimum set of things that have to be written down on hardcopy:

  • Your master password, recovery key, or whatever it takes to get into your data. Or at least all of your data that you don't want effectively burned when you're gone. (Keep that separate.)
  • The location of your will, safe deposit box, offsite backups, retirement and bank accounts, life insurance policies, and so on.
  • The name of your executor/executrix.
  • Any important information that your family is likely to need

My plan is to add an SD card with my most important files on it -- I checked, and the directory with all my passwords, tax information, receipts, and so on is only about 200MB. Perfect use for an old 500MB card or thumb drive that's too small to be useful for anything else.

Don't forget to update it if you change your password! That, after all, is the main point of this little exercise.

mdlbear: (river)

I haven't been writing much at all lately. I'm thinking it's time I did. There are a good number of things I'd like to get back to work on; some of you might have preferences or suggestions.

Part the First: Once and Future Posts

There are several series of themed posts I'd like to get back to work on. I suppose I might be able to put out one or two -- not one of each, though that would be really nice -- every week. We'll start with the ongoing series -- there's a lot of meta work that needs to be done, like a landing page, tagging the strays, and so on.

Not to mention copying them onto my website, and working out a way to host them there and have them crosspost onto DW, LJ, etc. rather than the other way around.

The River

The longest-running series of blog posts so far is The River -- posts here tend to be introspective, on sub-themes like friendship, love (whatever that is), stress, depression, and the care and feeding of geeks. If you want to start at the beginning, it's here at skip=500. Gleep.

I'm going to keep going with this, of course. At one point I was thinking of gathering the posts between 2008 and 2010 or thereabouts into a book, with the title Two Years On the River, but of course never got around to it. Plausible?

Technology

Most of these articles never got onto LJ; it's a series of artcles on my website over a decade ago. This is mainly about Linux. Other articles along that line include Adventures in Family Computing. Repost them on DW? There are also a lot of computer and networking posts that could easily fall into this category.

I could probably put things like cooking, woodworking, and my post about how to load a dishwasher under here.

Things with Tales

This one really needs some organization. I've written about several of my "things", including luggage, laptops, and musical instruments, but the only tagged one at the moment is The Hartmann bag.

Songs for Saturday

This one is pretty self-explanatory. I should get back to it. Even though it quickly became rather a lot of work, it had and has the advantage of being based on (but be careful always to call it please) research rather than originality.

It occurs to me that I could easily fill this in by posting some of the notes/backstories of my songs. Hmm.

Songs and Poems

In addition to writing more of these, I need to go back and consolidate the tags, since I see that I've also used "songs" and "poems" in a couple of cases.

Should I post highlights from the past? Dredge up some of the poetry I wrote in college and type it in? Grovel through the usenet archives?

Understanding Ursine

This is a project I've been thinking about for a couple of years now; I seem to recall making a bit of a start in a River post. You see, my use of language tends to be a little, shall we say, idiosyncratic. Words and phrases like "sorry" and "working on it" could easily generate a longish post.

Part the Second: Fiction

I've always wanted to write science fiction. I've always been pretty bad at it. This may be something I could work on. There are two longish pieces that were, at one point, almost "finished" in the sense of having a beginning, middle, and end, with a semblance of plot in the middle. Both would require a fair amount of work.

Rambling Rose

This is probably the closest thing to a finished story, best described as the back story to my song The Rambling Silver Rose (and something of a sequel to Bound For Hackers' Heaven. It's 700-odd lines; maybe serialize it here? That would be good for a couple of posts. What's a good size?

A Place to Run Free

Bound For Hackers' Heaven isn't just a song; it actually came out of a story that I wrote back in 1988. Along with several others, some of which are on my CD. And it's part of the backstory to Silk and Steel. It has a lot going for it, and it needs a nearly-complete rewrite. I mean, 1988.

It's written as a series of forwarded emails. The absolute minimum that could be done to fix it would be to change the framing to make them blog posts, pin down the dates (in 2030 and 2038), and change the author of the cover letter from Lexy to the viewpoint character, Lady Melody. Who is an AI built into a guitar.

On the other hand, a rewrite would be a pretty big can of worms to open -- the temptation would be to fill in more pieces of the blog, and to tie it in with S&S (which takes place at least seven years later, and there's a huge hole in between). (It's also 150 years before Rose; the Lady is still around, of course, and so is Hacktown, which gets a brief mention.)

But it would be fun. I think.

Part the Third: Longer Non-Fiction

Of course, any of the post series could turn into a book, though not all of them would benefit from such treatment. Here we turn to the few projects that were planned from the start as books, and are far enough along to actually have a hope of getting finished.

Neither of these is on the web, and both are written in LaTeX (which isn't an insurmountable problem -- there's a LaTeX-to-HTML converter which I've used quite a lot).

The BIG Number Book

This is actually pretty much finished, and has been since 1999, except that it's meant as a kids' book, so it needs illustrations. A large number of them.

The Magic Mirror

If Rambling Rose is the back-story behind The Rambling Silver Rose, The Magic Mirror is the back-story behind The World Inside the Crystal. Inside the computer is a world where magic works.

I really need to get back to this. The oldest commit log message, from 1998, says "initial checkin of Aug 18, 1996 version". The only thing after that is a minor spelling correction. So, yeah. Needs updating.

There's an outline and the chapter heads, but it's very incomplete. And of course it predates most of what we think of as the Web.

So there you have it.

Thoughts? Did I mention that I tend to get paralyzed when I have too many choices? Yeah, that. Did I also mention my recording projects? I did not. Those have been stalled for a few years, too.

Sometime soon, maybe even this week, I should post something more about where I intend to go from here. Getting the nonfiction books onto the web might be good places to start, though it's always tempting to spend time revising, editing, and organizing rather than actually writing.

I don't have a very good track record with New Year's resolutions, either.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)
raw notes )

A reasonably productive day: a lot of puttering, some singing (just before going to bed), tasty dinner, and a lot of writing (for once!). The writing, in particular, was Colleen's and my biographies for our FGOH gig at Baycon; I decided that my standard one was too short. The results, along with my previous effort, can be found here.

Dinner was shrimp and scallops in a garlic, butter, and wine sauce, with brown basmati rice and asparagus. I figured, rather than go to an expensive restaurant... Colleen liked it, so I Win.

Still seems as though I didn't get much done, but I suppose I'm just going to have to get used to that feeling.

mdlbear: (vixy-rose)

Now that she's made the public announcement, I can point you at my dear friend [livejournal.com profile] pocketnaomi's shiny new website, PocketPoems.net. As webmaster perpetrator, any gaffes in the layout or HTML coding are mine, as is any delay in getting it from a hastily-thrown-up single page to an intricate and beautiful site more worthy of her poetic talents.

Go and buy yourself or someone you love a poem. You'll be glad you did.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

I said in this post that I would be trying to carve out an hour a day for music and/or writing. I haven't been keeping careful track, but given that Tres Gique put in 7 or 8 hours' worth of practice time over the weekend, I've been doing ok on average.

Most of this week has been spent splitting up the recordings of the practice sessions -- not too creative, I'm afraid -- and writing up summaries and a technical report. I've gotten a little writing done on drafts in the River; I'll try to get at least one of those posted tomorrow.

I'm still finding it deeply weird that I seem to have slipped into the role of relationship consultant ("counselor" is too strong, I think) for geeks and people in love with geeks.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

Somehow the River has transmogrified itself from a series of introspective LJ posts into a Project. I have a directory with a handful of draft posts in progress in it, a to.do file with half-a-dozen more ideas, and an archive with some 20K words worth of posts in it (since the end of May, and not particularly complete at that; a quick check with wget and wc gets more like 40K, but that's an overestimate because many posts with the tag are only partially on-topic).

It occupies at least as much of my time and attention as filk music does these days. I'm starting to think of a wiki, and possibly even a book. (A Year on the River?) ETA: Before you ask: Yes, I would protect your privacy if I did anything like that )

I apologize in advance.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

From this post by [livejournal.com profile] cadhla comes a link to 50 thoughts on writing in her writing journal. Good stuff; well worth a read if you're doing anything creative, either as work or as a hobby.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

Non-Errors -- (Those usages people keep telling you are wrong but which are actually standard in English.

Split infinitives

For the hyper-critical, “to boldly go where no man has gone before” should be “to go boldly. . . .” It is good to be aware that inserting one or more words between “to” and a verb is not strictly speaking an error, and is often more expressive and graceful than moving the intervening words elsewhere; but so many people are offended by split infinitives that it is better to avoid them except when the alternatives sound strained and awkward.

Hopefully

This word has meant “it is to be hoped” for a very long time, and those who insist it can only mean “in a hopeful fashion” display more hopefulness than realism.

People should say a book is titled such-and-such rather than entitled.

No less a writer than Chaucer is cited by the Oxford English Dictionary as having used “entitled” in this sense, the very first meaning of the word listed by the OED. It may be a touch pretentious, but it’s not wrong.

It's part of an excellent website entitled "Common Errors in English" (from BoingBoing)

mdlbear: (hacker glider)

Yesterday's post about backups was close enough to a 1000-word article that I decided to put it on my website in the Linux section , under the title "Keeping Backups".

It's #5 in the "How I Work" series; I note with considerable dismay that the last article was written in November of 2003.

mdlbear: the positively imaginary half of a cubic mandelbrot set (Default)

If you write at home, or if you live with a writer, you need to take a look at today's For Better or For Worse strip.

Most Popular Tags

Syndicate

RSS Atom

Style Credit

Page generated 2019-04-22 02:25 pm
Powered by Dreamwidth Studios