Repost from https://todon.eu/@marcohackney/115992340469511552 with ALT text added. Unified chargers, free roaming, travel, study and work everywhere in the EU, simple bank transfers with SEPA and Wero. EU makes life better. It' definitely not GoodEnough™ in all parts.Work remains to be done. And that's worth doing!

Originally from a Facebook post by the EU Commission, ALT text added by me.

#ThanksEU

If you're talking to EU politicians about tech sovereignty, there are a couple of things I hope you'll ask them to consider:

One of the problems with the US tech giants is that they are too big to regulate. They have grown so big that they are more powerful than most countries. Only China and the EU are big enough to even consider trying to regulate them (this is one of the many reasons Brexit was a disaster). You don't want to replace a nominally American company that you can't regulate with a nominally French (or German, or whatever) company that is too big to regulate. It is far better to have a thousand billion-Euro companies than one trillion-Euro company:

• The smaller companies can exert less political pressure on governments.
• A thousand companies will spread out their hiring far more than one company, brining jobs to more regions.
• A billion-Euro company failing is bad for the economy, but a trillion-Euro company failing is a disaster.
• A thriving competitive environment with a dozen companies providing similar products and services gives better consumer outcomes than a single monopoly (or a duopoly like iOS and Android).

Pivoting from big US tech to big EU tech would retain most of the same problems.

And this leads nicely into the second point. Open source was popular in companies because second sources were a well-understood concept. If your business depends on X, you want to be able to buy X from two or more competing suppliers. With open source, in theory, it's easy for a new supplier to provide exactly the same thing. But big open source projects have the same problem as big corporations: they become too big to fork.

As a concrete example, the Chromium team refuses to take patches to support any OS that Google doesn't ship Chrome on. This has knock-on effects such as Electron (and therefore apps that use Electron) officially supporting only platforms that have enough market share for Google ads to care about them (or that Google uses in products or internally).

Open source, in theory, means that anyone can come along and be a second source for Chromium. But Chromium averages about one security vulnerability per day or two. If you are a week behind in upstream merges, you are pretty much guaranteed to have exploitable vulnerabilities. This makes maintaining a fork impossible. Other big projects do take patches but have codebases that undergo rapid continuous refactoring that makes it hard for third parties to build the expertise in the system. Or they have poor onboarding documentation and code comments and so the only way to learn the codebase is to work for the company that sells products around it.

Pivoting from big US tech to big open source projects also retains a lot of the same problems with respect to lock in. Governments should consider the number (and size) of companies that are willing and able to support a codebase when considering whether it meets procurement requirements. If only Google or Oracle (for example) can provide support (new features that the customer wants, merged upstream or maintained for 10 years in a fork) then it should not be considered. If a smaller consultancy such as Igalia can do the same (especially if they can and it's not a project that they have supported for another customer) then it's far more likely to be something that will remain a useful shape as requirements evolve.

Many small companies, supporting many small projects, should be the goal. As soon as a project becomes an essential part of an ecosystem, that should be a signal to fund alternatives.

it is apparently #portfolioDay ?

hello. i'm a ceramicist making raku shinto and shamanic lil friends and lil houses. i hope i can bring a bit of gentleness and spirit into the world through my work, maybe help brighten things even just a smidge.

sculptures can be found at https://www.driftingspirits.art

(or, for UK and norway folk because of tax reasons, https://www.etsy.com/shop/driftingspirits)

and there are lots of new friends to come over the next few weeks!

A while ago I posted about the legendary #Duralex glasses from France, and how the workers, facing possible bankruptcy, decided to turn it into a cooperative rather than accept being sold to investors that wanted to fire a third of the people. Well. They grew their revenue by 22% and plan to break even in 2027. They crowdfunded emergency funding, planned to be €5M which they had to stop when €20M was pledged within 48 hours. YES!

https://www.theguardian.com/world/2025/nov/22/french-people-want-to-save-us-help-pours-glassmaker-duralex

1/3

At the 2025 #Linux #Kernel Maintainers Summit this week the "rust for Linux" experiment has just been deemed concluded (https://lwn.net/SubscriberLink/1050174/6b6d55c90ce1100f/ ).

Rust for Linux maintainer Miguel Ojeda now submitted a patch to follow up on that and remove the "The Rust experiment" section from the #Linux #kernel's docs, as "Rust is here to stay":

conclude the Rust experiment – https://lore.kernel.org/lkml/202512130[email protected]/

He writes:

""The Rust support was merged in v6.1 into mainline in order to help determine whether Rust as a language was suitable for the kernel, i.e. worth the tradeoffs, technically, procedurally and socially.

At the 2025 Linux Kernel Maintainers Summit, the experiment has just been deemed concluded.

Thus remove the section -- it was not fully true already anyway, since there are already uses of Rust in production out there, some well-known Linux distributions enable it and it is already in millions of devices via Android.

Obviously, this does not mean that everything works for every #kernel configuration, architecture, toolchain etc., […]

But the experiment is done, i.e. Rust is here to stay.

I hope this signals commitment from the kernel to companies and other entities to invest more into it, e.g. into giving time to their kernel developers to train themselves in Rust.

[…]""

#LinuxKernel #Rustlang

Earlier this year, LWN.net featured an excellent article named "Linux's missing CRL infrastructure", and today I'm pleased to announce our plans to address that with a utility named 'upki'.

Canonical will be working with Dirkjan Ochtmann and Joe Birr-Pixton over the coming weeks to start bridging the PKI infrastructure gap - first for #Ubuntu, but later for the wider Linux audience.

Get the details on the Ubuntu Discourse!

https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki-infrastructure/73314