toast0

Below are the 2 reasons I could think of for not seeing the collision detector bug:

I wouldn't be surprised if floating point on an AXP emulator doesn't always match behavior on real chips...

If you're planning to run in clouds, committing to not buy hardware (during the contract term, presumably) isn't a big imposition. Maybe you switch to a different cloud, and you wouldn't buy hardware for that.

If you want to switch back to on prem, there's probably a way to structure acquiring hardware so it doesn't break the contract. Maybe you lease it, maybe the purchase happens through a related company, maybe there was no way for the contracted cloud to find out...

Well, "boonies" is pretty ill defined, but my criteria is most homes are are 10+ acre lots, and large lots are widely available.

You want your datacenter to be in reach of interstate highways (rail might be nice, too), two electrical substations [1], and close to fiber that's already run. That restricts your available boonies, but there's still lots outside of the east coast.

[1] yes, you'll have onsite generation, and yes, you might plan to run from onsite generation most of the time, but you still want to have the option for utility power, and it's nice to have two substations to get more uptime, subject to more transfer switch complexity.

so they can likely find a way to close that gap

I mean, typically you just list your job in the nearby major city, even when the site address isn't there. Same thing that you do when listing your hotel or your car for sale.

You need on the order of 15 permanent onsite employees to run a datacenter; 5 each for 24/7 coverage of security, building maintenance, and tech. You probably don't really need 24/7 onsite for building maintenance or tech. Traveling employees or (probably traveling) contractors can handle projects that exceed the local scope.

Should be able to locally source security and building maintenance, if the pay is good. These are skills that are needed everywhere. The onsite tech can likely be sourced locally too: first and foremost, they're remote hands ... knowledgeable remote hands are nicer, but the mandatory skills are: read and follow directions, notice and report unusual circumstances, lift and manipulate heavy objects. It's not rocket surgery.

If you put your datacenter in the near boonies, say 30 minutes away from the nearest suburb, you can usually still find the big lots you need, and people can commute from there: a 30 minute commute with no traffic isn't too awful. Of course, you'll have neighbors on large lots who didn't think through that living out on the boonies with no zoning meant noisy neighbors could move in. :P

Yeah, mix some creatine in with the thermal paste. It should help!

We do this and then no one reads it.

A) this is what happens with documentation, in general.

B) as an experienced reader of documentation, I can often tell when the documentation is likely to be accurate. It's not worth reading documentation that's inaccurate. AI written things tend to be inaccurate and not worth reading.

You should be happy that your people know to ignore the work you and the boss half assed.

It's much easier to discontinue military (and other) cooperation than it is to unshare knowledge.

Eh, xeon 2690 was released 2012q1 at 8 cores, 2690v4 was 2016q1 at 14 cores. Same suggested customer price. Clock speed dropped a bit, but IPC was way up (AES-NI had a big throughput increase among other things). IIRC, desktop core counts were pretty stagnant, but a Haswell/Broadwell desktop chip at the same corecount and similar clocks was much faster than a Ivy Bridge/Sandy Bridge.

During 2012-2016 AMD was firmly in the Bulldozer disaster.

In 2017, Zen1 came out, and Intel's tick/tock mostly stopped. Zen1 was better than Bulldozer, but not better than Intel. Zen2 in 2019 was the big moment, and Intel hadn't done much. I recall an interview where the AMD person (might have been Jim Keller) said they had been targetting Zen2 to be competitive with what they thought Intel would have when it came out. Since Intel was in their pipeline bubble, Zen2 was a big win.

Can't undo a 2013 tech sharing agreement because you got a call in 2023...

If this was a feature they wanted to provide, it would simplest to set the Roku up as a bridge. No dhcp, no nat, just a virtual switch. Roku devices run on Linux, if their HDMI chip supports Ethernet and that's plumbed to a Linux supported MAC (probably not), it might take an hour to build and test the feature. Longer if the wifi interface doesn't like being bridged (I've seen that on some openwrt devices).

There's esp-idf examples from espressif for doing bridging on an esp32 if you have one with a MAC and a PHY and/or spi mac+phy.

Or for wired ethernet, they could include a three port switch IC.

E-Arc uses the wires intended for Ethernet. Hook your Roku up to an earc port if you're seriously concerned about it.

Harder still is when the cause of the bug happens prior to its manifestation.

I've yet to debug a big where the manifestation happens prior to the cause... Sounds even harder. :p

but the study conflates both into the same bucket if they both make, say, $400K/yr

Annual income is easy to measure, net worth isn't. People like to measure things that are easier to measure. :P This is part of how 'millionaire' has gone from 'someone who has a million dollars' (for some value of has) to 'someone who has a million dollars of income per year'

SNES Doom shipped with a Super FX 2 in the cartridge, a custom RISC chip with a pixel-plot instruction, because the console's own CPU had no chance.

The Super FX is a custom RISC chip, but it was custom made for Star Fox and used for other projects with refinements.

even differences between an Intel i5 and Intel i7 pile up

i5 and i7 are terms which lack precision. Are you seeing different results for the same operations on the same arguments in the same order across an i5 and an i7 with the same core architecture?

Regardless, it would be great if you have examples of operations that have different results on different processors; my expectation was that I could expect same width, same operation, same arguments to provide the same result across most x86 processors (early pentiums not dividing properly and maybe more variance in the socket 7 days where there were so many vendors). Most of the issues I've seen documented were not running the same sequence of operations especially around 80-bit floats on x87 if something spills to a 64-bit double in memory. All that said, I prefer to deal in integers whenever possible, I know the edges of floating point are sharp, and I'd rather not be cut.

Of course the dark side of the moon is illuminated by the sun at times. But it has minimal human illumination, so that's pretty nice.

Let me kmow where I can get ECC RAM that's only 12% more than the price of non-ECC and I'll strongly consider it the next time I do a build. (Otoh, prices are high, so I'm not building anything for a while unless stuff breaks)

A lot of reservation land is owned by the tribe, so the tribal government can approve of the use both as the landowner and as the regulator, and potentially as the court in case of complaints. That does help things get done quickly.

If a datacenter brings infrastructure with it, such as telecom, grid, and water, that could be a boon as a lot of tribal land has a lack of utilities. There's also a real chance that development will exploit tribal governments without benefiting the tribes.

What really seems to make a difference is how well the project and the organization are at being split into indepedent groups.

I've been on projects where everybody needs to know everything, and on projects where many groups can be insulated from others.

The more your group can work without needing a meeting with other groups, the more things can progress in parallel.

Some projects won't work well with that constraint though. And some organizations won't either.

Reflecting the sun means the rail no longer has to fight the sun's heat.

Without the paint, the sun heats the rail and heat expansion fights against the elements holding the rail in place until the rail cools down or something moves. If the something moves, trains can derail.

Well,

a) did you pay your Elixir contractors more than you would pay a Java contractor for similar work?

but also...

b) scarcity isn't the only factor in price. Erlang/Elixir developers are scarce, but Erlang/Elixir jobs are also scarce. You need both demand and scarcity to raise prices. Also, it doesn't cost much to turn a willing, good developer into an Erlang/Elixir developer; substitute goods reduce the impact of scarcity.

also c) if you found contractors, but not employees, maybe you weren't willing to pay enough... So maybe the price is higher than you thought?

In the end, it's basically a Toyota Hilux.

A Toyota Hilux, sold in america would be nice. The small truck market is slim pickings... other than the slate (which is still vaporous), nothing small with a regular cab has been built in a while. Old trucks won't last forever.

It's been a while, but I used to work at WhatsApp and we used Erlang distribution heavily. I understand the clusters have gotten really huge since I left.

It's super handy. There's no security barrier between nodes. It's a headache if your network is unreliable.

For a chat app, messaging someone becomes a series of steps:

a) look up if they're online (send a message to the presence database service)

b) if you got a process id back, that's the process connected to the user, so send it the message. The process could be on the same machine or not, but the sending api is the same. This is the special part: few other environments make arbitrary messaging between processes/threads/tasks/whathaveyou so pervasive.

c) if you don't get a process id back, the user is offline; send the message to the offline database.

appreciate Elixir but the problem is the job market/talent pool is tiny compared to other existing languages.

I shipped an entire telecom infrastructure with barely knowing Elixir and we brought on contractors to audit the code and they found no issues.

Erlang/Elixir experience is rare, because it's not widely used and the teams are small. It's not worth trying to hire for it. Hire for people who can figure it out on the go (amd are willing to give it a try).

You did it, hire other people who seem likely to be able to.

Yes. But in some cases the waste will be avoided by not doing a production run at all if the minimum production quantity is too high and the law prohibits destroying the unwanted product.

You don't have to reduce the taxes. Just phase out the concept that you are paying into a retirement account and call a tax a tax.

I don't know how you sell that.

"Hey, guess what whipersnappers? You all will still pay the line item for Old Age, Survivors and Disability Insurance, but you won't get anything from it. Thanks, -- Old People who get to spend 12.4% of your income"

Fashionable clothes are perishable. "Nobody" wants to buy clothes from last season or last year.

Storing the clothes until they come back in fashion is expensive... and some materials really won't be useful after sitting for 10 years anyway. (Elastic bands really are perishable)

How it it a Windows issue that driver developers pack garbage with their drivers?

Because windows update automatically installs the garbage when the device is connected.

Microsoft could control the content of the software it automatically installs, but they don't. That's the issue.

Microsoft has a program to do static and dynamic analysis of drivers... not a sandbox, but better than nothing. Of course, wonky drivers plus wonky hardware can still do bad things (io-mmu can help, a bit).

The problems tend to be in the userspace software that's also installed with the driver. Sometimes there's also some pretty derpy stuff where the driver wants to talk to the userspace software but there's no validation/verification and that opens up a big hole.