Debian

Would this again segregate the users? Some attribute on a submission which refers to a license would be nice though

I would be happy to provide my energy to microsoft’s openai /s

This would be a good approach to improve growth of the community.

Does the ActivityPub protocol support copyright for user content? E.g. an artist releases some picture and they explicitly prompt a license. Each client should accept that they are obligated to prompt this license when using the content… Something like this

I only knew of debian. In case you can remember other occurrences, feel free to namedrop !!

Don’t hate google too much…! They are an essential company to the west world; They contribute a lot to the community.

As long there is no business interest, the developers there are very competent and would defend their architectural choices I want to believe.

But yes, they - as a whole - have earned such a mistrust by now very much IMO.

The EU will already have projects in development as far as my experience goes.

What I do not know though but think applies: Such an act is legally binding for all member states. If they fight these things, they are allowed to propose at the EU court for adjustment in order to be aligned with the national law. This can postpone the national implementation for a few years.

But it can only be revoked by a new act of the EU council.

And they can simply ignore any new suggestion of the EU parliament if they like to.

The Debian community not already maintains a Chromium fork. How much does that cost?

I honestly can’t and wouldn’t judge: Time, Resources, implicit know-how etc. are unknown to me.

The human time needed should grow with the number of patches that need to be applied to the upstream code base, …

jupp

… because some will fail now and then.

Forks are done due to different reasons. Therefore it depends why to fork. It could be possible that one feature diverges so much that applying patches isn’t enough. Especially patches in a debian sense, neither .diff/.patch-patches.

This is what I refer to as “fatness” of the fork. The more patches, the fatter. It should be possible to build, packege and publish a fork with zero patches without human intervention, after the initial automation work.

For a brief period, until something rattles on the build system. Debian patches are often applied to remove binary blobs due to licensing - Imagine upstream chooses to include M$ Recall into the render engine. You would need to apply extraordinary amounts of work. Maybe even maintaining a complete separate implementation. This would also imply changes on the build systems, which needs to get aligned continiously between both upstreams, now.

Maybe I’m missing something obvious. 😅

With each version you have to very carefully review every commit if you want to maintain compatability with upstream, in order to merge patches into your fork.

When there are 50 devs working on upstream and you need to review every commit to assure requirement X, this alone is a hard path. If you need to also apply workarounds compatible with future versions of upstream, you need PROFESSIONALS. Luckily these are found in the FOSS community; But they are underpaid and worse: underappreciated.

// plus I could imagine that things like chrome may even not be coming with the full test suite. The test suite of a browser are surely so huge I can’t even comprehend the effort put into it. And then bug tickets… Upstream says: Not in my version. Now the fork has to address these themselves! :)

It does not depend in how fat the fork is. You provide some reasons on your own.

Your assumption appears to be that open source software can be maintained with minimal costs by the community and sofware-aid assures an ongoing bug prevention of some sort.

In the end you still need at least a few full-time devs on it. It would be fair to pay them accordingly if they are maintaining behemoths of software.

Funfact: Infrastructure costs are x-times higher then IT Personel in my organization. A big chunk of it is energy and space; But its less then licensing costs…

At least the EU restricts this directly to your communication and make examples for its usages.

Plugins may introduce some risks imo. Non-standard behaviour may be a b*tch.

E.g. the idea of a plugin which posts tags:

How are these elected and shares across instances? And displayed on clients? Are they modifying the actual data written by the user in order to sync?

Maybe they are attractive to admins. But they can mostlikely already query and modify the database, right?

I do not want to be against it just mentioning that it may introduce problems on its own which in turn needs to get adressed. E.g.: When multiple plugins do a task at the same hook; How is the ordering managed? When are transactions committed? Should there be a maximal amount of time spend on plugins at some hook? How are resources shared then?

Let’s think about bad actors: Meta _deploys provides a plugin which compresses and decompresses post content and saves plenty of ressources for the admin. After a couple of years they put it to the grave or change the compression methods such that old posts cant be retrieved. But their instance surely still can access those.

I admire beeing lean. Had some projects where bad plugins raised in popularity and become the defacto standard. But they were resource-hungry and badly written or barely maintained. Workarounds spread back to the original program.

Just looked the first time into the lemmy code and it appears to be very neat and clean. I would recommend to stick to it. But then I am no maintainer and a nobody shrugs

//edit: To me plugins are good to aid customization and enlarging the user base. I do not see how this contributes to the fediverse and instances in the long run.

Why a regex? What do you actually want to filter out? Could it be descriminating?

Do you want to prohibit specific phrases? What abt dfrnt spllngs?

The original comment I replied to did not include considerations about future extensions.

So my - downvoted - comment is even more relevant. There are more important things to put valuable manpower on it. centsdroppedandleave

What U C is What U Get, huh?

Is it?

Ugh, okay Meredith, let’s pretend it’s impossible to handle this with user experience that makes the user acknowledge their conversation with a WhatsApp user is not secure. Meanwhile if the only viable way for this conversion to occur is to have WhatsApp on both ends, the situation less secure.

It is a privacy concern, not a security one.

So according to Meredith, the choice is between less overall security or not having conversations with people who don’t use Signal.

Could you cite this please? Because I do not see this beeing said or implied.

That could makes sense for her salary but it surely is a net negative for Signal users some of which will have to install WhatsApp since they won’t be able to afford not to have those conversations.

Entirley different conversation, accusations and projections. So dropping this.

Do you propose more bots in order to steer the public opinion? That could indeed generate serious money for reddit I suppose!

I doubt that web apps use less power then native apps. Especially because native apps can be entirely compiled to the architecture. It always depend on the software in question.

By dropping pwa they most likely prohibit an api to use any os interface at all. PWA additionally circumvent their store. And therefore steering developers back to their known ecosystem - which requires apple hardware to develop on. Additionally it may “preserve” the dedicated knowledge to develop against their os.

He’s actually German.

Doesn’t this mean the matrix film was right with their visualization (regardless of orientation)?

My X13s with Linux, at 250 nits brightness while browsing via WLAN and playing music from the browser via bluetooth uses 5-8W in total.

I am not familiar with any judicative system. It sounds to me that OpenAI wants to get the evidence the NYT collected beforehand.