lambalicious @ lambalicious @lemmy.sdf.org

**I write English / Escribo en Español.**

---

Read more

Posts

10

Comments

839

Joined

2 yr. ago

I don't really buy it tbh. People nowadays take pride in using stuff without understanding it. From Cookie Clicker, to even something as dangerous as car driving. In theory, they should be salivating at the Fediverse.

Hey at least you'll never run out of ich_iel!

What else do people expect them to do?

1.- Refuse-

2.- Apply only the part of the name change that's actually covered by US jurisdiction. The Gulf of Mexico extends noticeably beyond US's borders.

But hey this is Google we're talking about.

Besides, it still say Gulf of Mexico if you’re outside the USA.

If I'm a eg.: Colombian, it should be "Gulf of Mexico" "Golfo de México" wherever I stand, not "Gulf of America".

Oh please. Principles are like asses: everyone's got one, and everyone thinks it's other peoples's that stink.

Many things are worth nil on principle. It's the execution that matters.

And IPv6 won’t be that much harder, it’s only… uh… 32 hex digits

I'm still salty that IPv6 is not 6 octets. Six. It's right there in the name. IPv4 is 4 octets!

posts/second average user activity …

posts/second

posts per second

...what, are you looking for instances for bots?

Everyone gets signed up to that initially and those who want to transfer to another instance afterwards can.

That's the second big problem hidden in this model: account migration doesn't currently work (nor do I know of an ETA for feature release).

Not to mention the first problem: this heavily promotes centralization which is what caused this whole mess in the first place.

I don't get how people get hung on choosing a server when people have been chosing a starter Pokémon since 1998 without any major issues. And you get just about the "same" amount of practical info.

Really, what tiktok does to a generation...

Technically the only way you can vet, is by having root access to their servers and law officer level access to their documents.

Failing that, I can think of four baseline conditions to venture that a given product "shouldn't" enshittify, or that at least the utility of the project is recoverable (or forkable) if it does:

Req 0: Copiability. The software actually provides a full offline (or local) service. There's no way (that I know of!) to enshittify something that can live fully independently from its "mothership".

Req 1: "Letter and Spirit". License has to be Free Software (not just "Open Source") with all the liberties that come with it. (I assume in the future, an exception might be made to allow for New Ethical licenses that would be not FOSS as per the current definition)

Req 2: Reproducibility. Someone else has to have verified that using the source release builds the whole product (at most excepting "assets" like logos). This is usually verified empirically by someone getting to run and maintain a competing instance.

Req 3: No bite hand. The provider must have not used legal measures to exercise violence or restrictions against users of the product (be those consumers or devs). This includes eg.: using the DMCA to punish reviews, or punish implementation of req 2.

If a combination of provider and product completes those four requirements, I feel relatively well assured that the product can't reasonably enshittify, or at least that if it were to happen, there will be enough advance notice and devel momentum that the value of the product can be recovered from it.

Oh i see. I thought there was more to it – but I guess it's just Java being horrible as usual.

In a good internet, you shouldn't have to pay someone else for your own identity.

It's (un)amusing how the Fediverse of all things still depends on a system of identity that relies on forcing trust on a third party that can take that identity from you at any point and without recourse (within that system). Or, you know, you can "forget to drink your internet identity verification can for the commercial god", which is just as (un)funny.

Internet posts are being loaded!

Oh dear!

Wayland

Java support

...what?

It's incredible that wayland is so incapable that it can't even keep this kind of state, and we're back to having to basically having to write .xinit scripts. Because that's what little so far wayland offers: less than xinit.

Persistence of "mental state" mostly. By setting up a compose, you have a written down notion of things like volumes, environment variables and other elements stored somewhere for the behaviour of the container, that can not be ignored or defaulted if you don't wish it, for when you need to undo and redo a container and default behaviours are important.

While sure, those elements can be set in a loooong ${engine} run... command, it's easy to forget to set up something important or copy and paste an accidental endline. A compose file (plus a sample envfile, if you so wish) helps keep the way to set up variables and state under control. Made much easier now that we have both docker-compose run and podman-compose run.

Bue nos dí as pro fe sor

Ubiquitousness is not an aspect of the codec, let alone a technical one. It's yet another failure of capitalism.

Fam, the modern alternative to SSHFS is literally SSHFS.

All that said, if your use case is mostly downloading and uploading files but not moving them between remotes, then overlaying webdav on whatever you feel comfy on (and that's already what eg.: Nexctloud does, IIRC) should serve well.