Netwide Assembler (NASM) byl vydán v nové major verzi 3.00. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.
Linuxová distribuce Frugalware (Wikipedie) ke konci roku 2025 oficiálně končí.
Byla vydána nová verze 3.0.6 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP bude brzy k dispozici také na Flathubu.
Americký výrobce čipů AMD uzavřel s americkou společností OpenAI smlouvu na několikaleté dodávky vyspělých mikročipů pro umělou inteligenci (AI). Součástí dohody je i předkupní právo OpenAI na přibližně desetiprocentní podíl v AMD.
Byla vydána nová verze 10.1 sady aplikací pro SSH komunikaci OpenSSH. Uživatel je nově varován, když se nepoužívá postkvantovou výměnu klíčů.
Byly zpracovány a na YouTube zveřejněny videozáznamy z konference LinuxDays 2025.
Na konferenci LinuxDays 2025 byl oficiálně představen nový router Turris Omnia NG.
Přímý přenos (YouTube) z konference LinuxDays 2025, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
V únoru loňského roku Úřad pro ochranu osobních údajů pravomocně uložil společnosti Avast Software pokutu 351 mil. Kč za porušení GDPR. Městský soud v Praze tuto pokutu na úterním jednání zrušil. Potvrdil ale, že společnost Avast porušila zákon, když skrze svůj zdarma dostupný antivirový program sledovala, které weby jeho uživatelé navštěvují, a tyto informace předávala dceřiné společnosti Jumpshot. Úřad pro ochranu osobních údajů
… více »
$ scp -P 22 gNOSVN.2.0.tar.gz user@aa.bb.cc.dd:
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
Vysledek naskoci okamzite po zadani hesla a dal uz nic, do promptu se to nevrati. Pro jina IP (zz.xx.cc.vv napriklad) to funguje bez problemu. (Pro kraticke soubory taky.) Na cilovem pocitaci se vytvori prazdny soubor gNOSVN.2.0.tar.gz a visi tam ssh:
30350 ? Ss 0:00 \_ sshd: user [priv]
30355 ? S 0:00 | \_ sshd: user@notty
30356 ? Ss 0:00 | \_ scp -t .
Na vzdaleny pocitac se da zalogovat:
$ ssh user@aa.bb.cc.dd
funguje to normalne. Kdyz jsem na tom pocitaci nalogovany, tak
$ scp -P 22 jmeno@pu.vo.dni.IP:gNOSVN.2.0.tar.gz .
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
probehne bez problemu a soubor prenese. (Cili stahnout jde, natlacit nikoli)
Stejne tak se soubor da na vzdalenem pocitaci scp-ckovat sem a tam bez problemu:
$ scp -P 22 gNOSVN.2.0.tar.gz user@127.0.0.1:
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
$ scp -P 22 gNOSVN.2.0.tar.gz user@192.168.1.100:
Password:
gNOSVN.2.0.tar.gz 100% 648KB 647.9KB/s 00:00
Cili se zda, ze ten pocitac sam o sobe funguje, ale neco po ceste to zmrsi ... (ten pocitac je za nejakym firewalem/NATem, od ktereho nemam klice - ssh-cknout se zkrz zvladnu, scp funguje jen obracene)
Ma nekdo ideu, cim by to mohlo byt, nebo jak to resit? Admin toho NATu je (asi) spis malo zkuseny a obtizne dostupny, takze idealne primo co tam ma upravit, pokud se to da takhle usoudit?
Řešení dotazu:
# scp -P 22 * user@aa.bb.cc.dd:
Password:
000.tmp 100% 0 0.0KB/s 00:00
001.tmp 100% 1024 1.0KB/s 00:00
002.tmp 100% 2048 2.0KB/s 00:00
jeden kilobyte se prenese okamzite, pri dvou to vytuhne ...
(Obracene tahani se tvari, ze zvlada stovky kB/s)
tcpdump
em – nejlepší by bylo na obou stranách, ale to asi bude obtížné. Leda byste ji přesměroval do souboru a pak nějak k sobě dostal ten soubor.
.cz.ssh: P 12773:12837(64) ack 3454 win 165 <nop,nop,timestamp 524620035 150010234>
.cz.ssh: P 12837:14277(1440) ack 3502 win 165 <nop,nop,timestamp 524620041 150010237>
.cz.ssh: P 14277:14341(64) ack 3550 win 165 <nop,nop,timestamp 524620047 150010239>
.cz.ssh: P 14341:15781(1440) ack 3598 win 165 <nop,nop,timestamp 524620052 150010241>
.cz.ssh: P 15781:15845(64) ack 3646 win 165 <nop,nop,timestamp 524620058 150010244>
.cz.ssh: P 15845:17285(1440) ack 3694 win 165 <nop,nop,timestamp 524620063 150010246>
.cz.ssh: P 17285:17349(64) ack 3742 win 165 <nop,nop,timestamp 524620069 150010248>
.cz.ssh: P 17349:18789(1440) ack 3790 win 165 <nop,nop,timestamp 524620075 150010250>
.cz.ssh: P 18789:18853(64) ack 3838 win 165 <nop,nop,timestamp 524620081 150010253>
.cz.ssh: P 18853:20293(1440) ack 3886 win 165 <nop,nop,timestamp 524620086 150010255>
.cz.ssh: P 20293:20357(64) ack 3934 win 165 <nop,nop,timestamp 524620092 150010257>
.cz.ssh: P 20357:21797(1440) ack 3982 win 165 <nop,nop,timestamp 524620098 150010260>
.cz.ssh: P 21797:21861(64) ack 4030 win 165 <nop,nop,timestamp 524620104 150010262>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620109 150010264>
.cz.ssh: P 23309:23317(8) ack 4078 win 165 <nop,nop,timestamp 524620109 150010264>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620164 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620274 150010266>
.cz.ssh: F 23317:23317(0) ack 4078 win 165 <nop,nop,timestamp 524620490 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620494 150010266>
.cz.ssh: . 21861:23309(1448) ack 4078 win 165 <nop,nop,timestamp 524620934 150010419>
.cz.ssh: . 23701:25149(1448) ack 4174 win 165 <nop,nop,timestamp 524621182 150009572>
Je mozne, ze nekde je velikost dana na 1500. Na nekolika dalsich strojich, kde to funguje, se to zastavilo na hodnote 988 a packety se zacaly delit (= slo jich vic za sebou, jakmile to presahlo hranici).
Da se nekde na cilovem stroji nastavit, aby chtel mensi velikost?
I kdybyste to nastavil na druhém konci, budou se jen pakety fragmentovat po cestě, ale zdrojový počítač se je pokusí odeslat vcelku, a opět to neprojde
Pro TCP spojení tomu lze předejít, viz target TCPMSS
Tiskni
Sdílej: