Win8DE je desktopové prostředí pro Wayland, inspirované nechvalně proslulým uživatelským rozhraním Metro z Windows 8. Nabízí dlaždicové rozhraní s velkými tlačítky a jednoduchou navigací, optimalizované pro dotyková zařízení. Cílem projektu je přetvořit design operačního systému Windows 8 do funkčního a minimalistického rozhraní vhodného pro každodenní použití na Linuxu.
Laboratoře CZ.NIC vydaly Datovku 4.28.0 a Mobilní Datovku 2.6.0. Hlavní novinkou je ukládání rozpracovaných datových zpráv do konceptů. Datovka je svobodné multiplatformní aplikace pro přístup k datovým schránkám a k trvalému uchovávání datových zpráv v lokální databázi.
Unix Pipe Game je vzdělávací karetní hra zaměřená na děti a rodiče, která děti učí používat unixové příkazy prostřednictvím interaktivních úkolů. Klíčovým prvkem hry je využití symbolu | pro pipeline neboli 'rouru', který umožňuje propojit výstupy a vstupy jednotlivých unixových příkazů, v tomto případě vytištěných na kartičkách. Předpokládá se, že rodič má alespoň nějaké povědomí o unixových příkazech a jejich provazování pomocí |.
… více »PCIem je linuxový framework, který vytváří virtuální zařízení PCIe pomocí technik, které umožňují hostitelskému operačnímu systému rozpoznat tyto syntetické 'neexistující' karty jako fyzické zařízení přítomné na sběrnici. Framework PCIem je primárně zamýšlen jako pomůcka pro vývoj a testování ovladačů bez nutnosti použít skutečný hardware. Dle tvrzení projektu si fungování PCIem můžeme představit jako MITM (Man-in-the-Middle), který se nachází mezi ovladači a kernelem.
Byla nalezena vážná bezpečnostní chyba v telnetd z balíčku GNU InetUtils. Týká se verzí GNU InetUtils od 1.9.3 z 12. května 2015 až po aktuální 2.7 z 14. prosince 2025. Útočník může obejít autentizaci a získat root přístup, jelikož telnetd nekontroluje předaný obsah proměnné prostředí USER a pokud obsahuje "-f root"…
Stanislav Aleksandrov předložil patch rozšiřující KWin (KDE Plasma) na 3D virtuální desktopové prostředí (videoukázka v mp4).
Digg (Wikipedie), "místo, kde můžete sdílet a objevovat to nejlepší z internetu – a nejen to", je zpět. Ve veřejné betě.
Po .deb balíčcích Mozilla nově poskytuje také .rpm balíčky Firefoxu Nightly.
Vývojové prostředí IntelliJ IDEA slaví 25. narozeniny (YouTube).
Vedení společnosti NVIDIA údajně povolilo použití milionů knih ze známého 'warez' archivu Anna's Archive k výcviku umělé inteligence, ačkoliv vědělo, že archiv tyto knihy nezískal legální cestou. Žaloba, ve které se objevují i citace interních dokumentů společnosti NVIDIA, tvrdí, že NVIDIA přímo kontaktovala Anna's Archive a požadovala vysokorychlostní přístup k datům knihovny.
Skupina zaměřená na koordinaci a shromažďování informací prospěšných projektu Multiplatformní přístup pro datové schránky.
| Založena: | 5. 10. 2009 |
| Členů: | 26 |
| Článků: | 0 |
| Wiki stránek: | 7 |
| Dotazů: | 22 |
| Akcí: | 0 |
| Čtenost: | 28 % |
| Skóre: | 19 |
Potřeboval bych, aby se vývojáři dohodli na minimální množině podporovaných způsobů, jak ukládat zprávy do místních souborů a jak je z nich opět nahrávat do aplikace.
Když se omezím na zprávy, tak z ISDS lze dostat zprávu v CMS (nástupce PKCS#7) a pak ještě nepodepsanou přijatou jako čisté XML.
Uložení zprávy v CMS (tedy i s podpisem) má rozhodně smysl. Minimálně 602XML Filler tento formát umí, protože tak to leze z interaktivního webového rozhraní.
Pro čistou XML zprávu pak je rozhodně nutností uložit podstrom dmReturnedMessage (XSD typ tReturnedMessage), protože ten obsahuje „všechny“ informace (kromě událostí z doručenky).
Na druhou stranu data v CMS a data odpovědi na stažení nepodepsané zprávy neobsahují jen tento podstrom, ale obalují jej do MessageDownloadResponse (typ tMessDownOutput), který si s sebou táhne i dmStatus, na který rozhodně třetí strana není vůbec zvědavá. Navíc mi přijde, že tento zakuklenec je poplatný webovým službám ISDS (jako kdybychom se soubory staženými z webu uchovávali i HTTP hlavičky).
Pro zachování „zbytečné“ obálky MessageDownloadResponse zase hraje fakt, že přesně toto je uvnitř CMS, takže se pro programátora stává věc jednodušší.
Do hry vstupuje ještě „třetí“ formát, kdy se uživatel pokusí exportovat podepsanou zprávu z CMS do čistého XML, ale stále s původním jmenným prostorem podepsaných zpráv. To určitě budou lidi chtít, protože se nebudou chtít trápit s vybalováním CMS pro externí nástroje. Tento třetí formát by byl totožný s nepodepsanou zprávou (až na jmenný prostor), když by se ukládala obalená v MessageDownloadResponse.
Nakonec tu je čtvrtý formát definovaný výrobci spisových služeb, který je šířen spolu s dokumentací ISDS ve čtvrté příloze. Ten je ale dle mého názoru pro běžné uživatele vhodný asi jako pověstný kanón na vrabce.
Další data, která bude třeba archivovat, jsou doručenky. Ty jsou opět v CMS a jako čisté XML. A tu je stejný problém.
Jak to vydítě vy? Chtěl bych tímto zajistit kompatibilitu jednotlivých řešení a ušetřit si zbytečnou práci :)
Jednotné formáty klidně. Jednotné API těžko.
Za prvé máte různé jazyky s různými standardními knihovnami (třeba v céčku není ani standardní funkce na spojované seznamy), za druhé různé implementace mají různý přístup (někdo kvůli paralelizaci a malé paměti používá SAX, systém zpětných volání a asynchronní přístup; někdo chce vysoký výkon, ale nestará se o paměť, a tak v ní drží všechno) a nakonec standardní API se dělá, když chce někdo nahradit jednu zavedenou knihovnu jinou, přičemž problém je jasně definovaný a prakticky neměnný (třeba zpracování JPEGu), což rozhodně není příklad ISDS, který se neustále mění.
Tak třeba moje knihovna takovou funkci vůbec nemá, protože nemůžu vědět, co bude chtít aplikace se zprávou dělat.
Já to mám na nižší úrovni – funkce vrátí datovou strukturu z níž si aplikace může vyzobnout zprávu co by ukazatel na buffer. Jestli ji aplikace bude ukládat do souboru, tisknout, odesílat e-mailem nebo ověřovat digitální podpis, je opravdu jen na ní.
Nevylučuji, že nějaké obálky pro časté konstrukce dodělám, ale zatím jsem to nepovažoval za nutné. Na druhou stranu součástí zdrojových kódů jsou ukázkové způsoby použití a často opakované postupy tam jsou také vyčleněny do samostatného souboru (ukládání/načítání bufferu do/ze souboru, výpis datových struktur knihovny, řetězcová reprezentace výčtových typů). Takže to tam svým způsobem mám, ale nijak exaktně a systematicky.
Navíc si myslím, že potřeba a přínos takových komplexních volání se ukáže až s implementací plného klienta. A jsem moc líný psát, testovat a udržovat kód, který by nakonec nikdo nepoužíval.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
28.1.2010 17:30