Byla vydána třetí opravná verze 19.3 v únoru vydané verze 19.0 multimediálního centra Kodi (dříve XBMC, Wikipedie) s kódovým označením Matrix.
Společnost Trump Media & Technology Group (TMTG) založena bývalým prezidentem USA Donaldem Trumpem spouští sociální síť Truth Social. Ta je založena na open source sociální síti Mastodon, jejíž zdrojové kódy jsou k dispozici pod licencí AGPLv3 (GNU Affero General Public License). Zdrojové kódy Truth Social ale k dispozici nejsou a tím pádem je licence AGPLv3 porušována. Dle organizace Software Freedom Conservancy má TMTG 30 dnů na nápravu, tj. zveřejnění zdrojových kódů Truth Social. Pokud se tak nestane, přijde o práva ke zdrojovým kódům sítě Mastodon.
Fabio Loli vydal verzi 21.10 časové osy linuxových distribucí Linux Distributions Timeline. Ke stažení je png i svg. Jedná se o fork již neaktualizovaného GLDT (GNU/Linux Distribution Timeline).
Rozšíření Visual Studio Code "Language Support for Java(TM) by Red Hat" dospělo do verze 1.0. Přehled novinek s náhledy a videi v příspěvku na blogu.
Bylo oznámeno, že konference FOSDEM 2022 (Free and Open source Software Developers’ European Meeting) proběhne online o víkendu 5. a 6. února 2022.
Dactyl-Manuform (kombinace Dactyl a Manuform) je svého druhu populární typ ergonomické klávesnice. Existuje několik parametrických generátorů variant šasi pro 3D tisk, řada forků a dokonce několik drobných výrobců nabízí sady nebo již sestavené klávesnice: patří mezi ně např. Bastard Keyboards (dříve HID Technologies), jenž nyní zveřejnil schémata tvrdých ohebných PCB ([1] [2]) pod licencí Creative Commons BY-NC-SA 4.0. Oproti původnímu ručnímu drátování je to krok k více funkcím (podsvícené či hotswap spínače) a příp. sériové výrobě.
Byla vydána verze 1.56.0 programovacího jazyka Rust (Wikipedie). Současně byla edice Rust 2021 prohlášena za stabilní. Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
V PHP byla nalezena bezpečnostní chyba CVE-2021-21703 zneužitelná k lokální eskalaci práv. Opravena je v upstream verzi 8.0.12.
Na Crowd Supply běží kampaň na podporu zařízení KrakenSDR s pěti přijímači RTL-SDR. Lze je používat nezávisle nebo současně jako radiozaměřovač nebo pasivní radar.
Implementace OpenPGP Sequoia PGP byla přelicencována z GPL 2+ na LGPL 2+. Vývojáři to zdůvodňují na dvou příkladech: Apple nepovoluje GPL software ve svém App Storu a problém s GPL má také Thunderbird.
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:
