Anmelden
(Bild: Timofeev Vladimir/Shutterstock.com)
Die Bundesnetzagentur stellt die Weichen für eine Verlängerung der begehrten Mobilfunkfrequenzen. Offen bleibt, wie Neuling 1&1 berücksichtigt wird.
Die Bundesnetzagentur will demnächst auslaufende Nutzungsrechte für Mobilfunkfrequenzen offenbar verlängern und nicht neu versteigern. Entsprechende Pläne will die Behörde ihrem politischen Beirat Mitte Mai vorlegen, berichtet die Deutsche Presse-Agentur (dpa), der die Tagesordnung der Beiratssitzung vorliegt.
Damit käme die Regulierungsbehörde vor allem dem Wunsch der drei etablierten Netzbetreiber Deutsche Telekom, Telefónica-O2 und Vodafone [1] nach, die sich seit Jahren vehement für eine Verlängerung einsetzen. Offen ist derzeit noch, wie die Bundesnetzagentur auch die Bedürfnisse des Neulings 1&1 [2] berücksichtigen und den Wettbewerb im Mobilfunksektor sichern will.
Für die Verlängerung der Nutzungsrechte sollen sich die etablierten Netzbetreiber verpflichten, ihre Netze auf dem Land zu verbessern, berichtet die dpa. Ein "wettbewerbliches Verfahren" solle es dann später geben – hiermit dürfte eine neue Auktion in ein paar Jahren gemeint sein, wenn weitere Nutzungsrechte auslaufen. Die Behörde wollte das gegenüber dpa nicht weiter kommentieren.
Ende 2025 laufen die Nutzungsrechte für Frequenzen in den Bereichen 800 MHz, 1800 MHz und 2,6 GHz aus, die derzeit Telefónica, Deutsche Telekom und Vodafone innehaben. Die drei Netzbetreiber verfügen über weitere Frequenzen im 1800-MHz-Band, deren Nutzungsrechte 2033 zusammen mit anderem Spektrum bei 700 MHz, 900 MHz und 1500 MHz auslaufen. Für die Zeit nach 2033 könnte die Behörde dann mehr zusammenhängendes Spektrum neu vergeben.
Gerade die Frequenzen unter 1000 MHz sind aufgrund ihrer hohen Reichweite sehr begehrt. Bisher teilen sich die drei etablierten Netzbetreiber das Spektrum. Das gerade mit dem Bau eines neuen Netzes beschäftigte Unternehmen 1&1 erhebt ebenfalls Anspruch auf diese sogenannten Flächenfrequenzen. Einer Aufteilung des Spektrums unter den vier Wettbewerbern hat die Bundesnetzagentur bereits eine Absage erteilt.
Nur kurzlebig war die Idee, Nutzungsrechte für das Spektrum bei 800 MHz zu verlängern und die Vergabe der Frequenzen bei 900 MHz auf 2025 vorzuziehen [3]. Einen von 1&1 ins Spiel gebrachten Tausch von Frequenzen lehnen die anderen Netzbetreiber ab.
Den Informationen der dpa zufolge will die Bundesnetzagentur in der Beiratssitzung am 13. Mai einen sogenannten Konsultationsentwurf vorlegen. Darin legt die Behörde ihre Pläne dar, um sie den betroffenen Unternehmen und Organisationen zur Kommentierung vorzulegen. Erst nach dieser Konsultationsphase erfolgt eine Entscheidung.
Schon seit 2021 signalisiert die Bundesnetzagentur, dass sie eine Verlängerung der Nutzungsrechte um bis zu acht Jahre in Erwägung zieht [4]. Im Beirat dürfte das Vorhaben auf Wohlwollen stoßen, die Politik verspricht sich davon bessere Infrastruktur. Ein Wermutstropfen: Dem Staat entgeht viel Geld – bei der letzten Auktion 2019 kamen rund 6,6 Milliarden Euro zusammen [5].
Dass der Regulierer nach der Konsultation seine Pläne noch grundlegend ändert, ist unwahrscheinlich. Auch Kritik aus der Monopolkommission [6] und vom Bundeskartellamt [7] konnte die Behörde bisher nicht von ihrer Linie abbringen.
Grundsätzlich besteht auch 1&1 nicht auf einer Auktion – alle Netzbetreiber würden das Geld lieber behalten. So hat sich auch 1&1-CEO Ralph Dommermuth offen für andere Verfahren gezeigt, "solange sie 1&1 fair berücksichtigen". Wie die Bundesnetzagentur das sicherstellen will, wird der Konsultationsentwurf zeigen, sobald er veröffentlicht ist.
URL dieses Artikels:
https://www.heise.de/-9704454
Links in diesem Artikel:
[1] https://www.heise.de/news/Frequenzvergabe-Mobilfunker-gegen-gesetzliche-Vorfestlegung-auf-Auktion-5999924.html
[2] https://www.heise.de/news/Netzstart-von-1-1-Mit-500-Masten-zum-Mobilfunknetzbetreiber-9568535.html
[3] https://www.heise.de/news/Frequenztausch-Bundesnetzagentur-schlaegt-Verfahren-fuer-Mobilfunk-Auktionen-vor-7272945.html
[4] https://www.heise.de/news/Frequenzvergabe-Chefregulierer-offen-fuer-Verlaengerung-statt-Auktion-6279445.html
[5] https://www.heise.de/news/5G-Frequenzauktion-beendet-4445365.html
[6] https://www.heise.de/news/Netze-1-1-braucht-eine-Chance-im-Mobilfunkmarkt-9573751.html
[7] https://www.heise.de/news/Frequenzplan-der-Netzagentur-Bundeskartellamt-sorgt-sich-um-1-1-9356839.html
[8] mailto:vbr@heise.de
Copyright © 2024 Heise Medien
(Bild: Daniel AJ Sokolov)
Alle großen US-Mobilfunker haben ihre Kunden verraten und jahrelang deren Standortdaten verkauft. Jetzt sollen sie Strafe zahlen – für ein paar Monate.
T-Mobile USA, AT&T, Verizon und Sprint haben die Standortdaten ihrer Mobilfunkkunden verkauft, ohne die Zustimmung der Kunden einzuholen. Das sollten bitte die Käufer der Daten tun. Die haben aber den Zugriff auf die Daten weiterverkauft und es ihren Käufern überlassen, mittels Mausklick zu behaupten, sie hätten die vorgeschriebenen Zustimmungen der Betroffenen eingeholt. Dutzende Firmen haben zugegriffen und sich über automatische Schnittstellen (API) bedient. Jetzt sollen die Netzbetreiber Strafe zahlen, aber nur für einen Bruchteil der Zeit.
Entsprechende Strafbescheide [1] hat die US-Regulierungsbehörde FCC (Federal Communications Commission) am Montag veröffentlicht. Offiziell wurden die Ortungsdienste für biedere Zwecke beworben, etwa um eigene, verlorene Geräte wiederzufinden, oder Handynutzung in Gefängnissen aufzuspüren. Tatsächlich haben Kopfgeldjäger, Geheimdienste, Privatdetektive, diverse Unternehmen und auch Polizeibehörden illegal Amerikaner überwacht. Dabei ist die Standortabfrage seit 2007 nur mit Zustimmung des Betroffenen oder mit richterlicher Genehmigung oder in bestimmten Notfällen zulässig.
Ein Sheriff wurde deswegen zu sechs Monaten Gefängnis verurteilt. Er hatte stets angeklickt, dass seine Abfragen legal seien. Dazu lud er beliebige Dokumente hoch, beispielsweise eine Autoversicherungspolizze oder einzelne Seiten aus einem Polizeihandbuch, aber nicht die notwendigen richterlichen Genehmigungen, weil er die nicht bekommen hätte. Überprüft hat seine Abfragen niemand – und das ganz bewusst. Die LBS-Firma, bei der der Sheriff den Überwachungszugriff gekauft hat, meint, es sei Aufgabe des Sheriffs selbst, seine Einhaltung der Vorschriften zu überprüfen.
T-Mobile soll nun gut 80 Millionen US-Dollar Strafe zahlen, AT&T mehr als 57 Millionen, Verizon knapp 47 Millionen und Sprint über zwölf Millionen Dollar. In Summe sind das rund 196 Millionen Dollar. Die bestraften Netzbetreiber werden die Strafen wohl vor Gericht bekämpfen.
Merkwürdig ist die Berechnungsweise der Strafen. Die Behörde zählt nicht die Zahl der Betroffenen, sondern die Zahl der direkten Käufer der Standortdaten (sogenannte Aggregatoren) sowie deren Kunden (sogenannte Location Based Services, LBS). Beispielsweise bei T-Mobile waren das 81.
Diese Zahl multipliziert die Behörde mit 2.500 US-Dollar pro Tag, an denen die LBS-Firmen direkten API-Zugriff hatten – allerdings nicht für den gesamten Zeitraum der Rechtsverletzung, denn von Rechts wegen darf die Behörde nur ein Jahr rückwirkend ab Verfahrenseröffnung strafen. Aber sie zieht auch nicht ein Jahr heran, sondern den 9. Juni 2018. Das ist 30 Tage nach einem Bericht der New York Times [2] über die Anklage gegen den erwähnten Sheriff.
Die FCC erachtet demnach nur das Verhalten der Netzbetreiber ab 30 Tagen nach diesem Bericht für strafwürdig. Die Netzbetreiber haben noch bis zu zehn Monate nach dem Zeitungsbericht die Standortdaten ihrer Kunden verkauft. Hinzu kommen ein Basisbetrag von 40.000 Dollar pro LBS-Partner sowie ein Aufschlag von 50 bis 100 Prozent, je nach dem wie verwerflich sich der Netzbetreiber in den Augen der Behörde nach Aufdeckung durch die New York Times verhalten hat.
Eingeleitet hat die FCC das Verfahren noch unter US-Präsident Donald Trump, damals auch mit Zustimmung der republikanischen Mehrheit in der FCC. Inzwischen haben die Demokraten dort eine 3:2 Mehrheit, und nun sind die Republikaner plötzlich gegen die Strafbescheide. Einer der beiden vertritt die obskure These, dass der Verkauf der Standortdaten völlig legal sei, außer wenn der Nutzer gerade telefoniert. Und überhaupt hätte eine andere Behörde das Verfahren führen sollen. Der andere Republikaner in der FCC meint, es läge nur ein einzelner Rechtsverstoß pro Netzbetreiber vor, die Berechnung nach Tagen und einkaufenden Firmen sei unzulässig. Die Behörde hätte gar keine Strafen verhängen und sich stattdessen von den Netzbetreiber versprechen lassen sollen, in Zukunft brav zu sein.
Zwar geben die Netzbetreiber an, den Verkauf der Standortdaten inzwischen eingestellt zu haben. Das heißt aber nicht, dass die LBS-Anbieter erwerbslos geworden sind. Heute werden die Standortdaten heimlich bei allerlei Smartphone-Apps geerntet [3] und verkauft, gerne auch an Behörden, die solche Daten selbst nicht erheben dürften, wie beispielsweise die NSA (National Security Agency). In geringerem Umfang werden WLAN-Hotspots, Bluetooth-Beacons und IMSI-Catcher eingesetzt, um Standortdaten von Mobiltelefonen und anderen Geräten zu erfassen.
Treppenwitz: Der US-Geheimdienst NSA warnt selbst seit mindestens vier Jahren vor der Gefahr der Standortüberwachung von Mobilfunk-Nutzern für die Nationale Sicherheit. Dennoch fehlt den USA bis heute ein umfassendes Datenschutzgesetz.
URL dieses Artikels:
https://www.heise.de/-9703107
Links in diesem Artikel:
[1] https://www.fcc.gov/document/fcc-fines-largest-wireless-carriers-sharing-location-data
[2] https://www.nytimes.com/2018/05/10/technology/cellphone-tracking-law-enforcement.html
[3] https://www.heise.de/news/Massenueberwachung-zum-Sparpreis-US-Polizei-kann-Bewegungsprofile-analysieren-7251554.html
[4] https://www.fcc.gov/document/fcc-fines-largest-wireless-carriers-sharing-location-data
[5] mailto:ds@heise.de
Copyright © 2024 Heise Medien
(Bild: fizkes/Shutterstock.com)
Viele Entwicklerinnen und Entwickler werden in Bezug auf ihre tägliche Arbeitszeit abwertend als "nine-to-five" bezeichnet. Ist das wirklich fair oder sinnvoll?
Wenn Sie bereits einige Zeit in der Softwareentwicklung tätig sind, dann sind Ihnen die Begriffe "nine to five"-Entwicklerin oder -Entwickler wahrscheinlich schon begegnet. Vielleicht wurde eine Kollegin oder ein Kollege so bezeichnet, oder sogar Sie selbst. In der Regel wird dieser Ausdruck nicht positiv verwendet, sondern eher abwertend. Denn jemand, der "von 9 bis 17 Uhr" arbeitet, denkt – zumindest laut diesem Klischee – vor 9 Uhr morgens nicht über die Arbeit nach – und nach 17 Uhr erst recht nicht mehr.
Und das wird oft als verwerflich angesehen, denn das Mindeste, was man von einer Entwicklerin oder einem Entwickler erwarten könnte, ist, dass sie sich rund um die Uhr mit Softwareentwicklung beschäftigen und weiterbilden. Dass dies allerdings nicht der Realität der meisten Menschen entspricht, wird gerne übersehen. Und über genau diese überzogene Erwartungshaltung müssen wir sprechen. Ist es wirklich fair oder gar sinnvoll, Entwicklerinnen und Entwickler nach ihrer Arbeitszeit zu bewerten?
Unser aller Alltag ist getaktet, und das in hohem Maße. Tatsächlich werden wir schon von klein auf daran gewöhnt. Schülerinnen oder Schüler müssen morgens zu einer bestimmten Uhrzeit aufstehen und sich innerhalb einer gewissen Zeit fertig machen, um pünktlich um 8 Uhr in der Schule zu sein. An der Universität beginnt der Tag häufig später, etwa um 9 oder 10 Uhr, und in den meisten Büros geht es ebenfalls um 9 Uhr los. Diese Zeiten haben sich etabliert und die meisten Menschen richten sich danach – unabhängig davon, ob dies zu ihrem biologischen Rhythmus passt oder nicht.
Doch hier beginnt es schon, unfair zu werden: Denn diejenigen, die ein früher Start in den Tag am meisten trifft (Kinder und Jugendliche), müssen morgens am frühesten beginnen. Und das, obwohl inzwischen erwiesen ist, dass ein späterer Schulstart besser für die geistige und körperliche Entwicklung wäre. Aber nein: Kinder und Jugendliche sollen sich nicht beschweren; sie werden es schon schaffen, jeden Tag zu einer frühen Uhrzeit hoch konzentriert im Unterricht zu sitzen. Und wenn ein Kind damit Schwierigkeiten hat, ist natürlich das Kind und nicht das System schuld …
Unabhängig davon lässt sich nicht leugnen, dass es Menschen gibt, die eher früher aufstehen und solche, die eher später den Tag beginnen – die sogenannten Lerchen und die sogenannten Eulen. Mir ist unklar, wann es angesagt wurde, auf Menschen hinabzublicken, weil deren Tagesrhythmus nicht mit dem eigenen übereinstimmt, aber Lerchen versuchen häufig, den Eulen ein schlechtes Gewissen einzureden. Sie argumentieren, dass man morgens so viel verpasse und schimpfen über Langschläfer und Faulpelze. Umgekehrt müssen sie sich abends allerdings von den Eulen anhören, dass sie langweilig seien und kein Leben hätten. Wenn sie nicht jeden Morgen so früh aufstehen würden, könne man abends noch länger etwas mit ihnen unternehmen.
Hier treffen also zwei biologische Modelle aufeinander, von denen jedes glaubt, das überlegene zu sein. Eigentlich ist die ganze Diskussion völlig sinnlos. Doch mit Initiativen wie dem "5-Uhr-Club" werden solche Unterschiede genutzt, um andere herabzusetzen und sich selbst als Teil einer scheinbar höherwertigen und elitären Gruppe zu feiern. Ich persönlich bin kein Freund dieser Vorgehensweise.
Meine Abneigung gegen solche Haltungen rührt jedoch nicht daher, dass ich eine ausgesprochene Nachteule wäre: Ich stehe selbst oft relativ früh auf. Mein Problem damit ist viel eher, dass dieses Verhalten grundsätzlich überheblich und arrogant ist. Wir sollten als Gesellschaft doch vielmehr danach streben, jedem einzelnen Menschen gerecht zu werden. Dies entspricht auch der grundlegenden Forderung des Agilen Manifests [2]: "Individuals and Interactions over Processes and Tools". In der Informatik und Softwareentwicklung ist zudem die Arbeitszeit nicht zwingend an feste Zeiten gebunden. Das betrifft sowohl die Frage, wann gearbeitet wird, als auch die Dauer der Arbeit.
Wie ich bereits erwähnte: Ich bin keine Eule. Ich stehe grundsätzlich gerne früh auf. Es gefällt mir, vor allen anderen wach zu sein, zu erleben, wie die Natur erwacht, die ersten Vögel zu hören und den Sonnenaufgang zu beobachten. Je nach Jahreszeit stehe ich manchmal sogar schon um vier oder fünf Uhr morgens auf. Aber: Das fällt mir nicht immer leicht, und es bedeutet auch, dass ich abends entsprechend früh ins Bett gehen muss.
Ich bin aber auch keine Lerche: Wenn ich nicht wegen anstehender Termine früh aufstehen müsste, würde ich oft auch gerne bis fünf Uhr morgens wach bleiben und erst dann schlafen gehen. Das habe ich während meiner Schul- und Studienzeit in den Ferien oft getan – ich habe buchstäblich die Nacht zum Tag gemacht. Das entspricht auch ein wenig der romantisierten Vorstellung von Hackern, wie beispielsweise Neo in "Matrix", die nicht von 9 bis 17 Uhr arbeiten, sondern von 21 Uhr bis 5 Uhr morgens. Mit diesem Modell könnte ich mich durchaus anfreunden, zumindest zeitweise. In gewisser Weise wäre ich also manchmal gerne ein "nine to five"-Entwickler.
Wäre ich dann produktiver? Nicht unbedingt. Denn ob ich von 9 bis 17 Uhr arbeite oder von 21 Uhr bis 5 Uhr morgens: Es sind beides jeweils acht Stunden. Und keine dieser Zeiten ist per se besser oder schlechter als die andere. Deshalb finde ich es wenig sinnvoll, Menschen danach zu be- oder gar verurteilen, wann sie arbeiten. Eine Entwicklerin oder ein Entwickler leistet nicht bessere Arbeit, weil sie oder er früher oder später beginnt.
Die Qualität der Arbeit hängt vielmehr davon ab, ob die Arbeitszeit zum individuellen Tagesrhythmus passt. Wenn ich ständig gegen meine innere Uhr arbeiten muss, wirkt sich das natürlich auf die Qualität meiner Arbeit aus. Es wäre auch merkwürdig, wenn das anders wäre. Doch auch wenn man seine biologische Uhr berücksichtigt, ist der Tagesablauf nicht jeden Tag gleich. Wir sind keine Roboter, und unsere Gesellschaft sollte das berücksichtigen.
Hinzu kommt aber noch ein weiterer Aspekt: Acht Stunden sind nicht gleich acht Stunden. Was die eine Entwicklerin in acht Stunden schafft, gelingt dem anderen Entwickler vielleicht in einer ganzen Woche nicht – oder umgekehrt. Es macht daher aus einer bestimmten Perspektive kaum Sinn, Softwareentwicklung ausschließlich nach Zeit zu bemessen. Dies war bei rein körperlichen Tätigkeiten am Fließband sinnvoll, weil Anwesenheit gleichzeitig auch Arbeitszeit bedeutete.
Aber bei einer vorrangig kreativen und geistigen Tätigkeit wie der Softwareentwicklung trifft das nicht zu. Ich könnte acht Stunden in einem Büro sitzen, sehr beschäftigt aussehen und den ganzen Tag rein gar nichts erledigen. Oder ich könnte eine schlaflose Nacht im Bett verbringen, ein Problem durchdenken und plötzlich die Lösung finden, die mir die ganze Woche über nicht eingefallen ist. Wie bewertet man das? Hätte ich den entscheidenden Gedanken in der Nacht auch ohne die vorherige vergebliche Grübelei gefunden? Wer weiß. Und weitergedacht: Auf welche Kostenstelle verbuche ich eigentlich die Idee, die mir morgens unter der Dusche gekommen ist?
Unabhängig davon hängt die Zeit, die ich für eine Aufgabe benötige, stark von meiner Erfahrung ab. Auf Konferenzen, auf denen ich Live-Coding durchführe, wird mir oft gesagt, es sei beeindruckend, wie schnell ich Software entwerfen und programmieren könne. Was dabei oft übersehen wird: Den entsprechenden Vortrag habe ich in dieser oder einer ähnlichen Form vielleicht schon hundertmal gehalten. Ich weiß also genau, was ich mache, welche Probleme auftreten können und was mein Ziel ist.
Jeder Tastendruck sitzt, und auch wenn es oft spontan aussieht, ist häufig alles im Vorfeld geplant. Selbst die Fehler, die ich live mache, sind in 90 Prozent der Fälle einkalkuliert, denn Fehler bieten bekanntlich die beste Lerngelegenheit. Ich führe mein Publikum gerne bewusst in eine Falle, um dann gemeinsam mit ihnen einen Ausweg zu finden. Das ist lehrreicher, als wenn ich einfach von Anfang an erkläre, wie etwas funktioniert. Es mag also den Anschein haben, als würde mir alles leichtfallen, aber in Wirklichkeit mache ich vieles davon nicht zum ersten Mal. Auch ich koche nur mit Wasser.
Und das merken Sie, wenn Sie mir eine Aufgabe stellen, die mir überhaupt nicht liegt: Nehmen wir an, irgendetwas mit CSS – dann können Sie sicher sein, dass ich deutlich länger dafür benötigen werde als jemand, die oder der halbwegs Erfahrung mit CSS hat. Das verdeutlicht, was ich meine, wenn ich sage: Acht Stunden sind nicht einfach acht Stunden. Je nach Thema benötigt die eine oder der andere für dieselbe Aufgabe deutlich mehr oder weniger Zeit, einfach weil der persönliche Hintergrund unterschiedlich ist.
Daher ergibt es wenig Sinn, jemanden nur deshalb als "nine to five"-Entwicklerin oder -Entwickler zu diskreditieren: Erstens wissen Sie nicht, ob dies nicht vielleicht gerade die Zeit ist, in der die Person tatsächlich am produktivsten ist, und zweitens ist die viel interessantere Frage: Was erreicht die Person in dieser Zeit?
Der eigentlich wichtige Punkt ist doch: Was kommt am Ende bei alldem heraus? Stimmt die Qualität des Ergebnisses? Es kann durchaus sein, dass jemand, der von 9 bis 17 Uhr arbeitet, bessere Ergebnisse liefert als jemand, der freiwillig 80 Stunden pro Woche schuftet. Es könnte auch sein, dass jemand in nur vier Stunden pro Tag mehr erreicht als ein anderer in acht Stunden. Das hängt alles vom jeweiligen Themengebiet und der spezifischen Aufgabe ab und ist daher einfach nicht vergleichbar.
Dass wir in der IT-Branche immer noch die Arbeitszeit als Metrik verwenden, ist eigentlich absurd: Ja, diese Metrik funktioniert, aber nur weil sie funktioniert, ist sie noch lange keine gute Metrik. Auch "Lines of Code" könnte man als Maßstab heranziehen, und dennoch würde niemand ernsthaft vorschlagen, die Produktivität von Entwicklerinnen und Entwicklern anhand der Anzahl geschriebener Zeilen zu bewerten. Genauso schlecht ist der Ansatz, die benötigte Zeit zu messen. Wir tun dies nur, weil uns keine bessere Alternative zur Verfügung steht. Eine gute Idee ist es deshalb noch lange nicht.
Damit kommen wir nun zum eigentlichen Kern dieses Artikels: Der Begriff "nine to five" wird oft benutzt, um auszudrücken, dass jemand angeblich keinen guten Code schreibt oder keine durchdachten Lösungen entwickelt. Dieser Vorwurf zielt letztlich auf die Qualität der Ergebnisse ab. Insofern: Wenn Sie schon Kritik üben möchten, dann benennen Sie doch konkret, was Ihnen an dem Ergebnis nicht gefällt, aus technischer oder fachlicher Sicht.
Treten Sie in eine konstruktive Diskussion über die Inhalte ein. Es ist jedoch wenig sinnvoll, jemanden nur darauf zu reduzieren, dass sie oder er "nur acht Stunden" arbeitet und daraus dann zu folgern, die Person sei faul oder bequem – das finde zumindest ich persönlich menschlich einfach daneben. Vielleicht arbeitet diese Entwicklerin oder dieser Entwickler tatsächlich bereits nach bestem Wissen und Gewissen und manches gelingt vielleicht einfach nicht besser.
Möglicherweise liegt das an mangelnder Erfahrung, vielleicht fehlt eine zweite Meinung, vielleicht sind die eingesetzten Technologien neu und unbekannt, oder oder oder. In solchen Fällen sollten Sie daher also eher die- oder derjenige sein, die oder der hilfsbereit und konstruktiv ist und dazu beiträgt, andere voranzubringen, statt sich über deren Arbeitszeiten oder angeblich minderwertige Einstellung lustig zu machen.
Und wenn Sie das nächste Mal mitbekommen, dass eine Kollegin oder ein Kollege herablassend als "nine to five"-Entwicklerin oder -Entwickler bezeichnet wird, dann unterstützen Sie diese Person, statt mitzumachen. Nehmen Sie sich einen Moment Zeit, um etwas Positives beizutragen. Wer weiß, was Sie damit zum Guten bewirken.
URL dieses Artikels:
https://www.heise.de/-9692451
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://www.heise.de/hintergrund/20-Jahre-Agiles-Manifest-definitiv-den-Kinderschuhen-entwachsen-5049684.html
[3] mailto:map@ix.de
Copyright © 2024 Heise Medien
(Bild: Artur Szczybylo/Shutterstock.com)
Das neue, kompakte Werk des DOTNET-DOKTORs zu .NET 8.0 richtet sich an Umsteigerinnen und Umsteiger von .NET 7.0.
Auf Wunsch einiger Leserinnen und Leser habe ich alle Neuerungen in .NET 8.0 zu einem kompakten, kostengünstigen Buch (186 Seiten, ab 9,99 €) zusammengefasst. .NET 8.0 Update [1] ist ein Umsteigerbuch für Entwicklerinnen und Entwickler, die bisher mit .NET 7.0 gearbeitet haben. Es zeigt systematisch und anhand vieler praktischer Programmcodebeispiele die Neuerungen in .NET 8.0 in folgenden Bereichen auf:
(Bild: www.it-visions.de [2])
Das neue Buch gibt es in verschiedenen Formaten auf den folgenden Vertriebswegen:
Gedruckt bei Amazon.de: 14,99 € [3]
Kindle-E-Book bei Amazon.de: 9,99 € [4]
PDF bei www.IT-Visions.de (per EURO-Rechnung): 14,99 € [5]
PDF über Leanpub.com (Zahlung in US-Dollar per Kreditkarte oder PayPal): 14,99 US-$ [6]
URL dieses Artikels:
https://www.heise.de/-9699201
Links in diesem Artikel:
[1] https://www.IT-Visions.de/NETUpdate
[2] https://www.it-visions.de/buecher/buch.aspx?b=N8U
[3] https://www.amazon.de/exec/obidos/ASIN/3934279554/itvisions-21
[4] https://www.amazon.de/exec/obidos/ASIN/3934279554/itvisions-21
[5] https://it-visions.de/About/Bestellung.aspx?vid=11378
[6] https://leanpub.com/net8
[7] mailto:map@ix.de
Copyright © 2024 Heise Medien
(Bild: momente/Shutterstock.com)
Seven years after its abolition, the USA is reintroducing net neutrality. Difficult questions remain unanswered.
The USA is reintroducing The Three Commandments of Net Neutrality. They were adopted in 2015 but abolished at the end of 2017. [1] In addition, foreign mobile operators and internet service providers (ISPs) can be excluded from the market if they undermine national security – and the authority makes immediate use of this. ISPs must also report and resolve incidents and disclose their network management practices. This was decided by the Federal Communications Commission (FCC) on Thursday.
The three Democrats on the Commission voted in favor of the resolution, while the two Republicans voted against it. The idea of net neutrality goes back to the FCC in 2004 under Republican President George W. Bush. However, today's Republican Party has little in common with the party of that time. Together with large ISPs, it will attempt to have the regulation repealed by a parliamentary resolution or a court ruling. However, the 2015 net neutrality ruling [2] has already been unsuccessfully challenged in court. Net neutrality is very popular among the US population across all voter groups.
New are unclear statements on the relationship between the FCC requirements and the net neutrality regulations of individual US states, as well as a "wash me, but don't get me wet" rule for zero rating. On the new conflict issue of network slicing and regarding 5G IoT (Internet of Things), the authority is trying to get out of the affair with "let's take a look, then we'll see". This blurring could provide opponents of net neutrality with new starting points to convince a court to repeal net neutrality in part or in full.
Net neutrality actually sounds basic. The Three Commandments apply to retail broadband internet access offered to the mass market, whether fixed or mobile:
There is also a more general good conduct rule. The devil is in the details, especially as some technical measures can be anti-competitive or anti-consumer as well as pro-competitive.
With zero rating, the data consumption of certain applications or services is not deducted from the data volume included in a tariff. This gives the excluded services a competitive advantage over competitors and fundamentally undermines net neutrality. On the other hand, it could enable new service providers to enter markets that they would otherwise not be able to.
The FCC has not issued a specific rule on this, but would like to assess zero rating on a case-by-case basis in light of the general good conduct rule. It does clarify that it takes a critical view of paid zero-rating, where a service provider gives money or other benefits to an ISP if its service does not impact end users' data volumes. However, the final assessment of the impact of a particular zero-rating offer on the open Internet will depend on "the totality of the circumstances".
Network slicing is particularly fashionable in 5G mobile networks. Fixed capacities in the radio cells are allocated exclusively to certain services or customers. However, unused capacity remains unused and is not temporarily made available to other users. If, for example, an ISP provides a certain video streaming service via a virtually separate network, the question arises as to whether this is still broadband Internet access at all, which falls under the net neutrality regulations, or the wireless equivalent of cable TV, which is not an Internet service and is not regulated here.
The problem is that many network slices limit the capacity of non-reserved bandwidth, thus leading to disadvantages in undisputed broadband Internet access. In addition, there may be competitive disadvantages for virtual mobile network operators (MVNOs) that lease onto a third-party network. As a rule, they cannot offer network slicing.
The authority notes that the market and supply are still developing here. It is therefore too early for regulation. However, it promises to "take action against harmful use of network slicing". In particular, services that cannot be offered via the open Internet are likely to meet with approval – the authority cites remote medical operations with robots as an example. Interference and latency issues on the open Internet must be avoided at all costs.
Legally, the reintroduction of net neutrality is based on the FCC reclassifying broadband Internet access as a telecom service. This gives the authority the power to regulate so that it can issue net neutrality regulations. At the same time, the Internet and mobile communications are once again subject to national security regulations.
And the FCC takes advantage of this immediately. Five telecom providers owned by the People's Republic of China will be excluded from the US telecom market. This affects China Mobile, China Telecom Americas (CTA), China Unicom (CUA), Pacific Networks and Comnet. In the fixed network, the FCC has already closed China Telecom in the USA in 2021 [3]. This was not possible for the internet and mobile networks because the Republicans under President Donald Trump had withdrawn the FCC's authority to abolish net neutrality.
Following publication in the US Federal Register, the five Chinese providers have 60 days to cease operations in the USA. Net neutrality will also take effect on the same date. ISPs that market shared Internet access for multi-party homes will be given 180 days to adjust their contracts and business practices.
What remains unclear is the relationship between the federal net neutrality order and the net neutrality regulations introduced by about a dozen US states [4]. While the FCC could declare such state rules invalid, it has deliberately not done so.
As long as US states implement their rules in a way that is consistent with federal rules, the FCC wants to stay out of it and is even happy to support it. What this means in detail, and when the FCC would intervene, nobody knows. That will probably also depend on which political party is in charge at the FCC.
URL dieses Artikels:
https://www.heise.de/-9698971
Links in diesem Artikel:
[1] https://www.heise.de/news/USA-Netzneutralitaet-wird-abgeschafft-3918679.html?from-en=1
[2] https://www.heise.de/news/Rechtskraeftig-US-Netzneutralitaet-war-legal-4213865.html?from-en=1
[3] https://www.heise.de/news/China-Telecom-soll-in-den-USA-zusperren-6233744.html?from-en=1
[4] https://www.heise.de/news/Nach-Abschaffung-US-Staaten-wollen-Netzneutralitaet-foerdern-oder-einklagen-3920201.html?from-en=1
[5] https://www.heise.de/downloads/18/4/5/7/9/9/2/5/DOC-401676A1.pdf
[6] mailto:ds@heise.de
Copyright © 2024 Heise Medien
(Bild: momente/Shutterstock.com)
7 Jahre nach Abschaffung führen die USA die Netzneutralität wieder ein. Diffizile Fragen bleiben dabei offen.
Die USA führen Die Drei Gebote der Netzneutralität wieder ein. Sie wurden bereits 2015 beschlossen, Ende 2017 aber wieder abgeschafft [1]. Hinzu kommt die Möglichkeit, ausländische Mobilfunker und Internet Service Provider (ISP) vom Markt auszuschließen, wenn sie die Nationale Sicherheit unterminieren – und die Behörde macht sofort davon Gebrauch. Außerdem müssen ISPs Störungen melden und beheben sowie ihre Netzmanagementpraktiken offenlegen. Das hat die Regulierungsbehörde FCC (Federal Communications Commission) am Donnerstag beschlossen.
Die drei Demokraten der Commission stimmten für den Beschluss, die beiden Republikaner dagegen. Dabei geht die Idee der Netzneutralität auf die FCC im Jahr 2004 unter dem Republikanischen Präsidenten George W. Bush zurück. Doch die heutige Partei der Republikaner hat mit der damaligen wenig gemein. Sie wird, gemeinsam mit großen ISPs, versuchen, die Verordnung durch einen Parlamentsbeschluss oder ein Gerichtsurteil aufheben zu lassen. Allerdings wurde bereits der 2015 gefällte Netzneutralitätsbeschluss erfolglos vor Gericht angefochten [2]. In der US-Bevölkerung ist Netzneutralität quer durch die Wählerschichten sehr beliebt.
Neu sind undeutliche Aussagen zum Verhältnis der FCC-Vorgaben zu Netzneutralitätsbestimmungen einzelner US-Staaten, sowie eine "Wasch mich, aber mach mich nicht nass"-Regelung für Zero Rating. Zum neuen Konfliktthema Network Slicing sowie hinsichtlich 5G IoT (Internet of Things) versucht die Behörde, sich mit "schauen wir einmal, dann sehen wir schon" aus der Affäre zu ziehen. Diese Verschwommenheit könnte Gegnern der Netzneutralität neu Ansatzpunkte liefern, ein Gericht davon zu überzeugen, die Netzneutralität in Teilen oder ganz aufzuheben.
Eigentlich klingt Netzneutralität ganz einfach. Die Drei Gebote [3] gelten für im Einzelhandel für den Massenmarkt angebotene Breitband-Internetzugänge, egal ob Festnetz oder mobil:
Zudem gibt es eine allgemeinere Wohlverhaltensregel. Der Teufel liegt in Details, zumal sich einige technischen Maßnahmen sowohl wettbewerbs- oder verbraucherfeindlich als auch -freundlich auswirken können.
Bei Zero Rating wird der Datenverbrauch bestimmter Applikationen oder Dienste nicht vom inkludierten Datenvolumen eines Tarifs abgezogen. Das verschafft den ausgenommenen Diensten einen Wettbewerbsvorteil gegenüber Mitbewerbern und unterläuft grundsätzlich die Netzneutralität. Andererseits könnte es neuen Diensteanbieter Einstiege in Märkte ermöglichen, den sie sonst nicht schaffen würden.
Die FCC hat dazu keine spezielle Regel erlassen, sondern möchte Zero Rating im Einzelfall im Licht der allgemeinen Wohlverhaltensregel beurteilen. Sie stellt immerhin klar, dass sie bezahltes Zero Rating, bei dem ein Diensteanbieter einem ISP Geld oder andere Vorteile gibt, wenn sein Dienst nicht das Datenvolumen der Endkunden belastet, kritisch sieht. Bei der endgültigen Beurteilung der Auswirkungen eines bestimmten Zero-Rating-Angebots auf das offene Internet werde es aber auf "die Gesamtheit der Umstände" ankommen.
Network Slicing ist vor allem in 5G-Mobilfunknetzen in Mode. Dabei wird bestimmten Diensten oder Kunden feste Kapazitäten in den Funkzellen exklusiv zugewiesen. Nicht genutzte Kapazitäten liegen allerdings brach und werden nicht temporär anderen Nutzern zur Verfügung gestellt. Vermittelt ein ISP beispielsweise einen bestimmten Videostreaming-Dienst über ein virtuell abgetrenntes Netz, stellt sich die Frage, ob das überhaupt noch ein Breitband-Internetzugang ist, der unter die Netzneutralitätsbestimmungen fällt, oder das drahtlos Äquivalent von Kabelfernsehen, das kein Internetdienst ist und hier nicht reguliert wird.
Problematisch ist, dass viele Network Slices die Kapazität der nicht-reservierten Bandbreite einschränken, also zu Nachteilen beim unstreitigen Breitband-Internetzugang führen. Außerdem kann es Wettbewerbsnachteile für virtuelle Mobilfunkanbieter (MVNO) gebe, die sich in ein fremdes Netz einmieten. Sie können Network Slicing in der Regel nicht anbieten.
Die Behörde stellt fest, dass sich und Markt und Angebot hier noch entwickeln. Daher sei es für Regulierung zu früh. Sie verspricht aber, "gegen schädliche Verwendung von Network Slicing vorzugehen". Speziell Dienste, die sich über das offene Internet eher nicht anbieten lassen, dürften auf Wohlwollen treffen – die Behörde nennt medizinische Fernoperationen mit Robotern als Beispiel. Dabei müssen Störungen und Latenzprobleme im offenen Internet ja unbedingt vermieden werden.
Rechtlich fußt die Wiedereinführung der Netzneutralität darauf, dass die FCC Breitband-Internetzugang wieder als Telecom-Dienst einstuft. Das verschafft der Behörde die Zuständigkeit für Regulierung, sodass die sie Netzneutralitätsverordnung erlassen kann. Gleichzeitig fällt Internet und Mobilfunk damit auch wieder unter Bestimmungen zum Schutz der Nationalen Sicherheit.
Und das nutzt die FCC sofort. Fünf Telecom-Anbieter, die im Eigentum der Volksrepublik China stehen, werden vom US-Telecommarkt ausgeschlossen. Das betrifft China Mobile, China Telecom Americas (CTA), China Unicom (CUA), Pacific Networks und Comnet. Im Festnetz hat die FCC China Telecom bereits 2021 in den USA zugesperrt [4]. Für Internet und Mobilfunk war das nicht möglich, weil die Republikaner unter Präsident Donald Trump der FCC die Zuständigkeit entzogen hatten, um die Netzneutralität abzuschaffen.
Nach Veröffentlichung im US-Amtsblatt (Federal Register) haben die fünf chinesischen Provider 60 Tage Zeit, ihren Betrieb in den USA einzustellen. Zum gleichen Termin greift auch die Netzneutralität. ISP, die gemeinsame Internetzugänge für Mehrparteienhäuser vermarkten, erhalten 180 Tage Zeit, ihre Verträge und Geschäftspraktiken anzupassen.
Unklar bleibt das Verhältnis zwischen der bundesweit gültigen Netzneutralitätsverordnung und den von etwa einem Dutzend US-Staaten eingeführten Netzneutralitätsbestimmungen [5]. Die FCC könnte solche Staatenregeln zwar für unwirksam erklären, hat das aber bewusst nicht getan.
Solange US-Staaten ihre Vorschriften in einer Weise umsetzten, die im Einklang mit den Bundesregeln stehen, möchte sich die FCC da heraushalten und freut sich sogar über die Unterstützung. Was das im Details bedeutet, und wann die FCC einschreiten würde, weiß niemand. Das wird wohl auch davon abhängen, welche politische Partei gerade in der FCC das Sagen hat.
URL dieses Artikels:
https://www.heise.de/-9698966
Links in diesem Artikel:
[1] https://www.heise.de/news/USA-Netzneutralitaet-wird-abgeschafft-3918679.html
[2] https://www.heise.de/news/Rechtskraeftig-US-Netzneutralitaet-war-legal-4213865.html
[3] https://www.heise.de/news/FCC-gegen-Zwei-Klassen-Internet-Die-Drei-Gebote-der-Netzneutralitaet-2560672.html
[4] https://www.heise.de/news/China-Telecom-soll-in-den-USA-zusperren-6233744.html
[5] https://www.heise.de/news/Nach-Abschaffung-US-Staaten-wollen-Netzneutralitaet-foerdern-oder-einklagen-3920201.html
[6] https://www.heise.de/downloads/18/4/5/7/9/9/2/3/DOC-401676A1.pdf
[7] mailto:ds@heise.de
Copyright © 2024 Heise Medien
(Bild: Arista)
The upcoming flagship models in Arista's access point range should score points with two 10G uplinks and uplink encryption, among other things.
Arista has announced its new C460 series Wi-Fi access points for summer 2024. The performance data, such as two 10 Gbit/s uplinks and a maximum wireless data rate of 11.5 Gbit/s, is impressive. The devices also offer exciting features in the security environment, such as MACSec on the wired interface or, in combination with AGNI, individual PSKs per user with WPA3, which no other competitor offers.
The AP is based on Qualcomm's Networking Pro 1220 platform. It simultaneously provides a 4*4 antenna in accordance with IEEE standard 802.11be and a dedicated tri-band antenna in all three frequency bands (2.4 GHz, 5 GHz and 6 GHz). The maximum channel width is 320 MHz, which should make a downlink of 11.5 Gbit/s possible. It will also have a mesh function. There will be a version with internal and one for external antennas. However, certification by the Wi-Fi Alliance is still pending.
On the copper uplink side, the AP provides two 10G-Base-T ports with Power over Ethernet (PoE++, 802.3bt / up to 90 watts) according to Arista's data sheet [1], which also seems sensible due to the high Wi-Fi data rate. It only provides reduced functions via PoE+ (802.3at / up to 30 watts), which the manufacturer has not yet specified. However, the two ports could also be used to map redundancy scenarios for switch failures or updates.
In some customer networks, the data rates are likely to lead to bottlenecks in the performance of the tertiary cabling between the switch and access point.
MACSec encryption appears to make sense for WLAN access points, as these are often located in public areas and the patching is therefore accessible. Without MACSec, data traffic could easily be read by potential attackers via TAPs. Arista's approach can therefore encrypt between the switch and access point. The AP also comes with an integrated Trusted Platform Module (TPM) to secure the firmware.
Security continues on the wireless interfaces. Arista provides a dedicated module for a wireless intrusion prevention system. In combination with the in-house cloud NAC solution AGNI, Arista is currently the only manufacturer that can work with individual pre-shared keys per user on an SSID for WPA3. Arista calls this technology Unique PSK (UPSK).
In addition to the Wi-Fi functions, the AP also comes with a number of IoT interfaces. In addition to Bluetooth Low Energy (BLE), Zigbee, Matter, OpenThread and HADM are also available. It also has a GNSS receiver.
To deliver the required PoE power in combination with more 10G ports at the access level, Arista has named the 720XP series, which delivers a total of 48 10G ports with up to 90 W in accordance with 802.3bt as the 720XP-48TXH-2C-S model. With numerous APs, the power supply units are likely to become a bottleneck. Arista has also developed a VXLAN-based tunnel architecture in combination with its switches so that the aggregated data rates of several APs do not have to be routed through the bottleneck of a central controller appliance.
URL dieses Artikels:
https://www.heise.de/-9696826
Links in diesem Artikel:
[1] https://www.arista.com/en/products/wifi7-series/
[2] https://www.heise.de/ix/
[3] mailto:mma@heise.de
Copyright © 2024 Heise Medien
The symbolic image shows fiber optic installation work in the Canadian city of Lethbridge
(Bild: Daniel AJ Sokolov)
The Gigabit Infrastructure Act should make it easier to approve applications for high-speed networks and eliminate additional costs for telephone calls in EU.
With a record-breaking majority of 594 votes in favor and only 7 against, the EU Parliament adopted the long-controversial draft [1] Gigabit Infrastructure Regulation on Tuesday. It aims to reduce the bureaucracy, costs and administrative burden associated with the planned connection of all EU citizens to high-speed networks by 2030. In the future, a presumption of approval [2] is to apply: Applications for network expansion that are not answered within four months will be deemed to have been tacitly approved. However, the German Association of Energy and Water Industries (BDEW) regrets that the EU rules fall short of the German requirement of three months and therefore do not help with national implementation.
According to the Gigabit Infrastructure Act (GIA), which negotiators from the EU legislative bodies agreed on in February [3], all newly constructed or extensively renovated buildings must be equipped with fiber optics. Endless digging work should come to an end. Construction work must be coordinated between fiber optic installers and other public utilities and their work. The member states are to set up contact points in the form of a "Single Information Point" (SIP) to provide easily accessible, centralized and digital information on permits and construction work. Critical national infrastructures (KRITIS) are excluded.
In principle, network operators in EU countries will have to give competitors access to ducts and masts in future to reduce overall expansion costs. Exceptions apply to Germany and Italy. Providers there can refuse to overbuild existing fiber optic networks by sharing existing infrastructure if they offer solutions such as a virtual access product ("bitstream") [4]. The background to this extra sausage is that the German Telecommunications [5] Act (TKG) already provides for such an option. The industry association Buglas expressed its relief: This would allow the interests of companies "that have invested a great deal of effort in building fiber optic networks that extend at least as far as the buildings" to be better considered. Incentives to open up and use existing lines (open access) would also be strengthened.
Extra charges for calls, text messages and data usage from home to other member states [6] beyond general mobile roaming [7] have been limited in the EU since 2019 [8]. The limit for call surcharges is €0.19 per minute. This regulation expires on May 14. The GIA therefore envisages that the price caps will continue to apply for the moment, but that intra-EU communication surcharges will be abolished in 2029 – before then. However, the EU Commission is to issue regulations to protect providers from fraud and similar adversities. In order to close a legal loophole, the GIA will enter into force just three days after publication in the EU Official Journal - instead of after 20 days. This is because the draft still has to go through the EU Council of Ministers, which is scheduled for April 29. Telecom providers could otherwise have temporarily raised charges in mid-May.
URL dieses Artikels:
https://www.heise.de/-9695763
Links in diesem Artikel:
[1] https://www.heise.de/news/GIA-Telekommunikationsbranche-laeuft-Sturm-gegen-geplante-Gigabit-Verordnung-9617280.html?from-en=1
[2] https://www.heise.de/news/Bund-und-Laender-wollen-Ausbau-der-Mobilfunknetze-erleichtern-9355770.html?from-en=1
[3] https://www.heise.de/news/Durchbruch-um-4-45-Uhr-EU-Gremien-einigen-sich-auf-Gigabit-Verordnung-9620501.html?from-en=1
[4] https://www.heise.de/news/Netzausbau-Fuer-mehr-als-die-Haelfte-der-Haushalte-ist-Gigabit-eine-Option-4921988.html?from-en=1
[5] https://www.heise.de/news/TKG-Novelle-Bundestag-beschliesst-schnelles-Internet-fuer-alle-6024446.html?from-en=1
[6] https://www.heise.de/news/EU-Abgeordnete-wollen-Kosten-fuer-internationale-Telefongespraeche-senken-3823667.html?from-en=1
[7] https://www.heise.de/news/EU-Parlament-stimmt-fuer-Verlaengerung-von-freiem-Roaming-6219491.html?from-en=1
[8] https://www.heise.de/news/EU-Kosten-fuer-Ferngespraeche-sinken-Gigabitnetze-sollen-kommen-4240539.html?from-en=1
[9] https://www.heise.de/downloads/18/4/5/7/8/2/2/5/TA-9-2024-0292_DE.pdf
[10] mailto:ds@heise.de
Copyright © 2024 Heise Medien
(Bild: Arista)
Die kommenden Flaggschiffmodelle in Aristas Access-Point-Sortiment sollen unter anderem mit zweimal 10G im Uplink und Uplink-Verschlüsselung punkten.
Arista hat seine neuen WLAN-Access-Points der C460er-Serie für den Sommer 2024 angekündigt. Die Leistungsdaten, wie zweimal 10 Gbit/s im Uplink und eine maximale Funkdatenrate von 11,5 Gbit/s können sich sehen lassen. Zudem bringen die Geräte auch im Security-Umfeld spannende Features mit, etwa MACSec auf der verkabelten Schnittstelle oder in Kombination mit AGNI individuelle PSKs je Nutzer mit WPA3, die ansonsten kein Mitbewerber liefert.
Der AP baut auf Qualcomms Networking-Pro-1220-Plattform auf. Er liefert gleichzeitig in allen drei Frequenzbändern (2,4 GHz, 5 GHz und 6 GHz) jeweils eine 4*4-Antenne gemäß IEEE-Standard 802.11be und eine dedizierte Tri-Band-Antenne. Die maximale Kanalbreite beträgt 320 MHz, damit soll ein Downlink von 11,5 Gbit/s möglich sein. Auch eine Mesh-Funktion soll er mitbringen. Es wird eine Variante mit internen und eine für externe Antennen geben. Die Zertifizierung durch die Wi-Fi Alliance steht jedoch noch aus.
Auf der Kupfer-Uplink-Seite liefert der AP gemäß Datenblatt von Arista [1] zwei 10G-Base-T-Ports mit Power over Ethernet (PoE++, 802.3bt / bis zu 90 Watt), was aufgrund der hohen WLAN-Datenrate auch sinnvoll erscheint. Über PoE+ (802.3at / bis zu 30 Watt) liefert er nur reduzierte Funktionen, die der Hersteller bisher nicht näher ausführt. Auf Basis der beiden Ports könnte man jedoch auch Redundanzszenarien für Ausfälle oder Updates von Switches abbilden.
In einigen Kundennetzen dürften die Datenraten schon zu Engpässen im Bereich Leistungsfähigkeit der Tertiärverkabelung zwischen Switch und Access-Point führen.
Die MACSec-Verschlüsselung erscheint bei WLAN-Access-Points sinnvoll, da sich diese häufig in öffentlichen Bereichen befinden und die Patchungen somit zugängig sind. So könnte der Datenverkehr ohne MACSec recht einfach durch potenzielle Angreifer über TAPs mitgelesen werden. Der Ansatz von Arista kann also zwischen Switch und Access-Point verschlüsseln. Zudem liefert der AP einen integriertes Trusted Platform Module (TPM) zur Sicherung der Firmware.
Weiter geht es in puncto Sicherheit auf den drahtlosen Schnittstellen. Dort liefert Arista ein dediziertes Modul für ein Wireless Intrusion Prevention System. In Kombination mit der hauseigenen Cloud-NAC-Lösung AGNI ist Arista auch der derzeit einzige Hersteller, der mit individuellen Pre-Shared-Keys je Nutzer auf einer SSID für WPA3 arbeiten kann. Diese Technik nennt sich bei Arista Unique PSK (UPSK).
Neben den Wi-Fi-Funktionen bringt der AP zudem eine Menge IoT-Schnittstellen mit. So stehen neben Bluetooth Low Energy (BLE) auch Zigbee, Matter, und OpenThread, sowie HADM bereit. Zusätzlich besitzt er einen GNSS-Empfänger.
Um die benötigte PoE-Leistung in Kombination mit einer höheren Anzahl an 10G-Ports in der Access-Ebene zu liefern, benennt Arista die 720XP-Serie, die etwa als Modell 720XP-48TXH-2C-S insgesamt 48 10G-Ports mit bis zu 90 W gemäß 802.3bt liefert. Bei einer großen Menge an APs dürften dann die Netzteile zum Flaschenhals werden.
Zudem hat Arista eine VXLAN-basierte Tunnelarchitektur in Kombination mit deren Switches entwickelt, um die aggregierten Datenraten von mehreren APs nicht durch den Flaschenhals einer zentralen Controllerappliance leiten zu müssen.
URL dieses Artikels:
https://www.heise.de/-9696444
Links in diesem Artikel:
[1] https://www.arista.com/en/products/wifi7-series/
[2] https://www.heise.de/ix/
[3] mailto:axk@heise.de
Copyright © 2024 Heise Medien
(Bild: r.classen/Shutterstock.com)
Auf Basis der Klasse TimeProvider kann man sich in .NET 8.0 einen eigenen TimeProvider erstellen, der in Tests Uhrzeiten vorgaukelt.
Der vorherige Blogbeitrag zu den Neuerungen in .NET 8.0 [1] hat die darin neu eingeführte Klasse System.TimeProvider sowie den darauf aufbauende FakeTimeProvider von Microsoft im NuGet-Paket Microsoft.Extensions.TimeProvider.Testing [2] behandelt.
Man kann aber einen FakeTimeProvider auch selbst schreiben. Die Klasse ITVisionsFakeTimeProvider implementiert im folgenden Listing einen eigenen Provider auf Basis der abstrakten Basisklasse System.TimeProvider. Dieser ITVisionsFakeTimeProvider gibt immer die gleiche Zeit zurück, die im Konstruktor übergeben wurde und kann mit Advance() vorgestellt werden.
Zusätzlich zu der Implementierung von Microsoft bietet die Klasse einen einstellbaren Zeitraffer. Beispielsweise dauert das Warten nur zwei statt sechs Sekunden durch die Angabe von 3 als Zeitraffer im Konstruktor:
FreshRSS ITVisionsFakeTimeProvider ftp =
new(DateTime.Parse("14.11.2023 18:00:00"), 3);
await ftp.Delay(new TimeSpan(0, 0, 6));
// oder
await Task.Delay(new TimeSpan(0, 0, 5), ftp);Der Zeitraffer wirkt auch auf Timer. Während dieser Timer alle drei Sekunden auslöst
TimeProvider.System.CreateTimer
((x) => Callback(TimeProvider.System),
null,
new TimeSpan(0, 0, 3),
new TimeSpan(0, 0, 3));erfolgt hier aufgrund des Zeitraffers 3 die Auslösung jede Sekunde:
ftp.CreateTimer((x) => Callback(ftp),
null,
new TimeSpan(0, 0, 3),
new TimeSpan(0, 0, 3));Hier ist ein Codebeispiel mit dem ITVisionsFakeTimeProvider:
/// <summary>
/// Dieser FakeTimeProvider gibt immer die gleiche Zeit zurück,
/// die im Konstruktor übergeben wurde. Der Timer kann vorgestellt
/// werden mit Advance(). Für den Timer gibt es einen Zeitraffer.
/// </summary>
class ITVisionsFakeTimeProvider : TimeProvider
{
private readonly DateTimeOffset _date;
int _timeLapse = 1;
public ITVisionsFakeTimeProvider(DateTimeOffset date,
int timeLapse = 1)
{
_date = date;
_timeLapse = timeLapse;
}
public override DateTimeOffset GetUtcNow()
{
return _date;
}
/// <summary>
/// Zeit vorstellen
/// </summary>
public void Advance(TimeSpan timeSpan)
{
_date.Add(timeSpan);
}
/// <summary>
/// Timer mit Zeitraffer
/// </summary>
public override ITimer CreateTimer(TimerCallback callback,
object state,
TimeSpan dueTime,
TimeSpan period)
{
return base.CreateTimer(callback, state,
new TimeSpan((long)(dueTime.Ticks / _timeLapse)),
new TimeSpan((long)(period.Ticks / _timeLapse)));
}
}
URL dieses Artikels:
https://www.heise.de/-9683197
Links in diesem Artikel:
[1] https://www.heise.de/blog/Neu-in-NET-8-0-17-Zeitabstraktion-fuer-Tests-mit-Zeitangaben-9675891.html
[2] https://www.nuget.org/packages/Microsoft.Extensions.TimeProvider.Testing
[3] https://net.bettercode.eu/
[4] https://net.bettercode.eu/tickets.php
[5] mailto:rme@ix.de
Copyright © 2024 Heise Medien
Das Symbolbild zeigt Glasfaserverlegungsarbeiten in der kanadischen Stadt Lethbridge
(Bild: Daniel AJ Sokolov)
Mit dem Gigabit Infrastructure Act sollen Anträge für Hochgeschwindigkeitsnetze einfacher bewilligt werden und Mehrkosten für Telefonate in der EU wegfallen.
Mit der rekordverdächtigen Mehrheit von 594 Ja- und nur 7-Nein-Stimmen hat das EU-Parlament am Dienstag den lange umstrittenen Entwurf [1] für eine Gigabit-Infrastrukturverordnung beschlossen. Er zielt darauf ab, Bürokratie sowie Kosten und Verwaltungsaufwand rund um den geplanten Anschluss aller EU-Bürger an Hochgeschwindigkeitsnetze bis 2030 zu verringern. Künftig soll eine Genehmigungsfiktion greifen [2]: Anträge zum Netzausbau, die nicht innerhalb von vier Monaten beantwortet werden, gelten demnach als stillschweigend bewilligt. Der Bundesverband der Energie- und Wasserwirtschaft (BDEW) bedauert allerdings, dass die EU-Regeln hinter der deutschen Vorgabe von drei Monaten zurückbleiben und so bei der nationalen Umsetzung nicht weiter helfen.
Alle neu errichteten oder im größeren Umfang sanierten Gebäude müssen laut Gigabit Infrastructure Act (GIA), auf den sich Verhandlungsführer der EU-Gesetzgebungsgremien im Februar geeinigt [3] haben, mit Glasfaser ausgestattet werden. Endlose Buddelarbeiten sollen ein Ende haben. Bauarbeiten müssen zwischen Glasfaserinstallateuren und anderen öffentlichen Versorgern und deren Arbeiten koordiniert werden. Die Mitgliedsstaaten sollen Anlaufstellen in Form eines "Single Information Point" (SIP) einrichten, um Informationen zu Genehmigungen und Bauarbeiten leicht zugänglich zentral und digital bereitzustellen. Ausgenommen werden kritische nationale Infrastrukturen (Kritis).
Prinzipiell müssen Netzbetreiber in EU-Ländern Konkurrenten künftig Zugang zu Leerrohren und Masten geben, um die Ausbaukosten insgesamt zu drücken. Ausnahmen gelten für Deutschland und Italien. Anbieter können dort einen Überbau bestehender Glasfasernetze durch Mitnutzung bestehender Infrastruktur ablehnen, wenn sie Lösungen wie ein virtuelles Zugangsprodukt ("Bitstrom") [4] anbieten. Hintergrund der Extrawurst ist, dass das deutsche Telekommunikationsgesetz [5] (TKG) eine solche Option bereits vorsieht. Der Branchenverband Buglas zeigte sich erleichtert: So könnten die Interessen der Unternehmen besser berücksichtigt werden, "die mit hohem Aufwand bis mindestens in die Gebäude reichende Glasfasernetze errichten". Zudem würden Anreize zur Öffnung und Nutzung bestehender Leitungen (Open Access) gestärkt.
Extra-Gebühren für Anrufe, SMS und Datennutzung aus der Heimat in andere Mitgliedsstaaten [6] jenseits des allgemeinen Roamings im Mobilfunk [7] sind in der EU seit 2019 begrenzt [8]. Das Limit für Gesprächszuschläge beträgt 0,19 Euro pro Minute. Diese Vorschrift läuft am 14. Mai aus. Der GIA sieht daher vor, dass die Preisobergrenzen zwar zunächst weiter gelten, die innergemeinschaftlichen Kommunikationszuschläge aber 2029 entfallen - davor soll die EU-Kommission aber noch Vorschriften zum Schutz der Anbieter vor Betrug und ähnlichen Widrigkeiten erlassen. Um eine Gesetzeslücke zu schließen, wird der GIA schon drei Tage nach Veröffentlichung im EU-Amtsblatt in Kraft treten – statt nach 20. Denn der Entwurf muss noch durch den EU-Ministerrat, was für den 29. April geplant ist. Telecom-Anbieter hätten sonst Mitte Mai die Gebühren vorübergehend anheben können.
URL dieses Artikels:
https://www.heise.de/-9695742
Links in diesem Artikel:
[1] https://www.heise.de/news/GIA-Telekommunikationsbranche-laeuft-Sturm-gegen-geplante-Gigabit-Verordnung-9617280.html
[2] https://www.heise.de/news/Bund-und-Laender-wollen-Ausbau-der-Mobilfunknetze-erleichtern-9355770.html
[3] https://www.heise.de/news/Durchbruch-um-4-45-Uhr-EU-Gremien-einigen-sich-auf-Gigabit-Verordnung-9620501.html
[4] https://www.heise.de/news/Netzausbau-Fuer-mehr-als-die-Haelfte-der-Haushalte-ist-Gigabit-eine-Option-4921988.html
[5] https://www.heise.de/news/TKG-Novelle-Bundestag-beschliesst-schnelles-Internet-fuer-alle-6024446.html
[6] https://www.heise.de/news/EU-Abgeordnete-wollen-Kosten-fuer-internationale-Telefongespraeche-senken-3823667.html
[7] https://www.heise.de/news/EU-Parlament-stimmt-fuer-Verlaengerung-von-freiem-Roaming-6219491.html
[8] https://www.heise.de/news/EU-Kosten-fuer-Ferngespraeche-sinken-Gigabitnetze-sollen-kommen-4240539.html
[9] https://www.heise.de/downloads/18/4/5/7/8/2/1/5/TA-9-2024-0292_DE.pdf
[10] mailto:ds@heise.de
Copyright © 2024 Heise Medien
(Bild: iX)
With Hypershield, Cisco wants to completely revolutionize IT security - and take a lot of work off admins' hands. We show you what's behind the buzzwords.
Cisco wants nothing less than to revolutionize IT security with Hypershield. The manufacturer mentions exploit protection without patches, software upgrades without downtime and autonomous network segmentation. Hypershield is supposed to detect malicious behavior and automatically reconfigure networks to eliminate threats. But what is really behind this grandiose announcement?
In essence, it is about a security product based on eBPF, which is the result of the acquisition of Isovalent. Cisco wants to integrate eBPF into components such as switches and servers, including VMs and containers. The provider calls this Enforcement Points – it is therefore not an entirely new approach [1] in terms of methodology, but rather the familiar "centralized management, decentralized enforcement" approach that has been used for years in network access control (NAC [2]), for example.
The difference lies more in the enforcement points, which are intended to act as a kind of tiny firewall and therefore regulate data flows and behavior as early as possible at the point of origin. These should be able to run based on data processing units (DPUs), i.e. special network cards – also known as SmartNICs – that are installed in servers or network hardware. Cisco points out that these do not have to be special Cisco DPUs.
To be able to detect anomalies, Hypershield should first learn the normal behavior of the applications used via baselining. This will be enriched with information from Cisco's security intelligence team (Talos) about new attacks. The team evaluates the data collected online with the help of AI to detect malicious behavior more quickly.
The decision on how to deal with potentially malicious behavior can vary. One option is to provide basic information to administrators about which applications they need to patch. Another option is to implement compensating protection that protects the application. This could, for example, be a new network segment that does not allow any suspicious traffic. Specifically, certain communication patterns – such as known malicious URLs or lateral movements in the data center – could be blocked or isolation could be carried out after a successful attack. Hypershield's approach is to intercept these communication relationships as close as possible to the application. This should also make it easier to control data traffic in Kubernetes environments, for example.
The enforcement points should contain two data paths: One for productive and positively tested communications and a shadow path. The latter receives live data and, according to Cisco, uses AI to test whether the update works as expected. If the automated tests are successful, Hypershield switches the shadow path to productive.
The enforcement points rely on eBPF for this purpose. The extended Berkeley Packet Filter [3] allows programs to be loaded from user space and run in the kernel without changing the kernel source code or loading kernel modules. As this generates some load, this process can be outsourced to DPUs/SmartNICs to minimize the impact on productive workloads. Cisco is also aiming to develop switches with dedicated DPUs for these functions. However, these are not yet available.
Hypershield is managed in the cloud-based security policy manager Cisco Defense Orchestrator [4]. It displays CVEs, for example. An AI assistant provides additional information and suggests solutions, such as segmentation due to missing patches. According to Cisco, protection should also be able to run completely autonomously in the future.
The announcement [5] seems a little early, as many components such as the special switches for applying the security guidelines are not yet available. Nevertheless, the approach seems quite interesting, although the use of AI in the security environment, especially in the autonomous operation Cisco is aiming for, is likely to cause many administrators and security managers to break out in a sweat.
URL dieses Artikels:
https://www.heise.de/-9693576
Links in diesem Artikel:
[1] https://www.heise.de/news/l-f-Cisco-erfindet-die-Security-neu-9691102.html?from-en=1
[2] https://www.heise.de/hintergrund/Network-Access-Control-Die-Technik-hinter-Zero-Trust-4702937.html?from-en=1
[3] https://www.heise.de/tests/Beobachtungstool-Coroot-im-Test-Telemetriedaten-in-Erkenntnisse-umwandeln-9622639.html?from-en=1
[4] https://www.heise.de/news/Cisco-baut-KI-Features-in-seine-Firewalls-9548462.html?from-en=1
[5] https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2024/m04/cisco-hypershield-security-reimagined.html
[6] https://www.heise.de/ix/
[7] mailto:dahe@heise.de
Copyright © 2024 Heise Medien
(Bild: iX)
Mit Hypershield will Cisco die IT-Sicherheit komplett umkrempeln – und Admins viel Arbeit abnehmen. Wir zeigen, was hinter den Schlagwörtern steckt.
Cisco möchte mit Hypershield nicht weniger, als die IT-Sicherheit revolutionieren. Der Hersteller nennt dabei einen Exploit-Schutz ohne Patches, Software-Upgrades ohne Ausfallzeit, bis hin zur autonomen Netzwerk-Segmentierung. So soll Hypershield bösartiges Verhalten erkennen und Netzwerke automatisch neu konfigurieren, um Bedrohungen zu eliminieren. Doch was steckt wirklich hinter dieser vollmundigen Ankündigung?
Im Kern geht es um ein auf eBPF aufbauendes Sicherheitsprodukt, das aus der Übernahme von Isovalent hervorgeht. Cisco möchte eBPF in Komponenten wie Switches und Servern inklusive VMs und Containern integrieren. Der Anbieter nennt dies Enforcement Points – es handelt sich methodisch also nicht um einen komplett neuen Ansatz [1], sondern den altbekannten Weg "zentrales Management, dezentrales Enforcement", wie man ihn beispielsweise in der Netzwerkzugriffskontrolle (NAC) [2] bereits seit Jahren einsetzt.
Der Unterschied liegt eher an den Enforcement Points, die als eine Art winzige Firewall agieren sollen und folglich Datenflüsse und Verhalten möglichst früh am Entstehungspunkt reglementieren. Diese sollen auf Basis von Data Processing Units (DPUs), also speziellen Netzwerkkarten – auch als SmartNIC bezeichnet – laufen können, die in Servern oder Netzwerkhardware installiert sind. Cisco weist darauf hin, dass dies keine speziellen Cisco DPUs sein müssen.
Um Anomalien erkennen zu können, soll Hypershield zunächst über Baselining das Normalverhalten der eingesetzten Applikationen erlernen. Das soll mit Informationen aus Ciscos Security-Intelligence-Team (Talos) über neue Attacken angereichert werden. Das Team wertet KI-unterstützt die online gesammelten Daten aus, um bösartiges Verhalten schneller zu erkennen.
Die Entscheidung über den Umgang mit potenziell bösartigem Verhalten kann sich unterscheiden. Eine Option ist die grundlegende Information an die Administratoren, welche Anwendungen sie patchen müssen. Eine weitere Option besteht darin, einen kompensierenden Schutz zu implementieren, der die Anwendung schützt. Das kann beispielsweise die ein neues Netzwerksegment sein, das keinen verdächtigen Verkehr zulässt. Konkret könnten also beispielsweise bestimmte Kommunikationsmuster – wie zu bekannt bösartigen URLs oder Seitwärtsbewegungen im Rechenzentrum – geblockt oder Isolierungen nach einer erfolgreichen Attacke durchgeführt werden. Ansatz von Hypershield ist es, diese Kommunikationsbeziehungen möglichst nah an der Applikation abzugreifen. So sollen sich beispielsweise auch den Datenverkehr in Kubernetes-Umgebungen besser kontrollieren lassen.
Die Enforcement Points sollen zwei Datenpfade beinhalten: Einer für produktive und positiv getestete Kommunikationen und einen Schattenpfad. Letzterer erhält gespielte Live-Daten und nutzt laut Cisco KI, um zu testen, ob die Aktualisierung wie erwartet funktioniert. Sollten die automatisierten Tests erfolgreich sein, schaltet Hypershield den Schattenpfad produktiv.
Dazu setzen die Enforcement Points auf eBPF. Der extended Berkeley Packet Filter [4] erlaubt es, Programme aus dem Userspace zu laden und im Kernel ablaufen zu lassen, ohne hierfür den Kernel-Quellcode zu ändern oder Kernel-Module zu laden. Da das etwas Last erzeugt, kann dieser Prozess auf DPUs/SmartNICs ausgelagert werden, um produktive Arbeitslasten möglichst wenig zu beeinflussen. Zudem strebt Cisco an, Switche mit dedizierten DPUs für diese Funktionen zu entwickeln. Sie stehen jedoch noch nicht zur Verfügung.
Die Verwaltung von Hypershield läuft im Cloud-basierten Sicherheitsrichtlinienmanager Cisco Defense Orchestrator [5]. Er zeigt beispielsweise CVEs an. Ein KI-Assistent gibt zusätzliche Informationen dazu und schlägt Lösungsansätze vor, beispielsweise eine Segmentierung aufgrund nicht vorhandenen Patches. Perspektivisch soll der Schutz gemäß Cisco auch vollkommen autonom laufen können.
Die Ankündigung [6] erscheint etwas früh, da viele Bestandteile wie die speziellen Switche zur Anwendung der Sicherheitsrichtlinien noch nicht bereitstehen. Trotzdem erscheint der Ansatz recht interessant, obgleich der Einsatz von KI, insbesondere im von Cisco angestrebten autonomen Betrieb, im Security-Umfeld vielen Administratoren und Sicherheitsverantwortlichen Schweißperlen auf die Stirn treiben dürfte.
URL dieses Artikels:
https://www.heise.de/-9693337
Links in diesem Artikel:
[1] https://www.heise.de/news/l-f-Cisco-erfindet-die-Security-neu-9691102.html
[2] https://www.heise.de/hintergrund/Network-Access-Control-Die-Technik-hinter-Zero-Trust-4702937.html
[3] https://heise.de/s/NY1E
[4] https://www.heise.de/tests/Beobachtungstool-Coroot-im-Test-Telemetriedaten-in-Erkenntnisse-umwandeln-9622639.html
[5] https://www.heise.de/news/Cisco-baut-KI-Features-in-seine-Firewalls-9548462.html
[6] https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2024/m04/cisco-hypershield-security-reimagined.html
[7] https://www.heise.de/ix/
[8] mailto:fo@heise.de
Copyright © 2024 Heise Medien
(Bild: GaudiLab/Shutterstock.com)
Fast alle Unternehmen setzen auf das Daily als Meetingformat. Und fast alle Dailys sind eine Katastrophe: Langweilig, ineffizient und überflüssig. Warum?
Es gibt eine Beobachtung, die mir immer wieder auffällt. Viele Unternehmen setzen bei ihrer Entwicklung auf Scrum (oder zumindest auf das, was sie dafür halten) und führen im Zuge dessen auch tägliche Meetings, sogenannte Dailys, durch. Dabei muss ich ehrlich zugeben, dass ich bisher noch kein Unternehmen kennengelernt habe, bei dem ich die Dailys als produktiv oder gar hilfreich empfunden hätte. Meistens hatte ich stattdessen genau die gegenteilige Meinung: Die Dailys waren langweilig und ineffizient und aus meiner Sicht komplett überflüssig.
Natürlich möchte ich mich dabei nicht als das Maß der Dinge darstellen, doch nachdem ich wirklich viele Unternehmen von innen gesehen habe, fällt mir eben auf, dass zwar das Konzept des Daily-Meetings einerseits weitverbreitet zu sein scheint, die Umsetzung andererseits jedoch häufig keinen guten Eindruck hinterlässt. Hier liegt anscheinend ein Problem vor, über das man mal sprechen sollte. Denn: Warum sind Dailys denn so oft eine Katastrophe? Warum werden sie dennoch durchgeführt? Und gibt es Möglichkeiten, sie besser zu gestalten? Auf all diese Fragen möchte ich in diesem Artikel eingehen.
Wenn man sich fragt, wo eigentlich die ursprüngliche Idee für ein Daily-Meeting herkommt, werden vermutlich viele Entwicklerinnen und Entwickler antworten, dass es sich dabei um ein Konzept aus Scrum handelt. Ob die Idee der Dailys wirklich für Scrum erfunden wurde oder ob Scrum die Idee lediglich populär gemacht hat, weiß ich nicht, aber es lässt sich sicherlich festhalten, dass ein Zusammenhang zwischen der Verbreitung von Scrum und der Durchführung von Dailys zu bestehen scheint.
Die Frage, die sich nun stellt, lautet: Was ist eigentlich ein Daily? Ich habe einige Quellen zurate gezogen, darunter auch die Website scrum-master.de [2], welche das Daily als "kurzes, tägliches Statusmeeting des Teams" definiert. Im Vergleich dazu erwähnt der offizielle Scrum-Guide [3] das Wort "Status" nicht, beschreibt das Daily aber als ein 15-minütiges Treffen des Scrum-Teams. Ziel sei es, einen Einblick in den Fortschritt bezüglich des Sprint-Ziels zu bekommen und das Backlog auf Basis neuer Erkenntnisse für zukünftige Sprints anzupassen. Obwohl der Begriff "Status" dort also nicht explizit verwendet wird, zielt die Fragestellung im Kern dennoch darauf ab: "Wie steht es um den Fortschritt?"
Hier beginnen meiner Meinung nach bereits die Probleme. Nehmen wir diese beiden Definitionen als Ausgangspunkt, so ergibt sich die Frage: Wer nimmt an einem solchen Daily eigentlich teil? Die Antwort ist in beiden Fällen ziemlich klar: das "Team" beziehungsweise das "Scrum-Team". Bloß, was versteht man unter einem Team in Scrum? Es handelt sich um eine Gruppe von Personen, die für die Erstellung des Produkts essenziell sind und bewusst aus verschiedenen Disziplinen – von der Entwicklung über Design und Marketing bis hin zur Planung und Organisation – zusammengesetzt ist. Laut dem offiziellen Scrum-Guide gehören zu diesem Team [4] ausdrücklich die Rollen des Product Owners und des Scrum Masters.
Es könnte natürlich sein, dass dies in Ihrem Unternehmen anders gehandhabt wird, als ich es bisher kennengelernt habe. Möglicherweise ist bei Ihnen die Rolle des Product Owners tatsächlich darauf beschränkt, an der initialen Sprint-Planung teilzunehmen und später den Review durchzuführen. Aber in den meisten Fällen ist der Product Owner sehr daran interessiert zu erfahren, wer gerade woran arbeitet und wie die Projekte voranschreiten. Das geht so weit, dass diese Fragestellung des Product Owners in der Regel sogar die treibende Kraft hinter dem Daily ist. Wie zuvor erwähnt, es mag bei Ihnen anders sein, ich spreche hier nur von meinen Erfahrungen.
Das Hauptproblem dabei ist, dass das Daily auf diesem Weg in erster Linie zu einem Statusmeeting für Product Owner avanciert. Statt dass sich die Teammitglieder auf Augenhöhe austauschen, erfolgt oft ein Bericht an die – gefühlte oder tatsächliche – nächsthöhere Hierarchieebene. Bedenkt man, dass ein Team nach Scrum-Definition 7 +/- 2 Mitglieder umfassen sollte, so mag ein Meeting zwar auf der Uhr nur 15 Minuten dauern. Doch in Wirklichkeit sind, rein kostenmäßig betrachtet, bei 7 Teammitgliedern ganze 105 Minuten Arbeitszeit investiert worden – also fast zwei Stunden pro Tag.
Rechnet man das hoch, summiert sich das auf rund 10 Stunden pro Woche und annähernd 40 Stunden im Monat, die allein für die Dailys aufgewendet werden. Das bedeutet, dass durch die Dailys jeden Monat die Arbeitskraft einer ganzen Personenwoche verloren geht. Für ein bloßes Statusmeeting sind das aus meiner Sicht unverhältnismäßig hohe Kosten. Es handelt sich schlichtweg um eine Verschwendung von Zeit und Geld.
Aber das ist nicht das einzige Problem. Wenn ein solches Meeting zu einem Statusreportmeeting wird, entstehen für alle Teammitglieder Stress und Druck, weil sie das Gefühl haben, ständig etwas berichten zu müssen. Niemand möchte den Eindruck erwecken, nicht zu arbeiten. Deshalb wird notfalls irgendetwas erzählt, um irgendeinen Fortschritt vorzeigen zu können. Oft sind es dann tiefgehende technische Details, die für niemanden sonst im Team von echtem Interesse sind. Es scheint besser, irgendetwas Kompliziertes zu sagen, als einzuräumen: "Eigentlich gibt es gerade nichts Neues bei mir."
Wer das bezweifelt, sollte es einfach mal ausprobieren: Berichten Sie einige Tage lang nichts Neues und beobachten Sie, wie lange es dauert, bis Sie darauf angesprochen werden, warum es nicht vorangeht, was Sie derzeit überhaupt machen, und so weiter. Und hier zeigt sich die wahre Problematik: Aus einem harmlos wirkenden Statusreport wird schnell ein Kontrollmeeting, in dem geprüft wird, ob jede und jeder auch wirklich arbeitet. Es scheint, als könnte man nicht einfach darauf vertrauen, dass Sie eigenständig und diszipliniert arbeiten und sich melden, wenn es etwas zu berichten gibt – sei es positiv oder negativ.
Bezüglich dessen, was man in einem Daily Meeting idealerweise sagt, hat sich in vielen Unternehmen ein festes Muster etabliert, nämlich die berühmten drei Fragen: Was hast du gestern gemacht? Was machst du heute? Wo gibt es Probleme?
Diese werden von jedem Teilnehmer des Meetings routinemäßig beantwortet: "Ich habe gestern dies und das gemacht, heute werde ich jenes tun, und es läuft gut, ich habe aktuell keine Probleme." Es ist äußerst ermüdend, wenn diese Formel täglich von jeder und jedem ohne Variation wiederholt wird und der Informationsgehalt für die anderen Teammitglieder meistens gering ist.
Ich frage mich an der Stelle oft: Warum sollte ich, wenn ich etwas Wichtiges mitzuteilen habe, bis zum nächsten Daily warten? Das erscheint mir ineffizient, und es verzögert alles. Zudem nimmt es, zumindest bei guten Neuigkeiten, auch die Begeisterung. Wenn ich etwas Bedeutendes erreicht habe, das für das Team wichtig ist, möchte ich das doch gerne sofort teilen und nicht erst am nächsten Montag, weil das Daily am heutigen Freitag leider schon vorbei ist.
Gleiches gilt, wenn ein Problem auftritt – warum sollte ich Stunden bis zum nächsten Tag warten, um es anzusprechen? Und offen gesagt: Wenn jemand wissen möchte, woran ich derzeit arbeite, kann sie oder er mich einfach direkt fragen, oder einfach selbst nachsehen, beispielsweise im Projekt-Board – dafür ist es doch schließlich da. In der Mehrzahl der Tage gibt es aber einfach nicht viel Neues zu berichten, und alles, was ich dann wirklich möchte, ist, ungestört arbeiten zu können und nicht aus meiner Konzentration herausgerissen zu werden, weil das nächste unnötige Statusreportmeeting ansteht. Kurz gesagt: Ich habe meine Zweifel am Nutzen von Dailys.
Wie bereits erwähnt, kann es natürlich sein, dass das bei Ihnen alles komplett anders läuft. Persönlich habe ich Dailys allerdings noch nie als positiv erlebt, und das gilt unabhängig von der Art des Unternehmens. Die Probleme, die ich beschrieben habe, sind mir sowohl aus Start-ups als auch aus Großkonzernen bekannt, ebenso aus Unternehmen mit flachen Hierarchien wie aus solchen mit stark ausgeprägten Hierarchiestrukturen. Und diese Erfahrungen sind unabhängig davon, wie agil ein Unternehmen arbeitet (oder zu arbeiten glaubt, denn oft sind die vermeintlich agilen Unternehmen gar nicht wirklich agil). Falls Sie jetzt denken, dass es in Ihrem Unternehmen tatsächlich anders zugeht, würde ich mich freuen, wenn Sie Ihre Erfahrungen in den Kommentaren zu diesem Artikel teilen würden.
Nun ist es natürlich immer einfacher, Kritik zu üben, als konstruktive Verbesserungsvorschläge zu machen. Aber ich glaube, es ist an dieser Stelle gar nicht so schwierig, eine Verbesserung vorzuschlagen. Wie ich schon angedeutet habe: Ich möchte im Bedarfsfall nicht warten müssen, bis das nächste Daily stattfindet. Daher erscheint es mir sinnvoller, Kommunikation nach Bedarf zu ermöglichen. Haben Sie etwas erreicht, das das gesamte Team interessieren und freuen wird? Teilen Sie es direkt mit. Stehen Sie vor einem Problem, bei dem Sie schon länger feststecken, und würden gerne mit jemand anderem darüber sprechen? Suchen Sie direkt nach Unterstützung. Müssen Sie ein Konzept diskutieren, um weiterzukommen? Warten Sie nicht auf das nächste Daily, sondern sprechen Sie es direkt an. Ad-hoc-Kommunikation halte ich in einem Team von 7 +/- 2 Personen für weitaus sinnvoller, effektiver und effizienter als die üblichen, ineffektiven Dailys.
Natürlich könnten Sie jetzt einwenden: Nicht jede Person hat immer sofort Zeit. Das ist korrekt, und genau deshalb ist asynchrone Kommunikation so entscheidend. Ich meine also nicht, dass Sie, wenn Sie etwas Interessantes zu berichten haben, alle sofort zusammenrufen sollten. Vielmehr: Wenn Sie etwas Spannendes zu berichten haben, dann teilen Sie das beispielsweise im Team-Chat. Oder, wenn es sich um ein Feature handelt, das sich in der Benutzeroberfläche zeigt, machen Sie ein kurzes Video oder einen Screenshot und posten Sie das. Wenn Sie ein Problem haben, fragen Sie im Team-Chat, ob jemand, der sich in dem Bereich auskennt, Zeit hat, um sich mit Ihnen zusammenzusetzen. Und so weiter.
Direkt zu handeln, statt im Daily zu berichten, bedeutet nicht, dass Sie immer alle sofort informieren müssen. Es ist völlig in Ordnung, wenn Ihr Team die Nachricht vielleicht erst einige Stunden später oder sogar erst am nächsten Tag sieht – ähnlich wie bei einem Post in sozialen Medien, den nicht alle Ihre Freundinnen und Freunde sofort sehen. Und wenn wirklich dringender Handlungsbedarf besteht, dann können Sie immer noch alle zusammentrommeln. Aber selbst dann ist es sinnvoller, das direkt zu tun, statt auf das nächste Daily zu warten. Also, ganz egal, wie man es betrachtet: Ich persönlich sehe keinen Sinn darin, warum ich etwas bis zum nächsten Daily aufschieben sollte. Ich persönlich halte das schlichtweg für Quatsch.
Entsprechend dem, was ich bis hierhin geschrieben habe, haben wir bei the native web [5] keine Dailys. Tatsächlich haben wir überhaupt keine regelmäßigen Meetings, mit einer Ausnahme, auf die ich gleich noch kommen werde. Bei uns erfolgt immer alles ad-hoc, und damit sind wir seit nunmehr etwa 12 Jahren insgesamt sehr erfolgreich und zufrieden. Der große Vorteil dabei ist, dass wenn Sie etwas direkt ansprechen, Sie sich auch aussuchen können, wen Sie damit ansprechen. Das bedeutet, die Relevanz des Themas für die Personen, die ad-hoc zusammenkommen, ist wahrscheinlich viel größer als in einem Daily, wo alle sich stets alles anhören müssen. Und da ich erwähnte, wie wichtig asynchrone Kommunikation ist: Bei uns läuft das hauptsächlich über Slack.
Die einzige Ausnahme ist ein informelles wöchentliches Treffen, bei dem wir uns einfach zum informellen Austausch treffen, und wo gegebenenfalls noch Themen angesprochen werden können, die wirklich für alle relevant sind und die nicht bereits dringend waren. Und damit sind wir, wie zuvor erwähnt, sehr zufrieden.
Eines möchte ich jedoch noch klarstellen: Ich gebe mich nicht der Illusion hin, dass unsere Methode die magische Lösung für alle Probleme darstellt, egal in welchem Unternehmen Sie tätig sind. Was es jedoch definitiv zeigt, ist, dass es Alternativen gibt. Das bedeutet: Führen Sie keine Dailys durch, nur weil "man das in Scrum eben so macht" oder weil "es jeder macht". Entscheiden Sie sich stattdessen für Vorgehensweisen, die zu Ihnen passen und die tatsächlich einen Mehrwert für alle im Team bieten, und nicht nur für den Product Owner.
Wenn ein Großteil des Teams das Gefühl hat, ein Meeting sei eher Zeitverschwendung, dann sollten Sie darüber nachdenken, warum Sie dieses abhalten, welchen Zweck es erfüllen soll und welche Intention dahintersteckt, um dann alternative Wege zur Erreichung dieser Ziele zu suchen. Denn – und das ist das Wesentliche – Sie sind nicht dazu da, Scrum & Co. zufriedenzustellen. Vielmehr sollten Scrum & Co. dazu dienen, Sie zu unterstützen.
Stellen Sie Ihre Bedürfnisse und Anforderungen als Team also nicht zurück, nur weil ein Prozess oder ein Werkzeug dies von Ihnen verlangt. Die Prozesse und Werkzeuge sind da, um Ihnen zu helfen, nicht umgekehrt. Das ist übrigens der Kerngedanke der gesamten Agilität und tatsächlich der erste Punkt des Agilen Manifests [6]: „Menschen und deren Interaktionen sind wichtiger als Prozesse und Werkzeuge.“ Auf Englisch: „Individuals and interactions over processes and tools.“ Und das sollten Sie nie vergessen.
URL dieses Artikels:
https://www.heise.de/-9684706
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://scrum-master.de/Scrum-Meetings/Daily_Scrum_Meeting
[3] https://scrumguides.org/scrum-guide.html#daily-scrum
[4] https://scrumguides.org/scrum-guide.html#scrum-team
[5] https://www.thenativeweb.io/
[6] https://agilemanifesto.org/iso/de/manifesto.html
[7] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Pavel Ignatov/Shutterstock.com)
Das HTML-Rendern mit Razor-Komponenten ist in .NET 8.0 auch außerhalb von Blazor-Anwendungen möglich, beispielsweise für HTML-formatierte E-Mails.
Die Razor-Template-Syntax hat Microsoft schon im Jahr 2010 vorgestellt und in ASP.NET MVC Classic Version 3 am 13.11.2011eingeführt, siehe Blogeintrag von Scott Guthrie vom 3.7.2010 [1]. Sie wurde auch in ASP.NET Webpages verwendet und später in ASP.NET Core MVC und ASP.NET Core Razor Pages übernommen. In Blazor gibt es eine erweiterte Version mit einem vereinfachten Modell für wiederverwendbare Razor-Komponenten.
Das Rendern der in Blazor verwendeten Razor-Komponenten ist in .NET 8.0 auch außerhalb von Blazor-Anwendungen möglich. Somit steht die gleiche Syntax, die in Blazor für Web- und Hybridanwendungen zum Einsatz kommt, nun auch für HTML-Rendering für E-Mails im HTML-Format oder andere HTML-Einsatzgebiete zur Verfügung.
Dazu gibt es in .NET 8.0 die neue Klasse Microsoft.AspNetCore.Components.Web.HtmlRenderer [2] im NuGet-Paket Microsoft.AspNetCore.Components.Web.
Für das folgende Beispiel gibt es zunächst drei Razor-Komponenten. EMailTemplate.razor bindet Headline.razor und Footer.razor per Tags ein: <Headline> und <Footer>. Bei Headline wird ein Parameter übergeben. Bei Footer kann man ein Razor-Fragment übergeben.
Alle Styles sind im HTML-Dokument in <style>-Tags enthalten. Externe Style-Sheet-Dateien wie EMailTemplate.razor.css werden nicht wie Blazor automatisch integriert, sondern müssen explizit per <link rel="stylesheet" type="text/css" href="EMailTemplate.razor.css"> referenziert werden. Das funktioniert gut beim Rendering ins Dateisystem, ist aber nicht möglich bei E-Mails.
Der Code für EMailTemplate.razor sieht folgendermaßen aus:
<html>
<body>
<style>
body { font-family: Arial}
</style>
<Headline Text="Terminbestätigung"></Headline>
<p>Guten Tag @Name,</p>
<p>.NET 8.0 ist am <b>@Datum.ToLongDateString()</b> erschienen.</p>
@{
var url = "https://www.IT-Visions.de";
}
@* Einbinden einer weiteren Razor-Komponente mit Child Content *@
<Footer>
<p>
Ihr Team von<br />
<a href="@url">www.IT-Visions.de</a></p>
</Footer>
</body>
</html>
@code {
[Parameter]
public string Name { get; set; }
[Parameter]
public DateTime Datum { get; set; } = new(2023, 11, 14);
}
Dies ist der Code für Headline.razor:
@* Razor Component mit einfachem Parameter *@
<style>
.headline {
color: white;
background-color: #12B4FF;
padding: 10px;
}
</style>
<h3 class="headline">@Text</h3>
@code {
[Parameter]
public string Text { get; set; }
}
Und im Folgenden ist der Code für Footer.razor zu sehen:
@* Razor Component mit Template *@
<p>Mit freundlichen Grüßen</p>
@ChildContent
@code
{
[Parameter]
public RenderFragment ChildContent { get; set; }
}
Der Code im folgenden Listing rendert in einer Konsolenanwendung die E-Mail. Das entstandene HTML-Dokument gibt er auf der Konsole aus, speichert ihn in einer Datei und verwendet ihn zum Versand einer E-Mail:
using System.Diagnostics;
using ITVisions;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
namespace NET8_Console;
class FCL_RazorRendering
{
public async Task Run()
{
CUI.H1(nameof(FCL_RazorRendering));
#region Vorbereiten des Renderns mit Razor Templates
IServiceCollection services = new ServiceCollection();
services.AddLogging((loggingBuilder) => loggingBuilder
.SetMinimumLevel(LogLevel.Trace)
.AddConsole()
);
IServiceProvider serviceProvider = services.BuildServiceProvider();
ILoggerFactory loggerFactory = serviceProvider.GetRequiredService<ILoggerFactory>();
#endregion
#region HTML Rendering using a Razor Component
// Klasse HtmlRenderer neu in .NET 8.0
await using var renderer = new HtmlRenderer(serviceProvider, loggerFactory);
var html = await renderer.Dispatcher.InvokeAsync(async () =>
{
// Parameter zusammenstellen
var name = "Dr. Holger Schwichtenberg";
CUI.Print("Parameter 'Name' = " + name);
var pdic = new Dictionary<string, object>() { { "Name", name } };
var pv = ParameterView.FromDictionary(pdic); // oder: var pv = ParameterView.Empty;
// Nun EMailTemplate.razor rendern
var output = await renderer.RenderComponentAsync<Razor_EMailTemplates.EMailTemplate>(pv);
return output.ToHtmlString();
});
#endregion
#region HTML anzeigen
CUI.H2("Gerendertes HTML");
CUI.PrintYellow(html);
#endregion
#region HTML speichern
var path = Path.GetTempFileName();
path = Path.ChangeExtension(path, ".html");
System.IO.File.AppendAllText(path, html);
// Start new Process to open the File in the default Browser
Process.Start(new ProcessStartInfo(path) { UseShellExecute = true });
#endregion
#region HTML-E-Mail senden
new ITVisions.Network.MailUtil().SendMail("absender@IT-Visions.de",
"empfänger@IT-Visions.de",
"Terminbestätigung .NET 8.0",
html, HTML: true);
#endregion
}
}
(Bild: Screenshot (Holger Schwichtenberg))
URL dieses Artikels:
https://www.heise.de/-9691146
Links in diesem Artikel:
[1] https://weblogs.asp.net/scottgu/introducing-razor
[2] https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.components.web.htmlrenderer
[3] https://net.bettercode.eu/
[4] https://net.bettercode.eu/tickets.php
[5] mailto:rme@ix.de
Copyright © 2024 Heise Medien
(Bild: Lightspring/Shutterstock.com)
Nicht nur Putzfrauen sollen gezwungen werden, Kunden für US-Dienste auszuspionieren, etwa durch Hardware-Manipulation. Nicht zufällig drängt im Senat die Zeit.
Schnell, schnell muss es gehen im US-Senat. Denn am Freitag läuft der berüchtigte Abschnitt 702 des Überwachungsgesetzes FISA (Foreign Intelligence Surveillance Act) aus. Das darf nicht passieren, meinen beide US-Parteien – obwohl Donald Trump, Präsidentschaftskandidat der Republikaner, gegenwärtig für die Abschaffung dieses Überwachungsgesetzes ist. Das Unterhaus hat eine Verlängerung um zwei Jahre beschlossen, einen "Stasi-Paragraphen" hinzugefügt und gleichzeitig den Spionageauftrag erweitert. Der US-Senat muss noch zustimmen, mit Betonung auf "muss".
Die in Washington als Stasi-Paragraph bekannte Norm folgt eigentlich dem Beispiel der Volksrepublik China: Immer mehr Dritte sollen legal dazu gezwungen werden, heimlich für US-Geheimdienste zu spionieren. Bereits seit Jahren betroffen sind Netzbetreiber (electronic communication service provider). Doch das reicht den Spionen nicht mehr. Fortan sollen (mit wenigen Ausnahmen) alle und jeder dazu gezwungen werden können, die irgendwie Zugang zu Kabeln oder Geräten haben, über die Kommunikation laufen oder auf der Kommunikation gespeichert werden könnte. Das reicht vom Händler, der ein Netzwerkkabel verkauft, über den Bürovermieter bis zur Reinigungskraft, die einen Router abstauben kommt.
Sie alle können fortan legal dazu gezwungen werden, Daten abzusaugen, Spyware zu installieren oder Hardware zu manipulieren – so sieht es die vom US-Unterhaus verabschiedete Reform des FISA vor. Ausgenommen sind lediglich Vermieter bestimmten Wohnraums, Restaurants, und bestimmte öffentliche Einrichtungen wie Wasser- und Abwasserwerke, Müllentsorger, Polizei und Feuerwehr, Spitäler und Bibliotheken. Schon die Ausnahmeregeln zeigen, wie weitreichend der Spionagezwang ist.
Und es gibt eine große Ausnahme von der Ausnahme: Hat jemand von den Ausgenommenen ein Gerät oder Kabel zur Aufbewahrung oder Verwaltung inne, kann auch er zur Spionage gezwungen werden. Man denke an ein Krankenhaus, das eigentlich ausgenommen ist, das aber auf das Handy eines Patienten aufpasst, während er behandelt oder operiert wird.
Eine weitere Änderung weitet die Definition der zu sammelnden Daten aus. Es geht schon lange nicht mehr nur um Terrorismus und die Spionageabwehr. Nun kommen auch Drogen expliziert hinzu, und sogar deren Vorläufersubstanzen, die nicht selten alltägliche und harmlose Anwendungen haben. Informationen über Produktion, Verteilung und Finanzierung (!) solcher Substanzen sollen fortan offizielles Ziel der US-Auslandsspionage sein.
Ausgedehnt wird auch die Verwendung der gewonnenen Daten: Sie sollen fortan in vollem Umfang zur Überwachung [1] jeder ausländischen Person genutzt werden dürfen, die vorhat, in die USA einzureisen.
Der Begriff Auslandsspionage ist mit Anführungszeichen zu verstehen. Offiziell sind Ausländer völliges Freiwild, US-Personen dürfen aber im Inland nicht ausspioniert werden. Offiziell. Tatsächlich ist diese Einschränkung so dicht wie ein Maschendrahtzaun. Kommunikation von US-Personen im Inland [2] mit Ausländern wird ebenso überwacht, wie inländische Kommunikation zwischen US-Personen, in der ausländische Ziele bloß erwähnt werden. Letzteres ist als "abouts-communication" bekannt und soll fortan nicht mehr zulässig sein – das wäre die einzige Einschränkung dieser FISA-"Reform". Die Einschränkung gilt allerdings nur für vorsätzliche Überwachung, die auf "abouts-communication" abzielt.
Ist sie Beifang anderer Überwachung, darf sie auch weiterhin ausgewertet werden. Das gilt überhaupt für alle Informationen von oder über US-Personen, die von den Geheimdiensten gesammelt wurde. Sie darf auch Jahre später noch für völlig andere Zwecke genutzt werden. Zwar gab es im Unterhaus einen Abänderungsantrag, der dem FBI auferlegt hätte, solche Datenbankabfragen nur mit richterlicher Genehmigung durchzuführen. Doch ist dieser Antrag mit 212 zu 212 Stimmen gescheitert.
Bei der Erneuerung des FISA-Abschnitts 702 hat man sich so viel Zeit gelassen, dass der US-Senat nun unter Zugzwang steht. Er muss bis Freitag ebenfalls zustimmen, sonst fällt die Rechtsgrundlage für ganz viel Spionage, und das will in Washington niemand. Zeit, mit dem Unterhaus über Änderungen der Novelle zu beraten, bleibt kaum. Die abschließende Unterschrift durch US-Präsident Biden ist reine Formsache, ist doch das Weiße Haus eine der treibenden Kräfte hinter der Reform.
URL dieses Artikels:
https://www.heise.de/-9687201
Links in diesem Artikel:
[1] https://www.heise.de/thema/Ueberwachung
[2] https://www.heise.de/news/USA-Auslandsueberwachung-trifft-auch-US-Buerger-3568157.html
[3] https://www.congress.gov/bill/118th-congress/house-bill/7888/text
[4] mailto:ds@heise.de
Copyright © 2024 Heise Medien
[unable to retrieve full-text content]
(Bild: Maksim Shmeljov/Shutterstock.com)
Japan hat seine Pole-Position in der Chipproduktion seit den 1990er-Jahren verloren. Doch ein Großprojekt soll das ändern.
Die japanische Regierung hat ehrgeizige Pläne, um das Land wieder zu einem führenden Standort für die Chipproduktion zu machen. Anfang des Monats erhöhte sie die Subventionen für das Start-up Rapidus um 3,3 Milliarden auf etwa 6 Milliarden Euro. Das Investitions-Projekt gilt als einer der gewagtesten Versuche für eine technologische Aufholjagd, da Japan damit mehrere Chipgenerationen überspringen will.
Das Land ist zwar laut einer Analyse des Aktienhauses Morgan Stanley MUFG mit einem Anteil von 20 Prozent an der weltweiten Chipproduktion eine der größten Herstellernationen für Halbleiter. Doch dabei handelt es sich ausschließlich um alte Technologien mit Strukturen im zweistelligen Nanometerbereich. Moderne Chips stammen inzwischen zum großen Teil von TSMC aus Taiwan [1].
Das 2022 von japanischen Unternehmen wie Toyota und dem Technikkonzern NEC gegründete Rapidus [2] will hingegen Chips mit 2-Nanometer-Strukturen fertigen und damit zu den technologischen Weltmarktführern TSMC, Samsung aus Südkorea und Intel aufschließen.
Experten der US-Denkfabrik Center for International & Strategic Studies sehen darin "eine beispiellose technologische Leistung", wenn es den Japanern denn gelingt. Die Voraussetzungen sind so gut, wie sie nur sein können. Rapidus arbeitet eng mit anderen Unternehmen zusammen. Expertise bei fortschrittlicher Fertigungstechnik und Chipdesign stammt von IBM [3], die Belichtungstechnik von Imec in Belgien, während die Japaner letztlich die Produktionstechnik entwickeln. Trotzdem ist das Ganze alles andere als ein einfaches Unterfangen – es gilt, weit mehr als ein Jahrzehnt Entwicklungsrückstand aufzuholen.
Für Japans Regierung wäre es die Krönung ihrer Strategie, die Chipindustrie der einst führenden Halbleiternation wiederzubeleben. In den 1980er- und 1990er-Jahren stammten mehr als die Hälfte aller Computerchips aus der ältesten Industrienation Asiens. Doch als die Chipproduktion mit dem Start der digitalen Epoche und dann erst recht mit Smartphones richtig losging, konnten die Elektronikkonzerne beim Investitionswettrennen nicht mit ihren asiatischen Rivalen mithalten.
Zum einen war Japans Chipindustrie zu fragmentiert und damit die Sparten der Konzerne jede für sich zu klein. Zum anderen steckten viele Konzerne in Krisen und waren daher finanziell klamm, während Taiwan und Südkorea lokale Chipfertiger stark subventioniert haben. Daher überlebte die japanische Produktion nur in Nischen.
Toshibas ehemalige Speicherchip-Sparte leistet nun als Kioxia Samsung und SK Hynix Konkurrenz. Renesas, eine Auffanggesellschaft für die Chipsparten mehrerer Unternehmen, baut Chips für automobile und industrielle Anwendungen. Darüber hinaus sind die Japaner auch bei Sensoren stark, insbesondere bei Bildsensoren für Kameras und Smartphones. Zudem konnten die Hersteller von Anlagen, Bauteilen und Chemikalien bisher ihre starke Stellung in der globalen Chiplieferkette verteidigen.
Ende des vorigen Jahrzehnts beschloss die Regierung dann, die überlastete eigene Chipindustrie als Grundlage für eine industrielle Aufholjagd zu nutzen. Der Grund: Der wachsende Großmachtkonflikt zwischen China und den USA sowie Chinas Drohung, die Chip-Hochburg Taiwan anzugreifen, schürte die Angst, dass die Chip-Lieferungen für die eigene Industrie abreißen könnten.
Japans Ministerium für Wirtschaft, Handel und Industrie (METI) ging bei ihrer Wiederbelebungsstrategie sehr strategisch vor. Im Gegensatz zur Europäischen Union oder den USA verzichtete die japanische Regierung darauf, große Subventionspakete in Höhe von Milliarden Euro zu versprechen. Stattdessen werden staatliche Beihilfen projekt- und schrittweise vergeben. Zudem verfolgte die Regierung eine Etappenstrategie.
Zuerst konzentrierte sich das Ministerium darauf, TSMC zum Bau von Werken für relativ große Chips zu gewinnen [4], die Japans Industrie hauptsächlich benötigt. Damit wollten die Wirtschaftsplaner dafür sorgen, dass es für die Chips auch wirklich einen Absatzmarkt gibt.
Die Japaner überzeugten die Taiwaner sogar davon, mit dem Elektronikkonzern Sony und dem Automobilzulieferer Denso ein Joint Venture zu gründen. Dieses Modell steht auch für das Engagement von TSMC in Dresden [5] Pate.
Der Aufbau der ersten Fabrik, die Anfang des Jahres eingeweiht wurde, lief sogar so glatt, dass TSMC bereits ein zweites Werk plant. Dort sollen 6-Nanometer-Chips für autonomes Fahren hergestellt werden. Gerüchten zufolge denken die Taiwaner sogar über ein drittes Werk nach.
Der frühe Erfolg der Ansiedlungsstrategie stärkte die Bereitschaft der Wirtschaftsplaner, mit Rapidus eine wirklich große technologische Wette zu wagen. Die Regierung ist sich sehr wohl bewusst, dass dies Japans letzte Chance ist, mit einem japanischen Unternehmen in der Weltspitze mitzuspielen. METI-Minister Ken Saito sagte daher im vergangenen Jahr: "Das Projekt darf auf keinen Fall scheitern."
URL dieses Artikels:
https://www.heise.de/-9680421
Links in diesem Artikel:
[1] https://www.heise.de/thema/TSMC
[2] https://www.heise.de/news/Halbleiter-Wettrennen-Japan-gruendet-Rapidus-fuer-neue-2-Nanometer-Fertigung-7337319.html
[3] https://www.heise.de/thema/IBM
[4] https://www.heise.de/news/TSMC-Werke-Japan-subventioniert-angeblich-40-Prozent-9637437.html
[5] https://www.heise.de/news/TSMC-kommt-als-ESMC-nach-Deutschland-9237991.html
[6] https://www.instagram.com/technologyreview_de/
[7] mailto:jle@heise.de
Copyright © 2024 Heise Medien
[6]