Jó ötletnek tartod-e most egy újabb Linux disztro elindítását?

Egyéb

Igen
0% (0 szavazat)
Nem
0% (0 szavazat)
Őrültség
0% (0 szavazat)
Csak ha kellően mazochista és kitartó az illető
0% (0 szavazat)
Minek egy újabb a sok 100 mellé?
0% (0 szavazat)
(csak az eredmény érdekel)
0% (0 szavazat)
Összes szavazat: 0

( DirtY_iCE | 2007. 10. 31., sze – 18:47 )

inkább tegyék rendbe a meglévőket..

I hate myself, because I'm not open-source.

( MBence | 2007. 10. 31., sze – 20:33 )

Attól függ, mi a cél.
Szerintem kéne egy olyan opció is, hogy Egyéb (leírom a hozzászólásban)

( wladek1 | 2007. 10. 31., sze – 19:01 )

Natehát szerintem nem rossz ötlet.
Általában mindíg a felhasználó jön ki belőle győztesen. Aki most azt mondja erre, hogy nem, az gondoljon arra is, mennyivel jobb lehetne a Windows például, ha nem csak egy cég fejlesztené, hanem többen párhuzamosan.

__

/*no comment*/

Jam. Valószínűleg a világon kevésnek adatik meg életében, hogy olyat csináljon, amit előtte még soha senki. Viszont olyanra van esély, hogy nekiáll valaminek és jobbat csinál, mint ami eddig előtte volt. Ha más eredménye nem lesz, tanul a dologból, tapasztalatot szerez.

Végülis fáj az nekem, ha valaki új Linux disztrónak áll neki? Azt hiszem, hogy nem.

Mondom ezt amellett, hogy én biztos nem állnék neki ilyesminek.

--
trey @ gépház

azt nagyon nem kellene, ha mást nem akkoris ezt az Etch-et fogom foltozgatni, ha nem lesz debian :P
vagy még a Sarge-nak ... :D de DEBIAN marad, max mellé feltolok valami !linux-ot

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam
katt

A deb][inux egy fun projekt volt úgy 2002 közepén. Az IRC-n ökörködtünk. Kifigurázandó, hogy naponta jelent meg egy új disztró, elindítottam a deb][inux projektet. "Linux Debileknek". Gyakorlatilag a projekt egy félórás projekt volt. Lecseréltem a Loadlin szöveget, készítettem egy képernyőképet és a projekt be is fejezte működését. Gyakorlatilag demoztam, hogy a N+1 "új disztró projekt" nagy része erről szól. A deb][inux-nak semmi köze nem volt a Debian-hoz.

Képernyőkép a deb][inux-ról

--
trey @ gépház

( honorshark | 2007. 10. 31., sze – 19:07 )

Egyetértek az egyik előttemszólóval...Mi a cél?

( Gabb3r | 2007. 10. 31., sze – 19:10 )

akkor jó ötlet ha hiányt tölt be/speciális feladatra készült és nem az a cél, hogy egy újabb legnépszerűbb distro legyen

( Oscon | 2007. 10. 31., sze – 19:42 )

Egyéb:

- Egy stabil (hosszú karbantartású) kernelre építsen, melyekbe csak bizt. fixek, egyéb kernel_BUG fixek és új driverek kerülnek bele. Minden más marad a régiben
- Olyan kiegészítő kernelpatchekkel szereli fel az alap kernelét (pl. : grsec(PaX) / RSBAC, stb.), melyeket más disztrók nem.
- Az alkalmazások is fenti szellemben, csak biztonsági frissítések és kész.
- nem kell 5féle ablakkezelő/webserver/stb. minden "főbb kategóriából" legyen mondjuk 1, de akkor az faszántosan legyen supportálva.
- és persze csomagkezelős legyen.

Tehát egyfajta "új Adamantix" kicsit más szellemben. . ;-)

És most akkor fel is ébredtem a csipkejózsika álomból.

-------------

Nem a zsömle kicsi, a pofátok nagy...

Szerintem meg éppen tökmindegy, csak amit te írtál az fölöslegesen bonyolítaná a csomagkezelő készítők dolgát. Egyébként Gentoo alatt a doc meg hasonló dolgokat egy ebuild USE flagjeivel bírod állítgatni. Ha utólag szükség van a dokumentációra is, akkor újrafordíthatod az egész csomagot.

újrafordíthatod az egész csomagot.

Itt Kössenek fel, ha egyszer nekiállok KDE-t forgatni.
Legyenek a csomagok *binárisak*... ;-))

Nem ér az optimalizáció sebességben kb. semmit / desktopon legalábbis /, csak az inkompatibilitási tényezőt növeli.

------

Nem a zsömle kicsi, a pofátok nagy...

Sajnos pont az a bajság, hogy nem. A kde-meta csomagok egy nagyon erős hack eredményei, mert a KDE úgy van terjesztve, hogy féltonna szoftver van egy forráscsomagban, és minden kategória egy csomag. De egy új disztóba lehessen olyant csinálni hogy "${PKGMANAGER} ${INSTALLOPT} klipper kontact kmail akregator konqueror" ha már új disztrót akarunk csinálni

"Nem ér az optimalizáció sebességben kb. semmit / desktopon legalábbis /, csak az inkompatibilitási tényezőt növeli." - Szerencsére nincs így.

Egyébként ha eddig nem tudtad volna; a forrást a számítógép szokta lefordítani, nem a felhasználó, mert úgy praktikusabb.

-------------------
2.6.22-gentoo-r8

Pedig sajnos így van. Próbáltam én i486-os ;-), amd64es disztrót is ua. gépen, egy fikarcnyit sem lett gyorsabb.

Anno a disztróhoz kézzel forgatott cuccok sem lettek gyorsabbak az "előrecsomagoltaknál".

Csak az idő megy el a fordígatással teljesen feleslegesen. És ha error 2-vel megáll az éjszaka közepén, akkor még szívsz is.

De hát mindenkinek a saját ideje.

Az inkompatibilitást meg arra (is) értettem, hogy ha disztrón kívül teszel fel valamit (stílusosan forrásból), fennáll a lehetősége hogy olyan lib-re dependel amit az aranyos disztrógyártók nem , vagy nem a cucc "kérésének" megfelelően forgattak le. És akkor ezt nem biztos hogy egy új .deb-el elintézed. Állhatsz neki fordígatni. aztán a gép majdnem annyi időt tölt fordígatással, mint amennyit használod ;-)

--------

Nem a zsömle kicsi, a pofátok nagy...

"Pedig sajnos így van." - Mondjuk ezen az oldalon nem várok semmit, egyébként jobb helyeken az emberek érveket hoznak fel saját állításuk mellett, ha tudnak.

"Csak az idő megy el a fordígatással teljesen feleslegesen. És ha error 2-vel megáll az éjszaka közepén, akkor még szívsz is." - Mivel a gép forgat, a felhasználó ideje nem megy el, nem így logikus? Amúgy valamiért nekem sose állt le az éjszaka közepén (pedig túl vagyok már "néhány" installon). Olykor persze előfordul, de nem installnál, és mindig többet tudsz kezdeni egy forrással, mint egy szar binárissal, persze biztos valakinek meg az 01101001010... szimpatikusabb, és a linkelésből kideríteni a kimaradt függőségeket, de nekem nincs ilyen baromságokra időm.

"Az inkompatibilitást meg arra (is) értettem, hogy ha disztrón kívül teszel fel valamit (stílusosan forrásból), fennáll a lehetősége hogy olyan lib-re dependel amit az aranyos disztrógyártók nem, vagy nem a cucc "kérésének" megfelelően forgattak le." - Hogy érted, hogy disztrón kívül? Milyen disztró?

Pont desktopnál egyébként teljesen mindegy, hogy miközben használod, csomagokat forgat vagy nem. Szerveren pedig ha azonnal kell valami, azt fel lehet rakni binárisból.

-------------------
2.6.22-gentoo-r8

Pont desktopnál egyébként teljesen mindegy, hogy miközben használod, csomagokat forgat vagy nem

Hát egyáltalán nem mindegy hogy mekkora a rendszerterhelés már bocs, mert valami olyan szart kell 3 napig forgatnia, ami A.) bináris formában minden normális disztróban elérhető B) a "normál i486 bináris", és az agyonforgatott között semmifajta sebességkülönbség nincs.

------

Nem a zsömle kicsi, a pofátok nagy...

Nem tudom miket használsz, de 3 nap alatt egy egész rendszer lefordul 2x, p3-on is.

Még mindig nem értem mitől jobb az a bináris, amit teljesen más rendszeren, nem pont adott igényeknek megfelelően forgattak.

Azt sem értem, hogy miért töltene majdnem annyi időt forgatással a gép, mint amennyit használod, és ez egyátalán miért lenne baj, prímszámokat akarsz keresni 0-24, vagy mi?

-------------------
2.6.22-gentoo-r8

Még mindig nem értem mitől jobb az a bináris, amit teljesen más rendszeren, nem pont adott igényeknek megfelelően forgattak.

Attól jobb, hogy nincsenek vele extra kompatibilitási problémák.

/ Másrészről az AMD64es binárisokat szinte már az "adott rendszerre" forgatták, vagy a szinte talán el is hagyható. és szart sem ért sebesség terén. /

Ha valamit nem akarok belőle használni és belefordították, akkor annak megfelelő paraméterrel indítom. Ha pedig olyan "aprólék" hogy paraméterezni sem lehet, azt meg eleve tökfelesleges külön ezen a gépen is lefordítani, abból ugyanolyan jó a bináris. ;-)

Ha valami BUG jelentkezne, könnyebb a hibabejelentés/keresés, mert nem 1000-ből 1 gcc flag kombináció szülte.

és ez egyátalán miért lenne baj

Azért mert a gépet arra tartom, hogy használjam, nem arra hogy ő használjon ki engem.feleslegesen ne zabálja az áramot.

Amúgy egy költői kérdés. csak úgy kérdezem. A feltehetően "vélt" / vagy inkább "fiktív" ;-) sebességkülönbséget kihasználod, vagy meglennél nélküle is ;-)))

A kb. egyedüli dolog ahol a fordítást el tudom fogadni, az a kernel. Azt valóban érdemes külön a gépre fordítani, de nem azért mert ettől gyorsabb lesz, hanem a "felesleges modulok" (elsősorban driverekre gondolok) nem fogyasztanak erőforrást (IRQ,estébé), nem generálnak "strange bug"-okat, és a bennük keletkező biztonsági hibák sem érintik a rendszert ;-)...

Épp elég bugosak azok a driverek is amiket használni vagyunk kénytelenek. ;-)
Pl. ha van xserver teljesen felesleges a framebuffer sz'tem, és mindjárt nagy adag inkompatibilitási tényezőtől mentettük meg magunkat. vagy ha nem használunk ipv6ot, máris emeletünk rendszerünk biztonsági szintjén, amennyire bugzik a kódja még mindig. (2.6.20nál volt asszem vmi remote DoS, vagy hasonló (?))...

Egyedül a kernel forrást célszerű a disztróban megtartani, mert egyrészt ahhoz a disztró ad fixeket, másrészt mégiscsak azzal "futtatják" leginkább.

/ de ha egyszer marhán ráérek felteszek egy gentoot (ha fel bírom) egy konquerorral, mencoderrel, iceweasellel, nvidia-driverrel, grsecurityvel egy 2,4 gigás partícióra, aztán az orrotok alá dörgölöm hogy szart sem ért a sok göncöt forrásból feltenni. ;-) /

Off: debian-multimedia.org átmenetileg nem elérhető. nálatok se ?

--------------

Nem a zsömle kicsi, a pofátok nagy...

Nem értem, hogy milyen kompatibilitási problémákról van szó. Ezer helyen van leírva nagyon szépen, hogy mely optimalizációk nem okoznak kompatibilitási problémákat. Pl. a procihoz fordító CFLAG-ek általában nem (-march, -mtune), a -O2 megintcsak, a -f* flagek ugyancsak ritkán. Nyilván, ha valaki LDFLAGS-et is szerkeszt, az a saját hülyesége. Itt például csak a biztonságos dolgokat említik - méghozzá procira lebontva.
És tudod mit? Aki hozzáértés nélkül agyonoptimalizál, az meg is érdemli a széteső rendszerét.

És képzeld el, én telepítés után szinte alig fordítok, mint ahogy gondolom te se használod minden nap többször az apt-t. Ha már ki van alakítva a környezet, akkor a többi nem szokott érdekelni. Heti egy éjszakát meg frissülhet a rendszer, akkor általában alszom, nem zavar.

"Másrészről az AMD64es binárisokat szinte már az \"adott rendszerre\" forgatták, vagy a szinte talán el is hagyható. és szart sem ért sebesség terén." - Nem hagyható el, ne magadból indulj ki, más esetleg nem úgy használja a rendszert, mint a terjesztők gondolják/szeretnék/diktálják.

"Amúgy egy költői kérdés. csak úgy kérdezem. A feltehetően \"vélt\" / vagy inkább \"fiktív\" ;-) sebességkülönbséget kihasználod, vagy meglennél nélküle is ;-)))" - Nem elsősorban a sebességkülönbséget használom ki, hanem a stabilitást.

"A kb. egyedüli dolog ahol a fordítást el tudom fogadni, az a kernel. Azt valóban érdemes külön a gépre fordítani, de nem azért mert ettől gyorsabb lesz, ..." - pedig előre ismert igények szerint forgatva a kernelt észrevehetően gyorsabb rendszert kapunk, nem azért mert x modult nem forgatsz, y modult meg igen, a config fájl nem csak ebből áll, és nemcsak configolni lehet, hanem pecselni is.

"Ha valamit nem akarok belőle használni és belefordították, akkor annak megfelelő paraméterrel indítom. Ha pedig olyan \"aprólék\" hogy paraméterezni sem lehet, azt meg eleve tökfelesleges külön ezen a gépen is lefordítani, abból ugyanolyan jó a bináris. ;-)" - Nézd meg, hogy az mplayernek, phpnek, gccnek, glibcnek és még sok nagyobb csomagnak hány ebuildje van, és ezekkel mégcsak nem is a ./configure opciói szintjén konfigurálod. Olyan pedig nincs, hogy max kikapcsolod, ami nem kell, egyrészt nem mindig van rá lehetőség, másrészt van olyan opció, ami nem egy feature beforgatását engedélyezi, hanem attól teljesen másképp lesz forgatva, vannak olyanok is, amikkel egyszerre nem is lehet forgatni.

"Ha valami BUG jelentkezne, könnyebb a hibabejelentés/keresés, mert nem 1000-ből 1 gcc flag kombináció szülte." - Igen, nyilván ha mindenki közel ugyanazt csinálná, ugyanazt használná, ugyanúgy élne, akkor a felmerülő problémák se lennének olyan sokfélék, de az nem mind1, hogy milyen áron.

-------------------
2.6.22-gentoo-r8

Compiler opciókkal nem kapsz desktopon érezhető sebességkülönbséget a konzerv rendszerhez képest. És ne feledkezzetek meg arról, hogy a konzerv rendszer sem optimalizálatlan, hanem általános igényekhez optimalizált.

Linker opciókat nem próbáltam.

Ami pedig a speciális ./configure, patchkészlet és egyéb opciókat illeti: Ha a rendszeren lévő 1000 csomagból 300-nak a konzerv konfigurációja nem felel meg az igényeiteknek, akkor használjatok egészséggel forrásalapú rendszert. Ha viszont valakinek csak 5-10 csomaggal kapcsolatban vannak speciális igényei, akkor egyszerűbb azt az 5-10 csomagot forrásból leforgatni és bedrótozni egy bináris rendszerbe, mint megkockáztatni a másik 990-995 csomag félrekonfigurálását.

"Compiler opciókkal nem kapsz desktopon érezhető sebességkülönbséget a konzerv rendszerhez képest." - pedig sok programnál mégis, de a lényeg nem itt van.
Nem ment fel a debianból 3 verzió, mandrake (aztán később mandriva se), slackware se a notebookomra, mert elszállt mindegyiknek a telepítője, a debian alaprendszere meg errorozott folyton (le is fagyott aztán), hiába támogat elvileg a debian 15 vagy hány architektúrát. Gentoo felment elsőre hiba nélkül, úgyhogy nem hinném, hogy velem van a baj. Az meg nevetséges, hogy a fedora meg az ilyen szarok telepítője leáll, mert egy jelentéktelen csomag md5sum-ja nem stimmel, és azt írja, írjam ki újra mind a 4 cdt, hátha akkor jó lesz. A sok felesleges forgatás helyett inkább a rendszert kéne összerakni normálisan, hogy esetleg szerencsésebb esetben még telepíteni is lehessen, nem csak a legszokványosabb hw konfigurációkra.

"Ha a rendszeren lévő 1000 csomagból 300-nak a konzerv konfigurációja nem felel meg az igényeiteknek, akkor használjatok egészséggel forrásalapú rendszert" - Igen, ezt csináljuk.

"mint megkockáztatni a másik 990-995 csomag félrekonfigurálását." - Érdemes olyanok tanácsát megfogadni, akik valószínűleg többet foglalkoztak a csomaggal, és nem csak a ./configure --help alapján csinálni. Semmivel se több idő, mint keresgélni és kitalálgatni, hogy adott binárist pontosan hogy forgattak le, ha kiderül hogy nem az igényeknek megfelelően, akkor ugyanott tartasz, és még időt vesztettél, de biztosan ez a helyes módszer.

Aztán elég, ha ezerből 1 csomagot kell leforgatni kicsit máshogy, és akkor kiderül, hogy össze kell dobni rendesen a fordítót, headereket, függőségeket, esetleg kiderül, hogy azokat is másképp kéne forgatni..., de biztos ez a jobb, nem az, hogy előre megvan az összes forrás, fordító is készen áll, hogy ne csak binárisból tudjál pakolni, merthát akkor kb. minden menne elsőre (ugyanúgy binárisból is), ha pedig akkor kéne összerakni az egészet normálisan, amikor forgatni kéne, mennyivel izgalmasabb, akár napokat is el lehet tölteni vele.

-------------------
2.6.22-gentoo-r8

nem hinném, hogy velem van a baj.
De, mert bleeding edge hardvert vettél. Bleeding edge hardvert csak bleeding edge kernel hajt, ami a Gentoonál nem gond, mert az egy bleeding edge rendszer, de ahol a biztonság és stabilitás is számít, ott természetesen nem olyan jó a bleeding edge hardver támogatottsága.
Végülis a Gentoo igazságosabb, mert annak is hegeszteni kell, akinek mehetne minden out-of-box. Nem értem miért nehéz újabb kernelt feltenni egy megbízható rendszerre annak, aki Gentooval elboldogul.

Érdemes olyanok tanácsát megfogadni, akik valószínűleg többet foglalkoztak a csomaggal, és felinstallálni az általuk készített csomagot.

össze kell dobni rendesen a fordítót, headereket, függőségeket
Hát baromira nagy kunst:
# apt-get install build-essential
# apt-get build-dep foo

esetleg kiderül, hogy azokat is másképp kéne forgatni...
Ritkán van, de akkor is kezelhető.

"mert annak is hegeszteni kell, akinek mehetne minden out-of-box." - Nem tapasztaltam, hogy kéne, kernelt kivéve az egész automatizálható, és nem csak debian alatt lehet bináris csomagokból rakni rendszert.

"Hát baromira nagy kunst" - Nem hinném, hogy ugyanolyan könnyű, mint egy forrásalapú disztróban, ahol ez eleve elvárás, és ahol amúgy binárisból is lehet telepíteni ugyanolyan könnyen (akár az egész rendszert is), de biztos én vagyok tudatlan, és az apt is berakja a megfelelő függőség forrását a forrás megfelelő könyvtárába, természetesen automatikusan konfigurál igényeknek megfelelően, akár 50 függőségnél is, hiba nélkül, hibátlanul forgat, aztán ha kész, törli a work dirt, és az egészet részletesen (configure opciókat stb) adatbázisban vezeti, üzeneteket is küld, hogy milyen confignál mire figyeljünk, milyen bugok fordulhatnak elő stb, és természetesen az egész legalább annyira up-to-date... valamiért az az érzésem, hogy ezek közül egyik sem teljesül.

Még mindig nem mondta senki, hogy mi az alapja az eredeti felvetésnek, vagyis miért ne lenne gyorsabb, stabilabb egy forrásból rakott program, vagy az egész rendszer, és miért lenne instabilabb. De végülis nem kötelező, a tények úgyse változnának.

-------------------
2.6.22-gentoo-r8

Azért a gentoo fanok mondanivalójából az leszűrhető, hogy

1.) A gentoo is csak akkor lesz "gépre optimalizált", ha spéci gcc flagekkel fordítod. amelyik vagy biztos hogy inkompatibilitást okoz, vagy csak ritkán, vagy általában nem ;-))) /1100 csomagnál mondjuk az általában nem is szopáskategóriás/

2.) Az eddig "felvázolt" pozitív sebességkülönbség egy egy spéci serveres feladatnál jól jön. dekstopnál még mindig nem mondtatok egyértelmű teszteredményt. (nekem az is jó lenne, ha egy agyonoptimalizált gentoo egy nvidia driverrel mondjuk mit tud glxgears-el, ut2k4demoval, vagy valami hasonló mókával. Aztán egy ennek megfelelő bináris, uyganazokkal a CONFIG_beállításokkal elindított damonokkal ua. gépen, egy hasonló verziószámú kernellel (preempt,cfq nélkül), mit tud. Mert ez így tiszta sor. Kijön mondjuk ~0,17% (ex-has a jobbik eredményt feltételeztem ;-))), és akkor ennyi. ki ki döntse el , hogy ezért megéri e egy bináris disztró helyett a forrással szívni. Ha cinikus lennék , megkérdezném, hogy elengedhetetlen szüksége van a 1,7%os pluszra, de nem teszem ;-)))

3. Akárhogy is, időben, fogyasztásban, áramban eszi az erőforrásokat a fordígatás. Vajon effektív hány órát töltött el 1 év alatt a desktop gép fordígatásokkal...?

OFF: össze vissza kerülnek be a hozzászólásaim a szálba... HUP DRUPAL error? vagy mifene ?

-------------

Nem a zsömle kicsi, a pofátok nagy...

Hát nekem olyan túl sokat nem. Játszok, netezek, programozok, tesztelgetek, de a rendszerrel szinte alig van törődve. Még ha meg is nézem, hogy mi újság, akkor se mindig nyomok frissítést, 2-3 csomagért még nem. ha egyszerre akar 5-10 csomag frissülni, vagy kimondottan glsa sérülékenységem van, akkor frissítek soron kívül.

"A gentoo is csak akkor lesz "gépre optimalizált", ha spéci gcc flagekkel fordítod..."

Mar, ha 686 forditasz reggebbi, helyett gyorsabb lesz. (-march=i686 -O2)
Inkompatiblitas meg oda van irva az adott flaghez a manba. (Ha az van oda irva, hogy csak akkor jo ha minden mast is ezzel forgatsz akkor, sem lesz jo neked binary only softwerekhez ), az altalam emlitett ldflag -et nyugodtan hasznalhatod, (ha disztrot csinalok default lessz))

Windows NTx vonalat se hagyd ki a sorból...

A belépő újdonatúj 0-day cuccokhoz levő winntx driverek is általában max. jóindulatú béta driverek ;-). az hogy aláírták őket whql-el az nem jelent semmit. nagyon sok mindent aláírnak. lásd vista megjelenése ;-)

-------

Nem a zsömle kicsi, a pofátok nagy...

Nem hagyható el, ne magadból indulj ki, más esetleg nem úgy használja a rendszert, mint a terjesztők gondolják/szeretnék/diktálják.

Most erre mit mondjak, a bootolástól a glxgearsen át a mencoder felvételig minden majdnem ua. eredményt hozott. A glxgears pl. 64 biten kb. 2%-al (?) lehetett gyorsabb, a többi (mencoder, bootolás, tömörítés) még ennyi sem. (természetesen ua. beállításokkal, csak a programok+kernel volt i386 helyett amd64re fordítva). Ez összességében nézve közel sem sebességkülönbség.

Egyes alkalmazások számos paraméterrel futtathatóak egyébként. Tehát én sem úgy akarom mondjuk a kdm-et használni, meg a console screen, ahogy a fejlesztők defaultban beletették. meg az xservert is spéci xorg.conf-al. De ehhez nem kell újrafordítanom az egész hóbelevancot.

pedig előre ismert igények szerint forgatva a kernelt észrevehetően gyorsabb rendszert kapunk, nem azért mert x modult nem forgatsz, y modult meg igen, a config fájl nem csak ebből áll, és nemcsak configolni lehet, hanem pecselni is.

Valóban lehet számtalan ütemezőt, meg preemptív kernelt próbálgatni, de egyik sem ér DESKTOPon szart sem. Összességében nem lett gyorsabb, egyetlen alkalommal sem. Ami módosulás volt, hogy a KDM kb. 3hetetnte egyszer összerongyolta magát. Ha preempt helyett normál kernel van, Anticipatory shedullerel a CFQ helyett, akkor meg nem.

"Ha valami BUG jelentkezne, könnyebb a hibabejelentés/keresés, mert nem 1000-ből 1 gcc flag kombináció szülte." - Igen, nyilván ha mindenki közel ugyanazt csinálná, ugyanazt használná, ugyanúgy élne,

Nem kell túldramatizálni, de egy fajsúlyosan egyedi rendszer olyan problémákat is generálhat aminek a megoldása nem triviális, nem merül ki abban, hogy google /git problémakeres patch megvan, feltesz és működik. Okozhatja egy gcc verzió+ spéci flag , amire egyrészt beleőszülsz mire rájössz, másrészt meg a flag okozta 0,00000001% összteljesítmény javulás ;-) után én kérdezem meg, hoyg na megérte???

Ha nektek jó hogy potenciális szivacsok vagytok, egészségetekre. Mondom, én nem állok az önszopatás útjába.. ;-)

De aki használni akarja a gépét, és nem önjáró-build-serverként üzemeltetni, az már had örüljön picit a bináris disztribek létezésének ;-))

Tudom, gentooból is van bináris. De ha már bináris, akkor miért gentoo ;-))) ???

----------------------

Nem a zsömle kicsi, a pofátok nagy...

"spéci xorg.conf-al." - Jó, hát az a minimum hogy az ilyeneket mindenki magának írja, és mi se forgatunk újra valamit, csakmert átírtunk valamit a confban, de egy felesleges modul ugyanúgy foglalja a helyet.

"Valóban lehet számtalan ütemezőt, meg preemptív kernelt próbálgatni, de egyik sem ér DESKTOPon szart sem. Összességében nem lett gyorsabb, egyetlen alkalommal sem." - Sokan pedig nem így tapasztalták, de már írtam, hogy a lényeg igazából a nagyobb stabilitás, kompatibilitás.

"egy fajsúlyosan egyedi rendszer olyan problémákat is generálhat aminek a megoldása nem triviális, nem merül ki abban, hogy google /git problémakeres patch megvan, feltesz és működik." - Ha nagyon gáz, akkor fórum/bugreport, és hamar lesz rá megoldás. Nekem szerencsére még nem kellett odáig elmennem, pl. mióta erre a gépre felraktam, nem volt semmi különösebb probléma, egyszer kellett 20 másodpercet google-zni, pedig majdnem minden nap frissítek, ami megvan 1 perc alatt, syncet leszámítva, persze ha épp nem valami nagyobb csomagról van szó, de azokból ritkán jön új.

"Okozhatja egy gcc verzió+ spéci flag , amire egyrészt beleőszülsz mire rájössz, másrészt meg a flag okozta 0,00000001% összteljesítmény javulás ;-) után én kérdezem meg, hoyg na megérte???" - Valamiért ez velem sosem fordult elő... és másoktól se hallottam még, hogy jellemző lenne, de említsed csak ezt a gcc flag - inkompatibilitás témát minden hozzászólásodban, nyugodtan, merthát lehet tényleg, hogy egy gentoo-ssal valahol a világ másik felén életében egyszer előfordult, hogy egy biztonságosnak mondott flag miatt szívott. Egy mindenkiért, mindenki egyért, vagy hogy is van... :P

"Tudom, gentooból is van bináris. De ha már bináris, akkor miért gentoo ;-))) ???" - Pl. a csomagkezelő miatt, meg mert jó admin toolok vannak hozzá. De ez olyan kérdés, hogy mondtátok, hogy debian alatt is lehet forrásból rakni, akkor kérdezhettem volna, "akkor miért debian, ha úgyis forrásból raksz? Miért Linux? Miért, miért?".

1 évben amúgy a gépem összesen max. 2 napot tölt forgatással (install nem számít bele), ami valóban rengeteg idő, az áram után fizetett többletpénzből talán még egy kiló kenyeret is lehetne venni!

Érveket még mindig nem láttam amellett, hogy ha forrásból rakunk valamit, az instabilabb, inkompatibilisebb lesz, és biztosan nem lesz gyorsabb, de úgy tűnik nem is fogok.

-------------------
2.6.22-gentoo-r8

Eddig félrekonfigurálásról, hibákat okozó gcc flagekről besztéltetek, meghogy nem megbízható, mindenképp heggeszteni kell, ezek közül egyiket se tapasztaltam még, és sztem nem csak én.

A hatalmas inkompatibilitás/instabilitás pedig abban nyilvánul meg, hogy félévente kell fél percet googlezni, és begépelni a 3-4 soros megoldást a promptba.
Ált. ez úgy szokott menni, hogy reggel 5kor kelek, míg a sync lemegy (kb. 5 perc), csinálom a dolgaim, reggeli közben pedig ált. 15 másodperc míg a frissítést áttekintem és elindítom, mire indulok, már kész is, ha valami elszáll (néhány havonta előfordul), este két kanál kaja közt megoldom, ha kell a gép éppen forgatás közben, akkor is ugyanúgy tudom használni (nem játékra és prímszámkeresésre persze).

Ha lenne 20 gépem, akkor mindegyikre nem forgatnék le külön mindent, nagyobb csomagoknál ha azonos a config, csak 1x forgatnám le, és a tbz2-t küldeném szét, de csak 2 gépem van, és nem azonos configgal.

Nekem nincs időm olyan szarokra, minthogy bináris disztró (debian stb.)... csak egyszer akarok valamit másképp, mint ahogy le van forgatva, mire a ./configure-t összehozom (lehet, hogy én vagyok a béna, de nem tudom minden csomagnál fejből az összes kapcsolót), kinézni hogy éppen make && make install kell, vagy valami más, logolni, hogy a /usr/bin/install mit hova rak, aztán ha nem fordul le, akkor keresni az okát..., gentooval egy év alatt nincs ennyi teendő.

Ennyit arról, hogy ki mennyit szív, és kinek van sok ideje. Lehet magyarázni, és mindig, amikor szóbakerül a gentoo, beböfögni, hogy az időmilliomosoknak való, és állandó szopás, már a telepítés is, semmiféle sebességjavulás nem észlelhető a forrásból való telepítéssel desktopon, sőt, sokkal inkompatibilisebb lesz sokminden, természetesen csak és kizárólag forrásból lehet rakni, mert ugye ha nem abból rakunk, akkor ne gentoot használjunk vagy hogy is kell mondani... Közben egyiknek sincs semmi alapja, de kb. minden gentoos topic ezzel van tele (és ez a topic is).

-------------------
2.6.22-gentoo-r8

Én egyvalamire már régen rájöttem: a Debian fanatikusokat megtéríteni nagyon nehéz, mint ahiogy egy MCSE-t is az. Őket már beszippantotta az örvény, onnan csak lefele visz az út. Valamiért a debian fanatikusok yó része elvakult, de nagyon. Én itt és most csak azért mentem ebbe bele, mert nem volt yobb dolgom.

Én egyvalamire már régen rájöttem: a Gentoo fanatikusokat megtéríteni nagyon nehéz, mint ahiogy egy MCSE-t is az. Őket már beszippantotta az örvény, onnan csak lefele visz az út. Valamiért a gentoo fanatikusok yó része elvakult, de nagyon. Én itt és most csak azért mentem ebbe bele, mert nem volt yobb dolgom.

Én meg azt nem értem, hogy lehet ennyire belebuzulni. Vannak jó dolgok mindkettőben, de valahogy ez a két distro nagyon tudja fanatizálni a népet (aki volt SFD-n, az sejti, miről beszélek).
Ezt a jelenséget fejtse meg valaki!
It doesn't matter if you like my song as long as you can hear me sing

Néha én is hiányolom egy ports rendszer kényelmét, mert _bizonyos_ programok backportolása a stabil Debianra egyáltalán nem egyszerű. Ennek ellenére mégsem találtam jobbat, mert:

1. egyes disztrók ugyancsak nem nyújtják egy ports rendszer kényelmét, és nem is stabilabbak és megbízhatóbbak a Debiannál.
2. Gentooval kezdetben én is lelkes voltam, hogy most milyen spéci optimalizált rendszerem lesz, meg hogy szuperjó featureket facsarok majd ki USE flagekkel a programokból. Egy bloated XY disztró után valószínűleg gyorsnak tűnik a Gentoo, de Debian után lassabbnak tűnt, és ez kezdett kiábrándítani. Aztán megtaláltam, hogy a szuperjó feature benne van a Debian csomagban is. Én nem akarom a meleg vizet feltalálni. Ha egy maintainer is legfeljebb néhány tíz csomagban mélyül el, akkor miért kellene minden powerusernek elmélyülni abban az ~1000 csomagban, amit használ, hogy a végén megállapítsa, hogy a maintainer jól végezte dolgát. A disztribúciónak az a lényege, hogy ne kelljen ugyanazt a munkát értelmetlenül többször elvégezni, ezáltal emberi és gépi erőforrásokat spórolunk meg. Én nem játszom a hajamat, hogy ismerek minden csomagot, mert véletlenül sikerült olyan USE flag kombinációt összeállítani, amivel még éppen működik a program. Inkább ha valahol úgy találom, hogy nem jól van bekonfigurálva, akkor azt az egy csomagot felteszem forrásból.

mire a ./configure-t összehozom (lehet, hogy én vagyok a béna, de nem tudom minden csomagnál fejből az összes kapcsolót)
Ha neked egy csomag testreszabása USE flagek használatával ki is merül, akkor nem vagy valami nagy buherátor, csak egyszerűen nagynak érzed magad attól, hogy egy-két USE flaget ki-be kapcsolgatsz.

Pedig van számos lehetőség:
* ./configure --help
* ebuild olvasgatása
* fejlesztők honlapja
* Google

kinézni hogy éppen make && make install kell, vagy valami más, logolni, hogy a /usr/bin/install mit hova rak, aztán ha nem fordul le, akkor keresni az okát...
Debian alatt ez laza:

apt-get build-dep foo
apt-get source foo
cd foo-x.y.z
vim debian/rules
# itt átírogatod pl. a ./configure kapcsolókat
dpkg-buildpackage
cd ..
dpkg -i ...

Mivel a függőségek szépen fel lettek téve, ezért menni fog.

Én próbáltam már a debian/rules fájlt szerkeszteni. Talán erre mondják, hogy mesebeli: hol jó, hol nem jó. Én láttam olyan rules-t is, ami a configure-nak 5-6 féle kapcsolót adott át, a configure-t 2-3x is meghívta, és nem könnyü annyi helyet végigbogarászni, hogy mindenütt bebillentsem mondjuk a zlib supportot.

Amúgy tévedtek: Egyáltalán nem vagyok Gentoo fanatikus, sőt, ahova bináris rendszer kell, vagy nagyon gyorsan kell rendszer, Debian-t ajánlok. Desktop-ra pedig példáult vagy Ubuntu-t vagy Mandrivát. De ahova igazán kell teljesítmény (legyen az desktop felhasználás vagy server) oda csak Gentoo-t. És nagyon sokszor örültem, hogy e mellett a rendszer mellett tettem le a voksomat.

Az, hogy itthon Gentoo-t használok, az főleg a gyakorlás miatt van. Az, hogy próbálok embereket toborozni, hogy használjanak Gentoo-t, az pedig azért, mert a magyar Gentoo közösség még igencsak kis létszámú. Gondolom ezzel más disztrók is vannak így, valószínű, hogy az emberhiány ott is emberek toborzására ösztökéli az olyanokat, akik picit is felelősnek érzik magukat a distzró jövőjéért.
Nem mondom, hogy nagyon könnyű az élet Gentoo alatt, csak azt, hogy a közösség elég sokat tesz azért, hogy minél könnyebb legyen. Nem mondom hogy 5%, 10%, 100% sebességhozamot produkál a Gentoo felpakolása, de tény, hogy valamivel gyorsabb lesz a gép (még ha ez annyira nem is érezhető).

Nem kötelező váltani. Viszont ez esetben kultúráltan is lehet emberekkel közölni, hogy kösz, de nem, mint elkezdem a másik rendszerét ócsárolni, védekezésre késztetve az ellentábort. Én személy szerint sosem mondtam, hogy a Debian szar. Azt mondtam, hogy nekem elég sok problémám van vele a használat során, ami nem egyszerű bug, hogy csak lejelentem. Ezt sokan nyílt hadüzenetként értelmezték, és elkezdtek jönni, hogy így a Gentoo meg úgy. Tudom. Nagyon nehéz volt a váltás. Linuxban abszolút járatlanként még nehezebb (Gentoo alatt fordítottam életemben talán másodszor kernelt, és először működő kernelt). De én úgy érzem megérte.

Nem mondom, hogy most akkor mindenki térjen át, csak azt, hogy legalább próbálja ki, aki eddig nem próbálta, hogy tudja, miről beszél. Szánjon rá, mondjuk egy hétvégét, az nem olyan sok.

Én próbáltam már a debian/rules fájlt szerkeszteni.
Én igazság szerint csak egyszer szerkesztettem debian/rules fájlt (kivéve azt az esetet amikor én készítettem a debian csomagot), és akkor működött. Általában nekem megfelelnek a bináris csomagok. Na jó, mondjuk debian-multimedia.org-os mplayer nem játszik real médiát, de lusta vagyok kézzel forgatni, amikor amúgy sem nézek/hallgatok real videót/audiót.

Egyáltalán nem vagyok Gentoo fanatikus
Jó, ez neked úgy általában látszik a posztjaidon. Na de portage... turul16 meg csak simán sebességmániás.

Szánjon rá, mondjuk egy hétvégét, az nem olyan sok.
Én már szántam rá, de a tanulság az volt, hogy nem a Gentoo felel meg legjobban annak, amit én egy disztrótól elvárok. A Debian sem illeszkedik pontosan az igényeimre, ezért időnként folyamatosan keresem az alternatívákat, egyszer már azt hittem, hogy találtam jobbat (http://hup.hu/node/34830), de eddig még mindig a Debian felel meg a legjobban. Na meg már több mint 2 éve ezt használom, ezt ismerem. Így lehet, hogy más disztróknál a negatív tapasztalok valamely része éppen abból ered, hogy nem ismerem a disztrót.
Igazából valami olyan disztró kéne nekem, ahol vannak stabil, karbantartott release-ek bináris csomagokkal, de könnyen lehet új csomagokat feltelepíteni, akár forrásból.

Ez esetben a Slackware előnye az, hogy gyakrabban van release, ezáltal frissebbek a benne lévő libraryk.
A Debian előnye pedig, hogy nagy official repoval rendelkezik, és kényelmesen lehet azokat a függőségeket telepíteni, amelyek verziókövetelményének megfelel a Debian repoban lévő csomag.

Na most mondhatod, hogy Slackwarere annyiféle csomagkezelő létezik, mint égen a csillag, de felesleges, mivel azok a 3rd party szarok annyira megbízhatatlanok, hogy inkább maradok a pkgtoolnál.

Hogy érted, hogy disztrón kívül? Milyen disztró?

Pl. olyan spéci programra van szükséged , amit a disztrib nem tartalmaz.
Nyílván egy program miatt még nem érdemes széttúrni a rendszert, célszerűbb forrást leszedni és lefordítani. csak fordításkor jön elő, hogy ez az amaz hiányzik. :)

---------------

Nem a zsömle kicsi, a pofátok nagy...

Hát én i486os kernel + i486os xorg + i486 (?) os nvidia driver + i486os glxgearst állítottam szembe amd64es kernellel, amd64es xorggal, amd64es nvidia driverrel, és amd64es glxgearsel.

Tehát a feltevők közül egyik sem használta az i32libset.

Semmilyen gyorsulás nem történt. Itt meg pont ugyanúgy teljesített a két rendszer.

Amikor az mplayert forgattam legutóbb a debmultimedias csomaggal szemben, semmilyen eltérést nem tapasztaltam felvételkor. darabszámra ua. framet dobott el egyik is , mint a másik. A forgatással csak az idő ment el, meg a kotorászás a hiányzó -dev ek után. aztán meg csak a helyet foglalták. semmi értelme nem volt.

-----------

Nem a zsömle kicsi, a pofátok nagy...

"A forgatással csak az idő ment el, meg a kotorászás a hiányzó -dev ek után. aztán meg csak a helyet foglalták." - Azért ne a módszert hibáztasd, mert hülyeségekkel elbénázod az idődet, akkor nyilván sokáig tart a forgatás, akár évekig is.

-------------------
2.6.22-gentoo-r8

Beleolvasol a configure.ac fájlba, meg átgreppeled a headereket, és éles logikával kitalálod. Amúgy a normálisabb projektek leírják, hogy pl. Gtk+ ennyi és ennyi, Gnome Libs minimum ennyi, satöbbi. Amihez meg nem, legrosszabb esetbe egy is guglizás megmondja. Amúgy a Gentoo-ba elég sok mindenhez van gyári ebuild, amihez nincs, van 3rdparty ebuild, csak keresni kell. Hát igen, a google-t tudni kell használni, de kb ennyi tudást igényel a dolog.

"\"az ablakba\" (=doksiba) hogy egy 3rd software nek milyen libekre, -dev-ekre vagyon szüksége" - Ki szokták írni a project honlapjára, vagy ha nem, google ált. megtalálja, ha mégse, akkor még mindig kiderül a configure során, ez kb. 1 perc, de gentoohoz tényleg rengeteg ebuild van (overlayekkel együtt főleg), leszedi és felrakja automatikusan, ami kell, igény szerint egyedi konfigurációval. Amit ebuild nélkül raktam, azt csak azért, mert saját config szerint forgattam (amit persze ebuilddel is meg lehetett volna csinálni). Bináris distronál meg ne csodálkozz a szar függőségkezelésen, éppen elég (amúgy felesleges) meló mindent leforgatni az usereknek.

-------------------
2.6.22-gentoo-r8

Csak azok a szuperintelligens teremtmények válhatnak Debian adminisztrátorrá, akik még az olyan nehéz feladatokat is, mint néhály lib*-dev csomag feltelepítése, képesek nyavalygás nélkül egy-két könnyen megjegyezhető parancs kiadásával megoldani, mint amilyen az
# apt-get install libfoo-dev
vagy az
# auto-apt run ./configure

Pedig hálistennek így van. Nem a bootolás vagy az ls sebessége a dolog lényege.

Hadd mondjak el egy történetet:

Adott 3 gép, mind a 3 VMware, 64 MB RAM, ugyanazon az 1300 MHz-s procin osztoznak, egyforma gépek ugyebár. Feladat: MySQL NDB cluster létrehozása, 1 management 2 data node felállással (a management node volt a SQL node).
Debian (stable): fél nap után a cluster közöte, hogy nem képes felállni, valami kommunikációs hiba van, vagy mi.
Ubuntu (stable): 3 óra után elhasalt az egyik node, körülbelül fél óra után vette észre ezt a management node és körülbelül 10 perc alatt már le is állt az egész cluster.
Gentoo Linux (stable): A cluster körülbelül 5 percen belül állt. Az egyik data node túlterhelés miatt kiesett, az egész cluster azonnal leállt. a data node kipucolása, memóriájának növelése után a cluster a felállást követően 5 perc alatt elrendezte a "hatalmas" mennyiségű adat átvételét.

A dologhoz annyit, hogy a gépek klónok voltak, a virtuális lemezeket cp-vel klónoztam a többi gép alá, a konfigok tökéletesen egyeztek. A data és a management node közt egy különbség volt, a management node rendelkezett egy NAT kártyával, mert egy Drupal volt az SQL felhasználó rendszere.

A fenti jelenségeket sikerült néhány hónappal később friss installal is előidézni.

Ennyit a performanciáról.

Az inkompatibilitást meg arra (is) értettem, hogy ha disztrón kívül teszel fel valamit (stílusosan forrásból), fennáll a lehetősége hogy olyan lib-re dependel amit az aranyos disztrógyártók nem , vagy nem a cucc "kérésének" megfelelően forgattak le.

Erre azt mondom, hogy egy forrás alapú disztró esetében én seperc alatt csinálok mind a programhoz mind a hiányzó libekhez csomagot.

A fordítás alatt nem nyelvi fordítást kell érteni, ahova ember is kell.
Én például így telepítek Gentoo-t:

Amíg a rendszer a bootstrap folyamatot végzi (glibc, binutils, gcc, gettext), addig egyrészt letöltetem a következő lépés forrásállományait (ha azok nem lennének meg), és egy harmadik konzolon elvégzem a rendszer alapszintű felkonfigurálását (gépnév, make.conf, billentyűzet, konzolfont, miegymás).
Ezek után az első konzolon elkezdem a második fázist (stage2), közben elmegyek inni meg beszélek egy pár szót a családdal, mire visszajövök, képes vagyok a konfigurálást folytatni, letöltöm a bonyolultabb telepítésű programok legfrissebb csomgját, az ncurses lefordulása után felkonfigurálom a kernelt a régi konfig alapján, átnézem az újdonságokat a kernelben, finomhangolok. Mire ezzel elkészülök, a második fázis nagyjából be is fejeződik, a kernel forgatásra kész, a harmadik fázis olyan félóra alatt megvan. Az újraboot idején már van konzolos böngészőm, konzolos levelezőm, működik a net. Amíg az X és a gnome fordul, addig híreket olvasok, levelezek, HUP-olok, egyszóval el tudom verni az időmet.
Ha már van Gnome. bejelentkezek, és örülök.

Mindeközben nagyon kevéssé érdekel az, hogy a fordítás alatt pontosan mi zajlik (azzal együtt, hogy természetesen tudom hogy mi zajlik). Néha odanézek, ha el kell simítani valamit, körülbelül 3 paranccsal elsimítom, és megyek vissza az előző feladatomhoz. Van amikor pl. egy másik szerveren hibaelhárítok az install környezet alól. Ez nem Debian/SuSE/akármi, hogy az installálás alatt maximum falat tudsz kaparni, meg láblógatni, meg kávézni, meg halálra unni magad. A telepítő környezet maga is egy produktív rendszer, még a minimal install cd is.
Ha véletlen Live CD-t használok, az még jobb, akkor telepítés közben még akár VoIP-telefonálni is tudok.

Hadd mondjak el egy történetet:

A példád serverre vontakozik, én meg írtam fentebb hogy "desktopon legalábbis"...

nyílván serveren már adott esetben előjön a teljesítmény különbség.

bár serveren, sőt mondjuk inkább munkaállomáson speciel nem igazán célszerű fordításra alkalmas cuccokat elhelyezni biztonsági okokból. ;-)

Ha nincs mivel lefordítani, akkor egy 0-day exploit sem biztos hogy sokat ér...de mindenképpen egy apró akadály.

Ez nem Debian/SuSE/akármi, hogy az installálás alatt maximum falat tudsz kaparni, meg láblógatni, meg kávézni, meg halálra unni magad.

Épp elég hogy a configurálással is úm. "dolgozni" kell, hadd ne kelljen már azzal is dolgozni, hogy feltegyen a rendszer egy nyamvadt csomagot.

aptitude install és fent is van. készen, egészségesen. Legyen elég csak akkor forgatni (deb-src), ha nagyon muszáj.

dehát nyílván mások az igényeink. nem vagyunk egyformák. ;-)

Én a falat kaparnám ha a CPU-t 2 napra elvinné hogy megjelent a KDE-hez egy bugfix. hát a rossebot. ;-)

aztán nem tudnék miatta normálisan mencoder-rel felvenni, mert nincs elég nafta...

Meg aztán a helyfoglalás sem egészen egyforma. Nem kell a sok -dev meg header meg anyámkínnya. ;-)

------------

Nem a zsömle kicsi, a pofátok nagy...

Gondolod hogy a teljesítmény alkalmazásfüggő? Én kétlem. A kocsim se lessz sokkal hatékonyabb attól, hogy egy vagy két ember utazik benne.

Épp elég hogy a configurálással is úm. "dolgozni" kell, hadd ne kelljen már azzal is dolgozni, hogy feltegyen a rendszer egy nyamvadt csomagot.

Nem vagy elég figyelmes: én egy teljesen 0-ról való telepítést értettem ez alatt. Gondolom te se default installal használod a gépet hanem azért itt-ott beállítgatod. Én mondjuk rutinosan cca 3 perc alatt végzek vele, utána tudok fórumozni; de egy 2-3. installos emberke is olyan 5-10 perc alatt megtalálja és belövi ami kell - handbook olvasással együtt.

Csomag feltétele: szerinted az "emerge CSOMAGNEVE" parancs kiaadása olyan nagy munka? Akkor ajánljuk minden kedves túlsúlyos rendszergazdának a parancs kiadását :D.

Én a falat kaparnám ha a CPU-t 2 napra elvinné hogy megjelent a KDE-hez egy bugfix. hát a rossebot. ;-)

Te, mégis milyen géped van? AMD K6-2 500MHz + 64 RAM? Mert azzal valóban 3 nap. Egy manapság közép- ill alsókategóriának számító gépen (AMD Athlon XP, 512 RAM) olyan félóra alatt megvan, ha nincs terhelve a gép, 15 perc.

Helyfoglalás: A mai vinyók mellett? Könyörgöm, egy agyoninstallált Gentoo-n sem éri el a 100-110 megát a /usr/include mappa összmérete! Ahol meg a hely a szűk keresztmetszet, ott az 'rm' nevű programocska tud a gondokon segíteni. Ugyanígy a forráscsomagokat sem kell totojgatni, minden nagyobb forgatás után ki lehet törölni őket. Gondolkodás meg tervezés kérdése az egész.

Amúgy pont a mencoder a rossz példa, annál is láttam sebességjavulást Gentoo alatt.

Nem vagy elég figyelmes: én egy teljesen 0-ról való telepítést értettem ez alatt. Gondolom te se default installal használod a gépet hanem azért itt-ott beállítgatod

Más amikor a 3/4ig készregyártott config fájlokat szerkeztem mcedittel, mintha a csomag *lefordításához* az extra gcc flageket (a config fájlokat ezen felül még mindig be kell állítani). A kettő nem egy kategória.

szerinted az "emerge CSOMAGNEVE" parancs kiaadása olyan nagy munka?

A kiadása nem, a lefutása sz'tem annál inkább ;-))

Nem vagy elég figyelmes: én egy teljesen 0-ról való telepítést értettem ez alatt.

teljesen 0-ról feltettem egy AMD64re "optimalizált" disztrót. mégsem lett gyorsabb. ;-) biztonsági téren (PaX, (NXbit), memóriakezelés voltak finom újdonságok, de kompatibilitási gond cserébe volt vele, úgyhogy repült.

Egy manapság közép- ill alsókategóriának számító gépen (AMD Athlon XP, 512 RAM) olyan félóra alatt megvan, ha nincs terhelve a gép, 15 perc.

Nananana!!!! ezt hiszem ha látom ;-)

Amúgy pont a mencoder a rossz példa, annál is láttam sebességjavulást Gentoo alatt.

Hát van neki jópár SSE, hasonló utasításkészletet használó "flag"-je, de itt ezekkel együtt akkor sem lett gyorsabb.

Ugyanígy a forráscsomagokat sem kell totojgatni, minden nagyobb forgatás után ki lehet törölni őket.

define nagyobb forgatás. (iceweasel,kde update,openoffice,), vagy ? ;-)

De ha neked jó, hogy a géped majd annyit fordít mint amennyit használod, egészségedre, én a világért nem fosztanálak meg ettől az élvezettől...:-)

--------------

Nem a zsömle kicsi, a pofátok nagy...

Mindeközben nagyon kevéssé érdekel az, hogy a fordítás alatt pontosan mi zajlik (azzal együtt, hogy természetesen tudom hogy mi zajlik). Néha odanézek, ha el kell simítani valamit, körülbelül 3 paranccsal elsimítom, és megyek vissza az előző feladatomhoz. Van amikor pl. egy másik szerveren hibaelhárítok az install környezet alól. Ez nem Debian/SuSE/akármi, hogy az installálás alatt maximum falat tudsz kaparni, meg láblógatni, meg kávézni, meg halálra unni magad. A telepítő környezet maga is egy produktív rendszer, még a minimal install cd is.
Ha véletlen Live CD-t használok, az még jobb, akkor telepítés közben még akár VoIP-telefonálni is tudok.

...

debian install nálam ..

base sys fel
reboot
links, tmsnc fel
és a többi cuccot meg feltolom apt-get installal és nagyreészt nem a metacsomagokat használom, hanem lentről építkezek felfelé és így nem bassza tele a sys-t ugy _másik terminálon_ ugyan ugy mint a te kis gentoo-d alatt lehet bármit csinálni közben ...

ugyhogy ez nem csak a gentoo specialitása ...

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam
katt

De a base sys install alatt mégis mit tudsz csinálni? Reboot után még egy ncurses alapú vacakot végig kell külön tolni, mire ott vagy (asszem etch--nél nem, de ott meg a base install után. Mire én azt végigkattintgatom, addigra régen megírtam volna hozzá a konfigokat. S pláne amennyit gondolkozik közbe...)

maga el lenni tévedve ...

expert módba kell telepíteni és akkor kicsit jobban lehet configelni ...
és a base sys fenn van 5-10 perc alatt, utána meg nem az aptitude-ot kell haaználni, hanem simán apt-get install csomagnév, és a legelső az új kernel betolása. De mindenki másképp csinálja.

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam
katt

akkor most értelmes emberekhez méltóan ...
szerinted ez: "És ettől jobb lesz, vagy mi" visszafelé nem igaz?

