rjek

View it in the editor instead.

Everybody knows about bitfields :)

The compiler can't know at compile time with a naked pointer like it can with an array. [static 1] is handy to say it must not explicitly be NULL, as if it were optional, however.

It's a C99 feature, and clang's the only compiler I know of that produces the diagnostic (and only in later versions)

btw; I wrote this talk.

Please tell me who you work for, so I know to avoid any of your products. Using BBC Basic like this terrifies me. If anything, because its total lack of type safety for anything but the simplest of values.

High-density ARM servers are not ideal for every application. However, there are plenty of applications where you don't need massive amounts of computational grunt in each CPU, such as web serving, hadoop, mail and DNS servers, etc. Also, the density and lower power/cooling requirements can often offset the lack of performance. Each slab has a 260W PSU. The whole system can't pull more than 260W, ever. Some Intel CPUs need 200W just on their own.

In general, high-density or supercompute systems are installed with custom racks, cooling, power supplies, etc. This doesn't need anything custom, just something that isn't always the default in some DCs.

They're ARMs, they don't need much cooling anyway.

What understanding is it that you have that suggests that? It can shovel data via DMA as well as the next architecture.

You could do, or have one of them exhaust to its "front", and the other exhaust to its "back".

Yeah, it's eight individual systems with two very fast Ethernet links to an on-board managed switch.

Half depth, not width. Everything comes out the front, so you mount them back-to-back in a rack.

Yeah, I see they have the same sort of "talk to us for pricing and more info".

Important things to note is that each of the nodes in this Slab have their own local SATA solid-state storage, and the individual CPUs are quicker. The Boston thing has higher density though.

And you can buy them where, exactly? :)

If I have anything to do with it, in the next month or so :)

The only thing they're not in the same ballpark for is quantity of generated data. If you don't need much, this is as good.

Possibly. If your SSH and HTTP daemons and encrypted file systems use /dev/random, and you're running Linux, then possibly. Look in /proc/sys/kernel/random/entropy_avail, and possibly graph this over time. Also, some modern Linux distributions use data from the random pool at exec() (to randomise linkage), and so it's possible you could be running low already. TLS email also consumes huge amounts, and anybody running virtual servers might be having a problem.