DuckDuckGo AI Chat umožňuje "pokecat si" s GPT-3.5 Turbo od OpenAI nebo Claude 1.2 Instant od Anthropic. Bez vytváření účtu. Všechny chaty jsou soukromé. DuckDuckGo je neukládá ani nepoužívá k trénování modelů umělé inteligence.
VASA-1, výzkumný projekt Microsoftu. Na vstupu stačí jediná fotka a zvukový záznam. Na výstupu je dokonalá mluvící nebo zpívající hlava. Prý si technologii nechá jenom pro sebe. Žádné demo, API nebo placená služba. Zatím.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Myslím, že je celkem jedno, jestli ten soubor má 300 MB nebo 3000 MB. Jestli je archivační, vůbec na tom nesejde, mazání bude zřídkavé a compacting se dá udělat celkem snadno. Na hledání může být index stejně jako k databázi - a měl by být! Mám pocit, že třeba Evolution si ho dělá, dokonce fulltextový.Aby mohl server pracovat s e-maily efektivně, musí si k mboxu nebo maildiru vytvořit metadata, která popisují jednotlivé části e-mailu (aby se nemusel pokaždé znovu parsovat) a zaindexovat. Pak se takové poštovní schránky chopí Evolution nebo Thunderbird, který je zaměřen hlavně na POP3 a IMAP používá jen tak "bokem", všechny e-maily (nebo aspoň většinu) si stáhne do offline cache a zaindexuje si je. Uživatel se samozřejmě ke své poštovní schránce nepřipojuje jen z jednoho počítače, ale putuje po celé síti. Takže, v lepším případě, má e-maily na specializovaném poštovním serveru, ale přistupuje k nim skrze kopii e-mailů na souborovém serveru. V horším případě (cestovní profily Windows) má e-maily na serveru, a kopii celé schránky i s indexy si při každém přihlášení stahuje po síti a při odhlášení odesílá zpět. Mně to teda připadá padlé nahlavu. Mimochodem, to ukládání e-mailů do mailboxů/maildirů jde proti koncepci Unixu, kdy každý program dělá jen jednu věc. Protože na hledání může být index stejně jako k databázi - a měl by být, a tak si poštovní server naimplementuje svou malou databázi…
Mimochodem, to ukládání e-mailů do mailboxů/maildirů jde proti koncepci Unixu, kdy každý program dělá jen jednu věc. Protože na hledání může být index stejně jako k databázi - a měl by být, a tak si poštovní server naimplementuje svou malou databázi…
Přesně tohle mě napadlo, když jsem si vybíral (a nevybral) emailovýho klientaopen(3rd)
, ale musí si načíst seznam všech souborů, seřadit je a najít třetí a n a ten pak dát open(file_name)
. Pro tu nejkritičtejší operaci (najít 3. prvek) by se sice strom FS dal použít, ale aplikace ho nemá k dispozici.
Jinak teda pokud je dnešní situace tak tristní
Tristní... Těžko říct. Častěji než bych byl rád narážím na problémy u věcí, kde bych čekal, že jsou dávno vyřešené (no možná že jsou, ale firmy na to mají patenty a není to open source ).
Zrovna to řeší kamarád, co vyvíjí über-programovací jazyk,
Mno až vystřízlivým z oslav po státnicích, tak se vrhnu na MBOX2SQL. A udělám nad tím pár testů. Na netu jsem to nikde nenašel, pokud někdo něco podobného zná, tak prosím, dejte sem link.
Perzistentní heap by byla docela sranda.
Tak to zcela určitě
"Jenže ResiserFS ten strom používá nejspíš pro hledání sektoru začátku souboru dle čísla inode" A není tohle nesmysl? Operace nalezení prvního sektoru podle inode je snad otázkou jednoho diskového fetche, alespoň v tradičním unixovém FS. Problémem je hledání čísla inode u velikých adresářů ve filesystémech, které adresář implementují jako prostý lineární vektor dvojic (název, inode).Měl jsem na mysli hledání souboru ve velkém adresáři, moc jsem to zjednodušil
Jestliže bude v adresáři třetí soubor mít název "0000003", aplikace ho otevře pod tímto názvem. Následně FS musí najít inode, což je u tradičního unixového FS obecně O(N) operace, pokud hledám náhodný soubor v adresáři s N soubory, ale pokud FS udržuje mapování z názvů na inody ve stromu (Reiser, tuším...), pak je to O(log N). Takže aplikace má ten strom k dipozici, poněvadž adresuje soubory podle názvů.Pokud bude mít uživatel ve složce 1000 e-mailů a rozhodne se třetí smazat, soubory 000004 až 001000 se přečíslují? Děkuji nechci A zrovna IMAP musí umět vyhledat e-mail podle jeho "absolutního čísla" – identifikátoru, který se nemění (pokud je to možné), i podle pořadí e-mailu ve složce. A to ještě nemluvím o vyhledávání podle obsahu…
commit
pro ext3, ale nejspíš ne.
Tiskni Sdílej: