I've made a similar library called bash-term[1], which is similar, but only has functions for lower-level operations, like moving the cursor to the end of the line, etc. It's also cleaner and has almost no global variables.
This is the kind of stuff I describe in my semantic hotkeys[1] piece. There isn't a really good way to define hotkeys for web apps across websites. In lieu of a browser spec (for now), or a non-normative recommendation, there needs to be convention under no uncertain terms about which keys do what.
We already have Ctrl+K and Ctrl+/, I think it's time to formalize these conventions, and more! There is a gap of semantic interoperability across websites that needs some fixin'.
Ctrl+K is often used to perform any kind of action. On Discord, Slack, GitHub, etc. let you perform any action with this hotkey. It's also a generic search, as website searches implemented with Algolia use this by default.
Ctrl+/ is usually used to show all the keyboard shortcuts, or at least the most common ones. Usable on Discord, Slack, VSCode, etc.
I'd say bashrc and profile and friends are one of the few examples in which using hardcoded paths is OK. Same with SSH, GPG, and PAM.
But when people are talking about compliance, and hardcoding very few people are talking about those applications - there are hundreds of other applications do the wrong thing, and some scripts hardcode things as a result.
What are you talking about? When people say the "XDG spec", they are usually referring to the XDG Base Directory Specification, but there are other specifications from XDG - are you talking about a different one?
Because the XDG Base Directory Specification does not dictate about how files should be saved - whether in Pictures/, Documents/, or anything else...
Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition)
The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable.
It's been somewhat frustrating for distributions to install GRUB, hijacking the previous prioritized boot PE, and have entries for other installed Linux distributions missing.
> Over the years, I've been pleased to see that more and more distributions are writing their disk images and the like to the ESP. (Previously, dd'd USB images for distro installing _required_ the creation of a /boot partition)
> The logical next step would be to standardize everything through systemd, and ensure all boot images are autodiscoverable and automatically bootable.
As much as I like systemd, I think it's not necessary here: I have a EFISP that's about 16G: it also contains a few .ISO that can be loaded in case system maintenance or a full reinstall is needed. GrubFM and others like Ventoy let you boot directly on say Windows11-22H2.ISO, Ubuntu22-10.iso etc.
When I buy a new drive or computer, I just copy this partition: it's much faster than playing with thumbdrives or PXE Boot.
One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails AND it can take quite some time and effort to recover even if you're technically familiar with the boot process since there are no standardised procedures for duplicating the ESP or its content.
A second issue is that since FAT doesn't have permissions any user ID on the system can potentially mount, read, and possibly write to the ESP.
A separate (possibly encrypted) /boot/ file-system can be hosted on a RAID device or even loaded over the network.
With a 'regular' boot process (UEFI > ESP boot-loader core > LUKS unlock > /boot/ boot-loader 2nd stage > /boot/ kernel+initrd > root-fs) the only thing lost is the boot-loader core, which can quickly be switched for a USB boot, set options appropriately to find and use /boot/, and for the boot process to use alternate RAID device(s) and continue with a degraded boot.
On UEFI most distros now do not use os-prober to populate GRUB's own menu with other bootable OSes (GRUB_DISABLE_OS_PROBER=yes) since it expects those OSes to have added themselves to the UEFI boot menu.
As for replacing the default boot entry, this is caused by efibootmgr not GRUB. GRUB calls efibootmgr with "--create|-c" which adds a new BOOTNUM and puts it at the head of the list.
GRUB could be taught a new option that then does several efibootmgr operations: parsing text output of "efibootmgr" to get current boot order, --delete-bootorder then --bootorder A,B,C,OS to ensure OS is added last.
That is obviously fragile so best approach would be to teach efibootmgr a new option --create-append|-C that adds the new entry to the end of BootOrder and then simply teach GRUB a new variable GRUB_UEFI_BOOTORDER_FIRST=yes|no to use efibootmgr --create-append.
As someone who has run /boot on raid1 for years, I think his idea in the article of keeping them synchronised in userspace at update time (ie rsync) is better. There is no reason to need realtime raid1 kernelspace sync when /boot changes only monthly.
> One downside to storing these images on the (FAT) EFI System Partition is it is not possible to make it part of a software RAID device, so if the device the ESP is on dies suddenly, the boot fails
It is possible to make ESP part of MDRAID array of level 1 with metadata v1. True, the boot starts with single disk and only later Linux activates the array. So if your boot fails before that happens, reboot and try the other disk.
Or alternatively, don't set up MDRAID array for ESP, just have the ESP mirrored on all disks.
"don't set up MDRAID array for ESP, just have the ESP mirrored on all disks. "
Isn't that the entire point of utilising MD RAID-1 in the first place?
I've done as you suggest in years gone by with either metadata v0.9 or v1.0 (not v1.1 or v1.2) where the metadata is not at the start of the block device and therefore does not confuse a non-MDRAID-aware firmware or other OS.
OK now I get what you mean. In that case, one can reboot and select the other non-broken disk and the system will boot, with some hiccups due to degraded array, but it will boot.
This tool looks quite similar to Amie.so - which I use in conjunction with Todoist - do you have any major differentiating features? It seems like mainly there are more integrations
It seems unfortunate that the free plan is really just a 7 day trial, unless I misunderstood
Hello, feel free to reach out on the chat for more free trial if you need!
I didn't try Amie personally, but I agree that importing tasks automatically via integration is one of our differentiators. We put a lot of effort into creating a strong task management tool and we have a set of features to enhance planning. For example, we added rituals to plan our day, folders, labels, and sections to organize your tasks. On top of that, we offer a full calendar experience optimized for time blocking with features like "meet with", share availability, multiple time zones and customizable views
[1] https://github.com/bash-bastion/bash-term