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

Really cool looking project - looking forward to trying it out.

Unfortunely Aix and HP-UX servers were out of my control, thus scripts had to stay POSIX compatible for anything that had to run across all our servers, or written in Perl.

Get off my lawn! ;)

(1) crazy command options (it only takes one or two to ease your workflow over the what the system distro supplied, plus the same behavior for the same flags across platforms)

(2) the lawsuit (probably an understatement - it was Serious back then)

Edit: added "usage" for clarity, s/statment/statement

It's interesting to say that it's "just another UNIX flavour" when the most common flavours today all have some form of package management.

At least in nixpkgs it's easy to reference the right version explicitly for each context, but everything else is a just guessing.

I got into the habit of immediately installing gtar on any Solaris box I had root on (damn the leading "/" in the archive).

-----

The 2nd worst part was dealing with SunOS and HP/UX at work and Ultrix outside of work. Worst part was not grokking why MS-DOS wouldn't buffer keystrokes the few times I was exposed to it.

[0]: https://chimera-linux.org/docs/faq#what-is-the-projects-take...

I have spent lots of time with Linux servers. I’m also very pragmatic. systemd has made lots of stuff easier, is highly configurable, maintained and regularly updated, and properly standardised. I acknowledge people who have a need to feel in control or something, but I just want reliable computers that have a single way of doing stuff. They’re cattle, after all.

So I’d really love something with an immutable system image, signed boot, and systemd services top to bottom, along the lines of the thought experiments in Poetterings blog. Is that a thing?

It does have the "downside" of not just being plug-and-play but rather BYO system.

[0]: https://nixos.org/manual/nixos/stable/#preface /

  > CarbonOS is close, and GnomeOS too. 
  > and here, we build something generic to create images from Fedora/debian/suse/arch… distro packages:
  > https://github.com/systemd/particleos
  > There‘s a lot going on in the matrix channel of mkosi, I would recommend taking a look.

[1]: https://universal-blue.org/

Snap might not be a part of systemd, but it is in the same general category of ultra standardized system software.

I'm not sure why there's no real FOSS alternative to it, but there was an attempt at one point. I've always thought it would be cool to make a torrent-based P2P snap store.

Not an immutable distro though.

> systemd is written to deliberately (ab)use every single non-portable extension under the sun

I think this should be split into 2 parts. Linux specific kernel features and userspace extensions (GNU vs. POSIX).

Using linux specific kernel features (like cgroups) is good for a linux system. E.g. a common issue with sshd used to be that under high load it would become slow and problematic to log in. Systemd configures the system such that this becomes less likely to happen.

For userspace extensions I would have hoped that systemd would see it as a net positive to build upon a smaller set of tools and features, but the page seems to indicate otherwise. Does anyone know what happened on that front?

OCI container support is one of the things that keeps me so firmly planted in the Linux ecosystem.

Outside the kernel, calling into non-portable extensions should only be done with good reason. One of my favourite things about Chimera is its rejection of most of the GNU specific ecosystem.

Actually, I do not like GNU specific stuff in the kernel either. It should be possible to compile the kernel with multiple compilers.

Ironically, with the addition of Rust in the kernel, most distributions will have to use both LLVM and GCC to create a kernel whereas Chimera can use LLVM for both. Hopefully by the time important Rust code starts to ship in Linux, GCC will have a proper Rust front-end.

I am all for one “most popular” Linux distro that new users can be directed to and that commercial interests can support. Linux ubiquity is being held back by “fragmentation” in that way. That said, I want the ability for myself to choose other ways of doing things ( knowing the convenience I am giving up to do so ). I want focussed projects to be able to innovate. Even if we have a “most popular” option, I do not want a mono-culture.

You can have an all systemd system. It can be the norm. Please do not take away my ability to do something else. At least, do not do it without a good reason.

If Chimera is able to become as popular as Void is now, I would be happy. It would be amazing if it could be the next Arch. I am not sure what q66 wants for the distro but keeping the core distribution pure and having some successful derivatives would be cool ( if they kept to much the same vision ). But I guess I should let the project get out of Alpha first. :)

Personally I never liked systemd because I just didn't see the need for it and I don't like changes forced on me. I'm not a team player and I hate being told to 'just go with the flow'. The whole idea of FOSS for me is to be in control of my computer. Alnd I just don't like the character of Poettering and yes that matters. For a much more extreme example look at ReiserFS. It was totally shitcanned after it turned out its creator was an actual murderer.

Of course Poettering is nothing close to that and his biggest fault is being a little socially abrasive and opinionated. I'm just more sensitive to this than others. But I just really hate optionated software.

This probably makes me a "systemd hater" that the article speaks off. I understand as my concerns are indeed a bit petty. But they're mine anyhow.

In the end I moved to BSD. I'm very happy with it now. They don't have the push to constantly changing stuff around for the sake of things like systemd and net-tools.

Poettering might have opinions on what Linux should be that don’t overlap with yours, but systemd solves actual problems and works better than any init script shenanigans that came before. If you don’t agree with this premise, I call your proficiency with Linux into question (don’t take this in spite, please, it’s in no way meant personally).

Nor commercial involvement (e.g. RedHat/IBM or Ubuntu) for that matter. This is why I'm better off with BSD anyway because there's so much less commercial involvement.

And Linus yes he can be abrasive but usually I would agree with him more.

> I call your proficiency with Linux into question (don’t take this in spite, please, it’s in no way meant personally).

Well I'm certainly not very good with Linux anymore since I've used it less and less recently, gravitating more towards the BSDs. So that's not a bad point, I know how to start and stop systemd services and a bit on how to get logging back etc. But the point is, I never really wanted to learn something new. I've used FreeBSD since version 6 and it's hardly changed at all. And it works totally fine for me. But "being good with Linux" is not a goal for me anyway. I don't currently need it for my career anyway.

In the mean time I've been on Macs, but I really really abhor the way that Apple is constantly changing things around on me too (they are far worse at this than Linux) and they are consumerising the OS rapidly. So when I went back to FOSS I decided to go for BSD for this reason.

For myself, I am more bothered by RMS. Although I know Chimera has shunned GNU for technical reasons, I would personally prefer a world where all GNU software has been replaced by alternatives. In my view, we would be better off to be free of RMS and the politics he has created around around “GNU / Linux”. The GPL itself is an important option in Open Source and, while it is not my favourite, I wish it and the projects that adopt it much success. However, the GNU Project itself is becoming an impediment ( my views only of course ). Luckily, the GNU project represents quite a small list of software projects despite the way people talk about it. Replacing GCC, Glibc, and Coreutils would be enough. Of these, the most damaging and the hardest to replace is probably Glibc.

Anyway, my intent is not to trigger people with such opinions in this thread. I do not want them to reflect badly on Chimera. My only reason for chiming in is to illustrate that Poettering is not unique in collecting detractors.

Finally, systemd did solve real problems at the time. There are other solutions now though so let’s not render them inoperable. Also, not everything systemd wants to be now is better than the alternatives or even what came before. Not liking systemd does not mean wanting to go back to init scripts.

Btw, the system I use most daily uses systemd. I also use it in a project at work although, there, we have a strange bug “rarely” at shutdown that systemd is implicated in and I wish it ( and is ecosystem ) were easier to understand. So again, I find the Chimera approach attractive.

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

I do not really mean to criticize anybody myself. My venting is more about GNU advocates criticizing others, campaigning against collaboration, or trying to lay claim to vast swaths of software they did not write. Although I am very pro-Open Source, it also bothers me when too much abuse is heaped on commercial vendors that do contribute lots of code ( even code I don’t love ). At least, I prefer the complaining stayed technical.

Thank you again for your contributions. I hope I continue to enjoy your choices. Good luck either way.

I assume you forgot a word here and intended to write "changing stuff around for the sake of changing things"?

I just want to set the record straight: systemd solves the startup-dependency problem. Yes the old default init scripts worked fine for your system (that probably had very few services installed other than vanilla defaults), but it was insufficient for handling the exploding cascade of dependencies when service1 depends on the network, service2 depends on the graphical subsystem, service3 (the wifi daemon) can restart the network, etc. People tried in vain, hacked nasty rc.init scripts for years, until Poettering took matters into his own hands.

I will stop there because I dont know the whole history behind it, but I just take issue with the attitude that systemd in particular is just kids messing around with the latest-new-thing. Some of that does exist in the Linux sphere, even worse, with some maintainers putting inappropriate images and political messages in their apps[1]. But systemd - as with wayland - solves a problem that had been brewing a long time.I suppose you could almost think of it as a fix for developers instead of end users? I'm not compelling you to use it, just disputing your final point.

[1]. https://www.reddit.com/r/browsers/comments/18izmt4/clarifyin...

And that's perfectly fine. My problem with systemd is that it didn't stop there; it became this giant monolithic thing that Linux hangs off the edge of. That's Poettering's sin.

PS: I don't like Wayland either for that matter :) At all. My ideal would be an X12 with the X-Windows foundations but modified for modern realities.

- slower than glibc, and in occasionally difficult to predict spots;

- causes just a bit too much trouble porting software to it -- most upstreams are reluctant to accept patches, resulting in maintenance overhead for the distribution;

- occasionally subtly breaks things at runtime -- e.g. both alpine and chimera builds of firefox have the same two crashes which neither the official mozilla nor archlinux builds exhibit.

in the end i find i have to rely on my glibc chroot (e.g. for mozilla firefox build) too much for my liking.

Note that sometimes (/often) this purely due to the allocator, and as far as I remember Chimera uses a different allocator than the stock musl one.

What’s actually amazing about chimera is the musl + clang/llvm/compiler-rt combination. It allows you to do all kinds of amazing things easily from a programming perspective.

The apk 3 package manager, build system (cbuild) is also excellent. Everything feels modern and clean. Package availability is still limited and you would probably need to compile many of your favourite packages from source but I would still highly recommend this distribution.

Any examples?

As such, I have stuck with GCC which requires much less space.

Is this any different on Chimera.

I have 2TB of internal SSD storage on my laptop, and I can buy extra TB's for $50 each.

Why on earth would I balk at 100MB?

Some webpages serve half of that in optimized images for crying out loud, lol.

Yet I can't find many benchmarks.

Frustratingly, it's listed here, but not actually included in the results: https://github.com/daanx/mimalloc-bench Might be fun trying to run the benchmarks myself.

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)

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)

Similarly we should persist with musl. It’s infinitely cleaner, simpler and understandable.

I am in favor of standardizing the behavior of libc and having multiple implementations that are commonly used.

There are also many other POSIX ( UNIX-like ) operating systems such as FreeBSD and OpenBSD which have their own.

Redox has a Rust-based C library called Relibc that even works on Linux.

There are also other C libraries that work on Linux such as dietLibc and of course Bionic, which is the standard C library on Android.

The problem is not the lack of a standard, it is that Glibc does not follow the standard and is itself the de facto choice for desktop Linux. Applications that assume Glibc may not work on other implementations ( like MUSL ).

That's incorrect Glibc does follow the relevant standards, you can simply restrict yourself to only use POSIX and C11, it's just that program authors find the glibc-extensions convenient enough to use them over just the bare standard.

That said, some of the other libraries don't even claim to support the relevant standards, e.g. Bionic is not even fully POSIX compliant. So an application that assumes MUSL (which btw, also implements glibc, BSD and Linux extensions), can't use Bionic as a drop in replacement (not sure about Relibc).

To note that this is only became a thing when the Universal C Runtime was introduced in Windows 10, until then is was pretty much "Every C compiler provides their own", which was the common approach on non-UNIX systems.

There is already a standard you need to adhere to. It lives one level lower and is the Linux userland-kernel interface i.e the syscall interface.

My take on Chimera is that it is what a FreeBSD user would want if they were going to use Linux. They share the same compiler and userland. The build system rings a lot of bells.

At first, GNOME seems an odd choice but Chimera wants to avoid a lot of legacy and is pipewire and Wayland from the start.

I do understand that it may not be for everyone but my understanding is that when people say a desktop is not user focused, what they really mean is it isn't focused to people resistant to changes

That, or "it's not aligned perfectly with all my personal needs"

As an example, I feel like the usability of GNOME apps with client-side decorations is a lot poorer than the previous more traditional paradigms. The older paradigm may not be flawless, but it was much more consistent across applications, and most importantly, it's very easy to figure out. Trying to figure out how to do things in GNOME applications these days can be an exercise in frustration. I don't really want to play a game where I try to figure out what the trendy way to access the Settings dialog for a program is. Is it going to be somewhere in the global menu bar, or is it going to be on some nondescript button with dots or lines in it, or maybe something even MORE exciting? In the past, the worst thing was having to look through some defacto standard menus to find it. With modern applications, who knows.

Meanwhile, Mutter feels like it is resistant to practical concerns: they dug their heels on on server-side decorations, which did exactly what anyone could've told them it was going to do; now a bunch of applications have no or horribly broken borders on GNOME. I mean look, I know "it's really the application's fault because we said they had to deal with this" but also, I hope everyone understands that it genuinely doesn't matter, the outcome was predetermined based on the input.

On that front, I have a laundry list of complaints over how the direction Wayland has taken in GNOME in general, especially pushing things to clunky and unusable DBus interfaces that don't cover all of the important and already-common desktop use cases well enough. While I understand some of the reasoning, it is extremely difficult to argue that this isn't a focus on developer ideals over what would be ideal for users. Arguing that it's not "waylandy" to have input emulation in the Wayland protocol thus forcing you to use another binary protocol that's similar to Wayland but that you need to negotiate over DBus using desktop portals seems like a step very far in a weird direction when you are literally already speaking to the same compositor that's responsible for _dispatching_ input events.

Old man yells at cloud, but yeah GNOME definitely is "my way or the highway" in every regard, absolutely not a bastion of user-centric design or architecture. And that can be good if that's what you want, but I have a feeling it would be easily displaced by something that had a better attitude toward user concerns and pain points.

Even if KDE is buggy, it's extremely hard to argue it's not more user-centric. I'm wholly unsurprised when I see something like XWaylandVideoBridge coming out of KDE, as it's born out of trying to make things work for users rather than drawing a hardline.

That said, I do personally think GNOME and GTK4 are far better on phones and tablets than desktops. It's funny, because I simply would not consider them good options for desktop applications, but it all makes a lot more sense when you try it with a touchscreen. (That said, I don't view this as much of a saving grace because I've come to the conclusion that convergence is mostly a lie, something that you think is a good idea but in reality it's not; you just get something that's mostly bad on desktop, mostly bad on phone/tablet, or just generally not good on anything. GNOME is closer, IMO, to "mostly bad on desktop.")

Even if Gnome/GTK-4 supported server side decorations the problem of the heterogeneous app ecosystem would not be solved and you can observe the same regardless of the DE or even OS.

As a user the only major complaint I would have about Gnome is the regular breakage of extensions. On most distros it isn't an issue but it makes it rather unsuited to rolling release distros unless user is willing to regularly play with his package management config to prevent updates. On my Fedora machines it is not a big deal as the gnome major version is only upgraded on major Fedora version so I usually test with a VM before hand and if there is an extensions I really want to have I'll fix it o just wait a few weeks or months for the extension to be updated (or a fork being made).

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

Is this an experimental or hobby distro or does it intend to be something grandma can use?

If I had to choose this or BSD, it looks like I'd very strongly considering this or something like it, but it definitely doesn't seem like an Ubuntu or Windows replacement. Simplicity is just not a factor end users consider.

As a dev who likes modern software and isn't really into lightweight hacker friendly stuff... the odds of me using anything that's not at least 1% or total desktop market share is pretty low. Anyone who's not an Arch/Kali/BSD/suckless enthusiast type has a finely tuned sense of "Oh no, that makes me feel the same way that thinking about a project car does, I'm outta here".

It could drill be a wonderful worthwhile project... but it's going to be an uphill battle to interest anyone but tinkerers and I always kind of worry about people, because this stuff takes a lot of time and without managed expectations it can really be a disappointment when it doesn't take off. I've tried several times to start new projects and it's been pretty hard realizing they're unlikely to go anywhere anytime soon.

I think getting any mainstream adoption would require changing the entire software ecosystem in general. I would imagine there would be some kind of issues trying to port current mega apps like Steam or Chrome to this.

Plus, dynamic linking seems like it's not that well suited to user friendly distros meant for end users.

Unless you have snap or Flatpak or something like that, I don't see how you can have cutting edge large complex third party packages without at least occasional compatibility issues.

My experience with dynamic distros generally hasn't been terrible, but it always seems like there's some issue or other.

Does this have any kind of AppArmor type sandboxing?

It's an experimental hobby distro. If you want something grandma can use, you want to use use something everyone uses.

Chimera is fairly niche and goes against all standards. You're always going to run into Chimera specific issues. Chimera also has a nice transparant build system that one can tinker with.

As for Manjaro, I don't think it's hard to make a distro based on Arch that just works. Manjaro developers just suck.

This. They cant even be trusted to renew their certificate 4 times in a row. The level of incompetency reaches new highs.

I also think it's fine for projects to target a specific more hobby-esque audience. Not every project has to be for everyone.

It took me a long time to learn not to expect too much, and my choice of projects has been very different since learning this.

Some projects seem like they're held back by trying to be kinda-mainstream-ish, rather than being fully able to try whatever they want.

excellent observation

I wish Linux distributions could advertise to existing Linux users without inadvertently causing this sort of confusion among the non-Linux tech media. Many Linux users don't want the OS to take off, because things will get materially worse in many regards if it gets popular. You often only find the new users and tech media theorizing about the 'year of the Linux desktop', or about Linux's product weaknesses in the narrow lens of comparing it to Windows.

Fedora is able to balance this public image issue fairly well. In their landing page, they emphasize that it is for "developers and makers of all kinds". But because Fedora Workstation actually is fairly close to being an easy-for-all-users distro, in their "Is Fedora For Me" page, they have this paragraph that essentially explains that it might also be for non-developers as long as they are curious/enthusiastic about computers in general:

> The Fedora distribution is made for enthusiastic and curious computer users that like to learn and experience newer versions of software and therefore might not suit everyone. Although the Project works hard to make Fedora as usable as possible for the widest possible audience there are inherent limitations on how fast a new software can be translated, gain accessibility features, provide the most comprehensive documentation and guidance. If you on the other hand need a stable Linux distribution that supports even the latest hardware, are willing to put some effort to help the free and open source software (FOSS) community and file some bug reports this might be a perfect system for you!

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

You are spot on about this project I think in your analysis and I think it simply isn't ever going to be something everybody will want to use. That's okay, like you said, some don't want to participate in operating system development, you are mostly looking to be a user. There are plenty of free and open source operating systems that will mostly provide that kind of experience for you. The intent with something like Chimera is probably to dogfood these sorts of improvements so that other more user friendly distributions can use it as an upstream source in the future. So maybe one day we will see a more user friendly version of this.

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

I tend to focus a lot on having a clear purpose, just because I meet so many devs that don't quite understand how an non-tinkerer types see computing, and why the rest of us like Android, Web, Ubuntu, and Snap so much.

I have a hard time imagining someone making even a super polished derivative end users would want, but that's perfectly fine if the audience is hobbyists with a deep interest in OS stuff, and I wouldn't be surprised if the actual mainstream distros adopt some of the ideas if you discover something relevant to everyday use.

Not sure if Arch should be grouped with those. On the Steam statistics it's more popular than ubuntu, and that's not counting SteamOS.

In that sense, both of them are products, not projects, to the vast majority of users, and that influences what the core teams choose to focus on.

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

If you do embedded, those systems often run Linux, and it appeals to anyone who likes the idea of one standard platform for everything, so you might as well use it on the desktop. Especially with RasPi work, which is similar enough to Ubuntu that it really does seem more or less unified.

It's also free, and can run on old computers.

It doesn't have any commerical incentives to leave out features, so a large linux distro can support every protocol, file format, and filesystem with no hacking and fussing and buying expensive compatibility apps.

It supports lots of old windows stuff via WINE.

The goal is to run as much as possible native in Chimera but sometimes I am just trying to get something else done.

Chimera does not include distrobox in the repos but it does include podman so that gets you most of the way there. Anyway, it works great. I am posting this from Chimera right now.

Some people prefer Flatpak but I prefer old school package management. Flatpak just feels so heavy and opaque to me ( but I know opinions differ ). Distrobox certainly works better for console stuff.

Distrobox is just a handy tool as well and super convenient for spinning up quick sandboxes and temporary dev environments.

Arch is just a personal choice as well. I could have picked Void or Debian or anything else.

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

https://web.archive.org/web/20230811081600/https://voidlinux... https://voidlinux.org

> That’s why one of the goals in Chimera is to implement the actual useful systemd functionality, but independently and in our own way, without the shortcomings.

I question whether it would be possible for SystemD to be portable to other software stacks? Seems like it would be useful enough to attempt that port rather than literally rewrite SystemD, and you get to satisfy _both_ the SystemD stans and the haters at the same time! But who knows, it might lead to some kind of future innovation to have competing products doing the same thing...

https://github.com/ChimeraOS/chimeraos/issues/593

I guess the Chimera OS maintainer was polite about it, and Chimera Linux was pretty under the radar for a while.

The confusion is indeed unfortunate.

Anyway, I like the vision here, and am glad to see someone tackling things from this perspective.

I feel like they made a lot of good decisions in being simple enough without too simple, and backwards compatible enough without too much legacy... but imho wayland doesn't fit in that same space for me (at least not yet.)

nvidia?

> breaking compatibility with them seems like a hassle

They don't seem to be afraid of breaking compatibility -- witness deb/rpm, coreutils, glibc, etc...

I think I'll keep an eye on this

Now, of course, with service management the devil is in the details, so before you use something as system-wide init, I find it useful to ask yourself: How do they restart services? Do they give up at some point? How do they notify administrators of failures? Do they detect crashloops? How configurable is the logger? What CLIs are there to debug the state of the system (which service was first to fail, where is its definition)? How to make ephemeral or parametrised services? How to add pre-start, post-start, pre-stop, post-stop hooks? Can you use environment variables in your commands, and where do they come from?

I don't think you can find answers to some of these questions in docs. Once you do learn the answers, they may be disappointing - I indeed found myself quite disappointed in systemd after having to debug many failed-to-boot machines. With s6, I never run it, but there are few choices that raise eyebrows, e.g. the restart delay is hardcoded in source code to be 1 second. With dinit, I have yet to finish reading all its manpages, but at least timeout and restart policies are configurable.

This seems disingenuous at best.

Many distros already supply this feature. Debian is the most notable but there are many others. Install it, make any tweaks you want from the base install, sit on it for many years unchanged.

Considering the next paragraph goes on to describe OpenBSD userland, LLVM compiler, and musl libc, it appears the aim is actually to build a Linux distribution without GNU.

I usually steer away from projects which are defined by what they are not. It seems to build a community whose roots are based in hostility.

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)

> We are also putting a lot of effort into writing fresh low-level plumbing. For example, Chimera comes with first-class and built-in support for user services and other things dependent on session tracking (such as a shared session bus), implemented from scratch thanks to our Turnstile project, finally bringing functionality previously only available on distributions using systemd. This is being implemented in a vendor-independent manner so that other distributions can adopt it.

I hope this means they also get rid of nonsense like pulseaudio and logind.

I’m a bit skeptical of the “shared session bus” though. Linux supports inode watches for things that want to react to configuration changes, and session busses add a ton of complexity (including a second authorization language, and a userland SPOF)

And they have a custom alternative to login AIUI.

For now they seem to be using a different alternative to do at least some of it. I think it was called elogind?

At the top of the first page, under the Chimera Linux logo: "A modern, general-purpose non-GNU Linux distribution"

>This means Chimera is not a GNU/Linux system, as it utilizes neither GNU utilities, nor GNU libc, nor GNU toolchain. However, *the project is not anti-GNU/GPL*, and its userland choice is primarily technical. Users are generally free to use whichever software they like.

https://chimera-linux.org/about/#alternative-userland

This quote from the faq literally made me laugh out loud:

>Another side of the coin is the so-called “systemd-free community”, which tends to spread a lot of misconceptions and frankly deranged opinions that end up hurting any sort of positive effort. Chimera as a project denounces such people, and is explicitly not a part of this community. Such people should also not view Chimera as some sort of haven, because it is not. The project is explicitly anti-elitist and aims to find constructive solutions.

https://chimera-linux.org/docs/faq

Anyway, I wonder if they should be emphasizing security more on their homepage.

>Being a single lightweight package, it makes hardening the userland a lot easier too. It is possible to compile the Chimera userland with CFI and other techniques very easily, and it applies to all of the tools. With GNU tools trying to using these tends to fail, and addressing the issues becomes harder because it is out of our control and involves a much chunkier codebase where more can go wrong and where things are harder to track down.

https://chimera-linux.org/docs/faq

I would like to see more security-focused operating systems. And simplicity is obviously quite valuable for security. Perhaps they could find a nice niche as an accessible, UX and desktop-focused competitor to OpenBSD? Qubes is nice for desktop security, but it requires a powerful machine, and also maybe I could run Chimera in a qube some day for defense-in-depth :-)

One advantage of a desktop focus is someday you could make money selling laptops with preinstalls. I'll bet a lot of people would buy a cheap security-focused laptop to manage critical accounts, infrastructure, private keys even. Especially big companies that care about security. Then roll your profits into creating a great bug bounty program for your OS, in a virtuous cycle.

This is a somewhat ironic indictment of a project opting to avoid GNU. In fact, your quote could serve as a valid argument to avoid GNU. I cannot think of a project more completely defined by what it is not. I would certainly find it difficult to argue that GNU and its founder have not been a source of discord and hostility. The Open Source movement is a direct response to the hostile politics of GNU and Free Software.

In the case of Chimera Linux though, the founder has been pretty clear that they made their choices for engineering reasons and not political ones. There are lots of GNU packages in Chimera if you want them.

"What is GNU? GNU is an operating system that is free software—that is, it respects users' freedom."

https://www.gnu.org

Although GNU stands for "GNU is NOT Unix" that doesn't count as its a boomer hacker meme that started before GNU.

We mostly think that a variety of terrible technical decisions have been made and allowed to metastisize over the years, and that they are largely unfixable so long as Linux remains an operating system devoted primarily to ease of use, popularity, and packaged for non-professionals. A lot of this happened rather early on due to the influx of hobbyist programmers from the PC space, and so I think the GNU userland was mostly doomed from the beginning due to the qualifications (or lack thereof) of its programmers when important foundational design choices were made (they are better programmers and more professionally qualified these days, but they aren't about to roll back most of these foundational mistakes because it would collapse the whole thing like a tower of Jenga blocks).

Those goals actually align a lot with the GNU philosophies and so I support the Linux community fully in that way and for making free software available to as many as possible. But technically speaking, GNU userland is a pile of dog shit, and you've really got to rip it out and start from scratch like Chimera is doing as a bare minimum to actually make any kind of progress there.

Also if I look at many of the "professional" unixes userland tools I'd choose GNU userland any day, because the userland tools are incredibly handicapped, e.g. name one Solaris (or even better hp ux) core userland tool that is better than it's GNU equivalent.

That doesn't refute my statement that BSD pioneered containers with jails, as jails were widely used across multiple BSD versions (though they're oddly missing on macOS) before Linux's container architecture existed.

I had thought IBM did VMs rather than OS-level virtualization (wasn't Gene Amdahl the one who came up with the rules for classically virtualizable architectures?) but I'm not particularly familiar with IBM systems (though I have looked at the 360 instruction set, which has amazingly lasted for more than 50 years.)

Sadly the way things went, it isn't that much relevant nowadays.

XML definitions for service startup and inconsistent switches. Launchd is worse than systemd in those regards. I was quite happy to let go of my work iMac and do development on Linux.

YMMV - as I mentioned, I think launchd, systemd, and windows service manager are in a similar space; it could be I just encountered launchd first, so I'm more comfortable with it. Also the transition to systemd on Linux (e.g. rc files to upstart to systemd) felt more jarring than the macOS launchd transition.

On the GNU userland, something I hate it's the lack of integration. Emacs' calc shoudln't be calling Gnuplot, but GNU plotutils, at these should be enhanced to create 3D plots. Also, GNU Texinfo shoudln't be calling a full Texlive install to render math and PS/PDF files, but GNU Groff and geqn/gpic...

OFC

However these programs have cousins in stuff like BSD or Busybox, which implement similar functionality, but have a mostly, or completely separate codebase, and some differences in what they can do and how you make them do it, with a common user-facing one being differences in the command line flags available, and precisely how they behave.

In this case, Chimera uses a mix of stuff from FreeBSD and elsewhere, and also uses an alternative toolchain for compiling C, called musl, which is not glibc (glibc being a GNU project).

Since Linux distributions that use GNU are almost the universal rule, distros like this describe themsekves as "non-GNU".

https://chimera-linux.org/about/#alternative-userland

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

As for architectures, do you not run into many architecture specific problems?

I think Chimera Linux is definitely a project I want to keep an eye on.

It absolutely does not mean "no manual programming or customization from the user required". It means no dirty hacks, like the ones mainstream distros employ to make some of the customization and programming unnecessary that is actually kind of inherent to the way Unix has traditionally worked.

That may very well be much less easy to work with from a consumer perspective, but from a systems programmer perspective it's the opposite way. Those hacks that allow for the ease of use in a GNU userland make programming a massive pain in the ass where nothing "just works" the way it should, because GNU programs and libraries are in flagrant violation of every specification and rule of thumb that has ever really mattered for Unices.

Also, it's GNU libc that has gone out of its way to fail to adhere to standards, not musl. GNU does not give a single crap about open standards, because they believe that whatever GNU is IS the standard, which apparently is your view as well. That's simply unacceptable for a lot of people.

> Those hacks that allow for the ease of use in a GNU userland make programming a massive pain in the ass where nothing "just works" the way it should, because GNU programs and libraries are in flagrant violation of every specification and rule of thumb that has ever really mattered for Unices.

Just because the tools offer additional functionality does not mean they "violate every specification and rule of thumb that has ever really mattered for Unices" (what does that even mean?!). I mean you're welcome to edit files in ed, because that's pure Unix, but I'd rather use a more capable editor.

But vi/nvi it's useful because you can use commands to replace text inline, or pipe text parts to commands.

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)

To me, that is a bad thing and we agree that diversity should be possible.

We do not agree that “most Linux installs are going to be using Bionic”. Android uses the Linux kernel but it is not what people mean when they say “Linux”. The applications running on Android and the ones running on your Linux desktop are separate universes.

I too would like the standard C library to be an actual standard with multiple compliant and compatible implementations, and I'd like apps to work correctly across multiple implementations.

Speak for yourself.

In my mind, Linux is home routers, smart TVs, digital signage, tablets, smartphone, fridges, and yes, servers and workstations.

It requires some effort to migrate applications to musl, and there are functional differences from glibc. https://wiki.musl-libc.org/functional-differences-from-glibc...

"Standard" is one of those words that can mean different things. Insisting on one absolute definition and calling anyone who uses another definition "disingenuous" is not hugely constructive.

Nobody said anything about an absolute definition.

When describing the C standard library, the only reasonable interpretation of "nonstandard" is that it does not adhere to standard C. There are no counter-examples anyone has been able to provide from any corpus.

It's also ironic coming from someone who's opening salvo was to describe a post about musl being "non-standard" as constituting a "serious allegation".

No, it isn't. It's the GP's opinion.

Standard has a few different meanings, including something typically or commonly used. As in "GNU Libc has been the standard C library used by Linux distributions since 1991." That would be, you know, a statement of fact. Musl is, at best, a niche option used by a few distros.

Using musl is fine for limited uses, but it's magical thinking to believe that it's at exact feature and functional parity replacement for glibc.

If you want a monolithic, standardized, opinionated Unix, you may want to try macOS.