By Bitcoin Revista - Hace 3 meses - Tiempo de lectura: 5 minutos
¡No rompas el espacio de usuario!
“Mauro, ¡CALLA LA MIERDA! Es un error, está en el núcleo. ¿Cuánto tiempo llevas siendo mantenedor? ¿Y *todavía* no has aprendido la primera regla del mantenimiento del kernel? Si un cambio provoca que los programas del usuario se rompan, es un error en el kernel. Nunca NUNCA culpamos a los programas de usuario. ¿Qué tan difícil puede ser entender esto? -Linus Torvalds
No rompas el espacio de usuario. Ésta es la regla de oro de Linus Torvald para el desarrollo del kernel de Linux. Para aquellos de ustedes que leen esto y no están familiarizados con la naturaleza de Linux o los sistemas operativos en general, el núcleo es el corazón y el alma de un sistema operativo. El kernel es lo que realmente administra el hardware, moviendo bits entre el almacenamiento y la RAM, entre la RAM y la CPU a medida que se calculan las cosas, y todos los pequeños dispositivos y piezas de la computadora real que deben controlarse a nivel de hardware.
Cada aplicación o programa escrito para un sistema operativo tiene que interactuar con el kernel. Cuando descargas Photoshop o Telegram, todo lo que hace el programa se reduce esencialmente a llamar al kernel. "Hola kernel, toma lo que acabo de escribir, procésalo y envíalo a través de una conexión de red al servidor". "Hola kernel, toma el cambio de color que hice en este tono, sácalo de la RAM y envíalo a la CPU para modificarlo, luego vuelve a colocarlo en la RAM".
When the kernel is changed, in a somewhat similar fashion to Bitcoin, the chief goal of developers is to ensure that existing applications that assume a specific way to interact with the kernel do not break because of a change to the kernel. Sounds very familiar to Bitcoin and the necessity to maintain backwards compatibility for network consensus upgrades doesn’t it?
"En serio. ¿Qué tan difícil es entender esta regla? En particular, no rompemos el espacio del usuario con TOTAL CRAP. Estoy enojado porque todo tu correo electrónico estaba terriblemente mal y el parche que rompió las cosas era obviamente una mierda. Todo el parche es una mierda increíblemente rota. Agrega un código de error loco (ENOENT), y luego, como es tan loco, agrega algunos lugares para solucionarlo ("ret == -ENOENT ? -EINVAL : ret").
El hecho de que luego intentes poner *excusas* para romper el espacio del usuario y culpar a algún programa externo que *solía* funcionar, es simplemente vergonzoso. No es así como trabajamos. Arregle su maldita "herramienta de cumplimiento", porque obviamente está rota. Y arregle su enfoque de la programación del kernel”. -Linus Torvalds
Linux es uno de los proyectos de código abierto más importantes, si no el más importante, del mundo entero. Android se ejecuta en Linux, la mitad de la infraestructura backend (si no mucha más) se ejecuta en Linux. Sistemas integrados que controlan todo tipo de cosas computarizadas en el fondo de tu vida que ni siquiera considerarías ejecutar en Linux. El mundo literalmente funciona con Linux. Puede que no se haya apoderado del escritorio como muchos usuarios autistas de Linux querían que sucediera, pero silenciosamente se comió casi todo lo demás en segundo plano sin que nadie se diera cuenta.
All of these applications and programs people use in the course of their daily lives depend on the assumption that Linux kernel developers will not break backwards compatibility in new versions of the kernel to allow their applications to continue functioning. Otherwise, anything running applications must continue using older versions of the kernel or take on the burden of altering their applications to interact with a breaking change in the kernel.
Bitcoin’s most likely path to success is a very similar road, simply becoming a platform that financial applications and tools are built on top of in such a way that most people using them won’t even realize or consider that “Bitcoin ate the world.” In a similar vein to Linux, that golden rule of “Don’t break userspace” applies tenfold. The problem is the nature of Bitcoin as a distributed consensus system, rather than a single local kernel running on one person’s machine, wildly changes what “breaking userspace” means.
It’s not just developers that can break userspace, users themselves can break userspace. The entire last year of Ordinals, Inscriptions, and BRC-20 tokens should definitively demonstrate that. This offers a very serious quandary when looking at the mantra of “Don’t break userspace” from the point of view of developers. As much as many Bitcoiners in this space do not like Ordinals, and are upset that their own use cases are being disrupted by the network traffic Ordinals users are creating, ambos grupos son usuarios.
So how do developers confront this problem? One group of users is breaking userspace for another group of users. To enact a change that prevents the use of Ordinals or Inscriptions explicitly violates the mandates of don’t break userspace. I’m sure people want to say “Taproot broke userspace!” in response to this dilemma, but it did not. Taproot activation, and the allowance for witness data to be as large as the entire blocksize, did not break any pre-existing applications or uses built on top of Bitcoin. All it did was open the door for new applications and use cases.
Entonces, ¿qué hacemos aquí? Intentar filtrar, o romper con un cambio de consenso, las personas que crean Inscripciones o intercambian Ordinales es violar fundamentalmente la máxima de "no romper el espacio de usuario". No hacer nada permite que una clase de usuarios rompa el espacio de usuario de otra clase de usuarios. Fundamentalmente no hay solución a este problema excepto violar la regla de oro, o implementar una funcionalidad que permita a la clase de usuarios cuyo espacio de usuario ahora está roto adaptarse a las nuevas realidades de la red y mantener una versión viable de sus aplicaciones y uso. casos.
Not breaking the userspace of Bitcoin is of critical importance for its continued success and functionality, but it is not as simple as “don’t change anything.” Dynamic changes in user behavior, that require no change to the actual protocol itself, can have the same effect at the end of the day as a breaking change to the protocol. Are developers supposed to pick and choose which applications’ userspace is broken to maintain that of another application? I would say no, and go further to say that anyone advocating for such behavior from developers is demanding them to act irresponsibly and in a way that harms users of the system. So what is the answer here?
There is no answer except to push forward and continue adding improvements to the protocol that allow applications being broken by the behavior of certain users to function in the presence of emergent changes in users’ behavior. Otherwise, you are asking developers to throw out the golden rule and effectively play kingmakers in regards to what use cases are viable to build on top of Bitcoin.
Si seguimos ese camino, ¿qué estamos haciendo realmente aquí? No puedo decirles qué estamos haciendo en ese momento, pero sí puedo decirles que ya no se trata de construir un sistema distribuido y neutral.
Fuente original: Bitcoin Revista