Fejlődnek a video driverek

VGA

Öcsém hív, az egyik régi számítógépe nem boot-ol. Jól van, ránézek. Tényleg. Régi kernellel megy. Frissítek mindent a régi kernellel, probléma ugyanaz az újjal: megáll, mint a szög. A régi 6.14.11-es, az új 6.15.9-es. Nézem a logokat, nova-core driver megdöglött. Kb. azt sem tudom, mi az, de hangzásra meg utánaolvasás után valami nVidia csoda. Majd megtalálom ezt a cikket.

Tehát ez már hülyebiztos, mert Rustban írták, meg minden ellen is véd, tehát akkor biztos nagyon jó.

Nem jó. Nagyon nem. Amit C-ben írtak, az még működött, ez meg a logok alapján láthatóan összedől, a gép be sem boot-ol, de mosolyogjak hozzá, mert ez legalább Rustban íródott.

Letiltottam a kernel frissítését, továbbá beállítottam defaultnak a 6.14.11-es kernelt a Grubban.

Apropó, hogyan lehet megmondani 6.15+-os kernelnek, hogy ha nVidia hardware-t lát, ne ezt a Rustban írt szutykot töltse be - illetve csomagolja az initrd-be -, hanem a jól bevált C-ben írt nouveau drivert?

Az oprendszer Fedora 41.
 

  • 3069 megtekintés

( kroozo v | 2025. 08. 05., k – 09:38 )

Mondjuk erősen bele is van írva, hogy ez bizony kb az első step abban a driverben, mert még kurvára nincsen kész, de ja, a rust a baj :)

Mondjuk erősen bele is van írva, hogy ez bizony kb az első step abban a driverben

Akkor mit keres a stable ágban úgy egyáltalán? Hát nem erre lettek pont kitalálva a branchek?

még kurvára nincsen kész

Akkor mit keres a stable ágban úgy egyáltalán? És ráadásul defaultként?

Elég egyértelmű iocsemege kolléga kérdése: "hogyan lehet megmondani 6.15+-os kernelnek, hogy ha nVidia hardware-t lát, ne ezt a Rustban írt szutykot töltse be", tehát ez a félkész Rust szutyok az alapértelmezett az öcsi production-ready disztrója által szállított kernelben! Ez epic fail, bárhogy is nézzük.

Úgy, hogy a vanilla kernel az ilyen, mindig is ilyen volt, Linus már kurva rég megmondta, hogy az nem direktben usable, azért van a distributor (tényleg magyarázni kell ezt neked a kernelről, hogy miért nem branch?). A kérdés, hogy a fedora miért nem kapcsolta ki alapból? (Azért, mert a fedora ált gyorsan húzza be az új dolgokat, ez bizony benne vana  buliban)

Linus már kurva rég megmondta

Össze-vissza beszélsz. Amit Linus valójában megmondott, az ez. Nem a mainline-ról van szó, hanem a STABLE-ről. Oda hogy kerülhetett át, ha egyszer ennyire bugos?

A kérdés, hogy a fedora miért nem kapcsolta ki alapból?

Nem, a kérdés az, hogy egy ilyen félkész bughalmaz miért lett alapértelmezettnek beállítva? Ha mindenki tudta, hogy félkész, miért nem bukott ki a review során (akár Linus, akár Fedora), hogy talán nem kéne alapértelmezettnek lennie?
(Szóval nem az a baj, hogy a Fedora nem kapcsolta ki, hanem eleve az, hogy egyáltalán alapértelmezettnek lett valaha is beállítva mikor még félkész. Az már csak hab a tortán, hogy ráadásul ezt senki nem vette észre, kiment production-be.)

Olvasni tudsz?

Mainline
Mainline tree is maintained by Linus Torvalds. It's the tree where all new features are introduced and where all the exciting new development happens. New mainline kernels are released every 9-10 weeks.
Stable
After each mainline kernel is released, it is considered "stable." Any bug fixes for a stable kernel are backported from the mainline tree and applied by a designated stable kernel maintainer. There are usually only a few bugfix kernel releases until next mainline kernel becomes available -- unless it is designated a "longterm maintenance kernel." Stable kernel updates are released on as-needed basis, usually once a week.
 

Bemennek a patchek, linux kb 10 hetente releasel, és onnantól az a stabil, max a következő windowban bejövő bugifexből bakcportolnak rá, míg ki nem jön a következ. Nincsen ezen kívül hosszú életű teszting ág. És ezekbe a kernelekbe rendszeresen kerülnek be félkész dolgok, inkrementálisan. Tudod, release early, release often. És mindig is az volt a stance, hogy majd a disztró összerakja endusernek valóra. És ebből rendszeresen volt nyaffogás, van az a viszonylag új keletű dolog, hogy LTS kernel, ami többek között ezt is célozza valamennyire. Na, ez most nem ilyen, ez egy sima release :)

Aha, persze. A kernel fejlesztési folyamatának mélyreható ismeretéről tökéletesen tanúskodik a "Hát nem erre lettek pont kitalálva a branchek?" mondatod. Ja, nem. Annyira gyönyörű lejjebb is, ahogy a kizárólag a saját fejedben létező lófaszt próbálod számonkérni a linux fejlesztésen, és jössz azzal, hogy branchelniük kellene, és hát ezek hülyék.

Már megint fingod sincs miről beszélsz, az van.

A stable kernelben nem csak az van benne, ami kész van. Ez mindig is így volt. A kernel release-ek közül a stable semmilyen driver minőségére nem jelent garanciát.

Akkor mit keres a stable ágban úgy egyáltalán? És ráadásul defaultként?

Mert Linus így döntött. És nem default, maximum ha a disztró úgy konfigurálja a kernelt. Az nem Linus hibája, ha a Fedorások úgy döntöttek, hogy ez legyen a default. Ez egy félkész driver, ott is van a Kconfigban:

Choose this if you want to build the Nova Core driver for Nvidia
      GPUs based on the GPU System Processor (GSP). This is true for Turing
      and later GPUs.

      This driver is work in progress and may not be functional.

      If M is selected, the module will be called nova_core.

Amúgy mindenféle driverek esetén tök alap az, hogy félkész dolog van benn a stabil kernelfában. Ilyen volt az ext4 támogatás is, először a 2.6.19-es kernelben jelent meg, aztán a 2.6.28-ban lévő verzióra lett az mondva, hogy az már stabil és használható.

https://kernelnewbies.org/Linux_2_6_19#EXT_4

https://kernelnewbies.org/Linux_2_6_28#Ext4

Szerintem nem igazán érted, hogy miként működik a kernel fejlesztése, és mit jelent a stable kernel.

Tanuljatok már meg olvasni.

Idemásolom: Nem, a kérdés az, hogy egy ilyen félkész bughalmaz miért lett alapértelmezettnek beállítva?

Mert Linus így döntött.

És direkt odaírtam ezt is: nem bukott ki a review során (akár Linus, akár Fedora)

És igen, direkt erre találták ki a brancheket. Egy külön branchbe kellene ezzel szarakodni, nem a mainline kernelben, oda csak akkor kéne átkerüljön, ha már működik úgy-ahogy.

mindenféle driverek esetén tök alap az, hogy félkész dolog van benn a stabil kernelfában

Ja, ha már félig-meddig működőképes, és akkor is baszom nagy EXPERIMENTAL cimkével ellátva. A csenge próbálkozásokat tipikusan nem szokta beengedni Linus, csak ha már áll valahogy. Most mégis bekerült, és alapértelmezett is lett, akármit is pofáztok.

De miért kellett volna a kernel.org review-ján kibuknia? A kernel.org policyje szerint félkész dolog elfér a mainline/stable kernelben, mindig is így volt és most is így van. Teljesen jogosan van benne a mainline kernelben a nova-core driver.

Az, hogy a Fedora az új kernelben miért forgatja be modulként, annak meg semmi köze ahhoz, hogy Linus hogy dönt. Eleve a dokumentáció megmondja, hogy ez a driver nincs készen.
Amúgy ha megnézed a nova-core Kconfigját (linkeltem feljebb), default ki van kapcsolva a kernelbe forgatása.

config NOVA_CORE
    tristate "Nova Core GPU driver"
    depends on PCI
    depends on RUST
    depends on RUST_FW_LOADER_ABSTRACTIONS
    default n

A Fedora kernelébe ezzel a komittal került be: https://src.fedoraproject.org/rpms/kernel/c/fc343b9928b15914396277c0c6a…

Jól látszik a kernel-x86_64-fedora.config fájl 5216-os sorában a megfelelő rész:

CONFIG_NOVA_CORE=m

A Fedora kernelek ilyenek, követik az upstreamet, és mindent beforgatnak modulként, amit csak lehet.

 

A csenge próbálkozásokat tipikusan nem szokta beengedni Linus, csak ha már áll valahogy. Most mégis bekerült, és alapértelmezett is lett, akármit is pofáztok.

Az, hogy mi kerül be és mi nem, az Linus egyszemélyi döntése, ő a projekt teljhatalmú vezetője. Ha ő így döntött, akkor így döntött és kész. Így csinálja már 35 éve, pont most akarod ennél az egy kernelmodulnál ezt megkérdőjelezni?

A problémád és értetlenséged ez volt:

Akkor mit keres a stable ágban úgy egyáltalán?

Elmondtuk neked, hogy az a normális, hogy félkész dolog van a kernelben, de nem értetted meg.

Nincs semmilyen review szabály, ami miatt el kellett volna utasítani ezt a kernelmodult, nem kellett volna kibuknia sehol sem review során semminek. Egyetlen egy végső review szabály van: az van a kernelben, amiről Linus azt gondolja, hogy bemehet. Ez minden mást felülír.

És azt gondolta, hogy ez a driver a kernelben teljesen okés. Ugyanis teljesen normális egy ilyen állapotú driver a kernelfában, miért kéne kivételezni ezzel a driverrel? 

A Fedora meg beforgatja modulként, mert mindig is ezt csinálta.

Semmilyen review szabály nem sérült, nem kellett volna kibuknia sehol, ami történt, az a dolgok normál menete. A Fedora rolling release ilyen, meg a kernel is ilyen. Mindig is ilyen volt. Miért kellett volna másként lennie? 

A problámád az, hogy NEM ÉRTESZ hozzá, de azért csak jár a szád. Nem akartalak még jobban beégetni, de tessék, ha ragaszkodsz hozzá:

Az, hogy mi kerül be és mi nem, az Linus egyszemélyi döntése

Mondom én, hogy hülye vagy hozzá (kiemelés tőlem): "for example, of the over 9,500 patches which went into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus himself."
Írd és mondd: MINDÖSSZE 1.3% VOLT LINUS DÖNTÉSE (segítek, hogy a hozzád hasonló értelmi fogyatékosok is megértsék: 98.7%-ról NEM Linus döntött.)

Elmondtuk neked, hogy az a normális, hogy félkész dolog van a kernelben, de nem értetted meg.

Elmondtam, hogy a működésképtelen az nem félkész, a félkésztől elvárják ugyanis, hogy lehet, nem tud mindent még, de akkor se fagyjon le a picsába. És ha félkész, akkor a leírásába bele kellett volna írni, hogy "EXPERIMENTAL" (lásd pl mint itt vagy itt vagy itt)
Kerek perec le van persze írva ez is a kernelfejlesztési szabályzatban, de nem értetted meg. (Valószínűleg még csak el sem olvastad, csak jár itt a szád.)

1. Itt tehát hibázott Linus, mert működésképtelen kódot engedett stable-be, miközben legendás arról, hogy máskor ezért ki szokott kelni magából.
2. Hibázott a Fedora is, mert működésképtelen Rust fost fordított a kernelébe.
3. Kurvára tök mindegy, hogy mit okoskodsz, iocsemege öccsének akkor is lefagy a gépe, és hiába tolod itt a hülyeségeidet, akkor is bugos a Fedora kernele, mert lefagy induláskor.

locsemegének az a problémája, hogy olyan szállítót választott, amiről tudható, hogy a release early, release often modellt követi, emiatt könnyen előfordulhatnak problémák frissítéskor. Főleg a kernel frissítésekor.

Ha valaki egy ilyen modellt választ, akkor meg ne picsogjon, ő választotta ezt.

blacklisteld a nova_core modulet: https://discussion.fedoraproject.org/t/f42-updating-to-kernel-6-15-3-20… . Nyilván a nouveau-t ne (Aki ezt elnevezte, annak jövök egy üveg sörrel. Külsőleg.)

Én értem egyébként, hogy csak ezért nem húzod újra, mert minek, de egyébként egy ilyen kioskos gépen valójában nyugodtan ki lehet pinelni a kernel, nagy baja nem lesz (ha nem updateled az egészet, akkor se nagyon)

Elmondtam, hogy a működésképtelen az nem félkész, a félkésztől elvárják ugyanis, hogy lehet, nem tud mindent még, de akkor se fagyjon le a picsába.

De ez nem működésképtelen. Ha olvasnál fórumokat, akkor látnád, hogy sokaknak megy. Függ a hardver típusától, ami egy driver eserén nem meglepő dolog. Nem kezel minden Nvida eszközt, ez igaz. Ha a nagyokos disztribútor ezt és a noveaou-t is egyszerre modulként elérhetővé teszi, összeakadhatnak, ez is így van. Ez nem a driver készítőjének a problémája.

Írd és mondd: MINDÖSSZE 1.3% VOLT LINUS DÖNTÉSE (segítek, hogy a hozzád hasonló értelmi fogyatékosok is megértsék: 98.7%-ról NEM Linus döntött.)

Az is Linus döntése, hogy megbízik másokban (a maintainerekben), amikor beemelnek valamit a kernelfába. Minden a végén Linus felelőssége. A mainline repository-t Linus menedzseli.  De ez le is van írva a linkelt oldalon, pontosan ez előzi meg az általad kiemelt dolgokat: 

There is exactly one person who can merge patches into the mainline kernel repository: Linus Torvalds.

Csak az ő felelőssége az, hogy mi kerül be a mainline kernelbe, mivel csak ő mergelhet oda. Az, hogy másokban megbízik, és amire a maintainer azt mondja, hogy jó és ő bemergeli, az Linus döntése. Az, hogy egy patchet megnéz, vagy vakon bemergeli, az Linus döntése, rajta múlik az egész.

 

Kurvára tök mindegy, hogy mit okoskodsz, iocsemege öccsének akkor is lefagy a gépe, és hiába tolod itt a hülyeségeidet, akkor is bugos a Fedora kernele, mert lefagy induláskor.

Üdv a Linux világában, nem tudom miért kell meglepődni azon, ha egy rolling release disztribúció néha lefagy. Az egész Linuxos világ a konstans béta, release early, release often modellre épül (ez amúgy is a nyílt forrású fejlesztés egyik alap dogmája,  és pont a Linux kernel a fő példa rá, mint helyes működésre a nyílt fejlesztésben), cégek dollármilliárdokat keresnek azzal, hogy valamiféle stabilitást vigyenek ebbe.

"Az egész Linuxos világ a konstans béta, release early, release often modellre épül"

Pont ezért utálom az összes rolling disztribet, kivétel nélkül. Igazából nekem nem azzal van bajom, ha valaki rolling-ot használ, lelke rajta. A linuxos influenszerekkel van bajom, akik hirdetik ezt az igét az új felhasználóknak, de elfelejtik megemlíteni azt a tényt, hogy mennyire instabil dolgok ezek. Jön az új felhasználó, feltelepíti, örül, hogy a linux milyen cool(tényleg az), aztán eltelik 1-2 hét, és :

-elmegy a hang

-nem megy már a suspend, pedig ment

-nem áll le a gép

-nem megy a video lejátszás többé

-nem bootol be a gép

-elmegy a hálózat

 

stb,stb... A fő kretén influenszer ebből a szempontból DT. Kinyílik tőle a bicska a zsebemben.

ugyanezek mind pont meg szoktak tudni tortenni egy debian distupgrade-kor is. :) meg egy ubuntu LTS > LTS upgradekor is.

szerver kornyezetben ilyenkor szokas ugy donteni sokszor, hogy oke, akkor most nem upgrade lesz, koltoztetjuk a szolgaltatasokat a 3.14-csaba. :)

szoval az nem valtoztat semmin, hogy rolling-e egy disztro vagy sem (ugyanaz a kernelkod megy bele mindbe), csak mashova helyezi az elszarodast idoben. :)

Amúgy senki nem kötelezi Linust arra, hogy 10 hetente újabb kernelt adjon ki, át is nézhetné a patcheket. Mi baj történne abból, ha csak évente egy új kernel release lenne, összesen egy hetes merge window-val? Vagy kétévente lenne új kernel?

Az Linus döntése, hogy ilyen a fejlesztési folyamat, amilyen.

hat, kb. megallna az osszes Linux szerver oldali hw-fejlesztes. az tortenne :)
a gyartok pedig atallnanak hataros idon belul a MinuX-ra. (kov. betu az ABC-ben fork, ahova be is lehet tolni a pacheket ertelmes timewindow alatt) es az open compute alliance penze onnantol a MinuX fejlesztok zsebeit tomne :)

nem ertem a problemadat. a linux kernel folyamatos fejlesztes alatt van by design, ott allsz meg ahol akarsz es maradsz a seggeden az XYZ verzion. ahogyan ezt a disztrok is teszik eloszeretettel, sot, (elsosorban security) fixeket is backportolnak az adott XYZ verzioba. :)

senki nem kenyszerit senkit, h minden nap az adott napi git pull-bol forgatott kernelt kelljen hasznalnia. :)

csemege szeret veszelyesen elni, most megtapasztalta hol b*a el, mikor egy kiosk-ra fedorat rakott, mert "otthon bevalt a hipszterproject". nincs itt semmi latnivalo :)

ilyen felhasznalasra is van amugy fedora, csak azt ugy hivjuk, h silverblue/atomic. es ott picit mas a frissites menete. :)

( Zsugabubus | 2025. 08. 05., k – 11:05 )

Szerintem a nouveau sem egy főnyeremény, miért nem használod az nvidia zárt driverét inkább?

Ez egy nagyon régi, bontószökevény gép. A feladata annyi, hogy egy bemutatóteremben, kioskként a cég saját honlapján a vevő tudja böngészni a termékeket, nézni hozzá az árakat. Ehhez nem kell az utolsó cseppig kifacsarni a video processzor képességeit, pláne úgy, hogy a video processzor tranzisztorai is nagyjából fából vannak kifaragva, mert annyira régi. :)

Körülbelül 2 perc alatt bootol be a gép.

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

Akkor nem értem, hogy miért akarja ezt a csoda új drivert használni hozzá, azt írják, ez csak a legújabb GPU-kal működik.

Fedorához van 390-es driver is (rpmfusion repoból), az még a GeForce 400/500-asokhoz is jó. Attól, hogy nem kell a kártya minden képességeit kihasználni, a stabilitás még jól jöhet :)

Ez egy AMD alapú brand gép, talán valami HP vagy Fujitsu-Siemens, s egy nagyobb cég vedlette le. Nem tudom, pontosan milyen VGA van benne, annyira nem érdekelt.

A nouveau-t azért szeretem, mert beállítom, hogy frissítse magát a gép automatikusan, nem kell hozzányúlni, nem tainted a kernel, elvan, működik. A zárt driver esetében vagy előre fordított modul kell, de ha a kernel hamarabb frissül, mint a modul, a következő boot már grafikus felület nélkül lesz. Ha pedig dkms, meg effélék, akkor forrásból fordul az interface, de az elég para, hogy sikerül-e - általában igen -, nem épp fordítás közben jön áramszünet. Egy gyenge, lassú vason külön élmény forrásból fordítani.

Itt az a cél, hogy frissítse magát a gép, stabilan menjen, ne kelljen hozzányúlni. A nouveau stabil, legfeljebb lassabb a zártnál. De már jó rég óta Compiz is megy nouveau driverrel. Ez persze most nem kell, csak megjegyeztem.
 

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

Ez jogos, de kalapácsom van és mindent szögnek látok. ;) Szóval Red Hat 7.2 környékén kezdtem (talán 2001-ben), aztán volt ott még valami Red Hat 8.x meg Red Hat 9, utána Fedora Core 1, stb., jelenleg Fedora 42. Elég jól ismerem, nem kívánom azt az érzést, hogy nem tudom, mit kell csinálni egy Debiannal, ha frissítés közben jön egy áramszünet. Fedorát eddig mindig megmentettem a legváltozatosabb lesántulásokból is, sohasem telepítettem újra.

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

Tudom, de nem telepítem újra ezt a gépet, amin minden úgy van beállítva, ahogyan kell. És igen, azt is tudom, hogy hogyan lehetne a beállításokat költöztetni, de nekem ez nem ér annyit. Pontosabban inkább nézem a nőket a strandon, minthogy egy újabb Linuxot konfiguráljak. Ha baj van, így vagy úgy meg szoktam oldani Fedorával. Persze előfordul, hogy kérdezek, de ez még mindig a gyorsabb megoldás.

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

Pedig egyszer megérné az időt rászánni, hogy egy stabilabb oprendszerrel újratelepítsd, és akkor még többet nézhetnéd a nőket a strandon, mert nem jönnének mindenféle gonosz rozsdás driverek.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nekem a Fedorával a meghatározó emlékem az, hogy használtam 2 hónapig boldogan, majd egy frissítés után soha többé nem indult el az X. Akkoriban még nem voltam annyira gyakorlott az X hibakeresésében, ráment egy napom érdemi eredmény nélkül. De az is valami driver issue volt, ráadásul valami szögegyszerű intel kártyával. Végül letörültem, és visszakerült az Ubuntu. 

Amit akarok mondani: az elvvel van a bajom. Hogy minimálisan sincs a stable ág tesztelve.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Van az tesztelve :) A kernel valóban kicsit rolling jellegű (amit én egyébként személy szerint nem nagyon értek), nincs egy upstream major ráfagyasztva egy fedora verzióra, de azért várnak valamennyit. De személyes tapasztalataim alapján a Fedora meglehtősen fájdalommentes. Igen, dist upgrade környékén néha jönnek be új dolgok, dolgok változgatnak, de megdögleni nem nagyon szokott. Vannak körülöttem ubuntu nem LTSt használók, onnan sokkal többször szoktam panaszkodást hallani (bár az igaz, hogy az elmúlt 1-2 évben talán kevesebbet...)

Bármennyire is a legalsó réteg a kernel ring0-ban, meglepő módon nem szokott vele baj lenni. Persze mondhatod épp ezt a topikot, de egyfelől ez egy ősrégi gép, ráadásul nVidia VGA-val szerelve, és itt automatikusan, update repoból történt a frissítés.

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

A Fedorába nem csak dist upgrade környékén jönnek be "fura dolgok", egy sima verzión belüli upgrade is megöli a gépedet, és utána szophatsz konzolban, hogy valami grafikus kijelzésed legyen.

Hidd el, én nagyon szeretnék hinni, de kétszer volt fenn Fedora a gépemen, és mindkétszer 1-2 hónapon belül eljutottunk oda, hogy egy sima yum/dnf update utáni rebootnál széthullott az egész a rákba (az egyik esetben kernelpánikból kellett kivakarni, és utána nem volt X egyáltalán, a másik körben simán csak nem volt X egyáltalán). Nem viccből mondom, hogy nincs tesztelve.

Ehhez képest a munkahelyemen Ubuntu LTS-t használok, és nincs panaszom rá, itthon pedig volt Ubuntu nem-LTS és kb az volt, amit a Fedora-ról állítasz, dist-upgrade -nél esett szét. Ott tényleg vannak néha sorjás élek, de egy verzión belül nem nagyon mozognak semmivel, kernellel se, mással se, nagy meglepetések akkor vannak, ha valami PPA-t felraksz. Ráadásul Ubuntunál valahogy működik az, hogy nem tud úgy bebootolni (legalábbis vagy 8 éve nem láttam ilyet tőle), hogy valamilyen X ne legyen, akár SVGA driverrel, de kiszenvedi magából a grafikus felületet. Ez az, amit én desktopnak nevezek.

És csak hogy tiszta legyen: össze tudok én vakarni egy döglött Linuxot "mélykonzolból" is, nem kell hozzá GUI. Évekig volt Gentoo-m. Csak különbség van aközött, hogy tudok és hogy szeretek ilyet csinálni. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

neked masik fedora termek valo:

https://fedoraproject.org/atomic-desktops/

https://docs.fedoraproject.org/en-US/fedora-kinoite/updates-upgrades-ro…

ahanyszor nekem segiteni kellett ubuntu-s gepen X-et feleleszteni... hat, annyiszor nem volt gondom Fedoraval elsodleges desktopkent 5 ev alatt. :) hal'istennek mar nem erint egyik problema sem.

A Fedorába nem csak dist upgrade környékén jönnek be "fura dolgok", egy sima verzión belüli upgrade is megöli a gépedet, és utána szophatsz konzolban, hogy valami grafikus kijelzésed legyen.

Yep, új kernel tud landolni dist-upgradetől függetlenül (és a fentebbi hozzászólásomban finoman megfogalmazva utaltam is rá, hogy ez faszság, majort nem kéne beengedni nem dist upgradekor)

Hidd el, én nagyon szeretnék hinni, de kétszer volt fenn Fedora a gépemen, és mindkétszer 1-2 hónapon belül eljutottunk oda, hogy egy sima yum/dnf update utáni rebootnál széthullott az egész a rákba (az egyik esetben kernelpánikból kellett kivakarni, és utána nem volt X egyáltalán, a másik körben simán csak nem volt X egyáltalán).

Értem, én meg az F25 óta használom, egyszer volt dist upgradnel valami "komolyabb" megállás (egyébként nem video related), ami miatt baszódni kellett vele, szerintem kb háromnegyed órát (ebből 35 perc volt, míg kerítettem egy pendriveot, és valakivel kiirattam bootolósra).

Nem viccből mondom, hogy nincs tesztelve.

De, valamennyire van, de tényleg nem úgy, mint a releasek

Stable kernel updates

The upstream kernel community support the latest major version with stable updates (6.y.z releases). These updates are released approximately once a week, although they can occur more or less frequently. Once the upstream kernel community makes a stable release, Fedora builds it and submits it as an update to Bodhi. These updates are typically left in Bodhi for testing for several days before being submitted to the stable updates repository.

Major kernel updates

The Linux kernel releases new major versions (6.y releases) every few months. When this occurs, Fedora updates to the new major version after a couple upstream stable releases. When the updates are submitted to Bodhi, more time is allowed for testing than stable updates to ensure there are no serious regressions.

 

 , itthon pedig volt Ubuntu nem-LTS és kb az volt, amit a Fedora-ról állítasz, dist-upgrade -nél esett szét

Ezt én kb a nem Ubuntu LTSről állítottam. :) A fedora nem szokott szétesni, csak az-az megváltozik benne, többnyire eseménytelenül, pl kicserélik a pulset pipwire-re, ilyesmi. Nyilván, az új swk néha nem pont olyanok, mint a régi, meg más bugjaik vannak, de szétesni nem szokott. (Leszámítva a gnomeot, azt pár update után elengedtem, azok hülyék)

Ráadásul Ubuntunál valahogy működik az, hogy nem tud úgy bebootolni (legalábbis vagy 8 éve nem láttam ilyet tőle), hogy valamilyen X ne legyen, akár SVGA driverrel, de kiszenvedi magából a grafikus felületet. Ez az, amit én desktopnak nevezek.

És csak hogy tiszta legyen: össze tudok én vakarni egy döglött Linuxot "mélykonzolból" is, nem kell hozzá GUI. Évekig volt Gentoo-m. Csak különbség van aközött, hogy tudok és hogy szeretek ilyet csinálni. 

Én értem, csak mondom, én majd tíz év folyamat fedorával a hátom mögött nem látom, hogy ne működne. Szerintem bőven megbízhatóbban muzsikál, mint a nem LTS bubi, cserébe frissebb (és a nem LTS bubiról meg én pont ilyen szarokat látok, amik szerinted nincsenek). Meg úgy álltában, imho a bubi messze nem olyan jó, mint amennyire de facto lett :) 

Bocs, rengeteg a meló, nem mindennap jutok ide el.

Szóval, az Ubuntunak is megvannak a maga hibái, elismerem, van is vele szívás rendesen, de legtöbbször nem az alaprendszerrel van baj. Nem tudják eltagadni a Debianos örökséget, azok a dolgok még mindig elég jól működnek. A rápakolt Gnome (Unity) ellenben... mindegy, nem is akarok róla beszélni.

Lehet futok vele még egy kört valamikor, úgyis akarok majd egy játszós desktop VM-et telepíteni bizonyos okokból, és ott jobb lenne RPM alapú cuccot használni. A Debian/Ubuntuban egyetlen dolgot utálok, de azt nagyon, a csomagépítést. Számomra totálisan illogikus, rendszertelen ahogy működik, és nem bírom ráerőltetni az agyamat. Emiatt jobb lenne valami RPM alapúval nyomulni, de még nem találtam meg a tutit.

A fent említett Atomic Desktop-ot majd megnézegetem, érdekesnek tűnik.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Szóval, az Ubuntunak is megvannak a maga hibái, elismerem, van is vele szívás rendesen, de legtöbbször nem az alaprendszerrel van baj. Nem tudják eltagadni a Debianos örökséget, azok a dolgok még mindig elég jól működnek. A rápakolt Gnome (Unity) ellenben... mindegy, nem is akarok róla beszélni.

Ja, az ubi se használhatatlan egyáltalán, bár én egyre kevésbé kedvelem. Egyébként részben éppen azért, mert LTSben is rendre szokott lenni valami ordas nagy marhaság, amivel vagy nem tudnak, vagy leginkább nem akarnak mit kezdeni... A nem működik az /etc/init.d/networking restart wontfix volt talán a kedvencem, de az összeakad minden a networkdvel (vagy a netplannel, fene se emlékszik már), ami IPt szeretne baszogtatni, szóval kb bármi HA megoldás glhf is dobogós... Illetve van egy olyan kép a fejemben, hogy nem igazán van már az a hozzáadott értéke a debianhoz képest, ami annak idején volt, mikor kitalálták...

A fő erénye szerintem, hogy ha nem tudod eldönteni, hogy két párhuzamos next-gen techből melyik fog bejönni, akkor meg kell nézni, mit választottak, és a másik :D

De viccet félretéve, alapvetően szerintem ízlés kérdése, egyáltalán nem tűnik érdemi szinten szarabbnak a fedora. Ez a havonta összedől biztosan nem az, amit én magam körül látok. Imho rpm földén ez kifejezetten rendben van. Kicsit nagyobb nyugiért egyébként nem tűnt rossznak mostanában az opensuse-se, és nem csinálják azt a faszkodást, mint az RH a Centos körül, jó múltkor néztem, egész szimpi volt, bár a repok mi-honnan kicsit kaotikusnak tűntek elsőre.

Lehet futok vele még egy kört valamikor, úgyis akarok majd egy játszós desktop VM-et telepíteni bizonyos okokból, és ott jobb lenne RPM alapú cuccot használni. A Debian/Ubuntuban egyetlen dolgot utálok, de azt nagyon, a csomagépítést. Számomra totálisan illogikus, rendszertelen ahogy működik, és nem bírom ráerőltetni az agyamat. Emiatt jobb lenne valami RPM alapúval nyomulni, de még nem találtam meg a tutit.

Mondjuk ez érdekes, nekem az esetek 99.9%-ban annyira egykutya, hogy dnf vagy apt install, meg remove... Csak egyszer fogok írni egy wrappert, ami az összes ilyen szar összes subparancsát tudja, és attól függetlenül, hogy hogyan kevertem őket össze, az éppen aktuális osnek megfelelően adja ki, aztán beteszem a világ összes distrójába, amivel valaha dolgom van :biliből kéz kivesz:

Persze. A gond nem ez. A gond az, hogy amikor matatok, és lendületből beírom, hogy apt show foobar, aztán nyekken, hogy nincs apt, mert ez egy fedora, akkor átírom, hogy dnf show foobar, akkor meg nyekken, hogy mi a fasz az a show, mert azt itt infonak hívják... és persze ugyanez az rpm és a dpkg kapcsolóira :)

Ez egy nagyon régi, bontószökevény gép. A feladata annyi, hogy egy bemutatóteremben, kioskként a cég saját honlapján a vevő tudja böngészni a termékeket, nézni hozzá az árakat. Ehhez nem kell az utolsó cseppig kifacsarni a video processzor képességeit, pláne úgy, hogy a video processzor tranzisztorai is nagyjából fából vannak kifaragva, mert annyira régi. :)

Körülbelül 2 perc alatt bootol be a gép.

A legelső PCI express Nvidia kártya, a Geforce 6600 GT volt emlékeim szerint. Ehhez való legacy Nvidia driver 304.xx ma is letölthető és Gentoo Linux-szon Az X.Org 1.19 még felhúzható. Patchelve 5.x-es kernel alatt is lefordítható a 304.xx driver (vannak GitHub forkok). Szerintem egy tök érdekes project. 

Valószínűleg sokkal gyorsabban megoldható lenne a probléma egy újabb Radeon kártyával, amihez opensource driver van ráadásul, vagy az egész gép cseréje egy intel integrált grafikás PC-re. Sok Intel hülyeség ellenére az intel GPU támogatása kiváló linuxszon. De hát mi lenne úgy a geek élménnyel! :-)

“Az ellenség keze betette a lábát”

( zrubi v | 2025. 08. 06., sze – 01:06 )

Todom, meggyőzni nem tudlak, nem is cél!

De hogy erősítsem a már elhangzottakat:

 régi gépre - főleg amire ti használjátok - nem a Fedora való ;)

Erre a feladatra egy stabil, nem bleeding edge, sőt LTS verzióval rendelkető disztó való! :)

pl: RHEL, ami gyerekkorában egy korábbi Fedora-volt ;)

vagy Ubuntu LTS

 

ja, a régi kernel meg biztosan nem hatossal kezdődik ;) Ezeket (6.x) tulajdonképpen mi teszteljük, annyira bleeding edge :D

 

szerintem.

zrubi.hu

Régi gépre én se javaslom a Fedorát. Nem az új csomagverziók miatt, mert az még okés lenne, hanem a Fedorában van egy tonna corporate bullshit, ami a régi gépek erejét, memóriáját leeszi. Arch, Debian, esetleg Devuan, MX, vagy valami erre alapuló jobb lenne.

“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.”

( NevemTeve | 2025. 08. 07., cs – 12:12 )

TL;DR: Az egyik tudósember [LT] berakta a gányware-t a kernelbe mint kipróbálható opciót, a másik [RedHat] meg default-nak állította be. Kérdés: ki fogja ezt megszívni? Az end-user, természetesen.

( golgota | 2025. 08. 07., cs – 12:41 )

en ocsem keivertem amikor jott az hogy "a rust szar bezzeg a C"...kurva jo volt

Azt értem, hogy megvéd a hülyeségtől, meg azt is, hogy hibás algoritmust bármilyen nyelven lehet írni, csak ezt éppen úgy feleslegesnek tartom, mint a kétfaktoros hitelesítést, meg efféle trendi butaságokat. Azért, mert néhányan a homlokukra tetoválták a jelszavukat, bevezették a második faktort, amivel nekem, aki megjegyeztem azt, kellemetlenséget okoztak.

