Abe Estrada

Books

Fri, 20 Feb 2026 08:00:00 -0600

2026

Scrum - Jeff Sutherland
High Output Management - Andrew S. Grove
Staff Engineer - Will Larson
The Greatest Sentence Ever Written - Walter Isaacson
Hands-On Large Language Models - Jay Alammar

2025

The Coming Wave - Mustafa Suleyman
The Hackers Ethic - Pekka Himanen
The Elements of Marie Curie - Dava Sobel
Source Code - Bill Gates
Quantum Computing - Brian Clegg
Nexus - Yuval Noah Harari
A Vulnerable System - Andrew J. Stewart
Idea Man - Paul Allen
Revolutionary Algorithms - Torey Akers
Free Software, Free Society - Richard M. Stallman
Spam Nation - Brian Krebs
Stealth - Peter Westwick
The Quantum Labyrinth - Paul Halpern
Careless People - Sarah Wynn-Williams
Quantum Supremacy - Michio Kaku
Quantum Entanglement - Jed Brody
When the Moon Hits Your Eye - John Scalzi
The Vegetarian - Han Kang
Rare Tongues - Lorna Gibb
Heretic - Catherine Nixey
Crucial Conversations - Joseph Grenny
Between Two Rivers - Moudhy Al-Rashid
Constituent Service - John Scalzi
Buddhism for Beginners - Thubten Chodron
No Better Time - Molly Knight Raskin
La civilización del espectáculo - Mario Vargas Llosa
Jurassic Park - Michael Crichton
Pancho Villa - Paco Ignacio Taibo II
Armada - Ernest Cline
Never Lost Again - Bill Kilday
Empire of AI - Karen Hao
Fundamentals of Software Architecture - Mark Richards, Neal Ford
Software Architecture: The Hard Parts - Pramod Sadalage, Zhamak Dehghani
Digital Dharma - Deepak Chopra MD
Engineering Management for the Rest of Us - Sarah Drasner
Accelerate - Nicole Forsgren PhD
Hell Yeah or No - Derek Sivers
The Manager’s Path - Camille Fournier
An Elegant Puzzle - Will Larson
Thinking in Systems - Donella H. Meadows
Fundamentals of Data Engineering - Joe Reis
The Staff Engineer’s Path - Tanya Reilly

2024

Artificial Unintelligence — Meredith Broussard
Surfear el espacio-tiempo — Sergio de Régules & Miguel Alcubierre
En agosto nos vemos — Gabriel García Márquez
Filterworld — Kyle Chayka
Airbus A320 Filosofía operacional — Facundo Conforti
Burn Book — Kara Swisher
How to Make the Best Coffee at Home — James Hoffmann
Starter Villain — John Scalzi
The 37th Parallel — Ben Mezrich
The Great Bridge — David McCullough
Dark Wire — Joseph Cox
Pegasus — Laurent Richard & Sandrine Rigaud
The Wright Brothers — David McCullough
The Singularity Is Nearer — Ray Kurzweil
Gravitational Waves — Brian Clegg
Token Supremacy — Zachary Small
Just for Fun — Linus Torvalds & David Diamond
Fuego y Sangre — George R.R. Martin
Chip War - Chris Miller
Tracers in the Dark - Andy Greenberg
Cypherpunks - Julian Assange
We Were Yahoo! - Jeremy Ring
Mindf*ck - Christopher Wylie
How the Internet Happened - Brian McCullough

2023

Cinco Esquinas — Mario Vargas Llosa
The Big Short — Michael Lewis
The Man Who Solved the Market — Gregory Zuckerman
Like, Comment, Subscribe — Mark Bergen
The Woman Who Split the Atom — Marissa Moss
American Prometheus — Kai Bird & Martin J. Sherwin
And or Not — George Boole
Androids — Chet Haase
Dataclysm — Christian Rudder
Elon Musk — Walter Isaacson
Infinite Powers — Steven Strogatz
Your Face Belongs to Us — Kashmir Hill
Going Infinite — Michael Lewis
Extremely Online — Taylor Lorenz
Breaking Twitter — Ben Mezrich

2022

Algorithms to Live By — Tom Griffiths
Quantum Physics for Beginners — Darrell Ason
Dancing with Qubits — Robert S. Sutor
The Storyteller — Dave Grohl
The Pragmatic Programmer — David Thomas and Andrew Hunt
The Messenger — Peter Loftus
The Antisocial Network — Ben Mezrich
México, manual de usuario — Chumel Torres
Hackers — Steven Levy
Tao Te Ching — Lao Tzu
El Rey del Cash — Elena Chávez
Ultralearning — Scott Young

