10 let s projektem util-linux (diskuse)

[_]

To je ten vůl, co vyhodil ddate?

[Conscript89]

A co jsi udelal ty?

[_]

Stovky komitů do kernelu.

[xkucf03]

A udělal jsi i git push nebo to máš jenom u sebe?

[k3dAR]

spis udelal make a na disku mu to vyrobilo spoustu souboru, tak ma pocit ze to je ten commit ;)

[k3dAR]

ne, ten vul ses ty ;)

k3dar@xubuntu1404:~$ dpkg -S bin/ddate
util-linux: /usr/bin/ddate

[xkucf03]

Jakou máš distribuci/verzi?

$ dpkg -S bin/ddate
dpkg-query: vzoru *bin/ddate* nevyhovuje žádná cesta

$ dpkg -S bin/date
coreutils: /bin/date

$ uname -r
4.4.0-57-generic

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.1 LTS
Release:        16.04
Codename:       xenial

Ani jsem to neznal – tak jsem se díval, co to je, a moc nevidím důvod, proč by to mělo být v util-linux.

[k3dAR]

psal sem to do hostname ;) Xubuntu 14.04, na netbooku s 16.04 sem na tom teda jako ty...
ale stene je to vul to podtrzitko ;) a kdyz na to ted koukam tak Karel Žák zrusil vychozi buildovani ddate, nasledne kompletni vyrazeni uz provedl po roce nekdo jinej (Karel Žák byl jen commiter), s tim ze soucast je tam i odkaz kam se ddata presouva... podle me je to cele naprosto v poradku, tuplem s uvazenim o co v ddate jde, priste prijde nekdo ze by se do util-linux mel dostat sdate ;)

http://packages.ubuntu.com/xenial/ddate

Tak co, vole? Raději žádná reakce na můj předchozí komentář?

Ah, ok, přehlédl jsem tvůj komentář výše.

[Conscript89]

Tak ve Fedore to neni v util-linux, ale v balicku ddate, coz koresponduje s komentari od dalsich.

[Newpac]

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář

[the.max]

Jen ty jsi letadlo.

[ucetni]

pan Zak je take autorem vseobjimajiciho frameworku MAPE, software ktere melo zmenit svet. Pokusil se to natlacit i sem: http://ucto.linux.cz/setkani/zapis.php (hledej MAPE). Nastesti se uchytil u RH , kde jeho megalomanske predstavy pusobi jen minimum skod.

[deda.jabko]

Pokusil se to natlacit i sem: http://ucto.linux.cz/setkani/zapis.php (hledej MAPE)

To vypada na projekt, ktery je skoro stejne uspesny jako mistni pokus naprogramovat CAD pro Linux.

Zrovna kvalitní CAD pro Linux by imho ocenil velký počet lidí, stejně jako kvalitní alternativu k Photoshopu (Pixel bohužel chcípl) či kvalitní kancelářský balík (Open/LibreOffice nepočítám).

[xkucf03]

Zrovna kvalitní CAD pro Linux by imho ocenil velký počet lidí

+1 CAD je globálně použitelný, kdežto české účetnictví bude zajímat maximálně zlomek z cca. 10 milionů lidí.

stejně jako kvalitní alternativu k Photoshopu

Máme Gimp a Kritu.

Pixel bohužel chcípl

Je to škoda, byl to hodně zajímavý projekt. Dneska už asi bude trochu zastaralý, ale stejně by ho možná šlo oprášit a pokračovat ve vývoji. Autor z toho chtěl asi vytřískat prachy a když mu nikdo neplatil, tak to radši nechal chcípnout. Dneska by mohl udělat crowdfunding a po dosažení částky vydat zdrojáky pod svobodnou licencí.

kvalitní kancelářský balík (Open/LibreOffice nepočítám)

Možná je „kvalitní kancelářský“ oxymorón a správný přístup je z principu jiný – WYSIWYM editor a generování různých výstupních formátů místo kancelářského textového editoru; databáze, skripty, grafové a jiné nástroje místo tabulkového editoru…

Ve své kategorii (která je možná z principu špatná) je LibreOffice celkem dobrý. Asi by stálo za to trochu učesat GUI.

[dusan]

"CAD je globálně použitelný" - súhlas

Sledujem/podporujem freecad. Zatiaľ nepoužiteľný, ale možno o pár rokov keď pôjde vývoj ďalej niečo z toho bude.

[Petr Ježek]

Schroer Medusa?

[tomo_tn]

Catia ide spustit cez wine -- po drobnom doladeni takmer nejde spoznat rozdiel voci nativnej. Kvalitny CAD je tympadom vychytany.

[deda.jabko]

Zrovna kvalitní CAD pro Linux by imho ocenil velký počet lidí,

To urcite. Nicmene, abych pripomnel, mistni skupina pro vyvoj CADu skoncila u schuzovani a malovani obrazku bez jedineho radku kodu.

[xkucf03]

Ty bys radši, kdyby se začal bez rozmyslu bušit kód?

[deda.jabko]

Mam pocit deja vu, goto 2013.

Ted vazne, kolik neceho, na cem by se dal dalo stavet, vzniklo?

[xkucf03]

kolik neceho, na cem by se dal dalo stavet, vzniklo?

Budu mluvit jen za sebe: zabýval jsem se návrhem modulární architektury. Je to samozřejmě jen malá část toho, co je potřeba udělat, ale myslím si, že ten návrh je dobrý a že je správné, aby taková úvaha/diskuse o architektuře proběhla, než začne někdo něco programovat.

Architektura se dá později revidovat, není to nějaká posvátná kráva, ale přeci jen je dobré mít nějakou vizi, kam chceme směřovat (a v případě nutnosti ji změnit), než postupovat úplně chaoticky (což je zabiják projektu zvlášť při týmové spolupráci, protože každý může jít jiným směrem, i když každý bude mít svým způsobem pravdu).

[Sid]

Precital som si ten thread a to tam bolo odbornikov, ako v krcme pri fotbale. Ukazka ako nieco neriesit, to by som daval ako uvod pred startom projektu, ze ako nie...

[koroptev]

ten popis je extremne banalni imho

totez vznikne v hlave po minutovym premysleni

[radix]

Ty bys radši, kdyby se začal bez rozmyslu bušit kód?

Presne tak. IMHO lepsi investovat cas do tvorby nejakeho prototypu - tam clovek pozna ty skutecne problemy a vyzvy (ne jak to udelat, aby byl program perfektne modularni). Refaktorovat za chodu tak, jak se to zrovna hodi pro aktualni stav projektu. Architektura se nejspis X-krat prepise, ale tak uz to chodi.

Takove diskuse nad architekturou vedou typicky jen k bikesheddingu. Proste to udelej tak, jak je to momentalne nejjednodussi (vyprdni se na modularitu) a res problemy az prijdou.

Misto krasneho designu na papiru mozna budes mit monoliticky skaredy program, ktery aspon neco dela. Myslim, ze to druhe je lepsi a ze se z toho i vic naucis o dane domene.

[pavlix]

Tak hlavně kdyby byl nějaký kód, tak by tady bylo o čem mluvit. Jestli se tu chtějí lidé poplácávat po zádech, že před dvěma lety počmárali pár papírů, tak si myslím, že mají docela těžkou konkurenci v každé školce. Jako jo, mít osobní radost z toho, že si někdo povídal o architektuře, je samozřejmě fajn, ale čekat, že to ostatní ocení je pitomost. To by se v oceňování věcí, nad kterými někdy někdo přemýšlel, ani nezastavili.

[xkucf03]

Jako jo, mít osobní radost z toho, že si někdo povídal o architektuře, je samozřejmě fajn, ale čekat, že to ostatní ocení je pitomost.

Cílem nebylo, aby někdo ocenil „povídání o architektuře“, ale předejít některým chybám a ušetřit čas v budoucnu. Chyba, která se odhalí při analýze/návrhu, se opravuje nejlevněji, chyba, která se odhalí při vývoji, je dražší, chyba, která se odhalí při testování, je ještě dražší, a úplně nejdražší je chyba, která se odhalí až v produkci.

