q66

no it didn't

source: made the thing

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

well that's just what the LWN article states, the project itself does not do that anywhere

the desktops on chimera are standard (gnome/kde/xfce and a variety of compositors and window managers available for installation)

considering it's not a bsd nor it's trying to be like one, that question doesn't make a lot of sense?

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:

1) subprocess management 2) path parsing (and normalization, manipulation, etc.) 3) various filesystem operations 4) shell command lexing 5) globs and fnmatch patterns 6) json 7) date/time handling 8) filesystem advisory locks 9) temporary file handling 10) http client (for sources fetching without external subprocess) 11) termios and ptys (for isolation of controlling terminal) 12) regex 13) hashing 14) topological graph sorting 15) cmdline argument parsing 16) readline functionality 17) thread/task pools

and so on and so on

chimera does not interpose malloc, we outright patch it out inside musl, so not really something musl would support

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)

mozilla may not fix it, but they won't reject a patch, and if you keep it to yourself you're ensuring that it'll never get fixed

you said chimera's builds are affected by this, which means you've presumably tested it there; i see no bug report about it in cports either though

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

it's solely FreeBSD as an upstream for us, though Net/Open are an upstream for FreeBSD itself for some tools

the tools have made big strides over the last few decades, so it's nowhere near like it used to be back then

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)

there is a combobox to pick the repository: https://pkgs.chimera-linux.org/packages?name=xserver-xorg*&r...

i ran that when doing the initial porting: https://gist.github.com/q66/84288d3b8e70146a630f65dc1de4b683

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)

good news for you then, since there is a full distribution of xorg in the contrib repo and it's not expected to go away anytime soon (if ever)

chimera is designed to solve many issues other distros have; this includes e.g. the poor state of toolchain security hardening (you won't find any other distro with the same practical scope that's more strongly hardened in builds)

cbuild is also designed to solve real issues, particularly proper sandboxing and linting of builds to allow for a small team to maintain it while at the same time being fast and ensuring correctness (distro build systems often tend to be bash/make monstrosities that do nowhere near enough where they need to while doing too much where they shouldn't)

i used to work on void, and there are good reasons i went to start a new project instead; this includes poor quality packaging for a lot of void stuff (by part caused by xbps-src design choices), poor platform support (all non-x86 stuff is buggy, partly because of cross-compiling and not running unit tests for things being built) and state of infrastructure, design issues of xbps itself (lack of solver, poor implementation of shlibs system and virtual packages, etc.), lacking service management (no oneshots, no transparent/standardized support for user services, no support for dependencies, no support for service-integrated dbus activation etc.), lots of stuff sticks with legacy nonsense where systemd has taken over and improved things in the meantime (e.g. handling of dbus, user management and tmpfiles management, user services as mentioned before, etc), and so on and so on

we are also addressing the whole thing with "everybody has adopted systemd and its functionality, and distros without systemd have instead stuck their head in the sand and pretend systemd is the devil and implement none of the stuff people want" which is leading to increased dependence on systemd in various upstreams, and an increasing amount of bad hacks in non-systemd systems

supporting a lot of architectures is not something to regret, it's a good goal to have and aids keeping the ecosystem healthy as well as giving people the choice of running the system on hardware they like; any pain caused by supporting multiple archs pays off several times

i believe you are just making assumptions here; debian in this context does not count as a "simple system", if anything it's as complex as a distro can be and its packaging approach is a polar opposite of chimera's

i still like debian either way, because it's a nice community with good values/principles that has provided and still provides great value to the ecosystem, but it can also often be very fragile

the "just works" point of chimera stems from how things are built; everything it comes with is made to be "install and go" without having to go extra length to enable and set it up (while still being entirely transparent to the user), while being deterministic (packages in general don't rely on install hooks etc.) to ensure safe upgrades and easy auditing, and all that in a framework of a system that has a fraction of the complexity of a large distro and is maintainable by a small team

we make it consistently clear that it's not a reactionary project (https://chimera-linux.org/docs/faq, https://floss.social/@chimera_linux/111553324359284350, etc) and has no hostility to GNU or any of the projects we use alternatives to by default (and anybody displaying such hostility is unwelcome in the community)

the point with "just working" applies to what the system ships, obviously third party whatever is outside of our control

the system aims to have high quality packaging that results in a system that is consistently deterministic and auditable, while indeed making things just work (no extra effort beyond just installation required to get any software the system ships to work - on any CPU architecture it supports) - you can bootstrap a fully working system pretty much just by installing a single metapackage + a kernel in a root (and then refreshing the bootloader)

they do though, just not in the way you think; in general chimera is designed so that whatever you install from the repositories, it'll yield a working out of the box configuration

you want a desktop? you install it and it works; there is no (mandatory) tinkering with getting dbus, audio, wifi/bluetooth, or whatever else to work - most importantly things are set up in a way that installs are consistently deterministic and auditable (there is no reliance on complicated shell hooks or anything of the sort to do any kind of "fixups", most packages consist solely of extraction)

sure, when you involve third party shell scripts or whatever, there is a chance you'll run into compatibility troubles, but perhaps not as often as you think either

chimera is not much like freebsd at all, besides adopting the same core tools; it's mostly designed from scratch, and does not particularly try to "emulate" anything

i do like freebsd, i used it for around a decade so it probably left some mark (just like other systems i have touched over the years, like void and debian), but chimera does not try to explicitly be like anything else - i simply do what i feel are fitting design choices

it's designed to be a hacker distro; i just felt like "hacker distros" frequently tend to make a lot of things overly manual for no reason primarily due to halfassed choices made when packaging things - the way things are built in chimera is so that whatever is in the repo is "install and go" - and this includes things like large complicated desktops, in general things are designed so that if you bootstrap a system from scratch (by installing all the packages in an empty root) you need to do nothing more - other than the stuff you wish to explicitly change, and this is done without involving complicated scripts or anything of the likes, vast majority of packages install by simply unpacking themselves

to a degree your system package graph also defines your system configuration for things that are coarse enough to allow it; it's also easily auditable

the system does not aim to bring anything "to the masses" right now, considering the stage it's in; likely won't in the future either, as it's aimed at power users primarily

you can run steam in flatpak (it's there), chromium will probably come natively in not that long, it does not seem like that big of a nightmare besides the ways chromium is a nightmare in in general (you can run it in flatpak too right now)

there is no apparmor right now, but it'll come

in most applications where it matters, it actually tends to be the allocator; you'll find that especially interactive applications (e.g. browsers) tend to feel significantly more responsive in chimera than in alpine, as well as other things (e.g. LTO link times with lld take a third of the time)

the above is incorrect, chimera does use scudo but it patches musl to achieve that

and scudo is probably one of the few allocators that would work for this purpose, it absolutely cannot be applied to any allocator; there are some concerns that get in the way of that, e.g. the handling of ELF TLS in a libc (ELF TLS may not be and in musl's case is not available within the dynamic linker, which means you cannot use __thread and the likes anywhere within libc.so; scudo is designed to be flexible so you can get around it (we shove a pointer to the thread-local state directly in the pthread structure and manually mmap the data for it) but that is not necessarily the case with many other allocators, including mimalloc, hardened_malloc, and others)

musl's code is hardly pretty, but considering every linux libc's code is cursed and especially glibc's, musl still more or less wins there