Byla vydána nová verze 10.2 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze nové balíčky Immich, Immich Machine Learning, uv a RustDesk Client.
TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 6.0. Příští verze 7.0 je kvůli výkonu přepisována do programovacího jazyka Go.
Christian Schaller z Red Hatu na svém blogu popsal své zkušenosti s používáním AI při vývoji open source aplikací pro Linux. Pomocí různých AI aktualizoval nebo vytvořil aplikace Elgato Light GNOME Shell extension, Dell Ultrasharp Webcam 4K, Red Hat Planet, WMDock, XMMS resuscitated (aktualizace z GTK 2 a Esound na GTK 4, GStreamer a PipeWire) a Monkey Bubble. SANE ovladač pro skener Plustek OpticFilm 8200i se mu zatím nepovedl.
Americké firmy Tesla a SpaceX postaví v texaském Austinu moderní komplex na výrobu čipů pro umělou inteligenci (AI). Součástí projektu s názvem Terafab budou dvě moderní továrny na výrobu čipů – jedna se zaměří na automobily a humanoidní roboty, druhá na datová centra ve vesmíru. Uvedl to generální ředitel těchto firem Elon Musk. Projekt by podle odhadů měl stát 20 miliard USD (zhruba 425 miliard Kč).
Byla vydána nová stabilní verze 6.11 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Ubuntu 26.04 patrně bude ve výchozím nastavení zobrazovat hvězdičky při zadávání hesla příkazu sudo, změna vychází z nové verze sudo-rs. Ta sice zlepší použitelnost systému pro nové uživatele, na které mohlo 'tiché sudo' působit dojmem, že systém 'zamrzl' a nijak nereaguje na stisky kláves, na druhou stranu se jedná o možnou bezpečnostní slabinu, neboť zobrazování hvězdiček v terminálu odhaluje délku hesla. Původní chování příkazu sudo
… více »Projekt systemd schválil kontroverzní pull request, který do JSON záznamů uživatelů přidává nové pole 'birthDate', datum narození, tedy údaj vyžadovaný zákony o ověřování věku v Kalifornii, Coloradu a Brazílii. Jiný pull request, který tuto změnu napravoval, byl správcem projektu Lennartem Poetteringem zamítnut s následujícím zdůvodněním:
… více »Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 163 (pdf).
Eric Lengyel dobrovolně uvolnil jako volné dílo svůj patentovaný algoritmus Slug. Algoritmus vykresluje text a vektorovou grafiku na GPU přímo z dat Bézierových křivek, aniž by využíval texturové mapy obsahující jakékoli předem vypočítané nebo uložené obrázky a počítá přesné pokrytí pro ostré a škálovatelné zobrazení písma, referenční ukázka implementace v HLSL shaderech je na GitHubu. Slug je volným dílem od 17. března letošního
… více »Sashiko (GitHub) je open source automatizovaný systém pro revizi kódu linuxového jádra. Monitoruje veřejné mailing listy a hodnotí navrhované změny pomocí umělé inteligence. Výpočetní zdroje a LLM tokeny poskytuje Google.
Řešení dotazu:
Klíčková otázka: V čem tkví problém?
Většina různých rádoby-testů rádoby-bezpečnosti jednoduše zkouší, jestli je některý port filtrovaný, tj. jestli se místo connection refused příchozí pakety zahazují. Vsadil bych se, že těch 1056 portů není ve skutečnosti otevřených (netstat -apn) v tom smyslu, že by na nich něco poslouchalo. Prostě jenom nezahazují automaticky pakety a odpovídají místo toho connection refused.
U počítače na RFC4941, tj. například ve stylu implicitně nastaveného Android telefonu nebo zkrátka se zapnutými privacy extensions (v NetworkManageru, dejme tomu) dává velmi dobrý smysl většinu neočekávaných paketů rovnou zahazovat a nijak na ně nereagovat. Malinko to ztěžuje různé nmap průzkumy, malinko to zmenšuje případný dopad zranitelností v kernelu, kdyby se objevily, atd.
Naopak u počítače typu router, jehož přítomnost je (tak trochu) veřejně známá, má takové filtrování a zahazování paketů mnohem menší smysl a význam (byť nějaký furt jo). A otázka právě je, který přesně počítač se onen rádoby-bezpečnostní rádoby-test snažil kontaktovat…
Jsi si jistý, že se k tomu testu připojuješ přímo přes normální internet, kterým se dá navazovat spojení odkudkoliv kamkoliv oběma směry, tedy přes IPv6?
Kdysi se totiž používal vadný protokol IPv4, který kolem roku 1995 selhal, protože měl (omylem, původně jako experiment) 32-bitové adresy. Adresy záhy došly a vyvinul se z toho paskvilo-zmetek zvaný NAT, kvůli kterému se potom už s IPv4 většinou nedalo routovat odkudkoliv kamkoliv — připojení se sice dalo navázat odnikud někam, ale nedalo se navázat odněkud nikam. Je tedy možné, pokud by se něco takového v příslušné síti stále používalo, že si napřed vyžádáš test z „legacy“ (nebo spíš „garbage“) IPv4 sítě za NATem a test se pak (zrady netuše) snaží zpětně připojovat na NAT router, nikoliv přímo na notebook.
Hypotéza a spekulace: Co když se mobil samotný připojuje normálně přes IPv6 (a má tedy klasické nastavení sítě v Androidu, které má celkem reálnou šanci vypadat v „testech“ zeleně), zatímco pro routování do vnitřní sítě mobilního hotspotu se používá (například kvůli nevhodnému nebo nedostatečnému IPv6 rozsahu od operátora) jenom dvojitě NATované IPv4 zoufalství? To by znamenalo, že výsledky, které se ukazují na notebooku, nesouvisí ani s notebookem, ani s mobilem-hotspotem, nýbrž s externím NAT routerem někde v síti mobilního operátora.
Sečteno a podtrženo, je vhodné prověřit, kam přesně se ten rádoby-test připojuje. 
Zkus třeba tcpdump, který dovede ukázat, jestli notebook opravdu na všech uvedených portech dostává nějaké pokusné pakety a odpovídá na ně.
Zkus taky explicitně zakázat IPv4 a NAT (nebo jiným způsobem ověřit, že se notebook k testu připojuje přes IPv6). Bez IPv6 totiž celý test v podstatě nemá smysl — s největší pravděpodobností „testuješ“ jiné zařízení než to, které si test „vyžádalo“.
<-- další věc máš v OS perfektní nástroj na 3 písmena : UFW takže si můžeš otevřít a zavřít co chceš viz .:https://wiki.ubuntu.cz/bezpe%C4%8Dnost/firewall/ufw, https://www.root.cz/clanky/ufw-firewall-jednoduse-a-rychle/
Počítač - připojení AIM - veřejná adresa IPv4: 109.x.y.z
Můj mobil - připojení T-mobile - adresa IPv4: 37.48.y.z
Notebook - připojení také AIM, ale bydlí jinde - IP adresu neznám (používá WiFi)
Jeho mobil - připojení T-mobile, má stejnýho poskytovatele - IP adresu neznám
Čemu nerozumím, pokud udělám hotspot ze svého mobilu (tj. T-mobile IPv4 adresa 37.x.y.z) tak já na svém počítači i mobilu to mám zelený a on na moje připojení, který je vlastně OK to má červený a to jak ve Windows 10, tak i na čerstvý instalaci Ubuntu 20.04.3 LTS dokonce i se zapnutým firewalem GUWF.
Jak může na stejné IP adrese to mít vše špatně a já dobře?
Tiskni
Sdílej: