# baselayout-2.0.0_alpha1

## Sławomir Gąsiorowski

Witam

Nie udzielam się wiele na forum, ale chciałbym podzielić się z innymi gentoo entuzjastami wrażeniami po zaktualizacji baselayout do wersji 2.0.0_alfa1. Chłopaki zrobili kawał porządnej roboty - przepisali cały ociężały i powolny podsystem skryptów init'a (rc, depscan.sh, runscript.sh, functions.sh i inne) z bash'a i awk do C. Efekt jest taki jak przy initng - znaczny kop przy starcie systemu z tą różnicą, że baselayout jest nadal w pełni kompatybilne ze starą specyfikacją skryptów init w gentoo. Polecam wszystkim aby wypróbowali nowy baselayout. U mnie działa znakomicie. Przy włączonej opcji PARALLEL_STARTUP="yes" cały system (cups, hal, dbus, firewall, samba, ssh łącznie z kdm) wstaje w 25-30 sekund. Co więcej, z funkcji podsystemu rc korzysta też portage, więc i tutaj można zauwazyć pewien zysk, ale raczej słabo zauważalny.

Niedawno, pół roku temu zainstalowałem z ciekawości gentoo (2006.1 z baselayout 1.12) na P75 z 16 MB ram'u. Instalowałem oczywiście z binarek, które przygotowałem wcześniej pod Pentium na mocniejszym sprzecie.  System w trybie single user uruchamiał się strasznie powoli (około 10minut) co wywołało u mnie lekki szok. Pobieżna analiza wykazała że lwia część czasu wykonania pojedynczego skryptu /etc/init.d/skrypt (start,stop) to  kilkukrotne przetworzenie różnorakich skryptów bash, które za każdym razem wywołują inne skrypty bash, które wywołują skrypty awk... Dodam też że skrypt init.d był pusty, tzn, nie wykonywał nic. Jeśli dodamy do tego opcję równoległego startu tychże skryptów to wychodzi z tego niezła kaszana i 100% zajętości procka. Musiałem więc napisać własne skrypty rc dla init'a które po prostu uruchamiałby usługi bez całego obliczania kolejności, zależności itp... Całe szczęście już tak nie będzie, bowiem nowe baselayout jest już gotowe do testowania.

Przy okazji myślę, że powodzenie przepisania podsystemu skryptów init'a z basha i awk do C powinien na nowo ożywic dyskusję nad tematem wykonania podobnej pracy z podsystemem portage, czyli przepisania go, lub jego najbardziej skomplikowanych składników z pythona do C lub C++. Wiem, że na różnych forach toczyły się już zacięte dyskusje zwolenników i przeciwników tej ścieżki rozwoju Gentoo. Myślę że pomysł nie jest zły, wystarczy wypróbować pakiet portage-utils, który implementuje popularne funkcje zarządzania bazą portage w języku C i działa niesamowiecie szybko. 

Moim zdaniem przepisanie portage do C to konieczność, to znak czasu. Gentoo musi kusić nie tylko filozofią i koncepcją, lecz również szybkością działania niezaleznie od tego czy Xorg zostanie skompilowane z takimi czy innymi flagami. W ciągu kilku lat komputery stały się kilka razy szbsze, jednak ja podczas uzywania portage tego nie zauważam. Rozwój portage, dodawanie nowych funkcji zjada zasoby, teraz nawet na 3GHz Xeonie z 1GB Ramu wykonanie emerge -p --update --deep --newuse --world zajmuje sporo czasu. Pora na to, abysmy w końcu dostrzegli że mamy komputery 3 razy szybsze niż 3 lata temu. Pierwszy krok został juz wykonany- gentoo uruchamia się najszybciej spośród znanych mi dystrybucji linuxa. Drugi krok to porządki w portage. Nie uwżam przy tym, ze nalezy porzucić ścieżkę rozwoju portage w pythonie. Praktyka dowiodła że w ten sposób stworzono bardzo stabilny i niesamowicie świetny projekt. Po prostu to co zjada najwięcej zasobów, to co jest najcięższe powinno zostać maksymalnie zoptymalizowane. 

Mam nadzieję że kiedyś języki interpretowane znikna z profilu systemowego gentoo. Wtedy będziemy mogli powiedzieć że gentoo linux jest nie tylko potencjalnie najbardziej optymalnym linuxem (po kompilacji), ale także, że jest najszybszym linuxem pod każdym względem.

To tyle. Pozdrawiam serdecznie

----------

## lukas16

Co do przepisywania wszystkiego na C/C++ to jest już od dłuższego czasu menadżer pakietów oparty na C++ paludis --> https://forums.gentoo.org/viewtopic-t-556484.html więc wszystko zmierza ku dobrej drodze   :Smile: 

----------

## Sławomir Gąsiorowski

Słyszałem o projekcie, bardzo fajnie, że istnieje alternatywa. Przydałaby się jednak taka implementacja, która nie musiałaby zmieniać przyzwyczajeń użytkowników oraz przepisywania plików konfiguracyjnych... Może niedługo doczekamy się pełnego zamiennika portage, takiego jak baselayout. Tym czasem inicjatywa jak najbardziej  warta uwagi - wypróbuję na pewno tego paludis'a.

Pozdrawiam

----------

## canni

Paludis ma funkcjonalność która pozwala w większości na korzystanie z konfiguracji portage (jak np. czytanie /etc/portage) ale ta funkcjonalność jest jeszcze eksperymentalna i narazie nie działa zbyt dobrze, ale prawdopodobnie doprowadzą to do działania  :Smile: 

----------

## Vegan

Co do tego nowego baselauout kompletnie wywalilo mi skrypt net.eth0 , mam net przez dhcp z routera jak to naprawic pod nowym baselayoutem ?

----------

## canni

```
ln -sf /etc/init.d/net.lo /etc/init.d/net.eth0
```

 :Wink: 

----------

## garwol

wystarczy odmaskowac ten nowy baselayout w package.unmask czy trzeba jeszcze jakies dodatkowe "czynnosci migracyje" przeprowadzic?  :Very Happy:  i czy duze jest prawdopodobienstwo ze po tym mi system nie wstanie?  :Rolling Eyes: 

----------

## Sławomir Gąsiorowski

Ja tak zrobiłem, odmaskowałem w package.unmask i package.keywords baselayout i bodajże makedev. Potem zarchiwizowałem sobie stary baselayout na wszelki wypadek i zapuściłem kompilację.

Instalka ebuild robi całą migrację, o czym dokładnie informuje na końcu procesu instalacji. Moim zdaniem ryzyka nie ma. System wstanie, ale może sie okazać, że trzeba jeszcze coś dokonfigurować, pojawią się jakieś dziwne błedy, ale /sbin/rc zawsze powinien wykonac się poprawnie. W razie niemca to w grub'ie podczas startu dopisuje init=/bin/bash i wtedy diagnozuje problem, ale to dla hardcoreowców  :Smile:  U mnie na przykład zachowało sie kilka plików z /lib/rcscripts/net/ ze starego baselayout i ich nazwy w kontekście błędu wyświetlały się podczas startu skryptów sieciowych. Wcześniej dla pewności sprawdziem czy nie ma tych plików na liście w var/db/pkg/sys-apps/baselayout_2.0.0_alpha1/CONTENTS i skasowałem je...

Dodatkowo miałem problem z skryptem net.eth0, ale to dlatego że został on całkowicie przez programistów przepisany, a jego poprzednie kopie i dowiązania ebuild skasował. Poza tym nie znalazłem problemów. Należy pamiętac o uaktualnieniu wszystkich plików o jakie prosi dispatch-conf, lub etc-update.

Pozdrawiam

----------

## Paczesiowa

ja tam odradzam. wcale szybkosci nie odczulem (moze dlatego ze mam cos troche szybszego niz p100) jedyne co to kilkanascie errorow podczas startu (nie wiem czy faktycznie cos nie dziala czy tylko sobie pisze z nudow) no i jedna rzecz ktora nie dziala to vmware za cholere nie chce sie uruchomic. trzeba poczekac az bedzie chociaz ~x86 i poprawia inne pliki z init.d zeby sie dalo uzywac tego.

----------

## XianN

Ja mam ten baselayout i dziala bez problemow. Chociaz wzrostu wydajnosci rzeczywiscie nie widze...

----------

## Sławomir Gąsiorowski

Na sprzęcie high-end, a za taki można uważać każdy obecnie dostępne składaki PC rzeczywiście można wielkiej różnicy nie zauważyć. Zauważalne jest, przynajmniej dla mnie to, że cały podsystem rc po przepisaniu w C jest o niebo lżejszy, a naprawdę nie lubię marnowania cykli procesora... W bash'owo awk'owym wydaniu przetwarzanie skryptów bardzo mocno obciąża procesor - nawet na moim 1,8GHz Athlonie jest to odczuwalne. 

Jak ktoś chce sprawdzić, to może sobie zapętlić wykonanie instrukcji depscan.sh i zobaczyć top'em ile procent procka to zjada. Dodam tylko że drugie uruchomienie depscan.sh nie robi teoretycznie nic, w rzeczywistości nieustannie sprawdza wszystkie pliki /etc/init.d i /etc/conf.d czy aby się nie zmieniły. Skrypt depscan jest wywoływany za każdym wywołaniem skryptu z init.d. Prosze wstawić sobie echo w depscan.sh i zobaczyć ile razy jest ten skrypt uruchamiany podczas startu systemu  :Wink: 

Można też tak samo napisać sobie własny skrypt init'a i który nie robi nic poza einfo "hello" i tak samo zobaczyć w top'ie jak to obciąża procka w starym i nowym baselayout. 

Inny dowód - taki nie wprost -  to taki, że w moim komputerze w przypadku dużego obciążenia procesora po prostu słyszę jak wentylator zwiększa obroty... Ze starym baselayout zawsze podczas uruchamiania lub zamykania systemu wiatrak zaczynał chodzić głośniej - zawsze mnie to dziwiło, do czasu kiedy przeanalizowałem jak działa podsystem uruchamiania skryptów rc. Z nowym baselayout, podczas startu i zamykania systemu tego efektu nie ma - wentylator cichutko miele powietrze i w dodatku reboot komputera mam w 4 sekundy, a nie w 20.

Pozdrawiam

----------

## Sławomir Gąsiorowski

 *Paczesiowa wrote:*   

> ja tam odradzam. wcale szybkosci nie odczulem (moze dlatego ze mam cos troche szybszego niz p100) jedyne co to kilkanascie errorow podczas startu (nie wiem czy faktycznie cos nie dziala czy tylko sobie pisze z nudow) no i jedna rzecz ktora nie dziala to vmware za cholere nie chce sie uruchomic. trzeba poczekac az bedzie chociaz ~x86 i poprawia inne pliki z init.d zeby sie dalo uzywac tego.

 

Cóż, trzeba mieć świadomość tego, że testujemy alfa testową wersję. Errory najlepiej zanotować i podesłać na bugzillę, albo nic nie zmieniać i poczekać aż pakiet się ustablilizuje. A jeśli chodzi o vmware to zawsze miałem z tym same kłopoty - raz działało, raz nie - tak to już widac ma  :Smile: 

Pozdrawiam

----------

## garwol

na moim dosc starym sprzecie roznica jest zauwazalna, odpalenie systemu spadlo z ok 1:30 do 1:20, zamykanie z chyba 17s do 7s czyli zamyka sie 2,5 raza szybciej  :Shocked: 

no i jeszcze zauwazylem ze dysk znacznie mniej mieli podczas odpalania systemu, odpala sie jakos tak ciszej troche   :Wink: 

----------

## Paczesiowa

 *Sławomir Gąsiorowski wrote:*   

>  *Paczesiowa wrote:*   ja tam odradzam. wcale szybkosci nie odczulem (moze dlatego ze mam cos troche szybszego niz p100) jedyne co to kilkanascie errorow podczas startu (nie wiem czy faktycznie cos nie dziala czy tylko sobie pisze z nudow) no i jedna rzecz ktora nie dziala to vmware za cholere nie chce sie uruchomic. trzeba poczekac az bedzie chociaz ~x86 i poprawia inne pliki z init.d zeby sie dalo uzywac tego. 
> 
> Cóż, trzeba mieć świadomość tego, że testujemy alfa testową wersję. Errory najlepiej zanotować i podesłać na bugzillę, albo nic nie zmieniać i poczekać aż pakiet się ustablilizuje. A jeśli chodzi o vmware to zawsze miałem z tym same kłopoty - raz działało, raz nie - tak to już widac ma 
> 
> Pozdrawiam

 

ja nie mam zadnych klopotow. a te od baselayout to sa typowe initowe nie chce sie /etc/init.d/vmware odpalic ze wzgledu na jakis tam niepoprawny token.

----------

## Sławomir Gąsiorowski

Test wykonałem na dwóch komputerach, na pierwszym pracuję, drugi do główny serwer w zakładzie.

1. Athlon64 2,2GHz, 512MB RAM, 512Kb cache, x86_64, kernel 2.6.21-gentoo, profil 2006.1/no-multilib (baselayout-2.0.0_alpha1) 

2. IntelXeon 3GHz, 1GB RAM, 2MB cache, i686, kernel 2.6.19-gentoo-r5 SMP-HT, profil 2006.1 (baselayout-1.2.19-r2)

Test polegał na stukrotnym wykonaniu skryptu /etc/init.d/gpm (restart,status) i zmierzeniu czasu. Zrobiłem to za pomocą prosteych komend z linii poleceń bash na każdym z komputerów:

```
time for i in {0..100}; do /etc/init.d/gpm restart; done

time for i in {0..100}; do /etc/init.d/gpm status; done  

```

Dodatkowo zrobiłem to samo na skrypcie testowym (/etc/init.d/test):

```
depend() {

        need local

}

start() {

        ebegin "Starting test"

        eend ${?}

}

stop() {

        ebegin "Stopping test"

        eend ${?}

}
```

Oto wyniki:

1. baselayout-1.2.19-r2 (IntelXeon 3GHz): 

time for i in {0..100}; do /etc/init.d/gpm status; done

real    0m8.557s

user    0m6.100s

sys     0m2.520s

time for i in {0..100}; do /etc/init.d/test status; done

real    0m7.976s

user    0m6.000s

sys     0m2.070s

time for i in {0..100}; do /etc/init.d/gpm restart; done

real    0m40.663s

user    0m8.900s

sys     0m6.350s

time for i in {0..100}; do /etc/init.d/test restart; done

real    0m14.349s

user    0m9.810s

sys     0m4.750s

1. baselayout-2.0.0_alpha1 (Athlon64 2,2 GHz) 

time for i in {0..100}; do /etc/init.d/gpm status; done

real    0m0.373s

user    0m0.107s

sys     0m0.247s

time for i in {0..100}; do /etc/init.d/test status; done

real    0m0.259s

user    0m0.110s

sys     0m0.130s

time for i in {0..100}; do /etc/init.d/gpm restart; done

real    0m16.851s

user    0m1.213s

sys     0m1.820s

time for i in {0..100}; do /etc/init.d/test restart; done

real    0m2.812s

user    0m1.203s

sys     0m1.430s

Wynik jest oczywisty. Podczas wykonywania skryptu init.d z argumentem status nowe baselayout jest średnio 29 razy szybsze. Bardziej miarodajny jest stukrotny restart skryptu /etc/init.d gpm. Tutaj nowe baselayout jest około 2,5 raza szybsze. Restartowanie testowego skryptu zaś było ponad 4 razy szybsze.

Zdaję sobie sprawę z tego, że ten test nie jest w pełni miarodajny, warto jednak zwrócic uwagę, że pomimo iż procesor IntelXeon ma o 800MHz szybszy zegar i więcej pamięci cache procesora, różnica nadal jest bardzo duża.

----------

## manwe_

Jeżeli przyśpieszenie na w miarę "współczesnym" [Turion 1.8] sprzęcie jest znikome*, to ja tam nie widzę sensu przechodzenia na C [i sam nie mam raczej zamiaru]. A czemu? A temu, że skrypty bash'owe mogę sobie dostosowywać szybko i łatwo do własnego widzi-mi-się [już kilka tak sobie "poprawiłem", zresztą nie tylko w notebook'u, ale tez na serwerach]. A C(++) jak i innych języków kompilowalnych nie lubię i nie używam ['skryptowiec' ze mnie do szpiku kości], więc poprawianie tego przypominałoby akt masochistyczny.

* Normalny start systemu, nie uruchamianie jakiegoś skryptu 100 razy.

----------

## c2p

 *manwe_ wrote:*   

> Jeżeli przyśpieszenie na w miarę "współczesnym" [Turion 1.8] sprzęcie jest znikome*, to ja tam nie widzę sensu przechodzenia na C [i sam nie mam raczej zamiaru]. A czemu? A temu, że skrypty bash'owe mogę sobie dostosowywać szybko i łatwo do własnego widzi-mi-się [już kilka tak sobie "poprawiłem", zresztą nie tylko w notebook'u, ale tez na serwerach]. A C(++) jak i innych języków kompilowalnych nie lubię i nie używam ['skryptowiec' ze mnie do szpiku kości], więc poprawianie tego przypominałoby akt masochistyczny.
> 
> * Normalny start systemu, nie uruchamianie jakiegoś skryptu 100 razy.

 

A kto powiedział, że nie będzie można później przerabiać skryptów? Przecież:

 *Sławomir Gąsiorowski wrote:*   

> Efekt jest taki jak przy initng - znaczny kop przy starcie systemu z tą różnicą, że baselayout jest nadal w pełni kompatybilne ze starą specyfikacją skryptów init w gentoo.

 

pozdrawiam

----------

## Sławomir Gąsiorowski

Przypomina mi się historia z programem start-stop-daemon, ten pierwotnie był napisany w perlu. Był wolne i w sposób istotny spowalniał uruchamianie usług podczas startu systemu. Na rękach potem noszono autora jego implementacji w C (nasz rodak nomen omen).

```
A czemu? A temu, że skrypty bash'owe mogę sobie dostosowywać szybko i łatwo do własnego widzi-mi-się [już kilka tak sobie "poprawiłem", zresztą nie tylko w notebook'u, ale tez na serwerach]. A C(++) jak i innych języków kompilowalnych nie lubię i nie używam ['skryptowiec' ze mnie do szpiku kości], więc poprawianie tego przypominałoby akt masochistyczny. 
```

Chyba się nie zrozumieliśmy. Nikt nie mówi o przepisywaniu skryptów /etc/init.d/ do języka C - to byłby absurd !!! Poza tym w Gentoo nie ma skryptów bash'owych bo w nagłówku kazdego z nich jest jak wół /sbin/runscript a nie bash. Jeśli chodzi o poprawianie skryptów samodzielne, to chyba kolega nie miał na myśli poprawiania /sbin/rc, czy skryptów /lib/runscript ? Tutaj chodzi o przepisanie co języka niższego poziomu "silnika" podsystemu rc aby działał szybciej. To tak jakbyśmy mieli bash'a napisanego w basic'u, który co prawda działa, jest stabilny, ale zaczyna Ci przeszkadzac jego powolność. Przepisane go do C nie zmienia nic dla kogoś kto uzywa bash'a - pozostanie niezauwazone - podobnie jest z baselayout  :Smile:  Nawet jeśli baselayout jakiś masohista przepisałby w assemblerze, to przy zachowaniu komaptybilności wstecznej nie ma to żadnego znaczenia. Programisty skryptów bash nie interesuje to jak zaimplementowano basha, po prostu wpisuje #!/bin/bash i już. Tak samo programisty skryptów startowych z gentoo nigdy nie interesowało to co kryje sie za /sbin/runscript.

Nomen omen, zdarzyło mi się grzebać w baselayout , nawet udało mi się gdzie niegdzie go zoptymalizować po czym stwierdziłem że to najlepiej byłoby przepisać do C. Poza tym autor baselayout'a zapewne planował od dawna przejście na C, świadczą o tym komentarze w plikach.

 *Quote:*   

> 
> 
> Jeżeli przyśpieszenie na w miarę "współczesnym" [Turion 1.8] sprzęcie jest znikome*
> 
> 

 

Ja tam nie lubie jak ktoś marnuje takty procesora, poza tym nie zmuszajmy innych tak jak czyni to Microsoft do kupowania najnowszego sprzętu, bo inaczej nie sobie gentoo nie poużywasz... Tak jak kilka lat temu, tak i teraz minimalne wymagania linuxa są nadal na podobnym poziomie (o ile nie zechcemy uzywać Xindows i Gnome). Nie zabierajmy administratorom i innym zapaleńcom szansy postawienia Gentoo na P75MHz z byle powodu, z powodu lenistwa programistów którym nie chciało sie zoptymalizować swoich algorytmów, bo ci już kupili sobie dwuprocesorowe cudo i nadal się wkurzają i dziwią że im openoffice muli.

 *Quote:*   

> 
> 
> * Normalny start systemu, nie uruchamianie jakiegoś skryptu 100 razy.
> 
> 

 

A tu kolega się myli i to bardzo. To miało właśnie zasymulowac start systemu. Co prawda normalnie nie uruchamia się 100 skryptów z init.d. Normalnie jest ich około 40 (14 z runlevelu boot i co około 26 z runlevelu default) - proszę sprawdzić.  Poza tym w default wcale nie muszą być wszystkie skrypty zsymlinkowane, podsystem rc sam uruchamia niezbędne zależności. Prosze sobie też przeanalizowac skrypty rc i to jak są wywoływane - można się zdziwić... Podczas normalnego startu systemu każde wywołanie, instancja skryptu (w przypadku startu równoległego) z /etc/init.d uruchomienie bardzo skomplikowanego procesu. Zrównoleglenie tego procesu potęguje efekt. 

Każdy skrypt rc z gentoo nie jest uruchamiany za pomocą bash'a, tylko specjalnego /sbin/runscript. A więc następuje:

Wywołanie programu wrappera /sbin/runscript (to jest w C od zawsze) -> Programik /sbin/runscript wywołuje /sbin/ruinscript.sh z odpowiednimi argumentami (nazwa skryptu i jego argumenty) -> Skrypt /sbin/runscript.sh ładuje /sbin/functions.sh, /lib/rcscripts/sh/rc-services.sh, /lib/rcscripts/sh/rc-daemon.sh, /lib/rcscripts/sh/rc-help.sh, właściwy plik /etc/init.d/ oraz jego konfigurację z /etc/conf.d/. Weżmy teraz rc-services.sh, ten na dzień dobry zawsze uruchamia depscan.sh. Jak działa depscan ? Depscan mianowicie najpierw skanuje wszystkie pliki z /etc/init.d oraz /etc/conf.s w celu sprawdzenia czy aby któryś się nie zmienił. Jeśli się zmienił, to uruchamia specjalne skrypty awk, które przebudowują drzewo zależności pomiędzy pakietami. Te skrypty awk'owe tez sa interpretowane, co więcej po części dublują functions.sh, więc w awk napisano awk'owy odpowiednik tegoż skryptu. Ale zostawmy to awk, bo przebudowanie drzewa zalezności odbywa się tylko raz. Jest jednak pewien mankament. W depscan.sh sprawdzenie czy pliki się nie zmieniły od ostatniego sprawdzenia zaimplementowane jest tak:

```

for config in /etc/conf.d /etc/init.d /etc/rc.conf

do

! ${update} \

&& is_older_than "${mysvcdir}/depcache" "${config}" \

&& update=true

if is_older_than "${mtime_test}" "${config}" ; then

# Update the file modification time

touch "${config}" &>/dev/null

clock_screw=1

fi

done
```

Ten fragment depscan wykonuje się zawsze, bezwzględnie zawsze. Można sobie wstawic echo po komendzie 'do' żeby się przekonać, a wykonanie go trwa i to niemało czasu. Im więcej plików w /etc/init.d i /etc/conf.d tym dłużej trwa ich przetestowanie. Stąd niegasnąca dioda led z dysku twardego i główna przyczyna zwiększania sie u mnie prędkości obrotowej wentylatorów w obudowie  :Smile: 

Wróćmy zatem do runscript.sh. Skrypt ten po załadowaniu i wykonaniu wszystkich niezbędnych innych skryptów (w tym rc-services.sh który zawsze uruchamia depscan.sh) przechodzi do wykonania właściwego kodu z /etc/init.d. Ale zanim to zrobi, musi sprawdzić w drzewie zależności, czy aby wszystkie skrypty nadrzędne zostały uruchomione (to też trwa). Więc następuje coś w rodzaju rekurencji, czyli cała mantra zostaje powtórzona dla kazdego ze skryptów nadrzędnych, aż warunek zostanie spełniony. Na końcu, jeśli wszystko co musiało być sprawdzone zostało sprawdzone, jesli wszystko co musiałobyć uruchomione zostało uruchamione następuje uruchomienie naszego skryptu i przejście do następnego skryptu z listy. 

Nieźle się nasz kompuer musi się napocić przy tym. Silnik baselayout używa przecież bash'a. Kazde uruchomienie skryptu to automatyczne załadowanie od nowa wszystkich zależności do pamięci, co zajmuje czas. Niebotyczna kaszana robi się podczas włączenia PARALLEL_STARTUP, ponieważ równolegle kilkanaście skryptów ładuje się i mieli depscan'em, wczytuje functions.sh i wykonuje wiele innych rzeczy o których pewnie jeszcze nie wiem, ale słysze to kiedy nagle wiatrak od procesora zaczyna chodzić głośniej. I niech nikt mi nie mówi że mam sobie sprawić chłodzenie wodne  :Smile:  Bo to nie w tym rzecz.

Tak skomplikowanych algorytmów nie powinno się robić w bash'u czy w awk i nie jest to tylko moje zdanie.

Podsumowując, bardzo proszę żeby nie bagatelizować, wrecz nie odrzucać z definicji takich inicjatyw. Drażni mnie podejście w stylu skoro za rok procesory będą dwa razy szybsze to po co optymalizować algorytm... To znany tok rozumowania Billa Gates'a. Skoro dziś mamy 3 razy szybsze komputery niż 3 lata temu, to dlaczego nie mielibysmy na tym skorzystać, odczuc tego? Jakaz była radość kiedy w gcc zaimplementowano obsługę mmx, sse czy 3dnow - w końcu mplayer mógł pieknie odtwarzac filmy i to lepiej niż pod innymi systemami. A co by było, gdyby autorzy aplikacji odmówili przepisania co istatniejszych fragmentów swojego programu? Bylibysmy xli i w końcu ktoś by to zrobił za nich - patrz XMMS, który na  życzenie własnych autorów umarł. W końcu wybraliśmy gentoo to nie dlatego, że długo się kompiluje, czy dla szpanu tylko dlatego że lubimy optymalny system zarówno pod względem użytkowym, jak i wydajności. Nie bez kozery o gentoo mówi się że jest najszybszym linuxem (nawet ze starym baselayut). 

Pozdrawiam serdecznie

----------

## Paczesiowa

czas procesora jest o wiele tanszy niz czas programisty. wiec moim skromnym zdaniem lepiej by bylo jakby developerzy gentoo sie zajeli naprawianiem bugow, pisaniem ebuildow niz optymalizowaniem czegos jak uruchamianie komputera (co sie robi raz dziennie, a kazdy biedny administrator stawiajacy server na p75 uruchamia server przy wymianie sieciowki albo jak prad padnie). nie jestem przeciwny optymalizacjom, ale pamietajmy ze 80% pisanego kodu jet wykonywane przez 20% czasu procesora, wiec wazne jest wiedziec gdzie i co optymalizowac. bo nie chodzi o powrot do asemblera.

----------

## garwol

i juz mi sie pojawil pierwszy "bug?!" - dzisiaj przy odpaleniu kompa wlaczyl mi sie fsck (jak zawsze co 20 montowan) no i skrypty zamiast poczekac az dojdzie do konca to zaczely wyzucac jakies bledy ze nie moga odpalic czegos tam bo nie wstal checkroot itp ble ble, ale naszczescie i tak system sie odpalil normalnie  :Very Happy: 

 *Quote:*   

> czas procesora jest o wiele tanszy niz czas programisty

 

przecietny uzytkownik nie jest programista i niewiele go obchodzi ile kosztowal czas programisty, wazniejsze dla niego bedzie to ze mu sie system szybko odpala   :Confused: 

----------

## Sławomir Gąsiorowski

 *Paczesiowa wrote:*   

> czas procesora jest o wiele tanszy niz czas programisty. wiec moim skromnym zdaniem lepiej by bylo jakby developerzy gentoo sie zajeli naprawianiem bugow, pisaniem ebuildow niz optymalizowaniem czegos jak uruchamianie komputera (co sie robi raz dziennie, a kazdy biedny administrator stawiajacy server na p75 uruchamia server przy wymianie sieciowki albo jak prad padnie). 

 

O czym my mówimy ? W zasadzie o prostym programie który do wykonania prostej czynności - uruchomienia kilkunastu skryptów we właśniwej kolejności pożera bardzo nieproporcjonalnie duże zasoby sprzętowe systemu. O niczym więcej. Nikt mi nie wmówi, że sytuacja, w której prosty program podczas wykonywania prostych operacji pożera 90% zasobów współczesnego komputera jest normalna. Niedoróbek nie można usprawiedliwiać cennym czasem programisty. I nie ważne czy dotyczy to programu uruchamiania systemu, czy inny. Weźmy na ten przykład openoffice. Wszędzie narzekanie że wolno się uruchamia, na jakich komputerach oni to piszą, czy optymalizują tego kolosa? Fakt jest fakem, w obecnej postaci baselayout jest niereformowalny, należało go przepisać i zoptymalizować. Nie wolno wykręcać się sianem. Nie wolno też stawiać tego na ostrzu noża - ważne, żeby deweloperzy zajmujący się projektem mieli tego świadomość i mieli odpowiednio rozpisaną ścieżkę rozwoju programu. W końcu to odróżnia dobrych programistów od takich sobie, że zawsze chcą doskonalić swój produkt, a według wszelkich znaków na niebie i ziemi baselayout od dawna tworzone było z myślą o implementacji w C. Skoro autorzy baselayout zechcieli go poprawić, to nie wolno twierdzić że ich praca jest bez sensu. Teraz przyszedł czas na krok dalej i bardzo się z tego cieszę. Możemy się różnić w szczegółach jednak zdaniem wielu użytkowników linuxa kwestia porządnej implementacji startu systemu to ważna sprawa, zbyt zaniedbana i nieustandaryzowana żeby jej w końcu nie spróbowac ulepszyć.

Kolega zapewne przyzna mi rację kiedy powiem, że "Lepsze jest wrogiem dobrego". Bo i racja, nie ma sensu dziś instalować takich mocno rozwojowych nieprzetestowanych bajerów na serwerach. Nikomu nie każę też tego instalować na swoich komputerach. Przyjdzie czas, a pewnego dnia po aktualizacji nowe baselayout będzie na każdym gentoo, nikt nawet nie zwróci na to uwagi. Kiedy tymczasem narzekania o powolnym uruchamianiu się openoffice'a pomimo wymiany komputerów na 3 razy szybsze niż dziś nadal się nie skończą. Mnie do linuxa przekonywać nie trzeba, ale desktopów nie zawojuje bez super szybkiego środowiska graficznego i pakieru biurowego uruchamiającego się w pół sekundy. Warto więc może pokazać, że da się chociaż system uruchomić dużo szybciej niż do tej pory nie ?

 *Quote:*   

> 
> 
> nie jestem przeciwny optymalizacjom, ale pamietajmy ze 80% pisanego kodu jet wykonywane przez 20% czasu procesora, wiec wazne jest wiedziec gdzie i co optymalizowac. bo nie chodzi o powrot do asemblera.

 

W przypadku baselayout mniej niż 1% kodu uruchamianego tylko przy starcie/zatrzymywaniu systemu bez powodu, niepotrzebnie absorbowało 90% czasu procesora.

Pozdrawiam serdecznie

----------

## Raku

 *Paczesiowa wrote:*   

> czas procesora jest o wiele tanszy niz czas programisty. wiec moim skromnym zdaniem lepiej by bylo jakby developerzy gentoo sie zajeli naprawianiem bugow, pisaniem ebuildow niz optymalizowaniem czegos jak uruchamianie komputera 

 

pracujesz w firmie Microsoft?   :Twisted Evil: 

----------

## Paczesiowa

narzekasz na czas odpalania openoffica i to jest wlasnie problem ktory ludzi denerwuje o wiele bardizej niz czas uruchamiana calego komputera i tu by faktycznie warto poswiecic czas developerow zeby bylo szybciej.

a tak w ogole uruchamianie systemu jest glupie i archaiczne. hibernacja skraca ten czas do takich poziomow jakich baselayout napisane w asemblerze nie osiagnie.

nie, nie pracuje w microsofcie. ale pamietajcie ze czas programisty kosztuje. nie wazne czy jestescie uzytkowinkiem linuxa darmowego, developer poprawiajac baselayout nie zrobi czegos innego bardziej pozytecznego. naprawde nic was w gentoo bardziej nie wnerwia niz ten start systemu? ja np jakies pol roku temu zglosilem buga na bugzilli, nawet zamiescilem poprawionego ebuilda i nic, zaden developer nie chce na to spojrzec.

----------

## Carnivorous

Mam w takim razie pytanie: czy to ty piszesz ten baselayout? Jak nie to co cię interesuje czy programista ma czas na coś innego czy nie? Przecież prace nad nowym baselayoutem wcale nie spowodowały wstrzymania prac nad innymi aspektami działania systemu... Dobrze, że dystrybucja rozwija się, bo gdyby prace nad nią ograniczyły się tylko i wyłącznie do naprawy bugów to stała by się w krótkim czasie przestarzała, a przecież jednym z założeń Gentoo jest jej innowacyjność....

----------

## Paczesiowa

tez mnie to nie martwi, nie bede zapalal swieczek starem baselayout, tylko uwazam ze jest to niepotrzebne.

----------

## Poe

nie testowałem _jeszcze_ tego nowego wynalazku, ale jestem wyznawcą zasady, ze jezeli cos moze działać szybciej, płynniej, lepiej z mniejszym obciązeniem procesora, to jestem za. bardzo dobrze IMHO ze zabrali sie za baselayouta, chociazby z takiego prostego względu. mam laptopa czyli komputer mobilny. raz odpalam go w domu, raz w szkole, raz na peronie a jeszcze pozniej na imprezie. noszenie zahibernowanego laptopa w torbie? nie dziękuje. odpalanie systemu od nowa przy jak najmniejszym obciazeniu sprzetu = mniejszy pobór mocy z baterii, co jednak w mobilnych komputerach jest mimo wszystko wazne (po to są). 

Kwestia budowy portage w pythonie to inna sprawa, która też IMHO powinna byc rozwiązana z czasem

pozdrawiam

----------

## Paczesiowa

co zlego w hibernacji w torbie?

----------

## Poe

nie wiem, ale jakos nigdy nie ufałem temu.

a z resztą. czemu jest spor o to "dlaczego (podobno) ma działać szybciej, skoro może wolniej".... pierwszy raz spotykam sie z czyms, ze komus przeszkadza, ze coś jest modernizowane in plus...

----------

## no4b

 *Quote:*   

> hibernacja skraca ten czas do takich poziomow jakich baselayout napisane w asemblerze nie osiagnie.

 

Zakładając, że ta hibernacja działa... Akurat czas uruchamiania się gentoo jest jedną z rzeczy, która mnie w tej dystrybucji mocno denerwuje.

----------

## Carnivorous

A jak dla mnie nie jest źle... może wto wynik tego że przy Gentoo sporo się bawiłem ,a Archa troche olałem ale u mnie G. wstaje szybciej niż Arch. Nie zmienia to faktu, że jak coś może być lepsze, to IMHO powinno tak być   :Wink: 

----------

## Sławomir Gąsiorowski

 *Paczesiowa wrote:*   

> narzekasz na czas odpalania openoffica i to jest wlasnie problem ktory ludzi denerwuje o wiele bardizej niz czas uruchamiana calego komputera i tu by faktycznie warto poswiecic czas developerow zeby bylo szybciej.

 

Ciekawe, a co to za różnica ? Problem jest przecież bardzo podobny. A można by zastosować Twoje podejści, bo przecież można openoffice uruchomić raz i więcej go nie zamykać. Każde uruchomienie kolejnej instancji programu trwa już z reguły 10 razy szybciej, więc po co to optymalizować ?

 *Quote:*   

> 
> 
> a tak w ogole uruchamianie systemu jest glupie i archaiczne. hibernacja skraca ten czas do takich poziomow jakich baselayout napisane w asemblerze nie osiagnie.
> 
> 

 

Tylko, że różnica pomiędzy hibernacją jest taka, jak pomiędzy własnym garażem z szerokim wjazdem, a miejscem postojowym na parkingu - raz jest a raz go nie ma. Poza tym hibernacja ma swoje zalety systemu, ale ma też swoje wady.

 *Quote:*   

> 
> 
> nie, nie pracuje w microsofcie. ale pamietajcie ze czas programisty kosztuje. nie wazne czy jestescie uzytkowinkiem linuxa darmowego, developer poprawiajac baselayout nie zrobi czegos innego bardziej pozytecznego. 
> 
> 

 

Tak to już jest, że deweloperzy, nieważne w jakiej firmie, podzieleni sa na projekty. Każdy projekt ma swojego opiekuna i ludków do pracy nad nim. Nie widzę sensu w stwierdzeniu, że mogliby robić coś bardziej pożytecznego. Ci właśnie robią to co do nich należy.

 *Quote:*   

> 
> 
> naprawde nic was w gentoo bardziej nie wnerwia niz ten start systemu? 
> 
> 

 

Zaczęło mnie to denerwować, kiedy okazało się, że na sprzęcie na którym linux powinien jeszcze całkiem dobrze działać, gentoo uruchamia się kilkanaście minut. To trochę przeczy głównemu założeniu że Gentoo to system optymalny. Przy okazji odkryłem dlaczego podczas startu i zamykania systemu głośniej chodzą mi wiatraki w komputerze  :Smile: 

 *Quote:*   

> 
> 
> ja np jakies pol roku temu zglosilem buga na bugzilli, nawet zamiescilem poprawionego ebuilda i nic, zaden developer nie chce na to spojrzec.

 

Cóż, są ludzie i taborety, przykro mi.

Pozdrawiam

----------

## Raku

 *Paczesiowa wrote:*   

> narzekasz na czas odpalania openoffica i to jest wlasnie problem ktory ludzi denerwuje o wiele bardizej niz czas uruchamiana calego komputera i tu by faktycznie warto poswiecic czas developerow zeby bylo szybciej.

 

już dostałeś odpowiedź od Sławomira Gąsiorowskiego - po co optymalizować, skoro wystarczy raz włączyć? Niech się OO włącza ze startem systemu i problem znika. I tak można rozwiązać 99% problemów z wolno uruchamiającym się softem pod linuksem - więc po go poprawiac i optymalizować? 

Zawsze można w końcu kupić szybszy procesor lub pięć i dodatkowe 128GB RAM - a wszystko po to, żeby uruchomić nowy, zbajerowany notatnik, który napiszą programiści oderwani od zadań optymalizacji i poprawiania jakości tego g... które do tej pory spłodzili ...

 *Quote:*   

> a tak w ogole uruchamianie systemu jest glupie i archaiczne. hibernacja skraca ten czas do takich poziomow jakich baselayout napisane w asemblerze nie osiagnie.

 

jasne - i działa super idealnie i nikomu nie sprawia problemów ze sterownikami do kart graficznych, sieciowych, itp...

I po instalacji nowego kernela również wystarczy zrehibernować system...

 *Quote:*   

> nie, nie pracuje w microsofcie. ale pamietajcie ze czas programisty kosztuje.

 

ty temu programiście płacisz?

 *Quote:*   

> nie wazne czy jestescie uzytkowinkiem linuxa darmowego, developer poprawiajac baselayout nie zrobi czegos innego bardziej pozytecznego.

 

a co ma w takim razie robić developer przypisany do projektu baselayout? rżnąć w Call of Duty z kumplami?

 *Quote:*   

> naprawde nic was w gentoo bardziej nie wnerwia niz ten start systemu?

 

co mnie wnerwia, już nie raz pisałem. I żaden developer siłą odciągnięty od baselayouta nie jest w stanie tego naprawić.

 *Quote:*   

> ja np jakies pol roku temu zglosilem buga na bugzilli, nawet zamiescilem poprawionego ebuilda i nic, zaden developer nie chce na to spojrzec.

 

możesz podać linka do buga?

 *Quote:*   

> nie bede zapalal swieczek starem baselayout, tylko uwazam ze jest to niepotrzebne.

 

zawsze możesz umieścić nowy baselayout w jakiejś maskownicy i pozostać przy starym.

----------

## Yatmai

A wiecie, mnie tam boli, że mój serwerek restartuje się 2-3 minuty. 550Mhz 128 ramu i jedyne co ma to iptables, ssh, vsftpd i nfs... Naprawde nie rozumiem dlaczego się tak długo bootuje i bardzo mnie cieszy, że jednak ktoś coś robi w tym kierunku.

A swoją drogą, jak robią baselayout'a od zera to może w końcu skończą się enigmatyczne problemy czemu nfs z placa startuje bez problemu a ze skryptów przy bootowaniu za cholere (to samo miałem na poprzednim systemie z amuled).

A propos panów smęcących nosem, chcecie, by Linuch jak viśta potrzebował 3Ghz i 1GB ramu tylko po to by odpalić Firefox'a i WinAmp'a ? Doceńcie co macie i korzystajcie mądrze z tych gigaherców  :Razz: 

----------

## Spaulding

a ja mam pytanie  :Wink:  jak unmarkowac ten pakiet ? (3 dni mam gentoo) aha ... zauwazylem takze ze jest juz wersja alpha2  :Smile: 

----------

## c2p

@CzErYnA:

```
echo sys-apps/baselayout ~x86 >> /etc/portage/package.keywords

echo sys-apps/makedev ~x86 >> /etc/portage/package.keywords

echo sys-apps/baselayout  >> /etc/portage/package.unmask

echo sys-apps/makedev  >> /etc/portage/package.unmask

```

Chociaż po 3 dniach z gentoo, nie zawsze działąjąca alpha może Cię trochę zniechęcić...

----------

## przemos

O ile alpha1 jeszcze u mnie wstala, choc ze 2-3 bledy wyskoczyly, o tyle z alpha2 juz byly problemy, ale jakos udalo mi sie uruchomic system. Co do szybkosci uruchamiania sie - nie widze wiekszej roznicy, dlatego tez porownanie do initng jest troche nie na miejscu wg. mnie. A z powodu bledow przy uruchamianiu i niewyraznej roznicy w szybkosci startu zdecydowalem sie wrocic do stabilnego baselayouta.

----------

## kicior

 *przemos wrote:*   

> O ile alpha1 jeszcze u mnie wstała, choć ze 2-3 błędy wyskoczyły, o tyle z alpha2 już były problemy

 U mnie alpha2 wcale nie chciała odpalić systemu, musiałem wrócić do alpha1.

----------

## canni

 *kicior wrote:*   

>  *przemos wrote:*   O ile alpha1 jeszcze u mnie wstała, choć ze 2-3 błędy wyskoczyły, o tyle z alpha2 już były problemy U mnie alpha2 wcale nie chciała odpalić systemu, musiałem wrócić do alpha1.

 

Tak jak u mnie, tylko, że u mnie alpha2 nie potrafiła (nie wiedzieć czemu?) podmontować partycji z lvm2... Grzebałem trochę, ale musiałem wrócić do alpha1 :/

od raku: ort.Last edited by canni on Sat May 05, 2007 7:50 pm; edited 1 time in total

----------

## Johnny_Bit

Zgłaszajcie te problemy na bugzille, o to ona jest. Developerzy naprawdę tam zaglądają i naprawdę robią co mają robić.

----------

## Vegan

Nie jestem pewnien czy na bugzille mozna zglaszac programy zamaskowane i oficjalnie niewspierane ... chyba jest to wlasciwie zakazane.

----------

## Lord_Raven

Z alpha1 nie mialem przyjemnosci ale alpha2 chodzi jak marzenie. Roznica w szybkosci na moim 'nienajnowszym' sprzecie jest bardzo wyrazna.

----------

## suseu

mi alpha1 przyspieszyła znacznie, natomiast alpha2 wydaje się działać jak 1.12

----------

## binas77

 *suseu wrote:*   

> mi alpha1 przyspieszyła znacznie, natomiast alpha2 wydaje się działać jak 1.12

 

baselayout-1.12  -  czas uruchomienia: 1,29 min

baselayout-2.0.0-alpha2  - czas uruchomienia: 0:59 min

alpha1 - nie zdążyłem sprawdzić

PZDR

T.B.

----------

## Maf

Z ciekawości zapytam, od którego do którego momentu mierzycie czas uruchamiania systemu?

----------

## Sławomir Gąsiorowski

 *Maf wrote:*   

> Z ciekawości zapytam, od którego do którego momentu mierzycie czas uruchamiania systemu?

 

Ja staram się być konsekwentny i czas mierzę od momentu uruchomienia init'a, czyli po zakończeniu bootowania jądra. Czas bootowania jądra może być różny, zależy jak każdy sobie swoje jajko linuxa usmażył. U mnie czas uruchomienia linuxa, czyli do momentu uruchomienia graficznego bootmenadżera to 35 sekund (ze stoperem w ręku). Byłoby szybciej, gdyby demon hald nie wstrzymywał tego procesu na czas swojego uruchamiania, a trwa to w zależności od tego czy są płyty CD w napędach, czy też ich nie ma od 2 do 5 sekund (można to przyśpieszyć odpowiednio modyfikując skrypt hald poprzez dodanie &, tracimy wtedy jednak informację o tym czy hald uruchomił się czy nie). Czas zamknięcia systemu, czyli czas od wydania komendy reboot, do rzeczywistego restartu nie przekracza 10 sekund. Podkreślam, że system jest w miarę nowy (2 tygodnie), w większości na pakietach stabilnych (poza kernelem) bez specjalnych flag optymalizacyjnych CFLAGS, czy też LDFLAGS. Wiem, że te czasy dla niektórych są z kosmosu, ale zapewniam, że to prawda. Warto też podkreśłić, że nie uruchamiam całej armii demonów takich jak samba, apache, squid, nfs i wielu innych. Acha, przed chwilą zaktualizowałem baselayout do alpha2 i nie widzę różnicy w szybkości. Widać za to małą rewolucję w /etc/conf.d/rc.

A oto kilka informacji o moim komputerku:

```
sgasiorowski@localhost ~ $ emerge --info

Portage 2.1.2.2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.20-gentoo-r4 i686)

=================================================================

System uname: 2.6.20-gentoo-r4 i686 AMD Sempron(tm)

Gentoo Base System release 2.0.0_alpha2

Timestamp of tree: Sat, 05 May 2007 20:30:10 +0000

dev-java/java-config: 1.3.7, 2.0.31-r5

dev-lang/python:     2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.61

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.15-r1

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=athlon-xp -pipe"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo"

CXXFLAGS="-O2 -march=athlon-xp -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict"

GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/"

LANG="pl_PL"

LC_ALL="pl_PL"

LINGUAS="pl"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="3dnow 3dnowext a52 aac aalib acl aiglx alsa aspell audiofile berkdb bitmap-fonts bzip2 cdparanoia cli cracklib crypt css cups dbus dri dv dvd dvdr dvdread encode fam ffmpeg fortran gdbm gif glitz gpm gzip hal iconv ipv6 isdnlog ithreads jpeg jpeg2k kdehiddenvisibility libg++ lirc mad midi mmx mmxext mp3 musepack ncurses nls nptl nptlonly nsplugin ogg opengl pam pcre perl pic png ppds pppd python readline reflection sdl session sndfile sound spell spl sse ssl svg tcpd threads tiff truetype truetype-fonts type1-fonts unicode utempter v4l vorbis win32codecs x86 xattr xcb xinerama xml xorg xv xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" FOO2ZJS_DEVICES="hp1020" INPUT_DEVICES="keyboard mouse penmount" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl" LIRC_DEVICES="pixelview_pro" USERLAND="GNU" VIDEO_CARDS="nv v4l fbdev vesa vga"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

```

```

sgasiorowski@localhost ~ $ rc-status -a

Runlevel: boot

 alsasound                                                                             [  started  ]

 bootmisc                                                                              [  started  ]

 checkfs                                                                               [  started  ]

 checkroot                                                                             [  started  ]

 clock                                                                                 [  started  ]

 consolefont                                                                           [  started  ]

 hostname                                                                              [  started  ]

 keymaps                                                                               [  started  ]

 localmount                                                                            [  started  ]

 modules                                                                               [  started  ]

 net.eth0                                                                              [  started  ]

 net.lo                                                                                [  started  ]

 rmnologin                                                                             [  started  ]

 syslog-ng                                                                             [  started  ]

 urandom                                                                               [  started  ]

Runlevel: default

 cupsd                                                                                 [  started  ]

 gpm                                                                                   [  started  ]

 hald                                                                                  [  started  ]

 lircd                                                                                 [  started  ]

 local                                                                                 [  started  ]

 netmount                                                                              [  started  ]

 postgresql                                                                            [  started  ]

 xdm                                                                                   [  started  ]

Runlevel: nonetwork

 local                                                                                 [  started  ]

Runlevel: single

```

```
sgasiorowski@localhost ~ $ uname -a

Linux localhost 2.6.20-gentoo-r4 #1 Tue Apr 17 16:42:23 CEST 2007 i686 AMD Sempron(tm) AuthenticAMD GNU/Linux

```

```
sgasiorowski@localhost ~ $ cat /proc/cpuinfo

processor       : 0

vendor_id       : AuthenticAMD

cpu family      : 6

model           : 8

model name      : AMD Sempron(tm)

stepping        : 1

cpu MHz         : 1894.396

cache size      : 256 KB

fdiv_bug        : no

hlt_bug         : no

f00f_bug        : no

coma_bug        : no

fpu             : yes

fpu_exception   : yes

cpuid level     : 1

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow ts

bogomips        : 3792.78

clflush size    : 32

```

```
sgasiorowski@localhost ~ $ free

             total       used       free     shared    buffers     cached

Mem:        776768     272868     503900          0      11628     143068

-/+ buffers/cache:     118172     658596

Swap:            0          0          0

```

```
sgasiorowski@localhost ~ $ mount

/dev/sda5 on / type ext3 (rw,noatime)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)

udev on /dev type tmpfs (rw,nosuid)

devpts on /dev/pts type devpts (rw,nosuid,noexec)

none on /lib/rcscripts/init.d type tmpfs (rw,nosuid,nodev,noexec)

shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)

```

Pozdrawiam

----------

## mpapis

 *Sławomir Gąsiorowski wrote:*   

> U mnie czas uruchomienia linuxa, czyli do momentu uruchomienia graficznego bootmenadżera to 35 sekund (ze stoperem w ręku).

 

To mój system jest szybszy, startuje w 40 sekund od klawisza power  :Smile:  a zamyka się w 10 sekund, domyślam się ze szybki start zawdzięczam małej ilości softu jaki mam zainstalowany (modular KDE  :Smile:  ) choć z drugiej strony aż boje się pomyśleć co będzie jak już wszystko zainstaluje i uruchomię.

----------

## Grosik

Pokusilem sie o przetestowanie nowego baselayout w wersji alpha2. Na moim sprzecie (athlon64 3400+ 1GB ram) start systemu _troche_ przyspieszyl. Gentoo startuje znacznie plynniej. Co ciekawe, rzecza, ktora przyspieszyla najbardziej jest zamykanie. Trwa ono chwile (nie podam czasow w sekundach bo ich nie mierzylem, wszystko to moje subiektywne odczucia).

Generalnie zaraz po zainstalowaniu system uruchomil mi sie bez wiekszych problemow, jednak pojawily sie trzy problemy.

1. Problem ze splashutils, skrypt /etc/init.d/splash wypluwa ostrzezenie, ze nie ma funkcji add_suffix (chociaz startuje i dziala). Ponadto splash nie do konca chce dziala w trybie silent. Pojawia sie splash z paskiem postepu, ale ten pasek sie w ogole nie zmienia, nie pojawiaja sie procent w jakim system wystartowal, zamraza sie na napisie "Initializing kernel". Przy wylaczaniu splash w ogole sie nie pojawia (jest czarny ekran). Jezeli ktos uzywa gensplasha w trybie verbose to te bledy nie powinny mu w ogole przeszkadzac.

2. rc-status pokazuje, ze demon hplip nie uruchomil sie (pokazuje przy nim [ crashed ]), jednak samo hplip jak i drukarka dziala.

3. Ostatni najdziwniejszy problem. Po zainstalowaniu nowego baselayout przestalo dzialac mi mapowanie przyciskow myszki przy pomocy xmodamp. Co ciekawe dzieje sie to tylko wtedy, gdy menadzer okien uruchamiam przy pomocy KDM (sprawdzalem zarowno na KDE jak i fluxboksie). Problem ten nie wystepuje, gdy uruchamiam srodowisko graficzne przy pomocy startx.

Ostatni problem zmusil mnie do powrotu do starszej wersji baselayout. Jednak czekam z niecierpliwoscia na stabilna wersje nowego baselayout. System z nim startuje i zamyka sie znacznie plynniej (dla mnie to wazne, poniewaz czesto restartuje komputer).

----------

## c2p

 *Sławomir Gąsiorowski wrote:*   

>  *Maf wrote:*   Z ciekawości zapytam, od którego do którego momentu mierzycie czas uruchamiania systemu? 
> 
> Ja staram się być konsekwentny i czas mierzę od momentu uruchomienia init'a, czyli po zakończeniu bootowania jądra.

 

A nie lepiej zamiast bawić się zegarkiem, użyć app-benchmarks/bootchart?

----------

## manwe_

No cóż, pozostaje mi się bić w pierś. Zrozumiałem [przyznaję, pobieżnie przeczytałem wątek], że init.d też ma być przepisany  :Rolling Eyes:  Nie popieram marnowania cykli procesora, ale również nie jestem za ich oszczędnością względem wygody, dlatego napisałem tak, a nie inaczej [przy uprzednim zrozumieniu tematu]. Skoro na C przechodzi to "niżej" to ja już nie mam żadnych "ale", poza tym, żeby się pośpieszyli z finalną wersją  :Wink: 

----------

## Spaulding

a mi działa dobrze alpha2 system startuje wg mnie lżej  :Wink:  także polecam  :Smile: 

----------

## Carnivorous

U mnie startuje zdecydowanie zgrabniej, a zamyka sie porównywalnie z windą .... 98  :Smile:  Jedynie to po upgradzie do alpha2 nie mam skryptu net.eth0 (jedyne co mam z "net" to net.lo i netmount) i nie za bardzo wiem jak to naprawić... ktoś ma jakieś pomysły? bo sys odcięty on sieci to troche nie to co chciałem  :Razz: 

----------

## Gabrys

 *Sławomir Gąsiorowski wrote:*   

> Na sprzęcie high-end, a za taki można uważać każdy obecnie dostępne składaki PC rzeczywiście można wielkiej różnicy nie zauważyć. Zauważalne jest, przynajmniej dla mnie to, że cały podsystem rc po przepisaniu w C jest o niebo lżejszy, a naprawdę nie lubię marnowania cykli procesora... W bash'owo awk'owym wydaniu przetwarzanie skryptów bardzo mocno obciąża procesor - nawet na moim 1,8GHz Athlonie jest to odczuwalne. 

 

Niedobrze mi się robi jak czytam takie coś. Po to są języki wyższych rzędów, żeby się nie męczyć np. we własną implementację, powiedzmy, listy, tylko korzystać z tego co już jest, co daje szybsze kodowanie i mniejsze narażenie na błędy i szybszy cykl wydawania softu.

Jak nie lubisz jak Ci się marnują cykle procesora, to proponuję przepisać baselayout do asemblera, na pewno odczujesz różnicę.

----------

## tboloo

 *Gabrys wrote:*   

> 
> 
> Niedobrze mi się robi jak czytam takie coś. Po to są języki wyższych rzędów, żeby się nie męczyć np. we własną implementację, powiedzmy, listy, tylko korzystać z tego co już jest, co daje szybsze kodowanie i mniejsze narażenie na błędy i szybszy cykl wydawania softu.
> 
> Jak nie lubisz jak Ci się marnują cykle procesora, to proponuję przepisać baselayout do asemblera, na pewno odczujesz różnicę.

 

Czyli C == wynajdywanie koła ?? I pewnie nie ma gotowych implementacji list, drzew, b-drzew itd ??

Niedobrze mi się robi gdy ktoś takie głupoty pisze.

Co do języków wysokiego poziomu to proponuję Ci przepisanie kernela + softu np. w javie - na pewno będzie mniej błędów , szybszy cykl wydawniczy i nieporównywalnie szybsze kodowanie *sigh*

----------

## bigfun

 *Carnivorous wrote:*   

> Jedynie to po upgradzie do alpha2 nie mam skryptu net.eth0 (jedyne co mam z "net" to net.lo i netmount) i nie za bardzo wiem jak to naprawić... ktoś ma jakieś pomysły? bo sys odcięty on sieci to troche nie to co chciałem 

 

ln -s /etc/init.d/net.lo /etc/init.d/net.eth0  :Smile: 

Co do baselayout rowniez zrobilem update, i zdecydowanie widze przyspieszenie, system laduje sie znacznie zgrabniej i ogolnie jest lzejszy. zadnych bledow, (oczywiscie zrobiony etc-update). operacja całkowicie na plus  :Smile: 

A co do jezyka to mysle ze Gabrys ma oczywiscie racje ze jezyki wysokiego poziomu zostaly stwozone po to zeby proces tworzenia oprogramowania byl ulatwiony, ale mysle ze tak kluczowe rzeczy jak obsluga inicjalizacji  systemu (do kodu ktorej user nie potrzebuje dostepu, a wiec nie potrzeba aby byla byla ona napisana w jezyku skryptowym) powinna byc zoptymalizowana najbardziej jak sie da (asembler nie wchodzi w gre bo chodzi o przenosnosc kodu). Jezyki wysokiego poziomu maja raczej zastosowanie w aplikacjach end-user.

----------

## Superbeer

W zasadzie miałem pisać coś w stylu "Kolego @Gabrys, no i po co Ci te nerwy. Wściekasz się jakby chodziło o coś na prawdę ważnego a tutaj ludzie dyskutują o bitach, bajtach a Ty wtrąciłeś nawet assembler. Gdybyś był jakimś bicikiem w oprogramowaniu Gentoo to bym jeszcze zrozumiał... Ale w tym przypadku droga obrana przez developerów Gentoo dla baselayout wyjdzie nie tylko Tobie na zdrowie."

Jednak po przeczytaniu wzorcowo neutralnej i obiektywnej wypowiedzi @bigfun-a stwierdziłem, że nic więcej nie mogę do tego dodać.

Pozdrawiam wszystkich a @Gabrys-iowi życzę więcej spokoju ducha  :Smile: 

----------

## Poe

zmegrowalem nowego baselayouta. na moim laptopie (turion64 2.0, 1gb ram) operacja odpalania systemu jest błyskawiczna (cały start systemu trwa niecale 10s). niestety jedyny problem mam z połączeniem wi-fi (eth1, ndiswrapper). startuje niby dobrze, ale internetu nie ma. daje reset eth1, wszystko jest dobrze, tylko na koncu wywala "started but inactive", wiec poki co wrocilem do 1.12.x i z niecierpliwoscia czekam na nastepne wersje.

----------

## Lord_Raven

Dzis gdy odpalałem blaszaka trafilo sie cykliczne sprawdzanie ktorejs z partycji. Ku mojemu zdziwieniu nie pojawił sie pasek postępu. W zasadzie jedynym odwzorowaniem faktu sprawdzania partycji byla świecąca dioda od dysku no i komentarz o pozytywnym zakonczeniu procesu tuz po jego zakonczeniu.

----------

## Carnivorous

Po rozwiazniu problemu z eth0 wszystko działa ładnie, szybko i bez errorow - jakby to nie była alpha tylko któryć rc  :Razz:  Stanowczo polecam! Na moim sprzęcie (przedpotopowym PIII 566MHz 256MB SDRAM) od wystartowania kernela bootuje się (tzn. do w pełni używalnego ekranu logowania do KDE) w 26 sec. ze stoperem w ręku!!! Nie uruchamiam samby, nfs'a czy cupsa ale i tak ten wynik na takim sprzęcie to rewelacja!

----------

## p1c2u

czy przy alpha2 nie ma problemow z vmware?

----------

## suseu

nie wiem jak alpha2 z vmware, bo poprawiłem sobie już przy alpha1. wystarczy w pliku /etc/init.d/vmware zmienić z vmware-prettify na vmware_prettify (kilka razy).

----------

## lsdudi

 *Gabrys wrote:*   

> 
> 
> Niedobrze mi się robi jak czytam takie coś. Po to są języki wyższych rzędów, żeby się nie męczyć np. we własną implementację, powiedzmy, listy, tylko korzystać z tego co już jest, co daje szybsze kodowanie i mniejsze narażenie na błędy i szybszy cykl wydawania softu.
> 
> 

 

sie znawca znalazl 

moze sie i  wymysla to co juz wiele razy zostalo zaimplementowane

ale nie laduje sie calego lancuszka biblioteka ni zbednego kodu nie tworzy 

"z armata na muchy??"

wedlug twojej filozofi kernel powinine byc napisany w javie/c#/Ruby? no bo po co sie meczyc jak juz wszystko tam zaimplementowali

a do trybu tekstowego potrzeby bedzie core 2 duo  2GB i 3 dni czasu na bootowanie

zastanow sie co piszesz, nie do wszystkiego wskazany jest jezyk wysokiego poziomu (hmm od kiedy bash to jezyk wysokiego poziomu?)

A tutaj bardzo widoczne jest  przyscpieszenie gdyz tego bardzo nie zrownoleglisz bo wszytsko inne musi czekac az to sie wykona

sorki za kodowanie ale cos mam pokrecone z klawiatura

ps: w vimie 

```
:s%/vmware-prettify/vmware_prettify/g
```

i po klopocie

----------

## bigfun

 *lsdudi wrote:*   

> 
> 
> hmm od kiedy bash to jezyk wysokiego poziomu?
> 
> 

 

chyba raczej tak  :Smile: 

generalnie obecnie jezyk wysokiego poziomu to jezyk w ktorym programista nie musi sie martwic o takie rzeczy jak zarzadzanie pamiecia , czy zaglebiac sie w niuanse sprzetowe.. (chociaz jest to pojecie wzgledne, bo ogolnie np. C/C++ uwazane byly swojego czasu za jezyki wysokiego poziomu, a teraz jest tendencja do nazywania ich jezykami nizszego poziomu..).

Wydaje mi sie ze generalnie jezyki interpretowane (skryptowe), takie jak sh czy bash przyjelo sie uwazac za jezyki wysokiego poziomu.

Jeszcze co do baselayout, od czasu aktualizacji mplayer zaczal mi swirowac, tryb vo czasami dziala czasami nie, czasami caly mplayer lubi sie wylaczyc, raz nawet odtwarzalo sie do tylu o_O. zobacze czy porekompilacji bedzie ok

----------

## p1c2u

faktycznie vmware dziala dobrze za to jest problem z xdm:

```
stargate init.d # /etc/init.d/xdm start

/etc/init.d/xdm: line 121: ebegin: command not found

/etc/init.d/xdm: line 123: save_options: command not found

/etc/init.d/xdm: line 134: eend: command not found

 * ERROR: xdm failed to start

```

dziwne czemu sie czepia tych komend skoro w innych skryptach dzialaja z powodzeniam

UPDATE: emerge xinit pomoglLast edited by p1c2u on Tue May 08, 2007 9:08 am; edited 1 time in total

----------

## lsdudi

@bigfun

masz racje

ale listy/kolekcji nie masz tam zaimplementowanej mniej wecej o to mi chodziło 

pzdr

----------

## Maf

Baselayout 2.0.0 alpha2 przetestwowany, podobnie jak u innych trzeba było utworzyć dowiązania do net.lo, dodatkowo fsck milczy na temat swojej działalności  :Wink:  a no i jeszcze mały błąd z 'dm-crypt-execute-checkfs', który raczej nie ma praktycznego wpływu na mój system

----------

## Sławomir Gąsiorowski

 *Gabrys wrote:*   

>  *Sławomir Gąsiorowski wrote:*   Na sprzęcie high-end, a za taki można uważać każdy obecnie dostępne składaki PC rzeczywiście można wielkiej różnicy nie zauważyć. Zauważalne jest, przynajmniej dla mnie to, że cały podsystem rc po przepisaniu w C jest o niebo lżejszy, a naprawdę nie lubię marnowania cykli procesora... W bash'owo awk'owym wydaniu przetwarzanie skryptów bardzo mocno obciąża procesor - nawet na moim 1,8GHz Athlonie jest to odczuwalne.  
> 
> Niedobrze mi się robi jak czytam takie coś. Po to są języki wyższych rzędów, żeby się nie męczyć np. we własną implementację, powiedzmy, listy, tylko korzystać z tego co już jest, co daje szybsze kodowanie i mniejsze narażenie na błędy i szybszy cykl wydawania softu.
> 
> Jak nie lubisz jak Ci się marnują cykle procesora, to proponuję przepisać baselayout do asemblera, na pewno odczujesz różnicę.

 

Nie rozumiem dlaczego tekst, który kolega zacytował miałby wywoływac odruchy wymiotne. Przecież w takim razie kolega powinien wymiotować przy każdym uruchomieniu Linuxa - 99%  jest napisane w C i assemblerze. Już start systemu i wywołania init'a powinno spowodować mdłości, init bowiem jest w C napisany. Każde zalogowanie do systemu, paw na ekran, bo bash też jest napisany w C. Aż trudno powiedzieć co się stanie podczas uruchomienia desktop menadżera i mplayera, pełno tam assemblera korzystającego z mmx i 3dnow, wyląduje kolega na gastroenterologii z objawami popażenia przewodu pokarmowego kwasem solnym.

Ale dajmy spokój wygłupom...

Naprawdę, bzdury kolega pisze i chyba nie rozumie co sie kryje pod tematem przepisania baselayout do C, w ogóle co to jest baselayout i do czego służy. Na pewno, przepisanie baselayout nie polega to na przepisaniu skryptów /etc/init.d do C - tylko laik może coś tak durnego wydedukować. Skomplikowane algorytmy przetwarzania skryptów które do tej pory były napisane w bashu i awk napisano w C co pozwoliło na optymalizację algorytmu przy zachowaniu pełnej kompatybilności z dotychczasową specyfikacją skryptów startowych w gentoo. Dzięki temu z jeszcze większą przyjemnością sam będę używał tego podsystemu do tworzenia własnych skryptów bash'owych a'la gentoo.

Nie rozumiem kompletnie tej grupy ludzi, która tak strasznie broni się przed optymalizacją niskopoziomowych elementów systemu. W ten sposób wolne systemy operacyjne będą nadal przede wszystkim wolne, a raczej powolne. To tak jakby napisać silnik relacyjnej bazy danych dajmy na to w perlu po to aby przetestować koncepcję i potem dostać zjebki za to, że się to chce przepisać do C aby zoptymalizować już przetestowane algorytmy. Czyżby kolega uwierzył w mit, że nadchodzi kres kompilatorów i że całość oprogramowania powstawac będzie tylko za pomocą języków interpretowanych? Uważam, że języki interpretowane takie jak python nawet bash są świtenym narzędziem codziennej pracy użytkownika końcowego pod warunkiem, że nie będę musiał w nich implementować algorytmów na przykład transformaty fouriera tylko wywołam wewnątrz skryptu program napisanego w C, który wykona obliczenia i zwróci wynik standardowe wyjście Sam nie jestem masohistą i nie piszę programu w C, kiedy chcę wykonać np. raport z bazy danych. Pisze go w bash'u albo w pythonie. Ale userland systemowy zawsze pisany jest w C lub C++. Reasumując uważam, że bash i inne języki interpretowane są bardzo potrzebne, ale nie wszędzie. 

A jeśli chodzi o assemblera, to niech kolega wywali wszystkie funkcje assemblerowe z biblioteki standardowej, bibliotek multimedialnych, motorów baz danych i kernela i zastąpi je jakąś sensowną implementacją w perlu. Następnie niech kolega weźmie się za przepisane do pythona wszystkich podstawowych programów narzędziowychw  na końcu samego bash'a napisze w perlu i niech się cieszy optymalnym systemem. Acha i broń boże, niech nie używa zoptymalizowanych pod wydajność innych powłok systemowych.

Pozdrawiam serdecznie i proszę wybaczyć tą ironię przebijającą się w tekście.

Do moderatora: Przepraszam za te posty jeden pod drugim, przyjmuje do wiadomości że tak nie wolno. Od teraz daję słowo harcerza, że będę grzeczny  :Smile: 

----------

## radek-s

Przy migracji dosrałem kilka błędów:

```

 * Moving state from //var/lib/init.d to /lib/rcscripts/init.d

/etc/init.d/vmware: line 61: `vmware-prettify': not a valid identifier

 * Service `dhcpd' needs non existant service `net'

 * Service `dhcrelay' needs non existant service `net'

 * Service `distccd' needs non existant service `net'

 * Service `mit-krb5kadmind' needs non existant service `net'

 * Service `mit-krb5kdc' needs non existant service `net'

 * Service `nas' needs non existant service `net'

 * Service `netmount' needs non existant service `net'

 * Service `nfsmount' needs non existant service `net'

 * Service `rdate' needs non existant service `net'

 * Service `samba' needs non existant service `net'

 * Service `saslauthd' needs non existant service `net'

 * Service `slapd' needs non existant service `net'

 * Service `slurpd' needs non existant service `net'

 * Service `spamd' needs non existant service `net'

 * Service `sshd' needs non existant service `net'                                                                          [ !! ]led to update the service dependency tree

```

Czy wiecie może czym spowodowane?

----------

## manwe_

Może brakiem net.eth0 przy zakończeniu emerge? Też to miałem, ale błędy nie przeniosły się na działanie systemu, wszystko startuje i zamyka się ewidentnie szybciej [no i bezbłędnie].

----------

## Sławomir Gąsiorowski

 *radek-s wrote:*   

> Przy migracji dosrałem kilka błędów:
> 
> ```
> 
>  * Moving state from //var/lib/init.d to /lib/rcscripts/init.d
> ...

 

Też tak miałem przy pierwszym upgrade do baselayout2. Tym niemniej pomimo tego błędu wszystko działało bez zarzutu. A problem jest dziwny, bo standardowo w baselayout na dzień dobry w /etc/init.d jest skrypt net.lo (obecnie w alpha2-rc1 dowiązanie do /lib/rcscripts/sh/net.sh) które ma wpisane jak byk: 

```

depend() {

        local IFACE=${SVCNAME#*.}

        local IFVAR=$(echo -n "${IFACE}" | sed -e 's/[^[:alnum:]]/_/g')

        need localmount

        after bootmisc

        provide net

```

Wygląda na to, że w momencie wykonywania tego fragmentu skryptu jeszcze tego symlinka net.lo w /etc/init.d/ nie było ? Myslę że warto by ten tekst podesłać autorom baselayout. Ja ten błąd zignorowałem więcej już go na oczy nie widziałem.

Pozdrawiam

----------

## radek-s

Znalazłem jeszcze 2 błędy z którymi nie potrafie sobie poradzic:

```
laptop radek # /etc/init.d/distccd restart

 * Starting distccd ...

/sbin/start-stop-daemon: unrecognized option `--startas'                                                              [ !! ]

 * ERROR: distccd failed to start

laptop radek # /etc/init.d/splash restart

 * WARNING: you are stopping a boot service

/sbin/splash-functions.sh: line 115: add_suffix: command not found

 * Setting framebuffer console images ...                                                                             [ ok ]

laptop radek #                        
```

za pomoc z góry dziekuje i pozdrawiam!

----------

## noobah

No to i ja dorzuce cos od siebie. Na laptopie z x86 dziala bez problemu, tylko symllinka eth0 trzeba bylo zrobic, ale na desktopie z amd64 nie dziala net (symlink nie pomaga) i nie startuje gdm. Nie wiem czy ma na to wplyw ze na amd jest wersja -alpha2, a na x86 jest wersja -alpha2-r1 ?

Czy komus na amd64 dziala bez problemowo?

Generalnie mozna odczuc malego kopa, jakiego dostaje start systemu i zamykanie rozniez. Dla mnie jest to o tyle wazne ze tak samo jak Poe czesto wlaczam i wylaczam mojego lapka.

----------

## Grosik

 *noobah wrote:*   

> No to i ja dorzuce cos od siebie. Na laptopie z x86 dziala bez problemu, tylko symllinka eth0 trzeba bylo zrobic, ale na desktopie z amd64 nie dziala net (symlink nie pomaga) i nie startuje gdm. Nie wiem czy ma na to wplyw ze na amd jest wersja -alpha2, a na x86 jest wersja -alpha2-r1 ?
> 
> Czy komus na amd64 dziala bez problemowo?.

 

Mnie dziala(lo) bez problemow, symlink wystarczyl, zeby net wystartowal. KDM startowalo, nie wiem jak z gdm. Raczej nie obwinialbym architektury.

----------

## Sławomir Gąsiorowski

 *radek-s wrote:*   

> Znalazłem jeszcze 2 błędy z którymi nie potrafie sobie poradzic:
> 
> ```
> laptop radek # /etc/init.d/distccd restart
> 
> ...

 

Widać błąd jest w skrypcie /etc/init.d/distccd jest błąd, bo faktycznie start-stop-daemon nie ma takiej opcji jak '--startas', to zwykła literówka i powinno byc '--start'. Poszukaj i popraw sobie ten skrypt. Jeśli chodzi o splash'a to widać, że /sbin/splash-functions.sh nie został jeszcze dostosowany do nowego baselayout. Przy okazji okazuje się że zgodność wstecz ze starymi skryptami nie jest 100% ale coś za coś.

Pozdrawiam

----------

## Grosik

 *Sławomir Gąsiorowski wrote:*   

> 
> 
> Widać błąd jest w skrypcie /etc/init.d/distccd jest błąd, bo faktycznie start-stop-daemon nie ma takiej opcji jak '--startas', to zwykła literówka i powinno byc '--start'. Poszukaj i popraw sobie ten skrypt.
> 
> Pozdrawiam

 

No chyba raczej nie powinno tam byc --start. Stary start-stop-daemon:

```
grosik@metatron ~ $ /sbin/start-stop-daemon --help

...

  -a|--startas <pathname>       program to start (default is <executable>)

...
```

Widocznie nowy nie ma jeszcze wszystkich opcji, ewentualnie skrypt do distccd powinien zostac przepisany. radek-s zgłoś buga.

----------

## mziab

 *https://bugs.gentoo.org/show_bug.cgi?id=175980 wrote:*   

> 
> 
> --exec should be used in place of --startas.
> 
> They are effectively the same option.

 

----------

## kneczaj

Zainstalowałem ten nowy baselayout (2.0.0-alpha2-r1) i chodzi jak burza  :Very Happy: 

Zauważyłem tylko dwa bugi:

1. Mam spasha i normalnie najpierw pojawia się napis "initializing the kernel", a potem "booting the system". Z nowym baselayout przez cały czas mam pierwszy napis.

2. Przy sprawdzaniu partycji reiser4 wywala jakieś błędy - wyłączyłem jej sprawdzanie. Może dlatego, że uruchamiając ręcznie fsck.reiser4 trzeba potwierdzić, że chce się sprawdzić fs.

----------

## Vegan

"Przy sprawdzaniu partycji reiser4 wywala jakieś błędy"

moj fs to reiserfs ale 

Byc moze jest to zwiazne z moim problemem , czesto podczas restartu systemu wymusza odmontowanie "/" nawet jesli jest zajete co jest praktycznie rowne twardemu resetowi i koneczne jest fsck na starcie ktos zauwazyl taki blad w tym baselayoutcie alpha2 czy tylko mi sie to przydarza ?

----------

## przemos

 *Vegan wrote:*   

> 
> 
> Byc moze jest to zwiazne z moim problemem , czesto podczas restartu systemu wymusza odmontowanie "/" nawet jesli jest zajete co jest praktycznie rowne twardemu resetowi i koneczne jest fsck na starcie ktos zauwazyl taki blad w tym baselayoutcie alpha2 czy tylko mi sie to przydarza ?

 

Ja mam to zarówno w stabilnym baselayout, jak również w alpha2, ale nie występuje to zawsze, tylko z tego co zauważyłem przy wyłączaniu systemu, gdy przed momentem był mocno obciążony przez dłuższy czas.

----------

## Vegan

ok ale jest to dosyc niebezpieczne i bardzo uciazliwe , strach pomyslec co by bylo gdybym uzywal jfs anblo co gorsza xfs na "/" , zna ktos moze rozwiazanie albo co powduje ten problem ?

----------

## mirekm

A propos bugów to jeszcze:

1. nie obsługuje volumenów na LVM

2. nie potrafi odmontować partycji zamontowanych przez fuse (np. ntfs3g)

----------

## Grosik

 *mirekm wrote:*   

> 2. nie potrafi odmontować partycji zamontowanych przez fuse (np. ntfs3g)

 

Ja nie mialem z tym problemow.

----------

## Sławomir Gąsiorowski

 *Grosik wrote:*   

>  *Sławomir Gąsiorowski wrote:*   
> 
> Widać błąd jest w skrypcie /etc/init.d/distccd jest błąd, bo faktycznie start-stop-daemon nie ma takiej opcji jak '--startas', to zwykła literówka i powinno byc '--start'. Poszukaj i popraw sobie ten skrypt.
> 
> Pozdrawiam 
> ...

 

Dokładnie tak. Ten program też został chyba przepisany od zera i widocznie nie zaimplementowano w nowej wersji tej opcji. Poza tym miało być --exec a nie --start, przepraszam.

Pozdrawiam

----------

## c2p

 *Vegan wrote:*   

> Byc moze jest to zwiazne z moim problemem , czesto podczas restartu systemu wymusza odmontowanie "/" nawet jesli jest zajete co jest praktycznie rowne twardemu resetowi i koneczne jest fsck na starcie ktos zauwazyl taki blad w tym baselayoutcie alpha2 czy tylko mi sie to przydarza ?

 

Ja mam reiserfs i przy reboot/halt odmontowuje wszystko z /mnt, /home, wszystkie tmpfs, ale jeszcze nigdy nie odmontował /. Problem ten występuje w -alpha1, w -alpha2 też, więc wróciłem do stabilnego, bo nie chcę za każdym razem podczas uruchamiania oglądać "Replaying journal.... 1500 transactions replayed".

----------

## Vegan

Rowniez wrocilem do baselayout-stable bo szkoda mi danych i dysku , no co trzeba jeszcze poczkeac w koncu to wersja alpha ....

----------

## n0rbi666

Hm, a ja mam reiserfs na /home /usr/portage /var/tmp/portage /var/tmp/ccache - i odmontowuje dobrze.

Na / mam XFS - i również działa dobrze  :Smile: 

----------

## mziab

Zainstalowałem sobie to cudo na laptopie. Wrażenia w telegraficznym skrócie:

+ System włącza się o 18 sekund szybciej (bootchartd pokazuje spadek 1:02 ->0:44), ze stoperem start do pulpitu w ok. 46 sekund (przedtem ok. 1m10s).

+ Wyłącza się poniżej 10 sekund. Przedtem zajmowało mu to ponad pół minuty.

+ RC_PREFIX jest ładne  :Smile: 

+ Odmontowywanie ntfs3g mi działa. Nie zauważyłem też żadnych problemów ze squashfs ani żadnych problemów z odmontowywaniem /.

- Usługa nfs czasem muli przy włączaniu i wyłączaniu. Na szczęście usługa ta jest mi potrzebna tylko sporadycznie.

- RC_INTERACTIVE jest ignorowane.

- Brak RC_BOOTCHART, trzeba go odpalać ręcznie podając lilo init=/sbin/bootchartd.

- Przy migracji usunęło mi distcc z runlevelu. Wystarczyło spatchować skrypt (zmiana --startas na --exec) i dodać go jeszcze raz.

Podsumowując, jestem zadowolony z wyniku migracji. Jest parę niedoróbek, ale w moim przypadku nie przeszkadzają one w pracy. Na razie wstrzymam się jednak przed instalacją na moim stacjonarnym pececie, głównie z powodu rzekomo niedziałającego ppp.

----------

## Johnny_Bit

mam reiserfs na /, /home, /usr, /opt, /var i ładnie odmontowywuje, żadnych problemów nie ma.

----------

## Sławomir Gąsiorowski

Dziś zemergowałem baselayout-2.0.0_alpha3. Niestety, nadal jest problem z poprawnym startem niektórych usług. Dla kilku z nich,w losowej kolejności wyświetla się komunikat o błędzie, pomimo tego, że uruchomiły sie poprawnie. Wśród nich sa sshd, mdnsd, xdm, czasami cupsd... Komunikat pochodzi ze start-stop-daemon'a i sugeruje że dany proces umarł  :Smile:  Mam nadzieję, że w końcu to naprawią.

Acha i chyba wiem dlaczego fsck milczy podczas testu partycji. Po prostu nowe rc buforuje standardowe wyjście w czasie wykonywania i wyświetla wynik dopiero po zakończeniu działania skryptu. W przypadku fsck powinni to jakoś wyłączyc.

Pozdrawiam

----------

## manwe_

Mi też irdy nie podnosi [że niby umarł irattach].

----------

## lazy_bum

 *Sławomir Gąsiorowski wrote:*   

> Acha i chyba wiem dlaczego fsck milczy podczas testu partycji.

 

U mnie fsck działa bez problemu z "paskiem postępu". (-:

Co do wrażeń, po poprawieniu distccd u mnie wszystko działa.

Czas startu systemu spadł z (wg bootchart) 34 sekund do 20 (wg stopera spadł z 35 do 18 ;-).

Czas `stopu` nie został dokładnie wyliczony, ale na oko spadł co najmniej o połowę. O ile czas startu nigdy mi specjalnie nie przeszkadzał (oknowy system startował jeszcze dłużej), o tyle wyłączenie systemu trwało całe wieki (oknowy system wgniatał tutaj Gentoo w ziemię). Teraz cały proces trwa mniej więcej 6-8 sekund (czasem mu sie dłużej schodzi na odmontowanie /). Jest to dla mnie świetny wynik, bo od wpisania `poweroff` do wyłączenia systemu mogę spokojnie zabrać kubek z herbatą i podejść do listwy zasilającej aby przełączyć ją na 0. <-;

PS. start z alpha3 jest u mnie wolniejszy o 2-3 sekundy.

----------

## Lord_Raven

alpha3 ma problem z apachem. wywala: 

```
/sbin/start-stop-daemon: /usr/sbin/apache2 died

ERROR: apache2 failed to start
```

 mimo ze sam apache dziala

----------

## Sławomir Gąsiorowski

 *lazy_bum wrote:*   

>  *Sławomir Gąsiorowski wrote:*   Acha i chyba wiem dlaczego fsck milczy podczas testu partycji. 
> 
> U mnie fsck działa bez problemu z "paskiem postępu". (-:
> 
> 

 

A masz włączone PARALLEL_STARTUP w /etc/conf.d/rc ? Możliwe, że rc buforuje standardowe wyjście tylko w trybie równoległego uruchamiania usług... Trzeba by to sprawdzić.

Pozdrawiam

----------

## p1c2u

 *Lord_Raven wrote:*   

> alpha3 ma problem z apachem. wywala: 
> 
> ```
> /sbin/start-stop-daemon: /usr/sbin/apache2 died
> 
> ...

 

dokladnie, tez to mam

----------

## XianN

U mnie tez /sbin/start-stop-daemon dal popalic  :Smile:  Szczegolnie przy ipw3945d i bluetooth. Teraz juz jest wszystko ok, ale nie wiem do konca czy to kwestia rezygnacji z preemptible RCU czy upgradu do nowszej alfy (ipw3945d jestem prawie pewien, ze przez preemptible...). Aktualnie jade na 2.0.0-alpha3 i jest super. Do stabilnej chcialem wrocic, ale nie mialem juz sily i nerwow na poprawianie bledow, ktore co ciekawe w 2.0.0 sie nie pojawiaja:)

----------

## Polin

 *p1c2u wrote:*   

>  *Lord_Raven wrote:*   alpha3 ma problem z apachem. wywala: 
> 
> ```
> /sbin/start-stop-daemon: /usr/sbin/apache2 died
> 
> ...

 

Poradził już sobie ktoś z tym?

----------

## p1c2u

tak, wystarczy dodac parametr --name apache2 do start-stop-daemon

----------

## Polin

 *p1c2u wrote:*   

> tak, wystarczy dodac parametr --name apache2 do start-stop-daemon

 

Pomogło. Dzięki.  :Smile: 

----------

## Sławomir Gąsiorowski

Witam

Zapewne wielu z nas przeszkadza błąd w tym nowym baselayout polegający na tym, że zgłaszany jest bład startu usługi, choć ona nadal faktycznie działa. Doszedłem do tego, że odpowiedzialny jest za to program start-stop-daemon, który do nowego baselayout został przepisany po to aby się lepiej z nim integrował. Niestety nie za dobrze to im wyszło, bowiem bardzo często zwraca kod błędu w przypadku kiedy usługa którą uruchamia działa. 

```

/sbin/start-stop-daemon: /usr/sbin/apache2 died 

ERROR: apache2 failed to start

```

Ja znalazłem rozwiązanie problemu polegające na zakomentowaniu następującego fragmentu kodu w pliku start-stop-daemon.c(1032):

```

if (retestpid) {

        if (do_stop (NULL, NULL, pidfile, uid, 0, true, false, true) < 1)

                eerrorx ("%s: %s died", progname, exec);

}

```

U mnie ten brzydki hack rozwiązał problem - wszystko wydaje się działać bez zarzutu.

Pozdrawiam

----------

