Az open source projekteket két nagyon különböző részre lehet bontani.

Vannak a populáris projektek
(MPlayer, Linux kernel, GCC, OpenOffice.org, Mozilla, MySQL, GNOME, KDE, Apache, PHP, ...).
A freshmeat.net-en levő statisztikák nagyon jól eligazítanak abban, hogy melyik projektek tartoznak ide.

A nagy felhasználói táborral rendelkező projektek igazi
bazár fejlesztések.
Ezen projektek közös jellemzője, hogy rendkívül különböző igényekkel rendelkező felhasználók használják, és a saját dolgaikat ezekkel akarják megoldani. Sokan tisztítják a kódot. Jelentős innovációk kerülnek bele.Akár olyanok is amiket a zárt forráskódú konkurenciák lehetetlennek tartottak (masqureding, modulos kernel, de szerintem Árpiéknak is van ilyen listájuk :-), ...). Ezeket a kódokat rengetegen nézik át, sok egyetemista tanulja meg ezeken keresztül a programozás szépségeit.
Sokan gondolják (helyesen) úgy, hogy a legegyszerűbb módja a programozóként való "befutásuknak", hogy egy ilyen projekt lényeges részébe kell innovatív újítást beleprogramozniuk. Egy ilyen tett hosszú távra megalapozza az illető jövőjét. A (kezdő) fizetésén is látszani fog. Meg a későbbi elismertségén. Az emberek hajlamosak a kategorizálásra: ő egy ilyen képességű programozó. Ha kezdőként rögtön magas kategóriában kezd, az nagyon nem ugyanaz, mintha a "kávé készítést" gondolnák a szellemi képességeinek megfelelő feladatnak. Kicsit kisarkítottam, de a lényeg ez.

Az ezen projektekre épülő szupporthoz/egyedi fejlesztésekhez sok profi programozót lehet felvenni. Az ilyen projektekre való támaszkodás hosszú távú biztonságot nyújt. Biztos, hogy fejlődni fog a projekt. Biztos, hogy abba az irányba amerre a felhasználók akarják. Akik pont olyan dolgokat akarnak, mint te.

Ezekkel a projektekkel való nem open source konkurálás szerintem életveszélyes. Nem hiszem, hogy épeszű cégvezető egy 30 platformos C fordító kifejlesztésén, és eladásában látná cége jövőjét. Fordító a GCC. Pont. Nincs vita :-) Szerintem a GCC piaci részesedését megszorítani kizárólag egy olyan open source projekttel lehetne, ami kezdetben mindenképpen jelentősen támaszkodna a GCC kódjára, valamint rögtön induláskor jelentős számú fejlesztőt/felhasználót sikerülne átcsábítania. Bár el nem tudom képzelni, hogy mivel sikerülne ez az átcsábítás.

Kevés hiba van, amit egy ilyen projekt vezetése elkövethet, egyik pl: az újraírás. A Mozillásoknak 2 évig nem volt normális verziójuk, az Mplayer G2 kiadása is csak a jövő homályába vész. Ezzel az open source fejlesztés alapelvei sérülnek.



Pl: 7. Add ki korán. Add ki gyakran. És figyelj a fogyasztóidra.


Egy ekkora fejlesztőgárda akármilyen csúnya kódot képes kitisztítani, ha az a feladat.


Erről egy jó kis cikket találtok itt.



Másrészt



Van több, mint tízszer ennyi minimális felhasználói táborral rendelkező projekt. A freshmeat.net-en találtok ilyen projektből több, mint 10000-et. Ezek a projektek nem mindig kicsik. Vannak köztük nagyok is. Nem az a jellemző rájuk, hogy nincsenek új verziók, tehát lehetnek akár vitálisak is. A fő különbség a felhasználók számában van. Amíg kevesen használják, addig a fejlesztők is kevesen vannak. Az egész projekt sokkal inkább hasonlít egy katedrális építésre, mint a valódi open source fejlesztésre.
Előnye a céges zárt projektekhez képest a nyílt forrás. De a kód már nem hasonlít egy 1. kategóriás open source projekthez. Bonyolult, nincs kitisztítva. A néhány fejlesztő a saját dolgát csinálja. Az érdeklődőknek hónapokig esélyük sincs, hogy bármi értelmet fejlesszenek bele. Túl bonyolult, nehezen átlátható. Általában kevéssé dokumentáltak. A néhány core fejlesztőnek nincs szüksége rá, ők átlátják a kódot, a többiek meg nincsenek.

Ezen projektek semmi veszélyt nem jelentenek senkire. Léteznek, mert valaki elindította őket. Ennyi. Egyetlen előnyük, hogy a kódjuk (újra)felhasználható.

A gondjuk sokszor a jó vezető hiánya. Esetleg az olyan célok megfogalmazása, ami a kutyát sem érdekli.
Egy jó vezető egy ilyen projektből is képes első kategóriás open source projektet csinálni.



Lásd ESR példáját.


Nade hol vannak további jó vezetők?



bye

Andrej



Ezen írás legfrissebb verziója a könyvtárban található.


This work is licensed under a Creative Commons License.

Az MPlayerHQ szerint újabb szoftver érintett a KiSS Technology firmware ügyben.A MPlayerHQ szerint az újabb érintett szoftver a GPL licenc alatt terjesztett MAD (libmad) névre hallgató MPEG audio kodek. Ez a szoftver számos nyílt forrású projekt része.

Bővebben a MPlayerHQ-n.

Egy új projekt van indulóban, amely azt hiszem hiánypótló szerepet tölt(ene) be a magyar szabad szoftveres közösség életében. A neve HupWiki. Hogy mi ez? Idézek a HupWiki meghatározásából:

``A HupWiki egy WikiWiki projekt, amelynek célja egy teljes és pontos nyílt tartalmú Unix/Linux/BSD/szabad szoftver lexikon elkészítése.''

A HupWiki dokumentumai a GNU GPL licence alatt lennének terjesztve (ez még változhat, javaslatok a hozzászólásba jöhetnek).

Mi az a WikiWiki?

A WikiWiki egy ``world writeable'' weboldal, amelyet bárki módosíthat, bárki hozhat létre rajta bejegyzést, azt a bejegyzést bárki szerkesztheti, és ezáltal lesz (remélhetőleg) egyre jobb az oldal.

``Egy WikiWikiWeb lehetővé teszi olyan interneten elérhető dokumentumok létrehozását, melyeket egymással közreműködő emberek tudnak létrehozni és fejleszteni egy egyszerű leíró nyelv segítségével, és ezen lapok egyszerű web-böngészővel megtekinthetőek vagy szerkeszthetőek. Mivel a legtöbb wiki web alapú, ezért a "wiki" szóval általában a "WikiWikiWeb"-ekre gondolunk. Az egyes lapok neve "wikilap", míg a teljes, kereszthivatkozásokkal teli laphalmazt "a wiki"-nek nevezzük.

A "wiki wiki" hawaii nyelven "gyorsat" jelent, és a lapok létrehozásának és javításának gyorsasága a wiki technológia egyik legfontosabb jellemzője. Általában a módosításokat nem ellenőrzi senki megjelenésük előtt, és a legtöbb wiki vagy mindenki számára nyitott, vagy pedig egy nagyobb, az adott wikiben regisztrált közösség számára. A legtöbb esetben még a regisztráció sem szükséges.'' - (meghatározás szégyenletes módon lenyúlva a Magyar Wikipediából)Az oldal kísérleti jelleggel már üzemel. Hogy miért kísérleti jelleggel?

- fel szeretném mérni, hogy van-e rá igény

- kíváncsi vagyok arra, hogy egy mindenki által szerkeszthető oldal meg tud-e maradni annak, aminek a készítői szeretnék látni

Igény biztos, hogy van rá a világon, hiszen az eredeti angol Wikipedia 2001. januárjában indult, és akkora sikere lett, hogy lassan a negyedik szervert állítják üzembe a készítői. A Magyar Wikipedia is szépen fejlődik, köszönhetően Gervai Péter (grin) és szorgos segítői munkájának.

A HupWiki csak a HUP témáit szeretné feldolgozni, azaz nem általános célú enciklopéda lenne.

Szóval, akinek van kedve próbálja ki. Bár sok tartalom még nincs a HupWiki-ben, mindenkit kérnék a kultúrált szerkesztésre!

A HupWiki a elérhető lesz a wiki.hup.hu címen.

A HupWiki-t jelenleg ITT találod. Mire vársz? Próbáld ki a homokozót. Az oldalakat lehet diff-elni, és a Friss változások oldalon nyomon lehet követni az aktivitást.

Bizonyára vannak olyanok, akik azon törik a fejüket, hogy FreeBSD-re kellene áttérni. Miért ne lennének? Ezek közül biztos, hogy van olyan felhasználó, aki desktop gépére telepítené a Daemon-t.Az Ofb.biz oldal Focus on Unix rovatában jelentek meg a Desktop FreeBSD Part 1: Installation és az Desktop FreeBSD Part 2: Initial Setup cikkek. Talán hasznosak lehetnek a telepítés során.

Mivel a SuSE nem ad ki ISO imaget a disztribúcióiról, az egyetlen megoldás a telepítésre (a dobozos termék megvásárlása mellett) az FTP szerverről történő telepítés.

Ennek a menete az, hogy le kell tölteni a kis méretű boot.iso-t (

Aki ilyet keres, talál egyet itt.

Miközben egyesek leírták a Genesi Pegasos névre hallgató stuffját, a cég folyamatosan fejleszt, és adja ki új termékeit. llyen termék a 2004. januárjában piacra kerülő OpenBSD alapú biztonsági rendszerük is.A Pegasos Guardian névre hallgató rendszer pf csomagszűrőt, IDS (behatolás-érzékelő rendszert), és biztonsági teszt programokat (Nessus, Nmap, Dsniff, Paratrace) tartalmaz a kért kiépítéstől függően. A rendszer Bronze, Silver, Gold, Platinum és Platium+ kiépítésekben vásárolható meg. Az egyes kategóriák szoftveres kialakítása nagyban eltér egymástól.

A Pegasos Guardianról bővebben itt olvashatsz.

A termékről képeket (Infosecurity 2003) itt találsz.

Bán Szabolcs (Shooby) sikeresen lebuildelte a magyar OpenOffice.org-ot Max OS X 10.3 alá.
A build tartalmazza a hunspell 0.9.7-es helysírás-ellenőrzőt. A telepítőkészlet letölthető az
FSF.hu Alapítvány szerveréről.

Az MPlayer fejlesztői szerint a DVD, MPEG-4 lejátszókat gyártó KISS TECHNOLOGY GPL-t sértett. (Ez a megállapítás részükről annyira nem meglepő, hiszen a HUP már másfél hónappal ezelőtt megírta ezt).


Az MPlayer csapat szerint ha valaki egy gyors string keresést követ el a KISS firmware-én és az mplayer binárison, akkor nagyfokú egyezéseket vehet észre:KISS firmware:

$ strings KiSS_DP-508_FW2.7.4_PAL.iso | grep -A 3 -B 6 MPSub

Microdvd

Subrip

Subviewer

Sami

Vplayer

Unknown

MPSub

Subviewer 2.0

Subrip 0.9

Jacosub

MPlayer bináris:

$ strings /usr/bin/mplayer | grep -B 8 mpsub -A 4

L>microdvd

subrip

subviewer

sami

vplayer

dunnowhat

mpsub

subviewer 2.0

subrip 0.9

jacosub

Az Mplayer csapat felhívta a KISS figyelmét a dologra, de azok nem válaszoltak a levére. Az MPlayer csapat szerint nyilvánvaló a kódlopás.

Bővebben itt.

Megjelent a GPRS Easy Connect program 2.5.0-ás végleges verziója, amely már a Linux-on kívűl FreeBSD alól is futtatható.

A program immáron összesen 146 különböző mobilkészüléket támogat 176 szolgáltatónál világszerte.Újdonságok az előző verzióhoz képest:

Július óta újabb 1.000 porttal gyarapodott a FreeBSD Ports Collection. A FreshPorts szerint 10.023 port található a FreeBSD port gyűjteményében. Ebből mindössze 63 broken (valamilyen hiba miatt nem használható, és 4 forbidden (tiltott).

Ez a grafikon jól jellemzi FreeBSD portok gyarapodását.

Szép munka!

A PaX Team-nek köszönhetően elérhető egy kísérleti PaX biztonsági patch a 2.6-os (2.6.0) Linux kernelhez. A patch a 2.4.23-as kernelhez készült folt előre portolt verziója, amely jelenleg i386 platformon működik biztosan, a többi platformon valószínűleg le sem fordul.

A PaX patch használatával számos puffer túlcsordulásra építő támadásnak állhat ellen rendszerünk. Kipróbáltam a patchet a stabil 2.6.0-ás kernelen.



A tapasztalatok:A kernel simán lefordult, az összes PaX opciót engedélyeztem a ``menuconfig''-ban. Bebootolva a kernelt a fixen belefordított hálózati kártya inicializálása előtt kaptam egy ``general protection fault''-ot, de a kernel felállt, és elindította a rendszert. Lefuttattam a paxtest-0.9.5 tesztet. Eredménye:

Executable anonymous mapping : Killed

Executable bss : Killed

Executable data : Killed

Executable heap : Killed

Executable stack : Killed

Executable anonymous mapping (mprotect) : Killed

Executable bss (mprotect) : Killed

Executable data (mprotect) : Killed

Executable heap (mprotect) : Killed

Executable shared library bss (mprotect) : Killed

Executable shared library data (mprotect): Killed

Executable stack (mprotect) : Killed

Anonymous mapping randomisation test : 16 bits (guessed)

Heap randomisation test (ET_EXEC) : 13 bits (guessed)

Heap randomisation test (ET_DYN) : 25 bits (guessed)

Main executable randomisation (ET_EXEC) : 16 bits (guessed)

Main executable randomisation (ET_DYN) : 17 bits (guessed)

Shared library randomisation test : 16 bits (guessed)

Stack randomisation test (SEGMEXEC) : 23 bits (guessed)

Stack randomisation test (PAGEEXEC) : 24 bits (guessed)

Return to function (strcpy) : Vulnerable

Return to function (strcpy, RANDEXEC) : Return to function (memcpy) : Vulnerable

Return to function (memcpy, RANDEXEC) : Killed

Executable shared library bss : Killed

Executable shared library data : Killed

Writable text segments : Killed

A patch a kezdeti ``GPF''-től eltekintve nem okozott semmilyen negatív változást a kernelben (eddig). A PaX alkalmazása után néhány alkalmazás nem fut. Erről a kernel menuconfig help-je tájékozatat is minket. A legemlítésreméltóbb programok, amelyek nem indulnak el: az Xfree86 4.x verziója, a Java viruális gép és a Wine. A patch szerintem nem is desktop gépeken kap nagyobb hangsúlyt, hanem szerveren, ahol esetleg több rosszindulatú helyi felhasználóval kell számolnunk. A patchelt kernellel futott a MySQL 4.x, az Apache legújabb verziója, működött a PHP-ra írt weboldal, ment a postfix, és az amavisd-new is. Mindez Debian Sarge operációs rendszeren. Hosszabb távú tapasztalatok nincsenek, hiszen a patch 3 napja jelent meg. Tervezem egy teszt szerver felállítását, amely lokális hálón nagy terhelésnek van kitéve.

A szerver üzemeltetés szempontjából érdekes lehet még az, hogy mekkora a ``overhead''-je (overhead ebben az esetben = a patch működéséből adódó lassulás) van a patchnek. A dokumentáció szerint i386 és ppc környezetben számolnunk kell az ``overhead''-del. Erre vonatkozólag még nem végeztem méréseket. Az alpha, ia64, parisc, sparc, sparc64 és x86_64 platformokon nem kell overhead-del számolnunk.

A patch tesztelésre letölthető:

http://pax.grsecurity.net/pax-linux-2.6.0-200312302245.patch

A PaX mögött álló elgondolásról bővebben itt olvashatsz. A patchelt kernel teszteléséhez használható a paxtest-0.9.5 tesztprogram. A patchelt kernelen file alapon tudjuk a PaX jelzőket állítani. Ehhez a chpax programra van szükségünk.

Jó szórakozást!

A Lindows.com tegnap bejelentette, hogy hivatalosan is támogatja a Namesys következő generációs ReiserFS filerendszerét, a Reiser4-et. Ez nem meglepő hiszen Michael Robertson a Lindows.com CEO-ja korábban annak az MP3.com-nak volt a vezetője, aki a fő szponzora volt a ReiserFS fejlesztéseinek.

A Lindows.com bejelentette, hogy 2004 elején beépíti a Reiser4-et a LindowsOS operációs rendszerébe. A LindowsOS jelenleg a ReiserFS v3-at használja alapértelmezett filerendszerként. Nem ők az egyetlenek, akik a ReiserFS-t használják. Mellettük a SuSE és a Gentoo is alapértelmezett fs-ként használja a Reiser v3-at.

Mi is a Reiser4?A Reiser4 egy teljesen újraírt verziója a korábbi ReiserFS-nek. A készítők szerint számos olyan fejlett technológiát alkalmaztak a megalkotásakor, amely megakadályozza a filerendszer sérülését, lehetővé teszi a fileok kisebb helyen való tárolását, és emellett kiváló sebességet ad. A Lindows.com sajtóbejelentése szerint jelenleg a ReiserFS a leggyorsabb filerendszer, de a Reiser4 még ennél is 2-5-ször gyorsabb lesz (néhány benchmark itt). Ez köszönhető azoknak az új algoritmusokak, amelyet a Reiser4-ben alkalmaznak. A Reiser4 az adatbázisaiban az ún. ``táncoló fák'' (dancing trees) algoritmust alkalmazza a ``kiegyensúlyozott fa'' (balanced tree) algoritmus helyett. A fejlesztők szerint ez emeli sebességben a Reiser4-et a többi filerendszer fölé. A Reiser4 érdekessége, hogy van magyar vonatkozása is. Hans Reiser - a ReiserFS atyja - nem olyan régen járt Budapesten, hogy egy magyar szakemberrel vitassák meg a Reiser4 algoritmusait. A szakember Földiák Péter, akivel Reiser a filerendszerek szemantikájáról beszélgetett.

Lassan 2 éve csak ReiserFS-t használok a munkaállomásaimon és a mobil gépeimen, így érthető, hogy érdeklődve várom a Reiser4 megjelenését (augusztusi Reiser4 tesztjeim). A Reiser4 honlapja szerint a Reiser4 tesztelése a végső stádiumba érkezett, és hamarosan megjelenik. Kiváncsian várom!

A Lindows.com sajtóbejelentése a Reiser4 támogatásáról itt.

Mint az a hivatalos OpenBSD FAQ-ban olvasható, az OpenBSD jelenleg nem tud bootolni 8GB-nál nagyobb partícióról. Ennek az az oka, hogy az OpenBSD boot folyamat néhány helyen a régebbi CHS (cylinder-head-sector) olvasási metódust alkalmazza.

Ahhoz, hogy az OpenBSD-ben megszűnjön ez a korlátozás, az kell, hogy a boot folyamat alkalmazza az LBA (logical block addressing) lemez-szektor olvasási sémát. Ehhez azokat a BIOS hívásokat kell alkalmazni, amelyek a Phoenix Enhanced Disk Drive Specification (EDD) névre hallgató dokumentumban van lefektetve.

Ahhoz, hogy az OpenBSD tudjon 8GB-nál nagyobb partícióról bootolni, az alábbi alrendszereket úgy kell módosítani, hogy azok LBA-képesek legyenek:

A Mandrake Linux felhasználók nagy örömére a MandrakeSoft tegnap kiadtott egy újévi fejlesztői snapshotot. Az anyag egy 2 CD-s telepítő, amely a fejlesztők szerint egy újabb lépés 10.0-ás Mandrake Linuxhoz.Akik kipróbálják a snapshotot, azok tesztelhetik a stabil 2.6.0-ás kernelt, a KDE 3.1.94-et vagy az XFree86 4.3.99-et.

Bővebb infó itt.

Letölthető:

MandrakeLinux-20031231-CD1.i586.iso

MandrakeLinux-20031231-CD2.i586.iso

vagy Bittorrent-en keresztül.

Vigyázat nem zöldség!



Joelon is írja, és saját tapasztalatból is megerősíthetem, hogy az informatikai fejlesztéseknél, egy új ember felvétele után eltelik 6 hónap, mire az illető teljes értékű tagja lesz a fejlesztő-csapatnak.

Addig nagyon kell figyelni, milyen feladatot kap, mert nem látja át, hogy mi miért van. Tehát csak olyan feladatokat kaphat, amik pontosan definiálhatók, és a teljes kód-tömeg csak kis részének ismeretét feltételezik.6 hónap után az illetőre - képességei szerint - már homályosan definiált, akár az egész kódot érintő változtatásokat is rá lehet bízni.
Ebből az következik, hogyha egy szoftver-cég valamely termékéhez jelentős plusz fejlesztõi kapacitást akar felvenni, azt korlátozott hatékonysággal teheti meg. Már ha a 6 hónap számít. A mai világban, amikor például egy tudományos elsõségnél percek, döntenek, amikor az a cég, aki először jelenik meg az adott típusú szolgáltatással hosszú időre piac-vezető tud maradni, 6 hónap az rengeteget számít.



ELLENBEN

Az opensource fejlesztéseknél a kód nyilvános. Egyetemisták tömege élesítik rajta a körmeiket.
Ha egy cégnél úgy döntenek, hogy az adott opensource termékbe beletett új funkciókkal fogják elősegíteni a cég szolgáltatási tevékenységének expanzióját, akkor azonnal tudnak felvenni olyan embereket, akik az adott kódot tekintve régen túlestek a 6 hónapos betanulási időszakon.
A cég nyer 6 hónapot. Megnyeri az alkalmazottak 6 hónapi bérét. Az eddig nála alkalmazott szenior programozók idejéből nem rabol el rengeteget a newbie-k terelgetése. Nincsenek newbie-k. A piacon szenior programozók tömege császkál fel, s alá. A cég hihetetlen előnybe kerül, hiszen egy 6 hónappal rövidebb fejlesztési idő bőven elég lehet a sales/marketinges csapatnak, hogy a nem opensource konkurenciát jelentősen visszaszorítsa. 6 hónap rengeteg idő.



Ki kell használni.
Nagyon nem véletlen a Montavista szárnyalása. Az embedded oprendszereket fejlesztő cégek közül sokáig ő volt az egyetlen, aki profi, a kódot rendkívül jól ismerő programozókat vehetett fel.
(Pl: Robert Love-ot)


Az embedded oprendszerek piacán a harc eldőlt. A Wind River belépésével az OSDL-be nem maradt senki jelentõs szereplő, aki nem Linux kernelre építene embedded oprendszert. (M$ persze igen, de ezen a piacon teljesen minimális a részesedése)



bye
Andrej



Ezen írás legfrissebb verziója a könyvtárban található.

This work is licensed under a Creative Commons License.



------------------------------------------------------------------------



Andrej jelenleg Bali-n (Ázsia, Indonézia) él. Előtte vezető programozó és projekt vezető volt. Az eddigi munkája során is a brutális szabadságot élvezte (azonnal felmondott volna, ha például kötött munkaidőt akartak volna megkövetelni, és ezt érezték is munkaadói), de úgy gondolja, hogy ennél sokkal nagyobb szabadságra van szükség a normális élethez. A szabadság csak akkor lehet teljes/normális/jól élvezhető, ha nincs senki és semmi ami kényszeríti az embert. Hitvallása az andrejizmus.

Új év, új otthon?

Elkészült a 2.4.22-es kernelhez a legfrissebb (2003. 12. 30.) PaX-on alapuló backport.

Megtörtént az, ami mér régen érett. A XFree86 devel listára tegnap küldött levél szerint a Xfree86 Core Team nagy részének egyetértésében feloszlatták a Core Team-et.

A mai nap a kernel kiadások napja. Marcelo kiadta a 2.4.24-pre3 kernelt. Többek közt PPC32/SPARC frissítést, i2c kódtisztítást, LVM frissítést, új WAN drivert tartalmaz.

Letölthető innen.

Változások listája Marcelo levelében itt.

Alig adta ki Linus a 2.6.1-rc1 kernelt, AKPM máris postázta a 2.6.1-rc1-mm1 patchet (a listán hibásan 2.6.0-rc1-mm1-ként jelent meg). A patch néhány új funkció mellett a fő kernelfával történő szinkronizációkat tartalmazza.A patch letölthető:

ftp://ftp.kernel.org/.../akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/

Változások listája AKPM levelében itt.

Linus kiadta a 2.6.1-rc1 patchet. A foltba az eddig várólistán levő anyagok kerültek. Ahogy Linus írja, most egy újabb nyugalmas időszak kezdődik (azaz új dolgok nem kerülnek be a kernel forrásba), amíg ki nem derült, hogy a végleges 2.6.1 rendben van-e. A legtöbb új dolog már régóta jelen van Andrew Morton -mm fájában, és stabilnak tekinthető.

A patch letölthető linux-2.6.1-rc1.tar.bz2

Változások listája Linus levelében itt.

Az ATi bejelentette a 8500-as és újabb kártyáihoz a nem szabad forrású linuxos driverének legújabb verzióit. A verziószám a 3.7.0-ás.Mi az új benne?

[30 Dec 2003] DSA-405 xsok - missing privilege release

Ma Apache+mod_ssl-t frissítettem, mert néhány logban furcsa bejegyzéseket találtam. Kérések irányultak olyan fileokra, amelyek nem léteztek. Furcsa gyanúm volt, és kicsit utána néztem a dolognak. A gyanú nem volt alaptalan:

A népszerű Apache webszerver egy olyan bugot tartalmaz, amely lehetővé teszi nemkívánatos reguláris kifejezések (regex) értelmezését. A bugot kihasználva rosszindulatú támadók képesek tetszőleges kódot futtani az Apache-ot futtató felhasználó nevében. Ehhez a támadónak szüksége van olyan írható konfigurációs filera, mint például egy felhasználó public_html könyvtárában levő .htaccess file. A bug az Apache mod_alias és mod_rewrite regex értelmező kódjában található.

A hiba az összes 1.3.x Apache-ot érinti, kivéve a legújabb 1.3.29-est. Javaslom az Apache szerverek mielőbbi frissítését.

Emellett bugot találtak a mod_php Apache modul kódjában is. A hibát kihasználva bizonyos körülmények között a rosszindulató helyi felhasználó megtudja szerezni az irányítást a 443-as HTTPS port felett, és ott HTTPS szolgáltatást tud szimulálni.

A hibákról bővebben itt.

Ha már a CAD-eknél tartunk... nemrég megjelent egy hír a QCad-ről.



lignumCAD egy hasonlóan jó - és megbízható - CAD program, mint a QCad, talán egy kicsit többet kell benne gépelni... :-))