Názory k článku
Chromium 45 se zbaví kontroverzního binárního modulu

Gnome3 zavedl do desktopu "tablet-user-dummyness" přístup, který tam nemá co dělat. Kvůli Gnome3 jsem přestal používat Gnome.

Ad k dílu se přikládá ruka na základě dobrovolnosti a ne na základě finanční částky na účtu - fakt?
LinuxThreads platila Linux Foundation (které má toho času příjem minimálně $6M ročně), NPTL RedHat, NGPT IBM, X11.org X.Org Foundation, Mir Canonical, SurfaceFlinger Google, GTK The Gnome Foundation, Qt Digia, systemd RedHat, upstart Canonical.

Ad každý dělá to, co považuje za nejlepší; kdyby všichni táhli za jeden provaz - oni táhnou každý za jiný kus provazu, a každý jiným směrem. A je to těžce neefektivní. Snad jediné na čem se dokážou ve FOSS různé skupiny shodnout je to, co zdědily ze světa tradičních Unixů. To nakonec můžete vidět u tragického X11, které ani dekády onoho "dělání toho co každý jedinec považuje za nejlepší" nedokázalo nahradit něčím použitelným. Tenhle chaotický vývoj Linux jednoznačně poškozuje.

Tenhle chaotický vývoj Linux jednoznačně poškozuje.

Zato systematický vývoj stylem CTRL+C/CTRL+V v produktech MS, kdy jedna a ta samá díra je ve všech verzích Windows/Office počínaje těmi 15 let starými, to je vrchol dokonalosti.

Hele, Pytlíku, co kdybys už konečně šel svoje moudra trousit jinam? Doporučuju třeba nějakou útulnou záchodovou mísu.

Ad co myslíte, že dělají ty OSS projekty - jak se liší zaměření Waylandu a Miru, nebo systemd a upstart, NGPT a NPTL? Vždyť dělají totéž, jen jinak.

Ad Jako třeba Win32 API, .NET a WinRT - to je dost odlišná situace. Win32 je low-level API. Naproti tomu .NET je zamyšlený jako high level Framework. WinRT je pokračováním .NETu, a navíc spojuje "tradiční" C++ s .NETem. Navíc jde o API uvedené v letech 1993, 2000 a 2012, a všechny se používají.

co nechapete na tom ze ty projekty maji jinou vizi a nikdo je nebude nasilim nutit aby se prizpusobili vizi toho druheho, mate vy svobodnou volbu forknout windows a nektere jeho casti nahradit forkama tech casti, nebo necim uplne jinym postavenym od zakladu, nebo z kombinaci ostatniho? nemate, nechapete, tak jdete placat babovicky nekam jinam, tady vam to bahno vazne nikdo nezere :)

Ad projekty maji jinou vizi a nikdo je nebude nasilim nutit aby se prizpusobili vizi toho druheho - při vývoji SW se zpravidla moc násilí nepáchá :)

Ad forknout windows a nektere jeho casti nahradit forkama tech casti, nebo necim uplne jinym postavenym od zakladu, nebo z kombinaci ostatního - ve Windows můžete nahrazovat spoustu věcí, a to do té míry, že beze změny jediné řádky zdrojáku můžete třeba implementovat hard RTOS. Ale to vůbec není pointa. Pointa je v tom, že model vývoje použitý na platformě Linux zjevně nefunguje. Jak už jsem psal, například X11 je několik desítek let přežitá katastrofa, jeho náhradou se zabývalo už nevím kolik projektů, spálilo se na tom nepočítaně člověko-let, a přitom to pořád nepřineslo výsledek. Jaká konkrétní výhoda podle vás v tomto případě vyplývá z té řady odlišných vizí, ve světle toho že se za pár dekád nepodařilo ani jednu z nich završit? Navíc je nejblíže završení projekt Wayland, který ani nemá network transparency.

Pokud hovoříte o "svobodě", tak si uvědomte, že fragmentace má velmi negativní následky pro uživatele i vývojáře. Čím víc dílků skládačky se stejnou funkcí, tím víc se zbytečně propálí úsilí na vývoj, tím méně je výsledek testovaný, a tím obtížněji je platforma použitelná pro vývojáře.

Mimochodem nejsem jediný, kdo pojmenovává tenhle problém. Stejně to vidí i spousta uživatelů Linuxu.

ve Windows můžete nahrazovat spoustu věcí, a to do té míry, že beze změny jediné řádky zdrojáku můžete třeba implementovat hard RTOS

To se týká jen Windows Embedded, který nemá ty samé zdrojáky jako desktopové Windows. Například obsahuje ještě lepší OOM handler než linuxový OOM killer: při nedostatku paměti vytuhne celý systém.

Jak už jsem psal, například X11 je několik desítek let přežitá katastrofa, jeho náhradou se zabývalo už nevím kolik projektů, spálilo se na tom nepočítaně člověko-let, a přitom to pořád nepřineslo výsledek

A já na mobilu nemám Wayland a X11 na mém počítači se pořád musí nastavovat. Zkuste trochu méně trollovat.

Navíc je nejblíže završení projekt Wayland, který ani nemá network transparency.

No hlavně že Windows ji mají ;-)

Pokud hovoříte o "svobodě", tak si uvědomte, že fragmentace má velmi negativní následky pro uživatele i vývojáře.

MS na tom se svými zahozenými projekty není o nic lépe. Bob, Windows Neptune, WinFS, Palladium, transakční NTFS…

Ad se týká jen Windows Embedded, který nemá ty samé zdrojáky jako desktopové Windows - to se týká jakékoliv verze Windows řady NT. Zdrojáky Windows Embedded jsou převážně stejné jako u desktopové verze. Liší se některými součástmi (například Unified Write Filter), a tím že si můžete podrobně vybrat sadu instalovaných komponent v GUI.

Ad obsahuje ještě lepší OOM handler než linuxový OOM killer; při nedostatku paměti vytuhne celý systém - jednak jde o opravenou chybu, a pak linkujete Windows Embedded Compact, známé též jako Windows CE.

Ad já na mobilu nemám Wayland a X11 na mém počítači se pořád musí nastavovat - a?

Ad network transparency; hlavně že Windows ji mají - slyšel jste někdy o RDP?

Ad MS na tom se svými zahozenými projekty není o nic lépe.
- Bob - to byl alternativní shell
- Windows Neptune - takový produkt MS nikdy nevydal
- WinFS - takový produkt MS nikdy nevydal
- Palladium - takový produkt MS nikdy nevydal
- transakční NTFS - to je pořád podporované

to se týká jakékoliv verze Windows řady NT

Že o tom MS neví? Protože hard RTOS uvádí jen pro Windows Embedded.

Zdrojáky Windows Embedded jsou převážně stejné jako u desktopové verze. Liší se některými součástmi (například Unified Write Filter), a tím že si můžete podrobně vybrat sadu instalovaných komponent v GUI.

Takže bez změny jediné řádky zdrojáku znamená, že přidané řádky nepočítáte mezi změny. To jenom abychom si rozuměli. Takový RTLinux je tedy také bez změny jediné řádky zdrojáku.

Ad já na mobilu nemám Wayland a X11 na mém počítači se pořád musí nastavovat - a?

Doufal jsem, že když uvádím, na co reaguji, tak vás to třeba trkne. X11 dnes není ten samý, co před desítkami let, a Wayland evidentně funguje, takže ty „propálené člověko-roky“ mají výsledek.

slyšel jste někdy o RDP?

RDP je zadrátované v GDI? Já myslel, že je to samostatný vykreslovací backend. Wayland v sobě síťovou transparentnost nemá, protože to v jeho architektuře řeší kompozitor. Má to tu výhodu, že klient nemusí být Wayland.

takový produkt MS nikdy nevydal

Ale vyvíjel a propálil na tom mnoho člověko-let.

transakční NTFS - to je pořád podporované

Jenže nebude. Takže pro komerční vývoj jako by neexistoval.

Ad o tom MS neví? Protože hard RTOS uvádí jen pro Windows Embedded - z Windows řady NT se dá udělat RTOS beze změny zdrojáku WinNT. Například se dá nahradit HAL.

Ad X11 dnes není ten samý, co před desítkami let, a Wayland evidentně funguje - X11 má v principu pořád ty samé problémy: kryptický a nezabezpečený protokol, příšernou klientskou knihovnu, potřebu spousty round tripů, přehršel špatně dokumentovaných extensions, a to že podporuje jen obrazovku (žádné tiskárny, plottery). K tomu se časem nabaluje víc a víc funkcionality, takže se ta bažina prohlubuje.
Ad Wayland evidentně funguje - které distro funguje na Waylandu? A které distro se zbavilo kompatibility s X11?

Ad RDP je zadrátované v GDI? - z hlediska GDI je RDP jen driver zařízení, do kterého kreslí stejně jako by to byl driver lokální grafické karty. Design GDI navíc umožnuje driveru označit capabilities, resp. podporované operace. Jeden driver může podporovat jen zobrazení (nebo tisk) bitmapy, jiný může umět třeba cachovat bitmapy, kreslit obdélníky, křivky, rastrovat text atd. GDI pak používá tu sadu operací podporovanou driverem, a ostatní operace na převádí na ty podporované. To umožňuje použít jak RDP klienta s plnou podporou operací (například Windows nebo Wyse/Dell), tak například jednoduchého open source klienta který umí jen zobrazovat bitmapy.

Ad Wayland... v jeho architektuře řeší kompozitor - pokud jsem správně četl, tak neřeší, ale jednou by to snad možná řešit mohl. Mimochodem kompozitory pro Wayland používají OpenGL, které letos umřelo a bylo do budoucna nahrazeno pomocí API Vulcan.

Ad takový produkt MS nikdy nevydal; Ale vyvíjel a propálil na tom mnoho člověko-let - on MS také většinou části těch projektů použije jinde. Například části WinFS skončily v MS SQL Serveru a ADO.NET.

Ad transakční NTFS to je pořád podporované; Jenže nebude - cituji z linku: Microsoft is considering deprecating TxF APIs in a future version of Windows. To bych nepřeložil jako "nebude".

z Windows řady NT se dá udělat RTOS beze změny zdrojáku WinNT. Například se dá nahradit HAL

Náhradní HAL asi vykouzlíte, když není třeba nic napsat.

X11 má v principu pořád ty samé problémy: kryptický a nezabezpečený protokol, příšernou klientskou knihovnu, potřebu spousty round tripů, přehršel špatně dokumentovaných extensions, a to že podporuje jen obrazovku (žádné tiskárny, plottery). K tomu se časem nabaluje víc a víc funkcionality, takže se ta bažina prohlubuje.

Kryptický a nezabezpečený protokol. Že to říká někdo, kdo preferuje řešení MS.

Příšernou klientskou knihovnou je i GDI. Proto to nikdo soudný nepoužívá přímo, ale použije toolkit.

Spousty round tripů? To jako kterých?

Podporuje jen výstup na obrazovku, protože je to překvapivě server pro kreslení na obrazovku, nikoliv aplikace, co dělá všechno. Toolkity většinou umí tisknout WYSIWYG.

které distro funguje na Waylandu? A které distro se zbavilo kompatibility s X11?

Třeba Debian. Na mobilu mám Sailfish.

Které Windows se zbavily kompatibility s Windows 3.1?

z hlediska GDI je RDP jen driver zařízení, do kterého kreslí stejně jako by to byl driver lokální grafické karty

Ale vždyť takhle to funguje i u Waylandu. Kompositor se stará o kreslení na obrazovku. Nebo posílání přes síť. Nebo může tisknout.

pokud jsem správně četl, tak neřeší, ale jednou by to snad možná řešit mohl.

O kterém kompozitoru jste to četl? On totiž není jen jeden.

Mimochodem kompozitory pro Wayland používají OpenGL, které letos umřelo a bylo do budoucna nahrazeno pomocí API Vulcan.

Kompozitory pro Wayland mohou používat, co uznají za vhodné. Kromě OpenGL se používá i Cairo, klidně mohou používat i Vulcan nebo (když to někdo portuje na Windows) GDI.

on MS také většinou části těch projektů použije jinde. Například části WinFS skončily v MS SQL Serveru a ADO.NET.

Takže bazaar?

Microsoft is considering deprecating TxF APIs in a future version of Windows. To bych nepřeložil jako "nebude"

Já bych to přeložil jako „nepoužívejte to ve svém software“.

Ad Náhradní HAL asi vykouzlíte, když není třeba nic napsat - opakuji: nemusíte u toho měnit zdroják Windows. Není potřeba ani jeho rekompilace.

Ad Příšernou klientskou knihovnou je i GDI. Proto to nikdo soudný nepoužívá přímo, ale použije toolkit. - GDI je naopak k vývojáři poměrně přátelské, jeho funkce jsou rozumně použitelné a dobře dokumentované.
https://msdn.microsoft.com/en-us/library/aa923590.aspx

Ad X11, Spousty round tripů? To jako kterých? - zkuste si přečíst tohle:
http://www.informit.com/articles/article.aspx?p=1395423

Ad které distro funguje na Waylandu? Třeba Debian - fakt? Pokud jsem si všiml, tak Debian by default používá X11. A pokud mluvíte o nedovařených experimentech, tak ty jsou nedovařené a experimentální.

Ad Které Windows se zbavily kompatibility s Windows 3.1? - všechny 64-bitové Windows.

Ad takhle to funguje i u Waylandu. Kompositor se stará o kreslení na obrazovku. Nebo posílání přes síť. Nebo může tisknout - a existuje vůbec nějaký kompozitor, který by řešil vzdálený přístup? Já o něm nevím.

Ad Kompozitory pro Wayland mohou používat, co uznají za vhodné - zatím používají Cairo a OpenGL. Jsem zvědavý, kdy se naučí Vulcan nebo cokoliv jiného.

Ad části WinFS skončily v MS SQL Serveru a ADO.NET; Takže bazaar? - code reuse is good practice.

Ad TxF; Já bych to přeložil jako „nepoužívejte to ve svém software“ - to byste přeložil správně. Jenže to je něco jiného, než vaše původní tvrzení o zahozeném projektu.

jak se liší zaměření Waylandu a Miru

Podle Canonicalu nesplňuje Wayland jejich požadavky. V Miru je na rozdíl od Waylandu např. privilegovaný shell a jeho rozhraní je součást specifikace.

systemd a upstart

systemd se snaží být univerzální řešení, upstart bylo jednoduché a rychlé řešení pro Ubuntu. Asi jako Windows Mobile a Embedded. Nebo Windows 9x a NT. Nebo Windows Phone a RT. Všimněte si, že když se systemd stal dostatečně stabilním, Ubuntu upstart zahodilo.

NGPT a NPTL

Zase to samé, NGPT bylo pro jádro 2.4, NPTL pro 2.6.

navíc spojuje "tradiční" C++ s .NETem

O WinRT bych netvrdil, že je to tradiční C++, když se ani nedá jako C++ zkompilovat a ani nepoužívá STL.

všechny se používají

Ty služby v Linuxu se taky používají.

Ad Podle Canonicalu nesplňuje Wayland jejich požadavky - protože si každý vyvíjí svoje podle svých potřeb a bez jakékoliv koordinace. Jde jednoznačně o tříštění sil.

Ad systemd se snaží být univerzální řešení, upstart bylo jednoduché a rychlé řešení pro Ubuntu - což ústí v chaos, kde je prakticky nemožné na daném sytému zjistit například jaké deamony máte nainstalované a jestli běží, protože se to zjišťuje na různých distribucích (nemluvě o různých Unixech) různě. Je to špatné pro adminy, špatné pro uživatele a špatné pro autory aplikací.

Ad NGPT bylo pro jádro 2.4, NPTL pro 2.6 - šlo o dva prakticky nezávislé projekty, o dvě snahy o nahrazení příšernosti zvané LinuxThreads. To samozřejmě opakovaně rozbilo zpětnou kompatibilitu. Opět zbytečné tříštění sil, a opět je to špatné pro adminy, uživatele i autory aplikací.

Ad WinRT bych netvrdil, že je to tradiční C++, když se ani nedá jako C++ zkompilovat a ani nepoužívá STL - OK, tradiční můžete dát do uvozovek.

protože si každý vyvíjí svoje podle svých potřeb a bez jakékoliv koordinace. Jde jednoznačně o tříštění sil.

Stejně jako jde o tříštění sil třeba u C# a C++/CX (vs. C++), OOXML (vs. ODF), SSDP (vs. mDNS), ActiveX (vs. NPAPI), exFAT (vs. UDF) a Win32 API (vs. POSIX).

což ústí v chaos, kde je prakticky nemožné na daném sytému zjistit například jaké deamony máte nainstalované a jestli běží, protože se to zjišťuje na různých distribucích (nemluvě o různých Unixech) různě

upstart a systemd jsou celkem kompatibilní, a oba jdou používat pomocí příkazů pro sysvinit.

Takové Ovládací panely ve Windows na tom nejsou o moc lépe. V každé verzi Windows to funguje jinak.

šlo o dva prakticky nezávislé projekty, o dvě snahy o nahrazení příšernosti zvané LinuxThreads. To samozřejmě opakovaně rozbilo zpětnou kompatibilitu. Opět zbytečné tříštění sil, a opět je to špatné pro adminy, uživatele i autory aplikací.

V čem to rozbilo zpětnou kompatibilitu? V čem to bylo špatné pro uživatele či autory aplikací? Oboje byla implementace POSIX threads a oboje mělo stejné API.

Ad Stejně jako jde o tříštění sil třeba u... - jistě, to je také v řadě případů tříštění sil. Dokážu ale pochopit, proč si různé firmy jedou po svém: konkurují si. Jenže proč by si měly konkurovat týmy stavějící jeden systém pro 1% desktopových uživatelů? Vždyť to působí jako kdyby malosériový výrobce automobilů dodával vůz s jedním světlometem na střeše vozu a druhým vestavěným v sedadle spolujezdce, protože spolu soutěžilo těch pár lidí co vůz stavěli, a pravá ruka nevěděla co dělá levá.

Ad upstart a systemd jsou celkem kompatibilní, a oba jdou používat pomocí příkazů pro sysvinit - ovšem těch náhrad za initd je o trochu víc, a ovládají se různě. A aby to bylo zajímavější, většina z nich nemá ani tak základní věc, jako je API.

Ad nahrazení příšernosti zvané LinuxThreads; v čem to rozbilo zpětnou kompatibilitu? - například signal handling se dost liší. BTW LinuxThreads nebyly POSIX compliant. Migraci na NPTL by ale mohlo usnadnit to že LinuxThreads byly tak špatné, že se používaly velmi málo, takže nebylo moc co migrovat :)