UHU-Linux 1.1-beta1 (TMK)

Címkék

Megjelent az UHU-Linux 1.1 első publikus béta (tesztelésre szánt) kiadása.

Az alap rendszer iso fájlként az ftp://ftp.uhulinux.hu/uhu/1.1-beta1/ címről tölthető le, 80 perces CD-re írható ki. További csomagok az ftp://ftp.uhulinux.hu/uhu/dev/packages/ címen szerezhetők be. A tükörszerverek listája megtalálható a http://download.uhulinux.hu/MIRRORS címen.

A rendszer naprakész szoftverkomponensekből épül fel. Alapját a 2.4.22-es kernel adja, amelyet számtalan plusz szolgáltatással bővítettünk. Sokat fejlesztettünk a csatolható eszközök (például Pen drive-ok) felismerésén. Csomagjainkat a gcc 3.3.1-es verziójával fordítottuk, glibc

2.3.2-t használva.

A grafikus környezetek terén jelentős lépés GNOME 2.4, valamint a KDE-t is frissítettük 3.1.4-re. Újdonság az XFce 4.0-rc4, valamint számtalan egyéb ablakozó rendszer is megtalálható. Az alkalmazásfrissítések közül talán a Mozilla 1.4, Abiword 2.0, Gnumeric 1.2 érdemelnek külön említést.

Megkezdtük az alkalmazások egységes, konzisztens menürendszerbe szervezését, és a végleges 1.1 kiadásra el fogunk készülni ezzel. Az általunk megtervezett, mindig csak a telepített programokat tartalmazó menü a Gnome és KDE grafikus környezetek alatt éppúgy megjelenik, mint Blackbox, Enlightenment, FVWM, IceWM, Sawfish, Window Maker és XFce alatt.

A Gnome, KDE és XFce környezet, valamint az ezekbe illeszkedő GTK1, GTK2 és QT alapú alkalmazások egységes új kinézetet kaptak. A korábbi sárga-zöld Bumblebee-nél jóval elegánsabb Bluecurve nevű témát a Red Hat disztribúcióból kölcsönöztük.

A rendszerindítás, futásiszint-váltás, leállítás során futó szkriptek terén komoly átdolgozás történt. Ennek részeként például megszűnt a régi /etc/runlevel.conf fájl, helyét az /etc/runlevel.d könyvtár vette át, teljesen más szintaxist használva.

Az XFree86 csomag könyvtárstruktúrája is jelentős átszervezésen esett át.

A telepítőt, valamint az UHU Vezérlőközpontot újraírtuk GTK2 alapon, továbbá rengeteg hibajavítás és fejlesztés történt bennük. Ennek során például jelentősen átdolgoztuk a csomagválasztási lépést.

A csomagkezelőben (dpkg+apt) végzett változtatásoknak köszönhetően ezentúl gördülékeny lesz az előzetes (pre, beta stb.) csomagverziók kezelése. A frissítések pedig roppant hatékonyan letölthetők rsync protokoll használatával.

A béta kiadást tesztelésre szánjuk. Mindenféle hibajelentést szívesen fogadunk a dev@uhulinux.hu fejlesztői listánkra, viszont nem tudjuk garantálni, hogy bármiféle kérdésben segíteni fogunk, így aki stabil rendszert kíván használni, annak nem ajánljuk a béta kiadást, mindenképpen várja meg a végleges 1.1-et. Az 1.1-beta1 kiadásban súlyos hibáról nem tudunk, viszont bőven vannak még apró hibák vagy javítanivalók. Az egyik ilyen hiányosság az, hogy 1.0-ról egyelőre nem lehetséges frissíteni. Az ismert hibákról és hiányosságokról a telepítés végén, valamint a telepített rendszeren az UHU dokumentáció menüpont segítségével olvashatunk.

Jelen kiadás kódneve "TMK", mely mögött a "Tervszerű Megelőző Karbantartás" [1] és a "Tokiói Magyar Klub" [2] állnak.

[1] http://www.freeweb.hu/niva4ever/gep/01aug/17szabo.htm

[2] http://www.yudit.org/club/

Hozzászólások

Itt nálunk eléggé közkedvelt az Uhu...

Már csak egy kérdés leledzik:

Ha kijön az 1.1, utána már folyamatosan lehet frissíteni róla az újabb változatokra...? Mert akkor késöbb sem kellene újratelepíteni egy friss(ebb) rendszerért... :)

Az 1.0 -> 1.1 frissítést is meg fogjuk oldani, mint ahogy az összes többi kiadás is tartalmazni fogja a 2-3 azt megelőző stabil kiadásról történő frissítés lehetőségét. Azt nem garantálom, hogy ez a frissítés az "apt-get dist-upgrade" parancsot fogja jelenteni (sőt: 1.0-ról 1.1-re biztosan nem, hiszen történt egy-két gyökeres változás, melyeket az apt nem tud magától kezelni).

A béta/rc változatokról történő frissítést nem tervezzük külön támogatni. Ugyanakkor az 1.0 -> 1.1 frissítés lehetősége már valamelyik bétában meg fog jelenni, hogy lehessen magát a frissítési folyamatot is szélesebb körben tesztelni (természetesen nem az élesben használt 1.0, hanem egy tesztelés céljából telepített 1.0 rendszer frissítésére gondolok).

Na akkor nehany megjegyzes, hogy honnan ered ez a "TMK". Marmint a kozelmultbeli felbukkanasa...

Szoval mar jonehany honapja (iden tavasszal) "megalapult" a SuSE-TMK nevu tarsulat, akik elsosorban csomaggyartassal foglalkoznak.

Van egy allitolag privat levlistank, amely egy idoben publikussa valt :) Ezt kihasznalva az UHU-s fiuk csamcsogni kezdtek rajta... verig sertodtek, miegymas.

Szoval ennek a tiszteletere lett TMK a kodnev :) Most mar en is elmondhatom, hogy tettem vmit UHU-ert :)))

Levelekre link nehany megjegyzessel fentebb talalhato (tnx Oregon).

Amugy ez a project valoszinuleg egy honapon belul el fog indulni, azaz egy rpm rendszerezo "portal" inditasan dolgozom, amely tartalmazza TMK-s, es sok egyeb szerzo csomagjait...

{asm} (SuSE-TMK)

Kedves nevtelen!

Par "aprosag"-ra felhivnam a figyelmed:

- Az, hogy ez esetleg tenyleg maganlevelezes volt eredetileg (de vegulis megis publikussa tettetek), senkit nem erdekel, es semmit nem valtoztat azon, hogy itt a levelek tartalmaval, az azokban megfogalmazottakkal, illetve az egyeb mogottes szandekokkal van a baj. Feltetelezem, hogy ezt te is nagyon jol latod, viszont akkor nem ertem miert probalod ezzel a primitiv szoveggel eltussolni...

- Az UHU csapat, illetve az UHU-Linux Kft. nem kovetett el semmi torvenysertot vagy barmi ehhez hasonlot. Jo lenne viszont ha atgondolnad, hogy az alaptalan vadaskodas minek minosul...

- A suse disztribuciot nem hasznalom, nincs is vele semmi bajom. Viszont A magyarorszagi kepviselet, illetve a hozzajuk kozel allo tovabbi tmk levlista tagok azt hiszem szepen bemutatkoztak (Tisztelet a kivetelnek!). Ja, es elarulom neked, hogy szoktam tudni ha az uhu haza tajan szoba kerul a suse, de eddig ket es fel ev alatt osszesen nem fordult elo annyiszor mint a tmk levlista masfel honapja alatt.

Egy kedves mondas jut eszembe: "Vegyel vissza kisnyuszi, mert kisodrodsz a kanyarban!"

--

pozsy / UHU

Vegigolvasva a cikket es a hozzaszolasokat van par eszervetelem:

1. UHU Team: a kerdesem az lenne, hogy varhato-e valamikor, hogy az UHU Linux csomagkezelese beall egy vegleges verziora? Ugyanis ez a mostani allapot (allando valtozasok) nagyon nem tesznek jot az UHU Linuxnak.

2. A beta verziokra miert nem tervezitek a csomagkezelo valtoztatasakor az atmenetet a korabbi verziokrol? Ezzel sokkal gordulekenyebb lenne a hasznalat, ezaltal nektek is tobb info jutna vissza.

3. Hozzaszolok: mondhatom szep kis kozosseg... Egymas szemet kikaparnatok ahelyett, hogy osszefognatok es tennetek vmit az open source feeling Magyarorszagon torteno elterjeszteseert - teljesen mindegy, hogy ez csomagforditas vagy egyeb. Igy ne is varjatok, hogy olyan dolgok tortennek, mint amirol mar szot ejtett ez az oldal (pl. Becs, Munchen).


Akinek nem inge, stb...


Uff, en beszeltem.

Szia nevtelen!

(Tok jo, hogy meg a neved sem vallalod fel...)

- Nem publikaltunk semmit, legfeljebb url-t kozoltunk.

- Persze hogy azt irsz amit akarsz, senki nem mondta hogy nem tehetned. Ez meg a nyilt levelekre is igaz, bar tobb megszoritassal. Nem azzal van a baj, hogy nem irhatnal azt amit akarsz, hanem (mint ahogy mar irtam) a hozzaallasotokkal es gondolkodasotokkal! (Ami mellesleg csak art a hazai linux terjedesnek.)

- A multkor egy darab levelre sikerult raeroltetnetek a "suse fikazas"-t. Elarulom neked, hogy tenyleg elofordul ilyen a listainkon, de ha nem tunt volna fel, azt is elarulom hogy ez nem tolunk ered, es igyekszunk elfojtani oket. Ez epp ellentetes a ti "zart" listatokon tortentekkel.

- A listank neve amire utaltal: "csevej".

1. Eloszor 1az1be .deb, majd valtozas, ezutan nemlehetett hasznalni a "hekkelt" .deb csomagokat, majd mostis egy valtozas. Szerintem nem egesseges.

2. Na ez a baj. :) IMHO (es ez tenyleg az en szubjektiv velemenyem) ugy egesseges egy kiadas, hogy mar megvan hozza az atallas lehetosege egy korabbi, esetlegesen nem kompatibilis verziokrol a gordulekenyebb atallas.

Egyebkent meg jo munkat, elismeresem az eddigi munkatokhoz.

1. Brrr. Tenyleg nem ertelek. A csomagok formatuma mindig is pontosan ugyanugy .deb volt, ez nem valtozott! A problemak abbol adodnak, hogy a dpkg+apt bizonoyos dolgokat keptelen kezelni, pl szimlinkek atalakulasa file-a, vagy forditva.

2. Szerinted hany ember van, aki a mostani stabil 1.0-jat akarja elesben kiprobalni az uj betat, illetve a betas upgrade scriptet? :)

"Ezzel az a baj, hogy bajt keverni mindíg könnyebb!

Nagy arc kell ahhoz, hogy UHU 1.1 beta hírre SuSE-TMK-t emlegessen. A stílus, az életérzés valóban mutatja a SuSE-TMK archivumban olvasottakat.

Ha a közösség nem elég erős, akkor mindíg lesznek ilyen bajkeverők. (SuSE, SuSE über alles!)"


Erre az engem ismerok tudjak, mit szoktam valaszolni:

A verekedes nem ugy kezdodik, hogy valakit megutnek. Eddig csak veresrol van szo. A verekedes akkor kezdodik, amikor visszautnek.

Ha valaki teged pocskondiaz, akkor a legjobb megoldas az az, ha szora se meltatod. Elobb-utobb vagy komolyabbra fordul a vita, ekkor erdemlegesen is vissza tudsz szolni, vagy magatol elcsitul az illeto, leven hozza se szol senki. Ez utobbi gyakrabb.

>..über alles!)

ezeket keretik mellozi, mert mas jut rola eszembe. koszonom.

Mar vagy kozel 50 db rpm itt figyel a vinyomon, csak perpill nincs meg kesz hozza a webes felulet.

Es ebbol kovetkezik, hogy nem irtam linket sem...

- A SuSE a Linux Microsoftja!

Ilyen beszolasok utan szidjatok TMK-t ? ugyanmar...

Ugy latom akkor egyetertunk abban, hogy legjobb ha mindenki elolvassa maga az idezett TMK archivum-reszleteket, es utana maga itelkezik. Ha akarja, nyugodtan vesse ossze a http://lists.uhulinux.hu/ cim alatt talalhato uhu levlistak archivumaival. Mi nem zarjuk be oket, nem fenyegetozunk btk-val stb, mert nincs takargatni valonk.

Imho megoldható: tfh adott egy pistike csomag, amiben volt egy szimlink, ami fájlá változott, vagy vica versa. Akkor készítsetek egy pistike-common-t, amiben kvázi nincs semmi, viszont a postinst scriptjében megcsinálja a szükséges takarítást a változott fájlt illetően. Az új pistike csomag pedig Pre-Depends pistike-common.

Egyébként, meg ha valami miatt új apt kellene, még a frissítések előtt, hát nabumm... Debian rilíz nótában is láttunk már olyat, hogy azt javasolták, hogy upgrade előtt libc-t, dpkg-t, meg apt-ot frissítsünk, utána meg mehet, az apt-get update && apt-get dist-upgrade

BTW.: Debiján Rilíz Nótában már olyat is javasoltak, hogy ne apt-get dist-upgrade-del frissítsünk, hanem dselect-tel, mert az korrektebbül dolgozik.

Ezeken imho megérné elgondolkodni, és olyan irányba terelni a fejlesztést, hogy mégis megoldható legyen az upgrade.

Egyszer már vért izzadtam 1.0-rc1 -ről 1.0-rc2 -re upgrade-kor...

Légyszi ne tegyétek mégegyszer ezt velem, mert akkor inkább szenvedek további x órát az r=1 usernél is, és rakok neki is debiant...

SUSE-TMK-val kapcsolatban meg, hagyjátok az asm és egyéb anonymous moron féle hozzászólásokat... Nem kell velük foglalkozni, imho elég nevetségesen lejáratják magukat a hozzászólások nélkül is... És ahogy látom, semmi közül hivatalosan a SUSE-hoz, tehát bármi amit tesznek, egy haveri kör, akinek nincs jobb dolga mások fikázásánál, ellenben ha piszkálni kezditek őket, akkor még a suse is nektek eshet a hülye névhasonlóság miatt...

gyu: a pistike-common javaslatoddal kapcsolatban:

Egyrészt: Az /usr/X11R6 az 1.0-ban egy könyvtár, több tucat csomag pakol alá valamit. Az 1.1-ben az /usr/X11R6 egy szimlink. Ezt oldd meg légyszi apt-vel.

Másrészt: szeretnénk a disztribtől élesen elkülöníteni a az előző változások inkompatibilis vonásainak jeleit. Nem szeretnénk látni egy csomagot az 1.1-ben, amire az 1.1 puszta működéséhez egyáltalán nem lenne szükség, pusztán az 1.0-ról frissítést segíti. Látjuk, és például Debian bugtrackerben is leírták a Debian fejlesztők, hogy bizony számtalanszor előfordul, hogy ismert hibát csak azért nem javítanak, mert inkompatibilitást eredményezne a régebbi kiadásokkal. Ezt nem szeretnénk. Az elsődleges cél, hogy az 1.1 legyen annyira jó, annyira egyszerű, átlátható, letisztult, gánymentes, amennyire csak lehet. A frissítés menete maximálisan ennek van alárendelve, ha megy apt-vel akkor azzal, ha nem akkor nem. Most épp nem megy.

Egyébként épp te írtad, hogy a Debian fejlesztői is néha ajánlják hogy trükkösen frissíts (dselect-tel vagy először pár csomagot felrakva). Ha ilyen infókra, a frissítés rejtelmeire vagy kíváncsi, a dev listán mindig megkapod a részleteket. Ha az 1.0-ról a végleges 1.1-re fogsz átállni, akkor szakértőknek szóló frissítési dokumentáció helyett egy működő frissítő programot fogsz kapni (amely szkriptben természetesen körülbelül minden második parancs dpkg vagy apt lesz, megfelelő sorrendben stb...) Mi ezzel a gond?

iron: ahogy pozsy is írta, én sem értem első két kérdésedet.

Mindkét kérdésedben említed a csomagkezelő változását. A csomagkezelő nem változott (csak igen apró, szinte elhanyagolható mértékben), maguk a csomagok változtak lényegesen, némelyikük inkompatibilis módon.

Az 1.1 sok csomagban újabb az 1.0-nál, egy ilyen történet során elkerülhetetlen, hogy eltűnik régi csomag, megjelenik új, egyik fájl átköltözik egyikból a másikba stb. Egyszerűbb esetekben a dpkg/apt képes az ilyeneket befrissíteni, bonyolultabb esetekben már nem. gyu-nak már írtam az előbb: az elsődleges cél az, hogy az 1.1 önmagában a lehető legjobb legyen. A frissítés ennek alá van rendelve. Az 1.0-val való kompatiblitás nem szempont, felemás csomagokból összerakott félig 1.0, félig 1.1 rendszereket egyáltalán nem támogatunk, aki 1.0-ról 1.1-re frissíteni akar, annak pedig ez menni fog, ne izgulj, megoldjuk. Ha 1.0-ban egy fájl az X csomagban volt, de rájöttünk, hogy az Y-ban a helye, akkor egy pillanatig sem gondolkozunk az 1.0-val kompatibilitáson meg frissíthetőségen, hanem egyszerűen átrakjuk Y-ba, ez szerintem így van rendjén. Arra most tippelni sem tudok, hogy az 1.1 és az utána jövő kiadás során hány alkalommal fog ilyen történni.

A beta kiadásnak csakis a tesztelés a célja, nem az éles használat. Lesz olyan bétánk, amelyikkel már lehet 1.0-t frissíteni, de ennek sem az lesz a célja, hogy az 1.0 rendszeredet befrissítsd 1.1betaX-re és használd boldogan, hanem az, hogy magának a frissítésnek a menetét is tesztelni lehessen.

Mar bocs, de erre megint reflektalnom szukseges.

SUSE-TMK-val kapcsolatban meg, hagyjátok az asm és egyéb anonymous moron féle hozzászólásokat...

Kerdem en, irtam en ehhez a cikkhez nem megfelelo hozzaszolast? Ha igen, akkor melyikkel van gond?

Ha nem, akkor legyszi ne altalanosits.

Az Anonymous hozzaszolohoz meg semmi kozom... (legalabbis nem tudok rola)

Nem kell velük foglalkozni, imho elég nevetségesen lejáratják magukat a hozzászólások nélkül is...

Ezt gondolom a levelezes elolvasasa utan allitod. Irtam en (Toth Ferenc) ott barmi durvat?

A tobbiekert nem felelek :) De ugy tudom, hogy mindenki vallalja az elhangzottakat...

És ahogy látom, semmi közül hivatalosan a SUSE-hoz

Pontosan. Lehet hogy UHUsok nem hiszik el, de en meg egy fillert sem kaptam SuSE-tol, sot meg SuSE Mo. taggal sem talalkoztam szemelyesen...

bármi amit tesznek, egy haveri kör

Igen. A levlista stilusa is ebbol ered. Mivel szuk tarsasag, es levlista nem publikusnak hitt volta miatt az emberek nem valogattak meg szavaikat. Nem fogalmaztak szepen, kerek mondatokban. Ez kb. olyan mint egy kocsmai beszelgetes.

akinek nincs jobb dolga mások fikázásánál

Ezt tok jo, hogy mondod. A mai estem is PHP kodolassal telt az opensource kozosseg tamogatasa erdekeben.

Tudom, perpill TMK-nak semmi latszatja nincs, de majd lesz hamarosan. Mivel idaig szinte mindent egyedul csinaltam (rpm-ek, honlap), lehet hogy kivalok belole. Ez meg nyilt kerdes...

Masik dolog meg az, hogy en sem ertek egyet minden TMK-s megnyilvanulassal. Szoval kezelhetnetek ezt a dolgot vmivel szemelyesebben is. Nem szeretnem, ha barmifele tevekenysegem soran allandoan TMK-val azonositanatok...

Ha gondolod a tobbit maganban. Van itt a hup-on ilyen uzenetek ficsor.

Feljebb mar irtam: semmi bajunk a suse disztribucioval, es tavol alljon tolunk a fikazasa. A problema a magyarorszagi iroda es a tmk levlista egyes tagjaival, illetve hozzaallasukkal van.