Aktív fórumtémák

Tárgy Válaszok Legutóbbi beküldés Fórum Szerző
  Ajánljatok valamit webmin helyett 2019-12-16T01:08:25+0100 UNIX kezdő gentoojedi
  Használt Office cégeknek, intézményeknek megbízható forrásból 40  2019-12-16T00:59:39+0100 Iroda gentoojedi
  Mac mini + Air vagy MacBook Pro 13 2019-12-16T00:19:29+0100 Miniszámítógépek, SBC-k csardij
  Milyen lézernyomtatót vegyek 2019 karácsonyán? 13  2019-12-15T23:48:28+0100 Alaplapok icserny
  RE: Revolut - a valóban ingyenes bankolás 534  2019-12-15T23:35:39+0100 Közösségi kerekasztal gelei
  Russian police raid NGINX Moscow office 40  2019-12-15T22:26:39+0100 HUP cikkturkáló toMpEr
  DeepSpam v0.3 release - uj tokenizalo, uj dataset/model 52  2019-12-15T21:38:00+0100 Spam arpi_esp
  Villámakció: játékok ingyen 756  2019-12-15T21:25:53+0100 Játékok endi123
  [ELVIHETŐ] óriás SFF diszkdoboz!!!négy, kábelek és mindenféle... 2019-12-15T21:21:26+0100 Adás - vétel - csere andrej_
  DKIM kulccsal rendelkező, random feladó / domaintől érkező spammer blokkolása Postfixben 98  2019-12-15T20:58:57+0100 Linux-haladó gedg87
  Hanyag Fosta (Magyar Posta panaszbejelentő) 27  2019-12-15T20:41:45+0100 Fun Charybdis
  Jogerősen elítélték a Telekomot meghekkelő főiskolást 262  2019-12-15T20:13:37+0100 HUP cikkturkáló Hiena
  Milyen androidos tv-boxot? 130  2019-12-15T20:08:49+0100 Android zitev
  [ELADÓ] 2 db Pioneer rádió/erősítő + 4 db Videoton DC 2012 A 2019-12-15T19:11:43+0100 Adás - vétel - csere goodbyte
  Fura hiba Visual C-vel, gcc-vel minden ok. 16  2019-12-15T18:43:39+0100 C/C++ csfeco
  Turris MOX Classic router eladó 2019-12-15T17:16:22+0100 Adás - vétel - csere zseeeci
  pfSense CARP és pppoe tűzfal probléma 2019-12-15T16:46:56+0100 FreeBSD-all zilahu
  Virtuális szeművegek de melyiket? 2019-12-15T16:29:06+0100 Offtopic PP
  Brexit 1,097  2019-12-15T14:36:01+0100 Flame Mindthegap
  Szervert keresek 22  2019-12-15T13:49:36+0100 Adás - vétel - csere torokbalazs

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)

OpenOffice.org 1.0.1 kiadás

Címkék

Megjelent az OpenOffice.org 1.0.1-es verziója. A mostani kiadás fontos frissítéseket tartalmaz, amelyek technikaiak és "social" típusúak is.

A social oldalról az OpenOffice.org mostantól tartalmaz egy installálási útmutatót, amelyet a tarballban lehet megtalálni installation_guide.pdf néven.Az útmutató angol, olasz, német és francia nyelven érhető el. Tartalmazza a single user és a hálózati telepítés menetét is.

A technikai frissítések: az OpenOffice.org ki lett bővítve Mozilla integrációval, és tartalmaz néhány patchet a Solaris/Sparc felhasználóknak.

A változások listáját megtalálod Release Notes-ben. Látogasd meg a letöltési oldalt, hogy megtudd hol juthatsz hozzá a binárisokhoz és a forráskódhoz.

Frissített ipfw2 patchek FreeBSD-stable -hoz

Címkék

Luigi Rizzo kiadta azokat az új patcheket, amelyek lehetővé teszik, hogy ipfw2-t futtassunk a FreeBSD-stable -n. Az ipfw2 a nickneve az új tűzfal kódnak, amely jelenleg a FreeBSD-current -ben található. Ez a tűfal kód sokkal gyorsabb és flexibilisebb, mint a jelenlegi ipfw. Az új ipfw2 a régi ipfw szintaktikáját használja, így a meglevő régi konfigurációs fileok változtatás nélkül használhatók az új tűzfal kóddal.********************************

From: Luigi Rizzo

To: ipfw@FreeBSD.ORG

Subject: updated ipfw2 patches for -stable

As the subject says, the latest patches to run ipfw2 on -stable are at

http://info.iet.unipi.it/~luigi/ipf...le.020715.diffs

They rely on the code that I have committed to -stable last week, and replicate the functionality that is available in -current in the CVS repository.

This version fixes all bugs reported so far (which were limited to minor problems in the userland code, and alignment issues on 64-bit architectures) and implements keepalives to prevent dynamic rules

from expiring when your session is idle for longer than the timeout.

Once you have patched your source tree, you need to add

options IPFW2

to your kernel config file to have the new functionality available, otherwise you will still use the old ipfw code.

You also need to recompile /sbin/ipfw.

Note that this patch *does not* update libalias (I will add

patches for that in the next version of the code).

(For the curious, ipfw2 is a nickname for the new firewall code which is in -current. It is much faster and more flexible than the old one, and implements the old ipfw syntax as a subset, so your existing configuration files should work unmodified -- and if they don't, please report the rule(s) where it chokes so i can fix that).

cheers

luigi

FreeBSD: OpenOffice 1.0.1 kiadás

Címkék

Martin Blapp frissítette az OpenOffice.org portot. Az OpenOffice.org 1.0.1 csomagok elérhetők angol nyelven. Az 1.0.1 már a ports kollekcióban van. A szerző néhány napon belül frissíteni fogja a nyelvi portokat is.

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

From: Martin Blapp

To:

Subject: OpenOffice.org 1.0.1 is out

Hi all,

I just upgraded the port to OO.org , and also made a 1.0.1 package available for english. As usual, it can be downloaded on:

http://projects.imp.ch/openoffice/

I'll update the language dependent ports in the next few days.

Martin

Martin Blapp,

Összehasonlítás: BSD/OS és NetBSD

Címkék

Annak ellenére, hogy a BSD/OS-t és a NetBSD-t különböző fejlesztők, különböző úton járva fejlesztették az elmúlt 9 évben, a két rendszer számos dologban mutat hasonlóságot.

Jeremy C. Reed a BSDNewsLetter's hasábjain egy összefoglalót írt arról, hogy mik is a kulcsfontosságú különbségek, és mik a hasonlóságok a két rendszer között.Legnagyobb eltérés a licenszelésben van. Míg a BSD/OS a következőket mondja: "Ha nem értesz egyet a licenszfeltételekkel, azonnal juttasd vissza a disztribúciót a terjesztőhöz, és visszakapot a teljes árát." addig a NetBSD csak ennyit mond: "Welcome to NetBSD".

A teljes cikket megtalálod itt.

Stabilitása miatt választják a nyílt szoftvert a cégek

Címkék

A vállalatok elsősorban nem a forráskód nyilvánossága és a szoftver változtathatósága miatt választanak nyílt szoftvereket, hanem az ilyen rendszerek stabilitása és a jogtalan hozzáférés elleni védelem, valamint a költséghatékonyság miatt - derül ki egy európai uniós tanulmányból.A nagyfokú stabilitás és a jogtalan hozzáférés elleni védelem a két legfontosabb indok, ami miatt a vállalatok a nyílt forráskódú szoftverek mellett döntenek - áll a berlini székhelyű Berlecon Research tanulmányában, melynek elkészítését az Európai Unió támogatta. Ezzel szemben a nyilvános forráskód és a változtathatóság, tehát azok a tulajdonságok, melyek a nyílt forráskód definícióját adják, csak mellékes szerepet kapnak a választásnál - írja a "Nyílt forráskódú szoftverek alkalmazása vállalatoknál és közintézményeknél: Eredmények Németországból, Svédországból és Nagy-Britanniából" című tanulmány.

A Linux user visszatér - vissza a windowshoz

Címkék

Tony "kNIGits" Collins egy átlagos otthoni felhasználó. Nevezhetnénk Mr. Average John-nak is. Használja a számítógépet, de nem egy bitvadász. Régen a Windows OS-t használta, aztán nem tudni pontosan miért (talán a g33k faktor miatt) úgy gondolta a Linuxra vált (ettől l33t a gyerek). Kipróbált elmondása szerint mindent: Red Hat 5.2, Mandrake 7.0, volt egy kis kitérője a Debian világába, majd megvilágosodott és SuSE 8.0 felhasználó lett.Ezek után kiderült, hogy a összehulló win95 után a Linux sem elég stabil. A Red Hat telepítés után meghalt, az X szerver lassú, a fontok nem jók, az IDE CD-íróval nem tud CD-t írni, stb...

FreeBSD: 4.6.1 Release Candidate 1

Címkék

A FreeBSD 4.6.1 Release Canidate 1 (RC1) már elérhető FTP-n keresztül. Murray Stokely írta: "Ez az RC kiadás még az OpenSSH merge előtt készült (kösz DES!), de tartalmazza a BIND frissítéseket, és néhány fixet a sendmail-hez, ktrace-hez, stb..."A tervezett megjelenése a FreeBSD 4.6.1-nek tegnap lett volna, de egy kicsit csúszni fog. A többi várható megjelenés listáját itt találod. Ezek közül néhány: A második developer preview az 5.0-ból július. 25-re várható, a FreeBSD 4.7 október. 1, míg a várva-várt FreeBSD 5.0 megjelenése november. 20-ra tehető.

Alan Cox: Linux 2.4.19rc1-ac7

Címkék

AC nyomja ezerrel. Naponta adja ki a legújabb kernelpatchjeit. Itt a Linux 2.4.19rc1-ac7.

Letölthető: patch-2.4.19-rc1-ac7.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]

Linux 2.4.19rc1-ac7

o Merge more HPPA bits

o tcp_diag alignment fixup (Richard Henderson)

| Pending DaveM making a nicer fix Im sure

o Hopefully fix the SMP APIC problems rc6 gave some people (James Cleverdon)

o Fix incorrect __init in PCI core (Takayoshi KOCHI)

| Caused hotplug bugs

o Update IBM PCI hotplug driver (Greg Kroah-Hartmann)

o Add SCSI blacklist entries for Centristor (Robert Sertic)

o Update Documentation/sysctl/vm.txt (Steven Cole)

o Fix kdev_val macro (Steven Cole)

o Allow a user to force dma 0 to be allowed for ISAPnP [be nice to autodetect this ?] (Gerald Teschl)

o Hopefully fix bogus config question bug (me)

o Fix hang on some boxes if you unload maestro audio then hit the volume buttons (Samuel Thibault)

o Fix aha152x scsi (Juergen Fischer)

o Bluetooth pcmcia drivers (Marcel Holtmann)

M$: Steeve Ballmer belátta, hogy a Linux nem drágább a Windowsnál

Címkék

Steve Ballmer a Microsoft szoftveróriás vezérigazgatója elismerte, hogy a Linux futtatása nem drágább a Windows operációs rendszer üzemeltetésénél. Ez azért érdekes, mert a Microsoft hosszú időn keresztül hősiesen bizonygatta, hogy a Linux TCO-ja (Total Cost of Ownership - azaz a birtoklás teljes költsége) sokkal magasabb abban az esetben, ha egy cég Microsoft Windows szerver helyett Linuxot üzemeltet. Nem elég, hogy éveken keresztül ezt állították, de még lépésről-lépésre le is vezették, hogy ez így van. Ezt azzal indokolták, hogy igaz ugyan, hogy a Windows szerver operációs rendszert meg kell vásárolni egy bizonyos összegért, és az is igaz, hogy a Linuxhoz ingyen is hozzá lehet jutni, de végeredményképpen a Linux üzemeltetése drágább mert sokkal képzettebb, és sokkal több ember kell az üzemeltetéséhez. Ezt szépen ki is számolták, és a végén kijött nekik az eredmény: a Windows TCO-ja lényegesen alacsonyabb a Linuxénál. Most úgy látszik, hogy jobb belátásra tértek, mert Ballmer úgy nyilatkozott egy Varbusiness cikkben, hogy "Nem tudjuk kitalálni, hogyan lehetnénk olcsóbbak a Linuxnál. Nekünk mint cégnek, azon kell lennünk, hogy egy teljesen új gondolkodásmódot vezessünk be."

Debian Weekly News - 2002. július. 16

Címkék

Megjelent a DWN, a Debian közösség szokásos heti hírlevelének a legfrissebb száma. Ez a hírlevél az ez évi 27-dik DWN kiadás.

A tartalomból:

  • GNU/Linux csapat küzdelem
  • DebConf 2 sikeresen lezárult
  • Debian a mobiltelefonodon?
  • Mely csomagoknak kell a Non-US-be "mennie"?
  • Helwett-Packard a Debian-t választotta
  • Debian Mini-Konferencia januárban
  • Új stabil revízió látott napvilágot
  • Randevú Ian Jacksonnal
  • Free Font létrehozása
  • Csomag integritás ellenőrzés
  • Új és említésre méltó csomagok
  • Elárvult csomagok



    A hírlevelet elolvashatod itt
  • Wine(x) BridgeBuilder

    Címkék

    Egy újabb játék, ami megy wine(x)-szel...Hello.


    A "nagyobb" játékok után, itt egy mind méretben, mint ráfordított időben kisebb játék, ami elindult wine(x)-szel. A neve BridgeBuilder.



    Elegendő ezt az egy fájlt letölteni:



    bbdemo.exe


    Csak ez az egy verzió létezik, vagyis a demo, ami 122K.