Rendszerprogramozás

Gyakran hallunk, tanulunk, sőt használunk olyan kifejezéseket vagy kifejezéseket, amelyeket nem teljesen értünk. Szerintem ez elég gyakori a szoftverfejlesztői közösségen belül, legyen szó RESTful webes API-król, agilis módszertanról, gépi tanulásról vagy más kifejezésekről. Ez nem feltétlenül rossz dolog, de fontos megérteni, hogy mikor ismerünk valamit igazán, és mikor csak a nevét tudjuk.

Számomra a rendszerprogramozás egy ilyen kifejezés. Szeretném megpróbálni egyszerű nyelven elmagyarázni, hogy mit is jelent ez.

Mielőtt megértenénk, hogy mit jelent a Rendszerprogramozás, először is meg kell értenünk, hogy mi az a Rendszer. A szoftverek általában két táborba sorolhatók, a rendszerszoftverek és az alkalmazásszoftverek közé.

A rendszerszoftverek olyan számítógépes szoftverek, amelyeket arra terveztek, hogy platformot biztosítsanak más szoftverek számára. A rendszerszoftverek közé tartoznak például az operációs rendszerek, a számítástudományi szoftverek, a játékmotorok, az ipari automatizálás és a szoftver mint szolgáltatás alkalmazások.
… Az ilyen szoftver nem tekinthető rendszerszoftvernek, ha általában eltávolítható anélkül, hogy más szoftverek működését befolyásolná.
– wikipedia.org

A rendszerszoftver az operációs rendszer (OS) programjaiból és szolgáltatásaiból álló platform, beleértve a beállításokat és preferenciákat, a fájlkönyvtárakat és a rendszeralkalmazásokhoz használt funkciókat. A rendszerszoftverek közé tartoznak az alapvető számítógépes hardvereket és perifériákat működtető eszközillesztők is.
– techopedia.com

A rendszerszoftver a számítógép operációs rendszerét alkotó fájlokra és programokra utal. A rendszerfájlok közé tartoznak a funkciókönyvtárak, a rendszerszolgáltatások, a nyomtatók és egyéb hardverek illesztőprogramjai, a rendszerbeállítások és egyéb konfigurációs fájlok. A rendszerszoftver részét képező programok közé tartoznak az assemblerek, a fordítóprogramok, a fájlkezelő eszközök, a rendszer segédprogramok és a hibakeresők.
– techterms.com

A Wikipedia definíciója nagyon homályos azzal kapcsolatban, hogy mi számít rendszerszoftvernek, amennyiben az szolgáltatásokat nyújt más alkalmazások számára. A másik két definíció azonban tisztán az operációs rendszerre koncentrál – meghajtók, kernelek, könyvtárak és funkciók (gondoljunk a kernel/libc fejlécfájlokra és megosztott objektumokra). Ez szoros kapcsolatot feltételez a hardverrel. Ha megnézzük a Wikipédia egy másik, a rendszerprogramozásról szóló cikkét, akkor azt látjuk:

A rendszerprogramozás nagyfokú hardverismeretet igényel.

A cikk arra utal, hogy a rendszerprogramozás alapvető része az, hogy a dolgoknak nagyon gyorsnak kell lenniük. Ez érthetővé teszi, hogy miért kell sokat tudnunk a hardverről. Az is logikus, hogy a sebesség (teljesítmény) a rendszerprogramozás központi része lenne, ha az egy platform más szoftverek számára.

Ha az alkalmazás legközpontibb része (a rendszerszoftver “platformja”) lassú, akkor az egész alkalmazás lassú. Sok alkalmazás esetében, különösen a méretarányos alkalmazásoknál, ez egy “deal-breaker” lenne.

Szisztémaszoftver dióhéjban

A fenti idézetek és más források alapján a következő kritériumokra jutottam a rendszerszoftver meghatározásához:

• Platformot biztosít más szoftverek számára, amelyekre építeni lehet.
• Közvetlenül vagy szorosan kapcsolódik a számítógép hardveréhez a szükséges teljesítmény elérése és az absztrakciók felfedése érdekében (a platform részeként).

Mi az és mi nem rendszerszoftver

Példák arra, hogy mi a rendszerszoftver:

• OS Kernel
• Driverek
• Bare Metal Hypervisor (pl.g. Hyper-V és VM Ware ESXi)
• Compilerek (amelyek natív binárisokat állítanak elő) és hibakeresők

Példák arra, hogy mi nem rendszerszoftver:

• GUI Chat alkalmazás (Slack, Discord, stb.)
• Web alapú JavaScript alkalmazás
• Web Service API

Megfigyelhető, hogy míg a Web Service API-k szolgáltatást nyújtanak más szoftverek számára, nem lépnek (jellemzően) kapcsolatba a hardverrel, hogy absztrakciókat tegyenek ki felette. Vannak azonban olyan alkalmazások, amelyek egy középső szürke zónába esnek. Ezek közül a nagy teljesítményű számítástechnikai alkalmazások és a beágyazott szoftverek jutnak eszembe.

A nagy teljesítményű számítástechnikai (HPC) alkalmazások, például a tőzsdei valós idejű kereskedés, jellemzően nem tesznek ki platformot, de gyakori, hogy olyan kódot írnak, amely közvetlenül kapcsolódik a hardverhez. Ilyen például a kernel által kínált hálózati verem megkerülése és a saját hálózati verem megvalósítása, amely közvetlenül az NIC(ek)-hez beszél. Ily módon láthatjuk, hogy a HPC-szoftverek sok hasonlóságot mutatnak a rendszerszoftverekkel, mivel közvetlenül a hardverrel lépnek kölcsönhatásba a szükséges teljesítménynövekedés biztosítása érdekében.

A beágyazott szoftverfejlesztés szintén sok hasonlóságot mutat a rendszerszoftverekkel, mivel a kódot úgy írják, hogy közvetlenül a hardverrel lépjen kapcsolatba. Azonban a biztosított absztrakciókat jellemzően ugyanaz a szoftver fogyasztja, és nem tekinthető platformnak.

Nagyon fontos megemlíteni azokat az alkalmazásokat, amelyek hasonlóságot mutatnak a rendszerszoftver definíciójával, mivel valószínűleg látni fogjuk, hogy ezeket az alkalmazásokat/munkaköröket ilyen kifejezésekkel írják le (rendszerszoftver, rendszermérnökök stb.)

Rendszerprogramozás (+ Nyelvek)

A rendszereket definiálva, most már a rendszerprogramozást mint a rendszerprogramozási nyelvek segítségével történő rendszerszoftver-építést határozhatjuk meg. Elég egyszerű, nem?

Hát egy dolgot kihagytunk, a nyelveket. Az emberek gyakran úgy beszélnek a rendszerprogramozási nyelvekről, hogy “X nagyszerű, gyors, fordítható és rendszerprogramozási nyelv”. De vajon mindenki ugyanazon az oldalon áll abban, hogy mi is az a rendszerprogramozási nyelv?

A rendszerekre vonatkozó definíciónk alapján én a rendszerprogramozási nyelv kritériumait a következőképpen határoznám meg:

• Natív binárisra fordítva
• Más szoftverektől való függés nélkül építhető (beleértve a kernelt is)
• Más rendszerprogramozási nyelvekhez hasonló teljesítményjellemzők

Disclaimer: Ez az én definícióm. Mivel nincsenek meghatározott kritériumok, a definíciót abból vezetem le, aminek számomra van értelme, tekintettel arra a kontextusra, amelyben a rendszerszoftvereket definiáltam.

Compile to Native Binary

Ha egy nyelv nem tud a CPU által közvetlenül értelmezhető futtatható állományba fordítani, akkor definíció szerint egy platformon fut (pl. JVM, Ruby VM, Python VM, stb.). Lehetnek itt érvek, de az egyszerűség kedvéért úgy gondolom, hogy ez egy megfelelő kritérium.

No Dependencies

Az érv hasonló a natív binárisra való fordításhoz. Ha a nyelv mindig megköveteli valamilyen más szoftver jelenlétét a futtatáshoz, akkor egy platformon fut. Erre példa a Go és a benne lévő szabványos könyvtár. Az operációs rendszer támogatását igényli az olyan alapvető műveletek elvégzéséhez, mint a memória kiosztása, a szálak létrehozása (a goroutine-ok futásához), a beépített hálózati poller és egyéb műveletek. Bár ezeket az alapvető funkciókat újra lehet implementálni, ez akadályozza a használatot ebben a kontextusban, és könnyen elképzelhető, hogy miért nem minden nyelvet, még azokat sem, amelyek statikus bináris állományokká fordíthatók, rendszerprogramozási nyelvnek szánnak.

Hasonló teljesítményjellemzők

Ez egy kicsit megkerülhetetlen. Azt akarja azonban mondani, hogy a tipikusan rendszerprogramozási nyelveknek minősülő nyelvek rendszerén belül nem lehetnek nagy (nagyságrendi) különbségek a teljesítményjellemzőkben. A jellemzők alatt kifejezetten a végrehajtási sebességre és a memóriahatékonyságra gondolok.

Az összehasonlítás arany mércéje a C és/vagy a C++, ahogyan azt az összehasonlító benchmarkok gyakran képviselik, amelyek a végrehajtási sebességet abban mérik, hogy a nyelvek hány nagyságrenddel lassabbak, mint a C/C++.

Naming a few

A nyelvek, amelyek a fenti meghatározás alapján azonnal eszünkbe jutnak, a C és a C++. De vannak olyan újabb nyelvek is, mint a Rust és a Nim, amelyek szintén betöltik ezt a rést. Sőt, már létezik egy teljes egészében Rust nyelven írt operációs rendszer (RedoxOS) és egy Nim nyelven írt kernel (nimkernel).

Beszéljünk a Go nyelvről

Már korábban utaltam arra, hogy a Go talán nem tartozik a “rendszerprogramozási nyelvek” családjába. Azonban, ahogyan nem minden alkalmazás fér el szépen az alkalmazásszoftverek és a rendszerszoftverek között, úgy a nyelvek sem.

Gyakran nevezik a Go-t rendszerprogramozási nyelvnek, és még a golang.org is idézi:

A Go egy általános célú nyelv, amelyet a rendszerprogramozás szem előtt tartásával terveztek.

Még ez sem jelenti azonban egyenesen azt, hogy a Go egy rendszerprogramozási nyelv, csupán azt, hogy ennek szem előtt tartásával tervezték. Szerintem inkább középen helyezkedik el.

Míg a Go natív binárisokba fordítható, hasznos alacsony szintű koncepciókat tartalmaz (nyers/nem biztonságos mutatók, natív típusok, mint a bytes és int32, és inline assembly támogatás), és viszonylag hatékony; még mindig van néhány kihívás, amit le kell küzdenie. A Go egy futásidővel és egy szemétgyűjtővel érkezik.

A futásidő azt jelenti, hogy a futásidő bootstrapping/felülbírálása szükséges a kernel nélküli környezetekben való futtatáshoz. Ez jobban belemegy a nyelv belső implementációjába, ami a jövőbeli kiadásokban változhat. A változások további bootstrapping munkát igényelnek, ahogy a nyelv fejlődik.

A szemétgyűjtő (GC) vagy azt jelenti, hogy a Go korlátozottan használható alkalmazási területeken, vagy azt, hogy a GC-t ki kell kapcsolni és kézi memóriakezeléssel kell helyettesíteni. Abban az esetben, ha a GC nem helyettesíthető, a valós idejű tartomány (amelyet olyan műveletek határoznak meg, amelyeknek adott időkorlátokon belül kell befejeződniük és/vagy a teljesítményt nanoszekundumokban mérik) nem kockáztatná meg a GC nemdeterminisztikus szünetidejét.

Disztributed Systems Software

Az elosztott rendszerekről szóló egyre több szó esik, és az olyan alkalmazások, mint a Kubernetes, nagyon népszerűvé válnak, egy csomó új szókincset hallunk, amelyet (ha őszinték akarunk lenni) a legtöbbünk nem teljesen ért.

Edig a pontig a rendszerprogramozás és a rendszermérnökök kifejezéseket olyan kontextusokban láttam használni, ahol valójában elosztott rendszerprogramozást és elosztott rendszermérnököket értettek.

Ebben a bejegyzésben definiáltuk a rendszerszoftvereket, a rendszernyelveket és a rendszerprogramozást. Amikor azonban elosztott rendszerekről beszélünk, a rendszer jelentése megváltozik. És bár itt nem fogok belemerülni a konkrét különbségekbe (főleg azért, mert magamnak még jobban meg kell értenem őket), fontos, hogy megtegyük ezeket a mentális megkülönböztetéseket, és pontosabb beszédmódot használjunk, amikor csak lehet, hogy elkerüljük a zavart azok számára, akik még tanulják ezt a teret.