Oracle : dostáváme na prdel (2)

7.3.2016 00:11 | Přečteno: 5275× | plky

Dostáváme na prdel podobně jako v minulém zápisku : Oracle : dostáváme na prdel, jen to tentokrát bude stát trochu víc.

Oracle a přehled edicí / licencí

Poslední čtvrtletí roku 2015 bylo ve znamení licenčních změn ohledně Oracle DB. Na svět se vyklubala nová edice : Oracle Standard Edition Two a zanikly dosavadní Standard Edition a Standard Edition One.

Do této doby existovaly tři edice (když nebudeme počítat tu jejich free, personal, developer apod.). Těmi edicemi byly (základní srovnávací info z hlediska licencí):

• Oracle Standard Edition One
  - není možné provozovat RAC cluster
  - maximum 2 sockety na server
  - nejde použít žádné rozšíření/addon/option
  - cena na socket je 5800$
  - je možné licencovat na NUPy (named user plus)
• Oracle Standard Edition
  - je možné provozovat RAC cluster (je bundlováná s RAC option)
  - maximum 4 sockety na server, nebo jako součet všech socketů v rámci RAC (rac se tedy licenčně počítá jako jeden server)
  - nejde použít žádné rozšíření/option
  - cena na socket je 17500$
  - je možné licencovat na NUPy (named user plus)
• Oracle Enterprise Edition
  - nejvyšší edice s podporou všech funkcionalit pomocí addonů/options
  - nejde licencovat na socket, ale CPU+Core podle Oracle Processor Core Factor Table
  - je možné licencovat na NUPy (named user plus)
  

Celkem pěkný souhrn pro přehled zde : Why Not Oracle Standard Edition? - pdf

Oracle 12 - pluggable database

Velkou novinkou v Oracle 12c je Multitenant architektura, tzn. podpora kontejnerů v databázi / pluggable databáze. To by mělo usnadnit nasazení do cloudu, usnadnit správu, patchování apod. Tato funkcionalita je dostupná i v edici Standard Edition Two.
Pluggable databáze se automaticky nespouští, je na to potřeba vytvořit trigger. Asi nemá smysl popisovat, co to vše umí, na internetu jsou mnohem kvalitnější materiály. Každopádně Oracle to tlačí, seč to jen jde. Vtip přijde až posléze.

Oracle Standard Edition Two

A teď přijde první vtip. Tato edice tedy nahrazuje edice SE a SE One. Od každé z té edice si něco bere. Cena je stejná jako u SE, tj. 17500$. Cenu si tedy bere od původní SE stejně jako možnost využít RAC. Od SE One si bere limit na 2 sockety.
Dále přibyl limit na počet threadů u jedné běžící db na 16. Kdo chce tedy provozovat RAC, tak mu stačí dva jednosocketové servery s CPU, které mají 8 core (v případě intelu, jelikož HT = 16core - v případě pádu jednoho NODu se hodí), víc je zbytečné.
Kromě limitu na thready je tu další dobrý joke. Tím vtipem je implementace pluggable databáze, která je v případě SE Two omezena na 1 instanci :D. Kdo chce provozovat více pluggable databází, tak jedině s enterprise licencí.

Pokud jde o přechod z SE a SE One na SE Two, tak až vyprší zakoupený support na tyto edice, tak klienti musí cenově přejít na SE Two + kdo provozuje SE na 4 socketech, tak buď musí koupit EE edici, nebo zmigrovat na 2 sockety. Oba tábory mohou rovnou přejít na SE Two během již zakoupeného supportu.

Oracle Enterprise Edition

Tato edice je cenově o řád jinde (ano, tady už se pohybujeme v milionech), než SE Two edice. Vtip v případě EE je ten, že si oproti SE Two člověk o řád připlatí, ale je úplně bez funkcí. Základní EE totiž neumí RAC ani pluggable databáze. Na to vše je nutné zakoupit "option". Je libo podporu RAC, tak šup sem půl míče. Je libo podporu pluggable databází? Šup sem 400kkč. EE má prostě na všechno option, viz : Oracle Enterprise Edition Options
Finální cena za EE edici může tedy být několikanásobná oproti prvotní představě.

Oracle licenční audit ve firmě

Výše popsané je nakopávačka od Oracle pro všechny klienty edic SE One a pro některé klienty edice SE, nyní přijde ještě nakopávačka přímo pro nás. Tou byl licenční audit ze strany Oracle, který zajišťuje třetí strana (auditorská firma).

A jak se stane, že si vás chtějí prozkoumat? V našem případě to bylo z toho důvodu, že jsme měli nakoupeno asi 12 licencí oracle db, ale support jsme platili jen na 4, což údajně jejich systém vyhodnotil jako podezřelé a poslal k nám audit.

Audit probíhá tak, že musíte auditorskou firmu kompletně seznámit s řešením, která využívají Oracle DB + dodat schémata, co a jak se používá, co s čím komunikuje apod. Oni vám na oplátku dodají skripty, které musíte spustit na všech db serverech pod adminem. Čas na prozkoumání, co všechno ty skripty dělají, člověk má. Skripty jednak sbírají info o fyzickém železe, ale také spouštějí sql a tahají z db statistiky ohledně přístupů, nainstalovaných options apod. Výstupem jsou textové soubory. Ano, audit je založen na důvěře ke klientovi, neviděl bych problém s úpravou výstupu tak, aby vše sedělo a nikdo by nic nedokázal.

Mno, my jsme šli tou poctivou cestičkou, jejíž výsledkem byla koupě asi 10 cpu licencí na Oracle DB SE One :). Důvod byl prostý milý Watsone. Nesupportované db jsme měli linkama propojeny se supportovanou db. To se nesmí. Druhým průserem byla úprava v našem IS, kdy se před relativně krátkou dobou rozhodlo ušetřit čas a netahat jednu informaci z centrální db, ale tahat jí vždy z konkrétní db, ke které se informace vztahovala. Úprava v sw na pár řádků vlastně udělala to, že by všichni uživatelé museli být licencování na všech db (v tu chvíli si to asi nikdo neuvědomil). V takovém případě se koupě NUPů nevyplatí a šlo se cestou koupě CPU licencí. Oracle v takovém případě má i práva požadovat doplacení chybějícího supportu (v našem případě by to bylo za cca 5 let u všech těch nově dokoupených CPU licencí). Každopádně vše záleží na tom, jak budou úspěšná následující jednání/smlouvání, finální cenu/verdikt tady rozebírat nebudu.

Vtípek je v tomto případě v tom, že vše postupně centralizujeme a upouštíme od decentralizovaného řešení, které vzniklo z historických důvodů. Na pobočkách byl pomalý internet, velmi nestabilní, takže se nasazovalo co pobočka, to vlastní db + sync s centrálou. Když vypadl internet, tak to uživatelé na pobočce nepoznali a mohli fungovat, čerstvost dat z centrály jim vystačila na hodinku, někdy i déle. V dnešní době je net všude plně ok, všude vše zdvojeno + všichni chtějí mít vše hned. Postupně tedy rušíme db na pobočkách. Nakoupené licence z auditu s ročním supportem tedy nebudeme ani potřebovat.

Závěr

Důvod, proč používáme Oracle, je historický. Přechod FoxPro+dbf byl proveden na Visual FoxPro + Oracle. Od té doby se to tak jede, je nad tím postaveno hodně věcí a hodně systémů je prodrátovaných. Před delší dobou bylo rozhodnuto přepsat systém do jiného jazyka. Tím se stal C# + IIS, což jistě mnoho zdejších uživatelů stejně jako mně potěší a pohladí na srdci :)

       

Komentáře

[bigBRAMBOR]

takže vlastně jejich podezření, že se u vás děje něco nekalého bylo správné?

Oracle hráblo v bedně, asi se vedení rozhodlo, že menší instalace jim nestojí za námahu a tohle je cesta jak se jich zbavit.

[Max]

Ano, je to tak.
Zdar Max

[Max]

Resp. to byla trochu souhra nešťastných událostí. To, že vyžadují supportované db v rámci db linků je poněkud "divné". Mno a ta chybka na straně programátora to pak celé ještě zabila, navíc odstavit oracle na pobočkách bylo v plánu ještě před auditem, ale vzhledem k nedostatku času programátorů se to odložilo.
Nic z toho nebylo úmyslné.
Zdar Max

[bigBRAMBOR]

neexistuje firma stoprocentně licenčně čistá, jenom špatně zauditovaná.

[Max]

Hehe, jj :)
Zdar Max

[Max]

Jinak ani to jejich virtualizační řešení Oracle VM není pro malé instalace. Ke 100% funkčnosti jejich řešení jsou potřeba tři servery a plná licence na Oracle DB. Já osobně jsem to rozjel na jednom serveru s Oracle Express, ale taková instalace je na picatchu, protože pak ti db běží v dom0 a další věci kolem, což není moc ok.
Rozjížděl jsem to tak jen v rámci testu, nic víc.
Zdar Max

[user490]

Prečo to neprepíšete na MySQL Community Edition?

[Max]

Lol, pokusím se odpovědět v podobném duchu : "Protože chceme použít jako backend pro data databázi" :D.
Zdar Max

[pavlix]

To není v podobném duchu, ale naprostý kreténismus.

[Max]

Na vtip odpovím vtipem, který kolem MySQL koluje roky. To zda je to stále pravda, nebo ne, nehraje roli.
Prostě migrace na MySQL je krok zpět. Když už, tak na PostgreSQL.
Zdar Max

[pavlix]

Souhlasím. Šlo mi spíše o použití slova databáze namísto databázového systému. :)

[Bedňa]

PostgreSQL by som považoval za adekvátnu náhradu, aj keby bolo potrebné vraziť niečo do HW, stále je to menej ako za licencie a striehnutie neporušenia licenčných obmedzení. Tfuj, že si niekto nedokáže zarábať na podpore, serióznym spôsobom a berie MS ako etalón kvality.

[Nobody]

Pak ovsem nefnukej, ze zly Oracle, a uzivej si vyhody komercni closed source databaze plnymi dousky.

[Max]

A, tady asi někdo nepochopil, na co jsem reagoval ...
Zdar Max

[pavlix]

+1

[pavlix]

Proč? Pokud by s tím byla tak jako tak spojená nějaká větší práce, tak předělávat něco na MySQL je podle mě krok zpět.

[R]

Ked sa tym "krokom spat" usetria miliony a mozno to bude aj lepsie fungovat, tak preco nie...

[Ivan]

Nechci zacinat flame ale ackoliv jsou Oracle i MySQL "databaze" tak kazdy z tehle produktu miri uplne na jine zakazniky. Ackoliv se MySQL vyviji uz 20 let, tak porad jeste nema vlastnosti ktere zakaznici Oracle povazuji za naprosty zaklad (napr. online backup). Licencni politika Oracle je priserna a chapu kazdeho kdo od nich chce utect. Na migraci existuji urcite lepsi alternativy nez MySQL, napriklad takove ktere podporuji alespon ISO SQL92.

[xvasek]

Počky, MySQL fakt neumí online backup? Já zálohuju celé VM (za běhu), takže jsem to nikdy nehledal ani nepotřeboval, ale stejně...

Tímto příspěvkem se zatím nechci zařadit mezi lidi, kteří by nahrazovali Oracle pomocí MySQL, ale na druhou stranu na tom možná něco bude. Stejně jsou (měly by být) všechny větší systémy napsané v nějaké (objektové?) vrstvě abstrakce na DB, takže i tento možná na první pohled debilní nápad není úplně mimo. A pokud někdo používá Oracle cluster, tak buď nemá co dělat s prachama, nebo to už větší systém dle definice výše je. Jádro by mělo být ideálně přepsatelné, aby fungovalo i nad (plácnu) soubory XML s daty uzamykanými pomocí flock().

Systémy - v mém případě ERP - se kterými jsme pracoval, byly stejně všechny navržené okolo SQL úplně blbě a velká část práce / vývoje sestávala v obfuskaci vrozených vlastností SQL, takže to IMHO opravdu je relevantní směr uvažování. A pokud už mám mít nějaký stupidní datový kontejner, tak proč ne třeba MySQL.

[Max]

Neumí konzistentní. Řeší se to buď offline režimem, nebo se backup dělá na slave db, kterou lze na chvíli přepnout jen do ro, popř. stopnout.
Třeba Oracle umí konzistentní backup rmanem za pomocí checkpointů, viz : RMAN Backup Concepts
Zajímavé je také toto :
Snapshots Are NOT Backups
Docela by mně zajímalo, jaké možnosti zálohy má PostgreSQL.
Zdar Max

[Heron]

Docela by mně zajímalo, jaké možnosti zálohy má PostgreSQL.

Kdysi jsem k tomu něco ublognul. (Určitě to není vyčerpávájící seznam.) U postgresu je mnohem menší tlak na vymýšlení kravin, protože na rozdíl od MySQL (pokud používá myisam) je ta dumpovaná databáze během zálohy plně funkční a dump je zcela konzistentní, takže odpadají hovadiny typu slave do ro a jeho dump (přičemž ten slave u mysql může obsahovat cokoliv, když se poštěstí, tak třeba i konzistentní data). U PG lze dělat dump, lze dělat online backup, zamozřejmně totéž i na replikách a taky lze vzít celý svazek (pokud je jeden) a udělat jeho snapshot (v tom blogu se na konci ptám, jestli někdo provozuje pg na cow, tehdy nikdo neodpověděl, tak to provozuju sám. Snapshot jsem naposledy použil před upgrade 9.4 na 9.5.).

[Max]

Dle manuálu by ten backup měl být opravdu konzistentní. Narazil jsem třeba na toto :from my experience I can not confirm the statement that you can trust pg_dump, nebo na toto : Cache lookup failure for index during pg_dump, ale když s tím člověk počítá, tak snad ok.
Zdar Max

[Heron]

Popis té první chyby příliš nedává smysl. pg_dump je obyč. klient, který se připojuje po pq protokolu. Pokud ten server vypne, tak jeho dump určitě neudělá.

Druhá věc je objasněná snad jasně. Buď pg_dump ohlásí chybu - s tím snad zálohovací skript počítá, nebo transakce provádějící změnu schématu neproběhne (s tím by měl program také počítat). Není zde prostor pro poškození dat v db a není zde prostor pro výrobu vadného dumpu (prostě se nevyrobí žádný).

[Max]

Apropo, trochu odkloním diskusi a položím dotaz, zajímalo by mně, jakou máš zkušenost s provozem db na externím storage? Externím storage teď myslím jednu z variant iSCSI/NFS/FCoE.
Firma, co nám nabízela NetApp chtěla naše Oracle databáze připojovat přes NFS, což mi přišlo trochu jako úlet, na druhou stranu NFS v minimální verzi 4.1 na 10G lajně by konec konců nemuselo být nějak extra zlý. Každopádně i tak mi zatím asi nejlépe vychází FCoE (papírově).
Zdar Max

[Heron]

Tím myslíš provoz db přímo na fs, který je přímo nad iSCSI? Ne nemám, ale roky jsme jeli produkci nad vm, která byla na iscsci. Bez problémů.

Přímo na NFS také ne, ale přešli jsme z iSCSI na NFS (takže vm běží z NFS) a taky bez problémů.

Takže přímo jsem db nikdy na nfs nebo na fs na iscsi neprovozoval.

Jinak PG nemá žádné zvláštní nároky na FS, pouze se požaduje, aby se choval jako posix fs (což sice nikde definované není, ale tak nějak víme o co jde). A to teda zejména u (f)(data)sync apod. volání. Potom je mu šumák, jestli je to ext2, xfs, nebo nfs. Ale nezkoušel jsem to (ten nfs).

A upřímně řečeno, běh přímo nad NFS mi přijde rozumnější, než běh na xfs, blokové zařízení vm, bloková vrstva hypervizoru, soubor na NFS. Prostě je tam o pár vrstev méně. Úplně nejlepší je samozřejmně provozovat tu db přímo na HW toho storage a uspořádat disky tak (wal a tablespace), aby to tomu serveru nejlépe vyhovovalo a potom komunikovat čistě po tom db protokolu. To je rychlejší, než někam tahat bloky datových souborů po síti.

[melkors]

Nevim, jak je to ted, ale jednou jsem byl Oracle vyfu*an, ze provozovani DB na NFS neni podporovano. Ale je pravda, ze uz to je hezkych par let.

[Max]

Stejný je to s MS Exchange, ten oficiálně taktéž nelze provozovat na NFS, ale nemálo storage firem to vyhodnotily jako blbost a garantují funkčnost v případě Exchange VM na NFS. Nicméně MS si stále stojí za svém.
Jako Oracle oficiálně taktéž nepodporuje OracleDB v ESXi hypervisoru (a je jedno, jak je storage připojen), ale jen ve svých VM (Oracle VM, Solaris apod.) + pár výjimek je od big virtualizačních řešení na hw úrovní od HP apod.
Věřím tedy, že to stále nebude Oraclem podporováno.
Zdar Max

[Chulda]

no podpora pro oracle DB ve vmware je jen v případě, že VM je oracle linux a má to i zajímavé finanční dopady. Aspoň takhle mi to tvrdil náš obchodník, který to řešil s oraclem. Druhá varianta byla solaris na sunu.

[Max]

Finanční dopady to má jen v tom případě, že máš to ESXi v clusteru. V takovém případě musíš pro Oracle zalicencovat všechny servery v clusteru.
Další věcí je, že u ESXi ani jiných alternativních řešení Oracle neuznává partitioning. Když máš tedy dvouprocesorový server a Oracle s licencí na jeden CPU, tak ti Oracle neuzná, když tomu VM s Oraclem v ESXi přidělíš jen jeden CPU. Ale když to samé uděláš v Oracle VM (což je Xen), tak ti to uzná. Když to samé uděláš v XenServeru, tak ti to zase neuzná.
To je celý fór. Když máš standalone server, tak není problém ho uvirtualizovat a provozovat Oracle ve VM + k tomu ještě něco. Stále to provozuješ na stejném hw se stejnými spec. Jen to nesmíš připojit do clusteru.
Oni z Oracle a auditorských firem vždy straší a straší, ale reál je pak úplně někde jinde.
Toto jsem řešil v tom prvním blogu : Oracle : dostáváme na prdel
Zdar Max

[Chulda]

Hmm, tak to o oracle VM nějak vynechali :( Asi raději. Díky za info.

Jj, myslel jsem cluster.

[rich]

NFS je Oraclem samozrejme podporovano minimalne od verze 10G. Viz. http://docs.oracle.com/cd/B19306_01/install.102/b15660/install_overview.htm#BGBJJBFB nebo http://docs.oracle.com/cd/B19306_01/install.102/b15667/app_nas.htm Ve verzi 12c maji i vlastni DirectNFS

[Bedňa]

Snapshot, sync a mám realtime zálohu hocijakej databáze :)

[pavlix]

A při troše štěstí půjde i použít.

[Bedňa]

A při troše štěstí půjde i použít.

Dúfam že nie, je lepšie začať odznova a lepšie :)

Toto osvetlí viac.

[jekub]

ldh

[R]

Ide to aj na MySQL, ale musis predtym pouzit FLUSH TABLES WITH READ LOCK.

[EtDirloth]

Snapshot ziveho clustera (ci uz cez COW FS, alebo cp) by som robil s pouzitim pg_start_backup/pg_stop_backup - umozni to cistejsi start zo snapshotu. Alebo pouzit pg_basebackup.

Neprijemne na base-backupe je, ze bez checksumov sa v snapshotoch mozu hromadit koruptovane stranky.

[Heron]

Tak pomocí cp se živý cluster určitě kopírovat nedá, to nikdy nedopadne dobře (tam je pg_start_backup nutností). U snapshotů nevidím problém (pokud jednou db o sobě tvrdí acid, tak ať to dokáže).

pg_backup je super nástroj pro kopírování přes síť. Místo např: btrfs sub snap -r, btrfs send -> btrfs receive je pg_backup mnohem jednodušší.

Ano, na možné poškození souborů je nutné myslet i při online backup, je dobré to sem tam projet klasickým pg_dumpall ať se zkusí přečíst i ty stránky, na které se rok nesáhlo. Checksum je určitě dobrý nápad.

[Michal Kubeček]

Docela by mně zajímalo, jaké možnosti zálohy má PostgreSQL.

PostgreSQL používá, stejně jako Firebird, MGA (MVCC), takže tam backup zaživa není problém.

[tom]

napriklad takove ktere podporuji alespon ISO SQL92.

A oracle uz ISO SQL umi? Kdyz jsem s nim naposledy prisel do styku, neumel EXCEPT.

[houska]

... nema vlastnosti ktere zakaznici Oracle povazuji za naprosty zaklad (napr. online backup).

xtrabackup, provozujem 200 databazovych stroju a nikdy s tim nebyl problem

[R]

Uz v Oracle funguje LIMIT? To som povazoval za uplny zaklad v MySQL a ked som musel urobit nejaky SELECT z Oraclu, tak to neslo...

[Honza Jaroš]

Zdá se, že Oracle má ROWNUM a že ho má už nějaký pátek...

[Honza Jaroš]

A varianty pro další databáze jsou vyjmenované třeba zde.

[R]

A musis urobit vnoreny SELECT. Preco by to malo byt jednoduche, ked to moze byt zlozite? To je cely princip Oracle.

[Ivan]

Protoze databaze tu nejsou primarne od toho aby setrili programatorum praci. Oracle byvala "ortogonalni" databaze, ve smyslu ze na kazdy problem existuje prave jedno reseni. A gramatika SQL se nezasira blbostma jen proto, ze to nekdo pridal do strandartu. Implementuji je jen veci ktere jsou obecnejsi nez soucastne reseni. Napr. sekvence jsou obecnejsi nez autoincrement, imleplementace autoincrement id nic noveho neprinese. MINUS ma stejny vyznam jako EXCEPT. Returning clause je obecnejsi nez getGeneratedKeys. Rownum je obecnejsi nez LIMIT/OFFSET. Ale ANSI join je obecnejsi nez "(+)" anebo rekurzivni CTE je obecnejsi nez "CONNECT BY".

Tohle jsou veci za ktere jsou uzivatele vdecni, protoze to zarucuje zpetnou kompatibilitu. Dokonce dodnes muzete vytvorit tabulky s nazvy jako COMMIT, JOIN, PIVOT anebo MODEL a Oracle to snese. Tohle platilo az do verze 11g. 12ka dost zvlcila a prizpusobuje se noobum. Byl pridan autoincrement a LIMIT/OFFSET.

SQL od MySQL vypada jako kdyz pejsek s kocikou varili dort a je jednoznacne nejhori pro zacatecniky, kteri se SQL uci. Jsou tam veci jako podivny zapis stringu, nedeterministicky group by, vkladani vice radek najednou jednim insertem, ...

[R]

Preco by sa nemali dat vytvarat tabulky s nazvami COMMIT, JOIN, PIVOT, MODEL? V MySQL to staci zaquotovat:

MariaDB [xxx]> create table `join` (id int);
Query OK, 0 rows affected (0.19 sec)

MariaDB [xxx]> create table `create` (id int);
Query OK, 0 rows affected (0.19 sec)

MariaDB [xxx]> show tables;
+---------------+
| Tables_in_xxx |
+---------------+
| create        |
| join          |
+---------------+
2 rows in set (0.00 sec)

[pavlix]

A gramatika SQL se nezasira blbostma jen proto, ze to nekdo pridal do strandartu.

To koukám platí i pro češtinu.

[pavlix]

Tak miliony se dají ušetřit i přechodem z Oracle na papírovou kartotéku. :)

[Max]

Mno, když pominu, že je to vtip, tak nedají, protože místo jedné licence za třeba 10 míčů + 10 uživatelů by jsi musel mít barák + 100 uživatelů. Si spočítej, za jak dlouho se ti vrátí cena licence na ušetřených platech :) + nepočítám latence requestů pro zákazníky apod. :D
Když to řeknu blbě, tak jsme koupili SAP za těžký many, ale cena se asi za dva roky vrátila v podobě ušetřených platů (polovička lidí z fakturace/účetnictví mohla jít na jiné pozice, nebo do jiné firmy).
Zdar Max

[pavlix]

Nemam a nebudu mít čísla. Takže zbytečná diskuze.

[Chulda]

hehe a to ještě přijde obchodník, jestli si nechcete poslechnout novinky, protože platíte ranec a už jste pro obchodníka zajímavej. Cítí se velice dotčeně, když mu nikdo neodpovídá

[Odin1918]

Dekuji za pekny blogpost a docela obdivuji odvahu s jakou sdilite informace o svem zamestnavateli a o tom, jaky poradek mate v licencich. Nehodnotim, zda je spravne ci spatne takoveto informace verejne sdelovat, ale kazdopadne to bylo zajimave cteni a ja vam za nej dekuji.

[Chulda]

jinak ještě k tomu auditu - ten oracle DB je hroznej - loguje si i proč kdo a jak způsobil zapnutí placené funkce. Takže u bejvalého zaměstnavatele programátor zapnul kompresi tuším dumpů a tak přišli s požadavkem na zaplacení enterprise 5 let zpět. A to nebyl jediný případ, ještě tam byl třeba devel s produkčními daty (ve vývojovém prostředí nesmí být vůbec produkční data, ani vzorek) apod, takže na licencích a supportu padla většina ročníbo rozpočtu IT oddělení (tuším pár desítek mega)

[Max]

My jsme měli taktéž zapnuté nějaké volby od vývojáře, co si hrál, ale prokázali jsme, že to je omyl a že to nepoužíváme, takže to auditor nakonec přešel a dodal návod, jak tu blbost zase odebrat.
Jinak my jsme naštěstí neměli devel licenci pro vývoj, ale SE One pro 10 NUPáčů, takže produkční data ok.
Zdar Max

[Chulda]

tak to byla asi nějaká option, ale na změnu z enterprise na standard je jediná cesta - přeinstalovat. BTW, překlopení z develu na ostrý provoz to samé - nutnost smazat všechna data a oni to poznají z toho výstupu toho skriptu :(

[xkucf03]

Před delší dobou bylo rozhodnuto přepsat systém do jiného jazyka. Tím se stal C# + IIS

Takže s vámi vyjebal jeden výrobce proprietárního softwaru a vy teď chcete změnu, tak se chystáte nakrmit dalšího (a ještě horšího) výrobce proprietárního softwaru? Sorry, ale jestli jste takhle nepoučitelní, tak si asi nic jiného nezasloužíte.

[Max]

Asi takhle, já to nijak neovlivním, to je na šéfovi a týmu, co to píše.
S technologiemi jako takovými jsou spokojeni, takže o žádné "vyjebávce" nelze mluvit. Nás se přechod z SE na SE Two nijak nedotkne, takže tady také ok.
Mno a pokud jde o audit, tak to si posrali sami programátoři, resp. asi selhala jejich kontrola.
Dále spousta z nich dělá ve VisualFoxPro + pár nových dělá v C#. Byly snahy sehnat někoho s javou, ale nikdo se nenašel. Je tedy myslím logické, že když máme lidi, co umí C# + ostatní si k němu již několikrát čuchli, tak se půjde cestou, kterou znají/umí.
Mno a se C# už moc aplikačních serverů na výběr není :D.
Zdar Max

[podlesh]

Myslím že výměna VisualFoxPro za C# asi není nic kontroverzního, spíš by mě zajímalo zda k tomu IIS ještě přihodíte i SQL server nebo zda budete pokračovat s Oracle (pokud ano, tak to vypadá na pěkný blog-seriál ).

[Max]

Ano, zůstáváme u Oracle.
Nový IS se tedy píše pomocí : C# + Oracle + Entity Framework + IIS.
A bude formou web app.
Jinak "Entity Framework" je samozřejmě náročný a první select trvá docela dlouho. Údajně bude používán jen u nenáročných selectů.
Dále je stále docela bujaře vyvíjen + s každou novou verzí entity Frameworku se musí čekat na Oracle, až pro něj zahrne podporu.
Tož tak k vývoji :)
Zdar Max

[radeczek]

Mno a se C# už moc aplikačních serverů na výběr není :D.

No, nové ASP .NET by teoreticky mělo jít rozběhat i na linuxu...

[Max]

Ok, až to budeš produkčně provozovat 24/7 pro 1000+ uživatelů, tak se poděl se zkušenostmi a možná to pak také nasadíme.
Zdar Max

[xvasek]

No... Popravdě bych to osobně asi minimálně vyzkoušel. Pokud srovnám náš linux-based systém s věcmi, které nativně běží na Windows řešení a se kterými musíme kooperovat, tak jsme většinou něco jako mistři světa. Je to trochu podobné, jako svého času Novel - že odešel admin do důchodu se občas zjistilo až po několika letech, kdy fyzicky začaly odcházet disky.

[radeczek]

Jasně, já jsem k tomu taky skeptický... když vidím nenažranost ASP MVC appky v IIS, tak je mi z toho blbě. Třeba se jim to podaří nějak optimalizovat a linux tomu bude svědčit... Těžko říct. Křišťálovou kouli jsem včera ztratil... Osobně bych to taky rád otestoval, čistě z "vědeckého" zájmu.

[Heron]

Sorry, ale jestli jste takhle nepoučitelní, tak si asi nic jiného nezasloužíte.

Asi tak.

Mě to lehce připomíná příběh, co mi říkal IT pracovník u policie. Že prý policie není spokojená se software co mají od dodavatelů, že když ten dodavatel přestane existovat, tak jsou v prd. (Prostě klasické problémy uzavřeného softu.)

No, tak jsem mu začal vyprávět o OSS, on (kromě nějakých kravin že za OSS se taky musí platit licence a takových těch klasických blábolů) mi říkal, že policie k OSS stejně směřuje, protože si všechno píšou v C#...

Jako fakt nevím odkud to má, jestli tam mají nějaký pravidelný brainwashing nebo MS jen pořádá pro policii dobré večírky (min o jednom říkal).

Stejně tak příliš nechápu, proč je Max na abclinuxu (než že bych ho tady nechtěl), ale blogy o MS prostředí a na každou OSS technologii reaguje dost podobně, jako ten policajt.

Tak nevím, jestli je to jen shoda, nebo je za tím nějaká pravidelná masáž.

[pavlix]

Popovídej si s lidma od firem, co jsou lokálními partnery Microsoftu. Je tam velmi dobrá masáž. Například když se řešil OpenDocument, tak většina lidí z těchto kruhů věřila, že vyšel nový standard dokumentů postavený na XML a Microsoft ho s nadšením přijal za svůj a bude tím pádem kompatibilní s Open Office a dalšími díky nasazení Office Open XML. Myslím, že už s ohledem na tuto kampaň volili i název, aby zneužili existující značku OpenOffice pro svůj vlastní „Office“ Open formát.

[pavlix]

Další masáž byla v době, kdy bylo potřeba OOXML prosadit jako ISO standard, kdy MS naháněl partnery včetně třeba různých podplacených neziskovek, aby za něj orodovali a nevypadalo to jako Microsoft kontra zbytek světa.

[Heron]

včetně třeba různých podplacených neziskovek

Jo, to jsem na vlastní oči viděl taky. Neziskovka se nechala sbalit jak levná kurva. Tak jsem se s nimi rozloučil.

[pavlix]

Většina neziskovek ani nic jiného než levné kurvy nejsou. Tím neříkám, že nepomáhají nějaké cílové skupině, ale zájmy sponzorů jsou často zájmům klientů nadřazené. Vlastně dneska neznám neziskovku, ke které bych měl důvěru mimo některých v oblasti open source. Buď jsou to pámbíčkáři a pomoc bližním je cesta, jak se dostat k dalším ovečkám. Nebo jsou to političtí aktivisté, kteří prosazují mně nepřijatelný směr.

[Heron]

No zrovna tahle pomáhá zdravotně postiženým a tak snaha těch lidí je skutečně vesměs upřímná.

Problém je jakých lidí. Jsou to většinou lidi, kteří mají mnohem větší cit než rozum, takže si nevšimnou, že "hladí až do vyhlazení". To je jedna věc. Druhá je, že jejich technické znalosti jsou zcela nulové, takže vyhazují peníze od dárců (proto taky pomáhám fyzicky, moje peníze vůbec žádný spolek nikdy neuvidí). Potom je tam šílená fluktuace lidí, většinou jsou to mladé dívky půl roku po škole, půl roku před mateřskou. Takže bez zkušeností a navíc se s tím prostředím ani neseznámí a už jsou pryč.

No a potom stačí, když jim tam přijde nějaký připravený obchoďák, tak mu podepíšou úplně všechno.

Ono je to ve skutečnosti hrozně smutný, ti lidi mají snahu pomoct, ale efektivita je v podstatě nulová a ještě se nechají ojebat každým na potkání.

[Chulda]

nějak takhle se vyvinula neziskovka "Člověk v tísni" ve firmu profíků.

Nadšení amatéři bez znalostí a zkušeností jsou ve výsledku velmi drazí. Jenže v tom případě skončíte ve velmi drsné ekonomické realitě - je omezené množství peněz od sponzorů a tak se musíte sakra snažit, abyste si urvali dost na zaplacení svých lidí a aby mohli skutečně smysluplně pomáhat a aniž by jejich vlastní rodiny potřebovaly pomoc.

[pavlix]

nějak takhle se vyvinula neziskovka "Člověk v tísni" ve firmu profíků.

Ve firmu profíků, kteří jsou pro mě snad ještě víc nepřijatelní než katolická charita.

[Max]

To jsi si bohužel udělal trochu špatný obrázek, protože :
- loboval jsem v jobu za javu a OSS, to ale neprošlo kvůli vývojářům
- snažil jsem se vybrat OSS náhradu za Exchange (před cca 2 roky), ale po otestování všech možných OSS jsem prostě musel trochu cuknout(požadavek byl outlook + activesync) a nasadili jsme KerioConnect na CentOS
- protlačil jsem místo hw externího pole Supermicro + ZFS
- zmigroval jsem náš ftp z win na linux+proftpd
- protlačil jsem svn (kdysi, teď zvažuji, že protlačím migraci na git)
- nedávno jsem protlačil redmine oproti navrhovaným komerčním řešením
- zmigroval jsem radius server z win na linux+freeradius
- naladil jsem nagios+centreon, čímž jsem nás "ochránil" od proprientálního řešení
- pro terminálový přístup jsem rozjel FreeNX a poté přešel na X2Go, jenž tepaly několik let, než se letos nasadil Citrix, který byl vzhledem k požadavkům nevyhnutelný (MS Aplikace, MS Office apod.) s tím, že i tomu jsem se lehce bránil a snažil se rozjet oVirt s jeho řešením virtualizace desktopů (obsahuje uživatelský portál a vše kolem včetně správy uživatelů apod.), což se nezadařilo kvůli vysoké zabugovanosti
- odstavil jsem komerční řešení na zálohování a nasadil rsync + btrfs
- kdyby existoval nějaký OSS pro kamery, tak už by u nás tepal, resp. přemýšlím o nasazení iSpy, ale už mám protibojovníka, který nesmyslně lpí na Geovision, i když ho musí 1x až 2x měsíčně otáčet.
- Píši o MS, případně closed source, protože jsou to většinou věci, které aktuálně řeším. Dva blogy o Oracle, co jsem vydal, mi nepřijdou moc jako poplácávání Oracle po zádech.
Budeš se divit, ale odvážil jsem se před šéfem v jednom rozhovoru zmínit EnterpriseDB (kvůli částečné kompatibilitě s Oraclem) jako alternativu k Oracle (s vidinou toho, že až by se přešlo na enterprisedb, tak už by byl jen krůček k přechodu na čistý Postgresql).
Tady pod tímto blogem jsem reagoval na nabídku nasazení MySQL a zesměšnil jsem to z důvodů již zmiňovaných (hlavně proto, že si myslím, že na takovou věc je mnohem vhodnější Postgresql a nevidím tedy sebemenší důvod bavit se o mysql).
- blog o uzavřeném archivačním GFI řešení mi také nepřijde jako nějaké chválení.
- blog o pekle v MS licencích také není pochvala směrovaná na MS
atd. atd. atd.

Ano, v některých případech máme rozdílné názory na nasazení některých produktů v komerčním prostředí, ale to je asi tak vše. Nejsem žádný zastánce MS ani Oracle ani GFI ani Geovisionu apod.
Zdar Max

[Max]

Jinak pokud správně počítám, tak poměr mých článků o OSS vůči closed source je v poměru cca 1:1. Tzn., že na jeden výblitek o closed source (který je dost často hanící) jsem napsal jeden o OSS (tzn. kolem 26 článků OSS a kolem 26 o closed).
Zdar Max

[Heron]

Ale tak přede mnou se obhajovat nemusíš, prostě mám z několika posledních diskusích (třeba rok zpět) takový pocit. Naposledy včera mě překvapila diskuse s tím pg_dumpem (nějak mě překvapilo, že by jej někdo nepovažoval za funkční nástroj - tím neříkám, že tam nemůže být bug - může, ale to může být i v tom komerčním softu, kde se to navíc budou chtít zakrýt - ale ten nástroj je prostě funkční).

Tuhle se mě ptal kámoš jak často ten linux padá a jestli už je to v pohodě. To je ing. studoval informatiku, potom si vzdělání dokončil v oboru elektroniky. Pravda je ta, že linux nepadá, v minulosti nepadal (bez komentáře prosím) a ve srovnání s win jsou to právě win, které se dotáhly na linux. Nikoliv naopak. Nevím, odkud to má.

A s tím "už je to v pohodě?" se setkávám i u jiných technologií, které jsou roky v produkční kvalitě a stabilnější než komerční soft. Najednou o nich někdo začne pochybovat. Odkud se to bere?

Což teda mimochodem platí i pro ten pg, nemůžu nevzpomenout nasazení u jednoho státního podniku, kde se nás admin ptal, jak často je potřeba to restartovat. Když jsme mu dali nechápavými výrazy najevo, že nechápeme, tak nám sdělil, že jistý dodavatel třípísmenkové firmy jim říkal, že to mají restartovat každý týden. Tak jsme mu v klidu sdělili, že máme pg s uptime 600dnů (tím neříkám, že je to dobře, jen pro srovnání).

Takže tak. Ano, některé ty zápisky nejsou ke komerčnímu softu zrovna pozitivní, to je pravda, ale z diskuse vždy tak nějak vyplyne, že je to pořád lepší, než oss.

Ano, v některých případech máme rozdílné názory na nasazení některých produktů v komerčním prostředí, ale to je asi tak vše.

Ne, problém je jinde. Nám různí dodavatelé nabízejí různé technologie. Já se zabývám ukládáním dat, takže pokud někdo nabízí "yet another" úžasný storage, tak si vezmu cenu té technologie, nabízený výkon, nabízené funkce a vždy jsem byl schopen navrhnout řešení, které toho umí víc, pořizovací náklady nula (no, můj čas) a za ty prachy se tomu ještě koupí lepší hw, tak výkonem je to taky jinde. (A jako fakt mě nezajímá, jestli to má nebo nemá grafy a u emailu je mi úplně jedno, jestli to má nebo nemá wysiwyg editor. Různý obchodníci s teplou vodu lákají nejvíc na funkce, které jsou v praxi nejvíc k ničemu.)

[Max]

Chceš vědět, kde se ta nedůvěra bere? Ohledně toho pg_dumpu jsem se na něj díval proto, protože zkušenosti s MySQL + Oracle. V prvním případě s MySQL byla obava jasná (i když teď vím, že existuje externí nástroj, který ten backup umí konzistentní).
V druhém případě byla ta obava na místě proto, protože s Oraclem taktéž není konzistentní backup samozřejmostí a v některých případech je právě potřeba si hlídat checkpointy (záleží, jaký druh backupu se dělá).
Třeba firma, co dodala SAP u nás doteď dělá 1x týdně offline backup + se provozuje standby db.
V případě Citrixu mi zas týpek říkal, že bych to měl jednou týdně otočit, s čímž jsem ho poslal tam, kam slunce nesvítí, jasně jsem mu řekl, že je konec roku 2015 a né 2005. Citrix jinak otáčím jen jednou za delší dobu, když vylezou update.
Zdar Max

[Heron]

Chceš vědět, kde se ta nedůvěra bere?

No to mi to příliš nevysvětluje. Jasně, máš zkušenosti s nějakými produkty, tak při zkoumání nových zkontroluješ, jak to tam je. Ok, v pořádku, tak by to mělo být.

Já ale popisoval něco jiného. Jsou dva produkty A a B, A je komerční, druhý je free. Oba obsahují stejnou chybu. Nevím jak ty, ale já se často setkávám s tím, že si někdo řekne ok, B taky není bez chyby, tak dál zůstáváme u Áčka (a tedy dál platíme někomu). Zdá se, že pro spoustu lidí je default prostě komerční produkt a na free nepřejdou a ještě si to (nesmyslně) obhájí tak, že ten free taky není bez chyb.

[Max]

Sice to není můj případ, ale lze takový argument chápat z několika pohledů. Buď je daný člověk lenivý migrovat, nebo se bojí, že případný problém nebude mít na koho svést, což je tedy finálně problém s managementem firmy.
Zdar Max

[Aleš Kapica]

Buď je daný člověk lenivý migrovat, nebo se bojí, že případný problém nebude mít na koho svést, což je tedy finálně problém s managementem firmy.

Tohle bych na základě svých zkušeností vypíchnul jako klíčový faktor. Pokud totiž nějaké řešení existuje, tak i přes problémy s ním spojené se do změny nikomu nechce. Důvod je prostý - už ho znají a vědí i jaké má mouchy. U nového řešení se bojí nových, dosud neznámých problémů - a to i přes to, že mohou být zcela banálního charakteru, které by na základní funkcionalitu vůbec neměly vliv.

V případě řešení, které neznají, jsou odkázáni na někoho kdo ho velmi dobře zná. A v tom je ten háček - za open source neplatí, a tak je přirozeně ani nenapadne kalkulovat s nějakými financemi za které by si poptali někoho, kdo se v problematice orientuje, aby jim dělal support - raději to hodí na krk svému ajťákovi ať se s tím nějak popasuje. No a ten to podle schých schopností nějak dá. A nebo nedá a v tom případě začne lobovat za komerční řešení, kde se jednak předpokládá nějaká záruka a případně i placený "next bussines day" support, atp.

Ve skutečnosti to sice rovněž žádná sláva není, nicméně klient žije v iluzi, že někdo problém vyřeší.

Když se pak skutečně objeví problém, tak začne dusit opět svého ajťáka, aby s tím něco udělal. Ten v případě koupeného řešení pak má v ruce alespoň pomyslnou páku a začne honit dodavatele - ten v lepším případě pošle svého supporťáka.

Opravit banalitu, obzvláště pokud ji opakovaně řeší u různých klientů, je poměrně rychlé - už ví co a jak. Jenže pokud je problém mimo kompetenci supporťáka - způsobený dejme tomu chybou v aplikaci - tak se řešení natahuje a natahuje. A to do té doby, než si klient najde řešení jiné, vyprší smlouva, nebo já nevím co všechno. Ale za těch 20 let co se pohybuji v oboru jsem neslyšel o tom, že by skutečně někdy došlo na finanční plnění náhrady škody ze strany dodavatelské firmy! Pokud někdo tedy o takovém případu víte, tak to sem napište.

[Ivan]

Ale za těch 20 let co se pohybuji v oboru jsem neslyšel o tom, že by skutečně někdy došlo na finanční plnění náhrady škody ze strany dodavatelské firmy! Pokud někdo tedy o takovém případu víte, tak to sem napište.

Stava se to. Zadny dodavatel ale nevysoli cash. Pokud jde ale o veliky prusvih, tak dostanete "slevu". Takze nejdrive zaplatite hodne penez, pak platite cca 10% z ceny za rocni support a kdyz to nefunguje, tak vam tech 10% na rok odpusti.

[Aleš Kapica]

Sleva není náhrada škody.

To je asi tak, jako kdybychom se u nás v baráku smířili s výtahem, který firma dodala totálně v rozporu se zadáním. Je menší než měl být a unese méně než má nominálně mít. Takže se to musí udělat komplet znovu. Což znamená nejenom zaplatit jinou firmu, že to postaví, ale i vyhodit to co tam napáchala ta firma předchozí. A kdo by to měl zaplatit? Podle mě logicky firma, která nedodržela zadání smlouvy. A co je vtipné? Že tahle firma - která ve výběrovém řízení uspěla jen proto, že byla levnější jen o nějakých pár desítek tisíc než firma co to bude dělat teď - si troufla naopak zažalovat naše bytové družstvo za nezaplacení poslední splátky.

Jenže to jsou peníze. Nikdo ale nevyčíslí to, že jejich "rekonstrukce" výtahu netrvala 14 dní, ale dva měsíce, takže ještě přes vánoční svátky byli nuceni důchodci z vyšších pater štrachat den co den po schodech, jen proto, že ta firma nedodržela termín. A také to, že se teď budou muset zase obejít nějaký čas bez výtahu, než bude hotov nový. A to nehovořím ještě o tom, že se ten polofunkční výtah pokusili zablokovat, aby ho nebylo možné používat vůbec. Což už vyloženě hraničí s porušováním dobrých mravů.

[Chulda]

ale od toho jsem akceptační testy, ne? Když to neprojde akceptací, nemůže se to převzít a tedy vůbec zaplatit.

Pokud se zjistí, že akceptací to neprošlo, ale chyby nejsou fatální, tak se licituje o slevě nebo se přihodí něco navíc. To samé, pokud dojde ke zdržení.

Vím, že se proplácí faktury zákazníka třeba za ISDN backup, protože si dodavatel nevšiml, že backup lajny se nepřepnul zpět. Zaplatila se faktura za adhoc prodloužení smlouvy o měsíc, protože se zpozdila překláadka apod. To je věcí smlouvy, jaká jsou penále. Pokud tam nic není, tak pochopitelně nic platit nebudou.

[Aleš Kapica]

Věc se má tak, že když ti někdo začne dělá výtah, tak máš stavební dozor, co by na to měl dohlížet. A platí se ne až po dokončení a předání stavby, ale předem. A když zjistíš, že to co ti dělají neodpovídá zadání a tak nějak doufají, že jim to projde, tak už zase tam moc možností není.

[Chulda]

jistě, ale dozor třeba neovlivní rozměr kabiny, pokud je to něco typového a to něco typového je uvedeno ve smlouvě. Může ovlivnit materiály a způsob provedení.

Ne, nikdy se neplatí dopředu všechno. Pokud ano, tak evidentně ta firma ví proč to dělá a je blbost objednavatele, že na to skočí.

Ano, v případě výtahu je pak pouze alternativa "bez výtahu".

Ale jestli se nepletu, tak k nabídce musel přiložit technickou specifikaci výtahu. Nebo jste ji nechtěli?

[xvasek]

Akceptační testy. To by zákazník musel napřed vědět, co chce.

[Chulda]

No, IBM bývalého zaměstnavatele k tomu dotlačila (chtěla je předem). Což zrovna v tom případě nebylo vůbec na škodu - zjistili sme, co vlastně chceme

[xvasek]

Tak my je taky samozřejmě děláme, ale v praxi to vypadá často tak, že zákazník není schopný napsat akceptační kritéria, tak mu je napíšeme za něj a hle, naše řešení vyhovuje.

[alkoholik]

A jak to dopada v realu konkretne u Oracle?
Budes mit roky otevrene SR s bugy, co vyvolavaji internal server errory a neresitelne problemy na krku tak jako tak..

[Max]

A ještě existuje horší varianta, než tu, co jsi popsal. Tzn., že se zaplatí firma, které řešení nasadí a pak se to hodí IŤákovi na hlavu, aby se o to staral a nemusel se platit support.
V takovém případě se admin dostane do stavu, kdy má něco spravovat a ani neví, jak to funguje. Externí firma, co instalaci provádí, sice provede i nějaké hodinové basic školení, ale co si z toho asi člověk může odnést. Navíc odmítají dát třeba i instalační postup, protože jsou to jejich interní noty.
Takto jsem se dostal ke správě Exchange (kde by default byly tak blbé hodnoty, že nám to kvůli tomu asi 3x spadlo - 3x se řešil problém se špatným výchozím nastavením), Oracle DB + Oracle iAS + pak ještě RAC + standby, ke správě Citrixu, k DMS (kde opět výchozí nastavení bylo značně poddimenzované a kvůli tomu bylo opět několik neplánovaných odstávek), ke kontrole SAPu (kde jsou stále nějaké buffery v červeným, ale jednou support v měsíční zprávě řekne, že je to ok, podruhé, že to změnil a je třeba otočit server a tak stále pořád dokola).
Zdar Max

[melkors]

Jako by mi to neco pripominalo ...

V byvale praci se nasazoval novy SW, dodavatel dal specifikaci HW, takovou, ze kluci se chytili za hlavu a se slovy "vzdyt se na tom ani nerozbehne databaze" dali masiny cca 4x vykonnejsi. Po roce nadavek ze strany uzivatelu (je to liny jak prase) prisla ta sama firma a identifikovala problem: "Nedostatecny vykon HW". Manadement ji obe studie zaplatil ...

[Ivan]

Jedna firma si z toho dokonce udelala reklamni slogan "Nobody was fired for buing IBM". Je to takova definice kruhem. Produkty fy IBM jsou pry tak dokonale, ze pokud nefunguji, tak to vlastne ani nevadi, protoze by to stejne nikdo jiny nezvladl lepe. A o tom je to je, za komenrcni produkt nese odpovednost dodavatel, se free produkt nese odpovednost ten kdo rozhoduje.

[Randy_Sh]

Tuhle se mě ptal kámoš jak často ten linux padá a jestli už je to v pohodě. To je ing. studoval informatiku, potom si vzdělání dokončil v oboru elektroniky. Pravda je ta, že linux nepadá, v minulosti nepadal

Možná si ten člověk před lety vyzkoušel linux s KDE 4.0 a teď to zkusil znovu s KDE 5. Potom se mu nelze divit.

[Max]

Hehe, jj :D.
Zdar Max

[Heron]

Ne, ten člověk viděl linux poprvé někdy v 1998 a potom intenzivně v 2001. Nikoliv na desktopu ale v serverovém nasazení. Od té doby se s ním nepřímo setkával jako prostředím pro běh služeb. Já to nepsal ani tak proto, že bych chtěl někoho kritizovat (však se to taky velice rychle vysvětlilo), ale spíše pro tu otázku "už je to v pohodě" samotnou. Protože se s tím skutečně setkávám příliš často na to, abych to považoval za náhodu (a nejen u linuxu, libovolná "rock stable" technologie je najednou předmětem otázek).

Na druhou stranu je to možná dáno dobou. Děsím se jakékoliv nutné opravy na domě, protože sehnat schopného opraváře čehokoliv začíná být nadlidský úkol (3/4 roku běžná čekací doba). Pokud je to havarijní oprava a je potřeba sehnat někoho hned, tak kvalita těch lidí je velmi nízká a kvalita práce je katastrofální (ok, vyřeší aktutní problém, ale celou věc zhorší natolik, že je stejně nutná rekonstrukce).

[Aleš Kapica]

Na druhou stranu je to možná dáno dobou. Děsím se jakékoliv nutné opravy na domě, protože sehnat schopného opraváře čehokoliv začíná být nadlidský úkol (3/4 roku běžná čekací doba). Pokud je to havarijní oprava a je potřeba sehnat někoho hned, tak kvalita těch lidí je velmi nízká a kvalita práce je katastrofální (ok, vyřeší aktutní problém, ale celou věc zhorší natolik, že je stejně nutná rekonstrukce).

Je to tak. Takže na jedné straně máme relativně malou skupinu lidí co umí všechno, protože je okolnosti donutily k tomu aby se to naučili. A ti neví co dřív. A na straně druhé zástup neumětelů co jsou naprosto v pohodě, protože ví, že těch co umí je jako šafránu a nestíhají, takže je absolutně nemohou ohrozit.

A aby si někdo nemyslel - nemám v tuto chvíli na mysli svět počítačových technologií. Kamarád je středoškolský učitel. Učí IT a jako jeden z mála opravdu dobře. Rekonstruoval barák v jedné díře. Ve své naivitě a snaze ekonomicky pomoci místním řemeslníkům se je pokoušel upřednosťovat. Dopadlo to tak, že stejně si všechno nakonec musel udělat znovu a sám. Zvrzali na co sáhli. Jeden bezmozek vedle druhého. Takže si s postupující rekonstrukcí zvyšoval kvalikfikaci od kopáče, přes stavebního dělníka až po topenáře a elektrikáře.

[Heron]

Asi tak. Já měl po koupi bytu takovou hloupou představu, že si zadám rekonstrukci elektřiny. Původní je hliník a TN-C. Ale když vidím kvalitu práce a "kvalitu" nových instalací, tak jsem od tohoto nápadu upustil. Ta moje 40 let stará instalace je na tom lépe než ty nové. Jediná chyba je síť TN-C. Jsem jediný uživatel, navíc s §5 vyhl. 50/78 (poslední zkoušky už mám teda lehce propadlé), takže nikoho ta soustava neohrožuje (a když tak zabiju jen sám sebe).

Problém je už jen najít projektanta. Ti lepší jsou nesehnatelní (nebo nezaplatitelní) a ti horší zase jedou podle stejné šablony (jedno RCD stačí, některé obvody to ani nepotřebují, počet zásuvek a obvodů se limitně blíží nule). Diskuse o tom, proč chci rcbo (jističochránič) na každý obvod už raději ani nepočítám. Pokud to nějaký projektant nechápe, tak nazdar. A to jsme se ani nedostali ke značkám přístrojů.

Takže to nakonec dopadne, že si obnovím zkoušky a udělám si to sám. Někdy.

Úplně stejné zkušenosti mám i s kolem. Mám dražšího trekka i bike, myslel jsem si, že nejlepší bude to nechat servisovat klukama, co se tím živí. Chyba. Velká chyba. Neopraví ani to, co se po nich chce, neidentifikují nic dalšího. Takže, tak jako dřív, si to prostě servisuju sám.

Takže je to přesně tak jak píšeš. Z člověka musí být elektrikář, právník, bankéř, opravář odpadů a technik. Ne, že by mi to vadilo, problém je ten, že den má jen 24h.

[bibri]

Úplně stejné zkušenosti mám i s kolem. Mám dražšího trekka i bike, myslel jsem si, že nejlepší bude to nechat servisovat klukama, co se tím živí. Chyba. Velká chyba. Neopraví ani to, co se po nich chce, neidentifikují nic dalšího. Takže, tak jako dřív, si to prostě servisuju sám.

Sice OT, ale nedá mi to - já chodím k Matesovi, je to jediný rozumný cykloservis v OL.