Connect with us

Künstliche Intelligenz

Schutzschirm mit blinden Flecken: Was die Regierung zum „Cyber-Dome“ offen lässt


Deutschland plant einen Umbau seiner digitalen Verteidigung nach israelischem Vorbild, das laut Bundesinnenministerium (BMI) „weltweit als eines der technologisch führenden Länder gilt“. Das BMI will für das Konzept, das bis Ende 2026 stehen soll, eng mit Israel zusammenarbeiten und von dessen „Erfahrungen bei der automatisierten Erkennung und Mitigation von Cyberangriffen […] profitieren“.

Weiterlesen nach der Anzeige

Während das Bundesinnenministerium (BMI) den „Cyber-Dome“ als notwendigen Schutzschirm gegen Hybridangriffe bewirbt, bleiben zentrale Details zur Architektur, zu Datenflüssen und zu verfassungsrechtlichen Grenzen offen. Die Antwort der Bundesregierung auf eine Kleine Anfrage der Linken-Fraktion (PDF), unter anderem von Jan Köstering, und weitere Antworten des BSI zeigen, dass noch vieles unklar ist.

Bei fast allen Fragen zur konkreten technischen Ausgestaltung, zu beteiligten Firmen und zur Rolle von Nachrichtendiensten verweist das BMI auf Geheimhaltungspflichten oder auf einen noch nicht abgeschlossenen Planungsprozess. Konkrete Details zur Zusammenarbeit sind laut BMI „regierungsintern noch nicht abschließend abgestimmt“.

Cyberpakt mit Israel

Grundlage der Kooperation ist eine „Gemeinsame Erklärung zur Zusammenarbeit“, die Bundesinnenminister Alexander Dobrindt im Januar 2026 in Jerusalem unterzeichnete. Die Zusammenarbeit soll über themen- und aufgabenabhängige Kooperationsformate auf Arbeitsebene laufen. Was dort genau vereinbart wird, bleibt für die Öffentlichkeit bislang unter Verschluss. Als erster konkreter Schritt aus diesem Pakt fand bereits im Januar eine Übung von Vertretern des Bundesamts für Sicherheit in der Informationstechnik (BSI) in Israel statt, bei der die Abwehr eines weitreichenden Cyberangriffs trainiert wurde. Eine Anfrage von heise online zu Details, etwa welche KI-Systeme zum Einsatz kamen und zu den Ergebnissen, ließ das BSI bislang unbeantwortet.

Digitale Souveränität?

Das erklärte Ziel des BMI ist der Aufbau eines Systems in drei Clustern: ein Detektionsnetzwerk für Angriffe, ein Analyseverbund zur Auswertung und ein „offenes Ökosystem“ für die Verteilung von Warnungen. Dabei soll explizit israelisches Know-how bei der automatisierten Erkennung und Blockierung genutzt werden. Wie das mit digitaler Souveränität zusammenpasst, ist unklar, da der israelische Cyber-Dome massiv auf Technologien von US-Hyperscalern wie Google und Datenanalyse-Plattformen setzt.

Weiterlesen nach der Anzeige

Auf die Frage der Linken, welche Erkenntnisse sich Dobrindt „hinsichtlich des Bevölkerungs- und Zivilschutzes von einem Austausch mit Israel angesichts der offensichtlich vollkommen unterschiedlichen geografischen, politischen und historischen Rahmenbedingungen für den Bevölkerungs- und Zivilschutz in Israel und Deutschland“ erwartet, antwortet die Bundesregierung, dass der Minister auf „praxisnahe Erkenntnisse aus einem Land mit hoher Einsatzfrequenz“ setze. Diese Erfahrungen sollen nicht eins zu eins übernommen, sondern „analytisch und angepasst an deutsche Verhältnisse“ in den hiesigen Bevölkerungsschutz einfließen. Auf Nachfrage, ob die Cybersicherheitsmaßnahmen erhöht wurden, erklärte das BMI zudem, dass durch den Konflikt im Nahen Osten bisher keine zusätzlichen Auswirkungen auf die Cyberbedrohungslage in Deutschland erkennbar seien – eine Bewertung, die sich jedoch aufgrund der Dynamik jederzeit ändern könne. Die Behörden stünden hierzu im regelmäßigen Austausch.

Bezüglich menschenrechtlicher Maßstäbe und der Prüfung potenzieller Partnerfirmen, die in Überwachungs- oder Militärprogramme involviert sein könnten, blieb das Ministerium hingegen vage. Man teilte lediglich mit, dass bei jeder Kooperation, unabhängig vom Staat, „alle Gesetze eingehalten“ würden. Definierte rote Linien oder spezifische Ausschlusskriterien für Unternehmen nannte das BMI nicht. Laut Köstering ist „die mögliche Öffnung bundesdeutscher Datenbanken für Drittländer äußerst kritisch zu bewerten. Der Bundesregierung fehlt bislang ein überzeugendes Konzept, um sensible Datensätze vor dem Zugriff und der Verwertung durch gewinnorientierte Unternehmen zu schützen – sei es für das Training von KI-Systemen oder für andere Zwecke“.

Der Einsatz von KI, „etwa zur Zielerfassung“, werfe Köstering zufolge „schwerwiegende menschenrechtliche und völkerrechtliche Fragen auf. Im Kontext des Krieges im Gaza-Streifen stehen entsprechende Systeme im Verdacht, zu möglichen Kriegsverbrechen beigetragen zu haben. Vor diesem Hintergrund halte ich es für unverantwortlich, derartige Systeme ohne gründliche Evaluation und unabhängige Untersuchung überhaupt in Betracht zu ziehen.“

Keine Antwort zu KI-Systemen

Auf die explizite Frage der Abgeordneten, ob Software des US-Unternehmens Palantir oder KI-Systeme wie „Lavender“, die im israelischen Militärkontext zum Einsatz kommen, auch für den deutschen Cyber-Dome geprüft werden, heißt es: „Die Bundesregierung äußert sich grundsätzlich nicht öffentlich zu operativen Details von technischen Schutzeinrichtung [sic] ausländischer Stellen („Third-Party-Rule“), um die vertrauensvolle Zusammenarbeit mit ihren ausländischen Partnern nicht zu gefährden“. Damit bleibt offen, ob Deutschland durch den Import israelischer Architektur indirekt neue Abhängigkeiten von umstrittenen US-Sicherheitsfirmen eingeht.

„Zunehmend wird deutlich, dass Palantir auch aufgrund der autoritären bis autokratischen Positionierungen seiner Eigentümer ein erhebliches Risiko durch den Datenaustausch darstellen kann. Deshalb sollte die Bundesregierung sowohl von Kooperationen im Inland als auch vom Ankauf entsprechender Technik im Ausland Abstand nehmen“, sagt Köstering. Selbst die Existenz gemeinsamer Dateien wird mit Verweis auf das Staatswohl weder bestätigt noch dementiert.

Interessant wird zudem die institutionelle Ausgestaltung, da in Israel zivile Cyberabwehr, Militär und Nachrichtendienste eng verzahnt sind, während in Deutschland das verfassungsrechtliche Trennungsgebot zwischen Polizei und Geheimdiensten gilt. Die Bundesregierung benennt als deutsche Akteure „vor allem das Bundesamt für Sicherheit in der Informationstechnik (BSI), die Zentrale Stelle für Informationstechnik im Sicherheitsbereich (ZITiS), das Bundeskriminalamt (BKA) und die Bundespolizei“.

Schweigen zur Rolle der Nachrichtendienste

Während offiziell nur Polizei- und IT-Sicherheitsbehörden als Partner genannt werden, verweigert das Innenministerium auf Nachfrage jede Auskunft darüber, ob auch der Bundesnachrichtendienst (BND) oder das Bundesamt für Verfassungsschutz (BfV) über gemeinsame Dateien in den Cyber-Dome eingebunden sind. Unter Berufung auf das Staatswohl und den Schutz operativer Methoden wird weder bestätigt noch dementiert, ob deutsche Geheimdienste Daten mit ihren israelischen Pendants austauschen. Durch eine technische Hintertür des „Analyseverbunds“ wäre eine Vermischung von polizeilichen, geheimdienstlichen und militärischen Informationen möglich, die das deutsche Trennungsgebot faktisch aushebelt. Die Sorge vor kontrollfreien Räumen wächst zunehmend, etwa durch ein kürzlich bekannt gewordenes Urteil des Bundesverwaltungsgerichts. Das Gericht hatte entschieden, dass die Bundesdatenschutzbeauftragte (BfDI) ihre Kontrollrechte gegenüber dem BND im Streitfall nicht gerichtlich durchsetzen kann. Somit kann der Geheimdienst laut BfDI selbst entscheiden, was kontrolliert wird.

„Durch eine Beantwortung der Fragen nach Nutzung gemeinsamer Dateien zwischen dem BfV und ausländischen Nachrichtendiensten könnten Rückschlüsse auf die Arbeitsweise des BfV gezogen werden“, heißt es unter anderem in der Antwort der Bundesregierung. „Eine Konkretisierung hinsichtlich eines gegebenenfalls stattfindenden Austausches mit anderen Behörden könnte betroffene Personen oder Gruppen in die Lage versetzen, Abwehrstrategien zu entwickeln und somit die Erkenntnisgewinnung des BfV zu erschweren oder in Einzelfällen sogar unmöglich machen. Dies würde die Funktionsfähigkeit des BfV nachhaltig beeinträchtigen und damit einen erheblichen Nachteil für die Interessen der Bundesrepublik Deutschland bedeuten“, heißt es weiter.


(mack)



Source link

Verwandte Themen:
Weiterlesen

Künstliche Intelligenz

FreeBSD 14.4 läuft deutlich besser in der Cloud und auf Notebooks


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Das kostenlose Betriebssystem FreeBSD 14.4 hat den Release-Prozess durchlaufen und ist nun verfügbar. Wie in einigen Versionen zuvor gibt es für BSD-Verhältnisse überdurchschnittlich viele Verbesserungen und Erweiterungen, was darauf hindeuten könnte, dass das Interesse an den klassischen unixoiden Systemen weiter wächst. Neben Bugfixes und neuen Treibern gibt es auch Anpassungen, die Benutzer von FreeBSD 14 auf den Wechsel zu dem in Teilen grundlegend modernisierten FreeBSD 15 vorbereiten.

Weiterlesen nach der Anzeige

Installation auf Notebooks praxistauglicher

Notebook-Besitzer wird es freuen, dass die Pakete mit der WLAN-Firmware nun den Weg in das bootonly.iso und das mini-memstick.img gefunden haben, denn nur so kann bei der Installation bereits WLAN genutzt werden. Der WLAN-Treiber für Geräte nach Intel IEEE 802.11a/b/g/n/ac/ax/be ist endlich ACPI-fest und unterstützt damit 802.11ax/be sowie Einstellungen für PPAG (Per Platform Antenna Gain). Das Startup-Skript rc.d/bluetooth für den Bluetooth-Stack versucht nun mehrfach, sich mit Bluetooth-Geräten zu verbinden.

Im bislang etwas vernachlässigten Bereich Audio legt FreeBSD 14.4 ebenfalls zu. Neu ist sndctl(8), um ähnlich wie das uralte mixer(8) die Eigenschaften von Audiogeräten zu steuern. Gleichzeitig ist mit dem alten und fehlerhaften MIDI-Sequenzer im Kernel Schluss. Moderne Anwendungen erledigen MIDI im Userland. Ein Fehler in der Implementation von swapon(8) wurde behoben, sodass jetzt per GELI verschlüsselte Auslagerungsdateien auch über den .eli-Suffix in der fstab(5) definiert werden können.

FreeBSD fühlt sich auch in der Cloud immer wohler

Das Programm nuageinit(8) dient zur Initialisierung von Instanzen in einer Cloud-Umgebung, besteht aus drei rc(8)-Skripten und wird beim ersten Start nach der Systeminstallation ausgeführt. FreeBSD 14.4 erweitert es deutlich und unterstützt jetzt für das Bulk-Passwort-Management beispielsweise auch den chpasswd-Befehl inklusive aller veralteten Syntaxen.

Das Netgraph Control Utility ngctl(8) kann über das neue „-j“-Flag nun auch von außen in ein FreeBSD-Jail ohne eigenes ngctl(8) hineinreichen und dort Netgraph-Objekte (Nodes) verwalten. Beim Anlegen von Jails oder später per „jail -cm“ können FreeBSD-14.4-Jails beliebige „key=value “-Zeichenketten als Metadaten (meta=„…“ und env=„…“) übergeben werden. Das übergeordnete Jail kann beide Metadatenvariablen lesen, während das untergeordnete Jail nur env versteht.

Der EFI-Bootloader loader.efi wird nun auf alle ESPs (EFI System Partitions) eines Multivolume-ZFS-Datasets kopiert, sodass auch beim Ausfall des primären Laufwerks noch gebootet werden kann. Der nvme(4)-Treiber unterstützt BAR5 und ermöglicht es FreeBSD 14.4 damit, auch auf Google-Compute-Engine-4-Systemen zu laufen.

Weiterlesen nach der Anzeige

Die Treiber für schnelle Intel-Netzwerkkarten ix(4) und ixv(4) unterstützen jetzt die E610-Familie inklusive neuer PCI-IDs für Backplanes, SFP, 10 GbE, 2.5 GbE und die SGMII-Varianten (Serial Media-Independent Interface).

Plan 9 in FreeBSD für Bhyve-VMs

Das Plan 9 Filesystem Protocol (Styx) ist ein Netzwerk-Protokoll, das von den Bell Labs vor über drei Jahrzehnten für das legendäre verteilte Betriebssystem Plan 9 entwickelt wurde. In FreeBSD 14.4 kann der native Hypervisor Bhyve nun das 9P-Dateisystem p9fs(4) nutzen, um virtuellen Maschinen den Zugriff auf Dateien des Hosts zu erlauben. Da p9fs(4) Dateizugriffe direkt über den virtio-p9-Treiber abwickelt, ist diese Methode nicht nur extrem schnell, sondern benötigt im Gegensatz zu NFS, Samba oder SSHFS auch keinen Netzwerkstack. In ferner Zukunft wird p9fs(4) vermutlich durch virtio-fs ersetzt.

Auch FreeBSD 14.4 bereitet sich auf „pkbase“ vor

Upgrades von FreeBSD 14 auf 15 funktionieren wegen der Vereinheitlichung der Basis- und Userland-Pakete manchmal nicht, da libc(7) von libsys(7) abhängt, beim Upgrade via freebsd-update(8) aber libc(7) zuerst installiert wird. Weitere Aufrufe unter anderem von gunzip(8) brechen dann zusammen mit dem Upgrade-Prozess mit einem Fehler ab. Ein Fix von Colin Percival behebt das Problem bei FreeBSD 14.4.

Mit FreeBSD 15 beginnt der Wechsel von den traditionellen Distribution Sets zum neuen „pkgbase“. Bislang war freebsd-update(8) für das Basissystem zuständig (Kernel, Kernel-Module, /usr/bin, /usr/sbin, /lib usw.), während pkg(8) sich um alles andere kümmerte (Tools, X11, Anwendungen). In FreeBSD 15 wird es beide Systeme geben, mit FreeBSD 16 nur noch „pkgbase“, bei dem alle Pakete per pkg(8) verwaltet werden.

Den Umstieg muss also jeder FreeBSD-Anwender in absehbarer Zeit vollziehen: Die letzte Version von FreeBSD 13 ist Version 13.5, die am 30. April in den End-of-Life-Status wechselt. FreeBSD 14.6 als letztes 14er-Release wird bis November 2028 unterstützt, FreeBSD 15 dann bis Dezember 2029 (da greifen die 4 statt 5 Jahre Support-Zyklus). Von da an wird es kein freebsd-update(8) mehr geben.

FreeBSD 14.4 behebt alten OpenZFS-Bug

OpenZFS wurde in FreeBSD 14.4 auf Version 2.2.9 aktualisiert. Das beinhaltet Verbesserungen beim ARC-Shrinking, bessert einige Fehler für „zpool add“-Sicherheitschecks aus und erlaubt „zvol blk-mq“-Synchronization.

Wer FreeBSD schon länger nutzt, kennt das lästige Problem, dass bereits seit FreeBSD 13 und dem Umstieg von ZFS auf OpenZFS neue Installationen auf MBR-partitionierte Laufwerke mit Auto-ZFS in der Regel zu nicht lauffähigen Systemen führen. Das Problem wurde gelöst, indem OpenZFS+MBR nicht mehr als Option angeboten wird.

Für FreeBSD-Neulinge ist es verwunderlich, dass beim ersten Aufruf des Tools „pkg“ für die Paketverwaltung ebendieses pkg(8) zuerst installiert wird. Das merkwürdig wirkende Verhalten ist Absicht, um Inkompatibilitäten zu vermeiden. Das Parsing der Parameter dieses einmalig startenden pkg(7) (ja, 7) wurde bei FreeBSD 14.4 an das Parsing von pkg(8) angeglichen („pkg bootstrap -f“ statt „pkg -f bootstrap“) und könnte bei eigenen Installationsskripten ohne Anpassung zu Fehlern führen.

Mit FreeBSD 14.4 gibt es bei newfs(8) zum Anlegen neuer UFS1/UFS2-Dateisystemen (Unix File System) die neue Option „-u“, um „Soft Updates“ zu deaktivieren. Zuvor mussten die hart eingeschalteten Soft Updates im Nachhinein wieder per tunefs(8) entfernt werden.

Soft Updates sind ein von Marshall Kirk McKusick und Gregory R. Ganger ausführlich beschriebener Mechanismus, um FFS und später UFS1/UFS2 sowohl zu beschleunigen als auch sicherer in Bezug auf die Datenkonsistenz der Metadaten zu machen. Um bei einem plötzlichen Stromausfall oder Systemabsturz trotzdem möglichst valide Metadaten auf den Datenträgern zu haben, wurden bei den klassischen BSDs ursprünglich synchrone Schreibzugriffe eingeführt – dabei wird jede winzige Änderung sofort auf die Festplatte geschrieben. Das Anlegen und Schreiben von Dateien (Inode allokieren, Verzeichniseintrag schreiben, Blockbitmap aktualisieren) war so wegen träger Festplatten-Mechanik extrem langsam.

Soft Updates analysieren unter anderem die Abhängigkeiten der notwendigen Metadatenoperationen voneinander und schreiben diese dann optimiert (aber wiederum synchron) auf den Datenträger. Laut McKusick/Ganger führte das vor allem zu 30 bis 70 Prozent weniger Schreibzugriffen und damit zu einem spürbaren Performance-Boost (nicht vergessen: Ende der 90er hatten wir MFM/RLL hinter uns, nutzten IDE/PATA-Laufwerke, aber standen noch ein paar Jahre vor der Einführung von SATA [~2003]).

Im Laufe von FreeBSD 4.0 (1998), NetBSD 1.5 (2000) und OpenBSD 2.9 (2001) gab es erste Implementationen von Soft Updates. 2010 kam Journaling dazu (SU+J) und 2024 aktivierte FreeBSD bei newfs(8) per Default die Soft Updates. Das war zu einem Zeitpunkt, bei dem OpenBSD 7.4 (2023) den ganzen Soft-Update-Blob komplett entfernte, weil der Code viel zu komplex, schwer wartbar oder erweiterbar war und elend viele Abhängigkeiten mitbrachte. Das mag für manche Open-Source-Systeme kein Problem sein, bei OpenBSD ist es ein kategorisches „no go“.

NetBSD führte bei Version 5.0 als Alternative „Write Ahead Physical Block Logging“ (WAPBL‑Journaling) ein und warf Soft Updates bereits mit Version 6.0 (2012) aus dem System. Außerdem: Viele neue Funktionen konnten nicht implementiert werden, weil sie nicht mit Soft Updates zusammenpassten, und zusätzlich war der Geschwindigkeitsvorteil auf modernen SATA-Festplatten und vor allem -SSDs quasi irrelevant. Ohne Soft Updates bedeutet das bei den BSD-Dateisystemen FFS/UFS1/UFS2 bei einem Crash jedoch deutlich längere Boot-Zeiten wegen des nun notwendigen kompletten fsck(8)-Laufs. Für Datenbestände im Bereich etlicher TByte wäre das nicht mehr praxistauglich, aber da setzt man sowieso ZFS ein.

Kleiner geht’s kaum: FreeBSD 14.4 läuft auf Raspberry Pi Zero 2W

FreeBSD 14.4 ist als Open-Source-Software unter der freien BSD-Lizenz ab sofort kostenlos für die Architekturen amd64, i386, aarch64, armv7, powerpc, powerpc64 und riscv64 von der Projektseite herunterladbar. Alle Neuerungen beschreiben die Entwickler in den Release Notes. Kleiner Bonus: Die Images für SD-Karten wurden um den Device-Tree-Blob für den Raspberry Pi Zero 2W erweitert, sodass FreeBSD 14.4 nun auch auf diesem Winzling läuft.


(axk)



Source link

Weiterlesen

Künstliche Intelligenz

Vorstellung Mercedes VLE und VLS: Ausweichen nach oben


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Weiterlesen nach der Anzeige

Resultate von strategischen Entscheidungen werden in der Autoindustrie immer erst mit einer gewissen Verzögerung sichtbar. Vor ein paar Jahren wollte sich Mercedes mit einer Luxus-Strategie nach oben absetzen, im vergangenen Jahr nahm der Konzern davon wieder Abstand. So schnell lassen sich langfristige Entwicklungsprozesse allerdings nicht über den Haufen werfen, und so bekommt die V-Klasse nicht nur einen neuen Namen, sondern auch eine Ausrichtung, die auf besonders solvente Kunden setzt. Das ist nicht ohne Risiko, doch Mercedes unterfüttert sein Vorhaben durchaus solide.

Auf der Plattform Van.ca entsteht nicht nur ein Van, der sich bis zu einem Luxusmodell ausstatten lässt, sondern auch eine neue Generation von Transportern. Ähnlich wie beim GLC EQ soll die neue Generation gerade an der Front unmissverständlich markenbewusstes Selbstbewusstsein demonstrieren. Ein riesiger Grill, dessen Rand auch noch beleuchtet ist, unterstreicht den Anspruch. Im Van messen die Felgen zwischen 19 und 22 Zoll, für den noch nicht gezeigten Transporter könnte Mercedes auf ein Format wechseln, das den Reifentausch weniger teuer macht.


Mercedes VLE und VLS sollen das Fahrverhalten eines Crossovers mit Vielseitigkeit sowie Raumangebot eines Vans verbinden. (Bild:

Mercedes-Benz

)

Flut an Bildschirmen

Das Ladevolumen des V-Klasse-Nachfolgers liegt zwischen 795 und über 4000 Litern. VLE und VLS können bis zu 2,5 Tonnen an den Haken nehmen. Platz gibt es für bis zu acht Personen, die gegen reichlich Aufgeld auch auf klimatisierten Loungesesseln sitzen können. Je nach Ausstattung sind vorn bis zu drei Bildschirme mit 10 bis 14 Zoll Diagonalen sowie ein Head-up-Display eingebaut. Ähnlich wie BMW im 7er bietet Mercedes für die zweite Reihe ein ausklappbares Display an. Es ist 31,3 Zoll riesig und soll eine Auflösung von 8K haben. Der Bildschirm lässt sich vermutlich aufteilen.


Bis zu drei Bildschirme zwischen 10 und 14 Zoll Diagonale sowie ein Head-up-Display liefern fahrrelevante Informationen und Unterhaltung auf der Seite ohne Lenkrad. (Bild:

Mercedes-Benz

)

Serienmäßig bietet das Startmodell des Mercedes VLE elektrische Schiebetüren mit Fensterhebern – eine ungewöhnliche Kombination. Gegen Aufpreis gibt es Rollos an den hinteren Fenstern und eine Verschattung für das Panoramadach. Aufpreispflichtig bleiben eine motorisierte Heckklappe und eine separat zu öffnende Heckscheibe.

Weiterlesen nach der Anzeige

Zunächst mit zwei E-Antrieben

Zum Start des Verkaufs im Sommer 2026 sind zunächst zwei Antriebe geplant. Das vorläufige Basismodell VLE 300 mit Heckantrieb hat schon 200 kW, der VLE 400 mit Allradantrieb sogar 305 kW. Der Verbrauch im WLTP soll zwischen 18,6 und 21 kWh liegen. Im Zyklus verspricht Mercedes eine Reichweite von bis zu 700 km. Falls das nicht genügen sollte: Ab dem kommenden Jahr soll es den Van auch mit Verbrennungsmotoren geben.


Mit einer Spannungslage von 800 Volt ist der Akku der elektrischen Version in der Lage, bis zu 355 km in 15 Minuten nachzuladen. (Bild:

Mercedes-Benz

)

Doch mit 115 kWh Energiegehalt dürften zahlreiche Anwendungsprofile auch in dieser Klasse abgedeckt sein. Die maximale Ladeleistung liegt mit 300 kW leicht unter dem, was Mercedes in CLA EQ und GLC EQ anbietet. Mercedes setzt in all diesen Modellen auf eine 800-Volt-Plattform. Es ist zu erwarten, dass Ladestopps nicht allzu lang ausfallen werden. In der Praxis dürfte die kleine Differenz zu den Pkw-Modellen ohnehin keine nennenswerte Relevanz haben, denn einerseits ist der Unterschied mit 20 kW nicht allzu groß, andererseits sind Ladesäulen mit mehr als 300 kW in Deutschland momentan selten. In 15 Minuten sollen 355 km WLTP-Reichweite nachgeladen sein.

Familien nicht im Fokus

Mercedes nennt noch keine Preise, doch angesichts des Anspruchs, der hier formuliert wird, dürfte ein sechsstelliger Kaufpreis ohne größere Probleme zu erreichen sein. Wenn also demnächst wieder glücklich-aktiv-sportlich-kinderreiche Familien in Bildern als Zielgruppe angedeutet werden, kann das getrost als Ablenkung aus der Marketing-Maschinerie abgetan werden. Denn sie spielen in den Überlegungen der Produktplaner bestenfalls eine Nebenrolle. Wie bisher wendet sich der Konzern vorrangig an solvente Business-Kunden. Die Hoffnung des Konzerns ist, dass diese die zu erwartende Preisgestaltung mitgeht. Andernfalls muss das Überbleibsel der Luxus-Strategie nämlich tatsächlich ausweichen – und zwar nach unten.

Mehr zur Marke Mercedes


(mfz)



Source link

Weiterlesen

Künstliche Intelligenz

Raspberry Pi: Mini-Tower-Gehäuse bekommt Touchscreen


Der chinesische Hersteller Sunfounder stellt die dritte Variante seines Mini-Tower-Gehäuses für den Raspberry Pi 5 vor. Das Pironman 5 Pro Max erscheint mit zusätzlichen Erweiterungen; am auffälligsten ist der seitliche Touchscreen. Das Gehäuse ist bei Amazon bereits in Deutschland für 146 Euro erhältlich.

Weiterlesen nach der Anzeige

Der Touchscreen besteht aus einem 4,3 Zoll großen IPS-Panel, das 800 × 480 Pixel darstellt und per Display Serial Interface (DSI) mit einem Raspi verbunden wird. Auf den Produktbildern zeigt Sunfounder ähnliche Darstellungsmöglichkeiten wie auf dem bisherigen kleinen OLED-Display, aber ausführlicher, etwa mit Graphen zur Hardware-Auslastung. Nutzer können darauf aber alle möglichen Inhalte laufen lassen, für den Raspi ist das Display ein weiterer Monitor. Das kleine OLED-Display ist ebenfalls weiter im Paket enthalten.

Neu im Paket sind auch ein Kameramodul, das oben aus dem Gehäuse ragt, ein Mikrofon und zwei 3-Watt-Lautsprecher, die sich beide an der Rückseite befinden. Interessenten können so etwa KI-Software wie OpenClaw auf einem Raspi laufen lassen und ohne Headset mit Assistenten kommunizieren.


(Bild:

Sunfounder

)

Alle Erweiterungen des Pironman 5 Max sind auch beim Pironman 5 Pro Max dabei, darunter der Adapter für zwei M.2-Kärtchen. Interessierte können zum Beispiel zwei SSDs oder eine SSD und einen KI-Beschleuniger einbauen. Auch der CPU-Kühler und die Lüfter sind enthalten. Einen Raspberry Pi 5 und ein USB-C-Netzteil muss man getrennt kaufen. Ältere Raspis sind nicht kompatibel.

Sunfounder stellt eine Dokumentation bereit, wie alle Erweiterungen der Pironman-5-Gehäuse in Betrieb zu nehmen sind. Mit dem Raspberry Pi OS, Ubuntu, Kali Linux oder Homebridge lässt sich ein passendes Modul laden.

Weiterlesen nach der Anzeige


(mma)



Source link

Weiterlesen

Beliebt