UHU-Linux 1.2-beta0 (Herkules)

 ( trey | 2004. szeptember 13., hétfő - 17:18 )

Figyelmeztetés
-----------------

Az UHU-Linux 1.2-beta0 egy fejlesztői verzió, munkapéldány, tehát nem stabil
disztribúció. A rendszerrel kapcsolatban ennek megfelelően semmit sem
garantálunk. Erről részletesebben olvashatsz FTP szerverünkön az iso
image-ek lelőhelye melletti README fájlban, valamint a telepítés
megkezdésekor.Letöltés
---------

Az UHU-Linux 1.2-beta0 az alábbi címekről tölthető le:
ftp://ftp.uhulinux.hu/uhu/dev/1.2-beta0/
http://download.uhulinux.hu/uhu/dev/1.2-beta0/
rsync://rsync.uhulinux.hu/ftp/uhu/dev/1.2-beta0/

A második CD egyelőre nem tartalmaz érdemleges csomagokat. Azoknak ajánljuk,
akiknek az első CD bootolásával gondjuk akad. Az esetleges ilyen eseteket
kérjük, jelezzétek nekünk!

Főbb változások az UHU 1.1 óta
------------------------------------

Természetesen számtalan verziófrissítés, hibajavítás történt és számtalan új
szolgáltatás került bele a disztribbe. Ezeket képtelenség volna mind-mind
felsorolni, így csak a leglényegesebbekre térünk ki.

A rendszer ezentúl a 2.6-os kernelen alapul. A glibc változásának (lásd
lejjebb) mellékhatásaként 2.4-es kernel nem képes futtatni az új UHU
csomagjait, így a 2.4-es kernel használatát a legkisebb mértékben sem
támogatja a disztribúció.

A dev fájlrendszer tartalmát a korábbi devfs helyett az udev rendszer kezeli.

Az ide-scsi modul helyett az ide-cd modult használjuk, így CD-íráskor
például a cdrecord programban ATA:1,0,0 típusú azonosítóval kell az eszközre
hivatkozni.

A glibc-ben a többszálúság támogatására szolgáló ősrégi LinuxThreads
könyvtárat, mely minden szálat külön processzben hajtott végre, kicseréltük
a 2.6-os kernelben újonnan megjelent kernel szintű szálazás lehetőségeit
kihasználó NPTL-re. Ennek eredményeképp 2.4-es kernellel a disztribúció
csomagjai sajnos nem futtathatók. Ez nemcsak a fő rendszerre van hatással,
hanem értelemszerűen tetszőleges chroot rendszerre is, így például az
uhubuild sem képes 2.4-es futó kernel esetén a leendő UHU 1.2-höz illeszkedő
csomagok elkészítésére.

Az új glibc újabb POSIX verziót definiál, amely bizonyos rendszerprogramok
esetén elutasítja a régi típusú argumentumok haszálatát. Többek között az
alábbi programok érintettek:
Elavult használat -> Javasolt használat
head -10 -> head -n 10
tail -5 -> tail -n 5
tail +3 -> tail -n +3
sort +2 -> sort -k 3
sort +2 -5 -> sort -k 3,5
nice -19 -> nice -n 19
nice --20 -> nice -n -20
Az elavult használati módok ezen programok esetén még működnek, de
figyelmeztetést írnak ki. Ajánlott saját szkriptjeinket minél előbb átírni,
ugyanis más disztribúciók, illetve későbbi UHU verziók esetén a régimódi
kapcsolók már nem fognak működni. Egyes jóval ritkábban használt programok
esetén már most sem működik egy-egy elavult opció, a program kiírja a
helyette használandó szintaxist. Megjegyzendő, hogy mindezen programok
rávehetők a régi módon, figyelmeztetés nélkül történő működésre a
_POSIX2_VERSION=199209 környezeti változó beállításával.

A sleep parancs immár képes tört másodpercet is várni, a parancssorban a
törtszámot a használt nyelvtől függetlenül tizedesponttal kell megadni. Az
usleep parancsot idővel el fogjuk távolítani, erre már most figyelmeztet.

A gcc programot beállítottuk, hogy alapértelmezésben az i586 architektúra
utasításkészletét használva, i586-ra optimalizálva fordítson (vagyis
-march=i586 -mcpu=i586 az alapértelmezett érték, de ez természetesen
parancssorból felülbírálható). Ezzel összhangban a disztribúció legtöbb
csomagját is így optimalizáltuk.

Az XFree86 grafikus felületet lecseréltük XFree86-ről a dinamikusabban
fejlődő, más disztribúciók által is kedveltebb X.Org-ra.

Az X immár közvetlenül kezeli az egeret, nem a gpm-en keresztül.

A Grub rendszerbetöltő is sok téren fejlődött. Egyik nagy újdonsága a CD-ről
bootolás lehetősége. Sajnos a CD lemez tartalma csak akkor érhető el, ha
onnan bootolt a rendszer. A telepítő CD-n a korábbi isolinux (syslinux)
betöltőt lecseréltük tehát a jóval rugalmasabb Grub-ra.

A rendszerbetöltő grafikus felülete immár futás közben váltható angol és
magyar nyelv és billentyűzetkiosztás között, a telepítő indításakor
beállított érték a telepítőre is vonatkozik.

A menu.lst fájlban a korábbi cp852 helyett UTF-8 ékezetkódolást kell
használni, amennyiben magunk kívánunk ékezetes szöveget felvenni és azt a
rendszerbetöltő grafikus képernyőjén ékezethelyesen látni szeretnénk. Sajnos
ezek a bejegyzések szöveges módba váltás esetén meglehetősen
olvashatatlanok, mivel a szöveges mód a PC alapértelmezett cp437 kódolását
használja. Az UHU által alapból létrehozott bejegyzések mind angolul
szerepelnek a menu.lst-ben (például Memory Test), ezeket a grafikus
képernyőt megjelenítő program fordítja le magyarra.

A grafikus betöltő által használt témafájl az UHU 1.1-gyel inkompatibilis
formátumú.

Az eszközök automatikus csatolása a korábbi /mnt helyett a /media könyvtár
alá történik. A /media könyvtár alatt ramfs fájlrendszer található, így az
itt létrehozott plusz könyvtárak vagy fájlok a rendszer újraindítása során
elvesznek. Ezért a kézi csatolások számára továbbra is az /mnt-t ajánljuk.

A Gnome grafikus környezetet frissítettük 2.6-os verzióra. Ez a változat a
korábbi tegeződő formával ellentétben magázza a felhasználót, mint ahogy az
UHU-ban egyre több helyen mi is ezt a formát használjuk.

Grafikus belépés esetén UHU 1.1-ben a grafikus rendszer PATH változója nem
volt helyesen beállítva, így például Gnome-ban vagy KDE-ben az Alt+F2-t
követően beírt parancsot, vagy egy ikon által indított programot másmilyen
PATH mentén kereste meg a rendszer, mint a terminálban indított programot.
Hasonlóan például nem-interaktív ssh belépés esetén is hibás PATH állítódott
be. A PATH beállítását a shellből áthelyeztük a PAM autentikációs rendszerbe
a pam_envfeed.so modul, /sbin/pam_envfeed szkript és /etc/envfeed.d könyvtár
használatával. Így most már mindenütt ugyanazt az értéket kapja a
felhasználó.

A PATH beállítás eredményeképpen a sima "su" parancs a rendeltetésének
megfelelően csak root jogosultságokat nyújt, nem root környezetet, vagyis a
korábbi UHU disztribúciókkal ellentétben a PATH változót nem állítja át, így
a /root/bin, /sbin és /usr/sbin könyvtárak sem kerülnek bele, viszont ennek
megfelelően például a /home/felhasználó/bin sem kerül ki belőle. A "su -"
parancs nyújt rendszergazdai környezetet, ez átállítja a PATH-t is. A sima
"su" parancsra a régi viselkedés (PATH beállítása) elérhető az /etc/pam.d/su
fájl megszerkesztésével, vagy a shell inicializációs fájljaiba a PATH
beállításának visszarakásával.

A dhcp kliens immár csak akkor írja felül az ntp konfigurációs fájlját, ha
kapott ilyen adatot a szervertől.

Az UTF-8 karakterkészlet támogatása terén a következő főbb változások
történtek:
- A kernel a VFAT és hasonló fájlrendszereken a fájlnevek ékezeteit ezentúl
nem Latin2-re, hanem UTF8-ra alakítja.
- Új program, a ttyconv került bele a disztribúcióba, amelyik egyfajta
karakterkódolású terminál fölött másmilyen kódolású terminált emulál.
- A joe szövegszerkesztő új verziója már képes UTF8 kódolású fájlokat
szerkeszteni. Megjelent egy újabb terminálban futó UTF8-képes
szövegszerkesztő is, az ne (nice editor).
- A tetex-unicode csomaggal elérhető az [utf8]{inputenc} modul, mellyel
UTF-8 karakterkészletű LaTeX fájlokat tudunk lefordítani. A csomag csak
ideiglenesen van jelen a teTeX 2-es verziója mellett, a 3-as teTeX
hivatalosan is tartalmazni fogja az UTF8-támogatást.
A most készülő UHU 1.2 a terminálokban még Latin2 kódolást fog használni,
UHU 2.0-ra várható az UTF-8 terminálra történő átállás.

A grep programban a --color=auto opciót alapértelmezetté tettük, így
amennyiben terminálra ír, a találatot színezi. A GREP_COLOR környezeti
változóban állítható be a szín, melyet például az /etc/env.d könyvtár alatt
egy újonnan létrehozott fájlban állíthatunk be. A változó értéke az ANSI
escape-szekvenciának a tényleges színkód része, például:
GREP_COLOR=0 -> nem színez
GREP_COLOR=1 -> fényes
GREP_COLOR=1;33;42 -> zöld alapon világos sárga, stb.

Az alábbi főbb csomagátszervezések történtek:
- modutils -> module-init-tools
- devfsd -> udev
- xfree86*, fonts-xfree86* -> x.org*, fonts-x.org*
- a gcc-ből külön cpp nevű csomagra robbantottuk az előfeldolgozót
- a python csomagból a tk támogatás külön python-tkinter csomagba került át
- a fetchmail-ből külön fetchmailconf csomagba került át ez a program
- rsync-fuzzy megszűnt, az rsync tartalmazza a --fuzzy opciót
- mrproject, libmrproject -> planner
- libpopt, libpopt-dev -> popt, popt-dev
- gimp2 megszűnt, a gimp csomag a program 2-es verzióját tartalmazza
- enlightenment: a témák külön enlightenment-theme-* csomagokba költöztek
- quanta -> kdewebdev

Az uhubuild használói egy főbb változással találkozhatnak: a ccache
tartalmát ezentúl nem ömlesztve tároljuk, hanem lefordított csomagonként
külön .tar.gz-ben. Habár van néhány hátránya is az új megközelítésnek,
kétségtelen előny a jobb karbantarthatóság, hiszen magunk is könnyedén
törölni tudjuk egyes csomagok ccache-ét, valamint az uhubuild rendszer is
egy csomag sikeres újrafordításakor törli a régi, nem használt ccache
fájlokat.

Ismert főbb hibák
--------------------

A telepítő és az UHU vezérlőpult a grafikus kártya beállítása során
mindegyik videokártya számára a vesa modult javasolja az eszköz igazi
meghajtója helyett.

Az uhu-automount egyelőre csak a leválasztható eszközöket csatolja (floppy,
CD, usb adattárolók stb.), a merevlemezek egyéb partícióit nem.

A /dev könyvtár alatt több eszköz jogosultsága még nincs megfelelően
beállítva.

Soros egerek kezelése nincsen megoldva.

Korábbi UHU verzió frissítése egyelőre nem támogatott, kizárólag friss telepítés.

Az ISO image nagyobb 650MB-nál, nem fér rá 74 perces CD-re.

Visszajelzések
-----------------

A fejlesztést konstruktívan elősegítő észrevételeket, hibabejelentéseket a
dev@uhulinux.hu listára várjuk. Kérjük, levél küldése előtt győződj meg
róla, hogy mondanivalód korábban még nem hangzott el. A listára
feliratkozni, archívumát megtekinteni a lists.uhulinux.hu címen lehet. A
máshova (például webes fórumokba vagy másmilyen levelezési listánkra)
küldött hibabejelentéseket nincsen kapacitásunk követni.

A dev@uhulinux.hu levelezési lista a fejlesztés fóruma, komoly hangvételű
lista. Nem a fejlesztőkkel való bájcsevegés színhelye és nem is a fejlesztői
verzióval kapcsolatos felhasználói kérdések tárháza. A rendszerrel
kapcsolatos egyszerű felhasználói kérdésektől kérünk, kímélj meg minket!

A kezdo@uhulinux.hu a stabil UHU-Linux rendszert használók fóruma. Jelen
fejlesztői verzióval kapcsolatban semmiképpen ne írj arra a listára!

Köszönjük figyelmeteket:

Az UHU-Linux csapat

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ő.

hupról csak én nemtom letölteni? :S

A titok nyitja a DNS :-)
(nem az a HUP ami annak latszik)

igen, gondoltam :D
thx, mostmár műxik

Van itt amit en nem ertek:

A glibc-ben a többszálúság támogatására szolgáló ősrégi LinuxThreads könyvtárat, mely minden szálat külön processzben hajtott végre, kicseréltük a 2.6-os kernelben újonnan megjelent kernel szintű szálazás lehetőségeit kihasználó NPTL-re. Ennek eredményeképp 2.4-es kernellel a disztribúció csomagjai sajnos nem futtathatók. Ez nemcsak a fő rendszerre van hatással, hanem értelemszerűen tetszőleges chroot rendszerre is, így például az uhubuild sem képes 2.4-es futó kernel esetén a leendő UHU 1.2-höz illeszkedő csomagok elkészítésére.

Miert kell emiatt 2.4 supportot teljesen kiirtani? Mas disztribuciok gond nelkul megoldottak, hogy 2.4-es kernellel (sot, 2.2-vel is) is menjen libc, megis legyen NPTL (lasd pl Debian).

Két válasszal tudok szolgálni.

Az egyik: az UHU nem egy "rakd össze magadnak" típusú disztribúció, hanem egy "mi összerakjuk neked" típusú. Akinek 2.4-es kernelre van szüksége, annak az UHU 1.1-et ajánljuk, és az UHU 1.2 meg az UHU 2.0 megjelenése után is az UHU 1.1-et fogjuk ajánlani neki (esetleg tök más disztribet).

A 2.4-es kernelt nemcsak az nptl miatt nem támogatjuk, hanem mert számtalan egyéb vonzatot is átállítottunk. Az eszközkezeléstől (devfs vs. udev) a hardverdetektáláson át az egerek kezeléséig (/dev/input/mice, inputattach), modulok betöltéséig (module-init-tools) stb. kismillió dolgot át kellett állítanunk a disztribben, mert a 2.6-os kernel az adott szempontból jobb, rosszabb (ez hál'istennek ritka), vagy éppen csak más. Lehet, hogy debian kaliberű disztribúciónak van kapacitása ilyen kardinális kérdésekben alternatívákat nyújtani a felhasználók számára, mindegyiket megírni jóra, mindegyiket tesztelni és teszteltetni rengeteg emberrel. Nekünk nincs. Az UHU nem erről szól. Mi a 2.6-os kernelt jobbnak tartjuk a 2.4-esnél, az udev-et jobbnak a devfs-nél, a sysfs egy nagyon jól használható állatfaj, így aktívan építkezünk rá amióta tudunk. Előrefele lépünk. És ezzel egyáltalán nem vagyunk egyedül, szinte mindegyik céges fejlesztésű disztrib ezt a hozzáállást követi. Jó, némelyik egy-egy apró komponens (pl. libpthread) terén nyújt alternatívákat, régi verziót egy átmeneti időszak erejéig, de előbb-utóbb eldobja. Mi sajnos azonnal eldobjuk, vagyis hirtelen átállunk, mert nincsen kapacitásunk alternatívák kidolgozására és nincsen tesztelői kapacitásunk egy többféleképp összeállítható UHU minden összeállításának tesztelésére.

A másik: konkrétan az nptl esetén nem sikerült kiderítenem, hogy hogyan tudunk linuxthreads-et és nptl-t is fordítani és futási időben választani közülük. Nyilván kideríthető, megoldható, de úgy tűnt, hogy a teljes problémakör alapos megismeréséhez lényegesen több időt kéne rááldoznunk, mint amennyit (az első magyarázat miatt is) megér az egész. Meg tudnánk csinálni, de helyette azonos idő alatt azonos energiabefektetéssel megcsinálunk tíz másik dolgot, aminek mindegyiknek egyenként több értleme van.

Ha pedig te magad szeretnéd az nptl-t linuxthreads-re visszaállítani, vagy 2.4-es kernelbe nptl supportot patchelni és azt használni, megakadályozni nyilván nem tudunk benne, de remélem megérted, hogy ebben segíteni nincs kapacitásunk.

Az egyik valasz masodik fele mar meggyozobben hangzik, mint szimplan a glibc miatti valtas. Igy mar ertem az indokokat, koszonom!

az nptl/linuxthreads keveres ugyehez csak annyit tennek hozza, hogy gentoo alatt sem csinaltak meg, hasonlo okokbol.

amennyire en nezegettem par hete, a debian/redhat megoldas ugy mukodik, hogy gyakorlatilag ketszer forditjak le a glibc-t, egyszer nptl, masodszor pedig sima linuxthreads tamogatassal es utana /lib/tls ill. /lib/i586 (vagy hasonlo) helyekre installaljak oket. ezek utan futasidoben az ld.so donti el, hogy melyiket kell hasznalni, megpedig a .note szekcio alapjan, ami leirja, hogy milyen minimalis kernel verziora van szukseg az adott libc-hez (tehat ha 2.4-es kernellel inditasz, akkor az ld.so at fogja lepni a /lib/tls-t es helyette a /lib/i586-t fogja hasznalni, automatikusan). az LD_ASSUME_KERNEL kornyezeti valtozoval pedig explicite is ra lehet kenyszeriteni az ld.so-t, hogy egy adott libc verziot hasznaljon.

Igen, valami ilyesmi... csak ezt végigcsinálni a gyakorlatban, rápréselni a CD-re a dupla méretű glibc-t, kitalálni hogy az ld.so-t melyik fordításból kell szedni vagy számít-e ez egyáltalán valamit, kitalálni hogy melyik pthreads kivitelezés header fájljait telepítjük, melyikhez linkeljen alapból a gcc stb... nem egyszerű feladat. Inkább kihagytuk :-) Mivel elvileg abi- és api-kompatibilis a két kivitelezés, így alig okozhat gondot a csere. Állítólag van, ahol gondot okoz, de az uhu csomagjaiban nem.