Linux

A Linux kernel stack egy nagyon véges erőforrás, el kell férnie két memória oldalban (2 memory page - 8KB). A kernel stack túlcsordítása nem nehéz feladat, sajnos sok programozó nem fordít elegendő figyelmet a stack ellenőrzésre. A stack túlcsorulása katasztrófális hatással lehet rendszerre nézve.Andries Brouwer elgondolkozott a problémán, és a symlinkek feloldásának oldaláról közelítette meg a kérdést. A symlinkek feloldásának során (symbolic link resolution - az a folyamat, amely során a rendszer végighalad a szimbolikus link által mutatott úton) a kernel találkozhat egy újabb symlikkel, amely egy újabb symlinkre mutat stb., ezeket fel kell oldania. Ehhez a kernelnek egy rekurzív híváshoz kell folyamodnia, amelyet a symlink feloldó kód tartalmaz. Természetesen minden hívás helyet igényel a kernel stackben, így a rekurzív hívást fokozott figyelemmel kell kísérni, mert különben egy bizonyos számú symlink feloldás azzal járhat, hogy a kernel stack elfogy, vagyis a kernel stack túlcsordul (overflow). Hogy ez ne történhessen meg, a symlink kód egy konstansban szabályozza az egymás után feloldható symlinkek számát, amelyet 5 darabban határoztak meg.

Az LKML-re postázta Molnár Ingó a legújabb O(1) scheduler munkáját (A4). Ez egy merge a 2.5-currentből. A patch a 2.4.19-pre10-ac2 ellen készült.

[patch] 2.4.19-pre10-ac2: O(1) scheduler merge, -A4.

Nem tudom, ki mennyire szokta tesztelni a 2.5.x kernelszériát. Én rendszeresen nyomon követem a fejlesztéseket, és több-kevesebb sikerrel le is tudom fordítani a fejlesztői kerneleket. Számos érdekes újítás, új funkció található benne. Egyetlen olyan dolog volt eddig, ami miatt nem nagyon tudtam mélyebben tesztelni. Nem tudtam működésre bírni az nVIDIA féle bináris drivert. Többen is foglalkozhattak ezzel a problémával, mert megszületett a patch. Mostantól az NVIDIA_kernel-1.0-2960 driver működik a 2.5.24-es fejlesztői kernellel.Andre Bonin (kernel@bonin.ca) talált egy patchet, kicsit átgyúrta és a végső formájában alkalmas arra, hogy a 2.5.24-es fejlesztői kernelbe benyomja az nVIDIA drivert.

Rik van Riel reverse-mapping virtual memory implementációja (RMAP) fejlesztés alatt áll több hónapja. Többször is írtam már róla, mégpedig azért, mert a kernel fejlesztők közül sokan állítják, hogy jobb mint a jelenlegi kernel VM implementáció (Andrea Arcangeli féle). Jelenleg az RMAP csak a 2.4-es kernelhez érhető el, így nehéz lenne megmondani, hogy a fejlesztés alatt álló kernelben milyen teljesítményt mutatna.Ezen a helyzeten próbál meg változtatni Craig Kulesa, akik egy RMAP porton dolgozik. Célja, hogy az RMAP elérhető legyen a 2.5-ös kernelt használók számára is. Két formában postázta az eddigi munkáját: egy teljes port, amely számos változtatást tartalmaz, és egy minimális verziót, amely csak a reverse mapping kódot tartalmazza. Craig előzetes mérései szerint tiszteletteljes teljesítmény-növekedést érhetünk el ha a 2.5.23-as kernelben alkalmazzuk az RMAP kódot.

Néhány levélből számomra az következik, hogy nem mindenki van tisztában a Linux kernel verziójának jelentésével. Az ezen a héten megjelent Kernel Traffic egyik cikke is erről szól. Lássuk:

A kernel listán John L. Males az alábbiakat kérdezte:

1. Van valamilyen specifikáció amely meghatározza azt, hogy milyen hosszú lehet az "EXTRAVERSION" string a Linux kernelben?

2. Képes a kernel make/build folyamat valahogy szabályozni a meghatározott limitet?

Keith Owens az alábbiakat írta:

A $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) stringnek a teljes hossza nem haladhatja meg a 64 karaktert. Amennyiben mégis túllépi ezt, akkor az ``uname -r" értelmetlen dolgot ad vissza. A kernel verzió egy 2.4.17-rmap12e esetén az alábbiakból áll össze:

VERSION = 2

PATCHLEVEL = 4

SUBLEVEL = 17

EXTRAVERSION = -rmap12e

amelyből a kernel verziója (uname -r) az alábbiakban áll össze:

KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)

$(EXTRAVERSION)

(lásd: /usr/src/linux/Makefile)A 2-es kérdésre válaszolva: A kbuild 2.5 szabályozza a limitet, viszont a jelenlegi kernel build kód nem. Owens többször küldött patchet ez ügyben Linusnak (még a 2.4.15 kernel idején), de ő nem foglalkozott vele. Szerinte Linus nem törődik a kernel build problémákkal. Owens előásta a patchet, és elküldte Tosattinak, hogy a 2.4-be bekerüljön. Cox válaszolt a levélre:

"Kérlek küldj el belőle egy másolatot, és mergelem az -ac-be, ha Marcelo elvesztette vagy nem akar vele foglalkozni a 2.4.19 final előtt.

A Star Wars, Episode II: Attack of the Clones, ami 2002. májusában jelent meg, az Industrial Light & Magic (ILM) által ``gyártott" effektekkel volt tele. Ez nem újdonság, hiszen az ILM rengeteg filmhez adott már ilyen jellegű munkát. Az ILM 1975-ben alakult, hogy az akkor megjelenő Star Wars trükk munkálatait végezze el. Az ILM közreműködött olyan filmekben mint a Forrest Gump, Jurassic Park, Terminator 2, E.T., stb. és ezzel 14 Oscar díjat nyert.

(képek a folytatásban)A LinuxJournal-on egy hosszú cikk jelent meg arról, hogy az ILM Linuxot használ az animációs munkákra. Tényleg jól néz ki, ahogy Yoda mester egy GNOME desktopon kel életre.

"A Linux a munkánk minőségét növeli, nem annak időtartamát." - mondja Andy Hendrickson a kutatási és fejlesztési igazgató.

Köztudott dolog, hogy az ILM a filmeffektusokat egy SGI (Silicon Graphics) renderfarmon készítette eddig. Most azonban úgy gondolják, hogy eljött az idő, hogy a Irix-SGI párost részben vagy teljesen kiváltsák Linuxot futtató gépekkel.

Az ILM 3D részecske-szimulációs effektjei az Alias|Wavefront Maya programmal készülnek. Az ILM dolgozói jó tapasztalatokkal rendelkeznek a Linuxszal kapcsolatban: "Amint mondtam a Maya felhasználóink 90% Linuxot használ.", "Nagyon stabilnak látszik a Linux, egy hónapja nem halt le a Maya nálam.." - ehhez hasonló nyilatkozatokat tettek az ILM dolgozói.

És akkor egy-két szebb kép:

A teljes cikket elolvashatod itt.

Szép csendben megjelent a Slackware 8.1 harmadik release candidate kiadása.

Változások logja: ChangeLog.txt

Ez de mennyire kellett már. Aki komolyabb fejlesztéssel, 3D modellezéssel foglalkozik, annak nagy valószínűséggel nem ismeretlen a Pro/Engineer szoftver. A szoftvert a mechanikus alkatrészek tervezésénél használják (mechanical computer aided design (MCAD), például az autógyártás, motor-tervezés területén. Itt Győrben nem egy vállalatról tudom, hogy használják a Pro/Engineer-t.Tegnap a PTC bejelentette, hogy kiadja a nagy sikerű szoftver Linuxos változatát. A kiadásnál a PTC preferált partnere a HP lesz. Mivel Linux platformra nem nagyon létezett komolyabb CAD alkalmazás, talán a PTC Pro/Engineer szoftvere lehet az űttörő, és sorban jelenhetnek meg a későbbiekben olyan népszerű CAD szoftverek, mint a Windows platformon széles körben használt AutoCAD termékcsalád.

A PTC bejelentését itt.

A LinuxSecurity.com bejelentése szerint a EnGarde Secure Linux nyerte a Network Computing Editor's Choice díját, amellyel megnyerte a Biztonságos Linux Disztribúciók küzdelmét.A vizsgálatok szerint az EnGarde Secure Linux minden szempontnak tökéletesen megfelelt. Kezdve a alacsonyszintű-mechanizmusoktól (bináris integritás-ellenőrzés és verem (stack) védelem) egészen a magasszintű-felhasználás során felmerülő problémák megoldásáig (pl. kiváló patch interfész) bizonyította, hogy a fejlesztői csapat kiváló munkát végzett.

A terjesztés jól állta a különböző aljas vizsgálatokat, minden fajta gond nélkül állt ellen pl. a ptrace bugnak, stb.

A készítők figyelmeztetnek:

"A EnGarde Secure Linux nem tartalmazza a newgrp programot, és nem tartalmaz semmilyen más setuid/setgid-es végrehajtható állományt, amelyek hibái kihasználhatók lennének. Ezért a EnGarde Secure Linux nem érzékeny a ptrace bugra."

A terjesztés olyan disztribúciókat előzött meg, mint: Wirex Communications Immunix 7.0, Hewlett-Packard Co. Secure OS Software for Linux 1.0, Trustix Secure Linux 1.5.

Nem rossz eredmény.

Linus kiadta a fejlesztői kernel legújabb verzióját.