🚀 go-pugleaf

Marcin Laszewski wrote:

> Zawsze sie zastanawialem, dlaczego ludzie mecza sie w perl-u
> mimo, ze to samo moga zrobic w bezwatpienia bardziej prostym
> i przjrzystym awk-u ?
> 
> W ogole to go znacie? Jest szybki i spokojnie mozna w nim
> napisac 80% cgi ktore normalnie tlucze sie w perlu.
> 
> Co wy na to?

A co tu gadać. Wygląda na to że jeszcze bardzo mało wiesz
o perlu.

--
Piotr Piatkowski, WEB Corporation Polska sp. z o.o.

Marcin Laszewski wrote:
> 
> Sadzac po obfitosci wymiany mysli, to chyba nie jest to jezyk
> bardzo popularny (no... chyba, ze nie ma o czym gadac, ale to
> w sumie na jendo wychodzi). Z tego co mialem okazje podlubac
> w perlu to w porownaniu z innymi jezykami to nie wypada dobrze:

Jednym z najlepszych produktow jest win* gdyz grupy na jego temat
maja najwieksza ilosc postow. To oczywiste.

> Daleko mu do prostej (primitywnej?) ale nie budzacej, zednych
> niescislosci skladni jezyka C, a jakos jezyk-skrypt to przyrost
> formy nad trescia - pelno w nim zapozyczonych ze wszelkich
> mozliwych skryptow elementow - dlategpo roi sie od "!@#$%^&*()_+|}{":<<>
> i innycy interpunktow. Predki tez nie jest. Nawet wsrod innych
> interpretorow (awk).

Obawiam sie, ze jest dokladnie odwrotnie.
 
> Zawsze sie zastanawialem, dlaczego ludzie mecza sie w perl-u
> mimo, ze to samo moga zrobic w bezwatpienia bardziej prostym
> i przjrzystym awk-u ?

Do wiekszosci nietrywialnych zastosowan awk ma za malo mozliwosci.

> W ogole to go znacie? Jest szybki i spokojnie mozna w nim
> napisac 80% cgi ktore normalnie tlucze sie w perlu.

Oczywiscie nie znamy awk, sed, lex, itd. gdyz za bardzo by sie
nam szystko mieszalo.

-- 
Krzysztof Murkowski
mailto:murek@ml.put.poznan.pl
http://www.ml.put.poznan.pl/~murek

> W ogole to go znacie? Jest szybki i spokojnie mozna w nim
> napisac 80% cgi ktore normalnie tlucze sie w perlu.

Jest wolny i mozna napisac nie wiecej jak 3%.
Poza tym, to co innego.
Nie znam sie na perlu, ale pisalem duze skrypcichy w awk.
Koszmar, do tego nigdy nie wiesz, na jakiej maszynie jak bedzie dzialac.
Dlatego zaczalem perla.

Pawel.

laser@priam.umcs.lublin.pl (Marcin Laszewski) wrote:
>Sadzac po obfitosci wymiany mysli, to chyba nie jest to jezyk
>bardzo popularny (no... chyba, ze nie ma o czym gadac, ale to
>w sumie na jendo wychodzi). Z tego co mialem okazje podlubac
>w perlu to w porownaniu z innymi jezykami to nie wypada dobrze:
>
>Daleko mu do prostej (primitywnej?) ale nie budzacej, zednych
>niescislosci skladni jezyka C, a jakos jezyk-skrypt to przyrost
>formy nad trescia - pelno w nim zapozyczonych ze wszelkich
>mozliwych skryptow elementow - dlategpo roi sie od "!@#$%^&*()_+|}{":<<>
>i innycy interpunktow. Predki tez nie jest. Nawet wsrod innych
>interpretorow (awk).

niezupelnie o to chodzi. perl jest b.fajnym jezykiem. bardzo ostro
nastawionym na przetwarzanie plikow tekstowych, ale z binarnymi tez
sobie radzi.

problem jest w czym innym. jak do tej pory nie ukazal sie porzadny
kompilator do perl'a. przez to perl nadaje sie do realizacji tylko
bardzo malych projektow, ktore da sie zamknac co najwyzej w kilku
modulach.

>Zawsze sie zastanawialem, dlaczego ludzie mecza sie w perl-u
>mimo, ze to samo moga zrobic w bezwatpienia bardziej prostym
>i przjrzystym awk-u ?

nie wszystko da sie zrobic w awk-u :) w perlu mozesz zrobic
praktycznie to co w C. zrobisz to latwiej, tyle ze bedzie dzialac
wolniej.

>W ogole to go znacie? Jest szybki i spokojnie mozna w nim
>napisac 80% cgi ktore normalnie tlucze sie w perlu.

wlasnie. 80% a nie 100%. a jesli ten skrpyt ma sie dopukiwac
raz do jakiejs bazy danych, raz do innego serwra WWW, to juz cienko.
awk przegrywa.

>ml

-- 
/===================================\    oOOo      W temperaturze zera
| http://avalon.wbc.lublin.pl/~znik/ \===\__/==\   bezwzglednego swiatlo
| Grzegorz Szyszlo   mailto:znik@wbc.lublin.pl |   zmienia postac
\==============================================/   alotropowa   (by Znik)

Piotr Piatkowski (kompas@webcorp.com.pl) wrote:
: > Co wy na to?
: 
: A co tu gadać. Wygląda na to że jeszcze bardzo mało wiesz
: o perlu.

A tfu... Troche tam znam. Meczylem sie w tym przez dluzszy czas
na zadupiu Europy i jeszcze mi pobyt przedluzyli, wiec moze nie
jest tak zle?

Jedno jest faktem jest interpreterem, zatem:

*	wolniejszy jak jakies C
*	mniej bezpieczny jako CGI
*	ma kiepska i nieklarowna skladnie - ktos mowil, ze
	zna lex-a, abstracujac, ze jedno ma sie do drugiego
	jak maszynka do miesa, to moze probowal kto rozmacac
	skladnie perla ? Moglby sie pochwalic osiagnieciami ?

Poza tym, zwrocie uwage, ze tak czesto wychwalane zalety Perla,
jak np. "operowanie wyrazeniami regularnymi" to zadne osiagniecie,
wszak to juz wczesniej bylo w C, tyle, ze nikt tego nie uzywa
(zbyt czesto) bo po prostu nie warto - nawet w takich zastosowaniach
jak obsluga dzikosow "*", "?", itp, gdzie wyrazenia regularne
zdaja sie byc jak najbardziej na miejscu - nie stosuje sie ich!
(kto ciekaw, niech obejrzy zrodla shell-i unix-owych).

Bazy danych - jak w kazdym innym jezyku - otworz, wykonaj, zamknij.
I co w tym takiego ciekawego? A co powiecie na obsluga np. takiego
dbm-a ? W kazdym man-e pisze, ze jego podstwowa zaleta (wsrod
masy niedogodnosci) jest to, ze moze gromadzic miliardy rekordow.
DBM-a z miliardami rekorow co prawda nie widzialem, ale obsluga,
tfu! otworzenia takiej bazy w perlu to urwanie dysku. Dla ciekawosci
zapytam: dalej sie taka baze uzywa przez wczytanie jej calej
zawartosci do tablicy ? Mi stacja robocza Sun-a siadla.

Nie chce mowic, ze perl jest do kitu, bo sa firmy ktore pisza w nim
duze programy, ale jakie ma zalety w prownaniu np. z jezykiem C 
(ograniczmy sie do programow CGI) ? Co jest w Perlu czego nie ma
w C ?

Ja pytam po prostu.

Marcin Laszewski wrote:

> Jedno jest faktem jest interpreterem, zatem:

Zdefiniujmy najpierw, co to jest interpreter. Bo dla niektórych perl
jest kompilatorem. Zanim kod wykona to go najpierw kompiluje. Nie
generuje najefektywnijszego kodu maszynowego, ale nie jest to też
stricte interpreter.
 
> *       wolniejszy jak jakies C

No tak. To dlatego będziesz pisał wszystko w C?

> *       mniej bezpieczny jako CGI

Kwestie bezpieczeństwa CGI są naprawdę w minimalnym stopniu związane z
perlem jako interpreterem. W dobrze skonfigurowanym środowisku perl nie
był nigdy bardziej niebezpieczny niż jakikolwiek inny język
programowania.

> *       ma kiepska i nieklarowna skladnie - ktos mowil, ze
>         zna lex-a, abstracujac, ze jedno ma sie do drugiego
>         jak maszynka do miesa, to moze probowal kto rozmacac
>         skladnie perla ? Moglby sie pochwalic osiagnieciami ?

Ta składnia nie jest idealna - fakt. Ale z drugiej strony można w jednej
linii zapisać bardzo dużo. Perl jest bardzo efektywnym językiem w
pisaniu, gdy ktoś już go dobrze pozna. Składnia jest zorientowana na
szybkość klepania. Zresztą od zarania dziejów mottem perl'a była
możliwość napisania wszystkiego na conajmniej kilka sposobów.

> Bazy danych - jak w kazdym innym jezyku - otworz, wykonaj, zamknij.
> I co w tym takiego ciekawego? A co powiecie na obsluga np. takiego

OK. Napisz w C coś takiego:
#!/usr/bin/perl
use Mysql;
$conn = Mysql->connect('localhost', 'bar');
$query = $conn->query('SELECT a,b,c FROM foo');
#tutaj idzie np. początek strony HTML
while( (%pole) = ($query->fetchhash()) ) {
  print
"<tr><td>$pole{'a'}</td><td>$pole{'b'}</td><td>$pole{'c'}</td></tr>\n";
}
#reszta strony HTML
undef $conn;

Jak wolisz, może być w awk, albo dowolnym innym języku. W awk może być
trudno. W C program będzie dłuższy przynajmniej jakieś 10 razy. Powyższe
napisałem z pamięci w jakieś 40 sekund (na dodatek musiałem sobie
przypominać tę skomplikowaną składnię perl'a. To teraz stosując jakiś
język o prostszej składni napisz to, w 400 sekund. Starczy?

> dbm-a ? W kazdym man-e pisze, ze jego podstwowa zaleta (wsrod
> masy niedogodnosci) jest to, ze moze gromadzic miliardy rekordow.
> DBM-a z miliardami rekorow co prawda nie widzialem, ale obsluga,
> tfu! otworzenia takiej bazy w perlu to urwanie dysku. Dla ciekawosci
> zapytam: dalej sie taka baze uzywa przez wczytanie jej calej
> zawartosci do tablicy ? Mi stacja robocza Sun-a siadla.

Chyba coś Ci się pomerdało. Odkąd sięgam pamięcią, to w perlu można było
od zawsze korzystać z dbmów tak jak z tablic asocjacyjnych. Ale to nie
znaczy, że one były w całości wczytywane do pamięci i tam obsługiwane.
Poza tym dbm'y to nie są złożone bazy danych. To są jedynie indeksy
pozwalające na poukładanie pewnych wartości według klucza. Nie służą do
niczego bardziej złożonego. Natomiast perl może również korzystać z
innych baz danych.
 
> Nie chce mowic, ze perl jest do kitu, bo sa firmy ktore pisza w nim
> duze programy, ale jakie ma zalety w prownaniu np. z jezykiem C
> (ograniczmy sie do programow CGI) ? Co jest w Perlu czego nie ma
> w C ?

Naprawdę dużo w perlu jeszcze nie popisałeś. :-)

Przede wszystkim - po to się używa języków wyższego poziomu, żeby pisać
szybciej, a nie koniecznie po to, żeby się szybciej wykonywało.
Natomiast perl jak na język, który ma zalety interpretera jest bardzo
szybki. Jeśli chodzi specyficznie o CGI, gdzie perl akurat jest dość
często stosowany, to są możliwości uruchamiania zwykłych programów CGI w
taki sposób, że dodatkowy koszt wynikający z kompilacji skryptu znika
(mod_perl). Na dodatek na zupełnie przeciętnym komputerze jestem w
stanie obsługiwać kilka tysięcy transakcji na sekundę przy pomocy
skryptów w pelu. W chwili obecnej perl zapewnia moim zdaniem jeden z
lepszych współczynników cena/wydajność.

Nie wspominając już o takich szczegółach jak olbrzymia baza różnych
dodatkowych modułów do perla. Bardzo dobra organizacja i uporządkowanie
modułów. Od modułów, które ułatwiają pisanie skryptów, dostęp do baz
danych, komunikację sieciową, gotowych agentów różnych usług po takie,
dzięki którym możesz tworzyć frontend w X-ach, renderować trójwymiarowe
obrazki w OpenGL i robić jeszcze masę innych rzeczy. I mówisz, że w awk
też tak można? Mówimy o tym samym awk?

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND

Marcin Laszewski wrote:
> *       mniej bezpieczny jako CGI

Akurat tu jest dokladnie przeciwnie.
W Perlu trzebaby sie *naprawde starac*, zeby zrobic
buffer overflow.

A wogole to najlepiej pisac w Assemblerze.
Szybszy od C, jeszcze mniej przenosny, jeszcze latwiej robi
sie w nim bledy, etc., etc.

-- 
| E-mail -> mailto:mtrojnar@ddc.daewoo.com.pl   | Michal  Trojnara |
| Strona -> http://www.daewoo.com.pl/~mtrojnar/ |   090-29-83-44   |
| CHSI   -> http://www.chsi.rubikon.net.pl/     | Jezus jest Panem |

Michal Mosiewicz wrote:

> Marcin Laszewski wrote:
>
> > Jedno jest faktem jest interpreterem, zatem:
>
> Zdefiniujmy najpierw, co to jest interpreter. Bo dla niektórych perl
> jest kompilatorem. Zanim kod wykona to go najpierw kompiluje. Nie
> generuje najefektywnijszego kodu maszynowego, ale nie jest to też
> stricte interpreter.

O ile pamiętam, Perl nie generuje kodu maszynowego, a kod pośredni, który
faktycznie jest zbiorem odwołań do dobrze zoptymalizowanych procedur
napisanych w kodzie maszynowym. Dlatego Perl jest szybki - mimo tego co
napisano kilka postów wcześniej.
Chyba że to Perl dla Windows - ten podobno jest ślamazarny.

On 98.03.04 Marcin Laszewski pressed the following keys:

> Nie chce mowic, ze perl jest do kitu, bo sa firmy ktore pisza w nim
> duze programy, ale jakie ma zalety w prownaniu np. z jezykiem C 
> (ograniczmy sie do programow CGI) ? Co jest w Perlu czego nie ma
> w C ?
> 
> Ja pytam po prostu.

To, że perla widziałeś wydaje się oczywiste. Tylko powiedz mi, pisałeś Ty w
nim kiedykolwiek jakąś większą aplikację? To na szczęście nie jest temat
religijny, jak w przypadku świętej wojny między C i Paszczalem. Ja po
prostu używam perla i zauważam, że aplikacje w nim pisane rozwija się
szybciej niż w C i znacznie łatwiej uruchamia. Ma wszystko to, czego
potrzebuję podczas pisania CGI, nawet bardzo skomplikowanych, pozwala
również w śliczny sposób budować w oparciu o mod_perl i Apache dynamiczne
strony WWW. Jeśli kiedyś będziesz musiał w pół godziny obrobić 20MB plik
tekstowy o stałej strukturze, to wtedy zrozumiesz po co jest perl.
Awk, sed i C służą do troszeczkę innych celów i jeśli jeszcze
do tego nie doszedłeś, to tego i tak nie zrozumiesz.  Jeśli szukasz
zaczepki, to idź proszę na pl.comp.sys.advocacy, tam jest miejsce na
takie dyskusje.

Gad

-- 
                                 mailto:reptile@pdi.net :)
                  Women are more complicated than PC... :(
          Look into my headers and you'll see who I am. :)

On Thu, 5 Mar 1998, Mariusz Krukowski wrote:

> O ile pamiętam, Perl nie generuje kodu maszynowego, a kod pośredni, który
> faktycznie jest zbiorem odwołań do dobrze zoptymalizowanych procedur

Ale nadal ma cechy jezyka interpretowanego, eg. mozna zrobic cos takiego:

open(F,$ARGV[0]);while (<F>) $k.=$_;eval $k;

co ma znaczenie np. przy CGI stanowiacym interfejs miedzy formatami HTML-a
na dysku + baza danych, czysto tekstowych, kazde pole o zmiennej dlugosci. 

Eg mozna np zrobic sobie cos takiego: 
w HTML-u
<! &get_rekord(1745);$result=$pole[10].$pole[16]." Hello ".$time; !>
w PERLU
$k =~ s/\<\!([^!]*)\!\>/eval $1/ge;

powinno w miejsce niby-taga wstawic wartosc podstawienia ($result)...
moglem cos skopac ale idea pozostaje ta sama.

Juz nie mowiac o tym, ze w trakcie wykonywania programu mozna sobie
dynamicznie tworzyc nowe zmienne, na podstawie np. wprowadzanych danych. 

Ciekawe jak to mozna zrobic w C ;)

> napisanych w kodzie maszynowym. Dlatego Perl jest szybki - mimo tego co
> napisano kilka postów wcześniej.
> Chyba że to Perl dla Windows - ten podobno jest ślamazarny.

ActiveWare Perl pod Windowzy jest calkiem szybki. Ale to jest subiektywne
zdanie. Moze to ja mam po prostu za szybki komputer ;)

-- 
Co było pierwsze? Jajko czy kura?       | Staszek Paśko  [ p00h ]
Dlaczego kurczak przeszedł przez ulicę? | sp174751@students.mimuw.edu.pl
Gdzie jest najbliższe KFC?              | staszek@ic.com.pl 

On 4 Mar 1998, Marcin Laszewski wrote:

> Nie chce mowic, ze perl jest do kitu, bo sa firmy ktore pisza w nim
> duze programy, ale jakie ma zalety w prownaniu np. z jezykiem C 
> (ograniczmy sie do programow CGI) ? Co jest w Perlu czego nie ma
> w C ?

W C nie moge w trakcie programu odczytac z klawiatury podanych przez
uzytkownika dwoch wyrazow, i zmiennej o nazwie=pierwszy wyraz przypisac
wartosc=drugi wyraz. Chce miec mozliwosc zrobienia tego dowolna ilosc razy.
Chce miec mozliwosc pozniejszego zkorzystania z kazdej z tych wartosci. Bez
koniecznosci tworzenia rozwiazan naokolo (Eg. tablica hashujaca).

Jak to sie robi w C?

-- 
Co było pierwsze? Jajko czy kura?       | Staszek Paśko  [ p00h ]
Dlaczego kurczak przeszedł przez ulicę? | sp174751@students.mimuw.edu.pl
Gdzie jest najbliższe KFC?              | staszek@ic.com.pl 

Michal Mosiewicz <mimo@interdata.com.pl> wrote:

>> Jedno jest faktem jest interpreterem, zatem:
>
>Zdefiniujmy najpierw, co to jest interpreter. Bo dla niektórych perl
>jest kompilatorem. Zanim kod wykona to go najpierw kompiluje. Nie
>generuje najefektywnijszego kodu maszynowego, ale nie jest to te¿
>stricte interpreter.

on robi kompilacje do pseudokodu, ktory to pseudokod i tak jest
interpretowany.

>> *       wolniejszy jak jakies C
>
>No tak. To dlatego bêdziesz pisa³ wszystko w C?

chocby dlatego ze moge mieszac C i C++ bez ograniczen. w perlu
jakos trudno sie deklaruje klasy zmiennych.

>> *       mniej bezpieczny jako CGI
>
>Kwestie bezpieczeñstwa CGI s± naprawdê w minimalnym stopniu zwi±zane z
>perlem jako interpreterem.

owszem, sa. perl ma zwykle atrubut suid, i niektorzy wykorzystuja
to do wlamywania sie poprzez www.

>W dobrze skonfigurowanym ¶rodowisku perl nie
>by³ nigdy bardziej niebezpieczny ni¿ jakikolwiek inny jêzyk
>programowania.

jak napisze cos w C, to mi to cos dziala pod www jako nobody.
w perlu niestety rozniez tym bywa. ale do malych zastosowan,
albo szybkich akcji, perl nadaje sie b.dobrze :)

a tak prawde mowiac, raczej lepiej jest zrobic kilka bibliotek
uzupelniajacych C o funkcje dostepne w perlu. dotyczy to glownie
przeksztalcania lancuchow i list. podejrzewam ze takie biblioteki
juz sa, ale sam nie szukalem.

>> *       ma kiepska i nieklarowna skladnie - ktos mowil, ze
>>         zna lex-a, abstracujac, ze jedno ma sie do drugiego
>>         jak maszynka do miesa, to moze probowal kto rozmacac
>>         skladnie perla ? Moglby sie pochwalic osiagnieciami ?
>
>Ta sk³adnia nie jest idealna - fakt. Ale z drugiej strony mo¿na w jednej
>linii zapisaæ bardzo du¿o. Perl jest bardzo efektywnym jêzykiem w
>pisaniu, gdy kto¶ ju¿ go dobrze pozna. Sk³adnia jest zorientowana na
>szybko¶æ klepania. Zreszt± od zarania dziejów mottem perl'a by³a
>mo¿liwo¶æ napisania wszystkiego na conajmniej kilka sposobów.

tak. to jest duza zaleta perla. jeszcze jedna zaleta w porownaniu z C
jest taka, ze nie mozna zgubic wskaznika co zwykle powoduje blad ochrony.

>> Bazy danych - jak w kazdym innym jezyku - otworz, wykonaj, zamknij.
>> I co w tym takiego ciekawego? A co powiecie na obsluga np. takiego
>
>OK. Napisz w C co¶ takiego:
>#!/usr/bin/perl
>use Mysql;
>$conn = Mysql->connect('localhost', 'bar');
>$query = $conn->query('SELECT a,b,c FROM foo');
>#tutaj idzie np. pocz±tek strony HTML
>while( (%pole) = ($query->fetchhash()) ) {
>  print
>"<tr><td>$pole{'a'}</td><td>$pole{'b'}</td><td>$pole{'c'}</td></tr>\n";
>}
>#reszta strony HTML
>undef $conn;

w C zajelo by to dwa razy wiecej linii. za to obciazenie pamieci komputera
byloby nieporownywalnie mniejsze.

>Jak wolisz, mo¿e byæ w awk, albo dowolnym innym jêzyku. W awk mo¿e byæ
>trudno. W C program bêdzie d³u¿szy przynajmniej jakie¶ 10 razy.

nieprawda. 2 do 3ch razy.

>Micha³

ps: co do awk, to jego uzytecznosc polega bardziej na tym, by mozna
    bylo odpalac stare makefile :) bo innego uzytecznego zastosowania
    dla awk nie widze.

-- 
/===================================\    oOOo      W temperaturze zera
| http://avalon.wbc.lublin.pl/~znik/ \===\__/==\   bezwzglednego swiatlo
| Grzegorz Szyszlo   mailto:znik@wbc.lublin.pl |   zmienia postac
\==============================================/   alotropowa   (by Znik)

Michal Trojnara <mtrojnar@ddc.daewoo.com.pl> wrote:
>Marcin Laszewski wrote:
>> *       mniej bezpieczny jako CGI
>
>Akurat tu jest dokladnie przeciwnie.
>W Perlu trzebaby sie *naprawde starac*, zeby zrobic
>buffer overflow.
>
>A wogole to najlepiej pisac w Assemblerze.
>Szybszy od C, jeszcze mniej przenosny, jeszcze latwiej robi
>sie w nim bledy, etc., etc.

>| E-mail -> mailto:mtrojnar@ddc.daewoo.com.pl   | Michal  Trojnara |

assembler to jest na zbyt wysokim poziomie. proponuje zapis
bezposredno w kodzie maszynowym (kiedys niektorzy potrafili!)
i zapisywanie wszystkego w kolumnach w HEX  :))))

-- 
/===================================\    oOOo      W temperaturze zera
| http://avalon.wbc.lublin.pl/~znik/ \===\__/==\   bezwzglednego swiatlo
| Grzegorz Szyszlo   mailto:znik@wbc.lublin.pl |   zmienia postac
\==============================================/   alotropowa   (by Znik)

Grzegorz Szysz/lo wrote:
> assembler to jest na zbyt wysokim poziomie. proponuje zapis
> bezposredno w kodzie maszynowym (kiedys niektorzy potrafili!)
> i zapisywanie wszystkego w kolumnach w HEX  :))))

Ja do tej pory pamietam co wazniejsze instrukcje 6510 w HEX.  8-)

-- 
| E-mail -> mailto:mtrojnar@ddc.daewoo.com.pl   | Michal  Trojnara |
| Strona -> http://www.daewoo.com.pl/~mtrojnar/ |   090-29-83-44   |
| CHSI   -> http://www.chsi.rubikon.net.pl/     | Jezus jest Panem |

Michal Trojnara (mtrojnar@ddc.daewoo.com.pl) wrote:
: Ja do tej pory pamietam co wazniejsze instrukcje 6510 w HEX.  8-)

A co to kogo obchodzi? Jaki ma to zwiazek z Perl-em ?

Grzegorz Szysz/lo wrote:

> >Kwestie bezpieczeństwa CGI są naprawdę w minimalnym stopniu związane z
> >perlem jako interpreterem.
> 
> owszem, sa. perl ma zwykle atrubut suid, i niektorzy wykorzystuja
> to do wlamywania sie poprzez www.

Wiesz co, to jest mniej więcej taki argument, jak ten który usłyszałem kiedys
odnosnie ssh: "ssh jest niebezpieczne, bo można się przez niego zalogować
na roota, natomiast przez telnet nie można". Na wszelki wypadek dodam, że
w ssh można wyłączyć możliwosć logowania na root'a równie łatwo jak 
to się robi dla telneta. 

P.S. Słyszałes o czyms takim jak taint checking? Jak nie, to w skrócie powiem,
     że jest to sprawdzanie na etapie kompilacji bezpieczeństwa programu.
     Np. nie pozwoli wykonać eval na zmiennej którą mógł zmienić użytkownik,
     nie pozwoli wykonać zewnętrznego programu bez upewnienia się że PATH
     jest bezpieczna, i sprawdza jeszcze całą masę innych rzeczy. Włącza się
     to automatycznie jeżeli skrypt w perlu chodzi SUID (niekoniecznie root).
     Słyszałes o innym języku z takimi zabezpieczeniami?

--
Piotr Piatkowski, WEB Corporation Polska sp. z o.o.

sooda wrote:
> 
> > W ogole to go znacie? Jest szybki i spokojnie mozna w nim
> > napisac 80% cgi ktore normalnie tlucze sie w perlu.
> 
> Jest wolny i mozna napisac nie wiecej jak 3%.
> Poza tym, to co innego.
> Nie znam sie na perlu, ale pisalem duze skrypcichy w awk.
> Koszmar, do tego nigdy nie wiesz, na jakiej maszynie jak bedzie dzialac.
> Dlatego zaczalem perla.

Heh, jest tylko jedna rzecz w której awk jest lepszy od perla.
Znalazłem to w Camel Book, niestety nie mam jej pod ręką więc nie zacytuję
dosłownie, ale chodziło (chyba) o to, że w awk'u input separator może być
wyrażeniem regularnym, w perlu jest to string. Jak napisał Larry Wall
"awk has to be better in something" :-)

--
Piotr Piatkowski, WEB Corporation Polska sp. z o.o.

Grzegorz Szysz/lo wrote:

> problem jest w czym innym. jak do tej pory nie ukazal sie porzadny
> kompilator do perl'a. przez to perl nadaje sie do realizacji tylko
> bardzo malych projektow, ktore da sie zamknac co najwyzej w kilku
> modulach.

Mógłbys uzasadnić że jedno wynika z drugiego? Bo ja nie do końca
rozumiem...

--
Piotr Piatkowski, WEB Corporation Polska sp. z o.o.

Piotr Piatkowski <kompas@webcorp.com.pl> wrote:

>Wiesz co, to jest mniej wiêcej taki argument, jak ten który us³ysza³em kiedys
>odnosnie ssh: "ssh jest niebezpieczne, bo mo¿na siê przez niego zalogowaæ
>na roota, natomiast przez telnet nie mo¿na". Na wszelki wypadek dodam, ¿e
>w ssh mo¿na wy³±czyæ mo¿liwosæ logowania na root'a równie ³atwo jak 
>to siê robi dla telneta. 

nedzny argument, fakt.

>P.S. S³ysza³es o czyms takim jak taint checking? Jak nie, to w skrócie powiem,
>     ¿e jest to sprawdzanie na etapie kompilacji bezpieczeñstwa programu.
>     Np. nie pozwoli wykonaæ eval na zmiennej któr± móg³ zmieniæ u¿ytkownik,
>     nie pozwoli wykonaæ zewnêtrznego programu bez upewnienia siê ¿e PATH
>     jest bezpieczna, i sprawdza jeszcze ca³± masê innych rzeczy. W³±cza siê
>     to automatycznie je¿eli skrypt w perlu chodzi SUID (niekoniecznie root).
>     S³ysza³es o innym jêzyku z takimi zabezpieczeniami?

tak czy inaczej, teraz na bugtraq rycza na temat babola w funkcji strcpy.
czyli suid tak czy inaczej jest niebezpieczny, i lepiej go wylaczyc.

-- 
/===================================\    oOOo      W temperaturze zera
| http://avalon.wbc.lublin.pl/~znik/ \===\__/==\   bezwzglednego swiatlo
| Grzegorz Szyszlo   mailto:znik@wbc.lublin.pl |   zmienia postac
\==============================================/   alotropowa   (by Znik)

laser@priam.umcs.lublin.pl (Marcin Laszewski) wrote:
>Michal Trojnara (mtrojnar@ddc.daewoo.com.pl) wrote:
>: Ja do tej pory pamietam co wazniejsze instrukcje 6510 w HEX.  8-)
>
>A co to kogo obchodzi? Jaki ma to zwiazek z Perl-em ?

w perlu na Z80, pewnie jest cale mnostwo rozkazow 201d , czyli RET  :)))

-- 
/===================================\    oOOo      W temperaturze zera
| http://avalon.wbc.lublin.pl/~znik/ \===\__/==\   bezwzglednego swiatlo
| Grzegorz Szyszlo   mailto:znik@wbc.lublin.pl |   zmienia postac
\==============================================/   alotropowa   (by Znik)

Piotr Piatkowski <kompas@webcorp.com.pl> wrote:
>Grzegorz Szysz/lo wrote:
>
>> problem jest w czym innym. jak do tej pory nie ukazal sie porzadny
>> kompilator do perl'a. przez to perl nadaje sie do realizacji tylko
>> bardzo malych projektow, ktore da sie zamknac co najwyzej w kilku
>> modulach.
>
>Móg³bys uzasadniæ ¿e jedno wynika z drugiego? Bo ja nie do koñca
>rozumiem...

>Piotr Piatkowski, WEB Corporation Polska sp. z o.o.

chodzi o to, ze po uruchomieniu skryptu, nastepuje proces jego kompilacji.
niestety trwa to dosyc dlugo. o ile sam skrypt chodzi z zadowalajaca
szybkoscia,
to oczekiwanie na kompilacje przy kazdorazowym odpaleniu wiekszego skryptu,
moze doprowadzic do rozpaczy. dlatego wlasnie uwazam ze perl nadaje sie
do malych naglych zadan.

-- 
/===================================\    oOOo      W temperaturze zera
| http://avalon.wbc.lublin.pl/~znik/ \===\__/==\   bezwzglednego swiatlo
| Grzegorz Szyszlo   mailto:znik@wbc.lublin.pl |   zmienia postac
\==============================================/   alotropowa   (by Znik)

Grzegorz Szyszl'o wrote:

> chodzi o to, ze po uruchomieniu skryptu, nastepuje proces jego kompilacji.
> niestety trwa to dosyc dlugo. o ile sam skrypt chodzi z zadowalajaca
> szybkoscia,
> to oczekiwanie na kompilacje przy kazdorazowym odpaleniu wiekszego skryptu,
> moze doprowadzic do rozpaczy. dlatego wlasnie uwazam ze perl nadaje sie
> do malych naglych zadan.

Mały projekt a mały skrypt to dwie różne rzeczy. Szczególnie w przypadku
projektów działających w oparciu o WWW mamy do czynienia z podziałem
projektu na bardzo dużo małych elementów.

Na marginesie, to w moich (czasem całkiem sporych) projektach tam gdzie
zależy mi na zredukowaniu czasu kompilacji, przechowuję skrypty w
postaci skompilowanej. :-)

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND

Michal Mosiewicz wrote:
[..]
> 
> Na marginesie, to w moich (czasem całkiem sporych) projektach tam gdzie
> zależy mi na zredukowaniu czasu kompilacji, przechowuję skrypty w
> postaci skompilowanej. :-)

jak to robisz ???? mod_perl czy coś  innego ?

Paweł

Pawel Gajda wrote:
> 
> Michal Mosiewicz wrote:
> [..]
> >
> > Na marginesie, to w moich (czasem całkiem sporych) projektach tam gdzie
> > zależy mi na zredukowaniu czasu kompilacji, przechowuję skrypty w
> > postaci skompilowanej. :-)
> 
> jak to robisz ???? mod_perl czy coś  innego ?

No właśnie mod_perl. Na zupełnie przeciętnym komputerze (P150) dla
średnio złożonych skryptów osiągnięcie przepustowości rzędu 100 zleceń
na sekundę nie jest niczym niesamowitym. (Dla porównania na tym samym
komputerze czas odpalenia skryptu CGI korzystającego z CGI.pm wynosi
conajmniej 0.3 sekundy)

Oczywiście jest to rozwiązanie pamięciożerne i raczej nie opłaca się
stosować globalnie. Ale tam gdzie potrzeba trochę więcej szybkości i
mamy odpowiednią ilość RAMu, to działa naprawdę nieźle.

Michał

-- 
WWW: http://www.lodz.pdi.net/~mimo  tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz  *  Bugaj 66 m.54 *  95-200 Pabianice  *  POLAND