Rubenerd

He tweeted this morning:

I propose the book industry emulate the tremendous success we musicians have seen with streaming. For $10/mo users get access to every book in the world. When someone reads a book, the author receives a third of a cent.

Twitter then proceeded to do what it does best: asking him if he knew what libraries were. I can rattle off a few other obtuse non-sequiturs as well, like carrots, handbags, planets, hamsters, weddings, poets, and Kuala Lumpur. Have you heard of those, too? Actually, scratch that last one, they probably only know Malaysia from a Ben Stiller movie.

I’ve talked here a few times about how streaming services solved piracy for media companies, but not for individual artists, and especially not indie artists. A single CD sale represents tens of thousands of streaming plays, if not more. The power imbalance looks worse than it was in the Napster days, though the media are fine with this because their arses are covered.

These types of services devalue music, and in my experience they make music feel disposable. I think that’s a shame, and not where we should settle.

Keep your streaming service if you want, but be sure to support acts you care about. I buy an album a month with the money I was spending on streaming services instead, and sync them to a dedicated music player that I carry to work like it’s 2005. It’s made music fun again.

It’s time for another installment of Uh Oh!, the series where I highlight attempts by companies to obfuscate negative changes to their services. It’s like Yu-Gi-Oh!, only you lose half your cards each time you draw a holo.

Today is a to-do list service I briefly used a few years ago, with this email:

🚩 Changes to your $SERVICE plan

In the words of Aussie comedian Carl Barron, that dun look good.

We hope you’ve been getting the most out of $SERVICE, whether you’re using it to organize your work tasks, plan a wedding, or keep track of your grocery list (or all three!). Starting today, you’ll be able to do even more on $SERVICE’s Free plan. We’re unlocking a ton of previously-Premium features [..]

Uh oh.

As part of the change, any brand new free account will now be limited to 5 active projects.

And there it is! I was expecting something like syncing being paid-only; this is far worse. People who would use any of those extra features would be the exact ones who’d have more than five projects. I’m sure they know this.

It’s the same playbook every time, isn’t it? Cripple a core part of a service once you’ve locked in sufficient users, then cop the people churning with profits. My thoughts about that misleading business model aside, why do marketing teams think complement sandwiches are an effective announcement strategy, rather than being honest and upfront? It’s so blatant and transparent.

Be wary of such free tools, you’ll always end up paying for them in other ways. I prefer paying for services that are honest from the start.

(Update: An earlier version of this post was titled “More cores is good”, and it remains the permalink. It still makes grammatical sense in context, but it’s awkward. Like me)!

Discussions around Moore’s Law thesedays invariably end with a resigned sigh, and an admission that we’re “only” inking out more performance though pipeline consolidation—such as the Apple M1—and more cores.

Moore cores! Ah that’s good. Still not as good as AMD’s wasted opportunity to brand their binned 3-core CPUs as Tricorders or Tristars back in the day. But I digress.

Appreciate for a moment though that we’ve gone from single and dual core CPUs to ones with six, eight, and more becoming ubiquitous within a decade or so. Our workstations, desktops, and laptops now have more CPU cores than some servers or even supercomputers did in our lifetimes.

In the rush to opine the state of the silicon ceiling and lithographic constraints, the temptation is there to downplay how significant an improvement more cores provide. Humans don’t think like CPUs. We’re scatterbrained. We’re capable of holding and processing multiple thoughts at the same time. This is true even when we attempt mindfulness or meditation, not that I’m bitter or anything. This manifests in how we work, and there’s no question more cores has helped with this.

I love that my laptop here can have a few VMs running, a pkgin update being processed, a browser playing a video, and all the disparate chat apps one needs to conduct business in these times. Throw in my email client, maybe some background rendering, and a weekly deep ZFS scrub, and it starts to feel a bit like magic when you step back and admire all the asynchronous communication and moving parts working together without stepping on each others’ toes.

Each one of these tasks might be encountering the laws of diminishing returns as far as their compute times are concerned, but being able to command six separate little machines with the same input devices, storage, and display is neat. A hex-core CPU isn’t just the sum of its parts; it’s more useful than six separate machines.

Music Monday is a long-running series in which I discuss music on Mondays, surprising though the nomenclature may appear. There’s so much backstory to this song in the Hololive universe, so seeing them do a collab for it made me smile more than I care to admit!

“We are here for you to overcome the difficult times.”

Now I just need them to do James Taylor’s Carolina in my Mind to spur further nostalgia for a place I’ve never been. It’d play so well in Ame’s Café, right? Right?

NetBSD’s pkgsrc package manager is the best thing since sliced bread. Like everything the NetBSD maintainers touch, it’s high quality, well documented, predictable, and portable to a fault. I use it everywhere I can, from my macOS and FreeBSD laptops to remote Linux machines. This has lead people on social networks to ask me why, and to give examples.

