I use my phone a lot. Its the best for consuming media on the go sort of things, like reading, watching videos etc. Always on, always connected, ready to whip out in a moments notice!
I also hate using my phone for anything else: for a long time the reasons have eluded me, but this time I have a lead – I hate typing on my phone.
Obviously there are more fundamental problems here than those solved by strapping on a keyboard1, explained so well by this quote from 99% Percent invisible episode about Douglas Englebart -
The consumer market prioritizes simple and “user-friendly” devices over more complex and “learnable” devices.
They elaborate further
Englebart used to compare the sleek, simplified Apple products to a tricycle. You don’t need any special training to operate a tricycle, and that’s fine if you’re just going to go around the block. If you’re trying to go up a hill or go a long distance, you want a real bike. The kind with gears and brakes– the kind that takes time to learn how to steer and balance on.
Recently, I got to try a pocket reform. For the uninitiated, its a 7” pocket sized (arguably, depending on what kind of pockets you have) computer. It is a nifty little device with a lot of cool factor, including a compact mechanical keyboard and more or less running blob free software stack!
This got me thinking: Is it worthwhile to compromise extreme portability to gain learnability and configuration?
A device like pocket reform is not going to be as good as my phone for quickly reading through my reading list, at least not out of the box. Would I still prefer to stick with my phone? Obviously the answer is going to personal and subjective, but I believe its worthwhile to try!
Pocket reforms are currently only sold through the crown supply store in US, so I decided to wait until MNT starts selling them from their EU store, and spent the waiting time maybe hacking alternatives a bit – Can I strap a Blackberry Keyboard to my phone? Running mainline linux with the stack you are used to seems fun etc etc. Honestly, I needed some deliberation before dropping a cool grand on an experiment.
Also, after going through bit of internet searching, the options are not as limited as I thought; there are bunch of manufactures trying to make devices in this form factor: GPD seems to be the most popular, there are also no-name products with at least one very happy HN reader.
This nerdary also led me discover “Cyberdecks”. I have not read Neuromancer so I don’t know what makes something a cyberdeck; but the community seems to be building some of the coolest portable computing out there. Definitely check it out if you were living under a rock like me!
Still, probably would try it when becomes avaible for my phone and comes down from its > $100 pricetag.↩︎
Zvol are volumes backed by a zfs pool. They are quite popular as vm disk images.
Sometimes you just want to examine them in the host; here is how to mount them.
When the pool is imported, they show up under /dev/zvol/<path to zvol dataset>
. At this point they are just raw drives, and kernel knows nothing
about its structure. To be able to mount them, we first need to read its
partition structure and create partition specific /dev/
entires with
kpartx(8)
1.
# -a for add
kpartx -a /dev/zvol/<pathtozvol>
This will create corresponding devices for partitions under /dev/mapper
$:/dev/mapper]# ls -al
total 0
drwxr-xr-x 2 root root 120 Jan 12 17:04 .
drwxr-xr-x 20 root root 3980 Jan 12 17:04 ..
crw------- 1 root root 10, 236 Jan 12 17:00 control
lrwxrwxrwx 1 root root 7 Jan 12 17:04 root-zvol1 -> ../dm-0
lrwxrwxrwx 1 root root 7 Jan 12 17:04 root-zvol2 -> ../dm-1
lrwxrwxrwx 1 root root 7 Jan 12 17:04 root-zvol3 -> ../dm-2
Now you can mount them as a regular disk with mount
.
mount /dev/mapper/root-zvol1 /mnt
In nixos, kpartx
is part of package multipath-tools
↩︎
There exists a mutitude of tooling to remotely manage nixos machines, each with its own features and compromises.
In my experience, for a simple deployment of few hosts
nixos-rebuild --target-host
is pretty powerful.
This is the workflow I’ve been using to manage my personal systems:
I bootstrap the machines manually by following the nixos install
guide, and copy over
the generated configuration to config/<hostname>/configuration.nix
.
On the root directory create flake.nix
:
{
description = "systems needed";
inputs = {
# extra inputs go here
};
outputs = { self, nixpkgs }@attrs: {
# this is where we add new machines
nixosConfigurations = {
# host fancyHostname
fancyHostname = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
specialArgs = attrs;
modules = [
# This points to the actual machine configuration
(import ./config/nixmachine/configuration.nix)
];
};
};
};
}
From there, hosts can deployed over SSH!
nixos-rebuild switch --target-host root@fancyHostname --flake '.#fancyHostname'
More hosts can be added by adding them to the nixosConfigurations
attribute set.
nixosConfigurations = {
fancySecondHost = { ... }
...
}
I think this is an easier workflow for me to manage and debug, However a lot of things in this space has non-linear learning curves and has sparse documentation at best.
So maybe a tool with better documentation might work well for you?
This also relies heavily on flakes
, which is “experimental”. In my experience,
ground reality is everyone uses flakes, but good documentation is hard to come by
I’ve herd good things about Nix Flakes Book, but haven’t read it
This was first published at https://pencil.lalalala.in/dbalan/easy-nixos-remote-deployments
Lately the EU mirror for FreeBSD packages(http://pkg0.bme.freebsd.org) has been really slow for me. My best guess is the mirror is being overloaded, it could be because of my ISP peering weirdly too.
I already have a Poudriere setup running on a beefy server. How hard it would be building all the packages that I need? Turns out its not that hard at all.
First step is to get all the packages that I currently use and their port names
$ pkg query '%o' > x230-packages
# make sure they look right
$ head x230-packages
math/coinmp
x11-fonts/gentium-basic
graphics/ImageMagick6
devel/ORBit2
graphics/aalib
sysutils/accountsservice
print/adobe-cmaps
x11-themes/adwaita-icon-theme
x11/alacritty
audio/alsa-lib
Setup poudriere with instructions from handbook: https://www.freebsd.org/doc/handbook/ports-poudriere.html
Build the packages
/usr/local/bin/poudriere ports -p local -u
/usr/local/bin/poudriere bulk -j 12amd64 -p local -z x230 -f /root/x230-packages
After a day and half poudriere built all the packages I need :)
Now all that left is to disable the official repo and replace it with mine
cat > /usr/local/etc/pkg/repos/Mine.conf <<EOF
FreeBSD: { enabled: no }
builder: {
url: "https://<path to repo>/repo/12amd64-local-x230/",
enabled: yes
}
EOF
Bye bye slow mirrors!
This should be filed under over-engineering, and I should really investigate why the mirror is slow; This does work and love how simple and powerful the pkg system is. Workflow is far better than I am used to bulk building debian or arch packages.
“Alternatively, how I use Nitrokeys/GnuK/YubiKeys”
Most popular use for NitroKeys seems to be 2FA FIDO key. But these devices can also behave (emulate technically speaking) as an OpenPGP smartcard to store your gpg keys1.
GnuPG keys stored on smartcards only allow very narrow access to how one can use them. Smartcards exposes APIs to perform specific PGP operations like sign, encrypt, verify signature etc and no more; opposed to keys stored on local disk which gives all out access to keys if one has access to disk. Most important access that smartcards deny is the ability to copy them; essentially tieing your key to a physical object that can’t be replicated. As long as you have your key with you, no one else has access to them.
Almost all of the software we run has access to users disk on most operating systems, and we have seen exploits that target keys stored on disk again and again. The keys stored on disk are often encrypted, but stealing that encryption password is just a matter of chaining another exploit.
Having a physical root of trust combined with the fact that a lot of software supports GnuPG makes this a really nice composable component in my daily life.
Some work-flows that I use daily:
GnuPG has native support for SSH. Your smartcard becomes my ssh key as well and I can roam between my multiple machines without actually having to copy and leave keys around or having to manage multiple keys.
I also use a similar key for github since they use ssh to authenticate as well.
pass is a password manager following UNIX philosophy. It uses GnuPG keys to encrypt passwords, and by using a key on the smartcard, you can tie the trust to the smartcard.
Pass also opens up a lot more composable behaviors, I use it mostly for the next one –
aws-vault is a nifty tool to manage AWS credentials. It can transparently issue temporary keys and populate shell environment.
There is possibly more, I have seen people use the same key to unlock their disk encryption at boot :-)
I am not going to cover setting up the card here, since there are a lot of documentation about how to do so, and it varies slightly by the card that one is using. However I’d suggest to not generate keys on the card, since you have zero backups in case you loose the card and also, we have seen it is really hard to generate good keys on small devices.
Ones that I know, there are possibly more.
Each manufacturer have some models (usually the cheapest) are exclusivly FIDO keys and thus does not support this feature. NitroKey calls this feature “Email encryption” while Yubikey calls this “open PGP”.↩︎
unlike others Gnuk is a project to provide open firmware that implements smartcard. NitroKey sells a version based on GnuK called NitroKey Start.↩︎