Not true, FF comes with few binary blobs which are removed from Librewolf. Also there are some things disabled entirely at build time, so they are removed from being an option. So it's not just the settings, and it's not plain re-branding. Some distros has gotten it wrong, believing that it's just a matter of settings, but at least on the case of Librewolf and the Tor browser that's not the case.

That hey depend on FF continuous development to exist is true, that doesn't mean they just rebrand.

Mozilla being Mozilla, I'd guess. They should have gone sel-hosted with sourcehut, or at least gitlab. Or if not self-hosted, the choice should have been at the least gitlab or better, given it allows to chose DCO over CLA. But perhaps not everyone cares... I remember when gitlab introduced DCO, and how that helped debian and gnome to migrate to gitlab. After allowing DCO, other projects migrated as well.

I'm not that fan of gitlab, and I'd prefer sourcehut for open source projects, but if wanting something closer to github, then gitlab might be the answer. But Mozilla is a corp, maybe they don't care much about these things, and as a corp, perhaps they were looking for CLA sort of contribution any ways...

What I'm missing from wayland, it's not really something from wayland itself. Examples are several needed electron based applications, which some will refuse to properly work (for meetings, desktop sharing, etc), wine, gtk4 applications not respecting GDK_DPI_SCALE (not sure if already addressed) when not using gnome (wayfire being used as compositor), no proper support for conky (or eventually equivalent wayland functionality) yet, and several nuances with waybar, and some other tools. Major issue is my work dependency over some non floss electron binary blobs, like teams, slack, and so on, which particularly for desktop sharing and meetings don't yet work properly, no matter the electron options one can use for them, and some floss I use like signal, freetube, jitsi. Wine has a horrible hack, which I might live with, but it's horrible...

So I'll have to wait further for non wayland stuff to truly support wayland, and it has taken ages for that to happen, :(

I haven't tried labwc, andit sounds interesting, though I don't like openbox configs, and I really love fluxbox ways, which are also text files, but I never got used to openbox configs, perhaps just because I got way too familiar with fluxbox, which is what I use with Xorg (fluxbox + picom + tint2 + conky).

How about bcachefs. I'm waiting for it to support swapfiles, which seems to be in the TODO list, but so far doesn't work. If you use swap partition[s], or prefer not to have swap at all (I never fell for this, and besides swap is required for hibernation if that's a thing for you), then bcachefs is ready for you. It's already part of linux since 6.7, and on Artix, current linux is 6.8.9...

To me is the FS to use. I'm still on luks + ext4 (no LVM) and do entire home backups with plain rsync to an external device. I'd have to learn new stuff, since ext4 is really basic and easy to configure if in need, but I think bcachefs is worth it, and as mentioned, just waiting for it to support swapfiles, :)

Second one, which I'd rephrase as ubuntu sticking with apt/dpkg as its package manager. Which is really nice if you like ubuntu as a distro already.

Though I don't really get why there has to be a distro to be beaten. And having flavors is always good. I, for example, don't like distros changing too much upstream SW, so the more vanilla the better. I don't like either the periodic releases, and to be rolling release rocks. I don't like systemd, whereas most distros now a days are systemd dependent. I also dislike network manager and similar and require a distro that keeps support for the basic dhcpcd + wpa_supplicant... All that to say, that no distro fits all needs, so several options are good, no need to have one beating the rest, :)

Probably Guix, and GNU endorsed distributions. Binary blobs are not allowed on free/libre distributions, or not on their official repos. That said, most gnu + linux distributions don't care about those. Most will take care, if they get to realize it, about distribution licenses, so if something has some sort of legal issue to be distributed, that will get purged from its repos most probably...

Bloated and unnecessary if freeSW or openSW. That's what system shared libraries are for. If sandboxing is a thing, then firejail is availble, which can be combined with apparmor if looking for extra MAC security.

The main problem with systemd has never been the time it takes to boot, it's more on the lines of what @z3rOR0ne@lemmy.ml and @StrangeAstronomer@lemmy.ml mentioned.

Guix !

https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-23h2 https://www.bleepingcomputer.com/news/microsoft/microsoft-says-april-windows-updates-break-vpn-connections

Perhaps click bait, but based on MS' own list of issues with April's upgrade patchset.

Correct

Alacritty (with screen if I need a multiplexor)

Is it normal that on an upgrade, users are forced to re-login?

Source Mage GNU + Linux (external wiki)

How about not changing at all your regular packages,and containerizing what you want, or as much as possible through current profiles, through firejail? And couplet that with MAC protection offered by apparmor (one can actually set firejail to always use apparmor, and then tweak particular apps not to use it if it's too troublesome).

This way you have your provided distro packages (gentoo or sourcemage if source based distros, it doesn't matter), and have them execute containerized. The only thing is that there are not firejail profiles for every possible piece of SW, but the vanilla list of containers is not small either.

Are you looking to clean up your client inbox, or the server inbox?

If your client inbox, you don't need a plugin, on the account settings synchronization & storage, on the section disk space, select the synchronize the most recent and specify the amount days, months, years, whatever.

If you want to remove too old messages from the server, perhaps the server itself offers a way to do so...

It does have a "All articles" view, :) I'll go for it. On Arch it depends on webkitgtk, which some time back was considered insecure, and webkit2gtk was supposed to be the only one to use. Perhaps that changed...

Thanks !

I recommend you to explore sourcehut as well, if you're not afraid of something different to gitlab/github workflows.

akregator is unfortunately part of the kde-pim, requiring akonadi, and a bunch of kde deps, see for example:

% pacman -S akregator
resolving dependencies...
looking for conflicting packages...

Packages (92) accounts-qml-module-0.7-4  akonadi-contacts-23.08.0-1  akonadi-mime-23.08.0-1  akonadi-search-23.08.0-1  attica-5.109.0-1  grantlee-5.3.1-1
              grantleetheme-23.08.0-1  kaccounts-integration-23.08.0-1  kactivities-5.109.0-1  karchive-5.109.0-1  kauth-5.109.0-1  kbookmarks-5.109.0-1
              kcalendarcore-5.109.0-1  kcmutils-5.109.0-1  kcodecs-5.109.0-1  kcompletion-5.109.0-1  kconfig-5.109.0-1  kconfigwidgets-5.109.0-1
              kcontacts-1:5.109.0-1  kcoreaddons-5.109.0-1  kcrash-5.109.0-1  kdbusaddons-5.109.0-1  kdeclarative-5.109.0-1  kded-5.109.0-1
              kglobalaccel-5.109.0-1  kguiaddons-5.109.0-1  ki18n-5.109.0-1  kiconthemes-5.109.0-1  kidentitymanagement-23.08.0-1  kimap-23.08.0-1
              kio-5.109.0-2  kirigami2-5.109.0-1  kitemmodels-5.109.0-1  kitemviews-5.109.0-1  kjobwidgets-5.109.0-1  kldap-23.08.0-1  kmailtransport-23.08.0-1
              kmbox-23.08.0-1  kmime-23.08.0-1  knewstuff-5.109.0-1  knotifications-5.109.0-1  knotifyconfig-5.109.0-1  kontactinterface-23.08.0-1
              kpackage-5.109.0-1  kparts-5.109.0-1  kpimtextedit-23.08.0-1  krunner-5.109.0-1  kservice-5.109.0-1  ksmtp-23.08.0-1  ktextaddons-1.4.1-1
              ktextwidgets-5.109.0-1  kuserfeedback-1.2.0-1  kwallet-5.109.0-1  kwayland-5.109.0-1  kwidgetsaddons-5.109.0-1  kxmlgui-5.109.0-1
              libaccounts-glib-1.26-2  libaccounts-qt-1.16-3  libakonadi-23.08.0-1  libdbusmenu-qt5-0.9.3+16.04.20160218-6  libdmtx-0.7.7-1
              libgravatar-23.08.0-1  libkdepim-23.08.0-1  libkgapi-23.08.0-1  libkleo-23.08.0-1  messagelib-23.08.0-1  pimcommon-23.08.0-1
              plasma-framework-5.109.0-1  polkit-qt5-0.114.0-1  prison-5.109.0-1  purpose-5.109.0-1  qca-qt5-2.3.7-1  qt5-graphicaleffects-5.15.10-1
              qt5-location-5.15.10+kde+r4-2  qt5-quickcontrols-5.15.10-1  qt5-quickcontrols2-5.15.10+kde+r6-1  qt5-speech-5.15.10+kde+r1-1
              qt5-wayland-5.15.10+kde+r57-1  qt5-webchannel-5.15.10+kde+r3-1  qt5-webengine-5.15.14-5  qtkeychain-qt5-0.14.1-1
              signon-kwallet-extension-23.08.0-1  signon-plugin-oauth2-0.25-1  signon-ui-0.17+20171022-3  signond-8.61-1  solid-5.109.0-1  sonnet-5.109.0-1
              syndication-5.109.0-1  syntax-highlighting-5.109.0-1  threadweaver-5.109.0-1  xapian-core-1:1.4.23-1  akregator-23.08.0-1

I was hoping there's something which way less dependencies, hopefully GTK rather than Qt... At some point I wanted to use kmail and korganizer, also part of kde-pim, but besides korganizer never fixing a pretty old bug, the amount of deps I needed, plus the akonadi DB, made go back on that attempt. The same goes for akregator unfortunately...

Ohh, I didn't know lemmy already offered such thing. So it would be like https://_instance_/feeds/c/_community_.xml?sort=Active then?

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.

They don't run by themselves, they need a terminal emulator, or a console, underneath, so they can work. You can actually call screen on a console without graphical environment, and it'll provide the console all benefits of multiplexing. That doesn't make the multiplexer a terminal emulator by itself.

So, in my mind no, screen is not a terminal emulator, alacritty is, like xterm is, and so on. The multiplexor just adds extra capabilities to the terminal emulator.

At any rate, it's not worth going any further. What I meant is that neofetch was able to find out and show I'm using alacritty, whereas fastfetch doesn't show alacritty. And we can argue about the virtue of one or the other, but it'll boil down to taste. I prefer how neofetch shows alacritty, hehe. Some might prefer fastfetch showing screen. And most importantly, this is not critical at all.

There's an issue on fastfetch filed about it, and one of the devs indicated when using the screen multiplexer, they could find out the terminal emulator underneath, however they couldn't do the same with tmux. And to be consistent among multiplexers, they decided not to expose the terminal emulator underneath when using multiplexers, just show the multiplexer. I don't agree with that argument, but it's the dev right to choose to do that.

Greetings !

It might achieve it, but I'm not looking into having a lemmy instance, but rather being able to sort of browse and keep up to date with some communities, just as it was possible to do with reddit (no need to host anything)...

No, screen is a terminal multiplexer, like tmux. The terminal emulator I use is alacritty.

That has never been true, not at the point of the discussions on Debian (on Arch there was never a public discussion that I remember), and of of course not true now.

s6, dinit, runit, openrc and shephered are good options, currently in use by different distros. At the time of the public debian descussions, at least runit and openrc were available, but they were dismissed, and I don't remember the arguments, but not so convincing at the time, thus the whole discussion about the topic.

I'm not a systemd opponent, but claims of not having compelling alternatives doesn't feel right. I used Arch with systemd for a while, and I moved later to Artix with s6, and I'm thinking on testing dinit, and I have no issue. I guess if some major distros had made the move to runit or openrc, they would be more used as of now. BTW, at work, for containers and VMs I actually need to use systemd, and I see no problem with that.

It's totally true sysVinit was way hard to keep maintaining on distros, and something else was required. Probably given the influence from major distros changed the game over systemd, and now that's considered standardization now a days, but something else could also have become the standard. What's for sure is that there are success stories of using something else, Guix with shepherd, Artix with several inits (dinit, s6, runit, openrc), Gentoo with openrc (one can choose others, like systemd), void with runit, chimera with dinit, and the list goes on. Variety is not necessarily a luxury, in this case it means one can choose whatever aligns better to one's needs, believes (perhaps simplicity, perhaps minimalism, perhaps free/libre considerations, etc), and so on.

What's also true is that for work purposes, one can't be negligent learning about systemd, most probably one will need to deal with it sooner or later, because major distros, and in particular commercial ones, already embraced systemd, and that's not changing any time soon.

The sad effect of wide adoption of systemd, whether one opposes it or not, is that now services/daemons developers focus on providing systemd ready daemons, and for anything else the distro developers need to port to non systemd alternatives, and even build applications without systemd if that's possible at all. And if one is looking for a daemon not packaged by the non systemd distro of choice, ones is on our own creating the proper service/daemon, but not something impossible.

Well, there are alternatives. There's /e/ (murena.io now a days) and distroot, and you can use gnupg with others who also use gnupg, and with distroot you can use its own encryption as well. There's tutanota and prrotonmail, which use their own encryption mechanisms but only work with the same providers and not with other providers...

I mean there are already several non big corps providers of email. Distroot also provides xmpp, nextcloud, and several other services, the same as /e/. I can't tell I'd trust more TB than the alternatives, several of them are non profit. But there are options. It's sad before smart phones, some big corps were already dominating the services, and after them, things got even worse. But there have been, and still are, options for refugees. That's not the issue in my mind.

The big issue, is that those big corps do what they want, excluding those not using them. All of them, no exception, place received messages from /e/ to the spam, that if the email even reaches the final user, some times it gets discarded by the service without even getting to the end receiver. Several mail registrations for whatever account, banks, insurance, stores and so on, don't even accept email addresses if not from the big corps. So the huge and toxic influence from big corps doesn't get corrected by another non big corp service. It's like with FLOSS alternatives, or more private alternatives in general, the issue is the power most users give to those big corps. Most users prefer those corps services, at times ignoring the non big corps are not less comfortable, but most of the time they don't even care, even if told there are easy enough alternative they would still select big corps. Then with such power, big corps not only dominate, but also discriminate non big corps users...

There's a !pine64@lemmy.ml community BTW...

Thanks !

Yes SMGL is still active. You can try joining one of their channels. There are still people looking for source based distros, not sure while Gentoo is the only thing that pops up for them. I used it for some time, and it's fantastic. Sadly having to build stuff takes too much time, particularly on old, and not performance oriented HW. They had support for binaries, and actually include a binaries grimoire, so you could install binaries that used to take too much time, like Firefox for example. Still it takes too much to keep a source based distro. And if you go all the way, then when changing parts of the building toolchain, like gcc, the recommendation was to build everything so that everything would be built with the more up to date toolchain, that was cool, since SMGL has tools for it, but those fancy stuff take as well a lot of time. There I learned 1st about ccache, hahaha.

Sooo fun, :)

