2009 végére 52 millió brazil tanuló férhet hozzá Linux-hoz és KDE-hez

Open Source

Az elmúlt napokban több helyen - köztük az ismert KDE hacker Aaron Seigo blogjában is - felbukkant a hír, miszerint Brazília nyílt forrású programcsomag nagyszabású telepítésébe kezd. A program lényege, hogy a brazil általános iskolai oktatási rendszerben a Linux és a KDE lesz "a" szoftver platform. Elsőre ez merész állításnak tűnhet, de a számok önmagukért beszélnek.

Ez év végéig 32 millió tanulót kiszolgáló 29 000 laborban kerül a szoftvercsomag telepítésre, ahol meg is kezdik az aktív használatot. 2009 végig a tovább bővül a program, több mint 53 000 lab fog kiszolgálni 52 millió tanulót.

Linux Educacional 2.0

A telepített rendszer Debian alapokra épülő "Linux Educacional 2.0" és KDE 3.5 lesz.

Részletek itt és itt.

( Yorirou | 2008. 04. 26., szo – 19:12 )

ilyet kérek a jézuskától magyarországra is :)

( mofli | 2008. 04. 26., szo – 19:19 )

Növekedik a felhasználók száma, növekedik a potenciális fejlesztők száma. Ez tetszik :)

Az "olvasmányosság" csak egy feltétel a sok közül - csak példaként írtam -, python szerintem rossz példa, pl. az utasítászárójelezés hiánya (illetve megkerülése az indentálással), a gyengén típusossága, a hivatkozásszámlálós-szemétgyűjtős memóriakezelés, a más nyelvektől eltérő for ciklus, mind-mind megakadályozzák, hogy rendes tanulónyelvként lehessen alkalmazni. A Pascal ebből a szempontból mindenképpen jobb választás, pl. a változók kötelező deklarációja rákényszeríti a tanulót, hogy végiggondolja, hogy milyen erőforrásokra lesz szüksége az algoritmus lekódolásához (ráadásul megfelelő típusú változókat kell választania). Úgyhogy szerintem egy kezdőnek mindenképpen az egyik legjobb választás, az más kérdés, hogy milyen módon használják az iskolákban a Pascalt és mennyi idő alatt lendülnek túl rajta.

Meglepődtem néhány éve, amikor egy számtech. középiskolában tanuló egyik ismerős kislánynak segítettem a Pascal házi feladatában, és közölte, hogy nekik a tanárnő azt mondta, hogy a könyv első 200 oldalát - amely gyakorlatilag a nyelv pontos leírása volt az adattípusoktól a vezérlési szerkezeteken át az alapvető függvényekig - nem kell tudni. Én meg azt mondtam neki, ha programozó akar lenni az első 200 oldalt úgy olvassa, mintha a Bibliát olvasná, és álmából felriadva is tudja az ott leírtakat. Hogyan lehet valaki jó programozó, ha a használt nyelv elemeit nem tudja felhasználni a problémamegoldás megfelelő pontján?

Bocs a hosszú offtopicért. :)

init();

Szerk.: Ja, és én is C/C++/Java, csak úgy éreztem meg kell védenem a Pascalt, mert szerintem helye van az oktatásban.

Ha programozót akarunk képezni, akkor meg C. Igaz, kicsit mélyvíz, de egyszerű algoritmusokra tökéletes, ráadásul, ha párhuzamosan asm is van mellette, akkor legalább nem egy elméleti hátulgombolós "szakember" lesz belőle, hanem sejtése lesz arról, hogy mit csinál.
Ha középiskolában akarunk algoritmusokat tanítani, meg egyszerű programozást, arra egy scriptnyelv tökéletes, mert azon a szinten felesleges vesződni a típuskezeléssel meg a memóriafoglalással. Vagy python helyett Java, és akkor legalább valami használhatót is tanulnak.

Szerintem először gondolkodni kell megtanulni. Aztán késöbb johet egy programnyelv. Nemszeretek magammal példálózni, de én ebből a könyvből keztem megtanulni a programozást: http://szakkonyvkereskedes.hu/shop_artdet.php?shop_id=2973&cikk=termek_…
Nincs programnyelv. Ami van: pszeudokód, logika, algortmustervezés, és gonolkodásra ösztönöz. Ezek az alapok után jöhetnek a programnyelvek. Amugy a C - Pascal vitában énis inkább a C-re szavazok.

Mi idén (11. osztály) kezdtünk (nagyképű vagyok: kezdtek) el php-t tanulni pascal mellett. Furcsa, hogy az osztály nagy része jobban szereti a (szerintem hulladék) pascalt (ezt 9. óta nyomatják, ráadásul jó fej (és nem mellékesen csinos) a tanárnő :)). Bár talán nem a nyelv a hibás, hanem a php-t oktató tanerő. Kb. annyi egy óra, hogy valami főiskolai jegyzetet olvas fel, és a példákat ki kell másolnunk és ki kell próbálnunk. Ráadásul a jegyzet hamarabb oktatja a gettype, settype és vardump fv-ket, mint az if, for, (do) while utasításokat (hmm, hogy is hívják ezeket? :)).

Nem, de az ilyen-olyan "rákkeltő"-zős propagandaarcok is kátrányból készült úton közlekednek, vagy legalábbis nem hallotam még, hogy szolidaritásból a Mercedesükkel földutakon repesztenének autópályák helyett.
Sajnálom, hogy nem fogtad fel a mondanivalóm lényegét.
It doesn't matter if you like my song as long as you can hear me sing

Ember, tényleg szedd össze magad (ezt fogadd baráti jótanácsként, tehát menj, rúgj be, szedj össze valami ellenkező nemű lényt stb.), mert kezdesz elpoliverzumosodni, ugyanis beírsz valamit, és nem tetszik, hogy más esetleg kritizálja, és észérvek helyett hisztizel, mint egy fürdősk***a.
Bocs, én tényleg jót akarok, úgyhogy ne vedd személyeskedésnek.
It doesn't matter if you like my song as long as you can hear me sing

Most itt elsősorban a kátránnyal dolgozó emberekre értettem, de amikor 50+ fokra felhevül az aszfalt, akkor azért párolog belőle rendesen a sok karcinogén.
Egyébként mennyire leszel PHP-fanboy azért, mert egy PHP-s oldalra írogatsz? :-)
It doesn't matter if you like my song as long as you can hear me sing

Ismerve a jelenlegi középfokú programozói képzést, úgy vélem, hogy nagyon nem helyes ami jelen pillanatban ilyen téren megy.
Szerintem érdemesebb, egy diáknak az alapoktól megtanulnia az egész programfejlesztést, beleértve a fordítók használatát, debugolást, idegen kód olvasását. És egy élő, a hétköznapi életben eladható (java, c, c++, c#) nyelv oktatása ilyen téren sokkal előnyösebb, mert aki azt tanulja 2-3 év előnnyel fog indulni a munkaerő piacon, de nagy segítséget jelenthet neki a felsőoktatásban is. (Pl. Barokkosan más életérzés, amikor szembetalálja magát egy mikrokontrollerel az ember és nem akkor kell neki elkezdenie a "C for dummies" könyvet, mert egész ezidáig csak Pascalozott.)

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Elég baj lenne, ha valaki programozóként eladhatná magát a munkaerőpiacon a középiskolai oktatás után.

Aki tud programozni, annak nem 2-3 év egy újabb (és a pascalnak majdnem 1:1 megfelelő) nyelv megtanulása.

(És azoknak, akik a középiskolában tanulnak némi programozást, a 99.9 %-a életében nem fog mikrokontrollert programozni, ha egyáltalán tudja, hogy mi az.) Az alap középiskolai oktatás (nem fakultáció) némi alapot ad mindenből, és nem a felsőoktatás egy részét hozza előrébb, és nem szakembereket képez. Ez kb. minden tantárgyra igaz, nem lehet mindenkiből minden területre szakembert képezni.

A Pascal szerintem jó oktatásra, és ez akár azt is jelentheti (főleg a kevésbé érdeklődőknél), hogy a Pascal, majd C út könnyebb, mint rögtön a C.

Utasítászárójelezés?

Jó hogy nem mindjárt pontosvessző a sor végén :-)

Mint a sötét középkorban :-)

Nade egy kicsit komolyabban válaszolva: Szerintem meg pont fordítva.

Pascalban a jó stílus (az olvasmányosság miatt) az indentálás + a begin/end. Ebből a begin/end az olvashatóságot nem növeli, csak az ostoba fordítónak kell, mert egyébként nem tudja, hol egy blokk (honnan is tudná). Ha a kettő közül az egyiket elhagyod, a másikat kötelezővé teszed, hogy marad olvasható a kód?
Igen, indentálással.

A gyereknek tök mindegy, hogy zárójelez, vagy nem, azt kell megtanulnia, hogy vannak blokkok, és a blokkokat így kell jelölni...

Az, hogy nem kell a memóriakezeléssel szórakozni, egyértelműen pluszpont. Ugye egy kezdőről beszélünk, aki éppen algoritmusokat tanít. Nem kernelt ír, nem memóriakezelést hakkol, hanem mondjuk buborékrendezést próbálja megvalósítani.

A változók típusosságán lehet vitatkozni. Szerintem felesleges, de persze ostoba az a programozó, aki ugyanazt a változót mondjuk a program egyik részében ilyen, máshol meg olyan típusú adat tárolására használja.

Viszont mondjuk egy listánál baromi jó az, hogy bele lehet tenni bármit. Számot, szöveget, másik listát, ilyen-olyan objektumot.

Egy láncolt listához pascalban már egy csomót kell programozni, hogy egyáltalán működjék, pythonban meg lehet a megvalósítandó algoritmusra figyelni, nem a környezetet megteremteni (ugyanaz, mint a memóriakezelés)

G

En 7 evig hasznaltam Turbo Pascalt.
286-oson 5 evig, assembly nelkul kurva lassu.
Turbo C -vel pepecselni jobb lett volna, de amikor elkezdtem nem is tudtam, hogy van olyan is.

Egy pascal2C fordititas kozben, Set, es String ami erdekes lehet, a tobbi csak szebb,rovidebb, jobban atlathato kodot eredmenyez.

A pascal, nem egyszerubb.Ha elekzdel pointerezgetni egy halal a C-hez kepest.

Bloatware kategoriaert, inkabb az olyan okatatasi formak felelosek amik nem beszelnek arrol ,hogy mi menyibe kerul. Egy ket nyelvben ezt igyekeznek is elrejteni, akik ilyenen tanulnak, nem tudjak mitol lesz lassu, memoria evo a kodjuk.

Bár én a C "híve" vagyok a Pascallal szemben, de alapvetően nem tetszik a C záróbájtos "string"-je. Úgy vélem hossztárolós stringekkel alapvetően többre lehet menni - már amiatt is, mert rögvest ott a hossz, nem kell görcsölni a meghatározással. És 255 karakteres string igenis ELÉG a legtöbb esetben - hisz mit tárolsz stringben: személyneveket, városneveket, stb. Ha mégis úgy érzed, hosszabb string kell, ott a C++ és csinálsz erre egy olyasmit, hogy

class BigString {

private:
unsigned int hossz;
unsigned char *IdePakolom;

};

és persze a megfelelő függvényeket is meghatározod hozzá, ami igazán nem nehéz. Akár operator-overloadinggel is. Ez annyira nem nagy ördöngösség, hogy még én is megcsináltam, pedig egészen biztos, hogy csak hobby-programozó vagyok egy igazi profihoz képest.

És így már a max hossz lehet 65535, ami elég szép. De megadhatsz akár unsigned long int-et is hossz-nak, ha olyan perverz vagy...

A záróbájtos izémizé szóval egy hülyeség. Semmiképp sem úszod meg ott sem a méretkorlátot, egyszerűen mert a pointerek nem alkalmasak végtelen nagyságú memória megcímzésére. Akkor meg olyan mindegy, pláne mert a hossz rengetegszer kell majd neked úgyis a programban mint adat.
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

256 karakter nem mindig elég, főleg 2008-ban. Pl. most is írok egy programot Delphiben, ami webről kap adatokat, helyből több kbyte-s streamokat rakok át stringekbe.

