Linus Torvalds: Linux 3.3-rc4

 ( trey | 2012. február 19., vasárnap - 10:00 )

Újabb hét, újabb -rc kiadás. Linus ma bejelentette a 3.3-as kernel negyedik kiadásra jelölt változatát. A kiadás kissé csúszva érkezett, de ahogy Linus írja, most van rá mentsége. Az elmúlt napokat egy kellemetlen "floating point state corruption" bug levadászásával töltötték. A hiba javítását nehezítette, hogy az csak több feltétel együttes fennállása esetén jött elő. Csak 32 bites x86-on, csak modern, az AES-NI utasításokat támogató processzorok megléte, ezek támogatásának engedélyezése és olyan WiFi driver használata esetén jelentkezett, amely használja ezeket az utasításokat. Linus feltette a költői kérdést: Miért használtok még mindig 32 bites kerneleket? Linus levelében feltűnően buzdít mindenkit a 64 bites kernelek használatára...

Részletek a levélben.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

> Miért használtok még mindig 32 bites kerneleket?

- mert a géppark még számmottevő arányban tartalmaz 64 bitet nem támogató processzorokat, és ráadásul az Intel egy időben random adta a 64 bitet, lásd: bizonyos P4-ekben van, viszont bizonyos (sokkal újabb) Core Duo-kban nincs, ráadásul ennek nyilvántartását anno. még a leltárba sem vezettük be

- mert 32 bites userlanddel szívás 64 bites kerneleket alkotni. (és 10+ éve telepített, és azóta upgrade-elt rendszereket nem oly mesés dolog full 64-bitre újratelepíteni)

- mert a 32 bites kernellel, PAE-val alapjaiban véve semmi gond nincs... (kivéve néhány speciális felhasználási területet, pl. bitang nagy adatbázis-szerverek)

mert a 32 bites kernellel, PAE-val alapjaiban véve semmi gond nincs

+1

----
Debian SID Xfce | Dropbox

+1

+1. Sok régi vasba csiholunk életet. Van élet 64 bit alatt is.

====================================================================
- "Ha minden férfi egyforma, akkor miért válogatnak annyit a nők???"
- A nők az egyforma dolgok közt nagy figyelemmel és körültekintéssel válogatnak.

Én pl. most is egy Athlon XP-n dolgozom, ez az itthoni gépem. Vettem bele kis plusz RAM-ot, a komoly futtatásokat máshol végzem, minek váltanék?

De Linus mintha csak azt kifogásolná, hogy 64 bitre is képes rendszeren miért használ bárki 32 bites verziót.

1, ő arra gondolt, azokon a gépeken amelyek támogatják a 64bit-et
2, a 32bit userland 64bit kernellel támogatott a debian disztribúcióban, és bár soha nem használtam (saját kernellel viszont kb 1 évig) a tapasztalat az, hogy az olyan programokkal van gond, amelyeknek van kernel kapcsolata (driver) azonban nálam stabilan működött
3, sok reportot olvastam, hogy maga a platformváltás hozott gyorsulást.

> Miért használtok még mindig 32 bites kerneleket?
Pl. ezért.

A szálban az utolsó előtti tipp az I/O scheduler megváltoztatására megoldotta? Én épp ezért használok deadline ütemezőt, és azzal nincs fennakadás USB-re írás vagy egyéb I/O művelet során.

Azóta nem használtam 64bites Linuxot. :)
Majd ha nagyon unatkozom, akkor kipróbálom.

Nekem segített, bár nem 100%-os eredményt hoz. Néha még így is megakad...

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

OMG, lehet megoldottad egy lassan éve fennálló problémámat. :)

Nebassz*, hogy ezért másol egy gigát egy óráig a gépem pendrive-ra :o

* elnézést

> Linus levelében feltűnően buzdít mindenkit a 64 bites kernelek használatára...

Ez azt jelenti, hogy a 3.4-ben deprecated lesz az x86-32 platform, a 3.5-től pedig kiveszik a kernelből?

Lehet hogy addigra már lesz x86-128 támogatás is. Már ha gyártanak ilyen CPU-kat. :-)

Igen.

Nem, csak úgy érezte hogy kicsit ő is force -olja a dolgot. Ha belegondolunk, 2000. augusztusában már full specification állapotban volt az amd64 platform ( http://en.wikipedia.org/wiki/X86-64#History_of_AMD64 ), ami több, mint egy évtizede történt. Nagyon lassan olvad sajnos a 32 bites éra, és egy kicsit belerúgott ő is.
Nem hiszem, hogy ez bármit is jelent a közeljövőre nézve.

--
http://neurogadget.com/

Meg mindig gyorsabban talan mint az IPv4 -> IPv6 :)

Masreszt nem teljesen vilagos a "sajnos". Miert kene nekem 64 bit? Desktop rendszreimen mind max 1G memoria van (ok, tudom, ha tobb memoriam lenne akkor is megoldas lehet a PAE is pl), felesleges 64 bites kernel, sot, azzal meg tobb eroforrast is fogyasztana a gep. Most azert vegyek meg ram-ot, hogy elmondhassam, 64 bites kernelem van? :) mert amugy amire en hasznalom, eleg. Akkor meg minek? Nyilvan serveren kisse mas a leanyzo fekvese, ott szinte csak 64 biteseim vannak (par oskori maradvany 32 bites meg).

Szerintem siman onzo celbol irta be. Ha nem lenne felhasznaloi bazisa a 32 bites rendszereknek, nem kellene fejleszteni es egyszerusodne a dolga.

tompos

lol:)

Egy fel arch a 27 kozul, nem tetel.

A sokkal halottab dolgok, mint parisc vagy alpha is benne van meg a kernelben.
Sot ha jol remlik az alpha nem reg kapott rendes arch git fat, valakinek van ideje foglalkozni vele.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azért baj, mert rengeteg plusz munkát, beleölt erőforrást jelent. Egy disztribúció esetén (de legyen ez akár az Ms. Windows) nem kevés munkával jár mind2 platformot egyenlően supportálni, és ez csak 1 példa volt.

--
http://neurogadget.com/

Ne keverd a 64 bites kernelt, a 64 bites userland-del!
Amúgy meg, debianban itt lesz nemsoká a rendes multiarch támogatás!

Épp tegnap néztem, hogy már mernek igérni Wheezy-re, hogy bemutatkozik, és remek lesz, sőtt állítólag Natty-ben már van is.

Talán lassan eljutunk oda Linuxon is, ahol mondjuk a Solarisok, pl. a kezdetek óta vannak, by design, amióta tudnak 64 bitet.

Anno, már nem emlékszem ki mondta 2004-ben irc-en, hogy debianon tök megállt a 64bites fejlesztés/ fejlődés (emlékszem, akkor még experimental sid amd64 repo volt csak, kisérletező kedvűeknek, mint én, sőtt tán valamelyik bootloaderben még mintha bug-ot is fogtunk volna), mert tfheen volt kb. az egyetlen a Debian csapatban, aki látta, hogy kéne az egész etwast csinálni, csak akkor még a dpkg/apt sehol sem volt ennek a supportjában, és egy csomó szűklátókörű fejlesztőbe ütközött akkor...
Éééés, most értünk el oda, hogy megvalósulni látszik. Érdemes a fenti link History fejezetét elolvasni! ;-)

Nem is csoda. Meg mindig vannak olyan dolgok, amikbol nincs 64 bites verzio. De ez a kisebbik gond. A nagyobbik az az, hogy sok helyre teljesen felesleges es ertelmetlen 64 bites rendszert rakni. Mivel a binarisok valamicskevel nagyobbak, ahol nagyon keves memoriabol kell megoldani a dolgokat, ott sokkal kedveltebb lehet a 32 bites rendszer. Mire gondolok: pl bizonyos ipari PC-k. Nem egy mai darab, de arra, amire kell, arra teljesen jo, nem rossz, ha up-to-date kernel van rajta, viszont se ertelme nincs 64 bites rendszert rarakni, se haszna.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az ipari rendszerek miatt ne húzzuk már vissza az egész IT -t. Legyen rajta ARM, MIPS vagy valami profibb cucc. De ez csak az én véleményem.

--
http://neurogadget.com/

De nem lesz rajta, es nincs is ertelme. Egy P3 proci vigan elmuzsikal barhol, es ma mar szemet aron aruljak.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Egy ipari cumo, stabilan megy, es gonosz emberk nem erik el, akkor NEM piszkaljuk, csak ezert mert van ujabb kernel.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Erre szoktam mondani, hogy ami működik, azt nem kell megjavítani.

Fuszenecker_Róbert

Ez igaz, csak tessen tudni az ipari cuccok azok nem egyszer keszultek, most meg nem, hanem most is keszulnek, keszulgetnek. Es oda azert nem biztos, hogy az ember egy muzeumi kernelt tenne csak azert, mert Mr. Linux nem hajlando tamogatni bizonyos dolgokat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Mr. Linux nem hajlando tamogatni bizonyos dolgokat."

?? :)

--
http://neurogadget.com/

vajon mi lehet Mark Shuttleworth válasza Linus kérdésére?:)

Ha arra gondolsz h "32 bit recommended" akkor allitolag kov. verzional mar 64 bites lesz az ajanlott.

Félreértitek. Arra gondolt, hogy újabb, 64 bites platformon ne használjatok 32 bites kernelt. Nem egyáltalán, mert 32 bites platformon persze ez kell még.

--
joco voltam szevasz

Akkor ezt tessek elsuttogni a felhoszolgaltatoknak is. Mert onnet meg eleg sokszor gomolyognak ki 32 bites felhopamacsok.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Most komolyan, te úgy gondoltad, hogy mi úgy gondoltuk, hogy tisztán 32 bites architektúrán akarna velünk 64 bites kernelt futtatni? LOL.

Szerintem ezt rajtad kívül senki sem gondolta.

--
trey @ gépház

Pedig az első hozzászólás is így kezdi.

Hol is?

--
trey @ gépház

És ebben hol van, hogy ő 32 bit only gépen akar 64 bites kernelt futtatni?

--
trey @ gépház

Hát azzal magyarázza a 32 bit megmaradását a gépeken, hogy sok gép van ami 32 bit only. Mi ez ha nem annak félreértése, hogy a fenti tárgyú gépek nem képezik a beszélgetés tárgyát?

Én elvesztettem a fonalat. Kizárólag 32 bites gépen fizikailag lehet 64 bites kernelt futtatni?

--
trey @ gépház

Mer logikai önellentmondás az, amikor egy olyan kérdésre h
"Miért nem használtok 64 bites binugzot [újabb 64 bites architektúrán]"
az a válasz h
"Mert sok a 32 bites gép"

De biztos találnánk kiváló autós hasonlatot is :)

Nyilván nem szó szerint kell érteni, ugyanúgy vonatkozik bármely tejipari termék készítőire.


Bye Bye Nyuszifül

2.6.: still a stable kernel, but accept bigger changes leading up to it (timeframe: a month or two).
2..x: aim for big changes that may destabilize the kernel for several releases (timeframe: a year or two)
.x.x: Linus went crazy, broke absolutely everything, and rewrote the kernel to be a microkernel using a special message-passing version of Visual Basic. (timeframe: "we expect that he will be released from the mental institution in a decade or two").
Torvalds, Linus (2005-03-02). Message to Linux kernel mailing list. Retrieved on 2006-12-11.

x32 ABI (Application Binary Interface) is an under development Linux project that allows programs compiled for the x32 ABI to run in the 64-bit mode of x86-64 while only using 32-bit pointers and data fields. Though this limits the program to a virtual address space of 4 GB it also decreases the memory footprint of the program and in some cases can allow it to run faster.

(http://en.wikipedia.org/wiki/X86-64)

Ez lessz szerintem a megoldas. Jo kerdes mikorra latunk belole valamit...

Ebben megoldottak mar az intel VGA-k KMS problemajat ?

még van nekik?

Én tettem egy próbát. Elegem lett az Ubuntu(Gnome)-ból, mert a több monitoros környezetben fárasztó hasznánlni a hülyeségei miatt. Gondoltam visszatérek a SuSE-ra amit még a KDE 4.0 megjelenésekor hagytam ott a rengeteg bug miatt. Gondoltam, ha már lúd legyen kövér kipróbálom ezt a 64 bites mókát, sőt legyen mégkövérebb még btrfs-re is tettem az egészet.
Az eredmény az lett, hogy borzasztó lassú lett minden. Vagy a 64 bit vagy a btrfs de rohadt lassú. Egy elfekvő partícióra telepítettem egy 32 bit-est ext4-re és látványosan gyorsabb. Fele a boot idő. A következő próba alkalmával ki fog derülni, hogy a btrfs vagy a 64 bit a ludas.

sirkalmi

Csak siess a próbával, mert holnap reggel telepítem újra a gépem... :)

Komolyra fordítva a szót, tényleg érdekelne, mert a melóhelyemen 64bites oprendszert használok btrfs-sel (mondjuk nem érzem lassúnak), de több helyről is hallottam ilyeneket. Holnap pedig nekiállok otthon is az úratelepítésnek és ha addig nem készül el az összehasonlításod, akkor 64bit/btfs lesz.

Tömörítést használsz egyébként? Ha igen, milyet?

Szerintem a btrfs miatt lassú.


tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE