Unofficial sources are starting to say that XPoint does not exhibit wear from write cycles and the "1000x more endurance" is normalized to some other metric. If it was normalized against time, then you may expect NAND to last 3-5 years which would put XPoint around 3,000-5,000 years life time. We won't know until more official data or hands-on reviews happen.

DDR3 is about 10ns. If XPoint is 1000x faster than 5us NAND, then it has 1/2 the latency of DRAM. I doubt it, but you can see how it can easily be within a a factor or two.

When you restart your computer without a power down, you still have all that data in memory. Same difference. As for a power down, the only real benefit is it also resets the CPU and other hardware. When the BIOS starts up and copies data from the HD into memory, it already over-writes what was ever there. No changes required. If you want to take advantage of having persistent memory, then you'll need new protocols, but old protocols should continue to work as expected.

shark bait hoo haha - Finding Nemo

2ms is a few magnitudes too high for NAND. Google is returning back latencies of 5us-25us for NAND.

That only works if the newly resulting blocks are the same. If you cause all of the data to shift, then all of the data in the blocks could also shift creating blocks are that not the same. Flipping bits is one thing, but changing length is another.

And you'd both burn our your CPU's SRAM and DRAM in under a year. They're only rated for around 10^16 writes.

TLC VNAND has upwards of 60k cycles, but as low as 5k. Depends on how fast you want it. It's a speed-endurance tradeoff. 60k cycles is about 1/3rd the speed of the 5k cycles. With a non-linear tradeoff that causes diminishing returns on gained speed, there's bound to be a happy medium.

My LCD monitor takes longer than 1sec to turn on. I'm not too concerned. 1sec is "instant" for this class of interactions.

Flipping at bit at 100mhz would burn out your L1 cache's SRAM in one year.

This is where a good manager comes into play. My current and past manager would tell the other departments that if they could not do a good job in a timely fashion, we would do the job.

A programmer's productivity is relatively static. What's important is the quality of the code that allows the programmer to multiply the productivity of others. Code quality becomes very important as each layer of dependencies compounds the complexity of the system. 80/20 rules great until you're 3 dependency layers deep and 0.8^3 is only 0.5.

Sometimes the only way to fix cancer is to destroy it.

If a project is to take less than a month of uninterrupted dedicated work, I can usually get the time within 80%, siding on caution, so typically early. The further a project is expected to take, the more buffer I need to add in case things take longer.

As a programmer, it is my job to get into the head of the end user and figure out what they're trying to do. Requires seeing what they do, unrderstanding why they do it, and the end result.

"Union" is a dirty word because of cases like this. Someone at a local union shop was coming into work 2 hours late, strait from the bar and pissed up, then would leave 2 hours early, handled heavy equipment which resulted in some near accidents. No one told on him because he was high in the Union, but the company looked into the near accidents that got reported. Once finding out this guy was coming in late and drunk and leaving early, they fired him. A month later, the Union successfully sued the employer for firing the employee without first consulting the Union for permission. The person was rehired at his original wage and pretty much given a job to do nothing because he was always drunk. The employer finally got him to leave by offering him money to leave.

Crap like this is why people around here hate Unions.