2021

The Code Breaker — Walter Isaacson
A Promised Land — Barack Obama
How to Avoid a Climate Disaster — Bill Gates
Caffeine — Michael Pollan
Epidemiology — Rodolfo Saracci
Working in Public — Nadia Eghbal
Leonardo da Vinci — Walter Isaacson
No Filter — Sarah Frier
A Thousand Brains — Jeff Hawkins
Born a Crime — Trevor Noah
El Mundo de Sofía — Jostein Gaarder
The Art Of War — Sun Tzu
The Science of Everyday Life — Marty Jopson

2019

Thanks a Thousand — A. J. Jacobs
Digital Minimalism — Cal Newport
Ask an Astronaut — Tim Peake
Cult of Dead Cow — Joseph Menn
Hunt for the Skinwalker — Colm A. Kelleher & George Knapp
The Flight — Dan Hampton
The Ride of a Lifetime — Robert Iger
Permanent Record — Edward Snowden
El Principe — Nicolas Maquiavelo
Slim — Osorno Diego Enrique
Four Futures — Peter Frase
The Plane That Wasn’t There — Jeff Wise

Windows Terminal & Nushell

Sun, 08 Feb 2026 22:00:00 -0700

Les voy a contar cómo terminé usando Nushell .

Por causas ajenas a mí, tengo que trabajar en este entorno:

256 GB de espacio en disco
16 GB de RAM
Windows 11

Solo necesito mis aplicaciones en la terminal y un navegador. Eso es todo para trabajar.

Empecé usando WSL 2 con Debian. Funcionaba muy bien: ZSH era rápido y cómodo. Pero el espacio en disco se volvió un problema, así que decidí desinstalarlo.

Después descargué Alacritty , pensando que la terminal de Windows era la lenta… pero no. El verdadero cuello de botella era PowerShell.

Así fue como probé Nushell. Para mi sorpresa (hasta ahora), es lo único que me ha funcionado bien dentro de mis limitaciones. Luego descubrí que no es POSIX-compliant y que fue creada por una ex empleada de Microsoft . Ahora tiene sentido que sea tan rápida en Windows.

La diferencia de incluso un segundo es muy notable. Además, incluye todas las herramientas básicas que uso, así que no creo que me cueste acostumbrarme.

En macOS y Linux seguiré usando ZSH, pero si no fuera por esta situación particular, nunca le habría dado una oportunidad a Nushell.

Minimal Arch Linux

Sun, 28 Dec 2025 00:00:00 -0700

Desde que reparé mi vieja MacBook Pro , se ha convertido en mi máquina principal con Linux. Todo comenzó cuando descubrí los tiling window managers con i3 , del que me hice rápidamente fan. Luego, al migrar a Wayland , empecé a usar Sway , y ahora, gracias a una reciente actualización de Niri , este gestor de ventanas ya funciona en mi viejo equipo.

Actualmente, considero que esta es la configuración que más me ha gustado hasta la fecha.

Es una instalación base de Arch Linux con los siguientes paquetes:

niri
brightnessctl
firefox
fuzzel
kitty
mako
playerctl
swaylock
udiskie
xdg-utils

En mi búsqueda leí que varias personas recomiendan Noctalia como un shell para Wayland, pero la verdad es que no lo he visto necesario hasta ahora. Todo lo que necesito lo consigo directamente desde la terminal: uso Yazi como explorador de archivos, tdf o el navegador para ver archivos PDF, Kitty incluye un visualizador de imágenes mediante el comando kitten icat, y mpv para reproducir video y audio.

Escuchando música desde YouTube con mpv, navegando por algunas páginas de noticias y editando texto en la terminal, no he superado los 2 GB de uso de memoria RAM.

Después de muchos intentos, ajustes y experimentos, esta es, sin duda, la instalación mínima de Arch Linux que más me ha gustado. Es ligera, funcional y se adapta perfectamente a lo que realmente uso: la terminal, un buen gestor de ventanas y unas pocas herramientas bien elegidas. A veces, menos es más.

Nuevo Método HTTP Query →

Thu, 20 Nov 2025 19:00:00 -0700

TL;DR Es GET con “body”

El método HTTP QUERY es un método de solicitud seguro e idempotente que permite enviar consultas complejas como contenido de la solicitud en lugar de codificarlas en la URI. Este método proporciona una solución entre GET y POST, ofreciendo las ventajas de ambos y garantizando al mismo tiempo que la solicitud sea segura e idempotente. El método QUERY también permite a los servidores asignar URI a las consultas o a los resultados de las consultas para su posterior uso.

How Complex Systems Fail →

Thu, 23 Oct 2025 15:40:00 -0600

Excelente ensayo del Dr. Richard I. Cook sobre como las fallas en sistemas complejos son inherentes a la naturaleza de estos y sobre como nunca hay una única falla, sino una reacción en cadena de múltiples fallas, que desencadenan en la catástrofe de estos sistemas.

Todo esto con relación sobre la pasada falla que tuvieron los servicios de AWS en la región us-east-1 y la explicación en su postmortem .

Principios SOLID y React

Wed, 15 Oct 2025 11:00:00 -0600

La aplicación de los principios SOLID en React ayuda a escribir código fácil de mantener, escalable y comprobable. Aunque SOLID se diseñó originalmente para la programación orientada a objetos, muchas de sus ideas se adaptan bien a la arquitectura basada en componentes de React.

1. Single Responsibility Principle (SRP)

Un componente (o función/clase) solo debe tener una razón para cambiar.

Modo incorrecto:

const UserProfile = () => {
 const [user, setUser] = useState<User | null>(null);
 const [name, setName] = useState("");
 const [email, setEmail] = useState("");

 useEffect(() => {
 fetchUser().then(setUser);
 }, []);

 const validateEmail = (email: string) => /\S+@\S+\.\S+/.test(email);

 const handleSubmit = () => {
 if (!validateEmail(email)) {
 alert("Invalid email");
 return;
 }
 updateUser({ name, email });
 };

 return (
 <div>
 <h1>{user?.name}</h1>
 <input value={name} onChange={e => setName(e.target.value)} />
 <input value={email} onChange={e => setEmail(e.target.value)} />
 <button onClick={handleSubmit}>Save</button>
 </div>
 );
};

Solución: Dividir responsabilidades

// 1. Data fetching
const useUser = () => {
 const [user, setUser] = useState<User | null>(null);
 useEffect(() => {
 fetchUser().then(setUser);
 }, []);
 return user;
};

// 2. Validation logic
const useEmailValidation = () => {
 const validate = (email: string) => /\S+@\S+\.\S+/.test(email);
 return { validate };
};

// 3. UI Component
interface UserProfileFormProps {
 onSave: (data: { name: string; email: string }) => void;
}
const UserProfileForm: React.FC<UserProfileFormProps> = ({ onSave }) => {
 const [name, setName] = useState("");
 const [email, setEmail] = useState("");
 const { validate } = useEmailValidation();

 const handleSubmit = () => {
 if (!validate(email)) {
 alert("Invalid email");
 return;
 }
 onSave({ name, email });
 };

 return (
 <div>
 <input value={name} onChange={e => setName(e.target.value)} />
 <input value={email} onChange={e => setEmail(e.target.value)} />
 <button onClick={handleSubmit}>Save</button>
 </div>
 );
};

// 4. Main container
const UserProfile = () => {
 const user = useUser();

 const handleSave = (data: { name: string; email: string }) => {
 updateUser(data);
 };

 if (!user) return <div>Loading...</div>;

 return (
 <div>
 <h1>{user.name}</h1>
 <UserProfileForm onSave={handleSave} />
 </div>
 );
};

Cada parte tiene una responsabilidad: obtención de datos, validación, interfaz de usuario u orquestación.

2. Open/Closed Principle (OCP)

Los componentes deben estar abiertos a la ampliación, pero cerrados a la modificación.

Modo incorrecto:

const Notification = ({ type }: { type: "success" | "error" | "warning" }) => {
 let color = "gray";
 if (type === "success") color = "green";
 else if (type === "error") color = "red";
 else if (type === "warning") color = "orange";

 return <div style={{ color }}>{type} message</div>;
};

Para añadir un nuevo tipo es necesario modificar este componente.

Solución: Utilizar estrategia o configuración

const notificationStyles: Record<string, React.CSSProperties> = {
 success: { color: "green" },
 error: { color: "red" },
 warning: { color: "orange" },
 info: { color: "blue" }, // easily extensible
};

interface NotificationProps {
 type: keyof typeof notificationStyles;
}

const Notification: React.FC<NotificationProps> = ({ type }) => {
 return <div style={notificationStyles[type]}>{type} message</div>;
};

Se puede ampliar el comportamiento sin cambiar el componente.

3. Liskov Substitution Principle (LSP)

Los subtipos (por ejemplo, componentes o hooks) deben ser sustituibles por sus tipos base.

En React, esto suele aplicarse a los props de los componentes o a los hooks personalizados.

Modo incorrecto:

interface ButtonProps {
 variant: "primary" | "secondary";
 onClick: () => void;
}

const PrimaryButton: React.FC<ButtonProps> = ({ onClick }) => (
 <button className="primary" onClick={onClick} />
);

const DestructiveButton: React.FC<ButtonProps> = ({ onClick }) => (
 <button className="danger" onClick={onClick} /> // ignores variant!
);

Si se sustituye PrimaryButton por DestructiveButton, el comportamiento cambia de forma inesperada.

Solución: Respetar el contrato.

const ThemedButton: React.FC<ButtonProps> = ({ variant, onClick }) => {
 const className = variant === "primary" ? "primary" : "secondary";
 return <button className={className} onClick={onClick} />;
};

// Or a more flexible interface
interface FlexibleButtonProps {
 theme: "primary" | "secondary" | "danger";
 onClick: () => void;
}

Cualquier componente que implemente la misma interfaz se comporta de manera coherente.

4. Interface Segregation Principle (ISP)

No obligues a los clientes a depender de interfaces que no utilizan.

En React, esto significa evitar los props excesivos.

Modo incorrecto:

interface UserCardProps {
 user: User;
 onEdit?: () => void;
 onDelete?: () => void;
 showActions?: boolean;
 isEditable?: boolean;
 isAdminView?: boolean;
 // ... 10 more optional props
}
const UserCard: React.FC<UserCardProps> = (props) => {/* complex logic */};

La mayoría de los usos solo necesitan user.

Solución: Dividir en componentes específicos.

// Minimal version
const SimpleUserCard: React.FC<{ user: User }> = ({ user }) => (
 <div>{user.name}</div>
);

// With actions
const EditableUserCard: React.FC<
 { user: User; onEdit: () => void; onDelete: () => void }
> = ({ user, onEdit, onDelete }) => (
 <div>
 <SimpleUserCard user={user} />
 <button onClick={onEdit}>Edit</button>
 <button onClick={onDelete}>Delete</button>
 </div>
);

Los consumidores solo dependen de lo que necesitan.

5. Dependency Inversion Principle (DIP)

Los módulos de alto nivel no deben depender de detalles de bajo nivel. Dependen de abstracciones.

En React, esto significa desacoplar los componentes de los servicios concretos (por ejemplo, los clientes API).

const UserProfile = () => {
 const [user, setUser] = useState<User | null>(null);

 useEffect(() => {
 // Direct dependency on concrete implementation
 axios.get("/api/user").then(res => setUser(res.data));
 }, []);

 return <div>{user?.name}</div>;
};

Es difícil probar o cambiar la capa API.

Solución: Inyectar dependencias

// Abstraction
interface UserService {
 getUser(): Promise<User>;
}

// Concrete implementation
const ApiUserService: UserService = {
 getUser: () => axios.get("/api/user").then(res => res.data),
};

// For testing
const MockUserService: UserService = {
 getUser: () => Promise.resolve({ id: 1, name: "Test" }),
};

// Component depends on abstraction
interface UserProfileProps {
 userService: UserService;
}
const UserProfile: React.FC<UserProfileProps> = ({ userService }) => {
 const [user, setUser] = useState<User | null>(null);

 useEffect(() => {
 userService.getUser().then(setUser);
 }, [userService]);

 return <div>{user?.name}</div>;
};

// Usage
<UserProfile userService={ApiUserService} />;

Intercambiable, comprobable y desacoplado.

En resúmen:

SRP: Dividir componentes/hooks por interés (interfaz de usuario, lógica, datos)
OCP: Diseñar componentes que admitan extensiones (por ejemplo, mediante props u objetos de configuración).
LSP: Asegurarse de que los sustitutos de los componentes se comporten de manera coherente.
ISP: Evita la sobrecarga de propiedades; crea API de componentes específicas.
DIP: Inyectar servicios (clientes API, etc.) en lugar de codificarlos directamente.

