Mint már korábban arról szó volt egy másik oldalon, befejeződik az Alpha processzorok gyártása. Ezzel összefüggésben a HP úgy döntött, hogy OpenVMS rendszerét az Itaniumra portolja (bővebben itt).A fentiek még önmagukban nem "túl nagy" dolgok, elvégre mindig is jelentek meg, vagy tűntek el architektúrák. De, hogy is néz ki egy Alpha processzor?



A CPU-collection.de weboldalon találjuk meg a választ.



További információk: itt (hivatalos) és lexikális itt.

xmi küldte be a hírt:

A cseh Twibright Labs kiadta a Ronja optikai adatátviteli eszköz infravörös tartományban működő változatát, az Inferno-t. A teljes építési leírás GPL alatt terjeszthető. Remek példa arra, hogy opensource hardver nem csak FPGA program formájában képzelhető el.A Twibright Labs neve a Links web böngésző kapcsán lehet ismert.

A Ronja vezeték nélküli pont-pont összekötettések létesítésére alkalmas, nagyjából 1,4 km hatósugárral. Míg a legtöbb vezeték nélküli összekötettés rádiós (802.11) adatátvitelre épül, a Ronja ezt optikai úton valósítja meg. Ezzel elkerüli a kültéri rádiós átvitel egy lényeges problémáját, ez ugyanis nem engedélyköteles. Nem zavarja mások wifi hálózatát, és más hálózat sem zavarja az optikai átvitelt. A sugárnyaláb igen keskeny: a széttartás látható fényű változatnál 2 mrad (miliradián), a most megjelent infravörös változatnál a könnyebb célzás érdekében 3 mrad; ezért az egymás mellett haladó optikai adatutak sem zavarják egymást. A két végpont között szabad rálátás szükséges, de ez általában a nagy távolságú rádiós átvitelhez is kell. Közönséges, nagy fényerejű LED-eket használ, nem lézerdiódákat; a sugárzása az infravörös változatnak sem elég erős ahhoz, hogy szemkárosodást okozzon. Ezt egy erre a célra készített tanulmánnyal is alátámasztják.

Az egyetlen problémája, hogy a ködre/esőre érzékenyebb a rádiós megoldásoknál.

A rendszer 10Mbit-es full duplex ethernet kapcsolatot biztosít. Ellentétben a Wifi 11 illetve 54 Mbit-jével ez a 10Mbit kb 95%-ban ténylegesen kihasználható, mindkét irányba egyszerre. Így tehát a gyakorlatban elérhető átviteli sebesség a 802.11g-hez hasonló. Transzparens a végberendezések szempontjából, tehát közönséges AUI-s vagy UTP-s ethernet csatolókkal használható, nem kell hozzá speciális driver, egyedül a full duplex módot kell kézzel beállítani. (A későbbiekben várható erre is megoldás.)

Egy teljes kapcsolat összes moduljának megépítését kb 70 munkaórára teszik. A leírás eléggé szájbarágós, így annak pontos követésével elvileg első próbálkozásra működő rendszer készíthető. Kizárólag könnyen beszerezhető alkatrészekből áll, csak a LED igényelhet némi utánajárást (de tetszőlegesen helyettesíthető más, elegendően nagy fényerejű típussal is).

A leírás kiterjed a különféle tartószerelvényekre is, így színte bárhol (kémény, korlát, fal, tető) rögzíthető.

A suprnova.org és a novastream.org rádió honlapján olvasható a rövid közlemény, miszerint a jövő hét folyamán az eXeem első béta változatát közzéteszik.

FUSE: Filerendszer a felhasználói térben

Andrew Morton tegnap kiadta a 2.6.11-rc1-es kernel első -mm patchét. Az patch egyik újdonsága a FUSE. Ami miatt megakadt rajta a szemem elsősorban az, hogy meglehetősen magyaros volt a szerző neve. Korábban is láttam már a FUSE-t különböző fórumokon, de most, hogy esély van arra, hogy a mainline kernel része legyen jobban felkeltette az érdeklődésemet.

A FUSE szerzője Miklos Szeredi, aki tulajdonképpen Szeredi Miklós és hazánkfia. Mivel keveset tudtam a FUSE-ről úgy gondoltam, hogy a legegyszerűbb az lesz, ha közvetlenül a szerzőt kérdezem vele kapcsolatban. Ma délután írtam egy levelet, és Miklós pár órán belül válaszolt is.

Nézzük mi az a FUSE:``Láttam, hogy a FUSE beolvasztásra került a 2.6.11-rc1-mm1 kernelbe. Pár kérdésem lenne a FUSE-val kapcsolatban, de nem igazán találtam választ rájuk sem a http://www.szeredi.hu-n, sem a http://fuse.sourceforge.net/-en. Remélem, Tőled választ kapok a kérdéseimre :-)

Amennyit én tudok a FUSE-ről, az a következő:

A FUSE (Filesystem in USErspace) segítségével képesek vagyunk felhasználói térben filerendszert megvalósítani. A FUSE kommunikációs felülete egyszerű, hatékony, biztonságos és emellett támogatja a szokásos filerendszer szemantikákat.

Eredetileg az AVFS projekthez készült, de önálló projektté nőtte ki magát. A megszületése óta számos felhasználói térben megvalósított filerendszer használja a már FUSE-t.

Szóval a kérdések:''

trey: A klasszikus filerendszerek általában kernel térben vannak megvalósítva. Mi célból implementál valaki filerendszert a felhasználói térbe (user space)?

Szeredi Miklós: A kernel programozás több szempontból nehezebb, mint a közönséges (user space) programok írása. Például egy hiba a filerendszerünkben akár az egész rendszer stabilitására kihathat. Nehezebb nyomonkövetni a kernel futását, és a C nyelven kívül más nem használható. Ezek a
hátrányok mind nincsenek, ha userspace-ben valósítjuk meg a filerendszerünket.

Persze vannak hátulütői is a userspace megoldásnak: például
valamelyest lassul a file műveletek sebessége.

trey: Milyen lehetőségek vannak a FUSE-ban a felhasználók szemszögéből? Magyarul mire lehet felhasználni?

Szeredi Miklós: Van mindenféle: titkosított filerendszerek, a GMail-t mint tárhelyet kihasználó filerendszer, van amelyik Siemens telefonok adatait teszi elérhetővé, stb...

trey: Milyen korlátai vannak a FUSE-nak? Mi az amire a FUSE nem használható, és amire a kernel space filrendszereket kell használni?

Szeredi Miklós: Jelenleg a FUSE nem támogatja a memória meppelés (mmap) egy fajtáját (konkrétan shared writable mapping-et). Ezt azonban csak nagyon kevés, speciális program használja. Előbb utóbb majd felmerül az igény, hogy ez is működjön, de egyelőre nélkülözni kell.

Amúgy a határvonal nem ilyen éles. Vannak filerendszerek amik sokkal hatékonyabban megvalósíthatók kernelben (ilyenek a hagyományos, diszk alapú filerendszerek), és vannak amiket sokkal könnyebb userspace-ben megírni (pl. egy zip file-okat kezelő filerendszer)

trey: Mennyire stabil a FUSE? Használható már akár éles környezetben is?

Szeredi Miklós: Attól függ mennyire éles. Atomreaktorok vezérlésére például nem ajánlanám. Amúgy viszonylag stabil. Persze hibák mindig vannak és lesznek is. Jelenleg a legstabilabb verzió az 1.4-es, de ez már elég régi és sok minden hiányzik belőle. A legújabb a 2.2-pre3, ebben
azért még találunk problémákat.

trey: Miben más a FUSE, mit például a LUFS, amelynek első ránézésre hasonló a szerepe?

Szeredi Miklós: Valóban nagyon hasonló a két rendszer. A "lufis" névre hallgató kis programocska (FUSE honlapjáról letölthető) segítségével akár egy LUFS filerendszert is lehet FUSE kernellel futtatni.

