Blog (92)
Komentarze (104)
Recenzje (0)
@marcinw2Hey Joe! Potrzymaj mi piwo - dlaczego w Polsce nie ma własnych OS ani przeglądarek ani większych pakietów?

Hey Joe! Potrzymaj mi piwo - dlaczego w Polsce nie ma własnych OS ani przeglądarek ani większych pakietów?

20.04.2020 | aktual.: 20.04.2020 21:15

Dzisiaj wpis typowo blogowy, czyli o mentalności różnych ludzi i jak to się przekłada na IT.

Zacznijmy od klasycznego

"Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :‑)

Linus (torvalds@kruuna.helsinki.fi)

PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT‑harddisks, as that's all I have :‑(."

Powyższy tekst to oczywiście cytat z https://groups.google.com/forum/#!original/comp.os.minix/dlNtH7RRrGA/S...

Podobne podejście mają ludzie w wielu części świata:

  • Hey Joe! You can't do it. No, I can't? Take my beer. Ameryka great again!
  • Good morning Sir. I need this and this. Can you do it? Yes Sir, we can do it. We can do everything (tu niestety często i gęsto wychodzi odwrotnie niż powinno, ale to już temat na inny artykuł...)

Dlaczego o tym piszę?

W moich czasach (wiem, jak to brzmi) wielu młodych ludzi narzekało, że uczelnie polskie są na niskim poziomie... że siedzi tam masa teoretyzujących profesorów, którzy nie potrafią odnaleźć się na rynku (co nie zawsze było prawdą, ale wyjątki potwierdzały regułę).

Od czasu do czasu piszę różne narzędzia i widzę, że ta tendencja niestety dalej wylewa się na rynek, na którym (zbyt) wiele razy słychać: Nie da się. Za długo. Za trudne. Za mniej niż 15K nie ruszam. Lepiej skorzystać z gotowych rozwiązań (w domyśle: zrobionych przez kogoś)

Dużo Januszy Nosaczy chce przyjść na gotowe (hehe, przyjdę, wezmę, pójdę, hehe) albo czuje radość w krytykowaniu (nie mówię o konstruktywnej krytyce) - stąd zapewne posty pewnego pana, który poniekąd ma rację wytykając problemy na styku różnych kombinacji sprzętu i pewnych otwartych rozwiązań (i tak żywiołowa odpowiedź na nie).

Mnie w takich wypadku zawsze nachodzi pytanie: a gdzie nie ma błędów? Mac OS jak i Windows jak i Linux najlepsze są do określonych zastosowań, a każdy z nich ma swoje odchyłki od normy. Życie.

Ja jakoś jestem w stanie każdy z tych systemów skonfigurować i robić na każdym z nich cuda i cudeńka, szkoda, że jechanie po jednym z tych systemów na DP tak mocno karmi trolling.

W swoim poprzednim poście napisałem jasno o MileStone 2 projektu Sobieski+:

"Na pewno pierwsze kamienie milowe nie są doskonałe (kod bywa długi, nie ma opisów, nie wszystkie warstwy middleware są wydzielone, itp.), ale nie taka ich rola"

i celowo dodałem tytuł

"Jeden uparty kaleczy JavaScript"

Przedstawiłem sprawy jak są i nie próbowałem wciskać takiego kitu, jak ten o jakości pewnych programach "edukacyjnych" z TV.

Bardzo mnie ucieszyły wszystkie komentarze - generalnie napisane w sposób grzeczny i rzeczowy.

Zastanowiło mnie kilka rzeczy:

  • tylko jedna osoba zapytała się "akceptujesz PR? Może mógłbym coś pomóc w pisaniu"
  • w praktyce tylko jednak osoba otwarcie napisała "nie przejmuj się opiniami o niskiej jakości kodu"
  • sporo osób wskazało rzeczy oczywiste (takie jak mieszanie nazw polskich i angielskich, itp.) - zostało to napisane w dobrej wierze, ale poniekąd wskazało niezrozumienie mojej intencji (napisane wpierw całości kodu, przygotowanie architektury, itp. i dopiero później szlifowanie poprawności kodu)
  • dużo osób zaczęło trochę teoretyzować - zostało to napisane w dobrej wierze, ale pokazało pewną odtwórczość, może przywiązanie do tego, co gdzieś kiedyś jakiś autorytet napisał

Widać tu pewną mentalność - brak chęci praktykowania (OK, CMS to nie jest temat dla każdego), ale też dużą chęć czy potrzebę teoretyzowania.

Myślę, że w wielu częściach świata reakcja mogłaby być trochę inna - zamiast teoretyzowania/narzekania pytanie byłoby jedno: jak mogę pomóc?

Sporo projektów informatycznych zaczyna od prototypów (które pisane są tak, żeby być "feature complete" i pokazać, na ile dana technologia się nadaje), potem nachodzi faza szlifowania kodu, dopisywania dokumentacji, tysięcy testów, robienia ładnego GUI, dodawania nowych feature, itp.

Sobieski zatrzymał się pomiędzy pomiędzy fazami (wiadomo, projekty sobie, a życie sobie), Sobieski+ jest gdzieś pomiędzy etapem jeden i dwa.

Pójdźmy dalej - dużo programistów czy też "programistów" krytykujących Open Source jedzie po nich jak po burej kobyle, ale nie bierze w ogóle pod uwagę, że standardy użyte w projektach zamkniętych mogą być o niebo gorsze... ale te projekty wygrywają, bo są używane (nie dlatego, bo są lepsze).

Czy Windows 3.1 był naprawdę tak niezły jakościowo? A 9x? A Windows XP przed SP2?

Pytanie do wielu z was (niekoniecznie osób, które mnie komentowały): czy naprawdę dalej będziecie mówić, że każdy kod w wielkiej firmie jest od linijki?

Proszę bez hipokryzji mi tu.

Wielu z was pracuje w korpo i zna realia, w których dużą rolę odgrywa outsorcing, czyli w praktyce pisanie za najniższą możliwą stawkę (często przez "programistów" z egzotycznych krajów).

Albo w drugą stronę - czy myślicie, że w Google czy innej firmie nie wyciskają z technologii ostatnich soków i zawsze piszą zgodnie z best practises? Że nie robią różnych tricków, żeby coś chodziło szybciej?

Do czego prowadzi przesadne teoretyzowanie, widać na przykładzie projektu Servo Mozilli - miało być pięknie, strukturalnie, szybko i w ogóle miodnie, a po iluś latach developmentu jest masa kodu, ale działającego tragicznie (i napisanego nieczytelnie albo ze wstawkami z innych języków).

Widać to też na przykładzie różnych projektów rządowych (najczęściej oczywiście w klasycznym V‑modelu) - jest przetarg, masa dokumentacji, specyfikacji, potem jeden sztywny kod i "lessons learnt" (a nie powinno być, że programiści robią ileś prototypów, proponują najlepsze rozwiązania, są elastyczni? Weźmy przykład na przykład z Czech z systemem do winiet).

Kiedyś mieliśmy TAG, MksVir i dużo innych własnych projektów, obecnie na pewno mamy fachowców (którzy potrafią w nocy o północy wykazać, że danym języku var jest do tego, a const do czegoś innego), ale pracują na garnuszku firm z zagranicy... bo nie mają czasu, nie chce im się, itp.

Zaczynałem od kodowania w C i assemblera i siłą rzeczy kod bywał średnio czytelny, teraz praktyką jest np. rozdrabnianie wszystkiego na klasy ("bo to jest zgodne ze wzorcami projektowymi"). Widywałem już sytuacje, że jedna generyczna klasa była dziedziczona w ośmiu plikach, w których było po kilka linijek kodu i kilkadziesiąt z nagłówkami Copyright (1091753).

To "upraszczanie" kodu dochodzi w różnych wypadkach dochodzi do absurdu, generując samych klepaczy zamiast inżynierów (nie zmienia to oczywiście faktu, że jakość kodu Sobieski+ będzie poprawiana w kolejnych MileStone).

Bo ja panie nie siadam do czegoś, co ma tysiąc linii...

Ogromnie dziękuję za wasze komentarze. Będą stopniowo uwzględniane. Są cenne, ale też pokazują w niektórych miejscach "profesorskie" podejście, które różni się od mojego "Hey Joe".

Żeby była jasność - myślę, że najważniejsze jest znalezienie wyważonego podejścia między jakością kodu, a tym, żeby projekt w ogóle był i żeby był przydatny i żeby miał odpowiednią jakość.

Wolę napisać pięćset commitów przez pół roku i mieć działający schludny projekt niż pół roku czegoś tam próbować i napisać raz, a dobrze "zgodnie ze sztuką" (nie zmienia to faktu, że na produkcję pewne kiepskie rzeczy u mnie nigdy nie szły i nie pójdą).

Jeżeli mam zastosować tu analogię, to można to trochę porównać do trenowania sieci neuronowej w oparciu o znane wzorce (związane z doświadczeniem, best practises, etc.).

Wolę też oglądać konkret (czyli np. działający commit udowadniający, że coś może być lepsze, szybsze, mniejsze) niż godziny teoretycznych dyskusji.

Powiem ogólnie, abstrachując od tego, co teraz robię: nie zabijajmy inicjatyw w zalążku. Wspierajmy projekty pisane z sercem i z myślą o ludziach. Nigdy nie miejmy postawy roszczeniowej.

Jeśli ktoś chce mieć zabawę i uczestniczyć w pisaniu plikowego CMS, zapraszam do tworzenia PR na GitHub albo przynajmniej do kontaktu. Jeśli ktoś chce zająć się moimi innymi narzędziami, zapraszam (kiedyś proponowałem chociażby otwarcie "Przepisów drogowych").

Na tym polega rozwój.

Jak mawiał Stephen King - ćwiczyć, ćwiczyć, ćwiczyć.

Jak się nie uda teraz, to za miesiąc :)

Teraz Polska!

PS. Tytuł jest celowo prowokujący - mógłbym oczywiście wykazać różne projekty rozpoczynane przez polskich programistów, takie jak Quebes OS

Wybrane dla Ciebie
Komentarze (19)