Linux Sin Humo (Publicaciones sobre reflexion)

Upstream, Appstream y DownStream

sebelk — Fri, 25 Dec 2020 22:43:16 GMT

La manera tradicional que tenemos para instalar software en los entornos de escritorio de Linux es usando las herramientas de línea de comando o tal vez herramientas gráficas tales como Synaptic y dnfdragora.

Este tipo de instalación a la que los usuarios de Linux de unos cuantos años estamos acostumbrados no es ni más fácil ni más difícil que buscar aplicaciones, bajarlas y correr un instalador y presionando los botones "Next", "Next"...

Sin embargo, la mayoría de los usuarios finales en la actualidad suelen instalar aplicaciones desde centros de software desde teléfonos celulares, los famosos App Stores, tales como Google Play y Apple App Store.

Como respuesta los dos entornos de escritorio principales de Linux cuentan con herramientas similares: Software (GNOME) y Discover (Plasma) para crear una experiencia de usuario similar:

Este clase de programas usan no solamente el sistema de paquetes de la distribució (sea tanto repositorios oficiales como así también de teceros), sino además, pueden usar sistemas como flatpak y snapcraft.

Debajo de estas herramientas tenemos a AppStream la cual proporciona metadatos universales de aplicaciones. Se trata de una especificación de freedesktop.org que resulta beneficiosa tanto para desarrolladores como para usuarios finales.

Photo by Good Free Photos on Unsplash

Puede tratar de manera específica a cada componente de acuerdo a su tipo: aplicación de escritorio, complemento, codec, fuente, etc.

Estos metadatos se guardan en archivos XML. En Fedora, por ejemplo podemos encontrar estos archivos en:

/usr/share/app-info/
/usr/share/metainfo/

De acuerdo a las directrices para empaquetar software de Fedora, toda aplicación con interfaz gráfica tiene que tener un archivo *.appdata.xml

Debian usa un único archivo YAML en lugar de XML, en Debian Buster para plataforma AMD64 se encuentra en /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_dep11_Components-amd64.yml.gz.

Estos archivos suelen contener un identificador, nombre, resumen, icono que representa al componente, descripción, categoría, información de versiones. También puede indicar si el componente es esencial para el funcionamiento de un entorno de escritorio y capturas de pantalla. Incluso ofrece el soporte para que el usuario califique la aplicación.

Es muy importante contar con la metadata de las aplicaciones de modo que appstream y programas como Discover y Software funcionen correctamente. Por ejemplo, en el caso del repositorio rpmfusion es necesario instalar un paquete aparte: dnf install rpmfusion-free-appstream-data.noarch

En la actulidad un usuario puede buscar una determinada aplicación del proyecto KDE e instalarla desde KDE's Applications. Supongamos que encuentra a Calligra Stage y decide instalarla:

Es decir, se puede ver que tiene el siguiente URI: appstream://org.kde.calligrastage.desktop al ser una herramienta totalmente agnóstica puede usar tanto un repositorio tradicional, como los de flatpak y snapcraft. Es decir, es importante entender que appstream no es un método nuevo de empaquetar software o un nuevo tipo de repositorio. Si la aplicación no está en los repositorios mencionados, obviamente la instalación fallará.

Es decir, luego en Discover:

También, podríamos instalarla directamente usando appstream:

appstreamcli install org.kde.calligrastage.desktop

Para ver el estado:

Podemos ver entonces que appstream funciona como un puente bidireccional, los proyectos upstream pueden facilitar el empaquetamiento y disponibilidad de aplicaciones, y cada distribución (downstream) puede dar a conocer de una manera mucho más amigable el software para los usuarios finales creando un círculo virtuoso.

Fuentes y Más Recursos

¿Es btrfs el sistema de archivos que estábamos esperando?

sebelk — Sun, 13 Dec 2020 20:03:26 GMT

Digásmolo: btrfs es un sistema de archivos moderno para Linux.

Alguien leyendo esto seguramente va a pensar:

¿Qué está diciendo? ¿Cuál es la novedad? ¿Acaso no se puede rastrear los orígenes de btrfs por lo menos hasta el año 2007? ¿No es cierto que SUSE lo usa desde 2012?

Photo by Nathan Dumlao on Unsplash

Sí, todo es cierto, sin embargo, veamos la siguiente tabla:

Año	Filesystem
1993	XFS
1993	NTFS
1998	HFS+
1998	FAT32
2005	ZFS
2006	exFAT
2008	ext4
2009	btrfs
2016	APFS

La fecha de btrfs la situamos en 2009, ya que fue el año en que fue incorporado en Linux. En comparación a los demás sistemas de archivos de Linux es el más moderno (sí, ya se que existe stratis). Otro objetará diciendo que cronológicamente no hay mucho diferencia entre ext4 y btrfs. Sin embargo, leamos lo que dijo Theodore Ts'o:

Aunque ext4 tiene características mejoradas, no es un avance significativo, usa tecnología vieja y es una solución a corto plazo.

Y respecto a btrfs tuvo estos comentarios auspiciosos:

ofrece mejoras en escalabildad, confiabilidad, y facilidad de administración

Ah, ¿Ya dije que Ts'o es uno de los principales desarrolladores del sistema de archivos ext4?

Comparado con los demás sistemas operativos la ventaja es mucho más clara (HFS+ y NTFS). El sistema de archivos APFS es cierto es relativamente nuevo y apareció junto con macOS High Sierra. Es decir: Apple se tomó casi 20 años en crear un nuevo sistema de archivos. También hay que decir que en cuanto a funcionalidades, APFS y btrfs están prácticamente igualados.

Btrfs ofrece una buena cantidad de características, las que me parece importante resaltar son:

Subvolúmenes: Es un directorio que funciona como un volumen. Como tal, tiene su propia espacio de inodos. Por ejemplo:

Cada uno de estos archivos muestran un dispositivo diferente:

No obstante, cabe aclarar que no son dispositivos de bloque distintos como podría ser un volumen lógico en LVM.

Cada subvolumen puede ser montado con diferentes opciones e incluso en un +arbol completamente independiente para el usuario o aplicaciones que accede al mismo.

CoW: Los usuarios de Linux estamos acostumbrados a usar enlaces duros y enlaces simbóicos. Cada uno tiene sus ventajas y limitaciones. Esta funcionalidad permite copiar un archivo usando otro inodo pero sin consumir más espacio, ya que referencia en realidad al archivo original. Si se hace una modificación en la copia, los metadatos comienzan a apuntar a los nuevos datos. Gracias esta característica podemos hacer subvolumenes que contengan una instantánea de otro subvolumen existente. Todo esto de una manera mucho más consistente que con LVM.
Compresión: Otra de las ventajas es la compresión transparente, la cual puede ser por el sistema de archivo entero, por directorio o por archivo (pero por ahora, no por subvolumen).

Hay muchas razones para creer que btrfs puede y/o debería reemplazar a ext4 o xfs. De paso recordemos que xfs no soporta achicar un sistema de archivos y si pensamos zfs como una buena opción, hay problemas tanto de licenciamiento como en rendimiento (ver el artículo de Valerie Aurora, creadora de relatime y autoridad en la materia). Las ediciones de Fedora 33 para estaciones de trabajo y SUSE/openSUSE usan btrfs como sistema de archivos predeterminado. De esta manera podríamos prescindir de LVM e incluso de mdadm para RAID (btrfs tiene su propio soporte para RAID - aunque hay que tener en cuenta que RAID[56] no se considera estable aun). El proyecto btrfs debería tener cuidado de sí mismo, tiene tantas funcionalidades que como dice el dicho "lo perfecto es enemigo de lo bueno" (Ah, por cierto el autor de la frase es de Voltaire, alguien que precisamente no se conformaba con poco). Es decir, el único riesgo que veo en el futuro es convertirse en algo tan complejo que sea difícil de administrar o mantener. Veremos en unos años si logra posicionarse como el sistema de archivos de código abierto más utilizado.

Fuentes y más recursos

Un abrazo peligroso

sebelk — Sun, 24 May 2020 22:33:34 GMT

¿Cuán genuino es la movida de Microsoft hacia el Software Libre?

Photo by Samuel Scrimshaw on Unsplash

Recientemente Dona Sarkar dijo:

Windows no puede ser de código abierto por cuestiones como pueden ser nuestras políticas de privaciad y protección de datos. Un proyecto que empieza siendo de código abierto puede mantenerse así, pero uno que ha nacido dentro de un entorno cerrado, es más difícil de abrir.

Aquí nos presentamos con una falacia. Primero: ¿qué tiene que ver las políticas de privacidad y protección de datos con la apertura del código fuente?

Cualquiera con un mínimo de conocimiento profesional en informática encontrará esa explicación problemática.

¿Qué impedimentos tiene que tener el código fuente de un programa para contravenir las políticas de privacidad y protección de datos?

A mi en principio se me ocurren solamente dos, supongamos que tenemos un programa llamado ABC123 de la empresa ficticia Example Inc. Puede ser el que el código fuente utilce código patentado por otra empresa llamado AnotherOne Inc. En algún momento de la historia Example Inc. y Another Inc. hicieron un acuerdo de no revelación de código fuente.

Ese puede ser perfectamente un obstáculo para la revelación del código fuente. Pero claro en ese caso no tiene nada que ver con el interés por privacidad o la salvaguarda de los datos de los usuarios.

Otra posibilidad que sería ciertamente nefasta es que el programa almacene datos sensibles de las personas.

El código fuente de acuerdo a Wikipedia es

Es cualquier colección de código, posiblemente con comentarios escrito usando un lenguaje de programación legible por humanos, usualmente como texto plano.

Es decir, el código fuente es escrito por los programadores, los datos no forman parte y no debería haber razones para considerarlo así. Y si alguien considera que los datos sí forman parte es grave porque están utilizando los datos del usuario con fines comerciales.

Y el funcionamiento del programa ABC123 está desarrollado de una manera en el que sea imposible disociar los datos de del resto del código está ciertamente mal diseñado y el usuario está siendo damnificado por esa situación.

Lo cierto es que hasta ahora nadie le ha preguntado seriamente a Microsoft por qué no libera el código fuente de Windows.

Fuentes:

El principio de Le Châtelier

sebelk — Sun, 03 May 2020 21:37:52 GMT

Ya siendo adolescente me fascinaba el principio de Le Châtelier que enuncia:

Si se presenta una perturbación externa sobre un sistema en equilibrio, el sistema se ajustará de tal manera que se cancele parcialmente dicha perturbación en la medida que el sistema alcanza una nueva posición de equilibrio.

No siempre los equilibrios son ventajosos, a veces necesitamos romperlo para conseguir un beneficio.

Jan Tinneberg

¿Qué sucede si pensamos esto en términos sociales?

De hecho, hay un principio similar en economía formulado por Paul Samuelson en 1947. En biología este concepto se conoce como homeostasis.

Probablemente, la humanidad nunca estuvo ante una perturbación del equilibrio desde la segunda guerra mundial o incluso desde la caída del muro de Berlín.

¿Qué está haciendo hoy el equilibrio para restablecer el equilibrio? Creo que es una pregunta.

Es importante que nuestros dirigentes estén en el aspecto ético a la altura de las circunstancias. Pero entendiendo también que viejos conceptos son insuficientes. Una discusión entre "más estado" o liberalismo no alcanza. Es importante entender el grado en que la tecnología hoy nos rodea. Para qué se usa. Quienes son los dueños.

