Honestly AI has been used for moderation for decades. The newer models will be quite effective. It could be very useful for limiting lower effort spam. Sure dedicated spammers will figure it out and get by it but as the models get better that will get harder.

Of course like every use of probabilistic technology like AI it should still go to human review. We shouldn’t be shadowbanning people because computer said no. But holding suspicious posts in a review queue for the moderators seems quite reasonable (much like they already do with their current systems).

Honestly this sounds more like an investor update showing how innovative we are using modern technology and how it is going to really improve the platform and stonks will go up up up than any meaningful change to their current moderation systems.

Yes. Atom is very much a derivative of RSS. IIUC there was sort of a split between RSS v3 (which never really ended up landing) and Atom hence one had to pick a different name. If the world was a perfect place Atom probably would have been called RSS v3 and people would not be as confused. But at the time it probably wasn’t clear which spec would end up succeeding.

Atom is always better. The one exception is podcasts, as Atom isn’t always supported. But for non-podcast feeds always do Atom.

The main benefit is that it removes ambiguities that cause client incompatibilities and mean your feed looks different to different users. Using Atom just removes the issues. There are no downsides.

I wrote about this here: https://kevincox.ca/2022/05/06/rss-feed-best-practices/#formats

In theory it is safe. When a Nix package is built it isn’t “installed”. Unless root is running/installing random packages out of the Nix store there is no problem. As long as the user’s aren’t added to the trusted-users option they shouldn’t be able to cause any problems for other users.

However like any multi-user system you are sharing a Linux kernel. A kernel is a very complex piece of software with a huge attack surface. Privileged escalation vulnerabilities are commonly found. (This also applies to the nix-daemon, but it is a bit smaller attack surface but vulnerabilities are still occasionally found.) So you shouldn’t assume strong security isolation. I would say that a setup like this is acceptable for mostly-trusted people like coworkers or friends that are not expected to actively exploit vulnerabilities but definitely wouldn’t let random unknown users use the system.

So if you want strong isolation use a VM or separate hardware, but then you won’t be able to share the builds and packages defeating the point in this case.

declaring multiple variables is less error-prone than in C. In C, the following declares x to be a pointer, but (surprisingly at first!) y to be a normal integer:

int* x, y;

Whereas the equivalent in Go does what you’d expect, declaring both to be pointers:

var x, y *int

I don’t think this is a related at all. C could have easily decided that the definition makes both x and y pointers. They just decided not to so that you can declare more variables on one line by being able to do int x, *y, **z, .... It is more flexible.

Similarly that Go line could have been parsed like var x, (y*) int if they wanted to. They just made a different choice.

Trump doesn’t appear to care much about the law.

I understand that this is frustrating but it is arguably the right option. If the correct owner can recover the account without TOTP then the TOTP isn’t really protecting the account.

Of course there are various ways to authenticate and it can make sense to have authentication to be (username + password + OTP) OR (email verification) but for a lot of people that email verification is a weaker link. It is more secure to only allow the former.

What I wish is that more sites would document their account recovery procedure. Often times they ask for a phone number for verification or notifications and that silently becomes a backdoor into the account. Even better would be if users can select what authentication combos are supported on a per-account basis (there are a few companies with “lockdown” settings that are a simplified version of this).

Of course it then becomes important to make it clear to the user “if you ever loose you X your account is forever lost”. It shouldn’t be surprise.

Generally speaking it will be fine. SSH will also refuse keys with open permissions so you would notice if it was wide-open to other users of the device.

But you know if you are running random code or AI harnesses as that user it can be at risk. Or if you copy around the key all over the place it is more likely to leak. But generally speaking you are secure by default, just don’t do something dumb with the key and you’ll have no problems.

It sounds pretty reasonable. As long as you keep SSH patched and keep the key safe it should be quite locked down. Do double-check that password login isn’t allowed (or that all users have a very strong password).

One non-security note is be careful with rsync backup. Generally rsync isn’t considered a backup as any mistakes made in the source will be propagated to the “backup” on next sync. Although there are ways to use rsync to take good backups (like copying to a new directory for each backup).

Why only streaming services? Why not target the volume of any ads within content that contains audio? While we are at it why not say that the add can’t be significantly more bright?

I built Chibichange to have a way to conveniently deliver changelogs to Dawarich users

Have you considered just posting a changelog to your blog? That would be much more convenient than every app I run pinging me in its own way by phoning home to its server.

The problem is that only your heaviest users are going to pay to remove the ads, so it doesn’t make sense to price the subscription at any sort of average user. You need to slide the price point way up the distribution just to break even.

Oof, that is really not a good look. This should have been clearly disclosed and probably with a per-notification for the patch release.

It also supports iOS.

No, the DRM wouldn’t work at higher levels so you would have the same requirements with regard to 4k.

Please be civil and polite. This type of aggressive comment insulting people because of the tools that they use isn’t welcome here.

Please be polite. If you don’t like a post you can downvote it. If you would like to comment please be more civil.

This is the advantage of decentralization over federation. IMHO the fact that Lemmy is only federated really hurts it. Not so much for user accounts (in theory these can be backed up restored and moved. Not ideal but not awful) but in that communities are tied to servers. When the server a community is on goes away it is hugely damaging to that community.

Death to HDMI. DisplayPort is the superior port.

The problem with separating Calendar + Mail + Contacts is that they work best together. Although to be far I am not aware of an open-source system that effectively combines them.

Calendar event invites an updates go over mail. So you want your calendar application to automatically be able to get those. Also options like “automatically add invites from contacts to my calendar” is an awesome feature. Contacts can also be used for spam filtering (although this integration is a bit easier to do externally).

So currently I am using Nextcloud (self-hosted) although I don’t really like it because it is pretty slow on my low-powered VPS. But even still it doesn’t actually have proper email integration. There are bugs open and slowly moving but I’m still using Thunderbird to process most of my calendar stuff.

Not to mention JMAP which is slowly progressing which would be a huge improvement, especially for mobile clients. It also combines these three services.