Compare commits
5 commits
e7d4442af6
...
018c27f6e3
Author | SHA1 | Date | |
---|---|---|---|
Gabe Venberg | 018c27f6e3 | ||
Gabe Venberg | 87eec1d61b | ||
Gabe Venberg | 74b977fd65 | ||
Gabe Venberg | 6e6d7c21c6 | ||
Gabe Venberg | 509b212c83 |
|
@ -1,6 +1,6 @@
|
||||||
---
|
+++
|
||||||
title: "{{ replace .Name "-" " " | title }}"
|
title = "{{ replace .Name "-" " " | title }}"
|
||||||
date: {{ .Date }}
|
date = {{ .Date }}
|
||||||
draft: true
|
draft = true
|
||||||
---
|
+++
|
||||||
|
|
||||||
|
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 255 KiB After Width: | Height: | Size: 255 KiB |
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 212 KiB After Width: | Height: | Size: 212 KiB |
Before Width: | Height: | Size: 217 KiB After Width: | Height: | Size: 217 KiB |
|
@ -80,9 +80,9 @@ ls specifically can trace its history to 1961
|
||||||
-->
|
-->
|
||||||
|
|
||||||
Take a look at this [table](#appendix-the-tools) at the bottom of the page.
|
Take a look at this [table](#appendix-the-tools) at the bottom of the page.
|
||||||
Ill wait.
|
I'll wait.
|
||||||
Notice the relative scarcity between ~1995 and ~2015?
|
Notice the relative scarcity between ~1995 and ~2015?
|
||||||
Id like to talk about a trend Ive seen these past few years,
|
Id like to talk about a trend I've seen these past few years,
|
||||||
where people are rewriting and rethinking staples of the command line interface,
|
where people are rewriting and rethinking staples of the command line interface,
|
||||||
why I think this trend might be happening,
|
why I think this trend might be happening,
|
||||||
and why I think this trend is a good thing.
|
and why I think this trend is a good thing.
|
||||||
|
@ -161,13 +161,13 @@ Of course, fish still has the same level of configurability as zsh, it just also
|
||||||
|
|
||||||
To demonstrate my point, this is the default prompt for zsh with no configuration.
|
To demonstrate my point, this is the default prompt for zsh with no configuration.
|
||||||
It *only* shows the hostname, none of the advanced features you can get out of a zsh prompt even without plugins.
|
It *only* shows the hostname, none of the advanced features you can get out of a zsh prompt even without plugins.
|
||||||
![zsh prompt, only shows hostname](zsh_prompt.png)
|
![zsh prompt, only shows hostname](zsh-prompt.png)
|
||||||
Here is bash's prompt.
|
Here is bash's prompt.
|
||||||
It actually gives more info than zsh's, even though zsh can do more when properly configured.
|
It actually gives more info than zsh's, even though zsh can do more when properly configured.
|
||||||
![bash prompt, shows hostname and current directory](bash_prompt.png)
|
![bash prompt, shows hostname and current directory](bash-prompt.png)
|
||||||
And here is fish's default prompt.
|
And here is fish's default prompt.
|
||||||
It has a few colours, shows everything the bash prompt does, and additionally shows the git branch we are on.
|
It has a few colours, shows everything the bash prompt does, and additionally shows the git branch we are on.
|
||||||
![fish prompt, has colours, shows hostname, current directory, and git info](fish_prompt.png)
|
![fish prompt, has colours, shows hostname, current directory, and git info](fish-prompt.png)
|
||||||
|
|
||||||
Text editors are another great example of the evolution of out of the box defaults.
|
Text editors are another great example of the evolution of out of the box defaults.
|
||||||
Vim and Neovim both improved on their predecessors,
|
Vim and Neovim both improved on their predecessors,
|
||||||
|
@ -214,7 +214,7 @@ but its an extremely usable IDE out of the box thanks to having all of its featu
|
||||||
|
|
||||||
### Concise and discoverable documentation
|
### Concise and discoverable documentation
|
||||||
|
|
||||||
In my nvim config, I use [which-key](https://github.com/folke/which-key.nvim),
|
In my Nvim config, I use [which-key](https://github.com/folke/which-key.nvim),
|
||||||
a plugin that displays available keybindings as you type.
|
a plugin that displays available keybindings as you type.
|
||||||
I've been using vim for almost a decade, including a long time without which-key,
|
I've been using vim for almost a decade, including a long time without which-key,
|
||||||
so its not like I never learned the keybindings, but I still find which-key useful.
|
so its not like I never learned the keybindings, but I still find which-key useful.
|
||||||
|
@ -225,26 +225,27 @@ Naturally, when you go months without using certain parts of a program, you tend
|
||||||
Which-key solves that handily, by offering quick, non-intrusive reminders of what is available.
|
Which-key solves that handily, by offering quick, non-intrusive reminders of what is available.
|
||||||
Here's what my which-key config looks like:
|
Here's what my which-key config looks like:
|
||||||
|
|
||||||
![Which-key.nvim](nvim_which_key.png)
|
![Which-key.nvim, showing contextual key hints](nvim-which-key.png)
|
||||||
|
|
||||||
Now, which-key and its like have been around for a while,
|
Now, which-key and its like have been around for a while,
|
||||||
but other TUI programs have integrated contextual hints without the need for a plugin.
|
but other TUI programs have integrated contextual hints without the need for a plugin.
|
||||||
The two that I am aware of are zellij and helix.
|
The two that I am aware of are zellij and helix.
|
||||||
|
|
||||||
![Helix's contextual hint](helix_contextual_hint.png)
|
![Helix's contextual hint](helix-contextual-hint.png)
|
||||||
|
|
||||||
Helix both has autocompletion for its built in command line and a contextual hint that appears when you press the first key in a multi key combo.
|
Helix both has autocompletion for its built in command line and a contextual hint that appears when you press the first key in a multi key combo.
|
||||||
This drastically helps both new and experienced users learn and remember keybinds without making the editor any less powerful.
|
This drastically helps both new and experienced users learn and remember keybinds without making the editor any less powerful.
|
||||||
|
|
||||||
|
![Zellij's hint bar](zellij-hints.png)
|
||||||
|
|
||||||
Zellij has a bottom bar displaying keybindings available in the current mode.
|
Zellij has a bottom bar displaying keybindings available in the current mode.
|
||||||
This has proven invaluable for me, as I don't use a terminal multiplexer much
|
This has proven invaluable for me, as I don't use a terminal multiplexer much
|
||||||
(On GUI systems, I use the window manager for managing multiple terminals), and as such tend to forget the keybinds.
|
(On GUI systems, I use the window manager for managing multiple terminals), and as such tend to forget the keybinds.
|
||||||
|
Though it does take up screen space, and a person who used Zellij every day would most likely disable it,
|
||||||
<!-- look at zellij and helix and their built in keymap cheatsheets-->
|
the hints bar is more than worth it for new and occasional users.
|
||||||
|
|
||||||
### Common usecases should be easy
|
### Common usecases should be easy
|
||||||
|
|
||||||
<!-- look at sd, rg, and fd-->
|
|
||||||
Where possible, documentation should not even be required for the most common use cases.
|
Where possible, documentation should not even be required for the most common use cases.
|
||||||
Whenever I want to use `find`, I almost always have to first look at the man page,
|
Whenever I want to use `find`, I almost always have to first look at the man page,
|
||||||
as I don't use it quite often enough to memorize it.
|
as I don't use it quite often enough to memorize it.
|
||||||
|
@ -290,15 +291,34 @@ However, Just was designed from the outset to be a command runner, and as a resu
|
||||||
it is much easier to pick up the just language and make a quick set of commands that can be run.
|
it is much easier to pick up the just language and make a quick set of commands that can be run.
|
||||||
By leaving behind the old tool, a new tool can be made that better fits the tasks that people use the tool for.
|
By leaving behind the old tool, a new tool can be made that better fits the tasks that people use the tool for.
|
||||||
|
|
||||||
## The trendsetter
|
|
||||||
|
|
||||||
<!-- did neovim kick this all off?-->
|
|
||||||
|
|
||||||
## The languages
|
## The languages
|
||||||
|
|
||||||
<!-- most of the new tools are written in rust and go.-->
|
Now, looking back at that table, one might notice a pattern in the languages used.
|
||||||
|
While almost all tools before 2010 or so were written in C,
|
||||||
|
the language selection after that are dominated by Rust and Go.
|
||||||
|
|
||||||
<!-- rusts clap and gos cobra, CLI argument parsing libraries, help with this.-->
|
Of course, there are exceptions to the pattern.
|
||||||
|
TeX was written in pascal, Neovim kept C as its primary language,
|
||||||
|
and there is the occasional new tool written in C or C++.
|
||||||
|
But there is still a clear pattern in the language choice for newly written tools.
|
||||||
|
|
||||||
|
Now, why do you think that pattern has changed?
|
||||||
|
And have these new languages led to an increase in the number of tools being written?
|
||||||
|
I think so, and I don't actually think its the languages itself, so much as the libraries surrounding them.
|
||||||
|
|
||||||
|
Both Rust and Go have healthy package ecosystems surrounding interaction with the terminal.
|
||||||
|
Rust has Clap for argument parsing, TODO for dealing with ANSI escape codes,
|
||||||
|
and Ratatui and TODO for making TUIs.
|
||||||
|
Go has a similar set of tools, with Cobra for CLI argument parsing, TODO
|
||||||
|
|
||||||
|
These libraries combined with the extra ergonomics offered by the languages themselves,
|
||||||
|
make the barrier to entry lower,
|
||||||
|
allowing for more people to experiment with the design and ergonomics of CLI tools.
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
<!-- emphasize that the new tools are not 'better' just because they are new,
|
||||||
|
but because they take the old tools and learn what did and did not work for them. -->
|
||||||
|
|
||||||
## Appendix: the tools
|
## Appendix: the tools
|
||||||
|
|
Before Width: | Height: | Size: 217 KiB After Width: | Height: | Size: 217 KiB |
BIN
content/posts/cli-renaissance/zellij-hints.png
Normal file
After Width: | Height: | Size: 77 KiB |
Before Width: | Height: | Size: 7.7 KiB After Width: | Height: | Size: 7.7 KiB |
Before Width: | Height: | Size: 1.9 MiB After Width: | Height: | Size: 1.9 MiB |
|
@ -3,7 +3,7 @@ title = "Building My New Keyboard."
|
||||||
date = 2024-02-06T15:01:28-06:00
|
date = 2024-02-06T15:01:28-06:00
|
||||||
draft = false
|
draft = false
|
||||||
[cover]
|
[cover]
|
||||||
image = "keyboard_with_case"
|
image = "keyboard-with-case"
|
||||||
+++
|
+++
|
||||||
|
|
||||||
I've been using a split keyboard at home now for several years
|
I've been using a split keyboard at home now for several years
|
||||||
|
@ -36,7 +36,7 @@ I did ruin one switch by letting a leg getting hot enough to melt the housing pl
|
||||||
and desoldering it was unexpectedly difficult,
|
and desoldering it was unexpectedly difficult,
|
||||||
but not every build can be mistake free, right?
|
but not every build can be mistake free, right?
|
||||||
|
|
||||||
![The finished keyboard](finished_keyboard.jpg)
|
![The finished keyboard](finished-keyboard.jpg)
|
||||||
|
|
||||||
Flashing QMK was uneventful, working exactly as the [QMK docs](https://github.com/qmk/qmk_firmware/tree/master/keyboards/ferris/sweep) for the Ferris Sweep suggested.
|
Flashing QMK was uneventful, working exactly as the [QMK docs](https://github.com/qmk/qmk_firmware/tree/master/keyboards/ferris/sweep) for the Ferris Sweep suggested.
|
||||||
I would, however, recommend flashing the micros *before* doing any soldering,
|
I would, however, recommend flashing the micros *before* doing any soldering,
|
Before Width: | Height: | Size: 1.2 MiB After Width: | Height: | Size: 1.2 MiB |
Before Width: | Height: | Size: 80 KiB After Width: | Height: | Size: 80 KiB |
Before Width: | Height: | Size: 99 KiB After Width: | Height: | Size: 99 KiB |
Before Width: | Height: | Size: 60 KiB After Width: | Height: | Size: 60 KiB |
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 72 KiB |
Before Width: | Height: | Size: 58 KiB After Width: | Height: | Size: 58 KiB |
Before Width: | Height: | Size: 69 KiB After Width: | Height: | Size: 69 KiB |
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 68 KiB |
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 68 KiB |
|
@ -1,30 +1,37 @@
|
||||||
+++
|
+++
|
||||||
title = "Syncthing"
|
title = "Moving away from Nextcloud"
|
||||||
date = 2022-03-10T01:33:59-05:00
|
date = 2024-08-05T01:33:59-05:00
|
||||||
draft = true
|
draft = true
|
||||||
+++
|
+++
|
||||||
|
|
||||||
|
## Nextcloud
|
||||||
|
|
||||||
|
While Nextcloud had a lot of features and provides a nice web interface,
|
||||||
|
(I got a lot of use out of Nextcloud's caldav server)
|
||||||
|
I kept running into problems and limitations with it.
|
||||||
|
One thing is maintenance. Of my entire homelab,
|
||||||
|
I easily spent the most time troubleshooting and fixing Nextcloud,
|
||||||
|
sometimes having to reboot the VM multiple times per week.
|
||||||
|
Additionally, I've ran into a few annoying limitations,
|
||||||
|
such as the sever crashing if you view a folder with too many files in the web interface or apps.
|
||||||
|
Nextcloud does a lot of things, and does things very well,
|
||||||
|
but I would not describe it as a rock solid piece of software.
|
||||||
|
|
||||||
|
Due to this, during our [move to germany](../moving-to-germany) and the resuling reorganization of the homelab,
|
||||||
|
I decided to *finally* ditch Nextcloud, after talking about it for months.
|
||||||
|
|
||||||
|
## Syncthing
|
||||||
|
|
||||||
[Syncthing](https://syncthing.net/) is one of the best file syncing tools in existence,
|
[Syncthing](https://syncthing.net/) is one of the best file syncing tools in existence,
|
||||||
and I don't say that lightly.
|
and I don't say that lightly.
|
||||||
Syncthing is a distributed, peer to peer file syncing service.
|
Syncthing is a distributed, peer to peer file syncing service.
|
||||||
This means that it doesn't rely on a central, always online server ran by you or someone else,
|
This means that it doesn't rely on a central, always online server ran by you or someone else,
|
||||||
but that your devices directly send files between themselves whenever they are online at the same time.
|
but that your devices directly send files between themselves whenever they are online at the same time.
|
||||||
|
I used Syncthing to replace Nextclouds file syncing.
|
||||||
|
|
||||||
## Syncthing vs Nextcloud
|
### Syncthing vs Nextcloud
|
||||||
|
|
||||||
I use both Syncthing and Nextcloud for data storage and syncing,
|
Unlike Nextcloud, Syncthing has no web file manager,
|
||||||
and while Nextcloud has a lot of features and provides a nice web interface,
|
|
||||||
(I get a lot of use out of Nextcloud's caldav server)
|
|
||||||
I keep running into problems and limitations with it.
|
|
||||||
One thing is maintenance. Of my entire homelab,
|
|
||||||
I easily spend the most time troubleshooting and fixing Nextcloud,
|
|
||||||
sometimes having to reboot the VM multiple times per week.
|
|
||||||
Additionally, I've ran into a few annoying limitations more than once,
|
|
||||||
such as the sever crashing if you view a folder with too many files in the web interface or apps.
|
|
||||||
Nextcloud does a lot of things, and does things very well,
|
|
||||||
but I would not describe it as a rock solid piece of software.
|
|
||||||
|
|
||||||
Syncthing, on the other hand, has no web file manager,
|
|
||||||
does not do caldav or any of the other million things you can do with Nextcloud apps,
|
does not do caldav or any of the other million things you can do with Nextcloud apps,
|
||||||
and requires setup on both ends to setup a syncing connection.
|
and requires setup on both ends to setup a syncing connection.
|
||||||
In short, Syncthing does only one thing.
|
In short, Syncthing does only one thing.
|
||||||
|
@ -35,12 +42,7 @@ Even with a device like my phone,
|
||||||
constantly loosing and regaining network access,
|
constantly loosing and regaining network access,
|
||||||
files have synced perfectly, every time.
|
files have synced perfectly, every time.
|
||||||
|
|
||||||
While all my files are stored on my Nextcloud server,
|
### Distributed?
|
||||||
for folders with large number of files,
|
|
||||||
I only have one device syncing with Nextcloud,
|
|
||||||
and all other devices use Syncthing to sync with the device connected to Nextcloud.
|
|
||||||
|
|
||||||
## Distributed?
|
|
||||||
|
|
||||||
With Dropbox or Google drive, files are not sent directly between your devices,
|
With Dropbox or Google drive, files are not sent directly between your devices,
|
||||||
but are sent from one device to the server,
|
but are sent from one device to the server,
|
||||||
|
@ -52,11 +54,33 @@ Instead, devices all connect to each other, sending changes made on one device t
|
||||||
This makes all of your devices into a cluster, where no device has to always be online,
|
This makes all of your devices into a cluster, where no device has to always be online,
|
||||||
but any devices that happen to be online at the same time synchronize while they can.
|
but any devices that happen to be online at the same time synchronize while they can.
|
||||||
|
|
||||||
## Introducers
|
### Introducers
|
||||||
|
|
||||||
If you have a lot of devices, making sure every device is connected to every other device can become a hassle.
|
If you have a lot of devices, making sure every device is connected to every other device can become a hassle.
|
||||||
Thankfully, Syncthing has the concept of 'introducer' devices.
|
Thankfully, Syncthing has the concept of 'introducer' devices.
|
||||||
In short, With an introducer, you only need to connect your devices to the introducer,
|
In short, With an introducer, you only need to connect your devices to the introducer,
|
||||||
and the introducer will make connections between any devices that share the same folder with the introducer.
|
and the introducer will make connections between any devices that share the same folder with the introducer.
|
||||||
This is very useful, for example, to enable for a always online storage server,
|
This is very useful, for example, to enable for a always online storage server,
|
||||||
an architecture that I plan to implement in the future if I ever get around to moving away from Nextcloud.
|
and it is the architecture that I used to fully replace nextcloud.
|
||||||
|
|
||||||
|
## File Manager
|
||||||
|
|
||||||
|
While Syncthing is great for file syncing between devices,
|
||||||
|
we also wanted to be able to acess a web interface to upload, download, and view files on devices not in our Syncthing network.
|
||||||
|
|
||||||
|
TODO
|
||||||
|
|
||||||
|
## Radicale
|
||||||
|
|
||||||
|
The final function my family and I used nextcloud for was calander and todo list syncing.
|
||||||
|
This was done over Nextclouds CalDav server,
|
||||||
|
using DavX^5 as a mobile client, and Thunderbirds Lightning plugin as a desktop client.
|
||||||
|
This was almost a more important function than filesyncing, as my wife and I use it to organize our calanders,
|
||||||
|
Keep shopping lists, chore lists, lists of movies to watch, lists of long term projects, etc.
|
||||||
|
(we *really* used the hell out of todo lists.)
|
||||||
|
|
||||||
|
For this, we used [Radicale](https://radicale.org/v3.html). Radicale *only* does CalDav and CardDav syncing, nothing else,
|
||||||
|
but between Syncthing and FileManager, thats all we needed it to do to complete the nextcloud replacement.
|
||||||
|
Installation was incredibly simple, thanks to the existence of a prebuilt NixOs module for it.
|
||||||
|
After about an hour of research and work, I had a Radicale server up and running on my Hetzner node,
|
||||||
|
and had exported all of our calanders from Nextcloud and imported them into Radicale.
|
7
content/posts/moving-to-germany/index.md
Normal file
|
@ -0,0 +1,7 @@
|
||||||
|
+++
|
||||||
|
title = "Moving To Germany"
|
||||||
|
date = 2024-07-27T17:10:32-05:00
|
||||||
|
draft = true
|
||||||
|
+++
|
||||||
|
|
||||||
|
## TODO
|
5
justfile
|
@ -4,7 +4,12 @@ preview:
|
||||||
USER:='root'
|
USER:='root'
|
||||||
HOST:='gabevenberg.com'
|
HOST:='gabevenberg.com'
|
||||||
DIR:='/var/www/gabevenberg.com'
|
DIR:='/var/www/gabevenberg.com'
|
||||||
|
DRAFTDIR:='/var/www/draft.gabevenberg.com'
|
||||||
|
|
||||||
deploy:
|
deploy:
|
||||||
hugo --minify
|
hugo --minify
|
||||||
rsync -rvz --delete public/ {{USER}}@{{HOST}}:{{DIR}} # this will delete everything on the server that's not in the local public folder
|
rsync -rvz --delete public/ {{USER}}@{{HOST}}:{{DIR}} # this will delete everything on the server that's not in the local public folder
|
||||||
|
|
||||||
|
deploy-preview:
|
||||||
|
hugo --minify --buildDrafts --buildFuture
|
||||||
|
rsync -rvz --delete public/ {{USER}}@{{HOST}}:{{DRAFTDIR}} # this will delete everything on the server that's not in the local public folder
|
||||||
|
|