Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ondřej Novák

Stran: 1 ... 34 35 [36] 37 38
526
Vývoj / Re: Serializácia a deserializácia C++
« kdy: 02. 05. 2011, 00:29:12 »
Čau Stene.

K serializačním konstruktorům jsem se zatím ještě nedostal, spíš to řeším tak, že objekty jsou konstruované v základním (výchozím) tvaru. To nutně nemusí znamenat, že musí mít defaultní konstruktor. Ale myšlenkou je, že serializací se zaznamenává stav nějakých objektů a deserializací se ten stav obnovuje. Tedy nejprve se objekty zkonstruují ve výchozím stavu a pak se jim ten stav změní.

Proč jsi v původním mém konceptu změnil operator () na operator &?  On se operátor () dá použít i jako volání funktoru.

527
Software / Re: Proč firmy používají proprietární sw?
« kdy: 27. 04. 2011, 16:18:33 »
Prosté. Protože firmy řídí dementi, co si neumí spočítat nebo si nenechají poradit, že používáním OSS místo fujky proprietárního SW by vydělali víc. To je totiž primární důvod existence firem, vydělat svým majitelům.


A shodou okolností ti dementi pak vydělávají prachy  ;D

528
Software / Re: Proč firmy používají proprietární sw?
« kdy: 27. 04. 2011, 16:17:30 »
Ale stale to len potvrdzuje tvoju neschopnost, pretoze plno inych ludi je schopnych urobit viac v Gimpe ako ty vo windowsackom malovani.

S tímhle tvrzením právě nesouhlasím. Já si myslím, že GIMP je takový větší FFF (family, friends, fools) bysnys a spousta lidí po něm sáhnou jen proto, že se jim nechce / nemohou krást Photoshop.

529
Software / Re: Proč firmy používají proprietární sw?
« kdy: 27. 04. 2011, 15:49:15 »
Vzhladom na to, ze plno ludi Gimp pouziva aj na pracu a chvali si ho a vzhladom na to, ze Gimp je tu uz peknych niekolko rokov a doteraz neumrel kvoli slabej uzivatelskej zakladni, tak si dovolim tvrdit, ze ten pocit nutnosti vrazdit nevychadza z neschopnosti Gimpu, ale z neschopnosti Ondreja Novaka :)

No je to dost silné tvrzení, považovat zrovna Gimp za etalon neschopnosti pro člověka, který je schopen udělat víc věcí ve Windowsovském malovaní než v Gimp ... a na druhou stranu třeba i ve Photoshopu. Mimochodem, třeba Open Source Xara XL je mnohem lepší soft na tvorbu grafiky, pravda, nehodí se na odstraňování červených očí z domácích fotografií.

530
Software / Re: Proč firmy používají proprietární sw?
« kdy: 27. 04. 2011, 14:39:13 »
Jo GIMP je krásná ukázka OSS alternativy k Photoshopu. Používá každý zoufalec, který si nechce Photoshop ukrást

Nebo kterému prostě stačí. On Gimp toho umí docela dost a když mi stačí (třeba i pro firemní účely) není jediný důvod vydávat nekřesťanské peníze za Photoshop, leda že bych nevěděl co s nimi :)

A pracuje se vám s gimpem dobře? Já ho mám, jako jediný editor obrázků. A občas bych vraždil!

531
O serveru Root.cz / Re: Editace příspěvků v diskuzi
« kdy: 27. 04. 2011, 14:34:37 »
Co takhle dát možnost upravit poslední odeslaný příspěvek, pakliže na něj neexistuje odpověď? Vždyť detekovat novou odpověď v diskuzi umíte ne?

532
Software / Re: Proč firmy používají proprietární sw?
« kdy: 27. 04. 2011, 09:55:31 »
Co mi poslední dobou často padá (tiše bez hlášky) na paměť, je gimp (ano, jsem si vědom toho, že jsem na něj ošklivý, když chci po něm editovat netriviální obrázky s více vrstvami a chci mít dostatečný počet undo operací...) a těm XP samotným to nijak nevadí (prostě jej pustím znova a pokračuju od posledního uložení... Dá se na to zvyknout.)

