750:51

Most nem szakmai téma következik.

 

Hiszem, hogy fajra, nemre, bőrszínre, vallási hovatartozásra, társadalmi helyzetre és iskolázottságra való tekintet nélkül minden embert azonos jogok illetnek meg, tehét minden ember egyenlő. Vagy mégsem?

 

Az utóbbi hetek egyoldalú 6. arab-izraeli háborúja kapcsán ma eljutottam oda, hogy ismét udoromat fejezzem ki a világ egyik leginkább kirekesztő, idegengyűlölő és náci, igen NÁCI eszméket és módszereket idéző államával szemben. Ez pedig nem más, mint Izrael. Fontos tudni, hogy ilyenkor NEM a zsidó népet ítélem el – hisz ők is ártatlanok – hanem az izraeli állam és hadigépezetet (no persze, a haversrác ameriakkal karöltve).

 

Nem mintha a Hezbollah kiscserkész gyülekezet lenne (a pokolba velük!), de amit a másik oldal művel az már túlmegy minden határon. És én most pont arról a másik oldalról beszélek.

 

Nem tudom hogy képesek szembenézni magukkal akkor, amikor naponta abból űznek sportot, hogy többnyire ártatlan civileket és főleg gyerekeket marcangoljanak szét azokkal az idióta rakétáikkal. Az embernek felfordul a gyomra tőlük.

 

Az az óriási különbség a két fél között az, hogy izraeli oldalon eddig nagyjából 51 áldozat, arab oldalon pedig 750 (!!!) áldozat van. Vagyis 750:51-hez. Jó mi?! Ennek a 750 arab embernek (mert ők is emberek voltak az biztos!) túlnyomó többsége civil és legalább az 1/3-a gyermek. Ők semmiről se tehetnek, legfeljebb arról, hogy arabnak születtek ott és akkor, amikor. Ez az aránytalanság annyira bántó, hogy nem lehetett mellette szó nélkül elmenni. És a világ tűri, tűri, tűri… a végtelenségig eltűri ezt az arroganciát.

 

Rohadékok, szemetek, hogy fordulnának fel azok a felelősök a rakétáikkal együtt, akik eltűrik ezt, és továbbra is támogatják az értelmetlen öldöklést. Látott-e már valaki szétszaggatott gyermeket, családját sirató anyát, utcán menekülő férfiakat, nőket és gyermekeket,  földig rombolt otthonokat, földönfutóvá lett embereket? Aki nem, az nézze a híradókat. Hogy izraeli oldalon is előfordult ilyen? Nem kétséges. Őket is ugyanúgy sajnálom, még ha nekik jóval kisebb is a nyomoruk az arabokénál. Ugyanakkor gyarló emberi tulajdonságom az, hogy ha lehet, inkább a gyengébbek mellé állok. Allah segítse őket (ha már én nem tudom).

Miért omlik össze egy rendszer?

Sok-sok számítógép felhasználó napi problémái közé tartozik, hogy mialatt használja a gépét, az egyszer csak fogja magát és váratlanul összeomlik. Ez az állapot rendszerint kék halál (Windows) vagy kernel pánik (Unix/Linux) formájában jelentkezik. Vagy ki tudja. Kellemetlen dolgok tudom, bár egy darabig együtt lehet élni velük. Ebből is látszik, hogy a világ távolról sem tökéletes, főleg, ha számítógépről vagy szoftverről van szó.

 

Akik még soha sem foglalkoztak szoftverfejlesztéssel, azok nem is tudhatják mennyi minden befolyásolja annak megbízhatóságát és minőségét. Talán épp ezért abban a szent meggyőződésben élik nap mint nap szerény életüket, hogy semmi baj se érheti őket. Akkor meg főleg nem, ha heti, havi rendszerességgel, szorgos méhecske módjára telepítik a frissítéseket (vagy Windows esetén bekapcsolják az automatikus frissítést, ami persze nem csodaszer). Pedig dehogy van ez így.

 

A felhasználók többségének a mentális modelljében a szoftver is olyan, mint egy mosógép, TV vagy DVD-lejátszó/felvevő, amit egyszer megvesz az ember, majd üzembe helyezi, aztán jóccakát – évekig felé se néz (mármint hibából kifolyólag). Ezeknél az eszközöknél nincs rendszeres hibajavító csomag, nincs biztonsági rés, nincsenek rajta vírusok (most még legalábbis), és nem képezik a bulvárhírek szenzációhajhász betétanyagait.

 

A kutatók célja az lenne, hogy a hagyományos szoftverrendszerek is legalább annyira legyenek megbízhatóak, mint a korábban említett eszközök (csak nehogy valaki azt mondja, hogy a programozó írjon hibátlan szoftvert, mert az egyszerűen nem lehetséges). Addig is, amíg kitalálják a frankót, nézzük meg, hogy vajon mi okozhatja azokat a fránya rendszerösszeomlásokat.

 

A problémák többsége elsősorban két fő okra vezethető vissza:

  a. amikor túl sok a rendelkezésre álló jogosultság,

  b. és amikor nem megfelelő a hibás programrészek elszigetelése.

 

Az operációs rendszermag (kernel) hatókörén belül számos modul található, melyeknek közös a memóriabeli címterülete. Ezek a modulok mindannyian úgynevezett "kernel módban" működnek, azaz közös címterületek birtokában, és maximális hozzáférési jogokkal felruházva szabadon garázálkodhatnak. Elképzelhető tehát, hogy milyen kárt tudnak okozni egymásnak, és magának az operációs rendszernek is. Ilyen modulok lehetnek például az egyes hardvereszközök meghajtói (diszk, hálózat, nyomtató, USB, hang és video device driver-ek), vagy bármely más kernel módban üzemelő szolgáltatás/szerver/démon.

 

Ezek a szoftvermodulok rendszerint számos hibát tartalmazhatnak és tartalmaznak is. Tapasztalatok szerint a hibák száma arányosan növekszik a program forráskód sorainak számával. Több forráskód, több hiba. És e téren a nyílt forráskódú rendszerek se jobbak a zárt társaiknál. Átlagosan 1-16 hiba jut 1000 sorra, ami bizony nem kevés. Egy biztos, a hibák száma soha se lesz 0.

 

A meghajtó szoftvereket legtöbbször úgynevezett harmadik gyártók fejlesztik, és ritkán esnek át minden környezetre és működési helyzetre kiterjedő, alapos minőségellenőrzési vizsgálaton. Emiatt az olyan monolitikus rendszermagot tartalmazó operációs rendszerek, mint a Unix, Linux, a BSD-k és valamelyest a Windows is rendkívüli veszélynek vannak kitéve. Azért, mert a meghajtó szoftverek (mint korábban említettem már) kernel módban működnek, ahol bármit, bűntetlenül megtehetnek. Ha egy ilyen szoftvermodul bemondja az unalmast (hibás memóriahasználat, végtelen ciklus, másik modul vagy kernel memóriaterület felülírás, stb), akkor jobb esetben más meghajtó szoftver, rosszabb esetben maga az operáiós rendszer is azonnal képes a kardjába dőlni.

 

Többen és sokat szidják a jelenleg legelterjedtebb Windows operációs rendszereket, pedig pl. a Windows XP  összeomlásainak (kék haláljainak) 85%-a ilyen hibás meghajtószoftverek miatt fordul elő. Vagyis hiába van a Microsoftnak amúgy az egyik legszigorúbb tesztrendszere a világon, az "idegen", bevizsgálatlan meghajtó szoftverek mégis egy pillanat alatt elkaszálhatják a rendszert (márpedig a figyelmeztetések ellenére a felhasználó gyakran telepít fel ilyeneket). E téren a linuxsosok se dőlhetnek hátra a foteljukban, mert náluk is pont ugyanez a helyzet.

 

Felmerül a kérdés, hogy jó-jó, de miért a kernel memória címterén, és miért teljes jogosultsággal futnak ezek a modulok? A válasz egyszerű: a sebesség miatt. Ugyanis kernel módban, a közös cím és adatterületek, és az ellenőrzés hiánya miatt sokkal, de sokkal gyorsabb a rendszerhívás és a folyamatok közötti kommunikáció, mint pl. a megbízhatóságot jelentő felhasználói (user) módon belül. Hiszen a kernel természetes módon minden szoftverben megbízik, amely az ő hatókörén belül működik (vagyis mintha maga is a kernel része lenne). Csak érdekességképp jelzem, hogy a linux esetén nagyjából 7x (!!!) olyan gyorsan működnek a meghajtó szoftverek kernel módban, mint felhasználói módban.

 

A probléma egyik gyógymódja az, hogy a rendszermag ne monolitikus, hanem mikrokernel alapú legyen. Az ilyen megoldáson belül a kernelnek csak minimális feladata van, mely mindössze a folyamat (IPC), memória (MMU), és a megszakításkezelésre, illetve ütemezésre terjed ki. Minden más tevékenységet úgynevezett felhasználói (user) módban működő szerverfolyamatok (szolgáltatások) látnak el. A felhasználói módban futó folyamatok lassúbbak a kernel módú társaiknál, de mivel elkülönített memória címtereületen, minimális jogokkal futnak, így sem egymást, sem pedig az operációs rendszert nem veszélyeztetik. Ha bármelyik összeroskad, akkor az csak magával szúr ki. A többiek attól még vidáman működnek tovább. Azonban a felhasználói módban működő szoftvermodulok sajnos 7-12%-al lassúbbak a kernel módú társaiknál. Vajon a biztonság vagy a gyorsaság a fontosabb? Ez költői kérdés volt, mire a választ mindenki adja meg maga.

 

Mellesleg érdekes, hogy mikrokernel alapú operációs rendszer eddig nem sok készült (amúgy az oktatási célú MINIX v3 az pont ilyen).

 

(Zárójelben mondom, hogy a hírek szerint a Windows Vista, a fenti problémákból okulva a meghajtó szoftvereit áthelyezheti a kernel módból a felhasználói módba. Ha igaz, ezzel drámaian megnövekedhet majd az operációs rendszer megbízhatósága és bizonyára néhány százalékkel lecsökken a sebessége.)

 

Tehát a rendszerösszeomlások minimalizálása végett a fentebb említett mikrokernel és/vagy a felhasználói mód alkalmazása lehet az egyik legjobb választás.

 

További megoldások lehetnek még az alábbiak is:

  – fejlesztői nyelv által létrehozott biztonsági mechanizmusok (pl.: OKE – Open Kernel Environment),

  – ellenőrzött felhasználói módú meghajtók monolitikus kernelen belül,

  – minimális kernel méret (kevesebb kód, kevesebb hiba),

  – virtuális gépekben és exokernelekben futtatott meghajtó szoftverek,

  – stb.

 

Ezekre nézve is voltak már kísérletek, ilyenek pl. a következő operációs rendszerek vagy kernel megoldások:

  – a Mach kernel a Berkley UNIX-on,

  – a University of New South Wales linux kísérleti meghajtó szoftverei (csak diszk és Ethernet driver),

  – a Brinch Hansen-féle RC4000 rendszer,

  – a 80-as években készült Amoeba, Chorus és V. rendszerek,

  – a QNX – UNIX (valós idejű rendszer minimum kernel megoldással),

  – Jochen Liedtke által készített L4 (assembly), L4/Fiasco és L4Ka::Pistachio (C++) – Univeresity of Karlsruhe.

 

Ezek mindegyike jó kiindulási alap volt, de végleges és gazdaságos megoldást végül is egyik sem nyújtott (idő hiányában részletesen most nem számolok be róluk).

 

A fentiek miatt fontos lenne megvitatni (főleg magammal), hogy pontosan mi is a különbség a monolitikus és mikrokernel között, és miért biztonságosabb az egyik a másiknál?

 

Hm. Azt hiszem ez majd egy másik írás témája lesz.

Kiemelt frissítésként érkezik az IE7

Ebben is van/lesz hiba jócskán, ennek ellenére alig várom…

 

"Az Internet Explorer 7-es változatát – amikor megjelenik, a tervek szerint valamikor a negyedik negyedévben – az automatikus frissítés szolgáltatáson keresztül, „kiemelt prioritású” frissítésként fogja eljuttatni a Windows XP felhasználókhoz a Microsoft…"

 

Részletek itt.

Megint bajban a Wikipedia

Jómagam eddig se bíztam meg benne oly nagyon. Csak akkor használtam, ha nagyon-nagyon muszály volt. Inkább a jó öreg "zárt forráskódú" szótárakat javasolnám mindenkinek.

 

"A szócikk-vandalizmus egyre növekvő problémát jelent a Wikipediának, amely miatt egyre többen kérdőjelezik meg az alapkoncepció helyességét…"

 

Milyen igaz.

 

Részletek itt.

Frissült a bugróka

Az ember alig bírja kikerülni durva hibákat a világ állítólag "legbiztonságosabb" böngészőjében. Még jó, hogy csak ritkán használom. Ejnye-bejnye fiúkák, más szemében a szálkát is meglátjátok, de a sajátotokban a gerendát se…

 

"A Mozilla Alapítvány a szerdai nap végén honlapján újabb változatot tett közzé népszerű nyílt forrású böngészőcsomagjából. A Firefox új, 1.5.0.5 verziószámot viselő változata funkcionális fejlesztéseket nem hordoz magában, mindössze 13 – nagyrészt kritikus – sebezhetőség javítását tartalmazza.

 
A Firefox-ban foltozásra került tucatnyi sérülékenység közül nem kevesebb mint 8 kritikus besorolású, azaz olyan biztonsági rést képezett, amelyen keresztül hackerek tetszőleges programkódot juttathattak a böngészőbe, és akár az azt futtató gép feletti teljes ellenőrzést is átvehették…"

 

Részletek itt.

Júliusi könyvajánló

Miről híres a július hónap? Hát először is Julius Caesarról, mivel épp róla nevezték el (még diktátor korában). Aztán meg arról, hogy most is lesz könyvajánló, bár kissé karcsúra sikeredett.

 

Nemrég röviden írtam az elosztott rendszerekről. Ehhez kapcsolódóan találtam egy új, igencsak jó könyvet (a korábbi "Joel M. Circhlow: Elosztott rendszerek" könyvét máris felejtsük el).

 

Tanenbaum-Steen: Elosztott rendszerek – Alapelvek és paradigmák (Prentice Hall/Panem kiadó, 818 oldal)

Ez a könyv a téma csúcsa (eredetileg egyetemi tankönyvnek szánták). Nem csak tartalmilag jó, hanem a nehézségét tekintve még olvasmányos is. Az alábbiakról van szó benne (rajta-rajta, gatyát felkötni!):

  – Kommunikáció

  – Folyamatok

  – Elnevezési rendszerek

  – Szinkronizálás

  – Konzisztencia és többszörözés

  – Hibatűrés

  – Biztonság

  – Elosztott objektum alapú rendszerek

  – Elosztott dokumentum alapú rendszerek

  – Elosztott együttműködés alapú rendszerek

 

Az egyik szerző A.S. Tanenbaum már biztosan ismerős mindenkinek (én is többször hivatkoztam rá). Egyetemi tanár, a MINIX operációs rendszer kitatalálója, a mikrokernel védelmezője, Linus "főpingvin" Torvalds korábbi tanára és vitapartnere, számos kiváló könyv szerzője.

 

http://www.panem.hu/termekek.php?szt=59&szfk=3

OpenOffice-bibi

Nocak, nocak. Hát hol az a sok lelkes szoftverkommunista? Biztos épp buzgón szidják a Microsoftot, ami persze elveszi minden idejüket. Eközben nem igazán érnek rá a makrók biztonságával foglalkozni. Bezzeg, ha más gyártót kell köpködni, akkor igencsak résen vannak. Munkára fel!

 

"Egy minisztériumi vizsgálat szerint a Microsoft Office kevésbé sebezhető, mint az ingyenes alternatíva.

Bár az ingyenesen letölthető OpenOffice.org irodai szoftvercsomag egyre népszerűbb mind a magán-, mind pedig a kormányzati felhasználók körében, van legalábbis egy olyan terület, ahol a Microsoft Office-a jobb: a biztonság. Ezt állítja egy a francia védelmi minisztérium megbízásából állítólag egy éven át folytatott vizsgálat, melynek eredményeit nemrég ismertették.

A tárca szakemberei ennek során saját fejlesztésű ártalmas programok segítségével igyekeztek feltérképezni a két programcsomag gyenge pontjait. Következtetésük pedig az, hogy az OpenOffice.org bizonyos – például makró- – támadások ellen védtelenebb. Míg a szabad szoftver számos alkalommal figyelmeztetés nélkül végrehajtotta a kártékony makrókat, addig a Microsoft programja minden esetben kiabál, ha egy makróval ellátott dokumentumot akar megnyitni a felhasználó – hoztak egy példát a védelmisek, akik szerint azért lehet sebezhetőbb az OpenOffice.org, mert a fejlesztők elsősorban a Microsoft szoftverével versenyképes vagy éppen annál jobb szolgáltatásokra koncentrálnak, és nem a biztonságra.

A vizsgálat eredményeit – a részletek nem nyilvánosak – át fogják adni az OpenOffice.org-nak, és remélik, hogy ennek köszönhetően javul a szoftver biztonságossága. A jelentés azonban addig is lassíthatja a csomag terjedését Franciaországban, hiszen hatására a bevezetését fontolgató ügyfelek – például Párizs önkormányzata – könnyedén meggondolhatják magukat."

Eredeti hír itt.

Vevőt talált a Delphire a Borland?

Hajdanában, még úgy a Turbo Pascal 3.0 idején (gyerekek kedvéért: kb. 1990 tájékán) a Borland volt a legkedvesebb cégem. Sajnálom, hogy idáig fajult a dolog. Vajon ki lesz a vevő? Tippelhetek? Szerintem az Oracle vagy a Computer Associates. No, majd csak meglátjuk…

 
"Egy brit internetes informatikai magazin értesülései szerint a Borlandnak végre sikerült egy komolynak tűnő vevőt találnia a még az év elején eladásra meghirdetett fejlesztői eszközcsaládjára. A The Register megbízható belső forrásokra hivatkozva azt állítja, hogy a két cég az elkövetkező néhány héten belül bejelenti a többek között a Delphi, a C Builder és a JBuilder fejlesztőeszköz-családot érintő tranzakció megkötését és részleteit."

 

Részletek itt.

A nyílt forrás és a vírusfejlesztők

Csak fejlesszenek, fejlesszenek…

 

"Az ártalmas kódot készítok egyre gyakrabban használnak nyíltforrású eljárásokat a kódfejlesztés során, állítja a McAfee.

 

A 2006-os, globális fenyegetéseket elemzo jelentésében (Global Threat Report) számolt be arról az IT-biztonsággal foglalkozó vállalat, hogy a vírusírók egyre inkább megosztják egymás között a tudásukat, múlóban van a saját kódot féltékenyen óvó hackerek idoszaka. A McAfee szerint nemcsak a forráskód szabadon felhasználhatóságáról van szó, hanem azok használatának részletes leírásáról is, ami megkönnyíti az ismeretlen programrészek alkalmazását. Azaz a kevésbé járatos vírusírók is könnye(bbe)n használhatják ki az egyébként egyre komolyabb szakmai tudást és felkészültséget igénylo biztonsági réseket…"

 

Részletek itt.

Bill Gates új adománya: 64 milliárd forint

No nem nekünk, hanem AIDS-kutatásra. Amikor sokan szidalmazzák, akkor gondoljanak erre is. Jelenleg ő a világ legnagyobb adományozója (még akkor is, ha leírhatja az adójából).

 

"Mint a Bill and Melinda Gates alapítvány közölte, a pénzt a világ 19 országában működő, 165 tudósból álló nemzetközi hálózat kapja, amely a szerzett immunhiány-betegség elleni új gyógyszerek után kutat.

Az adomány az eddigi legmagasabb összegű anyagi segítség a világon az AIDS-kutatás számára, maga az alapítvány pedig, amely a pénzt kapja, a legnagyobb pénzalappal (29,1 milliárd dollárral) rendelkező karitatív szervezet a világon."

 

Részletek itt.

Kevés a gyakorlattal rendelkező szoftverfejlesztő

Biztos így van, de fütyülök rá. Rendszerint szívesebben alkalmazok kezdő programozókat, ők ugyanis könnyebben formálhatók, jobban igazodnak a körülményekhez, és még nem gondolják magukról, hogy annyira überfaszák. Ugyanakkor ki nem állhatom azokat a programozókat, akik ott ülnek az elefántcsonttoronyban, istennek képzelve magukat, miközben kezelhetetlenek, visszapofáznak, képtelenek határidőre, pontosan dolgozni és még sorolhatnám (persze akad néhány kivétel is). Egy kezdő programozó még sokmindenre megtanítható, hozzáigazítható a szabályaokhoz, szabványokhoz és még sorolhatnám. Villámgyorsan tanulnak és lelkesek. Ha nem, akkor legalább könnyű szívvel mondhatom nekik, hogy hasta la vista, kezdjenek máshol karriert építeni.

 

"A Grepton Informatikai Zrt. július elejétől fejlesztői csapatának bővítése érdekében a Microsoft Magyarország támogatásával intenzív képzést indított pályakezdő informatikusok számára .NET Iskola néven.
[…]
A Grepton szerint az egyetemeken az elméleti képzést megkapják a diákok: szinte csukott szemmel tudnak válaszolni fogalmi kérdésekre, de konkrét gyakorlati példa esetén elbizonytalanodnak, és a legtöbbjük alkalmazni sem tudja a tanultakat.
[…]
Az eddigi toborzásaink során szerzett tapasztalat azt mutatta, hogy gyakorlattal rendelkező fejlesztők nehezen találhatók a munkaerőpiacon. Ezzel párhuzamosan számos olyan pályakezdővel találkoztunk, akik a tapasztalat hiányát lelkesedésükkel és fogékonyságukkal ellensúlyozzák"

 

Részletek itt.

A Microsoft és a XenSource

Érdekes, érdekes…

 

"Óriási meglepetést okozva stratégiai együttműködési megállapodást jelentett be tegnap a Microsoft és a XenSource. Az egyezség szerint a Microsoft jelenleg fejlesztés alatt álló virtualizációs hypervisora, a Viridian kompatibilis lesz a Xennel. Ez azt jelenti, hogy a Viridian megjelenésekor a felhasználók a linuxos virtuális gépeiket Windows Server környezetben is teljes sebességgel futtathatják…"

 

Részletek itt.

Mert magozni jó

Zannya! Három éven belül 32 magos processzort tervez az Intel.

 

"Az Intel 2009/2010-re olyan processzort tervez forgalomba hozni, amely nem kevesebb, mint 32 darab 2 GHz-es magot tartalmaz majd…"

 

Részletek itt.

Adatbázis pillanatok – I.

Kicsit nagyképűen technológiai evangelistaként megjelölve magam úgy gondolom, ha van egy érdekes téma, (ami persze elsősorban engem érdekel, vagy sokat foglakozom vele), akkor talán mások is így lehetnek vele. Vagy legalább is remélem, hogy így. Mindegy, legyen ez egy általam gerjesztett egészséges optimizmus. Végül is csak az a fontos, hogy az olvasók közül néhányan új információkhoz jussanak. És ha ez sikerül, akkor máris jól érzem magam.

 

A bejegyzés címeként megadott "Adatbázis pillanatok" azt jelzi, hogy nem áll szándékomban teljes és átfogó képet adni az adatbázis-kezelő rendszerek belső működéséről. E célból sok és igen jó könyv jelent meg, melyeket korábban már én is ajánlottam. Inkább rendszeresen kiragadok egy-egy pillanatot, amely talán nem annyira ismert vagy nem olyan egyértelmű. Lássuk hát az elsőt.

 

Karakterláncok hossza

 

Bizonyára mindenki tudja, hogy egy adatbázis-oszlop, amikor alfanumerikus (szöveges vagy karakterlánc) jellegű adatot tartalmaz, akkor annak előre definiálni kell a maximális hosszát.

 

Példa: Hozzunk létre egy személyi adatokat tartalmazó táblát.

 

  CREATE TABLE Szemely (
    szemely_azonosito INTEGER     NOT NULL,
    szuletesi_datum   DATE        NOT NULL,
    szemely_nev       VARCHAR(30) NOT NULL,
    anyja_neve        CHAR(30)    NOT NULL,

 

    PRIMARY KEY(szemely_azonosito)
  );

 

Ebben a definícióban szerepel két karakterlánc oszlop, az egyik maga a személy neve, a másik pedig az anyja neve. Az egyik VARCHAR(30), tehát változó hosszúságú, a másik CHAR(30) állandó hosszúságú, de mindkettő max. 30 karaktert tartalmazhat.

 

Mégis vajon mi a különbség a kettő között?

 

Nos, az állandó hosszúságú "CHAR" adattípus úgy viselkedik, hogy ha a megadott maximális hossznál kevesebb karakter van benne, akkor a maradék helyet speciális töltelékkarakterekkel tölti ki. Ez a töltelékkarakter egy az ASCII kódtáblázat szerinti 8 bites (1 bájtos) karakter, mely szemre nem látható, és a kódja nem egyezik semelyik olyan karakter kódjával, amely SQL-utasításban használható. Megjegyzés: Ezen kitétel ellenére az Oracle és Microsoft SQL Server mégis a szóköz (32-es ASCII kódú) karaktert használja kitöltőnek.

 

A változó hosszúságú "VARCHAR" adattípusban olyan karakterláncok szerepelnek értékként, melyek hossza a megadott határok között változhat. Ha a megadott maximális hossznál kevesebb karakter van benne, akkor a "CHAR" típussal ellentétben a maradék hely NEM lesz feltöltve töltelékkarakterrel. Vagyis annyi karaktert tárol, amennyi benne van. Megjegyzés: Természetesen a maximális méretet egyik se lépheti túl.

 

Példa:
  – szemely_nev = ‘William Henry Gates III.‘
  – anyja_neve  = ‘Mary Gates                    ‘

 

  Ezesetben a "szemely_nev" oszlopban lévő adat tényleges hossza 24 karakter, az "anyja_neve" oszlopban
  lévő adat tényleges hossza pedig 30 karakter (a kitöltőkarakterek miatt, melyet most a " " jelöl).

 

Nem nehéz kitalálni, hogy a "VARCHAR" típus használatakor a benne lévő adat csak annyi helyet foglal, amennyi a tényleges hossza. A "CHAR" típus esetén pedig mind a maximális (jelen esetben 30) karakter hosszúságú helyet elfoglalja.

 

Hoppá! Akkor nyilván az első a jobb választás, nem igaz?  Hát ez attól függ.

 

A "VARCHAR" esetén tényleg optimálisabb a helyfoglalás, de amikor a hossza kibővül (pl.: 24-ről 28-ra), akkor az adatbázis-kezelőnek lázasan új helyet kell keresni a többletkaraktereknek. És ez bizony időveszteség. Na nem túl sok, de azért több millió adatnál már igenis számottevő lehet.

 

A "CHAR" típusú adat esetén pedig soha sem kell a további helyfoglalással törödni, mivel annak tényleges hossza már a kezdetektől a maximális (a kitöltőkarakterek miatt).

 

A változó hosszú "VARCHAR" típusú karakterláncok hosszának nyilvántartására kétféle technika terjedt el:

 

1. Hossz plusz tartalom: Amely szerint lefoglalunk egy n+1 bájt méretű helyet. Az első bájt egy 8 bites egész
    szám (0-255), a karakterlánc bájtjainak (hosszának) számával egyezik meg. A karakterlánc nem lehet
    hosszabb n karakternél, az n pedig nem lehet több, mint 255. Ennek segítségével mindig pontosan
    tudhatjuk, hogy hány karakterből áll az adat. Unicode-os karakterláncot is kezelni képes adatbázisban az
    első egy bájt helyett két bájtot alkalmaznak (0-65535).
  
   A módszer előnye, hogy gyorsan megtudhatjuk az aktuális hosszát, mivel ehhez csak meg kell néznünk az
   első bájton lévő számot, ami maga a hossz. Hátránya, hogy egy külön bájtot fenn kell tartani a hossz
   tárolásához.

 

   Példa: szemely_nev = 26‘William Henry Gates III.‘

 

2. Nullértékkel végződő tartalom: Amely szerint lefoglalunk egy n+1 bájt méretű helyet. Feltöltjük a kívánt
    adattal, majd az utolsó hasznos karakter után egy az ASCII kódtáblázatban lévő 0 kódú karaktert teszünk
    (figyelem, ez nem a nulla számjegy kódja, mert az bizony a 48, hanem a kódtáblázat szerinti 0 kódú
    karakter!). Ez egy olyan karakter, amely egyébként nem megengedett az SQL-karakterláncokban.
  
   A módszer előnye, hogy nem kell külön bájtot fenntartani a hossz tárolásához. Hátránya, hogy a
   karakterlánc végét (a 0 ASCII kódú karaktert) az adatbázis-kezelőnek mindig meg kell keresnie ahhoz, hogy
   megtudja meddig is tart ez az egész.

 

   Példa: szemely_nev = ‘William Henry Gates III.‘
 
A fentieken kívül illik tudni, hogy a "CHAR" típus alkalmazásánál figyelni kell arra is, melyszerint lehet benne kitöltőkarakter. Ez számos problémát okozhat, különösan az SQL-WHERE feltétel használatakor.

 

Példa:
  Itt a már jól ismert "anyja_neve" oszlop, melyben épp ‘Mary Gates                    ‘ van 
  (ebben a "CHAR" típus miatt vannak kiöltőkarakterek). Most tételezzük fel, hogy a személyek között
  önmagában is szerepel Mrs. Gates, ezért valahol létezik egy  "szemely_nev", melyben ‘Mary Gates’ adat van
  (ebben a "VARCHAR" típus miatt nincsenek kiöltőkarakterek), Mindkét mezőben ugyanaz az adat van, ennek
  ellenére mégsem lehetnek egyenlők, hiszen a…

  ‘Mary Gates                    ‘ nem ugyanaz, mint a ‘Mary Gates’

   (pont a kitöltőkarakterek miatt)

 

  Megoldás: a "CHAR" típusú oszlop tartalmából ki kell venni a kitöltőkaraktereket (erre minden adatbázis-
  kezelő ad valami függvényt, pl.: TRIM vagy LTRIM, RTRIM néven). Látható, hogy egy kis különbség mennyi
  problémát okozhat és néha egyáltalán nem egyszerű a megoldás.

 

A következő téma: Adatok fizikai tárolása

 

Folytatjuk…

Évekig sebezhető volt a Linux kernel

Tyűűűűű azannyát! A sok openmatyi közül valamelyik ennyi év alatt belebotlott a frankóba.

 

"Egyetlen karakter elírása miatt volt sebezhető évekig a Linux kernel
 
A napokban egy érdekes biztonsági rést került javításra a Linux kernelben, amelynek különlegességét az adja, hogy mindössze egyetlen egy karakter véletlen elírása miatt nyílt meg a rendszeren. A nyílt forrású magban most foltozásra került veszélyes rés több mint fél évtizede rejtőzött a kód egy szinte minden telepítésen aktívan használt részében, és rendszergazdai jogosultságok megszerzését tette lehetővé arra jogosulatlan felhasználók számára is.

 

A trükkös bugot a fejlesztőknek a Linux kernel 2.2.16-os változatába sikerült – nyilván nem szándékosan – becsempészniük, amikor az eredeti CD-ROM meghajtóprogramot a DVD egységek és lemezek támogatásával egészítették ki. A hiba lényegében mindössze egy "&" karakter helyett szereplő "=" volt, amely azonban annak ellenére, hogy csak egyetlen apró elírást jelentett, valójában egy óriási, ún. privilégium-eszkalációs biztonsági rést ütött a nyílt forrású rendszermagon.

 

A hiba kihasználásához a támadóknak mindössze egy speciálisan összeállított USB tollat, vagy manipulált ATAPI eszközt kellett a sebezhető Linux kernelt futtató géphez csatlakoztatniuk, amin – a biztonsági rés révén – pillanatok alatt rendszergazdai jogosultságokat szerezhettek, és így akár a gép feletti teljes ellenőrzést is átvehették. Ugyanakkor a sebezhetőség súlyosságát némileg csökkenti, hogy a támadás kivitelezéséhez az áldozatul kiszemelt géphez fizikai hozzáférés szükséges, amely a hiba kihasználását a legtöbb esetben erősen megnehezíti.

 

A Linux kernel a még 2000-ben megjelent 2.2.16-os verzióitól kezdődően egészen a legújabb 2.6.x-es változatáig minden kiadását érintő sebezhetőség javítása már elkészült, a hivatalos foltok megjelenése a különböző disztribúciókhoz pedig az elkövetkező napokban lesz várható."

 

Eredeti hír itt.