Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 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ářejí všichni účastníci, se skládá z desetiminutových
… více »
20.10.2007 17:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
. Kámoš z toho chce kompletního klienta, ty server - dohodněte se pánové 
20.10.2007 17:45
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Databáze nejsou zrovna úsporný prosředek k ukládání dat.
Otázka je, jestli se vyplatí vymýšlet vlastní optimální formát (a pak už vám nejspíš nezbyde čas nastudovat a naprogramovat všechny ty možné optimalizace, které už mají databáze naprogramované), nebo je lepší použít už hotovou databázi, která bude sice o něco méně efektivní, ale zase dostanete „zadarmo“ spoustu promyšlených optimalizací. Cena diskového prostoru bude dnes pravděpodobně daleko menší, než cena programátora, který zvládne naprogramovat efektivní databázový stroj…
To znamená, že člověk nepotřebuje blbosti typu QL parser a query optimizer a podobně, protože ví, co se s těmi daty bude dělat (přidej email, smaž email č. 13242, najdi emaily podle subjectu...). A těch věcí podle mě není hodně. Ostatně některé mailery to tak řeší, ne? Evolution s mboxem používá indexové soubory, jestli se nepletu.
21.10.2007 07:29
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
přidej email, smaž email č. 13242, najdi emaily podle subjectu...
...Vyhledávej v nich fultextem, seřaď relevantní emaily do stromu podle odkazů, hledej podle autora, data, čehokoliv, vyhledej maily daného autora v rozmezí datumů a jen s daným topicem...
Nene, stále mám pocit, že na toto se víc hodí SQL než souborová hash DB.
A co jako mám použít na ten fulltext? MySQL, které je podstatně pomalejší než Ruby+Ferret?
21.10.2007 18:36
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Prostě nevěřím tomu, že způsob jak to dělají mail klienti je nějak časově efektivní. Je mi jasné, že jejich vývojáři si často říkali něco ve smyslu, "hmm O(n^2), sakra, jak dlouho to bude trvat pro 100 položek? Jo je to hned, necháme to tak." Musí to jít rychleji, jen se to pro jejich počty nevyplatí implementovat. Fulltext nemusí být nutně 
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
20.10.2007 17:21
ALTER TABLE `xxx` ADD FULLTEXT..., ale i tohle zkusím.
21.10.2007 20:59
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Je mi jasné, že jejich vývojáři si často říkali něco ve smyslu, "hmm O(n^2), sakra, jak dlouho to bude trvat pro 100 položek? Jo je to hned, necháme to tak.Jestli to tak v konkrétním případě opravdu je, tak bych to autorovi otřískal o hlavu. Připomíná mi to obludně velké weby, kdy jen k zobrazení homepage je potřeba načíst 3 MB dat ("na mém připojení je to rychlé").
A těch věcí podle mě není hodně. Ostatně některé mailery to tak řeší, ne? Evolution s mboxem používá indexové soubory, jestli se nepletu.Třídění podle různých kritérií a hlaviček, fulltextové vyhledávání, statistiky… To že si to (téměř) každý klient řeší po svém a má vlastní index a keš uloženou někde lokálně je podle mne největší slabina dnešních e-mailových klientů.
21.10.2007 18:37
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
příliš náročné na výkon.
Tím si nejsem příliš jist, google dokazuje, že to jde. Bohužel pouze na web rozhranní.
A co jiného by klient měl dělat? To už rovnou můžeme vymyslet IMAPv5 s podporou všech těchhle věcí, protože jinak nevidím moc možností, jak to opravdu udělat standardní.Když ten IMAPv5 nebude mít vlastní TCP/IP protokol, ale bude fungovat přes HTTP, dostáváme se už pomalu k tomu, jak bych si to představoval. Že jsou e-maily uložené na serveru a pak ještě jednou na každém klientovi, aby v nich klient mohl vyhledávat, to opravdu nepovažuji za šťastné řešení. Zvlášť když se uživatel přihlašuje pokaždé jinde (jako třeba ve škole) – pak si buď musí index při každém přihlášení okopírovat ze sítě a při odhlášení zpět (srdečné pozdravy cestovním profilům Windows), nebo musí mít index připojený jako síťový disk – takže na serveru jsou ty e-maily jednou ve formátu pro IMAP server, jednou pro poštovního klienta. Nějak se mi tu ztrácí význam té zaklínací formulky „použij IMAP a e-maily máš na serveru“.
Jenomže většina poskytovatelů e-mailu tohle stejně nebude poskytovat - příliš náročné na výkon.Zatímco mít tohle a nad tím jako nadstavbu ještě webové rozhraní, to náročné na výkon není? Kdyby měl GMail zdokumentované rozhraní, přes které si to jejich AJAXové rozhraní povídá se serverem, je to už téměř ono (téměř proto, že je to zajisté proprietární věc, a pro standardizaci by bylo nutné mírně to zobecnit). Ostatně většina poskytovatelů ať si poskytuje co uzná za vhodné, já si vyberu takového, který tohle poskytovat bude. Resp. si to budu poskytovat sám, když bude k dispozici příslušný software. Jenom mi současné řešení zatím nevadí tolik, abych se sám pouštěl do psaní příslušného serveru i klienta – server bych si třeba i napsal, ale použitelný klient, který si poradí s kdejakým v HTML zpraseným e-mailem, nepatří k věcem, které bych toužil psát…
Zvlášť když se uživatel přihlašuje pokaždé jinde (jako třeba ve škole) – pak si buď musí index při každém přihlášení okopírovat ze sítě a při odhlášení zpětTo "ze sítě" tuším již dnes může znamenat z IMAP serveru, ne? Index bude proti všem mailům trapně malý, takže to ani nevadí. Navíc nemusí být "fyzicky" vcelku, takže se zpátky nemusí nahrát celý, ale jen rozdíl (a jednou za čas to slít vše dohromady). Stejně je myšlenka serverového vyhledávání podle mě trochu mimo, páč přecejen ideálem pro mě je všechna pošta šifrovaná.
To "ze sítě" tuším již dnes může znamenat z IMAP serveru, ne?Možná pro PINE, o něm se většinou tvrdí, že umí s IMAPem všechno
Ale pochybuji o tom, že by ten index byl přenositelný mezi různými klienty.
Index bude proti všem mailům trapně malý, takže to ani nevadí.Pro gigové schránky už to nějakých pár desítek mega bude.
Stejně je myšlenka serverového vyhledávání podle mě trochu mimo, páč přecejen ideálem pro mě je všechna pošta šifrovaná.To ale zároveň znamená přístup k poště jen z jednoho míst anebo několika málo míst. Pak vám samozřejmě lokální uložení pošty nemusí vadit. Někdo jiný ale zase chce mít poštu dostupnou odkudkoli se stejným komfortem, a nešifrovaná data na serveru mu nevadí. Dnes existuje jediná možnost, jak tohle zařídit – webové rozhraní. A to zrovna ten nejkomfortnější styl práce. Navíc i to fulltextové vyhledávání by šlo zařídit tak, že klient e-mail rozšifruje, vytvoří z něj seznam slov a ten pošle zpátky na server pro zařazení do indexu. Sice by pak na serveru bylo možné zjistit, jaká slova v e-mailu byla, ale už by nešlo získat přesnou podobu e-mailu.
).
Mít seznam slov z mailu díky nešifrovanému indexu je podle mě až moc. Navíc to předpokládá, že index nebo jeho části si budou klient a server nějak standardizovaně vyměňovat (což jsem teda požadoval i já, ale bylo mi to předloženo jako nevýhoda ).
Ono navíc ne všude, kde si chci přečíst mail nebo ho napsat, musím nutně chtít i vyhledávat, spíš bych řekl, že to se děje ve velké menšině případů, takže zdaleka ne vždy by se musel index mezi serverem a klientem přenášet.
20.10.2007 19:58
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
20.10.2007 20:02
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
.
20.10.2007 20:00
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
20.10.2007 20:19
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
) zacházet jako s plnohodnotným emailem, potřebuji je jen někam uložit, hlavně smazat ty soubory z disku (už jsou týden pryč) a následně nad nimi vyhledávat. Takže ani email server, ani klient. Prohlížeč.
bych zkusil nejaky virtual maildir filesystem pro fuse
Je to v plánu. Mám pocit, že už někdo nad fuse psal FS s daty v MySQL, ale tvrdil, že to bylo pomalé.
Jestli nechces klienta, ktery si indexuje hlavicky...
Jediná cesta je to napsat sám. Klientů jsem vyzkoušel hodně. Dal jsem na rady všech okolo, "tenhle je nejrychlejší, zkus ho". Možná byl. Pro prvních 30 000 mailů. Jediný kdo zvládal tehdy 400 000 emailů byl KMail, nad maildirem* a pop3. TB nad IMAPem je nepoužitelný. TB je vcelku nepoužitelný
*) jako on to není špatný způsob ukládání, přístup k jednotlivým emailům je rychlý, spousta metadat je ve jménu souboru a když se použije velikost bloku 512B, tak to nezabírá ani moc místa. Jenže zkuste si ty soubory pak zkopírovat. Nedočkáte se.
sqlite
Nevím proč, ale k podobným knihovnám mám averzi. Nechápu, proč nepoužít rovnou server. Výkonnostně si polepším.
Je to v plánu. Mám pocit, že už někdo nad fuse psal FS s daty v MySQL, ale tvrdil, že to bylo pomalé.FS nad databazi samozrejme bude mit bezne operce velmi pomale, ale pro specialni pripad, kdy budou pozadovane specialni operace by to nemuselo byt tak spatne. obecne Je problem s rychlosti cteni/zapis. Tam je asi nejlepsi reseni pouzit FS, ktery umi zpracovat mnoho souboru a stejne je ukladat na nem, ale ne vsechny v jednom adresari, ale radeji nejaky squid styl.
Jediná cesta je to napsat sám. Klientů jsem vyzkoušel hodně. Dal jsem na rady všech okolo, "tenhle je nejrychlejší, zkus ho". Možná byl. Pro prvních 30 000 mailů. Jediný kdo zvládal tehdy 400 000 emailů byl KMail, nad maildirem a pop3. TB nad IMAPem je nepoužitelný. TB je vcelku nepoužitelnýTo by mne hlavne zajimalo, jake nejcastejsi a casove kriticke operace se s temi 400k maily delaji a jestli jsou treba tridene a podobne. Protoze ja sice mam radove 100k mailu, ale vetsina jich je bokem, protoze mne zajimaji jednou za nekolik uherskych let.
Nevím proč, ale k podobným knihovnám mám averzi. Nechápu, proč nepoužít rovnou server. Výkonnostně si polepším.Protoze sqlite databaze se dobre prenasi a pro jednoduche veci ala INSERT/SELECT bohate staci a napr driver v QT4 je univarzalni nezavisle na platforme. Pokud chci neco robustniho a sloziteho, tak to samozrejme radeji vrazim do postgresu (vcetne toho, ze je tam vestaveny velmi slusny fulltext)
Tiskni
Sdílej:
20.10.2007 18:49