There’s an AUR open-tv package for Arch/Artix/…, and there’s even an AUR open-tv-bin version, but I prefer looking at the build recipes if available, and if not using Arch/Artix/… one can read through the PKGBUILD and see how it builds.

There are a bunch of non bloated alternatives with whether wayland compositors and also X11 window managers, and there’s also kde/plasma, xfce and mate if still wanting full DE, plus a hybrid lxde-gtk3/lxqt (lxqt supports both X11 and wayland I believe).

If going the non bloated ways, distributions can offer some modifications on the system configurations files, so that users can start with working software out of the box, and can even offer installation meta packages for a complete set of i3/sway packages to have an equivalent DE experience. What would be left to users is custom settings to get more appealing aesthetics depending on the user, if not i3/sway, then openbox/labwc, and so on. For a DE experience including into the meta package a toolbar like yambar (works on X11 and wayland), dunst/mako, udiskie, redshift/wlsunset and so on. The missing part on non bloated alternatives is easy of configuring through buttons and widgets, and even so lxqt made an easy of configure software component for openbox, and there might be something similar for labwc.

So non systemd distributions are far from dying because of gnome’s hostility.

And if I recall correctly, several gnome users (not its huge base of course) are moving away from gnome any ways unhappy with its plugin support, given gnome is known to leave plugins unsupported on its releases and not caring about them.

The AUR PKGBUILD shows a pretty simple recipe:

build() {
  arch-meson "${pkgname}-${pkgver//+/-}" build
  meson compile -C build
}

package() {
  meson install -C build --destdir "${pkgdir}"
  # permission fix
  chmod 755 "${pkgdir}/usr/bin/ascii-draw"
}

I’ve been seeing arch-meson often used, but haven’t explored what it does. Some day…

Though it’s way more fun to use text specification, like the one referenced by @fratermus@lemmy.sdf.org

My only experience with it was with harmony-music built/installed from AUR on artix, and I couldn’t keep using it, it was consuming too munch CPU, making the fans run nuts. Not sure if it was harmony-music itself, or flutter. Apparently not the same OP experience.

maybe, he mentioned stacked mode on a tiling compositor, which is valid, but that’s not a thing on stacking compositors… BTW, the stack mode on sway doesn’t mean it turns into a stacking compositor, rather it means tabbed mode with the tabs stacked vertically. But the OP knows better.

You might try tabbed mode instead of stacking mode. It’s great, as mentioned in some comment I made, I’m not a tiling guide, but the tabbed mode on sway is great. I would guess it’s available on hyprland since it borrows some concepts from sway. However if you find a lot of trouble on hyprland enabling it (I guess you shouldn’t) you might try sway. Beware you need exceptions because otherwise everything shows up maximized, but that’s not hard byt reading the man pages, compositor documentation, and looking around on the web. BTW, on sway this global config gives tabbed mode on all workspaces: workspace_layout tabbed and of course you can chenge it to stacking, or tiling whenever you want on any workspace…

I’m not a tiling guy, and the tabbed mode on sway seems to me like the best I’ve used. I believe it’s a much better experience than stacking compositors by a lot. Having a tab bar, and everything maximized to it (except what I consider is better off floating) is the best I’ve experienced. Stacking mode is the same just that is uses too much space by stacking the tabs, so I really don’t like stacking mode. So sway tabbed mode, in combination with a tiling concept of a workspace per particular objective (I use 10) and a simple bar (yamber) has no alternative on the stacking spectrum of compositors.

BTW, if going with a stacking compositor, I recommend labwc instead. I found a smoother and way more stable experience than wayfire (some functionality stops working often like sunset functionality, and usually way behind on wlroots support, not a take on wayfire devs, just that I find it more unstable than labwc).

Of course I’m biased towards less eye candy, though I still appreciate the equivalent to basic picom/compton on the Xorg world, which is the norm on any wayland compositor AFAIK.

Of course using another distro you want to emulate is much better.

But as it’s debian based, I’m wondering if a better approach would be to use repos from another close enough distro, like derivative distros which decide to build the stuff for the distro as much as possible (that maybe won’t prevent the need of flatpak and the like).

Another approach would be using a package manager that can work on top of any distro, like Guix, at least for FLOSS software.

