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.)
This account is being kept for the posterity, but it won’t see further activity past February.
If you want to contact me, I’m at /u/[email protected]
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:
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 @[email protected] 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!
Thank you! It’s working now.
It’s giving me an error, “Error Finding Entity // Make sure you spelled the entity correctly and that it exists!”, when I use my username for lemmy.ml; curiously it works well when I do it for my beehaw.org account.
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.
You’re welcome.
I think that people being jerks take for granted how confusing this might be, if you’re new; we (people in general) tend to take vocab that we already know for granted, as well as solutions for small problems. …except that it doesn’t work when you’re starting out, and we all need to start out somewhere, right.
You have two options: install curl
(check @[email protected]’s comment) or do it manually. Installing curl is the easiest.
If you want to do it the hard way (without the terminal), here’s how:
https://repository.mullvad.net/deb/mullvad-keyring.asc
from your web browser./usr/share/keyrings/
It’s less complicated than it looks like. The text is just a poorly written mess, full of options (Fedora vs. Ubuntu, repo vs. no repo, stable vs. beta), and they’re explaining how to do this through the terminal alone because the interface that you have might be different from what they expect. And because copy-pasting commands is faster.
Can’t I just download a file and install it? I’m on Ubuntu.
Yes, you can! In fact, the instructions include this option; it’s under “Installing the app without the Mullvad repository”. It’s a bad idea though; then you don’t get automatic updates.
A better way to do this is to tell your system “I want software from this repository”, so each time that they make a new version of the program, yours get updated.
but I have no idea what I’m doing here.
I’ll copy-paste their commands to do so, and explain what each does.
sudo curl -fsSLo /usr/share/keyrings/mullvad-keyring.asc https://repository.mullvad.net/deb/mullvad-keyring.asc
echo "deb [signed-by=/usr/share/keyrings/mullvad-keyring.asc arch=$( dpkg --print-architecture )] https://repository.mullvad.net/deb/stable $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/mullvad.list
sudo apt update
sudo apt install mullvad-vpn
The first command boils down to “download this keyring from the internet”. The keyring is a necessary file to know if you’re actually getting your software from Mullvad instead of PoopySoxHaxxor69. If you wanted, you could do it manually, and then move to the /usr/share/keyrings directory, but… it’s more work, come on.
The second command tells your system that you want software from repository.mullvad.net. I don’t use Ubuntu but there’s probably some GUI to do it for you.
The third command boils down to “hey, Ubuntu, update the list of packages for me”.
The fourth one installs the software.
The first response seems reasonable for me; it’s informative and replying to an ambiguous comment, as you can’t quite know if “isn’t there” refers to his individual needs or in general.
The second response is however passive aggressive garbage. Fl4ppers clarified that he was talking about his individual needs; notjustforhackers failed to take it into account, and his response sounds a lot like “I’m just sayin lol lmao… you liar”.
Last I heard is that they are testing 0.19 on Lemmy.ml.
Yup.
“Content not found in lemmy.ml’s single instance is not present in lemmy.ml as a whole at all”
A more accurate equivalence would be “Content not found in the lemmy.ml instance might be found elsewhere in Lemmy.” I’m talking about the federation vs. the lack of.
It’s not like Reddit represents the entire Internet, IDK why you’re giving them special treatment to exclude content without criticism.
I did not claim (or even imply) that “Reddit represents the whole internet”. And I am not “giving them special treatment to exclude content without criticism”. It is just that this content exclusion and the criticism are not relevant in the context of this discussion.
I heavily encourage you to re-read the title of the post (just the title is enough), for context, and contrast it with your own comment. Do it. Please.
It might reduce the problem but I don’t think that’ll solve it, as in some situations instances will still defed each other. For example, where an admin says “users from that instance break my rules, I don’t want to deal with it, defed time”.
It’s interesting how, by hosting your own instance, your view over Lemmy changes. I hope that self-hosters like you become more common.
I would rewrite the second sentence into “As such, content it doesn’t like is not possible to be hosted on their single, general-purpose instance.”
Or rather, “content not found in their single instance is not present in Reddit as a whole at all”.
That’s the point here - it’s true for Reddit but false for Lemmy, as content available in one instance doesn’t need to be hosted yet again in another.
Instance creation and management does not require coding skills. It’s a very different skill set, one of system administration and web hosting.
I phrased it poorly. What I tried to convey is that easier instance creation and management should be a priority for coders, so other people have an easier time hosting/managing their Lemmy instances.
That [interface devs should expect users to have 2+ accounts] is just a ugly workaround, I hope we can come up with something better.
Ugly workaround or not, I believe that this would be still sensible given the current state of Lemmy. Because when people want content from non-federated instances, here are their current solutions:
So the current state of the things actively encourages you to hop into big, general-purpose instances. That is bad for the federation, and it aggravates the “three groups to rule you, three sets of rules to follow” problem.
Do you happen to have an alternative for this idea? Preferably, one that would work with the Lemmyverse now?
Both are great steps in the right direction, I believe.
And eventually I think that “A federates with B” should boil down to “you can post in A using a B account”. With the combined feed being handled by the front-end, and all activity in B being hosted by B itself (not just images).
Lunix sucks so much that it got stuck into the version 2 for years.