W ramach dzisiejszej edycji zastanawiamy się, czy istnieje coś takiego jak „język idealny”, porozmawiamy o reperkusjach usunięcia Dockera z Kubernetesa, a także z archeologicznym zacięciem przyglądniemy się kodowi źródłowego z roku 1995. Miłej soboty!
1. Dlaczego wciąż szuamy “lepszego” Rusta?
Zacznę od filozoficznego pytania… czy da się poprawić idealne?
Bo przecież Rust uchodzi za taki chodzący po ziemi ideał, a jednak w dalszym ciągu powstają nowe języki, próbujące ulokować się w jego niszy. Jednym z nich jest Hare, o którego premierze w zeszłym miesiącu miałem ochotę nawet napisać, ale stwierdziłem, że jest to kolejny język który trochę #nikogo. Jak się okazuje, Sylvain Kerkour, popularny rustowy blogger, postanowił się jednak nad nim pochylić i wykorzystać go jako pretekst do rozważań nad tym, w których miejscach Rust projektantom podwinęła się noga.
Okazuje się, że jest ich tak naprawdę całkiem sporo. Sylvain w swojej analizie wskazuje braki związane z biblioteką standardową, podejściem do modularyzacji, managerami pakietów czy nawet zarządzaniem pamięcią, z której Rust przecież słynie. Obrywa się również mocno podejściu do rozwoju języka i metodom jego zarządzania, zaśmiecaniu całości nadmiarowymi (zdaniem autor) funkcjonalnościami, które zaburzają oryginalną klarowność API. Także, ideałów nie ma, drodzy wierzący (zwykle nie praktykujący) wyznawcy kościoła pod wezwaniem Świętego Rust.
A jeśli lubicie tego typu ranty, to ostatnio pojawiły się również dwa duże dotyczące Go. Jeden z nich jest analizą krytyczną niedawno dołożonych do języka generyków, drugi zaś to już istne mieszanie z błotem, jednak dosyć konstruktywne. Nawet jeśli nie piszecie w tym języku, podobnie jak w przypadku Rusta dalej warto sobie moim zdaniem do powyższych tekstów zerknąć, pozwalają bowiem zrozumieć pewne kontrowersyjne decyzje designerskie twórców języka.
BTW: Podoba Wam się czytanie o Rust czy Go? Jeśli tak, już niedługo w Vived App będziemy mieli dla Was ważne ogłoszenie 😉 Stay Tuned.
Źródła
- The Hare programming language
- What a better Rust would look like
- Crimes with Go Generics – Xe
- I want off Mr. Golang’s Wild Ride
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Kubernetes ostatecznie pozbywa się Dockera
No i mamy nowe duże wydanie Kubernetesa. Po “Ostatniej Granicy” (bo tak nazywało się wydanie 1.23 z grudnia) dostajemy “Obserwowacza Gwiazd”. Jest to wydanie naprawdę duże, ponieważ… wraz z nim Kubernetes ostatecznie pozbywa się Dockera. Zmiana zapowiadana była od lat, ale podejrzewam, że z programistami jak z drogowcami końcem roku, także spieszę wytłumaczyć o co chodzi.
Żeby zrozumieć na czym polega problem, niezbędne jest zerknięcie nieco pod maskę tego jak działa konteneryzacja w 2020. Zarówno Kubernetes, jak i Docker (a także każde inne narzędzie działające z kontenerami) posiada środowisko uruchomieniowe, pozwalające na wykonywanie dostarczonych obrazów. Kubernetes przez lata wspierało zarówno swój standard (CRI-O) jak i Dockerowy (containerd). Problem polega na tym, że Docker jest rozwiązaniem przeznaczonym do obsługi przez człowieka, przez co posiada sporo nadmiarowych funkcjonalności. Do tej pory Kubernetes je emulowało, wraz z wersją 1.20 rozpoczął się proces ich porzucania – całość zakończyć się miała wraz z wersją 1.22, w drugiej połowie 2021… ale całość się spóźniła o calutki rok.
Mamy zatem bardzo dobry przykład tego, jak zbawienną rzeczą są standardy. Docker może pozostać narzędziem używanym w developmencie lokalnym, zaś na Kubernetesie wygenerowane obrazy będą uruchamiane po prostu na ich własnym runtime. Jeżeli jesteście ciekawi rozszerzonej historii tak zwanego dockershimu, całość znajdziecie pod tym linkiem.
Jednak Kubernetes 1.24 to nie tylko ostateczne pozbycie się Dockera. To również możliwość rozszerzania podpiętych wolumenów bez downtime, Nowy Kubernetes to także testowe wsparcie formatu OpenAPI v3, a także kryptograficzne podpisywanie artefaktów wypluwanych przez Kubernetesa, co ma zwiększyć bezpieczeństwo i podatność na ataki supply-chain. Takich mniejszych i większych zmian jest więcej, ale to już pozwolę sobie odesłać Was do pełnych release notes.
Źródła
- Kubernetes 1.24: Stargazer
- Kubernetes 1.24: Volume Expansion Now A Stable Feature
- Updated: Dockershim Removal FAQ | Kubernetes
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Kod źródłowy Windows 3D Movie Makera trafia na GitHuba
A na koniec, po bardo przyziemnym opracowaniu Kubernetesa, teraz odjedziemy w kosmos i zajmiemy się niesamowitym prezentem od Pana Microsofta.
Każdy użytkownik Windowsa kojarzy pewnie program Windows Movie Makers, powstałą w 2000 roku aplikacje do domowego montażu wideo. Niewiele osób zdaje sobie jednak sprawę (min. ja jeszcze tydzień temu), że tak naprawdę jest to już kolejna aplikacja pod tą nazwą. Już w 1995 roku Microsoft wydał bowiem… 3D Movie Makera. Była to aplikacja przeznaczona dla dzieci, która pozwalała na przygotowywanie prościutkich filmików w 3D. Niestety, pojawiła się jeszcze w czasach przed YouTubem, więc świat o niej zapomniał. Wyobrażam sobie jednak alternatywną rzeczywistość, gdzie świat machinim poszedł zupełnie inną, alternatywną ścieżką.
Dlaczego o tym piszę? Ponieważ w zeszłym tygodniu Microsoft wypuścił cały jego kod źródłowy do internetu. Stanowi on uroczy artefakt czasów w których powstał i społeczność, która zaczęła rozkładać go na czynniki pierwsze znalazła sporo ciekawych kwiatków. Moim ulubionym kawałkiem programistycznej trivi jest informacja, że programiści preferowali kiedyś jednoliterowe zmienne bo… rozdzielczość monitorów była mała i pozwalało im to po prostu oszczędzić miejsce w linijce. Podobnych ciekawostek jest sporo, dlatego polecam powiązane z repozytorium wątki Redditowe i HackerNewsowe.
A na zakończenie, jak już pozostajemy w świecie Windowsa – ktoś próbował napisać grę na nowy Windowsowy Terminal i okazało się, że wydajność narzędzia dramatycznie spada w momencie użycia dwudziestego pierwszego koloru. Dlaczego? Jeżeli jesteście ciekawi, to twórcy oprogramowania wzięli sobie zgłoszenie na poważnie i zrobili naprawdę ciekawą analizę problemu.
BTW: Dawno i nieprawda: Przez krótki czas bawiłem się w pisanie serii, podczas której brałem “na warsztat” trendujące repozytoria githubowe i robiłem im review, próbując zrozumieć, jak działają pod spodem. Dajcie znać, jeśli ktoś miałby ochotę na powrót takiej serii, może w trochę luźniejszym formacie 😉 Czasem korci mnie, żeby do tego wrócić.
Źródła
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
