Vlákno názorů k článku
Microsoft je levnější než open source, zní z anglického Hampshire od K> - no jasne, kazdy prechod stoji spoustu penez, takze...

Makal jsem posledních nevím kolik dní. Dneska se naopak flákám :)

Vhodnost pro daný účel si musí každý posoudit sám. Na MS SW jede naprostá většina firem. Podle mě je to důsledek toho, že konkurence nedovede nabídnout srovnatelně dobré produkty.

Ad používám sdílený kalendář a Outlook na PC nemám - na sdílený kalendář samozřejmě není nutně potřeba Outlook. Ovšem má ho vyřešený velmi dobře, takže o hodně přicházíte :)

Pokud jde o Exchange+Outlook, tak tuhle kombinaci od začátku měly rády soukromé firmy. Do státní správy se pokud vím dostala až později. Nakonec stejně to bylo u psacího stroje, telefonu, kalkulačky a počítače :)

Jinak nevidím důvod, proč by zrovna za koupí licencí MS produktů do veřejného sektoru měla stát korupce. Státní správa prakticky nemá odborníky, protože jim neumí nabídnout plat a karierní postup srovnatelný se soukromým sektorem. Proto většinu IT řeší nákupem. A u toho bohužel často dochází ke korupci. Bez ohledu na to, kdo je dodavatelem technologie. Jestli myslíte, že když je projekt dodaný řekněme na Linuxu a Javě, tak korupce nehrozí, pak jste velmi naivní. Dodávku v takovém případě totiž neprovádí výrobce technologie. Provádí ji nějaká společnost navázaná na politiky, která technologii i práci někde nakoupí. A jestli ta společnost zaplatí za licence nějakému MS, RedHatu nebo Sunu, to je jí celkem jedno. Hlavně že ze zakázky vypadne pro určené lidi dost hotovosti.

"OpenOffice můžete běžet" určitě není spisovné, ale často podobné věci můžete slyšet. Samozřejmě to pochází z anglického "to run", "you can run OpenOffice".

V Mnichově založili distro LiMux nejprve na Debianu, a později na různých verzích Ubuntu, doplněných o KDE a různě customizovaných.

Ad polyfunkční příšernosti - překlep, měl jsem na mysli polofunkční příšernosti.

Ad následujících deseti letech, bude to velký úspěch, protože to bude vzor, že i bez MS to jde - pokud je politickým cílem nějaká údajná svoboda bez ohledu na vhodnost k použití, produktivitu, cenu a další aspekty, tak je to jistě velké vítězství. A samozřejmě se tím nevytvoří závislost na autorech Open/LibreOffice, společnostech jako je Canonical, neprohloubí se závislost na vlastním IT týmu atd., a všechno bude lepší a svobodnější :)

Noční směna je dnes ve formě.
Šetřete síly. Noc je ještě mladá a zas tak vysoké ty gáže nejsou.

"pokud je politickým cílem nějaká údajná svoboda bez ohledu na vhodnost k použití, produktivitu, cenu a další aspekty"

Vy jste jim tam dělal nějaký audit ohledně vhodnosti k použití a produktivity? O ceně se bavit vůbec nebudu, protože žádný reálný audit o reálných cenách, včetně nákladů na zaměstnené vs. nezaměstnané, migraci nezaměstnaných, produkční spotřebu zaměstnaných, DPH, atd. neexistuje.

"neprohloubí se závislost na vlastním IT týmu"

To už je podruhé v této diskuzi. Dávat přednost závislosti na zahraniční (dokonce mimo EU) společnosti před vlastním týmem, zejména u státu, může jen mimoň, nebo někdo touto společností placený.

Ad Vy jste jim tam dělal nějaký audit ohledně vhodnosti k použití a produktivity - nedělal. Ale mám představu o dostupnosti SW pro Linux , a není to žádná výhra. Mám také vícekrát vyzkoušený Linux s OOo, a proti Windows s MSO je to dost slabota.

Ad přednost závislosti na zahraniční (dokonce mimo EU) společnosti před vlastním týmem, zejména u státu, může jen mimoň - k tomu se vyjádřím v tom druhém příspěvku.

v práci jedu na w7, celkem slušný stroj 2x3GHz, 6GB DDR, poslední dobou je zralý na vyhození z okna, laguje, od začátku mi každou chvíli zablokuje doménovýus účet k serverům, prostě hnus (2-4 denně mám vynucenou 10 min pauzu pro zablokovaný účet, IT si s tím nevědí rady),

win servery v pátek pravidelné restarty

prostě hnus a navíc fialový.

Pokud vám počítač laguje, použijte Performance Monitor a pořiďte si záznam performance counters. Zpětně pak můžete analyzovat, kde byl problém.

Pokud se vám blokuje účet, je třeba zapnout auditing. Tam zjistíte, kdo se pokusil o neplatné přihlášení. Na prvním místě bych ale doporučil vymazat všechna hesla z password manageru. Je to nejpravděpodobnější příčině.

Pokud vaše IT oddělení neumí takovéhle základy, není problém v SW :)

Ad vlastní distro... na starosti to měl jeden (slovy JEDEN!) linux programátor - wow, jenom jeden? Super. V ČR jsou lidé levní, a pokud je ten člověk levný i v rámci ČR, třeba vystačí s 50k Kč hrubého. To je pro firmu náklad 810k Kč ročně, což je pro ilustraci cena OEM licence Windows na 410 stanic ročně. A to je jen (citace) JEDEN(!) člověk, na kterém je navíc firma nezdravě závislá (dovolená, nemoc, výpověď). V zahraničí jsou samozřejmě mzdy násobně vyšší, takže ten poměr bude ještě daleko horší.

Ad za 10 let nedokázali migrovat, víte nějaké podrobnosti - zajímavosti z vyjádření Peter Hofmanna (LiMux project leader):
- Devadesát procent [používaných] aplikací je přístupných z Linuxu. Většina byla portována, některé běží jako web apps, ve virtualizaci, nebo na terminálových serverech. To BTW znamená, že 10% aplikací dále běží jen na fyzických Windows. V jiném článku uvádí jako příklad bankovní SW ve finančním oddělení.
- Výrobu distra LiMux, jeho deployment a top level support provádí 25 lidí. Při mediánovém platu €41 235 ročně, 35% odvodech a 25 lidech je v přepočtu 16 700 175 Kč, což je cena 8452 OEM licencí Windows každý rok. A to se jistě vyplatí :). V praxi to bude dražší, protože nejde o adminy. Na každodenní administraci a supportu samozřejmě pracuje řada dalších lidí, a jejich počet Hofmann raději neuvedl.
Zdroj: http://www.techrepublic.com/article/how-munich-rejected-steve-ballmer-and-kicked-microsoft-out-of-the-city/

BTW v jiném článku Hofmann uvádí, že k LiMuxu nemají koupenou žádnou externí podporu. Takovému IT oddělení nelze než popřát hodně štěstí :)
http://www.pcworld.com/article/2082460/moving-a-city-to-linux-needs-political-backing-says-munich-project-leader.html

Ad Cena není jediný validní argument - jaký jiný validní argument tedy vidíte? Menší dostupnost SW, horší dostupnost lidí na trhu práce, větší závislost na vlastním IT týmu?

"To je pro firmu náklad 810k Kč ročně, což je pro ilustraci cena OEM licence Windows na 410 stanic ročně. "

A co když jich má 411? :-) nebo 8411... Tam už nám ta matematika výhodnosti začne drhnout, co. Mezní náklady na další instalaci prostě na nulu u windows pro celý trh a bez dementního omezování funkčnosti, počtu připojených uživatelů a podobných PR krávovin co sypou peníze ze závislých oveček Microsoft (tedy zatím) nedá :-). A to nemluvím o tom, že své řešení může daná firma také bez omezení prodávat dále i kdyby za nějakou symbolickou částku. Pořád to bude víc než s Windows.

"Ad Cena není jediný validní argument - jaký jiný validní argument tedy vidíte? Menší dostupnost SW, horší dostupnost lidí na trhu práce, větší závislost na vlastním IT týmu?"

Selský rozum mi říká že je vždy lepší být závislý na svém vlastním IT týmu, který mohu ovlivňovat dle svých přání než být závislý na firmě za oceánem, která mi za pár let řekne milý chlapče, končíme s podporou, tvé kdysi zaplacené licence ti jsou už reálně na nic a pokud nechceš za týden spravovat spambot díky nezalepitelným dírám v systému, kup si od nás pěkně rychle licence nové. Kdyby tento argument byl správný, tak i Microsoft by si objednával veškeré práce u externistů (ale je pravda že občas to tak vypadá, takže možná jste o krok vepředu :-D).

Ad co když jich má 411 - všiml jste si, že jsem psal o 410 licencích *ročně*? Pokud byste kupoval nové licence Windows po sedmi letech (což odpovídá upgrade WinXP na Win7), je těch licencí najednou 2870.
V každém případě ale zůstává u Windows výhoda daleko lepší dostupnosti SW, adminů i zkušených uživatelů, plus snazší komunikace s okolím.

Ad je vždy lepší být závislý na svém vlastním IT týmu... než... na firmě za oceánem - jo, možná je to lepší. Jenže ne pro firmu, ale pro členy toho týmu :)
Ta firma za oceánem funguje déle než váš IT tým, a vyškolení specialisté jsou k dispozici všude po světě v hojném množství. O ukončení podpory nějaké verze SW se samozřejmě firma dozví několik let předem, jak to bylo známo i u Windows XP. Jestli jste to vy postřehnul ukončení podpory WinXP týden předem, kdy o tom mluvili i na TV Nova, vypovídá to něco o vás, ne o výrobci Windows.

Ad kdyby tento argument byl správný, tak i Microsoft by si objednával veškeré práce u externistů - mýlíte se. MS dělá SW, a například budovy si nechává stavět externími firmami, protože je to věc kterou neumí a nechce dělat. Podobně masokombinát vyrábí maso, a IT je pro něj jenom nutný náklad, stejně jako elektřina nebo topení. Masokombinát nechce dělat IT business, vyvíjet produkty, a v podstatě nechce ani mít žádné IT; jediným důvodem pro existenci IT v takové firmě je zvýšená efektivita. Na IT business nemá odborníky, knowhow, management, marketing ani prodejní kanály. Podobně jako si nestaví služební automobily, nechce si stavět distra Linuxu.

Ad ze byste kupoval i HW, protoze XP HW na 7 vetsinou neni nic moc - pokud se jedná o stroje s CPU Pentium 233MHz a 64MB RAM, nejlépe se 14" CRT monitory, tak je asi fakt budete muset vyměnit. Pokud ale budete chtít nějaké dnešní mainstreamové distro Linuxu, a jet na něm ten šnečí LO/OO a třeba pár tabů browseru (zaměstnanci přece nutně potřebují Facebook a flashové hry), tak se tomu také nevyhnete.

Ad zkuseny uzivatel se s prechodem na Linux nejak srovna - skoro bych řekl, že čím zkušenější uživatel, tím větší problém. Pokud uživatel umí jen otevřít browser a napsat URL, je mu dost jedno, jaký má OS. Pokud používá Excel, píše v něm makra a používá podnikový IS psaný pro Windows, bude mít s přechodem daleko víc problémů.

Ad snazsi komunikaci mate na mysli - situaci kdy druhá strana "zcela nezvykle" používá aplikace jako Word, Excel, PowerPoint, AutoCAD, Photoshop, Illustrator.

Ad kdy se vas ta firma za oceanem zepta na cislo kreditky a pak vam rekne, ze mate rebootovat a kdyz to nepomuze, tak preinstalovat - to se vám stane, když máte OEM licenci desktopových Windows a pletete si support s helpdeskem. Pokud máte podepsaný kontrakt na support s vyřešením problému do daného času od nahlášení, vypadá situace trochu jinak.

Ad kdyby budovy byly staveny jako Widle - to není o Windows. Kdyby byly budovy stavěné jako SW, byli bychom všichni dávno mrtví. Nedávno jsem v diskusi psal, že i ty browsery, které zpracovávají pár set HTML tagů, jsou děravé jak řešeto. Důvodem je stav SW průmyslu. Jazyky jako C a C++ jsou z hlediska stability a bezpečnosti výsledných produktů dost katastrofické.

Mam tu vemi nebezpecnou aplikaci v C# ... dodavateli se jeste ani jednou nepovedlo pozmenit SQL dotaz v ni ... bez toho, aby se to cele neposralo. Pouziva na to totiz uzasne nastroje M$ ... a aby to fungovalo, musi nejdriv smaznout cely konektor ... ono to totiz nejde zmenit bez pristupu do databaze ... coz se na druhy strane zemekoule dela blbe, takze ve finale dycky nekdo prijede, a prekompiluje to na miste.

;D

Aha. Takže dodavatel napsal aplikaci pomocí wizarda, protože neumí ADO.NET. A navíc pro jistotu nemá pro vývoj kopii produktivní databáze, asi aby se mu lépe testovalo. Jo, ten problém bude jistě v nástrojích od MS :D

Myslím, že jsem nedávno zjistil, co za tím stojí a musím říct, že tentokrát má LO plnou pravdu.

Tři týdny nazpátek jsem musel z donucení sáhnout na aplikačku s GUI pro widle, psanou v C++ a pod M$VS 2008. Otřesný zážitek. Ono to totiž používá GUI v C# (ani se ti pakoně nepokusili schovat marshalling do knihoven C++, takže to musí člověk sám řešit v appce furt dokola jak vůl u žentouru. A Lael, jako správný odkojenec M$, přece ví, že k chybám v implementaci jejich kompilátoru C++ se přidají chyby v marshallingu COMu a chyby v komponentech psaných v C# a kdoví co ještě... Kdežto kdyby to psal jenom v tom C#, může si marshalling a druhý kompilátor ušetřit.

Tohle ovšem neplatí, pokud použiju Qt pod KDE apod. Tam se naopak ty mezistupně začnou s Javou a s C# hromadit...

Ad zavisi hlavne od daneho programatora - souhlas. Záleží jestli je to člověk. Pokud ano, tak dělá chyby, protože lidé jsou už takoví (zřejmě je tak stvořil nějaký geniální designér k obrazu svému). C/C++ bohužel k těm chybám vyloženě svádí. A když k nim dojde, tak často aplikace "vyhnije zevnitř", protože se někde něco přepsalo, a zjistíte to podle toho že se chová divně.

Samozřejmě to poněkud zjednodušuji. Ale faktem je, že současný neutěšený stav SW průmyslu, kdy se například v rozšířených browserech objevují *stovky* bezpečnostních děr ročně, je do značné míry daný výběrem technických prostředků.

Ad je lepsie Java alebo C# - z hlediska spolehlivosti a bezpečnosti je oboje lepší než C/C++. Java je pěkný jazyk, ale díky té snaze o WORA se v ní řada věcí prakticky nedá napsat. C# je stejně pěkný jazyk, ale navíc stojí na daleko bohatším frameworku. Na druhé straně pokud potřebujete psát něco pro Unixy, tak většinou vítězí Java, jak to ukazují třeba Oracle a IBM.

Buď to, nebo stovky bezpečnostních děr ročně. Zatím se zdá, že zákazníci tolerují ty stovky bezpečnostních děr ročně.

Důvody používání C/C++ jsou často čistě historické. Samozřejmě C/C++ je na tom lépe ohledně výkonu, i když u unmanaged C# je rozdíl minimální. Jenže zrovna CPU se u dnešních PC více-méně fláká, takže bych to neviděl jako problém. Multiplatformnost se dost přeceňuje, navíc u C/C++ zdaleka není samozřejmá. Nezapomínejte také, že v C# můžete dneska psát pro Windows, Xbox 360, MacOS, iOS, Android, Linux, BSD, PlayStation 3, Wii...

Budoucnost je podle mě v projektech typu Singularity a jazycích jako Spec#. Vzhledem k použití C# to přináší daleko menší náchylnost na chyby, a Spec# přináší snazší formální verifikaci kódu. Až se tam dostaneme, SW bude řádově spolehlivější a bezpečnější.

Nepleťte si singularitu a černou díru. Místo toho si přečtěte tohle:
http://research.microsoft.com/apps/pubs/default.aspx?id=69431
http://research.microsoft.com/apps/pubs/default.aspx?id=81154

"Multiplatformnost se dost přeceňuje..."

To jo, proto vůbec nevidíme masívní rozmach internetových aplikací, že :-)

"Nezapomínejte také, že v C# můžete dneska psát pro Windows, Xbox 360, MacOS, iOS, Android, Linux, BSD..."

Než psát multiplatformní aplikaci v C#, to 100x radši Javu, nebo klidně Python + WxWidgets a C++ pro na výkon náročné části.

"Budoucnost je podle mě v projektech typu Singularity a jazycích jako Spec#."

A všude postavíme bazmeky na "zelenou energii", aby vůbec ty mašiny s potřebným výkonem mělo co pohánět :-) To jsou vyhlídky.

Ad masívní rozmach internetových aplikací - jejich hlavním přínosem je absence instalačního procesu. To že můžete intranetovou aplikaci použít na iPadu je příjemný bonus.

Ad než multiplatformní aplikaci v C#, to 100x radši Javu, nebo klidně Python - vývojáři mobilních aplikací mají C# celkem rádi.

Ad všude postavíme bazmeky na "zelenou energii" - taková představa mě dost děsí

Ad mašiny s potřebným výkonem - dost se mýlíte. U Software-Isolated Processes vám odpadá spousta režie. API call má cca 8x nižší režii, vytvoření SIP 14x nižší režii proti klasickému procesu, message ping/pong 6x nižší režii, režie syscallu úplně odpadá. Samozřejmě v jiných situacích můžete ztratit řekněme až třetinu hrubého výkonu, ale část z toho dostanete zpátky díky výše zmíněné nižší režii.
http://research.microsoft.com/apps/pubs/default.aspx?id=69431

U inetových aplikací je absence instalace jedním z hlavních, nikoliv jediný hlavní přínos. Vypadá to všude stejně, používá se to všude stejně, nezáleží na OS.

"vývojáři mobilních aplikací mají C# celkem rádi"

No a? Lidi mají různé věci, které já nemusím, nebo rovnou nesnáším.

"taková představa mě dost děsí"

To mě taky.

vývojáři mobilních aplikací mají C# celkem rádi.
Ale jistě, proto jsou nabídky práce plné „hledáme schopné C# programátory pro Android“ a Javu už nikdo nenabízí :-D

Pokud potřebujete psát jen pro Android, tak není problém s Javou. Pokud chcete psát pro Android, iOS a Windows Phone, jednou z mnoha mála možností je Xamarin, tedy C#.

Jenže to není proto, že by C# bylo tak super a vývojáři jej měli rádi, ale kvůli těm blbým Windows. Pro Android a iOS můžete psát třeba v C++, Objective-C, Qt nebo Pythonu.

Pro ty "blbé" WP můžete také psát v C++. Bohužel Android, iOS a WP mají dost rozdílné API.

No a není to jedno? Stabndardně používám C/C++, Když něco potřebuju na widle, design pattern "facade" to jistí. Když se u M$ zase koná nějaký šňupací mejdan a přejdou z Metro na Metro#, mění se implementace jenom několika tříd a všechno funguje vesele dál. A víš, že pro ostatní platformy pak nemusím do ničeho sahat? Jenom projedu unit testy a hotovo.

Facade v praxi znamená nutnost projít API všech třech platforem a napsat wrappery pro vámi používanou funkcionalitu. A aby těch rozdílů mezi platformami nebylo málo, Windows (Phone) Runtime API je navíc z velké části asynchronní.

Proč bych vlastně nemohl napsat multipatformní apluikaci? Jediný důvod proti je v dnešní době to, že CEO mrkvosoftu bude prskat jak četník ze St. Tropez, když se mu spustí dcera.

Pokud jde o C# a jeho bezchybnot, to je absolutní mýtus. Kdyby nebyl, nebyl by potřeba ve středu jeden restart navíc kvůli security updtate. Navíc M$ tlačí vývojáře do toho, aby neprogramovali defenzivně a nástroje od nich vždycky stály za staou bačkoru a rozumný microsoftí programovací nástroj jsem ještě neviděl. To "bezchybnosti kódu" pomůže ještě víc.

Koho baví v každým projektu opisovat nebo kopírovat jako blbec stejný záplaty, který nedokázal M$ narvat přímo do knohoven, resp .ajít během tesování a fixnout před releasem? koho baví dělat v IDE, kde není možnost i zobrazit hoerarchii aktuálního souboru a nefunguje refaktorování? To je pak ta práce3x delší.

Visual Source Safe je absolutně nepoužitelný. VisualStudio pro C++ je několikanásobně větší než Qt framework a uživatelský komfort kulhá ne na dně, ale nejmíň na šest noh. A jestli instaluju VM pro Javu nebo pro C# je celkem jedno, výkon a RAMka jdou do kytek v obou případech. Akorát u javy stačí poslední JRE, u C# je těch běhových rostředí vždycky na PC minimálně pět (2003, 2005, 2008, ...) A u mě jako u embeďáka by rozhodoval ještě jeden detail - Jazelle, takže C# je až úplně poslední možnost z posledních a daleko, předaleko za Javou.

Ad C# a jeho bezchybnot, to je absolutní mýtus - bavíte se o jazyku C#, nebo o konkrétní implementaci běhového prostředí?

Ad M$ tlačí vývojáře do toho, aby neprogramovali defenzivně - jak to MS dělá? A jak Google a Mozilla tlačí vlastní vývojáře, když jejich browsery mají víc bugů než MSIE?

Ad v každým projektu opisovat nebo kopírovat jako blbec stejný záplaty, který nedokázal M$ narvat přímo do knohoven, resp .ajít během tesování a fixnout před releasem - konkrétně?

Ad v IDE, kde není možnost i zobrazit hoerarchii aktuálního souboru a nefunguje redaktorování - nevím jak u vás, ale moje VS v Solution Exploreru ukazuje soubory, a když soubor expanduji, vidím objektovou hierarchii. Buď máte tou hoerarchií na mysli něco jiného, nebo nevím. A refactoring mi vs VS také funguje bez problému.

Ad VisualStudio pro C++ je několikanásobně větší než Qt Framework - jaký má smysl srovnávat velikost vývojového prostředí a běhového prostředí?
Ad C# je těch běhových rostředí vždycky na PC minimálně pět - nesmysl. Potřebujete tu verzi, pro kterou jste aplikaci napsal.

Ad Jazelle - ARMv7 architecture has de-emphasized Jazelle. Only trivial hardware support for Jazelle is now required: support for entering and exiting Jazelle mode, but not for executing any Java bytecodes. Instead, the Thumb Execution Environment (ThumbEE) is now preferred. ... ARM Holdings deprecated any use of the ThumbEE instruction, and ARMv8 removes support for ThumbEE.