En un tiempo en que todos corremos detrás de los servicio de Internet, creo que más que nunca tenemos que hacernos preguntas sobre ella. Cuestionarnos la obsesión por los datos, por la rapidez vacía de resultados benéficos reales sobre las personas.

Un tiempo para que podamos descubrir que un empleado feliz puede ser más creativo y más productivo. El trabajo del hombre respetando a la naturaleza y por ende al mismo hombre contenido en ella.

Por primera vez después de mucho tiempo empezábamos a perder la vergüenza de decir que las personas son más importantes que las ganancias económicas.

Sin embargo, pudimos ver claramente en los últimos días como han aparecido las fuerzas que pretenden restablecer un equilibrio que perjudica a las grandes mayorías, dentro las cuales están los que menos tienen.

Enlaces de Interés

Cuestiones con VirtualBox

sebelk — Wed, 18 Mar 2020 23:02:07 GMT

Hay ciertos detalles a vece que necesitamos pulir al usar VirtualBox, por ejemplo:

Photo by Ales Nesetril on Unsplash

Al usar VirtualBox 6.1 aparecen los siguientes errores:

[drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send host log message.

Este error parece inocuo, tiene que ver con el driver de la tarjeta de video, la cual está en VMSVGA, el indicado para Linux.

el otro error es:

"failed to start Cgroup management daemon."

Lo que hice fue desinstalar paquetes obsoletos:

apt-get purge upstart libcgmanager0 cgmanager

Otro inconveniente menor suscitado es la baja resolución luego del login:

Probé aumentarle la memoria para video del guest a 32 MB, pero el problema persistía. Entonces creé un usuario de prueba que no presentaba ese problema y comparé los datos que me daba el comando:

gsettings list-recursively

para ambos usuarios.

No encontré diferencias. Entonces, comparé ambos directorios y borré el archivo $HOME/.config/monitors.xml del usuario con dicho problema y efectivamente, logré solucionarlo de ese modo.

El Open Source Bajo la Lupa

sebelk — Tue, 22 Oct 2019 20:39:41 GMT

Hay un artículo¹ escrito por Don Goodman-Wilson empleado de Github y miembro de Maintainerati. Ha sido sumamente inspirador por un lado y, ¿por qué no? pone en palabras cosas que uno viene elaborando hace rato.

Tim Marshall

DGW lanza una ataque demoledor sobre la OSI (Iniciativa del Open Source) al afirmar que facilita la concentración en manos poderosos a expensas de la explotación de los desarrolladores y está muy lejos de propiciar la democratización que declama.

Se propone el autor del post reemplazar ideologías centradas en el código por gente-céntricas. En síntesis: si las elecciones que tomamos respetan a los seres humanos son correctas, de lo contrario no lo son. Y que la ideología del Open Source cosifica.

La crítica más contundente que hace sobre el código abierto es que explota trabajo no remunerado. Y ese modelo dice, es insostenible.

Cita algunos casos interesantes que contraponen esta supuesta neutralidad del software:

La licencia de JSON
La licencia de 996.ICU
La licencia hipocrática de Coraline Ada Emke

Algunos principios para iniciar algo nuevo

Los responsable de un proyecto de software merecen ser tratados como personas.
La tecnología existe para servir a las necesidades humanas.
Los valores del código abierto tienen que servir a la comunidad

El código fuente es un dogma al que no le interesan las personas.

Y se termina preguntando:

¿Cómo luce un modelo colaborativo centrado en las personas, de desarrollo de software abierto?

Quiero agregar como opinión personal que mi posición está muy alejada de "software libre" bueno, "open source" malo. No hay mucha distancia de lo que proponen los caprichos del stallmanismo. Según él, lo más importante es la libertad del software. El centro no son las personas. Pero bueno, eso da para otro post.

Open Source is Broken - DEV Community ↩

GNU y Linux

sebelk — Wed, 15 May 2019 22:35:15 GMT

Retomo esta controversia sobre el nombre del sistema operativo. ¿Cómo deberíamos llamarlo GNU/Linux o Linux? Como obedeciendo un mandato religioso, muchos siguen escribiendo GNU/Linux. ¿Tendrá importancia? Bueno, tal vez no tanta como le podría asignar Richard Stallman, pero creo que sí porque tiene que ver justamente con la libertad de la que tanto declama el presidente y fundador de la Free Software Foundation.

La posición de Stallman y sus seguidores dice que debería llamarse GNU/Linux¹, la otra sostiene que Linux es la denominación correcta. Los primeros sostienen que GNU/Linux hace justicia el hecho de que Richard Stallman tenía como propósito crear un completo sistema operativo llamado GNU. Y dado que Linus Torvalds solamente aportó el núcleo del sistema operativo a un conjunto de herramientas pre-existentes el nombre debe ser compuesto. Desde la visión opuesta² dicen que es tan grande la cantidad de componentes en una distribución de Linux que siguiendo ese razonamiento tendríamos nombres bastante complejos como Plasma/KDE/Xorg/GNU/Linux.

Además, desde ambas partes nos recuerdan que hay sistemas con núcleo Linux que no poseen las herramientas GNU, por ejemplo, Android.

La posición GNUista tiende a minimizar la importancia de Linux: "es sólo un kernel". Cabe recordar que el núcleo Hurd recién comenzó a estar apenas usable 10 años después de la creación de Linux y 18 años más tarde del surgimiento del proyecto GNU³. De hecho, en la actualidad no tiene la madurez que se espera para un sistema operativo productivo⁴.

CentOS⁵ saca provecho del código fuente de Red Hat para crear una distribución de Linux. Hago hincapié en este ejemplo en particular, ya que no hay pretensión de originalidad en el proyecto. De hecho me animaría a decir que es un caso extraordinario de aprovechamiento de la la licencia GNU GPL. Dicen, frente a la pregunta si le hacen alguna modificación a las mismas

No. El mandato esencial de CentOS para nuestros repositorios base y de actualizaciones es NO extender o mejorar los paquetes o funcionalidades más allá de las que suministra los RPM's fuente del upstream (es decir Red Hat). CentOS se esfuerza intencionalmente en proporcionar funcionalidad binaria a nuestros usuarios. CentOS ofrece otros repositorios (opcionales) ⁶

A nadie se le ocurriría llamarlo Red Hat/CentOS.

Ubuntu está basada en Debian y nadie hablar de Debian/Ubuntu.
OS X deriva de Darwin y este a su vez de FreeBSD. A nadie se le ocurriría llamarlo de FreeBSD/Darwin/OS X.

En realidad, muchas distribuciones ni siquiera usan el nombre de Linux. ¿Alguien se ha quejado por eso? En cambio si es frecuente leer cosas como GNU/NetBSD por citar apenas un caso. Es injustificable esa diferencia. Creo que Stallman confunde el reconocimiento hacia el proyecto GNU con el derecho que cada uno tiene para iniciar un camino paralelo.

¿No es acaso Linux ejemplo de la famosas libertades del software reclamadas por el movimiento del software libre?: la libertad 1 de :

"...estudiar cómo funciona el programa, y cambiarlo para que haga lo que usted quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello. ⁷

Y la libertad 3 de :

La libertad de distribuir copias de tus versiones modificadas a otros. ⁷

Más aún, creo que Stalmann está en todo su derecho a llamarle GNU/Linux. Pero presionar a otros para que se adapten sus deseos de uno, no tiene nada que ver con la libertad.

Información adicional:

¿Por qué GNU/Linux? - Proyecto GNU - Free Software Foundation ↩
4 Opinions supporting "Linux" ↩
Linux y GNU - Proyecto GNU - Free Software Foundation ↩
status Podríamos seguir profundizando cada uno de los argumentos, pero creo que el eje de la discusión es totalmente errado. Los stallmanistas insisten en cuestión de reconocimiento, algo que no tiene nada que ver en este asunto. No es una cuestión de reconocimiento. ¿Desde cuando los nombres son acumulativos? Cuando Linus Torvalds creó su kernel lo hizo empezando un nuevo proyecto. En ningún momento lo hizo como parte del proyecto GNU de Stallman. ¿Está mal? No lo se. Pero estaba y está en todo su derecho de escoger el nombre que le sea de agrado. De hecho, sabemos bien que el nombre no fue elegido por él. La licencia GNU GPL hasta donde se, en ningún momento prohíbe crear un proyecto derivado con otro nombre. De hecho hay casos en el mundo del software que lo ilustran perfectamente, los cuales citaré a continuación: ↩
What is CentOS Linux? ↩
La traducción y el texto entre paréntesis es mío. Does CentOS change the upstream Source RPMs? ↩
¿Qué es el software libre? - Proyecto GNU - Free Software Foundation ↩↩

Paz y Propósito

sebelk — Sun, 06 Jan 2019 22:54:23 GMT

En la materia de la Tierra había pensado Aulë, a quien Ilúvatar había concedido una capacidad y un conocimiento apenas menores que los de Melkor; aunque lo que deleita y enorgullece a Aulë es la tarea de hacer y las cosas hechas, y no la posesión ni su propia maestría; por tanto da y nos atesora, y está libre de cuidados, emprendiendo siempre nuevas tareas.

El Silmarillion, JRR Tolkien

En las organizaciones de todo tipo podemos encontrar al menos estos tres tipos de disfuncionalidades:

Autoestima deficiente

Si una persona no tiene una autoestima sana, buscará algunos de estos métodos para disfrazar o aliviar ese padecimiento:

Involucrarse en tareas que no coinciden con sus mejores habilidades
Buscar la propia valía a través de tareas que termina superando y agotando sus recursos
Desplazar a quienes se interpongan en su camino
Forzar acontecimientos
Decir lo que otros quieren, pero no formar y hablar con voz propia
Culpar a otros por fracasos propios
No reconocer el mérito por los logros propios
La ausencia de protagonismo
Insatisfacción
Bronca y en casos extremos, odio
Obsesión por las metas y poca satisfacción en el recorrido a la misma
Es muy común la búsqueda de poder "sobre" en lugar de poder "para".
Ver la vida como un juego de suma cero: "Para ganar, otro tiene que perder"

El mensaje del emisor se percibe distinto de acuerdo al receptor

Este es un fenómeno prácticamente universal, ya que todos tenemos tendencias y hábitos de comportamiento e historia personal única. Cada vez que comunicamos algo es interpretado por el otro de manera distinta al contenido e intención de mensaje original. Cuanta más diferencia halla en esa interpretación mayor es la probabilidad de conflicto.

Comunicación inoportuna

Si bien sería absurdo buscar un momento ideal o perfecto para comunicar algo, a veces un mensaje antes o después de algún momento puede también generar malentendidos, conflictos, retrasar o frustrar la resolución de un problema.

Podemos hablar horas, asistir a cursos y conferencias sobre Project Management, ITIL, metodologías ágiles, DevOps y muchos conceptos más, algunos más de moda que otros, pero si ignoramos estas disfuncionalidades solamente estaremos cambiando de problemas, no resolviéndolos.

Algunas propuestas para eliminar esas disfuncionalidades podrían ser:

Conocernos mejor
Hablar con nuestra propia voz
Desarrollar el sentido de la oportunidad
Entender que hay una vida más allá del "poder sobre". Que también existe el goce y el disfrute por aprender y por hacer
Entender que no somos omnipotentes, pero aun así somos protagonistas

En definitiva, que podamos hallar 'paz y propósito'. Que es en realidad algo bastante más concreto de lo que podríamos pensar.

Fib3rtel pone restricciones para bajar archivos grandes

sebelk — Sat, 02 Feb 2008 14:23:18 GMT

Quería bajar una imagen iso de DVD de Centos 5.1. Sin embargo, noté que la descarga terminaba bastante rápido. Algo extraño estaba pasando, teniendo en cuenta que se trata de un archivo de 4,1 G. Pensé que se trataba de un problema del mirror. Pero luego probando con otros mirrors, e inclusive probando con ISOs de DVD de otras distribuciones, advertí que el problema se repetía.

$ wget http://linux.cucea.udg.mx/espejo/Mandriva/2008.0/mandriva-linux-2008.0-free-dvd-i586.iso
–07:49:15–  http://linux.cucea.udg.mx/espejo/Mandriva/2008.0/mandriva-linux-2008.0-free-dvd-i586.iso=>`mandriva-linux-2008.0-free-dvd-i586.iso’
Resolving linux.cucea.udg.mx… 148.202.23.6
Connecting to linux.cucea.udg.mx|148.202.23.6|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 269,768,704 (257M) [application/octet-stream

En la lista de correo Centos-mirror, John Lauro me dio una sencilla pero ingeniosa idea: comprobar si el sistema de archivos que estaba utilizando tenía un límite para crear archivos grandes. La primera prueba se puede hacer así:

$ dd if=/dev/zero of=5GB-file bs=1M count=5000

Entonces, obtuve un archivo llamado 5GB-file de 4,9 GB, lo cual era un primer indicio de que el sistema de archivos no era el problema. Tengo un wireless router que se conecta a Internet, que sirve como intermediario para una PC y una notebook. Creí por un momento que el Linksys WRT54G era el problema. Pero no, ya que conectándo la PC directamente al cablemodem tenía el mismo problema. La sospecha entonces comenzaba a apuntar fuertemente en dirección a Fib3rtel.

Luego, hice la siguiente prueba sugerida por John, hacer una descarga de un archivo grande desde un servidor web local. Así que eso hice, inicié Apache (de la PC con Mandriva 2008), puse un archivo de 4,9 GB e intenté bajarlo desde la notebook (con Fedora 8). Este fue el resultado:

$ wget http://192.168.1.2//5GB-file
--19:35:19--  http://192.168.1.2//5GB-file=> `5GB-file'
Connecting to 192.168.1.2:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5,242,880,000 (4.9G) [text/plain]0% [] 2,078,996      1.10M/s

Este resultado, sumado a las pruebas con tcptraceroute (idea leída del blog de Javier Smaldone) entre información recolectada, dieron el veredicto: No sólo Fib3rtel interpone a sus clientes un proxy transparente, sino que además impone un límite al tamaño de los archivos que se descargan. La pregunta (ingenua) es ¿Por qué la empresa no lo dice?

En lugar de llamar a Fib3rtel, y estar lidiando con la gente apenas capacitada del soporte técnico (y esperar los típicos diálogos del tipo: “Haga doble clic en Mi PC” – “Eh… uso Linux” o “Desconecte y reconecte su modem”, o , etc) encontré una solución al problema: usar Tor + Privoxy, los cuales me permiten esquivar el proxy transparente de Fib3rtel.

Descarga limitada por el proxy transparente de Fib3rtel:

$ wget http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso
–13:25:01–
http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso => `CentOS-5.1-x86_64-bin-DVD.iso’
Resolving holmes.umflint.edu… 141.216.3.72
Connecting to holmes.umflint.edu|141.216.3.72|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 147,687,424 (141M) [application/octet-stream]

$ export http_proxy=127.0.0.1:8118

$ wget http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso

–13:25:19–

http://holmes.umflint.edu/centos/5.1/isos/x86_64/CentOS-5.1-x86_64-bin-DVD.iso=> `CentOS-5.1-x86_64-bin-DVD.iso.1′
Connecting to 127.0.0.1:8118… connected.
Proxy request sent, awaiting response… 200 OK
Length: 4,442,654,720 (4.1G) [application/octet-stream]

Hasta la próxima.