North Korea is geopolitically useful as a buffer state between the United States' sphere of influence in South Korea, and China. China has defended it pretty determinedly, historically.
This article makes Odin sound extremely well-known. I've never heard of it before, and I feel like I keep up with programming topics pretty diligently. Admittedly I don't work at the systems programming layer, but I've definitely heard plenty about Rust and c++ topics.
Curious if others feel similarly, or maybe I just happened to miss it?
I read recently that corporate taxes used to be a lot higher on large conglomerated companies, which used to deter monopolization somewhat. Under this automatic-stake idea, it'd be interesting if the government's stake in corporations increased as they got larger? Companies try to avoid this and so don't combine so much?
Of course once the government does have a large stake in the largest monopoly-like companies, it's immensely motivated to keep them large. Hmm. This idea isn't good.
If it is, would that bad? Seems like a person who might really have strong personal investment in the situation. Using the oil companies' profits to try to shrink them, seems good.
If it's actively building the next generation of itself, I'd say that counts. It's more like a parent raising their kid well than it is like a parent modifying their own mind, but the result is still that you have a better model in a year than you do now.
Does this strike anyone as bad api design to anyone else? I don't know what their definition of "much" is and it may not be the same as mine. behind the scenes they must have a real number like page_visits_in_last_30_days, which they're checking against a threshold value or "much". It'd be much more useful to just go ahead and return page_visits_in_last_30_days.
(to be fair, maybe the api does offer this too and it's just not the focus of the article)
It's hard to know who was right. All of these things can be true: it made it back ok; it had a high chance of making it back ok; it should've had a much higher chance of making it back ok. Most of the concerned people were stressing this last point, that it should've been safer than it was. They still thought it had a quite high chance of making it back ok. It took a lot of shuttle missions before Columbia failed.
A less cynical explanation: It's heavily trained to ask follow-up questions at the end of a response, to drive more conversation and more engagement. That's useful both for making sure you want to renew your subscription, and also probably for generating more training data for future models. That's sufficient explanation for the behavior we're seeing.
It's true that track maintenance is costly but it's mostly costly because there's a whole lot of track to maintain; many hundreds of miles of it, often in hard to reach areas. This looks like it'd be a few hundred meters at most, all parallel to each other in one place. So hopefully it's easy enough. The tower crane also requires maintenance.
The funding model where, if I understand correctly, the construction contractor gets paid less (maybe none?) up front but gets 0.75ca per passenger-kilometer traveled on the system, is cool and does seem like it'd help align incentives and keep costs down.
Some of the other advantages listed in this article were enormous free wins not easily replicated elsewhere though. Somebody else had already paid for the new bridge to be wider to have a transit reservation on it. The same is true for the mount royal tunnel, which was conveniently and cleverly reused for sure, but which cost a staggering amount to construct when new.
This article calls standardization a key, but this system is entirely separate from Montreal's existing subway, and therefore doesn't match any existing standard within the city. https://xkcd.com/927/
Many of the great features suggested here (platform screen doors, full automation) are only possible on a brand new system like this. Very few cities have enough leftover rights-of-way to piece together entire new networks like this for cheap, without enormous land takings or tunneling. If you do have space for a new network, then inventing a new standard and using it makes sense; but if you don't, the best you can do is incremental evolution of the one you have.
When you're new it can be hard to tell what to ignore; it makes it tempting to pick a simpler framework that you can entirely grasp. Also any published examples, chatgpt etc won't be aware of the subset you've chosen to use when they're providing examples; they're gonna draw from the full set.
Ideally: there's a train close enough to walk, or a bus or tram that's nearby that runs frequently, is clean, and doesn't get stuck in traffic because there's not much car traffic.
Slightly more realistic: enough people can and do cycle or walk to the train that pressure is relieved on the roads for those who cannot cycle or walk.
Scott Alexander has issued many studies in his time and is surely aware of this phenomenon. He was very cautious even in this study to calibrate for this sort of noise; see the section about Michaels you know.
The airline websites that I've used are remarkably bad with their UI/UX. Far from any grandma being able to use it, definitely. I can rarely get through the process without some inexplicable error or missing field that I can't find or misbehaving custom date picker.
The loaded cars can go coast to coast, but trains are broken up and reorganized often in yards, especially in places like Chicago. this is efficient because two cars from LA headed to Toronto and NYC can travel together until Chicago and only then be split into two new trains. Even within a single railroad this is commonly done.
Thinking Machines was chosen over the Cray because they had more visual appeal. Sheryl Handler the CEO had (has) a real flair for and it showed; they were neat looking machines