Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Takže děkuji za rozšíření obzorů...
Kdyby existoval ideální pro všechny, nebylo by jich tolik....
14.10.2007 02:56
Yin | skóre: 39
| blog: Yinotopia
| Slovesnko, Košice
%!preprocess '^(\n)' '\1\1'Ak nie, myslim, ze napisat jednoduchy filter v akomkolvek jazyku by nemal byt problem. Teda aspon pre mna nie... budem potrebovat nejaky poriadny konvertor, nie moj "pain text 2 html", takze filter najdete v mojom blogu.
Nějak moc nechápu módu těchhle značkovacích zápisů určených pro převod do HTML. většina z nich je dobrá akorát tak pro ty, kdo nemůžou na klávesnici najít špičaté závorky.Možná proto, že SGML deriváty jsou hnus fialovej, HTML počínaje a XML konče. Editace člověkem je těžkej opruz a pro stroj je to ... no to potvrdí, každej kdo se pokusil napsat full featured XML parser a u HTML by HTML5 W3C WG mohla vyprávět. Ve výsledku SGML deriváty nesplňují ani jednu ze základních premis, není to ani pro člověka, ani pro stroj.
Ale proč se k tomuhle pak přidávají nejrůznější šablony, tabulky a další složité zápisy, které ovšem mají svou extra notaci a zpravidla se nedají rozumně parsovat, to nechápu.Jo, to taky nechápu, proč se zpravidla vymýšlí ještě něco horšího. Jako by SGML nebylo dost hnusné, musí se vymýšlet něco, co je ještě hůře parsovatelné.
5.10.2007 09:45
zoul | skóre: 43
| blog: ☂
| Boskovice
... Kdybych měl označkovat třeba text na web nebo článek do sborníku a měl bych si vybrat mezi JSON a XML, osobně bych si nejspíš vybral XML. ...A proč? Protože to funguje stejně jako .doc a .xsl. Žádnou logiku v tom nehledejte.
Když hledám >, hledám prostě tenhle jeden znak, a nemusím bádat, jestli náhodou není v uvozovkách a není před ním zpětné lomítko (např.). Jediné, k čemu potřebujete při tokenizaci XML kontext, jsou znakové entity (a to ten kontext stačí jen od začátku do konce entity). ...Hahaha, LOL, ROFL. Tak si napište takový parser XML. Zboří vám ho první komentář, nebo zrovna to CDATA, ale ono se přece nepoužívá, že? Jasně, že se CDATA nepoužívá, protože je to nepoužitelné. K čemu je uložení binárních dat ve kterých se nemůže vyskytovat určitá sekvence? No a co se používá místo toho? Base64 a že nám to nabobtná o 1/3, no bóže, však pásma je tu dost. Že to není součástí základního standardu XML, no bóže, zavedeme si na to spešl namespace, spešl atribut, spešl to ošéfujeme v parseru, ať žije univerzalita. A kde se nám poděl cíl a účel XML? No bóže, hlavně že je to móda. XML je špatný formát!
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
odstavce = [
[
{
text: "Když hledám >, hledám prostě tenhle jeden znak, a nemusím bádat, jestli"+
"náhodou není v uvozovkách a není před ním zpětné lomítko (např.). Jediné, k čemu"+
"potřebujete při tokenizaci XML kontext, jsou znakové entity (a to ten kontext stačí"+
"jen od začátku do konce entity). ...",
typ: "citace"
}
],
[
{
text: "Hahaha, LOL, ROFL. Tak si napište takový parser XML. Zboří vám ho první"+
"komentář, nebo zrovna to CDATA, ale ono se přece nepoužívá, že? Jasně, že se CDATA"+
"nepoužívá, protože je to nepoužitelné. K čemu je uložení binárních dat ve kterých se"+
"nemůže vyskytovat určitá sekvence? No a co se používá místo toho? Base64 a že nám to"+
"nabobtná o 1/3, no bóže, však pásma je tu dost. Že to není součástí základního standardu"+
"XML, no bóže, zavedeme si na to spešl namespace, spešl atribut, spešl to ošéfujeme v"+
"parseru, ať žije univerzalita. A kde se nám poděl cíl a účel XML? No bóže, hlavně že je"+
"to móda. XML ",
typ: "prostý text"
},
{
text: "je",
typ: "tučně"
},
{
text: " špatný formát!",
typ: "prostý text"
}
]
]
[{"citace":"Když hledám >, hledám prostě tenhle jeden znak, a nemusím bádat, jestli
náhodou není v uvozovkách a není před ním zpětné lomítko (např.). Jediné, k čemu
potřebujete při tokenizaci XML kontext, jsou znakové entity (a to ten kontext stačí
jen od začátku do konce entity). ..."},
"Hahaha, LOL, ROFL. Tak si napište takový parser XML. Zboří vám ho první
komentář, nebo zrovna to CDATA, ale ono se přece nepoužívá, že? Jasně, že se CDATA
nepoužívá, protože je to nepoužitelné. K čemu je uložení binárních dat ve kterých se
nemůže vyskytovat určitá sekvence? No a co se používá místo toho? Base64 a že nám to
nabobtná o 1/3, no bóže, však pásma je tu dost. Že to není součástí základního standardu
XML, no bóže, zavedeme si na to spešl namespace, spešl atribut, spešl to ošéfujeme v
parseru, ať žije univerzalita. A kde se nám poděl cíl a účel XML? No bóže, hlavně že je
to móda. XML ", {"tučně": "je"}, " špatný formát!"]Ale to by nevypadalo tak úděsně a nešly by s tím strašit malé děti. Pěkná ukázka demagogie, ale dosti chabá. A v YAMLu by to bylo ještě lepší.
6.10.2007 09:26
zoul | skóre: 43
| blog: ☂
| Boskovice
A že jste si jak na potvoru z všech možností vybral právě JSON, copak to? Záměr?Však jste nám ho sám nabízel jako první alternativu…?
Ale to by nevypadalo tak úděsně a nešly by s tím strašit malé děti.
"XML ", {"tučně": "je"}, " špatný formát!"XML <tučně>je</tučně> špatný formát!Vy máte fakticky pocit, že ten první zápis je jednodušší?
6.10.2007 09:55
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
5.10.2007 09:55
zoul | skóre: 43
| blog: ☂
| Boskovice
Mně je úplně fuk, jestli bude parsování hotové za 0,01 vtěřiny, nebo 0,02 vteřiny.No jasně, kdyby to bylo takhle, tak je to putna každému, ale on ten rozdíl je přinejmenším desetkrát větší a když děláte nějaké větší řešení, tak už mě sakramentsky zajímá jestli na to budu muset koupit mašiny za půl nebo za pět miliónů jek kvůli tomu, že XML je prostě standard.
Já prostě použiju nějaký hotový parser, kterých je pro každý jazyk kupa, a basta. Ano, psaní parseru je argument, a zvlášť tady mezi programátory je to velká obsese, ale pro praktický úspěch a praktickou použitelnost formátu jsou mnohem důležitější věci.Ano, hezky se to poslouchá jen do chvíle, kdy to má fungovat s trochu větším dokumentem, nebo nedej bože pár miliónů byť i malých dokumentíků, jo to je pak takovej průser, ale co je to dobré pro HW byznys.
5.10.2007 15:31
zoul | skóre: 43
| blog: ☂
| Boskovice
5.10.2007 16:03
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
O trosku nize se podivejte v komentari pana Jirsaka na ten "uzasne citelny" zapis vaseho komentare. ...Jistě, jeden demagog podpoří druhého odkazem na schválně zmršený příklad. Ale jde to i jinak. To bych sem mohl rovnou dát ukázku html generovanou Front Page nebo MS Word blahé paměti. Nebo OpenXML? Jo to by jsme se nasmáli.
6.10.2007 10:01
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
Ale jde to i jinakJe mi lito, porad stejny hnus
Nebo OpenXML? Jo to by jsme se nasmáli.Nebo ODF, ne? To je prece taky XML. Na pohled pro vas o nic mene deprimujici pohled. Opravdu by me zajimalo, cim prehlednejsim a hezcim byste nahradil XML v pripade techto datovych formatu. Vite co, zkuste napsat v OOo nejaky maly dokumentik, pak vezmete
content.xml z toho dokumentu a prepiste to do vasi oblibene alternativy XML. A pak si povime, co je prehlednejsi...
5.10.2007 10:46
Věroš | skóre: 24
| blog: Co není v hlavě
| 49.29 s.š., 16.54. v.d.
Nějak moc nechápu módu těchhle značkovacích zápisů určených pro převod do HTML. většina z nich je dobrá akorát tak pro ty, kdo nemůžou na klávesnici najít špičaté závorky.Protože ne všichni umí zapisovat HTML. Když jsem do Cestovatele přidal možnost zapisovat text do článků v Texy!, tak se to mezi členy redakce velmi ujalo
a rychle začali vyžadovat přidání Texy i do zpráviček a dalších částí webu...
Protože ne všichni umí zapisovat HTML. Když jsem do Cestovatele přidal možnost zapisovat text do článků v Texy!, tak se to mezi členy redakce velmi ujaloTakže se místo HTML učí Texy! A na jiném webu wiki dle MediaWiki. A jinde zase trochu jinou wiki. A pokud chtějí něco speciálnějšího, musí se zase naučit to HTML. V čem je třeba Texy! od nadpisů a seznamů dál jednodušší než HTML? Podle mne v ničem, naopak je složitější – v HTML se tag vždycky píše do špičatých závorek a uvnitř mohou být pojmenované atributy.
Takže se místo HTML učí Texy! A na jiném webu wiki dle MediaWiki. A jinde zase trochu jinou wiki.
Ano je to jedna z nevýhod. Idelání řešení pro všechny neexistuje, bohužel.
A pokud chtějí něco speciálnějšího, musí se zase naučit to HTML. V čem je třeba Texy! od nadpisů a seznamů dál jednodušší než HTML?
Ještě bych pochopil zápis, který mi umožní napsat odstavce, nadpisy, seznamy a možná nějaké jednoduché odkazy.
Vlastně jste si sám odpověděl. Pokud tento seznam pokryje 95% pořizování textu a je mi umožněno zbytek dopsat přímo v HTML. Pak mohu psát mnohem pohodlněji.
Ideální řešení pro všechny neexistuje a určitě někomu bude vyhovovat více jiný přístup.
Což ale právě není případ ani jednoho mně známého systému. Každý začne přidávat svou syntaxy pro vkládání obrázků, částí kódu tabulek, šablon… Už jenom to zvýrazňování textu – hvězdičky, apostrofy, uvozovky – možná to tolik neruší při čtení textu, ale když každý systém používá jinou syntaxy, je to celé k ničemu. To radši budu psát <b> a <i> a nebudu se muset pokaždé dívat, jakou ten který systém zrovna používá syntaxy. Ale aspoň jsem si ujasnil, jak by takový ideální wiki-like zápis měl vypadatJeště bych pochopil zápis, který mi umožní napsat odstavce, nadpisy, seznamy a možná nějaké jednoduché odkazy.Vlastně jste si sám odpověděl. Pokud tento seznam pokryje 95% pořizování textu a je mi umožněno zbytek dopsat přímo v HTML. Pak mohu psát mnohem pohodlněji.
Nelíbila se mi syntaxe MediaWiki se složitými šablonami a tabulkami, na druhou stranu se mi líbí jednoduchý zápis jednoduchého textu (odstavce, seznamy) bez "složitého" XML. Už je mi ale jasné, že nebude těžké napsat XML parser, který zvládně i to jednoduché z wiki syntaxe – odstavce, seznamy, nadpisy. Vše ostatní už pak může být XML.
Opravdu jednoduchý mi přijde ten Markdown (z těch co znám a neznám všechny), obsahuje jen ten základ, co jste vyjmenoval v původním příspěvku. Žádné tabulky, žádné šablony ani jiné složitosti... Právě ta složitost mi vadila na Asciidoc.
Pro mé potřeby je ale Markdown až moc jednoduchý...
Ve věci přemýšlení nad tím jak se zrovna píše <b> si dovolím oponovat. To je přesně to co nemusím dělat, pokud chci stejný text vystavit na web, vyrobit z něj PDF, poslat do firemní wiky... Pak mám konvertor, který mi z jednoho zdroje ty varianty vyrobí. Neumí to všechny konvertory a ani do všech možných formátů. Ale to je pak otázka potřeb a vhodného kompromisu.
5.10.2007 08:23
zoul | skóre: 43
| blog: ☂
| Boskovice
Celý text není založen na víře, ale z pochopitelných důvodů jsem popsal, to co ovládám - takže ano, je to také osobních preferencích.
Myslím, že není třeba být suchar a trocha nadsázky není škodlivá. Jistě jsou i jiné cesty jak se dobrat stejného výsledku - to nikde netvrdím ani nevnucuji nabízené řešení jako jedinou správnou.
Obsah je naproti tomu text s odstavci, nadpisy, různými fonty, obrázky atd.Ne ne, písma jsou forma. Obsah je citace, zdůraznění, příklad atd. A teprve těmto různým významům obsahu se pak přiřazuje forma – různé druhy nebo řezy písma. Problém většiny WYSIWYG je právě to S, tj. že se v nich nastavuje forma (písmo, barva, tučnost atd.), místo aby se určoval význam textu (ať už speciálními tagy, které HTML má, nebo třídami a přiřazenými styly pro ty ostatní významy). U složitějších věcí je pak jednodušší vytvořit jejich obsah i formu společně. Vemte si jako příklad Wikipedii, jaké se tam často používají složité konstrukce. Pokud se pak taková konstrukce oddělí do šablony, je to zase takové oddělení formy od obsahu – al ebylo by hodně náročné vytvořit a udržovat takový WYSIWYG editor, který by zvládal jako sémantické konstrukce používat i tu spoustu šablon. Nicméně to ještě není důvod, proč pro ty složitější konstrukce vymýšlet šílené zápisy nesrovnatelně složitější, než HTML.
IMHO jsou cílovou skupinou tohoto a podobných programů technicky zaměření uživatelé, jako jsou např. programátoři. Ten kdo chce používat svůj oblíbený vim/emacs/... a zároveň považuje konstrukci & za čitelnější než & je vhodným kandidátem na používání podobného nástroje.
Tento přístup není samozřejmě vhodný pro každého, někomu třeba vyhovuje některý z WYSIWYG editorů nebo přímé psaní HTML.
Já jsem také profi programátor a nikdy jsem nenapsal jediný web . XML a jeho deriváty považuji za dobrý základ pro protokoly a data zapisované a čtené programy, nikoliv lidmi.
Standard většinou nebývá nejlepší řešení.
Když jsem řešil konfigurák pro svou aplikaci, chtěl jsem použít YAML, ale nenašel jsem žádnou široce podporovanou a stabilní knihovnu (pro Javu). Nakonec stejně nějaký admin zvládne konfigurovat i v XML a pro klikače se stejně musí udělat GUI. Kolik třešní, tolik višní.
V obecném případě máte jistě pravdu - písma jsou forma a obsah je citace, zdůraznění, příklad atd. Běžně se ale tenhle rozdíl úplně stírá. Napíšu-li něco bold, je to prostě zvýraznění a netřeba o tom přemýšlet.Jenže to je právě problém. Někdo pak používá pro zvýraznění tučné písmo, jiný kurzívu a jiný červené písmo. A je to třeba ve stejné diskuzi, ve stejném redakčním systému, nebo dokonce na stejné wiki-stránce.
Wiki syntaxi mám docela rád, ale každopádně preferuju, když nad textareou pro zadávání textu jsou tlačítka, kterými lze udělat totéž, co syntaxí. Nenapadá mě žádný příklad konstrukce, která je natolik složitá, že nejde řešit WYSIWYG, a zároveň lze elegantně řešit něčím jako txt2tags či Texy! Jestli o nějakém takovém příkladu víte, byl by to určitě významný příspěvek této diskuzi.To po mně nechtějte, já tu celou dobu tvrdím, že txt2tags nebo Texy! řeší složitější konstrukce velmi neelegantně
Problém s WYSIWYG je, že je nemůžete rozumně používat s jiným způsobem zápisu, než HTML (bylo by moc pracné takový editor napsat a udržovat). A pro složitější systémy, než jsou komentáře (redakční systémy, blogy, wiki) potřebujete různé konstrukce jako šablony. Třeba jenom hloupý obsah stránky (__TOC__ z MediaWiki) – musel byste zařídit, aby vám jej WYSIWYG editor nedovolil změnit, dovolil vám jej úplně smazat nebo přesunout na jiné místo ve stránce, a aby se zaktualizoval, pokud změníte obsah stránky.
Může se zdát, že už chci po takovém systému moc, třeba tady v dikuzích ani blozích žádné šablony potřeba nejsou. Ale co když sem budu chtít implementovat funkci snadného vkládání odkazu do slovníku nebo FAQ? Už budu muset oželet to, že se mi text zobrazí skutečně tak, jak bude vypadat ve výsledku (tedy třeba odkaz na heslo ve slovníku a jako tooltip jeho vysvětlení), takže už to nebude tak úplně WYSIWYG, nebo budu muset zapomenout, že je to odkaz na heslo ve slovníku, a bude to prostě obyčejný odkaz s tooltipem – a až se změní URL slovníku, nebude mi stačit změnit v generátoru adresu, která se vygeneruje ze zdroje [slovník:heslo], ale budu muset změnit všechny komentáře v databázi.
<!-- _TOC_ -->. (Alespoň takto to wordpress řeší u tagu more, který dělí příspěvek na úvod a zbytek.)
Pokud jde o slovník, tam by to šlo nepochybně řešit podobně.
A jedna mírně mimotématická věc: změna URL slovníku, na který odkazují příspěvky, by se kromě měnění všech příspěvků dala řešit i konfigurací serveru (u PHP např. .htaccess a mod_rewrite), aby se požadavek na starou URL přepsal na novou.
<em> což se zobrazuje většinou jako kurzíva, a <strong> (které se zobrazuje většinou jako tučné písmo) je silné zdůraznění, ale většina lidí má pocit, že zvýraznění přece musí být pořádně vidět, tak jaká pak kurzíva…
V obecném případě máte jistě pravdu - písma jsou forma a obsah je citace, zdůraznění, příklad atd. Běžně se ale tenhle rozdíl úplně stírá. Napíšu-li něco bold, je to prostě zvýraznění a netřeba o tom přemýšlet.A výsledkem jsou takováto zvěrstva. Bold je poplatný době. Člověk který nikdy neviděl Word vůbec nepochopí, o co jde. Uvidíme za 20 let, co na to řeknou naše děti.
Tiskni
Sdílej:
