Gentooról váltanék Archra

Arch Linux

Üdv!

Mint ahogyan azt a cím is mutatja, a jelenlegi Gentoo rendszeremet szeretném lecserélni Archra. A mértet most hagyjuk, nem ez a lényeg, hanem hogy most nagyjából (és itt szeretném kiemelni a nagyjából-t) otthonosan mozgok a Gentoo rendszerében. Viszont a váltás felvet bennem néhány kérdést, lássuk csak:

-Emerge vs Pacman, különbségek, system update stb...
-Mi menedzseli a rendszerbeli beállításokat, Gentoo alatt ez az eselect (itt választok kernel symlinket, video drivert, java-vmet, runlevelek állítgatása)
-USE flagek nélkül az élet? Ha felrakok egy csomagot akkor az húz maga után mindent, vagy hogy mennek itt a dolgok? (pl gentoo alatt volt az mplyer ami nekem vdpau támogatással kellett ezert hozzá adtam a package.use ba a vdpau flagat ez itt, hogy megy?)
-A csomagoknak "van verziója" vagy mindig a legújabb kerül fel? (Hülyén hangzik ne kössetek bele, gondolom értitek mit akarok mondani... :D ) Ha igen, akkor hogy választom ki melyiket rakjam fel? (itt a maszkolásra gondolok, illetve gondolom itt is van stable meg testing stb, ezek engedélyezése és tiltása, hogy zajlik...)
-Elég lesz nekem az AUR a plusz csomagokra? Olvastam ilyet, hogy lehet még pluszba forrásból rakni csomagokat, ha valamit nem találsz? Meg olvastam a yaourtról is, ez olyasmi mint a layman? (ez a rész homályos, világosítsatok fel)
-Ha a config file-ok változnak itt is van ilyen etc-update szerűség, vagy intézi magának a rendszer?
-Gentoo után bonyolultabb lesz a rendszer ki/megismerése, használata vagy egyszerűbb?
-Szokásos mi szól ellene és mellette

Lehet, sőt biztos van olyan dolog amit kifelejtettem, akkor írjátok nyugodtan. Illetve mi lehet olyan ami Gentoo alatt megvan és itt nincs vagy fordítva és mire kell odafigyelni...

( ijanos | 2010. 08. 04., sze – 22:12 )

Ez egy nagyon hasznos mi-micsoda oldal:
http://wiki.archlinux.org/index.php/Pacman_Rosetta

ez meg egy általános összehasonlitás
http://wiki.archlinux.org/index.php/Arch_Compared_to_Other_Distribution…

ez pedig végigvisz az intallon és az alapokon:
http://wiki.archlinux.org/index.php/Beginners%27_Guide
ha ez utóbbin túl vagy már otthonosan kell mozognod.

ha valami érdekel jó esélyel találsz róla infót a wikiben, persze a legjobban akkor jársz ha elkezded csinálni és kérdezel ha valami nem tiszta :)

Az AUR bőven elég lesz plusz csomagokra, lehet nem jött át de az AURban nincsenek bináris csomagok, csak specko bash scriptek (PKGBUILD) amivel te buildheted a kívánt progit. a yaourt egy eszkoz amivel parancssorbol kezelheted az AURt, mert alapból a webes feluleten kell csomagokat vadaszni, letolteni, buildelni. Ide viszont két tanács: először ne használj yaourtot, telepíts pár dolgot kézzel aurból hogy érzed/tudd mi történik ilyenkor. Másodsorban pedig a yaourt egy lassú szar :) ajánlom helyette a packert esetleg a clyde -ot.

( Zaneck | 2010. 08. 04., sze – 22:20 )

Ajánlom a wiki.archlinux.org-ot és bbs.archlinux.org-ot tájékozódásra.

USE flagek helyett configure (./configure --enable-vdpau), itt egy PKGBUILD, amivel az Mplayer SVN forrásból buildelhető VDPAU támogatással, bár a core ágban lévő bináris is azzal érkezik.

Érdemes ismerkedni az Arch Linux csomagkezelő rendszerével, a Pacman-el és csomagépítő rendszerével az ABS-el és a közösségi csomagforrással az AUR-al, amely a csomagépítéshez szükséges PKGBUILD-eket tartalmazza és a makepkg-val. A Yaourt az AUR-nak a CLI frontendje.

A konfigurációs fájlokat a csomagkezelő frissíti, készít másolatot a korábbiakról (.pacsave).

Mindent megtalálsz a wiki.archlinux.org alatt, azaz RTFM.

Ilyen USE flag-szeru mukodesre nincs is semmilyen terv/lehetoseg? Jo lenne neha olyant csinalni, hogy mittudomen valaminek letiltani az ssl tamogatasat, meg ilyenek. Csak emiatt a franc akar kulon csomagot letrehozni.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

lásd lent, miért váltottam gentooról. ok, virtuálgépen még továbbél egy korábbi mentésből, csak desktop nélkül server szolgáltatás teszteléshez:) de már nem használom main rendszerként.
azóta a packages.gentoo searchöt megoldották, de hogyan... google:)
olyan külsősök, mint larry a tehén, jobb szolgáltatásokat nyomnak, mint a hivatalos gentoo szolgáltatások. znurt.org meglepő módon képes volt hetek alatt megoldani a weboldal search bugját.
imho a gentoo egy totál bazár distro, jól mutatja a bazaar erősségeit és hátulütőit. egy hagyományos os projekt már régen szétesett volna olyan kaotikus vezetés mellett, mint ami a gentoonál van. a gentoo mégis működőképes tudott maradni a mai napig. de az is igaz, hogy egy normál vezetéssel nem itt tartana ma a gentoo, hanem az egyik vezető linux disztrib lehetne.
legalább egy rendesen vezetett cég vagy alapítvány kellene mögé, nem olyan ugye, amit majdnem töröltek, mert az alap adminisztrációra is képtelen volt. ha lenne ilyen core szervezet, akkor nem tűnt volna el a gentoo.wiki mert, anyagi és/vagy infrastrukturális támogatást adott volna az ilyen értékes külsős projekteknek. a gentoo.wiki a legjobb linuxos doksigyűjtemény volt. ma már az arch wiki jobb nála.
kell legalább egy katedrális a bazárba.

Elhiszem neked, hogy így van, ahogy mondod, mert nem látok bele milyen alapítvány, milyen vezetéssel, milyen adminisztrációval működik. De ez kb. miben érint engem, mint usert? Az, hogy áramszünet miatt elszállt a rendszered, más Linuxal is megtörténhetett volna. (backupolni kell a fontos dolgokat) Szerintem elég naprakész a rendszer, leírod, hogy mik azok amiket megszoktál, kvázi mit keresel egy új oprendszerben. Miért, kísérletezni akarsz? Azt lehet más gépen is, én is adminisztrálok debiant pl. nemrossz, de Gentoomat nem cserélném le, csak ha muszáj lenne.

itt a hír a gentoo alapítványról, és a cikkben a link a korábbira, amikor visszavonták a működési engedélyt.
az áramszünet már csak az utolsó csepp volt. nem tűnt el minden adat, csak hibák voltak a /usr alatt, több binárist is érintett. helyre lehetett volna kalapálni, de nem volt kedvem akkor már hozzá. és már időt sem akartam tölteni vele. backup volt, az ment a virtuális gépbe. a kde4 csomagok voltak amik, hihetetlenül lassan készültek el, akkoriban lett szétkergetve a kde team. talán még kubuntu is előbb állt elő vele:) kíváncsi vagyok mikor jelenik meg a portageben a KDE4.5.
jelenleg úgy látom egy fő területen musthave a gentoo, a hardened linux kategóriában az egyetlen megbízható szereplő. ahova sok "megbízhatatlan" usert kell beengedni unix shell hozzáféréssel, oda hardened gentoo való:)
egyszer talán majd visszatérek a gentoohoz.

állítólag a 4.5.0 nem is lesz, mert nem elég stabil. Majd 4.5.1... Így magyarázta ki árpi.
Úgyhogy én nem várok, layman -a kde, és már megy is. Egy gépre már felment, hibátlanul lefordult, és úgy néz ki megy is. Most fordul itthon is. Nem tudom miért nincs a hivatalos portageben, mert az ebuildek kész vannak...

( sarkanyolo v | 2010. 08. 05., cs – 06:52 )

Üdv,

1. Az Emerge-t nem ismerem, a Pacman viszont igazán kezes kis jószág.
Gyors, jól kezeli a függőségeket, egyszerű használni és rengeteg dolgot tud.
1,5 éve nekem még nem volt bajom vele.

2. Én nem tudok ilyenről archban. Kernel-t szerintem felesleges magadnak fordítani. Először én is fordítottam, de az Arch elég gyorsan frissül. Nem volt kedvem pár hetente kernelt forgatni. Van LTS kernel is, azt is választhatod telepítésnél. Video drivernél egész egyszerűen telepítéskor kiválasztod azt a drivert, ami a kártyádhoz kell. (Nekem egész egyszerűen fel kellett tenni az "nvidia" csomagot, ez képes volt az Xorg configot is kigenerálni.

3. Amikor felraksz egy csomagot, akkor a Pacman kiír opcionális függőségeket. Pl ha felraksz egy fájlkezelőt, akkor kiírja megjegyzésként, hogy ha felteszed az unrar-t akkor együtt fog működni vele. De nem kötelező feltenni, később is bármikor felteheted, automatikusan érzékelni fogják azok a programok, amelyeknek opcionális függőségük.

4. A rendszer 3 tárolóból épül fel.
Core - szöveges alaprendszer, driverek
Extras - Xorg, gyakoribb programok, Desktop Environmentek
Community - az AUR-ból kiemelt programok, amik elég sok szavazatot kaptak.

Pacman.conf-ban kiválasztod, hogy ezekből a tárolókból a Stable vagy a Testing ágat szeretnéd használni. Visszalépést én úgy szoktam megoldani, hogy nem törlöm ki a Pacman által letöltött csomagokat. Így ha valami nem működik megfelelően vissza tudok downgradelni a gépen lévő régebbi verzióra. Ha a testing ágat használod, akkor pedig egyszerűen átírod a config fájlt Stable-re, és mehet a downgrade. Egyébként, ha a Stable ágat használod erre elég ritkán van szükség. (Nekem 1,5 év alatt kétszer kellett)

AUR-ban általában a legfrissebb verzió van a csomagokból. Gyakran a tárolók által kezelt programoknak is vannak AUR-os változatai, ahonnan a legfrissebb svn-es vagy git-es snapshotot lehet leszedni.

5. Gyakorlatilag amelyik program létezik linuxra, az 98%-ban megtalálható az AUR-ban. Az AUR nem tartalmaz programokat, csak recepteket ,PKBUILD fájlokat. A receptek megadják , hogy hol található a forrás, milyen kapcsolókkal kell lefordítani, mik a függőségek, milyen architektúrára. Ezeket a recepteket a rendszer automatikusan képes értelmezni, ennek alapján elkészíti neked a csomagot, amit ha feltelepítesz, ugyanúgy kezeli a Pacman, mint bármely más csomagot.
Ha valamit esetleg nem tartalmaz az AUR, annak te is írhatsz ilyen receptet, elég egyszerű. Gyakorlatilag minden elérhető Archra, amit forrásból is le tudnál fordítani.
Létezik még az Arch Build System azoknak akik gyakran használják az AUR-t. Soha nem használtam, de ha jól tudom (FIXME) a komplett AUR fát az összes recepttel együtt letölti a gépre, utána bármelyik szabadon fordítható, csak néha szinkronizálni kell.
A yaourt segítségével az AUR-t is úgy kezelheted, mintha egy sima tároló lenne.

6. Erre egy példát tudok mondani. Egy programnak frissült a mirrorlistje. A pacman nem írta felül a saját mirrorlistemet, hanem telepítéskor figyelmeztetett, hogy a frissített config megtalálható ezen az elérési helyen, mirrorlist.pacman névvel. Ha le szeretnéd cserélni, akkor csak átnevezed.

7. Nem volt soha Gentoom. 1 év Ubuntu után tettem fel Archot. Első pár hétben volt időm vele foglalkozni, azóta nem volt olyan problémám amit egy Google és 10 perc alatt ne tudtam volna megoldani.

8. Mellette: Nagy community, nagy csomagválaszték, mindig a legfrissebb stabil verzió, nem kell várni arra, hogy kijöjjön az új release. Szerintem jobb így, hogy naponta 2-3 csomag frissül, minthogy elavulnak a verziók és egy dist-upgrade-el lefrissít 200 csomagot. Ezenkívül gyors és stabil. Ja és az Arch Wiki fantasztikus.

"Kernel-t szerintem felesleges magadnak fordítani."

Ezt had döntse már el magának mindenki. Próbáltál már 855GM-et használni Daniel Vetter patchei és kernelfordítás nélkül?

"Létezik még az Arch Build System"

Az ABS egy komplett toolkit, nem csak az ABS tree, de ide tartozik a PKGBUILD, makepkg, az egész csomagépítő rendszer.

Hogy őszinte legyek, Google nélkül azt sem tudom, hogy a 855GM milyen színű lehet.

Egyszerűen megosztottam a tapasztalataimat, nem szabályrendszert fektettem le.
Hétköznapi használat során nem volt szükségem kernel fordításra, nekem jobban tetszett, hogy mindig friss kernellel dolgozhatok különösebb energia ráfordítás nélkül.

ABS-hez köszönöm a kiegészítést.

Először is nagyon szépen köszönöm a kimerítő választ. A Pacman tényleg elég sok funkciós csomagkezelőnek tűnik és amit eddig olvastam róla az alapján tetszik.

Az eselect-es dolog azért még érdekel mert vannak rendszer szintű beállítások amikor nagyon hasznos ez a kis tool, lehet akkor itt manuálisan állítgatom a dolgokat.

Ha jól veszem ki a szavaidból akkor érdemesebb a stable ágat használni... A package databasenel ilyet látok hogy community-testing és sima testing. Az elsőbe kb 8 csomag van szóval az elhanyagolható, a másodikba 570, ha innen valami stable lesz hova kerül be? A három tároló egyikébe?

( djszapi | 2010. 08. 05., cs – 10:14 )

Szia,

Ha KDE user vagy akkor erdemes inkabb chakra-ra valtani. Regen Arch alapu KDE distrolet-t csinaltunk, mostmar kulon distrot fejlesztunk, ami azert meg hasonlit az archra, de KDE usereknek, developereknek mindenkepp celszeru.

http://djszapi.homelinux.net

Üdv!

Sajnos, vagy nem sajnos gnome user vagyok, már ezt szoktam meg és ezt szerettem meg. De azért köszi a tanácsot, ha váltani akarok majd valamikor, akkor a chakra az elsők között lesz mint lehetséges KDE distro! :)

( Zaneck | 2010. 08. 05., cs – 13:40 )

Lehetőleg próbáld megkerülni a HAL (Hardware Abstraction Layer) használatát és támaszkodj az udev-re, a HAL ugyanis deprecated lett.

GNOME asztali környezettel ez egyszerűen menni fog, de azért odafigyelést igényel, a legegyszerűbb ha feketelistára teszed (/etc/pacman.conf).

Hmm éppen most járok ennél a résznél a wiki-ben:

"The GNOME desktop requires two daemons, FAM and HAL for proper operation."

Gondolom már nem mai iromány, de akkor most ott járunk, hogy az udev teljes egészében el tudja látni a HAL feladatát?

http://www.archlinux.org/packages/extra/i686/hal/

Ott van ugye a gnome-device-manager, gondolom ezt fel kell tennem, ha azt akarom, hogy ha berakok egy cd-t/dvd-t akkor azt egyből felcsatolja és ne kézzel kelljen bohóckodnom? Vagy az udev ezt is megoldja?

http://wiki.archlinux.org/index.php/Udev#Tips_.26_Tricks

Ezt találtam, tehát akkor most ebből az következik, hogy próbáljam meg kerülni a HAL használatát mindenképpen és hagyatkozzak csak az udev-re, vagy...? Ergo ha elindítom a gnome-ot akkor látja e majd a rendszer az újonnan csatlakoztatott eszközöket?

Én így csináltam, működik:

Fam-ot ne telepíts fel. Helyette Gamin. Csak felteszed, automatikusan elindul ha szükség van rá, semmit sem kell vele foglalkozni vagy állítgatni.

A Gnome telepítése előtt feltettem a Hal-at. /etc/rc.conf-ba be kell írni, hogy automatikusan induljon.
Telepítés után elindítod ( /etc/rc.d/hal start ) és innentől kezdve nem kell vele foglalkozni, teszi a dolgát a gaminnal együtt. Nálam több mint egy éve így van, még nem kellett hozzányúlnom.
Tökéletesen működik az automount, az új programok és hardverek észlelése.

Persze ez csak saját tapasztalat. Ha valakinek jobban fekszik az udev konfigolás, tegye.
Engem a wiki oldal picit elbizonytalanít, hogy tényleg az Udev-e a jövő: http://wiki.archlinux.org/index.php/Udev

Korábban a HAL-t az udev-el mergelték, részben pedig az udev-re épülő DeviceKit-el (ami egy udev D-Bus frontend), amit most mergeltek az udev-be. A devicekit-disks udisks, a devicekit-power pedig upower-ként érhető el.

Az udev .rules konfigurációs állományokat használ, a HAL .fdi-k egyáltalán nem voltak kézenfekvőbbek.

És nem hiába mondom, hogy mindenki hanyagolja a HAL-t, méghozzá minél előbb, lehetőleg azonnal, ma már egyetlen alkalmazáshoz sem szükséges.

Nem, a Xorg 1.8 már az udev-et használja.

Van xorg.conf.

01-keyboard-layout.conf vagy az azt is felülbíráló xorg.conf állományban meg tudod adni a billentyűzetkiosztást.

Ha ránéznél a xorg.conf.d tartalmára meglátnád milyen kézenfekvő és egyszerű módon konfigurálható így az X szerver.

Az udev teljes mértékben kiváltja a hal-t.

Az eszközök csatolásához: http://wiki.archlinux.org/index.php/Udev

Arch Linux alatt a a gnome-vfs dependel a hal-ra, javaslom a gnome-vfs-no-hal csomagot az AUR-ból.

Ubuntu alatt egy ideje már nincs hal, az udev-et használja, a gnome-vfs-t pedig --disable-hal-al fordítják.

A --disable-hal a lényeg a PKGBUILD-ban.

Paranoiára a kérdéses PKGBUILD-al kapcsolatban semmiféle okod nincs.
Te vagy nem használsz Arch Linux-ot vagy nem kellene használnod, ha még a csomagépítésről sem tudsz semmit.

A gnome-vfs --disable-hal kapcsolóval is fordítható, Ubuntu alatt is ezt tették feltehetően, mivel a GNOME-nak már nem függősége a HAL.

Elolvastam a PKBUILD-ot, saját kútfőből is rájöttem, hogy mi a lényeg. Viszonylag könnyű helyzetben voltam, mivel az AUR oldalon külön kiemelik.

Amire fel szerettem volna hívni a figyelmedet, hogy roppant fontosnak tartod a HAL lecserélését.
Ha ez az ötlet sokakban felmerült volna, akkor a HAL függőség nélküli gnome-vfs kicsit népszerűbb lenne 2 szavazatnál.

Szeretném megköszönni az operációs rendszer használati tanácsaidat, már töltöm is az edubuntut.

Azon nem kell meglepődni, hogy nem népszerű az udev, vagy, hogy nem a --disable-hal gnome-vfs került be a core-ba, és, hogy a wiki.archlinux.org-on sem szerepel, hogy a HAL deprecated lett és már semmihez nem elengedhetetlen.

Az Arch Linux fejlesztői, karbantartói és felhasználói a megszokott dolgokat kedvelik, a változatlanságot, ezért a hal, ezért nincs scim helyett ibus stb.

Éppen valamelyik Arch Linux fejes nyilatkozta fórumon nemrég, hogy ő azt se tudja mi az az OpenCL, nem is érdekli, és nem is fog bekerülni a core-ban lévő nvidia driverhez ahogy annak lennie kellene.

Ezek ilyenek, de attól még az Arch remek disztró.

Igazabol en sem ertem, miert rossz a HAL es miert jo az UDEV. Annak orulok, hogy a Xorg-bol kiveszik (illetve annyira nem is erdekel, en a HAL-os idokben is xorg.conf-ot hasznaltam), de hogy mas helyeken miert van utban... fogalmam sincs.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( sunmao v | 2010. 08. 08., v – 19:37 )

Van ugye a gnome csoport, ez tartalmaz csomagokat, pl az epiphany. Illetve van a gnome-extra ami tartalmaz számos hasznos csomagot illetve van pár olyan is amire nincs szükségem, a kérdés a következő mikor fel akarom rakni mondjuk a gnome csoporthoz tartozó csomagokat akkor tudok szelektálni valamilyen módon? Vagy szépen meg kell kérnem a pacman-t hogy listázza ki mely csomagok tartoznak a gnome csoporthoz és akkor szépen elkezdem kézzel felrakosgatni ami nekem kell...

Amikor egy csoportot akarsz feltenni (pl gnome-extras) akkor rákérdez, hogy telepíted-e az egész csoportot. Ha N-t ütsz, akkor egyesével rákérdez a csoport tagjaira, hogy szeretnéd-e telepíteni.
Legalábbis, amikor telepítettem a gnome-ot, még így volt (kb egy éve).

Ha csak 1-2 program nem kell, akkor célszerű feltenni az egész csoportot és a végén törölni a szükségtelen csomagokat. ( pacman -Rns epiphany )

( sunmao v | 2010. 08. 09., h – 16:32 )

Van egy kis Xorg mizéria... Most ugye újítottak a fiúk és a xorg.conf ot átrakták a xorg.conf.d-be és szétdobálták külön fileokra. A kérdésem az lenne, hogy akkor ha most mégis van xorg.conf az X11 mappába, akkor megpróbálja azt először betölteni, vagy figyelmen kívül hagyja vagy esetleg betölti ami ott van aztán majd szépen felülírja azzal ami a xorg.conf.d be van? Ezek alapján például ha modulokat akarok betölteni, akkor szépen fogom magam és a xorg.conf.d be létrehozok mondjuk egy 10-modules.conf ot és oda bevágom ezt:

Section "Module"

# Load "dri"
Load "glx"
Load "dbe"
EndSection

Effektíve minden section nek külön file?

szerk: Vagy lehet, hogy hülyeséget beszélek és csak a HAL pótlékoknak van ez a mappa fenntartva és a többi dolgot ugyanúgy xorg.conf-ba kell rakni?

"Since the HAL project has stopped development and deprecated itself, X.Org is planning to move off HAL in the future. Support for udev instead of HAL is available in X Servers 1.8 and later and enabled by default, pending platform availability. As HAL was also used for input device configuration, a new feature has been added to X Server 1.8 to support configuration snippets in the xorg.conf.d directory. Instead of udev rules, users and distributions are encouraged to use the xorg.conf.d for configuration. Old-style xorg.conf configuration is still available."

( uid_14357 | 2010. 08. 09., h – 16:50 )

Én ezt a folyamatot kb 1 éve eljátszottam, párhuzamosan használtam (két gépen) Arch Linuxot (>6-7 hónapig) és Gentoo Linuxot (>5 éve?).
Az Arch Linux a Gentoo után NAGYON fapados! Erre készülj fel. Hozzá lehet szokni a pacman-hez, yaourt-hoz, meg egy raklapnyi szkripthez hogy kb. ugynanazt a funkcionalitást megkapd amit az emerge tud.

A két rendszerben kb annyi a hasonlóság, hogy rolling release mindkettő. Minden másban szvsz különbözik.
A hivatalos wikije szerintem egész jól használható, a Pacman rosettát pedig ajánlom, hogy mentsd le txt-be, mert míg X-et varázsolsz rá, addig nem biztos, hogy kényelmesen eléred a netet :)

De ne legyen igazam! Sok sikert hozzá és használd egészséggel!

--
\\-- blog --//

( uid_16313 | 2010. 08. 09., h – 19:01 )

Helló!

Szórakoztam Gentoo-val régebben, szigorúan amatőr módjára.
Tetszett benne a maximális testreszabhatóság, amiben világelső, máig vallom.
Nem vált belőlem kernel hacker. Igaz, rohadt sok kernelt gyártottam 1 bizonyos vasra, kísérleteztem, optimalizáltam, stb...

No. A vége az lett, hogy eljutottam az alábbi tapasztalatokig:

1. A mindenféle optimalizálás ellenére az én felhasználói szokásaim tekintetében semmi érdemleges különbséget nem tapasztaltam az Archlinux-szal szemben.

2. A linux alkalmazások 99% semmit sem használ ki a fejlettebb CPU-k képességeiből. Gentoo alatt, ha jól emlékszem, pl. az OpenSSH SSE2-re optimalizálható maximum. Ha tévednék, javítsatok ki (már régen volt).

3. Időigényes a rendszer karbantartása, és a ráfordított idő nincs arányban az eredménnyel (még gyors vasakon sem).

4. Rábízom a kernel-t azokra, akik ki tudják hozni belőle a maximumot. Az Archlinux gyári kernele bőven megfelelő, és nem kell napokat eltölteni azzal, hogy egy bizonyos beállításnak milyen előnyei, hátrányai vannak, meg, hogy egyáltalán mire is való.

És az Archlinux.

Én valahogy mindig ennél kötök ki a portyázásaim után. Ennek tetszik a legjobban a filozófiája, felépítése, karbantartása. Valahol számomra ez tükrözi azt a rendszert, ami "igazi" Linux-feeling-et áraszt magából 2010-ben is, és nem akar Windows lenni. Itt is az alapról rántok fel mindent, de binárisan, és az I686-ra optimalizált csomagok vizuálisan nyújtják ugyanazt a sebességet, amit Gentoo alatt a hyperoptimalizált cuccok. Semmi fölösleges beállítás, csomag, csak az, ami tényleg kell.
A Pacman csomagkezelő függőségkezelése messze a legjobb ( na, itt most lehet flame-elni ) amivel eddig találkoztam.
A rendszer friss. Lehet most vitatkozni, hogy az új csomagok nem biztonságosak, és az ezeréves csomagok meg azok, szerintem ez nem igaz. A biztonságot nem a csomag életkora, hanem a javítások megjelenésének gyorsasága jeleni. És ebben a tekintetben az Archlinux az egyik legjobb distro. ( Ezen a ponton is lehet flame-elni :)

Tömören ennyi.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

"A mindenféle optimalizálás ellenére"

Core i7 processzorral, de én már egy AMD Athlon II-vel sem veszem észre a különbséget, de azért korábban egy Pentium M mellett oda voltam érte, hogy le tudtam játszani a 720p-t 10-30%-al nagyobb teljesítménnyel meg a gyorsabb böngészőt, kevesebb bootidőt stb.

Mostmár persze van VAAPI, a korlátot pedig desktop felhasználás mellett az I/O jelenti és a nem megfelelő ütemezők, regressziók stb., a CPU és a GPU a legkevésbé.

Eléggé szomorú a tendencia, az, hogy egyre inkább a brute force felé tolódik el a PC technológia.
A fénysebességgel fejlődő hardvereszközök lehetetlenné teszik a feature-ök maximális, időtálló és kompatibilis kihasználását. Vesszük a versenyautókat, és 50-el megyünk velük városban, mert a szabályok ezt engedik.
Néha már-már úgy gondolom, hogy az egyre bonyolultabb CISC processzorok fejlesztése zsákutca, és a jövő mást tartogat a számunkra.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

A közeljövő a párhuzamosítás és GPGPU stb. kihasználását tartogatja.

A miniatürizálás, a fogyasztás és hőleadás csökkentése koránt sem zsákutca, már most 2010-ben is lehetővé teszi, hogy a tenyeredben hordozz egy néhány évvel ezelőtti asztali számítógép teljesítményével, képességeivel rendelkező miniszámítógépet (Samsung Galaxy S stb.).

Amiről te beszélsz, az a hardverfejlődés iránya. Azzal sosem volt, kisebb-nagyobb zsákutcáktól eltekintve ( pl. Intel P4 ) probléma. A probléma a vasakon futó szoftverekkel van, és én most csak az optimalizáltság hatásfokának tekintetében vallom ezt.

A jelenlegi hardverek képességeinek optimális kihasználása szoftver oldalról erősen megkérdőjelezhető. Az, hogy ez így van, annak számos oka van, nem is szeretnék nagyon belemenni.

Sohasem tudjuk meg pl. hogy mire lenne képes pl. egy Core2-es CPU, mert a mai oprendszerek és alkalmazások a nyers teljesítményen kívül nincsenek ráoptimalizálva úgy, ahogyan lehetnének.

Aki látta anno a Commodore64-et, és azt, hogy mit hoztak ki belőle annak idején a programozók, az tudja, hogy miről is beszélek. Ott is megvolt a szoftverfejlesztés evolúciója. A kezdetleges, szinte karakteres gamékat PÁR ÉV alatt felfejlesztették a Last Ninja színvonalára ( izometrikus 3D ), mindezt úgy, hogy a hardverkörnyezet NEM VÁLTOZOTT. És még sorolhatnám. Egyszerűen manapság a rengeteg vasra nincs idő optimalizálni, vagy csak egyszerűen nem éri meg.
Tömegtermék lett az informatika, és olyan is.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

1. Régen a hardware korlátaival kellett küzdeniük a fejlesztőknek
2. Ma inkább a képzeletük korlátaival

A 2. talán ijesztőbb mert sokkal megfoghatatlanabb, de szerintem egyben sokkal felemelőbb és kreatívabb küzdelem.

A szolgáltatásoknak/absztrakciónak az a foka amire a szoftverek/szoftverfejlesztés eljuthat, legalább olyan jó jelzője pl. a Core2-es képességeinek mint valami puszta és száraz frame/sec érték.

+1

Bár a hardveres korlát is adott, most éppen a Metro 2033 nem megy semmin ami még nem munkaállomásnak tekinthető maximális beállítások mellett és még csak most jönnek a valósidejű ray tracing-et használó alkalmazások.

Optimalizálják a kódot, algoritmusokat ahogy tudják.

Kicsit vitatkoznék ezzel, ugyanis szerintem szépen hangzik, de:

1. Mivel régebben a hardver korlátaival kellett küzdeni ( pl. C=64 ), ott kellett igazán kreatívnak lenni, ahhoz, hogy látványos eredmények születhessenek. 8 biten az optimalizációk csúcsra voltak járatva. Ehhez kellett a valódi szaktudás, tehetség és a többi...

2. Ma nem a képzelet szab korlátot a programozásnak, hanem maga a programozás. Az objektum orientált világban összehányt szoftverek születnek a mindenféle framework-ökön keresztül. Már az sem érti a programot, aki írja ( enyhe túlzással ). Ha igaz volna amit írtál, akkor PC-n élvezetesebbnek, jobbnak, mittumén' kéne lennie pl. a szövegszerkesztésnek, játéknak, bárminek. C=64-en még nem voltak hotfixek, stb...

A feladat elvégzésének tekintetében nem látok lényegi fejlődést. X ideig tart valami. Nem végzek most sem a dolgommal gyorsabban. Több múlik azon, hogy milyen gyorsan gépelek, mint azon, hogy milyen gyors a gépem. A képzelet határait súroló 3D-s gamék meg egy kaptafára épülő unalmas agymosások, amik nem szórakoztatnak, hanem függővé tesznek ( már akit ). A C=64-es játékokban a képzelet és a megvalósítás minősége is maximumon volt. Más világ volt akkor, és más ma. Semmivel sem jobb a helyzet ma, csak más.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( sunmao v | 2010. 08. 10., k – 00:20 )

Nezegettem a logokat es az error.logs ban ezt talataltam:

Aug 9 22:21:27 maoacrh kernel: nForce2_smbus 0000:00:09.1: Error probing SMB1.
Aug 9 22:21:56 maoacrh kernel: end_request: I/O error, dev fd0, sector 0
Aug 9 22:22:08 maoacrh kernel: end_request: I/O error, dev fd0, sector 0
Aug 9 23:58:12 maoacrh kernel: nForce2_smbus 0000:00:09.1: Error probing SMB1.
Aug 9 23:58:43 maoacrh kernel: end_request: I/O error, dev fd0, sector 0
Aug 9 23:58:55 maoacrh kernel: end_request: I/O error, dev fd0, sector 0
Aug 10 00:02:18 maoacrh kernel: nForce2_smbus 0000:00:09.1: Error probing SMB1.
Aug 10 00:02:47 maoacrh kernel: end_request: I/O error, dev fd0, sector 0
Aug 10 00:02:59 maoacrh kernel: end_request: I/O error, dev fd0, sector 0

Ez mit takarhat?

Illetve a dmesgben is:

[root@maoacrh sunmao]# cat /var/log/dmesg.log | grep -A 5 -B 5 nForce2_smbus
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
forcedeth 0000:00:10.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:17:31:70:74:1c
forcedeth 0000:00:10.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3
ACPI: resource nForce2_smbus [io 0x1c00-0x1c3f] conflicts with ACPI region SM00 [??? 0x00001c00-0x00001c05 flags 0x30]
ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
nForce2_smbus 0000:00:09.1: Error probing SMB1.
i2c i2c-0: nForce2 SMBus adapter at 0x1c40
ACPI: PCI Interrupt Link [AMC1] enabled at IRQ 23
forcedeth 0000:00:11.0: PCI INT A -> Link[AMC1] -> GSI 23 (level, low) -> IRQ 23
forcedeth 0000:00:11.0: setting latency timer to 64
nv_probe: set workaround bit for reversed mac addr

A másik, mivel hogy a gdmet teljesen szétgányolták ezért nem szándékozom a továbbiakban hasznalni, úgyis egyedül használom a gépet. Tehát így néz ki a gnome DE indítása:

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

# exec gnome-session
# exec startkde
# exec startxfce4
exec ck-launch-session gnome-session
# ...or the Window Manager of your choice

Illetve az inittaban:

x:5:once:/bin/su sunmao -l -c "/bin/bash --login -c /usr/bin/startx >/dev/null 2>&1" van ez a sor.

Ez szép és jó, de mondjuk tty1 rol inditom a GNOME-ot startx el akkor tele hámyja a console-t egy csomo warningal, azt szeretném megtudni hogy ezek mennyire "normálisak"?

http://pastebin.org/462920 A dbus és a hal ottvan a DEAMON ok kozott az rc.confban, ja és eddig volt a home mappamban egy .xsession-errors és egy .xsession-errors.old ezeket kitöröltem, de mostmár nem hozza létre automatikusan ezeket a fileokat... miért?

Az xsessions fajlokat a DM hozta letre, ha nem DM-bol inditod a dolgokat, akkor ezek nyilvan kimaradnak a szamodra, mert a konzolra hanyodnak ki.

A Gdu a Gnome-disk-utility roviditese, erre probalj meg inkabb keresgelni.

Kernel error: talan ez segit, bar van akinek nem segitett. Egy probat meger, mert fajdalommentes.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Köszi a linket!
Itt azt írják, hogy a bug ártalmatlan szóval én se foglalkozok akkor vele, majd kijavítják valamelyik későbbi kernel verzióba.

Közbe nyomtam egy ilyet, tty1-en hogy startx * 2>startx_error aztán fogtam és elkezdtem nézni tail -f el, ilyenekre hibákat tol, hogy epiphanyban megnézem az előzményeket... Arról nem is beszélve, hogy az indítópultba olyan dolgoakt raktak be a fiúk alapból ami fel sincs nekem rakva, pl Evolution, de ami még viccesebb, hogy a 2.30-ból kihagyták a soundokat mint pl startup sound, ez is látszik a logban, viszont az Indítópultban ott van, a parancs: /usr/bin/canberra-gtk-play --id="desktop-login" --description="GNOME Login"

Én nem tudom, hogy ez figyelmetlenség, vagy micsoda de azért elég idegesítő... Arról nembeszélve, hogy a gdm-et nem lehet használni, mert nem enged beloginolni a saját useremmel és ezt nem én találom ki máshol is írták... A másik, hogy a témáját sem lehet változtatni, se autologint beállítani az egész gdm conf eltünt a 2.30-ból, miért kellett kivenni?? :(

Passz. Fel se rakja a gdmsetup binarist? Mondjuk nekem az arch-csal meggyult a bajom a bugzo X-uk miatt, ugyhogy nekem rogton repult a geprol, de ilyenek mellett egyre furcsabb... Ha lesz idom, csinalok probagepet belole, lehet, hogy csak te vagy peches...
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Tényleg lehet, hogy én csinálok valamit rosszul de itt nem találtam:

[sunmao@maoacrh gnome-osd-0.12.2]$ pacman -Ss gdmsetup
[sunmao@maoacrh gnome-osd-0.12.2]$ pacman -Ss gdm setup
[sunmao@maoacrh gnome-osd-0.12.2]$ pacman -Ss gdm
extra/gdm 2.30.4-1 (gnome-extra) [telepítve]
Gnome Display Manager (a reimplementation of xdm)
community/gdmap 0.8.1-2
Tool to inspect the used space of folders.

És itt se.

https://bbs.archlinux.org/viewtopic.php?id=82089
http://wiki.archlinux.org/index.php/GNOME#Configure

Nagyon úgy fest, hogy kézzel kell állítgatni de tényleg inkább hagytam a francba, bár kicsit elkeserítő... Gentoo alatt ugyanúgy tudid állítani a gdm-et 2.30 alatt is?

Bár AUR-ból le lehet hozzá szedni a gdm2setup-ot de ott még nem járok, hogy az AUR-t meg a package készítést kenjem vágjam... :)

szerk: Leszedtem, elkészítettem a csomagot, felraktam, megy...

( sunmao v | 2010. 08. 10., k – 13:27 )

Akkor most jött el az idő, hogy döntsek... Gnome után:

KDE, LXDE, XFCE

KDE-t már láttam, kis ideig használtam, annyira nem tetszett, viszont a másik kettőről semmit nem tudok?

Menni fognak ezekkel (XFCE,LXDE) a gnome appok? Egy awn-t fel tudok rakni, mert pl annak a deplistjében ott a gconf, gondolom leszedi hozzá, de használni is tudja majd más DE alatt? Ezeknek a DE-eknek vannak saját programjaik, mint DVD író, szövegszerkesztő, stb? Várom róluk a tapasztalatokat...

szerk: GTK+ -t használ mindkettő, feltehetően megválaszoltam magamnak az utolsó kérdést... :)

"Ezeknek a DE-eknek vannak saját programjaik"

http://www.xfce.org/projects/
http://lxde.org/lxde

"Menni fognak ezekkel (XFCE,LXDE) a gnome appok?"

Menni fognak.

Próbáld ki őket, nem vesztesz vele semmit. 


pacman -S xfce4 xfce4-goodies gamin gstreamer0.10-base-plugins
pacman -S lxde gamin

Ha nem tetszenek, eltávolítod őket. 


pacman -Rc xfce4
pacman -Rc lxde

( prygme | 2010. 08. 10., k – 15:02 )

bár nagyjából sejtem az okokat, azért érdekelnének az indokok. miért akarod lecserélni a gentoot?

Mert megunta hogy hegeszteni kell néha (mondjuk én kb. egy éve nem hegesztettem a gentoomat, egyszerűen csak működik napi frissítéssel), mivel azt jól ismeri látja a korlátait.
Most próbálkozik egy másik disztróval amihez f!ngja sincs, de amint látom ezt is hegeszteni kell...

Nagyjából igaz amit GES leírt. Nem tudom, hogy te Gentoo user vagy e vagy éppen most akarsz vele ismerkedni. Amit el tudok róla mondani, hogy az elején elég időigényes megismerkedni vele, illetve belerázódni a használatába, de ha ráérzel utána már nem annyira vészes. Cserébe lesz egy rendszered amit teljes egészében te szabhatsz testre és elég sokat tanulhatsz a Linux-ról. Ha nem csak használni akarod a rendszert, hanem kicsit érteni is hozzá, illetve érdekel a lelkülete a Linuxoknak akkor mindenképpen ajánlom. Viszont, ha gyorsan akarsz működő rendszert amivel nem kell "bajlódni" akkor nem... :)

gentoo user voltam. egy áramszünet miatt megsérült a filerendszer, és nem volt kedvem helyreállítani, mert akkorra már sok bajom volt vele. amikor az 1.4 körül elkezdtem használni, a legújabb programokból voltak ebuildek. friss volt a gentoo, mint egy sid, de a forrásalapúság miatt sokkal stabilabb is. DRobbins távozása után egyre jobban szétesett a gentoo, egyre jobban lemaradtak ebuildek a friss kiadásoktól. KDE4 upgrade történet egy vicc volt. gentoo.wiki eltűnése, packages.gentoo bug, majd "megoldásként" a search kilövése... stb. én ezért váltottam.

egy adott rendszeren fordított program nem fog tartalmazni olyan hw eszközt vagy sw libet tartalmazó kódot, ami egyébként nem található meg azon a rendszeren. egy binary disztribnél meg kell bíznod abban, hogy a bináris csomag összeállítója minden függőséget megfelelően beállított és az adott függő csomagokat karbantartó egyéb maintainerek nem változtattak semmi olyat, ami gondot okozhat. nem véletlenül kell hosszasan fagyasztani és tesztelni, és az sem véletlen, hogy a gyorsan változó SID egyes alkalmazásai néha elcrashelnek. az autoconf egy remek eszköz, de csak adott rendszeren fordítva tudja megfelelően beállítani a fordítás paramétereit. a Gentoo alapelve, hogy ha egy programozó stabilnak minősít egy kódot akkor az használható. nyilván saját rendszerén alaposan tesztelte. de ez csak a forrásra igaz. nem véletlen, hogy bináris disztribek stabil ágába mindig késéssel kerülnek be, az egyébként stabil kiadású programok.
az Ubuntu annyit változtatott a képen, hogy egyes kiemelt programokra kiemelt figyelmet fordít, így pl egy firefoxból általában a legújabb szokott az ubuntu kiadásokba kerülni. de ezt nem olyan egyszerű minden csomagnál megtenni, másrészt a firefoxnak nem olyan vészesek a függősége, harmadrészt a munka oroszlánrészét megcsinálja a Mozilla maga.

Szerintem ebben abszolult nincs igazad. Egyreszt ha nincs valamilyen hardver eszkozod akkor azok a modulok nem toltodnek be, azok a kodreszletek nem futnak le egy programban (ergo nem okozhatnak gondot).
A binaris disztrokban szerintem sokkal konnyebb egy csomag helyes mukodeset ellenorizni, hiszen tudott hogy milyen verzioju libek tartoznak a kiadasba, mik a fuggosegek.
Mig gentoonal tobb verzioja is lehet stabil egy-egy csomagnak, sot egy csomag tobb verzioja is lehet fenn. Mivel a programok kombinacioja hihetetlenul nagy, igy szinte lehetetlen mindent letesztelni, hiszen nincs ket egyforma gentoo installacio.
Szerintem a gentoo fenykoraban okos emberek nagy odafigyelessel allitottak ossze a stabil agat, es ezert volt kivallo minosegu, annak ellenere hogy forras alapu.

"Egyreszt ha nincs valamilyen hardver eszkozod akkor azok a modulok nem toltodnek be, azok a kodreszletek nem futnak le egy programban (ergo nem okozhatnak gondot)."
Ehhhmm... amennyiben a program iroja lekezelte ezt a lehetoseget.
"A binaris disztrokban szerintem sokkal konnyebb egy csomag helyes mukodeset ellenorizni, hiszen tudott hogy milyen verzioju libek tartoznak a kiadasba, mik a fuggosegek."
Miert, a forras alapu disztroknal szerinted csak ugy try-and-fail alapon fordulnak a cuccok? Nem, a csomagkeszito ott is kiteszteli, hogy minek mi a fuggosege - akar olyan szintekre is lemenve, hogy ha a configure kap egy --enable-awesome-feature akkor milyen uj fuggesek keletkeznek. Valamint lehetoseget ad az awesome_feature letiltasara is.
"Mig gentoonal tobb verzioja is lehet stabil egy-egy csomagnak, sot egy csomag tobb verzioja is lehet fenn. "
Itt tobb dolgot keversz. Egyfelol valoban lehet tobb verzioja is egy csomagnak stabil, am ha nincs SLOT beallitas, es az ujabb verziok nincsenek kimaszkolva, automatikusan a legutolso stabil kerul fel. Ha van SLOT beallitas, akkor az adott SLOT-ba tartozo csomag kerul fel, vagy ha meg nincs fenn a csomagnak egy verzioja sem, akkor a fuggosegeknek megfelelo legujabb kerul fel.
Multislotos csomagok eseteben az ilyentol fuggo csomagoknak ket lehetoseguk van: vagy definialjak, hogy melyik SLOT-jatol fuggenek az adott csomagnak.
"Mivel a programok kombinacioja hihetetlenul nagy, igy szinte lehetetlen mindent letesztelni"
Ez egy erdekes dolog. Altalaban igyekszenek a leheto legjobban letesztelni a csomagokat, az alap ugye az, hogy fordul/test lefut, de a mainstrem csomagokat a csomagolok ki is probaljak, hogy megy-e. Illetve van a Gentoo-nak rengeteg onkentes teszteloje, akik a testing agat tesztelik kiadas elott.

Egyebkent, ha valaki stabil agat hasznal, azzal manapsag sincsen tul nagy gond, legalabbis en nem szokom tapasztalni. A gondok mindig ott kezdodnek, hogy valaki elkezdi hasznalni a package.unmask/package.keywords fajlokat. Mert azon a lejton nagyon ovatosan kell haladni, a fek jo mukodese kotelezo elindulas elott.

-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"Egyebkent, ha valaki stabil agat hasznal, azzal manapsag sincsen tul nagy gond, legalabbis en nem szokom tapasztalni. A gondok mindig ott kezdodnek, hogy valaki elkezdi hasznalni a package.unmask/package.keywords fajlokat. Mert azon a lejton nagyon ovatosan kell haladni, a fek jo mukodese kotelezo elindulas elott."

Ezzel viszont szerintem annyi a gond, hogy a stable ágból egy mai user "nem él meg". Illetve lehet eljut egyszer oda a stable ág amikor már annyi csomag lesz, hogy ne legyen szükséged a package.keywords re, de akkor meg már az éppen fejlesztett csomag annyi verziószámmal odébb lesz, hogy azért leszel kénytelen maszkolni az illető mert a stable ben lévő csomag túl régi, sajnos még most ez sem áll fent mert van olyan csomag amiből már kijött 4-5 verzió de még a legelső sem stable. Ilyen alapvető csomag volt szerintem a netbeans java-s resze (talán ant-core) ami most már stable, de nekem még maszkolgatni kellett féléve és ugye azt meg tudjuk, hogy ha egyszer valaki elkezdi szerkesztgetni a package.keywords file-t az lavinát indíthat el... :)
Nem tudom a Gentoo-nál amúgy miszerint fordítanak időt a csomagok tesztelésére, de szerintem van pár mainstraim csomag amit rendszeresen tesztelnek és frissítenek, viszont van pár olyan amit egyszer beraktak testingnek aztán már jóideje ott van a cucc magárahagyva.

Nem tudom, nekem a netbeans az egyetlen mainstream progi, amit keywordolnom kell komolyabban, egyebkent meg csak olyasmit kell keywordolni, ami RoR fejleszteshez kell, tehat baromira nem desktop cucchoz valo. Meg persze a sajat csomagjaimat, az en overlayembe nincs stabil csomag, mert nincsenek teszteloim. Az sokba kerul ugyanis.

Stable Gnome, stable alaprendszer (ok, baselayout-2 meg openrc van, de ugye ezek nelkul is lehet elni), stable kernel, stable python-perl, stable Qt... minden fobb rendszerem stabil, es mukodik kocc nelkul (kopp-kopp).
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

