Megjelent az UHU-Linux 2.1

 ( Anonymous | 2008. január 18., péntek - 18:20 )

Tegnap, egyelőre nagyobb beharangozás nélkül megjelent az UHU-Linux 2.1-es verziója. Hivatalos bejelentés később várható... Letölthető innen.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem, meg nem toltheto le ftp-vel!

Egyebkent itt irtam errol: http://lists.uhulinux.hu/arc/dev/2008-01/msg00081.html

FTP es bejelentes jovo heten.

Akkor ez most nem is hir?

__

Zopr miafene

Én torrentről vadásztam le. Nem rossz, nagyon gyors. Pár dolgot a kor ízlésének és kihívásának megfelelően oldottak meg, de van még rajta csiszolni való. Az igazi értéke a nem hivatalos csomagokkal lesz szerintem teljes.

Mint az UHU eseteben mindig.
De ez valhol igy van jol. Magam reszerol mar atalltam debianra, de ha valakinek Linux ot ajanlok, altalaban mindig az UHU, esetleg Debian.

__

Zopr miafene

Nekem meg nem bootol az Asus laptomon :(

Nekem az MSI670-esen, de ez minden disztrónál így van, amelyik 2.6.23-as kernelt használ. Az UHU-nál kernelváltás majd a 2.2-nél lesz, úgyhogy a 2.1 ki fog maradni.

próbáld meg a noapic -al a grubban

nekem semelyik ubuntu nem bootol a gepemen az 'irqpoll' kernel parameter nelku. (off: meg a hardy se, kezdhetem megint a bugreportolast...pedig gutsynal is megtettem vagy 3x, de leszartak)

Nekem csak a 32 bitesek marhulnak, de mind. A 64 bittel nekem semmi gond. Próbálj ki egy 64 bitest is. Az enyémnek valószínűleg hibás a BIOS -a, mert az ACPI -t rosszul kezeli. Az APIC támogatás kiütése a BIOS -ból talán segítene.

Ezt már végigzongoráztam, az RC2-vel és az Ubuntu 7.10-zel is. Ubinál a telepítőt sikerült lefuttatni, de a rendszer semmilyen módon nem volt hajlandó elindulni.
http://hup.hu/node/48837

Hajrá fiúk, csak így tovább! :)

Puszta érdeklődés:

UHU-t használsz még most is, hogy kiváltál a csapatból?

__

Zopr miafene

Most kizárólag céges gépeket használok, azokon nem UHU van. Ha egyszer elhozom a sajátomat, akkor azon marad az UHU.

Hehh, most láttam, hogy hol is dolgozol jelenleg.
Értem már, hogy miért váltál meg az UHU -tól. :) (Biztos írtad elötte valahol, csak nem olvastam.)

__

Zopr miafene

Nem harangoztam be különösebben, sőt, addig nem is igazán akartam elárulni, amíg nem látszott számomra, hogy beválik az új hely. (Volt bennem egy minimális, tényleg nagyon pici félelem a gyökeresen újjal szemben, megvártam amíg elmúlik.) Most már aki kíváncsi, úgyis pillanatok alatt kiderítheti :)

Sziasztok!

Feltettem az új UHU-t és valami "nyikorgó" hang jön ki a gépből gyakori időközönként. Ubuntu alatt nem tapasztaltam ilyet, tehát a hardver jó.
Mi lehet ez?

Biztos a fiókák. :)

Azokat, hol találom? :)

A fészekben. Ez szerintem egyértelmű. :)

az interfészekben? :)

Komolyra fordítva a szót, honnan jön a hang?
Hangszóró, wincsi?
Ezt a két dolgot tudom elképzelni.

Nem igazán tudom. Van amikor "állásában" is csinálja, vagy akkor ha indítok egy programot, tehát nem lehet valami konkrét művelethez kötni. Szabálytalan időközönként teszi. Néztem a HDD LED-et nem villog. Most Ubuntu alól írok, így visszamegyek UHU-ra és jobban fülelek, utána jelentkezem.

Ui.:
Még régebben próbaként feltelepítettem a Mandriva 2007-et, ugyan ez volt.
"Régi" 2.0 UHU, Ubuntu nem csinál ilyet.

Meghallgattam, sokkal okosabb nem lettem, mert akkora zaj van "bent"...

Nagy valószínüséggel, a vinyóból jön a hang (hangszóróból semmi esetre sem), a legjobban az elektromos kisüléshez lehet hasonlítani. Esetenként (elég sokszor) összefüggésbe hozható az egér mozgatásával. Próbaként nyitottam terminált (Alt+Ctrl+F1) és leállítottam az X-et (init 3). Érdekes, hogy a bejelnetkezésnél várakozva a "hang" az óra másodpercéhez igazodva periódikusan jelentkezett. Bejelentkezve és egy kicsit links-el böngészve is előfordult "az elektromos kisüléshez hasomlító hang" de nem olyan erősen. Most, hogy írom ezt a bejegyzést (már grafikus felületen), csak az egér mozgatáskor és a billentyűk leütésekor jelentkezik.

Szinte biztos, hogy a vinyóból jön a hang. Pl. böngészöben új lap betöltése, vagy letöltés közben is.

Idézet:
Esetenként (elég sokszor) összefüggésbe hozható az egér mozgatásával.

Integrált hangkártya? Mert akkor ez "normális".......

Igen.

Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller

Viszont akkor a régebbi UHU-n (2.0) és Ubuntu-n (7.10) miért nem jelentkezik?

próbáld meg szétszedni az IRQ-kat.
BIOS-ban kiosztani, és pci=biosirq.

Ez nekem "nagy" feladat, azt sem tudom, hogy álljak neki. Na jó, boot-kor nyomom a Delete-t. Ha nem hosszú leírnád, merre keresgessek? Ez nem fog "bekavarni" az Ubuntunak?

Most elindulok itthonról, este leszek újból, az eddigi segítséget köszönöm.

a cpufreq szabályozás alapértelmezett?
ha igen, akkor az miatt csinálja, ha valami idélten freqvencián jár a cpu, a másik ilyen hangszerű, amikor azt RTC-t baszogatja az OS


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

_pinyo_villany_

"a cpufreq szabályozás alapértelmezett?"

Ezt hol tudom megnézni?

_saxus_

Ablak áthelyezésnél nem. Most például scrolloztam a Firefoxban, egy darabig csinálta majd abbahagyta.

$ zgrep CPU_FREQ /proc/config.gz

szerk.: vagy dmesg


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Kösz, ezekbe milyen sort keressek? (Bocs a sok kérdésért)

zgrep CPU_FREQ /proc/config.gz

ez konkréten egy sort ad vissza

amigy cpufreq szóra keress rá, vagy ondemand ... kapcsolatos szavakra


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

A config.gz file-ba ezeket találtam a "cpufreq" szóra,

# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_POWERNOW_K6=y
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
CONFIG_X86_GX_SUSPMOD=y
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
CONFIG_X86_P4_CLOCKMOD=y
CONFIG_X86_CPUFREQ_NFORCE2=y
CONFIG_X86_LONGRUN=y
CONFIG_X86_LONGHAUL=y
CONFIG_X86_E_POWERSAVER=y

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=y
CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y

és ezt az "ondemand" szóra

CONFIG_CPU_FREQ_GOV_ONDEMAND=y

talált süllyedt :D

ezeket kapcsold ki (forgass új kernel-t) és akkor meg fog szünni


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Köszöm a segítséget, de itt megállok. Még az életben nem forgattam kernel-t, majd talán később.

Köszönöm mégegyszer a gyors reagálást.

nyugi valoszinuleg nem kell kernelt forditanod, ez csak affele mania egyes embereknel
a /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor file-nak mi a tartalma?
ha ondemand akkor root-kent add ki a kovetkezo parancsot
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ha ez a gond akkor ettol valoszinuleg megszunik a problema

igen csak így meg scriptelni kell és berakni rcS.d-be, hogy lefussom mindig, ez meg így inkább gányolás :P
ha a kernelből kiszedi, akkor meg nem is lesz benne és az egy végleges megoldás.

ja amugy néz körbe acpi vagy powersave környékén és ott állítsd át


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

meg jo hogy uhu-ban nincs rcS.d :D

azt meg nem igazan ertem miert lenne ganyolas egy userspace-bol allithato dolgot userspace-bol allitan???
vagy esetleg a laptopomhoz is tartsak fenn kulon kernelverziokat, hogy beallithassam a szukseges proci freq-t ujrainditassal???

régen (4 vagy 5 éve) használtam uhu-t és ott is van valami rcS-jellegű, csak valami másik könyvtárban :P de a lényeg, hogy van


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Hát ez csúcs. Megszünt Janusz leírása alapján. Köszönöm!!
Akkor most erre kellene egy script-et írni, hogy minden iduláskor lefusson?

Egyébként ez probléma kárt tehet a gépbe?

nem hiszem hogy kart tehetne a gepben

script keszitese root-kent:
echo "performance" > /etc/rc.boot/90-scaling_governor.boot
chmod +x /etc/rc.boot/90-scaling_governor.boot

es kesz

szerintem ez kicsit sántít ...

#!/bin/sh

echo "cpufreq hack"
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor && \
echo "ok"

vagy:

#!/bin/sh

cpu=$(find /sys/devices/system/cpu/ -name scaling_governor)

echo "cpufreq hack:"

for i in $cpu;
do
 echo performance > $i &&\
 echo OK ||\
 echo Failed;
done

ez több processzor / mag esetén jó, mivel ott magonként lehet állítani, de ebbe a scriptbe is bele lehet kötni, mivel nem ellenőrzi, hogy van e cpufreq szabályozási lehetőség és ha nem talál, akkor csak szimplán kilép hibaüzenet nélkül ...
ennek kell benne lennie abban a file-ban


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

amen
attol meg az altalm irt megoldas tokeletes lesz neki, a tied agyuval verebre esete lenne az o eseteben
nyilvan ha altalanos megoldast akarnek a disztroba akkor nem 1 sorral oldanam meg, de most errol szo sincs

echo "performance" > /etc/rc.boot/90-scaling_governor.boot

ezzel csak az volt a bajom, hogy ha ezt futtatja, akkor a 90-scaling_governor.boot tartalma csak ennyi lesz: performance

és ha nem csinál egy performance nevű scriptet /bin , /sbin ... /usr/local/sbin alá, akkor nem fog csinálni semmit, mivel _HA_ jól tudom, akkor nincs alapból performance parancs, ami átállítaná

amúgy az ágyuval a veréb az jó hasonlat, de ezt én tovább szoktam fokozni: hidrogénbombával az egérre (r) (c) TM

szerk.:
init scriptek esetén a #!/bin/sh vagy a #!/bin/bash is javallott


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

hupsss tenyleg erosen bugzik a dolog :)

akkor a javitott verzio:
echo -e '#!/bin/bash\n\necho performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' > /etc/rc.boot/90-scaling_governor.boot
chmod +x /etc/rc.boot/90-scaling_governor.boot

Kipróbáltam mind három megoldást, látszólag (induláskor kiírja) lefut a script, azonban nem állítja performane-ra. ondemand marad.

Megfigyeltem, ha kijelentkezek és újból bejelentkezek ismét jelentkezik a probléma az
"echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" lefuttatásáig.

akkor a c-verzió jön, hogy az acpi-daemon környékén kell állítgatni (user-space-es tool) ...
nézz körbe a /etc/acpi vagy /etc/apmd vagy /etc/powersave vagy hasonló nevű könyvtárakban.


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

_acpi_ könyvtárakat itt találtam:

/lib/modules/2.6.23.9-1/kernel/drivers/acpi
/usr/include/acpi
/usr/lib/perl5/5.8.8/i386-linux-thread-multi-64int-ld
/usr/src/linux-2.6.23.9-1/include
/usr/src/linux-2.6.23.9-1/include/config
/usr/src/linux-2.6.23.9-1/include/config/hotplug/pci
/usr/src/linux-2.6.23.9-1/include/config/x86

_apmd_

Könyvtár csak egy van /usr/share/doc/Packages/apmd, de ez a doksi a laptopról ír. (ha jól értem)
apmd file-ok az /etc/init.d és a /usr/sbin könyvtárban, illetve az /etc/runlevel.d/custom és /etc/runlevel.d/default könyvtárban.

_powersave_

Könyvtár nincs, file-ok az alábbi helyen:

/usr/lib/pm-utils/power.d
(Itt sched-powersave file-ban van valami frekvenviáról, amik ide mutatnak:
"/sys/devices/system/cpu/sched_mc_power_savings"
"/sys/devices/system/cpu/sched_smp_power_savings")
/usr/sbin
/usr/src/linux-2.6.23.9-1/include/config/cpu/freq/gov
/usr/src/linux-2.6.23.9-1/include/config/x86/e

Ui.: A végén már csak csíkban fogunk írni. Ezen, hogy lehet javítani, mert mindent úgy csinálok, mint eddig? Az előnézet jó.

Sehogy. Nyiss egy új fórumtémát.

Na és ha nem, akkor mihez köthető, pl. egy ablak áthelyezésnél? Két gépen is megfigyeltem már (egyik egy Audigy 2-s, sajátomban meg egy SB Live! van használatban, nem az integrált), de időnként ettől függetlenül lehet hallani egy-egy ablak áthelyezésekor ilyen hangot.

Nekem a tv tuner kártya szedi fel a proci zaját. Ha a csatorna nincs lenémítva, akkor például DVD lejátszásakor, de még billentyű leütésekor is zajos. Szerencsére a tvtime-ot szoktam tv-zésre használni, és ennek van olyan opciója, hogy kilépéskor lenémítja ezt a csatornát, elindításkor meg visszaállítja. Ha nem lennék túl lusta, beraknám az UHU bugtrackerbe a többieknek, hogy tegyék defaulttá ezt a beállítást.

Érdekes, hogy az RC2 nem hibázott a konzolon az ékezetes betűkkel, míg a végleges igen. Remélhetőleg lesz nemsokára javítás.

biztos nem lesz javitva mert nem ismert bug (kiveve ha binaris nvidia drivert hasznalsz, de azzal nem tudunk mit kezdeni)
kifejtened kicsit reszletesebben?

én nem tudom időponthoz kötni, de vmelyik font csomag frissítése után az ékezetes betűk elromlottak konzol használatakor... akkor jó ötletnek tűnt átállítani egy másikra, már nagyon bánom, mert így lehetőségetek se lesz javítani :-(

sorry

--
by Mikul@s

na ize, most konzol alatt a szoveges 80x25-os konzolt erted, vagy valameyik terminal emulatort?

természetesen a terminál emulátort: yakuake & konsose

--
by Mikul@s

Nálam konsole is meg yakuake alatt is telejesen jó az ékezet, apt-get install fonts* után beállítottam dejavu sans mono-ra.

Inkább az a ciki, hogy a betűtípusok nagy része nem igazán magyar kompatibilis, hiányzik az őű. Ezen érdemes lenne változtatni szerintem.

Nekem a karakteres felületen is összeborulnak, nem kellahhoz nVidia driver. Elvileg minden ugyan az, mint az RC2.

bugs.uhulinux.hu -ra jelentsd

Milyen webkamerát tudtok ajánlani UHU 2.1 alá ami tuti, hogy működik?
Akkor olyat vásárolok.

http://mxhaard.free.fr/spca5xx.html

Vagy kinézel egyet a boltban megjegyzed a típusát és google-ben rákeresel a support és a típus linux szavakkal.

ööö... arra mertem gondolni, hogy a disztribúció készítésekor kipróbáltak, teszteltek 1-2 dolgot, mint pl. hálózat, cd írás, nyomtatók, scanner meg ilyesmik, akkor ezek között lehetett webkamera is. Arra nem is merek gondolni, hogy nem foglalkoztak a témával.
Nos ekkor lehetne mondani, hogy ilyen és ilyen típussal próbáltuk, működött. Igy szvsz. sokkal egyszerűbb lenne a dolog.
Egy gyártótól elvárhatónak találok egy ilyet a felhasználói felé.

Persze belátom lehet guglizni is, sőt ha ügyes vagyok saját disztribúciót is készíthetnék. Végtelen a lehetőségek száma.

Jaaa, amúgy köszönöm a linket, tanulmányozom.

Úgy gondolod, hogy a disztró készítőinek fiókszám rendelkezésére áll egy csomó kamera, nyomtató, szkenner, wifikártya?

Magyar disztróról van szó, nem egy multiról!

Zupaaa'! Régi kedvenc rendszerem tehát végre új erőre kap!

akkor folytassuk itt

ha kde-t raktál fel, akkor rakd fel a kpowersave csomagot vagy más esetben a powersaved-et és ezekben be lehet állítani, hogy milyen sémák szerint akarod használni a gépet. Be tudod, állítani, mi milyen freqin menjen stb stb milyen sémát használjon a cpufreq ...


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

Alap telepítés Gnome-al. Egyik csomag sincs a hivatalos tárolóban, de a leírásod adta az ötletet, hogy van valami tálca alkalmazás ami a CPU-t figyeli.

Így kitettem a tálcára a CPU frekvenciaváltozás-figyelőt és egy kattintással tudok "performace"-t választani. Ez így egyenlőre megfelel. Köszönöm a segítséget!

nm


linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.16-pancs1

"... fiókszám ... egy csomó kamera ..."

Valamit nagyon elolvastál. Ki írt olyat, hogy fiókszám meg csomó?
A kérdés nem az, hogy ilyen meg ilyen akármik működnek-e UHU-2.1 alatt.
Hol olvastál ilyet?
A kérdés az, hogy 1 azaz egy darab webkamera nevet mondjon a disztró készítője, amit kipróbált és működött, mert szeretnék egy probléma menteset vásárolni.
De úgylátom ők még vagy nem olvasták a kérdést, vagy nem méltatnak válaszra.

"Magyar disztró ... nem multi"

Én UHU-Linux Kft.-ről tudok, akkor meg talán valami pénz is van a dologban. Nem?
Munkát végeznek pénzért. Hogy most multi vagy nem multi?

Azert nem valaszoltam(tunk), mert csak integralt cuccohoz volt szerencsenk, azzal viszont nem sokat ersz.

Köszönöm a választ, sajnálattal veszem tudomásul. Akkor az van, amit GegSite ajánlott.

A honlapjuk frissítését nem kapkodják el.

Az nem lehet, hogy azért nincs még hivaalos bejelentés, mert nem stabil verzió? Nem mintha a stabilnak nevezett annyira stabil is lenne.

Az nem lehet, hogy azért nincs még hivaalos bejelentés, mert nem stabil verzió?

nem

Nem mintha a stabilnak nevezett annyira stabil is lenne.

példákat is fel tudsz sorolni, vagy csak vagdalkózol a szavakkal?

--
by Mikul@s

Nálam olyan gond jelentkezett, hogy telepités után további csomagtelepitéskor a synaptic nem ismeri fel a dvd-t amiröl feltelepitettem az UHU-t. Illetve magát az olvasót, olyan nincs üzenettel. (CD-ROM hozzáadása)
Az asztalon viszont 2 db ikon is kint van, mint ha 2db olvaso lenne - csak 1 van.
Az automatikus felismerés müködik.

Teszt környezet VMware 6.0.0 verzio. UHU-Linux-DVD iso fájl használva CD/DVD olvasóként.

Hát azt kell, hogy mondjam nem csak Vmware teszt környezetben nem ismeri fel a synaptic a CD olvasót.

Hiba üzenet:
E: Nem sikerült ide váltani: /media/.dev/cdrom/ - chdir (2 Nem létező fájl vagy könyvtár)

Nálatok (fejlesztők) működik?
Ha nem, akkor ilyenkor mi van?

Most már tudom, hinnem kellett volna a Vmware tesztnek.

ismert bug, reméljük hamarosan lesz javítása
létezik rá workaround, keresd meg légyszi a levlisták archivumában...

[mielőtt megkérdeznéd: nem vagyok fejlesztője, legalább is nem úgy]

--
by Mikul@s

Jaaa, hogy tudtok róla?

Akkor ezt most nem értem, miért a megbotránkozás? Ettől stabilnak lehet nyílvánítani?
Az előadás videot néztem, ha jól értettem (elég rosszul hallani) nyomják a "gyári" CD-ket.
Puff neki.
(Amúgy elég jól működik, A VirtualBox-ot nagyon jó, hogy beraktátok, köszönöm. Ami még elég kellemetlen - látványos - az XMMS alap betűkészlete, négyszögek jelentek meg nálam. Másik betűkészlettel már jó.)

"Ettől stabilnak lehet nyílvánítani?"
A stabilnak nyilvánítás sehol nem azt jelenti, hogy _hibátlan_, csak annyit, hogy kiadták, mint névvel/verzióval ellátott stabil verziót, aminek az állapota fix(CD/DVD/ftp stb.) Utólag max. bizonsági javítások jelennek meg hozzá, új verziójú csomagok csak nagyon kivételes esetben.
Ezzel szemben a fejlesztői változat folyamatosan változik, alakul.

" Megjelent az UHU-Linux 2.1 -> 2008. január 18 "

"... /media/.dev/cdrom/ - chdir (2 Nem létezo fájl vagy könyvtár)
Hiba bejelentés dátuma -> 2007.11.29 "

"Utólag max. bizonsági javítások jelennek meg hozzá..."

Nem látom be, hogy itt biztonsági résröl van szo.

"Az nem lehet, hogy azért nincs még hivatalos bejelentés, mert nem stabil verzió? "
"nem"

Annyi igaz, hogy az hibázik, aki dolgozik, de minimum be kéne látni a hibát.
Elképzelem az arcát a kedves felhasználónak, aki megvásárolja a legújabb hazait; és nem csodálkozom azon, hogy mit fog erre a hibára mondani. Elképzelhetö, hogy váltani fog má$ik cuccra.
Nem egyezik a felfogásunk, még jó hogy nem autót gyártotok.
Én anno abban az iparban voltam, ott elfogadhatatlan ez a felfogás. Ott egy ilyen kaliberü hibáért minimum kirúgják az embert.

(Miközben irok KWrite-ban, nem jó az ékezet. Beállitás -> "Betüstilus"-t nem lehet váltani.)

"Nem látom be, hogy itt biztonsági résröl van szo."
Ezt nem is állította senki.

"Annyi igaz, hogy az hibázik, aki dolgozik, de minimum be kéne látni a hibát."
Ahogy látom, nincs elutasítva a hibabejelentés.

"Nem egyezik a felfogásunk, még jó hogy nem autót gyártotok. "
Ne legyél tévedésbe, én nem UHU fejlesztő vagyok :)
Ha rajtam múlt volna, ez a hiba nem maradt volna benne a 2.1-ben,
főleg, hogy a korábbi verziókban is ismert volt már!

Számomra ez jött át abból amit irtál: a stabil változatnál csak kissebb- és biztonsági hibákról lehet beszélni, alapvető hibáktól mentes, hiszen nem béta, nem rc hanem STABIL.

Itt ez stabilnak van kikiáltva. Egy előző hozzászólásban vagdalkodásnak vették, hogy merték nem stabilnak mondani.

Arra, hogy ez a hiba a korábbi verziókban is benne volt, már nem tudok mit mondani. Én mint felhasználó nézem a dolgokat nem mint szakember. Egy szakember többet lát. Én használom minden nap és szurkolok, hogy legyen egy jó kis használható rendszer. Segiteni nem tudok, mert mint mondtam (irtam) olyan szinten nem értek hozzá. Mikor bejelentették, hogy "rc" akkor ránéztem. Utánna nemsokára "stabil" lett. Viszont már a telepitéskor problémába ütköztem. Nem tudom mire vélni a dolgot. Ilyen szinten nincs letesztelve?

Úgy tűnik ez a hiba valamiért vagy nem tűnt elég fontosnak korábban, vagy egyszerűen megfeledkeztek róla. Mindenesetre most úgy tűnik, hogy javítani fogják.

"Segiteni nem tudok, mert" vs. "Ilyen szinten nincs letesztelve?"

Ebben te is tudtál volna segíteni! Az UHU-t 2-3 ember fejleszti, nagyon nagy szükségük van a segítségre a tesztelés/hibabejelentés vonalon.

Ebben egy a véleményünk. De a valóságban nem így néz ki a dolog.
Az elvárás, hogy a hibát szakszerüen kell leirni. Ha pongyolán, hétköznapi szavakkal irják le -ettöl lehet pontos és lényegretörö-, akkor azt elküldik a francba és azt mondják rá, hogy egy f@sz (tisztelet a kivételnek).

Ezzel szemben szerintem pedig felhasználóknak készitik a cuccot, nálla van a "puding próbája".
Ha nem lehet egy csomagot feltenni CD-röl, ha nem müködik a skype vagy nem lehet a tüzfalat beállitani, a kedves felhasználó sz@rja le, hogy a szakember hónapokig durta a kodokat, használhatatlan az egész.
Szerinted hány felhasználó tudja, hogy ugyan beállitotta a guarddog tüzfalat, de az csak a következö inditásig müködik, mert nincs megoldva rendszer induláskor, hogy az is induljon? Azt hiszik biztonságba vannak, bár ha tudnák, hogy nincs semmi védelem. Ha ezt tudnák mit tennének?
Csak egy "pipát" kellenne késziteni a megfelelö helyre és már meg is lenne oldva a dolog. De nem, sz@rakodás folyik, meg vita a forumokon.
Szoval ez a szemlélet nem tetszik a kedves "szakembertársadalomnak", ezért nem is tartanak igényt az ilyen tesztelésre. Szvsz ha ez igy marad bár melyik disztrónál - nem változtatnak ezen - akkor elöbb-utóbb le is lehet húzni a rolót.
Vajon mi lehet az ubuntu sikere? Jaaa persze csak a reklám?
Most tesztelem a legújabb pclinuxos-t, nagyon jó kis rendszer az is.
De csak egy os-t tesz fel az ember, nálam ez az uhu.

Az első bekezdésben leírtakat én az UHU esetén nem tapasztaltam még.
(Az 1.1 óta tesztelem/jelentek hibákat/használom.)

Javítás letölthető.

"Jaaa, hogy tudtok róla?"
https://bugs.uhulinux.hu/view.php?id=397