understood, so no big issue with grub, cool !

I’m wondering how both mkinitcpio alternatives work on non systemd boxes with full disk encryption. With both, I refer to dracut and booster. On its origins I believe dracut was pretty tight involved with systemd, and booster is developed/maintained by an arch developer/user if not mistaken, and arch supposes systemd, though none of those things actually mean non systemd boxes are not supported.

I’m also wondering if the initrds generated can be launched by grub (I do /boot partition encryption/decryption with grub), and I also do / full partition encryption with luks. This booster issue sort of indicates as of now booster initrd images can’t be loaded by grub…

I see, I didn’t dig into the cause, being sort of a buffer overflow. Indeed that would be prevented by other languages, sorry for my misinterpretation. Other vulnerabilities unintentionally introduced by developers on logging what shouldn’t are not dependent on anything other than auditing them, but that was not the case then.

True, the logging is part of the library, but it’s totally centered on what the developers are logging. It’s a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn’t mean the library is broken and has to be replaced. The library’s logs need to be audited, and this as true for glibc as it is for musl, no exception, and it’s not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).

BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that’s not a syntactic error, and it’s not violating any compiling rules. It’s that something is logged that shouldn’t.

Also, the report indicates that the vulnerability can’t be exploited remotely, which reduces the risk for several systems…

That’s why I said library or language (someone else suggested rust).

The vulnerability is on logs, and that has nothing related to the library. Even less with the language…

Using wayfire (disabling the fancy resources eating plugins) + waybar + plus a bunch wlr utilities (some from sway).

I’m using integrated intel gpus. There’s a laptop with both the integrated intel gpu and a nvidia discrete one, but I had to configure the bios to only use the inegrated one, both the binary nvidia drivers, and the open source nvidia drivers fail to set fbdev=1 (the external hdmi monitor is the one associated to the nvidia gpu, and it gets a blank screen), which is required for enabling KMS, which is required for wayland, so no luck. Nouveau actually works, but it’s not stable enough, after some time of use the monitor turn off and there’s no way to turn it back on, and it feels slow or lagging compared to the intel gpu, although it should be the opposite. So I gave up on nvidia on that laptop, and any other box only has the integrated intel gpu anyways. I’ve read of successful stories with nvidia, both with the binary and the open drivers, but I think it’s not a generic thing that all nvidia gpus will work well on wayland with nvidia drivers. The noveau drivers are the only ones working for some gpus, but not stable enough. So I stick with the recommendation to stay away from nvidia if using wayland…

I guess although WM still applies, on the wayland jargon they’re called compositors, and the wayland compositors are not as light as the Xorg WMs, since there’s no Xorg server, and part of the responsibility of the server goes to the compositors on wayland…

There’s labwc, which is the compositor I would have chosen, but the developer decided to stick with xml configuration equivalent to the the openbox one, and also with the openbox themes/styles, which I never liked. On Xorg I used fluxbox + tint2 + …, and I tried openbox, but totally disliked it compared to fluxbox… But other than config and theming, I like its idea of being a light compositor.

Actually by disabling the plugins I am on wayfire, it’s pretty much labwc but with new decent config (I really like its config BTW), and using the gui toolkit theming, so no specific wayfire theming at all, which is nice, as opposed to the labwc own theming… Still, labwc is also an option for some.

Wayfire and labwc are not tiling compositors as most of all others, :)

I’ll take a look at iosevka fonts, thanks !

It looks like, though OTB (opentype bitmap fonts) are different than plain bitmap fonts, and are actually supported by pango. Alacritty allows me to use Terminus OTB fonts for example. There are other true type fonts which are also sort of my plan B, which are not supported by kitty either, as mentioned, I wanted to see if there’s a way not just to select between the list kitty offers, which is sort of limited. At any rate if not Terminus, I don’t really like much my plan B true type fonts much…

For those kitty users, have anyone been able to use fonts not in the list kitty support? I only use Terminus (OTB) fonts on terminal, and when trying kitty out, I found no way to get it to use Terminus (I could only select between those supported by kitty).

Alacritty (with screen if I need a multiplexor)

Thanks !

which one is it? The replies were erased, :(

Jami with unifiedPush notifications is a pretty good option

Wofi is still working fine with wayfire. It’s actually still offered on Arch as part of the “extra” repository:

% pacman -Ss wofi
extra/wofi 1.3-2 [installed]
    launcher for wlroots-based wayland compositors

To be honest, I found it more straight forward than rofi, but I could still use rofi if it worked well on wayland. I’ve never used tofi, and it doesn’t seem like a drop-in replacement for wofi. But I guess it’s worth trying. It’s seems less graphical than wofi though…

These two posts are really enlightening:

How I Built My New Linux Gaming Desktop In 2021 With Amd Cpugpu And Gnu Guix

I Love Arch But Gnu Guix Is My New Distro

From the last, there is a non guix project including packages for guix, which are not officially supported given hey are not free software. I recommend taking a look at the last post at least, since it comes from someone who used Arch, and made the move to Guix, not just opinions from people like me, who haven’t ever used Guix.

That said, Guix is in my TODO list. The thing is that I want to learn a bit more than minimal Guile, so I can write packages myself (there are always missing packages, even on Arch/Artix + AUR, I always have the need to whether tweak something at some point, or create a package still not in there), and also deal with my own services to run with shepherd. So I don’t want to blindly try things out…

It shares with Nix the reproducible build of everything, but the language it uses is Guile, which has some history. Nix has its own language. To me that’s a plus on Guix. But the most important part, is that the official repos are all for free software, and then on the non guix project one can look for non free software pieces, which to me this is also a plus. I guest most might differ.

But again, if you want to try it, even if it’s just because of curiosity, why not doing it so? I hope those prior posts from someone who migrated there might be helpful.

Why not looking for distributed mechanism, which don’t depend on trusting central servers or particular instances on decentralized mechanisms, like jami, or similar?

Ohh, Isee, thanks !

No, I don’t install gapps. I see, and yes, I can confirm I can disable it, :)

Thanks ! I have installed LOS 20 on other phones, and none has this thing. I’ll disable notifications on it as well. Unfortunately it can’t be disabled. Not sure why LOS ships it. Perhaps there’s no way to remove it for these phones, who knows…