Upgrades happen a different times it seems, depending on the phone, :( Yes, I notice exactly the same… I’m trying to ditch signal any ways, perhaps the right time. But the instructions someone share seem the appropriate ones.

Thanks !

I don’t see that, neither I see a note on its github repo. The only thing I noticed is something I haven’t paid attention before:

Currently, UnifiedPush is unavailable for linked devices.

Which is totally counter productive, and explains why even by setting unifiedPush through ntfy molly keeps draining battery, :(

The official F-Droid doesn’t offer Molly, not even the so called FOSS by its author. And the Molly-FOSS repo from the author still offers Molly (Unified Push). Am I missing something from the “Molly-UP deprecation” referred? I’m not seeing such a thing.

Just a minor suggestion. When looking for something different than what you’re currently familiar with, do so in very open minded way, hopefully no looking for clones to what you were used to, but willing to experience and learn new stuff (there’s no failure, just something new that had to be learned and experienced).

I know it’s easier saying than doing…

Looking for advice on giant communities is sort of hard, and in the end you won’t know what works better for you if you don’t try it. The open mind needs to come with some time to be able to play, and enjoy during the play, so it’s not a whole series of frustrations.

On this same forum (different threads/posts/converstions) I’ve read very different recommendations. Even though Manjaro has been recently getting a lot of bad reputation because of letting some certs expire, it’s still considered an “introductory” gnu + linux distribution. I’ve also read Mint is a pretty good “introductory” gnu + linux distribution as well, specially now that ubuntu has finally shown its inclination towards its snap store, rather than the good and solid dpkg + apt, which allowed it to grow on users to where it’s currently at.

I myself prefer rolling release models for distributions, and being as vanilla as possible, to be closer to upstream as possible. However I dislike systemd, which is just a personal taste, so I don’t have a specific recommendation. It used to be Manjaro offered openrc, but they dropped it, and the distributions I know are Artix (it has gui installers if that’s considered “introduction” level distribution, but one still need to handle the configuration mismatches with upgrades as with Arch), Gentoo (I wouldn’t say it’s not for starters, but for sure it has its learning curve, but more importantly you need to be aware that it’s a source based distribution), and Void. If you don’t really care, rolling release distributions, which might have an easy ramp up might be Manjaro as mentioned, and now I believe openSUSE Tumbleweed. maybe even fedora come close… Rolling release models might come even easier for newcomers, in my opinion, since there’s no need to think on what happens on major updates, but rather one needs to keep updating periodically, but hopefully the distribution helps supporting the safest and saner configurations natively so the user, and particularly newcomer to the distribution don’t have to deal a lot to get such safe and sane configurations, at least to start with. And that’s to me the important part to call it “introductory” distribution, easy installation might be part of it, but it’s hardly the majority of it, and this is perhaps the sad part of what I like about being as vanilla as possible, some distributions even take that as a mantra for configurations, and upstream developers don’t always have the safer, or the saner configurations by default. I believe Manjaro and some others take that into account to make things smoother to start with. Maintaining the distribution, keeping it up to date, being able to install stuff, has it’s learning curve, no matter the tools/frameworks to do so, and it might be harder if one has to deal with how to make things work because the software doesn’t work as it should (configuration required upfront), and it’s not hardened enough as well so the user needs to know that and do additional configuration upfront as well.

I see your point, many thanks !

I see, thanks !

Well, there is something mentioned about latest version of omemo:

OMEMO doesn’t attempt to provide even the vaguest rationale for its design choices, and appears to approach cryptography protocol specification with a care-free attitude.

To put it mildly, this is the wrong way to approach cryptography

…

Because there is no rationale given for this sudden square-root reduction in security against existential forgery attacks, we kind of have to fill in the gaps and assume it was because of some kind of performance or bandwidth considerations.

But even that doesn’t really justify it, does it?

You’re only saving 16 bytes of bandwidth by truncating the MAC. Meanwhile, the actual ciphertext blobs are being encoded with base64, which adds 33% of overhead.

For any message larger than 48 bytes, this base64 encoding will dominate the bandwidth consumption more than using the full HMAC tag would.

…

Is truncating the HMAC tag to to 128 bits still secure? According to Signal, yes, it is. And I offer no disagreement to Signal’s assessment here.

The problem is, as I’ve said repeatedly, OMEMO’s specification makes no attempt to justify their design decisions.

Then on one of the comments, there’s an interesting comment on something signal has mentioned it’s working on quantum resistance, that it’s no clear is something omemo will support, and even less when clients might adopt if eventually available:

Indeed quite often someone compares the two protocols and implies OMEMO is as mature as the current state of the art Signal protocol. Allow me to throw in the emerging post-quantum support that Signal is adding or already has in libsignal.

Somehow is implied on the comment that omemo is immature compared to libsignal…

At any rate, dino uses libsignal-protocol-c (on Artix/Arch 2.3.3), not libomemo, and conversations uses libaxolotle-java (according to the “about” section in the settings). So somehow using signal library underneath. Although I have no idea how up to date with regards to the signal library those might be (though the axolotl dependency on conversations allows to think it’s outdated). And for conversations the author mentions:

To be clear: These aren’t separate dependencies that Conversations pulls in to implement plugin supports. They’re first-party cryptographic implementations all within this Android app’s codebase.

I guess by 1st party the author means like copy/paste the code (with local twists, which might be dangerous but perhaps necessary) to have a local version of the libraries. This sounds like a non version related criticism, but it’s client related rather than protocol related, however the author mentions other clients are way worse, leaving no hope…

I don’t see on dino an option to always use omemo BTW, not sure if dino just it implies omemo by default, but it doesn’t have a way to force it. Perhaps a feature to ask dino developers…

At any rate, according the post there’s little hope for xmpp + omemo. Which was actually something I was still hoping for, well, besides getting jami working at some point (but it has crypto issues on its own, including lack of auditing).

I do use “undetermined”. Thanks a lot. I’ll be asking lemmy.ml somwhere…

What is implied with alacritty not being customizable, what is then .config/alacritty/alacritty.toml meant for? That said, I’d argue kitty has hard coded what fonts can be used with it, though some might think this is good, but in my mind it’s a limitation.

At any rate, this is a matter of taste. I use alacritty with screen. Some might argue kitty is better because of tabs supports, and if that’s a thing for them, then that’s fine…

At any rate, again, terminal emulators are a matter of taste…

Because I have no clue what’s going on… I’m assuming you guys know better.

And no, they don’t seem to be old… There’s a recent post about dino I don’t see, I don’t see either a post about some messages not decrypted, another about dergchart, and finally another one about gajim…

If there’s nothing to comment here, that’s fine… I was just wondering.

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

Perhaps @lapcatsoftware@mastodon.online could think of lemmy besides mastodon, hehe

deleted by creator

Yeah, I was afraid so… I’m OK with Arch, and I actually use Artix (to avoid systemd), but I know there are people who don’t want, neither can do configs, nor maintain them on upgrades, as it’s a typical thing on Arch, and most distros based on it… So I’m afraid there’s really no Arch based distribution for those kind of users, and EndeavourOS seems no exception. Actually if one really wants typical Arch after installation, there are alternatives to the Arch ISO, no need for other distribution for that I’d suggest…

It’d be nice to have an Arch based distribution equivalent to Mint, so maintenance is really minimal on new users, and users with no tech abilities. Something rolling release is actually something welcome for such users, since having to upgrade on major versions is not always as clean, even for people with some experience.

At any rate, thanks for the clarification.

One thing I don’t know about any Arch based distributions is how about configurations. On Arch, the default configurations for some packages, whether do not work out of the box, or are not the safest configs. Whether while installing new SW, or while updating, there’s a good level of involvement particularly with configurations.

Apart from installation, which in rolling release distributions it might be about a one time thing per device, configuration might become a burden for new users.

I believe Manjaro (I’ve never used it) comes with some sort of sane configs that work out of the box for most users, unless when looking for particular tweaks, or so I read in the past. But Manjaro has fallen really down on people’s preferences. If EndeavourOS uses Arch repos, I’m wondering if there’s any difference, once installed, between maintaining Arch and maintaining EndeavourOS. Just by how it sounds, it’s the same thing, a lot of wikies readings (particularly when not familiar with the SW and how to make it work, there’s SW that works without particular configs, but there are some that don’t really work nicely out of the box on Arch), having to config lots of things to install stuff and make it work, and then be careful on upgrades about configs changes. It doesn’t look like EndeavourOS makes this any simpler, and just having some extra stuff, but not having their own repos, where they package SW with curated configs, then I see no purpose other than to make the Arch install easier, which now a days have alternative ways to do so.

Can some one please clarify on configs, and maintenance in general, for EndeavourOS? Is there an Arch based distribution really making this easier on new gnu+linux users, who are are really not used to deal with any of that? TBH, depending on Arch packages repositories sounds hard to achieve any of that…

BTW, if using only apkmirror and apkpure as sources for apks, I’d recommend apkgrabber instead of their own binary apps

it’s not just osm instead of gmaps for the FOSS version. It’s NOT using google push notificationss neither gapps at all. Using sockets instead of push notifications. It makes molly FOSS being more battery hungry, but at least it’s not using google stuff. Not sure if the dev would be willing to integrate suipport for unified push for the FOSS version, that’d be even better…

There’s a !pine64@lemmy.ml community BTW…

For those using tbsync with TB, and any companion extension, like its provided for exchange (office 365 and the like), TB broke tbsync and its companion extensions… That said, there’s an issue, and apparently some developer releases for those wanting to try…

It’s been several times TB breaks extensions with such changes. TB devs don’t have to care, but that means for the users, to be extra careful, and to avoid upgrading until finding out required extensions have caught up…

+1 to Guix, see also: I Love Arch, But GNU Guix Is My New Distro

The env var works fine on Xorg though. And yeap, several applications need to catch up. That’s what I meant when I said it’s not wayland fault itself. However it’s been years things have been trying to catch up. Every now and then I try, but a couple of months back I couldn’t routinely use wayland, given all missing functionality plus additional nuances… The hard part is that if not using gnome, or plasma for that matter, getting things working take a lot of time, just to find out some things, I depend on for work, don’t work yet. At any rate, I still pay attention as well, to forums like this, to see if there’s some news that might trigger another retrial…