Bienvenido(a) a Grupo Linuxero del Bajío martes, mayo 24 2022 @ 11:47 CEST

Artículos

Opinión sobre las criptomonedas

  • miércoles, abril 27 2022 @ 10:26 CEST
  • Autor:
  • Lecturas 56
Artículos Hace unas semanas mi papá me envió un correo diciendo:
> Acabo de ver en Netflix una película sobre las criptomonedas y el robo descarado 
> de 250 millones de dólares.
>
> Esto viene a colación, debido a una declaración de Ricardo Salinas Pliego en la 
> que declara que las criptomonedas son buenas y él hace su preferencia por el 
> BITCOIN y que las va a aceptar en sus negocios:
> 
> https://www.elfinanciero.com.mx/economia/2022/04/11/bitcoin-alternativa-a-dinero-tradicional/

Así que le envié mi opinión al respecto, que aquí extiendo:

TL;DR: Las criptomonedas, en su estado actual, son un "esquema Ponzi", una estafa piramidal.

Gente como Salinas Pliego dicen eso, precisamente, para cubrir su exposición en bitcoins y salir con un pellizco, chingándose a los pobres pendejos creyentes que llegan después buscando hacerse ricos, mágicamente, comprándole sus bitcoins.

Las criptomonedas fueron uno de los subproductos tecno-culturales tras la crisis del 2008. El dinero fiducitario perdió precisamente su cualidad: nuestra fe en su valor. Ya no se puede confíar en él. Con la crisis evidenció cómo los bancos crean pueden crear dinero de la nada, sólo a partir de deuda que tengan contratada, operación conocida como multiplicador monetario. Y si sueltan créditos hipotecarios sin control, crean dinero sin control, pero si crean demasiado, no hay problema: el Estado los salva, cubriendo sus pérdidas a cargo del erario.

Entonces apareció un texto en internet, firmado simplemente por un tal Satoshi Nakamoto, de quien no se sabe nada, tal vez nunca hubo alguien llamado así, describiendo los detalles técnicos de cómo se podría manejar dinero de manera distribuída y sin confianza entre los participantes del sistema. Este documento describe dos operaciones básicas: cómo crear dinero (proof-of-work) y cómo llevar un registro de los movimientos de dinero de manera "anónima" (blockchain).

A ver si puedo explicar estos conceptos de manera simple. El segundo (blockchain):

El dinero simplemente es una cantidad asignada a un identificador (un numerote) conocido como billetera. Una persona real puede tener acceso a una o más billeteras. Dentro del sistema no hay forma de saber qué billetera está vinculada a una persona física, y eso parece asombroso. Pero el teatro se cae cuando uno pide dinero y tiene que decir, públicamente, cuál es su billetera.

Entonces, una operación sería la transferencia de una suma de una billetera a otra. Eso se escribe, como siempre, en un libro mayor contable. En el caso de las criptomonedas al libro mayor se le llama "blockchain", simplemente para que suene mamador. Pero es un libro mayor con dos características: 1) sólo se pueden añadir transacciones, nunca borrar ni modificar; y 2) este libro lo puede copiar cualquiera en internet.

Ejemplo: alguien compra algo y paga con criptomoneda. Entonces esta operación se escribe en dos blockchains: el de quien da el dinero y el de quien lo recibe. Estas personas están vinculadas con otros blockchains en internet que copian esta misma transacción validando que la misma operación exista en los dos blockchains afectados.

Supongamos que a mi blockchain le dice otro:

- Oye guey, mira, que me mandaron 500 criptomonedas de tal billetera.
- ¿En serio? a ver, no mames.

Mi blockchain entonces le pregunta al blockchain de la billetera que supuestamente le dio esa lana o uno cercano, y le contesta;

- Simón. Mira, todo coincide

Mi blockchain le dice entonces al primero:

- A toda madre, güey, ya te lo apunto yo aquí.

Pero, si llega un blockchain con una operación que no está replicada en otros blockchains, entonces se avisa a todos que ese es un blockchain inválido y ya nadie le creerá nada.

Hasta aquí todo maravilloso, tienes un sistema de transferencia de dinero descentralizado (no requieres de bancos, ni de switf, ni de visa). ¿A quién le puedes reclamar si te chingan la cartera? A absolutamente a nadie. ¿Qué pasa si se cae la red por mucho tiempo? ¿Qué pasa si se te borra el disco duro con tu blockchain y tu billetera? ¿Qué pasa si olvidas la contraseña de tu billetera? ¿Qué pasa si te invalidan tu blockchain sin mala intención de tu parte? Simplemente te chingas.

La otra operación es cómo crear dinero. Esta es la más compleja y problemática.

La creación de dinero, en un sistema distribuido y sin confianza, es a travésde un algoritmo critpográfico que usa métodos aleatorios y se le llama minería (porque también suena mamador).

La minería consiste en dejar que tu computadora genere números aleatorios grandotototes a lo pendejo. Si el número generado tiene un patrón específico, suena la sirena y aparecen criptomonedas en tu billetera. Es como ganar la lotería. Todos los blockchains saben que "tal billetera generó tal número aleatorio que le produjo tanta lana" porque tu computadora gastó un chingo de tiempo de procesamiento a lo pendejo (y de energía eléctrica) para producir una cantidad de criptomonedas.

El algoritmo está diseñado para generar cantidades de dinero variable en el tiempo: al principio se produce poca criptomoneda porque hay pocos mineros, pero el patrón ganador es fácil de obtener (por ejemplo, con que tenga un cero al final, o sea cada diez números producidos ganabas criptomonedas); con respecto pasa el tiempo hay más participantes en el sistema, y entre más dinero se haya generado, más difícil es obtener un número, ya que el patrón es cada vez más difícil de sacar (por ejemplo, seis ceros al final, o sea de cada millón de números generados, uno genera criptomonedas). El sistema va cambiando el patrón con respecto a la cantidad total de criptomonedas hay en el sistema, para evitar el problema del multiplicador monetario.

De entrada aquí ya se ve quién ya ganó: los cabrones que minaron primero. O sea, el requisito primordial de una estafa piramidal está servido.

Pero ahora viene lo más ojete de todo: la generación de números aleatorios es una operación computacional costosa, el CPU hace cálculos con números enormes y eso implica mayor consumo eléctrico y mayor generación de calor por el hardware. En este momento, el patrón para números aleatorios ganadores es de billones (en es español, millón de millones). Entonces, si uno se quiere dedicar a minar de manera que convenga, de poner enormes granjas de computadoras súper-potentes para simplemente generar números aleatorios a lo pendejo, gastando electricidad y generando calor como si no hubiera cambio climático. Hoy en día, estas granjas de minería en el mundo consumen más electricidad que países europeos enteros. Claro, se van a países donde la electricidad es barata para que les salga a cuentas. Pero, básicamente, estamos quemando bosques, gas, petróleo, destruyendo el planeta, para que un puñado de imbéciles tengan un numerito en la nube.

El dinero es un símbolo del valor. El valor es el trabajo humano dirigido a producir mercancías útiles para la sociedad. El símbolo dinerario está respaldado, inicialmente por una mercancía común, oro o plata, y luego por los impuestos recabados por los Estados (aunque ya nadie les cree ahora). Sin embargo, el dinero sigue representando el valor de la mercancía, el trabajo humano dedicado a ella. ¡Acá no! No hay trabajo humano ninguno! no hay producción de mercancías ninguna! No hay valor por donde se le busque.

Y claro, tenemos a un montón de pobres diablos, metiendo sus ahorros, dinero con el valor de su trabajo real, para especular en criptomonedas, sin entenderlas a cabalidad, y perdiéndolo todo. El ayudante del albañil que vino a hacer las reformas de la casa, un chaval de 20 años, con solo preparatoria, me contaba feliz que había ganado unos eurillos especulando en bitcoins y que se iba a forrar. Yo le decía que lo pensara mejor, pero hasta se ofendió. ¡Esas son las víctimas de hijos de la chingada como Ricardo Salinas Pliego!

Mi posición. El blockchain puede ser interesante para sustituir bancos y cosas como switf que son usados como armas por la OTAN para joder países como Cuba o Venezuela. Pero el resto es una estafa que participa de la destrucción ecológica del mundo.

Contra Chrome

  • martes, abril 19 2022 @ 09:03 CEST
  • Autor:
  • Lecturas 65
Artículos Salió un sitio web que emula los comis de Google para presentar sus producto, pero está vez para señalar los problemas que plantea el uso de Chrome.

https://contrachrome.com/

Para refleccionar qué herramientas usamos para navegar en Internet.

aplanando paquetes, o flatpakin'

  • domingo, febrero 13 2022 @ 04:06 CET
  • Autor:
  • Lecturas 90
Artículos El propósito de este texto es intentar explicar la tecnología flatpak [1].

Aquellos días donde cada distribución se enorgullecía de la cantidad de paquetes
que mantenía, de su maravilloso sistema de paquetería (deb, rpm, recetas de
compilación), se encuentran ya en su ocaso. No digo que desaparecerán, siguen
siendo necesarias, pero para un número menor de paquetes. Ya no buscaremos, en
la página de la distribución, si ya tienen empaquetada la última versión de la
aplicación que necesitamos.

Ahora, las aplicaciones se empaquetarán y distribuirán a través del sistema
flatpak.

Habrá a quienes no les interese esto y permanecerán fieles a su distribución o a
quemar ciclos de CPU y de vida para compilar todo. Pero para quienes la
computadora es una herramienta más, Flatpak es una respuesta a un reclamo común:
bajar, instalar, usar y actualizar la aplicación que usamos, sin necesidad de
saber, siquiera, qué distribución estamos usando. ¡Y lo mismo para los
desarrolladores! Ya no tienen que hacer, o pedir, recetas de empaquetado para
cada distribución que desean soportar.

Flatpak, entonces, es una tecnología muy cercana a la virtualización, entendida
como la capacidad de ejecutar una computadora virtual dentro de una computadora
real. Si han usado gnome-boxes [2] o qemu [3], tendrán más clara la idea.

Flatpak, exceptuando la arquitectura del CPU (amd64, arm, etc), virtualiza casi
todo, lo que permite controlar finamente los recursos que la aplicación
solicita. Piénsenlo como cuando se instala una aplicación en Android y les avisa
que necesita acceder a la red, a los contactos, a la cámara, etcétera. Pues
hagan de cuenta…

Por tanto, ejecutar o compilar una aplicación en Flatpak implica una
indirección: se le ordena a la computadora real que le ordene a la computadora
virtual ejecutar una acción, y está podrá, o no, ejecutarlo dependiendo del
entorno de ejecución, restringido, que tiene configurado.

Flatpak utiliza una tecnología llamada *OSTree* [4], que es una capa de
abstracción sobre el sistema de archivos del sistema operativo, con un espíritu
similar a *git*: transaccional, historial inmutable, con soporte de ramas
locales y repositorios remotos, etcétera. Para fines prácticos es un sistema de
archivos de sólo lectura, donde las modificaciones se hacen solamente bajo
ciertas condiciones.

El principio de las aplicaciones distribuidas por Flatpak es que son, en
principio, autocontenidas. Es decir, contienen dentro de ellas mismas todas las
dependencias requeridas. Sin embargo, esto es poco práctico para dependencias
comunes como las que provee Freedesktop, GNOME y KDE, así que se distribuyen las
llamadas *application platforms*, que básicamente son el conjunto de estas
dependencias, versionadas. También hay *runtimes*, que son librerías del sistema
como Mesa u otras implementaciones de OpenGL (por ejemplo las privativas de
NVIDIA). Por tanto, cuando se instala una aplicación en Flatpak, esta contiene
el manifiesto con la *application platform* y su versión que necesita.

Finalmente, hay repositorios de flatpak de donde uno puede instalar aplicaciones
listas para usar. El más importante y usado es flathub [5].

En conclusión, como usuario, simplemente disfruta de aplicaciones chidas
independientemente de tu distribución. Como desarrollador, pos hay que estudiar
un poco más para desarrollar para estos entornos (por la indirección a la que
obligan, hacen un poco más complejo el *debugging*).

1. https://flatpak.org/
2. https://help.gnome.org/users/gnome-boxes/stable/
3. https://www.qemu.org/
4. https://ostreedev.github.io/ostree/
5. https://flathub.org

La pesadilla de los punteros

  • martes, noviembre 16 2021 @ 11:18 CET
  • Autor:
  • Lecturas 409
Artículos Cuando uno aprende a programar en C y se adueña del uso de los punteros, uno generalmente se siente capaz de cualquier hazaña. Sin embargo, todo poder es ilusorio, porque esconde una poderosa debilidad. El concepto de puntero es intrínsecamente demasiado frágil. Tan así que es la fuente de muchos de los agujeros de seguridad, en especial el problema conocido como Use-after-Frees.

Supongamos que uno hace uso de un recurso, un objecto por ejemplo, y tiene una referencia a través de un puntero. Digamos

Object *p = get_object();

Pero en algún momento este objeto es liberado mientras retenemos el puntero p. Y entonces, si hacemos:

p->do_action();

Tenemos, en el mejor de los casos, una falla de segmento (segmentation fault). En el peor de los casos, el método es reemplazado, a través de un buffer overflow, por una función maliciosa.

El problema es generalizado y no es, de ninguna manera, excluviso de programadores novatos. Tanto es así que Google, en Chrome, que usa C++, esta proponiendo una clase llamada MagicPtr<T>, para manejar todos los punteros de los cuales la clase responsable no tiene control:

https://docs.google.com/document/d/1p...Nb_dbQ3ZBg

Contenedores

  • viernes, octubre 22 2021 @ 09:03 CEST
  • Autor:
  • Lecturas 232
Artículos Uno de los procesos más extendidos en TI es la instalacción de programas y servicios, llega a ser tedioso el tener que resolver todas las dependencias y compilar un programa para que funcione como es debido.

La gran diversidad de sistemas operativos y sus derivados trae alta complejidad para el desarrollador y por ende, casi nunca se soportan todos los posibles casos, más aún "la nube" trae la complejidad de trabajar o bien en un sistema recién horneado o limitado.

