Poslední příspěvky

Stran: 1 [2] 3 4 ... 10
11
Studium a uplatnění / Re:Jak učit dětičky na základní škole?
« Poslední příspěvek od Jiří Poucha kdy 15. 11. 2024, 21:09:28 »
Mintaka: já myslím, že si nerozumíme. Linux nijak nehaním, ani nehodnotím, bavíme se o výuce, o tom co a jak učit. Reaguju na pokus o flame, že linux není důležitý obsah. Ano, našel a rozvinul jste talent, který dneska linux bravurně ovládá. Ale to není argument, proč bychom se měli linuxem zabývat v "základním kurzu". Rád si to přišel vyjasnit osobně, kde a kdy ty pondělní kroužky jsou?

Každý, kdo do procesu vstupuje, má určeno, co bude učit, ale když to striktně určeno nemá, tak si látku nesmí vybírat, aby to hlavně bavilo jeho, ale jen a pouze podle toho, co potřebujou ty děti. Tím neříkám, že učitele učení nemá bavit, tím říkám, že primární je vždy rozvoj dítěte. Každého jednotlivého, bez ohledu na jejich talent. Souzním s názorem učitele dílen, který říkal, že jeho cílem nikdy nebylo, aby měl v každé třídě pět budoucích inženýrů, ale aby si všichni jeho žáci uměli zapojit zásuvku a schodišťák.

Obávám se, že u prvňáčků žádná smysluplná představa, co to je operační systém, nevzniká ani při intenzivním používání  ICT a nečekám, že by se to po sebelepším vysvětlování změnilo. Moc dobře si pamatuju z gymplu, jak marné byly pokusy
vyučovat informatice patnáctileté slečny.
Moje pedagogické působení se omezilo na občasné doučování MFCh, odvedl jsem dohromady asi tři semestry úvodních laborek z elektroniky na FELu a tři bakalářky. Před covidem jsem učil jednoho Aspergera programovat jednočipy, to bylo k tématu této diskuse zdaleka nejvýživnější.
12
Sítě / Re:Připojení ke SmartTV přes síť (ne bezdrátový displej)
« Poslední příspěvek od Ge Bu kdy 15. 11. 2024, 20:14:26 »
Někde to takto máme, dokonce s uchycenou zásuvkou (neleží volně) např. v liště. Žel to také spolehlivé není. Notebooky mají zřejmě různé výkony signálu a každý spoj navíc se projeví. Zvlášť, když se tak často používá. Po určité době se ochodí female podle typu notebooku to postupně přestává fungovat.

Asi jsem staromodni, ale ja bych do TV pripojil HDMI prodluzku, kabel v liste privedl az nekam ke katedre ci u ceho sedi ucitel, tam do prodluzky zapojil klasicky male-male HDMI kabel a ten vyvedl v dostatecne delce na stul.

Konektor v televizi bude porad pripojeny, nic ho neohrozi a kdyz je ten male-male HDMI kabel ochodi, za par korun se vymeni.

Podstatne spolehlivejsi nez jakeholiv sitovani nebo dokonce wifi, nehlede na nulovou potrebu cokoliv instalovat na ucitelske pocitace.
13
Sítě / Re:Připojení ke SmartTV přes síť (ne bezdrátový displej)
« Poslední příspěvek od Tomáš Rollo kdy 15. 11. 2024, 19:53:21 »
Asi jsem staromodni, ale ja bych do TV pripojil HDMI prodluzku, kabel v liste privedl az nekam ke katedre ci u ceho sedi ucitel, tam do prodluzky zapojil klasicky male-male HDMI kabel a ten vyvedl v dostatecne delce na stul.

Konektor v televizi bude porad pripojeny, nic ho neohrozi a kdyz je ten male-male HDMI kabel ochodi, za par korun se vymeni.

Podstatne spolehlivejsi nez jakeholiv sitovani nebo dokonce wifi, nehlede na nulovou potrebu cokoliv instalovat na ucitelske pocitace.
14
Sítě / Re:jaktože wlan extender má svůj dns záznam
« Poslední příspěvek od František Ryšánek kdy 15. 11. 2024, 19:13:10 »
Ohledně DNS záhady:
1) výrobci těchto krabiček (extenderů) mají vcelku svobodu, co si kdo naprasí do firmwaru
2) možná se zkuste mrknout, co dělá Bonjour / ZeroConf / uPnP a hlavně mDNS. Něco z toho se Vás může týkat.
Hint: APčka tohle často umí.
Na straně klienta: v operačním systému je knihovna, která zkouší přeložit jména pomocí mDNS. Tahle knihovna či plugin se zavěsí do "systémového všeobecného jmenného resolveru" vedle standardního DNS, lokálních překladů z /etc/hosts apod. Ten client-side zastřešující resolver se v Linuxu tuším jmenuje libnss.

Ohledně wifi extenderu v tříadresním režimu díky za zajímavé téma. Dost hlavolam. Něco jako Mikrotik station pseudo-bridge s překladem MAC adres, akorát v režimu vzduch-vzduch. Nebo by extender musel sledovat, který klient je schopen odpovědět sám za sebe, a pokud od něj nevidí ack, tak forwardnout/zopakovat původní "dotaz" od AP, a pokud jemu už klient odpoví, tak forwardnout zpátky APčku se src rádiovou MAC adresou klienta... nebo tak nějak, divočina.

Čtyřadresní backhaul je oproti tomu relativně jasnej (jako po kabelu) - ale to zas musí podporovat taky hlavní APčko, na které se ten extender pověsí, ten čtyřadresní spoj by musel asi jet jiným ESSIDem, než který slouží tříadresním čistým klientům... není to jenom otázka "zapnu extender a jedu, a je jedno, jestli o mně AP ví že jsem extender".

Klíčová slova: WDS a 802.11s
15
Sítě / Re:Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od RDa kdy 15. 11. 2024, 18:50:37 »
Ta dvoji by sla takto:

Kód: [Vybrat]
# vconfig add lan 15
Added VLAN with VID == 15 to IF -:lan:-
# vconfig add lan 90
Added VLAN with VID == 90 to IF -:lan:-
# ifconfig lan mtu 9000
# ifconfig lan.15 mtu 1500
# ifconfig lan.90 mtu 9000
# ifconfig lan.15 up
# ifconfig lan.90 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
lan.15: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lan.90: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
16
Mně to taky připadá jako téma na hezké programování v C(++) a BSD sockets API.
Kladu si otázku: co řešíte za specifický problém?

Potřebujete distribuovat nějaké soubory, a těch dat je příliš mnoho, než aby to 1Gb linka na straně serveru zvládla přenést všem klientům, ale pokud se to bude multicastovat, tak se to vejde/stihne?
Klienti potřebují vždy všichni tentýž soubor ve stejném čase? Je v tom případě potřeba, aby si o něj sami říkali? Nemůže mít server informaci, který soubor budou klienti potřebovat, a prostě ho "odvysílá" o své vůli? Musí server čekat, až budou všichni klienti připraveni, a tedy čekat až všichni projeví zájem?

Našel jsem jednu aplikaci, kde něco velmi podobného funguje. Cílový business model je "digital signage" = zobrazování reklamy na obrazovkách v síti, kde u každé obrazovky je malý lokální počítač s vlastní úložnou kapacitou. A říkají k tomu, že se jedná o "push delivery" souborů na klientské stroje (přehrávače).

Pokud by měl server dělat retransmise, pokud byť jediný klient signalizuje, že data nedostal, může se snadno smazat úspora, která z multicastingu plyne. Pokud se počet retransmisí neomezí, může to dopadnout volně v intencích toho co lze vidět na CANbusu při nějaké poruše fyzické vrstvy: jeden uzel stále dokola vysílá tutéž zprávu, ale všechny ostatní datové toky se zastaví :-) Princip toho jevu je podstatně odlišný, ale to deja-vu je silné :-)

Když mluvíte o multicastingu, plánujete "přihlašování k odběru" pomocí IGMP ? (Pokude ne, bavíme se efektivně o broadcastingu...)

Vypadá to na zábavné téma k analýze, ale chtělo by to trochu víc vstupních informací, aby stálo za to nad tím dumat :-)
17
Sítě / Re:Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od RDa kdy 15. 11. 2024, 18:48:34 »
nastaveni MTU 9000 na eth0 projde?

Ano, projde to timto stylem i separatne:

Kód: [Vybrat]
# vconfig add lan 123
# ifconfig lan mtu 9000
# ifconfig lan.123 mtu 1500
# ifconfig lan.123 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
lan.123: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Ale na kyzeny opacny stav (vlan s vyssi MTU) ne:

Kód: [Vybrat]
# vconfig add lan 123
# ifconfig lan mtu 9000
# ifconfig lan.123 mtu 9000
# ifconfig lan mtu 1500
# ifconfig lan.123 up
# ifconfig | grep mtu
lan: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lan.123: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Ta VLAN ma omezeny MTU na hodnotu ktera je aplikovana na nativni rozhrani.

Mozna tedy je sance, ze by zarizeni v dvoji siti meli pouze tagovane vlany, tj. obe dve nad fyzickym rozhranim, ktere by se pak uz dale nepouzivalo - a pak by tohle vyzadovalo bud manazovany switch nebo router s nastavenim te 1500 vlany jako dalsiho lan segmentu + nutnost mezi tim routovat. Pochybuji ze by byl dobry napad spojovat do bridge sit, ktera je fyzicke rozhrani a jedna tagovana vlan z nej, na tom routru.

Pridavam dalsi pozadavky/predstavy:
 - v 1500 siti se musi dorozumet vsichni se vsema a maj pristup na internet, jede tam dhcp
 - v 9000 siti neni pristup ven na internet, jen mezi specifickyma zarizenimi (a muzou mit staticke ip)
18
Sítě / Re:Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od czipis kdy 15. 11. 2024, 18:33:51 »
nastaveni MTU 9000 na eth0 projde?
19
Sítě / Re:souběžný posílání souboru na všechny ethernetové porty multicastem
« Poslední příspěvek od RDa kdy 15. 11. 2024, 18:21:33 »
Tak si neco takoveho napis, ze to bude distribuovat obsah v plovoucim okne a dokud vsichni prijemci nepotvrdi dokad ten obsah maji, tak se okno nebude posouvat a bude to delat retransmise.

Alternativne muzes pouzit namisto multicastu daisy-chain, ze kazdy klient vyjma posledniho bude jakoby proxy. To by slo zhackovat snad velice rychle skrze nejaky http proxy s lokalni cache... na 1..N-1 nastavis proxy, a na N-tem udelas wget :D

Rychlostne by to melo mit stejne parametry jako multicast, jen to bude mit vyssi spotrebu (protoze kazdy port ve switchi naplno vyuzije oba smery, vyjma prvniho a posledniho).
20
Sítě / Jumbo frames v kombinaci s VLAN
« Poslední příspěvek od RDa kdy 15. 11. 2024, 17:51:42 »
Snažím se (zatím v linuxu) nastavit sdílenou síťovku skrze VLAN do dvou sítí na různé MTU a nejde to.

Představa cílového stavu je:
eth0 s MTU 1500, subnet hlavni
eth0.10 s MTU 9000, subnet jiny


Při nastavení MTU pro rozhraní s VLAN (eth0.10) se vrací s jakoukoliv hodnotou:
Kód: [Vybrat]
SIOCSIFMTU: Numerical result out of range
Při nastavení MTU pro netagovanou síť (eth0) se tato hodnota projevuje o obou rozhraní (eth0, eth0.10)

Existuje nějaké řešení ?

Lze omezit na linuxu a macu MTU na vrstvě IP podsítě ?

Situace je: klasická domácí síť s hromadou různorodých zařízení má několik zařízení, mezi kterými chci provozovat ty jumbo frames (řekněme několik pracovních stanice a NAS), bez toho, abych musel tahat duplicitní kabeláž. Představa byla nasadit tagovanou VLAN, kde může tento jumbo provoz probíhat. A ejhle.. nejde to. WTF.
Stran: 1 [2] 3 4 ... 10