Aktív fórumtémák

Tárgy Válaszok Legutóbbi beküldés Fórum Szerző
  "15 éves tinédzser hekkelte meg állami intézmények informatikai rendszereit" 19  2025-09-11T01:49:51+0200 HUP cikkturkáló trey
  [Szavazás] Át kellene állni a többkulcsos adórendszerre Magyarországon? 506  2025-09-11T00:11:08+0200 HUP cikkturkáló trey
  [Megoldva] Roidmi károsultak fóruma (Roidmi csődbe ment, így nem használhatók tovább bizonyos eszközeik) 53  2025-09-10T23:03:58+0200 Közösségi kerekasztal Charybdis
  Proxmox -> Truenas ZFS sebesség kritikán aluli 16  2025-09-10T21:45:10+0200 Virtualizáció zsomLEE
  Deus Ex 1 Unreal Engine 5 mod 11  2025-09-10T21:22:02+0200 Játékok jevgenyij
  reMarkable 2 271  2025-09-10T18:46:11+0200 Notebook, laptop, mobiltelefon ... _Franko_
  Kamera elhelyezésénél kinek a jogai fontosabbak? 125  2025-09-10T16:47:57+0200 Hálózatok egyéb kikepzo
  Írj egy szerinted igaszságos SZJA számoló függvényt 191  2025-09-10T16:32:52+0200 Közösségi kerekasztal EspOS
  I5 gen3 proci win11 telepítése 14  2025-09-10T16:27:33+0200 Microsoft Windows zslaszlo
  Visa kártya adatok elmentés engedély nélkül 88  2025-09-10T16:09:54+0200 Security-all kikepzo
  PAL/SECAM/NTSC láma 33  2025-09-10T15:47:17+0200 Miniszámítógépek, SBC-k plt
  Adatmentés - rsync és pull 10  2025-09-10T15:01:35+0200 Debian GNU/Linux Luckye
  Tönkrevághatja az SSD-ket és HDD-ket a Windows 11 legújabb frissítése 43  2025-09-10T14:38:38+0200 HUP cikkturkáló DL3V1
  Egy par linkeleses tema/kerdes 2025-09-10T14:28:19+0200 C/C++ apal
  terraform.tfstate elveszett 2025-09-10T10:24:11+0200 Szkriptek: Python, Perl, Bash, ... ardi
  Unaloműző online játékok és azok eredményei #2 764  2025-09-10T08:52:37+0200 Játékok trey
  ESP-01 + Tasmota + Relé 129  2025-09-10T06:46:08+0200 Közösségi kerekasztal hnsz2002
  [PuppyLinux] BookwormPuppy32 telepítés 24  2025-09-10T06:24:30+0200 Debian GNU/Linux hrgy84
  π ≈ 4/√φ 32  2025-09-09T14:42:27+0200 Közösségi kerekasztal EspOS
  (lib)ELF for dummies? 14  2025-09-09T11:47:27+0200 Fejlesztés apal

Mozilla 1.1b

Címkék

Megjelent a Mozilla 1.1b verzió. Újdonságok:

  • Improvements to Arabic shaping which result in better layout of Arabic pages on Linux and other platforms without their own Arabic
    support.
  • A [43]bug was fixed which caused English text in text boxes to be displayed in the wrong direction on Hebrew pages.
  • The [44]JavaScript Debugger has gone through a major development cycle. It now sports a palette of nine views which can be rearranged within the main window, or docked in separate floating windows. It is also possible to create user defined views and commands directly with JavaScript. More details are available in the [45]FAQ, [46]newsgroup, or [47]IRC channel.
  • Distinct window icons on MS Windows for the different Mozilla applications
  • Mozilla on Linux now has Fullscreen mode. (press F11)
  • All Search entry points now your default search engine.
  • Improved site compatability and rendering.
  • The tab bar now has a button for creating new tabs.


Linux 2.4.19-rc3-ac2

Címkék

Néhány embernek volt SMP problémája az előző AC patchekkel. Ez még nincs javítva, némi debug munkára van még szükség.

Letölthető: patch-2.4.19-rc3-ac2.gz

Változások:[+ indicates stuff that went to Marcelo, o stuff that has not,

* indicates stuff that is merged in mainstream now, X stuff that proved bad and was dropped out]

The SMP problems some people are having are not fixed yet. The summit changes still need some debugging work

Linux 2.4.19rc3-ac2

o Fix escaped iconfig makefile line (Greg Louis)

o Fix a dcache locking error (Al Viro)

o AMD native powermanagement (Tony Lindgren,

Johnathan Hicks)

| Replaces amd768_pm as its already far better

o Remove dead tq_bdflush (Christoph Hellwig)

o Remove dead pg_nosave bits (Christoph Hellwig)

o Remove dead 8253x build script (Christoph Hellwig)

o Clean up speakup Makefile (Christoph Hellwig)

o Fix typo in drivers/net/Config.in (Hans-Joachim Baader)

o Update to new quota code with dual format (Jan Kara)

support

o Add the XFS framework for quota into it (Christoph Hellwig)

o Fix unaligned access on ewrk3 (Martin Brulisauer)

o Fix config breakage from mips merge (Christoph Hellwig)

o Recognize GPLv2 as a valid license (Keith Owens)

o Update ACPI hotplug driver (Takayoshi KOCHI)

| And fix posted shortly after

o Remove ksyms.c debugging junk (Khromy)

o Remove limits.h use in speakup (Adrian Bunk)

o NFS lock daemon fixes (Olaf Kirch)

| Sign errors, Openserver interoperability

o Further trident sound cleanup and fixes (Muli Ben-Yehuda)

o Change tcp_diag.h fix to keep DaveM happy (me)

o Add via apic to expected apic versions (me)

o Next batch of summit tweaks (James Cleverdon)

| Won't fix the existing APIC problem

o Add Vaio C1MV mode lines to radeonfb (James Mayer)

o Fix sloppy sign handling in apm and rio500 (Silvio Cesare)

o Reformat depca.c ready for some bugfixes (me)

Új/Alternatív BSD logoló eszköz

Címkék

Gustavo Rios, egy levelet küldött az openbsd misc levelezési listára, amelyben bejelentette, hogy tervezett és megvalósított egy alternatív log adat tároló/feldolgozó mechanizmust (log data storage processing mechanism). Ezt úgy hívja, hogy "Ant Fast Logging Utilities". Magában foglal egy logoló szervizt a STDIN_FILENO-n vagy egy fifo-n keresztül. Azt állítja hogy ez a mechanizmus hatékony, megbízható és portolható, ezen kívül teljesen illeszkedik az IEEE Std1003.1-1990 és ANSI C (ANSI X3.159-1989) szabványokhoz.

Bejelentés:***************************************

To: misc@openbsd.org

Subject: ASD Project

From: Gustavo Vieira Gonçalves Coelho Rios

Date: Sat, 20 Jul 2002 21:06:40 -0300

Organization: Alstom Transport Information Solutions

Hi folks!

I have just released my very open source program. It's designed to deliver reliable/efficient log data storage processing.

Some of it's features:

It's reliable, it never loses data (Provided OS/Hardware level workd Ok).

VERY efficient: Low consum of CPU power and memroy usage.

Standards: Designed to runs on every system that conforms with SUSV3 and compiled by any thing that meets ANSI C requirements.

License: BSD like.

I hope you appreciate.

Go to http://www.rootshell.be/~grios/logging.html

Újabb PHP bug

Címkék

Újabb súlyos hibát találtak a PHP-ban. A bugot az e-matters Security csapat találta. A hiba azért súlyos mert távolról kihasználható, és egyes architektúrák gépeit akár teljesen kompromittálni lehet a bug kihasználásával. A hiba a PHP 4.2.0 és 4.2.1 verzióit érinti. A hiba lehet DoS (Denial of Service) típusú, de akár teljesen lehet vele kompromittálni a webszervert. Az e-matters nem adja ki az exploitot. Ennek ellenére mindenkinek aki PHP-t használ azt ajánlják, hogy azonnal frissítse a PHP-t a webszerverén a 4.2.2 verzióra. Ebben a verzióban már javították a hibát.Lassan a disztribúciók is reagálni fognak a hibára. Aki nem tud addig várni, annak egyelőre forrásból kell megoldani a dolgot.

Az előző néhány másodperces kihagyás a PHP frissítése miatt volt, itt már az új kód fut. Ha valaki esetleg nem működő funkciót talál a szerveren az kérem jelezze a trey@debian.szintezis.hu mailcímen.

A bug részletes leírását megtalálod itt.

A 'Star Wars' effekt stúdió Intel-re vált

Címkék

Az Industrial Light and Magic csatlakozik a birodalomhoz, és Intel processzoros gépekre vált.

Az "effekt stúdió" lecseréli a régebbi SGI által szállított Unix-Risc gépeit a Dell által gyártott Intel-alapú Linuxot futtató szerverekre.

Arról már régebben beszámoltunk, hogy az ILM Linuxra vált (Linux az Industrial Light & Magic-nél). Most viszont Cliff Plumer, az ILM munkatára bejelentette, hogy a régi munkaállomások helyett 600 darab Pentium 4 munkaállomásokat telepítenek."The Intel workstations that were deployed were probably 20 percent of the price of SGI workstations we bought a few years ago," "Performancewise, they are about three times as fast." - "Az Intel munkaállomások amelyeket telepítünk, a néhány évvel ezelőtt vásárol SGI gépeink árának 20%-ba kerülnek. Teljesítményben pedig háromszor gyorsabbak." - mondta Plumer.

Azok a Unix gépek, amelyek az SGI-hez hasonló cégektől jöttek, uralták Hollywood-ot az elmúlt években. Ennek az oka a kiváló számítási teljesítmény volt, amellyel ezek a gépek rendelkeztek. Szinte az összes hi-end grafikus alkalmazás megjelent Risc alapú számítógépekre.

Jelenleg a teljesítménykülönbeség kezd eltűnni a Risc és az Intel-alapú gépek között. Így az olyan nagy animációs szoftver gyártó cégek, mint a Alias/Wavefront már megjelenteti termékeit (Maya) Intel platformra is.

Ezzel a témával foglalkozik a News,com "Star Wars" effects studio shifts to Intel című cikke.

Alan Cox: Linux 2.4.19rc3-ac1

Címkék

Alan Cox első foltja az RC3-hoz. Semmi extra, egyelőre csak merge az RC3-mal.

Letölthető: patch-2.4.19-rc3-ac1.gz

Változások:[+ indicates stuff that went to Marcelo, o stuff that has not,

* indicates stuff that is merged in mainstream now, X stuff that proved bad and was dropped out]

The SMP problems some people are having are not fixed yet. The summit changes still need some debugging work

Linux 2.4.19rc3-ac1

o Merge with 2.4.19rc3

LafiSoft Általános raktárkészlet kezelő és Számlázó update 1.0.10

Címkék

Kiadásra került a cím szerinti frissítés, amely letölthető a http://www.lafisoft.hu oldalról.Rengeteg probléma van a nyomtatási pozíciókkal, így arra kérem a Tisztelt tesztelőket és ingyenes korláton belüli aktív használókat, hogy jelezzék kinek nincs, és kinek van nyomtatott számlaformátum hibája.

A hivatalos számlaformátum nyomtatási képe:

http://www.lafisoft.hu/kep_raktlinux1/szamla.jpg

Kérjük írjátok meg, hogy melyik linux verzión, milyen nyomtató esetén jó vagy nem jó a fenti számla nyomtatása.

A válaszok eredménye lesz, hogy mi lesz a sorsa a jelenlegi nyomtatási alprogramnak.

Különösen érdekelne, hogy woody 3.0 hivatalos verzióval mi a tapasztalatotok.

Köszönettel:

Kiss Zoltán alias Lafi

LafiSoft Kiskunhalas Kassa u 24 6400

77-425262 ICQ 2510307

lafisoft@tvnetwork.hu lafisoft@emitel.hu lafisoft@mail.datanet.hu

Linus Torvalds: Linux-2.5.27

Címkék

Új fejlesztői kernel. Néhány patch amit Linus kifelejtett az előző kiadásból. Másra koncentrált, pl. az LSM beolvasztás megkezdésére, stb.



AGP kódtisztítás, IDE patchek 99-100, és 4GB FAT32 támogatás. USB frissítések.



Letölthető: patch-2.5.27.gz.



Változások logja itt.

Chris Wright: 2.4.19-rc3-lsm1

Címkék

Chris Wright levele szerint - amelyet az LKML-re küldött - megjelent a 2.4.19-rc3 LSM (Linux Security Modules) patch. Az LSM egy egyszerű, általános célú szerkezet, amely az "access control" megvalósítását teszi lehetővé.

A telje LSM patch (LSM + az összes modul) elérhető:

http://lsm.immunix.org/patches/2.4/2.4.19/patch-2.4.19-rc3-lsm1.gz

Változások logja:

http://lsm.immunix.org/patches/2.4/2.4.19/ChangeLog-2.4.19-rc3-lsm1

Kapcsolódó linkek:

Törjünk együtt Debiant!

Marcelo Tosatti: Linux 2.4.19-rc3

Címkék

Itt a 2.4.19 Release Candidate 3. Valószínű több RC kiadás nem lesz, hacsak valami kritikus probléma nem adódik.

Letölthető: patch-2.4.19-rc3.gz.

Változások:Summary of changes from v2.4.19-rc2 to v2.4.19-rc3

============================================

(02/07/17 1.622)

[PATCH] PATCH: fix aha152x

(02/07/17 1.623)

[PATCH] PATCH: update atp870u driver

(02/07/17 1.624)

[PATCH] PATCH: new PCI idents for gart

(02/07/17 1.625)

[PATCH] PATCH: AMD766/768 $PIR PCI table entries

(02/07/17 1.626)

[PATCH] PATCH: fix unload crash in AF_ROSE

(02/07/17 1.627)

[PATCH] PATCH: wrong flag type

(02/07/17 1.628)

[PATCH] PATCH: more scsi blacklist

(02/07/17 1.629)

[PATCH] fix .text.exit error in orinoco_plx.c

(02/07/17 1.630)

[PATCH] The real netfilter conntrack SMP overrun fix

(02/07/17 1.631)

[PATCH] 2.4.19-rc2 and !CONFIG_BLK_DEV_IDEPCI

(02/07/17 1.632)

[PATCH] PATCH: APM freeze on resume with SMP kernel cure

(02/07/17 1.633)

[PATCH] PATCH: fix oops printing

(02/07/17 1.634)

[PATCH] PATCH: fpu fault

(02/07/17 1.635)

[PATCH] PATCH: HP 01.09 megaraid

(02/07/17 1.636)

[PATCH] PATCH: maestro hang

(02/07/17 1.637)

[PATCH] PATCH: (low prio) stereo reporting

(02/07/17 1.638)

[PATCH] PATCH: hotplug

(02/07/17 1.639)

[PATCH] PATCH: Dunord PCI decode workaround

(02/07/17 1.640)

[PATCH] PATCH: (low priority) bose speakers

(02/07/17 1.641)

[PATCH] PATCH: fix make kernel-doc

(02/07/17 1.642)

[PATCH] PATCH: personality clashes

(02/07/17 1.643)

[PATCH] tmpfs double kunmap

(02/07/19 1.644)

[PATCH] Add missing PCI ID

(02/07/19 1.645)

Add missing ALI chipset enum in AGP

(02/07/19 1.646)

Fix wrong #ifdef in ide-pci.c: Was causing problems with

FastTrak

(02/07/19 1.647)

Changed EXTRAVERSION to -rc3

CPU, System Hőmerséklet lekérdezése linux alatt

Címkék

fabokzs összeütött egy howtot, melynek segítségével lekérdezhetővé válik a CPU, System hőmerséklet linux alatt. Lássuk:



Hogy ezen információhoz hozzájussunk szükség van egy olyan alaplapra, ami tartalmaza megfelelő szenzorokat. Ezt megtudhatjuk a BIOS-ból, ha van olyan opció, hogy CPU health status és azon belül kiírja a hőmérsékletet akkor sirály. De az, hogy mindig kilépjünk a BIOS -ba nem éppen a leghatékonyabb módszer. Linux alatt a következő két dologra van szükség: i2c, és lm-sensors.


A kernelnek legalább 2.4.13-asnak kell lennie!!!


Aki 2.5 -ös kernellel rendelkezik annak nagyon ajánlott a lenti címre ellátogatni, mert másképpen kell eljárni, mint a 2.4 -es kernel szériánál!!!Az lm-sensors hivatalos oldala

A gépem:

Alaplap: Abit kg7-raid

Processzor: AMD athlon 1333Mhz

kernel: 2.4.19-rc1-ac3

Ezt az oldalt érdemes azért átnézni mielőtt bármit is tennénk. Mert ha nincs az oldalon az alaplapunk

chipsetje (BUS drivere) akkor nem nagyon valószínű, hogy menni fog a dolog. Ha nem tudod hirtelen, hogy milyen a chipset akkor nézd meg az alaplap dobozát, vagy a kézikönyvét. Ha nem találod akkor az lspci paranccsal megtudhatod.

Csak pár a támogatott chipsetek közül:

Acer Labs M1533, M1535, and M1543C

AMD 756, 766, and 768

Apple Hydra (used on some PPC machines)

DEC 21272/21274 (Tsunami/Typhoon - on Alpha boards)

Intel I801 ICH/ICH0/ICH2/ICH3 (used in Intel 810, 810E, 815E, 820, 840 chipsets)

Intel PIIX4 (used in many Intel chipsets)

Intel I810/I815 GMCH

Intel 82443MX (440MX)

NVidia nForce

ServerWorks OSB4, CSB5

SiS 5595

SMSC Victory66, 74M1xx

3Dfx Voodoo 3 and Banshee

VIA Technologies VT82C586B, VT82C596A/B, VT82C686A/B, VT8231, VT8233, és VT8233A.

stb.

Nálam:

/home/fabokzs $ lspci | grep SMBus | cut -f3 -d':'

VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)

/home/fabokzs $

Hasonló van a listán, jó esélyem van, hogy fog menni.

(Ez az oldal segíthet, ha nem esetleg kesőbbiekben nem talalja meg a SMBus vezérlőt, vagy nem tudod milyen chipseted van.)

Fontos, hogy mind i2c -ból és lm-sensors -ból a verziószámnak meg kell egyezni, és érdemes mindkettőből a legújabb verziót feltenni (most a legújabb verzió a 2.6.4-as).

Feltehetjük csomagból:

apt-get install i2c-source lm-sensors-source

(/home/fabokzs $ apt-cache show i2c-source | grep ^Version

Version: 2.6.3-5

/home/fabokzs $
)

Letölthetjük őket:

lm_sensors-2.6.4.tar.gz

i2c-2.6.4.tar.gz

(Itt a verzió már 2.6.4 !!!)

CVS

cvs -d :pserver:anon@cvs.lm-sensors.nu:/home/cvs login

jelszó "anonymous"

cvs -d :pserver:anon@cvs.lm-sensors.nu:/home/cvs checkout lm_sensors

cvs -d :pserver:anon@cvs.lm-sensors.nu:/home/cvs checkout i2c

Én a második verziót választottam, és a /usr/src be tettem a két forrást, majd:



/usr/src # tar fxz lm_sensors-2.6.4.tar.gz

/usr/src # tar fxz i2c-2.6.4.tar.gz

/usr/src # ls

i2c-2.6.4 lm_sensors-2.6.4 NVIDIA_kernel-1.0-2880 patch-2.4.19-rc1

i2c-2.6.4.tar.gz lm_sensors-2.6.4.tar.gz patch-2.4.19-pre10 patch-2.4.19-rc1-ac3

linux NVIDIA_GLX-1.0-2880 patch-2.4.19-pre10-ac2

Mielőtt bármit is tennél győződj meg arról, hogy ezen bejegyzések szerepelnek-e a .config fájlban:

CONFIG_I2C_PROC=m

CONFIG_PROC_FS=y

Ha esetleg nem, akkor fordítsd újra a kernelt a fenti két opcióval.

Ahhoz, hogy be lehessen üzemelni a sensor-okhoz szükséges modulokat 3 mószer van:

Modulok lefordítása a "kernelen kívűl"

(én ezt a mószert használtam)



/usr/src # cd i2c-2.6.4/

/usr/src/i2c-2.6.4 # make clean all install

...

/usr/src/i2c-2.6.4 # cd ../lm_sensors-2.6.4/

/usr/src/lm_sensors-2.6.4 # make clean all install

A kernel patchelése:

(Ezt akkor érdemes választani, ha tudod pontosan milyen modulokra lesz szükség, vagy ha ha konkrét modulokat szeretnél a kernelbe belefordítani)



/usr/src # cd i2c-2.6.4/

/usr/src/i2c-2.6.4 # mkpatch/mkpatch.pl . /usr/src/linux | patch -p1 -E -d /usr/src/linux

...

/usr/src/i2c-2.6.4 # cd ../lm_sensors-2.6.4/

/usr/src/lm_sensors-2.6.4 # mkpatch/mkpatch.pl . /usr/src/linux | patch -p1 -E -d /usr/src/linux



Ha ez készen van, mehet a make menuconfig.

Ott a Character devices-ban lehet beállítani mindent.

A fenti két módszer keveréke

Részletesebben lásd az INSTALL fájlt a /usr/src/lm_sensors-2.6.4/ -ban, vagy a /usr/src/i2c-2.6.4/-ban.

Ha mindent jól csináltál, akkor a sensors és sensors-detect programokkal bővült az

arzenálod.

Ha kész vannak a modulok akkor meg kell keresni a megfelelő modulokat. Erre a legalkalmasabb:



/root # sensors-detect



Itt lehetőség szerint mindent "detektáltass fel", majd a végén kiirja, hogy mely modulokra lesz szükség ahhoz, hogy a sensors parancs megfelelően működjön.

Részlet az én sensors-detect végeredményemből:

WARNING! If you have some things built into your kernel, the below list will contain too many modules. Skip the appropriate ones! To load everything that is needed, add this to some /etc/rc* file:

#----cut here----

# I2C adapter drivers

modprobe i2c-isa

# I2C chip drivers

modprobe via686a

#----cut here----

To make the sensors modules behave correctly, add these lines to either

/etc/modules.conf or /etc/conf.modules:

#----cut here----

# I2C module options

alias char-major-89 i2c-dev

#----cut here----


Előfordulhat, hogy a sensors-detect nem talál semmit. Ekkor a chipseted nem támogatott ezen i2c illetve lm-sensors verziókkal, vagy csak nem találta meg.

Ilyenkor érdemes ezt az oldalt átolvasni.

Tehát nekem az i2c-isa, via686a modulokat kell betölteni, hogy le tudjam majd kérdezni az értékeket.

Először irjuk be a " alias char-major-89 i2c-dev " sort a /etc/modutils/aliases-ba:



/root # cat >> /etc/modutils/aliases

alias char-major-89 i2c-dev

/root #



(editorral is megcsinálhatjuk)

Majd:



/root # update-modules

/root #

Ezzel a sensors-detect által javasolt két müvelet közül a másodikkal meg is lennénk. Most gondoskodjunk arról, hogy indításnál a modulok betöltödjenek.



/root # cd /etc/init.d

/etc/init.d # cat > sensors

echo A sensors mukodesehez szukseges modulok betoltese

modprobe i2c-isa

modprobe via686a

echo betoltes befejezve

/etc/init.d # cd /etc/rcS.d

/etc/rcS.d # ln -s /etc/init.d/sensors S80Sensors

/etc/rcS.d #

A fenti műveletek elvégzése előtt se a /etc/init.d/sensors se a /etc/rcS.d/S80Sensors

NEM LÉTEZETT !!!!!!!!

És lássuk, hogy miért szenvedtünk eddig:



/home/fabokzs $ sensors

via686a-isa-6000

Adapter: ISA adapter

Algorithm: ISA algorithm

CPU core: +1.74 V (min = +1.79 V, max = +2.18 V) ALARM

+2.5V: +2.60 V (min = +2.24 V, max = +2.74 V)

I/O: +3.44 V (min = +2.95 V, max = +3.62 V)

+5V: +4.97 V (min = +4.47 V, max = +5.49 V)

+12V: +12.16 V (min = +10.79 V, max = +13.18 V)

CPU Fan: 0 RPM (min = 3000 RPM, div = 2)

P/S Fan: 4720 RPM (min = 3000 RPM, div = 2)

SYS Temp: +40.3°C (limit = +60°C, hysteresis = +50°C)

CPU Temp: +52.2°C (limit = +60°C, hysteresis = +50°C)

SBr Temp: +23.8°C (limit = +60°C, hysteresis = +50°C)

Ha szertnék, hogy a hőmérséklet értékeket loggolja a rendszer akkor telepítsd fel a sensord programot. (az adatok lekérdezéséhez NEM szükséges a sensord)



/root # apt-get install sensord

Az értékeket le lehet kerdezni grellm-mel is. Van beépített modulja, ami le tudja kerdezni.

Készítette: fabokzs [ZiB]


Utolsó módosítás dátuma: 2002-07-20

friss Debian potato extra CD-k

Címkék

Tegnap este ismét elkészítettem a szokásos extra CD-ket.
A változások:

  • Elkezdtem a CD-re is dokumentálni a változásokat a dch tool segítségével :-)
  • A KDE lekerült az extra CD-kről
  • A WOLK project fontosabb fájljait felraktam az első CD-re
  • Adrian Bunk backportjai átkerültek a 2. CD-re
  • Az ssh és ssl backportjaimat eltávolítottam, mert a debian frissítései közt teljesen újak vannak. (3.4p1-0.0potato1 verziójú ssh, és 0.9.6c-0.potato.1 openssl.)
  • A ximian Gnome mirrorozása a CD készítésekor automatikusan történik.

Hogyan keltsünk életre nVIDIA kártyát a 2.5.x fejlesztői kernel alatt?

Címkék

Mielőtt nekiesnél nVIDIA accelerated drivert faragni a 2.5-ös kernel alá, gondold át az alábbiakat. Az nVIDIA accelerated driver nem része a Linux kernelfának, 3party drivernek kell tekinteni, és ráadásul mérgezi a kernelt (TAINTED). A 2.5-ös kernel fejlesztői állapotban van, akár a géped teljes adattartalma is elveszhet a használata során. Senki nem garantálja neked, hogy az itt leírtak működnek majd nálad, nekem működik, de ez nem jelent semmit. Ha a valami nem működik, vagy a rendszered elpusztult, ne sírj se az nVIDIA-nak, se a kernelfejlesztőknek, se nekem. Az nVIDIA hivatalosan nem támogatja a fejlesztői Linux kernelt, a kernelfejlesztőket meg felesleges ezzel idegesíteni.

Ha ezek után mégis úgy döntesz, hogy te a gyors élet, gyors halál utat választod, mert a penge élén szeretsz táncolni, akkor olvasd tovább. Ha gyenge idegzetű vagy akkor jobb ha most abbahagyod ;)Lássuk miért is használjunk 2.5-ös kernelt a stabil, jól bevált 2.4 helyett? NE HASZNÁLJUNK. Ha mégis akkor szeretnél, nézzük milyen előnyünk származhat a 2.5 kernel használatából, főleg a gamer szemével nézve. Mert ugye ezért akarjuk beizzítani a gyorsított nVIDIA kártyát a fejlesztői kernel alatt, hogy kicsikarjunk a gépünkből még pár FPS-t.

Ha van nVIDIA kártyád, és Linux alatt akarsz értelmes játékkal játszani, akkor szükséged van az nVIDIA által gyártott bináris gyorsított, GL-lel rendelkező driverekre. Ez nélkül reménytelen Quake3, SOF, Unreal Tournament, Deux EX, Warcraft 3, stb.-t játszani. Mivel az nVIDIA nem támogatja a 2.5 fejlesztői kernelt, a driverek amit szállítanak nem fordulnak le a fejlesztői kernel alatt.

Akkor hogy fogunk játszni merül fel benned a kérdés?

A kérdés jogos. Úgy hogy egy patchelt nVIDIA drivert kell hozzá leforgatni.

Jó, de honnan szerezzek ilyet?

Tőlem. Sikerült a legutolsó fejlesztői (jelenleg a 2.5.26) alá befaragni az nVIDIA legutolsó driverét, a 2960-ast. Remélem az nVIDIA nem harapja le a fejem érte ;)

Miért használjak 2.5 kernelt?

Több okot is mondhatok. Egy, hogy kihasználjuk a legújabb fejlesztés eredményeit. Megtaláljuk benne az ALSA-t, a preemptív kernel funkciókat, az O(1) schedulert, és számos olyan dolgot amely jobban kihasználja a új hardverek adta lehetőségeket. A preemtívitásnak köszönhetően sokkal kisebb lesz a rendszer lappangási ideje, nő a rendeszer reakcióképessége, érezhetően javul a válaszidő. Az O(1) ütemező szintén kedvezően befolyásolja a rendszer működését. Az ALSA-t bele lehet patchelni a 2.4-es kernelbe, de minek ha benne van a 2.5-ben? Számos más területen változtatták meg a 2.5-ös kernelt, pl. BIO - block IO réteget, a VM alrendszert, az IDE kódot (erről jobb nem beszélni ;) amilyen állapotban most van. Összeségében látható a javulás, én legalábbis látom. Ha a rendszered backupoltad, és semmi olyan nincs rajta ami ha elveszik, akkor ne lehetne pótolni akkor vágj bele. Ha kétségeid vannak, akkor inkább ne.

Hogyan csináljam?

Hát feltételezem, hogy tudsz kernelt fordítani. Ez az alap, ez kell hozzá. Töltsd le a legfrissebb fejlesztői kernelt. Ezt megtalálod itt. Szükséged lesz még a patchet nVIDIA driverekre.

http://www.hup.hu/old/stuff/NVIDIA_GLX-1.0-2960.tar.gz

