q66

at least it actually supports blowfish

pretty much the only place where it's meaningfully slower is the allocator (which has a massive impact) so in chimera we have a special musl build that uses llvm's scudo instead (same as e.g. android) and is faster as well as more secure than glibc's allocator

the rest is mostly fewer specialized implementations of stuff for different cpus, but that rarely makes a difference in practice (i.e. outside of microbenchmarks)

the overall standards compliance is pretty good in musl

i don't think that statement makes much sense considering these two are not similar at all

chimera provides a comprehensive, opinionated OS, and little to nothing is common with alpine (not even the package manager, as apkv3 hasn't been deployed anywhere else)

it's probably the only linux distribution that has actual goal of having service management and other things practically comparable to systemd without using systemd, including first-class and built-in support for user services, session tracking and others; it utilizes stronger userland hardening than alpine (including e.g. clang CFI, until now only really deployed in android as far as linux distros go), has a superior (faster, more powerful, more secure) packaging infrastructure, and so on and so on

as for non-GNUness, it's more of a how it turned out thing and a means to an end, not a goal or a selling point in itself (it never really was that), however any sort of "why not use GNU" question is itself fallacious, considering this is a from-scratch project and there are always choices to be made (and there is no reason not to choose the one that fits better and provides practical advantages)

the faq has a lot of more detailed information: https://chimera-linux.org/docs/faq

fortunately, there is a FAQ which answers that and other things: https://chimera-linux.org/docs/faq#so-why-use-a-bsd-based-us...

it's actually just virtual memory, neofetch uses that instead of real memory consumption and the scudo allocator tends to be heavy on reserving virtual memory (actually much more so in the default configuration used in e.g. android than in ours, as i've already put some effort into optimizing that), it's harmless in most configurations (the real memory usage is much lower) though i still plan to look into that more later

sed -i does work in bsd-type environments (in fact, freebsd and gnu added the -i argument around the same time, in early 2002), the main difference is that bsd variants follow strict getopt shortopt parsing (i.e. no optional values, and -i always takes a suffix, with -i '' being equivalent to just -i in gnu) while gnu sed -i is quirky and reliant on its own getopt extensions (in gnu, sed -i '' does not work, but sed -i'' does)

the common portable invocation is something like `sed -ibak`, which works in both variants, and then remove the backup file; as far as i know, there is no way to portably invoke sed that does not backup

the reason python was used is because of its portability and robustness; it can be made to work (without problems) on pretty much any platform, plus it's omnipresent and has an extensive enough standard library to write things without pulling in tons of dependencies

it's also not actually a package management tool per se (that's handled by apk-tools) but really just a build system (it creates apk repositories) similar to ports, void-packages, etc.

i'm also a Void Linux developer, and the new system is based on my experiences with xbps-src (trying to avoid its problems)

i did intend to use pkg at first, however, after some experimenting apk turned out to be the better option (there are things pkg still doesn't support - such as version constraints, getting it to work on musl is a fair amount of patching, its shlib scanning is semi-broken on Linux, and its repo indexing is insufficient for my purposes)

i do use BSD make for a lot of components, but yes, there are a few where GNU make is not easily replaceable :) there are plans to change this eventually, but nothing has materialized yet

yes, i originally planned on making my own ports, but after seeing dcantrell's work, i decided to help out over there instead (i did a lot of the recent ports)

actually i had gcc in there at first, and it's roughly the same; however, clang does have a number of benefits of its own

the GNU tools have bigger featuresets, but from code quality aspect i much prefer the BSD ones

it's not targeted at embedded, but it is an experimental project for the time being (the motivation is a split between "because i could", "i wanted to provide polished ports of BSD software" and "i wanted to experiment with making a better package build system")