Kursy • Poradniki • Inspirujące DIY • Forum
Powiedzenie „It's not a bug, it's a feature”(„To nie problem, to cecha”) już na stałe zapisało się w historii branży technologicznej.
To humorystyczne określenie odnosi się do sytuacji, w której coś, co wygląda na błąd, w rzeczywistości przedstawiane jest jako zamierzona funkcjonalność.
Historia „It's not a bug, it's a feature” jest w gruncie rzeczy niejasna. Ciężko jest przypisać użycie tego zwrotu do konkretnej osoby czy grupy osób. Wiemy jedynie, że jego popularność rosła wraz z rozwojem branży technologicznej, przebijając się do mainstreamu mniej więcej na przełomie lat 70. i 80. XX wieku.
Jedna z legend głosi, że powiedzenie to pojawiło się w firmie IBM, jako sposób na usprawiedliwianie niektórych nieprzewidzianych zachowań systemów mainframe’owych, ale ciężko powiedzieć czy tak rzeczywiście było.
Rzeczywiście czasami zdarza się, że producenci sprzętu implementują konkretną funkcjonalność, która przez użytkowników odebrana zostaje jako nieprzemyślana, lub też nawet niezamierzona, gdy w rzeczywistości jest zupełnie odwrotnie. Jednak co by nie mówić zazwyczaj sprzęty i oprogramowanie jest dopracowane, choć nie oznacza to, że błędy się nie zdarzają. Tak jak w pisanym tekście znaleźć możemy literówki, czy też ortograficzne buble, tak też sprzęt elektroniczny bywa wadliwy.
Płacąc za nowy komputer, samochód, czy też oprogramowanie oczekujemy, że będzie ono jak najbardziej dopracowane, pozbawione potencjalnych wad. Te muszą być wykryte i przewidziane już na etapie projektowania, dlatego tak ważne są odpowiednie testy i kontrola jakości.
Historia jednak daje nam wiele przykładów sytuacji, w których programistyczny lub sprzętowy błąd ujawniał się już po premierze danego sprzętu. Zazwyczaj kończyły się one tylko frustracją użytkowników, ale bywały też sytuacje, gdzie sprzętowy błąd kończył się tragicznie. Dlatego w tym artykule opowiem wam o kilku mniej lub bardziej znanych wpadkach w świecie technologii.
Było wtorkowe popołudnie 4 czerwca 1996 roku. Tego właśnie dnia z kosmodromu Kourou miał się odbyć pierwszy lot Ariane 5 - nowej rakiety zaprojektowanej przez Europejską Agencję Kosmiczną i francuski Państwowy Ośrodek Badań Kosmicznych. Celem misji było wyniesienie na orbitę okołoziemską zespołu sond do badania magnetosfery.
Rakieta Ariane 5 była następczynią całkiem udanej konstrukcji Ariane 4, która przez lata wynosiła zaprojektowane przez człowieka urządzenia w przestrzeń kosmiczną. Kolejną iterację rakiety rozwijano przez ostatnie 10 lat, a budżet projektu wyniósł 7 mld dolarów, dlatego też nikt nie spodziewał się większych problemów.
Pierwsze pół minuty od momentu zapłonu silników wyglądały zupełnie „zwyczajnie”, Ariane 5 oderwała się od powierzchni ziemi i z każdą sekundą zwiększała pułap lotu. Jednak w pewnym momencie zdarzyło się coś dziwnego, rakieta przechyliła się o niemal 90°, a chwilę później obserwujące start kamery zarejestrowały olbrzymią eksplozję.
Przyczyną katastrofy okazał się błąd w oprogramowaniu rakiety. Moduł określający pozycję Ariane 5 w przestrzeni korzystał z szeregu zmiennych, a jedna z nich była też korekta prędkości w osi poziomej. Zmienna ta była 64 bitową wartością zmiennoprzecinkową konwertowaną przez komputer na 16 bitową liczbę całkowitą. 37 sekund po starcie 16 bitowa wartość osiągnęła swoje maksimum, czego efektem było przypisanie do niej wartości odpowiadającej kodowi błędu.
Ten jednak zaprojektowany był w identyczny sposób i również zgłaszał błąd przepełnienia. Niestety komputer pracował dalej, uznawszy błąd jako prawidłowa wartość korekty prędkości. Efektem tego była decyzja o korekcie kursu i zachowanie się rakiety w sposób widoczny na filmie powyżej.
Co ciekawe zmienna korekty prędkości w Ariane 5 nie była w ogóle potrzebna. Rakieta odziedziczyła ten moduł po swojej wcześniejszej wersji, w której był on wykorzystywany tylko w momencie startu. W czasie późniejszego lotu Ariane 4 nadal przypisywała wartości do zmiennej int, ale ich nie wykorzystywała. Była to tak naprawdę fragment niewykorzystywanego kodu, dostosowany do czwartej wersji rakiety.
Jednak nawet w przypadku martwego kodu, zgłoszony błąd musiał być obsłużony przez komputer, co poskutkowało efektem domina i modyfikacją kursu rakiety, którego nie dało się już cofnąć. Rejestrując nieprzewidziane zachowanie rakiety, automatycznie aktywował się moduł bezpieczeństwa, uruchamiając procedurę autodestrukcji i tak 4km nad ziemią Ariane 5 przestała istnieć.
Ciekawy jest natomiast sam raport z katastrofy, opublikowany dwa tygodnie po wypadku. Wskazuje on jako przyczynę nie tyle sam błąd w kodzie, a brak odpowiedniej analizy ryzyka. Badacze zaznaczają, że wadliwy kod jest tylko efektem braku wystarczających testów oprogramowania.
24 czerwca 2010 roku, to dzień, w którym można było obserwować tłumy ludzi w lokalnych sklepach Apple. Nie były one przypadkowe, ponieważ właśnie wtedy do sprzedaży trafił IPhone 4, czyli pierwszy telefon firmy z Cupertino wyposażony w wyświetlacz Retina. Cena urządzenia zaczynała się od 199 dolarów, a w przeciągu trzech dni Apple sprzedało ponad 1,7 mln telefonów.
Jednak mimo wysokich wolumenów sprzedaży, premiera ta nie była dla Apple sukcesem. Jeszcze w dniu premiery pojawiły się głosy, że z najnowszym iPhonem jest coś nie tak. Użytkownicy skarżyli się, że urządzenia mają problem z zasięgiem sieci komórkowej.
Co ciekawe problem ten występował tylko, gdy telefon trzymany był w lewej ręce. Wówczas paski sygnalizujące zasięg znikały częściowo, a w skrajnych przypadkach całkowicie. Przyczynę problemu dość szybko zidentyfikowali sami użytkownicy, dzielący się swoimi testami i diagnozami na forach internetowych, wniosek był jeden – iPhone 4 ma problem z anteną.
Problemy iPhona 4 z anteną nazwane zostały przez media „Antennagate”
Anteny telefonu miały formę pasków ze stali nierdzewnej umieszczonych wzdłuż krawędzi bocznych urządzenia. Pierwsza z nich zajmujący mniej więcej 1/3 obwodu odpowiedzialna była za komunikację Bluetooth, WIFI oraz GPS, natomiast większa antena odpowiadała za sygnał sieci komórkowej. Apple dość szybko potwierdziło, że problem istnieje, ale z drugiej strony był on bagatelizowany.
Konstrukcja anteny okalającej urządzenia była dla Apple czymś nowym, we wcześniejszych modelach ta umieszczana była wewnątrz. Teoretycznie nowe rozwiązanie miało poprawić zasięg, choć jak wiemy, już na etapie projektowania jeden z inżynierów, Rubén Caballero, wskazywał, że nowa konstrukcja może być problematyczna. Najbardziej istotna okazała się wąska szczelina anteny w jednym z rogów iPhona. Trzymając urządzenie w lewej ręce, ta była zakrywana co skutkowało utratą zasięgu.
Jednak mimo odkrycia przyczyny problemu Apple nadal bagatelizowało problem. 2 lipca opublikowane zostało oświadczenie, w którym firma poinformowała, że problemy z zasięgiem są kwestią oprogramowania, które zostanie jak najszybciej poprawione.
Sytuacja zmienia się jednak 12 lipca, gdy opublikowany zostaje raport Consumer Reports stwierdzający wprost, że urządzenia są wadliwe, a Apple zobowiązane jest do rozwiązania problemu. Co ciekawe w raporcie umieszczono też informację, że trzymanie telefonu w etui może znacznie zniwelować nieprawidłowe zachowanie anteny.
Ostatecznie firma przyznała się do błędu w projekcie, informując jednocześnie, że w kolejnych sprzedawanych egzemplarzach wada nie będzie występować, ponieważ antena pokrywana będzie specjalnym materiałem izolującym. Jednocześnie wszyscy klienci, którzy kupili wadliwe iPhony, mogą otrzymać darmowe etui, a ci, którzy kupili je wcześniej otrzymają zwrot pieniędzy.
Choć radioterapia wykorzystywana jest w leczeniu nowotworów już od bardzo wielu lat i dzięki niej uratowano życie ogromnej ilości osób, to w dziedzinie tej doszło też do kilku niechlubnych wypadków. Jednym z nich są incydenty związane z maszyną Therac-25.
Sprzęt ten wykorzystywano w amerykańskich i kanadyjskich szpitalach w drugiej połowie lat 80. XX wieku. W ciągu dwóch lat miedzy 1985 i 1987 doszło do sześciu przypadków podania pacjentom dawki promieniowania większej niż zaleconej przez lekarza, powodując poważne obrażenia, jak i śmierć pacjentów.
Maszyna Therac-25 (Źródło grafiki: https://pvs-studio.com/en/blog/posts/0438/)
Niepoprawne działanie sprzętu medycznego jest niedopuszczalne, dlatego już w 1985 roku, gdy wystąpił pierwszy wypadek z Therac-25 lekarze sugerowali, że maszyna może działać niepoprawnie, dlatego zwrócili się do producenta z prośbą o zbadanie tego tematu. Ten jednak stwierdził, że winnym podania zbyt dużej dawki promieniowania nie może być oprogramowanie urządzenia, wskazując problemy mechaniczne lub elektryczne.
Prawdziwą przyczynę problemów odkryli dopiero pracownicy jednego ze szpitali, w którym wcześniej doszło do wypadku. Zauważyli oni, że w specyficznych warunkach maszyna może podać pacjentowi dawkę promieniowania większą niż wybrana.
Therac-25 mógł pracować w trzech trybach: Electron mode – naświetlanie wiązką małej mocy na dużym obszarze, X-Ray mode – wykorzystanie wiązki dużej mocy na małym obszarze z dodatkową przesłoną regulującą, Light mode – brak promieniowania, sprzęt emitował tylko światło widzialne pomagające ustawić głowicę w odpowiednim miejscu.
Gdy wybierany był X-Ray mode, urządzenie potrzebowało około 8 sekund na odpowiednie ustawienie przesłony, ale jeśli w tym czasie operator zmienił tryb na Electron mode, urządzenie emitowało wiązkę dużej mocy bez odpowiedniego filtra. Podobnie sprawa wyglądała w momencie przełączenia z X-Ray mode na Light mode.
Obsługa Therac-25 nie była łatwa, dlatego w większości przypadków 8 sekund było wystarczającym czasem dla ustawiającej się przesłony. Jednak paradoksalnie najbardziej doświadczeni operatorzy, którzy potrafili wpisywać kolejne komendy niezwykle szybko, mogli nieświadomie przyczynić się do znacznego uszczerbku na zdrowiu, a w skrajnych przypadkach nawet do śmierci pacjenta.
W czasie procesu sądowego przeciwko producentowi dokładnie zbadane zostały wszystkie incydenty. Wskazano szereg wad oprogramowania Therac-25, które działało na komputerze PDP-11 i napisane było w asemblerze. Wskazano między innymi, że program współdzielił pamięć, ta sama zmienna odpowiadała za przechowywanie komend użytkownika, jak i śledzenie pozycji głowicy.
Podczas ustawiania mocy wiązki możliwe było dzielenie przez zero, co skutkowało ustawieniem jej maksymalnej wartości. Poza tym flaga informujące o niewłaściwej pozycji przesłony była inkrementowana zamiast przypisywania do niej konkretnej wartości. Jednak tak jak w przypadku Ariane 5 tutaj też zauważono, że błędy w kodzie są tylko efektem niepełnego przetestowania maszyny.
Jedną z najbardziej rozpoznawalnych rodzin jednostek centralnych Intela są procesory Pentium. Wprowadzono je na rynek w 1993 roku, zastępując tym samym konstrukcje Intel 486.
Linia Pentium w porównywaniu do swoich poprzedników posiadała wiele ulepszeń, w tym też znacznie bardziej wydajny algorytm służący do obliczeń zmiennoprzecinkowych. Który to też okazał się największym zmartwieniem niebieskich na początku lat 90. XX wieku.
Fragment rdzenia procesora odpowiedzialny za błąd FDIV. (https://www.righto.com/2024/12/this-die-photo-of-pentium-shows.html)
Przez pierwszy rok procesory Pentium sprzedawały się świetnie, wchodząc w skład najnowszych komputerów. Jedną z osób, która również kupiła jednostkę obliczeniową opartą na najnowszym procesorze Intela, był profesor Thomas Nicely z Lynchburg College.
Nie zdarzały się one zbyt często, ale były obecne. Profesor sprawdził też trzy inne komputery z procesorem Pentium i okazało się, że zachowują się w ten sam sposób. Jednak co ciekawe, jedno z jego starszych urządzeń wyposażone w procesor poprzedniej generacji nie miało tego problemu i wszystkie wyniki dzielenia były poprawne.
Nicely postanowił zwrócić się do pomocy technicznej Intela, ta jednak zbyła go klasycznym korporacyjnym tłumaczeniem, że problemu nie ma i niech nie zawraca głowy nikomu swoimi obliczeniami. Jednak stwierdzenie, że problemu nie ma, od początku mijało się z prawdą.
Logo firmy Intel. (https://en.wikipedia.org/wiki/Intel)
Intel doskonale zdawał sobie sprawę z wady jednostki FPU (zmiennoprzecinkowej). Ta wykryta została na przedpremierowych testach procesora, w których stwierdzono, że w przypadku dzielenia procesor bywa niedokładny. Problem jednak zbagatelizowano, ponieważ pojawiał się on mniej więcej raz na 9 miliardów operacji.
Pozostawiony bez odpowiedzi profesor postanowił wysłać wiadomość do kilku największych magazynów komputerowych tamtych lat, jak i swoich znajomych z branży technologicznej. Na efekty nie trzeba było długo czekać, wokół Intela rozpętała się medialna burza, której główną tezą była świadoma sprzedaż wadliwych chipów.
Postawiona pod ścianą korporacja przyznała, że fragment procesora, a dokładniej jedna z tablic PLA (ang. Programmable Logic Array) została niepoprawnie zaprojektowana, co powodowało błędy w dzieleniu zmiennoprzecinkowym, zaznaczając jednocześnie, że wadliwe jednostki zostaną wycofane, a nowe pozbawione błędu.
Tutaj cała historia mogłaby się skończyć, ale chciwość lub, jak kto woli oszczędność Intela sprawiła, że tak się nie stało. Firma zobowiązała się wymienić wszystkie sprzedane procesory Pentium, ale tylko w przypadku, gdy użytkownik będzie wstanie udowodnić, że dokładność w dzieleniu zmiennoprzecinkowym jest mu rzeczywiście potrzebna.
Klienci byli wściekli, czego efektem była jeszcze większa medialna nagonka. Co więcej, jeden z największych odbiorców procesorów Intela – IBM ogłosił, że wstrzymuje sprzedaż komputerów wyposażonych w tą jednostkę centralną. Po tej informacji Intelowi nie pozostało nic innego jak, posypać głowę popiołem i wycofać z rynku wszystkie wadliwe mikroukłady, co kosztowało korporację 475 milionów dolarów.
Problem, określany później jako „FDIV bug”, był tak jak wspomniałem, problemem sprzętowym. Jedna z tablic PLA procesora, która przechowywała wartości wykorzystywane przy operacjach dzielenia, została niepoprawnie zaprojektowana. Jak przyznał Intel brakowało w niej pięciu wartości, co skutkowało niepoprawnymi obliczeniami.
Co ciekawe Ken Shirriff, który przeanalizował strukturę procesora w swoim artykule zwrócił uwagę, że tak naprawdę brakuje nie pięciu, a aż szesnastu wartości. Jeśli chcielibyście dowiedzieć się więcej o FDIV bug na poziomie krzemu to odsyłam właśnie do świetnego materiału Kena Shirriffa.
23 września 1999 roku miał być dla pracowników NASA kolejnym zwyczajnym dniem. To wówczas do wejścia na orbitę Marsa przygotowywano sondę Mars Climate Orbiter, co było standardową procedurą, przećwiczoną na dziesiątkach statków, wystrzelonych wcześniej.
Sprzęt ten wyniesiony został w przestrzeń kosmiczną 10 miesięcy wcześniej, a jego celem po dotarciu do czerwonego globu było zbadanie marsjańskiego klimatu i atmosfery. Poza tym sonda miała pełnić funkcję przekaźnika komunikacyjnego w planowanym programie Mars Surveyor '98.
Nikt nie spodziewał się większych komplikacji. O godzinie 9:00:46 sonda rozpoczęła manewr wejścia na orbitę Marsa, uruchamiając główny silnik, który miał pracować przez 16 minut i 23 sekundy. Wszystko szło dobrze, jednak mniej więcej cztery minuty po rozpoczęciu manewru (9:04:52) kontakt radiowy z urządzeniem zostaje zerwany i już nigdy nie wraca.
Niemal natychmiast po wypadku powołana została komisja śledcza, której celem było zbadanie przyczyny katastrofy sondy Mars Climate Orbiter. Wyniki prac komisji poznaliśmy w listopadzie tego samego roku wskazujące jednoznacznie na błąd w oprogramowaniu.
Wszystkiemu winne okazały się jednostki miar. Zespół nawigacyjny z Jet Propulsion Laboratory (JPL) wykorzystał w swoich obliczeniach system metryczny (milimetry i metry), podczas gdy ekipa Lockheed Martin Astronautics w Denver, która zaprojektował i zbudował kosmiczną sondę, bazowała na angielskim systemie cali, stóp i funtów.
W pierwszej fazie lotu rozbieżności w systemie miar nie wpłynęły na trajektorię lotu statku, jednak podczas manewru wejścia na orbitę Marsa uruchamiany był silnik, którego moc korygowana była przez algorytm oczekujący wartości w systemie SI.
Otrzymując błędne informacje, komputer zbyt szybko obniżał wysokość lotu względem powierzchni czerwonej planety, co poskutkowało spaleniem się Mars Climate Orbiter w atmosferze Marsa.
Humorystyczna grafika powstała po incydencie z Mars Climate Orbiter. (https://www.simscale.com/blog/nasa-mars-climate-orbiter-metric/)
Mimo że wina za niepowodzenie misji spoczywała na inżynierach Lockheed Martin, ponieważ zgodnie ze sztuką pojazdy kosmiczne powinny operować na systemie metrycznym, NASA zdecydowała się nie obarczać winą ekipy z Denver.
Zamiast tego wielu pracowników JPL stwierdziło, że amerykańska agencja kosmiczna jest współwinna utraceniu sondy, wskazując na niedokładne testy i analizy pojazdu przed jego wyniesieniem w przestrzeń kosmiczną.
Samochody marki Toyota kojarzone są z bezpieczeństwem i niezawodnością, szczególnie w Polsce, gdzie fenomen ten urósł do naprawdę sporych rozmiarów. Jest w tym oczywiście sporo racji, bo zwłaszcza starsze modele Japońskiego koncernu rzeczywiście słyną z ponadprzeciętnej wytrzymałości, ale tak jak i inne koncerny motoryzacyjne, tak też Toyota ma w swojej historii momenty, o których wszyscy woleliby zapomnieć.
Logo firmy Toyota. (https://pl.wikipedia.org/wiki/Toyota)
W 2009 roku jadący wypożyczonym samochodem mężczyzna wraz ze swoją żoną i dwójką dzieci zadzwonił pod numer alarmowy 911. Poinformował on odbierającego operatora, że jedzie z prędkością ponad 125 mil (201 km/h), a pedał gazu i hamulca nie reaguje. Niestety mimo prób zatrzymania, czy chociażby zmniejszenia prędkości, kierowca utracił panowanie nad pojazdem i uderzył w barierkę, wszyscy pasażerowie zginęli na miejscu.
Nie jest pewne, czy był to pierwszy przypadek, w którym samochód Toyoty niezamierzanie przyśpieszył, ale faktem jest, że od tego momentu sprawą zainteresowały się media.
Korporacja zasypana gradem pytań wydała oświadczenie, że rzeczywiście w ich autach może dojść do zacięcia się manipulatora gazu, ale tylko w starszych egzemplarzach i prawdopodobieństwo takiej sytuacji jest bardzo małe. Jednocześnie zasugerowano, że powodem opisanego wypadku był prawdopodobnie przesunięty dywanik podłogowy, który zablokował gaz i hamulec. W prasie krążyła też teoria o wadliwym komputerze Toyoty, ale koncern kategorycznie temu zaprzeczył.
Grafika powstała na potrzeby programu Saturday Night Live NBC. (Źródło grafiki: https://en.namu.wiki/w/토요타%20리콜%20사태)
Mimo zaprzeczeń reakcja Japońskiego giganta była co najmniej zastawiająca. Choć według tłumaczeń samochody były pozbawione jakichkolwiek wad, to na przełomie stycznia i lutego 2010 roku ogłoszono wstrzymanie sprzedaży nowych samochodów i wycofanie z rynku prawie 9 milionów już sprzedanych pojazdów.
Jednak mimo tego, informacje o przyspieszających Toyotach pojawiały się nadal. Zmusiło to NHTSA (US Highway Traffic Safety Administration) do rozpoczęcia oficjalnego śledztwa w celu wyjaśnienia zaistniałej sytuacji. Niedługo później opublikowany został oficjalny raport, w którym podtrzymywano wcześniejsze tłumaczenie Toyoty.
Wszystkiemu winne są dywaniki podłogowe, a prawdopodobieństwo zacięcia się pedału gazu jest niezwykle małe. Mogłoby się wydawać, że korporacja wyszła z całej sytuacji obronną ręką, a zapobiegawcze wycofanie pojazdów dodaje jej tylko wiarygodności.
Tutaj jednak sprawa się nie kończy, ku zdumieniu wszystkich 19 marca 2014 roku Departament Sprawiedliwości Stanów Zjednoczonych na podstawie prowadzonego przez FBI dochodzenia nakazał Toyocie zapłacić ówcześnie największą w historii przemysłu motoryzacyjnego grzywnę 1,2 miliarda dolarów.
Była to cena korupcji, oszukiwania klientów oraz tuszowania błędów związanych z funkcjonowaniem komputera pokładowego. Okazało się, że elektronika Japońskich samochodów była wadliwa. Według prowadzonych eksperymentów przy większych prędkościach następowało zerwanie komunikacji między modułem przepustnicy, a centralnym komputerem, ponieważ ten niepoprawnie zarządzał wbudowaną pamięcią.
Poza tym ujawniono, że w czasie wcześniejszego dochodzenia prowadzonego przez NHTSA pracujący tam śledczy otrzymali od koncernu czeki in blanco wraz z wiadomością brzmiącą mniej więcej tak: „Skupcie się na dywanikach i zaciętym gazie, nie na błędach komputera”.
Jednak mimo lat w sprawie tej nadal istnieje wiele wątpliwości. Dodatkowo podsyca je raport śledczy z 2019 roku, w którym stwierdzono, że występujący problem elektroniki, nie był bezpośrednią przyczyną wypadków, a jedynie podstawą do procesu, w który można by wplątać Japońskiego giganta. Tekst stwierdza, że wadę w komunikacji wykryto tak naprawdę przypadkiem i bezpodstawnie powiązano ją z całą sprawą.
W branży technologicznej znajdziemy mnóstwo przykładów i historii błędów. Zarówno tych z dzisiejszej perspektywy zabawnych, jak i tych tragicznych. Choć producenci starają się przygotowywać jak najbardziej dopracowany sprzęt, to możemy być pewni, ze błędy nadal będą występować. Najważniejszym jest jednak, aby wszelkie wady były lekcją, z której można się czegoś nauczyć, czegoś, co w przyszłości zaprocentuje.
Półprzewodniki stały się fundamentem prawie każdej nowoczesnej technologii, a układy scalone są w niemal każdym urządzeniu elektronicznym.... Czytaj dalej »
Źródła: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 15
Przeczytaj powiązane artykuły oraz aktualnie popularne wpisy lub losuj inny artykuł »
Dołącz do 30 tysięcy osób, które otrzymują powiadomienia o nowych artykułach! Zapisz się, a otrzymasz PDF-y ze ściągami (m.in. na temat mocy, tranzystorów, diod i schematów) oraz listę inspirujących DIY z Arduino i RPi.
Trwa ładowanie komentarzy...