Příspěvky

1

Software / Re:Licencování softwaru s výjimkou nedemokratických režimů

« kdy: 23. 04. 2026, 12:20:38 »

Aké otvorené licencie umožňujú obmedziť použitie projektu na účely ...

Žádné. Takový software by nebyl otevřený ani svobodný už z definice. A hlavně to ani nedává smysl – pokud nějaký režim např. zavírá nebo zabíjí lidi za jejich názor, tak mu nějaká tvoje licence bude úplně ukradená a pokud se mu tvůj software bude hodit, tak ho použije tak jako tak. Jediným důsledkem takové licence je, že poškodíš normální slušné lidi, kteří se snaží respektovat pravidla – místo toho, aby dělali něco užitečného, tak se budou dohadovat, co je a co není dle takové licence v pořádku a dumat nad nejednoznačnostmi, které to nevyhnutelně vyvolává.

2

Hardware / Re:Tiskárna tiskne horizontální čáry

« kdy: 23. 04. 2026, 12:13:26 »

Zkoušel jsi se podívat do manuálu k tiskárně? Tam bývají tyhle typické problémy popsané včetně doporučených řešení.

3

Server / Re:Dovecot Sieve a odchozí e-maily

« kdy: 20. 03. 2026, 17:21:25 »

BCC se dá přidat i v Postfixu, viz https://www.postfix.org/postconf.5.html

4

Bazar / Re:Prodám zálohy linuxových distribucí na CD a DVD

« kdy: 28. 11. 2025, 16:59:21 »

Byl tu kdysi jeden komiks, který mi tohle připomnělo

https://www.root.cz/clanky/komiks-rande-s-intelektualem/

(nemohl jsem odolat ;-)

Trochu zvláštní pocit číst svoje skoro dvacet let staré komentáře... Při té příležitosti jsem si chtěl aspoň objednat osušku s tučňákem (fakt by se hodila), ale odkaz bohužel nefungoval.

Mojí motivací mít takovou sbírku všech možných vypálených linuxů bylo (opakuji BYLO!) připravit se na válku, alespoň takovýmto způsobem. Dnes věřím, že válka tady u nás v Čechách nebude a ani na Slovensku. Ale kdo ví, komu rupne v bedně a nechá z nějakého debilního důvodu zlikvidovat civilní síť počítačů.

Tohle nejsou vůbec zbytečné snahy. Ona sice nemusí přijít válka, ale může se rozpadnout ten globalizovaný svět a internet, ve kterém je všechno všem dostupné. Takže pracovat na decentralizaci a zálohování má určitě smysl. Kdysi jsem taky věřil takovému tomu „jak dáš jednou něco na internet, tak je to tam napořád“, ale to platí možná tak v případě nějakých sprostých nahrávek... ale jinak jsem za život viděl zmizet už dost webů, služeb, softwaru... že to důležité chci mít radši zálohované u sebe. Před pár lety jsem na tohle téma napsal: Zálohujeme internet: Zdrojové kódy. Časem se snad dostanu k sepsání dalších dílů seriálu.

5

Desktop / Re:Způsob sdílení obsahu mezi aplikacemi

« kdy: 17. 11. 2025, 16:51:55 »

Kopírování prostředním tlačítkem používám prakticky neustále. Dokonce na to mám namapované i slovníky (při držení klávesy Meta/Super mi to vyhledá označený text ve slovnících).

Pak používám klasickou schránku a přetahování objektů myší. Podle toho, co je v danou chvíli nejšikovnější.

A možná ještě jedna související metoda sdílení: otevřu jeden soubor ve dvou aplikacích a obě ho sledují (přes inotify), takže nemusím nic kopírovat nebo tahat myší, stačí jen v jedné aplikaci uložit a v druhé se to hned objeví. Můžou to být dva textové editory, ale třeba taky editor a ShaderShark nebo editor (či skript, Make atd.) a www prohlížeč Falkon. Typicky jde tedy o živý náhled a integraci mezi aplikacemi, které o sobě navzájem nemusí vědět, nemají nějakou explicitní vzájemné propojení a jen umí sledovat změny na FS.

6

Desktop / Re:Jak používáte více displejů?

« kdy: 28. 10. 2025, 18:11:08 »

Dřív jsem taky používal dva monitory (taková ta klasika - na jednom hlavní práce, na druhém nějaké pomocné věci, dokumentace atd.). Ale pak jsem došel k tomu, že lepší než otáčet hlavou je přepínat virtuální plochy (ty navíc s více monitory nejdou moc dohromady resp. měly by se přepínat buď nezávisle nebo jen na jednom displeji).

Problém více displejů je taky v tom, že člověk pak často sedí a kouká nakřivo – ten hlavní monitor sice může mít na střed, ale pak delší dobu čte dokumentaci na tom „vedlejším“ atd. Někdy jsem měl dole notebook a nad ním monitor, ale ten je pak dost vysoko. Pokud mají být vedle sebe, tak hodně záleží na šířce – u širokoúhlých displejů by si člověk vyloženě ukroutil hlavu – a u těch užších je zase otázka, proč jich mít víc a nepořídit radši jeden širší.

Mám tedy 16 virtuálních ploch (4×4) a úlohy na nich umístěné tak, abych se většinou přepínal jen mezi dvěma nejbližšími – tzn. např. IDE a hned vedle je terminál, kde program spouštím. Většinou mám jedno okno přes celou plochu. V IDE mám např. dva zdrojáky vedle sebe + postranní panel. Někdy mám vedle sebe dvě různá okna.

Jednu dobu jsem byl celkem nadšený z myšlenky aktivit v KDE. Sám o sobě to byl dobrý nápad, bohužel to ale nebylo dotažené a hlavně chyběla podpora v aplikacích. Takže se mi každou chvíli stávalo, že jsem např. kliknul na odkaz a on se začal otevírat v okně prohlížeče běžícího v jiné aktivitě, protože prohlížeč o aktivitách nic nevěděl a tohle okno považoval za hlavní nebo naposledy použité. U virtuálních ploch se to tedy děje taky, ale tam je aspoň mnohem rychlejší jejich přepínání a přesouvání oken z jedné na druhou.

Více fyzických monitorů se podle mého hodí, když člověk dělá něco jako dispečera – sleduje více obrazovek a může na ně koukat i z dálky nebo periferním viděním, protože tam až tak nečte drobný text ale spíš sleduje nějaké výraznější upozornění a změny.

Práci, kterou je potřeba oddělit víc, tak mám na samostatném fyzickém počítači, ale displej, klávesnice a myš jsou společné, takže pak jen přepínám počítače (udělal jsem si jakési vlastní softwarové KVM).

Můžeš prosím poslat screenshot pouze přepínače virtuálních ploch (do fóra nebo na můj email)? Zajímá mě velikost a umístění přepínače ploch na monitoru.

Normálně na liště, vlevo dole vedle tlačítka s hlavní nabídkou. Výška panelu je 80. Je to matice 4×4 a mám klávesové zkratky pro pohyb ve všech čtyřech směrech + pro přesun oken taky ve čtyřech směrech. Taky je užitečný náhled všech ploch přes celou obrazovku – v KDE se to jmenuje Mřížka plocha – stačí najet kurzorem do rohu obrazovky a vidím všechno a můžu přetahovat okna mezi plochami.

7

Desktop / Re:Jak používáte více displejů?

« kdy: 26. 10. 2025, 17:13:45 »

Například, pokud roztáhnu okno prohlížeče na celou obrazovku, tak většina webů má užitečný obsah pouze pruh cca 1/3 uprostřed (třeba root).

To proto, že dlouhé řádky se špatně čtou. Ze stejného důvodu máš např. v novinách (nebo i některých širokých knihách) text sázený do více sloupců.

Ze stejného důvodu nemám rád řádky přes 80 znaku. Také proto, že dva zdrojáky vedle sebe se mi pak nevejdou a skrolování je protivné

Souhlas. Já to měl dlouho za přežitek (přece máme široké monitory, vysoké rozlišení, zdrojáky už skoro nikdo netiskne atd.), ale pak mi došlo, že to omezení na 80 znaků má pořád něco do sebe a že se ta disciplinovanost vyplatí.

Co se týče těch webů – ano, tam by se taky vyplatila vícesloupcová sazba nebo aspoň využít tu šířku pro tabulky a obrázky.

8

Desktop / Re:Jak používáte více displejů?

« kdy: 26. 10. 2025, 13:39:52 »

Například, pokud roztáhnu okno prohlížeče na celou obrazovku, tak většina webů má užitečný obsah pouze pruh cca 1/3 uprostřed (třeba root).

To proto, že dlouhé řádky se špatně čtou. Ze stejného důvodu máš např. v novinách (nebo i některých širokých knihách) text sázený do více sloupců.

9

Desktop / Re:Jak používáte více displejů?

« kdy: 26. 10. 2025, 13:33:48 »

Dřív jsem taky používal dva monitory (taková ta klasika - na jednom hlavní práce, na druhém nějaké pomocné věci, dokumentace atd.). Ale pak jsem došel k tomu, že lepší než otáčet hlavou je přepínat virtuální plochy (ty navíc s více monitory nejdou moc dohromady resp. měly by se přepínat buď nezávisle nebo jen na jednom displeji).

Problém více displejů je taky v tom, že člověk pak často sedí a kouká nakřivo – ten hlavní monitor sice může mít na střed, ale pak delší dobu čte dokumentaci na tom „vedlejším“ atd. Někdy jsem měl dole notebook a nad ním monitor, ale ten je pak dost vysoko. Pokud mají být vedle sebe, tak hodně záleží na šířce – u širokoúhlých displejů by si člověk vyloženě ukroutil hlavu – a u těch užších je zase otázka, proč jich mít víc a nepořídit radši jeden širší.

Mám tedy 16 virtuálních ploch (4×4) a úlohy na nich umístěné tak, abych se většinou přepínal jen mezi dvěma nejbližšími – tzn. např. IDE a hned vedle je terminál, kde program spouštím. Většinou mám jedno okno přes celou plochu. V IDE mám např. dva zdrojáky vedle sebe + postranní panel. Někdy mám vedle sebe dvě různá okna.

Jednu dobu jsem byl celkem nadšený z myšlenky aktivit v KDE. Sám o sobě to byl dobrý nápad, bohužel to ale nebylo dotažené a hlavně chyběla podpora v aplikacích. Takže se mi každou chvíli stávalo, že jsem např. kliknul na odkaz a on se začal otevírat v okně prohlížeče běžícího v jiné aktivitě, protože prohlížeč o aktivitách nic nevěděl a tohle okno považoval za hlavní nebo naposledy použité. U virtuálních ploch se to tedy děje taky, ale tam je aspoň mnohem rychlejší jejich přepínání a přesouvání oken z jedné na druhou.

Více fyzických monitorů se podle mého hodí, když člověk dělá něco jako dispečera – sleduje více obrazovek a může na ně koukat i z dálky nebo periferním viděním, protože tam až tak nečte drobný text ale spíš sleduje nějaké výraznější upozornění a změny.

Práci, kterou je potřeba oddělit víc, tak mám na samostatném fyzickém počítači, ale displej, klávesnice a myš jsou společné, takže pak jen přepínám počítače (udělal jsem si jakési vlastní softwarové KVM).

10

Desktop / Re:Směr práce se dvěma okny

« kdy: 13. 10. 2025, 23:24:29 »

Typicky zleva doprava tzn. jako píšeme a čteme. Alespoň pokud jde o kopírování/přesouvání souborů v ortodoxních správcích souborů (např. mc). Když je toho víc a mám tam složky obráceně, tak je prohodím pomocí Ctrl+U. Pokud ale chci zkopírovat třeba jen jeden soubor, tak klidně v „opačném“ směru. Pokud jde o práci v IDE, tak tam mám většinou otevřené dva zdrojáky vedle sebe + vlevo panel se stromem projektů, tříd atd. Hlavní práci pak dělám v tom zdrojáku vlevo (protože je uprostřed obrazovky) a ten soubor vpravo slouží spíš jako dokumentace (dá se tedy říct, že tady „opisuji“ zprava doleva tzn. opačně než v tom mc). A když by šlo o přetahování myší mezi okny, tak mi asi taky přijde intuitivnější směr zprava doleva, protože jsem pravák, chytnu tu myš a ikonu vpravo a táhnu ji před sebe a ne někam pryč do strany.

Nevím, jestli tahle informace nějak pomohla :-) Čeho to vlastně bude koncept – celého desktopového prostředí nebo nějaké jedné aplikace?

11

Server / Re:hledání zprávy v postfixu

« kdy: 07. 10. 2025, 10:14:02 »

Klient si ten soubor může pojmenovat, jak chce, takže na serveru bude název jiný (klient ho ani nezná, takže šance, že by byly stejné se blíží nule).

Ten antivir dal asi zprávu do karantény, ne? Tak bych se k němu dostal a hledal podle obsahu (typicky postačí předmět a přibližné datum).

Pokud se k té zprávě nedostaneš, tak bych hledal podle data a času – zpráva byla na serveru přijata a uložena nejspíš krátce před tím než ji zachytil antivir. Pro jednoho uživatele resp. schránku by to nemělo být moc zpráv, které bude potřeba projít a zkontrolovat.

Případně je možné, že antivir zprávu ze serveru smazal a najdeš ji už jen v té karanténě.

12

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 03. 10. 2025, 16:09:16 »

Nedávno jsem tady do nějaké diskuse napsal, že generování XML je někdy lepší si napsat sám, ručně, bez knihoven a hned se seběhli místní trollové, co že si to dovoluji si takovou věc psát sám… Přitom to generování XML je výrazně jednodušší než parsování (byť si nepíšeš vlastní parser asi zpracováváš SAX události nebo pracuješ nad DOMem nebo něco podobného). (jen dodávám, že cílem toho mého generátoru nebylo generování libovolného XML, ale určité podmnožiny, která je pro moje potřeby dostačující – důležité je, aby výstup bylo validní XML)

Kdysi jsem měl číst ceník v XML, který prodejce generoval tuším v Pohodě. V záhlaví sada Windows-1250, v obsahu francouzský parfém. Výsledkem nevalidní XML. Prodejce byl bohužel přesvědčen, že má vše správně. Lepení XML bohužel pokaždé nevyjde.

Obávám se, že když někdo neví, v jakém kódování má která data, tak ho nezachrání ani knihovna.

Viz např. v PHP:

Kód: [Vybrat]

<?php

$xw = xmlwriter_open_memory();
xmlwriter_set_indent($xw, 1);
$res = xmlwriter_set_indent_string($xw, "\t");

xmlwriter_start_document($xw, '1.0', 'UTF-8');

xmlwriter_start_element($xw, 'zkouška-kódování');

$text = "čeština v UTF-8";
xmlwriter_start_element($xw, 'správně');
xmlwriter_text($xw, $text);
xmlwriter_end_element($xw);

// tato data se načetla např. ze souboru nebo z databáze:
$text = "čeština v ISO-8859-2";
$text = iconv("UTF-8", "ISO-8859-2", $text);
xmlwriter_start_element($xw, 'špatně');
xmlwriter_text($xw, $text);
xmlwriter_end_element($xw);

xmlwriter_end_element($xw);

echo xmlwriter_output_memory($xw);

?>
Nebo v Javě:

Kód: [Vybrat]

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import org.w3c.dom.Document;
import org.w3c.dom.Element;

public class BadEncodingXml {

    public static void main(String[] args) throws Exception {
        DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
        DocumentBuilder db = dbf.newDocumentBuilder();
        Document d = db.newDocument();

        Element root = d.createElement("zkouška-kódování");
        d.appendChild(root);

        {
            String text = "čeština v UTF-8";
            Element správně = d.createElement("správně");
            správně.appendChild(d.createTextNode(text));
            root.appendChild(správně);
        }

        {
            String text = "čeština v ISO-8859-2";
            text = new String(text.getBytes("ISO-8859-2"), "UTF-8");
            // Java tam aspoň dá: � takže XML je validní, byť data jsou chybná
            Element špatně = d.createElement("špatně");
            // případně: text = "\0";
            špatně.appendChild(d.createTextNode(text));
            root.appendChild(špatně);
        }
       
        TransformerFactory tf = TransformerFactory.newInstance();
        Transformer t = tf.newTransformer();
        t.transform(new DOMSource(d), new StreamResult(System.out));
    }
}

Chyba se dá udělat i při násobení dvou čísel, ale asi to neznamená, že přestaneme násobit, že?

Tady taky narážíme na to, že vývoj softwaru není jen o technologiích, ale i o lidském chování. Pro spolupráci je kolikrát důležitější než nedělat chyby, nebýt kretén a uznat, že v programu chyba je a opravit ji.

13

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 03. 10. 2025, 16:09:09 »

Nedávno jsem tady do nějaké diskuse napsal, že generování XML je někdy lepší si napsat sám, ručně, bez knihoven a hned se seběhli místní trollové, co že si to dovoluji si takovou věc psát sám… Přitom to generování XML je výrazně jednodušší než parsování (byť si nepíšeš vlastní parser asi zpracováváš SAX události nebo pracuješ nad DOMem nebo něco podobného). (jen dodávám, že cílem toho mého generátoru nebylo generování libovolného XML, ale určité podmnožiny, která je pro moje potřeby dostačující – důležité je, aby výstup bylo validní XML)

Muzu se zeptat v jakem jazyku/platforme je to nekdy lepsi? Protoze jediny duvod, co me napada, kdyby podpora xml byla resena v nejake knihovne, co je zabugovana nebo prilis velka, atd.... Tak by me zajimalo v jakem jazyku jste to resili, ze tam nebyla podpora pro xml...

Jednak v Javě - tam bylo cílem mít lepší kontrolu nad formátováním a odsazením + volitelné zvýrazňování syntaxe v terminálu. (jinak v Javě dobré knihovny jsou a podpora XML je ve standardní knihovně)

Jednak v C++ - tam to byla volba mezi a) napsáním cca 140 řádků kódu a b) přidáním závislosti na nějaké komplexní knihovně.

Ani jedno není „lepení stringů“ ale volají se tam metody jako writeStartElement(), writeCharacters(), writeComment() atd. (podobá se to StAX rozhraní).

To „lepení stringů“ se dá napsat třeba i v Bashi a je to jeden řádek s voláním příkazu sed s pár náhradami.

14

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 21:34:43 »

Navíc často ten dict může obsahovat jen omezenou množinu typů, takže třeba neomezeně dlouhé číslo do něj nejde uložit přímo jako číslo, ale jako řetězec a pak se bokem serializátoru do JSONu musí říct, ať to uloží jako číslo, ne jako řetězec (i když to tak je v tom slovníku).

No a? To je správně.

A není jednodušší to číslo nechat třeba jako BigInteger a naučit ten generátor, jak mapovat BigInteger na datové typy daného formátu? K čemu je dobré to převádět na String a pak si někde bokem předávat informaci, že tohle vlastně není String ale číslo?

15

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« kdy: 02. 10. 2025, 21:30:39 »

Já ti nerozumím. V čem, že je ten problém?

Problém je v tom, že to nemusí být stromová struktura, ale může to být obecný graf a na jeden objekt může vést reference z víc míst. Pokud to řešíš přes reflexi, tak tam tu informaci o tom, že jde o stejný objekt, akorát je na něj odkazováno z víc míst, máš zachovanou. Ale když to přesypeš do mapy map, tak se tam ta informace ztratí (nebo si minimálně přiděláš dost práce s tím, abys ji tam zachoval).