Linus Torvalds: Linux 3.3-rc4

Címkék

Ú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ások

> 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)

+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.

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.

> 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?

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).

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 

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 

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

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 ?

É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?