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
