Chimera Linux: if you like BSD and Linux, why not both
There are some important questions yet to answer, however, and the distro is clearly not yet ready for prime time. There's no init system yet (let's hope it's not systemd, because that would really be an unholy union) and there's not even a kernel, so I can't tell you what it runs; presumably it uses the kernel of the distro you bootstrap it on. For that reason, don't even think about asking for a bootable ISO. The source package build system is also custom and it wouldn't be surprising to me if it manifested rough edges for awhile.
The other question mark is LLVM; Chimera relies on clang, not gcc. clang works for a lot of things on ppc64le but at least in my usage doesn't properly work for some large projects like Firefox, and its performance is marginally poorer. This is undoubtedly no problem on the other two architectures, but they are the primary focus of LLVM and clang, and OpenPOWER isn't.
Still, I think there's real potential for this project, quite possibly for people who would ordinarily be attracted to Slackware's philosophy but are more used to the way BSDs do business. (As a product of the University of California, I have great empathy for this viewpoint.) And there's already precedent: Mac OS X macOS is a Mach kernel, but with a BSD userland, and look at how successful that concept was. Sometimes the best choice is the one you don't have to end up making.
there is nothing particularly worse about clang on ppc64le than on any other architecture (it even supports some features that are not available on say, aarch64, and is fully self hosting, i.e. provides support for the whole runtime)
ReplyDeleteproblems with firefox (if they exist) must be isolated to firefox, considering we build chromium for ppc64le(-musl) with clang at void since the beginning and it's never caused any issues, and likewise other things work just fine; mentioning that performance is worse is very off the mark, considering clang is known to perform roughly the same (and sometimes faster) as gcc the last few years
the statement about being portable to anything with llvm/clang is not entirely accurate; you also need support in the compiler-rt builtins and crt (that means e.g. s390x is not possible right now, but big-endian ppc64 or say, risc-v should be fine)
and no, there won't be systemd (the current main choice appears to be dinit, if that ends up not working for whatever reason, the second main choice is s6-rc)
I stick by my comments on clang. I agree it has improved, but I still see poorer performance with some workloads on ppc64le, so I will continue to politely disagree. I'm sure it's fine on the other two arches.
DeleteDo you build firefox with clang? It builds now -- it didn't used to -- but it still doesn't work.
for your reference, firefox works perfectly fine on ppc64le with clang without any patches specific to clang: https://twitter.com/octaforge/status/1487554432405590023
DeleteThanks, I'll check again on the next spin. I'm perfectly willing to believe there have been subsequent improvements.
Delete(Also, if you have a particular .mozconfig you're using, that would be helpful information to compare. To answer what you said in that thread, this was not a PGO build.)
Deleteyou can just check the cports build template: https://github.com/chimera-linux/cports/commit/848ee43d31047ce817e43ade2fbe6cdcce845ccc
Deletealso if you happen to be building with bundled nss, this code is broken and just not used on gcc (because __ppc64__ is not defined there): https://github.com/nss-dev/nss/blob/master/lib/freebl/mpi/mpcpucache.c#L708 - it segfaults just the same on ppc64le on gcc, so i just patched it out
Yes, it was with bundled NSS. But wouldn't the system NSS need to be built with a similar change?
Deletesure - i build system nss (which is used for firefox) with the patch
Deletebut in your case, presumably the system nss would be built with gcc, so it wouldn't have the problem - because gcc does not define __ppc64__ and thus does not pick up the broken code