I use Fedora on my workstation and somehow have trouble with packages. E.g., there is no OpenVPN 3, which I need for enterprise network. Huh, Fedora 39 doesn't even have it in EPEL. So sad.
Yeah.
The video author can enable a setting to analyze the comments. YouTube itself flags comments that it deems inappropriate. The author only chooses which videos to include this tweak and the level of strictness.
It is enabled by default.
Comments that may be spam, self-promotion, gibberish, and otherwise potentially inappropriate will automatically be held for review in YouTube Studio and will only be published if you approve them. If you want a higher level of protection for your channel, increasing strictness will increase the number of comments held for review.
Let me tell you a secret: any linux distribution is a kernel + a set of pre-installed drivers and programs + their configs. Nothing more than that! Most distributions use the same kernel and roughly the same set of programs. The only differences are in the desktop environment and initial settings.
I would recommend Linux Mint Debian Edition (LMDE) as a start choice. Do not trust those who say that if you choose a “beginner's distro” you won't have to get into the console or text configs. Your choice of distro will determine how often you'll do this.
As a regular user, I've used different distributions and always something didn't work. Many issues couldn't be solved via GUI, so I had to deep dive into both the console and all Linux services.
P.S. Arch Linux daily-driver.
Wow. Does anyone share software from "the russian hacker" Valdik outside the RUNet? That's the first time I've seen it.
We are together with you in favor of XMPP (I am with both hands)! You just "won't sell" that kind of solution to very many people. We are already living in a zoo of messengers. We need to come up with at least two that will cover all the basic needs and offer sufficient privacy.
Matrix's groups have an important difference from SimpleX. Even if the primary server is gone, the related servers will still have the copies.
Seems that's true. Text-only communication in Briar is built by design. I see this from its communication scheme. I don't think any other message options will come up. So I am also on it in case of the Internet outage. Besides, you can chat properly only when you and your contact are both online. Not a very handy option for daily use.
So SimpleX.Chat for privacy and Matrix for public groups.
Agreed. I'm using the native Windows version, written in C#. The developer stopped updating it because he switched to a cross-platform version. I take his point, as not everyone has experience with the technologies that are available on all systems. Electron is the solution. However, even the older version has all the features I need and an awesome UI/UX!
I would recommend Sayonara Player for Linux. It's not as awesome as Dopamine, but I still love it. I couldn't find anything better for Linux!
Sounds reasonable! 👍
Dopamine. The best player after some years of searching.
If a server is hosting our data, albeit in encrypted form, there is always the risk of the server being compromised. You know the history of PGP and why OpenPGP was created, don't you?
One of the options, where every user device is a server, is a blockchain. But I think you'll also agree that this scheme doesn't give complete privacy.
The issue of privacy in this case is a convenience issue. To me, federated is not a checkbox type property: it's either there or it's not. To me, it's a spectrum: some protocol is more federated, some less so. We could design a fully privacy-aware protocol and service that can only partially be considered as federated. You may disagree with me, but I haven't seen a clear definition with a complete list of federated protocol properties 😉
Agreed, it's a contradiction to be privacy and federated at the same time. The federated protocol helps the network to be fault-tolerant and cooperative. In other words, it's easier for us to find each other, and afterward it's harder to lose each other. It obviously doesn't condone privacy 😄
Like Snikket
I think it's unlikely this kind of service exists or is going to appear. There's a blog post by developers of the present implementations of XMPP. It explains the difference between decentralized services and centralized ones, and why the Signal messenger is more popular than all other messengers. A must-read.
Some interesting notes on the Matrix protocol, its limitations and comparison with IRC.
A few crucial quotes, as the article itself is voluminous (but very exhaustive!):
>Compare this to Matrix: when you send a message to a Matrix homeserver, that server first stores it in its internal SQL database. Then it will transmit that message to all clients connected to that server and room, and to all other servers that have clients connected to that room. Those remote servers, in turn, will keep a copy of that message and all its metadata in their own database, by default forever. On encrypted rooms those messages are encrypted, but not their metadata.
>In a federated network, one has to wonder whether GDPR enforcement is even possible at all. But in Matrix in particular, if you want to enforce your right to be forgotten in a given room, you would have to: >1. Enumerate all the users that ever joined the room while you were there >2. Discover all their home servers >3. Start a GDPR procedure against all those servers
>Overall, privacy protections in Matrix mostly concern message contents, not metadata. In other words, who's talking with who, when and from where is not well protected. Compared to a tool like Signal, which goes through great lengths to anonymize that data with features like private contact discovery, disappearing messages, sealed senders, and private groups, Matrix is definitely behind.
>This is a known issue (opened in 2019) in Synapse, but this is not just an implementation issue, it's a flaw in the protocol itself. Home servers keep join/leave of all rooms, which gives clear text information about who is talking to. Synapse logs may also contain privately identifiable information that home server admins might not be aware of in the first place. Those log rotation policies are separate from the server-level retention policy, which may be confusing for a novice sysadmin.
>Combine this with the federation: even if you trust your home server to do the right thing, the second you join a public room with third-party home servers, those ideas kind of get thrown out because those servers can do whatever they want with that information. Again, a problem that is hard to solve in any federation.
>So while you can workaround a home server going down at the room level, there's no such thing at the home server level, for user identities. So if you want those identities to be stable in the long term, you need to think about high availability. One limitation is that the domain name (e.g. matrix.example.com) must never change in the future, as renaming home servers is not supported.
>As a developer, I find Matrix kind of intimidating. The specification is huge. The official specification itself looks somewhat digestable: it's only 6 APIs so that looks, at first, kind of reasonable. But whenever you start asking complicated questions about Matrix, you quickly fall into the Matrix Spec Change specification (which, yes, is a separate specification). And there are literally hundreds of MSCs flying around. It's hard to tell what's been adopted and what hasn't, and even harder to figure out if your specific client has implemented it.
>Just taking the latest weekly Matrix report, you find that three new MSCs proposed, just last week! There's even a graph that shows the number of MSCs is progressing steadily, at 600+ proposals total, with the majority (300+) "new". I would guess the "merged" ones are at about 150.
>I'm also worried that we are repeating the errors of the past. The history of federated services is really fascinating:. IRC, FTP, HTTP, and SMTP were all created in the early days of the internet, and are all still around (except, arguably, FTP, which was removed from major browsers recently). All of them had to face serious challenges in growing their federation.
>IRC had numerous conflicts and forks, both at the technical level but also at the political level. The history of IRC is really something that anyone working on a federated system should study in detail, because they are bound to make the same mistakes if they are not familiar with it.
While I was asleep, apparently the site was hacked. Luckily, (big) part of the lemmy.world team is in US, and some early birds in EU also helped mitigate this. As I am told, this was the issue: - There is an vulnerability which was exploited - Several people had their JWT cookies leaked, including a...
There is some information about a vulnerability in the Lemmy frontend.
So I have questions for the SDF mods and admins.
- Has this affected our instance in any way?
- Has the fix been applied to our frontend?
Or is our instance like the Elusive Joe, and we're not so big yet that we're worth hacking?