I use artix, so if something is not in the official artix repos pacman also look on arch repos, then it looks my personal repos (I build some personal packages, but I also use aurutils, so there are packages on one of my personal repos that are really aur packages not mine). As I prefer to package the stuff I can’t find anywhere I haven’t found the need for something like Guix, but it might come handful if in order to include some software which depends on software way old for artix or something similar to that. Just a reminder that Guix and the like will work fine as package mechanism on top of any distro given their approach to keep the software out of the common unix path hierarchy.

BTW, labwc is sort of the openbox for wayland, in case interested

If you’re not into tiling, but still want several of the advantages of sway, it offers a couple of additional modes, stacked and tabbed. I really loved tabbed setting some things to be floating. It’s like it sounds, it offers a horizontal tab with all windows within per workspace, maximized below the tabs… Stacked is similar but it stacks the tabs vertically. If you’d tell me before a tiling compositor has such functionality I wouldn’t have believed it. I like it better than stacking compositors, :)

just now? :)

I guess there was an attempt to move away from the email flow, to allow more people to contribute (I read that was part of the motivation), perhaps that made sourcehut (although it’s in their plan, it hadn’t become their highest priority) not an option, however both can be self hosted (that’s what I would have expected from an organization as the Guix one, so that there’s no dependency on a cloud service, as good as it might be), and both have really good TOS and are non profit. But cloud services are still something its users/clients do not really own. Perhaps as I understood, savannah will still be used as a mirror, but not just temporally, rather for good, so that if something happens on the cloud, there’s plan B available… That’s why for such big and important project I would have preferred a self hosted service. But oh well, I’m not part of the decision, and not an user yet, hopefully to become one later on when getting some minimal understanding of both guile and guix configuration (still guile but I believe simpler), because no matter the distro I always have to write and maintain a few packages myself. Hopefully at some point doesn’t become never having the time to do so, hehe.

So all in all yes, the two best cloud options by far, but I’m surprised a Guix instance was not chosen, not sure if even considered.

It would have been better to self host forgejo, rather than trusting a cloud git service using forgejo. But to be honest, its TOS, as well as the sourcehut’s TOS which I even like it better, sound way better than GH’s…

Also a devclass post Mozilla quietly makes Microsoft’s GitHub the authoritative home for Firefox code suggests FF is making the GH repo the place to go as the source of truth for FF, :( This move to me is really sad, instead of moving to FLOSS alternatives it’s preferring a proprietary with a terrible hosting licensing (gitlab one is much better for example, not sure about codeberg’s one, but for sure is better as well), and what’s worse, one that uses anything hosted in there for its own purposes, including feeding openAI stuff with FLOSS code violating any licenses and so forth. Which actually makes me strengthen the idea that mozilla is trending to go in the wrong direction making things worse on every step they follow.

I use a derivative, Librewolf, but in the end it depends on the FF code… Sadly, using GH is still like the norm, and I can change that. servo browser engine and verso (browser based on servo) are also hosted on GH. But at least they started there and migrating is always a hard decision, FF is just moving there having other options, so it means they don’t care about GH mistreating users code…

I’m curious about which programs if you can share. I write few bash scripts which used to call sudo, and I replace sudo with doas in those. And in case of muscular memory I also added a bash alias so that if by mistake calling sudo in reality I’d be calling doas. So far no issues. O course I don’t use fancy args, and what I really needed from sudo I used to include it in /etc/sudoers and now on /etc/doas.conf, and I believe I couldn’t include a couple of options but they were not critical since I’ve lived without them so far. And it’s weird to find actual software that requires sudo, perhaps proprietary software. One can actually live without sudo and without doas, as long as there’s still su.

Not judging, rather curious, actually I’ve met several guys who write scripts which would benefit from using sudo/doas, but they claim better call the scripts through sudo/doas rather than adding them as dependencies.

A way smaller alternative therefore less prompt to vulnerabilities is OpenDoas found on Arch/Artix/… and other distros. From the GH project:

doas is a minimal replacement for the venerable sudo. It was initially written by Ted Unangst of the OpenBSD project to provide 95% of the features of sudo with a fraction of the codebase.

Well, before wayland I always used fluxbox (eventually with picom compositor, which previously was compton). Then now on wayland I’m using sway with fuzzel, yambar and others.

I’ve always felt both gnome and kde, as well as most other DEs really bloated. Gnome used to be more stable on wayland, and as of Today with better support for nvidia AFAIK, but KDE is quickly catching up.

Not sure why the hate on gnome (and I guess on GTK as well). It doesn’t offer all the customization by default, but you can get it through extensions while available. But on KDE one really needs to see a pletora of dependencies each time one adds a simple module or application. Both are improving gradually to become less intense on resources being KDE more advanced on that.

But hey, both are bloated compared to non full DE compositors such as sway or labwc. BTW I use sway with tabbed mode (not actually tiling) and some tweaks, and I prefer that over stacking compositors, but if wanting one labwc is pretty cool.

On X11 there’s a huge amount of window managers plus compositors plus several other applications which altogether can give a similar sense to a DE but way less intense on resources, and for sure way less bloated. To me DEs are overrated to answer your title, but perhaps that’s just me, :)

I know most don’t care. I initially stated most people don’t agree with me. This is just my take on universal packages in general. I really like and appreciate the typical shared libraries native to most distros. It’s OK we disagree, I only hope we don’t end up with empty shells with systemd and everything else on app stores…

I’ve tried in the past flatpak packages, they are terrible in many senses the proponent (vast majority AFAIK) don’t say, among them:

• They create huge static binaries
• One gets many libraries embedded in the static libraries or local static libs to the package which are often repeated among many static binaries, even the same version of them. This is totally avoided when building against dynamic native libraries.
• When installing a pletora of static dependencies for a package, lets say liri, a bunch of the stuff it requires might already bi installed natively in your system, but they need the static deps locally part of the package.
• Care must be applied, there are statistics available about abuse on vulnerabilities infection on pypi, npm and so on, this no different on these packagers repos/hubs.

Good that they provide an alternative way to install packages not available in your distro repos, but for that user repositories building against native libraries are a much better option, like AUR in the case of Arch, and even their binary packages coming from other distros or from upstream might be even better than those universal static binaries providers.

There are political aspects involved in the past claim from the proponents, and it’s that in their view gnu+linux echo-system should become like the windows one, where everyone company or org (to them doesn’t matter) should be able to provide their binary packages, and then there’s no reason to think of anyone being able to build their staff.

There’s a tendency actually on providers on those hubs, to ignore problems on people who tries to build their stuff on their own, claiming they only support those universal packages. Which to me it’s dangerous, since it goes in detriment to the ability to build and distribute the software, which might not be due to licenses, but rather practical reasons. This might actually be against the licenses they use, but now a day who cares, right, it’s available on that packager repo…

Lastly one argument provided in favor of the apps coming from those universal packages is sandboxing. But there’s firejail which can be install on most gnu+linux distributions, and comes with profiles for a pletora of apps, and if sandboxing is not enough, it can easily be combined with apparmor, or if you prefer selinux might be used… No need for those universal packages to have a sandboxed experience.

One final note, so far gnu+linux has been characterized by having a diversity, which is good, that diversity offers people options to choose from, and a lot of different solutions for different purposes. Not so long ago the claim was that it was not good, that meant fragmentation, and fragmentation is bad for adoption and maintenance. I see it the other way around, this diversity allows for choosing for what aligns better with the user intends, like easy to use, or rolling release, or as vanila as possible, or as up to date as possible, or as hardened as possible, etc, etc. Systemd is another example of this universalization intended. Perhaps some distros prefer to be a shell for systemd and get packages just from universal packages, that’s bad news to me.

Of course having universal packagers present an oportunity for corps and orgs to also provide stuff on the gnu+linux platform, but in my mind the best would be for them to offer free/libre and open source software, that would build on any system and be provided by any packager that wants to offer it. Though I believe that to be too idealistic perhaps. Jeje.

Artix (current)

• Vanilla as much as possible (same as Arch)
• Rolling release (same as Arch)
• No systemd (my personal preference)
• AUR availability (still an Arch derivative)

Guix (as soon as I have the time)

• Similar reason as for Artix
• Reproducible builds
• Guile
• Static configs