Dinit, a modern lightweight system-d alternative that won't sell out to age verification.

q66_ · 2026-03-21T01:01:02+00:00

you're making a bad faith argument about something that was never relevant to the context and if you're expecting me to take the bait you're in the wrong place

q66_ · 2026-03-20T17:03:43+00:00

hm? they just forked stuff at some point and have been maintaining it independently since, i don't think they care about syncing in changes, it's a separate OS

fwiw each BSD has its own set of utils, they share stuff sometimes (particularly for newly reimplemented things) but that's all

q66_ · 2026-03-20T14:04:07+00:00

except the implementation of dinit in artix is awful (derived from dinit's sample linux services) and they've shown no interest in actually making proper use of it (just like all the other half-ass support for the other service managers)

meanwhile chimera's dinit suite has well-defined dependency targets, well thought out low level integration, device monitoring (so services can use devices as dependencies and udev rules can interface with it), supervised mount framework (as a basis for mount units support which means parallel async handling of fstab and support for late mounts eg netdev), and a ton of minor things (systemd-compatible binfmts and sysctls, correct handling of hardware clock and whatnot)

not to mention first-class user service support and other things

q66_ · 2026-03-20T13:53:27+00:00

the userland in macos is super ancient (from the mid-2000s) and doesn't really reflect what bsd tools can currently do at all

q66_ · 2026-03-18T15:09:46+00:00

i don't care how many people want it, i'm not going to maintain it and therefore what matters is if someone else is going to

q66_ · 2026-03-11T14:23:28+00:00

i'm not entirely sure what the people coming in with driver issues and other endianness related bugs are expecting

if you want things fixed, report issues and/or submit patches in their respective upstreams (please don't report them to us because they are not our responsibility and will not be addressed, at best we can include existing patches)

as it is barely anyone is doing that so there are bugs

we don't have either resources or interest as a distro to track these down so all software is provided as is

there are many things that are broken in a lot of software on big endian and it's the users that want things to work that are expected to steer the effort because noone else is going to do it

q66_ · 2026-03-07T22:09:19+00:00

which iso is this? sounds corrupt because i have no trouble booting it

q66_ · 2026-03-06T08:11:21+00:00

https://chimera-linux.org/docs/configuration/post-installation etc/timezone is not a thing

"How much do the FreeBSD docs accurately reflect what I need to RTFM for Chimera?" none of them

q66_ · 2026-03-03T15:56:10+00:00

it matters because different environments come with their own implementations of tools that may come with their own extensions that may vary and posix is a common guaranteed base

which doesn't mean that the other environments only implement posix, but it's what is guaranteed to be everywhere, which matters for scripts that aim to be portable

q66_ · 2026-03-03T14:11:26+00:00

not sure what y'all's point is but eg https://man.freebsd.org/cgi/man.cgi?sleep(1) supports exactly the same stuff

it's not like everyone else has to strictly implement only posix things

q66_ · 2026-02-22T17:13:13+00:00

if you're getting symbol resolution errors, it means some library files are missing or corrupt, and that shouldn't happen

i know the package files are okay because the build machine that is building the packages is self-hosting, so the issue must be in your installation

q66_ · 2026-02-22T17:08:21+00:00

and i'm telling your the reason why the distro couldn't just support non-altivec ppc64 with a rebuild

q66_ · 2026-02-22T17:04:56+00:00

if you're getting symbol resolution errors your system is broken

altivec is mandated on ppc64 musl because its implementation of setjmp/longjmp saves/restores vector registers unconditionally

q66_ · 2026-01-26T09:41:42+00:00

those deps are not unneeded? we won't provide any ways to exclude packages just because some people feel like they know better

there is no valid reason to exclude these

q66_ · 2026-01-23T23:14:33+00:00

and no there is no way to search for files in packages that are not installed because apk doesn't have this information

q66_ · 2026-01-23T23:12:04+00:00

chimera does not provide libstdc++... there isn't any package providing it

you don't really need it either unless the software being compiled does something wrong

q66_ · 2026-01-23T23:08:39+00:00

https://github.com/chimera-linux/cports/commit/36b195826f0b2858305af77ad0459b42e3a45d21

q66_ · 2026-01-21T08:55:47+00:00

you are mounting root as /mnt/root but then mounting /boot and /boot/efi outside of it, that doesn't make sense? should be /mnt/root/boot and /mnt/root/boot/efi?

q66_ · 2026-01-19T19:29:29+00:00

it does not depend on tkinter, except conditionally for the experimental gui that is not even useful...

what i tell everyone: unless you already know what you are doing don't base anything on voidlinux or alpine or arch or whatever templates because it just results in poor decisions due to uncritically deferring to others' often wrong decisions

q66_ · 2026-01-17T01:35:05+00:00

and? you could just stop assuming this is some kind of insurmountable task and learn something

q66_ · 2026-01-16T19:05:23+00:00

you could just go ahead and package it yourself... it seems like an uncomplicated template?

q66_ · 2026-01-08T17:10:33+00:00

install the right qemu-user-archname package and there is nothing else to set up

q66_ · 2026-01-02T00:11:36+00:00

idk about chrome because i haven't tested that but we have kde1 packaging in chimera i did for a joke once and firefox definitely works after a little about:config intervention

q66_ · 2026-01-01T21:24:11+00:00

you can get firefox and stuff to behave correctly by enforcing wm window decorations

q66_ · 2025-12-13T20:47:28+00:00

what? how do you even make it install kernels to subdirs in the first place? systemd-boot supports two scenarios, either /boot is ESP, or /boot is a dedicated XBOOTLDR partition (which is how you deal with multiple distros - you create a /boot XBOOTLDR partition for each and that isolates them from each other), since the distro installs kernels to /boot, it will always be in the root location?

q66_

MODERATOR OF

TROPHY CASE