Bevezetik a Rust-ot, de C-ben is lehet jól programozni, nem törvényszerű a NULL pointer dereference, sem a use after free(), meg a többi. Aki figyelmetlen, kapkod, az majd Rustban fog olyan kódot írni, mint jelenleg a nova-core. Számít bármit is az eredmény szempontjából, hogy mi miatt lett rossz a végeredmény? A Rust sem tud megvédeni attól, hogy hibás algoritmust írjon valaki, a nova-core a legjobb példa erre. C-ben is lehet jó programot írni. Szóval a Rust úszógumi az úszni nem tudóknak, de az úszógumiból is ki lehet csúszni és meg lehet fulladni, tehát nem sok értelme van.

Jobban kellene esnie, ha a Rustban írt driver miatt pusztul meg a kernel ahhoz képest, mintha a C-ben írt driverbe döglene bele? Mert számomra mindkét eset egy elhasaló számítógép.

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

azert azt erthetned, hogy nem a rust hibaja, hogy olyan hardverre akartad raeroltetni a rust-os drivert tartalmazo kernelt, amivel nem kompatibilis :) C-ben, pythonban vagy go-ban irva se lett volna az. :)
ertjuk mi, hogy utalkozni meg fujjolni konnyebb :) merthogy te arra hegyezted ki az egeszet, hogy "a rasztosdrajvermiatt"!!!!1111 :)
a videodriverek igen, fejlodnek, es, ha megfigyeled, regen is volt kompatibilitasi matrixuk. meg most is. ez nem programnyelvfuggo. :)

azert azt erthetned, hogy nem a rust hibaja

Mintha én is ezt írtam volna. Ha a kétfaktoros hitelesítést megtörik, az sem feltétlen a kétfaktoros hitelesítés hibája, de attól még a kétfaktoros hitelesítés felesleges, mint az ötödik kerék.

Amúgy van egy jól működő, C-ben írt driver, nouveau a neve, és még működik is. 

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

Hát nem tudom. Szerintem az, hogy az nvidia uniform driverrel fedi le a kártyáit, az inkább a kivétel, mintsem a szabály. Sokkal jellemzőbb az egy chip - egy driver felállás (bár tény, hogy grafikus ügyekben talán kicsit jellemzőbb).

Meg egyébként nem, nem olyan, ez olyan, hogy elvárok valamit, amit az eredeti se úgy csinál :)

Nem indult a gép. Frissítette a rendszert. Kipróbálta a régebbi és újabb kernellel is. Majd végül kiderült, hogy az új rozsdás drájver üdvöske a ludas. 

Ami - milyen meglepő - megint kinek a köszönhető? Csak nem a Red Hat-nek? Akiknek köszönhetjük a systemd és a wayland nevű rákot is! Akik félkész szarokat erőltetnek a már meglévő és működő megoldások helyett!

Fentebb is leírták már, például bzt, de a Phoronix cikkben is ott van feketén-fehéren, hogy ez egy kezdetleges driver. Akkor mi a frászt keres egy végfelhasználó gépén, ha nem direkt ő telepítette?

Szóval mit és hol erőltetett locsemege?

Azt próbáljuk elmagyarázni hogy egy dzsunka gépen - amelynek a feladata az hogy kiosk-ként működjön - nem egy legújabb dolgokat tartalmazó rolling release-t használunk hanem egy atom stabil LTS rendszert.

A rolling release rendszereket valójában béta-nak kellene nevezni, mert ott bár megkapod a legújabb dolgokat, de cserébe semmilyen garancia nem lesz stabilitásra. 

A hülyeséget próbáljátok megmagyarázni. Le van írva a Phoronix cikkben is, hogy a nova egy "driver skeleton" jelenleg. Teljesen mindegy, hogy rolling release vagy LTS. Itt megint az agyatlan "erőszak" győzött! És ez tetten érhető egyre több helyen. Ti meg ennek tapsikoltok és persze a felhasználó a hülye...

Hagyjuk már a mellébeszélést!

Itt nem a disztrókészítőről van szó! Hanem arról, hogy a gyártó zárt meghajtója és a visszafejtett nyílt forráskúdú lefedte az nvidia kártyák szinte teljes palettáját. Tulajdonképpen szinte bármilyen nVidia kartyát tudtál használni vagy az előbbivel, vagy az utóbbival (azt hagyjuk, hogy egy rakás kaka mindegyik). Erre most kitalálták, hogy írunk egy újat (az mindegy, hogy éppen Rust nyelven), aminek a váza bekerült a kernelfába. Ez még messze nem egy működő dolog, csak egy váz!

Nem úgy kellett volna megjátszani, hogy frissítéskor pl. felhívjuk az idióta felhasználó figyelmét, hogy figyelj már koma, itt ez az új driver, ki akarod próbálni? De ha nincs legalább egy RTX 2000 szériás kártyád, akkor ne akard, mert az az előttiekkel nem megy!

Azért szerintem elég régóta megoldott dolog, hogy adott hardver azonosítóhoz, adott kernelmodult töltünk be, amivel talán megy is az a hardver...

Szerk.: sok részletet nem tudunk meg erről az egy esetről, locsemege nem részletezte. De azért találni hasonló sztorikat, köztül a fedora fórumon is.

Ha megnézed modinfoval, ezt kapod:

alias:          pci:v000010DEd*sv*sd*bc*sc*i*

Azaz minden nvidia cuccra betölti (d*), aztán gondolom kódban eldönti, hogy tudja-e kezelni vagy sem. Valószínű ez a kód nem sikerült túl jól.

 

Nouveau is hasonló:

alias:          pci:v000012D2d*sv*sd*bc03sc*i*
alias:          pci:v000010DEd*sv*sd*bc03sc*i*

Meg a zárt driver is:

alias:          of:N*T*Cnvidia,tegra234-displayC*
alias:          of:N*T*Cnvidia,tegra234-display
alias:          pci:v000010DEd*sv*sd*bc06sc80i00*
alias:          pci:v000010DEd*sv*sd*bc03sc02i00*
alias:          pci:v000010DEd*sv*sd*bc03sc00i00*

 

Itt megint az agyatlan "erőszak" győzött!

Dehogy. A Fedora szépen beforgatja kernel modulként, mert a Fedora erre való: release early, release often tesztrendszer. Nem véletlenül szállítja azonnal a legfrisebb kernelt, a Fedora arra való, hogy a felhasználók teszteljék azt a kernelt, ami majd valamikor a RHEL 11 kernele lesz.

Aki Fedorát használ, az vállalja ezt a kockázatot.
Egy LTS disztribúcióban ilyen nem fordulhat elő, ott az ember meg azt a kockázatot vállalja, hogy nem backportolnak a disztribúció kernelébe olyan dolgokat, ami neki mondjuk kellene.

Semmilyen erőszak nincs itt, mindegyik disztribúciónak megvan a maga célja, a maga stabilitási ígéreteivel, mindenki aszerint választ, hogy neki mi kell. Még netalántán az is lehet, hogy fejlesztés miatt rolling disztribúciót használ, míg szerveren meg hosszú támogatási idejű stabil disztribúciót. Olyan meg nincs, hogy mindenből legyen minden a legfrisebb, de legyen stabil is. A Linux és az open-source világ nem ilyen.

Pontosan arról van szó, hogy a rust nem azt ígérte, hogy bugmentes lesz, hanem hogy a memória managementtel kapcsolatos hibákat nem lehet majd sokkal nehezebb lesz elkövetni. Azt a faszságot, hogy rustban nem lehet szar alogritmust írni, természetesen senki nem gondolja, aki nem legalább félig agyhalott. Plusz jössz azzal, hogy szar a rust miatt, miközben az történt, hogy nem működött a driver egy olyan hardverrel, amiről soha nem is állította, hogy működni fog vele, csak a fedorások faszok voltak. Semmi köze a problémának a rusthoz, ha ezt az új drivert Cben írják, akkor is ugyanígy meg tudott volna dögleni. (Valójában egyáltalán nem lehetetlen, hogy a cben írt nouveau driver szart maga alá így, mert a másik miatt nem az volt a memóriában, mint amit gondolt a szerző ;) )

de C-ben is lehet jól programozni,

Erre meg azt tudnám mondani, hogy lett volna vagy harminc év elkezdeni, de valamiért mégse tetszett ezt tenni az öntudatos C programozó uraknak, mint azt a cve statisztikák mutatják, és amire mindig véletlenül pont nem sikerül valami értelmeset válaszolni ennek a tábornak, uh. valahogy mindig kuss a válasz. Egyébként meg vicces ez a te szádból, mikor pont több olyan topicodra is emlékszem (az utolsó néhány hete volt emlékeim szerint), ahol pontosan triviális memória management hogyan van Cben kérdésekkel nem voltál tisztában, és rendszeresen pörögtök az arcotokon rohadt hosszan. Meg hát emlékszünk még az olyanokra is, hogy a "return 0 is implementációja egy APInak :) ", meg az egyéb mindenféle rohadt okos megoldásra, ami neked tetszik, bár látszott, hogy landmine :) Szerintem neked pont az a bajod a rusttal, hogy tudod, hogy nem hagyna gányolni, hanem a kicsi kezedre baszkodna, amikor figyelmetlen vagy, meg kapkodsz :)

a cben írt nouveau driver szart maga alá így

Persze, nyilván ezért logolta a kernel, hogy a nova-core döglött meg. Még álcázza is magát a nouveau, de csak akkor, ha megdöglik. :)

 amire mindig véletlenül pont nem sikerül valami értelmeset válaszolni ennek a tábornak

Arra milyen választ vársz, hogy valaki elszúrta az algoritmust, vagy az implementációt? Teljesen mindegy, milyen nyelven.

Azzal mi bajod, ha kérdezek? Nem azért van a fórum? Te mindenről mindent is tudsz? Isten hozzád jár korrepetálásra? Én nem tudok mindent, nem is állítottam ezt soha. Különben értékadásban kérdeztem a post increment kiértékelési sorrendjét, ami végül is fajulhat memmória korrupcióvá, ha tömbindexről vagy pointerről van szó.

Meg hát emlékszünk még az olyanokra is, hogy a "return 0 is implementációja egy APInak :) "

Miért? Nem lehet az?

 Szerintem neked pont az a bajod a rusttal, hogy tudod, hogy nem hagyna gányolni, hanem a kicsi kezedre baszkodna, amikor figyelmetlen vagy, meg kapkodsz :)

Ez viszont igaz, mert én hamarabb programoztam assembly-ben, mint C-ben, s noha a legtöbb dolgot jól meg lehet oldani C-ben, már a C is kicsit korlátozott az assembly-hez képest, én meg szeretem a szabadságot. Ugyanis az a programozó felelőssége, ha trükkök százait veti be, ne egy nyelv kitalálója akarja nekem megmondani, mit csinálhatok és mit nem. Tudod, ez is szuverenitási kérdés. Következetes vagyok, annak idején én az EU-ba lépés ellen szavaztam, s azóta is ugyanezen a véleményen vagyok. Ugyanúgy megöli az EU a szabadságot, mint a Rust. 

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

Persze, nyilván ezért logolta a kernel, hogy a nova-core döglött meg. Még álcázza is magát a nouveau, de csak akkor, ha megdöglik. :)

Akkor természetesen nem, csak ez így eddig nem hangzott el a topicban, csak hogy összefosta magát a kernel :)

Arra milyen választ vársz, hogy valaki elszúrta az algoritmust, vagy az implementációt?

A kérdés nem  ez. A kérdés még mindig az, hogy ha a cve statisztikák alapján az összes cve durván egyharmada overflow és memory corruption, ami nagyságrendileg egyelő azzal, hogy a C programozó urak memóriát kezeltek, akkor miért nem kezdtek csak el egyszerűen jól programozni, ahogy szerintetek elég, mert nem kell a tool.

Teljesen mindegy, milyen nyelven.

jepp, pontosan ezzel kezdtem, hogy köze nincs a problémának a rusthoz ;)

Azzal mi bajod, ha kérdezek? Nem azért van a fórum? Te mindenről mindent is tudsz? Isten hozzád jár korrepetálásra? Én nem tudok mindent, nem is állítottam ezt soha. Különben értékadásban kérdeztem a post increment kiértékelési sorrendjét, ami végül is fajulhat memmória korrupcióvá, ha tömbindexről vagy pointerről van szó.

Azzal semmi bajom, természetesen én sem tudok mindent. Azt kéne észrevenni, hogy ha egyébként a Chez jól értő emberek rendszeresen fent akadnak ilyen problémákon, ráadásul hosszasan tudnak ebben a témában összeakadni, és nem dűlőre jutni, nos, az egyáltalán nem azt a világnézetet támasztja alá, hogy nincs értelme a tooling supportnak a problémakörben.

Főleg, hogy azt már tapasztalatból tudjuk, hogy ha a memóriakezelést nem toljuk le az egyszeri programozónak, akkor ezek gyakorlatilag nem léteznek. Példa erre az összes magasabb szintű, memória managelt nyelv, ahol nincsenek ilyenek. Kajánul mondhatnám, hogy persze az is lehet, hogy azokban jobb programozók dolgoznak :D De egyébként erről is tudjuk, hogy nem igaz, mert a másik egyharmada a problémáknak az XSS, ami egy rém hasonló probléma: alapvetően szar az architektúra, ezért oda kell rá figyelni, mit csinálsz. És hát látszik, hogy nem sikerül. (Sőt, másik két prominens doboz, az sql injection meg az input validation is ugyanez tulajdonképpen).

Szóval persze, van a rusttal egy csomó baj, meg megkérdőjelezhető részlet, de az, hogy legyen egy olyan eszköz, amit lehet biztonságos memória managementre használni olyan környezetben is, ahol a magasabb szintű, virtuál gépes, garbage collectoros és egyéb stratégiák nem megfelelőek, az egy teljesen logikus dolog, a tapasztalat jól mutatja, hogy ez a nincs semmi baj, c-ben is csak jól kell programozni, és a hülyék jobb eszközökkel is szart fognak írni, nem segít, nos ez nem tűnik egy védhető álláspontnak.

Miért? Nem lehet az?

De, gányolóföldén az. (Aztán majd valaki, aki használja, véletlen elhiszi, hogy memória címet kapott vissza, ahogy kellett volna, és ... nahát, null pointer dereference :D)

Ez viszont igaz, mert én hamarabb programoztam assembly-ben, mint C-ben, s noha a legtöbb dolgot jól meg lehet oldani C-ben, már a C is kicsit korlátozott az assembly-hez képest, én meg szeretem a szabadságot. Ugyanis az a programozó felelőssége, ha trükkök százait veti be, ne egy nyelv kitalálója akarja nekem megmondani, mit csinálhatok és mit nem. Tudod, ez is szuverenitási kérdés. Következetes vagyok, annak idején én az EU-ba lépés ellen szavaztam, s azóta is ugyanezen a véleményen vagyok. Ugyanúgy megöli az EU a szabadságot, mint a Rust. 

Én értem, csak az egyéni preferenciáid kevésbé érdekesek madártávlatban. Az, hogy te nem szereted, az nem jelenti azt, hogy nincs értelme.

(Egyébként meg nem nagyon mennék én bele ebbe az eu kérdésbe, de ez egyáltalán nem ugyanaz a szuverenitási kérdés. ) 

Erre a hozzászólásra válaszolok, de mindkettőtöknek (és igazából mindenkinek) szól.

A rust szerintem jó dolog. Akinek kell, fogja a kezét, akinek nem, arra is rászól, ha esetleg figyelmetlen. A rustban írt programok sem rosszabbak, mint bármelyik más nyelven írtak.

A probléma az, hogy egyeseknek annyira beakadt, hogy elkezdenek működő dolgokat újraírni, csak mert rust. Aztán csodálkoznak, hogy a szemük fénye összefossa magát. Ami persze elkerülhetetlen, hiszen az évek óta csiszolt, bugfixelt c-ben írt eredeti már elérte a szobatiszta kort. Ahhoz képest az ő implementációjuk sehol sem tart.

Szóval tudom, hogy egyszerűbb a rustot szidni, de a nyelv nem tehet arról, hogy néhányan abuzálják. Ez most újdonság, majd lecseng.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Én tudom, hogy van az az örökbecsű mondás, hogy ne javítsuk meg ami nem romlott el, de én remélem, hogy ennél komplexebb megfontolások alapján nyúlnak emberek hozzá működő dolgokhoz és teszik őket át más implementációs nyelvre. A szülési fájdalmak is egy tényező az egyenletben de - mint látszik - nem a legfontosabb. :)

A portolás teljesen más műfaj, annak lehet is értelme. Rust esetén én úgy képzelem el, hogy beemelik a komplett c programot, ami teljesen unsafe, aztán szépen egyesével 'rustosítják' a függvényeket, amíg az egész cucc biztonságos nem lesz.

Ezzel szemben úgy látom, hogy a 0-ról újraírás sokkal népszerűbb.

Debian - The "What?!" starts not!
http://nyizsa.blogspot.com

Ezzel szemben úgy látom, hogy a 0-ról újraírás sokkal népszerűbb.

Most az itteni panaszom ellen beszélek, de mégis meg tudom érteni ezt az álláspontot, mivel programozom is, noha nem vagyok software-es. Firmware-eket írok.

Amikor egy alrendszert elkezd írni az ember, kitalálja, megálmodja az aktuális igények alapján. Aztán az igények nőnek, jó lenne, ha ezt meg azt még tudná ez az alrendszer, csak hát nem úgy lett tervezve, ezért valami nyakatekert gányolással bele lehet gyúrni, kivételes eseteket kezelünk, jé, ennek a byte-nak csak az alsó 6 bitjét használjuk, akkor a felső kettőben eldugunk még két flag-et, amellyel jelezzük, hogy ez az a speciális eset, amivel már kinőttük az adott alrendszer eredeti képességeit.

Amikor meg átírásra kerül egy új nyelvre, az egyúttal egy óriási, kihagyhatatlan lehetőség arra, hogy ez az alrendszer eleve úgy legyen tervezve, hogy szépen, elegánsan kezelve legyenek az időközben felmerült új igények, és ne valamiféle maszatolás legyen, mint volt eddig, hanem kulturált megoldás.

Én is csináltam olyat, hogy egy műszer parancsértelmezőjét újraírtam, egy kommunikációs rétegét szintén, amikor már kinőtte a képességeit, és nem mellesleg bugos is volt. :)
 

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

Az újraírásnak is lehet értelme.

  • Az újraírás rossz, mert egy csomó, az évek során felgyűlt, hasznos apróbaszt kibasz az ablakon.
  • Az újraírás jó, mert egy csomó, az évek során felgyűlt, haszontalan apróbaszt kibasz az ablakon.
  • Az újraírás rossz, mert nem pontosan ugyanazt csinálja / használja.
  • Az újraírás jó, mert tudja használni az újabb / jobb lehetőségeket.
  • Az újraírás rossz, mert megváltozik az architektúra, ezért bizonyos dolgok szarabbak lesznek, amik korábban  jobbak voltak.
  • Az újraírás jó, mert meg lehet változtatni az architektúrát, ezért bizonyos dolgok, amik régebben szarok voltak, és nem lehetett őket értelmesen megoldani, most jobban kezelhetőek.

Mindennek van pro és kontra.

Általában a nyílt forráskódú projekteknél nincs hosszú tábú, átgondolt tervezés. Azért nincs, mert releasy early, release often módon, majd kialakul a dolog a folyamatos bétatesztek során.

Eric S. Raymond művében jól le van írva ez a bazár típusú működésmód, és ez a követendő.

ez tuti :D

mondjuk nekem nincs bajkom magaval a nyelvvel, de az evangelistai kb. mint a veganok. Eroszakos funademntalistak akik eppen csak nem gyilkolnak mindekit halomra, mert "bancsak" a hituket. Mar varom mikor lesznek ongyilkos vegan es rust evangelikusok :D

Mondjuk van egy ket ilyen C hivo csavo itt is   :D

Nem alkalmazható itt, nem arról van szó, hogy eldobták volna a nouveau drivert. Hanem készítenek egy másik Nvidia drivert, a meglévő mellé. Nem a helyére. Az open-source világban eléggé sok példa van arra, hogy egy adott feladatra sokféle implementáció van. Elég csak arra gondolni, hogy valamit azért implementálnak újra BSD vonalon, mert nem jó a licence, emiatt kell készíteni egy másik implementációt. Vagy elég arra gondolni, hogy van sok desktop környezet. Vagy éppen e-mail kliens. Meg sok minden más is megvan ezerféle módon implementálva.

ez mar kb. a harmadik fele nv driver lesz, csak most - fixme, en igy olvastam valahol - maga az nvidia csinal egy openszo'sz drivert linuxra, mert ha labdazni akar a linux datacenterekben hosszu tavon, akkor elvaras, hogy bele lehessen latni abba, ami a szoftverben tortenik. kvazi felzarkozaskepp intel es amd melle. :)