Příspěvky

826

Hardware / Re:Adaptér HDMI (Display Port) → USB-C

« kdy: 19. 08. 2019, 21:47:54 »

Souhlasím s panem Caletkou. Silně se obávám, že huby opatřené USB-C konektory budou podporovat pouze standardní USB 3.x provoz, nikoli DisplayPort.

Terminologický vysvětlivka: "DisplayPort alternate mode" je přívlastek týkající se využití USB-C rozhraní, nikoli přívlastek DisplayPortu. Tzn. jedná se o alternativní využití 4 rychlých signálových párů pro DP data, namísto standardního USB 3.x. Tzn. podle mého to vezme standardní DisplayPort signál z jakéhokoli zdroje a pošle ho to USB-C kabelem. On totiž USB-C kabel k mému lehkému údivu neobshuje 2 rychlé páry (RX+TX full duplex) ale dokonce 4. Možná to souvisí s "oboustranností" USB-C kabelu, nebo se jedná přinejmenším o vedlejší výhodu tohoto uspořádání. Hezky je to vidět na obrázcích v tom PDFku, co linknul Martin Sivák.

(Vlastně to není tak docela pravda. Dokonce je možný režim, kdy po dvou párech jede duplexní lane USB 3.x a zároveň po druhých dvou jede "zúžený" DP. Což není moc velký problém díky tomu, že DP posílá po datových linkách efektivně "paketový provoz", opět souhlas s panem Caletkou, takže není třeba nějak složitě řešit prokládání RGB kanálů / pixelů apod. - srov. např. se single a dual-channel LVDS. Jenom je potřeba vyřešit autodetekci/handshaking a mux/přepínač, které signály se pošlou po kterých párech. Každopádně v kabelu od DeLocku si toto podle mého řeší samotná redukční bambule na kabelu proti USB-C displeji, pokud je co řešit.)

Z toho PDF od pana Siváka mi plyne ještě další zádrhel - jestli si to správně vykládám. Ony se ty věci mezi sebou musí domluvit, v minimální variantě přes USB2 (samostatné dva dráty, kterých se DP režim netýká):

• který konec drátu je USB hostitel a který je USB koncové zařízení ve smyslu USB dat
• který konec je DP data source ("grafika") a který je DP data sink (displej)
• který konec je zdroj napájení a který je příjemce napájení - resp. tento aspekt zmíněné PDF zrovna moc neřeší.

Body 1. a 2. si donglík od DeLocku zjevně v USB signalizaci vyřeší (protože PDF říká, že USB2 je povinně podporované minimum u DP alternate módu, takže bych tipoval, že nejde o zcela pasivní redukci) ale v tom případě se obávám, že už tam není jak připojit napájení - myslím kudlou a páječkou, košer ve smyslu elektrickém a signalizačním. Protože jestli se DP/USB-C donglík dohodne s displejem, že ani jeden není zdrojem napájení, tak bych čekal, že když si z USB-C kabelu chirurgicky vytáhnu tlustý červený fous a nějakou zem, a připojím to na tvrdých +5V, tak ještě není nikde řečeno, že v displeji sepne správný FET a to napájení si vezme...

Možná jsem to celé moc překombinoval a čínská realita uvnitř kabelu i displeje bude řádově jednodušší. Možná je prostě na čase, koupit kus toho kabelu a podrobit ho bastlířské mučírně. Obecně se vcelku neobávám, že pokud připojíte natvrdo svých silných +5V na červený drát v kabelu, že by něco rovnou hořelo. Maximálně jeden nebo druhý konec si z toho tvrdého napájení nic nevezme. Pokud by došlo k tomu, že se na tom červeném drátu potkají 2-3 napájecí zdroje, tak podle mých dosavadních zkušeností s podobnými nesvatými praktikami (a na základě teorie) odhaduji, že prostě bude tahat ten zdroj, který bude dávat nejvyšší napětí (resp. bude při ustáleném výsledném napětí nejtvrdší). Všecky napájecí zdroje tahají jenom nahoru - takže pokud se nebudete snažit, krmit vypnutý počítač skrz HDMI aux PWR (vybavený pouze slabounkou cestičkou na plošáku) tak by skutečně nic moc hořet nemělo.

Samotná redukce DP/USB-C možná očekává napájení z DP strany, konektor DP obsahuje pin k tomu určený. Totéž HDMI. Takže je ještě otázka, jak tohle napájení pro aktivní redukce proleze kaskádou HDMI výstup -> první redukce -> druhá redukce. A jestli by mohlo téct napájení omylem opačným směrem, to je dobrá otázka.

827

Hardware / Re:Adaptér HDMI (Display Port) → USB-C

« kdy: 19. 08. 2019, 00:31:16 »

Nenašel jsem produkt, který by byl ve stylu "jediná krabička".
Našel jsem násedující dva kousky, které by snad šly zkombinovat:

https://www.delock.de/produkte/G_63928/merkmale.html?setLanguage=en

https://www.delock.de/produkte/G_62667/merkmale.html?setLanguage=en

(+ ještě potřebujete kabel DP/DP.)

Bohužel mám pocit, že to řeší jenom data, nikoli přiložené napájení v USB-C.

828

Sítě / Re:MSTP protokol na firemni siti

« kdy: 12. 08. 2019, 08:32:10 »

@zsvec a Max: konečně mi to někdo v kostce a přehledně vysvětlil :-) Díky. Ještě v souvislosti se zmínkou původního tazatele, že čas od času musí přidat VLANu pro "cizí černou skříňku"... trochu mi vrtá hlavou, jestli je nějaká vzájemná závislost mezi MSTP a "per VLAN FDB"  - tzn. CAM tabulka vedená pro každou VLAN zvlášť, nezávisle. V důsledku je pak taková síť tolerantní vůči duplicitním MAC adresám mezi VLAN, což je jednak bezpečnostní výhoda, jednak s některými svéráznými průmyslovými sítěmi nutná podmínka aby to vůbec nějak fungovalo... Ale zatím docházím k závěru, že MSTP a "per VLAN FDB" jsou dvě fičury navzájem dost nezávislé... A jistě u Cisca máte oboje, zřejmě v základní výbavě. U alternativních vendorů to bude "všelijaké".

829

Sítě / Re:Fanless 1Gbps switch

« kdy: 10. 08. 2019, 17:56:39 »

... tak switch to bude davat jen do urcite miry (soucet techto paralelnich toku se u switchu udava jako paramater "total non-blocking throughput") ale rika se tomu wirespeed. Je to dano tim ze se chip switche je na tuto cinnost vysopce optimalizovany, jen kouka do hlavicky ARP paketu a porovnava s CAM tabulkou, nic jineho nedela/neumi.

Opravdu nemístně si na okraj rejpnu: on L2 switch se učí adresy z jakéhokoli L2 paketu. Pravda je, že po připojení jednotlivého počítače (L3 zařízení) může být ARP dotaz jedním z prvních paketů, které ten switch na dotyčném portu uvidí. A pokud se ten počítač za jízdy nestěhuje v L2 topologii, tak se záznam v CAM tabulce už nikdy nezmění...

U všech switchů včetně levných SoHo modelů, pokud mají uvnitř jediný čip (tzn. cca do 8 portů) jsem zvyklý vídat udávaný switching bandwidth jako prostý součet jmenovitých rychlostí per port. Jasně je tam full duplex, ale osobně bych to x2 nenásobil, protože co jedním portem přiteče, jiným odteče a je to pořád tentýž traffic. Musel byste posílat krátké pakety (třeba pod 100B) aby to switch nestíhal forwardovat na L2 "at wire speed".

Na druhou stranu chip ktery umi byt jak router tak switch, nutne musi byt mene optimalizovany a vice variabilni, pripadne nektere cinnosti emuluje. Vezmete si ze jako router musi packety rozebirat na uroven L3, koukat do hlavicek IPv4 i IPv6, koukat do routing table, do firewall table, prepisovat hlavicky v pripade NATu, atp. To proste nikdy nemuze byt stejne efektivni jako v pripade prosteho switche.

Já bych především rozlišoval mezi L2 a L3.

L2 je v hardwaru a funguje v zásadě vždycky "at wire speed" - ovšem pozor na úzká hrdla vnitřní topologie u víceportových switchů.

L3 forwarding je cosi navíc, nadstavba. Pokud switch obsahuje nějaké L3 funkce, tak si troufám tvrdit, že to nijak neomezuje jeho průchodnost pro čistý L2 provoz. Pravda je, že tyhle pokročilé switche mívají o něco delší a hlavně méně deterministické průchozí latence, prostě protože toho zpracování je víc a taky vnitřní architektura pokročilých switchů (kaskáda sběrnic) bývá složitější.
Přestože Cisco svého času tvrdilo, že jsou softwarová firma, jejich proprietární uspořádání backplanů a akcelerátorů jsou jinačí liga než katalogové zapojení malých švábů od Marvellu s propojením přes SGMII. Pokud se správně pamatuju, když vezmete do ruky nějakou zásuvnou desku od Cisca, půlka velkých švábů na ní budou FPGA.

Někteří výrobci označují jako "L3 switch" i hardware, který má prostě jenom interní VLAN trunk do management CPU a ten relativně neduživý procesor softwarově forwarduje traffic na L3 (každý paket vezme do ruky). Podle mého do této ligy patří Turris.
Provoz v rámci VLANy je switchovaný na L2 hardwarově, a tedy "at wire speed" (v rámci topologických možností). Provoz mezi VLANami musí skrz interní VLAN trunk do "hlavy členovce", kde se forwarduje na L3 rychlostí "kolik dá procesor" a jeho OS (zde Linux) - a zase trunkem zpátky do L2 hardwaru. Na nějaké offloady forwardovacích rozhodnutí do hardwaru se tu myslím moc nehraje.

Zrovna v Turrisu je L2 matice oddělená od L3 procesoru. Fakt je, že v levných SoHo krabičkách se tuším vyskytují švábi (Broadocom, Atheros) kde je switchovací matice (5 vnějších PHY portů + trunk), management CPU jádro (MIPS) a třeba i WiFi rádio pohromadě v jednom čipu (SoCu). Mám pocit že ani tady se žádný HW offload L3 forwardingu nekoná, a třeba WiFi provoz se musí softwarově bridgovat do metalického ethernetu i na L2, protože WiFi rádio má rozhraní PCI-e a další svérázné okrajové vlastnosti...

V Cisco názvosloví "Fast switching IP" je podle mého jakási cache v routeru (L3), stále ještě na softwarové straně, která urychluje per-packet routovací rozhodnutí - tím, že se neprochází sekvenčně řetězec pravidel, ale předžvýkaný binární strom (= rychlejší algoritmus). Nebo jestli už to mělo nějakou lehkou HW akceleraci... nevím.

První skutečný offload L3 forwardingu do L2 HW, o kterém vím, je Cisco MLS. Tuším nám to předváděli jako novinku někdy okolo přelomu století... Hardware switchovací matice je schopen sledovat L3 "toky" (flows, definované zdrojovou a cílovou L3 adresou, snad i zdrojovým a cílovým portem?), CPU dostane "k rozhodnutí o next hopu" pouze první paket vznikajícího "toku", hardware switche si toho rozhodnutí všimne, a další pakety už switchuje "at wire speed" podle nakešovaných next-hopů. Toto se dalo nakonfigurovat už na nějakém L2 catalystu s externě připojeným L3 routerem, ale velice rychle se to stalo základní vlastností další generace L3 switchů.

Tušímže další level byl CEF/dCEF (možná záležitost spíš čistých routerů než switchů?), a další bylo PXF, což byl už dost volně programovatelný "paralelní koprocesor"... ale to jsme pořád na začátku století - dávno jsem ztratil přehled, kam se vývoj ubíral dál. Už pomocí PXF toho Cisco "switche" uměly v hardwaru opravdu hodně, vedle forwardingu na L3 taky filtrovat snad až do L5, nevím jestli NATovat apod. Jenom jak už jsem řekl, čím víc věcí ten switch musí s každým paketem provést, a čím větší/složitější je vnitřní "signálová cesta", obvykle taky vnitřní strom sběrnic, a tím větší je jitter průchozí latence (mluví ze mně IEEE1588, kloužu off topic, takže končím).

@kurtn: není zač... :-)

830

Server / Re:Raid5 mdadm zaloha

« kdy: 09. 08. 2019, 22:51:27 »

Když je pole degradované, byl bych opatrný jak s rebuildem, tak s kopírováním nastojato po sektorech. Spíš bych se snažil dostat z toho pole napřed po souborech ta nejvzácnější data, pak po souborech zbytek... taky záleží, jak moc je FS zaplněný. Prostě zbytečně nekopírovat/nerebuildovat prázdné místo. Snad tím trochu omezíte riziko, že najdete další vadné sektory na některém z dosud přeživších disků.

831

Software / Re:Rozdělení PDF

« kdy: 09. 08. 2019, 22:45:36 »

PDF split and merge.

Nebo obejít windowsí "print to PDF" a zkusit starý postup redmon->ghostscript, jenom nevím, jestli to ještě funguje v desítkách. Možná by se v Ghostscriptu našly nějaké opšny na kvalitu obrázků apod.

Jinak... remasterovat PDF na nižší kvalitu embednutých obrázků apod., neuměl něco takového Adobe Distiller?

832

Sítě / Re:MSTP protokol na firemni siti

« kdy: 09. 08. 2019, 10:34:37 »

Jo. Takže jedna instance MSTP a na ni namapované všechny VLANy. Jednoduchá situace. Podle mého ve výsledku ekvivalentní standardnímu STP/RSTP...

Víceméně mi vrtá hlavou, jestli bude taková MSTP-enabled síť vstřícná vůči náhodně přidanému dalšímu switchi, který neumí MSTP, jenom staré STP/RSTP. Nakonec by to mohlo fungovat, pokud si shovívavý moderní switch s MSTP všimne, že soused posílá BPDU ve starém formátu... resp. možná není "fungovat" jako "fungovat". Na jednom portu asi ano, otázka je, jak by se to chovalo při zasmyčkování. Asi záleží na detailech konfigurace. Ale to už asi odbíhám od tématu.

833

Sítě / Re:Fanless 1Gbps switch

« kdy: 09. 08. 2019, 10:17:13 »

Switch definuje predevsim parameter, ze pakety prehazuje mezi porty wirespeedem. Troufam si tvrdit ze tato podminka u turrisu prepnuteho do switch mode nebude splnena protoze tam nesjou chipy optimalizovane na tuto cinnost.

Dle dokumentace tento jejich modul obsahuje čip 88E6190 https://www.marvell.com/switching/link-street/index.jsp, což je zřejmě nějaký standardní switch čip od Marvellu, který používají i jiní zavedení výrobci, takže z tohoto pohledu neočekávám problémy.
Ale nejsem sítař, tak ani nevím, co je wirespeed. Pokud by se tu našel někdo zkušený a ochotný, kdo mi to vysvětlí, budu jedině rád... Wikipedie mi řekla, že to je maximální komunikační rychlost daného interface, na které se dá komunikovat (pokud jsem to dobře přeložil), což mi dává i smysl. V tom případě to ten Marvellí čip musí zvládnout taky, protože to je zřejmě základní parametr, který je od switche vyžadován.

Jojo, předřečník chtěl patrně tvrdit, že Turris Mox bridguje mezi těmi gigáči softwarově, tzn. že nestíhá switchovat mezi porty plnou rychlostí, co po těch portech přiteče.

Jak správně říkáte, zjevně to není pravda. Čip 88E6190 má 11 portů GbEth:

Kód: [Vybrat]

11-Port GE Switch, 8 GE PHYs + 1 RGMII/MII/RMII + 2 2.5G Serdes/SGMII

Ony i hardwarové switche mají také omezení na počet paketů za sekundu, ale ten je řádově výš než u routerů a IMO při MTU okolo 1500 B nepředstavuje úzké hrdlo (= nejsou potřeba ani jumbo frejmy).

Pokud by přišla řeč na "store and forward" vs. "cut through", tak sice nemám datasheet, ale podle mého tyhle nižší řady SoHo čipů od Marvellu a Realteku jsou všecky "store and forward" tzn. je tam on-chip integrovaná RAMka, řádově stovky kB. (Koukám že mladší 88E6390X už kromě 10Gb podporuje taky cut-through a PTP...)

Podle mého se tenhle šváb vyskytuje na Turris-Moxím modulu "E" (viz konfigurátor, v příloze screenshot) = 8x 10/100/1000 Base-T = využívá 8x PHY uvnitř 88E6190. 2x SGMII je nejspíš využito jako interní páteř boxu. Slyšel jsem správně, že maximální konfigurace sestavy Mox je 24 portů GbEth?

V levných switchích o pevné konfiguraci bývá k vidění nějaká centrální interní matice + 3x čip právě této třídy, který provádí "rozplet" na ten velký počet fyzických vnějších portů. Páteř v té hierarchii bývá SGMII nebo nějaká "backplanová" varianta GbEth, možná snop několika takových kanálů (aby backplane nepředstavoval jasné úzké hrdlo). Ideální pro páteř o plné průchodnosti by byl 10Gb Ethernet, ale ten je snad až ve vyšších řadách switchů (kdekoli vidíte vnější 10Gb uplink porty). Tuším jsem v nějakém schématu staršího switche viděl, že jedna ze tří "periferních" matic měla větší průchodnost páteře, nebo že několik uplinkových portů bylo vyvedeno přímo z centrální matice. Do těchto "silnějších" portů má zjevně smysl koncentrovat linky, které ve Vaší topologii realizují páteř nebo obsluhují vytížený server - pokud víte, které to jsou :-)

Mox myslím neobsahuje interní "centrální" matici. Armada 3720 umí sice 2x 2.5Gbps SGMII, ale tipnu si, že do "páteře" vede jenom jeden z těchto portů. Jinak by mi totiž moc nedávalo smysl stohování modulů "E". A ta SGMII páteř skutečně jede na 2.5 Gbps. Takže to vidím na tři switchovací matice v "daisy-chainu". Možná by šlo i víc, z hlediska samotného "stohování", ale mohou tam být jiná omezení (napájení?). Pokud se týče switchování mezi porty navzájem, je daisy chain co do počtu interních "store and forward hopů" v nejhorším případě prakticky ekvivalentní "klasické" hierarchii se skrytou centrální maticí. A že je "hlava členovce Moxe" připojena na jednom konci daisy chainu, to asi moc nevadí, protože těch 2.5 Gbps na L3 stejně asi nevystropuje.

Skutečně plný wire-speed bandwidth, agregátní pro všecky porty, any-to-any, je k dispozici jenom v rámci jediné switchovací matice = v rámci jediného čipu, často osmiportového jako zde. Tzn. pravda je, že když zatížíte všech 24 portů Moxe důsledně gigabitem tak, aby provoz šel skrz interní páteř mezi maticemi, tak to zřejmě "at wire speed" neuswitchuje, protože se úzkým hrdlem stane 2.5Gb páteř. Ale že by Mox "neobsahoval čipy optimalizované na wire-speed switching", to je myslím pořád o něco silnější tvrzení :-)

834

Sítě / Re:Fanless 1Gbps switch

« kdy: 08. 08. 2019, 23:39:03 »

Bohužel podle mého Ubiquiti a Mikrotik u svých "all in one" produktů (včetně venkovních WiFi rádií) na můj vkus poddimenzovávají chlazení (tepelnou vazbu a teplosměnnou plochu).

No to se teda hrube pletete

https://www.abctech.cz/mikrotik-wap-60g-rbwapg-60ad-60ghz-l3-base-station-image1-big_ies153528.jpg

CPU je z druhe strany PCB teplovodne prilepen na sedive telo radia ktere, jak si muzete vsimnout, tvori cele jeden velky chladic.

Velmi rád se hrubě pletu, děkuji za vykázání do příslušných mezí :-) a za odkaz na toho žebrovaného krasavce.

Asi vídám z nějakého důvodu ty levnější varianty. Např. velmi populární je zřejmě tenhle váleček:
https://mikrotik.com/product/RBGroove52HPnr2
Jeden shnilý jsem si rozebral, a nedivil jsem se, že tuhne.

Viděl jsem tuším nějaké podobné miniaturní rádijko integrované s anténou, to celé od Ubiquiti. Ale je to už pár let a ten dojem je matný.

835

Sítě / Re:MSTP protokol na firemni siti

« kdy: 08. 08. 2019, 23:33:46 »

Tzn. chcete zakruhovat fakt jenom management VLAN? U ostatních VLAN v téhle části topologie zálohu kruhem nepotřebujete?

8 managed switchů je krásná malá síť. Na tom přece musí chodit běžné STP/RSTP. Jestli si tím MSTP náhodou jenom nekomplikujete život.

836

Sítě / Re:Fanless 1Gbps switch

« kdy: 08. 08. 2019, 13:15:21 »

Fanless L2(L3) switch nízké řady není dnes problém i se 48G porty.

No, to si nejsem uplne jist. Treba Ubiquiti EdgeSwitch Light (skutecna spotreba 17W, meril jsem to) ktery byl puvodne vyraben jako fanless, dostal v dalsich revizich maly vetracek (coz jiste melo nejaky duvod).

Souhlasím s Vámi, že 48 portů GbEth už je dost. On každý metalický port potřebuje nějaký minimální výkon přinejmenším ve výkonovém konci. Pravda je, že to dávno není 1 Watt per port, jako za starých časů... přesto i po čtvrt Wattu to na 48 portech dost naskáče. A třeba optické transceivery taky něco žerou. Našel jsem k tomu jakousi studii z roku 2012 - zajímavé čtení, resp. spíš obrázky (grafy). Je tam porovnání nějakého starého Cisca proti novějšímu levnému noname switchi.

17 W se dá důstojně pasivně uchladit, pokud máte žravé čipy přivázané na vnější žebrovanou plochu šasi o velikosti nejméně cca 5,25" CD-ROM mechaniky (lépe 2x tolik). A ta žebrovaná plocha musí samozřejmě zářit do prostoru, což 1U skříň nacpaná v racku mezi další 1U skříně splní dost těžko.

Bohužel podle mého Ubiquiti a Mikrotik u svých "all in one" produktů (včetně venkovních WiFi rádií) na můj vkus poddimenzovávají chlazení (tepelnou vazbu a teplosměnnou plochu). Některé jejich modely se cca dožijí konce dvouleté záruky.

Starší D-linky mívaly větráky, ale s postupným zlepšováním křemíku (jemnější litografie, nižší spotřeba) už jsou asi 3-4 generace bez větráků, včetně modelů 24+4 porty. Jestli mi to připadá úplně zdravé je jiná věc. Že jsem kutil, tak obvykle počkám na konec záruky, vlezu dovnitř, nahradím elyty polymerem a přidám podtočený větrák. Dřív jsem klempířil díru do šasi, dneska třeba jenom vyrobím uvnitř tiché dmychadélko, které říká vzduchu "tímhle směrem se budeš zvolna pohybovat". Pravda je, že u poslední generace už mě tohle nutkání opouští. Provozuji takových výtečníků pro vlastní potřebu asi 5-6 kusů a nejstaršímu je snad 12 let. Původní elyty to vzdaly cca po třech letech, polymery mě už asi přežijou - spíš mě štve starý firmware, který měl některé opravdu dementní vlastnosti... (tabulka MAC adres jenom per port apod.).

Jinak pokud nekdo ma tip na fanless 1G switch s mensi spotrebou (idealne <10W u non-manag,24port) v cenove kategorii <5kKc, tak ho velmi uvitam.

Koukám k D-linku že, rozdíl mezi nejnižším unmanaged 24port modelem a trochu lepším 28port modelem s managementem je asi dvojnásobek v ceně, ale jenom 2W ve štítkové spotřebě (15 vs 17 W). Což by odpovídalo - samotný management CPU není nijak výkonný, většina spotřeby jde na vrub switchovací matice a PHY čipů. Mám trochu pocit, že ta štítková spotřeba je nadsazená, ale nechce se mi tahat klešťák a řešit kam ho chňapnout...

837

Server / Re:Emaily přes SMTP od O2 padají v Gmailu do spamu. Může za to blacklist Spamhaus?

« kdy: 07. 08. 2019, 14:54:13 »

Na straně odesílajících serverů je problém čistě v tom, že když je server větší než úplně malý, tak není dost dobře možné držet objem odchozího SPAMu na čisté nule.

Roboti z divokého internetu hádají hrubou silou hesla skrz pop3/imap - můžete proti nim nasadit fail2ban, ale pak máte na krku ruční práci tu a tam s nějakou bezelstnou užovkou, která zadá heslo desetkrát za sebou blbě.

Pokud nejsou Vaši uživatelé Vašimi kolegy ve firmě, ale máte volnější vztah, tak už jim nemůžete osobně promluvit do duše, že sice nechcete bejt svině a nutit je do opravdu brutálně tvrdých hesel, ale že heslo shodné jako login je fakt trefa do vlastní nohy apod.

Na freemailech, kde není žádný osobní kontakt, není problém, aby si spammer naklikal nebo nechal tlupu levných trollů v rozvojové zemi naklikat pár accountů, skrz které pak může hrčet SPAM dokud mu to provozovatel freemailu nezatrhne.

Kromě toho, na freemailu při tom počtu lidí se spíš vyskytne skutečný živý uživatel, který se snaží něco prodávat a vlastním jménem rozešle nějaké obchodní sdělení na větší počet adres - což tu a tam nějaký příjemce nahlásí jako spam. Může probíhat i úvaha, že co si nedovolím na podnikové síti, kde hlídá ten morous kolega správce, provedu na nějakém freemailu skrz účet na jedno použití... (hezky primitivně rukama). Čili nejedná se o špinavé skriptující robodroidy bez špetky šedé kůry mozkové, kteří mají pocit, že brutálním objemem odpadků naženou to, co schází na mentální koherenci obsaženého sdělení - jedná se o živé lidi, kteří se snaží vydělat si poměrně poctivě na živobytí a jejich obchodní sdělení mají lidský rozměr a i nějaký pochopitelný obsah.

Proč to přes web funguje a přes SMTP submission nikoli? Třeba protože jsou to u freemail operátora dva různé odchozí SMTP servery, a napsat spam-bota který odesílá přes SMTP je možná jednodušší, než napsat webového pavouka, který emuluje browser (nebo ovládá skutečný browser nějakou GUI automatizací, jenom aby odeslal SPAM) - takže ten nativní SMTP odesílátor má díky tomu statisticky horší reputaci. Apod.

838

Sítě / Re:Fanless 1Gbps switch

« kdy: 07. 08. 2019, 14:31:39 »

Fanless L2(L3) switch nízké řady není dnes problém i se 48G porty. Problém bude s tou kampatibilitou gbiců.

...pokud mohu soudit na základě svých omezených zkušeností, tak čím levnější a méně značkový switch, tím míň ofrňuje ohledně SFPček. Je dobré volit SFPčka, u kterých je napsáno, že jejich EEPROM splňuje SFP MSA = že sedí IDčko varianty modulu, základní kontrolní součty, že jsou pravda udávané parametry (vůči switchi především rychlost). Vyhněte se SFPčkům, která jsou (údajně) "kódovaná" pro různé proprietární značky (Cisco, HP, Huawei apod.).

Nenapsal jste, co očekáváte za funkcionality od toho switche, pouze počet portů.

Taktak. Jestli to výkonné hlučné Cisco náhodou nebylo trochu kanón na vrabce, pro 12 počítačů... Nebo zda se nejedná o kdysi žůžasný hardware nacpaný fičurami, který je dneska dobrý spíš jako topné těleso.

Tím nechci tvrdit, že je D-Link nějaký zázrak. Firmware posledních generací překvapí podporovanými fičurami (možná především na papíře) a postupně uvnitř ubývají vodnaté elyty... ale nedělejme si iluze, že by nějak bezbolestně zapadl do "Cisco ekosystému" v rozsáhlejší síti, která využívá Cisco fičurky (AAA, dynamické VLANy, CDP, co já vím co dál - už třeba jenom syntax konfigurace. D-link má dvě velmi podobné řady, z nichž jedna má i konzolu a druhá jenom HTTP GUI).
D-linky mají větrání na bocích. Pokud chcete prodloužit životnost, přišroubujte nebo připáskujte switch z boku na stůl, aby ventiloval komínovým efektem.

839

Windows a jiné systémy / Re:Windows se cpou do EFI jako první bootovací položka

« kdy: 07. 08. 2019, 13:16:36 »

Ještě mě napadá, jestli by téma nestálo za dotaz na nějakém modderském fóru, nejspíš https://www.win-raid.com/ . V tom případě se bavit o konkrétní značce a modelu stroje, a o značce BIOSu, pokud lze zjistit (AMI / Phoenix, nebo co). Třeba by někdo z tamních černokněžníků něco poradil.

840

Windows a jiné systémy / Re:Windows 10 analýza telemetrie od BSI

« kdy: 07. 08. 2019, 08:10:01 »

Takze je pre nich lahsie a richlejsie sa na testovany softver pozerat ako na blackbox.

Kde jsem to četl... někde v dokumentaci strace? Že kolikrát jeden pohled do výpisu strace dává lepší informaci, "co ten software dělá", než dva dny luštění zdrojáků... Jasně, pak záleží na Vaší pečlivosti a na okolnostech, zda Vám při "pohledu zvenčí" zkoumaná černá skříňka vykecá úplně všechno, co doopravdy umí...

V jednom z několika trochu výživných PDF na tom jinak dost upovídaném webu mi jako laikovi přišel zajímavý seznam nástrojů. A pár screenshotů, kde je vidět, že používají (mj. taky) kernel debugger... respect.

Mimochodem pokud jsem správně pochopil, zkratka/přesmyčka BSI/BIS v nadpisu i těle původního dotazu je jenom clickbait... Ony ty dvě organizace dělají myslím každá něco dost jiného.