Damn, that’s sad. Thank you for the info.

Worst hypothesis they just need to mess around a bit. For example I don’t think that queerasfu.ck would be registered.

They could get a .ck domain instead and move to queer.as.fu.ck, no?

I’ve seen even people in their 40s using them. I don’t think that it’s a big deal, or that it’s too late for that.

Another important detail is that Digg v4 pissed off most of the userbase, so the impact was pretty much immediate. Reddit APIcalypse pissed off only power users instead; the impact will only come off later (sadly likely past IPO).

Lunix sucks so much that it got stuck into the version 2 for years.

Neither, but if I must choose it’s probably slightly more like muscle than like cartilage. If prepared properly it’s really soft and a bit chewy, distantly reminding me meat from stews.

(That reminds me a local pub that prepares some fucking amazing breaded and deep-fried tripe. Definitively not doing it at home - it spills and bubbles the oil like crazy.)

Even here in South America, depending on the region, they’re invasive.

Let’s go simpler: what if your instance was allowed to copy the fed/defed lists from other instances, and use them (alongside simple Boolean logic plus if/then statements) to automatically decide who you’re going to federate/defederate with? That would enable caracoles and fedifams for admins who so desire, but also enable other organically grown relations.

For example. Let’s say that you just joined the federation. And there are three instances that you somewhat trust:

• Alice - it defederates only really problematic instances.
• Bob and Charlie - both are a bit prone to defederate other instances on a whim, but when both defed the same instance it’s usually problematic.

Then you could set up your defederation rules like this:

• if Alice defed it, then defed it too.
• else, if (Bob defed it) and (Charlie defed it), then defed it too.
• else, federate with it.

Of course, that would require distinguishing between manual and automatic fed/defed. You’d be able to use the manual fed/defed from other instances to create your automatic rules, to avoid deadlocks like “Alice is blocking it because Bob is blocking it, and Bob is blocking it because Alice is doing it”.

Aaaaah. I really, really wanted to complain about the excessive amount of keys.

(My comment above is partially a joke - don’t take it too seriously. Even if a new key was added it would be a bit more clutter, but not that big of a deal.)

The source that I’ve linked mentions semantic embedding; so does further literature on the internet. However, the operations are still being performed with the vectors resulting from the tokens themselves, with said embedding playing a secondary role.

This is evident for example through excerpts like

The token embeddings map a token ID to a fixed-size vector with some semantic meaning of the tokens. These brings some interesting properties: similar tokens will have a similar embedding (in other words, calculating the cosine similarity between two embeddings will give us a good idea of how similar the tokens are).

Emphasis mine. A similar conclusion (that the LLM is still handling the tokens, not their meaning) can be reached by analysing the hallucinations that your typical LLM bot outputs, and asking why that hallu is there.

What I’m proposing is deeper than that. It’s to use the input tokens (i.e. morphemes) only to retrieve the sememes (units of meaning; further info here) that they’re conveying, then discard the tokens themselves, and perform the operations solely on the sememes. Then for the output you translate the sememes obtained by the transformer into morphemes=tokens again.

I believe that this would have two big benefits:

1. The amount of data necessary to “train” the LLM will decrease. Perhaps by orders of magnitude.
2. A major type of hallucination will go away: self-contradiction (for example: states that A exists, then that A doesn’t exist).

And it might be an additional layer, but the whole approach is considerably simpler than what’s being done currently - pretending that the tokens themselves have some intrinsic value, then playing whack-a-mole with situations where the token and the contextually assigned value (by the human using the LLM) differ.

[This could even go deeper, handling a pragmatic layer beyond the tokens/morphemes and the units of meaning/sememes. It would be closer to what @njordomir@lemmy.world understood from my other comment, as it would then deal with the intent of the utterance.]

Not quite. I’m focusing on chatbots like Bard, ChatGPT and the likes, and their technology (LLM, or large language model).

At the core those LLMs work like this: they pick words, split them into “tokens”, and then perform a few operations on those tokens, across multiple layers. But at the end of the day they still work with the words themselves, not with the meaning being encoded by those words.

What I want is an LLM that assigns multiple meanings for those words, and performs the operations above on the meaning itself. In other words the LLM would actually understand you, not just chain words.

Complexity does not mean sophistication when it comes to AI and never has and to treat it as such is just a forceful way to make your ideas come true without putting in the real effort.

It’s a bit off-topic, but what I really want is a language model that assigns semantic values to the tokens, and handles those values instead of directly working with the tokens themselves. That would be probably far less complex than current state-of-art LLMs, but way more sophisticated, and require far less data for “training”.

Oh “great”, more crap between Ctrl and Alt.

[Grumpy grandpa] In my times, the space row only had five keys! And we did more than those youngsters do with eight, now nine keys!

Apparently my method is a mix of those listed in the text.

I’m in a similar situation as OP, some of my income is irregular. So my monthly budget isn’t directly based on the last month income, I use the average of the last six months, relying on a checking account for that. (I keep it with enough money to last me one or two months.)

Then I split that budget into four categories:

• savings - I aim for 25%. Into the saving account it goes.
• monthly fixed expenses - periodic, somewhat predictable, monthly. For example bills, cornmeal and rice, cat food, etc.
• variable expenses - they’re necessities like the above, but there’s some wiggling room. Like, if necessary I don’t mind eating eggs four lunches a week and walking instead of taking a bus, but I’d rather not to. Usually split into four weeks, so I expend it gradually.
• “fluff”*¹ - avoidable expenses that I still want for some reason like “it improves my mood”. Things for my hobbies, going to a restaurant, buying nicer clothes or hardware, etc. Unused fluff gets transferred to my savings account in the following month.

Then here’s how I address some complexities:

• periodic expenses for things that I buy every few months (e.g. gas canisters) - I include a fraction of them into the monthly fixed expenses, and only remove the money from the checking account when buying it
• erratic but large expenses (e.g. house repairs) - I usually “borrow” this money from the savings, then “repay” it in the following months, as a fixed expense*².
• high income multiple months in a row - I cap the budget and send the overflow to the savings.
• low income multiple months in a row - cut down fluff, then reduce variable expenses, then reduce monthly fixed expenses, then reduce savings, in this order.
• really low income multiple months in a row - if really necessary I borrow from the savings, keeping in mind that I’ll need to repay myself.

Notes:

1. The actual name that I give to this category is “imposto das lombrigas”, or roughly “roundworm tax”. That’s from from my family jokingly referring to cravings as "to have roundworms for [something].
2. Some people might use a credit card instead for that, to build credit; that also works, but it depends a lot on the government that you pay taxes to. I do have a credit card but I tend to avoid it, as often there are discounts for paying things in cash.

He’s almost Karate Kid!

One potential regression that I see is that the current generative models are abandoned, after being ruled as “infringing copyrights” by multiple countries. The tech itself won’t disappear but it’ll be considerably harder to train newer ones.

The most problematic part is however if one of them survives; likely Google. That would lead to a situation as in your second paragraph.

Ah, got it. My bad. Yeah, not providing anything is even lazier, and unlike “lazy” bash scripts it leaves the user clueless.

I like them, even for software installation. Partially because they’re lazy - it takes almost no effort to write a bash script that will solve a problem like this.

That said a flatpak (like you proposed) would look far more polished, indeed.

Frankly in this case even a simple bash script would do the trick. Have it check your distro, version, and architecture; if you got curl and stuff like this; then ask you if you want the stable or beta version of the software. Then based on this info it adds Mullvad to your repositories and automatically install it.