11,905 karma · joined May 21, 2009
Ugh, no way. There's way more to three ball juggling than just Mills Mess (no apostrophe, his name was Steve Mills and it's not possessive but just a title).
Mills Mess is the start of learning that there's more to three ball juggling than just a couple of over the top throws, not the end of it.
Somewhere like Kansas, wind power and battery based storage may be more effective.
Here's a map of pumped storage hydro potential; note how dense the potential is throughout most of the Western US. https://maps.nrel.gov/psh
The basic point is that nuclear is just really, really expensive, and it has been getting more expensive over time, while solar and wind have been getting cheaper.
Nuclear will continue to be viable in denser areas, with lower solar resources, and when you want to get a lot of production closer to large population.
There's a reason there are so many nuclear plants in the Northeast Corridor (Boston to Washington area), and so many fewer in the southwest, and I imagine that this trend will continue.
So even if you discount the capacity by a 25% capacity factor, and use the lower cost per reactor that I originally quoted, this is still cheaper than nuclear. And that's just the up-front investment. Operating costs are much cheaper for solar as well, the majority of the cost is in the initial build.
Given that transmission isn't free, there are areas of the country where solar has a lower capacity factor than this, and solar and wind take more land, there are still cases where nuclear may be a better investment. I'm just pointing out that there are plenty of simple, economic reasons why solar and wind are growing at a much faster rate than nuclear; it's cheaper overall, it requires less up-front capital, etc. Nuclear is likely to fill niches for a long time, but investment in nuclear is not going to be the major way to decarbonize.
And remember, nuclear generally needs some form of storage or supplementation with on-demand generation (generally via fossil fuels). Nuclear reactors are very slow to increase or decrease their output; they're best providing a constant base power output, but to account for periodic changes in demand across the day, you need either grid-scale storage or to supplement them with things like gas turbines that can quickly spin up and down. Many of our existing grid-scale energy storage systems are there to support nuclear. For example: https://www.wbur.org/news/2016/12/02/northfield-mountain-hyd...
But if you're already going to be building the grid-scale storage, supplying it with renewable energy can be a lot cheaper than supplying it with nuclear.
I'm not saying that nuclear will have no place in the energy grid as we decarbonize. But the economics are hard to justify as renewables and storage become cheaper.
A lot of the nuclear risk is already included in that cost; we have fairly robust nuclear regulation and safety engineering these days. I have pretty high confidence in the safety of modern nuclear reactors, because there has been the engineering needed to ensure it, and there's fairly strong regulatory oversight. Of course, that all gets factored into the price tag, which is part of why the price tag for nuclear is so high.
I'm just saying that I see a lot of discussion of more nuclear investment as the solution to decarbonization, but it's hard to make the economics work out; nuclear has gotten more expensive over time, while renewables have been dropping in price dramatically.
I'm sure there is some room for nuclear in the market, but it's hard to see it providing more than a fraction of what renewables do, just due to the massive cost difference.
edit: Oh, and that $6.8 billion looks optimistic. This project with two AP1000s looks like it costs $30 billion. https://www.ans.org/news/article-3949/vogtle-project-update-...
The NTSB is not quick to jump to conclusions; they are very thorough, and they collect and sort through a lot of evidence. It's not surprising that there's information out sooner that says more for such a high profile incident; but once the NTSB final report comes out, it will be quite detailed and thorough, and cover all of this and more.
So this all just serves to confirm that report, and what people suspected for a while; the bolts were just missing, removed for removing the door plug for the rivet rework and never reinstalled.
I routinely open a file in my editor, hit "Ctrl-c v B" for Git Blame mode, go to the line I'm interested in, and hit "Enter". Bam, there's the full commit message. From there I can can continue to trace backwards, blaming lines and reading full commit messages.
But, you know, not everyone uses Emacs and Magit, fair. How about just using "git gui blame file"? Click on a blame line, see the full commit message. This is a tool included with Git (available in a separate package in some installations).
OK, rather use an IDE? Install GitLens in VSCode. Easily accessible blame in your editor, where you can hover or click in various places to see full commit messages.
I mean, I agree in part; there are some tools which make good commit messages hard to write or find. The tiny little commit message edit box in VScode is not ideal. Lots of people use a workflow of "commit lots of crappy commits with one liner commit messages, let GitHub/GitLab squash them on merge."
But as an expert Git user who has managed to convince some teams to have a good commit message culture, if you do get people used to writing good commit messages, they can be very easy to find and read later on, there are tons of tools that make them easy to browse.
Obviously people want correctness; they would like their databases to not randomly lose data. Hence the fact that it's a highly advertised feature.
But when it actually comes down to selecting a database, convenience and performance seem to be what people actually compare on, there are very few places that actually hire someone like Kyle to dig in and verify the the consistency claims about a database.
Yes, there are misses, but they have been happening increasingly less frequently over time.
https://en.wikipedia.org/wiki/Aviation_safety#/media/File:Fa...
Aviation isn't perfect; nothing implemented by large groups of fallible humans with budget constraints will be. But it has one of the best safety track records of any industry.
Now, why won't aviation style engineering be applied in other fields, like databases? Well, because no one really cares enough. No one dies if some random database used by some ad platform loses the occasional transaction. Yeah, it's frustrating to engineers who are trying to build reliable systems, but in the grand scheme of things losing a few percent of transactions isn't the end of the world for most businesses.
You get safety cultures like that in aviation because there are real, substantial risks, so you need to have thorough engineering discipline, properly designed redundancy, etc.
For databases that are used for the majority of the business world, efficiency is generally a bigger concern than correctness; they'd rather have cheap and fast databases that lose a few transactions occasionally than something that actually provides consistency. But of course everyone thinks they need consistency, so it's advertised as a selling point while not actually being provided in practice.
The big difference is in how severe the difference between claims and reality are, and how the maintainers or vendors react to such bug reports.
In some cases, the maintainers or vendors will fix bugs, or update docs to be more clear. The different transaction isolated levels are complicated and nuanced, and there are standards which disagree with the general consensus in the literature, so there can easily be ambiguities that need to be cleared up or bugs that need to be fixed.
But then there are things like RavenDB; where they make clearly impossible claims like "ACID across multiple documents and multiple cluster nodes in an AP database." There is simply no way to achieve this.
And then there's how they respond to his findings. He filed bugs and had had responses a month ago, about things like "this thing that is documented to have transactional semantics does not have transactional semantics", and their response was just to say "oh, yeah, that's expected", and not fix anything or update any of their documentation to reflect that.
So, there's a big gulf between "this is a complex topic, and even some of the best systems have some issues if you test it thoroughly enough", and "the documentation is blatantly lying about transactions and consistency, and the CEO of the company doesn't think it's a problem."
The docs for RavenDB explicitly state https://ravendb.net/docs/article-page/6.0/csharp/client-api/...
The batched operations that are sent in the SaveChanges()
will complete transactionally. In other words, either all
changes are saved as a Single Atomic Transaction or none
of them are. So once SaveChanges returns successfully, it
is guaranteed that all changes are persisted to the database.
I dunno. If I paid for an ACID database, I'd expect, well, some ACID features, like the ability to run two transactions concurrently and have them be isolated. It looks like RavenDB is fundamentally not implementing even the most basic of its claims. This isn't some "oh, yeah, this is a complex problem, and there are a few bugs lurking in obscure corner cases", this is "it fundamentally doesn't support what they claim to support as the major front-page selling point."
Their front page selling point is "Fully transactional NoSQL database" which links to a page that says "A database without transactions is… well, not much of a database, and as far as transactions are concerned – ACID is the gold standard."
But then in response to these findings, they say that the thing that is documented to have transactional semantics doesn't actually have transactional semantics.
And I pay more for this, just in terms of my monthly premiums, not to mention all of the out of pocket and deductible costs, than I would in taxes for healthcare in just about any other developed country.
I don't know what metric people are using when saying that they are "happy" with their health insurance, other than comparing it to being uninsured in this country, in which case, sure, it beats that.
There are open source tools based on reverse engineering the bitstream for some smaller FPGAs like the Lattice family, some preliminary work on Xilinx, and one vendor actually supporting the open source toolchain (QuickLogic), but for anything serious on the major FPGA platforms, you still need to use the vendor toolchain.
But at least for the components we're developing, we have basically standardized on ARM, the TMS570 specifically since it offers a number of features for safety critical systems, and simplifies our tooling and safety analysis to use the same processor everywhere.
Z80 is pretty retro, and while I'm sure there may be some vendors who still use it, it's got to be getting pretty rare for new designs, between all the PowerPC, Arm, and now RISC-V processors available that allow you to use modern toolchains and so on, I'd be surprised if many people were doing new designs with the Z80
And running into these kinds of questions, both in a single project that evolves over time (rustc) and a separate project, help to feed information back into what you need for a formal specification; which is something that is being planned out. Having a second implementation can help find these areas where you might need to be narrower or broader in your specification, in order to clarify enough for it to be implementable or broaden it enough to accommodate reasonable implementation differences.
They are not trying to diverge in language implementation, but there will always be simple compiler bugs, which may crop up in one implementation but not another. For instance, some LLVM optimization pass may miscompile some code; gccrs wouldn't necessarily be trying to recreate that exact bug. I think that "bugs, quirks, and all" really means that they aren't trying to fix major limitations of rustc, such as introducing a whole different borrow checker model which might allow some programs that current rustc does not. They're trying to fairly faithfully recreate the language that rustc implements, even if some aspects might be considered sub-optimal, but they aren't going to re-implement every ICE and miscompilation, those are places where there could be differences.
WASM is superior in pretty much all ways to NaCl other than being a bit more time to go through the whole specification and implementation process. NaCl was a great prototype, and WASM is a much more polished result because of it.
I don't know enough about the specifics of Romero to say which it is, possibly more than one, but it doesn't seem to be unique to him, I see this kind of pattern in pop culture all the time.
Just because you live in a miserable, car-bound, suburban hellscape doesn't mean that everyone else has to.
I didn't even drive until I was 27. I'm in my 40s now, and have friends my age who still don't drive.
While the car reigns supreme in most of the US, there are still parts where it's possible to get away without one.
That opening sentence may be a bit clumsy, but what it's trying to say is that the games don't run directly on hardware on any of these machines, but instead runs in an interpreter.
It's surprising that something as simple as reading a file is slower in the Rust standard library as the Python standard library. Even knowing that a Python standard library call like this is written in C, you'd still expect the Rust standard library call to be of a similar speed; so you'd expect either that you're using it wrong, or that the Rust standard library has some weird behavior.
In this case, it turns out that neither were the case; there's just a weird hardware performance cliff based on the exact alignment of an allocation on particular hardware.
So, yeah, I'd expect a filesystem read to be pretty well optimized in Python, but I'd expect the same in Rust, so it's surprising that the latter was so much slower, and especially surprising that it turned out to be hardware and allocator dependent.
Pretty standard fare for a vehicle controller.