Gyakran Ismételt Kérdések a FreeBSD 6.`X`, 7.`X` és 8.`X` változatairól
Előző |  | Következő

# Fejezet 16. Egyéb kérdések

16.1. A FreeBSD miért használ sokkal több lapozóállományt, mint a Linux®?
16.2. A `top` miért jelez kevés szabad memóriát, miközben csak néhány program fut?
16.3. A `chmod` miért nem változtatja meg a szimbolikus linkek engedélyeit?
16.4. A FreeBSD képes DOS programokat futtatni?
16.5. Hogyan tudjuk az anyanyelvünkre lefordítani a FreeBSD dokumentációját?
16.6. A `FreeBSD.org` tartományon belüli e-mail címekre küldött levelek miért pattannak vissza?
16.7. Hogyan lehet egyszerűen FreeBSD rendszereket elérni?
16.8. Mi az a `sup` és hogyan lehet használni?
16.9. Hogy hívják azt a cuki kis vörös fickót?
16.10. Felhasználható a BSD démon képe?
16.11. Található valahol felhasználható kép a BSD démonról?
16.12. A levelezési listákon szerepeltek ismeretlen kifejezések vagy rövidítések. Hol lehet ezeknek utánanézni?
16.13. Miért fontos annyira a biciklitároló színe?

16.1. A FreeBSD miért használ sokkal több lapozóállományt, mint a Linux®?

A FreeBSD csupán látszólag használ több helyet a lapozásra, mint a Linux, valójában egyébként nem. A FreeBSD és a Linux közt az egyik leglényegesebb különbség, hogy a FreeBSD valamivel előre gondolkodik, és az összes pillanatnyilag nem használt lapot kilapozza a központi memóriából a lapozóterületre. Ezzel igyekszik minél több memóriát előkészíteni az aktív használatra. A Linux ezzel szemben a lapozást csak végső esetben használja. Ennek megfelelően a lapozóterület gyakoribb használatát remekül ellensúlyozza a fizikai memória hatékonyabb kihasználása.

Habár a FreeBSD igyekszik ebben a tekintetben előrelátó lenni, nem minden esetben tudja pontosan eldönteni, hogy a rendszerben mely lapokat nem használják éppen. Emiatt nem fogja az összes memóriát kilapozni, ha például egész éjszakára futni hagyjuk a gépünket.

16.2. A `top` miért jelez kevés szabad memóriát, miközben csak néhány program fut?

Röviden úgy válaszolhatnánk meg ezt a kérdést, hogy a szabad memória igazából elvesztegetett memória. A programok által szabadon hagyott memóriát a FreeBSD rendszermagja többnyire a lemez gyorsítótárazására használja fel. A top(1) kimenetében olvasható `Inact`, `Cache` és `Buf` értékek a lényegében különböző öregedési szintek szerint kategorizált tárazott adatok. A tárazás lényegében arra utal, hogy a rendszernek így nem a lassú elérésű lemezen kell a gyakran elérni kívánt adatok után kutatni, aminek köszönhetően növekszik az összteljesítmény. A top(1) kimenetében tehát `Free` kategória alacsony értéke alapvetően jót jelent, feltéve, ha nem nagyon kevés.

16.3. A `chmod` miért nem változtatja meg a szimbolikus linkek engedélyeit?

A szimbolikus linkekhez alapértelmezés szerint nem tartoznak engedélyek, ezért a chmod(1) ilyen esetekben az eredeti állomány engedélyeit változtatja meg. Ezért például, ha adott egy `ize` nevű állomány, valamint erre egy `mize` nevű szimbolikus link, akkor a következő parancs mindig működni fog:

    % chmod g-w mize

Ennek ellenére az `mize` engedélyei nem fognak megváltozni.

Ha egy adott könyvtárszerkezetben elhelyezkedő állományok engedélyeit akarjuk egyszerre módosítani, akkor a `-R` opció mellett a `-H` vagy `-L` opciókat is meg kell adnunk. Erről részletesebb információkat a chmod(1) és a symlink(7) man oldalairól tudhatunk meg.

> Figyelem: A chmod(1) `-R` opciója rekurzív működést tesz lehetővé. Óvatosan bánjunk a könyvtárakkal vagy a könyvtárakra mutató szimbolikus linkekkel a chmod(1) használata során. Ha egy szimbolikus link által hivatkozott könyvtár engedélyeit akarjuk megváltoztatni, akkor a chmod(1) parancsnak ne adjunk meg semmilyen paramétert és a nevet zárjuk perjellel (`/`). Például, ha az `ize` a `mize` könyvtárra mutató szimbolikus link, és meg akarjuk változtatni az `ize` engedélyeit (ami valójában a `mize` engedélyeit jelenti), akkor valami ilyesmit kellene megadnunk:

>     % chmod 555 ize/

> A név végén szereplő perjelből a chmod(1) tudni fogja, hogy követnie kell a `foo` szimbolikus linket és így az általa hivatkozott könyvtár, a `mize` engedélyeit fogja megváltoztatni.

16.4. A FreeBSD képes DOS programokat futtatni?

Igen, a Portgyűjteményben található `emulators/doscmd`, vagyis egy DOS emulációs program segítségével.

Amennyiben a doscmd önmagában még nem lenne elegendő, egy másik segédprogram, a `emulators/pcemu` segítségével emulálni tudunk egy 8088-as processzort, valamint a BIOS annyi részét, hogy futtatni tudjunk szöveges DOS alkalmazásokat. A használatához az X Window Systemre is szükségünk lesz.

Érdemes ezenkívül még megpróbálnunk a FreeBSD Portgyűjteményében található `emulators/dosbox` portot is. Ez az alkalmazás elsősorban a régi DOS-os játékok futtatásához szükséges környezet emulációjára koncentrál, a helyi állományrendszerben található állományok felhasználásával.

16.5. Hogyan tudjuk az anyanyelvünkre lefordítani a FreeBSD dokumentációját?

Olvassuk el a FreeBSD Dokumentációs Projekt bevezetőjében található Fordítói GYIK-ot.

16.6. A `FreeBSD.org` tartományon belüli e-mail címekre küldött levelek miért pattannak vissza?

A `FreeBSD.org` levelezőrendszere a bejövő levelekre vonatkozóan átvett néhány szigorúbb ellenőrzést a Postfix alkalmazástól, és ezért eldobja azokat a leveleket, amelyek formátuma hibás vagy feltehetően szemét. A leveleink az alábbi okok miatt pattanhatnak vissza:

- A levelet olyan név- vagy IP-tartományból küldtük, ahonnan korábban levélszemetet küldtek, ezért feketelistára került.

  A FreeBSD levelező szerverei eldobnak minden olyan levelet, amelyek feketelistás tartományokból érkeznek. Ha olyan cégen vagy tartományon keresztül akarunk küldeni, amelyik levélszemetet gyárt vagy továbbít, akkor váltsunk szolgáltatót.

- A levél törzse csak HTML kódot tartalmaz.

  A leveleinket egyszerű szöveges formátumban küldjük. Állítsuk be a levelező kliensünket erre.

- A `FreeBSD.org` címen üzemelő levelező szerver nem tudta a csatlakozó gép IP-címét szimbolikus névre feloldani.

  Az ellenkező irányú névfeloldás sikeressége alapvető követelmény a levelek fogadásához. Gondoskodjunk róla, hogy a levelező szerverünk IP-címével működjön az inverz névfeloldás, Sok otthoni szolgáltatás (DSL, kábel, betárcsázós stb. kapcsolat) erre nem ad lehetőséget. Ilyenkor a leveleinket próbáljuk meg a szolgáltatónk levelező szerverein keresztül küldeni.

- Az SMTP protokoll EHLO/HELO részében megadott hálózati név nem oldható fel valós IP-címre.

  Egy teljes, feloldható hálózati név elegendhetetlen a levél elfogadásához szükséges SMTP párbeszéd érvényességéhez. Ha nincs hivatalosan bejegyzett hálózati nevünk, akkor a szolgáltató levelező szervereit kell használnunk a levél elküldéséhez.

- A küldött üzenet azonosítója (Message ID) végén a `localhost` szerepel.

  Egyes levelező kliensek rossz azonosítónak hoznak létre az üzenetekhez, ezért a rendszer nem hajlandó elfogadni ezeket. Ilyenkor vagy rávesszük valahogy a levelező kliensünket, hogy rendes azonosítókat készítsen, vagy úgy állítjuk be a levéltovábbítónkat, hogy érvényes azonosítókra írja át.

16.7. Hogyan lehet egyszerűen FreeBSD rendszereket elérni?

Habár a FreeBSD maga nem nyújt akárki számára hozzáférést a saját szervereihez, mások viszont kínálnak bárki által elérhető UNIX® rendszereket. Ennek költsége és minősége szolgáltatónként változik.

Az Arbornet, Inc, vagy másik nevén M-Net 1983 óta szolgáltat nyílt hozzáférést UNIX típusú rendszerekhez. Egy System III alapokon működő Altos rendszerről a 1991-ben BSD/OS-re váltottak, majd 2000 júliusában aztán FreeBSD-re váltottak. Az M-Net telnet és SSH szolgáltatásokon keresztül is elérhető, és lényegében a FreeBSD alatt elérhető összes programhoz enged egy alapvető hozzáférést. A hálózati hozzáférés azonban csak a tagok és a támogatók számára engedélyezett. Ez egy non-profit szervezet. Az M-Net rendelkezik üzenőfallal (bulletin board system, BBS) és interaktív csevegőrendszerrel is.

A Grex az M-Net szolgáltatásához hasonlóan ugyanúgy kínál üzenőfalat és csevegési lehetőséget. Többségében azonban Sun™ 4M gépeik vannak, amelyen SunOS™ fut.

16.8. Mi az a `sup` és hogyan lehet használni?

A SUP mozaikszó mögött a “Software Update Protocol” (“Szoftverfrissítési protokoll”) áll, amelyet fejlesztési fák szinkronban tartására dolgoztak ki a Carnegie-Mellon Egyetemen. Régebben ennek segítségével tartották frissítették magukat a fejlesztői források különböző tükrözései a FreeBSD Projekten belül.

A SUP nem kifejezetten egy sávszélesség-takarékos megoldás, és egy ideje már nyugdíjba vonult. A forrásainkat jelen pillanatban a CVSup használatával tudjuk frissíteni.

16.9. Hogy hívják azt a cuki kis vörös fickót?

Igazából nincs neve, mindenki egyszerűen csak “BSD démonnak” nevezi. Ha mégis hívni szeretnénk valahogy, akkor szólítsuk csak “beastie”-nek, ugyanis a “beastie” kiejtése megegyezik a “BSD” szóéval (“bíeszdi”).

A BSD démonról a saját honlapján tudhatunk meg többet.

16.10. Felhasználható a BSD démon képe?

Talán. A BSD démon jogait Marshall Kirk McKusick birtokolja. A felhasználás pontos lehetőségeivel kapcsolatban olvassuk el Statement on the Use of the BSD Daemon Figure című írást.

Röviden úgy foglalhatnánk össze, hogy ízléses stílusban a saját céljainkra mindaddig nyugodtan felhasználhatjuk a képet, amíg megemlítjük az eredeti szerzőt. Ha kereskedelmi céljaink vannak, akkor írjunk Kirk McKusick `<mckusick@FreeBSD.org>` címére. A pontosabb részleteket a BSD démon honlapján olvashatjuk.

16.11. Található valahol felhasználható kép a BSD démonról?

EPS és XFig formátumú rajzok a `/usr/share/examples/BSD_daemon/` könyvtárban vannak.

