>From the beginning, I’ve believed the executive branch's real goal was to push down the yield on the 10-year Treasury
You're making it seem that there's a plan ... but what if this is just regular incompetence coupled with capricious behavior from a chaos agent?
I'm watching various officials give interviews and all of them are non-committal as it pertains to expectations. Why? Because none of them actually know!!! Trump has arbitrarily and capriciously changed "the plan" many times.
The political cohort behind the president is roughly in two halves. The first half are the original MAGA crowd (looking out for the working class, pro-liberty, anti-woke, etc.). The second half are the billionaire crowd.
The second group are active on pod casts, on Twitter/X, and are partly represented in government (directly or as advisors). An easy way to follow up on these people is to watch the All In Podcast or their related social media connections.
What these folks have said for a long time is that if USA stay on the same path, the USA goes broke after 10 years. So if you have long term investment in the USA, you lose your fortune in 10+ years.
This is the key motivation for their involvement in the current executive branch of government. This is why the DOGE program is so well supported by them.
If you lose the battle to reduce the 10-year Treasury yield, you lose the billionaires because they stand to make meaningful losses on a 10 year horizon.
I recognize the plight of the common citizen here; they are the plurality. But the big political levers come from these billionaires (absent a grass roots supported leader in the wings).
If the goal to drive the yield on T-notes down, then cut spending and raise taxes. Get the budget into something like balance and the Fed will cut rates, and borrowing costs will fall. You don't need some 3D chess with a manufactured financial crisis.
When your rational explanation involves people shooting themselves in the head to cure a headache, something's off. There's nothing to explain here besides a weak and incompetent leader with a deep need for attention, surrounded by lots of enablers.
I think only thing likely to make US go broke is Trump's actions.
DOGE doesn't save any money. Not only because it's created many legal messes that will take forever to work out in court but because most of those jobs are important and will eventually need to be replaced at great cost and with worse results. Also some of those jobs are for auditing inefficiency and prosecuting corruption resulting in more money spent. And on top of it all they'll be using these non existent savings to justify much larger tax cuts for the rich.
The reason it looks stupid is because it is. It's not that Trump is purely dumb he's just intellectually lazy and doesn't care about policy. He long ago decided he likes tarrifs on instinct so he put massive tarrifs despite the warnings that they would be disastrous
This belief seems to disregard the fact that the billionaire crowd hates markets being spooked far more than it cares about 10 year Treasury yields (which in any case went up precisely because markets were spooked; if you wanted to do something about reducing long term bond yields, committing to just about any other economic policy would be more credible). Even some of the most sycophantic billionaires were evidently furious about the tariff policy.
Also, Trump has been obsessed with the idea of tariffs since the 1980s.
My listening to such billionaires explains a different attitude.
Small investors, and medium investors hate market turbulence for sure.
But when you are a billionaire, you can easily profit from short term uncertainty. For example, Chamath recently disclosed a (potentially large) Credit Default Swap position (meaning he makes huge upside if USA debt position deteriorates). But he was the same person deeply concerned about USA long term debt. He is a well connected person to the executive branch.
The reason is that if you are a billionaire (tied to the USA financial system) then you can't escape the system when the entire system falls due to (God forbid) a collapse of the USA financial system in 10 years time. It is like they are the dinosaurs worried about a Meteor strike, but not worried about tigers and snakes (that can't hurt them).
If the billionaires were genuinely concerned about a complete collapse of the USA financial system in 10 years, they wouldn't have bet on a president with a track record of expanding debt to pump the stock market in the first place, and it would be hard to imagine anything less likely to stave off a crash than launching a trade war or threatening to annex your neighburs. Frankly the only only credible cause of the US economy completely collapsing within a decade is called Donald.
Getting a short term interest rate cut makes very little difference to the robustness of the US economy in a decade's time, and even if it did, there are many ways of getting a short term interest rate cut that don't involve massive economic disruption and permanently sabotaging US trading relationships (most obviously, the president nominates the chair of the Fed...). You could see what the likes of Ackman and Elon actually thought about the tariffs from them breaking ranks to moan about them.
The billionaires who backed Trump like standard right wing stuff like tax cuts, deregulation and/or racism, or figured he was going to win anyway so they might as well get credit for being seen as his ally. Some of them might actually be well informed enough to place shorts (and hey, the ones who own trading shops rather than manufacturing and services companies might be able to win more than they lose in equity value that way) but that's a completely separate issue from the idea that chaos now could have positive effects in a decade's time, which only one billionaire in the world is dumb enough to believe...
>How else should Ukraine pay for the military assistance it's receiving?... Sharing profits from your natural resources in exchange for military resources seems like a great deal to me.
Sorry, where did you get that this deal is for _FUTURE_ military resources??? Seriously - where did you hear that?
The only way the Trump administration characterized the mineral deal is as repayment for PAST military aid, even though it was perfectly understood that those were GRANTS (i.e. there were no terms attached to the military aid). The Trump administration also accused Ukraine of cheating/tricking the US/Biden administration to get this military aid ... and also of starting the war ... and also of being a dictatorship ... and also of being an obstacle to peace.
Trump administration also made it clear that the mineral deal is NOT a security guarantee, nor is the mineral deal payment for FUTURE military aid.
------------
It is a common pattern that whenever Trump says X, apologists, like you, come out of the woodwork and say something like "Well, what he really meant to say is Y".
Yes, it would be different if the mineral deal was payment for future military aid .. but it isn't - so why are you saying that?
Ooof. The core collections in Java are well understood to not be thread-safe by design, and this should have been noticed.
OP should go through the rest of the code and see if there are other places where collections are potentially operated by multiple threads.
>The easiest way to fix this was to wrap the TreeMap with Collections.synchronizedMap or switch to ConcurrentHashMap and sort on demand.
That will make the individual map operations thread-safe, but given that nobody thought of concurrency, are you sure series of operations are thread-safe? That is, are you sure the object that owns the tree-map is thread-safe. I wouldn't bet on it.
>Controversial Fix: Track visited nodes
Don't do that! The collection will still not be thread-safe and you'll just fail in some other more subtle way .. either now, or in the future (if/when the implementation changes in the next Java release).
>Sometimes, a detail oriented developer will notice the combination of threads and TreeMap, or even suggest to not use a TreeMap if ordered elements are not needed. Unfortunately, that didn’t happen in this case.
That's not a good take-away! OP, the problem is you violating the contract of the collection, which is clear that it isn't thread-safe. The problem ISN'T the side-effect of what happens when you violate the contract. If you change TreeMap to HashMap, it's still wrong (!!!), even though you may not get the side-effect of a high CPU utilization.
---------
When working with code that is operated on by multiple threads, the only surefire strategy I found was to to make every possible object immutable and limiting any object that could not be made immutable to small, self-contained and highly controlled sections. We rewrote one of the core modules following these principles, and it went from being a constant source of issues, to one of the most resilient sections of our codebase. Having these guidelines in place, also made code reviews much easier.
> That will make the individual map operations thread-safe, but given that nobody thought of concurrency, are you sure series of operations are thread-safe? That is, are you sure the object that owns the tree-map is thread-safe. I wouldn't bet on it.
This is a very important point! And, in my experience, a common mistake by programmers who aren't great at concurrency.
Lets say you have a concurrent dynamic array. The array class is designed to be thread-safe for the explicit purpose that you want to share it between threads. You want to access element 10, but you want to be sure that you're not out of bounds. So you do this:
if (array.size() > 10) {
array.element(10).doSomething();
}
It doesn't matter how thread-safe this array class is: these two operations combined are NOT thread-safe, because thread-safety of the class only means that `.size()` and `.element()` are on their own not going to cause any races. But it's entirely possible another thread removes elements in between you checking the size and accessing the element, at which point you'll (at best) get an out-of-bounds crash.
The way to fix it is to either use atomic methods on the class which does both (something like `.element_or_null()` or whatever), or to not bother with a concurrent dynamic array at all and instead just use regular one you guard with a mutex (so the mutex is held during both operations and whatever other operations other threads perform on the array).
A similar pattern (and overlooked very often) is with DB updates where you want to increment a number by 1, but split it into 2 roundtrips to the DB to get the existing value and set it to `value + 1`.
Concurrent transactions can screw it up, and you wouldn't notice until an escalation happens.
This kind of stuff is exactly why the original "thread-safe" collections in Java were deprecated in favor of the current one: locking on every operation means that a lot of trivial code "just works", but then things break without warning once you need consistency between consequent operations. And, at the same time, everybody is paying the locking penalty, even if they don't actually do concurrent access, or if they do their own locking.
Ironically, .NET repeated the same mistake with the same outcome - it's just less obvious because for .NET the switch from synchronized-by-default to unsync-by-default happened when generics were introduced, so type safety of the new collections was the part that devs generally paid the most attention to.
It’s absolutely a thread safety issue. It’s not a data race, but it’s a race condition and can very much cause unexpected behaviour e.g. out of bounds error even though on its face it has the correct preconditions.
Maybe I misunderstood. I took the first bullet to refer to wrapping operations in a lock and the second to refer to single writer multiple reader.
At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though.
Fixing it sucks because you usually have to go and add locking to your previously fast and efficient lock free setup.
> At least in the single writer scenario it all breaks down if a lock free reader requires multiple items that are related to one another. It's an easy oversight to make though.
This is true -- generally the solution to this is to ask for everything in a single message.
It can also break if the read implementation has mutable side effects, e.g. rebalancing. Java HashMap used to have this causing an infinite loop. I haven’t looked recently but my guess is it still does.
I mean, that's the "art of the deal". If you have a lock for all eternity, then you have a single owner, and are practically single-threaded.
The hard part is exactly all the combinations locks can be hold and given up, which will have a non-trivial number for more complex programs/data structures. That's where modeling software can help by iterating over all the possible cases.
This is basically what I thought: "Wait a second, is that data structure even thread-safe??" and then "Seems like you are just using the wrong data structure for your purpose.". Shoehorning with mutexes will usually lead to problems elsewhere and bottlenecks.
What you suggest to make objects immutable: Yes, and then one actually uses different data structures, which are made for being used as immutable data structures, making use of structural sharing, to avoid or limit an explosion in memory usage. So again its a case of "use the right data structures for the job". Using purely functional data structures makes one side of the problem simply disappear. The other side might not even come up in many cases: What if the threads depend on other versions of the data structure, which the other threads create? (need intermediate results of other threads). Then one has a real headache coming ones way, and probably needs again other data structures.
One additional idea I had, if one really wants to shoehorn it with the already used mutable data structure is, that one could write something that serializes the access attempts before they hit the data structure. That could also include grouping accesses into transactions and only running complete transactions. Then it makes me think whether it is close to implementing a database ...
So your solution to the the insanity that is the threading model was to reinvent the process model in it...
I don't intend to be mean, I just think the idea of independent execution in a shared memory environment is fundamentally flawed. And the effort in trying to get such follies working should have been put into better process models.
>So your solution to the the insanity that is the threading model was to reinvent the process model in it...
Where did you get that?
Immutability does not mean replicating the 'process model'. It means removing (limiting) an entire class of bugs from your multithreaded code. There will still be shared areas - and those should be controlled.
As a C maintainer, you should care how the other side of the interface is implemented even if you're not actively involved in writing that code. I don't think it is reasonable, for software quality reasons, to have a policy where a maintainer can simply pretend the other side doesn't exist.
That's up to the maintainer; if they don't have any knowledge of Rust, then it's better they don't get involved anyway. They're still responsible for designing the best C interface to their subsystem as possible, which is what most of the kernel will be interacting with. It puts the burden firmly on the shoulders of the Rust advocates; who believe the task is manageable.
As for your concern about code quality, it's the exact same situation that already exists today. The maintainer is responsible for his code, not for the code that calls it. And the Rust code, is just another user.
>They're still responsible for designing the best C interface to their subsystem as possible, which is what most of the kernel will be interacting with.
What if you're in a world where Rust code is either a significant or primary consumer of your interface ... surely as the API designer, you have to take some interest in how your API is consumed.
I'm not saying you become the owner of Rust bindings, or that you have to perform code-reviews, or that you have veto power over the module .. but you can't pretend Rust doesn't exist.
Giving good feedback about Rust<>C bindings requires knowing Rust well. It needs deep technical understanding of Rust's safety requirements, as well as a sense of Rust's idioms and design patterns.
C maintainers who don't care about Rust may have opinions about the Rust API, but that's not the same thing :)
There are definitely things that can be done in C to make Rust's side easier, and it'd be much easier to communicate if the C API maintainer knew Rust, but it's not necessary. Rust exists in a world of C APIs, none of which were designed for Rust.
The Rust folks can translate their requirements to C terms. The C API needs to have documented memory management and thread safety requirements, but that can be in any language.
That puts far too many chefs in the kitchen and worse(!) dilutes your time and understanding of the part of the code you know well. You need to trust your fellows in other areas of the code to make good decisions without you, and focus on what you know. Let other people do their own job without micromanaging them. Spend your time in your own lane.
Sometimes the other team proves incompetent and you are forced to do their job. However that is an unusual case. So trusting other teams to do their job well (which includes trying something you don't like) is a good rule.
The API is the contract boundary. As long as it is well documented and satisfies its postconditions, it can be implemented in anything. Computing thrives on layers of abstraction like this.
Sure, and that's ideal for the maintainers that are willing to do that (and there are several), but for the C devs that just don't care and can't be forced to care, this is a pragmatic compromise. Not everyone has to be involved on both sides.
Yes. This is exactly what it is. It is a "pragmatic compromise" to side-step major internal cultural and philosophical issues (not technical issues). You're basically telling a number of C maintainers that they can simply pretend Rust doesn't exist, even if it may be the case that Rust code is the primary consumer of that API. That's a workable solution, but it isn't an ideal solution - and that's a little sad.
You should care that it is usable, but how they use it should not concern you. If someone wants to use the usb driver to interface with a coin motor to build vibrating underwear, then that's none of your business. Your concern is if your driver works to spec and can be interfaced.
So if someone wants to write software in Rust that just uses the DMA driver, that should be fine. Linus is entirely in the right.
Yes. And that involves not completely ignoring an entire universe of consumers of your API, *as a general policy*. This is especially true with modules that may have Rust code as the primary consumer of the API.
I admit, I don't know what not ignoring Rust code by maintainer means in practice, and I agree it shouldn't mean that the C maintainer code-reviews the Rust bindings, or has veto power over the entire Rust module, or that the maintainer vets the architecture or design of the Rust module, or is on the Rust module mailing list. But it also shouldn't be that as a *general policy*, the C maintainer does not take any interest in how the API is consumed by Rust, and worse, pretends Rust doesn't exist.
>So if someone wants to write software in Rust that just uses the DMA driver, that should be fine.
I think there's a fundamental disconnect here and I'm not sure if I quite see it.
It seems to me as if you're speaking about a hypothetical scenario where Rust needs something from the interface that isn't required by other languages. And you can't articulate what that might be because you can't think of an example of what that would look like. And also, in this scenario, Rust is the primary user of this driver interface.
But if that's the case, it's getting really close to "if things were different, they'd be different". If that's not the case, then I don't understand your case.
There's nothing wrong with the interface. Rust can use it just fine. It doesn't do anything C code wouldn't. They're not even asking for anything from what I can see. The person who maintains the DMA driver doesn't want Rust _using_ his interface, he's rejecting PRs where Rust code is interfacing with his driver.
The closest analogy I can think of is he wrote a book, but he doesn't want left-handed people to read it.
The API maintainer should only be concerned how the API is consumed in only that it is consumable and doesn't cause unintended side effects. And neither of those should be impacted by the language used to consume the API.
Punch the hole though interface is a bad idea. And probably the worst one you can do. You 'should' just ignore the other side of the interface. And if that don't work. Fix the issue there (by yourself or find the code holder) instead of try to workaround from your end. Or if it always require change on both end, it's a hint that your interface isn't designed properly (thus always glue the the end together instead of separate it).
I hate it so much when people assume they are smart and workaround issue at other end of interface. It always end up that you need to understand both the workaround and original bug or you can't even read it.
I don't know ... I think it's 'properly rated'. The movie is deeply flawed but it has stayed in public consciousness and is (fondly) remembered. The first half is pretty good. The second half is a total mess and makes the entire plot, characterization and pacing unsalvageable. The visual art style is generally great, but there are some glaring misses.
>We are local min/max machines and need government to direct us to the global min/max but it doesn’t do that.
What is an example of that, because I governments do a reasonable of moving towards a global min/max. Where we haven't gone towards a global max/min is because it's actually hard. In many cases, the global min/max either isn't well defined, or if it is, you have to contend with existing infrastructure and huge costs to get there. For example, upgrading the electric grid to support massive amount of solar and wind power, is a multi-decade/multi-trillion dollar initiative (and this assumes solar and wind is even a 'global max/min' for carbon reduction .. and it isn't clear it is) ...
>Most things we designed are just so fucking inefficient and borderline insane,
Are they though? We're quite good (and dare I say it: 'efficient') at feeding, housing and transporting huge populations. Almost all the inefficiencies you mentioned are preference and/or comfort based. Society is not separated from laws of physics and economics. Everything is balanced against the cost of those services - when/if costs go up, you do tend to see corresponding change, typically in efficiency increase (e.g. smaller more efficient cars as gas prices go up).
>endless streams of 2000kg+ hunk of steel, plastic and glass, 95% of them transport about 80kg of human, 95% of the time they're just parked taking space for no reason.
That's true ... kind of ... there is a cost for car ownership and use that is different in different regions. If you're in New York, you're probably not driving to work.
The human part of car ownership is freedom. It's not ultra efficient to own a car, but there is something about it that is liberating for many people of all economic statuses. Most likely, in the future, car ownership will go away for the vast majority of people, and it will be sad when it does.
I'm sure the car marketing department agrees with you. Unfortunately, the reality for most people is not about freedom, it's about necessity. A car is simply the only way to get around; there are no other options. Freedom can't exist without choice. If you actually observe daily car users you'll find they are angry and frustrated. I find these daily frustrations occupy a vastly disproportionate space in their heads as well. How many times have you heard about the asshole on the road today? Or how bad the traffic was? These are signs that things aren't right, but people just can't see a way around it. If you realised something you were eating was unpleasant you'd just stop eating it, but people aren't able to stop driving.
You're clinging to the past where maybe the top 10% of society could own a car. Those people had freedom. Nowadays those people have private jets.
You're clinging to the past where maybe the top 10% of society could own a car.
You mean the early 20th century? In the mid-20th century far more than 10% of the population owned a car.
On the other hand you appear to have swallowed the WEF propaganda about increasing density to factory-farm levels and making the population truly own nothing, because then they'll be easier to observe and control. That's not freedom.
> I don't find the cons all that compelling to be honest
I found it reasonable.
The 5% improvement was balanced against the cons of increased cli complexity, lack of native JS zopfli implementation, and slower compression .. and 5% just wasn't worth it at the moment - and I agree.
>or at least I think they warrant further discussion
Yes, but there’s a difference between “this warrants further discussion” and “this warrants further discussion and I’m closing the RFC”. The latter all but guarantees that no further discussion will take place.
reply