Már lemondtunk róla...

...de 6 év után a GoboLinux 015 alpha megérkezett:
http://gobolinux.org/iso/

Veszélyben az LFS felhasználói tábora. :)

Szerk:

A hír felkerült a disztróvacsra. :)
http://distrowatch.com/

A telepítő el se indul, de nem baj. :)

( uzsolt v | 2014. 01. 21., k – 19:23 )

De semmi hír nincs róla, még a főoldalon sem. Taxy-taxy, te nagyon gyanús vagy nekem :)

( T_chris | 2014. 01. 21., k – 20:32 )

Most, hogy poli nem használja esküszöm kedvet kaptam hozzá. :)
Egy virtuális próbát megér. :)
- - - - - - -
"Nagy kár, hogy az informatika abba a korba ért, hogy lehet nyugodtan pazarolni az erőforrásokat." Saxus

Szerintem előbb kaptam erről hírt mint bárki más. Persze hogy fel vagyok iratkozva a hírlevelükre, még szép... De olvasd csak el, alant mit írtam, mennyire nem bírok magammal a kitörő örömtől, mennyire túlteng bennem a roppant érdeklődés...

Hozzáállásomra jellemző, hogy be se küldtem hírként ide a HUP-ra treynek...

( poliverzum | 2014. 01. 21., k – 20:53 )

Túl késő ez már nekem. Én már biza megmaradok a magam kreálta „szörnyszüleménynél”... Nem tudom különben, linkeltem-e már ide az elkészítéséről szóló tutoriált? Inenn tölthető le, bocs ha már volt:
http://parancssor.info/dokuwiki/doku.php?id=hogyan_keszithetsz_sajat_di…

Megjegyzem, nem tartom kizártnak hogy hátha amiatt történt némi mozgolódás gobóéknál ezügyben, mert én elkezdtem pattogni, megcsináltam a magam „disztróját”, s erre esetleg elkezdtek szégyenkezni vagy mittudomén... Persze ez nem biztos, de nem is tartom lehetetlennek.

Mindenesetre, valamiképp úgy vagyok ezzel hogy a fene se tudja mikor lesz ebből stable, de ha hamar lesz is, a következő releasera majd várjak megint 5 évet?! Sajnálom, de soha többé nem vagyok képes megbízni ebben a disztróban. Le se töltöm... Ergo, ki se próbálom. Ettől azonban még örülök annak hogy kijött belőle valami új, mert így készül nyilván sok recipe is hozzá, amikből ötleteket meríthetek, ha netán valami cifrább progit kell majd telepítenem a magam disztrójába, olyat, ami nincs benne az LFS vagy BLFS Bookban. Általában ugyan meg tudom oldani már az efféle gondjaimat minden efféle „ötletlopás” és külső segítség nélkül is, de csak könnyebb és hamarabb megy, ha van honnan puskázni.

Szóval, ha valaki eddig tényleg csak az irántam érzett ellenszenve miatt nem gobózott, akkor most megnyílt előtte a pálya, mert én tényleg nem folyok ebbe bele a továbbiakban.

Van nekem más dolgom is, hehehe...

Tényleg... Igazad van, erről megfeledkeztem. Mentségemre szóljon, most teljesen zanza a fejem, mert csak a készülő programnyelvemre bírok gondolni. Természetesen annak is lesz egy könyv szentelve (javában írom) ami ezáltal útmutató lesz azoknak, akik saját programnyelvet óhajtanának írni maguknak.

Szóval elismerem, igazad volt, ezúttal Te voltál a Nagy! (Nagy Vilmos...)

Persze, az hogy a változóknak neve van az már túl konformista megközelítés. Akik kitalálták ezt, előbb át kellett volna gondolniuk még egyszer.

(Bár gondolom ennek mélyebb okai lesznek. Felesleges nevet adni a változóknak, mert ez nem logikus. A változónevek úgysem adják vissza a dolgok jelentését, gondoljatok csak bele. Hát nem? Az ilyen kényelmi szempontok, mint hogy az ember agya mire áll rá jobban, magánügy!)

A változók neve a program lefordítása után érdektelenné válik. (Ne próbáljuk elfedni a lényeget a debugging, és egyéb ördögtől való funkciókra való hivatkozással!) Egy tisztességes programot általában hosszabb ideig használnak, mint effektíven a megírására fordított idő, így a program élettartamának nagyobb részében a változónevek lényegtelenek. Az pedig különösen jó, hogy ha már maga a programnyelv is csak arra fókuszál, ami a felhasználónak is fontos. A programozónak ugyan kicsit nehezebb lesz a dolga, de ő ezért fizetést kap, tehát fogja be a száját, vagy keressen más munkát.

----- 

(&%;_98\<|{3W10Tut,P0/on&Jkj"Fg}|B/!~}|{z(8qv55sr1C/n--k**;gfe$$5a!BB]\.-

Őszintén szólva belenéztem a fenti szálba, a közepén levő instant brainfuckot a változónévvel megnéztem, megállapítottam, hogy ez az én szempontomból hmm, tökéletesen érdektelen, és nem vettem a fáradtságot, hogy a hosszas többi izét is elolvassam.

Viszont ha interpéter, ha más, a végén gépi kódnak kell futni, nincs más lehetőség. Ott meg regiszterek vannak, memória műveletek, interruptok, meg ilyesmik, változónevek ellenben meg nem. Szóval a fenti komment, hogy a user szempontjából mindegy, hogy a kódban mi van, továbbra is valid imho.

Van benne némi igazság... Amennyiben ez tulajdonképpen egy „virtuális gép” lesz igazából, de olyan, ami meglehetősen „magas szintű” nyelven lesz programozva. Az elv az, hogy ne kelljen holmi magas szintű nyelvből előfordítást végezni a virtuális gép assembly nyelvére, hanem „kitapogatom”, mi az a „magas szint”, amelyen megalkotva egy programnyelvet, az még épp „közvetlenül értelmezhető” egy interpreter számára, anélkül, hogy ez jelentős sebességlassulást eredményezne.

Most jöttem rá hogy tényleg igazam van.
Oktatási célra kiváló lehet ez a cucc, így elképzelés alapján legalábbis. Mint a Logo. De ahogy azt sem, ezt sem fogják használni komolyabb projektekhez. Sőt ezt még annál is kevésbé. Csak azért mondom, nehogy illúzióid legyenek.

Turing gépre sem írnak komoly programokat, mégis tudomány ágak épülnek rá. Ez lesz a Poli gép.

Természetesen ha elkészül, arról blog az oldalamon, a http://parancssor.info oldalon lesz. Most még nincs. Sőt tulajdonképpen ha elkészül akkor se lesz róla olyan „igazi” blog, mert inkább könyv formájában teszem közzé. Természetesen ingyen.

Javában írom különben, egyszerűbb dolgokra már működik is. Most ott tartok, hogy magának a nyelvnek a fejlesztését félbehagytam, csak azért, hogy az eddigi részekről megírjam a könyvet, mondhatjuk tehát azt is, hogy jó alaposan dokumentáljam az eddigi munkát. Természetesen a magam bőbeszédű, szájbarágós stílusában. Ami azonban kifejezetten helyes ezesetben, tekintve hogy e programnyelv legfőbb haszna a szememben nem is az lesz hogy azt hinném, ezzel megváltom a világot, hanem hogy bemutatom a rendszerközeli dolgok fejlesztése iránt érdeklődő mindenkiknek, e speciális feladat során mint egy programnyelv elkészítése (s amit a legtöbben rém bonyolult dolognak tartanak, de szerintem teljesen indokolatlanul) itt tehát mikre kell gondolni, miféle területeken kell döntéseket hozni, melyik döntésnek mi lesz a következménye, stb, szóval ez a könyv a legkifejezettebben épp arra van, hogy könnyen emészthető legyen és nem valami „rém komoly” szakkönyv, hanem aki elolvassa, még ha azután nem is ír saját programnyelvet soha, akkor is utána egészen másképp tekint majd a compilerek és interpreterek világára, nem tartja majd őket valami titokzatos „feketedobozoknak” (bocs ha a „fekete” nem elég polkorrekt...), jobban átlátja majd, mi történik „ott a mélyben”...

Ennek ellenére, a könyv címe az, hogy „Hogyan írhatsz saját programnyelvet”.

Azt meg hogy „jobb lesz mint a C”, természetesen félig humornak kell érteni. Ebből legfeljebb annyi lesz az igaz, hogy a C, az ugyebár nem interpreter típusú, ez meg leginkább mégiscsak afelé közelít. Ugyanakkor, reményeim szerint az interpreter típusú nyelvek közt jóeséllyel ez lesz majd a leggyorsabb. Ha elkészül, szívesen várok majd ötleteket arra, miként lehet ezt mindenféle tesztekkel ellenőrizni is.

Ami a változók nevét illeti: amíg egy programban csak 3 változó van, addig a

KUTYASZIN
változó persze intuitívebb mint a @$A0.
Ha azonban van 300 változód, úgyis táblázatot kell írnod magadnak, melyik mire szolgál, s akkor nekem aztán biztos teljesen mindegy, hogy a változó neve
@SZIN123
vagy @$A2

De a részletekről itt nem is bocsátkozom vitába. Máshol sem. Nem vitatkozni akarok hanem alkotni. Majd ha kész lesz, úgyis megírom nektek a könyvem linkjét, addig felesleges erről elmélkedni... Annyi még, hogy a könyvemből 27 oldal már meg is van.

> Javában írom különben
Mivel már másodszor használod ezt a szófordulatot, és a mondatkezdés miatt mindkét helyen alapból nagybetűvel, [rosszul emlékeztem] már komolyan felmerült bennem a kérdés, hogy Javában vagy már javában írod. :)

> Ha azonban van 300 változód, úgyis táblázatot kell írnod magadnak,
Neeeeem. :D Ez a nagyon-nagyon szarul felépített kód definíciója.

Na látod, épp az ilyesmik miatt hiszik egyesek, hogy a programnyelvírás valami szörnyen bonyolult dolog! Mert az erről szóló művek hétszentség hogy ilyesmikkel kezdik szikkasztani az Olvasó agyát, hogy BNF és AST.

Megjegyzem a BNF-et még talán értem is, miért emlegeted, de hogy az AST-nak mi köze lenne az én nyelvemhez amikor fentebb említettem hogy ez nem compiler hanem interpreter típusú lesz, arról tényleg gőzöm nincs. Amennyire ismerem ezeket a dolgokat, az Abstract Syntax Tree arra való, hogy az általad begépelt forráskód kifejezéseit fa formában ábrázolja. A fordító azzal kezdi, hogy ezt „felrajzolja”, majd ebből később a gcc nyelvfüggetlen fákat csinál, és azon végzi az optimalizálást, s csak ezután generálja a futtatható állományt. (Ha tévednék, bocs, de ezt én is az „Álmoskönyvből” szoptam...)

Na most hogy egy interpreter és nem compiler típusú nyelvnek ez mire lenne jó, azt el nem tudom képzelni.

Nézd, én örülök ha tisztelsz netán mert olyasmit művelek ami a szemedben rémségesen komoly, de elárulom, hogy TAPASZTALATOM SZERINT egy programnyelv megalkotása messze KÖNNYEBB, mint egy nem is különösebben szinvonalas játékprogramé.

Hogy mást ne is mondjak, gondolj bele, alapvetően csak szövegfeldolgozásról van szó: Ott a forráskód, abból kell kutyulnia valamit! Játékprogram esetén viszont törődnie kell a grafika és hang programozásával is, meg ha szörnyek vannak azokat mozgattatnia kell valahogy valami démonnal vagy a megszakításrendszerre rákötve vagy akármi, ütközéseket vizsgálni, stb. Nem is lehet kérdéses, melyik feladat a könnyebb.

Miért, sorról sorra (utasításról utasításra) interpretálod a forrást? Vagyis ha van egy szintaktikai hiba egy olyan kód blokkban, ahová sohasem jut el a vezérlés, akkor arról nem is keletkezik hibaüzenet?

Pl. a php is egy interpretált nyelv, aztán mégis AST-t akarnak használni. Le is írja, hogy a jelenlegi megoldással bizonyos dolgok nem megoldhatóak.

Egyébként egy másik topicban volt szó arról, hogy szerinted azzal, hogy az egészet leírod, mindenképpen jót teszel. Ez szerintem csak akkor igaz, ha a témát megfelelően körüljárva, a szakma által elismert és alkalmazott módszereket bemutatva és felhasználva teszed. Ahogyan pl. egy szakdolgozatot illik elkészíteni. Ha nem így jársz el, lehet, hogy működő dolgot kapsz, de az biztos, hogy a módszer nem lesz megismételhető és semmilyen haszonnal nem jár az olvasó számára.

Már megint ezzel jössz, amivel a disztróm megalkotásakor is jöttetek! Hogy „nem lesz megismételhető”! Hogy a búbánatos francba ne lenne az, amikor ott a leírás a disztrómról, látod, minden utasítás ott szerepel, s hozzá bőséges egyéb leírás is, azaz nem volt igaza a károgóknak!

Ez a helyzet a programnyelvemmel is. Előszöris: Ott szerepel majd a teljes forráskód. C/C++ kevert nyelven írom. Emellett minden picit is bonyolultabb részlet ki van elemezve igazán szőrszálhasogató bőbeszédűséggel a könyvemben, hogy:

1. mit csinál
2. hogyan csinálja
3. miért kell azt egyáltalán megcsinálni
4. miért épp úgy a legjobb megcsinálni és nem másként

márpedig én „alapesetben” is bőbeszédű és szájbarágós vagyok szerintetek, most képzeld milyen lehet az ha már én magam is annak tartom a stílust! Mindezt a félreértések elkerülése végett, s a „gyengébbek kedvéért”. Ha ezek után valaki nem tudja utánamcsinálni, az ne programnyelvet készítsen hanem fogpiszkálót, az talán neki való és nem haladja meg a képességeit.

Azt se értem, miért kéne „utánam csinálni”. Ott a forráskód, azt nem utánamcsinálni kell mert már kész van, maximum lefordítani. A lényeg épp az lenne, ha a leírás alapján valaki készítene egy másik nyelvet, ami a saját szája íze szerint való, de épp emiatt MÁS mint az enyém, ezesetben azonban szó sem lehet utánamcsinálásról, mert az már ÚJAT ALKOTÁS! Legfeljebb ötleteket meríthet a művemből (ez is a lényege annak!), de akkor is el kell térjen tőle többé vagy kevésbé.

És igen, nemhogy sorról-sorra, de kis túlzással egyenesen karakterről-karakterre interpretálom a forrást! Asszem valami ilyesmit erről már valahol korábban is emlegettem itt a HUP-on. Emiatt nyilvánvaló, hogy ha valahol van olyan utasítássorozat amihez valamiért soha nem tud eljutni, akkor azt soha nem is hajtja végre, ergo soha nem is elemzi, tehát ha abban van valami szintaktikai vagy akármiféle más jellegű hiba, az soha a büdös életben nem is fog kiderülni!

Azt nem értem csak, ez miért lenne baj. Engem nem zavar akármennyi hiba sem, ha az úgyse okoz bajt, mert soha nem hajtódik végre... Az emberi genom is teli van hibás szakaszokkal (ami azt illeti, génláncunk nagyobbik hányada ilyesmi) ami azonban semmi bajt nem okoz, mert soha nem fordítódik le a fehérjeszintézis nyelvére. „döglött gének”.

Említettem már korábban talán, hogy ha ennek van egyáltalán valami konkrét célja és haszna az „oktatási” szinten túlmenően, akkor az az, hogy egy baromi gyors interpretert akarok megalkotni, olyat, ami majdnem gépi kódú sebességgel fut, de emellett:

1. Egyáltalán nem végez semmiféle előzetes optimalizációt a kódon, azaz nem fordítja le a forrásnyelvet holmi „köztes” nyelvre, mert ő maga a forráskód az a pszeudo-nyelv, az a „virtuális assembly” amit végrehajt,

2. Ahhoz képest hogy ez egy kvázi-assembly és ezért marha gyors, ahhoz képest a lehető legmagasabb szintű, ami még éppen megoldható ilyen feltételek mellett.

Na most az igazi gépi kódú állományokon se végez ugye a processzor a végrehajtása előtt holmi elemzést, helyes-e szintaktikusan vagy máshogy. Nekikezd végrehajtani, s ha valami gebasz történik közben, leáll és kiabál hogy baj van. Oszt' ennyi. Miért is kéne nálam másképpen lennie ennek?! Az isten szerelmére drága gyermekeim, aki másképp gondolja annak teljesen kibicsaklott a szemlélete! Az efféle dolgokat hogy a kód hibás-e, nem az interpreternek kell ellenőrizgetnie minden futás előtt, hanem a PROGRAMOZÓNAK, még mielőtt a programját kiadja a keze közül éles felhasználásra, mindenféle olyan eszközökkel, melyek nem is kéne hogy a program felhasználójának a rendelkezésére álljanak! Ilyesmi pld a debugger, a lépésenkénti programvégrehajtás, meg egyéb más okos mindenfélék, de LEGFŐKÉPPEN: a megfelelő tesztkörnyezet megteremtése, azaz kipróbálni a programját minél változatosabb bemenő adatokkal meg szituációkban!

Na ez az, amit a programozók elmulasztanak. Lusták a tesztkörnyezet kialakítására. Ellenőrizgessen a szerencsétlen interpreter ugyebár!

Hát NEM! Én teljesen nyiltan bevallom, hogy nyelvem tervezésekor a legislegfőbb mérce a hatékonyság, ennek szinte minden mást alárendeltem. Talán csak egyet nem: hogy könnyen lehessen bővíteni a későbbiekben. De ez az utóbbi szempont is csak korlátozott mértékben van figyelembe véve. Na meg olyan csúnya dolgokra is igyekeztem ügyelni, nehogy segfaultokkal szálljon el cifrább esetekben. A kód szépségére is ügyeltem, de ez nálam csak annyit jelent, hogy egyetlenegy warningot se tartok megengedhetőnek, annak ellenére, hogy ezen opciókkal fordítom:

CFLAGS = -funsigned-char -funsigned-bitfields -Wall -Wno-long-long -Wextra -pedantic -Wunused

A programozónak nálam maximális szabadsága van, ebből következik viszont az is, hogy maximálisan képes elkövetni akár a legmaximálisabb hülyeségeket is. Az ő dolga. Nehogy már a „szisztém” okosabb legyen mint aki használja! A tököm tele van azzal, hogy manapság mindenki úgy véli, meg kell óvjuk a júzert a saját hülyeségeitől. Például majdnem összefostam magamat meglepetésemben amikor kiderült, hogy a frissen telepített Debian rendszerem nem engedi rootként indítani a grafikus felületet. Az istenszerelmére, én vagyok a rút rót, nekem MINDENHEZ jogom kell legyen! Oké, lökjön a pofámba egy figyelmeztetést hogy ez szerinte nem bölcs dolog. Aztán majd én eldöntöm, vállalom-e ezt a kockázatot. De hogy slusszpassz NEM ENGEDI?!

Nálam szabad lesz hülye kódot írni is. Nyilván persze jó ha vannak módszerek az idiótaságok elkerülésére, de azok már nem a programnyelv részei kell legyenek. Azok már olyan dolgok, amik egy MÁSIK PROGRAM, valami „kódelemző” vagy „kódoptimalizáló” vagy hasonló nevű program feladatai, és marhára semmi köze se kell legyen a tulajdonképpeni interpreterhez.

A következőre gondolok:

Tegyük fel a nyelvemben leírható az a sor, hogy

A = 2 - B + B;

Te azt gondolod, az interpreter dolga hogy ezt felismerje valamiképp, és ne is foglalkozzon a B változóval, hanem nyugodjon meg abban, hogy A = 2 van itt. Én nem így gondolom. Mindenekelőtt: Lehet hogy a B egy volatile változó. De ha tutira nem az, akkor is, nekem az interpreter ne szörcsöljön azzal, hogy olyasmiket keres, HÁTHA rosszul írta a programozó a programot! Ennek végülis kevés az esélye. Ha azt a programot egymilliószor hajtjuk végre, mind az egymilliószor ellenőrizget hogy hátha rossz?! Mitől lenne rossz a tizedik alkalommal, ha előtte kilenccszer már jó volt?! A tupamaró gerillák bevetettek egy pszicikus látnokot aki szellemi ráhatással a távolból megváltoztatta a forráskód bájtjait az elmúlt éjszakán, „táv-hackeléssel” a „táv-gyógyítás” mintájára, vagy mi a szösz?!

Nem. Az interpreter csak ne ellenőrizgessen. ILYESMIT NE. Van amit kell ellenőriznie, de efféléhez semmi köze. Ezt a programozó küszöbölje ki, úgy, hogy alaposan végigbogarássza ő maga a kódot, illetve ha van neki erre kihegyezett célszoftvere, azt végigfuttatja a kódján, a forrásprogramon annak terjesztése előtt, s majd az a progi megtalálja az efféle hibákat. Ha az nem képes megtalálni ezeket, vélhetőleg az interpreter se lenne képes rá. Az interpreter dolga a VÉGREHAJTÁS, a lehető leggyorsabban. Ő arra való. Más dolgokra más szoftverek valók. Nem helyes ezeket egybekutyulni, mert már Murphy is megmondta:

„Többféle célra is alkalmas konyhai gép egyetlen feladatot se lát el tisztességesen”.

Arról nem is beszélve, hogy a feladatkörök egybemosása szöges ellentétben áll a KISS-elvvel.

Megismételhetőség alatt nem egészen ezt értettem. Ebben az esetben ezt úgy kell érteni, hogy a project során alkalmazott módszerek egy másik (hasonló, de más terméket előállító) project során újrafelhasználhatóak. Lásd Capability Maturity Model 2. szintje.

Tegyük fel, hogy írok egy olyan programot, ami mindössze 10 sor, és van benne egy ciklus, aminek a futásideje 1 hét. Ha a cikluson belül van egy olyan feltétel, ami csak az utolsó napon értékelődik ki igazra, és annak blokkján belül van egy szintaktikai hiba, vagy a ciklus után van egy szintaktikai hiba, akkor 7 napi munka megy a levesbe. Ehhez képest ha az interpereter elvégzi a szintaktikai ellenőrzést, azzal mindössze pár ms-t vesztek.

Bináris esetén nem igazán van olyan, hogy szintaxis. Ha pl. van egy alignment hiba (x86-on változó hosszúságú utasítások miatt), a processzor gond nélkül értelmezné a hibás kódot. Aztán ha olyan utasításba fut bele, amit végképp nem tud végrehajtani, akkor arról keletkezik kivétel. Tehát a processzornak esélye sincs, hogy "szintaktikai" hibát találjon, mert nincs is igazán szintaktika.

Az a helyzet, hogy összemosod a szintaktikai hibákat a szemantikaiakkal. Utóbbit valóban a programozónak kell kiküszöbölnie, mert csak ő tudja, hogy tulajdonképpen mit vár a programtól, az interpreter ezt nem tudja (pont, hogy a kódon keresztül tudja meg, amiben a hiba van). Ellenben a szintaktikai hibákat meg tudja találni, hiszen azt már tudja, hogy milyen szintaxist vár, ezért ez az ő dolga. Azt írod, legyen külön program a szintaktikai ellenőrző. Akkor felmerül a kérdés, hogy miért interpretált a nyelv, hiszen ha elvégzem a szintaktikai ellenőrzést előre, akkor akár le is lehetne fordítani a kódot, és akkor az interpreter már nem is kellene. Vagy ha hordozhatóságot szeretnél, akkor fordítson gépfüggetlen bytekódra, amit egy interpreter sokkal gyorsabban fel tud dolgozni (lásd Java, .NET).

Az a szó, hogy optimalizáció, mond neked valamit?
Szerinted egy interpreteres nyelv futtatója hogy működik?

Egy normális, modern fordító megírása lehet egyszerűbb, mint egy játéké, de közel sem olyan egyszerű, mint ahogy elképzeled.
Ja! Egy új nyelvet kitalálni (használhatót) végképp nem triviális dolog.
Írom mindezt úgy, hogy valamikor próbáltam megismerni a fordítók lelkivilágát.Részben szakkönyvekből, részben forráskódok alapján. (IBM 360 Assembler és COBOL volt az „áldozat")

Mondok egy meglepo dolgot, az interpreteres nyelvek 99%-a hasznal AST-t (a PHP nem). Ennek reszben optimalizacios okai vannak (fel tudja terkepezni a helyben kifejtheto fuggvenyeket (ami gyak. 1-2 utasitas, azt felesleges ugrassal meghivni, hanem inkabb behelyettesiti), ki tudja szamolni es behelyettesiteni a konstansokkal valo alapmuveleteket (hogy ne kelljen a valtozo eloszedesevel bajlodni a futtatas soran), erzekelni tudja a vegtelen ciklusokat, es meg ezer mas dolgot tud csinalni), reszben pedig az, hogy meg mielott a futasba belekezdene, kepes legyen egy szintaktikai ellenorzest vegrehajtani, hogy ne a program kozepen deruljon ki, hogy a tobbi resze olvashatatlan/ertelmezhetetlen/hibas.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( bviktor | 2014. 01. 21., k – 23:05 )

- The Installer (especially its Qt based GUI) has not been tested yet

Most mar megvan, miert volt erte oda poli. Ha csak ugy siman "mukodne", semmi erdekeset nem talalna benne, nem lenne mivel elbaszni az idejet.

There is a big error/mistake in your mind/brain. Amíg gobóztam, többnyire a nem grafikus installert használtam. Továbbá, akkoriban az még igenis ki volt próbálva b+viktorkám!

Különben is, mit érdekelne engem ez a GUI, amikor tudod rólam hogy konzolmániás vagyok, de ha GUI-zom akkor se szeretem a Qt alapú bloatware szarokat?!

Jelenleg meg please read above, mit írtam: ki se fogom próbálni, le se töltöm e verziót...

( uid_19334 | 2014. 01. 22., sze – 14:36 )

szvsz az ilyeneket inkabb a turkaloba kene kuldened