I read about its rhino-pkg, which is just a wrapper as I mentioned. My concern is not about not being able to use each package manager directly, but rather on its packaging policy. Is it to follow canonical/ubuntu decisions? Or will it keep packaging what it as a distro offers to users on deb packages controlled by apt?

Yes, I cross posted it to !rhinolinux@lemmy.ml once I noticed it had a community, though I guess that would be the 1st post ever, :)

and Guix

Well, Thunderbird doesn't, so I couldn't tell if all others were the same, :(

Thanks !

But neofetch tells you if wayland already:

WM: Wayfire (Wayland)

Actually while neofetch detects pretty well I'm using alacritty:

Terminal: alacritty

Probably they learned $TERM is really meaningless if using screen or tmux, but fastfetch totally misses this and mistakenly shows screen as the terminal:

Terminal: screen

The only thing I like of fastfetch over neofetch is that it's faster, :) And yes the display missing, but I've never considered that something of much interest for such output... To me neofetch is just fine, and on terminal it gives you a more accurate answer... In the end is a matter of taste... But what it does is well done, :)

Yeap, I just mentioned Mint because I'm aware about its policy, which is the one I'm hopping Rhino also follows, but I can't tell.

I'm not systemd user, and I generally see this absorbing as much as possible as a terrible practice. I don't usually comment on systemd stuff, since I'm happy just not being forced to use it.

However, even though I don't use it, the decision of people managing systemd really affects non systemd users. See by succeeding in getting all major distros into become systemd distros (somehow now governed by RH, if anyone cares), everything systemd absorbs tend to leave alternatives sooner or later deprecated, or abandoned.

Even autofs is no longer part of some official repos, given systemd has its own auto mount/unmount functionality... And there are several other examples...

At any rate, hopefully the more bloated systemd, doesn't make it the more vulnerable. And also hopefully, doesn't make life worse and worse to non systemd distros and users...

BTW, before sudo there was su, so a life without sudo is possible, :)

Thanks !

Thanks !

Will they keep doing that, is there a policy about it written somewhere? Have they expressed something about it in a forum or news, just like mint did at some point when ubuntu started with firefox mess and others. I can't find anything from their web site, and on this reddit post, Does Rhino Linux use Ubuntu mirrors for apt packages?, it seems they follow closely ubuntu's mirrors, and if they do so, whatever ubuntu stops supporting on APT, sounds like rhino will stop supporting on APT as well.

This would be very sad at least for me.

Besides !rhinolinux@lemmy.ml, which is not officially supported by rhino, there are 5 social media mechanisms they support, which I don't have account for neither I want to, and I don't want to subscribe to another mailing list either. Good old IRC is not one of the contact mechanisms supported BTW, neither email (but even if they did, I don't want to subscribe to yet another email list)... Perhaps someone on any of those official communication channels can ask and share what they answer, making a reference to what they answered already regarding repos...

Many thanks !

Ohh, thanks for that... I noticed when under the office's VPN, it doesn't work, :( Which is really bad to me, since it then block any services from it, :(

It seems like disroot doesn't like the office's cert when connected through VPN...

Thaks for replying !

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...