Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
Google Chrome 152 byl prohlášen za stabilní. Nejnovější stabilní verze 152.0.7977.64 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 327 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Před 35 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
Apple představil čipy M6 a M5 Ultra, Mac mini s M6 nebo M5 Pro a Mac Studio s M5 Max nebo M5 Ultra. Fedora Asahi Remix zatím podporuje jenom M1 a M2.
Firefox 157 přinese zapnutou podporu rastrového grafického formátu JPEG XL. Založena je na v Rustu napsané implementaci jxl-rs používané i v Chrome a Chromiu.
Vanilla OS 3 „Reunion“ byl vydán. Tato na Debianu „Sid“ založená desktopová distribuce s transakčními aktualizacemi „neměnného“ základního systému (ABRoot) nově podporuje architekturu arm64 (vedle x86-64), podporuje reprodukovatelné sestavení většiny balíčků a vylepšuje systémové nástroje. Vlastní meta-správce balíčků APX nyní používá Distrobox v2 a je dostupný i pro jiné distribuce.
vconfiga prikazem
ip addr add xx.xx.xxx.xx brd + dev XXX. Ma to vubec nejakou souvislost ?? dekuji za trpelivost a pouceni.Je docela dost mozne ze momentalne ani presne nevim o cem mluvim, takze asi i motam dve rozdilne veci. Jeste jednou diky .
20.12.2005 00:33
Yin | skóre: 39
| blog: Yinotopia
| Slovesnko, Košice
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
$ man vconfig > .1; man ip > .2; diff -u .1 .2; rm -f .1 .2
20.12.2005 00:36
Yin | skóre: 39
| blog: Yinotopia
| Slovesnko, Košice
man vconfig a man ip, ja nemám nainštalovaný ani jeden z nich, takže to musíš zvládnuť sám.
.
Nejprve je třeba si ujasnit, co to je VLAN, definovaný normou 802.1q. V zásadě jde o trik, jak jednou fyzickou ethernetovou sítí (a jedním fyzickým rozhraním) táhnout více logických ethernetových sítí, které "se vzájemně vůbec nevidí". Dosáhne se toho tak, že hlavička ethernetového rámce je rozšířena mj. o číslo VLANu, a každý rámec jdoucí oním fyzickým ethernetem si nese "svoji nálepku", do kterého VLANu patří.
Příklad: Na Linuxovém stroji příkazem vconfig add eth0 10 a vconfig add eth0 20 vytvoříte dvě nová zařízení, eth0.10 a eth0.20. Když na nich nastavíte nějaké IP adresy a začnete jimi posílat nějaký provoz, pak data odcházející z eth0.10 odejdou fyzickou síťovkou eth0 a budou mít "nálepku", že pocházejí z VLANu 10.
Analogicky příchozí provoz přitékající do síťovky eth0 je prozkoumán a z rámců se přečte nálepka, do kteréhože VLANu patří, a takový rámec je pak předán například na eth0.10, anebo na eth0.20, případně bude úplně zahozen (například pokud by měl VLAN ID 30).
Celé toto uspořádání slouží, jak už bylo řečeno, k vytvoření více logických ethernetových sítí nad jednou fyzickou, jde tedy o mechanismus 2. síťové vrstvy a musí jej podporovat všechna zařízení v dané fyzické LAN.
Příkazem ip a a prostě k jednomu síťovému zařízení můžete přidat více IP adres, a vytvořit tak více logických IP sítí nad jednou fyzickou ethernetovou (či jinou) sítí. To je mechanismus 3. vrstvy.
Sečteno a podtrženo: jde o dvě zcela různé věci, používané ke zcela rozdílným účelům. V některých situacích se používá to, v jiných ono, závisí na konkrétní potřebě, čeho že chcete dosáhnout.
ippridal dalsi IP adresu z verejneho sektoru.Nyni vse zda se funguje, lec mam pocit ze ne tak jak by mnelo.
Zapeklitý případ... 
Máte tedy jednu LAN, v ní jeden blok adres privátních, následně NATovaných, a druhý blok adres veřejných. Samozřejmě vám stačí obejít se bez VLANů a na rozhraní brány do té LAN nastavit dvě IP z toho a onoho bloku. To je zcela korektní a funkční řešení, s jediným "drobným" ale...
Ale spočívá v tom, že nemusí správně fungovat situace, kdy PC s privátní adresou v dané LAN zkusí komunikovat s jiným PC s veřejnou adresou v téže LAN. Tato situaci zavádí celou soustavu obskurních problémů, a její řešení může být velmi obtížné. (Vemte si tužku a papír, a zkuste si namalovat, jak jde požadavek, kde a jak se NATne, jak jde odpověď...)
Složitější řešení pomocí VLANů by spočívalo v tom, že byste v rámci dané LAN vytvořil dvě logické LAN pomocí dvou VLANů, v jedné z nich by běhala jen privátní IP, ve druhé jen veřejná IP. Brána by pak měla dvě VLANová rozhraní, na každém jednu adresu. Problém přímé komunikace veřejné a neveřejné adresy tím odpadá.
VLANové řešení by sice bylo neprůstřelné, ale je otázka, nakolik snadno je implementovatelné. V nejjednodušším případě metalické LAN s jedním switchem stačí, aby switch uměl 802.1q VLANy, a celé nastavení uděláte na něm a na bráně. Pokud je fyzická topologie LAN složitější, může být implementace VLANů obtížná, až velmi obtížná.
Jak už jsem říkal v předchozím příspěvku, to záleží , nějaký definitivní soud od zeleného stolu udělat nelze, respektive, bylo by to nezodpovědné.
co doporucuje te namisto nej ?. Co z toho zvlada VLAN a co ne __?? nebo je to otazka jadra ?? ..
Problém podpory se rozpadá na věci:
1. Fyzická schopnost přenášet VLANy. Maximální délka ethernetového rámce je 1500B, pokud jde o tagovaný rámec (tedy rámec s "nalepeným" číslem VLAN), může mít délku maximálně 1504B. Některá zařízení (například stařičké karty 3com, pokud vím) to prostě neumějí, tak dlouhý rámec nepřenesou, a síť nefunguje.
2. Logická podpora VLANů. U některých zařízení bude nutné, aby měly vnitřní povědomost o VLANech, tedy ne, aby je jenom přenášely, ale aby uměly tagovaný trunk rozbít na netagované.
Co se týče routerů, není problém ani s jedním bodem. VLANy jsou v jádře podporovány už leta, a každá dneska koupená síťovka (včetně těch realteků) s VLANy problém nemá.
S těmi rádii to může být problémové, netuším, co umějí a jak.
Každopádně, v tomto uspořádání bych měl z implementace VLANů docela obavy. Raději bych si dal tu práci a pořádně promyslel routing a NATy tak, aby obojí adresy kooperovaly. Bude to nejspíš jednodušší.
Tiskni
Sdílej:
