Kolejna ³ata.

[Marcin Dalecki]

Tomasz K³oczko wrote:

> Grzesiek czy w takim razie móg³by¶ przedstawiæ interpretacjê sytuacji
> zwi±zanej z zajêto¶ci± pamiêci w przypadku kiedy mamy bash+bash, bash+ksh
> i ksh+ksh ? Je¿eli widzicie tak¿e jakie¶ inne konsekwencje takiej zmiany
> oprócz ró¿nic w prêdko¶ci (sprawdza³em z configure z ksh jakiego mam
> jeszcze bez poprawek jakie zaproponowa³ Marcin .. rzeczywi¶cie jest
> szybciej i to ju¿ na pierwszyszy rzut oka; polecam ka¿demu ten test zeby
> siê przekona³ na w³asne oczy) to te¿ bym prosi³ o przedstawienie tego
> nawet je¿eli to s± poszlaki tych¿e (mo¿e wspólnie da siê jako¶ uzupe³niæ
> potrzebn± nam mozajkê faktów). Marcina te¿ bym prosi³ o to.
> 
> Tak¿e pytanie do Marcina czy przy swojej kalkulacji uwzglednia³ copy on
> write ?

Tak. Je¶li czego¶ nie wyja¶niem w 100% dok³adnie, to jest to raczej
win± mojego beztalencia dydaktycznego i faku, ¿e wyja¶nienia te
pisa³em "na kolanie" w robocie, niedospany i nadal jeszcze przeziêbiny,
a nie jakiej¶ g³êbokiej niewiedzy. Jak ju¿ nieraz wspomina³em:
Ja nie jestem od edukacji, ja jestem od kodowania.
Pisa³em je te¿ w pierwszej  kolejno¶ci dla Ciebie a nie Grze¶ka.
W³a¶nie dlatego, aby widzieæ co siê faktycznie w pamiêci dzieje,
bazowa³em w mej pierwotnej ocenie, która te¿ nigdy nie mia³a byæ
kamieniem
m±dro¶ci, na danych z top-a a nie po prostu:

~# size /bin/ksh
   text    data     bss     dec     hex filename
 173546    2816    7388  183750   2cdc6 /bin/ksh
~# size /bin/bash
   text    data     bss     dec     hex filename
 351773   18872   13184  383829   5db55 /bin/bash
~#    

Tu widaæ ponownie: Jak by na to nie spoj¿eæ, bash potrzebuje mniej
wiêcej pi razy drzwi dwa razy tyle pmiêci co ksh. I dlatego
w³a¶nie wytyka³em Grze¶kowi, ¿e pisze bzdury bez zerkania nawet 
na realia.

Tak czy siak s±dzê, ¿e Grzesiek *nieco* chyba jednak przesadza
odmawiaj±c mi wszelkich kompentecji pod wzglêdem Linux-a :-).
Tzn. ja siê z tego tylko ¶miaæ mogê. Przecie¿ dopiero do nied³ugiego
czasu w³±czy³em siê w Wasz projekt i chyba niema³o jak dotychczas ju¿
zrobi³em. Je¶li ktokowliek poczó³ siê obrazony, to 
proszê przyj±æ moje przeprosiny. Aczkolwiek lubiê, gdy kto¶ kto
mi odmawia³ g³owy, równie mnie przeprosi... 
Koniec dyskucji na tle "ty g³upi - ja mêdrca".

> Tak czy inaczej .. bashe u¿ywane jakie interact shelle bêd± zajmowaæ w
> miarê up³ywu czasu coraz wiêcej pamiêci. Na ksh u¿ywany jako

Tak bo tak jak ju¿ wy¿ej wspomnia³em free(3) wcale niekoniecznie 
zwraca pamiêæ do systemu, tylko jedynie do administacji wolnej pamiêci 
w malloc(3). W systemch z libc < 5.4.xx nie robi³ tego jak dot±d nigdy!
We FreeBSD 2.2 free(3) nie zwraca pamiêci do systmeu nigdy. Podobnie
z SunOS-em < 4.xx. To dla niewtajemniczonych brzmi zaskakuj±co,
ale tak jest. (OK najnowsze malloc-i te¿ od czasu do czasu co¶
zwracaj± do systemu bo one rob± zamiast sbrk(2) mmap na /dev/mem.
Dlatego 
pisa³em ¿e nieca³kiem.)  Tego rodzaju zachowanie siê dotyczy ka¿dego
programu
w UNIX-ie i jest oczywi¶cie nieco zaskakuj±cym dla pó³wiedz±cych,
niezapoznanych z programowaniem systemowym.

> przedewszystkim interpreter skryptów i co najwy¿ej rescue shell (o ile
> bêdzie on skompilowany statycznie) nie bêdzie to mia³o wiêkszego wp³ywu.
> Czyli przy ksh sprawy zwi±zane z wspó³dzieleniem pamiêci pomiêdzy kolene
> instancje nie bêd± mia³y wiêlkiego wp³ywu. W przypadku bash sprawa jest
> istotna gdy¿ ¶redni czas pracy procesu shella bêdzie o wiekle d³u¿szy ni¿
> w przyadku ksh. Przy za³o¿eniu tak¿e, ¿e ksh jest mo¿e i czêsto wywo³ywany
> ale na krótkie odcinki czasu jego wielko¶æ te¿ by predestynowa³a go do
> takiej roli jak± Marcin sugeruje (jako non-interact shell).

O to i tylko o to mi chodzi. Pamiêæ zajmowana przez nawet
zupe³nie ¶wierzego ksh jest mniej wiecej porównywalna do tego co
bash rezerwuje jako sam zakres niewspó³dzielony przy odpaleniu
kolejnego jego wcielenia. I nie chcê siê k³uciæ o ka¿dy bajt. Chodzi
mi tylko o skalê ró¿nicy bo tylko ta jest istotna.

> Dobra powy¿ej by³em niejako neutralny. Teraz chcia³bym jescze
> zasygnalizowa swoj± opiniê co do powy¿szego.
> 
> Czy zgoddzicie siê z tym obydwoje, ¿e przy powy¿szych za³o¿eniach i/lub
> nawet je¿eli czê¶æ u¿ytkowników zacznie u¿ywaæ ksh jako interact sh, a
> tak¿e nie
> znaj±æ szczegó³ów zwi±zanych z zajêto¶ci± pamiêci mo¿na przyj±æ z du¿ym
> poziomem wiarygodno¶ci, ¿e wprowadzenie jednak ksh jako tego który mia³by
> robic za link /bin/sh by³oby jednak korzystne ?

Tak zgadzam siê. Wszelkiego rodzaju testy realne na prêdko¶æ wykazuj±
bowiem, ¿e ksh jest o potêgê szybszyi oszczêdniejszy z zasobami. 
I jak Tomasz i ja ju¿ nieraz wspominali¶my, nie trzeba nawet wielkich 
benczmarków, aby siê o tym przekonaæ:

TO PO PROSTU WIDAÆ S£YCHAÆ I CZUÆ 

 - natychmiast, go³ym okiem!

> (i jeszcze do Grze¶ka) Zauwa¿, ¿e wyra¼nie widaæ podzia³ ról i zadañ dla
> obu shelli, i ¿e po pierwsze minimalny system pracuj±cy z jednym lub z
> kilkoma instalcjami ksh tak czy inaczej system by³by znacznie sprawniejszy
> przy niewielkiej ilo¶ci pamiêci (systemy embeded lub na pograniczu .. sam
> kilka tachich sprytnych urz±dzonek kilka mam i to przedewszystkim na AXP).
> Mo¿na by w takim razie przemie¶ciæ basha z base i na to miejsce wrzciæ
> ksh. W razie czego jakby kto¶ chcia³ koniecznie mieæ sh -> bash to mo¿na
> by zrobiæ ma³y pakiet wymagaj±cy basha, a zawieraj±cy tylko ten link +
> groff includ z manem. Co wiêcej .. tym podzia³em ról w zasadzie nie trzeba

To brzmi najsensowniej jako rozwi±zanie tego problemu z punktu widzenia
technicznego. Problem jaki moja ³ata rozwi±zywa³a to mia³o byæ w³asie
w pierwszej kolejno¶ci wyczyszczenie zale¿no¶ci od specyfików bash-a
w scryptach rc.d A Grzesiek przyczepi³ siê do zmiany w bang path, co 
akurat nie by³o najistotniejsz± kwesti±. Gdyby Grzesiek czyta³ moj±
pocztê, 
to ja nie twierdzi³em, aby tê ³aty tak bezmy¶lnie wpakowaæ do CVS-a.
Zreszt± Arkadiusz ju¿ chyba te moje propozycje zmiany kupi³ i
wprowadzi³. 
(Dziêki.)

Nie widzê równie¿ potrzeby, aby system instalacyjny opiera³ siê na
bash-u. Tu bowiem trzeba byæ oszczêdnym a ksh nie jest po
ustwieniu set -o emacs tak niedogodny jak by kto¶ sobie my¶la³.
Mo¿na edytowaæ wiersz kursorami i historiê komend te¿ kursorem
odwo³ywaæ.
Kompletacja w rodzaju TAB te¿ dzia³a tylko, ¿e pod podwójnym
naci¶niêciu Ctrl-[, co z reszt± mo¿na przy pomocy bind
sobie równie¿ przekonfigurowaæ na TAB poprzez:  bind '^I'=complete.
Jak podobnie warto sobie ustawiæ jeszcze kika innych klawiszy
terminalowych (Home/End).

T³umaczê zreszt± manpage-a do ksh-a na polski (OK narazie
tak na brudno.) i mo¿na sobie siê tego wszystkiego tam ³adnie doczytaæ.
Jedneo chyba bêdê musia³ jeszcze rêcznie w pdksh za³ataæ: tj.
8 bitowo¶æ wprowadzeñ...

> mocno sterowaæ, a istot± niewielkiego wp³ywu tej zmiany na pracê
> interakcyjn± jest to, ¿e przewa¿nie jako defaul shell przy tworzeniu
> uzytkowników nie ustawia siê /bin/sh, a co¶ innego (najczê¶ciej chyba
> bash, potem tcsh)

Pe³na zgoda z mojej strony. Sam w koñcu uzywam bash-a jako shell-a 
interakcyjnego! Tak nawet siê do tej pory o odszukanie komendy
set -o emacs w ksh nie troszczy³em. Ale chyba zaraz przejdê 
(sam dla siebie w zcisznym domciu, nie zamierzam nikogo do tego z
muszaæ!) w pe³ni na ksh, bo ju¿ wiem jak to ustawiac w /etc/profile.

> Sam nie u¿ywam za szeroko skryptów ale zanam kilka osób które w sh robi±
> czasem ca³kiem ³adne CGI. Przy uwzglêdnieniu, ¿e ksh jest raczej
> non-interact shell te¿ mia³oby to znaczenie.

No i oczywi¶cie zalet± jest równie¿, ¿e ksh jest zgodny z
istniej±cym standardem. Nie przez przypadek Linux przy wyci±ganiu siê
co¶ tam gawêdzi o POSIX. Natomiast je¶li kto¶ w swoich scryptach
koniecznie
u¿ywa jakich¶ "features" z bash, które nie s± zgodne z Korn-em,
i nie podaje poprawnego #!/bin/bash to jest ju¿ sam sobie winny i jego 
scrypty nadaj± siê do poprawy a nie na odwrót. Kontrolê nad scryptami
init to mamy my i tam mo¿emy ¶mia³o gwarantowaæ, ¿eby by³y one czyste.

> Decyzja co do zmiany bazowebo /bin/sh nie jest czym¶ ma³o istotnym. W
> takiej sytuacji dobrze by by³o ¿eby ta decyzja nie by³a podjêta na
> podstawie impusu.

Widzê jeszcze jeden jedyny problem, jakim jest poprawne dostosowanie
/etc/profile do mo¿liwych ró¿nych shell-i. Widzia³em jak to siê robi
pod Solarisem i mam to ju¿ w domu gotowe. Je¶li wiêc kto¶
chcia³by zerkn±æ na mój profile i odpowiednio dopasowaæ to co jest
instalowane domy¶lnie w skel i rc-scripts z PLD to chêtnie go
podrzucê....

> Widomo jest jedno, ¿e to ¿e kojarzenie bash, ¿e to w zasadzie sh wziê³o
> siê z wp³ywu jaki wywiera FSF na ca³e ¶rodowisku linuxowe. pdksh w tym
> wypadku jest odtr±cany i to nie ze wzglêdów technicznych, a wy³±cznie
> ideologicznych (nie jest przynajmniej GPL/BSD .. jest na swego rodzaju
> licencji public domain). W Debianie ludzie kieruj± siê wzglêdami
> licencyjnymi, W RH tym ¿eby to ³adnie i wygodnie w miarê wygl±da³o. My nie

W RH s± te¿ po prostu bardzo niechlujni...

> musimy sobie narzucaæ takich ograniczeñ i mo¿emy wy³±cznie skupiæ siê na
> samej materii elementarnej z jakiej przychodzi nam uk³adaæ to co
> zamierzamy nazwaæ dystrybucj±. Mamy dziêki temu mo¿liwo¶æ rzeczywi¶cie
> zrobienia czego¶ naprawdê u¿ytecznego .. czego¶ co tak¿e z du¿ym
> prawdopodobieñstwem zupe³nie ptrzy okazji bêdzie ca³kiem ³adnie (mo¿e
> nawet lepiej ni¿ RH xczy inne) wygl±da³o.

Popieram w 100 procentach! 
Podpisujê siê pod tym obiema rukami! 
Technika technika i jeszcze raz *technika* powinna decydowaæ 
o systemie a nie jakie¶ wzglêdy typu ideolo, lub czyje¶ widzimisiê.
Tym widzimisiê mog± byæ równie¿ ¶mia³o komercyjne interesy jakiej¶
jednej firmy. Niezale¿nie od tego jakiej.

W koñcu w³a¶nie w Polsce absurdy ideolo przerabiali¶my przez
jakie¶ 50 lat z wiadomym skutkiem... Proszê mnie nie rozumieæ ¼le, ja 
nie jestem jakim¶ prawicowcem czy jakimkolwiek radyka³em niezale¿nie
od tego jakiego namaszczenia. Raczej wrêcz przeciwnie.
Ja tylko nie lubiê ideologizowania rzeczy które z ideologi± *nic*
nie powinny mieæ do czynienia! (I to terz tylko proszê przyj±æ jako
o¶wiadczenie moich osobistych pogl±dów a nie poczatek jakiej¶ 
"dyskusji".)

--Marcin