Po roce byla vydána nová stabilní verze 25.6.0 svobodného multiplatformního multimediálního přehrávače SMPlayer (Wikipedie).
DNS4EU, tj. evropská infrastruktura služeb DNS založená na vysoce federovaném a distribuovaném ochranném ekosystému, byla spuštěna v testovacím režimu [𝕏]. Na výběr je 5 možností filtrování DNS.
Skriptovací programovací jazyk PHP (PHP: Hypertext Preprocessor, původně Personal Home Page) dnes slaví 30 let. Přesně před třiceti lety, 8. června 1995, oznámil Rasmus Lerdorf vydání PHP Tools (Personal Home Page Tools) verze 1.0.
Ve středu v 17:00 byl ve Francii zablokován přístup k PornHubu a dalším webům pro dospělé. K 17:30 došlo k nárůstu počtu registrací Proton VPN o 1 000 % [𝕏]. Dle nového francouzského zákona jsou provozovatelé těchto webů povinni ověřovat věk uživatelů prostřednictvím průkazu totožnosti nebo platební karty.
Před 32 lety, 6. června 1993, byl spuštěn první český WWW server (ještě pod TLD .cs), pro potřeby fyziků zabývajících se problematikou vysokých energií.
Střílečku Borderlands 2 lze v rámci výprodeje série Borderlands na Steamu získat zdarma napořád, když aktivaci provedete do 8. června 19:00.
Byla vydána nová verze 2.22 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
Canonical Launchpad vypíná systém správy verzí Bazaar. Vývojáři mohou své repozitáře do 1. září přemigrovat na Git.
Byla vydána nová verze 2.53.21 svobodného multiplatformního balíku internetových aplikací SeaMonkey (Wikipedie). Přehled novinek v poznámkách k vydání.
Petici za povinné zveřejnění zdrojových kódů softwaru použitých ve veřejné správě lze podepsat na ePetice.
nazminujete se o nejvetsim problemu a tou je casova promenlivost dopadu povahy dat. Dnes neskodna data, napr. ze je nekdo homosexual mohou mit za 20 let dalekosahle nasledky, az bude potreba najit skupinu tech 'kteri za to mohou'. A centralni data dnes muze bez povoleni soudce prohlizet kdejaka sluzba. Ponechat jakakoliv data nekomu tretimu je velmi nebezpecne. Jedina ochrana je, ze data jsou roztristena tak detailne, ze je technicky nemozne najit souvislosti.
Tohle bych mozna upresnil. Jsou v podstate dve hlavni vyuziti cloudovych ulozist - jako rozlozeni zateze narocnych webovych stranek a jako interni datove uloziste (zalohy, archivy). V tom prvnim pripade jde o verejna data (resp. data, ktera by byla stejne uverejnena na webovem serveru klienta). V druhem pripade ani nepripoustim fakt, ze by nekdo pustil ven interni data spolecnosti bez hodne silne sifry.
To mi pripomina nedavny exces s klici v Debianu. Jestli jsem tehdy pochopil problem, tak v pripade pouziti toho spatneho klice z Debianu by bylo mozne dostat se nepovolene k sifrovanym datum ulozenym na techto "verejnych" ulozistich...
Jasne, byl to spis recnicky obrat. Stejne si nejsem jisty, jak moc by to cesky Internet ustal, vzhledem k tomu, ze ma Sitel (NIX4?) nejrychlejsi konektivitu. Znate to, cim pretizenejsi nejaka linka je, tim rychleji uzivatele klikaji na F5 .
> Jsem zvědavý na tu diplomku,
Netýká se přímo cloud computingu . Píšu o Toru a dalších anonymizačních sítích.
> oni sice nevidí "dovnitř", ale pro mnohé z nich je to spíš východa
Samozřejmě něco jiného je _možnost_ a _potřeba_. Souhlasím, že je dobré, že firmy nepotřebují znát technické detaily, prostě dostanou API. Na druhou stranu fakt, že nevím, jak ta technologie funguje ve mě moc důvěry nevzbuzuje. Viz případ té firmy, co ztratila 50% dat. Myslím, že v případě solidního designu té sítě se tohle prostě _nemůže_ stát.
> failures různých cloudů se mohutně publikují
Publikují se následky, ale ne příčiny. To, že Amazon tehdy a tehdy nejel vím, ale byla odstraněna příčina, aby se to příště nestalo? Myslím, že ten zajíc v pytli na tohle sedí docela trefně. Ostatně myslím, že na tomhle serveru nejsem sám, kdo má rád otevřenost .
> možná že u profíků typu Google nebo Amazon, keří se na tohle specializují, je to riziko přece jen menší než když si to budeme dělat sami
Tak samozřejmě je pravděpodobné, že diskové pole Google bude spolehlivější než Frantovo Diskové Pole (tm). Jde o to, co se v globálním měřítku stane, když vypadne FDP (tm) a když Google. Z tohodle pohledu má Google mnohem větší zodpovědnost než Franta.
> problém z hlediska hrozby vendor lock-in
Správně jste postřehl, že se zajímám úzce o data storage cloudy. V téhle oblasti si zase nemyslím, že ten vendor lockin je nějak výrazně možný. Je celkem jedno, jestli se ta data nahrávají přes FTP, NFS, WebServices nebo FrantuvProtokol(tm, samozrejme), protože je velmi jednoduché realizovat abstrahující mezivrstvu.
> Tohle by mohlo pro firmy problém s uzavřeností řešit lépe než provoz nezávislými právními subjekty
Ne, tohle vůbec neřeší to, co jsem měl na mysli. Pokud bude interoperabilni standard mezi IBM a Amazonem, Vy budete mít data u Amazonu a Amazon "lehne popelem" (prostě se admini ožerou a změní hesla), IBM Vám nepomůže. Já měl na mysli vytvoření absolutně decentralizované sítě, kde když se jeden subjekt rozhodne, že ho to už "neba" a vypne servery, síť se sama zreplikuje. Stejně jako RAID...
> kdo přebere zodpovědnost v případě problému atp
Nikdo . Ostatně stejně jako když se najde bezpečnostní díra v opensource serverovém OS, který ve firmě na všech strojích používáte. Vtip je v tom, že to riziko by bylo rozložené a podle designu by nemusel existovat single point of failure. Něco jiného je chyba v implementaci software, ale od toho zase máme testing, peer reviews a bezpečnostní audity, že ano.
> na druhou stranu je to zajímavá myšlenka a z určitého pohledu má jistě opodstatnění.
Dovedu si představit nějaky opensource projekt... Co jsem hledal na webu, tak jsem nenašel nic přesně takového. Samozřejmě existují implementace cloud filesystémů, ale fígl je v tom, že jsou zaměřené primárně na výkon a vzájemně si důvěřují. Ta myšlenka, kterou tady píšu je o filesystemu, kde se jednotlivé nody _podezírají_. Ani se nesnažím popírat, že ta myšlenka souvísí právě s Torem. Vyžadovalo by to samozřejmě datový i přenosový overhead, ale mohlo by to být opravdu robustní - tedy vhodné pro backupy a archivaci.
Ale kdyby někdo věděl o implementaci něčeho podobného, co tady píšu, tak určitě sem s tím.
> budeš se v té diplomce zabývat i tím?
Ne , diplomka mě jen navnadila na systematické přemýšlení o těhle věcech.
Nevím, jestli jste na to nenarazil, ale existuje projekt Internet Backplane Protocol, což je sada na sobě nezávislých datových úložišť, kterým uživatel apriori nevěří.
Uživatel si vybere cluster, naalokuje prostor (a trvanlivost dat) a odešle zašifrovaná data. Uživateli je vrácena trojice hashů, které slouží jako tokeny pro budoucí tři nezávislé operace – pro čtení dat, pro přepis dat a pro změnu trvanlivosti dat. Takže uživatel A může nahrát data, uživateli B předá hash pro čtení a šifrovací klíč, a uživatel B si pak může data přečíst. Vhledem k tomu, že data se šifrují na straně klientů, tak provozovatel serveru nemá šanci zjistit, co v nich je.
Dále protokol (a některá úložiště) umožňuje asynchronní přesun dat, kdy původnímu úložišti řeknete, že chcete data překopírovat na další vámi určené úložiště a „systém“ se už o to postará.
Celé to bylo vymyšleno pro pro armádní účely a vývoj si zaplatila DARPA. Takže výsledek je pod licencí BSD. Kdybyste chtěl, mám balíčky pro Gentoo (ale testoval jsem jen klientskou stranu).
Zajimave, zajimave! Priznam se, ze na tohle jsem pri svych soucasnych toulkach na Internetu nenarazil, ikdyz ted zpetne si uvedomuju, ze jsem o tom uz kdysi slysel. Samotna klientska strana (co jsem zatim precetl) je zhruba to, jak bych si to predstavoval. Jde o to, ze IBP zrejme neresi failover mezi jednotlivymi cloudy - tj. kdyz nahraju data na jeden depot a jeho node lehne, o data prijdu...? Budu to muset jeste kapanek vic nastudovat.
Myslim, ze ty balicky najdu nekde na Internetu. Kdyby ne, urcite se Vam ozvu. Dekuju za nabidku!
Mimo to take distribuovane sitove datove uloziste (block-level ) vyviji Evgeniy Polyakov pod jmenem DST. Klient uz je v Linux-staging, takze by mohl byt brzy i ve vanilla jadre.
> se v tom postu soustředíš na storage - ale cloud computing není jen o tom, takové věci jako možnost kupovat si výpočetní výkon
Na tohle jsem zapomněl pořádně zareagovat. Hlavní důvod, proč rozebírám především storage je v tom, že u pronájmu výpočetního výkonu nevidím to riziko popisované výše. Výkon je jen tupý výkon. Když není, dá se dokoupit (silně zjednodušeně řečeno). Originální data firmy (archivy) nikoliv...
Presne. IMHO ten problem neni jen o "cloud computingu". Ta neschopnost/nemoznost decentralizace je smutna -- ja cekal, ze s rozvojem P2P siti uvidime masivnejsi prenos techto myslenek i do infrastruktur firem, ale nic...
Tiskni
Sdílej: