GOS IMAGE - co dodać/usunąć?

[Gość ada6666]

a nie da się jakoś tego zrobić tak jak kiedyś ze bez problemu instalowałem WiFi offline z pena sformatowanego na FAT32...

[tux]

Nowe kernele nie mają wkompilowanej obsługi wszystkich FS.

GOS nie dostosowuje się do specyficznych rozwiązań. Tunery mają LAN i mają tak działać. WiFi po doinstalowaniu. Najprościej na chwilę LAN wpiąć.

[Gość ada6666]

a nie można wkleić żeby działalo... (LAN mam już przepalony) na starym sofcie nie było problemów) a ułatwiło by to obsługe i instalacje nie tylko mi....

[tux]

Odpowiedz z mojej strony NIE

 

GOS jest takie jak opisane na www.

Od momentu wydania nowych obrazów nie ma wyjątków.

Zawsze mozna użyć np. drugiego tunera do przygotowania softu do nand ze sterownikami wifi. Jest przecież backup.

 

Założenie jest takie, że tuner ma być sprawny.

[Gość zdzislaw22]

do skasowania

[mickey]

Czasami męczy mnie pytanie: Czy lepiej powiększyć uImage (w sumie w NAND/NOR i tak jest konkretna ilość na to przeznaczona) czy mnożyć moduły. Jeżeli patrzeć tylko na miejsce, to uImage + moduły zajmuje więcej niż uImage z tymi samymi modułami "wkompilowanymi" ... no i moduły zajmują miejsce w systemie plików, a uImage pakuje się w swój obszar flash.

 

Druga strona medalu, to pamięć. Tu się nie znam, ale pewnie mniejsze jajko mniej RAMu zajmuje. A jak to wygląda po "wkompilowaniu" czy załadowaniu listy modułów...

 

Tyle dywagacji. A w odniesieniu do przedmówcy: Powszechność FAT/FAT32 na pendrajwach jest tak duża, że faktycznie może należałoby to "wkompilować" w jajko, albo wrzucić vfat.ko (fat.ko i msdos.ko też?) w GOS Image ... a może nawet w Core. Z mojego punktu widzenia zupełnie zbędne ... bo działa mi sieć, a nawet gdyby nie działała, to pendrajwa z EXT zrobię szybko. Ale jak komuś sieć nie działa i nie używał nigdy linuksa to może nie dać rady tego problemu przeskoczyć.

[tux]

Oczywiście, że do IMAGE można dodać. Tyle, że skoro fat32 to dlaczego nie ntfs czy xfs?

Na dobrą sprawę to od razu dodajmy sterowniki wifi. No ale skoro już tak dodajemy to jeszcze skórki, bo dlaczego nie?

 

Mozna tak długo pisać...A problem tu powstały to uszkodzony box i kombinowanie jak to uruchomić. Na koniec to w sumie GOS powinien przewidzieć, że ludzie już nie potrafią myśleć (ktoś inny projektując coś myśli za nich) i iść ta drogą. Jednak tu bylo, jest i bedzie inaczej.

Nie poddam się temu i nie będzie jak wszędzie.

 

Osoba ma kilka wyjść ale musi chcieć je znaleźć.

GOS nie jest dla tych co grzebią wszędzie nie mając pojęcia o tym w czym grzebią i wyrywają co chwila system.

GOS z założenia wygrywa się, konfiguracje, używa i aktualizuje.

Co prawda teraz po 3 latach trzeba bylo wgrać ponownie, ale dla chcącego nic trudnego.

Jeżeli kogoś przerasta brak fst32 w Kernelu to na 100% GOS nie jest dla tej osoby. Łatwiej juz nie będzie. W miarę prostowania wszystkiego niektóre rzeczy sie zmieniają.

 

I tak przy okazji....wiecie dlaczego efi/uefi używa fat na partycji rozruchowe?

Bo tylko jeden system operacyjny "nie trawi" nic spoza swojego obozu.

 

To nie GOS jest nie przystosowane (jak inne systemy). To ten "jedyny" nie przystosował się do reszty. Nie widzi reszty i szydzi z niej.

[Gość zdzislaw22]

do skasowania

[tux]

Ogólnie dodanie paczki kernel-modules-extrafs-gos to kolejne około 550kb do IMAGE.

Nie mam nic przeciw (powiedzmy) ale żeby to zrobić muszę wyedytować plik /etc/fsmodules.conf. Operacja zajmie kilka chwil i OK. Jednak będzie problem jak ktoś odinstaluje ten pakiet. Na początku dostanie 6 błędów podczas ładowania.

 

Proponuje inaczej....zrobić głosowanie/pisanie/cokolwiek....co ma być w CORE. Jak będzie wiadomo co i jak to zdecydujemy co można dodać w łatwy sposób a co nie. Może coś uda się tak przygotować/zmodyfikować aby było OK.

 

[Gość j00zek]

Głosuję, żeby w core była dodana obsługa fat-a. A nawet zaszyta w kernelu, jak to było dotychczas. Ewentualnie, żeby wersja IMAGE miała inny kernel z obsługą FAT-a, ale chyba bez sensu aż tak kombinować.

Reszta fs zbędna , jak ktoś się uprze, to sobie doinstaluje

 

[tux]

W CORE nie bo nie. To właśnie jest CORE.

Ale w IMAGE można by dodać FAT32/VFAT. W sumie jak ktoś ma CORE to, jak ustaliliśmy, wie co wgrywa. IMAGE to co innego. Tutaj może faktycznie dodać FAT32/VFAT, ale może i więcej....Potraktujmy IMAGE jak coś dla zwykłego użytkownika. CORE zostawmy dla zaawansowanych.

 

Tak będzie chyba najlepiej. Dla każdego coś dobrego.

[mickey]

Oczywiście, że do IMAGE można dodać. Tyle, że skoro fat32 to dlaczego nie ntfs czy xfs?

Na dobrą sprawę to od razu dodajmy sterowniki wifi. No ale skoro już tak dodajemy to jeszcze skórki, bo dlaczego nie?

 

Bo FAT to taki dziwny system plików. Nieprzydatny do niczego, ze względu na awaryjność i brak obsługi uprawnień, ale jednocześnie obsługiwany przez wszystkie (?) systemy operacyjne bez problemów formalno-prawnych. O EFI sam pisałeś. Nawet Android kartę pamięci w FAT32 formatuje uparcie. No i jak pisał @zdzislaw22: "90% penów korzystają z tego systemu".

 

Skłaniam się nawet ku wkompilowaniu tego w jajko, żeby sobie więcej głowy nie zawracać tym problemem. I moim zdaniem warto wyciąć obsługę FAT32 (msdos.ko + fat.ko + vfat.ko) z extrafs i zrobić z tego osobną paczkę, która nie jest zależnością do czegokolwiek, czyli można ją w dowolnym momencie usunąć. Paczkę, która powinna być w Image. Ale co do Core, to nie będę się upierał ... chociaż te 3 moduły razem to poniżej 100kB (ok. 60kB). Tyle, że Core bez sieci jest nieużywalny, więc samo dodanie obsługi FAT32 i tak nic nie da.

[tux]

Idea jest taka, że wszystko co się da pakujemy w moduły.

Jak skończę dodatkowe prace to wszystko się wyjaśni dlaczego.

[robert_cz]

Idea jest taka, że wszystko co się da pakujemy w moduły.

Jak skończę dodatkowe prace to wszystko się wyjaśni dlaczego.

 

A ja chyba wiem dlaczego. Bo @tux chce uruchomić dynamiczne ładowanie modułów. zgadłem?

 

To ja w takim wypadku mam pytanie i wniosek. Jak NFS wyrzuci się z jądra do modułu, to uruchamianie przez ubota po sieci będzie działać?

Jeśli tak, to ja głosuję za wyłączeniem NFS-a z jądra, a później, jeśli można, dodanie dla ułatwienia paczek:

- Samba-client (zależnej od modułu jądra CIFS i wtyczki network browser),

- NFS-client (zależnej od modułu jadra NFS i wtyczki network browser),

 

PS. tak jeszcze myślałem, że wtyczka network browser powinna być zależna od modułu jądra NFS i CIFS, ale co wtedy z tymi którzy chcą tylko NFS, albo tylko Sambę.

 

Tak mi się wymyśliło, jak się spodoba, to fajnie, a jak nie to też obrażony nie będę. :-)

[tux]

NFS prawdopodobnie wyleci i będzie specjalne jajko pod boot z u-boota.

Ale to też za trochę. Teraz możemy mieć różne warianty kernela :)

[Gość ada6666]

Ja również jestem za aby opcja zestala w przyszłości dołączona (fat).... dzięki...

[tux]

A może jaśniej?

Piszcie dokładnie -- chcę to i to.

[Szycha881]

Chciałbym przywrócenia sprawności funkcji "zapasowy zdalny odbiornik" przy konfiguracji do używania bez anteny SAT, gdyż od kilku miesięcy nie funkcjonuje ona poprawnie