Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Miroslav Šilhavý

Stran: 1 ... 22 23 [24] 25 26 ... 206
346
Sítě / Re:Dostatečný signál pro Chromecast v paneláku
« kdy: 27. 12. 2020, 19:13:23 »
chromecast nechci propojovat ethernetem, muselo by se asi vrtat do zdi..

Kriste pane, jestli jde o to udělat jednu dírku do zdi, tak ji udělejte. Ušetříte si spoustu starostí s WiFi, která má objektivně dost potenciálních problémů. Druhou možností je experimentovat, dokud nenajdete správná zařízení a správné rozmístění, aby to fungovalo. S tím Vám nikdo neporadí, protože se to liší místo od místa, situací od situace. Obvykle bývá to experimentování dražší, než překonat lenost, udělat průraz a trasu po kablík.

Jestli jdete signálem přes tři panelové zdi, tak si přestavte kolik je v nich armovacích želez.

347
Software / Re:Linux SW falešný RAID 0 (zrcadlení)
« kdy: 27. 12. 2020, 08:43:10 »
Tohle je znovuobjevování kola, přemýšlení, kterým si lidé prošli od devadesátých let.

Obyčejné dd na to stačit nebude, protože data nebudou konzistentní - nebo by se to muselo provádět offline. Offline by to šlo provést v rámci initrd, ale přijde mi to jako opičárna.

Prehistorická možnost je použít md raid a ve chvíli, kdy je vše synchronizované, pomocí mdadm odebrat disk. Při záloze ho zase přidat. Mělo by to být bezpečné, ale jen teoreticky. MD na to není určený - ten je určený k tomu, že oba disky jsou rovnocenné. Stačí selhání ve vyhodnocení toho, který z disků má starší, a který mladší data, a máte na světě synchronizaci opačným směrem, než chcete. Riziko není velké, ale existuje. MD bych se vyhnul.

Smysluplnější řešení jsou snapshoty v rámci ZFS / btrfs.

Pokud však jde o to mít možnost rychle obnovit systém, vyprdl bych se na obrazy disků. Obrazy disků jsou závislé na velikosti disku a ne vždy to potřebujete / chcete. Stejně rychle obnovíte z obyčejné zálohy.

Osobně bych použil obyčejné zálohování. Mám rád borg backup - rychle zálohuje, rychle obnovuje. Při havárii nainstalujete jen základní systém a borg a za chvíli natáhnete data ze zálohy. Výhodou bude vyšší rychlost, než u image a taky získáte deduplikovaný a komprimovaný archiv záloh v čase. Do stejného prostoru dostanete násobně víc záloh, než do obyčejného image.

348
Sítě / Re:Dostatečný signál pro Chromecast v paneláku
« kdy: 25. 12. 2020, 19:57:06 »
Jeste nikdy jsem u sebe ani u spousty svych kamaradu nikdy nevidel, ze by mikrovlna trouba uniky prepalila wifi. Je to pekna blbost.

Klidně přijďte, předvedu v praxi.

349
Sítě / Re:Dostatečný signál pro Chromecast v paneláku
« kdy: 25. 12. 2020, 13:36:48 »
Normální to tedy není, že mikrovlnná trouba něco vyzařuje do okolí, naopak by měla mít dostatečné stínění a nulové záření. A chůvičku bych sem netahal, protože ta je stavěná na přenos v pásmu 2,4 GHz a je to tedy v pořádku, byť samozřejmě může zarušit WiFi.

Nemáte pravdu. Mikrovlnné trouby zcela běžně něco málo vyzáří - a to něco málo na rušení WiFi bohatě stačí.
Stínění v troubě není ani tolik na ochranu zdraví, ale kvůli tomu, aby vůbec topila. Uvnitř trouby ne každá vlna "zasáhne" ohřívaný materiál. Bylo by škoda ji vypustit ven - proto se od klece odráží, aby při odrazu měla ještě šanci něco ohřát.

Na to, jestli se jich trochu dostane ven, na to se prdí. Zdraví to neohrožuje.

350
Sítě / Re:Dostatečný signál pro Chromecast v paneláku
« kdy: 24. 12. 2020, 22:13:56 »
Takovou mikrovlnku bych měl strach používat...
Je vcelku normální, že něco z mikrovlnky uteče ven...ona konec konců tu wifi totálně zabije i dětská chůvička s videem a to má max Tx nějakých 100mW. A to je snad i horší než ta mikrovlnka...

Ze své vlastní zkušenosti potvrzuju, že spuštěná mikrovlnka dokáže vygumovat nebo silně zarušit WiFi.

351
Sítě / Re:Dostatečný signál pro Chromecast v paneláku
« kdy: 23. 12. 2020, 21:37:41 »
Co potřebujete koupit? Ethernet.
Panelák je prolátaný železy a pár metrů od Vás sytí éter asi deset dalších sousedů.

Vypomoci si lze třeba powerline ethernetem, ale pokud máte ve zdech hliníkové dráty, výsledky bývají - slušně řečeno - kolísavé.

Nakonec dopadnete jako každý: několikrát se budete mořit s wifi a možná s powerline, vrazíte do toho nepříjemné peníze, abyste došel k tisíckrát zjištěnému: přes veškeré obtíže raději natáhnete ethernet.

352
Sítě / Re:Přes Wi-Fi 6 kopíruju jen 220 MB/s
« kdy: 23. 12. 2020, 13:52:13 »
Kromě rušení, kolizí...
Do hry vstupuje ještě i výkon samotného zařízení - tj. WiFi část sice komunikuje po rychlém standardu, ale CPU/buffery zařízení to nezvládají. Pak taky může být problém i na straně "serveru", který data prostě nemusí rychleji dávat (rychlost disku, CPU, výkon síťové karty, ...). Rychlost může značně zpomalovat antivirus - a v kombinaci se specifiky WiFi přenosu poklesne rychlost víc, než při stejné operaci na ethernetu... U kopírování většího množství souborů rychlost poklesá vždy (zase, důvodů je více). Pokud nejde využít plné datagramy, rychlost poklesá taky dramaticky...

Tohle je léta stejná písnička. Prodejci inzerují rychlost standardu, ale nemluví se o tom, že reálné rychlosti záleží na mnoha faktorech, které se do inzerátu vypsat nedají.

353
Software / Re:Zálohování v rámci sítě
« kdy: 22. 12. 2020, 16:37:05 »
Především tím, že stanice nemají data. Pak není potřeba nic ze stanic zálohovat. Ono zálohovat, ověřovat zálohy, jestli jdou obnovit - to vše má nějakou náročnost a ta roste s počtem stanic. Tomu je lepší se vyhnout.

354
Soudruzi z redmondu nebyli schopni udělat ani úplně elementární věc na nejexponovanějším místě systému.

Asi co člověk, to jiný názor. Já hledání substringu nenávidím, hází mi to výsledky, které nesouvisejí s tím, co hledám. Ve většině případů vím aspoň jedno slovo z víceslovného názvu.

Myslím, že na vendorovi toho softwaru je, aby uměl vzít v potaz i to, jak systémy fungují. Pokud nejpoužívanější OS umí hledat podle začátků slov a podle klíčových slov v popisu (ano, to taky windows dělají), tak je na místě, aby svůj produkt nazvali inteligentně, případně doplnili často hledaná slova do popisů aplikace.

Pro mě je to - upřímně, bez sarkazmu - hodně zajímavý jev. Já tu vidím popis softwaru, který výrobce zbabral (očividně), nedal si ani práci, aby byl dobře popsaný pro hledání - ale na vině je v očích uživatele jen Microsoft.

355
A třetí pohled: core prvky mají statickou konfiguraci IP a zároveň jsou zadané v DHCP.

Ano, toto se používá právě u těch prvků, které musejí zajistit, aby vše ostatní už fungovalo samočinně. K takovému řešení se kloním, ale snažím se, aby těch závislých na statické konfiguraci bylo co nejméně.

Ono ostatně není na škodu, když se problém projeví co nejdříve. Pro jeho řešení je daleko lepší, než když něco nefunguje vůbec, než když nefunguje napůl. Přemíra užívání statických IP adres vede k tomu, že část služeb se "dovolá domů" a část ne. Pak příčiny hledají déle, než když to nefunguje vůbec. Nejen kvůli technikům - ti obvykle problém najdou - ale i kvůli uživatelům. Dokud "nefunguje jen něco", tak uživatel nemá motivaci (čas) volat podporu a raději pracuje v omezeném prostředí, aby jen dokončil svoje pracovní úkoly. Mezitím se problémy hromadí.

Jako příklad můžu uvést intranetovou appku. Ta na statických IP adresách bude fungovat, i kdyby bylo zemětřesení. Jenže ta appka samotná může dotahovat část dat z externích zdrojů, které na DNS závislé jsou. Setkal jsem se s tím, že uživatelé pracovali a ignorovali "drobné chyby", které jim to hlásilo, ale vše vypadalo, že běží. Během několika hodin se v datech udělalo tolik problémů, že je bylo potřeba dva dny ručně řešit. Kdyby appka spadla celá, protože DNS nejelo (dobře), zastavili by práci a problém by byl vyřešen rychleji.

Ale to jsme někde jinde, než jsme začali. U core prvků a serverových OS platí jiné zásady. Bavili jsme se o tom, že Windows na deskopu nejsou optimalizovány úplně "na klikačku" řešit více statických adres, metrik a přepínání mezi nimi. To je prostě fakt a důvodem je to, že se nepředpokládá, že by to byla úplně běžná situace v síti.

356
Ty dva měsíce života, co jsem se snažil donutit support, aby to vyřešil, mi už nikdo nevrátí. Je to dost OT, ale sorry, nedalo mi to. A taky že mne děsí, jak a čím se linux a windows k sobě přibližují.

Jasně, tyhle partikulární bolesti jsme zažili u všeho. I u linuxu a i před systemd, i u windows, i novellu - prostě všude. Stoprocentně se jim vyhnout nejde a v konkrétním případě mnohdy neexistuje jiné řešení než "špatné", ale stále lepší, než to "teoreticky dobré". Mám na mysli spíš to, že odborník by měl mít sílu podívat se nejen na problém, který řeší "tady a teď", ale i na to, co bude v budoucnu a jestli "to nové" kráčí správným směrem. Např. systemd správným směrem podle mě kráčí - posouvá linux mezi moderní operační systémy. Zároveň nezatracuju ani init, s velkou oblibou používám i BSD, protože na spoustě serverů nepotřebuju nic víc, než stabilní systém. Pokud ale používám linux, tak s oblibou se systemd.

Windows a linux se podle mě k sobě nepřibližují, jen si ze sebe berou to nejlepší, co se osvědčilo. Nejen linuxáci jsou dobří správci serverů, oni i ti na windows umějí hodně - každí s jiným zaměřením.

Co je pro budoucnost linuxu mimo servery "hrozbou" je WSL. Je to takový paradox, linux se dostává všem víc k ruce, ale oddaluje ho to od přímého použití. Na serverech zatím ne, ačkoliv cloudy směřují čím dál víc k tomu, že zákazníky méně a méně zajímá, na jakém OS to běží, hlavně když jim provider zaručí, že to běží. To je další vývoj, který linux posouvá víc od lidí. Ale to je ještě daleko a změnit se může kde co, jen vidím, že ta tu cestu se už naskočilo a tohle je jeden z možných konců.

357
Slriptovat rutinní činosti není špatná ale dobrá praktika. U nás ve firmě, stovky pc, pravděpodobně přes tisíc strojů, mají všechny statickou adresu.

Podle toho, co máte na mysli. Běžná správa se scriptuje, ať už na Linuxu, nebo na Windows - resp. tam přednostně přes politiky skupin. Fungovat na statických adresách lze, ale má to své nevýhody. Podobně jako auto bez klimatizace: nemůže se sice porouchat, levněji se servisuje - ale nechladí.

358
Chci aby dítě nehrálo víc než hodinu denně v pracovní den od 15 do 18 hod. a dvě hodiny o víkendu od 6 ro 18 hod. Jak to nastavuješ?

Já třeba výchovou dětí. Můj názor je, že striktním omezením maximálně naučíte děti tomu, že co není pod třemi zákazy, dvěma zámky a jednou pokutou, jako kdyby nebylo. Myslím, že s podobnou vizí funguje i to omezení doby, které má dát do ruky nástroj před excesivním chováním, ale nemá nahrazovat výchovu. Uznávám, že to je věc názoru a nechci se přít nad styly výchovy.

Z technického hlediska mluvíte o detailu, ke kterému může nejen každý rodič, ale i každá firma (zde Microsoft) přistupovat jinak. Že Vám to nastavení nevyhovuje - budiž, může být. Ale že by bylo na prd - jakožto univerzální pravda?

359
Což je zcela irelevantní v momentě, kdy tu síť šéfuje někdo úplně jinej. Což jsem napsal hned na začátku.

To je přeci jedno, kdo to zbabral a způsobil dalším problémy. Příčin je v reálném světě na tisíc, třeba i to, že jsou jiné priority, než to předělávat a problémy jsou přijatelné. Pointa je v tom, že na okrajové situace se nikdo nezaměřuje (což je jen správně).

360
Na statických adresách nic nesprávného není, právě naopak, je výhodou, když vím pod jakou adresou které zařízení najdu. Skriptování rutinných činností je o dost jednodušší.

Ukazuje to na špatné praktiky. Na stanici obvykle nic scriptovat nepotřebujete (proboha, proč by bylo?), a pokud ano, tak od toho jsme už před nějakým časem vynalezli DNS.

Stran: 1 ... 22 23 [24] 25 26 ... 206