FoundationDB made this idea famous. Instead of relying only on unit tests and real-cluster end-to-end tests, it runs distributed workloads inside a simulated world where time, network faults, process failures, and scheduling decisions can be explored and reproduced from a seed. TigerBeetle pushed a complementary discipline: make invariants part of the code, assert the shape of the state continuously, and turn silent corruption into loud local failures.

At Clever Cloud, we have been applying that direction to Rust infrastructure software. Moonpool, developed by Pierre Zemb, gives Rust systems a deterministic simulation environment where time, networking, tasks, randomness, and storage can be virtualized behind provider traits. Magnetar is where we apply that approach to a client for Apache Pulsar. This is also the approach that we are taking in Sōzu.

Magnetar is a from-scratch Apache Pulsar client driver in Rust. It is built around a sans-io protocol core, a production Tokio engine, and a Moonpool engine for deterministic simulation. This first public release is meant for engineers who want to try Magnetar, evaluate the architecture, compare behavior with existing Pulsar clients, and help shape a stronger Rust-native Pulsar ecosystem.

The goal is not only to expose a Rust API around Pulsar. The goal is to build a client whose difficult behavior can be inspected, replayed, and made to fail before production gets the chance.

A Pulsar client is part of the distributed system

It is tempting to think about a client library as the easy side of a distributed system. The broker is where replication, storage, ownership, and coordination live. The client only connects, sends messages, receives messages, and acknowledges them.

That view does not survive contact with a real Apache Pulsar client.

A serious Pulsar client has to manage producers, consumers, readers, partitioned topics, multi-topic consumers, pattern subscriptions, transactions, schemas, authentication, proxy routing, broker lookup, cluster failover, reconnect, backoff, batching, chunking, ack grouping, unacked-message tracking, negative acknowledgements, retry-letter and dead-letter flows, observability, and a long list of Pulsar Improvement Proposals.

Many of the hard bugs are not about one command being encoded incorrectly. They are about time and ordering. A broker drops while a publish is in flight. A reconnect happens while a consumer has pending acknowledgements. A token refresh races with a session reset. A proxy lookup points to a new broker while the old connection is still draining. A topic migrates and the client must rebuild enough state to continue without pretending the old session still exists.

That means a Pulsar client is not just a convenience wrapper around a socket. It is part of the distributed system. It owns state that has to remain coherent while the world around it changes.

If that state is hidden inside runtime tasks, channel queues, implicit clocks, and timing accidents, then the client becomes hardest to reason about exactly when precision matters most. Magnetar starts from the opposite assumption: make the protocol state explicit, drive it through narrow boundaries, and keep the I/O outside.

From the Rust Pulsar ecosystem to Magnetar

Magnetar comes from experience with the Rust Pulsar ecosystem, including maintaining and using pulsar-rs. That work matters. It gave Rust users an Apache Pulsar client and created the practical context in which the next generation of driver work could be evaluated.

Magnetar is not an article-length criticism of what existed before it. It is a continuation of the same ecosystem from a different architectural starting point. After spending time with real Pulsar usage, the shape of the next step became clearer: a Rust Pulsar driver should make the protocol/runtime boundary sharper, make difficult behavior reproducible, track parity explicitly, and make testability a first-class design constraint.

That is why Magnetar does not begin with the public builder API. It begins with the protocol.

The user-facing API matters, and the first release already exposes a broad surface. But for a distributed client, the deeper question is what happens underneath that API when the broker moves, the connection drops, the clock advances, a timeout fires, a subscription is rebuilt, or the same trace is replayed under a different runtime.

The sans-io core

The heart of Magnetar is magnetar-proto. It is a synchronous protocol state machine. It has no sockets. It does not depend on Tokio. It does not spawn tasks. It does not use async. It does not read the host clock on the protocol hot path.

Its shape follows the same broad idea that made quinn-proto influential in the Rust networking world: feed bytes in, poll bytes out, poll semantic events, and ask the state machine when its next timer expires.

Conceptually, the interface looks like this:

> connection.handle_bytes(now, bytes);

connection.poll_transmit(&mut out);
connection.poll_event();
connection.poll_timeout();

That small shape is a large architectural choice.

handle_bytes lets an engine feed wire bytes into the state machine. poll_transmit drains outbound frames. poll_event yields semantic events that the runtime must react to, such as authentication challenges, lookup outcomes, checksum mismatches, reconnect signals, or protocol-level transitions. poll_timeout lets the runtime ask when to wake the state machine again.

The state machine does not decide where bytes come from. It does not know whether the network is a real TCP stream, a TLS stream, a byte pipe inside a simulator, or a scripted broker in a differential harness. It does not decide what "now" means. The engine passes time in.

The public traits in magnetar-proto follow the same rule. They are not runtime services hidden behind async callbacks. They are small protocol contracts at the points where the state machine needs a decision or a transformation: AuthProvider produces authentication bytes, Schema defines encoding, decoding, schema data, and broker-resolved schema hooks, MessageEncryptor and MessageDecryptor describe payload crypto over bytes and message metadata, ServiceUrlProvider exposes the current service URL for failover, and HealthProbe uses a poll-style contract instead of binding the protocol crate to an async runtime. The pattern is deliberate: the protocol core can ask for facts, bytes, or readiness, while the I/O, caching, refresh logic, network probes, and scheduler stay outside.

This separation is not just a clean layering exercise. It is what makes the protocol testable without a broker, without a socket, and without an async runtime. A protocol bug can be reduced to a fixture: feed these bytes at this instant, poll these outputs, assert this event stream, and replay the same sequence again.

For an Apache Pulsar client, that matters because the wire protocol is not only a happy path. It includes producer creation, consumer subscription, acks, nacks, transactions, broker errors, redirects, authentication challenges, topic migration, replicated-subscription markers, schema metadata, batching, chunking, and close paths. Each of these has state. Each state transition is easier to reason about when it is not mixed with socket reads, task scheduling, and runtime-specific wakeups.

No channels as an architectural constraint

Magnetar also makes an unusual Rust async choice: channel primitives are banned from the workspace.

The straightforward architecture for a network client is often producer future to channel, channel to driver task, driver task to channel, channel to consumer future. That can work, but it spreads state across queues and tasks. Backpressure becomes implicit. Close semantics become library-specific. Dropped futures can leave messages stranded in places that are hard to inspect. The debugging question becomes "where did this message go?"

Magnetar uses a different pattern. State lives inside the protocol state machine and the runtime-owned shared connection. User-facing futures register wakers in slabs keyed by operation identifiers. The driver owns the I/O loop, feeds bytes into the state machine, drains outbound frames, and wakes the matching futures as outcomes arrive.

This is not an aesthetic ban on channels. It is a way to keep ownership of state explicit. When the driver rebuilds producers after a reconnect, when a consumer waits for a message, when an ack outcome is delivered, or when a pending operation fails because a session is gone, the relevant state is in the state machine and can be inspected there.

That design has trade-offs. It puts more pressure on the correctness of the state machine. It requires careful lock ordering. It requires reviewers to understand waker registration and wakeup paths. But it also makes the behavior much easier to simulate, replay, and compare across runtimes.

Two engines, one state machine

Magnetar ships two engines that drive the same protocol core.

The default engine is magnetar-runtime-tokio. It is the production execution path: TCP, TLS through tokio-rustls, driver tasks, real time, real sockets, and the public PulsarClient surface most users will reach first.

The second engine is magnetar-runtime-moonpool. It drives the same magnetar-proto::Connection state machine through Moonpool providers. Instead of baking in the runtime, Moonpool exposes provider traits for networking, time, task spawning, randomness, and storage. Under a production-style provider bundle, the engine can run against real I/O. Under simulation providers, those same categories can be virtualized.

This is where deterministic simulation becomes practical. The client can be driven in a world where time advances under control, network delivery can be reordered or interrupted, tasks run under a deterministic scheduler, randomness is seeded, and failures can be replayed from the same seed.

Moonpool is not a mock. A mock usually replaces a component with simplified behavior. That is useful for many unit tests, but it is not the same thing as exercising a real client through hard interleavings.

Moonpool is also not a normal end-to-end test. An e2e test runs the real system, which is essential, but it usually runs with real time, real networking, and failures that are difficult to reproduce once the timing has moved on.

Moonpool sits in a different space. It keeps the client code close to the real execution path while virtualizing the providers that make distributed behavior hard to reproduce. The point is not to avoid e2e tests. The point is to add a regime where failures are not anecdotes. They become seeds.

Magnetar's Moonpool engine uses the same protocol state machine as the Tokio engine. The TLS path is also driven in a way that preserves the simulation boundary: instead of relying on tokio-rustls, the Moonpool engine drives rustls::ClientConnection over the byte pipe directly. That keeps TLS handshakes under the same deterministic control as the rest of the simulated network.

Differential testing: making the engines agree

Two engines are useful only if they do not silently become two different clients.

Magnetar therefore includes a differential harness. It runs a trace, such as connect, open producer, send, subscribe, receive, ack, seek, and close, against both the Tokio and Moonpool engines, then compares the user-visible event streams.

This matters because the Moonpool engine is used to find bugs that are difficult to expose with real time and real sockets. For that to be meaningful, the simulated engine must remain observationally aligned with the production engine at the user boundary.

If Tokio and Moonpool drift, the simulator becomes less trustworthy. If the differential harness keeps them aligned, then a seed failure in the simulated world is much more likely to point at a real property of the client, not a separate test-only implementation.

This is also why Magnetar's validation policy is strict about cross-runtime coverage. Behavioral changes are expected to exercise the sans-io layer, the Tokio runtime, the Moonpool runtime, differential equivalence, and the e2e surface when applicable. That is more work than adding one unit test. It is also the cost of making deterministic simulation a real engineering tool rather than a side experiment.

Java parity as a credibility contract

Simulation is not a substitute for feature breadth. It is what makes feature breadth less fragile.

Apache Pulsar has a mature Java client, and for many users that client defines what "a Pulsar client" means. Basic produce and consume are not enough. A credible client must cover the behaviors applications rely on: batching, compression, transactions, schemas, partitioned topics, multi-topic and pattern consumers, retries, dead-letter flows, authentication providers, proxy support, failover, admin operations, and the PIPs that shape modern Pulsar usage.

Magnetar tracks Java-client parity as a public contract. The README carries the parity matrix and the engine-by-engine status. The article does not need to reproduce that matrix, but the matrix itself is important. It gives users a way to evaluate the project as a Pulsar client, not as a narrow experiment around one happy path.

This is the reason Magnetar's first public release is broader than a minimal demo. It includes the protocol foundation, the public facade, runtime engines, admin support, authentication providers, message crypto, CLI work, observability hooks, and a growing list of PIP surfaces.

The exact reason for tracking parity is simple: users do not choose a client library only because its internal architecture is elegant. They choose it because it can represent the system they actually run. Architecture makes that surface maintainable. Parity makes it useful.

Beyond produce and consume

