Home  >  okolice

Manjaro i ucieczka z 32 bitów

Pomimo buńczucznych zapowiedzi o planowanym porzuceniu platformy 32 bitowej niewiele dystrybucji linuksowych zdecydowało się na ten krok. W zasadzie to dopiero Manjaro będzie realnym prekursorem tego trendu.

Xfce w symbiozie z Manjaro
Wszyscy chcieliby już zamknąć za sobą etap pracy na przestarzałym sprzęcie. Wynika to z postępu ale i możliwości deweloperów z których raczej mało który jest kustoszem w muzeum rozwiązań minionych. Wszyscy dysponujemy już w miarę nowymi konstrukcjami i wyjątkiem od tego nie są twórcy dystrybucji Manjaro. W niedawnym anonsie zadeklarowali oni chęć definitywnego porzucenia wydań 32 bitowych z racji niewystarczającej ilości rąk i sprzętu do prac nad wspomnianą architekturą. Nie ma w tym nic poruszającego, wszak takie samo „wygaszanie” wsparcia odbywa się już w Debianie, który próbuje uwolnić się od balastu i386. Podobne zapowiedzi słychać tu i ówdzie. Ale nikt jeszcze nie podjął tak kategorycznej decyzji, która zostanie wdrożona praktycznie z miesiąca na miesiąc.

Ostatnim Manjaro w wersji 32 bitowej będzie wydanie 17.0.3. Przez wrzesień i październik (2017) możemy jeszcze spodziewać się aktualizacji paczek dla tego wydania, ale proces „porzucania” zakończy się w listopadzie bieżącego roku. Od tego czasu Manjaro dostępne będzie tylko w wersji 64 bitowej.

Czy będziemy tęsknić za 32 bitami na pulpicie? Być może niektóre osoby z leciwymi komputerami będą musiały pomyśleć o aktualizacji sprzętu lub zmianie dystrybucji. Architektura sama z siebie nie zniknie z dnia na dzień. Mało tego, na rynku sprzętu zintegrowanego cięcie kosztów przez stosowanie starszych rozwiązań to wciąż powszechne zachowanie. 32 bity jeszcze długo będą z nami w rozwiązaniach, gdzie po prostu nie potrzeba aż takiego narzutu jaki oferuje architektura 64 bitowa. Z tego też powodu dystrybucje nie są aż tak kategoryczne w swoich decyzjach. Kto wie komu i kiedy jednak wystarczy myśl techniczna z ubiegłego wieku? 

Tags:

21 komentarzy

  2. “Wszyscy chcieliby już zamknąć za sobą etap pracy na przestarzałym sprzęcie.”

    A kto decyduje co jest “przestarzałe”?
    Przewagą Linuksa nad Windowsem miała być możliwość uruchomienia na każdym niemal sprzęcie.
    To gdzie ta przewaga teraz jest? W (_!_) !

  3. Sorry, ale twierdzenia o “prekusorze” są chyba mocno przesadzone.
    Ot, Arch dość dawno temu zapowiedział koniec wsparcia dla ok. 1.7% jego użytkowników i w związku z tym porzucenie platformy 32-bit. Nie do końca i nie tak radykalnie jak np. w KaOS. Manjaro? Mogło się wybić na niepodległość i ciągnąć dalej wsparcie tej platformy. Wybrało ciągnięcie paczek z Archa. Ot tyle.
    Swoją drogą, takie wsparcie dla niszowego użytkownika kosztuje. Kto ponieść ma te koszty? Są dystrybucje dla starych komputerów (teraz to 32 bit), zatem niech się przesiądzie ktoś, kto potrzebuje.

  4. A masz tu wsparcie dla 8, czy 16 bitowych komputerów? Też nie. Jeden fork nie czyni problemu, albowiem nadal są dystrybucje specjalnie przeznaczone na starsze komputery.

  5. Ale o tym właśnie wspomniałem. Porzucenie arch 32-bit póki co jest w sferze zapowiedzi. Dopiero Manjaro zamieni słowa w czyny. Nie jest to może jakiś super-przełomowy moment, ot, kilka procent z kilku procent użytkowników Manjaro będzie musiało rozważyć aktualizację. Raczej nie zachwieje to światem w posadach 🙂

  6. Prawdę mówiąc, to możliwość uruchomienia na ‘czymkolwiek’ będzie istniała nadal. Producenci ruterów i innych raczej rzadko polegają na tym, co oferują dystrybucje. Sami sobie rzeźbią kernel pod swoje potrzeby i wymagania. Problem porzucania 32-bitowej architektury raczej ich obejdzie szerokim łukiem – dopóki takowe rozwiązania nie zostaną wycofane z kernela (albo nie będzie możliwości ich aktywowania).

  7. Tutaj popieram Pawła. Artykuł powinien dotyczyć Archa a nie Manjaro bo to Arch “będzie realnym prekursorem tego trendu” a Manjaro jako pochodna to odziedziczy. Więc nieprawdą jest zdanie “nikt jeszcze nie podjął tak kategorycznej decyzji, która zostanie wdrożona praktycznie z miesiąca na miesiąc”.

  8. ja podjąłem taką decyzję.Od czerwca przestałem wspierać 32 bitową architekturę w moim domu.
    Wszystkie moje komputery to 64 bit.
    Ot co.

  9. I bardzo dobrze, mogli by jeszcze odchudzić kernel ze starego kodu wspierające stare architektury. Tworzyć go od c2d i AMD 64 X4, a przestarzałe niech siedzą na starych jądrach 2, 3. Tak samo Xorg, nie wracam do niego Wayland działa mi idealnie.

  10. Z całym szacunkiem, ale Manjaro tu nie będzie realnym prekursorem, który “zamieni słowa w czyny”, a jedynie zapowiedziany na listopad ruch jest konsekwencją styczniowej zapowiedzi z Archa. Nawet zapowiedź porzucenia architektury przez Manjaro https://manjaro.org/2017/09/02/maintenance-phasing-out-i686-support/ jest kalką styczniowej zapowiedzi Archa https://www.archlinux.org/news/phasing-out-i686-support/
    Prekursorem natomiast takiego rozwiązania – jeśli już o prekursorów chodzi, to była chyba Chakra sposód tych bardziej popularnych dystrybucji (przynajmniej wówczas gdy się pojawiała, sporo było o niej szumu i w rankingach popularności była wyżej niż obecnie). Najbardziej natomiast konsekwentne rozwiązanie jest w KaOS, gdzie w ogóle nie ma nawet bibliotek multilib. O ile w Archu, Manjaro, czy Chakra nadal będzie można uruchomić program czy użyć sterownika 32-bitowego, to w KaOS nie ma takiej możliwości.

  11. Sam kod dla ZU jest obojętny. ZU ma do dyspozycji skompilowaną binarkę. Nie ma kernela “hybrydowego”, który obsługuje architekturę 32 i 64 bitową. Jest kernel albo dla jednej, albo dla drugiej. W kernelu dla architektury 64-bitowej nie masz wsparcia dla procesorów 32-bitowych, nie zawiera on tego kodu. Natomiast sam kod… Cóż, dalsze rozwijanie w nim wsparcia dla architektury 32-bitowej umożliwia kompilowanie z nich kerneli używanych w dystrybucjach, które je wspierają, bądź też tworzenie kerneli przeznaczonych do używania na urządzeniach, które są 32-bitowe, jednocześnie nic nie tracąc z wszystkich nowinek, które są wprowadzone. To od kompilującego kernel zależy jego ostateczny kształt. Od niego zależy czy i jak będzie “odchudzony”. Zwykle jednak, mainstreamowe dystrybucje starają się robić kernele tak, by ZU nie miał kłopotów z jakimiś peryferiami, stąd też domyślne kernele są dość sporych rozmiarów i obładowane zbędnymi funkcjami w każdym konkretnym przypadku. To głównie właśnie chęć zapewnienia możliwości używania takiego kernela w każdym możliwym przypadku powoduje jego “tłustość”. Cóż – albo decydujesz się używać taki kernel, albo budujesz sam pod Twoje potrzeby.
    Kernele z linii 2.x nie są już wspierane. Ktoś musiałby przejąć ten kod i zapewnić mu ponownie choćby wsparcie bezpieczeństwa. Lepsza sytuacja jest pośród linii 3, albowiem w przypadku 3.16 (to jest bodaj najpopularniejszy kernel w Androidzie) wsparcie w istocie jest bardzo długie, bo EOL spodziewany jest w kwietniu 2020 (to zresztą najdłużej wspierany kernel z obecnie rozwijanych jeszcze :)).

  12. Manjaro niestety nie będzie pierwsze, w czerwcu ubiegłego roku architekturę 32-bitową porzucił Antergos i od tamtego czasu dostępne są jedynie buildy 64-bitowe.

  13. Nie rozumiem co mieliby twórcy Manjaro do gadania w tej kwestii, skoro ich system opiera się wprost na paczkach Archa? O ile dobrze pamiętam deweloperzy Archa kończą tworzyć paczki 32bitowe jakoś w listopadzie, więc siłą rzeczy Manjaro też będzie musiało porzucić tą platformę. Nie zaczną przecież kompilować wszystkich paczek swojego systemu dla architektury 32bitowej, bo nigdy przecież tego nie robili.

  14. Tak jak i wszystkie inne dystrybucje opierające się na Archu. Co Arch wprowadzi to inni muszą przyjąć.

  16. To ja wiem że jest osobny dla 32 i 64. Chodziło mi o to że teraz wychodzą procesory inteli i3, i5, i7 z serii 8xxx, oraz dla AMD procesory Ryzen r3, r5, r7. I od tej serii procesorów wzwyż będzie pisany nowy kernel 5.xx, tak samo dodać tyko karty najnowsze z tego roku nvidia GTX 1xxx, radeon RX5xx sterowniki do najnowszych Wi-Fi itp. A starą wersję rozwijać sobie nadal osobno. Wielu ludzi co kupiło by nowy sprzęt wybierało by dystrybucję lub sam kernel z serii 5.xx. To by na pewno odchudziło i przyspieszyło system, a na pewno unowocześniło by kerenl, pozbywając się starego kodu pisanego jeszcze w czasach standardu C89.

  17. Tyle, że… to kompletnie nie tak działa 🙂
    Zbuduj kiedyś kernel samemu. Zobaczysz, że problem w “starym kodzie” jest iluzoryczny i tylko i wyłącznie jest problemem osób, które nigdy kernela nie robiły.

  20. Porzucenie arch w sferze zapowiedzi? Bzdura….

    The decision means that February ISO will be the last that allows to
    install 32 bit Arch Linux. The next 9 months are deprecation period,
    during which i686 will be still receiving upgraded packages. Starting
    from November 2017, packaging and repository tools will no longer
    require that from maintainers, effectively making i686 unsupported.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Post comment

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.