Der Relativistic Heavy Ion Collider (RHIC) am Brookhaven National Laboratory hat am 6. Februar 2026 kurz nach 9 Uhr morgens seine finalen Kollisionen durchgeführt. Wie das Brookhaven National Laboratory mitteilte, kollidierten dabei nahezu lichtschnelle Sauerstoff-Ionen in den Detektoren STAR und sPHENIX. Nach über 25 Jahren Betrieb endet damit die wissenschaftliche Arbeit des Teilchenbeschleunigers.

RHIC nahm im Sommer 2000 den Betrieb auf und arbeitete in dieser Zeit mit zehn verschiedenen Atomarten in unterschiedlichen Energien und Konfigurationen. Der finale Durchlauf erzeugte den größten Datensatz aus Gold-Ionen-Kollisionen sowie Proton-Proton-Kollisionen für Spin-Analysen. Hinzu kamen niedrigenergetische Fixed-Target-Kollisionen und Sauerstoff-Sauerstoff-Interaktionen.

Der Detektor sPHENIX sammelte allein im letzten Durchgang über 200 Petabyte Rohdaten – mehr als alle vorherigen RHIC-Datensätze zusammen. Darunter befinden sich 40 Milliarden Momentaufnahmen von Gold-Ionen-Kollisionen. „RHIC ist eine der erfolgreichsten Nutzereinrichtungen des DOE Office of Science und steht Tausenden Wissenschaftlern aus den gesamten Vereinigten Staaten und der ganzen Welt zur Verfügung“, erklärte Darío Gil, Staatssekretär für Wissenschaft im US-Energieministerium.

Der Beschleuniger mit seinen zwei 3,8 Kilometer langen supraleitenden Ringen erzeugte während seiner Laufzeit Quark-Gluon-Plasma (QGP), das die Materie kurz nach dem Urknall vor 14 Milliarden Jahren nachahmte. Die Experimente wiesen 2005 nach, dass sich QGP wie eine perfekte Flüssigkeit verhält. Zudem trugen die Messungen wesentlich zur Aufklärung des Proton-Spins bei.

Platz für den Electron-Ion Collider

Das Ende von RHIC ist zugleich der Startschuss für seinen Nachfolger: den Electron-Ion Collider (EIC). Der neue Teilchenbeschleuniger wird wichtige Komponenten von RHIC übernehmen, darunter den Ion-Speicherring und die Injektoren. Einer der beiden Ringe wird durch einen Elektronenring im bestehenden Tunnel ersetzt.

Das EIC-Projekt soll präzise Messungen der Quark- und Gluon-Verteilung in Protonen ermöglichen und deren Beiträge zur Masse und Spin untersuchen. Der Baubeginn ist für 2026 vorgesehen, erste Experimente sollen Anfang der 2030er Jahre starten. Das US-Energieministerium rechnet mit Kosten zwischen 1,7 und 2,8 Milliarden US-Dollar. „Wir wussten, dass RHIC beendet werden musste, damit EIC stattfinden konnte. Es ist ein bittersüßer Moment“, kommentierte Wolfram Fischer, Leiter der Collider-Accelerator-Abteilung am Brookhaven National Laboratory.

Auch am CERN stehen Weichen auf Zukunft

Während in den USA ein Teilchenbeschleuniger seinen Nachfolger bekommt, plant das CERN in Europa bereits die nächste Generation. Wie aus der Machbarkeitsstudie für den Future Circular Collider hervorgeht, soll der FCC mit einem 91 Kilometer langen Tunnel und einer Tiefe von 200 Metern den aktuellen Large Hadron Collider (LHC) mit seinen 27 Kilometern Umfang deutlich übertreffen.

Der LHC selbst hat kürzlich einen bemerkenswerten Meilenstein erreicht: Die Forschungseinrichtung archivierte mehr als ein Exabyte an Daten auf über 60.000 Magnetbändern. Das High-Luminosity-Upgrade des LHC soll die Datenmenge künftig verzehnfachen. Für den FCC haben mehrere Milliardäre bereits 860 Millionen Euro zugesagt, darunter Eric Schmidt, Xavier Niel und John Elkann.

Die erste Phase des FCC ist als Elektron-Positron-Collider konzipiert und soll als „Higgs-Fabrik“ dienen. In späteren Ausbaustufen sind Protonenkollisionen mit Energien bis 100 Teraelektronenvolt geplant – mehr als das Siebenfache der aktuellen LHC-Kapazität. Der CERN-Rat prüft die vollständige Machbarkeitsstudie, ein Baubeginn könnte in den 2040er Jahren erfolgen.

(vza)

Der Betriebsrat des Erfurter Logistikzentrums des Mode-Versandhändlers Zalando hat den Vorstand aufgefordert, Alternativen zur Schließung des Standorts zu prüfen. „Darüber ist überhaupt noch nicht gesprochen worden“, sagte der Betriebsratsvorsitzende Tony Krause vor einer Betriebsversammlung der Deutschen Presse-Agentur in Erfurt.

Thüringens Ministerpräsident Mario Voigt (CDU) wird den Beschäftigten nach Angaben der Staatskanzlei die Unterstützung der Landesregierung zusichern. „Die Entscheidung des Unternehmens war verantwortungslos“, erklärte Voigt.

Zukunft für 2700 Arbeitnehmer unsicher

Bei der Betriebsversammlung geht es um die berufliche Zukunft der 2700 Beschäftigten des Internet-Modehändlers in Erfurt. Der Betriebsrat hat – um allen Platz zu bieten – eine Messehalle in Erfurt gemietet. Betroffen sind nach Schätzungen außerdem etwa 300 Beschäftigte bei Dienstleistern in der Region.

Die Arbeitnehmervertretung kritisiert seit der Schließungsentscheidung von Anfang Januar, dass der Betriebsrat entgegen der rechtlichen Regelungen nicht rechtzeitig gehört worden sei. Er pocht auf sein Beteiligungsrecht. Seit der Verkündung, dass der Standort im September geschlossen werden soll, habe es keinen Kontakt mit dem Vorstand gegeben, sagte Krause. Der Betriebsrat habe inzwischen einen Rechtsanwalt eingeschaltet.

Was das Zalando-Management sagt

Standortleiter Stefan Rutschmann sagte nach Unternehmensangaben, „die Entscheidung, den Standort Erfurt zu schließen, ist aus Sicht des Unternehmens unumgänglich.“ Zalando habe jede andere Option geprüft. „Wir wollen keine falschen Hoffnungen wecken, sondern mit allen Beteiligten arbeiten, um euch jetzt konkret zu helfen.“

Personalvorständin Astrid Arndt versicherte, das Management sei bereit, mit der Belegschaft über Details und Hintergründe zu sprechen, „um dann in die Verhandlungen für einen starken Sozialplan einzusteigen. Wir wollen euch finanzielle Sicherheit bieten und klare Perspektiven schaffen, inklusive spezieller Angebote für diejenigen, die sich frühzeitig umorientieren möchten.“

Kritik an Taschenkontrollen

Trotz des Schocks laufe der Betrieb in dem Logistikzentrum normal weiter. „Es gibt niemanden, der auf uns zukommt wegen eines Aufhebungsvertrags“. Erste Vorbereitungen zur Jobvermittlung durch die regionale Arbeitsagentur gebe es nur für Beschäftigte, deren befristete Verträge in nächster Zeit ausliefen.

Kritik übte der Betriebsrat an Sicherheitsvorkehrungen des Unternehmens bei der ersten Betriebsversammlung nach dem angekündigten Standort-Aus am Donnerstagabend. Es sei mit vielen Sicherheitskräften, Taschenkontrollen und möglicherweise Scannern zu rechnen, so Krause. „Wir halten das für völlig überzogen.“

Krause verwies darauf, dass das Unternehmen bereits bei der Verkündung der Standortschließung Anfang Januar extreme Sicherheitsvorkehrungen getroffen habe. Es seien Fenstergriffe entfernt und etwa 50 zusätzliche Sicherheitsleute, aber auch Sanitäter eingesetzt worden. Ein Unternehmenssprecher von Zalando sagte auf Anfrage zu den Sicherheitsvorkehrungen, der Arbeitgeber habe eine Fürsorgepflicht und stehe bei Vorfällen auch in der Haftung. „Sicherheit geht vor“.

Landesregierung spart nicht mit Kritik

Nach Angaben von Voigt wolle die Landesregierung alles daransetzen, neue berufliche Perspektiven für die Zalando-Beschäftigten zu schaffen. „Wir unterstützen Qualifizierungen, organisieren Beratung direkt vor Ort und setzen auf die vielen Logistikunternehmen hier in Mittelthüringen. Wir werden alles dafür tun, dass alle Betroffenen eine faire Chance auf neue Arbeit bekommen.“

Wirtschaftsministerin Colette Boos-John (CDU) warf dem Unternehmen vor, es über lange Zeit versäumt zu haben, kontinuierlich in die Modernisierung und Weiterentwicklung seines ältesten und größten Logistikstandorts zu investieren. „Die Entscheidung zur Standortschließung war aus meiner Sicht deshalb keineswegs alternativlos – sondern sie wäre vermeidbar gewesen.“ Den Umgang mit den Mitarbeitern bezeichnete sie als „geradezu schäbig“.

Arbeitsministerin Katharina Schenk (SPD) erinnerte an die finanzielle Förderung der Investition vor 14 Jahren. Für Zalando wurde von der Stadt eine Buslinie eröffnet und ein Radweg gebaut. Schenk: „Zalando darf jetzt nicht zu billig davonkommen.“ Mitbestimmung müsse wirklich gelebt werden.

(dmk)

Die Programmiersprache Rust eignet sich gut für die Umsetzung von Cross-Plattformprojekten. Der erste Teil der Artikelserie hat die grundlegenden Konzepte einer langlebigen Cross-Plattform-Architektur vorgestellt: Ein herausgelöster Core in Rust bildet das Fundament für nachhaltige Apps. Die Implementierung eines einfachen MVVM-Patterns mit ViewModel, Actions und State zeigte eine einfache konkrete Umsetzung dieses Ansatzes. Wie sich die Architektur verfeinern lässt, zeigt sich, wenn man sie um Validierungen erweitert.

Cross-Plattform mit Crux

Das in Rust geschriebene Framework Crux für die plattformübergreifende Entwicklung implementiert die im ersten Artikelteil vorgestellten Konzepte. Was Aktion hieß, nennt Crux Event. Der Zustand(State) heißt Model. Durch den ähnlichen Namen ist die Grenze zum ViewModel leider nicht mehr ganz so deutlich. Das ViewModel heißt nämlich auch bei Crux ViewModel. Umso wichtiger ist es, die Abgrenzung bei der Umsetzung im Hinterkopf zu behalten.

Zudem bringt Crux mit Effect und Command noch weitere wichtige Konzepte mit.

Ein Effect bildet einen Seiteneffekt der hexagonalen Architektur ab. In diesem Kontext sind Seiteneffekte gleichbedeutend mit Plattformspezifika und dem Rendern des User Interface (UI). Dabei ist ein Effect keine Einbahnstraße. Durch ein Command lässt es sich mit einem Event verknüpfen, sodass der verarbeitete Effekt beantwortet und die Antwort in der App auf ein weiteres Event angewendet werden kann. Auf diese Art lässt sich der Zugriff auf das jeweilige Dateisystem und auf native APIs abstrahieren und umsetzen.

Crux definiert außerdem die Begriffe App, Core und Shell.

• Die App ist das zentrale Trait und ein Pendant zum Core aus Teil 1
• Core umhüllt die App und sorgt dafür, dass ein Event in die App hinein- und nur eine Liste von Effect oder das ViewModel aus der App hinausgeht
• Shell bezeichnetet den Konsumenten des Cores (bepackt mit der App), wie eine native App auf Basis von Swift, Kotlin oder C#

Beispiel: E-Mail-App

Das zuvor in Teil 1 implementierte Beispiel wird erneut aufgegriffen und auf Crux übertragen. Als Erstes die einfachen Typen (Listing 1):

Listing 1: Crux: Event/Model/ViewModel-Definitionen

#[derive(Deserialize, Serialize)]
pub enum Event {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges,
}

#[derive(Default)]
pub struct Model {
    name: String,
    email: String,
}

#[derive(Deserialize, Serialize)]
pub struct ViewModel {
    pub name: String,
    pub email: String,
}

Hierbei gibt es keine Überraschungen. Actions werden zu Event (Einzahl), State wird zu Model und das ViewModel bleibt bestehen.

Als Nächstes die neuen Typen (Listing 2):

Listing 2: Crux: Effect-Enum und App-Struct

#[effect]
pub enum Effect {
    Render(RenderOperation),
}

#[derive(Default)]
pub struct EmailApp;

Das Enum Effect definiert alle möglichen Kommunikationen aus dem Core hinaus. Das Struct EmailApp bleibt leer. Es implementiert im nächsten Schritt das Trait App von Crux.

Die Implementierung von App ist in drei Blöcke (siehe Kommentare in Listing 3) unterteilt.

Listing 3: Crux: App-Trait-Implementierung

impl App for EmailApp {
    // 1
    type Event = Event;
    type Model = Model;
    type ViewModel = ViewModel;
    type Capabilities = (); // deprecated
    type Effect = Effect;

    // 2
    fn update(
        &self,
        event: Self::Event,
        model: &mut Self::Model,
        _caps: &Self::Capabilities,
    ) -> Command<:effect self::event=""> {
        match event {
            Event::ChangeEmail(email) => {
                model.email = email.clone();
            }
            Event::ChangeName(name) => {
                model.name = name.clone();
            }
            Event::ApplyChanges => {}
        }
        render()
    }

    // 3
    fn view(&self, model: &Self::Model) -> Self::ViewModel {
        ViewModel {
            name: model.name.clone(),
            email: model.email.clone(),
        }
    }
}

Der erste Block legt die grundlegenden assoziierten Typen fest, die App vorsieht. Diese Typen sind aus Listing 1 und 2 bekannt. Der Typ Capabilities ist ein Relikt und gilt als veraltet (deprecated). Dieses Konzept wurde vor der Einführung von Command genutzt. Daher ist es lediglich aus Gründen der Rückwärtskompatibilität vorhanden und lässt sich ignorieren.

Die update-Methode nimmt eingehende Events entgegen und passt daraufhin den Zustand (Model) an. Änderungen am Namen oder der E-Mail-Adresse werden auch hier direkt im Model gespeichert. Nach der Verarbeitung eines Events wird ein Render– Effect ausgelöst. Dieser kann in der Shell aufgegriffen, das ViewModel angefragt und das Re-Rendering angestoßen werden.

Die view-Methode in Abschnitt 3 bietet die Schnittstelle, um das ViewModel zu erstellen. Wie zuvor erzeugt das ViewModel das aktuelle Model (Zustand) und bereitet die relevanten Informationen für die UI so auf, dass die Benutzeroberfläche sie direkt anzeigen kann.

App im Core einwickeln

Um die App zu verwenden, gilt es diese im Core zu umhüllen (zu wrappen):

let core: Arc> = Arc::new(Core::new());

Dieser Core-Instanz lässt sich ein Event übergeben und die zurückkommenden Effekte können verarbeitet werden (Listing 4).

Listing 4: Crux: Effect-Verarbeitung

let effects: Vec =
    core.process_event(ChangeEmail("marcel.koch@example.org".into()));

for effect in effects {
  match effect {
    Effect::Render(_) => {
      let view_model = core.view();
      
      assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}

process_event nimmt das Event entgegen und gibt eine Liste von Effekten zurück. Das Beispiel behandelt nur eine Art von Effect: Render. Es wird geprüft, ob das ViewModel die eben übergebene E-Mail-Adresse enthält.

Ist das UI verbunden, tritt es bei jeder Änderung der E-Mail-Adresse auf.

Core in Bridge wrappen

Geht es nicht um einen reinen Aufruf innerhalb von Rust, ist die Integration in andere Technologien abhängig von Serialisierung. Diese Aufgabe übernimmt auf der Rust-Seite die Bridge. Ein einfacher Einsatz sähe in Rust wie folgt aus:

Listing 5: Crux: Bridge-Integration

let serialized = 
    bincode::serialize(&ChangeEmail("marcel.koch@example.org".into())).unwrap();

let effects: Vec = bridge.process_event(&serialized).unwrap();

let effects: Vec> =
bincode::deserialize(effects.as_slice()).unwrap();

for request in effects {
  let effect = request.effect;
  
  match effect {
    EffectFfi::Render(_) => {
    let view_model = bridge.view().unwrap();
    let view_model: ViewModel =
    bincode::deserialize(&view_model).unwrap();
    
    assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}

Es ist der gleiche Ablauf wie zuvor mit dem reinen Core. Die einzigen Unterschiede sind die Serialisierung des Events und die Deserialisierung der Effekte und des ViewModel. Diese Serialisierungen werden in einem realistischen Einsatz in den jeweiligen Fremdtechnologien (.NET, Swift etc.) durchgeführt. Diese Umsetzung zeigt der nächste Teil dieser Artikelserie.