CafeFrog, cafefrog@lemmy.cafe

Not a bad idea :)

You’re hitting a problem I have with Ublue as well. I wanted to experiment with immutable distros last year, but Ublue provided extremely little information on how their different flavors actually differed under the hood. I ended up having to search through their forums for like an hour to find snippets of how their different when some people asked, but it was never comprehensive.

From what I recall, Bazzite had a few kernel optimizations for gaming, and received updates at a faster frequency than Bluefin, with one of the devs saying that Bazzite would be more likely to experience regressions due to it being more bleeding edge.

Looking at Bazzite’s front page now, they actually seem to be doing a better job of mentioning what’s unique about it than when I last tried it. But Bluefin and Aurora are still ambiguous.

It’s always been based on stable, AFAIK.

Maybe the notebook needed newer kernel code?

If it was able to boot the Live USB to install it, I figure that means the kernel is new enough to actually run the laptop properly. I can only guess something in the installer itself was messing up somehow? Or perhaps it wasn’t making an entry in the boot table? That’s an odd one for sure.

Only Bluefin LTS is based on CentOS. Standard Bluefin is based on Fedora.

LMDE is not based on Sid, it’s based on Debian Stable. LMDE 7 is currently based on Debian 13 Trixie. You sure you had the right ISO?

Cinnamon was written from scratch to reflect a more traditional desktop metaphor. It was not created from existing GNOME code.

Many parts of Cinnamon were forked from Gnome 3 and Gnome 2 (Mate).

• XPlayer was forked from Gnome Videos (Totem)
• Xviewer was forked from Eye of Gnome
• Xreader was forked from Atril from MATE (itself a fork of Envince from Gnome 2)
• Xed is a fork of Pluma (itself a fork of Gedit 2)
• Cinnamon’s compositor, Muffin, was forked from Gnome 3’s Mutter compositor

Many other parts of Cinnamon are made from scratch, but it is not wrong the say it’s also a Gnome 3 fork in many ways.

An unexpected but welcome update, the Fluxer dev agreed to remove the CLA, which puts it back in the running.

Crazy to see that Las Vegas is essentially surrounded by easily stirred up naturally occuring asbestos in the dust, and Nevada actively suppresses that information.

Like holy shit that’s huge. Being outside in that area is exposing yourself to a massive lung cancer risk.

Just a heads up to anyone interested in Fluxer: I was just informed today of a huge red flag; it has a contributor CLA that could allow it to change to a non-FLOSS license in the future. I was hopeful for it previously, but that kills it for me.

Just a heads up to anyone interested in Fluxer: I was just informed today of a huge red flag for Fluxer; it has a contributor CLA that could allow it to change to a non-FLOSS license in the future. I was hopeful for it previously, but that kills it for me.

EDIT: The Fluxer dev has agreed to remove the CLA!

Just a heads up to anyone interested in Fluxer: I was just informed today of a huge red flag for Fluxer; it has a contributor CLA that could allow it to change to a non-FLOSS license in the future. I was hopeful for it previously, but that kills it for me.

Also @irelephant@lemmy.dbzer0.com

Have safe travels, poVoq!

Fair enough. It definitely isn’t quite as smooth as Discord. I’m hoping that with more funding and users, Movim could get that last bit of polish it needs, but if Fluxer is able to do it first, then fair play honestly.

Personally I think it matters in this case due to the odd way that Matrix is designed to share metadata with all federated servers, which means the one run by Matrix/Element basically has access virtually all metadata on the network, which considering their background, is concerning for me. I wrote more about that aspect here: https://lemmy.cafe/post/31672929/15961430

I see. Does the crypto aspect of Odysee and its new NFT-liking owner concern you at all? If not, have you seen this video?

I’d recommend this well presented short talk on it to get a quick rundown :)

That would be impossible to enforce practically, and would devastate businesses, their main financial supporters.

Like Lemmy a few years ago, there is not yet a large community on Movim. I’m hoping that an exodus of Discord users who give Movim a try will bring with it more activity, just as the reddit API exodus did with Lemmy a couple years back. The first adopters may need to rely on just using it to communicate with friends for a bit as they either wait for others to build communities, or build some themselves, which is what made Lemmy as healthy and vibrant as it is today :)

Matrix is so laggy and clunky and slow and annoying. XMPP was just perfect. And the “Conversations” client, for XMPP, is so fucking fast.

I’ve noticed that as well, XMPP has never been laggy in my experience, it’s very snappy. Matrix is hit or miss, sometimes fine, sometimes a bit slow, especially in larger rooms.

How does XMPP’s E2EE compare to matrix’?

As far as I know, XMPP’s OMEMO encryption is modeled off of Signal’s encryption, but modified to function without a centralized server. It’s generally regarded as a very solid, strong encryption, even better than openPGP.

Matrix’s encryption uses Megolm or olm, which I believe is also regarded well as far as the encryption itself. The issue is that Matrix’s inherent design means it’s spreading copies of the metadata of those messages (though the contents of the message itself is encrypted) far and wide to many servers unnessesarily. Seeing as a lot can still be gleaned from metadata (when a message was sent, to who it was sent to), it’s a concerning model considering how big the main Matrix server is, which means that it usually always receives a copy of all metadata activity on the protocol, unless a self-hosted server completely kills federation (which defeats the point of it).

A good comment from an older reddit thread summed it up well:

matrix.org is unique because it hosts so many user accounts. As a result, it becomes a metadata honeypot for the entire matrix network.
It’s kind of a design flaw in my eyes. Matrix is great. But it would be even better if it didn’t have this issue.

Xmpp is federated, but you have the option of not sharing chat metadata with other servers on the network. Matrix doesn’t give that option.
matrix.org is effectively a central server due to the fact that a majority of accounts are hosted there, AND all metadata associated with those accounts, which includes metadata from other servers they communicate with, accumulates on matrix.org. I would suspect a very high percentage of matrix metadata, ends up on a single server. Xmpp just does not have this problem.