"Interfejs powstaje w bólach" czyli nowa mowomowa na... (2020)
Submitted by marcin on Mon 24-Aug-2020

polski
polski blog
dobreprogramy.pl
Windows
Chrome


Artykuł został opublikowany w serwisie dobreprogramy.pl

10 marca 2019 niejaki clouds65 zgłasza błąd o tym, że jego Linux uruchomiony w HyperV (z buforem ramki hyperv_fb) działa koszmarnie wolno.

12 marca 2019 użytkownik z nickiem dcui (najwyraźniej pracownik MS) stwierdza, że bug może być odtworzony ("I can reproduce the exact symptoms on latest Hyper-V build. It looks like recently something on the host side causes this issue.") i dodaje "I'm going to report this issue to Hyper-V team, but I'm afraid it can not be resolved soon".

Użytkownik marcinwiacek w dniach 3 - 6 lipca 2019 zauważa, że problem również go dotyczy. Zaraportowane są takie detale jak procesor (myślę, że to ważne w kontekście kolejnego odkrycia) i fakt, że włączenie opcji "Processor compatibility" dla CPU rozwiązuje problem.

Firma Microsoft wie już, gdzie, co i jak (i wie również, w którym mniej więcej buildzie HyperV wystąpił błąd).

Możnaby powiedzieć, że całość w tym momencie traci rację bytu - mamy przecież jego obejście...

Ale, ale... HyperV to produkt komercyjny, pisany przez wielką firmę... w międzyczasie błąd jest raportowany przez innych ludzi... przychodzi wreszcie 27 lipca 2020 i dcui stwierdza "I still can't understand why checking the "Processor compatibility" box would make a difference and I can't reproduce the same symptom with my test VMs".

Ktoś może powiedzieć - OK, błąd, pomyłka ludzka, normalna sprawa, zdarza się...

Czy jednak normalne jest, że przez 16 miesięcy nikt nie potrafi / nie chce dojść do tego, co trapi niezłe skądinąd narzędzie? (żeby nie było wątpliwości: link)

Jak dla mnie słowa "I'm afraid it can not be resolved soon" (przewijają się w całym wątku) potwierdzają, że odpowiedni zespół może być zbyt mały.

I teraz dochodzimy do tematu Windows i tego, że "Jednolity interfejs powstaje w bólach".

Kolejne wydania tego systemu przez lata wprowadzały wiele fundamentalnych nowości - fonty True Type, ochrona pamięci, obsługa 64-bitów, NTFS, DirectX, itd.

Dziesiątka to historia zupełnie inna - obarczony brzemieniem kompatybilności kod, nie do końca z wydzielonymi warstwami, potrafi sprawić problemy na bardzo różnych platformach. Owszem, są pewne próby dodawania nowych funkcjonalności (chociażby HyperV czy podsystem Linuxa), ale... wiele elementów systemu nie jest ruszane od lat.

Czytałem na ten temat jakości MS wiele teorii - że rozwiązywano zespoły testerskie (i testowanie jest robione wyłącznie na maszynach wirtualnych), że starsi inżynierowie (którzy naprawdę znali technologie użyte do pisania Windows NT) już nie pracują, itp.

Na pewno głośno było o pani Donie Sarkar i jej udziale w programie Windows Insider.

image

Ja jako osoba z zewnątrz widzę kilka rzeczy:

  • Windows ma (zbyt) duży bagaż kompatybilności - ogromnym problemem jest nawet to, że z systemu będzie usuwany archaiczny IE
  • Dla każdego pracownika MS lepiej jest wspierać to, co przynosi sukces, czyli dodawanie nowych funkcjonalności (niż ich zmianę, co może spowodować problem z kompatybilnością)
  • Firma MS jest firmą amerykańską - "rozkazy" przychodzą z góry, a jaka sytuacja jest w US, to widać (Donald, wirus, BLM, mniejszości, etc. - w tej sytuacji dużo pracy przejmują ludzie z zagranicy, którzy niekoniecznie są z największym doświadczeniem)
  • Firma MS realizuje strategię narzuconą przez CEO - proszę zauważyć, że za czasów Gatesa mieliśmy dużo rewolucji, za czasów Ballmera już jakby dużo problemów, a obecna strategia to taki miks wszystkiego (a w obszarze Windows dodawanie dużo rzeczy)
  • Dużo się mówi o kiepskiej sytuacji w krzemowej dolinie (choćby z uwagi na sytuację w USA, ale też problemy z wizami)

