Both Kev and Mike posted recently about their app defaults for the year. And it got me thinking. I want do that too! Here's a little of dust cleaning on this blog. Sharing the apps I been using this year.

• ✉️ Mail service: Fastmail
• 📫️ Mail Client: Fastmail and Thunderbird
• 📝 Notes: Logseq
• ✅ Todo: Todoist and LogSeq
• 🗓️ Calendar App: Fastmail
• 📅 Calendar Organizer: Morgen
• 👤 Contacts: Fastmail
• 📖 RSS reader: Readwise
• ☁️ Cloud Storage: Syncthing and DigitalOcean spaces
• 🖼️ Photo Library: Flickr
• 🌐 Web Browser: Firefox
• 🗨️ Chat: Delta.chat and Line
• 🔖 Bookmarks: Firefox
• 📖 Read Later: Readwise
• 📕 Reading: Readwise
• 📜 Word Processor: LaTex
• 📈 Spreadsheets: Airtable
• 🛒 Shopping Lists: Todoist
• 💰️ Personal Finance: YNAB
• 🎵 Music: Amazon Music
• 🎤 Podcast: Pocket Casts
• 🔐 Password Manager: 1password
• 🧑‍🚒 Social Media: Fediverse
• 🔎 Search: DuckDuckGo
• 🤖 AI search: Kagi
• ⌨️ Code Editor: Helix

Ever since the whole re-licensing from Hashicorp, I been looking at what to self-host. I started with rethinking what's the OS I'm using. And why.

So after thinking about the choices, I finally settled on a victor; Ubuntu Core.

Full Disclaimer, the choice is solely my own. It does not mean all of the many many many options out there are not viable. Far from it. I wrote a post debating the options for 'just' three and couldn't decide then. This OS simply seems to be working for me.

Canonical's Ubuntu Core became preferred for a primary reason. I don't want to care of the host OS. Long are the days I have time to customize everything. Creating custom kernels to get higher clock speeds. Now? I barely get to modify my editor.

From past usage, Ubuntu Core stayed out of my way. Basically, it was there for running LXD system containers of Hashicorp's Nomad, Consul, and Vault. All LXD containers. Easily built using Hashicorp's Packer.

My use case spent little on Ubuntu Core itself. And that's precisely the point. I noticed I almost never thought of the OS I was running. I did think of it every once in while. But anything configuration related was of how I could strip LXD completely. Building snaps instead for all the Hashicorp tools. Yet the setup with LXD worked too darn good, to fix what wasn't broken.

I spent most of my time focusing not on the host OS. Not on the LXD cluster. Nope, not even “that much” on Hashicorp services and tools.

My time was on applications. I was not worried about what Ubuntu Core did. Including updates. Everything actually worked automatically. Fully hands off when it came to the host OS. It was quite brilliant.

That same was not so for regular distributions. And surprisingly, not true with other immutable OS offerings. I spent a lot of time worrying about the host OS then. How to configure my startup settings to get things absurdly working. What to do about updates. Then, how to handle changes of updates when things broke. More time was spent provisioning and managing the host OS than on what was running the applications. Let alone the applications themselves.

I'll try Ubuntu Core for a few. If it ends up working out like I think it will, then great. If not, I can always wave back at the others.

#linux #UbuntuCore #distro

Now while many options exists, for me, I been debating on three. Dive so deep I hit bedrock with Nix and NixOS. Accept Kubernetes as the one true OS through Talos. Or drink the orange glowing Kool-Aid of snaps in Ubuntu Core. Bare with me. There's logic in these.

The choices

I been debating the choice on what to use as my de-facto immutable OS for a while now.

The three I settled (for now) are ones I think make the most sense. To set and forget. Distributions where I can realistically automate the entire thing. Without much fear of the ground falling apart. Because unlike normal Linux distributions, immutable OS versions are the wild west of Linux distros. All choose radically different ways of achieving same goals. Choice is great for ecosystem growth. Terrible for a foundation.

Ubuntu Core

The one I'm sure gets most debate is Ubuntu Core. Even though it's the most systematically grounded version of an immutable OS. The design is fairly simple. Use snaps. But the genius of this is how Canonical made every part of the OS into an isolated snap. Snaps you can update and change without impacting the 'core' of the OS.

You can update the entire OS with changing the snap version of the core you are based from. So jumping from Ubuntu core 20 to Ubuntu core 22 was doing something like this. And as Canonical has matured with how Ubuntu core operates, they have also made different layers to this design. Using the atomic principal.

So now there are snaps for the linux kernel. And configuration based ones called gadget snaps. Responsible for handling bootstrapping on a specific hardware. All following the same everything is a snap.

You can still run any application you want. The difference here is you have to package them differently. Or at least differently from the norm.

The con with Ubuntu core is that you have to accept their way of packaging software with snaps. There is no alternative. You must have Canonical as your overseer here. The pro is everything stated before benefits your ability to have a stable immutable system. It should not be understated. The ease that comes with having maintainability so low, with ubuntu core, is pretty remarkable.

Talos

Talos differs in a very simple way. The ENTIRE operating system. It is Linux technically because Talos uses the Linux kernel. It immediately deviates from there. You don't use an OS with Talos. What you use is Kubernetes.

Kubernetes is infamous at being complex. I even wrote about my annoyance years ago. After years, that article is still true for self hosted Kubernetes cluster. So is Kubernetes worth self hosting? I can wholeheartedly say NO. But with an exception. The exception here is if you are using Talos.

You see, Talos strips away practically everything of the OS. But it does it in a way that makes a lot of sense. You don't use ssh, because there is no shell to ssh to! Instead you use their gRPC API component; apid. Interfacing with the operating system. Talos has no systemd. Instead, replaced with their own PID 1. An init system called machined. With the whole purpose running what kubernetes needs and the gRPC interface to define the OS.

In practice, Talos is actually dead simple to use and administer. It makes using and maintaining kubernetes strikingly easy. New version release? Run talosctl to upgrade:

talosctl upgrade-k8s --to 1.28.0

Same is true for updating Talos itself. Because the OS is atomic, there is very little thought process required to handling failures. You rollback like nothing happened. Here, you simply use kubernetes.

The con with talos isn't actually the use of talos. It's the principal of only using kubernetes for everything. If you not comfortable with a job orchestration like it, DO NOT USE. If you somehow like ssh or want to install other things directly on the OS, DO NOT USE. If you don't want to do literally everything as code, definitely DO NOT USE.

But if you do value what Talos offers, it's immensely difficult not to choose it. So many problems are simply non-existent on Talos. The OS makes you question why even bother with the old ways.

NixOS

The prophecy is written. NixOS is the answer to our Linux administration ways. It will solve all our problems with packaging software. We will know of history as before and after NixOS. And quite frankly, it really does feel this way.

NixOS shines in the same ways the others in this list shine. It rethinks what a Linux is and could be. If you make absolutely everything atomic, to the core of how you package and run software, then do you even need to care if your OS breaks? NixOS potency is the nix programming language. Not to be confused with the nix as a package manager. Or the OS who is also called nix.

Unlike the other options on this list, the con with NixOS is quite immediately apparent. It's the difficulty you first have learning the ways of then learning the ways of using nix. Documentation is quite difficult to come by for nix. Much of your time will be left questioning how anything even functions. There's also then the full upgrade to nix design called nix flakes. All enough to really put incredible friction. Friction on nix usage and nixos adoption.

However, the moment you passed the hurdles of learning nix, nothing comes even close to its versatility. I personally have migrated most of my software to run with nix. Or at the very least, build with nix. For work, I have development environments strictly nix based. And the list goes on.

With NixOS, it's the same principal. You write your closure and you can be assured it will work. No matter what mess you do to the machine. You can roll back like nothing ever occurred. There's nothing really like Nix and NixOS. The principal is that you handle the hurdle of defining how your software is built. From then on, it will just run.

No more conflicts with versions of python. No issues with running two independently different versions of the same software. Because of the closure design, there's no need to containerize your applications. They 'just' work. With zero conflict running on the same host. Optimally, NixOS gets you the closest to the promise of Gentoo, but entirely atomic and immutable.

So what to choose?

I don't know yet. The reality is, all three options serve very similar ideas of running an immutable OS. They simply attack the problems differently. Talos packages software in kubernetes manifest essentially. Ubuntu Core is snaps. And NixOS is nix closures. All with different tradeoffs that are far too long to add to this never ending post.

For security reasons, I would probably go for Talos. Because of the stripped purpose of the OS, there's a smaller footprint to a security issue. Yes. Even with Kubernetes.

For maintainability, I think Ubuntu Core is prime. Canonical has been doing Linux distributions for decades now. They know what it means to make something function. Every Ubuntu core release has a maintenance window of up to ten years. Meaning, if I want to just run my thing, with no fuss, this will be it.

For customization, nothing gets even close to what NixOS promises and delivers. I would be able to take all the Nix flakes I been writing for myself and run straight on NixOS. True “it works on my machine” on all machines.

#linux #immutableos #ubuntucore #talos #nixos #atomic #ubuntu #kubernetes

In mid August, Hashicorp dropped an infinitesimal bomb. All their software would be stripped from their open source license. Replaced with business source license for four years to a release.

I won't go into what the license entails. The thousands of community posts throughout the internet likely fill that void.

Instead, reflecting what a delay in open source means. To collect my thoughts. And I came up with essentially Hashicorp decision is their own. While I can sympathize with their reasoning, it doesn't mean I agree. Nor do I need to agree with the company.

For me personally, the license means a time of change. Moving away from almost exclusively Hashicorp software. There are literal thousands of alternatives available. Maybe not as seamlessly interconnected. But none the less, the options exist.

I already have my eyes set on a bunch of shinny things I wanted to try. But been dragging my feat. Precisely due to ease of use Hashicorp products have provided. Though now, going to actually try something different.

This time around, I'm going to write out my thoughts on what I end up building. So maybe, the built infrastructure can help others.

#hashicorp #license #software

I've used RSS for a long time. Absorbing was the same as gathering information then. In the past, all it took was to subscribe to a few feeds of some sites or blogs with summaries. Then going about and sitting down to read through those feeds of interests. RSS worked immensely well for the time. However, as more content ended up being produced, even RSS has become very unmanageable. You end up with multiple sources and feeds that are simply never ending. Requiring you to continuously spend your time gathering information rather than absorbing.

Worse still is with how much social media has changed where you have to gather. It is not enough to read through your RSS. You also now need to go through twitter, reddit, hacker news, countless of mailing lists, and all those blogs you follow. Gathering information can get exhausting. Especially if your focus is to absorb, learn, and move on with your day. Simply put, too much content to gather and too little time to absorb it all.

The way I been tackling this problem is having to reluctantly move away from RSS. Instead using a proprietary tool called Mailbrew. Somewhere around last year, DHH wrote a post on not using twitter directly. And the tool, he ended up focusing on to achieve that was the very same; Mailbrew. So I've gone sort of the same channel of thought, but taken it a bit further. I don't use Mailbrew only for twitter. I use it to gather all of the news I use to absorb.

With Mailbrew, I'm able to use multiple different sources. So I can still have all the RSS feeds I had before. But now, I can also add social media to the mix. So yes, twitter, reddit, and all the rest. All gathering information in different digests Mailbrew calls “brews”. Each brew of mine are centered on themes. For example, I have one for all software development news I tend to look for I call Active Software News. The list focuses solely on software development and gathers information from a few source types like hacker news, RSS, and twitter. Another would then be for everything I want to know of web3 I call Digitial Financials. Again same idea of gathering informational themes.

If only gathering information was enough, Mailbrew can help quite a lot. But that isn't the goal here. The goal is to not just gather information, but also absorb it. So the most important part of Mailbrew is in limiting how much of every source you are provided.

Starting with frequency, Mailbrew can send each one of your brew digests according to the frequency you desire. For Digital Financials, I have Mailbrew send out the brew each day in the morning. But for another public brew of mine called Active Software News, I have it only send a brew weekdays on Monday, Wednesday, and Friday at noon. However if frequency was the only limitation, then you would still have thousands of pieces to drown from when you open those digest.

The next and more important part is the count of each source. This I think is where Mailbrew shines and is why I've stuck to using it over alternatives. You see, the frequency is how you limit when you get information, but the count of each source is how you limit the exhaust of those sources. Instead of having every article sent to you waiting to be read in a forever list, you can limit the count by most recent or popular of those sources.

An excellent example of catering counts is the Digital Financials brew. Web3 is almost impossible to keep up to date without using twitter. Most of the news is centered around the platform and gathering alone can be extremely time consuming. Instead, I have a few set of lists on the brew to limit how much of each type of source is given. Some have three posts for source types and other just two for any given twitter handle. Along with limiting each post, the brew's source types also have the count of the source type limited. Meaning, not only how many post per author is given, but limiting how many posts of the source type as well. This allows to be informed, but only enough. So that it takes about 10-20 minutes a day to get informed of what's going on versus hours drained of my free time. It works well enough that I don't need to be constantly reading articles and posts the gathered information.

The power of Mailbrew with both limiting frequency and count of digest brews means you are able to focus. You don't or need to be on top of every piece of news available on those digests. You can still very much go down the rabbit hole of a specific source, but you don't have to start with everything from the start. Only enough to both gather information and absorb what you are gathering. Not constantly checking your sources, scrolling endless lists of social media, and being able to disable notifications for practically everything. So you can spend your day doing the thousand other things you have to do.

Now it doesn't mean that immediately reading this starter guide, you will have everything under the sun set up with Nix Flakes for your development need. But at least, you won't have to worry about setting up asdf, your weird hacks you need for your machine and the other tiny little things to get elixir started with elixir-ls.

Background

A little background. Nix, for the uninitiated, is a purely functional language for package management. What makes Nix interesting is you can use the purely functional aspect to build out artifacts which are entirely idempotent. Meaning, no matter how many times you run the nix expressions you have, the end result will always be the same regardless of external state of a machine. Its build structure as a package manager has evolved the language to build out guaranteed result for all sorts of software. Yet, Nix itself isn't exactly easy to learn. Due in part to the ambitions of the project and difficulties, which arose from those ambitions, complexities crept in. Nix Flakes is an answer to some of these complexities and more.

With Nix Flakes, you have the ability to have a very well defined package for a project. Written and using Nix in a way that takes all the learning from its years. Making it easier to define what you want from nix; the build result for a package.

Getting flakes enabled

So how do you get started with Nix Flakes? The first part that you should probably have is nix already installed and some familiarity with the nix language. Run through the guide to your platform needs.

Next is the settings to use nix with flakes. Since flakes is still in development (but relatively stable), you do need to enable the feature on nix. You can do so by enabling the experimental features of both nix-command and flakes through the nix.conf file.

# make nix config path if not existent
mkdir ~/.config/nix/ -p
# add the settings to the file on config path
echo "experimental-features = nix-command flakes" | tee ~/.config/nix/nix.conf -a

Once the settings are applied, you should be able to validate by running show-config

nix show-config | grep experimental

If all is successful, you should see an output for the same experimental features you wrote on the nix.conf file.

The flake.nix file

So now to get to use nix flake comes the heart of the project, the flake.nix file. The file itself needs three defined keys on the set, description, inputs, and outputs. Each one of them plays a different role in how to define your package you want to build.

description key

The description key is a one liner description of what the flake project is. Helps in giving what the flake is for quick review after you have a few hundred of these built out...

# flake.nix, ignoring input and output
{
  description = "A description of some kind";
}

inputs key

The inputs is how you can import external sources of other flakes into the flake project you have. In other words, any project you may need or tools required to get started, this is where you will define their source. Example below is using the standard nixpkgs and a tool called flake-utils, which provides a set of functions to make flake nix packages simpler to set up without external dependencies.

# flake.nix, ignoring description and output
{
  inputs = {
    # using unstable branch for the latest packages of nixpkgs
    nixpkgs = { url = "github:NixOS/nixpkgs/nixpkgs-unstable"; }; 
    flake-utils = { url = "github:numtide/flake-utils"; };
  };
}

outputs key

The outputs is where the bulk of your logic for what you will build with flakes. It has quite a numerous of options, but in this use case, we only care of the devShell key, which is what will be used to populate the development environment. While the following may all look like a lot for the output, it's also everything that would be needed for either building out a nix flake package or use for a development environment:

# flake.nix, ignoreing description and input
{
  outputs = { self, nixpkgs, flake-utils }:
   flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs { inherit system; };

        elixir = pkgs.beam.packages.erlang.elixir;
        elixir-ls = pkgs.beam.packages.erlang.elixir_ls;
        locales = pkgs.glibcLocales;
      in
      {
        devShell = pkgs.mkShell {
          buildInputs = [
            elixir
            locales
          ]
        }
      });
}

The output key is actually a function which takes the inputs defined on inputs. Hence the set { self, nixpkgs, flake-utils }. All the inputs on the function were defined on the input with self being the flake.nix file itself. The next portion is using a simple but powerful flake-utils function called eachDefaultSystem. What the function provides is actually build the development environment for all available platforms currently available for nix as a default. You can see the list by running nix flake show (after the file is fully written) and you will be provided an output like the following:

└───devShell
    ├───aarch64-darwin: development environment 'nix-shell'
    ├───aarch64-linux: development environment 'nix-shell'
    ├───i686-linux: development environment 'nix-shell'
    ├───x86_64-darwin: development environment 'nix-shell'
    └───x86_64-linux: development environment 'nix-shell'

Meaning, you do not have to worry about what OS you using, as long as it's linux or macos. You write your nix flake with the ability to use it with all the supported platforms from the start for your environment. In other words, Write once, run on all the machines. No more of that 'it runs on my machine' debacle.

The last section is a let .. in pair to both declare what you will use in the system you are building and devShell itself. The packages use here are simply elixir, elixir-ls for sanity, and locales to make sure elixir is able to use the proper locale settings of the shell environment produced by the nix flake.

Finally, the devShell in this case is the buildInputs wanted for the shell environment and nothing more:

      {
        devShell = pkgs.mkShell {
          buildInputs = [
            elixir
            locales
          ]
      }

Notice while elixir-ls package isn't directly declared in the mkShell buildInput, it is part of the output on let. Allowing to still have linked access to its packages.

The full nix flake development environment

Finally, putting it all together, getting a nix flake project started for your development environment, all falls down to what packages you need on the devShell. With the flake.nix file on the root of your project, you have the ability to have the packages you need and ready for you to work with.

{
    description = "Development environment";

  inputs = {
      nixpkgs = { url = "github:NixOS/nixpkgs/nixpkgs-unstable"; };
    flake-utils = { url = "github:numtide/flake-utils"; };
  };

  outputs = { self, nixpkgs, flake-utils }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        inherit (nixpkgs.lib) optional;
        pkgs = import nixpkgs { inherit system; };

        elixir = pkgs.beam.packages.erlang.elixir;
        elixir-ls = pkgs.beam.packages.erlang.elixir_ls;
        locales = pkgs.glibcLocales;
      in
      {
          devShell = pkgs.mkShell
          {
              buildInputs = [
                elixir
              locales
            ];
          };
      }
    );
}

#elixir #development #nix #flakes

Bonus: Limiting by platform of choice your nix flake

Glad you made it this far. Well friend, besides the default system listing on flake-utils, there is another route you can go in setting up you development environment. You may have noticed that the run of nix flake show showed multiple platforms and architectures available by default. However, it may be you don't need to use all those platforms and architecture. You may like to target only a set of architectures or platforms you need and that's it. Speeding up your build process and saving on some storage if you don't want those extra platforms.

flake-utils has the option with the flake-utils.lib.eachSystem function. The function itself takes an array of systems you want the flake to build out. To use the function, you have to use a let .. in expression to define the array and then it's use. For my use, I only target aarch64-linux and x86_64-linux since those are the only platforms I work with. So I define them on an array.

supportedSystems = [ "x86_64-linux" "aarch64-linux" ];

Then I use that defined array to apply to the the function flake-utils.lib.eachSystem

flake-utils.lib.eachSystem supportedSystems (system: 
  # same as blocks before with `flake-utils.lib.eachDefaultSystem`
)

With all of it put together below, you can see how to use with let .. in expression:

{
  description = "Development environment";

  inputs = {
    nixpkgs = { url = "github:NixOS/nixpkgs/nixpkgs-unstable"; };
    flake-utils = { url = "github:numtide/flake-utils"; };
  };

  outputs = { self, nixpkgs, flake-utils }:
    let supportedSystems = [ "x86_64-linux" "aarch64-linux" ];
    in
    flake-utils.lib.eachSystem supportedSystems (system:
      let
        inherit (nixpkgs.lib) optional;
        pkgs = import nixpkgs { inherit system; };

        elixir = pkgs.beam.packages.erlang.elixir;
        elixir-ls = pkgs.beam.packages.erlang.elixir_ls;
        locales = pkgs.glibcLocales;
      in
      {
        devShell = pkgs.mkShell
          {
            buildInputs = [
              elixir
              locales
            ];
          };
      }
    );
}

Now when you run nix flake show the output should be only the platforms you defined:

    ├───aarch64-linux: development environment 'nix-shell'
    └───x86_64-linux: development environment 'nix-shell'

I been using 1password for a while at work and with the 1Password Linux having some nice integrations, thought why not try it out as an every day driver. Not to mention that a business plan gives a free family plan for every account on its plan. So I started to venture forth. And of course, immediately I hit a snag. Bitwarden isn't supported as a 1password direct conversion. Although 1password do offer a way for you to use csv import, you still need to format the csv correctly.

Bitwarden graciously offers the ability to export as a csv and json (and encrypted json if that's your thing). The exported raw csv doesn't exactly format as is to 1password. Looked around online and found some tools that could do the job, but they kind of suck in setting it up how I would like. So of course I want to make my own. Thing is, I wanted to do this as quick as I could.

The tool would have to take the exported csv file and truncate to only have login type rows and only columns related to such. One of the endless interesting features sqlite has is the ability to import and export a csv. You also get a tool to mutate a relational data file with a file based relation database. Thus, sqlite was my preferred choice to get the conversion out of the way.

So first's thing's first: figure out what is the converted format to use on 1password. When you export from bitwarden as an csv, the export column outputs as follows:

folder,favorite,type,name,notes,fields,login_uri,login_username,login_password,login_totp

I only care for the conversion to get a few columns set up:

name,notes,url,username,password,one-time password

Knowing the format, go right ahead and make a database on sqlite:

sqlite3 convert.db

Next, set the import mode to csv and import the exported csv to a raw table

sqlite> .mode csv
sqlite> .import raw.csv raw

Due to not giving the schema here nor needing to, all the columns will be imported as TEXT type. The imported type works to the need here. So let's make a new table called 'output' with the columns desired. The table created will be the same as raw but with the selected columns only and their names. To do so, simply run a select for said columns:

CREATE TABLE output AS SELECT type, name, notes, login_uri as url, login_username as username, login_password as password, login_totp as 'one-time password' from raw;

Next, remember the ask here was only to have login types from 1password for this conversion. Running a delete for everything but the login type:

delete from output where type != 'login';

Then drop the column for 'type' as it's not needed:

ALTER TABLE output DROP COLUMN type; 

Now the output table should be ready to exporting to import in 1password. Let's go ahead and set sqlite headers on and set output file:

.headers on
.output converted.csv

Lastly, get that output table exported. Since we know we want all the fields let's go ahead and export with a select all:

select * from output;

You're done with the file. It should now work in importing on 1password. Now before you go and say, “hey fool, you could do this much simpler”. You are right, I could. So here's the lines for everything above using relation database correctly:

.mode csv
.import raw.csv raw
.headers on
.output converted.csv

SELECT 
  name, notes, login_uri as url, login_username as username, login_password as password, login_totp as 'one-time password' 
FROM raw
WHERE type = 'login';

The output is exactly what is desired here and it also gives a baseline of what I want my csv output to be. You can go ahead and import the csv to 1password now. Just make sure to remove the first row and correlate the column names with those that would be for 1password. The one last piece is that one time password isn't available as a type you can choose. So you need to make a custom field. Then you can apply by editing the field after import. I know, annoying.

Originally I thought the keyboard was a neat idea. I had a new need for a new keyboard and it's been a awful long while (read two years) since I had something decent. Not to mention, I suffer from what I am calling the Linux terminal syndrome. It is a deadly disease in which you tell everyone you use Linux and happen to also almost exclusively use a keyboard due to some bizarre hatred of mouses. Because of this lifetime choice, I am constantly typing and try as much as possible to take care of my hands. It is also to lessen the suffering from something very real like carpal tunnel or tendinitis. So I gave the team the good ol' funding on kickstarter.

It's been one month since my life has changed with Keyboardio's Atreus keyboard. The keyboard itself is forty four hardware keys in total. Take some time to leave that number to sink in... I'll wait....

Forty four keys.

FORTY FOUR KEYS.

OK. Why is the magic number such a big deal? So a normal keyboard has somewhere around 104 keys. What the team at Keyboardio did was look at a normal keyboard and say, “lol, NO.” These people went and cut down by more than half all the keys, yet figured a way to make you have more functionality on your existing keys than you can possibly ever need. Keyboardio went ahead like mad men, saw the potential of shifting to a different layer on a keyboard, and took it up a notch. You see, the keyboard has an ability to shift to different layers of which all the keys can be different to focus on what you need. So the 104 keys can be stuffed in just 3 layers on the keyboard, with spacing to spare.

Afterwards, Keyboardio went and then said, “You know what? Let's just add more layers, cause why not?” Thus, Atreus keyboard has the ability of holding nine layers of key definitions you can fully customize to whatever your needs or itch running at any time. The crazy people over at Keyboardio also made it so you can import and export the key definitions in structured JSON. Technically giving you endless formatting to your heart's content. So in case you somehow wanted to share your keys (I do and did, click here), you can with minimal effort.

Along with the customization, and there is definite more you can do with this, the Atreus design is what really makes sense for balanced sane typing. Since all the keys are layered on the forty four keys, your hand never reaches to press any key on the keyboard. This means none of that extended stretching to press the ESC key three meters away from the next key. It also features an ergonomic design that just makes sense. So much so that it feels very awkward touching another keyboard, which doesn't use the structure.

Lastly, and certainly not least, you can use BOX switches to make as much sound as mechanically possible. For me, this means using BOX red switches. Allowing me to keep my tradition of using my keyboard as if I'm playing a piano. Bundle all this in and you got yourself something almost healing to the touch. I dare say, you will probably be typing faster and smoother as time goes on.

The biggest piece to get and learn is the layout of the layering you set up. There was a lot of thought put into the original formatting. In other words, do fight the urge of customizing Keyboardio's choosing for Atreus layering layout. It will make the curve just that much easier to adapt towards. Then once you get a feel, start making it to your needs.

I'm still learning this little powerhouse, but I can safely say my typing has only gotten better without sacrificing my hands in the process.

Disclaimer: this whole article was written with the wondrous forty four keys of Atreus.

#keyboard #tooling #hardware

Anyone who has written software for multiple architectures know it is never plainly, “compile for your target and it will just work.” The reality is, there are always some exception you must take account for. It makes sense why. Any difference in architecture means entirely different ISA or even revision. Which translates to different rules for memory, instruction sets available, operational cost analyst, and much more. So taking your C code and just compiling it for AArch64 wouldn't cut it.

The same can be said for a process virtual machine used in Java. In theory, using the virtual machine meant you would target only the virtual machine and not have have to worry about the architecture the virtual machine would run under. However, in practice it has not been the case. Almost always, you still have to be aware of the architecture you are targeting due to bound operational differences like the list given prior.

This is where Web Assembly (wasm) is starting to shine. Wasm initially started as a way to run bytecode faster on the browser. Allowing for running heavier logic not possible with ECMAScript. To accomplish this, wasm was set up to use a process virtual machine like the JVM, but that targets a very specific ISA. So the VM can execute the ISA differently, but still requires to be able to run without modification. This results in the bytecode having exactly the same assembly definition regardless of physical architecture. Which means the VM can execute the bytecode on how it would be better optimized for the architecture. Giving way to focusing on only writing for a single target and only optimizing for that target. Leaving the VM that will run the wasm binary to take care of the heavy lifting as it should.

Right now, the prospect of wasm use in running on everything is not there just yet. It was only December 2019 the wasm specification was even agreed upon by W3C. Yet, you can see the ability starting to creep up. Projects like WASI from Mozilla for portability and security, Krustlet for kubelet running wasm instead of containers on kubernetes, and Cloudflare's Workers for running on the edge with GEO distribution using wasm.

I'm excited to see web assembly's potential. Its progress may result in a saner stack. Maybe even only requiring one runtime and nothing else, web assembly.

#Day14 #100DaysToOffload #Wasm #WebAssembly

If you haven't, then you haven't had a codebase at the multi thousand lines of boilerplate. You just naturally end up writing so much logic gates, just to get around the limitations of what you are using. This is true in software development, but it is especially true in a Domain Specific Language (DSL) for Infrastructure as Code (IaC). My setup has always been to use the declarative nature of Hashicorp's Terraform and AWS Cloudformation for their respective jobs. The IaC tools have worked great. I've been a heavy user of both. But it can get pretty ridiculous how much you have to do to get one single resource up and running (correctly anyway).

Moreover, if you try to do the same with a provisioner or ochestrator, then you are definitely in for multiples levels of hell. Not to say you can't go the route of using Kubernetes for your IaC implementation or Ansible in a declarative fashion. The problem is, you end up writing too much boilerplate before you ever get to what you wanted to do. Your goal ends being forever further away from your intentions.

What terraform and cloudformation get right is you need a full set of primitives to your infrastructure. It makes declarative state the goal of what you want, rather than the how you get to that state. If you try to use libraries for cloud providers directly, like boto or godo, with a programming language of choice, you end essentially building an entire in-house IaC provisioner. Requiring no difference in the level of boilerplate you write. Probably more so as you now need code to define basic primitives in a declarative fashion before you can create what you want.

However, using a generic programming language for IaC can have some strong upsides. You can get precise logic and structures that are very well defined to what you need the infrastructure to be. You can also do some classical test driven development to better define your logic. So in the past few months, I have been thinking on how to resolve the problems of having to constantly write so much boilerplate, make maintenance more manageable, and have better abstractions for core primitives I want to create on a cloud provider. Instead of trying to do this again with cloudformation and terraform, I have begun working with pulumi and AWS CDK for the ambitious goal.

I'm still early in my venture, but so far I have learned both provide much simpler definitions for resources to create. The boilerplate is extremely minimal as the tools are designed for you to create modules or packages that you extend for your needs. With both, my codebases have gone done considerably. Making maintenance actually feasible. I'm still discovering of their usage. Still, I'm really liking the ability to use a full generic programming language to do everything I need to in my IaC.

#100DaysToOffload #Day13 #Infrastructure #IaC #Declarative