valahogy a nyilt forrásnak ez a legnagyobb nyűgje, mint ahogy itt is láthatjuk, hogy csak marni tudjuk egymást, de nem csak *BSD vs Linux, de Linux vs Linux vagy akármi más programmal kapcsolatba. Sok cég vagy ember szerintem ettöl "futamodik meg" és azt mondja, kössz nekem nem kell. Pedig hasznéos, csak a rossz oldalát látja.
Visszatérve a Gentoo vs Debian-hoz, mind a két rendszer alatt meg lehet csinálni ugyan azt, _CSAK ÉRTENI KELL_ hozzá, pl spec installkor, ha gondolkodsz is egy kicsit azokkal a programokkal kezded, amiket tudsz használi install alatt és hasznos, ezt meg lehet oldani mind a két rendszer alatt. Azt hogy ki miért az egyiket vagy a másikat preferálja az legyen az ő dolga. Multkor spec elkezdtem egy freebsd-t forrásból feltolni és valahogy az 1MB/s-es nettel nem valami élvezet és ott is az olyan dolgokkal kezdtem, amivel le tudom magamat kötni (ld links és tsai) ugyan ezt csinálom debiannal is és akkor nem unatkozok közben vagy csinálok valami értelmesebbet, ami nem a géppel kapcsolatos, mert ugyebár lehet ilyet is ...
sum: szvsz aki meg akar valamit csinálni az meg is tudja legyen az gentoo vagy debian

[off]
ennyit a szent beszédről ..
[/off]

Nekem mindig igazam van, ha nem, akkor nincs igazam, szoval megint igazam van hogy nincs igazam
katt

Amíg a rendszer a bootstrap folyamatot végzi [...] Ha már van Gnome. bejelentkezek, és örülök.

10 perc alatt felrakom az XP-t, 20-30 alatt tetszőleges bináris linuxot (ha épp nincs semmi hw-s szopás), előbbire kb 20 perc alatt felrakom a szokásos drivereket meg beállítgatom a szokásos dolgaimat, utobbinál feladattól fuggően 10 perctől 1-2 óra.

Fél óra alatt szerintem nem kapok Gentoo-n teljes értékű (értsd: van grafikától kezdve hangon át minden) rendszert.

De. LiveCD, stage3, bináris csomagok. Onnantól munka mellett forgathatid újra a rendszert - immár merevlemezről bootolva.
Az, hogy én a stage1-et favorizálom, az akár az én betegségem is lehet.

Ja, és most láttam, hogy állítólag működik a GLI, a Gentoo grafikus telepítője - csak a livecd-n van.

"Fél óra alatt szerintem nem kapok Gentoo-n teljes értékű (értsd: van grafikától kezdve hangon át minden) rendszert." - Hát akkor elég béna vagy, ha csak debian alatt tudsz binárisból rakni, de ezért ne a terjesztőt hibáztasd, olvasni kéne kicsit többet.

-------------------
2.6.22-gentoo-r8

Szerintem jó lenne, ha tudna build-et IS, de legyen bináris alapból. De ha tud build-et az legyen teljesen automatikus, és működjön úgy, hogy ha kell, akkor megy más disztrón is. Így lehetne kiadni disztrófüggetlen forráscsomagokat. A telepítésnél pedig szedje le a devel csomagokat, de csak amik kellenek. Ezeknek a letöltött verziói mehetnek egy cache-be, mint ahogy az apt is csinál egyet. Tömörítse ki őket a build-hez, utána szedje le! (Persze ha eredetileg installálva volt, akkor ne. A lényeg, hogy egy izolált helyre kerüljenek a többi csomagtól). Ha nem érhetőek el a forráscsomagok, akkor töltse le őket akár ebben a formátumban, és úgy build-elje.
Ez így szerintem egész korrekt tudna lenni.

A -dev csomagok nem nagyon tudnak izolált helyre kerülni, mert sok program elég szélsőséges algoritmusokkal van ellátva. Volt olyan, ami normál esetben simán ismerte a DESTDIR-t, csak épp a képeit akarta mindenáron a valódi rendszerbe tenni. Persze a sandbox rögtön elsikoltotta magát...

