Mai Linuxos szívás

A linux disztribúciók egyik diszkrét bája, hogy mindegyikőjük testre szabott szopatással kényezteti a felhasználókat. Az egyik ilyen dolog a csomagkezelők által okozott kisebb-nagyobb malőrök. A dependency hell nevű dolog talán a legismertebb de a személyes kedvencem az "elefánt a porcelánboltban" mentalitás.
Egy telepített rendszer általában csak a feltelepítéséig szűz, utána a felhasználó megpróbálja a személyes igényeinek megfelelően hangolni. Ennek következtében, egyik másik részen módosít, adott esetben kicserél komponenseket. Aztán jön a rendszerfrissítés. Ugyebár, egy intelligens telepítő képes arra, hogy felismerje a rendszerben bekövetkezett változásokat és ennek megfelelően vagy piszkálja a felhasználót, vagy kihagyja az adott komponens frissítését. Csak épp ilyen nem létezik.
Az általam használt rendszereken az egyik dolog amit rendszeresen kézzel telepítek, az a kernel. Ennek az-az oka, mert így lehet biztonsági frissítésekkel naprakészen tartani a rendszert, jobb szeretem ha az adott rendszer driverei nincsenek modulba forgatva és így nincs a rendszer az udev kénye-kedvének kiszolgáltatva, plusz elég sok olyan alkalmazást futtatok amik realtime OS funkciókat követelnek meg. Ezekkel nem is lenne gond, csakhogy a dependency hell miatt egyes forrás csomagok telepítése megköveteli az épp aktuális kernel csomagból történő telepítését, és ezen ponton jelenik meg a csomagkezelő diszkrét bája, mert rendszerfrissítésnél csuklóból lecseréli a futó kernelt. Mivel cseszik figyelmeztetni az embert, ezért aztán a következő bootnál derül ki, hogy a gép merevre kernelpánikolja magát. Ez még nem is lenne gond, ha az adott gép nem az embertől 50 kilométerre, egy oszlop tetejére lenne kitéve.

Hogy miért kell újraindítani egy amúgy tökéletesen működő rendszert?
Mondjuk azért mert a sikeres, űberfasza, topon lévő, istenek az-az a kernel fejlesztők tíz év alatt nem képesek egy olyan ici-pici featuret implementálni rendesen mint az USB portok host oldali power managementje.
Nem lehet olyan bonyolult dolog, hiszen a geci, szemét, mocsok, disznó Microsoftos lámák még az USB2.0 előtt a Win98-ban képesek voltak implementálni.
Mondjuk azon is el lehet polemizálni, hogy vajon miért dobja el egy hét után a v4l az addig tökéletesen működő kamerát? Sanda gyanúm, hogy a szofisztikált kódjában lehet egy fasza túlcsordulás, amitől átmegy emoba a szentem. Hiába no, az ember tanulja meg naponta egyszer újraindítani a gépeit.
Különösen rendszerfrissítés után.
Végülis süt a nap, lehet élvezni a szép havas tájat.
Extrémsportolni a koromsötét éjszakában a lejegesedett oszlopon.
Iyenkor szeretnék szakmát váltani, és elmenni mondjuk ludditának vagy "kernelfelhasználóielégedettségkommunikációsmanagernek", ez utóbbihoz még baseballütőt is csatolnék a CVmhez.

Stay tooned...

Debian
(Igen, tisztában vagyok azzal, hogy "létezik olyan kapcsoló amivel" és "a XY másik disztóval ilyen nincsen", viszont napi 10x óra munka után földimogyoróval és vatikáni valutával fizetett másod, harmad, hatodállás miatt nem vagyok hajlandó:
a, órákat keresni egy szájbavert opciót
b, megtanulni egy másik disztribúció faszságait.
Majd esetleg akkor, ha főállásban ez lesz a feladatom.)
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Igen, az élet kényszerít. Mivel nem IT bohóc vagyok, ezért a napi munkámhoz nincs szükségem 4-5 linux disztribúció alapos ismeretére, és mivel kedvenc hobbielfoglaltságom különféle disztribúciók telepítgetése, ezért talán elnézhető, hogy az alapján választottam ki, hogy melyik disztribúció támogatja a legtöbb architektúrát és tartalmazza a legtöbb csomagot.

