Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
phone - phoneservice
0207xxxxxxx - 0207xxxxxxx@customername.sip.ourdomain.net
0207yyyyyyy - 0207yyyyyyy@othercustomer.sip.ourdomain.net
.
.
.
.
celkovo ma 4 miliony riadkov a je to databaza aliasov pre OpenSER.
mam nasledovne poziadavky:
- databaza musi zvladnut az 30 000 READS behom jednej sekundy
- co sa tyka updatov, tie budu velmi zriedkave, na tie nemam ziadne poziadavky
a teraz otazky:
Zvladne toto MySQL s InnoDB? nemal by som radsej pouzit nejaku BerkeleyDB?
pobezi to na 4 jadrovom Xeone, 16GB RAM. RAID-5 uscsi 320. Viem ze to budem musiet aj otestovat, teda neocakavam odpoved po ktorej sa do toho vrhnem, staci nasmerovanie od ludi so skusenostami.
Použil bych klidně MySQL ale s MyISAM, protože dle dostupných informací je MyISAM při takovýchto tabulkách mnohem rychlejší. Vlastnosti, který přináší InnoDB oproti MyISAM (např. transakce) při plánovaném využití nepotřebuješ.
BerkleyDB (db4) - 0.699s memcached - 2.585s MySQL (MyISAM) - 7.124s sqlite - 20.448s PostgreSQL - 96.241sZ môjho pohľadu veľmi príjemne prekvapil db4 a MySQL, naopak Postgres a memcache boli značným sklamaním.
BerkleyDB (db4) - 0.494s sqlite - 1.537s MySQL (MyISAM) - 2.002s PostgreSQL - 4.997s memcached - masked pre 64bit, t.j. netestovanéT.j. nie až taký debakel, aj keď postgres z toho aj tak zvlášť dobre nevychádza. Na druhej strane, používame ho a ceníme si ho nie preto, že vie slúžiť ako rýchla hash-tabuľka, ale preto, že má aj nejaké tie funkcie naviac...
araxon=# \d speed_test Table "public.speed_test" Column | Type | Modifiers --------+-------------------+----------- num | character(7) | not null val | character varying | not null Indexes: "speed_test_pkey" PRIMARY KEY, btree (num)Po inserte všetkých riadkov som ešte spravil VACUUM ANALYZE. Problém bol asi v tom, že súbor s databázou a indexom bol väčší než voľná RAM a tak sa do diskovej cache celý nezmestil - narozdiel od všetkých ostatných DB čo som skúšal. Je pravda, že miesto char som mohol použiť radšej numeric, ale char som použil aj vo všetkých ostatných DB...
MySQL (MyISAM) - 7.124s MySQL (InnoDB) - 9.293sRozdiel nijak zvlášť veľký... ale trvalo mi hodnú chvíľu, kým som to na InnoDB vôbec rozbehol. Defaultne je to nastavené tak, že InnoDB zaberá max. 128M a riadky, ktoré sa tam nezmestia majú proste smolu. Navyše pri OPTIMIZE TABLE to potrebuje ďalší priestor, lebo inak optimize zlyhá a rýchlosť výberu je potom nič moc. A ešte pri insertovaní v rámci transakcie som pozeral z druhej transakcie na počet riadkov, a ten sa priebežne menil - to by som nenazýval "transaction isolation". V postgrese toto chodilo predvídateľnejšie - kým som nedal commit, tak som videl počet riadkov nula...
pri insertovaní v rámci transakcie som pozeral z druhej transakcie na počet riadkov, a ten sa priebežne menil - to by som nenazýval "transaction isolation"Tak buďto to nebyla transakce (autocommit), nebo jste měl isolation level nastavený na read uncommitted, to se stává i v lepších rodinách
Tiskni Sdílej: