ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
Scientific Linux 6.2 RC1Pat Riehecky tegnap bejelentette a Scientific Linux 6.2-es kiadásának első RC-jét. A SL - a CentOS-hez hasonlóan - a Red Hat Enterprise Linux forrásából közösségi munkával előállított Linux disztribúció. [ bejelentés | i386 ISO | x86_64 ISO ]
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzésekHUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 8% Összes szavazat: 592
Új felhasználók
InformációKövess minket!Partnerünk |
Jó dolog amit csinálnak, egész sokáig használtam. Egy bánatom van: sok olyan alap program is hiányzott, amire azért szükségem lenne (pl. timidity++). Nem találtam meg külső repóban sem, habár ez engem is minősíthet.
Hajrá nekik!
Azért mondjuk ennek a csomagnak a hiánya egy szerver distronál talán nem olyan meglepő.
A Scientific Linux-ot többnyire nem szervernek használják, ezért a felhasználók hajlamosak elfeledkezni arról, hogy ez mégis csak az RHEL-ből származik.
Én személy szerint úgy gondolom, hogy egy RHEL-admin számára kifejezetten sokat számítana, ha a napi deszktop rendszereként tudná ugyanazt az oprendszert használni, mint amit szintén napi szinten mogyoróznia kell. Nyilván ez kompromisszumokkal járható út csak. Van akinek ehhez elég a böngésző, másoknak kell mp3-lejátszó, csetprogram, stb.
Kollega azt gondolja, hogy neki midi-lejátszó hiányzik a boldogsághoz. (Persze nem tudom, hogy RHEL-admin-e egyáltalán.) Persze úgy gondolom, azért egy timidity++ forrásból telepítése nem szabad, hogy akkora ördöngősség legyen; persze az, hogy rpm legyen belőle, hogy utána normálisan karbantartható legyen, az egy csekély lépéssel már bonyolultabb.
Szerk: áfonya kollega src.rpm javaslata pláne járhatónak tűnik.
Fedorás src.rpm-ből nem sikerült elkészítened a csomagot?
http://download.fedora.redhat.com/pub/fedora/linux/updates/16/SRPMS/timidity++-2.13.2-25.fc16.1.src.rpm
Érzésem szerint nem lenne nehéz mert mindkét rendszer közeli rokon.
Muszaj, egyedul nem lehet:)
tompos
nem kell ezzel bajlódni f12-13 esetleg 14 csomag röhögve megy fel bármely el6 variánsra.
>>: sys-admin.hu :<<
Jóérzésű rendszergazda ilyet nem csinál azért :-)
Miért nem?
az el6 az gyakorlatilag a f12-13 alapon készült, annak a folytatása.
>>: sys-admin.hu :<<
Mert hosszú távon nem jól karbantartható. Mondok néhány példát, hogy mi lehet rossz ezzel kapcsolatban:
- lehet, hogy az F12-es és az EL6-os glibc között van valami apró különbség egy jelentéktelen függvényben és emiatt nem működik a csomag
- lehet, hogy a RedHat support azt fogja mondani, hogy "ejj, az az F12-es csomag okozza a hibát, hagyj minket békén"
- (lehet, hogy a supportnak igaza is lesz a kérdésben)
- lehet, hogy a gépre ráesik egy meteor, és újra kell telepítened 2019-ben - ebben az esetben sok sikert az F12-es csomag megtalálásához
- ha más lesz a rendszergazda, akkor ő vajon honnan fogja tudni, hogy honnan van ez a csomag?
Persze ezek a dolgok desktopon nem igazán számítanak, meg mindegyik ellen lehet védekezni teljesen jó módszerekkel - de valahol itt válik el egymástól a rendszert összetákoló Pistike és a rendszermérnök István.
Szerintem.
Ha bármit fölteszel, ami nem RHEL, akkor a support abba fog belekötni. Akár jogos, akár nem. Úgyhogy a support így is, úgy is bukta.
Elvileg src.rpm-ből megépíteni a legjobb, de ott is vannak szívások. Egyrészt föl kell tenni az összes dependencia devel csomagját. Itt már lehet gubanc, mert lehet, hogy az RHEL-ben nem olyan verzió van, vagy egyáltalán semmilyen nincs.
Aztán ha meg is épül a csomag, a SELINUX szabályokat kézzel kell legyártani. Ez a lépés teljesen karbantarthatatlanná teszi a rendszert. Legalábbis én még nem találtam ki rá automatikus megoldást.
Szóval szívás az élet. De aki RHEL klónt használ, az ne panaszkodjon, hanem készüljön föl ilyenekre!
ez így van, tapasztalatm. :S
>>: sys-admin.hu :<<
Ha RHEL klont hasznalsz, akkor eleve nincs support...:)
tompos
Huh, hát azért ez a timidity++ nem egy túlzottan fontosnak tűnő csomag, legalábbis nem a számomra. Nem vagyok benne biztos, hogy a RedHat-nél érdemes lenne emberi erőforrásokat pazarolni a támogatására, valószínűleg ezért nincs benne a disztribúcióban.
Egyébként meg ha a RHEL/CentOS/SL hármasból akarsz használni valamit desktopon, akkor úgy érdemes beállítanod a rendszeredet, hogy a következő repositorykat használja:
- alapdisztribúció (nyilván)
- EPEL (http://fedoraproject.org/wiki/EPEL)
- repoforge (http://repoforge.org/use/)
- bármi más, egyedi igényekhez igazítva (adobe, videókártya-vezérlő, vmware stb.)
A yum-priorities pluginnal pontosan ebben a sorrendben érdemes prioritást is rakni a repokra. Ami fontos, hogy a repoforge ne előzze meg az EPEL-t, mert abból bizony galibák lehetnek.
Az ezekben összesen fellelhető csomagok már általában elegendőek szoktak lenni desktopra is, bár az tény, hogy így sem fog senki olyan friss csomagokat kapni, mint egy Fedora, Ubuntu, Arch vagy Gentoo esetében.
Még egy megjegyzés: szerveren viszont a fentebbi repok közül inkább csak a base és indokoltabb esetben az EPEL szerepeljen - a RedHat support csúnyán szokott nézni a többire, ha valami galibával felhívod őket.
+1 az EPEL-re
Alapvetoen nem szerverre hasznaltam, hanem mert a Xilinx ISE igazan jol RHEL-en erzi jol magat, ami meg a munkamhoz kell. Nyilvan fel tudok.ganyolni magamnak barmit, ha artol van szo, csak meglepett a dolog, mert a Debian csomagvalasztekahoz voltam szokva.
Az itt feltett kérdéseimre tudnátok írni pár sort? Előre is köszi.