Byla vydána Java 20 / JDK 20. Nových vlastností (JEP - JDK Enhancement Proposal) je 7. Nová Java / JDK vychází každých 6 měsíců. LTS verze je 17.
Google spustil konverzační AI Bard. Vyzkoušet lze zatím pouze ve Spojených státech a Spojeném království. Více v Bard FAQ.
David Buchanan na svém blogu rozebírá zranitelnost acropalypse (CVE-2023-21036) telefonů Google Pixel. Z výřezu (crop) snímku obrazovky vytvořeného integrovanou aplikací Markup může být možné částečné obnovení původního snímku obrazovky. Viz tweet Simona Aaronse. Vyzkoušet lze webovou aplikaci acropalypse.app. Opraveno v březnové aktualizaci.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) byla vydána v nové verzi 1.19.0. Přehled novinek i s náhledy v příspěvku na blogu. Kvůli "převzetí Gitei" společností Gitea Limited byl v prosinci loňského roku představen fork Gitei s názvem Forgejo (Codeberg).
Byla vydána nová verze 5.11 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Nově je používán zram. Tor Browser byl aktualizován na verzi 12.0.4. Thunderbird na verzi 102.9.0.
Na GOG.com běží Spring Sale. Při té příležitosti lze získat zdarma počítačovou hru Lorelai (ProtonDB).
Curl, řádkový nástroj a knihovna pro přenos dat po různých protokolech, slaví 25 let. Vydána byla nová verze 8.0.0. Mimo jiné řeší 6 zranitelností.
V sobotu 25. března proběhne Arduino Day 2023. Od 14:00 lze sledovat oficiální stream. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.
Fabrice Bellard, tvůrce FFmpeg nebo QEMU, představil TextSynth Server. Jedná se o webový server nabízející REST API k velkým AI jazykovým modelům. CPU verze je k dispozici zdarma jako binárka pod licencí MIT. GPU verze je komerční. Vyzkoušet lze na stránkách TextSynth.
Na konferenci LibrePlanet 2023 byly vyhlášeny ceny Free Software Foundation. Oceněni byli Eli Zaretskii za dlouhodobé příspěvky (správce Emacsu), Tad „SkewedZeppelin“ za nové příspěvky (správce DivestOS, distribuce Androidu) a projekt GNU Jami za společenský přínos.
Už na zemi bude problém s nanoboty.
Pro mezigalktický internet se bude využívat zakřivení prostoru a další rozměry, takže mu rychlost světla postačí.
a za druhé aby si každý mohl přidělený rozsah rozdělit na podsítěKdyž dostanu /64, tak už si to na podsítě rozdělit nemůžu, a to ani kdybych nechtěl používat SLAAC, ne?
protože dnes má pár podsítí každá domácnost (minimálně LAN a WiF)V mnoha domacnostech tvori lan a wifi jednu podsit (z hlediska sitove vrstvy).
Podle mne to není úplně v pořádku koncepčně, jsou to dvě fyzicky odlišné sítě, veškerý provoz mezi nimi musí jít přes jedno zařízení – podle mne je správné, aby tím zařízením byl router.
Pokud bychom tento argument považovali za dostatečný, můžeme prohlásit za špatný jakýkoli bridge a v podstatě jakýkoli ethernet používající více samostatných switchů. Pokud by "fyzicky odlišné" mělo znamenat různou fyzickou implementaci, tak co třeba bridge použitý pro zpřístupnění xen/KVM hosta?
Už jenom proto, že WiFi zpravidla sahá i ven z bytu nebo baráku a může se k ní pokoušet připojit kdokoli, zatímco připojit se přes LAN zpravidla znamená dostat se ke kabelu uvnitř bytu nebo baráku.
To už je samozřejmě jiná, ale to je věc konkrétního správce, jak si stanoví pravidla (a jak má tu wi-fi zabezpečenou).
Více switchů je něco jiného – switch je jen zdokonalený hub, který pokud si je jist, že nějaký paket stačí poslat na jeden port, neobtěžuje tím ostatní porty.
Switch a bridge jsou jen dva různé názvy pro stejnou funkci.
Liší se to například tím, že při komunikaci dvojic zařízení A s B a C s D se ty dvě komunikace navzájem neovlivňují (v ideálním případě), protože komunikují přímo mezi sebou. Pokud A a C budou v jedné síti a B a D v druhé síti a ty sítě budou propojené bridgem, ty dvě komunikace se ovlivňují, protože jdou přes společný prvek a dělí se o jeho kapacitu.
V tom ale žádný rozdíl není, oboje platí jak pro switch, tak pro bridge (pochopitelně - je to totiž totéž).
Rozdíl je v tom, zda je to zařízení v centru jedné sítě, nebo zda propojuje dvě jinak samostatné sítě.
Jak se to pozná? Jak se prinicipiálně liší "jedna síť v jejímž centru je X" a "dvě jinak samostatné sítě propojené X", ať už si za X dosadíte switch nebo bridge?
Pokud chce kdokoli z jednoho pobřeží komunikovat s kýmkoli z druhého pobřeží, musí přes jeden most, "bridge", který ty dvě sítě spojuje.
Bridge také nemusíte mít jenom jeden. Třeba u toho příkladu s xen DomU je celkem běžné, že každý interface má svůj bridge. A stejně tak může mít bridge víc než dva porty.
pořád je rozdíl v tom, jestli se na něco dívám jako na jednu síť nebo na dvě propojené sítě.
Jinak řečeno: na úplně stejně fungující síť se můžete dívat dvěma různými způsoby a podle toho ten prvek označit dvěma různými termíny, ale z funkčního hlediska je to úplně totéž.
Když budu chtít propojit dvě sítě do jedné, asi mezi ně nebudu dávat 32portový switch. A když budu chtít propojit několik počítačů do jedné sítě, asi nebudu mezi každé dva počítače dávat bridge.
To, že počet portů zařízení volíte podle toho, kolik jich potřebujete, a to, že topologii se snažíte volit co nejjednodušší, nijak nesouvisí s otázkou, jestli je mezi funkcí bridge a switche nějaký principiální rozdíl (které se stále nápadněji vyhýbáte).
a to je to, co si pod tím člověk nejprve představí
A to je celý problém. Já se nebavím o tom, co vy si představujete. Já se bavím o tom, jak ta zařízení fungují.
Mne by nikdy nenapadlo nazývat síťovou kartu „ethernetovým segmentem“.
Mne také ne. Ale jak to souvisí s příspěvkem, na který odpovídáte?
To už je samozřejmě jiná, ale to je věc konkrétního správce, jak si stanoví pravidla (a jak má tu wi-fi zabezpečenou).Zcela nový rozměr to dostává, když zařízení se zapnutým Wi-Fi Sense ochotně sdělí heslo k síti všem kontaktům. Zabezpečení privátním klíčem (ten doufám Wi-Fi Sence nesdílí) není v domácích sítích zrovna běžné, a podle mne většina lidí nepovažuje svou domácí síť za veřejnou a nechová se tak k ní. Ale pokud někdo chce, aby na jeho tiskárně mohl tisknout kdokoli, kdo jde zrovna kolem po ulici, ať si poslouží…
Hm, jenže když to bude routovaný, tak se rozbijou ty autodiscovery protokolyJirsáka bych si vůbec nevšímal. Člověk chce mít doma jednu síť, bez ohledu na to, co k ní připojí po wifi a co po drátě. Ta síť má tudíž mít jeden IP rozsah pro každou použitou verzi protokolu a vše má fungovat úplně stejně jako by to bylo vše zadrátované. Druhá síť má smysl jen pokud je její účel nějak odlišný od té první, například když člověk doma provozuje malou serverovnu nebo nějaké experimentální sítě.
A taky je problém v tom, že routování je výpočetně náročnější než bridgeNevěřím, že poznáš rozdíl mezi routingem a bridgem u linuxového routeru.
Nevěřím, že poznáš rozdíl mezi routingem a bridgem u linuxového routeru.Tak docela velký rozdíl je v tom, že bridge u IPv4 nemusí u každého paketu přepočítávat checksum.
Pokud chci na drátu 1G tak routing je nereálný v domácích podmínkách.Nejsem si vědom podmínek, kdy by byl routing nereálný a soft bridging reálný, ty packety prochází pokud vím úplně stejným stackem.
A je vlastně soft bridging na 1G reálný?Není o nic méně reálný než soft routing ;).
Myslel jsem tím, že pokud budu mít domácí drátovou síť na 1G propojenou switchemPři srovnání routingu a soft bridgingu je switch jaksi mimo kontext. Nicméně Ondrova odpověď dává vědět o tom, že zásadní rozdíl už dlouho nedělá bridging versus routing, ale software versus hardware.
Aby byl rozdíl výraznější, tak něco trochu staršího HW: http://routerboard.com/RB433L Bridging 64 byte - 63.8 Mbps Routing 64 byte - 52.1 MbpsStarší hardware, malé pakety, rozdíly kolem 20%, dejme tomu. Jenom bych se ještě ujistil, že se jedná o software bridging a ne switching.
Když se nastaví nějaké filtrování, tak mohou být nepříjemně velké rozdíly i na dnešním HW.O filtrování nebyla řeč, navíc lze stejně dobře provádět u bridge jako u routingu, takže mi není jasné, proč to sem taháš.
asi je to trochu rizikové, protože autokonfigurační mechanismy počítají s max. /64 na síť, protože těch zbylých 64 bitů na počítače využijí kompletVe skutečnosti to platí jen pro jeden z mechanismů automatické konfigurace, ale v nějakém RFC jsem to pravidlo četl jako obecně platné, nejspíš to bylo IPv6 Addressing Architecture nebo nějaké takové, a to už dává jen politický smysl (přesvědčit všechny, aby byly ready na SLAAC a přidělovali velké rozsahy), nikoliv technický.
počítám, že také postupem času budou přibývat zařízení s hw optimalizací|akcelerací a tam by to pak byl také značný problém...To mi přijde jako příliš vágní zdůvodnění.
To je jednoduché: IPv6 je překombinovaná a přeinženýrovaná sračka, která ani přes neustálé vydávání nových RFC pořádně nefunguje (viz např. patička).Ono není moc bezpečné ani provozovat tu IPv4, ale to není dostatečně lukrativní téma.
Takže nepřekvapí, že na začátku vývoje IPv6 byli všichni podělaní z toho, že bude adres málo, tak navrhli 128 bitů. Pak se zjistilo, že to vlastně až tak málo není, tak nějaká „chytrá“ hlavička vymyslela způsob, jak tento adresní prostor spolehlivě promrhat... „Toto je jediná část komentáře, která se nějak týká dělení adresního rozsahu, je střelená od boku a nesmyslná. Doufám, že to Petr označil jako řešení omylem, to není tlačítko like ve stylu facebooku.
Tiskni
Sdílej: