jfred | Recent Entries

I've decided to move back to a personal website, since it's easier for me to update than Dreamwidth posts are which I think will encourage me to blog a little bit more. My new website is here. If you're following this one in your RSS reader and still care to see my posts, update your RSS reader to the new blog!

I'll be migrating the posts from this one piecemeal, so you might see some old posts come through. I'll be marking them with the original old timestamps.

Phone manufacturers have promised convergence for years, but every attempt I've come across in the past has never quite satisfied me:

Android with DeX: Available on fast phones, which is a plus, but Android apps often don't scale well to a desktop interface. (Also requires using a Samsung phone with stock firmware, which requires signing in with a Google account, which I'd like to avoid.)

Ubuntu Touch: Nice interface, generally only available on slower phones thus far (so not many options for convergence), I was never able to get my Yubikey working with it which I need for remote sysadmin work.

That's starting to change with the latest batch of Linux phones. I'm posting this now from a Librem 5 connected to an HP Lap Dock, which so far has been a super fun combo to play with!

What's so special about it?

Since one of the main things I need to be able to do is to SSH to remote systems, and since I use my GPG key via ssh-agent to do so, smartcard support is a must for me. Normally I would just use my Yubikey for this; I carry it everywhere I go for that reason. But the Librem 5 has something interesting that most phones don't: a dedicated smartcard reader! So right off the bat, I loaded my subkeys onto a 3FF smartcard and now can treat the L5 as if my Yubikey were always plugged in.
When plugged into a lapdock, the phone's screen is extended to the lapdock as if the phone were just a small monitor on a typical Linux dual-monitor setup. And, well, that's basically what it is! Phosh/Phoc still have a few bugs that need to be worked out in a docked situation, but nothing that should be catastrophic for most people.
And just as if you were using a Linux laptop, you get all the usual Linux apps you might want! Some of them might not make sense on a phone screen, but they probably do make sense on a lapdock! There's something just incredibly cool about running desktop Linux software on your phone.

Why is it not my daily driver yet?

While the Librem 5 has been a lot of fun to play with, and I think I can be reasonably productive with it, there are both hardware and software needs holding me back from using it as a daily driver.

Battery life: The phone just doesn't last that long on battery, especially if anything happens to be running in the background. I can't get a full day on a single charge, and it takes long enough to charge that realistically I'd have to leave the phone plugged in whenever at my desk to make sure it's charged when I need it My N900 did this impressively well, so I'm hopeful that it'll be possible to extend the Librem 5's battery life significantly, but it's got a long way to go.

MMS: Some of my friends use MMS to communicate via group text. I need this in a phone. This is non-negotiable.

Usable mobile Matrix client with e2e encryption: This is a doozy. Fractal looks nice, but is often too slow on the L5 and doesn't support e2e. Hydrogen is probably the closest, but the best options for running it at the moment are: have Epiphany install the site as an app (at which point you don't get push notifications) or run Hydrogen in Firefox (at which point you have a bunch of browser chrome getting in the way on a small screen). Honestly, an Electron version of Hydrogen with push notifications would help a lot here! I use Matrix to chat with my girlfriend and most of my friends; this is also non-negotiable.

I'm confident that many of these will be fixed in time, and I'm hopeful that I'll be able to comfortably use this device full-time once they are. Until then, I'll be having a lot of fun playing at least!

So the big free software news of the week is that Amazon is forking Elasticsearch after Elastic relicensed Elasticsearch under the SSPL. The internet's in a frenzy about this, as tends to happen these days whenever a large previously free software project goes proprietary. I'm disappointed that the free software world has partly lost yet another useful piece of software, and glad that the project will at least live on in some form as free software, even if not from Elastic.

But let's back up a moment. What is the SSPL, the license that Elasticsearch was just relicensed to? What does it do? Why does everyone consider it a proprietary license? Well, it's largely based on the GPL, with a few additional restrictions that kick in if you're "mak[ing] the functionality of the Program or a modified version available to third parties as a service". Let's take a look at the relevant bits of the license text for a moment:

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

Now, one thing in particular here jumps out at me (emphasis mine):

you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License

Keep in mind that the definition of "service source code" here means:

all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

You might be able to see where I'm going here. To comply with this license while offering the SSPL-licensed program as a service, you must be able to relicense all the software in your stack under the SSPL. It's incredibly unlikely that you're able to do this: if you use Linux for example, it's under the GPL, and while you can do many things with this you can't relicense it under the SSPL.

I'm inclined to interpret this somewhat uncharitably and say that the license was intentionally written to make complying with this clause nearly impossible. However, let's think about a more charitable interpretation for a moment. If we assume that your goal is to ensure that users of your software are always able to make changes to the software they're actually using, distribute those changes, and so on, there are a few license tweaks you could make. Rather than requiring that the program itself and its surrounding enviroment all be distributed under the SSPL, you could be more flexible with the licenses, like so:

“Service Dependencies” mean the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
...
you must make the Service Dependencies available via network download to everyone at no charge, under the terms of this License or, at your option, under any other licenses designated as Free Software by the Free Software Foundation, or as Open Source by the OSI.

I'm not saying this is perfect or that we should start doing this, but it's an interesting line of thought to think about. Most hosting companies certainly wouldn't be able to comply with this, but if you were willing to commit to only using FOSS, it doesn't close the door to it immediately. (If the software were running on Guix, for example, it would likely be pretty easy for me to comply by posting the Guix manifest for my servers along with the Guix revision used.) I think a license modified in this way would be a bit more palatable to the free software community than the SSPL is today, while still preventing large companies from integrating the software into their proprietary offerings.

Even this modified license would not be Open Source. It probably wouldn't be acceptable under the DFSG. It might, however, be Free Software, and that'd be an interesting discussion to have.

I've been putting together a nice little mobile computing setup lately, so thought I'd share it! It hasn't been too useful during the pandemic, but hopefully that'll change when things are back to normal. Whenever that is.

The idea, generally, was that I wanted something I could take with me in a small bag like this one:

The sling bag I use for my mobile computing setup

Bringing something like this with me is much less unwieldy than a full-size backpack.

The main part of my setup is the GPD Micro PC. It's a little handheld computer reminiscent of UMPCs from over a decade ago. I was always fond of tiny PCs, and they're now affordable enough that I bought this thing on a whim a while back.

To go alongside that, I found a thin foldable bluetooth keyboard and a mouse thin enough to not take up much space as well. This is convenient if I have a desk to set up on, but less convenient if I'm on the go. The Micro PC's keyboard is mainly meant for thumb-typing, meaning it's okay for small things but not the best if I'm working on something for an extended period of time. (It was wonderful when I was flashing my router's firmware and needed a direct connection, as my router's somewhat out of the way.)

It's possible that I'll eventually replace this with something that has a more typical keyboard like the GPD Pocket 2, but for now this is what I've got.

In addition to the keyboard/mouse, I've got a super portable USB-C dock in there. It's really meant for the Nintendo Switch, but works with other USB-C devices with DisplayPort more generally.

The electronic devices I pack in my small sling bag

At home I dock this to a more stationary USB-C dock, or if I don't want to be tethered to my desk I'll use the NexDock 2:

This is more cumbersome than it could be, because the Micro PC seems to have a bug that prevents USB-C DisplayPort output from working with some devices, including the NexDock 2. The practical result of that is that I need to use two cables instead of just one, which makes positioning the Micro PC while using the NexDock a bit finicky.

All in all though, all these USB-C devices and peripherals have given me a taste for what future convergent Linux devices could look like; this isn't as portable as a Samsung phone running DeX for example, but it's way more functional for someone like myself who wants a full Linux desktop everywhere I go.

I'm writing this post as part of #100DaysToOffload.

The good

You can't tell people anything: On the difficulty of really conveying something to someone without hands-on experience. I've experienced this from the teacher's side recently when trying to explain Kubernetes concepts to someone who only has experience administering individual, mutable machines. I think I've also recently experienced it from the student's perspective trying to absorb some of the object capability literature. Trying to get some hands-on experience there to avoid that!

Dungeon Scrawl: Looks to be a quick'n'easy way to put together nice-looking dungeon maps for D&D campaigns. I haven't DM'd anything yet, but I plan to at some point.

A Security Kernel Based on the Lambda Calculus: A paper I read recently on a security model based on object capabilities. It's the best introduction to the field I've read so far; highly recommended if you're at all interested in access control, Scheme, etc. (Thanks cwebber for the pointer!)

The ugly

New bill to ban encryption without backdoors: The crypto wars return. Again. Invoking three of the four horsemen of the infocalypse literally by name.

Every so often, I'll have a discussion with a non-free-software person that ends up here:

Me: I think software freedom is important because it allows everyone to modify the software if they need to.

Person 2: But most people won't change their software! They don't know how! Why do they need to be able to?

Obviously, as a free software advocate, I do think it's important for people to be able to change their software. There are plenty of reasons for this that I won't get too deep into: autonomy, trustworthiness, interoperability, etc. These have been covered pretty comprehensively already, and the GNU project's philosophy page is a pretty good place to start.

But, honestly... they also kind of have a point. Most people don't know how to change their software. Most people wouldn't even know how to start. Hell, I have some programming experience myself, and even I find it nontrivial to get started modifying some of the software I use.

I feel like, while software has gotten progressively easier to use, it hasn't gotten that much easier to build, develop, and compose. Take the web browser you're reading this from, for example. If you see something on your screen and you want to find out how it works, how do you even get started? Imagine you've never touched a command line before. What are you supposed to make of this?

It doesn't have to be this way. The early web was much better at this than the web of today; "View Source" was a powerful thing when most sites were handwritten HTML. I personally learned the HTML basics from Neopets, of all places! (And I definitely wasn't the only one.) Now, with minified HTML and JavaScript everywhere? Not so much.

It's not just the web, too; I use Emacs extensively, and one of the best things about it in my opinion is that it exposes its internals in a way most modern software does not. Just about everything in Emacs is introspectable and programmable - you can jump to the source code for any of its functionality in a few keystrokes, and you can overwrite parts of it on the fly and see what it does. In fact, your personal configuration is code in the same language and environment used to write Emacs itself! There's a snippet from a speech on an early Emacs that I think is particularly illuminating:

Multics Emacs proved to be a great success — programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.

There are few such systems in the wild today, though. Most modern software is not like this. But there was so much promise in earlier computing systems! Just look at this demo of the Alto's software!

Watch on YouTube

Or what about the Sugar environment used on the OLPC laptops? That had a "View Source" button for every activity. And something magical happened when they got that into the hands of kids: the kids started programming! About 50% of commits came from the kids themselves! (See this video at around 3:00.)

What's the takeaway here? I think we need to drastically lower the barrier to entry to hacking on programs. The ability to modify free software is an enormous advantage, but we don't lead people to it well enough. It should be a benefit available to everyone. Then, maybe, we'll build a world where everyone is able to and expects to be able to shape their computing environment.

Imagine one of these kids visiting an Apple Store sometime in the future and innocently asking where the “View Source” key is. “Let you view the source? But that’s our property, it belongs to us, you can’t have it.”

I would be remiss if I failed to mention the Malleable Systems Collective, which aspires to exactly this goal. Highly recommend browsing through the site for more examples of systems that provide this level of openness to their users.

I'm writing this post as part of #100DaysToOffload. This is my first post in the series, but I'm hoping I'll be able to make it a habit. Fingers crossed!