Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 140 (pdf) a HackSpace 77 (pdf).
ESPHome, tj. open source systém umožňující nastavovat zařízení s čipy ESP (i dalšími) pomocí konfiguračních souborů a připojit je do domácí automatizace, například do Home Assistantu, byl vydán ve verzi 2024.4.0.
LF AI & Data Foundation patřící pod Linux Foundation spustila Open Platform for Enterprise AI (OPEA).
Neziskové průmyslové konsorcium Khronos Group vydalo verzi 1.1 specifikace OpenXR (Wikipedie), tj. standardu specifikujícího přístup k platformám a zařízením pro XR, tj. platformám a zařízením pro AR (rozšířenou realitu) a VR (virtuální realitu). Do základu se z rozšíření dostalo XR_EXT_local_floor. Společnost Collabora implementuje novou verzi specifikace do platformy Monado, tj. open source implementace OpenXR.
Byla vydána nová verze 0.38.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 4.4 nebo novější a také libplacebo 6.338.2 nebo novější.
ClamAV (Wikipedie), tj. multiplatformní antivirový engine s otevřeným zdrojovým kódem pro detekci trojských koní, virů, malwaru a dalších škodlivých hrozeb, byl vydán ve verzích 1.3.1, 1.2.3 a 1.0.6. Ve verzi 1.3.1 je mimo jiné řešena bezpečnostní chyba CVE-2024-20380.
Digitální a informační agentura (DIA) oznámila (PDF, X a Facebook), že mobilní aplikace Portál občana je ode dneška oficiálně venku.
#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Současné vývojové jádro 2.6 je 2.6.29-rc2. Linus ho vydal těsně předtím, než vyrazil z domova na cestu na linux.conf.au. Přestože je [-rc] relativně malý, je pravděpodobně pro většinu lidí důležitý a výrazný: objevují se první opravy regresí. Na mnoha strojích nefungovala 3D akcelerace (žádný Compiz! Co budeme dělat bez těch třesoucích se okýnek?!), což by mělo být opravené stejně jako tuna podobných záležitostí. Detaily vizte ve zkráceném changelogu, spoustu detailů v kompletním changelogu.
V době psaní tohoto článku nebyla do repozitáře hlavní řady po 2.6.29-rc2 začleněna žádná sada změn. Linus je pravděpodobně poněkud zaneprázdněn svou novou kariérou holiče (přijal výzvu oholit Bdaleho Garbee na charitativní aukci "večeře pro tučňáka" pořádané na linux.conf.au), takže ještě chvíli asi nebude začleňovat patche.
Současné stabilní jádro 2.6 je 2.6.28.1 vydané s dlouhým seznamem oprav 18. ledna.
Co se uživatelů 2.6.27 týče, 2.6.27.12 bylo také vydáno 18., před ním bylo 14. ledna vydáno 2.6.27.11. Greg Kroah-Hartman řekl, že plánuje udržovat 2.6.27 jako relativně dlouhodobé vydání a Adrian Bunk se chystá ho poté převzít, takže pro toto jádro by opravy měly být k dispozici docela dlouho.
-- Andrew Morton má obavy z adaptivních mutexů.
-- Andrew Morton o začlenění SLQB
Tato minikonference v rámci linux.conf.au hostila několik diskuzí o specifických bezpečnostních technologiích, z nichž mnohé zde byly v minulosti pokryty. Závěrečnou událostí dne byla nicméně odborná diskuze pokrývající širokou oblast bezpečnostních záležitostí. Casey Schaufler (který také převzal funkci moderátora), Russell Coker, James Morris, Z. Cliffe Schreuders a Kentaro Takeda diskutovali o skládání modulů [module stacking], zvětšujícím se využití bezpečnostních technologií, autoritativních háčcích a dalších tématech.
Skládání modulů bylo prvním tématem, kterým se zabývali. "Skládání" znamená načtení více než jednoho bezpečnostního modulu s tím, že každý z nich se může účastnit rozhodování o bezpečnosti. Tato technika má své kouzlo; umožnila by napsat a zajímavým způsobem zkombinovat více úžeji zaměřených modulů. Skládání nicméně není v linuxovém jádře podporováno - a jde o situaci, která se podle všeho nebude v blízké budoucnosti měnit.
Casey, který s touto záležitostí začal, zodpověděl svou vlastní otázku tak, že by byl rád, aby bylo skládání modulů podporováno; systému by to přidalo na flexibilitě. Řešení, které preferuje, by zahrnovalo vytvoření speciálního bezpečnostního modulu, který by rozhodoval o tom, který z ostatních bude rozhodovat ve specifické situaci. Pokud vím, tak tento skládací modul ve skutečnosti ještě neexistuje.
Russelova odpověď byla jednodušší: byl by rád, aby rozumný počet uživatelů nejdřív využíval alespoň jeden bezpečnostní modul. Jakmile tento problém bude vyřešen, lze se přesunout ke komplikovanějším úkolům.
James mluvil o "problému skládatelnosti": kombinování bezpečnostních technologií způsobem, který jejich autoři neočekávali a který může vést k nepředvídatelným výsledkům. Lidé pracující na bezpečnostních technologií, nesnáší nepředvídatelné výsledky. Vývojáři SELinuxu se snažili tento problém řešit tak, že by byl SELinux jediný pravý bezpečnostní modul (termín autora článku, nikoliv Jamesův), takže by jakoukoliv bezpečnostní situaci bylo možné řešit v rámci jednoho modulu. Tento aspekt SELinuxu nicméně není skutečně využíván.
Cliffeovou odpovědí bylo to, že skládání by mělo být povoleno, i kdyby jenom proto, aby to vývojáře odradilo od přidávání paralelních sad háčků, které podporují jejich vlastní bezpečnostní technologie. James nicméně reagoval, že mnoho s bezpečností spojených modulů (řekněme správa integrity [integrity management] nebo vyhledávání malwaru) by skutečně mělo mít své vlastní API. Kentaro poznamenal, že vývojáři TOMOYO Linuxu opravdu chtějí, aby jejich práce mohla koexistovat s ostatními moduly, takže by také byl rád, aby bylo skládání podporováno.
Zde Jon Corbet diskutující požádal, jestli by mohli rozvést Russelovu myšlenku: Jak zajistit, aby lidé používali bezpečnostní technologie, které máme nyní? Bezpečnostní modul není moc k užitku, když ho frustrovaný správce systému jednoduše vypne ve chvíli, kdy se mu plete do cesty. Casey odpověděl, že bylo nešťastné, když byl první bezpečnostní modul daný k dispozici k širokému používání (SELinux) tak komplexní. Spousta lidí skutečně nepotřebuje všechny možnosti, které SELinux poskytuje. Sada menších a pochopitelnějších bezpečnostních modulů by si přijetí získala mnohem snadněji. SELinux je příliš monolitický; nedá se použít jen tak nalehko.
Russel navrhl, abychom se podívali na historii bezpečnosti. Kdysi byl přijat názor, že všechny důležité procesy by měly běžet pod rootem. Postupem času se jasně ukázalo, že to byl špatný nápad, a různé systémové démony se přesunuly k jinému uživatelskému ID. Nepředložené praktiky jako spouštění IRC klientů pod rootem byly zakázány. Dostat se do tohoto bodu znamenalo dlouhý proces výuky; tento proces bude muset u technologií, jako je SELinux, pokračovat. James souhlasil, že je zapotřebí čas, a poznamenal, že s postupem času se využití SELinuxu zvyšuje. V tomto ohledu mohou pomoci některé jednoduché věci, jako je přimět administrátory přepnout SELinux do tolerantního režimu místo toho, aby ho vypnuli úplně.
V dlouhodobém měřítku je nicméně potřeba nástroje pro vyšší úrovně. Současné rozhraní politiky SELinuxu je v podstatě assembler (na SELinuxu založené) bezpečnosti; většina uživatelů by neměla být nucena pracovat se systémem na této úrovni. Cliffe souhlasil s tím, že svalit vinu na uživatele, když vypnou zabezpečení, je špatný způsob. Jde o chybu vývojářů zabezpečení, jejichž nástroje nejsou dostatečně jednoduché, aby je bylo možno používat. Bezpečnost musí být stavěna s použitím abstrakcí na vyšší úrovni, kterým uživatelé mohou porozumět; technologie, na které pracuje (FBAC-LSM) je navrhována s ohledem na tento cíl. Kentaro dodal, že většina uživatelů nechce být nucena k přemýšlení o zabezpečení; je potřeba ho implementovat tak, aby nemuseli.
Zde se diskutující přesunuli k diskuzi o cloud computingu. James, poté, co se zeptal, co tento termín skutečně znamená, poznamenal, že v této oblasti se dá udělat mnoho užitečných věcí a že Linux nabízí hodně užitečných technik, které mohou pomoci - například jmenné prostory. I zde je nicméně potřeba udělat spoustu práce. Cliffe dodal, že existuje infrastruktura pro lidi, kteří chtějí pracovat na bezpečném cloud computingu, ale skládání modulů by ji zjednodušilo. Kentaro prohlásil, že cloud computing je jedním z klíčových cílů jeho práce; zde je pro Linux spousta prostoru. Je však potřeba se vyhnout vytvoření jediného kritického bodu [single point of failure], který by celou tu věc mohl položit. Caseyho příspěvek k tomuto tématu byl, že cloud computing pravděpodobně přivede kryptografii zpět do popředí bezpečnostního výzkumu; když jsou vaše data na serverech jiných lidí, tato data je potřeba dobře chránit.
Russel se k diskuzi připojil s tím, že bezpečnost mnoha ze současných nabídek cloud computingu je podprůměrná. Často jsou nabízeny distribuce, které již nemají bezpečnostní podporu a poskytují spousty nepatchovaného softwaru. Jsou nezabezpečené a "zralé ke sklizni", ale ani pro relativně znalého uživatele není v takových prostředích jednoduché věci zabezpečit. Skutečným problémem, říká, je to, že neexistuje žádný obchodní model pro lepší bezpečnost, takže poskytovatelé "cloudu" do této oblasti neinvestují.
Někdo z obecenstva se zeptal na autoritativní háčky. Tyto háčky byly v počátku vývoje architektury linuxových bezpečnostních modulů spornou záležitostí, LSM je v současnosti navrženo tak, že umožňuje pouze restriktivní háčky: bezpečnostní modul může bezpečnostní politiku oproti základnímu linuxovému řízení přístupu pouze zpřísnit. Za tím je skryta myšlenka, že chyba v bezpečnostním modulu nemůže věci zhoršit víc, než jak byly. Autoritativní háčky by na druhou stranu nechaly bezpečnostní modul umožnit procesu, aby dělal věci, které by mu jinak nebyly dovoleny.
Casey zopakoval historii skrývající se za současnou politikou "žádné autoritativní háčky" a dodal, že jaderní vývojáři se také obávali, že by autoritativní háčky zjednodušily zneužití LSM API binárními moduly. To vskutku bylo, jak říká, hlavní důvodem zákazu těchto háčků. Tato politika nicméně nezpomalila proprietární bezpečnostní moduly a v současnosti by byl model umožňující autoritativní háčky lepší. Provést takovou změnu by však bylo "skutečně dost náročné". Russel souhlasil, že tyto "iracionální obavy" z autoritativních háčků jsou stále široce rozšířené, ale jistota poskytovaná jejich nepřítomností by se nakonec mohla vyplatit. Jak Cliffe, tak Kentaro si mysleli, že s autoritativními háčky by bylo možné udělat zajímavé věci a že je možná správný čas revidovat to, jak linuxové bezpečnostní moduly fungují.
Proběhla krátká diskuze o pocitu, že LSM API je příliš silně orientováno na potřeby SELinuxu. James souhlasil, že bylo podle SELinuxu "tvarováno", ale poznamenal, že je to přirozený důsledek faktu, že SELinux byl jediným uživatelem tohoto API po většinu jeho historie. Casey poznamenal, že věci se v nedávné době změnily podle potřeb jeho modulu SMACK. Také se objevily nějaké nové háčky kvůli podpoře na cestách založených modulů jako je TOMOYO Linux a AppArmor.
Další člen obecenstva se vrátil k jiné záležitosti, o které se zmínil Russel: co by měly distribuce dělat, když dospějí ke konci svého života. Měl by systém s nepodporovaným jádrem odmítnout bootovat nebo alespoň odmítnout aktivovat síťová rozhraní? Russel reagoval zjevnou odpovědí: jak by člověk potom takový systém mohl aktualizovat? Casey upozornil na to, že v provozu je strašné množství routerů, na kterých běží starý nepodporovaný software, Internet, říká, je vytvořen z prošlých systémů. Russel navrhl, že ISP by možná měli vynutit používání podporovaného softwaru a že by vlády možná měly toto jednání podporovat. Cliffe poznamenal, že toto představuje další problém s použitelností: ve skutečnosti potřebujeme zajistit, aby bylo jednoduché provozovat aktuální systém. V tomto směru došlo k poměrně slušnému pokroku.
Poslední téma se zabývalo "bezpečnostní mytologií", tj. věcmi, o kterých "každý ví", že zlepšují bezpečnost, ale ve skutečnosti tomu tak není. Nucené změny hesla jsou jednou z takových záležitostí. Casey řekl, že nějakých 20 let každý "věděl", že bezpečnost znamená silnou kryptografii. Tyto věci je potřeba řešit jako problém lidí, jiný způsob není. Russel dodal, že často není možné zjistit, jaké jsou dopady bezpečnostních pravidel. James řekl, že je skutečně potřeba, aby se technicky zaměření lidé postavili proti hloupým bezpečnostním pravidlům. Přirovnal to k problému časného nasazení Linuxu, kde ho lidé nejprve nasadili a později žádali o odpuštění. Cliffovým názorem je, že uživatelé ve skutečnosti neví, kdy se po nich žádá rozhodnutí spojené s bezpečností, takže ve skutečnosti neví, kdy mohou jejich činy ohrozit jejich vlastní bezpečnost. Kentaro souhlasil s tím, že je potřeba najít způsoby, jakými uživatelům poskytnout více informací o tom, k čemu je ve skutečnosti jejich bezpečnostní technologie.
Diskutéři se poté rozprchli a začal večírek podepisování PGP klíčů (což bylo bezpochyby provedeno vysoce bezpečným způsobem).
Originál tohoto článku napsal Joab Jackson.
Někdy koncem ledna nebo začátkem února vydá Internet Engineering Task Force své konečné požehnání nejnovější verzi dlouhověkého Síťového souborového systému [Network File System, NFS], verzi 4.1. I když autoři nového standardu zdůrazňují, že jde o menší revizi NFS, objevuje se zde přinejmenším jedna radikálně nová možnost nazvaná Paralelní NFS (pNFS).
Nálepka "paralelní" u pNFS znamená, že NFS klienty mohou přímo přistupovat k velkým úložným systémům bez nutnosti jít přes úložný server. Bez vědomí klientů jsou ukládaná data rozdělena mezi několik disků, takže když jsou potřeba, lze je stahovat paralelně, čímž se ještě více sníží doba jejich získávání. Kdo provozuje clusterový počítačový systém, okamžitě vidí přitažlivost tohoto přístupu.
Začali jsme s procesem posílání všech těchto patchů správcům NFS v Linuxu, řekl Brent Welch, ředitel architektury softwaru firmy Panasas, která je jednou ze společností zaměřených na ukládání dat, jež se podílely na kódu pNFS. Poznamenal, že práce na prototypu a implementaci pNFS jako části NFS v Linuxu probíhá již kolem dvou let. Pokračující práce zahrnuje aktualizaci softwaru jak NFS klienta, tak NFS serveru.
Kód bude podle Brenta do linuxového jádra navržen ve dvou sadách. První sada bude obsahovat základní procedury nastavování a ukončování pNFS sezení, které budou pro výměnu ID a inicializaci/ukončování sezení používat vzdálené volání funkcí [Remote Procedure Call, RPC]. Vývojové týmy se ženou za tím, aby základní rozvržení pNFS bylo začleněno do jádra 2.6.30. Druhá sada, připravená pro 2.6.31, bude větší patch, který bude obsahovat I/O příkazy pro přístup a změnu rozvržení souborů stejně jako pro čtení a zápis dat. Vzhledem k tomu, že významné distribuce převezmou jádro 2.6.31 až několik měsíců poté, co bude vydáno, pNFS pravděpodobně nebudou před začátkem roku 2010 nasazovat ani ty nejambicióznější IT firmy.
NFS všichni známe. Umožňuje klientským strojům připojit unixové disky, které jsou uloženy někde na síti, tak, jako by šlo o lokální disk. Mnoho polí založených na úložných zařízeních připojených k síti [Network Attached Storage, NAS] používá NFS. S NAS leží spousta pevných disků za jedinou IP adresou, všechny disky jsou spravovány NAS strojem. NAS umožňuje organizaci do fondů [pool], takže správci mohou jemněji (a tím efektivněji) alokovat úložný prostor mezi všechny uživatele.
V roce 2004 vysvětlili ve vyjádření problému dva vývojáři zodpovědní za rozjetí pNFS (ředitel technologie [chief technology officer] Panasas Garth Gibson a technik Network Appliance (NetApp) Peter Corbett), jaká jsou omezení tohoto přístupu, obzvláště v prostředích vysoce výkonných výpočtů:
V kostce vysvětlili, že hlava NAS [NAS Head] - nebo server - představuje potenciální problém s NAS (nebo jiným typem na NFS založeném síťovém ukládání dat). Jestliže příliš mnoho klientů naráz od serveru něco požaduje, I/O se zpomalí všem. Lze se vrátit k přímému přístupu, ale tím se ztrácí výhody společného ukládání. Pro clusterové výpočetní systémy, ve kterých mohou tucty uzlů pracovat se stejnou sadou dat, takto rozdělené ukládání prostě není proveditelné. Totéž platí pro několik úložných serverů: systém založený na NFS nemůže podporovat několik serverů, které by zapisovaly do stejného souborového systému.
Garth a Peter byli první tahouni vývoje pNFS, společně s Gary Griderem z Los Alamos National Laboratory. V další práci pokračovali technici z EMC, Panasas, NetApp a dalších společností. Centrum pro integraci informačních technologií [Center for Information Technology Integration, CITI] Michiganské univerzity společně s IBM Almaden Research Center vyvíjejí implementaci pNFS pro Linux pro klienty a úložné servery.
pNFS umožní klientům se přímo připojit k úložnému zařízení, které potřebují, místo připojování se přes nějaký druh brány. Lidé za pNFS rádi říkají, že jejich přístup odděluje řídící provoz od datového provozu. Když klient požaduje konkrétní soubor nebo blok na úložišti, vyšle požadavek serveru nazvanému Server metadat [Metadata Server, MDS], který vrátí mapu toho, kde všechna data sídlí uvnitř síťového úložiště. Klient poté může k datům přistupovat přímo podle práv nastavených souborovým systémem. Jakmile je úložiště změněno, klient na změny upozorní MDS, které aktualizuje rozvržení souborů.
Vzhledem k tomu, že pNFS klientu umožňuje hovořit přímo s úložným zařízením, stejně tak jako umožňuje rozdělit klientská data mezi několik úložných zařízení, má klient k dispozici rychlejší I/O, než kdyby musel jednoduše komunikovat s jedinou NAS hlavou - nebo komunikovat s jediným úložným serverem. V roce 2007 tři vývojáři z IBM Almaden Research Center, Dean Hildebrand, Marc Eshel a Roger Haskin, demonstrovali [PDF] na konferenci Supercomputing 2007 (SC07), jak mohou tři klienty saturovat desetigigabitovou linku čtením dat z 336 na Linuxu založených úložných zařízení. Takové propustnosti by bylo těžké dosáhnout při použití standardního NFS při přístupu k jedinému souboru, řekl Dean. Chtěli jsme ukázat, že pNFS může škálovat podle síťového hardwaru, který je k dispozici.
pNFS je převážně založeno na třech sadách protokolů. Jeden protokol je pro mapování či rozvržení zdrojů, které jsou uloženy na klientu. Interpretuje a zužitkovává mapu vrácenou od serveru metadat. Druhý je transportní protokol, který je také uložen na klientu. Koordinuje přenos dat mezi klienty a úložnými zařízeními. Transportní protokol zajišťuje samotné I/O s úložnými zařízeními. Řídící protokol synchronizuje server metadat s úložnými zařízeními. Poslední protokol je jediný, který není specifikován NFS - je dán k dispozici výrobcům, i když většinu toho, co bude tento protokol zajišťovat, lze zakódovat do NFS příkazů.
pNFS může pracovat s třemi typy ukládání dat - na souborech založeným ukládáním, na objektech založeným ukládáním a na blocích založeném ukládání. Protokol NFSv4.1 sám o sobě obsahuje na souborech založený úložný protokol. Pro objektové a blokové protokoly jsou vyvíjena dodatečná RFC. Na souborech založené ukládání je to, co většina správců systémů považuje za ukládání; je to standardní přístup uložení souborů do hierarchické sady adresářů. Na blocích založené ukládání se používá v úložných sítích [Storage Area Network, SAN], ve kterých aplikace přistupují k diskovému prostoru přímo posíláním příkazů SCSI [rozhraní malých počítačových systémů, Small Computer System Interface] přes Fibre Channel, nebo v současnosti stále častěji přes TCP/IP pomocí Internet SCSI (iSCSI) protokolu. Na objektech založené ukládání je novější hráč, jde o paralelní přístup, který zahrnuje ukládání samotných dat společně se sebepopisujícími metadaty.
Slovo o sémantice: Mějte na paměti, že NFS není sám o sobě souborový systém, což platí i pro pNFS. NFS poskytuje protokoly pro práci se vzdáleným souborovým systémem tak, jako by byl lokální. Stejně tak pNFS nabízí možnost pracovat se soubory spravovanými paralelním souborovým systémem, jako by byly na lokálním disku, a řešit přitom takové záležitosti, jako je nastavování práv a zajišťování integrity dat. Naštěstí během posledních pár let vzniklo několik paralelních souborových systémů, které by měly s pNFS fungovat snadno. Na straně open source je paralelní virtuální souborový systém (pVFS). Pravděpodobně nejpoužívanějším open source paralelní souborový systém je nyní Lustre, na který dohlíží Sun Microsystems. Na komerční straně byl ve vysoce výkonných výpočetních clusterech úspěšně nasazován souborový systém PanFS firmy Panasas, stejně jako General Parallel File System (GPFS) od IBM. Všechny tyto přístupy sdílí stejný nápad - nechat klienty komunikovat přímo s úložnými zařízeními, přičemž rozvržení úložiště sleduje nějaký druh serveru metadat. Většina dalších možností nicméně spoléhá na používání výbavy od jediného výrobce.
Hlavní výhoda [používání pNFS] se očekává na straně klienta, poznamenává CITI programátor J. Bruce Fields, který testuje NFS 4.1 na linuxových serverech. U většiny paralelních souborových systémů jsou potřeba nějaké rekonfigurace jádra na klientech, aby mohly s těmito souborovými systémy pracovat. Na prototypu linuxového klienta je možné spustit standardní příkaz mount a dostat se k souborům, které jsou požadovány. Klient automaticky jedná s pNFS a najde datové servery. Až budeme hotovi, mělo by to bez námahy fungovat na linuxovém klientu v kterékoliv distribuci, kterou si vyberete, říká.
Výhodou pNFS je, že NFS všichni znají, a navíc bude v NFS přimo zabudováno. Fakt, že NFS je standardní komponenta v téměř všech překladech linuxového jádra, značně omezí množství práce, kterou budou muset správci vynaložit, aby pro linuxový server nastavili paralelní souborový systém. Většina správců je více obeznámena s obecnými postupy pro zacházení s NFS. Mnohem více, než řekněme se zacházením s Lustre, které potřebuje mnoho jaderných patchů a odlišné chápání, když přijde na porozumění příkazů.
pNFS by mělo pomoci i prodejcům úložišť, protože nebudou muset portovat klientský software na mnohé linuxové distribuce. Brent Welch například poznamenal, že Panasas musí udržovat kód pro tucty linuxových distribucí. Místo toho by se dalo spolehnout na NFS a soustředit se na úložná zařízení. Podle společné přednášky, kterou měli někteří vývojáři na konferenci SC08, Panasas, NetApp, EMC a IBM slíbily [PDF], že budou pNFS podporovat přinejmenším v některých svých úložných produktech. Sun Microsystems má také v plánu podporovat pNFS v Solarisu.
A i když se většina současné práce na pNFS soustředí na práci velkých clusterů, jednoho dne by mohlo být možné, že by pNFS v nějaké podobě používaly i pracovní stanice a desktopy. Gary Grider upozornil na to, že v určitém bodě je možné, že budete mít několik teraflopů ve své kanceláři, v takovém případě možná budete pro přístup k datům na tak silném osobním systému potřebovat něco víc, než je pouhé NFS. pNFS se v takovém prostředí může hodit.
Vskutku. Před dávnými časy jsme byli omezeni k práci pouze se soubory, které byly přímo na našich vlastních strojích, přes FTP jsme stahovali cokoliv, co bylo uložené jinde. NFS nám ale umožnilo připojovat disky přes síť relativně jednoduchým příkazem. Nyní může pNFS věci zjednodušit ještě o krok více tím, že nám umožní ukládat velké soubory nebo spousty souborů s rychlostí, o které můžeme nyní jenom snít. To je přinejmenším příslib pNFS.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Takže Panasas ještě existuje? Před pár lety jsem s nimi měl tu čest, a PanFS mi přišel jako skvělá věc. Jen jsme měli trochu problém jak ty 4Gbps z Panasas storage clusteru rozumně dostat ke klientům, aby nikde nebylo úzké hrdlo. Jestli podobná paralelní funkcionalita zachvíli bude k dispozici přes NFS tak se máme na co těšit.
Mimochodem před těmi asi třemi lety běžely jednotlivé Storage Nodes na FreeBSD. Zajímalo by mě jestli se ho pořád drží, nebo jestli už přešli na Linux.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz