Mě celkem baví ta dlouhá léta úvah uživatelů Linuxu na téma "Windows určitě přejdou na linuxový kernel". Kernel Windows je v principu dost odlišný od jakéhokoliv unixového, a upřímně o dost lepší. Hlavně se ale liší tím, že se podobné věci dělají jinak. Stačí si projít dokumentaci API (v případě Linuxu asi zdrojáky), a hned uvidíte spoustu rozdílů. Jako příklad si vezměte funkce NtCreateFile() a open() níže. Rozdíly jsou i v práci s pamětí, dramaticky odlišně se liší správa zařízení, grafika atd.
https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntcreatefile
https://manpages.debian.org/unstable/manpages-dev/open.2.en.html
Je fajn, že existují compatibility layers typu Wine. Jenže ty ve skutečnosti značnou část Win32 API ignorují, aplikaci hlásí že byla akce úspěšně provedena, a spoléhají na to, že to nepovede k nefunkčnosti aplikace. Na straně Windows jste mohl vidět WSL verze 1, kde se implementovaly linuxové syscalls, a výsledek byl výkonem i absencí podpory některých syscalls dost nepřesvědčivý. WSL verze 2 už jedou Linux kernel ve VM, do kterého se zavádějí moduly virtuálních zařízení komunikujících přes VM bus, a přístup k FS se řeší přes network redirector. Na obou stranách jsou tedy vidět omezení compatibility layeru. Když chcete běžet Win32 aplikaci na Linuxu, raději si pusťte Windows ve VM. Když chcete běžet Linuxovou aplikaci na Windows, pusťte si přes WSL Linux (de-facto) ve VM.
Včem je lepší win kernel, když firmy musí platit implentaci a její aktulizaci? Tudíž když firma nemá peníze tak to stagnuje... to znamená zastarávání jejich "jádra" jako takového... Tudíž se vracíme k tomu linux vs win... ale MS je na peníze a nevěřím tomu, že ušetřené peníze za jádra nebudou zrovna malé, aby k tomu rozhodnutí nedošlo...
Oni lidé obecně pracují jen když z toho něco mají. Pokud jde o MS, tak ten je momentálně v žebříčku tržní kapitalizace na druhém místě s částkou 3 395 miliard dolarů, a minulý rok měl příjmy ve výši 211.9 miliard dolarů, což je mimochodem více než dvojnásobek českého státního rozpočtu. Fakt bych se nebál, že by MS neměl peníze na vývoj.
Migrovat Windows na linuxový kernel je asi stejně praktické, jako posadit bagr na podvozek motokáry, nebo naopak. Prostě to na sebe nepasuje, a přineslo by to dlouhou řadu problémů.
To už bych upřímně viděl jako pravděpodobnější, že IBM zabalí AIX, HP zabalí HP-UX a Oracle zabalí Solaris. Všechny jmenované Unixy totiž mají s Linuxem veliký překryv funkcionality a konceptů. Řekněme že je to jako posadit bagr na podvozek jiného bagru, nebo motokáru na podvozek jiné motokáry. Tedy nikoliv triviální, ale přesto daleko snazší. A že ten či onen Unix umí proti Linuxu něco navíc? Přece není problém danou funkcionalitu dodat do Linuxu, zvlášť když k ní máte zdroják. Víte kolik by ty firmy mohly ušetřit na vývoji vlastního OS?
Win32 API bylo "nalepené" na MS-DOSu, OS/2 a NT? To je poměrně odvážné tvrzení, když Win32 bylo vytvořené pro Windows NT.
O Wine jsem přece psal. Spoustu volání Win32 API prostě ignoruje, vrací 0x0 (ERROR_SUCCESS, The operation completed successfully) a spoléhá se na to, že to nezpůsobí ztrátu funkce dané aplikace. A zatraceně často tahle sázka nevyjde.
Kde konkrétně se MS snažil zbavit legacy API nadobro? Snad leda Windows RT, které obsahovaly spoustu Win32 aplikací, ale umožňovaly instalaci dodatečných aplikací pouze přes Store. Jenže to měla být hlavně blbuvzdorná konkurence pro ořezané Chromebooky. Kde jinde se o to MS pokoušel?
Zabudli ste spomenúť .Net, predtým sa ešte vymýšlal Avalon a podobné ptákoviny. Proste win api je také zlé, že ho nemajú radi ani v microsofte. A je zastaralé, sú s nim problémy Len bohužiaľ veľkí výrobcovia softvéru na ňom trvajú.
Dobre, ohýbajte si slová, ako chcete, ak zajtra opustia NT architektúru, ktorú ukradli fy. Digital, proste použijú niečo iné, povedzme TempleOS. Oni sú v tomto flexibilnejší, než si myslíte.
7. 7. 2024, 21:29 editováno autorem komentáře
.NET Framework není náhradou Win32 API. Je to sada knihoven pro vyšší úroveň abstrakce, podobně jako řekněme Delphi runtime library. Když se podíváte řekněme na System.Drawing, tak je to C# wrapper pro Win32, převážně pro GDI+. Windows.Forms zase obalují User32 a GDI+, atd. Avalon, resp. WPF, je dlouho součástí .NETu, a v podstatě jde o managed GUI framework nad DirectX. Nevěříte? Ke všem jmenovaným komponentám MS uvolnil zdrojáky, takže si je můžete na GitHubu projít.
Nekonkrétní boilerplate typu "zlé, nemají rádi, zastaralé, 'sú s ním problémy'" apod. ani nemusíte psát, protože bez konkrétních podpůrných argumentů je to o ničem.
MS je flexibilní, ale nevidím důvod, proč by opouštěl architekturu NT, která velmi dobře funguje. Pokud by migroval, tak na něco lepšího, ne na nějaký generačně starší Unix. Motivací k migraci by mohl být například managed code OS, který by měl nějaké matematicky zaručené vlastnosti, a tím eliminoval dlouhou řadu bugů a bezpečnostních problémů.
Pokud jde o "krádež architektury firmy Digital", tak to považuji za pokus o flame. Ale zkusme krátkou sumarizaci. VMS byl napsán v assembleru, NT jsou psané v C/C++ a od začátku portabilní. VMS měl monolitický kernel, NT jsou modifikovaný mikrokernel. VMS neměl (v době designu NT) multithreading, NT na něm od začátku masivně stojí. VMS neměl subsystémy, NT od začátku měly subsystémy Win32, OS/2 a POSIX. Samotné API VMS a NT je také naprosto odlišné. Jestli ty systémy mají něco společného, tak je to hlavní architekt a pár obecných konceptů, protože nikdo nebude vymýšlet znovu kolo.
Zkuste si také uvědomit, že Linux je od začátku psaný podle dokumentace jiných Unixů, reimplemetovaný jednu stránku dokumentace za druhou. Občas se v něm dokonce okrajově objevil kód z jiného Unixu (kde ovšem společnost SCO nedokázala prokázat, že má k zahrnutému kódu autorská práva, na čemž její soudní procesy ztroskotaly). Závěry ohledně toho, kdo co ukradl, nechám na laskavém čtenáři.
>>>Je to sada knihoven pro vyšší úroveň abstrakce, podobně jako
Whatever, tú vyššiu abstrakciu potrebovali, aby sa zbavili zastaralého low level api. Ale trh chcel inak. Tak so sebou ťahajú tú škaredú obludu aj s mŕtvymi hnátami a kopou nedorobkov.
>>>Pokud jde o "krádež architektury firmy Digital", tak to považuji za pokus o flame.
Preto, keď posunieš VMS o jeden znak dostaneš WNT, čo nie je náhoda, ale zámer, vykrádali platformu ako len mohli. Mali z toho právne problémy, ale urovnali to vytvorením WNT pre architektúru Alpha. Čo bolo pre Digital výhodné, lebo ich počítače boli rýchlejšie, než PC.
Čo sa týka POSIX-u na WNT, musím sa smiať, bola to najhoršia implementácia, aká existovala. Microsoft si z nej urobil srandu, ako len mohol. Aspoň vďaka tomu Cygnus software niečo zarobil. Radím si pozrieť video "How Microsoft Made A Mockery Of Government Standards (ft. POSIX Subsystem)"
S tým opisovaním kódu z UNIX-u do Linuxu, to sa prudko mýlite, nič také nebolo. Iba Microsoftia baracuda SCO trollovala konkurenciu Microsoftu. SCO bola pôvodne divízia Microsoftu, ktorá vyvýjala prvý komerčný UNIX vôbec - Xenix. Microsoft, pardon SCO bol len na smiech a nič nedokázal.
Alebo to máte pomiešané a mýlite si to s 386BSD, tam bol problém, ktorý neskôr odstránili, lebo 386BSD je UNIX, teda aspoň jeho ideový potomok. Ten sa vytváral prepisovaním UNIX-u.
Víte, ono je dobré psát spíš o věcech, o kterých máme trochu představu.
Low level API nejsou zastaralá. Na Unixech můžete vidět libc (glibc), X11 a další low level API. Většina aplikací pro Linux je psaná pro Qt, GTK, Cairo a další API s vyšší úrovní abstrakce. Znamená to tedy, že je libc zastaralá, protože je low level? Ne. Všechny ty ostatní higher level knihovny používají libc a další low level knihovny, aby postavily tu vyšší úroveň abstrakce. Podobně písek a cement nejsou zastaralé jen protože při stavbě domu většinou používáte betonové cihly, které jsou tak mimochodem z písku a cementu. Z cihel se jen některé věci lépe staví.
V čem *konkrétně* Windows NT "vykradly" VMS? Ano, Digital se chtěl soudit, MS nechtěl, a místo toho situaci využil. Dostal NT na platformu Alpha, a vycvičil lidi z Digitalu v jejich podpoře a prodeji.
POSIX subsystem ve Windows byl určený pro migraci existujícího unixového SW na Windows, a byl POSIX compliant. To video, které uvádíte, je o ničem. Autor nechtěně vtipně považuje Windows Resource Kit a SDK, tedy dvě věci které jsou volně ke stažení na webu MS, za "obskurní". Děsně ho překvapuje, že POSIX Subsystem neuměl přímo zavádět binárky zkompilované pro úplně jinou architekturu, nebo to že když chce něco přeložit, tak potřebuje... kompilátor?! No to je skandál :D. Zkouší kompilovat kolekci her pro BSD "z konce 90. let", které používají API neobsažená v POSIXu (protože POSIX je nejmenší společný násobek toho API chaosu ve světě Unixů), a zkouší to na OS vydaném v roce 1996. Překvapuje ho hromada warningů a chyb při kompilaci, protože zřejmě nikdy nezkoušel ani přeložit nic na Linuxu ze zdrojáku. Nakonec si sám můžete zkusit nainstalovat řekněme FreeBDS, a přeložit nějakou aplikaci psanou pro Linux. Na AIXu, HP-UX nebo Solarisu to je problémů jen více. Mimochodem co má podle vás s věcí společný Cygnus? Nepletete si to s něčím jiným?
Ohledně Linuxu jste se zapomněl vyjádřit k tomu, že je reimplementací Unixů, jednu stránku dokumentace po druhé. Je to podle vás vykrádání, nebo ne? Protože logicky těžko zároveň tvrdit že Windows NT "vykradly" VMS, a že Linux není vykradený Unix.
Do Linuxu se dostal kód Berkeley Packet Filter, části kódu sovusejícího s formátem ELF (řekněme .exe pro Unixy), kód napsaný v USL jako rozšíření dřívějšího kódu Unixu, kód podpory SMP, JFS, RCU a NUMA napsaný v IBM jako rozšíření dřívějšího kódu Unixu, a pár dalších případů. Problém pro společnost SCO byl v tom, že na nic z toho nebyla schopna doložit autorská práva. Jinak SCO (tehdy Santa Cruz Operation) nikdy nebyla pobočkou MS. MS licencoval Unix od AT&T, a upravil do a uvedl ho na několik platforem, včetně x86, pod jménem Xenix. Svého času to byl nejrozšířenější Unix na světě, měřeno počtem instalací. Společnost Santa Cruz Operation, podobně jako další společnosti, byla prodejcem Xenixu, podílela se do jisté míry na jeho portování a rozvoji. Společnost SCO Group, která vedla soudní spory ohledně Linuxu, nemá s původním Santa Cruz Operation moc společného. V roce 2000 totiž Caldera Systems odkoupila divizi unixových technologií a služeb od Santa Cruz Operation. V roce 2002 se Caldera Systems přejmenovala na SCO Group, a začala vést spory ohledně kódu od Santa Cruz Operation, který se měl údajně dostat do Linuxu. Nechme proto pohádek o tom, jak byla SCO Group "kdysi divizí Microsoftu", apod.
>>Low level API nejsou zastaralá. Na Unixech můžete vidět libc (glibc), X11 a další low level API.
Zle ste ma pochopili (ako ináč), low level api nie sú zastaralé. Windows api je zastaralé. .Net mal slúžiť na to, aby bol jednoduchší prechod medzi rôznymi low level api. Načo by ináč písali multiplatformný engine s virtuálnym strojom, ak by nemienili pokryť viac platforiem? A tými platformami nemali byť plaformy ako linux, ale windows platformy.
>>> V čem *konkrétně* Windows NT "vykradly" VMS?
Konkrétne vo všetkom, tu je článok: https://web.archive.org/web/20180731124738/https://www.itprotoday.com/management-mobility/windows-nt-and-vms-rest-story
>>>POSIX subsystem ve Windows byl určený pro migraci existujícího unixového SW
Mal slúžiť na obchádzanie požiadavky pre vládne systémy, ktoré vyžadovali POSIX. Implementovali štandard naschval najhoršie, ako to išlo. Lebo nebol dovtedy najlepšie napísaný. POSIX na WIN NT bol nepoužitelný, akákoľvek snaha portovať POSIX-ové programy bola takmer nemožná. Tu dávam link na spomínané video vyššie: https://www.youtube.com/watch?v=BOeku3hDzrM
>>> Ohledně Linuxu jste se zapomněl vyjádřit k tomu, že je reimplementací Unixů, jednu stránku dokumentace po druhé.
Nie je, je to kernel napísaný na zelenej lúke.
>>>Do Linuxu se dostal kód...
Nedostal. Boli to falošné obvinenia a celý proces bol trolling.
Aha. Takže win32 je zastaralé protože... Nic konkrétního k těm API nejste schopen uvést, ale zato se dozvím kouzelnou nepodloženou spekulaci: .NET - implementovaný ve Win32! - měl být určený pro přechod mezi různými nekompatibilními Windows. K tomu sice nemáte žádný relevantní podklad, ale asi stačí váš silný dojem. A zřejmě pomocí nějakého oslího můstku to má dokazovat zaostalost Win32, s tím že konkrétní aspekty toho API sice neznáte, natož abyste věděl v čem konkrétně podle vás má být zaostalé, ale dojem je dojem, a to se počítá :D. Pro vaši informaci, .NET byl minimálně částečně odpovědí Microsoftu na Javu. Jde o framework pro snazší psaní aplikací, stejně jako například Visual Basic a jeho VBRUN knihovny, nebo Borland Delphi a jeho Delphi runtime library.
Článek o NT v. VMS by mohl popisovat stejnou podobu mezi Unixem a NT. Že se v NT procesu říká proces (jako na VMS, Unixech a všude jinde), kernel podporuje SMP (jako na VMS a dlouhé řadě Unixů), používá se stránkovaná a nestránkovaná paměť (jako na VMS a dlouhé řadě Unixů), procesy mají prioritu a nižší číslo znamená nižší prioritu (jako na VMS, Linuxu a BSD), scheduler zvyšuje prioritu procesu pokud by se zbytečně čekalo (jako na VMS a AIXu) atd. - to má být to "vykradení"? LOL :D. Není vykradení také to, že se používá file system a soubory mají jména?
To video jsem komentoval, a nechci to dělat znovu. MS implementoval POSIX.1, a samozřejmě byl použitelný, protože prošel certifikací. Portovat POSIXové programy šlo, pokud používaly výhradně POSIX API (a přesně to vláda chtěla). Případné použití ne-POSIX API vyžadovalo nahrazení volání pomocí těch POSIXových. Ovšem podobné problémy existují při kompilaci unixového SW na jiném Unixu naprosto běžně, protože - a to zjevně nevíte - Unixy nemají všechny stejné API, a v řadě věcí se liší. Už jsem popisoval, že autor videa vypadá šokovaný tím, že si musí dvě věci stáhnout, a že pro překlad zdrojáku potřebuje kompilátor, což podle něj znamená, že je věc nepoužitelná, protože by to nikdo nedělal. Jenže z perspektivy vývojáře, který má portovat POSIX aplikaci, je to celkem v pohodě. A uživatel? Ten nepotřebuje SDK, Resource Kit ani kompilátor. POSIX aplikaci pro Windows prostě spustí, protože ji pro něj někdo přeložil. Opakuji, že za mě je to video o ničem. Zkuste trochu zapojit kritické uvažování.
Aha, takže Linux, který přepsal komerční Unixy jedno volání API po druhém, koncept po konceptu, jednu stránku dokumentace po druhé, je to "kernel napsaný na zelené louce". Ovšem když autoři NT použijí nějakou terminologii a pár konceptů ze své předchozí práce, tak "vykradli VMS". Tohle jasně svědčí o tom, že objektivita je vám zcela cizí.
Do Linuxu se dostal kód, o které jsem psal. Problém byl v tom, že společnost SCO Group nebyla schopna doložit copyright k tomu kódu. Některé části byly nezávisle uvolněné pod BSD licencí, další byly napsané na základě starších Unixů a SCO Group nebyla schopna doložit že by šlo o díla odvozená od něčeho na co měla copyright... Na Wikipedii to máte ozdrojované. Můžete si projít jednotlivé soudní pře, včetně soupisu důkazů.
https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes#SCO_allegations_of_copyright_and_trade_secret_violations
Tady bych to asi ukončil, diskuse o vašich subjektivních dojmech mě netáhne.
>>Aha. Takže win32 je zastaralé protože... Nic konkrétního k těm API nejste schopen uvést,
Dobre, tak keď je to nepodložená špekulácia, tak aj s WinRT to bude nepodložená špekulácia, problém s vami, keď pre stromy nevidíte les.
>>Článek o NT v. VMS by mohl popisovat stejnou podobu mezi Unixem a NT.
Nemohol, NT Nevzniklo vykradnutím zdrodových kódov UNIXU a ich prepisom do C. Vzniklo vykradnutím zdrojových kódov VMS a ich prepisom do C. Ale to by ste vedeli, ak by ste ten článok čítali.
Boli až také podobné, že inžinieri z Digitalu, keď pomáhali portovať NT na Alphu, nemali vôbec problém sa v nich orientovať a boli im veľmi známe.
>>To video jsem komentoval, a nechci to dělat znovu. MS implementoval POSIX.1, a ....
Zjavne ste to video nevideli, POSIX v NT nebol použitelný nedalo sa s ním robiť nič, microsoft to zámerne odflákol. To nebolo nič na spôsob, že by programátori boli ufňukaní, to reálne bolo hrozné a nepoužitelné. Bol to žart od microsoftu. Aj tooling bol odfláknutý, bolo treba použiť divný spôsob kompilovania, a nakoniec aj tak aplikácie nešli skompilovať po celej tej tortúre. Pozrite si to video, prosím. Ak by to neodflákli, neexistoval by cygwin. Bodka. Ak to, čo opisuje pán vo videu považujete za normálne, tak potom sa Vám veľmi čudujem, ešte raz sem dám link, je to normálne hands-on video a nie bláboly: https://www.youtube.com/watch?v=BOeku3hDzrM
>>>Aha, takže Linux, který přepsal komerční Unixy jedno volání API po druhém, koncept po konceptu, jednu stránku dokumentace po druhé ...
Mýlite sa, v Linuxe bolo implementované POSIX API, ktoré bolo verejne dostupné a POVINNÉ, ak ste chceli povedzme robiť zakázky pre štát. Ak sa tomu trochu rozumiete, je to iné, než ukradnúť zdrojáky a začať ich prepisovať v tíme, ktorý sa skladá s pôvodných vývojárov VMS, ktorí odišli z firmy DEC. Môžem mať implementované verejné api, ale keď pokradnem internals (Ako to spravil microsoft) je to iné.
>>>Do Linuxu se dostal kód, o které jsem psal. Problém byl v tom, že společnost SCO Group nebyla schopna doložit copyr...
Nedostal, proste nič v rukách nemali, bol to FUD.
>>>Tady bych to asi ukončil, diskuse o vašich subjektivních dojmech mě netáhne.
Škoda, bola s vami sranda, ale ja verím, že aj keď ostentatívne ignorujete napísané a dodané zdroje, tak sa na vás niečo nalepilo.
1. "Zastaralé" Win32 - doložil jste NULA příkladů toho, jak konkrétně je Win32 API zastaralé. WinRT je opět API s vyšší úrovní abstrakce, tentokrát určené pro C++, a usnadňující vzájemné volání mezi kódem psaným v C++ na straně jedné, a C# a ostatními .NET jazyky na straně druhé. Jenže protože neznáte Win32, .NET ani WinRT, tak nemá smysl ani popisovat, jaký problém WinRT řeší.
2. WinNT jako "vykradené VMS" - já ten článek samozřejmě četl. Autor tam používá metaforu (abych použil vaší terminologii), když tvrdí, že vývojáři z MS "přepsali VMS v jazyce C, a při tom začistili, vyladili, poštelovali a přidali novou funcionalitu...". Dokládá to tím, že použili podobnou terminologii, například "process scheduler" (a jak asi plánovači procesů mají říkat?), oba OS podporují SMP (stejně jako i řada Unixů), na VMS je program "BACKUP" a v NT "NT Backup" (jak asi říkat programu který dělá backup?) apod. Nic z toho nevyžaduje přístup ke zdrojákům. Pro vaše obvinění, že autoři NT ukradli zdrojáky VMS, existuje NULA důkazů - ale možná jde zase o metaforu :D. A jestli si myslíte, že je možné napsat OS tak že vezmete úplně jiný OS, psaný pro jiný úplně HW v assembleru, a "přepíšete ho do C", tak to jen ukazuje, jak moc jste mimo. Zvlášť když se ty OS liší v architektuře (monolitický kernel vs. modifikovaný mikrokernel), resource protection (VMS používá tři protection rings, NT dva), API, použitých datových typech (NT používají UTF-16 stringy) atd.
3. POSIX v NT. To video jsem samozřejmě viděl. Proto jsem o tom napsal tisíc znaků. POSIX subsystem nabízel API, nikoliv tooling. Ten byl součástí SDK a částečně Resource Kitu. "Divný způsob kompilace" byl daný tím, že POSIX aplikace mohly zavádět jen POSIX procesy, takže tam byl wrapper. A kompilovat samozřejmě šlo, akorát jste musel kompilovat to co používalo výhradně POSIX API. Přesně proto jsem vám psal, že si máte zkusit zkompilovat aplikace pro Linux (nejlépe o pár let novější než OS na kterém je budete překládat) na BSD, nebo třeba AIXu, abyste viděl, že to dopadne velmi podobně. Jenže to byste musel číst a chápat, co píšu. Pokud jde o Cygwin nebo Services for Unix, tak obojí prostě podporuje víc než jen čistý POSIX.1. To ovšem jaksi není pro certifikaci POSIX compliance potřeba.
4. Linus psal, že psal Linux podle dokumentace komerčních Unixů. Nikdo ho nenutil otrocky reimplementovat podle dokumentace funkci po funkci, byla to jeho volba. Linux je prostě opis komerčních Unixů, jedna ku jedné.
Hrach o stenu. K ostatnému sa nevyjadrujem, najmä k POSIX vo WINNT, ste stratený prípad.
Ale k tomuto sa vyjadrím:
>>>Linux je prostě opis komerčních Unixů, jedna ku jedné.
Nie je to opis komerčných unixov 1:1, ani nemôže byť. Linus k takému nemal prístup. Inšpiroval sa minixom a to nebol komerčný unix, bol to výčbový projekt, ktorý sa dodával ku knihe. Ale ani ten neprepisoval, lebo linux mal inú filozofiu. Keď si pozriete rodostrom unixov, tak Linux do neho nepatrí, dodávam obrázok.
https://en.wikipedia.org/wiki/History_of_Unix#/media/File:Unix_history-simple.svg
Všimnite si tam zaradenie napríklad FreeBSD, ktoré vznikalo vami opisovaným spôsobom.
Zjavne si pletiete operačný systém GNU a Linux. Ale ani GNU nevznikalo prepisom komerčných aplikácii. GNU vznikalo pôvodne ako sada nástrojov pre komerčné unixy. Na komerčných unixoch bol problém, že ich bolo veľa a každý si na nich robil veci po svojom, ani utility neboli kompatibilné. Nainštalovaním GNU vtedy človek paradoxne získal unifikovaný interface s možnosťou úpravy kódu podľa seba, čo bolo nevídané. Keď sa vytváral štandard POSIX, tak sa vytváral podľa GNU, lebo to bol podporovaný multiplatformný softvér. Následne už dokázal existovať štandard POSIX sám o sebe a GNU sa muselo začať podriaďovať POSIXu.
Je pekné, že ste si obrátili kauzalitu a tvrdíte nezmysly. No preto nemá "Linux" právne problémy, okrém pár vymyslených FUD-ov a trollich monsterprocesov.
Jak konkrétně byla SCO Group, která vedla ty soudní spory, s Microsoftem propojená pomocí IP a majetkově? Nebojte se být konkrétní :). Jinak směšné je nazývat jednu firmu divizí jiné firmy, když tomu tak technicky není. Je to jako když si zadřete do prstu třísku, a mluvíte o tom, že máte zlomenou ruku. Nemáte, jde o dvě různé věci.
Ako konkrétne - ohľadom IP - ich UNIX obsahoval inovácie vymyslené samotným microsoftom, nebol to vanilla UNIX od AT&T, ani BSD UNIX. Koncom 80-tych rokov, kúpil Microsoft podiel v SCO. V čase, keď sa robili predátorské súdne spory, t.j. 2003, nakúpil Microsoft licencie SCO UNIX-u za cca 12 miliónov eur (nepamätám si presne), neviem, čo tým chceli robiť, asi mal Ballmer tajne v pivnici unixový cluster s obrovským počtom nód a hral na tom reversi ... , whatever. Jasné, že to bolo financovanie trollingu SCO.
Je to dosť konkrétne? Bola to asi tak nezávislá firma, ako je Bielorusko nezávislé na Rusku. Divíziu ofc berte ako metaforu naznačujúcu silné prepojenie. Bola to de facto divízia, určená prevažne na trolling. Ináč by už ani neexistovala.
Ano, koncem 80. let MS na nějakou dobu koupil 20% podíl v Santa Cruz Operation. Už jsme si ale vysvětlovali (a vy jste to zjevně nepochytil), že SCO Group, která vedla ty soudní spory, není Santa Cruz Operation, ve které MS měl kdysi dočasně minoritní podíl.
Ano, MS koupil od SCO licenci za cca 8-16 milionů USD. Těch zákazníků bylo víc, a úplně první byl údajně Sun Microsystems. Nejspíš také chtěl skrytě zlikvidovat Linux ;). Další byl například hosting provider EV1Servers, který běžel 20 000 serverů. SCO Group chtěla pro ilustraci $699 za každé jádro CPU, na kterém běžel Linux. Obeslali minimálně tisíc zákazníků, ale bohužel nevím, kolik jich opravdu zaplatilo. Šlo ale minimálně o miliony dolarů, spíš o desítky.
https://www.cnet.com/tech/services-and-software/sun-expands-unix-deal-with-sco/
Je možné, že MS licenci koupil proto aby společnosti SCO "nabil" pro jednání s dalšími firmami? Je to samozřejmě možné, protože každý businessman ví, že když krvácí konkurent, tak je to dobré. Dělá to z SCO Group divizi Microsoftu? Možná leda ve vašich metaforách ;). Pokud hledáte opravdový důvod, proč SCO Group šla do těch soudů, tak si uvědomte, že akcie té firmy byly v prosinci 2002 za $1.50 a směřovala k bankrotu. V půlce října 2003 byly akcie po $22.29. Kdo je včas koupil (a včas se jich zbavil než znovu spadly), tak vydělal balík. Nutno ovšem dodat, že tehdejší CEO Darl McBride byl v roce 2009 vyhozen poté co firma zbankrotovala. Pustil se do jiného businessu, a v roce 2020 vyhlásil osobní bankrot.
Neni pravděpodobnější, že IBM zabalí AIX, protože na tom běží celý jejich portfolio včetně projektu qvantum. U kvantového akcelerátoru by to znamenalo přepsat veškerý kód a začít opravdu od úplného začátku. Proto se můžete setkat u kvantových akcelerátorů s AIX.
HP-UX dejme tomu, jedinej zádrhel může být oblast super počítačů.
Solaris je opravdu svým způsobem všude a třeba afrika na tom zásadně jede, včetně velké části asie nebo se můžem ve velkém setkat v USA nebo kanadě...
Problém těchto zmíněných příkladů jsou záměry na velmi specifické zákazníky, nebo odvětví, kdy změna znamená obrovský problem. V případě Win je to půl na půl.
Není mi jasné, proč by kvantový akcelerátor nemohl běžet na Linuxu namísto AIXu, a proč by bylo nutné přepsat veškerý kód. Ale rád se dozvím, kde konkrétně by podle vás měl být zádrhel.
Superpočítače jsou dneska převážně výpočetní gridy, a tam je úplně jedno, jaký OS běží na nodech. Samozřejmě firmy mají spoustu know-how a kódu, ale opět mi uniká, co konkrétně by mělo bránit přechodu na Linux.
Solaris samozřejmě běží na pár instalacích. To slovo "pár" je ve srovnání s Windows nebo Linuxem, ale jsou to poměrně velké instalace. Ovšem SPARC je podle všeho mrtvý, poslední model CPU vyšel v roce 2017, Fujitsu už migrovalo na ARM. Zbývající HW pro Solaris je na x86-64, a může s klidem běžet na Linuxu. Ano, Solaris je lepší Unix než Linux, ale opět nevidím důvod, proč by Oracle nemohl chybějící funkcionalitu dolepit do Linuxu, zvláště kdy k ní má zdrojáky.
Váš argument byl, že "když firma nemá peníze tak to stagnuje". S IBM to jde od devíti k pěti, resp. od cca 100 miliard dolarů tržeb k pouhým 61 v roce 2023. HPE se od rozdělení HP potácí, minulý rok tržby 29.14 miliard. Oracle jako jediný z té trojice alespoň trochu roste, ale nic moc. Všechny tři ty firmy mají dohromady tržby jako dvě třetiny Microsoftu, ale každá z nich vyvíjí svůj vlastní Unix. Připomíná mi to tři kohouty, kteří na smetišti bojují o jednu poslední žížalu. Roli jejich OS totiž u dlouhé řady zákazníků dávno převzal Linux. Sakra, už i ten SAP, který je tak konzervativní, že vždycky čekám kde se na mě začnou sypat děrné štítky, napsal HANA in-memory DB specificky pro Linux. A to znamená, že na Linux migrují všichni jeho zákazníci. Co víc k AIXu, HP-UX a Solarisu? Snad jen jedno: poslední ať zhasne.
Nepsal jsem to ve stylu agumentum ad absurdum. Za mě opravdu tzv. "profesionální" Unixy už dlouho umírají.
V devadesátých letech jejich trh poprvé zbouraly Windows NT. Do té doby když firma chtěla server, připojení k pobočkám, mail, nebo prakticky cokoliv jiného, tak to automaticky znamenalo Unix. Chcete server? Zavolejte našeho obchodníka, on přijede nebo přiletí, vše s vámi probere, a vypracuje nabídku, jako kdybyste chtěl postavit raketoplán - i za podobnou cenu :/. Když se začaly prodávat servery na Windows NT, najednou jsme měli směšně levný HW, ceníky, výběr ze spousty dodavatelů HW, obrovskou nabídku aplikací, SDK zdarma a celou MSDN za pár dolarů... Za cenu výměny disku v serveru běžícím na HP-UX jste mohl mít Windows server s podobným výkonem a úložnou kapacitou, včetně OS a roční podpory. Za cenu prakticky jakéhokoliv serverového SW pro "profi" Unix jste mohl koupit lepší serverový SW pro Widows Server, desktopový SW pro celou firmu, a ještě si zaletět na dovolenou do Karibiku.
Unixům v podstatě zbyly dvě bašty: velmi konzervativní zákazníci, a zákazníci jejichž nároky nebyl schopen uspokojit HW běžící na Intelu. Tu první kategorii zboural Linux, protože to znamená zůstat "tradičně" na Unix(-like) OS, a hodně ušetřit. Akcelerovalo to s tím, jak se Linux portoval SW typu Oracle, SAP apod. Prakticky všechno, co můžete mít na Unixu, můžete mít dávno i na Linuxu. Ta druhá kategorie vymírala s tím, jak Intel HW pokrýval potřeby čím dál větší části zákazníků. High availability clustering? Už je i ve Windows, další část zákazníků přešla. Velké paměťové nároky a 64-bitový OS? Už je na Windows i na Linuxu, další část zákazníků přešla. A takhle výrobci Unixů dodnes prožívají smrt tisíci řezy. Za mě ty firmy mají přesně to, co si za své chování v osmdesátkách a devadesátkách zaslouží.
To že v HPe zabalili HP-UX jsem fakt nevěděl. Přejít na Itanium se ve zpětném zrcátku jeví jako skočit bungee a zapomenout se přivázat. Přechod na x64 asi nemá smysl, protože úprku zákazníků na Linux už nemá přechod kdo zaplatit, a hlavně trh pro další Unix a Unix-like OS pro platformu x64 je velmi malý.
Na druhé straně je to celé trochu smutné. Možná bych si měl nějaký vyřazovaný box s HP-UX koupit, s tím že ho jednou budu při zvláštních příležitostech bootovat a ukazovat užaslým vnoučatům SAM a CDE :)
S Windows serverovymi rieseniami nemam prilis velke skusenosti. Tak isto som rozmaznany velkym korporatom kde sa podpisovali skutocne velke dealy a teda vymena disku je drobne na pivo. Mnohi nasi zakaznici mali golden contract, tam sa platili mesacne skutocne ine palky.
Vyhoda ale bola v stabilite. Spravne nasetupovany HP-UX proste siel (samozrejme malo to svoje bugy). Oracle/SAP v bankach, vyrobcovia lietadiel, autopriemysel a pod --- nebolo o com. Clustrove riesenia, kde backend robia high end storage. Sila mala byt v paralelnom spracovani dat prave na oracle.
Ano, dnes ked musim patchovat HP-UX tak si trieskam hlavu o stol ake je to pomale (i6 cpu). Ale vyvoj HP-UX zastal v 11.31, prva relase 2007, niekedy kolo 2014-2015 to uz bolo jasne, ze je koniec. V case prvych migracii z HP-UX na Linux to bol cisty pain. Nemalo ani zmysel sa pozerat, ze preco sa zase Linux zosypal - proste reboot a ide sa.
Dnes je to ale uz ine, Linux na toto skutocne dozrel, dobehol a aj predbehol vo vela veciach.
11.11 sa da uz celkom ok spustit v qemu (pa-risc verzia)
8. 7. 2024, 22:58 editováno autorem komentáře
Been there, done that, got the T-shirt. Kontrakty na každý server jak na stavbu raketoplánu, dárky pro managery u zákazníka ve výši jejich měsíčního platu a více, tahání top managerů od zákazníků na různé akce snad po všech kontinentech vyjma Antarktidy, různé druhy "všimného" decision makerům za uzavření kontraktu... A teď si představte, že za ty "drobné na pivo", na které vyjde výměna disku, najednou koupíte celý server i s roční podporou, protože výrobci PC HW a SW nemají nemravné zisky a neutrácejí za... různé druhy všimného. HW je najednou od více dodavatelů, transparentně, rychle, jako když si kupujete vysavač a ne raketoplán. I u těch původně čistě unixových zákazníků, kde nakonec zůstane řekněme HP-UX, najednou připadá na jeden HP-UX deset Windows Serverů, a později se začnou množit i ty linuxové. To jste určitě viděl u těch bank, výrobců letadel, v autoprůmyslu, energetice, u těžařů atd. A já navíc (asi na rozdíl od většiny čtenářů tohoto serveru) viděl řadu případů, kde ve firmách v tomto tržním sektoru žádný Unix nezůstal. Banky jsou, pravda, mimořádně konzervativní, a nějaký Unix se u nich většinou (ale ne vždy) najde.
Pokud jde o stabilitu, tak s tou jsem kupodivu na serverech s Windows nikdy neviděl větší problém. Jasně, někdy odejde HW, který zrovna není redundantní. Nebo spadne aplikace na HA clusteru, najede node B, a tam se situace opakuje, protože je problém v datech nebo DB. U Linuxu jsem párkrát viděl takové speciality, jako ztrátu dat na SW RAIDu, který zákazník použil, protože chtěl ušetřit. Ale předpokládám, že u RHEL a SLES se situace časem zlepšila.
QEMU jako fajn (bez ironie), ale nejsem si jistý, jestli je to řešení pro migraci produkčního prostředí. Navíc většina aplikací pro HP-UX stejně existuje i pro Linux, takže je asi snazší migrovat na nativní Linux.
To máte zřejmě na mysli přesun části GDI do win32k.sys (nikoliv .dll). Tenhle přesun snížil overhead volání grafického subsystému, a tím výrazně zvedl jeho výkon.
Pokud bych měl v těch letech na starosti architekturu NT, a mohl si vybrat mezi tím, aby diskutér Wasper považoval NT kernel za "pejsek s kočičkou NEvařili dort", nebo výrazně zvýšil výkon grafického subsystému, tak si vyberu to druhé ;)
Tak v tom případě navrhuji test po fyzikářsku - experimentem. Pozveme někam tehdejší windows a citrix adminy, rozdáme jim středověké zbraně , já budu tvrdit, že to bylo nekoncepční hloupost, vy budete tvrdit to co tvrdíte. A oni si vzpomenou na tehdejší bezesné noci.
(hint: Ono to do kernel space rvalo i printer drivery. *mává na Minoltu*)
O prasárně stylu UAE přelepené přes klasická ACL práva se radši ani nezmiňovat (užitečnější virtualizovat fs se to co si pamatuju naučilo až mnohem později)
Ono hlavně nemělo (a nemá) smysl psát plné drivery tiskárny, když bylo možné použít univerzální driver od výrobce OS (v NT4 Raster Device Driver aka RASDD), a dodat k němu DLL s parametry. Pokud se někdo "chytře" rozhodl znovu vynalézat kolo a psát PCL nebo PS driver, a neuměl to, tak mohl být výsledek pochopitelně špatný.
Ale navrhuji jiný experiment, pozveme vývojáře aplikací. Ať s těmi středověkými zbraněmi kvalifikovaně své preference. Buď GDI, kde mohou jedním API kreslit po obrazovce, tiskárně, plotru apod. A nebo X11, s tím výkonem a API, včetně například font serveru, k tomu LPD a "dodělej si sám". Mám za to, že se k otázce grafického subsystému v době uvedení NT4 vyjádří... s drtivou převahou :) ve prospěch NT.
Zřejmě máte na mysli UAC, nikoliv UAE, navíc to není věc kernelu. Je to čistě důsledek toho, že Windows provozují často lidé, kteří si je i administrují, a proto jedou celou dobu s právy admina. Proto se uživatelův security token "rozdvojí", s tím že jede pod tím limitovaným, a teprve pokud akce vyžaduje práva admina, tak se to potvrdí pomocí UAC Elevation Prompt. Nelíbí se vám to? Vypněte si UAC.
Mimochodem, jste si vědom toho (tuhle diskusi jsme před 15 lety vedli na Mageu, ze pane Srnka...) že architektura i386 nemá jen user/supervisor, ale má 4 priority levely (ringy) + IOPL, takže i to, když chcete něco dát do privilegovaného kódu, tak se to nemusí strčit zrovna do kernelové nuly kde chyba = BSOD.
Takže fakt to není stabilita/výkon, ale spíš zprasený výkon.
O jakém zvířeti to tu mluvíte? Pokud nějaké potkáte, tak ho nezapomeňte nakrmit :)
Ano, architektura i386 má více protection rings. A z nějakého důvodu Windows, Linux a MacOS používají jen dva: ring 0 a ring 3. Proč? Například protože ring, ve kterém kód běží, je určen na základě segmentu. To vylučuje větší granularitu, například na základě memory page. Moderní OS z dobrých důvodů segmentové adresování prakticky ignorují. Kdo se neoklepe při vzpomínce na segmentování na 8086/8088? Dnešní OS tedy při startu prostě vytvoří segmenty začínající na offsetu 0, a s maximální velikosti. Navíc pokud jde o ochranu paměti na úrovni stránky, tak tabulka PTE má jeden bit indikující že je memory page "privileged", a to zahrnuje ring 0, 1 a 2. To maže většinu relevantních rozdílů mezi ringy 0, 1 a 2. Dále kód v ringu 1 nebo 2 bude logicky používat vyšší počet mode transitions, a tím pádem bude pomalejší. Hlavně jsou ale protection rings silně závislé na konkrétní platformě. Portabilní OS, jako jsou Windows řady NT (fungující v principu na Intel i860, x86, DEC Alpha, MIPS, PowerPC, SPARC, Itanium, x64 a ARM), bude těžko řešit různě stavěné protection rings každé jednotlivé platformy. Například Dec Alpha a MIPS mají jen dva protection rings. ARM má dva (plus podporu virtualizace, u Intelu "ring -1"), ovšem podle dokumentace jsou to zřejmě processor modes, a ne protection rings, což je dost výrazný rozdíl. A ještě bych dodal, že Intel ve svém návrhu architektury x86S, očištěné o historický balast, navrhuje ring 1 a 2 odstranit. Nikdo je totiž nepoužívá.