Harmadik Országos Perl Találkozó: előadókat és szponzorokat keresünk!

Perl

Örömmel jelenthetjük, hogy immár harmadik alkalommal országos Perl találkozót szervezünk. A találkozó témája "A Perl jelene és jövője". A találkozó időpontja október 22., szombat. Szívesen vesszük hazai és külföldi előadók, szponzorok jelentkezését!A magyar Perl levelezőlista tagjai immáron harmadik alkalommal rendeznek országos Perl találkozót. Ebben az évben szeretnénk az eddigi találkozókon továbblépve egy nagyobb lélegzetű rendezvényt szervezni, külföldi előadók meghívásával, a korábbiakhoz képest egy kicsit nagyobb helyszínen.

A találkozót október 22-n, egy szombati napon tartjuk, reggel 9-től várhatóan délután 16-ig. A találkozó helyszíne az ELTE Radnóti Miklós Gyakorlóiskolája lesz.

A találkozóra a jelentkezést a közeljövőben hirdetjük meg, most érdeklődő előadók, szponzorok jelentkezését várjuk!

Előadást tartani szinte bármely, a Perl-hez kapcsolódó témakörben lehet, szívesen veszünk villámelőadásokat (5-10 percben egy adott témakör gyors bemutatása), vagy hosszabb lélegzetvételű bemutatókat.

Az előadók Szabó Gábornál jelentkezhetnek. Kérjük, hogy az előadás címét, rövid leírását, nyelvét (angol/magyar), az igényelt időt írják be, illetve röviden mutassák be magukat.

A rendezvényre több neves külföldi Perles személyiség meghívását is tervezzük, illetve a helyszín bérlete is pénzbe kerül, ezekre a célokra tehát minden támogatást szívesen veszünk.

A szponozorok jelentkezését Bártházi András várja.

( trey | 2005. 09. 16., p – 10:00 )

En szeretem a Perl-t. Eleg sokat barkacsolok benne. A HUP-on is dolgozik nehany egyszeru Perl szkript a hatterben. Ujabban azt vettem eszre, hogy az ismeretsegi koromben nehany ember elfordult a Perl-tol es helyette Python-t es Ruby-t kezdtek el hasznalni. Tobb embert is hallottam panaszkodni a Perl-re. Ez ilyen vilagtendencia, vagy csak egyedulallo esetek lehetnek, es nincs semmi baj a Perl-el?

NEM szeretnék flame-et. Csak 1 vélemény.

Én Python hívő vagyok, lehet hogy egy kicsit elfogult, de szerintem a Python áttekinthetőbb szintaktikája, gyorsabb tanulhatósága és bizonyos esetekben a feladat gyorasbb megoldása lehet a Perl től elfordulók (vagy nem Perl-ben kezdő) programozók számának növekedése. Számomra a következők miatt egyéertelmű a Python használata (amik nincsenek perl-ben, vagy nem tudok róla) : wxPython, ZOPE, Plone, amiket használok, és nem tudok róla hogy lenne ilyen hatékony pl. Perl-ben írt alkalmazásszerver vagy CMS/CMF rendszer. Hasonló a helyzet a Ruby-val, csak az még fiatalabb nyelv.

"Ez ilyen vilagtendencia, vagy csak egyedulallo esetek lehetnek, es nincs semmi baj a Perl-el?"

Sajnos úgy tűnik igen. Ma már szinte sehol nem kezdenek

nagyobb projektekbe Perl nyelven. Kis feladatokra PHP, Python nagyobbakra JAVA. A perl6 csak igeret évek óta.

Pedig én is szeretem.

Mi egy vállalati dokumentumkezelő rendszerbe kezdtünk bele nemrégiben Perlben. Semelyik általam ismert más nyelv nem lenne képes potenciálisan ekkora rugalmasságra a más rendszerekhez való csatlakozás, kész modulok terén. Nem konkrétan a nyelv miatt, hanem a CPAN miatt.

A Perl 6 kidolgozása valóban egy sokéves folyamat. Idén azért elég sokminden történt ezen a téren. Nem egy egyszerű _architektúráról_ szól, hanem egy nagyon sokmindenre képes, kifejezetten modern, jól tervezett nyelvről. Ettől még fejlődhetne gyorsabban persze. A Perl 6-ról és az architektúrájáról a tervek szerint én is, illetve Leo Tötsch (Parrot "főfejlesztő") is beszélni fogunk, lehet kérdezni. :)

Mint lentebb irtam MO-on soha nem volt nagyon nepszeru a Perl. Kulfoldon jobban nyomjak, eleg megnezni a megjelent konyvek listajat.

Az teny, hogy a nyelv jelentosege csokkent, mivel sok jo nyelv van ma mar (pl. Python (a PHP _nem_ tartozik ide)). Ami meg mindig nagy elonye a Perl-nek, hogy sok library van hozza (CPAN).

A fenti cikk inkabb velemenynek tunik, mint tenyszeru kozlesnek. A PHP rossz pelda. Azert terjedt el, mert egyszeru es meg tudja tanulni a 14 eves gyerek is.

Az viszont igaz, hogy a Perl-re nem voltak elterjedt megoldasok. Pl. sokat CGI-t hasznaltak, ami ugye eleg lassu. Aztan mondtak, hogy lassu a Perl. Pedig nem a program futasa lassu, hanem az overhead nagy, amivel egy CGI elindul. A PHP CGI is lassu.

FastCGI-s megoldast alig lattam, tutorial nem igazan volt a fastcgi.com-on kivul. Van meg a mod_perl nevu remalom, de azt inkabb hagyjuk.

PHP-ban konnyu volt weboldalakat irni, nem kellett bekonfigolni a CGI-t, chmod-olni stb. Perl-ben viszont igen es meg akkor is csak egy CGI-t kaptal, ami lassan futott.

Ez mennyiben implikalja, hogy nem rossz? Anno abban kezdtek el, mert vsz. olyan emberuk volt, aki ahhoz ertett. a CGI meg nem birta volna azt a terhelest, tehat az nem lehetett alternativa.

nehany mod_perl problema (nemelyik igaz a mod_php-ra is):

- az interpreter az apache address space-eben fut. biztonsagi szempontbol ez tudod mit jelent...

- minden process a web user jogaival fut

- a mod_perl forditas mindig rizikos: perl es apache C-flag-ek keverednek (thread-es Perl vs. thread-es apache)

- nem tudod kirakni a programot egy kulon szerverre, mivel az az apache-ban fut (load-sharing/balacing).

A PHP sem biztonsagos. Annak meg masmilyen nyugjei vannak. De ilyen alapon ami a weben van arra azt allitani, hogy biztonsagos... erdekes dolog lenne.

> - a mod_perl forditas mindig rizikos: perl es apache C-flag-ek keverednek (thread-es Perl vs. thread-es apache)

Ez a disztributor dolga. Normalis disztroban te mar elvileg leprobalt dolgot kapsz.

> - nem tudod kirakni a programot egy kulon szerverre, mivel az az apache-ban fut (load-sharing/balacing).

Ezt pontosithatnad. A Slashdot az alabbi rendszerben mukodik:

* 5 load balanced Web servers dedicated to pages

* 3 load balanced Web servers dedicated to images

* 1 SQL server

* 1 NFS Server

Ne ertsd felre, nem vedeni akarom, de valami, ami kiszolgal ekkora latogatottsagot az annyira nem lehet *****. Es penzuk is lenne atterni, ha nagyon akarnanak.

Az nem biztonsagos, ha az interpreter a webszerverben fut. Nalam nem fut ott.

Igen, altalaban meguszod, ha disztribuciot hasznalsz. Attol ez meg letezo problema. Lehet nem neked, de sokan szivnak vele.

Arra gondoltam, hogy nem tudsz olyat csinalni, mint mondjuk TBNL-nel vagy FastCGI-nel, hogy a program _egesze_ egy masik gepen fut. Mert a mod_perl-hez mindig kell webszerver is. Az altalam hasznalt megoldasnal viszont nem kell webszerver arra a gepre, amin a program fut. Eggyel kevesebb kockazati tenyezo.

Furcsa, de a Perl/CGI is meglepően gyorsan tud futni egy modern architektúrán (egy átlagos oldalt simán kiszolgál). Ha pedig valóban a sebesség a fontos, akkor mi SpeedyCGI-t használunk. Tök jó lenne ilyen dolgokról is beszélgetni a találkozón...

> Az nem biztonsagos

Biztos igazad van. Bar meg nem hallottam rola, hogy a Slashdot-ot feltortek volna.

> Igen, altalaban meguszod, ha disztribuciot hasznalsz.

Webszerveren mi mast hasznalna az ember? Regen meg en is nekialltam olyannal jatszani, hogy kezzel osszereszeltem egy LAMP-ot, de ma mar nem tennem. Van nekem rendes eletem is... Ezert vannak a disztributorok, a ports maintainerek, stb.

Nem is fejlesztik agyon. Van egy mukodo rendszer es kesz. A programozokon is sok mulik, de ha feltorik, akkor az egesz webszerverrel ok rendelkeznek. Mig, ha szeparaltan fut a program, akkor nem erik el az apache-ot.

Altalaban igen, de van, amikor neki kell allni kezzel. Debiannal eddig mindig sajat PHP, PGSQL csomagokat raktunk fel, mert a developereknek kellett az uj verzio, ami stabel-ben nem volt meg. Vagy megvolt, csak nem volt beleforditva valami.

Csak megjegyeznem: ha fent letezok igazi problemak:

- hasznaljatok AS-t (python: tovabbra is Zope), akkor nem keveredik az apache es a mod_xyz address space-ben, stb...

- tobbaszalusag egy helyen lesz kezelve, eleve tobbszalu vegrehajtas a WebContainer es DB es Http kiszolgalas szinten is

- nincs filerendszer problema mert a Zope ZODB-ben tarol mindent (virtualis filerendszer szeru ODB), sajat sokretu permission es Role kezelo rendszerrel

- ZEO : megoldhato barmilyen terheles elosztas, balancing stb... elvileg vegtelen szamu frontend -el, ecceruen

- Ha mar azon megy a vita kik hasznaljak (ZOPE+PLONE):

NATO, NASA-JPL, developer.ebay.com, Lufthansa, OSDL, Free Software Foundation, CBS New York, AARP, Rice University ECE, Oxfam America, UBUNTU.COM :-)))

( sas | 2005. 09. 16., p – 14:54 )

ez nagyon-nagyon kár !

nem lehetne áthozni a bercsényibe?

:))

Ha flame hat flame, a python szintaxisa undorito (termeszetesen ez szemelyes velemeny) tetu lassu, es mocsok sok eroforrast zabal, egyeb gond nincs vele.

Perl jo, csak az emberek gondolkodnak mashogy, ahogy a beirasod jelenti, nem a feladat a lenyeg hanem a megoldas... Gepigeny, memoria ilyen szempontbol lenyegtelen..

Csak a PHP viszi el a programozókat a Perl-től. De csak cgi a cgi. Az pedig csak az egyik megjelenési felülete a Perl-nek.

Egyébiránt a mianam hallottam, hogy az egyik barátomat egy cég kifejezetten megkérte, hogy Perl-ben csinálja mega honlapjukat, mert a PHP-val kapcsolatban volt negatív tapasztalatuk. Hopsz.. ;)

Ui.: A Perl nem a legkönnyebb nyelv, de a leghatékonyabb.

Minden nyelv masra valo. Meg akkor is, ha "altalanos celu nyelv"-nek hivjak.

Mielott a hatekonysagrol beszelnenk, nezd meg a Common Lisp, Haskell es SML nyelveket is.

Haskell-ben pl. igy nez ki a fibonacci generator:

fib = 0 : 1 : zipWith (+) fib (tail fib)

Tudom, hogy annak, aki nem ismeri a Haskell-t semmit nem mond, de megis latszik, hogy mennyire tomor. A Perl-nek is az egyik nagy elonye, hogy tomor tud lenni.

Quicksort:

qsort [] = []

qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x

where

elts_lt_x = [y | y = x]

ezen nagyjabol lehet latni, hogy mit csinal es hogyan, meg kivulallok szamara is. Nagyon analog az algoritmus matematikai leirasara. Most nezz meg egy C-ben megirt quicksort-ot :-)

> > NEM szeretnék flame-et. Csak 1 vélemény. ...

> Ha flame hat flame, a python szintaxisa undorito ...

Azert jo hogy leirtak hogy nem flame...

En is irnek egy velemenyt: szamomra python kod olvashatobb, mint perl szvsz, de ugye kinek a pap kinek a papne...

York.

