Autor: dagorret

  • ¿Puedo trabajar con Moodle en un Proyecto Laravel?

    ¿Puedo trabajar con Moodle en un Proyecto Laravel?

    Estoy trabajando en un proyecto Lucy. Que es un sistema de gestión académica. Y tengo que activarlo contra Moodle en principio y luego contra Microsoft Teams. Para probar Moodle, necesito tenerlo levantado en un entorno de producción. ¿Se puede integrarlo en Sails?

    Sí, podemos hacerlo de las dos formas:

    • A) Integrarlo al stack de Sail con un docker-compose.override.yml. Es práctico para un entorno de pruebas único (Laravel + DB + Moodle en la misma red).
    • B) Correr Moodle en un compose aparte. Es más limpio si querés aislar servicios, reiniciar/actualizar Moodle sin tocar tu app o usar otra DB/volúmenes.

    Para “probar contra él” localmente, A suele ser suficiente. Abajo te dejo un override listo con Moodle (Bitnami) usando el MySQL del stack Sail.


    Opción A — Agregar Moodle al proyecto Sail (recomendado para pruebas locales)

    Crea docker-compose.override.yml en la raíz del proyecto Laravel:

    services:
      # Moodle (servidor web + PHP en un solo contenedor)
      moodle:
        image: bitnami/moodle:latest
        depends_on:
          - mysql         # o "mariadb" si ese es tu servicio DB en Sail
        environment:
          # Datos del admin de Moodle
          MOODLE_USERNAME: admin
          MOODLE_PASSWORD: admin123
          MOODLE_EMAIL: [email protected]
    
          # Conexión a la base (apunta al servicio DB de Sail)
          MOODLE_DATABASE_TYPE: mysqli         # o "pgsql" si usás Postgres
          MOODLE_DATABASE_HOST: ${DB_HOST:-mysql}
          MOODLE_DATABASE_PORT_NUMBER: ${FORWARD_DB_PORT:-3306}
          MOODLE_DATABASE_USER: ${DB_USERNAME:-sail}
          MOODLE_DATABASE_PASSWORD: ${DB_PASSWORD:-password}
          MOODLE_DATABASE_NAME: moodle         # DB nueva para Moodle
    
          # Opcionales útiles
          PHP_MEMORY_LIMIT: 512M
          PHP_UPLOAD_MAX_FILESIZE: 64M
          PHP_POST_MAX_SIZE: 64M
          # MOODLE_SITE_NAME: "Moodle local"
          # MOODLE_PASSWORD_POLICY: "false"
    
        ports:
          - "${FORWARD_MOODLE_PORT:-8083}:8080"  # http://localhost:8083
        volumes:
          - moodle_app:/bitnami/moodle
          - moodle_data:/bitnami/moodledata
        networks:
          - sail
    
    volumes:
      moodle_app:
      moodle_data:
    
    networks:
      sail:
        external: true
        name: ${APP_SERVICE:-sail}
    

    Antes de levantar, asegurate de crear la base moodle en tu MySQL de Sail (o define DB_USERNAME con permisos para crearla). Si preferís que Moodle la cree, dale permisos de creación al usuario.

    Levantar:

    ./vendor/bin/sail up -d
    

    Abrí http://localhost:8083 (admin/admin123 según lo configurado arriba).
    Tu Laravel puede “probar contra Moodle” vía HTTP (APIs/rest, OAuth2, LTI, etc.). Si necesitás que Moodle haga callbacks a Laravel, usa APP_URL y el puerto expuesto de tu app.

    Notas

    • Si usás Postgres en Sail, cambia:
      • depends_on: [pgsql]
      • MOODLE_DATABASE_TYPE: pgsql
      • MOODLE_DATABASE_PORT_NUMBER: 5432
      • MOODLE_DATABASE_HOST: pgsql
    • Moodle requiere un cron. El contenedor Bitnami trae cron integrado. Si querés forzarlo: MOODLE_ENABLE_CRON: "yes" (ya suele venir activo). Alternativa: programar un curl al cron.php con un contenedor sidecar.

    Opción B — Moodle en un compose separado (más aislamiento)

    En otra carpeta:

    services:
      moodle:
        image: bitnami/moodle:latest
        environment:
          MOODLE_USERNAME: admin
          MOODLE_PASSWORD: admin123
          MOODLE_EMAIL: [email protected]
          MOODLE_DATABASE_TYPE: mysqli
          MOODLE_DATABASE_HOST: db
          MOODLE_DATABASE_PORT_NUMBER: 3306
          MOODLE_DATABASE_USER: moodle
          MOODLE_DATABASE_PASSWORD: moodlepass
          MOODLE_DATABASE_NAME: moodle
        ports:
          - "8083:8080"
        volumes:
          - moodle_app:/bitnami/moodle
          - moodle_data:/bitnami/moodledata
        depends_on:
          - db
    
      db:
        image: mysql:8
        environment:
          MYSQL_DATABASE: moodle
          MYSQL_USER: moodle
          MYSQL_PASSWORD: moodlepass
          MYSQL_ROOT_PASSWORD: rootpass
        volumes:
          - db_data:/var/lib/mysql
    
    volumes:
      moodle_app:
      moodle_data:
      db_data:
    

    Luego docker compose up -d. Tu app Laravel puede hablar con Moodle vía http://localhost:8083.


    ¿Cuál conviene?

    • Integrado (override): setup más rápido; todo en una sola red; ideal para pruebas de integración locales.
    • Separado: reinicios y upgrades de Moodle sin afectar Sail; mejor si querés probar múltiples versiones de Moodle o DB diferente.
  • phpMyAdmin o pgAdmin al proyecto Laravel en Sail

    phpMyAdmin o pgAdmin al proyecto Laravel en Sail

    Lo más limpio es agregar un docker-compose.override.yml en tu proyecto Sail (así no tocas el docker-compose.yml generado). Ahí definís phpMyAdmin (para MySQL/MariaDB) o pgAdmin (para PostgreSQL).

    Sail carga automáticamente los *-override.yml si están en la raíz del proyecto.


    Opción A — phpMyAdmin (MySQL/MariaDB)

    Crea docker-compose.override.yml con:

    services:
      phpmyadmin:
        image: phpmyadmin:latest
        depends_on:
          - mysql   # o "mariadb" si usás ese servicio
        environment:
          PMA_HOST: ${DB_HOST:-mysql}              # host del servicio MySQL/MariaDB
          PMA_PORT: ${FORWARD_DB_PORT:-3306}       # puerto interno del contenedor DB
          # Opcional si querés autologin con root (si definís root pass en tu DB):
          # MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:-secret}
        ports:
          - "${FORWARD_PHPMYADMIN_PORT:-8081}:80"  # http://localhost:8081
        networks:
          - sail
    
    networks:
      sail:
        external: true
        name: ${APP_SERVICE:-sail} # red que crea Sail (normalmente "sail")
    

    Luego:

    ./vendor/bin/sail up -d
    

    Entrás en http://localhost:8081.
    Servidor: mysql (o mariadb), Usuario/Clave: los de tu .env (DB_USERNAME / DB_PASSWORD).

    Si usás mariadb en Sail, cambia depends_on a mariadb y PMA_HOST a mariadb.


    Opción B — pgAdmin (PostgreSQL)

    En el mismo docker-compose.override.yml (o en otro), agrega:

    services:
      pgadmin:
        image: dpage/pgadmin4:latest
        depends_on:
          - pgsql
        environment:
          PGADMIN_DEFAULT_EMAIL: [email protected]
          PGADMIN_DEFAULT_PASSWORD: admin123
        ports:
          - "${FORWARD_PGADMIN_PORT:-8082}:80"     # http://localhost:8082
        volumes:
          - pgadmin_data:/var/lib/pgadmin
        networks:
          - sail
    
    volumes:
      pgadmin_data:
        driver: local
    
    networks:
      sail:
        external: true
        name: ${APP_SERVICE:-sail}
    

    Levanta:

    ./vendor/bin/sail up -d
    

    Entrás en http://localhost:8082 con el email/clave de arriba.
    Dentro de pgAdmin, Add New Server y usa:

    • Name: Local
    • Host name/address: pgsql
    • Port: 5432
    • Username/Password: los de tu .env (DB_USERNAME / DB_PASSWORD)

    Notas útiles

    • Si cambiás los puertos, podés setear variables en .env del host: FORWARD_PHPMYADMIN_PORT=8081 FORWARD_PGADMIN_PORT=8082
    • Si ya tenías los contenedores arriba y no aparecen los nuevos servicios: ./vendor/bin/sail down ./vendor/bin/sail up -d
    • Con mysql en Sail, el root suele no tener password. Usá el usuario app (DB_USERNAME) o configura MYSQL_ROOT_PASSWORD en el servicio DB y reflotalo.
  • Sails opciones de configuración o instalación.

    Sails opciones de configuración o instalación.

    🧩 1. Especificar versión de PHP

    Podés usar el parámetro php en la URL.
    Por ejemplo, para crear un proyecto con PHP 8.3:

    curl -s "https://laravel.build/miapp?php=8.3" | bash
    

    Opciones válidas: php=8.0, php=8.1, php=8.2, php=8.3, php=8.4 (según las imágenes disponibles).

    Esto afecta la imagen base de Sail (laravelsail/php83-composer, etc.)


    ⚙️ 2. Especificar servicios / componentes

    Podés pasar una lista separada por comas en el parámetro with=:

    curl -s "https://laravel.build/miapp?with=mysql,redis,mailpit,meilisearch" | bash
    

    Servicios disponibles:

    • mysql, pgsql, mariadb
    • redis, memcached
    • meilisearch
    • mailpit
    • selenium

    Si no especificás ninguno, usa por defecto mysql.


    🎯 3. Especificar versión de Laravel

    El script oficial siempre instala la última versión estable del framework.
    Pero si querés una versión específica (por ejemplo Laravel 10.x), podés hacerlo después del bash usando Composer dentro de Docker:

    curl -s "https://laravel.build/miapp?php=8.3&with=pgsql,redis" | bash
    cd miapp
    ./vendor/bin/sail composer create-project laravel/laravel:^10.0 .
    

    O directamente sin usar el laravel.build:

    docker run --rm -v $(pwd):/app -w /app laravelsail/php83-composer:latest \
      composer create-project laravel/laravel:^10.0 miapp
    

    🧱 4. Ejemplo completo

    Ejemplo práctico:
    Laravel 10 + PHP 8.3 + Postgres + Redis + Mailpit

    curl -s "https://laravel.build/miapp?php=8.3&with=pgsql,redis,mailpit" | bash
    cd miapp
    ./vendor/bin/sail up -d
    

    🧰 5. Extra: personalizar el stack luego

    Una vez creado el proyecto, podés ajustar el stack en docker-compose.yml y el .env para añadir o quitar servicios.
    Por ejemplo, agregar meilisearch o cambiar mysqlpgsql.

  • De la Teoría del Actor-Red (ANT) a los estudios de infraestructura y ontologías múltiples

    De la Teoría del Actor-Red (ANT) a los estudios de infraestructura y ontologías múltiples

    Las nuevas derivas de la sociología del conocimiento y la ciencia contemporánea


    1. Herencia de la ANT

    Tras la expansión de la Teoría del Actor-Red en los años noventa, emergió una generación de investigadores que retomó sus intuiciones pero desplazó el foco desde las redes visibles hacia las estructuras invisibles y las ontologías implícitas que sostienen la práctica científica. La ciencia dejó de pensarse como un conjunto de actores en interacción y pasó a concebirse como un entramado de infraestructuras, clasificaciones y modos de existencia.


    2. Estudios de infraestructura: lo invisible que organiza el conocimiento

    Autoras como Susan Leigh Star y Geoffrey Bowker abrieron los llamados infrastructure studies. En obras como Sorting Things Out: Classification and Its Consequences (1999), demostraron que las infraestructuras —bases de datos, estándares, taxonomías— son artefactos políticos que definen qué cuenta como conocimiento y quién puede producirlo.

    Las categorías científicas, los formularios y los códigos técnicos no son neutrales: son el esqueleto invisible de las redes sociotécnicas. Así, el poder epistemológico se ejerce a través de los sistemas de clasificación que estructuran el mundo digital y burocrático.


    3. Ontologías múltiples y el giro post-ANT

    Annemarie Mol, en The Body Multiple (2002), propone el concepto de ontologías múltiples: los objetos científicos no son únicos ni estables, sino que se multiplican en las prácticas. El “cuerpo” que examina el médico, el cirujano o el patólogo son realidades diferentes, producidas en distintos regímenes de práctica. No existe un mundo, sino muchos mundos en acción.

    Este giro post-ANT —también impulsado por John Law— desplaza la atención desde la red hacia la performatividad de lo real: el conocimiento no describe el mundo, lo hace existir de maneras diversas.


    4. De la coproducción a las ecologías de saberes

    Autores como Sheila Jasanoff desarrollan el concepto de coproducción: la ciencia y el orden social se constituyen mutuamente. Mientras tanto, desde el Sur Global, Boaventura de Sousa Santos propone las ecologías de saberes y las epistemologías del Sur, ampliando el horizonte actor-red hacia formas no occidentales de conocimiento.

    Estas perspectivas articulan la sociología de la ciencia con la justicia cognitiva y la política global del saber, extendiendo la noción de “red” hacia dimensiones culturales, ecológicas y poscoloniales.


    5. Materialidades digitales y agencia no humana

    Con la expansión de los datos, los algoritmos y la inteligencia artificial, la ANT encuentra nuevas aplicaciones. Autores como Lucy Suchman y N. Katherine Hayles estudian la agencia distribuida en entornos híbridos humano-máquina, donde el conocimiento emerge de interacciones computacionales y cognitivas. Las redes se vuelven más densas, automáticas y globales.


    6. Hacia una sociología de las infraestructuras del saber

    El legado conjunto de Latour, Callon, Star, Mol y Jasanoff sugiere una conclusión poderosa: comprender la ciencia contemporánea exige estudiar sus infraestructuras epistémicas. Los cables, los servidores, los algoritmos y los estándares internacionales son hoy los equivalentes de los laboratorios del siglo XIX. La ciencia ya no está sólo “en el laboratorio”: está en la nube, en las bases de datos, en las plataformas.


    7. Conclusión: del laboratorio a Gaia

    En sus últimos trabajos, Bruno Latour amplió esta visión hacia la ecología del planeta. En Facing Gaia (2017), propone una política de los seres terrestres: una ontología relacional de la Tierra donde humanos, máquinas y ecosistemas forman un mismo tejido de interdependencia. Es el cierre natural de una línea que comenzó analizando la ciencia en el laboratorio y termina pensándola como una práctica planetaria.

    “Estamos todos atrapados en la misma red de interdependencias terrestres.”
    Bruno Latour


    Serie: Sociología del conocimiento científico
    Próximo artículo (cierre de temporada): Del laboratorio a Gaia: epistemologías relacionales en tiempos de crisis planetaria

  • Cómo crear un proyecto Laravel con Sail sin instalar PHP ni Composer en tu sistema

    Cómo crear un proyecto Laravel con Sail sin instalar PHP ni Composer en tu sistema

    Si estás en Arch Linux (o cualquier distro liviana) y no querés ensuciar tu entorno con PHP, Composer o Node.js, Laravel Sail te permite trabajar completamente dentro de contenedores Docker. Solo necesitás tener Docker y Docker Compose v2 instalados en tu host.


    🐋 1. Instalar y habilitar Docker

    sudo pacman -S docker docker-compose
    sudo systemctl enable --now docker
    sudo usermod -aG docker $USER
    # Cerrá sesión y volvé a entrar para aplicar el grupo docker

    En Compose v2 se usa docker compose (sin guion). Cualquiera de los dos paquetes (docker-compose o docker-compose-plugin) sirve.


    ⚙️ 2. Crear un nuevo proyecto Laravel con Sail

    Podés generar el proyecto directamente con el script oficial de Laravel, que ya configura Sail:

    curl -s https://laravel.build/miapp | bash
    cd miapp
    ./vendor/bin/sail up -d

    Esto crea el entorno completo con PHP, Composer, Node, MySQL y Redis dentro de contenedores.

    Elegir servicios opcionales

    Podés personalizar qué servicios incluye el entorno ejecutando:

    curl -s "https://laravel.build/miapp?with=pgsql,redis,mailpit" | bash

    Servicios comunes: mysqlpgsqlmariadbredismeilisearchmailpitselenium.


    💻 3. Comandos básicos con Sail

    Usá ./vendor/bin/sail para todo:

    # Artisan
    ./vendor/bin/sail php artisan migrate
    
    # Composer
    ./vendor/bin/sail composer require laravel/sanctum
    
    # Node / Vite
    ./vendor/bin/sail npm install
    ./vendor/bin/sail npm run dev

    Alias opcional para acortar:

    alias sail='[ -f sail ] && bash sail || bash vendor/bin/sail'

    🔧 4. Agregar Sail a un proyecto Laravel existente

    Si ya tenés un proyecto Laravel sin Sail, podés agregarlo sin necesidad de tener PHP instalado localmente.

    docker run --rm -u "$(id -u):$(id -g)" -v "$PWD":/app -w /app composer:2 \
      composer require laravel/sail --dev
    
    docker run --rm -v "$PWD":/var/www/html -w /var/www/html \
      laravelsail/php84-composer:latest php vendor/bin/sail install
    
    ./vendor/bin/sail up -d

    🧩 5. Problemas comunes

    • Permisos en carpetas:sudo chown -R $USER:$USER storage bootstrap/cache
    • Puertos ocupados:
      Editá docker-compose.yml o el archivo .env y cambiá APP_PORTFORWARD_DB_PORT, etc.
    • Variables de entorno:
      Revisá el archivo .env generado y ajustá los valores según tus servicios (DB_*MAIL_*, etc.).

    ✅ Conclusión

    Con Laravel Sail podés desarrollar aplicaciones modernas sin instalar nada fuera de Docker.
    En Arch, esto es ideal para mantener tu sistema limpio y tu entorno de desarrollo totalmente reproducible.

    Si querés, puedo dejarte el comando exacto para un stack típico (Postgres + Redis + Mailpit) listo para levantar con docker compose. 🚀

  • Unbound: el DNS recursivo que domina en entornos ISP

    Unbound: el DNS recursivo que domina en entornos ISP

    Seguridad, velocidad y confiabilidad para redes profesionales.

    Unbound, desarrollado por NLnet Labs, es uno de los resolutores DNS recursivos más usados en ISP, universidades y datacenters. Su foco está en la validación DNSSEC, la recursión directa a la raíz, una caché flexible y un diseño robusto que prioriza estabilidad y seguridad.

    ¿Por qué los ISP eligen Unbound?

    • DNSSEC completo: validación criptográfica del árbol DNS.
    • Recursión directa: no depende de forwarders externos; consulta a raíz y TLD.
    • Caché agresiva y configurable: millones de registros posibles; TTLs ajustables.
    • Prefetch y Serve-expired: respuestas rápidas incluso si los autoritativos están lentos.
    • Protecciones integradas: hardening contra envenenamiento de caché, amplificación y NXDOMAIN floods.
    • Arquitectura modular: módulos como subnetcache (ECS), cachedb (Redis/LMDB), python, dnstap.

    Distribuciones recomendadas para producción

    En servidores, la consistencia y el soporte a largo plazo son clave. Por eso:

    • Debian / Ubuntu Server: estables, automatizables (systemd, apt) y con versiones de Unbound bien mantenidas.
    • Rocky Linux / AlmaLinux / RHEL: base empresarial, kernel y toolchain confiables, actualizaciones previsibles.
    • No recomendado: Arch Linux: su modelo rolling release puede introducir cambios de librerías o kernel que afecten la estabilidad en producción. Para servidores DNS, priorizá stability over novelty.

    Instalación rápida en Debian / Ubuntu Server

    Comandos listos para copiar y pegar:

    sudo apt update
    sudo apt install unbound -y
    sudo wget -O /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
    sudo unbound-anchor -a "/var/lib/unbound/root.key"
    sudo systemctl enable --now unbound
    sudo systemctl status unbound
    

    Ubicaciones útiles:

    • Configuración: /etc/unbound/unbound.conf
    • Validación de configuración: unbound-checkconf
    • Control y estadísticas: unbound-control
    • Logs: journalctl -u unbound

    Instalación rápida en Rocky Linux / AlmaLinux / RHEL

    Comandos listos para copiar y pegar:

    sudo dnf install unbound -y
    sudo curl -o /var/lib/unbound/root.hints https://www.internic.net/domain/named.cache
    sudo unbound-anchor -a "/var/lib/unbound/root.key"
    sudo systemctl enable --now unbound
    sudo systemctl status unbound
    

    Ubicaciones útiles:

    • Configuración: /etc/unbound/unbound.conf
    • Validación de configuración: unbound-checkconf
    • Logs: journalctl -u unbound

    Buenas prácticas de ajuste (opcional)

    • Buffers y MTU: usar edns-buffer-size y max-udp-size a 1232 para evitar fragmentación.
    • Concurrencia: ajustar num-threads, outgoing-range y num-queries-per-thread según CPU.
    • Caché: ampliar rrset-cache-size y msg-cache-size para reducir recursiones.
    • Monitoreo: observar requestlist.exceeded, num.queries_timed_out y tiempos de recursión.

    Conclusión: Unbound ofrece un balance excelente entre rendimiento, seguridad y estabilidad. Para servidores en producción, preferí Debian o Rocky Linux. No recomiendo Arch en este rol por su carácter rolling y la posibilidad de cambios disruptivos.

  • Caída global de Microsoft Azure y Microsoft 365: causas, impacto y lecciones sobre DNS y resiliencia en la nube (Octubre 2025)

    Caída global de Microsoft Azure y Microsoft 365: causas, impacto y lecciones sobre DNS y resiliencia en la nube (Octubre 2025)

    El 29 de octubre de 2025, una interrupción global afectó a Microsoft Azure y Microsoft 365, provocando fallas de acceso a portales administrativos, autenticación y aplicaciones en línea. A continuación, un resumen ejecutivo del incidente, el trasfondo técnico (DNS/AFD) y recomendaciones prácticas de continuidad y resiliencia.


    📰 Resumen del incidente

    El 29 de octubre de 2025, Microsoft sufrió una interrupción global que afectó a Azure, Microsoft 365, Xbox Live y otros servicios empresariales.
    Los reportes comenzaron alrededor de las 9:37 PM (GMT+5:30), con fallas de acceso a portales administrativos, autenticación y aplicaciones en línea.

    La causa principal informada fue un problema de conectividad interna que impactó la resolución de nombres (DNS) y la infraestructura de Azure Front Door (AFD), impidiendo que muchas solicitudes se enruten y resuelvan correctamente.

    ⚙️ ¿Qué pasó técnicamente?

    🔹 Azure Front Door (AFD)

    Azure Front Door opera como CDN y punto de entrada global (edge) para aplicaciones en Azure: balanceo de carga, aceleración de contenido y políticas de seguridad.
    Una configuración errónea o degradación en su conectividad interna generó fallas de enrutamiento hacia backends y servicios críticos (incluida la administración y autenticación).

    🔹 DNS: el eslabón invisible que todo lo une

    El DNS (Domain Name System) traduce dominios como portal.azure.com a direcciones IP. Si falla, los usuarios no pueden alcanzar los servicios aunque los servidores estén operativos.
    Durante el incidente, la conectividad interna degradada afectó la resolución de nombres y el enrutamiento hacia endpoints clave, amplificando la indisponibilidad.

    🔹 Efecto dominó

    • Fallas intermitentes en autenticación (Azure AD / Entra ID).
    • Portal de Azure y Microsoft 365 admin center con accesos degradados o caídos.
    • Aplicaciones SaaS con timeouts y lentitud generalizada.
    • Impacto en empresas de consumo y servicios con aplicaciones dependientes de Azure.

    🌍 Impactos globales

    • Empresas: interrupción de herramientas de productividad y operaciones críticas.
    • Usuarios finales: bloqueos en correo, colaboración y aplicaciones alojadas en la nube.
    • Equipos IT: diagnóstico complejo por indisponibilidad simultánea de portales y páginas de estado.
    • Negocio: pérdidas económicas, impacto reputacional y activación de planes de continuidad (BCP).

    🧠 Lecciones teóricas e infraestructurales

    🏗️ A. Diseño para el fallo (Design for Failure)

    Incluso arquitecturas globales pueden presentar puntos únicos de falla. Diseñar con redundancia multi-zona/región e idealmente multi-nube minimiza el blast radius de un error de configuración o una degradación del plano de red.

    🌐 B. DNS como vector de riesgo

    El DNS es crítico y a menudo subestimado: implementar servidores redundantes, monitoring sintético, validación y plan de contingencia para fallas de resolución/propagación es esencial.

    🗣️ C. Transparencia y comunicación

    La rapidez y claridad del proveedor durante incidentes masivos habilita respuestas operativas eficaces del cliente. Aun así, los clientes deben tener paneles de monitoreo propios e independientes del proveedor.

    🧩 D. Dependencias invisibles

    Mapear dependencias (CDN, DNS, autenticación, balanceadores) permite entender cómo un fallo en el edge puede cascader a capas superiores (SaaS, portales, identidades).

    🛡️ Recomendaciones para organizaciones

    1. Auditar dependencias críticas: DNS, CDN (AFD), identidad, balanceadores, WAF.
    2. Redundancia geográfica y pruebas de conmutación por error (DR/BCP) documentadas y ensayadas.
    3. Monitoreo sintético (latencia, DNS, HTTP, autenticación) y alertas fuera de la nube afectada.
    4. Simulacros periódicos de incidentes para medir MTTD/MTTR y fortalecer playbooks.
    5. Revisar SLA/compensaciones ante interrupciones sostenidas; registrar impacto y evidencias.
    6. Visibilidad propia (observabilidad y tableros independientes) para no depender del portal del proveedor.

    🔍 Conclusión

    La caída global de Azure/Microsoft 365 en octubre de 2025 recuerda que la nube, por sofisticada que sea, no es infalible. La madurez digital consiste en diseñar para la resiliencia, distribuir la carga y sostener la operación aun cuando la nube falle.

    📚 Fuentes

  • El sistema operativo del mundo: tecnología, libertad y dependencia

    El sistema operativo del mundo: tecnología, libertad y dependencia

    Reflexión de miércoles

    Vivimos rodeados de pantallas, redes, algoritmos y dispositivos. Pero más que rodeados, vivimos dentro de ellos. La tecnología ya no es una herramienta externa: es el ambiente en el que respiramos, el tejido invisible de nuestras decisiones, emociones y vínculos. Este texto explora cómo el software se convirtió en la forma contemporánea del mundo.

    Cuando todo funciona con software, ¿quién gobierna lo invisible?


    Durante siglos pensamos la técnica como un conjunto de herramientas al servicio del ser humano. Sin embargo, en el siglo XXI esa relación se invirtió: ya no manejamos los instrumentos, sino que habitamos dentro de ellos. El sistema operativo —esa capa invisible de código que sostiene el funcionamiento del mundo digital— se convirtió en la nueva infraestructura de la existencia. No solo organiza las máquinas: organiza nuestras vidas.


    1. La invisibilidad del poder tecnológico

    Martin Heidegger lo advirtió en La pregunta por la técnica (1954): la esencia de la técnica no es instrumental, sino ontológica. No se trata solo de medios para fines, sino de una forma de revelar el mundo. Hoy esa revelación adopta la forma del dato: todo lo que no puede medirse tiende a desaparecer. La técnica contemporánea ya no se limita a ayudarnos; nos define, nos traduce, nos anticipa.

    Lo más inquietante de este poder es su invisibilidad. Nadie “decide” los algoritmos que rigen la vida cotidiana, pero todos los seguimos. Desde los motores de búsqueda hasta los sistemas de recomendación, el poder técnico opera sin rostro. Como diría Bruno Latour, las máquinas se volvieron actores sociales: participan, median, intervienen. El problema no es su existencia, sino que no las percibimos como parte de la política.


    2. El código como ontología

    Gilbert Simondon sostenía que comprender una máquina es comprender su génesis. Hoy esa génesis está en el código: líneas de texto que determinan qué puede y qué no puede hacer un cuerpo, un sistema, una ciudad. El código es la nueva gramática de lo real. Escribe las reglas que antes pertenecían a la física o a la moral.

    Donna Haraway, en su Manifiesto Cyborg, propuso superar la frontera entre lo humano y lo técnico. El “cyborg” no es una fantasía futurista, sino nuestra condición presente: seres híbridos, ensamblados entre biología y algoritmo. Ya no usamos tecnología: somos tecnología. Y ese tránsito redefine la idea de libertad.


    3. De Linux a la nube: el poder de lo anónimo

    Linux, símbolo del conocimiento compartido, encarnó una ética de cooperación y autonomía. Pero su triunfo técnico se tradujo, paradójicamente, en dependencia social. Las grandes corporaciones —Amazon, Google, Microsoft— basan su infraestructura en Linux, pero la envuelven en un modelo cerrado. El código libre alimenta ecosistemas que privatizan la red.

    Shoshana Zuboff describió este fenómeno como capitalismo de la vigilancia: los sistemas aprenden de nosotros y, en ese aprendizaje, nos gobiernan. Android, derivado de Linux, representa esa paradoja: libre en origen, controlado en la práctica. La promesa de apertura devino ecosistema de control. Lo mismo ocurre con la nube: un espacio público sostenido por arquitecturas privadas.


    4. Ejemplos de un poder cotidiano

    El teléfono inteligente es el laboratorio perfecto del nuevo orden tecnológico. Nos da acceso, pero también nos encierra. Cada gesto deja un rastro, cada desplazamiento una coordenada. No necesitamos que nos vigilen: colaboramos con nuestra vigilancia.

    En los vehículos eléctricos, el propietario no posee realmente su máquina. Tesla puede activar o desactivar funciones a distancia; un coche puede “morir” por decisión remota. En las casas inteligentes, el confort se compra con privacidad: el hogar se convierte en sensor. Y en las inteligencias artificiales, la conversación se vuelve espejo: creemos dialogar, pero solo completamos patrones.

    Estos ejemplos no hablan de distopías futuras, sino del presente. El sistema operativo del mundo ya está en marcha, y su poder no proviene de la coerción, sino de la conveniencia. El usuario libre es aquel que todavía no actualizó sus términos de servicio.


    5. La humanidad delegada

    Byung-Chul Han observa que el sujeto digital ya no es dominado por la autoridad externa, sino por la autoexplotación. Nos controlamos con la ilusión de libertad. “El sujeto del rendimiento se explota a sí mismo creyendo que se realiza.” Cada notificación es una microtarea emocional. Cada algoritmo, un espejo que nos devuelve una versión optimizada de nosotros mismos.

    Delegamos la memoria en los dispositivos, la orientación en los mapas, la decisión en los sistemas de recomendación. La inteligencia artificial no roba empleos: roba tiempo, atención, sentido. Nos libera de pensar, pero también de experimentar. La dependencia técnica no se impone: se seduce.


    6. Habitar el sistema

    No existe un “afuera” de la tecnología. La desconexión es una fantasía pastoral. La verdadera libertad no consiste en escapar del sistema, sino en comprenderlo. Heidegger decía que la salvación solo puede surgir de donde acecha el peligro: la técnica puede revelar otra forma de habitar el mundo. Pero eso requiere conciencia, pedagogía y política.

    La alfabetización del siglo XXI no es solo aprender a programar: es aprender a pensar el poder inscrito en el código. Linux demostró que otra manera de construir tecnología es posible. Ahora el desafío es construir otra manera de vivir dentro de ella.


    “Ya no vivimos en un mundo con máquinas: vivimos dentro de ellas.”


    Bibliografía orientativa

    • Heidegger, Martin. La pregunta por la técnica. Editorial Anthropos, 1994.
    • Simondon, Gilbert. El modo de existencia de los objetos técnicos. Cactus, 2013.
    • Haraway, Donna. Manifiesto Cyborg. Madrid: Cátedra, 1995.
    • Zuboff, Shoshana. The Age of Surveillance Capitalism. PublicAffairs, 2019.
    • Han, Byung-Chul. La sociedad del cansancio. Herder, 2012.
    • Latour, Bruno. Reensamblar lo social. Manantial, 2008.

    Artículo previo de esta serie: Linux ganó: por qué el software libre gobierna el mundo sin estar en tu escritorio

  • Latour y Callon: cómo los objetos piensan la ciencia

    Latour y Callon: cómo los objetos piensan la ciencia

    Redes, traducción y controversias en la producción del conocimiento


    1. Contexto y surgimiento

    Durante las décadas de 1970 y 1980, la sociología de la ciencia experimentó una transformación decisiva. En Francia, Bruno Latour y Michel Callon desarrollaron una perspectiva que rompió con las visiones estructuralistas y economicistas de la actividad científica. Su propuesta, conocida como Teoría del Actor-Red (ANT, por sus siglas en inglés), cambió el modo de entender la relación entre conocimiento, tecnología y sociedad.

    Frente a la idea de la ciencia como un campo (Bourdieu) o una arena (Knorr-Cetina), Latour y Callon conciben la práctica científica como una red heterogénea donde humanos y no humanos participan en pie de igualdad en la producción del conocimiento.


    2. Los objetos como actores

    Uno de los postulados centrales de la ANT es el principio de simetría generalizada: los objetos, las máquinas, los instrumentos o los documentos tienen agencia, en tanto intervienen y modifican las acciones humanas. No son meros medios, sino participantes activos en el tejido sociotécnico.

    Así, un microscopio, un protocolo experimental o un gráfico estadístico “actúan” porque configuran lo que los científicos pueden ver, medir o comunicar. La ciencia deja de ser un relato de héroes humanos para volverse una historia de asociaciones materiales y discursivas.


    3. El concepto de traducción

    Para explicar cómo se forman y estabilizan estas redes, Latour y Callon introducen el concepto de traducción. La traducción es el proceso mediante el cual un actor logra que otros adopten sus objetivos, redefiniendo sus intereses y roles en el proceso. Es una forma de negociación y alineamiento de fuerzas.

    Callon (1986) lo ejemplifica magistralmente en su estudio sobre la pesca de la vieira de Saint-Brieuc, donde científicos, pescadores y moluscos interactúan en una red de intereses mutuos. La red científica sólo se estabiliza cuando los distintos actores —humanos y no humanos— son traducidos hacia un propósito común.


    4. Ejemplo: Pasteur y el poder de las redes

    Latour, en The Pasteurization of France (1988), muestra cómo Louis Pasteur logró transformar el conocimiento microbiológico en una fuerza social y política. No lo hizo solo: lo acompañaron microscopios, vacunas, campesinos, bacterias, laboratorios y ministerios. La “revolución pasteuriana” fue en realidad la traducción de múltiples redes hacia un mismo objetivo: domesticar los microbios y controlar la naturaleza.

    La ciencia aparece así como un proyecto colectivo de ensamblaje, donde las verdades se estabilizan porque las redes se sostienen, no porque exista un tribunal epistemológico superior.


    5. Diferencias con Knorr-Cetina y Bourdieu

    Aunque comparten el interés por las prácticas concretas, Latour y Callon se distancian de Knorr-Cetina en un punto clave: ella mantiene un horizonte “epistémico” (la producción del conocimiento), mientras que la ANT elimina la frontera entre lo social y lo científico.

    Comparado con Bourdieu, el cambio es aún más profundo. La ANT disuelve la noción de campo y sustituye la lógica de posiciones por la de redes móviles. No hay jerarquías predefinidas, sino configuraciones efímeras de poder, mediadas por humanos y objetos.


    6. Críticas y límites

    • Se le reprocha su tendencia a la despolitización: al distribuir la agencia entre todo tipo de actores, puede diluir la responsabilidad humana.
    • También se cuestiona su neutralidad analítica, ya que evita diferenciar entre causas justas e injustas, o entre saberes emancipadores y dominantes.
    • Sin embargo, su potencia heurística es indiscutible: permite estudiar la ciencia, la tecnología y la sociedad como procesos de coproducción.

    7. Legado contemporáneo

    La ANT abrió el camino para los estudios sobre controversias sociotécnicas, la ciencia en acción y la política de los objetos. Hoy sus ideas se aplican al análisis de redes digitales, inteligencia artificial, sostenibilidad y gobernanza ambiental.

    “No hay sociedad ni naturaleza: sólo redes que se hacen y deshacen.”
    Bruno Latour


    Serie: Sociología del conocimiento científico
    Próximo artículo: De la Teoría del Actor-Red (ANT) a los estudios de infraestructura y ontologías múltiples

  • Ciencia para sanar, sombras para brillar: cuando el descubrimiento choca con el poder

    Ciencia para sanar, sombras para brillar: cuando el descubrimiento choca con el poder

    La ciencia, en su sentido más noble, no nace de la ambición de premios ni del cálculo de patentes. Nace del impulso de comprender y de aliviar. Es un servicio —a la salud, a la verdad, al futuro— que pide humildad.
    Pero en la historia de ese servicio abundan también las bajezas: jerarquías que sofocan, sesgos de género, apropiaciones del mérito, intereses comerciales que se imponen al rigor.
    El “espíritu del descubridor/creador” es el que se atreve a mirar lo que nadie mira, a sostener la curiosidad incluso cuando el poder la castiga.

    A continuación, diez historias. Ocho son ya historia escrita; dos están ocurriendo hoy mismo. Todas muestran la tensión entre la ciencia como servicio y la ciencia como sistema de poder.


    1. Albert Schatz y la estreptomicina: la cura traicionada (1943–1952)

    En 1943, en un sótano de la Universidad de Rutgers, el joven Albert Israel Schatz, de 23 años, aisló a partir de un cultivo de suelo una sustancia activa contra el bacilo de Koch. La estreptomicina fue el primer antibiótico efectivo contra la tuberculosis humana, responsable entonces de millones de muertes anuales.
    Su director, Selman Waksman, patentó el hallazgo, registró las regalías y en 1952 recibió en solitario el Premio Nobel de Medicina “por el descubrimiento de la estreptomicina” (The Lancet, 2005). Schatz, indignado, demandó judicialmente. Obtuvo una fracción simbólica de las regalías y el reconocimiento póstumo como codescubridor.
    El propio tribunal que falló a su favor habló de una “injusticia institucionalizada”.

    Por qué importa: el descubrimiento salvó millones de vidas, pero la recompensa fue absorbida por las jerarquías del laboratorio. El caso ilustra cómo la estructura académica puede apropiarse del esfuerzo individual bajo el disfraz del “trabajo en equipo”.

    2. Rosalind Franklin y la fotografía robada (1952–1962)

    En 1952, Rosalind Franklin tomó en el King’s College de Londres la famosa Foto 51, un patrón de difracción de rayos X que revelaba la forma helicoidal del ADN. Su colega Maurice Wilkins mostró la imagen sin su consentimiento a James Watson y Francis Crick, quienes elaboraron el modelo de la doble hélice.
    Diez años después, el Nobel 1962 fue otorgado a ellos tres; Franklin había muerto en 1958 y, según las reglas, el premio no se concede póstumamente.
    Décadas más tarde, la revisión de los cuadernos de laboratorio demostró que su trabajo había sido decisivo (National Geographic, 2013; Nature Reviews Genetics, 2020).

    Por qué importa: el ADN es la piedra angular de la biomedicina. El episodio recuerda que la ciencia no sólo requiere datos, sino ética del reconocimiento.

    3. Banting, Best y la insulina: curar la diabetes, repartir la gloria (1921–1923)

    El cirujano Frederick Banting y el estudiante Charles Best lograron aislar la insulina en perros pancreatectomizados, y junto al bioquímico James Collip lograron purificarla para uso humano.
    El Nobel de Medicina 1923 fue concedido a Banting y John Macleod, jefe del laboratorio. En protesta, Banting compartió su mitad del premio con Best; Macleod, con Collip (Nobel Archives).

    Por qué importa: el hallazgo permitió que la diabetes pasara de sentencia a enfermedad crónica, pero el reparto del mérito reveló las grietas éticas en la ciencia aplicada.

    4. Lise Meitner: la física que explicó la fisión y fue borrada (1938–1944)

    En 1938, tras huir del nazismo, Lise Meitner calculó junto a su sobrino Otto Frisch la ecuación energética de la fisión nuclear, interpretando correctamente los experimentos de Otto Hahn.
    El Nobel de Química 1944 fue otorgado solo a Hahn. Documentos posteriores mostraron que la idea interpretativa había sido de Meitner y Frisch (Science History Institute, 2018).

    Por qué importa: Meitner rehusó participar en el Proyecto Manhattan. Su lección ética es doble: comprender la materia no implica desentenderse del uso que se hace de ella.

    5. Chien-Shiung Wu y la paridad quebrada (1956–1957)

    La física Chien-Shiung Wu realizó el experimento que demostró que la paridad no se conserva en el decaimiento beta, confirmando la hipótesis teórica de T. D. Lee y C. N. Yang.
    Ellos recibieron el Nobel de Física 1957; Wu fue omitida. Años después, el American Physical Society reconoció su rol experimental como “imprescindible” (AIP Archives).

    Por qué importa: sin su precisión experimental, la física moderna no sería la misma. Un caso clásico de invisibilización del trabajo femenino.

    6. Jocelyn Bell Burnell y los pulsos del universo (1967–1974)

    En 1967, mientras analizaba kilómetros de registros de radio, la doctoranda Jocelyn Bell Burnell detectó una señal rítmica imposible de atribuir a ruido: el primer púlsar.
    El Nobel 1974 fue para su supervisor Antony Hewish y Martin Ryle. Bell Burnell quedó fuera, aunque su nombre figuraba en el artículo original.
    En 2018 recibió el Breakthrough Prize y donó los tres millones de dólares a becas para mujeres y minorías (University of Cambridge, 2018).

    Por qué importa: es la reivindicación de la mirada atenta. Ciencia como paciencia, no como poder.

    7. Henrietta Lacks y las células inmortales (1951–actualidad)

    Henrietta Lacks, mujer afroestadounidense tratada por cáncer cervical en 1951, jamás supo que sus células serían extraídas sin consentimiento.
    Su línea celular HeLa resultó “inmortal”: permitió desarrollar vacunas, terapias génicas y fármacos oncológicos.
    En 2013, el NIH estableció un acuerdo con sus descendientes para el control del acceso a los datos genómicos (NIH Press Release, 2013).

    Por qué importa: ciencia útil que nació de una falla ética. El progreso no exime de responsabilidad moral.

    8. Ignaz Semmelweis: la higiene que la autoridad rechazó (1847–1865)

    El obstetra Ignaz Semmelweis demostró en 1847 que el simple lavado de manos reducía en más de un 80 % la fiebre puerperal.
    Fue ridiculizado, destituido y murió internado en un manicomio.
    Solo décadas después, Pasteur y Lister confirmaron sus observaciones (Britannica).

    Por qué importa: verdad incómoda contra autoridad establecida. Descubrir a favor de la vida y contra el prestigio.

    9. CRISPR: la guerra moderna por el ADN (2012–2025)

    El sistema CRISPR-Cas9, desarrollado por Jennifer Doudna y Emmanuelle Charpentier, revolucionó la edición genética.
    En 2020 recibieron el Nobel de Química, pero la disputa por las patentes entre la Universidad de California y el Broad Institute continúa.
    En mayo de 2025, un tribunal federal reabrió el caso (Reuters, 2025).

    Por qué importa: este conflicto define quién controlará el acceso a terapias génicas potencialmente curativas.

    10. Alzhéimer: fraude, prisa y captura regulatoria (2006–2025)

    a) El fraude de las imágenes

    En 2006, un paper en Nature describió la proteína Aβ*56 como clave en el Alzhéimer.
    En 2022, Science reveló manipulación de imágenes; en 2024 se inició la retractación (Science, 2022; Nature, 2024).

    b) La prisa regulatoria

    En 2021, la FDA aprobó Aducanumab (Aduhelm) con evidencia insuficiente.
    El Congreso investigó en 2022 y la OIG criticó el proceso en 2025.

    Por qué importa: la bajeza no fue robo, sino pérdida de rigor ante la presión del mercado y la desesperación social.


    Epílogo: por qué seguimos creyendo

    Las diez historias muestran que la ciencia es humana, demasiado humana. Pero también que su poder curativo es incomparable.
    Los errores, las injusticias y los sesgos no niegan su valor: lo afirman, porque nos obligan a corregir, a institucionalizar la ética, a educar el carácter tanto como el método.

    Creer en la ciencia no es creer en su pureza, sino en su capacidad de autocorrección.
    Por eso seguimos en ella: porque, aun entre sombras, sigue siendo el camino más honesto para servir a la vida.


    Referencias

    • The Lancet (2005). “Albert Schatz and the discovery of streptomycin.”
    • National Geographic (2013). “The woman who was left out of the DNA story.”
    • Nature Reviews Genetics (2020). “Reassessing Rosalind Franklin’s contribution.”
    • Nobel Prize Archives (1923). “The discovery of insulin.”
    • Science History Institute (2018). “Lise Meitner: the woman behind the split atom.”
    • American Institute of Physics (AIP) Archives. “Chien-Shiung Wu and the parity experiment.”
    • University of Cambridge (2018). “Bell Burnell’s discovery of pulsars.”
    • NIH Press Release (2013). “NIH announces HeLa Genome Data Access agreement.”
    • Encyclopaedia Britannica. “Ignaz Semmelweis.”
    • Reuters (2025). “U.S. court revives CRISPR patent dispute.”
    • Science (2022). “Image manipulation in Alzheimer’s research.”
    • Nature (2024). “Retraction notice for Lesné et al.”
    • Congressional Report (2022). “FDA’s approval of Aduhelm.”
    • Office of Inspector General (2025). “Review of accelerated approval for Alzheimer’s drugs.”