matduggan.com

Podman Desktop is here and it works great. When Docker changed their license to the following, it was widely understood that its time as the default local developer tool was coming to an end.

Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.

Podman, already in many respects the superior product, didn't initially have a one to one replacement for Docker Desktop, the commonly used local development engine. However now it does and it works amazingly well. Works with your existing Dockerfiles, has all the Kubernetes functionality and even allows you to use multiple container engines (like Docker) at the same time.

I'm shocked how good it is for a not 1.0 release, but for anyone out there installing Docker Desktop at work, stop and use this instead. Download it here.

With the release of iOS 16 and MacOS Ventura, we are now in the age of passkeys. This is happening through WebAuthn, a specification written by the W3C and FIDO with the involvement of all of the major vendors such as Google, Mozilla, etc. The basic premise is familiar to anyone who has used SSH in their career: you login through the distribution of public keys, keeping the private key on the device.

Like all security initiatives, someone took the problem of "users sometimes reuse passwords" and decided the correct solution is to involve biometric security when I log into my coffee shop website to put my order in. I disagree with the basic premise of the standard on a personal level. I think it probably would have been fine to implement an API where the service simply requested a random password and then stored it in the existing browser password sync. It would have solved the first problem of password reuse, allowed for export and didn't require a total change in how all authentication works. However I am not the kind of person who writes these whitepapers full of math so I defer to the experts.

How WebAuthn works is the server receives from the user a public key and randomly generated ID. This private key is distributed and stored in the client vendor sync process, meaning it is available to different devices as long as those devices exist within the same vendor ecosystem. This stuck out to me as a fascinating transition for passwords and one with long-term implications for user retention across the different platforms.

Imagine being Apple or Google and getting to tell users "if you abandon this platform, you are going to lose every login you have". This is a tremendous threat and since all platforms will effectively be able to share it at the same time, not a legal threat. Let's get into the details of what WebAuthn is and how it works, then walk through how this provides tremendous value to platform holders as a way of locking in users.

WebAuthn Properties

WebAuthn is a web-based API that allows web servers, called Relying Parties to communicate with authenticators on a users device. I'll refer to these as RPs from now on. To get started, the wserver creates new credentials by calling navigator.credentials.create() on the client.

const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions
});

This object has a number of properties.

• challenge: a buffer of random bytes generated by the server to prevent replay attacks.
• rp: basically the website, needs to be a subset of the domain currently in the browser.
• user: information about the user. Suggested not to use PII data but even if you use name and displayName it doesn't appear that this is ever relayed to the rp source
• pubKeyCredParams: what public keys are acceptable to the server
• authenticatorSelection: do you want anything to be allowed to be an authenticator or do you want a cross-platform authenticator like only a YubiKey
• timeout: self-documenting
• attestation: information from the authenticator that could be used to track users.

Attestation

What you are getting back as the service is the attestation statement, which is a somewhat vague concept. It's a signed data object that includes info about the public key and some other pieces of information. You can see the generic object below

This part is kind of interesting. There are actually 4 tiers of "information you get back about the user".

• none: You don't want anything and is the default
• indirect: the client is allowed how to obtain such a statement. The client may replace an authenticator-generated statement with one generated with an Anonymization CA.
• direct: you want the statement
• enterprise: you want the statement that may include uniquely identifying information. The authenticator needs to be configured to say "this rp ID is allowed to request this information", so presumably this will be for devices enrolled in some sort of MDM.

You get back an attestationObject at the end of all of this which basically allows you to parse metadata about the registration event as well as the public key, along with the fmt of the attestation which is effectively the type of authenticator you used. Finally you have the statement itself.

When a user wants to sign in, the process works pretty simply. We call navigator.credentials.get() on the client, which basically says go get me the credentials I specify in allowCredentials. You can say what the ID is and how to get the credentials (through usb, bluetooth, nfc, etc).

For further code samples and a great walkthrough I recommend: https://webauthn.guide/

The key to how this all works is that the private key is synced by the vendor to the different devices (allowing for portability) but also allows for phone delegation. So for instance if you are a Windows Chrome user and want to sign in using passkeys, you can, as long as you still have the Apple device that you originally created the passkey on.

Passkey cross-device flow

1. The vendor supplies a "Passkey from nearby devices" option when the user is logging in
2. The web site displays a QR code
3. The device which contains the passkey points its camera and starts an auth flow
4. The two devices perform a Bluetooth handshake to ensure they are actually near each others and agree on a server to use as an exchange post
5. The device with the passkey is used to perform the actual auth process.
6. Now in theory the service should offer some sort of "would you like to make a new passkey on this device".

At no point did you transfer the private key anywhere. That entire sync process is controlled by the vendor, meaning your option for portable authentication is going to be a roaming authentiator (aka a YubiKey).

It's important to note here that a lot of assumptions have been made about developers around the requirement of local storage of private keys. This isn't necessarily the case. Authenticators have the option of not storing their private keys locally at all. You have the option of instead storing the private keys with the rp, encrypted under a symmetric key held by the authenticator. This elasticity to the spec comes up a lot, with many decisions deferred to the vendors.

Why Does This Matter?

WebAuthn has taken a strong "decentralized" design philosophy, which makes sense until you realize that the inability to export private keys isn't....really true. Basically by submitting an attestation, the vendor is saying "these devices private keys cannot be stolen". You can see the initial conversation on GitHub here. It's making the problem someone else's issue.

By saying, in essence, portability of private keys is not a concern of the spec and leaving it entirely in the hands of vendors, we have created one of the greatest opportunities for user lock-in in recent history. It is now on the individual services and the vendors to allow for users to seamlessly sign in using different devices. The degree by which platform owners want to allow these devices to work with each other is entirely within their own control.

We can see that vendors understand this to some extent. Apple has announced that once passkey is supported in the OS, device-bound keys will no longer be supported. You will not have the option of not using iCloud (or Chrome Sync services). Administrators will likely not love the idea of critical keys being synced to devices possibly beyond their control (although the enterprise attestation provides some protection against this). So already in these early days we see a lot of work being done to ensure a good user experience but at the cost of increased vendor buy-in.

Scenario

You are a non-technical user, who used their iPhone in the normal way. When presented with a login you let the default of "use passkeys" ride, without doing anything special. You lose your phone, but don't own any other Apple products. By default iCloud Keychain only works on iOS, iPadOS and macOS. In order to seamlessly log into any service that you registered through your phone with passkeys, you have to purchase another Apple product.

If you attempt to switch to Android, while it supports passkeys, it is between you and the RP on how controlling access to your original account will work. Since allowing users to reset their passkeys through requesting a passkey reset through an email link eliminates a lot of the value of said service, I'm not exactly sure how this is going to be handled. Presumably there will need to be some other out-of-band login.

Also remember that from the RPs side, what you are getting is almost no information about the user. You aren't even (confidently) getting what kind of authenticator. This is great from a GDPR perspective, not having to hold email addresses and names and all sorts of other PII in your database (and does greatly eliminate many of the security concerns around databases). However if I am a web developer who goes "all-in" with this platform, it's hard to see how at some point I'm not going to fall back to "email this user a link to perform some action" and require the email address for account registration.

On the RP side they'll need to: verify this is the right user (hopefully they got some other ID in the registration flow), remove the passphrase and then have the user enroll again. This isn't a terrible flow, but is quite a bit more complicated than the story today of: log in again through SSO or by resetting a password by sending a reset link to email.

What about Chrome?

Chrome supports the standard, but not in a cross-platform way.

Passkeys are synchronized across devices that are part of the same ecosystem. For example, if a user creates a passkey on Android, it is available on all Android devices as long as the user is signed in to the same Google account. However, the same passkey is not available on iOS, macOS or Windows, even if you are using the same browser, like Chrome.

Ultimately it is the hardware you are generating the key on that matters for vendor syncing, not the browser or OS.

The result of this is going to be pretty basic: as years go on, the inertia required to switch platforms will increase as more services are added as passkeys. There exists no way currently that I'm able to find that would allow you to either: add a secondary device to the exchange process or to bulk transfer out of Vendor A and into Vendor B. Instead any user who wants to switch services will need to go through the process of re-enrolling in each services with a new user ID, presumably hoping that email was captured as part of the sign-up flow so that the website or app can tie the two values together.

There is a proposed spec that would allow for dual enrollment, but only from the start. Meaning you would need to have your iOS authenticator, then attach your Chromebook authenticator to it from the start. There is no way to go back through and re-sync all logins with the new device and you would need constant access to both devices to complete the gesture element of the auth.

Yubico proposal

You can read that proposal here.

Yubico has an interesting idea here based on ARKG or Asynchronous Remote Key Generation. The basic idea is that you have a primary authenticator and a secondary authenticator that has no data transfer between the two. The proposed flow looks as follows

• Backup device generators a private-public key pair and transfers the public key to the primary authenticator
• This is used by the primary authenticator to derive new public keys on behalf of the backup device
• Then the primary generates a new pair for each backup device registered and sends this on to the RP along with its primary key.
• If the primary disappears, the backup device can request the cred from the RP and use it to derive the key used. In order to retrieve the cred associated with a user, there needs to be some sort of identifier outside of the user ID in the spec which is a random value not surfaced to the user.

For more math information on the spec itself check this paper out.

ARKG functionality. ARKG allows arbitrary public keys pk′ to
be derived from an original pk, with corresponding sk′ being cal-
culated at a later time—requiring private key sk for the key pair
(sk, pk) and credential cred.
Definition 3.1 (ARKG). The remote key generation and recovery
scheme ARKG B (Setup, KGen, DerivePK, DeriveSK, Check) con-
sists of the following algorithms:
• Setup(1𝜆 ) generates and outputs public parameters pp =
((G, 𝑔, 𝑞), MAC, KDF1, KDF2) of the scheme for the security
parameter 𝜆 ∈ N.
• KGen(pp), on input pp, computes and returns a private-
public key pair (sk, pk).
• DerivePK(pp, pk, aux) probabilistically returns a new public
key pk′ together with the link cred between pk and pk′, for
the inputs pp, pk and auxiliary data aux. The input aux is
always required but may be empty.
• DeriveSK(pp, sk, cred), computes and outputs either the new
private key sk′, corresponding to the public key pk′ using
cred, or ⊥ on error.
• Check(pp, sk′, pk′), on input (sk′, pk′), returns 1 if (sk′, pk′)
forms a valid private-public key pair, where sk′ is the cor-
responding private key to public key pk′, otherwise 0.
Correctness. An ARKG scheme is correct if, ∀𝜆 ∈ N, pp ←
Setup(1𝜆 ), the probability Pr [Check(pp, sk′, pk′) = 1] = 1 if
(sk, pk) ← KGen(pp);
(pk′, cred) ← DerivePK(pp, pk, ·);
sk′ ← DeriveSK(pp, sk, cred).

Challenges

The WebAuthn presents a massive leap forward for security. There's no disputing that. Not only does it greatly reduce the amount of personal information flowing around the auth flow, it also breaks the reliance on email address or phone numbers as sources of truth. The back-bone of the protocol is a well-understand handshake process used for years and extremely well-vetted.

However the spec still has a lot of usability challenges that need to be addressed especially as adoption speeds up.

Here are the ones I see in no particular order:

