Divny clanek p. Zajicka v News on 'Net (long)

[Milan Kerslager]

Dobry den,

dost me mrzi pristup p. Zajicka k problemum, kterym nerozumi, takze jsem
okometoval jeho zmateny clanek, ktery vysel 8. srpna v News on 'Net
(http://www.bajt.cz/).

Problem je o to horsi, ze toto zpravodajstvi je soucasti vetsiho
zpravodajskeho serveru. Nekorektni (a bez zakladnich znalosti)
vychvalovani Linuxu do nebes neni vubec prinosne a navic je zde pruhledne
i pro prumerneho uzivatele vypocetni techniky.

Nektere casti jsou vysvetleny pomerne zjednodusujicim zpusobem, jinak by
to bylo az prilis dlouhe.


On Tue, 8 Aug 2000, News on 'Net wrote:

> Proč upgrady na novější verze Windows krachují?
[...] 

Nasledujici odstavec jsem prilis nepochopil. Pokusim se jej tedy rozebrat:

> Programy Windows souběžně pracují se stejnými DLL, z čehož může
> vzcházet řada krachů.

DLL jsou sdilene knihovny, ktere se nachazeji pri behu programu v casti
pameti, ktera je jen pro cteni. Program nemuze zhavarovat proto, ze jiny
pouziva tutez knihovnu. Program zhavaruje, kdyz jsou v kodu knihovny vecne
chyby (napr. fce vrati chybne nulovy pointer a pri zapisu do mista, kam
ukazuje, dojde k poruseni ochrany pameti nebo k prepsani vlastnich dat).

DLL zpusobuji pady programu (ktere je vyuzivaji) proto, ze M$ nepouzil pro
udrzbu knihoven (DLL) zadny mechanismus verzi (jednoduse si usetril praci
tim, ze knihovny neudrzuje). Knihovna sice uvnitr obsahuje cislo verze,
avsak pruhledny system udrzby neexistuje. V knihovnach jsou chyby nebo
funkce maji nejake chovani. Pokud se toto chovani zmeni, program, ktery je
vyuziva, se dostane do potizi. M$ dodava opravene knihovny ne jako soucast
systemu (a tim padem by se zavazal k zverejnovani oprav), ale jako soucast
svych aplikaci. Pokud si tedy napr. M$ Word prinese svoji DLL, ktera zmeni
vnitrni chovani exportovanych funkci, pak konkurencni program prestane
fungovat (to plati napr. i pro starsi verzi Excelu). Uzivatel je nucen
koupit cely balik SW novy -> M$ vydela penize.

Problem tedy neni v "soubeznem pracovani", ale v menicich se podminkach
bez rozumneho oddeleni ci soucasne moznosti pouzivani novych a starych
verzi DLL.

> Tvůrci a vývojáři Unixu, Linuxu a Macu přistupují
> k využívání zdrojů při běhu programů zcela jinak. Tam se software bere
> jako jednotka, která se sama - odděleně od jiných běžících programů -
> projde neohroženě pamětí, učiní, co učinit má, a zmizí, má-li zmizet.

Model pouzivani knihoven je v M$ OS stejny, jako ve svete Unixu. Programy
nenesou ve svych binarkach knihovni funkce, protoze je to neefektivni
(duplikace). Misto toho se kod programu odkazuje na externi knihovni
funkce. Pri spusteni programu A je prislusna knihovna systemem zavedena do
sdilitelneho (jen pro cteni) useku pameti. Program B, ktery vyuziva stejne
funkce, se pak bude odkazovat do stejneho mista v pameti (pamet se sdili,
cili se setri). Pocet instanci programu vyuzivajicich sdilenou knihovnu je
neomezeny.

Zminka o "neohrozenosti" ma na mysli asi to, ze v chranenem rezimu
(protected mode, 32 bitovy rezim procesoru i386 a kompatibilnim) lze pamet
chranit, v 16 bitovem rezimu (real mode, realny rezim) to nelze. 16 bitove
instrukce tedy mohou psat "kam chteji" (a tak vznika pad systemu). V
chranenem rezimu je vsak mozne vyuzit tzv. virtualniho rezimu x86, kdy lze
vymezit oddeleny usek pameti, ktery bude 16 bitove uloze "prideleny".
Nedokonale (mozna, ze pise zadne) vyuziti tohoto mechanismu vede k tomu,
ze 16 bit. aplikace v M$ prostredi muze "sundat" cely system. Funkcni
vyuziti nalezneme u OS/2, kde 16. bit. aplikace neohrozi jadro systemu,
ale sunda jen blok pameti, kde bezi (vcetne "sve" kopie 16 bit. jadra OS).
Takovychto chranenych useku muze byt (i v OS/2) vice a mohou byt naprosto
nezavisle (to je vsak narocne na RAM pro duplikace 16. bit jadra systemu a
dalsich datovych struktur v pameti).

Linux je plne 32 bitovy, prepnuti do realneho rezimu nepovoli a 16 bitove
aplikace *musi* vyuzivat VMx86 (napr. DosEmu).

> V Linuxu se o tom snadno přesvědčíte pohledem na procenta podílu paměti,
> jakou ten který software sdílí sám za sebe (když je spuštěných programů
> příliš a paměti málo, i Linux samozřejmě swapuje na disk). A žádné DLL.

V Linuxu se vyuziva jak "normalnich" sdilenych knihoven (binarka se
linkuje proti externi dynamicky zavadene knihovne), tak DSO (dynamicke
sdilene objekty), coz je dodatecne zavedeni knihovny (resp. modulu) za
behu aplikace. Tj. prislusna knihovna nemusi byt v systemu pri spusteni
programu pritomna v systemu a program ji nemusi pouzit. V pripade potreby
si ji vsak zavede a exportovane funkce vyuzije (napr. Apache a jeho DSO,
pro PHP do Apache dalsi DSO pro rozsireni funkci o podporu databazi,
matematiky, atd). Mechanismus je funkcne identicky s chovanim a vyuzivanim
DLL ve Windows.

"DLL" tey v Linuxu existuji, jen se jim "rika" jinak. Podstatny rozdil je
v pouzitem mechanismu soubeznych existenci verzi. Implementacni rozdily
zde povazujme za nepodstatne.

Knihovny jsou v Unixovych systemech cislovany tremi cisly (napr.
glibc-2.1.3 v RH 6.2). Nejnizsi je tzv. patchlevel a jeho zmena oznacuje
opravu, ktera zachovava zpetnou binarni kompatibilitu (program linkovany
proti 2.1.0 bude fungovat i proti 2.1.30). Prostredni je tzv. minor
number, binarni kompatibilita neexistuje, program je potreba znovu
prelinkovat (neni treba jej prelozit). Nejvyssi cislo je major number,
meni se nejmene a vyjadruje generaci (tj. napr. velke zmeny filozofie
knihovny, zmenu API [tj. zmena volani funkci, jejich nazvu, vyznamu a
parametru]).

Na major verzi se dela symbolicka linka (napr libc.so.6 -> libc-2.1.3.so),
ktera oznazuje "default". O zavadeni dynamickych knihoven pri startu
programu se stara dynamicky zavadec (dynamic loader, ld.so). Tim je
zajistena centralni sprava a tak i moznost sdileni knihoven vice programy.
Normalne loader respektuje symbolickou linku, jeho chovani lze vsak zmenit
(tzv. preload knihovny, muze dojit k predefinovani, resp. zmene chovani
"normalni" knihovni funkce, nebo se vyuzije zavedeni odlisne knihovny). Z
toho vyplyva, ze v systemu lze mit vsechny verze knihoven a dokonce je lze
uchovavat na libovolnych mistech v systemu.

Swapovani je nepresny pojem. Zde jde o lidove oznaceni strankovani
(vyznamem naprosto odlisne). Pamet je rozdelena na stranky (obvykle 4kB,
ale napr. 64 bitovy procesor Alpha umi i 8kB), snahou systemu je
nepouzivane stranky odlozit na disk. V pripade, ze program pristupuje na
stranku, ktera je mimo pamet, dojde k vyvolani vnitrniho preruseni
"vypadek stranky" (page fault), ktery stranku zavede do pameti a zopakuje
instrukci, ktera vypadek vyvolala -> program pokracuje nerusene dal. OS
neumi predpovidat budoucnost (k pocitacum se nedodavaji kristalove koule),
proto OS pri rozhodovani, kterou stranku vyhodi na disk, musi vychazet z
minulosti. Obvykle je mechanismus redukovan na "spineni" stranek, kdy
pristup na stranku nastavi "spinavy bit". OS sleduje tyto bity a vypracuje
seznam nejdele nepouzitych stranek -> ty se v budoucnu zrejme nebudou
nejdele pouzivat, takze je lze vyhodit z RAM na disk.

Kvalita (i pruznost, narocnost) tohoto mechanismu urcuje kvalitu VM
(modulu virtualni pameti, tez memory managment). Castym problemem jsou
pripady trashingu (system chybne urcuje stranky pro vyhozeni, neustale
dochazi k jejich opetovnemu zavadeni, muze byt zpusobeno totalnim
nedostatkem pameti) nebo OOM (Out Of Memory), kdy v okamziku, kdy dojde
pamet, nesmi dojit k zastave pameti a system by mel "odstrelit" vinika (a
ne nevinne systemove dulezite procesy).

Ve filozofii spravy pameti tedy neni mezi M$ systemy a Linuxem rozdilu.
Vse je uzce svazano s HW podporou procesoru, takze nelze vymyslet nic
"originalniho", krome ruzne urovne kvality SW zpracovani. "Swapuji" tedy
oba, otazkou zustava, kdo vice (ci mene) plytva systemovymi zdoji.

Sdilena pamet nevznika jen pri pouzivani knihoven, ale take treba pri
opetovnem spusteni stejneho programu (typicky napr. shell v Unixech). V
tomto pripade se vyuzije toho, ze pametovy prostor procesu je rozdelen na
casti a napr. kod programu, staticke promenne a konstatanty mohou byt ve
spolecnem prostoru oznacenem jen pro cteni. Ten se pak sdili na rozdil od
prostoru se zasobnikem, dynamickymi promennymi a treba promennymi
prostredi, ktery ma kazdy proces svuj (a zapisuje si do nej sva data).

Chovani obou rodin systemu je zde tedy temer identicke.

> Nově instalovaný program ve Windows může provést cílené změny v
> operačním systému (odtud možné krachy upgradů). Něco takového je u
> Unixu/Linuxu aj. systémů nemyslitelné. Proto je jejich upgrade snadný.

Vysvetleno vyse u knihoven. Dalsi otazkou je, co vsechno je jeste system a
co jsou jiz aplikace (u M$ produktu). V Unixu instalovany program skutecne
memuze primo modifikovat jadro systemu, obvykle ani nemeni dynamicky
zaveditelne moduly jadra (obdoba DSO, ale rozsiruje dynamicky jadro o
ovladace nebo jine funkce, napr. ovladani dalsich systemu souboru, u M$ je
obdoba ve VxD). Nalezneme vsak pripady, kdy program bud prinese vlastni
modul (napr. VMWare), nebo nejaky modul meni (napr. 3Com dodava vlastni
modul pro 3C905C karty). Ve svete Linuxu je obvykle, ze je k dispozici
patch pro jadro (tj. soubor se zachycenou zmenou ve zdrojacich), u
non-open-source produktu se obvykle "nahraje" modifikujici modul (napr.
service packy u NetWare), ktere predefinuji nektere funkce (opet preload).

> Zpětná kompatibilita se ctí tak dva kroky dozadu.

Zde bylo asi mysleno "verze distribuce", coz je zcela nesouvisejici pojem
(i kdyz ke zmene major cisla distribuce obvykle dochazi ve stejnem
okamziku, jako pri zmene knihoven nebo jine dulezite soucasti systemu, aby
to uzivatel "videl" na prvni pohled).

Kompatibilita je v normalnich casovych horizontech zajistena pouhym
prelinkovanim SW, protoze volani zakladnich funkci se obvykle nemeni.
Specialni knihovny (napr. DB, knihovny pro GUI) mohou menit sve API
casteji (nasleduje zmena major cisla verze). Pak je potreba bud program
predelat, nebo vyuzit moznosti koexistence starsich knihoven v systemu
(compat- balicky).

> To neznamená, že po
> upgradu padne úplně všechen nainstalovaný software, ale že vývoj
> aplikačního softwaru sleduje vývoj operačního systému a že se do něj
> integrují jeho nové možnosti.

Aplikace a system by ze zasady nemely byt provazany. Snad jedinou vyjimkou
budou veci na systemove urovni, ktere vsak normalni programy nedelaji.
Kompatibilita se zajistuje na urovni knihoven (tj. napr. emulace threadu,
kdyz system thready v pravem slova smyslu [a kompletne] nativne
nepodporuje).

Zde je potreba si uvedomit, ze M$ si ulehcil praci a vyvoj ovladacu HW
presunul do uzivatelskeho prostoru (user space). Normalni programator
nemuze bez detailni znalosti OS (u M$ predmetem obchodniho tajemstvi)
napsat ovladac, ktery zapadne do jadra a nezpusobi katastrofu. Pokud ovsem
da tvurce OS programatorovi nadbytecne moznosti (napr. moznost zakazani
preruseni, primy pristup k HW), pak lze takovy oladac snadno napsat.
Bohuzel to povede k nestabilite systemu (ovladac HW pobezi s absolutnimi
pravy a snadno shodi cely system). Ze je to nesystemove, vi i M$ a proto
si u NT "osvojuje" ovladace (bud firma odevzda zdrojaky nebo si u NT se
svym HW ani neskrtne a ztrati trh -> M$ usetri za platy programatoru).

> Uživatel musí pochopitelně sledovat, zda
> si upgrade systému nevyžádá i upgrade už příliš staré verze nějakého
> programu. Nejlepší je průběžně upgradovat všechno (většina je na Inetu
> a za hubičku, takže žádný problém s distribucí). Výsledkem tohoto
> přístupu je robustnost celého systému a bezpečnost běhu softwaru.

Zavislosti (dependencies) mezi binarkou a knihovnami (pripadne jinymi
programy) se resi na urovni tzv. balicku. Nejznamejsimi jsou RPM (pouziva
Red Hat, SuSe, Mandrake, ...) a DEB (pouziva Debian). Balicek obsahuje
automaticky vygenerovane informace o tom, jake vsechny knihovny binarky
uvnitr potrebuji. Uzivatel pak nemusi sledovat vubec nic. Oba dva systemy
balicku vedou kompletni databazi vsech souboru v systemu. Proto je
aktualizace (upgrade), mazani nebo pridavani balicku vlemi jednoduche.

Upgradovany system nemusi byt robusnejsi, avsak i predstava bezchybneho
stareho SW je zcestna. Lepsi funkce SW se vsak snadneji dosahne malymi
postupnymi kroky, nez skokem. Take se rika "Never touch a runnig system",
coz je take pravda.... Doporucit tedy lze jednoznacne jen bezpecnostni
updaty, ostatni je vzdy otazkou volby uzivatele.
 
> Redaktor Salonu shledává přespřílišnou zahleděnost MS do enormní
> zpětné kompatibility Windows a odčerpávání značných vývojářských zdrojů
> do tvorby GUI jako koncepční nedostatek, který "replikuje" potenciální
> nestabilitu Windows i do nových verzí. Nakonec hodnotí přínos WME pro

V Linuxu lze take provozovat novou (ELF) binarku vedle stare (A.OUT).
Problem bude spise v nezajmu o perfektni dotazeni programatorske casti
(stoji to penize). Zajem je naopak o vydelani penez, takze nektere
"nedostatky" se meni primo na zlatonosne marketingove vyhody.

> uživatele, který by upgradoval z W98. Neshledává žádný podstatný. GUI
> Windows považuje za zcela nejlepší mezi všemi, a líbí se mu, že si v
> jakýchkoli Windows může pustit své staré dosovské prográmky. Jenže...

O to bych se hadal. Uz ve W'98 nefunguji nektere programy s primym
pristupem k HW. Pravda je v tom, ze prodavat opravy systemu jako system
novy, je nehoraznost (mam legalni CD, na kterem je napsano, ze je to s
USB, avsak USB kamera ani scanner s ni nefunguji. Jedine, ze bych si pry
koupil W'98). Ze si to nekteri lide nechaji libit, je jiny problem, ktery
spise zavani flame war, nez seriozni diskuzi.

> stojí to opravdu za to? MS zřejmě ano. Mimochodem, pokud se chystáte
> upgradovat na WME, dobrá zpráva pro vás - MS srazil plánovanou cenu o
> 33% z $89 na $59 (geekové rovněž srážejí cenu Linuxu - z $0 na
> $0...heč:)
>         Zdroj: http://www.salon.com/    Salon a BAJT

--
                        Milan Kerslager
                        E-mail: milan.kerslager na spsselib.hiedu.cz
                        WWW:    http://www.spsselib.hiedu.cz/~kerslage/