Aktív fórumtémák

Tárgy Válaszok Legutóbbi beküldés Fórum Szerző
  git rábeszélés ötletek 37  2025-08-24T12:11:50+0200 Fejlesztés ruczati
  Német agybaj újratöltve: Illegálissá válhat a reklámblokkolás, börtön is járhat majd érte 473  2025-08-24T12:10:38+0200 Web, mail, IRC, IM, hálózatok jevgenyij
  Tönkrevághatja az SSD-ket és HDD-ket a Windows 11 legújabb frissítése 29  2025-08-24T12:02:04+0200 HUP cikkturkáló DL3V1
  Robotporszívó helyi szerverre irányítása 57  2025-08-24T12:01:54+0200 Hálózati eszközök kikepzo
  Mikrotik ipsec 20 kbps, de miért? 2025-08-24T11:20:12+0200 Hálózati eszközök ecsi
  Schrödinger Linux 24  2025-08-24T11:09:42+0200 Tudtad-e, hogy... EspOS
  Laptop Power Pack ASUS Vivobook-hoz 2025-08-24T10:57:16+0200 Elektronika, Elektromos eszközök mraacz
  [MEGOLDVA] Kis github segítséget kérnék 17  2025-08-24T10:13:21+0200 C/C++ bzt
  Fidesz osztja a friss időt Openwrt 18.06.2-ön vagy csak T-online-soknak? 30  2025-08-24T07:49:23+0200 Hálózati eszközök lusi
  Backup megoldások, ötleteljünk 49  2025-08-24T06:13:50+0200 Segédprogramok zslaszlo
  Roidmi károsultak fóruma (Roidmi csődbe ment, így nem használhatók tovább bizonyos eszközeik) 49  2025-08-23T23:53:23+0200 Közösségi kerekasztal Charybdis
  Feltörték a Gmail-t 40  2025-08-23T20:15:34+0200 HUP cikkturkáló bzt
  Jogsi nélküli autó időseknek 216  2025-08-23T20:11:57+0200 Közösségi kerekasztal plt
  Yettelnél vásárolt telefon kártyafüggetlen-e? 2025-08-23T19:42:50+0200 Notebook, laptop, mobiltelefon ... veresh
  Unaloműző online játékok és azok eredményei #2 747  2025-08-23T09:24:56+0200 Játékok trey
  Virtualizáció és Bitlocker 2025-08-23T09:02:03+0200 Virtualizáció PDA_FAN
  win10 frissitese win11-re, avagy lehet elni ujratelepites nelkul? a valasz, igen! 19  2025-08-23T06:51:59+0200 Microsoft Windows x-daemon
  Létezik olyan kapcsoló modul ami beépíthető buta kapcsoló mögé és zigbee hálózaton keresztül bindelhető hub nélkül? 23  2025-08-22T13:41:18+0200 Elektronika, Elektromos eszközök denton
  NIS2 tapasztalatok 94  2025-08-22T10:33:47+0200 Közösségi kerekasztal pentike
  Melyik AI (vagy nem AI) eszköz tud összeszedni információt webről 17  2025-08-21T18:36:58+0200 Segédprogramok gee

DragonFly BSD - telepítés, cvsup, kernel fordítás, buildworld

Címkék

Ma folytatjuk a BSD rendszerekkel való ismerkedést. A mai nap témája a DragonFly BSD, amely egy ígéretes FreeBSD fork.

A Dragonfly BSD Matthew Dillon korábbi FreeBSD fejlesztő FreeBSD 4.x forkja. A terjesztés jelenleg még fejlesztés alatt áll, belőle publikus kiadás még nem jelent meg soha. A rendszer annyira fejlesztés alatt álló, hogy még telepítője sincs. A rendszer telepítésére több módszer is létezik, ebből az egyik a Live CD-ROM-ról való telepítés. Ezt (plusz a kernel fordítást és a rendszer újrafordítást (buildworld)) ismerteti ez a kicsit hosszabb, 32 képpel illusztrált útmutató.

1.) A DragonFly BSD fejlesztői CD verziójának előkészítése

1.1) Töltsük le a dfly-20040506.iso névre hallgató fejlesztői snapshot ISO image gzip-pelt verzióját innen.

1.2) Bontsuk ki az archive-ból:

# gzip -d dfly-20040506.iso.gz

majd írjuk CD-re (használj újraírható CD-t, óvd a környezeted!).

A CD-ROM-ra rábootolva egy teljesen működő DragonFly BSD-t kapunk. A merevlemezed nem módosul azzal, hogy bebootolsz a CD-ROM-ról.

FIGYELEM!!! A DRAGONFLY BSD FEJLESZTÉS ALATT ÁLL ÉS JELENLEG KÍSÉRLETI JELLEGGEL MŰKÖDIK. A CD-ROM FELHASZNÁLÁSÁHOZ ERŐSEN AJÁNLOTT VALAMILYEN BSD RENDSZEREN SZERZETT ELŐZETES TAPASZTALAT. Ha csak tesztelni szeretnéd a DragonFly BSD-t, akkor a CD-vel bebootolva egy teljesen működő konzolos rendszert kapsz. A rendszer ilyenkor swap nélkül működik, ezért a fizikai memóriád mérete korlátozhatja a használatot.

2.0) Automatikus telepítés

A DragonFly BSD egyelőre nem rendelkezik automatikus telepítővel. A fejlesztők jelenleg dolgoznak ilyen keretrendszeren, de ezt nem tartalmazza a CD-ROM.

3.) Manuális telepítés

3.1) A manuális telepítés során a következő parancsok végrehajtásával tudod a DragonFly BSD operációs rendszert a merevlemezedre telepíteni. A sikeres telepítéshez ismerned kell a BSD-szerű UNIX rendszereket. Az elsődleges IDE merevlemezed általában a ``ad0'' névre hallgat, és a DragonFly BSD általában az merevlemez első slice-ára települ.

A telepítés megkezdéséhez bootoljunk rá a frissen sütött CD-ROM-ra. Ha rábootoltunk a CD-ROM-ra várjuk meg, hogy bejelentkezzen a boot menü:



3.2) Ha a kernel elindította a rendszert, és megkaptuk a prompt-ot, akkor bejelentkezhetünk ``root'' felhasználóként. A bejelentkezésnél nincs ``root'' jelszó!

3.3) Ha a merevlemezünk már használatban volt, akkor a sikeres telepítés érdekében távolítsuk el a régi boot blokkot.

FIGYELEM! A KÖVETKEZŐ LÉPÉSEK TELJESEN TÖRLIK ÉS ÚJRAPARTÍCIONÁLJÁK A MEREVLEMEZT! CSAK AKKOR FOLYTASD A TELEPÍTÉST, HA TUDOD MIT TESZEL!

# dd if=/dev/zero of=/dev/ad0 bs=32k count=16

# fdisk -IB ad0

3.4) A következő lépés az, hogy boot blokkot telepítünk a merevlemezre és ellenőrizzük a telepítést:

# boot0cfg -B ad0

# boot0cfg -v ad0

3.5) Ezután létre kell hoznunk egy kezdeti címkét (initial label) a HDD kiválasztott slice-án. Ha problémád van a bootolással, akkor próbáld meg kinullázni slice első 32 blokkját dd-vel (dd if=/dev/zero of=/dev/ad0s1 bs=32k count=16), majd telepítsd újra a label-t.

# disklabel -B -r -w ad0s1 auto

Andrew Morton: Linux 2.6.6-mm1

Címkék

Tegnap, a stabil 2.6.6-os Linux kernel kiadása után 5 órával már kint is volt az első -mm patch.

Néhány változás: bk-agpgart.patch

bk-alsa.patch

bk-cifs.patch

bk-cpufreq.patch

bk-driver-core.patch

bk-drm.patch

bk-i2c.patch

bk-libata.patch

bk-netdev.patch

bk-pci.patch

bk-scsi.patch

bk-usb.patch

Letölthető a szokásos helyről, itt.

Változások listája: itt.

A saga folytatódik...

Címkék

A múlt heti hardver-cserét sajnos nem sikerült száz százalékosan befejezni, így vasárnap ismét leállás lesz az ftp.fsn.hu szolgáltatásban, amely most a fájlszerver backend helyett a frontendeket fogja érinteni.

Milyen naplózó filerendszert tegyek Linux alá?

A napokban vetődött fel az a kérdés a Fórumban, hogy vajon milyen naplózó filerendszert kellene telepíteni manapság egy Linux disztó alá, hogy a legnagyobb teljesítményt és biztonságot érhessük el.

Mintha Justin Piszcz meghallotta volna a kérdést, mert azonnal össze is ütött egy FS benchmark versenyt a népszerű linuxos journaling filerendszerek között. A versenyben az alábbi FS-ek szerepeltek: ext2 (mint kakukktojás), ext3, reiserfs, jfs, xfs. Lássuk mit állapított meg a teszter (huh, de sok ilyen tesztet láttunk már...).A teszt során használt konfiguráció:

Számítógép: Dell Optiplex GX1

CPU: Pentium III 500MHZ

RAM: 768MB

SWAP: 1536MB

Controller: Promise ATA/100 TX - BIOS 14 - IN PCI SLOT #1

Merevlemezek:

1] Western Digital 250GB ATA/100 8MB CACHE 7200RPM

2] Maxtor 61.4GB ATA/66 2MB CACHE 5400RPM

Tesztelt merevlemez: The Western Digital 250GB

A tesztek 2.4.26-os Linux kernel alatt futottak, 2.3.2 libc verzióval.

A teszt az alábbiakból állt:

- 10.000 file létrehozása ``touch''-csal

- ``find'' futtatása a könyvtárban

- könyvtár törlése

- 10.000 könyvtár készítése ``mkdir''-rel

- ``find'' futtatása a könyvtárban

- a 10.000 könyvtárat tartalmazókönyvtár törlése

- kernel tarball másolása egyik diszkről a tesztelt diszkre

- stb.

A konklúzió szerint ha valaki naplózó FS-t szeretne, akkor a következőkből célszerű választania (a tesztjei alapján): JFS, ReiserFS vagy XFS. A cikk írója meglepődött az ext3 lassúságán, hiszen - mint, írja - ez az alapértelmezett FS számos disztribúcióban.

A tesztet megtekintheted itt.

Ismerjük meg a TCP reset támadásokat (1. rész)

Pár hete arról olvashattunk a médiákban, hogy egy komoly sebezhetőség található a TCP-ben (Transmission Control Protocol). A hibára Paul Watson hívta fel a figyelmet Slipping In The window: TCP Reset Attacks című munkájában. Akkor neves szakemberek a hibát komolynak nevezték, míg egyes hírforrások szerint csak a média fújta fel az ügyet.

A KernelTrap most egy interjút készített Theo de Raadt-tal, az OpenBSD projekt vezetőjével, hogy kiderüljön mi is az igazság. Az interjú egy két részes cikksorozat része. A cikksorozat célja, hogy segítségével az olvasó jobban megérthesse a TCP Reset Attacks típusú támadások mibenlétét.

A cikksorozat első részében egy kis ismertetőt olvashatunk a TCP működéséről.

A sorozat első részét megtalálod itt.

Új KNOPPIX ISO image (20040510)

Címkék

Ma megjelent a május 4-én kiadott KNOPPIX 3.4 frissített ISO-ja.

Változások:- eltávolításra került néhány SCSI kernel modul a knoppix26-ból (2.6-os kernel), mert instabilak voltak

- bootfloppy generáló szkript a Knoppix 'Utilities' menüben

- merevlemez telepítő frissítések

- 'knoppix splash' javítások

- időzóna és nyelv add-on-ok

- captive-ntfs változások

- e100/eepro100 frissítések

- szokásos Debian frissítések

A teljes változások logja itt.

Linus Torvalds: Linux 2.6.6

Címkék

Kicsit hosszabb kihagyás után Linus kiadta a stabil 2.6.6-os Linux kernelt. Az új anyagban NTFS, XFS, FAT és CIFS frissítések találhatók. Leállításkori IDE cache-flush javítás, és a szokásos architektúra frissítések: ppc, sparc, s390 és ARM (plusz néhány x86-64 javítás).Az anyag letölthető: patch-2.6.6.bz2, FULL

A változások listája Linus levelében itt.

A kernel patcheléshez segítséget itt találsz.

Ingyenes Canon i250 driver

Címkék

Nem tudom, hogy ki tud még róla, én ma találtam ezeket a drivereket a Canon i250-es nyomtatóhoz, ami elvileg nem támogatott Linux alatt, csak a turboprint-tel, viszont most itt van egy teljes értékű ingyenes driver az új-zélandi

Canon oldalról
.

Bill Joy csatlakozott a Fortune magazinhoz

Rik Kirkland vezető szerkesztő bejelentése szerint Bill Joy - Unix guru, a BSD egyik atyja, a vi editor megalkotója, a Sun Microsystems egyik alapítója - csatlakozott a Fortune magazinhoz, mint szerkesztőségi tanácsadó. Joy az új munkahelyén a tudomány és technika rovatok szerkesztőinek tanácsadója lesz, és emellett alkalmanként cikkeket fog írni.

Bill Joy tavaly szeptemberben 21 év után hagyta el a Sun Microsystemet.

A Yahoo!Finance cikke itt.

HUP SSL certificate - segíts te is!

Címkék

Sziasztok,

A HUP, mint egyre komolyodó, egyre több szakmai értéket képviselő portál sajnos még mindig nem rendelkezik hivatalos CA (Certificate Authority) által "aláírt" certificate-tel. Segíts összekalapolni ezt a rendes körülmények között nem túl nagy, évi kb. 20.000 forintos összeget (árakról infó itt, típus: SSL Szerver, C osztály). Mint mindenki tudja, a HUP non-profit "szervezet", nem rendelkezik bevétellel, és senki sem várhatja, hogy trey a saját zsebéből fizesse ki az egész összeget, miközben mindenféle anyagi ellenszolgáltatás nélkül tartja fenn a portált. Pár szó a certificate mibenlétéről:

A certificate, azaz csúnya és kicsit félrevezető magyar szóval tanúsítvány része annak titkosítási folyamatnak, amit a HUP https része is használ. Addig nem igazán használható, amíg egy aláíró szerv (CA, azaz Certificate Authority) nem hitelesíti, ez viszont pénzbe kerül. Erre gyűjtünk.

Miért is kell ez:

Amíg a CA nem hitelesíti a HUP certificate-jét, addig sajnos sok helyen a https oldalt nem lehet megnézni (sok ilyesmikre érzékeny céges tűzfal élből levágja a kapcsolatot), vagy ahol meg lehet, mindenképp egy nem túl bizalomgerjesztő figyelmeztető üzenet jelenik meg, melyben a böngésző arra panaszkodik, hogy nem hitelesített tanúsítvánnyal találkozott.



Egyelőre felmérjük az ``adakozó kedvet'', ezért egy szavazást találsz a cikk mellett. Ebben jelezd, hogy adakoznál-e ilyen célra, és a hozzászólásokban, hogy kb. mennyivel tudnál hozzájárulni a certificate igényléséhez.

A PF User's Guide BSD Licenc alatt

Címkék

Daniel Hartmeier, az OpenBSD-s PF szerzőjének bejelentése szerint a OpenBSD PF User's Guide munka BSD Licenc alá került. Nick Holland és Joel Knight nagyszerű munkája mostantól szabadon felhasználható bárkinek bármilyen céllal. Ettől a pillanattól kezdve lehetőség van arra, hogy más projektek - mint például a FreeBSD, amely nemrég olvasztotta be a PF-et - közreműködhessenek a dokumentum fejlődésében.

Az Intel dobta a szerver és desktop processzor terveit

Címkék

Jönnek a dupla magos processzorok

A Reuters szerint az Intel pénteken bejelentette, hogy félredobta két új processzorának fejlesztését annak érdekében, hogy sokkal hatékonyabb CPU technológiát fejleszthessen ki.

A cél a processzorok hőtermelésének csökkentése, hiszen az egyre nagyobb órajelű processzorok sokkal drágább és zajosabb hűtőket igényelnének. Az Intel a negyedik generációs Pentium 4 processzorok, a Tejas kódnévre hallgató chipek fejlesztését törölte. Emellett törlésre került az új, kis kategóriájú szerverekbe szánt Xeon processzor, a Jayhawk is, amely szintén a Tejas architektúrára épült volna.

E processzorok helyett az Intel valószínűleg jövőre már dual-core processzorokat fog kínálni a desktop és notebook gépek számára. A dupla magos processzorok - ahogy nevük is mutatja - az eddigivel ellentétben nem egy, hanem két magot (core) fognak tartalmazni.

``Ez olyan, mintha két hengert tennénk az autóba egy nagy henger helyett.'' - mondta Nathan Brookwood elemző.

Egy ``hengerrel'' az Intel jövőbeli chipjei túl forróak lennének. - folytatta Brookwood.

Az ún. dupla magos technológia lehetővé teszi, hogy a processzorok kétszer akkora teljesítmény leadása mellett kevesebb energiát használjanak fel. A dupla magos processzorok esetén azoknak nem szükséges túl magas órajelen futni a megfelelő teljesítmény eléréséhez.

A bejelentésről itt.

Az Intel rivális AMD szintén tervezi a 64 bites processzorainak dual core verzióját. Ezek a processzorok a 2005-ös év végére várhatók.

Jelenleg csak az IBM szerverekben található ilyen iker magos processzor, de a nagy gyártók közül a Sun Microsystems (korábbi cikk) és a Hewlett Packard is dolgozik a saját implementációján.

Bővebben itt.

Vasárnap leállás!

Címkék

Az elmúlt három évben az FSN egyes szerverei folyamatosan üzemeltek, így némelyikben megérett már pár alkatrész a cserére. Vasárnap ezen elhasználódott eszközök leváltása fog megtörténni kevésbé elhasználódottakra, amelyek reméljük kitartanak majd legalább a következő három évig.

A cserék miatt az FSN Axelero Rt-nél elhelyezett számítógépek nyújtotta szolgáltatásaiban rövidebb-hosszabb kiesések várhatók. A legjelentősebb leállás az ftp.fsn.hu-t fogja érinteni. A szerelés remélhetőleg nem lesz kihatással a portál működésére.

A türelmet előre is köszönjük.A fenti akcióval átveszi az FSN váltott-uptime verseny váltóbotját a portál:

ns.fsn.hu: 7:17PM up 654 days, 1:08, 1 user, load averages: 0.09, 0.05, 0.00

hup.hu: 7:17PM up 586 days, 5:17, 2 users, load averages: 0.02, 0.06, 0.07

OpenBSD - a rendszer építése forrásból (kernel)

Címkék

Nna, a visszajelzésekből úgy látom, hogy egyre többen érdeklődnek az OpenBSD iránt. Remélem, hogy az első kettő írás kedvet csinált ehhez a szoftver disztribúcióhoz. Aki esetleg most kapcsolódna be a dologba, az megtalálja a telepítésre vonatkozó információkat itt, a telepítés után ajánlott első lépések leírását itt.

A mai napon azt nézzük meg, hogy hogyan kell saját, az OpenBSD csapat által is támogatott kernelt fordítani. Vágjunk bele:

1.1.) az OpenBSD kiadások

Az OpenBSD-nek három kiadása (flavor = íz, aroma, illat, ahogy az OpenBSD-sek hívják) létezik:

-release: Az OpenBSD-nek az a verziója, amely 6 hónaponként került kiadásra CD-n

-stable: A release, plusz azok a kritikus patchek, javítások (az errata oldalról), amelyek fontosak a biztonságos és stabil működéshez

-current: Az OpenBSD ``éppen aktuális'' verziója, amely fejlesztés alatt áll, és amelyből 6 havonta -release lesz

Grafikusan ez valahogy így néz ki:





A legtöbb felhasználó a -release és a -stable kiadásokat használja, de vannak szép számmal akik mindig a legfrissebb állapotot tükröző -current-et futtatják. Míg a -release és a -stable stabilitást nyújt a felhasználóinak, addig a -current-ben előfordulhat, hogy valami éppen nem működik.

Éppen ezért azoknak, akik éles rendszert futtatnak a -stable (patchelt -release) javasolt. Akiknek az a legfontosabb, hogy állandóan a legfrissebb, legújabb funkciókat használhassák (tapasztalt felhasználók, fejlesztők, tesztelők) esetleg azon az áron is, hogy néha valami nem működik, nekik ajánlható a -current kiadás.

1.2.) snapshot-ok

A kiadások mellett léteznek ún. snapshotok (pillanatképek) is a fejlesztés éppen aktuális állásáról. A kiadások közt levő fél éves ciklusokban jelennek meg a snapshotok az FTP oldalakon. A snapshotok - mint ahogy nevük is mutatja - a fejlesztés éppen aktuális pillanatát ``fényképezik'' le, az éppen aktuális kódból generálónak, így nagyon könnyen előfordulhat, hogy a snapshotok nem működnek 100%-osan.

Kinek jók akkor a snapshotok? A snapshotok igazából a -current felhasználóknak jó. A snapshot jó kiindulópont lehet a -current usernek, hiszen azt telepítve könnyen szinkronizálhatja magát a -current fához.

1.3.) tartsuk a dolgokat szinkronban!

El is érkeztunk minden operációs rendszer biztonságos és stabil működésének sarkalatos pontjához. Egy operációs rendszer csak akkor működik megfelelően, ha az karban van tartva. Ez azt jelenti, hogy a megfelelő verziót használjuk, és a megjelent biztonsági és funkcionális patcheket, javításokat alkalmazzuk a rendszerünkön. Nincs ez máshogy az OpenBSD esetében sem.

Az OpenBSD-vel ismerkedőknek fontos megérteni, hogy az OpenBSD egy operációs rendszer, plusz a megfelelő programok utility-k halmaza, nem pusztán egy operációs rendszer mag (kernel). Ellentétben a Linuxszal (a kernelről beszélünk), ahol a disztribútorok által összeállított programok több kernel verzióval is ragyogóan működnek, a BSD világban az egész operációs rendszer egy egészet alkot, amelyet nem szabad szétválasztani. A OpenBSD három fő részből áll:

- OpenBSD kernel

- az ``userland'' (programok, utility-k, amelyek szerves egységet alkotnak a kernellel)

- port fa (ports tree) (külső 3party alkalmazások)

Ennek a három komponensnek szinkronban kell lennie, máskülönben nemkívánatos működés lehet a ``káosz'' eredménye. Például: nem fogsz tudni vadonatúj port-okat futtatni mondjuk egy-két hónapos rendszeren, vagy nem tudsz működő kernelt fordítani a -current forrásból, ha az ``userland'' programjaid nem a legújabbak. Tehát a jelszó: szinkronizálás!

Hogyan?

A szinronizálás legegyszerűbben úgy történhet, hogy letöltjük a kernel és az ``userland'' forrását, lefordítjuk, majd telepítjük. Ezzel az első kettő komponens naprakész. Természetesen szinkronban kell tartanunk a port fát is (erről később). Egyetlen nagyon fontos dolog van, amelyet észben kell tartani a forrásból való frissítéskor: a frissítés egyirányú, azaz csak upgrade-lni lehet. Downgrade-re nincs lehetőség. A frissítés iránya mindig a korábbiról az újabbra, a -stable-ról a -currentre történik. Nem teheted meg azt, hogy az OpenBSD 3.5-current-et használva meggondolod magad (mert mondjuk valami nem működik) és visszalépsz a 3.5-stable-re. A választás a magad választása, ilyenkor csak azt tudod megtenni, hogy újratelepíted a rendszert az elejéről (from scratch). Az OpenBSD csapat ebben neked nem fog segíteni, hiába is fordulsz hozzájuk!

Mielőtt -current-re frissítesz GONDOLD MEG KÉTSZER!

1.4.) Miért van szükségem saját kernelre?

Általában nincs szükséged saját (nem a GENERIC file alapján fordított) kernelre, megfelelő az OpenBSD csapat által szállított GENERIC kernel.

A kernelt többféleképpen is ``felépítheted''. Fordíthatod a GENERIC (konfig)file alapján (ez az OpenBSD csapat által szállított kernel), de készíthetsz saját kernelt is úgy, mint mondjuk Linux alatt. A saját kernel készíthető -release, -stable és -current kódból is, akárcsak a GENERIC kernel. Egy óriási különbség van a saját és a GENERIC kernel között. Az előbbit nem, míg az utóbbit támogatja az OpenBSD csapat.

A GENERIC kernel konfigurációs file (amely alapján a GENERIC kernelt le tudjuk fordítani) úgy van felépítve, hogy az a legtöbb ember számára megfelelő. Sok ember azt hiszi, hogy ha saját kernelt fordít, akkor jobb lesz a rendszerének működése, teljesítménye. Ez nem igaz az OpenBSD esetén! Csak speciális igények esetén kell saját (nem a GENERIC konfig alapján) kernelt fordítanod!

Néhány ok ami miatt saját kernelt fordíthatsz:

- Biztos vagy benne, hogy tudod mit teszel, és el akarsz távolítani bizonyos számodra szükségtelen eszközmeghajtó-programokat (device drivers), mert olyan rendszerre akarod telepíteni az OpenBSD-t, amely nagyon kevés memóriával rendelkezik

- Biztos vagy benne, hogy tudod mit teszel, és engedélyezni akarsz olyan funkciókat, amelyek alapértelmezetten nincsenek engedélyezve, vagy le akarsz tiltani olyan funkciókat, amelyek alapértelmezett engedélyezve vannak, de számodra szükségtelenek

- Biztos vagy benne, hogy tudod mit teszel, és engedélyezni szeretnél csak kísérleti jelleggel elérhető funkciókat

- Biztos vagy benne, hogy tudod mit teszel, és olyan speciális kivánságaid vannak, amelyeket a GENERIC kernel nem elégít ki, ezért saját kernelt fordítasz (viszont ha nem működik valami a saját kerneleddel, akkor nem fogod megkérdezni, hogy miért nem működik)

Néhány ok ami miatt _biztos_, hogy nem kell saját kernel fordítanod:

- Normális esetben nem kell saját kernelt fordítanod

- Saját kernellel nem lesz gyorsabb a rendszered

- Saját kernellel könnyen készíthetsz kevésbé megbízható rendszert

- Saját kernellel nem kapsz támogatást a fejlesztőktől

- Ha valami hibát találsz, akkor azt előbb reprodukálnod kell majd a GENERIC kernellel is, mielőtt azt szeretnéd, hogy a fejlesztők komolyan foglalkozznak a problémáddal

- A felhasználók és a fejlesztők nevetni fognak, ha tönkreteszed a rendszered

- A saját fordító (compiler) opciók gyakrabban idéznek elő fordító program hibákat, minthogy gyorsítanák a rendszer működését

1.5.) a kenrel konfigurációs fileok

Az OpenBSD kernel ``építésének'' módja a konfigurációs fileokban van rögzítve. Ezek a filok a /usr/src/sys/arch/$arch/conf/ könyvtában találhatóak alapértelmezés szerint (ahol a $arch az éppen használt architektúrát jelenti). Minden architektúrának van egy olyan fileja, amelyet GENERIC-nek hívnak. Ebből a fileból lehet előállítani a standard OpenBSD kernelt a különböző platformokra. Léteznek még egyéb kernel konfigurációs fileok is, amelyekkel különböző céllal létrehozott kerneleket lehet előállítani. Ilyen fileok például a DISKLESS, RAMDISK, RAMDISKB, RAMDISKC, amelyek nevéből lehet következtetni arra, hogy milyen kernelt lehet belőlük ``építeni''.

A konfigurációs filet a config(8) dolgozza fel, amely létrehozza és előkészíti fordításra használt könyvtárt a ../compile útvonalon (tipikus telepítés esetén a /usr/src/sys/arch/$arch/compile/ útvonalon). A config(8) szintén létrehoz egy Makefile-t, és az összes többi olyan filet, amely a sikeres kernelfordításhoz szükséges.

Példaként nézd meg az i386-os architektúra konfigurációs filejait itt.

A konfigurációs fileok architektúránként változnak, de van közös részük is. Ezért van az, hogy a fileok elejében ezt olvashatjuk:

include "../../../conf/GENERIC"

Ez azt jelenti, hogy a platform-független opciók ebben a fileban vannak elhelyezve, és ezt használja az összes platform kiegészítve a saját, csak az ő platformjára jellemző opciókkal.

Ez a file a src/sys/conf/. Ha saját kernel konfig filet hozol létre, akkor nézd meg ezt a filet is!

1.6.) saját kernel építése

A saját kernel készítésére vonatkozó teljes és részletes leírást megtalálod a man afterboot(8)-ban, itt csak egy rövid leírást talász:

Ahhoz, hogy saját kernelt fordíthass, szükséged lesz a forráskódra. Ezt vagy a hivatalos CD-ROM-on (3-as diszk), vagy az FTP oldalakon találod.

Forrás telepítése CD-ről:

A következő példa feltételezi, hogy a 3-as CD fel van mountolva a /mnt alá:

# cd /usr/src

# tar xvzf /mnt/src.tar.gz

Forrás telepítése FTP-ről:

Ha a forráskódot FTP-ről töltöd le, akkor szükség lesz a src.tar.gz és a sys.tar.gz fileokra is. Az első az ``userland'' forrása, míg a második a kernelforrás. (A CD-ROM-on ez a két file egybe van dolgozva). Az FTP-s letöltés esetén ezt a két file-t bontsd ki a /usr/src könyvtárba.

A legegyszerűbb módon úgy tudsz saját kernelt fordítani, hogy a GENERIC filet használod fel (emlékezz! csak indokolt esetben kell eltérni a GENERIC filetól! a legtöbb esetben semmi sem indokolja, hogy módosítsd a hivatalos kernel konfigurációt!).

A GENERIC file-t megtalálod a /usr/src/sys/arch/$ARCH/conf/GENERIC útvonalon, ahol a $ARCH az általad használt architektúrát jelöli. Ez a legtöbb esetben i386.

A fordítás (ha a forrásfa csak olvasható helyen van):

# cd /akárhova

# cp /usr/src/sys/arch/$ARCH/conf/SOMEFILE VALAMI

(ahol a VALAMI általában a rendszer neve. Például ha a gép a foobar.foo.hu, akkor a VALAMI legyen FOOBAR. ez nem kötelező, csak ajánlott, és bevett szokás)

# vi VALAMI (változtassunk, ha szeretnénk)

# config -s /usr/src/sys -b . VALAMI

ezt két parancs követheti:

# make depend

- VAGY -

# make clean

# make

A ``make depend''-et akkor kell futtatni, ha valami változott a forrásban (pl. patchelted, vagy frissítetted), azaz általában mindig. A ``make clean''-t abban az esetben kell használni, ha megváltoztattuk a kernel konfigurációs opciókat és/vagy a forrásfában nagyobb változtatás történt. A ``make clean'' egyébként bármikor használható, egyetlen hátránya a hosszabb ``build''-elési idő.

A fordítás (ha a forrásfa írható/olvasható):

# cd sys/arch/$ARCH/conf

# cp SOMEFILE VALAMI

# vi VALAMI (változtass igényed szerint)

# config VALAMI (bővebben infóért nézd meg a man config(8)-ot)

# cd ../compile/VALAMI

# make

Ahol az $ARCH az általad használt architektúra (pl. i386).

A kernel helyére másolása:

# cp /bsd /bsd.old

# cp /sys/arch/$ARCH/compile/SOMEFILE/bsd /bsd

Ha valami balul ütne ki, akkor a boot időben válaszd a korábbi kernelt:

boot> bsd.old

és ebben az esetben a korábbi működő kerneled (/bsd.old) indul el a frissen fordított helyett (/bsd).

Mára ennyi, legközelebb folytatjuk.



Az írás a hivatalos OpenBSD FAQ lapján készült.

Fedora Core 2 Test 3 ISO-k törlésre jelölve

A Fedora Core 2 test 3 ISO-k még 24 órán keresztül elérhetők a HUP-ról, azután törlésre kerülnek. Kérek mindenkit, hogy 2004. 05. 09. 13:00 óráig fejezze be a letöltést.

www.hup.hu/~trey/FC2_test3/FC2-test3-i386-disc1.iso

www.hup.hu/~trey/FC2_test3/FC2-test3-i386-disc2.iso

www.hup.hu/~trey/FC2_test3/FC2-test3-i386-disc3.iso

www.hup.hu/~trey/FC2_test3/FC2-test3-i386-disc4.iso

www.hup.hu/~trey/FC2_test3/MD5SUM

Az ET kitart a szoftveres szabadalmak bevezetése mellett

Címkék

Az Európai Tanács elnökségi posztját betöltő Írország a szoftverek, adatstruktúrák és üzleti módszerek szabadalmaztatását lehetővé tevő direktívát nyom keresztül. Ha a tanács tagjai Május 18-ig nem döntenek másképp, akkor a szoftverek szabadalmaztatása lehetővé válik az EU-ban. Tiltakozni továbbra is a

http://petition.eurolinux.org/

http://www.ffii.org/

oldalakon lehet.Az Európa Parlament októberben a szoftverek, adatstruktúrák és üzleti módszerek szabadalmaztatása ellen tette le voksát. Most az Európai Tanács mindezt semmibevéve, különösebb vita nélkül ezzel ellentétes szellemű döntést készül hozni. Az EP tagjai nemzeti hovatartozástól és pártállástól függetlenül elítélték ezt az antidemokratikus gyakorlatot.

A szoftveres ötletek, módszerek szabadalmaztatása a szabad szoftverek hasznalátát sok esetben illegállissá teheti. Az amerikai példából láthattuk, hogy gyakran teljesen nyilvánvaló ötletek hosszadalmas, sok millió dollárt felemésztő jogi csatározásokhoz vezethetnek, és ezek a komolyabb anyagi háttérrel rendelkező félnek kedveznek. Ezért is lobbizott az Európai Kis és Középvállalatok szövetsége vehemensen a szoftveres szabadalmak európai bevezetése ellen, hiszen így minden program és portál szabadalmi ügyvédek céltáblájáva válhat.

Forrás : http://swpat.ffii.org/news/04/cons0507/index.en.html

A SCO csökkenti a kiadásait, alkalmazottakat bocsátott el

Címkék

Április közepén a SCO egyik nagy befektetője a Baystar Capital felszólította a UNIX gyártót, hogy azonnal vásárolja vissza tőle a 20.000 darab SCO részvényét. Akkor a másik befeketető, a Royal Bank of Canada még várakozó állásponton volt a befektetésének sorsát illetően. Most úgy tűnik, hogy ez a befektető kivonul a SCO-ból. Május 5-én a Royal Bank of Canada értesítette a SCO-t, hogy a korábban vásárolt 10.000 darab Series A-1 Convertible Preferred (átváltható elsőbbségi részvény) SCO részvényét átváltja 740,740 darab közönséges SCO részvényre. Emellett értesített a céget, hogy részvényeinek egy részét, 20.000 darabot, eladta a Baystar Capital-nak.

A Santa Cruz Sentinel úgy tudja, hogy a SCO alkalmazottakat bocsátott el annak érdekében, hogy a következő negyedéve nyereséges lehessen. Egyesek szerint ez a befektető Baystar felhívására történt. Az elbocsátott emberek száma 12, amely tekintve az összes dolgozók számát (275 világszerte) nem kevés.

Blake Stowell szóvivő szerint a 10% alatti leépítés a vezető pozícióban levő embereket nem érintette.

Az üggyel foglalkozik az Eweek itt, és a Linuxinsider itt.

kexec: rebootoljuk gyorsabban a Linuxot!

Címkék

Pont egy évvel ezelőtt írtam már a kexec-ről. Akkor még csak arról számolhattam be, folyamatban van a fejlesztése az akkor még fejlesztői állapotban levő 2.5-ös Linux kernelhez. Azóta már megjelent a stabil 2.6-os kernel is, úgyhogy nézzük mi változott azóta:

Abban az esetben, ha munkád nem követeli meg azt, hogy rebootold a Linuxod napjában többször, vagy nem dolgozol olyan környezetben, ahol a rendszer pár perces kiesése is gondot okozhat, valószínűleg nem fog érdekelni, hogy az operációs rendszered 20 másodpercet, vagy mondjuk 2 percet bootol. Ellenkező esetben megtennél mindent, hogy minél rövidebb időre csökkentsd a rendszered elindulásának idejét...

A gyors rendszerindítás annyira foglalkoztatja a kernel fejlesztőket is, hogy megszületett a kexec, amely pont ezt hivatott szolgálni. A kexec segítségével elérhetjük azt, hogy egy új Linux kernelt bootoljuk be anélkül, hogy keresztül kellene mennünk a bootloader-en. A kexec megkönnyíti a kernel fejlesztők, szoftver fejlesztők, ISP-k, és más olyan felhasználók életét, akiknek napjában többször is újra kell indítaniuk a gépüket, vagy az újraindítás időtartamát minél kisebbre kell szorítaniuk.

A kexec-nek egyetlen korlátja van jelenleg: csak 32-bites x86 platformon működik. Ahogy a számítógépek fejlődnek, és egyre bonyolultabb lesz a belső felépítésük, úgy számíthaunk arra, hogy egyre hosszabb lesz a rendszerek boot-olási ideje is. Az újraindítások időtartama egyre nagyobb, ha mondjuk sok eszközt kiszolgáló SCSI buszaink vannak, vagy a gépünkben nagy mennyiségű ECC memória van, stb. Az elvégzett tesztek szerint a bootolási idő jelentős részét a firmware szakasz adja (az a szakasz, amikor a rendszer felismeri és ``megszólítja'' a hozzákapcsolt fizikai eszközöket). Ha ezt a szakaszt át tudnánk lépni, akkor jelentősen lerövidíthetnénk a rendszer újraindításának idejét. A kexec pontosan ezt teszi.

Ahhoz, hogy megismerjük a kexec működését, fontos, hogy átlássuk a Linux kernel boot folyamatát. Ez a folyamat két részből áll: a bootloader szakaszból és a kernel szakaszból.

A bootloader szakasz fő részei a hardver szakasz, a firmware szakasz, az első szintű bootloader (first-level bootloader) és a másod szintű bootloader (second-level bootloader). A boot folyamat azzal kezdődik, hogy bekapcsoljuk a számítógépet. Bizonyos inicializálások után az irányítás a firmware-hez kerül. A firmware-t egyes architektúrákon hívjuk "BIOS" -nak is. A firmware felismeri az egyes eszközöket, pl. a memória kontroller(eke)t, busz eszközöket, háttértárakat, stb. Ezután a firmware a beállítások alapján átadja a vezérlést egy minimális bootloader-nek, amelyet Master Boot Record-nak (MBR) is hívunk. Az MBR vagy merevlemezen, vagy eltávolítható eszközön vagy akár ``hálózaton'' is lehet. A következő lépés az, hogy az MBR az irányítást átadja az operációs rendszernek. Ez a feladat már a másod szintű bootloader-re hárul (gyakran ezt nevezik boot loader-nek). Ez a boot loader teszi lehetővé a felhasználónak, hogy kiválassza a futtatandó kernelt, betölti a kernelt a memóriába a megadott paraméterekkel, inicializálja a kernelt, kialakítja a megfelelő futtatási környezetet, majd ``futtatja'' a kernelt.

Az előzőekben ismertetett szakaszokat hivatott áthidalni a kexec, hiszen a következő lépcsőfok már a kernel szakasz, ahol a kernel átveszi az irányítást.

Mi az a kexec?

A kexec Eric Biederman munkája, amely jelenleg is folyamatos fejlesztés alatt áll. A kexec egy kernel patch, amely lehetővé teszi, hogy egy futó kernelből egy másik kernelt indítsunk anélkül, hoyg végig kelljen mennünk a bekapcsolástól a másod szintű bootloader-ig terjedő szakaszokon. Közben nincs hardver reset, nincs detektálás és inicializálás, és semmi olyan lépés, amely lelassíthatná a boot folyamatot.

Hogy működik?

A kexec két részből áll. Egy kernel patch-ből és egy ``user-space'' segédprogramból, amely a kexec-tools névre hallgat. A patchel meg kell foltozni a kernelünket, majd egy kernelt kell fordítani a patchelt forrásból a CONFIG_KEXEC opciót engedélyezve. A kexec-tools segédprogramot le kell fordítani az operációs rendszerünkön.

A kexec használata:

# kexec -l kernel_image -append="kernel_paraméterek"

konkrétabban:

# kexec -l /boot/bzImage -append="root=/dev/hda1"

Ha a már futó kernelt szeretnénk rebootolni, akkor a

# kexec -e

paranccsal adhatunk utasítást erre.



A kexec patcheket és az user-space utility-t letöltheted a legfrissebb 2.6-os kernelekhez innen. Bővebb infót a kexec-ről az IBM developerWorks oldalain olvashatsz itt.