Nem kizárt, hogy dobja az Ubuntu a SPARC és Itanium architektúrák támogatását

Ubuntu

Scott James Remnant tegnapi levelében elmondta, hogy az Ubuntu SPARC portjának használata és karbantartottsága egyaránt csökken. Ebből kifolyólag a port minősége már nem üti meg azt a minimális szintet, amelyet a fejlesztők az Ubuntu portoktól elvárnak. Az Ubuntu Developer Summit-on folyt beszélgetések után egy olyan, az Ubuntu Technical Board által ratifikált döntés született, melynek értelmében az Ubuntu 10.10 "feature freeze" mérföldkövével egy időben leállítják az Ubuntu SPARC portját.

Ha az Ubuntu felhasználók és/vagy fejlesztők azt szeretnék, hogy a port életben maradjon, akkor össze kell fogniuk és a fent megjelölt határidőig olyan állapotba kell hozniuk, hogy az megüsse a portoktól elvárt minimális szintet. Hogy ez sikerüljön, ahhoz jelentős munkát kell végezni mind a kernelen, mind a toolchain-en.

Remnant elmondta, hogy az Ubuntu IA64 (Itanium) portja jobb állapotban van, mint a SPARC port, de nincsen aktívan karbantartva. Az Ubuntu elismeri, hogy lennének előnyei a port megtartásának és azt is, hogy a kernel és a toolchain jobb állapotban van mint a SPARC-é, de a technikai vezetés attól tart, hogy aktív karbantartás nélkül a minőség gyors ütemben romlik majd. Éppen ezért ha nem lép elő egy karbantartásra jelentkező csapat, az Ubuntu ezt a portot is leállítja.

A részletek itt.

( Csigaa | 2010. 06. 08., k – 18:17 )

Quality is always important to Ubuntu

Bocs, de ezen könnyesre röhögtem magam.

Nem azt mondom, hogy nincs, tisztaban vagyok azzal, hogy egy elkurt driver vagy egy hibas hardver igen gyorsan meg tudja fektetni a Wint...

... meg az osszes tobbi OS-t is. OSX-t is sikerult mar kifektetnem azzal, hogy radugtam a Mini-re a fejhallgatom, egyszer es valoszinuleg valami egyeb parajelenseggel osszefuggoen. Egyszer volt, tulleptem rajta, azota is megy vigan.

Viszont lenyegesen sokat valtozott az elmult 12 evben a helyzet Windows teren is.

----------------
Lvl86 Troll

Egyedül arra utaltam h itt sokan (vagy csak néhányan de hangosan) látványosan szenvednek az ubuntu vélt vagy valós minőségi problémái miatt, közben vélt vagy valós problémák más rendszerrel is vannak bőven.

Általában ezek a fanyalgások visszavezethetők preferencia, ellenérzés, vagy programellátottság alapokra, magyarán kurvaszubjektív, de tény h ennyi pénzért (nulla) lehetne sokkaljobbabb is :)

A valós probléma az, hogy ha nem frissítek, elavul gyorsan (újabb programokat nem tudok telepíteni a régi libek miatt, vagy fordíthatok kézzel minden függőséget), ha meg frissítek, a hw fele "nem támogatottá" válik. Kiadásonként változik, melyik fele.

Valami itt nagyon el van b.szva. Minden OS-sel van probléma, de ez már minden határon túlmegy.

Tény h a bubi verzióváltásait eléggé aktívan követik a fejlesztők, és pl a hardy-t már eléggé leszarják. A kernel és xorg verzióugrásaival meg pár driver-fejlesztő nem tud/akar lépést tartani. Emiatt pl. jaunty-tól ugrott a régebbi ati kártyák "gyári" "támogatása". Az ilyen jellegű problémák viszont szerintem könnyen előjöhetnek pár más gyorsabban mozgó disztribúciónál is.

Most hogy én vagyok szerencsés, vagy te balszerencsés, nemtom, de olyan végzetes problémám nekem még nem volt.

Ugyanúgy véleményt mondok ahogy te; általában technikai érvekkel alátámasztva. Nem kell hogy tetsszen...

És olyan OS-ben nincs semmiféle minőség szem előtt tartva, amiben kiadásról-kiadásra lehet totózni, melyik hw és funkció nem fog működni ami az előzőben jól működött -- ezt ismerve elég furcsa a minőséget mint érvet látni a SPARC és IA64 kidobásában.
Csak ennyit akartam.

Az a szomorú, hogy nem tudok.

Ettől viszont ez még abszolút nulla minőségellenőrzést jelent; az nem menti fel az Ubuntut hogy a többi hasonló is ilyen hanyagul kezeli a kiadásokat.
Azt meg ne mondja nekem senki, hogyha egyszer valami működött, törvényszerű hogy random elb.sszák a következő verzióban...

Ez nem teljesen az Ubuntu hibája. Ahogy látom, a Canonical nagyon jó irányba próbálja vinni a desktop Linuxot, a gond a megvalósítás amatőrségén van. Egyszerűen nincs elég erőforrásuk, emberek szabadidejére pedig nem lehet egy ekkora projektet alapozni. Emiatt van ennyi bug. Be van jelentve, hozzá van kapcsolva a Debian-os hibajelentés, ahhoz meg az upstream bugtrackerben a hiba. Nincsen elég képzett fejlesztőjük (képzetlenek meg ne kezdjenek el bugfixelni, lásd debian vs openssl).

Ez sajnos igaz a többi disztróra is. Nem feltétlen a disztribúciókra kellene ráhárítani az összes sarat. Ha a szoftver rossz, de muszáj szállítani (kernel nélkül nem mehet az OS, viszont az új kernel meg támogatja azokat a hardvereket, amikkel már fél éve adnak el gépeket), akkor nem nagyon van mit tenni.

Én is belefutottam egy kellemes bugba de ezért nem az Ubuntut hibáztatom, hanem a kernelfejlesztőket (más disztrókban is előfordul).

Ha az a tendencia hogy a friss xyz komponens (kernel, akármi) mindig egy foshalom, és bizony ezt látjuk, akkor a disztribútor szállíthatna régebbi, működőt is -- egy idő után a lusta fejlsztők rátérnének a használható kiadások készítésére, ha a félkész szart senki se használná.

Amúgy kb minden főkomponensre (kernel, devkit, stb) ráférne egy stable/devel ág szétválasztás, mert ami most "release" címen fut, arra sokszor a beta státuszt se lenne pofám kitenni.

szerk: persze felfoghatjuk úgy is, hogy az ingyenes disztrok amik orrbaszájba betolják ezeket a félkész "release"-ket, a világméretű alpha/beta teszt, amiből a RH és a Novell vastagon profitál.
Végülis az időddel és a hatékonyságod csökkenésével fizetsz a rendszerért... akár sokkal nagyobb árat, mintha megvennéd a garantáltan működő enterprise RH-t (a Windows témát most nem piszkálnám mert nagyon elvinné a szálat más irányba).

Maradjunk a kernelnél az egyszerűség kedvéért. Tfh te vagy a disztribútor. Jön az új release, kernel verzió frissítést kell meglépned, mert az új kernellel olyan hardvereket támogatsz, amik friss gépeken vannak. A laptop tulajdonosok többsége javuló akksi időt jelent. Az AMD graf kártyák jobban működnek (meg képzeld még ezt el 1-2 hardverre). Az új verzióval azonban bizonyos régebbi hardvert használók panaszkodnak, hogy furcsa bugok jönnek ki, amik nehezen reprodukálhatóak ezért nem nagyon tudsz (mint csomagkarbantartó) épkézláb reportot írni az upstream-nek. Ilyen bugok voltak az előző kernelben is, egy részük megjavult.

A release közeledik, mit tennél? Hagyod a régi kernelt, és azért fognak téged lehúzni, mert nem támogatod az új hardvereket. Ha az újat rakod, akkor azért fogsz kapni, mert bizonyos userek idegesítő bugokat fognak találni. Kivárhatod még a következő kernelt (2-3 hónap), de semmi sem garantálja, hogy az jó lesz. Az újból a régibe backportolni drivereket nincs erőforrásod, és az ilyen munka normál esetben nem a te dolgod (az, hogy a RH szétpatcheli a kernelt nagyon jól jellemzi azt, hogy mennyire nem megfelelő a kernel minősége; ennek nem így kellene lennie).

Jó, de érted, ebből a user csak azt látja hogy ami eddig ment az most már nem... ami nem állapot. Rúgja seggbe a disztribútor a kernelfejlesztőket, de ne én lássam már kárát annak hogy valami f.szfej átírja a fél drivert felelőtlenül, hogy 1 új hw menjen, közben 5 régen működő már nem fog, és legalább 2 stabil kiadáson(!!) keresztül nem is javítják (pl. uvcvideo).

Az ilyen fejlesztőket jobb helyen páros lábbal rúgják ki. A linux esetén meg ők a gárda gerince?
szerk: ha meg nem, a gerinc igazán átnézhetné, mit basz el az anonim gmailes címről küldött patch mielőtt beteszi a stabilnak csúfolt kiadásba.

Értem persze. Én, mint végfelhasználó sem örülök annak, hogy naponta 2-3x újra kell indítanom a gépet, mert a wifi megadja magát.

A gond az, hogy a disztribúció pl a kernellel nem sok mindent tud kezdeni. Bármelyik másik nyílt forrású kernellel csak rosszabbul járnának hw támogatás ügyében. Hasonlóan létfontosságú, de elméletileg jobban helyettesíthető projekttől is akart már nagy disztribúció szabadulni (Debian vs glibc), de az sem sikerült. Pedig Ulrich Drepper sokkal rosszabb, mint az összes kernelfejlesztő együtt.

Persze lehet nyílt levelekkel végtelen flamewar-okat indítani, de ennek kb annyi értelme van, mint mélyvallásos emberekkel vitatkozni (if it compiles, it is good, if it boots it is perfect).

Ha nem tartozol azon szerencsések közé, akiket elkerülnek ezek a bugok (kolléga évek óta Gentoo-t nyúz, egy darab driver bugja nem volt kiadott vanilla kernellel; nekem volt olyan kernelverzió, amivel a régi laptopom be se bootolt), akkor érdemes lehet megfontolni a váltást desktopon egy másik OS-re.

Igazaboll a kernelfejlesztok kozul ki kene venni a hobbikoderek felet, es helyettuk fizetett fejlesztoket rakni be. Valamint kene egy normalis projektvezetes, mert ami most van, az lathatoan... elegtelen.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A hobbikóderekkel semmi gond. Azokkal van a gond, akik elégtelen ellenőrzés után beengedik a kernelbe.

Projektvezetés... ahhoz olyan embert kell a projekt élére állítani, akinek mind szakmailag, mind emberileg tekintélye van. Az utóbbit nem úgy értem, hogy leugat a halálba, ha ellentmondasz neki, hanem úgy, hogy karizmatikus vezető is egyben. Ilyen ember kevés van :(

"Egy kutyát is dughatsz a gépbe, de nem az oprendszert kell okolni, hogy nem ismeri fel a kutyát, és nem hajtja meg jól."
Ooo... a hardverelemeket nem az oprendszer mukodteti? Ha nem az oprendszert kell okolni, akkor mit? A hardvert nyilvan nem, esetleg a gyartot, hogy miert nem tud kompatibilis lenni az elozo modellel a hw, de ez a szal messzire vezetne, szoval inkabb hagyjuk.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A driver "gyártót", mert az azonos hw modellel nem kompatbilis az új driver.
Az meg hogy ki fejleszti Linuxhoz a drivereket, és hogy miért, szintén messzire vezetne.

Az aktuális helyzetből látjuk, hogy a mostani modell teljesen tarthatatlan, valahol v. több helyen is gyökeres változtatások kellenének.

Linux eseteben nincs, vagy nagyon keves az elszeparalt hw driver (ATi, nVidia), szoval a driver az oprendszer resze.

Nem tarthatatlan annyira ez a model sztem, csak erto vezetes kene a dologhoz. Nem veletlen, hogy a projektvezeto egy kulon szakma.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Csak azért kérdeztem, mert nekem az jött le, hogy te is könnyesre röhögted magad ezen: Quality is always important to Ubuntu.
Azt sugallva ezzel, hogy szerinted az Ubuntunak nem mindig fontos a minőség!
Honnan tudod, mondta valaki? Saját tapasztalat nem nagyon lehet, hiszen négy éve nem láttál Linuxot!

>>Mekkora feszültséggel működik Magyarországon az elektromos hálózat?<< Elmés!

>>Tell your parents not to ruin the world that you will live in.<<

( molnarsg | 2010. 06. 08., k – 22:58 )

Pont amikor vegre beszereztem egy SparcCenter 2000-est.
Hogy fogok igy Ubuntut tenni ra?

( nanto | 2010. 06. 09., sze – 00:06 )

hat nevetsges is, hogy 2010-ben ilyen ertelmetlen egzotikus architekturak tamogatottabbak, mint az arm (nem sokaig). Azon agyalok, van-e ertelme x86 x64 arm, es esetleg ppc-n kivul barmire is fejleszteni
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

off: KDE 4.5 Beta 1 hasznalhato mar? Csak mert azzal kapcsolatos liveCD-t akarom jun 22.-en Londonba kivinni es azzal kell ellennem egy darabig (bar en szerintem nem a Masturbating Monkeyt viszem)
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Reszben egyetertek. Legalabbis nekem hiaba van Ubuntu Server, nekem az Desktop distro marad, Desktop az meg tobbnyire x86, x64, ppc, es arm. Debian az mar pl mas teszta, szervereknel igenis kellenek az egzotikus (es abban az esetben nem ertelmetlen) architekturak
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Viszont, mivel az Ubuntu nem szerverre valo (az, hogy egyesek szerver rendszernek hasznaljak, attol meg nem lesz rendes szerver rendszer, ahhoz sokkal nagyobb stabilitas kellene), igy maga a problema nem letezik. Debianban ugy tudom meg van ppc meg mas architektura is.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.