[ad_1]
“Mauro, SHUT THE FUCK UP!” It's a bug, ok – in the kernel. How long have you been a maintainer? And you haven't learned the first rule of kernel maintenance *yet*? If a change causes user programs to break, it is a bug in the kernel. We NEVER blame user programs. How difficult can this be to understand? » -Linus Torvalds
Don't break userspace. This is Linus Torvald's golden rule for Linux kernel development. For those of you reading this who are unfamiliar with the nature of Linux or operating systems in general, the kernel is the heart and soul of an operating system. The kernel is what actually manages the hardware, moving bits between storage and RAM, between RAM and CPU as things are calculated, as well as all the little peripherals and elements of the actual computer which must be controlled at the hardware level.
Every application or program written for an operating system must interact with the kernel. When you download Photoshop or Telegram, basically all that program does is call the kernel. “Hey kernel, take what I just typed, process it, and send it over a network connection to the server.” “Hey core, take the color change I made to this pitch, take it out of RAM and send it to the CPU to change, then put it back into RAM.”
When the kernel is modified, in a manner somewhat similar to Bitcoin, the developers' primary goal is to ensure that existing applications that assume a specific way of interacting with the kernel are not broken due to a modification of the nucleus. This sounds very familiar to Bitcoin and the need to maintain backwards compatibility for consensus network upgrades, right?
“Seriously. How hard is this rule to understand? We're especially not breaking userspace with TOTAL CRAP. I'm angry, because your whole email was horribly wrong, and the patch that broke things was obviously crap. The whole patch is incredibly broken crap. It adds an insane error code (ENOENT), then because it's so insane it adds a few places to fix it (“ret == -ENOENT? -EINVAL: ret”).
The fact that you then try to find *excuses* to break userspace and blame an external program that *had* worked is just shameful. This is not how we work. Fix your damn “compliance tool” because it’s obviously broken. And fix your approach to kernel programming. -Linus Torvalds
Linux is one of the largest, if not the largest, open source projects in the world. Android runs Linux, half of the backend infrastructure (if not much more) runs Linux. Embedded systems controlling all sorts of computerized things in the background of your life that you wouldn't even consider running on Linux. The world literally runs on Linux. It may not have taken over the desktop like many autistic Linux users wanted to see, but it quietly ate up almost everything else in the background without anyone noticing.
All of these applications and programs that people use during their daily lives rely on the assumption that Linux kernel developers will not break backward compatibility in new versions of the kernel to allow their applications to continue working. Otherwise, all running applications must continue to use older versions of the kernel or take on the burden of modifying their applications to interact with a radical kernel change.
Bitcoin's most likely path to success is a very similar path, simply becoming a platform on which financial applications and tools are built in such a way that most people using them don't even realize or consider that “Bitcoin ate the world”. In the same vein as Linux, this golden rule of “Don't break user space” applies tenfold. The problem is that the nature of Bitcoin as a distributed consensus system, rather than a single local core running on a single person's machine, radically changes what “breaking user space” means.
It's not just developers who can break userspace, users themselves can break userspace. The entire last year of Ordinals, Registrations and BRC-20 tokens should definitively demonstrate this. This poses a very serious dilemma when considering the mantra “Don't break userland” from a developer perspective. Even though many Bitcoiners in this space dislike ordinals and are upset that their own use cases are disrupted by the network traffic that users of ordinals create, both groups are users.
So how do developers deal with this problem? A group of users breaks the user space of another group of users. Adopting a change that prevents the use of ordinals or inscriptions explicitly violates mandates not to break userspace. I'm sure people want to say “Taproot broke userspace!” » in response to this dilemma, but this is not the case. Enabling Taproot and allowing witness data to be as large as the total block size did not break any pre-existing applications or uses built on top of Bitcoin. This only opened the door to new applications and use cases.
So what are we doing here? To try to filter out, or break with consensual change, people who create inscriptions or exchange ordinals is to fundamentally violate the maxim of “don't break user space”. Doing nothing allows one user class to break the user space of another user class. There is basically no solution to this problem except violating the golden rule, or implementing a feature that allows the class of users whose userspace is currently broken to adapt to the new network realities and to maintain a viable version of their applications and their use. case.
Not breaking Bitcoin's userspace is critically important to its continued success and functionality, but it's not as simple as “don't change anything.” Dynamic changes in user behavior, which do not require any changes to the protocol itself, may ultimately have the same effect as a radical change to the protocol. Are developers supposed to choose which applications' user space is broken to keep that of another application? I would say no, and I would go further to say that anyone advocating such behavior from developers is asking 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 move forward and continue adding improvements to the protocol that allow applications broken by certain user behavior to work in the presence of emerging changes in user behavior. Otherwise, you're asking developers to abandon the golden rule and effectively play the role of kingmaker when it comes to what use cases can be built on Bitcoin.
If we go this route, what are we really doing here? I can't tell you what we're doing at this point, but I can tell you that it's no longer about building a distributed, neutral system.
[ad_2]
Source by [author_name]