Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.
Společnost Meta otevírá svůj operační systém Meta Horizon OS pro headsety pro virtuální a rozšířenou realitu. Vedle Meta Quest se bude používat i v připravovaných headsetech od Asusu a Lenova.
Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
10.12.2021 22:12
| Přečteno: 6431×
| 
| poslední úprava: 10.12.2021 22:17
(pozn. ve verzi 18.1.40 to vypadá, že Oracle SQL API zase odstranila ??? Change Log: ...The SQL API is no longer supported. If you require SQL support you must use Berkeley DB 18.1.32 or earlier.)
Programátoři běžného software tu databázi znali až pod názvem Sleepycat. Osobně jsem si s jedním ze jmenovaných vývojářů, Mikem Olsonem vymnenil několik mailu, protože jsme chtěli ve firmě komerční licenci Sleepycat, ale bohužel se nám zdálo tenkrát 25000 $ za neomezenou licenci příliš mnoho. Dnes to vidím trochu jinak, Oracle chce dnes za licenci na 1 server 9000 $. I když je zmíněný produkt dnes tak trochu na odstavné koleji, je možno na historii a zúčastněných lidech odpozorovat řadu zajímavých faktů.
1. Pořádné software dělá hrstka lidí
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. Např. ti v rozhovoru zmínění vývojáři Seltzer, Olson a Bostic studovali u Stonebrakera na Berkeley universitě. Stonebraker je ten s tou Ingres a Postgres, Olson v rozhovoru zmiňuje, že to byl on, kdo implemetoval binární stromy do Postgres a později i u BerkeleyDB. Olson míní, že ta implementace v BerkeleyDB je lepší než v Postgres a že to chtěl už dávno změnit, ale nedostal se k tomu. 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.
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.
2. Manželé programátoři
Teď bych se chtěl přiznat k takové zapeklité věci. Anglicky jsem nikdy moc neuměl a protože se dříve skutečně v IT ženy moc nevyskytovaly, tak jsem si automaticky myslel, že se za tím jménem Seltzer skrývá nějaký programátor - kdybych se vyznal v anglických křestních jménech, tak by mi to asi trklo, že Margo je dívčí jméno.
O to víc jsem byl překvapen, že paní Margo Seltzerova je i významná vysokoškolská osobnost a že za podstatnými částmi BerkleeyDB stojí ona. Co mi ovšem jste mnohem více udivilo je skutečnost, že Margo Seltzer a Keit Bostic jsou manželé. Pan Bostic je relativně známý programátor zejména svým výrokem:
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
3.duální licence a licence vůbec
Z uvedeného rozhovoru jsme pochopil, že vynálezcem duálního licencování je právě Keith Bostic. Já jsem celou dobu vycházel z toho, že to musel vymyslet nějaký lump z marketingu. BerkelryDB - tedy dříve Sleepycat byla nabízena právě s duální licencí tedy jednak s licencí velmi podobnou GPL a nebo komerční. Protože ta BerkeleyDB je vlastně knihovna, tak někdo, kdo chce tu BerkeleyDB použít a šířit musí dát k dispozici i vlastní software, které tu knihovnu používá. To byl také tenkrát ten důvod, proč jsme chtěli vědět, co ta komerční licence stojí.
S 'rozšířením' těch nejrůznějších licenci u svobodného software jsme si všimli zajímavé tendence jak se dá té 'publikaci' vlastního software i pod GPL licencí 'vyhnout'. Jedná se o tzv. 'internal use'. To zn., že firma která chce nasadit nějaké software, které je podle GPL 'odvozené dílo' to může ve vlastních 4 stěnách bez omezení provozovat. Softwarová firma, která to tomu uživateli dodá a třeba i instaluje musí samozřejmě splnit ty podmínky GPL a tedy uživateli předat kompletní zdrojáky celého software. To není až takový problém, protože ty zdrojáky dnes vyžaduje každý uživatel (nějakého podnikového systému). Ten uživatel má také samozřejmě teoretickou možnost sám to software dál šířit pod GPL licenci, ale to je naprosto nerealsitické. Zde tedy prakticky nehrozí, že by se vlastní software muselo nějak obecně šířit.
Zmíněná Oracle BerkeleyDB je dnes ovšem svázána s licenci AGPL. To ssebou přináší určité komplikace výše zmíněného použití. Dle té AGPL licence musí dostat ty kompletní zdrojáky 'každý' uživatel, který pracuje s takovým software přes síť. Podle APGL je ta práce přes síť vpodstatě to 'šíření' toho software. Zde vyvstává opět otázka při tom 'internal use'. Dnes používá každý pracovník software přes síť - i uvnitř nějaké firmy. Otázkou tedy je, zda musí tedy napr. každý zaměstnanec firmy, který to firemní software používá dostat v nějaké formě možnost si to kompletní software stáhnout. V Německu se s tímhle již soudně zabývali a dospěli k zajímavému závěru - jestliže se to software používá v rámci nějaké právnické osoby (napr útvar, divize nějakého podniku), tak se jedna o to ty '4 vlastní stěny'. Jestliže je software používáno přes tytto hranice, tak pak se již jedná o 'šíření' odvozeného díla a je třeba splnit ty náležitosti té licence.
Samozřejmě, že s technickým pokrokem a celkovou situací dochází stále k novým otázkám. Např. home office -> je používání firemního software na dálku (přes VPN) nyní šíření ve smysluu AGPL?
Řekl bych tedy pateticky na závěr, Keit Bostic /R. Stallman nám tady vhodili do prostoru pěkné jablko sváru
Pozn: chtěl jsem podobnou otázku položit paní Formanové z firmy SedlakovaLegal, která na konferenci OpenAlt 2021 o problematice licenci referovala, ale bohužel jsem její přednášku propásl. Takže jestli tady čte, tak se k tomu může klidně vyjádřit
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).
13.12.2021 18:38
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
13.12.2021 18:53
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
)
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
)
14.12.2021 14:41
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
14.12.2021 17:00
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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.
15.12.2021 05:21
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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í.
14.12.2021 12:11
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
13.12.2021 19:54
xkucf03 | skóre: 49
| blog: xkucf03
Čá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.
16.12.2021 21:21
xkucf03 | skóre: 49
| blog: xkucf03
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.
14.12.2021 03:52
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
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.
20.12.2021 20:38
Josef Kufner | skóre: 70
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
11.12.2021 08:13
Max | skóre: 72
| blog: Max_Devaine
11.12.2021 11:29
xkucf03 | skóre: 49
| blog: xkucf03
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ř.
11.12.2021 11:36
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
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.
12.12.2021 06:43
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
14.12.2021 00:24
Gréta | skóre: 36
| blog: Grétin blogísek
| 🇮🇱==❤️ , 🇵🇸==💩 , 🇪🇺==☭
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?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
-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)...