Názory k článku
Pod Windows už lze neoficiálně rozběhnout i Arch Linux
-
rudiik (neregistrovaný)
To nemusi byt az tak pravda. Korporat ma vetsinou dane podporovane/povolene OS a jejich zakladni nastaveni v ramci nejake policy nebo standardu. To ale zdaleka nemusi znamenat, ze nejde nic dalsiho nainstalovat. Pouze mohou existovat blacklistovane aplikace po jejichz instalaci dostane uzivatel pres prsty - typicky P2P veci, IRC, ruzne remote udelatka typy TeamView a podobne.
Osobne taky jedu na W10 s Cygwinem a na tohle se docela tesim, protoze Cygwin obcas ma podivne bugy. -
Lael Ophir (neregistrovaný)
Bohužel linuxové nástroje mají na WSL spoustu omezení. Například ve všech aplikacích vidíte normální cesty, jen v těch pod WSL jsou cesty v unixovém formátu. Zobrazování funguje jen přes X11 server, což je řekněme GUI obdoba děrných štítků. Předpokládám že většina zařízení nejede, protože na Unixech jsou závislé na device files.
Pokud chcete na Windows instalovat open source z repozitáře, stačí nainstalovat Chocolatey, a pak napsat choco install vim git win32-openssh mc, a je hotovo. Pro aktualizaci stačí spustit choco upgrade.
https://chocolatey.org -
Atrament (neregistrovaný)
Kdepak, vyzkoušel jsem Chocolatey, ale to není alternativa k WSL, jde prostě jenom o balíčkovací systém pro Windows a to není to co potřebuju. Na WSL oceňuju, že je to komplet Linuxová příkazová řádka se vším všudy. Nepoužívám přes to žádné aplikace vyžadující Xka, a ani nic co by potřebovalo device files, takže se mně naštěstí žádná omezení které uvádíš netýkají.
-
Andrej Podzimek (neregistrovaný)
Otřesný linuxový desktop mě pobavil. :-D KDE strčí hravě do kapsy všechny Windows, které kdy nabootovaly.
Kdyby o otřesném linuxovém desktopu hovořil nějaký Apple fanatik, asi bych to s pousmáním chápal -- zvykl si na zlatou klec, která jaksi nic neumí a nedělá a tedy nic nezkazí, a použitelný desktop ho děsí. Ale mluvit o údajně otřesném linuxovém desktopu ve srovnání s žumpou zvanou Windows -- to je poněkud ujeté. Pohodlí Windows? :-D Jako fakt vážně?
Inu, dobrý trolling, to se musí nechat. A ano, trolly bych správně neměl krmit.
-
nobody (neregistrovaný)
vstup jen na vlastni nebezpeci ;)
http://1inux.deviantart.com/art/Metro-Interface-for-Linux-342402045
https://www.gnome-look.org/search?projectSearchText=METROlux -
xyz (neregistrovaný)
Ve spoustě firem je heterogení prostředí...
Ale proč bych tam neměl nainstalovat rovnou Linux. Jaké jsou asi výhody Linuxu běžícího ve Win ?
Asi takovéto: systém zabere několikrát více místa, je mnohem náročnější na systémové prostředky, tím pádem méně stabilní, bootování trvá déle, po aktualizacích je vyžadován restart (častější restarty), atd.
Kdo asi na takovémto systému bude rozjíždět firemní aplikace, asi úplný blázen.
-
Z mého pohledu je to záchrana pro mnoho vývojářů. V několika firmách jsem před lety řešil kompilaci GCC a cross toolů pro různé embedded projekty (často ne-Linuxové) a bylo to vždy extrémní množství zbytečně vynaloženého času, pokud jsem to chtěl předvést/udělat tak, aby to mohli reprodukovat. Jednalo se o cílové architektury m68k, PowerPC, ARM.
O řád lepší bylo připravit toolchain pro Cygwin nebo MSys canadian-crossem na Linuxu. Takové Sysgo, pokud vím, a další naivestovali hromadu času do úprav Linuxového jádra a build systému, aby bylo možné embedded řešení vyvíjet na Windows. Potíž totiž je, že v mnoha velkých firmách je tvrdá korporátní politika, která zakazuje vlastní instalaci OS na zaměstnanecké počítače a i pokud je to možné, tak se často bez proprietárních bezpečnostních řešení vůbec nedostanou na síť nebo to řeší připojením pracovních počítačů přes své soukromé mobilní datové služby.
Co sleduji současný trend, tak již velké množství těch firem nabízejících podporu embedded Linux vývoje spíš "nativní" Windows řešení pro extrémní spotřebu času jak u nich tak u zákazníků vzdalo a řeší to (často předinstalovanými) Linuxovými virtuály pod Windows. Ale věřím, že řešení s WSL bude často pohodlnější a třeba se jednou přiblíží život embedded a mobilních vývojářů komfortem a trochu i výkonem práci pod GNU/Linuxem. Na druhou stranu mono specializovaných profesionálních nástrojů pro analýzu komunikací atd. existuje jen pro Windows. Takže někdy i nic jiného něž kombinace obou systémů je nutnost. A nebo si nástroje řešit vlastní cestou.
Například na CAN máme teď díky našim aktivitám a pracem studentů analyzátor, který je v záznamu času příchodu zpráv přesnější a výkonnější než střední až možná i základní vyšší třída nástrojů s Windows only rozhraním. Ale další analýzu záznamu a filtrování si musíme řešit také sami, od jednoduchého grepu v příkazové řádce až po Qt aplikace. Takže pro mnoho firem je klikací Windows řešení rychlejší cesta. Když pak dojde na složitější věci, tak již stejně skriptování a klikání v proprietárním analyzátoru nestačí a je pak celkem jedno, kde se aplikace píše. Na Linuxu je to jednodušší třeba u CANu o to, že existuje jednotné API a není nutné integrovat knihovny několika odlišných dodavatelů CAN HW.
Obecně tedy považuji WSL za velkou pomoc. Zároveň MS motivuje k analýze a poučení se z řešení před mnoha lety vyvinutými pro Linux. Například museli naimplementovat Futex (i když z pohledu RT a robust Futex je to spíš jen parodie) a API přidali i do WIN32. Až časem vymřou starší verze OS a knihovny tak postupně třeba i výkon takové základní funkce jako zamknutí mutexu a čekání na event bude ve Windows na rozumné úrovni. Analýza vývoje čekání na event je ve WIN32 API je mimochodem extrémně zajímavá tím kolik špatných řešení a optimalizací lze vymyslet. Celkem hezký základ z VMS, kvůli nárokům na inicializační syscally přidání lazy init, výsledkem náhodné padání aplikací až za běhu kvůli vyčerpání prostředků, přidání keyed event aby bylo možné napsat frontu pro čekání na uvolnění prostředků, atd atd. a pak přidání Futexu a možnost to řešit bez inicializačních syscallů úplně.
-
Funkce jsou ve WIN APi k dispozici od MSDN Windows 8, Windows Server 2012. Jedná se o WaitOnAddress, WakeByAddressSingle, WakeByAddressAll Windows 8 / 2012 Server. Podle dokumentace není vyřešené/nezmiňuje se priority inheritence, robustness, requeue, ani není jasné, jaké bude chování na sdílené paměti mezi procesy. Ale to poslední předpokládám, že kvůli WSL bude již řešené. Korektní RT priority asi v NT jádře vyřešit nelze, protože chybí základ. Ve WIN CE bylo dědění priorit řešené, jinde jsem to u MS neviděl.
Mnou sesbírané poznatky a zajímavosti k tématu řešení synchronizace/serializace běhu procesů a vláken jsem se snažil mimo jiné předávat studentům v rámci předmětu Opensource programování http://rtime.felk.cvut.cz/osp/.
Odkazy a poznámky viz Slide 14 přednášky se zamyšlením nad škálovatelností software obecně, která předvádí pár zajímavých problémů a řešení na úrovni Linuxového jádra a propojení se userspace.
Vzhledem k tomu, že se minimálně ta více v anketách viditelná část studentů oborů Počítačové inženýrství a Softwarové inženýrství vyjádřila, že považují takováto témata za nehodná času lidí, kteří by měli příští operační systémy navrhovat a implementovat výkonné aplikace a softwarová řešení, tak předmět v budoucích programech není a je velmi nízká pravděpodobnost, že ještě někdy poběží
Náhradou bude předmět Efektivní software, který budou učit kolegové, tak se jim snad bude se studenty vést lépe.
Za sebe uvažuji, nabídnout svůj pohled a zkušenosti s danými oblastmi jako cyklus přednášek pro SUT nebo jinde i mimo mojí domovskou univerzitu, pokud se najdou zájemci, kterým by můj výklad vyhovoval.
-
Lael Ophir (neregistrovaný)
Dokumentace nezmiňuje implementační detaily, které se mohou lišit v dalších verzích, a na které nemáte (a nesmíte) spoléhat.
https://blogs.msdn.microsoft.com/oldnewthing/20160826-00/?p=94185 -
Díky za doplnění odkazu. Myslím, že jsem i původně něco k WaitOnAddress četl z blogu Raymonda Chena, ale tento článek to myslím nebyl. Z popisu implementace mi pak trochu vstávají vlasy na hlavě, protože se tváří nejasně a lze interpretovat i tak, že hash table je v user-space. To pak využití mezi procesy zcela vylučuje. Linux překládá pro sdílené VMA adresu v jádře na "fyzickou" (typu inode + offset) a hashuje až podle této adresy. Takže buzení pak chodí nezávisle na procesu. Pro lokální futexy se řešilo zrychlení nedávno LWN: In pursuit of faster futexes
Co se týče výčtu nedostatků, tak to opravdu není implementační detail. Ne jen implementace mutexů a WaitOnAddress ale celý současný návrh jádra Windows vylučuje jakékoliv uvažování o použití v řídicích aplikacích a kdekoliv, kde na časování záleží. MS sám jasně před chováním/kvalitou svého jádra varuje. The scheduler solves priority Inversion problem by randomly boosting the priority of the ready threads. Přitom návrh Futexu s vyřešením dědění priorit je opravdu ještě o řád vyšší level, než mít ochranu proti inverzi priorit vyřešenou pro WaitForSingleObject, kde (také alespoň podle dokumentace MS) řešená zatím nemůže být a není.
Obecně je zarážející, jak je neuvěřitelně nízká technologická úroveň mnoha řešení ve Windows (při inkasovaných a proinvestovaných částkách). Přitom start z VMS a drivery postavené na IORP byl dobrý. Celkově výsledný stav vyvrací MS i Vámi dříve často opakované teze o tom, že open-source komunita umí akorát kopírovat a vytvářet horší alternativy k řešením, do kterých inovativní firmy musely desetiletí investovat. Ve většině případech to nebyla pravda nikdy a dnes to již potvrzuje i samotný MS tím, že se snaží ke komunitnímu vývoji a modelu připojit. Pro technologický stav celkově nainstalované báze SW a systémů (kde se stále stále se značným zastoupení Windows musí počítat) by bylo velmi dobře, aby se každý vývojář ne jen MS zajímal o to, jak problémy řeší ostatní a v případě open-source je to tak jednoduché, že je ignorování opravdu ostuda.
-
Lael Ophir (neregistrovaný)
Ad To pak využití mezi procesy zcela vylučuje - ano, to je snad zjevné z dokumentace.
Ad Linux překládá pro sdílené VMA adresu v jádře na "fyzickou" (typu inode + offset) a hashuje až podle této adresy - nemá moc smysl si z Win32 API vybrat thread synchronization funkci, a vyčítat jí, že není to interprocess synchronization. Windows mají řadu synchronizačních mechanismů různého určení. Třeba Critical Section Objects, které propadají na kernel space až pokud je třeba. Pak jsou tu (celkem nové) Slim Reader/Writer (SRW) Locks, condition variables, one-time initialization, interlocked variable access atd.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms681924(v=vs.85).aspxAd celý současný návrh jádra Windows vylučuje jakékoliv uvažování o použití v řídicích aplikacích a kdekoliv, kde na časování záleží - Windows NT nejsou RTOS. Ovšem kernel Linuxu se svými gigantickými locky (svého času včetně BKL), overcommittingem a dalšími features na tom také není nic moc. Ve Windows můžete použít například RT extension IntervalZero RTX, nebo jsou tu Windows CE.
Ad neuvěřitelně nízká technologická úroveň mnoha řešení ve Windows - nějaké konkrétní příklady? Zatím jste si akorát vybral jeden synchronizační mechanismus, a srovnáváte ho s úplně jiným mechanismem na Linuxu.
-
Nemyslím si, že implementace kritických sekcí (z pohledu POSIXu mutexů) je jedno okrajové primitivum. Předpokládám, že se shodneme, že v dnešní době je pro využití výkonu nutné implementovat mnoho algoritmů vícevláknově. Zamykání je pak většinou bohužel potřeba (*) a jeho rychlost a spolehlivost je kritická. Z měření a testů různých projektů, které nakonec kvůli uživatelům přidávají port pro Windows vyplývá, že WaitOnAddress má nejmenší overhead. Pro starší verze Windows pak vypadá nadějně NtWaitForKeyedEvent
Proč KeyedEvent existují a obecně implementace kritických sekcí se několikrát zásadním způsobem ve Windows nepovedla si lze přečíst ve zápiscích Windows keyed events, critical sections, and new Vista synchronization features, zde LockLess Keyed Events nebo u Raimonda Chena <a href="">The history of Win32 critical sections so far. Na mě jeho vyjádření "Windows XP solved the problem of the dreaded "out of memory" exception" působí tak, že si je vědom toho, jak se MS sám ve vývoji a údržbě API topí. Přitom KeyedEvents bylo z bláta do louže, z pohledu determinizmu katastrofa, z pohledu složitosti další berlička s mnoha voláními do jádra, která jen zajišťuje to, že původní pomalá volání půjde použít bez padání aplikace
Co se týče Linuxového jádra a RT, tak máte pravdu, že se v jádře nalézají konstrukce, které jsou ošklivé a z pohledu RT katastrofální. Například celý síťový stack, který je optimalizovaný na propustnost, ale struktury SKB se vymkly kontrole. V BSD se mi MBUFy zdají jednodušší a možná jsou i výkonnější. Ale základ jádra je napsaný celkem dobře a po aplikaci RT patchů je možné přes standardní POSIXové API jádra a drivery docílit odezev, které jsou obdivuhodné a na které Widows s nepreemptivním Dispatch Levelem nikdy mít nebude. I na tak slabém HW, jako je Rsapberry Pi 1 je možné docílit i při testování pod maximální a všestrannou zátěží odezev jádra, které za dlouhodobé ověřování nepřekročí 350 usec. Přitom třeba i s regulační smyčkou uzavřenou přes SPI jsme na 1 kHz neměli problémy. V jádře pak zpracování událostí buzenými vlákny zvládalo jakž takž i 20 kHz. To vše bez náhrady HAL alternativním jádrem OS, ještě k tomu uzavřeným, které pouští RT tasky mimo plánovač Windows a vlastně z Windows dělá jen paravirtualizovanou doménu pro nepodstatné úlohy a správu. O možnostech RT v Linuxu jsem takový úvodní článek pro Root před časem napsal GNU/Linux pro řízení a rychlost jeho odezvy. Jinak z toho, co pozoruji ve velkých firmám, tak je až děsivé, kam všude Linux firmy nasazují a jak často neexistují alternativy. Takže jsem letošní léto věnoval pomoci projektu RTEMS https://www.rtems.org/, který takovou alternativou pro určité ohraničené oblasti je. Například je strategickou volbou ESA a NASA pro mnoho vesmírných misí a po mnoho let je v nich již na specifické úkoly nasazovaný.
(*) Co se týče paralelizace, tak kritické sekce jsou obecně problém a Linux již mnoho let používá tam, kde to lze, mechanizmy Read Copy Update (RCU), které přispívají k řádovému zvýšení propustnosti. RCU mechanismus je k dispozici i jako knihovny pro user-space http://liburcu.org/. Dohodlo se již MS s IBM na poskytnutí patentů k této technologii vyvinuté v rámci vývoje jádra Linux tak, aby konečně začalo nabízet tento mechanizmus i v rámci MS WIN a NT API?
Jak je to s tím Futexem na WIndows, chodí alespoň ten ve WSL mezi procesy? Běží v této oblasti nějaký vývoj? Jsou někde pro WS k dispozici výstupy OpenGroup Operating System Tests? Našel jsem akorát výsledky LTP pro WSL (CommandLine-Documentation LTP_Results). Mimochodem, mohu nabídnout maličký ale celkem zajímavý kousek SW k otestování mutexů, conditional variables a semaforů mezi několika procesy. Někdo může vyzkoušet, jak to na WSL bude chodit.
-
Lael Ophir (neregistrovaný)
Ad v dnešní době je pro využití výkonu nutné implementovat mnoho algoritmů vícevláknově - to jistě ano. Proto nechápu, proč řešíte synchronizaci procesů a nikoliv threadů.
Ad Z měření a testů různých projektů, které nakonec kvůli uživatelům přidávají port pro Windows vyplývá, že WaitOnAddress má nejmenší overhead - to mě zajímá. Máte k tomu nějaké zdroje, nejlépe týkající se srovnání výkonu Win32 sync primitiv? Mimochodem uvědomte si ale že každé z těch primitiv má jiné výhody a nevýhody. WaitOnAddress je rychlý, ale má to svou cenu jinde.
Ad NtWaitForKeyedEvent - to je použité mimo jiné v SRW LocksAd implementace kritických sekcí se několikrát zásadním způsobem ve Windows nepovedla - byla poplatná své době. Mimochodem v té době jste ještě na Linuxu neměli ani funkční threading, s tím že LinuxThreads za funkční opravdu nelze považovat. A z toho jak je threading do kernelu dopatlaný asi musí vstávat vlasy hrůzou každému. Nejpřiléhavější popis, který mě napadá, je refactoring kladivem, bruskou a lepicí páskou.
Ad dreaded "out of memory" exception; z pohledu determinizmu katastrofa - a jako alternativu byste doporučil Linux, který "deterministicky" lže o úspěšné alokaci paměti (overcommitting), a když ta lež praskne, tak náhodně odstřeluje procesy (OOM Killer)? Většina OS má problém když dojde na OOM, ale zrovna Linux je na tom velmi špatně.
Ad další berlička s mnoha voláními do jádra, která jen zajišťuje to, že původní pomalá volání půjde použít bez padání aplikace - se kterými mnoha voláními? Sám jste linkoval: CriticalSection API... similar to mutexes on pthreads in Linux, has a fast-path where no transition to kernelspace via a system call is needed. Critical Section Objects se časem zrychlily, ale problém je v tom, že vývojáři hrabali na nedokumentované části struktury. Kvůli tomu nezrychlily tak jak by mohly.Ad základ jádra je napsaný celkem dobře a po aplikaci RT patchů... - které jsou tuším nepodporované... Navíc píšete o 350us. S RTX se na Pentiu dostanete na worst-case 2-30us, podle HW. Plus RTX běží i pokud jádro NT z nějakého důvodu spadne.
Ad RTX... bez náhrady HAL alternativním jádrem OS, ještě k tomu uzavřeným, které pouští RT tasky mimo plánovač Windows a vlastně z Windows dělá jen paravirtualizovanou doménu pro nepodstatné úlohy a správu - RTX HAL nenahrazuje, ale rozšiřuje. Všimněte si, že není potřeba změna jediného řádku zdrojáku NT, ani jeho nový překlad. NT tasky se pak používají pro úlohy, které nejsou časově kritické. Netvrdil bych že jsou "nepodstatné", nebo že jde jen o správu.Ad Linux již mnoho let používá tam, kde to lze, mechanizmy Read Copy Update (RCU), které přispívají k řádovému zvýšení propustnosti. RCU mechanismus je k dispozici i jako knihovny pro user-space http://liburcu.org/. Dohodlo se již MS s IBM na poskytnutí patentů k této technologii vyvinuté v rámci vývoje jádra Linux tak, aby konečně začalo nabízet tento mechanizmus i v rámci MS WIN a NT API? - lock-free synchronization techniques se ve Windows používají dlouho, například ve Vistě se zvyšoval počet míst kde jsou použity. Ohledně API: Win32 nabízí Interlocked Singly Linked Lists, pro C++ je tu Parallel Patterns Library, .NET má Concurrent Collections. O dohodě mezi MS a IBM nevím, ale nevylučuji že existuje.
https://msdn.microsoft.com/en-us/library/ms684121%28VS.85%29.aspx
https://msdn.microsoft.com/en-us/library/dd504870.aspx
https://msdn.microsoft.com/en-us/library/dd460718(v=vs.110).aspxAd s tím Futexem na WIndows, chodí alespoň ten ve WSL mezi procesy - pokud máte na mysli SRW Locks, tak ne. Ve Windows se používá multithreading. Na Unixech sice také zjistili že existují thready, a dokonce konečně existují použitelné implementace i mimo Solaris :), ale autoři kódu to asi ještě nepostřehli.
Ad Běží v této oblasti nějaký vývoj - pochybuji, bylo by to jako vyvíjet podporu děrných štítků. Ale můžete použít events, mutexes, semaphores, timer objects, a samozřejmě Interlocked API.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684122(v=vs.85).aspxMimochodem produktivnější než ptát se mě, který se C/C++ vyhýbá jak může, je obrátit se na dokumentaci nebo knihu Windows Internals. Tohle je šesté vydání, sedmé bude vycházet teď na podzim. Okolo stran 180-210 se řeší synchronizace.
http://materias.fi.uba.ar/7508/WI6/Windows%20Internals%20Part%201%20(6th%20Edition).pdf -
j (neregistrovaný)
Jo, tovizejo ... a presne takhle se to dela ...
Kdyz uz, tak se prekvapive provozuje nejaka virtualizacni platforma ... coz je ... prekvapko ... prakticky za 100% prave tux(vmware nevyjimaje), a na nem se poustej widle. Rozhodne se to nikdy nikde nedela opacne. A viz ty proc? Paac tux narozdil od widli nepada.
-
Lael Ophir (neregistrovaný)
Hm. Mě nefungoval VMware ESXi, protože byly pořád problémy se síťovou konektivitou při zátěži. Ti co vystavují pěkně vysoké faktury s tím také nedokázali nijak pomoc. Od přechodu na Hyper-V nebyl nikdy problém. A to se od té doby řádově zvýšil počet hostů i guestů. Ale jinak to nefunguje a nikdy nebude... konkrétně vám :)
-
j (neregistrovaný)
To je zdejsi M$ maskot lulan, tomu se widle patchujou 3s, a bootujou za 1s. Restart je pak jedinej zpusob jak patchnout opice, a je to zcela vporadku ... ;D
Jestli se chces vazne kralovsky pobavit, tak si pohraj s tim jejich XP modem ... to sou totiz defakto virtualni XPcka, a presne podle toho se to naprosto demente chova, a to co ti nejede jinde v tom stejne nezprovoznis. Napriklad pokud to mas v domene, tak to znamena, ze musis mit v domene i ty XPcka a chova se to jako dalsi PC ... vcetne nutnosti to administrovat ... lol. A samo neustale to pada a pada a pada, takze kdyz si nahodis vmware player, tak to jednak pobezi, druhak to nerezesere materskej system a zatreti to budou realny XPcka, takze na nich pobezi presne to co na XPckach.
BTW: Uz sem mel v ruce asi 50 stroju, ktery byly po instalaci win10 zcela nefunkcni ... protoze nemeli sit. Ti curaci v M$ neumej integrovat drivery ani pro ty nejbeznejsi sitovky na trhu ... ani toho blbyho realteka kterej je vsude to proste nenajde. lol
Nejmin 15 let se mi nestalo, ze by tux nenastartoval a nemel sit. A to vcetne vsemoznych obskurnich kousku HW, u kterych sem ani nedoufal, ze by to mohlo chodit.
-
Lael Ophir (neregistrovaný)
Ad tomu se widle patchujou 3s, a bootujou za 1s - tady si zase někdo vymýšlí
Ad si pohraj s tim jejich XP modem - ten jsem nikdy nepoužíval. Navíc je určený pro Win7, ne Win8/10. To VHDX se dá použít v Hyper-V, a nevidím důvod, aby to padalo jinak nebo víc než ve VMware.
Ad Uz sem mel v ruce asi 50 stroju; curaci v M$ neumej integrovat drivery ani pro ty nejbeznejsi sitovky na trhu - hmm, a co si třeba driver přidat na instalační média? Neumíte? Aha.
Ad Nejmin 15 let se mi nestalo, ze by tux nenastartoval a nemel sit - zato já pravidelně řešil problémy s WiFi, které nikdy nefungovalo jak by mělo. Většinou vůbec, jindy po dlouhém přemlouvání (stahování, kompilace) a s hromadou problémů včetně tuhnutí systému.
-
NULL (neregistrovaný)
@ j
Zrovna včera jsem známé na notebooku s win 10 řešil, že jí nešel zvuk. Na latopu přes fn - zaplý. Na liště ikonka - zaplý, ovladač hlasitosti byl na max, zařízení reproduktor - vybráno. Sranda. Takže vyhledat potíže - ono to občas od win7 pomůže a taky je to jednoduší než hledat na MS nějakou radu typu přeiinstaluj ovladač. No a jak to dopadlo? Dám vyhledat potíže a ejhle: zařízení -> sluchátka. Úplně něco jiného než ukazuje v nastavení. Ok, pár dementních otázek průvodce, ale pomohlo. Po restartu zase nastavené debilně na sluchátka. A víš co je sranda? V tom NTB nikdy sluchátka nebyly - Nikam ho nenosí a sluchátka nemá :-D To je výkon. Člověk by se i zasmál, resp. zasměje, ale jinak je to k pláči. Takové školácké a laciné chyby v OS . . . .
-
Lael Ophir (neregistrovaný)
Buď driver, nebo zdířka sluchátek. Ty zdířky typicky detekují vložení konektoru pomocí spínače. Je to mechanicky titěrné, a často to odchází, takže pak zařízení trvale chybě indikuje, že jsou připojena sluchátka. Ale v mlze je jasně vidět, že to není chyba driveru ani HW, ale OS :D
-
Lael Ophir (neregistrovaný)
Ad konektor odchazi kdyz se casto pouziva, nikoliv kdyz uzivatel nema, nepouziva sluchatka a nikdy je do toho konektoru nezasunul - konektor častěji odchází, když se používá. Ve skutečnosti nevíte jestli ho uživatel (nebo jeho kolega, partner/ka, děcko) použil. Konektor samozřejmě může odejít i pokud se použije jen jednou, a otázka je, jestli je potřeba alespoň to jedno použití. Takže závěr je ten, že to může být driver nebo konektor, s tím že konektor jste nevyloučil. Chápu že vy máte předpřipravený závěr, který pak "vidíte v mlze". Já radši fakta, než abych věřil nesmyslům.
Ad kdo podle tebe muze za to ze se Windows chtej... restartovat - a co si o tom myslíte vy?
-
NULL (neregistrovaný)
"Ve skutečnosti nevíte jestli ho uživatel"
Vím, dotyčný NTB by totiž do nedávna můj a kupován byl nový. Takže
"Chápu že vy máte předpřipravený závěr, který pak "vidíte v mlze". Já radši fakta, než abych věřil nesmyslům."
e zase další <|> z té tvojí huby o věcech o kterých ho.no víš. Ale drze rýpat, to jo. Se divím, že radši nesedíš na podpoře MS a neradíš každému ať přeinstaluje drivery nebo rovnou OS. -
NULL (neregistrovaný)
" Buď driver, nebo zdířka sluchátek. Ty zdířky typicky detekují vložení konektoru........ že jsou připojena sluchátka. Ale v mlze je jasně vidět, že to není chyba driveru ani HW, ale OS :D"
Až na to, že to v nastavení ukazuje ty reproduktory, takže buď to správně identifikuje pokažený konektor jako sluchátka a debilně zobrazuje v nastavení, nebo debilně identifikuje konektor ( je teda ale chybný ) a správně zobrazuje v nastavení. V obou případech je to špatně. Na tom je hezky vidět, že logické myšlení a chápání psaného textu nezvládáš a v hlavě máš nas..no . . . To je přesně to, co předvádíš pořád. Link si najdeš (informaci) ale zpracovat ji a začlenit do problematiky nebo života tak, abys nebyl za debila, to už nedokážeš.
-
Lael Ophir (neregistrovaný)
No jasně, konektorem to být nemůže, protože notebook byl "do nedávna [váš] a kupován byl nový". To že to není konektorem prokážete buď tak že najdete jinou příčinu (klidně to může být ten driver, nebo i něco jiného), nebo tak že testem vyloučíte, že by to byl konektor. Problém jste sice podle všeho zatím nevyřešil, ale už víte, že já mám v hlavě nasráno, když upozorním, že to může být i konektor. To svědčí jednak o tom že nechápete ani triviality, a pak (což je zásadnější) o tom že jste nevychované vulgární hovado, jedním slovem lůza. Takže za mě: naučte se slušnosti, nebo jděte do hajzlu.
-
NULL (neregistrovaný)
"No jasně, konektorem to být nemůže, protože notebook byl "do nedávna [váš] a kupován byl nový". To že to není konektorem prokážete buď tak že najdete jinou příčinu "
Jsi idiot? Já ti nenapsal že to není konektorem ale že vím, že se nepoužíval, protože jsem ten notebook měl skoro celou jeho dobu já. Jak jsem psal. Ani psanému textu nerozumíš, tak se nepouštěj do nějakých rozborů, vole. Samozřejmě že mě to s tím konektorem nenapadlo (protože ho nikdo nikdy na tom ntb nepoužíval) a ani jsem neveděl že takové chyby mohou vzniknout a samozřejmě že to vyzkouším nebo otestuju - a to proto, že neodsuzuji informace jenom proto, že je vyřkne nějaká <|> ale třídím je podle toho, jaké jsou a jakou mají hodnotu a začlením je do rozhodování. Tak jak ti to celou dobu píšu. Pak se po takových výlevech a 0 chápavosti a volovinách co třepeš nediv, že ti člověk nadává nebo píše sprostě, protože jinak absolutně nezapojuuješ tu palici ani trochu . . .
-
Brouk (neregistrovaný)
1) zavést kompatibilitu s konkurencí
2) nabídnout (pokud možno co nejvíce stávajícím i novým klientům) VÝHODNOU / dotovanou cenu i při hostování konkurenčních služeb
3) vydržet tak dlouho, abych získal dostatečně velkou skupinu klientů
4) zavést "změny", které způsobí problémy pouze těm, kteří jsou ještě stále u konkurence
5) nabídnou vlastní řešení stávájícím klientům
6) GOTO 4 dokud nezlikviduji konkurenciZatím jsme u bodu 1), ale pokud se to povede, bude to pekelná jízda.
-
Osobně v tom jako archer moc potenciálu nevidím. Jediný, který mne napadá, je možnost proniknout snáze do wokenních nástrojů zevnitř, protože v kombinaci s virtualizací je možné téměř vše. Na straně Windows jsou patrné silné znaky deficitu systémového vývoje, což vede k otevírání se směrem k UNIX like prostředím. MS tím vlastně přiznává, že jeho cesta vedla stezkou hojnosti k poušti...