Myślę, że tak naprawdę projekt nowego interfejsu Windows toczy się siłą rozpędu. Owszem, pewne elementy będą zrobione, bo ktoś się chce wykazać... ale tak naprawdę nikt nie ma silnej motywacji, żeby obecny Windows NT był lepszym systemem.

Gdzie jest chociażby ReFS?

Nie oszukujmy się - świat poszedł w kierunku totalnego odseparowania aplikacji (a nie wrzucania wszystkiego nawet do katalogu z systemem) i triumfy śledzą małe i odseparowane od siebie programy (Microsoft przeniósł to na desktop o wiele gorzej niż widgety w Viście).

Siłą systemu Windows są pewne aplikacje np. w firmach (i gdyby przestały działać, to automatycznie byłby to jego koniec), DirectX i gry, nikt za to nie chce już nawet Active X (OK, jest jeszcze w zastosowaniach korporacyjnych).

Firma nie ma pomysłu, a oddzielne rozwiązania nawet we własnych produktach (oddzielny update w Edge i Office) pokazują, że zespoły niezbyt współpracują ze sobą.

Przykład raportu dotyczącego HyperV udowadnia mi tylko, jak daleko to zaszło.

Ale... żeby nie było, że to Microsoft jest zły. 

Błąd https://bugs.chromium.org/p/chromium/issues/detail?id=118639 został zgłoszony 16 marca 2012 i dotyczył tego, że zdarzenia keydown i keyup w przeglądarce Chrome na Android zgłaszają keyCode równy zero (zawsze).

Od słowa do słowa okazało się, że problem występuje m.in. wtedy, gdy używana jest klawiatura GBoard.

Ostateczna odpowiedź zespołu Google - to nie będzie naprawione.

Czyli mamy system Android (gdzie Google jakby gra decydującą rolę), mamy klawiaturę GBoard i przeglądarkę Chrome i decyzja jest taka, że coś nie zostanie zrobione zgodnie ze specyfikacją.

Oczywiście w przedstawionym wątku jest masa uzasadnień, jakie to nienowoczesne używać tych zdarzeń, itp.

Pójdźmy dalej - w https://bugs.chromium.org/p/chromium/issues/detail?id=962309 dnia 12 marca 2019 zgłosiłem sugestię, że w okienku historii Chrome warto dodać możliwość zwijania / rozwijania poszczególnych dni. 

Został przedstawiony patch na kilkanaście linijek (do autorów kodu) i... wszyscy nabrali wody w usta.

Nie, bo nie.

https://bugs.chromium.org/p/chromium/issues/detail?id=959657 z 5 maja 2019 to prosta zmiana napisu w ustawieniach Chrome...

Wymieniać możbaby długo, ale wisienką na torcie jest kilkakrotne wydłużenie kompilacji Chrome (w moim wypadku to była zmiana 1h w 4h), co oczywiście wiąże się ze stratą energii i czasu i widocznym wpływem na środowisko naturalne, bo Chrome kompilowany jest tysiące razy dziennie w wielu miejscach na świecie.

image

W kontekście takiego podejścia do spraw jakoś mnie nie dziwi fakt, że usługi Google nie działały w ostatni tygodniu... przy okazji odnajduję wiele analogii z Microsoftem i zadaję sobie pytanie retoryczne: czy naprawdę ktoś wierzy, że duopol na rynku przeglądarek (Safari / Chrome) NIE będzie hamulcem?

Na pewno w obecnej sytuacji żaden manager nie zgodzi się np. na przepisanie Chrome na Kotlina albo zrobienie od nowa w sposób zupełnie modułowy (za dużo zasobów, za mało zysków). Myślę, że Mozilla miała swoją wielką szansę, ale jej Servo wygląda mi na wielki monolit, gdzie chciano zrobić za dużo na raz.

Muszę też przyznać, że w opisywanym obszarze trochę lepiej zachowuje się ostatnia wspomniana firma / fundacja - oni w przypadku Firefox Preview z rozbrajającą szczerością przynajmniej przyznają, że mogą odrzucać jakikolwiek kod (co zresztą stało się w moim wypadku i myślę, że związane było z brakiem zasobów).

To jak? Ktoś jeszcze wierzy, że ten nowy interfejs w Windows to taka skomplikowana sprawa? (śmiem twierdzić, że każdy duży projekt w IT powstaje w bólach, ale tu jakby chodzi o coś innego, co właśnie pokazałem) I czy kogoś to jeszcze w ogóle interesuje?

PS. Dodajmy do tego oczywiście obecność kolejnych pokoleń inżynierów, którzy w takich firmach również chcą się wykazać i często i gęsto proponują technologie "świeże". I testowanie na najdroższych użytkownikach, co dobitnie pokazało Adobe z Lightroom.