Sajnos nem sikerult leirni a fuggvenyt az elobb. A lenyeg, hogy Haskell-ben sokkal olvashatobb, mint pl. C-ben. Nyilvan bizonyos szintu ismeret mindkettohoz kell, de a Haskell verzio az algoritmus majdnem 1:1 konverzioja.

De egyetertunk, a programnak olvashatonak kell lennie.

"Az nem biztonsagos, ha az interpreter a webszerverben fut. Nalam nem fut ott."

Na hát ez egy bődületes nagy baromság! Ha a webszerver-ben a perl mondjuk www-data userrel fut, akkor mi a bánattól lesz kevésbé biztonságos, mint egy másik ugyanolyan jellegű userrel futtatva?

Általában egy nagy terhelésű web-es alkalmazás fut egy apache-on, ami mást nem csinál csak azt futtatja és kész.

Te ezzel szemben azt javaslod, hogy ehelyett mondjuk FastCGI-vel adjuk át a kéréseket az apache-ból egy másik démonnak.

Ez azon kívül, hogy a FastCGI socketes kommunikációja újabb hibalehetőségeket és overhead-et hoz a rendszerbe, semmi változást nem jelent.

Persze, ha hosting-szolgáltató vagy, akkor elég baj, hogy mindenkinek a scriptje ugyanazokkal a jogokkal fut, de erre találták ki az Apache 2-ben a virtualhost-onkénti user-eket.

Nem állítom, hogy nincs probléma a mod_perl-lel, de pont az nem a biztonság!

A FastCGI-t nem a biztonsagra javasoltam, mivel mar egy CGI is kulon userkent fut.

A hangsuly azon volt, hogy apache1 alatt is futhat minden CGI sajat userrel, ami igencsak nagy kulonbseg a mod_perl/php-hez kepest, ahol www-data-kent fut, ami gyakorlatilag egyfajta super-user.

Na akkor tételesen végigveszem az érveidet:

"- az interpreter az apache address space-eben fut. biztonsagi szempontbol ez tudod mit jelent..."

Semmit nem jelent. Ha szarul van megírva, így is úgy is elszáll vagy épp feltörik, a leak-eken meg segít, ha apache-nak beállítod, hány request-et hajthat végre egy process.

"- minden process a web user jogaival fut"

A web user-nek semmi extra joga nincs, így ennek semmi jelentősége. (kivétel természetesen a hosting-szolgáltatás esete, de erre ott van apache2)

"- a mod_perl forditas mindig rizikos: perl es apache C-flag-ek keverednek (thread-es Perl vs. thread-es apache)"

Régebben sokat fordítottam mod_perl-es apache-okat, mert még nem volt ilyen a disztrókban, de soha nem keveredtek semmilyen flag-ek. Ma már nincs ilyen probléma, mert a disztróban van rendes mod_perl-es apache. Nem is éri meg fordítgatni, mert csak a biztonságot kockáztatod azzal, hogy garantáltan később ér el hozzád a patch, amivel kezdheted az újrafordítást, mint a disztrók maintainer-eihez. Ráadásul a hibákat gyakran csak a köv. nagy verzióban javítják úgyhogy vadászhatod a patchet a CVS-ből.

"- nem tudod kirakni a programot egy kulon szerverre, mivel az az apache-ban fut (load-sharing/balacing)."

Rakok mondjuk három mod_perl-es apache-ot három gépre, hogy párhuzamosan szolgálják ki a kéréseket. Slashdot, Amazon is ezt csinálja.

1. Ez olyan, mintha kernel-space-ben futtatnal user-space programokat. Szoval ne mondd azt, hogy nem jelent semmit.

2. a www-data minden ele, ami a sajat tulajdonaban van, vagyis az apache nagy reszet. ha minden CGI kulon userrel fut, akkor ha megtorik sem fer hozza az apache-hoz.

3. lasd fent, nem azert irtam a forditast, mert sok idom van, hanem azert, mert elofordul, hogy a disztos csomag nem megfelelo az adott celra. Nem azt mondtam, hogy mindig ez van, azt mondtam, hogy elofordul.

4. Lasd fent, a lenyeg az volt, hogy nem kell web szerver azokra a gepekre, ahol a web-es programom fut. Kevesebb konfigolas, kevesebb lehetseges lyuk.