Zkuste nějak zjistit, jaký exit status to vrací. Pokud to vrací C0000417 (-1073740777), pak je to ochycená chyba Buffer Overrun, a takto Windows Vista/7 reagují na tento druh chyby. S nakopnutým zásobníkem totiž nemůžete udělat nic, je to bezpečnostní opatření. XPčka takovou ochranu neměly.

Jo GIMP je krásná ukázka OSS alternativy k Photoshopu. Používá každý zoufalec, který si nechce Photoshop ukrást

533
Software / Re: Proč firmy používají proprietární sw?
« kdy: 27. 04. 2011, 09:07:36 »
Jen Vás doplním. Pokud jste narážel na "slavný" OOM Killer, tak jej Linuxové jádro používá jako poslední zoufalý pokus uvolnit nějakou paměť, aby nedošlo k zastavení systému a
Já vím, já ho znám. Pokud vypnu swap, pak je to velmi často věc, která mi zabíjí procesy. Problém je to s overcommitem, kdy proces dostane slíbenou paměť, ale při lámání chleba už kolikrát nestihne dokončit svou práci a OOM Killer ho zabije v nekonzistentním stavu. Skvělá featura!

Windows co já vím, když došlo na lámání chleba  - minimálně do XPéček, spolehlivě vytuhly

Jo, a kolíkrát jste ty XPčka použil? Pokužívám Win2000,XP,Vista,W7 v různých virtuálech v různých až sparťanských podmínkách a nikdy jsem nenarazil na to co popisujete. V jedné verzi VMWARE byla chyba v diskovém ovladači, který vytuhl když dostal hodně práce. Na tom samozřejmě vytuhl celý OS při čekání na odswapování paměti. Oni to ty windowsy nakonec vyřešili modrou smrtí asi po čtvrt hodině čekání. Pokud se  Vám to stávalo taky, hledal bych chybu v ovladačích. Zvlášť, pokud máte HW made in china, kompletní dodávku včetně software.

534
Software / Re: Proč firmy používají proprietární sw?
« kdy: 26. 04. 2011, 23:45:16 »
Jakoukoliv. Ve Windows často pád jedné aplikace vzal sebou celé Windows, u Linuxu stačí odstřelit jeden proces. Postupem času se to zlepšovalo, poslední Windows, se kterými jsem pracoval byly Visty a ano, byly mnohem lepší než třeba W98SE. Ale přesto po přechodu na Linux (byť je to Kubuntu) to byl znatelný rozdíl. Mluvím zejména o vývoji software a práci s dynamickou pamětí. Pokud uděláte chybu a při testování se chyba projeví, pak má stejná situace prokazatelně horší důsledky pod Windows.

Dynamické paměti, to myslíte DRAM? Jak to s tím souvisí? Nebo Vás doteď překvapuje, že to co Windows řeší swapováním, to Linux řeší zabitím? Dost výborný nástroj na řešení paměťových špiček. Zkuste si v Kubuntu zapnout swap a udělejte stejnou chybu. Nepřihlásíte se ani sshčkem  ;) a na ping vám to odpoví za několik sekund.

Prosím, nechte to být.

535
Software / Re: OSS vs. proprietární
« kdy: 26. 04. 2011, 23:18:44 »
Tyhle lidi stejně neocení lepší správu procesů a lepší filesystém, když obvykle ani nevědí, co to

V kterým unixu je lepší správa procesů? Kterou distribuci si mám nainstalovat?

536
Software / Re: Proč firmy používají proprietární sw?
« kdy: 26. 04. 2011, 23:09:39 »
Zkuste si odpovědět na otázku, proč by firma měla používat software který je někde na úrovni mezi čínskou kopií a neustále nedokončenou betaverzí.  ;D

Upřímě, pokud jde o OSS, které není primárně vyvíjeno za peníze, pak je to děs a hrůza. Pokud jde o OSS vyvýjené jen tak bokem k většímu projektu, který je za velké peníze, pak člověk musí očekávat jednostranné zaměření a nulový rozvoj jiným směrem. Pokud jde o OSS, jehož vývoj je financováno nějakým velkým mecenášem, pak za nedlouho skončí, přejde na proprietální větev, nebo vymyslí nějaký odlišný obchodí model, kde software sice bude zdarma ale bez další podpory za peníze bude k ničemu.

Já vím, že OSS neznamená zdarma, ale pokud je ve zdrojovém kódu zakomponované i jiste know-how, pak to jako OSS prostě prodávat nelze, dál se to bude šířit zdarma. Co se OSS vázané na HW týče, tam to fungovat může, protože se vývoj toho softu zaplatí cenou HW, a bez HW je ten soft k ničemu. Proto třeba může fungovat vývojový SW pro Arduino, protože adaptace jiného HW na tento soft má znatelné náklady, a běžný uživatel si stejně koupí celý kit i se softwarem, takže to vývoj zaplatí.

537
Vývoj / Re: Uzavření descriptorů po forku
« kdy: 26. 04. 2011, 16:44:32 »
Navíc to stále neřeší případy, kdy proces obsahuje deskriptor(y), které uživatel explicitně neotevřel. Takže stejně se o jejich uzavření (pokud je chce uzavřít) musí postarat sám. Tak kde je ta výhoda std::fstream?

Ano, to je ten průser o kterém mluvím. Programátor se musí starat o věci, nad kterými nemá absolutní (nebo spíš žádnou) kontrolu. Musí být připraven na situace, o kterých nemá ani potuchy.

Opakuji. Nejde o chybu knihoven třetích stran. Knihovna nemá a nemůže mít nejmenší tušení, že vy děláte poměrně radikální manipulaci s procesem (fork, execve).
Netušil jsem, že spuštění cizího procesu je radikální manipulace s procesem. Existuje nějaká neradikální cesta? Něco jako CreateProcess ve Windows?

Jde o chybu vaší knihovny, že se nechová ke zdrojům procesu konzistentně a tudíž korektně (část deskriptorů zavíráte a část ne).
Nezavírá žádné, jen ty svoje označuje flagem O_CLOEXEC. Chci budoucímu uživateli mé knihovny dát jistotu, že si knihovna nevytvoří žádný prostředek, který by přežil exec aniž by o tom programátor věděl.

Vy vytváříte proces, vy jste zodpovědný za vyřešení problémů, kterou jsou s tím spojené. A to navíc tak, aby to práci uživateli ušetřilo.

Ale houby, za problémy spojené s vytvářením nového procesu je zodpovědný operačný systém. Ten ale doposud problémy spíš vytváří.

V tuto chvíli není jediný důvod, aby používal vaši fstream. Ani jeden důvod. O obsluhu ostatních deskriptorů se musí postarat tak, jako tak, takže k čemu by si měl komplikovat život?

