V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána nová verze 2.4.64 svobodného multiplatformního webového serveru Apache (httpd). Řešeno je mimo jiné 8 bezpečnostních chyb.
Společnost xAI na síti 𝕏 představila Grok 4, tj. novou verzi svého AI LLM modelu Grok.
Ministerstvo vnitra odhalilo závažný kyberincident v IT systému resortu. Systém, do kterého se dostal útočník bez oprávnění, byl odpojen a nedošlo k odcizení dat [𝕏].
$ 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: