- Compiler Explorer ha ido cambiando su forma de almacenamiento desde 2012 para que los enlaces compartidos sigan funcionando durante mucho tiempo, pero el cierre de goo.gl hace urgente preservar los antiguos enlaces
godbolt.org/g/abc123 - Al principio guardaba todo el estado del compilador dentro de la URL; en 2014 añadió el servicio de acortamiento de URL de Google y, en 2016, tras la prohibición de URL acortadas en Stack Overflow, creó enlaces puente como
godbolt.org/g/abc123 - Desde 2018, cuando los límites de longitud de las URL se volvieron un problema mayor, pasó a guardar el estado como documentos JSON en S3 y a gestionar el mapeo entre hashes cortos y rutas completas con DynamoDB
- Cuando Google desactive los enlaces de goo.gl en agosto de 2025, será difícil resolver los enlaces antiguos basados en goo.gl, así que están reuniendo en su propia base de datos unos 12,000 enlaces
gencontrados en la web pública y en registros - Si alguien que tiene enlaces viejos de Compiler Explorer los visita ahora, es posible que entren en la lista de preservación; el conocimiento compartido que debe durar mucho tiempo es más seguro cuando se posee directamente la infraestructura clave
Cambios en la forma de guardar enlaces en Compiler Explorer
- En 2012, Compiler Explorer guardaba todo su estado dentro de la URL
- Codificar todo el estado del compilador en la URL hacía que esta se volviera muy larga y difícil de manejar, así que en marzo de 2014 se añadió soporte para las URL cortas de goo.gl
- En ese momento, los enlaces cortos tenían la forma
goo.gl/abc123y, al hacer clic, redirigían a la URL completa de Compiler Explorer, donde luego se decodificaba el estado contenido en la URL
Enlaces puente tras la prohibición de Stack Overflow
- En 2016, Stack Overflow prohibió los servicios de acortamiento de enlaces porque podían ocultar el destino real
- Esta medida también afectó a los enlaces de Compiler Explorer, y en ese momento no había intención de almacenar directamente los datos de los usuarios
- La solución alternativa fue seguir usando goo.gl, pero mostrar a los usuarios enlaces con formato
godbolt.org/g/abc123abc123era el ID único de goo.gl- Al entrar a
/g/abc123, se redirigía agoo.gl/abc123 - Luego goo.gl volvía a redirigir a la URL completa de godbolt.org que contenía el estado
- Más adelante se empezó a usar la API de Google para evitar esas cadenas de redirección de varios pasos
Cambio al almacenamiento propio en 2018
- En 2018, el límite de longitud de las URL se convirtió en un problema aún mayor, y además ya se estaban comprimiendo los datos dentro de la URL
- Compiler Explorer cambió a una estructura donde guarda el estado directamente
- También revisa si el hash corto del enlace contiene palabras ofensivas
- Si aparece una palabra ofensiva, añade información adicional al documento de forma intencional para generar un hash distinto
- Ese comportamiento terminó derivando en el bug #1297
El problema de preservación causado por el cierre de goo.gl
- Compiler Explorer todavía soporta enlaces
godbolt.org/g/abc123 - Google dijo que los enlaces existentes seguirían redirigiendo a su destino previsto, pero goo.gl pasó a ser de solo lectura hace años y su cierre definitivo está previsto para agosto de 2025
- Después de ese cierre, ya no será posible resolver enlaces basados en goo.gl
- Los enlaces
goo.glpropiamente dichos no pueden resolverse del lado de Compiler Explorer, pero los enlacesgodbolt.org/g/abc123sí pueden preservarse en una base de datos propia
Recolección de enlaces existentes y base de datos propia
- Durante los últimos días han estado reuniendo enlaces existentes y sus URL de destino desde varias fuentes públicas
- Hasta ahora han encontrado alrededor de 12,000 enlaces
- API de búsqueda web de Google
- API de GitHub
- Registros web propios
- Volcado de datos de Stack Overflow en archive.org
- Listado de páginas web archivadas por Archive.org
- Internamente ya hicieron un cambio para priorizar su propia base de datos por encima de goo.gl
- También están vigilando nuevos enlaces
gque aún no están en la base de datos - En local usan una base de datos sqlite, y en producción usan Dynamo
Cómo pueden ayudar los usuarios
- Si tienes guardados enlaces antiguos
godbolt.org/g/abc123, ayuda visitarlos ahora - Al visitar un enlace, queda registrado en los logs web y luego podría añadirse a la base de datos
- Si no se hace, ese enlace podría dejar de funcionar después de agosto de 2025
- Este caso muestra el riesgo de depender de servicios de terceros para infraestructura importante
- Para cumplir la promesa de una “URL que dure para siempre”, hace falta ser dueño de todo el stack
1 comentarios
Opiniones de Hacker News
Antes de 2010, daba por hecho que los enlaces se mantendrían para siempre y usaba mucho los marcadores del navegador.
Más tarde descubrí que una buena parte de mis marcadores se había vuelto prácticamente inutilizable por la pudrición de enlaces, y desde entonces empecé a imprimir páginas web como PDF para guardarlas.
Cuando la función de vista de lectura se volvió bastante estable y común, cambié a copiar el contenido de la vista de lectura y guardarlo como archivos RTF.
Uso la extensión SingleFile para archivar todas las páginas que visito.
Es fácil de configurar, pero hay que tener en cuenta que consume mucho espacio en disco.
$ du -h ~/archive/webpages1.1T /home/andrew/archive/webpageshttps://github.com/gildas-lormeau/SingleFile
Si instalas la extensión oficial de navegador de Web Archive, puedes configurarla para que archive automáticamente todas las páginas que visitas.
Mi solución fue recordar el contenido importante en sí, o al menos recordar dónde podía encontrarlo.
Como todavía no me he muerto, supongo que funciona.
Me pregunto si existe una extensión de navegador que, cuando un enlace vence, vaya automáticamente a web.archive.org.
Es realmente absurdo que los navegadores todavía no hayan incorporado esta lección y corregido la función de marcadores.
Cada marcador debería guardar no solo el enlace, sino también una copia completa de la página renderizada. No debería guardar solo el código fuente original, que puede depender de contenido dinámico que ya no existirá.
Las pestañas abiertas deberían funcionar igual. Cuando vuelvo a una pestaña sin conexión a Internet, no quiero ver un error de red solo porque el navegador tuvo la amabilidad de expulsar esa pestaña de la memoria.
En ese caso, hasta que yo recargue manualmente, debería restaurar el estado desde el disco, no desde la red.
En cuanto a Goo.gl, valdría la pena colaborar con el proyecto ArchiveTeam[1].
“El acortamiento de URL fue una idea realmente terrible”[2]
[1] https://wiki.archiveteam.org/index.php/Goo.gl
[2] https://wiki.archiveteam.org/index.php/URLTeam
Así que es muy probable que tengan muchas, o incluso todas, las URL de Compiler Explorer, y parece buena idea contactarlos.
Que las URL duren para siempre era un sueño hermoso, pero en la realidad parece que el 99% de las URL no son eternas.
En vez de seguir librando una batalla perdida, quizá deberíamos construir tecnología sobre la premisa de que la infraestructura no es permanente.
Exacto. Y también hace falta no usar servicios de acortamiento de URL como infraestructura.
Los URN intentaban resolver este problema separando la identidad de un objeto de su ubicación.
Pero no lograron un uso amplio, y luego los servicios de acortamiento de enlaces reimplementaron esa idea de forma pésima.
https://en.m.wikipedia.org/wiki/Uniform_Resource_Name
Los nombres de dominio cambian de dueño con frecuencia, y una URL que debería ser permanente puede convertirse con el tiempo en un enlace malicioso de phishing.
Una URL identifica la ubicación de un recurso en la red, no el recurso en sí, así que no necesita ser permanente ni única.
Por eso se llama “uniform resource locator”.
Este problema ya se había reconocido en 1997, y por eso se creó el Digital Object Identifier.
Hay algo poético en haber abusado de un servicio de acortamiento de enlaces como si fuera una base de datos y luego tener que recuperar enlaces valiosos por todo Internet porque se perdió la referencia original.
Quienes realmente abusan son los que usan servicios de acortamiento para ocultar fraudes, spam y sitios web ilegales detrás de un dominio común y repartirlos por todas partes.
Lo que usaron como base de datos no fue la URL corta, sino sus propias URL, es decir, la parte que contenía el estado del compilador.
https://killedbygoogle.com/
“Google Go Links (2010–2021)”
“Cerrado hace unos 4 años. También conocido como Google Short Links, era un servicio de acortamiento de URL. También admitía dominios personalizados para clientes de Google Workspace. El servicio tenía unos 11 años”
Pero romper también los enlaces existentes es una acción mucho peor. Especialmente si Google todavía lo mantiene de alguna forma para uso interno en sus propias apps.
Es un poco sorprendente que a Google le parezca que vale la pena el esfuerzo de cerrar incluso una versión de solo lectura.
A menos que le preocupen riesgos legales por redirecciones de enlaces privados que sigan en línea.
Para ser sincero, aunque el costo sea trivial, sigue siendo un costo neto, así que parece igual de posible que simplemente lo corten, dejando de lado la buena voluntad o las promesas pasadas.
“Este artículo fue escrito por una persona, pero las sugerencias de enlaces y la revisión gramatical las hizo un LLM”.
Es la segunda vez hoy que veo este aviso de uso de LLM. Parece que estoy viendo el inicio de una nueva moda.
Si el contenido se sostiene por sí solo, basta. Si el contenido es basura, ¿por qué importa si es basura generada por IA o por una persona?
La única razón por la que alguien querría o querría saber una notificación es porque no puede juzgar por sí mismo la calidad del contenido y usa si fue generado por IA como un indicador sustituto de baja calidad.
No me gusta decirlo, pero a menos que intervenga una fundación con fondos muy sólidos, Compiler Explorer y godbolt.org tampoco durarán para siempre.
Para entonces, quizá toda la información ya haya sido destilada dentro de un modelo universal con 487 quintillones de parámetros.
Hasta ahora nos ha ido bastante bien. Esta semana cumplimos 13 años.
Incluso suponiendo que el crecimiento continúe y que todos los patrocinadores actuales se retiren, tenemos fondos para aguantar un poco más de un año.
Dicho eso, sí estoy pensando en algo como una fundación. El punto único de falla no es el financiamiento, sino “yo”.
Es cierto, pero al menos ahora los enlaces de Compiler Explorer se romperán cuando Compiler Explorer desaparezca, no antes.
Creo que los enlaces de Compiler Explorer con más valor para sobrevivir a largo plazo son los que están en reportes de bugs.
Por comodidad enlazo Compiler Explorer en los reportes de bugs, pero también incluyo el código en el propio reporte y especifico el compilador y la versión usados para reproducir el bug.
No espero que Compiler Explorer vaya a desaparecer pronto, pero hacer que los reportes de bugs sean autocontenidos los protege incluso en ese caso.
Gracias al teorema de no ocultación, la información permanecerá para siempre ;)
Probablemente no haya forma de pedirle a alguien dentro de Google que consulte la base de datos y encuentre todos los enlaces acortados que apuntan a godbolt.org.
Mantener un nombre de dominio cuesta dinero, así que no sé cómo una URL podría durar para siempre.
Me pregunto si la muerte de las URL podría ser algo bueno. La humanidad hace un esfuerzo especial por conservar lo bueno, y el resto entra al recolector de basura de la historia.
Los historiadores más bien desearían que hubiera más basura histórica.
Porque así obtendrían más información sobre la vida “real”, no solo sobre las partes que alguien consideró dignas de preservar.
Si pudiera viajar en el tiempo, sería interesante ver cómo los historiadores de dentro de mil años mirarán nuestra época, en la que mucha información desaparecerá sin dejar rastro a medida que los medios digitales se degraden.
Estoy de acuerdo. Hace tiempo escribí algunas ideas relacionadas aquí: https://boehs.org/node/internet-evanescence