Synex Linux es un proyecto comunitario argentino basado en Debian que busca ofrecer una experiencia Linux minimalista, estable y flexible. Lo que comenzó como una solución para estandarizar terminales dentro de una empresa terminó convirtiéndose en una distribución con varias ediciones, herramientas propias y una filosofía clara: entregar al usuario una base limpia para que pueda construir su sistema según sus propias necesidades.
En esta entrevista conocemos cómo nació Synex Linux, por qué el proyecto decidió apostar por un modelo Semi-rolling basado en Debian Testing, su incorporación de COSMIC, el desarrollo de herramientas como synex-snapshots y los planes del equipo alrededor de tecnologías como Btrfs, ZFS y Snapshot Boot.
1. ¿Cómo nació Synex Linux y qué necesidad busca resolver?
Synex Linux: Nació de una necesidad concreta de mi trabajo: unificar la base de terminales bajo un mismo sistema operativo. El 70% de las terminales de la empresa trabaja con Linux y ninguna distribución cubría lo que esperaba.
Yo ya trabajaba con Debian a nivel servidor, pero para terminales no lo consideraba. Las versiones live vienen muy cargadas de software y el trabajo de limpieza iba a ser complejo, mientras que hacer un netinstall y replicarlo en todos los equipos era tedioso.
Así que decidí estudiar Debian Live Build y construir una versión adaptada a mis necesidades.
Empecé con una base minimalista, aprendí mucho en el camino y decidí darle entidad propia. Synex nace el 17 de septiembre de 2025 y liberamos la primera versión el 24 de ese mismo mes.
La idea era ofrecer un sistema con lo justo y necesario, para que cada usuario instale y configure el sistema a su medida, sin imposiciones. Synex trata de ser el punto de partida de cualquier instalación personalizada.
2. ¿Por qué eligieron un modelo Semi-rolling?
Synex Linux: Hoy tenemos dos ediciones de escritorio y una de servidor:
- Synex 13, sobre Debian estable.
- Synex Semi-rolling, sobre Debian Testing.
- Synex Server, también sobre la base estable y con su propio ciclo de releases.
Synex 13 se actualiza mediante revisiones, como u1 y u2. Semi-rolling utiliza versionado por fecha, por ejemplo 26.08.17, mientras que Server utiliza revisiones, actualmente R7.
Semi-rolling salió a mediados de abril con dos objetivos: ofrecer software más actualizado sin resignar la estabilidad de Debian y funcionar como plataforma de lanzamiento de nuestros desarrollos, que una vez probados pasan a Synex estable.
Además, como Debian Testing es la candidata a convertirse en la siguiente versión estable, nos permite anticiparnos al próximo ciclo y disponer de tiempo suficiente para resolver los problemas que puedan aparecer.
Para muchos usuarios también es importante poder acceder a versiones más nuevas de las aplicaciones y probar características recientes.
3. ¿Cuál es actualmente la filosofía principal de Synex?
Synex Linux: Es una combinación: buscamos un sistema seguro, estable y que facilite las tareas al usuario.
Nuestra otra premisa desde el principio fue no reinventar la rueda. Desarrollamos únicamente donde encontramos una necesidad puntual o algo que consideramos que podía hacerse mejor.
El helper NVIDIA es un ejemplo, pensado para que cualquier usuario pueda instalar los controladores sin complicaciones.
Synex Package Manager (SPM) es otro caso. Existen muchos gestores de software, pero ninguno se adaptaba completamente a la experiencia de usuario que buscábamos.
También existía el problema de las distintas ediciones. KDE y GNOME incluyen sus propios gestores, pero otros escritorios y gestores de ventanas quedaban fuera. SPM nos permitió unificar todas nuestras ediciones bajo un mismo gestor, independientemente de que el usuario utilice Openbox, COSMIC u otro entorno.
Todo lo que hacemos está pensado alrededor de la experiencia del usuario.
4. KDE Plasma, GNOME, XFCE, COSMIC y otros escritorios
Synex Linux: Arrancamos con la idea de mantener solamente KDE y XFCE, pero con el tiempo vimos que era importante llegar a distintos tipos de usuarios.
Actualmente tenemos ocho opciones. KDE Plasma, GNOME, XFCE y COSMIC están disponibles tanto en Synex 13 como en Semi-rolling. MATE, LXDE, IceWM y Openbox son exclusivos de Synex 13.
Siempre que evaluamos un entorno nuevo realizamos pruebas exhaustivas para analizar cómo se desempeña, cómo se integra con nuestro ecosistema y cuánto puede aportar. Si no nos convence, queda fuera.
En cuanto a la personalización, la experiencia es básicamente la predeterminada del escritorio. Ajustamos elementos de branding como logos, colores y tipografía, pero evitamos la personalización extrema y, especialmente, los componentes de terceros.
La misma lógica minimalista que aplicamos al software también la aplicamos a la parte gráfica.
5. ¿Por qué Synex incorporó el escritorio COSMIC?
Synex Linux: Fue inicialmente por curiosidad. No lo había utilizado más que alguna vez que instalé Pop!_OS para probarlo.
Empecé a analizar el proyecto en detalle con COSMIC 1.0.16 y, cuando me convenció, decidí realizar una compilación propia de los paquetes para Synex.
Actualmente no existen muchas distribuciones que lo ofrezcan y me parecía importante no depender de conversiones de paquetes de Fedora ni de paquetes de terceros.
Tenemos un repositorio en GitHub con los scripts necesarios para construir tus propios paquetes DEB directamente desde el código fuente de System76.
Desde Epoch 1.0.16 hasta ahora el proyecto ha avanzado muy rápido. El 17 de agosto liberamos Semi-rolling con COSMIC 1.5.0 y pocos días después System76 ya había publicado la versión 1.7.0.
Desde la versión 1.1.0, cuando anunciaron point releases más frecuentes, el ritmo de desarrollo ha sido alto y muchas de las mejoras están orientadas a la experiencia del usuario y a la corrección de errores.
Están haciendo un excelente trabajo y creo que en poco tiempo COSMIC va a ganar terreno más allá de la curiosidad inicial de los usuarios.
6. synex-snapshots: una herramienta propia para snapshots Btrfs
Synex Linux: El motivo fue principalmente la flexibilidad y la integración.
Timeshift tiene un modelo bastante cerrado respecto de los subvolúmenes. Permite incluir un home, pero nos parecía insuficiente.
Snapper es diferente: es mucho más flexible y potente, pero está orientado a otro tipo de administración.
Lo que queríamos era ofrecer una experiencia integrada dentro del ecosistema Synex: creación, metadatos, restauración segura y recuperación desde el arranque dentro de una misma herramienta.
synex-snapshots detecta los subvolúmenes operativos del sistema y trabaja con diferentes layouts de Btrfs sin depender de nombres fijos como @ o @home.
También permite crear snapshots single de un subvolumen determinado o full del conjunto de subvolúmenes administrados.
Sobre esta base fuimos incorporando restauración segura, automatización, Snapshot Boot mediante GRUB y protección de /boot cuando se encuentra en una partición separada.
La idea nunca fue crear simplemente otra interfaz para ejecutar comandos de Btrfs, sino desarrollar un flujo de recuperación completamente integrado al sistema.
Ahora estamos llevando esa misma filosofía a ZFS, con una implementación adaptada específicamente a su arquitectura.
7. ¿Cómo funciona la restauración segura de synex-snapshots?
Synex Linux: Antes de aplicar cualquier restauración, synex-snapshots valida el conjunto y crea automáticamente un snapshot pre-restore con el estado actual del sistema.
Ese estado puede encontrarse incluso dañado. La idea es conservar exactamente lo que existía inmediatamente antes de realizar la restauración, tanto por seguridad como para poder analizar posteriormente qué ocurrió.
La herramienta permite snapshots single de un subvolumen o full del conjunto de subvolúmenes operativos.
Cada conjunto genera un manifest con metadatos que la aplicación utiliza para identificarlo y validarlo.
Cuando una restauración termina, obligamos a reiniciar el sistema y bloqueamos una segunda restauración hasta que ese reinicio haya ocurrido. De esta manera evitamos encadenar operaciones sobre un estado que todavía no ha arrancado.
Arrancar un snapshot desde GRUB
Además, integramos grub-btrfs. Los snapshots que contienen el root pueden iniciarse en modo de solo lectura directamente desde GRUB.
Si el sistema queda inutilizable debido, por ejemplo, a la eliminación de /etc u otra carpeta crítica, o simplemente deja de arrancar, el usuario puede iniciar un snapshot anterior, abrir synex-snapshots y restaurarlo directamente.
La aplicación detecta automáticamente que está funcionando en modo Snapshot Boot y dirige la operación hacia los subvolúmenes canónicos del sistema instalado.
Incluso si ese sistema perdió su archivo /etc/fstab, la recuperación puede continuar y el snapshot pre-restore se conserva.
En un snapshot single del root se utilizan los /home y /var/log actuales.
En un full que también contenga esos subvolúmenes utilizamos overlayfs para permitir escritura temporal sin modificar el snapshot original.
Si /boot está en una partición ext4 separada, synex-snapshots la preserva en un archivo .tar.zst validado que forma parte del proceso de restauración, evitando tener que repararlo posteriormente desde un sistema live mediante chroot.
Es importante aclarar su alcance: synex-snapshots es una herramienta de rollback basada en copy-on-write y no sustituye una estrategia de copias de seguridad. Los snapshots continúan almacenados en el mismo dispositivo que el sistema.
8. Snapshots automáticos antes de actualizaciones críticas
Synex Linux: synex-snapshots ya incorpora automatización propia.
Los snapshots automáticos son single del subvolumen raíz y cuentan con frecuencia y retención configurables.
Decidimos que los snapshots full se mantengan como una operación manual porque, ante una actualización problemática, normalmente lo que interesa recuperar es el sistema y no reemplazar también los datos actuales del usuario.
El siguiente paso será integrarlo con Synex Package Manager.
La idea es que, antes de determinadas actualizaciones críticas, como una actualización del kernel, SPM pueda ejecutar automáticamente un snapshot preventivo del root.
De esta manera, si una actualización falla o deja al sistema sin arrancar, el usuario podrá iniciar el snapshot anterior desde GRUB mediante Snapshot Boot y restaurarlo fácilmente.
9. ¿Cómo protege Synex Semi-rolling la estabilidad del sistema?
Synex Linux: Estamos tranquilos con la base Testing de Debian. No es tan extrema como otras propuestas rolling release, como Arch Linux u openSUSE Tumbleweed, pero eso no significa que descuidemos las pruebas.
Antes de publicar una release de Semi-rolling, desde el propio proceso de build revisamos escenarios donde pudieron producirse cambios en paquetes o librerías.
Los probamos en un entorno de testing y solamente después continuamos con el build, las pruebas finales y la publicación.
Si aparece algún problema posteriormente, lo publicamos en el foro o en la sección de noticias de nuestra web, incluyendo una solución detallada cuando está disponible.
Un ejemplo reciente fue un problema con configuraciones legacy de GRUB que afectaba al arranque en modo MBR. Recibimos el reporte de un usuario, comunicamos el problema y lo corregimos en la imagen siguiente.
Hasta ahora no hemos tenido escenarios especialmente complicados y esperamos que continúe así.
10. ¿Cómo gestiona Synex la seguridad?
Synex Linux: Synex 13 y Server se apoyan en Debian Stable, mientras que Semi-rolling utiliza Debian Testing.
En ambos casos heredamos gran parte del trabajo de seguridad y mantenimiento que realiza Debian y, para un proyecto de nuestra escala, eso es fundamental.
Cuando aparece un fallo que podría afectarnos, comprobamos si ya ha sido solucionado y realizamos pruebas en nuestros entornos para asegurarnos de que la corrección funciona correctamente en Synex.
Si todavía no existe una solución y contamos con una alternativa viable, intentamos ofrecer una mitigación o un parche provisional y lo comunicamos mediante nuestros principales canales: la web, el foro y el grupo de Telegram.
La realidad es que, para las actualizaciones de seguridad correspondientes a componentes provenientes de Debian, dependemos —como ocurre con muchos proyectos derivados pequeños— del trabajo del propio proyecto Debian.
Nuestra función es integrar, probar y comunicar correctamente esas correcciones dentro de Synex.
11. Un proyecto desarrollado actualmente por dos personas
Synex Linux: Actualmente somos dos personas.
La comunicación está abierta a través de todos nuestros canales, aunque el foro es el medio preferido. Según el tipo de colaboración, orientamos posteriormente al usuario hacia el canal adecuado.
Lo que más necesitamos actualmente es feedback de la comunidad. Puede ocurrir que algo muy sencillo se nos pase, como sucedió con el error relacionado con configuraciones legacy de GRUB.
También tenemos abierto el sistema de tickets de SourceForge para reportar fallos.
En cuanto al código, ya publicamos en GitHub el repositorio con los scripts de compilación de COSMIC y planeamos extender esa publicación al resto de nuestras aplicaciones.
La documentación y las traducciones son otro ámbito donde cualquier colaboración resulta muy valiosa.
Mantenemos el sitio y los anuncios en español e inglés, pero ampliar el proyecto hacia más idiomas no es algo que podamos afrontar solos.
El feedback siempre es bienvenido y resulta muy necesario para nosotros.
12. ZFS, ServerHub, SPM y las próximas novedades de Synex
Synex Linux: Estamos avanzando con la integración de ZFS dentro de synex-snapshots.
Ya disponemos de detección del backend y de las primeras operaciones nativas sobre datasets y snapshots. Actualmente estamos completando el resto para llevarlo al mismo nivel que Btrfs.
Queremos conservar de cara al usuario los mismos conceptos —single, full, automatización y restauración— pero utilizando internamente los mecanismos nativos de ZFS y manteniendo ambos backends separados.
Posteriormente llegará la integración con SPM para generar snapshots preventivos antes de actualizaciones críticas.
Synex Server y gestión de ZFS
En la edición Server estamos ampliando el catálogo de ServerHub y mejorando synex-installer.
También estamos desarrollando synex-zfs-manager, una aplicación destinada a facilitar la administración de ZFS y especialmente de dRAID.
La herramienta podrá proponer arreglos de discos en función del hardware disponible y mostrar las distintas alternativas de manera sencilla.
También está pensada para configuraciones como RAIDZ1, RAIDZ2, RAIDZ3 y otras posibilidades de almacenamiento.
Además, continuaremos mejorando lo que ya tenemos: nuevas funciones para SPM, una integración más profunda entre Calamares y synex-snapshots y la entrega de las últimas actualizaciones de COSMIC, que actualmente constituye una de nuestras prioridades.
13. ¿Qué debería diferenciar a Synex dentro de dos o tres años?
Synex Linux: El diferencial es el enfoque.
Synex está pensado desde lo cotidiano. Las herramientas que desarrollamos y los problemas que abordamos nacen de nuestras propias frustraciones, y entendemos que muchos otros usuarios experimentan situaciones similares.
También existe un componente importante de identidad.
Synex es un proyecto comunitario argentino, desarrollado por dos personas y sostenido con recursos propios.
Esa escala también determina nuestra forma de trabajar: sin cuentas centralizadas, sin tiendas de aplicaciones propias y sin nada que el usuario deba aceptar obligatoriamente para poder utilizar el sistema.
Creemos que existe espacio para proyectos de este tipo y que desde nuestra región también se puede contribuir a un ecosistema donde gran parte de los proyectos tecnológicos procede de Europa o Estados Unidos.
No esperamos un tipo de usuario particular.
Nuestra intención es que Synex pueda utilizarse en cualquier ámbito donde sea necesario disponer de un sistema minimalista, simple y estable que contribuya a ofrecer una mejor experiencia de uso.
Synex Linux continúa evolucionando sobre Debian con una propuesta que combina minimalismo, herramientas propias y tecnologías como Btrfs, ZFS y COSMIC. Su evolución durante los próximos años mostrará hasta dónde puede llegar este proyecto comunitario desarrollado desde Argentina para el ecosistema Linux.
