Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Řešení dotazu:
hodne experimentujem s Linuxom - Debian.
Tam čistota opravdu nehrozí. Na experimentování doporučuji solidní dostro, nikoliv nejhorší distro na světě.
Aby som tieto projekty rozbehal, je nutne nainstalovat kniznice a ine zavyslosti z repozitarov alebo kompilovane zo zdrojakov.
Na slušném distru se dá 99% tohoto ušetřit. Když zkusíš náhodných 20 projektů z GitHubu, aktuálních a udržovaných, prostě přeložit (dejme tomu) na současném Archu a závislosti si nainstaluješ ze standardních distribučních balíků, jak to má být, rozběháš těch projektů (dejme tomu) 18 z 20.
Na Debianu možná tak 5 z 20 a to budeš rád. Zbytek bude peklo, zastaralé verze, verze zmrvené pro Debian, a tak dále.
Nemluvě o tom, že na Archu je ultra-jednoduché udělat si PKGBUILD a všechno mít rovnou jako balíček (s korektní správou souborů a (od)instalací). Na Debianu je tvorba vlastních balíčků prakticky nemožná záležitost, pokud se tomu člověk nechce věnovat full-time.
Ako cas siel, z disku sa stalo jedno velke smetisko - cca 50GB projektov vlastnych aj cudzich proste bordel.
Zásda číslo 1: nikdy neinstalovat nic pod rootem přímo ze zdrojáků (stylem make install). Od toho je na slušných distrech fakeroot používaný balíčkovacím manažerem, už odnepaměti.
Záchrana číslo 1: prostě vyhledat ničím nevlastněné soubory mimo /home (leč bacha na /etc a na adresáře končící na .d atd.) a smazat je.
Dostal som sa do "dependency hell" stavu a problemy so zavislostami - rozbil som si Debiana.
Možná. V každém případě, Debian je rozbitý už sám od sebe, z principu.
Vysledok bol cisty reinstall a zahodenie vsetkeho balastu - ten bordel sa nedal ani rozumne vytriedit.
Ale ano, dal. Jenže na rozumném distru by především ani nevznikl.
Mal som supercisty zaklad na kancelarsku pracu s virtualboxom.
Proč takový šílený overkill? Pokud experimentuješ s několika instancemi téhož systému (stejná architektura, stejný kernel) a liší se jenom obsah souborového systému, od toho jsou LXC kontejnery.
Nejlepší tool na tohle je virt-manager a libvirtd. V jednom společném UI máš
Ale problem bola obsluha - virtualka fullscreen - nevedel som si na to zvyknut, odozvy misi a klevesnice - bolo tam citelne mikrooneskorenie.
Když chci nativně fungující virtuálku (například FreeBSD jako virtuálku v Linuxu), dám té virtuálce přes virt-manager + KVM celou grafickou kartu přes VFIO, například celou tučnou NVidii v eGPU. A k tomu taky nějaký ten Thunderbolt USB hub (skrz PCIe + VFIO). Pak má prostě (de facto) nativní výkon.
Pokud jde o virtuálku v okně, zpoždění není tak hrozné, když si tam v KVM zprovozníš virtio, k tomu případně Spice, a k tomu taky (skrz virtio) grafickou akceleraci.
Nicméně tohle↑ je pořád o scénáři typu jiný systém / jiný kernel. Pro stejnou architekturu + stejný kernel, jenom jiné soubory, potřebuješ LXC kontejner. Pak všechny starosti s latencí zmizí.
Strata vykonu bola citelna aj ked som robil len v jednej VM.
LXC → Nulová ztráta výkonu.
KVM + libvirtd virtuálka + virtio balloon + rozumně nastavené SMP → Zanedbatelná ztráta výkonu.
Stačí si vybrat.
Mate nejake napady ako udzat cisty system, nerozbit si ho a popritom si skusat a ucit sa.
Není třeba mít nápady. Stačí používat standardní a desetiletími prověřená řešení (místo ad-hoc hacků všeho druhu):
/home mezi nimi třeba může být sdílený, pokud je to žádoucí. Nebo taky nemusí.Hlavně je potřeba na takové věci trochu myslet předem, dřív než uživatel začne vytvářet bordel.
Na Debianu je tvorba vlastních balíčků prakticky nemožná záležitost, pokud se tomu člověk nechce věnovat full-time.
Sorry, ale plácáš blbosti. Práce na full-time je to za předpokladu, že chceš svoje balíky dostat do oficiální distribuce. Pokud si děláš balíky jen pro svou potřebu, tak není problém.
Ten člověk v tom má evidentně guláš, takže si stadiem zabordeleného systému projde bez ohledu na distribuci. Debian mu ale naopak nedovolí ten systém rozesrat totálně. Jenom se musí naučit číst. APT je docela ukecaný a většinou se i snaží poradit co dál.
Debian mu ale naopak nedovolí ten systém rozesrat totálně.
Ano, to mu skutečně nedovolí, neboť Debian je totálně rozesraný už sám od sebe v momentě instalace.
Možná by se to dalo přirovnat k onomu prazvláštnímu způsobu obrany před šířením požárů, kdy se cíleně vypálí pás pole nebo lesa, aby se potom přes spáleniště nedostal větší požár… Leč soudě podle tazatelovy nespokojenosti s výsledkem, tohle přirovnání nejspíš nesedí. (Spáleniště nepomohlo.)
Nelze než doporučit vyhnout se Debianu. Uživatel může nadělat spoustu chyb s každou distribucí, to bezesporu, ale není důvod si situaci od začátku komplikovat tou nejhorší distribucí.
Debian je totálně rozesraný už sám od sebe v momentě instalace.A proto je to jedna z nejpoužívanějších linuxových distribucí na serverech.
napsat, ze strasne chces, aby ostatni vedeli, ze jsi totalni kokot, jde i kratsim zpusobem
Tiskni
Sdílej: