Re: Tempo startu X-ów
On Thu, Oct 27, 2005 at 01:13:30AM +0200, Marek Zakowicz wrote: > Chyba nie przeczytałeś dokładnie tego co napisałem: znaki 2 i 3 w nazwach > skrótów z katalogów /etc/rc?.d/ to np. "20" w skrócie S20xdm z > katalogu /etc/rc5.d. Tak, masz rację. Znak zapytania w nazwie katalogu sugerował, że w to właśnie miejsce należy wstawić wspomniane przez ciebie ,,2 i 3'' :) Pozdrawiam, Adam -- Adam Byrtek / Alpha ,,Każdy ideał w ciele jest trywialny'' -- prawdy algebraiczne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
On Wed, 26 Oct 2005, Krzysztof Matusik wrote: [...] Ktoś wspomniał gdzie indziej, że ważna jest tylko kolejność runleveli- co jest oczywiście nieprawdą: wyobraźmy sobie sytuację uruchamiania równolegle skryptów podnoszenia interfaców sieciowych i usług sieciowych- można spodziewać się, że te drugie nie zostaną uruchomiane właściwie (np. gniazda nie zostaną ustanowione). Jeśli tym kimś miałem być ja, to nie dokładnie przeczytałeś mój list, albo ja się nie wyraziłem dość jasno. Pisałem nie o runlevelach tylko o dwucyfrowych kodach, określających kolejność uruchamiania skryptów startowych [update-rc.d(8)]. W oparciu o ten kod, skrypty mają zagwarantowane, że np. S19* są wykonywane przed S20*, ale skrypty mające ten sam kod np. z prefiksem S20 mogą być wykonane równolegle (nie ma między nimi zależności). Na tym polegała też moja modyfikacja, skryptu /etc/init.d/rc, że skrypty z tym samym prefiksem uruchamiam współbieżnie, natomiast przed rozpoczęciem uruchamiania skryptów z nowym prefiksem, czekam na zakończenie wszystkich skryptów uruchomionych wcześniej... Kiedyś próbowałem modyfikować skrypty startowe, tak by część zadań uruchamiała się równolegle. Jest spory zysk na czasie i wcale nie jest potrzebna maszyna wieloprocesorowa. Możesz podać więcej szczegółów - bo ja uzyskałem duży zysk na czasie, tylko w wariancie bez synchronizacji; po dodaniu synchronizacji (jak powyżej), zysk był na poziomie 6%... Jednak nie można zastosować tego do dystrybucji, bo każda maszyna będzie zachowywać się inaczej- jak podejrzewam. Problem leży w samym działaniu INITa i konstrukcji /etc/rc.d/; skrypty wykonywane są szeregowo. Potrzebny byłby program, którego config wyglądałby trochę jak relacyjna baza danych. Tak to wygląda w MS Windows - deklarujesz zależności pomiędzy usługami. Tworzą one taki skierowany graf acykliczny (DIG). Żeby rozpocząć uruchamianie usług zapewne wykonywane jest sortowanie topologiczne i to co jest na jego wyjściu jest równoważne liście z danego /etc/rc?.d na systemach *nix'owych. Nie wątpię, że taka deklaratywna konfiguracja jest prostsza w utrzymaniu niż podana wprost lista skryptów, ale nie demonizowałbym różnicy. W końcu mówimy o kilkunastu - kilkudziesięciu skryptach. Oczywiście mam nadzieje, że kiedyś i w Debianie pojawi się konfiguracja deklaratywna, choćby jako coś z czego generowane są katalogi odsyłaczy /etc/rc?.d... Pozdrawiam, Marek -- "Niewiara jest jak wiara na miarę" Raz, Dwa, Trzy
Re: Tempo startu X-ów
On Wed, 26 Oct 2005, Adam Byrtek wrote: On Wed, Oct 26, 2005 at 10:59:42AM +0200, Marek Zakowicz wrote: Moim skromnym zdaniem synchronizacja jest istotna, ale tylko na etapie przechodzenia pomiędzy różnymi kodami (znaki 2 i 3 w nazwach skrótów w /etc/rc?.d/), służącymi właśnie do określania kolejności. Te liczby nie określają kolejności uruchamiania, a numer runlevel. Domyślny runlevel można łatwo sprawdzić: Chyba nie przeczytałeś dokładnie tego co napisałem: znaki 2 i 3 w nazwach skrótów z katalogów /etc/rc?.d/ to np. "20" w skrócie S20xdm z katalogu /etc/rc5.d. Oczywiście znaki te to nie jest runlevel tylko kod używany przez init do określenia kolejności uruchamiania skryptów [update-rc.d (8)]... Pozdrawiam, Marek -- "No co Ty, chyba nie wierzysz w mamę? Kto to w ogóle miałby być?" fragment dyskusji prowadzonej przez bliźniaków w brzuchu matki (obserwator nieznany)
Re: Tempo startu X-ów
On Wed, Oct 26, 2005 at 08:06:26PM +0200, Krzysztof Matusik wrote: > Problem leży w samym działaniu INITa i konstrukcji /etc/rc.d/; skrypty > wykonywane są szeregowo. Potrzebny byłby program, którego config wyglądałby > trochę jak relacyjna baza danych. Bądź też- owszem, uruchamiać skrypty > równolegle, jednak same skrypty musiałyby zawierać mechanizmy (np. instrukcje > warunkowe), które chroniłyby je przed niebezpieczeństwami takiego zabiegu. Gentoo posiada takie rozwiązanie (skrypty startowe mogą mieć zależności), jednak (na razie) domyślnie skrypty uruchamiane są szeregowo, można to zmienić ustawiając zmienną RC_PARALLEL_STARTUP w /etc/conf.d/rc. Wracając do Debiana, istnieje szereg następców mocno już przestarzałego inita, zapewniających podobną funkcjonalność. Pozdrawiam, Alpha -- Adam Byrtek / Alpha ,,Każdy ideał w ciele jest trywialny'' -- prawdy algebraiczne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
On Wed, Oct 26, 2005 at 10:59:42AM +0200, Marek Zakowicz wrote: > Moim skromnym zdaniem synchronizacja jest istotna, ale tylko na etapie > przechodzenia pomiędzy różnymi kodami (znaki 2 i 3 w nazwach skrótów w > /etc/rc?.d/), służącymi właśnie do określania kolejności. Te liczby nie określają kolejności uruchamiania, a numer runlevel. Domyślny runlevel można łatwo sprawdzić: $ grep initdefault /etc/inittab -- Adam Byrtek / Alpha ,,Każdy ideał w ciele jest trywialny'' -- prawdy algebraiczne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
Dnia 26-10-2005, śro o godzinie 20:06 +0200, Krzysztof Matusik napisał(a): > Dnia środa, 26 października 2005 01:10, Waldemar Dworakowski napisał: > > Rafał Rawicki wrote: > > > Szymon Nieradka napisał(a): > > >> Łukasz Pieczara napisał(a): > > >>> http://www.hoeg.org/blog/2005/07/27/fast-booting-debian/ > > >> > > >> Opis jest do Sarge. W Etch trochę się zmieniło. Nie mam takiej linijki > > >> (startup $i start). Domyślam się, że teraz robi to samo: > > >> > > >> startup $ACTION $SCRIPTS > > >> > > >> ale ona prawdopodobnie odpowiada nie tylko za start ale i za stop. > > >> I tu pojawia się niebezpieczeństwo, że np. zanim zatrzymam jakąś > > >> usługę system będzie próbował odmontować dyski. To się zapewne nie > > >> uda, więc chwilę później będzie elegancki shutdown... :( > > > > > > A jakby dodać tam instrukcję warunkową? > > > I odpalać w tło tylko przy starcie :) > > > > IMHO troche ryzykowne. Nie wiem jak sa zrobione semafory > > synchronizacji dostepu do zasobow i jak beda przebiegaly procesy - > > szczegolnie na maszynach wieloprocesorowych (choc tam zysk moglby byc > > najwiekszy). IMHO nie bez powodow ktos wymyslil taka a nie inna > > sekwencje ladowania... > > > > Hmm. To wszystko wykracza poza czas bootowania samych X-ów ale przyznaję, że > sam mocno nad tym dumałem. Ktoś wspomniał gdzie indziej, że ważna jest tylko > kolejność runleveli- co jest oczywiście nieprawdą: > wyobraźmy sobie sytuację uruchamiania równolegle skryptów podnoszenia > interfaców sieciowych i usług sieciowych- można spodziewać się, że te drugie > nie zostaną uruchomiane właściwie (np. gniazda nie zostaną ustanowione). > Kiedyś próbowałem modyfikować skrypty startowe, tak by część zadań > uruchamiała > się równolegle. Jest spory zysk na czasie i wcale nie jest potrzebna maszyna > wieloprocesorowa. Jednak nie można zastosować tego do dystrybucji, bo każda > maszyna będzie zachowywać się inaczej- jak podejrzewam. > Problem leży w samym działaniu INITa i konstrukcji /etc/rc.d/; skrypty > wykonywane są szeregowo. Potrzebny byłby program, którego config wyglądałby > trochę jak relacyjna baza danych. Bądź też- owszem, uruchamiać skrypty > równolegle, jednak same skrypty musiałyby zawierać mechanizmy (np. instrukcje > warunkowe), które chroniłyby je przed niebezpieczeństwami takiego zabiegu. > Koniec końców warto wymienić sysV-init na coś lepszego. > Dostrzegam, że były dyskusje na debian-devel w tej kwestii. > Czy coś z tego wynikło? > > Ps. Polecam: > http://lists.debian.org/debian-devel/2004/01/msg00972.html > > Kolesie z GNOME pracują nad systemem uruchamiania usług i ontrolowania ich poprzez D-BUS, z takimi rzeczami jak Depends i Provides. Trochę potrwa zanim to powstanie, a na wprowadzenie tego do Debiana poczekamy jeszcze parę lat, ale zapowiada się interesująco. Nasze wnuki skorzystają ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
Dnia środa, 26 października 2005 01:10, Waldemar Dworakowski napisał: > Rafał Rawicki wrote: > > Szymon Nieradka napisał(a): > >> Łukasz Pieczara napisał(a): > >>> http://www.hoeg.org/blog/2005/07/27/fast-booting-debian/ > >> > >> Opis jest do Sarge. W Etch trochę się zmieniło. Nie mam takiej linijki > >> (startup $i start). Domyślam się, że teraz robi to samo: > >> > >> startup $ACTION $SCRIPTS > >> > >> ale ona prawdopodobnie odpowiada nie tylko za start ale i za stop. > >> I tu pojawia się niebezpieczeństwo, że np. zanim zatrzymam jakąś > >> usługę system będzie próbował odmontować dyski. To się zapewne nie > >> uda, więc chwilę później będzie elegancki shutdown... :( > > > > A jakby dodać tam instrukcję warunkową? > > I odpalać w tło tylko przy starcie :) > > IMHO troche ryzykowne. Nie wiem jak sa zrobione semafory > synchronizacji dostepu do zasobow i jak beda przebiegaly procesy - > szczegolnie na maszynach wieloprocesorowych (choc tam zysk moglby byc > najwiekszy). IMHO nie bez powodow ktos wymyslil taka a nie inna > sekwencje ladowania... > Hmm. To wszystko wykracza poza czas bootowania samych X-ów ale przyznaję, że sam mocno nad tym dumałem. Ktoś wspomniał gdzie indziej, że ważna jest tylko kolejność runleveli- co jest oczywiście nieprawdą: wyobraźmy sobie sytuację uruchamiania równolegle skryptów podnoszenia interfaców sieciowych i usług sieciowych- można spodziewać się, że te drugie nie zostaną uruchomiane właściwie (np. gniazda nie zostaną ustanowione). Kiedyś próbowałem modyfikować skrypty startowe, tak by część zadań uruchamiała się równolegle. Jest spory zysk na czasie i wcale nie jest potrzebna maszyna wieloprocesorowa. Jednak nie można zastosować tego do dystrybucji, bo każda maszyna będzie zachowywać się inaczej- jak podejrzewam. Problem leży w samym działaniu INITa i konstrukcji /etc/rc.d/; skrypty wykonywane są szeregowo. Potrzebny byłby program, którego config wyglądałby trochę jak relacyjna baza danych. Bądź też- owszem, uruchamiać skrypty równolegle, jednak same skrypty musiałyby zawierać mechanizmy (np. instrukcje warunkowe), które chroniłyby je przed niebezpieczeństwami takiego zabiegu. Koniec końców warto wymienić sysV-init na coś lepszego. Dostrzegam, że były dyskusje na debian-devel w tej kwestii. Czy coś z tego wynikło? Ps. Polecam: http://lists.debian.org/debian-devel/2004/01/msg00972.html
Re: Tempo startu X-ów
On Wed, 26 Oct 2005, Waldemar Dworakowski wrote: IMHO troche ryzykowne. Nie wiem jak sa zrobione semafory synchronizacji dostepu do zasobow i jak beda przebiegaly procesy - szczegolnie na maszynach wieloprocesorowych (choc tam zysk moglby byc najwiekszy). IMHO nie bez powodow ktos wymyslil taka a nie inna sekwencje ladowania... Moim skromnym zdaniem synchronizacja jest istotna, ale tylko na etapie przechodzenia pomiędzy różnymi kodami (znaki 2 i 3 w nazwach skrótów w /etc/rc?.d/), służącymi właśnie do określania kolejności. Niestety po uwzględnieniu takiej synchronizacji, wartość porady dotyczącej uruchamiania w tle znacząco maleje (dla testowanego przeze mnie systemu jest to około 6%, czyli w granicach błędu - bardziej znaczące wyniki dało kiedyś zastąpienie sh->bash przez sh->dash) natomiast jest zauważalny wpływ fc-cache (dzięki za info :) ). Oto wyniki testów: Mierzyłem (/var/log/syslog) dwa czasy do rozpoczęcia startu X i do uruchomienia kdm. Przed poprawkami: 08:19:34 - 08:19:19 = 15 s | 08:19:56 - 08:19:19 = 37 s Po poprawce /etc/init.d/rc związanej z uruchamianiem demonów w tle: 08:58:03 - 08:57:56 = 7 s | 08:58:23 - 08:57:56 = 27 s Po fc-cache: 09:18:40 - 09:18:34 = 6 s | 09:18:50 - 09:18:34 = 16 s Po uwzględnieniu synchronizacji w /etc/init.d/rc przy zmianie kodu: 10:31:39 - 10:31:25 = 14 s | 10:31:48 - 10:31:25 = 23 s Pozdrawiam, Marek -- "Zasoby ludzkie" - to chyba jakieś pojęcie z propagandy Hitlera? - mydło, guziki...
Re: Tempo startu X-ów
Dnia 26-10-2005, śro o godzinie 01:10 +0200, Waldemar Dworakowski napisał(a): > Przyznam tez iz wedle mnie wkompilowanie uzywanych (i tylko uzywanych) > driverow w jadro powinno pomoc na wydajnosc. A czemu by tak miało być? -- Pozdrawiam, Krzysiek Kiełczewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
Rafał Rawicki wrote: Szymon Nieradka napisał(a): Łukasz Pieczara napisał(a): http://www.hoeg.org/blog/2005/07/27/fast-booting-debian/ Opis jest do Sarge. W Etch trochę się zmieniło. Nie mam takiej linijki (startup $i start). Domyślam się, że teraz robi to samo: startup $ACTION $SCRIPTS ale ona prawdopodobnie odpowiada nie tylko za start ale i za stop. I tu pojawia się niebezpieczeństwo, że np. zanim zatrzymam jakąś usługę system będzie próbował odmontować dyski. To się zapewne nie uda, więc chwilę później będzie elegancki shutdown... :( A jakby dodać tam instrukcję warunkową? I odpalać w tło tylko przy starcie :) IMHO troche ryzykowne. Nie wiem jak sa zrobione semafory synchronizacji dostepu do zasobow i jak beda przebiegaly procesy - szczegolnie na maszynach wieloprocesorowych (choc tam zysk moglby byc najwiekszy). IMHO nie bez powodow ktos wymyslil taka a nie inna sekwencje ladowania... Przyznam tez iz wedle mnie wkompilowanie uzywanych (i tylko uzywanych) driverow w jadro powinno pomoc na wydajnosc. Czy ktos moglby powiedziec dlaczego jest inaczej (jesli jest)? WD
Re: Tempo startu X-ów
Szymon Nieradka napisał(a): Łukasz Pieczara napisał(a): http://www.hoeg.org/blog/2005/07/27/fast-booting-debian/ Opis jest do Sarge. W Etch trochę się zmieniło. Nie mam takiej linijki (startup $i start). Domyślam się, że teraz robi to samo: startup $ACTION $SCRIPTS ale ona prawdopodobnie odpowiada nie tylko za start ale i za stop. I tu pojawia się niebezpieczeństwo, że np. zanim zatrzymam jakąś usługę system będzie próbował odmontować dyski. To się zapewne nie uda, więc chwilę później będzie elegancki shutdown... :( A jakby dodać tam instrukcję warunkową? I odpalać w tło tylko przy starcie :) -- Podrawiam Rafał Rawicki [EMAIL PROTECTED] | jid: rawicki//chrome.pl | gg: 5245773 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
Krzysztof Matusik wrote: Dnia wtorek, 25 października 2005 13:48, Szymon Nieradka napisał: $ dpkg-reconfigure fontconfig Heheh. Ot co! Pomogło. Na czym polega sekret? otoz ja kiedys mialem cos podobnego i wykrylem, ze rekonfiguracja fontconfig to duzo za duzo ;) wystarczy wydanie polecenia fc-cache i po krzyku :) Marcin -- Marcin Błażejowski GG# 203127 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
Dnia wtorek, 25 października 2005 13:48, Szymon Nieradka napisał: > $ dpkg-reconfigure fontconfig Heheh. Ot co! Pomogło. Na czym polega sekret?
Re: Tempo startu X-ów
[EMAIL PROTECTED] wrote: Moim skromnym zdaniem lepiej jest skompilować wszystko jako moduły,wyrzucić narzędzia typu hotplug,załadowąć większość potrzebnych modułów (z wyjąkiem drivera karty graficznej i klawiatury) już po starcie serwera Xorg. Generalnie jak kiedys czytalem w podreczniku instalcji debiana o ile dobrze pamietam, byla mowa ze sterowniki ktore sa niezbedne do uruchmoniena systemu wrzucamy w jadro, reszta sterwonikow jesli nie jest konieczna przy starcie, a wykorzystujemy je od czasu do czasu moze byc ładowana jako moduł. Jest jeszcze opcja z: http://smarden.sunsite.dk/runit/ apt-get install runit Podobno przyspiesza start, mnie sie jednak nie chcialo z tym bawic. Jesli ktos ma duzo samozaparcia, moze sprawdzic ;-) Łukasz Pieczara -- jid: [EMAIL PROTECTED] gg: 3669560 pgp: 0x698F1CA2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
Łukasz Pieczara napisał(a): http://www.hoeg.org/blog/2005/07/27/fast-booting-debian/ Opis jest do Sarge. W Etch trochę się zmieniło. Nie mam takiej linijki (startup $i start). Domyślam się, że teraz robi to samo: startup $ACTION $SCRIPTS ale ona prawdopodobnie odpowiada nie tylko za start ale i za stop. I tu pojawia się niebezpieczeństwo, że np. zanim zatrzymam jakąś usługę system będzie próbował odmontować dyski. To się zapewne nie uda, więc chwilę później będzie elegancki shutdown... :( -- /// Szymon Nieradka /// Biuro Informatyki i Telekomunikacji /// Stocznia Szczecińska Nowa Sp. z o.o.
Re: Tempo startu X-ów
Wiadomość Oryginalna Od: Łukasz Pieczara <[EMAIL PROTECTED]> Do: debian-user-polish@lists.debian.org Data: Tue, 25 Oct 2005 13:26:42 +0200 Temat: Re: Tempo startu X-ów > Krzysztof Matusik wrote: > zaraz gryzę się w > > język, bo bezcelowe jest tłumaczenie, że serwer X, to nie Debian, a Debian to > > nie Linux, i przeciętnych użytkowników w ogóle te dywagacje nie interesują. > > Interesuje ich sprawność działania. > > > > Co robić? > > Specjalnie nie pomoge (szczegolnie jest chodzi o Xy), ale jesli o > szybszy start Linuxa, to taki trick swego czasu znalazlem w sieci: > > http://www.hoeg.org/blog/2005/07/27/fast-booting-debian/ > > Łukasz Pieczara Jeśli chodzi o sam start debiana. na podanej stronce jest napisane aby,kompilować drivery do kernela, myślę że to już wydłuża proces startu o nawet 20 sekund ! Moim skromnym zdaniem lepiej jest skompilować wszystko jako moduły,wyrzucić narzędzia typu hotplug,załadowąć większość potrzebnych modułów (z wyjąkiem drivera karty graficznej i klawiatury) już po starcie serwera Xorg. Od gruba do startu Xorg,wchodze w 8 sek. I tu jest rzeczywiście DRAMAT czemu ten serwer jest tak wolny i ładuje sie kolejne 12 sek.(stosuje automatyczne logowanie przez gdm i menedzer okien fluxbox,GDM-z moich testów wynika że zwalnia start tylko 1s), wydaję mi się że troche zwolił się start X po zainstalowaniu dużej ilości czcionek. Wyłączając moduły w sekcji modules w pliku xorg.conf niewiele można zdziałać ... załączam moje pliki rcS.d,rc2.d,i kilka moich plików z init.d rc.tar Description: Unix tar archive
Re: Tempo startu X-ów
Krzysztof Matusik napisał(a): Poruszam dosyć szeroki temat. Szczególnie po instalacji xorg można poczuć tą potworną przypadłość- dłuuugi start serwera X. Co to jest? Są jakieś sposoby na przyspieszenie tego procesu? $ dpkg-reconfigure fontconfig :) -- /// Szymon Nieradka /// Biuro Informatyki i Telekomunikacji /// Stocznia Szczecińska Nowa Sp. z o.o.
Re: Tempo startu X-ów
Dnia wtorek, 25 października 2005 13:25, Wojciech Ziniewicz napisał: > U mnie zarówno na xorgu jak na xfree na maszynie Celek 1.2GHz + 1 GB > RAM wszystko włącza się obiektywnie "szybko" (nie wolniej niż mój > winxp w pracy) z zastrzeżeniem że Xorg włącza sie bardzo szybko > (szybciej od xfree) > > może chodzi raczej o włączanie się KDE/GNOME/another_wm ? Hmm, może zatem to KDM/GDM? Jest ktoś, kto ma tutaj jakieś spostrzeżenia? Na przykład porównanie z XDM? Ja dawno już nie używałem ni XDM ni startu z konsoli. Ja zwykle pracuję z mocno 'dociążonym' KDE, nie narzekam wcale- nawet spore sesje przywracają się całkiem sprawnie. Pozdrawiam
Re: Tempo startu X-ów
Dnia Tue, Oct 25, 2005 at 01:20:10PM +0200, Krzysztof Matusik napisał(a): [...] > Poruszam dosyć szeroki temat. Szczególnie po instalacji xorg można poczuć tą > potworną przypadłość- dłuuugi start serwera X. Co to jest? Są jakieś sposoby > na przyspieszenie tego procesu? Czy to kwestia ładowanych modułów? Czy można > to jakoś racjonalnie podejść? > Przy GHzowych procesorach to jest jeszcze znośne, ale przy starszych > maszynach > microsoft stanowi niedościgniony wzór. Potwierdzam, u mnie tez tak jest. Mam Celerona 333MHz (czyli złomiaczek juz niezły) z 256MB RAMu, NVidia z 32 MB RAMu. Przejście z woody'ego na Sarge, to jakby kto mojemu złomiaczkowi na garb wrzucił kilka dodatkowych worków piasku. I żeby było jasne - żadnego GNOME/KDE (nawet core bibliotek nie mam zainstalowanych). Zgłoszenie się Xów po uruchomieniu kompa (lub nawet wylogowaniu usera!) to dobra minuta. Tragedia, ale niestety Sarge oferuje pare rzeczy, dla których jestem gotowy sie pomęczyć. Żona strasznie narzeka ;-)... pozdrawiam -- ~QLIVER~~~Marcin Landowski _ *\ *\ ~~~GG:6509957, Tleen~~~ *_|o|[EMAIL PROTECTED]@koti.pl~~ ~~8-\___/ ~~~poczta.wp.pl~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
Krzysztof Matusik wrote: zaraz gryzę się w język, bo bezcelowe jest tłumaczenie, że serwer X, to nie Debian, a Debian to nie Linux, i przeciętnych użytkowników w ogóle te dywagacje nie interesują. Interesuje ich sprawność działania. Co robić? Specjalnie nie pomoge (szczegolnie jest chodzi o Xy), ale jesli o szybszy start Linuxa, to taki trick swego czasu znalazlem w sieci: http://www.hoeg.org/blog/2005/07/27/fast-booting-debian/ Łukasz Pieczara -- jid: [EMAIL PROTECTED] gg: 3669560 pgp: 0x698F1CA2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tempo startu X-ów
2005/10/25, Krzysztof Matusik <[EMAIL PROTECTED]>: > Witam. > > Poruszam dosyć szeroki temat. Szczególnie po instalacji xorg można poczuć tą > potworną przypadłość- dłuuugi start serwera X. Co to jest? Są jakieś sposoby > na przyspieszenie tego procesu? Czy to kwestia ładowanych modułów? Czy można > to jakoś racjonalnie podejść? > Przy GHzowych procesorach to jest jeszcze znośne, ale przy starszych maszynach > microsoft stanowi niedościgniony wzór. U mnie zarówno na xorgu jak na xfree na maszynie Celek 1.2GHz + 1 GB RAM wszystko włącza się obiektywnie "szybko" (nie wolniej niż mój winxp w pracy) z zastrzeżeniem że Xorg włącza sie bardzo szybko (szybciej od xfree) może chodzi raczej o włączanie się KDE/GNOME/another_wm ? -- Pozdrawiam, Wojciech Ziniewicz | [EMAIL PROTECTED] Powered by google.com | [wanna gmail?]
Tempo startu X-ów
Witam. Poruszam dosyć szeroki temat. Szczególnie po instalacji xorg można poczuć tą potworną przypadłość- dłuuugi start serwera X. Co to jest? Są jakieś sposoby na przyspieszenie tego procesu? Czy to kwestia ładowanych modułów? Czy można to jakoś racjonalnie podejść? Przy GHzowych procesorach to jest jeszcze znośne, ale przy starszych maszynach microsoft stanowi niedościgniony wzór. Myślę, że parę osób słyszało tą argumentację: "Linux strasznie długo się uruchamia". Ja zaraz gryzę się w język, bo bezcelowe jest tłumaczenie, że serwer X, to nie Debian, a Debian to nie Linux, i przeciętnych użytkowników w ogóle te dywagacje nie interesują. Interesuje ich sprawność działania. Co robić?
