Por favor, no arruinen este software con vibe coding
(github.com/RsyncProject)- Este issue terminó en estado Closed, y como era una publicación de reclamo sin pasos de reproducción ni propuesta de corrección en el texto, no se ven ramas, PR ni milestones vinculados
- La queja original era la preocupación de que entraran en rsync cambios con intervención de IA, afectando su estabilidad; el cuerpo se publicó centrado en imágenes, sin explicación textual
- Un usuario reportó que, como log2ram usa rsync, una impresora 3D funcionó al 100% de CPU, y expresó que la IA básicamente introdujo este bug en un robot
- Otro usuario opinó que rsync era una herramienta estable que no necesitaba funciones nuevas ni reescrituras, sino solo actualizaciones de seguridad y correcciones de bugs, y que en las dos últimas versiones patch surgieron problemas que no deberían haber alterado funciones existentes
- Un usuario que usa rsync para trabajo de DFIR explicó que el solo hecho de que la IA participe en las actualizaciones hace que, por política interna, se trate como una “herramienta de IA”, por lo que ahora requiere revisión adicional
- Del lado contrario, respondieron que el issue tracker no es un espacio para quejas virales y que, sin un reporte de bug concreto ni pasos de reproducción, debería moverse a Discussions o hacerse un fork
- El choque principal creció entre la postura de “es software libre, si no te gusta haz un fork” y la postura de que rsync ya es una herramienta de infraestructura crítica, por lo que solo hablar de pinning o forks aguas abajo ya es una señal de problema
- Algunos usuarios mencionaron una reescritura en Rust o un fork, pero otros marcaron distancia diciendo que rsync es valorado por su estabilidad y porque simplemente funciona, y que una reescritura sería otro proyecto aparte
- Quienes defienden el uso de IA pidieron no meter toda mención de IA en la bolsa de “vibe slop”, y exigieron auditar directamente el log de commits desde marzo para verificar por qué se hicieron los cambios
- kaithar explicó que el trabajo reciente incluye correcciones de bugs y fallas de seguridad, además de hardening, como lecturas de memoria no inicializada, overflows/underflows del protocolo wire, timestamps de 32 bits y ajustes relacionados con el estándar de C
- Ese mismo comentario respondió que fijarse en versiones antiguas como 3.4.1 puede dejar a los usuarios en versiones con varios CVE, y que las regresiones pueden aparecer en casos límite que las pruebas no detectaron
- En conclusión, el issue no convergió en una corrección concreta de bugs y quedó como un debate sobre cómo manejar la confianza, auditoría y gobernanza del desarrollo asistido por IA en infraestructura estable de largo plazo como rsync
1 comentarios
Comentarios en Hacker News
Este comportamiento de manada es realmente extraño, y algunos parecen estar actuando de forma irracional. Hasta cierto punto entiendo la motivación de querer “ganar” esta pelea, pero definitivamente esta no es la manera y solo hace que parezcan fanáticos
Basta con buscar regression en la página de issues y revisar los 17 resultados; toma 5 minutos. Incluso podría haber más en el rastreador que usaban antes de GitHub
Este comportamiento es muy tonto, y parece que la gente intenta aferrarse a cualquier cosa posible para justificar su odio a la IA. Parece que olvidaron que la gente también cometía errores antes de la IA
Si hay evidencia de que la IA aumentó de forma significativa los issues no resueltos de rsync, me gustaría verla. Entonces con gusto cambiaría de opinión
Puede que no sea la causa directa de este commit, pero podría ser una reacción a otros problemas acumulados, y eso en sí mismo debería tomarse en cuenta
Da la impresión de que la gente está cansada de tener que tragarse a la fuerza discursos tipo “la IA es lo mejor desde [metáfora cultural]”, y quiere resistirse agarrándose de cualquier pajita; me parece una reacción bastante normal
Si nadie expresa la preocupación de que los usuarios no confían en la IA, ¿cómo se va a enterar el mantenedor? rsync era muy estable. ¿La gente debería simplemente pasarse en silencio a Openrsync y no decir nada?
Uno de esos enlaces lleva a una recopilación mayor de bugs reportados en distribuciones derivadas (https://github.com/void-linux/void-packages/issues/60825)
Dada la reputación del software hecho con vibecoding, la indignación es muy razonable. Incluso expertos a los que uno respeta dicen cosas como “para que no meta bugs hay que manejarlo de una forma muy específica, y probablemente conviene usarlo solo para una versión 0 para explorar el dominio”
Y aquí lo que está pasando es que la herramienta central de backups estándar de la industria está siendo saboteada de forma claramente insegura por la intención de un mantenedor de “agregar más funciones”
En el hilo de Timeshift también se menciona que “después de actualizar rsync, el uso de CPU durante los backups diarios se volvió tan excesivo que tuve que detener timeshift porque parecía ejecutarse para siempre”
Dicho de otro modo, la herramienta a la que la gente confiaba sus backups y sus datos está rompiendo toda su infraestructura de respaldo con una enorme cantidad de regresiones y bugs nuevos, y están frustrados y enojados porque la razón es que el desarrollador principal está haciendo vibecoding
Incluso expertos en vibecoding como Simon Wilson aclaran explícitamente que esto solo funciona “cuando se maneja la herramienta de cierta manera”; así que o este mantenedor no lo está haciendo así, o esa afirmación no es cierta
Si de verdad lees ese hilo y no solo hojeas la parte donde dos personas se pelean, hay varios reportes de usuarios en entornos industriales y gubernamentales que tienen que volver a pasar por todo el procedimiento para actualizar este software. El software se volvió inmediatamente poco confiable y causó daño directo a los usuarios, socavando la razón misma de existir de ese software
Si yo también le hubiera confiado a este software más de 500 GB de backups, estaría enojado, y me preguntaría cuántos problemas más habrán entrado y no saldrán a la luz hasta que una empresa, por no probar sus backups de forma constante, sufra una pérdida de datos de 10 millones de dólares
De verdad no lo entiendo
Hay software sólido que usan muchísimas personas y servicios. Funciona bien, cumple su función y, de vez en cuando, solo necesita actualizaciones menores para corregir bugs
¿Por qué hace falta IA aquí?
Además, tampoco entiendo por qué la gente dice “haz un fork y usa la versión anterior”. Debería ser al revés. Deberían hacer un fork paralelo tipo younamethetool-ai y no tocar el original
¿Ahora tengo que hacer fork y mantener yo mismo todas mis herramientas del sistema?
Quejarse en el issue tracker, sin pruebas, de que la IA está arruinando el software es una forma del acoso a contribuidores de open source que se discute con frecuencia en Hacker News [1]
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“El issue tracker no es un lugar para cosechar publicaciones virales de redes sociales. Reporta un bug accionable o haz tu propio fork. Desahogarte sobre las decisiones de los desarrolladores no es productivo”
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
“@II-Paulus-II, detente. No sabes nada. Has desplegado cero funcionalidades a mano. Nadie depende de tu código. No eres más que alguien que señala ‘esto lo escribió una IA’ mientras se esconde detrás de una superioridad moral basada en escribir proyectos de juguete y scripts desde cero. No sabes desplegar, no sabes adaptarte y tampoco entiendes que el issue tracker no es lugar para esa actitud”
[1] https://news.ycombinator.com/item?id=43077833
No lo leí en detalle, pero la frase “En esta versión se corrigieron 6 CVE. Los seis fueron asignados por VulnCheck como CNA. Las versiones afectadas son, en todos los casos, la 3.4.2 o anteriores” parece una respuesta bastante fuerte al “¿por qué?”
https://download.samba.org/pub/rsync/NEWS#3.4.3
La primera reacción, obviamente, sería querer decirles que se vayan a otro lado
Si el “público” quiere tomar el proyecto y mantenerlo, puede hacer un fork, pero es un trabajo poco agradecido
Además, en un proyecto open source ni siquiera hace falta una razón para cambiar las herramientas que usa, y tampoco te deben esa razón a ti
La forma en que se abrió ese issue es realmente desagradable, pero no entiendo por qué parece que los mantenedores soltaron IA sobre rsync. ¿Por qué harían eso? Ya tenían reputación y confianza, lideran un nicho específico, están libres de presión del mercado, a la gente le gusta la herramienta y hace exactamente bien lo que tiene que hacer; ¿por qué intentar con un montón de cosas experimentales relativamente innecesarias?
Es como ese breve monólogo de Matrix sobre cómo la mente humana primitiva no puede aceptar el paraíso. Usaron una herramienta perfecta, ganaron, son casi irremplazables en su nicho, son confiables y, metafóricamente, se volvieron un nombre que todo el mundo conoce. Apostar eso o meterle mano no tiene sentido para nadie y de verdad desconcierta
Aun así, hacerlo así en el issue tracker oficial sigue siendo una conducta realmente desagradable. La actitud es mala y no parece haber buena fe
Pero ahora la IA no parece un positivo neto en ningún lado, y veo esta reacción contra el uso de IA generativa como una buena corrección de rumbo por parte del público
Hay textos que hablan de la gratificación instantánea del uso de LLM, y cuanto más interactúo con gente que usa estas herramientas, más pienso que este realmente puede ser el problema central. Nuestra biología no da para manejarlo
Veo a personas originalmente muy inteligentes haciendo cosas realmente tontas porque una tragamonedas se los dijo, e incluso entrenadas para quedarse impotentes cuando la tragamonedas falla
A mí me tratan como un ludita que no ve el progreso, mientras veo a colegas crear benchmarks sin sentido y pegarles gráficas bonitas hechas con IA
Entonces tengo que elegir entre sonreír y fingir que es buen trabajo, o regañarlos porque el benchmark es inútil ya que prueba una sección fijada como constante. En cualquiera de los dos casos termino tratándolos no como colegas inteligentes, sino como niños de 7 años
Estén los mantenedores de rsync en cualquier punto entre mantenedores perfectos y responsables o niños incompetentes, en realidad no lo sabemos
Pero, aun a riesgo de desviarme un poco del tema, se me ocurre esto. Dejando de lado que software maduro como Rsync no necesita movimiento por movimiento como cantidad de líneas de código cambiadas, supongamos que los mantenedores administran el proyecto con la mejor intención posible
Si esto está pasando en el código abierto, ¿en qué estado estará la calidad del software cerrado?
El uso de IA, es decir, el volumen de prompts, entra en las evaluaciones de empleados como si fuera una métrica de éxito, y la gente está en pánico por la amenaza de despidos masivos causados por la IA
Da vértigo
https://github.com/RsyncProject/rsync/issues/929#issuecommen... muestra que ya no funciona en Darwin antiguo ni en Linux < 5.6, y Linux 5.6 es una versión que quedó programada para obsolescencia en 2020. También hay algunos otros bugs
No se puede esperar que el mantenedor soporte sistemas antiguos y conozca todos los efectos que tendrán los cambios. Da igual si lo hizo con IA o a mano
Por cierto, el bug en sí entró en 30656c5e, generado por Claude Code, y probablemente vino acompañado de una revisión y pruebas inapropiadas
https://github.com/RsyncProject/rsync/commit/30656c5e
Alguien usó IA para hacer bisección reciente de rsync: https://github.com/themgt/rsync-compare-link-dest-341-343-re...
Intento de alguien más por arreglarlo con más Claude Code: https://github.com/RsyncProject/rsync/pull/930
Ticket relacionado: https://github.com/RsyncProject/rsync/issues/915
Recomiendo agregar más pruebas de regresión al commit justo anterior a 30656c5e y luego hacer rebase hacia adelante manteniendo la funcionalidad
Esto no era una “nueva función no deseada”. Tridge estaba arreglando un problema de seguridad relacionado con el reporte del bug. Lo entiendo. A todos nos están golpeando los problemas de seguridad. Arreglarlos no es opcional
No diría que sea divertido volver a software de hace 10 años para lidiar con esto, así que impresiona que tridge esté haciendo el esfuerzo
Yo también soy culpable de usar LLM para salir de este tipo de caos. No sé qué hace tridge, pero yo reviso línea por línea el código que escupe el LLM. Aun así, el riesgo de que se cuele un bug sigue siendo claramente alto
Hace mucho que no veía ese código y ya no lo conozco como antes. Así que no sería una gran sorpresa que se filtraran bugs
Lo raro de toda esta explosión es que la persona que presentó la queja original parece muy empeñada en proteger su sistema de respaldo, pero el commit de tridge era de hace apenas 2 semanas. Sabemos que tridge es excelente, pero ¿no habría que tratar esto como software alfa, obviamente? ¿Qué estaba pensando? Quizá esa persona también necesite aprender un poco sobre cómo construir sistemas confiables
Hace unos años, la probabilidad de que un post de este tipo llegara a la portada de Hacker News habría sido casi cero. Independientemente de si el contenido es correcto o no, era porque aquí no estaba lleno de gente común que no entiende qué tipo de comportamiento es inaceptable
De lo que se habla aquí es del lenguaje violento del issue. Pero ahora estamos rodeados de personas que ni siquiera pueden distinguir lo más obvio
Esa no es manera de decirle a un mantenedor que no estás de acuerdo con la dirección del proyecto. Este issue es completamente inútil. Habría sido mejor un reporte de bug de algo “arruinado por vibe coded”
Eso dio justo en el clavo. Ningún reporte de bug intenta siquiera documentar la supuesta regresión de --compare-dest=. Aunque hagas Ctrl-F, no parece que nadie vuelva a mencionar “compare-dest”
La gente que deja comentarios inútiles de indignación contra la IA podría haberle pedido a Opus 4.8 que ejecutara rsync 3.4.3 y 3.4.1, documentara a fondo la regresión y encontrara el commit que la rompió con git bisect, para producir un reporte de bug 1000 veces más profesional y útil
Si la sociedad quiere que el trabajo humano sea visto como más valioso que el trabajo de la IA, conviene evitar hacer tonterías que solo los humanos pueden hacer
¿No será que llegó a portada porque otras personas sienten algo parecido respecto a un software que usan todos los días para trabajo importante?
Es cierto que un issue de GitHub puede ser algo trillado, y claramente es una tarea poco agradecida, pero en la práctica rsync es la piedra angular de muchos pipelines sensibles
Si de verdad crees que está fuera de tema, la respuesta cortés es cerrar el issue
Todavía no me queda claro qué es tan evidente. Para mí, “detente. No sabes nada. Has desplegado cero funciones a mano. Nadie depende de tu código” suena mucho más violento que “please do not vibe fuckup this software”
¿Alguien en ese hilo del issue llegó a explicar cuál era realmente el problema? Me refiero a pasos de reproducción, comportamiento esperado y comportamiento real
Esto fue publicado en un rastreador de issues. “El mensaje del commit menciona a Claude, y una persona en Bluesky cree que cierto problema no especificado que tuvo está relacionado con esos commits” no es un issue accionable
Dejando de lado todo el resto de la discusión, si fuera mi proyecto yo lo habría cerrado y bloqueado por “falta de información para reproducir”. Hay mejores lugares para discusiones generales sobre IA, forks o desahogos de enojo
Los usuarios de Linux < 5.6 no pueden compilar desde GitHub. Me parece una regresión bastante menor. La gente que usa versiones mantenidas de 5.6, sobre todo versiones de seguridad extendida, probablemente tiene mantenedores de su distribución que pueden detectar el fallo de compilación y corregirlo a tiempo
El endurecimiento contra ataques de path traversal provoca fallos para usuarios que usan el protocolo nativo de rsync sin chroot. Irónicamente, no se recomienda mucho usar chroot = no
Uno podría incluso recomendar no usar rsync nativo de forma automatizada, o directamente no usarlo. El CVE que corrige ese commit aplica precisamente a ese caso de uso
https://www.cve.org/CVERecord?id=CVE-2026-29518
Se necesita daemon + no chroot. “daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.”
Así que el workflow afectado es el más vulnerable, y aun así la gente está recomendando volver a una versión anterior
Además, si una prueba de regresión debería haber detectado esto, entonces esa prueba tendría que haber existido desde antes
Parece que algunos han olvidado de qué tratan los proyectos FOSS
“15. Exención de garantía
En la medida en que lo permita la ley aplicable, no hay garantía para este programa. Salvo que se establezca por escrito lo contrario, los titulares del copyright y/u otras partes proporcionan el programa ‘tal cual’, sin garantía de ningún tipo, expresa o implícita, incluyendo, pero sin limitarse a ello, las garantías implícitas de comercialización e idoneidad para un propósito particular. Todo el riesgo respecto de la calidad y el rendimiento del programa recae en usted. Si el programa resulta defectuoso, usted asume el costo de todo servicio, reparación o corrección necesario”
Me reservo el derecho de quejarme, refunfuñar, criticar, enojarme o comentar de cualquier otra forma sobre todas y cada una de las decisiones, commits, parches, marketing u otras decisiones que tome el proyecto. Dichos comentarios no garantizan idoneidad para ningún propósito, ni incluyen garantía implícita de ser correctos, útiles o amables. Si mis comentarios resultan no ser deseados, usted se reserva el derecho de metérselos donde no da el sol
Está bien imprimir esta cláusula de exención para consultarla cuando uno se encuentre con críticas no deseadas a proyectos FOSS
No entiendo por qué la gente no comprende que la actitud de “pueden hacer lo que quieran” funciona en ambos sentidos. Los usuarios también pueden hacer lo que quieran. Si no les gusta, pueden expresarlo
Uno de los comentarios del issue lo decía así
“Que le des sopa gratis a una persona sin hogar no significa que esté bien orinar en ella”
Ese issue ya se convirtió en un desastre, y tu argumento ya apareció ahí. Todos podrían haberlo manejado mejor, pero citar a ciegas texto legal no lo resuelve ni lo mejora
Ya voy por la tercera publicación de HN sobre este tema. Cada vez se repiten los mismos tuits, o esa clase de publicaciones de Mastodon/Bluesky o como les llamen. ¿Alguien realmente depuró el problema?
¿La causa fue código generado de forma descuidada, o fue una corrección de seguridad legítima que lo rompió por accidente? Es decir, de una manera que una persona también podría haber hecho
Esta histeria anti-IA es un típico pánico moral
Como en todo pánico moral, si el punto 1 es cierto o no es totalmente secundario. Lo esencial es obtener una especie de liberación casi sexual en el punto 2
En este caso, sé que hay código generado por IA en rsync. Como ya lo hay, a estas alturas, en la mayoría del software útil. Pero en internet vemos una cacería de brujas todos los días, y como en toda cacería de brujas, importa poco si la acusación es cierta. La histeria en sí es el objetivo
La ira que aparece alrededor de la IA no existe porque el público esté mal informado o porque el mensaje esté mal planteado, sino por una cuestión de realidad física
Esta sola cosa se está usando como pretexto para despidos masivos, los CEOs tecnológicos casi a diario dicen que también van a quitarle el trabajo a todos los demás, y las grandes empresas de la nube están absorbiendo todo el oxígeno de la habitación. Ni siquiera la industria de los videojuegos estuvo a salvo
Ver esto como “solo un pánico moral típico” es como ver hacia qué lado se retira el mar y correr de frente justo en esa dirección
Si sigo leyendo, la misma persona también usa lenguaje emocional como “cacería de brujas” e “histeria”
¿De verdad esto es una cacería de brujas? ¿Y realmente se puede saber si la gente del otro lado de internet está sintiendo algo cercano a una liberación sexual?
¿No estarás respondiendo al lenguaje emocional y al razonamiento flojo de otras personas exactamente de la misma manera?
¿Desde cuándo los issues de GitHub se volvieron un lugar para subir capturas de publicaciones de otras plataformas?
Este tipo de comportamiento solo lo había visto en lugares donde se suben memes o contenido de entretenimiento
No hay un reporte de bug accionable ni una solicitud de funcionalidad. Tampoco hay una versión en texto. Ni siquiera hay enlace a la publicación original
¿La persona que subió esto confundió GitHub Issues con su cuenta personal de Twitter?