Vita a BSD grep körül

Címkék

Kövesdán Gábor munkájának nyomán jutott a FreeBSD projekt BSD licencű grep implementációhoz. A BSD grep 2010. július 22-én került importálásra a FreeBSD 9-CURRENT-be.

Az elmúlt napokban vita alakult ki a BSD grep körül, amely azzal kezdődött, hogy az egyik FreeBSD fejlesztő, Doug Barton (dougb@), hivatalosan arra kérte Gábort, hogy cserélje vissza az alapértelmezett BSD grep-et a GNU grep-re.

Doug - mint a portmaster szerzője - nemrégiben fejlesztés közben teljesítményproblémákba ütközött. Utánanézve a dolgoknak arra jutott, hogy nem az ő kódjában van a probléma, hanem a BSD grep okozza a lassulást. Feltelepítette a GNU grep-et és összehasonlította a BSD grep-pel. A tesztelésre használt script a BSD grep esetében 47 másodperces eredményt adott vissza, míg a GNU grep esetében 2 másodpercest.

Az eredmények tükrében Doug arra kérte Gábort, hogy tegye a HEAD-ben alapértelmezetté a GNU grep-et. Felhívta a figyelmét arra, hogy nem arra kéri, hogy távolítsa el a BSD grep-et a forrásfából, csak arra, hogy ne az legyen az alapértelmezett grep.

A kérés nyomán hosszabb vita kezdődött.

Volt aki szerint a -current azért van, hogy ott lehessen tesztelni. Joel Dahl azt javasolta, hogy maradjon a BSD grep az alapértelmezett még egy ideig és koncentráljanak a teljesítményproblémák javítására.

Volt aki szintén a BSD grep optimalizálásában látta az előrelépés lehetőségét. Gábor erre azt válaszolta, hogy az optimalizálás nem triviális. Lehetnek ugyan még lehetőségek az optimalizálásra, de túl sokat azoktól sem lehet várni. Azonban ha valakinek van ötlete, azt szívesen veszi.

Volt aki szerint a BSD grep nem elég kiforrott még és inkább a GNU grep legújabb verzióját kellene a fába importálni. Erre volt, aki megjegyezte, hogy a GNU grep GPLv3-ra váltott, a legutolsó GPLv2-es verzió pedig a fában van.

Voltak akik a licenc téma vonalat próbálták meglovagolni.

A thread itt kezdődik.

Hozzászólások

egy kis peccseléssel már 30 mp-nél tartanak...
szerintem.

Licencnácik bikeshedje. :))

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

még a 2clause BSD licenc is túl restriktív. sürgősen újra kell írni a teljes FreeBSD rendszert 0clause bsd licenc alatt, azaz Public domain alatt. csak az új pdBSD lehet igazán szabad:)

messzirol ranezve a cikkre azt hittem mar hogy ez is valami anti-opensolarisos cikk lesz:)

miert? mert az egyik threadban az illumos-devel listan (lenyege a threadnak: mint tudjuk jelenlegi opensolarisba van par dolog ami nem nyilt es ezeket kikene valtani valamivel, a threadba kovesdan altal fejlesztett bsd iconv rol van szo ) is feltunt kovesdan neve:)

...is feltunt kovesdan neve
Ismerős volt a neve nekem is. A BME-n általánosan jellemző rettenetes adatkezelési standardokra remek példa, hogy 1 db guglizással megtudtam róla, hogy:
- melyik tárgyakat mikor vette fel, némelyiknél, hogy melyik csoportban volt (kicsit gáz),
- néhány tárgyból tudom, hogy mikor és melyik teremben vizsgázott (nagyobb mértékben gáz),
- mi az önálló labor témája és ki a konzulense (nem baj ha kinn van), milyen jegyet kapott rá (ez utóbbi viszont kifejezetten gáz),
- mi volt a TDK témája és ki volt a konzulense (ez az egy amit kifejezetten helyesnek tartok, hogy publikusan kinn van),
- illetve egy rakás levlistára írt levele is megvan (ez megintcsak nagyon gáz)

Szerintem ha még kicsit rászánnám az időt, akkor a neptun kódja is meglenne, onnantól kezdve pedig újabb 1db guglizás és egy csomó publikusan kinn figyelő jegye is megvan. És ez csak vegytiszta google, semmi cheating belsős infókkal.

Azért ilyenkor kissé szégyellem, hogy én is ott dolgozom, még ha nem is én követtem el ezeket. :(
---
Internet Memetikai Tanszék

mert az infosheet-et nehezebb kitolteni.
Itt, Debrecenben, van olyna prof. habil. lófütty. Ph.D.(sic!), aki letelefonál a tanulmányi rendszer adminisztrátorokhoz hogy irjak be, és bediktálja. Mind a 122 hallgató aláírásait és vizsgajegyeit. Persze ezt neptunzaras napjan.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

a neptunos userneveket meg indito jelszavakat emailben kaptak, de van, amelyik meg mindig letagadja, hogy neki lenne neptun accountja, sőt, azt is tagadja, hogy egyaltalan intezeti emailcime lenne. A targyait telefonon intezteti az adminokkal (mint az elmult 40 evben), ha meg levelet kuldesz, akkor meg kapod a daemontol a quota exceededet.

nemreg atallt a DE-IK lotus domino alapu levelezesre. csakhogy olyan kurvadraga, hogy nem tudtak eleg seat licencet venni... ugyhogy van akinek van fiokja (mer az neki "jar"), s van akinek nincs (mert masodlagos... azaz meg van, a regi rendszerben, amit okkal csereltek le). gondolom kitalalod, kik azok a fontos emberek, akik elveszik a licenceket azoktol, akik hasznaljak is. pl ezert van az, hogy a legtobb fiatal tanar gmail-es cimrol intezi az intezeti dolgokat, ilyen gipsz.jakab.deik@gmail.c0m jellegu cimekrol...

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Ha jol csinaljak, akkor az mind a szakdolgozo, mind pedig a temavezeto szamara komoly szellemi ertek, ergo referencia. Talan pont az a baj, hogy az emberek altalaban megakadnak a dolgok konkret anyagi vonzatanal. Igyis-ugyis ra kell(ene) szanni azt a kb. 600 munkaorat valamire, akkor miert ne adjunk neki ertelmet...? (Gabor is ugyanezt csinalta anno.)

Neptun kód névből, anyja nevéből és születési dátumból születik. Ennek ellenére nekem valahogy más lett a suliban, mint a koliban (ott is volt külön egy neptun).

ELTE-s ETR kódban meg elvileg benne van mindenféle, de már nem emlékszem, mit mesélt munkatárs.

----------------
Lvl86 Troll

Én meg nem értem miért volt valaha zárt. Véleményem szerint senki se írjon olyan levelet egy többszázfős levlistára, amit nagy nyilvánosság előtt sem vállalna. Viszont ez részben visszatartó erő azokban, akik illegális vagy az egyetemi szabályzatba ütköző dolgot művelnek ezeken a listákon.
PS: arról nem beszélve, hogy lehet a google keresőjét használni az elbaszott sympa archívuma helyett.

szerk: nem kötekedni szeretnék, én üzemeltettem a szóban forgó szervert és kiváncsi vagyok mások véleményére.

Jó ezen én most leállhatnék vitázni, pro- és kontra érveket hozhatnánk fel addig, amíg a képernyő jobb széléig ér a thread.
Ebbe most nem fogok bele, mert off.

Csak azt gondold meg, hogy az ilyen indoklásnak, amivel te jöttél - ha elég sokan gondolkodnak hasonlóan - végül az a következménye, hogy egy sima publikus web kereséssel "facebook-os" szintű eredményeket lehet kapni az illetőről. Ezt azért ne mondjuk már, hogy rendben van.
---
Internet Memetikai Tanszék

Ezek a nem nativ angol fejlesztok elegge kerekbe torik a nyelvet, foleg az orosz srac...

Ha valami ami újabb ennyire vacakul sikerül az nem fejlesztés hanem kisérletezgetés. Nem tudom mit kell ezen vitatkozni, marad a régi jól bevált és kész. Majd ha a tisztelt fejlesztő a negyvenhét másodperc helyett hozza a négy-öt másodpercet akkor lehetne arról beszélni hogy kell-e a kódja vagy sem. Persze még mindig messze lenne a két másodperctől.

Eddig nem jött ki ez a teljesítmény probléma, mert a tesztjeim alapján elhanyagolható volt a különbség, és nem gondoltam, hogy egyes esetekben így felhalmozódhat.

Más:
- GNU grep megeszi a memóriát, embedded rendszerek fejlesztői ezért "szeretik" nagyon. A BSD grepnél ez nem fordul elő.
- Nézd meg hány soros a GNU grep, abból mennyi hülyeség. Pl. rlimitet állít be, mert egyes rendszereken a regex lib is zabálja a memóriát, vagy pedig optimizációkat eszközöl, amelyek a regex libben kéne hogy legyenek, hogy ezeket az optimizációkat minden használja, ami hozzá linkelődik, és a utilityk kódja meg maradjon tiszta. A BSD grep kódja ezzel szemben kicsi, tiszta és könnyen karbantartható.
- Az egész Ports Collection lefordult vele hiba nélkül. Ekkora tesztelés után nem volt várható, hogy még ennyi hiba felbukkan.

Mindezeket figyelembe véve indokolt és kívánatos volt a csere. Szóval legközelebb nézz is utána a dolgoknak, mielőtt beböfögsz valamit, kérlek.

szintiszta algoritmikus problema

Ebből (ha egyáltalán érvényes most a BSD grep szitura) egyáltalán nem következik, hogy "könnyű".

A konkrét probléma továbbá nem feltétlenül csak algoritmikus. Ha megnézed a freebsd wiki-ben a grep cikkelyét (valahol volt itt linkelve a témában), akkor látod, hogy specifikációs kérdések is vannak -- először is ki kellene választaniuk, hogy milyen regex változatot akarnak támogatni.

Ha jól sejtem, első körben a POSIX-ra lőttek, de hosszú távon GNU kompatibiliset szeretnének. Ha megvan a kívánt regex válfaj, akkor is rengeteg implementációs kérdés marad nyitva. Lásd például:

http://swtch.com/~rsc/regexp/regexp1.html

En mindenesetre szeretnem megkoszonni Gabornak az aldozatos munkajat. Ugy erzem, egyaltalan nem konnyu helytallni a FreeBSD -HEAD agban. Az ilyenek velejaroi a fejlesztesnek, es sokkal jobb, hogy most derult ki, mintsem a 9.0-RELEASE megjelenese utan. Lenyegeben erre is valo ez az ag, hiszen mindent valahol el kell kezdeni hasznalni szelesebb korben is. Erre egyebkent talan azt szoktak mondani, hogy nem a hiba szamit, hanem hogy ki tudod-e javitani. Es szerintem o kepes lesz ra.