Repo Linusa Torvalds w którym pisze, że jest wywajbkodowane.
Also note that the python visualizer tool has been basically written by vibe-coding. I know more about analog filters -- and that's not saying much -- than I do about python. It started out as my typical "google and do the monkey-see-monkey-do" kind of programming, but then I cut out the middle-man -- me -- and just used Google Antigravity to do the audio sample visualizer.
Gdyby mi ktoś powiedział 16 lat temu, że będzie tak popularny to chyba bym nie uwierzył. Pamiętam jak ja trzymałem programy na studia w git a inni w svnach i cvsach
Szczerze, uważam że IT potrzebuje więcej takich ludzi jak Linus. Czasem mam wrażenie, że 95% branży to stado płatków śniegu, którzy potrafią się obrazić po code review.
Aha, za to ja się zwykle spotykałem z code review który był walką o pierdolety, nijak nie mającą się ani do poprawności, ani do wydajności, ani do czytelności. No ale coś trzeba przecież zgłosić a próba zrozumienia czyjegoś kodu wymagałaby wysiłku.
@pierdonauta_kosmolony Ja również widziałem kłótnie o nazwy zmiennych oraz porównywanie długości penisów. Kluczem jest balans oraz jasne zasady. Dodatkowo, zwykle pomaga jeśli reviewerów jest dwóch.
Ten czlowiek powinien dostac nobla. Napisal linuxa i git'a. Jestem bardzo ciekawy jakby wygladal swiat bez linuxa. Czy znalazlby sie ktos kto napisalby cos lepszego? Moze IBM albo SUN w czasach swojej swietnosci?
Linus to mocny gość. Szkoda, że nigdy nie przewodził w stworzeniu jakiejś dystrybucji bo wg mnie ma ostre zasady i wielokrotnie uratował userspace przed zmianami w kernelu, które popsułyby istniejące aplikacje.
@Dzemik_Skrytozerca To nie są komentarze samego Linusa tylko wszystkich maintainerów. Jako, że to jest GIT to można łatwo sprawdzić kto jest autorem każdej linijki. Btw niektóre te komentarze mają po 20 lat xD.
Jakiś tydzień temu trafiłem na info, że Linus Torvalds (twórca i główny opiekun #linux )
w prywatnej korespondencji zapowiedział, że zaakceptuje kod napisany w Rust, nawet pomimo sprzeciwu opiekunów. Zaskakująca zmiana stanowiska może otworzyć drogę do poważnych reform w strukturze jądra systemu, ale jednocześnie rodzi pytania o przyszłość społeczności rozwijającej system.
Było to o tyle dziwne, że
jeszcze niedawno Torvalds publicznie opowiadał się przeciwko wdrażaniu języka Rust do jądra Linuxa, podkreślając, że system działa znakomicie w C i nie ma potrzeby wprowadzania tak radykalnych zmian. Jego komentarze były surowe i jasno wskazywały na brak akceptacji dla nowego języka w tak kluczowym komponencie oprogramowania.
Jądra systemu napisanego jedynie w języku C bronił jeden z głownych opiekunów Christoph Hellwig:
Hellwig, nie kryjąc oburzenia, po raz kolejny porównał Rust do "nowotworu", który może zagrozić stabilności jądra Linuxa. Podkreśla, że dodanie wsparcia dla innego języka może prowadzić do chaosu i fragmentacji kodu. „Nieustanna rotacja pomiędzy różnych językami to największy koszmar każdego administratora kodu” – stwierdził Hellwig.
Christoph Hellwig, jeden z kluczowych opiekunów jądra systemu, który znany jest ze swojego zdecydowanego sprzeciwu wobec implementacji języka Rust w jądrze Linuksa, zrezygnował z funkcji opiekuna odpowiedzialnego za dma-mapping.
Christoph Hellwig od lat jawnie krytykował wprowadzanie Rusta do kodu jądra Linuksa, nazywając go „rakiem” i podkreślając, że jego obecność rozprzestrzenia się jak „przerzuty” po całym systemie. Hellwig, zagorzały zwolennik języka C, uważał, że to właśnie C zapewnia większą stabilność i bezpieczeństwo kodu. Jego decyzja o rezygnacji z części obowiązków przyszła niespełna tydzień po tym, jak ujawnił treść prywatnej korespondencji z Torvaldsem, w której twórca Linuxa wyraził swoje zaskakujące poparcie dla języka Rust.
Co będzie dalej z Christophem?
Choć Hellwig zrzekł się części swoich obowiązków, nadal pozostaje aktywny w społeczności Linuxa. Wciąż pełni funkcje opiekuna sterownika NVMe oraz sekcji FreeVXFS. Jego odejście z obszaru mapowania DMA oznacza jednak, że Marek Szyprowski, drugi opiekun tej sekcji, będzie musiał samodzielnie przejąć pełną odpowiedzialność za ten kluczowy element infrastruktury Linuxa.
@Deykun dlaczego nie dziwi mnie że takie kwiatki występują właśnie przy dacie i czasie. Zakładam, że ktoś chciał znać przesunięcie czasowe względem UTC jak i konkretnej strefy czasowej (stąd system_timestamp i local_timestamp), ze względu na możliwe zmiany czasu w danej strefie czasowej. I może dowiemy się tego właśnie wtedy, kiedy kod będzie działać podczas zmiany czasu.
No ale to tylko moje domysły i nie mam zamiaru przez to nie spać po nocach ;)
@Dzemik_Skrytozerca flatpak jest spoko, ale działa tylko dla aplikacji GUI - nie jest kompatybilny z CLI. Snap tutaj jest lepszy, ale za to to mocno powiązany z Canonicalem i przez to scentralizowany. Appimage wydaje się być lepszą alternatywą, ale za to już przestarzałą bo musisz mieć narzędzia do aktualizacji "pakietów". Nie wiem czemu ale mam wrażenie, że to nadal nie są technologie, które zrobiłyby przełom i cały czas czekamy na alternatywę.
Warto popatrzyć jak zrobił to Google z Androidem. Jest apk, które jest podpisane cyfrowo więc ściągając z dowolnego miejsca można sprawdzić autentyczność. System zapewnia warstwę abstrakcji w taki sposób, że aplikacja napisana na androida 8 nadal będzie działać na najnowszym. Oczywiście to przez to, że Android ładuje w bootstrap pliki jar, które potrafią zapewnić bezpieczeństwo systemu - co w obecnym GNU/Linux nigdy nie było nawet rozważane. Nawet system obecnie zaczyna przechodzić na APEX, który ma jeszcze poprawić bezpieczeństwo oraz możliwość aktualizacji komponentów.
Szczerze? Mam wrażenie, że gdyby środowisko linuksowe pogodziło się z tym, że niektóre rzeczy wymagają zaorania i napisania od nowa to większość problemów dałoby się rozwiązać. Tyle, że to wymaga sporo pracy i chyba najlepiej byłoby skopiować rozwiązania za AOSP tak aby pasowały do desktopowych rozwiązań.
Tylko Linux foundation, Google, Canonical, RedHat i Suse są dość duże by zainwestować w odpowiedni development - bo nie ukrywajmy, coś takiego kosztuje i to sporo.
No niestety, poza Canonical nie widzę nikogo, kto coś robi w tym zakresie systemowo. A Canonical średnio się stara.
@radek-piotr-krasny Chłop bardzo specyficzny w obejściu, kontrowersyjny, no ale diablo inteligentny. Bardzo podoba mi się jego świadomość nt. burdelu w desktopowych dystrybucjach. Lubię jego bezpardonowe podejście do jakości - bez niego Linux nie byłby tak dobrym kernelem.
@KulturalnyLosPederasta kulturalnie się zapytałem czy mintaj obsłuży rozszerzony pulpit na dwóch lub więcej wyświetlaczach (wyjście HDMI + mini DP) 1szy to tv 4k HDR (domyślny do wyświetlania aplikacji pełnoekranowych), 2gi to monitor Full HD, a lapek to bieda edyszion wyntel 4 rdzenie z ht, 16gb ram, 2 X SSD i grafika low-force 1050 z 4GB RAM
@tomek tak na szybko zerknalem w neta. Z tego co przeczytalem to chodzi o konsole n64 i mozliwosc odpalenia na nim kernela. Moim zdaniem przerost formy nad trescia bo n64 ma ramu tyle co nic. Chociaz kto wie co napalency z tym zrobia. Moze jakies rozszerzenia do n64?