Byla vydána nová verze 4.8.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 142 (pdf) a HackSpace 79 (pdf).
Qtractor (Wikipedie) dospěl do verze 1.0.0. Jedná se o Audio/MIDI vícestopý sekvencer.
Byl vydán svobodný kancelářský balík OnlyOffice Docs 8.1. Vedle četných oprav přináší několik funkcí včetně podpory editace textu v PDF a vytváření formulářů v PDF.
Daniel Stenberg, autor nástroje curl, z databáze SteamDB zjistil, že aktuálně 22 734 her na Steamu používá curl.
Společnost Anthropic vydala Claude 3.5 Sonnet, tj. novou verzi své umělé inteligence Claude (Wikipedie). Videoukázky na YouTube. S Claude 3, stejně jak s GPT-3.5, Llama 3 a Mixtral, si lze pokecat bez přihlašování na DuckDuckGo AI Chat.
Byla vydána nová stabilní verze 6.8 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 126. Přehled novinek i s náhledy v příspěvku na blogu a na YouTube. Vypíchnuta jsou vylepšení v integrovaném poštovním klientu.
Příspěvek Aukce domén – měsíc po spuštění na blogu CZ.NIC shrnuje první měsíc provozu Aukce domén .CZ. Aukcemi prošlo celkem 18 174 domén, z toho na 742 z nich byl učiněn alespoň 1 příhoz. Nejdražší aukcí byla na doménu virtualnisidlo.cz s cenou 95 001 Kč, která však nebyla včas uhrazena. Nejdražší aukcí, která byla vydražena i zaplacena je praguecityline.cz s cenovkou 55 600 Kč.
Před 40 lety, 19. června 1984, Bob Scheifler představil první verzi okenního systému X (X Window System). Vycházela z okenního systému W (W Window System).
Desktopové prostředí MATE bylo vydáno ve verzi 1.28. V gitových repozitářích je sice už od února, ale oznámení vydání se na webu objevilo s několikaměsíčním zpožděním (únorové datum zveřejnění je nepravdivé). Jde o první velké vydání od roku 2021. Uživatelsky nejvýznamnější pokrok je v podpoře Waylandu.
Dufam ze sa v niektorej z buducich casti bude riesit aj sposob antispamoveho riesenia.Ano, ale ještě to bohužel chvilku potrvá.
Toto řešení již bylo kdysi popsáno (v Poštovní server s virtuálními účty trochu jinak). Doufám, že se dočkáme i řešení přes LDAP
hosts = localhost dn = cn=ldapproxy,dc=domain,dc=tld dnpass = tajneheslo auth_bind = yes auth_bind_userdn = uid=%u,ou=users,o=%d,o=hosting,dc=domain,dc=tld ldap_version = 3 base = o=hosting,dc=domain,dc=tld scope = subtree user_attrs = mailMessageStore=home,mailQuotaSize=quota=maildir:storage user_filter = (&(objectClass=posixAccount)(objectClass=qmailUser)(mail=%u)(employeeType=mail)(description=active)) pass_attrs = mail=user pass_filter = (&(objectClass=posixAccount)(objectClass=qmailUser)(mail=%u)(employeeType=mail)(description=active)) user_global_uid = 1011 user_global_gid = 1011+ nastavení postfixu ve stylu:
domains_server_host = localhost domains_search_base = o=hosting,dc=domain,dc=tld domains_query_filter = (&(o=%s)(objectClass=organization)(description=active)) domains_result_attribute = o domains_scope = one domains_cache = no domains_bind = yes domains_bind_dn = cn=ldapproxy,dc=domain,dc=tld domains_bind_pw = tajneheslo domains_version = 3 aliases_server_host = localhost aliases_search_base = o=hosting,dc=domain,dc=tld aliases_query_filter = (&(objectClass=qmailUser)(mail=%s)(description=active)(employeeType=mail)) aliases_result_attribute = mailForwardingAddress aliases_scope = sub aliases_cache = no aliases_bind = yes aliases_bind_dn = cn=ldapproxy,dc=domain,dc=tld aliases_bind_pw = tajneheslo aliases_version = 3 accounts_server_host = localhost accounts_search_base = o=hosting,dc=domain,dc=tld accounts_query_filter = (&(objectClass=qmailUser)(mail=%s)(description=active)(employeeType=mail)) accounts_result_attribute = mailMessageStore accounts_result_format = %s/Maildir/ accounts_scope = sub accounts_cache = no accounts_bind = yes accounts_bind_dn = cn=ldapproxy,dc=domain,dc=tld accounts_bind_pw = tajneheslo accounts_version = 3 alternate_server_host = localhost alternate_search_base = o=hosting,dc=domain,dc=tld alternate_query_filter = (&(objectClass=qmailUser)(mailAlternateAddress=%s)(description=active)(employeeType=mail)) alternate_result_attribute = mailMessageStore alternate_result_format = %s/Maildir/ alternate_scope = sub alternate_cache = no alternate_bind = yes alternate_bind_dn = cn=ldapproxy,dc=domain,dc=tld alternate_bind_pw = tajneheslo alternate_version = 3 dovecot_destination_recipient_limit = 1 virtual_transport = dovecot
mydestinations
definujete lokální domény a ve virtualdomains
definujete virtuální domény. Kombinovat to můžete třeba pomocí aliasů. Důležité je pochopit ten základní princip, ono se to totiž ani moc netýká domén, jako účtů - lokální domény jsou určeny pro systémové účty, pošta se doručuje do "systémového" adresáře pro poštu konkrétního systémového uživatele. Virtuální domény jsou určeny pro virtuální (nesystémové) účty, doručování musí být explicitně nakonfigurováno (je nutné říci, jak z virtuálního účtu získat informace o úložišti e-mailů).
mydestination
, jestlize je tato promenna prazdana vse je ok. A posta chodi i na virtualni ucty.
Ulozeni informaci v prostych/hash souborech ma samozdrejme i svuj duvod, krome samozdrejme na prvni pohled horsi udrzovatelnosti (coz lze odbourat pomoci nekoli skriptu), ale prinaseji vyssi vykon zpracovani zprav.
Ono je sice moc pekne reseni(i na pohled napr.pro zakaznika) drzet informace o uctech v relacni DB (a to vcetne anti spam/vir reseni, forwardu ...), ale uvedovme si jak je tento proces narocny na DB, prichod jednoho emailu spousti pomerne narocnou proceduru a co teprve v pripade zpracovani i nejakou tu dekadu vetsiho poctu (1ky,10ky, 100ky tisic ), db permanentne pretizena, uzamykani tabulek ... apod. co horsi se muze stat nez, ze to DB nevydrzi a sesype se... problem
Videl jsem reseni prave na rozsahlych hash-mapach, ktere navic dokazalo rozlozit zatez na vice serveru, informace se skutecne udrzovaly v DB, nikoliv vsak informace nutne pro sluzby, ale info ze ktereho se generovali hash-mapy
Vyhoda byla v jiz zminene rychlosti, nezavislost na DB (i kdyz se DB zhroutila nic se nedelo, pouze clovek neni schopen pridat/upravit/smazat uzivatel,ale system jede dal), nastroje zajistujici tento chod meli samozdrejme web rozhrani, za kterym sedela "opice".
Takze bych nezatracoval textove soubory.
Ono je sice moc pekne reseni(i na pohled napr.pro zakaznika) drzet informace o uctech v relacni DB (a to vcetne anti spam/vir reseni, forwardu ...), ale uvedovme si jak je tento proces narocny na DB, prichod jednoho emailu spousti pomerne narocnou proceduru a co teprve v pripade zpracovani i nejakou tu dekadu vetsiho poctu (1ky,10ky, 100ky tisic ), db permanentne pretizena, uzamykani tabulek ... apod. co horsi se muze stat nez, ze to DB nevydrzi a sesype se... problemProblém to je, pokud se to špatně navrhne a/nebo realizuje. Databází může být více exemplářů (replikují se z jednoho zdroje) na samostatných strojích, ještě s on-line zálohováním (replikací) do geograficky vzdálené lokality. Například. Když něco uhnije, jede se dál. Problém s přetížením vzniká typicky při špatném návrhu DB.
Videl jsem reseni prave na rozsahlych hash-mapach, ktere navic dokazalo rozlozit zatez na vice serveru, informace se skutecne udrzovaly v DB, nikoliv vsak informace nutne pro sluzby, ale info ze ktereho se generovali hash-mapyJenže pokud se tam dějí změny, musí se to pořád všechno přegenerovávat znovu. I kvůli drobnosti, kdy se v DB updatuje jeden atribut v jediném řádku, se tady musí generovat celý obrovský soubor.
Takze bych nezatracoval textove soubory.Soubory nezatracuji, je vidím jejich místo tam, kde je málo dat a hlavně se málo mění. Pro uložení více dat vidím jako lepší řešení použít databázi.
Tiskni
Sdílej: