HTML

Az élet kódjai

Csináld maga. Senki nem csinálja meg helyetted.

Friss topikok

  • sdani: @Travis.CG: Nohát, nem is tudtam, hogy ilyen van... bár ahogy elnézem ezek a komponensek fizetősek... (2018.11.01. 10:14) Rossz beidegződések a bionformatikában
  • Csenge Tarnói: Ez érdekes. Most csinálok egy meta-analízist, életemben először, úgyhogy az én tudásom is felszíne... (2018.10.01. 21:39) Ez már nekem sok
  • robertherczeg: Nekem a kedvenc az volt, hogy: "Inkább eleve Mann-Whitney és/vagy Wilcoxon tesztet használjunk, m... (2018.09.04. 07:47) Ezért utálom a Wilcoxon-tesztet
  • Travis.CG: ÉÉÉÉÉs megjelent! (2018.08.24. 23:31) Nehéz szülés 2
  • Szedlák Ádám: Hogy én mennyire köszönöm ezt a posztot, arra nincs szó. A kódoljon mindenki / legyen mindenki olc... (2018.06.25. 03:37) Legyen mindenki programozó

Virtu...virtu...virtualizáció!

2016.12.16. 00:55 Travis.CG

Már nagyon ritka, hogy egy munkafolyamathoz csak egyetlen programot használunk. Sok programot, sok különböző beállítást használunk, gyakran egymással összeegyeztethetetlen konfigurációkban.

Az is problémát jelenthet, ha nincs rendszergazdai hozzáférésünk az adott rendszerhez, de programokat kell rá telepítenünk. A megoldás a virtualizáció lehet. Ebben a posztban virtualizáció alatt értem mindazokat a technológiákat, amelyek lehetővé teszik, hogy több környezetet működtessünk, de nem feltétlenül párhuzamosan.

Természetesen csinálhatunk mindent kézzel. Linux alatt a PATH, LD_LIBRARY_PATH környezeti változókkal beállíthatjuk, hogy programjaink honnan olvassák be a fájlokat. Ha Python-t használunk, a modulok helyét a PYTHONPATH változó határozza meg. R esetében is van lehetőségünk újra definiálni a csomagok helyét: R_LIBS, R_LIBS_USER, R_LIBS_SITE. Ez a megoldás nem nyújt 100% védelmet a konfigurációk ütközése ellen, de limitált hozzáférésű rendszereknél egy lehetséges megoldás. Nekem például volt olyan problémám, hogy egy számítógép klaszteren a fő gépen más konfiguráció volt, mint a munkát végző csomópontokon. Ezekkel a trükkökkel viszont felül tudtam bírálni minden beállítást.

Természetesen az egész hardvert is emulálhatjuk. Ha nincs például PPC processzoros gépünk, a hardver emulációjával elérhetjük, hogy legyen. Újgenerációs Amiga-szerü rendszereken például futtathatunk régi, Motorola processzoros alkalmazásokat (Windows alatt a WinUAE teszi ugyan ezt). De említhetném a sokak által ismert VirtualBoxot is. Ez utóbbi segítségével az intézeti Windowsos laptopra telepítettem egy Linuxot. A géphez nincs rendszergazdai hozzáférésem, mert az IT nem engedi, de a virtuális Linuxhoz van.

Az egész hardver virtualizálása több erőforrást igényel, mintha csak egy operációs rendszert futtatnánk, de szerencsére van megoldás akkor is, ha csak a kernelt akarjuk virtualizálni. A Docker például kedvelt eszköz, pont ez a célja.

Könnyen összeállíthatjuk kedvenc szoftveres környezetünket, elküldhetjük másoknak és elfelejthetjük a telepítés során fellépő hibákat, mert a rendszer garantálja, hogy a csomagunkat használva mindenki ugyan azt kapja. Még webes szolgáltatások is vannak a csomagok tárolására.

Valamivel kevésbé flexibilis ugyan és nem is ez az eredeti célja, de a Conda is tartalmaz virtuális környezetek kezelésére parancsokat. A Conda igazi célja a csomagok egyszerű telepítése és frissítése, de a

conda create -n env
source activate env

létrehoz egy env nevű környezetet. Minden további parancs erre a környezetre fog vonatkozni. A Conda egyébként tartalmaz egy tisztán bioinformatikai csatornát biconda néven.

Szólj hozzá!

Címkék: amiga rendszergazda

A bejegyzés trackback címe:

https://cybernetic.blog.hu/api/trackback/id/tr7811969721

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.