Al aplicar SOLID en React, se crean aplicaciones más fáciles de probar, refactorizar y escalar, incluso en un marco de interfaz de usuario declarativo y funcional.

Astro Build Time

Thu, 02 Oct 2025 16:00:00 -0600

Tengo una página web construida con Astro y noté que el tiempo de compilación había aumentado a más de un minuto para generar aproximadamente 500 páginas estáticas.

Buscando optimizaciones, la recomendación general era clara: evitar ejecutar cualquier operación fetch dentro de las páginas que se generan dinámicamente o que utilizan la función getStaticPaths. Por ello, tomé la decisión de migrar estas páginas a la nueva API de “Content Collections” de Astro, una funcionalidad que no estaba disponible cuando el sitio fue creado.

El cambio realizado fue el siguiente:

-export const getStaticPaths = async () => {
- const res = await fetch(`${API_URL}/podcasts`, {
- headers: {
- "Content-Type": "application/json",
- },
- method: "GET",
- });
- const { podcasts } = await res?.json();
- return podcasts.map((podcast) => ({
- params: { podcast: podcast.id },
- }));
-};

+import { getCollection } from "astro:content";
+export async function getStaticPaths() {
+ const podcasts = await getCollection("podcasts");
+ return podcasts.map((podcast) => ({
+ params: { podcast: podcast.id },
+ }));
+}

Con esta migración, logré que las 500 páginas dejen de hacer llamadas individuales a la API.

Ahora, toda la información necesaria se captura una sola vez al inicio del proceso de build y se almacena en memoria. Esto garantiza que el tiempo de acceso sea casi inmediato y elimina los costos de latencia. El resultado fue una mejora drástica: el tiempo de carga pasó de 100 ms a solo 1 ms por página.

Esta optimización se refleja directamente en una reducción significativa del tiempo total de generación del sitio.

Fuente:

Content Collections

Protocolos para APIs

Sun, 24 Aug 2025 22:55:00 -0600

En el mundo del desarrollo de software, las APIs (Interfaces de Programación de Aplicaciones) son el puente que permite la comunicación entre diferentes sistemas. Sin embargo, elegir el protocolo adecuado para una API no es solo una decisión técnica: puede marcar la diferencia entre un sistema rápido, seguro y escalable, y uno que sufre de cuellos de botella y limitaciones funcionales.

Estos son los protocolos más comunes utilizados en APIs, cons sus ventajas, limitaciones y cuándo usar cada uno, basándonos en los fundamentos clave de una arquitectura eficiente.

HTTP y HTTPS: La base de las APIs web

HTTP (Hypertext Transfer Protocol) es el protocolo más utilizado en la web. Funciona bajo un modelo de solicitud respuesta: el cliente envía una solicitud y el servidor responde.

Características clave de HTTP:

Métodos comunes: GET (leer), POST (crear), PUT/PATCH (actualizar), DELETE (eliminar).
Códigos de estado: 200 (éxito), 400 (error del cliente), 500 (error del servidor).
Encabezados como Content-Type, Authorization, Cache-Control.
Sin embargo, HTTP por sí solo no es seguro. Aquí es donde entra HTTPS.

HTTPS = HTTP + TLS/SSL

HTTPS añade una capa de cifrado que protege los datos en tránsito. Sus beneficios incluyen:

Confidencialidad: los datos no pueden ser leídos por terceros.
Integridad: los datos no pueden ser alterados.
Autenticación: el cliente puede verificar la identidad del servidor.
Ventajas SEO: los motores de búsqueda favorecen sitios con HTTPS.

WebSockets: Comunicación en tiempo real

HTTP es excelente para solicitudes puntuales, pero no es ideal para aplicaciones en tiempo real, como chats, notificaciones o paneles de monitoreo.

Imagina un chat: si usas HTTP, el cliente debe hacer solicitudes constantes ("¿hay nuevos mensajes?") incluso cuando no hay novedades. Esto genera:

Alta latencia.
Uso innecesario de ancho de banda.
Mayor carga en el servidor.

WebSockets resuelve este problema estableciendo una conexión persistente y bidireccional entre cliente y servidor.

Cómo funciona:

El cliente inicia una “mano de mano” (handshake) con el servidor usando HTTP.
Una vez establecida, la conexión se convierte en un canal bidireccional.
El servidor puede enviar datos al cliente en cualquier momento, sin necesidad de que este lo solicite.

Ventajas:

