A new linux distro that doesnt use systemd and is actually reasonable about it? Interesting...
I think I'll keep an eye on this
Chimera Linux
201–210 of 224 posts
Re: Chimera Linux
#202Earlier quoted context omitted.
Gnome is one of my favorite DE as to me it is so easily usable and efficient with maximise use of the keyboard straight out of the box while still being very practical to use with a tactile screen. 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
I think in general, the GNOME foundation does a lot of good stuff overall, but I do not like the direction GNOME and Mutter have taken. Personally, I think that a lot of modern design is focused more on looking pleasing to UX/UI designers than it is focusing on genuine usability. As an example, I feel like the usability of GNOME apps with client-side decorations is a lot poorer than the previous more traditional para…
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
Re: Chimera Linux
#203Earlier quoted context omitted.
That strikes me as disingenuous. Can you show me even one example of another person using "nonstandard" in this way as applied to a C library ?
You are replying to someone who did, so there's your example. There's a bunch of other people in this thread as well – you really don't need to look very far. "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.
> 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.
Re: Chimera Linux
#204Even though I do not fully agree, I think this project has one of the most mature, nuanced, and balanced takes on systemd I have seen yet [0]. [0]: https://chimera-linux.org/docs/faq#what-is-the-projects-take...
A Bit OT, but is there something like the contrary to this - a distro actually fully embracing systemd components? 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…
You might want to take a look at NixOS[0]. It is fully built around systems for services etc. and while it does allow you to, e.g., use an alternate local DNS resolver instead of systemd-resolved, it still makes it easy to build a fully immutable distro with mostly systemd components.
It does have the "downside" of not just being plug-and-play but rather BYO system.
Re: Chimera Linux
#205I am not sure that the founder approves of this but my current favourite way to use Chimera on the desktop is to install an Arch Linux distrobox inside it. This allows me to enjoy the base Chimera system while also having instant access to the full Arch repo and AUR catalog. It is also a simple way to run any application which currently has issues with MUSL ( since things run on Glibc inside distrobox ). Since Distrobox passes Wayland through, even graphical apps work great.
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.
Re: Chimera Linux
#206Even though I do not fully agree, I think this project has one of the most mature, nuanced, and balanced takes on systemd I have seen yet [0]. [0]: https://chimera-linux.org/docs/faq#what-is-the-projects-take...
A Bit OT, but is there something like the contrary to this - a distro actually fully embracing systemd components? 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…
Actually, I went ahead and just asked him. This was his response (if you’re reading this for some reason, Lennart, thanks again):
> 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.Re: Chimera Linux
#207Earlier quoted context omitted.
I think in general, the GNOME foundation does a lot of good stuff overall, but I do not like the direction GNOME and Mutter have taken. Personally, I think that a lot of modern design is focused more on looking pleasing to UX/UI designers than it is focusing on genuine usability. As an example, I feel like the usability of GNOME apps with client-side decorations is a lot poorer than the previous more traditional para…
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 application…
Full stop and without prejudice, libdecor is a bad idea. It requires linking to C code which is not normally necessary on Linux, and if you want to respect the GTK theme in GNOME, you need to link to GTK (even if indirectly: it still has to be in your process's address space) and have access to user settings. This is a whole lot of complexity that GUI libraries and container runtimes will need to deal with just for GNOME if they want something as ridiculous as native looking titlebars, especially considering a wide variety of applications that otherwise don't care about looking native would definitely like to have native titlebars. Another good example of a situation where it'd be nice is Wine, which can currently have native titlebars on X11 but not Wayland.
> 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)
Application developers and users don't care about Mutter's clean dependencies. It doesn't matter how the problem is solved, it just matters that it is solved. For all the application developers care, they can resolve the problem by having another process manage GTK shells around applications and not having Mutter actually do it.
As for not wanting GTK in Mutter, well, a lot of applications also don't want to have GTK in their process space, so it seems like this desire shouldn't be very surprising to GNOME developers.
What will happen here is that libdecor will be treated like a polyfill just for the snowflake case of GNOME and the damn-near rest of the world will figure out a way to do SSD. Exactly how doesn't matter, so as long as it's out of the application's own concerns. This is basically the only way that things can work, because if you wanted e.g. native titlebar regardless of whether you were on GNOME or KDE or something else entirely, you don't want to have every single flatpak/snap/whatever needing to pull in the entirety of GTK4 and Qt6 or whatever just to be able to try to have native titlebars. The only reason this works for GNOME is that GNOME is the only DE that does things that only work if they are the center of the universe, so you can have the GNOME case and the rest of the world case just fine. (I know the common argument here is "but what about Weston", but I am not aware of any desktop Linux system that boots into Weston, so it's really neither here nor there.)
Re: Chimera Linux
#208Earlier quoted context omitted.
Also why when on a macOS system I never felt the urge to install Homebrew or something similar, it is just another UNIX flavour.
isnt the macos system called NOT UNIX ? ^.^
Apple macOS is a UNIX™ and has been for decades, both in Arm and x86 implementations, and before that in PowerPC form.
Two Linux distros, both derived from CentOS Linux, have also held certification in the past.
Whether an OS is a UNIX™ or not is nothing to do with whether it is based on AT&T code and has not been since Novell bought AT&T Unix Labs and donated the trademark to the Open Group in 1993. For three decades, whether it's a Unix or not depends solely on whether it passes Unix compatibility testing.
Linux is a Unix and so is macOS.
Re: Chimera Linux
#209Earlier quoted context omitted.
Have they addressed any of the complaints about Snap auto-updating and not being able to use 3rd party repositories?
Auto refresh can be disabled globally or per-snap now, the server is still closed source. 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.
> the server is still closed source.
No it isn't. Canonical's snap store is closed source but Snap does not depend on it and the process of configuring snapd to fetch and install from your own store is fully documented and needs no proprietary or Canonical tech whatsoever.
Re: Chimera Linux
#210Interesting take on SystemD. I personally find it very helpful, but one of its major downsides as a project is that it is, to borrow a quote from Benno Rice, "aggressively Linux-specific". That said, it appears their own software choices prevent them from using it as summarized in the following quote: > That’s why one of the goals in Chimera is to implement the actual useful systemd functionality, but independently a…
Nobody is going to use SystemD on Mac or Windows so why does it matter if it is Linux specific?
Linux is not the only FOSS Unix, you know.