Die Rückkehr der pinken Lederjacke? Warner hat einen Nachfolger des im Frühjahr erschienenen „Minecraft“-Kinofilms angekündigt. Der Film soll am 23. Juli 2027 in die Kinos kommen, erklärt Warner – auf einem Teaserbild sind lediglich zwei Spitzhacken auf einer Werkbank zu sehen.

„Ein Minecraft Film“ kam im April 2025 in die Kinos. Nachdem der erste Trailer bei „Minecraft“-Fans eher auf Entgeisterung gestoßen war, entwickelte sich der fertige Film zum Hit: Am Box Office spülte er fast eine Milliarde US-Dollar in die Kassen. Ein Nachfolger war angesichts dessen alternativlos. Dass ein zweiter Teil kommen sollte, war in Hollywood daher erwartet worden, berichtet das Branchenmagazin Variety.

Allzu viele Veränderungen sind im Vergleich zum ersten Teil wohl nicht zu erwarten: Jares Hess kehrt als Regisseur zurück, Jason Momoa wird Producer – ob er auch wieder eine Schauspielrolle übernehmen wird, ist noch offen. Mit weiteren Informationen hält sich Warner Bros. aktuell noch bedeckt.

Auch zweiter „Mario“-Film in Arbeit

Videospielfans können sich neben dem zweiten Teil von „Ein Minecraft Film“ auch auf die Fortsetzung eines weiteren Gaming-Kassenschlagers freuen: Vor wenigen Wochen hat Nintendo angekündigt, dass auch der „Mario“-Film einen zweiten Teil bekommen soll. Der „The Super Mario Galaxy Movie“ soll im April 2026 in die Kinos kommen, teilte Nintendo mit. „The Super Mario Galaxy Movie“ folgt auf den „Super Mario Bros.“-Film, den Nintendo 2023 in die Kinos gebracht hat. Das Animationsstudio Illumination produziert erneut Teil 2. Auch die Schauspieler aus dem ersten Teil sollen zurückkommen – dazu gehören in der englischsprachigen Fassung Chris Pratt als Mario und Anya Taylor-Joy als Prinzessin Peach.

Der „Mario“-Film von Nintendo war sogar noch etwas erfolgreicher als der „Minecraft“-Streifen: Er hat über eine Milliarde US-Dollar in die Kassen gespült.

(dahe)

Die US-Bank Morgan Stanley hat ihr Kursziel für die Apple-Aktie, die am Donnerstag bei knapp 254 US-Dollar (ein Minus von 1,56 Prozent gegenüber dem Vortag) stand, auf fast 300 Dollar erhöht – und zwar nicht aufgrund des Verkaufserfolgs beim iPhone 17, sondern wegen eines „positiven Ausblicks“ auf die Nachfolgebaureihe, die erst im Herbst 2026 erwartet wird. Die jüngste Kurszielfestlegung der Analysten liegt nun bei 298 Dollar, wie es in einer Notiz an Investoren hieß. Dabei hatte Morgan Stanley im März 2025 ihr Kursziel noch auf 252 Dollar reduziert, da die Investmentbank damals schlechtere Verkäufe beim iPhone 17 vorhersagte.

Mehr Upgrader im kommenden Jahr?

Die jüngste Oktober-Prognose sieht das nun aber anders. Morgan Stanley ist nun in Sachen iPhone 17 positiver gestimmt und glaubt an ein Apple-Umsatzplus von vier Prozent für das Fiskaljahr 2026 auf dann 230,3 Milliarden Dollar. Der Durchschnittswert der Wall Street liegt hier bei nur 220 Milliarden. Neben möglichen Preiserhöhungen über die Produktlinie hinweg – das erste iPhone-Foldable soll mindestens 2000 Dollar kosten – rechnen die Banker auch mit mehr Verkäufen insgesamt.

Die Nachfrage nach dem iPhone 17 verspricht demnach einen besser als erhofften iPhone-18-Zyklus. Im kommenden Jahr sei zudem mit mehr Nutzern zu rechnen, die alte iPhones austauschen wollten, so Morgan Stanley. Die Bank geht von insgesamt sechs neuen iPhones im Apple-Fiskaljahr 2026 aus. Neben iPhone 18 (Standardmodell) seien iPhone 18 Pro, 18 Pro Max, ein zweites Air, ein Foldable und (wohl später) ein iPhone 18e als Einsteigermodell geplant.

Das „Bull-Szenario“

Im gesamten Fiskaljahr 2026 sei mit 243 Millionen verkauften iPhones zu rechnen. Sollte es Apple jedoch gelingen, bis zu 270 Millionen Einheiten zu verkaufen – das sogenannte „Bull-Szenario“ des Bankhauses, sei das Kursziel 376 statt 298 Dollar.

Beim iPhone 17 gibt es Analysten zufolge derzeit einen differenzierten Verkaufsmix. Demnach läuft insbesondere das Standardmodell gut – gefolgt von den Pro-Varianten. Beim Air sieht es angeblich schlechter aus. Das besonders dünne iPhone ist recht teuer und hat mit einigen Kompromissen – nur eine Kamera, kleinerer Akku – zu kämpfen, was offenbar die „Verkaufe“ erschwert. Tatsächlich sind die Geräte auch aktuell direkt in Apples deutschen Ladengeschäften abholbar, während man auf ein iPhone 17 mehrere Wochen warten muss.

(bsc)

In der modernen Softwareentwicklung ist Nebenläufigkeit allgegenwärtig. Selbst kleine Anwendungen laufen oft auf Systemen mit mehreren Kernen, interagieren mit Datenbanken, warten auf Netzwerkantworten oder teilen sich Ressourcen wie Dateien und Speicherbereiche. In verteilten Systemen und Embedded-Software kommt noch hinzu, dass verschiedene Prozesse aufeinander reagieren müssen, oft unter Echtzeitbedingungen. Die Praxis zeigt: Sobald mehrere Dinge gleichzeitig passieren können, entstehen neue Fehlerklassen, die sich in seriellen Programmen nie gezeigt hätten.

Muster 3: Concurrency und Scheduling: Wenn sich Prozesse gegenseitig blockieren

Ein berühmtes Beispiel ist der Mars Pathfinder, eine NASA-Mission aus dem Jahr 1997. Die Landung selbst war ein spektakulärer Erfolg – die Sonde setzte sanft auf dem Mars auf und begann, Daten zu senden. Doch kurz darauf kam es zu sporadischen Systemabstürzen und automatischen Resets, die das Team am Boden in Alarmbereitschaft versetzten.

Die Ursache war eine Priority Inversion, ein klassisches Concurrency-Problem. In einem Echtzeitbetriebssystem gibt es Aufgaben mit unterschiedlicher Priorität. Hohe Priorität bedeutet: Diese Aufgabe soll möglichst sofort laufen, sobald sie bereit ist. Niedrige Priorität darf sie nicht blockieren.

Auf dem Pathfinder lief eine solche hochpriorisierte Aufgabe, die Daten vom Wettersensor verarbeitete. Sie benötigte jedoch Zugriff auf eine gemeinsame Ressource – in diesem Fall einen Mutex, der von einer niedrig priorisierten Aufgabe gehalten wurde. Diese niedrig priorisierte Aufgabe wurde wiederum von einer mittel priorisierten Aufgabe ständig verdrängt. Das Ergebnis: Die hochpriorisierte Aufgabe wartete indirekt auf eine niedrige, die nie zum Zuge kam.

Dieses Phänomen der „Umkehrung der Prioritäten“ führte dazu, dass das System in bestimmten Lastsituationen hängen blieb und schließlich neu startete. Die Lösung war im Prinzip einfach: Die Entwicklerinnen und Entwickler aktivierten Priority-Inheritance im Echtzeitbetriebssystem VxWorks. Dadurch erbte die blockierende, niedrig priorisierte Aufgabe vorübergehend die hohe Priorität, sobald eine höherwertige Aufgabe auf sie wartete. Der Knoten löste sich, und die Abstürze verschwanden.

Dieses Beispiel ist lehrreich, weil es gleich mehrere typische Muster verdeutlicht:

• Nebenläufigkeitsfehler sind schwer zu reproduzieren: Sie treten oft nur unter bestimmten Lastprofilen auf.
• Redundanz oder Wiederholungen helfen nicht automatisch: Wenn der Fehler im Design liegt, trifft er alle Instanzen gleichermaßen.
• Kleinste Details im Scheduling können den Unterschied machen: Die Software kann tausendmal korrekt laufen und beim tausend-und-ersten Mal ausfallen.

In modernen Anwendungen können ähnliche Probleme in Form von Deadlocks, Race Conditions oder Livelocks auftreten. Diese zeigen sich meist nicht im lokalen Testlauf, sondern erst in der Produktion, wenn reale Last und reale Parallelität wirken. Doch wie lassen sich solche Fehler vermeiden?

1. Klare Lock-Hierarchien: Wenn mehrere Ressourcen gesperrt werden, sollte immer in derselben Reihenfolge gelockt werden.
2. Prioritätsprotokolle nutzen: Mechanismen wie Priority Inheritance oder Priority Ceiling sind in vielen Echtzeitbetriebssystemen und sogar in modernen Frameworks verfügbar.
3. Nebenläufigkeit entkoppeln: Statt gemeinsame Zustände direkt zu sperren, können Architekturen mit Message Passing oder Actor-Modellen Race Conditions vermeiden.
4. Deterministische Tests und Simulationen: Spezielle Testframeworks können Prozesse gezielt verzögern oder Scheduler manipulieren, um seltene Konflikte reproduzierbar zu machen.
5. Telemetrie und Monitoring: Auch im Betrieb sollte sichtbar sein, wenn Locks ungewöhnlich lange gehalten werden.

Für Teams, die Web-Backends oder Cloud-Services entwickeln, zeigt sich übrigens dieselbe Gefahr, nur in geringfügig anderer Form: Datenbanktransaktionen, verteilte Caches oder konkurrierende API-Requests können ähnliche Effekte haben. Ein langsamer Hintergrundprozess blockiert einen Lock, während eine Flut von parallelen Requests diesen Zustand eskalieren lässt.

Die Lehre aus dem Pathfinder-Vorfall ist daher zeitlos: Nebenläufigkeit ist kein kostenloser Performance-Booster, sondern ein komplexes System, das Entwicklerinnen und Entwickler explizit entwerfen und überwachen müssen. Wer Concurrency als Randthema behandelt, wird früher oder später auf schwer reproduzierbare und potenziell katastrophale Fehler stoßen.

Aus Softwarefehlern lernen – die Serie

Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Im nächsten Teil lesen Sie: Zeit, Kalender und Geografie: Wenn die Uhr nicht das misst, was man denkt.

(who)