Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Problem roku 2020 – w Polsce przestały działać niektóre drukarki fiskalne. Błąd daty. Zamykają (niektóre) sklepy.
Problem dotyczy drukarek fiskalnych Delio firmy Novitus. Jakieś szczegóły? Proszę bardzo:
Okazało się, że w drukarkach był błąd z aktualizacją daty – po prostu nie można było jej ustawić na 2020 rok.
O braku możliwości normalnej sprzedaży biletów pisze Multikino:
W związku z awarią drukarek fiskalnych w naszych kinach, zakup biletów możliwy jest WYŁĄCZNIE za pośrednictwem strony internetowej oraz aplikacji mobilnej.
Problemy mają też miasta:
UWAGA! Z powodu awarii kasa w Urzędzie Miasta jest dziś nieczynna. Przepraszamy za utrudnienia.
W tradycyjny sposób nie można czasem kupić i biletów do teatru:
Szanowni Klienci! W związku z awarią systemu kasa CTMiT nieczynna do odwołania.
Problemów zgłasza też sporo restauracji z różnych miast:
Od rana walczymy z awarią kasy fiskalnej – będziemy zamknięci, dopóki nie uda nam się usunąć tej usterki ☹️
Sam producent potwierdza problem i pisze tak:
W dniu 1 stycznia 2020 w drukarkach DELIO wystąpił „błąd zegara” blokujący możliwość wystawienia paragonów z właściwą datą. Błąd został już zlokalizowany i określono sposób jego naprawy. Niestety niemożliwe jest dokonanie naprawy u Klienta i konieczna jest interwencja serwisu producenta.
Okres świąteczny, dużo zgłoszeń i konieczność wizyty w serwisie (bez możliwości zdalnej naprawy) nie wróżą dobrze. Można się pocieszać, że „podatny” jest tylko jeden model.–ms
nie działa też większość popularnych automatów z przekąskami/napojami – wyświetlają komunikat „błąd daty i godziny”
Pytanie czy proces testów wykonywany w ramach release’u firmware’u nie wychwycił tego potencjalnego bug’a?
„Można się pocieszać, że „podatny” jest tylko jeden model.”
Sprawdźcie ile jest tych DELIO 😉
„pomilenijna pluskwa” ;-E
Z powodu awarii programatora w Warszawie drukarki trzeba wysyłać do Nowego Sącza. W wielu miastach jest problem z zakupem nowych urządzeń – wszystko zostało już wykupione. Przewidywany czas naprawy wynosi 5 dni. Sama procedura naprawy przez producenta jest wątpliwa prawnie, gdyż wiąże się z modyfikacją softu w zafiskalizowanej drukarce i czego wykonanie normalnie bez zdjęcia plomby jest niemożliwe.
Ciekawe ile firm postanowi dochodzić odszkodowania za straty w sądzie i jak producent z tego wybrnie.
Od kiedy to serwis centralny ma problem z legalnym zdejmowaniem plomby?
Od kiedy to jest problem ze zmianą softu w zafiskalizowanej drukarce przez producenta czy dystrybutora? Przed 2013 takie operacje wykonywał normalny serwis za zgodą serwisu głównego.
Rozmawiam kiedyś z poważnym programistą embedded:
– a jak testujecie automatycznie?
– nie da się testować automatycznie firmware
Game over.
Niektórzy zatrzymali się mentalnie w latach 60tych, szczególnie w embedded gdzie ciągle powszechna jest era wcześnie łupanego programowania.
Ewentualnie mieli jakieś planowane postarzanie, tylko zapomnieli :D
> Niektórzy zatrzymali się mentalnie w latach 60tych, szczególnie w embedded gdzie ciągle powszechna jest era wcześnie łupanego programowania.
Co masz na myśli? Możesz napisać więcej na ten temat, i co byś polecał początkującemu programiście firmware do przeczytania żeby zbudować sobie profesjonalną bazę wiedzy programistycznej?
a) używanie języków zbyt blisko assemblera: C i asm
b) z tego powodu niemożnośc unit testowania
c) z braku abstrakcji wynikającej z a) niemożnośc jakiegokolwiek innego testowania automatycznego
d) z powodu a) niemożnośc testowania tego in vitro poza urządzeniem
Konkretnie programiści embedded mają od lat leżace do dyspozycji techniki pisania kodu które pozwalają testować grubą wiekszosc kodu poza urządzeniem, a obsługa daty jest wręcz idealnym przykładem czegoś co jest możliwe do testowania poza. Ale jednocześnie ludzie Ci zatrzymali się w rozwoju na bardzo prymitywnych językach jak C i assembler i ignorują jakikolwiek postęp w tym temacie i są odporni na nawer próby uabstrakcyjnienia tego co mają. Efektem czego dostaja kod uniwersalny zmielony z implementcją na konkretny sprzęt, z zerową abstrakcją. I na koniec „nie da się” i kurtyna.
Trudno coś poradzić poza wysłaniem delikwentów na kursy programowania. W dodatku zazwyczaj są oni przeświadczeni o tym że nie da się lepiej (urodzeni hackerzy), więc problemem jest ideologia i zarozumialstwo (znam to na kilku przykładach z autopsji).
Dla przykładu: zmiana języka z C na C++ i kilka sztuczek powoduje natychmiastowy wzrost abstrakcji, umożliwia unit testowanie i testowanie automatyczne większości kodu embedded z *zerowym* wysiłkiem i *zerowym* narzutem w kodzie wynikowym (uwaga: teoretycy C++ w embedded powiedzą inaczej, ale to brednie wszak bo nigdy tego nie sprawdzili). Czyli zmiana języka na C++ i zmiana stylu pisania na abstrakcyjny od ręki rozwiązuje problemy testowania. Problem jest jak zwykle ideologiczy. Taki embedowiec, usłyszał gdzieś w necie że C++ jest niekoszerny, zajmuje dużo, ma błedy itd itp idiotyzmy. I dalej dziubie w asm/C. Kurtyna.
A zmiana na C++ i stylu pisania to najmniej bolesna zmiana jaką takowy misio może podnieć jakość bez rewolucji.
Problem jest białkowy. Niestety problemy białkowe rozwiązują się wyjątkowo powoli.
Uwaga dla hejterów: Pisanie w C++ nie wymaga klas. C++ to nie tylko klasy. W embedded np. stosuje się powszechnie statyczny polimorfizm. Aruino od dawna stosuje C++ tylko tego tak nie nazwali i nagle ma to masę zwolenników.
Dla Hunera: odrzuć bredzenie o tym że w embedded uzywa się C i asm i są najlepsze. Są tylko najlepsze w bardzo wąskim zastosowaniu. Ważniejsza jest abstrakcja kodu. Skoro zamierzasz się uczyć embedded to nie ucz się embedded. Naucz się pisać abstrakcyjnie, stosować choćby unit testy i dopiero potem wejdź w embedded. Zrozumiesz jak prymitywnymi metodami posługuje się ten świat i jak łatwo można to naprawić jeśli tylko nie bedzie się słuchało kretynów piszących od 40 lat w asm/C na 8051.
Poważnie tak powszechnie piszą w tym asmie?
I naprawdę w C nie można zrobić tych testów, a w C++ można?
Jesli trafisz ma „miszcza” od 8051 to na bank będzie od preferował asm albo jakiś wyjątkowo prymitywny dialekt C (zazwyczaj ograniczony kiepskimi kompilatorami na te dziwne architektury) który ad asm niewiele się różni. W C skrajnie cieżko robić abstrakcje pozwalające testować ten sam kod nieintruzywnie, zazwyczaj kończy się to miliardem makr nad którymi nikt po chwili nie panuje. Natomiast w C++ jest znacząco łatwiej dostać darmową abstrakację bez obciążania kodu wynikowego i testować. Niestety to wymaga znajomości nowoczesnych technik programowania a przeciez masz przed sobą hackera od 8051 który zna na pamięć kody maszynowe a ostatnią ksiązkę o programowaniu czytał w ’70. Cięzko mu wyjaśnić że jak napisze 2 linijki więcej w C++ to dostanie abstrakcje. Dla niego te dwie linijki więcej to za daleko od asm, nigdy się na to nie zgodzi „żeby nie mieć kontroli nad każdym bitem”. Ponadto istnieje przeświadczenie że pisanie więcej kodu po stronie wysokiego poziomu przekłada się na więcej aseblera. Co oczywiscie bzdura, ale przeciez taki legacy programator 8051 nie ma o tym pojęcia bo nigdy nie próbował natomiast słyszał i wyczytał na gopherze. Tak czy inaczej w świecie embedded nowoczesne techniki testowania kodu nie istnieją poza kilkoma wyjątkami związanymi z charyzmą drobnego promila programistów. Zazwyczaj większość pisze gówniany kod w C, nieprzenośny, nietestowalny, zmielony z konkretną implementacją, wymyślając kwadratowe koła za każdym razem i bezustannie bredzi że inaczej się nie da „no bo jak?”. No wiec wiadomo od 40 lat jak. Reszta to kwestia biologii.
@Sebo
A polecisz dobrą literaturę w temacie „efektywne programowanie C++ embedded”? Z ewentualnymi wstawkami w asmie, jeśli to nie herezja?
@VerSteX
Jak już mówiłem, unikaj książek do embedded na początek. Zainteresuj się książkami z okolic boost/stl jeśli to ma być C++. Techniki jakie tam są pokazane, szczególnie boost, szablony, traits, są wprost użyteczne w embedded, ponadto boost powszechnie korzysta z polimorfizmu statycznego więc koncepcje abstrakcji kodu bez narzutu runtime jak znalazł. Wstawki asm są wszędzie takie same i wątpię aby ktoś miał książkę o asm w c++.
PS. Arduino korzysta z C++ w pewnym zakresie, niestety to nie jest akurat dobry przykład bo nie maja w interesie testowania kodu. To co jednak tam jest zazwyczaj jest i tak o lata świetlne nowocześniejsze niż wypociny legacy programmers od 8051.
PS2. I wybierz architekturę współczesną. Może się okazać że psu na budę te wszystkie abstrakcje kiedy wybierasz procesor bez sensownego kompilatora.
Sebo, coś się tak tej 51-ki uczepił ? Ktoś tego jeszcze (w branży fiskalnej) używa ?
Na początku wieku pracowałem w jednej z głównych firm z tej branży, 51 z pogardą traktowaliśmy przechodząc na H8s – a ile testów było robionych automatycznie na PC, Panie…
OK, było trochę kodu w ASM, ale nie więcej niż trzeba (cóż, własny OS…).
@No_Way_To_Pay: Mentalność po 8051 została. Nie da się tego, tamtego i owego. Z niechęcia, a często agresja, przechodzi się na zdrowo rozsądkowe architektury które nie dość że szybsze, łatwiejsze to jeszcze kompilatory mają normalne. itd itp. 8051 jak z soczewce skupia wszystkie problemy świata embedded. I to sa praktycznie wyłącznie problemy białkowe.
To że są wyjątki nic nie znaczy choć bez wątpienia się chwali. Gro ludzi z embedded to programiści niskopoziomowi, im starsi tym dalej od współczesnych technik zapewniania jakości kodu. Będą pisać na ARMach tak samo jak na 8051. Czyli byle jak.
To co, kolejna pluskwa w 2049? :)
Raczej w 2038…
Albo i wcześniej: 7 lutego 2036 przekręci się NTP.
Y2K20 ;))
Kto wie, może nawet 19 stycznia 2038, wtedy to 32-bitowy Unix time wyczerpie się…