CrossOver, komerční produkt založený na Wine, byl vydán ve verzi 26. Přehled novinek v ChangeLogu. CrossOver 26 vychází z Wine 11.0, D3DMetal 3.0, DXMT 0.72, Wine Mono 10.4.1 a vkd3d 1.18. Do 17. února lze koupit CrossOver+ se slevou 26 %.
KiCad je nově k dispozici také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit [Mastodon, 𝕏].
Šenčenská firma Seeed Studio představila projekt levného robotického ramena reBot Arm B601, primárně coby pomůcky pro studenty a výzkumníky. Paže má 6 stupňů volnosti, dosah 650 mm a nosnost 1,5 kilogramu, podporované platformy mají být ROS1, ROS2, LeRobot, Pinocchio a Isaac Sim, krom toho bude k dispozici vlastní SDK napsané v Pythonu. Kompletní seznam součástek, videonávody a nejspíš i cena budou zveřejněny až koncem tohoto měsíce.
… více »Byla vydána nová verze 36.0, tj. první stabilní verze nové řady 36, svobodného multimediálního centra MythTV (Wikipedie). Přehled novinek a vylepšení v poznámkách k vydání.
Byl vydán LineageOS 23.2 (Mastodon). LineageOS (Wikipedie) je svobodný operační systém pro chytré telefony, tablety a set-top boxy založený na Androidu. Jedná se o nástupce CyanogenModu.
Od března budou mít uživatelé Discordu bez ověření věku pouze minimální práva vhodná pro teenagery.
Evropská komise (EK) předběžně shledala čínskou sociální síť pro sdílení krátkých videí TikTok návykovým designem v rozporu s unijním nařízením o digitálních službách (DSA). Komise, která je exekutivním orgánem Evropské unie a má rozsáhlé pravomoci, o tom informovala v tiskovém sdělení. TikTok v reakci uvedl, že EK o platformě vykreslila podle něj zcela nepravdivý obraz, a proto se bude bránit.… více »
Offpunk byl vydán ve verzi 3.0. Jedná se o webový prohlížeč běžící v terminálu a podporující také protokoly Gemini, Gopher a RSS. Přibyl nástroj xkcdpunk pro zobrazení XKCD v terminálu.
Promethee je projekt, který implementuje UEFI (Unified Extensible Firmware Interface) bindingy pro JavaScript. Z bootovacího média načítá a spouští soubor 'script.js', který může používat UEFI služby. Cílem je vytvořit zavaděč, který lze přizpůsobit pomocí HTML/CSS/JS. Repozitář se zdrojovými kódy je na Codebergu.
Zpráva Justičního výboru Sněmovny reprezentantů upozorňuje na cenzurní kampaň Evropské komise, mířenou proti svobodě projevu na sociálních sítích. V dokumentu se uvádí, že se Evropská komise během posledních šesti let účastnila více než 100 uzavřených jednání, během nichž po platformách požadovala úpravy pravidel moderování obsahu, přičemž toto úsilí Komise zahrnovalo i cenzuru politických názorů a pravdivých informací. Výbor zdůrazňuje, že tento přístup Bruselu ohrožuje ústavou zaručená práva Američanů na svobodu projevu.
Rád bych požádal o radu ohledně řešení problému. Současná situace:
Máme síť o 11 domácnostech, cca. 5 počítačů je zapojeno přímo přes UTP, ostatní přes Wifi 2,4 GHz. Celá síť přistupuje k síti internet přes linku ADSL, která je přes modem v režimu bridge připojena na PC, kde běží Debian. Zde je také nastaven NAT (a pak nějaké další služby, jako fileserver, ventrilo, OpenVPN).
Je to pár dní, kdy se packet loss lidí přes UTP (i Wifi, ale zde bych to připisoval na vrub technologii) při téměř nevytížené lince zvýšil z 0 % na 4 %.
Lokální PC --> (NAT)Debian --> nic.cz packet loss 4 %, avšak ping kolem 13 ms (v podstatě odezva našeho ADSL připojení)
192.168.123.131 --> 192.168.123.1 --> nic.cz
Avšak pokud tento PC budu pingovat přes OpenVPN, packet loss je 0 %.
Můj PC jinde v internet --> (routing)Debian --> Lokální PC
138.0.1.2 --> 138.0.1.1 / 192.168.123.1 --> 192.168.123.131
Packet loss mezi Debianem a lokálním PC je nulový, stejně tak jako mezi Debianem a serverem na internetu.
Z celé situace jsem vydedukoval, že za ztrátu paketů může přímo PC s Debianem. Iptables jsou v podstatě téměř prázdné, mimo nastavení NAT.
Jak bych měl dohledat a opravit zdroj tohoto problému?
Děkuji
Plna conntrack tabulka? Co rikaji logy.
Zkuste hledat ip_conntrack_max a ip_conntrack_tcp_timeout_established.
Děkuji za reakci.
ip_conntrack_max je nastavena mnohem vetsi, nez je opravdu potreba. Pocet spojeni zde v tuto chvili byl asi 225 (povoleno 65536)
ip_contnrack_tcp_timeout_established byl nastaven na 84000, snizil jsem ho ted na 3600, ale vliv to nemelo (a takhle uz ho asi necham)
Systémový log se k těm zahozeným packetům nevyjadřuje, do jakých logů se mám ještě podívat?
Neni na tom routeru pusteny nejaky shaper?
V tento moment packet loss zmizel.
Shaper je vyplý, používal jsem tam Promethea, ale při jeho používání začaly zlobit weby seznamu.cz (lide.cz, email.cz, apod.), tak je "odstavený".
Tak jsem to zakřikl, stále beze změny.. kolem 4 %.
Nerozumím pingu z Internetu na lokální PC. To kvůli překladu adres nejde.
Pokud máte trasu mezi strojem v Internetu a routerem zabalenou v OpenVPN, pak v jakém transportním protokolu? Pokud to je TCP, tak se není čemu divit, protože ten výpadky zamaskuje.
Doporučuji měřit ztrátovost na trase mezi routerem a strojem v Internetu. Měřit čisté IPv4 bez nějakých tunelů. A měřit každý směr zvlášť (na stroji, kam pingáte si přes tcpdump ověřte, že všechny ICMP echo request packety dorazí).
Tunel je TCP... děkuji
Na ten zbytek mrknu.
Vyřešeno!!!
Packet loss způsobovala síťová karta, přes kterou jsem byl bridgem připojen k ADSL.
Měl jsem původně za to, že stejně jako u win linux ztrátu paketů hlásí průběžně, né až v koncové statistice.
Děkuji všem za pomoc 
Většinu svého života se pohybuji u Windows a zde je ten řádek... vypršel časový limit.... proto i po roce je pro mě takováto věc novinkou 
Děkuji, zase jsem o něco chytřejší 
Avšak pokud tento PC budu pingovat přes OpenVPN, packet loss je 0 %.Protože i když bude packet loss na fyzické lince 90%, OpenVPN bude opakovat vysílání tak dlouho, než ten paket dorazí. Nebo zkráceně: ta hodnota vůbec o ničem nevypovídá
Tiskni
Sdílej: