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 »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
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)
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
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ýchDalší 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: