Ano, když dojde k chybě, je to symptom chyby. Buď v návrhu, nebo v implementaci. Viz co jse psal v 18. 6. 23:44. Podívejte se na to. Nemá smysl, abych totéž psal znovu vám.
Preemptivní kernel je takový, u kterého scheduler provede context switch i tehdy, když se aktuálně provádí kód kernelu. V praxi je podmínkou i reentrance kernelu, tedy možnost mít více threadů prováděných v kernelu. V případě SMP je samozřejmě žádoucí mít preemptivní a reentrantní kernel (jaký mají NT). Naopak tradiční unixový model, kdy jede v kernel mode jen jeden proces, a pokud jsme v kernel mode, nelze provést kontext switch, je z řady důvodů nešťastný. Ovšem dnes se tradičního modelu již řada unixů zbavila.
Transakce jsou dobré třeba u DMS systému. Máte file system či jiné zařízení, kde držíte soubory. V DB držíte informace o nich. Když přidáte dokument, chcete udělat toto: "start transakce, zapiš soubor s daty, zapiš soubor s metadaty, zapiš informace o něm do DB, commit". Transakční FS to umí.
Shody barev se docílit dá, samozřejmě s ohledem na fyzikální limity. Problém je v tom, že když máte nějakou hodnotu RGB (smozřejmě totéž pro CMYK a další), tak jí každé zařízení interpretuje jinak. Viz též gamma correction (každé zařízení má jinou linearitu odezvy). Dále se zařízení liší teplotou bílé, atd. Když máte informace o barevném rozsahu zařízení, můžete zajistit, aby se barva s danou hodnotou RGB zobrazila na zařízení tak, jak má (pokud je to fyzikálně možné). Potom si můžete vybrat, jestli chcete zachovávat barvy, které jdou přenést, a zbytek natvrdo ořezat (colorimetric CMS), nebo jesti chcete provést transformaci barevných prostorů tak, aby byl zachován výsledný dojem (fotka vypadala v rámci možností přirozeně; perception CMS). Bez informace o rozsahu tištitelných barev tiskárny nemůžete správně převést RGB hodnoty na CMYK, protože nebudete brát v úvahu minimální a maximální krytí barev, ne-čistotu barev (barva C obsahuje i stopy M, Y a K), linearitu odezvy (hodnota C 192 nemusí znamenat 75% krytí, viz gamma korekce), atd.

