Stary Komputer Forum

Może głupie pytanie, może mądre.
Jak w tytule, interesuje mnie system Linux, który pozwoli na instalacje programów bez potrzeby internetu. Każde distro jakie spotykam po prostu pobiera i instaluje. Żadnych instalatorów na dysku nie zostawia co mnie niestety smuci bo jestem przyzwyczajony do posiadania gigabajtów instalatorów pod Windowsa i to samo chciałbym tu bo akurat łącze internetowe mam po kosztach
Próbowałem z Debianem ale niestety paczki .deb domagają się pobierania "zależności" co nie za bardzo mnie satysfakcjonuje bo w praktyce sprawia to mi tylko zamęt na dysku i wolałbym już to instalować z terminala. Prawdopodobnie odpowiedzią na moje pytanie jest pobranie całego dostepnego repozytorium i trzymanie go offline. Trochę niepraktyczne bo nie każdy program jest mi potrzebny do życia. Z drugiej jednak strony, może jest opcja na pobranie tylko wybranych programów, które byłyby gotowe do instalacji i tylko z nimi by to repo sobie funkcjonowało?
Chcę być w stanie pobrać sobie raz programy i trzymać je na dysku i móc instalować sobie system na różnych komputerach bez obawy o to, że potrzebuję jednak internetu by coś w nim skonfigurować.
Debian to chyba jedyna rozsądna opcja w tym wypadku bo ten system ma aktualizacje repozytorium jakoś raz na dwa lata jeśli się nie mylę.

Najlepszym (i jedynym jaki znam) sposobem na przenośne programy na linuksie, które nie wymagają osobnego instalowania zależności to format appimage. Nie jest on jednak bardzo popularny i nie każdy program można dostać w tej formie.
Znalazłem to narzędzie: https://github.com/simoniz0r/deb2appimage.
Ale wydaje mi się, że konwertowanie każdego programu którego potrzebujemy będzie pracochłonne i niewygodne.

Znalazłem lepszy sposób. Można pobierać paczki deb danego programu oraz paczki deb jego zależności.
https://superuser.com/questions/876727/ ... pendencies
Później te paczki można sobie trzymać offline i instalować w razie potrzeb.

prot pisze: ↑01 sie 2022, 11:09 Znalazłem lepszy sposób. Można pobierać paczki deb danego programu oraz paczki deb jego zależności.
https://superuser.com/questions/876727/ ... pendencies
Później te paczki można sobie trzymać offline i instalować w razie potrzeb.

prot pisze: ↑31 lip 2022, 23:47 Najlepszym (i jedynym jaki znam) sposobem na przenośne programy na linuksie, które nie wymagają osobnego instalowania zależności to format appimage. Nie jest on jednak bardzo popularny i nie każdy program można dostać w tej formie.
Znalazłem to narzędzie: https://github.com/simoniz0r/deb2appimage.
Ale wydaje mi się, że konwertowanie każdego programu którego potrzebujemy będzie pracochłonne i niewygodne.

nie sprawdzałem ale dowiedziałem się o innej metodzie, mianowicie trzeba zrobić tak:

apt-get install APLIKACJA --download-only

pobierze to nam same paczki z zależnościami, które potem można zainstalować bez internetu za pomocą

apt install APLIKACJA

paczki są trzymane w /var/cache/apt/archives/

Nie jest to jednak poręczna metoda bo szybko tworzy się bałagan i najlepiej sobie zrobić plik tekstowy z rzeczami, które pobieramy (typu neofetch, filezilla etc). Aby działało to na innym komputerze bez internetu trzeba przekopiować do tej samej lokalizacji, przez co znowu, brak poręczności :/
Ostatecznie jednak, działa to, aczkolwiek nie działa to z WINE jak i Flatpakiem. WINE po prostu nie działa i domaga się ponownego pobrania a Flatpak nie obsługuje flagi --download-only.

Co do AppImage, nie jestem wielkim fanem tego bo często są to przestarzałe paczki i niekiedy często bez zależności samych w sobie.

O problemach paczkowania na linuksie wypowiedział się kiedyś sam Torvalds i wiele się od tego czasu nie zmieniło
https://www.youtube.com/watch?v=Pzl1B7nB9Kc

APT oraz RPM obsługuje repozytoria offline, np. na plycie CD. W zasadzie ścieżka do repozytorium może być dowolna, adres URL, ścieżka do pliku na dysku czy ścieżka do pliku na CD. Można zrobić sobie "prywatne" repozytorium (jest to po prostu struktura katalogow i jakiś plik manifestu, dla apt plik Release) z paczkami .deb albo .rpm i nagrać je na dowolny nośnik. Wiele programow pod Linuksa było kiedyś rozprowadzane w formie repozytoriów RPM nagranych na plyte CD. Skrypt instalacyjny instalował paczki z plyty CD.

Jak otworzysz /etc/apt/sources.list na świeżozainstalowanym debianie, to jeśli instalowałeś z DVD, masz tam dwa wpisy ktore definiują repo na tym DVD

Można tego repo nawet nie nagrywać, tylko trzymać na lokalnym komputerze i mieć podmontowany zasób sieciowy z tego komputera na innym komputerze, ale OP pyta o offline wiec nie bede sie rozpisywać o NFS.

Skoro już ktoś wraca do tematu "offline instalatorów" w linuksie - to najlepszym rozwiązaniem serio jest posiadanie paru płyt z repozytorium. Niestety z wydania na wydanie rozszerza się repozytorium Debiana i coraz więcej płyt co dwa lata trzeba by było nagrywać. Jak również - coraz więcej jest aktualizacji zmieniających wersje aplikacji - a kiedyś tego nie było i jak miałeś firefoksa 2.0, to miałeś go do końca świata.

Pozostaje nauczyć się Slackware

Tuudzież - pobrać CAŁE repozytorium na dodatkowy dysk i wpisać go w sources.list. Ale nie wiem, czy to dobre rozwiązanie dla osoby, która ma ograniczony transfer internetu (jakby miała nieograniczony, nie miałaby ochoty trzymać offline instalatorów).

Problem z Linuksem jest taki, że ten system ma w dupie wsteczną kompatybilność. Mógłby się starać, ale od zawsze ten system prze do przodu i nie patrzy w tył. Masz apkę na GTK, ale nowa wersja GTK nie jest kompatybilna i na czas wydania nie zaktualizowałeś aplikacji? Puff, leci z repozytorium. Szybciutko, lecimy do przodu, szybko, szybko, szybko.

Slackware i ewentualnie BSD są rozwiązaniem na ten problem. Niestety wymagają czytania dokumentacji, cierpliwości i rezygnacji z niektórych przyjemności, na które pozwalają inne systemy. Mowa bardziej o BSD w tym temacie. Tutaj nawet nie ma obsługi DRM w kernelu, przez co nie działa Spotify. A sterowniki trzeba ręcznie aktywować w kernelu.

Slack najmniej ogranicza, bo jest Linuksem - ale przykładowo aplikacje 32-bit na 64-bitowym systemie to nadal bardzo trudny orzech do zgryzienia i przez chwilę nieuwagi - można bezpowrotnie uszkodzić sobie ich działanie i już wincyj Stim na Slakłor się nie odpali. I tak... udało mi się to zrobić... I nie - nadal nie naprawiłem . Nie chce mi się, bo na starym Dellu jedyne co uruchamiam to Diablo 1 (Devilution), Unreal Tournament 99 (najnowszy patch jest pod linuksa 64bitowego) oraz jakieś Pingus czy Super Tux. To jest jedyna wada Slackware i chciałbym, by dało się tym jakoś "ładniej" zarządzać. Choć podejrzewam, że obsługa multiliba popsułaby mocno prostotę tego systemu.

Co łączy BSD i Slacka? Niesamowita przewidywalność i brak pogoni za nowościami. Slack wychodzi raz na milion lat a systemy BSD nadal trzymają sprawny legacy software w repozytorium. W NetBSD niedawno nadal widziałem oryginalne Gnome 2 w repozytorium, co mnie zaskoczyło

Co do systemów BSD, to każdy jest inny. Nie są ze sobą kompatybilne. Często ten sam problem ma na nich zupełnie inne rozwiązanie. Jakieś dwa lata temu napisałem artykuł o moich przeżyciach z NetBSD okiem linuxiarza. Oczywiście na portalu linuxiarze.pl!

Jak robiłem drugie podejście na poważnie do tego systemu, bo było trzecie w rzeczywistości, ale przy tym pierwszym, to nie wiedziałem jak rozgryźć główny podręcznik, to stare i dobre kde4 nie dało się uruchomić, bo ekran logowania kdm wypadł z kolekcji portów pkgsrc, zapewne był już takim starociem, że nie było możliwości utrzymania go przy życiu. Kde4 ma w sobie błąd powodujący, ze da się uruchomić tylko w trybie awaryjnym. A niestety ani slim, ani xdm nie wspierają takich opcji. Po dłuższej zabawie sobie odpuściłem.

Zainstalowałem DragonflyBSD, które z kolei zainstalowało się bez problemu. Po zalogowaniu się do roota, odpaliłem pkg update, zaś potem pkg upgrade, które spowodowało aktualizacje samego pkg, aż tu pod koniec wywaliło mi repozytoria. Rozwiązanie problemu, który jest znany od co najmniej 2012 roku w DragonflyBSD, nie przyniosło w moim przypadku żadnego pozytywnego skutku. Dodam, że narzędzie pkg wywodzi się PC-BSD, po którym ślad już nie został, a jest obecnie rozwijane przez deweloperów FreeBSD, gdzie problem nie występuje. Na marginesie w maju 2021 roku instalowałem DragonflyBSD bez tego problemu

Jeśli chodzi o Slackware, to miałem kontakt z pochodną dystrybucja o nazwie Zenwalk i to dość krótko, więc brak mi wiedzy na ten temat.