Já měl vždy za to, že synchronizační primitiva používaná pro synchronizaci procesů jsou daleko dražší, než v případě synchronizace mezi thready.
Krátce žijící proces je mimořádně nákladná sranda. Nakonec proto i unixy šly touto cestou: proces-per-request (short living), worker processes (long-living), multithreading. Windows jsou pochopitelně architektonicky výrazně novější, takže první ani druhý model je v nich spíše exotickou záležitostí.
Optimalizované aplikace dnes počítají na straně unixu s multithreadingem. Viz Oracle, Apache, a v podstatě cokoliv dalšího.
Nevím, jak business object, ale objektový model MS celkem funguje. Windows a všechny MS aplikace jsou dnes poskládané z objektů, což dává produktům neuvěřitelnou flexibilitu. V tom mají unixy samozřejmě také co dohánět.
Souhlasím, že často bývá limitem I/O, a nikoliv CPU. Často se to řeší zvětšením paměti (větši procento dat dostupné bez přístupu na disk), a efektivně tedy 64-bit architekturou. Dalším limitem je rychlost operační paměti, která se k dnešním CPU má asi jako šnek k formuli.
Názor ke zprávičce MS Windows Home Server poškozuje soubory
