Milyen UNIX-ot?

UNIX kezdő

Sziasztok!

Lassan a linux mellett szeretnék a UNIX-okkal is foglalkozni. Nem tudok róluk sokat, ezért érdekelne, ki melyiket javasolná a komolyabb foglalkozáshoz. Hallottam már IBM-AIX-ról, HP-UX-ról, BSD-kről, Solaris-ról és OpenSolaris-ról. Érdekel a java is, ezért a SUN felé húz a szívem. Ha az OpenSolarissal ismerkednék, később gondolom a Solaris is könnyebben menne. A piaci részesedésüket nem tudom, olyannal szeretnék fogllakozni aminek van jövője és jelene.

Válaszotokat köszönöm :)

Root-Tech

  • 9940 megtekintés

( bambano | 2010. 07. 04., v – 15:11 )

egyelőre azon áll a vita, hogy a solarisnál lesz-e később...

aix jó befektetésnek tűnik.

( aspirin v | 2010. 07. 04., v – 15:23 )

Eeegen, most egy kicsit nem lehet tudni, hogy a Solarissal mi lesz...
Az én szívem egyébként Solaris felé húz. Ráadásul ebből van x86-os verzió is (AIX, HP-UX: asszem egyiknek sincs x86 portja), azaz akár otthon is el tudsz kezdeni ismerkedni egy "kereskedelmi unix"-szal.
_állítólag_ (ezt tőlem okosabbak mondták) ha egy ker. unixot ismersz, a többihez sokkal könnyebb hozzászagolni.
Kéretik figyelembe venni, hogy *BSD-ben abszolúte nem vagyok otthon. :)

szerk: az Opensol & Sol 10 néhány hónapja elég erőteljesen szétvált, tehát ha erre veszed az irányt, _és_ szerverekkel szeretnél ismerkedni, akkor az S10 is erősen ajánlott. Vannak PV driverei, tehát elvileg jól elvan Xen-nel, vagy(?) VBox-szal (mekkéne nézni - a Xen biztos :)).
<-------
You can't grep on dead trees.

Az lesz a gond vele, hogy nem fogsz sokat nyerni, sot. A osol ugyanis jo esellyel csak HVM guestkent fog menni rajta, es a pure qemu kepessegei... hat... No perszer a CPU virtualizacios cuccai dobnak rajta valamennyit, de en ilyen guesteknel maradnek a vboxnal.
-- 


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

Magam részéről szintén Solaris 10-et javaslok, bár a többi sem lebecsülendő. Az ORACLE a Solarisnak nagy hátszelet tud adni, és az eddigi SUN technológiák, elgondolások, elég meggyőzőek tudnak lenni, ha valaki egyszerű linux buherátorként akar kicsit a nagyok világába is belekukkantani.

Solaris (10) tanuláshoz pedig ajánlom a saját kis gyűjteményemet: http://blog.xorp.hu/solaris-howtos

Bár a tényleges adminisztráláson (szopás) mindenképp elengedhetetlen.

MiszterX -- http://blog.xorp.hu

En mindenesetre az OpenSolaris mellett tennem le a voksom. FreeBSD-t szeretek meg DMZ-be pakolt szervereken hasznalni. Lassuk nalam miert jobb az OpenSolaris. A sajat 2010.03-amat mi mindenre is tudom hasznalni? Pl:
+ NAS 1,6 dual core atom 64 biten
Ez jelent ZFS-t deduplikacioval, 4 db 1,5TB hdd raidz-be szervezve.
Sajat adatokkal (kepek, zenek, installerek, virtual gepek, backup) a deduplikacio es a zfs default tomoriteset bekapcsolva, (400GB-nkent 50GB megtakaritas, azaz 400GB adatom a fizikai teruletbol 350GB-t foglal.) Timeslider snapshotokkal. Van nfs, cifs es iscsi. (Akar szimpla SSD cache-el is lehet a tomb read es write muveleteit gyorsitani.)
A FreeBSD ellen nalam a nem igazan friss (es jo kepessegeket mellozo) zfs verzioja szol.
+ szereten az SMF-t, Solaris 10-nel is jol jon az ismerete
+ Solaris 10-en/OpenSolaris-on nalam ezek az alkalmazasok jol mennek: Java, JRuby (RoR), GlassFish, OpenDS, Oracle (korabbi Sun) DSEE, Oracle Database 11gR2, MySQL, Netbeans, Apache, Lighttpd, Mongrel, Nginx. Mondjuk ezek nagy reszet RHEL es Debian alapokon is osszeraktam, vmint az Oracle nelkuliek FreeBSD-n is okesak, de ez ne legyen a Solaris hatranya. NFSv4 szerver hatarozottan Solarison jobb.
- Az ipkg zfs snapshottal kiegeszulve jo, de az OpenSolaris koruli hallgatasban, csak egy iden marciusi dev build (b134) erheto el, a disztribucio dev repositoryja szabadon hozzaferhetoen biztos nem frissul (csak az OS/Net forrasa erheto el, b143-nal jar), itt a FreeBSD 8.x kaphatja a pontot a ports tree es az upgrade miatt.
+ virtualbox es zonak, szukseg eseten xen. A FreeBSD, itt csak a jaillel nem tud nevezni a versenyre.
: dtrace 1-1
: OpenBSD-s pf FreeBSD-n DMZ-ben talan jobb, mint Solaris tuzfal, konnyu a jaileket natolni, de az ipf a crossbow-t is figyelembe veve, boven karpotol
: pxe boot - diszk nelkuli uzem
+ Lenovo T61-en, wifi + nvidia/compiz + 3G usb modem :) (Nyugi, laptopon inkabb Ubuntu Linux ;)

En, ha most keresnek kereskedelmi Unixot, Oracle Solaris-t/OpenSolaris-t tanulnek. Meg Javat, mint Eddie Larisson es Lenny Linux. :)

Mukodni mukodik, csak ennyi (2G) memorianal a dedup tabla hamar eleri azt a meretet (a poolon elfoglalt blokkok szamatol fuggoen), hogy nem lesz eleg hely szamara a RAM-ban. Ennek koszonhetoen alacsony irasi sebesseg erheto el. Ha netrol toltok le, nalam az 5 Mbit lefele savszelt gond nelkul irja dedupolva. Ha irasi sebesseg kell nfs-en, akkor nem dedupolt tmp datasetre irok vagy a root poolra, azon sincs dedup. Ha vmit gyorsan ki kell irnom diszkre, de kesobb dedupolva akarom tarolni, akkor a ket pool kozotti adatmozgatast rsync-el szepen meg lehet oldani.
Ezeket a negativ mutatokat fokent a teljesitmenyfelvetel es a vas kis merete miatt hajlando voltam bevallalni.

zfs destroy-t hasznaltam korabban kevesebb rammal is, nalam nem jott elo ilyen problema most sem, lehet csak makom van/volt es nem teszteltem eleg alaposan.

Elfogadom, hogy vannak a zfs-nek hibai, nalam ez arrol szol, h a celjaimra a legmegfelelobb valasztas. Amugy minden baja ellenere enterprise szinten is helytallo storage epitheto zfs-el, barmennyire is utaljak itt sokan.

Hogy az elmult hetek hirei utan a zfs fejlesztese milyen iranyt vesz gozom sincs. Mar jelen allapotaban befagyasztva is hasznalhato lesz sokak szamara akar FreeBSD-vel, akar Illumos-el, akar Solaris Express-el.

Minden kotekedes nelkul: van valamilyen elerheto relevans adatod arrol, hogy "alig használják kritikus környezetekben"?

Kicsit furcsa erzest keltett bennem a hozzaszolasod. Egybol arra gondoltam, hogy azert, mert en szemely szerint csak tizes nagysagrendu AIX-et futtato masinaval, ellenben Solaris-t futtato szerverek ezreivel talalkoztam, meg nem jelentenem ki, hogy AIX-et nem nagyon hasznalnak.

Több ügyfélnél, EU-szerte, illetve Magyarországon, minimum több száz, ha nem több ezer Solaris szerver alapján mondom én is, hogy nem hallottam sehol, hogy ZFS volna produktív környezetben. Néhány fehér holló persze van, de ott is a csúnya szopást hangsúlyozzák inkább a Solaris admin kollégák.

Ezen én is csodálkoztam amúgy a hype alapján.
--
2e845cb4c3a5b5bd6508455b1739a8a2

Ok, legalabb felvillantottal vmi szemelyes tapasztalat felet.
En sem irtam, h az ezres nagysagrendu Solarison ZFS lett volna.
De tenyleg furcsa, hogy az altalad is emlitett hype ellenere a kutya sem hasznalna...
Nem azt mondom, h esz nelkul irany mindent zfs-re, de pl. root filerendszer ala szivbaj nelkul raktam tobb helyen is es nincs vele gondom. Az elonyeit pedig elvezem.
Nekem jok a tapasztalataim, annak ellenere hogy en is talalkoztam kellemetlen bugokkal a "nehai" OpenSolaris dev agon.

Érdekes... nekem ellenkező tapasztalatom van vele.
kb. másfél-két éve volt egy projekt, ahol zfs-t raktunk Oracle alá.
Mivel volt benne portolási meló is, baromi jól lehetett úgy tesztelni, hogy a hosszú betöltést csak egyszer kellett kivárni, utána snapshot+rollback-al 1 perc alatt vissza lehetett állni minden teszt után a "szűz" adatbázis állapotra.

Éles napi üzem során pedig snapshotokkal és zfs send+ receive scriptekkel duplikálódik online üzemben az adatbázis két másik szerverre.

Azóta is stabil, és anno a teljesítménye teszteléskor jobb volt, mint ufs-en. (Ja, és nem pistike homokozója kategória, hanem egy bankkártya rendszer.)

a blogoddal kapcsolatosan van egy eszrevetelem, a hardening reszben:

# inetadm -d [process-neve]

Amennyiben pedig mégis engedélyezni szeretnénk valamit akkor:

# inetadm -d [process-neve]

Engedelyezni a -e kapcsoloval kell :)

-- Soha ne vitatkozz idiotakkal! Lesulyedsz az O szintjukre es legyoznek a rutinjukkal !!! --

( vl v | 2010. 07. 07., sze – 22:53 )

Ha nem tudsz nem-PC (értsd: nem x86-kompatibilis CPU-val rendelkező) gépet szerezni a játszadozáshoz, akkor a kommerciális unixok közül csak a Solaris, a nyílt forrású, de kommerciális hátterű unixok közül pedig csak az OpenSolaris marad. Ugyanis sem az AIX, sem a HP-UX nem fut PC processzorokon (AIX-hoz RS/6000 kell valamilyen IBM Power CPU-val, a HP-UX meg régi PA-RISC-eken vagy Ithaniumon fut). A többi kommerciális unixot meg nyugodtan elfelejtheted.

Vagy maradsz a klasszikus nyílt forrású, nyílt hátterű unixok körében (Linux, FreeBSD, OpenBSD, NetBSD, és haverjaik).

A Solaris jövője úgy en bloc kérdéses, ha elmúlik, akkor nem marad kommerciális unix PC-n...

Én majd' minden évben olvasom, hogy csődvédelmet kérnek, majd az utolsó pillanatban akad egy "kalandbefektető", aki a jogi csatározások finanszírozásában lát fantáziát, és megmenti őket (kifizeti az adósságokat), aztán az újabb jogász-szélmalomharc megint felemészti az összes zsetonukat, miközben magát a terméket vagy 5 éve szinte nem is fejlesztik. Ha ezt (= bármikor csődbe mehetnek) jövőnek lehet nevezni...

A nyíltság azért lényeges, mert a nem nyílt oprendszer a fejlesztésének leállítása + a tulajdonos csődbemenetele után igen jó eséllyel kukázódik. Ha nyílt lenne, akkor lenne esélye az életre azután is, hogy az SCO végleg csődbe megy.

>> A többi kommerciális unixot meg nyugodtan elfelejtheted.

> Hehe, erről a Digital Unix is tud? [...]

+1. OSF/1-re (asszem OSF1 V4.0 1091 volt) fantasztikus volt SUSv1 alá fejleszteni. Mintha az ember a SUSv1 64 bites referencia-implementációja elé ült volna le. (Pedig a UNIX 95 registry-ben nem is szerepel.)

x86 portja volt neki valaha? tudtommal csak alpha-n futott mind a Digital, mind a későbbi Tru64
a kommenternek meg ez volt a megjegyzese.
amugy pl ilyet mar(meg?) egesz olcson kapni Tru64-hez jatszani, kar, hogy a szallitas
ide megegyszer annyi + a szoftver :) bar talan OpenVMS is felmegy ra, azt pedig lehet ingyen igenyelni hobbyst programbol, de
az meg mar nem unix, szoval offtopic :)

No, UNIX kell? Nesze:

bsd43, bsd42, 386bsd (vax, pdp, illetve x86) install image-ek:
http://bsd42.sourceforge.net/

bsd43, bsd42, ultrix (vax, illetve pdp11) image-ek es VM:
http://simh.trailing-edge.com/

dec MIPS ultrixot futtatni kepes VM:
http://gxemul.sourceforge.net/

regi UNIX-ok:
http://www.tuhs.org/

bsd43, bsd42, ultrix (vax, illetve pdp11), sunos forras (m68k ?), irix forras (MIPS), dynix/ptx (x86)
ftp://ifctfvax.harhan.org/

SunOS/Solaris/NeXTStep SPARC architektura emulatorok, QEMU patch BLOG:
http://tyom.blogspot.com/

Vegyes vadallat profi virtualizacios blog, unix tema is akad sok:
http://virtuallyfun.blogspot.com/

FreeAXP for winfos (megy *buntu alatt is, sznobok kedveert), Tru64 futtatasahoz alpha-architecture VM, kib. jo:
http://www.migrationspecialties.com/

Qemu (foleg, hogy valaszoljak is a szalban: tyom.blogspot.com -mal egyutt tekintve)
http://www.qemu.org
packages.ubuntu.org

Gugliban keress ra meg a SUN SPARC TME emulatorra is, csomagkent megtalalhato a NetBSD-ben is, negyfele sparc-os vasat emulal, netbsd megy rajtok, SunOS passz. Van rajta 2 link retro, engedelyezett SunOS install tape image konyvtarakra

Altalaban veve ha nincs sok fizikai helyed, vagy sokba faj az aramszamla, es valamifele egzotikus vason futo unix-ra akarsz ragyurni, akkor szopasfaktort minimalizalando celszeru olyat valasztani, ami jol virtualizalhato fospeecee kornyezetben, vagy van x86-os (hasznalhato) portja, pl. az AIX 1.3 nem ilyen (PS/2, vagy ESA 2.x sem nyero Z/hercules alatt), Irix szinten felejtos, HP-UX nemkulonben (persze ha pl. utobbihoz ertesz, nem doglesz ehen, csak ferj el egy olyan vas mellett :P )

amit tutira erdemes UNIX-ok kozul atnyalazni minimalis extra hw igennyel (extra cpu kapacitas es ram olykor azert nem art):
Solaris
Opensolaris
SCO*.*
NetBSD
OpenBSD
FreeBSD
4.3BSD Quasijarus, esetleg Wisconsin NFS
QNX 6.* vagy frissebb
Tru64 5.*

http://nocirc.org/

teszteltem a sok divatunigzost, vegre valaki kapcsolt :PP ;))

(bar ha a VMS orrba-szajba fel van hozva e forumon, akkor batran idecitalhato a QNX is. )

ha mar off, legalabb legyen hasznos:
Amugy a ftp.fsn QNX installcd ISO-kban ott vannak az egyfloppylemezes QNX grafikus csuvaszszkriptes webbongeszos disztrok is 1440k-s kepfajlokban elrejtve a konyvtarstruccturakban, batran kiprobalhatja minden kedves valagan tojashejjal rendelkezo ujonc, de elotte a tojashej legyen kicserelve pelenkara! Batrabbak modosithatjak is, lecserelhetik a halokartya modulokat benne pl. olyanra, amit VMware tamogat, vagy valami ujabb PC, es memdisk+grub segitsegevel csinalhatnak maguknak helyreallito live image-eket stb...

http://nocirc.org/

( zwei | 2010. 07. 08., cs – 12:00 )

"olyannal szeretnék fogllakozni aminek van jövője és jelene"

Hibás hozzáállás
Olyannal kell foglalkozni, aminek van jelene, de nincs jövője. :)

Ha pl. a Solaris pár év múlva kipusztul, min. még 10-20 évig szükség lesz jó Solaris expertekre, az infrastruktúrába kiszedhetetlenül bedrótozott Sol. rendszerek támogatására. Mivel addigra elég kevés lesz a Sol. expert, ezért szép pénzt lehet majd az őskövületek supportján keresni. :)

( LGee | 2010. 07. 08., cs – 12:47 )

AIX-szel nem lesz tul sok allaslehetoseged, de cserebe sok kerdesedre tudunk valaszolni ;-)

( turdus | 2010. 07. 08., cs – 17:28 )

- Mi a különbség a SUN Solaris-a és Stanislaw Lem Solaris-a között?
- Az egyik egy idegen életforma, ami őrületbe kerget mindenkit, aki kapcsolatba kerül vele, a másikból filmet csinált Tarkovszkij.

Komolyra fordítva a szót: kereskedelmi unixok nem sétagalopp, nem igazán az az otthon felrakom aztán megtanulom kategória, keményen fizetős kurzusok vannak, ahol elmondják mindazt, ami a man page-kből kimaradt. Másik kérdés a licenszek, Solaris-t pl tuti nem rakhatsz fel legálisan otthon a gépedre, hiába x86 (ezért jött létre az OpenSolaris, de a kettő mára ég és föld).

