Forum Debian Users Gang

jest jest jakaś możliwość żeby do takiego systemu zaimplementować aptitude/apt-get żeby można było instalować gotowe pakiety *.deb czy na takiej dystrybucji trzeba będzie wszystko kompilować?

oczywiście, możesz sobie skompilować apta i rodzinkę itd. nikt ci nie zabroni i możliwe nawet że zadziała.

ale nie miej zbyt wielkich nadziei na jakąkolwiek binarną kompatybilność pomiędzy debianem a twoim LFSem. słowem - zainstalować *.debka, zainstalujesz. ale w chwili jego uruchomienia najprawdopodobniej segfault.

BTW, widziałeś dystrybucję pt. GoboLinux? ma bardzo ciekawy menedżer pakietów - ów "menedżer" był w linuksie od pierwszego wydania, tylko nikt wcześniej nie wpadł na pomysł aby tak właśnie go wykorzystać :P

Mogę się mylić, ale do tej pory wydawało mi się, że dystrybucje źródłowe stawia się własnie po to, żeby mieć samodzielnie skompilowane pakiety.

Po co zaś kompilować? Żeby mieć oprogramowanie zoptymalizowane do działania w danych warunkach tudzież żeby skorzystać z jakiejś funkcji, której nie wkompilowała osoba tworząca paczkę. Z tym, że to pierwsze w znacznej części jest mitem — żeby faktycznie odczuć różnicę w efektywności działania pomiędzy programem własnoręcznie skompilowanym, a tym pochodzącym z paczki przeznaczonej na daną architekturę (to jest ważne — Debian udostępnia paczki optymalizowane pod architekturę i386, i dlatego na niearchaicznym sprzęcie jest wolniejszy od takiego Archa), nie wystarczy ./configure && make && make burdel — należy zoptymializować flagi kompilatora, dokładnie ustawić flagi skryptu konfiguracyjnego itd. Do tego zaś potrzebna jest większe niż „marna” wiedza o kompilacji.

Sądząc po tym, że chcesz mieć system uruchamiający się z pendrive, domyślam się, że będziesz chciał uruchomić go na różnych komputerach, z czego specyfikacja każdego z nich nie jest dokładnie znana. Ponieważ nie znasz sprzętu docelowego, optymializacja oprogramowania (zakładając że jednak można zoptymalizować pod niewiadomą) jest bezcelowa — nie przyniesie wymiernych korzyści. Na jednym komputerze będzie działało jak burza, na drugim wręcz przeciwnie albo wcale.

W powyższym krótkim wykładzie doszedłem do punktu, w którym samodzielna kompilacja nie ma do zaoferowania żadnych profitów. Jednak wciąż ma wady, o których do tej pory nie wspomniałem.

Primo czasochłonność. Więcej dodawać nie muszę.

Secundo czysta kompilacja, czyli taka jaką oferuje LFS, nie udostępnia żadnego sposobu na śledzenie tego, co dzieje się w systemie. Nie tylko trzeba mieć na uwadze wszystkie zależności, ale również aktualizacje są poważnym problemem — konieczność ponownego skompilowania pakietu można jeszcze przeboleć, ale brak jakiegokolwiek informowania o dostępności nowszych wersji z pewnością da się odczuć.

Oczywiście społeczność LFS stara się jakoś zmniejszyć tę drugą niedogodność (pierwsza jest wpisana w założenia projektu). http://www.linuxfromscratch.org/hints/read.html — wyszukaj na tej stronie package, a znajdziesz kilka podejść do rozwiązania rzeczonego problemu. Wybierzesz i zaimplementujesz to, które Ci się najbardziej spodoba.

Jeżeli dalej nie przekonałem Cię, że nie potrzebujesz dystrybucji źródłowej, muszę przynajmniej zapytać: dlaczego LFS? Nie lepiej wybrać jakąś dystrybucję źródłową która udostępnia menedżer pakietów? Gentoo, BSD z ich portami czy inne, mniej znane, co nie znaczy że gorsze.

Jeżeli chodzi o uruchamianie z pendrive, zainteresuj się tą stroną: http://www.pendrivelinux.com/ .

Tyle ode mnie. Powodzenia życzę. Przyda Ci się podczas tego marnotrawienia czasu (tak, uważam Twój pomysł za marnotrawienie czasu. Co bynajmniej nie jest argumentem przeciwko jego realizacji — Twoja wola).

Możesz sprawdzić Kiwi, jedną z możliwości jest stworzenie  dystrybucji na pendrive
Inne narzedzie to np. UCK do tworzenia Live Cd.
Nie używałem powyższych narzędzi ale myśle , że będzie o wiele łatwiej niż zabawa z LFS.

Ostatnio edytowany przez ba10 (2008-06-03 16:22:51)

Przetłumaczony LFS :)

http://www.loz.republika.pl/lfs/index.html

azhag napisał(-a):

Minio napisał(-a):

Debian udostępnia paczki optymalizowane pod architekturę i386

właściwie to i486

Mea culpa, i486. Zresztą Ty wiesz, jaka ta moja wiedza o Debianie jest ;) .

Jak już powiedziałem na optymalizacji równanej z przyspieszeniem mi nie zależy. Jakoś niezbyt mnie kręci spędzanie godzin na przeglądaniu confów i innych opcji ./configure tylko po to żeby zyskać 0.001% czy choćby nawet 1% czasu gdyż przy dzisiejszych kompach to jest totalnie bez sensu ;] Co innego gdyby wzrost miał sięgać 10-20% wtedy można się pokusić o takie zabawy. Ale to tylko moje skromne zdanie. Co do łańcuszka kompilacji to fakt bywa stresujący ;] A jedyną "optymalizacją" jaką bym wrzucił to tylko do kernela: obsługę do 4GB RAM'u, architekturę na i586/i686 i jeszcze jedną którą mam włączoną na własnym kernelu ale nie pamiętam nazwy z cofiga ;)

Chodzi o portable system z prawdziwego zdarzenia, taki do którego w razie nieprzewidzianych okoliczności, można dodać taki a nie inny pakiet. Typowe LiveCD w tym momencie odpada. A z pendrive'em jakoś nie mogłem sobie poradzić konwencjonalnymi metodami - trzeba będzie powalczyć jeszcze raz. Dlatego pytam. Co polecacie. Czy coś a'la LFS/system kompilowany czy kolejna próba postawienia Etcha na penisie?

Minio napisał(-a):

Standardowa odpowiedź: to w czym czujesz się najlepiej. Jeżeli znasz Debiana, stawiaj Debiana. Jeżeli Gentoo nie ma przed Tobą tajemnic, stawiaj Gentoo. Jeżeli Suse Cię urzekło, postaw Suse.

Powiem tak. Używałem kilku(nastu) dystrybucji ale niestety nie jestem guru czy "inżynierem" w posługiwaniu się nimi. Odnośnie dystrybucji to mam 3 "ulubione" PLD, Debian i Mandriva. Chociaż na Debianie pracuję dopiero od 2 miesięcy ;] PLD mnie chwilowo zraziło problemami przy instalacji z chroot'a a Mandriva... Hmmm, jak to określa Trin, stała się zbyt cukierkowa i też nie mogłem dojść do ładu z kilkoma rzeczami. No i jej rozmiary..... Straszne ;] Za kompilację Gentoo nawet się nie biorę bo polegnę na pierwszym kroku ;] Obecnie PLD w wersji Th i Ti jest nie do końca dopracowane a wersja Ac jest już lekko przestarzała (moim zdaniem!!) ;] Pozostaje Debian :D Nie ważne czy będzie to Etch, Lenny czy Sid. Chociaż preferuję Etcha ;))

Dobra wybór dystrybucji powiedzmy że mam(y) za sobą ;) Teraz proszę mi powiedzieć czy jest możliwość zainstalowania/przekompilowania KDE tak aby nie zajmowało +400MB ;) Jest wiele pakietów w samym KDE których nie używam (Klipper, Kate - preeruję Kwrite ;], KPager, KTip)... Czy pozostaje mi Flux lub inny WM i instalacja samych bibliotek QT i GTK+

EDIT:
Ewentualnie proszę o szczegółowe informacje na temat instalacji Debiana na pendrive'ie przy pomocy deboostrap'a ;) to co jest na konkurencyjnym forum jest jeszcze troszkę enigmatyczne i nie do końca sobie poradziłem ;) Przede wszystkim chodzi mi o kroki związane z instalacją (własnego) jajka i gruba. Może ktoś z Was to robił ja wymiękłem na instalacji gruba i partycjonowaniu ;] a co za tym idzie nie przebrnąłem przez pozostałe kroki ;] :((

Ostatnio edytowany przez winnetou (2008-06-03 23:59:16)

Minio napisał(-a):

Dostrzegam sprzeczność. Z czasem system się starzeje, innej możliwości po prostu nie ma. Nikt nie mówi że trzeba przekompilowywać wszystko raz na tydzień, ale powiedzmy po kwartale z pewnością znajdzie się kilka rzeczy które powinny być zaktualizowane. Nie mówiąc już o np. roku.

OS to nie wino, z wiekiem nie staje się lepszy ;) .

Jednak tak często nie wychodzą. Nawet przez dwa lata można nie kompilować nic. Np. GCC? Nic nie korzysta z bardziej zaawansowanych/nowszych funkcji (kernel chyba dalej zaleca te z linii 3.x), GTK aż tak bardzo się nie zmienia... Albo inaczej... Od początku tego roku narzekam na pustkę... Nic nie kompilowałem... Poza takimi rzeczami, które chciałem nowsze postestować jak Kadu czy Wine, czy Firefox 3b5..

Dowód: Popatrz na daty ostatniej modyfikacji katalogów... ftp://ftp.gnu.org/gnu/
Ale i nowsze daty nie oznaczają, że koniecznie trzeba już to aktualizować. Nie ma potrzeby.

Dystrybucje zwykle dłuuugo testują pakiety, np. takie Glibc... I zawsze jest o kilka rzędów starsze. Ja mam świeże i nie mam żadnych błędów czy cuś...

Minio napisał(-a):

Nie nie nie, w dystrybucji źródłowej jest tak samo. Jeżeli pakiet A się zmienił na tyle, że została zerwana zgodność A(P|B)I (pomijając w tym miejscu rozważania na temat różnic pomiędzy nimi) z pakietem B, który od niego zależał, nalezy przekompilować oba. Znaczy: podczas aktualizacji zostaje przekompilowany pakiet A, a potem okazuje się że pakiet B nie działa i trzeba go skompilować, że tak rzeknę z angielska, against nowsza wersja biblioteki zależnej.

Oczywiście zerwanie zgodności nie następuje często (chyba że mowa o kernelu, któtrego jedno wydanie nie jest kompatybilne z poprzednim), ale gdy jednak nastąpi... Zresztą po coś to revdep-rebuild w Gentoo dali ;) .

Zgodności nie są przerywane za często. Problem więc nie istnieje. Ja tam mam Glib1.2 i Glib2.x, GTK1.2 i GTK2.x, mam Qt3 i Qt4 i nic się nie kłóci. A kompilacja to już przecie oczywiste jest, że aktualizacja to kompilowania nowszych wersji. Tej samej biblioteki dwa razy nie trzeba kompilować.

Minio napisał(-a):

To jak w końcu jest, kompilowane działa stabilniej czy gorzej niż paczkowe?
MSPANC.

Lepiej niż paczkowane o 100%, bo wiemy co mamy i gdzie mamy, a nie instaluje nie wiadomo co, nie wiadomo gdzie. Tu mamy kontrolę nad każdym plikiem. Przy okazji uczy to pracy z kompilatorem, rozwiązywania z nim problemów, uczy programowania, bo zna się strukturę źródeł programów i każdy sobie swój styl doskonali.

NIC napisał(-a):

Jednak tak często nie wychodzą. Nawet przez dwa lata można nie kompilować nic. Np. GCC? Nic nie korzysta z bardziej zaawansowanych/nowszych funkcji (kernel chyba dalej zaleca te z linii 3.x), GTK aż tak bardzo się nie zmienia... Albo inaczej... Od początku tego roku narzekam na pustkę... Nic nie kompilowałem... Poza takimi rzeczami, które chciałem nowsze postestować jak Kadu czy Wine, czy Firefox 3b5..

Dowód: Popatrz na daty ostatniej modyfikacji katalogów... ftp://ftp.gnu.org/gnu/
Ale i nowsze daty nie oznaczają, że koniecznie trzeba już to aktualizować. Nie ma potrzeby.

Dystrybucje zwykle dłuuugo testują pakiety, np. takie Glibc... I zawsze jest o kilka rzędów starsze. Ja mam świeże i nie mam żadnych błędów czy cuś...

Podstawowe elementy systemu GNU sobie, oporogramowanie używane na tym systemie sobie. Np. powiedzmy średnio raz na pół roku wychodzi nowy OOo (2.3 wyszedł w grudniu 2007, 2.4 w maju tego roku; dawniejszych dat nie sprawdzałem, stąd „powiedzmy” powyżej). Claws-mail, program pocztowy, zacząłem używać jakoś dwa lata temu, kiedy jeszcze nazywał się sylpheed-claws. Wersji nie pamiętam, 2.7 albo 2.9 wtedy była... teraz jest 3.4. Co oznacza, że nowa wersja była wydawana częściej jak raz na pół roku.

Podobne przykłady można mnożyć.

Oczywiście z drugiej strony znajdują się np. MPD, na którego wersję 0.12 przyszło czekać prawie dwa lata (0.13 potrzebował niecałego roku) czy Kadu (tutaj dokładnych dat nie podam, gdyż nieszczególnie interesuję się rozwojem; ale pomiędzy wersją 0.5 a 0.6 upłynął rok jeśli nie dwa).

Wszystko zależy od doboru oprogramowania. Ja pamiętam że, jak jeszcze używałem Gentoo, rzadko były dni, kiedy w portage nie pojawiła się nowsza wersja któregoś z pakietów, których używałem. Zresztą teraz na Debianie jest podobnie.

Oczywiście, nie ma konieczności aktualizacji na bieżąco. Ale trudno wtedy powiedzieć o systemie, że jest aktualny.

NIC napisał(-a):

Zgodności nie są przerywane za często. Problem więc nie istnieje. Ja tam mam Glib1.2 i Glib2.x, GTK1.2 i GTK2.x, mam Qt3 i Qt4 i nic się nie kłóci. A kompilacja to już przecie oczywiste jest, że aktualizacja to kompilowania nowszych wersji. Tej samej biblioteki dwa razy nie trzeba kompilować.

Ale jednak się zdarza. Nie pamiętam szczegółów, ale jakoś w zeszłym roku na Gentoo musiałem rekompilować dosłownie połowę systemu po aktualizacji jakiejś krytycznej dla działania systemu paczki. Z jakiegoś powodu mi świta, że mogło chodzić o libiconv, ale bynajmniej nie twierdzę z całą pewnością. Pamiętam tyle, że nowa paczka w systemie umieszczała plik z dwójką w nazwie, podczas gdy wszystkie programy chciały tej biblioteki bez wspomnianej dwójki...

Przepraszam, ale więcej nie jestem w stanie sobie przypomnieć. Niemniej jestem przekonany, że każdy z użytkowników Gentoo (używających go dłużej niż tydzień!) jest w stanie opowiedzieć podobną historię.

NIC napisał(-a):

Minio napisał(-a):

To jak w końcu jest, kompilowane działa stabilniej czy gorzej niż paczkowe?
MSPANC.

Lepiej niż paczkowane o 100%, bo wiemy co mamy i gdzie mamy, a nie instaluje nie wiadomo co, nie wiadomo gdzie. Tu mamy kontrolę nad każdym plikiem. Przy okazji uczy to pracy z kompilatorem, rozwiązywania z nim problemów, uczy programowania, bo zna się strukturę źródeł programów i każdy sobie swój styl doskonali.

Argumenty niepodważalne przy przyjęciu dwóch warunków:
1. faktycznie komuś ta wiedza jest do szczęścia potrzebna. Akurat mnie nie jest. Aptitude może sobie rozrzucić pliki w najbardziej egzotyczne miejsca jakie mu przyjdą do głowy, póki działa średnio mnie to interesuje. A specyfika Debiana jest taka, że akurat o poprawne działanie martwić się nie muszę — jest celem określonym w fazie projektowej.
2. kompiluje się z mózgiem a nie robi ./configure && make && make burdel, o czym wspomniałem w pierwszym poście. Zapewniam, że spora część osób „kompilujących” programy w życiu nie zajrzała do skryptu konfiguracyjnego, a co dopiero źródeł programu.

Ostatnio edytowany przez Minio (2008-06-04 18:34:28)

azhag postanowiłem się pobawić grml i przygotować sobie obraz iso z tym co mi pasuje i napotykam na poważny błąd :( ;/

Etch-x86:/home/winnetou/grml# dpkg -i grml-live_0.7_all.deb
Zaznaczenie poprzednio niezaznaczonego pakietu grml-live.
(Odczytywanie bazy danych ... 96812 plików i katalogów obecnie zainstalowanych.)
Rozpakowanie grml-live (z grml-live_0.7_all.deb) ...
dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie grml-live:
 grml-live zależy od fai-client (>= 3.2.4); jednakże:
  Wersją fai-client w systemie jest 3.1.8.
 grml-live zależy od fai-server (>= 3.2.4); jednakże:
  Wersją fai-server w systemie jest 3.1.8.
dpkg: błąd przetwarzania grml-live (--install):
 problemy z zależnościami - pozostawiony nieskonfigurowany
Wystąpiły błędy podczas przetwarzania:
 grml-live

używam Etch'a. Czy jak dodam repo z testing/unstable i potem

aptitude install fai-server fai-client -t experimental/unstable

to nie wywali mi połowy systemu?? ;>

Nie poprawi bo błędów nie ma. A nawet jak są to lepiej. Bo te Debiany itp. to jest sprzeczność z ideą. Oni owszem... Poprawiają błędy w pakiecie XYZ, ale nie zgłaszają tego twórcom pakietów (kod), a więc na co komu takie poprawianie. Takie działania hamują ten piękny ruch na rzecz wolnego i otwartego oprogramowania.

Co do błędów jeszcze. Można samemu poprawić. Ja pamiętam np. poprawiałem jedynie sobie port MIDI w DosBoksie, bo mi warrningi wypisywało po uruchomieniu :] Prosta operacja, ale czemu był błąd to nie wiem do tej pory...

Jeśli byłyby błędy to patrz nie chwaliłbym swojego systemu. Ale tu wszystko działa dopóty dopóki nie będzie mojej ingerencji gdzieś (w system)

Nie kontaktują się. Nie słyszałeś o ostatniej aferze z OpenSSL? Ponadto każda dystrybucja robi np. swoje zmiany np. w takim KDE... Raczej nigdy żadna taka nie trafiła do oficjalnego kodu, a przecie część rzeczy słusznie dodają od siebie.

"Jak błędy są to lepiej." Dowody:
- musimy w końcu zaktualizować system... albowiem jak wszystko hula to nie robimy tego.. może minąć rok a my bez aktualizacji.. bo i co aktualizować... A jak zaktualizujemy to później nie będzie trzeba tego robić jak aplikacja XVS poprosi o wersję nowszą.
- może wyzwoli to u nas zdolności programistyczne
- warunkiem rozwoju pakietu są błędy w nim, bo jak nie ma błędów to rozwój programu stoi, po czym twórcy porzucają go, chyba większość programów do oglądania TV tam ma... i teraz nie chcą się kompilować z nowszym oprogramowaniem, bo są przestarzałe (po 2 lata mają lub więcej).

Co do Świętego Grala... To jest tylko jeden program, który zasługuje na to miano, bo nie ma błędów itp: Windows Vista ;)

Ostatnio edytowany przez NIC (2008-06-07 10:09:00)