Linux-ra cserélte a VxWorks-öt az Alcatel-Lucent az új vállalati switch-ében

Linux

Az Alcatel-Lucent AOS (Alcatel-Lucent Operating System) névre hallgató operációs rendszere eddig VxWorks-alapú volt. A vállalat 2009-ben döntött úgy, hogy VxWorks-ről beágyazott Linux-ra vált. Akkor azt nyilatkozták, hogy a VxWorks elavult, nem sok mozgás van körülötte és a csomagjai sem éppen a legjobbak. Akkor a vállalat azt ígérte, hogy az első linuxos switche 2010-ben érkezik. Így is lett.

Az OmniSwitch 10K névre hallgató vállalati platformjában dolgozó AOS 7 operációs rendszer már Linux-ra épül. Az OmniSwitch 10K 256 darab 10GbE portig tud skálázódni. Steve Melahn, az OmniSwitch 10K-ért felelős termékigazgató elmondta, hogy a készülékben alkalmazott saját Linux disztribúció a kernel.org-os mainline kernelre épül. A vezető szerint több oka is volt annak, hogy VxWorks-ről Linux-ra váltottak. Az okok közt említette a Linux-szal javult a memóriavédelem és a modularitás, de szerepet játszottak a váltásban olyan üzleti döntések is, amelyek a licenceléssel függenek össze.

A részletek itt.

( Zahy v | 2010. 10. 17., v – 11:06 )

Magyarul: ha 5 centtel olcsobban adjuk az eddigi verzional ellenben nem fizetunk 10 centet a VxWorks-ert, akkor az nekunk jobb uzlet. (Ha raadasul nem is adjuk 5 centtel olcsobban, hisz ez egy sokkal ujabb verzio - tehat tobbet er az eddiginel 5 centtel, akkor meg jobb nekunk.) A tobbi kb maszlag.

Ha eközben a minőség nem csökken, (hiszen csökkenő minőség csökkenő eladást jelentene ami borítaná a képletet), akkor ez egy minden szempontból jó döntés volt nem?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Ha viszont abból indulunk ki, hogy a VxWorks kernel ARINC-653 minősítésű, tehát repülőgép fedélzeti irányítórendszert lehet alapozni rá, valamint több űrszonda is ezzel működik 5+ éve a Mars felszínén, számos különféle meghibásodást túlélve, akkor kicsit más a helyzet.

Arról nem a VxWorks tehet, hogy a Linksys ezt is képes volt elcseszni.
---
Internet Memetikai Tanszék

De (nem) csak azért, mert oly' jó volt, hanem így elég volt fele akkora RAM és NAND is. És a VxWorks licence kisebb összeg volt, mint amit a HW-en spóroltak.
Én pl. 705K-nál kisebb (2.6-os) kernelt még nem tudtam összedobni, és abban már nem volt IP stack sem. Szóval 2M RAM-ban jól futó cuccot Linux-szal összerakni igen necces.

( asm v | 2010. 10. 17., v – 13:25 )

Csak hat igy ki kell adniuk a kernelhez irodott modositasok forrasat...

( Replaced | 2010. 10. 17., v – 13:49 )

nem sok mozgas? LOL
pont ez a lenyeg a vxworks-ben, hogy stabil es jol kiprobalt rendszer

--
NetBSD - Simplicity is prerequisite for reliability

Gondolom rohadt sokba kerül újratanúsíttatni a módosításokat. Még akkor is, ha bugfix.

Az Esterelről hallottam olyan adatot, hogy a DO178B szabványnak megfelelő kódgenerátorukat csak vezérigazgatói engedéllyel lehet módosítani, mert ~10 mérnökévnyi munka utána a verifikáció, hogy újra meglegyen a tanúsítvány.

Hát ilyen a másik véglet a Linux fejlesztési modelljéhez képest.
---
Internet Memetikai Tanszék

De igen végsősoron arra való. A probléma ott kezdődik, hogy hogyan specifikálod a "helyes" működést. Nyilván nem tudsz minden részletre kiterjedő specifikációt adni (legalábbis csak nagyon egyszerű feladatnál van rá esély), verifikálni viszont csak a specifikációnak megfelelőséget lehet. Vannak bizonyos szabványok, amik különféle biztonságkritikus rendszerekben való használhatóságnak előfeltételeit rögzítik. Legközismertebb példa: ha egy OS kernel elvileg képes valamilyen módon deadlockba kerülni, akkor biztosan nem felel meg.
Viszont tekinthető bugnak az is, ha a rendszerhívási API-ban valami nem úgy működik, ahogy az logikusan elvárható lenne (a specifikációban nincs kellően pontosan rögzítve, hogy hogyan is kéne működnie), nem fagy le a rendszer tőle, nem befolyásolja a kernel többi részét, más folyamatokat, de maga a hívás nem azt csinálja, amit kéne. Emiatt csak valami workarounddal lehet megoldani a feladatot. Ettől még az adott OS megszerezheti a DO178B, ARINC653, vagy MISRA vagy tudomisén milyen egyéb szervezetek előírásainak való megfelelőséget, mert teljesíti azt, amit ezek a szabványok előírnak, a bug ezeket az előírások nem veszélyezteti. Nyilván akkor, ha repülőgépre akarja valaki telepíteni, akkor nemcsak az OS-t, hanem a rajta futó alkalmazásokat és a futtató hardvert is egyben, integráltan kell vizsgálni, itt érdekesek lehetnek az eddig le nem fedett bugok is. Ha az alkalmazásfejlesztő workaroundolja az OS API őt érintő bugjait, akkor megszerezhető minősítés.
---
Internet Memetikai Tanszék