#linux

Firecracker is an open source virtualization technology purpose-built for creating and managing secure, multi-tenant container and function-based services. It enables you to deploy workloads in lightweight virtual machines (microVMs) that provide enhanced security and workload isolation over traditional VMs, while enabling the speed and resource efficiency of containers.

For teams that want the capabilities of Firecracker without managing infrastructure, Lambda MicroVMs is a fully managed serverless compute primitive. Built on the same Firecracker virtualization powering 15 trillion+ monthly Lambda function invocations, it provides isolated sandboxes with near-instant launch, state persistence for up to 8 hours, and automatic suspend/resume. No capacity planning required.

TL;DR: Niklas and I built a fully OpenGL ES 3.0 compliant GPU driver for the M4 Mac Mini and MacBook Neo in about a month, a process which normally takes years. Here is Chrome and Firefox running WebGL on the M4 Mac Mini with working compositing:

Ninety-nine percent of the time a simple /goal resume or “keep going” was enough to have the LLM continue (which also shows the restrictions were overly aggressive), but they still broke my unattended workflow. I coded the fastest, dumbest possible solution: a daemon that takes a screenshot every minute, diffs it against the last screenshot, and if identical (because Codex stopped making progress) types /goal resume. I accidentally left it on in some group chats

Requires=

Similar to Wants=, but declares a stronger requirement dependency. Dependencies of this type may also be configured by adding a symlink to a .requires/ directory accompanying the unit file.

If this unit gets activated, the units listed will be activated as well. If one of the other units fails to activate, and an ordering dependency After= on the failing unit is set, this unit will not be started. Besides, with or without specifying After=, this unit will be stopped (or restarted) if one of the other units is explicitly stopped (or restarted).

Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, ConditionPathIsSymbolicLink=, … — see below) do not cause the start job of a unit with a Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not propagated to units having a Requires= dependency. Use the BindsTo= dependency type together with After= to ensure that a unit may never be in active state without a specific other unit also in active state (see below).

Added in version 201.

Cockpit is a web-based graphical interface for servers, intended for everyone, especially those who are:

Thanks to Cockpit intentionally using system APIs and commands, a whole team of admins can manage a system in the way they prefer, including the command line and utilities right alongside Cockpit.

Cockpit makes Linux discoverable. You don’t have to remember commands at a command-line.

See your server in a web browser and perform system tasks with a mouse. It’s easy to start containers, administer storage, configure networks, and inspect logs. Basically, you can think of Cockpit like a graphical “desktop interface”, but for individual servers.

Cockpit uses APIs that already exist on the system. It doesn’t reinvent subsystems or add a layer of its own tooling.

By default, Cockpit uses your system’s normal user logins and privileges. Network-wide logins are also supported through single-sign-on and other authentication techniques.

Cockpit itself doesn’t eat resources or even run in the background when you’re not using it. It runs on demand, thanks to systemd socket activation.

Ghostty is a fast, feature-rich, and cross-platform terminal emulator that uses platform-native UI and GPU acceleration.

Rclone is a command-line program to manage files on cloud storage. It is a feature-rich alternative to cloud vendors' web storage interfaces. Over 70 cloud storage products support rclone including S3 object stores, business & consumer file storage services, as well as standard transfer protocols.

Rclone has powerful cloud equivalents to the unix commands rsync, cp, mv, mount, ls, ncdu, tree, rm, and cat. Rclone's familiar syntax includes shell pipeline support, and --dry-run protection. It is used at the command line, in scripts or via its API.

multi-pane terminal:

tmux is a terminal multiplexer. It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal.

• Ctrl + B + >: Open pane actions menu

Navigation:

• Ctrl + B + %: Split the current pane with a vertical line to create a horizontal layout
• Ctrl + B + ": Split the current with a horizontal line to create a vertical layout
• Ctrl + B + ➡️: Switch to pane to the direction (works with ⬅️➡️⬇️⬆️)
• Ctrl + B + z: Zoom the current pane (make it maximized or minimized)

Sessions: tmux starts a session that lives in the background like screen does. So if ssh deteaches, the session lives on until reboot or until it's killed.

• tmux new -s mysession: Allows naming a session -otherwise a random session name is generated.
• tmux ls: List sessions.
• tmux attach -t mysession: Reattach to session.
• tmux kill-session -t mysession: Clean up when done.
• Ctrl-B D: Manually detach from a running session.

Command Mode:

• Ctrl + B + :: Enter command mode.

Commands:

• :resize-pane -D|-U|-L|-R <number>: -D (down), -U (up), -L (left), or -R (right). <number> is the number of "cells" i.e. character grid rows/columns.
  • NOTE: To resize a pane in tmux, press Ctrl+b followed by Ctrl and the arrow keys to adjust the size by one cell.