@giacomo

And all of this starts with the data itself. It is the data you want to access which has the real value. Data you should own from the beginning.

If the data is in an open standard format, there is a possibility to break free.

If you cannot control the data, there are no baseline for digital sovereignty. If you cannot have access to software being able to make use of the data in a meaningful way for you, there are no baseline for digital sovereignty. If the software cannot be written, because the data format is unknown or too closely tied to the service provider generating the data, there are no baseline to achieve digital sovereignty.

With open standards, there can be built open source software using those open standards. Thus, you can decode and extract meaningful information from the data.

There are also no requirements anywhere that there must be more implementations for open source project from more countries. They key point is that source code must be open and available for all. That takes away the chances of someone talking full control of the software and restricting the freedom otherwise possible. Without a source code available, the path to extracting meaningful information ends up incredibly hard.

Open sourced software is one piece of the digital sovereignty puzzle, data in an open standard is another piece in the same puzzle.

Having access to the data files containing your information is yet another piece in the same puzzle. You cannot achieve digital sovereignty without all of these three pieces;then someone will still have control of your information.

Likewise, if you use a service with a proprietary API - you are bound to that service as long as that service uses the same API. If more service providers provide the same standardised API, you can more easily switch between services. Again, open standards is a key component for digital sovereignty - otherwise you will not be able to process your data as you want.

@jwildeboer

@giacomo

If you're concerned about the US controlling open source - you can fork it. But a fork won't be successful if it doesn't have users and contributors.

Remember OpenOffice.org? What do you think people talk more about - that one or the fork LibreOffice?

Android has forks as well. The main problem with Android isn't the problems forking the OS itself. It's the Google Play layers, which is not open source and fully controlled by Google - which way too many apps depends on, making it much harder to break free from Google's Android implementation.

You are equally not forced to use or implement protocols you don't deem needed in your own code. Use the alternatives, HTTP is well established and can do most of what QUIC can do. And the HTTP standard can also be extended and improved.

Protocols not being based on open standards - they are a pain to support outside of its origin software stack. Reverse engineering is the only viable path if there are no other open alternatives available.

So open source and open standards can help you break free of evil empires; the capability of digital sovereignty is built into open source and open standards.

@jwildeboer

@jwildeboer

If you can't manage your own data, you're locked in.
If you can't have access to the software processing your data, you're locked in.
If you can't access you're data due to the data being stored in a service which is down or has blocked your access, you're locked in.

It's as easy as that. Don't put your data in a place where you can't access it when you need it.

Open standards avoid this, your data format is documented and there are more implementations of parsers

It starts with open standards, as then there are less reasons to protect the software inside a proprietary blackbox.

Open source and free/libre software is the natural extension of open standards.

@mosgaard Good point on documentation. That's going to be something going to bite users for a long time - until docs are being updated or clearly marked deprecated/outdated.

And as @PaulDavisTheFirst proved me wrong yesterday, there's a lot of misconceptions and misunderstanding - due to the inherited confused mess from prior days. I owe him an apology and a big thanks for his patience educating me on how Pipewire fits in the stack, in a JACK context. I was clearly wrong. Now I have a better understanding - which helps my further investigations on my latency challenges.

@Vivaldi

@anchr @bjoernstaerk @cmyrland

Tror nok de generative LLM tjenestene i dag ikke er så veldig effektive, grunnet dårlig forståelse av selve innholdet de genererer.

Men at en LLM i dag kan brukes til å få idéer til hvordan man kan løse en oppgave og til en viss grad gi et mer konkret startpunkt man kan bearbeide videre, der kan den nok fungere.

Men å tro at du kan kaste masse oppgaver på en LLM og forvente at du slipper å gjøre veldig mye mer, det tror jeg er veldig naivt - i beste fall.

Dagens LLMer finner mønster og et system i en stor mengde data veldig raskt sammenlignet mot hva et menneske kan greie. Men sammenfatningen av det den har vektlagt må sjekkes nøye - for LLM er langt i fra nøytrale. Og det arbeidet kan ikke overlates til en LLM, og vil dermed ta tid fra et menneske.

Og da er jo spørsmålet, eller dilemmaet: Kan en LLMs sammenfatning av informasjon gi nye innfallsvinkler som et eller flere mennesker kunne ha oversett? Og er det verdt tidsbruken som trengs til å kvalitetssikre resultatet fra en LLM?

Svaret er nok heller ikke svart/hvitt. Det finnes nok tilfeller hvor det kan vurderes mer effektivt å la LLM gjøre en viss mengde av grov jobben - og hvor så er tilfelle. Og det finnes andre oppgaver hvor LLM blir mer kostbart i forhold til tiden som trengs for kvalitetssikringen.

Men LLM selges inn over alt som oppfinnelsen som er minst like stor som oppdagelsen av hjulet. Og det er et solid oversalg av hva LLMer kan gjøre i dag.