🚚 The bookmarklet has moved to https://github.com/bramus/mastodon-profile-redirect/
---Utility for keymap creation. | |
---@param lhs string | |
---@param rhs string|function | |
---@param opts string|table | |
---@param mode? string|string[] | |
local function keymap(lhs, rhs, opts, mode) | |
opts = type(opts) == 'string' and { desc = opts } | |
or vim.tbl_extend('error', opts --[[@as table]], { buffer = bufnr }) | |
mode = mode or 'n' | |
vim.keymap.set(mode, lhs, rhs, opts) |
.PHONY: hooks | |
hooks: | |
git config --local core.hooksPath $(shell pwd)/.githooks |
With wf-recorder it is possible to record one output. When ffmpeg is compiled with sdl support, then it is possible to use "sdl" as the muxer and replay the recorded video instead of writing it to a file.
local fmt = string.format | |
-- Iterator that splits a string o a given delimiter | |
local function split(str, delim) | |
delim = delim or "%s" | |
return string.gmatch(str, fmt('[^%s]+', delim)) | |
end | |
-- Find the proper directory separator depending | |
-- on lua installation or OS. |
Locking down a linux machine is getting easier by the day. Recent advancements in systemd-boot have enabled a host of features to help users ensure that their machines have not been tampered with. This guide provides a walkthrough of how to turn on many of these features during installation, as well as reasoning for why certain features help improve security.
The steps laid out below draw on a wide variety of existing resources, and in places I'll point to them rather than attempt to regurgitate full explanations of the various security components. The most significant one, which I highly encourage everyone to read, is Rod Smith's site about secure boot, which is the most comprehensive and cogent explanation of UEFI, boot managers and boot loaders, and secure boot. Another incredibly useful resources is Safeboot, which encapsulates many of the setup steps below in a Debian application.
body, textarea, input, button { | |
font-size: 11px; | |
} | |
a { | |
color: green; | |
} | |
p>a { | |
color: green !important; |
:root { | |
--font-family: system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; | |
--body-color: rgba(255, 255, 255, 0.7); | |
--body-background: #282c34; | |
--header-link-color: #9b9494; | |
--header-active-link-color: #d19a66; | |
--input-border: 1px solid #2c384e; | |
--input-background: #2c384e; | |
--input-placeholder-color: #888; | |
--input-focus-border-color: #d19a66; |
The open source community depends on the efforts of a small group of volunteers relative to the number of users. In order to make the most of contributors' time, here is some advice for asking “good questions”. This is largely paraphrased from this article by Eric Steven Raymond and Rick Moen, with edits for brevity and tone. If you have the time (and tolerance), I strongly recommend reading that article over this one. Let's start with the procedure.
- Try to find an answer by searching the archives of the issue-tracker, IRC, matrix-room, discord, forum or mailing list you plan to post to.
- Try to find an answer by searching the Web.
- Try to find an answer by reading the manual.
- Try to find an answer by reading a FAQ.
- Try to find an answer by inspection or experimentation.