Hlavní navigace

Microsoft přidává podporu D3D12 Compute do Mesa 22.0

11. 1. 2022

Sdílet

Microsoft Love Linux Autor: Microsoft

Není to tak dlouho, co Microsoft zaslal do projektu Mesa kód pro podporu OpenGL Shader Storage Buffer Objects. Jde o jednu z věcí, která pozvolna posouvá podporu kódu Direct3D 12 v Mesa od starší verze OpenGL 3.3 k věcem, které vyžaduje řada OpenGL 4.x. Nyní jde Microsoft o další krůček dál a do Mesa 22.0 zamířila podpora Direct3D 12 Compute.

Cílem je, aby bylo možné provozovat výpočetní (Compute) úlohy běžící přes OpenGL / OpenGL ES 3.1, a tak nad Direct3D 12 ovladači v rámci Windows Subsystem for Linux. Požadavek na začlenění kód do Mesa 22.0 zaslal Jesse Natalie z Microsoftu (k tématu má jedno starší video) a bylo mu vyhověno. Vydání Mesa 22.0 lze očekávat někdy v průběhu února tohoto roku.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 11. 1. 2022 23:10

    David Heidelberg

    Microsoft si zřejmě konečně řekl, že by mohl ušetřit za vývoj věcí, které může používat bez placení a vlastně mu na nich nesejde. Výrobci dodají kvalitní ovladače pro DirectX a zdarma dostanou mizernější implementaci OGL.

    Vzpomínám si, že s OpenGL byli v ovladačích často problémy v dobách, když jsem používal Win 95 - XP, takže bych řekl „huráˮ, kdybych je ještě používat musel.

    Jediné komu se to nevyplatí, jsou všichni ostatní. Přínos pro komunitu, Linux a alternativní systémy mi přijde přinejlepším lehce záporný -> komplexita kódu lehce vzroste..

    Change my mind.

  • 12. 1. 2022 3:25

    Ladis

    Celý je to jen kvůli tomu, abys pro cloud (= Linux) mohl vyvíjet na Windows PC. Díky grafickému ovladači v jejich virtualizaci WSL2 můžeš např. učit neuronové sítě na GPU NVidia, a pak to jen hodíš na server. Žádný trápení s instalací a nastavováním desktopového Linuxu (už tam např. funguje high DPI, aby to nebylo rozmazaný? a pro mě důležitá je i vzdálená plocha). Vzhledem k tomu, že na desktopovém Linuxu většina distribucí nevydělává, tak je to vlastně jedno (Ubuntu např. vydělává na serverech, proto se jim hodí spolupracovat s MS, aby ve WSL bylo Ubuntu - stejný OS jako na serveru).

    PS: Problém s OpenGL do XP včetně byl ten, že ovladače grafiky na CD Windows neměly OpenGL. Musel jsi stáhnout a nainstalovat ovladač z webu výrobce. Což pro BFU nebylo jednoduché.

  • 12. 1. 2022 8:01

    Derryk


    "Problém s OpenGL do XP včetně byl ten, že ovladače grafiky na CD Windows neměly OpenGL."

    Určitě? Pokud se dobře pamatuji OpenGL spořiče (3D Maze, 3D Pipes, 3D Létající objekty atd..) běžely od prvních Windows95 i v čisté instalaci. OpenGL od MS bylo údajně zkriplené, aby DirectX byl proti němu rychlejší. Silicon vydal vlastní OpenGL driver (CosmicGL ?) pro Windows, který poskytoval lepší výkon. Možná se pletu, je to již nějaký ten pátek, ale přísahal bych na to. ;)

  • 12. 1. 2022 10:11

    Ladis

    OpenGL existovalo jako softwarová knihovna, ale ne jako ovladače. Tato knihovna měla high performance vertexy, ale pomalé pixely. Verze od SGI přišla s akcelerací pixelů přes MMX. Microsoft rychlé pixely nepotřeboval, protože to měl zařídit výrobce GPU. Takzvaný Mini-Client Driver měl napojit jen funkci pro rasterizaci - zbytek už tehdy komplexního OpenGL nechal na Microsoftu. Byl to podobný driver model jako pro Direct3D (tehdejší GPU neměly hardwarové T&L).

  • 12. 1. 2022 10:36

    Ladis

    Zajímavosti:
    1. Vertexy v softwarovém OpenGL Microsoftu byly 3x rychlejší než v softwarovém MesaGL.
    2. Na instalačním CD Windows 2000 je Mini-Client Driver pro S3 Virge - jako ukázka programování MCD ovladačů OpenGL. Umí kreslit i v okně (to Virge standardně neumí, ale v Linuxu jo a MesaGL naportovaná do Windows také).

  • 12. 1. 2022 14:08

    Ladis

    Doplnění - tady je web benchmarku, co jsem dělal s bráchou:
    http://swarm.cz/gpubench/

    Výsledky jsou v odkazu RESULTS. Je tam i srovnání softwarových rendererů Microsoft/SGI/Mesa:

    Software (Mesa, P-MMX 133MHz)
    Software (SGI, 486DX4 75MHz)
    Software (SGI, P-MMX 133MHz)
    Software (WinNT4, P-MMX 133MHz)
    Software (WinNT4, 2xP3 1GHz)

  • 12. 1. 2022 15:06

    Ladis

    Doplnění od bráchy:

    Microsoft OpenGL neupradoval na MMX, protože v té době už byl rozkaz focusovat se na Direct3D. Nicméně zk*iplené nebylo... jen prostě vyšlo v době před MMX. To OpenGL od SGI pro Windows, které MMX mělo, vyšlo o nějaké roky později. Kdyby byla ještě původní vůle prosazovat OpenGL ve Windows, věřím, že by tam MMX přidali stejně jako třeba i nějaké další extense.

    Ale v době, kdy to OpenGL od MS vyšlo, tak bylo za mě naopak dost dobrý. Však netexturovaný věci se s ním daly používat i na rychlejších 486. U komerčních UNIXů si kolikrát za podporu OpenGL platit extra licence. Mám pocit, že po IRIXu byl Windows NT prvním OS, kde jsi mohl bez poplatků, out-of-the-box začít psát OpenGL programy.

  • 12. 1. 2022 9:11

    martinpoljak

    Narozdíl od Windows trápení s instalací a nastavováním na desktopovém Linuxu fakt není. To je ostatně právě jeden z důvodů, proč jsem Windows opustil už před lety. A co máte kde rozmazané fakt netuším.

  • 12. 1. 2022 10:05

    Ladis

    Mluvím o tom, že dnes většina majoritních distribucí defaultně kreslí přes Wayland, i když nejsou hotové základní věci jako podpora high DPI v X11 aplikacích (např 90 % nových notebooků má high DPI displej), vzdálená plocha a dokonce i drag&drop. Člověk pak musí řešit, jak permanentně přepnout na X11 (pak vše funguje).

  • 12. 1. 2022 14:18

    ja.

    Ale stale je pointa, ze high dpi rozmazane nie je.

    Rozmazany je fractional scaling pre X11 aplikacie beziace pod xwaylandom. Ono to tak aj zostane; X11 protokolom sa neda aplikacii povedat, ze na jednej obrazovke maju renderovat v jednej mierke, na druhej v druhej a v niektorych pripadoch v oboch (okno ktore prechadza z jedneho monitoru na druhy, low-dpi mirror high-dpi displeja), co je velmi realna situacia, ktoru wayland kompozitor musi obsluzit.

    A nie, zaviest novy protokol / nove atomy na X11 okne nie je riesenie. Existujuce X11 aplikacie s tym fungovat nebudu.

    Takze pokial mate problem s rozmazanymi aplikaciami pri fractional scalingu, pourgujte ich autorov, nech podporuju wayland.

  • 12. 1. 2022 14:29

    Ladis

    Takhle to ale není. Fractional scaling fungoval v dobách, kdy Wayland ještě neexistoval. Tak jako se okamžitě překreslily aplikace v GTK a Qt, když jsi v nastavení změnil DPI, tak pro multimonitor se tenhle event posílal aplikacím po přetažení na druhý monitor. A nemáte ani pravdu v tom, že se na podpoře High DPI nepracuje pro XWayland - první verze (nejprve natvrdo pro konkrétní aplikaci) už funguje na Fedoře pro Chrome (ten tam zatím, nebo aspoň nedávno, běžel přes XWayland). Funguje včetně přetažení na monitor s jiným DPI (akorát kuzor myši je pak blbě - podle toho se to pozná).

  • 12. 1. 2022 16:32

    ja.

    Akurat to nebol fractional scaling, ale specifikacia DPI pre displej (nie screen!). Bolo mozne mat viacero screenov s rovnakym dpi v ramci jedneho displeja, alebo viacero displejov s jednym screenom, ale v druhom pripade nebolo mozne presuvat okna z jedneho na druhy - aplikacia musela na jednom displeji okno zrusit a na druhom vytvorit. Toto zvladal akurat XEmacs, nic ine. Co sa tyka samotneho dpi, aplikacie nacitali globalne nastavenie pri starte, pouzivali ho po zvysok session a skalovali iba velkost fontov, ale nie ostatnych assetov, obzvlast nie rastrovych. Vyzeralo to dost zle a presne toto hidpi riesi.

    No a ze sa pracuje na whiteliste pre specificke aplikacie? Zabity cas, riesenie pre jednu aplikaciu, ale ked to niekoho bavi, nech sa hra. Google mohol radsej zapracovat na podpore Waylandu v Chrome... Ostatne stare X11 aplikacie s tym fungovat aj tak nebudu, z dovodu, ktory som spomenul vyssie.

    Vo Windows situacia je podobna - 99% aplikacii pri pouziti s large fonts (co je ekvivalent X11 dpi) je rozbitych. Preto Windows 8/10 prisli s novymi API pre hidpi.

    MacOS zase pre zmenu povie vsetkym aplikaciam ze bezia v hidpi (ak je aspon jeden pripojeny displej hidpi) a skaluje to smerom dole v displej serveri. Vysledky to dava vacsinou uspokojive, okrem niektorych velkosti, ako napr. 125%. Preto tato velkost, popularna v PC svete (fullhd@14"), v MacOS nie je dostupna vobec.

  • 12. 1. 2022 17:01

    Ladis

    1. DPI, které není násobek 100 %, je fractional scaling.

    2. Nevím, co mícháte nějaké obrazovky a screeny. Mluvím o tom obdélníkovém zařízení zobrazujícího obraz. Desktopový monitor nebo displej notebooku.

    3. Nemluvím o separátním X serveru na druhém monitoru. Mluvím o více monitorech obsluhovaných jedním grafickým serverem (můžete např přetahovat okna).

    4. Nemáte pravdu. Čisté GTK a Qt aplikace škálovaly i rastrovou grafiku a projevila se změna DPI okamžitě. Jiné aplikace, jako např Firefox, bylo třeba restartovat (četly si DPI jen pro startu, ale škálovaly i rastrovou grafiku). Určitě byly aplikace, které škálovaly jen fonty, ale takové byly i např ve Windows. Příslušně upravit aplikaci bylo mnohem míň práce než ji předělávat na Wayland (to totiž není jen přechod na vyšší major verzi GUI toolkitu, ale i zbavení se všech volání X11 - přitom dodnes např GTK 3 neumí relative mouse movement, takže musíte psát vedle sebe příkazy X11+Wayland).

    5. Zabitý čas to není, protože člověk není živ jen desktopem, terminálem, jednoduchým file manažerem, notepadem a webovým prohlížečem. Takový GIMP (jeden z nejvýznamnějších grafických software na Linuxu) začal přechod na GTK 3 až nedávno (čekal,naz se ustálí vývoj, který každou chvíli přinesl nějakou nekompatibilitu).

    6. Google samozřejmě pracuje na podpoře Wayland v Chrome. Experimentálně to jde zapnout. Ale nezapomeňte, že na Waylandu se stále pracuje - ještě se dodělává poslední základní funkčnost. Některé aplikace na to musí počkat.

    7. Není pravda, takzvané Large Fonts (DPI 125 %, mimochodem většina dnes prodaných notebooků - FullHD na 15") fungují ve Windows od verze 3.x - z dob kdy ještě žádný Linux neexistoval! Proto je jeho podpora i v 10, někdy i 20, let starých programech. Problém ve Windows nastal s DPI 150 % a vyššími. Nicméně Microsoft to zvládl udělat tak, že není třeba předělávat aplikaci na jiný grafický server, GUI framework, nebo aspoň vyšší major verzi stávajícího frameworku. Stačí přidat položku do manifestu, že aplikace umí HighDPI nebo MultiDPI a odpovídat na nové eventy. Mimochodem, starší aplikace, které umí jen HighDPI (jeden monitor, s vyšším DPI), ale ne MultiDPI (více monitorů, s různým DPI), fungují aspoň na primárním displeji (v XWayland by je rozmazal - dokud nebude pro tohle dokončena vámi zavrhovaná podpora v XWayland).

    8. MacOS byl vždycky OS pro grafickou práci, takže přirozeně přinesl masivní nástup HighDPI. Váš vysmíváný systém škálování mimochodem používá i ten "úžasný" Wayland. Jenže Apple si to může dovolit, protože k tomu dodává dostatečně výkonné GPU. Mimochodem i 125 % brácha rozchodil na externím displeji k macbooku - je třeba ale použít hack s pomocným virtuálním monitorem.

  • 12. 1. 2022 17:19

    ja.

    1) Nie, nie je. Fraction == zlomok. 200% alebo 300% nie je fractional scaling, ale integer scaling.

    2) Pokial neviete, zopakujte si terminologiu X11. https://en.wikipedia.org/wiki/X_Window_System#Key_terms

    3) V tomto pripade v X11 obe musia mat rovnake DPI. V case ked sa to navrhovalo zjavne nepocitali s tym, ze kazdy screen moze mat inu hodnotu.

    4) Nie, neskalovali. Okrem toho to nie je len na frameworku, ale aj na aplikacii. Ked GIMP zobrazuje nejaky subor, musi vediet, co urobi s ikonami v toolbare a co so samotnym pouzivatelskym suborom (doteraz to nevie). Detto Remmina.

    5) GIMP konkretne ma problem s clovekohodinami -- resp. s tym, ze ich nikto nedava do tohto projektu. GTK3 je tu vyse 10 rokov.

    6) Ked porovnam, ako rychlo boli schopni urobit niektore veci (napr. podpora ARM) a ako sa vlecie podpora Waylandu, tak Chrome pre Linux ma zhruba rovnaku prioritu ako ten GIMP ;). Ta "zakladna" funkcnost ktora sa doraba su upravy, ktore mohli byt urobene len na zaklade skusenosti aplikacii z praxe... ktore na to tiez nejaku dekadu zvysoka. Zobudili sa, az ked RHEL dal Wayland ako default, ze aha, oni to fakt myslia vazne.

    7) Linux v tej dobe existoval, bola to jedina moznost, ako mohol mat bezny student doma 32-bitovy system aj s X11. Large fonts bolo rozbite odkedy sa zacali objavovat aplikacie napisane v Delphi (t.j. tiez doba Windows 3.x), kde na to programatori tiez zvysoka, ved na ich pocitaci to islo dobre... A ako to viem? Mal som 17" monitor s rozlisenim 1280x1024, kde bolo treba pouzivat Large fonts, tak velmi dobre viem, co vsetko neslo.

    > Nicméně Microsoft to zvládl udělat tak, že není třeba předělávat aplikaci na jiný grafický server, GUI framework, nebo aspoň vyšší major verzi stávajícího frameworku. Stačí přidat položku do manifestu, že aplikace umí HighDPI nebo MultiDPI a odpovídat na nové eventy

    Microsoft ma ten "luxus" ze kazda jedna aplikacia ma dynamicky prilinkovane gdi.dll a tam si mozu poupravovat co chcu. Linuxovy displaj server musi fungovat s kazdou aplikaciou, ktora si otvori X11 socket a hovori X11 protokolom, ci uz je to historicky libx11 nalinkovany staticky, najnovsi libxcb, nalinkovany dynamicky alebo doma uvarena kniznica na X11 protokol (boli take pokusy v go...).

    > Mimochodem, starší aplikace, které umí jen HighDPI (jeden monitor, s vyšším DPI), ale ne MultiDPI (více monitorů, s různým DPI), fungují aspoň na primárním displeji (v XWayland by je rozmazal - dokud nebude pro tohle dokončena vámi zavrhovaná podpora v XWayland).

    Ono je dost aplikacii, ktore su rozmazane aj vo Windows.

    8) Ja sa downscalingu nevysmievam, kde ste to nasli? Ono to ma dovod, preco to Apple zatrhol - treba zobrazovat 8 logickych pixelov pomocou 5 fyzickych, a ono to fakt uz vyzera dost blbo. Apple ani take displeje nema, ktore by to potrebovali. Na Linuxe alebo Windowse bohuzial pouzivatelom povedat nemozete, pocuvat nebudu a budu si dupat svoje, a potom sa stazovat, ze to blbo vyzera - aj ked presne to je dovod, preco to nebolo podporovane v prvom rade.

  • 12. 1. 2022 18:06

    Ladis

    1. Však to jsem psal: "DPI, které není násobek 100 %, je fractional scaling."

    2. Vy jste začal se slovíčkařením, co jednotlivé termíny znamenají v jednom z mnoha grafických API, o kterých se bavíme. Já předpokládal, že každý chápe pod obrazovkou/scre­enem/monitorem to samé.

    3. Je pravda, že X11 podporu monitorů s různým DPI sám neřeší, ale řešilo to desktopové prostředí. Koneckonců ani Wayland mnoho věcí neřeší a zůstává to na desktopovém prostředí (duplicitní práce, jak každé to musí implementovat znovu - uvidíme, jestli vzniknou nějaká DE např. na wlroots, který se to snaží sjednotit). Nejpoužívanější distribucí bylo Ubuntu, a v něm jeho prostředí Unity to umělo - postupem, jak jsem popisoval. Poslal event o změně DPI oknu po přesunu na druhý monitor s jiným DPI. Vzhledem k enormní roztříštěnosti linuxových distribucí samozřejmě věřím, že byly i takové, kde to nefungovalo (koneckonců ani ten Wayland dodnes ani po 10 letech ve většině distribucí nefunguje!).

    4. Jak píšu, moje zkušenost je, že aplikace neměly problém škálovat i ikony např. v toolbaru. Měnil jste skutečně DPI, nebo jen velikost písem?

    5. První roky ale bylo GTK 3 každou chvíli rozbité. Navíc pokud má GIMP problém s člověkohodinami, co většina toho software, co dělají fanoušci opensource o volném čase po práci?

    6. Chrome podporoval ARM už z dob prvních chromebooků a co byl naportován na Android (nejprv tam byl jiný prohlížeč). Myslím, že v současnosti v Chrome na Wayland nefungují jen věci, které ještě nejsou ve Wayland hotové - až budou, tak to Google implementuje.

    7. Já Delphi taky používal, ale 125 % DPI monitor jsem tehdy neměl, tak nevím. Jinak je třeba rozlišovat mezi původním režimem 125 % "Large Fonts" a tím moderním roztahováním ve Windows, které rozmaže i tyto aplikace a neptá se, jestli umí 125 %. Pokud máte displej s DPI 125 %, tak na původní systém (ostrá grafika) jde stále přepnout, akorát ve Windows 11 už jen v registru. Windows to takhle dělá, aby fungovalo případné připojení externího monitoru s jiným DPI. Ale není to problém, díky mnohem jednodušší implementaci High/MultiDPI ve Windows aplikacích se podpora rychle přidala do většiny z nich.

    Kolik aplikací mluví s X serverem přes socket? Většina přes knihovnu. Resp. přes nějaký GUI toolkit nad tím. Nikdo neříká, že 100 % aplikací musí být dokonalé (tj. ne roztažené s rozmazáním - to ale stačí jako fallback). Stačí podpora pro aplikace GTK/Qt/SDL nebo "přímo" přes X11 knihovnu a pokryjete tím většinu aplikací a her. Když jsem studoval zdrojáky Quake 1 (použil jsem je pro X11 verzi benchmarku GPUbench, viz https://www.root.cz/zpravicky/microsoft-pridava-podporu-d3d12-compute-do-mesa-22-0/#o1084911 ), tak i tahle stařičká hra kreslila přes X11 knihovnu a ne socket.

    >> Mimochodem, starší aplikace, ...
    >Ono je dost aplikacii, ktore su rozmazane aj vo Windows.
    Situace, o které jsem mluvil, je cca 10 let stará aplikace (tj. ještě před zrozením Waylandu), která podporuje vyšší DPI, ale ne různé monitory s různým DPI. Windows ji vykreslí v DPI primárního monitoru - na ostatních monitorech ji škáluje jako bitmapu, ale tu highres verzi podle primárního monitoru, ne podle DPI 100 %. V XWayland to ignoruje a bere ji jako aplikaci, co nic o DPI neví. Samozřejmě pracuje se na tom, aby to fungovalo - navzdory vašim nářkům.

    8. Apple to potřebuje, protože víceméně neprodává externí monitory - uživatel musí připojit "PC" monitor. PC je o velkém rozmezí výkonu a ceny, a proto Windows zvolil nativní vykreslování pro různá DPI. Tj. pro dnes nejrozšířenější DPI 125 % není třeba 2,56x výkonnější GPU pro kreslení DPI 200 % (a pak downsamplovat). Wayland šel cestou Apple, takže Linux je na stejném HW pomalejší než Windows.

  • 12. 1. 2022 17:15

    Saljack

    Nefungoval vždy to DPI bylo stejné měl jsem 4K a FullHD a hrál jsem si s tím fakt dlouho a na X11 to prostě nejde aby měla jedna obrazovka jiné DPI jako druhá.

  • 12. 1. 2022 12:29

    Maor

    Na windows žádné problémy nejsou, většinou jsou na PC předinstalované a uživatel si jen vytvoří účet. Přizpůsobení si OS je na obou srovnatelně náročné, většinou stačí nainstalovat nějaký "tweak" balíček s GUI klikátky, kde se dá všechno nastavit.
    Na windows ale jde spustit i aplikace složitější grafická aplikace ne jen VIM v terminálu. Jakmile uživatel chce na linuxu pustit něco, co vyžaduje 2D nebo 3D grafiku, má problém, pokud si nenajde na všechno OOT patche.
    To jsem nezačal s tím, že aktualizace na linuxu něco rozbije mnohem častěji, než na Windows.
    Dle mých zkušeností je celkem použitelná distribuce ChromeOS a pokud netřeba desktop tak RHEL, ostatní distribuce jsou typu pofixuj si sám.

  • 12. 1. 2022 14:49

    bez_přezdívky

    ...aha.

    A já jsem myslel, že ty aktualizace, co mažou uživatelská data, vytvářejí boot-loopy a podobně jsou pro Windows.

    Taky jsem netušil, že ty aplikace, které vyžadují akceleraci grafiky a které mi pěkně běhají, že provozuji na Windows. Také si nepamatuji, že bych hledal nějaké OOT patche (to ani netuším co to je).

    Windows jsou sice předinstalované, ale kromě webového prohlížeče a notepadu snad neobsahují vůbec nic. Takže tu hromadu aplikací pro běžné použití není potřeba doinstalovat (narozdíl od linuxu)?

    Ale toho trolla už krmit nebudu.

  • 12. 1. 2022 15:21

    Jen tak

    ty delas, jako kdyby se to delao kazdy tyden dvakrat. povede se to jednou za dva roky a to jeste na omezenem mnozstvi pocitacu.

    az bude linux na desktopu rozsireny stejne masove, jako windows, budou takoveto problemy viditelne i na linux. jak jednoduche.

  • 12. 1. 2022 22:12

    bez_přezdívky

    Nevím, jak rozšířenost linuxového desktopu rozbije jeho aktualizace? Linux je bez nadsázky nejrozšířenější uživatelský operační systém v celé sluneční soustavě a desktop pouhá podmnožina aplikací, které můžeš nebo nemusíš mít (narozdíl od Windows ne-server).

    Aktualizací jednotlivé distribuce připravují dohromady stovky, možná i tisíce, denně. A nevím o případu kdy aktualizace jako taková zlikvidovala uživatelská data. Vím o znepřístupnění vlivem chyby aplikace, vím o poškození vlivem chyby admina (ať už aktualizací nebo přeinstalací systému či aplikace), ale ne o masivním mazání, protože aktualizace.

    P.S. Ve Windows oddělení v bývalé práci měli pěkný bobky z každé aktualizace a divil by ses kolik jim dalo práce, než je pustili na všechny stanice. A to byly všechny centrálně spravované a uživatelé neměli admin práva.

  • 12. 1. 2022 23:11

    Jen tak

    nerozbije je nijak . on uz je rozbiji. jen diky marginalnímu rozsireni mezi bfu se o tom prakticky nemluví, protoze si toho prakticky nikdo nevsimne.

    az bude na desktopu pouzivat linux vetsina planety, tak kazdy maly prusvih bude videt tak, jako na windows.

  • 13. 1. 2022 12:29

    Jen tak

    a tys jeste nezazil, ze aktualizace nejakeho baliku na linuxovem desktopu zpusobila nefukcnost neceho?

    aha... zajimave.. ja jen, ze linuxovy diskusni skupiny jsou takovych pripadu plné .. -D

  • 13. 1. 2022 13:57

    bez_přezdívky

    No popravdě řečeno už hodně (opravdu hodně) dlouho ne. A to tak, že si nepamatuji vážnější problém. A pokud bych to vztáhl na jádro, základní OS a desktop, tak od okamžiku, kdy nepoužívám nvidia GK, tak snad vůbec.

    A pokud to vezmu obecně, tak zde, prosím, srovnáváme nesrovnatelné - v Linuxu je téměř vše volitelná aplikace - můžu ji mít nebo nemusím. Vše se navíc řídí centrálním repozitářem distribuce, takže se stírají rozdíly mezi „základním systémem“ (jádro + desktop) a „aplikací třetích stran“ (např. grafický/texto­vý/video editor, antivir, pracovní nástroje...) jako je to u Windows. A chyby v aplikacích jsou napříč operačními systémy a mohou rozbíjet něco co chvíli. U Win se kritika snese na autora, u Linuxu na distribuci, ale chyba je pořád u autora.

    V každém případě, nezažil jsem, kdy by aktualizace způsobila smazání uživatelských dat. Mohou být nepřístupná, ale ne smazaná. Případně, ve verzi X něco jede, ve verzi x+1 už ne. Ale opět to jsou věci, co se dějí všude zhruba stejně. Ale stále mohu obvykle jít o krok zpět...

  • 13. 1. 2022 14:26

    Jen tak

    a to je přesně to, co píšu ... vy jste něco nezažil, nebo neviděl.. ale vy jste malý vzorek.

    ja používám windowsy od dob win 95. a řekněmě že od dob osmiček (ale ani před tím) jsem taky nezažil, že by windows update něco rozbil (at funkcne, nebo treba doslo ke ztrate dat). a taky netvrdím, že se něco nemůže stát. jsem, stejně jako vy, jen nevýznamný statistický vzorek.

    pokud se třeba ve windows update objeví problém, který postihne 0,1% instalací, tak se pořád jedná o 1,5 milionu uživatelů. a tak je o takovém problému slyšet.

    pokud se na linuxovém desktopu objeví problém, který postihne 0,1% instalací, tak se bavíme o cca 37 tisících postižených uživatelích. toho si v podstatě nikdo nevšimne.

    (čísla vychází z jakéhosi průzkumu, který tvrdí, že na desktopu má windows cca 1,5 mld počítačů a tvoří to cca 80% podílu všech desktopových instalací. o linuxu stejný zdroj tvrdí, že jde o cca 2%)

  • 13. 1. 2022 14:29

    Ladis

    Ano, jak už tu bylo víckrát řečeno, některé problémy v (desktopovém) Linuxu "nenastávají" jednoduše díky jeho marginálnímu rozšíření. Však i ve Windows ty problémy byly u tak malého promile uživatelů, že to MS ignoroval. Problém byl právě v tom, že pro určité typy chyb (smazání dat) by neměla být žádná hranice, kdy problém ignorovat.

  • 12. 1. 2022 20:53

    D.A.Tiger

    [David Heidelberg]
    Me to moc neprekvapuje. Vlastne vubec. Stale vice me pripada, ze cele to "ms love linux" se da do cestiny prelozit takto: "Dobre, utecte si jinam, ale udelame maximum, aby jste neutekli daleko - na Widlich, pod taktovkou M$".

    Kazdopadne, otazkou vsak je, jestli z toho neco nemuze vytriskat treba Wine - pak by to nejaky ten prinos preci jen melo.

    Jinak k tomu OpenGL na starych Widlych. Ja moc s tim velky problemy na 95-XP nepamatuji - alespon co se tyce her. Prikladem budiz RTCW, ktery prave OpenGL vyzadoval (pokud si to dobre pamatuji). Nekdy v dobe Vist, se vsak M$ s OpenGl rozkmotril a pak teprve zacaly problemy....

    12. 1. 2022, 20:54 editováno autorem komentáře