Asi proto, že mé streamy nejsou určeny k vytváření procesů, ale k něčemu úplně jinému a tohle jen tak bokem. Ano, s jednou z možností je vytvořit process a k němu můj stream, který se dá plnit daty stejně jako varianta pipe, fork, exec, ale bez zbytečných close (pipe je také O_CLOEXEC, pouze po forku se descriptory zduplikují do descriptorů 0,1,2 které jediný přežijí.

Tohle (v)fork API tu je přes 30 let. Ukažte mi ten průser v praxi.
Hurá, po třiceti letech jsme přišli na průser v Unixu. Budeme dalších 30 let dělat, že neexistuje? Tenhle váš závěr je likvidační.

A příklad toho průseru? OpenSSH

V diskuzi je už zbytečné dál pokračovat. Díky za ujasnění problému.

538
Vývoj / Re: Uzavření descriptorů po forku
« kdy: 26. 04. 2011, 02:22:56 »
Princip neutrality říká, že to se knihovny netýká, to by neměla řešit, a zavírání všech deskriptorů při spuštění procesu tak trochu princip neutrality narušuje.
Mohl byste mi přiblížit obsah principu neutrality?


Laicky řečeno, nepletu se do věcí, do kterých mi nic není. Zavřením všech deskriptorů při spuštění jiného procesu bych zasáhl do obvyklých zvyklostí programů třetích stran, které třeba mají důvod, proč mají sdílení zapnuté. Nechci prostě opravovat "průser" unixového API, chovám se k němu neutrálně.

Jinak můj názor je, že právě takové použití vaší knihovny ten problém vytváří a nejedná se o problém cizích knihoven. Váš požadavek na otevírání souboru pouze přes vaše API není právě "standardní".
To jste nepochopil. Už v okamžiku, kdy uživatel místo open použije std::fstream je tedy nestandardní chování? (mimochodem, jaké flagy nastavuje STL na své deskriptory???) Požadavek na použití mého API má samozřejmě několik podmínek. Jednak by mělo zjednodušit práci programátora víc, než přímou práci s open/std::fstream a jednak by mělo být multiplatformní, tj, ovládat se stejně minimálně pod oběma mainstreamovýma platformama (windows/linux). Pouze definuju styčné body, kde je třeba občas přecházet mezi mým API a třeba API knihovny třetí strany, například, pokud knihovna vyžaduje FD pro další práci a já mám soubor otevřen v mém objektu představující soubor.

Nicméně smyslem bylo vysvětlit právě ten princip neutrality. Místa, kde dochází k přístupu do mého API se uplatňují jeho (moje) pravidla tak, aby všechny objekty spravované tím API se chovaly konzistentně, tedy, aby deskriptor, který adaptuje moje API byo nesdílený, dokud si uživatel o sdílení explicitně nepožádá. Deskriptory, které si vytvoří knihovna třetí strany v rámci své práce a nevstupují do mého API mi jsou naprosto volné. Není moje zodpovědnost žehlit chyby v knihovnách třetích stran a pokud knihovna interně vytváří deskriptory, které se by default sdílí, je to problém knihovny a programátora, který tu knihovnu používá. Má knihovna neumí rozhodnout, zda je to záměr, nebo chyba.


Citace
Citace
Navíc to zjednodušuje opt-in. Mohu určit, které deskriptory se budou sdílet a nechat si vygenerovat fake-filename takového deskriptoru. To pak předat na příkazové řádce child procesu, který... pokud je napsán v mé knihovně... může soubor otevřít standardním postupem. Tohle mi totiž bude fungovat i pod Windows (Pomocí DuplicateHandle se zapnutým sdílením).
To, že vám jako autorovi takové knihovny, něco zjednodušuje implementaci knihovny není tak podstatné jako to, že by knihovna měla zjednodušovat práci uživateli takové knihovny.
Myslím si, že to zjednoduší práci i uživatelům. Jak pošlete child aplikaci 5 vstupních a 7 výstupních streamů? Já si je předám na příkazové řádce :-)
Citace
Já bych volil ten sysctl, sysconf, nebo getrlimit. Ale to API bych pořádně promyslel.

Mě to přijde jako hackoidní řešení. Chápu to u sshčka, i když tam se taky bere jen prvních  64 deskriptorů, pak se člověk ptá, zda to vůbec má smysl.

Průser unixu je zde o tom, že deskriptory se duplikují do cizích procesů a ještě větší průser je, že se duplikují dál do jejich child procesů bez kontroly, protože process, který dál forkuje a provádí exec se vůbec o existenci těchto deskriptorů nemusí dozvědět. Protunelovat se takto do zabezpečené seance tak není žádný problém.

Neutrální postoj je ten, že si to zabezpečím u sebe a nebudu ten průser řešit nějakým hackem a zadělávat si na další průser.

539
Vývoj / Re: Uzavření descriptorů po forku
« kdy: 25. 04. 2011, 21:37:25 »
Tohle bych nedoporučoval. Co s deskriptory, které bude otevírat cizí knihovna? Co s deskriptory, které jsou otevřené již při spuštění procesu? Co s další teoretickou knihovnou, která bych chtěla dělat totéž tj. vynucovat otevírání souborů přes své API? Navíc nemůžete řešit jen soubory ale všechny typy objektů.

Jde v zásadě o tyto prostředky. Soubory, roury, sockety, obecně cokoliv, co se dá číst nebo zapisovat jako stream. Různé pseudodeskriptory jako eventfs, signalfd neuvažuju. Princip neutrality říká, že to se knihovny netýká, to by neměla řešit, a zavírání všech deskriptorů při spuštění procesu tak trochu princip neutrality narušuje. Takže po zvážení všech komplikací, včetně výše uvedených problémů se zavíráním deskriptorů naslepo jsem se rozhodl to řešit touto cestou.

Jinak co jde o knihovny třetích stran, není na mě, abych řešil problémy cizích knihoven, spíš abych já sám je nevytvářel. Považuji tedy používání O_CLOEXEC skoro za povinnost. Má knihovna má samozřejmě schopnost "otevřít soubor z FD", takže pokud někdo chce používat mé knihovny s knihovnou třetích stran, může použít tuto funkcionalitu (je tam i možnost převést stream z mé knihovny na FD). Nicméně i tady budu nastavovat FD_CLOEXEC, tak, aby se deskriptory adaptované knihovnou chovaly konsistentně.

Navíc to zjednodušuje opt-in. Mohu určit, které deskriptory se budou sdílet a nechat si vygenerovat fake-filename takového deskriptoru. To pak předat na příkazové řádce child procesu, který... pokud je napsán v mé knihovně... může soubor otevřít standardním postupem. Tohle mi totiž bude fungovat i pod Windows (Pomocí DuplicateHandle se zapnutým sdílením).

Předpokládám, že se to týká i socketů.

Citace
:-) No to tak jako tak zavádíte. Buďto zavádíte API z win do lin nebo obráceně.

opt-in z Windows mi přijde lepší, proto převeznu formu API z win. Ale v jiných místech mám zase API dle linuxu  (například dvojice mutex-con.variable ve Windows citelně chybí, dá se emulovat)

540
Vývoj / Re: Uzavření descriptorů po forku
« kdy: 25. 04. 2011, 09:44:42 »
Pokud píšeš knihovnu, která zajišťuje spouštění procesů, tak uživatel by měl vědět, že před voláním tvého API má uzavřít _potřebné_ deskriptory resp. uklidit po sobě. Příp. bys měl API rozšířit tak, aby si z tvé knihovny volal uživatelovy "úklidové funkce" (callbacky).

No já se to snažím napsat portabilní aspoň mezi linuxem a windowsem. No a ten styl práce je trochu jiný, na Windows totiž nemusím uzavírat deskriptory, takže mi přijde divné zavádět pravidla, která platí jen na jedné platformě. Na Windows mohu otevřít deskriptory tak, aby se sdílely, ale musím to explicitně uvést. Opt-in mi tedy přijde lepší, než opt-out.

Opravdu nechci, aby uživatel řešil při spouštění procesu, které kde má pootevírané soubory, k čemu pak taková knihovna je? Ideální stav je přitom tento:

Kód: [Vybrat]
Process p("/bin/bash -c ls");
p.start();
p.join();

případně

Kód: [Vybrat]
Process p1("/bin/bash -c ls"),p2("/usr/bin/sort");
p1 | p2;
p1.start();p2.start();
p1.join();p2.join();

Kde je prostor pro nějaké callbacky?

Spíš mě napadlo lepší řešení. Protože bych chtěl dosáhnout toho, aby uživatel mé knihovny otevíral soubory také pomocí mé knihovny, dám všude tam, kde se otevírají nějaké deskriptory automaticky O_CLOEXEC a zavedu API pro sdílení deskriptorů. Fakt je to lepší, protože tím odpadají i takové zbytečné problémy, jako že někdo v jednom vláknu otevře soubor a než mu stačí udělat opt-out ze sdílení, jiné vlákno udělá fork(). Ale je to takový nejistý... zbytek bude řešeno v guidelines.

Stran: 1 ... 34 35 [36] 37 38