1. Ukratko, nit (thread) je „lakši“ proces. To znači da pokretanje niti oduzima manje procesorskog vremena, i da ima manje informacija vezanih za njih (zbog bržeg učitavanja).
Takođe, najčešće niti jednog procesa dele isti memorijski prostor, ali to zavisi od samog operativnog sistema i vrste niti.
2. ring0 = rad na samom procesoru do mile volje = neportabilno i nebezbedno
Loše napisan program u „ring0“ može da sruši čitav sistem. Za proces sa takvim privilegijama, bolje je biti siguran da on neće da brlja po tuđoj memoriji (pošto mu je apsolutno sva memorija na raspolaganju), pa čak može i samo jezgro da zezne. Uopšte, pisanje programa u ring0 je odstupanje od mehanizama zaštite koji su uvedeni upravo zbog loših programa. Znači, ako bismo sve programe pisali u ring0, to je vraćanje na W95 i DOS, i zanemarivanje svega što je naknadno došlo.
Prednosti koje program ima u „ring0“ je to što može svemu da pristupa neposredno: kešu operativnog sistema za fajlove, celoj memoriji, celom disku, svim uređajima (mrežnim karticama, itd.), tj. nema posrednika (API je vrsta posrednika, a svi znamo: što više posrednika, to duže traje postupak).
Apache, IIS i drugi serveri se mogu napraviti potpuno nezavisno od toga da li bilo kakva podrška postoji u jezgru. Tako, npr. Linux već 2–3 godine sadrži khttpd (Kernel HTTPd), koji istina retko ko koristi. On omogućava upravo to što MS sada ugrađuje u jezgro WS2003: brže služenje stranica.
On može da sarađuje sa bilo kojim drugim softverom (Apache, zar bi neko još nešto ;-), a radi na vrlo jednostavan način: ako stranica postoji na disku, pošalji je direktno (a to je onda veoma brzo), ako je potrebno dinamički nešto obraditi, onda prosledi zahtev serveru. MS je sigurno više toga preneo u jezgro kako bi postigao veće ubrzanje.
Takođe, problem ring0 je prisutan i sa drajverima. Npr. Linux je „monolitno“ jezgro, tj. drajveri rade sa istim privilegijama kao i samo jezgro. Zato, loš drajver može da radi na sistemu šta god poželi. Kod „mikrokernela“, drajveri su takođe izolovani, i sve što radi u ring0 je kod veličine neretko ispod 30kb. Tu je veliki problem brzina IPC-a (pošto se sve preko njega odvija), a istraživanja u ovoj oblasti razvoja operativnih sistema relativno kratko znaju za kvalitetna rešenja (rešenja koja su uporediva sa monolitnim jezgrima po pitanju brzine).
Ova vrsta dizajna je u mogućnosti da čak onemogući i sve vrste „prekoračenja bafera“, ali retke su implementacije koje idu do tih detalja. A samo zamislimo šta će nam nuditi sledeći „buffer overflow“ u Windows-u (najverovatnije ništa novo, pošto pretpostavljam da se i IIS dosad izvršavao sa dovoljnim privilegijama ;-)).
Možda se moje mišljenje promenilo, ali ne i činjenica da sam u pravu.