And now for something completely different – Die Chip-Krise
Von heise online — 13. Mai 2022 um 11:55
(Bild: Rowan Morgan/Shutterstock.com)
Eigentlich sollte auf diesem Blog schon längst eine Serie zum Raspberry Pi Zero 2 W beginnen. Doch die Chip-Krise hat dies verhindert.
Eigentlich sollte auf diesem Blog schon längst eine Serie zum Raspberry Pi Zero 2 W beginnen. Doch die Chip-Krise hat dies verhindert, weil sich momentan kein Raspberry-Pi-Board erwerben lässt; zumindest nicht zu vernünftigen Preisen, also für 15 Euro statt für Wucherpreise um die 50 bis 100 Euro. Woran das liegt, möchte der vorliegende Artikel beleuchten.
Am Anfang war Corona
Als wegen des Coronavirus Sars-CoV-2 die jetzige Wirtschaftskrise im Frühjahr 2020 begann, hoffte die Halbleiterindustrie gerade, sich von ihrer eigenen Wirtschaftsflaute zu erholen. Doch das Virus bereitete dieser Hoffnung schon bald ein jähes Ende. Kunden der Chipproduzenten stornierten übereifrig viele Aufträge, etwa die Automobilindustrie. Kurz darauf erholte sich die Nachfrage zwar wieder so stark, dass die Produktionskapazitäten nicht mithalten konnten, aber bis heute leiden viele Branchen und auch die Maker-Szene unter diesem Problem.
Der ein oder andere mag sich noch daran erinnern, dass durch das Corona-indizierte Homeoffice der Bedarf nach Consumer-Electronics (beispielsweise Webcams, Spielekonsolen, Streaming-Hardware) stark anstieg, was das Problem weiter verschärfte.
Von dem Chip-Mangel sind auch zahlreiche Boards aus der Raspberry Pi Familie betroffen
Weitere Ursachen
Es gab allerdings parallel zur Pandemie auch noch andere Ursachen.
Pleiten, Pech und Pannen: Im Winter 2021 fielen wegen eines dramatischen Kälteeinbruchs im texanischen Austin mehrere Fabs aus. Zusätzlich gab es in Japan einen Großbrand in einer für die Automobilindustrie wichtigen Halbleiterfabrik. Das alles in einer Zeit, in der wegen Corona ohnehin weniger Arbeitskräfte verfügbar waren. Zu schlechter-letzt kam Ende des Jahres 2021 wegen Komplett-Lockdowns die Halbleiterproduktion im chinesischen Xian zum Stopp.
Donald Trump: Aufgrund der US-Sanktionen und Handelsbeschränkungen gegenüber China durch Präsident Trump sollten chinesische Elektronikhersteller weniger Halbleiterprodukte aus den USA beziehen können. Das brachte die Firmen dazu, zum einen große Hamsterkäufe benötigter Komponenten zu tätigen und zum anderen, sich stärker auf eigene Füße zu stellen.
Bitcoin & Co: Da wäre auch noch der Run auf Kryptowährungen. Dieser Trend hat zu riesigen Serverfarmen geführt, die mit großem Aufwand Mining betreiben, also das energieintensive Erschaffen neuer Bitcoins. Durch den Anstieg der Energiepreise war das Mining schon bald nicht mehr rentabel, weshalb die professionellen Miner ihre Zelte in China aufschlugen, was der chinesische Staat aber sinnvollerweise schon bald unterbunden hat. Um Mining weiterhin rentabel zu gestalten, bedarf es vieler Rechenressourcen in Gestalt von Hochleistungsgrafikkarten. Das führte schon vor der Pandemie zu Engpässen und letztendlich dazu, dass die Preise für Grafikkarten alle Preisindizes nach oben durchbrachen.
Rohstoffe: Eine wichtige Ingredienz zur Fertigung von Halbleiterprodukten sind die dafür benötigten Ressourcen. Damit ist nicht etwa nur Silizium gemeint, das es sprichwörtlich wie Sand am Meer gibt. Für die Veredelung zu Reinstsilizium sind entsprechende Produktionskapazitäten notwendig, und für Elektronik sind seltene Erden und Metalle unabdingbar. Diese sind aber sehr beschränkt auf unserem Planeten verfügbar. Viele Länder und Firmen konkurrieren um sie. Bis zur Entwicklung geeigneter Ersatzstoffe kann es noch eine Weile dauern.
Quo vadis?
Erst für Ende 2022 haben einige Marktanalysten das Ende dieser Knappheit prognostiziert. Es würden demnach noch einige Monate vergehen, bis sich die Situation wieder einigermaßen beruhigen könnte. Der CEO von Intel, Pat Gelsinger, prophezeit sogar, dass das limitierte Angebot für Chips sich noch bis ins Jahr 2024 erstrecken dürfte. Keine guten Nachrichten also sowohl für die Industrie als auch für Konsumenten.
Was Maker jetzt tun können:
Bei Single-Board-Computern wie der Raspberry-Pi-Familie hilft nur, sich bei den bekannten Händlern auf den entsprechenden Online-Seiten anzumelden, um mitzukriegen, dass neue Tranchen zu vernünftigen Preisen wieder verfügbar sind. Erfahrungsgemäß erhalten die größeren Händler immer wieder Lieferungen, die sie aber relativ schnell verkaufen. Allerdings sind Boards wie Raspberry Pi Zero und Zero 2 W jetzt schon über einen längeren Zeitraum nicht mehr in den Lagern der Händler vorzufinden.
Im Bereich der Microcontroller-Boards ist die Lage momentan relativ entspannt. Boards wie die der Arduino-Familie, ESP8266- & ESP32-Boards sowie Raspberry Pi Picos sind problemlos verfügbar. Ein Hamstern ist also unnötig. Dennoch empfiehlt es sich, für geplante Projekte die notwendigen Komponenten frühzeitig einzukaufen – sicher ist sicher!
Bei den Boards von beispielsweise Microchip oder STM existieren aber durchaus einige Produkte, die voraussichtlich erst 2023 wieder zur Verfügung stehen. Lady Ada von Adafruit gibt dazu einige Hinweise und Informationen in ihrer jungen YouTube-Playlist "Chip Shortage" [1]. Unter dem Titel "The Great Search" hat Adafruit in Zusammenarbeit mit Digi-Key weitere YouTube-Videos bereitgestellt. In diesen Episoden erläutert Lady Ada, wie der Maker für bestimmte Funktionalitäten wie etwa Schaltern herausfinden kann, welche konkreten Produkte es gibt, die alle oder die meisten gewünschten Anforderungen erfüllen. Dadurch lassen sich auch Alternativen zu vergriffenen beziehungsweise nicht verfügbaren Bausteinen finden. Diese YouTube-Videos sind zwar weniger unterhaltend, dafür aber sehr informativ und hilfreich. Wer sich dafür interessiert, sollte auf YouTube nach "The Great Search" und "Adafruit" suchen oder den Adafruit-Blog [2] konsultieren.
Fazit
Die Chip-Krise dürfte uns noch einige Zeit begleiten. Speziell bei der Herstellung leistungsfähigerer und damit komplexerer Chips kommt die momentane Knappheit zum Tragen. Das führt beispielsweise bei Automotive-Anwendungen zu Problemen, aber auch bei Consumer-Produkten.
Zum Glück sind nicht alle Produktkategorien gleichermaßen davon betroffen. Im Microcontroller-Bereich schaut es noch besser aus. Trotzdem erscheint es ratsam, eigene Maker-Projekte bezüglich der Bill of Material rechtzeitig vorab zu planen und die eigene Logistik entsprechend anzupassen. Dieser Blog wird jedenfalls darauf Rücksicht nehmen, zumal es keinen Sinn ergibt, Projekte oder Boards vorzustellen, die der interessierte Maker nicht oder nur zu Wucherpreisen anschaffen kann.
URL dieses Artikels: https://www.heise.de/-7090001
Links in diesem Artikel: [1] https://youtube.com/playlist?list=PLjF7R1fz_OOX6EyjN3BYud1VHIqnDyvm_ [2] https://blog.adafruit.com/category/the-great-search/ [3] mailto:michael.stal@gmail.com
Frisch aus der Werkstatt - Ein Selbstbau-Synthesizer von Moog
Von heise online — 07. April 2022 um 06:58
Frisch aus der Werkstatt - Ein Selbstbau-Synthesizer von Moog
Dr. Michael Stal
(Bild: Moog Music)
In der letzten Episode stand der Korg NTS-1 im Fokus. Das ist aber nicht der einzige verfügbare Synthesizer zum Zusammenbauen.
Vom Urvater aller Synthesizer Robert Moog gibt es einen relativ preisgünstigen Bausatz namens Werkstatt-01. Um diesen "Mini-Moog" soll es im vorliegenden Beitrag gehen.
Werkstatt-01 – des Moogs Kern
Der analoge, einstimmige Moog-Synthesizer Werkstatt-01 kam zum ersten Mal im Jahre 2015 als DiY-Baukasten auf den Markt. Das Produkt umfasst einen kleinen Analogsynthesizer, der Technik von größeren Moog-Synthesizern wie Little Phatty, Sub 37 oder Mini Voyager enthält.
Das Kit ist das Ergebnis des jährlich stattfindenden Moogfests, bei dem Kunden, Künstler und Mitarbeiter die Moog-Produktfamilie zelebrieren. Dazu gehören unter anderem Vorträge und musikalische Sessions. Im Jahr 2014 konnten Interessenten unter Hilfestellung von Moog-Mitarbeitern den kleinen Synthesizer Werkstatt-01 zusammenbauen, sich daran auch nach der Konferenz erfreuen, und außerdem überall und jedermann von diesem Miniatursynthesizer erzählen, was schließlich in der Moog-Community zu einer Euphorie für den Werkstatt-01 führte. Überrascht von dieser positiven Resonanz, beschloss Moog, den DiY-Synthesizer 2015 als Baukasten für alle Interessierten herauszubringen.
Zu Beginn mussten Synthesizer- oder Elektronikfreaks noch über 300 Euro für das Kit hinblättern plus weitere 49 Euro für den optionalen CV-Expander.
2020 hat Moog den Synthesizer neu aufgelegt. Seitdem ist der Bausatz inklusive CV-Expander bereits für rund 215 Euro im Fachhandel erhältlich.
Bauarbeiten
Das Zusammenschrauben beziehungsweise Stecken der Komponenten dauert nicht mehr als zehn Minuten. Alles, was Maker dafür benötigen, ist ein handelsüblicher Philips-Schraubenzieher. Die folgende Bilderstrecke illustriert, welche Schritte dabei nötig sind.
Unboxing: Der Synthesizer kommt gut verpackt an.
Sichtung aller gelieferten Teile.
Zunächst montiert der Maker die Gummifüße ans Gehäuse.
Die PCB-Platine kommt per Schrauben aufs Gehäuse
Ein gutes Zeichen: die rote LED brennt.
Vor dem Aufstecken des Frontpanels sollten angehende Moog-Anwender den Werkstatt-01 über das mitgelieferte Netzteil an den Strom anschließen. Leuchtet die rote LED bei LFO kontinuierlich oder blinkt sie je nach Einstellung des RATE-Drehknopfes, dann funktioniert das Gerät einwandfrei.
Wer auch den CV-Expander am Gerät befestigen möchte, verwendet auf der rechten Gehäuseseite die zwei beigelegten spitzen Schrauben statt der zwei schwarzen Gehäuseschrauben.
Nun wird noch auf der rechten Gehäuseseite der CV-Expander montiert.
Was der Werkstatt-01 unter der Haube bietet
Im letzten Beitrag [1] kamen bereits die grundsätzlichen Elemente eines (analogen) Synthesizers zur Sprache. Trotzdem erfolgt an dieser Stelle nochmals ein Überblick, um auch die Terminologie von Moog kennenzulernen.
Grobarchitektur des Werkstatt-01. Die durchgehenden Pfeile repräsentieren Audiosignale, die gestrichelten Pfeile Kontrollsignale.
(Bild: (c) Moog Music)
Die erste und zentrale Komponente jedes Synthesizers ist ein Oszillator, der Wellen mit bis zu 16 kHz erzeugt. Dieser firmiert unter dem Begriff VCO (Voltage-Controlled Oscillator) und erlaubt beim Werkstatt-01 (Bedienbereich WAVE) entweder Sägezahnwellen (SAW) oder Rechteckswellen (PULSE). Deren Frequenz lässt sich mit dem FREQ-Poti und deren Intensität mit dem PWM-Poti vom Anwender beeinflussen. PWM steht dabei für Pulse-Width-Modulation und bestimmt, wie lange das Signal anliegen (Busy-Phase) und wie lange es nicht anliegen soll (Idle-Phase). Dadurch lässt sich die Intensität des Signals variieren.
Ein Envelope Generator (ENVELOPE beziehungsweise EG) bietet Einstellmöglichkeiten für jeden erzeugten Ton: A = Attack beschreibt die Zeit, bis zu der ein Ton seine maximale Amplitude (Lautstärke) erreicht, S = SUSTAIN regelt die Höhe des Tons (SUSTAIN = ON), und D = DECAY ist dafür verantwortlich, wie lange es am Schluss dauert, bis der Ton wieder die 0 erreicht.
Links unten auf dem Bedienpanel gibt es als weiteren Oszillator den LFO (Low-Frequency Generator), der im Gegensatz zum VCO einen niedrigfrequenten Oszillator darstellt. Als Wellenformen sind Rechteckswellen und Dreieckswellen möglich. Der Schaltpoti RATE stellt die Frequenz des LFO ein. Dessen Wellen sind für das menschliche Ohr nicht hörbar. Aber wozu braucht es dann überhaupt einen LFO?
Oberfächliches Schaltungsdiagramm für den Werkstatt-1
Dazu betrachten wir zwischen VCO und LFO den VCO MOD, einen Modulator, der vorgegebene Wellen moduliert. Dessen Quelle (SOURCE) kann dabei entweder der LFO oder der Hüllkurvengenerator (EG) sein. Die Modulation arbeitet dabei als Ziel (DEST) entweder auf der Pulsweitenmodulation (PWM) oder der Frequenz (FREQ) des VCO. Die Intensität beziehungsweise Stärke der Modulation hängt von der Einstellung von AMOUNT ab. Obwohl also die vom LFO erzeugten Wellen für uns nicht hörbar sind, verändern sie angewandt auf den VCO den Sound hörbar. Der LFO spielt also eine wichtige Rolle bei dem Anpassen der Wellenform.
Im Abschnitt rechts neben dem VCO residiert der VCF (Voltage-Controlled Filter), eine Komponente, die aus der im VCO erzeugten Welle Frequenzen herausschneidet oder Resonanz hinzufügt. Mit dem Poti CUTOFF legt der Musiker fest, welche Frequenzen der Synthesizer herausfiltern soll. Damit wird auch der Moog-typische Ladder-Filter mit 24db Flankenanstieg realisiert, der Moog-Synthesizern ihren charakteristischen, "fetten" Ton verschafft. Bei der Resonanz füttert der Synthesizer die Ausgabe des Filters nochmals an den Eingang zurück, was zu einer harmonischen Verstärkung des Tons führt.
Rechts daneben befindet sich der VCA (Voltage-Controlled Amplifier), der entweder auf Basis der Hüllkurve dynamisch arbeitet (EG) oder statisch einen andauernden Ton erzeugt (ON).
Der Modulator namens VCF MOD nutzt als Quelle (SOURCE) entweder den Hüllkurvengenerator (EG) oder den LFO, moduliert dabei mit einer einstellbaren Stärke (AMOUNT) den Filter VCF und kann dabei auch die Polarität umkehren (POLARITY), was erlaubt, die CUTOFF-Frequenz weiter zu senken und damit einen "dunkleren" Sound zu erzeugen. Wenn etwa der VCF MOD den LFO als Quelle nutzt, verschiebt sich dynamisch und regelmäßig die CUTOFF-Frequenz des Filters VCF gemäß dem dazumodulierten LFOs, sodass als Ergebnis ein alarmartiger Klang entsteht.
Der Drehknopf GLIDE dient dazu, den Übergang zwischen zwei aufeinanderfolgenden Tastenanschlägen festzulegen, beantwortet also die Frage, ob sich Töne stakkatoartig, also abrupt abwechseln, oder stattdessen legatoartig sanft ineinander gleiten.
Rechts neben dem GLIDE-Knopf befinden sich übrigens die Tasten, um einzelne Noten einer Oktave zu spielen. Dieser Kompromiss ist der Größe des Synthesizers geschuldet, weil der kleine Synthesizer natürlich keinen Platz für eine echte Klaviatur besitzt. Die unteren acht Eingabeknöpfe entsprechen den weißen Tasten eines Klaviers im Umfang einer Oktave, die fünf oberen Knöpfe den schwarzen Klaviertasten.
In der Spielpraxis empfiehlt sich deshalb eine andere, bequemere Eingabemöglichkeit etwa ein Midi-Keyboard.
Im Großen und Ganzen legt das Gerät also fest, wie seine verschiedenen Sektionen verschaltet sind. Hier ist oft vom Signalpfad die Rede. Durch Wechselschalter lassen sich zumindest alternative Signalpfade definieren, etwa bei der schalterbasierten Wahl zwischen unterschiedlichen Quellen und Zielen beim VCO MOD.
Der am Werkstatt-01 anmontierte CV-Expander – CV steht für Control Voltage – verändert diese Situation, in dem er mittels Patchkabel erlaubt, eigene Signalpfade zu definieren. Dadurch lässt sich der Werkstatt-01 vereinfacht als semimodularer Synthesizer betrachten. Nebenbei bemerkt: Ohne Integration des CV-Expanders lassen sich diese Verbindungen mittels eingesteckter Dupontkabel vorgeben.
Am CV-Expander lassen sich neue Signalpfade per Patch-Kabel schalten, die zu interessanten Sounds führen.
Und als Eingänge: VCF OUT IN, GATE IN, LFO IN, VCO EXP IN, VCO LIN IN, VCA IN, CV IN.
Wer also einen Eingang mit einem Ausgang verbindet, kann völlig neue Konfigurationen definieren. Der Synthesizer bietet für jeden Ausgang zwei Ports, für jeden Eingang einen Port. Damit lassen sich von jedem Ausgang per Kabel bis zu zwei Eingänge ansteuern.
Mögliche Beispielskonfiguration: Musiker verbinden per Dupontkabel oder Patchkabel den Ausgang des Envelope Generators mit dem Eingang des LFO. Dadurch beeinflusst das vom Envelope Generator ausgehende Spannungssignal die Frequenz des LFOs, was zu einem speziellen oszillierenden Ton mit sich vergrößernden Dämpfung führt.
Benutzung und Kalibrierung des Synthesizers
Zunächst lohnt es sich, mit dem Synthesizer zu experimentieren. Einfach einen Kopfhörer in die 6,3 mm-Buchse anschließen und schon kann es losgehen.
Das Werkstatt-01 Exploration Patchbook [5] ist ein guter Ausgangspunkt, um zu lernen, wie sich verschiedene Soundeffekte mittels Patchkabel am CV-Expander erzielen lassen.
Einbringen von Verzerrung mittels zweier Patchkabel.
“Pick up the Phone” ist ein weiterer Patch-Vorschlag.
Auf der SoundCloud [6] finden sich unter der Suchzeichenkette “moog werkstatt” allerlei Beispiele für im Werkstatt-01 produzierte Sounds.
Den Anschluss externer Hardware, zum Beispiel des Midi-Keyboards Arturia KeyStep Pro an den Werkstatt-01 über den CV-Expander, zeigt exemplarisch ein Video des amerikanischen Händlers Sweetwater [7] ().
Beim Anschließen externer Hardware kann es freilich passieren, dass die Oktave auf dem Moog nicht mehr richtig kalibriert ist, was zum Beispiel zu einer Abweichung von einem Halbton führen kann, weil etwa aus dem oberen C ein C# wird. In diesem Fall muss der Anwender den Synthesizer kalibrieren. Dazu gibt es sowohl Anleitungen auf YouTube [8] als auch ein Manual [9]. Normalerweise deckt 1 V auf dem Synthesizer eine Oktave ab, aber durch Anschluss eines externen Geräts ist es möglich, dass sich hier etwas verschiebt, was sich durch den Trimpoti VCO EXP TRIM kalibrieren lässt. Der sitzt direkt auf dem eingebauten PCB-Board. Zum Kalbrieren reicht also das VCO-EXP-TRIM-Poti plus ein Instrumententuner, den es als Hardware oder als Smartphone-App gibt.
Mods
Den Synthesizer von Moog betrachtet der Artikel vor allem wegen seiner Ausbaufähigkeiten. So können Anwender unter anderem den LFO zu einem zweiten VCO umbauen, per Arduino oder einem anderen Microcontroller einen Arpeggiator konstruieren oder einen wabbelnden Klang erzeugen, eine Pitchbend-Möglichkeit oder einen Noise-Generator hinzufügen, und vieles mehr.
Für die Mods sind im wesentlichen einfache Bausteine wie Breadboards, Dupontkabel, Widerstände, Potis und Kondensatoren notwendig. Bei ausgefeilteren Mods kommen auch schon einmal Arduino Boards oder 555-ICs zum Einsatz. Jeder Mod benötigt den GND des Werkstatt-01. Dazu öffnet der Maker das Gehäuse, und verbindet das abisolierte Ende eines schwarzen Dupontkabels mit einer der inneren Schrauben, die das Synthesizerboard am metallenen Gehäuserahmen befestigen. Führt man das andere Ende dieses Kabels nach außen, lässt es sich mit der Schaltung des Mods als Common Ground verbinden.
Der Besitzer des Werkstatt-01 offeriert also eine ganze Palette an Möglichkeiten zum Erweitern.
Auch andere Mütter haben schöne Töchter
Sowohl der Moog Werkstatt-01 als auch der Korg NTS-1 kamen in diesem Blog zur Sprache, weil sie ermöglichen, Themen wie Elektronik und Musik, Mikrocontroller, Embedded Software zu adressieren. Die beiden vorgestellten Kits sind nicht mehr die jüngsten, stammen dafür von bekannten, innovativen Unternehmen, haben eine große Community, und lassen sich modifizieren beziehungsweise erweitern.
Wer einen ausgefeilten DiY-Synthesizer zu einem günstigen Preis sucht, sollte die Webseite von Zynthian besuchen. Bei Zynthian handelt es sich um eine Open Synth Software und gleichzeitig um eine Linux-Distribution für den Raspberry Pi (3 oder 4). Wer die Community unterstützen möchte, ordert das zugehörige Kit (aktuelle Version [15]). Ein Zynthian-Gerät lässt sich aber auch mit einfachen Mitteln selbst entwerfen und zusammenbauen. Von Floyd Steinberg gibt es dazu ein passendes YouTube-Video [16], in dem aus einem Raspberry Pi Board, einem kleinen Touch-Display und einem Midi-USB-Kabel ein Zynthian-Synthesizer entsteht.
Die Axoloi Community [17] hat ein Board erstellt (Axoloti Core), mit dem sich unter Zuhilfenahme einer außergewöhnlichen Software, dem Axoloti Patcher, coole Sachen machen lassen. Es könnte aber unter Umständen schwierig sein, ein solches Board zu erwerben. Zumindest hatte der Autor damit Probleme.
Für Synthesizer-Interessierte mit mehr Bezug zum Musikmachen als zu Elektronik und Embedded Systemen, gibt es schon für wenige Hundert Euro sehr leistungsfähige Geräte. So eignen sich für den Einstieg zum Beispiel der Korg Minilogue XD oder der Wave-basierte ASM HydraSynth-Explorer, der Roland JD-Xi, der Arturia MicroFreak, der Behringer DeepMind 6, oder der Yamaha MX49 V2.
Fazit
In dieser und der vorherigen Folge kamen die Synthesizer Korg NTS-1 und Moog Werkstatt-01 zur Sprache. Beide Kits stammen von renommierten Unternehmen, verfügen wegen ihres Alters über große Communitys, und erweisen sich als gut erweiterbar mittels eigener Software und Elektronik. Sie vermitteln Grundkenntnisse in puncto Synthesizer, und lassen sich durch die große Zahl von Informationsquellen leicht durchdringen. Während der Werkstatt-01 das Patchen über Kabel erlaubt, trumpft der NTS-1 mit mehr Schnittstellen auf. Das Experimentieren mit ihnen macht Spaß, weil man sie gut in die eigene Sound-Konfiguration integrieren kann. Beim ein oder anderen wird dadurch vielleicht der Funken entzündet, es auch mal mit ausgewachsenen Geräten zu versuchen.
URL dieses Artikels: https://www.heise.de/-6664968
Der Synthesizer ist ein Paradebeispiel für die Symbiose aus Musikinstrumentenbau und Elektronik. Ein kleiner Bausatz macht Appetit darauf.
Egal ob Tonabnehmer, Instrumententuner oder Effektgeräte für Gitarristen - schon vor langer Zeit sind Musikinstrumentenbau und Elektronik eine erfolgreiche Symbiose eingegangen, anfangs bei Gitarren und Keyboards. Als Paradebeispiel für die vollständige Verschmelzung beider Disziplinen fungieren Synthesizer, weshalb in diesem Beitrag ein kleiner Bausatz im Vordergrund stehen soll.
Es fängt nicht immer klein an
1964 erschuf der legendäre Robert Moog den weltweit ersten analogen Synthesizer. Er hat anfangs die Geräte dieser Gattung als raumfüllende Spezialanfertigungen für Musikstudios konzipiert.
Erst ab 1970 wurden Synthesizer wie der kompakte Minimoog einem breiteren Publikum zugänglich und inspirierten andere Unternehmen dazu, auf Moogs Spuren zu wandeln. Firmennamen wie Korg, Roland, Akai oder Oberheim dürften für die meisten Musikgenießer bekannt klingen.
Heutzutage existieren Synthesizer in allen Leistungs- und Preisklassen. Korg, AKAI, Roland und selbst Moog bieten entsprechende Produkte für wenig Geld an.
Für noch weniger Geld lassen sich freilich im Apple App Store oder Google Play Store Apps erwerben, die ganze Synthesizer simulieren, darunter auch legendäre Geräte wie den Minimoog. Aber seien wir ehrlich: An die akkustischen und haptischen Momente mit echter Hardware kommen virtuelle Synthesizer nicht ran.
Wer aus Elektroniksicht tiefer in die Materie eintauchen und die innere Arbeitsweise von Synthesizern kennenlernen möchte, geht ins Museum oder legt selbst Hand an. Und dafür eignet sich insbesondere der Korg NTS-1, ein als Baukasten ausgelieferter minimalistischer Synthesizer. Es ist beileibe nicht der einzige Synthesizer-Bausatz, aber eindeutig einer der interessantesten.
Der Mini-Synthesizer NTS-1 von Korg ist als Bausatz konzipiert.
Übrigens werde ich in einem Folgeartikel auch noch auf den Moog Werkstatt-01 eingehen, den Interessierte ebenfalls als Bausatz erwerben können, um sich als Besitzer eines Moog betrachten zu können.
Was ist ein Synthesizer?
Ein Synthesizer setzt per Klangsynthese in Echtzeit auf elektronischem Weg Klänge zusammen. Die Ansteuerung der synthetisierten Klänge kann durch einen Sequenzer (spielt gespeicherte Klangfolgen), einen Arpeggiator (spielt Akkorde) oder durch eine Klaviatur (spielt alle gedrückten Tasten) erfolgen.
Dabei synthetisiert ein monophoner Synthesizer nur einen Ton gleichzeitig, ein polyphoner Synthesizer hingegen mehrere. Die Elektronik eines Synthesizers, egal ob mono- oder polyphon, kann dabei analog, digital oder hybrid arbeiten.
Der erste Baustein, den Musiker auf einem Synthesizer vorfinden, ist ein sogenannter VCO (Voltage-Control-Oscillator), der eine Welle als Fundament erzeugt. Ein VCO erlaubt das Generieren von Wellen in verschiedenen Formen, Frequenzen und Amplituden. Als Wellenform treten häufig Sinuskurven, Sägezahn-, Dreieck- und Rechteckformen (Pulse) auf. Synthesizer wie der Korg-NTS1 erlauben zusätzlich benutzerdefinierte Wellenformen. Während eine Sinuswelle einen “sauberen” Ton erzeugt, weisen andere Wellenformen unterschiedliche charakteristische Obertöne (sogenannte Harmonics) auf. Das gilt auch für Musikinstrumente, weshalb mancher Synthesizer bei Wahl der richtigen Modellierungsparameter „echte“ Musikinstrumente sehr realitätsnah nachahmen kann.
Im Bereich Filter legen Anwender – nomen est omen – diverse Filter für den erzeugten Ton fest, zum Beispiel Low-Pass-, High-Pass- und Band-Pass-Filter. Das geschieht mittels einer Cut-Off-Frequenz, die die Grenze für das Abschneiden der Frequenz festlegt. Ein Low-Pass-Filter definiert beispielsweise eine Cut-Off-Frequenz, ab der ein Synthesizer die höherfrequenten Klanganteile herausfiltert, sodass nur noch die niedrigeren Frequenzen den Filter passieren können.
Synthesizer stellen in der Regel einen LFO (Low Frequence Oscillator) zur Verfügung, mit dessen Hilfe sich die erzeugte Wellenfunktion modulieren lässt. Normalerweise sind niederfrequente Wellen für den Menschen nicht wahrnehmbar. Sobald Nutzer den LFO allerdings dafür einsetzen, um eine andere (hörbare) Welle zu modulieren, verleiht er dem erzeugten Ton eine auch im menschlichen Ohr wahrnehmbare, spezielle Charakteristik. Mittels der Frequenz des LFO lässt sich so die Intensität der modulierten Welle festlegen, mit dessen Amplitude die Stärke des wahrnehmbaren Modulationseffekts. Mit einem LFO ist es beispielsweise möglich, Tremoloeffekte zu erzeugen.
Danach kommt der EG (Envelope Generator) zum Einsatz, der eine ADSR-Amplitudenhüllkurve definiert. Die einzelnen Buchstaben stehen für die Parameter Attack (Zeit bis der Ton sein Maximum erreicht), Decay (Zeit bis der Ton auf ein geringeres Plateau fällt), Sustain (Tonhöhe nach dem Decay) und Release (Zeit bis der Ton zu guter letzt wieder auf die Amplitude 0 fällt).
Zusätzlich ermöglichen Synthesizer das Anwenden diverser Effekte auf den Klang, etwa Reverb und Delay.
Ein Arpeggiator sorgt bei einem anhaltenden Tastendruck dafür, dass nicht nur ein einziger Ton sondern sequenziell die Töne eines Akkords abgespielt werden. Dabei lässt sich zum Beispiel festlegen, welche Oktave der Synthesizer abspielt, welchen Akkordtyp er dafür nutzt, wie lange jeder Ton anhält, wie lange die Pause zwischen Tönen dauern soll, und vieles mehr.
Wer glaubt, ein monophoner Synthesizer könne automatisch nur einen VCO besitzen, der liegt falsch. In einem monophonen Synthesizer können mehrere VCOs für schwebende Klänge sorgen. Polyphone Synthesizer besitzen hingegen immer mehrere VCOs, mit denen sich verschiedene Tonhöhen und deshalb auch Akkorde spielen lassen. Sie integrieren einen Mixer, mit dessen Hilfe der Musiker bestimmt, aus welchen Anteilen der diversen VCOs der resultierende Klang sich zusammensetzt. Das ist notwendig, weil etwa eine Sägezahnwelle durchsetzungsfähiger ist als eine Sinuswelle. In diesem Fall reicht von ersterem Signal oft ein kleinerer Anteil als vom zweiten Signal.
Das Schaltbild des weiter unten besprochenen monophonen Korg NTS-1 enthält alle genannten Komponenten: Oscillator (VCO), Filter, Envelope Generator, Modulator (LFO) sowie die Effekte Delay und Reverb. Durch Schalter (->Route) lassen sich auf Wunsch ein, zwei oder drei der letztgenannten Bausteine umgehen. Zusätzlich gibt es einen Eingang, um den Synthesizer von außen anzusteuern (etwa über ein Midi-Keyboard, Effektgeräte, oder andere Synthesizer) sowie Ausgänge für Kopfhörer beziehungsweise Lautsprecher oder andere nachgeschaltete Geräte (zum Beispiel Recorder, Sampler, Mixer). Mittels eines Arpeggiators lassen sich gemäß eingestellten Akkorden Sequenzen von so erzeugten Klängen abspielen.
Die Schaltung des NTS-1 zeigt die vorgebenene Reinhenfolge seiner Klangkomponenten.
In den meisten Synthesizern ist die dargestellte Signalkette mehr oder weniger fest integriert. Speziell modulare Synthesizer bieten dagegen die Möglichkeit, einzelne Komponenten beispielsweise über Patchkabel miteinander zu verbinden, um auf diese Weise beliebige Signalketten zu konfigurieren. Besonders die früheren Synthesizer waren an der verwirrenden Vielzahl ihrer Patchkabel zu erkennen. In einem YouTube Video [1] aus dem Jahr 1970 demonstriert Wendy Carlos dieses Vorgehen. Sie war Mitarbeiterin des Synthesizer-Pioniers Robert Moog und erlangte 1968 als Künstlerin mit dem Album “Switched-on Bach” Berühmtheit, auf dem – wie sollte es anders sein – ein Moog-Synthesizer zum Einsatz kam.
Insgesamt stellt ein Synthesizer also sehr viele Stellschrauben zur Verfügung, mit denen sich gefühlt unendlich viele Sound-Landschaften gestalten lassen. Jeder Synthesizer verfügt über spezielle Hardwareeigenschaften, die das Klangbild mitbestimmen. So besitzen Synthesizer von Moog einen sehr charakteristischen “fetten” Klang.
Es gibt auch Synthesizer, die andere Verfahren nutzen, etwas Wavelists und Waveforms wie der ASM HydraSynth. Deren Potenzial ist wesentlich größer, dafür die Umsetzung von Klangideen meistens aufwendiger. Auf diese alternativen Konzepte geht der vorliegende Artikel aus Platzgründen nicht ein.
Do it yourself
Für den Preis und die Mächtigkeit eines Synthesizers gibt es scheinbar keine Grenze nach oben. Das gilt aber nicht für den Geldbeutel und die Wünsche von uns Normalsterblichen. Zum Glück geht es auch sehr günstig und minimalistisch. Der hybride monophone Korg NTS-1 richtet sich zum einen an diejenigen, die Erfahrung mit einem Synthesizer erwerben wollen, und zum anderen an erfahrene Zeitgenossen, die das Gerät als zusätzliche Möglichkeit betrachten, eigene Soundquellen aufzupeppen. Für einen Straßenpreis von 99 Euro können Interessenten den Bausatz erwerben, der neben dem Kurzmanual auch einen QR Code enthält. Letzterer verweist auf eine Korg-Webseite mit der visuellen Bauanleitung für den NTS-1 [2], wobei der Begriff “Bausatz” auf einige abschreckend wirken könnte. Genau genommen, besteht das Zusammenbauen in diesem Fall nicht aus Löten, sondern im wesentlichen aus dem Zusammenstecken zweier Platinen und dem Zusammenschrauben des Gehäuses.
Zu Beginn verschafft sich der angehende Synthesizer-Besitzer einen Überblick über die Einzelteile.
Das “Zerbrechen” der großen Platte in ihre Einzelteile (Platinen) anhand der perforierten Schnittstellen, ist dabei noch das kritischste Manöver. Genau genommen, ist das Zusammenbauen selbst für Zeitgenossen mit zwei linken Händen keine echte Herausforderung. Die ganze Montage ist deshalb in gut einer halben Stunde erledigt.
Sobald der NTS-1 über ein Micro-USB-Kabel zum ersten Mal Strom erhält, fährt das Gerät hoch, und gibt durch das Aufflackern diverser LEDs und Texten in der Anzeige ein erstes Lebenszeichen von sich. Wer über die 3,5mm-Klinkenbuchse an der Gehäusefront einen Kopfhörer anschließt, kann sofort mit dem Experimentieren anfangen. Das Gerät integriert aber auch einen eingebauten Lautsprecher mit geringer Leistung als Nice-to-have-Feature. Die aufgeklebte Miniklaviatur dient der Bedienung. Das ist zwar pragmatisch, aber nicht besonders bequem. Besitzer eines Midi-Keyboards können dieses per Midi-Kabel mit dem Midi-in-Eingang des NTS-1 verbinden (Typ: TRS-A 3,5mm-Klinkenbuchse), was die Bedienung spürbar erleichtert. Über den Audio-in-Eingang lassen sich eigene Tonquellen anschließen. Zwei weitere Buchsen Sync-In/-Out helfen bei der Synchronisation mit und über andere Geräte.
Nach einer halben Stunde Zusammenbauen ist der Synthesizer einsatzbereit.
Ein paar Proben gefällig? Als Appetithäppchen hat Korg ein paar Soundbeispiele auf der Soundcloud [3] veröffentlicht (Suchstring: “Korg NTS-1”). Dort lässt sich ein erster Eindruck von den vielfältigen musikalischen Möglichkeiten des Miniatur-Synthesizers gewinnen.
Dass der Synthesizer nicht als Spielzeug konzipiert ist, liegt auf der Hand, zumal er dieselben Komponenten verwendet, die auch bei seinen “ausgewachsenen” Brüdern Korg Minilogue XD und Korg Prologue zum Einsatz kommen. Der Autor als Besitzer eines Korg Minilogue und eines Minilogue XD kann das aus eigener Erfahrung bestätigen.
Programmierschnittstelle
Der NTS-1 ist deshalb auch kompatibel mit dem logue-SDK der Synthesizerproduktfamilie bestehend aus Korg Minilogue, Korg Monologue und eben auch Korg NTS-1. Die zugehörigen Dateien befinden sich auf einem Github-Repository [4]. Als Programmiersprache liegt C++ zugrunde. Diverse Hobbyisten und Profis haben damit bereits zum Teil sehr ausgefeilte eigene Effekte und Oszillatoren entwickelt. Eine Sammlung von freien Oszillatoren ist beispielsweise über die Webseite [5] verfügbar. Bei einer Websuche finden sich aber noch wesentlich mehr Effekte und Oszillatoren sowie YouTube-Videos zu dem Thema.
Wer keine Lust hat, das SDK programmatisch zu nutzen, kann stattdessen auf Windows oder macOS die Software NTS-1 digital Librarian [6]installieren, die das bequeme Laden und Verwalten von vorgefertigten Oszillatoren und Effekten über eine grafische Oberfläche unterstützt ). Damit lassen sich allerlei mächtige Funktionalitäten auf das Gerät laden.
Wer noch mehr Futter für den NTS-1 braucht, findet bei Hammond Eggs Music [7] passende logue-Plug-ins für alle Korg-Produkte aus der logue-Familie (NTS-1, Prologue und Minilogue XD).
Die spartanische GUI des NTS-1 digital Librarian.
Übrigens: Momo Müller bietet für 6,90€ einen interaktiven Editor [8] für den NTS-1 sowohl als Standalone-Programm als auch als VST-Plug-in an. Damit lässt sich der Synthesizer problemlos in eine DAW (Digital Audio Workstation) der Wahl integrieren.
Korg NTS-1 Editor und Soundbank von Momo Müller.
Der spanischen Entwickler Oscar RC stellt einen kostenlosen Webeditor für den NTS-1 zur Verfügung, der als PWA (Progressive Web Application) sogar offline funktioniert. Die Quellen dazu gibt es auf GitHub [9].
Der kostenlose Webeditor des spanischen Entwicklers Oscar RC.
Hardwareanbauten
Sogar das Erstellen einer eigenen Frontplatte für den NTS-1 ist denkbar. So findet sich auf der Webseite [10] eine alternative Frontplatte für den NTS-1, die sich über Arduino-Shields erweitern lässt. Auf der genannten Webseite gibt es noch weitere Custom Front Panels und den Verweis auf einen ausführlichen Arduino-Sketch mit einem Sequencer-Template. Ein zusätzliches YouTube-Video [11] erläutert den Austausch der normalen Frontplatte mit der gerade beschriebenen alternativen Frontplatte.
Fazit
Synthesizer sind heute nicht mehr von professionellen Musikproduktionen wegzudenken. Das Arbeiten mit ihnen macht nicht nur Musikenthusiasten sehr viel Spaß. Wer wissen möchte, wie ein Synthesizer intern funktioniert, erlebt mit Bausätzen wie dem Korg NTS-1 zwar keine Erleuchtung, aber zumindest interessante Einblicke, gerade weil sie minimalistisch gehalten sind. Zur Hilfestellung gibt es auf YouTube zahlreiche informative Videos nicht nur allgemein über Synthesizer, sondern auch speziell über den NTS-1.
Apropos YouTube. Wer noch mehr über den NTS-1 erfahren will. Unter dem Link [12] finden sich Dutzende Videos zu diesem Thema.
Ohnehin ist es spannend, dass es um den NTS-1 inzwischen eine große Community gibt. Nicht schlecht für einen preisgünstigen DiY-Synth. Natürlich lässt der Name des Geräts vermuten, dass es irgendwann auch einen NTS-2 geben könnte. Einige NTS-1-Liebhaber scharren deshalb schon mit ihren Hufen.
Wer den Bausatz erwerben möchte, besucht am besten die Webseiten großer Fachgeschäfte. Für den vorliegenden Artikel hat der Autor sein Exemplar bei Thomann [13] erworben.
URL dieses Artikels: https://www.heise.de/-6658911
Warum "zukunftssichere" Architekturen gefährlich sind
Von heise online — 29. März 2022 um 12:46
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Softwarearchitektur eines IT-Systems umfasst zwei Bereiche: Die Technologien zur Umsetzung und die Strukturierung des Systems in einzelne Module. Geht es um die Zukunftssicherheit von Architekturen, muss man beide Bereiche betrachten.
Struktur
Eine grobgranulare Struktur eines Systems ist notwendig, damit Menschen das System verstehen und ändern können. Softwaresysteme werden im Team entwickelt. Das führt zu einem Problem: Kein Mensch kann die Arbeit aller Menschen aus dem Team im Detail verstehen. Eine Strukturierung des Systems in Module ermöglicht ein Verständnis auf einer abstrakten Ebene - der Ebene der Module und nicht auf der Ebene einzelner Codezeilen.
Die architekturelle Struktur sollte die Module des Systems so anordnen, dass Funktionalitäten leicht zu ändern und zu verstehen sind. Also hängt die Struktur von den Funktionalitäten und damit von den Anforderungen ab. Das zentrale Problem bei der Softwareentwicklung ist, dass sich Anforderungen ändern – nicht nur weil Kunden neue Anforderungen stellen, sondern auch, weil beim Durchdenken oder bei der Anwendung des Systems Anforderungen klarer werden, sich neue Möglichkeiten offenbaren oder Inkonsistenzen auftauchen und beseitigt werden müssen. Teams, Kundinnen und Anwender lernen ständig mehr über das System und die zu entwickelnde Funktionalität. Dieses neue Wissen zu ignorieren,wäre absurd. Daher ergeben sich zwangsläufig Änderungen.
Einige Änderungen an den Anforderungen sind so signifikant, dass die Strukturierung des Systems und damit die Architektur angepasst werden muss. Ob das System zukunftssicher ist, entzieht sich also prinzipiell unserer Kenntnis, weil wir die Zukunft und die neuen Anforderungen nicht absehen können. Vielleicht passt die Architektur gut zu den neuen Anforderungen, vielleicht sind aber auch größere Änderungen notwendig.
Nur Absehbare Änderungen einbeziehen
Aber nicht alle neuen Anforderungen sind vollkommen überraschend. Natürlich ist es sinnvoll, absehbare Änderungen in den Entwurf der Architektur einzubeziehen. Wenn die Änderungen dann doch nicht erfolgen, ist die Architektur an einigen Stellen unnötig flexibel und daher möglicherweise an einigen Stellen zu kompliziert. Das ist aber ein weiterer Trade-off in der Architektur. Soll das System auf absehbare Änderungen vorbereitet werden oder nicht? Über solche Fragen nachzudenken und sie individuell zu entscheiden, ist sicher besser, als sie blind mit "You Ain't Gonna Need It" (YAGNI, Du wirst es nicht brauchen) zu beantworten. Dieses Motto stammt aus dem Extreme-Programming-Umfeld der Jahrtausendwende. Es diente dazu, sich gegen übermäßig generische Lösungen abzusetzen. Wenn man nämlich ein System so entwickelt, dass es auf alle denkbaren Änderungen vorbereitet ist, wird es übermäßig komplex. Daher sollte die Architektur nur absehbare Änderungen in Erwägung ziehen und diese auch nur dann in den Architektur einfließen lassen, wenn die Vorteile klar überwiegen.
Zukunftsfähigkeit = einfach verständlich
Dennoch kann man in der Strukturierung eine gewissen Zukunftsfähigkeit des Systems erreichen. Wenn die Strukturierung das Verständnis nicht erleichtert oder wenn Module nicht lose gekoppelt sind und Änderungen dadurch immer größere Teile des System betreffen, dann ist das System schon jetzt nicht einfach wartbar. Das wird sich in Zukunft nicht verbessern.
Wenn zentrale Konzepte der Fachdomäne gar nicht im System abgebildet sind oder fachliche Konzepte generell im System schlecht repräsentiert sind, ist es schwierig die Abbildung der Fachlichkeit auf das System zu verstehen. Verständnis ist aber die Voraussetzung für jede Änderung.
Also kann man die Struktur des Systems möglichst eng an der Fachlichkeit ausrichten und so zukunftsfähig gestalten. Wenn die fachlichen Konzept klar und verständlich umgesetzt sind, kann man sie auch einfach ändern und auf zukünftige Anforderungen anpassen. Über die fachlichen Konzepte hinaus eingebaute Flexibilität schadet dabei mehr als sie hilft: Sie ist meistens an den falschen Stellen und verschlechtert damit die Verständlichkeit. Man kann eben zukünftige Änderungen nicht vorweg erahnen und einfach implementierbar machen.
Technologie
Neben der Struktur ist auch die Technologieauswahl ein wichtiger Teil der Architektur. Softwareentwicklung unterliegt einem ständigen Technologiewandel. Man kann einem Technologie-Stack dennoch bescheinigen, dass er mehr oder weniger modern ist. Diese Aussage weist schon auf mangelnde Zukunftssicherheit hin: Was heute modern ist, ist morgen veraltet. “Modern” ist zunächst ein relativ inhaltsleerer Begriff: Was nützt es, wenn eine Technologie erst einige Jahre alt ist?
Die Modernität von Technologien darf kein Selbstzweck sein: Schließlich sollen Softwarearchitekturen Geschäftsprobleme lösen – und dazu ist ein möglichst moderner Technologie-Stack nicht zwingend notwendig. Aufwand, der in die Modernisierung von Technologien und das Erlernen neuer Ansätze fließt, sollte vielleicht besser in Aktivitäten fließen, die Geschäftswert erzeugen. Aber irgendwann sind Technologien so alt, dass sie nicht mehr weiter gepflegt werden. Spätestens wenn dann Sicherheitsupdates ausbleiben, muss man aktualisieren oder umsteigen. Sonst kann ein Sicherheitsproblem dazu führen, dass das System nicht mehr nutzbar ist oder gar erheblichen Schaden anrichtet. In beiden Fällen erzeugt das System keinen Geschäftswert mehr, sondern im Extremfall einen Geschäftsverlust. Wenn irgendwann die Technologien so alt sind, dass sich niemand mehr damit beschäftigen will, nimmt der Druck für eine Migration weiter zu.
Es kann natürlich Technologien geben, die scheinbar zukunftssicher sind. Die Programmiersprache Java beispielsweise gibt es seit über 25 Jahren. Aber auch hier gilt: Alte Java-Versionen bekommen keine Sicherheitsupdates mehr. Und Java-Code aus dem letzten Jahrhundert sieht wegen neuer Sprach-Features anders aus als aktueller Code. Schließlich gibt es ganz andere Frameworks oder zumindest neue Versionen der Frameworks. Selbst eine Technologie, die lange existiert, ist also einem Wandel unterworfen und muss ständig aktualisiert werden.
Anders gesagt: Man kommt nicht darum herum, neue Technologien einzusetzen. Der Wunsch nach einer Zukunftssicherheit ist nicht realisierbar.
Container
Container können die Zukunftssicherheit erhöhen: Jeder Container enthält ein eigenes Dateisystem und ist von anderen Containern weitgehend isoliert. Aus Sicht der Software wirkt es fast so, als wäre jeder Container ein getrennter Computer mit einem eigenen Dateisystem, einer eigener Netzwerkschnittstelle usw. Daher können in jedem Container eine eigene Programmiersprache und eigene Frameworks eingesetzt werden. Wenn man beispielsweise mit Microservices die Teile des Systems auf mehrere Container verteilt, kann ein Update auf eine neue Technologie zunächst in einem Container und dann schrittweise in anderen Containern umgesetzt werden. Das ist risikoärmer und macht die Architektur zukunftssicherer, weil die Einführung neuer Technologien einfacher wird.
Container-Technologien sind aber auch irgendwann erfunden worden: Kubernetes gibt es seit 2014, Docker seit 2013. Bis die Technologien im Mainstream angekommen sind, hat es dann noch einige Jahre gedauert. Um sie zu nutzen, muss man ältere Projekte ändern. Diese Innovationen sind nicht vorhersehbar. 2012 kann kein Architektur-Review vorhergesehen haben, dass ein Projekt nicht zukunftssicher ist, weil es keine Container nutzt.
Und eines ist auch bei Containern sicher: Es wird eine Zeit geben, in der man die Nase rümpft, wenn jemand noch Container nutzt, weil es dann eine viel bessere, neue Technologie geben wird. Hinzu kommt: In einem Frontend mehrere JavaScript-Frameworks gemeinsam zu nutzen bleibt eine echte Herausforderung – aber die Geschwindigkeit, mit der neue JavaScript-Frameworks erscheinen, ist nach wie vor beeindruckend. Also sind diese Probleme gerade da schwer lösbar, wo neue Technologien noch mit einer viel größeren Geschwindigkeit erscheinen.
Man sollte sich also an den Gedanken gewöhnen, dass man im Moment an Lösungen arbeitet, die irgendwann technologisch veraltet sind. Und man kann das Problem höchstens abmildern, aber nicht lösen.
Also Zukunftssicherheit vermeiden!
Die Frage nach der Zukunftssicherheit kann sogar ein Hinweis auf ein Problem sein: Wenn eine Architektur zukunftssicher wäre, müsste man sie nicht korrigieren. Das ist aber wünschenswert. Wenn Korrekturen stattdessen als Schwäche einer Architektur interpretiert und daher möglichst wenige zum Ziel werden, kann ein Problem sein. Dann können Hinweise auf eigentlich notwendige Änderungen ignoriert werden, um keine Korrekturen an der Architektur vornehmen zu müssen. Wer will schon gerne eingestehen, dass die Architektur eben nicht zukunftssicher war? Durch das Unterdrücken der Änderungen erscheint die Architektur "zukunftssicher", aber in Wirklichkeit passt die Architektur zunehmend schlechter zum System. Dass Architekturen nicht rechtzeitig an Änderungen angepasst werden, ist vermutlich eine größere Quelle für schlechte Architekturen als Probleme mit dem ursprünglichen Entwurf. So führt der Wunsch nach einer zukunftssicheren Architektur zu einer schlechteren Architektur.
Aber diese Paradoxie muss nicht der einzige Grund für ausbleibende Änderungen an der Architektur sein. Eine Architektur zu ändern ist anstrengend: Schließlich hat man sich mit dem Entwurf viel Mühe gegeben und vielleicht wesentliche Konzepte sogar schon in Prototypen ausprobiert. Von diesen ganzen Mühen Abschied zu nehmen, kann schwer fallen, ist aber manchmal nötig. Und man sollte auch kein schlechtes Gewissen haben, weil die Architektur nun obsolet ist. Softwareentwicklung ist nur in Iterationen umsetzbar. Eine Iteration der Architektur trägt die nächste schon in sich. Dennoch muss man sich bei dem Entwurf der Architektur Mühe geben. Erst wenn man wirklich versucht, die Architektur zu entwerfen, werden sich die Optimierungspotentiale zeigen.
Wenn es notwendig ist, Architekturen ändern zu können, kann die Erstellung der Architektur keine Phase in einem Projekt sein, die irgendwann abgeschlossen ist. Schließlich muss die Architektur ständig an die sich ändernde Welt angepasst werden. Dazu sollte es einen Prozess geben. Wenn es nämlich keinen Prozess für Änderungen an der Architektur gibt, wird sie vermutlich nicht angepasst werden. Dann lassen sich die Funktionalitäten zunehmend schlechter umsetzen.
Fazit
Die Frage nach einem Architekturänderungsprozess ist also wichtiger als die Frage nach der Zukunftssicherheit der Architektur. Und Projekte, die auf diese Frage keine Antwort haben, setzen sich der Gefahr aus, in Zukunft Schwierigkeiten mit der Architektur zu haben.
tl;dr
Technologische Innovationen und neue Anforderungen machen Änderungen an der Architektur zwingend - sie kann nicht zukunftssicher sein. Lösung: Dieser Realität in die Augen sehen und Architekturen anpassen, wenn notwendig.
Vielen Dank an Gerrit Beine, Martin Eigenbrodt, Joachim Praetorius und Gernot Starke für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels: https://www.heise.de/-6655162
Links in diesem Artikel: [1] mailto:eberhard.wolff@gmail.com
Vor 30 Jahren: Overdrive – der 486SX wird erwachsen
Von Georg Schnurer — 24. Mai 2022 um 11:53
Vor 30 Jahren: Overdrive – der 486SX wird erwachsen
Test & Kaufberatung | Test
Georg Schnurer
Als neues Mitglied der x86-Familie soll Overdrive aus dem Aschenputtel 486SX eine Prinzessin machen. c’t hat im Labor untersucht, ob das gelingt.
Vor 30 Jahren: Dieser Beitrag stammt aus c't 6/1992
Der Reigen neuer Intel-Prozessoren nimmt kein Ende. Am 26. Mai wird ein weiteres Mitglied der x86-Familie offiziell in die Gesellschaft eingeführt. Overdrive heißt der Debütant. Wir hatten bereits vor der Premiere Gelegenheit, Intels jüngstem Sproß auf den Zahn zu fühlen.
Vor knapp einem Jahr stellte Intel als Reaktion auf AMDs 40-MHz-386 den i486SX vor. Die Parole der Marketing-Strategen hieß damals: „Vier ist mehr als Drei“. Die Praxis zeigte allerdings schnell, daß AMDs 40-MHz-386 schneller war als der mit 20 MHz getaktete Kontrahent - vierzig ist eben doch mehr als zwanzig. Inzwischen ist das 486-Kastrat nicht nur im begehrten Plastikgehäuse, sondern auch als 25-MHz-Version erhältlich und wartet so mit etwa der gleichen Leistung wie die AMD-CPU auf.
Gegen diese rein leistungorientierte Argumentation führte Intel das Schlagwort „Upgradability“ in die Diskusion ein. Der Performance-Upgrade-Sockel sollte dem 486SX-Anwender den Weg in die Zukunft offen halten. Bisher sah diese Zukunft allerdings eher wie eine Sackgasse aus: Das einzige real existierende Upgrade war der 487SX, der den SX auf den (Leistungs-)Stand des 25-MHz-DX hob, indem er den Coprozessor nachlieferte. Zu allem Überfluß kostete dieses Upgrade etwa genauso viel wie ein komplettes Motherboard mit dem schnelleren 486/33-Prozessor.
Neue Perspektiven soll jetzt der Overdrive 486SX schaffen. Er arbeitet - wie der bereits in c't 4/92 vorgestellte DX2 - intern mit doppelter Frequenz, hat allerdings ein anderes, dem Upgrade-Sockel angepaßtes Pinout. Außerdem trägt er einen Kühlkörper, der die 50-MHz-Version des Overdrive vor dem Hitzetod bewahren soll. Intern sind die beiden Prozessoren gleich.
c’t-Test mit Apfelmännchen
Entsprechend fielen auch unsere Testergebnisse aus. Alle Programme, die – wie das 3D-Studio – vorwiegend mit kleinen Schleifen arbeiten, profitieren besonders stark vom höheren internen Takt, da sie innerhalb des 8 KByte großen integrierten Cache ablaufen. Hier ergeben sich Steigerungsraten von bis zu 95 Prozent gegenüber dem 487SX. Je intensiver ein Programm auf I/O- oder Memory-Transfer angewiesen ist, um so stärker wirkt sich die langsamere externe Taktfrequenz aus.
Besonders deutlich zeigt sich das beim Apfelmännchen. Die Version ohne Grafikausgabe läuft doppelt so schnell wie auf dem 487SX. Bei der anderen Version bremst die Grafikausgabe, die Steigerungsrate liegt nur noch bei 64 Prozent. Noch deutlicher sinkt die Performance beim AutoCAD-11-Benchmark. Dieser arbeitet intensiv mit Grafikkarte und Hauptspeicher, so daß der „Over“getriebene Rechner nur noch 59 Prozent schneller als der i487SX ist.
Technisch gesehen ist der Overdrive also auf jeden Fall das bessere Upgrade für den 486SX. Er bietet – im Gegensatz zum i487SX – einen echten Performance-Gewinn gegenüber dem 486. Ob der SX-Anwender das allerdings auch so sieht, hängt von Intels Preispolitik ab. Wenn sich der Preis des Overdrive etwa in der Größenordnung des i487SX einpendelt, hat es sich für den Anwender sicher gelohnt, auf das SX-Pferd zu setzen. Andernfalls bewahrheitet sich allerdings unser bereits bei Einführung des SX geäußerter Verdacht eines Schildbürgerstreichs auf Kosten der Anwender.
Es bleibt zu hoffen, daß Intel dem SX dieses Schicksal erspart, zumal sich die preisliche Positionierung des Overdrive als Nagelprobe für weitere Projekte dieser Art erweisen könnte. Nur wenn der Anwender für den Upgrade-Prozessor deutlich weniger investieren muß als für ein neues Board der gleichen Prozessorklasse, geht die Rechnung auf.
Upgrade-Visionen
Das nächste Upgrade-Projekt hat Intel bereits auf leisen Sohlen mit dem DX2 begonnen. Bei genauerem Hinsehen stellt man fest, daß dieser Chip ein vom normalen 486DX abweichendes Pinout hat. Fünf Pins sind hinzugekommen: Vier dienen - wie schon beim 50-MHz-486 - als Testpins für den Boundary Scan (TCK, TDI, TDO und TMS), der fünfte ist neu. Mit diesem Upgrade Present Signal (UP) läßt sich der DX2 abschalten.
Wer sich bis ans Ende der Design-Empfehlungen für DX2-Systeme durchkämpft, entdeckt dort auch die Spezifikation des Upgrade-Sockels. Er besteht aus einer 240poligen PGA-Fassung, deren innere 169 Pins kompatibel zum 487SX/Overdrive-Sockel sind. Auf der neu hinzugekommenen äußeren Kontaktreihe befinden sich neben drei Orientierungs-Pins und Masse-Kontakten sieben mit RES 1 bis RES 7 bezeichnete zusätzliche Anschlüsse.
Intels Overdrive i486SX braucht einen Kühlköper, um in der 50-MHz-Version nicht den Hitzetod zu sterben.
Obwohl Intel keinerlei Informationen über diese neuen Signale preisgibt, erlaubt dieser Sockel doch schon einige Rückschlüsse auf den zu erwartenden neuen Prozessor - nennen wir ihn einmal 586-Overdrive. Wie der DX2 wird auch dieser Chip als Double-Clock-Prozessor arbeiten. Ein höheres Verhältnis zwischen internem und externem Takt erscheint mir aus heutiger Sicht wenig sinnvoll. Auch die Datenbusbreite wird - wie beim DX2 - zumindest extern bei 32 Bit bleiben. Intern ist eine Verbreiterung des Datenbus auf 64 Bit allerdings ohne weiteres möglich.
Der 586-Overdrive wird mit Sicherheit einen integrierten Cache besitzen. Es ist sehr wahrscheinlich, daß dieser deutlich größer als die bisher bei 486-Systemen üblichen 8 KByte wird. Die zusätzlichen Steuerleitungen legen darüber hinaus die Vermutung nahe, daß Intel auch an eine Modifikation der Cache-Strategie denkt. Der DX2 arbeitet wie alle 486er mit einem Write-Through-Cache. Moderne Motherboard-Designs ergänzen diesen meist durch einen externen Write-Buffer. Was liegt also näher, als einen solchen Buffer direkt in die neue CPU zu integrieren? Eine andere Möglichkeit bestünde darin, den integrierten Cache der Upgrade-CPU als Write-Back-System auszuführen.
Und der Anwender?
Intel will nach eigener Aussage in Zukunft für jede Prozessorgeneration einen Upgrade-Sockel spezifizieren. Dieser soll dem Anwender einen Umstieg auf die neue Prozessorgeneration auch ohne Boardwechsel ermöglichen und so die einmal getätigten Investitionen schützen. Intel hat es in der Hand, ob auch der Anwender etwas von den neuen Upgrade-Möglichkeiten hat. Nur ein attraktiver Preis für die Overdrive-CPUs wird zur Akzeptanz der neuen Strategie führen.
Eins ist auf jeden Fall klar: Boardhersteller werden freiwillig keinen Upgrade-Sockel vorsehen. Sie verdienen schließlich nichts daran, wenn ein Kunde in einen Overdrive investiert, statt sich ein neues Board zu kaufen. Nur wenn es gelingt, die Upgrade-Möglichkeit als Qualitätskriterium zu etablieren, werden Hersteller diese auch vorsehen. Die Schlüssel dazu halten der Marktführer und König Kunde in der Hand. Es täte dem Markt gut, wenn Intel durch eine attraktive Preispolitik seinen Teil dazu beitragen würde.
()
URL dieses Artikels: https://www.heise.de/-7103801
Warum "zukunftssichere" Architekturen gefährlich sind
Von heise online — 29. März 2022 um 12:46
Warum "zukunftssichere" Architekturen gefährlich sind
Continuous ArchitectureEberhard Wolff
Die Frage "Ist diese Software-Architektur zukunftssicher?" kann man eigentlich generell mit "nein" beantworten. Schlimmer noch: Die Frage zu stellen, kann schon auf ein falsches Verständnis von Architektur hinweisen.
Die Softwarearchitektur eines IT-Systems umfasst zwei Bereiche: Die Technologien zur Umsetzung und die Strukturierung des Systems in einzelne Module. Geht es um die Zukunftssicherheit von Architekturen, muss man beide Bereiche betrachten.
Struktur
Eine grobgranulare Struktur eines Systems ist notwendig, damit Menschen das System verstehen und ändern können. Softwaresysteme werden im Team entwickelt. Das führt zu einem Problem: Kein Mensch kann die Arbeit aller Menschen aus dem Team im Detail verstehen. Eine Strukturierung des Systems in Module ermöglicht ein Verständnis auf einer abstrakten Ebene - der Ebene der Module und nicht auf der Ebene einzelner Codezeilen.
Die architekturelle Struktur sollte die Module des Systems so anordnen, dass Funktionalitäten leicht zu ändern und zu verstehen sind. Also hängt die Struktur von den Funktionalitäten und damit von den Anforderungen ab. Das zentrale Problem bei der Softwareentwicklung ist, dass sich Anforderungen ändern – nicht nur weil Kunden neue Anforderungen stellen, sondern auch, weil beim Durchdenken oder bei der Anwendung des Systems Anforderungen klarer werden, sich neue Möglichkeiten offenbaren oder Inkonsistenzen auftauchen und beseitigt werden müssen. Teams, Kundinnen und Anwender lernen ständig mehr über das System und die zu entwickelnde Funktionalität. Dieses neue Wissen zu ignorieren,wäre absurd. Daher ergeben sich zwangsläufig Änderungen.
Einige Änderungen an den Anforderungen sind so signifikant, dass die Strukturierung des Systems und damit die Architektur angepasst werden muss. Ob das System zukunftssicher ist, entzieht sich also prinzipiell unserer Kenntnis, weil wir die Zukunft und die neuen Anforderungen nicht absehen können. Vielleicht passt die Architektur gut zu den neuen Anforderungen, vielleicht sind aber auch größere Änderungen notwendig.
Nur Absehbare Änderungen einbeziehen
Aber nicht alle neuen Anforderungen sind vollkommen überraschend. Natürlich ist es sinnvoll, absehbare Änderungen in den Entwurf der Architektur einzubeziehen. Wenn die Änderungen dann doch nicht erfolgen, ist die Architektur an einigen Stellen unnötig flexibel und daher möglicherweise an einigen Stellen zu kompliziert. Das ist aber ein weiterer Trade-off in der Architektur. Soll das System auf absehbare Änderungen vorbereitet werden oder nicht? Über solche Fragen nachzudenken und sie individuell zu entscheiden, ist sicher besser, als sie blind mit "You Ain't Gonna Need It" (YAGNI, Du wirst es nicht brauchen) zu beantworten. Dieses Motto stammt aus dem Extreme-Programming-Umfeld der Jahrtausendwende. Es diente dazu, sich gegen übermäßig generische Lösungen abzusetzen. Wenn man nämlich ein System so entwickelt, dass es auf alle denkbaren Änderungen vorbereitet ist, wird es übermäßig komplex. Daher sollte die Architektur nur absehbare Änderungen in Erwägung ziehen und diese auch nur dann in den Architektur einfließen lassen, wenn die Vorteile klar überwiegen.
Zukunftsfähigkeit = einfach verständlich
Dennoch kann man in der Strukturierung eine gewissen Zukunftsfähigkeit des Systems erreichen. Wenn die Strukturierung das Verständnis nicht erleichtert oder wenn Module nicht lose gekoppelt sind und Änderungen dadurch immer größere Teile des System betreffen, dann ist das System schon jetzt nicht einfach wartbar. Das wird sich in Zukunft nicht verbessern.
Wenn zentrale Konzepte der Fachdomäne gar nicht im System abgebildet sind oder fachliche Konzepte generell im System schlecht repräsentiert sind, ist es schwierig die Abbildung der Fachlichkeit auf das System zu verstehen. Verständnis ist aber die Voraussetzung für jede Änderung.
Also kann man die Struktur des Systems möglichst eng an der Fachlichkeit ausrichten und so zukunftsfähig gestalten. Wenn die fachlichen Konzept klar und verständlich umgesetzt sind, kann man sie auch einfach ändern und auf zukünftige Anforderungen anpassen. Über die fachlichen Konzepte hinaus eingebaute Flexibilität schadet dabei mehr als sie hilft: Sie ist meistens an den falschen Stellen und verschlechtert damit die Verständlichkeit. Man kann eben zukünftige Änderungen nicht vorweg erahnen und einfach implementierbar machen.
Technologie
Neben der Struktur ist auch die Technologieauswahl ein wichtiger Teil der Architektur. Softwareentwicklung unterliegt einem ständigen Technologiewandel. Man kann einem Technologie-Stack dennoch bescheinigen, dass er mehr oder weniger modern ist. Diese Aussage weist schon auf mangelnde Zukunftssicherheit hin: Was heute modern ist, ist morgen veraltet. “Modern” ist zunächst ein relativ inhaltsleerer Begriff: Was nützt es, wenn eine Technologie erst einige Jahre alt ist?
Die Modernität von Technologien darf kein Selbstzweck sein: Schließlich sollen Softwarearchitekturen Geschäftsprobleme lösen – und dazu ist ein möglichst moderner Technologie-Stack nicht zwingend notwendig. Aufwand, der in die Modernisierung von Technologien und das Erlernen neuer Ansätze fließt, sollte vielleicht besser in Aktivitäten fließen, die Geschäftswert erzeugen. Aber irgendwann sind Technologien so alt, dass sie nicht mehr weiter gepflegt werden. Spätestens wenn dann Sicherheitsupdates ausbleiben, muss man aktualisieren oder umsteigen. Sonst kann ein Sicherheitsproblem dazu führen, dass das System nicht mehr nutzbar ist oder gar erheblichen Schaden anrichtet. In beiden Fällen erzeugt das System keinen Geschäftswert mehr, sondern im Extremfall einen Geschäftsverlust. Wenn irgendwann die Technologien so alt sind, dass sich niemand mehr damit beschäftigen will, nimmt der Druck für eine Migration weiter zu.
Es kann natürlich Technologien geben, die scheinbar zukunftssicher sind. Die Programmiersprache Java beispielsweise gibt es seit über 25 Jahren. Aber auch hier gilt: Alte Java-Versionen bekommen keine Sicherheitsupdates mehr. Und Java-Code aus dem letzten Jahrhundert sieht wegen neuer Sprach-Features anders aus als aktueller Code. Schließlich gibt es ganz andere Frameworks oder zumindest neue Versionen der Frameworks. Selbst eine Technologie, die lange existiert, ist also einem Wandel unterworfen und muss ständig aktualisiert werden.
Anders gesagt: Man kommt nicht darum herum, neue Technologien einzusetzen. Der Wunsch nach einer Zukunftssicherheit ist nicht realisierbar.
Container
Container können die Zukunftssicherheit erhöhen: Jeder Container enthält ein eigenes Dateisystem und ist von anderen Containern weitgehend isoliert. Aus Sicht der Software wirkt es fast so, als wäre jeder Container ein getrennter Computer mit einem eigenen Dateisystem, einer eigener Netzwerkschnittstelle usw. Daher können in jedem Container eine eigene Programmiersprache und eigene Frameworks eingesetzt werden. Wenn man beispielsweise mit Microservices die Teile des Systems auf mehrere Container verteilt, kann ein Update auf eine neue Technologie zunächst in einem Container und dann schrittweise in anderen Containern umgesetzt werden. Das ist risikoärmer und macht die Architektur zukunftssicherer, weil die Einführung neuer Technologien einfacher wird.
Container-Technologien sind aber auch irgendwann erfunden worden: Kubernetes gibt es seit 2014, Docker seit 2013. Bis die Technologien im Mainstream angekommen sind, hat es dann noch einige Jahre gedauert. Um sie zu nutzen, muss man ältere Projekte ändern. Diese Innovationen sind nicht vorhersehbar. 2012 kann kein Architektur-Review vorhergesehen haben, dass ein Projekt nicht zukunftssicher ist, weil es keine Container nutzt.
Und eines ist auch bei Containern sicher: Es wird eine Zeit geben, in der man die Nase rümpft, wenn jemand noch Container nutzt, weil es dann eine viel bessere, neue Technologie geben wird. Hinzu kommt: In einem Frontend mehrere JavaScript-Frameworks gemeinsam zu nutzen bleibt eine echte Herausforderung – aber die Geschwindigkeit, mit der neue JavaScript-Frameworks erscheinen, ist nach wie vor beeindruckend. Also sind diese Probleme gerade da schwer lösbar, wo neue Technologien noch mit einer viel größeren Geschwindigkeit erscheinen.
Man sollte sich also an den Gedanken gewöhnen, dass man im Moment an Lösungen arbeitet, die irgendwann technologisch veraltet sind. Und man kann das Problem höchstens abmildern, aber nicht lösen.
Also Zukunftssicherheit vermeiden!
Die Frage nach der Zukunftssicherheit kann sogar ein Hinweis auf ein Problem sein: Wenn eine Architektur zukunftssicher wäre, müsste man sie nicht korrigieren. Das ist aber wünschenswert. Wenn Korrekturen stattdessen als Schwäche einer Architektur interpretiert und daher möglichst wenige zum Ziel werden, kann ein Problem sein. Dann können Hinweise auf eigentlich notwendige Änderungen ignoriert werden, um keine Korrekturen an der Architektur vornehmen zu müssen. Wer will schon gerne eingestehen, dass die Architektur eben nicht zukunftssicher war? Durch das Unterdrücken der Änderungen erscheint die Architektur "zukunftssicher", aber in Wirklichkeit passt die Architektur zunehmend schlechter zum System. Dass Architekturen nicht rechtzeitig an Änderungen angepasst werden, ist vermutlich eine größere Quelle für schlechte Architekturen als Probleme mit dem ursprünglichen Entwurf. So führt der Wunsch nach einer zukunftssicheren Architektur zu einer schlechteren Architektur.
Aber diese Paradoxie muss nicht der einzige Grund für ausbleibende Änderungen an der Architektur sein. Eine Architektur zu ändern ist anstrengend: Schließlich hat man sich mit dem Entwurf viel Mühe gegeben und vielleicht wesentliche Konzepte sogar schon in Prototypen ausprobiert. Von diesen ganzen Mühen Abschied zu nehmen, kann schwer fallen, ist aber manchmal nötig. Und man sollte auch kein schlechtes Gewissen haben, weil die Architektur nun obsolet ist. Softwareentwicklung ist nur in Iterationen umsetzbar. Eine Iteration der Architektur trägt die nächste schon in sich. Dennoch muss man sich bei dem Entwurf der Architektur Mühe geben. Erst wenn man wirklich versucht, die Architektur zu entwerfen, werden sich die Optimierungspotentiale zeigen.
Wenn es notwendig ist, Architekturen ändern zu können, kann die Erstellung der Architektur keine Phase in einem Projekt sein, die irgendwann abgeschlossen ist. Schließlich muss die Architektur ständig an die sich ändernde Welt angepasst werden. Dazu sollte es einen Prozess geben. Wenn es nämlich keinen Prozess für Änderungen an der Architektur gibt, wird sie vermutlich nicht angepasst werden. Dann lassen sich die Funktionalitäten zunehmend schlechter umsetzen.
Fazit
Die Frage nach einem Architekturänderungsprozess ist also wichtiger als die Frage nach der Zukunftssicherheit der Architektur. Und Projekte, die auf diese Frage keine Antwort haben, setzen sich der Gefahr aus, in Zukunft Schwierigkeiten mit der Architektur zu haben.
tl;dr
Technologische Innovationen und neue Anforderungen machen Änderungen an der Architektur zwingend - sie kann nicht zukunftssicher sein. Lösung: Dieser Realität in die Augen sehen und Architekturen anpassen, wenn notwendig.
Vielen Dank an Gerrit Beine, Martin Eigenbrodt, Joachim Praetorius und Gernot Starke für die Kommentare zu einer früheren Version des Artikels.
URL dieses Artikels: https://www.heise.de/-6655162
Auf den Arm nehmen - Tinkerkit Braccio Arduino Robotic Arm
Von heise online — 10. März 2022 um 12:04
Auf den Arm nehmen - Tinkerkit Braccio Arduino Robotic Arm
Der Pragmatische Architekt
Michael Stal
Der Roboterarm Tinkerkit Braccio Robot verspricht einen kostengünstigen Einstieg in die Robotik. Lohnt sich der Kauf?
Wer sich für Elektronik und Mechanik interessiert, dürfte irgendwann auf Mechatronik und Robotik stoßen, speziell auf interessante Themen wie ferngesteuerte Fahrzeuge oder Roboterarme. Industriell nutzbare Roboterarme a la Kuka und Fanuc sind auch im Kleinformat nahezu unerschwinglich. Was also tun, wenn der Wunsch nach einem einfachen Einstieg in diese Technologie auf den Nägeln brennt? Tut es zur Not auch ein preisgünstiger Baukasten?
Tinkerkit Braccio Robot
In diesem Blog kam das Arduino-Ökosystem schon in zahlreichen Postings zur Sprache. Viele experimentelle Robotikmodelle basieren auf Arduino-Boards. Auf dem Arduino-eigenen Shop [1] und auch woanders gibt es entsprechende Kits, darunter den Tinkerkit Braccio Arduino Robotic Arm für rund 199 € (ohne MwSt). Der Name des Roboterarms ist übrigens mit Bedacht gewählt, weil das italienische “Braccio” dem deutschen Wort “Arm” entspricht.
Der Braccio-Roboterarm besitzt sechs Bewegungsachsen und firmiert daher als 6DOF-Roboterarm (DOF = Degrees of Freedom). Einfache Daumenregel: Jeder Motor fügt in der Regel einen Freiheitgrad hinzu. Natürlich ist für diesen Preis kein Roboter zu erwarten, der viele Kilogramm in höchster Geschwindigkeit, mit vorgebener Trajektorie, und mit großer Präzision bewegen kann - die aktuelle Version kommt auf etwa 150 g Maximallast bei ausgestrecktem Arm und sonst auf bis zu 400 g.
Aber taugt ein solches Kit zumindest für den Einstieg in die Thematik?
Um diese Frage zu beantworten, habe ich den Braccio-Roboterarm von Arduino erworben. Zusätzlich benutzte ich ein Arduino-Board aus eigenen Bestand, das dem Roboterarm über das beigefügte Braccio-Shield Befehle gibt. Dieses Board sollte den Formfaktor eines Arduino Uno, Leonardo oder Mega besitzen und 5V-Logik implementieren, um das Braccio-Shield huckepack aufnehmen und steuern zu können - das Shield verbindet die verschiedenen Servos mit dem Arduino.
Auf den einschlägigen Verkaufsplattformen kosten Arduino-kompatible Boards ab etwa 9 Euro (Beispielsbezugsquelle [3]). Alternativ lässt sich auch das Braccio Bundle Kit erwerben, in dem für rund 219 € bereits ein Original Arduino Uno Board enthalten ist.
Dass der Baukasten aus elektronischen und mechanischen Einzelteilen sowie Gehäuseteilen besteht (siehe Abb. 1) und von seinem neuen Besitzer erst mal Bastelarbeit abverlangt, ist kein Bug sondern ein Feature. Nur dadurch lassen sich wertvolle Einblicke in die Bestandteile eines zugegebenermaßen sehr einfachen Roboterarms gewinnen.
https://amzn.to/35jdWk8
Zudem bieten Enthusiasten ergänzende Komponenten für den Braccio auf 3D-Modell-Plattformen wie Thingiverse an.
Zusammenbau
Wer das Löten elektronischer Bauteile scheut, kann übrigens aufatmen: Nach 21 Schritten und 63 Schrauben ist die vollständige Konstruktion geschafft, ganz ohne Löten. Enthalten im Kit sind sechs Servomotoren, zwei des Typs SR 311 und vier des Typs SR 431 mit höherem Drehmoment.
Für den Zusammenbau des Braccio ist das notwendige Werkzeug- ein Philips Schraubenzieher und ein Maulschlüssel -im Kit enthalten, zumindest theoretisch. Der normalerweise enthaltene kleine Maulschlüssel fehlte in meinem Kit. Wer sich vorab Details der Montage zu Gemüte führen möchte, findet die Bauanleitung zum Beispiel hier [4]. Alternativ existiert ein 17-minütiges YouTube-Video [5], das alle Aufbauschritte illustriert.Nicht zu vergessen die Braccio-Dokumentation auf dem Arduino Web [6].
In etwa zwei bis maximal drei Stunden Arbeit lässt sich der Braccio sorgfältig und gemütlich zusammenbauen, wofür sich zum Beispiel ein verregneter Sonntagnachmittag anbietet. Das Endergebnis ist in Abb. 2a und 2b zu sehen.
Das Werk ist nach 2 Stunden vollendet.
Zwei bis drei Stunden dauert das Zusammensetzen des Roboterarms. Zu sehen ist das voll verbundene Braccio-Shield.
Wenn einige Teile übrig bleiben, besteht kein Grund zur Panik. Im Kit sind ein paar Ersatzteile vorhanden, speziell für die Teile, die leicht verloren gehen könnten oder Verschleiß ausgesetzt sind.
Schneller, höher, weiter
Was ich als wenig optimal empfinde, ist die sehr leichte Basis des Braccio in Gestalt eines kleinen quadratischen Holzbrettchens. Diese Konstruktion macht den Braccio instabil, wodurch er zum Kippen neigt. Das Anschrauben des Arms auf eine Tischplatte dürfte nur für die wenigsten in Frage kommen. Als Gegenmaßnahme bietet es sich an, entweder ein größeres Holz- oder Aluminiumbrett oder eine verstärkte Basis mit integriertem Gewicht zu bauen. Für letztere Option gibt es auf Thingiverse ein entsprechendes Fundament zum Selbstdrucken [7]. In dieses Fundament lässt sich ein passendes Gewicht integrieren.
Wer aus dem Greifer eine besser zupackende, zangenförmige Hand machen möchte, findet auch hierzu ein passendes 3D-Modell [8]auf Thingiverse.
Hallo, Computer!
Für die nachfolgenden Beispiele habe ich einen Arduino Mega-Klone eingesetzt, da dieser mehr Schnittstellen besitzt, sollte man beziehungsweise frau den Braccio später durch eigene Zusatzkomponenten ergänzen wollen. Die bereits erwähnte Braccio-Dokumentation auf arduino.cc bietet hier einige Anregungen.
Entsprechende Arduino-Sketches funktionieren natürlich auch mit einem Arduino Uno oder Leonardo. Sitzt das Braccio-Shield erst mal auf dem auserwählten Arduino-Board, kann die Programmierung beginnen.
Dafür lassen sich diverse IDEs nutzen, darunter Visual Studio Code plus PlatformIO-Addin oder die gute alte Arduino IDE.
Apropos gut und alt: Empfehlenswert ist zwar der Einsatz der aktuellen und überarbeiteten Arduino IDE 2.0. Wer wie ich aber noch eine Version der “klassischen” Arduino IDE auf einem Computer (mit Linux, Windows oder macOS) installiert hat, kann auch diese nutzen.
Nach Start der Arduino-IDE führt der erste Schritt zur Bibliotheksverwaltung. Für die Suche nach der passenden Bibliothek genügt der Begriff “Braccio”, worauf besagte Bibliothek in der Trefferliste erscheint. Ein Klick auf Install genügt und schon installiert die IDE die Braccio-Bibliothek und, sofern noch nicht vorhanden, auch die benötigte Servo-Bibliothek als Abhängigkeit erstgenannter Bibliothek.
Installation der Braccio-Bibliothek über die Bibliotheksverwaltung.
Neben der Bibliothek stellt die Arduino-IDE auch die zusätzlich enthaltenen Programmbeispiele zur Verfügung. Insgesamt gibt es davon fünf. Empfehlenswert ist zuallererst die Ausführung des Sketches testBraccio90.
Nach Installation der Braccio-Bibliothek findet sich unter Datei | Beispiele der Eintrag Braccio mit all den dort bereitgestellten Beispielen.
Nach der Initialisierung des Roboterarms, worauf dieser eine Initialposition einnimmt, vollführt der Braccio zunächst einen höflichen Knicks, um abschließend mit nach oben ausgestrecktem Arm zu verweilen. Dadurch können Maker testen, ob sie den Braccio und insbesondere dessen Servos richtig zusammen geschraubt haben.
Der testBraccio90-Sketch endet - bei erfolgreichem Aufbau - in nach oben ausgestreckter Haltung.
Der Arduino-Sketch inkludiert zunächst die Header-Dateien für die Braccio- und die Servo-Bibliothek, um danach für alle Servos von base (Basis) bis gripper (Greifer) eine Variable zu definieren.
Die Methode Braccio.begin() initialisiert die Bibliothek und bewegt alle Servo-Motoren auf initiale Positionen. Die Basis dreht sich auf 90°, die Schulter auf 45°, der Ellbogen ebenso wie das vertikale Handgelenk auf 180°, das Handgelenk selbst rotiert auf 90°, der Greifer auf 10°. Für den Greifer bedeuten 10° eine geöffnete, 73° hingegen eine geschlossene Haltung.
void setup() { Braccio.begin(); }
In der Dauerschleife loop gibt es nur einen Befehl:Braccio.ServoMovement(delay, M1, M2, M3, M4, M5, M6);
Dieser bewegt die Servomotoren (M1 … M6) auf die angegebenen Winkel, wobei zwischen der abgeschlossenen Bewegung eines Servomotors bis zum Start des nächsten Servomotors eine Pause von delay (in Millisekunden!) einzuhalten ist:
Mehr als die öffentlichen Methoden begin() und ServoMovement() existieren in der Bibliothek nicht.
Darüber hinaus gibt es weitere Open-Source-Bibliotheken zur Ansteuerung des Braccio. So hat Lukas Severinghaus die Bibliothek BraccioV2 [9]entworfen, die zusätzliche Funktionalität bietet, sich aber auf die aktuelleren Braccio-Kits mit mindestens Version 4 des Braccio-Shield beschränkt. Zum Beispiel gibt es dort Routinen zur Kalibrierung der Gelenke (Min-, Max-, Mittelposition) und Funktionen für die relative Bewegung des Roboterarms.
Open Source Hardware
Der Braccio-Roboterarm gehört zu den Vertretern der Open Source Hardware. Seine CAD-Dateien stehen auf einer Webseite zum Herunterladen [10] zur Verfügung.Interessenten können daher selbst Hand anlegen, also etwa robustere Teile bauen, das Modell skalieren,leistungsstärkere Motoren integrieren, und einen eigenen Braccio de la casa entwerfen.
Auf den bekannten Seiten mit 3D-Druckmodellen lassen sich wie bereits erwähnt weitere Perlen aufspüren. Der bekannte YouTuber 3D Printing Professor hat einen Controller entworfen (siehe hier [11]), der die Bedienung des Braccio über zwei Mini-Joysticks ermöglicht. Die Mathematik für die Steuerung aller Mittelmotoren bezüglich der Y-Achse implementiert dabei ein Arduino Sketch.
Braccio Simulation
Will Stedden beschreibt auf seiner Webseite [12]eine Simulation des Bracciomit ROS MoveIt [13] und dem Physiksimulator Gazebo [14]. Der Quellcode hierzu findet sich auf GitHub [15]. Interessant in dem kleinen Artikel finde ich vor allem, dass Will Stedden auch auf Einschränkungen des Braccio eingeht, etwa „wie lässt sich der Braccio-Roboterarm genau auf eine Position x bewegen“, was sich durchaus als nichttrivial erweist.
Fazit
Das Braccio Tinkerkit bietet einen Roboterarm für Maker, dessen Aufbau und Programmierung eine ganze Menge Spaß macht. Damit lassen sich einige Grundlagen über solche Arme erlernen, speziell über die koordinierte Ansteuerung von (Servo-)Motoren per Microcontroller. Natürlich ersetzt ein solcher Baukasten nicht das Erlernen von mathematischen und physikalischen Grundlagen der Robotik. Spätestens, wenn Maker:innen einen Roboterarm mit herausfordernderen Eigenschaften entwickeln möchten, dessen Abläufe eine genaue vorherige Planung benötigen, bedarf es eines ingenieurmäßigen Vorgehens sowie leistungsstärkerer Materialien und Motoren. Aber dafür sind Roboterarme für wenige Hundert Euro auch nicht gedacht. Die gehören eher zumEdutainment und sind dementsprechend als Spielzeuge mit Lerncharakter zu betrachten.
Natürlich ist der Braccio nur ein Beispiel. Wer jetzt auf den Geschmack gekommen ist und sich für 3D Druck begeistert, findet auf Thingiverse komplette Projekte für Roboterarme zum NachdruckenbeziehungsweiseNachbauen, etwa:
Micro-Frontends sind Benutzeroberflächen, die sich aus kleinen isolierten Anwendungen zusammensetzen. Implementieren kann man sie zum Beispiel mit Web Components.
Es handelt sich um die Übertragung des Microservice-Konzepts aus dem Backendbereich auf das Frontend: Größere Anwendungen werden in kleinere, besser zu implementierende und zu wartende Unteranwendungen zerlegt. Entwickler können dabei die Sprachen und Frameworks wählen, die zu ihnen und dem konkreten Anwendungsfall passen. Web Components sind ein möglicher Ansatz zur Implementierung solcher Micro-Frontends.
Es gibt viele Möglichkeiten, Micro-Frontends zu bauen: Unter anderem können Inline Frames (IFrames) eingesetzt werden, in denen unterschiedliche Single-Page-Apps ausgeführt werden. Über jeweils zu implementierende Kommunikationsschichten können diese miteinander Daten austauschen. Die Module Federation in Webpack 5 erlaubt das Nachladen von fremdem Programmcode zur Laufzeit, um dasselbe Ziel zu erreichen – hier nicht in unterschiedlichen Frames, sondern in ein und demselben Browsingkontext. Ganz ähnlich verhält es sich mit Web Components, mit denen sich dieser Artikel beschäftigt.
Web Components: Das Komponentenmodell des Web
Web Components [1] sind das eingebaute Komponentenmodell des Web. Entwickler können dabei eigene HTML-Elemente definieren und deren Aussehen sowie Verhalten selbst steuern. Die Technologie ist noch verhältnismäßig neu, funktioniert aber in den vier Evergreen-Browsern Chrome, Edge, Firefox und Safari seit längerem.
Der Datenaustausch erfolgt über benutzerdefinierte DOM-Attribute bzw. -Eigenschaften sowie -Ereignisse, auf der Komponente können auch eigene JavaScript-Methoden definiert werden, das Theming der Komponenten ist dabei über CSS Custom Properties möglich.
Web Components lassen sich mit Plain JavaScript schreiben, es gibt jedoch auch Bibliotheken wie Lit, die das Verfassen solcher Elemente noch einmal deutlich vereinfachen. Weiterhin erlauben auch Frameworks wie Angular (Angular Elements) oder Stencil das Verfassen eigener Web Components. Entwickler können hier einfach einen passenden Unterbau aussuchen, die Komponenten lassen sich anschließend problemlos miteinander kombinieren.
Web Components werden zur Laufzeit durch den Verwender registriert, damit ist auch ein Nachladen beliebiger Komponenten während der Ausführung möglich. Es gilt jedoch zu bedenken , dass der hierfür erforderliche JavaScript-Code innerhalb des eigenen JS-Kontextes ausgeführt wird. Einmal geladen kann der fremde Code etwa den Local Storage oder auch Cookies auslesen, wenn sie für JavaScript sichtbar sind. Wenn dies vermieden werden soll, bieten sich die oben genannten IFrame-Ansätze an.
Paint in Ihrer Anwendung einbinden
Vor wenigen Monaten habe ich hier auf dem ÜberKreuz-Blog meinen webbasierten Remake von Microsoft Paint [2] vorgestellt. Es handelt sich dabei um eine Progressive Web App, die komplett alleinstehend betrieben werden kann. Die Anwendung ist zugleich jedoch eine Web Component und kann somit auch in beliebige andere Anwendungen eingebettet werden. Die Paint-Web-Component steht unter dem Paket @christianliebel/paint [3]auf npmjs.org zur Verfügung.
Die Paint-Web-Component schreibt den Dateinamen des Dokuments in einen Adobe-Spectrum-Button
Viele Softwarehersteller setzen Design Systems ein, die Steuerelemente in der eigenen Corporate Identity enthalten. Adobe hat sein Design System namens Spectrum mit Web Components realisiert und quelloffen zur Verfügung gestellt. Unter anderem kommen diese Komponenten beim jüngst eingeführten Photoshop Web [4] zum Einsatz. Zur einfachen Demonstration des Ansatzes wird der Titel des aktuell bearbeiteten Dokuments der Paint-App auf einen Spectrum-Button geschrieben:
Um zu wissen, welche benutzerdefinierten HTML-Elemente von Drittanbieterpaketen zur Verfügung gestellt werden, gibt es das sogenannte Custom Element Manifest. Es zählt alle Web Components mit den verfügbaren Attributen, Eigenschaften, Ereignissen und CSS-Variablen auf. Für manche Umgebungen gibt es auch Generatoren, um die Manifest-Datei automatisiert erstellen zu lassen.
{ "version": 2, "tags": [ { "name": "paint-app", "description": "An open-source, Web Components-based remake" + "of MS Paint using modern web capabilities.", "properties": [], "events": [ { "name": "titlechange", "description": "The titlechange event fires whenever" + "the document's title changes, for example, " + "when a document is saved with a new name," + "or a document was opened from the file system.", "type": "{ title: string }" } ], "slots": [], "cssProperties": [] } ] }
Grenzen und Probleme
Bei Micro-Frontends ergibt sich das Problem, dass eigentlich unabhängige Anwendungen integriert werden müssen. Eventuell gibt es Versionsabhängigkeiten zwischen den Einzelanwendungen, die erfüllt werden müssen. Ist das nicht möglich, funktioniert auch die Gesamtanwendung nicht. Komponentenmarktplätze wie npmjs.org haben sich dieser Problematik durch das Konzept der semantischen Versionierung genähert. Hier ergibt sich durch die Versionsnummer, ob bei einem Update Breaking Changes zu erwarten sind. Ein weiterer Ansatz besteht darin, Schnittstellen dauerhaft abwärtskompatibel zu gestalten. Die Win32-API oder die Web-Plattform sind gute Beispiele hierfür, allerdings bedarf es hierfür passender organisatorischen Strukturen, um dieses Ziel einzuhalten.
Speziell auf Web Components bezogen lassen sich Custom Elements derzeit nur genau einmal registrieren. Mehrere Komponentenversionen nebeneinander ließen sich also nur durch versionierte Komponentennamen (z.B. <my-button-2>) realisieren – ein Antipattern. Die spätere Neuregistrierung einer Web Component, etwa um zur Laufzeit geänderte Versionsabhängigkeiten zu erfüllen, ist nicht möglich. Abhilfe soll hier die Scoped Custom Element Registry [5] schaffen, die bei der Web Platform Incubator Community Group (WICG) vorgeschlagen wurde. Damit ist eine Komponentenregistrierung in untergeordneten Anwendungsscopes möglich. Ein Polyfill ist verfügbar, implementiert ist das Konzept bislang aber in keinem Browser.
Aufgrund der vielen Schnittgrenzen kann der Micro-Frontend-Ansatz schließlich selbst zum Problem werden: Typische Anforderungen, die den Einsatz von Micro-Frontends bedingen, sind hochmodulare Umgebungen mit mehreren Zielanwendungen oder Apps, die von mehreren organisatorisch getrennten Teams mit unterschiedlichen Vorerfahrungen zeitgleich entwickelt werden sollen. Liegt das nicht vor, sind Entwickler mit einem durch passende Architekturmittel gut strukturierten Monolithen eventuell besser aufgehoben.
Fazit
Wenn wirklich ein Micro-Frontend-Ansatz gebraucht wird, stellen Web Components eine gute Option zur Umsetzung dar. Da sie im selben JavaScript-Kontext ausgeführt werden, sollten nur eigene Komponenten verwendet werden oder nur solche, deren Hersteller vertraut wird. Dann können unterschiedliche Entwicklerteams gleichzeitig unter Zuhilfenahme unterschiedlichster Frameworks eine oder mehrere Anwendungen entwickeln.
URL dieses Artikels: https://www.heise.de/-6328145
Links in diesem Artikel: [1] https://www.heise.de/developer/artikel/Single-Page-Applications-ohne-Framework-Web-Components-als-Ersatz-fuer-React-Co-4850959.html [2] https://www.heise.de/developer/artikel/paint-js-org-MS-Paint-Remake-als-PWA-mit-Web-Components-und-modernen-Web-Capabilities-6058723.html [3] https://www.npmjs.com/package/@christianliebel/paint [4] https://www.heise.de/developer/artikel/Analyse-Photoshop-jetzt-als-Webanwendung-verfuegbar-6229321.html [5] https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
Im Dezember 2021 sorgte die Sicherheitslücke Log4Shell in dem Logging-Framework Log4j für Java für Aufregung, die vom BSI als kritisch eingeschätzt und auf Warnstufe Rot eingestuft wurde. Nachdem sich der Staub inzwischen gelegt hat, ist es an der Zeit für einen Review: Was lässt sich aus alldem lernen?
Log4j ist praktisch der De-Facto-Standard für Logging in Java. Dennoch handelt es sich bei dem Framework lediglich um ein Werkzeug für Logging, ein Thema, das eher unspektakulär und wenig aufregend klingt. Doch trotzdem (oder vielleicht auch gerade deshalb) verbarg sich in dem Modul eine eklatante Sicherheitslücke, deren Details im CVE 2021-44228 näher beschrieben werden.
Über die technischen Details der Sicherheitslücke, das Angriffsszenario und Strategien zum Schließen der Lücke wurde in den vergangenen Wochen sehr viel berichtet, weshalb es wenig sinnvoll ist, das alles noch einmal zu wiederholen.
Doch es stellen sich darüber hinaus Fragen, die bislang nur wenig diskutiert worden sind, die aber mehr Aufmerksamkeit verdient hätten. Dazu zählt zum einen, welche Ursachen und Gründe es für dieses Problem gibt, wie die ganze Situation überhaupt entstehen konnte, was sie begünstigt hat. Das ist die Frage nach dem "warum". Zum anderen stellt sich die Frage, was sich daraus lernen lässt: Wie lässt sich ein derartiges Fiasko zukünftig verhindern?
Kulturelle und gesellschaftliche Gründe
Dafür gibt es technische, vor allem aber auch kulturelle und gesellschaftliche Gründe. Der kulturelle Grund ist, dass Java an sich Komplexität fördert. Einfache Lösungen werden nicht favorisiert, sondern es wird auf Komplexität gebaut – und die Log4Shell-Thematik ist das Ergebnis überbordender Komplexität, die nicht mehr zu überblicken oder gar zu meistern ist. Das hat Kristian Köhntopp vor einigen Wochen auch in seinem hervorragenden Kommentar zu Log4j: Es funktioniert wie spezifiziert [1] beschrieben.
Der gesellschaftliche Grund ist, dass zwar faktisch alle Unternehmen sich bei Open Source bedienen und davon abhängen, im Gegenzug aber kaum ein Unternehmen bereit ist, auch etwas beizusteuern oder zurückzugeben. Lizenzen wie AGPL & Co., die die eigentlich viel ehrlicheren Open-Source-Lizenzen sind, weil sie nicht nur Rechte einräumen, sondern auch Pflichten einfordern, werden von nahezu allen Unternehmen als Ausschlusskriterium behandelt, und stattdessen lieber auf die bequemen Alternativen MIT & Co. gesetzt. Und warum?
Weil es zumindest kurzfristig weniger kostet: Weniger Zeit und vor allem weniger Geld. Aber das ist eben nur eine kurzfristig erfolgreiche Strategie. Langfristig wird dieser Ansatz schiefgehen, und genau das ist jetzt mit Log4Shell eindrucksvoll passiert. Doch auch jetzt ist es einfacher, auf Open Source und die Entwicklerinnen und Entwickler dahinter zu schimpfen als sich proaktiv für ein nachhaltiges Modell einzusetzen, das Open Source für alle Beteiligten zum Vorteil werden lässt – nicht nur für die Verwender, sondern auch für die Menschen, die Open Source entwickeln.
Ein Geschäftsmodell für Open Source
An diesem Missstand muss sich dringend etwas ändern. Was wir als IT-Branche benötigen, ist ein tragfähiges Geschäftsmodell für nachhaltige Open-Source-Software. Und wir als Entwicklerinnen und Entwickler von Open Source müssen aufhören, unsere Zeit zu verschenken, als sei sie nichts wert.
Nur dann haben wir eine Chance, dass Open Source ein langfristig erfolgreiches und zugleich auch faires Modell werden kann, das nicht einseitig die belastet, die den Erfolg von Open Source erst ermöglichen.
URL dieses Artikels: https://www.heise.de/-6317678
Links in diesem Artikel: [1] https://www.heise.de/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html
Eine weihnachtliche LED-Schneelandschaft im Eigenbau
Von heise online — 10. Dezember 2021 um 16:09
Eine weihnachtliche LED-Schneelandschaft im Eigenbau
the next big thingGolo Roden
Der Advent gilt als besinnliche und beschauliche Zeit. Warum also nicht sich die Zeit nehmen und gemeinsam mit der Familie oder Freunden etwas schönes basteln und entwickeln – beispielsweise eine weihnachtliche LED-Schneelandschaft?
Im vergangenen Jahr lag der Schwerpunkt des Advents-Specials meines Unternehmens, der the native web GmbH, auf der persönlichen Weiterentwicklung. In 24 Videos ging es um für Entwicklerinnen und Entwickler alltagsrelevante Themen [1] abseits der Technologien, insbesondere um die hohe Relevanz von Konzepten und Prinzipien sowie das "richtige" Mindset.
Die weihnachtliche LED-Schneelandschaft
Auch in diesem Jahr wollten wir wieder etwas Besonderes machen, ohne aber das Thema des Vorjahres lediglich zu wiederholen. Deshalb haben wir uns überlegt, eine weihnachtliche LED-Schneelandschaft zu gestalten, zu sägen, zu kleben, zu löten und sie schließlich auch zu programmieren.
Dazu werden wir in der Adventszeit nach und nach sechs Videos veröffentlichen, in denen wir die einzelnen Schritte anschaulich erklären, so dass sie leicht nachgemacht werden können. Den Anfang machen zunächst die Vorstellung des Projekts [2] und die Einkaufsliste [3], auf der die benötigten Materialien und Werkzeuge zu finden sind.
Die Videos finden sich in einer eigenen Playlist [4] auf unserem YouTube-Kanal [5], ich werde aber auch diesen Blogpost regelmäßig um die neuen Links erweitern:
Auch in diesem Jahr gibt das HTTP Archive sein kostenloses Jahrbuch, den Web Almanac heraus. 112 Autoren, Analysten und Reviewer aus der Community haben sich zusammengetan, um den Zustand des Web im Jahr 2021 zu analysieren. Entstanden ist ein Werk mit 24 Kapiteln, die das Web aus unterschiedlichsten Blickwinkeln beleuchten.
Das HTTP Archive ist eine Unterorganisation des Internet Archive, das unter anderem für seine Wayback Machine bekannt ist. Das HTTP Archive crawlt monatlich 8,2 Millionen Websites und führt dabei unterschiedliche Analysen durch. Dazu zählt etwa die Größe der übertragenen Dateien, eingesetzte Caching-Techniken oder verwendete Webschnittstellen. Insgesamt fallen 39,5 TByte Datenmaterial an.
Der Web Almanac, der dieses Jahr zum dritten Mal herausgegeben wird, basiert auf den Daten des Crawls im Juli 2021. Insgesamt 24 Kapitel widmen sich unterschiedlichsten Themenbereichen im Web, darunter CSS, Kompression oder Barrierefreiheit. In diesem Jahr feiert das Kapitel zu WebAssembly sein Debüt. Nur ein Ausschnitt einiger interessanter Erkenntnisse: 94,4 Prozent aller Websites laden mindestens eine Third-Party-Ressource. 43,02 Prozent aller Desktop-Websites verweisen auf eine Datenschutzerklärung. Die beliebteste HTML-Element-ID lautet "content".
Der Autor dieses Blogs hat das Kapitel über Capabilities verfasst: In diesem werden Websites auf die Verwendung moderner Webschnittstellen [1] geprüft. Die meistgenutzten APIs sind die Async Clipboard API und die Web Share API; rund 9 Prozent aller Websites setzen Code ein, der auf diese Schnittstellen zurückgreift. Im vergangenen Jahr hat sich die Nutzung der Async Clipboard API um Faktor 10 erhöht.
URL dieses Artikels: https://www.heise.de/-6280705
Links in diesem Artikel: [1] https://www.heise.de/developer/artikel/Google-Projekt-Fugu-Die-Macht-des-Kugelfisches-4255636.html [2] https://almanac.httparchive.org/en/2021/
Capacitor oder Cordova: Welche Plattform sollten Entwickler webbasierter Mobilapps wählen?
Von heise online — 22. November 2021 um 08:13
Capacitor oder Cordova: Welche Plattform sollten Entwickler webbasierter Mobilapps wählen?
ÜberKreuz Christian Liebel
Wer webbasierte Anwendungen für Android und iOS schreibt, hat die Qual der Wahl: Mit Capacitor und Cordova gibt es zwei Ansätze, die zum selben Ziel führen. Zeit für einen Vergleich der beiden Cross-Plattform-Frameworks.
Das Framework Apache Cordova, auch unter dem Namen PhoneGap bekannt, bringt seit über einer Dekade zuverlässig Web-Apps auf Mobilgeräte. Mit Capacitor gibt es einen Herausforderer, hinter dem mit Ionic ein Unternehmenssponsor steht. ÜberKreuz stellt die beiden Plattformen vor und gibt eine Empfehlung ab, welcher Ansatz nach Meinung des Autors gegenwärtig zu bevorzugen wäre.
Apache Cordova: Cross-Plattform-Apps als Buildartefakte
Cordova [1] ist ein Community-Projekt der Apache Software Foundation (ASF). Es handelt sich dabei um den technischen Kern des Frameworks PhoneGap, das Adobe im Jahr 2011 gekauft hatte. Während Adobe PhoneGap als kommerziellen Dienst mit einigen Mehrwertangeboten wie einem Cloud-basierten Build-System betrieb, wurde der Unterbau quelloffen verfügbar gemacht und an die ASF übergeben. Im August 2020 kündigte Adobe an, PhoneGap einzustellen und sich nicht mehr an der Weiterentwicklung von Cordova zu beteiligen. Damit liegt die Wartung der Software nun bei der Community.
Bei Cordova gibt es zwei wichtige Konzepte: Plattformen und Plug-ins. Die Plattform stellt den portablen, webbasierten Quelltext auf einem bestimmten nativen Betriebssystem zur Verfügung, zum Beispiel Android oder iOS. Es werden auch weitere Plattformen wie macOS, Windows oder Electron unterstützt. Die Plattform greift auf die vom Betriebssystem bereitgestellte Web-View zurück und bettet die Anwendung darin ein. Daneben gibt es Plug-ins, die der Webanwendung den Zugriff auf beliebige native Schnittstellen erlauben. Das Plug-in enthält dabei (je Zielplattform) nativen Quelltext und macht diesen in JavaScript verfügbar.
Die grundlegende Philosophie bei Cordova ist, dass das komplette native Plattformprojekt als Artefakt eines Build-Vorgangs entsteht; für Entwickler verhält es sich als Black Box. Sämtliche Modifikationen werden in einer XML-Konfigurationsdatei vorgenommen und die Plattformprojekte daraus generiert. Die nativen Quelltexte sollen weder im Repository eingecheckt noch in irgendeiner Form verändert werden, da die Anpassungen beim nächsten Build wieder hinfällig wären.
Daten der App-Analyse-Plattform appfigures zeigen [2], dass im November 2021 rund 18 Prozent der App-Store-Anwendungen und Google-Play-Anwendungen auf Cordova setzen (über alle Anwendungskategorien hinweg, einschließlich Spielen). Das macht die Plattform im App Store zum zweithäufigsten und im Play-Store zum dritthäufigsten eingesetzten Entwicklungs-SDK. Auf Cordova setzt etwa die Selbstachtungs-App Sanvello (4,8 Sterne bei 17.300 Bewertungen im App Store).
Cordova spielt bei den meistverwendeten SDKs auf den vorderen Plätzen mit (Screenshot: appfigures.com, Stand: 21. November 2021)
Capacitor: Ionic fordert Cordova heraus
Capacitor [3] ist im Jahr 2019 erstmals erschienen. Hinter Capacitor steckt das Unternehmen Ionic, das auch ein gleichnamiges Cross-Plattform-Framework herausgibt und weitere Dienste rund um die plattformübergreifende Entwicklung anbietet. Bei Capacitor handelt es sich vergleichbar zu Cordova um die technische Basis, um Webanwendungen auf nativen Plattformen zur Verfügung stellen zu können. Das Framework Ionic stellt darüber hinaus Steuerelemente in den nativen Plattformstilen von Android und iOS bereit, damit diese Anwendungen so aussehen und sich so verhalten wie ihre nativen Gegenstücke. Weitere Dienste wie Cloud-Builds oder Single Sign-on lassen sich kostenpflichtig bei Ionic abonnieren.
Der zentrale Unterschied zwischen Cordova und Capacitor besteht in der Philosophie, wie die nativen Plattformprojekte betrachtet werden: Bei Capacitor werden diese nicht als Build-Artefakt angesehen, sondern einmal generiert, in die Codebasis eingecheckt und dann direkt modifiziert [4]. Damit haben Entwickler die volle Freiheit im Umgang mit dem nativen Projekt, müssen sich umgekehrt aber auch um dessen Wartung kümmern.
Plattformen und Plug-ins gibt es auch bei Capacitor: Als Ausgabeplattformen werden iOS, Android sowie Progressive Web-Apps unterstützt. Das Framework stellt für häufig verwendete native Schnittstellen eigene Plug-ins zur Verfügung und kümmert sich um deren Wartung. Außerdem ist Capacitor mit den meisten Cordova-Plug-ins kompatibel und kann somit auch auf diese zurückgreifen. Installierte Plug-ins findet Capacitor übrigens automatisch, wohingegen diese bei Cordova in der Konfiguration bekannt gemacht werden müssen.
Capacitor rangiert laut den Daten von appfigures aktuell auf Platz 20 (unter einem Prozent der Anwendungen) im App Store beziehungsweise Platz 12 (etwa 1 Prozent der Anwendungen) in Google Play unter den meistverwendeten Development-SDKs. Auf Capacitor setzt etwa die Fitness-App Sworkit (4,7 Sterne bei 27.000 Bewertungen im App Store).
Für welchen Ansatz sollten sich Entwickler entscheiden?
Cordova und Capacitor lösen zunächst einmal dasselbe Problem, nämlich die Ausführung einer Webanwendung auf einer nativen Plattform. Capacitor entstand dabei auf Basis der Erfahrungen des Ionic-Teams mit Cordova. Zugleich steht mit Ionic ein Unternehmenssponsor hinter Capacitor, der sein Geschäftsmodell darauf aufbaut. Weiterhin reagiert Capacitor durch die Bereitstellung einer PWA-Ausgabeplattform auf aktuelle Trends.
Das Cordova-Ökosystem scheint überdies in die Jahre gekommen. Einige von der Community bereitgestellte Plug-ins sind veraltet und werden nicht mehr gewartet. Auch JavaScript hat sich in der Zwischenzeit weiterentwickelt: Manche der Cordova-Plug-ins stellen globale Methoden bereit, die von Capacitor veröffentlichten Schnittstellen setzen hingegen auf ECMAScript-Module. Das bedeutet jedoch nicht, dass die Entwicklung von Cordova eingestellt ist, außerdem vereint Cordova derzeit noch den größeren Marktanteil auf sich.
Im täglichen Gebrauch fühlt sich der von Capacitor gewählte Ansatz, die nativen Plattformprojekte in das Repository einzuchecken, deutlich besser an. Manchmal braucht es bei Cordova-Projekten separate Build-Skripte, um String-Replacements an den Quelldateien der nativen Projekte durchzuführen. Umgekehrt bedeutet der Capacitor-Ansatz jedoch auch einen erhöhten Wartungsaufwand bei Plattformupdates.
Zusammengefasst dürfte Capacitor aktuell die naheliegendere Wahl für die meisten Entwicklerteams sein. Das Framework ist deutlich moderner und der Unternehmenssponsor dürfte die kontinuierliche Weiterentwicklung auf absehbare Zeit sichern.
URL dieses Artikels: https://www.heise.de/-4690975
Links in diesem Artikel: [1] https://cordova.apache.org/ [2] https://appfigures.com/top-sdks/development/all%E2%80%8B [3] https://capacitorjs.com/ [4] https://ionicframework.com/blog/announcing-capacitor-1-0/
Nicht nur die Corona-Infektionen nehmen zu. Im Herbst und Winter ist auch Grippezeit.
Jetzt mit plus weiterlesen!Testen Sie jetzt unser plus Abo für nur 0,99€ im ersten Monat. Sie erhalten sofort Zugang zu allen plus Inhalten im Web und in unserer News-App.Jetzt für 0,99€ testen*Sie sind bereits Abonnent?hier einloggen
Einen Gang zurückschalten: Zurzeit haben wieder Erkältung und Grippe viele Menschen im Griff. Symbolfoto: dpa
Ende der epidemischen Lage: Das sagen Vogelsberger Mediziner und Politiker
Von Benjamin Gössl — 30. Oktober 2021 um 00:00
Im Vogelsbergkreis haben derzeit 22 798 Personen zwei Impfungen bei Hausärzten erhalten, 2987 Vogelsberger wurden mit dem Einmal-Impfstoff von Johnsen & Johnsen geimpft, 621 Vogelsberger haben bereits eine Auffrischungsimpfung erhalten. Die Daten vom Stand 24. Oktober stammen von der Kassenärztlichen Vereinigung und werden unter anderem auf der Homepage des Hessischen Sozialministeriums veröffentlicht. Laut Angaben des Kreises, die auf den Daten bis einschließlich 17. Oktober basieren, verteilen sich die Impfungen wie folgt: Erstimpfungen 59,37 Prozent, vollständige Impfungen 63,3 Prozent, Dritt- bzw. Auffrischungsimpfungen 1,82 Prozent.
Architekt Alexander Felde, TÜV-Geschäftsführer Henning Stricker und der Bereichsleiter Facility Management TÜV Hessen Marcus Beschnitt befüllen gemeinsam die Zeitkapsel (von links).
(Foto: Lucas Schwarzburg)
Jetzt teilen:
Jetzt teilen:
ALSFELD - Der TÜV modernisiert sein Service-Center in Alsfeld und baut in der Grünberger Straße 76 eine neue Prüfanlage. Aus diesem Anlass hat am Donnerstag eine feierliche Grundsteinlegung mit geladenen Gästen und dem Versenken einer Zeitkapsel stattgefunden.
Unter anderem begrüßte der Geschäftsführer des TÜV Hessen Henning Stricker den Ersten Stadtrat Berthold Rinner (CDU) für die Stadt Alsfeld und den Kreisbeigeordneten Hans-Jürgen Herbst (SPD) für den Landkreis. Der TÜV investiere in Alsfeld, auch wenn das natürlich kein Vergleich zu dem Vorhaben der DHL sei, betonte Stricker während seiner kurzen Rede. Mit einer Investition von rund 2,5 Millionen Euro werde die Beschäftigung der ortsansässigen Mitarbeiter gesichert, „die hier einen wunderbaren Job Vorort machen“. Die Aufgabe des TÜV sei es, die Sicherheit im Straßenverkehr sicherzustellen. Das gelte sowohl für die Abnahme der theoretischen Führerscheinprüfung als auch der Überprüfung und Straßenzulassung der Fahrzeuge. Neben der Hauptuntersuchung werde durch die Abgasuntersuchung auch ein Beitrag für den Umweltschutz geleistet. „Was lange währt, wird endlich gut“, meinte Stricker über die Zeit zur Antragstellung des Neubaus bis hin zur Genehmigung und dem Start der Bauarbeiten.
Nach der kurzen Ansprache von Stricker wurde eine Zeitkapsel mit einer Oberhessischen Zeitung und unterschriebenen Urkunden des TÜV in einer Mauer versenkt.
Der TÜV Hessen ist seit dem Jahr 1964 am Standort in Alsfeld vertreten. Nach über 50 Jahren hat nun der Abriss des alten Gebäudes stattgefunden, an dessen Stelle der Neubau errichtet wird. Dieser soll im ersten Quartal 2022 abgeschlossen sein. In der Zwischenzeit finden aber weiterhin sämtliche Service-Angebote wie Hauptuntersuchungen oder theoretische Fahrerlaubnisprüfungen statt. Diese werden in einem provisorisch errichteten Prüfgebäude durchgeführt. Während der kompletten Bauzeit bleiben auch die Öffnungszeiten unverändert.
Um Wartezeiten zu vermeiden, empfiehlt der TÜV eine vorherige Terminvereinbarung für die Hauptuntersuchung. Dies ist telefonisch unter der Nummer 0800/2727270 oder online unter www.tuev-hessen.de/wunschtermin möglich.
*geschrieben von OZ-Schülerpraktikant Lucas Schwarzburg
FreshRSS 