16.12. A levelezési listákon szerepeltek ismeretlen kifejezések vagy rövidítések. Hol lehet ezeknek utánanézni?

Olvassuk el a FreeBSD szakkifejezéseinek gyűjteményét.

16.13. Miért fontos annyira a biciklitároló színe?

Erre röviden úgy adhatnánk választ, hogy ezzel igazából nem kell annyira törődnünk. Ha viszont valamivel terjedelmesebben akarunk válaszolni, akkor azt mondhatnánk, hogy azért, mert egy biciklitároló megépítése még nem tántorít el senkit sem a válaszott szín kritizálásától és az átfestésének fontolgatásától. Ez a metafora alapvetően arról szól, hogy nem kell feltétlenül minden apró részletről vitatkoznunk csupán azért, mert jobban értünk hozzá. Sokak tapasztalata szerint ugyanis a változtatásokhoz kapcsolódó megjegyzések által gerjesztett zaj fordítottan arányos az adott változtatás bonyolultságával.

A még hosszabb és teljesebb válasz eredetileg egy nagyon hosszú és fárasztó vita eredményeképpen keletkezett, amikor arról esett szó, hogy a sleep(1) törtekkel dolgozzon-e vagy sem. Erre válaszul küldte Poul-Henning Kamp `<phk@FreeBSD.org>` az azóta híressé vált “A bike shed (any color will do) on greener grass...” (“(Bármilyen színű) biciklitároló megfelelne egy zöldebb gyepen...”) című levelét. Ebből szeretnénk most idézni:

“Miről is szól ez a biciklitároló?” -- kérdezték tőlem sokan.

Ez egy hosszú, vagy még inkább régi történet, amely azonban valójában meglehetősen rövid. C. Northcote Parkinson “Parkinson törvénye” címmel írt egy könyvet az 1960-as évek elején, amelyben elég nagy betekintést adott a vezetés dinamikájába.

[a könyv részletes bemutatását most kihagyjuk]

A konkrét példában egy biciklitároló szerepel egy atomerőművel szemben, szóval ez is eléggé jól érzékelteti a könyv korát.

Parkinson ezen keresztül bemutatja, hogyan kell egy igazgatói tanács elé járulni egy több millió vagy akár milliárd dolláros atomerőmű megépítéséhez, azonban egy egyszerű biciklitároló megépítésekor könnyen véget nem érő vitatkozásba bonyolódhatunk.

Parkinson elmagyarázza, mindez azért van, mert egy atomerőmű annyira óriási, drága és bonyolult, hogy az emberek egyszerűen nem értik meg. Ezért nem szólnak semmit és megnyugtatják magukat a feltételezéssel, hogy valaki más korábban már biztosan utánajárt a részleteknek. Richard P. Feynmann is könyveiben rengeteg érdekes és nagyon találó példát ad ezekre Los Alamossal kapcsolatban.

Vegyünk ezzel szemben most egy biciklitárolót. Bárki képes egy hétvége alatt összetákolni egy ilyet és még így is marad ideje megnézni a meccset. Ezért nem számít, mennyire jól megfogalmazott, előkészített és logikus is a javaslatunk, valaki biztosan meg fogja ragadni a lehetőséget, hogy az orrunk előtt fitogtassa a képességeit és megmutassa magát: ő bizony itt járt.

Dániában ezt mi úgy hívjuk, hogy “otthagyjuk a kezünk nyomát”. Ez mindössze a személyes büszkeségről és tekintélyről szól, vagyis hogy végre elmondhassuk: “Ezt nézd! Én csináltam.” Ez ugyan leginkább a politikusokra jellemző, de alapvetően minden emberben ott él. Gondoljunk csak a friss betonban hagyott lábnyomokra.

--Poul-Henning Kamp `<phk@FreeBSD.org>`, freebsd-hackers, 1999. október 2. |

Előző | Tartalom | Következő
Soros vonali kommunikáció |  | Mókás dolgok a FreeBSD-vel kapcsolatban

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.