This release fills me with great pride and joy. SubEthaEdit always has a special place in my heart. It is where my journey as a developer in the Apple ecosystem started. I owe it the position I am in today. This connection is why I’m taking the time to maintain it again and try to lead it towards a long lasting future. Therefore I think it is worthwhile looking at how everything came together.
The post itself, and this remembrance by Gus Mueller, are both great reads about the formative days of OS X app development.
SubEthaEdit remains very relevant today. It’s a hat in the ring for how to do collaborative text editing. Google Docs is the only successful application in this space and that’s only for rich text, making live collaboration for plain text, e.g., source code and markdown, still an unsolved problem1. SubEthaEdit is a plain text editor designed specifically for this purpose.
SubEthaEdit’s implementation uses Apple’s Bonjour networking technology (also notable that it’s based on an “old Xerox Parc Paper”):
Luckily one of us dug up an old Xerox Parc Paper that showed how latency free live collaboration can be done. At that time it fit perfectly with the newly released Bonjour technology to allow for networking without configuration between Macs. That was super exciting and we quickly got to a point where we could see this technology as viable and so we went on to build our application.
The major problem with SubEthaEdit’s collaborative editing model is that it’s only available while users are connected with each other. It’s not like Google Docs where anyone with the right URL (and access rights) can just start editing the file. Instead one user has to invite other users to start editing, and the session only lasts as long as the original user keeps that file open in SubEthaEdit. It may seem like the Google Docs model is obviously better when compared this way, but it’s really not that straight forward. The Google Docs model is entirely incompatible with version control for example, whereas SubEthaEdit’s model works brilliantly with it. Of course the fact that SubEthaEdit is also a true first-class Mac native app makes it a joy to use.
One of the interesting bits about SubEthaEdit becoming free is that an application like this thrives on the network effect. If you want to edit a file with someone collaboratively, convincing them to use a $40 application is a big hurdle to overcome. I hope this change means SubEthaEdit gets some wider use, I know I’ll be looking for opportunities to use it with my collaborators now.
John Gruber again writing about iOS and iPad as a “pro” platform:
But, I will object to one thing: the iPad feels like a young platform, yes, but it’s not young. It’s over 8 years old. Steve Jobs was still around to introduce it. When the Mac was 8 years old in 1992, System 7 had been launched and it was a very advanced platform, suitable for work of any kind. The new iPad Pro hardware might be the best consumer computer hardware ever made — the only rivals are the iPhone XS and XR. But software-wise, the iPad platform is nowhere near as far along after 8 years as the Mac was a generation ago.
Like many others, I had my stint trying to do more of my work on iOS. For me it was a disaster, I mainly just learned how much I love the Mac as a platform, and that I have an extreme skepticism of whether iOS is even on the path to becoming a pro platform. I stand by my statement that not bootstrapping iOS has put a ceiling on its usefulness. It won’t reach it its full potential as pro platform until the developers at Apple working on improving iOS everyday are doing that work on iOS devices.
In the context of all the conversations about the new iPad Pros replacing Macs, I found these paragraphs from a Daring Fireball article last year very compelling. John Gruber writes:
But put software development aside. I think the bigger problem for the iPad is that there are few productivity tasks, period, where iPad is hardware-constrained. Aldus PageMaker shipped for the Mac in 1985. By 1987 or 1988, it was easy to argue that the Mac was, hands-down, the best platform the world had ever seen for graphic designers and visual artists. By 1991 — seven years after the original Mac — I think it was inarguable. And the improvements in Mac software during those years drove demand for improved hardware. Photoshop, Illustrator, Freehand (R.I.P.), QuarkXpress — those apps pushed the limits of Mac hardware in those days.
That’s just not true for iPad. The iPad is a terrific platform for casual use. I think it’s better than a MacBook for reading and watching video. It’s great for casual gaming. I know plenty of people who much prefer the iPad as a tool for writing. Not because iPad writing apps are more powerful, but rather because they’re simpler, less distracting, and easier to focus upon. None of those are compelling reasons to upgrade an older iPad for a newer more powerful one.
But you don’t need a Mac. You need Xcode on the iPad. That’s all. […]
There’s no particular reason you can’t write and debug code on an iPad, and it’s going to happen. Same for Logic, and Final Cut, and Photoshop, and so on. Oh sure, maybe it won’t be those specific apps (though in a lot of cases, it will be), but tasks themselves are always more interface-agnostic than you think.
I see where he’s coming from, and there’s a part of me that agrees, or at least wants to agree. The architecture of iOS is fundamentally more secure and easier to use than macOS, and I love fantasizing about a future where it’s the only OS I ever need.
But the mistake I think he’s making is equating programming to just another task. For computers, it’s not a task, it’s the task; it’s what makes everything else possible. And you still can’t do it on iOS1. Has any platform ever become a first-class programming platform retroactively? They’re usually designed to be bootstrapped as fast as possible.
I’m increasingly convinced that this process of bootstrapping builds features into the nature of platform, and that these features can’t be retroactively changed or added2. And if that’s true, it means the ship has already sailed on iOS ever being a great programming platform. I really hope Apple proves me wrong on this.
It’s such an obnoxious term, but so perfectly apt I can’t help using it: iOS only allows “toy” programming. ↩︎
Spotlight, LaunchBar 6 and fzf generally have this use case covered for me, but I’m fascinated by the growing trend of performance-orientated applications using Rust for a backend, someotherexamples.
I had a personal realization recently: kottke.org isn’t so much a thing I’m making but a process I’m going through. A journey. A journey towards knowledge, discovery, empathy, connection, and a better way of seeing the world. Along the way, I’ve found myself and all of you. I feel so so so lucky to have had this opportunity.
What I’ve always loved about kottke.org is that more than any other site it makes blogging feel, not like a continuation of other forms writing and publishing, but like a medium all its own.
What Bitcoin actually accomplished is the financialization of a few genuinely joyous ideas. Shrug away the exchange rate, and you have a set of technologies that, for one, allows you to create scarcity. At least of a kind, because you can encode data and information into the blockchain in a way that lets you say, “This is the first one of these particular digital things.” It’s been applied to digital art, and you can see applications for patents, stock photos, things like that. With copies all over the place. […]
People feel compelled to make predictions about blockchains. Here’s mine: The current wave of coins will eventually ebb, because it’s a big, inefficient, unholy mess. It’s more ideology than financial instrument, and ideology is rarely a sustainable store of value. Plus, transactions are slow (everyone says they’re fixing that), and you shouldn’t have to use an aluminum smelter’s worth of power to make new currency.
For what it’s worth I don’t understand the Bitcoin backlash we’re currently in. The creation of a decentralized currency out of computer algorithms seems like a pretty amazing achievement. Whether it ends up having a positive impact, it’s far too early to tell. But technology is the canonical genie you can’t put back in the bottle – its influence will be felt either way.
Great write-up by Stephen M. Deusner for Pitchfork on country music podcast “Cocaine & Rhinestones” just wrapping up its first season:
Early one morning in 1957, country singer Ernest Tubb barged into the lobby of the National Life Building in downtown Nashville, withdrew a revolver from his holster, and shot at a person he thought was Jim Denny. Formerly the gatekeeper at the Grand Ol’ Opry and currently a concert promoter and song publisher, Denny was the guy who fired Hank Williams and told Elvis Presley he had no future in the music business. He was also still asleep in bed, which ended up not mattering anyway: Tubb, who had spent the week binge-drinking, hit only walls. Nevertheless, he was arrested and thrown in the drunk tank, which for him meant buying cigarettes for the cops and playing a few songs at the station.
When we play Minecraft together, the direction of his development, and thus our relationship, is reversed: He converts the world into expressions of his own fantasies and dreams. And by letting me enter and explore those dream worlds with him, I come to understand him in a way that the games from my childhood do not.
Touring the worlds that my son has settled over the last couple of years, I find a lot of the imagery one might expect from a kid his age. Throughout are standard fantasies like living in a treehouse or on a boat. The dominant themes vary as I pass through time: trains in his earliest worlds, then robots, a long streak of pyramids. Pirate ships, particularly half-sunken ones with treasure chests, remain a constant.
It’ll be fascinating to see what kids who have been creating worlds their whole lives do when they grow up.
His trajectory up to that point was a blur of a different hue. From teen sideman to Charlie Parker’s bebop revolution to a solo career that’s better compared to Pablo Picasso than other jazz musicians, Miles instigated entire paradigm shifts in music. Or, as he hissed to a matron at a White House dinner in the 1980s: “I’ve changed music five or six times.” Most narratives point to iconic albums like Birth of the Cool, Relaxin’ With the Miles Davis Quintet, Kind of Blue, Sketches of Spain, Miles Smiles and Bitches Brew, but his 1974 album Get Up With It hangs like an ominous storm cloud over them all, the one that fans of his other works might hesitate to name, his last studio album before he fell mute for the rest of the decade. Like Orpheus grieving in the underworld or Marlow going up the river, Miles went to a place that forever altered his DNA. When he finally returned to the studio, he never sounded the same.
This view is generally expressed only by those who are extremely technically nerdy — i.e. the sort of guys who honestly see Mac OS X as Unix with a Mac GUI, rather than as an updated version of the Mac OS with Unix-like underpinnings.
There’s no better way to put it; that’s what I’m going for on this blog, giving a voice to the ones who see it as Unix with a Mac GUI.
One of the concepts I want to emphasize is the advantage of using small “composable” Unix utilities. To this end, I use rg for all kinds of operations that search or list files. One advantage of this approach is that convenient rules setup in rg, e.g., ignoring .git directories and files in .gitignore, then propagate over every file and search operation I perform.
But something that’s always bothered me is since rgdoesn’t support finding directories (understandably), I lose rg semantics when searching for directories, and instead get decades old find semantics, which don’t do smart things like ignoring things that probably should be ignored.
So I was delighted when I followed the ripgrepGitHub issue to the fzf README to fd. A utility that does exactly what I’m looking for, find directories while replicating the smart take on semantics used by rg (and other modern unixutilities).
Here’s an example of my favorite use of this, replacing the built-in fzfzsh widget’s FZF_ALT_C_COMMAND, which enables a key command to fuzzy filter a directory to cd to recursively.
What the heck is the POSIX shell anyway? Well, the POSIX (the Portable Operating System Interface) shell is the standard Unix shell - standard meaning it was formally defined and shipped in a published standard. This makes shell scripts written for it portable, something no other shell can lay claim to. The POSIX shell is basically a formalized version of the venerable Bourne shell, and on your system it lives at /bin/sh, unless you’re one of the unlucky masses for whom this is a symlink to bash.
If you’re on macOS then unfortunately you’re part of those “unwashed messes” that symlink1/bin/sh to bash. This has some interesting implications, in that even if you use the #!/bin/shshebang in your scripts, they won’t be guaranteed to be portable to other (Unix and Linux) systems. I’ve found a practical solution is to just use the bash shebang, #!/usr/bin/env bash, which will make your scripts portable to any other system running bash.
It appears that technically it’s not a symlink, but in practice in behaves close enough. ↩︎
Xray is an experimental Electron-based text editor informed by what we’ve learned in the four years since the launch of Atom. In the short term, this project is a testbed for rapidly iterating on several radical ideas without risking the stability of Atom. The longer term future of the code in this repository will become clearer after a few months of progress. For now, our primary goal is to iterate rapidly and learn as much as possible.
8ms: Scrolling, animations, and fine-grained interactions such as typing or cursor movement.
50ms: Coarse-grained interactions such as opening a file or initiating a search. If we can’t complete the action within this window, we should show a progress bar.
Contrary to popular belief, we’re not using HTML/CSS for slide rendering, but instead we’re using native macOS views to construct each slide. This allows us to leverage built-in system capabilities like exporting to PDF, native video players, great text rendering and many more.
Avoiding web views: A time-honored tradition of fine apps everywhere.
I got so frustrated by not being able to quickly find web pages in my Safari history that I hacked together a simple command-line interface that lets me search my history with fzf.
It comes in two pieces, a shell script that uses the sqlite3 command-line utility to dump the title and URL of each web page:
read-r-d''select<<EOM
SELECT title, url
FROM history_visits
INNER JOIN history_items
ON history_visits.history_item = history_items.id
ORDER BY visit_time desc
LIMIT 1000;
EOM
sqlite3 -noheader-separator$'\t' ~/Library/Safari/History.db \"$select" 2>/dev/null \
| uniq
And a zsh function that pipes its output through fzf:
