Las herramientas de la comuna, la mirada del vigilante
El día se parte en dos: la IA por fin aprende a hablarle a los datos desordenados sin romper el almacén, mientras las gafas de Meta, siempre encendidas, deciden que la calle es suya. Un conjunto de herramientas sirve la hustle de la gente. El otro la vigila. Elige tu lado.
DesktopCommander MCP: ejecuta comandos de terminal desde tu app con IA
Un dev llamado wonderwhy-er acaba de subir a GitHub un repo llamado DesktopCommander MCP. Permite que agentes de IA ejecuten comandos de terminal directamente en tu máquina.
La herramienta está construida como un servidor MCP. Eso significa que una app puede hablarle y decirle qué ejecutar. La idea es sencilla: darle a tu IA una línea directa a la shell.
La página de GitHub lista los pasos de instalación y algunos comandos. También hay notas sobre permisos y seguridad. El autor dice que está pensado como un bloque de construcción para otras herramientas.
TLDR DevOps compartió el repo en su newsletter. El post dirige a los lectores a la página de GitHub. También enlaza a otro proyecto llamado ruflo en GitHub. Ese parece una herramienta distinta con una idea similar.
El repo es open source. Lo puedes encontrar en https://github.com/wonderwhy-er/DesktopCommanderMCP. Si quieres probarlo, vas a necesitar instalar el servidor y conectarlo a un cliente MCP.
Esto todavía está en etapa temprana. El repo es pequeño. El README es corto. El autor no ha lanzado un producto pulido todavía. Es más bien un proof of concept.
Por qué nos importa:
Si manejas una tech shop chiquita o un side hustle, herramientas que le permiten a la IA hablar con tu terminal podrían cambiar cómo manejas deployments, backups y mantenimiento — pero necesitas saber exactamente qué se está ejecutando antes de dejar que corra.
Cómo dividir tablas de Postgres para que las queries no se trabe
Postgres te permite dividir tablas grandes en particiones — filas con la misma fecha, la misma región, lo que sea. La base de datos luego descarta las particiones que no necesita, así que las queries escanean menos datos. No es magia, pero es la forma más barata de evitar que una tabla se convierta en un cuello de botella.
TLDR DevOps explica cómo funciona el pruning de particiones por debajo. La idea: defines una clave de partición y el planner usa esa clave para saltarse las particiones que no pueden coincidir con tu WHERE. Si estás corriendo analytics en una tabla que ya creció a millones de filas, esto suele ser el primer palanca que jalas antes de pensar en un rewrite completo.
El post también toca los trade-offs — el mantenimiento de las particiones, el costo de tener demasiadas particiones pequeñas, y cuándo el pruning simplemente no se activa porque el planner no puede demostrar que una partición es irrelevante. Vale la pena leerlo si estás peleando con una tabla que ya se hizo demasiado grande para manejarla de un solo golpe.
La fuente es un newsletter de dev, así que el tono es práctico, sin relleno. TLDR DevOps lo maneja Dan Luu, quien escribe para ingenieros que necesitan entregar.
Por qué nos importa: cuando las apps hechas por devs de Brown se ponen lentas porque la base de datos no da abasto, este tipo de fix de bajo nivel es lo que mantiene el hustle corriendo sin necesidad de un rebuild completo.
Lo que realmente hace un system prompt — y por qué te importa para tu side hustle
¿Sabes cómo tu abuela te da instrucciones cuando te manda al mercado? No te dice "ve a comprar comida." Te dice: "Compra el cilantro, no el perejil. Agarra las cebollitas pequeñas. No dejes que el vendedor te robe en el peso." Eso es un system prompt.
Un modelo de IA sin un prompt es como un primo que sabe cocinar pero no tiene receta. Echa algo a la sartén, pero nunca sabes qué sabor vas a obtener. El prompt es la receta. Le dice al modelo: quién debe ser, qué evitar, cómo hablar.
Piénsalo como el grupo de WhatsApp de tu familia. Cuando mandas un mensaje ahí, no escribes "Estimado señor." Escribes: "Primos, la migra está en la frontera otra vez, cuídense." El prompt pone el tono, la audiencia, las reglas. Lo mismo con la IA.
Aquí está la cosa que nadie te dice: el prompt no son solo instrucciones. Es la primera capa de control. Si no pones las reglas, el modelo las pone por ti — y va a caer en lo corporativo, lo seguro, lo aburrido.
Por qué nos importa: La mayoría de nosotros ya usamos herramientas de IA para nuestros negocios, para la tarea de nuestros hijos, para nuestras necesidades de traducción. Si no entendemos qué está haciendo el system prompt, estamos dejando que alguien más escriba las reglas de cómo se responden nuestras propias palabras.
Así que aquí va tu jugada: cuando uses cualquier herramienta de IA, pregúntate: ¿quién escribió las instrucciones de fondo? Y si tú eres el que escribe el prompt, escríbelo como si le hablaras a un primo, no a un abogado. Sé específico. Pon el tono. Di lo que no quieres. El modelo te va a seguir.
Si lo haces bien, las consultas que antes tardaban segundos caen a milisegundos. Si lo haces mal, estás pagando por la complejidad sin ninguna ganancia de velocidad.
— hakibenita.com
#how-to-keep-your-database-from-choking-on-itself-b66b89Una gramática para la ingeniería de datos, no solo SQL
Xorq está empujando la ingeniería de datos hacia una gramática unificada. En vez de escribir consultas SQL separadas, jobs de Spark o scripts de Pandas para cada tarea, la idea es expresar tu pipeline de datos como una representación abstracta única — y luego compilarlo en el backend que necesites.
La propuesta es sencilla: define lo que quieres, no cómo hacerlo en un motor específico. Si tu cluster se cae, cambias de backend. Si tus datos crecen más allá de la memoria, cambias de Pandas a Spark. La lógica se mantiene igual.
Es una idea real, no un pitch deck. La gramática es el punto.
BFTS Chat: IA para la comuna, no para la nube
Estás corriendo una clínica comunitaria, un distrito escolar, un programa del condado o un negocio pequeño. Tu staff cambia entre inglés y español a mitad de la conversación. Un padre pregunta sobre opciones de IEP, un paciente necesita ayuda con la autorización previa, un maestro redacta una propuesta de beca — todo en el mismo hilo. Los chatbots mainstream o ignoran la realidad bilingüe o mandan tus documentos a la nube de otro. Eso no es cómo proteges a tu gente, a tus pacientes, a tus estudiantes. BFTS Chat está hecho para esto. Un tenant por organización. Ocho herramientas hechas a la medida — chat, análisis de docs, borradores de IEP, helpdesk, becas, autorización previa, SOPs, propuestas — todo bilingüe por defecto. Puedes correrlo contra un cerebro on-prem así nada sale de tu red. No se requiere API pública. No hay modo forzado de inglés primero. No hay “no entiendo”. Esto te toca. Constrúyelo, pruébalo, úsalo a tu manera. https://tools.brownforces.io
Búsqueda vectorial llega a los lakehouses de Apache Hudi
Apache Hudi está agregando búsqueda vectorial a su plataforma de lakehouse, permitiendo que los equipos ejecuten consultas semánticas directamente sobre los datos crudos sin tener que moverlos a una base de datos vectorial separada.
La función se integra con los formatos de tabla existentes de Hudi, así que los datos se quedan en el mismo lugar donde se ingirieron. Los equipos pueden almacenar embeddings junto con columnas estructuradas y consultarlos con búsqueda por similitud. El movimiento reduce la "plomería" entre la ingesta, el almacenamiento y la recuperación.
Hudi es open source.
La trampa oculta de latencia en Kafka: linger.ms te está robando tiempo
Jack vanlightly desglosó un ajuste silencioso pero costoso de Kafka que la mayoría de los equipos deja en su valor por defecto.
El ajuste: linger.ms. Controla cuánto tiempo espera el broker para agrupar mensajes antes de enviarlos al disco.
El valor por defecto es cero. Eso significa que cada mensaje se escribe inmediatamente. En un sistema de alto rendimiento, eso son muchas escrituras en disco. Y las escrituras en disco son caras.
La solución es simple. Pon linger.ms en algo como 5 o 10 milisegundos. El broker ahora espera unos milisegundos, recoge un pequeño lote y los escribe juntos. Una escritura en lugar de diez.
El resultado: el rendimiento salta. La latencia por mensaje baja. El uso de CPU en el broker cae.
Pero no es gratis. Estás intercambiando un poquito de latencia de cola por una gran ganancia en rendimiento. Si tu sistema ya es lento en los bordes, esto no te va a ayudar. Pero si estás escribiendo miles de mensajes por segundo, este ajuste probablemente sea la ganancia de rendimiento más barata que vas a encontrar.
El blog post pasa por las matemáticas. Muestra cómo el agrupamiento cambia el perfil de I/O. No es ciencia espacial. Es solo un ajuste que la mayoría ignora porque está escondido en la documentación.
Sin magia. Sin nueva herramienta. Solo un número que puedes cambiar en tu config y ver cómo tu broker deja de ahogarse.
Por qué nos importa: La mayoría de las apps de las que depende nuestra comunidad — las que corren en servidores compartidos, las que no pueden permitirse una instancia más grande — probablemente están corriendo este valor por defecto. Un ajuste de 10ms no cuesta nada y te compra espacio para respirar. No necesitamos esperar a un presupuesto más grande para correr nuestros sistemas más suave.
Iceberg 3: el nuevo tipo que deja que la IA mande JSON desordenado sin romper tu warehouse
Apache Iceberg 3.0 acaba de aterrizar un nuevo tipo de dato llamado V3 Variant. Es un big deal para los equipos que meten modelos de IA a sus data warehouses. La forma vieja era adivinar cómo se verían tus payloads JSON y armar un esquema rígido. Si la IA cambiaba su output, todo se rompía.
Con V3 Variant, simplemente tiras el JSON tal cual. Iceberg lo guarda. Y todavía puedes consultarlo. Los datos se mantienen estructurados para buscar, pero flexibles para agarrar cualquier cosa que el modelo escupa. No más migraciones de esquema cada vez que el modelo se actualiza.
Las gafas inteligentes de Meta que graban todo, todo el tiempo: el futuro de la vigilancia constante
Meta está jugando con la idea de unas gafas inteligentes que graban todo, todo el tiempo.
Esa es la titular. El detalle es más fino. Gizmodo reporta que Meta está explorando el concepto. No lo han construido. No lo han lanzado. Solo lo están probando.
Aun así. La implicación pesa.
Gafas que ven lo que tú ves. Que capturan lo que tú capturas. Que nunca dejan de grabar. No porque tú se lo pidas. Porque pueden.
Seamos claros: esto no es un producto. Es una dirección. Y las direcciones son cómo las empresas prueban si la gente se va a asustar antes de lanzar algo.
La tecnología ya está aquí. Cámaras en las gafas. Baterías diminutas. Sensores siempre activos. El hardware no es la barrera. La barrera es lo que le pasa al video. Quién lo guarda. Quién lo vende. Quién tiene derecho a verlo.
Y la pregunta real, la que nadie está haciendo aún:
Si un par de gafas está grabando todo el tiempo, ¿quién es dueño de la imagen del desconocido que pasa por tu barrio? ¿La persona que lleva las gafas? ¿La empresa que las fabricó? ¿El algoritmo que lo detecta?
Este es el primo que tiene un negocio paralelo vendiendo cámaras. Él sabe de la tecnología. También sabe lo rápido que se propaga una vez que es lo suficientemente barata.
Por qué nos importa:
Cuando la gente que tiene las cámaras es la misma que las compra, la gente se convierte en el contenido — y el contenido se vende al mejor postor, sin que nadie lo haya pedido.
Las gafas inteligentes de Meta quieren grabarlo todo, todo el tiempo
Meta está jugando con la idea de unas gafas inteligentes que graben todo, todo el tiempo. El reporte de Gizmodo señala esto como una posibilidad real, no solo un rumor.
Eso significa cámaras y micrófonos dentro de las monturas que usas como unas gafas normales. Siempre encendidas. Siempre mirando. Siempre escuchando.
La tecnología ya está aquí. Las gafas Ray-Ban de Meta ya graban video y audio. La diferencia es el alcance: este nuevo enfoque empuja hacia una vigilancia constante, sin parpadear, que llevas en la cara.
Esto no es un lanzamiento de producto nuevo. Es una dirección. Un empujón.
City Labs, con base en Miami, logra el primer hito de energía nuclear comercial en el espacio
Una empresa con base en Miami llamada City Labs acaba de hacer lo que nadie más ha logrado hasta ahora: producir su primera energía nuclear comercial en el espacio. La noticia saltó después de que Ars Technica publicara la historia.
City Labs tiene su base en Miami. Y eso importa. No toda la acción está en Silicon Valley. A veces, la gente que está construyendo lo siguiente lo está haciendo en el sur de Florida, con una forma diferente de hustle.
El hito se describe como "un primero para la energía nuclear comercial en el espacio". Esa es la headline. Los detalles son escasos en lo que hay disponible por ahora. No tenemos un desglose técnico completo, un timeline, ni una explicación de cuánta energía están generando. Lo que sí tenemos es el hecho de que pasó y de que la empresa tiene su base en Miami.
Esto no es cosa del gobierno, no es NASA. Es comercial. Eso significa dinero privado, riesgo privado, recompensa privada. Significa que alguien allá afuera está apostando capital real a la energía nuclear más allá de la atmósfera de la Tierra. Las apuestas son altas. Los fracasos serían espectaculares. Los éxitos cambiarían la forma en que pensamos sobre la energía fuera de la Tierra.
Hay un mundo entero de gente en esta comunidad que piensa que el espacio es un hobby de los ricos. Pero la gente que está construyendo esto es la misma clase de gente que corre negocios paralelos, que hace hustle, que se las arregla con menos de lo que los libros de texto dicen que necesitan. Miami es la base. El trabajo es duro. La recompensa es real.
Por qué nos importa: cuando gente de nuestros barrios está construyendo el futuro de la energía más allá de la Tierra, es la prueba de que la siguiente ola de innovación no está esperando permiso de una costa que nunca has visto.