Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

[Jonathan Wiltshire <jmw@debian.org>]

On Fri, Jun 29, 2018 at 06:05:55PM +0100, Luke Kenneth Casson Leighton wrote:
>  apologies for repeating it again: this is why i'm recommending people
> try "-Wl,--no-keep-memory" on the linker phase as if it works as
> intended it will almost certainly drastically reduce memory usage to
> the point where it will stay, for the majority of packages, well
> within the 2GB limit i.e. within resident RAM.
[...]
>  most of them won't have native SATA: very few 32-bit ARM systems do.
> GbE is not that common either (so decent-speed network drives are
> challenging, as well).  so they'll almost certainly be USB-based
> (USB-to-SATA, which is known-unreliable), and putting such vast
> amounts of drive-hammering through USB-to-SATA due to thrashing isn't
> going to help :)
[...]
> 
>  the allwinner A20 and R40 are the two low-cost ARM systems that i'm
> aware of that have native SATA.
> 
> 
>  there is however a new devboard that is reasonably cheap and should
> be available really soon: the Rock64Pro (not to be confused with the
> Rock64, which does NOT have PCie), from pine64:
> https://www.pine64.org/?page_id=61454
> 
>  it's one of the first *low-cost* ARM dev-boards that i've seen which
> has 4GB of RAM and has a 4x PCIe slot.  the team have tested it out
> with an NVMe SSD and also 4x SATA PCIe cards: they easily managed to
> hit 20 Gigabits per second on the NVMe drive (2500 mbytes/sec).
> 
>  also worth noting, they're working on a 2U rackmount server which
> will have i think something insane like 48 Rock64Pro boards in one
> full-length case.
> 
>  the Rock64Pro uses the RK3399 which is a 4-core CortexA53 plus 2-core
> CortexA72 for a total 6-core SMP system, all 64-bit.
> 
>  if anyone would like me to have a word with TL Lim (the CEO of
> pine64) i can see if he is willing and able to donate some Rock64Pro
> boards to the debian farm, let me know.

None of this addresses the basic DSA requirement of remote management.
Troubling local hands to change a disk once in a while is reasonable; being
blocked waiting for a power cycle on a regular basis is not (and I can't
imagine hosting sponsors are wild about their employees' time being used
for that either).

Development boards just don't cut it any longer.

-- 
Jonathan Wiltshire                                      jmw@debian.org
Debian Developer                         http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51