Poslední příspěvky

1

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

« Poslední příspěvek od bindiff kdy Dnes v 00:31:57 »

Větsinou používám primární výběr, ale když zrovna nemám v ruce myš, tak clipboard. Při kopírování do Emacsu je možné text vkládat běžným způsobem pomocí C-Y a Emacsí „schránka“ se přepíše aktuální schránkou. Když náhodou přijdu o obsah schránky, v Emacsu ho můžu vyhrabat z historie pomocí M-Y.

Když jsem na KDE, používám v Klipperu kontextové menu s vlastními akcemi, které se zobrazí po zkopírování textu. Jinde mám klávesové zkratky pro akce ve stylu „otevři aktuální obsah clipboardu v MPV“, takže (v tomhle případě) otevření videa z liknu na webu je celkem snadné.

Drag&Drop používám velmi vzácně, s výjimkou LibreOffice Calcu pro přesuny a kopírování výběru v něm a jednoho nejmenovaného chatovacího programu pro přeposílání zpráv.

Discord (který používám jen vzácně a z donucení =) ) bere middleklik cca kamkoliv do okna jako příkaz vložení primárního výběru – je to velmi šikovné, ale celkem často se mi stává, že někomu omylem pošlu svůj primární výběr. Tahle featura mi chybí v cca všech komunikátorech kromě Discordu.

2

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

« Poslední příspěvek od bindiff kdy Dnes v 00:25:00 »

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í.

Tohle má celkem pěkně pořešené Okular, který znovunačítá otevřený dokument, pokud byl přepsán. (Bohužel v případě zapsání neplatného souboru zobrazuje prázdné okno.) Na editování (La)TeXu používám Emacs, takže Emacs s autosave + rebuild při uložení .tex souboru + reload v Okularu řeší náhled úprav celkem pěkně.

KDE to teda dotáhlo ještě dál a udělali Kile, který kombinuje KatePart (komponenta textového editoru z KDE) s OkularPart do jedné aplikace, navíc ukazuje pozici v .tex souboru jako linku v PDF. Jeden čas jsem to používala, je to fajn.

3

Bazar / Re:Prodám Dell s Ryzen 2200G za 500 Kč

« Poslední příspěvek od Jaroslav Štěpánek kdy 17. 11. 2025, 22:47:46 »

V pohodě, díky za info.

4

Bazar / Re:Prodám AMX dotykové monitory nové MX 1001 L

« Poslední příspěvek od Jaroslav Štěpánek kdy 17. 11. 2025, 21:38:42 »

Zdravím, já bych si dva klidně vzal. Bylo by možné je poslat zasilkovnou/alzaboxem nebo tak nějak?

Diky

5

Sítě / Re:Venkovní síťový kabel na 300 m a 1 Gbit

« Poslední příspěvek od František Ryšánek kdy 17. 11. 2025, 20:59:55 »

Nelinearita ale vadí velmi, zejm. moderním modulacím s velkou bitovou hloubkou na symbol (QAM a její dcera OFDM).

Zde diskutovaná technologie G.hn pracuje s modulací QAM 4096

Ano QAM4096 potřebuje EVM pod 1% a problémy nastávají hlavně u koncových zesilovačů vysílače (větší výkony a/nebo low power design).

Zde diskutovaná technologie pracuje s výkonem max 5dBm (cca 3mW), což je při 75ohm méně než 1V amplituda, a bavíme se o pasivních prvcích. Má někdo aspoň jednu zkušenost či odkaz, že by to byl problém? Nebo je to další "důvod" proč to nedělat správně?

Zkoušeli jsme to na SHDSL modemech velmi konkrétně a prakticky. SHDSL modemy G.991.2 Annex B, rychlost 15 Mbps na pár, "modem" byl vlastně router se dvěma SHDSL porty, uměl i routovat a dvě linky bondovat. Modulace byla nějaká varianta TC-PAM, nevím kolik to mělo efektivních bitů na symbol. Vyštrachal jsem v archivu a přikládám dva screenshoty FFT pro dvě různé modulační rychlosti, a oscilogram do zátěže 100 Ohm - já tam čtu asi 3V špička od nuly, to je lehce přes 2V efektivní. Naprázdno / jenom krátký kabel to dávalo rozkmit kolem +/- 10 V (špička).

Vzala se sdružená ochrana tř.B+C, nějaká Brokova stávající, která byla poměrně "utažená" na optimální ochranný účinek a koordinaci energetických odolností v kaskádě. Ta ochrana byla naladěná na "nějaký dvoudrát" - už nevím, jestli to byly voiceband async modemy, nebo RS485 nebo tak něco. Prostě první stage jiskřiště, druhý stage transily, sériově rezistory (Brokův oblíbený model, wattáž, odpor). Ty původní transily byly tuším "5 kW" - týká se odolnosti pro pulz o nějakých časových parametrech, zřejmě daných normou, možná EN61000-4-4.

Snažili jsme se z toho skrz dvě ochany na stole dostat aspoň 5 Mbps, což bylo jinak reálné omezení nějakých dlouhých linek co běžně provozovali naši zákazníci. V původním zapojení skrz ochranu nechodil provoz vůbec. Když jsem vyhodil transil, tak se linka spojovala bez omezení na max. Tak jsem zkoušel v několika krocích slabší a slabší transily, až se přenos postupně rozjel. Nojo, ale výsledný transil měl tak mizernou energetickou odolnost, že prakticky nemělo smysl ho v zapojení nechávat, protože samotný modem uvnitř byl chráněný teoreticky líp :-) Provoz mezi 2 - 5 - 7 Mbps mi podle starých záznamů chodil s transily jako 1.5KE33CA nebo P4KE33CA - to je otvírací napětí 33V, bipolární model, 1500 resp. 400 W.  Zajímavé bylo, že když jsem na linku přidal jenom rezistivní útlum (citelně větší než dělala samotná ochrana), nebo i kondík o podobné kapacitě jako měl parazitně transil, tak přenos fungoval. Tolik k mé hypotéze o nelinearitě. Zobrazit konstalaci toho TC-PAMu samozřejmě neumím, nemám jak. A údaje jako odstup SNR... tuším v podobě jednoho úhrnného čísla se z toho dostat dal. Jo, v záznamu čtu něco jako 24 dB v ideálním případě, a něco jako 9-11 dB když "to aspoň nějak bylo ochotné fungovat" (rychlost na automatiku, jednotky Mbps). Což samozřejmě neříká nic o spektrální charakteristice linky, rozložení toho IMD rušení ve spektru apod.

Vemte si, že ten transil má otvírat řádově při 30V, posílám skrz něj něco jako 3V, a stejně mi ten signál zmarní, ale jinak než kondenzátor. Jasně... Vy mluvíte o signálu s amplitudou asi 1V RMS, to je asi půlka, a intermodulační produkty za jinak stejných okolností klesají v logaritmické škále dvakrát rychleji než signál. Otázkou je, zda my dva spolu srovnáváme "za jinak stejných okolností" atd.

Čili ve finále mám jenom tu praktickou zkušenost, s přenosem asi 2..15 Mbps, nedaleko od těch úrovní amplitudy co zmiňujete, že transil je víc trápení než užitku. Bohužel :-( Ve finále jsme to dodávali jenom jako jednostupňovou ochranu (jiskřiště + odpory) a statisticky to mělo ochranný efekt snad stoprocentní.

6

Server / Re:Proxmox: SSH klíče a zápisy disku

« Poslední příspěvek od František Ryšánek kdy 17. 11. 2025, 20:00:12 »

apt-get install iotop ?
Jinak je to nějakých 24 kBps ... jestli atime by tomu mohl přidávat, inu proč ne... rostou nějaké logy? dmesg se pohybuje? Kdyby tam byl třeba ZFS, ten si téměř neustále na pozadí odmocňuje pí jenom z toho titulu že dejchá, ale EXT4 takové věci nedělá...

7

Server / Re:Proxmox: SSH klíče a zápisy disku

« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy 17. 11. 2025, 18:26:21 »

Jo, nenapsal jsem, jak jsem to měřil a sice iostat -h 30 ,zatím ne hlouběji ne . kacířská otázka, když tam neběží VM, inotify se probojuje až to LXCs?
Disková geometrie je úplně základní setup s jediným nvme diskem kde je  storage local(Directory, asi z root partition,který je ext) a local-data, žádný raidy ani cephy

Jsou tam 2 LXC, na které defacto nikdo nepřistupuje

Proč mě to trápí, že mi to připadá prostě nadměrné na to že ty kontájnery nic nedělají a taky  že ten zápis se děje defacto přes všechny lvm. (ačkoliv discard jen přes dm-1=root)

A nebo jsem zmlsaný tím, že RPI za 100 dní má iostat-h:
      tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn Device
     0,03         0,4k         0,3k       3,6G       2,3G mmcblk0
(tam docker ani LXC ani virtuály nejsou, ale router dns, dhcp a vše co jsem identifikoval jako zapisující jsem montnul to tmpfs v fstab : varlolg, var-lib, varlata, var-cache-samba ,vařkaši, varkaše-nscd)   


A asi by to mělo vydržet 150let tímto tempem..... Jen si říkám, jestli to nezapisuje úplně zbytečně kvůli nějaké drobnosti jako  atime režim commit timeout, něco nad LVM...

Kód: [Vybrat]

#mapování:
 ls -lolgha /dev/mapper/ | grep -Pio pve-.+ |  awk '{ print $3 , $1}' |sort
../dm-0 pve-swap
../dm-1 pve-root
../dm-2 pve-data_tmeta
../dm-3 pve-data_tdata
../dm-4 pve-data-tpool
../dm-5 pve-data
../dm-6 pve-vm--100--disk--0
../dm-7 pve-vm--102--disk--0

iostat h 30 #  zajímavost  sloupec discard nuly kromě dm-1

Linux 6.14.11-3-pve (virt)      17.11.2025      _x86_64_        (4 CPU)

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
     0,00         0,0k         0,0k         0,0k       2,7M       0,0k       0,0k dm-0
     1,35         1,1k        11,4k       144,8k     677,5M       6,9G      88,0G dm-1
     0,02         0,0k         0,0k         0,0k      14,8M      30,0M       0,0k dm-2
     1,96         2,0k        11,6k         0,0k       1,2G       7,0G       0,0k dm-3
     1,96         2,0k        11,6k         0,0k       1,2G       7,0G       0,0k dm-4
     1,41         1,3k         8,6k         0,0k     807,0M       5,2G       0,0k dm-6
     0,55         0,7k         2,9k         0,0k     463,5M       1,7G       0,0k dm-7
     2,66        54,4k        23,0k       146,4k      33,1G      14,0G      89,0G nvme0n1

^ první výpis není aktivita za x sekund , ale od počátku (asi od bootu)
... uptime je 7 dní

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-0
     0,56         0,0k         1,8k         0,0k       0,0k      60,0k       0,0k dm-1
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-2
     1,94         0,0k         9,9k         0,0k       0,0k     336,0k       0,0k dm-3
     1,94         0,0k         9,9k         0,0k       0,0k     336,0k       0,0k dm-4
     1,59         0,0k         8,5k         0,0k       0,0k     288,0k       0,0k dm-6
     0,35         0,0k         1,4k         0,0k       0,0k      48,0k       0,0k dm-7
     2,00        45,2k        11,6k         0,0k       1,5M     396,0k       0,0k nvme0n1

lol

      tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd Device
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-0
     1,41         0,0k        15,1k         0,0k       0,0k     512,0k       0,0k dm-1
     0,00         0,0k         0,0k         0,0k       0,0k       0,0k       0,0k dm-2
     1,85         0,0k         8,1k         0,0k       0,0k     276,0k       0,0k dm-3
     1,85         0,0k         8,1k         0,0k       0,0k     276,0k       0,0k dm-4
     1,21         0,0k         5,8k         0,0k       0,0k     196,0k       0,0k dm-6
     0,65         0,0k         2,4k         0,0k       0,0k      80,0k       0,0k dm-7
     2,74        45,2k        23,2k         0,0k       1,5M     788,0k       0,0k nvme0n1

^C


8

Server / Re:Proxmox: SSH klíče a zápisy disku

« Poslední příspěvek od RDa kdy 17. 11. 2025, 17:41:07 »

3. Proč mi to žere  2GB zápisu na disk denně, když to nic nedělá? Je to standardní množství dat, co zapisuje plus mínus každá dstribuce Existuje nějaká optimalizace jako commit teimout nebo vcar log na tmpfs?

Odkud pochazi ta metrika "2GB denne" ?

Trasovani I/O, pokud tedy nic jako bezet nema, bych resil skrze inotify - podival se, na co se saha.

Samozrejme to neodhali veci, ktere jsou otevreny trvale a pristupuje se do nich.. takze zde bud udelat diff z nejakeho skenu FS s atributy (rekurzivni ls -la?) pred a po jednom dni, nebo prozkoumat lsof.

Pokud jsou data zapsany (ne prepsany), tak je muzes odhalit i skrze snapshotovani a diff mezi nema.

Dej vedet jak to pokrocilo v tomto smeru a na co jsi prisel - co za zapisy stalo.

9

Server / Re:Proxmox: SSH klíče a zápisy disku

« Poslední příspěvek od czmiho kdy 17. 11. 2025, 16:58:16 »

Ty klice pridava sam proxmox pro vnitrni potreby pve (migrace a dalsi operace v clusteru kdy jeden nod dela ssh na druhy)

Vytvoreni clusteru a pridani nodu viz https://pve.proxmox.com/wiki/Cluster_Manager

Nemam zadny nicnedelajici proxmox abych to mohl zmerit, ale asi to bude v norme. Zalezi i na souborovem systemu a raidlevelu, treba zfs raidz2 bude mit write multiplication klidne pres 6x u malych zapisu. Ciste ze zvedavosti - proc te 2GB/den trapi?

10

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

« Poslední příspěvek od Franta Kučera 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.