Różnice w światopoglądzie Manjaro i Archa

Kącik początkującego
1

Jestem zażenowany tą wypowiedzią. Arch32 jest nieoficjalną wersją tego systemu, nie jest w żaden sposób wspierana przez developerów Arch Linux, którzy zarzucili wsparcie dla tej architektury. Po drugie, instalujesz stary kernel 4.19 i nie czytasz o zmianach jakie należy podjąć - a o tym masz nawet informację na stronie głównej. W repo Archa nie ma żadnego kernela poniżej 5.9 (czyli od wersji, w której wprowadzono obsługę zstd) tak więc ciężko oczekiwać, by wspierali kernele, których nie mają w repo. To obowiązkiem użytkownika jest dostosować się pod aktualne paczki w systemie, nie na odwrót. Manjaro ma kernele poniżej 5.9 (ot choćby 5.4) i tutaj najprawdopodobniej domyślnym standardem pozostanie gzip, co rzecz jasna jest najbardziej logicznym wyjściem z tej sytuacji.

W tym wypadku topornością wykazał się użytkownik, który instalował system i nie sprawdził newsów na stronie głównej.

2

OffTopic - cd.
Pisząc w tym konkretnym przypadku o “toporności”, nie miałem na myśli tylko Archa32 ale ogólnie Archa i brak w nim wersji Live.
Uzupełniając moją wypowiedź, dlaczego Arch jest “toporny” w porównaniu do Manjaro, dodałbym także:

  • uciążliwość instalacji Archa,
  • brak w systemie przydatnych skryptów typu mhwd,
  • brak w systemie wygodnego graficznego pakietu do zarządzania oprogramowaniem typu Pamac,
  • brak w systemie wygodnego graficznego pakietu do zarządzania ustawieniami typu Manjaro Settings Manager,
  • brak w systemie możliwości posiadania kilku kerneli LTS,
  • brak wygodnych narzędzi do wygodnego (graficznego) zarządzania kernelami.
3

Arch nie jest systemem dla osób początkujących i nigdy nie będzie, stąd też nie można się w nim spodziewać takich ułatwiaczy. Graficzne menedżery zabiłyby jego filozofię i główne cechy. Gdyby było inaczej, distro pokroju Manjaro nie miałoby sensu - bo takim Manjaro byłby Arch.

Do jednego muszę się przyczepić.

Brednie, brednie, brednie. Można mieć w systemie tyle kerneli LTS, ile dusza zapragnie. Wystarczy je tylko skompilować.
Prawidłowo wysunięty argument powinien brzmieć: brak w repozytorium większej ilości kerneli LTS. Czy jest to wada? Z punktu widzenia użytkownika Archa odpowiem: nie. Jak czegoś potrzebuję, to sam to kompiluję.

Konkludując - Arch nie jest i nie będzie systemem przyjaznym dla osoby początkujących i za taką toporność stawiam ten system na piedestale. Dla osób bardzo początkujących bądź bardzo mało doświadczonych w Linuksie jak np. @majo jest właśnie Manjaro. Wilk syty i owca cała, równowaga w przyrodzie zachowana - każdy znalazł coś dla siebie i za to lubię open source.

4

I to jest dla mnie zdecydowane wskazanie na Manjaro, gdzie kernele są dostępne i nie trzeba ich kompilować (co jest toporną alternatywą, niepotrzebnie zajmującą czas).

Skomplikowany proces instalacji, ograniczona ilość kerneli i innych wymienionych i brakujących w Archu cech, wg mnie, nie kwalifikuje Archa do nazwania go “przyjaznym”.
I nie jest to tylko związane z wiedzą użytkownika, ale z brakiem wygodnych rozwiązań, ułatwiających pracę z systemem i oszczędzających cenny czas użytkownika.

Rozwijając twoją wypowiedź: “Jak czegoś potrzebuję, to sam to kompiluję”, można by było dojść do absurdalnego wniosku, że samem mogę kompilować wszystkie pakiety (i żadne nie będą potrzebne w systemie), a nawet, że samemu można sobie stworzyć system dla siebie. I oczywiście można to zrobić i niektórzy się tak bawią. Ja jednak wybieram wygodę i nie trwonienie czasu na ponowne wynalezienie koła.

5

@majo
Nie zgodzę się z Tobą że kompilacja kernela jest stratą czasu.
Od jakiegoś już czasu sam kompiluje sobie kernel linux-tkg przy pomocy modprobed-db
I zajmuje mi to około 25 minut, bo pewnie nie wiesz ale narzędzie modprobed.db służy do wyszukiwania modułów i jest zapisywane w .config/modprobed.db i na podstawie tej listy modułów jest budowany kernel, czyli jeżeli używasz GPU Intel to tylko to jest budowane, bez AMD i innych.

Druga sprawa nie wiem jak na Manjaro są kompilowane kernele, bo np. na Arch-u domyślnie timer_freq jest ustawiany na 300Hz, a ja podczas kompilacji ustawiam sobie na 1000Hz przez co jajo działa o wiele wydajniej.

Tak więc Twoje stwierdzenie ze samodzielna kompilacja kernela jest stratą czasu, jest błędne, ponieważ można dostosować kernel pod swój sprzęt.

6

Częściowo masz rację. Jednak wydaje mi się, że taka potrzeba ma faktycznie miejsce u bardzo nielicznej grupy użytkowników, u których może wystąpić jakiś problem/konflikt z ich sprzętem (plus tych, którzy chcą się czegoś nauczyć).
Natomiast absolutnej większości wystarczy to, co daje im system.

7

Kto Ci takich bzdur nagadał, że Arch to przyjazny system? Lub inaczej - wskaż mi choć jedną przesłankę, gdzie autorzy systemu stwierdzili, że Arch to distro user friendly. Na szczęście nie jest i na szczęście nigdy nie będzie. Na szczęście jest Manjaro i na szczęście to ono jest user-friendly.

W Manjaro masz wyłącznie stockowe kernele - natomiast nie zauważyłem, by były takie kernel jak ot choćby zen czy hardened, które niewątpliwie mają swoje plusy. Nie masz większej ilości ltsów, ale masz za to dużo większą różnorodność. Co kto woli. Dla mnie taki hardened to must-have i często z niego korzystam.

Ten fragment świadczy niestety o ignorancji i/lub braku wiedzy. Kto powiedział, że kompilowanie własnych pakietów musi być w jakikolwiek sposób kłopotliwe? Zdajesz sobie sprawę, że wystarczy jeden skrypt by przekompilować hurtowo wszystkie interesujące nas paczki i odbywa się to bez potrzeby ręcznej obsługi, np. w nocy? Też cenię sobie wygodę. Niestety, pewne pakiety muszę kompilować samodzielnie, bo wersje dostarczane w repo nie działają tak, jakbym sobie tego życzył. To jest absurdalne? Cytując klasyka - nie sądzę.

Tak, zgadza się. Ale równie dobrze można podzielić użytkowników na inne grupy:

  1. Zwykli użytkownicy - wystarcza im to, co daje system.
  2. Zwykli użytkownicy+ - żartobliwie nawiązując do nazwy pewnego programu - to co wcześniej, plus czasem kompilują program, którego potrzebują
  3. Użytkownicy, którzy chcą uczyć się systemu - tacy np. jak ja. Dzięki temu wiem, co jest pod maską, jak jest awaria - umiem sobie poradzić a nie prosić o pomoc i na nią czekać, jak niektórzy :wink: a także zdobywać doświadczenie. Dzięki temu, że kombinowałem i uczyłem się udało się je zdobyć i przekuć na pracę w branży. Można? Można. Strata czasu? Nie.

Ja nie mierzę wszystkich swoją miarą i wiem, że są osoby które mają takie zabawy gdzieś. Ich prawo. Porównywanie Archa do Manjaro to jak porównywanie jabłka do bananów. Nie ma to sensu. Każdy ma różne oczekiwania i pojęcie lepszości jest mocno subiektywne. Zalewa mnie mocno jak ktoś pitoli “Ale X jest lepsze od Y”. Nie - nie jest, to jest tylko i wyłącznie czyjaś subiektywna opinia, która przeważnie nikogo innego nie obchodzi. Każdy używa co mu pasuje i tyle w temacie, nie ma sensu tracić energii na czcze gadanie co jest lepsze a co gorsze, bo to co dla Ciebie jest zaletą Manjaro dla mnie jest wadą a to co dla Ciebie jest wadą Archa dla mnie jest jego najmocniejszą stroną. Ilu ludzi, tle opinii.

Ale to oczywiście nie oznacza, że jak ktoś głosi herezje, to nie będę próbował ich prostować - rzecz jasna kulturalnie :smiley:

8

Mnie w Archu bardzo przeszkadza częstotliwość pojawiania się aktualizacji. Za dużo tego. Za często.

9

Na tej zasadzie działa prawdziwy RR. Też używam Arch-a, i są dni że jest aktualizacja tylko jednej paczki, i są też takie kiedy do aktualizacji jest 120 paczek, ale zdarza się to bardzo rzadko.

10

Zgadzam się. Co prawda nie chce mi się tego robić, ale za czasów maszyn o bardzo ograniczonych możliwościach sprzętowych było koniecznością. Kompilowało się tylko te elementy, które w danym momencie były potrzebne, co zwalniało zasoby. W którymś starym numerze czasopisma CHIP był piękny wielostronicowy tutorial kompilacji jajka. Robiłem to za każdą nową wersją kernela. Owszem, teraz może ma to mniejszy sens (choć nadal ma) ze względu na mnogość peryferiów, które można nabyć i niewątpliwie są przydatne i czasami działają od strzała, bo odp. moduł jajka już jest. MHWD nie załatwia wszystkich problemów.

11

Dla tych, którzy narzekają na konieczność kompilowania czegokolwiek i dla tych, którzy chełpią się kompilacją swoich kerneli - wasze nienawiści i miłości skupiają się w jednym punkcie —> Gentoo, dystrybucji dla prawdziwych twardzieli o tytanowych jajach i postrachu zwolenników ułatwiania sobie życia; dystrybucji, która sparafrazowała znaną zasadę (wszystko jest plikiem), tworząc własną: wszystko jest kompilacją.

Litości panowie, dajcie spokój:

https://youtu.be/bQd2Rpv-f9c?t=218

3 polubienia
12

Na tym polega właśnie system rolling release. Ja to akurat bardzo cenię, ale rozumiem, że ktoś może mieć inne zdanie. Swoją drogą - aktualizacje Manjaro stable są przecież większe niż te z Archa, bo pojawiają się rzadziej, ale jak już to hurtowo.

13

bzdura każde .iso Arch’a jest Live ( po odpaleniu nagranego .iso masz wersję live ) no ale fakt nie jest graficzna… ( i pewno to masz na myśli pisząc że brak wersji Live )

ja bym to nazwał zaletą…

przez te skrypty zrezygnowałem z Manjaro ( miałem same problemy - system nie pracował jak ja chciałem )

wszystko można samemu zrobić, zainstalować to co się chce ( po prawdzie wszelkie niepotrzebne rzeczy które nie kolidowały z zależnościami pakietów wyleciały a miałem manjaro-i3 zostało co to niezbędne, i tak to nie było to bo przez wspomniane skrypty mhwd same problemy nawet coby zbudować własny kernel pod lapka ( jak to wcześniej robiłem na blaszaku na Debianie )

ja do takich rzeczy mam Octopi ale tylko do podglądy, a i tak wszystkie instalacje ( aktualizacje ) robię w terminalu ( jak mi powiedział mój mentor od Debiana w 2009 roku )

ja np: mam 4 kernele w tym 1 zbudowane osobiście pod lapka…

siedząc większość swojej przygody z Linux na Debian i jego pochodnych muszę powiedzieć prostszego distro niż Arch nie widziałem ( gdzie wszystko możesz samemu zrobić, i mieć to co potrzebujesz a nie kupę nie potrzebnych paczek ( których nie wywalisz bo zależności od zależności ) tak miałem właśnie we wspomnianym Manjaro-i3…
piszesz o ułatwianiu pracy jw. jak sobie sam ustawisz-ułatwisz pracę z systemem tak będziesz miał ( a nie coś narzuconego ) nigdy nie lubiłem takich rozwiązań ( dlatego pewno pokochałem tiling window manager ) gdzie wszystko możesz poustawiać jak chcesz i jest to lekkie

bardzo spodobało mi się to stwierdzenie ( pozwolisz że będę stosował przy nadarzających sposobnościach ) :wink:

dla mnie to akurat zaleta i czasami jak są dni że nie ma aktualizacji ( rzadko ale się zdarza ) to zaraz sprawdzam czy coś się nie popsuło :wink:
a tak na poważnie to ciągle masz aktualny system i wszystko działa perfekt…

ale się rozpisałem jak kogoś coś tam ubodło to sorry ale takie mam zdanie i kropka…
Pozdrawiam :grinning:

14

Rolling release polega na częstości … NIE! nie na częstości, tylko na ciągłości.

Wikipedia:
[…] A rolling release is typically implemented using small and frequent updates. However, simply having updates does not automatically mean that a piece of software is using a rolling release cycle […]

Nieustannie czytam o tym, że rolling, to częste aktualizacje, że na tym, to polega. Nie na tym, to polega, tylko na tym, że nie ma wyraźnych różnic pomiędzy poszczególnymi wersjami, które tak na prawdę, są snapshot’ami z danej chwili, z aktualnego stanu ciągłej produkcji.

Z marketingowego punktu widzenia (taka była początkowa narracja producenta) Microsoft Windows 10 jest systemem ciągłym, bo nie ma osobnych wersji, tylko raz instalujesz, a potem już tylko aktualizujesz. Ostatnimi czasy nie słyszę już takich bredni, więc pewnie ktoś zorientował się, że to bzdury, bo raz do roku jest tzw. ‘duża aktualizacja’, która polega na świeżej instalacji i przeniesieniu konfiguracji ze starej, a cykl wsparcia jest 1,5-roczny. Mamy więc, jak dawniej, określoną wersję oprogramowania, do której pojawiają się aktualizacje (głównie skumulowane - tak jakby małe service pack’i), a raz do roku następuje aktualizacja do nowej wersji systemu, który otrzymuje poprawki przez 180 dni (poprawki, są dedykowane do konkretnej wersji) - jak dawniej, tylko zmiany systemu częściej, nie raz na kilka lat, tylko raz do roku.

To, że nazwa handlowa tych wszystkich wersji jest taka sama (Windows 10), to nie jest powód do uznania systemu za ciągły. Gdyby aktualizacje pojawiały się codziennie, to nie sprawiłoby, że stałby się ciągły. Czego mu brakuje do ciągłości? Bravo! brakuje ciągłości, przerywanej przez ‘dużą aktualizację’, bo istotą rolling release (rolling update, continuous delivery, wydanie ciągłe) jest ciągłość technologiczna, a nie częstość występowania zmian.

https://pl.wikipedia.org/wiki/Rolling_release
https://en.wikipedia.org/wiki/Rolling_release

P.S. Manjaro, wg niektórych, nie jest prawdziwie ciągłą dystrybucją - w przeciwieństwie do Arch’a - bo ma update’y zbyt rzadko.
Szkoci i Samoańczycy nie, są prawdziwymi mężczyznami, bo noszą spódniczki.

Proszę bardzo —> CC BY.

2 polubienia
15

powiem tak to mój Debian który jest na blaszaku też jest rolling ( bo od 2009 do 2016 był aktualizowany - jak robił jako serwer/desktop ) i ciągle była to ta sama instalacja a wydań Debiana trochę było przez ten czas ( od 2016 robi jako archiwum więc nie dbam już o aktualizacje… )
reasumując jeśli chodzi o ciągłość to każde distro jest rolling - bo większość dystrybucji Debian-pochodnych na ciągłość

ale…
" Rolling release development models are one of many types of software release life cycles. Although a rolling release model can be used in the development of any piece or collection of software, it is often seen in use by Linux distributions, notable examples being for instance GNU Guix System, Arch Linux, Gentoo Linux, openSUSE Tumbleweed, GhostBSD, PCLinuxOS, Solus (operating system), SparkyLinux and Void Linux."

źródło:

jakoś brak Manjaro i wspomnianego Debiana wśród wymienionych przykładów
( a bardziej wierzę anglo-języcznej wiki niż naszej… )

to tak w temacie :grinning:

16

@LinGruby to może zainteresuje Ciebie to distro:

Kiedyś używałem Siduxa, ale projekt umarł. Coś mi się zdaje że to jego spadkobierca.

17

nie dzięki od 5 lat siedzę na Arch’u ( z krótkim epizodem około 3 miesięcznym z Manjaro-i3 )
a Debian-pochodne distro czyli Ubuntu Server mam od 5 lat na swoim VPS KVM ( ale to z lenistwa bo już był zainstalowany jak brałem VPS ) bo jak bym miał stawiać sam to postawił bym Debiana ( przez 7 lat sprawował się poprawnie 24h/7 jako home server produkcyjny… )

ale dodam że repo sidux’a miałem na blaszaku i jak chciałem czasami nowsze paczki to brałem właśnie z sidux’a :wink:

18

Nie do końca. Następcą sidux jest/był aptosid. Siduction powstał sporo później.

W zasadzie to na jednym i na drugim.