Amúgy felesleges a -dev csomagok különpakolása. Ahol számít a hely, ott egy 'rm -rf /usr/include/*' kiadása bármikor gondmegoldó tud lenni. A dokumentációkat viszint lehessen szabályozni (/usr/share/doc/*).

Akkor buildeljen chroot-ban, nekem mindegy. Én csak azt nem szeretem, hogy leszedek egy csomó dev csomagot, hogy leforgassak valamit, utána már nem emlékszem, hogy melyikek voltak azok.
Meg azért én is szoktam fejleszteni, szóval az összes dev-et nem kéne lezúzni, csak azokat, amik nem kellenek.

( dejo v | 2007. 10. 31., sze – 20:35 )

Ha valakinek ahhoz van kedve, akkor csinálja.

( styg v | 2007. 10. 31., sze – 20:47 )

Kíváncsi lennék, hogy a pre-ubuntu időkben erre a kérdésre mit feleltek volna az emberek..

Ugyanezt. És az Ubuntutól függetlenül fenntartom a véleményem, az Ubi az üdítő kivétel. Semelyik másik disztrib mögé nem tudnak betolni pénzt, nem hogy annyit hanem egyáltalán nem, mint az Uborka mögé, így az új disztrok a szokásos nyűgbe halnak bele, a hosszútávú supportba, a bug-tracking-ba, a csomagfrissítésekbe és rokon problémákba. Iszonyat mennyiségű csomag van, ezt karbantartani nagyon sok emberes feladat. Ráadásul ha megnézzük, az Ubi is Debianra építkezik, a dollármilliók és a több száz ember is valószínűleg kevés egy élenjáró önálló új disztrib létrehozásához.

Akkor most szentsegtorest fogok elkovetni, de olyat mondok, hogy:

Mi lenne ha nem pakolnanak bele a disztribucioba minden ocskasagot, hanem mondjuk csak a legalapvetobb dolgokat? Akinek meg kell valami extra az leforgatja, esetleg letolti binarisban a "gyarto" oldalarol.

Ergo:
- Ne adj isten egy CD-n elferne az egesz cucc
- Joval kevesebb mindent kene supportalni, ergo jol ossze lehetne loni az egeszet

Vagy erre azt mondana mindenki hogy "dehat a *** disztribucioban van husvetitojas-kifesto program, ebben miert nincs?" :)

Amugy en is a "minek"-re szavaztam...

Örültem a Zenwalknak míg arról szólt hogy csinálnak egy jó telepítőlistát slackware-hez. Aztán egyre inkompatibilisebb lett a slackware-rel. Ugyanez van a Kiwi meg a Mint Linuxokkal, csináltak egy jó telepítőlistát Ubuntuhoz. Csak a Mint-nél kitalálták hogy ne legyen update-notifier mert az zavarja a júzert. Igazából csak az volt a gond hogy a Celena upgrade-et ajánlott fel Gutsyra. :)
--
Degradálódjunk kicsit visszább!

( zolix | 2007. 10. 31., sze – 22:47 )

Miért ne? Még ha csak magának is farigcsál kezdetben az illető, kizárólag, mert valami miatt nem jönnek be neki a meglévő, aktív disztribúciók, vagy csak tanulási célzattal akár... Aztán ha esetleg kisül belőle valami használható, esetleg felfedez, feltalál valami egyedi, forradalmi megoldást... Persze ehhez az kell, hogy valóban új (!) disztribúció legyen, ne egy X alapú újabb logó-háttérkép-bootsplash lecserélős valami, tehát a unix filozófiát szem előtt tartva, de egyedi elképzelésekkel. Ennek lenne értelme.

( s3r3nity | 2007. 11. 01., cs – 00:39 )

Én kíváncsi lennék rá. Szeretem az újdonságokat. Jah de csak akkor ha nem egy újabb Debian - fork arra nincs szükség sztem.
Lassan a Distrowatch is átalakul Debian-forkWatch -á ... :)

---
MSI KT3 Ultra, 1GB DDR, AMD Athlon 1800+, NVIDIA GForce4 MX 440

( tetemes | 2007. 11. 01., cs – 02:34 )

OFF + FLAME gyanús

Legalább politikamentes oldalon mellőzzük kérdésben az "e" kérdőszó használatát!

Helyesen így lehetne a kérdőszó használatával:
"Az érdekel, hogy jó ötletnek tartod-e most egy újabb Linux disztro elindítását."

vagy így nélküle:
"Jó ötletnek tartod most egy újabb Linux disztro elindítását?"

( ProTech | 2007. 11. 01., cs – 08:47 )

Szerintem egy ujjabb tomeg disztro keszitesere semmi szukseg. Abbol igy is van boven.

Aminek latom ertelmet, ha valaki ki akar probalni valami nagyobb ujitast, amit nem lehet megtenni egy mar letezo disztro keretein belul. Ha az a forradalmi ujitas bejon akkor lehet belole akar tomeg disztro is. Pl. a Gentoo eseteben, a forras alapu csomagkezelest nem lehetett volna megcsinalni egy mar letezo disztro keretein belul, tehat erdemes volt. De egy DZSbuntunak ami hobbi horgaszoknak keszult, es tartalmaz rengeteg horgasztrukkot manual formaban nem biztos, hogy sok ertelme van.

( E-Medve v | 2007. 11. 01., cs – 09:20 )

Én ugyan azt nyomtam, hogy "Minek egy újabb a sok 100 mellé?", de ha az az egy új olyat mutat, amit az eddigiek nem és azt úgy, hogy nem próbálja meg eldugni a rendszert teljesen user elől, akkor akár még jó is lehet. De enélkül felesleges. (amit az eddigiek nem = hasznos valami legyen és tényleg korszakalkotó)

( msandor v | 2007. 11. 01., cs – 10:47 )

szerintem más válaszok születtek volna, ha tudnátok, hogy Oldman melyik "új" disztróra gondolt :-)

--
by Mikul@s

( creativex | 2007. 11. 01., cs – 10:53 )

nem értek a egyet a "Minek egy újabb a sok 100 mellé?" szavazókkal, mert pl. az ubuntu előtt is lehetett volna ezt mondani, most meg kár lenne ha nem lenne...

( geronimo | 2007. 11. 01., cs – 12:58 )

Vajon hülyeség volt anno egy n plusz egyedik webes keresőt írni?
Vagy egy n plusz egyedik webes levelezőt?
--
kövi

( egeresz | 2007. 11. 01., cs – 13:05 )

brobalom lefedni a lehetosegeket;)
- egy mar meglevo disztribbel konkural: a verseny erositi a mar meglevo disztribet, a jobb megoldasok fognak fennmaradni vagy atkerulni a masikba; esetleg az egyik lenyomja a masikat (az uj a regit, a regi az ujat, mindegy, mert a jobb marad meg)
- egy valodi lefedetlen teruletet fed le: ujabb felhasznalokat hoz a linuxnak, hiszen olyanok is elerik, akik idaig nem
- nincs is ilyen piaci res: becsodol siman

Ez eddig 2 jo, 1 erdektelen resz. Akkor mi a baj?

-A baj az, hogy esetlegesen felesleges iranyba megy el programozoi eroforras, amit szerencsesebben is elmehetne. A kozponti dikatatorikus eroforraselosztas nelkuli helyzetben csak arra szamithatsz, hogy mindenki azt csinal, amiben hisz (amit akar) a szabalyzo elv a rendszerben nem a kozponti hatalom, hanem a piac (mit hanyan hasznalnak). Ez a szabalyzas igenis komoly eroforrast emeszt fel. Zavar? Zavar. Megkozkaztatom azonban, hogy a piac szabalyzo hatasa kevesebb eroforrast emeszt fel, mint egy kontrollalhatatlan kozponti hatalom. Tekintsd ugy, hogy az auj disztrib letrehozasaba olt (feleslegesnek latszo) eroforras azt szolgalja, hogy az egesz jobb legyen (szabalyzasi celra megy el).
- A kedvenc disztromat tamadja. Alapveto emberi jelenseg, hogy neked ez tetszik, nekem az, es roszul esik, ha valaki masra tesz. Ez nem baj. Az viszont, hogy ezt nem latod, az baj :-)

mithagytamki?

egeresz

Probalok kotekedni az altalad felvazolt lehetosegekkel :}}

- ha egy mar meglevo disztribucioval konkural, akkor valoszinuleg olyan nagy ujitast nem vezet be ami miatt inkompatibilisse valna az szulo disztribucioval. Ez esetben miert nem lehet a fejlesztest a szulo disztribuciohoz kuldeni, eleinte testing/snapshot/unstable/stb agba, majd ha bevalik es a felhasznaloknak tetszik atteni a fo agba? Igy nem lesz olyan helyzet, hogy egyik dolog ami nekem tetszik a szulo disztribucioban van meg, egy masik dolog pedig az ujban, en pedig 2 szek kozott a foldre ulok, mert egyuttesen egyik sem tudja a nekem szukseges 2 dolgot.
- a disztrowatch-on fellelheto nehany szaz disztribucio kozul hany nevezheto olyannak amely eddig nem lefedett teruletre lepett be?
- becsodoles utan a fejlesztok hany szazaleka kezd egy ujabb disztribucio fejlesztesebe nullarol, esetleg egy mas jellegu disztribucio forkolasba es hany mondja azt, hogy rossz otlet volt es inkabb visszaallok a szulo disztribucuiot segiteni?

Bajok:
- szerintem igenis elveszlik az eroforras ennyi disztribucio kozott. Lehet nem pontos hasonlat, de hatha megis jo lesz: mi ertelme hogy parhuzamosan fejlesztik az openoffice-t, koffice-t, gnomeoffice-t? Nem lenne jobb, ha mondjuk az openoffice foglalkozna az alappal, azaz elkesziteni a szukseges modulokat, library-ket es hozza API-kat, es a koffice/goffice csak a qt-s illetve gtk-s grafikus feluletet kesziteni hozza? Mint ahogy van sok mplayer frontend, de mindegyik az mplayer-re epul. Ehhez persze kell egy megfelelo alap amire biztosan lehet epiteni. Nem latom ertelmet ugyanazt a dolgot tobbszor megcsinalni kisebb-nagyobb modositasokkal.
- a kedvenc disztribuciomat semmi sem fenyegetheti amig annak a fejlesztese halad. Legyen Ubuntu/Suse/stb akarmilyen felhasznalobarat, kenyelmes, egyszeru, ugyis mindig a Slackware marad a szivemcsucske :}}

Tehat szerintem ha valaki nekiall uj disztribucionak, akkor legyen valami olyan ekletkepes otlete amit a mar letezo disztribuciokban nagyon nehez lenne megvalositani. Mint ahogy emlitettek a forrasbol valo telepitest es hogy ezert jo otlet volt megcsinalni a gentoo-t. De csak azert mert mas programokat tesz az install cd-re, modositja a kinezetet, esetleg beletesz 2 uj csomagot, azert nem erdemes uj disztribuciot csinalni. Igaz, ehhez hozzajon az, hogy a szulo disztribucio-ban elterjedt mentalitas nem mindig egyeztetheto ossze az altala elgondolt valtoztatasokkal. Epp ezert kezd valaki ujba.

Ugyhogy amig nem talalnak ki valami teljesen uj hozzaallast, amely biztositja egy disztribucio tag keretek kozotti bovithetoseget, addig hetente/naponta fognak uj hosszabb/rovidebb elettartamu disztribuciok szuletni.

A dolog kulcsa a motivaciokban rejlik. Az, hogy a motivaciok eredmenyekeppen olyan is szuletik, ami a kulso felhasznalo szamara alkalmas, mar csak a raadas. ;-) Mindenkit a sajat erdeklodes vagy problemaja motival, es nem az, hogy masnak mi kell, vagy masok szerint mi lenne racionalis, vagy hatekony. Es ez igy van jol. A szabadidomben azt csinalok, ami nekem jol esik, es egyaltalan nem erdekel, hogy masok mit szeretnenek kihozni az en szabadidombol.

( Boobek | 2007. 11. 01., cs – 18:43 )

Igen, ha van benne ötlet - valami új hasznos dolog, és van is rá kereslet
Persze ezek mellett csak akkor, ha megvan mögé még a tábor is...

( utpKabel | 2007. 11. 04., v – 09:25 )

Szóval 31% szerint jó ötlet, 60% szerint rossz, 10%-ot meg csak az eredmény érdekel.

( numen v | 2007. 11. 04., v – 13:49 )

kinek jó ötlet?
annak aki csinálja, színe joga. A neten elfér, ő fejlődik, van aki örül neki, ha más nem, akkor ő maga.
Mindenki jól jár. Még az is, aki ilyesmin szeret trollkodni:P

Miért kellene leszólnia annak, aki nem csinál semmit azt, aki zabot hegyez? Főleg ha az utóbbi nem is biztos. 

int getRandomNumber() {
return 4; //szabályos kockadobással választva. garantáltan véletlenszerű.
} //xkcd

( orizat | 2007. 11. 07., sze – 09:05 )

természetesen tök jó minden új disztrókezdeményezés, különösen ha van benne eredeti ötlet, újdonság. Ez a nagyszerű a linux világában hogy van választási lehetőség és a szomszédom is a tesóm is a faterom is mást használ mint én .... a windows-osok meg 98/xp/vista oszt annyi, mint a cucilizmusban mikor volt a trabi/skoda/zsiga nesze neked ....monokultúra... majd meg is döglik...eccer
Az új disztró felett pedig a piac/a felhasználók törnek pálcát értsd döntenek értsd telepítik használatba veszik vagy nem ....evolúció, kiválasztódás, stb....

cszs

( asch v | 2007. 11. 14., sze – 16:41 )

Naná.
Akár egy kvázi-disztribúció, ami csak specializál és kiegészít egy meglévőt (mint Kiwi), akár egy teljesen új, ötletes dolog is hasznos szerintem.

( Hiena v | 2007. 11. 17., szo – 14:03 )

Új disztribet csak úgy érdemes kihozni, ha megfelelő koncepció van mögötte és van a szerkesztők között hajlandóság arra, kellő mennyiségű kódolást beleáldozva javítsák azokat a hibákat amik más disztribeknek a részei, és kellő pofátlansággal összelopják azokat amik jók.
Hogy mit látnék szívesen egy új disztribben?
A dependenciák ütközésmetessé tétele, adott esetben stand-alone-ként fordított alkalmazásokkal.
Egyszerű, egyklikkes telepítést.
Grafikus, szájbarágós tutorial a kezdő felhasználóknak.
Help, help, help, help...Mindez applikációkba integrálva és nem rtfm szinten.
On the fly localizáció váltás.
Ésszerű, átlátható konfigurációmanagement.(No registry, no database, no xml, no m'am)
Megregulázott könyvtárstruktúra
GUI a parancssori alkalmazásoknak, mert 21. század van vagy miaszösz.
Jól összeválogatott alkalmazások.
No gnome, No kde please.
Gyors, kicsi footprintű, scriptelhető, alkalmazás indító.(8% prociteljesitmény egy appletnek? No thanks.)
Normális grafikus filekezelő, és nem valami explorer utánérzés
Működő drag-n-drop.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "