Shery és RePa

Úgy kezdődött a dolog, hogy a facebookos srácok nyílt forrásúvá tették és kiadták a FriendFeed mögött álló python alapú webszervert, a Tornadot. Aranyos dolog, mert nem blokkol, sok klienst képes párhuzamosan kiszolgálni és relatíve gyors mert esemény vezérelt. Feltéve, hogy Linuxon használjuk, mert csak és kizárólag az epollt támogatja (illetve a hagyományos select()-et, nade akkor oda minden előnye).
Viszont én Solaris alatt is szeretném kihasználni a fent említett előnyöket, úgyhogy gyorsan összedobtam egy apró wrappert a libevent köré, ami működik is, és így a Solaris/FreeBSD felhasználók is örülhetnek.

Gyorsan nézzük hogyan történt a dolog.

Először a libeventet kellett letölteni és lefordítani. Szerencsére gond nélkül fordult update 7-es Solaris 10-en.
(jelenleg az 1.4.12-es változat a stabil, azt használtam)

$ ./configure --prefix=/opt/bitnet
...
checking port.h usability... yes # solaris event ports, ez kell nekünk
...
$ make install

Hogy python alól használni tudjuk, ahhoz szükségünk van a python-libevent csomagra, amit én kézzel tettem fel innen, mert a sajtboltos változat ősrégi.

$ export CFLAGS="-I/opt/bitnet/include"
$ export LDFLAGS="-L/opt/bitnet/lib"
$ python setup.py install

Ezután jött az érdemi munka, a tornadot rábeszélni, hogy a libevent-et használja. Ehhez egy ugyan olyan wrapper osztályt csináltam, amit a srácok csináltak maguknak a saját epoll, illetve a hagyományos select() támogatásához, ami igazából a standard python Poll objektum által megvalósított interface:

class _LibEvent(object):
    """A libevent based IOLoop implementation"""
 
    def __init__(self):
        self._eb = libevent.EventBase()
        self._events = {}
        self._ready_fds = {}
 
    def _fd_ready(self, fd, events, eventObj):
        eventmask = (IOLoop.READ * (events & libevent.EV_READ) / libevent.EV_READ) | \
                    (IOLoop.WRITE * (events & libevent.EV_WRITE) / libevent.EV_WRITE) | \
                    (IOLoop.ERROR * (events & libevent.EV_TIMEOUT) / libevent.EV_TIMEOUT)
 
        self._ready_fds[fd] = eventmask
 
    def register(self, fd, events):
        # ezt a reszt is at lehetne alakitani olyanna, mint az elozo fuggveny
        eventmask = 0
        if events & IOLoop.READ:
            eventmask = eventmask | libevent.EV_READ | libevent.EV_PERSIST
        if events & IOLoop.WRITE:
            eventmask = eventmask | libevent.EV_WRITE
        if events & IOLoop.ERROR:
            # does libevent has error event type?
            eventmask = eventmask | libevent.EV_TIMEOUT
 
        self._events[fd] = self._eb.create_event(fd, eventmask, self._fd_ready)
        self._events[fd].add_to_loop()
 
    def modify(self, fd, events):
        self.unregister(fd)
        self.register(fd, events)
 
    def unregister(self, fd):
        self._events[fd].remove_from_loop()
        del self._events[fd]
 
    def poll(self, timeout=10):
        self._ready_fds = {}
 
        self._eb.loop_exit(timeout)
        # libevent.EVLOOP_NONBLOCK hasznalatakor a timert sem varja meg, es megeszi a cpu-t
        self._eb.loop(libevent.EVLOOP_ONCE)
 
        return self._ready_fds.items()
 
...
 
# legvegere, illetve a mar ott levo 'try' blockba:
try:
    import libevent
    _poll = _LibEvent
except:
    _poll = _Select

Illetve ha nem akarjuk belehackolni a tornadoba a cuccot, akkor "monkey patching" technikával is bedolgozhatjuk, ekkor az alkalmazásunk ioloopjanak indítása előtt kell megmondanunk explicite, hogy libeventet használjon:

import tornado.ioloop
tornado.ioloop._poll = _LibEvent
tornado.ioloop.IOLoop.instance().start()

(remélem ezt nem kell sokáig megtenni, jeleztem a fejlesztők felé, hogy jó lenne a libevent támogatást a fő fejlesztési vonalon látni)

Csináltam is néhány gyorstesztet az egyik szerverünkön, sok párhuzamos kérés esetén látszik a fejlődés. A teszteket az apache féle ab paranccsal mértem, ahol az 'n' az összes lekérés, a 'c' pedig a konkurenciát (ennyi szálon próbálkozik párhuzamosan) jelenti. A parancsokat háromszor egymás után megismételtem, és a legjobb eredmény került ki ide.
(ulimit -n unlimited)

1. _Select:
   • n=10000, c=100: 1048.10 [#/sec]
   • n=10000, c=1000: 683.96 [#/sec]
   • n=10000, c=2000: 672.85 [#/sec] (a háromból egyszer meghalt a lenti hibával)
   • n=10000, c=5000: háromszor egymás után: filedescriptor out of range in select()
2. _LibEvent:
   • n=10000, c=100: 1056.57 [#/sec]
   • n=10000, c=1000: 1013.59 [#/sec]
   • n=10000, c=2000: 1004.94 [#/sec]
   • n=10000, c=5000: 954.52 [#/sec]
   • n=10000, c=10000: 781.10 [#/sec]
   • n=20000, c=10000: 934.32 [#/sec]

Első körben nekem elég is volt ennyi, hogy lássam, hogy megérte, aztán majd valami egyszerű webalkalmazással meg kéne nézni, hogy a többi megoldáshoz képest (fcgi, cherrypy, esetleg mod_wsgi) hogy muzsikál a cucc.

Használjátok egészséggel!

Megjelent a végleges python 3000!
(Túl sok változás nem történt az előző postjaim óta.)

Pythonra fel!

A műveletet tegnap befejeztük, éljen az open source, és az OpenSolaris fejlesztők, akik nélkül nem jöhetett volna létre pl. a gani driver, ami pöccre begyújtotta a Linksys chipes Realteknek keresztelt kártyát.
Következik a zónák - és bennük a szolgáltatások - felépítése, kíváncsi vagyok, hogy a Solaris hogy muzsikál x86 hardveren.

Végre megjelent!

Stabil API - ami azt jelenti, hogy az 1.0-s Django alkalmazások változtatás nélkül fognak futni a többi 1.x kiadáson -, és eltűnt a figyelmeztetés is, hogy nem ajánlják éles használatra. Rengeteg új feature (nem csak az előző 0.96-os változathoz képest, csak az elmúlt másfél hónapban több jelentős változás került bele a kódba), megújult dokumentáció, és a már megismert sebesség és stabilitás.

Aki webet fejleszt, nem zárkózik el az új dolgoktól, és még nem próbálta volna ki, annak mindenképpen ajánlom.

Már régóta beszéltek róla, hogy a Google majd egyszercsak előrukkol egy saját böngésző megoldással. És úgy tűnik most jött el az idő.

Pár screenshot, illetve egy képregény szerű bemutató is kikerült már, és a lényeget - magát a böngészőt, ami ráadásul nyílt forrású lesz - mára ígérik.

Kíváncsian várom, hogy egy ilyen nagy, és webes témákban talán a legszakértőbb cég milyen böngészővel áll elő, illetve hogy az hogy fog szerepelni a jelenlegi eléggé élezett böngészőháborúban, ahol a Firefox éppen kezdi néhány helyen beérni az IE-t.

[Update]: Letölthető bár egyelőre csak windowsra

Nemrég, hogy megjelent a python 3.0 beta (sőt, lassan itt a beta 2), úgy gondoltam, hogy megnézem mostmár mit tud. Eddig is olvasgattam, hogy a 2.x vonalhoz képest bizony változik az API, bár mivel a 2-es vonal is folytatódik, és több dologgal is segítik az áttérést, túl nagy gondok valószínűleg nem lesznek. A python 2.6 képes (lesz majd) jelezni, ha nem 3.0 kompatibilis dolgokat használ az ember, és ha már csak azokat használ, akkor van egy tool - a 2to3 -, ami az esetek 99%-ában automatikusan átalakítja a forrás py3k kompatibilissé.

Na nézzük röviden mit kapunk. tovább...

Gabortol kaptam ezt a videot, ami rovid izelitot ad a Vim kepessegeibol. Mivel en azert mar egy ideje hasznalom, nekem sok ujat nem mutatott, de megosztanam a nagykozonseggel, hatha valakit rasegit az igaz utra

A szerzo tervezi, hogy tobb rovid bemutato videot keszit majd a Vimrol, akit kicsit is erdekel, nezze meg az elso reszt, es ha tetszett fel is iratkozhat, nehogy lemaradjon.

Megegyszer:
A bemutato: Vim screencast tutorial teaser
Az elso resz: Vim screencast #1

Thank you Aaron!

Ma erdekes problemaba utkoztem. Egyik django instanceomba probaltam ekezetes betuket bevinni (ez nalam altalaban a fejlesztesi szakasz leges legvegere marad ), aztan nem sikerult teljesen, egeszen a mysqltol jott a hibauzenet, hogy marpedig valami nem jo ('Data truncated').

Johat nezzuk mi lehet, debian szokashoz hiven a szerver, a kliens es miattuk a default parameterekkel letrehozott adatbazisok, tablak mind latin1 kodolasuak ('latin1_swedish_ci' collation mellett, barmi is legyen az). Erted, 2008, latin1. Johat, akkor valtoztassuk meg, my.cnf-be gyorsan:

[mysqld]
default-character-set = utf8
character-set-server = utf8
init-connect = 'SET NAMES utf8'

Meglevo adatbazist es tablakat az ALTER TABLE/DATABASE [akarmi] CHARACTER SET utf8 COLLATE utf8_general_ci paranccsal at is toltam, aztan azt hittem itt a boldogsag. De nem. A hiba szepen jott ezutan is.
Google fellapoz, hopp, megoldas az az, hogy kidobod az adatbazist a szemetbe, majd ujracsinalod, mikor mar minden utf8 barat. Ertem.

Szerencsere ez igazabol csak annyit jelentett nalam, hogy kidumpoltam az adatbazist, majd - mindenfele modositas nelkul - visszadumpoltam. Hiszen papiron mar a tablak is utf8 baratok voltak, csak igazibol nem:

# mysqldump adatbazis > adatbazis.sql
# mysql adatbazis < adatbazis.sql

Es most minden szepen mukodik.

Tehat a Sun ugy dontott, hogy beszall a adatbazis bizniszbe is, most kb. a csapbol is ez folyik a neten, meg az index is megirta.

De szerintem - es masok szerint is - ennek a lepesnek melyebb strategiai celja is van. (Na persze egy sajat adatbaziskezelo - ami egyebkent a a legelterjedtebbek koze tartozik a vilagon -, sose jon rosszul a haznal, meg hat a supportert is lehet szep penzt kerni.)

Megpedig: kis- es kozepvallalatok koreben meltan nepszeru opensource LAMP modellnek tud lassan a Sun jol mukodo es rendesen tamogatott alternativat nyujtani. Ez lenne a SAMJ , azaz az (Open)Solaris+Apache+MySQL+Java alapu platform. (Igazan szep akkor lenne, ha az Apache helyett valami sajat, jol mukodo opensource webszerverrel is kijonnenek.)
Vegulis minden reszegyseg opensource, ingyen lehet hasznalni, es (majdnem) minden komponponenshez a Sun tud adni olyan supportot, amit senki mas.

A Solaris azert tobb ponton tud olyat mutatni a Linuxnak, hogy az elszegyelli magat, azzal nem is lenne gond. A Javaval viszont bonyolultabb a helyzet. Eloszoris aki eddig phpban "programozott" - tisztelet a kivetelnek - az nem fog megtanulni csakugy hipphopp Javaban (persze a Sun jo penzert mindenkit megtanit ), ott azert mar tenyleg programozni kell, a php-nal jol bevallt ganyolas nem sok eredmenyt hozhat. Es mondjuk nekem szemely szerint is vannak fenntartasaim a Java webes felhasznalast tekintve, plane epp a LAMP-os celkozosseg koreben, na de majd meglatjuk, mit hoz a jovo.

Eszunkbe jutott, hogy mi lenne, ha csinalnank a workstationokre uj Sol10-es flar image-et, mert a regi mar elegge regi. Arra gondoltam, hogy ha mar ugyis benne vagyok, akkor forgatok egy e17-et is bele, hadd oruljon az a 2-3 fejleszto, aki rajtam kivul hasznalna (em mar jo masfel eve azt hasznalok itt is)

Igaz, hogy a regit relative keves hackolassal sikerult leforditani, es az enlightenmentes fiuk elvileg az elejetol kezdve ugyelnek a platformfuggetlensegre (johat, azert X kell hozza), de hat ismerem en a programozokat, ugyhogy aggodtam egy kicsit, hogy nagy faba vagom a fejszemet. Hat felesleges volt. tovább...

Valaki nemreg megkerdezte, hogy mit hasznalok zenelejatszasra a szamitogepen, aztan gondoltam hatha mast is erdekel.

Mig regesreg kb. minden linuxos kollega azt valaszolta volna, hogy xmms (ahogy windowsos korokben a winamp volt a legnepszerubb), mara mar azert nagyon sok igen jo lejatszo kozul valaszthatunk, es majd mindenkinek mas all kozel a szivehez.

En egy jo ideje az mpd-t hasznalom, igen nagy megelegedessel. Igen sokfele fileformatumot tamogat (mp3, ogg, flac, aac, ...), keveset eroforrast igenyel, es tavolrol is egyszeruen vezerelheto.
Maga az mpd - ahogy a neve is mutatja - csak egy daemon, ami pont annyit tud, amennyit egy zenelejatszonak tudnia kell - zenet jatszik le. Viszont ahhoz, hogy vezereljuk nem art valami kliens, amivel hozzaferunk. Szerencsere igen sok kozul valaszthatunk.

En a puritan mpc es ncmpctol kezdve, a gmpcn es sonatan at eljutottam a pitchforkig. Bongeszom ugyis mindig nyitva van, akkor meg miert ne hasznaljam arra, hogy azon keresztul iranyitsam a zenelejatszast? Kulon hasznos lehet a dolog, ha a lakasban van egy HTPC, viszont mi inkabb mondjuk a sajat laptopunkon netezunk, akkor onnan is egyszeruen valtogathatunk a zeneszamok kozott - es ha esetleg nem tetszik a parunknak az aktualis zene, akkor o is egyszeruen valthat

Egyik futo projectben felmerult, hogy hogy osztunk meg weben tartalmat ugy a neppel, hogy rendes access controlunk lehessen. Azaz pl. lehessen alligatni userenkent savszelesseget, hozzaferesi idot, es minden butasagot, ami csak eszunkbe jut.

Alapbol ugye van a webszerver oldali .htaccess es baratai megoldas, ahol eleg szukosek a lehetosegek, es hat nem is egy olyan kifinomult admin feluletunk van, mint a djangonak. De kigondoltam valamit, igaz a modszer nem tul hatekony - az eroforrasok szempontjabol -, de mindent lehet, amit mi akarunk, es majd max kap a gep +10% procit es memoriat.

Az alapotlet az, hogy nem kozvetlen a webszerver adja vissza a filet a kliensnek, hanem az csak egy cgi/fcgi scripttol keri azt el, ami szepen "felolvassa" azt a merevlemezrol, felteve, hogy a felhasznalonak ezt mi megengedtuk.
Ezt egyebkent egy akarmilyen scriptnyelvben nevetsegesen egyszeru megcsinalni, pl. phpban:

$filename = "/ez/a/file/kell";
header('Content-Type: ilyentipusuafile');
header('Content-Length: afilehossza');
readfile($filename);

Szoval egyatalan nem bonyolult.

Djangoban azonban nem talaltam olyat, hogyan adok vissza nem tipikus tartalmat. Az alap HttpResponse-t nem arra talaltak ki, hogy szepen olvassa fel a fileokat a winyorol, ugyhogy - eljen az OOP - leszarmaztattam belole, es ime az eredmeny.
Djangoban ezutan csak egy view kell, ami ellenorzi, hogy megfelelo-e minden feltetel (be van-e lepve a felhasznalo, a megadott idopontban tolthet-e le, kek-e a szeme, es hithu kereszteny-e), es ha igen, akkor egy egyszeru return HttpFileResponse(fileneve), es a file mar uton is van.

Nincs meg kesz persze, de akinek kell, az vigye, akinek meg van valami jo otlete, az szoljon! (A kod egyebkent a kb. 3 hettel ezelotti svn trunk alapjan keszult, stabil 0.96-os djangoval, vagy a legfrissebb fejlszetoi anyaggal nem feltetlen mukodik, de sokat tuti nem kell rajta dolgozni, hogy menjen.)

Ha van ket programunk, es mi azt szeretnenk, hogy az egyik beszelgessen a masikkal, akkor sokfele IPC megoldas kozul valaszthatunk, a hagyomanyosoktol kezdve (szemafor, socket, ...) a modernebbekig (pl. CORBA, RMI, ...) eleg sokmindent valaszthatunk. Utobbiak koze tartozik a DBUS, melyet a modern linux disztribuciok kivetel nelkul tartalmaznak.

Nezzunk egy egyszeru peldat arra, hogy ezt az uzenet-buszt az egyszeru halando hogyan hasznalhatja. Eszkozkent termeszetesen a sokak altal meltan kedvelt python nyelvet valasztottam
Ubuntu/debian alatt a python-dbus csomag tartalmazza a szukseges dolgokat.

Nezzuk gyorsan, hogy nez ki egy uj szolgaltatas, utana fuzok hozza egy kis magyarazatot:

import dbus, dbus.service, dbus.glib
import gobject
 
class ButaService(dbus.service.Object):
 
  @dbus.service.method(dbus_interface='hu.horak.ButaInterface',
                       in_signature='s', out_signature='')
  def irjadki(self, szoveg):
    print "Ez jott: %s" % szoveg
 
bus = dbus.SessionBus()
name = dbus.service.BusName('hu.horak.ButaServer', bus=bus)
obj = ButaService(name, '/')
 
loop = gobject.MainLoop()
print 'Figyelek...'
loop.run()

Amint lathato eloszor letrehozzuk a szolgaltatasunkhoz tartozo osztalyt, a dbus.service.Object osztalybol szarmaztatva. Ezen osztaly metodusait exportalhatjuk szolgaltataskent a dbus.service.method dekorator fuggvennyel - ennek a szolgaltatasi felulet nevet kell megadni, illetve a bejovo es kimeno parameterek tipusat - ami pythonban ugye nem egyertelmu, dbuson viszont annak kell lennie.
A szolgaltatasunkat mikor peldanyositjuk, az regisztralja magat egy mar meglevo busznal. Alapertelmezetten ket ilyen busz van, a SessionBus, ami a bejelentkezett felhasznaloknak a sajatja, illetve a SystemBus, ahol a rendszeruzenetek szaladgalnak. Mivel utobbihoz csak rendszergazdai jogokkal tudunk szolgaltatast hozzaadni, ezert az elobbit illik valasztanunk.
Ha kesz a szolgaltatasunk mar csak varni kell, hogy valami kliens hasznalja is azt, ehhez szuksegunk van egy glib kompatibilis mainloopra. Elinditjuk, es varjuk, hogy az elso kliens uzenetet kuldjon nekunk...

...amit meg ennel is joval egyszerubb:

import dbus, dbus.glib
 
bus = dbus.SessionBus()
 
server = dbus.Interface(bus.get_object('hu.horak.ButaServer', '/'),
                        'hu.horak.ButaInterface')
server.irjadki("helloszia")

A kliens egyszeruen annyit csinal, hogy lekeri a beregisztralt szolgaltatasunkat (illetve egy helyi proxy-objektumot keszit, ami vegulis tarsalog a szerver oldallal), majd meghivja az exportalt metodusat. A szerver oldalon pedig megjelenik az "Ez jott: helloszia" uzenet.

Pofonegyszeru. Persze nem arra van kitalalva, hogy masodpercenkent tobbmillio uzenetet kuldozgessunk...
Akit jobban erdekel a tema megnezheti az eredeti tutorialt.

Gabor baratom emacs parti ( fiatal meg, nem tudja mi a jo ), legfrisebb cikkeben azt irja le, hogy lehet megkerni az emacset, hogy ne az aktualis konyvtarba helyezze a backup filejait (mert pl. mi van ha oda nincs irasjogunk, vagy tavoli filerendszeren van, vagy ...), hanem oda ahova mi szeretnenk.

En viszont vim parti vagyok, ott sem bonyolultabb a dolog: az ideiglenes (swap) fileok helyet a directory valtozo tarolja (vesszovel elvalasztva tobb konyvtar is megadhato, az elso lehetseges helyre kerul majd a file), pl:

:set directory=~/bkp/vim,.,/tmp

A backup fileok helyet a backupdir valtozo segitsegevel adhatjuk meg a fentihez hasonlo modon.
Emacs-szel ellentetben vim-ben a backup nemhogy nem kapcsolhato ki*, hanem alapbol nincs bekapcsolva, a

:set bk

paranccsal kapcsolhato be.

A beallitasokat termeszetesen erdemes a ~/.vimrc fileocskaba gyujteni (ilyenkor a parancs ele nem kell : ), es akkor a vim kovetkezo inditasakor nem kell ujra beirnunk.

*: persze, hogy emacsban is kikapcsolhato, csak nem tanacsos

Az AMD bejelentette, hogy szep lassan megnyitjak az eddig zart forrasu ATI videokartya-drivert. Igazabol ez mindenkinek jo, egyfelol eddig Linux alatt az Nvidias eszkozok sokkal jobban muzsikaltak (es nem feltetlenul a hardware miatt), tehat akinek ATI kartyaja van, az valoszinuleg jol fog jarni. Es remelem az Nvidia sem hagyja majd ennyiben a dolgot, es kirukkolnak majd valamivel ok is - ha nem is nyitjak meg a sajat driveruket, legalabb a Nouveau projectet tamogathatnak egy kicsit, legalabb valami doksival.
Na persze en az AMD-nek is csak akkor hiszek, ha mar valoban megtekintheto a doksi

Ma a diggen talaltam egy cikket egy viszonylag egyszeru, es - manapsag meg - hatekony spam ellenes technikarol.

Annyi a lenyege, hogy ha a megjegyzes mezok koze elrejtunk egy extra mezot, amibe ha valamit valaki ir, akkor nem lesz ervenyes a megjegyzese. Az elrejtest szo szerint ertem, CSS visibility: hidden jellemzo segitsegevel (remelem ez IE alatt is mukodik, egyelore ott nem tudtam megnezni).

Gondoltam egyet, es gyorsan gyartottam is hozza egy wordpress plugint, akinek kell letolti, kitomoriti a wp-content/plugins konyvtarba, bekapcsolja az admin oldalon, es kesz.

Ha esetleg megse lenne kesz, akkor az azert lehet, mert a tema nem teljesen standard, ez esetben a comment form megjelenitesi reszhez be kell szurni az alabbi kodreszletet:

do_action('comment_form', $post->ID);

Eszreveteleket szivesen fogadok kommentben, esetleg ha valamiert nem mukodik, es nem tudsz kommentelni, akkor levelben

Szal, ahogy regebben irtam, csinaltam specko M2Crypto csomagot Solarishoz, mert abban trukkos az openssl. Ma upgradeltem, mert kiderult, hogy annyira trukkos az a szemet, hogy annak ellenere, hogy nincs benne 256 bites AES, azert lejelenti, hogy van:

.( horakgy@sun130sd pts/32 ~ )----
'(14:20:28)% openssl ciphers "ALL"
ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:...

Es bizony mikor ennek az M2Crypto (vagy barmimas) megorul, es lelkesen elkezdi hasznalni, akkor elszall.
Ha kell olyan, ami ennek nem dol be, akkor szedd le innen.

A Solaris 10-ben frissul a python, illetve belekerul a 2.4.4-es verzio is. Ugyhogy az az otletem tamadt, hogy forditsam le ehhez az M2Crypto-t, ami amugy egy openssl wrapper pythonhoz, es igen hasznos tud lenni. Hat nekialltam.

Mar regebben is olvastam valamivel kapcsolatban, hogy pl. az openssl-t, meg hasonlo kriptografiaval kapcsolatos cuccokat nemigen szabad ellenseges (marmint az USA-nak ellenseges) orszagokba exportalni. Dehat azzal is tisztaban voltam, hogy Solarist adnak el Irannak is, abban meg benne van. Viszont ma kiderult hol a csel: a Solarisban levo openssl bizony csak a 128 bites AES-t tamogatja, a 192 es a 256 bitest nem (es meg ki tudja mit sporoltak ki belole). Igy viszont az M2Crypto nemigazan megy vele. Persze tehetnenk fel akarhonnan a netrol leszedett openssl-t, es fordithatnank azzal is, de szamomra ez nem volt megoldas, ezert picit megpiszkaltam a forrast, es minden AES fuggvenyt a 128 bites valtozatokra mappeltem at.

Egyelore ugy fest mukodik, ha valakinek szuksege van ilyen csomagra (mert nekem pl. volt, de nem talaltam sehol), akkor az szedheti is iziben.

Gabor baratom ujabb Firefox kiterjesztesre hivta fel olvasoi figyelmet, es inkabb megemlitem enis, hatha valaki ot nem olvassa (van olyan?).

Igaz, hogy az uj wordpress mar mentegeti a szovegdoboz tartalmat idonkent, de ez azert egyelore eleg ritka szolgaltatas, es hat megis jobb vim-mel irni a postot (ahogy ezt most epp teszem)
Es amiota ezer gomb van az egereken, azota bizony megeshet, hogy az ember akaratlanul nyom egy history-back-et.

Disznojo.

Szoval a egyre inkabb baratja a szabad szoftvereknek. Eloszor jott az OpenSolaris, aztan a Java, most pedig a GPLv3 - tehat latszik, hogy tartani is akarja ezt az iranyt, aminek en igencsak orulok.

Igazabol en szeretem a Linuxot, jo regota hasznalom, nincs is vele nagyon bajom. Solarist szinten szeretem, igazabol ugyanazokat az alkalmazasokat hasznalom rajta szinte, mint amit Linuxon.
Az atlag usernel egyelore a Linux a nyero, tobb hardvert tamogat, vannak ra jatekok, nagyobb a reklam korulotte. Ezzel szemben az Solaris sima foldi halandoknak meg csak rovid ideje elerheto, ahonnan jott, ott nemigazan kellett foglalkozni a mindenfele szutyok kinai PC hardverrel, es nem is nagyon akart rajta jatszani senki, de pl. a driver interface az atomstabil, tehat elvileg ezeket a hatranyokat hamar ledolgozhatna. A Linuxban ellenben... (Igen, tudom, bezzeg a *BSD-k.)
Egyelore en otthonra meg Linuxot valasztanek, ha nullarol kene telepiteni, de remelem eljon az ido, amikor nyugodt szivvel telepithetek akar OpenSolarist is.