Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Perl: The only language that looks the same before and after RSA encryption.Přiznejme si, že je to skutečně neobvyklé, když manželé společně programují databázi. Představuji si, že u večeře rozebírají nějakou hash-implementaci v databázi a pak se o tom baví i pozdě večer
Tiskni
Sdílej:
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 licencieto 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.
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).
jen se pridava syntakticky cukr podle naladyJenž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.
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
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 lepsiJo, a když se potom dohádaj, tak si tam vzájemně nastrkají odjištěné granáty.
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.
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.
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í.
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 časeJasný, 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.
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.
Čá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).
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.
ž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?
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.
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.
od vynalezu rekneme C (nebo FORTRANu podle vkusu kazdeho pametnika) se vlastne nic nezmeniloAle 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.
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.
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.
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.
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á.
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.
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
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).
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ř.
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.
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
Přiznejme si, že je to skutečně neobvyklé, když manželé společně programují databázi.
Jim Starkey a Ann Harrison?
-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)...