Vlákno názorů k článku Linspire a Microsoft: Další dva kamarádi od jar - Možná že microsoftu dochází dech, jak je vidět...

Příští hlavní verze má kódový název Windows Vienna. Win32 kód má běžet pouze v sandboxu, zjevně půjde o posun směrem ke konceptu Singularity (.NET, Software Isolated Processes). Má dojít i k redefinici uživatelského rozhraní, uvažuje se o ovládání hlasem s analýzouo syntaxe apod. Technologie jsou k dispozici už dnes, jen je třeba je vhodně použít a namixovat. Viz například:

http://youtube.com/watch?v=MqAWHZgHU4Q - automatická recepční, automatická digitální asistentka
http://research.microsoft.com/os/singularity/ - research project, ze kterého si zřejmě budoucí Windows odnesou kus architektury. Zajímavé publikace.

Vy ste tie dokumenty ani nečítal. Toto je skutočne "basic research". Na čokoľvek sa príde, tak sa bude implementovať evolučne, nie revolučne - ak sa to vôbec ukáže ako užitočné. IBM ma tiež svoj research, INRIA má svoj. To, že dnes zakladný výskum v oblasti OS robí už aj Microsoft predsa nie je nič prevratné - veď na to má zdroje. Nebolo to tak dávno, keď jeho výskumníci len premýšľali ako vylepšiť Microsoft keyboard :)

Singularity is a laboratory for experimentation in new design ideas, not a design solution. While we like to think our current code base represents a significant step forward from prior work, we do not see it as an "ideal" system or an end in itself.

Písať tu, že Singularity je základ daľšej verzie OS od Microsoft... tak to hovorí samo za seba. Vás ale jednoznačne baví sa anonymne ventilovať na linuxových fórach.

Psal jsem, že si příští verze Windows odnese některé věci ze Singularity, což zřejmě bude pravda. V horším případě to bude přes-příští verze Windows.

MS Research je tu řadu let, a MS keyboard jde mimo ně. Ano, ostatní mají také svůj research. A jaký research má open source komunita? Počká, až někdo něco vypustí, a pak to reimplementuje jako open source (tak nakonec vznikl i Linux)?

Psal jsi:

Win32 kód má běžet pouze v sandboxu, zjevně půjde o posun směrem ke konceptu Singularity (.NET, Software Isolated Processes)

Mas k tomuto tvrzeni nejake podklady?

http://en.wikipedia.org/wiki/Windows_Vienna

O SIP se tam nemluví, ale můžete hádat, jaký je důvod příklonu MS k .NETu. Nakonec projekt Singularity udělal za poslední rok velký pokrok, a podle mě si výsledky MS nenechá ujít.

Takze cira spekulace?

A jaký research má open source komunita? Počká, až někdo něco vypustí, a pak to reimplementuje jako open source (tak nakonec vznikl i Linux)?
Linux vznikol od zakladu a ako vzor si bral minix(Windows vzniklo ukradnutim kodu z apple). Vista ma 3D desktop a aj brutalne poziadavky na HW(linux ma tiez 3D desktop a nema brutalne poziadavky na HW, lepsie povedane ma stale tie iste poziadavky ako bez 3D desktopu, asi az na VGA, ale aj integrovane uz maju aku taku podporu 3D akceleracie) tu vidiet ten MS Research...

Linux vznikl od začátku, ovšem jako přepis UNIXů. Stejné API, stejně filozofie, stejné všechno. Ano, na začátku byla inspirace Minixem, ale to na věci nic nemění.

Windows vznikly na zdrojácích Apple? :) Podívejte se na Windows 1.0, jejich možnosti, a na tehdejší Apple. Apple byl o hodně dál. Těžko si představit, jak zdroják OS z Motoroly někdo použije v grafické nadstavbě DOSu ;). Koncepty GUI byly převzaty od Apple (což bylo právně čisté); Apple ty koncepty obdobně převzal od Xerox Star.

Pokud mluvíme o NT, tak ty byly napsány opět z nuly, s využitím zkušeností z OS/2, a hlavně zkušeností týmu Dave Cutlera z vývoje VMS.

Vista má 3D akceleraci GUI, včetně 3D akcelerace kreslení fontů, ClearType apod. Okna (nativních aplikací) se skládají pomocí 3D akcelerace z primitiv. Linuxové 3D desktopy jsou jen kompozitní managery, které zobrazují pomocí 3D technologie okna, která jsou klasicky SW renderovaná. WPF je výrazně technologicky pokročilejší. HW náročnost není tak vysoká, jak si představujete - zkuste si to. Navíc Vista je určená pro nové počítače; nemá smysl dnes psát systém pro 2GHz Pentium III s S3 Trio64, když takový systém už dávno nekoupíte.

Vy si predstavujete open-source komunitu ako bandu aktivistov, ktorí veselo kodujú kernel v miestnom výčape. Je to úsmevná predstava ale tak to nefunguje. Research robia univerzity, štátne vedecké ústavy a veľké firmy. Či sú výsledky práce vydané ako open-source je vecou danej inštitúcie. INRIA vydáva ako open-source skoro všetko, Microsoft Research malú časť ale platí napr. vývoj GHC Haskell compilátora ktorý je open-source. Stavať nejakú iluzórnu open-source komunitu vs Microsoft je naivné.

Samozřejmě sázka na managed jazyky nemusí vyjít, ale zatím tomu nic nenapovídá. Současná situace (buffer overflow kam se člověk podívá, obrovská spousta chyb v C/C++ kódu) potřebuje řešení, a koncept Singularity ukazuje cestu.

Mikrokernely umřely na náročnost kernel mode transition. V NT z mikrokernelů zbyla modularita a popsaný interface mezi komponentami, ale servery běží v kernel mode. Faktem je, že po slibném začátku mikrokernely odpadly, a s managed jazyky se může stát totéž.

Thread safe garbage collection je samozřejmě problém. Ovšem je možné provádět collection nezávisle pro každý proces. Singularity má levné "procesy" (SIP), takže je jich velká hromada, a tedy garbage collection není tak katastrofický.

