Názory k článku Michal Krause: na desktopu mám Mac, ale Linux jsem neopustil

Ten poslední odstavec je úsměvný - jako školitel a lektor se pohybuji mezi docela velkým spektrem vývojářů a vysoká produktivita vývojářů na windows - to se snad ani nedá komentovat. Korporace Unix masivně používali pouze na serverech, a tam povětšinou zůstal - jen komerční Unixy nahradil Linux. Na desktopu se Unix nikdy zvlášť nepoužíval - vyjma grafických workstations - což byly ve své době špičkové produkty, ale hodně drahé. Pro běžnou kancelářskou práci se používala windows.
Microsft měl a má některé špičkové produkty - a to se týká i dokumentace - třeba tištěná dokumentace k Office Pro byla hodně dobrá - naopak dokumentace k skriptování MS Exchange téměř neexistovala - porovnejte dokumentaci MSSQL a Oracle - ta v MSSQL měla kolikrát u klíčových detailů odstavec.
Ohledně deploymentu - vyrobit rpmko je docela jednoduché - vyrobit instalačku aniž byste si koupili komerční tool byla cesta do pravěku (alespoň před 3 roky, kdy jsem se o to pokoušel). Kupovat profi nástroj kvůli výrobě jedné instalačky se mi opravdu nechtělo.
S produkty MSSQL jsem komerčně pracoval od roku 1994 - a něco bylo něco kvalitní, něco ani náhodou. U MS většinou neřešíte open source licence - postačí licence Microsoftu - ne tak nedávno se tu v ČR nebyl člověk, který by úplně rozuměl licencím MSSQL a několikrát se prodej licencí verifikoval v Redmontu. To s open source fakt nezažijete - většina produktů pro vývojáře používá BSD nebo LGPL.

Já myslím že se to komentovat dá. Když mají vývojáři dobré nástroje, dobrou dokumentaci a širokou platformu, tak mohou více řešit co potřebují napsat, a méně jak toho docílit. To vede k vyšší produktivitě.

Korporace používaly Unixy, a pak ve velkém přešly na Windows. Na pár místech zůstaly komerční Unixy, a ty se už pár let migrují na Linux. Koukněte se co ve firmách běží: directory services na Windows (Active Directory), file sharing na Windows, groupware na Windows (Exchange, výjimečně Lotus Domino), DB většinou na Windows (MS SQL a méně Oracle, s tím že Oracle může být výjimečně i na Unixu; BTW PostgreSQL jsem v žádné firmě ještě nepotkal), podnikové informační systémy v naprosté většině případů na Windows (od SW pro správu hotelu o pěti pokojích až po trojici Navision, Axapa a SAP), DMS/WF na Windows (typicky SharePoint) atd. Případný in-house development probíhá v naprosté většině případů opět pro Windows, z důvodů pospaných v prvním odstavci. Unixy najdete na webu (konkrétně Linux a FreeBSD protože jsou zdarma), případně u některých konzervativních firem v oblasti telekomunikací a bankovnictví (protože síla zvyku).

RPMko vyrobíte pro konkrétní verzi konkrétního distra Linuxu, pokud tedy to distro používá RPM. Takže nakonec skončíte s hromadou RPM balíčků pro jednu kategorii distrer, DEB balíčky pro druhou kategorii distrer, dalšími formáty balíčků pro ještě jiná distra (PISI pro Pardus, PET pro Puppy Linux atd.), a kdo ví s čím pro ostatní Unixy (PKG pro Solaris, úplně jiný PKG pro MacOS, SD-UX pro HP-UX, tuším BFF pro AIX). To ještě neřeším že váš SW bude nejspíš závislý na hromadě knihoven, které mohou a nemusí být k dispozici v požadované verzi pro konkrétní verzi konkrétního Unixu. Člověk se pak nevidí, že třeba Oracle má vlastní instalační prostředí založené na Javě. Přesto jeho "Quick Installation Guide" pro verzi 11g má 31 normostran. BTW ne-quick verze pro Solaris, která se mi tu válí na disku, má 226 normostran; uznávám že se tam řeší víc než jen instalace.
Instalačku pro Windows vyrobíte triviálně ve Visual Studiu (součástí VS je i InstallShield Limited Edition), a funguje na všech aktuálních verzích Windows.

SQL Server v roce 1994 opravdu nebyl nic moc. Použitelný začal být tak ve verzi 2000, svět RDBMS převálcovala tato verze a všechny po ní následující. Asi tomu pomohly i administrační nástroje, které jsou třeba u Oraclu opravdu příšerné. Osobně mám ale dobré zkušenosti hlavně s query optimizerem, u kterého mi přijde, že proti Oraclu daleko méně často generuje nesmyslný execution plan.

S open source naopak na licence narazíte velmi často. Spousta kódu je pod GPL, případně nejrůznějšími dalšími problematickými licencemi, a Richard Stallman dokonce vývojáře nabádá, aby knihovny uvolňovali pod GPL. Jinak souhlas že MS licence také nejsou triviální, ale ve srovnání se světem open source mi to pořád připadá výrazně lepší.
https://www.gnu.org/licenses/why-not-lgpl.en.html

Pak kdo má posunuté vidění - že by SQL server převálcoval svět :-) .. Má ale dobře našlápnuto, bo Oracle začal při tom žraní i nehorázně mlaskat - a cena už neodpovídá výkonu. Instalace Oraclu je naprosto antisystémová - jak na Win, tak v Linuxu - takže to není úplně dobrý příklad.

Je v tom trocha nadsázky, ale SQL Server přeoral svět RDBMS. Svého času jste ve firmách našel Oracle a DB2. Potom přišly Windows NT a později MS SQL Server. Oracle asi ještě pořád vede v tržbách, ale klesá. A DB2 aby člověk hledal s lupou.

Ano, instalace Oraclu je antisystémová. Je ale dobré se zamyslet nad důvodem. Pokud chcete psát SW klidně jen pro více Unixů, je deployment dost obtížný, což Oracle vyřešil právě vlastním instalátorem.

Pokud si vybavuju Oracle správně, tak stejný instalátor se používá i pro MSWin.

Ani na jednom Unixu a Linux není nutné pro instalaci používat Javu - tam Oracle totálně ustřelil - podobně jako např. IBM s instalací Lotus Notes. Za tím není jediný objektivní důvod - pouze nekompetentní development nebo management - možná obojí. Na Linuxu v podstatě stačí udržovat spec file a deb file - a více-méně máte pokrytý Debian like a RHEL distribuce.

Ano, Oracle používá stejný instalátor všude. Pokud už mají instalátor který funguje na všech Unixech, tak ho prostě použijí i na Windows.

Pokud chcete instalaci v GUI a s nastavováním řady options, jak jinak než Javou byste to řešil?

Na Linuxu byste měl provést překlad na konkrétní verzi konkrétního distra, protože jinak sice máte balíček, ale ten na cílovém distru jaksi nemusí fungovat. U ostatních Unixů je to ještě další boj. Ve srovnání s tím mi Windows Installer připadá pro vývojáře jako dost dobré řešení.

Proč pro těch několik málo parametrů, které potřebujete znát při instalaci potřebujete GUI? Možná bych ještě chápal TUI, ale táhnout sebou Javu. To fakt může vymyslet jedině bezmozek - nebo manager.

Na Linuxu potřebujete spec file a o zbytek se postará rpmbuilder - pokud se přeloží(překlad obsahuje provedení regresních testů), tak se nestává, že by na cílovém distru něco nefungovalo. Jeden spec file Vám bude fungovat pro všechny RHEL systémy, druhý pro všechny DEB systémy.

Ono těch parametrů není až tak málo. TUI by šlo, ale jsme v jednadvacátém století, ne v půlce dvacátého.

Vzhledem k tomu že různé verze toho samého distra mají i různé verze gcc a glibc, nemluvě o dalších komponentách, tak dost pochybuji, že jedním balíčkem pokryjete nějakou širší množinu dister. Nakonec i PostgreSQL vydáváte v balíčcích typu pgdg-redhat95-9.5-2.noarch.rpm, pgdg-fedora96-9.6-1.noarch.rpm, xenial-pgdg, trusty-pgdg, s tím že verze 9.2 běží na RHEL/CentOS/SL/OL 7, verze 8.4 na RHEL/CentOS/SL/OL 6 atd., a pro ostatní Unixy máte samozřejmě další balíčky (pro Solaris 11 postgresql-9.6.1-S11.sparc-64.tar.bz2, pro Solaris 10 postgresql-9.6.1-S10.sparc-64.tar.bz2...). Kolik těch balíčků vlastně máte na pokrytí FreeBSD, OpenBSD, Red Hat (+CentOS, Fedora atd.), Debian, Ubuntu, SuSE Linux, MacOS X a Solarisu v různých verzích? Jeden? Pět? Dvacet? Padesát?

Máte hromadu balíčků - a v podstatě pořád jeden spec file - nesmíte zapomenout ještě na variace CPU, verze operačních systémů, kompilace extenzí, ... přičemž jakmile máte napsaný spec file, tak veškerou práci za vás udělá infrastruktura - včetně doručení rpmek do repozitářů. I kdyby těch balíčků byly stovky, tak vám to nedá práci navíc - a pro uživatele je to pořád pouze "dnf install postgresql-server".

Jsem zvědavý kolik Unixů zvládne podporovat MSSQL a jak dobrá bude integrace do systémů.

Samozřejmě pokud nastavíte build system, tak to není práce navíc. Práce navíc je to když potřebujete přidat nové distro nebo jeho verzi, a práce navíc je to na supportu (ale to zákazník zaplatí, tak co).

BTW kolik těch balíčků tedy vydáváte na pokrytí těch platforem? Přepokládám že vy to zjistíte během minuty nebo dvou. Celkem by měl to zajímalo.

Ad kolik Unixů zvládne podporovat MSSQL a jak dobrá bude integrace do systémů - já také. Tipnu si že bude podporovat jen 2-3 distra Linuxu, dost možná s vlastním instalátorem.

viz https://yum.postgresql.org/ budu počítat jen RHEL - 15 x 5 verzí x cca 20 balíků pro každou verzi ... 1500 .. balíků. Podobné to bude na Debianu. Ke konfiguraci repozitářů a build systému přístup nemám - nikdy mne to nezajímalo, ale pokud budete mít zájem, tak se mohu Devrima zeptat.

Nám zákazníci neplatí - viz BSD licence :) - my nemůžeme přenášet na zákazníky - musíme používat dobré nástroje a dělat práci efektivně - mám pocit, že o balíky se stará jeden člověk. Jelikož Postgres releasuje každý rok minimálně 4x 5 podporovaných verzí, tak automatizaci potřebujete tak jako tak. A jakmile už jednou ten systém máte postavený, tak není problém jej rozvíjet.

Jestli bude MSSQL kopírovat Oracle, tak potěš P.B. Taky by se mohl v něčem poučit, jak to dělat, případně nedělat. Dneska už není až takový problém si udělat vlastní repozitář - Google to umí, Oracle to umí (např. s VirtualBoxem), tak by Microsoft mohl ukázat, že tu je 21. století.

Co chcete konfigurovat na databázi při instalaci. Vyberu si balíčky - případně si mohu zaklikat (o patro výše ve správě balíčků) a pak se někam nakopírují soubory - a to tak jak každá distribuce očekává. Díky tomu v systému není bordel. Zbytek už se může provádět v administraci databáze. Podívejte se na instalaci PostgreSQL, MySQL.. "dnf install ..", service xxx start. To, že korprace ztratily schopnost dělat věci jednoduše není problém Unixu, Linuxu.

Tak si projděte instalaci Oracle, uvidíte. Mimochodem úplně nechápu, proč Oracle (a mimochodem řada jiných unixových SW) vyžaduje tak velkou spoustu přípravných kroků. Chápu že nelze vytvořit skupiny, uživatele a někdy ani služby, protože na to neexistuje API, ale řada jiných věcí by technicky šla vyřešit automatizovaně.

No nic, nechci vás nijak demotivovat. Chtěl jsem jen ukázat, že z druhé strany barikády není vývoj pro Unixy žádný med. Možná když se na to podíváte z mého úhlu pohledu, s tím co jsem psal, tak snad trochu pochopíte, proč se většina autorů tvorbě unixového SW vyhýbá jak to jde.

A proč by nešlo automatizovaně udělat uživatele, služby a skupiny? Samozřejmě, že to není žádný problém.

V případě Oracle je to spíš korporátní demence - už instalátor XE je někde jinde.

Je potřeba respektovat platformu - dokud si vývojáři Postgresu mysleli, že Postgres na Windows nebude problém, bo NT jsou POSIX, tak Postgres na windows nebyl - hodně věcí se muselo upravit, rozšířit.

Klasický desktop dožívá - pro desktop se píše minimum nových věcí - gro je web, případně mobilní aplikace a hry. Myslím si, že je to naprosto jasné Microsoftu - žene se, co mu síly stačí do cloudu a hodně dobře vidí, jakou má pozici na webu. Myslím si, že pro hromadu lidí v MS musela být hodně hořká pilulka integrace Ubuntu. City ale peníze nevydělávaji.

Já se také práci na Win vyhýbám, co to jde. Věřte mi, týden nespím, když mám udělat rekompilaci Orafce nebo plpgsql_checku ve Visual Studiu. Vybuildovat 8 verzí knihoven je děs, případně identifikovat problémy s dependencema, kdy Win jen zahlásí, že knihovna není, ačkoliv je, ale na to potřebujete speciální nástroj, aby Vám zkontroloval u ukázal chybné dependence - Visual Studio bez problémů vyrobí DLLku. Je fakt, že v gcc si nic nenaklikám, ale něco automatizovat ve Visual Studiu, kdy nemůžete jednoduše naklonovat části projektů...

Ad proč by nešlo automatizovaně udělat uživatele, služby a skupiny - leda shell out, navíc podle konkrétní verze konkrétního Unixu. Nic moc.

Ad Je potřeba respektovat platformu - souhlas

Ad gro je web, případně mobilní aplikace a hry - záleží co děláte. Jak jsem psal nějakému kolegovi, pokud někdo píše mobilní piškvorky, tak to takhle může vidět. Ale nepředpokládám že by firemní sektor zaniknul, nebo že by firmy držely řekněme registr svých HR smluv ve veřejném cloudu a jako primární interface k němu měly aplikaci na smartphonu.

Ad Já se také práci na Win vyhýbám, co to jde - to vidíme svým způsobem podobně, jen každý z úplně opačné strany. Mě třeba děsí i jen představa tarballu, který bych měl kompilovat, probírat se potom desítkami kB chyb a zjišťovat proč to nekompiluje.
Ad automatizovat ve Visual Studiu, kdy nemůžete jednoduše naklonovat části projektů - záleží na prostředí. Na TFS můžete klonovat jak uznáte za vhodné (resp. vytvářet branches, koncept je prakticky stejný), a má nově i integraci s Gitem (která je v praxi dost na nic, protože source code management je jen jedna část potřebné funkcionality).

Namádkou jsem se díval na useradd, groupadd - podporováno na HPUX, Solaris, Linux - v čem je problém? Případně by to byly čtyři řádky v shellu - to jsou určitě komplikovanější věci - například neúplná nebo neoptimální podpora mmap na různých platformách - jiná optimalizace spinlocků, atd. Když se chce, tak to jde - https://www.postgresql.org/docs/current/static/supported-platforms.html . Samozřejmě, že Microsoft bude tvrdit, že to nejde, proč by tvrdil něco jiného a hrál do karet konkurenci - pravda je ale jinde.

Nikdy jsem netvrdil, že by firemní sektor zanikl - korporace jsou věčné - zaniknou ale klasické desktop aplikace - tlustého klienta nahradí AJAX aplikace - teď mi trochu docvakává proč tak dlouho MS cryplil IE - jakmile ustoupil, tak si tím vykopal hrob. U nových aplikací nemusíte řešit na čem a odkud běží, máte jednoduché prostředí - z principu, nikoliv z komplikovaných komplexních nástrojů, které vyžadují enterprise licence. Podívejte se na Jiru, Confluence, SalesForce. Nekladou si skoro žádné podmínky na klienta.

Samozřejmě, že vždy budou výjimky potvrzující pravidlo - CAD systémy - ale už třeba velké množství GIS aplikací se přestěhovalo na web.

Ad useradd, groupadd - ano, chybí API, takže je to asi jediné řešení.

Ad jsou určitě komplikovanější věci - bezpochyby.

Ad zaniknou ale klasické desktop aplikace, tlustého klienta nahradí AJAX aplikace - nemyslím. Webové aplikace jsou pěkné v tom, že je není potřeba instalovat. Bohužel jsou velmi mizerné v použitelnosti UI. Osobně považuji za nesmysl cpát všechno do browseru, abychom umožnili uživateli to co uměly aplikace už v době Windows 95, ale zato o dost méně pohodlně, s obrovskou spotřebou a CPU, a na platformě browserů které jsou nonstop děravé.
Mimochodem koukněte se na mobilní aplikace. Kupodivu se nepoužívá primárně webové rozhraní, ale "klasické" instalované aplikace s "klasickým" mobilním UI.

Kolik je jich implementováno s nativním UI a kolik je jich implementováno pomocí web technologie. To, jak se tváří, je úplně jiná otázka.
Mizerné UI je nesmysl - to je jen otázka, kdo co umí, a co komu vyhovuje. Když jsem se díval na SAP, Navision - tak tam rozhodně nebylo nic v UI, co by na webu nešlo.

useradd, groupadd - to je API.

Je to o té platformě - dokud neexistoval powershell, tak skriptování na Win byla bída a utrpení - dokonce se používal vbscript, což byla taková sr..., že já bych to z firmy na veřejnost nepustil - i s powershellem to není žádná sláva - ale je to o světelný rok lepší.

Na unixu díky možnosti integrace přes pipe a schopnostem shellu není jediný problém integrovat tyto aplikace.

Je to rozdíl od Win - pokud tam aplikace nepodporuje COM, DCOM, .NET, tak v podstatě není integrovatelná - sendkeys je fakt historie. Na Unixu díky stdin/stdout a konzistenci konceptu to není potřeba.

Ad useradd, groupadd - můžu se ptát z jaké knihovny ta API jsou? Nevidím je v libc ani v POSIXu. Podle všeho jsou to utility nebo skripty (tj. nikoliv API), a mimochodem v POSIXu je opět nevidím.

Ohledně skriptování: na Unixech se skriptuje tak že spouštíte utility s parametry a parsujete jejich textový výstup. Díky zvyku se vám může zdát že je to poměrně univerzální, ale není to tak.

Zkuste si třeba vybrat okna podle nějakého kritéria.
Get-Process |where {$_.mainWindowTItle -like "*Notepad*"} |format-table id,name,mainwin­dowtitle -autosize

Nebo řekněte Excelu (ve vašem případě LO Calc) aby založil dokument a něco do něj zapsal. Výsledek si pak třeba můžete uložit jako PDF, když na to přijde. Samozřejmě do Excelu můžete exportovat pomocí Out-Excel, a dokonce můžete zobrazit uživateli gridview pomocí Out-GridView, ale chtěl jsem tu ukázat možnost práce s Excelem.
$excel = New-Object -ComObject Excel.Application
$excel.Visible = $true
$workbook = $excel.Workbo­oks.Add()
$sheet = $workbook.Acti­veSheet
$counter = 0
Get-Service |
ForEach-Object {
    $counter++
    $sheet.cells.I­tem($counter,1) = $_.Name
    $sheet.cells.I­tem($counter,2) = $_.DisplayName
    $sheet.cells.I­tem($counter,3) = $_.Status
}

Navíc je důležité si uvědomit, že neparsujete text. Pracujete s objekty, filtrujete jejich properties, nemusíte spouštět utility. Takže když vyberete služby, tak dostanete objekty. Pipe pro objekty, filtrování objektů podle vlastností, volání metod... To je s dovolením generačně napřed proti skriptování na Unixech.
get-service bits,wsearch,win­rm,spooler | where {$_.status -eq 'running'} | stop-service -whatif

To co řešíte utilitami se v PowerShellu řeší odlišně. Například New-LocalUser nebo New-ADUser vám umožní založit uživatele, ale také vám ho vrátí jako objekt, se kterým můžete dál pracovat.

Ne, to je spíš ukázka toho, že s PowerShellem nejste omezený na command line apps a parsování textů. Samozřejmě pro psaní xlsx souborů můžete použít ExcelPSLib, můžete zobrazit grid pomocí Out-GridView, exportovat CSV, XML atd.

Jinak - podívejte se u Vás doma - pořád jedním z největších uživatelů PostgreSQL je Microsoft.

No nevím ...

U nás ve firmě máme od roku 2007 Windows a Linux desktopy zhruba půl na půl .

Na správu Windowsích desktopů (v AD) máme vyhražené 2 lidi a nestíhají nic jiného.

Linuxy spravuje jeden člověk a k tomu píše interní webové aplikace, aby se necítil nevytížen.

Tolik praxe.

Z mé zkušenosti je to spíš naopak ...

LibreOffice občas pomrší design "supr dupr" Word dokumentu, ne, že ne.

Ale sranda je, že MSOffice občas neotevře MSOffice dokument, zvlášť Word je na to swiňa. Pak se i na Windows LO hodí.

BDW: na LibreOffice nám jede 3/4 firmy, používáme ji i na Windows.

Ve Wordu je možné dokument otevřít s option Open and Repair, je to ve File Open dialogu jako volba u tlačítka Open. Dost mě překvapuje kolik adminů to neví.

Normálně na Laela nereaguji,ale tohle mě dostalo.
1) Oracle a Windows - Instaluji veškeré databáze Oracle u zákazníků (malé a střední firmy, několik velkých a státních institucí) pro provoz našeho ERP Notia Business Server. Poměr Linux:Windows 10:1. Unixů je zhruba stejně jako Windows. V podstatě se databáze na Windows instalují jen a pouze tam, kde má zákazník(malá firma) jediný historicky nainstalovaný server.
2) PostgreSQL používáme u našich zákazníků jako databázi pro CRM.

To hodně záleží na trhu, na kterém se pohybujete. Přesně jak jsem linkoval, sampling bias. Kdybyste instaloval DB2 nebo produkt běžící nad DB2, tak byste nejspíš všude okolo sebe viděl AIX.

Pro kolemjdoucí, ohledně toho RPM, DEB: Zde autor komentáře ukazuje zarputilost, s jakou se pokouší obhájit skutečnost, že Microsoft má snad nejhorší řešení balíčkování software. A to včetně Apple světa. Bohužel pro něj, na každou z jeho připomínek ohledně linuxu a balíčků se dá odpovědět jednoslovně: nesmysl. Doporučuji nenechat se znejistět a seznámit se se skutečností.

Napsal jsem snad něco špatně? Pokud je deployment tak ideální, jak připravíte balíček pro různá distra Linuxu založená na RPM, DEB a dalších, dále pro AIX, HP-UX, Solaris a MacOS (jako bonus můžete přibrat třeba FreeBSD)?

Psal jsem o vývoji pro Windows. Uděláte jeden MSI balíček, a ten pak nainstalujete na všech aktuálních verzích Windows. Thread na tohle téma začal někde tady:
https://www.root.cz/clanky/michal-krause-na-desktopu-mam-mac-ale-linux-jsem-neopustil/nazory/906957/

Jak definujete jeden operační systém? Je Ubuntu a RHEL jeden OS? Pokud ano, proč se pro ně připravují balíčky zvlášť? A pokud jsou to odlišné OS, tak je Ubuntu Trusty 14.04 LTS a 16.04 LTS Xenial jeden OS? Pokud ano, proč se pro ně připravují balíčky zvlášť? A pokud jsou to různé OS, tak proč předstírat že existuje něco jako platforma Unix nebo platforma Linux, a nepřiznat si, že deployment je na Unixech dost velký problém?

Já bych to přiznal, kdyby to byla pravda. Jenže ona to pravda není, to je pak těžký.

Pro většinu deb based distibucí napíšu jeden makefile - to máme Ubuntu, Debian, Mint,..., pro většinu rpm based distribucí spec soubor - Fedoru, Centos, Suse,.... Maximálně si musím dát majlzla na architekturu.

Jako nejsem maintainer, co se tím živí. Balíčky jsem si dělal jen proto, abych v tom měl pořádek, jde to prostě samo.

Proč tedy třeba kolegové vydávají PostgreSQL v desítkách balíčků, pro každé distro a každou jeho verzi? Předpokládám že obdobu Notepadu je možné zvládnout i jedním balíčkem RPM, jedním DEB, a po jednom od těch pár ostatních formátů.

Protože, tak je to nejjednodušší - nemusíme řešit minimálního společného jmenovatele - a můžeme akceptovat lokální specifika, případně změny v čase. Kdyby za buildem pro každou distribuci byla těžká ruční práce, tak bychom se na to dívali možná jinak - ale všechno je automatizované. Navíc nikdo si nemusí po internetu stahovat něco co nechce, nepotřebuje, není pro jeho platformu.
Pro uživatele to také není žádná komplikace - chce Postgres, systém vybere potřebné baličky a nainstaluje je (včetně všech závislostí). Práce na 3 minuty - včetně konfigurace k nastartování databáze.
U Windows je to mnohem komplikovanější - nic jako automatické řešení dependencí neexistuje (na straně klienta) - například se musí řešit "Redistrbutable" knihovny pro MSVS - což mi možná pořeší instalátor, ale zvětšuje se mi objem instalace nebo nutím uživatele, aby hledal některé instalace na webu Microsoftu a instaloval si je sám. V tomhle Microsoft hrozně zaspal - krásná ukázka jsou bugfixy - porovnejte RHEL a Win10. Kolik se toho stahuje, a jak dlouho trvá bugfixování. A to se mi bugfixují stovky aplikací nikoliv pouze operační systém.

No já jsem linkoval jak situace s deploymentem došla tak daleko, že se začaly vydávat balíčky typu Flatpak, Snap a AppImage. Linus Torvalds et al. zajímavě komentovali právě problémy při vytváření balíčků pro více distribucí.
https://www.root.cz/clanky/michal-krause-na-desktopu-mam-mac-ale-linux-jsem-neopustil/nazory/907404/

Ohledně instalace na Windows: nemyslím že je to mnohem komplikovanější. Je to hlavně jiné. Ve Windows se počítá s tím, že instalátor aplikace ideálně obsahuje rozdíl mezi čistým OS a cílovým stavem. Aby s sebou aplikace nemusela tahat velké balíky typu .NETu, můžou z nich být závislosti. Jejich absence pak může instalaci zastavit, nebo je může instalátor stáhnout.
https://msdn.microsoft.com/en-us/library/ee942965(v=vs.110).aspx

U bugfixů nemyslím že by toho MS tahal nějak hodně. Délka instalace je daná hlavně tím, že MS ověřuje i soubory na disku.

Ad to se mi bugfixují stovky aplikací nikoliv pouze operační systém - aktualizují se vám stovky balíčků, nikoliv aplikací. Například LibreOffice je z hlediska Windows jedna aplikace. Z hlediska Linuxu je to jeden metabalíček, a vlastních balíčků jsou nějaké desítky nebo stovky (libreoffice-base, libreoffice-base-core, libreoffice-common, libreoffice-calc, libreoffice-canzeley-client, libreoffice-help-en-us, libreoffice-help-cs, ...).

Pokud je deployment tak ideální, jak připravíte MSI soubor pro AIX, HP-UX, Solaris a MacOS (jako bonus můžete přibrat třeba FreeBSD)?

To už by bylo zbytečně moc. Ono úplně stačí instalátor nativní aplikace pro Windows x86 a x86_64, registry s WOW6432Node, to je zábavy na dlouhé zimní večery...

Popravdě, tady musím říct, že zde je nejflexibilnější MacOS, jejich suffix určující platformu u každé knihovny je naprosto super. Kéž by se tohle dostalo do Linuxu...

Mě by třeba zajímalo, jak vytvoříte ve Windows softwarový balíček s programem, který budu moct distribuovat a prodávat, automaticky aktualizovat, budu moct odkazovat na knihovny třetích stran - například wxPython, Python, a DX11, a samozřejmě v případě, že tyto knihovny nejsou na systému uživatele nainstalovány, tak se automaticky nainstalují (po odsouhlasení uživatelem). Tak nějak samozřejmou podmínkou je, že tyto knihovny nemusím dodávat ručně já, ale instalátor si je sežene z obvyklých zdrojů.

Netřeba zdůrazňovat že toto všechno je v Linuxových distibucích už desítky let samozřejmostí.

V případě Windows se na obzoru objevili první vlaštovky v podobě https://chocolatey.org/, ale nejsem si jist, jestli to není jen bundlovací nástroj jako NuGet.

Záleží jaký balíček chcete. Klasický instalátor může obsahovat merge modules, a případně instalovat nebo dotahovat z webu komponenty (typicky .NET, DX).

Ad toto všechno je v Linuxových distibucích už desítky let samozřejmostí - stejně jako to že balíčky se vydávají pro konkrétní verzi konkrétního distra. Mimochodem výraz dependency hell jistě znáte, a nepochází ze světa Windows. S deploymentem na Linuxu je to tak "skvělé", že vznikly iniciativy jako Flatpak, Snap a AppImage. Cíle jsou jasné: binární kompatibilita a nezávislost aplikace na distru a jeho verzi. A protože jde o Linux, tak vznikly hned tři různé formáty, které sice dělají prakticky totéž, ale zato za každým stojí jiná skupinka, aby se "správně" tříštily síly. Za flatpakem stojí freedesktop.org (ti stojí mimo jiné za neúspěšnou snahou Linux Standard Base), za Snapem Canonical (který mimo jiné vedou svou "chvályhodnou" válku Wayland versus Mir), u AppImage nevím.

BTW Linus Tovalds objevil AppImage a byl nadšený, protože řeší přesně ty problémy o kterých jsem psal: závislost balíčku na distru a jeho verzi. Vyplatí se přečíst i komentáře.
https://plus.google.com/+LinusTorvalds/posts/WyrATKUnmrS

OK, takže odpověď zní: Windows to neumí.

Co se týče Flatpak, Snap a AppImage - tam je pointa v tom, že Windows se nedostal ještě ani na úroveň těch rpm a deb repozitářů. Ne v tom, že rpm a deb jsou ideální.

Odpověď je že umí. Popsal jsem vám jak můžete aplikaci šířit s komponentami typu .NET Framework nebo DirectX. Samozřejmě můžete v rámci setupu také detekovat jestli je k dispozici řekněme Ghostscript a případně ho nainstalovat. O aktualizace se vám opět může postarat setup package, třeba InstallShield.

Windows se nedostal "na úroveň" deb/rpm repozitářů, protože požadavky byly úplně jiné. Setup aplikace by měl obsahovat ideálně rozdíl mezi čistým systémem a nainstalovanou aplikací. Pokud aplikace táhne něco velikého typu .NET Framework, tak se to řeší jak jsem popisoval.

Pokud jde o Flatpak, Snap a AppImage, tak to je prakticky obšlehnutý koncept aplikací z Apple AppStore, Windows Store atd.

Chápu, tedy v krátkosti: neumí.

U GPL licence na DB engine není problém. Problém nastane pokud jsou pod GPL licencí klientské knihovny té DB. Autoři většiny DB engines mají asi dost rozumu, aby to tak nedělali, a používají LGPL.

Ale když nalinkujete ve své aplikaci namátkou GNU Scientific Library, GNU Leg, Goptical, DynORM a řadu dalších, tak se vaše aplikace nakazí a budete muset uvolnit její zdroják. Paradoxně se mohou nakazit i drivery, a například někteří autoři kernelu tvrdí, že kernelový modul prostě musí být pod GPL (a vyjma toho neposkytují stabilní kernelové ABI, asi aby výrobce HW ještě víc odradili). To že se to nevymáhá třeba u video driverů je dané nejspíš tím, že by pak Linux o ty drivery přišel.
https://www.gnu.org/software/gsl/
http://savannah.gnu.org/projects/leg/
https://www.gnu.org/software/goptical/
https://dynorm.codeplex.com/

Ad kdyby RMS nabadal, at zerete male deti, na konkretni pouziiti aplikaci to nema vliv - ovšem má to vliv na vývojáře open source SW, protože RMS je zakladatelem jejich hnutí.

Ad svet opensource z par jasne definovanymi licencemi - konkrétně GPLv2, GPLv3, LGPL 2 a 3, AGPL různých verzí, Apache různých verzí, Berkeley Database License, BSD různých verzí a modifikací, Educational Community, FreeBSD, Freetype, imlib2, Intel Open Source License, MPL, NCSA, OpenLDAP, Perl různých verzí, IBM Public License a dlouhá řada dalších, jsou jich minimálně desítky. Share and enjoy, jak by řekl Nutri-Matic Drinks Synthesizer :)
https://www.gnu.org/licenses/license-list.en.html#SoftwareLicenses

Ad Bavime se tu ale o databazovych servrech, ne? - bavíme se tu o deploymentu aplikací na Windows vs. Unixech (včetně Linuxu).

Ad O licenci rozhoduji konkretni vyvojari konkretnich produktu, stejne jako u proprietarniho SW - to ano, ovšem ta jejich rozhodnutí nedělají život vývojáře nijak snadný.

Ad Pricemz polovina z nich se vejde na jednu az dve stranky - smlouva o pár stránkách ke každému kousku SW, kde jich musíte nasbírat nevím kolik abyste (ani tak ne-)dostal to co máte v ceně Windows za pár korun, to mi nezní moc atraktivně.

Ad pridej do seznamu Windows 3.11, Windows 9x, Windows CE... - v tom případě přidejte do seznamu Android, WebOS, a samozřejmě desetitisíce modelů různých domácích routerů, televizí a mikrovlnek... :)
Takhle asi ne. Pokud se bavíme o deploymentu na Windows, mám na mysli podporované verze. A nemá smysl vám předhazovat že RPM balíček pro poslední RHEL nejde na verzi 1 z roku 1995.

Ad Ty licence se opakuji - některé, někdy. Je to reálně existující problém, zvlášť když těch komponent musíte posbírat desítky a více, abyste (ne)dostal to co je v ceně Windows.

ODB... what? Nezpozdil jste se tak o 20 let? :) Navíc aplikace už dlouhou řadu let skladují connection string interně, ne v ODBC Data Sources. No a nakonec vizte první dvě položky tady:
http://www.isunshare.com/images/article/windows-8/open-windows-8-8.1-task-scheduler/double-click-task-scheduler.png

BTW kdybyste tam ty ikony neměl, tak v adresáři %systemdrive%\Win­dows\SysWoW64 je 32-bitová verze a v %systemdrive%\Win­dows\System32, executable je Odbcad32.exe. Je to popsané na MSDN i v MS KB.

BTW2 vždycky mě dovede překvapit, jak dokážete dělat věci přes ruku.

Hmm, zkusíme se podívat v Excelu. Data, Get External Data, From Other Sources. Nabízí to hned jako první From SQL Server, vyjma dalších možností také From Data Connection Wizard (Import data for an unlisted format by using the Data Connection Wizard and OLEDB). Tak mě napadá: nemohl jste se v tom Excelu podívat sám? Nebo je snad tak obtížné najít, pro člověka který (alespoň doufám) investoval úsilí do toho aby se naučil regexy, stovky příkazů a jejich parametry, skriptování v bashi, ovládání vi atd.?

Žvanění z cesty je vaše specialita, a navíc si to nejspíš ani neuvědomujete. OLEDB se nemusí instalovat. Musí se instalovat OLEDB provider, což je řekněme obdoba ODBC driveru. V instalaci Windows už by tuším měl být SQL Server OLEDB provider, pro ostatní typy DB si ho doinstalujete stejně jako ODBC driver.

To co máte na mysli vy je zřejmě Microsoft OLE DB Provider for ODBC Drivers. Pokud totiž nemáte OLEDB provider, můžete použít tenhle, který vám umožní použít ODBC driver.

Můžete si to udělat další čárku na seznamu "tohle jsem taky nevěděl, ale zato jsem hlasitě tvrdil blbosti". Pokud vám dojde místo na čárky, použijte vedlejší místnost.

No vzhledem k tomu že informace které píšete v diskusích jsou konzistentně zcela mimo, tak si o tom dovolím pochybovat. Vaše kombinace sebevědomí, neznalosti a vulgarity je dost unikátní. Je opravdu zábavné to pozorovat.

Ad ted bych prosil tu 10s aktualizaci - já nikdy nepsal o 10s aktualizaci, opět si vymýšlíte. Proč mě to už nepřekvapí? :)

Čistě GPL knihoven je minimum - většina knihoven pro vývoj je z rozumných důvodů LGPL nebo BSD, případně jejich modifikace. LGPL nebo BSD nejsou nakažlivé - text BSD má půl stránky. Pokud si vybavuji, tak vlastní licenci má téměř každý dodavatel komerčního sw, takže tu máme několik licencí MS, Oracle, Novelu, ... v podstatě neomezené množství - vůči tomu je počet o.s. licencí obdivuhodně malý.

Čistě GPL knihoven není až tolik, dokud chcete věci, které mají operační systémy standardně už desítky let. Pokud chcete něco specifičtějšího, je toho kódu pod GPL licencí víc. Souhlas že LGPL a BSD jsou z hlediska vývojáře v pohodě. Pak samozřejmě nastává čas se kouknout po dokumentaci... aby člověk zjistil, že je většinou poněkud tristní.

Ad vlastní licenci má téměř každý dodavatel komerčního sw, takže tu máme několik licencí MS, Oracle, Novelu, ... v podstatě neomezené množství; vůči tomu je počet o.s. licencí obdivuhodně malý - souhlas že těch licencí je hodně, ale open source licencí také není málo. Navíc v jednom produktu od velkého dodavatele dostanete velikou spoustu API, a nemusíte sbírat desítky projektů pod různými licencemi, abyste zjistil že jste jeden z několika mála uživatelů, a knihovna je plná bugů a omezení. Za rok pak dost možná zjistíte, že vývoj několika knihoven, které váš projekt používá, prostě ustal.

Nevím, jestli mi to uvěříte, ale používal jsem řadu knihoven a produktů od MS, jejichž vývoj ustal. Mám zákazníky, kteří používají už téměř mrtvé produkty MS, a to bez naděje na rozumný vývoj - např. zvýšení limitů třeba v počtu indexů na tabulku (ačkoliv nějaký vývoj ten produkt má - zvětšil se počet barev fontů z 256 na 65K). Na rozdíl od open source jsem neměl žádnou možnost si opravit chyby nebo pokračovat ve vývoji. Pokud si vzpomínám na svoji éru s Visual Basicem a .NETem - byl jsem jeden z prvních lidí, kteří tady v ČR měli .NET v ruce, tak skoro každý dodavatel komponent měl svojí a jinou licenční politiku. Z těch dodavatelů jich přežila možná desetina, spíš setina. Vzpomínám si na hrůzu v očích mých kolegů, když Microsoft zařízl vývoj Visual Basic a COM, ve chvíli, kdy jim to konečně začalo jakž takž fungovat - a bez jakýchkoliv výčitek začal podporovat pouze .NET.

MS zákazníkům zpravidla nabízí migrační cestu. Když ji nenabídne on, přispěchají jiní, protože jsou v tom peníze.

V případě VB MS několik let dopředu ohlašoval ukončení podpory, a poskytnul migrační wizard na VB.NET. Několik projektů jsem převáděl, a některé divočiny bylo nutné opravit ručně, ale vcelku to nebyl problém. Mimochodem tehdy jste mohl migrovat i na Xojo REALbasic. Předpokládám že kdybyste to udělal, tak byste později splakal nad výdělkem.

Ohledně komponent souhlas, svého času byla spousta výrobců, a dost jich nepřežilo. Dnes je situace o dost lepší. Každopádně pokud mám možnosti si vybrat mezi stabilní rozšířenou platformou a nějakým malým projektem, ať už s jakoukoliv licencí, tak preferuji option A.

Ad To s licenci nema nic spolecneho - souhlas, to je věc celého ekosystému

Ad diky opensource si muzes knihovny opravit, coz s proprietarnim softwarem nemuzes - jistě: rozebrat knihovnu, identifikovat problém, otestovat výsledek, zdokumentovat a vrátit. Pokud se změna nedostane do upstreamu, tak si ji budete doživotně udržovat, podporovat a šířit sám. Už při kroku "rozebrat knihovnu" jste nejspíš vypálil víc času, než kolik by vás stálo si ji koupit s podporou. Sorry jako, ale modifikovat si zdrojáky čehokoliv co používáte k vývoji aplikace je hodně špatný nápad.

Ad projekt cca 10mil. radku kodu ve VB6, ktery obsahoval chyby kvuli chybam z VB6, ktere se musely ruzne obchazet, protoze Microsoft prohlasil, ze tuto platformu nebude dal podporovat a prestal opravovat chyby a polibte si - MS to prohlásil pěkných pár let před ukončením podpory, a poskytnul migrační cestu na VB.NET s automatickým převodem projektů. Ano, bylo potřeba sem tam něco opravit ručně (migroval jsem víc takových projektů, pravda menšího rozsahu), ale věděli jste o tom roky dopředu.

Takhle bysme se nikam nedostali - ukončil MS podporu - ano, ne? V čem se lišil od jiných dodavatelů, ať už o.s. nebo proprietárních? Kolik je "pěkných pár ler" konkrétně? To, že Microsoft dodal migrační tool - aby ne - VB6 byla jeho vlajková loď - mohl si dovolit mnohé, ale zase až tolik nasr...t lidi si dovolit nemohl - nehledě na to, že potřeboval dostat lidi do .NETu.

Jak si mohu koupit podporu u firmy, která už neexistuje?

Díky za info - potřeboval jsem zabalit Orafce - což je možná o fous komplikovanější než běžná instalace - musíte vybrat správné soubory a správné cílové adresáře na základě instalovaného Postgresu. Nakonec to vyřešil zazipovaný archiv, a každý uživatel si nakopíruje dllka, která potřebuje a kam potřebuje.

V čem konkrétně je problém s MSI? Instalátor může používat standardní i custom steps, a samozřejmě není problém realizovat jakoukoliv akci jak v kontextu uživatele, tak admina.

Mono by mělo podporovat WinForms 2.0. Se XAML je to uznávám poněkud slabší. Ale myslím že se multiplatformní vývoj dost přeceňuje. Naprostá většina zákazníků jede Windows, nebo alespoň může jet Windows. Je nesmysl si při vývoji obrazně řečeno uřezat osm prstů z deseti, aby člověk mohl podporovat o procento víc zákazníků.

Problém je v odlišnostech platforem. Windows mají zatraceně široké API, a pokud chcete mít stejnou množinu API k dispozici na jiné platformě, znamená to nalít obrovské částky do vývoje. Pokud se jedná o menší projekt, tak ten je vždy odsouzen do stejné role jako Java nebo Qt: nejmenší společný násobek platforem, a k tomu sem tam nějaká vlastní multiplatformní dodělávka.

Nevím co šlukujete vy, ale Perlu bych se rozhodně vyhnul, protože je to přece jen příliš drsný kouř :)

Široké API - to je hezký eufemismus - myslím si, že většina rozumných platforem se snaží nemít zbytečně redundantní API.

To máte na mysli třeba Qt, LessTif, GTK+, Skia, FLTK, Fox toolkit, Nana C++, wxWidgets, TnFOX, Ultimate++, CEGUI, IUP, JUCE a EFL, s tím že žádný z těch widget toolkitů ale formálně vzato není součástí platformy, protože POSIX GUI pro jistotu vůbec neřeší? Nebo máte na mysli X11, Wayland, Mir, Fresco/Berlin, Xynth, Y, Z atd.? Než jsem napsal příspěvek, dost možná vznikla nebo zanikla další widget library nebo window system :)

Co nedefinuje POSIX (a toho je zatraceně málo), to připomíná divoce bublající polévku. A když už se někdo pokusí o standardizaci, jako Linux Standard Base, tak to dopadne neslavně. LSB verze 5 rozbíjí zpětnou kompatibilitu, Debian i Ubuntu od projektu odstoupily, a co jsem se naposled koukal, tak LSB v5 podporuje jedno distro s pro mě neznámým názvem. Podotýkám že LSB (ne-)řeší pouze Linux, a na Solarisu, HP-UX, AIXu a FreeBSD je situace ještě jiná.

Z grafických systémů je standardní zatím jen jeden (X11), ostatní se o to pomalu pokouší, ale budou potřebovat zajistit nějakou formu kompatibility aby se mohly prosadit. Co se týče těch toolkitů, tak si můžete vybrat svůj oblíbený a on nad X11 prostě bude fungovat. Pokud si vyberete wxWidgets, tak ten v nějaké formě půjde i na těch Windows. (To jen kdyby náhodou někomu nebylo zřejmé jak velkou koninu plácáte v prvním odstavci.)

Co se týče instalace, tak můžete udělat (jak navrhoval Pavel) rpm, nebo deb, pokud chcete aby se váš software dobře integroval s nějakou s častých distribucí. To se často ve světě open-source děje. Komerční produkty jsou často staticky kompilované a distribuované jako tar.gz (někdy jako samorozbalující se tar.gz), a pokud nepotřebujete integraci se systémem (vypínání/zapínání služeb,...), ale pustit jen nějaké grafické klikátko tak to bohatě stačí.

Ano, z grafických systémů je de-facto standardní (ehm, extensions) jen ten zcela nevyhovující, který měl být už před pár dekádami nahrazen. Vývoj dalšího grafického systému probíhá tradičně chaoticky, protože chybí jakékoliv vedení. Projekty vznikají, zanikají, roky plynou...

Bohužel i u těch klikátek je problém, například v různých desktopových prostředích se různě integrují položky do "Start Menu". V služeb je vtipné že neexistuje API pro jejich procházení, zjišťování stavu, spouštění, zastavování, zakládání a rušení. Resp. Solaris má Service Management Facility, systemd má D-Bus interface, ale většinou jde o klubka init scriptů, a kde je API, tam je na každém Unixu jiné. Opět to připomíná pejska kočičku, když vařili dort.

Říká Vám něco https://www.freedesktop.org/wiki/ ?

V okamžiku, kdy Sun integroval Gnome do Solarisu defacto vznikl hodně silný standard. Co se týče GUI v Linuxu si můžete vybrat - narozdíl od Windows - Unixáři jsou vyhraněnější a každému vyhovuje něco jiného - proto tu je GNOME, KDE, případně light GUI. Bylo by jednodušší, kdyby všichni byli postavení do latě - ale Linux je o svobodě, lidi si vybírají, co jim vyhovuje.

Jen pro informaci - běžím na nové Fedoře, a že tu nemám Xka v podstatě nepoznám.

Ad https://www.freedesktop.org/wiki/ - ano, to mi něco říká. Freedesktop.org stojí například za prakticky nepoužívaným LSB, jak jsem psal v jiném threadu. Naštěstí to vypadá, že se různé grafická prostředí začala scházet alespoň na specifikaci desktop entry (nevím jestli všechny), protože tu dvacet let byla situace, kdy se aplikace po instalaci objevila v jednom prostředí, ale už ne v druhém.

Ano, je fajn, že si můžete vybrat GUI. Jenže to můžete i ve Windows, akorát to bereme spíš jako zábavu pro děti, než abychom týden tunili UI než začneme pracovat. Otázka je kolik desktopových prostředí, grafických systémů, widget libraries a všeho ostatního potřebujete, než si uvědomíte, že jde o chaos ve stylu pejsek a kočička vaří dort, kde jsou nové verze těch desktopových prostředí nestabilní a špatně použitelné (Unity, Plasma), grafický systém nakonec existuje funkční a rozšířený jen jeden a naprosto nevhodný a nebezpečný k tomu (protože to nikdo - vašimi slovy - nepostaví do latě), a widget libs jsou trnem v oku každého odborníka na ergonomii, zvlášť když každá aplikace používá jiný.

Přemýšlím, co víc podobá Win10 Gnome nebo Gnome Win10 - a co tu bylo dřív?

Mimochodem nějaká alternativní desktopová prostředí pro Linux, pro případ že byste měl poblíž teenagery co si chtějí hrát :)
http://www.winstep.net/xtreme.asp
http://www.altshell.com/AltShell/index.html
http://www.pokki.com/
http://www.stardock.com/products/odnt/
https://cairoshell.github.io/
https://sourceforge.net/projects/emerge/
http://sharpe.sourceforge.net/
http://www.astonshell.com/index.html
http://bb4win.sourceforge.net/bblean/

Pro lepsi predstavu, screenshot sveho windowmanageru jsem kdysi dal sem:
http://www.abclinuxu.cz/desktopy/ebik-20130806
Dekorace oken nejsou zadne, na top-level urovni (cela obrazovka) mam tri okna - to je videt tim, ze tam kde by normalne byl horni okraj okna s titulkem jsou tri taby. Levy tab (pojmenovany defaultne WTiling<1>) je vnorena "plocha", kterou mam rozdelenou vertikalne. Kdyz nejake okno pustim do pripravene oblasti tak se samo resizuje presne na tu oblast.

Priklad jineho tiling wm (i3wm):
http://www.abclinuxu.cz/desktopy/miker-20141226

Bohuzel, na takovych windowmanagerech neni moc co k divani, takze se screenshoty shaneji po webu spatne.

Ten "naprosto nevyhovující" systém umožňuje kompletní výměnu windowmanagera. Chtěl jsem nějaký tiling window manager do Windows (pardon, ve světě windows se tomu říká tuším shell), ale bohužel, toto je příliš zadrátované do windows, než aby to někdo výrazně měnil. I proto to trvá ostatním grafickým systémům tak dlouho. Ten "zcela nevyhovující" systém je totiž překvapivě dost funkční, a za léta existence se v něm objevilo tolik "fixů/obezliček", že nově napsaný systém ho bude dohánět leta, i kdyby byl řízen dobře. Podobný pokus můžeme vidět třeba v mnohokrát propíraném systemd. Už je tu leta, a spousta distribucí ho má jako default. A i přesto toho zatím umí spustit míň, a často i míň spolehlivě než většina ostatních správců služeb. Doufám jen, že se do něj napře teď tolik sil, aby se odladil, když už byl takto prosazen.
Jediná věc, ve které je X11 opravdu nevyhovující je bezpečnost. Ale ruku na srdce, většina útoků jde přes prohlížeč, a často jsou jejich cílem vaše data na internetu. S tím žádný grafický subsystém nebo operační systém nic nezmůže.

Co se týče integrace do "Start Menu", tak nemůžu říct ani popel, protože nepoužívám žádné DE. Tudíž nemám žádné standardní "start menu". Jediné menu co mám, jsem si nakonfiguroval sám a spouští ty aplikace, které spouštím tak často, že je nechci spouštět z příkazové řádky.

Ve Windows samozřejmě můžete shell nahradit, případně rozsáhle modifikovat. Několik kousků jsem linkoval.
https://www.root.cz/clanky/michal-krause-na-desktopu-mam-mac-ale-linux-jsem-neopustil/nazory/907175/

Pokud vás zajímá důvod proč si ve Windows shell nahrazují jen teenageři kteří chtějí vytunit počítač, tak je to jednoduché. Napsat opravdu funkční shell není až tak složité technicky, ale velmi náročné navrhnout GUI tak, aby bylo v praxi dobře použitelné. Například když ve společnosti Canonical strávili nejspíš spoustu člověko-let návrhem a implementací Unity, tak si pozvali 12 uživatelů na testy usability. Výsledek opravdu stojí za přečtení.
http://www.mail-archive.com/ubuntu-desktop@lists.ubuntu.com/msg02912.html

X11 má naprosto šílený protokol, děsivou klientskou knihovnu, neřeší tisk (což je dost zásadní pro WYSIWYG aplikace), má spoustu mizerně dokumentovaných extensions (na kterých je dnešní desktop závislý), po odpojení session ji nelze znovu připojit, pro vzdálený přístup je ještě horší než ultra-primitivní VNC přenášející bitmapy... a ano, je na štíru s bezpečností. Jako sorry, ale i Windows 3.0 měly zobrazování vyřešené lépe, a to (bohužel) není nadsázka.
A protože vývoj Linuxu je neřízený a provádějí ho různé skupinky, které se rády pomlouvají a hází po sobě špínu místo aby pracovaly na jedné věci, tak máte už desítky let přežitý a nebezpečný grafický subsystém, a spoustu nedotažených pokusů o jeho nahrazení. Za mě nic moc.

Existuje spousta spatnych shellu stejne jako spousta spatnych windowmanageru pro X11. Ja shanim neco, co mi bude umet spravovat okna samo, misto toho abych si je musel tahat mysi. Z toho uz jsem vyrostl. Bohuzel sprava oken je tak zarostla do windows, ze ji windows shelly neresi. Touhle cestou se vydaly tiling window managery (ion3/notion, awesome, xmonad, ...), a musim rict, ze se to pouziva vyrazne produktivneji nes standardni WIMP. Nic takoveho jsem pro windows nenasel, a pred sedmi lety jsem hledal dost intenzivne. (Tiling window managery maji podobne jako editor Vim trochu narocnejsi ucici krivku na zacatku, ale to se velmi rychle vrati na pohodli prace s aplikacemi. To neni nic pro BFU, kteri chteji zapnout a mit falesny pocit ze vsemu rozumi.)

Proc by mel X11 resit tisk? Tohle bych si rad poslechl. To ma preci resit toolkit, ktery bude umet kreslit do rastru X11 i do krivek postskriptu nebo jinych tiskovych primitiv.

Windows 3.0 umely prenaset obraz na dalku? V dobe Windows 3.0, totiz tohle byla skutecna vyhoda protokolu X11: graficke terminaly (v dnesni reci thin-clienti) staly radove mene nez osobni pocitac. A clovek se tim mohl pripojit ke skutecne multi-uzivatelskemu prostredi, na celkem silny server, kde bezely aplikace dulezite pro firmu nebo pro vyuku.To ze se X11 dnes stale pouziva, znamena ze pouzitelny stale je. Pouziva se dnes zobrazovaci system z Windows 3.0?

Ad podobne jako editor Vim trochu narocnejsi ucici krivku na zacatku, ale to se velmi rychle vrati - ehm... Za mě je vim vynikající ukázkou toho, jak UI rozhodně vypadat nemá. Samozřejmě nic proti vaší preferenci.

Linky na pár tiling shellů a/nebo pluginů. Koukal jsem že většina z nich existuje, ale nikdy jsem je nezkoušel.
https://www.reddit.com/r/windows/comments/2rn775/best_tiled_window_manager_for_windows/

Ad Proc by mel X11 resit tisk? Tohle bych si rad poslechl. To ma preci resit toolkit, ktery bude umet kreslit do rastru X11 i do krivek postskriptu nebo jinych tiskovych primitiv - protože pak nepotřebujete toolkit, který pracně překládá volání z jednoho API na nevím kolik jiných API, a vzniká u toho spousta chyb. Je to úplně zbytečný layer, který bylo nutné zavést jen protože Unixy nemají grafický subsystém.

Jak se zobrazování a tisk řeší na Windows od verze 3.0: vespod jsou drivery zařízení typu obrazovky nebo tiskárny. Driver deklaruje jaké operace na zařízení poskytuje: bitmapy, polygony, křivky, texty atd. Nad drivery je GDI, které nahoře poskytuje relativně high-level API. Volání těch API překládá na to co umí driver. Takže když aplikace chce nakreslit B-spline, zavolá GDI, a GDI to buď přepustí driveru (pokud operaci podporuje), nebo volání přeloží na jedno či více volání které driver umí (například na bitmapu). Totéž u kreslení textu: aplikace zavolá GDI, a GDI buď řekne driveru že má nakreslit text, nebo požadavek přeloží na jiná volání včetně jako jsou třeba křivky a bitmapy. Je vcelku jedno jestli aplikace chce kreslit do okna nebo po stránce tiskárny. Prostě použijete ten samý kód, jenom ho necháte kreslit po jiném kontextu (řekněme plátně).
Vzdálený přístup se provádí (tuším od NT 4.0) tak že se použije RDP driver na straně kde běží aplikace, a ten deklaruje podporované operace, které nahlásí klient. GDI pak volá funkce RDP driveru, a ten je serializované posílá na klienta. Díky tomu je možné mít primitivního RDP klienta který umí jen bitmapy (například starší open source implementace RDP klientů), a GDI prostě pro klienta přeloží volání na bitmapy. Běžní klienti (Remote Desktop Client nebo thin client krabičky třeba od WYSE) podporují daleko více operací, samozřejmě je to efektivnější. K tomu Remote Desktop poskytuje sdílení clipboardu (nejen grafického), přesměrování zvuku, tisku, removable zařízení, čipových karet atd.

Ad V dobe Windows 3.0, totiz tohle byla skutecna vyhoda protokolu X11: graficke terminaly (v dnesni reci thin-clienti) staly radove mene nez osobni pocitac - grafické terminály stály výrazně méně než unixová workstation, to samozřejmě ano. Bohužel nejjednodušší způsob jak zabít terminál, server i síť mezi nimi bylo spustit xclock. Tehdejší X11 bylo opravdu jen pro otrlé. A ohledně ceny to také nebyla žádná sláva, protože X11 terminál byl technicky jeden předražený počítač, ke kterému jste musel mít jako server (well, X11 klient) druhý veliký a velmi předražený počítač (byť sdílený mezi pár uživateli). Dopadlo to tak, že firmy nakonec radši každému posadily na stůl levné PC.

Ad To ze se X11 dnes stale pouziva, znamena ze pouzitelny stale je - ono to hlavně znamená, že na Unixech bohužel není žádná lepší alternativa. O "kvalitách" X11 toho bylo napsáno a řečeno tolik, že to radši nalinkuji než abych psal román. Unixy potřebují něco jako GDI, WPFnebo Apple Quartz, akorát nikdo s ničím podobným nebyl schopný přijít a opravdu to prosadit.
http://www.std.org/~msm/common/protocol.pdf
https://www.youtube.com/watch?v=RIctzAQOe44#t=07m40s
https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html#xorg

Ad Pouziva se dnes zobrazovaci system z Windows 3.0 - ano, velké procento aplikací na Windows používá GDI API. Nové aplikace používají WPF, které je koncipované od začátku pro maximální využití GPU, je více orientované na vektory, typografii a multimédia, lépe pracuje se subpixelovými koordináty atd.

Ja si stale myslim, ze graficky server/system by mel byt oddeleny od toolkitu, prave proto aby tu mohly byt konkurecni toolkity a vyvojari meli volbu zda pouziji QT4, GTK3, nebo cokoli jineho. Graficky server by mel delat jen svoji praci a delat ji dobre: mel by spristupnit aplikaci kresleni do okna, a mel by ji to spristupnit tak, aby to neovlivnovalo ostatni aplikace (tady ma X11 rezervy). Dale by mel spristupnit klavesnici a mys a dovolit nejakemu programu MIMO tento server, aby delal politicka rozhodnuti o tom komu budou dorucene eventy z klavesnice/my­si/jineho ovladaciho zarizeni. Jinak to bude zase velky moloch se spoustou chyb, ktere bude tezko ladit natoz pak opravovat.

Toolkity jsou hlavně z nouze ctnost, protože s X11 lib se pracovalo velmi mizerně. Podpora tisku u X11 (původně jen hardcopy obrazovky) byla tak tragická, že ji nikdo nepoužíval. A protože rozvoj Unixu jako platformy se prakticky zastavil s Unix wars, nemá platforma žádný opravdový grafický subsystém. Výsledkem je úplné oddělení tisku od zobrazování. Svého času aplikace musely zobrazovat pomocí X11 a tisknout pomocí lpr, kterému podvrhly PostScript. Toolkity jsou původně widget toolkity, které z nutnosti nabraly i překlad high level grafického API na naprosto nesouvisející X11, PostScript, SVG a kdo ví co ještě.

To jestli vývojář použije Qt, GTK+ nebo něco jiného přece nic neříká o API systému. Nakonec Qt i GTK běží i na Windows, kde prostě volají GDI. Podobně jsme měli ve Windows třeba vbrun lib: hodí se k vystavění abstrakce nad Win32 vhodné pro Visual Basic, ale nepotřebuje řešit X11 a PostScript. Podobně Java má svou vrstvu abstrakce, ale zobrazuje přes GDI.

Za mě by zavedení grafického subsystému (a dalšího pokročilého API) na Unixech eliminovalo spoustu případů kde je nutné používat toolkity (BTW Qt je spíš platforma než toolkit), a v těch zbylých případech by jejich psaní bylo výrazně jednodušší.

Toolkit byl už v originálním designu - např. Athena. V době, kdy X11 vznikaly nikoho nenapadlo, že by se tisk mohl řídit výstupem na obrazovku - od toho byl na Unixech PostScript. GDI a GDI tisk bylo řešení typu z nouze ctnost určené pro laciné hloupé jehličkové tiskárny.

X11 je určitě překonaný design (velká část se už dneska vůbec nepoužívá) - nicméně, to že dobře fungoval 30 let bez větších změn na desítkách platforem něco říká o kvalitě a univerzálnosti návrhu - oproti tomu Windows GDI nikdy neopustilo platformu Windows. Vůbec se nedá porovnat design X11 a GDI, stejně tak možnosti - X11 bylo základem grafiky unixových workstation - možnosti grafiky dohnaly windows až kolem roku 2000.

Už běžím půl roku ma Waylandu nepoznám žádný velký rozdíl - pro běžného uživatele se X11, jakkoliv se jednalo o vousatý sw, nepředstavovaly žádné omezení.

Pokud si vzpomínám, tak ani s Microsoft Windows API se nepracovalo přímo bez knihoven - MFC - aby bylo možné nad API psát rozumně aplikace.

Tak já jsem pro čisté WindowsAPI aplikačku psal (v plain C protože licence kompilátoru). Bylo to v roce 2005. Jako dalo se, ostatně ono se dá ledacos. Ale to API žádný zázrak není, a některé hacky, jako třeba dvojité volání fukcí pro alokace paměti, jsou opravdu vtipné. A dokumentace byl otřesný problém.

Dokumentace byl problém? To myslíte vážně? Na Linuxu neexistuje nic typu MSDN, kde by byla dokumentace pohromadě. Hledáte ji po všech čertech, a pokud ji najdete, tak bývá buď špatná nebo ještě horší. Srovnejte:
https://www.gnu.org/software/libc/manual/html_node/Opening-and-Closing-Files.html#Opening-and-Closing-Files
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363874(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx

A srovnejte znovu:
https://www.gnu.org/software/libc/manual/html_node/Memory.html
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366779(v=vs.85).aspx

https://www.opengl.org/documentation/
https://msdn.microsoft.com/en-us/library/windows/desktop/ee663279(v=vs.85).aspx

https://docs.oracle.com/javase/7/docs/technotes/guides/collections/overview.html
https://msdn.microsoft.com/en-us/library/mt654013.aspx

Rozdíl mezi teorií (v tom žiješ ty), a praxí když potřebuji skutečně něco zjistit (já).

Naštěstí to bylo v závěru mé Windows éry. Od té doby už jsem se s tím bazmekem nemusel patlat.

Ad Toolkit byl už v originálním designu, např. Athena - OK, to máte pravdu.

Ad V době, kdy X11 vznikaly nikoho nenapadlo, že by se tisk mohl řídit výstupem na obrazovku, od toho byl na Unixech PostScript - no v té době Unixy tiskly převážně textově. První desktopová PS tiskárna přišla až v roce 1985.

Ad GDI a GDI tisk bylo řešení typu z nouze ctnost určené pro laciné hloupé jehličkové tiskárny - nejen pro jehličkové tiskárny, ale dá to celkem rozum. První desktopová PS tiskárna byla Apple LaserWriter, a musela mít silnější CPU než tehdejší desktopy, aby byla schopná stránku v nějaké realistické době vyrastrovat. Pro ilustraci Apple LaserWriter měl 12 MHz Motorola 68000, 1.5MB RAM, a cenovku 6995 USD (v dnešních cenách 15576 USD). HP LaserJet měla stejný mechanismus, ale jen 8 MHz Motorola 68000 a 128kB paměti, a přišla jen na 3495 USD, a ještě přišla na trh o rok dříve, protože nebylo potřeba pracně implementovat PostScript.
Omezit možnost tisku pouze na PS by byla veliká chyba. PS byl velmi náročný na CPU a paměť, vyžadoval licenci od Adobe, tiskárny byly drahé. Pokud jste chtěl WYSIWYG, tak byste buď musel mít dvě nesouvisející code paths, což je špatné, nebo zobrazovat PS, kde vyjma HW náročnosti znamená bylo brzdou to že rastrování PS grafiky a zvláště fontů při nižších rozlišeních bylo prakticky nepoužitelné (zlepšilo se jen do jisté míry, to až když bylo dávno pozdě). Takže MS udělal logickou věc: oddělil tiskový jazyk od aplikace, a nechal ho generovat v driveru. Ať tiskárna používá PostScript, PCL, ESC/P nebo něco úplně jiného, vytiskne vždy totéž, a stačí k tomu napsat poměrně jednoduchý driver tiskárny. O zbytek se postará OS, a aplikace pak může jedním API kreslit po obrazovce i tiskárně libovolného typu. Za mě velmi dobrý design.

Ad X11 je určitě překonaný design - souhlas
Ad to že dobře fungoval 30 let bez větších změn na desítkách platforem něco říká o kvalitě a univerzálnosti návrhu, oproti tomu Windows GDI nikdy neopustilo platformu Windows - to co popisujete není kvalita a univerzálnost, ale přežívání technologického pravěku v hloubi jeskyně. X11 nikdy ve větším neopustilo platformu Unix (ano, platformu, i když fragmentovanou a nerozvíjenou v důsledku Unix Wars). GDI měl a má na stole každý uživatel Windows, tj. skoro každý uživatel PC desktopu, a to také už 30 let.

Ad Vůbec se nedá porovnat design X11 a GDI, stejně tak možnosti - dá se porovnat, a s výjimkou vzdáleného přístupu (což u personal computeru nebylo nijak zásadní), který dohonily až pozdější verze Windows, to ve všech ohledech to srovnání pro X11 vyznívá velmi špatně.

Ad ani s Microsoft Windows API se nepracovalo přímo bez knihoven (MFC) aby bylo možné nad API psát rozumně aplikace - Win32 API je primárně Cčkové, stylem podobné řekněme GTK. Pro různé jazyky, včetně C++, Pascalu a VB, se vytvářely úrovně abstrakce vhodné pro použití v daném jazyku. Nicméně jsem opravdu neviděl, že by taková knihovna musela suplovat u grafiky všechno od high level API až po překlad do jazyka tiskárny.

Ad pro běžného uživatele se X11, jakkoliv se jednalo o vousatý sw, nepředstavovaly žádné omezení - vyjma vzdáleného přístupu (BTW tam si s Waylandem ani moc nepolepšíte), rychlosti rastrování (stránka čínských znaků opravdu nepotěší), bezpečnosti, problémů s přepínáním do fullscreen režimu (a hlavně zpět) atd. Jinak super že jedete na Waylandu. Předpokládám že nějaké (asi velké) procento aplikací používá dále X11 code path přes XWayland. Navíc Wayland opět nedělá to co by moderní grafický subsystém měl umět, a navíc odebírá vzdálený přístup. Je to v podstatě "X11++" namísto GDI, WPF nebo Quartz. Jenže za řekněme 20 let se nepovedlo udělat nic lepšího, takže buďme rádi za Wayland.

To by mne zajímalo, co je tak na GDI super? V podstatě na to aby se dalo používat, tak musel Microsoft přijít s DirectX knihovnama. Jestli je jedinou výhodou low level rendrování pro tisk, tak to teda nic moc. Pokud mluvíme o Unixových workstation, tak tam cena za postscript tiskárnu nehrála žádnou roli. Pro běžného uživatele Windows byla samozřejmě nedostupná - bavíme se o windows - levném "lowend" kancelářském software, které bylo designované pro výrazně slabší stroje.
Co se týče Xek, tak teď trolíte - když bych vedle sebe dal Windows aplikaci, a třeba Gnome aplikaci, tak tam najdu 99% stejných prvků - jen namapovaných v jiných knihovnách. Ono více-méně Microsoft použil hodně podobné techniky - viz použití knihoven, které dávali 95vzhled nebo 2000 vzhled
Xka navržená mnohem generičtěji než jakékoliv Win prostředí v té době - podívejte se na práci se source, na konfigurace, na možnosti mapování kláves, ... To se ještě o 15 let později ve win hackovalo.

Co je tak super? DDI pro abstrakci nad kreslicími zařízeními, což garantuje nezávislost na konkrétním tiskovém jazyku (stejně jako na konkrétní grafické kartě). Relativně high level API pro aplikace, s jednou code path pro zobrazení i tisk. Nízké HW nároky a vysoká rychlost.

Ano, Unixové WS byly neskutečně předražené, takže nějakých v dnešních cenách 15500 USD za PS tiskárnu nehrálo roli. To bude jeden z důvodů proč se nerozšířily a po příchodu Windows NT poměrně rychle umřely.

Ad když bych vedle sebe dal Windows aplikaci, a třeba Gnome aplikaci, tak tam najdu 99% stejných prvků - no jistě, ale ty samé prvky si můžete klidně i namalovat v MS Paintu. Pokud se bavíme o architektuře, tak tam je značný rozdíl.

Ad Microsoft použil hodně podobné techniky, viz použití knihoven, které dávali 95vzhled nebo 2000 vzhled - pokud za podobnou techniku považujete to že dekorace a widgety (mimochodem řádově kvalitnější než tehdy měly Unixy) jsou v knihovnách, tak ano. Ne že by to mělo smysl dělat nějak jinak.

Ad Xka navržená mnohem generičtěji než jakékoliv Win prostředí v té době - a bylo to k něčemu? Vzdálený přístup nepoužitelný díky špatně navrženému protokolu se spoustou round tripů, font management tak "kvalitní" že rozchodit zobrazování na X11 serveru bylo opravdu umění, a tak "výkonné" že se dnes raději fonty rastrují úplně mimo X11, protože to vychází lépe. Na protokol určený primárně pro vzdálené stroje je to celkem mazec. A když vezmete v úvahu že se nelze ani znovu připojit k odpojené session... Ne, X11 nebyl dobrý systém ani na začátku svého života.

Ad konfigurace - konfigurace X11 byla vždycky utrpení, změna rozlišení přišla po 10 letech a nakonec se z X11 radši přesunula pryč (BTW dodnes když vám umře fullscreen aplikace, tak se nezmění rozlišení a gamma zpátky na stav před startem aplikace), práce s více monitory je za nula bodů, mimochodem nelze nahradit driver za běhu (to uměly tuším už Windows 98) protože to vyžaduje restart X serveru a není možný reconnect, server má spustu blokujících a dlouho trvajících volání...

Ad možnosti mapování kláves - bohužel dodnes nefungují globální zkratky když otevřete menu, přepínání layoutu klávesnice nefunguje (koliduje s klávesovými zkratkami - když nastavíte Alt+Shift na změnu layoutu, nepůjde vám Alt+Shift+písmeno, bug byl nahlášen před 13 lety), aplikace můžou snadno "grabout" klávesnici i kurzor myši atd. Konfigurák s textovým mapováním kláves je sice zajímavý pokud vám upadne jedna klávesa a potřebujete ji nahradit jinou :), ale jinak mi přínos uniká.

Ať přemýšlím jak přemýšlím, nedaří se mi na X11 najít jiné pozitivum, než (spíše teoretickou) možnost vzdáleného přístupu před tím než se i to naučily Windows lépe.

Myslíte, že bych nenašel dlouho neopravené bugy ve Windows? Hroma věcí už je dneska jinak.
Unixové workstation byly hodně drahé - ale byla to úplně jiná liga, co se týče výkonu, stability, komfortu, bezpečnosti.
Umřely až, když PC se dostala na přibližně stejnou hw úroveň a Windows začaly být stabilní - bavíme se o spíš o roku 2003-2004 - první NT na ně neměla ani náhodou. Ještě v roce 2002 dokázaly být NT 2000 zavirované dříve než se dokončila instalace a stihl se nainstalovat antivir.

Určitě existují i dlouho neopravené bugy ve Windows, ale to co jsem psal popisuje jak poměrně závažné bugy, tak (častěji) špatný návrh.

Souhlasím že unixové WS měly svého času proti Intelu vyšší výkon. Jenže ony ho také díky některým unixovým specifikům (třeba X11) potřebovaly víc než Windows. Windows NT jim začaly ujídat trh poměrně rychle, už ve verzi 3.51 to bylo vidět a portoval se SW. U NT 4 se naplno migrovalo a unixové WS byly "na dožití". Navíc tehdy Windows NT byly k dispozici i pro Alphu, MIPS a PowerPC, což mělo zahnat obavy z nedostatku výkonu.
Typický příběh je CATIA, kde v roce 1988 uvedli verzi pro Unix, v roce 1998 pro Windows NT, a v roce 2008 už vydali verzi jen pro Windows. Navíc po uvedení WinNT nedošlo jen k migraci na ně (třeba AutoCAD, MicroStation), ale také ke vzniku velké spousty nového SW (3D Studio MAX, Autodesk Inventor, Solid Edge a další).

Pokud zmiňujete rok 2003-2004, tak myslím že máte trochu zpoždění. V té době už přecházel na Windows řady XP celý firemní svět, který do té doby jel na Windows 9x. A to že Win2000 byly zavirované ještě před dokončením instalace? Pamatuji to u WinXP bez SP, navíc je to dost jednoduše řešitelné. Buď instalujete z médií s posledním SP, nebo instalujete bez sítě a SP doinstalujete před připojením k síti. Taková trivialita mi nepřijde jako důvod si kupovat WS od Sunu, na které běží pět aplikací včetně xtermu a xclocku (a vyjma těch dvou chtějí za licenci vždy hmotnost instalačního média a manuálů ve zlatě), je k ní potřeba monitor od Sunu protože s jiným nejde, klávesnice a myš od Sunu, a ta myš nefunguje na jiné podložce než od Sunu (nedělám si srandu). To prosím za desetinásobek ceny stroje s Windows.

BTW perlička: předpokládám že víte o Windows NT pro různé HW platformy, MSIE a MediaPlayeru pro Unixy a podobných lehce exotických jevech. Ale víte že Sun vyráběl svého času servery s certifikací pro Windows?

Nejsem si jist, co si z tvého příspěvku mám vzít. Že má Microsoft dobré obchodníky, kteří jsou schopni prodat mizerný produkt? To přeci nikdo nerozporuje.

To pěkně popisujete vývoj piškvorek s leaderboardem v cloudu a s webovým nebo mobilním UI. BTW mobilní appka má tu "výhodu", může na server odeslat i address list a případně přeposlat třeba autentizační zprávu z banky :), ale to je trochu jiné téma.

Ad kde je business: pokud jde o ty piškvorky, tak si nejsem jistý jestli je tam business, ale budiž. Nicméně ve světě businessu zákazníci cloud ve velkém procentu případů prostě odmítají, a chtějí mít své aplikace a hlavně svá data u sebe. Asi si uvědomují rizika spojená s cloudem. Svět holt nejsou jen piškvorky na mobilu.

Ohledně daemonu/service: pokud jsem si všiml, tak Tomcat používá právě jsvc/procrun. Mimochodem fakt super link. FYI dokumentace by měla vypadat asi takhle:
https://msdn.microsoft.com/en-us/library/9k985bc9(v=vs.110).aspx
https://msdn.microsoft.com/en-us/library/zt39148a(v=vs.110).aspx

Maven je fajn, ale nezapomínejte, že vývoj Javy poněkud vázne a spousta funkcionality chybí. Díky tomu potřebujete knihovnu na každou blbost, protože musíte doplňovat základní funkcionalitu, kterou Java dávno měla mít. Příklad za všechny: proč proboha JDBC neumí named parameters? To kvůli takové blbosti fakt musím tahat další knihovnu? A proč Java až do verze 8 nemá base64 encoder? To si i na tuhle blbost musím tahat knihovnu? Totéž StringJoiner, to si snad dělají srandu? Atd., atd. Pak se nedivte, že vaše aplikace vypadá pomalu jako mirror Maven repository.

Na .NETu máme samozřejmě také třeba NuGet, ale .NET je daleko širší platforma než Java, takže nepotřebujeme na každém druhém řádku záplatovat její nedostatky stažením další a další knihovny.

Laele, chtěl jsem napsat něco podobného jako Youda, ale byl rychlejší (nebo možná já moc líný), tak aspoň odpovím na "doplňující dotazy":

Cloud dneska potřebuje prakticky každá společnost, včetně bank, které jsou na data hodně opatrné. Jediný rozdíl je, jestli ten cloud bude vnitřní, privátní nebo globální. Kdo dneska nepoužívá Cloud přinejmenším na vývoj, je neskutečně neefektivní a už i dinosauři se pohnuli, bo jinak by zašli stejně jako před tisící let. Mimochodem, na ten vnitřní Cloud můžete použít třeba otevřený OpenShift a vyhnout se tak vendor lock-in, je-li to nutné. V ostrém kontrastu proti tomu, co nabízí Microsoft - Azure, jediná instance, jediná firma, jediná licenční politika. Cesta do kytek.

Co se jazyku Java týče, obsahoval rozumně určenou množinu, která se postupně rozvíjela. To nejspíš mělo smysl s tím, kolik měly zařízení paměti. Dneska je to spíš jedno, ale IMHO Java stále dodržuje ten racionální poměr mezi základní funkcionalitou a chtěl-bych-tam-každou-blbost-o-které-se-mi-v-noci-zdálo. Pokud chcu něco extra, musím se podívat kolem, samozřejmě. Nicméně v důsledku je pro Java Hibernate, Spring, Spring boot, Guava, Guice, Camel, Hadoop, Rx, Spark, Netty, Jackson, Log4j a desítky dalších projektů, které skutečně něco dělají, a které mi srazí vývoj projektu z desítek člověkolet na třeba pár měsícu. Zatímco pro .Net mám sice ten základ, který umí o něco víc než Java core, ale k tomu není nic navíc. NuGet je s prominutím hromada nevyspělého šrotu.

Výsledkem je, že velké projekty se řeší v Java, a .Net vývojáří si stále šmudlí aplikace ve stylu 90-tých let - WPF, EntityFramework a přímá konexe do databáze - jak to dneska ještě vůbec někdo může používat?? Když jsem naposledy řešil obyčejného REST klienta v .Net, tak mě z toho bolela hlava ještě měsíc. V Java věc na pár řádků. Jediná věc, která to uměla trošku na úrovni, byl Spring.Net, ale ten je praktický mrtvý od doby, co hlavní vývojář přešel do MS. Náhrada v .Net core? Ani náhodou...

O automatických buildech, deployment, docker atd. škoda mluvit, viz předchozí příspěvek. Jazyk je jenom malý střípek v mozaice...

Ad Azure, jediná instance, jediná firma, jediná licenční politika - omyl. Viděl jste někdy Windows Azure Pack/Stack? To to Azure na vašem HW. Můžete ho mít u vás nebo u ISP, používá/nabízí ho i české NWT Silo, dále T-Systems, Rackspace, Hostway, Dell, Lufthansa a spousta dalších.

Ad IMHO Java stále dodržuje ten racionální poměr mezi základní funkcionalitou a chtěl-bych-tam-každou-blbost-o-které-se-mi-v-noci-zdálo - IMHO Java má tenhle poměr úplně mimo a i naprosto základní věci je potřeba lepit externími knihovnami.

Ad v důsledku je pro Java... a desítky dalších projektů, které skutečně něco dělají, a které mi srazí vývoj projektu z desítek člověkolet na třeba pár měsícu - to i v .NETu. Ekvivalenty:
Hibernate - třeba LINQ to SQL, LINQ2DB. Doporučuji si přečíst tohle: https://msdn.microsoft.com/en-us/library/aa479863.aspx#linqcompari_topic5
Spring boot - řeší problémy které .NET vůbec nemá
Guava - System.Collections, C# extension methods atd.
Guice - nullable types (int? i = 10;), immutable collections (ImmutableList<T>) atd.
Camel - MSMQ, Azure Bus, Microsoft Enterprise Library, MassTransit atd.
Hadoop - Windows Distributed File System, případně .NET SDK for Hadoop :)
Rx - Rx.NET
Spark - MS Prajna
Netty - async/await, Microsoft Enterprise Library, Google Interlace atd.
Jackson - JSON.NET
Log4j - NLog, Microsoft Enterprise Library

Ad .Net vývojáří si stále šmudlí aplikace ve stylu 90-tých let; WPF, EntityFramework a přímá konexe do databáze - myslím že na GUI nic lepšího než WPF zatím není. EntityFramework, ale ani žádné jiné pokusy o ORM, mě nikdy neuspokojily. Kdykoliv totiž potřebujete něco jen trochu složitějšího, tak to dopadne vysloveně katastroficky. Takže pokud bych si dělal katalog své (fyzické) knihovny, tak by to mohlo mít smysl.

Ad jsem naposledy řešil obyčejného REST klienta v .Net, tak mě z toho bolela hlava ještě měsíc - používám Json.NET, dá se použít i System.Runtime­.Serialization­.Json.DataCon­tractJsonSeri­alizer.

Ad O automatických buildech, deployment, docker atd. škoda mluvit, viz předchozí příspěvek - kdy jste naposledy opravdu používal Visual Studio? :)
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-deploy
https://docs.microsoft.com/en-us/azure/app-service-web/app-service-continuous-deployment

Tak vidím, že jste v Microsoftu na hledání ekvivalentu tvrdě pracovali, ale v polovině případů jste úplně mimo, v druhé polovině se těžko jedná o ekvivalent:

LINQ je hodně low level v porování s Hibernate
Spring boot - neřeší problémy, ale automatizuje a generuje kód (+spousta dalších věcí), tedy šetří tunu času při vývoji, navíc třeba Spring Boot Data
Guava - collections jsou hodně malá část
Guice - tady jste úplně mimo, Guice řeší Dependency Injection
Camel - integrační platforma, opět úplně mimo s MSMQ, Azure Bus atd., o desítkach konektorů ani nemluvě
Hadoop - srovnání opět úplně mimo
Spark - nesrovnatelné

Netty - async/await je nesrovnatelný low level. Je to ten typický příklad, kde s Java/Netty použiju existující codecs a pipeline a bude mě implementace třeba IoT stát pár dní. Zatímco s async/await v .Net to bude rok a ještě to nebude škálovat podle představ. Mimochodem, je dobré se podívat na benchmarky Netty vs IIS (640k/s vs 30k/s). Když to .Net umí tak hezky, proč má tak tragické výsledky?

Ad WPF - GUI je mi celkem ukradené, tragédie je ta architektura za tím - přímá konexe do DB je věc z minulého století. Řekl bych, že typickým zákazníkem pro tento typ software je tak státní úřad...

Ad REST v .Net - jenže já nemluvím o JSON (de)serializaci, ale o REST klientovi. A zatímco třeba Spring RestTemplate předám jenom URL pattern a on se postará o zbytek, včetně transparentní XML/JSON/cokoliv, tak v .Net budu matlat všechny vrstvy dohromady ručně. V Java pracuju o level až dva výš.

Jestli jste skutečně našli jenom tohle jako náhrady, tak bych se tím radši nechlubil, to je na tom .Net ještě hůř než jsem si myslel...

Já nevím co dělali v MS, ale pro mě je diskuse na rootu výplní pro dlouhou chvíli. Navíc nejsem Java developer, takže v některých případech vím co máte na mysli, v jiných ne.

U Hibernate jsem vám psal výhrady. LINQ je na nižší úrovni abstrakce, a právě proto ho používám (v kombinaci s klasickým System.Data.SqlCli­ent). ORM toolkity jsou při složitějších scénářích vysoce kontraproduktivní.
Collection jsou jen část toho co dělá Guava, proto jsem uváděl také C# lang extensions. Guava je přesně ta záplata na chybějící funkcionalitu, kterou měla dávno mít Java.
Pardon, komentář u Guice asi patřil jinam. Guice má jako obdobu třeba Suice.
https://github.com/disturbing/suice
U Camel jsem vám dal pár alternativ, ale samozřejmě je tu vždycky také BizTalk server :)
Spak a Prajna srovnávat nebudu, obojí jde mimo mě.
Ohledně Netty: opět záleží na tom co píšete. Vždycky je tu i DotNetty.
Ad WPF - pro mě je naopak GUI celkem zásadní, Java je ohledně GUI vysloveně tragická (když odhlédneme od toho že instalovat JRE na desktop je bezpečnostní katastrofa). Nevím co máte na mysli ohledně přímé konexe do DB.

Ohledně REST: pardon, pro vás asi bude lepší RestSharp. Já REST API vidím zcela výjimečně.

Každopádně co jsem vám chtěl sdělit je hlavně to že Java je pozadu ohledně jazyka i platformy. Properties, lambda, generics, implicit conversions, language extensions... v Javě buď nejsou, nebo jsou to pozdní a polovičaté snahy dohánět zbytek světa. Vlastní platforma je prakticky holá, a na každý nesmysl aby člověk tahal jednu nebo více knihoven. Důvodem není velikost JRE, ale to že Oracle na Javu kašle. A pro vývoj desktopových aplikací, nebo obecně čehokoliv co má nějaké GUI, je Java úplně mrtvá. Chápu že pokud na serveru mícháte data dlouhým bidlem a víc vás to netrápí, tak Java není až tak špatná. Pro mě to ale není.