Hozzászólások
-
Bejegyzés
-
Szerintem a Pascal nyelv tanítása zsákutcába vezet, mert:
– túl sok a megkötés (homokozó)
– egy Pascalon edződött programozó általában nehezebben tud más nyelven hatékony kódot írni (kihasználni a másik nyelv adottságait), mert megszokta a túl sok korlátot, vagy elkényelmesedett
– egyenes ágon csak a Delphi nyelv fele lehet továbblépni (C nyelvről az irány: C++, Java, PHP, C#), ezért sok fölösleges dolgot kell megtanulni, ha nem a Delphi a végcél
– a jelenlegi projektek fejlesztése 90-95 százalékban C/C++, Java, PHP vagy C# nyelven történik (a Pascal/Delphi nagyon ritka), ezért nehéz tisztán Pascal/Delphi nyelvű programozásból megélni
– csak tippelem, úgy a jelenlegi Pascal/Delphi nyelvű projectek nagyjából a fele váltana másik nyelvre, ha tehetné (lásd LafiSoft), de idő, pénz, vagy más erőforrás hiányában nem teszik
– kórosan szegényes az MDA(UML) és a SOA eszközök Pascal/Delphi támogatottsága.Ezzel az utolsó ponttal el is jutottam egy olyan – az iskolák jelenlegi alacsony szintje miatti – másik problémához, ami sokaknak fog hatalmas hátrányt okozni, ha valaki a közeljövőben programozói munkát szeretne vállalni. Ugyanis a korábban felvetett szabványosítási dolog (ja igen, az ISO9899:1999 és az ANSI C 2000 ugyanaz, a nemzetközi szabványt fogadták el helyi amerikai szabványnak – és miért ne, itthon sokan az amerikai ANSI C-vel villognak) a jelenlegi helyzetre vonatkozik, addig az MDA/SOA probléma „csak” pár év múlva fog jelentkezni. Jelenleg a közepes szintű ismerethez hozzátartozik az UML jelölések értelmezése (olvasása), de egyre inkább terjednek a komplex fejlesztő rendszerek alkalmazása. Itt már a C/C++ páros is haldoklik, mert jelenleg a Java és az MS .Net az elsődleges célplatform, a Pascal meg egy dinoszaurusz („Dínó, dínó!” – lelkesedni azért még a jövőben is lehet). Hihetetlen, de itt jön elő, hogy egyes iskolák között mekkora is a különbség, ha az egyik a múlt, a másik meg a jövő évtized technológiáját oktatja. Szóval az ész megállhat, de a fejlődés nem fog.
kisbetu wrote:kozapeti wrote:ugye ezek a kódok hordozhatóak a fejlesztő környezetek között?nem
A válaszom mindenkinek szól. Nekem úgy tűnik, ide a fórumba sokszor nem jut el a napfény. Nem arról kellene beszélgetni a témával kapcsolatban, hogy a felvetett – nem szándékos volt – butaságot hogyan lehet fokozni. Ma Magyarországon azt akiről megtudják a munkaadók, hogy Borland C-n tanulta a programozást és ebből akar megélni (csak ezt ismeri), sírva körberöhögik (max tapintatból nem nyílvánosan). A munkaerő piacon jelenleg csak az ISO9899 az elfogadható (ahol a C nyelv ismeret számít), semmi más. Ebből a szempontból a gcc sem éppen tökéletes, úgy 95%-át teljesíti (gcc 4.xx), viszont a még meg nem jelent gcc 4.3 már a következő ISO szabvány (talán ISO9899:2008) egyes elemeit is tartalmazza. Számomra döbbenetes, hogy az iskolákban még őskori (5-10 éve nem fejlesztett) eszközökkel tanítanak, azaz a gyakorlatban tökéletesen használhatatlan tudást biztosítanak (még a Microsoft jelenegi platformjain sem használhatóak).
Javaslom, aki Borlanc C-vel most ismerkedik, vágja hozzá ezt a doksit a tanárához (esetleg nyomtatva, hogy jobban megérezze):
http://www.ishiboo.com/~nirva/c++/C_STANDARD-ISOIEC9899-1999.pdfMegjegyzés: aki nem érti mi a gondom, probálja meg Borland C-s ismerettel megcsinálni a brainbench C minősítést.
http://www.brainbench.com/xml/bb/common/testcenter/taketest.xml?testId=52Érdekes, nekem a dmesg ilyet is kiír (biztos a rendszerem rossz):
Code:0MB HIGHMEM available.
511MB LOWMEM available.
vmalloc : 0xe0800000 – 0xff7fe000 ( 495 MB)
lowmem : 0xc0000000 – 0xdfff0000 ( 511 MB)
[fglrx] Maximum main memory to use for locked dma buffers: 431 MBytes.Nálad lehet hogy csak simán az lspci-t kell kiadni az /sbin előtag nélkül. Ugye rendszergazdaként próbáltad?
Akkor már csak a telepítő (vagy rescue) lemez maradt. Vagy keress egy kernel bugot, amit kihasználva felhasználói szintet tudsz változtatni, így nem kell újra indítanod a szervert. 🙂
Nem tudom melyik disztrib tartalmaza a drivert alapból, de itt találsz:
„A videókártyám tipusa: Leadtek a gyártó Winfast PX6600LE”
Viszont a 6200LE TurboCache-es, nincs rajta memória.http://www.pcworld.hu/story.php?sid=4531
Viszont tényleg hasznos lenne egy lspci kimenet:
# /sbin/lspci
Meg egy dmesg részlet is sokat segítene, még ha egyéb infók is vannak benne. Csak a RAM és a modulok által lefoglalt (kezelt) memória infók a lényegesek.
# dmesg | grep MB
„Te valószínűleg a távolbalátást és a gondolatolvasást is magasabb szinten űzöd, mint mi, földi hajlandók.”
Nevezd aminek akarod, én szakmai felkészültségnek hívom.„Gyere gyakrabban segíteni, hogy több boldog kérdezője legyen a fórumnak.”
Sajnos ami miatt korábban aktívabb voltam, már nincs meg. Az előző postod is bizonyítja, itt már misztifikálás, kultuszépítés és trendiség dominál. Nem az én világom.Számomra egyértelmű, hogy a „problémát” egy nVidia TurboCache vagy ATI HyperMemory kategóriájú grafikus kártya okozza. Nevezzétek természetfelettinek, mágiának, bárminek.
„Pont ezért gondoltam, hogy talán ReiserFS-t kéne használni ext3 helyett.”
Egy nagy terhelésű squid szerver esetén talán. De nagyon jó a mem találati arány, nagyon keveset használja a vinyót kis terhelésnél.„maximum_object_size_in_memory 16 KB”
Ezt 100kB-ra módosítanám, így 1000-1500 fájl fér a 64MB-os mem gyorstárba, és sokkal jobb lesz a találat mutató (16kB alatt nem sok web objektum található).Ha jobban megnézed, ebbe az irányba senki sem ment el. Mellesleg a „dmesg | grep MB” beszédesebb, azt is megmondja, ha nem a grafigus kártyával van a gond.
„A memória valószínűleg rendben van, a gépen levő más rendszerek látják a teljes méretét (Kubuntu, Frugalware, Fedora).”
Könyörgöm, melyik méretét??? Ez a mondat úgy is igaz lehet, hogy a RAM modulból (1GB) a kernel által összesen használt méretét írja ki (1GB) és nem a főmemória méretét (896MB). Mindez csak nézőpont kérdése.