http://www.hup.hu/old/stuff/NVIDIA_kernel-1.0-2960_2.5.xx.tar.gz

ezeket itt találod.

Amit tenned kell. Lefordítod a fejlesztői kernelt. Bebootolsz vele. Letöltöd ezeket a patchelt nVIDIA drivereket, és a hagyományos módon telepíted őket. Ha nem tudod, hogy kell telepíteni, akkor olvasd el README-t.

Élvezd a fejlesztői kernel tulajdonságait. ;)

Debian Woody: 2 év után végre....

Címkék

A Debian legújabb stabil verziója ezennel A Debian GNU/Linux 3.0 aka. 'Woody'. Sokat kellett rá várni. Egész pontosan 1 év, 11 hónap és 4 nap telt el a 2.2 (aka. potato) kiadása óta. A főbb tudnivalók:

AJ bejelentése

Hivatalos bejelentés

Release Notes

Telepítési útmutató

Bootfloppyk

Netistall ISO-k

CD image készítő stuff

Az új testing terjesztés neve ezennel Sarge.



Azoknak akik esetleg a szerverükre ki akarják tenni:



woody logo1 woody logo2
Egy kis magyarázat a verziókhoz:



A jelenlegi stabil terjesztés neve Debian GNU/Linux 3.0 kódnevén Woody. A jelenlegi tesztverzió a Sarge. Ez azt jelenti, hogy tegnaptól a Woody nem fog nagyon változni, csak a bizotnsági és bugfixek kerülnek bele. A Woody tegnapi állapota átkrült a Sargeba, az az új teszt verzió. Mostantól az (úgy látszik) örök SID-ből (SID a gonosz fiú a Toy Story-ban, de sokak szerint a SID jelentése : Still in Development) kerülnek a csomagok a Sargeba. Ha a Sarge közel áll a kiadáshoz, abból lesz magy a frozen, azaz a fagyasztott disztribúció. És majdan egykor a frozenből lesz a stable. Ez az örök körforgás.



FIGYELEM:



Általános hiba szokott lenni, hogy valakinek a sources.list-jében nem névvel vannak a hivatkozások (pl. potato, woody, stb.) hanem a disztribúció állapotára (stable, unstable). Erre kéretik figyelni, mert okozhatnak meglepetéseket. Én javaslom, hogy inkább névvel hivatkozzunk rá, mert akkor az esetleges releaseknél nem érhet minket meglepetés.



Tehát a jelenlegi STABIL Woody források:



deb http://ftp.hu.debian.org/debian woody main contrib non-free

deb http://ftp.hu.debian.org/debian-non-US woody/non-US main contrib non-free

deb-src http://ftp.hu.debian.org/debian woody main contrib non-free

deb-src http://ftp.hu.debian.org/debian-non-US woody/non-US main contrib non-free

deb http://security.debian.org woody/updates main contrib non-free




A testing Sarge forrásai:



deb http://ftp.hu.debian.org/debian sarge main contrib non-free

deb http://ftp.hu.debian.org/debian-non-US sarge/non-US main contrib non-free

deb-src http://ftp.hu.debian.org/debian sarge main contrib non-free

deb-src http://ftp.hu.debian.org/debian-non-US sarge/non-US main contrib non-free

deb http://security.debian.org woody/updates main contrib non-free



Ogg Vorbis 1.0

Címkék

We made it! Ogg Vorbis has hit 1.0! - azaz "Megcsináltuk! Az Ogg Vorbis elérte az 1.0-t!" olvashatjuk az Ogg Vorbis honlapján.

Az Ogg Vorbis egy nyílt, zenei formátum az mp3 helyett, teljesen free, semmiféle jogvédett algoritmust nem használ. Lejátszó és encoder linux [freeamp, xmms,...] windoze [winamp, ..] alá.

Az Ogg Vorbis 1.0 letölthető :

http://www.vorbis.com/download.psp.

Perl 5.8.0 kiadás

Címkék

Megjelent a Perl 5.8.0-ás verziója. Az release announcement már elérhető. Az kiadásban számos új dolog található, kiemelném az Unicode támogatás javítását, az új threads implementációt, 64-bit támogatást, egy rakás új modult, stb. Olvasd el a bejelentést.

A stable kiadás így jelenleg a perl 5.6.0, a latest pedig az 5.8.0. Jelenleg nincs fejlesztői kiadás.

A latest verzió letölthető: http://www.cpan.org/src/latest.tar.gz

Új FreeBSD processz scheduler kiadás

Címkék

Luigi Rizzo implementált egy új, súly-alapú processz ütemezőt (scheduler) a FreeBSD-stable -hez. A scheduler portolása a FreeBSD-current -hez jelenleg is folyamatban van.A "Proportional Share scheduler" elérhető az alábbi linken:

http://info.iet.unipi.it/~luigi/ps_sched.20020719a.diff

A patch a legújabb -STABLE rendszerekehez készült, valószínűleg működig a 4.4-nél újabb rendszereken. Összesen 3 file került módosításra: kern_synch.c, kern_switch.c és a proc.h, plusz egy one-line változás a kern_exit.c-ben.)

Rizzo letesztelte a patchet egy diskless gépen, és a teszt szerint túlélt egy X sessiont, Netscapet, xterm-et, stb. Ennek ellenére NEM ajánlott roduktív rendszereken. Egyelőre tesztelési fázisban van.

Bejelentés:

**************************************************

Date: Thu, 18 Jul 2002 16:31:57 -0700

From: Luigi Rizzo

To: arch@FreeBSD.ORG

Subject: NEW SCHEDULER available (was Re: proposed changes to kern_switch.c and kern_synch.c)

Hi,

as promised, a first version of the Proportional Share scheduler

that we developed is available at

http://info.iet.unipi.it/~luigi/ps_sched.20020719a.diff

These are for a recent -STABLE (i think any version from 4.4 should

work; the only 3 files modified are kern_synch.c, kern_switch.c and

proc.h, plus a one-line change to kern_exit.c).

I have tested it a little bit on a diskless system, and it seems

to survive running a full X session with the usual set of xterm,

netscape etc. while i do a "renice" of the processes and even switch

back and forth between schedulers. But do not trust this yet for a

production system!

The sysctl variable kern.scheduler controls the scheduler in use.

kern.scheduler=1 (default) selects Proportional Share

kern.scheduler=0 selects the Feedback Priority ("classic BSD")

You can switch between the two schedulers by changing the value of

the sysctl variable.

To change the "weight" associated to a process, use the "nice" and

"renice" commands. As usual, positive values (+1..+20) mean the

process will get a smaller share of the CPU, negative values (-1..-20)

will get a larger share. The actual weights (which control the

relative fraction of CPU cycles given to each process) are assigned

through a lookup table which maps the value to the range

1 ... 100 ... 1000 (min, normal, max weight).

The "old" scheduler (Feedback Priority) should be as robust and

stable as always, whereas there are still a few things to cleanup

in the Proportional Share scheduler, namely:

* I have not looked in detail at the SMP case, so do not run

it on an SMP kernel;

* given that there are no priorities, processes woken up by a

tsleep() are not guaranteed to run before all processes

with p_priority >= PUSER; however, they are given a shorter

deadline so they are likely to run first.

* RTPRI and IDLEPRI processes do not have yet any special treatment

(they all end up together with normal processes; this is trivial

to fix, i just haven't had time to look at that).

Have fun, and please if you use it let me know of any bugs and

possibly suggestions to adapt it to -current.

cheers

luigi

On Tue, Jul 16, 2002 at 11:52:16PM -0700, Luigi Rizzo wrote:

> Hi,

> we have implemented a weight-based process scheduler

> for FreeBSD-stable, and are trying to port it to -current (in the

> description below replace "process" with "thread/kse" as appropriate

> for the -current case).

>

> In order to make this work, it is convenient to have all

> scheduler-specific functions and data structures in a

> single file (kern_switch*.c), and generic support in

> another one (kern_synch.c). I believe this was also the original

> BSD design in partitioning the code between the two files.

> However, in our current code, there are some functions which

> are scheduler-specific (see below) which are misplaced.

>

> So I would like to make the following, purely cosmetic, change

> identified as step #1 below, both for consistency with what i

> believe to be the original design, and to simplify further work

> in this area. These would go to both -current and -stable; I

> repeat, they are only cosmetic changes.

>

> Comments ? I already spoke to julian who has no objections.

>

> For those interested, a patch for -current is attached, and the one

> for -stable is very similar (for the records, in -stable we have a

> fully functional weight-based process scheduler, where you still

> control the weights using "nice", and you can switch between the

> old and the new scheduler at any time using a sysctl variable).

>

> --- Re. the multi-scheduler architecture ---

>

> The general idea is to make the process/thread/kse scheduler

> a replaceable piece of the kernel, requiring no modifications

> to the "struct proc", and with the ability of switching from

> one scheduler to another one at runtime (this both for testing

> purposes and for whatever need may arise).

>

>

> The way to achieve this would be the following:

>

> 1. identify all scheduler-specific functions, put all of them

> in one file (e.g. kern_switch.c for the default scheduler),

> and define function pointers for all of them;

>

> 2. use one field in "struct proc" as a link to whatever

> scheduler-specific data structures are necessary.

> In -stable, we have the p_pad3 field that can be used

> for this purpose, much like the if_index field in struct ifnet.

>

> 3. implement a function which, under control of a sysctl call,

> activate a new scheduler (by initialising all the function

> pointers to appropriate values) and moves all processes from

> the old to the new one.

>

> Step #1 is basically a cosmetic change, requiring mostly a move of

> some functions from kern_synch.c to kern_switch.c. These are

>

> roundrobin();

>

> curpriority_cmp();

>

> resetpriority();

>

> parts of schedcpu() and schedclock();

>

> cheers

> luigi

> ----------------------------------

>

> Index: kern_switch.c

> ==================================================

=================

> RCS file: /home/ncvs/src/sys/kern/kern_switch.c,v

> retrieving revision 1.33

> diff -u -r1.33 kern_switch.c

> --- kern_switch.c14 Jul 2002 03:43:33 -00001.33

> +++ kern_switch.c16 Jul 2002 22:15:06 -0000

> @@ -97,6 +97,7 @@

> #include

> #include

> #include

> +#include

> #include

>

> CTASSERT((RQB_BPW * RQB_LEN) == RQ_NQS);

> @@ -107,6 +108,9 @@

> static struct runq runq;

> SYSINIT(runq, SI_SUB_RUN_QUEUE, SI_ORDER_FIRST, runq_init, &runq)

>

> +static struct callout roundrobin_callout;

> +

> +static voidroundrobin(void *arg);

> static void runq_readjust(struct runq *rq, struct kse *ke);

> / **************************************************

**********************

> * Functions that manipulate runnability from a thread perspective.*

> @@ -442,9 +446,13 @@

> {

> int i;

>

> +callout_init(&roundrobin_callout, 0);

> +

> bzero(rq, sizeof *rq);

> for (i = 0; i TAILQ_INIT(&rq->rq_queues[i]);

> +

> +roundrobin(NULL);

> }

>

> /*

> @@ -719,3 +727,207 @@

> }

> #endif

>

> +/*

> + * -- formerly in kern_synch.c

> + */

> +

> +int curpriority_cmp(struct thread *td);

> +

> +int

> +curpriority_cmp(struct thread *td)

> +{

> +return (td->td_priority - curthread->td_priority);

> +}

> +

> +/*

> + * Force switch among equal priority processes every 100ms.

> + * We don't actually need to force a context switch of the current process.

> + * The act of firing the event triggers a context switch to softclock() and

> + * then switching back out again which is equivalent to a preemption, thus

> + * no further work is needed on the local CPU.

> + */

> +/* ARGSUSED */

> +static void

> +roundrobin(arg)

> +void *arg;

> +{

> +

> +#ifdef SMP

> +mtx_lock_spin(&sched_lock);

> +forward_roundrobin();

> +mtx_unlock_spin(&sched_lock);

> +#endif

> +

> +callout_reset(&roundrobin_callout, sched_quantum, roundrobin, NULL);

> +}

> +

> +/* calculations for digital decay to forget 90% of usage in 5*loadav sec */

> +#define loadfactor(loadav) (2 * (loadav))

> +#define decay_cpu(loadfac, cpu) (((loadfac) * (cpu)) / ((loadfac) + FSCALE))

> +extern fixpt_t ccpu;

> +#define CCPU_SHIFT 11/* XXX dup from kern_synch.c! */

> +

> +/*

> + * Recompute process priorities, every hz ticks.

> + * MP-safe, called without the Giant mutex.

> + */

> +void schedcpu1(struct ksegrp *kg);

> +/* ARGSUSED */

> +void

> +schedcpu1(struct ksegrp *kg)

> +{

> +register fixpt_t loadfac = loadfactor(averunnable.ldavg[0]);

> +struct thread *td;

> +struct kse *ke;

> +int realstathz;

> +int awake;

> +

> + realstathz = stathz ? stathz : hz;

> +

> +awake = 0;

> +FOREACH_KSE_IN_GROUP(kg, ke) {

> +/*

> + * Increment time in/out of memory and sleep

> + * time (if sleeping). We ignore overflow;

> + * with 16-bit int's (remember them?)

> + * overflow takes 45 days.

> + */

> +/* XXXKSE **WRONG***/

> +/*

> + * the kse slptimes are not touched in wakeup

> + * because the thread may not HAVE a KSE

> + */

> +if ((ke->ke_state == KES_ONRUNQ) ||

> + ((ke->ke_state == KES_THREAD) &&

> + (ke->ke_thread->td_state == TDS_RUNNING))) {

> +ke->ke_slptime++;

> +} else {

> +ke->ke_slptime = 0;

> +awake = 1;

> +}

> +

> +/*

> + * pctcpu is only for ps?

> + * Do it per kse.. and add them up at the end?

> + * XXXKSE

> + */

> +ke->ke_pctcpu = (ke->ke_pctcpu * ccpu) >> FSHIFT;

> +/*

> + * If the kse has been idle the entire second,

> + * stop recalculating its priority until

> + * it wakes up.

> + */

> +if (ke->ke_slptime > 1) {

> +continue;

> +}

> +

> +#if(FSHIFT >= CCPU_SHIFT)

> +ke->ke_pctcpu += (realstathz == 100) ?

> + ((fixpt_t) ke->ke_cpticks) + (FSHIFT - CCPU_SHIFT) :

> + 100 * (((fixpt_t) ke->ke_cpticks) + (FSHIFT - CCPU_SHIFT)) / realstathz;

> +#else

> +ke->ke_pctcpu += ((FSCALE - ccpu) *

> + (ke->ke_cpticks * FSCALE / realstathz)) >>

> + FSHIFT;

> +#endif

> +ke->ke_cpticks = 0;

> +} /* end of kse loop */

> +if (awake == 0) {

> +kg->kg_slptime++;

> +} else {

> +kg->kg_slptime = 0;

> +}

> +kg->kg_estcpu = decay_cpu(loadfac, kg->kg_estcpu);

> +resetpriority(kg);

> +FOREACH_THREAD_IN_GROUP(kg, td) {

> +int changedqueue;

> +if (td->td_priority >= PUSER) {

> +/*

> + * Only change the priority

> + * of threads that are still at their

> + * user priority.

> + * XXXKSE This is problematic

> + * as we may need to re-order

> + * the threads on the KSEG list.

> + */

> +changedqueue =

> + ((td->td_priority / RQ_PPQ) !=

> + (kg->kg_user_pri / RQ_PPQ));

> +

> +td->td_priority = kg->kg_user_pri;

> +if (changedqueue &&

> + td->td_state == TDS_RUNQ) {

> +/* this could be optimised */

> +remrunqueue(td);

> +td->td_priority =

> + kg->kg_user_pri;

> +setrunqueue(td);

> +} else {

> +td->td_priority = kg->kg_user_pri;

> +}

> +}

> +}

> +}

> +

> +/*

> + * Compute the priority of a process when running in user mode.

> + * Arrange to reschedule if the resulting priority is better

> + * than that of the current process.

> + */

> +void

> +resetpriority(kg)

> +register struct ksegrp *kg;

> +{

> +register unsigned int newpriority;

> +struct thread *td;

> +

> +mtx_lock_spin(&sched_lock);

> +if (kg->kg_pri_class == PRI_TIMESHARE) {

> +newpriority = PUSER + kg->kg_estcpu / INVERSE_ESTCPU_WEIGHT +

> + NICE_WEIGHT * (kg->kg_nice - PRIO_MIN);

> +newpriority = min(max(newpriority, PRI_MIN_TIMESHARE),

> + PRI_MAX_TIMESHARE);

> +kg->kg_user_pri = newpriority;

> +}

> +FOREACH_THREAD_IN_GROUP(kg, td) {

> +maybe_resched(td);/* XXXKSE silly */

> +}

> +mtx_unlock_spin(&sched_lock);

> +}

> +

> +#if 0

> +/*

> + * We adjust the priority of the current process. The priority of

> + * a process gets worse as it accumulates CPU time. The cpu usage

> + * estimator (p_estcpu) is increased here. resetpriority() will

> + * compute a different priority each time p_estcpu increases by

> + * INVERSE_ESTCPU_WEIGHT

> + * (until MAXPRI is reached). The cpu usage estimator ramps up

> + * quite quickly when the process is running (linearly), and decays

> + * away exponentially, at a rate which is proportionally slower when

> + * the system is busy. The basic principle is that the system will

> + * 90% forget that the process used a lot of CPU time in 5 * loadav

> + * seconds. This causes the system to favor processes which haven't

> + * run much recently, and to round-robin among other processes.

> + */

> +void

> +schedclock(td)

> +struct thread *td;

> +{

> +struct kse *ke;

> +struct ksegrp *kg;

> +

> +KASSERT((td != NULL), ("schedlock: null thread pointer"));

> +ke = td->td_kse;

> +kg = td->td_ksegrp;

> +ke->ke_cpticks++;

> +kg->kg_estcpu = ESTCPULIM(kg->kg_estcpu + 1);

> +if ((kg->kg_estcpu % INVERSE_ESTCPU_WEIGHT) == 0) {

> +resetpriority(kg);

> +if (td->td_priority >= PUSER)

> +td->td_priority = kg->kg_user_pri;

> +}

> +}

> +#endif

> Index: kern_synch.c

> ==================================================

=================

> RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v

> retrieving revision 1.185

> diff -u -r1.185 kern_synch.c

> --- kern_synch.c14 Jul 2002 03:43:33 -00001.185

> +++ kern_synch.c16 Jul 2002 22:16:46 -0000

> @@ -67,6 +67,8 @@

>

> #include

>

> +voidschedcpu1(struct ksegrp *kg); /* XXX in kern_switch.c */

> +

> static void sched_setup(void *dummy);

> SYSINIT(sched_setup, SI_SUB_KICK_SCHEDULER, SI_ORDER_FIRST, sched_setup, NULL)

>

> @@ -76,7 +78,6 @@

>

> static struct callout loadav_callout;

> static struct callout schedcpu_callout;

> -static struct callout roundrobin_callout;

>

> struct loadavg averunnable =

> { {0, 0, 0}, FSCALE };/* load average, of runnable procs */

> @@ -92,7 +93,6 @@

>

> static voidendtsleep(void *);

> static voidloadav(void *arg);

> -static voidroundrobin(void *arg);

> static voidschedcpu(void *arg);

>

> static int

> @@ -135,28 +135,6 @@

> }

>

> /*

> - * Force switch among equal priority processes every 100ms.

> - * We don't actually need to force a context switch of the current process.

> - * The act of firing the event triggers a context switch to softclock() and

> - * then switching back out again which is equivalent to a preemption, thus

> - * no further work is needed on the local CPU.

> - */

> -/* ARGSUSED */

> -static void

> -roundrobin(arg)

> -void *arg;

> -{

> -

> -#ifdef SMP

> -mtx_lock_spin(&sched_lock);

> -forward_roundrobin();

> -mtx_unlock_spin(&sched_lock);

> -#endif

> -

> -callout_reset(&roundrobin_callout, sched_quantum, roundrobin, NULL);

> -}

> -

> -/*

> * Constants for digital decay and forget:

> *90% of (p_estcpu) usage in 5 * loadav time

> *95% of (p_pctcpu) usage in 60 seconds (load insensitive)

> @@ -225,7 +203,7 @@

> #definedecay_cpu(loadfac, cpu)(((loadfac) * (cpu)) / ((loadfac) + FSCALE))

>

> /* decay 95% of `p_pctcpu' in 60 seconds; see CCPU_SHIFT before changing */

> -static fixpt_tccpu = 0.95122942450071400909 * FSCALE;/* exp(-1/20) */

> +fixpt_tccpu = 0.95122942450071400909 * FSCALE;/* exp(-1/20) */

> SYSCTL_INT(_kern, OID_AUTO, ccpu, CTLFLAG_RD, &ccpu, 0, "");

>

> /* kernel uses `FSCALE', userland (SHOULD) use kern.fscale */

> @@ -255,105 +233,15 @@

> schedcpu(arg)

> void *arg;

> {

> -register fixpt_t loadfac = loadfactor(averunnable.ldavg[0]);

> -struct thread *td;

> struct proc *p;

> -struct kse *ke;

> struct ksegrp *kg;

> -int realstathz;

> -int awake;

>

> -realstathz = stathz ? stathz : hz;

> sx_slock(&allproc_lock);

> FOREACH_PROC_IN_SYSTEM(p) {

> mtx_lock_spin(&sched_lock);

> p->p_swtime++;

> FOREACH_KSEGRP_IN_PROC(p, kg) {

> -awake = 0;

> -FOREACH_KSE_IN_GROUP(kg, ke) {

> -/*

> - * Increment time in/out of memory and sleep

> - * time (if sleeping). We ignore overflow;

> - * with 16-bit int's (remember them?)

> - * overflow takes 45 days.

> - */

> -/* XXXKSE **WRONG***/

> -/*

> - * the kse slptimes are not touched in wakeup

> - * because the thread may not HAVE a KSE

> - */

> -if ((ke->ke_state == KES_ONRUNQ) ||

> - ((ke->ke_state == KES_THREAD) &&

> - (ke->ke_thread->td_state == TDS_RUNNING))) {

> -ke->ke_slptime++;

> -} else {

> -ke->ke_slptime = 0;

> -awake = 1;

> -}

> -

> -/*

> - * pctcpu is only for ps?

> - * Do it per kse.. and add them up at the end?

> - * XXXKSE

> - */

> -ke->ke_pctcpu = (ke->ke_pctcpu * ccpu) >> FSHIFT;

> -/*

> - * If the kse has been idle the entire second,

> - * stop recalculating its priority until

> - * it wakes up.

> - */

> -if (ke->ke_slptime > 1) {

> -continue;

> -}

> -

> -#if(FSHIFT >= CCPU_SHIFT)

> -ke->ke_pctcpu += (realstathz == 100) ?

> - ((fixpt_t) ke->ke_cpticks) - (FSHIFT - CCPU_SHIFT) :

> - 100 * (((fixpt_t) ke->ke_cpticks) - (FSHIFT - CCPU_SHIFT)) / realstathz;

> -#else

> -ke->ke_pctcpu += ((FSCALE - ccpu) *

> - (ke->ke_cpticks * FSCALE / realstathz)) >>

> - FSHIFT;

> -#endif

> -ke->ke_cpticks = 0;

> -} /* end of kse loop */

> -if (awake == 0) {

> -kg->kg_slptime++;

> -} else {

> -kg->kg_slptime = 0;

> -}

> -kg->kg_estcpu = decay_cpu(loadfac, kg->kg_estcpu);

> - resetpriority(kg);

> -FOREACH_THREAD_IN_GROUP(kg, td) {

> -int changedqueue;

> -if (td->td_priority >= PUSER) {

> -/*

> - * Only change the priority

> - * of threads that are still at their

> - * user priority.

> - * XXXKSE This is problematic

> - * as we may need to re-order

> - * the threads on the KSEG list.

> - */

> -changedqueue =

> - ((td->td_priority / RQ_PPQ) !=

> - (kg->kg_user_pri / RQ_PPQ));

> -

> -td->td_priority = kg->kg_user_pri;

> -if (changedqueue &&

> - td->td_state == TDS_RUNQ) {

> -/* this could be optimised */

> -remrunqueue(td);

> -td->td_priority =

> - kg->kg_user_pri;

> -setrunqueue(td);

> -} else {

> -td->td_priority = kg->kg_user_pri;

> -}

> -}

> -}

> +schedcpu1(kg);

> } /* end of ksegrp loop */

> mtx_unlock_spin(&sched_lock);

> } /* end of process loop */

> @@ -944,32 +832,6 @@

> }

>

> /*

> - * Compute the priority of a process when running in user mode.

> - * Arrange to reschedule if the resulting priority is better

> - * than that of the current process.

> - */

> -void

> -resetpriority(kg)

> -register struct ksegrp *kg;

> -{

> -register unsigned int newpriority;

> -struct thread *td;

> -

> -mtx_lock_spin(&sched_lock);

> -if (kg->kg_pri_class == PRI_TIMESHARE) {

> -newpriority = PUSER + kg->kg_estcpu / INVERSE_ESTCPU_WEIGHT +

> - NICE_WEIGHT * (kg->kg_nice - PRIO_MIN);

> -newpriority = min(max(newpriority, PRI_MIN_TIMESHARE),

> - PRI_MAX_TIMESHARE);

> -kg->kg_user_pri = newpriority;

> -}

> -FOREACH_THREAD_IN_GROUP(kg, td) {

> -maybe_resched(td);/* XXXKSE silly */

> -}

> -mtx_unlock_spin(&sched_lock);

> -}

> -

> -/*

> * Compute a tenex style load average of a quantity on

> * 1, 5 and 15 minute intervals.

> * XXXKSE Needs complete rewrite when correct info is available.

> @@ -1022,11 +884,9 @@

> {

>

> callout_init(&schedcpu_callout, 1);

> -callout_init(&roundrobin_callout, 0);

> callout_init(&loadav_callout, 0);

>

> /* Kick off timeout driven events by calling first time. */

> -roundrobin(NULL);

> schedcpu(NULL);

> loadav(NULL);

> }

>

> ----- End forwarded message -----

>

> To Unsubscribe: send mail to majordomo@FreeBSD.org

> with "unsubscribe freebsd-arch" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org

with "unsubscribe freebsd-arch" in the body of the message

systrace az alaprendszerben

Címkék

Az OpenBSD legújabb kiadásában (3.2) úgy tűnik már alaprendszer-szinten is használatba kerül a systrace nevű szolgáltatás a megnövelt biztonság érdekében. A systrace-ről már írtunk régebben, ahol megemlítettük annak legfőbb tulajdonságait (rendszerhívás figyelés és korlátozás). A systrace körüli első fellángolások lecsillapodása után logikusnak tűnt a lépés, hogy az alaprendszerben lévő, jól körülhatárolható szolgáltatásokat nyújtó (pld. named) programokat ezzel az eszközzel tegyék még biztonságosabbá az esetleges programhibák kivédése érdekében.
Az ehhez szükséges policy fájlok már meg is jelentek az /etc/systrace könyvtárban, így jogos a feltételezés, hogy a jelenleg elérhető két darabot (lpd és named) továbbiak fogják követni (például a chrootban futtatott apache-hoz).
A systrace használatával a démonok által elérhető rendszerhívások meglehetősen jól szabályozhatók, tehát egy esetleges betörés is kisebb kockázatot jelent majd az OpenBSD-n systrace policyvel rendelkező programok esetében.

Alan Cox: Linux 2.4.19-rc2-ac2

Címkék

Hát a 2.4.19-rc2-ac1 nem sikerült valami jól. A verziója rosszul volt megírva (2.4.19-rc1-ac7-nek hazudta magát), és Alan javított egy IDE bugot is.

Letölthető: patch-2.4.19-rc2-ac2.gz

Változások:From: Alan Cox

To: linux-kernel@vger.kernel.org

Subject: Linux 2.4.19-rc2-ac2

Date: 18 Jul 2002 21:35:53 +0200

[+ indicates stuff that went to Marcelo, o stuff that has not,

* indicates stuff that is merged in mainstream now, X stuff that proved bad and was dropped out]

Linux 2.4.29rc2-ac2

o Fix ide probe crash stupid bug in ac1 (me)

| I mismerged Kurt's change

Linux doksik magyarul

Címkék

Bár már cca egy éve üzemel talán sokan ismerik is, ennek ellenére érdemesnek tartom bemutatni a következõ oldalt. A linuxdoc.freeweb.hu nagyon jól összefoglalja a linuxos dokumentációkat minden kezdõ (haladó?) linuxos számára.


Az oldalt minden olyan felhasználónak ajánlom akinek nyelvi nehézségek miatt eddig gondot okozott a Linux használatba vétele és a rendszer feletti uralkodás. :)

http://linuxdoc.freeweb.hu/

Alan Cox: Linux 2.4.19-rc2-ac1

Címkék

Alig jött ki a 2.4.19 Release Candidate 2 kernel, Alan Cox már meg is patchelte.

A patch letölthető: patch-2.4.19-rc2-ac1.gz

Változások:From: Alan Cox (alan@redhat.com)

Date: Thu Jul 18 2002 - 10:45:42 EST

[+ indicates stuff that went to Marcelo, o stuff that has not,

* indicates stuff that is merged in mainstream now, X stuff that proved bad and was dropped out]

Linux 2.4.19rc2-ac1

o Merge with 2.4.19-rc2

o Minor HP merge fixup

o Orinoco build fix (Adrian Bunk)

o Vaio C1VE/N frame buffer console mode (Marcel Wijlaars)

o Fix an inverted test in sym53c8xx_2 (Grant Grundler)

o Fix aic7xxx build without PCI enabled (me)

o Clear allocated gendisk in IDE (Kurt Garloff)