I used to say this as well but like.. industry has, for a long time now equated “durable” with “stored on disk”. Any DBA will assume that’s what it means, and use that fact when they work out the replication they need either in clustering or in raid.
If you’re building a data storage system and are using the term “durable” to mean “it’s in RAM on three virtual machines”, for example, I don’t think it’s unfair to say that you are lying to your customers, because you are intentionally misusing a well-established term.
I forget the product, but more than a decade ago I remember someone broke out their durability into a table with columns for all the settings their data store offered between “ram on one node” and “fsync confirmed on a quorum of nodes’ disks” and rows for example failure cases ranging from “unexpected reboot of one machine” to “catastrophic loss of quorum-1 machines”. Cells were data loss risks from “prevented” to “possible” to “likely”.
That was very helpful when choosing durability levels.
I don’t have any respect for the viewpoint that “durable” is equatable with “stored on disk”, and I don’t want to spend time accommodating that viewpoint. It is just an oversimplification in a very bad way.
AFRs and discussions about different failure scenarios are the bare minimum. The bare minimum for scenarios is disk loss, total machine loss, and data center loss. This is just my take on things. I don’t care if something is on disk or not. I do care what happens when a sector on disk goes bad, when a faulty power supply destroys all the disks in a machine, or when a data center floods.
That forces you to think about things like whether you want to turn on synchronous replication.
The point of “durable” implying stored to durable media is precisely that it allows the operator of the system to make that kind of calculation. They know the disks they picked and the replication chosen, and as long as the database calls fsync, their calculations will work.
My beef is with database systems that use the argument you made further up thread to skip fsync to juice their performance numbers. Data is not “durable” if turning off the machines storing it means it’s lost, that’s a category difference, not a pure probability difference as you are claiming.
It is of course totally fine to not store data to durable media and say the risk of devops doing a coordinated reboot is as low as the risk of raid disk data loss, but then don’t use the word “durable”.
If a company says “encrypted at rest” that is generally compliance-speak for “not encrypted, but the hard drive partition is encrypted”.
Various certifications require this, I guess because they were written before hyper scalers and the assumed attack vector was that someone would literally steal a hard drive.
A running machine is not “at rest”, just like you can read files on your encrypted Mac HDD, the running program has decrypted access to the hard drive.
"encrypted at rest" is great to guard against stolen laptops, or in the server room both against people breaking in and stealing servers (unlikely at the security level of most hyperscalers, but possible) or more commonly broken HDDs being improperly disposed
How does that transalte to VMs? If "encryption at rest" is done at the guest level, instead of (or in addition to) host, that would be pretty close to minimal "encrypted except when it use" time and protect against virtual equivalents of pulling a hard drive out of a data center.
I feel like I’ve seen elsewhere that the argument there is that you often must have this optimisation working in algos that rely on it or you will get stack overflows. Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.
> Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.
Having a way to guarantee TCO/TCE is essential for some cases, yes. GP's question, though, was why a keyword specifically and not a hypothetical attribute that effectively does the same thing.
A keyword seems nicer to me. I think the only reason to use attributes is to avoid the work of adding actual new syntax, but seeing as they've already done that...
Respectfully, 30kWh is not much in this context. In 10 years every modern 2-car home will have 200kWh on the driveway just from the EVs; add a 100kWh whole home battery at a price point close to a 10kWh battery today and the calculus changes in most of the world.
The cost of materials going into modern batteries easily leaves room for another 10x reduction in price, IMO where this all is heading is obvious. Zero marginal cost will win every day of the week.
FWIW we run our cabin on 15kWh battery today year around, though we do run a small wood stove to supplant the heat pump on cold winter days.
40 kWH of storage and 9 kW of solar panels is all I need personally to live a 1st world lifestyle in the bay area mostly off-grid except for water and internet.
PNW is fraught, amazing during the Summer, but underpowered in Winter. The best solution is overprovisioning panels by a factor of 4 or so if the room is available. Did a place up there and it's hugely overproductive half the year, and just under break even in the dead of Winter.
From the Bay area or so and down across the country is ideal for solar, passing through a lot of red states that ought to know better. Fun fact though: Texas has the most windmills of any state by a huge margin.
I bet you didn't even see the tragic farce when writing your solution. Land development requiring ”2-car homes" is the driver of the problem! An apartment only has to heat one or two walls facing the outside instead of 4. That's 50-75% right off the top of your energy usage, with the mean closer to 75%.
There's nothing farcical about wanting one's own space where there's space to have one's own space. I'm grateful to no longer be sharing walls with a domestic abuse couple on one side and a midnight banshee on the other wall when she got busy. Energy is cheap, people are exhausting.
And that gets into another coordination problem we're unable to solve. It's a solved problem to build apartments where you can't hear your neighbors, but the builders don't have incentive to spend the money upfront to do so and we add regulations to make it more expensive for them to do so. So people go on thinking "apartments suck" and not the correct "we shouldn't let people build apartments which suck".
Also, living in SFH isn't avoiding all problems. I'd rather live in a properly-built apartment than my old house when my neighbor left her dogs outside to bark for the entire work day, every single day, and all the city would do is fine her a hundred bucks every few months. (or if you want to say "rural", that's 1 a small fraction of the population and 2 I like hospitals).
And the usual engineer mindset to consider the options to be 1 or 0, no?
I just live far enough from the center of it all that I have a vacant quarter acre and thicker windows that happened when the last owner's mistakes caught up with me the current owner. For medical, I have UCSF, and for major medical, I have medical tourism, something I fully endorse from experience. And yes, not everyone can do that. And well, I can't touch my toes and they probably can. Life's funny that way.
No reason to be rude or hyperbolic - I agree with you that cars destroy communities and we should strive to reduce the need for cars and parking.
For solar powered homes specifically though, multi-story buildings are much harder to run solar powered from the simple ratios - even if you reduce energy use 75%, at 4 stories you are break-even in roof-ratio-to-energy-need. I’ve worked in this space a while, and it’s now pretty straight forward to run single-family homes 24/7/367 on solar in most of the world, but multi story buildings are much harder.
Utility solar is cheaper in studies that do not factor in the cost of distribution, but the picture is much less clear when total system cost is considered - not having to pay for expanded distribution grids or new interconnects is a major benefit of residential production.
As for the last part not being true, can you clarify? The majority of the earths population lives between the 20th and 40th latitude, the band around the earth approximately between Madrid and the Sahara desert. Sure you can’t run a poorly insulated home in northern Michigan on solar year around without considerable expense, but that’s nowhere near where the majority of humanity lives.
I misread you as saying all homes. You're right that anywhere that's sunny year round, a SFH can be self-sufficient for electricity with photovoltaic and batteries.
Fooled by Randomness talks a good bit about this, and argues it’s true - except you don’t know what to bet on. Hence the outlier successes will be from extreme risk takers, and for each such person there will be 1,000s of other gamblers that bet on the wrong thing.
Taleb does the math as well IIRC, assuming there are x hundred thousand extreme risk takers, and outlier “correct bets” are y% chance, then you will have a surprisingly high number of people with a long series of “correct” bets behind them looking like business geniuses, from pure chance & basic statistics.
This was really good, and second leaning on property testing. I’ve had really good outcomes from setting up Schemathesis and getting blanket coverage for stuff like “there should be no request you can generate as logged in user A that let’s you do things as or see things that belong to user B”, as well as “there should be no request you can find to any API endpoint that can trigger a 5xx response”
It is a shame reddit lets people hide their post and comment history now so there can be no identifying signals about astro-turfing or bots. I'm sure this is ostensibly about preventing harassment, and in actuality about disguising bot behavior driving engagement. Or maybe I'm just extra cynical this morning.
I am surprised by the number of comments that say the assembler is trivial - it is admittedly perhaps simpler than some other parts of the compiler chain, but it’s not trivial.
What you are doing is kinda serialising a self-referential graph structure of machine code entries that reference each others addresses, but you don’t know the addresses because the (x86) instructions are variable-length, so you can’t know them until you generate the machine code, chicken-and-egg problem.
Personally I find writing parsers much much simpler than writing assemblers.
assembler is far from trivial at least for x86 where there are many possible encodings for a given instruction. emitting the most optimal encoding that does the correct thing depends on surrounding context, and you'd have to do multiple passes over the input.
What is a single example where the optimal encoding depends on context? (I am assuming you're just doing an assembler where registers have already been chosen, vs. a compiler that can choose sse vs. scalar and do register allocation etc.)?
“mov rcx, 0”. At least one assembler (the Go assembler) would at one point blindly (and arguably, incorrectly) rewrite this to “xor rcx, rcx”, which is smaller but modifies flags, which “mov” does not. I believe Go fixed this later, possibly by looking at surrounding instructions to see if the flags were being used, for instance by an “adc” later, to know if the assembler needs to pick the larger “mov” encoding.
Whether that logic should belong in a compiler or an assembler is a separate issue, but it definitely was in the assembler there.
jumps is another one. jmp can have many encodings depending on where the target offset you're jumping to is. but often times, the offset is not yet known when you first encounter the jump insn and have to assemble it.
In practice, one of the difficulties in getting _clang_ to assemble the Linux kernel (as opposed to GNU `as` aka GAS), was having clang implement support for "fragments" in more places.
There were a few cases IIRC around usage of the `.` operator which means something to the effect of "the current point in the program." It can be used in complex expressions, and sometimes resolving those requires multiple passes. So supporting GAS compatible syntax in more than just the basic cases forces the architecture of your assembler to be multi-pass.
You also need to choose optimal instruction encoding, and you need to understand how relocs work - which things can you resolve now vs which require you to encode info for the linker to fill in once the program is launched, etc etc.
Not sure why I'm on this little micro-rant about this; I'm sure Claude could write a workable assembler. I'm more like.. I've written one assembler and many, many parsers, and the parsers where way simpler, yet this thread is littered with people that seem to think assemblers are just lookup tables from ascii to machine code with a loop slapped on top of them.
I don’t understand this summary - isn’t this a summary of the authors recitation of Masleys position? It’s missing the part that actually matters, the authors position and how it differs from Masley?
If you’re building a data storage system and are using the term “durable” to mean “it’s in RAM on three virtual machines”, for example, I don’t think it’s unfair to say that you are lying to your customers, because you are intentionally misusing a well-established term.