Latencia mínima.
Ahorro de ancho de banda.
Ideal para aplicaciones en tiempo real.

AMQP: Mensajería confiable entre servicios

AMQP (Advanced Message Queuing Protocol) es un protocolo orientado a mensajería, común en entornos empresariales.

Funciona con un modelo de productor-consumidor y un broker de mensajes (como RabbitMQ):

El productor (por ejemplo, un sistema de pedidos) envía un mensaje a una cola.
El consumidor (por ejemplo, un sistema de notificaciones) lo procesa cuando esté disponible.

Beneficios de AMQP:

Desacoplamiento: los servicios no necesitan estar activos al mismo tiempo.
Garantía de entrega: los mensajes no se pierden si el consumidor está caído.
Escalabilidad: puedes tener múltiples consumidores procesando mensajes en paralelo.

gRPC: Alto performance para microservicios

Desarrollado por Google, gRPC es un framework de comunicación de alto performance que utiliza:

HTTP/2 como protocolo de transporte.
Protocol Buffers (protobuf) para serialización eficiente de datos.

Ventajas de gRPC:

Muy rápido y eficiente en el uso de recursos.
Soporta streaming bidireccional (cliente y servidor pueden enviar flujos de datos).
Ideal para comunicación entre microservicios en un entorno backend.

Conclusión

Los protocolos más comunes HTTP/HTTPS, WebSockets, AMQP y gRPC cubren alrededor del 90% de los casos de uso en APIs modernas. La clave está en entender sus fortalezas y elegir el que mejor se adapte a tu escenario.

Usa HTTP/HTTPS como predeterminado para APIs web.
Opta por WebSockets en aplicaciones en tiempo real.
Implementa AMQP para mensajería confiable y desacoplada.
Considera gRPC para comunicaciones de alto rendimiento entre servicios.

macOS Daemons/LaunchAgents

Thu, 14 Aug 2025 21:00:00 -0600

A diferencia de Linux, donde se utiliza comúnmente cron para tareas programadas, en macOS el enfoque recomendado son los daemons y los launch agents. Aunque crontab existe en macOS, no es la forma preferida para ejecutar servicios o comandos de forma periódica.

Un daemon se utiliza principalmente para procesos del sistema o aplicaciones de línea de comandos que corren independientemente del usuario. Por otro lado, un launch agent está asociado a una sesión de usuario y puede interactuar con aplicaciones gráficas, por lo que es más adecuado para tareas específicas del usuario.

Hace tiempo que utilizo aerc como cliente de correo, ya que permite una conexión IMAP directa. Sin embargo, en esta ocasión necesitaba realizar copias de seguridad automáticas de una cuenta de correo. Para ello, configuré un launch agent que ejecuta mbsync -a cada cierto intervalo de tiempo.

Creación del archivo de configuración

Primero, se debe crear un archivo de configuración en formato .plist, que es básicamente un XML con un esquema específico. Este archivo debe ubicarse en el directorio ~/Library/LaunchAgents/.

`~/Library/LaunchAgents/com.user.mbsync.plist`

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
 <dict>
 <key>Label</key>
 <string>com.user.mbsync</string>
 <key>ProgramArguments</key>
 <array>
 <string>/usr/bin/mbsync</string>
 <string>-a</string>
 </array>
 <!-- 300 seconds = 5 minutes -->
 <key>StartInterval</key>
 <integer>300</integer>
 <!-- Run immediately when loaded -->
 <key>RunAtLoad</key>
 <true/>
 <!-- Log output -->
 <key>StandardOutPath</key>
 <string>/tmp/mbsync.log</string>
 <!-- Log errors -->
 <key>StandardErrorPath</key>
 <string>/tmp/mbsync.error.log</string>
 </dict>
</plist>

Una vez creado el archivo, se carga con el siguiente comando:

launchctl load ~/Library/LaunchAgents/com.user.mbsync.plist

Puedes verificar el estado del agente con:

launchctl list | grep com.user.mbsync

Para detener y eliminar la tarea programada, usa:

launchctl unload ~/Library/LaunchAgents/com.user.mbsync.plist

Notas adicionales:

Asegúrate de que mbsync esté correctamente configurado en tu sistema.
Los archivos .plist deben tener permisos válidos y sintaxis correcta; de lo contrario, launchctl no los cargará.

Apple silicon: Container →

Wed, 13 Aug 2025 16:00:00 -0600

brew install container
container system start
container run hello-world