❌

Normal view

Received today — 23 June 2026 ⏭

Khrys’presso du lundi 22 juin 2026

✇Framablog
By: Khrys
22 June 2026 at 05:42

Comme chaque lundi, un coup d’Ɠil dans le rĂ©troviseur pour dĂ©couvrir les informations que vous avez peut-ĂȘtre ratĂ©es la semaine derniĂšre.

Tous les liens listĂ©s ci-dessous sont a priori accessibles librement. Si ce n’est pas le cas, pensez Ă  activer votre bloqueur de javascript favori ou Ă  passer en “mode lecture” (Firefox) ;-)

Brave New World

Spécial IA

Spécial guerre(s) au Moyen-Orient

Spécial femmes dans le monde

Spécial France

Spécial femmes en France

Spécial médias et pouvoir

Spécial emmerdeurs irresponsables gérant comme des pieds (et à la néolibérale)

SpĂ©cial recul des droits et libertĂ©s, violences policiĂšres, montĂ©e de l’extrĂȘme-droite


Spécial résistances

Spécial outils de résistance

Spécial MAGAM et cie

Les autres lectures de la semaine

Les BDs/graphiques/photos de la semaine

Les vidéos/podcasts de la semaine

Les trucs chouettes de la semaine

Retrouvez les revues de web précédentes dans la catégorie Libre Veille du Framablog.

Les articles, commentaires et autres images qui composent ces « Khrys’presso » n’engagent que moi (Khrys).

Christian Hergert: Asynchronous State Machines with Fibers

✇Planet GNOME
21 June 2026 at 10:48

Writing state machines gets a bit of a bad reputation because they are often implemented in complex manners which are specific to the problem domain. I think that makes people shy away from writing them when they are truly beneficial, including myself.

Where they often go awry is when you have some sort of work that needs to be done asynchronously. This is exceedingly common in UI programming like GTK applications but just as easily found in daemons.

Because of this, I see people explicitly avoiding the state machine, or worse, implicitly avoiding its correctness by open-coding a solution across a dozen callbacks.

With DexLimiter and DexFiber I find I can write these state machines better.

You can use the limiter with a max-concurrency of 1 to get an “asynchronous Mutex” of sorts. No lock management necessary.

static void
password_daemon_init (PasswordDaemon *daemon)
{
  daemon->limiter = dex_limiter_new (1);
}

Imagine, if you will, that a limiter is a mutex plus a callback/closure which fires as soon as a slot is free. That means we need a little state to send to our transition callback.

/* Define our closure state for a transition */
DEX_DEFINE_CLOSURE_TYPE (StateTransition, state_transition,
  DEX_DEFINE_CLOSURE_OBJECT (PasswordDaemon, daemon),
  DEX_DEFINE_CLOSURE_VALUE (PasswordDaemonMode, target))

That is a nice wrapper around defining a struct with a new and free function.

Now we can request a transition of the state machine. Since our DexLimiter is an asynchronous mutex (with a single runnable slot), the fiber will not be spawned until it is the highest priority.

DexFuture *
password_daemon_transition (PasswordDaemon     *daemon,
                            PasswordDaemonMode  mode)
{
  StateTransition *transition;

  transition = state_transition_new ();
  transition->daemon = g_object_ref (daemon);
  transition->target = mode;

  return dex_limiter_run (daemon->limiter, NULL, 0,
                          password_daemon_transition_fiber,
                          transition,
                          state_transition_free);
}

That makes our transition code very clean when you combine the fiber with g_autoptr() and dex_await() to await the completion of futures. So a state machine might look like the following:

static DexFuture *
password_daemon_transition_fiber (gpointer user_data)
{
  TransitionState *state = user_data;
  GError *error = NULL;

  switch (state->target)
    {
     case PASSWORD_DAEMON_MODE_HANDOFF:
       if (state->daemon->mode != PASSWORD_DAEMON_MODE_INITIAL)
         return invalid_transition (state->daemon->mode,
                                    state->target);

       if (!password_daemon_enter_handoff (self, &error))
         return dex_future_new_for_error (&error);

       break;

      case PASSWORD_DAEMON_MODE_LOCKED:
        ...

      case PASSWORD_DAEMON_MODE_UNLOCKED:
        ...
    }

  return dex_future_new_enum (state->daemon->mode);
}

static gboolean
password_daemon_enter_handoff (PasswordDaemon  *daemon,
                               GError         **error)
{
  GSocket *control;

  if (!(control = dex_await_object (create_socket (), error)))
    return FALSE;

  ...
}

What I find nice about this is enter/leave transition components can be customized for the state machine transition. That leaves room for transitions between states which require specialization for correctness.

This is much cleaner than ad-hoc callbacks chained together because you can await in the transition fiber for asynchronous work to complete and the state machine itself is preserved. No shoving temporary state in your class instance. No testing hell to see if you caught all the failure cases. No pain with sequencing or order of main loop processing.

Hopefully that shows you can use libdex to write more correct and cleaner state machines by keeping the majority of the implementation in one place.

Hylke Bons: Icon for ChiPass

✇Planet GNOME
21 June 2026 at 00:00
Icon for ChiPass

Week 23

This week's icon is for whitequark's project:
ChiPass: "Store and autofill passwords"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Funded by community sponsors (every little helps!).

This Week in GNOME: #254 Commit Graph

✇Planet GNOME
20 June 2026 at 09:42

Update on what happened across the GNOME project in the week from June 13 to June 20.

Third Party Projects

Sjoerd Stendahl says

This week I released Lockpicker.

Lockpicker is a tool to recover passwords from a hash. Essentially it functions as a front-end for hashcat, making it possible to do password recovery without the hassle of hashcat syntax in a GNOME native graphical interface.‹ It’s mainly useful for anyone that is curious about password recovery, security or as a companion app for CTF-challenges.

You can check it out on Flathub.

Luiggi R. Cardoso reports

Draft’s v2.3 is out now!

Now Draft has a new backend and cleaner code, making it easier and faster to add features.

This new version brings:

  • Markdown-inspired styling to make it simpler to organize your notes and snippets;
  • Zoom functionality to make the text larger and easier to read;
  • Now the app fully follows your accent color, making the interface seamless with your desktop.

Download it on Flathub | Contribute on GitLab | Weblate will be back soon!

JumpLink reports

Learn 6502 Assembly (learn assembly programming on a virtual retro console) just shipped 0.7.0. The app now speaks Hebrew, fully translated by Menachem (@naattxx), who also tested and contributed the new right-to-left support. That makes Hebrew our first RTL language and prepares the app for more. This release also welcomes a new Indonesian translation by Arif Budiman, alongside the usual round of small fixes and improvements.

tanay says

Whisp has surpassed 1,000 downloads this week within 15 days(I am in Awe, Thank you so so much). The application now includes several quality-of-life improvements, including the List module, tree-style lists for better organization, note pinning, and keyboard shortcuts for faster navigation.

Development is now moving into Phase 2, focused on expanding Whisp beyond note-taking. Planned features include a built-in Math Engine for calculations, unit and measurement conversions, and Image-to-Text functionality powered by OCR.

Thank you to everyone who has tried, reported issues, and contributed feedback. Community support has been invaluable in helping shape the project.

Project website: https://tanaybhomia.github.io/Whisp/ Source code: https://github.com/tanaybhomia/Whisp

If you’d like to support development, UPI donations are now available through the website, and COFI support is planned soon.

Gitte ↗

A simple Git GUI for GNOME

Christian reports

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.7.0 release! 🎉

The headline feature this time is a visual commit graph in the commit log: branches are drawn with color-coded lines, so commits off the mainline get a distinct per-branch color and it’s much easier to follow how history actually branches and merges. Stashes and pending changes show up as commits in that graph too, giving you a complete picture of your repository at a glance. You can also drop multiple commits at once now.

Diffs got a lot smarter as well. Gitte now detects renames, and the word-based diff has been overhauled to highlight intra-line changes more often. There’s also a new shortcut (Ctrl+D) to switch between staged and unstaged in the working copy view.

There’s more control over your lists and directories: you can toggle whether Gitte recurses into untracked directories, and the branch and tag lists now have a configurable sort order, with global defaults available in the preferences.

This release also comes with a broad UI overhaul. The main layout has been greatly reworked (special thanks to Brage Fuglseth!), and the preferences dialog is now a standard Adwaita preferences dialog. The columns now each have a distinct background color, the sidebar was reorganized, and the commit-graph and “rebase in progress” banners were revamped. On top of that come nice new action buttons in the sidebar, better spinners if an operations takes a bit longer, pane widths kept in sync across all views, and the usual round of consistent title casing and spacing fixes.

Under the hood there’s a performance pass too: file diff lists now show at most 100 files (30 expanded by default, with an option to force loading everything), more operations run asynchronously, and the diff view isn’t reloaded when it doesn’t need to be.

And of course there’s the usual pile of fixes: diff lines are redrawn on theme switch, scroll position is preserved while staging and unstaging, long labels break correctly, tag badges got a better color, and the window size is now saved correctly — including when quitting with Ctrl+Q.

Get it on Flathub, for macOS or have a look at the Code.

GDM Settings ↗

Customize your login screen.

Mazhar Hussain says

It has been almost 2 years since I last posted about GDM Settings on TWIG. While there have been some releases during that time, the development wasn’t happening really consistently. I’m really sad to announce that the development of GDM Settings is on hold for now. I’m not sure when (or if) I’ll pick up the development of this app again.

See issue#324 for information.

Thank you all for the support! It really meant a lot. ❀

Shell Extensions

Christian W reports

macOS-style text capture now also for GNOME: select any screen area, OCR it, copy instantly, optionally translate with this new extension https://extensions.gnome.org/extension/10209/snap-text-extractor/

TomĂĄĆĄ GaĆŸovič says

RSS Feed extension is back after a long time and ported to latest GNOME. Same old feeds, but with a modern look. If you like your news directly from shell you can give it a try https://extensions.gnome.org/extension/948/rss-feed Project page: https://github.com/todevelopers/gnome-shell-extension-rss-feed

Miscellaneous

balooii reports

For the two people out there that might be interested in trying out GIMP 0.54 from 1996 on your modern Linux system: Now you can, I created a Flatpak just for fun. It’s the last version using Motif before it’s creators decided to kick off a little toolkit called GTK
 https://gitlab.gnome.org/balooii/gimp-0.54

GNOME OS ↗

The GNOME operating system, development and testing platform

Bilal Elmoussaoui reports

GNOME OS is now using oo7 by default as a replacement of gnome-keyring-daemon, oo7-portal for the XDG Secrets portal implementation and oo7-cli as a replacement for secret-tool.

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

Hari Rana: Draft-Driven Blogging

✇Planet GNOME
20 June 2026 at 00:00

From 2021 to 2023, I was really motivated to write articles regularly, but that is no longer the case. Most of my energy goes into programming nowadays. Whenever I try to write about a complicated topic in a digestible manner, I quickly lose motivation and don’t publish it.

For half a year, I’ve been trying to write an article about the thought process that went through when making the month view in GNOME Calendar accessible, as well as the implementation details. However, explaining complicated technical details into something that is simultaneously digestible to non-developers interested in accessibility and free and open-source calendar application developers requires me to withdraw my knowledge and assumptions, consider the perspective of someone who is not knowledgeable in this topic, and then recall the events that led me to take certain decisions, which demands a lot of energy.

Due to a lack of motivation, I want to try a different approach. I am calling this approach “draft-driven blogging”. Instead of publishing articles once they are complete, I will publish the draft publicly. This draft may contain keywords, incomplete sentences, random notes, empty sections and other characteristics that are only found in drafts. I will then iteratively improve the draft until it is considered finished.

This approach makes sense to me in terms of publishing and getting things done. I tend to seek perfection, which is great for maximizing quality, but it comes at the cost of motivation. Without external pressure, I am not motivated to fix something if it is not already publicly available. Seeing an unfinished blog post publicly is simply appalling. As it’s ugly, it motivates me to fix and complete it. So, instead of writing and publishing the ‘perfect’ article, I publish the ugly draft and complete it out of spite. Maybe “spite-driven blogging” is a better term for it?

Of course, communication is important. With drafts, I will add a disclaimer stating that the article in question is a draft. The published date will be the date of the last edit, and all previous drafts will be deleted. To avoid spamming RSS feeds and notifications, I will try to republish drafts infrequently.

It’s all an experiment; it might work well, or it might not. I might keep this approach or just pretend that I never tried it in the first place. We’ll see.

Hylke Bons: Icon for Hex Colordle

✇Planet GNOME
19 June 2026 at 00:00
Icon for Hex Colordle

Week 22

This week's icon is for Krafting's project:
Hex Colordle: "Find the color"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Funded by community sponsors (every little helps!).

Table ronde « Logiciels libres », avec Framasoft, Ă  l’AssemblĂ©e Nationale

✇Framablog
By: Framasoft
18 June 2026 at 16:20

Depuis fĂ©vrier 2026, la commission d’enquĂȘte « sur les dĂ©pendances structurelles et les vulnĂ©rabilitĂ©s systĂ©miques dans le secteur du numĂ©rique et les risques pour l’indĂ©pendance de la France » est conduite, Ă  l’AssemblĂ©e nationale par Cyrielle Chatelain (rapporteure) et Philippe Latombe (prĂ©sident). De nombreuses auditions ont Ă©tĂ© tenues, le logiciel libre y Ă©tant souvent Ă©voquĂ© comme alternative aux situations de dĂ©pendance. Framasoft a Ă©tĂ© auditionnĂ©e mercredi 6 mai 2026 dans le cadre d’une table ronde sur le logiciel libre.

Pierre-Yves Gosset, coordinateur des services numĂ©riques de l’association Framasoft, est intervenu au cĂŽtĂ© d’Étienne Gonnu et LoĂŻc Dayot, respectivement chargĂ© de plaidoyer et administrateur de l’association April, de Renaud Chaput, directeur technique de Mastodon, et de Nicolas Vivant, fondateur de France NumĂ©rique Libre, directeur de la stratĂ©gie et de la culture numĂ©riques de la commune d’Échirolles.

 

VulnĂ©rabilitĂ©s systĂ©miques dans le secteur du numĂ©rique : Table ronde sur le logiciel libre – Mercredi 6 mai 2026
 

 

Les auditions se sont achevĂ©es courant mai et le rapport devrait ĂȘtre publiĂ© en juillet 2026.

 

 

Sam Thursfield: Status update, 17th June 2026

✇Planet GNOME
18 June 2026 at 07:58

This month I’m mostly listening to music by Nu Genea, Danalogue and Noon Garden.

I’m going to tell you about a big change I’m proposing for folks using Freedesktop SDK to build operating systems. And I’m also going to talk a bit about the GNOME Foundation elections. Maybe I’ll do that first.

GNOME Foundation elections

The GNOME Foundation is a democratically organised not-for-profit that grew from the GNOME open source project around the year 2000. Anyone who contributes to the GNOME open source project can be a member of the Foundation, which allows (among other things) periodically voting in a Board of Directors who govern the Foundation. You probably know all of this.

Back in 2001 the Foundation was a lively active space. Check out the election results from 2001: 11 candidates were selected out of 25 candidates, some of whom made pretty wild campaign promises such as banning all mentions of proprietary software.

When I became more involved in GNOME, ten or fifteen years ago, the Foundation seemed pretty boring and sensible and not many people volunteered to be directors. Here’s a mail from 2017 of someone complaining about not enough candidates and low voter turnout.

This year’s election has nine eight candidates for five seats, and a lively debate. Two years ago a big explosion happened in the community, and we are still dealing with the fallout and, in many cases, still piecing together what actually happened. (It seems like the explosion had been building for a long time and maybe the boring and sensible days of 2017 weren’t as boring and sensible as they appeared from outside.) I am not impressed by the tone of some of the discourse, everyone involved in the campaign believes in what they are doing and deserves respect, but it does make me optimistic about the future of the GNOME Foundation. Questioning things is healthier than ignoring them.

My quiet theory is that the dynamics of open source have changed fundamentally now that LLMs are a mainstream technology. Code is less of an asset than it ever was. A lot of work in the desktop space since 1997 has been simply keeping pace with the rest of the industry: Apple introduced glassy window bars and so we had to have them in GNOME too, Apple introduced “retina” displays and now we need fractional scaling, Apple introduced the App Store and now we need Flatpak, and so on. All of these are huge engineering efforts requiring a lot of new code.

Now the industry is out of ideas. Apple this year are announcing AI integration and more glassy window bars.

So if code is not the asset, what is? The people, as it always ways. And in an increasingly hostile and untrustworthy internet, where you can’t even trust websites any more, a resilient autonomous and trusted structure like the GNOME Foundation, with a battle-tested democratic structure, and strong moderation capabilities to keep out the increasingly automated and vociferous trolls, is a very valuable thing indeed. (No wonder the trolls see it as a threat).

It’s hard to imagine a parallel universe where there’s no KDE eV and no GNOME Foundation, but I suspect we would miss both of them. Clearly all of the candidates believe in the Foundation enough to run for election. Remember that it’s an unpaid position with a lot of responsibility and minimal benefits. Being a director is a personal sacrifice. So thanks to everyone who keeps it working.

freedesktop-sdk.bst:public-stacks/runtime-gnu.bst

Onto the more technical material, I guess. The Freedesktop SDK is a widely used Flatpak app runtime that powers thousands of apps on Flathub. You probably know that, too.

Flatpak aimed from the beginning to be distro-independent, and consequently the Freedesktop SDK isn’t a repackaging of Debian or Fedora or Alpine Linux, but something more like a DIY Linux From Scratch build. As an app user you don’t notice any of this, because it’s very well executed and apps just work. Again, it’s hard now to imagine a parallel universe where the main Flatpak runtime was Fedora in a trenchcoat, but perhaps that would have impeded the success of Flatpak. (Of course Canonical still built their own app store technology, but I suspect that Canonical re-inventing things is part of every parallel universe).

So Freedesktop SDK has build instructions for common Linux tools, utilities and libraries, and they are so good that most BuildStream projects end up junctioning Freedesktop SDK to reuse them. (I covered this in more detail back in April). In theory this brings a virtuous cycle: we use FDSDK in industry and that funds maintenance and improvement of the build instructions, which in turn benefits the Flatpak runtime which doesn’t have any source of funding of its own.

I’ve been working on a slightly tricky intersection between these two worlds, which I call “Choose your own userland”. It makes a relatively small change to a stack element in Freedesktop SDK, but one which has big consequences for BuildStream projects that junction the project. (And no immediate consequences for Flatpak users, but you could see it as future-proofing).

A stack element is a group of elements. Freedesktop SDK provides various “public stacks” with useful element groupings. Most of these are related to build systems, like public-stacks/buildsystem-autotools.bst which includes everything you need to run builds with the crusty old GNU Autotools build system. Then there’s this special one: public-stacks/runtime-minimal.bst, which as of today includes the following:

  • Root filesystem symlinks
  • C/C++ platform libraries like GNU GLIBC,
  • The GNU Bash shell (and its dependencies Readline and ncurses)
  • GNU Coreutils, and all their dependencies

This stack is a recent addition, announced in the release notes of last year’s FDSDK 25.08 major release:

[BREAKING CHANGE] It’s now possible to create more minimal runtimes thanks to rework of bootstrap-import.bst. This adds a new stack public-stacks/buildsystem-make.bst which is essentially same as the original bootstrap-import.bst. There is also a new stack public-stacks/runtime-minimal.bst that is intended to provide a minimal environment that you can shell into. More info in the related issues: #1728 (closed), #1523

My selfish motivation for this change is I want to build embedded systems that don’t include GNU Bash and Coreutils at all, using BusyBox to provide the shell and utilities instead. This is hard today with FDSDK because every element unconditionally depends on Bash and Coreutils, so how can I remove them from my final system? But coincidentally, in the desktop world we are also seeing GNU Coreutils replaced with uutils/coreutils, a reimplementation in Rust which is already the default in Ubuntu since 25.10. So there’s another reason we might not want to hardcode a specific coreutils implementation in the lowest level stack.

The idea implemented in my branch came from Abderrahim and is delightfully simple: just drop Bash and Coreutils from the runtime-minimal stack, and have elements opt into them explictly.

On hearing the idea, I wasn’t sure how this would work, so of course I was effectively nerd-sniped into trying it. The result is as we’d hoped, it allows you to build systems with alternative coreutils. The FDSDK includes some example VMs, and here’s an example of one of them booting with uutils/coreutils (taken from MR!31779):

So the approach works. My main concern was the amount of churn we would cause if we change the meaning of runtime-minimal.bst. Of course, we often still want GNU Bash and GNU Coreutils, so my branch adds an additional public-stacks/runtime-gnu.bst element that brings in a GNU userland. I added Bash and Coreutils into all the public-stacks/buildsystem-*.bst elements too as we still want them at build time. That means that for most elements the change is actually transparent. You just need to ensure that each output explicitly includes a shell and utilities of your choice as runtime-depensd.

To test things further I tested the changes in branch of gnome-build-meta. It was pretty boring working through various build failures to get to a new dependency graph, but I came out the other side still convinced that this change is a good idea. (You can see my gnome-build-meta branch here, bearing in mind half the changes are actually dealing with differences between FDSDK 25.08 and ‘master’).

There was some lively discussion on the MR and I’m still not entirely clear if this change is going to land, much as I like it. One sticking point is a fear of landing big changes and not having enough people to deal with the fallout, and as an open source maintainer I certainly know that feeling, so I have more testing planned still.

Another complaint is that this change reneges on the promise from 25.08 about public-stacks/runtime-minimal.bst, that it “is intended to provide a minimal environment that you can shell into.“. You can’t shell into anything if there’s no shell, of course, so I can’t argue with the premise. But I am missing why this is a big deal. I’ve always had a bad time in BuildStream build shells because I just want to edit a file for testing and dammit there’s no Vim or even Vi or even Nano
 in fact we don’t even seem to have less?! So I’ve always wanted a way to overlay elements with debug tools in my shell, and it turns out that “bst shell should be able to stage the specified element on top of a base element” is a feature request that’s been open since 2018.

If you use FDSDK as a junction and you like the idea then I’d appreciate comments on the MR. (If you hate the idea, I’m sure you’ve already switched tabs and are half way through posting an irate comment ;-). I am of course prepared for an outcome where this change doesn’t land, and it may indeed lead to some separation of “Linux OS & compiler bootstrap using BuildStream” and “Base Flatpak runtime” into different projects. My gut feeling is that this would be a bit like trying to carve a single grape into two pieces, i.e. there are still few enough people who actually want to maintain build instructions that it makes more sense to collaborate in the same repo.

Thanks as always for reading!

Michael Calabrese: Pitivi Timeline Ruler | Standalone Beta Progress

✇Planet GNOME
18 June 2026 at 00:00

Hello GNOME, This is a progress report on the Pitivi Timeline Ruler Rust rewrite.

Progress

We are rewriting the Pitivi Ruler in Rust and gtk4 snapshot logic to improve performance and memory safety. At its current stage the ruler is being constructed as a standalone widget in a personal repo that can be found here:

Pitivi Timeline Ruler

GTK_DEBUG=interactive cargo run --example sandbox

Any feedback on the code is greatly appreciated!

Structure

I am structuring this around rendering a single interval of ticks between two major ticks once, then stamping that across the duration of the project, as seen in draw_single_interval().

With the ticks stamped across the timeline I am then rendering a cache of Pango labels for the timestamps that are stamped across the visible window. I made the decision to use a BTreeMap for the cache for ease of iterating chronologically through the stamps and for dropping out-of-bounds keys. The logic for this cache handling primarily lives in update_label_cache().

After some feedback from members of the video editing community, I made the decision that minor ticks should always be clean multiples of frames in the time period. This logic is implemented in calculate_minor_divisions().

Next Steps

The primary goal I am focusing on next is implementing the gesture handling, including click and drag actions. Once gestures are implemented I am going to begin moving a lot of the math to traits so that I can write a mock_env and a live_env to start writing some unit testing.

Web-Based Remote Installation for Fedora Linux: Here’s What We’re Building

✇Fedora Magazine
By: Bruno Ciconelle
17 June 2026 at 08:00

If you’ve ever needed to install Fedora Linux on a headless server, a Raspberry Pi, or any machine without a monitor attached, you’ve probably reached for VNC or RDP. They work – but as the installer moves to a web-based interface, there’s a new opportunity to do something more native to that model. We’re building it, and we want your input before we go too far down a path that’s hard to reverse.

Why This Is Happening

The Anaconda installer’s Web UI first landed in Fedora Linux 42 Workstation and was extended to all Live spins in Fedora Linux 43. It’s a full graphical installer built on Cockpit tooling and using PatternFly widgets. The GUI is rendered in a fullscreen browser window – but until now, that browser had to be running on the same machine you’re installing onto.

Here’s the thing: VNC and RDP were built around the GTK interface. While RDP could technically work with the Web UI too (it operates at the display level), a remote browser is a much better fit – orders of magnitude less data and much lower UI latency. As the Web UI becomes the primary installer interface across Fedora Linux editions, it needs its own native remote access story.

On top of that, there are two more forces pushing in the same direction.

As browsers move toward Flatpak packaging – already the reality for atomic desktops and derivatives like Bazzite – remote installation opens an opportunity for shipping focused, smaller boot images that don’t need to bundle a local browser at all. A lightweight ISO aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine.

And once you have a browser-rendered installer, serving it to a remote browser is the natural next step anyway. A headless ARM SBC doesn’t need to run a GPU-accelerated browser locally just to show you a disk partitioning screen. Your laptop can do that for it.

What It Actually Is

The concept is pretty straightforward: Anaconda’s Web UI, already built on Cockpit, gets served over HTTPS. You point a browser at the machine you’re installing, authenticate with a PIN, and you’re controlling the installation remotely. No VNC client, no RDP client, no X forwarding. Just a browser.

If you’ve used Cockpit to manage a server, you already have a feel for the experience. The difference is that the machine you’re connecting to is mid-install, not running a full OS.

Use Cases

The ones we’ve talked through most:

Headless servers – You’re installing onto a server in a rack with no attached display. You expose the Web UI over the network and control everything from your workstation.

Lightweight ARM SBCs – Devices like Raspberry Pi have limited resources. With remote rendering, the Pi just runs the installer backend; all the UI rendering happens on whatever machine you’re connecting from.

Remote monitoring – Even if you’re not fully headless, being able to watch an installation from another machine is genuinely useful. Kick off a server install, go make coffee, check progress from your laptop.

The Design Decisions So Far

We’ve had some meaty discussions about how this should work, and a few things are now settled.

Authentication: You set a PIN through kickstart or boot options, and type it into the browser login page. Same pattern as VNC and RDP – the user provides the password, not the system.

TLS with self-signed certificates: The connection is encrypted, but the certificate is generated on the fly at boot. That means your browser will show the “this certificate isn’t trusted” warning. We’ve accepted this tradeoff – shipping a private key on installation media is a security risk, and the IP address isn’t known ahead of time, so standard PKI doesn’t really apply. For environments that need proper certificates (say, a university deploying at scale), Image Builder is likely the right path to embed custom certs. That’s a later problem.

Single connection only: Only one browser session can connect at a time. Two concurrent sessions could genuinely conflict – one session starting installation while another changes the storage configuration. So: one connection, full stop.

Reconnection behavior: If you disconnect and reconnect, what happens depends on where the installation was. Before the review screen – the point of no return – you start from step one. After the review screen (installation actually running), you land on the progress view. Simple two-state model, covers the critical cases.

Config isolation and port: All Cockpit configuration specific to remote installation lives in /etc/anaconda/cockpit/, not the default Cockpit paths – otherwise the config could leak into the installed system. We’re leaning toward port 443 by default so you can just point your browser at the machine’s IP without specifying a port, but the port will also be configurable.

How This Compares to VNC and RDP

VNC has been around in Anaconda for years; RDP support was added more recently. Both work by screen-sharing the GTK interface. Technically, RDP could work with the Web UI too – it operates at the display level, scraping pixels from the screen. But a remote browser is simply better: you send orders of magnitude less data and get much lower UI latency compared to streaming a full desktop.

Beyond performance, there are practical advantages. No client is required – any modern browser works. No VNC viewer to install, no RDP client to configure, no protocol quirks across platforms. And it’s the same Web UI we’re already actively developing, so features and fixes automatically benefit the remote experience. With VNC or RDP, you’re screen-sharing a separate GTK codebase – a separate maintenance burden.

VNC and RDP aren’t going away for now – they still work with the GTK legacy interface. But as the Web UI becomes the default across more Fedora Linux editions, browser-based remote access is where the investment goes.

Where We Are Right Now

This is a developer preview. Here’s what’s working:

  • Custom login page with PIN-based authentication
  • Separate socket-activated systemd unit for auth (clean separation from the main Cockpit process)
  • Session cookies that survive tab closes, require re-login on browser close
  • Cockpit config in an isolated, anaconda-owned path

Here’s what’s still open:

  • Single-connection enforcement (this will likely require close collaboration with the Cockpit team)
  • Backend detection of whether installation is already running (this is needed for proper reconnection behavior)

If you want to see the PoC in action, there’s a draft PR at rhinstaller/anaconda-webui#1274 with the authentication setup – custom login page, pin-based auth script, socket-activated systemd units, and the Cockpit config override. To try it yourself, clone the PR branch, build an updates image, and boot it with virt-install:

git clone -b poc-remote https://github.com/bruno-fs/anaconda-webui.git
cd anaconda-webui
make create-updates.img

virt-install \
  --name anaconda-remote-test \
  --ram 4096 \
  --vcpus 2 \
  --disk size=20 \
  --location /path/to/Fedora-Everything-netinst-x86_64-Rawhide.iso \
  --extra-arg "inst.updates=http://your-host:port/updates.img" \
  --extra-arg "inst.webui.remote"

This is a proof of concept, not production-ready code. The PIN is hardcoded to 1234, there’s no TLS, and single-connection enforcement isn’t in place yet. Don’t use this for real installations – it’s meant to show the direction and let you poke at the approach. Once the installer boots, point a browser at the VM’s IP and enter 1234 on the login page. It’s rough, but it runs.

What We Want to Hear From You

We’re sharing this now because some of these decisions are hard to unwind once the feature ships, and community input is more useful now than after the fact. A few things we’re genuinely thinking about:

Remote installation is opt-in – you enable it through boot options or kickstart. But here’s a question we’re genuinely considering: should we ship a lightweight boot ISO without a local browser, with remote installation enabled by default? A minimal image aimed at headless and network install scenarios, where the assumption is that you’re connecting from another machine. Would that be useful to you? And if you’re using VNC or RDP for remote installation today, would this replace them? What would it need to do that it doesn’t yet?

Come talk to us on Matrix (#anaconda:fedoraproject.org), or leave a comment on this article. You can also follow the work on the anaconda-webui GitHub repo. We’re looking forward to hearing from you.

Hylke Bons: Bobby joins GNOME Circle

✇Planet GNOME
17 June 2026 at 00:00

Excited that Bobby has been accepted as a GNOME Circle app!


Screenshot of a SQLite table opened in Bobby

Who’s Bobby?

Bobby is a viewer utility. It displays tables from SQLite files. The most deployed database format in the world. That’s it.

Whilst hacking on the backend of Auroras I was missing an easy way to check my data tables. There are many database management tools, but they seemed too heavy for my use case.

GTK4 and Libadwaita

Releasing something smaller first also was a chance to refamiliarise myself with modern GNOME app development. It was my first serious project using Rust.

GTK is still the rock UI toolkit it has always been. Libadwaita makes it easy for your app to look beautiful and is a lot of fun to use.

The main challenge was hooking up the database backend to the ListModel required to be displayed by the new ColumnView. The struggle was worth it though as it enables Bobby to have lazy loading of rows, smooth scrolling, and a limited memory footprint.

After that using any other widget should be a breeze!

Future

I will keep the scope of the app small, but there are a few features I want to add in the future:

  • Encrypted file support
  • Updating values in place
  • Search

Get Bobby on Flathub and always sanitise your database inputs!

Jakub Steiner: Things That Last

✇Planet GNOME
17 June 2026 at 00:00

One of the great annual trips we do with a bunch of friends is a train trip to Jakuszyce, a tiny stop in neighbouring Poland, and ride along the contour line through one of the most beautiful places in the Jizera Mountains. There's only one proper climb from Smedava to Knajpa, the rest is fast. A joyride. Catching up on our lives on the train and a joyride home is the best combo.

Forever Young Bike

I tend to think of myself as a friend of repairs, of making things last. I have sadly had to retire our washing machine after a good 25 years. The dishwasher before that served us more than 15. A boiler and heater had to go this year after about 20. I had my previous car for 13 years and felt like I was bailing too soon, even though there were quite a few issues with it at the end. None of those things ever felt new to me by the end. They most certainly showed their age.

But the bike. The bike I ride every year on that trip, the one leaning against the wall in the shed right now — it still feels like my "new bike". I replaced the tires and brake pads last year and the thing screams. It is such a joy to ride. It feels current, alive, like something I just picked out. Until a friend sent me a photo his Google Photos app reminded him of. A very young version of myself is sitting on that exact bike. Fifteen years ago. Nothing has aged except me. Bikes just don't age like we do.

What’s Next for Pagure.io?!

✇Fedora Magazine
By: Tomáơ Hrčka
16 June 2026 at 14:59

At the Flock 2026 Birds of a Feather session, poetically named FFFwF (or, for us lazy people, Forging Fedora’s Future with Forgejo), we discussed the current state of our migration effort to the new forge. I asked the obligatory question: Who still has things on pagure.io?!

A few brave contributors raised their hands, some with an uneasy look in their eyes. Miro swiftly pointed out that everybody is affected by one particular repository; looking at you, `fedora-scm-requests`. Luckily, the RelEng folks have it in their sights. Sure, there are a few other repos lying around the old faithful, but it is time for the Fedora Project to move on and embrace the Forge.

Our new home is currently running on the LTS branch in v15.0.2. We are going to stick with it in production, and our next LTS upgrade will be to v19.

What is going to happen next?

Pagure itself as a project is hosted on pagure.io, and that service is going to be decommissioned at the end of July 2026. What does that mean for you? Well, that depends on when you are reading this.

If you just came back from Flock 2026 and you still have active repositories on pagure.io, here is what you need to do:

  • Check out the existing organizations in the Forge. If your project fits into any of the existing ones, ask its owners for a migration.

Some of us have commits in projects that point back to pagure.io. Don’t worry, we are not going to break your links, for foreseeable future. We will explore options for implementing redirects so your historical links successfully point to their current locations.

The best way to handle the transition after your move, right now, is to inform your users about your new home. Add a BIG BOLD ANNOUNCEMENT to your README, close all open issues, and create a single pinned issue with your migration announcement.

Note: Do not expect to be able to log in to pagure.io after July 2026.

Wait
 and what about `dist-git`?

Well, that is the next target in the scopes of the Forge team. As I showed you in the room, we have 11 Features that define the transition. The biggest task at hand is a bit more sneaky. We are missing multiple enhancements to the upstream project that will require a lot of coordination and Go code. So, if you find yourself in possession of spare cycles and a particular need to help us make it better and faster, Forgejo is waiting for you!

A road-map with all the tasks for the move will land in the Forge soon. (See resource list below.)

Important Links & Resources

  • Check out the new home: Browse existing organizations on the new Fedora Forge
  • Want to write some Go? Contribute to the upstream Forgejo project.
  • Track our progress: Migration roadmap will be posted here soon

AI Disclaimer: Grammar and formatting were done with the help of robots; all the original brain-farts are my own.

LaSuite.coop : interview d’une coopĂ©rative qui veut (elle aussi !) dĂ©googliser internet

✇Framablog
By: Framasoft
16 June 2026 at 13:20

Ce n’est pas tous les jours qu’on a de belles perspectives à partager. Alors ne boudons pas notre plaisir !

En mars dernier, nous vous partagions un (long) article sur La suite numĂ©rique de l’État, les critiques qui en Ă©taient faites, et plus gĂ©nĂ©ralement la stratĂ©gie « Make or Buy » de l’État.

Nous Ă©voquions alors une interview de l’équipe de LaSuite.coop, une coopĂ©rative dont l’objectif est de proposer des outils numĂ©riques libres et Ă©thiques (en partie basĂ©s sur les outils de LaSuite de l’État).

Nous avons enfin trouvĂ© le temps de les interroger sur leur projet, et ça tombe bien, puisqu’elles et ils ouvrent leur sociĂ©tariat Ă  toute personne souhaitant participer Ă  l’aventure. 

Hello l’équipe de LaSuite.coop ! On est ravi⋅es de vous accueillir pour cette nouvelle interview sur le Framablog. Commençons par le dĂ©but : qui ĂȘtes-vous ?

Bonjour Ă  toute la communautĂ© Framasoft ! Ici LaSuite.coop, une coopĂ©rative nĂ©e de la rencontre entre plusieurs structures qui avaient chacune la mĂȘme conviction : les organisations qui dĂ©fendent des valeurs progressistes mĂ©ritent des outils numĂ©riques qui leur ressemblent.

DerriĂšre le projet, on trouve cinq structures fondatrices : IndieHosters, coopĂ©rative qui hĂ©berge des services libres depuis plus de dix ans ; Open Source Politics, spĂ©cialiste des plateformes de dĂ©mocratie participative pour les collectivitĂ©s ; Yaal Coop, coopĂ©rative de dĂ©veloppement logiciel ; Algoo, Ă©diteur de GalaĂ©, notre solution de messagerie email libre et Le Bureau.coop coopĂ©rative qui accompagne dans la gestion de noms de domaine.. Ensemble, nous avons constituĂ© une SCIC, une SociĂ©tĂ© CoopĂ©rative d’IntĂ©rĂȘt Collectif, pour porter collectivement ce projet.

Ce qui nous rassemble, ce n’est pas simplement le logiciel libre. C’est l’idĂ©e que la maniĂšre dont on produit et gouverne les outils numĂ©riques a des consĂ©quences politiques concrĂštes. On se doute que vous le savez dĂ©jĂ , mais utiliser Google Workspace ou Microsoft 365, ce n’est pas un choix neutre : c’est confier ses donnĂ©es, ses communications et son autonomie Ă  des entreprises dont le modĂšle Ă©conomique repose sur l’extraction et la centralisation. Nous pensons qu’il existe une autre voie, et nous essayons de la rendre accessible.

Alors, dites nous en plus maintenant sur le projet « LaSuite.coop ». Quelle est son histoire ?

L’idĂ©e vient d’IndieHosters. Depuis 2015, TimothĂ©e, Pierre et leur collectif expĂ©rimentent des outils libres avec une conviction simple : il devrait ĂȘtre possible de s’émanciper des GAFAM sans sacrifier le confort ni la fiabilitĂ©. En 2020, pendant le confinement, ils lancent Liiibre, une suite collaborative complĂšte, avec un modĂšle Ă©conomique basĂ© sur les communs, sans clients ni prestataires, mais avec des contributeurs et contributrices d’une ressource partagĂ©e. L’utopie concrĂšte, comme ils disaient.

C’est Ă  cette mĂȘme pĂ©riode qu’IndieHosters et Open Source Politics commencent Ă  travailler ensemble sur des projets de civic tech comme la mise en place d’outils de documentation pour NumĂ©rique En Commun(s) et la migration de la pĂ©tition du SĂ©nat sur Decidim. En parallĂšle, IndieHosters est sollicitĂ© pour contribuer Ă  l’infrastructure de La Suite numĂ©rique de l’État portĂ©e par la DINUM. Deux chemins qui s’alimentent mutuellement : d’un cĂŽtĂ© des expertises techniques qui se renforcent au contact de dĂ©ploiements Ă  grande Ă©chelle, de l’autre des relations de confiance qui se construisent avec des personnes d’horizons diffĂ©rents venant de l’État, de l’ESS et de la civic tech.

C’est lĂ  qu’IndieHosters propose Ă  OSP de commercialiser Liiibre. IndieHosters (« IH ») avait les outils et l’infrastructure, Open Source Politics (« OSP ») avait les clients et les relations commerciales. Une complĂ©mentaritĂ© Ă©vidente. Et du cĂŽtĂ© d’OSP, le contexte accĂ©lĂšre la dĂ©cision : quand Musk rachĂšte Twitter pour en faire une machine Ă  dĂ©sinformation, quand Trump rĂ©compense les Big Tech qui l’ont soutenu, quand Meta supprime ses Ă©quipes de fact-checking, on rĂ©alise que proposer seulement des outils de participation citoyenne Ă  nos clients n’est plus suffisant. La souverainetĂ© numĂ©rique ne peut pas s’arrĂȘter Ă  la plateforme de consultation. On embrasse donc la vision d’IndieHosters.

C’est de lĂ  que naĂźt l’idĂ©e de LaSuite.coop. Ensemble, on a regardĂ© de prĂšs les outils de La Suite numĂ©rique de l’État et ils nous ont grandement sĂ©duit. Comme ils Ă©taient rĂ©servĂ©s aux agents publics nous y avons vu une opportunitĂ© d’en faire profiter le plus grand nombre. Mais pour aller plus loin, il fallait s’entourer.

Pour le dĂ©veloppement IndieHosters a pensĂ© Ă  Yaal Coop qu’ils connaissent via le rĂ©seau Libre Entreprise, un rĂ©seau d’entreprise du numĂ©rique libre qui applique les valeurs du libre Ă  sa gouvernance (horizontalitĂ©, transparence, Ă©galitĂ© salariale, 
), ainsi que par le collectif CHATONS.

Et suite au rachat de Gandi on a vu émerger deux initiatives qui nous on plu, Galae un service email professionnel commercialisé par Algoo et LeBureau.coop pour les noms de domaines. On leur a alors présenté notre projet et proposé de nous rejoindre.

OK. Alors maintenant, creusons un peu votre offre de services : vous proposez quoi ? Et à qui ?

À qui s’adresse-t-on ? À toute organisation qui cherche une alternative crĂ©dible aux suites de Google ou Microsoft : associations, syndicats, coopĂ©ratives, mutuelles, structures de l’ESS, collectivitĂ©s, communes de plus de 1 500 habitants, Ă©tablissements d’enseignement supĂ©rieur, mĂ©dias indĂ©pendants, partis politiques
 Si vous partagez nos valeurs et avez besoin d’outils fiables sans sacrifier votre indĂ©pendance numĂ©rique, LaSuite.coop s’adresse Ă  vous.

Un mot sur notre modĂšle : on parle de cotisation, pas d’abonnement, et ce n’est pas qu’une question de sĂ©mantique. En cotisant, une organisation ne paie pas simplement un prestataire pour un service, elle contribue Ă  un commun, elle participe Ă  le faire vivre et Ă  le dĂ©velopper. C’est une relation fondamentalement diffĂ©rente de celle qu’on entretient avec un Ă©diteur SaaS classique. Le montant est calculĂ© en fonction de la taille de l’organisation et des outils dĂ©ployĂ©s il nous paraĂźt logique de ne pas faire payer une petite asso au mĂȘme tarif qu’une fĂ©dĂ©ration nationale.

ConcrĂštement, on propose aujourd’hui une suite complĂšte accessible via un portail de connexion unique : visio, chat, mail, agenda, prise de notes collaborative, stockage et partage de fichiers (avec la suite Collabora intĂ©grĂ©e pour crĂ©er vos documents textes, tableurs et prĂ©sentations), un gestionnaire de mots de passe et Grist, un outil no-code super puissant pour gĂ©rer vos donnĂ©es. Notre offre actuelle s’adresse aux organisations d’au moins dix personnes, mais on travaille Ă  ouvrir le service aux particuliers et aux petits collectifs d’ici la fin de l’annĂ©e. La souverainetĂ© numĂ©rique ne devrait pas ĂȘtre rĂ©servĂ©e aux structures dĂ©jĂ  bien installĂ©es.

 

Capture du site LaSuite.coop

Capture du site LaSuite.coop

 

Votre offre propose essentiellement les logiciels portĂ©s par La Suite NumĂ©rique de l’État, pourquoi ? Quel est votre rapport avec les Ă©quipes de la Dinum ?

Notre offre comporte en partie des logiciels portĂ©s par la DINUM parce que ce sont de trĂšs bons outils, tout simplement. Docs, Fichiers, Grist, Visio, ces logiciels ont Ă©tĂ© dĂ©veloppĂ©s (ou amĂ©liorĂ© pour le cas de Grist) pour rĂ©pondre aux exigences d’une administration qui gĂšre des donnĂ©es sensibles et des millions d’utilisatrices et d’utilisateurs. Ils sont robustes, open source, maintenus par des communautĂ©s actives. Quand on a regardĂ© ce qui existait pour construire LaSuite.coop, la rĂ©ponse s’est imposĂ©e assez naturellement.

D’autant plus que les membres d’IndieHosters ont contribuĂ© en partie Ă  l’infrastructure de La Suite numĂ©rique de l’État. Cette relation de travail a crĂ©Ă© une vraie proximitĂ©. Aujourd’hui on remonte des bugs, on participe aux discussions sur la feuille de route, et on s’implique dans les rĂ©flexions pour pĂ©renniser le code de ces outils dans la durĂ©e. Il n’y a pas de contrat qui nous lie, juste une communautĂ© qui s’articule dans le mĂȘme sens. On avance ensemble, chacun de son cĂŽtĂ©, vers le mĂȘme horizon.

C’est d’ailleurs ce que TimothĂ©e est allĂ© dĂ©fendre plus tĂŽt cette annĂ©e au FOSDEM : un modĂšle public-coopĂ©ratif pour les communs numĂ©riques. L’idĂ©e est simple et puissante, la DINUM crĂ©e et garantit les communs, LaSuite.coop les maintient, les dĂ©ploie et les rend accessibles au-delĂ  de l’administration, et la communautĂ© en oriente l’évolution. Chacun son rĂŽle, dans le mĂȘme sens. Un modĂšle qui n’a pas besoin de capital-risque ni de logique extractive pour tenir, juste des acteurs alignĂ©s sur l’intĂ©rĂȘt gĂ©nĂ©ral.

 

Avez-vous d’autres envies d’ouverture de services en perspective ?

Oui en effet ! D’abord ouvrir le service aux structures de moins de dix personnes et aux particuliers, ensuite, dĂ©velopper un outil de migration pour faciliter la transition vers LaSuite.coop pour le plus grand nombre. Parce qu’on sait que le frein principal ce n’est pas la volontĂ©, c’est la complexitĂ© perçue du passage d’un outil Ă  un autre. Un bon outil de migration, c’est ce qui transforme une bonne intention en vrai changement.

Nous avons Ă©galement des liens Ă©troits avec d’autres Ă©diteurs d’applications qu’on prĂ©voit de faire rentrer dans la gouvernance et dans l’offre prochainement : Biru (avec l’app Tenzu), tiBillet, kaihuri (pour Mobilizon) et peut ĂȘtre vous Framasoft (pour PeerTube).

 

Super ! Vous ĂȘtes actuellement en pĂ©riode de prĂ©-ouverture de levĂ©e de fonds, car vous ouvrez votre sociĂ©tariat. Qu’est-ce que cela signifie, concrĂštement ?

Devenir sociĂ©taire de LaSuite.coop, c’est acquĂ©rir au moins une part sociale Ă  100 euros et avec elle, une voix dans la coopĂ©rative. Droit de vote, accĂšs aux assemblĂ©es gĂ©nĂ©rales, possibilitĂ© de peser sur les futurs dĂ©veloppements des outils. On ne devient pas client, on devient copropriĂ©taire d’une infrastructure numĂ©rique souveraine.

C’est rare, et c’est ce qui nous tient Ă  cƓur, que les personnes qui utilisent ces outils puissent aussi dĂ©cider de leur direction. Une coopĂ©rative sans sociĂ©taires, c’est une coquille vide. Avec eux, c’est un projet qui s’ancre dans le temps.

Pour l’instant, vous pouvez manifester votre intĂ©rĂȘt sur notre site, la campagne ouvrira trĂšs prochainement. Ces prĂ©-inscriptions comptent beaucoup pour nous car c’est une façon concrĂšte de mesurer l’intĂ©rĂȘt pour le projet et de nous donner la confiance nĂ©cessaire pour avancer sereinement vers nos objectifs. Inscrivez-vous dĂšs maintenant sur https://societariat.lasuite.coop/ pour ĂȘtre averti·e en avant-premiĂšre.

Capture Ă©cran site LaSuite.coop

Capture Ă©cran site LaSuite.coop

 

Vous ĂȘtes-vous fixĂ© des objectifs financiers Ă  atteindre ? Lesquels et pourquoi ?

Nous nous sommes fixĂ© un objectif minimum de 200 000 € pour avoir les reins solides et franchir un premier cap : augmenter significativement le nombre d’organisations auxquelles nous proposons nos services, en commençant par les coopĂ©ratives.

Au-delĂ , nous espĂ©rons rencontrer un Ă©cho le plus large possible, pour avoir les moyens d’outiller rapidement les petites entreprises et le grand public.

Enfin, Ă  partir d’un seuil de quelques millions d’euros, nous considĂ©rons qu’il sera prĂ©fĂ©rable de crĂ©er un fonds de dotation pour accompagner l’essaimage de structures comme la nĂŽtre sur le territoire, plutĂŽt que de devenir une mĂ©ga-structure. Nous avons Ă  cƓur de privilĂ©gier la mise en rĂ©seau de structures Ă  taille humaine comme le font des coopĂ©ratives telles que Biocoop ou Enercoop, plutĂŽt que de former un monolithe. Sur ce point aussi, on pense diffĂ©remment des GAFAM !

Les tarifs de LaSuite.coop (au 11/06/2026)

Les tarifs de LaSuite.coop (au 11/06/2026)

Allongez-vous sur le divan, fermez les yeux
 Pour vous, dans 5 ans, LaSuite.coop, c’est quoi ?

Dans cinq ans, on aimerait avoir prouvĂ© qu’un modĂšle coopĂ©ratif peut tenir face aux gĂ©ants, pas en les imitant, mais en faisant mieux sur ce qui compte vraiment. Des outils aussi fluides que Google Workspace, avec un contact humain en plus et des donnĂ©es qui restent les vĂŽtres.

ConcrĂštement, on veut avoir ouvert le service au grand public, dĂ©veloppĂ© un outil de migration en un clic depuis Microsoft et Google et commencĂ© Ă  reverser une part de notre chiffre d’affaires aux communs numĂ©riques que nous faisons vivre.

On veut aussi avoir les moyens de financer deux postes qui nous tiennent particuliĂšrement Ă  cƓur. Le premier : une personne dĂ©diĂ©e Ă  la qualitĂ© du code que l’on repartage Ă  la communautĂ© open source avec documentation rigoureuse, code lisible, pour que n’importe qui puisse venir Ă©tudier ce qu’on fait et s’en emparer. Le deuxiĂšme, une personne Ă  temps complet sur l’animation de l’écosystĂšme des communs numĂ©riques, en interne ou via une structure partenaire. Parce qu’un commun sans communautĂ© active, ça ne dure pas.

Il y a aussi l’ambition plus large de contribuer Ă  faire migrer une partie significative de la population française vers des outils libres (on a le droit de rĂȘver) et de porter un plaidoyer au niveau europĂ©en pour que ce modĂšle public-coopĂ©ratif essaime au-delĂ  de nos frontiĂšres. Nous sommes convaincus que la souverainetĂ© numĂ©rique ne se construira pas pays par pays, chacun dans son coin. En cinq ans, on veut avoir dĂ©montrĂ© que l’utopie concrĂšte, ça fonctionne.

On espĂšre aussi que dans 5 ans (et mĂȘme bien avant) on fasse parti des membres bien identifiĂ©s des Licoornes et qu’on participe avec eux Ă  promouvoir le modĂšle coopĂ©ratif, comme ils le font avec leur campagne ALT au capitalisme en cours.

Capture Ă©cran site LaSuite.coop

Question relativement rĂ©currente dans les interviews du Framablog : y a-t-il une question que vous auriez aimĂ© qu’on vous pose ?

La question qu’on redoute un peu mais qu’il faut poser : « Qu’est-ce qui pourrait faire Ă©chouer LaSuite.coop ? »

L’indiffĂ©rence. Pas l’hostilitĂ©, ça, ça mobilise, mais l’indiffĂ©rence
 Le sentiment que le problĂšme n’est pas si urgent, qu’on verra ça plus tard. On peut construire les meilleurs outils du monde, porter le modĂšle le plus juste qui soit, si personne ne se sent concernĂ©, ça ne suffit pas. C’est pour ça que le sociĂ©tariat compte autant pour nous. Chaque personne qui rejoint la coopĂ©rative, c’est une personne de plus qui a dĂ©cidĂ© que plus tard c’est maintenant.

 

Lien pour vous soutenir :

→ societariat.lasuite.coop

Jussi Pakkanen: Beware of Star Trek managers, especially when bearing MBAs

✇Planet GNOME
15 June 2026 at 19:29

Almost exactly three years ago the Oceangate submarine implosion happened. The disaster came about when a billionaire called Stockton Rush created his own unclassified submarine to go sightseeing on the Titanic. Ignoring all advice from experts he created a "macgyveresque death trap" that eventually killed him and sadly also 4 innocent people. The whole thing was a massive display of stupidity and arrogance with unfortunate outcomes. We are not going to go into the actual event any deeper, but those interested can find lots of material online.

Instead we are going to look more deeply into one often overlooked points of Stockton Rush's character. Apparently he felt like he was something of a "new James T. Kirk" (link1 paywalled, link2). Liking Star Trek is not that unusual. I'm guessing that more than 99% of the readers of this blog are fellow Star Trek fans. The problem lies elsewhere, but to understand it we first have travel back in time.

A brief overview of the British navy during the Napoleonic wars (by a non-historian, so probably inaccurate)

The original concept for Star Trek was, approximately, The Adventures of Horatio Hornblower in Space! The Enterprise is basically a British warship sailing through the vast ocean of outer space. The command structure mirrors this, where you have a captain, navigator, ship's doctor and so on. The Next Generation leaned into this even further by having a first officer and so on. The original Star Trek never went into detail on how the main cast got to their current positions, just that there was an Starfleet Academy they went to.

In the Napoleonic era of Hornblower things were quite different. Anyone who wanted to become a captain pretty much had to be from the upper classes. They had to obtain a letter of recommendation so that they could join a vessel as a midshipman at the age of 13 or so. They were expected to be able seamen by this time and then spent the next six to seven years working on the ship rigging sails and doing all manner of random jobs. This went on for six to nine years depending on circumstances, after which the person could take a formal examination to become a lieutenant. The test was not trivial, many people could not pass even after trying multiple times.

A lieutenant then had to work successfully for several years before obtaining the rank of captain. Even that did not guarantee a commission. Some captains never commanded a ship simply because there were not enough of them to go around. All in all becoming a ship's captain was a long and difficult journey. In a surprisingly non-British turn of events it was not possible for aristocrats to sneak past the gates. Getting a midshipman position was obviously easier with connections, but the lieutenant's test was something they had to pass on their own.

All of this is to say that every captain of the time was an expert with decades of working experience on many different positions aboard the ship.

What does a captain actually do?

[Note: I have not fact checked this portion at all. Feel free to consider it fanfiction.]

The year is 1808 and we are aboard a British warship about to leave for a mission of great importance. The captain gives the order to set sail. Whistles are blown, bells are rung and sailors springs into action. Every single man, with one exception, is either doing manual labour or directly supervising their underlings. That exception is the captain, who seemingly stands around doing nothing (at least if you ask the crew). This is not so.

What he is doing is crucial. He is observing the state of the ship and her crew. This includes things like overall crew morale, any aberrations from normal operations that could cause problems, thinking of workflow improvements and so on. In a sense he has to sense the ship itself. This only works because of two things. First of all he has personal experience doing the exact work he is observing. If you have not personally "been there", you can't really know if a crew is working well or not. You need a "gut feeling" to be able to sense this. Secondly the captain does not have any manual labour so he can focus all of his mental energy on observing the ship's state. He is preparing for all the unexpected things that may occur in the future. This can only happen if your brain is free from menial tasks.

This is exactly what most books on business and project management advocate. It is a time tested way of improving your chances of success. A highly skilled commander can take an average team of people and lead them to victory. It is the basic plot of most military and sports movies.

Getting back to the present

Now take a typical modern day billionaire-via-inheritance and show them Star Trek at an impressionable age. Do they see the advantages of education, hard work and ethics? The foundation upon which Gene Roddenberry carefully built the show? Hell no! What they see is this (TNG screenshot used because TOS did not have a suitable maritime episode).

And then they think: "Wow! I want to be exactly like that! Parading around in a funny hat while everyone obeys my orders without question is my life's mission from now on. And I get to have sexy space sex with hot sexy space ladies of sex whenever I want. This appeals to me even more profoundly than Atlas Shrugged." Some of them might go on to watch Master and Commander and shed tears upon realizing that they cant publicly flog employees for failing to salute their superiors. Yet. Expect this to be made legal in Silicon Valley any day now.

Liking Kirk is not in any way a bad thing. Wanting to "be just like Kirk" is, because in the real world running a business like Kirk runs the Enterprise is a terrible way to do things. An example will illustrate this nicely. Let's imagine a random episode where the Enterprise has gotten into trouble. Eventually Kirk will call for Scotty and tell him: "You need to <babble> <babble> <babble>." Scotty will then reply with a varying level of scottish accent something like: "I cannae change the laws of physics, captain". Kirk will then say the same thing again, just more aggressively and in a close up shot. Scotty replies with "Well in that case I can get it done in sixty minutes." Kirk counters with: "You have five." And thus the problem is solved. Kirk gets a commendation for incredible valour under stress while Scotty, who did all of the actual work, is never mentioned.

In "Kirk style" management the Big Boss tells his underlings what to do. If they try to give any sort of feedback, the Boss ignores everything and just repeats his original orders again and again until the other party yields. The only reason underlings ever resist The Vision is that they are lazy and it is the job of the manager to put them in their place. This seems like a bit from a comedy show, but I have unfortunately worked under bosses like this. Either you try to talk at least some sense into them, fail, get labeled as a "not team player", watch the project crash and get blamed for the failure, or you try to do the impossible task given to you, fail watch the project crash and get blamed for the failure.

Another major problem with Kirk is that due to the way tv shows and movies need to be structured, he is actually an obsessive gambler. The stakes must always get higher and the ways to get out of trouble must become ever crazier. Kirk will break any and all laws and regulations he sees fit and then, once he has succeeded, no disciplinary action is taken. The ends justify the means. Idolising this sort of behaviour leads to thinking that wild one-in-a-million gambits will succeed at least 99 times out of a hundred. And even if it fails, you can get out of it by betting everything on an even bigger gamble. The real world does not work like that. Reality is not a story and you are not its hero. It does not owe you eternal, or even eventual, success. Had Stockton Rush survived his death trap, he would most likely have faced criminal charges and, if convicted, gone to jail.

The myth of the existence of the professional manager

Let's make one last detour in the 1800s and assume that the 7th Earl of Sidcup or some such really wants to get his idiot son instated as a captain. He and contacts the appropriate naval officers.

"My offspring needs to become a captain of a ship post haste!"

"Well first he has to become a midshipman and ..."

"Phah! None of that nonsense. It's way too slow and not becoming of my statute. Also my son is 35 years old so the post of a midshipman would be beneath him."

"I see. Well what sort of prior naval experience does he have?"

"None."

"Has he even ever been out to sea?"

"Not to my knowledge. But that does not matter. He is highly skilled in using the abacus excelius to compute annual budgets."

"By himself?"

"Of course not. That is what secretaries are for. He just gives them orders. That he can do. And that is all that matters. Same as in sailing."

This person is unlikely to get his wish with this line of reasoning. On the other hand in modern business life this is common. For example when startups get VC money, a common requirement is that they need to get a "proper manager" as a CEO. Typically this means the investor's friend, and more often than not an MBA.

Contrary to common belief, having an MBA does not make you incompetent at managing a technical company (though there is a strong positive correlation). It is entirely possible to be a good manager on a field you have no personal experience in. You just have to have a lot of humility, listen (actually, properly listen) to your employees and let the people with hands-on experience make the most technical, product and development decisions. In other words you have to be the enabler, not the maverick decision maker. People with these sorts of personality traits are rare and typically their career choices steer as far away from getting an MBA as possible.

The absolute worst thing happens if the CEO in question combines the (lack of) skills of an MBA with the attitude of Kirk. That leads to incompetent decisions based on willful ignorance, executed with the fury of an egomaniac who refuses to even entertain the notion that they might be wrong. Further, any person inside the organisation who dares to point out potential flaws in the plan will soon find themselves outside said organisation. Disagreement is treason. Treason shall not go unpunished.

In the 1800s the British navy could be said to be the best in the world. It seems plausible that one component of this success was the requirement that the officers running their ships had to have actual experience operating the ship. Not looking at other people operating it. Not pretending to read about operating it for a test. Actually doing it. If we look around how MBA wielding sociopath CEOs are enshittifying absolutely everything about the tech industry, bringing this requirement back into active use starts to feel awfully tempting.

Epilogue: Why doesn't everything immediately explode?

A reasonable counterpoint to everything written above would be that if managers truly are that bad, shouldn't all those companies be bankrupt by now? In an ideal world they would be, but there are opposing forces that keep them going.

The first one is that all corporations have inertia. If you took an established major company and actively started to mismanage it to death, it would still take years for things to eventually collapse. 

The second one is a dirty little secret. Many employees care more about the product they work on than "corporate visions" that seem to stem from overuse of peyote. They don't blindly obey idiotic commands but instead try to make things silently work within the system. Basically this means that corporations thrive despite their mad kings, not because of them. I know several people who have worked in these kinds of organizations and this is not as rare of an occurrence as one might imagine.

I have also experienced it personally. Years ago I was at a company, whose CEO (who, to the best of my knowledge, did not have an MBA) wanted to change the company's product so that it would do a specific thing X. Everybody thought this was a horrible idea and tried to reason with him using solid business and technical reasons (which turned out to be 100% correct). That failed. Spectacularly. This lead to an eternal series of secret meetings. The participants were main developers and all managers except the CEO. The only item on the agenda was "How can we make the CEO think that we did what he ordered while doing the exact opposite".

Eventually we did succeed, but boy was that a surreal couple of weeks.

Sandbox AI coding agents with microVMs on Fedora Linux

✇Fedora Magazine
By: Martin Sehnoutka
15 June 2026 at 08:00

AI coding agents such as Claude code or Codex get more capable every month. This is great for productivity, but approving all commands gets annoying really quickly. On the other hand, allowing agents to run any command on your work machine is not a great idea. They are really good at exploring your production cluster using kubectl or running remote commands at your production servers over SSH.

Fortunately, Linux distributions come with plenty of options for process isolation. You can run agents as a completely different user, in a container, or in a VM. This article shows how to use microVMs to run coding agents.

Security concerns

Running AI agents in unattended mode is like running untrusted code. Companies behind these agents, such as Anthropic or Google, are not trying to steal credentials, but people keep coming up with new attack vectors like Slopsquatting or prompt injections virtually anywhere.

The coding agents themselves ship with built-in mitigations that try to refuse prompt injections as described, for example, here.

Lightweight sandboxing technologies are another layer of defense in coding agents. On Linux, bwrap is one of the possible implementations. This raises the bar, yet sandbox escapes are still a problem. Take a look at CVE-2026-39861 as an example of multi-platform sandbox escape.

You could use containers to isolate the agent in their own namespace, but they still share the host kernel. Some of the the recent kernel vulnerabilities resulted in privilege escalation (switching from regular user to root) suggesting that containers are not enough as a security boundary.

In the rest of this article, I describe how to use microVMs to easily sandbox coding agents on your Fedora Linux.

Exploring microVMs

First of all, let’s take a look at what microVMs are. Just like any VM, they have their own kernel, one per each microVM. Compared to traditional VMs they start in very short time (hundreds of milliseconds) but don’t offer all the features of full VMs.

This article explains usage of krun runtime for podman. This approach offers the same well-known workflow as containers, but simply runs every container as a microVM.

Start by installing the runtime:

dnf install crun-krun

To run a microVM, simply run podman with –runtime=krun in your terminal:

podman run --runtime=krun --rm -it fedora:44 /bin/bash

Things to watch out for

A microVM is not a regular container, so a few things might behave differently. First, allocate enough CPU and RAM with krun annotations. The defaults are too small and might result in OOM (Out Of Memory) kills. Second, make sure you have libkrun version >= 1.8. Older versions have a bug which prevents you from pressing Enter in your coding agent. Third, the microVM ignores the USER set in the Dockerfile and always boots as root. Either switch to the correct user manually or put the switch into an entrypoint script.

Case study: sandboxing Claude Code for a Python project

This section outlines a simple setup for a Python project managed by uv. It uses podman-compose to mount the project into the microVM. Compared to containers, this podman compose needs additional annotations for UID/GID translation, SELinux labeling, and HW resources. The final setup is very similar to what you would need for containers.

To install podman compose from official Fedora repositories, run:

dnf install podman-compose

The setup has 3 parts:

  • Dockerfile
  • docker-compose.yaml
  • entrypoint.sh

Dockerfile

As mentioned above, podman with krun runtime still runs containers, but spawns each of them in a microVM. This example container includes uv package manager, claude code and a few additional RPM packages. Define your own container based on your project dependencies and programming language.

Make sure to create an unprivileged user and use it for running the agent.

FROM fedora:44

ARG HOST_UID=1000
ARG HOST_GID=1000

# Create group and user matching host UID/GID
RUN groupadd -g ${HOST_GID} appuser && \
    useradd -u ${HOST_UID} -g ${HOST_GID} -m appuser

RUN mkdir -p /venv && chown appuser:appuser /venv
RUN mkdir -p /home/appuser/.claude && chown appuser:appuser /home/appuser/.claude

USER appuser

# Rarely-changing tooling. Kept above the dnf layer so editing the RPM list
# below does not invalidate (and re-run) these installs.
RUN curl -LsSf https://astral.sh/uv/install.sh | sh && \
    curl -fsSL https://claude.ai/install.sh | bash
USER root

# Frequently-changing RPMs. Kept last so adding a package only rebuilds from here down.
RUN dnf install git make vim free libpq-devel python3-devel gcc -y && \
    dnf clean all

COPY --chown=appuser entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

USER appuser
WORKDIR /app

# This is needed because entrypoint does not have .local/bin in the PATH
ENV PATH="/home/appuser/.local/bin:$PATH"
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/bin/bash"]

docker-compose.yaml

The compose file defines how to mount the project directory into the microVM. This is where most of the magic happens, because podman needs to translate UID/GID and manage SELinux labels, otherwise the files would not be accessible inside of the microVM or they would end up being owned by a different user.

services:
  claude:
    container_name: project-name-claude
    annotations:
      run.oci.handler: krun
      krun.ram_mib: "4096"
      krun.cpus: "4"
    user: "${HOST_UID}:${HOST_GID}"
    userns_mode: keep-id  # optional, for rootless host
    build:
      context: .
      args:
        HOST_UID: "${HOST_UID}"  # use UID and GID from the host so that files created in the container have correct permissions
        HOST_GID: "${HOST_GID}"
    volumes:
      - ../:/app:U,z  # bind mount your project
      - project-name-venv-cache:/venv:U,z
      - claude-config:/home/appuser/.claude:U,z  # persistent claude credentials/config
    working_dir: /app
    stdin_open: true
    tty: true
    environment:
      - CLAUDE_CONFIG_DIR=/home/appuser/.claude
      - UV_LINK_MODE=copy
      - UV_PROJECT_ENVIRONMENT=/venv/env  # This is inside the cached volume
      - UV_PYTHON_INSTALL_DIR=/venv/python  # So that uv-managed python installations are not in home but cached in /venv
      - TERM=xterm-256color
      - COLORTERM=truecolor

volumes:
  project-name-venv-cache:
  claude-config:
    external: true
    name: claude-config

There are 3 key parts:

  • annotations – these select krun as a runtime and specify HW requirements
  • user and userns_mode – this tells podman to translate UID/GID so that the files created in the microVM end up owned by your user on the host
  • volume labels – z tells podman to relabel the files with a shared SELinux label. Otherwise SELinux would prevent the process inside the microVM from touching the files in the volume. U tells podman to recursively chown all files.

entrypoint.sh

The entrypoint creates a virtual environment for the Python project, because we don’t want dynamic dependencies baked into the container image. It also runs the switch from root to regular user because podman with krun runtime ignores the USER directive from the container.

#!/bin/bash
set -e

echo "Sandbox started as user: $(id -un) in directory: $(pwd)"

if [ "$(id -un)" != "appuser" ]; then
  runuser -u appuser -- uv sync
  echo "Running ${@} as appuser"
  exec runuser -u appuser -- "$@"
fi

uv sync
exec "$@"

Run the setup

First, build the container:

$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml build
STEP 1/18: FROM fedora:44
...
Successfully tagged localhost/agent-sandbox_claude:latest

Then create the external volume and run the claude container interactively:

$ podman volume create claude-config
$ HOST_UID=$(id -u) HOST_GID=$(id -g) podman-compose -f .agent-sandbox/docker-compose.yaml run --rm claude
Sandbox started as user: root in directory: /app
Resolved 3 packages in 6ms
Checked 3 packages in 1ms
Running /bin/bash as appuser
tty: ttyname error: Inappropriate ioctl for device
[appuser@3bd1234b9a77 app]$

You can now check that the kernel is different by running uname -a inside of the microVM.

Putting it together: single script to create the whole setup

Creating the same setup manually for every project is not the greatest user experience, but you can automate the setup using a simple script like this. It installs a new sbx command that wraps the setup described above into 3 simple command options: init, build, and run.

A word of caution — microVM is not a bulletproof boundary

A microVM raises the bar considerably, but it is not perfect isolation, and it would be irresponsible to present it as such. Take a look at the libkrun git repository to read more about the security model.

If you want to run software that might be dangerous, prefer using a full VM or even cloud VM.

Conclusion

MicroVMs seem like a sweet spot for running AI Agents. They provide a familiar workflow of containers, but the agents run on their own kernel behind a hypervisor. This article describes workflow based on podman and krun runtime because Fedora Linux ships both of them natively, but there are plenty of other options available for any platform (for example dockersandbox).

Note about AI usage: I wrote this article myself. I used Claude (Anthropic) to significantly refine the grammar, wording, and sentence structure; the technical content and all claims are my own and tested.

Quand est-ce qu’on interdit les lunettes connectĂ©es ?

✇Framablog
By: Gee
15 June 2026 at 06:45

Bon. On pensait ĂȘtre dĂ©barrassĂ©s de ces saletĂ©s suite au flop des Google Glass, mais visiblement, ça revient Ă  la mode. Alors faisons le point


Quand est-ce qu’on interdit les lunettes connectĂ©es ?

💡 Aujourd’hui, on s’attaque Ă  un gros morceau : les lunettes connectĂ©es. Bon, le terme officiel, c’est « lunettes intelligentes », de l’anglais « smartglasses » calquĂ© sur « smartphone » 

Gee dit : « Mais moi, j'en ai marre qu'on nous colle de “l'intelligence” Ă  tout-va dans un monde numĂ©rique qui me semble de plus en plus stupide. Alors j'vais appeler ça des “lunettes connectĂ©es”. » On voit un homme avec des lunettes connectĂ©es. Une flĂšche indique « lunettes connectĂ©es », une autre « air con ».

⚠ Il y a 15 ans dĂ©jĂ , en 2011, Google lance les hostilitĂ©s avec les Google Glass.

Un type avec des lunettes dit : « Je peux filmer et enregistrer tout le monde d'un simple regard ! » La Geekette dit : « Mais c'est horrible ! » Le type répond : « Oui, mais c'est seulement 1500 $ et la batterie tient une heure en me cramant la tempe au passage ! Ceci est une révolution ! »

▶ Lorsque Google met fin Ă  l’expĂ©rimentation en 2015, aprĂšs un nombre de ventes ridicule, on croit le projet enterrĂ© dans la dĂ©charge du numĂ©rique oĂč viendront vite le rejoindre les NFT et le MĂ©tavers.

Mais c’est sans compter sur


Facebook en 2021.

Zuckerberg dit : « On lance les Ray-Ban Meta ! De la surveillance gĂ©nĂ©ralisĂ©e, oui, mais avec la classe ! En partenariat avec Ray-Ban – bah oui – et EssilorLuxottica* ! » La Geekette, faussement enthousiaste : « Euuh
 ouaaais
 yoopy  »

✷ La multinationale franco-italienne de la lunette. Ce qui nous permet de classer ce projet dans la catĂ©gorie « cacarico » : c’est caca, oui, mais c’est un peu français aussi !

💡 Au niveau technique, on reste sur du classique : camĂ©ras et microphones intĂ©grĂ©s, connexion au tĂ©lĂ©phone par Bluetooth, et Ă©videmment, stockage sur les serveurs de Facebook, dont on rappellera Ă  toutes fins utiles qu’ils sont soumis aux lois Ă©tatsuniennes comme le Patriot Act.

RĂ©sumĂ© du Patriot Act en termes juridiques simples. Cas 1 : vous ĂȘtes citoyen des États-Unis, on se torche avec votre vie privĂ©e. Cas 2 : vous n'ĂȘtes pas citoyen des États-Unis : pareil, mais on y va Ă  deux mains.

Une question se pose donc assez rapidement :

Quand est-ce qu’on interdit ces merdes ?

Un politicien rĂ©pond : « Mais non, les interdictions, c'est pour les pauvres qui font des rave parties ! Pour les multinationales, je propose plutĂŽt des pactes de responsabilitĂ© et des incitations fiscales Ă  n'ĂȘtre des pourritures que de maniĂšre plus occasionnelle. » Une flĂšche indique : rĂ©sumĂ© des politiques actuelles en termes juridiques simples.

⚠ Il n’y a AUCUN univers oĂč filer des lunettes connectĂ©es Ă  tout le monde, ça se passe bien.

Un type filme avec un smartphone en disant : « Aaah, les smartphones
 Avoir toujours une camĂ©ra dans la poche, quel plaisir pour filmer n'importe qui n'importe quand sans son consentement ! Dommage que ce soit si voyant. » Une femme passe en le remarquant : « Héé ! »

MĂȘme image, mais le type a des lunettes, les mains dans les poches. Il dit : « C'est mieux. » La femme passe sans s'en rendre compte.

⚠ LĂ , si on commence Ă  avoir des lunettes connectĂ©es un peu partout, on se lance sur un chemin dystopique Ă  un niveau hallucinant.

(Surtout si, comme pour les fameuses enceintes connectĂ©es, les lunettes filment et enregistrent un peu quand Facebook le veut, sans qu’on ait des masses de contrĂŽle sur les donnĂ©es et ce qui en est fait).

C’est la certitude, ou plutĂŽt l’incertitude – ce qui est presque pire – d’ĂȘtre filmĂ©, enregistrĂ© et analysĂ© en permanence.

Un type en cravate regarde une foule avec plein de lunettes et pense : « Un panoptique gĂ©nĂ©ralisĂ© et participatif
 quel pied ! »

D’ailleurs, le public ne s’y trompe pas : dans une Ă©tude de la CNIL, on apprend que deux tiers des sondĂ©s trouvent que c’est un risque pour la vie privĂ©e.

Le smiley commente : « Moi j'pense que le dernier tiers avait pas compris la question. »

▶ Pour les lunettes connectĂ©es comme pour l’IA gĂ©nĂ©rative, on aimerait voir les mĂȘmes prĂ©cautions que pour le clonage humain, rapidement interdit aprĂšs la naissance de Dolly, la premiĂšre brebis clonĂ©e en 1997.

1997. On voit la brebis taguĂ©e « Dolly », un homme rĂ©agit : « Quelle horreur ! Ça pose trop de problĂšmes Ă©thiques, on va lĂ©gifĂ©rer ! » 2022. Deux brebis taguĂ©es « ChatGPT qui pousse les gens au suicide », « Grok qui gĂ©nĂšre de la pĂ©dopornographie et des deep fakes », avec des lunettes connectĂ©es sur leurs visages. L'homme, extatique : « Quelle rĂ©volution ! Cramons nos derniĂšres chances d'attĂ©nuer le dĂ©rĂšglement climatique pour encourager ça ! »

⚠ Rappelons que le mantra de Facebook a longtemps Ă©tĂ© « move fast and break things », ce qui signifie donc « bouger vite et casser des trucs ». En gĂ©nĂ©ral, quand quelqu’un annonce ses intentions aussi clairement, on ne lui dĂ©roule pas le tapis rouge.

Un loubard avec une barre-Ă -mine dit : « Bonjour, je viens tout pĂ©ter. Votre vie privĂ©e, vos capacitĂ©s cognitives, votre Ă©quilibre social et vos rythmes de vie. » En face, un politicien rĂ©pond : « Euuh  » Le loubard dit : « Mais c'est pour le progrĂšs technologique. » L'autre : « Ah ! Ça va alors. »

Ceci dit, ne soyons pas totalement nĂ©gatifs, il reste un peu d’espoir, notamment du cĂŽtĂ© de l’Union europĂ©enne :

le RĂšglement sur l’intelligence artificielle, par exemple, enquiquine pas mal Meta et compagnie sur la question de l’exploitation des donnĂ©es des lunettes par IA.

Zuckerberg dit : « Rooh, du coup on n'a pas pu sortir la version avec Ă©cran intĂ©gré ! On n'aime pas l'innovation, chez ces arriĂ©rĂ©s d'europĂ©ens ! » Gee prĂ©cise : « Y'a aussi la prĂ©sence de batteries amovibles et remplaçables sur les appareils technologiques que l'UE va bientĂŽt commencer Ă  imposer, et que les Ray-Ban Meta n'ont pas. » Zuckerberg : « Boarf, on va plancher sur une batterie amovible, si y'a que ça pour vous amadouer  »

💡 Ces rares freins sont un dĂ©but, mais restent timides par rapport Ă  l’ampleur du problĂšme. Connaissant l’historique des GAFAM, est-ce que ce sera vraiment suffisant ?

Les GAFAM disent : « Contourner des lĂ©gislations  »  «   par des dĂ©tails techniques ? » « Tout en payant des millions en lobbying intensif  » «   pour orienter les lĂ©gislations suivantes ? » « C'est vraiment pas notre genre ! »

⚠ Ce serait donc pas mal de ne pas trainer pour lĂ©gifĂ©rer sur les objets de surveillance gĂ©nĂ©ralisĂ©es que sont ces lunettes connectĂ©es : pour une fois, on pourrait avoir un cadre lĂ©gal contraignant et protecteur (pour nous) en amont du bazar.

Le loubard arrive et dit : « Bonjour, je viens tout pĂ©ter. Je
 HÉÉÉÉ ! oĂč est ma barre-Ă -mine ?! » Un type avec une casquette UE la tient derriĂšre lui en disant : « ConfisquĂ©e ! » Note : BD sous licence CC BY SA (grisebouille.net), dessinĂ©e le 8 juin 2026 par Gee.

Sources :

Crédit : Gee (Creative Commons By-Sa)

❌