Re: MIPS support

[Vincent Legoll]

Hello everybody,

I'll do a single email answer, hope that is not off limits...

The gnubee is dual-core x 2 threads, 880 MHz 32 bit mips, 512 MB RAM, 2x1Gbps
ethernet, 6 SATA ports, SPI flash & microSD, USB 2 & 3, u-boot bootloader.

http://gnubee.org
https://www.mediatek.com/products/homeNetworking/mt7621n-a

To Jack Hill
> There seems to be a a fair amount of the router-class hardware available
> that works with Free Software, but not much, if any, of the latter, more
> powerful hardware. Unfortunately, I think having the more powerful
> hardware available would make it much easier to work on the port.

Yes, there's only a handful of desktop-class hw available, and it's
hard to find,
probably expensive too.

On the other hand there are a lot of router-class hw, and the gnubee which lies
in between .

Debian has a lot of mips hw available, see:
https://db.debian.org/machines.cgi
maybe we can ask for an account there if needed.

> I feel similarly. It's always sad to see things go (I used to have a
> collection of SPARC hardware, but let it go when I moved a few years ago),
> but no need to keep it just for me.

I never got my hands on sparc (to own one, we used to have sparcs at school, and
even alphas then, I'm getting old...)

> Vincent, it sounds like there are at least two of us. Maybe we can work
> together.

Yes, certainly, I really hope to be able to get something done on that front.

To Christopher Baines
> At least the main blocker for me is the lack of substitutes for the
> things that fail to build with QEMU. So maybe one or a few machines
> which were able to build those specific things would be sufficient to
> provide some substitutes.

I still not have tried mips (arm*, powerpc* and even there I still do not have
gone very far, but only tried cross-compilation which has it own set
of problems).

Can you elaborate a bit, compilation through qemu should be slow but
mostly work,
at least I hope. We should have a look at debian's arches MLs, there
are a lot of
efforts made to fix and upstream things, being done there.

> I did have a look at seeing if I could purchase hardware, but I didn't
> really know what to look at. Maybe we could try putting out an appeal
> for MIPS hardware, maybe someone has some they don't use and would
> donate?

I jumped on the gnubee, as even if it only is 32bit, it was nicer hw than the
available routers. I think the crowdsupply campaign founder still had some
available last I heard. There are 2 versions one for 2"1/2 drives and one for
3"1/2 that was in a following campaign (I didn't grab one of those). It is not
dirt-cheap, though.

To Leo Famulari

> It's not really a maintenance burden currently since we don't actually
> build or maintain the Guix on MIPS at all.

OK, that's (kind of) nice to hear, that it is not a great burden for guix
maintainer

> I think this discussion is evidence that people find the situation a bit
> confusing. When I am looking into a project, I find it demotivating to
> read documentation about features that may or may not work — it's best
> when the documentation accurately reflects what the software can do.

Yes, exactly, that's why I asked if there was any incentive to try to document
the state and actual efforts being done on the porting front.

https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00175.html

> So, whether or not to officially retire the Guix MIPS port would not be
> related to supporting Guix on the GnuBee, which would be cool!

Yes, maybe apart from a few entries in case/switch statements, this would not
cost us a lot of SLOCs, then people can build themselves and/or share the
results with guix publish, and make it into a collective effort...

OpenBSD is also doing a lot of work supporting some select old HW, their ports
building time is in weeks for some of them. So it should be doable.

> Declarative NAS configuration would be nice :)

Yes, the power of guix to the rescue of poor old hw !

> It would be helpful to get some clarification of the relationship
> between these architectures before deciding what to do.

If none of us has access to any mips64 (which is what I think guix support
was targeting), the point is kind of moot.

And there's also the problem of guix/scheme being hard on resources (This is
something I'm not really sure, but the attempts I did on arm32 were not really
promising on that front, which is why I postponed further investigations there.
Hoping to get accustomed with guix porting for ppc64 which don't have those
problems in the mean time)

That was a long one...

Thanks everyone for guix it's a refreshing thing !

--
Vincent Legoll