The biggest reason comes down to what I call digital hygiene, best described by Merlin Mann as “not storing compost in your vegetable crisper”. There’s value in disambiguating personal tools and applications from what is required to run the system, because updating one set shouldn’t impact the other.

(I’ve had people ask me to quantify more about why I prefer using the BSDs over Linux where I can, and this is one of the reasons. Their architectural decision to include everything required to bootstrap a system in “base” and delegate other software to their respective package managers makes updates easier and less error prone. It comes with other benefits, but that’s for another post).

I use pkgsrc on systems for the same purpose. I use the system package manager to install software I need for my desktop environment on workstations, or services on servers, then let pkgsrc handle tooling that I’ve got more flexibility to break and tinker with. It maintains its own tree in /opt, which means in a pinch I can blow the whole thing away without affecting the rest of the system. This is especially useful on Debian given most Linux distros make no distinction between system and application packages. I even use it on FreeBSD where a dedicated jail for each project might be overkill, or when I want to maintain the exact same versions of tools across my FreeBSD and Mac machines. Did I mention how portable pkgsrc is!?

Speaking of macOS, what about Homebrew? I use it to install graphical applications, but by design it’s no longer possible to easily modify build options. It’s part of a broader trend on the Mac to protect users from themselves and to deliver better experiences, but it gets in the way of my work. MacPorts is far more useful, but I use pkgsrc everywhere else so it made sense to stick with the tools I know.

(My first post about pkgsrc on Mac OS X in 2008 mostly still applies today, but you’re best looking at the official docs).

It’s also simplified my life. I used to maintain multiple package and config managers for every tool I used, but thesedays I delegate it to pkgsrc. Just this morning I updated a new system with some of the essentials I need:

# pkgin install perl ImageMagick p5-PerlMagick p5-DBD-SQLite \
    p5-XML-XPath tex-latex tex-latex-bin tex-standalone

pkgsrc is also a capable package manager for systems that either don’t ship with one, or where you have limited access. I used to run it on Slackware and illumos, and maintained a pkgsrc tree in my home directory on my university’s RHEL system (cough). I need to get back into illumos again; by putting this on the record here I hope it’ll be more difficult for me to shirk this responsibility! It should go without saying that it works well on NetBSD too :).

The pkgsrc website lists the various OSs it supports, and how you can give it a try. Those on macOS, illumos, and CentOS can also use the binary packages generously supplied by Joyent.

Igor Sysoev confirmed this was all that was necessary, at least at the time:

find /path/to/cache -type f -exec rm {}\;

I suppose that makes sense!

I’ve been seeing advertisements on Twitter like this:

Discover $SERVICE, an app that makes it possible to read and listen to the big ideas from the world’s most influential nonfiction books in just 15 minutes.

They then present a table of books you’ll be smashing through during a given month, with the implication that without their service you’d be reading far less.

This qualifies for a you do you! More power to their customers who’s motivation is to read as many books as they can, in as short a time period as possible. But I couldn’t imagine a worse way to read books.

It reminded me of one specific high school English class. Ms Gravina told us of a student of hers who claimed to have read War and Peace and a few Jane Austin books, but didn’t understand half of it. It spawned a discussion on reading comprehension, and whether one is really reading something if they’re only seeing words on a page. I’ve come to love Jane Austin, though I’ll bet I’m still missing some context even now.

Ironically, it was that same class where I admitted to reading fewer than a dozen books a year, which invited surprise and ridicule. I like to lose myself completely in what I’m reading; it’s not unusual for me to reread entire chapters, take notes, draw diagrams, and quote passages in my journal that made me think about something. Non-fiction books lead me to wanting to learn more about a topic, whether it be through podcasts or finding a subject expert who blogs about it. I’m especially fascinated by worldbuilding in fiction books too. This reading style falls afoul of a metric that prioritises breadth over depth.

I read even fewer books today; probably in the range of eight to ten a year. Part of this stems from competing uses of my time, and the volume of blogs I still read via RSS every day. I would like to read more, but for me that will come from adjusting priorities, not speed reading services.

I’ve been reading a lot of optimistic press about the idea of a great post-COVID reset. Our lives won’t return to what they were in 2019, and our lived experiences during this pandemic will usher in a rethink in work obligations, social interactions, and a healtier relationship with technology.

Kaitlyn Tiffany perfectly summarised the prevailing attitudes for The Atlantic yesterday:

As vaccination rates tick up, and IRL social life resumes, it’s getting easier to imagine that we’re on the brink of something big: a coordinated withdrawal from swiping and streaming, a new consensus that staying home to watch Netflix is no longer a chill Friday-night plan, but an affront.

