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.
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.
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.
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.