Witaj na Forum Linuxiarzy
Zanim zalogujesz się, by pisać na naszym forum, zapoznaj się z kilkoma zasadami savoir-vivre'u w dziale Administracja.
Wiadomości z problemami zamieszczone w wątku "Przywitaj się" oraz wszelkie reklamy na naszym forum będą usuwane.

Dystrybucja dla początkującego linuksiarza.

Zaczęty przez dayashita23, Listopad 20, 2019, 01:56:21 AM

Poprzedni wątek - Następny wątek

pavbaranov

Ta... i tak wyłącznie debowe. W sumie dość dobrym wyborem (nie tylko "na początek") może okazać się OpenSUSE. Od debowych na pewno ma lepszy audyt paczek.

Piotr_1988

@MSki - mi Ubuntu też lubiło niewstawać i to bez aktualizacji. Wieszało się, trzeba było przyciskiem wyłączać i już nie wstawało. Wtedy trzeba było uruchomić wersję live z pendrive i użyć fsck. Nie znam się na tyle, by naprawiać takie rzeczy w Ubuntu, także od dziś cieszę się MX Linux. Piszesz jednak, że "szukanie właściwego distra należy rozpocząć od oglądu Kernela - od wersji 5.3 wzwyż." tymczasem na MX jest kernel 4.19.0-6-amd64. Zastanawiam się, czym go zastąpić i czy faktycznie jest taka potrzeba, by zastępować... Widziałem jakieś niepochlebne recenzcje Liquorixa, także zastanawiam się nad antiX 5.2.21 kernel Meltdown and Spectre patched lub Debian 5.4 mx test.
Fedora Silverblue  |  Rocky Linux  |  NomadBSD

pavbaranov

OT: (Sorry, bo robi się w tym wątku misz-masz, a zatem raz ostatni OT z mojej strony):
@Piotr_1988 - Niczym. Kernel 4.19 jest LTSem ze wsparciem do grudnia br. Jeśli wszystko Ci działa jak powinno, to niczym nie musisz go zastępować. Jeśli już, to z obecnych można polecić 5.4 (bo LTS - wsparcie do 12.2021) lub jakikolwiek "bieżący" (obecnie to 5.5.x) i po przejściu w EOL przesiadka na 5.6 itd. Meltwon i Spectre od dawna są już zalatane i to całe wieki przed wersją 5.2. (który również jest EOL). 

MSki

Sprawę Kernela należałoby oczywiście pominąć w rozważaniach tego tematu, gdyż pobierając z sieci obraz iso, pobieramy zazwyczaj jego najnowszą wersję, lub wersję LTS, którą wyposażono we względnie nowy Kernel.. dlatego napisałem o 5.3 wzwyż.. zapominając o LTS-ie -> 4.19
I tak się dziwnie składa, że Ubuntu 18.04.4 posiada Kernel 5.3 zapożyczony z wer. 19.10 Ubuntu.

Nieśmiało zapytam, bo tego jakoś nie potrafię zrozumieć;
Czy wraz zakończeniem wsparcia dla Kernela 5.3 (EOL) deweloperzy opiekujący się wydaniem LTS 18.04.4 spowodują, że wśród pakietów aktualizacyjnych system znajdzie się Kernel w wersji 5.4 lub w jeszcze wyższej wersji ?
Czy użytkownik, tej wersji Ubuntu, zmuszony będzie "ręcznie" dokonywać zmian Kernela ?

pavbaranov

#34
Cytat: MSki w Luty 15, 2020, 09:50:57 AM
Nieśmiało zapytam, bo tego jakoś nie potrafię zrozumieć;
Czy wraz zakończeniem wsparcia dla Kernela 5.3 (EOL) deweloperzy opiekujący się wydaniem LTS 18.04.4 spowodują, że wśród pakietów aktualizacyjnych system znajdzie się Kernel w wersji 5.4 lub w jeszcze wyższej wersji ?
Czy użytkownik, tej wersji Ubuntu, zmuszony będzie "ręcznie" dokonywać zmian Kernela ?
Znów się zrobił OT, ale niech tam mi wybaczone zostanie.
O EOL mówi się w odniesieniu do kerneli z https://kernel.org. Masz tam tabelkę prezentującą aktualnie wspierane przez zespół pracujący nad ich rozwojem (upstream) kernele. Co jakiś czas możesz tam zobaczyć owe EOL przy jakimś kernelu - oznacza to, że ta linia kernela przez upstream nie jest już dalej rozwijana (potem już ten kernel nie jest widoczny w tabelce, tak jak to ma miejsce np. ze wszystkimi kernelami z linii 5 niższymi niż 5.4.
Każda z linii kernela otrzymuje swoje wydania poprawkowe, które zawierają:
- ewentualne łatki bezpieczeństwa,
- łatki poprawiające funkcjonalność, ale tylko i wyłącznie w ramach tej funkcjonalności, która została wdrożona w jego wydaniu oznaczonym trzecią cyfrą 0,
- łatki usuwające dostrzeżone błędy (regresje, wadliwie wdrożone nowe funkcjonalności itp.).
W danej linii kernela raczej trudno się spodziewać jakichś dodatkowych funkcji, które zostały zaimplementowane w "wyższej" linii, ani też nie zostaną usunięte jakieś funkcjonalności, które w tej "wyższej" linii zostają usunięte (niekiedy tak się dzieje). Innymi słowy - taki nadal wspierany kernel 4.19.104 zachowuje funkcjonalność kernela 4.9.0 (tej trzeciej cyfry nie musi tu być), ale otrzymał już 104 poprawki, które wprowadziły jakieś zmiany w zakresie owych 3 punktów wymienionych wyżej. Nie zawiera natomiast żadnej "nowości", która została wprowadzona w kernelach wyższych niż 4.19. Stąd też np. jeśli jakieś urządzenie jest obsługiwane dopiero w kernelu 5.4, to pomimo tego, że 4.19 nadal jest wspierany i rozwijany, raczej nie możesz się spodziewać, że zmiana ta wprowadzona zostanie do niego. Z chwilą utraty wsparcia przez upstream dana linia kernela jest porzucana, czyli upstream już nie zajmuje się jej rozwojem, nie otrzyma ona żadnych poprawek i to nawet jeśli chodzi o poprawki bezpieczeństwa.
Na to nakładają się deweloperzy poszczególnych dystrybucji, którzy mogą zdecydować się na próbę samodzielnego rozwoju jakiegoś kernela. Tak się dzieje w przypadku Canonicala. Pomijając pewne kwestie związane z ewentualnym dostosowywaniem upstreamowego kernela do własnych potrzeb tej dystrybucji, zasadniczo zobowiązują się oni przed użytkownikami do tego, że - po przejściu upstreamowego kernela w stan EOL - przynajmniej poprawki bezpieczeństwa, które pojawią się w nowszych liniach zostaną wprowadzone. Niekiedy również zostaną wprowadzone jakieś inne jeszcze łatki związane z naprawą jakichś funkcjonalności (poprawkami błędów) oraz - rzadko - zaimplementowane zostaną jakieś nowe funkcjonalności z nowszych linii (to ostatnie bywa również robione w przypadku tych kerneli, gdy kernel jeszcze nie ma statusu EOL).
Niestety nie zawsze uda się nałożyć łatkę z nowszych linii kerneli na starszą już niewspieraną linię, a niekiedy nie jest to takie proste i wymaga innych jeszcze zmian w kernelu, które nie polegają wyłącznie na zrobieniu zwykłej "synchronizacji" (nie wiem jak to nazwać, po angielsku to sync i mniejsza o to jak się to robi, po prostu dość łatwo w ten sposób uzyskać gotową łatkę, którą można nałożyć).

Streszczając:
1. Dopóki określona linia kernela występuje w danej dystrybucji, to teoretycznie deweloperzy tej dystrybucji biorą odpowiedzialność za to, że nawet po przejściu tego kernela w stan EOL, nadal będą do tego kernela dodawać przynajmniej łatki bezpieczeństwa.
2. Jeśli dalsze łatanie tej linii kernela nie będzie już możliwe, to powinni dokonać zmiany kernela w swej dystrybucji na nowszą wersję.
I tu koniec suchego "wykładu", ale nie byłbym sobą, gdybym kilku groszy nie dopowiedział. O ile mam jakieś zaufanie (i to spore) do deweloperów upstreamowego kernela, w tym przede wszystkim do Linusa i do Grega, to z zaufaniem do opiekunów kerneli w różnych dystrybucjach mam problem i mieszane uczucia. Tym mniejsze to zaufanie jest im w mniejszym stopniu dana dystrybucja ma osób opiekujących się kernelem, wypracowane narzędzia kontroli paczek (audytu, w tym kernela), a przede wszystkim, jeśli ci opiekunowie (jak i cała zresztą dystrybucja) nie uczestniczą mniej lub bardziej aktywnie w rozwoju upstreamowego kernela. Owe zaufanie się zmniejsza również, gdy ewentualny aktywny udział jest próbą wymuszenia na upstream zmian w kernelu dostosowanych pod kątem wyłącznie danej dystrybucji. Kompletnie nie mam zaufania zaś do małych, sforkowanych dystrybucji. Rolą każdego jest ocena swego zaufania wobec deweloperów dystrybucji, którą wybrał, a która oferuje oprogramowanie, w tym kernele, po ukończeniu ich wsparcia. U mnie jest ono praktycznie w każdym przypadku niskie już choćby z tej przyczyny, że o ile przy nadal wspieranym kernelu, zauważywszy jakiś błąd mogę liczyć na to, że po jego zgłoszeniu błąd taki zostanie usunięty, to w przypadku kerneli EOL jedyne wsparcie, które mogę otrzymać jest od deweloperów dystrybucji. Na ile można liczyć na to, że ów dostrzeżony błąd zostanie poprawiony przez nich we własnym zakresie, w sytuacji, gdy nie biorą oni aktywnego udziału w rozwoju kernela - sam sobie odpowiedz.

W moim absolutnie prywatnym rankingu owego zaufania, Canonical w tej stawce mieści się gdzieś powyżej średniej - i to nawet sporo, ale do obdarzenia ich pełnym zaufaniem sporo jeszcze (spośród innych dystrybucji w tym wątku - do Minta zaufania nie mam wcale, w Sparky problem zasadniczo nie istnieje, Fedora - spore, a w przypadku MX po prostu nie wiem). Zdecydowanie wyższe mam zaufanie do Red Hat (a co za tym idzie do CentOS) czy OpenSUSE. Podkreślam, to moja, prywatna opinia, na której rozwinięcie na pewno nie ma miejsca w tym wątku, tak jak i na podjęcie jakiejkolwiek dyskusji w tym zakresie.

Mam nadzieję, że wytłumaczyłem, a nie zagmatwałem.

MSki

Bardzo Ci dziękuję za ten wykład i za chęci pisania, oraz dzielenia się wiedzą, której (mówię za siebie) nie wszyscy posiadają :)
To o czym piszesz, jest bardzo cenną i jednocześnie pouczającą informacją, przybliżającą w znacznym stopniu reguły rządzące w Linuksie.
Chyba nie tylko ja korzystam na czytaniu tego typu wykładów(?), których w sieci wciąż w potocznej i zrozumiałej formie za mało.
Pozdrawiam serdecznie.

Zobacz najnowsze wiadomości na forum