Současně jsem tím sledoval osobní zájem – naučit se dělat modulární aplikace v C++ – čekal jsem, že v té diskusi někdo poradí, jak na to. Bohužel jsem se moc konkrétních řešení nedozvěděl – jen, že je to prý jednoduché. Přesto skutečně modulárních aplikací v C++ je málo – požadavky jsou v komentářích pod tím blogem – jde o to, aby se ta modularita promítla i na úrovni distribučních balíčků (.deb, .rpm…), aby šlo moduly dynamicky přidávat a odebírat (nemusí být nutně za chodu programu, ale musí to být možné tam, kde je program nainstalovaný), moduly musí jít kompilovat nezávisle na sobě, pro kompilaci modulu musí stačit minimum kódu (definice rozhraní – ne že kvůli tomu budu muset mít celý ten systém), musí jít kombinovat moduly zkompilované různými lidmi v různou dobu, moduly musí být možné je verzovat samostatně v nezávislých úložištích… a je k tomu potřeba nějaký šikovný nástroj pro sestavení (build), aby tohle všechno člověk nemusel řešit ručně hromadou kódu/konfigurace, ale stačilo k tomu pár metadat (říct, jaké má modul závislosti a co naopak poskytuje).

[deda.jabko]

Chyba, která se odhalí při analýze/návrhu, se opravuje nejlevněji, chyba, která se odhalí při vývoji, je dražší, chyba, která se odhalí při testování, je ještě dražší, a úplně nejdražší je chyba, která se odhalí až v produkci.

Az se mi tomu nechce verit. Vy jste snad na VSE museli mit i nejaky predmet "Obhajování věčných pravd realitě navzdory".

Cílem nebylo, aby někdo ocenil „povídání o architektuře“, ale předejít některým chybám a ušetřit čas v budoucnu

Kolika chybam jste takto predesli?

jde o to, aby se ta modularita promítla i na úrovni distribučních balíčků (.deb, .rpm…), aby šlo moduly dynamicky přidávat a odebírat (nemusí být nutně za chodu programu, ale musí to být možné tam, kde je program nainstalovaný), moduly musí jít kompilovat nezávisle na sobě, pro kompilaci modulu musí stačit minimum kódu (definice rozhraní – ne že kvůli tomu budu muset mít celý ten systém), musí jít kombinovat moduly zkompilované různými lidmi v různou dobu, moduly musí být možné je verzovat samostatně v nezávislých úložištích…

A kolik modulu se takto podarilo jiz vytvorit?

Mohl bych klidne sarkastictejsi, ale asi to nema cenu. Ve vasem pripade jste proste pro formu zabili obsah. Radsi jste si vykladali o forme nez, aby nekdo resil skutecny obsah, protoze to by znamenalo skutecnou praci.

Ale na tom zaslo jiz hodne projektu, treba to vyse zmine ucetnictvi, takze neni nutne propadat do deprese.

[pavlix]

Musím uznat, že se dobře bavím.

[xkucf03]

Az se mi tomu nechce verit. Vy jste snad na VSE museli mit i nejaky predmet "Obhajování věčných pravd realitě navzdory".

Na VŠE jsme se tohle sice učili, ale pak jsem si to hodně krát ověřil v praxi.

• Je opravdu jednodušší zajít za analytikem/zákazníkem (nebo se nad věcí víc zamyslet, když to dělá člověk sám pro sebe) a některé věci si ujasnit a předělat návrh, než to naprogramovat blbě a pak se divit, že to nefunguje.
• Když přijdu na chybu během vývoje (např. díky psaní jednotkových nebo vývojářských komplexních testů nebo díky tomu, že si to po sobě přečtu), tak je oprava jednodušší (levnější), než když mi chybu nahlásí tester. Mám to totiž ještě v krátkodobé paměti v hlavě, nemusím dělat nový commit, merge, přepínat se myšlenkami z jiné práce/projektu zpět na tohle.
• Když na chybu přijde tester ještě před nasazením do produkce, tak se předejde ostudě a případným věcným škodám, nemusí se znovu nasazovat, nemusí se vydávat nová verze + vše jako v předchozím bodě (vývojář to má v hlavě, nemusí vzpomínat, co dělal před týdnem/měsícem/rokem).

Kolika chybam jste takto predesli?

U toho CADu to nejde říct, protože nedošlo na realizaci. U jiných projektů to ale byla spousta chyb, kterým se podařilo předejít. Oproti tomu si představ nějakého alibistického vývojáře, který to naprogramuje podle špatného zadání, aniž by o něm diskutoval (chtěl ho změnit) – on má sice „splněno“, ale výsledek nefunguje.

