The OP is about packaging issues with userspace utilities due to version pinning in Rust. It's an issue with Rust in general. Kent is not obligated to lock dependencies in any particular fashion. He could loosen the dependencies, but there is no obligation, and Debian has no obligation to package it.
This is different from the thread you linked in which the bcachefs kernel code and the submission process is discussed, and on which there was a thread here as well in the last days. But your criticism, as valid as it is, only applies there, not in a thread about tooling packaging issue.
Maybe not, but doesn't really answer my question what this would be used for.
I'm not hating, just interested; my last knowledge was that if you wanted to play Direct3D 12 games, you'd need the proton fork. But I don't know many other things Direct3D is used for, so...
Don't know how much this would help you; I did this on NixOS, however the steps for creating the key pair and enrolling is the same on all distributions, while your UEFI steps can vary depending on the manufacturer.
Microsoft, by default, decides which code is safe to run, yes.
However, that's not the only way to use Secure Boot; I enroll my own certificates in addition to Microsoft's, allowing code that I sign to be booted into. This requires some UEFI setup once.
For most machines, Secure Boot should never lock you out completely; you can always disable it, fix your boot chain and reenable.
I think it's actually sensible technology, but as every security feature, it usually comes at the cost of some convenience.
By how the protocol is structured, it's impossible for the address a downloader sees to know what the packet they forward actually contains, so they're just taking the role of an ISP. Also, they don't know the original source IP.
If not only Musk but also the banks are stuck in this problem, it's their own fault and incovenience. Not sure why you ignored his completely verbose explanation of how this problem is only Musk's (and maybe the banks he made the deal with).
That's the thing, the banks fear it will be their problem. They don't care about Tesla as a third party, but themselves.
I'd love Musk to get fucked by this whole ordeal. This was rather about if the creditors allow it or of they're afraid of the fallout.
And you're right, it won't be all instantly sold, but it is a large amount of shares and I'd think it would have a negative impact on share price.
and implying this is in anyway similar to the financial crisis is absurd clickbait.
I think it's similar in the fact that banks once again gave credit where the securities are massively overvalued; and I'm not sure there are enough investors around to pay that much money for shares. What are bag holders gonna do when the price goes down because a lot of shares are selling?
Anyhow, this assumes a sane market, which hasn't been the case for Tesla for 5 years.
You don't really understand the point I think, whether it's correct or not I don't know. His theoretical wealth is derived from the price of the last share sold. He probably can't just sell ($13bn/current share price) shares and get $13bn out of that, there aren't enough buy orders at that price, and you risk a panic sell by other holders. These other holders possible also include the banks were talking about, or at least related businesses and their clients.
Long story short, if banks had him liquidate shares worth $13bn, his net worth would fall (not the banks direct problem, bit probably wouldn't make future client acquisition easier); but it might be that they lose more money indirectly. All this calculation with a stock's market cap is a bit like a house of cards; it's really high, but don't shake it too much. At least that's an issue with overvalued stocks; sound businesses where the stock price reflects the company's actual value, maybe even pays dividend, don't have that problem.
The OP is about packaging issues with userspace utilities due to version pinning in Rust. It's an issue with Rust in general. Kent is not obligated to lock dependencies in any particular fashion. He could loosen the dependencies, but there is no obligation, and Debian has no obligation to package it.
This is different from the thread you linked in which the bcachefs kernel code and the submission process is discussed, and on which there was a thread here as well in the last days. But your criticism, as valid as it is, only applies there, not in a thread about tooling packaging issue.