Por ello, se han implementado diversas soluciones (que no resuelven el problema al 100%), siendo una de ellas los llamados contenedores, liderado por Docker (https://www.docker.com/) y alternativas como Singularity (https://sylabs.io/singularity/).

Rust en el Kernel

  • martes, octubre 12 2021 @ 05:44 CEST
  • Autor:
  • Lecturas 306
Artículos Ojalá todos aquí sepamos que es Rust, y si no es así, nunca es tarde para saberlo.

Rust es un lenguaje de programación, patrocinado inicialmente por Mozilla, con el propósito de desarrollar su navegador web de siguiente generación, llamado Servo. No obstante, Mozilla ha sorteado vaivenes económicos y tuvo que cortar Servo. Sin embargo, el lenguaje de programación, que siempre conservó su independencia organizacional, sigue tan sano y vibrante como el primer día. Hoy por hoy, Google, Microsoft y muchas otras empresas potentes están utilizando el lenguaje para su consumo interno y en prototipos de futuros productos.

¿Por qué tanto éxito? Veamos sus características:

* Rust no necesita de un entorno de ejecución. Se compila y el binario opera directamente sobre el hardware y SO, tal como un programa escrito en C/C++. Su compilación tiene niveles de optimización elevados, además de generar binarios para varias plataformas, al utilizar LLVM (un framework para hacer compiladores, como clang).

* Rust no necesita de un recolector de basura. Sin embargo, garantiza seguridad de memoria, evitando desbordamientos de búfer (buffer overflow) o fugas de memoria (memory leaks). Esto lo logra a través de un sistema de posesión (ownership) de las variables (esto es lo más interesante y con más implicaciones a la hora de programar). No permite punteros nulos y favorece la asignación de memoria de la pila (stack) sobre la del heap.

* Rust tiene un modelo de programación orientado a la concurrencia, gracias a su tipado (tipos de datos), su sistema de posesión de variables, evitando las condiciones de carrera (race conditions) verificado en tiempo de compilación,

* Rust adopta características de varios modelos de programación: imperativa (como C/C++), funcional (como Lisp o Haskell), orientada a objetos (como Java).

* Rust se distribuye con una serie de utilerías que permiten desarrollar, perfilar y optimizar aplicaciones complejas con solo descargar su toolchain, facilitando la "productividad" del desarrollador.

* Rust tiene ya un enorme catálogo de librerías (llamadas crates) listas para descargar y utilizar: https://crates.io/

Tuve la oportunidad de colaborar en Servo en su momento, desarrollando el soporte para los tags <video> y <audio>, con los excelentes bindings de GStreamer para Rust.

En fin, hay más cosas que decir, pero harían este post más largo de lo que es.

El propósito del post es para comentar que la gente del kernel de Linux ha estado debatiendo los últimos años de usar Rust dentro del Kernel, sobre todo para desarrollar drivers, que suelen ser los que contienen el código más mediocre y menos revisado.

Miguel Ojeda ha sido el promotor de este adopción creando bindigs para las APIs internas del kernel y cuenta con el apoyo de varios mantenedores. Hasta al propio Linus Torvalds le parece prometedor.

Esta es una charla que dio en el pasado Linaro Connect:

https://www.youtube.com/watch?v=VlSkZYBeK8Q

automatizando el montado con autofs

  • sábado, septiembre 26 2015 @ 11:01 CEST
  • Autor:
  • Lecturas 1,713
Artículos

Durante los últimos días dentro del proyecto donde trabajo, nos dimos a la tarea de buscar una solución para poder otorgar a los usuarios sin privilegios a los servidores, una forma simple de acceder a puntos de montaje remotos y evitar la jerga de tener que hacerles el favor ocupar los privilegios de root en estatarea. Asi que nos estamos dando a la tarea implementar el servicio de autofs.

Linux Unified Key Setup

  • domingo, junio 07 2015 @ 12:48 CEST
  • Autor:
  • Lecturas 2,104
Artículos

Compré un SSD externo con interfaz USB3 como dispositivo de respaldo. En realidad ya no me cabían tantos "repositorios" en mi computadora y siempre es necesario tener espacio libre en disco para maniobrar.

No obstante, no quiero que la información que está allí almacenada pueda ser leída por cualquiera sin mi consentimiento. Son mis datos, y como la intimidad, éstos no se toman por asalto, sino por consenso. Es por ello que decidí enterarme en cómo usar el cifrado de discos duros.

Para cifrar discos duros se usa el comando cryptsetup, que es la interfaz de usuario para módulo del kernel dm-crypt, que a su vez usa la infraestructura del kernel llamada device-mapper, cuya función es mapear dispositivos físicos de bloques (discos) a un dispositivo virtual de bloques de alto nivel, donde podemos tener servicios como Linux volume manager, dm-cache, etc.. Distribuciones como Debian o Fedora instalan esta funcionalidad por defecto.

CyanogenMod

  • miércoles, mayo 13 2015 @ 01:15 CEST
  • Autor:
  • Lecturas 2,603
Artículos

Hace unas semanas me convencí de cambiar de teléfono móvil. Después de poco más de tres años, decidí cambiar mi N9 por un OnePlus One.

Detesto cambiar de hardware, pero mi N9 ya sufría de varios achaques, producto del acelerado cambio tecnológico. Por ejemplo, su navegador Web ya no despliega correctamente muchos sitios, en especial Wikipedia, que me es indispensable. También su aplicación para Whatsapp (wazapp), a pesar de que admiro el esfuerzo de sus desarrolladores, nunca llegó a ser utilizable, ya que drena la batería.

¿Por qué elegí OnePlus One? Por pereza. Es decir, cuando tengo que comprar cacharros, le pregunto a gente que ha indagado a profundidad al elegir los suyos, escucho sus razones y no lo pienso mucho más. Soy afortunado de conocer personas que dedican tiempo a investigar y son generosos al compartir sus conclusiones.

La razón con más peso es que estos teléfonos llevan, pre-instalado, CyanogenMod.

Page navigation