Melyik Linux disztribúciót preferálod szerver célra?

Linux

archlinux
1% (11 szavazat)
debian
51% (427 szavazat)
gentoo
6% (51 szavazat)
mandrake, mandriva
1% (8 szavazat)
red hat enterprise linux, centos, oracle enterprise linux, scientific linux
13% (108 szavazat)
slackware, zenwalk, slamd64, slax, bluewhite64
3% (27 szavazat)
suse linux enterprise server
5% (45 szavazat)
ubuntu
20% (165 szavazat)
Összes szavazat: 842

( cheeky v | 2009. 11. 26., cs – 12:54 )

Na ha ennyire lemaradtatok a kategóriaszavazáskor... Ezért ugyan biztos nem jár majd HOVD plecsni, de akit az érdekel, mely disztrók népszerűek szerver szinten, most tolongjanak.

te 5 év 49 hét minusz 1 napig komaba voltal?...

anyway eleg huje felsorolas..
meglep h valaki mandrake et hasznal szerveren .. es te berakol zenwalkot sci linux, slax meg ilyeneket?

arrol nem is beszelve h csomo linuxot kigyatal... fedora.. opensuse .. az egesz szavazas szar ahogy van.. nem is tom trey miert tette ki

Szerverre fedora-t rakni botorság, aki azt a környezetet szereti, és szerverre vágyik, beáll a RHEL/Centos táborba...
Igen, odatehettem volna melléjük a Fedorát, nem tettem, mert számomra az desktop fókuszú disztró.

Minden elégedetlennek figyelmébe ajánlanám, hogy a HOVD topikban való sírás-rívás mellett mindenkinek lehetősége volt mindenféle javaslatokat tenni. Sőt, mindenkinek lehetősége volt az ottani kategória szét off-olása helyett kiírni ezt a szavazást nálam jobban.
Én lettem, aki kiírta, én állítottam össze a listát, ilyen lett.

Konkrétan a Slack-es sor át lett emelve a disztró szavazásból. Nem ismerem az összes flavor-t, így nem vacakoltam azzal, melyiket vegyem ki.
OpenSUSE -> fáradjon a SLES sorhoz, bár megint csak desktop fókuszú.
Sci Linux-ból hallottam, hogy fürtöt építettek, meg HPC célra használták, tehát szervernek elmegy. Amúgy meg full RHEL kompatibilis akar lenni.

Ha neked ez szar, akkor legalább a hülyét tanuld meg leírni, és ha megvagy, csinálj jobbat.
Meg pl ne tartsd magadba, mi hiányzik, mert különben legközelebb is egy hülye szavazás kerül ki.

Mások sírtak ezen az oldalon ezekért az adatokért.
Én javasoltam egy szavazást erre az oldalra, hogy legyen meg az örömük.
Trey kirakta a szavazást, mert arra érdemesnek találta.

Te meg rinyálsz, mert nem tetszik valami. De azon kívül, hogy rinyálsz, mit csináltál? Nem tetszik? Opciók:
- Csinálsz jobbat.
- Nem szavazol.
- Nem is nézed meg a szavazást, mondván a Solaris hívő lelkedet felzaklatná.
- Nem is látogatod azt az oldalt, ahova ilyen szar szavazások csak úgy kikerülhetnek.
- Hallgatsz.

"szamomra"
Mar megbocsass, de ha szavazast irsz ki, a legutolso ami szamit, az a te velemenyed. Arrol nem beszelve, hogy olyan allat szerintem mar reg nincs, aki Mandrake-t hasznalna egyaltalan barmire. Tessek mar vegre megjegyezni hogy az Mandriva.
-- 


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

Ha szavazást írok ki, azt, hogy miből lehet választani, én szabom meg. Tehát igen vaskosan számít az én véleményem.

És igen, van olyan állat, aki még mindig Mandrake szervert üzemeltet. Ne kérdezd, miért, én sem értem, de van. Neki valahogy elrepült az elmúlt négy év, vagy nem értem. Meg azt sem, hogy mit rázod a fát, a szavazásban mindkét név kinn volt, okkal.

Bocsi, hogy belevau, DE:

Szerintem is hiányos a szavazás, így az eredménye is megkérdőjelezhető. Kihagytad gyakorlatilag az összes magyar fejlesztésű terjesztést (UHU-Linux, Frugalware és BlackPantherOS, kivéve, ha van még más is). Ja, hogy szerinted ezek "desktop fókuszú" disztribúciók? Érdekes, hogy a Mandrivát is annak tartod, de még beletetted. A Fedorát, mint a legnépszerűbb és legjobb terjesztések egyikét pedig lazán kihagytad. Tök értelmetlen az egész.

Továbbá, honnan vetted, hogy egy "desktop fókuszú" Linuxot nem lehet szerveren használni? Igaz vagy sem, de a Linux az Linux, bármilyen terjesztés is legyen, azaz, ha teszel hozzá egy megfelelő szakértelemmel rendelkező rendszergazdát, akkor egy stabil és biztonságos szervered lesz, ha pedig egy szakbarbárral csináltatod, akkor hiába adsz neki akármilyen profinak mondott Linuxos szerver-specializált OS-t az eredmény egy fos lesz. Mint az életben megannyi területen, itt is az ember az, akinek van értéke, ha minőségi munkáról van szó, és nem a gép vagy a szoftver.

Ergo, hibás a gondolkodásmódod -> rossz szavazás!
Bocsi, de ez van...

--

nTOMasz
"The hardest thing in this world is to live in it!"

( Dgzt | 2009. 11. 26., cs – 17:25 )

Énnekem otthoni asztali gépemen és laptopomon is Debian van. Egykori szervergépemen is ez volt. Énszerintem az egyik legjobb disztró, én elégedett vagyok vele. Csomagok közt van minden, nem kell vele szarakodni, már csak be kell állítani őket.
---------------------------
Oszt jónapot!

( dikki | 2009. 11. 26., cs – 17:58 )

én külön vettem volna még a centost és a rhel-t. nem mindegy, hogy vki csak azért használja-e mert "enterspájz és ingyérbe kerül" vagy mert előfizet rá.

( iron v | 2009. 11. 26., cs – 18:11 )

"Egyéb, leírom hozzászólásban:"

1. mindig a megfelelőt a megfelelő célra (tűzfalra minek rakjak centos/rhel/sles/debian/ubuntu, van rá megfelelőbb)
2. sok disztró hiányzik a felsorolásból

2. Igen, vettem, elnézést. Szűk volt a fantáziám. Majd legközelebb jobban sikerül.

1. Ezt a választ nem tudom értelmezni. Én is mindig a megfelelő disztrót használom a feladathoz. De ettől még van kedvencem. Sőt. Kedvenc feladatom is van. És lám, a kettőből már ki is jön, melyik a kedvenc (ó bocs, preferált) szerver disztró számomra. Nem olyan nagy feladat, próbáld meg. Meg mindenki, aki erre a badarságra +1-ezik.

[off]
kedvenc feladatom nincs. az munka...
[on]
van, Frugalware, bar aki errefele olvasgat, az talan meg emlexik ram :D
azonban a Frugalware sem alkalmas barmilyen feladatra. nemreg kiserleteztem Ubuntu ltsp kornyezettel, de ugy 70 user folott akkora hatast dobott a rendszer, hogy orom volt nezni.

( Zahy v | 2009. 11. 26., cs – 18:57 )

OFF on
Bakker, 800 fölötti olvasás van, és 200 alatti szavazás. Akkor azért lássuk be, nem volt akkora marha nagy igény arra a szavazásra, csak jó volt egy kicsit szétoffolni a topicot.
OFF off

( gna | 2009. 11. 26., cs – 20:23 )

Egy kollégám szerint az ubuntu az ördög, és a centos most az isten.
Szerintem meg jo a debian mert azzal kezdtem tartósan szerverezni, és support szerződések nélkül is minden problémát meg lehetett oldani. Aztán ubuntu lett a folytatás mert nem szeretek mindig forgatni ha valami frissebb kell. Majd lett centos mert az van 64bit paravirtben xenserver templateben. De a szavazatom ubuntu, mert ha kell azzal is megvan a support szerződés lehetősége, és nem szanaszét mindenhonan kell szoftver csomagokat beszereznem. ennyi

Meg hogy nem sokban ter el?! Hat... ha zongorazni lehetne a kulonbseget, hangverseny kerekedne belole, de egyebkent tenyleg alig ter el.

Nem csak hogy frissebb es bovebb a csomagvalasztek, de sok esetben eppen ezert gyorsabb is.
-- 


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

A debian es az ubuntu es locitrom es esti feny. Sajat dokumentacioja nulla, QA es kodminoseg meg erosen tendal afele. Lattam mar mindkettobe olyan megoldasokat, hogy a keszitojenek a hatan vertem volna szet a billentyuzetet. A Google meg a kozosseg meg nagyon szep dolog, de ha SLA-d van allasidore, akkor nincs ido szep lassan elokeresni a problemat, hanem adott idon belul eszkalalnod kell - es hoppa, Debian eseten abszolut nincs hova. Ubuntu eseten elmeletileg lenne - bar en nagyon keves cegrol tudok, aki megvette volna az Ubuntu szerverei melle a tamogatast - cserebe az Ubuntu szervernek szinte teljesen alkalmatlan, a legvaratlanabb helyzetekben kepes mely depresszioba esni, magaval sodorva az epp a kozeleben tartozkodo admin(oka)t is.
-- 


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

Aha. A fizetős k. drága RHEL supportja meg a pofádba hazudik, és csúszik miatta egy projekted majdnem 2 hónapot, és rohadtul nem hajlandóak foglalkozni a problémával. Nesze neked SLA. Nincs rosszul összerakva a RHEL, nem ezt mondom, egész szerethető is, használhatónak mindenképp használható, de a supporttal ne jöjjön senki villogni, mert egy kalap szar. Tetű egy cég ebből a szempontból, és nem vélem felfedezni a javuló tendenciát már évek óta.

Szóval tudásmegosztás és menedzsment szempontból épp ugyanott vagy vele, mint bármelyik "community OS"-szel.

Van egy nagy kulonbseg. Lehet hogy csuszik a projekt, viszont ha ugy kotod a support szerzodest, akkor egyreszt a RedHat orra ala lehet dorgolni, hogy nem ilyen ideju megoldasra lett kotve a szerzodes, masfelol a fonok orra ala lehet dorgolni, hogy te mar eszkalaltal, tehat reszedrol be van tartva a vallalt kotelezettseg, a kulso ceg hibajat nem sozhatja a nyakadba.

Nem tudom, hogy ezt egy community OS eseteben hol tudod megtenni.
-- 


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

Ez nekem kicsit sunyi stílus, hogy lesöpörjük magunkról a problémát, és áthárítjuk, hogy "igaziból" 3rd party a hibás.

Most akkor elvállaltad, hogy supportálsz, vagy nem?
Ha igen, akkor csináld!

Ha meg RHEL-t vesz vki. akkor nem értem miért akar téged még közbeiktatni. (Meg azt sem, hogy ha te vállaltad a supportot X felé, akkor az, hogy neked meg RH felé van support szerződésed, a téged az X felé vállalt SLA alól miért ment fel, hogy te tovább"eszkalál"tad...)

Nem érted.

X dolgozik Y cég IT osztályán. Y cég kötött egy SLA-t Z céggel.

A cucc éppen nem működik. X megnézte, kiderítette, hogy valami olyan módon szar, amivel nem tud mit kezdeni. Tehát eszkalálja a problémát.

Ha jön a főnök, hogy Xkém, ezt kurvára meg kéne csinálni most azonnal, mert egyébként beüt a mennykő, Y cég fizet Z cégnek, stb., akkor X mondhatja, hogy bocs főnök, a RH supportra várunk. X fedezve van.

Persze nem ezért köt Y cég support szerződést, hogy a saját alkalmazottjának jó legyen, hanem azt remélik tőle, hogy majd a hibákat a support megoldja, és így Y-nak nem kell Z számára utalni a zsetont.

Nekem két cég supportjával van csak tapasztalatom. Az egyik az én összes problémámat megoldotta, vagy olyan infót adtak, ami alapján elindulva én meg tudtam oldani.
A másik cégtől is volt, amire kaptunk választ, meg volt olyan is, hogy a rendszer működése miatt bebukott egy projekt, és ez után kicsit több, mint egy évvel értesítettek, hogy ja, egyébként van valami senki által nem ismert modulban egy függvény, amit használva az adott működés az ügyfél által elvárt módra változtatható. Szépen megköszöntük, de mondtuk, hogy kicsit elkéstek ezzel.

Igazából a cikkben sehol nem találkoztam azzal, hogy a szerver milyen célokat fog kiszolgálni, és milyen vállalt felelősséggel kell azt üzemeltetned!

Ilyen megfontolásból, továbbá abból a tényből kifolyólag, miszerint a centos és a RHEL egymással binárisan kompatibilis, ugyanazon rendszer számodra megfelelő lehet akkor is, ha saját részedre kell egy server célokat szolgáló rendszer, vagy egy nagyvállalati szuperkiszolgáló, aminek minden köhögésére 20 ember figyel. Nem beszélve arról, hogy az egyikben szerzett tapasztalat nem elhanyagolható a másiknál sem.

( nucc | 2009. 11. 26., cs – 23:27 )

Nalam Gentoo-val fuszerezett Debian fut a szerveren... Ha valasztanom kene akkor Debian, de vannak vele fenntartasaim.

( arpi_esp v | 2009. 11. 26., cs – 23:55 )

slackware alapok (de nagyon csak alapok) aztan a lenyeg forrasbol, adott igenyekre es hardverre konfigolva/forditva.

A'rpi

Ezt nem gáz karban tartani? Ha biztonsági patch-ek jönnek ki az általad használt csomagokra, akkor azokat mindig felrakod? Vagy azokon a hardvereken a biztonság nem lényegi szempont?
Azért kérdezem, mert az még értem, hogy ha összeállítasz egy rendszert, és az megy, nem bugos stb., akkor fölösleges a programokat frissíteni az új feature-ökért, hiszen azokra nincs szükség. No de a security update-k azok még kellenek, kivéve, ha a security nem szempont. (Olyat is el tudok képzelni.) Vagy rosszul látom?
Csaba

Nem a karbantartás a gáz, hanem hogy ezáltal erősen kötve vagy a rendszergazdádhoz. Mondhatni kiszolgáltatott helyzetbe kerülsz, ahol a rendszergazda diktál. Mindez persze a megrendelő vagy munkaadó szemszögéből. Saját servernél ez nem szempont, ott amúgy is kötve vagy a rendszergazdához. :-)
Én megrendelőként vagy munkaadóként olyan, elterjedt disztribúciót választanék, amelyhez könnyen találok a munkaerőpiacon szakembert. Így én - a megrendelő vagy munkaadó - kerülök jobb helyzetbe.
Ismered a mondást? "Nincs pótolhatatlan ember. Ha mégis, azonnal szabadulj meg tőle."

Ave, Saabi.

Ismered a mondást? "Nincs pótolhatatlan ember. Ha mégis, azonnal szabadulj meg tőle."

Na ehhez ennyit:

(1) nem biztos, hogy a pótolhatatlan az, aki annak tűnik.
(2) ha valóban pótolhatatlan, akkor nem kirúgni kell, hanem
megfizetni, különben nagyon gyorsan a konkurrenciánál köt
ki. Egy cég _valódi_ arculatát a pótolhatatlan emberek
határozzák meg. Pl.: elég mókás lett volna, ha M. Sch. -t
kirugják a Ferráritól, mondván, hogy pótolhatatlan.

Továbbá: szerverüzemeltetői szinten _NINCS_ pótolhatatlan
ember. Ha a slackware jól ketyeg, akkor keresek egy olyan
embert (ha az eddigi elszemtelenedett), aki ért hozzá.
Ha nem jól ketyeg, akkor kirúgom a rendszeregazdát és az
új ember hozza azt, amit ő szeret, mert ezzel a
rendszerrel lesz a leghatékonyabb, azaz számomra a
legolcsóbb. (A migrálási költségekkel együtt is meg
fogja érni - amenyibben az új ember _VALÓBAN_ megfelelő.)

Hogy a témához is hozzászóljak: nálam mindenhol (25-30
gép) Slackware van.

> Sol omnibus lucet.

Szeretem, amikor szándékosan nem értik amit mondani
akartam. Annál a cégnél, amelynél egy olyan bizalmi
állásban, mint a rendszergazda, nagy a jövés-menés, ott
a legkisebb gond a szervermigrálás, más nagyságrendű
problémák vannak, elsősorban a vezetésben.

> Sol omnibus lucet.

Kérdés az, minek kell neked rendszergazda. Azért, hogy
végrehajtsa az utasításokat, vagy azért, hogy megoldjon egy
problémát. Én végig az utóbbi kategóriáról beszélek. Az
utasításvégrehajtók bár rendkívül készségesek tudnak lenni,
de mégiscsak csicskák és nem rendszergazdák.

> Sol omnibus lucet.

Igen, azonban nem mindegy, hogy a problemat csak ugy kepes megoldani, hogy az elso parancs amit kiad a format c: vagy kepes a meglevo rendszer keretein belul megoldast nyujtani a problemara.

Nagyon komoly indok kell arra, hogy egy mukodo rendszerben gyokeres valtozasok eszkozoltessenek, ez ugyanis elkerulhetetlen zavarral jar a mindennapos munkaban. Hiaba gany az egesz rendszer, akkor is elsosorban az adott rendszer keretein belul kell megoldani a problemakat, es nem szerver-ujratelepitesekkel.
-- 


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

Ha a rendszer gány, akkor legegyszerűbb a format c:, hidd
el. Ha nem gány, akkor bárki képes üzemeltetni. Az igazán
jó rendszergazda ahhoz kell, hogy egy igazán jó struktúra
alakuljon ki. Egy igazán jó struktúrában pedig _majdnem_
mindegy milyen oprendszer ketyeg.

Továbbá: ha elmegy a régi rendszergazda, akkor van
egy-két kötelező gyakorlat - tehát mindenképpen van
döccenő. Azt ne mondja nekem senki, hogy kicserélsz egy
kulcsszemélyt és minden megy tovább, mint azelőtt. A
format c: ebben a kérdésben a legkevesebb.

Vannak persze olyan cégek, amelyeknél az anyavállalat
komoly előírásokat fogalmaz meg - sokszor értelmetlenül -
az IT környezettel kapcsolatban. Most nem ezekről az
esetekről beszélünk.

Ez nagyjából válasz Szabinak is.

> Sol omnibus lucet.

Ha szerinted a problémák megoldása csak személyreszabott rendszeren lehetséges, akkor téged a rendszergazdád nagyon megvezetett. Szerintem a jó rendszergazdának éppen az az ismérve, hogy bármilyen (najó, nem szélsőségesen, de általában) körülmények közt képes dolgozni és egy rendszer működőképességét biztosítani. Akinek a munkához az kell, hogy ismerős közegben mozogjon - és ezt nem az adott közeg megismerésével éri el - azt nem tudom jó rendszergazdának tekinteni.

Ave, Saabi.

( hrgy84 | 2009. 11. 27., p – 08:33 )

A sorrend nalam:
Mandriva
Debian
Gentoo

Mindharom kedvenc, es adott celra az adott rendszert hasznalom.
-- 


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

Nem gondolom, hogy igényesebb lenne egy olyan cég supportját megvennem, akinek mondjuk nem beszélem a nyelvét.
Azt gondolom, egy szerver nem a support-tól lesz igényes, hanem attól, hogy le van dokumentálva minden amit végrehajtottak rajta, így bárki át tudja venni bármikor a rendszergazdai munkát.

Mandriva. Van nekik kimondottan szerver disztrojuk is, supportal mindennel cakkumpakk. Bar en speciel nem azt hasznalom, de adott esetben volna ra lehetoseg. Es igen komoly garanciakat vallalnak a ceges verziora, szoval en nem mernem csak ugy hobbylinuxnak nevezni. Erdemes utanaolvasni, a legtobb app szamara redhat-kompatibilis.
-- 


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

( Lightning | 2009. 12. 04., p – 17:12 )

Web és/vagy adatbázis-szerverre debian, fájlmegosztásra és továbbiakra bubuntu LTS.
Szerk.: Úgynézki váltok CentOS-ra. Végül kipróbáltam és eddig meglehetősen tetszik.
Azért nem hagyom el a deb alapú distrókat se. :)

( korci | 2009. 11. 27., p – 09:51 )

Részemről mindenképpen bináris terjesztésű disztró a preferált, mert nagy mennyiségben könnyebb karban tartani.
Standard web,adatbázis,mail szervernek a debian tökéletesen megfelel számomra. Ott még sosem hiányzott a support. Igaz Lenny alatt a xen hagy maga után kivetnivalót. Ubuntu hozzáállásától a hideg ráz (láttam már olyat, hogy majd a következő verzióban javítjuk, akkor is, ha az éppen nem LTS). Cluster építésre és ahol mindenképpen szeretnének supportot, inkább RH vagy Suse (Novellék rendesen foglalkoznak a heartbeattel és annak környékével, igaz bele lehet futni bugokba rendesen, és sok helyen nincsen jól dokumentálva, de ez sajnos nem csak rájuk igaz).

Nekunk most baromi jo lenne egy debian supportos, tobb eve kinlodunk egy szerverrel, gyak a 2.6.14-es kernel ota nem tudtunk meg olyan allapotot osszehozni, hogy legyen lvm, az ne fagyjon szet hetente, es a halozati stack ne jatszon csigat.
-- 


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

Cluster építésről:
A sles11-be egy igen csúnya cluster bugot sikerült beszervezni, valamint eddig a gdm és az openldap lett meggyanúsítva (hw hiba lehetőségét nem említve) egy hónapok óta húzódó projektben (akinek inge, tudja miaz/kiaz). Kezdek egyre jobban bízni a dzsunkapcben és a hackelt megoldásokban, mert legalább fele/harmada árban össze lehet hozni ugyanazt a megoldást, rádaásul sokkal nagyobb rálátásod és ráhatásod van a hw-re.

( saynos | 2009. 11. 28., szo – 00:29 )

Nincs min csodalkozni, a vegeredmeny egyertelmu volt.

Szerk: DE! A Rolling Release-t jobban szivlelem. (Ezert hasznalok pl desktopon Gentoo-t es Arch-ot, es ezert gondolkodom a valtason szerveren is)

( saabi v | 2009. 12. 03., cs – 10:27 )

Önellentmondásba keveredtem:

Akinek a munkához az kell, hogy ismerős közegben mozogjon - és ezt nem az adott közeg megismerésével éri el - azt nem tudom jó rendszergazdának tekinteni.

vs

Mi az amit te mar gaznak nevezel?

Ha ismeretlen és nem szabványos a környezet.

Megpróbálom feloldani az ellentmondást. Természetesen - mint talán mindenki - én is hatékonyabban dolgozom olyan környezetben amit ismerek. Adott környezet ismerete kétféleképp érhető el. Egyrészt úgy, hogy magam alakítom ki a környezetet. Másfelől pedig úgy, hogy a lehetséges környezetek egymásra hasonlítanak, szabványosak.

Az elsőnek felvetett, saját magunk alakítjuk ki a környezetet módszer tökéletesen használható otthon vagy saját cégnél. Olyan helyen, ahol garantált, hogy a környezetet kialakító személy fog az adott környezetben dolgozni mindig. Munkahelyen ugyanakkor ez nem megvalósítható, hiszen az üzemeltetőnek csereszabatosnak kell lennie, egy cég sem vállalhatja annak kockázatát, hogy egy vagy több emberének elvesztése a további működést akadályozza. Ugyanakkor természetesen a cégeknek is igényük van a hatékony munkavégzésre. (vagy talán nekik van erre igényük leginkább?) A hatékonyságot biztosító ismerős környezet, cserélhető alkalmazottak mellett akkor biztosítható, ha az a környezet szabványos.
Nézzük a servernek használható Linux disztribúciók körét. Miért szeretnek a cégek Red Hat Enterprise Linuxot vagy SuSE Enterprise Servert használni? Hihetnénk, hogy a support miatt. (ami egyébként valóban nem elhanyagolható szempont) Szerintem a supportnál fontosabb, hogy ha szabályos RHEL vagy SLES környezetünk van, akkor azon bármelyik, RHCT (vagy magasabb) illetve CLA (vagy magasabb) minősítésel rendelkező munkavállaló különösebb betanulási idő nélkül kezdhet el dolgozni.

Ave, Saabi.

Ave, Saabi.

Alapvetoen ez igy van a "nem szabvanyos" rendszereknel is, ha rendesen atadjak a feladatokat (tehat a regi rendszergazda tenylegesen atadja a rendszert es nem neked kell megismerned magadtol) akkor szinte minden olyan ember, aki uzemeltetett mar hosszabb ideig (2-4 ev) Linuxot, barmilyen Linux alapu kornyezetet at tud venni.

A felfedezos verzio se sokkal bonyolultabb igazabol, mivel a "szabvanyos" Linuxok csak azt garantaljak, hogy a fajlok _helye_ szabvanyos, hogy a fajlok mennyire kommentezettek, illetoleg maga a rendszer altalaba veve mennyire dokumentalt, arrol sajnos semmilyen szabvany nem mond ki semmit, marpedig uzemeltetoi szempontbol ez sokkal fontosabb, mint kitalalni, hogy az Apache epp hol tarolja a fajljait. Raadasul nem tul sok "nem (hivatalos) szabvany" linux van, ami viszonylag konnyen tanulhato.
-- 


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