wow:

We use specifically crafted messages that trigger delivery receipts allowing any user to be pinged without their knowledge or consent

That makes think that 1st, perhaps it would be a good idea to avoid “return receipts” on any messenger, though that breaks ability to know if the destination has actually received, and if the destination has actually read the message.

Perhaps another thing, even though your messenger doesn’t identify users with phone numbers at all, still block the messenger to have access to your contact list. Not sure if this affects, for example if a xmpp client has access to a broader contact list, if it can only relate to xmpp addresses it wouldn’t pay attention to phone numbers, but I can’t really tell.

And of course, don’t use any messenger which tights users with phone numbers, no matter if to share among contacts now usernames are used instead of the phone number, when the phone number is still the way to identify the user.

True, but not entirely, signature spoofing needs OS support, and LOS and divestOS don’t, whereas murenaOS (/e/OS) and lineageOS for microG do. Other than that microG’s own f-droid repo makes it easy to keep microG’s component up to date.

That’s why I mentioned it would be nice to upstream divestOS bootloader lock/unlock at will solution, so that not just LOS, but derivative ROMs can inherit that solution. As some people don’t like the tight integration from murena (/e/) with all of its rebranding, LOS for microG is a very appealing option, if wanting full microG’s support. Actually LOS for microG was there quite before /e/ was created.

That’s great if not having to use any proprietary apps depending on google services, including push notifications, since part of divestos unsupported stuff includes:

Google Apps or microG or Sandboxed Play Services are NOT supported.

Which is fine, if you don’t need to use such apps. An alternative to /e/os, which now a days is actually murenaOS, is lineageOS for micro G, which does sort of monthly releases based on whatever is available as nightly releases on lineageOS. It does provide you with microG and also with F-Droid with privileged extensions installed and already set for you. This might be more suitable than divestos if in need for some such apps.

Yup, divestOS allows for booloader lock though unfortunately they don’t support microG. I hope they somehow help upstream their relock solution to LOS. I use LOS for microG instead, since I need stupid bank apps and also for the office some stupid proprietary multi factor authentication apps… If only LOS for microG could lock the bootloader at will (it needs to be unlocked for major upgrades, like on regular LOS), that’d be great.

There’s as well CalyxOS, which uses microG and also locks the bootloader, however I do prefer LOS since the strategy from CalyxOS and GrapheneOS trying to deGoogle pure Android in my mind sound like having some limitations, as opposed to LOS approach to be based on AOSP instead. Though that’s just in my mind, I’m sure those guys in Calyx and Graphene are the best at security and privacy.

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?

I don’t think so. Dhcpcd + wpa_supplicant is really light, suitable for light installers, and live USB stick images.

I’ve been using dhcpcd + wpa_supplicant for so long… I do understand currently users prefer NM, but I hope there’s no push for it to be the unique way to manage network connectivity, and on light installers, I hope I’m not force to use NM either.

very few, and one has to try so many times… I gave up. I guess RSS feeds whenever possible. though that consumes disk if local, so I’m really reluctant…

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.

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.

true !

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…

Ohh, that’s an android app. I use PC/laptop to check on subs… Thanks any ways !

That’s so sad. So perhaps it’s time to say goodbye to reddit frontends, :( I’d prefer to setup rss feeds, but even those are getting rate limited now a days.

Sadly, even with the movement to lemmy, several interesting technical subs are still strong on reddit. The thing with local feeds, is disk space, and self-host is something I can’t do at the moment. At any rate, with the last libreddit front end down, I can’t even easily get the subs I was locally subscribed to, :(

Oh well…

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…

Artix GNU+Linux. In plan: Guix GNU+Linux.

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, :)

Actually to me, this has made Jitsi less of an option now a days, cause when people need to start looking for which instance, then things become no longer as easy… I now recommend instead Jami, which is close to distributed, which is way better, perhaps if people start using for video calls, it gains users base for being the communication app of choice, :)

I have it working with my family, and ti works quite fine. It’s quite easy as well, once the accounts have all been setup…

Setting an account is not hard at all. The complexities come when wanting multiple devices getting in sync. On Android it’s been rock solid for some time already. On the GNU+Linux side, depending on the distro, it might have fatal issues, or just work.

It depends on what you want. I encourage people to use Jami (distributed, so might be a thing, if not self-hosting your own service, since what is said decentralized in reality is a set of centralized services). If too hard, then XMPP + OMemo. And only then, Matrix (by design it gives up more meta data than XMPP).