gondolj egy olyan esetre, amikor adott valamilyen voip/im program aminek van egy csomó függősége. kommunikációs protokollok, codecek stb. a többi klienssel való kommunikációért felelős libből kiszedik az IPv6 támogatást, mert a fő fejlesztője problémásnak találja a vonatkozó kódrészt, és az újraírásig kivágja az egészet. a SIDben előfordulhat, hogy az adott libet tartalmazó csomagot karbantartó már újracsomagolja a .deb csomagot, de az voip/im gui klienst tartalmazó .deb még mindig azt a binárist tartalmazza, ami IPv6al lett fordítva. csakhogy a függőségből már eltűnt annak a támogatása, amit a voip/im program gyakori crashekkel honorál. természetesen ilyenkor megy a bugreport és pár napon belül, az aktuális frissítéssel jön a javítás.
Gentoo és más source distrib alatt, az újrafordítás alatt az autoconf érzékeli, hogy a függőségek miatt jelenleg nincs lehetőség ipv6ra ezért kihagyja a voip/ip kliensből is. így eleve stabil binárist kapsz a fordítás után.
vagy egy olyan rendszeren ahol tudod, hogy soha nem lesz szükséged nyomtatásra, kihagyod a cups támogatást, a USE flagek nagyon jók ilyen esetek kezelésére. ha valamelyik programban így nyomtatással kapcsolatos hiba lenne, akár a fő fejlesztő kódja miatt vagy akár egy szerencsétlen patch miatt, az téged nem fog érinteni.

( sunmao v | 2010. 08. 11., sze – 14:52 )

Nagyon szégyenteljes dolog xfce alatt k3b et használni? Megnéztem mik a függőségei, szerintem annyira nem vészes.

cdrdao
cdrkit
ffmpeg >=0.5
kdebase-runtime
kdemultimedia-kioslave
libdvdread >=4.1.3
libmad
libmpcdec >=1.2.5
libsamplerate
libxft
shared-mime-info
taglib >=1.4

Vagy egyáltalán miért mondják azt, hogy ne használjunk KDE libes cuccokat nem KDE alatt? Nagyobb az összeomlás esálye vagy van valami más oka? Sajnos eddig ez a legjobb iró program amit találtam Linux alá, illetve ottvan még a nero de ugye az fizetős, szvsz brasero elég vacak...

Azert, mert egy csomo szolgaltatast elindit a hatterben, ami a sajat DE-d szolgaltatasai melle indul el, vagyis pluszba foglalja a memoriat (KDE alatt ugye ez azert nem gond, mert ott ezek loginkor elindulnak). Egyebkent meg irasra konzolbol is eleg jol lehet dolgozni ;-)
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

El tudok olyat képzelni, hogy az adott szoftver máshogy használja az eszközt, más pufferelési technikát alkalmaz, máshogy van megírva a program stb... Pl ugye azt tudjuk, hogy ha van egy max 52x-en író író, akkor az nem fog folyamatosan 52x en írni hanem változó lesz a sebesség az írás ciklusától függően. Na például ebben is lehet eltérés, ezért szerintem annyira nem evidens az amit mondasz. Illetve volt ilyen furcsaságom nekem brasero-val, hogy 0,3x-an írta végig a DVD-t, nem tudom miért (windows alatt ultra iso-val repesztett)..

Tényleg nem kötekedni akarok, csak kérdezem, hogy akkor az xfburn és a k3b is és a brasero is egy frontend a cdrkit programhoz? A Brasero és a K3b valóban ezt használja, de az xfburn dep listje a következő:

* desktop-file-utils
* gstreamer0.10-base >=0.10.26
* hicolor-icon-theme
* libburn >=0.7.6.pl00
* libisofs >=0.6.28
* librsvg
* libxfcegui4 >=4.6.3
* thunar >=1.0.1-5

Tehát ő a libburn-t használja az íráshoz. Akkor ebből le lehet vonni a következőt, más libek > más implementáció > más sebesség? :)

Viszont ettől függetlenül úgylátszik, hogy mégis a cdrtools os megoldáshoz kell folyamodnom, mert az xfburn sem váltotta be a hozzáfűzött reményeket. Ami abban nyílvánult meg, hogy 3 db DVD-met vágta tönkre... illetve ez így nem igaz mert kiírtam egy filmet DVD-RW re, aztán beraktam asztali lejátszóba, szaggatott. Aztán megint kiírtam akkor is rossz volt, aztán leszedtem egy másik rip-jét a filmnek, az se ment rendesen, majd végül mikor K3b-el kiírtam akkor ment szépen. Ezzel kapcsolatban két kérdésem lenne, cdrtools miért jobb mint a cdrkit és írta hrgy hogy ugye a qt libeket használó K3b "egy csomo szolgaltatast elindit a hatterben, ami a sajat DE-d szolgaltatasai melle indul el, vagyis pluszba foglalja a memoriat". Nah most ez ugye akkor foglalja a memóriát mikor fut a program, tehát addig veszi el a memóriát míg írom a CD-t/DVD-t, azt meg végülis ki lehet bírni, és persze utánna a memória megint felszabadul ahogy bezártam a progit?

( prygme | 2010. 08. 13., p – 14:26 )

DRobbins 2éve kezdett egy alternatív gentoolinuxot, a Fungoot. kezd használhatónak tűnni, lehet hogy kipróbálom. imho jó hatással lesz a gentoora is.

( sunmao v | 2010. 08. 25., sze – 13:03 )

Lassan végül is sikerül az átállás és kezdem megszokni a rendszert...
Viszont még közel sem tökéletesek a beállítások, ezt mutatja az X-em indulása is: http://pastebin.com/6AatLRhR

A configom:

xorg.conf
Section "Files"
FontPath "/usr/share/X11/fonts/100dpi/:unscaled"
FontPath "/usr/share/X11/fonts/100dpi"
EndSection

Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "yes"
Option "XkbLayout" "hu"
EndSection

Section "InputClass"
Identifier "Keyboard Defaults"
MatchIsKeyboard "yes"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

Section "Module"
# direct rendering infrastructure which makes opengl go fast
Load "dri"
# glx and glcore implement opengl
Load "glx"
Load "GLcore"
# double buffering extension (no apps use?)
Load "dbe"
EndSection

/etc/X11/xorg.conf.d/10-evdev.conf
# Catchall classes for input devices
# We don't simply match on any device since that also adds accelerometers
# and other devices that we don't really want to use. The list below
# matches everything but joysticks.

Section "InputClass"
Identifier "evdev pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev tablet catchall"
MatchIsTablet "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection

/etc/X11/xorg.conf.d/10-quirks.conf
# Collection of quirks and blacklist/whitelists for specific devices.

# Accelerometer device, posts data through ABS_X/ABS_Y, making X unusable
# http://bugs.freedesktop.org/show_bug.cgi?id=22442
Section "InputClass"
Identifier "ThinkPad HDAPS accelerometer blacklist"
MatchProduct "ThinkPad HDAPS accelerometer data"
Option "Ignore" "on"
EndSection

/etc/X11/xorg.conf.d/20-nvidia.conf
Section "Device"
Identifier "Default nvidia Device"
Driver "nvidia"
Option "NoLogo" "True"
EndSection

/etc/inittab-ból indítom az X-et így: x:5:once:/bin/su sunmao -l -c "/bin/bash --login -c /usr/bin/startx > /home/sunmao/startx.log 2>&1"

/usr/bin/startxfce4: X server already running on display :0 - Ezt a sort pl abszolút nem értem mikor boot után inittab-ból indul elsőnek az X.

Ami probléma, hogy mikor elindul a DE van olyan, hogy nem jelenik meg a panel csak ha oda kattintok. Van olyan hogy a dock se jelenik meg. Mikor kilövöm az X et és elindítom a tty1-ről akkor minden elem elsőre betölt. Én arra gondolok, hogy az elején összeakadnak a dolgok mikor a compiz indul és ezért nem tud betöltődni minden rendesen, mikor már fut a rendszer utána már a compizzal nem kell törődnie ezért megy minden szépen. Erre valami késleltetés kéne? A többi hibaüzenet is elég idegesítő, kíváncsi lennék mik azok...

Az /etc/X11/xorg.conf.d-ban lévő fájlokhoz nem nyúltam azok alapból ott voltak.

Hu, ezert megint utalni fog mindenki, de nem erdekel: legyszi, ami ilyen hosszu meg nagy, azt tedd mar legkozelebb pastebinre. Akit erdekel, elolvassa, akit meg nem, azt ne terheljuk mar fel kilometer hosszu kommentekkel. Legyen a korlat mondjuk 10 sor. A gist.github.com-on tobb file-t is be tudsz pasztazni, raadasul megorzodik a tabulalas is.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( fdavid | 2010. 11. 07., v – 12:33 )

En is fontolgatom a valtast arch-ra, de hat kozel 8 ev gentoozas utan kicsit nehez a kenyelmesre kitaposott cipot lecserelni. Egy virtualboxba feldobtam az archot, es nagyjabol a rovid hasznalat alatt az alabbiakra jutottam:

* Az adminisztracios toolok nekem kicsit kenyelmetlenek, es nem hozzak mindenben az altalam megszokott funkcionalitast (portage/eix/equery/genlop/etc-update/rc-*/stb.). Erosen ugy tunik a forumuokbol, hogy a gentoo hoskorara emlekezteto privat szkriptgyartas folyik ezeknek a funkcionalitasoknak potlasara.

* Bar az arch latszolag megkulonbozteti a fuggosegkent es a kozvetlenul telepitett csomagokat, megsem igazodom el teljesen a dologban, hiszen a "core" installasaval az osszes core csomag kozvetlenul telepitettnek minosul. Es ez igy van - ha jol ertettem - az osszes csoporttal (meta-csomaggal). Ezzel szemben a gentoonal a "system" es a "world" metacsomagok nagyon jol mukodtek. A system csomagok nem valtak explicitte, ha az ember ezt nem akarta, igy jol kovetheto volt a kozvetlenul telepitett csomagok listaja. raadasul ezt mar a toolok is pl. szinekkel megkulonboztettek.

* Nem ertem, hogy ha minden csomagnak csak egyetlen verzioja van a repositoryban, akkor hogyan lehet visszalepni egy problema eseten. Elofordulhat tipikusan kernelnel, driver csomagoknal, stb., hogy az uj nem mukodik rendesen. Ilyenkor varhatok amig valaki ki nem javitja? Mi van ha egy rendszeren belul egy adott librarybol tobbfele kell? Mi van a pl. a KDE-vel? Ha valaki nem akar valtani pl. 4.5-re mert hianyzik a PIM belole? Vagy ha korabban nem akart valtani 4.x-re? A fuggosegek miatt egy ido utan ugyis ra fog kenyszerulni az upgradere. Ezt erzem a legnagyobb gondnak. Persze tudom nem kotelezo a repositoryt updatelni, de akkor mi ertelme archot hasznalni.

* A tobb csomagverzionak meg volt egyebkent egy masik nagy elonye, megpedig az ember latta, hogy egy csomagot aktivan fejlesztenek-e. Mar lehetett latni a maszkolt verziokat, es az meber sejthette a frissules utemet.

Osszegezve: nekem hoanyzik az archbol egyfajta kiforrottsag, es a csomagpolitikaja elbizonytalanit. Tudtoka fentiekre vonatkozolag megerositest/cafolatot?

Megerősítelek. Az Arch inkább a slackware értelemben vett egyszerűség híve.

a privát scriptgyártás stimmel, a csomagfüggőségek is olyank amilyenek.
Verziót visszalépni úgy tudsz, hogy levadászod a egy (direkt?) lassan frissülő mirrorról vagy az ARMról (*) a régebbi csomagot. Ha erről lekésel akkor svnből kell kivadásznod a régebbi verzió PKGBUILDjét és lefordíthatod magadnak. ha zavaró bug van egy új csomagban akkor hamar jönni szokott a javított verzió, az apró de zavaró bugokkal nincs mindig szerencséje az embernek.
És igen, egy ideig ignorálhatod a frissítéseket ha nem akarod az új verziót használni, de előbbutóbb rákényszerülsz a váltásra. kde3-hoz anno asszem volt 3rdparty repo.

* ARM - arch rollback machine, snapshotokat csináln a repokról, ez se hivatalos http://arm.konnichi.com/

Ami azt illeti, en is ezt erzem. Ez valahogy tulmegy a szandekolt egyszerusegen, ez mar inkabb a hobbyprojektek fejlodesere utal. Nem tudom, sok tekintetben a debian is egyszeru, megis erzek benne egyfajta osszeszedettseget. Azonban az Arch, minel tobbet olvasok rola, annal kevesbe gyoz meg.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
  • Miféle adminisztrációs eszközökre gondolsz? Nem ismerem a gentoo-t, még anno az őskorában tesztelgettem kicsit, de egy 1,3-as durcin kicsit fárasztó volt állandóan forgatni. Nekem egyetlen egy adminisztrációs eszköz kell: vim. 3-4 fájl (elég jól meg vannak tűzdelve páldákkal) szerkesztésével teljesen fel lehet konfigurálni a rendszert.
  • Függőségek tekintetében szerintem a pacman nagyon jó.
  • Az igaz, hogy a csomagtárolókban a csomagoknak csak egy verziója létezik (kivéve AUR, mert ott többfajta is elérhető). De a régebben telepített csomagokat elérheted a
    /var/cache/pacman/pkg

    könyvtárban, igaz ennek van hátránya: egy idő után nagyon nagy lesz, ha nem takarítja az ember. Ha jól emlékszem, akkor vannak olyan szerverek, ahol tárolják a csomagok régebbi verzióját is, tehát a csomagok visszaállítása megoldható.

  • A pacman képes arra, hogy bizonyos csomagokat, ill. fájlokat ,,kihagyjon'' a frissítésből. (
    HoldPackage, IgnorePkg, IgnoreGroup, NoUpgrade

    )

Természetesen az Arch sem tökéletes, mint bármely más disztró sem. Megvannak a gyenge pontjai, de az erősségei is. Én nagyon sok disztribúciót kipróbáltam, de ez tetszett a legjobban. (Ebben nagy szerepe van az ArchWiki-nek is.)
Most röviden ennyi jutott eszembe...

Egy olyan adminisztracios eszkoz, mint az etc-update eleg fontos stuff egy rolling rendszeren, hiszen lehetove teszi peldaul a haromutas konfig fajl mergelest.

Egyebkent meg kimondtad a kulcsszot: nem ismered a Gentoo-t, kovetkezeskepp ugy probalsz ellenvelemenyt formalni, hogy nem is erted a vitapartnered allaspontjat. Szerintem olvass utana, hogy a Gentoo milyen, es utana gyere vissza meggyozni.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nem ellenvéleményt akartam formálni, csak leírtam a felvetett problémákra vonatkozó véleményem. Vitapartner? Dehogy akarok vitatkozni... És nem fogok utána olvasni a gentoo-nak, mert nem igazán érdekel. Ha esetleg vitatkozni szeretnék, természetesen pótolni fogom ebbéli hiányosságaimat. Valamint meggyőzni sem akarom. Az elküldött válazok/olvasott információk alapján szerintem el tudja dönteni, hogy akar-e váltani.

* Adminisztracios eszkozok: nyilvan nem editorra gondoltam, bar en is vimet hasznalok, de azert a vim nem tud csomagokat kezelni, csomagadtbazisban keresni, telepitesi logokat feldolgozni, automatikusan megkeresni es mergelesre felkinalni a frissitendo konfiguracios fileokat, stb. Nyilvan bizonyos funkcionalitasok ebbol megvannak az archban is, de a gentoos eszkozok nagyon kiforrottak, kenyelmesek. Azert persze ennyi ev gentoozas utan altalaban nem szoktam megijedni konfig fileok szerkesztesetol ;-)
* A fuggosegek tekinteteben lehet, hogy a pacman nagyon jo, de a meta csomagokat szerintem nem megfeleloen kezeli, igy osszekeverednek a fuggosegkent es a kozvetlenul telepitett csomagok.