Názory k článku
Edge bude ve Windows 10 virtualizováno kvůli bezpečnosti
-
Lael Ophir (neregistrovaný)
Někde jsem četl i o edicích Pro a Edu, uvidíme. Přínosné to bude, protože když si zaměstnanec na poči přečte zprávy nebo bude čumět na porno, tak to půjde přes virtualizovaný browser, jehož stav se po zavření smázne. Tím se opravdu minimalizuje možnost nákazy. V GPO pak bude seznam serverů, pro které se virtualizace neprovádí, například *.intranet.local.
-
Ondra Satai NekolaZlatý podporovatelDalsi pokus MS zavest privatni API, ke kteremu neda nikomu pristup?
-
Ondra Satai NekolaZlatý podporovatel
Mas vic moznosti, jak neceho podobneho dosahnout
- MAC
- firejail
- spoustet browser pod jinym uzivaelem (a idealne i pod jinym X serverem) -
Lael Ophir (neregistrovaný)
Edge již nyní používá tzv. sandboxing jako například Chrome - je to trochu jinak. Chrome používá sandboxing, tak jako MSIE a později Edge. Sandboxing v MSIE je starší než celý Chrome browser.
https://blogs.msdn.microsoft.com/ie/2006/02/09/protected-mode-in-vista-ie7/ -
Lael Ophir (neregistrovaný)
Pokud máte na mysli řešeto, tak největší řešeto na trhu je za rok 2015 Google Chrome. Data od Secunia:
Google Chrome 516 zranitelností, Mozilla Firefox 254 zranitelností, MSIE 197 zranitelností.
Zdroj: strana 20 tohoto reportu
http://resources.flexerasoftware.com/web/pdf/Research-SVM-Vulnerability-Review-2016.pdf -
Jenže to je úplně špatně pochopeno. MSIE nemá otevřené zdrojáky, a proto se v něm chyby hůře hledají, ale zato lépe prodávají a ještě lépe se tutlají. A v Chrome za najití chyby dostanene i zaplaceno, takže je velká motivace hledat a hledat. Výsledkem bude lepší kód, což je důležité (a nikoliv počet chyb). Navíc Microsoft už dlouho chyby "sdružuje" a ani o nich podrobně neinformuje. Nalezené problémy bagatelizuje, odkládá záplaty (aby měl "lepší čísla", o kterých mluvíte) nebo uměle snižuje nebezpečnost problému (např. tím, že "vlastnost není implicitně zapnutá"). Atd...
-
Lael Ophir (neregistrovaný)
Aha. Takže když má MSIE víc bugů než třeba Firefox (který tehdy používalo minimum uživatelů), tak je to tím, že open source je kvalitnější. Když má víc bugů Firefox a Chrome než MSIE, tak je to protože se v open source lépe hledají bugy. A vůbec vám nepřijde, že si lžete do kapsy? ;)
FYI na hledání chyb nepotřebujete zdrojáky, v praxi zneužívané zranitelnosti se poměrně rychle dostanou do hledáčku antivirových společností, a i MS má bounty programy. Čísla mluví o počtu zranitelností a nikoliv patchů, MS pokud vím patche dále popisuje, a statistika vypadala velmi podobně i za rok 2014. Chrome a Firefox jsou dnes stejnou bezpečnostní katastrofou, jako MSIE někdy ve verzi 6.
Za mě osobně jsou (všechny hlavní) browsery ukázkovou příšerností, protože interpretují pár set HTML tagů, ale už dlouhá léta mají stovky zranitelností ročně. Osobně bych byl daleko víc vděčný za snížení počtu těch zranitelností. Ale ne, vývoj musí jít dál. Takže místo toho aby se opravovaly chyby, tak se implementují ještě rozepsané drafty různých částí HTML5, a u toho se zavádějí stovky dalších chyb. Místo browseru s menším počtem chyb teď můžeme z webové aplikace používat webcam a mikrofon (haló, Velký Bratr?), a brzo budou prý web apps umět ovládat BT zařízení. Wow! :/
-
Víc očí víc vidí: https://cs.wikipedia.org/wiki/Linus%C5%AFv_z%C3%A1kon
OSS projekt, o který je zájem, má kód řádově kvalitnější, než uzavřený kód, což v případě Chrome/Chromium platí. Příslušné studie si najděte.
BTW: pokud máte (komerční) automat na kontrolu kódu, je pro něho nejlepší reklamou, když najde chyby v nějakém známém OSS projektu. -
Lael Ophir (neregistrovaný)
Ad Víc očí víc vidí - to je oblíbený mýtus. K tomu aby ty oči viděly, musely by se dívat. A to se neděje. Navíc s počtem očí se počet nalezených bugů nijak zvlášť nezvyšuje. Fallacy 8: "Given enough eyeballs, all bugs are shallow."
http://ff.tu-sofia.bg/~bogi/France/SoftEng/books/Addison%20Wesley%20-%20Robert%20L%20Glass%20-%20Facts%20and%20Fallacies%20of%20Software%20Engineering.pdf strana 140Mimochodem kdybyste měl pravdu, tak by těžko docházelo k problémům typu Heartbleed, "Debian OpenSSL Security Snafu" atd.
Ad pokud máte (komerční) automat na kontrolu kódu, je pro něho nejlepší reklamou, když najde chyby v nějakém známém OSS projektu - to bude asi tím, že uzavřený kód k analýze nezískáte, a když ano, tak s NDA :)
Ad Příslušné studie si najděte - důkazní tíže je na vaší straně. Minimálně počty bugů v Google Chrome a Firefoxu nevypovídají o tom, že by byl kód nějak kvalitnější.
-
Filip JirsákStříbrný podporovatelExistence konkrétních chyb nic nedokazuje. Pouze to vyvrací případné tvrzení, že dotyčná metoda vývoje software vede k absolutně bezchybnému kódu – což ale nikdo netvrdí. Aby oči viděli, musí se dívat, je sice pravdivé, nicméně v případě opensource to pořád znamená alespoň to, že se dívat mohou – a že tedy opensource nebude horší a průměrně bude lepšá, než closedsource. Protože základ je v obou případech stejný, a v případě opensource se aspoň občas někdo podívá. Leda že byste dokázal, že na closed source se dívá víc očí, což by byl pozoruhodný fyzikální úkaz.
Nevím, odkud máte informace o počtu chyb v Chrome nebo Firefoxu. Já dokážu zjistit počet opravených chyb a počet nahlášených chyb. V případě Internet Exploreru nebo Edge známe akorát počet přiznaných chyb. Jak z toho chcete porovnávat, který kód je kvalitnější?
-
NULL (neregistrovaný)
@ Lael
"důkazní tíže je na vaší straně. Minimálně počty bugů v Google Chrome a Firefoxu nevypovídají o tom, že by byl kód nějak kvalitnější."
Zas to tvoje nepochopení statistik?
Počet bugů vypovídá tak akorát o počtu bugů. Vůbec se nevztahuje na to, jak je SW kvalitní nebo jak aktivně se na něm pracuje. A počet opravených bugů se vztahuje k počtu opravených bugů a k ničemu jinému.
Dokažme si to:
Mám 1k řádků kódu a tam 1 bug v macrech už 15 let nahlášený umožňující třeba eskalaci práv (based on true MS story) a třeba 10 bugů v nějakém zobrazení.
vs.
Mám 1M řádků kódu a tam 400 bugů a 2 z nich umožňují eskalaci práv.Má otázka: Opravdu počet bugů vypovídá o nějaké kvalitě?
Ale aby ses zase nenechal mýlit, kvalita kódu je komplexní téma, kde nejsou jenom chyby, ale také čitelnost, rychlost, testovatelnost, případně přenositelnost ale také nějaká účelnost a určitě to není všechno . . .
"Mimochodem kdybyste měl pravdu, tak by těžko docházelo k problémům typu Heartbleed, "Debian OpenSSL Security Snafu" atd."
Prosim tě " typu Heartbleed, "Debian OpenSSL Security Snafu" atd."" jsou celkem dost specializované věci a zde to ani tak platit nemůže už z principu. Jenže zde, už víme, že byly odhaleny, přiznány a ihned opraveny. Kdy naposledy třeba MS nechal otestovat své implementace, a pokud se nepletu tak vychází z těch samých knihoven SSL, někým jiným než svým týmem - napíšu omezeným, ale ve smyslu počtu a tedy i variací zkušeností?
Celkově ale ten princip OSS nechápeš. Nikdo snad netvrdí že je to něco samospásného, ale rozhodně jsou na tom takové kódy lépe. Nejenom co do počtu kontroly, ale také co do použití pro vývojáře kteří na to navazují. Dále pak může víc lidí přispět a tím i zlepšit nebo rozšířit funkcionalitu podle toho co jim vyhovuje a případně se to dá přidat pro všechny. Není totiž nic lepšího, než třeba vytvářet komunikaci s binárkou ke které není dokumentace nebo není dokumentace udržovaná a ta pak začne někde bugovat. U OSS se "lehce" podívám. Dovedeš si představit, že by třeba MS měl dělat Arduino a sám vyvýjet všechny knihovny a pak to mít "zdarma" aby podpořil prodej desek - licenci neřeš ( OSS je o přístupu ke kódu, ne o konečné licenci), jenom ten masivní záběr vývoje ke věcem, které jsou OSS, když najednou začne posílat třeba 50k lidí z celého světa oproti dvěma kanclům vývojářů closed source?
-
Lael Ophir (neregistrovaný)
Ad Počet bugů vypovídá tak akorát o počtu bugů. Vůbec se nevztahuje na to, jak je SW kvalitní - takže bugy podle vás nejsou relevantní z hlediska kvality kódu? Co je tedy podle vás kvalitou kódu? (vizte též níže)
Ad Má otázka: Opravdu počet bugů vypovídá o nějaké kvalitě? - pokud mám čtečku HTML, která má na práci interpretovat pár set bugů, a má stovky bezpečnostních bugů ročně (opakovaně po více let), tak to opravdu o kvalitě kódu neříká nic dobrého.
Ad nejsou jenom chyby, ale také čitelnost, rychlost, testovatelnost, případně přenositelnost ale také nějaká účelnost a určitě to není všechno - OK, tím odpovídáte na mou první otázku. Za mě jsou zranitelnosti v kódu pro jeho kvalitu výrazně důležitější, než cokoliv jiného. Zvlášť u kódu, který běží na stovkách milionů instalací. Navíc například čitelnost těžko hodnotit objektivně, a velmi těžko pokud zdroják nemáte k dispozici :). A například přenositelnost v řadě případů není vůbec relevantní.
Ad " typu Heartbleed, "Debian OpenSSL Security Snafu" atd."" jsou celkem dost specializované věci a zde to ani tak platit nemůže už z principu - ano, protože těch mnoho očí ve skutečnosti zdrojáky nečte a neanalyzuje.
Ad už víme, že byly odhaleny, přiznány a ihned opraveny - tyhle (a další) závažné byly odhaleny po dlouhých letech, kdy "mnoho očí" mělo podle teorie kontrolovat zdrojáky. Zjevně to nefunguje, což sám přiznáváte.Ad Kdy naposledy třeba MS nechal otestovat své implementace... někým jiným než svým týmem - a co je špatného na interním code review? MS má 114000 zaměstnanců, takže nevidím důvod, aby si najímal na audit kódu externí společnosti (počet odhalených chyb s větším počtem reviewerů nijak výrazně neroste). Osobně bych se obával spíš open source projektů, které mají pár core developerů, a hromadu přispěvatelů, kteří sice kód pořádně neznají, ale občas pošlou pár řádek kódu. A dál bych se velmi obával toho, že kdokoliv může zanést do open source projektu bezpečnostní problém záměrně. Autor toho kódu může mít čistě virtuální identitu, open source komunita lidi nijak neověřuje. Stačí mu párkrát přispět kusem kódu, tím získat trochu důvěry, a zavést "drobnou chybu" z kategorie "honest mistake". Zrovna vy rád věříte dost divokým teoriím. Jak divoká vám přijde myšlenka, že někdo zavede do open source projektu něco typu "Debian OpenSSL Security Snafu"? Stačí jeden "drobný omyl", Cčko je dost kryptický jazyk. Na www.ioccc.org je dokonce soutěž v tvorbě zdánlivě neškodného kódu, který zavádí skryté chování.
Ad pokud se nepletu tak vychází z těch samých knihoven SSL - ne, MS nevychází z OpenSSL.
Ad ale ten princip OSS nechápeš - ale chápu
Ad rozhodně jsou na tom takové kódy lépe. Nejenom co do počtu kontroly - tady nesouhlasím, protože neexistuje žádný relevantní zdroj, který by takové tvrzení dokázal.
Ad co do použití pro vývojáře kteří na to navazují - tady souhlas. Když mám zdroják, můžu v něm udělat změny. Jenže když udělám změny, nikdo mi nezaručí jejich integraci o upstreamu, a provádět vlastní dokumentaci, testování a hlavně údržbu těch změn je veliká spousta práce. Dále pokud je kód pod licencí typu GPL, tak to znamená, že když se takového kódu dotknu byť jen klackem, tak musím uvolnit zdrojáky vlastní aplikace. A to je z hlediska businessu mimořádně špatné. Proti použití open source například s BSD licencí nemám vůbec nic, pokud je kvalitní. Ovšem upozorňuji že když potřebuji řekněme knihovnu pro rozeznávání barcodů, tak určitě nebudu používat nějakou která je mizerná a nefunguje, jen protože je k ní zdroják.Ad vytvářet komunikaci s binárkou ke které není dokumentace nebo není dokumentace udržovaná a ta pak začne někde bugovat. U OSS se "lehce" podívám - tady pozor. Pokud se "lehce" podíváte, tak spoléháte na konkrétní zdroják. Jenže ten zítra může vypadat úplně jinak. Garantované je to co je v dokumentaci. Konkrétní (a častý) příklad: vývojář se koukne, kde shell skladuje ikony. Najde je jako resources v knihovně X, takže je odtamtud začne tahat. V příští verzi Windows se ikony shellu změní, a jeho aplikace padá při dotahování resources. Je to triviální příklad, ale demonstruje, že se nikdy nesmí spoléhat na nedokumentované vlasnosti.
Ad Dovedeš si představit, že by třeba MS měl dělat Arduino - MS nabízí například .NET Gadgeteer. Nemáte zdroják k OS, ale to není důvod aby nemohli lidé napsat hromadu knihoven. Nakonec desktopové Windows také nejsou open source, a koukněte se, kolik aplikací pro ně existuje. Nepíše je 50k lidí, ale miliony lidí. Někteří píšou pro Windows open source, jiní freeware, další placené aplikace. Klíčem je oddělit platformu a vývoj nad ní, což se dávno dělá i ve světě open source.
-
nobody (neregistrovaný)
nevazenej a nemilej sasku vyslanej z PR oddeleni Microsoftu...
opensource prohlizec = otevrene priznani vsech chyb, hledat je muze kdokoliv z nekolika miliard
closedsource prohlizec = priznane chyby jsou jen zlomek tech nalezenych, navic se cumulujou pod dalsi, aby to vypadalo ze je jich mene... dale ten prohlizec obsahuje chyby na ktere zamestnanci Microsoftu neprisli, a bez dostupneho zdrojaku jde stale jen o 114000 paru oci (kde jsou PR sasci, uklizecky, manageri a dalsi ktere na tom nic nevidej), pokud by byl otevren tech chyb by take mohlo hledat nekolik miliard paru oci navic....
-
Lael Ophir (neregistrovaný)
Žijte ve svých iluzích, jestli vám to vyhovuje. Google Chrome je sice děravý jako řešeto, ale určitě v něm miliardy uživatelů hledají bugy dnem i nocí :D. BTW ty počty chyb jsou od třetích stran, ne od MS.
Jak jsem už psal, když měl MSIE hromadu bugů a Firefox velmi málo, tak to podle vámi podobných bylo proto, že je Firefox coby open source skoro bezchybný. Když má MSIE pár chyb a Google Chrome i Firefox jich mají hromady, tak je to proto, že v open source se chyby lépe hledají a opravují. Jinými slovy na faktech nezáleží, vy si vždy odůvodníte svoje. A s tím souvisí i další odstavec.
Ad nevazenej a nemilej sasku - všiml jste si, že místo mozku máte chrastítko ve tvaru Tuxe?
-
NULL (neregistrovaný)
Ani bych neřekl. Odkazovaný článek se netýká ani tak IE, ale maximálně tak IE ve W Vista. Nepamatuji si, že Chrome by mělo sandbox jenom pro pár verzí OS z 20.
Celkově z toho, jak jsem to proletěl to ani tak není sandbox v IE ( jak to srovnáváš s Chrome ) ale doplněk IE7 ve Vistách a hlavní featury jsou ve W Vista, které manipulují s IE, který o tom nai nemá páru. Ano, ten maník je z teamu MS IE ale mluví o tom jak systém zabezpečuje IE, ne o tom jak má IE sandbox."Defense in depth is a security principle that a system should provide multiple layers of defense, in case one layer is ever breached. Protected Mode takes advantage of three key new technologies in Vista’s security model: "
O tom je ten článek a ne o sandboxingu jak tu lžeš. Žádný sandboxing, ale testovací běh a ten ještě ke všemu zajišťuje systém, ne browser - jestli si takový název IE vůbec zaslouží.
-
Lael Ophir (neregistrovaný)
Sandboxing pochopitelně funguje tak, že OS ořeže přístup aplikace ke zbytku systému. A pochopitelně se používají mechanismy, které dává k dispozici OS. V tomto scénáři MIC a UIPI.
Ad Nepamatuji si, že Chrome by mělo sandbox jenom pro pár verzí OS z 20 - pokud jsem si všiml, svého času měl Chrome sandbox jen pro Windows. Ale můžu se mýlit. Ostatní OS tolik nesleduji, a Chrome ani většinu dalších produktů společnosti Google nepoužívám. Nicméně na Windows používá Chrome ty samé techniky, jako MSIE. Konkrétně se koukněte na MIC a SetProcessMitigationPolicy.
https://www.chromium.org/developers/design-documents/sandboxAd O tom je ten článek a ne o sandboxingu jak tu lžeš - napsal bych že lžete vy, ale je možné, že jen nevíte o čem mluvíte.
Ad testovací běh - ehm, to má být konkrétně co?
-
NULL (neregistrovaný)
Článek mluví o tom, že oddělí proces IE ve Vistách a "pokud se nic neposere", tak ho pustí normálně. To je ten testovací běh a to je to, čemu ty říkáš sandbox. Takže v 1. případě si laskavě přečti co jsi linkoval a b druhém si zjisti, co je to sandbox a proč to widle dodnes neumí bez externího programu.
-
Lael Ophir (neregistrovaný)
Tipnu si že je marné vám to vysvětlovat, ale jsem ochotný to zkusit. Pokud jste si MIC a UIPI přebral jako oddělí proces IE ve Vistách a "pokud se nic neposere", tak ho pustí normálně, tak jste si to přebral fakt dost špatně.
Windows mají mechanismus zvaný Mandatory Integrity Control, což je MS implementace mechanismu Mandatory Access Control. By default může proces běžet s integrity level (IL) úrovně Low, Medium, High nebo System. Procesy s nižším IL například nemůžou posílat window messages (řekněme X11 events) procesům s vyšším IL (což je podstata User Interface Privilege Isolation, mimochodem vlastnost kterou X11 dodnes nemá), nemůžou ani číst informace z procesů s vyšším IL atd. Proces běžící s low IL mimo jiné nemá přístup k většině FS a Registry.
V případě MSIE samozřejmě nelze celý proces jednoduše spustit s low IL. Od browseru totiž například očekáváte, že bude umět uložit soubor kamkoliv na disk. Na druhé straně chcete zabránit tomu, aby proces ve kterém běží layout engine při nějakém nabourání mohl hrabat někam na disk. To se řeší tak, že část browseru běží s low IL. Jde o část která se stará o parsování HTML, vykreslování atd. Další část běží s medium IL (tj. jako běžný proces). Když ta část běžící v low IL potřebuje například uložit soubor, požádá o to pomocí nějaké formy IPC tu část běžící s normal IL.
Jak jsem od začátku psal, tenhle mechanismus je použitý v MSIE od verze 7, která vyšla tuším dva roky před první verzí Chrome. Chrome používá stejný mechanismus. Resp. ono je těch použitých mechanismů víc, ale to co jsem popsal je zjednodušený základ. Asi se s tím spokojíme, a nebudeme tu z toho dělat kurz technik Win32 sandboxingu :)
-
Na GNU/Linuxu se udělá jedoduše fork a nebo clone, oddělí se adresní prostor a sníží oprávnění a i v této konfiguraci není problém zajistit předávání dat a synchronizovat procesy třeba přes futex.
Jak jste mi posledně vysvětlil, tak požadavek na kvalitní synchronizační mechanizmy bez overheadu mezi procesy ve Windows není potřeba, protože používání procesů v rámci jedné aplikace je technologie ubohých Unixů, která se používala jen proto, že byly 100 let za opicemi a moderní architektura Windows se tím zabývat nemusí, protože předběhla Unix v oblasti vláken o mnoho let.
Tady jsou pak výsledky takových tvrzení a vedení vývoje lidmi, kteří nemají přehled.
Omezující WIN API a právě chybějící fork() je důvod, proč je Cygwin tak komplikovaný a dělají se kvůli jeho emulaci strašlivé věci.
Na druhou stranu souhlasím s tím, že fork() je elegantní řešení pro určité oblasti, ale právě jeho jednoduchost a síla dlouhou dobu byla překážkou optimalizovat spouštění nového procesu s nezávislým kódem a původní jednoduše vypadající řešení typu vfork() žádné štěstí nepřinesla. Ale POSIX zavedl posix_spawn() a Linux to i před tím umožňoval na úrovni volání jádra řešit přes clone(). Viz:
http://www.abclinuxu.cz/zpravicky/linux-4.6#15
Naopak Cygwin ukazuje, jaké zásadní limity má WIN API. Je dost možné, že jednoho dne i Microsoft začne své aplikace portovat na WSL API nebo se konečně poučí a WIN API dá do pořádku.
-
Martin Dráb (neregistrovaný)
Minimálně na WIndows XP (= na nich jsem jej zkoušel) bylo možné docílit efektu forku systémovým voláním NtCreateProcess při neuvedení handle (deskriptoru) image nového procesu. Problém samozřejmě leží v tom, že toto volání není zrovna dokumentované a podobně jako se píše v komentáři na abclinuxu, bylo třeba udělat o dost více věcí, než jen zavolat NtCreateProcess, aby vše fungovalo. Navíc je pravděpodobné, že tyto neznámé (ale asi poměrně snadno zjistitelné reverzním inženýrstvím) kroky se trochu měnily s novými verzemi Windows.
Moc nevidím, jak souvisí fork se sandboxingem. Pokud chce proces spustit jiný proces s nižším oprávněním a sdílet s ním nějaké prostředky, tu možnost má. Ale je to pracnější než jedno volání fork.
> Naopak Cygwin ukazuje, jaké zásadní limity má WIN API
Zmiňovaný limit nevidím jako zásadní. Návrháři WIndows zřejmě byli toho názoru, že pokud spouštíme proces, tak bude mít jiný kód a množina sdílených prostředků bude omezená, a tak fork moc nenajde uplatnění.
Ale souhlasím, že jsou věci, které bych přes WIndows API rád udělal a je to trochu problém. Na druhou stranu, když jsem se ptal linuxu znalejších kolegů, zda "linux API" (uvozovky neznamenají urážku) podporuje něco na způsob WaitForMultipleObjects, tak jsem dostal zápornou odpověď.
-
Lael Ophir (neregistrovaný)
Ad Na GNU/Linuxu se udělá jedoduše fork a nebo clone - aha. A tím se vyřeší to aby cílový proces nemohl na FS kam nemá, nemohl posílat X11 events jinému procesu atd.? Ne, nevyřeší. Konkrétní řešení používané Chromem je kombinace user namespaces a seccomp-bpf.
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.mdAd chybějící fork() - fork() je bad practice, protože pro něj potřebujete spoustu paměti. U tradičních Unixů to znamenalo paměťový prostor parenta opravdu zkopírovat. U "nových" implementací se sice používá CoW, ale přesto tu paměť můžete potřebovat. Katastrofa jménem fork() je jedním z důvodů, proč Linux používá ještě větší katastrofy jménem memory overcommitment a OOM Killer.
Ad Cygwin ukazuje, jaké zásadní limity má WIN API - ehm? Windows na rozdíl od Unixů nikdy nepotřebovaly "smrtící" sekvenci fork/exec (kde spuštění 1kB utility z DB enginu s alokovanými 20GB RAM spotřebuje dalších 20GB RAM), a na rozdíl od tradičních Unixů měly od začátku threading, takže potřeba worker procesů byla zcela okrajová. Windows tedy nenabízejí API na něco, co nepotřebují. Samozřejmě je možné fork() emulovat na úrovni kernelu, jak to nakonec dělají Services for UNIX i WSL.
Ad Je dost možné, že jednoho dne i Microsoft začne své aplikace portovat na WSL API - jasně, kvůli volání fork(), které potřebují jen (staré) aplikace psané pro Unixy :)BTW POSIX ani Linux "kupodivu" nemá API ani na management servisů/daemonů, změnu konfigurace síťových interface, přidání uživatele a další zcela základní operace. POSIX spoustu věcí řeší jen utilitami a nikoliv na úrovni API. Utility pak typicky mají nastavený SUID bit a provedou nějakou "magii", která je specifická pro daný Unix (a klidně pro danou verzi), a typicky nedokumentovaná. V případě managementu servisů/daemonů jde na každém Unixu o různá klubka skriptů, na Solarisu je SMF, na některých distrech se prosazuje systemd, pak je tu launchd, Android init, OpenRC... Bohužel je to klasický unixový chaos, kde deset skupin pracuje na tom samém, a ani jedna neudělá nic pořádně. Stejně jako u náhrady X11 něčím rozumným, která je cca 20 let pozadu. Jediné co na Unixech opravdu funguje je to, co bylo implementováno před těmi cca 20 lety a dále. Od té doby jde jen o stagnaci, opisování funkcionality ze starších komerčních implementací do open source, a chaotický vývoj kde nejen že levá ruka neví co dělá pravá, ale ani palec neví co dělá ukazovák.
-
Jenže MIC je ve Windows "broken by design" a taky je to úděsně komplikovaný. Psal o tom Mark Russinovich, než ho Microsoft koupil. A stanovisko Microsoftu je, že to byl záměr :-) BTW: pamatuju dobu, co vyšel Chrome se sandboxem. Tenkrát se otevřeně psalo, že úroveň sandboxování je v Chrome mnohem vyšší a Microsoft se později chlubil tím, jak podle Chrome dále MSIE omezují...
-
Imnafoy (neregistrovaný)
Hmmm... Hyper-V ... Když jsem naposled testoval Hyper-V tak jsem zjistil, že ve Windows (7, 8, 10) když se aktivuje Hyper-V, tak si vyhradí VT-X pouze pro sebe, což by znamenalo, že po aktualizaci Win10 s virtualizovaným Edge už můžeme zahodit virtualbox/vmware/whatever protože v případě 32bitových virtualizovaných mašin se značně sníží výkon bez VT-X a v případě 64bitových máme smůlu úplně... To by mě zajímalo jestli na to někdo u Microsoftu pomyslel.... Ne, vlastně co si nalhávám... proč by měli? :(
-
Filip JirsákStříbrný podporovatel
Edge, Internet Explorer a spousta dalších aplikací používá WinInet a mají tedy společnou konfiguraci sítě. Kterou mimochodem používá i Google Chrome, ale ten předpokládám WinInet nepoužívá. Takže co se týče proxy serveru, umí Edge přesně to samé co Internet Explorer. Je možné, že Edge nemá GUI na nastavení – v takovém případě stačí nastavit si to v Internet Exploreru, Google Chrome nebo Ovládacích panelech Windows, vše je to jedno a totéž nastavení.