• Users and administrators will need to understand and accept that credentials are backed up and synced across unknown devices employing varying levels of biometric security.
• Core to the concept of WebAuthn is the idea of unlinkability. That means different keys must be used for every new account at the RP. Transferring or combining accounts is a problem for the RP which will require some planning on the part of service providers.
• In order to use this feature, services like iCloud Sync will be turned on and the security of that vendor account is now the primary security of the entire collection of passwords. This is great for consumers, less great for other systems.
• There currently exists no concept of delegation. Imagine I need to provide you with some subset of access which I can delegate, grant and revoke permissions, etc. There is an interesting paper on the idea of delegation which you can find here.
• Consumers should be aware of the level of platform buy-in they're committing to. Users acclimated to Chromebooks and Chrome on Windows being mostly interchangeable should be made aware that this login is now tied to a class of hardware.
• We need some sort of "vendor exchange" process. This will be a challenge since part of the spec is that you are including information about the authenticator (if the RP asks for it). So there's no reason to think a service which generated an account for you based on one type of authenticator will accept another one. Presumably since the default is no information on this, a sync would mostly work across different vendors.
• The vendor sync needs to extend outside of OEMs. If I use iCloud passkeys for years and then enroll in 1Password, there's no reason why I shouldn't be able to  move everything to that platform. I understand not allowing them to be exposed to users (although I have some platform ownership questions there like 'isn't it my passkey'), but some sort of certified exchange is a requirement and one that should have been taken care of before the standard was launched.

Conclusion

This is a giant leap forward in security for average users. It is also, as currently implemented, one of the most effective platform lock-ins I've ever seen. Forget the "green text" vs "blue text", as years go on and users rely more and more on passkeys for logins (which they should), switching platforms entirely will go from "a few days of work" to potentially needing to reach out and attempt to undo every single one of these logins and re-enroll. For folks who keep their original devices or a device in the ecosystem, this is mostly time consuming.

For users who don't, which will be a non-trivial percentage (why would a non-technical user keep their iphone around and not sell it if they have a brand new android), this is going to be an immense time commitment. This all assumes a high degree of usage of this standard, but I have trouble imagining web developers won't want to use this. It is simple a better more secure system that shifts a lot of the security burden off of them.

I have always liked text editors. There is something promising about them, a blank canvas that you can quickly mess up with your random commented out lines. I went from BBEdit, my favorite Mac app of all time (seriously I love this app so much I bought a tshirt with their logo on it which you can get here) to Vim. I still use BBEdit all the time, mostly as a clipboard style storage location, notes or just outlining tasks. Vim + tmux has been my go-to now for 5+ years.

Now I know this is a contentious topic. If you like using a full IDE (Integrated Development Environment) know that I am not coming for you. It's not my preference but it is entirely valid and right. People interested in an ideological fight over this issue should remember you are asking people to spend 8 hours a day using this thing. There isn't a right or wrong answer to "what tool should you be using", it's more like picking a chair or a mattress. That said, I'm not qualified to really speak on what is the best IDE (although according to people I work with its VS Code with plugins by a mile).

However with the rise of Rust there has been an explosion of new entries into the text editor space, with a lot of cool and novel ideas. I thought it would be fun to download some and try them out for a few hours each to get some actual work done. These won't be incredibly detailed reviews, but if there is interest I'm more than happy to go back and do a deeper dive into any individual one.

Should I use any of these to pay my bills?

That's up to you, but I will outline a few common recommendations below that I've used extensively for mission critical work along with why I like them. If you are just here looking for what should be your daily workhorse, it would be safer to pick from those. However a lot of the projects I'll discuss later are certainly safe to use, just might not have all the bells and whistles.

Here are some of the tools I've used for at least a few months in a row as my most-used applications along with any tips or add-ons I liked.

If you are ok with a learning curve

• Vim. I understand Neovim is better, I still use standard Vim. I have not encountered any issues in 5+ years of daily use that would prompt me to change. However if you are just starting go with Neovim. At some point I'm sure I'll find some issue that causes me to switch.  
  
  Vim plugins: My former coworkers at Braintree maintain the best Vim dotfiles that I have used at every job since which you can grab here.
  
  Tutorial: I learned with Vim Golf which was actually pretty fun, but I've also heard a lot of good things about Vimified. Either should be fine, also Vim has a built-in tutorial which is more than enough to get you started. If you install Vim from Homebrew or from a linux package, just run vimtutor in your terminal, go through it and you'll have what you need to get started.
  
• Tmux. You typically want to leave Vim running in something like Tmux just so you can keep multiple things running at the same time and switch between them. My workflow looks something like: a dev box I am SSH'd into, Vim open and then maybe docs or a man page. I use this for my Tmux config.

You just need something right now

• On Mac I recommend BBEdit. You can use most of the features for free forever, it is made by some of the best Mac developers in the world and I've never ever lost a file that I've been working on in BBEdit. Seriously, I've written 50 page papers on BBEdit with 100% confidence.
• Windows: no idea. Good luck out there kiddo. I remember Notepad++ from college. Presumably there is something better. I'm sure VS Code works great on Windows.
• Linux I've always used Sublime Text for a fast GUI text editor. The plugin ecosystem is good. Here are some I always install:
  1. Package Control since nothing else works without it.
  2. Terminal since opening a terminal from Sublime Text needs to happen all the time.
  3. Sublime Linter
  4. Linters for your language of choice.

What about Emacs?

I don't really know it well enough to speak to it. I'm open to running through a tutorial but I just never worked at a place where its use was widespread enough to justify sitting down and learning it. If there's a good tutorial though hit me up on Twitter and I'm glad to run through it. Link

I'm here for the new stuff, not this Lifehacker 2011 list.

Look sometimes people stumble on these posts who shouldn't be reading the dribble I write and send me comments on Twitter. Disclaimer over, from here on we're here for the new and the weird.

Amp

Amp is a text editor with a focus on "batteries included". You open it with: amp [dir | file1 file2 ...] after installing it. First day using it, the big value is a great  file finder. Hit space after opening it, Amp indexes all the files in the path and allows you to very quickly search among them.

What takes a second to get used to is that this isn't a fuzzy file finder. Instead of typing full words, use parts of the path , separated by spaces. Here's what it looks like in practice:

This takes a second to get used to, but very quickly I felt like I was searching with more accuracy than ever. Weirdly by default this didn't visually scale, so even if there were more results I didn't see them. You can change this in the config file documented here. I feel like 5 results is kind of crazy low as a default

Typical text movement is , and m keys for scroll up and down. Movement is the  h,j,k,l  commands are there, along with w,b for word. Most of your interactions though will be through the jump mode, which is weird as hell.

What it seems to be doing is going through your file and changing the beginning of the word to be a two letter code that is unique. So you can very quickly jump to words. Now this would make sense if it prefixed the words with the characters, but on my installation it replaced the first two characters. This makes files pretty much impossible to work on.

Unfortunately, even though I really enjoyed the file search, this was the end of my experiment with Amp. It isn't clear whether the tool is still being updated and since so much of the mobility relies on Jump, this messing up the first two characters of every word makes my workflow impossible. I didn't see anything obviously wrong in my installation and I did install from source so I'm not sure what else could be done on my end to resolve this.

I'm really disappointed. I liked what I saw of Amp and I feel like there are some good ideas there. I love the focus on file management and searching. I'll keep an eye on the repo and revisit this if something new comes up.

Survived: .5 hours of my production work

Helix

Helix is maybe the first Rust application I've used where I had to look and see "wait this isn't Node right?" In case you think I'm being ridiculous:

However upon starting Helix you instantly see why it's including every Rust crate. This is a robust text editor, aimed squarely at the Vims/Emacs of the world. The basic concept is one of multiple cursors, so you are attempting to remove one of the steps from Vim. Overall the goal is a batteries included text editor that handles syntax in a slightly different way.

Syntax Tree

One feature touted in Helix is an integration with Tree-sitter. The idea is to get a more concurrent representation of the structure of your code. You've seen this before, but it's not in Vim and is still an experimental feature in Neovim. It includes built-in support for a lot of languages and in my testing works well, allowing you to search through the tree and not just search text. Basically you can now select nodes vs raw text.

Language Server

Similar to Neovim (and available on Vim 8 through a plugin), there is language server support. I typically lump this more into IDE features but it is a nice touch, especially for folks who have gotten used to it. I found myself using it quite a bit, which is unusual since I don't have it installed in my Vim setup. It turns out I might have been wrong about language servers all these years. You can see the languages supported here.

Enough of the features, how does it work?

I walked into using Helix expecting not to like it. I was completely wrong. Everything about it is a complete delight to use in a way that is so effortless that I wondered in the back of my mind "have I actually used this product before and forgotten?" You start it with hx on the command line and access all commands with :. On first startup, I was already up and running, editing work files quickly.

Minute to minute it does feel a lot like Vim, which for me is a huge perk but might not be for you. The basic flow is reversed though, so instead of action -> object it's object -> action. To delete a word in Vim is dw, delete word. In Helix it is wd. There is a fair amount of muscle memory for me around this, so it isn't an instant change. However the payoff is pretty massive.

Multiple Cursors

You can obviously manipulate text on a global scale with Vim. Search for a word then edit the second selection with cgn. You can then iterate through the text with the . tool. For more complex situations you can run macros over the entire file. While this functionality exists, Helix with the multiple cursors makes it easier to pick up on. Go to the beginning of the text, hit the %, then s and you have multiple cursors to manipulate text.

Trying to help all the time

Hitting g in a file brings up all the goto commands, which is really nice when you are starting.

You'll also notice the language server commands called out here with d. This allows you to jump to the definition as determined by LSP. By default this didn't work with Terraform, but it provided a good chance to try out adding one. There was a slight issue with hcl not being included in the GitHub list of supported languages but it was on the list of languages in their docs. GitHub link here.

Anyway it looks like it uses the standard Terraform language server, so nbd. For some reason the language docs don't link to the language server they mean, but I'm glad to go through and make a PR for that later. We install the Terraform language server, run :config-open and write out a new language entry. Except maybe we don't need to?

Here is where it gets a little bit confusing. My initial read of the documentation here suggested that I need to write a new config to get the language server to work. However that actually isn't the case. I just happened to run hx --health and bam, Terraform is set up. I confirmed yes it does in fact just work with the default config. The Helix team explains I don't need to do anything here but I must have missed it.

Anyway, if its on the list just install the language server and then confirm with hx --health that it has picked it up.

In terms of theme I actually like the purple, but that's extremely customizable. Find those docs here. However they also include most of the normal terminal themes in the box, meaning you can try out whatever moves you with :themes. Here's the ones that come with it:

Just type what you want and the theme instantly switches:

Large Files

Sometimes I'm a bad Vim user. I will admit that I, from time to time, will open giant log files and attempt to search them in Vim vs doing that I should do and use a tool for searching large bodies of txt. Typically Vim will chug while doing this, which is totally understandable, but I was curious how will Helix hold up.

Sample file is: 207M Sep  4 21:19 giant_file.txt and opening it in Vim does cause noticeable slow-downs. Helix opens instantly, like zero visible change to me from a tiny file. Making an even larger file, 879M Sep  4 21:22 huge_file.txt, I decide to test again. BEFORE YOU PING ME ON TWITTER: I know this is because I have a lot of plugins. Helix also comes with a lot of stuff, so I don't consider this to be that insane of a test. Don't agree? Run your own tests.

With the 800M file Vim absolutely chugs, taking forever to show the first line of text. Helix is once again instant. Everything works really quickly and if I didn't know the file was huge, it wouldn't occur to me. I'm super impressed.

Survived: 20 hours of my production work but really could be endless

I didn't walk into this expecting to find a Vim replacement for me, but Helix is really compelling. It's fast, the extension-first mentality shines since the editor comes ready to get to work, everything is really discoverable in a way that just isn't true with Vim. An expert might know how to do everything Helix does in Vim, but there's no way a new user would be able to find out that information as easily in Vim as you can in Helix.

Progress on the editor is steady and impressive, but even in the current state I didn't find a lot to dislike. Performance was extremely stable testing on MacOS Intel and M1 along with Linux ARM and x86. If you are interested in the terminal editor life but want something with a lot more of the modern features built in, Helix is a world class product. The team behind it should be super proud.

If there is interest I would be happy to do a longer in-depth thing about Helix. Just let me know on Twitter.

Kibi

How much text editor can you get into less than 1024 lines of code? More than you might think! Kibi is an interesting project, inspired by kilo. It's a pretty basic text editor, but with some nice features. Think of it more like nano as compared to Helix. It aspires to do a bit less but really exceeds in what it sets out to do.

Most of the main functionality is visible on the page, but you can set syntax highlighting manually by following the steps here. It is unfortunately missing a few features I would love, things like displaying the tree of a directory if you pass it a directory. Instead passing it a directory throws an IO error, which is understandable.

If you are just starting out and looking for a simple text editor, really easy to recommend this one. For people especially who work with one type of file a lot, it's very simple to add syntax highlighting. My hope would be at some point a community collection of common syntax highlighting is added along with some file path support. Unfortunately without those things, there isn't that much for me to test.

Some of the shortcuts didn't work for me either. CTRL-D duplicated but CTRL-R didn't seem to remove the line. The one feature I REALLY liked was CTRL-E, which allows you to execute a shell command and then inputs the value into the line with the cursor. This is really great for a lot of sysadmin tasks where you are switching between tmux panes, putting the output of a command into the file.

This little tool would really get to the next level with just a few adjustments. Maybe add CTRL+arrow keys for jumping to the next word, some common highlighting options. However it's not bad for a nano replacement, which is pretty high praise considering the legacy of that app.

Survived: 1 hour of my production work but not a totally fair comparison

Lapce

Now before you get into it with me, this is a BIT of a stretch. However because it supports modal editing I'm going to consider it. I was mostly curious what does a GUI Rust app look like in a text editor.

My first impression was....mixed.

I like the terminal at the bottom, but there didn't seem to be window resizing and it didn't support terraform (which is fine). However most baffling was after I selected this directory as my project I couldn't figure out how to get out of it. I know that's ironic as a Vim user complaining that I couldn't escape a project but I was a little baffled. Where is the file explorer?

It's actually the file name drop-down centered at the top that is where you can navigate to other projects. You use : and you can access all sorts of commands within the editor.

This would be one of the many UI things I ran into which I thought was unusual. The app doesn't follow most of the MacOS conventions, a strange choice I see a lot with new desktop applications using Rust frameworks. Settings isn't where it should be, under the App name -> Preferences.

Instead it is under a gear icon in the top right corner.

Settings has everything you need but again not very MacOS, not really following normal layout. It's all here though.

Once I opened a codebase that the editor supported, it seemed to work fine. To be honest it's roughly the same experience as whenever I open an IDE. This one feels very snappy and I think there's a lot of good promise here, but it doesn't feel particulally Vim-like.

The primary value of Lapce, from what I could tell, is that it has a great SSH integration, just click the Blue cloud icon and enter the ssh path of username@hostname and it worked great. It also does really well with big projects, lots of text, not slowing down when processing them. However since I don't really work in big codebases like that, the SSH integration is nice but I'm not really able to put it through its paces.

However if you do work with a lot of big files and find other IDEs sluggish, it's probably worth trying. Once you get a handle on the UI it all works pretty well.

Survived: 8 hours

I think if I was more of an IDE person and willing to put in the time Lapce could work fine for my workflow. I just didn't see anything that really spoke to me that would justify the time invested.

Conclusion

It's really an exciting time to be a programmer for a lot of reasons. We have more mechanical keyboards, more monitors and more text editors. But in all seriousness I love that people are out there making this stuff and I think all of them should be proud. It's really exciting to be able to offer people new options in this space instead of repeating the five or so dominant platforms.

If you are looking for something new to try right now, Helix is really impressive and I think hard to beat.

I strongly encourage people to download these, try them out, or PLEASE let me know if there is a good one I missed. I'm more than happy to do a review of another text editor at pretty much any time. You can find me on Twitter.

Once again I asked, “Father, I want to know what a dying person feels when no one will speak with him, nor be open enough to permit him to speak, about his dying.”
The old man was quiet, and we sat without speaking for nearly an hour. Since he did not bid me leave, I remained. Although I was content, I feared he would not share his wisdom, but he finally spoke. The words came slowly.
“My son, it is the horse on the dining-room table. It is a horse that visits every house and sits on every dining-room table—the tables of the rich and of the poor, of the simple and of the wise. This horse just sits there, but its presence makes you wish to leave without speaking of it. If you leave, you will always fear the presence of the horse. When it sits on your table, you will wish to speak of it, but you may not be able to.

The Dog

I knew when we walked into this room that they didn't have any good news for me. There's a look people have when they are about to give you bad news and this line of vets staring at me had it. We were at Copenhagen University Animal Hospital, the best veterinary clinic in Denmark. I had brought Pixel, my corgi here, after a long series of unlikely events had each ended with the worst possible scenario. It started with a black lump on his skin.

We had moved Pixel from Chicago to Denmark, a process that involved a lot of trips to the vet, so when the lump appeared we noticed quickly. A trip to our local vet reassured us though, who took a look, prescribed antibiotics and told us to take him home and keep it clear. It didn't take long for us to realize something worse was happening. He kept scratching the thing open, dripping blood all over the house. My wife and I would wrestle with him in the bathroom every night after we put our newborn baby to bed, trying to clean the wound with the angled squirt bottle we had purchased to help my wife heal after childbirth. He ended up bandaged up and limping around, blood slowly seeping through the bandages.

After a few days the wound started to smell and we insisted the vet take another look. She glanced at it, proclaimed it was extremely seriously and had us to go to the next tier of care. They took care of the lump but told me "we are sure it is cancer" after taking a look at a sample of what they removed. I did some research and was convinced that, yes while it might be cancer, the chances of it being dangerous were slim. It wasn't uncommon for dogs to develop these lumps and since it had been cleanly removed with good margins, we had a decent chance.

Except we didn't. This nice woman, the professor of animal oncology looked at me while Pixel wandered around the room glancing suspiciously at the vet students. I marveled how calm they seemed as she delivered the news. He wasn't going to get better. She didn't know how much time I had. It wasn't going to be a long time. "Think months, not years" she said trying to reassure me that I at least had some time.

For a month after I was in a fog, just trying to cope with the impending loss of my friend. This vision I had that my daughter would know this dog and get to experience him was fading, replacing with the sad reality of a stainless steel table and watching a dog breath his last breath, transforming into a fur rug before your eyes. It was something I had no illusions about, having just done it with our cat who was ill.

Certainly, this would be the worst of it. My best friend, this animal that had come with me from Chicago to Denmark and kept me company alone for the first month of my time in the country. This dog who I had purchased in a McDonald's parking lot from a woman who assured me he "loved cocktail wieners and Law and Order", this loss would be enough. I could survive this and recover.

I was wrong though. This was just the beginning of the suffering.

Over the next three months I would be hit with a series of blows unlike anything I've ever experienced. In fast succession I would lose all but one of my grandparents, my brother would admit he suffered from a serious addiction to a dangerous drug and my mother would get diagnosed with a hard-to-treat cancer. You can feel your world shrink as you endlessly play out the worst case scenario time after time.

I found myself afraid to answer the phone, worried that this call would be the one that gave me the final piece of bad news. At the same time, I became desperate for distractions. Anything I could throw myself into, be it reading or writing or playing old PS1 videogames and losing over and over. Finally I hit on something that worked and I wanted to share with the rest of you.

Programming is something that distracted me in a way that nothing else did. It is difficult enough to require your entire focus yet rewarding enough that you still get the small bursts of "well at least I got something done". I'll talk about what I ended up making and what I'm working on, some trial and error I went through and some ideas for folks desperate for something, anything, to distract them from the horrors.

Since this is me, the first thing I did was do a ton of research. I don't know why this is always my go-to but here we are. You read the blog of an obsessive, this is what you get.

What is Grief?

At a basic level, grief is simply the term that indicates one's reactions to loss. When one suffers a large loss, you experience grief. More specifically grief refers to the heavy toll that weighs on the bereaved. We often discuss it in the context of emotions, the outpouring of feelings that is the most pronounced sign of grief.

In popular culture grief is often presented as 5 stages which include denial, anger, bargaining, depression and acceptance. These are often portrayed as linear, with each person passing through one to get to the other. More modern literature presents a different model. Worden suggested in 2002 that we think of grief as being a collection of tasks, rather than stages. The tasks are as follows:

1. Accept the reality of the loss
2. Work through the pain of grief
3. Adjust to an environment in which the deceased is missing
4. To emotionally relocate the deceased and move on with life.

One thing we don't discuss a lot with grief is the oscillation between two different sets of coping mechanisms. This is something Stroebe and Schut (1999) discussed at length, that there is a loss oriented coping mechanism and a restoration oriented coping mechanism for loss.

What this suggests is that, contrary to some discourse on the topic, you should anticipate needing to switch between two different mental modes. There needs to be part of you that is anticipating the issues you are going to face, getting ready to be useful for the people you care about who are suffering.

Aren't these people still alive?

Yes, so why am I so mentally consumed with thinking about this? Well it turns out there is a term for this called "anticipatory grief". First introduced by Lindemann (1944), it's been a topic in the academic writings around grief ever since. At a basic level it is just grief that happens before but in relation to impending death. It is also sometimes referred to as "anticipatory mourning".

One thing that became clear talking to people who have been through loss and death and experienced similar feelings of obsession over the loss before it happened is it doesn't take the place of actual grieving and mourning. This shook me to my core. I was going to obsess over this for years and it was going to happen, then I was going to still go through the same process.

The other thing that made me nervous was how many people reported chronic grief reactions. These are the normal stages of grief, only they are prolonged in duration and do not lead to a reasonable outcome. You get stuck in the grieving process. This is common enough that it is being proposed as a new DSM category of Attachment Disorders. For those that are curious, here are the criteria:

• Criterion A. Chronic and disruptive yearning, pining, and longing for the deceased
• Criteria B. The person must have four of the following eight remaining symptoms at least several times a day or to a degree intense enough to be distressing and disruptive:

1. Trouble accepting the death
2. Inability to trust others
3. Excessive bitterness or anger related to the death
4. Uneasiness about moving on
5. Numbness/detachment
6. Feeling life is empty or meaningless without the deceased
7. Envisioning a bleak future
8. Feeling agitated

• Criterion C. The above symptom disturbance must cause marked and persistent dysfunction in social, occupational, or other important domains
• Criterion D. The above symptom disturbance must last at least six months

Clearly I needed to get ready to settle in for the long haul if I was going to be of any use to anyone.

After talking to a support group it was clear the process really has no beginning or end. They emphasized getting a lot of sleep and trying to keep it as regular as possible. Don't end up trapped in the house for days not moving. Set small goals and basically be cautious, don't make any giant changes or decisions.

We talked about what a lot of them did and much of the discussion focused around a spiritual element. I'm not spiritual in any meaningful way. While I can appreciate the architecture of a church or a place of worship, seeking a higher power has never been a large part of my life. For the less religious a lot of them talking about creative outlets. These seemed more reasonable to me. "You should consider poetry" one man said. I didn't want to tell him I don't think I've ever really read poetry, much less written it.

What even is "focus" and "distractions"

I'm not going to lie. I figured I would add this section as a fun "this is how distractions and focus works in the human mind" with some graphs and charts. After spending a few days reading through JSTOR I had no such simple charts or graphs. The exact science behind how our minds work, what is focus and what is a distraction is a complicated topic so far beyond my ability to give it justice that it is laughable.

So here is my DISCLAIMER. As far as I can tell, we do not know how information is processed, stored or recalled in the brain. We also aren't sure how feelings or thinking even works. To even begin to answer these questions, you would need to be an expert in a ton of disciplines which I'm not. I'm not qualified to teach you anything about any topic related to the brain.

Why don't we know more about the human brain? Basically neurons are extremely small and the brain is very complicated. Scientists have been working on mapping the brain for 40 years with smaller organisms with some success. The way scientists seem to study this is: define the behavior, identify neurons involved in that behavior, finally agitate those neurons to see their role in changing the behavior. This is called "circuit dynamics". You can see a really good write-up here.

As you add complexity to the brain being studied, drawing these connections get more and more complicated. Our tools have improved as well, allowing us to tag neurons with different genes so they show up as different colors when studied to better understand their relationship in more complex creatures.

Anyway brains are really complicated and a lot of the stuff we repeat back to each other about how they work is, at best, educated guesses and at worst deliberately misleading. The actual scientific research happening in the field is still very much in the "getting a map of the terrain" step.

Disclaimer understood get on with it

Our brains are constantly being flooded with information from every direction. Somehow our mind has a tool to enable us to focus on one piece of information and filter out the distractions. When we focus on something, the electrical activity of the neocortex changes. The neurons there stop signalling in-sync and start firing out of order.

Why? Seemingly to allow us to let the neurons respond to different information in different ways. This means I can focus on your voice and filter out the background noise of the coffee shop. It seems the cholinergic system (don't stress I also had never heard of it) plays a large role in allowing this sync/out of sync behavior to work.

It turns out the cholinergic system regulates a lot of stuff. It handles the sensory processing, attention, sleep, and a lot more. You can read a lot more about it here. This system seems to be what is broadcasting to the brain "this is the thing you need to be focused on".

So we know that there is a system, based in science, to how focus and distraction work. However that isn't the only criteria that our minds use to judge whether a task was good or bad. We also rely on dopamine source floating around in our skulls to tell us "was that thing worth the effort we put into it". In order for the distraction to do what I wanted it had to be engrossing enough to trigger my brain into focusing on it and also giving me the dopamine to keep me invested.

The Nature of the Problem

There is a reality when you start to lose your family that is unlike anything I've ever experienced. You are being uprooted, the world you knew before is disappearing. The jokes change, the conversation change, you and the rest of your family have a different relationship now. Grief is a cruel teacher.

There is nothing gentle about feeling these entities in your life start to fade away. Quickly you discover that you lack the language for these conversations, long pauses on the phone while you struggle to offer anything up that isn't a glib stupid greeting card saying.

Other people lack the language too and it is hard to not hate them for it. I feel a sense of obligation to give the people expressing their sadness to me something, but I already know as I start talking that I don't have it. People are quick to offer up information or steps, which I think is natural, but the nature of illness is you can't really "work the problem". The Americans obsess on what hospital network she got into, the Danes obsess on how is she feeling.

You find yourself regretting all the certainty you had before. There was an idea of your life and that idea, as it turns out, had very little propping it up. For all the years invested in one view of the universe, this is far bigger. I'm not in it yet, but I can see its edges and interacting with people who are churning in its core scares me. My mind used to wander endlessly, but no more. Left to its own devices it will succumb to intense darkness.

Denial helps us to pace our feelings of grief. There is a grace in denial. It is nature's way of letting in only as much as we can handle.

Outside of the crisis you try and put together the memories and pieces into some sort of story. Was I good to Pixel? Did I pay enough attention to the stories my grandparents told me, the lessons and the funny bits? What kind of child was I? You begin to try and put them together into some sort of narrative, some way of explaining it to other people, but it falls apart. I can't edit without feeling dishonest. Without editing it becomes this jumble of words and ideas without a beginning or end.

I became afraid of my daughter dying in a way I hadn't before. Sure I had a lot of fear going into the birth process and I was as guilty as anyone of checking on her breathing 10 times a night at first. The first night with her in the hospital, me lying there on a bed staring at the ceiling while our roommate sobbed through the night, her boyfriend and baby snoozing away peacefully, I felt this fear for the first time. But I dealt with it, ran the numbers, looked at the stats, did the research.

Now I feel cursed with the knowledge that someone has to be the other percent. Never did I really think I was blessed, but I had managed to go so long without a disaster that it felt maybe like I would continue to skate forever. Then they hit all at once, stacked on each other. Children can die from small falls, choking on reasonable pieces of food or any of a million other things. Dropping her off at daycare for the first time, I felt the lack of control and almost turned around.

You can't curse your children to carry your emotional weight though. It is yours, the price of being an adult. My parents never did and I'm not going to be the first. A lot of stuff talks about solving grief but that's not even how this really works. You persist through these times, waiting for the phone call you know is coming. That's it, there isn't anything else to do or say about it. You sit and you wait and you listen to people awkwardly try to reassure you in the same way you once did to others.

Why Programming?

Obviously I need something to distract me. Like a lot of people in the tech field, I tend to hobby-bounce. I had many drawers full of brief interests where I would obsess over something for a month or so, join the online community for it, read everything I could find about it and then drop it hard. When I moved from Chicago to Denmark though, all that stuff had to go. Condense your life down to a cargo container and very soon you need to make hard choices about what comes and what gets donated. This all means that I had to throw out any idea which involved the purchase of a lot of stuff.

Some other obvious stuff was out unfortunately. Denmark doesn't have a strong volunteering movement, which makes sense in the context of "if the job is worth doing you should probably pay someone to do it". My schedule with a small child wasn't amendable to a lot of hours spent outside of the house with the exception of work.

My list of requirements looked like this:

• Not a big initial financial investment
• Flexible schedule
• Gave me the feeling of "making something"
• Couldn't take up a lot of physical space

How to make it different from work

From the beginning I knew I had to make this different from what I do at work. I write code at work, I didn't want this to turn into something where I end up working on stuff for work at all hours. So I laid out a few basic rules to help keep the two things separate from get.

• Use the absolute latest bleeding beta release of the programming language. Forget stability, get all the new features.
• Don't write tests. I love TDD but I didn't want this to be "a work product".
• Do not think about if you are going to release it into the public. If you want to later, go for it, but often when I'm working on a small fun project I get derailed thinking "well I need tests and CI and to use the correct framework and ensure I have a good and simple process for getting it running" etc etc.
• Try to find projects where there would be a good feedback loop of seeing progress.
• If something isn't interesting, just stop it immediately.

I started with a tvOS app.The whole OS exists to basically play video content, it is pretty easy to write and test and plus it is fun. Very quickly I felt it working, this distraction where I felt subconsciously I was allowed to be distracted because "this is productive and educational". It removed the sense of guilt I had when I was playing videogames or reading a book, tortured by a sense of "you should be focusing more on the members of your family that are going through this nightmare".

The tutorial I followed was this one. Nothing but good things to say about the experience, but I found a lot of the layout stuff to not really do much for me. I've never been that interested in CSS or web frontend work, not that it isn't valuable work I just don't have an eye for it. On to the next thing then.

From there I switched to GUI apps based in large part on this post. I use CLI tools all the time, it might be nice to make simple Python GUIs of commonly used tools for myself. I started small and easy, since I really wanted to get a fast feeling of progress.

The only GUI framework I've ever used before is tkinter which is convenient because it happens to be an idiot-proof GUI design. Here's the basic Hello World example:

from tkinter import *
from tkinter import ttk
root = Tk()
frm = ttk.Frame(root, padding=10)
frm.grid()
ttk.Label(frm, text="Hello World!").grid(column=0, row=0)
ttk.Button(frm, text="Quit", command=root.destroy).grid(column=1, row=0)
root.mainloop()

Immediately you should see some great helpful hints. First it's a grid, so adding or changing the relative position of the label is easy. Second we have a lot of flexibility with things that can sometimes be a problem with GUIs like auto-resizing.

Adding window.columnconfigure(i, weight=1, minsize=75) and window.rowconfigure(i, weight=1, minsize=50) allows us to quickly add resizing and by changing the weights we can change which column or row grows at what rate.

For those unaware of how GUI apps work, it's mostly based on Events and Event Handlers. Sometimes happens (a click or the keyboard is pressed) and you execute something as a result. See the Quit button above for a basic example. Very quickly you can start making fun little GUI apps that do whatever you want. The steps look like this:

1. Import tkinter and make a new window

import tkinter as tk

window = tk.Tk()

window.title("Your Sweet App")

window.resizable(width=False, height=False)

Make a widget with a label and assign it to a Frame
start = tk.Frame(master=window)
output_value = tk.Entry(master=start, width=10)
input = tk.Label(master=start, text="whatever")

Set up your layout, add a button to trigger an action and then define a function which you call on the Button with the command argument.

Have no idea what I'm talking about? No worries, I just did this tutorial and an hour later I was back up and running. You can make all sorts of cool stuff with Ttk and Tkinter.

Defining functions to run basically shell commands and output their value was surprisingly fun. I started with real basic ones like host.

1. Check to make sure it exists with shutil.which link
2. Run the command and format the output
3. Display in the GUI.

After that I made a GUI to check DKIM, SPF and DMARC. Then a GUI for seeing all your AWS stuff and deleting it if you wanted to. A simple website uptime checker that made a lambda for each new website you added in AWS and then had the app check an SQS queue when it opened to confirm the status. These things weren't really useful but they were fun and different.

The trick is to think of them like toys. They're not projects like you have at work, it's like Legos in Python. It's not serious and you can do whatever you want with them. I made a little one to check if any of the local shops had a bunch of hard to find electronics for sale. I didn't really want the electronics but it burned a lot of time.

Checking in

After this I just started including anything random I felt like including. Config files in TOML, storing state in SQLite, whatever seemed interesting. All of it is super easy in Python and with the GUI you get that really nice instant feedback. I'm not pulling containers or doing anything that requires a ton of setup. It is all super fast. This has become a nice nightly ritual. I get to sit there, open up the tools that I've come to know well, and very slowly change these various little GUIs. It's difficult enough to fully distract, to suck my whole mind into it.

I can't really tell you what will work for you, but hopefully this at least provided you with some idea of something that might work for you. I wish I had something more useful to say to people reading this suffering. I'm sorry. It seems the only sentiment I have heard that is honest.