A legfőbb különbség a filerendszerek futtatási környezetében rejlik. A LUFS filerendszerek dinamikus könyvtár (shared object) formájúak, miket egy keretprogram tölt be és hív meg minden egyes műveletre.

A FUSE esetén a filerendszer maga egy futtatható program, ami azonban használ egy könyvtárat (libfuse) a kernellel való kommunikáció megkönnyítésére.

trey: Olvastam a filerendszerek közt egy SMB for FUSE névre hallgató FS-ről. A leírása azt mondja, hogy hogy az SMB for FUSE-val probléma nélkül böngészhetem a (windows) hálózatot úgy, mintha az a saját filerendszeremen lenne. Körülbelül ezt tudom megvalósítani a kernel-beli smbfs és smbmount felhasználásával is. Miért jobb nekem, ha ezt a FUSE segítségével valósítom meg?

Szeredi Miklós: Pontosan nem tudom, mivel még nem probáltam (szerencsére nagyon keveset kell Windows környezettel érintkeznem). De valahogy úgy képzelem, hogy az SMB for FUSE a hálózaton található gépek feltérképezését könnyíti meg.

trey: Hiányoltam a filerendszerek közül az SSH-n vagy FTP-n keresztüli távoli filerendszerek mount-olásának lehetőségét (mint például a LUFS SSHFS vagy FTPFS). Ilyen létezik a FUSE-hoz is?

Szeredi Miklós: Egyrészt lehet a fent említett "lufis" megoldást alkalmazni. Ez azonban kicsit nehézkes, és már van natív SSHFS (FUSE honlapjáról letölthető, és 2.2-es FUSE verziót igényel).

trey: Miért pont FUSE a neve? Ha jól tudom, ezen a néven fut már másik projekt is?

Szeredi Miklós: Nagyon okos kis rövidítés: Filesystem in USErspace. De a névválasztás nem az erősségem, és ez a név már sok fejfájást okozott.

Köszönöm szépen Szeredi Miklósnak a gyors válaszokat. Mint Miklós írta, ez volt az első interjúja, így külön örömmel tölt el, hogy a HUP kérdezhette először...

A FUSE-val egyébként a napokban foglakozott a KernelTrap is itt.

A Google kis- és középvállalatok számára szánja a Google Mini elnevezésű dobozát, amely képes egy website-on, vagy akár a teljes céges intraneten keresni.

Pár napja több fórumon is olvasható volt néhány cikk (1, 2) a debianos apt-build használatáról. Ha már annyit emlegették gondoltam kipróbálom.

Előrebocsátom, hogy nem vagyok híve az ész nélküli optimalizálásnak. Azt vallom, hogy egy rendszer inkább legyen stabilabb, mintsem pár százalékkal gyorsabb (vagy lassabb és nagyobb?), de hajlamosabb a tévedésre.
Ez az írás is csak azért született, hogy lássuk, hogy a Debian alatt is van lehetőség arra, hogy valaki optimalizált csomagokat fordítson egyszerűen a saját rendszerére.

A ``legjobb disztribúció szerintem'' vitákban gyakran előkerül érvként, hogy ``a Debian azért nem jó, mert nincs lehetőség (vagy csak körülményesen lehet) az adott rendszerre lefordítani, optimalizalni a csomagokat, míg más disztribúciókban ez egyszerűen megy''.

Természetesen a fenti állítás nem igaz. Gondolom a hasonló állításokat cáfolandó született meg Julien Reveret ``apt-build: Optimize Debian packages for your system'' című írása is. Az írás azt mutatja be, hogy hogyan lehet a Debianban a szoftvereket úgy újrafordítani az apt-build segítségével, hogy azok a rendszerhez legyenek igazítva.

Az optimalizált rendszerhez jutásnak több módja is van. Az egyik a szokásos... letöltöm a forrást, kicsomagolom, futtatom a configure szkriptet, beállítom az kedvenc opcióimat, lefordítom, majd ``make install''-lal telepítem. Ezzel egy probléma van: nem használom ki a Debian csomagkezelés előnyeit. A másik lehetőség a Stow használata, amely nem igényel túl nagy erőfeszítést, de a végeredmény szintén nem igazán integrálódik össze a Debian csomagkezelő rendszerével. Az igazi megoldás az, hogy újrafordítjuk a Debian számára elkészített csomagokat az apt-build felhasználásával.

Az írás hatására kipróbáltam, hogy is van ez. Én biztos nem fogok ezzel időt tölteni, de hátha valakinek megjön a kedve hozzá :-)

Lássuk!1.) Próbáld ki, és használni fogod!

Az apt-build telepítése a szokásos módon történik:

# apt-get install apt-build

Amikor telepítve van, a post installation szkript egy csomó kérdést fog feltenni a

Az általad megadott információk a későbbi felhasználás céljából a /etc/apt/apt-build.conf fileban tárolódnak. Ha a telepítéskor elhibáztál egy kérdést, ott tudod korrigálni a beállításokat. A telepítés után így néz ki a file:

Persze az options=" " részbe jöhetnek a további okosságok, mint például a -fomit-frame-pointer
-funroll-loops -pipe, hogy csak a gyakrabban használtakat említsük (teljes lista itt).

Ellenőrizd le, hogy a build-dir és a repository-dir paraméterek olyan partícióra mutatnak, ahol a fordításhoz elegendő hely áll majd rendelkezésre.

Végül a használathoz egy sort be kell szúrni a /etc/apt/sources.list fileba (függően attól, hogy melyik terjesztést követed):

Ha ezzel végeztél, akkor kész is vagy az apt-build használatára!

2.) És most mit csinálunk?

Az apt-build-nek néhány kulcsszava ismerős lehet az apt-get-ből. A leggyakrabban használt parancsok az update, upgrade, install, source és clean-build. Melyik mire való?

Az update parancs azt csinálja, amit a neve mond. Frissíti a telepíthető csomagok listáját. Az upgrade parancs hatását gondolom nem kell magyarázni. Nézzük mit csinál az install parancs:

Amint látjuk az apt elvégzett néhány feladatot. Megvizsgálta a build függőségeit, letöltötte a forrást, lefordította, majd telepítette a csomagot. A fordítást természetesen annak megfelelően végezte el, ahogy azt korábban az /etc/apt/apt-build.conf-ban megadtuk. Ezzel a csomag optimalizált állapotban telepítésre került a rendszerünkre.

3.) Mi van még?

Nézzük meg a source parancsot. Ez a parancs nem csinál semmi mást, mint letölti a telepítendő csomag elkészítéséhez szükséges forrást, és azokat fileokat amelyeket a debian/ könyvtárban találunk, és amelyek ahhoz kellenek, hogy elkészíthessük a csomagot (rules, control, changelog fileok, stb.). Ezeket behelyezi a build könyvtárba, kibontja őket és alkalmazza a pactheket. Például:

4.) Az egészet akarom!

A BSD rendszereken megfelelő előkészületek után egy make buildworld paranccsal újra tudjuk fordítani az egész alaprendszert úgy, hogy az a gépünkhöz legyen igazítva. Milyen jó lenne, ha Debian alatt is meg lehetne ezt csinálni! Sőt az összes telepített csomagot újra lehetne fordítani... Az apt-build-del újra tudjuk!

Amint látszik a world fordításához még hiányzik a /etc/apt/apt-build.list file. Ezt létre kell hoznunk:

Megszerkesztjük a filet igény szerint. Ezután egy apt-build world paranccsal újra tudjuk fordítani a rendszerünkön található csomagokat. FIGYELEM: mindenki csak saját felelősségére!

Annak érdekében, hogy egy apt-get dist-upgrade parancs kiadása után a szépen lefordított csomagjainkat ne írja felül az apt a hivatalos verzióval, állítsuk be az apt-build által készített csomagok prioritását a apt-pinning segítségével a /etc/apt/preferences fileban így:

Package: *

Pin: release o=apt-build

Pin-Priority: 990

Ezután nem kell aggódnunk, hogy az dist-upgrade fejbevágja a saját csomagjainkat. Az ellenőrzéshez használjuk az apt-cache policy parancsot:

# apt-cache policy

Package Files:

100 /var/lib/dpkg/status

release a=now

500 http://ftp.de.debian.org sarge/non-free Packages

release o=Debian,a=unstable,l=Debian,c=non-free

origin ftp.de.debian.org

500 http://ftp.de.debian.org sarge/contrib Packages

release
o=Debian,a=unstable,l=Debian,c=contrib

origin ftp.de.debian.org

500 http://ftp.de.debian.org sarge/main Packages

release o=Debian,a=unstable,l=Debian,c=main

origin ftp.de.debian.org

990 file: apt-build/main Packages

release o=apt-build,a=apt-build,l=apt-build,c=main

Pinned Packages:

Ez az írás csak egy kis kivonat volt az eredeti cikkből. Az angol nyelvű verziót megtalálod itt. A használat előtt érdemes még elolvasni a /usr/share/doc/apt-build/README.Debian file-t is. További infók nyerhetők ki a (sajnos már csak Google cache-ben megtalálható) APT-Build HOWTO-ból is.

Több csomagot is sikerrel újrafordítottam az apt-build-del. Nekiálltam a world lefordításának is, de aztán ráuntam. Aki esetleg nekiáll lepörgetni egy egész rendszert, az írja meg a tapasztalatait!

A HP azt tervezi, hogy megfiatalítja az OpenVMS operációs rendszert. A cég hétfőn tervezi kiadni az OpenVMS 8.2-t. Ez lesz az első olyan kiadás, amely már futni fog az Intel Itanium processzorokon. Ez azért érdekes, mert ezzel új életet adnak az OpenVMS-nek. Az Alpha processzorok tervezésének / gyártásának befejezésével az OpenVMS jelenlegi processzor alapja szűnik meg. Úgy tűnik, hogy itt is az Itanium veszi át a kifutó termék szerepét (hasonlóan a HP PA-RISC processzoraihoz, ahol szintén ez a csere (megy) ment végbe).

Ebből az alkalomból egy hosszabb összefoglalót készített a C|net, amelyet elolvashatsz itt.

Ezen kívül egy interjút is elolvashatsz itt Mark Gorham-mal a HP OpenVMS diviziójának felelős alelnökével.

Közeledik a sokak által várt XFce 4.2 végleges változatának kiadása.Ez önmagában még nem lenne újdonság, viszont az os-cillation mirrorjain (akik egyébként az -rc változatokhoz is készítettek Debian csomagokat) megjelentek a 4.2-es verzió csomagjai.

Hivatalos bejelentés még nincs az xfce.org-on, de a roadmap szerint holnap várható.

A Debian csomagokat az os-cillation Debian Sarge-on tesztelte, de minden probléma nélkül működik természetesen Debian Sid alatt is.

Használathoz a következő sorokat kell a sources.list-be szúrni:

deb http://www.os-works.com/debian testing main

deb-src http://www.os-works.com/debian testing main

XFce 4.2.0 Debian package list

Telepítéshez útravaló annak aki nem tudná hogyan kell.

Patrick J. Volkerding nemrég egy IRC-s beszélgetésben felvázolta a Slackware jövőjét, a 11-es kiadására várható változásokat a dsiztribúcióban.

Greg ``groggy'' Lehey - FreeBSD híresség, volt core team tag, a Vinum szerzője - egyik kedvenc időtöltése az otthoni sörfőzés. A hacker összeütött egy számítógép-vezérelt otthoni sörfőző berendezést. A sörfőző felügyeletét (pl. az állandó hőmérsékletet) egy 486-os gépen futó FreeBSD végzi. Aki kedvet kapott az otthoni sörfőzéshez, az látogassa meg (a /. effektus elmúltával) Greg honlapját (mirrordot oldal) a részletekért és a receptért.

Megjelent a Thoggen névre hallgató linuxos DVD rippelő program 0.2-es kiadása. A program a gstreamer-t és a GTK+ toolkitet használja a működéséhez.

Tegnap megjelent a MySQL 4.1.x szériájnak soronkövetkező bugfix kiadása. A forráskód és a bináris csomagok több platformra letölthetőek innen.

Végre az OpenBSD-be került pár dolog, ami a Bluetooth támogatást hivatott segíteni.

Chris Wright a korábbi beszélgetés hatására összeállította a Linux kernel biztonsági hibáit majdan kezelő kapcsolattartó ``működésének'' vázlatát.

A vázlatban az áll, hogy a Linux kernel fejlesztői nagyon komolyan veszik a biztonságot. Ennek megfelelően ha valaki biztonsági hibát talál, arról szeretnének (időben) tudni, hogy azokat javíthassák, és publikálhassák olyan gyorsan, ahogy az csak lehetséges.

A vázlat szerint ezt az alábbi módon szeretnék végrehajtani:1) Kapcsolattartó

Lesz egy kapcsolattartó. A kapcsolattartó a $CONTACTADDR. Ez nem más, mint egy zártkörű levelezési lista, amelynek a tagjai a biztonsági tisztek (Security Officers). Az Ő feladatuk, hogy a bejelentéseket megvizsgálják, szükség esetén a javításokat kifejlesszék, majd kiadják a fixeket. Az elképzelhető, hogy a biztonsági tisztek extra segítséget kérjenek az alrendszerek karbantartóitól ahhoz, hogy a hibát megértsék és a javítást el tudják készíteni.

Kívánatos lenne ha a bejelentéseket a kapcsolattartó $PUBKEY kulcsával titkosítva tennék meg a bejelentők.

Minél több információt biztosítanak a bejelentők, annál könnyebben és gyorsabban lehet a hibákat javítani. Bármilyen működő exploit kódok nagyon hasznosak a javítás kifejlesztéséhez. A biztonsági tisztek semmilyen exploitot nem publikálnak a bejelentő beleegyezése nélkül, kivéve ha az már publikus.

2) Bejelentés

A kernel biztonsági kontakt célja, hogy együttműködjön a bug bejelentőjével a hiba kijavításában és elvégezze a bejelentést (disclosure). A kernel biztonsági kontakt a hiba teljes közzétételét támogatja olyan gyorsan, ahogy az csak lehetséges. Ésszerű a bejelentés késleltetése abban az esetben, ha a hiba vagy a javítás nem teljes egészében ismert / megértett, a javítás nincs teljes egészében kész vagy a gyártók koordinációjára még szükség van. A késleltetési időt az illetékesek rövidre tervezik, amelyek napokban és nem hetekben, hónapokban mérhetők majd. Az teljes bejelentés alapértelmezett késleltetése $NUMDAYS.

Durván ennyi a javaslat.

Születtek még egyéb javaslatok is. Például Florian Weimer szerint a 3. pontnak érdemes lenne felvenni egy NDA-ra vonatkozó kitételt. Alan Cox szerint megfontolandó lenne egy a https://bugs.kernel.org-on működtetett Bugzilla is. Alan szerint a $NUMDAYS késleltetés mértékét még meg kell vitatni, de szerinte a 14 napos időkeret megfelelő lehetne.

További hozzászólások a thread-ben.

A Neumann János Számítógép-tudományi Társaság Webalkalmazások Fejlesztése Szakosztálya az ELTE Radnóti Miklós Gyakorlóiskola kiemelkedő támogatásával – immár hagyományosan – megrendezi a Harmadik Magyarországi PHP Konferenciát. Az előző két év hasonló eseményei után, az igen sikeres PHP RoadShow rendezvények tapasztalatait ötvözve a szokásos szervezői csapat készül a konferenciára. A helyszín ezúttal is az iskola 1146, Budapest, Cházár A. u. 10. szám alatt található épülete, az időpont 2005. március 12., szombat.A konferencia programja

A programot három párhuzamos szálon futó előadások alkotják, melyek között adatbázis kezelési kérdésektől kezdve, tervezési mintákon és módszertanokon át kész keretrendszerekig és tartalomkezelőkig számos szakmai téma kerül terítékre. Ezúttal kiemelt szerepet kapnak a PHP-hez szorosan nem kapcsolódó, ám a korszerű webfejlesztés alapkérdéseit jelentő CSS és diszkrét JavaScript technológiák, illetve a segítséggel élők számára is használható webhelyek kialakításának módszerei. A programban helyet kapott az információvédelem kérdése is.

A rendezvényre hazánkba látogat két külföldi vendégelőadó is, a PHPs körök elismert szaktekintélyei. Derick Rethans a nemzetközi környezetben is jól működő webhelyekről és a teljesítmény optimalizálásról beszél majd, Lukas Smith a PEAR kódkönyvtárat mutatja be, illetve az adatbázis absztrakcióról tart előadást.

A rendezvény látogatása ezúttal is ingyenes lesz, ám a később elindított regisztrációhoz kötött, a helyszín maximális befogadóképessége által korlátozott. Egyelőre a rendezvény hírlevelére iratkozhatnak fel azok, akik semmiképpen sem szeretnének lemaradni a szakmai programról.

Közösségi találkozók

A konferencia hagyományos módon lehetőséget ad a webfejlesztők különböző közösségeinek találkozására, a levelezőlistákról, fórumokról ismert szakmabeliek különtermekben találkozhatnak majd.

Programozói verseny

A rendezvény kapcsán ismét meghirdetésre kerül az ezúttal 2005 5+5k PHP 5 compo névre hallgató programozói verseny, mely értékes nyereményekkel csábítja a tehetségüket megmutatni szándékozó fejlesztőket, hogy szokatlan körülmények között bizonyítsák rátermettségüket.

Mi a PHP?

A PHP az egyik legelterjedtebb webes programozási nyelv, ami mára általános célú nyelvvé nőtte ki magát. Ingyenessége és széleskörű elérhetősége biztosítja a továbbra is folyamatosan növekvő felhasználói bázist számára. A nyelv Magyarországon is egyre népszerűbb a részben magyar dokumentációnak, magyar könyveknek, levelezési listáknak és tanfolyamoknak köszönhetően. A PHP gyorsan tanulható, de a tapasztalt programozók számára is hatékony eszközöket nyújt, ezért érdemes vele megismerkedni.

A Webalkalmazások Fejlesztése Szakosztályról

2003-ban, az Első Magyarországi PHP Konferencia keretén belül alakult meg a Neumann János Számítógép-tudományi Társaság Webalkalmazások Fejlesztése Szakosztálya. A független, szakmai közösség célja a webalkalmazások fejlesztésére használható nyelvek (például a PHP) népszerűsítése, szakmai anyagok írása, fordítása, azok támogatása, továbbá a programozási nyelvekkel és a kapcsolódó technológiákkal foglalkozó konferenciák szervezése és lebonyolítása. A szervezet szakmai lapja a Weblabor. A szakosztály nyitott, szívesen fogad olyan személyeket, akik részt szeretnének venni a tevékenységében.

A TS-7200 néhány jellemzője:

- 200MHz ARM9 processzor (MMU-val)

- 32 MB SDRAM

- 8 MB Flash drive (opcionálisan 16 MB)

- 10/100 Ethernet- Compact Flash foglalat

- 2 USB host port

- 2 COM port

- 20 DIO

- PC/104 expansion bus

- opcionális A/D és RS-485

- opcionális 802.11b WiFi

A alap stuff ára kevesebb, mint 150 amerikai dollár. A NetBSD december közepe óta portolva van a TS-7200-as gépekre.

James Chacon a NetBSD Release Engineering tagja egy magyarázatot postázott a NetBSD branch-ekről és az azokban várható változásokról a netbsd-announce listára. Elolvashatod itt.

Han Boetes azon mesterkedik, hogy Propolice támogatást ad a Linux kernelhez. A Propolice egy az IBM (Hiroaki Etoh) által kifejlesztett gcc (GNU Compiler Collection) kiterjesztés, amely védelmet ígér a stack manipulációs támadások ellen.

A C-ben írt programok az elégtelen programozói ismeretek vagy hanyagság miatt gyakran szenvednek olyan hibákban, amelyek puffer túlcsordulásos (buffer overflow) támadásokhoz nyújtanak támadási felületet. A Propolice az ilyen támadásokat próbálja meg detektálni és a változók újrarendezésével védelmet próbál nyújtani a mutatók (pointers) manipulálása ellen. A Propolice védelem a fordításkor kerül az alkalmazásokba, ezért a használatához az összes védendő alkalmazást újra kell fordítani. Az OpenBSD már jó ideje használja a Propolice-t (1, 2). Han Boetes egy levelet írt az LKML-re amelyben kifejtette, hogy szerinte a legtöbb Linux kernel hiba a puffer túlcsordulásos hibák közé tartozik. Hasznos lenne, ha a Linux kernelt le lehetne fordítani Propolice támogatással, mert szerinte a Propolice használatával az összes buffer overflow hiba DoS támadássá mérséklődhet a PP használata esetén. Ezért arra kéri a fejlesztőket, hogy fogadjanak el egy olyan patchet, amely lehetővé teszi a Linux kernel lefordítását PP támogatással (természetesen patchelt gcc esetén).

A fejlesztők több dologban sem értettek egyet Han-nel. Arjan van de Ven szerint a Linux kernel hibák nagy része nem buffer overflow hiba. Feltette a kérdést, hogy Han szerint mit nyernénk a PP-vel a Linux kernelben. Arjan szerint a PP alkalmazása sokkal inkább az userland-ben lenne érdekes. Andi Kleen egyetértett Arjan-nel, szerinte is nagyon ritkák a bof típusú hibák a Linux kernelben. Urlich Drepper szerint a Propolice gcc patchek meglehetősen a instabilak.

Mindenesetre született patch a 2.6.9-hez, aki úgy érzi, hogy kipróbálná, az megtalálja a foltot a thread-ben.

Több fejlesztés is történt a KDE 3.4 alpha megjelenése óta, így a KDE projekt kiadta a KDE 3.4 beta 1-et. Az anyag a Krokodile kódnévre hallgat.

Megjelent a GNOME desktop környezet legújabb fejlesztői kiadása. A változások listája itt, letölthető innen és innen.

[2005. jan. 13.] DSA-638 gopher - several vulnerabilities

[2005. jan. 13.] DSA-637 exim-tls - buffer overflow

A frissítésről szóló FAQ-nk itt.

Megjelent a népszerű webszerkesztő 1.0-s kiadása. A Bluefish egy teljes értékű szerkesztő program temérdek beépített funkcióval, varázslóval, amely megkönnyítheti a webdizájnerek és -programozók életét.

A napokban kiderült, hogy a torol.sh fatálisan működik, ha a fájl-, vagy könyvtárnév szóközt tartalmaz (köszönet fonya-nak az észrevételért).

"Free Software Magazine is the free magazine for the free software world." Ez a mondat köszönti a frissen indult, nevéből sejthetően nyíltforrású, szabad szoftverekkel foglalkozó Free Software Magazine honlapjának látogatóit. Az újság elektronikus és nyomtatott formában is elérhető.Az első szám tartalmából:

Werner Puschitz összeállított egy olyan biztonsági útmutatót, amelynek célja, hogy összeszedje az éles körülmények között üzemeltett Linux rendszerek biztonságosabbá tételéhez szükséges alapvető dolgokat.

A tartalomból:* General

* Patching Linux Systems and Limiting Software Packages (RPMs)

* Disabling System Services

* Checking Accounts

* Enabling Password Aging

* Setting Password Restrictions

* Restricting Use of Previous Passwords

* Locking User Accounts After Too Many Login Failures

* Restricting User Access Based on Time and Day

* Restricting Direct Login Access for System and Shared Accounts

* Restricting su Access for System and Shared Accounts

* Restricting System Access from Servers and Networks

* Preventing Accidental Denial of Service

* Checking File Permissions and Ownership

* Securing NFS

* Securing SSH

* Securing Sendmail

* Kernel Tunable Parameters

* Displaying Login Banners

* Miscellaneous

* Security Books

Az útmutató elolvasható itt.