A nem 0 byte-s stringnek egyébként - ha jól tudom - előnye a gyorsaság (ugye tudjuk hol a vége, nem kell keresni, hossz visszaadása pl. O(1) alatt megvan, stb.), hátránya, hogy több memóriát foglal és limitálva van a mérete. Bár nem látom értelmét pl. 32 bitnél hosszabb leírót adni, 4G-s stringgel elég ritkán találkozik az ember.

Több memóriát foglal? Mennyivel? Tegyük fel 100 ezer stringet használsz egy progi egy futása során. Záróbájtos stringnél ez a hossz jelzésére (=záróbájt) 100 ezer bájt elhasználása. Ha az én módszeremet használjuk unsigned int hossztárolással, akkor a hossz tárolására elhasználsz 200 ezer bájtot, ami pont kétszerese az előbbinek. Ez plusz 100 K. A mai memóriaméretek mellett tökéletesen jelentéktelen mennyiség. De ha unsigned long int változót használsz hossztárolásra, még akkor is csak 400 K megy el e célra, ami 300 K-val nagyobb mint a záróbájtos baromkodás, ami még mindig csak egyharmad mega, azaz még mindig elhanyagolható. Továbbá, így lehetőség van rá, hogy mert ismered a stringnek lefoglalt tárterület méretét, ha nem kell a string, annak a területét felhasználd egy másik string tárolására, amennyiben annak a hossza kisebb vagy egyenlő mint a már nem szükséges string hossza, s így ügyes módon lassítod a memória defragmentálódását és a sebességet is megnöveled, mert nem kell újabb memória lefoglalásával s a felesleges stringek memóriájának felszabadításával bajmolódnia a rendszernek.
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Azért ennyire nem triviális.

Az int (pascalban integer) adattípus meg manapság már 32 bit. (Bár ez platformfüggő, de maradjunk az x86-nál). Szóval nem 200k, hanem +300K többletet jelent. Másrészt egy mai CPU gyorsabban dolgozik 32 bites számokkal, mint 16 bitessel. Nem véletlen az, hogy egy 1..10 közötti for ciklushoz is inkább int-t használnak, mint byte-t.

Másrészt, ha reallokálod a stringet (példádban ugye rövidítés volt), semmi nem garantálja, hogy ugyanarra a memóriaterületre kerül.

Harmadrészt: mikor ezeket kitalálták, akkor nem voltak még azért gigabyte-s modulok (az informatikában meg nagyon keményen be tud tokozódni a visszafelé-kompatibilitás). Turbo Pascal-t eredetileg DOS-ra fejlesztették, keményen ott volt a 64K-s segmensméret-limit, ebbe ugye elég korlátozottan férnek bele a dolgok. Itt nagyon nem mindegy, hogy néhány kbyte-val mi történik.

Ezen kívül ha jól értem, te úgy gondolod, hogy ha mondjuk van egy 200 byte hosszú stringed, és átírod a hosszát 100 byte-ra, akkor a hátsó 100 byte fel van szabadítva. Nem lesz.

Ezen kívül stringekkel van egy további komoly probléma. Eddig ugye mindenki úgy állt hozzá, hogy karakter = byte. Holott ez ma már egyáltalán nem igaz. Azt, hogy a különféle iso-8859-X -l való bajlódás az vicc, arra már régen rájöttek. Az UTF-8 ebből a szempontból szép meg jó, csak hiába írod be, hogy x byte hosszú, egyáltalán nem következik az, hogy az x karakter hosszú lesz. Szóval egy programban nehéz vele dolgozni.

Másik megoldás az UNICODE. (.NET használja pl. a stringekhez). Előnye, hogy minden karakter fix hosszúságú (2 byte), könnyű vele dolgozni, de mégiscsak max 64K különféle karaktert képes kezelni, szemben az UTF-8 néhánymilliójával szemben.

Nem értettél meg. Ha én magam definiálok egy mondjuk "BigString" osztályt, ott én szabom meg, milyen változó legyen a hosszjelző mező. Ha én azt írom, unsigned int, akkor annyi legalábbis biztos a mai gépeken, hogy minimum 2 bájtos lesz. Engem nem zavar ha 4 bájtos, de 2 bájtos biztos lesz.

Aztán, nem képzelem, hogy ha átírom a hosszat 200-ról százra, a hátsó 100 fel lesz szabadítva. Ekkora lámaságot ne tételezz fel rólam, ENNÉL azért én is profibb vagyok! Hanem arra gondoltam, ha van mondjuk egy efféle osztályod:

class BigString {
unsigned int hossz;
unsigned char *IdePakolom;
};

s ennek van mondjuk egy unsigned int Hossz(void); metódusa a hossz lekérdezésre, akkor ebből csinálsz egy tömböt valahogy így:

BigString eredeti[1000];

ezt feltöltöd adatokkal, ehhez persze valamiképp lefoglalod az IdePakolom pointer által mutatott memóriaterületeket a szükséges méretekre, ami mindegyik stringnél más. Aztán mondjuk az a munka, hogy e stringeket névsorba rendezd. És tegyük fel kétféleképp is, mondjuk a szokásos módon, meg úgy is, hogy a string vége felől nézve. (Ez csak egy hirtelen példa, sok másféle feladat is lehetséges). És tegyük fel, az eredeti tömb meg nem kell már neked a rendezés után. Logikus, hogy csinálj egy újabb, BigStringekből álló tömböt, ebbe pakold a mondjuk szokásos módon névsorba rendezett stringeket, majd ezen új tömböt rendezed a másik módon, és a vége felöl rendezett stringeket tartalmazó tömböt úgy oldd meg, hogy az így rendezett stringeket az eredeti tömbbe pakolod, de úgy, hogy az aktuális indexű tömbelemen levő (már nem szükséges) string hosszát előbb kiolvasod, s ha kisebb vagy egyenlő mint amit bele akarsz írni a tömbelem azon részére, akkor egyszerűen bemásolod oda, s a hossz értéket átírod a megfelelőre. (Így megoldod az egész feladatot 3 tömb helyett mindössze 2-vel). Könnyű belátni, hogy átlagos esetben 50% esélyed van rá, hogy ezt így megteheted, mert véletlenszerűen kiválasztva 2 stringet 50% az esély rá, hogy mondjuk épp az első string kisebb vagy egyenlő hosszúságú a másodiknál. Azaz az esetek felében nem kell memóriafelszabadítással és új területfoglalással vackolódnod. Ez NEM jelenti az újrafelhasznált tömbelem nem szükséges bájtjainak azonnali felszabadítását, de azt jelenti, hogy különben igenis fel kéne szabadítanod és új területet fogalnod. Pld, ha ész nélkül egyszerűen minden már nem szükséges tömbelemet felszabadítasz és újat allokálsz, akkor az eredeti[i] tömbelemnél, ha az mondjuk 80 bájtos, fel kell szabadítsd e 80 bájtot, és le kell foglalnod egy mondjuk 60 bájtos területet. Így ahogy én mondom, egy egyszerű hosszellenőrzés, bemásolod az első 60 bájt helyére a stringet és átírod a hosszat 80-ról 60-ra. Megspórolod tehát az eredeti[i] elem felszabadítását s egy új lefoglalását, annak ellenére, hogy természetesen marad ott egy 80-60=20 bájt nagyságú kihasználatlan terület a végén. De az majd felszabadul akkor, ha amúgyis felszabadítod az egész eredeti[i] elem IdePakolom pointerét, ha máskor nem hát legkésőbb a progi befejeződésekor.

-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Épp az UTF-8 terjedése miatt nincs értelme a záróbájtos stringekkel görcsölnünk. Normálisan úgy kell megoldani a karakterkezelést, hogy

class betu {
...
};

és nem holmi záróbájtos stringet használunk, hanem

class karaktersorozat {

unsigned int hossz;
betu *IdePakolom;

};

és kész! Illetve, ebből csinálhatunk tömböket is, stringtömbök helyett:

karaktersorozat NagyonFontosTalánUTF8banKódoltAdataim[SokSokString];

Aztán hogy a "betu" osztálynak mi a belső felépítése, a kutyát sem érdekli! Ha tisztességesen követjük az objektumorientált programozás alapelveit, akkor nem fogunk az osztály privát mezőiben kívülről turkálni, és csak a publikus tagfüggvényeket hívogatjuk. Lehet, hogy valami ISO-kódlap formában van benne az adat, 1 bájton tárolva. Lehet hogy UTF-8 vagy Unicode-kódolással. Marhára nem számít. Ha megváltozik a kódolás mert valami más környezetbe visszük át a progit, csak a "betu" osztályt kell átírnunk, minden egyéb része a proginak használható marad átírás nélkül is. Sőt, akár talán valami futásidőben hozzárendelődő okosságot is lehet kitalálni, hogy felderítse, épp most miként vannak kódolva a betűk, s aszerint hívogassa a függvényeit a betu osztály, s így eleve le is kezel minden variációt ő maga. Virtuális tagfüggvény, asszem ez a neve, bár még nem éltem vele. De ismétlem ez az ő dolga, a betu osztályé, nehogy már a string osztály törődjön vele! A stringünk betűket tartalmaz, ennyit tud. Nem kell tudja, a betű hány bájtos. Az a betű dolga.

-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

JAJ! Ezt azért gondold át, de nagyon, mert ez így mind nagyon szép, de brutális megvalósítás. Hiába objektum orientált a .NET és a Java, ott is vannak primitív típusok (pl. int, char és hasonló), amik igaz, hogy kifele osztályként látszanak, de nem durvítanak be ennyire.

Kezdjük azzal, hogy ha te minden egyes karaktert egy osztályként akarsz lekezelni (C-ben és hagyományos Pascalban már eleve bukta, mert azok nem OOP nyelvek) akkor valami brutális nagy memóriafelhasználás és fragmentáció lesz a vége. Ha te egy tömbben tárolod le az egyes karakter osztályok pointereit, akkor karakterenként bőven lehet számolni egy 8-12 byte-val, ami csak az osztályok kezelésére megy el (ha te osztályokból csinálsz egy tömbböt, azok a HEAP-ban nem folytonosan fognak elhelyezkedni, a tömbben csak az egyes osztályok címei szerepelnek). Arról nem is beszélve, hogy mekkora brutális nagy CPU idő kellene enek kezelésére. Még ma is.

Sebesség szempontjából még mindig a legjobb valamilyen konstans méretű primitív típus (.NET -ben pl. a char az gyk. egy short hosszúságú szám, de UTF-8 esetén lehetne mondjuk unsigned int, és mindent konvertálni 32 bites UNICODE-ra, bár ez is általábanosságban jó 70%-s feleslegesen lefoglalt memóriát igényelne). Ilyenkor ugye el lehet érni lineálisan a karaktereket a tömbben (string másolésa pl. mehet memcpy() -vel, nem kell midnen egyes karaktert egyenként(!) külön(!) megcímezni, arról nem is beszélve, hogy ha az OOP egységbezárást is be akarod tartani akkor még egy függvényhívás is bejön a property lekérdezésekor).

(Így megoldod az egész feladatot 3 tömb helyett mindössze 2-vel).

Rendezés hogy jött ide? Egyébként: rendezést meg lehet oldani egyetlen egy tömbbel is. HA nem kell az eredeti tömb, akkor célszerű oda berendezni (megvan már, fix mérete, nem kell megint lefoglalni - a memóriafoglalás elég lassú művelet!). Van nagyon sok szép algoritmus, ami n+1 memóriaigénnyel O(n*log(n)) idő alatt berendezi neked a tömbböd). Szerintem nézz utána a rendezőalgoritmusoknak.

Ha mégis nagyobb a célstring, mint amekkora kell, akkor se vagy előrébb. Ha nem szabadítod fel azt a 20 bytet, akkor az elveszett. És azért hülyeség, mert nem az adatot, hanem a Stringet fogod áthelyezni (jelen esetben ez ugye a string címének átadása, ld. tömbök működése: ha nem primitív, konstans adattípus, akkor a tömbben a cím fog szerepelni). Egyébként is OOP paradigma szerint is az objektum(referenciát/mutatót) fogod átadni, nem az adatot.

De saját magadnak is ellentmondasz:

Aztán, nem képzelem, hogy ha átírom a hosszat 200-ról százra, a hátsó 100 fel lesz szabadítva.

Így ahogy én mondom, egy egyszerű hosszellenőrzés, bemásolod az első 60 bájt helyére a stringet és átírod a hosszat 80-ról 60-ra. Megspórolod tehát az eredeti[i] elem felszabadítását s egy új lefoglalását, annak ellenére, hogy természetesen marad ott egy 80-60=20 bájt nagyságú kihasználatlan terület a végén.

Neharagudj, de szvsz. nem igazán vagy képben azzal, hogy mikor mi adódik át, tárolódik, mik azok az OOP paradigmák, stb.

Ne haragudj, de szerintem abszolút másról beszélsz, mint amiről én. Például feleslegesen kevered bele, hogy stringnél általában címeket adunk át. Ezt én is tudom. De ELŐFORDULHAT olyan eset, amikor igenis másolni kell "fizikailag" a teljes stringet, s ha akkor egy amúgyis korábban már lefoglalt memóriaterületre másolod, aminek adatai amúgy nem kellenek, akkor megspórolsz egy memóriafoglalást. nyilvánvaló.

"Szerintem nézz utána a rendezőalgoritmusoknak."

Imádom az efféle beköpéseket, amikkel úgy tünteti fel valaki, mintha a beszélgetőtársa hülye volna. Képzeld, ismerek egypár rendezőalgoritmust, egyet ráadásul énh magam találtam ki. TUDOM, hogy van helybenrendező algoritmus is. Én szándékosan nem olyan példát hoztam fel, mert így meg tudtam magyarázni (Legalábbis ez lett volna a célom...) hogy mire gondolok a stringek esetében. De nem is vitázom erről tovább, mert mintha nem akarnád érteni. Nézd, szabad világban élünk állítólag, ha neked annyira a záróbájtos stringek tetszenek, használd őket egészséggel!

Amit arról írtál, hogy az én betű/karakter megoldásom memóriazabáló és lassúbb, mint a primitív típusok használata, abban természetesen teljesen igazad van. Mégis, ez az egyetlen IGAZÁN biztos módja annak, hogy a problémát korrektül oldjuk meg. Másképp csak gányolás az egész, és hibalehetőségek végtelen sora...
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

"Például feleslegesen kevered bele, hogy stringnél általában címeket adunk át."

Miért lenne felesleges? Te hoztad az adatmásolást fel, mikor az általad hozott osztály példányában másoljuk a karaktereket (amiből te még egész nyugodtan objektumot is készítenél). Mit csinálsz akkor, ha van egy pointer a stringre (vagy egy karakterére?) Azok nem fognak átíródni, rosszabb esetben felülíródik az eredeti adat és máris kész az unhandled exception.

"Imádom az efféle beköpéseket, amikkel úgy tünteti fel valaki, mintha a beszélgetőtársa hülye volna. Képzeld, ismerek egypár rendezőalgoritmust, egyet ráadásul énh magam találtam ki. "

Tehetek róla, hogy te hoztál hülye példát? Azt mondod logikus? Végiggondoltad te mit csinál az az algoritmus?
- Lefoglalsz egy n hosszúságú tömbböt. (malloc és tsi, keressünk neki helyet, stb.)
- "szokásos" rendezés meg nem tudom mi. Olyan nincs. Ha most arra gondolsz, hogy végigmész a tömbön, kikeresed a legkissebbet, aztán átkopizod az új tömb első elemére, aztán nézed tovább a második legkissebbig, akkor az az egyszerű cserés rendezés azzal a különbséggel, hogy új tömbbe teszed. Csak itt még a másolással is eltöltesz egy rakás időt.
- Ezután (az egyébként már rendezett tömböt) nem kis munkával visszamásolod az eredetibe.
- (Arról nem is beszélve, hogy ha minden egyes karaktert is példányosítani kellene, akkor annak brutálisan nagy CPU és memória igénye lenne, fragmentációról nem is beszélve).

Ennél még a legprimitívebb egyszerű cserés rendezés is nagyságrendekkel gyorsabb, és cserekor nem primitív adattipus esetén gyk. pointer-totojgatásról van szó. Azokhoz képest meg hol van pl. egy QuickSort.

Az ilyenekből látszik, hogy nem értesz hozzá.

"Mégis, ez az egyetlen IGAZÁN biztos módja annak, hogy a problémát korrektül oldjuk meg."

Nem tudom, hogy hol igazán biztos megoldás a probléma korrekt megoldására, mikor fényévekkel erőforráskímélőbb megoldások vannak.

Azt viszont nem értem, hogy honnan jött az, hogy én a \0 végű stringek híve vagyok? Szerintem a legjobb megoldás még mindig az, mikor a stringet, mint egy karaktertömb kezeljük és megszabjuk hogy a karakter az unsigned short, (vagy ha nagyon kell az UTF-8, akkor unsigned int). Egy tömbnek mindig tudjuk a hosszát, elemei közvetlenül elérhetőek egy lépésből, (mivel primitív típusról van szó, ezért a memóriában folytonosan fognak elhelyezkedni az alkalmazás számára) címzés a tömb_kezdete + (index * típus_hossza) módon elvégezhető, nem kell ilyen hülyeségekkel foglalkozni, mint első karakter memóriacímének kikeresése, osztály kikeresése a memóriában, osztály megállapítása, adattag lekérdezése ("adatrejtés" ugyebár), azon belül tényleges karakter lekérdezése, aztán ugyanezt az összes többivel.

Egyszerűen nem hiszem el, hogy ennyire értetlen vagy. Ez már direkt dolog a részedről. Egészen másról beszélsz, mint amiről én írtam, s közben olyan hülyeségekkel vádolsz, amikről nem is beszéltem, csak te magyarázod bele a postomba őket.

Azt hiszem felesleges a további kommunikációnk, mert szándékosan nem akarod érteni amit írok, éss szándékosan próbálsz a válaszaiddal hülyének feltüntetni engeem, ismétlem olyasmik miatt, amik csak a te belemagyarázásaid.
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Mégis miről beszélnék?

Elindult itt azzal, hogy az újabb Pascalokban is \0 végű stringek vannak.

Itt jöttél (többek között) azzal, hogy a régi Pascalos megoldás híve vagy és hoztál egy osztályt példának, meg 256 karakternek a legtöbb esetben elégnek kell lenni.

Itt írtam, hogy 2008-ban annyira nem biztos. Meg megemlítettem a nagyobb méretet.

Erre te jössz azzal (a stílussal, amire a többiek azt mondják, hogy bicskanyitogató), hogy "Több memóriát foglal? Mennyivel?" Ne akard már megmagyarázni, hogy a 2 meg a 4 nem több, mint az 1. erre írtam, hogy ezt nem ma találták ki és miért annyi az annyi. Postod végén elkezdtél zagyválni a string átméretezésről és a memóriadefragmentációról, holott bárki, aki kicsit is tudja hogy működik ez, az tudja, hogy a stringműveletek új stringet adnak vissza.

De még ugyanannál a postodnál is jól látható az, hogy ilyen alapdolgokkal, mint hogy ma 32 bites az integer x86-n, nem vagy tisztába.

Visszatérve a postodra adott válaszomra: itt hoztam fel azt is, hogy komolyabb probléma az, hogy mikor egyre inkább igény van a nemzetközi karakterkódolások támogatására, még mindig ott tartunk, hogy karakter = byte.

Itt azzal jöttél, hogy nem értelek, merthogy a saját osztályodban te szabod meg, hogy milyen változó lesz az (gondolom típust akartál írni, de sebaj). Viszont ha készítesz két-három különböző méretű Stringosztályt, akkor még számold bele az ezzel járó adminisztrációt is. Továbbá itt említetted, hogy egy string "átméretezésekor" (ami még mindig nem az eredeti stringen, hanem egy újon történik), felszabadul a 100 byte, de a postod végén már kihasználatlan byte-król beszéltél.

Az meg csak most esik le, hogy ami "C++" kódot írtál ebben a postodban, az mekkora baromság. Ez a betu *IdePakolom; ez egy(!) datab betűre mutató pointer, nem többre. charnál ugye a pointer+1 az a következő karaktert mutatja, mert primitívek sorban vannak (ez történik, ha pl. a második karaktert olvasod ki egy stringből és mindegy, hogy milyen string az). De ha te itt a betu osztályra próbálsz egy pointer+1 -s olvasást elvégezni, akkor egy nagyon ronda segfaultot fogsz kapni. Ha írni próbálod, akkor meg szimplán teleszemeteled a memóriát. Ide tömb kell (és akkor már majdnem ugyanott vagyunk, amit én mondtam).

Amit utána írtál az mind szép és jó, csak teljesítmény szempontjából katasztrófa. Egyébként a privát mezők védelmét adatrejtés elvének és ált. property-ken keresztül szokták megvalósítani az elérésüket (bár tény, hogy kész kód szempontjából függvény).

Ezután fejtettem ki, hogy miért hülyeség az osztályos megoldásod. Meg az előtte lévő postodban a rendezés.

Itt meg még mindig nem értem, hogy miért lenne felesleges a pointerezés (ugye előző postomban említettem, hogy azzal egyszerűbb, csak hogy tartsuk az ok-okozati összefüggést a postok tartalma között). Fényévekkel gyorsabb 1x4 byte-t totojgatni, mint egy egész stringet. Azt meg nem írom le újra, hogy mennyi esetben kerülne bele egy lefoglalt BigString osztályba a stringed, 2x már megtettem, csak ebben a postban.

Utána sok konkrét ellenérvet nem hoztál már fel, "az én módszerem az IGAZÁN megváltás" és a "másképp gányolás az egész" (hogy mi bajod azzal, hogy egy fix hosszúságú tömbben tárolunk teszemazt konstans 2 byten tárolt karaktereket, azt azóta se árultad el).

Itt meg válaszoltam a postodra. Még idéztem is, ne mond már, hogy nem látod a logikai kapcsolatot: első bekezdés a pointerre, második arra, hogy márpedig tényleg hülyeség a rendezés (bár úgy se fogod elismerni), harmadik rész meg arra, hogy hiába állítod, hogy igazán üdvözítő megoldás, egy nagy bloatware gány az egész, mert egyszerűbben, töredék CPU igénnyel meg lehet oldani ugyanazt. Az pedig akárhogy is nézzük, jobb megoldás.

Itt meg szimplán próbálsz terelni, hogy semmi logikai kapcsolat nincs a válaszaimban a postjaidra. Na ne mond már.

Foleg a rengeteg cast miatt, ez fp -ben is megmaradt.
Az oktatasban meg meg mindig TP van es ott meg rajon seg,ofs,ptr,addr akarmik.

(Hasznaltam Delphi-t is kylix -et is, FreePascal -al kesobb talalkoztam, C/C++ utan nem latom ertelmet, ma hasznalt programok kozul elnyoszo ami tartalmaz pascal kodot, talan nem veletlenul)

"Foleg a rengeteg cast miatt, ez fp -ben is megmaradt."

Lehet. Használtam pointereket Free Pascalban, volt már vagy 2 éve, nem emlékszem arra, hogy kényelmetlen vagy logikátlan lett volna. (Az pedig nem árt, ha az ember odafigyel arra, hogy valami milyen típusú. Változóknál is kikapcsolhatnánk a típusellenőrzést, nem sok értelme lenne.)

"Az oktatasban meg meg mindig TP van es ott meg rajon seg,ofs,ptr,addr akarmik."

Az szerintem is gáz, hogy az oktatásban TP-t használnak. (Bővebben itt. Tulajdonképpen nem tudom, hogy most mit tanítanak, majd megkérdezem a kisebbeket.)

anno alaposan beleastam magam, a korabeli tc nemnagyon fordit gyorsabb kodot, mint a tp, persze az alapdolgok; foleg a stringkezeles teljesen mas, az alapkonyvtarakban ez elegge tukrozodik is, de ha jol megnezed, a tcbe egy csomo dolgot a tpbol emeltek at, meg a mogotte levo kompilalt kod is igencsak hasonlo.
meg mondjuk a tp -t elegge lekorlatozta, hogy igencsak az msdoshoz szabtak, unitmeret ugye max 64K adatszegmens osszmerete max 64K ; a tc-ben asszem a large modellnek felelt meg, de hat ugye ott valaszthatott az emberfia, hogy mostakkor ne legyen large, hanem small, medium, huge ; na ugy mar volt meret es sebessegkulonbseg is.
amugymeg szerintem peldaul a kodteruletre mutato pointerre sokkal elegansabb megoldas ez a deklaracio

var hivdmeg : procedure(par : word);

mint a c mindenfele csillagos trukkje, ugyan a fordito nehezmenyezi, ha ugy hivod, hogy nem wordot adsz at a parameterben, viszont a stack overflownak is kisebb az eselye.

es akarhol latok lassu meg memoriaevo kodot, azt valahogy mind c-sek csinaltak.

normalis ember budos eletebe nem lattot pascalba irt programot

Normális ember vagyok, de olyan helyen dolgozom, ahol a 90-es években szinte az összes programot Turbo Pascal-ban készítette a fejlesztő cég, és időnként bele kell nézni a forráskódba. Én nem szeretem, de ma is fejlesztünk pl. Delphi-ben (ami ugye mégiscsak egy OOP-vel megpofozott Pascal).

szal mi az ertelme azt eroltetni?

Nem kell erőltetni, de oktatási célokra jó. És nem tudhatod hol találkozol vele véletlenül. Felütöd pl. Andrew S. Tannenbaum Számítógép hálózatok c. könyvét - ami ugye egy alapmű -, és lám, milyen nyelven vannak a példakódok: Pascalban.

init();

normalis ember == end user
van szerinted pascalba irt program amit mindennap hasznalnak? nincs
miert kene oktatasi celra hasznalni? ha ugyse fogja tenyleges hasznat venni, ott van a c* python perl ruby php, pl szerintem meg a php erdekelne is a gyereket csinaljon maganak egy kis sziteot persze html/css vel fuszerezve.
--
blog.sartek.net

hogy jon ez ide?
//sajat velemeny
persze h nem erdekli az end usert h mibe van irva -- persze vannak kivetelek pelda: tomboy egy kis szar program es kell neki 100 kilo mono.. es meirt? mert c# buzi irta, szepen meglehetett volna csinalni C be, es gyorsabb is lett volna
maskull itt hupon se lattam pascal os allas hirdetest (igen. nem 6 eve vagyok regelve es nem olvastam el mindent)
szal en nem latom ertelmet pascalrol beszelni se.. majd ha lesz olyan tantargy h a programozas tortenete ott megemliteni ennyi :)
tanuljunk c* ot vagy akarmek leszarmazotjat aminek ertelme van.

//sajat velemeny
--
blog.sartek.net

"hogy jon ez ide?"

Ezeket írtad: "normalis ember budos eletebe nem lattot pascalba irt programot"
"normalis ember == end user"
Konklúzió: "end user budos eletebe nem lattot pascalba irt programot"
Viszont azt, aki programozást tanul, miért érdekelné, hogy mint end user miben írt programokat használ? Az ő programját (középiskolai oktatás után) pedig úgyse fogja end user használni.

"mert c# buzi irta, szepen meglehetett volna csinalni C be"

Ennek ellenére sokan szokták Pascal helyett Java-t, C#-t, Python-t stb. javasolni itt. Te is C*-ot vagy akármelyik leszármazottját javasoltad - ezek nagy része interpreter vagy precompiler, compiler nyelvként csak a C és a C++ jön szóba.

"szal en nem latom ertelmet pascalrol beszelni se"

Középiskolai oktatás után senki nem fog álláshirdetésre jelentkezni. Az az értelme, hogy könnyebben megtanulja, így több fér bele a kevés középiskolai órakeretbe, és mégis lát valamit a programozásból, és esetleg nem is megy el a kedve az egésztől. Ha utána komolyabban programozást tanul, úgyis rövid idő alatt meg tudja utána tanulni a C-t/C++-t (és a programozás tanulására fordított időnek jó esetben úgyis a legkisebb része a nyelvek szintaktikájának a megtanulása)

Go(bo)Linux. Elárulom ugyanis, hátha valaki még nem tudná: a GoboLinuxot főként Brazíliában fejlesztik... És remekül honosított brazíliai portugálra a dokumentációja... Igazából az angolon kívül legjobban épp portugálul és MAGYARUL érhetőek el a doksijai. (A portugál nem az én érdemem...) És e két nyelv alig marad el az "eredeti" angol nyelvtől a gobót illetően.

Vagyis: igen komoly esélyét látom annak, hogy mert a GoboLinux kifejezetten "hazai" disztró Brazíliában, legalább úgy, mint nálunk az Uhu, emiatt a brazil linuxosok akik most fognak kinevelődni, jelentős tömegekben ismerkednek majd meg a Gobóval is, még ha eredetileg nem is azt tanulják a suliban. Azaz a GoboLinux helyzete végeredményben drámaian erősödni fog a disztrók közt néhány év múlva. Nem állítom én sem, hogy rövid időn belül ez lesz az "alapértelmezett" disztró Brazíliában, de okvetlenül drasztikusan növekedik majd a Gobót használók "darabszáma" és százalékos aránya is a világban. Tetszik vagy sem, ez van és lesz.

-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Én lényegében mindaddig kitartottam a hazai Uhu mellett, míg meg nem ismerkedtem a Gobóval. És a váltásra kizárólag 2 ok ösztökélt:

1. Valami "barkácsolósabb" disztrót akartam, s lehetőleg forrásalapút.
2. Amint rátaláltam a Gobóra (ami épp forrásalapú...) "beleszerettem" a módosított könyvtárszerkezetébe.

De addig kitartottam az Uhu mellett. Ha lenne valami Gobo-szerű disztró ami ugyanakkor magyar, nyilván amellé pártolnék.

A brazil linuxosok meg persze nem amiatt fognak begobózni, mert a gobót éppp Brazíliában fejlesztik, hanem mert jól honosított a dokumentációja. Biztosra vehetitek ugyanis, ott se mindenki tud angolul, de aki igen, az is szívesen veszi, ha többnyire anyanyelvén olvasgathatja a fontos dolgokat. S ha valami mégsincs portugálra lefordítva, megkérdi anyanyelvén a brazil fejlesztőt, s az nem angolul válaszol majd neki... Ez roppant előny.

-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Jogos, én is azt szeretem frugalware-ben, hogy magyarul tudok segítséget kérni irc-n. :) Bár azt hozzáteszem, hogy a dokumentáció elsősorban angol, nyilván mert ez egy nemzetközi disztró, és mert talán vannak nem magyar fejlesztők is.

Báár. A debian honosítása szerintem minden nyelven jól áll, úgyhogy a brazil (portugál) dokumentáció szerintem egyáltalán nem lehet rossz. Akkor meg minek váltsanak?

Kíváncsi leszek közülük hánynak fog tetszeni a Gobo könyvtárszerkezete, miután már éveken keresztül a "gagyi, elavult" POSIX szabványú felépítést tanulták.

Ha nem láttál volna korábban Win-t (márpedig jövőre ott kezdő kisiskolások jóeséllyel nem nagyon fognak), akkor miért váltanál erre?

Értsed már meg végre, hogy magasan szarok a Win-be!!!!!!!!!!!!!!!! Nem amiatt vagyok Gobo-párti!!!!!!!!!!!!! Egyszerűen a Gobo-féle felépítés messze sokkal logikusabb. Jó, szerény leszek, s hozzáteszem: a SZÁMOMRA. De ennek baromira semmi köze a Win-hez, egyszerűen alapvetőnek érzem, hogy ha én valami izémizét telepítek, s az több részből áll de ezek összetartoznak (emiatt alkotnak egy csomagot), akkor telepítés után is EGY helyre kerüljenek, ne mászkáljanak szét kismillió helyre a könyvtárszerkezetben.
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Osx-en mi a neve annak hogy egy program egy .app végű könyvtár, benne minden ami kellhet?
Miért nem ezt az utat követi a gobo? (Amiben úgyanúgy vannak shared libek csak a könyvtárnevek mások mint szokott)
--
the tide is turning

Alapvetően (a nemzetközi fejlesztőgárda miatt...) a GoboLinux doksijainak "alap"nyelve is az angol, de állítom neked (mint olyasvalaki aki aktív tagja a fordítócsapatuknak, így van rálátásom a témára bőven) hogy sok más nyelvre is _kitűnő_ a doksik fordítása, de e nyelveken belül is magasan kiemelkedik éppen pontosan a brazíliai portugál és a magyar. Kifejezetten e két nyelv esetén gyakorlatilag nincs semmi fontos cikk, ami ne lenne lefordítva. Egyetlen hosszabb cikkről tudok ami ne lenne meg nekik portugálul, de az abban levő infók is elérhetőek más cikkekben amik már le vannak fordítva; e cikk viszont le van fordítva magyarra. Ellenben két régebbi, már elavult doksi nincs (s mert elavult, nem is lesz) lefordítva magyarra, és van még két nem túl jelentős cikk, aminek nincs meg a magyar fordítása. Majd valamikor ha kedvem tartja megcsinálom.

(Valójában ami a magyar nyelvet illeti, e téren a portugált is lekörözzük, mert az angol GoboWikijüknek számos fontos szócikkét lefordítottam és közreadtam a könyvemben, ami portugálul úgy tudom nincs (még) meg. Persze ezek nem is fontosak a "hétköznapi" usereknek, de annak fontos lehet, aki a fejlesztésben részt akar venni. Igaz, elismerem, azok valszeg úgyis tudnak angolul).

Szóval a GoboLinux kifejezetten ragyogóan áll, ami a portugál (és magyar) anyanyelvű illetők infóhoz jutási lehetőségét illeti, tehát ha ez fontos a braziloknak, akkor a Gobo sok-sok más disztróval szemben előnyben van. No és itt nem a debiannal kell összehasonlítani, hanem egy másik FORRÁSalapú disztróval, azaz inkább aki tud róla valamit azt mondja meg, a Gentoo, Arch és LFS hogyan áll ezt illetően? Úgy értem ezek doksijai mennyire vannak "honosítva" (brazíliai)portugál nyelvre (illetve magyarra is, ha már megkérdezhetem, mert érdekel).

A Gobo ugyanis forrásalapú, emiatt a forrásalapú disztrókkal van versenyben valamilyen értelemben ezt illetően. Nem kétlem épp emiatt nemigen lesz maga a Gobo "a" brazil "nép-disztró", de azt hiszem a második helyezett szerepét simán megszerezheti ott pár éven belül. Különben is, a fejlesztők igencsak aktívnak tűnnek marketingtéren is, nemrég is volt Hishammal egy interjúja valami norvég lapnak.
-------------
Regényeim:
http://adlibrum.hu/Poliverzum/
http://www.novumverlag.hu/novitaeten/8/?product_id=22&detail=1
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

( turul16 v | 2008. 04. 26., szo – 21:38 )

52 millio tanulo, ez kvazi megduplazza a Linux falhasznalok szamat.

( xilu | 2008. 04. 26., szo – 21:41 )

kde nagyon kakukktojásnak tűník címben :)

2009 végére 52 millió brazil tanuló férhet hozzá Linux-hoz és KDE-hez

kb nem hozzáértőknek az jönne le belőle hogy a KDE is valami oprendszer :D

--
Xiluka

( Vladi | 2008. 04. 26., szo – 22:20 )

A Linux Educacional 2.0 disztrónak nincs valami oldala? Én csak híreket és blogbejegyzéseket találok. Meg ezt:
http://webeduc.mec.gov.br/
De ez nekem nagyon portugál. :)

Szerk:
Meglett: Ez az oldal, és itt az iso is. :)

( emberk | 2008. 04. 26., szo – 22:41 )

Nem semmi. Ez egy igenkomoly példa lesz. Csak figyelni kell, hog yműkodik e a dolg (bár okafogyott hogy miért ne működne), magyarországon is meg lehetne spórolni egy "kis" Microsoftadót így.

Ide tartozó hír:

Ministry of Education from Brazil is buying 90,000 Debian GNU Linux computers

Tehát ezeket az iskolai géptermeket kb. 90 ezer gép fogja ellátni?

Tesztik, hogy egy központi szerverhet 5-15 terminált csatlakoztatnak majd. Ez hasonló mint a macedóniai iskolákkba tervezett megoldás...

( vasy05 | 2008. 04. 27., v – 21:43 )

De jó lenne, ha Magyarországon is ez lenne. :))))
--
Gentoo Linux - 2.6.24-gentoo-r4