ja si osobně nemyslim, že internet věcí bude nějak více motivovat v nasazení ipv6, už jen pro to, že většina prvků by měla být pasivní
Bezpečnost se neřeší nikde, chtěl jsem si doma udělat pár senzorů na měření a po hcvíly hledání jsem narazil na už docela mosově rozšířené mysensors kde se nějaké zabezpečení také neřeší a samy tvůrci k tomu přistupovaly s tím, že je zajímá funkčnost
jaký je Váš názor na všelijaké kontejnery (docker,..) zvíší bezpečnost nebo díky tomu, že se vše hezky zabalí tak aby to jelo se bude používat ten samý kontejner roky bez aktualizací knihoven aby se to nerozbylo
Njn, ale není to náhodou zneužité něčí služby bez jeho vědomí, zakomponovat do svého firmware IP adresu na cizí službu?
Nebo snad měl výrobce povolení od poskytovatele NTP?
Pokud ano, nedalo se tomu předejít třeba tím, že by se teoreticky spočítalo, jak bude NTP těmito zařízeními využit a pak případně po výrobci požadovat úhradu vícenákladů za využití?
Hodně otázek, nikde ale odpovědi.
Že se dělá fw skoro "na koleně" je jasné, jak by jinak bylo možné koupit třeba v Tesco, nebo Alze router s Wifi za 400 Kč? Kolik je asi výrobní cena? Kolik se jich musí vyrobit, aby se to vyplatilo?
Prostě vzít nějaký OpenSource, zbastlit to dohromady a nacpat do zařízení. A víc se o to nestarat (jasné, když za rok takto "navrhnou" třeba několik zařízení ... lišících se jen drobnostmi).
Ach jo ... to si ještě v tom kybersvětě užijeme :-)
Článek moc pěkně popisuje několik zásadních problémů současného IT, které je nejvyšší čas řešit:
1) "Euforie". Obecná slepá důvěra a až náboženský technoteistický fanatismus v němž pramení nadšení z každé nové hračky, kterou člověk prostě "musí mít", samozřejmě co nejlevněji a hlavní je "aby to _něco_ dělalo". Už není podstatné jak. Vlastník tomu stejně nerozumí, jen upíná své naděje k tomu, že s tou hračkou bude šťastnější. Třeba takové "smartwatch" jsou jako kouzelný amulet. Když si je koupím, budu šťastný.
2) Zoufalá neznalost/nevzdělanost u spotřebitelů i výrobců. Školy produkují polovzdělané poloprogramátory. Neumí myslet, software štrykují jak ponožky - ovšem s větším množstvím děr, ve špatné velikosti a ze špatného materiálu. Naštěstí díky předchozímu bodu to nikomu nevadí...
3) Ignorace filosofie a sociálních věd obecně. IT sféra a bohužel i IT školy systematicky ignorují staré známé pravdy a otázky filosofie, sociologie, psychologie, politologie a podobně. Ty vědy často řeší nebo už dávno vyřešily podobné problémy (např. právě problematiku útočení), k jakým se dostane při práci překvapivě i programátor. Jenže ten je zvyklý (kvůli své hlouposti a neznalosti) už od školy shlížet na humanitní vědy opovržlivě a ignorovat jejich poznatky. Důsledkem je jeho hloupé a nefunkční řešení, kterému by se musel humaniťák smát, pokud by ovšem měl elementární technické vzdělání (viz 1. bod).
Pokud už se něco z těchhle věd využívá, tak jde spíš o marketingové zneužívání jako třeba u facebooku nebo cílené reklamy obecně apod.
4) Konzumismus a obecná tendence vyrábět co nejlevnější zmetky, které se tváří, že fungují. Tohle je celospolečenská nálada, která podle mého názoru částečně pramení právě v IT a přesvědčení, že člověk se má především bavit a ne pracovat a že podstatný není vnitřek, ale stačí povrchní pseudokrása.
Před časem jsem v Kolíně nad Rýnem viděl věc, která mě nutila se zamyslet. Na místní katedrále jsem vystoupal na tu cca 100 m vysokou věž. Nahoře na téměř nepřístupném ochozu jsem se trochu vyklonil a všiml si za rohem části sochy. Ta socha nemůže být zespoda vidět. Není celá vidět ani z toho ochozu, což je místo nejbližší. Jediný, kdo ji může vidět je tak leda parašutista, který to nevybere a padá na věž. Přesto tam je a ta část, co jsem viděl je detailně zpracovaná, jako asi celek. Dneska by v tom místě nejspíš nebyla pořádně udělaná ani střecha, protože si toho nikdo nevšimne.
Co není vidět, to může být z jakéhokoliv aušusu. Naleštěný povrch a uvnitř shnilý sotva držící zmetek. Funguje to i u software. Userinterface barevný a "krásný", vnitřní funkčnost ale nespolehlivá nebo dokonce nesprávná... Umělohmotně dokonalá kráska na povrchu naleštěná nejmodernějším makeupem, uvnitř blbec jehož hloupost se nebe dotýká...
Je toho víc, ale myslím, že řešení paradoxně není v silách IT. Rozhodně nestačí jen používat IPv6. Jestliže udělám zmetek a skryji ho v dostatečně velkém adresním prostoru, je to totéž jako když si malé dítě zakryje ručičkama oči a schová se pod stůl. Dřív nebo později ho stejně někdo najde...
Změna je potřeba v přemýšlení a chování lidí. Stvoření nemůže být lepší než stvořitel (vidíte, teologické otázky v IT...). Blb nemůže stvořit chytré zařízení...
4) Sochy byly drahé vždy a nikdy se proto nedělaly jen tak zbůhdarma, aby nebyly vidět. Zato se ve středověku téměř vždy stavělo bez nějakých větších systematických plánů a sochu skryla pozdní dostavba, podle wikipedie se uvedená katedrála stavěla neuvěřitelných 600 let.
Dobrý den
S tímto by jsem úplně nesouhlasil. Gotická katedrála byla stavěna věřícími v boha pro boha. Dle jejich tehdejšího pohledu byl bůh na nebesích. A proto stavba musela být nejkrásnější z jeho pohledu. Což z dnešního pohledu vypadá ne zcela pochopitelně neboť z pohledu lidí bylo mnoho detailů pro lidi neviditelných. Nicméně pro ně tyto detaily ani vidět být neměli. Adresát byl jiný.
Úplně 100% bych si tím jist nebyl. Nevím jak sochy, ale třeba Santiniho kostel na Zelené hoře při pohledu shora ukazuje o investorovi stavby mnohem víc informací než je vidět ze země. To samé některé barokní aleje jsou budované tak, aby byly hezké shora.
Viz: Jiří Sádlo, Krajina a revoluce. Ale pravdou je, že socha je trošku menší objekt.
Souhlasím, jen bych ty humanitní vědy nepřeceňoval. Myslím, že k tomuto nemají moc co říci.
Tady chybí hlavně elementární poctivost a technická vzdělanost a to, čemu se v řemeslech říkalo fortelná práce. Spousta záležitostí je bohužel poháněna hlavně lidskou blbostí a tupým kšeftem.
Internet věcí...co to vlastně je? Hlavně zoufalá snaha výrobců vnutit uživatelům další víceméně neužitečný brak, za který budou platit. A ty opravdu přínosné záležitosti kolem toho se ztratí pod nánosem smetí. Bude se dále navyšovat kapacita sítí jen proto, aby byly schopné přenášet další neužitečná data, poroste v nich chaos...
Mají mnoho co říci - ona bezpečnost, s tím související např. soukromí! Nebo třeba společenské chování při používání nových věcí jako mobilní telefony... atd.
To je ale těžko vysvětlovat informatikovi, který je v lepším případě všeobecně nevzdělaný (a ještě je na to pyšný!), v horším stojí za hovno i jako ten informatik. Jako jsem kdysi parafrázoval větou „ekonom je dobrý sluha, ale zlý pán“, to samé platí pro informatiky - informatika nemůže řídit život, protože jsou věci, které ji přesahují.
Ad 3) No, konkrétní příklady, to je docela těžké, ale zkusím: IT už v rámci umělé inteligence dost úspěšně využívá jiné přírodovědné obory, konkrétně biologii. Genetické algoritmy jsou de facto klasická evoluce zapsaná algoritmem. Z oblasti humanitních věd nevím o ničem, co by informatika využila. Jednoduchá argumentace by byla, že to může být i "nepoužitelností" nebo "zbytečností" humanitních objevů, ale to si nemyslím.
Příkladem filosoficko-teologické otázky v IT je například otázka stvoření a jsoucna v objektovém programování. Problematika pochopení toho, jak ve Squeaku/Smalltalku fungují metatřídy, to je dost blízké. Podobně jako otázka mnohonásobné dědičnosti (C++ vs. Java) je pěkný příklad otázky ze sociologie/antropologie. V počítačových sítích vyvstal nový prostor paradoxně bez pevných pravidel "etikety", tak jako vznikl na světě. Myslím si, že problematika kyberzločinu a kyberválek by se měla studovat s ohledem na znalosti z politologie, psychologie, sociologie atd...
Uznávám, že tu skrývám i přesně opačný problém a sice že tak jako zarytí ajťáci ignorují humanitní vědy, protože jim nerozumí a museli by se učit úplně jiný přístup k vědě, tak svorně i humanitní vědy ignorují IT, protože tomu nerozumí a nechtějí se učit exaktní, deterministrický (algoritmický) přístup. Navíc IT je paradoxně právě oblastí, kde je nezbytná spolupráce s jinými obory a pochopení látky jiných oborů. Akorát zatím se používá jen biologie, medicína, fyzika atd.
Ad "Blb nemůže stvořit chytré zařízení":
no ano, takhle zjednodušené tvrzení je zavádějící, ale principiálně mi jde o toto: algoritmus je deterministický, je to posloupnost kroků/instrukcí. Abych stvořil chytrý algoritmus, musím ho sám být schopen pochopit a zapsat. Existuje sice ještě alternativa náhody, kdy budu tak dlouho skládat instrukce za sebe, až se to začne "chovat chytře", ale ve chvíli kdy jsem nebyl schopen ten chytrý algoritmus pochopit a zapsat, ho stejně nebudu schopen rozpoznat i kdybych ho vytvořil nahodile, protože mu nebudu rozumět. Můžeme se bavit o evoluci, ale pak je potřeba si specifikovat pojmy "blb" a "chytré zařízení". Jestliže je někdo schopen vytvořit systém schopný evoluce, pak jistě není blb...
> Existuje sice ještě alternativa náhody, kdy budu tak dlouho skládat instrukce za sebe, až se to začne "chovat chytře", ale ve chvíli kdy jsem nebyl schopen ten chytrý algoritmus pochopit a zapsat, ho stejně nebudu schopen rozpoznat i kdybych ho vytvořil nahodile, protože mu nebudu rozumět.
Algoritmu nepotřebuje rozumět, stačí mu jen otestovat, zda se pro nějaký vstupní subset chová korektně.
Ono vůbec celkově, tenhle příspěvek mi celý přijde jako demonstrace přísloví "přání otcem myšlenky".
No nevím, myslím si, že přesně takový přístup je pak zdrojem oněch problémů s nekvalitním kódem.
Ano, jedna věc je např. nastavení omezujících podmínek a nechat běžet výpočet tak, aby je splňoval... Dejme tomu, jenže to vyžaduje zadefinování těch omezujících podmínek, tzn. autor musí vědět, čeho chce dosáhnout a i když nerozumí postupu, rozumí alespoň požadavkům na cílový stav.
Jinak "stačí otestovat, zda se pro nějaký vstupní subset chová korektně" popírá nezbytnou vlastnost algoritmu a sice korektnost. Nestačí, aby byl korektní jen pro "nějaký subset". Nejsem si jistý, jestli je rozumné programovat tímhle způsobem. Řídící software pro letadla se chová korektně od výšky 0 po 200 metrů, tak s tím vzlítneme? Překročíme 200 metrů algoritmus vypne všechny motory...
Jinak uznávám, že mi chybí potřebné znalosti z logického programování a programování s omezujícími podmínkami, což je oblast, která se toho úzce týká.
Je škoda, že věda je tak rozvinutá, že člověk už není schopen ji celou ani v základu pojmout...
No, před časem jsem viděl jeden díl leteckých katastrof, kdy autopilot podle špatných dat z měřáků nabyl dojmu, že je 10 metrů pod zemí a začal prudce stoupat (místo toho, aby poznal, že to je nesmysl a předal řízení pilotovi). Takže ano, takto se dělají i řídící systémy letadel.
V jinych dilech muzes zjistit, ze pilot na zaklade toho co mu ukazovaly pristroje dostal stroj do padu, pritom stacilo nedelat proste nic. Ukazovalo mu to totiz ze leti prilis rychle. Coz pri danym nastaveni pripusti byly samo kraviny, jenze piloti sou uceni ze to co ukazuje merak je pravda.
Což má také dobrý důvod. Člověk jakožto tvor zcela nepřizpůsobený létání je zejména za špatné viditelnosti velmi náchylný k omylům způsobeným tím, že naše smysly za daných podmínek nefungují správně. Jeden příklad za všechny, letíte v noci nad mořem, je zataženo, takže nemáte vůbec žádný orientační bod. Teď začnete zrychlovat při udržování výšky. Akorát, že akcelerace způsobí, že vám sensory ve středním uchu začnou tvrdit, že stoupáte. Jestliže v tuhle chvíli rozhodnete věřit tomu, co cítíte a ne přístrojům, tak to naklopíte rovnou do moře.
Další věc se jmenuje "defenzivní programování". Psát kód tak, aby při chybě pokud možno nešel zkompilovat. Direktiva -wall kompilátoru je samozřejnmost a v binárce nesmí být ani warning. Testy na mezní podmínky. Testy na nesmyslný vstupní hodnoty.
Pokud jde zkomplovat, musí na chybu upozornit. Tzn, výjimky, assert na vstupu, assert na výstupu, návratový kódy...
Už jsem viděl nejeden systém, kde byla validace vstupů, která při chybě čidla zfalšovala nějakou "smysluplnou" hodnotu, se kterou se pak pracovalo a ani UI, ani řídící algoritmus nevěděl, že to není reálná hodnota... Zařízení nehavarovalo, ale ovládaná technologie se chovala divně. Místo, aby se technologie odstavila a indikovalo to chybu.
Při práci na SW se holt musí myslet, konzultovat a testovat. Jinak je to na pytel.
Tyhle veci se (pokud) delaj tak, ze se pri chybe soft prepne do nejakyho "nouzovyho" rezimu, kdy se vystupy nastavej do nejaky "default" hodnoty. Tzn trebas u toho letadla se pripusti nastavej trebas na 75%, coz je hodnota pri ktery by to melo normalne letet. Samo ze by to zaroven melo signalizovat ze je neco spatne a ne se tvarit, ze se nic nedeje.
Co furt letadla? Pokud jde o teplotní nebo tlakový čidlo chemickýho reaktoru a začnu automatiku krmit vymyšlenýma hausnumerama, tak to často taky nebude jenom o prachách... Pojišťovací ventil to taky nezachrání, pokud ta směs v reaktoru bude toxická, nestabilní nebo prudce reagovat se vzduchem. To bude po finanční stránce i co do zranění/úmrtí horší, než Cessna řízená Windows 95.
Obecně, padělání dat z čidla je vždycky prasárna. Minimálně modul vstupů ví, že je někde chyba a má to zarazit. Ne se snažit to flikovat vymyšlenou hodnotou. Protože když už někdo utrácí prachy za snímání nějaká hodnoty, asi ji pro něco potřebuje a když pak ta hodnota někde chybí, je to poznat.
Ale ony ani ty stroje se běžně nouzově nevypínají. Mají tlačitkou pro nouzové vypnutí, ale to se používá jen při pádu člověka do stroje nebo nějaké podobné katastrofě. SW sice také stroj umí odstavit, ale dělá to dost jinak - například jen zastaví posuv nástroje a pak se snaží vypnout postupně osy. Záleží, co tam programátor napíše. U hodně osých zařízení je pak běžné, že to SW prostě vypnout neumí a jen začne řvát a potřebuje člověka. Hrozí totiž (a ono se to i stává), že když vypnete jednu osu a jinou ne, tak vám narazí obrobek do nástrojové hlavy a to už jsou dost velké peníze. Nebo narazí "jen" do nástroje, což na peníze nebývá problém, ale ten šrapnel s břitem z nástrojové oceli může i zabít.
Zkrátka "nouzové vypnutí vynucené softwarem" je u čehokoliv, kde se pohybují věci s nezanedbatelnou hybností a momentem setrvačnosti, riziko.
Nouzový vypnutí nemusí být jenom pomocí stop hříbku. Může ho vyvolat i např. tlakový spínač, optická závora, zámek na dveřích,... Záleží na aplikaci a bezpečnostní třídě stroje.
Nouzový vypnutí nesmí záviset na software a na řídícím systému. Řídící systém ho ale může aktivovat a pokud není kritická situace, může ještě udělat nějaký bezpečnostní úkony. Ale pokud je to čidlo důležitý pro chod stroje. musí nakonec stejně PLC sestřelit i bezpečnostní relé.
A bezpečnostní obvody se při návrhu žídí nějakou analýzou rizik a podle toho je to navrženo - např. se zastaví jenom mechanický části pomocí brzdy, ale odčerpávání provozních kapalin a chlazení jede dál... A je tam někdy víc levelů nouzovýho vypnutí. Je to stroj od stroje jiný.
Záleží na aplikaci. U některých strojních zařízení naopak vypnutí nepřichází v úvahu. Nejde jen o letadla, ale i o reaktory, pece, medicínské přístroje, auta atd. Ostatně tu pec jsem jednou zažil - vypnul se výhřev ale i posun materiálu. Než pec stihla vychladnout, tak to zničilo velkou část materiálu, který uvnitř uvázl. U pece můžete nouzově vypnout výhřev, ale ne posun - ty věci, co jsou uvnitř, musíte dostat ven.
Alternativou k "defenzivnímu programování" je "fault tolerant". Je vždy nutné zvážit, který přístup je lepší. Já osobně preferuji fault tolerant jen proto, že jsem začínal na SW pro elektrárny a i na VŠ jsem se s tím setkával na každém kroku. TCP, HTML, vše tohle je příklad fault tolerant. Internet by rázem vypadal jinak, kdyby ztracený packet nebo prohozené packety způsobily ukončení spojení. Nebo kdyby na neznámý tag v HTML prohlížeč reagoval prázdnou stránkou, které by dominoval úsporný nápis "assert failed: unknown tag".
Na čem se shodneme je probém, pokud dojde k závažné chybě a není to správně reportováno. Že se ve streamu ztratil paket a TCP stack ho poslal znovu mě asi nezajímá (dokud se jich neztrácí polovina), ale fakt, že jeden ze senzorů tlaku dává jiný výsledek než ty ostatní a proto je ignorován, by mě naopak velmi zajímal.
Kdyby prohlížeče na neznámé tagy reagovaly prázdnou stránkou s onou hláškou a bylo tomu tak "od začátku", byl by dnes internet opravdu jiný, ani ne tak do viditelného obsahu jako "zázemí", byl by plný zcela validních stránek, protože by kdokoliv, kdo by chtěl něco zveřejnit, neměl jinou možnost než právě pomocí zcela validního kódu.
Tohle je totiž nutný důsledek "fault tolerant" přístupu aplikovaného na výstupy lidské práce, to, co tolerujete, se bude vyskytovat, protože proč věnovat úsilí něčemu, na čem ve výsledku nesejde?
>Nebo kdyby na neznámý tag v HTML prohlížeč reagoval prázdnou stránkou, které by dominoval úsporný nápis "assert failed: unknown tag".
Tráva by byla zelenější, lidi šťastnější, dokonce možná i na ten světový mír by došlo. Tohle domýšlení si, co vadný a špatně zformátovaný tag vlastně znamená může za takovou kopu zla, že ani nevím jak to vysvětlit.
A ačkoliv by existovalo HTML 2.0, drtivá většina lidí i serverů by používala HTML 1.0. V diskusích by se pak sázelo, zda dříve dojde k masovému nasazení HTML 2.0 nebo IPv6.
Neříkám, že tahle volba nezpůsobila kopu zla. Ale myslím si, že to byla jedna z vlastností, která z toho udělala tak masovou záležitost. Fakt, že jste do stránek mohli přidávat nové věci, aniž byste automaticky odstřihli všechny uživatele se starší verzí prohlížeče, byl podle mne jeden z klíčů k úspěchu www.
Proč? Stačí mít ve specifkaci, že neznámý tag bude ignorován. Při testech se pošle pár nesmyslných tagů (1-10 náhodně generovaných znaků; pokud se trefí do seznamu podporovaných, generuje se znovu) a pokud při tom prohlížeč klekne nebo nezobrazí stránku, je to chyba.
Ne každá neznámá věc na vstupu musí omezit funkčnost. Od toho snad mají vývojáři mozek a dělají analýzy, ne? Jenom pitomec začne rovnou psát zdrojáky.
Co kdyz se do pece dostane neco co tam byt nema? Tak to protahnes celou peci a poskodis si vnitrek jen protoze to nejde vypnout nebo se ti tam priplete clovek a sef te pochvali ze dneska mimo rohliku budou i pirozky? Nebo ze je fajn ze mame material venku ale hlavni technik bude figurantem na haloweenske party?
Taky bylo kdysi hloupe davat do peci, mrazaku, ruznych technologickych komor tlacitko na odstaveni/otevreni. Vsak dokud nebudem misto izolatoru delat golemy tak to nema vyznam. No par lidi/decek se jim tam ohralo a pak "promovani inzenyri" shledali ze ne vzdy se da vzorecky urcit - ano je to mozne a ze jim chybi vzdelani i z jinych oboru.
Existuje sice ještě alternativa náhody, kdy budu tak dlouho skládat instrukce za sebe, až se to začne "chovat chytře", ale ve chvíli kdy jsem nebyl schopen ten chytrý algoritmus pochopit a zapsat, ho stejně nebudu schopen rozpoznat i kdybych ho vytvořil nahodile, protože mu nebudu rozumět.
Přesně takhle se ale dělají neuronové sítě pro rozpoznávání obrazů, vzorů, atd. Pospojuje se pár neuronů, chvilku se trénují a pak najednou začnou dělat to, co se od nich chce. Nikdo nemá ani páru, jak to opravdu funguje, jen několik málo lidí má možná mlhavé tušení, jak by to asi tak mohlo být.
Podobně se zkoušely dělat návrhy hradlových polí evolučními algoritmy. Vyšla hradlová pole, která fungovala, ale nikdo nevěděl proč.
Jsem si poměrně jistý, že "nikdo nevěděl proč" není úplně pravdivé tvrzení...
Jedna věc je, když tomu nerozumí autor, druhá věc je když si s tím někdo hraje, "nějak" to nastaví a "něco" z toho vyleze a třetí věc je, když kolegové nebo publikum v aule zírá, co ten algoritmus vyrobil a nerozumí, protože si nepřečetlo skripta před přednáškou a nemá dostatečné základy pro porozumění přednášejícímu...
Pokud se nemýlím, neuronové sítě používají hodnotící funkce a výpočet chyby v populaci ke zhodnocení korektnosti výstupu, případně v rámci genetických algoritmů k selekci.
Blb nedokáže korektně nastavit hodnotící funkci a proto mu pravděpodobně polezou ven zmetky. I kdyby ne a vylezlo něco, co je (zdánlivě) korektní, nedokáže to rozhodnout, jelikož to nedokázal zhodnotit.
Pokud jsem schopen sestavit korektní hodnotící funkci, pak systému rozumím bez ohledu na to, že nevím, proč z něj vylezly zrovna ty parametry, které to dalo. Podstatné je, že ty parametry byly získány na základě pochopené hodnotící funkce a jsou s ní v souladu. To, že nemám čas provádět simulaci ručně neznamená, že nerozumím principu...
Aha, asi se neshodneme na tom, co znamená "vědět proč". Podle mě to znamená pochopit, proč daný systém funguje, ne jenom pochopit, jak byl získán. Tedy proč právě toto nastavení vah a spínacích hladin v neuronové síti pozná jablko, ne jak byla ta neuronová síť trénovaná. A troufám si tvrdit, že to opravdu nikdo neví.
A u těch hradel to bylo opravdu tak. Po dlouhém zkoumání byli schopni odhalit jen to, že to hradlové pole fungovalo jako analogový systém a pro jeho funkci byly důležité přechodové jevy při přepínání logických stavů. Dál se nedostali.
> Jsem si poměrně jistý, že "nikdo nevěděl proč" není úplně pravdivé tvrzení...
Ne. Vážně nikdo nevěděl proč. Autoři spustili evoluční algoritmus na FPGA a po pár tisících generací vzniklo něco, co využívalo všech vlastností čipu. I těch, se kterými lidé nejsou schopni operovat (parazitní kapacity třeba) a které se projevují například jen u konkrétních kusů kvůli chybám. Výsledkem bylo schéma které vůbec nedávalo smysl a obsahovalo konfigurace bloků, které nejsou nikam zapojeny, ale když je odpojili, tak to přestalo fungovat. Viz část Case study, kde je taky závěr:
We still do not understand fully how it works: the core of the timing mechanism is a subtle property of the VLSI medium. We have ruled out most possibilities: circuit activity (including glitch-transients and beat-frequencies), metastability [5], and thermal time-constants from self-heating. Whatever this small effect, we understand that it is amplified by alterations in bistable and transient dynamics of oscillatory loops, and in detail how this is used to derive an orderly near-optimal output.
Dalším zajímavým výsledkem jsou třeba evolučně vypěstované antény, které jsou topologicky naprosto cizí všem lidsky navrhovaným. Něco takového člověk prostě navrhnout ani nemůže.
Podrobnosti viz: SEKANINA, Lukáš. Evoluční hardware: od automatického generování patentovatelných invencí k sebemodifikujícím se strojům. Vyd. 1. Praha: Academia, 2009, 321 s. Gerstner. ISBN 978-80-200-1729-1.
Jenze "umely" neuron zvladne vytvorit kdokoli. Stejne tak jich libovolny mnoztvi "nejak" pospojovat. Neni v tom zadna veda, protoze zakladni princip je trivialni.
Kdyz na to prijde, vypestovat si biologicky neurony taky neni nic, co by nekdo nezvlad klidne doma v kuchyni.
Posilat jim nejaky vstup a cist nejaky vystup ... taky neni nic, co by vyzadovalo nejaky hluboky porozumneni. To ze to po nejakem mnoztvi ucicich cyklu zacne fungovat tak nejak "samo" je pak to, cemu vlastne poradne nikdo nerozumi. Ani ti vedatori ne. Ti tak maximalne muzou zkoumat stav, ve kterym ta neuronova sit je, ale proc prave takhle je to treba aby to delalo neco ...
A prave proto, ze nikdo nevi jak to funguje, se neuronovy site ucej. Kdyby nekdo vedel jak to funguje, moh by tu sit rovnou nastavit tak, aby delala to, co se po ni chce.
Ono se toho vi pomerne dost, hlavne u jednoduchych siti, treba viz http://colah.github.io/posts/2014-03-NN-Manifolds-Topology/
Co presne se deje na urovni jednotlivych neuronu je samozrejme problem, jde o hodne komplexni system. Ale tvrzeni "nikdo nevi jak to funguje" mi prijde prehnany.
Chapu argumenty o tom, ze vnitrnim mechanismum kompletne nerozumime, ale nevyvozoval bych z toho kompletni nepochopeni systemu jako takoveho. Neco podobnyho se da najit v mnoha oblastech, kdy nezname mechanismy na nejnizsi urovni a presto nam to nebrani delat velmi presne a spolehlive predpovedi (napr. gravitace - projevy mame vyborne popsany, aniz bychom vedeli presny mechanismus). Tady dokonce mechanismy zname, ale proste nejsme schopni pojmout tu komplexnost, takze kyzenou sit ladime optimalizacnim procesem.
Jenom k doplneni me myslenky - malou sit s jednotkami neuronu a nizkym poctem vstupu, ktera vykonava nejaky jednoduchy trideni, by urcite clovek rucne odladit zvladl. Co nam brani postupovat stejne u velkych je proste jejich rozsah, kdy uz nas mozek nepojme vsechny vlivy, zpetny vazby atp., proste onu komplexnost. Tak na to proste postvem optimalizaci.
Se vším souhlasím. Jen mi pořád vrtá hlavou, jak nedělat programové zmetky. Na to neexistuje snad žádná literatura. Jediné co jsem kdy četl je kniha "Co programátory ve škole neučí". Mimo to, jak asi víte, tak není možné nikdy vytvořit 100% spolehlivý a už vůbec bezpečný program.
Jo, ten je relativně dobrej, ale spíš s soustředí na Javu a ne vždycky je to aplikovatelný jinde.
Raděj mám Code Complete II od Mc Connela. Je to čtení na trochu delší dobu, ale spousta zajímavých postřehů a donutí člověka myslet...
No a pak bylo něco o DDT/Iconix, z hlavy si nevzpomenu. Ale docela inspirativní pro strategie testování. Jenom to nesmí člověk brát mo doslova, byla to óda na DDT a nedostatky umně maskovali.
Mne pred lety prisel jako hodne dobry odpich prave pro Java/Python proste mainstream svet. Vsak on je dneska i strejda Bob nekde jinde...
Hmmm, dvojku jsem nejak nezaregistroval, diky.
Tak, tak, ono pak je strasne moc specializovanych veci na uzsi temata. Trebas k agile je toho metrak, k automatickemu testovani taky (mam rad Kenta Becka, bijte mne, mucte mne, ale hned ta prvni knizka o tematu je IMO nejlepsi; moc mi nesednul jinak vseobecne oblibovany Growing OO soft driven by tests), k implementaci jsou prima Implementation Patterns (pro zmenu od Becka)...
Ale sirsich zdroju typu "prectes dalsich 500 stran a pochopis tak 80% prasaren, co jsi delal dosud", tech zas tak moc neni. A zrovna to bych ocenil pro FP svet.
Jednoduše. Nepsat. Generovat.
Komunikační protokol, to je sada zpráv. Řekněme, že by jich bylo 50, v každé pět parametrů a společná hlavička. Napsat samotný parsování protokolu v C je otročina a kdo se bude psát s unit testama?
Pro každou zprácu je potřeba udělat testy, kde bude
- Správná délka dat
- Víc dat pro daný typ zprávy (buffer overflow)
- Nekompletní zpráva
- Simulace chyby zabezpečení
Potom pro každý parametr
- kontrola validace (řekněme 100 hodnot v průměru)
- minimum a maximum
- korektní uložení do aplikace
- notifikace o změně
To je 5*105+4 = 529 testů/zprávu. Pro 50 zpráv 26450dílčích testů jenom pro korektní příjem dat.
Při tom pro 5*50 parametrů by to bylo 250 validačních funkcí + 50 parsovacích funkcí + dispatcher + validace hlaviček + CRC, + ... Počítejme 350 funkcí a kdekoliv může být chyba. Viděl jsem takový parsery na 25kLOC a víc.
Při tom stačí protokol popsat abstraktně, ale ve strojově čitelné formě, prohnat skriptíkem a vyjedou unit testy i kostra parseru bez překlepů. Za pět minut vytvořeno a otestováno...
Je to věda. Postupů a přístupů je řada, mnohé dokonce z dob před počítači (diagnostika a spolehlivost je obor starý pár set let). Vydá to na celou knihovnu. Důležité je ale hlavně myšlení. Pracovat s tím, že nic není spolehlivé, nic není bezpečné a všechno se pokazí. A už od začátku s tím počítat a tomu se přizpůsobit. Ale to z knížky nenačtete, na to je potřeba najít společnost, která si na tom zakládá a chvíli v tom žít. Osobně jsem měl to štěstí, že jsem začínal ve společnosti, co vytváří programy pro řízení údržby v jaderných elektrárnách. Pro tuto metodiku vývoje SW se používá název "fault tolerant".
Proto docela pláču, když někdo přeceňuje unit testy nebo předpokládá, že spolehlivost zlepší kontrolou vstupních parametrů. Protože jádro spolehlivosti není v tom, zjistit, že je něco špatně, ale v tom, umět se s tím vypořádat nebo to dokonce opravit. Kdykoliv se setkám s programem, který jen oznámí "general exception, call administrator" a vypne se, tak si podvědomě řeknu: bum.
Zkrátka: chyby byly, jsou a budou. Cestu nevidím v tom, vytvářet bezchybný software a hardware. Já cestu vidím v tom, vytvářet software, co dokáže chyby detekovat a vypořádat se s nimi.
Smutná pravda, bohužel. Sám programuji v oboru embedded sw a u zařízení, která by měla být jakýmsi technickým etalonem jsem nucen více řešit vzhled než funkcionalitu. "Ono to úplně nefunguje? To nevadí, hlavně že to pro marketing bude vypadat dobře ..."
Divný svět, kde se řemeslo a fortel považují div ne za sprostá slova :-(
Ono především bude nutné definovat, kdo má za ta zařízení odpovědnost. Může to být výrobce/dovozce, může to být koncový uživatel, může to být třeba i ISP. A je to celkem jedno, oni už si to mezi sebou nějak smluvně přerovnají. Ale důležité je, aby ta zodpovědnost byla určená. Protože dnes je tím postiženým nějaká univerzita nebo firma, která s tou „hloupou věcí“ nemá vůbec nic společného.
Proc? Jak muze vyrobce ovlivnit, kdo a co s jeho nozem dela? Jak muze majitel toho noze ovlivnit, co snim udela jeho navsteva? Jak to muze ovlivnit spravce silnice?
Je to ejdnoduchy, vyrobce prodava to, co zakaznici kupuji, zakaznici kupuji to, co jim vyhovuje, a spravce silnic se stara o to, aby ty silnice byly sjizdny. A ze nekomu nestacej jedny vrata pro tu hromadu aut ktery k nemu jezdej, je jeho problem. NIkdo mu nebrani si misto vrat postavit betonovej zataras.
... a až dostávajú širšiu cestu, výrobca vyrobí ďalší milión ddos škatúľ :-)
Naopak, popisovaný prípad je jednoznačne zodpovednosť výrobcu a univerzita ho imho mala riešiť.
Posunúť čas vracaný zblázneným televízorom o 30 rokov dozadu, takže ich zákazníci začnú hromadne reklamovať kvôli nefunkčnému nahrávaniu a ssl. Ako whatismyip vracať localhost, takže routery poputujú späť do predajni, nakoľko nebudú routovať. A výrobcu žalovať za sabotáž a tlačiť ho k odškodneniu za každý deň, až kým pokazené mašiny nenesie zo sveta? Ako? Jeho problém.
Len tak bude aspoň nejaká šanca, že v novej verzii škatúľ bude firmware nad ktorým niekto aspoň symbolicky rozmýšľal.
Cokoli co ma v sobe nejaky SW vyzaduje udrzbu stejne jako auto. A stejne jako u toho auta to bud delas sam, nebo si to nekde zaplatis. A nebo se na to, uplne stejne jako u auta, muzes vysrat. To auto taky bude jezdit s 10let starym olejem, brzdovkou ... muze vyrobce za to, ze brzdit nebude?
Muze vyrobce plotu za to, ze ti zrezne, kdyz ho nenatres? Stejne dobre si muzes koupit uz natrenej. Ale musis za to priplatit.
Dokonce si muzes koupit nuz na jedno pouziti ... muze vyrobce za to, ze nebude fungovat jeste za rok?
Proste dostanes PRESNE to, co si ZAPLATIS. A pokud si zcela dobrovolne kupujes smejd, tak dostanes smejd. Pokud si nekdo koupi hrnce za 50k, a jde si stezovat, mel by dostat jeste 50 ran bicem a verejne.
To prece neni vubec o v6ce... Vetsina orpavdu blbych (dneska) zarizeni nikdy ani v6ku implmentovat nebude, takze modlit se ke 6kove spase je o nicem. Naopak tim VYRAZNE naroste pocet moznych utoku... Je to o neschopnosti firem a konzumetarismu, kde si neuvedomujou dusledky sveho chovani. Vzhledem k tomu, ze dneska se ridi uz kde co, pocinaje svetlama a konce splachnutim hajzliku, to bude zajimave. U nas se to resi pomerne jednoduse, net (at uz 4ka, nebo 6ka) je jen trasportni vrstva pro par AES paketu a zbytek bezi nekde kontrolovatelne (buzove v Cloudu). Spolehat na podobne otevrene zdroje muze jen trotl, zvlastne kdyz uz tam prijdou sluzby, o jejichz kompromitaci je evidetni zajem (EZS, poskozeni vyroby...). Jeste bych podotkl, ze hloupa zarizeni neni TV ani router, kde bezi "plnohotnotny" kernel (treba Hurd :) ale opravdu ta, ktera nejsou videt a cim dal tim vic se vsude rozsiruji. Obvykle nedelaji nic, krom rizeni, bonzovani, .... O to je horsi, kdyz se takova zarizeni vys.... :) Jak uz napsal jinej Muf, dokud se nezmeni pricina, tezko se zmeni dusledky. A takove ty tiche krabicky, co treba rozvicujou lampy ve mestech, ridi pristupy, dohleduji jine systemy treba ve vyrobe, nebo doprave, .. jsou pripojeny k netu ? Protoze ten pocit, ze to ma nekdo "pod kontrolou" je prece krasnej, obvykel tech nekolik lidi, kteri to udrzujou v chodu, muzou neco udelat primo z hospody (o: Nicmene, mira diletanstvi v tomto oboru vysoce nadprumerna :) Takze neco jako fyzicke oddeleni siti nepripada moc v uvahu, benefity spojene se spojenim skrze net jsou tak velke, ze i bezpecnostni pozadavky se casto prizpusobi....
Osobne jsem docela zvedavej, co vypadne ze spojenetctvi Dědka a NICu...
R.
Pěkný článek, který bych si nikdy netroufla napsat. Názory autora víceméně sdílím, jenže kdykoliv jsem na tyto věci upozornila, byla jsem za idiota. Opravdu není dobré používat kdejakou službu o jejímž pozadí nic nevíte. To jsou přesně ty věci, které způsobí, že se z ničeho nic něco rozbije. Pokud někam pustíte statisíce věcí, mělo by to být vyzkoušené atd.
IPv6 je nutnost bez ohledu na internet věcí. Ale prorokuju, že to bude muset přijít zákonem podobně, jako to bylo u přechodu na DVB-T. Faktem taky je, že kdyby z procesu tvorby IPv6 někdo zavčas vykopal akademiky a následně to navrhovali lidé, co tomu rozumí, byl masivní rozvoj Internetu po roce 2000 už na 6ce a nebylo co řešit. A taky by nás nebolela hlava z takových věcí, jako je třeba ra.
Pokud jde o humanitce, mám je ráda, jsou zábavní, ale v IT je vidím stejně ráda jako polovzdělané geeky. Jejich destruktivní potenciál je tak zhruba stejný.
A pokud jde o zmíněnou službu na vrácení ip. Cítím za tím nějaký SIP telefon. A v klidu bych zkusila nečekané odpovědi. Pokud takové věci nezačneme aktivně rozbíjet, nikdo nevyrazí jejich vývojáře a tím pádem takových krámů bude víc a víc až se z toho kolektivně okotíme.
> Faktem taky je, že kdyby z procesu tvorby IPv6 někdo zavčas vykopal akademiky a následně to navrhovali lidé, co tomu rozumí, byl masivní rozvoj Internetu po roce 2000 už na 6ce a nebylo co řešit.
To už je snad na založení "Kanceláře pro uvádění příběhů o IPv6 na pravou míru"...
https://en.wikipedia.org/wiki/IPv6#Working-group_proposals
The working-group members were J. Allard (Microsoft), Steve Bellovin (AT&T), Jim Bound (Digital Equipment Corporation), Ross Callon (Wellfleet), Brian Carpenter (CERN), Dave Clark (MIT), John Curran (NEARNET), Steve Deering (Xerox), Dino Farinacci (Cisco), Paul Francis (NTT), Eric Fleischmann (Boeing), Mark Knopper (Ameritech), Greg Minshall (Novell), Rob Ullmann (Lotus), and Lixia Zhang (Xerox).
Plno akademiků a žádná komeční firma, co?
Zjednodušujete to jak vy, tak váš předřečník. Ten si vytvořil vazbu akademik = mudrlant, co tomu nerozumí a vy si vytváříte stejně tak jednoduchou rovnici jméno + firma = člověk z komerce, co tomu asi rozumí.
Kancelář pro uvádění příběhů na pravou míru se ale nemůže dívat na takovéto povrchní rovnice, ale musí se dívat na reálné dotazy a připomínky, které tito lidé do diskuze zasílají. Množství z nich sice pracuje v komerčních firmách, ale většinou v nějakém R&D oddělení a jsou de facto akademici. Stačí chvíli sledovat v6ops, 6man atp. a můžete si velké množství z nich zařadit do škatulky mudrlantů, kteří, ač jsou z komerčních firem tak nemají zkušenosti a reálné komerční síťové prostředí neviděli ani z rychlíku.
Dufam, ze masivna IP premavka z chladniciek, mikrovlniek, praciek a podobnych zariadeni zahlti taketo data centra:
https://en.wikipedia.org/wiki/Utah_Data_Center
1) IPv6 je nutnost. Bez něho se dvě zařízení domluví njenom přes veřejnýho prostředníka. Probíhá to tak, že se kávovar ptá skrz NAT a síť ISP co 20s serveru, jestli mů vařit latté nebo espresso a kolik smetany do něj. Bez ohledu na to, že jsou tři hodiny v nci a nikdo to po něm nechce. Appka v mobilu se zase furt co 5s ptá, jestli na chatě není zloděj.. pokud bude 1 dotaz/odpověď 0,5kB co 5s, dává tyo průměrný traffic 0,1kBps. Ale když těch zařízení bude doma 20 a těch domácností bude 500 000, dá to 1GBps. Jenom na hloupý a zbytečný dotazy. Pokud má být dostupná a nezaspamovaná infrastruktura, je ve veřejným zájmu, aby zařízení na sebe viděla a posílaly se jenom změny. Když to nechce respektovat výrobce, nastavme regulace tak, že IPv6 je povinnost (novela 22/1997 Sb.).
2) Posílání dat ke zpracování na server často nedává smysl a zákazník o tom ani neví. Když je u potravin povinnost informovat o složení, zaveďme povinnost informovat, co se posílá na server. nechť dodavatelé soupeří o autonomii zařízení při výpadku IT infrastruktury.
3) Výrobce musí být zodpovědný za svůj produkt. Dneska podle zákona o výrobcích (22/1997) nesmí výrobek např. rušit ostatní zařízení (EMC) - doplňme tam narušení dostupnosti IT infrastruktury a služeb. Dejmě ČOIce pokyny...
4) Výrobce musí být přinucen poskytovat podporu po celou dobu životnosti výrobku, pokud je tento schopný svou činností narušit zájmy třetí strany (třeba účasti s DDoS), popř. předat nezbytné podklady třetí straně a informovat o tom zákazníka..
5) Uživatel musí mít zodpovědnost za jeho zařízení. Když může zodpovídat za to, že autem nikoho neřejede, že z jeho střechy nespadne sníh někomu za krk, že jeho pes nikoho nepokouše apod., nevím, proč by nemohl zodpovídat za svoje IoT hračky. Tj. za safety update, pokud update nedělá na dálku výrobce. Pokud jeho zařízení něco vyvede a neprokáže, že měl poslední verzi FW, dát mu flastra.
Bohužel, jiná cesta k bezpečnýmu a efektivnímu IoT není :(
Ad1)
Mám automatizované třeba ovládání akvária. Ke komunikaci těchto "hloupých" zařízení, jako ESP, arduino atd slouží protokol MQTT, pro trvalou komunikaci s webovým rozhranním/mobilní aplikací pak WebSocket. Mezi tím mi stojí jednoduchý broker, který nový požadavek, nebo naměřenou hodnotu předá když je potřeba, nikoliv v časových intervalech jako v dobách ajax.
Nevím, jak by mi k tomu IPv6 pomohla, autorizace zařízení, nebo webiu mi řeší onen broker, pokud tam tečou data odjinud, ignoruje je.
1)
V době, kdy každé pako, kterému se podařilo rozběhat wordpress a změnit mu šablonu, se považuje za programátora, mi to přijde jako utopie.
novela 22/1997 Sb.
Přeji hodně štěstí při prosazování tohoto vtipu korporacím a Číně
2)
Hodně štěstí při prosazování tohoto úmyslu vůči celému světu
3)
Hlásím se k ČOIce, firemní výlety do Číny budou pěkné
4)
Jakým konkrétním způsobem je chcete donutit? (Hodně štestí s Čínou mi už přišlo jako klišé)
5)
Uvědomujete si problematičnost této krásné myšlenky? Budete prosazovat nějaký unifikovaný způsob update fw? A podobných problémů je tam spousty.
Ty podle mě neuděláš taky aby nebyly dosahem omezené jenom na tu jednu síť.
Ale skrývání mi přijde přeceňované, stačí, aby to zařízení začalo komunikovat (což je tak nějak jeho smyslem), a už bude slyšet. Navíc uváděné privacy extensions znemožní jeho vzdálené ovládání i vlastníkovi a to je opět často smyslem…
Chjo ... zase ...
privacy extension nic neznemoznuje. Pouziva se vyhradne pro odchozi komunikaci. Kazdy zarizeni ma zaroven fixni IPcko (ktery v principu nesmi pro odchozi provoz se zapnutym privacy vubec pouzivat). Ale pokud chci aby se na to zarizeni dalo pripojit, je prave to fixni IPcko to, ktery patri do dns.
Proč?
1) Za tu 404 tě prostě nikdo nezavře, i kdyby se rozkrájel.
2) Přečti si zdroják nějaké pěkné 404. Doporučuji třeba: http://www.google.cz/wasedfgh
Zatím bych to nijak neřešilm uvidíme jak se to bude vyvíjet. Aktuálně se vše jeví že se jedná opět o mega giga ultra PR kampaň jako jsme tu zažily už s netbooky, cloudem, bitcoinem,big data apod. Hlavně je nutno hejlům prodat iluzi vychytaného bydlení kde budou štastně vychovávat potomstvo a získají informace které nepotřebují ze zařízení které jsou k ničemu.
Free, Cool a In "zdar"
Kapitalismus narazil na své hranice zejména v rámci morálky. Zboží se už nevyrábí proto, aby splnilo určitou službu. Jde jenom o prodej. V případě "internetu věcí" se někdo snaží vymyslet nové odvětví, aby z nás vytěžili další peníze.
Ona se vůbec technika a nejrůznější "vynálezy" vystavují jako nějaká svátost. Rychlejší, menší, větší... Tyto a jiné přívlastky typu nám cpou před nos a snáží se nám na nich demonstrovat zlepšení kvality života.
To je omyl - lidstvo je cháska nespokojená a potřebuje neustále nové impulsy, které mu dodají pocit, že se "něco" děje. Inu když někdo potřebuje vlastnit "něco", aby byl "někým...
Když někde vidím noblesní slovíčka typu super, ultra, multi... atd., můj mozek bije na poplach... To už jsem ale dost odbočil od tématu- omlouvám se.
... by byl taky zajímavý téma. A týká se to i profesionálů. Viz moje zkušenost s bankou, kde mám hypotéku (proto zatím nebudu jmenovat.
1. Poštou došel normální (!) dopis, kde jsou přihlašovací údaje k portálu. Našel jsem tam jenom čtyřmístný PIN a bylo uvedeno, že jako přihlašovací jmén mám použít číslo účtu. Číslo účtu bylo v záhlaví (rok 2011).
2. Po přihlášení hned naběhla historie transakcí a osobní údaje. Změnu hesla ani jinou konfiguraci jsem nikde nenašel, natož pak nějaký požadavek na dvoufaktorovou autentizaci. Takže klienti mají množinu 10^4 hesel a jako user name devítimístný násobky čísla 11.
3. Proti brute force je to chráněno dočasným zablokováním po několika špatných PINech.
Docela rád bych věděl, co by banka dělala, kdyby někdo napsal bota, který zvolí náhodný PIN a z několika IP adres na něho začne střílet náhodně generovaný čísla účtů s fixním PINem... Prolomení jednoho účtu by sice s blokací po špatným PINu trvalo dlouho, ale skenování osobních údajů to nezpomalí. Při 100 requestech/s a obsazených 10% čísel účtů je to v průměru 3,6 prolomených účtů za hodinu. A při jejich blbosti je možný, že čísla účtů generují popořadě...
Jako "Safety Assisted DoS"? :D Zajímavá myšlenka.
Při 50k klientů a pětiminutové blokaci stačí ani ne 170 spojení po TCP za sekundu. Na lince se to hádám ani nepozná... A když je bot s 300 neudržovanýma IoT krámama, každý posílá paket 1x za 2s... A 50 000 lidí se nedostane na účet. Jenom díky predikovatelnýmu login name...