Yleistä keskustelua Launchpad bugiraportoinnista

[timbba]

Tuota en kyllä oikein usko, koska suspend-ongelmat ovat erittäin laaja vyyhti. Siinä ei myöskään välttämättä pidempi julkaisusykli auta, jos ongelma on valitulla Linux-ytimellä kyseisen laitteen tuessa (tai tarkemmin ottaen väärin toimivan laitteen kiertokonstin sisällytyksessä). Toki tuonne acpi-support-paketin puolelle voi tällöin pidempään kerätä konekohtaisia kiertokonstiluetteloita, eli jonkin verran tilanne varmasti parantuisi. Yhtään ei kyllä auta se, että moni käyttää suljettuja NVIDIA:n ja AMD:n ajureita, joilla ongelmia on paljon eikä ko. ongelmia voi korjata.

Saattaa olla, mutta saattaa myös olla että yksi korjaus korjaisi kaikki bugit. Koskaan ei voi olla varma..  Noissa bugeissa vaa nimittäin on niin laajasti erilaista rautaa, eri kerneleitä, eri valmistajien näyttiksiä, yms.. Sen takia uskon että vika ei ole jossain tietyssä kiertokonsteissa.

Ja omalla raudalla Debian vaa jyllää suspendia mainiosti, kun taas Ubuntussa ei ole toiminut kuin 7.10 versiossa (eikä siinäkään heittämällä vaa muistaakseni piti asentaa uswsusp).

[lompolo]

Mutta jossain vaiheessa julkaisusykliä voisi pohtia uusiksi, miten olisi esim. 8kk julkaisutahti niin, että olisi esim. 8.04 LTS, 8.12, 9.08, 10.04 LTS? Saisi pidettyä kuitenkin 2 vuoden LTS-tahdin.

Toinen vaihtoehto on että LTS:ää seuraavan julkaisun voisi melkein vaikka jättää välistä... Ubuntu 8.10 on oikeastaan kyllä aika hyvä, mutta kyllä yleismielikuva on että 6.10 ja 8.10 ovat molemmat saaneet muita julkaisuja vähemmän huomiota, ja bugeja riittää, kun LTS-julkaisun .1-version kehittäminen on jatkunut kesä-heinäkuulle asti.

Kumpikin vaihtoehto on ongelmallinen. 6kk sykli sopii hyvin yhteen Gnomen julkaisujen kanssa. Yhden version jättäminen välistä taas rikkoisi ikävästi julkaisujen tasaisuuden. Käyttäjä voi tietysti jättää LTS versiota (8.04) seuraavan version (8.10) päivittämättä ja vaikka asentaa sitä seuraavan (9.04) uutena asennuksena.

[lompolo]

Ja omalla raudalla Debian vaa jyllää suspendia mainiosti, kun taas Ubuntussa ei ole toiminut kuin 7.10 versiossa (eikä siinäkään heittämällä vaa muistaakseni piti asentaa uswsusp).

Tuo olisi hyvä tieto lisättäväksi bugiraporttiin. En uskalla suositella Debianin kernelin kokeilua Ubuntussa, kun en tiedä rikkooko se jotain. Kernelin kääntäminen voisi olla parempi ratkaisu.

Debian on myös laadukas jakelu 

[Timo Jyrinki]

Saattaa olla, mutta saattaa myös olla että yksi korjaus korjaisi kaikki bugit. Koskaan ei voi olla varma..  Noissa bugeissa vaa nimittäin on niin laajasti erilaista rautaa, eri kerneleitä, eri valmistajien näyttiksiä, yms.. Sen takia uskon että vika ei ole jossain tietyssä kiertokonsteissa.

Kärjistetysti koko ACPI-virranhallintastandardi on yhtä kuin kiertokonstien suuri kasa, ja suunnittelultaan susi. Jos noin suuren laitteistomäärän ongelmiin olisi olemassa yksi selkeä ratkaisu, se olisi jo toteutettu. Jokainen noista bugeista voi todellisuudessa olla bugi aivan eri paikassa. Suspend ei ole mikään yksi "teepä suspend", vaan vaatii koko laitteiston ja ajureiden saumattoman yhteistyön tilan tallentamisessa ja komponenttien siirtämisessä toiseen tilaan oikeassa järjestyksessä, sekä jälleen laitteiston käynnistäminen oikealla tavalla. Vika yhdessäkin kohdassa rikkoo ns. kaiken, niitä kohtia on tosiaan monta ja laitekokoonpanomahdollisuuksia tuhansia.

Useimmat suspend-bugiraportit Launchpadissa eivät kerro itse ongelmasta paljon, koska suspend-ongelmien jäljittäminen on usein hankalaa Linux-ytimen kehittäjillekin - miten saat tietoa irti koneesta, jonka toiminta on jo suurimmalta osin keskeytetty ja jokin on vieläpä mennyt vikaan? Siinä ei auta vaikka osaa kertoa laitekomponentit, dmesg:n ynnä muuta perustietoa.

Noissa linkatuissa bugiraporteissakin useissa esiintyy nvidian suljettu näytönohjainajuri, jonka edessä käytännössä sekä Ubuntun että Linux-ytimen kehittäjät nostavat kädet pystyyn. Käyttäjän kannalta ongelma on toki Ubuntussa tällöinkin, mutta teknisesti asialle ei voi tehdä mitään (paitsi tietysti nvidia itse). Osassa bugiraporteissa kerrotaan vain ongelman oireet ("musta ruutu, kursori vilkkuu"), jotka taas eivät auta ongelman ratkaisussa mitenkään. Ja tosiaan ikävä kyllä ne hyvätkin bugiraportit tuolla, jos eivät liity selkeästi johonkin Ubuntun tekemään muutokseen, ovat oikeastaan väärässä paikassa koska oikea sijainti olisi http://bugzilla.kernel.org/. Mutta yksi Launchpadin tarkoitusperistä onkin toimia bugiraporttien sulatusuunina, josta toivottavasti valuu se todella konkreettinen, tekninen tieto eteenpäin.

[timbba]

Edelleen Timo pidät hienosti Ubuntun puolia.. 

Se mikä Ubuntussa ei toimi, niin toimii kuitenkin Debianissa. Jotain siis Ubuntussa on tehty eri lailla ja siinä luultavimmin syy. Tiedän kyllä että acpi on surkuhupaisasti suunniteltu viritelmä.. Mutta toisaalta; miksi Debianissa suspend toimii (Etch, Lenny, etc..), mutta Ubuntussa ei toimi (Gutsy, Hardy, Intrepid, etc..)? Täysin sama laitteisto.. Jotain siis Ubuntussa on viritelty ja niiden raportointi ei kuulu bugzilla.kernel.org:iin.

Senkin voin kertoa, että käytän nvidian suljettua ajuria.. mutta edelleen, kaikilla nvidian eri ajuriversioilla Debian vaa pelittää (1.0-96xx, 100.14.xx, 169.xx, 17x.xx, 18x.xx), mutta Ubu ei.. siis aatellen suspendia.

[Timo Jyrinki]

Edelleen Timo pidät hienosti Ubuntun puolia.. 

Yritän vain pitää kokonaiskuvan mukana, ongelmia kun on monentyyppisiä eikä tosiaan vain yhdestä asiasta johtuvia. Ja sitten vielä se että Launchpad-bugitulva on niin suuri, että ei kellään (paitsi koko yhteisöllä) ole resursseilla yrittää käydä niitä läpi.

Se mikä Ubuntussa ei toimi, niin toimii kuitenkin Debianissa. Jotain siis Ubuntussa on tehty eri lailla ja siinä luultavimmin syy. Tiedän kyllä että acpi on surkuhupaisasti suunniteltu viritelmä.. Mutta toisaalta; miksi Debianissa suspend toimii (Etch, Lenny, etc..), mutta Ubuntussa ei toimi (Gutsy, Hardy, Intrepid, etc..)? Täysin sama laitteisto.. Jotain siis Ubuntussa on viritelty ja niiden raportointi ei kuulu bugzilla.kernel.org:iin.

Tuossa on aika hyvä lähtökohta kyllä tehdä tarkempaa tutkimusta, ja asia jonka bugiraportissakin mainitsemalla saattaa tehdä bugista monia muita kiinnostavamman (koska tosiaan ei välttämättä ole kernel-bugi suoraan). Onko yhdessäkään Debianissa sama kernelin pääversio (2.6.24 esim.) kuin kokeilemassasi Ubuntussa? Esim. etchiin saa sen "etch and a half" -kernelin joka on 2.6.24. Ei kuitenkaan voi jättää huomioimatta, että ongelma esiintyisi esim. 2.6.24:ssa (hardy), ei 2.6.26:ssa (lenny), ja taas 2.6.27/2.6.28:ssa (intrepid/jaunty). Näitä selvittäessä ongelman haarukointi on aina hyväksi. Ja tosiaan tuo Debian-pointti kannattaa mainita siellä bugin kuvauksessa, mutta mielellään vasta sitten kun on kokeiltu Debian/Ubuntua joissa sama kernel (esim. se Debian etch-and-a-half 2.6.24:lla ja Ubuntu 8.04 LTS). Siitä voitaisiin päästä kernelin ulkopuolelle, mikä on sentään edistystä.

Vielä se kyllä pitää mainita, että kannattaa kokeilla nvidia-ajurin poistamista ja nv-ajurin käyttöä suspend-testailuihin. Kuten jo todettu, se mahdollisuus että lopulta ongelma jollain tavalla liittyisi suljettuun ajuriin laskee jo bugiraportin kiinnostavuutta. Ja tästä tulikin mieleen, että Debian lennyssäkään _ei_ ole 1.5.0-Xserveriä kuten Ubuntu 8.10:ssa, vaan 1.4.3. Ja melko tunnettu fakta on, että NVIDIAn ajurit hajoilevat jatkuvasti jokaisen uuden X:n ilmestyessä, ja usein eritoten suspend-ongelmia esiintyy. Ja joka tapauksessa tuo onko ongelmaa nv-ajuria käyttämällä (nvidia kokonaan poistettuna) on jälleen yksi lisätieto bugiraporttiin.

Kohtapuoliin Debian 5.0 julkaistaan, ja unstableen mennee 2.6.28. Tällöin olisi hyvä mahdollisuus vertailla Debian sidiä (tai lennyä sidin kernelillä) ja Ubuntun jauntyä rinnakkain. Tuossa on sekin mielenkiintoinen juttu, että Ubuntu kun perustuu Debianiin, niin se on melko yhdenmukainen muiltakin osin (acpi-support-paketti jne.) Debianin kanssa. Mutta tosiaan tuo X-server menee tällä hetkellä eri versionumeroissa, paitsi jos vertailee Ubuntu 8.04 & Debian 5.0.

Itse viestiketjun aiheeseen liittyen esimerkkisi (suspend-ongelma) näyttää bugikorjauksen ja -raportoinnin hankalimmat puolet - noita on niin vaikea debugata että tarvitsisi olla itse lähes kernel-kehittäjä osatakseen jäljittää virhettä riittävän pitkälle, jotta tietojen avulla ongelma voitaisiin korjata.

Muistaakseni nyt 9.04:ssa kävi käsky Canonicalilta, että käyvät läpi jokaisen työntekijän kaikki koneet, etsivät onko suspend-ongelmia ja korjaavat. Yksi tapa lähestyä ongelmaa Tosin esim. nvidiallisia koneita ei varmaan lasketa mukaan. Toki myös esim. Dell varmistelee omia koneitaan ja muutenkin yhteisön lisäksi myös yritysapureita on. Nyt julkaisuun keskityttäessä on kuitenkin jo valittu kernel (2.6.28), niin ei voida enää odottaa maagisesti paremmin toimivaa kerneliä Torvaldsin suunnalta, vaan pitää hioa tätä ympärillä olevaa. Ubuntu 8.10:n kanssa muuten otettiin harppaus 2.6.27:een suht viime metreillä, varmaan sekin on vaikuttanut suspendin hajoiluun.

Senkin voin kertoa, että käytän nvidian suljettua ajuria.. mutta edelleen, kaikilla nvidian eri ajuriversioilla Debian vaa pelittää (1.0-96xx, 100.14.xx, 169.xx, 17x.xx, 18x.xx), mutta Ubu ei.. siis aatellen suspendia.

Ok, tuokin on hyvä tieto.

[timbba]

Ja tosiaan tuo Debian-pointti kannattaa mainita siellä bugin kuvauksessa, mutta mielellään vasta sitten kun on kokeiltu Debian/Ubuntua joissa sama kernel (esim. se Debian etch-and-a-half 2.6.24:lla ja Ubuntu 8.04 LTS).

Debianissa on kokeiltu 2.6.24 toimivasti, Ubuntussa ei toimivasti.

Vielä se kyllä pitää mainita, että kannattaa kokeilla nvidia-ajurin poistamista ja nv-ajurin käyttöä suspend-testailuihin.

Ubuntussa on kokeiltu ilman binääriajureitakin.. ja lopputulos ei vaa toimi.

Edited: Sen lisään tähän viel, että mulla on siis usko mennyt tuohon Launchpadiin... Ei sinne jaksa noitakaa infoja  alkaa lisäilemään, sillä se on turhaa. Vastaukset bugeihin tulee kuukausia myöhässä, jolloin uusi versio on jo ulkona. Tällöinkin käsketään yleisemmin vain testailemaan sillä sitten.

[Timo Jyrinki]

Edited: Sen lisään tähän viel, että mulla on siis usko mennyt tuohon Launchpadiin... Ei sinne jaksa noitakaa infoja  alkaa lisäilemään, sillä se on turhaa. Vastaukset bugeihin tulee kuukausia myöhässä, jolloin uusi versio on jo ulkona. Tällöinkin käsketään yleisemmin vain testailemaan sillä sitten.

Ok no sitten asian pidempi tutkiminen ei ole kovin hyödyllistä.

Edelleen ehkä hieman häiritsee tuo asenne siitä että "vastaukset bugeihin tulee myöhässä" - kenen niitä vastauksia pitäisi tehtailla, ja mitä niiden vastauksien pitäisi sisältää? Sekin joka bugiraporttiisi vastasi jauntyn kokeilemisesta näyttäisi olevan satoja bugeja vapaa-ajallaan käsittelevä henkilö. Kuinka paljon lisää aikaa juuri hänen pitäisi lisää käyttää tutkiakseen sinun ongelmaa? Ja mitä kukaan voi tehdä jos hänellä ei ole samaa HP:n konetta kuin sinulla? Annetuissa tiedoissa syötelaitteista voi olla sopivalle asiantuntijalle tiedonjyvänen mahdollisesta ongelman aiheuttajasta, mutta voi olla myös että nykyisillä bugiraportissa olevilla tiedoilla ei kukaan ongelmaa voi vielä jäljittää (esim. toinen kone samoilla tiedoilla toimii moitteetta). Jälkimmäisessä tapauksessa kukaan ei edes voi vastata bugiraporttiin muuta kuin että "kokeilepa jauntyllä", ellei sitten "kokeile synaptics-ajurin git-versiota debug-outputilla, ja vertaa toisaalle".

Jos ainoa ongelma on tuo näppäimistön toimimattomuus, eli kannettavaan sisältyvät syötelaitteet eivät toimi, luulisin että ongelma ei ole kernelissä vaan esim. X:ssä. Ja tällainen ongelma on tosiaan täysin eri suspend-ongelma kuin ne yleiset, eli että laite ei herää suspendista lainkaan.

Jos tämän tutkimisessa haluaisi edetä, mitä nyt ei ilmeisesti haluttu, olisi hyvä etsiä esim. tuon synapticsia käyttävän laitteen vendor/product-tiedoilla mahdollisia kohtalotovereita, merkitä jokin bugi toisen duplikaatiksi jos vastaava oire (näppäimistö/touchpad ei toimi suspendin jälkeen) löytyy ja jatkaa sitä kautta. Mitä paremmin jokin tietty ongelma saadaan eristettyä ja kerättyä samat bugit toistensa duplikaateiksi, sitä paremmin ongelma alkaa hahmottua ja ylipäänsä erottua Launchpadin tuhansien "bugiraporttien" kohinasta. Myös joku toinen voi jossain vaiheessa lähteä tätä tutkimustyötä tekemään, esim. tämä joka jauntyn kokeilemista ehdotti, mutta kyse on siitä löytyykö ihmisiä, esim. näiltä foorumeilta, jotka tuota työtä voisivat tehdä. Niillä kehittäjillä, jotka osaisivat mahdollisesti tällaisen ongelman korjata, ei ole aikaa käydä henkilökohtaista keskustelua jokaisen tuhansista bugiraportoijista kanssa vain sen takia, että ongelman jäljittämiseen tarvittavia tietoja ole.

Suomen / tämän foorumin tasolla omia bugiselvittelyitä / kiinnostavia bugeja voi listata esim. Ubuntun kehittäminen -sivulle, esim. jos haluaa ottaa pieneksi urakakseen suspend-ongelmiin liittyvien bugien työstämisen/jalostamisen. Ja tämä on nyt suunnattu niille, joilla olisi halua käyttää vapaa-aikaansa bugien jäljittämis/korjailupuuhiin (se on ihan mukavaa puuhaa saada "järjesteltyä"/keräiltyä bugeja, jopa ratkaistua, ja autettua ihmisiä jotka ovat bugiraportteja laittaneet).

Vaihtoehtona Launchpadille olisi toki normaali ohjelmatoimittajan tapa, eli ei bugienraportoimisjärjestelmää lainkaan. Avointen ohjelmaprojektien puolella tapana ei vain ole ongelmia peitellä, mutta ongelmien ratkaisu on myös kaikkien ongelmien ratkaisemisesta kiinnostuneiden harteilla kollektiivisesti.

Edit: Lisäyksenä yhteenveto: "a) mikään softa ei ole bugitonta, b) kukaan ei voi korjata kaikkia bugeja, c) avoimissa softissa yhteisöstä kokonaisuutena, mukaan lukien mahdolliset palkatut työntekijät yrityksissä, on kiinni, mitkä bugit tulee korjatuksi". Eli tarkoituksenani ei ole sanoa etteikö Launchpad toimi käyttäjän kannalta epäoptimaalisesti, ja olisi mukava jos palautetta tulisi enemmän sekä toimintaa, vaan tuoda nuo kolme pääpointtia vain esiin.

[timbba]

Edelleen ehkä hieman häiritsee tuo asenne siitä että "vastaukset bugeihin tulee myöhässä" - kenen niitä vastauksia pitäisi tehtailla, ja mitä niiden vastauksien pitäisi sisältää? Sekin joka bugiraporttiisi vastasi jauntyn kokeilemisesta näyttäisi olevan satoja bugeja vapaa-ajallaan käsittelevä henkilö. Kuinka paljon lisää aikaa juuri hänen pitäisi lisää käyttää tutkiakseen sinun ongelmaa?

Et ymmärrä nyt minun pointtiani. Bugikorjaukseen ei ole Ubuntulla paukkuja, kun ei ole vain yksinkertaisesti aikaa ku seuraava release painaa päälle. Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...

Jos ainoa ongelma on tuo näppäimistön toimimattomuus, eli kannettavaan sisältyvät syötelaitteet eivät toimi, luulisin että ongelma ei ole kernelissä vaan esim. X:ssä. Ja tällainen ongelma on tosiaan täysin eri suspend-ongelma kuin ne yleiset, eli että laite ei herää suspendista lainkaan.

Nyt epähuomiossa olen puhunut väärin. Eli tämä bugi mistä nyt puhut, ei ole se mistä itse puhun. En ollutkaan avannut itse bugia, vaan täydentänyt erään toisen avaamaa bugia. Sori sekaannus siitä...

Se bugi mitä ajan takaa on, kun Ubuntu ei edes mene suspend-tilaan. Kovalevy sammuu, fanit jää pyörimään, näyttöön jää vain vilkuttava underscore, jne... Vain reboot auttaa. Ja noita bugeja on pilvin pimein launchpadissa... Eikä kommentin kommenttia liitteiden lisäämisien jälkeen missään bugissa. Suspend on kuitenkin prioriteetiltaan minusta aika oleellinen asia, niin luulisi että niitä edes jotenkin tsekattaisiin.

Mutta edelleen kaikki kaatuu minusta siihen, että ei vaa ole aikaa niitä tsekata (uus release painaa päälle). Tämä on minun pointtini ja siksi olen ottanut sen asenteen, että en itse sinne Launchpadiin mitään laita, ku ei sillä ole vaikutusta. Kyllä osaan ihan itsekin aina kokeilla uudella releasella, enkä vain jonkun kehotteesta.

Itse olen yrittänyt myös metsästää vikaa, mutta tietotaito ei vaa riitä. Joten helpompaa aina pitää Debian yhdellä partitiolla ja kokeilla Ubuntua silloin tällöin, josko jokin versio toimisi. Niin kun sanoin, niin Ubuntua haluaisin käyttää lähinnä siksi että pakettivarastoja on pilvin pimein. Helpottaa ettei tarvi ite käännellä ku välillä kääntelyssä tulee mutkia matkaan...

[qwertyy]

Jos tämän tutkimisessa haluaisi edetä, mitä nyt ei ilmeisesti haluttu, olisi hyvä etsiä esim. tuon synapticsia käyttävän laitteen vendor/product-tiedoilla mahdollisia kohtalotovereita, merkitä jokin bugi toisen duplikaatiksi jos vastaava oire (näppäimistö/touchpad ei toimi suspendin jälkeen) löytyy ja jatkaa sitä kautta. Mitä paremmin jokin tietty ongelma saadaan eristettyä ja kerättyä samat bugit toistensa duplikaateiksi, sitä paremmin ongelma alkaa hahmottua ja ylipäänsä erottua Launchpadin tuhansien "bugiraporttien" kohinasta.

No en minä kyllä noinkaan ole sanonut, että en haluaisi edetä tuon tutkimisessa, vaan kun en viitsisi edes yrittää merkitä bugiraportissani mainittua käytännössä täysin identtistä bugiraporttia duplikaatiksi ja nimenomaan lisäsin tuohon raporttiin linkitetyn bugiraportin tietoja joita oli kysytty myöhemmin, mutta niitä ei oltu saatu.

Oikeastaan nyt päästiinkin asian ytimeen ja ehkä selittää myös alkuperäistä kysymystäni. Eli sain jatkokysymyksen, testasin ja vastasin. Silloin muuttui tila "triaged", enkä siis keksinyt että millä perusteilla näin siis tapahtui ja mitä se tarkemmin käytännöntasolla edes tarkoittaa. Tuskin se triaged statukseen muuttunut sen takia, että jauntyn alpha 3:lla koneeni ei nouse enää lainkaan suspendista?

Hiukan OT, mutta toimiiko tuo suspend ylipäätään oikein monilla kannettavilla ihan asennuksen jälkeen. En ole vielä kovin moneen läppäriin kerennyt linuxeja asentaa, mutta jotenkin mutulla taitaa olla todella ongelmallinen linuxeissa? Mitä vanhat linux konkarit tähän sanovat?

*muoks*
läppäreissä en muuten oikeastaan olekaan kokeillut kuin Ubuntuja poislukien eee.

[Asmo Koskinen]

Et ymmärrä nyt minun pointtiani. Bugikorjaukseen ei ole Ubuntulla paukkuja, kun ei ole vain yksinkertaisesti aikaa ku seuraava release painaa päälle. Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...

Timo ei ymmärrä, hmm...  

Kenellä on paukkuja? IBM? Sun? RedHat? Novell? Oracle? Öhh... Microsoft?

Linux-kerneliä syytetään aika ajoin ahneudesta lisätä uusia ominaisuuksia, vaikka vanhojakaan ei ole vielä korjattu.

Tämä ketju/vuodatus on vuodelta 2001!!!

"I've used Linux for over 5 years now. In all the time I've used it, I
have never seen this much instability in a single kernel
series - though I've noticed each successive 'stable' series having
more bugs than the last (2.2.x crashed once a week with SMP
until 2.2.10!).
[--]
This brings me to the subject of this rant: are we going too fast? New
drivers are still showing up in each successive kernel, and yet no one
seems to be able to fix the old bugs that already exist."

http://lkml.indiana.edu/hypermail/linux/kernel/0108.1/0881.html

Joten olet huomannut ongelman, joka on ollut olemassa siitä asti, kun ylipäänsä keksittiin ohjelmoida tietokoneita/ohjelmia.

Mitä Alan Cox vastasi vuonna 2001, tuohon valituksen. Samasta "mulle-kaikki-heti-nyt" -ongelmasta ("latest version" obsession) me edelleen kärsimme.

"Kernel.org certainly should list the 2.2 status (hey I maintain it I'm
allowed to be biased). Its unfortunate it many ways that people are still so
programmed to the "latest version" obsession of the proprietary world some
times. For most people 2.4 is the right choice but for absolute stability
why change "
----

Mitä Sinä voit tehdä?

Kirjoittaa kärsivällisesti bugiraportteja ja odottaa. Jos osaat koodata, niin... Use The Source, Luke!

Ystävällisin terveisin Asmo Koskinen.

[timbba]

Et ymmärrä nyt minun pointtiani. Bugikorjaukseen ei ole Ubuntulla paukkuja, kun ei ole vain yksinkertaisesti aikaa ku seuraava release painaa päälle. Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...

Timo ei ymärrä, hmm...  

Kenellä on paukkuja? IBM? Sun? RedHat? Novell? Oracle? Öhh... Microsoft?

Linux-kerneliä syytetään aika ajoin ahneudesta lisätä uusia ominaisuuksia, vaikka vanhojakaan ei ole vielä korjattu.

Debianilla tuntuu paukkuja olevan ku aina toimii... Ubuntussa ei ole toiminut kuin 7.10 versiossa vasta asennettuani uswsusp-paketin. Kernelissä se vika ei ole ku Debian käyttää ihan yhtälailla samoja kerneleitä (esmes 2.6.24). On ollut muitakin koneita kuin omani jossa Ubuntun suspend ei toimi, mutta yllättäen Debian vain rokkaa.

En ymmärrä miksi pitää hirveästi pitää puolia jos selkeästi eri distroissa samoilla kerneleillä toinen toimii ja toinen ei. Ja minusta juurikin syypää Ubuntun toimimattomuuteen on liian nopea releasointi aikataulu.

Testasin muuten omassa koneessani Jauntynkin --> ei toiminut. Odotan innolla, että Jaunty nappais tuon 2.6.29 kernelin, josko sillä toimis ku kerneliinkin on tehty jotain muutoksia suspendiin.

[Asmo Koskinen]

En ymmärrä miksi pitää hirveästi pitää puolia jos selkeästi eri distroissa samoilla kerneleillä toinen toimii ja toinen ei. Ja minusta juurikin syypää Ubuntun toimimattomuuteen on liian nopea releasointi aikataulu.

En provosoi, vaan sanon, minkä olen ennenkin sanonut.

Äänestä jaloillasi.

Jos Debian tai joku muu distro toimii paremmin, niin käytä ihmeessa sitä.

Minäkin lopetan Ubuntun käytön heti sinä päivänä, kun löytyy parempi distro, joka vastaa minun vaatimuksiani LTSP5:n suhteen. Vielä sellaista distroa ei ole tullut vastaan.

Joten äänestä kukkarollasi, kun kysessä on rauta ja äänestä jaloillasi, kun kysessää on softa. Ei se sen kummempaa ole.

Ystävällisin terveisin Asmo Koskinen.

[timbba]

Niin kun sanoin, niin Ubuntua haluaisin käyttää lähinnä siksi että pakettivarastoja on pilvin pimein. Helpottaa ettei tarvi ite käännellä ku välillä kääntelyssä tulee mutkia matkaan...

Tuo on syy miksi Ubuntua yritän koneelleni saada..

[Timo Jyrinki]

No en minä kyllä noinkaan ole sanonut, että en haluaisi edetä tuon tutkimisessa, vaan kun en viitsisi edes yrittää merkitä bugiraportissani mainittua käytännössä täysin identtistä bugiraporttia duplikaatiksi ja nimenomaan lisäsin tuohon raporttiin linkitetyn bugiraportin tietoja joita oli kysytty myöhemmin, mutta niitä ei oltu saatu.

Viittasin timballe, mutta eihän se ollutkaan hänen bugiraporttinsa ja sekoitin itsekin nuo lukuisat

Ja siis yleensäkin "ok", sain jo sanottua haluamani joten tosiaan:

Tätä yritän tässä toitottaa... Kun ei ehditä bugeja korjailla, niin kaikki releaset ovat bugisia ja kierre on valmis. En ole ainut joka ajattelee näin...

Joo, tästähän olikin jo puhetta, että on varmasti paljon puoltamassa sitäkin että joskus ei enää olisi puolivuosittaisia julkaisuja. Linus itsehän veikkaili vuoden sykliä hyväksi. Toisaalta sitten Ubuntu-käyttäjiä valuisi esim. Fedoran puolelle, ja lisäisikö vai vähentäisikö se sitten yhteisön osallistumista bugien korjailuun jos uutta julkaisua (ja esim. sen alpha/beta-vaiheita) pitäisi odottaa niin kauan. Vaikeita kysymyksiä.

Suspend on kuitenkin prioriteetiltaan minusta aika oleellinen asia, niin luulisi että niitä edes jotenkin tsekattaisiin.

Koko ajan, ja tuhansia bugiraportteja on varmasti käsitelty ja tullut korjatuksi. Ubuntu 9.04:aan on jälleen tarkoitus keskittyä kovasti suspend/resume-ongelmiin, ja tämä voi olla mielenkiintoista luettavaa:
http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html

Siellä perustellaan muun muassa, miksi pysyä 2.6.28:ssa 9.04:ää varten, eli voidaan testata paremmin. "We are making the suspend & resume one of our top priorities for this cycle. We ran a suspend and resume workshop with every notebook at the sprint.". 12 koneella testatusta 65:stä heidän sprintissään oli ongelmia, ja niistä 12:sta suurin osa ongelmaisista liittyi NVIDIAn käyttöön. Tulossa on myös yhteisön aktivoimista / organisoimista ongelmien korjaamiseen.

Oikeastaan nyt päästiinkin asian ytimeen ja ehkä selittää myös alkuperäistä kysymystäni. Eli sain jatkokysymyksen, testasin ja vastasin. Silloin muuttui tila "triaged", enkä siis keksinyt että millä perusteilla näin siis tapahtui ja mitä se tarkemmin käytännöntasolla edes tarkoittaa. Tuskin se triaged statukseen muuttunut sen takia, että jauntyn alpha 3:lla koneeni ei nouse enää lainkaan suspendista?

Jaa-a Se tarkoittaa että bugiin on saatu oleellisia tietoja bugia käsitelleen arvion mielestä, käytännössä varmaan tuo että tiedetään input-laitteista valmistaja/tuote-id:t riittää ainakin siihen että joku kiinnostunut voi tosiaan etsiä yhtymäkohtia muihin ongelmiin, tai jopa synaptics-ajurista mahdollista viitettä juuri tuohon laitteeseen.

Hiukan OT, mutta toimiiko tuo suspend ylipäätään oikein monilla kannettavilla ihan asennuksen jälkeen. En ole vielä kovin moneen läppäriin kerennyt linuxeja asentaa, mutta jotenkin mutulla taitaa olla todella ongelmallinen linuxeissa? Mitä vanhat linux konkarit tähän sanovat?

Tilanne elää aika paljon, mutta kuten yleensä ainakin uusimmilla laitteilla on aina uusia ongelmia. Mutu-tuntumalla vähintään puolen vuoden vanhaan laitteeseen (tai vanhempaan) jos laittaa nykyään tuoreen Linuxin, eikä käytössä ole Nvidiaa, mahdollisuudet ovat varsin hyvät. Tuosta ylempää laskien arviolta 90% Mutta paljonhan on upouusia koneita upouusilla emolevyillä, ja sitä nvidiaa myös. Ja myös ATI-käyttäjät usein vielä asentavat suljetun ajurin jolla on ollut tapana hajoilla suspendissa ainakin 7.10:een asti, en tiedä olisiko nyt sattumalta muuttunut luotettavammaksi.

Debianilla tuntuu paukkuja olevan ku aina toimii... Ubuntussa ei ole toiminut kuin 7.10 versiossa vasta asennettuani uswsusp-paketin. Kernelissä se vika ei ole ku Debian käyttää ihan yhtälailla samoja kerneleitä (esmes 2.6.24). On ollut muitakin koneita kuin omani jossa Ubuntun suspend ei toimi, mutta yllättäen Debian vain rokkaa.

Debian on kokonaan yhteisön tekemä distro, eli heillä ei ole Canonicalinkaan tapaista yritystä auttamassa. Tästä voidaan päätellä ainakin se, että jos Ubuntun yhteisö kehittyisi pidemmälle, saataisiin useampia ongelmia ratkaistua. Ja toisaalta toki se, että Debianin pidempi julkaisusykli tuottaa vakaampia julkaisuja.

Ja onneksi on Debian! Kaikki distrot palvelevat erilaisia tarkoituksia, ja Debian on luultavasti "rock solid" -sarjan ykkönen. Ei ole tarkoituksenani pitää ketään Ubuntussa eikä siltä kannalta "puolustaa" Ubuntua, vaan kertoa miten asiat toimivat (tai eivät toimi). Jos Debian toimii paremmin, en voi kuvitella parempaa vaihtoehtoa Ubuntulle, joka suurimmalta osalta on sama asia kuin Debian muutenkin. Jos taas haluaa uudempia ohjelmistoja, on aina jonkin verran enemmän bugejakin. Itse olen pitkään käytänyt Debiania pääkäyttiksenäni työkäytössä.

Niin kun sanoin, niin Ubuntua haluaisin käyttää lähinnä siksi että pakettivarastoja on pilvin pimein. Helpottaa ettei tarvi ite käännellä ku välillä kääntelyssä tulee mutkia matkaan...

Tiedätkö http://www.backports.org/ , http://debian-multimedia.org/ , http://debian-unofficial.org/ , http://www.apt-get.org/ ?

[lompolo]

Ubuntu 9.04:aan on jälleen tarkoitus keskittyä kovasti suspend/resume-ongelmiin, ja tämä voi olla mielenkiintoista luettavaa:
http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html

Kannattaa lukea. Tuolta löytyy mm. pakettivarasto, missä on kokeiltavaksi vanilla kerneleitä, Ubuntussa olevat versiot ilman ubuntun muutoksia ja tuorein kehitysversio (nyt 2.6.29-rc4)

Saisiko ongelmia rajattua ajamalla komennon suspend esim. recovery modessa?

[timbba]

Ubuntu 9.04:aan on jälleen tarkoitus keskittyä kovasti suspend/resume-ongelmiin, ja tämä voi olla mielenkiintoista luettavaa:
http://blog.redvoodoo.org/2009/02/jaunty-kernel-bits.html

Kannattaa lukea. Tuolta löytyy mm. pakettivarasto, missä on kokeiltavaksi vanilla kerneleitä, Ubuntussa olevat versiot ilman ubuntun muutoksia ja tuorein kehitysversio (nyt 2.6.29-rc4)

Saisiko ongelmia rajattua ajamalla komennon suspend esim. recovery modessa?

Se on kyllä erinomaista, että Ubuntussa nyt aletaan panostaa tuohon suspendiin. Pitääpä kokeilla noilla 2.6.29 kerneleillä ja noita suspend testiscriptejä. Katotaan kuinka äijän käy.

[timbba]

Kannattaa lukea. Tuolta löytyy mm. pakettivarasto, missä on kokeiltavaksi vanilla kerneleitä, Ubuntussa olevat versiot ilman ubuntun muutoksia ja tuorein kehitysversio (nyt 2.6.29-rc4)

Eipä auttanut noikaan.. Vika ei siis ole kernelissä, vaa jossain ihan muualla: Ubuntun virittämissä pm-suspendin quirkseissä, acpin scripteissä, tai jossain muussa vastaavassa virityksessä..

Saisiko ongelmia rajattua ajamalla komennon suspend esim. recovery modessa?

Eipä auta oikein tuokaa.. pm-suspend ku tekee recoveryssa, niin ei mitää muuta tapahu kuin underscore jää vilkkumaan ylänurkkaan. Jotain on kuitenkin Jauntyssä  tehty erilailla sillä X:stä suspendatessa näyttö sammuu, mutta suspend moodiin se ei mene kuitenkaan ollenkaa. Kovalevyn vaihdoin hiljaisempaan, niin en ole varma enää sammuuko se niin kuin Intrepidissä.