Squeak (Wikipedie), open source implementace programovacího jazyka a prostředí Smalltalk, byl vydán ve verzi 6.1. Přehled novinek v poznámkách k vydání.
V Linuxu v KVM byla nalezena a v upstreamu již byla opravena kritická zranitelnost Zapscape aneb CVE-2026-64561. Root na hostovaném počítači (virtuální stroj) může obejít izolaci a získat plnou kontrolu nad hostitelským systémem (DoS útok nebo vzdálené spuštění kódu s právy roota). Na obou hlavních architekturách – Intel i AMD. Zranitelnost v Linuxu existovala 6 let (od července 2020 do července 2026).
Počítačová hra Knytt napsaná v Multimedia Fusion 2 byla vydána před 20 lety. Při této příležitosti byl dnes představen moderní port (YouTube) této plošinovky na současné operační systémy pod názvem Knytt Classic. Je zdarma k dispozici na Steamu a GOG.com.
Americká technologická společnost Meta Platforms představila nový model umělé inteligence (AI) Muse Glimmer. Model je menší než přední modely AI od konkurence a má běžet přímo na počítačích uživatelů. Meta model zpřístupní jako open source, tedy otevřený software. Nový model je navržen tak, aby zvládal takzvané agentní úkoly na počítačích se spotřebitelskou grafickou kartou. Klade si tak za cíl uspokojit poptávku po systémech AI, které běží přímo na zařízeních uživatelů.
V pátek 28. srpna 2026 se v pražském Karlíně uskuteční již osmý Mobilní Hackday. Akce začne v 10:00 a potrvá až do večera. Setkání proběhne v prostorách SUSE Linux, s.r.o. na adrese Křižíkova 148/34, Praha 8 – Karlín. Nejbližší zastávkou je Křižíkova, kam se lze dostat tramvají i metrem. Na programu budou například novinky z posledních měsíců, možnosti, jak si zjednodušit práci s LLM/AI, a také nová linuxová distribuce BengalOS, včetně … více »
Jakub Vrána vydal Adminer ve verzi 6.0.0 s více než 130 změnami: "Většina změn vznikla s asistencí Claude Opus 5. Někteří lidi se bojí, že AI asistence může kód zamořit technickým dluhem. To je jistě pravda, pokud vývojář všechny změny bezduše odbouchne Enterem. Ale pokud si pořádně projde plán, vyjedná v něm změny a pak totéž udělá i s vygenerovaným kódem, kvalita kódu stoupne a technický dluh naopak klesne. Je to jako párové programování s
… více »Sam Aaron vydal novou major verzi 5.0.0 aplikace Sonic Pi (Wikipedie) určené také pro výuku programování pomocí skládání hudby. Přehled novinek na GitHubu. Instalovat lze také z Flathubu.
U příležitosti 30. výročí vydání počítačové hry Quake byla vydána nová epizoda s názvem Dawn of the Machine (Steam).
Vládní CERT upozorňuje (𝕏) na sérii bezpečnostních záplat (CVSS 9.9) v produktech Cisco řešících kritické zranitelnosti umožňující obejití autentizace, eskalaci oprávnění, vzdálené spuštění kódu a odepření služby. Úspěšné zneužití může útočníkům umožnit získat neoprávněný přístup k dotčeným systémům, kompromitovat zařízení Cisco Catalyst SD-WAN a Cisco IOS XE, spustit libovolný kód, zpřístupnit citlivé informace nebo narušit dostupnost postižených systémů.
Soud v americkém státě Nové Mexiko ve čtvrtek nařídil internetové společnosti Meta Platforms zaplatit 567 milionů dolarů (téměř 12 miliard Kč) za újmy, které její platformy působí mladým lidem. S přihlédnutím k dřívějšímu verdiktu tak má společnost celkem zaplatit 942 milionů dolarů, což je malý zlomek jejího ročního výnosu, který loni činil 60 miliard dolarů. Čtvrteční verdikt firmě také nařizuje, aby změnila způsob, jakým její
… více »Ta jedna, "moje", by předělatelná byla, ale neumím v LO udělat makra co dělají teď to co dělá excel. Zkoušel jsem si jedno přepsat do LO, strávil nad tím asi 3 hodiny a vzdal to. Teoreticky to určitě půjde, ale makra v LO mi přijdou těžší než to celé předělat do PostgreSQL a všechny funkce co teď dělají makra zbastlit v PHP.
Ta druhá netuším , tu spravuje kolega, a ten masivně a často generuje spousty grafů a pivotů pomocí toho náhledu co v LO Calcu vůbec nejsou. Pivoty sice LO umí, ale člově musí přesně vědět, co chce dát do řádků, sloupců atd. a celé to pak musí dělat znovu když to nevyjde. Excel to má velmi komfortní: metodou pokus omyl člověk zkouší co ho napadne, hned vidí náhled a potvrdí to až vidí v náhledu to co vidět chtěl. Pokud vím tak podpora pivotů v OpenOffice byla minimálně do roku 2010 tragická (max 8 polí kvůli pitomému omezení v UI) a fixnuté to bylo až v LO v roce 2010 (https://lists.freedesktop.org/archives/libreoffice/2010-December/004781.html), kdy a jestli to už je opravené i v OO netuším. NAvíc kolega není vůbec ochotný se přeučovat to co umí v Excelu na LO tj. ten si bude reporty dělat v Excelu dál a není nikdo kdo by mu mohl nařídit ať přejde na LO (aniž by odešel jinam :))
NAvíc kolega není vůbec ochotný se přeučovat to co umí v Excelu na LOAha, takže tady je jádro pudla. Myslím, že byste měli do variant započítat ještě výměnu kolegy za takového, co není línej se učit nové věci.
Myslím, že byste měli do variant započítat ještě výměnu kolegy za takového, co není línej se učit nové věci.Ano, tento risk je hodně vysoký z pohledu businessu, takže by určitě měl být započítaný (vedení firem mívají ráda Risk Matrix - pak stačí každou kategorii ohodnotit číslem a vynásobit, abychom získali reálnou finanční hodnotu a vedení vidělo to obrovské číslo, které firmu může často kompletně položit).
Databázi teď zkouším dělat v PostgreSQL a experimentuji i s napojením na ni přes LO Base, ale bez pořádné aplikační vrstvy - kterou musí někdo napsat - řešení přes LO Base formuláře a dotazy je jen na hodně specifické use cases.
Kolega co dělá různé účetní reporty není programátor, v Excelu umí poskládat vše přes různé kontingenční tabulky co potřebuje on i vedení firmy, na pár kliků udělá grafy atd. Pár dalších lidí do toho chce lézt taky a opět - graf a filtr v excelu udělají, SQL dotaz ne. Co vidím reálné je mít data třeba v tom PostgreSQL a propojit to s Excelem přes PowerPivot, tj tou aplikací bude právě ten Excel a ty reporty a grafy atd se budou dynamicky aktualizovat podle toho co přibyde v databázi...
Resp. v případě dat z Pohody by se jednalo o napojení Excelu a PowerPivotů rovnou na ten MSSQL server kde leží ta databáze Pohody. Akorát bychom museli porozumět datovému modelu co používá Stormware a poskládat si pohledy tak jak potřebujeme pro ty naše sestavy.
věci co se týkají objednávek přes eshop B2B i B2C si můžeme nechat udělat přímo od dodavatele eshopu,ale spousta reportů neleze jen z eshopu, ale i prodejních akcí aj. zdrojů.
Kolega co dělá různé účetní reporty není programátor, v Excelu umí poskládat vše přes různé kontingenční tabulky co potřebuje on i vedení firmy, na pár kliků udělá grafy atd
Již snad za rok bychom měli jít s kůží na "ten větší" trhTakže se přecejen věci začínají hýbat... :)
Když už je hodně přesně specifikované z jakých vstupů mají být jaké výstupy a je to stabilní a požadovaný report, tak dedikovaná aplikace je fajn, ale tady jde o firmu, kde není nic jisté a zatím skoro všechny požadavky zadané na funkčnost eshopu aj. systémů co se za dost peněz implementovaly, se nakonec musely neustále doplňovat a měnit a řada z nich se brzy přestala používat atd... tedy když firma nemá ještě jasno v tom co chce, tak z nejasných nebo nesmyslných požadavků lezou drahá a neužitečná řešení. Opravit si podomácku pár vzorců v excelu nebo makro v tomto prostě dělá lepší službu, byť samozřejmě systémovější je aby firma měla v procesech a požadavcích jasněji. Otázka jestli to u rostoucí, "bleeding edge" firmy s rychlým růstem kdy požadavky před rokem byly úplně jiné než požadavky dnes, jde dělat nějaké pevné systémy co už za pár měsíců možná budou svazovat.
Otázka jestli to u rostoucí, "bleeding edge" firmy s rychlým růstem kdy požadavky před rokem byly úplně jiné než požadavky dnes, jde dělat nějaké pevné systémy co už za pár měsíců možná budou svazovat.Za rok bych Vám řekl, že se rozhodně vyplatí postavit a měnit systém a odkázal Vás na počin, na který jsem si udělal malou reklamu v příspěvku výše (tento počin mj. přímo nabádá k neustálému vývoji požadavků - klidně měnících se každý den). Ale aktuálně to je o mnoho svízelnější, takže souhlas, Excel to řeší.
Tak třeba formuláře jsou bezva, ale efektivní práce s výslednými tabulkami? Nebo jakýmikoli většími tabulkami kde je v buňce hodně textu? Zpracování importních CSV pro eshop kde je v buňkách HTML kód? Uf. Když mám v buňce 2 stránky textu, jak buňku zmenším, aby se mi vůbec vešla na výšku stránky? Pro lidi co chtějí vést pokladní knihu OK, ale mám tolik use cases kde jsou Google tabulky naprosté peklo a Libreoffice calc naprostý luxus, že fakt díky, ne. O problémech když do G Drive naimportuju soubor v XLSX nebo ODS a Google ho po otevření přeuloží do nového formátu pro editaci, se stejným jménem jako ten původní soubor, a nemožnosti tohle synchronizovat s počítačem, nemluvě. Na Google (G Suite) jsme chtěli přejít ale spíš kvůli mailům a kalendářům, na sdílení souborů jsem se postavil docela proti Google Drivu, Google docs jsou skvělé na kolaborativní editaci nebo korektury textů apod., ale opět - nesmí se tam chtít nějaká interoperabilita s Excelem nebo LO Calc. Naučit lidi aby pochopili google koncept více souborů stejného jména v jedné složce, a vytváření klonů importovaného souboru každým otevřením, a drželi striktní disciplínu a zabraňovali vlastním tělem aby se tohle dělo... nemožné.
BTW synchronizační klient na G Drive pro Linux, na rozdíl od Dropboxu nebo ownCloudu neexistuje. Různá obskurní 3rd party řešení zkouším už pár let a je to úplně naprd. Zažil jsem i masivní ztrátu složek v G Drivu, resp. soubory šly vyhledat, ale nebyly v žádné složce a nešly nijak obnovit. Proti tomu Dropbox, nebo ownCloud na němž už několik let firma jede (před pár lety jsem to už málem chtěl zabalit kvůli kritickým bugům typu race conditions u Qt < 5.2 v kombinaci s SSL, což vedlo k poškozování náhodně některých souborů při importu), je to z mých zkušeností spolehlivější než ten Google.
Mnohem radši podpořím Office365 a data v OOXML na OneDrivu, tam je aspoň rozumně fungující kompatibilita mezi online verzí a desktopovými aplikacemi a funguje i synchronizace.
Když neuvažuji zjevné věci jako skoro nekompatibilní makra a nemožnost rozumně v LO makra nahrávat (pracuji často tak že nahraju makroa pak ručně zjednodušuju makra a zobecňuju, je topro mě rychlejší než vše psát zgruntu, nejsem programátor), tak u tabulek je problém se vzorci, kdy v excelu používané pojmenované buňky a rozsahy mi LO často nespolkne a nevím co přesně ještě jde a co ne. Potom Excel zase nespolkne vzorce z LO když hlásí že tam jsou použité regulární výrazy (nevím o tom, že by ve vzorci byly, ale Excel zobrazí jen hodnoty a vzorce zahodí). Katastrofálně dopadá když MS office otevře OpenDocument Text z Writeru, zahodí obrázky na pozadí, záhlaví, zápatí a v podstatě se vizuální styl dokumentu úplně rozpadne, opětovné uložení způsobí dokument který je k zahození. Uložit v LO do docx a to otevřít ve Wordu je naopak celkem OK. Tedy mnohem horší kompatibilita je ze strany MS Office vůči OpenDocumentu, než ze strany Libreoffice vůči OOXML.
Ale i tak STYLY odstavců, znaků jsou katastrofa v obou směrech. Word generuje spoustu stylů co uživatel nikdy explicitně nevytvořil, a ve Writeru pak je seznam stylů zaspamovaný kravinami. Word IMHO moc nepodporuje styly stránek a styly odsazení, nebo podporuje to úplně jinak. Obecně dokument co má jen nadpis 1,2,3 a obyč text tak tam je to jedno. U velmi pečlivě vyttvořeného dokumenty se styly, obsahem, záhlavím zápatím obrázkem na pozadí atd. už je ztráta byť běžným uživatelům mnohdy skoro neviditelná, dost velká a pro mě neakceptovatelná. U Excelu moc nechápu jak fungují a jestli pořádně vůbec fungují styly tak jako ve Wordu. LO Calc umí relativně kvalitně styly i v rámci Calcu, Excel tohle proti tomu IMHO dost prasí (bavím se o verzi 2013 standalone, nevím jak to je u 2016)
Prostě soubor by se měl otevírat v aplikací, ve které byl vytvořen a ideálně v té samé verzi. Pokud jedno z toho porušíte, musíte očekávat problémy.
Díky za postřehy.
Ten postřeh o migraci všech stávajících Opendocumentů do OOXML je zásadní a vůbec si nedovedu představit jak to realizovat. Jiné složité tabulky a stovky ne-li tisíce dokumentů existují v ODS/ODT. Tabulky v ODS jsou naprosto nekompatibilní s Excelem. Jak se vůbec dá spočítat nákladnost takové migrace, pokud vlastně daný dokument ani když ho v LO uložím do xlsx nedokážu v Excelu otevřít aniž bych o všechny vzorce na nichž jsou desítky hodin práce a testování, přišel?
Nemluvě o spoustě ODT souborů které mnohdy jsou dělané v LO Writeru namísto plnohodnotného DTP typu Indesign či Scribus, a je na nich zásadní přesný vzhled. Tj. pro otevření je nutný LO plus všechny potřebné fonty. Automatizovaná bezztrátová migrace do Wordu opět nemožná.
JJ SoftMaker Office je fajn, sam jsem si jej koupil i na doma. Jedine co me mrzi je ze je treba kupovat zvlast licenci na Windows a Linux, ale casto maji slevy, takze pro uzivatele co vlastni Linux verzi je cena za Windows verzi treba i polovicni.
proškolit lidi může být dražší než předplácet Office365 nebo koupit krabice/multilicenci MSOa proškolení na MSO je zdarma???
Excel to má velmi komfortní: metodou pokus omyl člověk zkouší co ho napadne, hned vidí náhled a potvrdí to až vidí v náhledu to co vidět chtěl.To by sa potom dalo danu vec rovno vytvorit podla toho, co vidiet chcem
. (Ale jasne, chapem, ze to bolo myslene inac, len som si nemohol odpustit drobne rypnutie.)
Z textu jsem pochopil, že kritické tabulky jsou dvě a obě se nějak tvoří pomocí maker. Z čeho? Je to nějaký výstup z toho účetnictví nebo cosi z éšopů? Pokud se to dělá makry budou to nějaké víceméně statické reporty, které by třeba mohli dobastlit ti hoši od pohody (nebo co to je).
Pokud nee, dají se data asi dostat přímo z databáze, OpenOpice i následovníci spolupracují s JDBC velmi dobře a obsahy tabulek se dají zjistit metodou pokus-omyl ("select * from tabulka" a většina jich bude prázdných
).Další možnost se jmenuje Business inteligence, což je trochu vyšší level. Tady třeba:. Samozřejmě to má i M$ ale bude to stát peníze. Výhoda ale je, že to ty reporty s obrázkami plive skoro samo.
ZDAR!V první řadě bych začal analýzou reálných (byznys) potřeb firmy a jejích procesů + optimalizací. A až pak vybíral správný nástroj. Stavět IS na kancelářském1balíku a pár2 jednotlivcích, kteří v něm píší jakási makra, není moc dobrý nápad (hodně silný eufemismus).
[1] a ještě k tomu proprietárním
[2] kolik dalších lidí tomu rozumí a je schopno to udržovat?
A máš tam oddělená data (dají se zálohovat) od programu (dá se verzovat) tzn. logika a UI jsou zvlášť, má to nějaké API nebo si nad tím můžeš pouštět SQL dotazy.
Ta makra v Excelu v takove male firme "vyviji" treba nejaky ucetni...Budu rád, když mi do takové firmy zajistíte exkurzi.
Tiskni
Sdílej: