Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 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áří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
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: