note: i've been doing lua for two decades and am well familiar with the language itself as well as its inner workings (far less so with python), and i've been building distro tooling for almost as long, and no, definitely not
sure, in fact i updated an entire distro to a new python major version several times
cbuild started iirc with python 3.8, currently it requires at least 3.12 due to some features (it will stay on that minimum for a while, though newer versions are always supported), updating it has always been seamless though
it's absolutely the kitchen sink standard library and "complex" language that makes it worth using, because 1) it means no additional dependencies and 2) the language is expressive enough to let the template syntax remain simple and well-abstracted
have you ever tried bootstrapping python? because it's really not a big deal (the only hard dependencies are a C compiler, libffi, and zlib, though distros also add libedit or readline, expat, sqlite, bzip2, xz, and openssl, all trivial dependencies present in more or less any system); tkinter is pretty much always compiled and packaged separately
meanwhile with lua you'd need many additional modules, and the templates would be verbose and far less readable
a non-exhaustive list of stuff python provides that would need to be provided separately:
chimera definitely goes for its own type of experience, the source of the core tools does not make that much of a difference in that (they were mostly chosen for other reasons anyway)
that said i was a freebsd user for over a decade so it must have left some mark (even though generally the systems have little to do with each other in their general design)
the above is not entirely correct, alpine does have and always had signed packages
in the other aspects most distros are generally not much or at all better, since all that stuff is hard and takes extra infrastructure
in chimera we try to make source bootstrap possible and in general not rely on third party executables, but it's not always possible (e.g. some language toolchains were bootstrapped from official binaries originally) and we try to respect best practices for reproducibility (pretty sure alpine does too) but actually verifying it would need dedicated infra/resources, so we don't do it
scudo requires 64-bit atomics which make libc hookup on 32-bit systems a bit of a pain but nothing that cannot be overcome
it can only use the primary32 allocator on 32-bit systems, which is fine, chimera uses primary32 universally because it uses less virtual memory while performing more or less the same in practice
it's significantly and visibly faster than mallocng in most things user-facing, effectively anything that allocates and is multi-threaded (e.g. builds - LTO linking times take a third the time, web browsers are snappier, java is snappier, etc)
this is misleading, apk transactions are only atomic if no pre/post-install/deinstall/upgrade hooks run, as every invocation of a hook requires a commit of everything done until that point
they are not atomic in alpine, i highly doubt they are atomic in adelie, they are almost atomic in chimera, though there is still a couple places left that break that and i'm working on them (some of it also requires apk 3.x features and is not possible with legacy apk which both alpine and adelie are using)
lack of server-side decorations in mutter is primarily a technical problem that's not really easily solvable - currently the compositor code does not actually depend on any drawing library, to draw native serverside decorations it'd have to pull in entire gtk (a lot of effort was put into eliminating gtk from the wayland compositor path in the first place; mutter the X11 window manager, i.e. what xwayland applications use, has the dependency, so it can draw decorations)
serverside decorations are generally a broken paradigm too, pretty much no other system than X11 does them, and they introduce limitations and inconsistency to the application UI (the application can't reasonably control their contents so they're there to provide 3 buttons and waste a bunch of space), having integrated clientside decorations is one of the more visible reasons why gnome's UI feels polished and consistent
if the application is incapable of drawing reasonable decorations on its own, there is now libdecor (e.g. SDL uses it) and it has gained a gtk backend a while back, so it should be able to draw native decorations; while applications using a full toolkit have no problem in the first place, because the toolkits are fully capable of it
I generally just don't want to see anybody being attacked for the work they do; I'm fine with people criticizing RMS, since that's generally because of his views that deserve to be condemned, but I wish to see no hostility towards maintainers of GNU projects or systemd
the GNU codebases may have their issues (but not always; there are some very high quality ones), but that's still not a reason for personal attacks, and frequently the maintainers are just trying to do their best and don't deserve any of that shit
ideally I'd like to see an ecosystem where all the projects are represented, where the projects collaborate, adapt ideas from each other, and strive for portability and interoperability so that compatibility problems do not exist and so that users have the greatest freedom in terms of both hardware and software; but I guess that may be too much to ask
that part refers solely to gratuitous use of extensions in the code, it does not refer to things like cgroups for which there are no portable equivalents, or anything else that is required to implement useful functionality and has no portable counterparts
musl is just a mandatory choice; the toolchain configuration doesn't really allow running anything else (glibc doesn't go together with clang+compiler-rt, they only very recently made it build with clang and that's still assuming a gcc-centric runtime as glibc actually dlopens libgcc_s, and every other libc is going to be much worse in terms of support)
i think you overstate how much trouble it is to port software to it; most software does not involve any porting in the first place, upstreams are not that reluctant, and as for firefox having a specific crash, have you reported it?
slowness is typically a default allocator issue and that does not apply to us (in fact, it may sometimes be faster)
that said, scudo is highly configurable, and the performance reflects the configuration (you can even swap out the primary allocator, secondary cache, you can tune all the parameters, the TSD registry implementation has a big impact on multithreaded code, etc.), so it's not 100% representative - chimera's current configuration is further tweaked for both better performance and lower memory usage
scudo being this configurable is excellent because it is what enables such integration in the first place (other allocators e.g. frequently rely on ELF TLS, i.e. __thread and the likes, which would make libc integration very difficult and would require major changes to the dynamic linker, with scudo we instead implement a custom TSD registry and simply shove an extra pointer in the pthread structure)
source: made the thing