Számomra az operációs rendszer csak egy szerszám, mint mondjuk a kalapács. Mint ilyen nem érdekel, hogy milyen a színe és a formája az adott kalapács nyelének, hanem a kalapácsként való használhatósága. Mivel egy kalapáccsal sok mindent lehet csinálni a falbontástól kezdve a szobrászkodásig, és én ezek közül mindegyikbe belekontárkodom, ezért olyan kalapácsra van szükségem ami minden célra megfelel. Legfeljebb bontásnál kicsit kisebb darabot ütök ki egyszerre, a szobrászkodásnál, meg kicsit kisebbet ütök a vésőre. Ami fontos, hogy a kalapács ne essen szét. Ne kelljen naponta megigazítani a fejét, ékeket verni bele, nyelet cserélni. Egy szerszám lényege, hogy azzal új dolgokat tudjon létrehozni az ember, nem pedig, hogy azt reszelni kelljen. Erre vannak a szerszámkészítők. Csak épp a nagy probléma, hogy ezek a szerszámkészítők vagy rosszul végzik a munkájukat, vagy épp művésznek képzelik magukat és olyan nyelet álmodnak a kalapácsnak amit megfogni sem lehet. Ilyenkor minden kalapácshasználó emberben jogosan felmerül a kérdés, hogy az ilyent miért akarják mindenkire ráerőltetni, és miért nem egy vitrinben tartják.

Hogy miért kell az embernek 4-5 másodállást csinálni, arról talán egy másik alkalommal.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem szólom le az IT szakemberek, csak annyit akarok érzékeltetni, hogy ugyanabban a cirkuszban, más porondon lépünk fel.

Nem telepítgetek különféle disztribúciókat, és csak olyan szinten akarom megismerni az általam használtat, hogy azt használni tudjam a céljaim eléréséhez. Maradva a kalapácsos hasonlatnál: Ha egy szöget akarok beverni akkor nem érdekel, hogy a kalapács nyele milyen fából van, hanem az érdekel, hogy a többi kalapácsnál megismer fel-le mozgatással betudom verni a szöget vagy sem. Ha nem akkor elvárom, hogy vagy ne kalapácsnak nevezzék az adott eszközt, vagy olyanra csinálják a nyelét, hogy eszembe se jusson szögbeverésre használni.

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

( uid_18247 | 2010. 02. 08., h – 11:17 )

Take it easy, sir, örülj, hogy nem kell Wint használnod. :)

( pala | 2010. 02. 08., h – 11:32 )

Szerintem itt inkabb az a problema, hogy a custom dolgaidat szeretned debian-os supportal hasznalni :)
1) Le tudsz te is magadnak forditani minden biztonsagi frissitest a te igenyeidnek megfeleloen.
Tudsz belole .deb csomagokat kesziteni, ezeket akar sajat repo-ba belerakni.
2) Le tudod ellenorizni, hogy mit fog tenni a csomagkezelo pl.: a --simulate kapcsoloval es ez alapjan megfeleloen el lehet jarni.

Linux alatt soha nem lesz egy Big Red Button, amit ha megnyomsz akkor a rendszer pont ugy fog mukodni ahogy azt epp elkepzeled, de ha nem tetszik valami nyugodtan atirhatod es ez igy van jol.

-== If you want peace prepare for waR ==-

( bambano | 2010. 02. 08., h – 11:56 )

pebkac
holdra teszed a kernelt, leszeded a gyárit, oszt jónapot.
mondjuk a webkamerák támogatása nem csak a debianban, de úgy általában minden linuxban mostohagyerek, a legzűrösebb terület.

ha pedig valamit nem akarsz megkeresni órák alatt, akkor itt van ez a hup nevű dolog, ahova nem csak a kernelkommunikációdat lehet beírni, hanem a kérdéseket is.

javaslom még átgondolni a "működő cuccot nem babrálunk" filozófiát.

Ha holdra teszem a kernelt akkor a vele függőségben lévő csomagok sem fognak frissülni. A kernelkarbantartáson kívül, meg hadd ne kelljen még a további n száz csomagot is kézzel karbantartanom.

A fórumos segítségkérés csak abban az esetben opció, ha több órás googlezés és dokumentációtúrás nem vezetett eredményre, és még ebben az esetben is több órámba telik a pontos ok kiderítése, ugyanis nem biztos, hogy mondjuk egy ioctl-el kapcsolatos bugra lesz kompetens. (Lásd: http://hup.hu/node/81648 Ez utóbbinál, durván 9 munkaórát töltöttem googlevel és különféle böngésző, ablakkezelő, flash-plugin próbálgatással még úgy is, hogy az egyik fórumita megmondta a "helyes" megoldást, mert a helyes megoldás valójában félmegoldás.)

Működő cuccost nem babrálunk egy szép elv, csak kár, hogy egy élő rendszerben nem használható.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"Ha holdra teszem a kernelt akkor a vele függőségben lévő csomagok sem fognak frissülni.": ezt így nem nagyon látom... ha az általad gyártott kernel csomag provide-ol megfelelő verziószámú kernelt, akkor a tőle függő csomagok fognak update-elődni.

"Működő cuccost nem babrálunk egy szép elv, csak kár, hogy egy élő rendszerben nem használható.": nem nagyon van más működő elv élő rendszerre...

Szerintem o nem szofisztikalja annyira szet magat, hogy debilany csomagot gyartson a kernelbol. Fogja, felrakja, megy. A debian csomag gyartas egyebkent se egy leanyalom, az ember nem feltetlen akar folyamatosan azzal szorakozni.
A make deb meg nem debian kompatibilis, csak egy deb csomag. Attol meg ugyanugy sikoltozni fog a hianyzo cuccok miatt.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

attól, hogy *szerinted* én mennyire szofisztikálom szét magam, még tudhatom, hogy hogyan kell kernel csomagot csinálni...

a debianos csomag gyártása egy darab utasítás, ha leszámítjuk azt, hogy előtte az általad használt custom patch-eket rá kell tenni. csak nyilván egyszerűbb fikázni a debiant, mint utánanézni, hogy mit kell csinálni vele. Ezt hívják az informatikus szlengben pebkac-nak.

Kérdés csak az, hogy vajon nekem kifizetődik-e 3 hetente új csomagot gyártanom, megküzdenem a dependency hell-el, vagy beütni a parancssorba a "make intall"-t? Kérdés kifizetődik-e annak a párezer amatőr felhasználónak, akiknek nincs ideje egy saját repot managelni, hogy az összes egyedi dolguk fusson.
Nevezheted pebkac-nak a dolgot, hiszen a probléma okozói egyben a disztrib fejlesztői, akik a fenti embereknek az életét keserítik meg azzal, hogy feltételezik, hogy az operációs rendszerüket alapbeállításban fogja mindenki használni. Ez feljebb emlegetett művészke felfogás, viszont ez esetben a disztribet kéretik vitrinbe tenni és nem pedig működő OS-ként aposztrofálni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

de magyarázd már el nekem, mennyivel bonyolultabb beütni egy make-kpkg --revision=mykernel0001 binary utasítást, mint egy make installt?

Letöltöd az utolsó debianizált kernel forrást, rápakolod a saját patch-edet, beütöd a fenti sort meg egy dpkg -i-t és kész.

Mi ebben a bonyolult, komolyan nem értem. Nincs dependecy hell. Én simán csereberélek gyári kerneleket és soha nincs belőle semmi probléma, milyen dependency hellről beszélsz? Írj már egy konkrét példát meg hibaüzeneteket, hogy lássuk, mi a tényleges gond.

de rászánok 10 percet, megnézek egy friss stock kernelt, hogy mennyi idő debian csomagot faragni belőle, mert kezd érdekelni.

Bonyolultabb. Csak szamold meg a karaktereket.
Azon felul a dependency hell igenis letezik, mert azon csomagok, melyek ugynevezett modulcsomagoktol fuggnek (ez is de marhasag... vagy forgassa helyben forrasbol, vagy legyen a kernelcsomag resze), azok sapogni fognak, mert neked nem az, es nem olyan verzios kerneled van, mint amit ok elvarnak. Hogy? Az ember ne telepitsen ilyeneket? Oke, de akkor mas csomagok se fuggjenek ilyenektol.

Tenyleg, komolyan nem ertem, miert kell az embernek elsajatitani azt, hogy a kisujjat muszaly kinyujtani, es muszaly a kalapacsot fejjel lefele tartani ahhoz, hogy az az atkozott szog bemasszon a falba. Nem en akarok az eszkozhoz idomulni, az idomuljon hozzam, mert kettonk kozul nem en vagyok az eszkozert.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Bonyolultabb. Csak szamold meg a karaktereket.": rotfl

Oké, felraktál az oszlop tetejére egy gépet a webkamerádhoz, abban pl. kell az ati radeonok 3d gyorsítása az x alá?

"miert kell az embernek elsajatitani azt": nem kell. egy linux üzemeltetése során sok területen lehet a szerszám rossz végére kerülni, a disztrók abban különböznek, hogy melyik melyik területen akar valami megoldást adni. A debian a csomagmenedzsment terén csinált jó dolgokat, cserébe, hogy rendes csomagmenedzsment van, tartanod kell magad bizonyos szabályokhoz. Tehát nem "kell". Ha kell a csomagmenedzsment, akkor kellenek a szabályok. A te döntésed. Eldöntötted, amikor debiant raktál fel.

De továbbra is várom a konkrétumokat. Egyébként meg, ha jól emlékszem, ha csak modulról van szó, azt a debianos kernel teljes újrafordítása nélkül is meg lehet csinálni. Úgyhogy ha a kernelt nem fordítottad újra, nincs dependency hell.

idezet a topicnyitobol: "elég sok olyan alkalmazást futtatok amik realtime OS funkciókat követelnek meg." SZVSZ a deb kernelbe default nincsenek ilyten kepessegek, plusz a deb default kernel sokszor tulsagosan is regi egyes hardverekhez (na jo, sokhoz)
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

te most szándékosan hülyének tetteted magad, amikor a default debian kernelhez ragaszkodsz arra válaszolva, hogy én debianizált kernel használatát javaslom???
A debian repokban van 2.6.32-es kernel, amiből az elsőt 2009. december 3-án adták ki stock verzióban.
Milyen olyan hardvered van, ami 2009. december 3-án még nem volt támogatva, azóta meg igen, ÉS azt neked kötelezően fel kellett tenni az oszlop tetejére?

A magam részéről a továbbiakban igyekszem mellőzni ezt a bejegyzést, mert egyre inkább úgy látom, hogy itt nem arról van szó, hogy a debian rossz vagy a debianban nem lehet valamit rendesen megcsinálni, hanem arról van szó, hogy valahol összeszedtél valami frusztráltságot és a debiant választottad ki arra, hogy levezesd rajta a dühödet.

Szíved joga, de ilyen topicban ne várj érdemi segítséget.

Utolsó próbálkozásként: miért nem szeded le az utolsó debianizált kernel forrást és fordítod le magadnak újra??? Mielőtt megint gyógyegérkedni kezdel: nem a default debian kernelről beszélek és nem az utolsó stock gyári kernelről, hanem arról, ami kint van a debian repókban, legfrissebb. És ismételten megkérdezem: mi az, ami nincs meg a gyári kernelben és neked fontos, hogy ott legyen az oszlop tetején? De nem melléduma kell, hanem url patch-ekre vagy driverekre.

1) A nicket illik elolvasni, nem nekem van az oszlop tetejen gepem, hanem Hienanak, a tobbi stimmel.
2) A debianizalt kernel az milyen? En eddig ketto fele kernelrol tudok a temaban:
- amit az apt-get kernel-source rak fel (ez van a debian package repository-ban)
- amit a kernel.org -rol toltok le.
Jo, hogy dobalodzunk kifejezesekkel, csak azok szamara, akik esetleg mereszelnek nem Debian hasznalok lenni, talan erthetoen is lehetne fogalmazni.

A topicnyito pedig egyertelmuen leirta, hogy realtime OS cuccok kellenek neki a kernelbe, ami mindig is kulon patchkeszlet volt (GIYF). Ha nem tudsz az interneten keresni, ne rajtam vezesd le a frusztraltsagodat, nagyon kerlek.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"- amit az apt-get kernel-source rak fel (ez van a debian package repository-ban)": ennek a tisztességes neve a debianizált kernel.
"- amit a kernel.org -rol toltok le": ennek meg a stock kernel a tisztességes neve.

nem frusztráltságot vezetek le, hanem felhívom a figyelmet arra, hogy nem illik olyanért hibáztatni a debiant, ami nem a debian hibája, hanem a felhasználóé.

A kérdés pedig nem az, hogy tudok-e az interneten keresni, hanem az, hogyha megmondod, mivel patkolod a kernelt, megnézem, hogy az valójában mekkora munka, mert ez neked segítHET. Ha nem mondod meg, nem fogom megnézni.

> Kérdés csak az, hogy vajon nekem kifizetődik-e 3 hetente új csomagot gyártanom

Mint tudjuk, a linux by design ilyen (véleményem szerint szar design, de az egy más történet).

Más nézőpontból viszont folyamatos munkát biztosít a vele fogalalkozó embereknek.

Ne felejtsük el, hogy a Microsoft által tátongva hagyott különböző hiányosságok toldozásán nem egy cég nőtt világméretűvé.
__________________________________
2e845cb4c3a5b5bd6508455b1739a8a2

Sztm egy checkinstallal, és vmi saját repóval egészen jól kordában lehetne tartani a problémáidat.
Azt is érdemes lenne megvizsgálni, hogy neked -a hasonlatoddal élve- tényleg a kalapácsra van-e szükséged, vagy éppen egy csavarhúzóra...
Egyébként mi az a csomag, ami egy HOLD esetén nem frissülne, és nem a kernelhez, vagy vmi fejlesztői (-dev) stuffhoz tartozik?

( BaT | 2010. 02. 08., h – 15:29 )

Usb power managment alatt mit értesz? Mert pl. nálam usb wifi cuccal volt olyan, h. suspend előtt szoftveresen lehúztam az eszközt, mert csak így ment a resume. Valami /sys-es vagy /procos trükközés volt, nem 5 perc volt rájönni, de működött.

( zdesigner | 2010. 02. 08., h – 17:08 )

Ismerős érzések.
Mióta Arch Linuxot használok, izgalmasabb lett az életem. Ez különösen akkor igaz, ha látom, hogy frissülne az X.org, az nVidia driver, a libjpeg vagy a libpng. Szóval résen kell lenni, mit ír ki a pacman.
Ha ezeket a csomagokat meglátom, mennek rögtön IgnorePkg listára, átolvasom az Arch fórumon a káromkodásokat hibabejelentéseket és azok elhárításait a válaszokat rájuk, hogy lelki erőt szerezzek, majd ezt megismétlem egy héttel később is kb. :), végül leveszem az IgnorePkg listából őket és imádkozom frissítek.

Stabilabb, ha hajlandó vagy várni pár napot, míg követi a legacy nVidia bináris driver a rendszer többi részének frissítését. Illetve ha nem kell mindenfélét IgnorePkg-re raknod, mert kdemod-legacy repóból feltett 3.5-ös KDE-t használsz, mert a KDE4 vaporware ("-ez a KDE 4.3 már a KDE4? -nem."). ;) A legutóbbi eset a KDE 3.5 miatt egy problémás libjpeg frissítés: Frissült a csomag, de az én KDE-mnek régebbi libjpeg kellett, szóval AUR-ból fordítottam egy régit is az új mellé.
Ha mindenből kész vagy az újat használni és a hardvered is támogatja, akkor király az Arch. Meg úgy egyébként is. ;)

Dehogynem...

Most volt nagy libjpeg meg libpng frissítés, csak várni kellett egy kicsit, hogy az összes csomag kövesse a változásokat. Előre kiplakátolták mindenhova, hogy mindenki legyen résen, különben pórul járhat. Aki ennek ellenére virgonckodott, azt tényleg meglepetés érte