3D tiskárny Original Prusa MK4S (a MK4) v kombinaci s Prusamenty PLA a PETG mají mezinárodně uznávanou certifikaci UL 2904 GREENGUARD, která potvrzuje splnění přísných bezpečnostních standardů pro VOC a UFP.
Byla vydána verze R1/beta5 open source operačního systému Haiku (Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání.
Sovereign Tech Fund (Wikipedie), tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří Sambu částkou 688 800 eur.
Společnost OpenAI představila novou řadu svých AI modelů OpenAI o1 navržených tak, aby "strávily více času přemýšlením, než zareagují". Videoukázky na 𝕏 nebo YouTube.
Sailathon 24, tj. hackathon mobilního operačního systému Sailfish OS, proběhne od 27. do 30. září v Praze na Strahově ve školícím centru Silicon Hill.
Bylo vydáno Ubuntu 22.04.5 LTS, tj. páté opravné vydání Ubuntu 22.04 LTS s kódovým názvem Jammy Jellyfish. Stejně tak Kubuntu 22.04.5 LTS, Ubuntu Budgie 22.04.5 LTS, Ubuntu MATE 22.04.5 LTS, Lubuntu 22.04.5 LTS, Ubuntu Kylin 22.04.5 LTS, Ubuntu Studio 22.04.5 LTS a Xubuntu 22.04.5 LTS.
Byla publikována veřejná Výroční zpráva Bezpečnostní informační služby za rok 2023 (pdf).
Byla vydána nová verze 8.7 multiplatformní digitální pracovní stanice pro práci s audiem (DAW) Ardour. Přehled oprav, vylepšení a novinek v oficiálním oznámení.
Společnost Juno Computers prodávající počítače s předinstalovaným Linuxem má nově v nabídce linuxový tablet Juno Tab 3. Na výběr je Mobian Phosh, Ubuntu 24.04 (GNOME) a Kubuntu 24.04 (KDE Plasma). Cena začíná na 699 dolarech.
VirtualBox, tj. multiplatformní virtualizační software, byl vydán v nové verzi 7.1. Přehled novinek v Changelogu. Přináší modernizovaný vzhled a ovládání. Přepínat se lze mezi základním a rozšířeným uživatelským rozhraním. NAT nově podporuje IPv6. Linuxový hostitel a host mohou sdílet schránku na Waylandu.
Dělám ajťáka v menší české firmě, cca 25 lidí. Snažím se omezovat zbytečné přeplácení za licence komerčního softwaru, které reálně moc nepotřebujeme, ale samozřejmě nakupovat je, kdy není žádná rozumná náhrada. U účetního systému běžícího na Windows serveru moc náhradu nemáme, takže platíme jako mourovatí za každého uživatele s RDP přístupem na Windows server, plus za každého uživatele účetního systému uvnitř toho serveru. Grafik potřebuje Adobe Illustrator, OK, budiž, jedna licence. Dva lidi potřebují komplexní funkce v Excelu zejména makra a pohodlnou práci s pivot tables, OK, proč ne, dělat makra v Libreoffice Calcu je proti Excelu napřeshubu.
Pak tu je ale je zbytek firmy, který makra v Excelu neumí a nepoužívá, a vlastně žádné funkce unikátní pro MS Office nepotřebuje. Proto jede firma na LibreOffice a naprostá většina dokumentů i tabulek je právě v ODT/ODS formátech a s kompatibilitou mezi uživateli není problém. Pár lidí ale má své počítače se svými MS Office, a s nimi je největší problém, protože mají tendenci OpenDocumenty od ostatních lidí otvírat a přeukládat v MS Office, čímž jejich Word a Excel v těch ODS/ODT souborech napáchá tolik škod, že míň škod by snad bylo, kdyby celá firma sice měla Libreoffice, ale ukládala do OOXML (DOCX/XLSX) byť to není nativní formát LO.
Problém navíc je, že těch pár tabulek XLSX s těmi makry a pivoty by rádi občas editovali i další lidi, takže by to chtělo dokoupit pát dalších licencí Excelu nebo MS office jako celku, a z diskuse vyplynulo, že to je blbé mít takto heterogenní systém většiny dokumentů v OpenDocumentu a pár klíčových tabulek v XLSX, kdy daná XLSX nejdou dobře otevřít (a hlavně se nesmí uložit) v LO, a OpenDocumenty přicházejí o ještě víc funkcí pokud se otevřou a nedejbože uloží v MS Office. V tuto chvíli už tahám za kratší konec provazu, protože ve firmě je silnější touha mít vše jednotné, tj. plošně všude hodit MS Office.
Snažím se zatím docela marně najít nějaké RECENTNÍ studie (2011+), kde by se dělala CBA (cost-benefit analýza) resp. se počítalo TCO (total cost of ownership) u open source kancelářského balíku a Microsoft Office u nějakých srovnatelných organizací. Možná fakt MSO vyjdou v TCO líp, protože proškolit lidi může být dražší než předplácet Office365 nebo koupit krabice/multilicenci MSO, v tom případě holt má ekonomika přednost. Ale bez nějakých čísel v tom vůbec nemám jasno a nezbývá mi, než vycházet ze své linuxo-centrické ideologie a víry bez jakýchkoli důkazů, že přece jen ten vendor lock-in a plošné nakupování licencí nakonec až tak výhodný nemusí být, akorát že po čase už nebude vůbec ekonomicky výhodné směr změnit - zatímco teď ještě to možné je, protože makra a funkce nekompatibilní s LIbreoffice obsahují v celé firmě pouhé dvě master tabulky. Jde mi o to, ale mít nějaká čísla, bez nich setrvání u otevřeného kancelářského balíku a pokračování současného hybridního systému, kdy se MSO používají jen na specifické dokumenty, a na vše ostatní pak LO, patrně nebude mít dlouhého trvání.
(P.S. Osobně jsem jedním z těch mála uživatelů toho Excelu a autorem jedné z těch dvou master tabulek co nefungují v Libreoffice :) Excel mám ve Windows ve VirtualBoxu uvnitř Linux Mintu. OpenOffice jsem ale používal už od verze 1.1 a ve Writeru i Calcu jsem docela power user a znám poměrně dobře jak funkce tak i limity OO/LO. Umím zaškolit lidi, jak ve Writeru či Calcu udělají skoro cokoli.)
Tiskni Sdílej:
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 . (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.