Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Svobodný nemocniční informační systém GNU Health Hospital Information System (HIS) (Wikipedie) byl vydán ve verzi 5.0 (Mastodon).
Tento blog obsahuje nebezpečnou symboliku.
Dnes mi Jindra Plešinger připomněl svým blogpostem o kontrole pravopisu moji dlouhodobou myšlenku.
Používám prostředí KDE a líbí se mi, že se snaží vše provázat. O co se jedná? Jednotný systém kontaktů, který využívá KMail i kopette (to mám z druhé ruky, sám používám PSI). Kparts (např. textový editor Kate v okně zcela jiného programu, nebo kpdf v okně prohlížeče webu), beru skoro jako samozřejmost. Ještě to není dokonalé, snad v dalších versích.
Co takhle jít dál? V KMymoney mám seznam plátců, který není synchronizovaný s kontakty. Nebylo by hezké se mrknout na plátce, kterým vám dluží, rovnou z KMymoney mu napsat email, nebo poslat IM zprávu? Kolekci amaroKu mám v MySQL databasi. Tak proč ne všechny emaily, kontakty, historii IM komunikace a třeba i správu versí dokumentů? Tohle všechno využívám, jen odděleně. Subversion támhle, db kontaktů interní KDE, emaily v mail diru (a je požitek jich mít 100 000*) a historie PSI je ve vlastním formátu, který sice jde "snadno" rozparsovat, ale to se dá říct prakticky o všem.
Pokusil jsem se něco takového navrhnout sám (v freemindu je to pěkná mapa), ale je to nad mé síly. Chci se zeptat, neexistuje něco takového? Prosím, odkazy na MS Office si nechte, hledám něco FOSS a ani ty office to nemají dotažené do konce.
Celé by to bylo postavené na otevřených formátech, o data by se starala volitelná SQL database (snad není takový problém zajistit obecnou kompatibilitu na úrovni SQL příkazů). To znamená, že by nebyl problém se připojit přes šifrovanou linku odkudkoliv a mít tak svá data neustále při sobě.
*) Dávat to sem je trochu OT, ale nechci zakládat další blog. To opravdu neexistuje klient nebo systém, který by to zvládl? Pro MS Outlook (a prosím, nechci flame), nebyl problém mít 30 000 emailů v jedné složce. Outlook používal vlastní DB emailů a podle mého názoru, to dělal dobře. Na linuxu jsem našel jen mailbox (hmm 3GB textový soubor, co takhle smazat 15 emailů na začátku?), maildir nebo mb (co email, to soubor -- čímž se problém přesouvá na filesystém a nenašel jsem takový, který by to rozumně zvládal). Jak tohle řeší seznam, gmail a podobní? Vždyť ti se musejí postarat o miliardy emailů.
Tiskni
Sdílej:
No, nad niečím podobným som už tiež istý čas uvažoval. Žiaľ, stále ostávam pri tom "chcel by som..." Jednoducho neexistuje nič, čo by mi úplne vyhovovalo.
Btw - nie je jeden z "propagačných bodov" Linuxu aj to, že máme slobodu voľby? V takom prípade môžeme o integrovanom systéme len snívať ;)
Jak tu tu sleduji, tak se mi tahle myšlenka stále honí hlavou, přispěji tedy také svou troškou myšlenek. Nějaká db na netu, případně aplikace ji obhospodařující, je asi nezbytná, ale z důvodu offline bude asi stejně potřeba, aby si data spravovala aplikace sama a do db se data pouze replikovala. Co to tedy udělat nějak takto:
1. Klientská aplikace (démon), do které se nainstalují pluginy pro konkrétní programy (im, mail, atp.), s možností spouštět jako samostatný program s parametry.
2a. Spousta existujících aplikací umožňuje spustit nějaký program při nějaké akci (třeba příchod mailu). Spustí tedy daný plugin a předá parametry specifikující co je to za akci.
2b. Pokud není možné předchozí a existuje jednoduchý způsob, jak k dané aplikaci plugin udělat, tak udělat.
2c. Pokud předchozí nebude snadno zrealizovatelné, tak démon na základě pluginu bude v definovaném intervalu zkoušet sám zjistit změny v aplikaci (třeba změna v logu im, přečte změnu a provede kýžené)
3. Démon už ví, že se něco změnilo, projde nastavení, jestli na danou změnu má něco udělat
4. Vykoná zvolené (spustí mail klient s parametry - o to se postara plugin pro daného klienta)
5. Vše se pokouší replikovat na server
Pokud třeba nebudu mít doma nainstalovaný program, odpovídající nějaké akci, tak na server uloží status o nevykonané akci. Když pak přijdu do kanceláře, démon zjistí neprovedenou akci, ověří že on pro danou akci program (plugin) má, tak akci provede nyní.Úmyslně teď neřeším pracovní skupiny a sdílení dat. Data na serveru by mohla být pro jednotlivé programy ukládána v xml, to by mohlo být snad dostatečně univerzální. Konfigurace by se taktéž replikovala na server, ale s rozlišením různých pracovišť s informací o pluginech a klientech na nich.
Co by tedy bylo potřeba:
1. Definovat strukturu DB
2. Framework pro webovou aplikaci - s jasně definovaným API pro pluginy
3. Základ webové aplikace pro nastavování
4. Základní pluginy na webu pro mail, im, kalendář (včetně rozlišení nejpoužívanějších aplikací
5. Klientský démon a pluginy pro něj s jednoduchým návodem k danému programu
Každý program by tedy potřeboval plugin pro démona, plugin do sebe nebo specifikaci jako propojit s démonem, specifikaci xml do db, plugin na web pro konfiguraci akci atp.
Jo a hlavně pořádnou analýzu a hodně času
Uff, jsem se rozepsal.... mno prostě pár myšlenek
Vím, že tu jsou ještě asi další dva lidi z Opavy, tak se můžeme někdy domluvit a jít si někam sednout..To muzem
Rozumím. No já mám slíbený nocleh od teroristy, ale jak to dopadne ... to nikdo neví.