|
|
So nothing particularly odd or scary happened this last week, so there is no excuse to delay the 6.5 release. I still have this nagging feeling that a lot of people are on vacation and that things have been quiet partly due to that. But this release has been going smoothly, so that's probably just me being paranoid. The biggest patches this last week were literally just to our selftests. The shortlog below is obviously not the 6.5 release log, it's purely just the last week since rc7. Anyway, this obviously means that the merge window for 6.6 starts tomorrow. I already have ~20 pull requests pending and ready to go, but before we start the next merge frenzy, please give this final release one last round of testing, ok? Linus
- A hozzászóláshoz be kell jelentkezni
- 639 megtekintés
Hozzászólások
5.16rc1 ota el van torve az AMD-n a nested virtualizacio VMware-hez. :(
- A hozzászóláshoz be kell jelentkezni
Ez feature, nem bug Torvalds szerint. Többször világosan megmondta, hogy ilyen zárt illetve 3rd party kernelmodulokkal nem fogja a visszafelé kompatibilitást fenntartani, ha eltörnek, akkor így járás esete forog fenn. Ezt a VMware-nek kell megoldani, hogy az új verziójuk menjen újabb kerneleken. Ez egyben a zárt kód átka is, várhatsz rájuk, míg szíveskednek javítani. FOSS-nál a közösség már rég kijavította volna.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
kar, hogy te mar megint nem ertesz a temahoz, fogalmad sincs, hogy en mirol beszelek de azert iszonyat megszakerted...
a kernel tolta el egy patchcsel, amit egy tulbuzgo fejleszto kuldott be, es revertelni kene.
- A hozzászóláshoz be kell jelentkezni
Nem, te nem érted megint. A kernel behozott valami új funkciót, ami tényleg új feature, nem bug, és NEM érdekli őket, hogy a VMware-rel mi lesz. Ráadásul ezt nem szemétségből csinálják, hanem a fejlesztői szabadság miatt, most képzeld el, hogy te vagy a kernelfejlesztő, és lennének ötleteid, hogy milyen irányban viszed tovább a kerneled, milyen API-k alapján, de ugye nem csinálhatod, mert ilyen nagy cégek elvárnák, hogy ilyen-olyan kernelmoduluk működőképes maradjon, meg jajj, ne törd el, aztán te meg megkötött kézzel csak úgy lavírozhatnál, olyan akadályok között, amit ők megengednek, meg másnak a fekete dobozként működő zárt kódjait bástyázd körbe a saját kódodban körbehekkeléssel. Kicsit olyan farka csóválja a kutyát kategória.
Mondom, ez halál komoly, ezt a VMware-nek told be bugreportba, hogy oldják meg. Ez az ő feladatuk, nem várhatják mástól, hogy majd megcsinálja helyettük, se a kernelesektől, se az AMD-től. Arra se hivatkozhatnak, hogy Intellel megy, mert nem releváns. Ez nem csak a VMware-nek szól, anno a ZFS fejlesztők is küszködtek ilyesmivel, NVidia is szélmalomharcol ebben a tekintetben. Ehhez hozzá kell szokniuk, hogy a Linux világa egy gyorsan változó valami, nem olyan, mint a Windows, hogy megírod, aztán hátra lehet dőlni, mert menni fog 5-10 évig, a következő főverzióig, de még talán annál tovább is. Még én se vagyok kivétel, pl. a 6.4-es kernel óta a kernelfejlesztők átdolgozták azt az API-t, amivel a free, vmstat, /proc/akármi jelenti le a használatban lévő és szabad memóriát, és elég nagyot néztem, hogy mitől nőtt irreálisan a memóriafogyasztás. Nem tetszik, de nem reklamálhatok, nem én fejlesztem a kernelt, a tényleges fejlesztőknek kell hogy szabadságuk legyen ebben.
Emlékszem anno ezt ment akkor is, mikor az AMD nekikezdett a nyílt GPU drivereinek, és az újabb kernelekkel eltört a régi zárt Catalyst driver, abból is milyen háborgás volt, aztán ment a hőbörgés fórumokon, hogy szar az Arch, megbízhatatlan a bleeding edge rolling, és ez ment egész addig, míg végül a debianosok, és ubuntusok is ezt kapták arcukba, akkor jött rá mindenki, hogy ez nem bug, hanem feature. Vagy most pl. az Arch csomagfenntartók azon szórakoznak 1 éve, hogy visszatartják az 5.2-es Bash-t, mert van néhány behozott feature, meg megváltozott működés, ami eltör korábbi scripteket, de nem értik meg, hogy ennek nem állhatnak ellen, mert ezek szándékos változások, és így fognak maradni. Vagy emlékszem, mikor bejött a systemd, és sok disztró meg embere úgy volt vele, hogy ezt a szart ők nem (ezzel még egyet is értenék), de ugye észre kellett vegyék, hogy széllel szemben itt nem fognak hugyozni, és szépen adoptálta is mindenki, mert nem volt sok választása. Most ez lesz a Waylanddel, Pipewire-rel is. Sőt, valamennyire ez volt a Python 2.x vs. 3.x váltásnál is, változott a nyelv, de sok fejlsztő próbált a régi verzión ragadni évekig, taktikáztak, hogy majd ez jó lesz 2032-ig, meg különben is LTS, de végül meg kellett törjenek, mikor a legtöbb mainstream disztró szépen száműzte a Python 2-s csomagokat a tárolóiból.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
hallod te mirol beszelsz?????????????????????
Nem, te nem érted megint. A kernel behozott valami új funkciót, ami tényleg új feature, nem bug, és NEM érdekli őket, hogy a VMware-rel mi lesz.
mirol beszelsz????????????
en konkret patchrol, ami mar sok verzio ota ott van, halal felesleges, es eltorte a vmware guesten a nested virtualizaciot KVM alatt.
te?
- A hozzászóláshoz be kell jelentkezni
Az a te bajod, ha nem akarod érteni. Megnéztem egyébként a neten, erről semmit nem találtam. Elhiszem azonban neked, hogy nem megy, ha csak egy patch, akkor próbáld eltávolítani, vagy feltenni egy olyan kernelt, amin ez nincs rajta.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
amirol fent irsz annak SEMMI KOZE ahhoz, amirol en beszelek.
ha nem talal semmit, nem kerestel eleg jol. ha jol kerestel volna akkor megtalaltad volna mondjuk ezt, vagy ezt. vajon ezek alapjan mar megtalalod a commitot? ;)
- A hozzászóláshoz be kell jelentkezni
Hagyd, ő ilyen.
A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.
- A hozzászóláshoz be kell jelentkezni
Meglepő, péntek környékén még valami automata tesztelés során jelentkező nagyobb regressziót javítottak, és arról volt szó, hogy még egy hetet csúszik a végleges 6.5 kiadása. Ezek szerint megoldották. Nincs még kint az Arch Testingben, de gondolom órákon belül várható.
Szerk.: na, már le is jött. Eddig jól megy, semmi változást nem érzek a 6.4.x verziókhoz képest. Semmi nem lett hűvösebb, gyorsabb, bloatabb, de az ellenkezője sem, az új procisebezhetőségek foltozása ellenére sem. Ez mondjuk inkább jó jel. Az is igaz, hogy rövid ideje futtatom, ha van valami alattomosabb bug, az sokszor csak bizonyos helyzetekben jön elő, így korai elkiabálni.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni