Linus Torvalds: Linux 3.17

Kernel

Linus bejelentette a 3.17-es kernel végleges kiadását. Mivel ezt a hetet utazással tölti, a jövő héten pedig kezdődik a LinuxCon EU rendezvény, a beolvasztási időablak nem a megszokottak szerint alakul. Vagy három hetes lesz a megszokott két hetessel szemben, vagy csak lassabban fog elindulni a szokottnál. Linusnak nincs ellenére, hogy már most érkezzenek hozzá a "pull" kérések (valójában már kapott is néhányat), de azokat a jövő hétnél előbb valószínűleg nem kezdi el majd feldolgozni.

A bejelentés itt olvasható. A 3.17 kernel újdonságairól részletes összefoglalót szokás szerint a KernelNewbies aktuális, Linux 3.17 oldalán lehet majd találni (még üres).

( uid_20184 | 2014. 10. 06., h – 08:44 )

Vartam mar, az Acer C720 Chromebookhoz van benne touchpad tamogatas (tobbek kozott).

---
Tetragir

( ssa2 v | 2014. 10. 06., h – 17:55 )

Ismét leszarták megy-e rajta az aktuális nvidia driver...

Ezzel is lefordul, csak éppen nem működik az x. A legújabb kernelekkel csak szerencsés esetben szokott működni. A 3.16-tal pl. nem volt gond már az elején sem, ha jól emlékszem.
Van amikor nem fordul le, vagy lefordul de a modult nem lehet betölteni. Illetve a jelenlegi esetben lefordul, a modult be lehet tölteni, de nem indul a grafikus felület.
Ez szerintem leginkább azért van, mert a kernelfejlesztők magasról szarnak az egészre. Pont nem érdekli őket, hogy a kernelükön megy-e az nvidia zárt drivere. Ilyenkor csak azt lehet tenni, hogy vár az ember egy újabb driverre, esetleg a disztró fejlesztői készitenek valami javítást a kernelhez. Aztán egyszer majd működni fog. De addigra meg kiadják a 3.18-at, aztán kezdődik minden elölről (vagy nem).

Nálam 343.22 van fent és az nem megy a 3.17-es kernellel. Az nvidia aránylag gyakran ad ki drivereket, ezzel nincs is baj, de szerintem az lenne a legjobb megoldás, ha előre egyeztetnének velük a kernel fejlesztői és eleve olyan kernelt adnának ki, amivel továbbra is működik az aktuális nvidia driver, vagy legalább figyelmeztetnék az nvidiát az őket is érintő változásokra, hogy gyorsabban tudjanak reagálni. Jelenleg szerintem semmiféle kommunikáció nem zajlik köztük. A kernel fejlesztői kiadják a késznek gondolt változatot, aztán az vagy megy, vagy nem. Ha megy, akkor mázlija volt az nvidia kártyát használóknak. Ha nem, akkor az nvidia előbb-utóbb tudomást szerez a hibáról és majd valamikor kiad egy újabb változatot. Szerintem nem így kellene működnie a dolgoknak...

Csak nem azt akarod mondani, hogy a 3.17-rc(n) az nVidia fejlesztői számára nagy titkot képeztek, miközben én a szobámból bármikor ránézhettem a forrásra, a patch-ekre, a changelogokra. Ha figyelted, amit írtam a Fedora 21-gyel kapcsolatban, már a 3.16.4-es kernel megjelenése előtt írtam, hogy az ath9k_htc regressziója javítva lesz ebben a kernel verzióban. Vajon honnan tudtam, miközben nem vagyok kernel fejlesztő? (Azt most hagyjuk, hogy végül is a Fedora fejlesztői a 3.16.4-es kernelt Fedora 20-hoz fordították le, míg Fedora 21-hez egyből a 3.17-est. A gépemen ez utóbbi fut éppen.)

Szóval hagyjuk már ezt, hogy a kernel fejlesztőinek kell egy zárt driver-t fejlesztő céghez alkalmazkodni, valamitnt az nVidia mérnökeinek fogalmuk sem volt arról, mi lesz a 3.17-esben. De, tudták, csak vagy nem volt elég ember, pénz, paripa, fegyver az adott célra, vagy lusták voltak, vagy lassúak, vagy szabadságon volt, aki ezzel foglalkozott, vagy töpreng, hogyan alkalmazkodjon a változásokhoz.

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

"de szerintem az lenne a legjobb megoldás, ha előre egyeztetnének velük a kernel fejlesztői és eleve olyan kernelt adnának ki, amivel továbbra is működik az aktuális nvidia driver, vagy legalább figyelmeztetnék az nvidiát az őket is érintő változásokra, hogy gyorsabban tudjanak reagálni"

ROTFL

Ezért vannak a kernelből (és más termékekből is, Windows, iOS a világ végéig sorolhatnám) -rc, alpha, béta, technical preview kiadások. Hogy a rá, hozzá fejlesztők, ISV-k a végleges kiadásra ráhegeszthessék a szarukat és ne akkor kelljen kapkodniuk, amikor a végleges már kinn van.

Fordítva ülsz a lovon. Netán fejlesztő vagy?

--
trey @ gépház

Ez akkor lenne okés, hogyha lenne kiadási ütemterv, amit tartanak. Azaz tudni lehet, hogy az rc mikor jelenik meg, mikor jelenik meg a beta, mikor a végleges, ekkor be lehet ütemezni a cégnél az erőforrásokat, hogy elkészüljenek időben.
Nem mindegy, hogy 1 heted, vagy 3 hónapod van a változáskövetésre.

Ehhez képest a kernelnek nincs stabil ütemterve, Linus kénye-kedve szerint működnek a dolgok:
http://hup.hu/cikkek/20140817/linus_torvalds_linux_3_17-rc1
http://hup.hu/cikkek/20140826/linus_torvalds_linux_3_17-rc2

A 3.16 kiadásakor nem jelentettek be semmilyen ütemtervet, csak azt, hogy hopp, lehet kommitolni a 3.17-hez. Ez így nem éppen ISV-barát dolog.

Ugyanígy nincs szó arról sem, hogy mik azok az API változások, amik várhatók, lesz-e az rcN után az rc-ben API változás vagy csak bugvadászat folyik stb. Terv nélkül nehéz.

iOS 8 esetén a beta megjelenésekor kint volt a komplett dokumentáció a változásokról.
Windows 10 esetén például lehet tudni, hogy benne lesz a DirectX 12, az Early Access-ben ki is lehet azt próbálni.
http://blogs.msdn.com/b/directx/archive/2014/10/01/directx-12-and-windo…

Minden kernel alrendszernek van sajat listaja, ahol az erdemi fejlesztes zajlik, es a maintainerek kuldenek Linusnak pull request-et, nem egyik naprol a masikra valtoznak a dolgok. Aki akarja, az tudja is kovetni a valtozasokat. Az nvidia fejlesztoi is megtehetik, es meg is teszik - az xserver ABI valtozasokat ugyanugy le tudjak kovetni, mint a kernel valtozasait, es meglepo modon oket nem nagyon lattam meg emiatt problemazni.

"es a maintainerek kuldenek Linusnak pull request-et"
Az pont naprol napra valtozik, hogy Linus mit fogad be, azaz mi lesz a kiadasban, es mi nem.

Tok mindegy, hogy a $RANDOM_ISV_NAME koveti-e az adott alrendszer listajat, ha egy ember kenye-kedve donti el, hogy mi lesz a release-ben es hogy az mikor jelenik meg.

( locsemege v | 2014. 10. 06., h – 21:12 )

Fedora 21-hez már fordul, hamarosan már lesz ilyenem. :)

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