ubuntu & launchpad monnyon le!

de most komolyan, felidegesít folyton... a bug reportokat el se olvassa a kutya se, semmi válasz, aztán meg hopp, töröljük 1 év után. persze így is lehet csökkenteni a "bugok számát"... vagy a standard válasz, hogy "próbáld meg újabb kiadással." nem próbálom vazz, nem vagyok én teszter, nekem az lts-ben oldják meg a problémát! na de ezek már ismertek voltak a számomra eddig is. de most kipróbáltam valami újat: ask a question. hátha valami fejlesztő tud rá válaszolni...
erre kapom ezt:

Your question #12345678 on Ubuntu changed:
https://answers.launchpad.net/ubuntu/+question/12345678

Status: Open => Expired

Launchpad Janitor expired the question:
This question was expired because it remained in the 'Open' state
without activity for the last 15 days.

--
If you're still having this problem, you can reopen your question either by replying to this email or by going to the following page and entering more information about your problem: https://answers.launchpad.net/ubuntu/+question/12345678
You received this question notification because you are a direct subscriber of the question.

mégis miért expired? a kutya sem olvasta el, senki nem válaszolt rá, akkor mitől oldódott volna már meg a probléma? miféle többletinformáció? mindent leírtam pontosan. ha valakinek még kell több infó, az kérdezze meg. de ezt nem tette senki.
nem elég, hogy használhatatlanul lassú a launchpad, még ilyen szarul van megírva is! aki ezt a janitort írta, az mit gondolt? hogy a "hihetetlenül hosszú ideje megnyitott" kérdések (15 nap!!!) törölhetőek? meg hogy megoldódtak bizonyára, ha nem is válaszolt rá senki, akkor is?
mély nyomot hagyott bennem még az a bug report, amit 3-4 ubuntu kiadáson keresztül jelentettem be, folyton frissítve, hogy még mindig szar, még mindig, még mindig... és a csávó meg nem is értette meg, hogy mi a baj, és nem bírta reprodukálni a triviális bugot... pedig már screenshotot meg videót is csináltam meg minden... mire vagy 2 év alatt végre eljutott odáig, hogy "jé tényleg, hát ez itt critical bug"... pfff... (persze javítva még nincs azóta sem...)
eh... így semmi értelme nincs az egésznek.

( kikke | 2010. 10. 28., cs – 12:07 )

Nyehehe. Wishlistre rakják ha mégis foglalkoznak vele vagy insufficient information felkiáltással törlik. Volt olyan, hogy akkor reagált valaki amikor már túladtam a vason amin jelentkezett egy driver hiba.

Szerencsére opensource, így amikor sokáig leszarták, hogy a nautilus a fájl létrehozási dátumokat nem másolja, mondván ez így helyes, tudtam patchelni forrást és fordítani új binárist belőle. Meg aztán van olyan, hogy debianban ugyanaz a csomagverzió hibátlanul működik. Meg olyan is, hogy szembemennek a fejlesztőkkel, és mondjuk inkább a rendszer GD libjével linkelik a PHP-t.

Persze a fizetős supportot még nem próbáltam. Mindig előkerül az Ubuntu mellett érvként, hogy elérhető hozzá üzleti támogatás. Vajon ez mit jelent? Lehet szakértőkkel konzultálni a RedHat-re migrálásról vagy mi?

( styg v | 2010. 10. 28., cs – 12:03 )

Megértem a frusztrációd.
Ha megteheted, akkor válts stabilabb/aktívabb platformra.
Ha nem teheted meg, akkor kénytelen leszel együtt élni ezzel (vagy magad kijavítani a hibát, bár ez valószínűleg horribilis befektetéssel jár).

Ha a bejegyzésedet azért hoztad létre, hogy kiereszd a fáradt gőzt, akkor... már egyenesbe is jöttél. :-)

( dap | 2010. 10. 28., cs – 12:51 )

Nem linkeltel a bugreportot, pedig lehet épp innen nézne valaki rá, gyakran az is gyorsítja a folyamatot, ha menedzseled a bugot, hirdeted, reklámozod. Najó, ebben magam se bíznék, de kíváncsivá tettél. :)

Egyébként ez így megy a Fedoránál is - az első körös ellenőrzést szinte azonnal megcsinálják (át kell verekedned magad rajta), utána confirmed státuszban elcsücsülhet évekig a bug, ha nem olyan alkalmazásról van szó, amit a Fedora fejlesztők tartanak karban.

RHEL fizetős supportal ez egész másképp megy, bár az átverekedés ott is megvan, de utána is pörögnek az események.

hát ez nem segített.
viszont érdekes, ezt eddig észre sem vettem: úgy tűnik, hogy ezek a 21 perces időpontok ezek mindig fix időpontokban vannak, és nem arról van szó, hogy mondjuk bootolás időpontjától kezd a 21 perces ciklus. most rebootoltam a divider paraméterrel (nem segített), és a következő csúcs menetrendszerűen megjött 21 perccel a _reboot előtti_ csúcs után.
fura.

Ha a CPU használaton semmi nem látszik akkor azt érdemes megnézni, hogy esetleg nem-e D státusz miatt van. NFS, vagy más hálózati fájlrendszer, FUSE nincs mountolva?

Mondjuk a load az érdekesen jön ki, a mérése ugye úgy történik ugye, hogy a kernel szúrópróbával megszámolja a D,R státuszban lévő processzek számát és azzal korrigálja a loadavg addigi értékét. Ha neked van egy olyan szoftvered, ami a másodperc 1/10 -edére 1000 szálat futtat egyszerre, akkor 90% -os idle processzor mellett kaphatsz kb 100 -as loadot CPU erőforráshiány végett. Szóval úgy mérj, ahogy a kernel, pl.: top -i -H -d .2 -b

A kimenetet fájlba loggolni és összevetni azzal a rövid idővel, amikor a grafikonon a load felfelé ívelt (amikor lecseng az már teljesen érdektelen). Ha vannak processzek D vagy R státuszban, utána nekik lehet menni pl az strace [-r -t] -vel és figyelni, hogy milyen műveletbe akadnak be VAGY kilőni a fenébe és ha megszűnt a jelenség, akkor már konkrétabb bugreportot tudsz küldeni. Ott kell lennie a bűnösnek a top logban.

a cpu használat az totál 0, sehol semmi csúcs. a processzeket már sokat nézegettem ezen csúcsok alatt is, és nem láttam semmi gyanúsat se felbukkani, se lerohadni, se semmi. egyáltalán semmi változás nem látszik a processzekben ez alatt az idő alatt.
de holnap megnézem újra, nagyobb felbontásban. az általam készített 5 másodperces poll alatt is látszik a felfutásban némi fűrészfog minta, mintha több kis processz indulna egymás után és az rántaná fel a load-ot, de sajnos ennek semmi nyomát nem láttam topban, de lehet, hogy nagyon kis rövid élettartamú pici processzekről volt szó, amik az 5 secen belül el is tűntek?
nincs nfs, fuse sincs elvileg, viszont ez egy samba szerver (is), de kliensek nélkül is ezt csinálja. majd ha lesz időm és lesz egy kis leállás (valamelyik este), akkoir kipróbálom, hogy mindent letiltok a francba, és megnézem, hogy akkor is csinálja-e, vagy pedig valamelyik szolgáltatás/démon okozza ezt.
mondjuk addig nézegetem itthon is virtualboxban.

----------------------------------
feel the beat - it's everywhere!

Nagyobb felbontásban szerintem látszani fog, hogy felfutás közben valami sűrűbben ottvan a processzlistában mint egyébként (a cpu használatot nem is kell nézni, csak hogy mi bukkan fel sűrűbben). A kernel egy hasonló listából állapítja meg a load értéket (csak más időpillanatokban veszi a mintát), szóval látszania kell. Az eddigi 5mp -s pollok között sokminden elrejtőzhetett.

megnéztem ezt a top-ot -d .2-vel, és látni, ahogy elkezd felkúszni a load (kábé fél perc alatt), de semmi extra nem bukkan fel. ugyanaz történik, ami normál esetben is, néha felbukkan egy pillanatra egy-egy "event/0", "flush", egy valamilyen "scsi_eh_1", egy "ata/0" meg hasonlók, de ezek amúgy is fel-felbukkannak. mást nem látok.
egyébként kiirtottam a fél rendszert, nem fut se x, se gdm, se samba, se ftp se ntp se webmin se webminstats se semmi.

ez egy tök sima 32 bites ubuntu 10.04, ext4-re rakva. sima grafikus telepítővel. nincs titkosítás meg semmi. rendszeresen felfrissítve, ha jól rémlik (lusta vagyok megint odamenni), mindenféle backportolt meg nem támogatott frissítések is be vannak kapcsolva, stb. xfce/xubuntu utólag rárakva, de szereintem ez nem számít, mivel a komplett xorg is le van már lőve. vbox beállítások szerintem nem fontosak, mert a céges gépemen lévő vbox is ezt csinlja pedig az teljesen más architektúra, valamint az "éles vas" is ezt műveli. ami visszajelzést kaptam másoktól, az annyi volt, hogy egy sima alap telepítés ubuntu is ezt csinálja már.

----------------------------------
feel the beat - it's everywhere!

Valójában Mark Shuttleworth földönkívüliekkel tárgyalt az űrben, akik egy 12000000 km (42 fénymásodperc) átmérőjű pulzáló mágneses teret akarnak létrehozni. Hogy miért pont 42? Nem tudom. A lényeg, hogy ehhez 21 másodpercenként megemelik az Ubuntut futtató gépek fogyasztását egy pillanatra. Ma még csak nálad. Holnap ki tudja.

hmmm, hihetően hangzik! nem vagy véletlenül ubuntu fejlesztő? :D mindenesetre hihetőbb, mint a logokban 21 percenként felbukkanó "establishing communication channel with botnet master node... FAIL, retry in 1 second", meg ilyen semmitmondó üzenetek. :)
a 21 egyébként onnan jön, hogy 21cm a hidrogén hullámhossza, úgyhogy ez különösen alkalmas földönkívüliekkel való kapcsolattartáshoz.

a méter definíciója: egy méter annak a távolságnak a (pi^42)-ed része, amennyit a fény annyi idő alatt tesz meg, amíg egy átlagos ubuntu bugot expirálnakkijavítanak.
(régi elavult definíció szerint: annak a távolságnak (10^e)-ediken része, amit a fény annyi idő alatt megtesz, amennyi ubuntu két hiperfinom kiadási szintje közti frissítés, majd az azt követő backupból visszaállítás ideje.)

( uid_2783 | 2010. 10. 28., cs – 16:05 )

[cinikus_on]
pedig ez egy qrva jó és atomstabil rencer (állítólag), amibe rengeteg fejlesztés és hibajavítás történik. állítólag összességében több mint a top10 disztribúciókban.
[cinikus_off]

nem gondolod, hogy van idejük a bugreportokkal foglalkozni, miközben félévente adják ki az újabbnál újabb verziókat?

--
blackPanther 10.1.1
"amióta esténként kikapcsolom a mobilomat, utolérhetetlen vagyok az ágyban." - ismeretlen szerző

( Yorirou | 2010. 10. 28., cs – 16:44 )

Nekem szinte az osszes Lucid bugomat ugy zartak le, hogy maverickben javitva van (WTF).

Illetve vannak olyan bugok, amik evek ota megvannak, es mindig irogatnak hozza, hogy meg mindig szar.

( Charybdis | 2010. 10. 28., cs – 18:08 )

De miért törlik a bugreportot? Ennek semmi értelme. Kit zavar az, ha ott van?

Akkor tényleg így van beállítva, az elég amatőr. Írni kéne egy bugreportot, hogy állítsák át.