Kolejna ³ata.

[Tomasz Kłoczko]

On Tue, 23 Feb 1999, Grzegorz Stanislawski wrote:
[..]
> > Gdy programu UNIX-owe pracuja to rezerwuja dodatkowo pamiec ale
> > *nigdy* (no prawie nigdy) jej nie zwalniaja spowrotem do systemu. 
> 
>  Pomylilo ci sie chyba z Windows 3.11.

Panowie zejdźcie znawzajem z siebie .. to popierwsze. Niewiedza nie jest
niczym wstydliwym przynajmniej do momentu kiedy sie o tym dowie .. potem
to już co innego. Tak poprostu nie przystoi.

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 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
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).

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 ?

(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
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)

Sam nie używam za szeroko skryptów ale zanam kilka sosó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.
 
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.

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
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.

I jeszcze raz proszę .. mniej zwrotów pod osobistym adresem czyli poprostu
spokojna odpowiedź/wyjaśnienie.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*