Vlákno názorů k článku Bude svobodný software platit za intelektuální vlastnictví? od pepan - dakujme bohu ze namiesto billa je tam balmer,...
-
pepan (neregistrovaný)dakujme bohu ze namiesto billa je tam balmer, ved ten clovek mi pripada jak keby spadol zo stodoly. ked MS krachne tak to bude jeho praca. bill bol aspon vyborny obchodnik, ale balmer je len kecal, ktory nevie co trepe... jeho kecy su len pre tych "pojedacov kolacov", kazdy krory sa v tom vyzna sa len pousmeje, it gramotnost stale rastie, zachvilu nebude mat kto balmera pocuvat :)
-
Bennie (neregistrovaný)Poučte neznalce v čem tak zásadním se principelně liší Windows od Linuxu? Tedy kromě vzhledu?
Je evidentní, že půlka úspěchu MS je šikovnost a kličkování na, možná i za hranou.
Mimochodem softwarový patent je výmysl, který nikde kromě USA neplatí. Takže pokud si chtějí tyhle války vést USA, ať si je vedou. Ať to dopadne jakkoliv, nemá to právně žádný dopad v Evropě. Tady lze patentovat jen technické řešení, nikoliv postup nebo myšlenku. -
K2 (neregistrovaný)Windows a unixy se dost liší technicky. Windows mají komplexní API pro řadu věcí, pro které ho unixy nemají (správa uživatelů, multimédia, GUI, kreslení, tisk, shoda barev). Samotný kernel Windows je podstatně modernější (preemptivní, reentrantní, modifikovaný mikrokernel, podpora Unicode napříč systémem).
Jak ale ukazuje příklad Windows 3.x, 9x a MacOS 9-, uživatelé nemají problém používat technicky slabší systém. Chtějí, aby byl SW orientován na ně, na jejich potřeby. V tomhle unixy naprosto dokonale selhávají. Kdyby byl Linux dobře cílený na uživatele, technická převaha Windows by byla zcela k ničemu. -
Aha. Linux není reentrantní a nepodporuje Unicode. Tak na čem mi to běží systém, když to, co mám, Linux být nemůže? Krucinál, že on mi někdo v kernelovém balíčku podstrčil NTčka! :DDD Kdepak, to není kernel, co má problémy s Unicode - to spíš některé nástroje kolem si ještě budou muset zvyknout na UTF-8, třeba tr. (Ovšem o tom, že Windows interně používají to nejstupidnější kódování, které existuje (endianově závislé, nekompaktní, lineární složitost mnoha operací s řetězci) radši pomlčíme. :-))
On ale okénkový kernel taky není žádná super sláva. Co se mi na něm dost líbí, to je SEH a VEH. Ale třeba realtime: Pokud je mi známo, knihovny (spíš by asi zasloužily označení „binární patche“ :-)) pro „realtimizaci“ Windows jsou, pokud vím, poměrně nechutně drahé. Přitom RT rozšíření budou mergnuta do kernelu 2.6.22, pokud je mi známo. Mj. by jejich součástí měla být i preemptivnost, která v tom seznamu opravdu zatím chybí. :-) -
K2 (neregistrovaný)Podpora Unicode na unixech spočívá v tom, že se přes char-API cpe UTF-8, protože je to jediný způsob, jak na starý systém naroubovat nové features. Velká sranda nastane, když se dohromady provozují aplikace počítající s UTF-8, a aplikace s UTF-8 nepočítající. Pak dochází k chybné innterpretaci názvů souborů apod.
"Elegantní" také je, že glibc používá UTF-8 pro file operations a UTF-32 pro vybraná NLS volání. NLS volání je také možné provozovat v UTF-8, a glibc pak interně překládá vstup do UTF-32 a výstup zpět do UTF-8. Některé frameworky pak pracují v UTF-16, třeba Qt. Potom není problém, aby při v rámci jednoho volání došlo k překladu UTF-16 na UTF-8, pak na UTF-32, vlastní operaci, převodu na UTF-8, a nakonec zase převodu na UTF-16. Dále řada standardních libc C funkcí pracuje s typem char, který neumožňuje pracovat s Unicode znaky, protože tyto mohou být v UTF-8 reprezentovány více než jedním charem. Možná jsem jediný, komu tohle celé připadne "poněkud divoké". Srovnejte s NT, které mají API v UTF-16. Aplikace předá string v UTF-16, systém pracuje v UTF-16, a v UTF-16 ho zase vrátí.
Ad nekompaktní, lineární složitost mnoha operací s řetězci - nekompaktní záleží od jazyka. V čem se liší složitost operace s řetězci s 8-bit typem char a s 16-bit WCHAR? Navíc pokud na unixech pracujeme s Unicode, tak UTF-8 bude typicky převeden na UTF-32, pak zpracován, a nakonec převeden zpět na UTF-8, což je dost náročné.
Ad real-time extensions - Windows jsou modulární systém, tedy lze nahradit/rozšířit jednotlivé moduly; samozřejmě bez zásahu do zdrojáku. Konkrétně RT extensions se implementují na úrovni HAL. Jak dopadnou RT extensions pro Linux nevím, nechám se překvapit. -
Windows maji komplexni API pro radu veci, o kterych si Unix mysli ze do operacniho systemu nepatri. Samotny kernel windows obsahuje jeste casti NT 3.1 a v ramci "mikrokernelovatosti" je jeho soucasti i GUI (u verze XP) a "ochrana autorskych prav" (u Visty). Ale tu podporu unicode maji vazne lepsi, to jo.
Linux je na svoje uzivatele cileny skvele. Problem je, ze uzivatele-programatori jsou uz vsichni na linuxu a ted potrebujeme verzi cilenou na beznejsi typ uzivatele :-).