Jestli si myslíš, že to, co píšu, platí jen v „enterprise“ světě, tak to není pravda – jinde to platí snad ještě víc. Když uděláš chyby v RFC nebo obecně specifikaci resp. otevřeném standardu, tak ostatní podle toho začnou psát servery, klienty, knihovny… a pak už to jen tak nezměníš, protože by spousta lidí musela přepsat svůj kód a ještě by se museli koordinovat, aby byli kompatibilní mezi sebou. Přitom by stačilo se jen trochu lépe zamyslet při tvorbě toho standardu. Totéž platí i pro různé interní formáty nebo konfiguraci – když chyby vychytáš ještě před vydáním stabilní/produkční verze, tak o nic nejde, prostě změníš formát a u sebe si soubory přepíšeš – ale když to prošvihneš a necháš tam chybu hnít déle, tak buď ji neopravíš vůbec (stane se z toho vlastnost), nebo budeš muset psát konverzní nástroj a/nebo návody pro uživatele, aby mohli upgradovat (nebo se na to vykašleš a za to ti fakt nepoděkují).

Ve vasem pripade jste proste pro formu zabili obsah.

Že jsem si do svého blogu napsal pár slov o architektuře nikomu nebránilo, aby si nezávisle na tom psal prototyp.

Vytvořit CAD je hodně velký projekt, který vyžaduje velké investice – buď do toho musí někdo vrazit hodně peněz nebo do toho nadšenci vloží svůj volný čas – tak jako tak je to velká investice – a opravdové zlo by bylo promrhat ji kvůli odfláknutému návrhu.

[deda.jabko]

Vy jste snad na VSE museli mit i nejaky predmet "Obhajování věčných pravd realitě navzdory".

Na VŠE jsme se tohle sice učili

Tak ted uz tomu opravdu verim.

U toho CADu to nejde říct, protože nedošlo na realizaci. U jiných projektů to ale byla spousta chyb, kterým se podařilo předejít. Oproti tomu si představ nějakého alibistického vývojáře, který to naprogramuje podle špatného zadání, aniž by o něm diskutoval (chtěl ho změnit) – on má sice „splněno“, ale výsledek nefunguje.

Tomuhle se snad nemuze smat uz ani pavlix.

Že jsem si do svého blogu napsal pár slov o architektuře nikomu nebránilo, aby si nezávisle na tom psal prototyp.

V tom neni nic osobniho. On to byl skvele nastartovany projekt, mel nekolik blogovych zapisku s vasnivymi diskuzemi, webovou stranku s verzovacim systemem, promysleny navrh... akorat z toho byl jeden velky fail, protoze kazdy byl architekt, ale malokdo chtel byt ten mourenin, co bude kopat zaklady.

[deda.jabko]

Když uděláš chyby v RFC nebo obecně

To je v teto diskuzi bezpredmetne, protoze RFC odpovida verejnemu rozhrani. Coz pochopitelne u nove vznikajiciho projektu nema cenu resit. Navic RFC je casto dlouho ve fazi Draft, dokud se na implementacich neoveri, ze je zivotaschopne a pripadne se RFC upravuje podle ziskanych zkusenosti.

[xkucf03]

Proste to udelej tak, jak je to momentalne nejjednodussi (vyprdni se na modularitu) a res problemy az prijdou. Misto krasneho designu na papiru mozna budes mit monoliticky skaredy program, ktery aspon neco dela.

Tenhle přístup vede k tomu, že pořád přidáváš další a další kód… a pak se nad tím po nějaké době zamyslíš a dojde ti, že je to obludnost, která má zásadní chyby, ale už jsi do toho investoval tolik času, že je těžké to zahodit a začít znova nebo to přepsat. Pokud ten program v tu dobu má už nějaké uživatele, tak je přepis mnohem horší až nemožný, protože se musíš nějak vypořádat se zpětnou kompatibilitou.

Oba extrémy jsou špatné – a) paralýza analýzou – každý asi slyšel o projektu (nebo ho v horším případě zažil), kde se dlouze analyzovalo a nakonec se nic nevytvořilo nebo to bylo nefunkční b) programování bez rozmyslu, kde autor je zahrabaný v kódu a chybí mu nadhled – až se jednoho dne vynoří a rozhlédne (typicky po nějakém vnějším impulzu) a zjistí, že se dopracoval k programu, který má zásadní návrhové/architektonické chyby a brání to jeho použitelnosti – čemuž se dalo předejít, kdyby trochu víc přemýšlel a méně psal.

Proto máme iterativní vývoj, kde máš jednak nějakou dlouhodobou vizi (kterou průběžně aktualizuješ) a jednak plán aktuální iterace, kde si vytyčíš cíle a výstupy.

Neříkám, že prototypování nemá smysl – má – tady by ten prototyp vypadal asi tak, že vezmeš nějakou CSG a zkusíš si kolem ní postavit nějaký program. To se několikrát zopakuje s různými knihovnami, pak se nějaká vybere nebo napíše vlastní a pak se to zahodí a začne se psát skutečný program. Úvaha nad návrhem a architekturou probíhá současně s tím. Vynechat jedno nebo druhé je chyba. Nebezpečí prototypů je v tom, že jeden ten kód píše jako prototyp (tzn. rychleji a méně pečlivě) a druhý to pak vezme, řekne si, že je to docela dobré (což tak zvenku a na první pohled může vypadat) a začne na tom stavět. Všichni by měli mít jasno v tom, co se dělá – jestli prototyp/PoC k zahození, nějaká jednorázová aplikace, která bude sloužit pár dní/týdnů/měsíců, nebo software, který tu bude pět deset nebo i více let a bude se rozvíjet. Pokud v tomhle dojde k „nedorozumění“ tak to způsobuje dost vážné problémy a hodně projektů kvůli tomu dopadlo špatně.

Jedna z nejhorších vět, které si můžeš říct, je: „pak se to předělá, až bude čas“ – ten čas totiž nebude nikdy – to je smutná realita. Pokud bys náhodou měl možnost do toho ten čas investovat, tak tě to vyjde dost draho, protože předělávat kód po měsících nebo letech (nebo dokonce psaný někým, kdo už v týmu není) je daleko těžší než předělat kód, který jsi psal včera (nebo ho rovnou napsat pořádně). Když už na něčem šetřit, tak na tom, že něco neuděláš, nenapíšeš, ale ne na tom, že to tam sice je, ale je to odfláknuté – pak se na jedno špatné rozhodnutí nabalují další a další a vylepšit ten kámen, který je kdesi vespod už moc nejde.

[radix]

Tenhle přístup vede k tomu, že pořád přidáváš další a další kód… a pak se nad tím po nějaké době zamyslíš a dojde ti, že je to obludnost, která má zásadní chyby, ale už jsi do toho investoval tolik času, že je těžké to zahodit a začít znova nebo to přepsat.

Je potreba refaktorovat za chodu. Vytvaret abstrakce, jak jsou potreba, rusit je, kdyz uz jsou zbytecne. Pri programovani je potreba premyslet a ne jen busit kod.

Pokud ten program v tu dobu má už nějaké uživatele, tak je přepis mnohem horší až nemožný, protože se musíš nějak vypořádat se zpětnou kompatibilitou.

Zpetna kompatibilita je tezke bremeno. Prvnich par let vyvoje takoveho CADu by to melo byt zakazane slovo.

Oba extrémy jsou špatné – a) paralýza analýzou – každý asi slyšel o projektu (nebo ho v horším případě zažil), kde se dlouze analyzovalo a nakonec se nic nevytvořilo nebo to bylo nefunkční b) programování bez rozmyslu, kde autor je zahrabaný v kódu a chybí mu nadhled – až se jednoho dne vynoří a rozhlédne (typicky po nějakém vnějším impulzu) a zjistí, že se dopracoval k programu, který má zásadní návrhové/architektonické chyby a brání to jeho použitelnosti – čemuž se dalo předejít, kdyby trochu víc přemýšlel a méně psal. Proto máme iterativní vývoj, kde máš jednak nějakou dlouhodobou vizi (kterou průběžně aktualizuješ) a jednak plán aktuální iterace, kde si vytyčíš cíle a výstupy.

To urcite. Tvoje snaha mit projekt modularni od zacatku, a to ve smyslu doinstalovatelnych modulu je ale podle me velmi drahy luxus. Modularita na teto urovni je a) pomerne draha ficura b) nema s CADem jako takovym nic spolecneho. Svazet diskusi na takove periferni tema (v teto fazi projektu) je dost kontra produktivni.

Neříkám, že prototypování nemá smysl – má – tady by ten prototyp vypadal asi tak, že vezmeš nějakou CSG a zkusíš si kolem ní postavit nějaký program. To se několikrát zopakuje s různými knihovnami, pak se nějaká vybere nebo napíše vlastní a pak se to zahodí a začne se psát skutečný program. Úvaha nad návrhem a architekturou probíhá současně s tím. Vynechat jedno nebo druhé je chyba. Nebezpečí prototypů je v tom, že jeden ten kód píše jako prototyp (tzn. rychleji a méně pečlivě) a druhý to pak vezme, řekne si, že je to docela dobré (což tak zvenku a na první pohled může vypadat) a začne na tom stavět. Všichni by měli mít jasno v tom, co se dělá – jestli prototyp/PoC k zahození, nějaká jednorázová aplikace, která bude sloužit pár dní/týdnů/měsíců, nebo software, který tu bude pět deset nebo i více let a bude se rozvíjet. Pokud v tomhle dojde k „nedorozumění“ tak to způsobuje dost vážné problémy a hodně projektů kvůli tomu dopadlo špatně.

Opet, je potreba pri programovani premyslet a refaktorovat. Stavet na prototypu realny produkt neni problem, pokud se toto pravidlo dodrzuje. Neni nutne cely prototyp zahodit. Prototyp loguje pres System.out? Pridej log4j. Prototyp neresi transakce? Pridej transaction manager a obal do transakcniho kontextu servisni vstvu. Ze servisni vrstva neexistuje? (i v prototypu by idealne mela) Refaktoruj ji z controlleru do servisni vrstvy.

Jedna z nejhorších vět, které si můžeš říct, je: „pak se to předělá, až bude čas“ – ten čas totiž nebude nikdy – to je smutná realita. Pokud bys náhodou měl možnost do toho ten čas investovat, tak tě to vyjde dost draho, protože předělávat kód po měsících nebo letech (nebo dokonce psaný někým, kdo už v týmu není) je daleko těžší než předělat kód, který jsi psal včera (nebo ho rovnou napsat pořádně). Když už na něčem šetřit, tak na tom, že něco neuděláš, nenapíšeš, ale ne na tom, že to tam sice je, ale je to odfláknuté – pak se na jedno špatné rozhodnutí nabalují další a další a vylepšit ten kámen, který je kdesi vespod už moc nejde.

Mluvime tady o novem projektu - nebudes refaktorovat po letech, ale po hodinach, dnech, max po tydnech. Vyhodu mas v tom, ze v tom bode mas daleko lepsi prehled - vis, ktere abstrakce jsou potreba, vidis patterny v kodu. Nejsi slepy, jako kdyz se snazis predem vestit architekturu ze vzduchu.

[deda.jabko]

Toto se líbí uživateli deda.jabko.

[Petr Ježek]

Asi se každěmu nepodaří vše, co v dobrém a se znalostí věci zamýšlel. Jinak použitelných CADů je pro linuxové prostředí k dispozici celkem dost, osobně favorizuji Medusu.

[VK]

Medusu jsem tuším kdysi zkoušel, pokud je to ten CAD, kde se prvně nakreslí výkres ve 2D, a potom si z toho program vytvoří 3D model. Což je skvělé na převádění staré dokumentace do 3D, ale jinak mi to moc přirozené nepřijde. Nebo se pletu?

[koroptev]

pokud je mym cilem pouzivat cad program s nejakymi vlastnostmi tak proste poridim ten cad a zbytek veci jako co za os pod tim pobezi jsou totalni podruznosti kdyz ten os bude umet korektne pracovat s hw jako treba win tak je to koneckoncu jen plus

[k3dAR]

pokud je cilem pouzivat svobodny os, tak proste nainstaluju svobodny os a zbytek jako programy co bezi nad tim poridim svobodny sw... to ze ten svobodny os funguje korektne s hw je podstatne plus, stejne tak funkcni a inteligentni system aktualizaci... a to jsou veci ktere na nesvobodnem os win nejsou ;)

[xkucf03]

Pokud nechci, aby se mnou výhradní dodavatel, na kterém jsem závislý, za pár let vyjebal, tak budu používat svobodný software.