Nemozem suhlasit s tym ze Java alebo C# je bezpecnejsia ako C/C++. Su to tri svety. Najlepsi kod robia ludia ked maju najlepsie nastroje a nemusia premyslat ako to pisat ale cely cas venuju tomu co pisu. To ci pisu bezpecne je zasa otazka toho ake je medzi programatormi povedomie o bezpecnosti. Kludne dokazem napisat sifrovaci nastroj v Jave ktory bude uchovavat kluce na disku v Temp adresari v nesifrovanej forme.
V Linuxe sa robi kod najlepsie v C/C++ pretoze Emacs a Vi su na to optimalizovane. Vo Windowse najradsej pisem v C# lebo Visual studio je podla mna optimalizovane na C#. O Jave by som momentalne z pohladu bezpecnosti radsej ani nehovoril, moc casto sa v nej samej objavuju diery.
A ked treba pisat nieco pre DirectX tak je tu jednoznacne C++, pisat v C# kod to by sa v hre dalo kluckovat medzi gulkami ako v matrixe :-)
A prehladace tiez radim do kategorie programov ktore musia rychlo reagovat a to ze neuvolnim v C++ 1MB RAM za hodinu nehra pri dnesnych osobnych pocitacoch taku ulohu ako spomalenie pri runtime behu.

Ad dokazem napisat sifrovaci nastroj v Jave ktory bude uchovavat kluce na disku v Temp - to jistě lze udělat

Java je bezpečná coby jazyk. Bohužel implementace JRE od Sunu je plná děr.

Ad najlepsi kod robia ludia ked maju najlepsie nastroje - nevím jaké nástroje používají autoři Chromu, Firefoxu a MSIE. Zato vím, že Chrome měl v minulém roce 245 vulnerabilities, Firefox 270 a MSIE 126.
http://secunia.com/vulnerability-review/browser_security.html

Ad to ze neuvolnim v C++ 1MB RAM za hodinu nehra pri dnesnych osobnych pocitacoch taku ulohu - takže resource leaks považujete za normální? Mohli bychom jít o krok dál, a prohlásit za normální i buffer overrun :)

JRE od Oracle je plne dier, nepametam ze by ma v dobach Sunu niekedy napadol Java trojsky kon. Co povazujete za bezpecne? Idealnu a neexistujucu implementaciu?
Ale asi ste ma nepochopil zranitelnosti pramenia z toho ze programatori nevedia robit kod bezpecne. Mozno by to chcelo knihu Myslime bezpecne v C++ tak ako bola Myslime objektovo v jazyku Java. Ale ziadnu taku knihu som zatial nevidel, ak nejaka firma ziska know-how tak si ho chrani. Mozno by mohol Microsoft ako priekopnik pomoct takymto sposobom ludstvu o par krokov vpred. Ta statistika vypoveda o tom ako daleko su v tomto smere vyvojari Firefoxu Chrome a IE a bohuzial kazdy z nich sa uci len na svojich chybach, keby zverejnovali svoje poznatky tak by tie cisla mohli byt vsetky pod sto. Ale dost fantazirovania, to sa aj tak nestane :-).
Mat tak profiler ako je v Xcode, to by sa hladali uniky pamete. Mozete si vyskusat programovat pre Macos a uvidite kolko leakov vyrobite. Predpokladam ze profilery na windowsoch su oproti profileru xcode menej striktne lebo ako si potom vysvetlit ze windows nevydrzi ani mesiac bez resetu. Oproti ipadu ktory som neresetol odkedy sa neupdatuje os a to je tak dva roky.

Ano, JRE je plné děr. Je pěkné, že Java nesvádí k chybám tolik jako C/C++, a lépe se verifikuje. Když je ale děravé JRE, je to na nic.

Programátoři budou dělat chyby vždycky, protože jsou to lidé. Zlepšení situace je možné použitím jazyků, které nejsou náchylné k chybám, a verifikací kódu. Trochu to komplikuje fakt, že OS jsou psané v C/C++, mají primární API pro určené C/C++ (Win32, libc), a nad tím teprve stavíme v C/C++ runtime knihovny pro vyšší jazyky. Je potřeba bezpečnější jazyky dostat blíž směrem k HW: do frameworků (.NET je psaný z velké části v C#), OS a driverů. A samozřejmě provádět formální verifikaci a model checking.

MS samozřejmě má nástroje pro hledání memory leaks, pro native code i managed code. Nejspíš je všechny ani neznám. Vyjma má spoustu dalších nástrojů: Static Driver Verifier, source-code annotation language (SAL) včetně driverů, jeho C runtime má pár security features... Pěkné, ale programátoři jsou nesmírně vynalézaví :/.
http://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.120).aspx
http://blogs.msdn.com/b/dotnet/archive/2013/04/04/net-memory-allocation-profiling-with-visual-studio-2012.aspx
http://www.microsoft.com/en-us/download/details.aspx?id=40336
http://msdn.microsoft.com/en-us/library/windows/hardware/ff552808(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/hh916383.aspx
http://msdn.microsoft.com/en-us/library/8ef0s5kh.aspx

Memory leaks jsou jen jedním z mnoha problémů. Práce s pamětí je v C/C++ tak divoká, že třeba ty browsery dodnes obsahují řadu chyb buffer overrun.

Ad windows nevydrzi ani mesiac bez resetu - už NT 4 mi jely bez restartu řadu měsíců. Pokud vaše Windows nepřežijí ani měsíc, nejspíš budete mít problém s drivery nebo HW.

Zdroj?

Ono je těch nebezpečí plno. A je na programátorovi, jak se k nim postaví a co využije. Třeb já mám rád statický typování. Když někde vyskočí warning "Použil jsi homotnost_v_li­brach, má být hmotnost_v_gramech" u argumentu funkce, tak je hned o spadenou raketu míň.

Stejně tak styl práce - napřed naskicuju myšlenku, pak ladím a pak refaktoruju. Je běžný, že ve skice se funkce jmenuje "poslito(t, l, *d) " místo "posliUserData(tar­get, length, *data)". A že uvnitř je třeba pět věcí, který se dají použít i jinde ve třídě. A po odladění můžu
- všechno přepisovat ručně (kdekoliv, chyby jsou jistota)
- Využít Edit - Nahradit vše a po jednom potvrzovat změny (jistota, že někde něco přehlídnu nebo nehradím co nemám)
- Využít Edit - nahradit vše bez dotazování, ale zkoušel někdo nahradit "l" za length ve všech zdrojácích globálně? Doporučuju, Laeli.
- Použít funkci pro refaktorování (Ctrl+Shift+R v Qt nebo Eclipse), napsat nový název entty a potvrdit. Vyměněno v celým projektu a jenom tam, kde to má být. Ve VS 9nejnovější, co jsem zkoušel, byla 2008) nic takovýho nebylo.

Pak zjistím, že část metody s hodí v jiné metodě funkce. Podle principu DRY z toho udělám privátní funkci. Ve VS je to ruční přepisování proměnných, vyjmutí kódu, vytvoření těšla metody, dopsání do třídy, kontrola, ... V Eclipse vyberu blok, z pop-up menu vynberu "extract function", vyberu, která z proměnných v bloku je návratová hodnota, jestli to má být funkce nebo metoda třídy a její druh (private, protected,..). Pak stačí kliknout na OK.

Chci něco z Qt hodit do GITu? CTRL+G, CTR+A - přidáno. Ctrl+G, Ctrl+C - commit. Stačilo dopsta komentář. Ty se ve widlích musíš přepnout do průzkumníka, v TortoiseGIT se proklikáváš jak blbec a práce stojí...

Dokumentace - není nad to, když si to můžu prohlídnout. Doxygen je na to ideální. A VS namá ani syntax highliht pro Doxygen komentáře, v Qt nebo v Eclipse to vidím rovnou a mám i vizuální kontrolu, že jsem zadal blbě klíčový slovo pro Doxygen.

A tak by se, ohledně nástrojů, dalo pokračovat furt.

Jsi-li masochista, trp s C#. Já zůstanu u svýho C, C++ a Javy, protože práce je tam mnohem efektivnější, než ve VS. A výsledný kód co do rychlosti, bezpečnosti, správnosti a spolehlivosti je hodně o tom, co (ne)zvládne programátor. V sbebebzpečnějším prostředí se může tát, ža napíšeš totální blbost, nebo že reportuješ do logu nešifrovaný výpisy loginu...

By the way, když jsme u logu, tak ohledně tvýho chlebodárce jsme měli na security školení dobrý příklad, jak se to nedělá. Chybová hláška "Chyba MS SQL ver x.y.z.bž v tabulce abc..." zobrazená uživateli online systému...Demon­strovali na to, kde sehnat špionážní informace, s kým vlastně hacker válčí...

Ad rename identifikátoru, extract method - oboje umělo pokud vím už Visual Studio 2005.
http://msdn.microsoft.com/en-us/library/719exd8s(v=vs.120).aspx

Ad Doxygen - fakt jste ve VS nikdy neviděl XML Documentation Features? Když před metodou napíšete třikrát slash, vygeneruje vám to dokonce stub se summary i parametry. Při kompilaci vám VS umí vyhodit XML s dokumentací, a pomocí Sandcastle ho můžete převést do HTML nebo .chm.
http://msdn.microsoft.com/en-us/library/z04awywx.aspx

Ad TortoiseGIT - ve VS se častěji používá s Team Foundation Serverem, a jeho podporu má vestavěnou. TortoiseGIT je jen jeden z klientů pro Git; existují jiní klienti s integrací do Visual Studia. VS 2013 má navíc integraci s Gitem vestavěnou. Visual SourceSafe je mrtvý minimálně od VS 2005.

Ad tak by se, ohledně nástrojů, dalo pokračovat furt - zjevně VS moc neznáte, a skončil jste někde u verze 2003.

Ad V sbebebzpečnějším prostředí se může tát, ža napíšeš totální blbost - to jistě ano. Nicméně C/C++ k chybám vyloženě svádí, a ve spoustě případů je člověk zjistí až tak, že kód nějak divně vyhnije zevnitř. Současný tristní stav SW průmyslu je do značné míry výsledkem používáním C/C++. Nemyslím si, že by v Googlu, Mozzila Foundation i Microsoftu pracovalo stádo neschopných idiotů. A přesto mají browsery stovky zranitelností ročně.

Ad Chybová hláška "Chyba MS SQL ver x.y.z.bž v tabulce abc..." - IIS ve výchozím nastavení vrací podrobnou hlášku jen pokud při lokálním přístupu. Vzdáleným klientům dává stručnou hlášku, která neobsahuje detaily typu jména souboru, tabulky apod. Bohužel neznáte IIS a na školení vám to zjevně neřekli.
http://blogs.msdn.com/b/benjaminperkins/archive/2012/06/11/displaying-detailed-error-messages-in-iis.aspx

Proč tedy MS nepřepíše Trident do C#, když je to tak parádní?

To by byla zatraceně velká investice. Pro ilustraci Firefox má cca 11M řádek kódu. MSIE sice nemusí obalovat ani duplikovat funkcionalitu OS, ale přesto je to velký projekt.

Další problém je v knihovnách používaných Tridentem. API OS je psané pro C/C++, a spousta API propadá na volání Win32. Navíc managed code přináší oproti nativnímu jistý overhead, a ten při běhu na klasickém OS není možné stlačit.

Podle všeho nás čeká spíš celkem dlouhá cesta. Aplikace se budou psát ve WinRT, což zajišťuje interoperabilitu mezi managed a unmanaged kódem, a umožní to postupnou náhradu starého kódu za nový.

"wow, jenom jeden? Super. V ČR jsou lidé levní..."

Blabla. Podstatná byla i tato část: "který to zvládal s přehledem". Víte, oni ten server instalují svým zákazníkům se svými aplikacemi. Kolik by stály licence při cca 500 instalacích, na které se připojuje (ať to nepřeženu) 5000 lidí? Odpovídat nemusíte, mě to ani moc nezajímá. Ono totiž ne vše je jen o nějakých stupidních licencích.

Ad migrace: takže je uveden jeden typ nemigrovaného SW: bankovní aplikace. O zbytku nevíme nic. Hlavně že máte pseudoargument proti.

"BTW v jiném článku Hofmann uvádí, že k LiMuxu nemají koupenou žádnou externí podporu. Takovému IT oddělení nelze než popřát hodně štěstí :)"

Inu, pokud mají vlastní distro a zaměstnávají odborníky, nikoliv klikače, nemusí být externí podpora nezbytná. BTW ani zaplacená podpora kolikrát nepomůže, stížností na nekompetentnost M$ podpory jsem četl desítky.

"jaký jiný validní argument tedy vidíte?"

Třeba vyšší zaměstnanost.

"větší závislost na vlastním IT týmu"

Větší závislost na vlastním IT týmu než na zahraniční korporaci je pro mě velice významné plus u státní správy.

Myslel jsem že je řeč o desktopu. Pokud je to určené pro servery, může to mít opodstatnění. Záleží také na konkrétní aplikaci, jestli se nevyplatí urychlit vývoj použitím technologií obsažených ve Windows. Nakonec to může ušetřit spoustu peněz. Zkoušeno na lidech.

Ad migrace: není důležitý seznam konkrétních aplikací. Důležité je to, že takové aplikace v Mnichově mají, je jich 10%, a ani po deseti letech trvání projektu je nedokázali migrovat.

Ad pokud mají vlastní distro a zaměstnávají odborníky, nikoliv klikače, nemusí být externí podpora nezbytná - dokud mají štěstí, tak externí podpora není potřeba. Pokud se vám řekněme rozsype FS tak, že nejde namountovat, ale fsck -f tvrdí že je vše OK (což se mi stalo na Linuxu doma), a stojí kvůli tomu produkce, tak by se smlouva o podpoře najednou celkem hodila. Zvlášť pokud se jedná například o větší eshop, kde hodina mimo provoz znamená ztrátu tržeb za tu hodinu. Nebo o právní kancelář, kde bez přístupu k dokumentům a mailům může dojít na veliké škody.

Ad stížností na nekompetentnost M$ podpory jsem četl desítky - doufám že nemáte na mysli stesky uživatelů s OEM licencí, kteří se diví, že MS support otevře incident jen pokud zaplatí :). Pro MS produkty si můžete si koupit i podporu s garantovanou dobou vyřešení problému. Jak garantuje dobu vyřešení problému interní IT oddělení? Nejspíš prostě doufá, že to nějak dopadne.

Ad vyšší zaměstnanost - takže Mnichov podle slov vedoucího projektu, kterému nejspíš věříte víc než já :), potřebuje v IT méně lidí než před migrací, ale podle vás jejich projekt zvýšil zaměstnanost. Wow. Nad tím se budete muset ještě zamyslet :). BTW o kolik procent ceny byste si připlatil třeba za stejné auto, kdyby se při jeho výrobě zaměstnalo o 10% lidí víc? Homo economicus by neměl dát ani korunu.

Ad větší závislost na vlastním IT týmu... je pro mě velice významné plus - pokud jste součástí toho týmu, může pro vás mít výhody :). Nicméně Mnichov je závislý na americké společnosti Canonical, na americké Apache Software Foundation nebo The Document Foundation, plus na řadě dalších dodavatelů (kterým ovšem neplatí). A k tomu na vlastních 25 lidech, bez nasmlouvané externí podpory. Když se těch 25 lidí rozhodne jít o dům dál, bude mít Mnichov neskutečný problém. Mnichov je svým způsobem rukojmí toho týmu. Kdyby měli nasmlouvanou podporu a maximalizovali použití běžných firemních produktů, dá se relativně snadno nahradit jakákoliv část týmu. Srovnání rizik závislosti na vlastním maličkém týmu (který je stejně závislý na amerických dodavatelích, jak jsem psal) a na velké americké společnosti mi vychází jasně pro tu velkou americkou společnost.

Řeč je o tom, že mít a udržovat vlastní distro není nic složitého, pokud mám někoho, kdo tomu rozumí.

Ad migrace: seznam a účel aplikací je velice podstatný. Pokud totiž nevíte, PROČ stále provozují 10 % aplikací na win, je tento argument irelevantní a nesvědčí proti přechodu na linux.

Ad podpora: jasně jsem psal, že pokud má někdo odborníky, kteří systému rozumí. Nepsal jsem, že podpora není nezbytná VŽDY. Nepochopil, nebo potřebujete za každou cenu mít svou pravdu i s nesmyslnými příklady?

Ad stížnosti: nikoliv, nešlo o OEM.

Ad zaměstnanost: a těch 10 let, které migrace trvala jako co? Ty přeskočili? Nebo celou tu migraci zvládl ten tým, který zaměstnávají teď?

"BTW o kolik procent ceny byste si připlatil třeba za stejné auto, kdyby se při jeho výrobě zaměstnalo o 10% lidí víc?"

Opět: bavíme se o státní správě a ta NENÍ soukromou společností.

"Nicméně Mnichov je závislý na americké společnosti Canonical, na americké Apache Software Foundation nebo The Document Foundation"

Není.

"A k tomu na vlastních 25 lidech, bez nasmlouvané externí podpory. Když se těch 25 lidí rozhodne jít o dům dál, bude mít Mnichov neskutečný problém."

Já si myslím, že to nejsou hlupáci a mají to ošetřeno. Vy jste ovšem "odborník" na všechno :-)

"Srovnání rizik závislosti na vlastním maličkém týmu (který je stejně závislý na amerických dodavatelích, jak jsem psal) a na velké americké společnosti mi vychází jasně pro tu velkou americkou společnost."

A přesto ta firma s vlastním distrem linuxu funguje již více než 10 let a počet zákazníků jim roste (a není zdalrka jediná). Obejdou se bez podpory velké americké společnosti. Tudíž vám to vychází špatně.

Ad mít a udržovat vlastní distro není nic složitého - pokud ho založíte na jiném distru, a neděláte příliš velké změny, může to být poměrně jednoduché. Jak jsem uváděl, v Mnichově je to jinak.

Ad seznam a účel aplikací je velice podstatný - nemusím analyzovat znát aplikace. Stačí mi vědět, že 10% aplikací v Mnichově nelze používat z Linuxu, a další běží ve virtualizaci.

Ad interní podpora: ta by systému měla vždy rozumět, ovšem má to svá omezení. Příklad s mrtvým FS mi přijde celkem výstižný.

Ad zaměstnanost, celou tu migraci zvládl ten tým, který zaměstnávají teď - předpokládám že to zvládli ve stejném počtu lidí, jaký mají teď. Přepis aplikací asi dělali externí firmy.

Ad kolik procent ceny byste si připlatil, bavíme se o státní správě a ta NENÍ soukromou společností - souhlas, státní správa není soukromou společností. A proto by měla dělat věci záměrně méně efektivně než soukromé firmy? Vždyť jsou to peníze daňových poplatníků. Státní správa by s nimi naopak měla zacházet co nejefektivněji.

Ad Mnichov je závislý na americké společnosti Canonical... Není - jak není? Pokud si založíte vlastní distro na Ubuntu a LibreOffice, jste závislý na Canonicalu a The Document Foundation. Oni vám ten SW dodávají. Pokud o přestanou rozvíjet nebo přestanou opravovat chyby, máte problém.

Ad nejsou hlupáci a mají to ošetřeno - jak?

Ad ta firma s vlastním distrem linuxu funguje již více než 10 let - super, přeji jim samozřejmě mnoho úspěchů.

Ad distro: psal jsem jasně, že je dosti překopané, tedy není to nic ve stylu vezmu distro, doplním do něj dvě své aplikace a udělám ISO. Dalo by se to v klidu k tomu Mnichovu přirovnat.

Ad podpora: jistě, potentěný filesystém vyřeší podpora jak? A BTW e-shop, který kvůli tomu lehne, si nic jiného nezaslouží.

Zaměstnanost a s tím související finance: možná to bude pro vás překvapení, ale pro stát může být ve výsledku vyhodnější zvolit variantu s vyššími počátečními náklady s tím, že zajistí práci buďto formou přímého zaměstnání nebo podporou místních firem jako subdodavatelů. To u soukromé firmy neplatí.

Ad závislost: protože jsou k dispozici zdrojáky. Vývoj či údržba může v případě krachu dotyčných firem pokračovat, nebo lze přejít na jiné výchozí distro s minimálním úsilím. Neříkám, že to není problém, je, ale má řešení a je jednodušší, než když krachne nějaký proprietární projekt, pro který náhrada prostě není.

Jak to mají ošetřeno netuším, to byste spíš měl vědět vy, když se tady oháníte tím, jak je to nevýhodné.

Ad Dalo by se to v klidu k tomu Mnichovu přirovnat - vy víte o distru LiMux víc než to, že je v současné době založené na Ubuntu? Pokud ne, jak ho chcete srovnávat s něčím jiným?

Ad potentěný filesystém vyřeší podpora jak - to už je jejich problém :). Já bych skouknul jestli sedí první NTFS boot sector proti záložnímu, a případně ho opravil. Pokud to nepomůže, tak udělat image disku, a jít si hrát s hexa editorem.

Ad stát... zajistí práci - komu? Nezaměstnaným registrovaným na úřadě práce? To asi těžko. Práci zajistí lidem z oboru IT, po kterých je veliká poptávka. A to nezaměstnanost fakt nesníží.

Ad jsou k dispozici zdrojáky - ty jsou vám jako zákazníkovi k ničemu, protože by vás financování vývoje či údržby vyšlo nesmírně draho. A jak jsem psal, v případě krachu komerční IT firmy zpravidla někdo převezme vývoj, nebo nabídne migrační cestu.

Přesné podrobnosti nevím, ale princip bude víceméně stejný, kdy se (zjednodušeně řečeno) upraví instalace, vyháže se nepotřebný balast, doplní vlastní balast a předkonfigurované GUI.

Ad filesystém: a tohle jako bude řešit placená podpora M$? Že bude dolovat ztracená data hexaeditorem?

Ad zaměstnanost: psal jsem to jako obecný přístup a dokonce jsem tam měl i podporu místních firem.

"ty jsou vám jako zákazníkovi k ničemu, protože by vás financování vývoje či údržby vyšlo nesmírně draho"

Zato přechod na jiný systém v případě krachu/zaříznutí proprietárního řešení přijde nesmírně levno :-)

"A jak jsem psal, v případě krachu komerční IT firmy zpravidla někdo převezme vývoj, nebo nabídne migrační cestu."

To je pořád dokola. Já píšu, že dostupnost zdrojáků je výhoda. Tohle je prostě fakt, který nelze popřít.

Ad FS: záleží jakou podporu a od koho si koupíte.

Ad zaměstnanost - jistě, ekonomický protekcionismus přináší samé skvělé výsledky. Doveden do důsledku do můžete vidět třeba v Severní Koreji :)

Ad přechod na jiný systém v případě krachu/zaříznutí proprietárního řešení - riziko toho, že MS zařízne Windows nebo MS Office, vidím jako poměrně malé. Daleko menší, než že vývoj OO/LO ustane. Upřímně, od doby co do toho nelije peníze Sun také skoro ustal.

Ad dostupnost zdrojáků je výhoda - pro zákazníka zanedbatelná. Pro výrobce SW je to naopak silná nevýhoda.

Ad rozprodani uplne vseho do zahranici - komu jinému jste v devadesátých letech chtěl podniky prodávat? Ty co přišly do českých rukou mnohdy dopadly jako Poldi Kladno. Ty prodané do zahraničí dopadly spíš jako Škoda Auto.

Ad byly [sic] bychom na tom v podstate stejne jako ta Severni Korea - spíš jako Ukrajina nebo Bulharsko. ČSSR byla průmyslově orientovaná, takže to po revoluci byl sice dost masakr, ale dopadli jsme v porovnání v mnoha jinými velmi dobře.

BTW Češi si sice rádi stěžují, ale ve skutečnosti se mají poměrně dobře. V GNP PPP jsme předstihli Řecko, Portugalsko a nově Kypr (byť ne naším snažením - měli bankovní krizi), životní úroveň trvale roste, naše byty jsou poměrně velké, máme spoustu aut, nedošlo u nás k vážným ekonomickým problémům (třeba Poláci měli v lednu 1990 *meziměsíční* inflaci 72%, Bulhaři v únoru 1997 123%) atd.

Jo, ono to je vždycky hrozně jednoduché. Čůráci z Francie přijeli zničit konkurenci. Pár detailů k věci:

Vyrábět cukr v ČR je stejně "chytré", jako pěstovat tu banány. Nemáme na to klimatické podmínky, a výroba je neskutečně drahá. Je daleko levnější cukr dovézt třeba z Brazílie. Východní blok dovážet nemohl, takže jsme tu draze pěstovali cukrovou řepu a vyráběli z ní cukr.

Vyloženou perverzí je evropská CAP (Common Agricultural Policy) týkající se (nejen) cukru. Situace před rokem 2006: EU garantovala minimální cenu cukrové řepy a výkupní cenu cukru. V důsledku těchto regulací byla cena cukru v Evropě 2x-4x vyšší než na světovém trhu. Aby dotace nebyly příliš vysoké, stanovila k tomu EU kvóty na produkci cukru. Ty byly přiděleny jednotlivým státům, které je pak rozdělovaly mezi cukrovary. A protože se nesmyslně drahého cukru v EU přesto vyrábělo příliš, exportoval se mimo EU. Cena cukru na světových trzích je ale výrazně nižší, a proto bylo potřeba vývoz cukru dotovat. Před levným dovozem chránily EU cla.
Takže EU platila obrovské dotace na výrobu i export cukru, které neměly žádný ekonomický smysl. V jejich důsledku byla EU největším světovým exportérem cukru, ačkoliv pro jeho výrobu neměla a nemá podmínky. To by nevymysleli ani Antony Jay a Jonathan Lynn, autoři seriálu Yes Minister.
Reforma v roce 2006 umožnila "převod cukru do příštího roku", a trochu snížila výkupní ceny. Zároveň v rámci restrukturali­začního programu nabídla výrobcům možnost vrátit kvótu na cukr proti finanční kompenzaci. Nyní se peče další reforma, která by snad mohla dotace kompletně odstranit. Evropští zemědělci proti (jakékoliv) reformě (tradičně) protestují.

V ČR působila mimo jiné společnost Eastern Sugar ČR, společný podnik Tate & Lyle a Saint Louis Sucre. ČR v přípravě na vstup do EU od roku 2000 přistoupila k evropskému systému kvót na cukr. Společnost Eastern Sugar ČR si opakovaně stěžovala, že jí byla přidělena kvóta na cukr jen ve výši 12% toho co měla dostat (a s čím počítal podnikatelský záměr), zatím co konkurenci byly kvóty naopak navyšovány. Společnost nakonec šla do arbitráže s ČR.
Při reformě CAP v roce 2006 nabídla EU výrobcům nevratný odkup kvót na cukr. Společnost Eastern Sugar ČR toho využila a přidělené kvóty prodala. Podmínkou byla fyzická demolice cukrovarů. Protože se ale našli zájemci o budovy, pokusila se společnost se SZIF (Státní zemědělský intervenční fond) sjednat změny podmínek restrukturalizace. SZIF žádost zamítl, a cukrovary tedy byly srovnány se zemí.

V roce 2007 Eastern Sugar ČR vyhrála arbitráž s ČR, a dostala 27,2M EUR. Podle arbitrů bylo důvodem neobjektivní jednání MZe při rozdělování kvóty na cukr a vytvoření korupčního prostředí.

Takže jak vidíte, cukrovary šly k zemi z následujících důvodů:
- Výroba cukru v ČR nemá smysl, a na otevřeném trhu není rentabilní.
- EU má (nejen) ohledně cukru úchylnou zemědělskou politiku s kvótami.
- ČR rozdělovala kvóty korupčně, a na Eastern Sugar ČR se dostalo málo.
- EU nabídla firmě peníze za zastavení výroby a demolici cukrovarů.
- SZIF zamítl plán na zachování budov (díky EU asi neměl jinou možnost).

Blbý nápad byla stavba nových cukrovarů v ČR. Měl byste se ptát, proč jsme vlastně ty cukrovary prodali. Na dalším místě když jsme je prodali, tak jsme neměli připustit netransparentní a korupční přidělování kvót, které zjevně vedlo k nerentabilní výrobě. Kdyby cukrovar s českými vlastníky dostal kvótu pod 12% výrobní kapacity, nejspíš by ty kvóty prodal a budovy zboural úplně stejně.

Výsledek vidím pozitivně: vyrábíme méně předraženého cukru, a lidé se mohou věnovat něčemu smysluplnému. Dotace na cukr stejně během pár let skončí (pokud šílení zemědělci nezablokují tu cukernou reformu CAP), a pak zavřou i ten zbytek cukrovarů.

http://en.wikipedia.org/wiki/Broken_window_fallacy

lol ... lael, ocekavam te dnes v 12:00 ... prid mi spravit rozesrany ntfs ...widle sem si poctive koupil ...

Vis jak funguje ta tvoje uzasna M$ podpora? Zavolam tam, s tim ze chci provest (zcela v souladu s licenci) downgrade widli (!serverovych) ... a at mi teda reknou, kde si mam stahnout tu starsi verzi, pripadne aspon SN ... a vis ty vubec jaka je odpoved?

"Tak si to nekde stahnete z warezu nebo to opiste z nejakyho lepiku" ... lol.

Ad prid mi spravit rozesrany ntfs - my spolu snad máme smlouvu o podpoře? Pokud ne, tak si mě můžete zaplatit. Dneska smůla, protože se flákám na rootu :). Zítra mám práci, o víkendu na vás kašlu, a příští týden mám čas možná ve středu. Už je jasnější, proč je lepší mít support contract?

Ad M$ podpora... stahnete z warezu - vzhledem k tomu, že se hovory na support běžně nahrávají, by mě podobné výroky dost překvapily. Pokud k tomu přesto došlo, záznam takové konverzace pošlete jejich nadřízeným.

"Když se těch 25 lidí rozhodne jít o dům dál, bude mít Mnichov neskutečný problém. Mnichov je svým způsobem rukojmí toho týmu."
No to mi připomíná třeba výhodnost řešení a la Opencard v Praze, kdy jen díky externím dodavatelům to tak krásně ekonomicky funguje a šetříme. Pokud se v Mnichově rozhodli, že si to budou dělat sami, tak asi se snaží personální otázky řešit tak, aby 25 lidí najednou neodešlo. To bychom se museli podobně zeptat, co by se stalo, kdyby odešli najednou všichni vývojáři MS: to se taky asi nestane, leda že by se MS prodalo i s Nokií někomu jinému.

Stran podpory MS mi to připomnělo třeba KMS pro Office, to jsem si fakt myslel, že si ze mne historicky dělá MS legraci, že toto mám jako nástroj pro Key Management Service, kdy to slovo "management" je tam asi omylem. Kdysi jsem zkoušel to s MS vyřešit třeba pro správu několika samostatných multilicencí (uživatelé z několika zemí se připojovali ke KMS v interní síti), ale ještě štěstí, že Win serverů jsme měli víc, tak holt jsem udělal zcela mimo jakoukoliv logiku KMS pro jinou zemi, protože nešlo spravovat víc klíčů na jednom severu. Tohle nebyla ani Beta, ani Alpha, to bylo prostě naprosto blbě. S MS jsem nápravu stavu dohodnout nemohl, protože nic lepšího neměli. V mé bezvadné náladě mi tam přistál mail od BSA (ze Slovenska), ať jim předložím seznamy licencí MS. Poslal jsem je do háje, ať se se mnou baví někdo od MS, pokud to chce vědět . Tak jsme sice museli my (při nákupech celosvětových licencí) to deklarovat pro jednotlivé pobočky a republiky, ale MS mi při své skvělé podpoře ani nemohl dát nic lepšího pro správu Office licencí než mizerný KMS.

Přechod na LO/OO je sice pracný - hlavně komunikačně. Hromada lidí vůbec třeba s Excelem neumí, ale tvrdí, že ho chce. V jedné firmě jsem nejprve na LO přemigroval majitele firmy a po dlouhé době, kdy mu nic nechybělo, naopak jsme díky doplňkům byli schopni řešit i specifická přání, jsme při výměně techniky ušetřili peníze, kdy konečně on mohl podřízeným říct, že to skutečně funguje a tak ať si nevymýšlejí blbosti. On, jakožto majitel firmy, ušetřil x desítek tisíc za Office licence, moje cena za správu byla naprosto stejná.

V bývalé firmě, když to byla ještě garážovka, se to řešilo jednoduše. Majitel používal M$ opice a papírování moc nebylo, každý věděl, co se dělá, stačil jeden kompl s kancelářským balíkem...

Pak jsme se rozšířili o deset lidí během půl roku. Najednou přibylo i dokumentace pro ostatní zaměstnance a s tím spojené administrativy. Navíc vývoj pro Linux, takže se řešla nějaká univerzálka. Ukázal jsem šéfovi, co jde udělat tehdy ještě v OpenOffice, že to jde vykopnout přímo do PDF bez nějakýho Acrobata atd. Tak prý to prubne. Po týdnu bylo rozhodnuto - M$O sůatnou, ale jenom dvě licence - u šéfa a u sekretářky. A všichni povinně OO. Ono se to moc nezdá, ale u malé firmy licence za 10 litrů x 15 lidí při rychlým rozšíření je celkem poznat... Místo licencí na kanclbalík používaný 10% času se tak pořídilo několik přístrojů - druhý osciloskop a zdroje s vytížením 40% pracovní doby. A o tom to je.

To musí být letitý příběh. Export do PDF umí MS Office už 7 let, a před tím šlo použít virtuální tiskárnu (která se stejně hodí, pokud chcete PDF i z jiné aplikace). Microsoft Office pro podnikatele také stojí okolo 5000 Kč (multilicence je jistě levnější), ne 10000.

tisk do souboru (PDF a Postcript) umí Linux přímo v tisku i bez dodatečné virtuální tiskárny PDFcretor apod u win nutných doplňků,
to je to co vy nazýváte u MSO2010 "Export do PDF umí MS Office už 7 let" ,

LO/OO má podle mě více přímý export na rozdíl od xklikacího exportu u MSO.

Ad tisk do souboru (PDF a Postcript) umí Linux přímo - to bude tím, že se na Linuxu většina věcí tiskne za použití PDF a PS.

Ad LO/OO má podle mě více přímý export na rozdíl od xklikacího exportu u MSO - nechápu co máte na mysli. MS Office 2007 (SP2 a vyšší - před tím to byl doplněk ke stažení zdarma) má export do PDF prostě v menu File/Save As jako jeden z formátů. Samozřejmě se export do PDF dá používat třeba z kódu makra. Mimochodem včetně PDF/A.

Ad "výhodnost" řešení a la Opencard - hledáte problém na nesprávném místě. Skutečné problémy jsou tyhle:
1. Podle informací z denního tisku se někteří lidé na radnici se rozhodli dát projekt Opencard firmě, na kterou byli finančně napojeni.
2. Projekt byl cca 10x předražen proti původním odhadům.
Problém není v použití externího dodavatele. Problém je v tom, že projekt (podle informací z denního tisku) použila jistá skupina lidí k vlastnímu obohacení.

Ad se snaží personální otázky řešit tak, aby 25 lidí najednou neodešlo - to se může stát celkem snadno. Například pokud se u nějakého ukáže, že nemít nasmlouvanou podporu k produktům byla chyba, a dojde ke sporu s vedoucím projektu. Pokud se sbalí a půjde jinam, jistá část týmu ho může následovat. Viděl jsem podobné věci několikrát.

Ad KMS pro Office - bohužel MS KMS jde mimo mě, takže bez komentáře.

Ad Hromada lidí vůbec třeba s Excelem neumí, ale tvrdí, že ho chce - a pak je tu hromada lidí, kteří s Excelem umí, a proto ho chtějí. A zrovna tahle hromada je celkem důležitá.

Ad on mohl podřízeným říct, že to skutečně funguje - jako způsob protlačení změny je to dobré. Jestli majitel firmy opravdu umí používat Excel nebo Calc, a jestli umí posoudit případy jeho použití zaměstnanci, to je úplně jiná otázka.

Ad my meli najednou nekolik desitek tisic zapornych licenci - měli jste si nechat udělat licenční audit, a chtít od MS peníze za ty záporné licence :)

No, mě by jen zajímalo, kolik lidí (a když se bavíte tak hezky v číslech), za jakou mzdu by bylo potřeba na správu těch 410 stanic s MS? Teď mi prosím spočítejte tu výhodnost...
Respektive jinak. Mějme firmu dejme tomu s 5 servery a 80 stanicemi. Pokud jede vše na Linuxu, tak úplně bez problémů to zvládnou dva lidé s průměrným platem 50k Kč (a to dělají i jiné věci, jinak by se ukousali nudou). Kolik lidí a za jakou mzdu musí být zaměstnáno, pokud stanice pojedou na MS a servery na Linuxu tak, aby byl provoz stejně kvalitní = stane se maximálně dvakrát do roka, že je problém a já nemůžu půl dne pracovat, než mi IT spraví počítač (a s tím dvakrát do roka si myslím dost přeháním).
Čekám na Vaši kalkulaci výhodnosti. Pokud mě přesvědčíte, předložím klidně návrh vedení firmy na krok zpět k MS :)

Ad mějme firmu dejme tomu s 5 servery a 80 stanicemi - záleží na použitých produktech, na prostředí, a na tom co od IT očekáváte. Běžnou síť malé firmy tohoto rozsahu mohou samozřejmě bez problému administrovat dva lidé.

To je jiná věc. Ale proti tomu je jednoduchá obrana, dát do smlouvy větu "Dílo bude provedeno podle aktuálně platných norem, RFC a mezinárodních standardů." nic takovýho ani Silverlight, ani M$IE nesplňuje, pak ale nezbývá než dodavateli jednoduše škrtit penězovod do doby, než to uvede do stavu podle smlouvy.

nedávno jsem viděl webovou databázi pro malé organizace a tu údajně vývojáři vyvíjejí jen pro FF,Chrome apod, pro IE není vyvíjena jelikož IE nedodržuje standarty a neumožňuje některé funcionality.

http://www.ikpo.cz/