Comments on: Recenzja: Slackware 10.1

By: puszczyk

puszczyk — Sun, 15 Jan 2006 17:11:59 +0000

O które ustawienia konkretnie Ci chodzi ? Całego xorg.conf nie prześle, bo od tego czasu troche na kompie u mnie się zmieniło (slackware zastąpiony przez archa, a kde przez gnome); ale może moge mimo wszystko jakoś pomóc.

By: puszczyk

puszczyk — Sun, 15 Jan 2006 17:10:21 +0000

By: fenek

fenek — Sun, 15 Jan 2006 13:47:19 +0000

jakie są ustawienia na tej fotce w xorgu ?

By: michup

michup — Fri, 06 Jan 2006 23:03:09 +0000

Jeszcze jedno… istnieje mozliwosc, o ktorej moze jeszcze nie wszyscy wiedza, podczas instalacji wyboru z jakimi bibliotekami ma byc konsolidowany dany program.
Nie daje to gwarancji na prawidlowe dzialanie ale nie wyklucza sukcesu. Bardziej zaawansowani i programisci czesto zaprzegaja do pracy istniejace biblioteki przerabiajac programy.
Posluze sie jeszcze raz hipotetycznym przykladem z biblioteka math(operacje matematyczne dla programow w jezyku C). Ktos moze lubowac sie w matematyce i poszukiwac najlepszego sposrod wielu kalkulatorow. Wszystkie one licza to samo i wykorzystuja te same operacje matematyczne. Jednak wielu programistow pisze wlasne biblioteki np moja_math dla “supercalc”. Co wcale nie oznacza ze musimy jej uzywac. Mozemy sprobowac skompilowac program z uzyciem biblioteki math, a jesli sie nie powiedzie lub czesciowo sie powiedzie to przebudowac odpowiednio program.
Sytuacja odwrotna, mamy kalkulator “calc” wykorzystujacy bilbioteke math ale przeczytalismy na jakilinux.org o nowej swietnie napisanej bibliotece super_math(bo jest szybsza i przechowuje liczbe pi do 16 miejsc po przecinku a biblioteka math do 12) dla systemow linux i chcemy zaprzegnac ja do pracy w naszym kalkulatorze “calc”.
Tak sie sklada, ze wszystko da sie zrobic w dziedzinie informatyki… a jesli napotykamy na problem, rozwiazujemy go wprowadzajac kolejny poziom abstrakcji… rodzac nowe problemy, i tak to sie kreci juz.

By: michup

michup — Fri, 06 Jan 2006 22:30:02 +0000

Duzo sie mowi tutaj o zaleznosciach wiec wtrace i swoje dwa grosze. Otoz jesli ktos jeszcze nie wie slowem wstepu…

Kompilator nie posiada wystarczajacych informacji o naszym systemie, zeby samodzielnie przygotowac dzialajacy program. Nowoczesne systemy do zbudowania programow wymagaja bibliotek.
Biblioteka jest zbiorem skompilowanych wczesniej funkcji, ktore mozna dolaczyc do naszego programu- jak operacje matematyczne w bibliotece math (dla jezyka C).
Biblioteki sa wykorzystywane przede wszystkim w trakcie konsolidacji, czyli gdy konsolidator(linkier) tworzy program.
Rozrozniamy dwa typy bibliotek: statyczne(static libraries) i wspoldzielone (shared libraries).
Konsolidujac program z bibliotekami statycznymi, konsolidator kopiuje odpowiednie wycinki kodu maszynowego z biblioteki i wkleja je do pliku wykonywalnego. Dalej plik wynikowy nie potrzebuje juz biblioteki do dzialania. Niestety rozmiary bibliotek statycznych i pamiecio-zernosc wymagaly nowego rozwiazania.
W odpowiedzi wymyslono biblioteki wspoldzielone. Po uruchomieniu programu konsolidowanego z biblioteka wspoldzielona, system laduje kod tej biblioteki do pamieci procesu tylko gdy jest aktualnie potrzebny. Ponadto rozne procesy moga wspoldzielic kod z biblioteki znajdujacy sie obecnie w pamieci.

Biblioteki wspoldzielone sa narzedziem o niezwyklej elastycznosci mimo to mozna ich latwo naduzyc.
Moga nam sie przytrafic 3 zasadnicze nieszczescia:
-brakujace biblioteki
-znaczacy spadek wydajnosci
-nieprawidlowe biblioteki

Wszystkie te problemy pojawia sie w sytuacji zlych nawykow w praktyce instalacyjnej lub/i programistycznej - naduzywanie zmiennej LD_LIBRARY_PATH.
Wpisywanie w nia listy katalogow w poszukiwaniu bibliotek powoduje, ze program ld.so (konsolidator dynamiczny) bedzie w nich szukal bibliotek, zanim zacznie szukac gdzie indziej. W przypadku przeniesienia biblioteki mozna spodziewac sie problemow!
Jezeli ustawimy zmienna LD_LIBRARY_PATH w plikach startowych systemu to moze spowodowac to konflikty i nieprawidlowe dowiazania bibliotek, poniewaz katalogi te beda przeszukiwane na potrzeby kazdego uruchamianego procesu w systemie! Na dodatek spadnie bardzo wydajnosc systemu!

Jezeli ktos jeszcze nie domyslil sie jaki to ma zwiazek z zaleznosciami…
Biblioteki moze napisac kazdy, jest to poprostu zbior mniejszych programow- funkci, procedur wykonujacych pojedyncze scisle okreslone czynnosci. Jednym pisanie programow wychodzi lepiej (najcz. sa to oficjalne produkcje) innym nieco gorzej albo tylko na wlasne potrzeby, ale dziela sie swoim programistycznym dorobkiem (nie oficjalne produkcje).
Czasami nie jest konieczne instalowanie ich wszystkich, bo w koncu ile potrzebujemy bibliotek z operacjami matematycznymi? Odp jednej. Nalezy wiec zwracac uwage na to co sie instaluje. Jezeli programista lub my namieszamy w zmiennej LD_LIBRARY_PATH i na dodatek bedziemy mieli wiele bibliotek z ta sama zawartoscia (lub jeszcze gorzej tylko podobna) to mozemy zrobic niezly smietnik w systemie. Mowiac prosto: programy sie “pogubia” ktorych bibliotek powinny uzywac.

Podsumowujac, zalety instalowania wlasnorecznego:
-mozemy zmienic domyslne ustawienia
-zainstalowane w ten sposob oprogr. najczesciej lepiej znosi aktualizacje systemu
-instalujac pakiety samodzielnie, czesto lepiej poznajemy zasady jego obslugi
-zawsze instalujemy najnowsze wydania pakietow
-pakiety dostosywane sa do naszych potrzeb latwiej poddaja sie procedurze kopii bezpieczenstwa
-pakiety dostosowane do naszych potrzeb mozna latwiej rozprowadzac w sieci

A teraz kilka wad:
-zajmuje to troche czasu
-jezeli tak naprawde nie bedziemy korzystac z pakietu to marnujemy czas (co jest rowniez i zaleta bo wprowadza samodyscyplinke, jezeli naprawde czegos chcesz to osiagniesz cel, inaczej nie warto)
-istnieje prawdopodobienstwo nieprawidlowego skonfigurowania pakietu

Tak wiec na pytanie czy wlasnoreczne instalowanie pakietow odchudzi zasobnosc systemu, odpowiadam tak. Przy instalacji wlasnorecznej nalezy dowiedziec sie:
-jakich bibliotek nasz program potrzebuje
-jak nasz program wyszukuje biblioteki
-jak nalezy konsolidowac program z bibliotekami
-jakie sa najczestsze problemy z bibliotekami
…unikniemy w ten sposob zbednych bibliotek ktore sa prawdziwymi “spaslakami” skracamy rowniez czas wyszukiwania danej biblioteki (przez ld.so) i unikamy ew. bledow i powielania sie bibliotek.

Nieprawda jest, ze wszystkie sugerowane zaleznosci przez systemy zarzadzania plikow sa wymagane do prawidlowej instalacji programu, tylko ze dobieraja one te przewidziane przy standardowej instalacji.
Dla przykladu program IM Kopete, przewidziany dla srodowiska KDE. Wykonalem test na Mandriva 2006 instalujac program Kopete w srodowisku GNOME wraz ze wszystkimi standardowo przewidzianymi zaleznosciami. W efekcie zainstalowal mi cale srodowisko KDE, ktore zajmuje (strzelam ok 500MB). Doprowadzilo to do licznych bledow miedzy srodowiskami graficznymi- przemieszanie z poplataniem.
Ale Kopete dziala, takze systemy zarzadzania pakietami wywiazuja sie z zadan jakie im powierzamy… w swojej ironii oczywiscie. Dlatego sa one cennymi narzedziami i pomocnikami ale tylko w rekach tego, ktory wie jak z nich skorzystac. Zarzadzanie pakietami nie uchroni nikogo przed nauka i wykazaniem checi dowiedzenia sie co to za zaleznosci, co robia i czy sa faktycznie potrzebne.

Nie wazne jak dazysz do celu, wazne ze robisz to z glowa, inaczej nie warto.

By: CierN

CierN — Fri, 06 Jan 2006 18:09:16 +0000

Pozwole sobie wtrącić swoje 3 grosze.
Każdy system ma swoje wdy i zalety.
Kocham slaka za ich brak
Instaluje program :
pakiet instaluje sie a przy pierwszym uruchonieniu wywala błędy ze brak mu teakich a takich bibliotek
dodaje je i po krzyku system działa.
Ze żrudeł: w momęcie kompliacji wyskakuja mi błędy i mowią ze brak jakiś biliotek : efekt robie to samo.
czy to jest zaleta TAK Jeśli system pracuje jako deteskop to duza zaleta

By: michuk

michuk — Fri, 28 Oct 2005 09:01:56 +0000

MacMaster: nie rozumiesz idei zależności w Debianie. Jeśli apt stwierdził że odinstaluje Ci kde to nie znaczy że nagle przestaniesz mieć to środowisko. To znaczy jedynie że odinstalujesz sobie meta-pakiet o nazwie kde, który grupuje wszystkie inne pakiety związane ze środowiskiem KDE.
Innymi słowy:
* apt-get install kde - zainstaluje Ci KDE ze wszystkimi zależnościami
* apt-get remove kde - usunie Ci tylko metapakiet KDE, co w sumie nie zmieni dla Ceibie prawie nic (jedynie jeśli twórcy postanowią dodać jakąś aplikację do metapakietu KDE to apt-get dist-upgrade nie doinstaluje Ci jej, co zrobiłby gdybyś miał zainstalowany metapakiet)

Jeśli chcesz odinstalować całe KDE, to użyj aptitude.

By: MacMaster

MacMaster — Sat, 22 Oct 2005 15:41:09 +0000

Chociażby w debianie lub fedorze. Jak chciałem w fedorze odinstalować niektóre narzędzia kde, to chciało mi wywalic całe środowisko i wiele cennych aplikacji. Co do zależności: jak dla mnie jest to czasem wadą, czasem zaletą.

By: Abraham Mani-Tu

Abraham Mani-Tu — Sat, 22 Oct 2005 15:40:37 +0000

Wielki Programista i Jezus korzystali z zależności i byli szczęśliwi, bo to co Wielki Programista chciał było dobre. Ale Jezus zrezygnował z zależności, nie może trafić na Ziemię i niewiadomo, kiedy złoży obiecane odwiedziny. I co jest lepsze?

By: michux

michux — Sat, 20 Aug 2005 21:01:31 +0000

Chcąc odinstalować jakąś małą aplikację, możemy być zmuszeni do odinstalowania np. całego KDE… Dlatego mimo wszystko wolę Slacka

W jakim systemie masz tak idiotyczne skonstruowane zależności? Ja się z czymś takim nie spotkałem.

By: guitarrizer

guitarrizer — Sat, 20 Aug 2005 21:00:34 +0000

Śledzenie zależności może i jest zaletą podczas instalacji oprogramowania, ale podczas deinstalacji to już się robi z tego koszmar. Chcąc odinstalować jakąś małą aplikację, możemy być zmuszeni do odinstalowania np. całego KDE… Dlatego mimo wszystko wolę Slacka

pzdr

By: slack-user

slack-user — Sat, 20 Aug 2005 20:59:59 +0000

chyba tylko slackware daje domyślną nazwę hosta darkstar

Nie Domyślnie Slackware wyświetla w konsoli cytaty

By: puszczyk

puszczyk — Sat, 20 Aug 2005 20:59:28 +0000

Gwarantuje, że tego zrzut jest ze Slackware.

pio z tym darkstar, to masz racje, ale ewentualnie to mogłem ustawić taką nazwę w debianie

Ten zrzut ekranu zrobiłem po to, żeby nie było tak monotonie; inna kożyść jest taka, że każdy może się przekonać, o tym, że w slacku tryb graficzny nie dosyć że jest, to jeszcze daje się go skonfigurować

By: pio

pio — Sat, 20 Aug 2005 20:58:35 +0000

Ktoś pisał że na zrzucie ekranu nie widać że to slack, tak do końca to nie jestem pewien, ale na 99% chyba tylko slackware daje domyślną nazwę hosta darkstar, co widać na konsoli.

By: NatterX

NatterX — Sat, 20 Aug 2005 20:58:05 +0000

Każdy używa takiej dytrybucji jaka mu “pasi”.
Za zależnościami przemawia łatwość instalacji, która jest zaletą dla nowych user’ów (a nie wykluczone, że i dla starych ). Jednak taki automatyczny “cymbergraj” wrzuca nam do systemu sporo niepotrzebnego “śmiecia”. Jeśli ktoś posiada 120GB dysk +1GB ram i procka w okolicach 3GHz to mu to nie przeszkadza.
Podobnie jest z automatycznym tworzeniem skryptów.
Akurat ta ostatnia możliwość napawa mnie sporym niepokojem. Bowiem skrypty podobnie jak programy w C powinny być pisane przez kogoś kto wie co czyni. A to jest niezbyt często występującą cechą. Nie chciałbym tutaj zaczynać dyskusji na temat niezawodności i jakości oprogramowania (choć warto byłoby to poruszyć znacznie szerzej).
Wracając do tematu. Na jednym biegunie mamy dystrybucje obsługujące pakiety a na drugim te, które tego nie czynią.
Ten drugi przypadek raczej jest dla tech, którzy lubią bądź muszą wybebeszyć system by podnieść go z popiołów. Wszak muszą wiedzieć co robią.
Jeśli Linux ma stać na P133+64MB Ram + 256MB CF i zbierać/transmitować dane bez przerwy przez 18 miesięcy to nie zalecałbym Fedory. Tak przy okazji postawiłem Slack’a 10.0 na 64MB CF i zostało jeszcze trochę miejsca na dane (oczywiście bez X’ów :-)).
Ta dwoistość się nie wyklucza. U mnie na jednym komputerze zainstalowany jest Slack 10.0 (trochę przebudowany) a na drugim Mandrake 10.0 (mocno przebudowany). A wszystko dla tego, że różne rzeczy robię na różnych komputerach.
Dlatego: Nade wszystko wygoda!