AIX-et meg HP-UX-et csak böködtem egyetemen, arról nem tudok véleményt mondani, a BSD meg nem igazán kereskedelmi (egyetemi projekt eredetileg vagy mi fene, és vannak ingyenes forkjai). Az Ultrix volt az első komoly kereskedelmi unix, amin dolgoztam, viszonlag egyszerű, de sajnos megölték, mikor a Compaq felvásárolta a DEC-et :-(

Summa summarum én BSD-znék a helyedben először, aztán váltanék nagygépes unixra (AIX vagy Solaris).

"kereskedelmi unixok nem sétagalopp, nem igazán az az otthon felrakom aztán megtanulom kategória, keményen fizetős kurzusok vannak, ahol elmondják mindazt, ami a man page-kből kimaradt."

Tanfolyam nélkül sem vészes.
A tanfolyam arra jó, hogy gyorsan, tematikusan az arcodba tolják azt, amit magadtól csak hosszabb idő alatt tudsz elsajátítani.

"A tanfolyam arra jó, hogy gyorsan, tematikusan az arcodba tolják azt, amit magadtól csak hosszabb idő alatt tudsz elsajátítani."
Pontosan erre gondoltam. Ha még nem látott ilyent közelről, akkor a hosszabb idő az tényleg hosszú lehet.
Gondolj csak bele, mennyi macera egy pendrive-ot bemountolni, ha nincs vold-d (phydev kiderítése, megnézni melyik dsk dev linkel rá, ahelyett hogy egyszerűen dmesg grep. Azért elsőre nagyon nem triv, pláne, ha semmit nem olvastál még róla, és azt se tudod, mi a különbség a devices, a dev, a dsk és az rdsk között).

Komolyra fordítva a szót: kereskedelmi unixok nem sétagalopp, nem igazán az az otthon felrakom aztán megtanulom kategória, keményen fizetős kurzusok vannak, ahol elmondják mindazt, ami a man page-kből kimaradt.

Hát... biztos én vagyok zseni, de szerintem meg nem könnyebb megtanulni a Linuxot (normálisan használni), mint mondjuk a Solarist. A man page pedig semelyik kommerciális unixnál nem tekinthető "A" dokumentációnak... Mindegyik vendor meglehetősen korrekt doksit gyárt (és ez nem = a man page-ekkel), nagyon sok, az alkalmazott technológiákat, alrendszerek működését komplett elmagyarázó, mintapéldákat tartalmazó doksit tesznek közzé a gyártók. Aki ezekből nem tudja megérteni a dolgokat, azon a fizetős kurzus sem segít.

Másik kérdés a licenszek, Solaris-t pl tuti nem rakhatsz fel legálisan otthon a gépedre, hiába x86 (ezért jött létre az OpenSolaris, de a kettő mára ég és föld).

Licensz: http://www.sun.com/software/solaris/licensing/sla.xml
El lehet olvasni, szerintem ebből nem az jön le, hogy "tuti nem rakhatsz fel legálisan otthon a gépedre".

"ég és föld": az OpenSolaris a következő generációs Solaris verzió még ki nem adott tesztágya. Egy nap talán kijön a Solaris 11 (erre azért még jó esélyt látok, mennek bele a mérnök-munkaórák a rebrandingbe :), akkor - ha addig nem változik a policy, és nem szüntetik meg addig az OpenSolarist - a Solaris 11 100%-ban az aktuális OpenSolaris kódját fogja tartalmazni, meg pluszban még azokat a dolgokat, amiknek a forrását nem nyitották meg.

Az Ultrix volt az első komoly kereskedelmi unix, amin dolgoztam, viszonlag egyszerű, de sajnos megölték, mikor a Compaq felvásárolta a DEC-et :-(

Az Ultrix halálos ítéletét az OSF/1 megjelenése jelentette, a Digital úgy döntött, hogy nem BSD alapon, hanem System V alapon képzeli el a jövőt (mint ahogy az összes többi kommerciális unix vendor is pont ugyanígy döntött). Alphára már el sem készült a Ultrix-port, ezzel gyakorlatilag már rég nem lehetett normális vasat venni alája, mire a DEC pályafutása 98-ban véget ért.

Nézőpont kérdése. Nem arra gondoltam, hogy könnyebb-e megtanulni a Linuxot, hanem arra, hogy a kérdező fogalma a UNIX-ról a Linuxra korlátozódik, ergo előbb valami pc-s unix-ot ajánlanék, mielőtt Solaris-al kezd.

Licensz kapcsán: nekem csak annyi jön le belőle, hogy 90 napig használhatod. Hogy pontosan mit és milyen feltételekkel értenek individual use alatt, az nem világos, merthogy nagyon hasonlít a commertial-ra, ami viszont egész biztos nem ingyenes (volt, valamikor, járt a géphez, de már nem).

Solaris vs OpenSolaris: azért lássuk be, hogy a kerskedelmi unix pont attól lesz az, ami, amit pluszba hozzáraknak az openhez. Szvsz ez triv.

Ultrix: bizony így történt. Kár érte, kifejezetten kedveltem a DEC termékeit. Azért az alpha-mon futott még egy darabig VMS :-) Azóta is nehéz elmagyaráznom a kizárólag unixon nevelkedett kollégáknak, hogy mekkora királyság az file szintű, sorszámozott snapshot...

Erről mesélhetnétek még, én egyetemen találkoztam VMS-el kicsit, és nagyon megtetszett az oprendszer hozzáállása, de nem igazán mélyedtem bele a nagygépes rendszerekbe (az egyetlen Alpha emulátor amit találtam az fizetős volt akkoriban), szóval miért volt annyira jó a VMS az akkor nagygépes oprendszerekkel szemben, meg úgy általában, milyen érzés volt egy desktoptól ennyire idegen rendszerrel dolgozni?

Mondjuk melóhelyen is DCL scriptekkel fordítottunk, szóval tulajdonképpen könnyen lehet, hogy dolgoztam VMS-el, csak nem tudok róla, mert a felület eltakarta...
----
Hülye pelikán

Na most nekem is vannak régi, megszépült, melóhelyi emlékeim DEC alphákról.

Ezzel együtt úgy gondolom, a világ (desktop OS-eket nem számolva) a Linux mellett teszi le a garast. Tehát ha valaki IT-ben akar dolgozni 5,10 meg 15 év múlva is, akkor stabilan lehet ajánlani, hogy tegyen fel egy linux disztrót (én személy szerint a Debian-t ajánlanám), és püfölje azt.

--
GPLv3-as hozzászólás.

Hat, a fene jobban tudja. Nagyon nagy kornyezetbe mar szerintem erosen szopoag a Linux, foleg a bazarmodell hatranyai miatt (jo, persze, a kereskedelmi linuxokhoz lehet venni patch-supportot is, de itt elsosorban az a gond, hogy KELL venni, mert Linuxon sokkal nagyobb a bug eselye, mint akarhol masutt, ahol szervezettebb fejlesztes folyik, es kevesebb kezben koncentralodnak a kodok). Raadasul a bankoknal nem szamit ritka allatfajnak valamelyik kereskedelmi UNIX, es arrafele egesz jo fizeteseket lehet kapni, szoval nem rossz rahajtani a UNIX-ra.

Pufolesre... hat nem tudom. Ha valaki total nem ismer semmilyen konzolos dolgot, akkor talan jo lehet neki a Debian-Ubuntu vonal, de azutan szerintem rogton valtson valami RPM alapu stuffra, es tanulja meg kivul-belul, mert semelyik komoly enterprise Linux nem hasznal dpkg-t. Meg persze parhuzamosan erdemes elmerulni egy Gentoo menedzselesenek mindennapjaiban, rengeteget lehet tanulni a Linuxrol csak azzal, hogy birtokolsz es aktivan hasznalsz egy Gentoo telepitvenyt. Ennek a magasabb szintje a sikeres LFS telepites :-)
-- 


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

( Replaced | 2010. 07. 08., cs – 18:33 )

NetBSD, nem az az emberevo kereskedelmi unix, de nagyon jo alapokat ad barmi mas unix like rendszer megertesehez

--
NetBSD - Simplicity is prerequisite for reliability

Nem tudom, en csak tapasztalatokrol tudok beszamolni, szamomra a FreeBSD valahogy nem jott be. Tulsagosan is ki akarja nyalni az ember alfelet, ami nem biztos, hogy jo dolog, foleg, hogy amikor probaltam, jopar TUI-s cucca egyszeruen bugos volt, nem mukodott. A NetBSD-t felraktam, kicsit kerdezgettem Replaced-et, de alapvetoen ment magatol. Jo, mondjuk nekem a Gentoo-s multammal nem idegen a rendszer lelkeben valo vajkalas, szoval igy megint nem vagyok teljesen mervado...
-- 


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

Hát nem is az.

Konkrét bizonyítéknak speciel itt az ioccc.org -os klasszikus, a korn.c ( http://www.ioccc.org/1987/korn.c ). Anno amikor először AIX-hez közel kerültem (késői 4.x, vagy nagyon korai 5.x volt . esetleg 3?, a bánat se emlékszik már rá), le se fordult AIX-en. C-ben büfék maguktól rájönnek, a többieknek ha nagyon muszáj vagy elmagyarázom én, vagy elolvassa mindenki magának a hozzá tartozó REAMDE-ben, hogy mi a trükkje a dolognak. És bizony jelentős részben a UNIX (illeve a kódban szerplő forma szerint: unix ) a dolog alapja.

Basszus, az egész összesen 70 karakter, ne add fel :-) Mi anno HZ kollegával 1 teljes délelőtt után jutottunk el odáig, hogy lefordítsuk (a sokak által utált SCO-n, amin csont nélkül fordult a natív fordítójával), majd a kimenet alapján próbáltunk rájönni. Nem segített, ellenben mihelyt rájöttünk, hogy mi a szar a kódban a "unix", onnan már könnyű volt. Mondhatom, két mérnöknapnyi munka eredményeként megvolt :-)

OSX: 


xxxxx-MacBook-Pro:~ psc$ gcc ./korn.c 
./korn.c: In function ‘main’:
./korn.c:1: warning: incompatible implicit declaration of built-in function ‘printf’
./korn.c:1: error: ‘unix’ undeclared (first use in this function)
./korn.c:1: error: (Each undeclared identifier is reported only once
./korn.c:1: error: for each function it appears in.)
xxxxx-MacBook-Pro:~ psc$

FreeBSD 8.0: 


[root@aaaaa ~]# gcc ./korn.c 
./korn.c: In function 'main':
./korn.c:1: warning: incompatible implicit declaration of built-in function 'printf'
[root@aaaaa ~]# ./a.out 
unix

Na most melyik a szabványos viselkedés?
Írtam én már C-ben virtuális gépet meg hozzá assemblert is (igaz rég volt már), tehát nem áll tőlem távol a dolog, de ez most megfogott....

Passz, az biztos, hogy ez itt Windows XP sp3-mal meg cygwin-nel: 


$ uname.exe -a ; echo "----"; gcc -Wall korn.c -o korn.exe ; echo "----" ;./korn.exe
CYGWIN_NT-5.1 mazsola 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin
----
korn.c:1: warning: return type defaults to `int'
korn.c: In function `main':
korn.c:1: warning: implicit declaration of function `printf'
korn.c:1: warning: embedded `\0' in format
korn.c:1: warning: control reaches end of non-void function
----
unix

Mondjuk az 'unix' az egy predefiniált macro :http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros…

"it is common to find unix defined on Unix systems."

De ugye ez nem kötelező dolog, csak "common", viszont __unix__ van minden unix rendszeren...
A fenti szöveg szerint ki kéne próbálni a gcc -t -ansi vagy -std(xx) kapcsolókkal is.
Ennek most nem állok neki. :)

Lényeg a lényeg, hogy a fenti kód kitűnő példa arra, hogy hogyan lehet olyan kodot írni, amik olyan undefined compiler feature-kra támaszkodnak, ezért a program futása bizonytalan. :)

Az idéztt leírás utolsó két sora:
"We are slowly phasing out all predefined macros which are outside the reserved namespace. You should never use them in new programs, and we encourage you to correct older code to use the parallel macros whenever you find it. We don't recommend you use the system-specific macros that are in the reserved namespace, either. It is better in the long run to check specifically for features you need, using a tool such as autoconf."

Tehát lehet, hogy a FreeBSD-s gcc-en még benne van, az OSX-es gcc-ből pedig már kigyomlálták az 'unix' makrót, ennyi az egész.

ANSI-val természetesen nem müx: 


$ uname.exe -a ; echo; gcc -ansi -Wall korn.c -o korn.exe ; echo;./korn.exe
CYGWIN_NT-5.1 mazsola 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin

korn.c:1: warning: return type defaults to `int'
korn.c: In function `main':
korn.c:1: warning: implicit declaration of function `printf'
korn.c:1: error: `unix' undeclared (first use in this function)
korn.c:1: error: (Each undeclared identifier is reported only once
korn.c:1: error: for each function it appears in.)

bash: ./korn.exe: No such file or directory

Én is kipróbáltam -ansi -val közben. :)
Tehát annyi van, hogy a FreeBSD-men levő gcc nem -ansi strict szerint dolgozik alapértelmezetten, az OSX-ben levő gcc pedig igen.
És a doognak nincs sok köze az "unix"-hoz, mindössze az derül ki, hogy az 'unix' predefined built-in makró definiálva van-e, vagy nem. :)

Hogyúgyvan :) 


$ uname.exe -a ; echo; gcc -ansi -Dunix -Wall korn.c -o korn.exe ; echo; ./korn.exe
CYGWIN_NT-5.1 mazsola 1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin

korn.c:1: warning: return type defaults to `int'
korn.c: In function `main':
korn.c:1: warning: implicit declaration of function `printf'
korn.c:1: warning: embedded `\0' in format
korn.c:1: warning: control reaches end of non-void function

unix

( NevemTeve | 2010. 08. 24., k – 08:48 )

Olyat szeretnél, aminek van jövője? Az a linux. Persze lehet hobbizgatni mondjuk egy AIX-szel (én is csinálom), pont olyan érzés, mintha valami lebutított, kiherélt, visszafogott linux-szal dolgoznál.

Ebben teljesen igazad van. De "sajnos" single image Linux is fut 1024 CPU-n.

"The feat was achieved on an SGI Altix 4700 system powered by 1,024 Intel® Itanium® 2 processors running under a single copy of SUSE® Linux Enterprise Server 10 from Novell with SGI ProPack™ 5 for Linux. The configuration, which includes 4TB of system memory, is the largest single system image (SSI) attainable on a Linux® OS system. "

Ekkor írtunk 2006-ot.

--
trey @ gépház

Nekem szemelyesen szerencsere 'csak' a desktop koruli vergodes tapasztalatai jutottak (kernel, driverek, konkretan ld pl blogomban az iwlagn/iwlwifi problemait), a velemenyemet masok tapasztalatai, a forumokban, hirekben olvasottak alapjan alkottam.

A tisztanlatas kedveert hozzateszem, hogy tobb mint 6 eve szinte kizarolag Linuxot hasznalok desktopon otthon.

Ebben a sorrendben, bar a kernel magasan kiemelkedik a tobbi kozul. Es itt nem csak desktop felhasznalasra gondolok, pl. a LVM snapshot kod (ami ugye elsosorban ertelmet ad az LVM letenek) is nagyon sokaig bugzott, random megdogleseket produkalva backupkor, ami - valljuk be - nem igazan jo ajanlolevel.

A Linuxnal (ugye sokak szerin a Linux csak kernel, beszeljunk tehat a kernelrol) mar eleve a kernel config rendszer is ugy szar, ahogy van, egy atgondolatlan, osszevissza rendszer, amit csak baromi nehezen lehet megtanulni kezelni. Raadasul az allyesconfig, allmodconfig defconfig trion kivul nem igazan csinalnak config template-ket (hasznalhatot meg aztan vegkepp), pedig legalabb a virtualizacios cuccokhoz (xen, kvm, etc.) lehetne egy-egy config template.
A kernel API instabilitasa pedig mindig jo adu barmilyen vitaban, szoval most bedobjuk azt is.
-- 


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

Kezdetben arra használtam, amire való: egyszerű, karakteres felületen beállítani/megnézni azokat a dolgokat, amikre szükség(em) volt. Aztán a scriptfájlt is elkezdtem nézegetni, és jó sokat tanultam belőle, a speciálisan aix-es parancsok terén.
A smit(ty) tényleg jó eszköz, ha valamit relative gyorsan, az arra szolgáló/használható parancsok részletes ismerete nélkül kell megcsinálni.

Sajnos ezek a munkahelyek már csak ilyenek: azt kell csinálni, amit a főnök mond;) Ha AIX-es gépünk van, akkor azt kell gyűrni... és ha nincs rajta mittudomén, például rinetd, akkor lefordítjuk forrásból, kijavítjuk a platform-specifikus problémákat, örülünk... vagy ha hibás a gyári strnlen, összecsapunk egy sajátot... nem sírunk, dolgozunk;)
persze vannak keményebb káposzták is, pl az, hogy amikor lefordítunk mondjuk egy iconv-ot vagy (bármi mást) a shared libek verziószám nélküli lib*.a könyvtárakban keletkeznek a /usr/local/lib-ben, ami a verziókezelést kellemesen megnehezíti.

> ha hibás a gyári strnlen, összecsapunk egy sajátot...

Erre pedig van support. Csak nem pre-5.2 rendszer, hogy ilyenekkel kell vergodni?

> a shared libek verziószám nélküli lib*.a könyvtárakban keletkeznek a /usr/local/lib-ben, ami a verziókezelést kellemesen megnehezíti.

Ezt nem ertem, mi koze a fileneveknek a verziokezeleshez...???

Amikor elkezdtünk AIX-olni, akkor az volt az aktuális verzió... itten van a tárgyi bizonyíték: http://forum.index.hu/Article/showArticle?t=9046421&go=44340477&p=1#443…

A verzió valami olyasmit jelent, hogy ha forrásból telepítem a foo-1.1-et, akkor keletkezik nekem egy /usr/local/libfoo.a, benne egy libfoo-1.so, ha pedig ezután telepítem a foo-2.4-et, akkor a libfoo.a szépen felülíródik, új tartalma libfoo-2.so lesz, a régi libfoo-t használó programok meg szépen megszűnnek működni.

Köszi a hozzászólást, de sajnos a generikus unix ismeretek itt nem segítenek, az AIX-nek saját hagyományai és szokásai vannak.
pl:

$ ldd /bin/sh
/bin/sh needs:
/usr/lib/libc.a(shr.o)
/unix
/usr/lib/libcrypt.a(shr.o)

Ha kitörölném a libc.a-t, akkor a /bin/sh nem indulna el, mert a shr.o (a 'shared object' rövidítése) hiányozna neki.

( doc | 2010. 08. 24., k – 13:26 )

IRIX
mar csak az egzotikus hw miatt is hatalmas elmeny (az Octane-om meg az O2-m akar mindennapi feladatokra is hasznalhato a mai napig)
-
Slackware current / OSX Snow Leopard

En sem neteztem vele (nincs hozza jelszo, se installkit, fel kene torni, csak lusta vagyok:) valami demo oldalt lehet megnyitni, rajta egy animalt SGI logoval, meg nem tudom meg mivel, de ez mar sok volt neki, ugyhogy nem is eroltettem. Pedig, amint az IRIX-rol olvastam az alapjan nem lenne nehez dolgom a toressel;>

Nem fikazom, sot, alapvetoen imadom az SGI/Silicon Graphics gepeket (egyreszt mert kurva jol neznek ki, masreszt pedig egy retkes PC-bol is kepesek olyasmit kihozni, amitol a legtobb kocka megnyalja mind a tiz ujjat:D pl. a Visual Workstation 320/540 az egyedi chipsettel... amikor meghallottam, hogy az Apple atall Intel processzorra, remeltem, hogy ok is ilyesmit csinalnak, de nem), csak azert az IRIX-rol neha olvasni erdekes dolgokat/velemenyeket.

A fizikai hozzaferes es a biztonsag kapcsolatarol azert kicsit mas a velemenyem, illetve a tapasztalatom, de altalaban ugy van, ahogy irod:)

( tomeeSAN | 2010. 08. 24., k – 17:34 )

Szevasztok

Solaris egyenlőre nem hal ki!
Oracle-ék az üzletpolitikát kicsit átlövik, de a solaris és a sparc megmarad!
Veszel egy baromi drága gépet, és nagyon olcsón kapsz hozzá adatbázist...
Viszont az új árakat elnézve x86-os SUN ( Oracle ) gépet, a közeljövőben nem veszünk, ha az ember épp nem oracle-t szeretne rajta (szerintem nem versenyképes az IBM gépekkel )...

Én sol 10 upd 6 -vagy az utánival kezdenék... ott már stabil a lucreate :) ( sun mérnökök szerint is )

SUN - We make the NET WORK

Passz, neked vannak adataid? Amugy meg nem az volt a kerdes, hogy _jelenleg_ hanyan hasznaljak, hanem a solaris jovojerol szolt a csevely. Marpedig a Oracle RDBMS kitunoen fut OEL rendszeren, kovetkezeskeppen minimalis igenye van az RDBMS piacanak a Solarisra (SPARC). Nem hinnem, hogy az itthoni OEL eladasok szamai motivalna a Oracle-t, hogy esetleg szuntesse be az OEL fejleszteset.
-- 


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

( elhasznalo | 2010. 08. 24., k – 18:00 )

Vegigolvasva a topikot ertem miert jarok ide evente ketszer.

omglolb+

kerdesre valaszolva:

Mac OS X

¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
A szak­ember olyan barbár, akinek tudatlansága nem terjed ki min­denre. (Stanislaw Lem: Az Úr hangja)

Unix es van jovoje. ellenben ezzel a linuxos portallal.
¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
A szak­ember olyan barbár, akinek tudatlansága nem terjed ki min­denre. (Stanislaw Lem: Az Úr hangja)

Irónia nélkül: ha pölö én fikázok valamit az azért van mert vagy már létezik annál jobb megoldás, vagy precízen pontosan meg tudom mutatni, hogy miben kell és lehet javítani az adott dolgon.

A srácúr magát a portált fikázta meg, kérdem én mutasson ennél jobb magyar unixos portált jelenleg? Kétlem, hogy tudna.

--
GPLv3-as hozzászólás.

A Unixos emberek egy resze vagy kikopott a temabol (= got a life, vagy megunta a sysadminsagot, es elment projektvezetonek), vagy hagyta magat elidegeniteni a HUP-tol ('there be trolls'). En szemely szerint jol elvagyok a sajat Unixos dolgaimmal, es nem nagyon erdekel a 'zaj'. Az ertelmes, erdeklodo emberek magtalaljak egymast, es fenntartjak azt, ami miatt meg mindig erdemes idejarni.

Szerintem a Linuxszal is erdemes foglalkozni azok miatt, amik jok benne.

szerinted mennyiben segit az OSX megismerese es hasznalata mondjuk egy AIX vagy HP-UX kezeleseben (jobban, mint a Linux ismerete)?
az altalanos Unixos toolok kb ugyanazok mint Linuxon (bar a GNU-s cuccok gyakran engedekenyebbek), az OSX-specifikus dolgoknak, GUI-nak meg semmi koze random Unixokhoz
-
Slackware current / OSX Snow Leopard

Igen, csakhogy a OSX egyben BSD/UNIX is, igy meg lehet ismerni pl. a disk/rdisk differenciat, a bootolas mechanizmusat, es meg sok egyeb mast is. AIX-en meg nem hiszem, hogy egy elmeny lenne a mindennapi desktop feladatok vegzese. Raadasul Linuxrol atterve ra kellett jonnom arra a szomoru igazsagra, hogy a linuxos es a unixos tooloknak kozuk nincs egymashoz (jo, ls, find, grep meg ilyenek kvazi-standardok, de pl. adj ki egy netstat-et $RANDOM UNIX-on, es lon csodalkozas (nehol nincs, nehol tok masra valo...). De ugyanez all ipl. a route parancsra is, es ezek ilyen total alap rendszerparancsok voltak.

Egyebkent bennem az volt az elkepzeles, hogy OSX-et hasznalva desktopon kenyelmesen meg lehet tanulni a konzolos dolgok kezeleset (amellett, hogy kozben van egy rendes oprendszer, amit lehet hasznalni desktop feladatokra, lsd. meg jatekok AIX-en...), ami ad egy alap UNIX ismeretet, es hozzaszoktat a szintaxisokhoz, ami esetleg jelentosen elterhet a Linuxostol (szinte mindig). Ha mar az embernek ilyesmi a kezeben van, akkor mar konnyebben boldogul egy UNIX-szal, mintha a Linuxos beidegzodeseivel kinlodna. Ezt tapasztalatbol mondom, en ezeket mar vegigszivtam.
-- 


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

Jo, akkor vigyel ki egy atlag Linux usert a HP-UX -hoz, es mondd neki, hogy innentol kezelgessed aranyom. Nem hinnem, hogy kissebb szemeket meresztgetne, bar talan bejelentkezni meg tudna.

Egyebkent meg nyilvan nem a divatmacesekrol volt szo, hanem azokrol, akik szeretnenek megtanulni valamilyen UNIX rendszert kezelni (ugye, errol szol a topicindito), marpedig arra az OSX alkalmas.

Nem tudom, miert kell erolkodni azon, hogy felreerts valamit, ami a kontextusaban nyilvanvalo.
-- 


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

Nem ezt állt szándékomban kiemelni, sajnálom, ha így értetted. AIX-ban is van LVM, HP-UX-ban is, Solarisban is, szóval nem hiszem, hogy ez a Linux fejlettségét jelezné.

Csupán arra céloztam, hogy nem olyan rendszeren kéne unixot tanulni, amelyiken esély nincs arra, hogy a viszonylag új, de már alap technikákat megtanulja. Ilyen az LVM, ami nélkül manapság szerintem már bűn gépet telepíteni.

Desktopra? A rugalmassága szerintem megfizethetetlen.

Nem kellett a kukába dobni.

Jelentkezik két ember az állásra, egyforma képességekkel, AIX rendszeradminnak. Mindkettőtől megkérdezem, hogy használt-e már LVM-et valaha. Az egyik bólint,hogy persze, hogyne, otthon is az van. A másik meg néz kerek szemekkel, hogy mi az.

Én úgy hiszem tudom, hogy melyik embert fogom felvenni.

Omm... az LVM mennyire tanulhato dolog? All a kezelese mondjuk 5 parancsbol?

Nagyobb gond tud az lenni, hogy egy linuxon edzodott emberke azt keptelen lekerdezni (nmap nelkul), hogy milyen portokon figyelnek programok, pedig ez sokkal alapabb kerdes az LVM-nel. De felhozhatnam mondjuk a ksh kezeleset (OSX-en alapbol van ksh, csak nem az a default shell).
-- 


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

Ez az lsof szépen rámutat az AIX jósága (mert tényleg az) és használhatósága közötti különbségre:

# ls -l /usr/sbin/lsof
lrwxrwxrwx 1 root system 28 Oct 9 2009 /usr/sbin/lsof -> ../../opt/freeware/sbin/lsof

Halványan azt is sejteti, hogy (ma már) mennyire kell elveszni a Linux után az AIX konzolnál... és itt persze nem arra gondolok, hogy ubuntu akárhány első installja után DB2 alá fog tuningolni bárki.

file -h $(which lsof)

;-)

btw. 


# file -h $(which lsof)
/usr/sbin/lsof: symbolic link to /usr/sbin/lsof64.
# file -h $(which lsof64)
/usr/sbin/lsof64: 64-bit XCOFF executable or object module not stripped

 # lslpp -wcq /usr/sbin/lsof64
/usr/sbin/lsof64:lsof.base:0

Van rendes BFF-ben is egy ideje.

Amit felhozol az hibás érvelés.

Linuxon meg lehet ismerni az LVM működését.
OSX-en nem lehet.

Linuxon edződtem, és le tudtam kérdezni. Zseni-e vagyok?


ap:~# vg
vgcfgbackup vgconvert vgextend vgreduce vgscan
vgcfgrestore vgcreate vgimport vgremove vgsplit
vgchange vgdisplay vgmerge vgrename
vgck vgexport vgmknodes vgs
ap:~# lv
lvchange lvdisplay lvmchange lvmsadc lvremove lvs
lvconvert lvextend lvmdiskscan lvmsar lvrename lvscan
lvcreate lvm lvmdump lvreduce lvresize

Ez szemre több mint öt. Elismerem, hogy a napi használatban tényleg nem több amit használ az ember, jobbára a lvextendre van szükség. De nem is arról van szó, hogy a parancsokat ismerje, arra ott a redbúk meg a többi doksi. A szemlélet a fontos, hogy tudja, hogy lehet ilyet csinálni, és hogy hogyan lehet. Aix-on nagyon szép az lvm, minden fontos dolog le van benne írva, a blokkméretekről meg mindenről, aminek utána kell olvasni, utána ami linuxon lvcreate, az aixon createlv, oszt jónapot.

Ja, és a ksh... Egyrészt egy aptitude install ksh nem egy rettenetes nagy kihívás. Másrészt meg nem érdekel, hogy ismeri-e a ksh-t, ha tud csh-ban vagy bash-ban vagy *sh-ban jól érthető, olvasható, kommentezett, mások által is áttekinthető scriptet írni, akkor tudni fog ksh-ban is, legfeljebb elmegy pár napja a man olvasgatásával meg a ksh optimalizációk megismerésével. Amik szépek ugyan, meg gyorsak, de épp azt nehezítik, hogy mindenki könnyen olvashassa a kódot (lásd sed). Ha meg olvshatatlan, dokumentálatlan munkát ad ki a kezéből, akkor mindegy, hogy milyen szuperül oldotta meg a problémát, a következő embernek nulláról kell újraírnia mindent.

Szerintem.

Azért a Linux-os lvm-et meg az AIX-es diszkkezelést annyival elintézni, hogy "ami linuxon lvcreate az aixon createlv"... Picit nagyobb az eltérés - kezdve az elvi alapoktól...

Bár a ha tud csh/bash/*sh-ban normálisan scriptet írni, akkor tudni fog ksh-ban is... Aki csh-val (brrr...) kezdi, az azért elég sokáig fog "szenvedni" más shellek használatával.

"Ha meg olvshatatlan, dokumentálatlan munkát ad ki a kezéből, akkor mindegy, hogy milyen szuperül oldotta meg a problémát, a következő embernek nulláról kell újraírnia mindent."
En azert torekedni szoktam arra, hogy a kodjaim szepen formazottak, es ondokumentalok legyenek.

Az AIX es a Linux kozti hatalmas kulonbsegekre itt feljebb a kollegak mar felhivtak a figyelmedet, gyak. a Linuxos tudast dobhatod a kukaba amikor leulsz egy AIX ele, gyanitom meg a parameterezes sem ugyanaz.

Ami a ksh-t illeti, azert a bash/csh-hoz kepest eleg nagy kulonbsegek vannak, a par napos man olvasgatas korosan optimista becsles volt.
-- 


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

Igen, engedékenyebbek a linuxok. Nagyon jó fogalmazás. Ezért volt az, hogy amikor a linuxon edződött fejemmel leültem először a SCO UNIX elé, először megtéptem a hajam. De amikor megszoktam, megtanultam a sajátosságait, az lett a véleményem róla, hogy kevés jobb eszköz volt a kezem alatt, azok is mind mainframe-en vagy middleware-en kerültek elő. Ezért szerintem sem alkalmas a linux felkészíteni valakit egy rendes kereskedelmi unixra. Legegyszerűbb egy rendes unixot feltenni és azon tornászni.

Ha x86-on akarsz ismerkedni legálisan az OSX-szel kapcsolatban álló fapados óperenciás rendszerrel, akkor ingyenes lehetõségként adott a Darwin. v8.0.1 iso letölthetõ pl. az apple oldaláról is. Régebbi Darwin-t nem javaslok ebbõl, mert durván bugos (a legfrissebb is, de az még a legjobban virtualizálható)

http://hup.hu/taxonomy/term/209
http://www.youtube.com/watch?v=QXz7-BNC6jw
http://nocirc.org/

( turul16 v | 2010. 08. 25., sze – 13:40 )

Inkabb legy profibb Linuxos. Hosszutavon jobban megeri IMHO.

De, ha mindenkeppen akkarsz unix rendszert latni, akkor Solaris. a nem desktop, kereskedelmi unixok piacanak kb. felet viszi es meg jo darabig lessz is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Most egyetemen a Schönherzben állítólag kapunk fix IP-t és saját domaint is. A lehetőségeim kitárultak :) Egyenlőre haladok linux vonalon tovább, a sulinak van solarisa, akármikor be tudok rá ssh-zni. Amúgy félek kicsit a Solaris, OpenSolaris jövőjétől. AIX lehet felkapaszkodóban van, de nincs alá vasam.

Root-Tech

( goodbyte v | 2010. 08. 25., sze – 13:54 )

+sok az AIX-nak.
Egy éves tapasztalatom van benne céges környezetben, és nagyon bátran merem ajánlani, hogy ismerkedj vele.
Vasat is lehet hozzá szerezni kis szerencsével, nekem pár tízezer forintért sikerült, amin még az 5.3-as AIX simán elfut. Persze nem két szekrény méretű vasra kell gondolni...
Az enyém pl akár desktopra is alkalmas lehet, mivel van benne 3D gyorsítós (!) VGA és van rajta X is (még nem volt alkalmam kipróbálni).

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"