kaliszad

Sure, ground source heat pumps instead of air source heat pumps. You pull the thermal energy from the ground or e.g. a lake. That has almost a constant temperature all year around starting at a certain depth. These can be extremely efficient, you can get 5-6x the heat per unit of electricity consumed from these. Of course the initial investment is high as you have to drill or otherwise bury the pipes/ hoses into the ground.

Mostly it's about safety though. About 25% of accidents in homes happen around cooking. Having an open flame is a problem, breathing the microparticles and increased CO2 also don't help. However, to be accurate, gas stoves seem to cause less accidents than resistive heating stoves, because the flame is more audible and people seem to be more careful around it. Induction is safest.

The economic efficiency can be increased, if you can get rid of the gas connection. Also, if you can store/ produce electricity, you can optimize costs further.

We do have a quite regular Siemens dryer with a self-cleaning heat pump, also quite standard now. It runs for years, we've got it with the apartment, dries most loads in about 2 hours. Yes, it was probably a higher-end model when new but it's worth it - I guess it runs at least once a day on average.

My assumption is this isn't the way it works because it would be doing work up front, when it's not clear that the return will be necessary at all (think UDP). The response could be some time in the distant future or never, keeping the mapping in memory could be a problem (IPv6 design is 30 years old... and fast memory was even more expensive back then).

Laser etching QR codes onto thin sheets of non-corroding metal or ceramics may be a lot easier to preserve and read back. Also etching the ISO/IEC 18004 standard as text/ images may be doable also. Reimplementing the needed software can be done with today's AI in a matter of a day or two. (I have actually done that over a longer period of time though.)

... and Anthropic for instance.

Look at how much the components cost 6 months ago and now. That may explain why some calculations shifted considerably. It may be an act of keeping up with the market and having some reserve.

I would like to strike a better balance between charging by the hour and complete fix price, especially where the work is hardly predictable up front. The problem here is a mix of trust, respect and discipline. If both parties share these values and an hour really represents useful AND needed output than the actual time spent would always be larger than the billed amount. We do have such understanding with some clients and consultants/ contractors. This works well if the work is on-off, shorter projects with people that have a long-term professional relationship. Of course, such an approach will never go down with people who have a stubborn accounting mindset.

Within the tech industry, we rely on people to think things through well. Because like with other engineered systems actually changing things later has a real cost, even though it's all an artificial, massless construct and even though we do have AI to do some of the grunt work. The problem is, we are building understanding, predictability and bigger changes tend to make some assumptions obsolete. Sometimes you don't even know which exactly, unless you have precisely engineered the change - costing thinking time that is mostly invisible, e.g. people only write down the result of the thinking or the gist of the straightened path to that result if you are lucky. Almost nobody writes down the paths not taken and the reasoning for those decisions along the way. All of this is the proof of work that's missing or that's hard to verify, if it was created honestly and not inflated artificially.

So yes, measuring work, efficiency of spending time doing work and agreeing on compensation are the hard parts, especially if we cut trust out of the equation.

In effect if the operating system knew about the DRAM layout, it could for instance double critical data structures and race the processing. Maybe this would be helpful in the networking areas.

On the other hand this can maybe get fixed in hardware by just copying the page that's being refreshed to the side somewhere, eliminating the whole waiting problem. Last but not least, AFAIK writes to a row already recharge the capacitors so there shouldn't be a need to refresh it. What am I missing?

It also allows you to write stuff like Rama, Specter (@nathanmarz) and to wrap stuff that you do often to avoid boilerplate.