[..] It’s possible that the nightmare of being too online lifted only temporarily, while we were trapped at our computers, and that the tech backlash might resume its prior course once life returns to “normal.” But I can’t help feeling as though the pandemic has forced us to confront—and overcome—some of the fears that animated the urge to drown our phones in 2019.

Australia and New Zealand have largely lived without COVID this year. An American friend living in our apartment complex said that society here offers a glimpse into what the rest of the world can expect when we’re all vaccinated, and the curves trend downwards.

I can report: there was no reset here. For those of us lucky enough not to work in hospitality, we returned to the same offices with the same commutes and the same expectations as before. We’re as wed to our phones and technology. Workaholism is still held in high esteem. We snapped back to our old routines quickly. Mid-2021 is mid-2019, albeit without international holidays outside the Australia–NZ travel bubble.

Part of this perhaps stems from the urge and desire to achieve normalicy again, after a period of uncertainty and fear. There’s comfort in the familiar.

I get where Kaitlyn and other excited journalists are coming from; I was making predictions like this a year ago too. But don’t be at all surprised if the world largely looks the same. That may be a good or a bad thing depending on your view.

I’ve been working on OPML, RSS, and other web feeds for a small project I hope to announce soon! OPML was designed by Dave Winer as a format for his outliner software, but is also widely used for web feed subscription lists.

The OPML 2.0 specification defines the following mandatory attributes:

<outline text="Rubenerd"
    type="rss"
    xmlUrl="https://rubenerd.com/feed/" />

It’s also common to see these optional attributes:

<outline text="Rubenerd"
    title="Rubenerd"
    type="rss"
    version="RSS2"
    language="en-SG"
    xmlUrl="https://rubenerd.com/feed/"
    htmlUrl="https://rubenerd.com/" />

Note type and version, which refer to what the target feed is. This works for RSS feeds, which is the bulk of what I use and publish. But what about Atom and JSON Feed? Almost all OPML files I’ve seen reference type="rss" regardless of the target feed’s format. Here’s a reference to an Atom 1.0 feed in a typical OPML file:

<outline text="Martin Fowler" 
    htmlUrl="http://martinfowler.com" 
    type="rss" 
    xmlUrl="http://martinfowler.com/feed.atom" />

But I’ve seen exceptions. Embarcadero Software references Atom feeds in their OPML files with type="ATOM" and version="1.0" for the version:

<outline title="Technical Articles" 
    htmlUrl="https://edn.embarcadero.com/articles/interbase/3rdpartytools" 
    xmlUrl="https://edn.embarcadero.com/articles/interbase/3rdpartytools/feed" 
    type="ATOM" 
    version="1.0" />

I’ve since learned this isn’t technically correct. The specification defines subscription list elements in OPML as having type="rss". Emphasis added:

A subscription list is a possibly multiple-level list of subscriptions to feeds. Each sub-element of the body of the OPML document is a node of type rss or an outline element that contains nodes of type rss.

So how do we disambiguate between disparate feed formats and versions, if type=rss is used to reference feeds in general? The spec grants some leeway in using the version attribute.

The values [that version] can have are: RSS1 for RSS 1.0; RSS for 0.91, 0.92 or 2.0; scriptingNews for scriptingNews format. There are no known values for Atom feeds, but they certainly could be provided.

I was worried about referring to multiple versions with just RSS, but Dave’s subscriptionList example references it numerically like RSS1 above:

type="rss" version="RSS2"

I’ll be referring to Atom feeds with ATOM1 to keep with this convention.

🌲 🌲 🌲

Which leads to the reasonable question, why include this attribute if it’s optional and loosely-defined? Philosophically, I think it’s a shame that RSS, OPML, and related formats have all this expressive syntax that’s almost never used. It hints at an alternative future of the web where decentralised and distributed writers and applications flourished instead of a few social networks.

Pragmatically though, I’m going to use them in my upcoming project. OPML parsers in the real world have to function assuming those above values are missing, or liberally interpret invalid data. I control the data in my tool, so why not use the data if it’s there?

Happy Friday evening! This is not an exhaustive list, it’s only the first ones that popped into my head like so many corn kernels.

• Bagels
• Doughnuts and cronuts
• Incompletely-filled canolli
• Roll cake
• Calamari, and other squid-based comestibles
• Swiss cheese
• Diced green/spring onions
• Bread, with inclusions
• Penne pasta
• Funnel cake
• Kürtőskalács (I cheated and looked up the spelling)
• Onion rings
• Half-baked analogies

These are a sampling of foods that don’t have holes, for the sake of completeness and comparison:

• Short soup
• Knödel
• Charcuterie boards, whatever they are