RMS na TEDx (diskuse)

[Dát smazat]

Díky za odkaz.

Opravdu dobrá přednáška základních myšlenek libre software.

[Bedňa]

Ja mám jeho prednášky veľmi rád. Je to frajer.

[frdrx]

Konečně prezentace, kterou má smysl šířit mezi známé.

[helment]

No nevím, vyzobrazovat uzavřený software jako otrokáře s prostěradlem přes hlavu mi přijde praštěné. Používám GNU nástroje a k tomu vyvíjím uzavřený software, kde ze záhadného důvodu neinstaluji žádné backdoory, neprodávám informace dál a ani se nesnažím klienty nijak omezovat a už vůbec je nedojím jako nějakou krávu, jak vše RMS naznačuje jako fundamentální znaky proprietárního SW.

On je totiž někdy problém se na svobodným SW uživit (viz miliardy flamů za poslední dekády). Pokud má člověk odlišnou vizi od nějaké skupiny vývojářů, která by ho mohla tak tak sponzorovat (tedy nechce pracovat pro RH, Novel, Digiu..), a kdy se musí spolehnout sám na sebe, tak to není vůbec lehký úkol, který má navíc často naprosto nulovou přidanou hodnotu. Snad jediná možnost je podpora, jenže software, který závisí na podpoře a je tak z návrhu neuchopitelný, že za ni uživatel musí doplácet, mi přijde jako produkt špatné navržený, který o vývojáři neříká nic dobrého. Já si tedy raději nechám zaplatit kvalitní vývoj a snažím se, aby nasazení a běh byly automatické záležitosti a podporu naopak nabízím zdarma.

Takže k RMS: za svobodným SW stojím a rád ho používám kvůli velkým hráčům, jejichž praktiky se mi nelíbí, ale dělat z uzavřeného SW Satana, co chce jen škodit a z lidí tahat prachy, to je od reality odtržené asi stejně, jako kůže na patě.

[frdrx]

kde ze záhadného důvodu neinstaluji žádné backdoory, neprodávám informace dál a ani se nesnažím klienty nijak omezovat

A to ti máme věřit?

[helment]

Nemusíš, ale mě to sotva přesvědčí když znám pravdu

[frdrx]

Což je případným uživatelům platný jak mrtvýmu zimník.

[helment]

Jasně, proto je lepší někoho očerňovat FUDem

[frdrx]

FUD je něco úplně jiného. RMS a další pouze konstatují, že proprietární software není zpravidla důvěryhodný, což je jasné z principu.

[helment]

Asi jsme viděli jiné video, proti tomuhle se totiž neozývám

[frdrx]

Tomu co v tom videu říká nelze nic fakticky vytknout.

[Jendа]

RMS a další pouze konstatují, že proprietární software není zpravidla důvěryhodný, což je jasné z principu.

Video jsem neviděl, ale svobodný je? Mně nepřijde.

[frdrx]

Ano, v případě svobodného můžeš ověřit, zda se nejedná o malware, případně ho upravit tak, aby nebyl. Na video se určitě podívej.

[kralyk z abclinuxu]

RMS a další pouze konstatují, že proprietární software není zpravidla důvěryhodný, což je jasné z principu.

Video jsem neviděl, ale svobodný je? Mně nepřijde.

On mluvil spíše o právech uživatele než o technických detailech - v kostce: Free software může samozřejmě taky obsahovat malware, ale nezavřou tě za to, když budeš zjišťovat co to dělá, odstraňovat malwarové funkce a redistribuovat změněný SW.

[xkucf03]

Asi tak. Tohle se dá přirovnat ke dvěma státním organizacím:

• vedoucí jedné tvrdí, že nic nekrade a s penězi daňových poplatníků nakládá hospodárně
• ta druhá organizace používá transparentní účet a zveřejňuje všechny smlouvy

Někteří lidé prostě lžou (politici a obchodníci obzvlášť), tak je lepší mít důkazy a fakta – a ne jen poslouchat líbivá slova.

[pavlix]

+1

[Miloslav Ponkrác]

-1

[Miloslav Ponkrác]

Pokud první organizace bude mít 10 × nižší náklady a 3 × větší užitečné výsledky a výstupy, než druhá organizace (o které je známo, že její účetnictví je transpúaretní a v pořádku), pak toto je pro mě dostatečným důkazem a nepotřebuji se hrabat v jejich účetnictví.

Jen jsem chtěl napsat, že důkaz lze provést mnoha způsoby.

Zastánci open source tvrdí, že kromě pročmuchání dokumentů (zdrojáků, účetnictví, dosaďte co je libo) žádný jiný důkaz neexistuje, ale to je běžná manipulace, kterou open source komunita dělá. A je jedno, jestli tuto manipulaci použil v příspěvku můj předřečník, nebo kdokoli jiné z open source komunity. Demagogie jako demagogie.

Kromě toho předstírat spoustu věcí v chodu organizace a účetnictví je už natolik zvládnuto, že kreativní účetnictví je na vysokém stupni falšování, a není to vždy tak snadné poznat, ani když ho máte k dispozici.

Samé silné řeči o kontrole zdrojáků, ale čas od času se třeba v linux kernelu objevují třeba i 10 let staré chyby. A to kernel sleduje poměrně dost lidí.

Problém je, že slovo „důkaz“ není to samé co „transparentnost“. Ačkoli jste se snažil (stejně jako to dělá open source komunita), že je to totéž.

[xxx]

Pro takovy postup volby je ale potreba mit alespon jednu OS organizaci jako referenci :).

[Hans1024]

Cetl jste tu diskuzi vubec? Svobodny software vam dava >>moznost<< zdrojaky kontrolovat. To neznamena, ze automaticky najdete vsechny bugy a backdoory, ale porad je to tisickrat lepsi, nez kdyz zadnou takovou moznost nemate.

[Fluttershy, yay!]

Instituce (nebo aplikace) není statická a pokud se věci z hlediska efektivity začnou kazit¹, transparence z principu umožní nebo aspoň výrazně usnadní nezávislý audit. Princip je stejný jako u diktatur nebo monarchií: osvícený vládce je super, ale co když mu jedne nebo jeho (dědičný) nástupce bude magor, příp. loutka?

¹ Ostatně, jak se ta efektivita pozná bez duplikace práce pomocí jiné metodologie?

[xkucf03]

Pokud první organizace bude mít 10 × nižší náklady a 3 × větší užitečné výsledky a výstupy, než druhá organizace

U těch organizací je se srovnáním problém, třeba srovnávat ministerstvo kultury a ministerstvo zemědělství je blbost – kdo má užitečnější výsledky a výstupy? I když to budou třeba dvě města s podobným počtem obyvatelstva, každé má jiné dispozice, historii, majetek, podniky na svém území… V určitých případech dává porovnání černých skříněk smysl – ovšem to neznamená, že by transparentnost byla zbytečná.

U softwaru jde zase o to, že většina těch pastí není na první pohled vidět nebo se neprojeví hned – např. kradení dat uživatele, zadní vrátka nebo třeba to, že se výrobce chystá v příštím roce výrazně zvednout ceny (a ty jsi na jeho proprietárních produktech závislý a nemůžeš jen tak hned přejít jinam). Pro běžné uživatele je pořádná zrada i takové DRM – např. vidí televizi, která umí nahrávat pořady, to jim přijde jako skvělá vlastnost, tak si ji koupí – ale až pozdě zjistí, že ty nahrané pořady si můžou přehrávat jen na té jedné televizi, nemůžou si je pouštět na chatě nebo v autě (kvůli čemuž si je nahrávali), nebo na novější televizi, když se ta původní rozbije nebo zastará.

Samé silné řeči o kontrole zdrojáků, ale čas od času se třeba v linux kernelu objevují třeba i 10 let staré chyby. A to kernel sleduje poměrně dost lidí.

V každém softwaru jsou chyby. Že se v tom otevřeném nějaké najdou, přece neznamená, že v tom uzavřeném nejsou. Naopak, uzavřenost (nezveřejnění zdrojáků) nemůže ničemu prospět a výsledek může být (za jinak stejných okolností) leda horší, maximálně stejný.

Ty „10 let staré chyby“ jsou zajimavý fenomén. Ono to vypadá hrozně skandálně, ale je to celkem pochopitelné, stačí se podívat, jak vypadají ty procesy. Většinou (jak u svobodného tak proprietárního softwaru) se dělají revize kódu bezprostředně po jeho napsání – takže se chyba odhalí buď hned nebo vůbec. Po revizích přijde testování, ale to se dělá taky v řádu dní nebo týdnů po napsání kódu. Takže jakmile chyba jednou proklouzne a přežije těch prvních pár dní/týdnů, už je dost malá pravděpodobnost, že se na ni přijde. Na ty bezpečností chyby, které nemají přímý vliv na funkcionalitu, se nepřijde ani během běžného používání. A taková chyba tam klidně těch deset let viset může, není na tom nic překvapivého.

Může se to dít u proprietárního i svobodného softwaru. Ale ten svobodný má výhodu v tom, že kdokoli na planetě může udělat audit, nebo si ty zdrojáky může prostě jen číst (třeba aby se z nich něco naučil) a chybu náhodou odhalit. Což znamená vyšší pravděpodobnost odhalení a nižší průměrnou dobu existence chyby než u srovnatelného proprietárního softwaru.

BTW: když nějaký režim zveřejní statistiku, kolik v té zemi žije feťáků, tak v očích některých může vypadat hůř než režim, který žádnou statistiku nezveřejní a jen prohlásí, že tam žádní feťáci nejsou. Ale neznamená to, že by ten transparentní režim byl horší i ve skutečnosti.

Problém je, že slovo „důkaz“ není to samé co „transparentnost“. Ačkoli jste se snažil (stejně jako to dělá open source komunita), že je to totéž.

Psal jsem „důkazy a fakta“. Pořád je to lepší než prázdné sliby. A ta transparentnost funguje i preventivně – když budu mít otevřené účetnictví a veřejné smlouvy, tak sice můžu krást nebo se chovat nehospodárně – v tom mi to fyzicky nebrání – ale vím, že se na to může snadno přijít, tak to spíš nebudu dělat – než když bude všechno tajné. Navíc ty zveřejněné informace už nejde vzít zpět a dodatečně je zfalšovat – zatímco ty neveřejné zdrojáky nebo účetnictví můžu v případě nějakého průšvihu dodatečně pozměnit.

Neříkám, že svobodný software je všelék a podmínka postačující, ale je rozhodně lepší, než ten uzavřený.

[:::]

...neinstaluji žádné backdoory, neprodávám informace dál a ani se nesnažím klienty nijak omezovat...

To je sice pekny, ze nam to tady takhle slibujes, ale kdyz ti prijde NSL a gag order, tak udelas co?

Pravda, u nas zatim NSL nechodi (pokud vim), ale myslim ze je celkem rozumny predpokladat ze jakejkoli uzavrenej sw vytvorenej v USA (a pravdepodobne mnoha dalsich zemich) je kompromitovanej.

[helment]

ale kdyz ti prijde NSL a gag order

A jak se proti tomu může bránit třeba provozovatel otevřeného systému? Pokud může nějak odmítnout třeba přístup do OSS mailového serveru, proč bych to samé nemohl udělat já? A pokud nemůže, v čem se to liší?

[pavlix]

Bránit se nemůže, ale útočník u open source čelí podstatně většímu riziku odhalení. Pokud je ten projekt komunitně spravovaný nebo dokonce nezávisle auditovatelný, je to riziko o to větší.

[helment]

Tedy za předpokladu, že zdrojový kód nasazeného produktu je stejný jako ten v CVS? To je dost naivní, ne?

[pavlix]

Nikdo netvrdil, že je open source postačující podmínkou.

[helment]

No mně jde spíše o to, že to naopak nic neřeší, protože o výsledném produktu nevíš nic. Je třeba fajn, že ábíčko tu má zveřejněné zdrojáky (pokud si tedy dobře pamatuji), ale nevidím tu nikde přístup na server, kde bych si mohl ověřit, že je nikdo na příkaz nějaké agentury neopatchoval (když už se pohybujeme v této rovině).

Jako OSS je skvělý pro jednotlivce, ale RMS ukazoval příklady služeb, které jsou tím postiženy naprosto stejně.

[pavlix]

Pokud jsi chtěl pouze tvrdit, že dostupnost zdrojových kódů sama o sobě nevede na absenci backdooru v provozním prostředí, tak s tebou samozřejmě souhlasím, jako asi všichni tady. Ale pak sis asi mohl odpustit ty litanii na téma neschopnosti se pomocí open source uživit.

[Hans1024]

Vsak Stallman zduraznoval, ze nejdulezitejsi jsou pocitace jednotlivcu, a ze posilat sva data do cloudu je spatne (a to bez ohledu na to, jestli ten cloud pouziva svobodny nebo uzavreny software).

[xkucf03]

Na tohle se hodí GNU Affero GPL, díky ní bys měl mít možnost si stáhnout přesně ten zdroják, který běží na serveru. Samozřejmě to předpokládá, že provozovatel dodržuje licenci.

Nicméně když používáš službu běžící u někoho jiného a nemáš „end-to-end“ šifrování, tak mu věřit musíš. Výhoda svobodného softwaru je v tom, že si ho můžeš provozovat i sám a pak přesně víš, z jakých zdrojáků to bylo přeložené a co ti tam běží. Takže můžeš začít na hostingu, časem si rozchodit vlastní server a pořád používáš stejnou aplikaci. Nebo naopak přejít z vlastního serveru na hosting, když se objeví někdo dostatečně důvěryhodný. Stejně tak můžeš střídat dodavatele/poskytovatele a funguje mezi nimi konkurence – ne jako když máš jeden vyhledávač od Googlu, jednu sociální síť od Facebooku…

[Grunt]

Samozřejmě to předpokládá, že provozovatel dodržuje licenci.

Kdyby to šlo zajistit technicky místo licenčně, bylo by to asi ještě o kousek lepší.

[xkucf03]

Technicky jsem to zajistil tak, že při kompilaci se vyrobí i archiv zdrojáků a přibalí k distribuovaným binárkám (a pak to jde stáhnout třeba přes web). Takže si můžeš upravit zdrojáky, zkompilovat, nasadit a tím zveřejníš i ty úpravy. (příklad)

Samozřejmě, když budeš zločinec, tak ten skript přepíšeš tak, aby přibalil jiné zdrojáky. Líp to asi udělat nejde, pokud to má být svobodný software a ne zaDRMovaná sračka (což by bylo jaksi v rozporu samo se sebou).

[Grunt]

Šlo by i líp. Interpretované jazyky těžko podvrhneš. Připojíš se na server, dostaneš sandbox, nebudeš-li věřit interpretu (dá se podvrhnout) můžeš si uploadnout a spustit vlastní interpret. Pak máš jistotu, že cokoliv budeš rvát do interpretu a dostávat jako výsledek si můžeš kdykoliv snadno zobrazit či poslat v čitelné formě a bude to přesně to co vzdáleně spouštíš. Ono by zas tak složité něco takového implementovat do nějakého protokolu nebylo. Ale furt musíš věřit, že systém na kterém interpret spouštíš není podvrhnutý a že to cpeš do interpretu a dostáváš jako výsledek je také to co si posíláš v čitelné formě. Bylo by k tomu ještě nějak potřeba ověřit, že to co běží na serveru má někde nějaké zdrojové kódy a že to není podvrhnuté. Tohle si klidně teď můžeš zkusit s SSHčkem.

[Jendа]

To nechápu. K čemu mi pomůže spustit interpret, když mi protistrana podvrhla backdoornutý procesor? Co že to má vlastně dělat?

[Grunt]

Co když bude mít v sobě protistrana TPM a ty k němu budeš mít pomocí nějakého jednoduchého komunikačního protokolu přístup? Co když ti protistrana nabídne přístup k paměti ve které běží jádro a server (aspoň ta instrukční část). Velmi snadno si ověříš, že ty věci jsou řekněme z repositářů jednoduchým hashem (samozřejmě musíš věřit že hash v databázi balíčkovače nějaké distribuce není podvržený, ale jestli platí to co kluci říkají o Reproducible builds, tak i to si budeš moct ověřit) a ne že jde o nějaký jejich tajný build typu Chrome/Chromium. Trusted Computing se dá velice snadno zneužít (v našem případě asi spíš využít) i proti druhé straně. Od dnešního dne nechci nic jiného než kompletní přístup ke zdrojákům aplikací od Googlu, možnost si ověřit že ty zdrojáky na jejich serverech opravdu běží při zpracovávání mých dat, přihlašovat se nebudu pomocí hesla ale pomocí mého veřejného klíče, druhý veřejný klíč se bude používat k ukládání veškerých mých soukromých dat k nim do databází a moje soukromé data mi můžou posílat zpátky a já už si je rozšifruju v prohlížeči svým soukromým klíčem u mě na mém počítači. A pokud ne, tak na můj login můžou klidně zapomenout. Bych chtěl vidět ten boom cloudových služeb a SaaS sraček, když by poskytovatelé ve svých databázích neměli nic jiného jen petabajty cizích šifrovaných dat. Pak nech poskytujou prostor a výpočetní čas

[Jendа]

Jak probíhá to ověřování pomocí TPM? TPM si sáhne do paměti, spočítá hash, podepíše ho a pošle mně? Jak je zařízeno, že mezi TPM a pamětí nesedí nějaká DDR proxy, která posílá jiný kód TPM a jiný procesoru k vykonání?

přihlašovat se nebudu pomocí hesla ale pomocí mého veřejného klíče, druhý veřejný klíč se bude používat k ukládání veškerých mých soukromých dat k nim do databází a moje soukromé data mi můžou posílat zpátky a já už si je rozšifruju v prohlížeči svým soukromým klíčem u mě na mém počítači

K tomu není potřeba TPM. Přihlašování klíčem je již sto let zmáknuto (např. v SSH), k šifrování při ukládání stačí třeba ohackovat GPG.

[Grunt]

Jak probíhá to ověřování pomocí TPM?

Nemám nejmenší ponětí. Do dnešního dne jsem o existenci takového zařízení neměl moc šajnu a moc mě to nezajímalo.

TPM si sáhne do paměti, spočítá hash, podepíše ho a pošle mně?

Čoveče a nechceš ti pracovat na implementaci protipiratských ochran? To není až tak špatný nápad.

Jak je zařízeno, že mezi TPM a pamětí nesedí nějaká DDR proxy, která posílá jiný kód TPM a jiný procesoru k vykonání?

Modul musí být ověřený, otevřený, důvěryhodný a komunikace musí probíhat zabezpečeným kanálem.

K tomu není potřeba TPM. Přihlašování klíčem je již sto let zmáknuto (např. v SSH), k šifrování při ukládání stačí třeba ohackovat GPG.

Data by si musel šifrovat za svůj procesorový čas. Lepší je využít poskytovatelův procesorový čas.

[Grunt]

a nechceš ti

Ach jo. Končím.

[Jendа]

Modul musí být ověřený, otevřený, důvěryhodný a komunikace musí probíhat zabezpečeným kanálem.

Leda že by paměť byla přímo uvnitř modulu a spoléhal bys, že s tím útočník neumí manipulovat.

[Grunt]

A ještě si zkus představit že se pomocí SSL/TLS připojuješ na nějaké stránky a jako součást inicializace se provede prověření TPM, jádra, démonu co ti servíruje data a možná ještě nějakých přidružených aplikací, vše samozřejmě pomocí hashů a krom zámku by ti v adresním řádku ještě vyskočila ikonka vyculeného procesoru v sluníčkově-duhových barvách. Čoveče, to by byla jiná.

[Marvin]

Celej tvuj argument je ale zalozenej na predpokladu ze NSA nema klic z TPM.

[Grunt]

To je fakt. Ale i tak už by byla implementace nějakého šmírování o řád nebo možná dva složitější. Jinak kdo říká že ty TPM musí nutně produkovat soukromé subjekty zodpovídající se nějakému státu?

[Jendа]

Jinak kdo říká že ty TPM musí nutně produkovat soukromé subjekty zodpovídající se nějakému státu?

Go for it. Vypálit křemík se stupněm integrace a výkonem dostatečným na kryptografii bohužel není něco, co by zvládl přes noc každý hackerspace.

[Grunt]

Ale nahrát do takového zařízení klíč s vhodným rozhraním zvládnu i já. Resp. pokud by klíče nahrávala neutrální a důvěryhodná instituce (v mém případě to zahrnuje Richarda Stallmanna, moji babičku a Alláha), nemám s tím problém.

[xkucf03]

Což o to, to by chtělo používat virtuální servery a na nich si provozovat vlastní prověřené aplikace, místo používání nějakých SaaS/Cloudů.. Ale pak už je jedno, jestli je to interpretované nebo kompilované – místo vlastního interpretu si můžeš nahrát vlastní kompilátor, přeložit a spustit binárku. A v obou případech je stále riziko, že ti poskytovatel vydumpuje RAM nebo okopíruje obsah disku a ukradne data (nebo je pozmění). Takže nakonec stejně skončíš u vlastního fyzicky zabezpečeného hardwaru

[Grunt]

A v obou případech je stále riziko, že ti poskytovatel vydumpuje RAM nebo okopíruje obsah disku a ukradne data (nebo je pozmění)

Když ty data co k nim budu ukládat se budou u nich za jejich procesorový čas šifrovat (musí samozřejmě poskytnout ověření šifrovacího SW a já musím mít volbu nad šifrovacím algoritmem) a zpětně dešifrovat u mě, nemám s tím nejmenší problém. Poskytovatel poskytuje prostor a čas, tak má plné právo nějaký shluk dat kterým nerozumí smazat nebo si je libovolně pozměnit k obrazu svému. Teda aspoň tak dlouho co všechny soukromé šifrovací klíče zůstanou u mě

[Jendа]

Takže nakonec stejně skončíš u vlastního fyzicky zabezpečeného hardwaru

Což v boomu RaspberryPi za osm stovek a neomezeného megabitu v kdejaké dědině není problém. Teda vlastně je - došla nám přirozená čísla… (IP adresy)

[Grunt]

pokud to má být svobodný software a ne zaDRMovaná sračka (což by bylo jaksi v rozporu samo se sebou).

Proč? Nebyla tohle původně účel trusted computingu? Proč omezovat uživatele v tom co můžeš spouštět když můžeš omezit svého provozovatele nějaké cloudové služby? Princip jde aplikovat tak či onak…

[xkucf03]

Teoreticky by se ta technologie dala použít ve prospěch uživatele. Ale jak to chceš udělat na vzdáleném serveru, který ti nepatří? Jak zevnitř (z té své aplikace) poznáš, že je okolí (operační systém, virtualizace, hardware…) v pořádku a nelže ti?

IMHO bezpečný cloud je jen tvůj vlastní, který máš plně pod kontrolou, nebo takový, který funguje jen jako úložiště – ukládáš na něj pouze šifrované soubory a veškerou logiku máš na klientech.

[Grunt]

Jak zevnitř (z té své aplikace) poznáš, že je okolí (operační systém, virtualizace, hardware…) v pořádku a nelže ti?

Není náhodou přesně tohle snaha Microsoftu a důvod proč se tak vehementně dere do UEFI? Proč by to v případě Microsoftu mělo být naprosto v pořádku, ale když chci úplně to samé i já, tak už ne?

[Jendа]

Není náhodou přesně tohle snaha Microsoftu a důvod proč se tak vehementně dere do UEFI?

…a proč zatím bylo snad každé DRM a TPM prolomeno.

[Grunt]

Protože to dělal Microsoft a jemu podobní? No jedna věc se musí uznat. S každou iterací je to prolamování obtížnější víc a víc.

[Grunt]

Já nemám nejmenší problém s UEFI a trusted computingem obecně pokud i protistrany s tím nemají problém? A vlastně mám. Když už jsme u toho, proč to neudělat tak že já povalím na otevřeném BIOSu, otevřeném operačním systému či jakémkoliv jiném systému mé volby a protistrany (servery) nech si nechají svůj trusted computing ať mám jistotu, že valí pouze ověřený (v mém případě je žádoucí otevřený) kód? Nebylo by to ještě lepší? Bohužel realita je přesně opačná.

[Fluttershy, yay!]

IMHO bezpečný cloud je jen tvůj vlastní, který máš plně pod kontrolou

Je to pak cloud, pokud nejsem někdo jako Jeff Bezos?

[xkucf03]

Pak se tomu říká privátní cloud, tak asi ano. Nicméně se to týká velkých organizací/firem, které jsou takovou infrastrukturu schopny provozovat (IT oddělení pak ostatním uživatelům v organizaci skutečně poskytuje služby, které jsou pro ně „cloud“). Je ale nesmysl si připojit RPi nebo nějaký server do sítě a říkat tomu „cloud“.

Proto mi třeba nesedí, že se ownCloud jmenuje ownCloud, když to ve skutečnosti žádný cloud není. Je to klasická klient-server aplikace. Ale buzzwordy a marketing pronikly i do téhle oblasti a lid si to asi žádá.

[Fluttershy, yay!]

Jaký/který cloud tedy můžu mít já osobně pod kontrolou?

[xkucf03]

Ty osobně asi žádný. Já taky nemám svůj cloud. Ale můžeme mít v pohodě vlastní server, který nám cloud víc než nahradí.

[Fluttershy, yay!]

Ty osobně asi žádný. Já taky nemám svůj cloud.

Bingo.

Ale můžeme mít v pohodě vlastní server, který nám cloud víc než nahradí.

Tím bych si tak jistý nebyl. Jako kdyby u nás nikdy nebyly povodně...

[xkucf03]

Od toho je zálohování. Případně nasadit online replikaci a mít aktuální/synchronizovaná data na více místech – ani to už není taková utopie.

[Fluttershy, yay!]

Když bude vytopená servrovna nebo se fízli rozhodnou předstírat aktivitu (a vyrvou všechny dráty v servrovně ze zásuvek), služba nepojede.

[xkucf03]

To ale nepojede ani ten cloud. Jeden server budeš mít doma a jeden v serverovně. Povodně jsou tím s velkou pravděpodobností pokryté a pokud jde o cílený útok – musel by napadnout obě místa současně. Když to srovnáš s cloudem, je to pořád mnohem lepší, protože cloud pravděpodobně útočníkům data poskytuje bez tvého vědomí tak jako tak. A odstavení služby (zablokování tvého účtu) je tam taky na denním pořádku, ani nemusíš nic provést a pomoci se jen tak nedovoláš, nikdo se s tebou nebude ani bavit. Pro cloud typu Facebook/Google/Microsoft nejsi zákazníkem ale komoditou, zdrojem.

[Fluttershy, yay!]

Konkrétní příklad. Potřebuju sdílet nějaké texty s dalšími lidmi a přistupovat k nim z různých míst. Používám pro ty účely gitit (gitový repozitář + wiki pro editaci dat). Běží na serveru v nějaké servrovně. Přijde živelná katastrofa nebo ve stejné servrovně byl i server, na kterém běžel growshop, a rázem mi služba neběží. V případě cloudu tento problém nenastane.

To, že dáváš rovnítko mezi poskytovatele cloudu a Facebook/Google/Microsoft, je argumentační klam.

[xkucf03]

Pokud je to distribuovaný verzovací systém, tak jsi úplně v pohodě – budeš mít všechno i na klientech a není problém okamžitě nahodit jiný server (nebo za server prohlásit jednoho z klientů) a data synchronizovat přes něj. Nebo můžeš mít servery celou dobu dva a dělat mezi nimi push/pull.

Ta wiki může stavět nad soubory v tom verzovacím systému a dělat pro něj vlastně jen GUI. Nebo může mít data v databázi a ta bude replikovaná na více strojích.

Uživatelům stačí znát adresu sekundárního serveru nebo si tohle ošetříš přes DNS a zautomatizuješ.

[Fluttershy, yay!]

Přesně v duchu výroku

Počítače usnadňují práci, která by se bez nich vůbec nemusela dělat.

[xkucf03]

Tak si to piš do papírového notýsku a když ti ho vezme velká voda nebo policie, tak máš smůlu :-P

Cloud není žádné kouzlo nebo zázračné řešení – tu samou práci s replikací tam taky musí někdo udělat (jen to zvenku nevidíš).

[Fluttershy, yay!]

Proč lidi používají Dropbox? Protože je to jednoduché. Proč si místo toho nenahodí vlastní server s OwnCloudem (nebo něčím podobným)? Protože to není jednoduché. Když pominu, že samotný software není velká sláva, přesně ta migrace, kterou jsi popsal, není uživatelsky přívětivá.

Takže proč nepoužít cloud? Provozovatelem cloudu není jenom Google/MS/FB, jak podsouváš. Může to být taky třeba evropská LaCie (Wuala) nebo třeba CESNET.

[xkucf03]

Zrovna ten CESNET poskytuje mj. ownCloud A ano, tohle je jeden z těch serióznějších poskytovatelů, kterým bych i trochu věřil.

[Fluttershy, yay!]

Není ta infrastruktura náhodou cloud? Mně cloudem docela dost zavání.

[Josef Kufner]

"Cloud" je o tom, že oddělíš server od železa na kterém běží. Tím pádem můžeš službu přesouvat mezi fyzickými servery dle libosti a pořád poběží.

Pokud chceš svůj malý privátní cloud, nahoď pár serverů, propoj je dostatečně tlustou linkou a na tom spusť virtuální servery dle požadovaných služeb. Když ti nějaký fyzický server začne dělat potíže, přesuneš na něm běžící virtuální servery na jiný stroj a ten porouchaný v klidu opravíš. Pokud porucha bude náhlá, asi bude potřeba obnovit virtuální server ze zálohy, ale místo opravy fyzického serveru si službu prostě pustíš někde jinde.

Pokud to povaha služby umožňuje, je vhodné mít spuštěných několik instancí najednou, pak se ty výpadky projeví jen zvýšením zátěže ostatních serverů.

[Jendа]

Pleteš si otevřený software a službu, která tento software používá.

[Grunt]

Tedy za předpokladu, že zdrojový kód nasazeného produktu je stejný jako ten v CVS?

Popravdě tohle štve spoustu lidí včetně mě. Kdyby existoval způsob jak porovnat hash z binárky s hashem ze zdrojáku, věřím že už by takový nástroj dávno existoval. Bohužel to asi nebude tak jednoduché.

[psio]

Tohle nejde ani teoreticky. Bez fyzickeho pristupu a kontrolou hashu ktery by zacinal u firmware.

[Grunt]

Takhle jsem to nemyslel. Myslel jsem jednoduchý způsob kterým ověříš, že danému binárnímu kódu odpovídá daný zdrojový kód (tzn. nějaký hash zdrojáku) a budeš mít jistotu že nikdo nepřidal ani bajtík do zdrojáku (muselo by to kompletně změnit hash výsledku). Jednoduše pak můžeš distribuovat binárky s nějakým ověřovacím hashem a nemusel by si furt jak trotl všechno kompilovat. Ono přece jen nějakou malinkatou výhodu interpretované jazyky oproti těm kompilovaným mají.

[Hans1024]

Tak v Debianu nekdo pracuje na reproducible buildech. Ale postupujou dost pomalu a nevim, jestli se jim to nekdy podari protlacit do Debianu jako default. Zatim jsou reprodukovatelne myslim asi 2/3 balicku. Tipuju, ze to bude fungovat tak za 10 let. Ja uz jsem stratil nervy a presel jsem na Gentoo

[xkucf03]

Minimálně se na tom pracuje: Reproducible builds

[Grunt]

Netýká se to i guixu?

[Josef Kufner]

Existuje. Jmenuje se to reproducible builds a v Debianu na tom pracují. Pointa je v tom, že kompilací zdrojáků vznikne vždy na byte stejná binárka (balíček). Takže pokud znáš hash binárky a máš zdrojáky, stačí je zkompilovat do nové binárky, spočítat její hash a porovnat s tím prvním.

[Grunt]

Hmm. Idea trusted remote computingu se začíná pomalu formovat

[Miloslav Ponkrác]

Takže stačí zkompilovat lepším kompilátorem.

Nebo kompilátorem, kterému změním ve standardní knihovně implementaci funkce strlen() za mnou vlastní optimalizovanou a 20 × rychlejší.

Případně patchnout kompilátor volitelným patchem ze stránek gcc.

A pokud udělám překlad zdrojáku s profilerem, kdy nechám program běžet, profiler mi zjistí údaje šité na míru stroji a pak kompilátor zkompiluje zoptimalizovanou binárku na míru mému stroji, která ne mém stroji poběží nejryhleji možně, obávám se, že také bude s hashem haprovat. Protože na každém stroji může vyjít dost odlišná binárka.

Pokud dělají v Debianu na tomto, je to naprosto v pohodě. Občas si musejí nabít ústa a historicky objevit, že tudy cesta nevede.

[xxx]

Tak holt kompiluju dvakrat. Jednou pro overeni, podruhe pro optimalizace.

[Josef Kufner]

A co s tím?

Pointa je v tom, že ze stejného zdrojového balíčku při použití stejného překladače vznikne stejný binární balíček. Takže si můžeš namátkou ověřit, že to co je v oficiálních repositářích opravdu vzniklo z uvedených zdrojáků.

[Miloslav Ponkrác]

Problém je, že žádný kompilátor tyto záruky nedává. A to z velmi rozumných důvodů.

Tedy vychází se z předpokladu, který nikdo nezaručuje.

---

Takových nezaručených předpokladů, které nikdo neslíbil lidi zažijí plno. Například na začátku dospělého života řada mužů vychází z předpokladu, že ženy se chovají plus mínus stejně jako muži, a jde se s nimi vždy rozumně domluvit. A pak zjišťují, že tento předpoklad je jaksi nezaručený.

Při hodnocení šmírování řada lidí zase vychází s předpokladu, že „kdo nic špatného nedělá, nemusí se bát“. Což stálo mnoho zmařených životů.

No a jinde někdo vychází z předpokladu, že kompilátor ze stejného souboru udělá vždy shodnou binárku.

Všechny tři předpoklady jsou nesmírně a na první pohled logické. Nemají logickou chybu, přesto nefungují V PRAXI.

Znovu říkám, žádný kompilátor nedává tuto záruku, že ze stejného zdrojáku vznikne vždy stejná binárka. Proto opírat se o kompilátorem či jazykem nezaručené věci je cesta do pekel. I když se to zná logické. Ale logických se zdá tolik věcí, a praxe mnoho hezkých teorií rychle a nemilosrdně zabije.

[Grunt]

Například na začátku dospělého života řada mužů vychází z předpokladu, že ženy se chovají plus mínus stejně jako muži, a jde se s nimi vždy rozumně domluvit.

Jak proboha souvisejí kompilátory s ženskýma?

[kralyk z abclinuxu]

Jak proboha souvisejí kompilátory s ženskýma?

Warningy můžeš ignorovat, ale jednoho dne se ti to vymstí.

[xkucf03]

→ do fortunek

[Miloslav Ponkrác]

Abych nemluvit teoreticky. Zde je příklad zdrojového kódu, který při kompilaci stejným kompilátorem dává odlišné binárky a tento způsob ověření nebude fungovat:

int main() { printf("Program (zkompilován %d) spuštěn\n", __DATE__); // ... return 0; }

A shořeli jste s ověřením jako papír snadno a rychle.

[Miloslav Ponkrác]

Nějak neumím používat tento redakční systém. Takže oprava:

int main()
{
  printf("Program (zkompilován %s) spuštěn\n", __DATE__);
  // ...
  return 0; 
}

[Hans1024]

Ja nechapu o co vam jde, samozrejme ze zde sou prekazky a spousta balicku se musi opatchovat, ale ti co na tom pracuji si jsou ruznych prekazek vedomi, a proto na tom *pracuji* misto toho aby zvanili o tom, ze nestaci lusknout prstem aby to fungovalo.

[Miloslav Ponkrác]

Já jenom dodávám, že Ti co na tom pracují jen pravděpodobně zjistí, že vyfukováním kouře do vody zlato nevzniká.

Nic více a nic méně.

Někdy je lépe „žvanit“ a přemýslet, než tupě makat.

Klidně se vsadím, že z tohoto makání žádný výsledek nevznikne a tiše se to opustí.

Představa, že Debian všem programátorům na světě hromadně zakáže podmíněnou kompilaci – to je nejspíše drsné přecenění síla makáčů v Debianu. Takovou moc asi nemají.

[pavlix]

Když něco nepochopíte, je lepší se zeptat, než si hrát na proroka.

[Miloslav Ponkrác]

A na má slova dojde. Málokdy jsem si tak jist, jako v tomto případě.

[Marvin]

Algoritmus ze stejnyho vstupu VZDY udela stejnej vystup. Jak rekl Mr. John von Neumann:

Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin.

Kdyz se budes snazit tak se ti nejak podari zajistit jinej vstup. Krome uz zminovanyho __DATE__ me napada treba upravit makefile aby precetl par nahodnejch byte z /dev/random. Ulozit je do souboru jako retezec, a ten potom inkludovat .

Kazdopadne v 99.999999% programu tohle nema co delat. Takze pokud narazis na program ktery se kompiluje pokazdy jinak tak bych doporucoval poslat bug report.

[Miloslav Ponkrác]

Chápu, takže snad abychom první poslali bug report do ISO organizace, že C/C++ obsahuje předdefinovaná makra __DATE__ a __TIME__.

[Marvin]

To ze jazyk obsahuje neco co by vetsina programu nemela pouzivat neni chyba jazyka.

[Miloslav Ponkrác]

Proč by to neměla používat? Protože to Marvin řekl?

Když dám u většiny programů v shellu: program --version, tak často se dozvím i kdy bylo zkompilováno.

Např. zkuste vim --version

A je to velmi užitečné vědět.

[xkucf03]

A je nutné mít tuhle informaci uvnitř binárky? Program se obvykle skládá z mnoha souborů a tohle by mohlo být v jednom z nich. A pak by se počítaly otisky z jednotlivých souborů – takže bys třeba zjistil, že se liší v jednom krátkém texťáku, ale binárky jsou 100% shodné.

Ono když o sobě nějaký program tvrdí, že byl zkompilován 7. 7. 2014 ve 13:11, tak mu to stejně nemůžu věřit – autor tam mohl napsat cokoli nebo mohl někdo dodatečně patchovat binárku. Taková informace pro mne nemá moc velkou cenu, resp. nebude mi vadit, když nebude přímo v binárce ale bude v externím souboru (důvěryhodné je to srovnatelně).

Naopak mnohem hodnotnější informace je pro mne ten hash binárky a to, že si můžu vzít údajné zdrojáky a zkontrolovat jestli po překladu vedou na stejnou binárku. Opět to jsou fakta vs. sliby – textový řetězec "7. 7. 2014 ve 13:11" je jen prázdný slib, zatímco bajt po bajtu porovnané dvě binárky, to jsou fakta.

Pokud si tedy můžu vybrat, tak jsem pro přesun variabilních částí do samostatných souborů, ve prospěch toho, že budu mít stabilní hashe binárek.

P.S. samozřejmě se to netýká optimalizací pro konkrétní počítač nebo používání speciálních nestandardních kompilátorů – bavíme se o běžné distribuci.

[Miloslav Ponkrác]

Podle zákona Occamovy břitvy je jednodušší opustit špatnou myšlenku, že stejný zdroják bude generovat stejnou binárku, než donutit všechny programátory na světě, aby něco dělali jinak.

Ty variabilní části, do kterých to přesunute, to zkontrolujete jak, že zrovna v nich není backdoor?

[Fluttershy, yay!]

Hlavně mi není úplně jasné, proč by to datum měl řešit zrovna program a ne správce balíčků.

[Hans1024]

Kdybyste si o tom neco precetl, vedel byste, ze cilem je aby zadne variabilni casti ve vysledku nebyly (pouziva se faketime).

[Grunt]

A je nutné mít tuhle informaci uvnitř binárky? Program se obvykle skládá z mnoha souborů a tohle by mohlo být v jednom z nich. A pak by se počítaly otisky z jednotlivých souborů

No need to. Tyhle věci jsou uvnitř jednoho ELFu rozděleny do různých sekcí a sekce se samotným kódem _by měla_ zůstavat furt stejná, ne?

[xkucf03]

Teoreticky, ale to už máš platformě závislé řešení (ELF – ale co třeba .class v Javě nebo zkompilovaný Python, Erlang, PHP, Lisp atd.?). Umístit variabilní části do souborů je jednoduché a univerzální.

[Grunt]

Nejsem zastáncem Ponkráce ani trochu, nicméně je fakt, že nějak lépe by se to vymyslet mohlo. Když to tak beru všeho všudy kolem, tak kompilátor skutečně je hashovací funkce. Akorát pěkně náročná. Proto jsem se záměrně ve svých úvahách výše nepouštěl dál než za interpretované jazyky. Neřeknu jestli je to jednodušší nebo ne. Nicméně ELF je na každé platformě stejný a dělí to do stejných struktur i když třeba v různém pořadí.

ale co třeba .class v Javě

Kdyby se hlasovalo, tak bych byl pro povinné zavedení GCJ do repositářů aby jediný způsob jak bych mohl potkat s Javou by byl zdrojový jazyk v políčku balíčkovacího manažeru. Tolik ke .class v Javě.

[kralyk z abclinuxu]

Kdyby se hlasovalo, tak bych byl pro povinné zavedení GCJ do repositářů aby jediný způsob jak bych mohl potkat s Javou by byl zdrojový jazyk v políčku balíčkovacího manažeru. Tolik ke .class v Javě.

+1

[kralyk z abclinuxu]

Nicméně GCJ je, zdá se, mrtvý, takže pokud se člověk chce vyhnout JVM, nesmí Java sw používat vůbec...

[Grunt]

Nicméně GCJ je, zdá se, mrtvý

Ani ne tak mrtvý jako spíš závislý na GNU Classpath, jestli jsem to pochopil správně (a vůbec není vyloučeno že ne). A ty nemá moc cenu vyvíjet když máme OpenJDK. Něco málo jsem si sliboval od spojenecké ofenzivy Apačské harmonie, ale nakonec prd modrá rybko. Budu muset na spásu čekat dál. Přitom zajímavé, že VM jak hub po dešti, dovedou kompilovat dozadu i dopředu a bůh ví kterým směrem, ale do souboru/binárky to nedovede AFAIK přesměrovat ani jeden.

[xkucf03]

Java resp. JVM ti vadí, ale skriptovací jazyky vyžadující interpret ti nevadí? Proč?

[Grunt]

Protože ostatní interprety narozdíl od standardní implementace JVM jsou nainstalované out-of-box a pokud ne, tak nesežerou půlku USB storage při doinstalování, nerozlezou se do tisíců složek, nebalí spustitelné soubory do ZIPu, ale přímo do spustitelných binárek (a pokud ne tak mě nezajímají) a dovedou spolupracovat se systémovými knihovnami skrze bindingy a nepotřebují při instalaci nějaké malinkaté pidi-aplikačky tahat půlku operačního systému ve svém rodném jazyce (a pokud ano, tak mě nezajímají).

[xkucf03]

nesežerou půlku USB storage při doinstalování

To máš nějaký malý USB disk.

$ aptitude show openjdk-7-jre-headless | grep Velikost
Velikost po rozbalení: 57,2 M

nerozlezou se do tisíců složek

Já to mám v jedné, v /usr/lib/jvm. Co máš za distribuci? A pokud si stáhneš JRE/JDK, tak je to prostě jeden zip, který stačí rozbalit do jednoho adresáře, ani se nemusí instalovat.

nebalí spustitelné soubory do ZIPu,

Na ZIPu nevidím nic špatného, přijde mi lepší použít standardní formát (který můžeš procházet třeba v mc) než vymýšlet něco vlastního. Kromě toho to ani balit nemusíš, spustitelné jsou samotné .class soubory, program může být tvořen adresářem obsahujícím zkompilované třídy.

ale přímo do spustitelných binárek

Viz GCJ. Případně se dá přibalit JRE, ale to je takový ošklivý hack, stejně jako přibalit jakýkoli jiný interpret – systémové řešení je, že máš interpret/VM nainstalovaný jen jednou a programy spouštíš přes něj.

a dovedou spolupracovat se systémovými knihovnami skrze bindingy

Z Javy taky můžeš volat nativní knihovny. Viz JNI, JNA…

nepotřebují při instalaci nějaké malinkaté pidi-aplikačky tahat půlku operačního systému ve svém rodném jazyce

U svých programů se snažím mít minimální závislosti. Že je někdo okouzlen Mavenem a nafláká v něm bez uvážení závislosti tak, že postahuje půlku Internetu, to už je jeho problém – je to chyba autora aplikace, ne jazyka/platformy.

[Grunt]

Velikost po rozbalení: 57,2 M

A to je jako málo, jo?

Kromě toho to ani balit nemusíš, spustitelné jsou samotné .class soubory, program může být tvořen adresářem obsahujícím zkompilované třídy.

Hele nestraš takhle navečer a radši všechno flákej do jaru. To tě varuju.

Viz GCJ.

Ono i GIJ je milejší. Bohužel se schopnostmi jaké má.

Z Javy taky můžeš volat nativní knihovny.

Můžeš. A 90% aplikaci si je tahá sebou jako třídy pro strýčka náhodu. Fuj.

Že je někdo okouzlen Mavenem

To je právě ta nádhera kompilované Javy (a ostatních kompilovaných jazyků). Nemusím se starat co je to Eclipse, ecj, Apache Maven, kdejaké Frameworky, atd. Jenom před jméno souboru fláknu „./“ – no nádherný svět. Chybí už jen duha, delfínci a šampaňské.

[xkucf03]

A to je jako málo, jo?

Vzhledem k velikostem disků a rychlostem připojení je to málo. Vzhledem k tomu, co umí, mi to přijde přiměřené. Jasně, mohlo by to být menší, ale žíly mi to netrhá.

Hele nestraš takhle navečer a radši všechno flákej do jaru. To tě varuju.

Však já to tak normálně dělám, to jen tak pro pořádek, jaké jsou možnosti.

Ale pythonisti mají zjevně jiný názor – třeba jeden prográmek:

$ ls /usr/share/virt-manager/virtManager/*.pyc | wc -l
52

V Javě by bylo ekvivalentem mít v tom adresáři nasypáno 52 .class souborů (což javisté typicky nedělají a zabalí to do jednoho JARu).

Můžeš. A 90% aplikaci si je tahá sebou jako třídy pro strýčka náhodu. Fuj.

Zase je to platformě nezávislé, poběží to všude stejně. Nativní kód bych dneska používal jen pro vybrané části, kde potřebuješ hrubý výkon nebo nějakou úzkou spolupráci s OS/HW.

Druhá věc jsou závislosti na javovských knihovnách, JARech. V distribucích – třeba v Debianu – máš spousty takových knihoven, třeba JDBC ovladače a mnohé další, takže správně udělaná aplikace v Javě bude tyto závislosti deklarovat v balíčku, ale nebude s sebou tahat vlastní JARy – použije ty z /usr/share/java.

nádhera kompilované Javy

S GCJ si taky občas hraji… no líbí se mi to a rád bych, aby tím šlo překládat víc programů v Javě, i složitějších.

Jenom před jméno souboru fláknu „./“

Na to ani nepotřebuješ kompilaci do ELFu – takhle můžeš spouštět i .class nebo .jar soubory. Viz Binfmt misc for Java.

[Grunt]

Prosím přestaň s tou argumentací ve prospěch Javy. Krom toho že zbytečně ztrácíš čas ještě ke všemu zbytečně ztrácíš čas.

[Grunt]

S GCJ si taky občas hraji… no líbí se mi to a rád bych, aby tím šlo překládat víc programů v Javě, i složitějších.

No a když už jsme u toho tak prej… ale zní mi to jako hoax.

[Hans1024]

Taky existovaly nejake experimenty, jak skompilovat javu pomoci llvm (vmkit) do binarky, ale me se tim nic skompilovat nepodarilo

[Grunt]

Cítím v kostech, že to zas bude další zajímavý víkend.

[kralyk z abclinuxu]

Zase je to platformě nezávislé, poběží to všude stejně. Nativní kód bych dneska používal jen pro vybrané části, kde potřebuješ hrubý výkon nebo nějakou úzkou spolupráci s OS/HW.

Omg, proč? I kompilované aplikace mohou být multiplatformní, není to velký problém.

[pavlix]

Mezi multiplatformní a platformně nezávislé je rozdíl. A nativním kódem se většinou myslí kód pro daný procesor, ne kód pro nějaký procesor, který se pouští v emulaci, to už rovnou můžeš používat nějaký typ bajtkódu. Na tvé řešení jsem zvědavý.

[kralyk z abclinuxu]

Mezi multiplatformní a platformně nezávislé je rozdíl.

V kontextu diskuse moc nevidím jaký.

Situace Java: Zdrojový kód a bytecode je platformně nezávislý, JVM obsahuje příslušné abstrakce platformy.

Situace kompilovaný jazyk: Zdrojový kód je platformně nezívislý, binárka ne, kompilátor / standardní knihovna / framework obstahuje příslušné abstrakce platformy.

V podstatě jediný rozdíl je, že v případě Javy se kompiluje just in time, jinak ale co se přenosnosti týče, přijde mi to v bleděmodrém to isté.

[pavlix]

Už ti rozumím. Máš pravdu, že aplikace, které se kompilují, jsou do jisté míry nezávislé na platformě. Z té věty jsem si ale představoval již zkompilované aplikace, které nezávislé rozhodně nejsou.

[kralyk z abclinuxu]

Java resp. JVM ti vadí, ale skriptovací jazyky vyžadující interpret ti nevadí? Proč?

Python sice obecně rychlejší než Java určitě nebude, nicméně startup time imho bude mít rychlejší, a to až výrazně. JVM je prostě velkej. Ale jinak i programy v pythonu můžou trpět podobným problémem - z tohohle důvodu jsem např. velmi rychle odinstaloval bittorrent klient Deluge...

[xkucf03]

Python sice obecně rychlejší než Java určitě nebude, nicméně startup time imho bude mít rychlejší, a to až výrazně. JVM je prostě velkej

Start má Java pomalejší, ale v absolutních číslech to dnes není nic drastického – ty procesy mají obvykle delšího trvání, nespouštíš každých 10 ms jeden, aby ti to muselo tolik vadit.

$ time python --version
Python 2.7.5+

real    0m0.003s
user    0m0.001s
sys     0m0.003s

$ time java -version
java version "1.7.0_55"
OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.13.10.1)
OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

real    0m0.074s
user    0m0.061s
sys     0m0.016s

[xkucf03]

Nicméně ELF je na každé platformě stejný

Ale ELF není jediný formát pro binárky – a dokonce to ani binárky být nemusí – co třeba takový shellový skript vygenerovaný během kompilace? Jak v něm najdeš nějaké sekce? Samostatné soubory, které v balíčku můžeš označit jako variabilní, jsou univerzální řešení.

aby jediný způsob jak bych mohl potkat s Javou by byl zdrojový jazyk v políčku balíčkovacího manažeru. Tolik ke .class v Javě.

Že se ti Java nelíbí, neznamená, že ji přestanou ostatní používat.

[Grunt]

Ale ELF není jediný formát pro binárky – a dokonce to ani binárky být nemusí

Máš recht.

Samostatné soubory, které v balíčku můžeš označit jako variabilní, jsou univerzální řešení.

A co je variabilní a co ne budeš označovat při balení ručně? Fuj.

Že se ti Java nelíbí, neznamená, že ji přestanou ostatní používat.

Nikde jsem neříkal že se mi Java nelíbí. Ba naopak. Co jsem si o víkendu zkompiloval pár ukázkových aplikací v GCJ a měl z toho pomalu erekci se mi Java začíná líbit.

[Fluttershy, yay!]

Nikde jsem neříkal že se mi Java nelíbí. Ba naopak. Co jsem si o víkendu zkompiloval pár ukázkových aplikací v GCJ a měl z toho pomalu erekci se mi Java začíná líbit.

Guilty as charged. Na kafové plantáže s ním!

[xkucf03]

A co je variabilní a co ne budeš označovat při balení ručně? Fuj.

Označovat to nemusíš – tak jako tak je potřeba při kontrole ukázat diff. Ale označením jasně deklaruješ, že to byl záměr, že to není chyba.

Ale záleží, k čemu to má sloužit – jak tu někdo psal o distribuovaných buildech a šíření balíčků přes torrenty, tam by to nešlo, to by musel být balíček 100% shodný (variabilní části by se leda musely vyčlenit do jiného, což ale u informace typu „čas kompilace“ nedává smysl).

[kralyk z abclinuxu]

Nikde jsem neříkal že se mi Java nelíbí. Ba naopak. Co jsem si o víkendu zkompiloval pár ukázkových aplikací v GCJ a měl z toho pomalu erekci se mi Java začíná líbit.

No, já teď zkoušel Hello World abych viděl ten startup time. Nasralo mě už to, že si nemůžu soubor obsahující třídu Hello pojmenovat hello.java, ale musí to být Hello.java. Myslím, že tento příklad sumarizuje celkovou idiocii Javovského světa.

Tím nechci říct, že se v Javě nedá psát dobrý SW. Určitě dá. Třeba pro nějakou netriviální webovou aplikaci bych o Javě vážně uvažoval a programování v Javě přežiju (když přežiju PHP - což je snad ještě idiotštější jazyk - přežiju cokoli). Ale tahle nesmyslná náboženská přikázání jako je to výše mě prostě strašně vytáčejí, připadají mi jako takový Clippy programátorského světa...

[Grunt]

Ono vůbec když program v Javě vypíše na obrazovku Hello World a nepotřebuje k tomu 95 M (java-1.7.0-openjdk-headless-1.7.0.60-2.5.0.1.fc20.i686) + závislosti nebo nějaký framework je samo o sobě dost sexy.

[Grunt]

No, já teď zkoušel Hello World abych viděl ten startup time. Nasralo mě už to, že si nemůžu soubor obsahující třídu Hello pojmenovat hello.java, ale musí to být Hello.java. Myslím, že tento příklad sumarizuje celkovou idiocii Javovského světa.

To je v pohodě. Já dokonce jednou musel vyplňovat parametr --main pro gcj.

[xkucf03]

Nasralo mě už to, že si nemůžu soubor obsahující třídu Hello pojmenovat hello.java, ale musí to být Hello.java. Myslím, že tento příklad sumarizuje celkovou idiocii Javovského světa.

OMFG! Vždycky jsem to bral jako výhodu, že je v tom pořádek a názvy adresářů/souborů přesně pasují na názvy balíčků a tříd.

Hlavně že Pythonisti trvají na pythomém odsazování mezerami a přikládají odsazení bloků zásadní význam pro funkci programu.

[Fluttershy, yay!]

Pche, nějaká Java. ADA!

[JS1]

No ono ta nevyhoda zacina uz u toho, ze se jaksi tridami supluje modularni system. (Me se treba libi, jak elegantne ma tohle vyresene jazyk Go.)

Jsou to prave podobne byrokraticke pitomosti, ktere lidem na Jave vadi.

S tim Pythonem se ale pletes. Zatimco u Javy to tak byt nemusi, odsazovani v Pythonu je potreba proste proto, ze nejak se tomu interpretru kde zacina a konci blok sdelit musi. Takze u Pythonu se byrokracie (a redundance) naopak eliminuje.

[xkucf03]

Někdo tomu říká byrokracie, někdo štábní kultura. Mně ten pořádek vyhovuje.

No ono ta nevyhoda zacina uz u toho, ze se jaksi tridami supluje modularni system.

Moduly se suplují třídami? Pro mě jsou moduly balíčky (v té nejjednodušší formě) nebo pak třeba projekty v Netbeans (aplikace rozdělená na víc modulů/projektů) nebo Maven nebo OSGi.

[JS1]

Ja nemam nic proti stabni kulture. Jen mi pripada nesmyslne ji nezavisle vynucovat na dvou mistech (uvnitr zdrojaku a v adresarove strukture), to je prave byrokracie, o ktere mluvim.

Kdyby se tridami nesuploval modularni system, budou proste moduly a tridy ortogonalni koncepty. Pak neexistuje duvod pro "private" (na urovni tridy) a neexistuje duvod, proc davat kazdou tridu do zvlastniho souboru.

Zpusob rozdeleni kodu na moduly (nezavisle kusy kodu) ma byt v kompetenci programatora. Nema kopirovat tridy - trida je samostatny typ (a proto nemam rad vetsinu strukturalnich design patternu, ktere ten fakt, ze trida ma byt predevsim typ, vesele ignoruji). Je to asi stejna hloupost jako kdyby jsi spisovatelum tvrdil, ze kazda kapitola knizky se musi odehravat na stejnem miste (predstavovat jedno "dejstvi"), jinak je to proste spatne napsana knizka.

Ja, priznam se, moderni zpusob psani stylem "spousta malych souboru" moc rad nemam. S IDE na tom vubec nezalezi, v kterem souboru co je (a jak jsou velke). Bez IDE je mene vetsich souboru, a v mensim poctu adresaru, pohodlnejsi na cteni (ale nesmi se to prehnat do opacneho extremu).

[xkucf03]

Pak neexistuje duvod pro "private" (na urovni tridy)

To jako že by se nepoužívalo zapouzdření – OOP?

a neexistuje duvod, proc davat kazdou tridu do zvlastniho souboru

Co je vidět a co lze volat z pohledu kódu/jazyka přece nezáleží na tom, jestli je to v jednom souboru nebo ve dvou – tyhle věci spolu nesouvisí.

Zpusob rozdeleni kodu na moduly (nezavisle kusy kodu) ma byt v kompetenci programatora.

Vždyť to tak taky je. Jen asi chápu moduly s větší granularitou než ty. Pro mne je modul třeba interní knihovna programu, plug-in pro vstupní nebo výstupní formát nebo pro nějakou volitelnou funkcionalitu. Proto pro mě jsou moduly ty projekty v Netbeans, OSGi nebo Maven. Zatímco balíčky a třídy jsou interní členění v rámci modulu.

A krásně tam funguje ta izolace a viditelnost – modul nevidí třídy jiných modulů, pokud je nemá deklarované jako závislosti – což tě nutí nepsat špagetový kód, kde všechno souvisí se vším a všechno se navzájem volá. Ty vazby jsou volnější, modul používá třeba rozhraní VýstupníModul a nepracuje přímo s třídou VýstupníModulProFormátXY, i když se k němu v době běhu jeho implementace dostane.

Bez IDE je mene vetsich souboru, a v mensim poctu adresaru, pohodlnejsi na cteni

Na to mám právě opačný názor – v IDE vidím stromovou strukturu balíčků a adresářů, můžu se skrz to navigovat, snadno najít, co potřebuji. A když nemám IDE, tak použiji nějakého správce souborů + textový editor a vidím v podstatě tu samou stromovou strukturu a můžu s tím (i bez toho IDE) celkem slušně pracovat a vyznat se v tom. Ono kdyby všichni používali IDE, tak by klidně mohl být celý program namaštěný v jednom souboru a mohli bychom si ušetřit tu „práci“ a „byrokracii“ s dělením do souborů a udržováním¹ duplicitní struktury.

Ale i když člověk používá IDE, tak se to hodí – já např. s verzovacím systémem pracuji hlavně z terminálu (podporu v IDE používám spíš jen na zobrazení rozdílů, aktuálních změn) a hodí se mi přesně vidět, v kterých třídách, v kterých balíčcích došlo ke změnám – při přepínání mezi IDE a terminálem pracuji s tou samou stromovou strukturou (je jednou je oddělovačem cesty tečka a jednou lomítko), nemusím řešit, proč je to tady jinak než tam a v hlavě si to překládat. Fakt v tom nevidím žádný přínos, mít adresáře/soubory pojmenované jinak než balíčky/třídy.

_{[1] ve skutečnosti s tím žádnou práci nemáme, protože to udržuje IDE}

[kralyk z abclinuxu]

To jako že by se nepoužívalo zapouzdření – OOP?

Doufám, že nejsi další z lidí, kteří si myslí, že OOP = objekty v Javě? Prosím, nebuď

Jinak ano, nekteré "moderní cool" jazyky (zmiňované Go a Rust, příp. tuším i další) mají private pouze na rozhraní modulů. (Souvisí to také s tím, že tyto jazyky nemají koncept třídy jako takové, objekty se řeší trochu jinak.)

[xkucf03]

Zapouzdření je obecný koncept OOP, netýká se jen Javy.

A obecně jsem zastáncem toho, že by kód měl vidět a znát jen to, co ke své činnosti potřebuje, ne nic zbytečného navíc. Dá se jít i dál za privátní vlastnosti tříd – např. co se týče typů: nebudu u proměnné prozrazovat příliš konkrétní typ, použiji obecný, se kterým si okolní/následující kód musí vystačit¹; proměnné můžu uzavřít do bloků i v rámci jedné metody, aby rozsah jejich platnosti nebyl zbytečně velký²; něco podobného je princip minimálních práv v databázi – aplikace/komponenta má nějakého DB uživatele a ten vidí jen to, co skutečně vidět musí a zapisovat taky může jen tam, kam potřebuje.

_{[1] kdykoli později můžu změnit deklaraci na konkrétnější typ – ale udělám to až ve chvíli, kdy je to skutečně potřeba
[2] samozřejmě se nabízí rozdělení na více metod, ale jsou případy, kdy více metod nemá smysl, ale omezení rozsahu platnosti proměnné ano}

[kralyk z abclinuxu]

Zapouzdření je obecný koncept OOP, netýká se jen Javy.

Souhlasím, ale je možné jej implementovat různými způsoby. Ten Javovský nemusí být nutně Jediný Správný.

A obecně jsem zastáncem toho, že by kód měl vidět a znát jen to, co ke své činnosti potřebuje, ne nic zbytečného navíc.

Souhlasím, ale je potřeba tohle pravidlo aplikovat s rozumnou mírou. Kód nikdy nebude vidět skutečně jen a pouze to, co opravdu potřebuje.

[xkucf03]

Kód nikdy nebude vidět skutečně jen a pouze to, co opravdu potřebuje.

Úplně dokonalé to asi nebude, ale dá se tomu přiblížit a hlavně nevidím důvod, proč tu hranici posouvat opačným směrem (třeba k ne/viditelnosti až na úrovni modulu a ne třídy).

[kralyk z abclinuxu]

hlavně nevidím důvod, proč tu hranici posouvat opačným směrem (třeba k ne/viditelnosti až na úrovni modulu a ne třídy).

V jiných jazycich to může dávat smysl. Go a Rust jsou založeny na traits (v Go se jim říká interface, ale je to velmi podobné), tam když pracuješ s objektem, nepracuješ s třídou (kterou ty jazyky ani nemají), ale většinou s trait/interface, takže tam pak ani nehrozí, že bys přistoupil k vnitřním memberům třídy. Je to trochu jako bys v Javě pracoval vždy jen s interface (ačkoli úplně to samé to není), pak by private class membery taky začaly ztrácet smysl...

No a pak existuje např. JavaScript, kde se to prostě nepovažuje za tak důležité (což má svá pro i proti - chce to nebrat to tak strašně dogmaticky).

[pavlix]

Já osobně nevnímám modul jako příliš velký rozsah platnosti a pro běžné použití mi dokonce vyhovuje pythoní styl zapouzdření, které je řešeno informativní cestou (programátor na první pohled vidí, která část API je veřejná a která nikoliv) a značně to usnadňuje ladění i bez speciálních nástrojů. Zvláště oproti C++, kde bych zapouzdření nazval buzerativní, protože je vše ve skutečnosti přístupné, jenom velmi složitě.

Chápu i smysl bezpečného zapouzdření, což je předpokládám v Javě, jen mám dojem, že na úrovni modulu musí bohatě stačit. Nepíše se náhodou v Javě obvykle tak, že jeden modul odpovídá jedné třídě? V takovém případě by bylo zapouzdření na úrovni třídy i modulu ekvivalentní.

[xkucf03]

Jak jsem psal, tohle pojetí modulů nesdílím – pro mě je modul něco s trochu větší granularitou. A tam chci mít rozhodně zapouzdření i uvnitř modulů, ne jen na jejich hranici, a dokonce se někdy snažím i o zapouzdření uvnitř tříd/metod.

[pavlix]

To už se ale nebavíme o praktické stránce ale o fetiši.

[deda.jabko]

Jen mi pripada nesmyslne ji nezavisle vynucovat na dvou mistech

Problem vznika s tim, ze je potreba mapovat tridy na nejake fyzicke soubory. S timhle si hezky poradil SmallTalk. V pripade Javy mi to prijde jako trochu nestastne, ale ma to i sve pozitivni stranky.

Je to asi stejna hloupost jako kdyby jsi spisovatelum tvrdil, ze kazda kapitola knizky se musi odehravat na stejnem miste (predstavovat jedno "dejstvi")

Tohle prirovnani pokulhava. Musis si uvedomit, ze Java jako jazyk byl navrzeny s ohledem pro nasazeni v ,,softwarovem prumyslu'', aby eliminoval chyby a zatimto ucelem ma zamerne omezene vyjadrovaci schopnosti. Z tohoto pohledu by se dalo programovani v Jave prirovnat k technickemu kresleni, kdy existuji unifikovane standardy, kterych se vetsina drzi a lide tak mohou spolupracovat bez nejakych vetsich komplikaci. Nebude to sice zadna elegance, ale svuj ucel to bude plnit. Vedle toho existuji jazyky, kde muzes popustit uzdu sve fantazii na maximum, ale je pravdepodobne, ze tomu bude rozumet jen par zasvecenych, zhruba asi neco jako modernimu umeni.

Jeden z nejcastejsich duvodu, proc lidi na Javu nadavaji je, ze nechapou vyse zminenou motivaci pro ten jazyk a v prenesenem slova smyslu chcou pomoci technickeho kresleni vytvaret impresionisticky obraz a pak nadavaji, ze jim to nejde. Tohle vyzaduje urcite prizpusobeni mysleni, na ktere proste nekteri nechcou pristoupit, protoze jsou zvykli na jine jazyky.

[xkucf03]

Problem vznika s tim, ze je potreba mapovat tridy na nejake fyzicke soubory.

Teoreticky by .java soubory mohly být nasypané v jednom adresáři a libovolně pojmenované nebo i všechny třídy z jednoho balíčku v jednom souboru. A až ty výsledné .class soubory by kompilátor roztřídil do správných adresářů a správně pojmenoval. Ale pořád nikde nevidím ten přínos, k čemu by to bylo dobré.

BTW: fyzické soubory to ani být nemusí – definice tříd by šlo klidně natahovat třeba z SQL databáze, ne?

[deda.jabko]

Teoreticky by .java soubory mohly být nasypané v jednom adresáři a libovolně pojmenované nebo i všechny třídy z jednoho balíčku v jednom souboru.

A kdyz je Java ten objektovy jazyk, nemohly by zdrojove kody byt objekty a ulozene v pameti? A co kdyby ta pamet byla perzistentni?

A až ty výsledné .class soubory by kompilátor roztřídil do správných adresářů a správně pojmenoval.

A kdyz je Java ten objektovy jazyk, nemohly by prelozene tridy byt objekty a ulozene v pameti? A co kdyby ta pamet byla perzistentni?

Ale pořád nikde nevidím ten přínos, k čemu by to bylo dobré.

Je potreba popustit uzdu fantazii. :-]

BTW: fyzické soubory to ani být nemusí – definice tříd by šlo klidně natahovat třeba z SQL databáze, ne?

Je potreba popustit uzdu fantazii. :-]

[xkucf03]

Klidně by z toho šel udělat Smalltalk. Ukládal a načítal by se nějaký blob¹ a v něm by byly i zdrojáky i přeložené třídy a program by se mohl i sám dynamicky za chodu upravovat (ať už generováním zdrojáku a jeho kompilací nebo generováním/úpravou mezikódu)…

ale asi dám přeci jen přednost klasickým zdrojákům v souborech s názvy odpovídajícími třídám/balíčkům

_{[1] případně tam přidat abstrakci, aby se nemuselo řešit, co je ještě na disku a co už načtené v paměti}

[kralyk z abclinuxu]

Z tohoto pohledu by se dalo programovani v Jave prirovnat k technickemu kresleni, kdy existuji unifikovane standardy, kterych se vetsina drzi a lide tak mohou spolupracovat bez nejakych vetsich komplikaci. Nebude to sice zadna elegance, ale svuj ucel to bude plnit. Vedle toho existuji jazyky, kde muzes popustit uzdu sve fantazii na maximum, ale je pravdepodobne, ze tomu bude rozumet jen par zasvecenych, zhruba asi neco jako modernimu umeni.

Zajímavé přirovnání, já bych to trochu poupravil:

Všechny jazyky jsou jako technické kreslení, akorát s různě velkými omezeními.

Java povoluje pouze úhly násobku 45°, protože ostatní úhly jsou matoucí pro nezkušené a zanášejí se jimi chyby do projektů.

PHP povoluje pouze úhly násobku 20° z historických důvodů, ve verzi 4 byly přidány i násobky 45°, ale mimo násobky 90°.

[xkucf03]

Musis si uvedomit, ze Java jako jazyk byl navrzeny … Jeden z nejcastejsich duvodu, proc lidi na Javu nadavaji je, ze nechapou vyse zminenou motivaci pro ten jazyk a v prenesenem slova smyslu chcou pomoci technickeho kresleni vytvaret impresionisticky obraz a pak nadavaji, ze jim to nejde.

+1, moc hezky napsáno

[kralyk z abclinuxu]

No ono ta nevyhoda zacina uz u toho, ze se jaksi tridami supluje modularni system.

+1

(Me se treba libi, jak elegantne ma tohle vyresene jazyk Go.)

Ok, já se mrknu, jak to má řešené Go, ty se můžeš mrknout, jak to má řešeno Rust

[JS1]

Hm, zbezne jsem to o tom Rustu precetl, ale taky nevim, jestli je to spravna cesta.

Tady musim trochu souhlasit s deda.jabko. Ja nejsem proti tomu, aby se semantika modulu odrazela v usporadani zdrojaku do souboru a adresaru. Rust, pokud to chapu spravne, to dovoluje (temer) zcela oddelit, coz neni uplne vec, s kterou bych souhlasil. V Go (tusim, uz je to nejaky cas, co jsem ho studoval) ale v podstate plati, ze soubor odpovida modulu.

To co se mi nelibi je smesovani typu a modulu; to povazuji v Jave za problematicke.

[kralyk z abclinuxu]

OMFG! Vždycky jsem to bral jako výhodu, že je v tom pořádek a názvy adresářů/souborů přesně pasují na názvy balíčků a tříd.

Jo, jenže nutit mě do velkého písmena na začátku souboru? WTF? Na některých jiných platformách to ani není rozlišitelné, tak nevim, proč to na UNIXu vyžaduje, navíc když na UNIXu soubory s velkýma písmenama zrovna zvykem nejsou. Jinak já mám pořádek / dodržování konvencí taky rád, bohužel Java mě nenechá dodržovat konvence, které považuju za smysluplné, ale místo toho mi nutí svoje vlastní, imho přiblblé.

Hlavně že Pythonisti trvají na pythomém odsazování mezerami a přikládají odsazení bloků zásadní význam pro funkci programu.

Já osobně python odsazuju tabama, není v tom problém.

[deda.jabko]

Jo, jenže nutit mě do velkého písmena na začátku souboru?

Nikdo te k tomu nenuti. Ale nazev souboru musi odpovidat nazvu tridy, to docela dava smysl. A je _konvenci_, ze nazev tridy zacina velkym pismenem.

Poznamka pod carou: je to vlastne jen dusledna aplikace pravidla convention over configuration, i kdyz prapuvodni motivace byla asi ve zjednoduseni class loaderu.

Jinak já mám pořádek / dodržování konvencí taky rád, bohužel Java mě nenechá dodržovat konvence, které považuju za smysluplné, ale místo toho mi nutí svoje vlastní, imho přiblblé.

A to je presne ono. Pak ma kazdy sve priblble konvence a kdo se v tom ma vyznat? Pravidelne musim kontrolovat zdrojaky ruznych projektu. V Jave, kde je styl kodovani docela pevne nastaveny, jej lidi plus/minus dodrzuji. Ale treba co generuji programatori v C# z toho jde nekdy hlava kolem. Kazdy ma svoje konvence, ale jejich logiku si peclive taji. Uz jsem videl dva ruzne namespace v jednom souboru, soubor o velikosti 5000+ radek, protoze obsahoval 10+ trid, atd. Radost s takovou veci pracovat.

[Bystroushaak]

A to je presne ono. Pak ma kazdy sve priblble konvence a kdo se v tom ma vyznat? Pravidelne musim kontrolovat zdrojaky ruznych projektu.

Jak, kontrolovat? To jako že by ti to bez toho nešlo, nebo na co narážíš?

[kralyk z abclinuxu]

A to je presne ono. Pak ma kazdy sve priblble konvence a kdo se v tom ma vyznat?

Imho konvence by měl mít možnost si nastavit projekt.

Ale treba co generuji programatori v C# z toho jde nekdy hlava kolem. Kazdy ma svoje konvence, ale jejich logiku si peclive taji. Uz jsem videl dva ruzne namespace v jednom souboru, soubor o velikosti 5000+ radek, protoze obsahoval 10+ trid, atd. Radost s takovou veci pracovat.

To je opačný extrémem, tj. naprostý anarchismus. Někteří lidé věří, že nastolením Jedné Svaté Konvence, kterou je nutné dodržovat, se tahle negativa eliminují. Není to pravda, pouze se ve výsledku projeví jinde. Zdrojové kódy, které jsou sice kompilovatelná Java, ale jinak naprostý bordel, jsou toho důlkazem...

[deda.jabko]

Imho konvence by měl mít možnost si nastavit projekt.

IMHO konvence by mely byt dany spolecne s jazykem. Vzhledem k tomu, ze dnesni projekty se skladaji typicky z velkeho mnozstvi podprojektu, rikejme jim treba knihovny, je zadouci, aby v celem projektu byla pouzivana jedna konvence, bez ohledu na momentalni pohnuti mysli autora ,,podprojektu''.

Zdrojové kódy, které jsou sice kompilovatelná Java, ale jinak naprostý bordel, jsou toho důlkazem...

A za ta muze ta konvence?

[kralyk z abclinuxu]

IMHO konvence by mely byt dany spolecne s jazykem. Vzhledem k tomu, ze dnesni projekty se skladaji typicky z velkeho mnozstvi podprojektu, rikejme jim treba knihovny, je zadouci, aby v celem projektu byla pouzivana jedna konvence, bez ohledu na momentalni pohnuti mysli autora ,,podprojektu''.

To záleží, jak důsledně správce projektu vyžaduje dodržování konvence, a je celkem jedno, jestli tam jsou podprojekty, nebo ne.

Pokud bys vyžadoval konvenci jazykem, v podstatě tím vylučuješ možnost mít jednotnou konvenci v projektu, který je napsán ve více než jednom jazyku - což imho není nijak neobvyklý jev.

A za ta muze ta konvence?

Ne, nemůže, to jsem nechtěl říct. Chtěl jsem říct, že vynucení konvence jazykem v důsledku nepřináší kýžený pořádek / štábní kulturu, resp. pouze povrchně. Pořádkumilovní lidé budou pořádní i bez toho, lidé, co nejsou pořádní, nebudou pořádní ani s tím.

[deda.jabko]

To záleží, jak důsledně správce projektu vyžaduje dodržování konvence, a je celkem jedno, jestli tam jsou podprojekty, nebo ne.

Neni. Vezmi si, ze knihovny od Oraclu budou pouzivat jednu konvenci pro pojmenovani trid/metod, atd. knihovny od Apache Foundation budou pouzivat jinou konvenci a ty budes chtit mit svoji. Zajimalo by me, co s tim jako spravce udelas?

Pokud bys vyžadoval konvenci jazykem, v podstatě tím vylučuješ možnost mít jednotnou konvenci v projektu

Toto je argumentacni klam (Nirvana fallacy). Proste kdyz jsi v Rime, chovej se jako Riman. V Jave budes dodrzovat konvence pro Javu, v Cecku zase pro Cecko, v cem je problem?

Ne, nemůže, to jsem nechtěl říct.

Super, na funkci to nema vliv.

Pořádkumilovní lidé budou pořádní i bez toho, lidé, co nejsou pořádní, nebudou pořádní ani s tím.

To je vylozene cernobile videni sveta.

[kralyk z abclinuxu]

Neni. Vezmi si, ze knihovny od Oraclu budou pouzivat jednu konvenci pro pojmenovani trid/metod, atd. knihovny od Apache Foundation budou pouzivat jinou konvenci a ty budes chtit mit svoji. Zajimalo by me, co s tim jako spravce udelas?

Nic. Proč bych měl něco dělat s konvencí depenenčního projektu?

Přesně tohle se mi stalo nedávno na jednom C++ projektu, kde byl použit framework wxWidgets, který používá velká písmena na začátku funkcí. Na API v tom projektu se to ale nijak neprojeví, protože vše je zapouzdřeno, čili ta nejednotnost bude vidět pouze v interním kódu. Svým způsobem to považuju i za plus, protože pak okamžitě vidím, které funkce vedou do wxWidgets.

[xkucf03]

Nic. Proč bych měl něco dělat s konvencí depenenčního projektu?

Jde o to, jak moc tu cizí knihovnu přijmeš za svoji a integruješ do svého programu – může to pro tebe být fuj, které si držíš daleko od těla a vytvoříš si nad tím nějakou vlastní abstrakci/izolaci, ale taky to můžeš přijmout a integrovat do svého programu, takže se ti v něm běžně budou vyskytovat ty cizí třídy a metody – pak je fajn mít alespoň v rámci jednoho zdrojáku jednotnou konvenci. Ale i když to bude více souborů/tříd – můžeš se chtít podívat na implementaci nějaké metody (z té knihovny), klikneš… a najednou by sis v hlavě musel přepnout, že tady třeba velká písmena znamenají něco jiného.

Svým způsobem to považuju i za plus, protože pak okamžitě vidím, které funkce vedou do wxWidgets.

Tohle někdy používám s češtinou/angličtinou – pokud jde o lokální/soukromý projekt, tak na první pohled poznám, co je můj kód a co kód cizí knihovny nebo platformy.

[deda.jabko]

Nic. Proč bych měl něco dělat s konvencí depenenčního projektu?

Tak vidis?

Přesně tohle se mi stalo nedávno na jednom C++ projektu, kde byl použit framework wxWidgets, který používá velká písmena na začátku funkcí.

S jednou knihovnou je to mila odlisnost, ktera dokaze potesit. Az tech knihoven budes mit dvacet od ruznych dodavatelu, mozna zmenis nazor.

[kralyk z abclinuxu]

S jednou knihovnou je to mila odlisnost, ktera dokaze potesit. Az tech knihoven budes mit dvacet od ruznych dodavatelu, mozna zmenis nazor.

V tom projektu jsou použity i další jiné knihovny s jinými konvencemi (vč. např. části pro podporu widlí - kdo viděl někdy konvenci winapi, ví, o čem je řeč ). Já to vidím jako věc, se kterou je lepší se vyrovnat spíš než začínat svaté války o 'správnou' konvenci... Ale je to věc názoru, nechci říct, že můj přístup je jediný správný.

[xkucf03]

v podstatě tím vylučuješ možnost mít jednotnou konvenci v projektu, který je napsán ve více než jednom jazyku - což imho není nijak neobvyklý jev.

To stejně nejde, protože to někdy nejsou jen konvence ale nepřekročitelné vlastnosti/omezení různých jazyků – někde se třeba rozlišují velká a malá písmena nebo jsou přípustné mezery/tečky/podtržítka/čísla/… a jinde ne.

Navíc na tom můžou pracovat různí lidé – někdo třeba bude mít na starosti skripty/XHTML/CSS/JS ve více projektech, zatímco jiný bude dělat spíš SQL a jiný hlavně Javu – je lepší držet společné konvence spíš podle jazyků než podle projektů. Samozřejmě pojmenování by mělo být stejné, ale jednou to bude zapsané třeba jako MojeStruktura a jindy moje_struktura.

A když si pročítáš kód a plynule přecházíš mezi svým programem a použitými knihovnami, tak je dobré, aby ty konvence byly stejné – jsi v tu chvíli přepnutý třeba v režimu „třídy začínají velkými písmeny, metody malými“. Ale když pak třeba začneš upravovat shellový skript v rámci toho projektu, tak se stejně musíš v hlavě přepnout, že teď píšeš v jiném jazyce – tak společně s tím můžeš přepnout i na jiné konvence (třeba podtržítka).

Chtěl jsem říct, že vynucení konvence jazykem v důsledku nepřináší kýžený pořádek / štábní kulturu, resp. pouze povrchně.

Podle mých zkušeností, když někdo zprasí návrh (nesmyslné/nelogické třídy, metody, nedodržování základních principů OOP nebo jiného paradigmatu), tak kdyby byl jazyk/konvence volnější, ten jeho návrh by nebyl o nic lepší, jen by to navíc bylo zprasené i co se týče názvů, velikosti písmen, odsazení, struktury souborů a adresářů atd. A četlo by se to ještě hůř, než když je špatně „jen“ ten návrh.

[kralyk z abclinuxu]

A když si pročítáš kód a plynule přecházíš mezi svým programem a použitými knihovnami, tak je dobré, aby ty konvence byly stejné – jsi v tu chvíli přepnutý třeba v režimu „třídy začínají velkými písmeny, metody malými“. Ale když pak třeba začneš upravovat shellový skript v rámci toho projektu, tak se stejně musíš v hlavě přepnout, že teď píšeš v jiném jazyce – tak společně s tím můžeš přepnout i na jiné konvence (třeba podtržítka).

Hmm, takže přepínání konvence při použití různých jazyků nevadí, ale různých projektů ano... :-/

Podle mých zkušeností, když někdo zprasí návrh (nesmyslné/nelogické třídy, metody, nedodržování základních principů OOP nebo jiného paradigmatu), tak kdyby byl jazyk/konvence volnější, ten jeho návrh by nebyl o nic lepší, jen by to navíc bylo zprasené i co se týče názvů, velikosti písmen, odsazení, struktury souborů a adresářů atd. A četlo by se to ještě hůř, než když je špatně „jen“ ten návrh.

Naprosto souhlasím. Je věc názoru, co je lepší, já jsem toho názoru, že nezprasená konvence + zprasený návrh není o nic lepší než když je zprasené ooboje (ten kód stejně někdo bude muset refaktorovat). Svým způsobem jsem i radši, když tu zprásenost vidím na první pohled

[xkucf03]

Hmm, takže přepínání konvence při použití různých jazyků nevadí, ale různých projektů ano... :-/

Je to tak. Oboje mít bohužel nelze a je potřeba si vybrat jednu možnost, tak si vybírám tuhle. Když si otevřu skript v Perlu, BASHi nebo SQL, tak na první pohled vidím, že jsem někde jinde a uvědomím si, že tam platí i jiné konvence. Ale když se v IDE v rámci jednoho jazyka prokliknu na definici nějaké metody, tak bych rád, aby tam platily stejné konvence, přestože ta třída/metoda pochází z jiného projektu/knihovny.

[JS1]

Já osobně python odsazuju tabama, není v tom problém.

To IMHO nedelas dobre. Jednou to otevres v editoru, ktery ma nastavene taby jinak, pripadne ma misto tabu mezery, ulozis.. a mas po zdrojaku (osobni zkusenost).

I kdyz je fakt, ze dnes je uz natolik bezne pouzivat verzovani, ze to zase tak moc nehrozi. Ja si radeji zapinam v editoru vzdy mezery misto tabu.

[kralyk z abclinuxu]

No takové editory naštěstí nepoužívám

[pavlix]

+1

[kralyk z abclinuxu]

ELF – ale co třeba .class v Javě nebo zkompilovaný Python, Erlang, PHP, Lisp atd.?

Tak především to musí podporovat kompilátor, pak je možné se bavit o nějakých metadatech apod...

[Josef Kufner]

Zrovna v tomto případě je `git describe` stejně užitečný jako __DATE__ a přitom vede k reprodukovatelným buildům.

[xkucf03]

Používám obojí:

$ sql-dk --version 
SQL-DK
Mercurial: 483fad138716+ v0.9
Compiled:  2014-04-06 23:37:42+02:00

ale úplnou zárukou to stejně není – musel bys mít vždy čistě naklonované úložiště zdrojáků, nesměly by tam být žádné necommitnuté změny.

[kralyk z abclinuxu]

No, balíčky se z necommitnutých změn nesestavují...

[Miloslav Ponkrác]

„Algoritmus ze stejnyho vstupu VZDY udela stejnej vystup.“

… máte větší sebevědomí, než znalosti, to se občas stává:

http://cs.wikipedia.org/wiki/Nedeterministick%C3%BD_algoritmus

---

„Jak rekl Mr. John von Neumann: Anyone who attempts to generate random numbers by deterministic means is, of course, living in a state of sin.“

Jste si jist, že jste tu větu a její smysl správně pochopil?

[Marvin]

http://cs.wikipedia.org/wiki/Nedeterministick%C3%BD_algoritmus

Nesnaz se slovickarit. Pojem "algoritmus" implicitne oznacuje "deterministicky algoritmus". A to proto ze nemame zadne jine stroje. Az budou bezne kvantove pocitace tak se ta definice muze posunout.

Jste si jist, že jste tu větu a její smysl správně pochopil?

Ano

[Miloslav Ponkrác]

Pojem algoritmus znamená libovolný postup jasně vedoucí k cíli. Opačný pojem k pojmu algoritmus je heuristický postup. Pojem algoritmus nic o determinističnosti neříká.

To, že si pleteš pojmy a dojmy, to je Tvůj problém.

K druhému, tu anglickou větu jsi krutě nepochopil. Jednak mluví o něčem jiném, než o algoritmech obecně. Mluví o obtížích až nemožnosti konstrukce generátorů náhodných čísel z deterministických postupů, což je z věty jasně patrné.

Dále dovol, abych Tvé příspěvky již ignoroval, protože Tvé znalosti a přehled jsou nulové, ale sebevědomí máš až do nebe, bohužel ničím nepodložené. Smysl debaty za takových okolností není žádný.

[:::]

Heuristika neni algoritmus?

A pak jeste napise neco o tom jak si ostatni pletou "pojmy a dojmy" :))

--

K vete: Podle me je tam jasna spojitost.

Algoritmus se chova vzdy stejne. Z toho plynou obe veci:

- neni mozne generovat opravdu nahodna cisla

- pro stejny vstup vygeneruje stejny vystup

[Miloslav Ponkrác]

Ach jo. Ne, pokud se budeme držet přesných definic, pak heuristika není algoritmus.

Stejně tak vycucané nesmyslné a nepravdivé tvrzení, že algoritmus se chová vždy stejně, které jste si vymyslel, protože se vám to zdá logické, neplatí.

Příště doporučuji spíše si něco přečíst, než začnete diskutovat. Já se dalších diskusí na téma hlupák dělá chytrého už zříkám a reagovat na to nebudu.

[deda.jabko]

Ach jo. Ne, pokud se budeme držet přesných definic, pak heuristika není algoritmus.

Aby ta diskuze mela smysl, muzete sem postnout vase definice, pokud mozno vcetne nejakeho autoritativniho zdroje.

Docela by me zajimalo, zda podle tech definic jsou treba takove greedy algoritmy ve skutecnosti algoritmy, nebo heuristika.

[:::]

Ach jo. Ne, pokud se budeme držet přesných definic, pak heuristika není algoritmus.

-- Miloslav Ponkrác

Heuristika *je* algoritmus. ktery ale nepocita presne reseni.

In computer science, artificial intelligence, and mathematical optimization, a heuristic is a technique designed for solving a problem more quickly when classic methods are too slow, or for finding an approximate solution when classic methods fail to find any exact solution. This is achieved by trading optimality, completeness, accuracy, or precision for speed. In a way, it can be considered a shortcut.

-- zdroj

--

Stejně tak vycucané nesmyslné a nepravdivé tvrzení, že algoritmus se chová vždy stejně, které jste si vymyslel, protože se vám to zdá logické, neplatí.

-- Miloslav Ponkrác

Ja a marvin nejsme jedini kdo si mysli ze pokud neni receno jinak, tak "algoritmus" == "deterministicky algoritmus":

Often in computational theory, the term "algorithm" refers to a deterministic algorithm.

-- zdroj

--

Příště doporučuji spíše si něco přečíst, než začnete diskutovat.

-- Miloslav Ponkrác

Doporucuju precist odkazy nahore a pak se zamyslet jestli to nejses ty kdo potrebuje neco dostudovat

--

Já se dalších diskusí na téma hlupák dělá chytrého už zříkám a reagovat na to nebudu.

-- Miloslav Ponkrác

Prelozeno do cestiny: "Diskuzi vzdavam. Evidentne na ni nemam mentalni kapacitu "

[JS1]

Algoritmus se chova vzdy stejne.

Nejsem si jisty, jestli to skutecne plati. Vezmi si treba randomizovane algoritmy - ty jsou deterministicke v tom smyslu, ze na stejny vstup davaji stejny vystup, nicmene jejich chovani (zpusob vypoctu) se skutecne muze v jednotlivych spustenich lisit.

[Josef Kufner]

Všechny současné počítače i algoritmy pro ně jsou deterministické. A pokud náhodou nejsou, je to způsobeno nějakou chybou. Jediná výjimka jsou hardwarové generátory náhodných čísel, které sbírají nějaký šum a podle toho si cucají bity z prstu.

Hardwarovým generátorem nemusí být jen dedikovaný kus hardwaru, běžně se používá například pohyb myší uživatelem, události od ovladačů a další věci, které je obtížné předpovídat. Ale pokud tyto vstupy podvrhneš, algoritmy, které to sbírají, ti to nakombinují do stejného výstupu kolikrát budeš chtít.

Všechny algoritmy, kde vystupuje náhoda, mají tuto náhodu jako vstupní proměnnou, kterou si načtou například z toho hardwarového generátoru. Softwarové generátory náhodných čísel jsou jen pseudonáhodné, neboť používají nějaké pěkné matematické udělátko na vyrábění šumu. Ale pokud znáš počáteční semínko, můžeš si nechat vygenerovat stejnou "náhodnou" posloupnost znovu. Například OpenTTD to umožňuje nastavit při zakládání nové hry, takže zadáním stejného čísla si můžeš nechat vygenerovat znovu stejnou "náhodnou" mapu.

[JS1]

Ano, muzes nad tim takto filozofovat. Ja jen, ze rozliseni na deterministicky a nedeterministicky jde trochu jinudy. Oznaceni deterministicky algoritmus neimplikuje nutne stejne chovani na stejnych vstupech (priklad: randomizovany algoritmus), a naopak oznaceni nedeterministicky algoritmus neimplikuje neopakovatelnost (priklad: ulozeny vstup z nahodneho generatoru).

Ono obecne lze na ruznych urovnich celkem snadno prechazet mezi determinismem a nedeterminismem (napriklad pocitace jsou zpusob, jak vykonavat deterministickou cinnost na nedeterministickem fyzikalnim zaklade fyziky mnoha castic), coz ponekud invaliduje ruzne diskuse o svobodne vuli a podobne.

[JS1]

Asi bych to jeste rekl lepe: Zda je neco deterministicke zalezi prave na urovni naseho pohledu. Tudiz treba pocitac:

- na urovni jednotlivych atomu a elektronu je nedeterministicky

- na urovni hradel je deterministicky

- na urovni aplikace muze byt zase nedeterministicky, pokud treba OS nabizi API pro pseudonahodny generator

[Josef Kufner]

Pseudonáhodný generátor je deterministický. Proto ta předpona "pseudo"

[JS1]

To plati prave jen za urcitych predpokladu. Z hlediska aplikace, ktera bezi nad OS, na kterem mohou bezet i jine aplikace, a pseudonahodny generator poskytuje ten OS, deterministicky neni.

[Josef Kufner]

Oznaceni deterministicky algoritmus neimplikuje nutne stejne chovani na stejnych vstupech (priklad: randomizovany algoritmus)

Kdepak. To je přesně to, co to slovo znamená. To není filozofování, to je prostá definice:

Deterministický algoritmus je v informatice označení pro algoritmus, který vždy ze stejných výchozích (vstupních) podmínek svým během vytvoří stejné výsledky (je tedy předvídatelný). Každý aktuální i následující krok vykonávání algoritmu je vždy jednoznačně definován. (Zdroj a formální definice)

Randomizovaný algoritmus je deterministický, jen má jeden vstup navíc – náhodné číslo. Z pohledu ostatních komponent sice můžeš tento vstup zanedbat a považovat to za nedeterministickou věc, ale to nemění nic na tom, že ve skutečnosti algoritmus nedeterministický není a nedeterminismus je schovaný vedle.

Občas je docela obtížné tento další vstup identifikovat, například při výskytu race-conditions nebo při interakci s externím prostředím, ale i tam jsou algoritmy deterministické a nedeterminismus má na svědomí něco jiného.

[JS1]

Z pohledu ostatních komponent sice můžeš tento vstup zanedbat a považovat to za nedeterministickou věc, ale to nemění nic na tom, že ve skutečnosti algoritmus nedeterministický není a nedeterminismus je schovaný vedle.

No ale nerikas pak to same, co ja? Napsal jsem, ze randomizovany algoritmus lze povazovat za deterministicky, presto ale nechova se na stejnem vstupu (zase jde o vstup z hlediska teorie algoritmu) stejne.

[kralyk z abclinuxu]

Abych nemluvit teoreticky. Zde je příklad zdrojového kódu, který při kompilaci stejným kompilátorem dává odlišné binárky a tento způsob ověření nebude fungovat:

int main() { printf("Program (zkompilován %d) spuštěn\n", __DATE__); // ... return 0; }

A shořeli jste s ověřením jako papír snadno a rychle.

$ faketime '2008-12-24 08:15:42' gcc main.c
$ ./a.out
Program (zkompilován Dec 24 2008) spuštěn

Myslím, že jediný, kdo tu snadno a rychle hoří, jsi ty...

[Miloslav Ponkrác]

Vynikající. Budeme kompilovat zdrojáky s falešným systémovým časem. Mohli bychom třeba rozehrát takový malý boj programátorů vůči balíčkovačům v Debianu. Jako protitah nabízím tuto funkci:

// Module fight.c
// $Id$
// Do Id systém správy verzí doplní mimo jiné datum a čas poslední změny.

bool isCompileTimeBad()
{
  time_type const last_source_commited = getTimeFromId("$Id");
  time_type const compile_time = getTimeFromMacro(__DATE__, __TIME__);
  if (last_source_commited >= compile_time)
    return true;
  if (getTimeDifferenceInDays(last_source_commited, compile_time) > 1000)
    return true;
  return false;
}


int main()
{
  if (isCompileTimeBad())
    exit(EXIT_FAILURE);
  // ...
}

Jste na řadě.

[kralyk z abclinuxu]

Tím jsi dokázal, že pokud zkopmilujeme jiný zdrojový kód, vznikne (potenciálně) jiná binárka. Tomu říkám objev. Gratuluji

[pavlix]

Dokonalost.

[Miloslav Ponkrác]

Kompilujeme stále stejný zdrojový kód. Dokonce vznikne i stále stejná binárka, pokud podvrhnete stále stejný systémový čas při kompilaci. Pokud tvrdíte něco jiného, zřejmě jste zdroják nepochopil. Co se mění je, že program nederministicky, s určitou mírou pravděpodobnosti odmítne běžet, pokud kompilující persona si budete ve faketime příliš vymýšlet.

[kralyk z abclinuxu]

Cože??? Jestliže vznikne stejná binárka jako ta, která vznikla při kompilaci balíčku, tak je všechno v pořádku, nesnad? To přece bylo cílem

[Miloslav Ponkrác]

Ano, akorát, že pokud zkompilujete program normálně, bude fungovat. A nebude vnizkat při kompilaci stejná binárka.

Pokud se ho snažíte srovnat do latě fake časem, pak sice bude vznikat stejná binárka, ale program nebude uživateli vždy fungovat správně.

Něco mi říká, že uživatelé nepreferují postupy, které jim vyrábějí nefunkční binárky. A to ani za báječného předpokladu, že binárka je super zkontrolovaná.

Ale možná se chováte jinak a používáte záměrně programy, které nepracují správně. A pak chápu, že Vám nedochází, že to není ta pravá cesta.

A nyní dovolte, abych tuto diskusi už skončil. Napsal jsem toho už dost a čas je příliš cenný na diskusích pořád dokola.

[kralyk z abclinuxu]

Něco mi říká, že uživatelé nepreferují postupy, které jim vyrábějí nefunkční binárky.

Jestliže ten balíček obsahuje špatně funkční binárku, tak ho uživatelé nebudou prefereovat zcela bez ohledu na to, jestli ho někdo zkontroluje, nebo ne, nebo jestli vůbec je zkontrolovatelný.

Ty ale jen tak trolluješ, ne? Protože takhle blbý příklad snad nikdo nemůže myslet vážně...

[xkucf03]

Pro běžné distribuce, kde se dělají balíčky jednou pro x86 a jednou pro amd64 (žádné optimalizace pro konkrétní stroj se neřeší) a kompiluje se standardním kompilátorem, který je toho času v dané distribuci, to může klidně fungovat.

A kdo chce optimalizovat a používat vlastní kompilátory, ten si může instalovat přes

apt-build install …

a kontrolovat otisk zdrojových balíčků.

[Miloslav Ponkrác]

Nemůže. Protože polovina programů vypisuje při spuštění s parametrem --version jako informoci o verzi jednak číslo verze, jednak datum a čas kompilace.

Prostě je to nesmyl jako kontrola.

[xkucf03]

Tak se ta informace o času kompilace buď vypustí a pak půjde kontrolovat otisk celého .deb/.rpm/apod. balíčku, nebo se přesune do samostatného souboru a při kontrole se pak dozvíš, že všechno odpovídá, kromě souboru version.txt a ukáže ti to jeho diff, kde uvidíš, že se změnil jen čas.

[kralyk z abclinuxu]

Nebo by se dal kopmilátoru předhodit datum/čas stejný jako má balíček, viz třeba libfaketime. To mi přijde jednodušší.

[Miloslav Ponkrác]

Mně přijde nejjednodušší se smířit s tím, že teorie, že stejný zdroják dá stejnou binárku je nesmysl, než hackovat systémový čas.

Spíše bych se poohlédl po mechanismu kryptologického podpisu binárky jejím autorem, což je IMHO daleko spolehlivější a méně problematická cesta.

Technické zajištění, aby bylo možné zjistit, že binárka přesně odpovídá danému zdrojáku je možné jen jediným způsobem a to současným splněním všech následujících podmínek:

1) Že si tu binárku zkompilujete sám vlastníma rukama.

2) Nemáte podvržený kompilátor (či jiný škodlivý kód na kompu), který někdo tajně změnil, aby generoval jiný kód, než ve zdrojáku.

[kralyk z abclinuxu]

Mně přijde nejjednodušší se smířit s tím, že teorie, že stejný zdroják dá stejnou binárku je nesmysl, než hackovat systémový čas.

Můžeš dát příklad, kde se v procesu kompilace C/C++ vyskytuje nedeterminismus? Preprocesorové kravinky jako __DATE__, __TIME__ a __FILE__ jsou snadno řešitelné. Co dál?

[Miloslav Ponkrác]

Cokoli, kde do procesu kompilace vstupuje okolní proměnná.

Například jakýkoli překlad, který kompiluje na míru stroji. Běžně se používá před řadou programů komfigurace.

Třeba jsem jednou studoval knihovnu pro výpočet velkých čísel. Kompilovala se na míru počítači a to tak, že před kompilací program pročmuchal parametry stroje – jaké instrukce umí procesor, jak je stroj rychlý a další – a vygeneroval tabulky čísel (jako C zdroják), které optimalizovaly rychlost výpočtů pro daný stroj na největší efektivitu. A zdroják + tabulky se pak standardně přeložily.

On se totiž zdroják dá nejenom napsat rukou, ale také vygenerovat automatem. A dělá se to dosti často.

[Hans1024]

Tady se bavime o distribucich, ty obvykle binarky nekompiluji na miru konkretnimu pocitaci.

[Miloslav Ponkrác]

Ale mohly by podvrhovat fake hodnoty času.

Pokud máte na to ověřit, že binárka z distribuce je stejná jako vzor, který si ze zdrojáků zkompilujete u sebe, pak je jednodušší a lepší ověření, že se na distribuční binárku vykašlete rovnou, a zkompilujete si to ze zdrojáků sám.

Vymýšlet, jak se levou rukou podrbat za pravým uchem, je skvělý trénink, ale hloupý.

[Hans1024]

Tak pardon, ze nam nezalezi jen na uzivatelich Gentoo.

[kralyk z abclinuxu]

Pokud máte na to ověřit, že binárka z distribuce je stejná jako vzor, který si ze zdrojáků zkompilujete u sebe, pak je jednodušší a lepší ověření, že se na distribuční binárku vykašlete rovnou, a zkompilujete si to ze zdrojáků sám.

Není pravda, protože pak nemám nic, na základě čeho bych mohl upozornit komunitu, že nějaký dsitributor distribuuje podvržené binárky.

[Miloslav Ponkrác]

Pokud chcete dělat veřejný kontrolní úřad, pak máte pravdu. Ale požadavky kontorlních úřadů jsou jiné, než pokud hledáte osobní řešení.

[xkucf03]

Takové programy by se ale do distribucí neměly dostat, protože hrozí, že na cílových strojích (jiných, než kde se kompilovalo) nebudou fungovat nebo budou neefektivní. Resp. dostat se tam mohou, ale distributor by o tom měl vědět a měl by nasimulovat (nebo předat jako volbu při kompilaci) nějakou stabilní konfiguraci, kterou předpokládá u koncových uživatelů. Asi jako když dělám balíčky pro x86, tak tam taky nebudu strkat kousky programů pro amd64, přestože se to na amd64 kompiluje.

Takže reprodukovatelné buildy zde nejsou problém, nýbrž nástroj, který mne na (nezávisle existující) problém upozorní.

[Miloslav Ponkrác]

Máte pravdu v tom, že je možné definovat množinu podmínek, za kterých vzniknou reprodukovatelné buildy (abych použil Váš termín).

Jistě to možné je, ačkoli v té množině podmínek bude víc bodů, než jen nepoužívat __DATE__ a __TIME__, ale je to v principu řešitelné.

Mým názorem je, že to stejně nic neřeší. Chcete-li ověřit binárku vůči zdrojákům, stejně si ji musíte zkompilovat u sebe a porovnat hashe. Pak ale nemusíte binárku z distribuce tahat vůbec a rovnou si zkompilovat ten zdroják. A tím pádem není třeba nic ověřovat.

[Hans1024]

Asi nechapete k cemu to ma slouzit. Tady nejde o to, aby si to overoval kazdy, tady jde o to, ze stejne jako u otevrenych zdrojaku maji lidi moznost se do nich podivat (a nekteri to udelaji), tak u reprodukovatelnych binarek maji lidi moznost je nezavisle reprodukovat (a nekteri to udelaji), coz ve vysledku zvysi celkovou duveryhodnost.

[Miloslav Ponkrác]

Za předpokladu, který v realitě nikdy nedosáhnete, že všichni programátoři nebudou používat podmíněnou kompilaci ani nic, co by měnilo výsledek kompilace.

Jinak řečeno, teorie je to krásná, ale praxe ji zničí. Nic jiného neříkám.

[pavlix]

Asi nechapete k cemu to ma slouzit.

Což znemožňuje jakoukoliv smysluplnou diskuzi. Ten mechanismus není úplně jednoduchý a myslím si, že je i hodně postavený na zkušenosti. Člověk, kterému je to absolutně cizí a pochopit to ani nechce, podle mě nemá šanci.

[Miloslav Ponkrác]

A nebo je ten nápad úplně pitomý absolutně od začátku, a nechtějí to pochopit druzí.

Je třeba brát v úvahu obě variantu, pokud chcete objektivně rozhodovat.

[Bystroushaak]

Mým názorem je, že to stejně nic neřeší. Chcete-li ověřit binárku vůči zdrojákům, stejně si ji musíte zkompilovat u sebe a porovnat hashe. Pak ale nemusíte binárku z distribuce tahat vůbec a rovnou si zkompilovat ten zdroják. A tím pádem není třeba nic ověřovat.

Tohle je imho validní argument, který by tu měl zaznít častěji, namísto hádek nad determinističností. I když se to povede naprogramovat, tak k čemu že to vlastně prakticky bude? Aby uživatelé binárních distribucí měli možnost ověřit balíky. Balíky ověří jejich kompilací. Skoro nikdy nebude všechno kompilovat, protože pak by nemusel používat binární distribuci. Lidi budou muset věřit třetí straně -> jsou tam kde byli.

Pokud NSA náhodou infikuje nějaký balík, tak si chudáci budou muset dát tu práci, aby po sobě upravili i ten hash.

[xkucf03]

Skoro nikdy nebude všechno kompilovat, protože pak by nemusel používat binární distribuci. Lidi budou muset věřit třetí straně -> jsou tam kde byli.

Představ si, že někomu dodáš software, dáš mu zdrojáky i binárky pro snadnou okamžitou instalaci. On to nemusí kompilovat ani kontrolovat, ale může – což tě nutí dělat svoji práci pořádně a odevzdat mu skutečně svobodný software, kompletní zdrojáky, které jdou přeložit. A on má záruku, že když si ve zdrojáku třeba opraví nějakou chybu, že mu v programu nezmizí pět jiných funkcí, protože ty jsi tam jaksi přikompiloval nějak jinak a „zapomněl“ jsi mu říct, že ty zdrojáky vlastně nebyly kompletní nebo úplně aktuální.

Ty reprodukovatelné buildy beru jako dobrou praktiku, která nutí lidi dělat věci správně a transparentně. Ne jako něco, co by se muselo dnes a denně používat a neustále kontrolovat – i náhodné občasné kontroly pomáhají vytvářet ten tlak na kvalitu.

Stejně tak by třeba program neměl komunikovat po síti, pokud k tomu nemá uživatelem daný důvod, nebo by neměl číst soubory na tvém disku, které ke své funkci nepotřebuje.

Pokud NSA náhodou infikuje nějaký balík, tak si chudáci budou muset dát tu práci, aby po sobě upravili i ten hash.

To by právě museli upravit přímo ten zdroják – neříkám, že to nejde, ale nestačí prostě získat klíče distributorů a nacpat na jejich servery svoje balíky – resp. přišlo by se na to.

[Grunt]

I když se to povede naprogramovat, tak k čemu že to vlastně prakticky bude?

Já ti to nepovím. Ale doporučuju použít Google, protože pak zjistíš že odpověď na tuto otázku hledají všude možně (povětšinou v otevřených projektech), vč. FSF nebo Red Hatu. Takže laicky si myslím, že to asi bude mít nějakou váhu (jinak mi není jasné proč by nad tím tolik lidí ztrácelo čas).

[Grunt]

Oprava: Zrovna jsem si projel nějaké odkazy s podíval se na jednu přednášku a jede v tom mnohem víc entit než jsem si původně představoval, včetně BitCoinové komunity. Proč je to tak důležité, ale stále nevím.

[xkucf03]

Spíše bych se poohlédl po mechanismu kryptologického podpisu binárky jejím autorem, což je IMHO daleko spolehlivější a méně problematická cesta

Tady záleží, kdo to kompiluje, jestli autor nebo distributor. Běžně se to podepisuje, byť na úrovni archivů – autoři podepisují tar.gz s binárkami a distributoři zase .deb/.rpm balíčky. Podepisovat to na úrovni binárky a kontrolovat při každém spuštění sice jde, ale až tolik užitku to nepřináší.

Že někdo něco podepsal je sice hezké, ale k čemu mi to je, když nevím, jak moc mu můžu věřit?

Ovšem když mám podepsaný zdroják, ze kterého ta binárka prokazatelně vzešla, tak to můžu zpětně použít jako důkaz, že tam tu chybu zanesl on – což by mělo působit preventivně, aby tam nikdo raději tu chybu nezanesl. A další věc je, že i když v programu nějaká škodlivá vlastnost bude, můžu ji odstranit a program dál používat, nemusím ho zahazovat úplně a přecházet jinam.

[Miloslav Ponkrác]

„Že někdo něco podepsal je sice hezké, ale k čemu mi to je, když nevím, jak moc mu můžu věřit?“

Souhlasím. Ale nic lepšího zatím nikdo nevymyslel.

Na druhé straně třeba linuxová komunita věří distribučním serverům Debianu natolik, že běžně nechává automaticky updatovat i důležité servery přímo z nich po internetu, aniž by tomu nevěřila. Zde se uplatňuje linuxovou komunitou mnohem vyšší stupeň důvěry.

---

„Ovšem když mám podepsaný zdroják, ze kterého ta binárka prokazatelně vzešla, tak to můžu zpětně použít jako důkaz, že tam tu chybu zanesl on“

Za předpokladu, že nebude chyba v kernelu, operačním systému, konfiguraci počítače, v hw, nebo v nějaké knihovně. Stejně jako že chyba není ve vstupních datech, ani uživatel obsluhující program neudělal nikdy žádnou chybu.

Pak je možné jednoznačně říci, že chybu udělal autor zdrojáku.

---

„A další věc je, že i když v programu nějaká škodlivá vlastnost bude, můžu ji odstranit a program dál používat, nemusím ho zahazovat úplně a přecházet jinam.“

Něco jako každý uživatel vynikajícím programátorem? To asi neklapne.

Teoreticky máte pravdu, ale prakticky to tak jednoduché není.

[Miloslav Ponkrác]

Proč by se měla vypustit? Z jakého důvodu?

[Hans1024]

Vy to nemyslite vazne, ze? Vy tady jenom tak trollite, ze?

[Miloslav Ponkrác]

Myslím to vážně.

Spíše mě fascinuje, s jakou vehemencí se obhajuje špatný nápad, který by měl být opuštěn, než se snažit o jeho nalepovák, který stejně nebude fungovat.

Datum a čas kompilace je jenom jednou z mnoha možností, zdůrazňuji jen jednou z mnoha, která způsobuje, že binárka nezůstává stejná při opakovaných kompilacích.

[Hans1024]

Me zase fascinuje, ze si o tom nic poradne neprectete ani nezjistite, ale presto to kritizujete, jak hospodsti politici u piva.

[Miloslav Ponkrác]

Mě zase fascinuje Váš komentář obsahující celkem výrazné množství věcné argumentace, a to celkem nula bitů.

Reagovat na komentář bez jakékoli argumentace je nesmysl, jak jistě sám uznáte, protože není na co reagovat.

[Hans1024]

Jiste. Zatimco cela vase argumentace stoji na trivialne resitelnem problemu timestampu.

Pripada mi to jako:

"Ja nemuzu nikam jit, protoze mam hlavu v zadnici!"

"Tak si vytahnete hlavu ze zadnice."

"A proc bych to delal?"

"Abyste mohl nekam jit."

"A jak vite ze pak budu moct nekam jit?"

"Jini to zkusili a povedlo se jim to."

"Tak to teda ne, my to budem bojkotovat a zastrcime tu hlavu jeste hloubeji!"

[Miloslav Ponkrác]

Dal jsem v této diskusi řadu příspěvků, kdy ukazuji, že je mnohem více situací, než timestamp, které mění binární otisk.

Spíše mi přijde, že se řeší, jak strčit hlavu do zadnice a nemít ji umazanou od vnitřního obsahu střeva. Já tvrdím, že je lépe ji tam nestrkat vůbec (tedy opustit myšlenku stability hashe binárky).

Ostatní tvrdí, že když se nebude hlava do zadnice strkat rovně, ale pod úhlem 30 °, že nebude od exkrementů. Případně když si vývojář dá předtím klystýr (nebude používat podmíněnou kompilaci), nebudou žádné exkrementy. Já na to, je to fajn myšlenka, teď jen všechny ty celosvětově ty vývojáře donutit, aby si zavedli klystýr pří vývoji, a bude to ok.

[pavlix]

Přirovnání s exkrementy, to je ještě lepší než běžná jirsákovská přirovnání s auty a letadly.

[Miloslav Ponkrác]

Já si s hlavou zadnici nezačal, pane učiteli. To prosím Hans1024.

[pavlix]

Pravda je, že hansova verse přirovnání mi přišla vcelku trefná.

[Miloslav Ponkrác]

Mně nikoli. Hansova verze vychází z předpokladu, že JAKÝKOLI NÁPAD je dobrý, jen je třeba vymyslet, jak ho zrealizovat. Nepočítá a variantou, že některé nápady jsou hovadiny samy a sobě a je lépe je nerealizovat vůbec a vymyslet něco jiného.

[pavlix]

Na tuhle slovní onanii nemám žádnou odpověď ;).

[Miloslav Ponkrác]

A to je to nejlepší zakončení nesmyslné diskuse. Kéž by byli všichni tak moudří jako pavlix.

[Grunt]

Nepočítá a variantou, že některé nápady jsou hovadiny samy a sobě

No jak se tak dívám, rozhodně není sám.

[Xerces]

Napište to prosím také někam do diskuze k systemd

[xkucf03]

A co teprve exkrementy padající z letadel na auta!

[Grunt]

LOL. Tak to nemá chybu. To je ještě lepší než moje proměřování a porovnávání kruhovitosti a průměru rektálních otvorů. Pokaždé když se diskuze zvrtne do umazávání si hlav obsahem vnitřní strany tlustého střeva, je to znamení toho, že diskuse začíná být opravdu vážná. Klaním se před velmistrem vykrucování, protože vymyslet tak stupidní analogii, na to už musí být jeden vážně retardovaný.

[Bystroushaak]

LOL. Tak to nemá chybu. To je ještě lepší než moje proměřování a porovnávání kruhovitosti a průměru rektálních otvorů.

Na tohle to ale nemá; Silicon Valley dick jerk algorithm (mimochodem zatím nejlepší komediální seriál za tenhle rok)

[kralyk z abclinuxu]

Dal jsem v této diskusi řadu příspěvků, kdy ukazuji, že je mnohem více situací, než timestamp, které mění binární otisk.

Pokud vím, tak nedal, kromě modifikace zdrojáku, což je triviální případ.

[Grunt]

Jinak odborník na strkání hlav do prdele se pozná už po čuchu. Od dnešního dne nestrkám hlavu do prdele jinak než pod úhlem 30°. Děkuji za radu.

[xkucf03]

Píšu vypustit nebo přesunout do samostatného souboru. Čas uvedený v souboru version.txt má stejnou váhu jako čas uvedený přímo v binárce (podvrhnout se dá oboje). Ale binárka se stabilním hashem pro mne má větší hodnotu, než binárka, která je pokaždé jiná, i když zdroják a kompilátor zůstávají stejné.

[Miloslav Ponkrác]

Chápu. Jen nejsem přesvědčen, jestli požadavek stability hashe binárky při opakovaných kompilacích je rozumný požadavek.

V historii se požadavek záruky na to, že je spuštěn daný zdroják řešil vždy tak, že se na daném stroji zkompiloval. Nic lepšího nikdo nevymyslel. Navíc to v ničem neomezuje.

A to nemluvím o tom, že řada programů si přímo do binárky při instalaci i leccos zapisuje.

A to nemluvím třeba o kernelu, který se na daném stroji zkompiluje na míru stroji, třeba jen s určitou podmnožinou driverů. Taková binárka je také proměnlivá.

Jednoduše jsem přesvědčen, že tudy cesta nevede. A že je to neřešitelné bez kastrace mnoha užitečných možností programů.

[Josef Kufner]

Jedno další využití reprodukovatelných buildů je distribuovaná kompilace.

Několik klientů reprodukovatelně zkompiluje stejný zdrojový balíček a dá je k dispozici (např. po BitTorrentu). Na server se uloží jen název, verze, URL repositáře se zdrojáky a hash. Klienti si zkompilovaný balíček mohou stáhnout a podle hashe ze serveru ověřit jeho pravost.

Server hash zveřejní až poté, kdy od několika nezávislých klientů obdrží stejný hash. Kompilující klienti zaslaný hash podepíšou, aby bylo zarueno, od koho jsou. Zbytek je jen o nastavení politiky na serveru o tom, co považuje za důvěryhodné. Podpisy kompilujících je možné přiložit k balíčkům pro zvýšení důvěryhodnosti.

Ve výsledku distributorovi stačí jen minimální infrastruktura, v podstatě jeden server s indexem balíčků a jejich hashi. Vše ostatní může být zcela decentralizované. Přitom však není nutné, aby všichni kompilovali vše.

[Josef Kufner]

Není třeba nic vypouštět. Naopak, ten čas je potřeba uložit do balíku.

Když se balíček kompiluje poprvé, uloží se do něj čas kompilace. Když se bude balíček reprodukovat, přečte se z původního balíčku čas kompilace a nastaví se novému buildu. Výsledkem bude identický balíček jako při prvním buildu.

Alternativou je použít čas verze (commitu) ze kterého je buildováno. Tedy nastavit __DATE__ a __TIME__ na hodnotu `git log --pretty="%ci" -n 1` (v odpovídajícím formátu).

Takto budeš mít obojí, smysluplný čas kompilace i reprodukovatelný build.

[Venda]

... se nesnažím klienty ...

trochu OT, ale obcas se to snad musi rict:

vim, ze porevolucni doba ssebou prinesla kopirovani 'zapadni' mluvy a vznikl jakysi gulas ohledne vlastni identity, jazyka. Proto dochazi k temto jazykovym vystrelkum, kdy se misto slova 'zakaznik' pouzije slovo klient. Zduraznuji jeste jednou, vim , ze mladi lide za to nemohou, ale prave proto je snad nato treba upozornit.

Tedy, o klientovi hovori zejmena pravnici - maji totiz k zakaznikovi jiz ze zakona zvlastni vztah a slovem klient je tento duverny vztah prave vyjadren. Zrovna takovy duverny vztah existuje mezi lekarem a 'pacientem', i kdyz se nam dnesni doba snazi namluvit, ze nemocnice delaji vsechno mozne pro 'klienty'.

Prosim, mejte na pameti, ze jazyk je vec veskrze logicka a pouzivani spravnych pojmu usnadnuje komunikaci. Kdyz tedy budete pro nekoho delat nejake software, tak se nestydte mluvit o zakaznicich, neni to nic sprosteho.

[helment]

Tak ono je to hlavně proto, že mám výhradně zahraniční zákazníky a tak nějak už to mám zadrátované a jde mi to na jazyk jako anglismus Ale díky za upozornění

[pavlix]

Hlavně že v některých zemích je klient každý, kdo si dojde pro česnek do obchodu. Chápu rozhořčení nad vytěsňováním českých slov i pokusy o intuitivní chápání pojmů. Ale tady mi přijde, že to vnáší spíše zmatek než cokoliv jiného.

[podlesh]

Tou revolucí je míněna která přesně? Tuto připomínku jsem totiž viděl v prvorepublikovém fejetonu.

A když už jsem u té historie, tak se mi vybavuje kritika z let šedesátých o podužívání "doba" jako aktivní, dokonce myslící entity: "doba se snaží", "doba přinesla", "za to může doba".

OT, ale je myslím zajímavé na to upozornit

Zrovna takovy duverny vztah existuje mezi lekarem a 'pacientem', i kdyz se nam dnesni doba snazi namluvit, ze nemocnice delaji vsechno mozne pro 'klienty'.

A je to opravdu totéž? Nejsem si jistý, zda pacient bez právní způsobilosti (např. novorozenec) je klient. A na druhou stranu, myslím že mezi klientynemocnice patří někdy i právnické osoby, které zcela jistě nejsou pacienty.

Z těchto důvodů si myslím, že problém není nahrazení jednoho pojmu druhým, ale prosté zmatení pojmu lidmi kteří nedostali ty správné instrukce (a sami si to moc neujasnili). Prostě normální šlendrián, typický pro každou dobu.

[podlesh]

Jo, a že jsem si vzpomněl - otázka "klient nebo zákazník" se objevila i v románu "Ponurý dům" (kapitola 22). Rok vydání 1853.

[psio]

Souhlasim. Jazyk je mocny nastroj manipulace a korporatni zmrdspeak masivne infiltroval do bezne komunikace. I tyhle zdanlive nuance vyznamne ovlivnuji mysleni lidi a klade vyssi naroky na rozkryvani praveho obsahu sdeleni ("v zajmu zvyseni kvality poskytovanych sluzeb" vs. "zajisteni pravne pouzitelneho materialu proti zakaznikovi pro pripadne soudni spory" apod.).

Vyucuje se o tom v zakladnich kurzech lingvistiky, Noam Chomsky o tom pise snad v kazdem dile. Kdo se ucil cizi jazyk na hovorove urovni, tak muze potvrdit jak nutne je proniknout i do zpusobu uvazovani aby plne rozumel.

[JS1]

Prosim, mejte na pameti, ze jazyk je vec veskrze logicka a pouzivani spravnych pojmu usnadnuje komunikaci.

Neni.

[Josef Kufner]

Ale je. Jen většinou prostý obsah sdlení není hlavní důvod pro provedení sdělení.

[JS1]

Cekal jsem, ze se nekdo takto blbe ozve a bude polemizovat s tim "vec veskrze logicka". Snazil jsem se to zestrucnit, dekuji ti za to, ze se to nepovedlo.

[coder]

Jo tak tohle má dobrou úroveň.

[Grunt]

Docela zajímavé jak se čtyři elementární svobody týkají mnohem více věcí než-li je software.

[Agent]

Stále si okusuje nohy?

Pojďme si vyprávět fťypi:

Pánské spodky se dělí podle věku na tři druhy: do 30 let - je to klec na tygra 30 - 50 let - taška na šaška nad 50 let - chýše pro měkkýše..

Neurolog potká kolegu gynekologa a ptá se ho: U nás je to na nervy, a jak u vás?

Vtrhne primář se samopalem do pokoje k pacientům a zahuláká: Tohle je poslední dávka, kterou vám hradí pojišťovna..

Postarší manželský pár si zaplatil vyhlídkový let. Pilot jim říká, když to vydržíte potichu aniž byste cekli, máte to zadarmo. Tak s nima ve vzduchu vyvádí různé akrobatické kousky. Když přistanou, povídá, vy jste dobrý, neslyšel jsem ani hlásku! Vystrašenej chlap na to, no já chtěl křičet už když vypadla manželka, ale řekl jsem si, že to vydržím..

Zvířátka jela na dovolenou a probíhalo to jako u lidí: Lišák jel s milenkou. Osel jel s manželkou. Vůl s celou rodinou. Kanec jel sám a čekal, jaká svině se k němu přidá..

[Ondra]

tak na tomto prispevku je videt, ze i trolling se musi umet. a kdyz se umi, stoji to za to. vytribeny vkus pro humor i cit pro detail. spicka ve svem oboru, podobne jako prednaska RMS zase v oboru svem.

za me + 1

[frdrx]

Úspěšnost trollingu se měří počtem reakcí.

[Bystroushaak]

Počtem a silou. Zrovna tohle bych třeba ani jako trolling vůbec neklasifikoval.

[frdrx]

Já právě taky ne.

[Grunt]

Stále si okusuje nohy?

Hele, jak to bylo o tom staviteli mostů?

[JZD]

Nejsou k tomu české titulky, aspoň že byly obrázky, ty se mi líbily.