Linux

UnixReview: User Mode Linux

Címkék

Március közepén írtam két cikket az User Mode Linux-ról. Akkor elmondtam, hogy szerintem milyen előnyei vannak, miért érdemes bárkinek feltelepítenie a gépére, hogy hogyan lehet szinte két perc alatt működésre bírni egy vagy több önállóan futó Linux rendszert a Linux rendszerünk alatt. Hülyén hangzik, ugye? Pedig nem hülyeség ;-)Most valami hasonló (talán részletesebb) leírást készített Joe "Zonker" Brockmeier, amelyet a hasábjain olvashatsz el itt.

Kapcsolódó cikkeink:

UML: User Mode Linux (1. rész - a kezdetek)

UML: User Mode Linux (2. rész - a kapcsolat)

A 2.6.0 megjelenéséig mindenképpen javítandó hibák listája

Címkék

Andrew Morton egy olyan listát állított össze, amely a "most-fix list" névre hallgat, és azokat a feladatokat tartalmazza, amelyeket a kernelfejlesztőknek mindenképpen be kell fejezniük, mielőtt a 2.5.x fejlesztői kernel átfordul a 2.6 szériába. A listáját azzal adta elő, hogy ha a listán levő dolgokat befejezik, az nem jelenti automatikusan azt, hogy a 2.6-ot szállítani fogják. Szerinte a 2.6 elnevezés azt kell hogy jelentse, hogy a felhasználók nyugodtan áttérhetnek a 2.4-ről azzal az elvárással, hogy ami a 2.4 alatt működött, az működni fog a 2.6 alatt is, a kernel nem halálozik el, a kernel nem zabálja meg az adataikat, és nem fut úgy, mint egy kutya (jó kis hasonlat, csak tudnám mit jelent ;-)Andrew listája nem tartalmazza a szokásos bugokat (azokat amelyek amúgy is szerepelnek a Bugzilla-ban), a kívánság-lista elemeket, és az általános driver problémákat. A listáját három nagy részre lehet felbontani:

  • mindenképpen javítandó bugok
  • legújabb funkciók és gyorsítások
  • fontos driver bugok


Olvasd el a komplett listát itt.

Itt az idő a kernel nemzetköziesítésére?

Címkék

Az LKML-en egy olyan ötlet bukkant fel, miszerint eljött az ideje annak, hogy az operációs rendszer magját - azaz magát a kernelt - nemzetköziesíteni kellene. Mi is jelent ez? Azt, hogy lassan az összes linuxos program rendelkezik lokalizációs támogatással, képes megszólalni minden program azon a nyelven, amely nyelven a felhasználója beszél, így vannak akik úgy gondolják, hogy itt az idő arra, hogy a Linux kernel is több nyelven beszéljen. Jelenleg a kernel csak az angol nyelven hajlandó "beszélni", ez a gyári default.Számos próbálkozás irányult arra, hogy a fent említett "problémát" megoldják. Az egyik megoldás az lenne, hogy a különböző printk() sztringek különböző nyelven lennének benne a kernel forrásában, és futási időben (runtime) lenne kiválasztva a szükséges nyelv. Ennek az elgondolásnak a hátulütője az, hogy a kernel mérete túlságosan megnőne. Ennél talán jobb lenne az, ha fordítási időben lehetne kiválasztani a kernelbe fordítandó nyelvet. Linus elmondta a véleményét a kernelen belüli lokalizációról:

"Gyerünk csináljátok, csak ne a kernelben. Csináljátok a klogd-dal, vagy valami hasonlóval."

Szóval a "fordítókat" kényszerítik az ún. user space megoldások keresésére. A feladat nem könnyű, mert például a 2.5.67-es kernel 52000 lefordítandó üzenetet tartalmaz.

Linus állásfoglalása itt.

Egyébként volt a kernel magyarra fordításának egy erőtlen próbálkozása. A magyarítást el is kezdték a 2.4.18-as kernel forrásának alapján. Hogy milyen eredménnyel? Nézd meg a kapcsolódó cikkeinket:

Pinglin

Elkészült az új PINGLIN-PATCH

Kernel: swap előolvasás (prefetch)

Címkék

Thomas Schlichter egy érdekes ötlettel állt elő az LKML-en. Egy levelet postázott a levlistára, amelyben egy olyan új kernelfunkciót vázolt fel - mint lehetségesen implementálható feature - amelyet egyik operációs rendszer sem tartalmaz jelenleg, de hasznos lehetne főleg az asztali számítógépek területén. Az elgondolás az, hogy be kellene olvasni előre a kilapozott (swapped out) memóriaoldalakat akkor, ha van szabad rendelkezésre álló fizikai memóri (RAM), a CPU éppen idle (azaz nem csinál semmit), és az IO terhelés is alacsony. Hogy mire lenne ez jó?Mivel a számítógép éppen üresben jár, "nem kerülne semmibe" ha a kilapozott oldalakat előre behúznánk a fizikai memóriába. Képzeljük el az alábbi helyzetet:

A felhasználó internetezik, a böngészőjében számos ablak meg van nyitva. Majd gondol egyet, és játszani kezd valamilyen játékkal. A játék sok RAM-ot igényel, ezért a rendszer kilapozza a felesleges böngészőt a lemez swap területére. A felhasználó befejezi a játékot, majd elmegy iszik egy kávét. A számítógép tulajdonképpen "idle" állapotba kerül, ilyenkor vissza lehetne lapozni a fizikai memóriába az előzőleg kilapozott böngészőt, és mire a felhasználó újra visszatér a gépéhez, nem kell arra várnia, míg a rendszer a memóriába tölti a böngészőt, hiszen az a kávészünet alatt megtette ezt.

Schlichter szerint a megoldás nem okozna teljesítménybeli negatív változást, hiszen csak szabad erőforrásokat használnánk fel.

Az elgondolásnak csak egy buktatója van. Hogy nincs jelenleg olyan algoritmus, amely meg tudná jósolni, hogy melyik az az oldal amit be kell húzni a memóriába előre. Azaz, hogy melyikekre lesz szükség legközelebb. A rendszer teljesítménye csökkenthet, ha rossz oldalakat tölt be, hiszen ha nem azokra van szükség akkor a rossz oldalakat előbb ki kell lapozni, majd a szükséges oldalakat be kell tölteni.

Bővebben a dologról itt.

Zack Brown: Kernel Traffic #214

Címkék

Megjelent a Zack Brown által karbantartott, heti rendszerességgel megjelenő, az LKML (Linux Kernel Mailing List) levelezési lista tartalmát kivonatos formában feldolgozó hírlevél, a Kernel Traffic.

A Linux kernel fejlesztésének legfrissebb híreit itt olvashatod.

Disztro hírek: LFS 4.1 és KNOPPIX 3.2-04-28

Címkék

Hosszú várakozás után végre megjelent a LFS (Linux from Scratch - azaz Linux 0-ról indulva, gyártva, telepítve saját kézzel). Meg tudod nézni a fő LFS oldalon itt, a mirrorok 24 órán belül frissülni fognak. Tegnap megjelent a népszerű Debian alapú "Live" terjesztés legújabb kiadása is, a 3.2-04-28-as verzió. Ez letölthető innen.

Honlap: www.knopper.net/knoppix

Linus véleménye a DRM-ről

Címkék

Linus Torvalds kommentálta a DRM-et (Digital Right Management). A kommentár nem osztott maradéktalan sikert a kernelhackerek között. Talán azért, mert olyan kijelentéseket is tartalmazott mint ez: "Világossá akarom tenni, hogy a DRM teljesen OK a Linux szempontjából."

Linus levelében leírja, hogy Őt nem érdekli, hogy ki mit csinál a Linux kernellel. A GPL kimondja, hogy a forráskódot ki kell adni, de nem korlátoz senkit abban, hogy bárhogyan módosítsa a forrást. Többen szeretnék a Linux kernelt (bináris) digitálisan aláírni, és így forgalmazni (disztribútorok). Linus szerint nincs ezzel semmi baj. Még akkor sem, ha ezért RMS Őt "csak egy mérnöknek" is nevezi. Ő ezt vállalja, hozzátéve, hogy egy olyan mérnök, aki a lehető legjobb OS-t szeretné létrehozni.

Őt nem érdekli, hogy valaki alá akarja írni a kernelt, mert Ő is ezt teszi minden nap indirekt módon, amikor a kernel.org-ra felteszi a forrást. A tarballokat a kernel.org aláírja, hogy azok akik letöltik, biztosak lehessenek benne, hogy ugyanazt a forrást kapják, amelyet Linus feltöltött. Ugyanezt elvégezve egy binárissal mi a különbség? Semmi. Az emberek biztosak lehetnek benne, hogy ez a valódi bináris, meg lehet benne bízni.

Olvasd el Linus levelét:From: Linus Torvalds

To: Kernel Mailing List

Subject: Flame Linus to a crisp!

Date: Wed, 23 Apr 2003 20:59:45 -0700 (PDT)

Ok,

there's no way to do this gracefully, so I won't even try. I'm going to just hunker down for some really impressive extended flaming, and my asbestos underwear is firmly in place, and extremely uncomfortable.

I want to make it clear that DRM is perfectly ok with Linux!

There, I've said it. I'm out of the closet. So bring it on...

I've had some private discussions with various people about this already, and I do realize that a lot of people want to use the kernel in some way to just make DRM go away, at least as far as Linux is concerned. Either by some policy decision or by extending the GPL to just not allow it.

In some ways the discussion was very similar to some of the software patent related GPL-NG discussions from a year or so ago: "we don't like it, and we should change the license to make it not work somehow".

And like the software patent issue, I also don't necessarily like DRM myself, but I still ended up feeling the same: I'm an "Oppenheimer", and I refuse to play politics with Linux, and I think you can use Linux for whatever you want to - which very much includes things I don't necessarily personally approve of.

The GPL requires you to give out sources to the kernel, but it doesn't limit what you can _do_ with the kernel. On the whole, this is just another example of why rms calls me "just an engineer" and thinks I have no ideals.

[ Personally, I see it as a virtue - trying to make the world a slightly better place _without_ trying to impose your moral values on other people. You do whatever the h*ll rings your bell, I'm just an engineer who wants to make the best OS possible. ]

In short, it's perfectly ok to sign a kernel image - I do it myself indirectly every day through the kernel.org, as kernel.org will sign the tar-balls I upload to make sure people can at least verify that they came that way. Doing the same thing on the binary is no different: signing a binary is a perfectly fine way to show the world that you're the one behind it, and that _you_ trust it.

And since I can imaging signing binaries myself, I don't feel that I can disallow anybody else doing so.

Another part of the DRM discussion is the fact that signing is only the first step: _acting_ on the fact whether a binary is signed or not (by refusing to load it, for example, or by refusing to give it a secret key) is required too.

But since the signature is pointless unless you _use_ it for something, and since the decision how to use the signature is clearly outside of the scope of the kernel itself (and thus not a "derived work" or anything like that), I have to convince myself that not only is it clearly ok to act on the knowledge of whather the kernel is signed or not, it's also outside of
the scope of what the GPL talks about, and thus irrelevant to the license.

That's the short and sweet of it. I wanted to bring this out in the open, because I know there are people who think that signed binaries are an act of "subversion" (or "perversion") of the GPL, and I wanted to make sure that people don't live under mis-apprehension that it can't be done.

I think there are many quite valid reasons to sign (and verify) your kernel images, and while some of the uses of signing are odious, I don't see any sane way to distinguish between "good" signers and "bad" signers.

Comments? I'd love to get some real discussion about this, but in the end I'm personally convinced that we have to allow it.

Btw, one thing that is clearly _not_ allowed by the GPL is hiding private keys in the binary. You can sign the binary that is a result of the build process, but you can _not_ make a binary that is aware of certain keys without making those keys public - because those keys will obviously have been part of the kernel build itself.

So don't get these two things confused - one is an external key that is applied _to_ the kernel (ok, and outside the license), and the other one is embedding a key _into_ the kernel (still ok, but the GPL requires that such a key has to be made available as "source" to the kernel).

Linus

-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org

More majordomo info at http://vger.kernel.org/majordomo-info.html

Please read the FAQ at http://www.tux.org/lkml/

Linux Tábor 2003

Címkék

(linuxtabor.hu) Ismét megrendezésre kerül a Linux Tábor. A harmadik, hagyományosan Szerencsen tartott tábor időpontja 2003. június 29. - július 12. A két, egyenként egy-egy hetes kurzus lehetőséget ad mind kezdő, haladó és profi linuxosoknak tudásuk továbbfejlesztésére. A kezdő szinten várjuk azokat is, akik csak most ismerkednének meg a linux-al. A délelöttönként tartott előadások után változatos programokkal gazdagítjuk az élményeket. A szakmánál maradva, a résztvevők megismerkedhetnek a BSD-vel, mely egy a linuxhoz hasonló, szintén szabad szoftver alapú operációs rendszer. Lehetőség van saját gépet hozni, amire segítünk feltelepíteni a linuxot, melyet az LME CD-író projekt keretében a helyszínen oda is tudunk adni. A részvételt esti borkóstolás illetve pincevacsora teszi feledhetetlenné. A tábor önköltségi alapon szerveződik, így a részvételi díj igen alacsony. Felnőtt LME tagok 22000,- forintért 6 napig teljes ellátást kapnak az oktatáson kívül. A jelentkezési határidő 2003. május 31. A táborban a helyek korlátozottak, így oktatásra hetente csak 60 fő jelentkezését tudjuk elfogadni. A kisérők száma gyakorlatilag korlátlan.


Jelentkezni az Interneten a linuxtabor.hu weboldalon lehet, ahol részletes információk is olvashatók a táborról. A táborral kapcsolatos kérdéseket a linuxtabor@webhome.hu e-mail címen várjuk.


Minden érdeklődőt szeretettel várunk!