Aktív fórumtémák

Tárgy Válaszok Legutóbbi beküldés Fórum Szerző
  Írj egy szerinted igaszságos SZJA számoló függvényt 98  2025-09-05T01:49:30+0200 Közösségi kerekasztal EspOS
  Kamera elhelyezésénél kinek a jogai fontosabbak? 30  2025-09-05T01:37:04+0200 Hálózatok egyéb kikepzo
  [Szavazás] Át kellene állni a többkulcsos adórendszerre Magyarországon? 181  2025-09-05T01:02:12+0200 HUP cikkturkáló trey
  188.x.y.0 67  2025-09-04T23:03:00+0200 Hálózatok általános EspOS
  ESP-01 + Tasmota + Relé 93  2025-09-04T23:01:32+0200 Közösségi kerekasztal hnsz2002
  I2C probléma Yocto 5 alatt Recomputer R1035 el 2025-09-04T22:16:39+0200 UNIX haladó wolfwood
  Német agybaj újratöltve: Illegálissá válhat a reklámblokkolás, börtön is járhat majd érte 705  2025-09-04T21:44:03+0200 Web, mail, IRC, IM, hálózatok jevgenyij
  Proxmox ötletelés - Intel lga2011-v3-ról, AMD AM5-re? 16  2025-09-04T21:29:30+0200 Virtualizáció HandsOfVelika
  Telekom vs Cludflare probléma 320  2025-09-04T20:42:59+0200 Hálózatok általános rviktor
  IceWM: eltűnt Alt+Tab 2025-09-04T20:02:18+0200 Linux-haladó szaszi
  Unaloműző online játék újratöltve 2025-09-04T19:58:09+0200 Játékok bzt
  Személyi igazolvány mindkét oldalának másolatával vissza lehet élni? 108  2025-09-04T19:08:33+0200 Közösségi kerekasztal Charybdis
  Műszerészetet tanulni autodidakta módon Hackinghez 29  2025-09-04T18:25:04+0200 Elektronika, Elektromos eszközök Honkydoo
  Több CNI plugin Kubernetessel 13  2025-09-04T13:49:32+0200 Hálózatok általános SPYFF
  Win11 - DVR 14  2025-09-04T13:15:34+0200 Web, mail, IRC, IM, hálózatok EspOS
  Unaloműző online játékok és azok eredményei #2 755  2025-09-04T06:35:49+0200 Játékok trey
  Milyen hatással lesznek a HUP-ra a Prohardver migránsok? 245  2025-09-04T06:34:27+0200 Közösségi kerekasztal Ritter
  Microsoft Surface Laptop 3 kijelző üveg csere 2025-09-03T21:48:03+0200 Notebook, laptop, mobiltelefon ... pityulaman1983
  Tönkrevághatja az SSD-ket és HDD-ket a Windows 11 legújabb frissítése 41  2025-09-03T16:43:07+0200 HUP cikkturkáló DL3V1
  WinApps for Linux, újabb Windows kompatibilitási megoldás Linuxra. 18  2025-09-03T16:33:23+0200 Linux-haladó Ritter

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.

Kell Debian grafikus telepítővel, hardver felismeréssel? Tessék...

Címkék

Április közepén írtam arról, hogy a Progeny kiadta a Progeny Debian 2.0 fejlesztői verziójának első alpha-ját. A Progeny - a Debian kieszelőjének, Ian Murdock-nak cége - most olyan Debian kiadást készít, amely grafikus telepítőt (Red Hat Anaconda portolt verziója), hardver felismerést, friss programokat kínál felhasználóinak. Nézd meg a képeket:





























A Linuxcompatible.org most feltelepítette a Progeny Debian 2.0 developer verzióját, és egy áttekintést készített a telepítés folyamatáról. Az anyagot megtalálod itt még több képpel illusztrálva.

Néhány Linux disztró összehasonlítása

Címkék

A The Jem Report készített egy összehasonlítást a legnagyobb Linux disztribúciókról.



A vizsgált disztribúciók:

A kereskedelmi Linux disztrók "dobozos" szoftvert árulnak CD/DVD-vel, és papír segédletekkel.

A közösségek által fejlesztett disztrók olyanok, mint a kézi főzésű sör, az első egy-két alkalom munkával/csalódással/hibákkal jár, de néhány probálkozás után az ember jobb/ízlesebb eredményt tud elérni, mint a bolti dobozossal.



A teljes összehasonlítást megtalálod itt.

005: RELIABILITY FIX: Reply to in-window SYN with a rate-limited ACK

Címkék

Az OpenBSD csapat egy megbízhatóságot javító patchet adott ki minap a korábban a HUP-on is említett TCP implementációban található sebezhetőség ellen. A csapat hozzáteszi, hogy az OpenBSD-n eddig is nehéz volt kihasználni ezt a sebezhetőséget, hiszen az OBSD TCP/IP stack már korábban is fel volt készítve Paul Watson prezentációjában ismertetett problémák közül néhányra. Többek közt alkalmazza a random port számok, és random ISN-ek technikáját. A mostani patch további paranoiákat tartalmaz.

Az errata-kat megtalálod: az OpenBSD 3.5-höz itt, a 3.4-hez pedig itt.

A Red Hat bemutatta az új desktop operációs rendszerét

Most, hogy a Red Hat magára hagyta a Fedora-val a nem vállalati desktop felhasználókat, elkészítette az új, Red Hat Desktop névre hallgató asztali gép operációs rendszerét. A RHD, mint a Red Hat jelenlegi desktop ajánlatában szereplő Red Hat Enterprise Linux WS társterméke fog megjelenni. A termék célközönsége a vállalati felhasználókon kívül a mérnökök, szoftver fejlesztők, CAD felhasználók.

Az új stuff ellentétben a WS-sel, nem per rendszer alapon licencelődik, hanem 10-es és 50-es csomagokban kapható majd.

Bővebben itt.

Közben Jeremy Hogan nyilatkozott a Red Hat desktop startégiájáról a NewsForge-nak. A nyilatkozat tulajdonképpen reakció volt Joe Barr egy korábbi kritikáktól sem mentes cikkére.

Weblabor találkozó

Címkék

A hír egy kicsit offtopic ugyan itt, de hátha érdekel pár embert. A Weblabor ötödik szülinapja alkalmából találkozót tart, melyre minden a webprogramozás iránt érdeklődőt szerettel vár. Bővebben a link mögött lehet olvasgatni róla.

Készítsünk saját OpenBSD telepítő CD-t

Címkék

Hozzávalók: internet elérés, egy működő tükör szerver, mkisofs, cdíró program, és kétnapi hideg élelem.

1.) Szemeljünk ki egy szervert, FTP-zzünk fel rá.
2.) Majd keressük az OpenBSD könyvtárat.
3.) Készítsünk elő egy könytvárat a gépünkön. Legyen mondjuk: openbsd.
4.) Ebben hozzunk létre egy 3.5 nevű könyvtárat.
5.) Töltsük le bele a szerverről a tools, i386 könyvtárat, és ízlés szerint a packages könyvtárból, amit csak kívánunk. A szöveges fileok esetleg mehetnek a 3.5-be.
6.) Majd keressük az XF4.tgz, ports.tgz, src.tgz, sys.tgz nevű fájlokat, és rakjuk az openbsd könyvtárunkba. Ezzel az előkészületekkel készen is lennénk.
7.) Hozzuk létre az ISO-nkat. Menjünk az openbsd könyvtárunkba, majd gépeljük be: