Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Řešení dotazu:
....databazovy specialista z enterprise prostedia....toto bych oznacil za "reseni problemu", pokud existuji enterprise databazovi specialiste na MySQL (kterou navic kdysi koupil SUN za USD1G), asi to s tou serioznosti nebude tak spatne... ;)
MyISAM někdy mívá podobné vlastnosti, které uvádíš. Aria a InnoDB jsou modernější, tímto neduhem by neměly trpět.Mohl bys to trochu rozvést? Mám databázi v MyISAM. Pokud bych přešel na InnoDB, bude odolnější v případě "tvrdého" ukončení (např. "zamrznutí PC"), popřípadě bude vyšší pravděpodobnost obnovy? Nedávno se mi stalo, že PC komplet zamrzl. Po restartu se vše tvářilo OK, ale v "zamrznutém" PC chyběli nějaké data. Přitom vše běží jako master-master (dvě samostatné PC) a synchronizace prostě neproběhla, žádná chybová hláška, nic. Musel jsem druhý "master" zrušit a importovat do něj data z prvního. Přitom druhý "master" funguje jen jako záložní, data se do něj jen synchronizují.
Mohl bys to trochu rozvést? Mám databázi v MyISAM. Pokud bych přešel na InnoDB, bude odolnější v případě "tvrdého" ukončení (např. "zamrznutí PC"), popřípadě bude vyšší pravděpodobnost obnovy?Ano, InnoDB je stabilnější. Navíc podporuje transakce, což se určitě bude hodit.
11.10.2017 06:31
okbob | skóre: 30
| blog: systemakuv_blog
| Benešov
11.10.2017 00:08
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Jinak ohledně té MySQL viz též třeba David Karban: MySQL sežere vaše dataAno, něco podobného jsem taky už kdysi psal. MySQL ignoruje příkazy (engine v create table), ignoruje datové typu (do čísla si klidně vložte text), ignoruje špatný konfig (prostě se to spustí bez nějakého engine, třeba toho, co umí transakce, takže to potom ignoruje commit / rollback). Replikace nefunguje (ale máte si ji kontrolovat, to je vaše chyba, že jste přišli o data) a tak dále. Prostě MySQL nebrat.
Získal jsem dojem, že MySQL a PHP patří dobře k sobě.Ano, naprosto souhlasím. PHP je na tom stejně blbě jako MySQL. Tohle je php v kostce:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
26.10.2017 22:14
md5('240610708') == md5('QNKCDZO')
K původnímu dotazu: doporučuju se mysql vyhnout. Pokud potřebujete SQL db, tak je tu postgresql nebo třeba firebird.
By default, ale u vseho co ignoruje vygeneruje warning a da se nastavit aby misto warningu hazela errory. Oproti PostgreSQL ma vyhodu ve mnozstvi enginu. Takze clovek muze nakombinovat data mezi ruznymi enginy jak potrebuje. Mam neco co je opravdova databazova aplikace s transakcema a paralelnim zapisem? Je tu XtraDB. Mam sber ruznych dat kde transakce nepotrebuju ale mam hromady zaznamu? Je tu Aria. Mam hromadu vyexportovvanych zaloh do kterych se jednou za uhersky rok potrebuju podivat? Je tu CSV engine. Sphinx a spider meli taky nejaky zajimavy vyuziti.Jinak ohledně té MySQL viz též třeba David Karban: MySQL sežere vaše dataAno, něco podobného jsem taky už kdysi psal. MySQL ignoruje příkazy (engine v create table), ignoruje datové typu (do čísla si klidně vložte text), ignoruje špatný konfig (prostě se to spustí bez nějakého engine, třeba toho, co umí transakce, takže to potom ignoruje commit / rollback). Replikace nefunguje (ale máte si ji kontrolovat, to je vaše chyba, že jste přišli o data) a tak dále. Prostě MySQL nebrat.
Takze clovek muze nakombinovat data mezi ruznymi enginy jak potrebuje.
Kdyby to bylo per database, tak budiž. Ale to, že mohou v jedné databázi fungovat některé tabulky transakčně a některé ne, osobně považuji za jeden z nejhorších nápadů, o jakých jsem v souvislosti s databázemi slyšel.
11.10.2017 09:26
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
a da se nastavitAno, tohle je klasická hláška ze světa MySQL. Všechno je vaše chyba, měli jste si to nastavit. Znám několik případů, kdy se k vůli mysql přišlo o data. Vím o projektech, kde se po změně na jiný db server přišlo na to, že do VARCHAR(xx) se ukládají výrazně delší texty, než xx, a v db jsou prostě useklé. A data už nejsou. Od kámoše mám info, že někde v nějakém ne zrovna malém projektu a ne zrovna nevýznamném projektu se do číselného sloupce (něco jako flag) ukládaly písmenka. DB si na to nestěžuje, vše funguje. Akorát data nesedí, integrita je narušená. Přišlo se na to až s migrací na postgres (ale tj celkem jedno, to by se zjistilo i při jiných migracích). A odpověď je, že si to mají nastavit. Oni si to nastavili. VARCHAR(20) je svým způsobem nastavení. Pokud to db ignoruje, jakou mám jistotu, že když v konfigu nastavím
opravdu_to_kontroluj = pravda to bude fungovat? Potom někdo přijde a řekne, tj tvoje chyba protože musíš zapnout ještě: ano_myslim_to_vazne_chci_kontroly = prosím. (Tohle nemám z MySQL, ale už jsem na to taky u jednoho programu narazil. Dvě konfigurační volby, jedna chtěla boolean a druhá chtěla nějaký slovní token.)
Takze za me, na 80 tisic radek by mozna stacila i SQLiteTohle bych řekl že trochu záleží na tom, co se s těmi záznamy děje. Posuzovat náročnost db podle počtu záznamů nelze. Nehledě na to, že sqlite bude mít trochu výkonnostní problém s paralelním přístupem.
ale co si z toho clovek udela, to maAno, s tímto souhlasím. MySQL se dá použít určitým způsobem s velkou výhodou. Ale to vyžaduje poměrně hluboké znalosti toho, na co se to hodí. Tím se ale posouvá na zcela opačný profesní konec, než pro začátečníky, kteří toho moc neví. A ti právě narazí u MySQL na hromadu nečekaných vlastností a nepříjemných překvapení.
takže jak je to ve verzi 10 fakt nevím.InnoDB už taky umí fulltext. To je asi tak všechno.
SHOW WARNIGS; a výsledek se dostaví:
Warning(1265): Data truncated for column 'name' at row 1
Přece se nebudu před každým insertem ptát databáze na její strukturu. Pouze jí sdělím: "Tady máš data a pokud ti nechutnají, tak je vyplivni nebo aspoň řekni, že ti nechutnají."Tak potom si ale musíš MySQL nastaviť do STRICT mode, databáza nevie čítať tvoje myšlienky, musíš jej konfiguráciou povedať čo chceš.
Pokud je požadavek na replikaci/clustering (což je dnes docela časté), pak např. firebird moc nepomůže. Jsou instalace (např. naše), kde se nepoužívají složité query a (zcela záměrně) facility nabízené databází (uložené procedury, triggery), ale o to víc je potřeba řešit replikaci/clusterování. Konzistentní klon souborů masteru bez jakéhokoliv omezení jeho provozu pomocí Xtrabackup je triviální, již jsou v něm hned uložené pointery pro nastavení sekundáru. Poté přesunout souborů na jiný stroj, nad ním spoustit db a z pointerů zapnout replikaci - práce na chvíli. Nemusí se nic dumpovat/nalévat, to by u naší 100GB DB chvíli trvalo. Na jeden slave replikujeme z několika produkčních serverů současně (vždy jen jeden master zapisuje), takže je přehození mezi nimi snadné, slave odebírá pořád data od všech. Nečekal jsem, že to bude fungovat tak spolehlivě...
Nicméně moderní Postgresql 9 má již replikaci taky hezky řešenou, co jsem se koukal. Detaily bohužel neznám...
Pokud je požadavek na replikaci/clustering (což je dnes docela časté), pak např. firebird moc nepomůže.
V tomto případě byl požadavek na replikaci jen workaround na neschopnost databáze udělat zálohu za běhu bez udušení všeho ostatního, takže tam by Firebird s MGA a "levnými" read only snapshoty pomohl docela znatelně. Jinak i pro Firebird existují řešení pro replikaci, ale nejsou open source.
Fráze "v tomto případě" se vztahovala k Heronovu postu, o kterém se v tomto vlákně diskutuje.
Ale z toho, co píšete v druhém odstavci, to vypadá, že i ve vašem případě je replikace vlastně workaround na absenci levných read only snapshot transakcí.
17.10.2017 10:01
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
se pro porovnáváníV tom příkladu je toho špatně mnohem víc. Výstupem md5 hash (pro dané vstupy) je hexa řetězec, který začíná 0e. Tohle php zmate natolik, že si myslí, že řetězec je číslo*, pokusí se ho zkonvertovat, konverze nedopadne dobře, obě "čísla" po konverzi skončí na stejné hodnotě a porovnání to vyhodnotí jako true. *) Což ve skutečnosti je, takže by měl porovnávat 128b hodnoty. Výstupem md5 je 128b číslo, ten hexa řetězec je jen převod tohoto čísla do soustavy o základu 16. Rozhodně to není float s exponentem.
17.10.2017 11:12
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
O důvod víc, proč nepoužívat MD5 pro ukládání hesel.Ach jo
MD5 se pro ukládání hesel neměla používat nikdy. První známky prolomení jsou z roku 1995 (resp. 1993), kompletně prolomeno v roce 2004. Před 13 lety. I kdyby to nebylo, tak je stejně slabá, 128b, díky narozeninovému paradoxu tedy pouze 64b, bylo brute force prolomeno někdy hodně dávno.
Do roku 2010 bylo možné použít sílu 80b (tedy alespoň 160b kryptografickou hash), potom už jen 112b a pochopitelně větší. Tedy něco jako 224b, takže nejblíže 256b - sha2-256). Dneska už i sha2 není úplně bez poskvrny, takže se používá zúžení sha 256/512 (z sha512 se vezme jen 256b).
To vše platí za situace, kdy má heslo entropii 112b a víc.
Pokud ne, je nutné použít PBKDF2 (já osobně je nemám rád, protože nikdo pořádně neví, zda se tím milionem iterací neoslabuje ta funkce samotná, takže doporučuju rovnou používat klíč s dostatečnou entropií).
Takže asi tak.
Nehledě na to, že výstup začínající 0e lze získat z libovolné jiné funkce, takže to nefunguje bez ohledu na zvolenou fci.
Příklad je to sice hezký, ale neříká to nic o tom, že je PHP špatné. Má jen jiné vlastnosti než je obvyklé u jiných jazyků. O důvod víc, proč nepoužívat MD5 pro ukládání hesel.Rozporováním uvedeného příkladu nedokážete, že je PHP bezproblémové
PHP je na tom skutečně asi tak jako Mysql - pokud bych si mohl vybrat, vybral bych u konkurence.
Pokud někdo v C použije pro porovnání operátor "=", tak mu kompilátor neřekne nicmuj gcc mne varuje ....
26.10.2017 01:34
-Wparentheses, defaultně se ten warning nezobrazuje, ale je to obsaženo ve -Wall.
Není až tak důležité, zda je MySQL špatná databáze. Otázka je spíš taková: Proč vůbec uvažovat o MySQL, když PostgreSQL je asi tak o sto generací a deset světelných let dál? Pokud hledáš databázi na nový projekt, která s projektem poroste od megabytů na notebooku až do replikovaných petabytů s paralelním vyhodnocováním, odpověď je PostgreSQL. Není třeba hledat nic jiného a není třeba zkoušet napřed polovičaté hračky a pak migrovat jinam. V případě aplikací v C++ PostgreSQL prostě rulezzzzzz.
Diskuse byla o příčině, proč je MySQL tak rozšířená, a vy jste místo příčiny uvedl důsledek.Jste na omylu, já uvedl pouze to, jaký je současný stav. V současném stavu je MySQL u PHP webhostingů tak rozšířená proto, že málokterý CMS podporuje něco jiného a nejvýznamnější CMS nepodporuje nic jiného. K tomu, jak se k tomuto stavu došlo, jsem se nevyjadřoval. A jestli máte za to, že diskuze byla o příčině, tedy o něčem, co se odehrálo v minulosti, možná jste cokoliv o minulosti měl zmínit dřív než v #55, abychom to věděli i my ostatní, co nežijeme ve vaší hlavě.
Ovšem těch 20 let determinovalo, jaký je současný stav.To je klidně možné, ale nijak to nerozporuje moje tvrzení o tom, jaký ten současný stav je.
Já jsem některé ty hostingy v té době používal.Jste dobrej. Ale na věcech to nic nemění.
Ale co taky chtít od vás, který máte pocit, že musíte mít vždycky pravdu, a pokud ne, platí bod jedna.Tak od vás tohle hodnocení sedí.
Mění. Hlavně to vyvrací tvé tvrzení, že Filip Jirsák je jen teoretikem.Já jsem některé ty hostingy v té době používal.Jste dobrej. Ale na věcech to nic nemění.
S tou nízkou vstupní bariérou to je tak, že MySQL bylo vždy docela snadné rozchodit.
Mně tam naopak některé věci (třeba kolem autentizace) přišly zbytečně komplikované. Ale pravda, když se to porovnává s PostgreSQL, tak to je samozřejmě jiná liga.
Na primitivní dotazy ORM frameworků odpovídá MySQL obvykle o něco rychleji.Což ale pořád nevykompenzuje fakt, že je to kopa hnoje.
Proč by někdo na webhostingu používal PostgreSQLPro začátek protože je to - narozdíl od Mysql - databáze. Chová se příčetně, neztrácí data, a tak.
Na to se dá říct asi tak jediné: PostgreSQL je tady. Kde na GitHubu najdu Oracle? Nějak ho tam nevidím…
Pri desiatkach tisic eur na procesor to nebyva zanedbatelna polozka.Při započítání ceny výpadku kritických aplikací je ta cena za licence naprosto zanedbatelná...
Odhadem je max. několik tisíc záznamů přes všechny tabulky (kolem 80).Jaké by byly cena za zpracovávání jednoho záznamu v případě Oracle? Myslíš, že je to ekonomicky smysluplný úkol pro SAP.
Dokonce by asi ani nenarazil na limity
Ano, samozřejmě zajímají, pokud vyvíjejí svůj vlastní software. Co vás vede k (mylné) představě, že tomu tak není? Licenční podmínky a další vlastnosti software (například dostupnost zdrojových kódů) jsou jedním z mnoha kritérií při rozhodování.
Tučně zvýrazněná část věty výše je poměrně důležitá, protože ve spoustě případů jde o řešení objednaná od třetí strany. A pokud ta třetí strana nabízí řešení s Oracle, ve kterém je cena za licence nenápadně schovaná v celkové ceně, koncový zákazník pak už většinou výběru databáze nevěnuje tolik pozornosti. (Ke své škodě, dlužno dodat.)
Zrovna banka nebo letecká společnost (a především státní správa) jsou podle mého mínění nasazení, kde Oracle nemá co dělat, zejména po kauzách tohoto typu. Podobně jako Shitdows je i Oracle software od firmy, která si raději honí své closed-source ego, než aby poděkovala za odhalení bezpečnostních nedostatků. Pravda, u žádného softwaru není zcela jisté, že v něm není exploit, který používá NSA, nebo že tam není rovnou backdoor. Jde ale především o to, že do PostgreSQL by se backdoor dostával hodně těžko a těžké by taky bylo dlouhodobě to tam udržet. U closed-source produktů se může člověk tak leda ptát: Wanna cry?
Tiskni
Sdílej:
