abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 00:33 | Zajímavý článek

Správce nástroje curl Daniel Stenberg na GitHubu průběžně vytváří svou novou knihu Uncurled, v níž shrnuje své dlouhodobé zkušenosti s údržbou open-source projektu: od odpozorovaných pouček po vtipné a ne až tak vtipné příklady e-mailů od uživatelů.

Fluttershy, yay! | Komentářů: 0
dnes 00:22 | Nová verze

Byla vydána nová major verze 25.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 1
dnes 00:11 | Nová verze

Deno (Wikipedie), běhové prostředí (runtime) pro JavaScript a TypeScript, bylo vydáno ve verzi 1.22. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 18:22 | Nová verze

Společnost Red Hat oznámila vydání Red Hat Enterprise Linuxu (RHEL) 9.0. Vedle nových vlastností a oprav chyb přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 6
včera 14:00 | Komunita

Lars Knoll oznámil, že po 25 letech v ekosystému Qt, z toho 22 let pracující pro různé společnosti vlastnící Qt, odchází ze společnosti The Qt Company do malého norského startupu.

Ladislav Hagara | Komentářů: 2
včera 13:22 | Zajímavý projekt

Na Kickstarteru běží kampaň na podporu mini ITX desky Turing Pi 2 Cluster Computer. Vložením 4 výpočetních modulů, podporovány jsou Raspberry Pi 4, Turing RK1 a Nvidia Jetson, lze získat 4uzlový cluster. Cena desky je 219 dolarů.

Ladislav Hagara | Komentářů: 2
včera 10:00 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 198. brněnský sraz, který proběhne v pátek 20. května tradičně od 18 hodin v Pivovarské restauraci Moravia.

Ladislav Hagara | Komentářů: 2
včera 07:00 | Zajímavý software

Byla vydána nová verze 0.25 herního enginu Fyrox, původně rg3d. Přehled novinek s kódy, náhledy i videi v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
včera 00:11 | Nová verze

Multiplatformní audio přehrávač Qmmp (Wikipedie) byl vydán ve verzi 2.1.0. Z novinek lze zmínit například podporu XDG Base Directory Specification.

Ladislav Hagara | Komentářů: 0
17.5. 23:22 | Komunita

Letošní konference LibreOffice proběhne 28. září až 1. října v Bolzanu. The Document Foundation hledá přednášející.

Zdeněk Crhonek | Komentářů: 0
Na sociálních sítích nebo jiných webových diskuzích vystupuji pod
 (60%)
 (16%)
 (24%)
Celkem 276 hlasů
 Komentářů: 23, poslední včera 16:14
Rozcestník
Štítky: není přiřazen žádný štítek



Vložit další komentář
10.12.2021 23:38 debian+ | skóre: 30 | blog: analyzy
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Ja si myslím, že podla AGPL musí byt byt zverejnení kód (stačilo by iba cez intranet? ;) aj zamestnancovi. Zmluva hovori jednoznačne (nečítal som ju) cez sieť. Ak by sme to zignorovali, tak sme viac menej zrušili OEM a EULA licencie.
debian.plus@protonmail.com
12.12.2021 15:35 johnyK | skóre: 1 | blog: uxblog
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Zmluva hovori jednoznačne (nečítal som ju) cez sieť.
ano, takhle to vidi nekteri a ja jsem zaregistroval nejvetsi cirkus kolem te AGPL u produktu 'iText' (itextpdf.com). Ten byl (a je) casto pouzivan a pote co zmenili licenci na AGPL, tak se rada lidi ptala dokonce toho supportu od iText , jestli to mohou ve vlastni firme u vlastniho software pouzivat (to je ten internal use) a iText vicemene tenkrat odpovidal v tom smyslu, ze je treba to vlastni software uzivatelum kompletne zpristupnit a dodnes na webovych strankach salamounsky tvrdi, ze iText se da pouzit jen v 'AGPL-prostredi'. (It’s a legal violation to use iText Community and our open source add-ons in a non-AGPL environment.)

Pricemz u vsech tech svobodnych licenci stoji na zacatku vzdycky, ze pouzivat to muze kazdy jak chce, jenom u toho sireni je svazan nejakymi povinostmi. Ja to reknu primo - je to jen muj nazor - ale ja mam dojem, ze ti , kteri zvolili AGPL licenci pro vlastni produkt tak trochu kalkuluji s tim, ze uzivatel je, co se pouzivani tyce v nejistote a tlaci ho tak neprimo ke koupi komercni licence. Je to samozrejme legalni, nikdo nenuti nekoho pouzivat produkt s AGPL licenci ale , hmm ...

zrušili OEM a EULA licencie
to si myslim je ted nespravny argument. EULA a podobna licencni ujednani jsou jasne orientovana na 'pouzivani' - jedno jestli doma, ve firme, na Mesici, kdekoliv. I v te EULa jsou ruzne varianty jako ze pouzivani v praci opravnuje i pouziovani kopie software na domacim pocitaci a tisice ruznych vyjimek a pod. Ale vzdy jde o pouziti. Tedy tak to vidim.
11.12.2021 00:17 Want
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Pro mne to není nijak překvapivé. Za vývojem software jsou ve skutečnosti pouhé stovky lidí. Žádné tisíce nebo miliony, jak by si někdo naivně myslel. To je důvod, proč mám k těmto lidem hlubokou úctu, respekt a pokoru, pokud uvolnili výsledek svého snažení jako open source.
12.12.2021 23:20 zzz
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Za vývojem software jsou ve skutečnosti pouhé stovky lidí.
Co je tim presne mysleno? Podle jiste studie je na zemi zhruba 27 milionu profesionalnich vyvojaru.

Nebo myslis OSS vyvojare? Tech je prokazatelne taky daleko vic (staci se podivat na github).
13.12.2021 10:58 plostenka
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Miliony lidi pisi nejaky kod ktery v mnoha iteracich dela to same dokola (veskera webarina, telefonni aplikace, Doom 16,...).

Stovky lidi, mozna mensi tisice, tedy skutecni vyvojari, pisi kod ktery posunuje schopnosti HW a efektivitu lidi jako celku (jadro linuxu, db enginy, zpracovani dat z CERNu,...).
13.12.2021 11:46 zzz
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
I tak jsou to uplne jine rady. Vem si kolik je ruznych kernelu pro ruzne pouziti, kolik ruznych databazovych enginu (relacni, dokumentove, sloupcove, grafove), ruzne compilery a nove jazyky, kolik lidi pracuje na novych aplikacich machine learning, computer vision, speech recognition, quantum computing, kryptografie a cybersecurity, robotika, bioinformatika, simulace fyziky/chemie, milion veci okolo siti, cloud a kontejnerizace, distribuovane/paralelni zpracovani dat, supercomputing, zpracovani obrazu/zvuku, formalni metody, veskery vyvoj okolo hardware (ovladace), atd. atd.

Samotnych podoboru je nejspis stovky (mozna tisice), je naprosto naivni si myslet, ze tohle vsechno resi jen par tisic lidi.
13.12.2021 18:04 plostenka
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Prave. Ruzne jayky maji ruznou syntax, ale resi porat to same - od vynalezu rekneme C (nebo FORTRANu podle vkusu kazdeho pametnika) se vlastne nic nezmenilo, jen se pridava syntakticky cukr podle nalady. DB to same, od vynalezu relacni DB je to opet to same dokolecka, jen s jinym API. Nova myslenka bylo treba SVN, Git to dotahl. Nova myslenka byl multiuzivatelsky OS/360, Linux to dotahl. Nova myslenka byl ARPANET, dnesni Internet to dotahl. Nova myslenka bylo GSM, dnesni G5 je jen vylepseni. Nekdo vyvinul prvni neuronky, to byl taky vyvojar. A tak...

Tech lidi kteri skutecne pracuji na vecech ktere ovlivni civilizaci na dalsi desitky let je strasne malo. Lidi kteri s temi vecmi delaji zajimave veci je vic. No a bastlicu okolo jsou desitky milionu.
Heron avatar 13.12.2021 18:38 Heron | skóre: 53 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Souhlas.
jen se pridava syntakticky cukr podle nalady
Jenže tohle je zrovna dost důležité. Je potřeba transformovat myšlenku z lidského mozku do podoby strojáku. A každý člověk vnímá jazyk jinak, a pro počítač je potřeba to jinak překládat. Takže ano, všechny turingovsky úplné jazyky mají stejnou sílu, ale někomu se lépe píše v C, někomu v Java Scriptu a někomu v Golangu. Kdyby to tak nebylo, tak můžeme rovnou psát jedničky a nuly a žádné jazyky nejsou potřeba.

K dalšímu impulsu dopředu je potřeba nějaký metapohled na celou problematiku. Něco, co se stalo ve fyzice. O spoustě fyzikálních veličin se vědělo, že jsou nějak speciální ale nevědělo se proč. Potom přišla Noether, zjistila vztah mezi zákony zachování a symetriemi a náhle se na to šlo zcela opačně. Symetrie generují zákony zachování a příslušné veličiny a ne naopak. Celou moderní fyziku (nebo alespoň kvantovou teorii pole) lze vybudovat na zelené louce jen výběrem symetrií, které chceme. (Obecně lze vybudovat cokoliv, ale pokud to má být fyzika spojená s realitou, tak je dobrý si vybrat jen ty v přírodě realizované.)

Nevím, jestli je něco takového možné v IT. Obecně by chtělo najít definici prostoru, najít v něm umístění a definici všech stávajících IT objevů a potom to zkusit zobecnit. (Třídy algoritmů a tak.) Tj. najít generátor (celého) prostoru možných stavů. Otázkou je, jestli by to vůbec k něčemu bylo, např. sortovacích algoritmů může existovat nekonečně mnoho, ale jak (automaticky) vybrat ty nejlepší a jestli to není zbytečná práce.
Heron avatar 13.12.2021 18:53 Heron | skóre: 53 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Resp. (aby mě opět někdo netahal za slovo) grupy symetrií a kvantová teorie pole je jenom framework, od kterého chceme splnit tyhle grupy a další věci (třeba je dobrý mít částice hmoty). Symetrie potom vygeneruje pole a příslušné intermediální částice.

Je úplně super, že jsme našli stroj na kostky lega, akorát ty energie jsou trochu mimo dosah. Už jsou vlhké sny o 100TeV urychlovači ale někteří fyzici jsou skeptičtí, jestli se v tomto okně (14TeV-100TeV) vůbec něco najde, protože některý předpovědi potenciálu vycházejí trochu mimo rozsah možností. Ale určitě by se to mělo zkusit.

V IT by to snad tak náročné být nemuselo. (To se mi to kecá, když o tom nic nevím. :-D)
14.12.2021 08:44 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Informatika prodělala intenzivní teoretický vývoj mezi 30. a 70. lety 20. století. Rozlišil se problém ­– algoritmus – implementace, výpočetní modely podle schopností (gramatiky apod.), algoritmy podle obtížnosti (rozhodnutelnost, vyčíslitelnost, třídy složitosti), teoretizovali se komunikační sítě (jakýkoliv protokol lze redukovat na problém synchronizace, který nikdy nezaručí spolehlivost), na informaci se aplikovala teorie entropie (problém ekvivalence energie a informace). V podstatě po Gödelově principu neurčitosti jsme prohloubili skepsi důkazem nerozhodnutelnosti problému zastavení (což znamená, že automaticky nelze vybrat nejlepší sortovací algoritmus) a důkazem příslušnosti charakteristických problémů určité třídě složitosti (např. že s deterministickými stroji problém obchodního cestujícího nevyřešíš lépe než v exponenciálním čase). Výsledkem je, že jestli implementuješ Dijkstrův algoritmus pro hledání nejkratší cesty sítí v céčku nebo Haskellu, je v podstatě jedno. Každá implementace má stejná nepřekročitelná omezení a schopnosti. Ano, zůstává pár nevyřešených problémů na pomezí matematiky a informatiky, ale ty tu máme už 50 let bez viditelného pokroku. A pak tu máme problémy, kterou jsou teoreticky vyřešené, ale nemáme počítače, které by je upočítaly. V podstatě se čeká na kvantové počítače. Jenže ty mají zase svá fyzikální omezení. Takže jediný pokrok, který si můžeme právě užívat třeba na poli kryptografie je přechod k eliptickým křivkám. O kryptomeněnách, jejíchž efektivita s množstvím transakcí klesá kvůli vazbě na spotřebovanou energii a prostor, darmo mluvit.
14.12.2021 11:48 johnyK | skóre: 1 | blog: uxblog
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
ja se jednoduse priznam, ze tomu co napsal Heron a ty proste nerozumim. Ale kdyz kolega Heron pise:
Obecně by chtělo najít definici prostoru, najít v něm umístění a definici všech stávajících IT objevů a potom to zkusit zobecnit.
tak si rikam, ze by na tu problematiku inovaci v software sel 'nejak vedecky' -> jak je holt asi zvykly z toho oboru ktery studoval.

Me skutecne prekvapuje, ze se nekonaji snahy to software uchopit spise z te inzenyrske strany, tak nejak prakticteji. Tzn. spise vyzkumy ohledne modularity, vicepouzitelnosti. V soucasnosti se spise hledi na tu stranku prvotniho zhotovovani toho software, na ty agilni metody a vubec nejak vylepsit tu stranku na strane project-managementu. (kdyz se budou mit ti lide v tomm projektu vzajemne radi, tak bude to software lepsi :-) )
Heron avatar 14.12.2021 14:41 Heron | skóre: 53 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
tak si rikam, ze by na tu problematiku inovaci v software sel 'nejak vedecky' -> jak je holt asi zvykly z toho oboru ktery studoval.
Pointou mělo být (a asi jsem to trochu přehnal s tou analogií, sorry), že se na věci dá dívat i trochu z dálky.

Nedávno jsem viděl video, kde borec vysvětluje úpravy obrázků pomocí matic. Jasně, obrázek je matice, hodnoty jsou v jednoduchém případě (monochromatický obrázek) hodnoty 0-255 (nebo 0.0-1.0). Technickej přístup (můj) je mít dva for cykly, řádek, sloupec a s těmi pixely něco udělat (přičíst hodnotu a tím to zesvětlit apod.). Chápeme se.

Borec (asi matematik) si řekl, hmm, máme matici, tak co všechno umíme s maticemi dělat? Jasně, afinní transformace jsou jedna věc, ale co dál? No a potom to rozvíjel čistě na maticových operacích. Na počátku jsou pixely, na konci jsou možná taky pixely, ale to uprostřed je prostě maticový počet. Naprosto obecný. A tohle je prostě jinej pohled na rastrový obrázek.

No a ve fyzice se jiným pohledem z dálky přišlo na to, že ty konkrétní veličiny mají svůj hodně hluboký původ a ten je úplně jiný, než by kdokoliv před tím hádal. A že těch veličin je daleko víc a některý jsou moc fajn (třeba spin - až se v IT přestane používat elektrický náboj (0 - malý náboj, 1 - velký náboj - takto fungujou ramky) a začne se používat spin, tak to bude teprve revoluce - spin (elektronu) má dvě hodnoty, takže jeden elektron už by mohl nést informaci o jednom bitu - takto snadný to nikdy nebude, ale na spoustě místech by se spin mohl použít jako dočasné skladiště informace).

A tak mě napadlo, jestli lze tohle udělat i pro computer science. Prostě se na to podívat z dálky a jinak. Vůbec nevím, tímhle se afaik možná zabývá Bystroušák a je to úplně mimo můj obor. (Já jsem admin serverů a amatérskej programátor, o teoretické informatice nevím vůbec nic.)
Me skutecne prekvapuje, ze se nekonaji snahy to software uchopit spise z te inzenyrske strany, tak nejak prakticteji.

Nekonají? Furt sleduju konference o tom, jak správně rozdělit projekt, jak navrhovat knihovny apod. Když se podívám na linux, tak se změnil koncept a místo dřívějších monolitických řešení (třeba těžkotonážní apache s modulama) se používá více rozmělněné (nginx a před proxy pass volat vše, co je potřeba - malé jednoduché services, které jsou snadné na nastavení). A tohle je tak nějak všude. My používáme těžkotonážní PostgreSQL, ale mezitím je tu hafo jednodušších db (z hlediska toho, co umí) a stačí to taky.
V soucasnosti se spise hledi na tu stranku prvotniho zhotovovani toho software, na ty agilni metody a vubec nejak vylepsit tu stranku na strane project-managementu.
Asi jak kde. Spoustu projektů je nutné rozvíjet a roku udržovat. Motám se teď kolem sw projektu, který sahá až do roku 1993. A jak píše Pavel, těch koulí na noze je tam už opravdu hodně. Ale říznout do toho bude náročný. Takže se dělá refaktoring a vylepšuje se to postupně. Což ale prostě trvá roky.
kdyz se budou mit ti lide v tomm projektu vzajemne radi, tak bude to software lepsi
Jo, a když se potom dohádaj, tak si tam vzájemně nastrkají odjištěné granáty. :-D

Bystroushaak avatar 14.12.2021 17:00 Bystroushaak | skóre: 36 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
No a ve fyzice se jiným pohledem z dálky přišlo na to, že ty konkrétní veličiny mají svůj hodně hluboký původ a ten je úplně jiný, než by kdokoliv před tím hádal. A že těch veličin je daleko víc a některý jsou moc fajn (třeba spin - až se v IT přestane používat elektrický náboj (0 - malý náboj, 1 - velký náboj - takto fungujou ramky) a začne se používat spin, tak to bude teprve revoluce - spin (elektronu) má dvě hodnoty, takže jeden elektron už by mohl nést informaci o jednom bitu - takto snadný to nikdy nebude, ale na spoustě místech by se spin mohl použít jako dočasné skladiště informace).
Jmenuje se to Spintronika (anglicky).
A tak mě napadlo, jestli lze tohle udělat i pro computer science. Prostě se na to podívat z dálky a jinak. Vůbec nevím, tímhle se afaik možná zabývá Bystroušák a je to úplně mimo můj obor.
Já se zabývám nějakou podmnožinou tohohle, a ne teda computer science, ale spíš praktického IT co se týče software, ukládání dat, práce s nimi a user-interface. Většina z toho spočívá v designu (nebavím se o grafice, ale o human interface). V podstatě se vším v IT na nějaké úrovni dřív nebo později pracují lidé, a když se podíváš na věci z uhlu pohledu, kdy vystoupíš ze současného kontextu (umím to a používám to, tak je to samozřejmé a dobré), tak vidíš jak všechno saje a vlastně za většinou prakticky používaných věcí a paradigmat není žádné informované rozhodnutí, ale náhoda a chaos.
14.12.2021 21:31 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.

To „vědecké zobecnění“ se už stalo. Nad třídou Turingových strojů jsou teoreticky postulované další třídy výpočetních modelů, které mají mnohem silnější výpočetní schopnosti a třeba problém obchodního cestujícího je pro ně čistě polynomiální problém. Problém, je že tato zobecnění (prozatím) „nemají fyzikální význam“. Jsou to hypotetické konstrukce, ve stylu mějme nedeterministický stroj, který v konstantním čase uhádne řešení a v polynomiálním čase deterministicky ověří, že se trefil. Takovým nedeterministickým strojem by mohl být kvantový počítač (bohužel jen na omezenou množinu problémů a hlavně na velikost stavového prostoru), ze kterého standardní deterministický počítač odečte řešení a ověří jej. Další třídy jsou ještě šílenější a vztah k realitě je ještě mizivější.

Ale si to není to pravé fyzikální zobecnění, co chtěl Heron. Ve fyzice se staré zákonitosti často ukážou aproximací speciálního případu mnohem větší zákonitosti. Takže v podstatě nový objev je schopen nahradit ten starý. V informatice to ale tak není. Tam staré objevy zůstávají v plné platnosti a nové jsou ve stylu „tento problém lze redukovat na již jiný známý, takže má stejné řešení“ nebo „řešení tohoto problému jsme do teď neznali, a teď víme, že řešení nalézt ani nelze“. Právě to je příčinou té skepse, o které jsem psal. Zatímco ve fyzice postupně víme více a více, tak v informatice spíše postupně zjišťujeme, co všechno nikdy nepoznáme.

Bystroushaak avatar 15.12.2021 05:21 Bystroushaak | skóre: 36 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Zatímco ve fyzice postupně víme více a více, tak v informatice spíše postupně zjišťujeme, co všechno nikdy nepoznáme.
Tak to je obecně problém matematiky už někdy od Gödela. Machine learning v tomhle dělá trochu progress, protože sice pořád nejsme schopni řešit obecně třeba třídu problémů, ale jsme schopni najít nějaká specifická dostatečně dobrá řešení / heuristiky, co fungují.
Heron avatar 14.12.2021 12:11 Heron | skóre: 53 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
V podstatě po Gödelově principu neurčitosti jsme prohloubili skepsi důkazem nerozhodnutelnosti problému zastavení
Zeptám se jako idiot. Je tohle fakt problém? Jako ano, obecně je nerozhodnutelné, zda nějaký obecný alg. skončí nebo ne. Jasně. Ale nejde vybrat pouze ty alg. které jsou dokázané a na nich to postavit? Mám pocit, že MS vyvíjel OS, kterej je komplet dokazatelný. (Singularity)
např. že s deterministickými stroji problém obchodního cestujícího nevyřešíš lépe než v exponenciálním čase
Jasný, ale můžu mít (a mám) jiný alg. který to sice neřeší přesně, ale řeší to dost dobře a hlavně rychle. Prostě trochu fuzzy přístup.
V podstatě se čeká na kvantové počítače.
Já bych v tohle byl fakt hodně skeptickej. Kvantový počítače budou (alespoň z počátku) hodně specifický akcelerátory a nepůjde na nich pustit cokoliv. Jasně, možná že lidstvo dokáže osedlat problém superpozice a provázanost a udělat z toho alespoň trochu obecnej počítač, ale zatím tohle světlo na konci tunelu vůbec není vidět. Ale třeba se komplet pletu a půjde to fakt rychle. Tohle je takový drobný pokrok.
Takže jediný pokrok, který si můžeme právě užívat třeba na poli kryptografie je přechod k eliptickým křivkám.
Já mám s nima trochu osobní problém. U RSA je jasně danej problém. Všechny parametry si vygeneruješ sám. U ECC je potřeba vybrat konkrétní křivku. Pro obě strany komunikace stejnou. A tady je prostě problém s důvěrou. Odkud se vzala zrovna tato konkrétní křivka? Nevygeneroval ji náhodou někdo, protože se mu na ní zrovna dobře počítá? Tohle je IMHO dost neřešitelnej problém. Jasně, je to pěkný, je to malý atd, ale červíček pořád hlodá. Proč právě tahle křivka.
14.12.2021 22:24 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.

Problém formální verifikace je, že toho umí velmi málo. Pár aritmetických operací a podmínek. Jakmile jí dáte program, co může alokovat paměť, tak jste skončil, protože alokace paměti znamená změnu velikosti stavového prostoru a to by bylo nutné všechno přepočítat od začátku. A když program může alokace provádět dynamicky (na základě vstupu), tak prostě to je, jako kdyby se vám počet rozměrů prostoru měnil pod rukama. Je to, asi jako když na ose přirozených čísel máte čísel nekonečně mnoho, ale na ose reálných čísel jen v intervalu [0;1] jich je ještě více. Pak na celé reálné ose je to nekonečno ještě nekonečnější. Takže v praxi formálně verifikované programy se nepíší tak, že by někdo napsal program a někdo jiný dokázal, že je ekvivalentní specifikaci (to ani vší obecnosti nelze). Ale dělá se to tak, že se napíše formální specifikace (tedy v podstatě naprogramuje se řešení v nějakém formálním jazyce), a pak se specifikace přeloží překladačem do strojového jazyka. A za předpokladu, že překladač neobsahuje chybu, tak binární program i specifikace jsou považovaný za ekvivalentní. Co se celkem používá, je formální důkaz nekorektnosti programu. (Různé statické analýzy kódu.) Problém ale bývá, že ten důkaz stojí ne neúplném výpočetním modelu (popis chování externích funkcí) a tedy občas hlásí jako chyby stavy, které nikdy nastat nemohou.

Fuzzy přístup je asi nevyhnutelnost. Čím jsou systémy složitější, tím obsahují více chyb, takže na nějakou bezchybnost nebo optimální řešení už se nehraje. Zcela extrémní přístup je umělá inteligence. V nedávném článku na Lupě je zmíněno rozpoznávání lidí na pražském letišti a z uvedených čísel plyne, že na 1 úspěšně poznaného člověka připadá 44 chybně určených. Přesto si Policie ČR takový systém platí. Lidi si prostě zvykli, že počítače chybují.

S omezeností kvantových počítačů souhlasím. Kromě toho že se nehodí na všechny algoritmy, tak problém je inherentní nestabilita, která roste s počtem superpozic. Takže prakticky kvantové počítače jsou zatím jen akcelerátory o malém počtu quibitů. V podstatě těch pár firem, co je vyvíjí, tak akorát touží udělat dostatečně stabilní systém, který zvládne pár typizovaných úloh (např. faktorizaci RSA klíčů), na které klasické počítače v rozumném čase už nestačí. Dál se bez nějakého zásadního fyzikální průlomu nedostanou. To jim ale bude stačit, aby si své kupce našly.

15.12.2021 18:25 j
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Problem budes mit uz v tom, ze i kdyz vemes "binarku", tak aktualne zcela jiste (ale nejen) ve svete x86 nevis, co ve skutecnosti bude CPU delat. Protoze ten ma dalsi vrstvy prekladu, ktery se jeste k tomu muzou i na stejnym kuse CPU v case menit.

BTW: Kdyz mluvis o nekonecnech tak sem si vzpomel na jednu hezkou veticku "kdyz nekdo zacne mluvit o mnozine vsech mnozin (uci na ZS), dejte mu par facek za sebe, a dalsi par za me ... doc csc ..." ;D

---

Dete s tim guuglem dopice!
xkucf03 avatar 13.12.2021 19:54 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh

Částečně souhlasím, ale na druhou stranu: kdo je víc, ten, kdo vyrobí dláto, štětec či tužku, nebo umělec, který pomocí těchto nástrojů vytvoří nějaké dílo? Ano, můžeš říct, že ten, kdo vyrobil první tužku, ovlivnil celý budoucí vývoj lidstva, ale to nijak nezlehčuje zásluhy jednotlivých umělců (nebo jiných profesí), kteří tento nástroj „jen aplikovali“. Navíc dát dohromady dřevo a grafit by asi zvládl i ten umělec, zatímco autor první tužky nebo štětce by třeba tak pěkné obrazy nevytvořil. Podle mého to nejde moc porovnávat, jsou to odlišné druhy činností a potřeba jsou oba. Je to jako se hádat, jestli je víc matematik nebo chemik.

Ty inovace se dějí i tam, kde se „jen aplikují“ hotové nástroje, akorát to jsou inovace na jiné úrovni. Nicméně neříkám, že každý programátor je vědec nebo umělec – velká část té práce je prostě řemeslo (což je taky potřeba).

Spíš je otázka, proč je poptávka po těch nudných opakujících činnostech, proč někdo platí za znovu-vynalézání kola. Částečně to bude pokrok – nová generace/verze řeší danou úlohu lépe než ta stará, ale z větší části to bude asi způsobené proprietárním softwarem (svobodný software by šlo přizpůsobit a přepoužít) a potom nevhodným návrhem a malou granularitou (existující software umí to, co chci, ale zároveň k tomu přibaluje spoustu jiných věcí, které nechci, a nejde je dost dobře oddělit, takže si to radši napíši sám).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
14.12.2021 05:06 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
K znovupoužití některých technologií částečně dochází - třeba nad Postgresem je postaveno několik jiných databází, kdy se modifikují vrstvy úplně vespod nebo vrstvy úplně nahoře.

Podle mne, ale musí jednou za čas dojít k razantním přepisům software. Každý sw má určitou "kapacitu" úprav, ke kterým samozřejmě dochází, tak jak se přidávají nové funkce. Po určité době je nutné z gruntu přepsat protože a) máte novou perspektivu - vidíte všechny úpravy a modifikace v celku a máte možnost přepsat kostru, b) máte nové možnosti - jak po stránce hw, tak po stránce sw (dost věcí se dříve nedalo dělat, protože se kód jednoduše nevešel do RAM), c) jsou jinak nastavené botlenecks - tím jak se mění železo, a mění se i potřeby a očekávání uživatelů, d) mění se i styl programování (a pocit, že je něco user friendly nebo není) - na low levelu programovat s ncurses nebo libxml2 je z dnešního pohledu šíleně nepohodlné a to jsou knihovny, které ve své době představovaly technologickou špičku.

A občas je nutné do toho seknout, a začít od nuly. Zpětná kompatibilita na jednu stranu umožňuje budovat neskutečně komplexní věci, na druhou stranu je to čím větší koule na noze. Je to parádně vidět na systémových knihovnách. Přidáváním rozšiřováním stávajícího API udržuji zpětnou kompatibilitu, ale na druhou stranu zvyšuji komplexitu vývoje. Dneska POSIX má funkcionalitu a limity hardware 50 let starého hardware (a NT 30 let).

Jinak k vývoji dochází pořád - i v databázích, a jsou to jak důležité změny v konceptu, tak změny v implementaci (sloupcové databáze, distribuce dat, optimalizace nad statistikami, způsoby estimace, nové typy indexů, ...) - jen ten vývoj možná není tak viditelný jako dřív, ale to je otázka měřítka - v software, která je starší a komplexnější ty změny nejsou tak vidět (navíc pak víc a víc uživatelů preferuje stabilitu a kompatibilitu, což zvyšuje komplexitu, a zpomaluje vývoj).
14.12.2021 08:04 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Typická ukázka je tohle vlákno v tar-bugs ohledně změny výchozího formátu archivu. Člověk z Gentoo navrhuje změnu, protože dokumentace už 20 let upozorňuje, že k ní dojde, načež správce taru oponuje, že je příliš nečekaná.
15.12.2021 18:39 j
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Jenze musis se na to podivat i tak, ze zkratka ten tlak na stabilitu === uzivatele o novy funkce nestojej, nepotrebujou je, neni duvod menit to co funguje, a i kdyz trebas me reknes, ze po prepsani to bude o 50% vykonejsi, tak ja ti reknu, ze nez to prepises a nez to bude dostatecne stabilni aby se to dalo pouzivat, tak vykon HW naroste o 500%.

Jinak i v databazich, ktery se obecne daji oznacit za pomerne dlouhodobe stabilni, opakovane narazim, na to, ze nejaka verze neco zacne nove podporovat, aby to pak v dalsi, nebo obdalsi verzi uz zase nepodporovala, coz je neco, co nebude akceptovat vubec nikdo.

Taky si pak myslim, ze dobre navrzenej SW problem s "upravama" nema. Samo takovych veci nebude nijak moc. Ale pro predstavu, v nekterych pripadech nemusis trebas i vic nez 90% aplikace vubec instalovat, pokud nechces nejakou tu zpetnou kompatabilitu. Jsou to oddeleny moduly, jsou nejak udrzovany, ale pokud je nevyuzivas, tak je nepotrebujes. Cehoz trebas presnym opakem sou widle, ktery ti nainstalujou i ten dos (a stejne snim nejsou kompatabilni).

BTW: Jinak zarnym prikladem sou Xka vs wayland ... vsechno spatne, napisem to znova, dyk tam 90% neni treba ... aby se tam 89% reimplementovalo pristich 30 let zpet ...
15.12.2021 19:07 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Výkon hw roste, ale rozhodně ne o 500%, pokud se budeme bavit o ekonomicky rentabilním hw. Co hodně roste jsou diskové kapacity a objem dat. A naopak klesají znalosti vývojářů a i ochota k redukci, archivaci dat. Zvyšují se požadavky na rychlost, atd. Navíc u komerčního sw musíte dodávat nové funkce, protože máte konkurenci, a jenom bugfixováním se na trhu neudržíte.
15.12.2021 20:26 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Výkon hw roste, ale rozhodně ne o 500%
Ono je nutne rict, za jak dlouhou dobu. Muj oblibeny priklad je srovnani ASCI Red, prvni pocitac co v roce 1996 prekonal 1TFLOPS a stal 46 mil. dolaru, a Sony PS2, ktery v roce 2006 mel dokonce vyssi vykon a stal $500. V kazdem pripade jde na tom videt ta disproporce v rychlosti vyvoje HW a SW.
Co hodně roste jsou diskové kapacity a objem dat.

Z pohledu zpracovani dat mi prijde jako hodne zajimavy narust kapacity pameti, kdy pro spoustu uloh zacina byt vykonove zajimave a ekonomicke unosne je provadet primo v pameti.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
15.12.2021 21:18 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
No zrovna v databázích se vyšší výkon operací v plovoucí čárce moc neuplatní.

Paměti je docela dost, a samozřejmě, že paměť hodně pomáhá. V posledních 10 letech se ukazuje, že je potřeba revize některých konceptů, které pak s větší pamětí nefungují optimálně (hash tabulky). A dokud nebudou běžně k dispozici persistentní paměti, tak je samozřejmě u větších dat problém po havárii, kdy přijdete o všechno, co jste měl v paměti. Pro databáze existuje hw akcelerace, ale zatím je to dost exkluzívní a drahá záležitost.

15.12.2021 22:07 johnyK | skóre: 1 | blog: uxblog
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
že je potřeba revize některých konceptů,
ja jsem uz pred casem videl nasledujici:

https://www.percona.com/blog/2017/01/06/millions-queries-per-second-postgresql-and-mysql-peaceful-battle-at-modern-demanding-workloads/

a nebo

https://mariadb.org/10-1-mio-qps/#comments

Je to sice na peknem hardware, ale 1 milion queries za vterinu - to se fakt ptam, kdo to vubec potrebuje. Urcite, jak pisete, vsechno se archivuje, narustaji data, ale napr. v Nemecku je ca. 3 miliony firem a z toho je jen 5000 skutecne obrovskych. U takovych bych si dokazal predstavit, ze potrebuji vykon, ale tech 99,9983 % zbylych firem musi s tim milionem snad vystacit?
16.12.2021 06:11 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Pro klasické aplikace se to nevyužije, a je to jen marketing (maximální zátěž, kterou jsem v ČR viděl, je o 2-3 řády nižší). Jsou ale různý monitorovací aplikace, kde by se potřeby takové průchodnosti mohlo dosáhnout. Osobně bych na to ale použil nějaký speciál navržený na rychlé inserty, a který je navržený, tak aby ta databáze byla rovnou distribuovaná, případně bych použil proudovou databázi.

Občas se taková rezerva může hodit pro blbě použitá ORMka, ale samozřejmě, že mnohem efektivnější je správně použít ORM nebo nepoužít (tam, kde hrozí vyšší zátěž, a vývojáři nevědí, co dělají - dobrému vývojáři ORM může ušetřit nějakou práci, ale už i průměrnému vývojáři umožní napsat hroznou píčovinu, která bude na netriviálních datech zoufale pomalá).
15.12.2021 22:59 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
V posledních 10 letech se ukazuje, že je potřeba revize některých konceptů, které pak s větší pamětí nefungují optimálně (hash tabulky).
Z dlouhodobeho pohledu bude potreba prehodnotit i ostatni tradicni koncepty, protoze hromada veci v tradicnich RDBMS pocita s tim, ze vsechna data se do pameti nevejdou, coz pak pridava rezii, ktere se muzeme zbavit.
A dokud nebudou běžně k dispozici persistentní paměti, tak je samozřejmě u větších dat problém po havárii, kdy přijdete o všechno, co jste měl v paměti.
Z pohledu ztraty dat to nevidim jako problem, protoze autoritativnim zdrojem dat zustava transakcni log. Pri obnove dat pak zalezi na tom, jestli lze obetovat vypadek a jak dlouhy.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
16.12.2021 06:19 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Posledních 20 let už se používají inmemory db - Monet je hezká databáze, která dělá hromadu věcí jinak. Problémy nastanou v brutálním poklesu výkonu, když se vám data náhodou do té RAM nevejdou, a pomalý studený start (ono načíst třeba 300GB z disku může chvíli trvat), i když inmemory db z principu zas nemohou být tak velké. Dá se to udělat tak, že o data nepřijdete, ale můžete mít dlouhý výpadek. Zas výkon je o 2 řády lepší než u klasických databází, takže s potenciálně větším rizikem můžete provozovat mnohem efektivněji řadu úloh.
16.12.2021 08:51 j
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Kdyz mi nekdo nabidne, ze za rekneme 100 clovekohodin zrychli nejakou jednu funkcnost o 10% (pokud by slibil vic, budu to chtit jako chybu opravit zdarma), tak je pro me efektivnejsi si za tech 100 hodin koupit vykonejsi HW. Zrychlim tim uplne vse.

A ano, vim ze v nejaky fazi muzu narazit na to, ze vetsi palice uz neni k dispozici, ale to se tyce tak mozna tisiciny promile aplikacnich nasazeni.

Mimochodem, naopak, provadet neco v pameti dava smysl cim dal mensi, protoze vykony diskovych ulozist za poslednich rekneme 10let rostly radove, cena per IO pak radove klesla. Defakto tam, kde si musel mit klidne i cely racky plny disku aby ses dostal na pozadovany IOps ti dneska muzou stacit dve SSDcka strceny primo do serveru. Bywoko ti totiz jediny SSDcko nahradi zhruba stovku 15k disku, spis vic.

---

Dete s tim guuglem dopice!
16.12.2021 08:32 j
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Za jak dlouho prepises a odladis aplikaci, ktera ma reknem 10M radku zdrojaku? Za 10 nebo 15 nebo mozna 30 let? A ve finale budes mit presne stejnej bordel jako mela puvodni aplikace, takze muzes zacit obratem prepisovat znova.

A nikolivek, uzivatele komercnich aplikaci naopak chteji, aby jejich aplikace fungovala stale stejne, a jestli je dokaze neco doslova a dopismene nasrat, tak prave zmeny, o ktere nestoji. Specielne proto, ze ty zmeny typicky naprosto nijak nezlepsi jejich praci, zato rozbijou jejich pracovni workflow a snizi efektivitu prace klidne o dva rady.

Dam ti takovej typickej priklad. Ucetnicvi. Znam nemalo firem, kde pouzivaji stale "DOSovou" variantu. Proc? Je to cele ovladane klavesovyma zkratkama, na mys netreba vubec sahat a efektivita prace je o nejmene rad lepsi, nez v okeni variante, ve ktere musi uzivatel neustale honit po cele plose vsemozne ovladaci prvky. A to jeste nemluvim o situaci, kdy aplikace "inteligentne" ovladaci prvky presunuje, takze uzivatel musi neustale resit, jestli to vpravo nahore je zrovna to, co potrebuje, nebo neco uplne jinyho.

---

Dete s tim guuglem dopice!
16.12.2021 08:58 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
To, co chtějí uživatele je jedna věc. Druhá věc je, aby měli programátoři na chleba. Bez nějakých zásadních revizí ten software neprodáte dalším zákazníkům. A bez nových zákazníků více méně skončíte. Ztratíte konkurenceschopnost a nakonec i ty stávající zákazníky, protože vás neuživí a fixní náklady budete rozpočítávat na menší počet zákazníků, kterým se to samozřejmě nebude líbit. A údržba starého sw může být dost drahá záležitost.
16.12.2021 16:43 j
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Ehmm ... v komercni sfere o ktery je rec, se za SW plati maintanence, a ta dela nejakych 20% ceny implementace (tedy licence + prace). Takze i kdybys jako dodavatel nedelal vubec nic, tak se vpohode uzivis.

Ty prachy pak zakaznici plati prave za to, ze ten SW bude dlouhodobe funkcni(cimz se mysli predevsim to, ze kdyz soudruzi v M$ neco rozbijou, tak ze to dodavatel ve svym SW nejak opravi), nederavy a pripadne v souladu s legislativou, pokud obsahuje nejaky legislativne zavisly procesy.

V nekterych luzich (adobe napr) se rozmohly moresy na tema ze platis 30-50% rocne, a sw se ti meni pod rukama, na coz nemalo uzivatelu reagovalo tak, ze se radostne presunuli ke starym, jednorazove zaplacenym a neudrzovanym verzim, nebot nehodlaji platit za bazmek, ktery kazdy mesic nefunguje nejak jinak.

A co se tyce prodeje, tak nekteri zakaznici si pri vyberu SW nechavaji delat reserze na tema zasadni zmeny za poslednich 10 let, a kdyz tam nejaka je, tak nabidka putuje do kose. Protoze stabilita SW je jejich primarni pozadavek. A vubec se jim nedivim, protoze nasazeni SW trva tak neco mezi rokem (u tech nejprimitivnejsich veci) az 5 lety, takze nehodlaji rok po zprovozneni zase vsechno delat znova.

---

Dete s tim guuglem dopice!
16.12.2021 17:09 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Komerční Unixy garantovaly kompatibilitu zpětnou kompatibilitu až za hrob. A kde je jim konec. Je fakt, že jsem viděl sw ve fabrikách běžet ještě na win 3.11, ale bez bug fixů, s šíleným UI. Občas narazíte na konzervy, ale pak už to neumí kdo používat a neumí ani kdo programovat.
xkucf03 avatar 16.12.2021 21:21 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vývoj softwaru, věda, umění, řemeslo, znovuvynalézání kola, svobodný software, granularita, modulární návrh
Ehmm ... v komercni sfere o ktery je rec, se za SW plati maintanence, a ta dela nejakych 20% ceny implementace (tedy licence + prace). Takze i kdybys jako dodavatel nedelal vubec nic, tak se vpohode uzivis.

Za údržbu se sice platí, ale na dlouhodobé uživení se to není. Svým způsobem máte pravdu oba. Na jednu stranu zákazníci chtějí stabilitu a nemají moc rádi změny, zvlášť když jim to něco rozbije (a jak se jednou naruší důvěra v dodavatele, tak je těžké ji získat zpět). Na druhou stranu se čas od času na trhu objeví někdo, kdo nelenil, investoval a na zelené louce vyvinul nový software… a přetáhne část zákazníků, kterým buď došla trpělivost s údržbou starého softwaru nebo v tom vidí nějaký potenciál (nové/jiné funkce, které starý software neměl a těžko je přidá). Často taky dojde k nějakému posunu, změní se potřeby uživatelů, ze starého softwaru se používá jen část funkcionality a naopak jiná část chybí.

Ve svém článku o komplexitě softwaru v kapitole Časová dimenze popisuji jeden případ – takhle to může dopadnout, když se snažíš uživit jen z údržby a ten software jinak nerozvíjíš. Nechci prozrazovat, o jaký software přesně šlo, ale je to reálný příklad z praxe.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
13.12.2021 21:14 zzz
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
od vynalezu rekneme C (nebo FORTRANu podle vkusu kazdeho pametnika) se vlastne nic nezmenilo
Ale to prece neni pravda. Probehlo obrovske mnozstvi inovaci a treba funkcionalni programovaci jazyky (Haskell) nebo type driven (Idris) nemuzes jen tak odsoudit jako "to same jako C".
DB to same, od vynalezu relacni DB je to opet to same dokolecka, jen s jinym API.
Pokud znas jen relacni databaze tak ano, ale co vsechny ostatni typy? To mi prijde hrozne ignorantske pojeti.
Nova myslenka bylo treba SVN, Git to dotahl.
Tak teda uplne nevim, jestli te brat vazne nebo ne. SVN urcite nebylo "nova myslenka" a GIT rozhodne neni "dotazeni SVN".
Tech lidi kteri skutecne pracuji na vecech ktere ovlivni civilizaci na dalsi desitky let je strasne malo.
Fakt teda nechapu, koho teda povazujes za vyvojare a koho ne. Jen na Linuxu 5.14 se podilelo ~2000 commiteru, ti vsichni kolektivne ovlivni civilizaci na dalsi desitky let, protoze vysledek jejich prace se bude masivne desitky let pouzivat.
Bystroushaak avatar 14.12.2021 03:52 Bystroushaak | skóre: 36 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
15.12.2021 18:49 j
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
To skoro vypada, jako ze o programovani nic nevis ...

Je prece uplne jedno, jestli do strojaku prelozim C nebo cokoli jinyho, vysledek bude (v optimalnim pripade) totoznej. Klidne muzu napsat predkladac z francouztiny nebo klingonstiny, a porad to bude totez, jen s jinou syntaxi zdrojaku.

---

Dete s tim guuglem dopice!
15.12.2021 20:37 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
To skoro vypada, jako ze o programovani nic nevis ...
Jeste ze je tu takovy odbornik...

Programovani absolutne neni o tom, jak bude vypadat vysledny kod, ale o tom, jak se program vytvari a udrzuje a zde opravdu jsou fundamentalni rozdily mezi jednotlivymi jazyky.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
15.12.2021 21:19 zzz
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Je prece uplne jedno, jestli do strojaku prelozim C nebo cokoli jinyho, vysledek bude (v optimalnim pripade) totoznej.
To je diskuse jako s prvakem na vysce, ktery dosahl osviceni po prvnim precteni wiki o Turing-complete jazycich.

1) existuje mnoho jinych (dulezitejsich) metrik programovacich jazyku nez jen vysledny strojak.

2) at uz je "optimalni pripad" cokoliv, je to irelevantni, protoze ten optimalni pripad se v realite nevyskytuje

3) Ani v tom teoretickem "optimalnim pripade" nedokazi ruzne jazyky/compilery vytvorit identicky strojak. Nektere maji ruzny inherentni overhead, jine maji vice (napr. typovych) informaci pro lepsi optimalizaci atp.

4) Cela ta idea, ze tohle by melo nejakym zpusobem dokazovat nedostatek inovace, je absurdni.
16.12.2021 16:54 j
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Jinak receno, jen potvrzujes co sem napsal - nevis o programovani nic, a presne proto vypadaji vysledky tak jak vypadaji - naprosto nepouzitelny nabubrely aplikace ktery nefungujou ani jako demo.

Pokud se ohanis optimalizaci prekladace, tak to je potvrzeni cislo dve, protoze programator pise odptimalni kod a neceka ze za nej bude myslet kompilator.

Kdyz totiz reknu, ze neco ma mit 10B tak vim proc to ma byt 10B a kompilatoru muze byt uprdele jestli to bude cislo nebo pismenka, zatimco ty netusis co tam bude a proc to tam bude, a ocekavas, ze to za tebe vykouma prekladac. Coz pak vede k tomu, ze tam primasti dalsi MB kodu kvuli tomu, ze programator nevi co dela.

CPU VZDY provadi POUZE strojovej kod, a prave a POUZE to je cil libovolnyho programovani. A pokud tohle nevis, tak ses proste jeden z toho stada debilu ktery vykrikujou jaky sou programatori.

---

Dete s tim guuglem dopice!
16.12.2021 19:09 plostenka
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Pokud se ohanis optimalizaci prekladace, tak to je potvrzeni cislo dve, protoze programator pise odptimalni kod a neceka ze za nej bude myslet kompilator.
To je velice odvazne tvrzeni. Programator pise v prvni rade PoC, v druhe funkcni kod a az kdyz ma nahodou cas nebo zasadni duvod, tak i optimalizace okolo.

Rozhodnuti, jestli ma byt cyklus volany dokolecka nebo rozbaleny, jestli funkci volat nebo inlineovat, jestli... je u C klidne mozne nechat na gcc/clangu, u vyssich jazyku casto ani nemas jak si svoji vuli rozumne vynutit.
CPU VZDY provadi POUZE strojovej kod, a prave a POUZE to je cil libovolnyho programovani.
Na modernich procesorech se k strojovymu kodu ani nedostanes. I kdybys psal v assembleru, tak to co vidis v hexeditu jsou jen "makra" pro skutecny strojovy kod, tzv mikroinstrukce, kterym CPU skutecne rozumi a do kterych si ty makroinstrukce interne prevadi.
17.12.2021 12:37 zzz
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
To je takova sbirka zvastu, ze se mi na to uz nechce reagovat.
20.12.2021 13:45 marbu | skóre: 31 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Stačí se podívat např. na historii Unixu, ten základní koncept dala dohromady hrstka lidí. A když bych se podíval mimo svět free software, tak bych např. čekal, že za windows jádrem taky nebude těch lidí nějak moc.
There is no point in being so cool in a cold world. Source code of the BioNTech/Pfizer SARS-CoV-2 Vaccine
Josef Kufner avatar 20.12.2021 20:38 Josef Kufner | skóre: 70
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Takřka všechny projekty začínají s vizí jednotlivce a pokračují typicky v rukou malého týmu, který udává směr vývoje a řeší klíčové komponenty. Pak se kolem točí tisíce přispěvatelů, kteří často dodají jen nějakou opravu či menší fičurku a zas zmizí mezi běžné uživatele.
Hello world ! Segmentation fault (core dumped)
11.12.2021 00:35 kvr
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Tehdy, když ještě MySQL nemělo transakce, tak existovala možnost jako engine použít BerkeleyDB a transakce tu byly.
Ona sice BerkeleyDB podporuje transakce, ale na SQL je příliš nízkoúrovňový. IMHO výsledkem muselo být příliš mnoho zamykání nad nízkoúrovňovými objekty, místo objektů na úrovni abstrakce SQL. K tomu samozřejmě potenciální deadlocks při zamykání několika indexů, mapování těch indexů na struktury tabulek atd. IMHO je to nesmysl a potenciální výkonnostní problém, řešit vysokoúrovňové problémy takhle nízko.

To je taky důvod, proč se neujala v podnikové sféře - má jednoduše jinou úlohu - prakticky jen rychlá key-value databáze, spíš technicky orientovaná.
14.12.2021 12:26 johnyK | skóre: 1 | blog: uxblog
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Ona sice BerkeleyDB podporuje transakce, ale na SQL je příliš nízkoúrovňový
tak detailne se v tom nevyznam, ale kdyz se tak podivam na ten dokument - v clanku zminena transakcni knihovna libtp -

https://dsf.berkeley.edu/papers/ERL-M92-02.pdf

tak v tom schematu na obr. 1 je zobrazena uplne klasicka koncepce reseni transakcniho zpracovani - jak to resi vlastne vsechny databaze. Myslim tim, ze jsou obsazeny ty standardni komponenty, zejmena tedy lock-log-buffer-manager, ktere zajistuji aby se prave napr. zamykalo rozumne. U te BerkeleyDB zamyka ten lock-manager standardne po strankach, jak je to i u ostatnich db bezne.

Je pravda, ze v pocatcich mysql (verze 3.x) kdyz BerkeleyDB jako engine implementovali, tak byla rada pocatecnich a omezujicich problemu napr. pro praci s mnoha tabulkami. Ja vidim problem spise v necem jinem.

Pred dobre 15 lety se celkem zive diskutovala ta technicka problematika u MySQL - totiz ta moznost vyuzivat ruzne enginy - pamatuji si, jak pan Stehule myslim tenkrat na rootu rikal, ze je to sice hezke, ze je mozno si tu engine zvolit, ale ze to nemuze vlastne fungovat. Ja jsem tenkrat nesouhlasil a dnes musim rici, ze vyvoj dal panu Stehulemu za pravdu. Nakonec se z MySQL/MariaDB stala databaze s jedinym engine - INNO-DB. Ja fakt neznam nikoho, kdo by pouzival neco jineho. Proste vice tech engine ten vyrobce podle me nemuze vubec ani logisticky zvladnout. A ta obecna interface mezi MySQL a tou kterou engine samozrejme omezuje moznosti skloubit jednotlive casti do jednoho optimalniho celku. Takze ja si myslim, ze neodesla jen BerkeleyDB engine, ale i ty ostatni.
14.12.2021 14:05 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Vzpomínám si, že tohle se někdy řešilo. On to není úplně můj názor (je dost věcí, kterým nerozumím, a na které nemám názor), jen jsem ventiloval obecný komunitní přístup k možnostem psaní engine v Postgresu. MySQL v té době byla hodně nabuzená - oni odjakživa měli dva engine (MyISAM, a memory), a v relativně úspěšně tam přidali třetí InnoDB (a připravovali se na čtvrtý na Falcona). Co jsem se pak dozvěděl, tak pro MySQL to bylo relativně přirozená věc - MySQL vznikla kombinací relačního engine MyISAM + interpretu SQL. Oni "jen" zobecnili svoje interní API. Navíc uživatelé MySQL byli zvyklí, že jednotlivé funkcionality různě fungují nebo nefungují. Takže to rozmáchnutí se do šířky u MySQL je docela pochopitelné. Naproti tomu Postgres běžel nad vlastním jádrem, a přidávat další jádra nebylo na pořadu dne - nebylo by to jednoduché, a komunitě nešlo o co největší záběr ale spíš o co největší konzistenci a nejrobustnější implementaci. Taky komunita si nebyla jistá, jaké komponenty by engine měl obsahovat, a jak by se to mělo integrovat, a tudíž se touhle cestou Postgres nevydal. Postgres dokáže integrovat různé db skrze FDW API, ale je to úplně jiný mentální model. Dneska má pg storage API, ale to je designově něco jiného samostatně fungující databázový engine.

Ten koncept v MySQL, vzhledem k historii MySQL, nebyl úplně mimo mísu - ale chyběl tomu byznys model. Firmy, které psaly db enginy se nedostaly k financím, nedostaly se k lizu, ke kterému se dostala MySQL ab od Googlu a Facebooku, a od MySQL ab nedostaly žádnou podporu a skončily. Pak další éra NoSQL databází ukázala, že prostor pro další db určitě je, případně dnešní NewSQL ukazují, že se dá životaschopně propojit speciální db engine s SQL, a že se to dá ufinancovat provozem jako služby v cloudu. Jako klasický sw se vývoj ale neuživil. Teď to třeba ale naráží na parazitování Amazonu, který firmám, které píší vlastní db engine podráží nohy. Napsat engine je jedna věc - dlouhodobě to ufinancovat je věc druhá - myslím si, že neskutečný miliardy rizikových investic byly propálený ve vývoji nových db engine.

Další otázkou jsou uživatelé - běžný masoví programátoři - drtivá většina z nich nepochopila rozdíly mezi enginy v MySQL (vůbec si nedělám iluze, o tom, kolik z nich tuší o rozdílech mezi InnoDB a MyISAM), a benefity a rizika z toho plynoucí. Samozřejmě, pro pokročilé uživatele by tam benefit byl, ale těch je minimum, a ty to nedokáží ufinancovat.
15.12.2021 14:52 johnyK | skóre: 1 | blog: uxblog
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Dneska má pg storage API,
je myslena ta pluggable storage? Prohledel jsem si Vase clanky k Postgresql na rootu a i kdyz to maji uz od verze 12, tak jsem k tomu nic nenasel. Ani na postgrescz. Na internetu je nekolik firem, ktere to chteji nejak vyuzivat (ta ruska firma PostgresPro,cinane z HighGo), odkazy na prednasku Andrese Freunda, ale jinak nic praktickeho, priklady. V orig. dokumentaci k pgsql jsem take nic nenasel. Nevite o nejakych prikladech, projektech, ze kterych by se dalo nejak vycist, jak to vubec funguje. Nebo mozna planujete clanecek :-)
15.12.2021 18:18 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
juju. Co vím, tak aktuálně nic není hotového, co by se dalo použít, nicméně to není úplně mrtvé. Jen od nějaké generalizace a pročištění API, k použitelnému storage je dlouhá cesta (podstatně delší než se původně myslelo), a že aby to mělo větší efekt, tak těch změn musí být víc (indexy, executor, další background workry), že jen změna formátu větší extra výkon nepřinese.

Tady je dokumentace https://www.postgresql.org/docs/current/tableam.html. Další článek se schématy a s popisem inmemory storage.

Jednoduchý relativně funkční příklad je například https://github.com/adjust/pg_cryogen.

zheap je možné už otestovat.

Mám pocit, že se pořád dělá na zedstore - což by měl být sloupcový engine. Někde jsem četl, že timescale uvažuje o append only engine pro časové řady. Teď asi nejnovější a nejrozkročenější je orioledb.

Tomuhle by měl rozumět Tomáš Vondra, který jeden čas dělal na implementaci sloupcového engine v Postgresu v 2ndq. Tohle je jinak téma, které jde úplně mimo mne, a vzhledem k tomu, že je COVID a nejsou žádné akce, tak nemám ani žádné zákulisní informace.
11.12.2021 08:01 okbobcz | skóre: 3
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Na indexech se určitě od dob akademického Postgresu zapracovalo. Tam nejde jen o strukturu, ale i o samotné vyhledávání, ale i o to, jak funguje napasování na multigenerační architekturu, nakolik se musí nebo nemusí při update zamykat (jak se index bude chovat při souběhu updates, ...). Ta základní kostra zůstala - v gitu je poslední záznam z léta 96 https://github.com/postgres/postgres/blob/master/src/backend/access/index/indexam.c, a co jsem se díval do historie, tak asi nejvíc změn se týká čištění a oprav bugů. Minimálně ale v rámci komunitního Postgresu vznikly nové formáty indexů, které zmiňovaný autor určitě neimplementoval - GiST, GiN, SP-GiST, Hash, BRIN.

Ten článek jsem četl také - mám pocit, že v tom článku lepší implementací stromů myslely LSM stromy http://source.wiredtiger.com/3.2.1/lsm.html. Výhodou LSM stromů je konstantní rychlost insertů (zvlášť u velkých tabulek, které se nevejdou do RAM). Ty (LSM indexy) v Postgresu nejsou, ačkoliv to není žádná novinka. Samotná implementace stromu asi není velký problém, nicméně a) musí se to napasovat na tu implementaci multigenerační architektury, která je v Postgresu (která nepoužívá undo log), b) nevím jak je to dneska, ale dřív (cca 15 let zpátky) tam byl problém se sw patenty a v pg nesmí být nic, co by bylo ohledně patentů rizikové. Dneska už patenty možná neplatí, ale zase rychlost insertů na Postgresu není extra palčivý problém - Postgres se moc nepoužívá jako rychlý storage, a tam kde to potřebují, tak a) mohou použít MySQL nebo MariaDB s LSM enginem, b) může se použít FDW driver vůči externí db, která by tento problém řešila lépe, c) dneska je mnohem víc ramky, a v kombinaci s partitioningem se dá ještě i s klasickým indexem docílit dostatečného výkonu pro většinu aplikací, které se na Postgresu provozují (aplikace, kde rychlost insertu je kritická, tak se většinou neprovozují na pg - na dnešním železe desítky tisíc insertů za sec i na pg nejsou problém).

Vím o nějakých experimentech, teď nedávno jsem viděl jeden pokus, který vypadá hodně nadějně - nejde jen o změnu indexu, ale i o změnu uložení heapu, který používá nové storage API v pg. Je to ale pořád experiment, který může být zajímavý. Teď jsou aplikace, u kterých zákazníkům říkám, že na to se jim Postgres nehodí, a s tím novým alternativním enginem (určitě nebude primární - a je otázka jak bude licencován) aplikací, kam se nehodí Postgres, bude méně.
Max avatar 11.12.2021 08:13 Max | skóre: 70 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Zajímavé počtení, děkuji.
Zdar Max
Měl jsem sen ... :(
xkucf03 avatar 11.12.2021 11:29 xkucf03 | skóre: 49 | blog: xkucf03
Rozbalit Rozbalit vše Interní distribuce GPL softwaru uvnitř firmy

Is making and using multiple copies within one organization or company “distribution”?

No, in that case the organization is just making the copies for itself. As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.

However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.

Zdroj: Frequently Asked Questions about the GNU Licenses

Dokud jsi zaměstnanec, tak je to interní použití, protože vystupuješ jako součást té jedné právnické osoby, která je držitelem licence. Pokud by se to šířilo např. k zákazníkům nebo dodavatelům, tak už by to byla distribuce a ti by museli dostat i zdrojáky (protože nejsou součást té první právnické osoby).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
12.12.2021 11:59 trekker.dk | skóre: 72
Rozbalit Rozbalit vše Re: Interní distribuce GPL softwaru uvnitř firmy
Např. home office -> je používání firemního software na dálku (přes VPN) nyní šíření ve smysluu AGPL?
IMO je to totéž, jako když ten zaměstnanec sedí v kanclu - i když je doma, je to v rámci organizace - uvnitř.
Quando omni flunkus moritati
Heron avatar 11.12.2021 11:36 Heron | skóre: 53 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Nápadné na té databázi byla skutečnost, že tam není SQL. Mladší kolegové si jistě řeknou, co je to za podivnou databázi, ale to tak dříve bylo.
Tohle nebylo jenom dříve, databáze není synonymum pro SQL. Dneska lze mít kvalitní key-value, dokumentovou, objektovou, relační a ani ta nemusí být nutně vybavena SQL.
Je s podivem, jak málo programátorů postavilo celou naší dnešní databázovou výbavu na nohy. Nejsou to vůbec žádné velké týmy, spíše skupiny o několika lidech.
To mě zarazilo na MS. Na youtube je týpek, který (alespoň to tvrdí a je schopen z fleku napsat win32 app v assembleru, takže bych mu celkem veřil) pro MS pracoval od dob DOSu a pro řadu NT potom napsal Task Manager, zip folders (a další změny v Exploreru) a hru Pinball (a spoustu dalších věcí). Schválně, kdy se původní Task Manager z NT 4.0 změnil (resp. opačně položená otázka: jak dlouho vydržel ten původní?) a kolik věcí v nastavení se od verze NT 4.0 vůbec nezměnilo a vůbec se na to nesáhlo? Minimálně vzhledově jsou ty okýnka úplně stejný jako v NT4.0 a nejdou resizovat. Fakt by mě zajímalo, kolik lidí se v MS motá kolem jádra (on tvrdí, že v jeho době to bylo něco jako 6 - otázka co tím myslí, NT je částečně microkernel a tohle bude opravdu malé ale složité) a kolem těchto systémových věcí, když tohle napsal jeden týpek a 15 let se to nezměnilo (jasně, interní patche určitě byly).
Možná by nám pánové Stěhule nebo Vondra mohli sdělit, jestli je v postgres skutečně ještě ta původní Olsonova implementace a nebo už to přece jen někdo vylepšil.
Přidávám se ke přání. O tohle bych si rád početl.
Také je možno zmínit, že lidé z BerkeleyDB po odchodu od Oraclu vytvořili databázi, s kterou pracuje MongoDB. Přiznám se, že jsem těmhle No-SQL databázím nikdy moc nevěřil, ale když za tím stojí někdo takový, tak se to přece jen musí asi otestovat.
Ono to funguje dobře, akorát je potřeba přijmout trochu jiný přístup k věci a to jak ze strany vývoje appky, tak ze strany administrace. U Monga se spousta věcí řeší tak, že prostě přidej další node a zmigruj. (Nemá / nemělo to ekvivalent vacuum full, takže se to neumělo zmenšit a zmenšení se řešilo migrací na další node a zrušení původního.)

BerkeleyDB jsem používal jako backend pro SVN. Vadilo mi, že standardně to má milion souborů pro milion verzí, takže jsem používal BDB.

Pěkný článek, díky.
11.12.2021 11:51 ehmmm
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Ten win32 v asm klidne verim. V podstate pripravis stack/registry a volas API funkce.

Co se tyka toho maleho mnozstvi programatoru, tak trochu sleduju FirebirdSQL a mam pocit, ze to delaji asi v peti lidech.
Bystroushaak avatar 12.12.2021 06:43 Bystroushaak | skóre: 36 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Zajímavý blog, díky za něj. Kdysi mě zaujalo video ohledně vývoje SQLite, myslím že to bylo tohle; SQLite: The Database at the Edge of the Network with Dr. Richard Hipp.
14.12.2021 10:35 johnyK | skóre: 1 | blog: uxblog
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
hi, diky z ten link. Takhle emotivni prednasku jsem uz fakt dlouho nevidel.

A jak tam rika - software, ktere patri k nejpouzivanejsim na svete delaji 3 lide.
14.12.2021 15:15 ehmmm
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
emotivni = crazy ayes
Gréta avatar 14.12.2021 00:24 Gréta | skóre: 35 | blog: Grétin blogísek | Stockholm
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.

normálka prostě se jakoby ktomu hádání kdo furt vlednici strká pivo do jogurtů/kdo furt nechává zvednutý prkýnko/etc přidá hádání kdo jako za kterej bug muže :D ;D

15.12.2021 17:09 Michal Kubeček | skóre: 72 | Luštěnice
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Přiznejme si, že je to skutečně neobvyklé, když manželé společně programují databázi.

Jim Starkey a Ann Harrison?

20.12.2021 13:37 marbu | skóre: 31 | blog: hromada | Brno
Rozbalit Rozbalit vše Re: Vývojáři BerkeleyDB a toho všeho kolem.
Díky za zápisek, ten rozhovor jsem nedávno taky četl. Já si BerkeleyDB vybavuju jako backend pro rpm databázi, i když těch utilit používajících libdb bude stále dost, např. pam nebo iproute. Jinak nedávno Fedora přešla právě z licenčních důvodů na sqlite.

BerkeleyDB jsem přímo nikdy nepoužíval, ale zkoušel jsem tu zmiňovanou XML nadstavbu, a moc nadšený jsem z toho nebyl. Ono celý ten koncept XML databáze nebyl úplně dobře definovaný.

There is no point in being so cool in a cold world. Source code of the BioNTech/Pfizer SARS-CoV-2 Vaccine
22.12.2021 18:34 ajtacka
Rozbalit Rozbalit vše Re:
Tři voříšky pro Popelku

Príklad jazyka Erlang z strana okolo 205
-module(person).
-include("person.hrl").
-compile(export_all). % For test purposes only.
%% This creates an instance of a person.
%% Note: The phone number is not supplied so the
%% default value [] will be used.
make_hacker_without_phone(Name, Age) ->
 #person{name = Name, age = Age, 
 dict = [{computer_knowledge, excellent}, 
 {drinks, coke}]}.
%% This demonstrates matching in arguments
print(#person{name = Name, age = Age,
 phone = Phone, dict = Dict}) ->
 io:format("Name: ~s, Age: ~w, Phone: ~w ~n" 
 "Dictionary: ~w.~n", [Name, Age, Phone, Dict]).
%% Demonstrates type testing, selector, updating.
birthday(P) when is_record(P, person) -> 
 P#person{age = P#person.age + 1}.
register_two_hackers() ->
 Hacker1 = make_hacker_without_phone("Joe", 29),
 OldHacker = birthday(Hacker1),
 % The central_register_server should have 
 % an interface function for this.
 central_register_server ! {register_person, Hacker1},
 central_register_server ! {register_person, 
 OldHacker#person{name = "Robert", 
 phone = [0,8,3,2,4,5,3,1]}}.
Problém s jazykom Erlang je ten, že nie je MainStream a treba povedať, že by potreboval dosť prekopať, respektívne domyslieť a navyše reálny svet je dosť zvláštny(tým nechcem povedať, že sa Erlang nepoužíva, práve naopak)...

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.