The phrase "Pulsar client" can hide a lot of surface area. From the outside, the first examples usually look small: build a client, create a producer, send a payload, subscribe with a consumer, receive a message, acknowledge it. Those examples are useful because they show the entry point. They are not enough to evaluate the client.

Real Pulsar applications depend on behaviors that only appear after the first demo works. A producer may need batching, compression, chunking, access modes, sequence ids, send timeouts, per-message properties, transactions, interceptors, and latency statistics. A consumer may need batch receive, cumulative acknowledgements, batch-index acknowledgements, nack backoff, ack timeout handling, retry topics, dead-letter topics, seek, pause/resume, subscription modes, and per-partition behavior. Applications with strict schemas need Avro, JSON, Protobuf, Protobuf-native, KeyValue, primitive schemas, and broker-side schema lookup semantics. Deployments with security requirements need token auth, mTLS, OAuth2, SASL, Kerberos/GSSAPI, Athenz, TLS provider choices, and a way to reason about crypto behavior without making every build drag every provider.

Those features are not independent checkboxes. They interact. Batching interacts with compression and send timeouts. Chunking interacts with sequence ids and redelivery. Transactions interact with acknowledgements. Reconnect interacts with producers, consumers, lookups, proxy routing, and failover. Observability has to describe the behavior without leaking secrets or flooding operators under churn.

That is why Magnetar's feature work and architecture work are tied together. The more complete the surface becomes, the more important it is that the protocol state is explicit and that the runtime boundary is narrow. A broad client built on accidental state becomes harder to maintain as it becomes more useful. A broad client built on replayable state gives maintainers a better chance to keep feature growth from turning into hidden behavior.

Validation as architecture

Magnetar's test strategy is intentionally layered because each layer catches a different class of bug.

The sans-io layer lets protocol behavior be tested without sockets or async tasks. The project testing documentation currently records more than 270 unit tests in magnetar-proto. Those tests exercise the state machine directly: bytes in, events out, transmit buffers out, state transitions checked.

Runtime integration tests exercise the glue that pure protocol tests cannot cover. The Tokio engine and Moonpool engine each have their own integration surfaces, and the project enforces runtime parity so one engine does not quietly fall behind the other.

The deterministic chaos pack targets the failure schedules that motivated the architecture in the first place: reconnect, failover, virtual-clock timers, TLS handshake ordering, in-flight publishes, broker migration, and adversarial network behavior. The Moonpool engine documentation describes a daily Moonpool seed sweep with 128 freshly rolled random seeds in parallel. The number is less important than what it represents: the client is being driven through schedules that a human would not write by hand.

Differential equivalence tests compare the two runtime worlds. They ask a direct question: if the same trace is run through Tokio and Moonpool, does the user see the same behavior?

End-to-end tests still matter. They keep Magnetar honest against a real Apache Pulsar broker. Simulation can make failures reproducible, but it does not replace compatibility with the system users actually deploy.

Taken together, these layers are not ceremony. They are part of the architecture. The point is not to collect large test numbers. The point is to put validation pressure exactly where distributed clients fail: protocol state, runtime boundaries, reconnect logic, timing, equivalence, and real broker behavior.

What reproducibility changes in practice

The practical value of deterministic simulation is not that it makes tests more sophisticated. It changes the debugging loop.

When a traditional end-to-end test fails because of timing, the first question is often whether the failure is reproducible at all. If it is not, engineers start adding sleeps, logs, larger timeouts, or retry loops. Some of those changes are useful. Many of them only move the failure somewhere else. The failure remains a story: "we saw it once in CI".

With a deterministic simulation, the failure should become an artifact. The artifact is a seed, a trace, and a state transition that can be replayed. The question changes from "can we make it happen again?" to "what invariant did this schedule violate?"

That difference matters for a client library. Client bugs often sit at the boundary between user code and the broker. They are easy to misattribute. A publish can fail because the broker closed the connection, because the client lost an outcome, because the reconnect path rebuilt the producer too late, because an ack was delivered to the wrong waiter, because a timeout fired against stale session state, or because the runtime task died after the protocol had already transitioned.

If all of that behavior is spread across tasks, channels, timers, and sockets, a failure report is hard to compress. If the protocol state machine is explicit, the runtime boundary is narrow, and the same sequence can be replayed under controlled providers, the report can become much smaller: this seed, this trace, this event order, this invariant.

That is why Magnetar treats reproducibility as part of the client design. The point is not only to catch more bugs. The point is to make the bugs that do appear cheaper to understand and safer to fix.

It also changes code review. A reviewer can ask whether a behavior is covered at the right layer. Is this a pure protocol transition? Then the sans-io test should feed bytes and assert events. Is it runtime glue? Then Tokio and Moonpool need equivalent coverage. Is it an observable behavior shared by both engines? Then the differential harness should compare the event streams. Is it broker compatibility? Then an e2e test should touch a real Pulsar broker.

Those questions are more precise than "did we add tests?" They connect the test to the failure model.

What to inspect first

For engineers reading Magnetar for the first time, the best entry point is not a single file. It is the relationship between the documents and the code.

The README gives the public surface: what the client exposes, which features are implemented, how the Java-client parity matrix is tracked, which PIPs are supported, and how the two engines are positioned. That is the user-facing contract.

The architecture document explains the shape underneath that contract. It shows the crate topology, the dependency direction, the sans-io boundary, the driver loop, the event model, the producer and consumer paths, the runtime engines, TLS sites, schemas, PIP coverage, and the validation strategy. That is the system map.

The ADR series explains why the system has this shape. ADR-0004 records the sans-io split. ADR-0003 records the no-channels rule. ADR-0011 records clock injection. ADR-0010 records the Java parity decision. ADR-0019 records how the production Tokio engine and the Moonpool engine relate to the parity goal. ADR-0024 records the cross-runtime testing policy.

This matters because Magnetar is intentionally not only a code drop. It is a set of engineering decisions with a public audit trail. If you disagree with the design, the ADRs give you the right surface to discuss. If you want to contribute a feature, the parity matrix and validation policy tell you what "done" means. If you want to evaluate the simulation work, the Moonpool engine documentation and the differential harness show how the same protocol core is driven in different worlds.

The first release should therefore be read in two ways. As a Pulsar user, look at the client surface and the parity matrix. As a Rust infrastructure engineer, look at the state-machine boundary and the simulation strategy. The interesting part of Magnetar is that both views are meant to reinforce each other.

What the first public release gives you

This first public release is a technical entry point. It is for engineers who want to try Magnetar, read the architecture, inspect the ADRs, compare behavior with existing Pulsar clients, and help shape the Rust-native Pulsar ecosystem.

The high-level client API starts with the usual shape:

let client = PulsarClient::builder()
    .service_url("pulsar://localhost:6650")
    .build()
    .await?;

let producer = client
    .producer("persistent://public/default/orders")
    .create()
    .await?;

That API is important because the client must be usable. But the release is also an invitation to inspect the lower layers. Read the README for the feature matrix. Read the architecture document for the sans-io design. Read the ADRs for the decisions behind no channels, swappable engines, clock injection, Java parity, Moonpool parity, TLS provider choices, and cross-runtime validation. Read the Moonpool engine documentation if you are interested in how deterministic simulation can be applied to a real network client.

The important point for this article is the direction: Magnetar is public so engineers can evaluate both the client surface and the engineering model behind it.

The inaugural technical entry point is available via v1.0.0, while the current state of the driver can be tracked in the v1.2.0 release. 

Why this matters beyond Magnetar

Magnetar is an Apache Pulsar client. It is also a concrete example of how we want to build more Rust infrastructure software.

Distributed systems fail through state transitions. Some of those transitions are obvious and easy to test. Many are not. They happen when time advances in an unlucky place, when a retry overlaps with a close path, when a broker drops a connection after accepting part of the session, when a callback is registered just after a notification, or when a reconnect path rebuilds one handle but not another.

You can try to chase those bugs after they happen. Sometimes that is unavoidable. But the architecture can make the chase easier or harder.

A client with a pure protocol core, explicit events, injected time, replaceable I/O, deterministic seeds, and cross-runtime comparison gives engineers better tools. It lets them reduce a failure to a trace. It lets them replay that trace. It lets them ask whether a simulated failure corresponds to the production runtime. It lets them add an invariant where a silent state drift used to hide.

That is the direction Magnetar takes. Make the protocol explicit. Make the runtime replaceable. Make failures reproducible. Make correctness something the code has to demonstrate continuously.

Thank you to Pierre Zemb for Moonpool and for pushing this deterministic-simulation direction in Rust, and to the contributors and maintainers in the Rust Pulsar ecosystem whose work made the next step possible.

Magnetar is open source. The code, architecture notes, ADRs, and documentation live at github.com/CleverCloud/magnetar.

References

Magnetar

• Magnetar repository. Public Rust Apache Pulsar client repository. https://github.com/CleverCloud/magnetar
• Magnetar README. Public feature surface, Java client parity matrix, supported PIPs, engine coverage, and status. https://github.com/CleverCloud/magnetar/blob/main/README.md
• Magnetar architecture. Sans-io rationale, crate topology, driver loop, protocol state machine, and tests. https://github.com/CleverCloud/magnetar/blob/main/ARCHITECTURE.md
• Magnetar documentation index. Moonpool engine, testing, CLI, observability, logging, PIP features. https://github.com/CleverCloud/magnetar/blob/main/docs/README.md
• Moonpool engine documentation. Deterministic-simulation engine, chaos pack, differential harness, provider model. https://github.com/CleverCloud/magnetar/blob/main/docs/moonpool-engine.md
• Testing documentation. Test categories and validation commands. https://github.com/CleverCloud/magnetar/blob/main/docs/testing.md
• ADR-0004. Sans-io magnetar-proto and swappable I/O engines. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0004-sans-io-protocol-core.md
• ADR-0010. Full Java-client parity scope. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0010-v0-1-full-java-parity.md
• ADR-0024. Cross-runtime test and coverage policy. https://github.com/CleverCloud/magnetar/blob/main/specs/adr/0024-cross-runtime-test-and-coverage-policy.md

Ecosystem

• pulsar-rs. Existing Rust Apache Pulsar client project. https://github.com/streamnative/pulsar-rs
• Apache Pulsar. Distributed messaging and streaming platform. https://pulsar.apache.org/
• Apache Pulsar Java client. Reference client surface for many Pulsar users. https://pulsar.apache.org/docs/

Deterministic simulation

• FoundationDB testing. Deterministic simulation and fault injection lineage. https://apple.github.io/foundationdb/testing.html
• TigerBeetle TigerStyle. Assertion-first engineering style. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md
• TigerBeetle VOPR. Simulation testing approach. https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/internals/vopr.md
• Moonpool repository. Deterministic simulation for Rust systems, developed by Pierre Zemb. https://github.com/PierreZ/moonpool
• moonpool-sim. Simulation engine crate for Moonpool. https://crates.io/crates/moonpool-sim

Animé par : Horacio GONZALEZ
Avec la participation de :
- Matthieu VINCENT
- Yannick GUERN
- Yohann VINEZ

Episode enregistré le 15 septembre 2025

Chapitrage et Liens

00:00:16 - Présentation des invités

00:03:16 - Communautés Tech dans une ESN comme Sopra

00:04:46 - Yannick et les casques VR - Metaquest
OpenXR - https://www.khronos.org/OpenXR 
https://learn.microsoft.com/fr-fr/windows/mixed-reality/develop/native/openxr  
Utiliser la VR dans Godot - https://docs.godotengine.org/fr/4.x/tutorials/xr/setting_up_xr.html 

00:14:33 - Vous ne devriez pas acheter vos AirPods Pro 3 en Europe
https://www.numerama.com/tech/2071103-vous-ne-devriez-pas-acheter-vos-airpods-pro-3-en-europe.html 

00:20:06  - Utilisation malencontreuse d’IA dans la maintenance des bibliothèques Rust 
https://x.com/davidtolnay/status/1883906113428676938

00:35:06 - Investissement MistralAI par ASML 
https://x.com/AlainGoudey/status/1964939896243511656
https://www.clubic.com/actualite-579064-vous-pensiez-le-rgb-surfait-ces-barrettes-de-ram-arrivent-avec-un-ecran-oled.html 
https://www.techradar.com/ai-platforms-assistants/chatgpt/the-models-are-really-devious-sam-altmans-hardware-chief-says-openai-wants-kill-switches-built-into-hardware-in-case-things-go-wrong 

00:42:00 - Les modèles d'Anthropic s'invitent dans Microsoft 365
 https://www.lemondeinformatique.fr/actualites/lire-les-modeles-d-anthropic-s-invitent-dans-microsoft-365-97856.html

00:44:16 - Les outils inutiles mais marrants
https://github.com/mmulet/term.everything : une GUI dans le terminal
https://github.com/leaningtech/webvm/ : une VM linux dans ton navigateur (utile pour quand on fait des slides “as-code”)
https://github.com/sanaysarthak/git-laugh-track : des rires qd tu commites#142 -  Un titre à trouver

00:48:22 - Musique de fin – OST Clair Obscur: Expedition 33
https://www.youtube.com/watch?v=zmvsw2ILX5k

Animé par Julien Durillon - @juuduu
avec la participation de :

• Arnaud Lefebvre - @blackyoup
• Agathe - @agathe
• Adrien Mahieux - @saruspete

Épisode enregistré le 25 septembre 2024

Chapitrage et Liens

00:01:46 : Mais c’est quoi Kernel Recipies  ?
https://kernel-recipes.org

00:06:27 : Nos confs préférées

• Structures des données pour être efficace dans le cache line : https://kernel-recipes.org/en/2024/schedule/assisted-reorganization-of-data-structures/
• https://kernel-recipes.org/en/2024/schedule/how-cern-serves-1eb-of-data-via-fuse/
• Comment l’association Linux est devenue un CNA : https://kernel-recipes.org/en/2024/kernel-and-security/
• https://kernel-recipes.org/en/2024/schedule/case-study-concurrent-counting/
• https://kernel-recipes.org/en/2024/virtme-ng/
• Lire /proc/meminfo https://kernel-recipes.org/en/2024/schedule/all-your-memory-are-belong-to-whom/
• https://kernel-recipes.org/en/2024/schedule/preempt_rt-over-the-years/

00:29:55 : Présentation sched_ext
Écrire un scheduler en bpf pour tester des nouveautés
Ça arrivera dans la 6.12

6.11
00:35:22 : Plein de nouveautés RISC-V
Support de rust en 6.10
Mem hotplug 6.11
00:42:50 : Agner table (un pdf)
00:42:31 : io_uring: bind/listen sur un port
00:44:08 : Sloppy logic analyzer
Un analyzer logique du pauvre, un peu pourri, mais c’est là
Ça permet de debug un système à distance, avec du GPIO

00:48:40 : NULL blk, un driver block en rust pour amorcer la pompe
Ça permet de tester ses applis qui écrivent en block
00:54:00 : Version min 1.78 et on peut compiler avec rust 1.80
00:56:00 : Musique de fin : Katy Perry - I kissed a girl - https://www.youtube.com/watch?v=tAp9BKosZXs

Animé par Horacio Gonzalez - @LostInBrittany
avec la participation de :

• Sylvain Wallez - @bluxte
• Emmanuel Bosquet - @EmmanuelBosquet
• Erwan Rougeux - @ERougeux

Épisode enregistré le 19 août 2024

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Chapitrage & Liens

00:00:16 : Introduction et présentation des participants

00:03:00 : Debug machine à laver
https://x.com/bluxte/status/1824857486811103239
https://www.ifixit.com/ - IFixIt

00:16:38 : Home Assistant 2024.08 :
https://www.home-assistant.io/blog/2024/08/07/release-20248/ - LLAMA 3.1 support
https://www.openhomefoundation.org/ - passage en foundation
https://esphome.io/ - ESPHome
https://github.com/visualapproach/WiFi-remote-for-Bestway-Lay-Z-SPA - hack du SPA pour home assistant

00:38:43 : Proton evolve to a non profit foundation :
https://proton.me/blog/fr/proton-non-profit-foundation

00:44:48 : Root cause analysis Crowdstrike - Est-ce que Rust aurait pu l’éviter ?
https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/

00:53:16 : Musique de fin : Popcorn
https://youtu.be/Yx0KBLFG8qc?si=mN0FTpAACWrPbW1K

Animé par Horacio Gonzalez - @LostInBrittany
avec la participation de :

• Julien Briault - @ju_hnny5
• Lisa Carrier - @Lisaa_cr
• Florentin Dubois - @FlorentinDUBOIS

Épisode enregistré le 25 juillet 2024

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Chapitrage

00:00:16 : Introduction et présentation des participants

00:02:13 : Formation de Lisa et le hacking éthique
https://www.utt.fr/formations/diplome-d-ingenieur/reseaux-et-telecommunications
https://www.linkedin.com/company/hackutt/posts/?feedView=all

00:05:45 : Un outil pour éviter les leaks de secrets
https://github.com/gitleaks/gitleaks

00:08:15: Un outil pour scanner les ports
https://github.com/RustScan/RustScan

00:10:33 : regreSSHion : une faille critique dans OpenSSH touche des millions de serveurs
https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

00:12:56 : Arx, un outil écrit en Rust (aussi) pour remplacer Tar
https://github.com/jubako/arx
Performance : https://github.com/jubako/arx?tab=readme-ov-file-performance
CoreUtils en Rust : https://github.com/uutils/coreutils

00:18:06 : Cloudflare : un nouvel outil gratuit empêche les robots de siphonner le contenu des sites web pour entraîner des IA
https://www.zdnet.fr/actualites/cloudflare-un-nouvel-outil-gratuit-empeche-les-robots-de-siphonner-le-contenu-des-sites-web-pour-entrainer-des-ia-394241.htm

00:22:09 : Stack Overflow Annual Developer Survey
https://stackoverflow.blog/2024/07/24/developers-want-more-more-more-the-2024-results-from-stack-overflow-s-annual-developer-survey/

00:25:45: OVHcloud, Managed Rancher Service
https://blog.ovhcloud.com/how-to-create-a-kubernetes-cluster-in-a-local-zone-through-managed-rancher-service/

00:29:18 : Illiad recherche un acquéreur pour racheter 49% du capital de sa filiale de centres de données OpCore
https://www.universfreebox.com/article/567767/iliad-met-en-vente-49-de-ses-data-centers-pour-reduire-sa-dette

00:32:25 : Chrome, ability to turn off sharing of third party
https://www.theverge.com/2024/7/22/24203893/google-cookie-tracking-prompt-ad-targeting-privacy-sandbox

00:35:12 : Apple Maps sur le Web en version Bêta
https://x.com/theapplehub/status/1816189777693270332?s=46&t=TTwUj4NwwFWNozryQD5j4Q
https://www.openstreetmap.org/

00:37:11 : Lancement produit chez Ubiquity : Cloud Gateway Max
https://9to5mac.com/2024/07/16/ubiquiti-launches-new-cloud-gateway-max/
https://www.reddit.com/r/Ubiquiti/comments/1aoicwx/playing_snake_on_etherlighting_switch/

00:41:59 : Security overview dashboard (la suite logique de dependabot)
https://github.blog/changelog/2024-07-19-security-overview-dashboards-secret-scanning-metrics-and-enablement-trends-reports-are-now-generally-available

00:42:54 : Dgraph, back to basics
https://dgraph.io/blog/post/what-is-acid-transaction/
https://dgraph.io/blog/post/clustering-database/
https://dgraph.io/blog/post/leiden-clustering/
https://dgraph.io/blog/post/what-is-vertical-scaling/

00:46:55 : Cillium v1.16.0
https://github.com/cilium/cilium/releases/tag/v1.16.0

00:48:30 : Musique de fin
https://www.youtube.com/watch?v=fYpT1XGy250&pp=ygUcaW5mbHVlbmNldXIgYXNjZW5kYW50IHZpZXJnZQ%3D%3D

Animé par Quentin ADAM - @waxzce
avec la participation de :
Anaïs Vivion - CEO de Beapp et Présidente de French Tech Nantes
Denis Germain - Senior Lead SRE - Deezer - @zwindler
Nathan Ménard - CEO de Drakkar - @n_menard

Épisode enregistré le 16 janvier 2024 au Palace de Nantes

Coordination : Carine GUILLEMET
Cadreur : Lucas PARISET
Réalisation : Yann BRESSON
Moyens Techniques : Smartmedias

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Chapitrage

00:00:00 Introduction et présentation des invités

00:03:00 Quatre statements (ou presque...) pour résumer 2023 : 1- on est tous passés au Metavers

00:05:17 : 2- Le feuilleton Open AI

00:05:42 : 3- X / Twitter, c'était mieux avant...

00:09:05 : 4- Tout le monde a compris le projet de loi SREN

00:10:16 Regards croisés sur 2023 : L'essor de ChatGPT et des IA génératives

00:16:00 La course à la rentabilité pour 2024 dans la Tech

00:22:40 GreenTech : L'impact des stratégies numérique responsable

00:28:45 L'innovation de l'année : l'IA - Regards croisés

00:38:24 Souveraineté technologique

00:41:47 Les tendances à venir pour 2024 : La fin des stagiaires ?

00:45:50 2024, l'année Rust

00:48:42 L'IA et Clever ?

00:49:24 Le déclin des ESN

00:51:20 Des robots intelligents

00:52:40 L'IA, un destin comparable à celui des NFT ?

00:54:45 Recrudescence d'incidents de sécurité

00:55:45 Les élections américaines

00:59:10 Le retour de PhP dans le top du WEB

01:00:10 La curation des IA par l'IA

01:02:05 Manipulations de masses avec les élections à venir

01:05:50 Questions / Réponses avec le public - Le désenchantement du software ?

Animé par Jean-Baptiste KAISER - @ArendSyl
avec la participation de :
- Guillaume ASSIER : @GuillaumeAssier
- Eloi DEMOLIS : @Wonshtrum
- Sylvain WALLEZ : @bluxte

Épisode enregistré le 7 novembre 2023

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Chapitrage et liens

00:01:52 Google/YouTube et la pub
https://andadinosaur.com/youtube-s-anti-adblock-and-ublock-origin
et https://www.theverge.com/2023/10/27/23934961/google-antitrust-trial-defaults-search-deal-26-3-billion

00:10:43 Facebook et Instagram payants en Europe ?
https://about.fb.com/news/2023/10/facebook-and-instagram-to-offer-subscription-for-no-ads-in-europe/
https://www.linkedin.com/pulse/meta-et-rgpd-pourquoi-labonnement-payant-%C3%A0-facebook-pose-champeau-cp2le

00:14:26 Emulation Risc V sur Linux avec Scratch
https://www.hackster.io/news/linux-on-scratch-is-proven-possible-thanks-to-this-clever-risc-v-emulator-project-815bf0937ec7

00:17:30 Une machine de Turing sous PowerPoint
https://www.youtube.com/watch?v=deswvXZ0Sjc
On The Turing Completeness of PowerPoint (SIGBOVIK)

00:20:20 Brainfuck latex
https://www.youtube.com/watch?v=deswvXZ0Sjc
[DEVFEST Toulouse 2019] Applications de Brainfuck, langage minimaliste mais Turing-complet

00:22:28 Async traits merged in master
https://twitter.com/compiler_errors/status/1713338363460321763
https://releases.rs/docs/1.75.0/

00:25:30 Linux v6.6 avec du nouveau sur eBPF
https://twitter.com/pchaigno/status/1719024426774069701

00:29:17 WebAssembly pour passer du Rust en douce
https://twitter.com/bluxte/status/1717233980485914986

00:38:12 WebAssembly GC dans Chrome
https://developer.chrome.com/blog/wasmgc/

00:49:10 Rust certifié pour les systèmes critiques
https://ferrous-systems.com/blog/ferrocene-open-source/

00:58:10 Tailspin, un petit outil en Rust pour lire des logs colorisés
https://github.com/bensadeh/tailspin

01:03:23 : Musique de fin : Måneskin - HONEY (ARE U COMING?)
https://www.youtube.com/watch?v=ds18Ozzp8h0

After the MACI podcast, Clever Cloud is now offering new content on Twitch. On this platform, the aim is more pedagogical: to offer viewers the chance to improve their skills in certain languages and tools.

First content on Rust language

The Rust language is gaining in popularity for its performance, its low-level nature, its memory security and its ability to detect errors at compile time.

At Clever Cloud, it's being used more and more, and we're seeing a real increase in interest when we talk to developers at trade fairs and meetings.

Akanoa then came up with the idea of sharing his skills via Twitch lives. A Clever Cloud colleague, Manu, was keen to learn this language. It was the perfect way to launch the channel. We're going to continue with this, and add new content as the months go by.

How can you take part?

There are 2 ways to enter today:

• First, you can follow our live Twitch sessions every other Wednesday (whenever possible) from 3 to 5 p.m. on our Twitch channel,
• Secondly, you can replay our live sessions on the Twitch channel or on our Youtube channel.

We're thinking of offering our viewers the chance to take part in live sessions in the future. If you're interested in taking part in our content one day, please contact us.

A will to share

At Clever Cloud, sharing skills is an integral part of our values: Open Source, talks, workshops, and so on. We're also committed to Open Source (Reverse Proxy Sōzu , the Biscuit token, participation in the Linux kernel, etc.) and strongly believe that sharing lifts everyone up. Today, going on Twitch is a new step in this willingness to share knowledge that we're proud of.

Animé par Quentin ADAM

avec la participation de :

• Sun Tan - @__sunix_
• Horacio Gonzalez - @LostInBrittany
• Sebastien Blanc - @sebi2706

Épisode enregistré le 5 octobre 2023

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Timecodes et liens

00:02:45 Rust pour Intellij devient payant
https://x.com/rustrover/status/1701944316573204945?s=46&t=Cd-Q3SyiffHQkyTKLC-sFg

00:07:14 Comment rattraper ses erreurs dans Git avec Dangit
https://dangitgit.com/en

00:07:53 Une proposition de standardisation des emoji dans Git : codification ou source d’inspiration ?
https://gitmoji.dev

00:11:20 Nouveau projet exemple de Clever Cloud en .NET
https://x.com/waxzce/status/1709558406405644785?s=20

00:13:15 Visual Code Studio - nouvelle version 1.82
https://twitter.com/davlgd/status/1699886746937540814

00:15:50 Oracle prépare un plugin Java pour VScode, charge contre modèle réactif…
Keynote Devoxx
https://docs.oracle.com/fr-ca/iaas/nosql-database/doc/using-visual-studio-code-extension-development.html
https://twitter.com/Devoxx/status/1709492804391489713

00:18:50 Metabase 47
https://twitter.com/metabase/status/1704161194032943593

00:20:20 Scala3 - Play en RC 2.9.0
https://github.com/playframework/playframework/releases/tag/2.9.0-RC2

00:25:25 Introducing runes
https://svelte.dev/blog/runes

00:28:50 Servo web rendering engine joins Linux Foundation Europe
https://linuxfoundation.eu/newsroom/servo-web-rendering-engine-joins-linux-foundation-europe

00:33:00 des cours de Rust avec Clever sur Twitch !
https://twitter.com/clever_cloudFR/status/1703759381899227199

00:35:55 Photoshop en version WEB grace à Webassembly
https://twitter.com/sethshaw/status/1707511072016810069?s=46&t=ymswwB3NV0qGUdT1M-dGZg

00:41:20 Open core legacy patcher prolonge la vie des vieux Macs
https://dortania.github.io/OpenCore-Legacy-Patcher/
https://x.com/FabriceNeuman/status/1709102672672965052?s=20

00:42:45 Les algorithmes de compression concurrencés par l’IA https://www.spiria.com/fr/blogue/breves-technos/les-algorithmes-de-compression-concurrences-par-lia/

00:46:20 l'outil de l’épisode : Yazi
https://github.com/sxyazi/yazi
Et en bonus : rust player
https://github.com/Kingtous/RustPlayer

00:48:42 La musique de fin
Joe Henry - "Lead Me On" (Live at WFUV)
https://www.youtube.com/watch?v=usRwlP4OkEk

Dans cet épisode très ouvert il est question de Rust qui est à la base de wymmo.com (le portail de notre invité), du ralentissement du secteur, de Docker pousse l'open source vers le payant et d'histoire de nos machines. Nous passons un moment à parler d'IA : annonce de GPT4, CopilotX, LLaMA avant de présenter quelques outils et de finir en musique.

Avec la participation de @juuduu
Emmanuel Bosquet (@EmmanuelBosquet) / Twitter
Guillaume Assier 🔋 (@GuillaumeAssier) / Twitter
jrx - Eventually Consultant - C# .. 🦀⚙️ (@jrouaix) / Twitter

Épisode enregistré le 24 mars 2023.

👋 Venez discuter avec nous sur @clever_cloudFR pour nous dire ce que vous avez pensé de ce nouvel épisode.

➡️ Pour découvrir ou réécouter d’anciens épisodes c’est par ici !

Timecode & Liens

00:00:16 - Présentation des participants

00:01:27 Projet pro : https://wymmo.com/

00:09:28 Et sinon le ralentissement dans notre secteur, vous le ressentez ?
https://www.lesechos.fr/start-up/next40-vivatech/payfit-se-separe-de-20-de-ses-effectifs-1910932
https://emploi.developpez.com/actu/342624/Y-a-t-il-une-bulle-dans-l-industrie-Tech-et-est-elle-en-train-d-eclater-Les-donnees-sur-les-offres-d-emploi-le-suggerent-mais-les-experts-estiment-que-c-est-le-moment-ideal-pour-y-travailler/

00:21:18 : Docker pousse l’open source vers un modèle payant
https://blog.alexellis.io/docker-is-deleting-open-source-images/
Faut faire du blé… devenir rentable
0€ −> 420€/an
Changement dans un mois.

00:28:58 Un peu d'histoire (en podcast), d'où viennent nos machines (Jérôme):

• https://techcafe.fr/steampunk-cafe-machine-de-babbage-et-autres-machines-a-vapeur/
  Métiers à tisser, cartes perforés, ordinateur à vapeur et machines analogiques (beaucoup de liens en description)
• https://techcafe.fr/supplement-steampunk-cafe-2-langleterre-du-colossus-a-lamstrad/
  La suite de l'Histoire et premiers transistors
  00:34:04 : Eloge duclavier BEPO
  https://bepo.fr/wiki/Accueil
  Klavaro : https://klavaro.sourceforge.io/fr/index.html

00:38:40 Open AI ne sera plus “open” et annonce GPT-4 (Jérôme)
https://openai.com/research/gpt-4
https://www.theverge.com/2023/3/15/23640180/openai-gpt-4-launch-closed-research-ilya-sutskever-interview
- L'IA passe de l'ère de la recherche à l'ère du secret
- "Open" AI n'a jamais si mal porté son nom

00:44:34 : CopilotX
https://github.blog/2023-03-22-github-copilot-x-the-ai-powered-developer-experience/ (Emmanuel)

00:49:21 : Comment fonctionnent les IA tels GPT-x
https://www.joshwcomeau.com/blog/the-end-of-frontend-development/

00:57:56 : Demandes DMCA des dépôts basés sur le modèle LLaMA (Large Language Model Meta AI) par Meta
Lama-dl + forks
https://twitter.com/theshawwn/status/1638925249709240322
https://github.com/github/dmca/blob/master/2023/03/2023-03-21-meta.md
https://twitter.com/Dorialexander/status/1638992849516544000?s=20

01:00:29 : Vol de compte meta via une extension chrome qui surfe sur la vague chatgpt
https://thehackernews.com/2023/03/fake-chatgpt-chrome-browser-extension.html

01:02:26 : Support en alpha des plugins dans chatgpt qui va améliorer son expérience produit
https://openai.com/blog/chatgpt-plugins

01:04:00 : Codegenr, l’outil de la semaine
https://github.com/eventuallyconsultant/codegenr

01:11:56 : Musique de fin - Sound of science - Portal
https://www.youtube.com/watch?v=l0xh4qopQpk

Si les dés en avait décidé autrement, il y aurait pu avoir :

• Julien : https://www.youtube.com/watch?v=BtxTSXhZbOQ Ma’agalim, Idan Raichel
• Guillaume : https://www.youtube.com/watch?v=hVvx8cZcklQ When You’re Around, Oliver Tree
• Jérôme : https://www.youtube.com/watch?v=6AbssmQ7EPI&list=PLD27AC29593FA45A7&index=18