Ohledně validace kódu doporučuji http://research.microsoft.com/os/singularity/ , a zvláště tuto publikaci:
http://research.microsoft.com/copyright/accept.asp?path=http://www.research.microsoft.com/os/singularity/publications/MSPC2006_DeconstructingIsolation.pdf&pub=ACM
V je to popis Software Isolated Process. Ve zkratce managed jazyk (C#, cokoliv jiného na .NETu, od konkurence Java) zaručuje, že aplikace nemůže například castovat integer na pointer, hrábnout mimo svůj address space, atd. Tento kód se přeloží do MSIL (u Javy by to byl bytecode). Na cílovém počítači se provede verifikace MSIL kódu, překlad do nativního (v našem případě x86) kódu, a v praxi by se výsledek zřejmě digitálně podepsal. Výsledný kód, stejně jako operační systém, běží v ring 0. Přitom je předchozí kontrolou zajištěno, že aplikace nemůže hrábnout, kam nemá. Výhodou je, že při volání systému vůbez nedochází ke kernel mode transition, takže je režie volání velmi nízká (cca 8x nižší než na tradičním systému). Pro kompatibilitu s dnešním kódem umí Singularity i "klasické procesy" v ring 3.

Samozřejmě popsaná validace řeší pouze bezpečnost, neumí třeba najít deadlock. Obecně vzato lze provést statickou analýzu kódu, která modeluje algoritmus jako stavový automat. Ten by byl zpravidla příliš velký, nicméně lze vyvodit jisté závěry pro menší kusy kódu (třeba modul, class), a na vyšší úrovni abstrakce z toho vyvozovat závěry. Jo do managed jazyků je třeba zavést invarianty, jinak je statická analýza poněkud problematická.

Jisté nástroje jsou i pro C/C++ (PREfast), ale v unmanaged jazyku v principu těžko odhadnout, co se stane po castu integeru na pointer ;). Pro .NET nabízí dnes MS FxCop, ale to je samozřejmě jen začátek.

OS (včetně kernelu) může být napsán převážně v managed jazyku (samozřejmě nakonec přeloženého do nativního kódu). Výše je vidět, jaké výhody to může přinést. MS je podle mě v této oblasti leaderem, protože má rozjeté zajímavé projekty, a má dostatek kvalitních lidí i peněz, aby to dotáhnul do konce. Otázka je, jestli to bude v příští verzi Windows, nebo až v té další. A samozřejmě je další otázka, jestli to trh přijme (a MS získá pár desítek let nádskok nad konkurencí), nebo se na tom MS složí. Za 10 let to bude jasnější ;)

Mě třeba Windows mrznou jen když se v chladiči CPU usadí dost prachu. Pak teplota vystoupá nad 60 st při běžném přehrávání MP3, a občas spadnou. Co se týče vašich známých, tak ochopitelně nemohu hodnotit je, jejich HW, ani použité drivery. Zato mám vlastní zkušenosti.

Mam kolem sebe (bohuzel) spoustu wokenicaru a ikdyz jsou nekteri z nich fanatici do woken presto slysim ze jim to pada porad a v ruznych podivnych situacich, jsou to od zakladnich bfu po programatory. Btw dlouhos nepouzil slovo Singularity :-) je to v tvejch prispevcich bez toho takovy "neuceleny a nepresvedcivy" :-D

Vite, nechtel jsem se do tehle diskuze nechat zaplest, ale Vas styl prispevku me k tomu donutil. Nevsiml jsem si, ze by autor prispevku na ktery reagujete se k Vam choval arogantne nebo nekoho nazyval blbcem. Pokud nedokazete vecne argumentovat, radeji na ty "blbce" opravdu nereagujte. Udelate tim sluzbu sobe i ostatnim. Jste typicky priklad fanatika, ktery se uchyluje k vulgaritam, kdyz mu nekdo sahne na jeho modlu. Autora obvinujete z toho, ze nic nevi o Linuxu (coz z jeho dalsich prispevku rozhodne neni pravda), ale sam nic nevite o Windows (a o Linuxu taky), ale presto se do podobnych diskuzi poustite. Z Vaseho prispevku je zrejme, ze jste to Vy, kdo ma omezene znalosti (nechapete rozdil thread vs. proces, nevite co autor myslel color managementem, myslite si, ze ma Linux priorizovana preruseni atd.), ale mate drzost nekoho takto arogante urazet. Jste ostuda uzivatelu Linuxu.

Ale k veci:

... taková záruka je na nic, když ti program nezafunguje ...
Co je to za blabol? Proc odsuzujete neco, co pomaha napsat robustnejsi aplikaci? Napsal jste nekdy vicevlaknovou aplikaci, kde mezi sebou komunikuje vic threadu? Garantuji vam, ze v kazdem takovem slozitejsim programu alespon jednu chybu typu "race condition" nebo "memory leak" udelate. A kdybyste si to zkusil, vedel byste, jak tezko se chyby tohoto typu hledaji. Cokoliv, co toto usnadni je vitane a jenom hlupak to shazuje.

Nevim proc argumentujete winem. Je to sice hezka vec, ale k dokonalosti ma teda dost daleko. Krome jednoduchych utilitek bych si to do produkcniho prostredi nasadit netroufl. A ty "rychlejsi programy" bych taky chtel videt, ja mam zkusennost presne opacnou. Ale asi nepouzivam "ty prave programy". A ty optimalizovane drivery - jako priklad si zjistete kolik ruznych stacku ma Linux pro wi-fi a jak nekompatibilni jsou jejich user-spacovy interfejsy. Totalni hruza. A zkuste si obcas precist jaderne novinky na abicku, me z toho obcas vstavaji vlasy hruzou na hlave, jak se reseni nekterych problemu bastli,lepi a obchazi. Pat a Mat hadra.

Co maji Windows navic v multimedich? Obecne (a to se netyka multimedii) maji velice pochopitelne a dobre navrzene API (tim myslim .NET ne Win32Api), ktery je konzistentni at se jedna o grafiku, zvuk, sit a nebo treba bluetooth. A dokumentaci na jednom miste. Linux je tzv. "kazdy pes, jina ves". Ano, je to logicke, podle toho jak vznika, ale za dusledek to ma to, ze se pro nej programuje hur. Pro kazdy subsystem se musi extra shanet dokumentace, nekdy je tech subsystemu vic a nemate zaruceny, ktery z nich u koncoveho uzivatele bude atd. A na tohle hodne lidi slysi, protoze programator je clovek liny. A proc delat veci slozite, kdyz to jde jednoduse. A ono se ve Visual Studio v .NET programuje opravdu dobre a nepotrebuji zadnou mezivrstvu, protoze ta je uz tvorena .NETem. Ale vy asi programator nejste...Mam trochu strach, ze prave .NET dost lidi odezene a zpovyka a nebude se tolik aplikaci pro Linux portovat. Ale v tomto snad nemam pravdu.

Ze nevite co znamena color management jasne dokazuje, co jste vlastne zac (ale pritom si myslite, ze jste snedl vsechnu moudrost sveta). V jinem prispevku je to vysvetleno, zkuste se zeptat nejakeho DTPaka, co dela profi sazbu. A ne, zadne klikatko to opravdu neni, musi to byt integralni soucast systemu, aby to melo smysl.

Linux nema priorizovane interupty. Tecka. Vite kulovy. Precte si BLEKovy clanky.

Nejste programator (nebo jste spatny) takze nechapete rozdil proces vs. thread. Na serverove aplikace se hodi procesy, protoze tam neni potreba sdilet pamet a odstineni jednotlivych pripojeni je zadouci. Thready se pozivaji do desktopovych aplikaci, kde je potreba delat vice ukolu soucasne, ale pamet je potreba sdilet. Proto je Linux lepsi na servery a Windows na desktopove aplikace. Windowsum chybi fork, Linux ma zoufale udelane thready.

A, a muzete mi poradit, jak z aplikace zahajim na ext3 transakci a jak ji ukoncim? To bych teda moc rad vedel. Vite vubec o cem pisete?

Ne, opravdu me fascinuje vase hulvatstvi, arogance a pritom neznalost. Opravdu uz nereagujte, pokud mate v umyslu pokracovat timto zpusobem. Muzeme diskutovat vecne, ale nehodlam vest dialog s nekym, kdo me (nebo kohokoliv jineho) oznaci za blbce, machra ktery nic nevi a debilem, jenom proto, ze mam jiny nazor nez on. Krome znalosti si zkuste jeste doplnit mezilidkse vztahy.

Mimochodem, abyste me neobvinoval ze jsem agent MS. Nejsem. A pouzivam primarne Linux. Ale nejsem fanatik a dokazu se podivat i ke konkurenci a uznat, co maji lepsi. Na rozdil od Vas.

A zkuste si obcas precist jaderne novinky na abicku, me z toho obcas vstavaji vlasy hruzou na hlave, jak se reseni nekterych problemu bastli,lepi a obchazi. Pat a Mat hadra.

V takovych pripadech je obvykle lepsi precist si original na LKML nez nekolikrat prechroustany text, jehoz vyzneni je ovlivneno nazory 'chroustacu' a navic casto vytrzene z kontextu.

Co maji Windows navic v multimedich? Obecne (a to se netyka multimedii) maji velice pochopitelne a dobre navrzene API (tim myslim .NET ne Win32Api), ktery je konzistentni at se jedna o grafiku, zvuk, sit a nebo treba bluetooth. A dokumentaci na jednom miste. Linux je tzv. "kazdy pes, jina ves". Ano, je to logicke, podle toho jak vznika, ale za dusledek to ma to, ze se pro nej programuje hur. Pro kazdy subsystem se musi extra shanet dokumentace, nekdy je tech subsystemu vic a nemate zaruceny, ktery z nich u koncoveho uzivatele bude atd.

Ono je otazka, ktery z techto pristupu k interfacum je lepsi. Navrh interfacu ja napul magicka cinnost, pro kterou nejsou dostatecne znama racionalni objektivni kvalitativni kriteria. Pokud mas vic soupericich pristupu k dane problematice, tezko apriori rici, ktery z nich je lepsi (a zda jsou vubec porovnatelne). Ve Windows proste MS rekl - tento interface je spravna cesta. To ale nutne neznamena, ze to je nejlepsi z moznych cest. V Linuxu je demokraticky vyvoj - kazdy programator svym rozhodnutim hlasuje pro nektera z techto API tim, ze je pouzije ve svych programech. Pokud bych mel pritomnost nejakeho API zarucenou, tak zaroven bych se (jako uzivatel) nemohl daneho subsystemu zbavit, pokud bych ho nepotreboval.

Linux nema priorizovane interupty.

Predchozi clanek se ale vyjadroval k prioritizovanym I/O operacim, nikoliv k interruptum.

Ja netvrdim, ze cely Linux je bastl, v zadnem pripade, ale musite uznat, ze obcas se to lepi dost zoufale. WiFi drivery jsou podle me zarnym prikladem (ale snad to po implementaci mac80211 bude lepsi, snad se toho doziju ;-)

Pro me jako programatora, ktery musi zarucit, ze program pojede na kteremkoliv pocitaci u kterehokoliv zakaznika je spis podstatnejsi to, ze je API jedno a je konstatni (ne ze tady zas zacne nekdo vyrvavat, ze Win95 se chovaly trochu jinak new Win3.11 a Win98, o tehle vykopavkach se bavit nehodlam). Od win2k se Win32 API drzi pekne a s .NETem pujde i docela dobre pouzivat bez mezivrstev.

Kdyz chci prehrat zvuk, tak vim, ze kdyz bude chodit u me na XP, bude chodit na vsech XP,Vistach a 2K. Kdekoliv. A nemusim psat 3 pluginy pro Alsu/Arts/ESS. Proste mit system kde na blbe prehrani zvuku musim premyslet, jestli ma mixer nebo nema mixer a kdyz ma mixer, jestli ma ten a nebo ten a psat pro ne pluginy je proste nocni mura. Sice je fakt, ze podobna situace se da najit u Windows taky (peklo Bluetooth stacku) prece jen na Linuxu je castejsi. A ja radsi prekousnu horsi API nez jeho kvantitu. Zrovna v tomhle punktu to uz nenazyvam svobodou ale anarchii. Ne, ja se opravdu trosku bojim, ze kdyz firma udela v .NETu slusne a ciste napsanej program a rekne, ze si by ho treba i portovala na Linux a uvidi tuhle anarchii a nekonzistenci celyho API a zaroven neexistenci nejakyho objektovyho frameworku, ktery by to vse zastresoval a zjednodusoval, tak si rekne, ze to za to nestoji a vykasle se na to.Ale chtel bych se mylit.

A co se tyce tech I/O operaci... Mate pravdu, bylo to o operacich a ne o interuptech (a ani jedno Linux nema), ale domnivam se, ze tezko se daji udelat priorizovane I/O bez priorizace IRQ, takze bych to za tak velky omyl nepovazoval.

Pokud jsem si všimnul, aplikace pro Linux napsané v Mono už nejsou až takoví exoti.

Mohl bych se zeptat, jak se to má v Linuxu s I/O prioritizací a ionice? Ionice je údajně jen pro čtení, a nevím, jestli je to opravdu prioritizace, nebo jen nějaký hack.

Ja netvrdim, ze cely Linux je bastl, v zadnem pripade, ale musite uznat, ze obcas se to lepi dost zoufale. WiFi drivery jsou podle me zarnym prikladem (ale snad to po implementaci mac80211 bude lepsi, snad se toho doziju ;-)

Uznavam, ze situace v oblasti wifi driveru je dost neuspokojiva. Nenazyval bych to ale problem bastlu a lepeni (coz jsou obvykle vyrazy pro vyuzivani existujiciho kodu naprosto nevhodnym zpusobem), jako spis nedostatecne koordinace mezi vyvojari ruznych wifi driveru (a tedy spis nevyuzivani jiz existujiciho kodu a zbytecna duplikace).

A co se tyce tech I/O operaci... Mate pravdu, bylo to o operacich a ne o interuptech (a ani jedno Linux nema),

Viz ionice.

ale domnivam se, ze tezko se daji udelat priorizovane I/O bez priorizace IRQ, takze bych to za tak velky omyl nepovazoval.

Domnivam se, ze obsluha IRQ ma na priorizaci I/O operaci zcela marginalni vliv. Prioritizace I/O operaci je koncepcne podobne treba sitovemu shapingu - pri zapisu/cteni dat na disk (odeslani/prijeti paketu) si vybiras pozadavek k zpracovani nikoliv podle FIFO, ale podle priorit. Dulezity je tedy vyber pozadavku, ktere se predaji hardware. U pevnych disku jsou samozrejme komplikace se slozitym ovlivnovanim vyrizovani jednotlivych pozadavku.

Jestli kvůli přehrání zvuku píšete pluginy, tak vás fakt lituju :-D
Hustej humor... dík!

vase nazory jsou zkresleny dosti ovlivnenim ms, divim se ze jste tu a pouzivate vubec linux ...

Aa, dalsi fanatik se ozval. Argumentovat sice neumite, ale hloupe se navazet ano. Ne nejsem ovlivnen MS. Mam svuj vlastni rozum a tvorim si vlastni nazory. A to proto, ze pracuji s obojim. Neco se mi vic libi na unixech (na tech delam zejmena embedded systemy, tam se Windows (CE) nemuzou s Linuxem merit (alespon pro me), jejich desktopove rizeni pak multiplatforme Linux/Windows. Takze znam oboje a to prvni se mi dela (mnohem!) lip v Linuxu na to druhe jsou podle me lepsi Windows. Na rozdil od vas to netvrdim fanaticky, ale proste proto, ze to vychazi z me praxe.

O Vas bych rekl bych, ze jste trochu blazen (ale to jste tady myslim i priznal), pokud se domnivate, ze je svet cernobily. Ze vsechno co udela MS je spatne, zle, ze tam delaji pouze ti nejhorsi programatori, ale to co v Linuxu zbastli kdejaky studentik jako diplomku (neurazim, ale dost veci tak opravdu vzika [a konci]) je lepsi. Ne svet neni cernobily a nic neni totalne spatne a na druhou stranu neni nic absolutne dobre. Pokud jste to ve svem veku jeste nepochopil, je mi vas lito. Opravdu mi reknete, ze jste nekdy pod windows napsal vice vlaknovou aplikaci s ruznymi komunikacnimi procesy, slozitejsi grafikou a databazovanim (a odpovedi,ze kdysi davno ve Win95 jsem napsal Hello World neberu). Nebudu Vam verit, protoze to ani neni pravda.

Ja opravdu nechapu, proc mate takovou potrebu zde placat o necem, o cem vubec nic nevite a jeste urazet ty, co si vlastni praxi vytovrili jiny nazor nez vy. Ja mam Linux rad, fandim mu, ale na rozdil od Vas nejsem fanatik a nebudu se do krve hadat, ze je neco lepsi, kdyz si myslim, ze to neni pravda.

Moje programy nejsou pro BFU, ale do prumyslu. Musi fungovat. Takze diky za poklonu :-)

pro prumyslova bfu? :-)

"tvorim si vlastni nazory"

-- nevypada to tak

"...ze jste trochu blazen..."

-- trochu vic :-)

-- obecne ty kody studentiku byvaji lepsi nez nejakych freeware spyware ja nevim co ware (krom slackware:-)) na wokna, komercni appz mozna ne, tezko rict wokna nepouzivam a neznam, nicmene stejne si to nemyslim"

"svet neni cernobily"

-- to rozhodne neni

"vicevlaknovou aplikaci"

-- pro win jsem nikdy nic nenapsal, jednou jsem na nich delal a nemohl jsem najit jak se mountuje cdrom tak jsem to zabalil

"na rozdil od vas nejsem fanatik"

-- tato ma identita, ano mam jich zde vice, je vytvorena za ucelem byt fanatik s mirne omezenymi tech. znalostmi, obcas mi to (ne v teto diskusi) ujede, protoze tech. znalosti o unixech mam pomerne siroke, ale snazim se to drzet v mezich, tato ma osobnost je spise rypavy nadsenec, ktery ma obecnejsi prehled, kdyz se budete bavit s mou jinou osobnosti, asi ji date za pravdu :-) preji pekny zbytek dne!

0) Netykáme si.
1) Pokud vám nedochází, že záruka typu "nemůže dojít k buffer overflow", případně "nemůže dojít k deadlocku" je zcela novou kvalitativní úrovní SW engineeringu, tak není chyba na mé straně. U kódu v C/C++ totiž tohle nikdo nemůže nijak zaručit (nelze provést automatickou analýzu kódu). Dnešní research projecty tohle umí částečně zaručit v Javě a v .NETu. Tady se ten koncept posouvá na úroveň celého OS a všech (nativních) aplikací. Letos všichni budeme ohroženi stovkami chyb typu buffer overflow, bude používána obrovská spousta kódu který může vést (a povede) k deadlockům, velké procento kódu má chybný návrh či implementaci. Budeme tedy mít bezpečnostní chyby, programy budou selhávat a padat (na všech platformách). A nikdo s tím nemůže nic udělat. Popsané koncepty ukazují cestu ven. Někdo to ale holt nechápe...
2) A: Wine je nedodělaná emulace, která se s původním systémem těžko může měřit. Víc k tomu snad není co říci.
3) B: Windows mají preemptivní kernel od roku 1993, kdy byla uvedena první verze NT. U Linuxu je preempce kernelu od verze 2.6 (ve 2.4 tuším jako externí patch), a díky špatné implementaci (výkon, bugy) se distra nadále dodávají bez preempce kernelu.
C: V multimédích mají Windows třeba modulární framework kompresorů a dekompresorů (DirectShow), a API pro zacházení s multimédii.
D: Color management je věc, která zajišťuje, že barvy na skenu, na obrazovce a na výtisku budou vypadat stejně. Každé zařízení má barevný profil, který říká, jaký rozsah barev (gamut) umí zobrazit. Pokud mám například monitor s vyšší teplotou bílé barvy, Windows automaticky zobrazují grafiku tak, aby zůstaly barvy zachované. Ttotéž při tisku. Vyjma toho je součástí třeba modulární systém výroby separací (třeba separace do CMYK, pokud víte, o čem je řeč), s default modulem od firmy Linotype Hell, tj. pokročilý převody mezi barevnými prostory. Ve Vistě je navíc podpora HDR (barevné hodnoty i jako floaty, tedy třeba 96 bitů na pixel). Zmínky o barvení oken a klikátkách svědčí o naprosté neznalosi problematiky. Holt to není příkaz na command line, tak to neznáte ;)
E: Linux má prioritizaci I/O? Takže mohu říci "čti ze souboru, a má to nízkou I/O prioritu", případně "potřebuji garantovat přenos 700kB/sec pro tuto aplikaci"? Obávám se, že to Linux neumí. To druhé umí IRIX s XFS (nikoliv Linux s XFS).
F: ACID - ext3 samozřejemě není ACID. Nelze říci "začátek transakce; smaž soubor; udělej změnu v souboru; zapiš něco do DB; založ nový soubor a zapiš do něj", a potom říci "commit" (udělej to vše), nebo "rollback" (neudělej nic), s tím, že je to "vše nebo nic". Kdybyste byl na MFF dále než v prvním semestru, možná byste věděl, o čem jsou transakce a co znamená ACID (ne, pod jazyk se to nedává).

