Re: ARM port(s) BoF at DebConf
On Thu, Jul 19, 2012 at 6:35 PM, Steve McIntyre <firstname.lastname@example.org> wrote:
> Both armel and armhf are doing well, covering ~96% of the archive. We
> don't have any ARM server hardware yet, so we're stuck using
> development boards as build machines. They work, but they're a PITA
> for hosting and they're not designed for 24x7 usage like we're doing
> so they're not that reliable.
there was a post on the arm-netbook mailing list about a 7W quad-core
tegra3-based mini ITX motherboard which could take up to 2gb of RAM.
whether it's the usual
style of vapourware or actual reality i'd strongly suggest someone
gets onto them and considers putting together a group buy / bulk order
just to make it worthwhile their time making a batch, because it's
literally the first ARM-based machine i've ever heard about that can
actually take 2gb of RAM.
oh: also the motherboards have eSATA and uPCI-e, hm let me find the
post.... here you go:
btw, steve: it's not the c++ doing linking in swap that's the
problem, it's trying to do *debug* builds of c++ applications that's
the problem. webkit for example requires a minimum of 1.4gb of
resident RAM for the linker phase if you enable debug builds. i have
mentioned a number of times that it's debug builds that are the
problem, and that all you have to do is disable debugging (*1) and the
build will complete within 15 minutes instead of 15 hours, but as
usual because it's that "fucking moron lkcl telling us what the fuck
to do" nobody bothers to listen. well, keep on not listening for as
long as you (plural) find it useful to do so: i'm not the one with a
PITA for having to wait 18 hours for a debug build of a c++ app to
complete, am i, eh? *eyebrows-arched*....
(*1) and if someone _really_ wants a debug build of that particular
problematic package, on a build and distro port that's still
experimental, well, surely they can compile it themselves, using their
own resources, yes?