Abych to uzavřel, několikrát jste předvedl, že mimo jste vy. K tomu pár výpadů, některé vulgární. Reagovat nemusíte, můžete si jít hrát s plyšovým Tuxem.

No zajímavé... Když už jste to nakousl - jak můžete zaručit, že k něčemu stoprocentně nedojde? Například k přetečení zásobníku? Když k tomu dochází, tak je to jen symptom nějaké jiné chyby.
Co myslíte pod "preemptivní kernel"?
Priorita IO... to nezní špatně, ale byl bych skeptický. Může to přinést víc škody než užitku, pokud se to vezme za špatný konec.
A ty transakce - k čemu je to dobré?
Pokud jde o barvy, tak bych jen řekl, že není možné docílit shody barev na papíře a na obrazovce monitoru nebo LCD, prostě to nejde už z fyzikální podstaty a nic na tom nezmění ani 96bitů na pixel. Pokud jde o barvy, tak opravdu true WYSIWIG je buď hoooodně daleko, nebo na současných technologiích nerealizovatelné.

Ve světě výpočetní techniky se pohybuji už hodně dlouho, dá se říct že jsem pamětník a zjišťuji že mnoho podobných koncepcí už se zkoušelo v minulosti (aka Multics) ale neosvědčilo se. V mainstreamu se nepohybuji, proto se ptám tak hloupě.

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.

Stále nechápu. Proti destrukci způsobené přetečením zásobníku mě ochrání MMU. Pokud k něčemu takovému dochází, je to jiná hrubá chyba a nic jiného než odstřel procesu na základě generované výjimky nemá smysl provádět. To už známe 40 let. Ladit takové situace už umíme ještě déle.

Aha, takže ve skutečnosti myslíte reentrantní kernel? Kde jinde než v rámci kódu jádra se podle vás provádí přepnutí kontextu? To máte nějaké popletené... Hlavně tedy nechápu, proč by se to mělo nazývat preemptivní kernel, z terminologického hlediska je to nesmysl. Jádro může být reentrantní nebo nemusí. Pokud podporuje multitasking, v podstatě jakoukoli formu, pak musí být reentrantní vždycky, to je základní předpoklad celé filosofie multitaskingu. V případě preemptivního multitaskingu je jen otázkou, zda přechodem na kód jádra má dojít k zákazu přepnutí kontextu z popudu časovače, či ne. Jednoduchá odpověď neexistuje. Zajistíme-li, že operace nevedoucí k přepnutí kontextu proběhnou rychle - a o to by mělo jít vždy - pak tento zákaz přepnutí v rámci sdílení času nevadí. Pokud naopak přepnutí povolíme, znamená to, že dodatečně musíme ošetřit kritické sekce nad strukturami jádra, což zpětně vede ke zpomalení služeb jádra. Rozhodně v žádném případě není pravda, že by to mělo vždy za následek zvýšení průchodnosti jádra!!! Naopak tímto mechanismem můžeme neúměrně zvýšit režii systému způsobenou zbytečným přepínáním kontextu, což je časově poměrně náročná operace.

Pokud jde o ten FS, jestli jsem to dobře pochopil, tak jde teda jen o převzetí způsobu práce s databází na úroveň FS. To už se zkoušelo někdy v 70. letech nebo na konci 60. let, ale zavrhlo se to a byly k tomu dobré důvody, proč to tak nedělat.

Ano, ma to trochu popletene.
On potrebuje trochu shodit Linux...tak se snazi, no :-)

Ale že blafujou hustě, co...?

Oddělení procesů stojí celkem dost prostředků. Takový context switch není zdaleka zdarma, a kernel mode transition je ještě dražší. Popisoval jsem tu v jiném příspěvku alternativní způsob oddělení procesů (SIP), a dával tam linky. Podstata je ale v tom, že řešit nastalý problém je v podstatě k ničemu, protože mléko je už rozlité. Pokud například jazyk neumožní pointerovou aritmetiku (a pointery na funkce zapouzdří tak, aby s nimi nešlo manipulovat), odstraní se příčina řady chyb. Viz též co jsem psal o statické analýze kódu (například záruka typu "kód oneobsahuje deadlock").

Ano, preemptivní (za běhu kódu můžeme utrhnout execution a provést context switch) a reentrantní (kód lze provádět na více místech najednou) kernel. Mluvím o přepnutí kontextu ve chvíli, kdy se thread (proces) nachází v režimu jádra. Samozřejmě pokud kernel není preemptivní, zvyšuje se lacency. Pokud není reentrantní, je to problém při SMP (scalability velmi trpí). Samozřejmě preemptivní a reentrantní kernel nesmí držet statická data, a kde je to nutné (jako že takových míst je dost), musí se použít nějaký mutex. Když se tak postupuje od návrhu, je to celkem v pohodě. Pokud se preempce kernelu implementuje dodatečně, zavání to hromadou bugů (viz Linux kernel s CONFIG_PREEMPT), a mizerným výkonem (opět viz Linux; nevyznám se v Linx kernelu, ale zřejmě by to chtělo snížit míru používání statických dat, což se dodatečně bude dělat velmi špatně).

ACID FS nesouvisí s DB. DB jsem použil pouze pro demonstraci možností. Jiným použitím je, když zahájím transakci, na webový server budu pět minut kopírovat novou verzi aplikace, a pak dám comit. Nejprve budou všecny soubory ve staré verzi, a po commitu v nové verzi. Možností použití transakcí je celá řada.

Oddělení procesů stojí celkem dost prostředků. Takový context switch není zdaleka zdarma, a kernel mode transition je ještě dražší.

Neni to naopak?

Ano, preemptivní (za běhu kódu můžeme utrhnout execution a provést context switch) a reentrantní (kód lze provádět na více místech najednou) kernel. Mluvím o přepnutí kontextu ve chvíli, kdy se thread (proces) nachází v režimu jádra. Samozřejmě pokud kernel není preemptivní, zvyšuje se lacency. Pokud není reentrantní, je to problém při SMP (scalability velmi trpí). Samozřejmě preemptivní a reentrantní kernel nesmí držet statická data, a kde je to nutné (jako že takových míst je dost), musí se použít nějaký mutex. Když se tak postupuje od návrhu, je to celkem v pohodě. Pokud se preempce kernelu implementuje dodatečně, zavání to hromadou bugů a mizerným výkonem

Reentrantni je jadro uz pekne dlouho - kvuli multiprocessingu. Pridat tam pak preempci uz neni zas takovy problem. Mas nejake podklady ohledne tvrzeni, ze Linux ma mizerny vykon a hromadu bugu v kombinaci s CONFIG_PREEMPT (napr. relativne k Win), nebo jen mlzis?

Já mám stále pocit, že mluvíte cizím jazykem.
Co myslíte tím, že oddělení procesů stojí dost prostředků? Uveďte prosím nějaký příklad, asi oba myslíme něco jiného, protože nechápu co na tom co myslím já by mohlo stát mnoho prostředků.
Přepnutí kontextu je jedna z časově nejnáročnějších operací, která na systémech s ochranou paměti prakticky odsoudila mikrojádra mimo hru, souhlasím a řekl bych, že oba myslíme to samé. Co myslíte pod pojmem "kernel mode transition", že je to podle vás zase tak drahé? S rozlitým mlékem souhlasím, sám jsem to řekl hned v první reakci. Pokud jazyk něco neumožní, znamená to předpoklad, že ten jazyk je používán blbem nebo nezkušeným člověkem, který neví co dělá - př. Pascal. Problémů, které tím způsobíme, je ale víc, než těch, kterým jsme zabránili. Uzavřeme si cestu k přímočarým efektivním řešením, budeme muset okecávat jednoduchou věc tak, abychom nepoužili přímočaré, ale potenciálně nebezpečné řešení. Tudy rozhodně cesta nevede, je to příliš defenzivní způsob programování který přímo implikuje neefektivní řešení problémů. Zabránění deadlocků se zkoumalo celá desetiletí a bylo to dávno uspokojivě vyřešeno. Pokud neprogramuje prase, řešení je snadné, stejně jako dynamická detekce deadlocku když už k němu dojde. Staticky objevit deadlock je věc neřešitelná a matematicky je toto tvrzení dávno dokázané, viz přednášky z OS (nebo už se to dnes neučí?).

"Ano, preemptivní (za běhu kódu můžeme utrhnout execution a provést context switch) a reentrantní (kód lze provádět na více místech najednou) kernel" - co myslíte větou "za běhu kódu můžeme utrhnout execution a provést context switch"? To snad ani nemá hlavu a patu, nebo opět myslíme oba něco jiného. Znovu opakuji, že k přepnutí kontextu jindy, než v okamžiku, kdy se vlákno (proces) nachází v režimu jádra, dojít nemůže. Už z principu - trošku si ty přechody stavů představujte. A pokud povolím časovači, aby přehodil kontext ve chvíli, kdy se proces v režimu jádra schyluje k uspání sama sebe a přepnutí kontextu, pak tím na průchodnosti systému rozhodně nepřidám. Znovu opakuji, že to není tak jednoduché, jak to tu presentujete. SMP bych sem vůbec netahal, s tím jsou spojeny jiné problémy a reentrance leží mnohem níže. U SMP je problém potřeba provádět některé typy operací jednou instrukcí, ale to zas tak příliš nesouvisí s reentrancí jako takovou. Reentrance je nezbytná pro multitasking vůbec. Bez reentrance není multitasking a bavit se o SMP už pak vůbec nemá smysl. Takže opět nějak nevím, co myslíte větou "Pokud není reentrantní, je to problém při SMP (scalability velmi trpí)". Opět se mi zdá, že věta nemá hlavu ani patu, nebo že se bavíme o různých věcech.
"Samozřejmě preemptivní a reentrantní kernel nesmí držet statická data, a kde je to nutné (jako že takových míst je dost), musí se použít nějaký mutex" - jádro bez statických dat si představit nedokážu. Reentrantnost ještě neznamená, že je nutno použít nějakou formu IPC. To je spojeno až s tím, co nazýváte preempce, ale ani tehdy to není nezbytně nutné - záleží na situaci a na řešení. Často je průchodnější kritickou sekci řešit prostě zákazem přepnutí kontextu - pokud se jedná o časově zanedbatelnou trivialitu typu změna údaje v tabulce procesů. Postavit nad tím semafor by bylo méně efektivní. V každém případě dopsat ochranu před kritická data není zas takový problém oproti situaci, kdy to tam je od začátku. Velice často se to tak dělá - jádro se odladí se zákazem přepínání a pak se postupně povoluje přerušení v dalších a dalších místech. Není to rozhodně nic, co zavání nějakými kritickými problémy. Dá se předpokládat, že i NT se takovým způsobem ladily. Odkud plyne váš přepoklad, že to nutně zavání mizerným výkonem, je pro mne neznámá. Používání statických dat na výkon systému negativní vliv mít nebude. Náhradou za lokální data se problém může ještě prohloubit.

Ty transakce jsou mi už jasné... jistě se najde řada aplikací, kde to má nějaký smysl, ale otázkou je jestli jich je tolik, aby se to muselo implementovat na úroveň FS.

Ano, mluvíme každý jiným jazykem. Když napíšu kernel mode transition, tak mluvím o přechodu do kernel mode (což je překlad slovo od slova), tedy přechod mezi ring 3 a ring 0. Překvapuje mě, že se na to ptáte. A ano, je to drahá operace. "za běhu kódu můžeme utrhnout execution a provést context switch" znamená, že během provádění kódu (ve Windows možno za běhu user mode i kernel mode) dojde k interruptu od timeru, scheduler (plánovač) vyhodnotí, který thread poběží dále, provede obnovení jeho kontextu, a předá mu řízení (aka context switch).

Bez reentrance není multitasking? Mám za to, že třeba u Win16 nebylo reentrantní skoro nic. Souhlasím ale, že SMP by bez reentrance bylo velmi neefektivní (byť ho provést lze).

Ano, jádro musí
(i) statická data. Nicméně kde to jde, je lépe použít data lokální. A jak píšu, je to třeba dělat od začátku. Dále dopisovat cokoliv (v našem případě ochranu statických dat) do pár milionů řádek kódu je veliký problém, zvláště když každé opomenutí znamená riziko havárie kernelu.

Ohledně jazyků nesouhlasím. Skoro všechny problémy se spolehlivostí a (ne)bezpečností dnešního IT světa spočívají v tom, že je stávající kód napsán v C/C++. Programátoři chyby dělali, dělají, a dělat budou (je to jejich vlastnost, nedá se tomu zabránit). Pokud je složitost systémů "dostatečně" vysoká, nezbývá, než začít to dělat tak, aby se některé věci pokazit prostě nemohly.

No, protože ani nevím, jestli té době odpovíte, tak to snad stačilo ;)

0) Vytykat nekomu tykani na webovych diskusnich forech je asi nejaka nova moda. Tohle je uz druhy pripad v poslednich par dnech tady na rootu :-)

1)Staticky rozhodnout, zda v programu nedojde k buffer overflow (napr. indexaci mimo rozsah pole) nebo k deadlocku je algoritmicky nerozhodnutelne, takze v plne obecnosti to asi nikdy nepujde, castecne zaruky (za urcitych podminek bude mozne prokazat, ze k tomu nedojde) je delat i pro C. Dynamicke kontroly je mozne vicemene delat i v C, akorat se to moc nepouziva.

2) Wine je (nekompletni) reimplementace Windowsich API, nikoliv emulace (alespon ne emulace v obvyklem slova smyslu).

3) Pokud mas uniprocesor a vypnutou kernelovou preempci, tak mas podstatne mensi sanci na race conditions v kernelu. Tudiz pokud neni potreba, tak je lepsi ji nepouzivat. Myslis, ze vsechny hardwarove drivery pro Windows jsou proste race-condition bugu? Mozna, ze kdyby sla ve Windows kernelova preempce vypnout, tak by byly stabilnejsi.

E) Prvni z techto veci AFAIK vicemene ma. Viz ionice.

0) Inet je komunikace jako každá jiná. Vykání k tomu patří stejně, jako v běžném životě. Pryč jsou doby FIDO a začátků inetu. I email se dnes považuje za skoro rovnocenný klasickému dopisu.

1) Ano, některé věci se staticky rozhodnout nedají. Tam se to řeší dynamicko kontrolou. Nemusí se ověřovat vše vždy před přístupem. Například u for cyklu stačí dynamicky zkontrolovat, zda nedojde k indexaci mimo rozsah pole, a pokud zjevně nedojde, tak nechat cyklus proběhnout. To je ovšem řešeno již na úrovni kompilátoru MSIL do native code.

2) Ano, technicky máte pravdu.

3) Je dobré psát kernel tak, aby race conditions neměl. Windows jsou stabilní s preemptivním kernelem. Chápu, že když se tento problém neřeší při návrhu, ale později ad hoc, tak jsou výsledky řekněme rozpačité. To je holt specifikum vzniku Linuxu. HW drivery by měly být v pohodě, minimálně ty certifikované (na server snad nikdo jiné nedá). MS nabízí i nástroje pro statickou analýzu kódu driveru (PREfast, Static Driver Verifier).

E) To jsem nevěděl, Linux až tak nesleduji. O ionice jsem toho moc nezjistil. Zato o Windows jsem zjistil, že priorita I/O propadá až na drivery, a u nové verze NCQ se bude na prioritu brát ohled (bude součástí requestu). Dále ve Windows máme aplikační API, které umožňuje nastavit I/O priority na úrovni procesu (SetPriorityClass), treadu (SetThreadPriority) i konkrétního file handle (SetFileInformationByHandle). Když systém swapuje, umí odlišit prioritu požadavku (při nedostatku paměti zřejmě high). Utility dodávané se systémem podporují prioritu I/O, například defragmenter. Jak je na tom ionice?

1) Je v tomhle nejaky rozdil mezi C a 'managed jazycich', jako treba Java? Hypoteticky by JIT mohl vyuzivat nejake run-time informace pro rozlicne kompilace, ale dost pochybuji, ze se to nekde vyuziva.

3) Problemy obvykle nejsou v navrhu (a to ani v Linuxu), jako spis v chybach pri implementaci a to zejmena u HW driveru (ktere casto pisi mene zkuseni lide nez ti, kteri pisi core subsystemu). A race conditions jsou z tohodle hlediska zaludnejsi nez ostatni chyby.

E) Problematiku ionice take moc nesleduji. Vim akorat o moznosti nastaveni priorit pro cele procesy a podle ruznych zminek to je zrejme podporovano jen pro cteni (coz by byl citelny nedostatek). Zrejme v teto oblasti je treba na Linuxu jeste zapracovat.

1) Pokud jsem si všimnul, tak C toho moc neověřuje. Pokud použiji index za hranicí pole (což není technicky přesné, ve skutečnosti jde spíše o pointerovou aritmetiku), prostě zapíšu do paměti, kam nemám. Přesně tenhle typ chyb (plus strcpy) může za velké procento problémů dnešního světa IT, a přechod na managed jazyky dost pomůže.

3) Ověřit třeba návrh network stacku, nebo alokátoru u FS, jestli neobsahuje deadlock, je velmi záslužné. Samozřejmě drivery dnes píše každý idiot, a podle toho to vypadá :(. Ale jak jsem psal v jiném příspěvku, MS dodává nástroje pro statickou analýzu kódu driveru, plus Driver Verifier pro "škádlení" driveru za běhu (dynamická analýza).

E) Děkuji za informaci.

1) Pokud jsem si všimnul, tak C toho moc neověřuje. Pokud použiji index za hranicí pole (což není technicky přesné, ve skutečnosti jde spíše o pointerovou aritmetiku), prostě zapíšu do paměti, kam nemám. Přesně tenhle typ chyb (plus strcpy) může za velké procento problémů dnešního světa IT, a přechod na managed jazyky dost pomůže.

C je jazyk - zadny jazyk samozrejme nic neoveruje. Ale konkretni kompilatory a interpreti jiz overovat mohou. Je pravda, ze pointerova aritmetika to trochu komplikuje, ale az na nejaky obskurni kod by snad nemel byt problem pridat mechanismy pro dynamicke kontroly do kompilatoru C.

Bohužel u stávajícího kódu by přidání jakýchkoliv kontrol znamenalo nutnost toho hromady přepsat, a ještě by spousta věcí unikla. Je to právě z důvodu pointerové aritmetiky a podobných věcí. Jak jsem psal, pokud někdo ad absurdum přetypuje pointer na string na integer, a bude s ním dál něco dělat, tak už nikdo nikdy nic nezajistí.

Jenže přesně tenhle problém způsobil, že Pascal se nikdy neprosadil před C. Omezování programátora zkušeného programátora akorát štve.

0, Tykanie je sucastou netikety uz dobrych 30 rokov. Vzdy sa povazovalo za normalne v elektronickej komunikacii.


Vykanie je samo osebe degenerovany aristokraticky prezitok. Najprv onikanie, potom vykanie. Len aby sa veci nepomenovali pravym menom.

"Racili by sa (oni) pozriet von oknom?" -v podstate hovorim o niekom, kto mozno nie je ani v tejto miestnosti.
"Mohli by ste sa pozriet von oknom?" -ked to hovorim konkretnej osobe, zase len zahmlievam a rozptylujem. Aby nahodou nemal niekto pocit, ze KONKRETNE OD NEHO nieco chcem.


Aristokrati boli tak precitliveli na svoje ego, ze priamo ho oslovit s nejakou otazkou alebo poziadavkou, JEHO AKO OSOBU, to by asi nerozchodil. Ako moze obycajna spodina vstupit do komunikacie s jeho osvietenou vysostou?
Kedze nejakej komunikacii so spodinou sa zial zrejme vyhnut nedalo (so sluhami atd), tak sa to aspon zahmlievalo a rozptylovalo, aby sa chudacik modrokrvnik necitil dotknuty. Takze namiesto konkretnej OSOBY (TY, clovek) hovorime akoby o nejakej uplne vzdialenej SKUPINE osob niekde vonku v zahrade (ONI) na co sa uz nikto neurazi lebo vlastne o nikom konkretnom nie je rec. Alebo hovorime aspon k nejakej neurcitej pritomnej SKUPINE osob (VY), cim sa vlastne takisto nikoho konkretneho nedotkneme.

trefne!

+1

Ale holt mame co do cineni s kravatakem, kterej je na to hrdej a vyzaduje vykani, kam linuxova fora klesla, ach, za chvili to tu bude samy managor, tfuj

trefne!

+1

Ale holt mame co do cineni s kravatakem, kterej je na to hrdej a vyzaduje vykani, kam linuxova fora klesla, ach, za chvili to tu bude samy managor, tfuj

Holt wokenicarovi kravataci nesnasi tykani :D

Obludy chodící ve vytahaném tričku a otrhaných džínách zase píšou "iteligentní" příspěvky do diskuzí, viz Dnes 12:25 ;). Kravata je věc vkusu, a na dobrý oblek jsem vždy hrdý.

Jo ty taky nemam rad, pokud jde o me, rad si vybiram obleceni dusledne a velmi mi na nem zalezi, proto take ten duvod proc nechodim s bilym limeckem a sibenici jako stadecko poslusnych marketingovych vypatlanych ovecek moderniho prumyslu :-)

A mas taky ty ruzovy kosile ktery jsou ted dnes moderni a vzdycky me v mhd rozesmeji ? :-)

Jo ty taky nemam rad, pokud jde o me, rad si vybiram obleceni dusledne a velmi mi na nem zalezi, proto take ten duvod proc nechodim s bilym limeckem a sibenici jako stadecko poslusnych marketingovych vypatlanych ovecek moderniho prumyslu :-)

A mas taky ty ruzovy kosile ktery jsou ted dnes moderni a vzdycky me v mhd rozesmeji ? :-)

mh-jakže? A růžová???

LO, ty jsi taková hnusná blafující svině, že si říkám, jestli nejseš pan Havelka z A21.
To je taky totální nekompetentní idiot, který slouží jen k tomu, aby mátl lidi a budil dojem kompetentnosti.

Lidi jako ty je nutno ignorovat, ne se s nima bavit. Protože když se s tebou někdo baví, tak se jen učíš lépe lhát a budit dojem.

Ano, pane kolego, také vás mám rád. Těším se, až se v nějaké české firmě setkáme, budeme si vykat, a spolupracovat spolu. Jinak jste předvedl skvělé argumenty, gratuluji ;)

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Singularity singularity singularity
Dyvelopers dyvelopers dyvelopers

Nemohu se ubranit dojmu, ze vsechny tve prispevky do teto diskuse byly daleko mene prinosne, nez prispevky uzivatele 'LO'.

Vnitrni psychologicky zamer manifestovat absenci rady kvalitnich nazoru a pri teto cinnosti tez demonstrovat spekulativni a casto modifikovany vliv prispevku bez hlubsiho smyslu a jejich vlivu na okoli ci prime ovlivneni diskutujicich.

Neboli cesky, obcas prilit olej do ohne :-)

Když s panem LO diskutujete, jen zlepšujete jeho blaférské schopnosti.

Nedělejte to. Čím víc bude ten člověk (a lidé jemu podobní) otrkanější z diskusí, tím bude IT větší peklo.

Když není problém efektivity Linux kernelu se zapnutou preempcí ve statických strukturách, tak kde tedy? Píšete, že tomu vůbec nerozumím. To je sice roztomilé, ale bylo by lepší, kdybyste problematiku vysvětlil.

"Výmysly" u forku: co je špatně, a jak to podle vás je? K rozdílu mezi vytváření vlákna a procesu: pokud máte server, který obsluhuje requesty, tak jich budete chtít obsluhovat více najednou. Nejprve se zpracovával pouze jeden požadavek, později se přišlo s worker procesy, a nevyšším stupněm vývoje jsou zatím thready. Mají totiž nejnižší režii. Přepínání kontextů: co je konkrétně špatně? Přepnutí kontextu procesu a vlákna možná trvá stejně dlouho na Linuxu (do jeho vnitřností tolik nevidím), ale ne tak v jiných systémech. Kontext switch mezi procesy opravdu znamená nutnost natáhnout memory map procesu (page-mapping table). Nevidím důvod, proč byste totéž dělal při změně kontextu mezi thready, které v rámci procesu memory map sdílí. Dále k forku: bohužel forkované procesy spolu "mluví" jen přes IPC, což je opět overhead navíc. Jestli měl Multics thready, to nevím, ale řada systémů (včetně VMS, Windows, Solarisu a Windows) má jejich implementaci dost kvalitní. Nakonec thready se prosazují i na Linuxu, jenom to dlouho trvalo (viz katastrofa jménem Linuxthreads).