Miben jo/jobb a(z) (Open)Solaris?

Sun Solaris, SunOS

Elnezest, ha tobbszor felmerult kerdest feszegetek.

Az erdekelne, hogy akar objektiv, akar szubjektiv szemontok alapjan miben jobb a Solaris a Linuxnal, *BSD-nel vagy egyeb kereskedelmi Unixoknal. Egy-egy szempontnak is orulnek, a lenyeg az, hogy lassam, egyes emberek mi alapjan preferaljak.

Szamomra elegge ismeretlen es marginalis OS (nagyon keveset adminisztraltam, nagyon feluletesen), es amiket eddig hallottam/lattam rola, azok nem gyoztek meg tulsagosan, bar ez nem jelenti azt, hogy eloiteleteim lennenek iranta.
(Bevallom, ez nem teljesen igaz: mikor meglattam, hogy OpenSolaris-ban csak full GUI install tamogatott GNOME-mal, illetve a default shell bash, meglepetesemben kis tulzassal a terdemen tortem kette a cd-t.)

szerk.

- Nem a flame erdekel
- Azok valaszoljanak, akik hasznaltak/hasznaljak is

  • 11026 megtekintés

( znurgl | 2009. 03. 18., sze – 17:09 )

Ez egy jó kérdés, engem is érdekel, csak ne legyen belőle flame.

En is foleg okulni szeretnek belole, elsosorban a tapasztalatok erdekelnek. Elobb vagy utobb szeretnem kozelebbrol is megismerni a Solaris-t.

Sajnos hiaba hasznalok AIX-et, megsem tudom azt allitani, hogy a marketingdumakon kivul uzletileg is ertekelheto, mereseken alapulo elonyoket tudnek mellette felsorolni, persze a marketinganyagokat en is olvastam. Adminisztratorkent viszont jonehany kellemes ervem van mellette.

( Replaced | 2009. 03. 18., sze – 17:11 )

gyonyoruszep kernele van :)

--
When in doubt, use brute force.

A Minix csak elmeletben szep.
Implementálnom kellett userspaceben TCP-t Minix alatt egy kurzusra (azon az egyetemen, ahol Tanenbaum tanit - VU Amsterdam), soha eletemben tobbet nem akarok Minixel de meg osszefutni sem. A userlandje a 90-es eveket idezi, es most nem a user interfacere gondolok, hanem a programozoi interfacekre.

--
The Net is indeed vast and infinite...
http://gablog.eu

( selli | 2009. 03. 18., sze – 17:16 )

en nem hasznalom ( csak vbox ba van fent ) nem is ertek hozza, szoval meg lehet dobalni kovel :) de szerintem a legjobb pontja a ZFS.
Linuxba talan majd a btrfs tud majd versenyezni vele. amugy en is kivancsi vagyok a velemenyekre

( Yorirou | 2009. 03. 18., sze – 17:36 )

subscribe

"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q

par dolog igy hirtelen:
- svc: hanyinger az egesz, de mar ott gazos hogy pl a manifestek XML ben vannak. XML bazmeg ajjjj. brainfuck
- normalis csomagkezeles (nem a pkgadd, pkgrm nem az es ne kelljen mar sunfreewaren kutatni)
- installer kernele nem 64 bites igy 2T< tombre nem tudsz installalni. csak telepites utan tudod hasznalni. shitshow (bar azota lehet javitottak)
- ezen kivul nem beszelve arra hogy kb 20000 evre visszamenoleg backware compatible minden es ez kicsit ahhoz vezet hogy kenyelmetlenul erzem magad a rendszeren

"- ezen kivul nem beszelve arra hogy kb 20000 evre visszamenoleg backware compatible minden es ez kicsit ahhoz vezet hogy kenyelmetlenul erzem magad a rendszeren"
a windows-t is ilyenre tervezték. csak nem sikerült. lehet ezért van, "hogy kenyelmetlenul erzed magad a rendszeren"?

--
"Megtanultam a zenét, de nem csináltam, s azóta tudással, de irigység nélkül hallgatom.
Megtanultam egy sereg tudományt, mesterséget és művészetet, értek hozzájuk, de nem csinálom, s így érdektelenül tudom azokat élvezni. "
Hamvas Béla

en szeretem az svct ;)
a csomagkezelesre ott a pkg. tud mindent. (opensolarisrol beszelek most, a topic is az)
opensolarison ez a kernel dolog annyira nem izgat, mert ugyis kezzel konfizok fel mindent install utan ;) es ott mar 64bit.
a backward compatibility meg hat, ez van. nem minden os hobbios, ahol lehet 2 naponta breakelni az APIt :)

"semmiben egy fos az egesz."

Azert ennyire megsem kellene irigyelni, hogy masfel procinal tobbre is skalazodik. ;)

"- svc: hanyinger az egesz, de mar ott gazos hogy pl a manifestek XML ben vannak. XML bazmeg ajjjj. brainfuck"

Az openbsd-ben levo semmi tenyleg sokkal jobb nala (mar ha a josag mertekegysege az xml-file-szazalek).

"- normalis csomagkezeles (nem a pkgadd, pkgrm nem az es ne kelljen mar sunfreewaren kutatni)"

ips

"- ezen kivul nem beszelve arra hogy kb 20000 evre visszamenoleg backware compatible minden es ez kicsit ahhoz vezet hogy kenyelmetlenul erzem magad a rendszeren"

Ez feature.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

( sibidiba | 2009. 03. 18., sze – 18:06 )

Annyira nincs nagy tapasztalatom, de egy-ket gyongyszem: DTrace, ZFS, Containers/Zones, Trusted Extensions, jol skalazodo utemezok.

--
The Net is indeed vast and infinite...
http://gablog.eu

( gee v | 2009. 03. 18., sze – 18:16 )

Én amikor telepítettem, (nem open) Solarist, nem bash volt a shell, és nem volt gnome.

Miért azt tettem fel? Egyszerű: a programokat amiket használunk, jellemzően kétféle rendszerre készítik el:
HPUX és Solaris.
Milyen programok ezek? Számlázórendszer, provisioning alkalmazás, ilyesmi. Meg volt egy tűzfal is, de az lehet, hogy más rendszerre is elérhető lett volna, de nekem csak Solarisra való telepítő CD-t küldtek.
Nekem kb. mindegy volt, használtam, adminisztrálgattam ezt is azt is. Vannak dolgok, amit máshogy kell megcsinálni egyikben vagy másikban, de szerintem tök mindegy melyik. El kell olvasni, aztán jól van.
De azt mondják a népek (pl. a szoftverház, aki fejlesztette az egyik szoftvert), hogy ugyanaz a program Solarison gyorsabb.
Egy program volt, amit HPUX-on is és Solarison is használtam (meg persze az Oracle), de nekem nem tűnt különbözőnek.

Valaha nagyon régen (10 év) még DEC OSF-1-et is használtak ilyen számlázós dolgokra, ez mostanában már kikopott.

Mást, pl. AIX nem láttam egyáltalán, valahogy a telkó szektorban úgy látszik, nem terjedt el nagyon.

G

Lehet hogy o csak kapta a szervert es mivel nem kellett a gnome, leszedtek. Honnan tudod? Annyira jo, amikor latatlanba fikaz valaki.

A bash meg lehet nyugodtan gepen, nem kotelez senki a hasznalatara.
-- 


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

( sartek | 2009. 03. 18., sze – 18:25 )

stabilitas:
kernel: nem azt mondom h sose volt crashem, de mind azert mert erosen alfa software-t teszteltem pl: fuse-ntfs-3g, boomer (1 crashem volt boomerrel, bejelnetettem es par nap utan kaptam is az uj binaryst azota nincs vele baj (ilyen tereN)
GUI: ez ugy ket fo reszbol all:
X: semmi bajom nem volt vele
GNOME: mivel /dev et hasznalok osszeakadtam par "blocker"-rel (pl: #6656) de relative hamar meglett oldva, de maskullonben stabilnak mondanam
Driverek: itt vannak gondok, bar speciel nekem csak 1 eszkozom van amihez nincs driver: tv tuner, es valoszinu hogy nem is lesz (az enyemhez saa7134)

--
HUP@Steam

@sartek
tunerhez:
http://bt848x.sourceforge.net/

Én egy pctv pro-t be tudtam izzítani így, ezzel, x86-on.
Eléggé fapados, meg nem karbantartott, de kép+hang van, meg csatornát is lehet váltani, tehát bőven több, mint a semmi! :)
Ja, igen: az "experimental"-lal volt sikeres a project, a bt848x nem ment.

<-------
You can't grep on dead trees.

(szívesen! :))

Sajnálom, más meg aztán végképp tényleg nincs... :(
Gondoltam már arra, hogy fel lehetne dobni az opensolaris.org valamelyik listáján, hátha valaki lecsapna rá, hogy kicsit rugdossa (én ehhez kevés vagyok), de aztán sose jutottam el a tettig.
Régen néztem és is; majd megint ránézek, hogy van-e valami buktatója, esetleg.

<-------
You can't grep on dead trees.

( znurgl | 2009. 03. 18., sze – 21:33 )

Tehát akkor elsősorban desktop, mint server?

( w4rp v | 2009. 03. 19., cs – 11:08 )

Hamár opensolaris a téma, itt megkérdezem:
Van lehetőség rá, hogy headless install-t csináljak valahogy? Tehát netboot, aztán ssh-n a folytatás?

( _Joel | 2009. 03. 19., cs – 11:50 )

2 évig Sol 10, december óta OpenSolaris van a kiszolgálóinkon. A futó alkalmazások: Postfix, Postgresql, Sun Web Server, Glassfish (Trac, Hudson, subversion), elsősorban saját java alkalmazások hostingja és fejlesztésének támogatása a profil.

- svc-vel én személy szerint ki vagyok békülve. A "fúj XML" kifogásnak jó, érvnek nem. Egy manifest file-lal és egy svccfg-vel megadható paraméterezéssel pl simán elfut egymás mellett init script duplikáció nélkül több szolgáltatáspéldány (pl. dev/qa/prod alkalmazásszerver domain-ek).

- ZFS. Backuphoz nagyon jó - pl a mailbox-okat tároló könyvtárról naponta készül egy snapshot -> ha az ügyfél letörölte a levelét reggel, az esti snapshotról vissza lehet állítani a mailbox-át, mindez gyakorlatilag zéró adminisztrációt igénylő feladat (a restore is csak egy cp). Aztán a napi snapshot-okat lehet egy hét után törölni (nekünk most heti 1 őrződik meg 2 hónapig, azután törlődnek azok is). Snapshot-okat backup-olni is lényegesen egyszerűbb.

- Régebbi solarisokhoz képest rengeteg a kényelmi változás - az integrált ipfilter hasznos, alapértelmezett a bash shell, a root user csak egy role lett, az új package management is végre hasonlít ahhoz, amit az ember más rendszereken megszokott. Desktopra nem használom, bár a live cd-t bebootoltam a notebook-omon - hang is volt, a wifit is egyből felismerte és kérte a WPA kulcsot. Látszik, hogy dolgoztak rajta, bár érezni, hogy ez inkább csak amolyan "afterthought" és nem egy koherens stratégia eredménye.

Szubjektíve: nekem sokkal kényelmesebb és kellemesebb (Open)Solarison dolgozni, mint Linuxon (szerver célra gondolok, desktopilag köszönöm egyelőre még maradok Windowson).

--
The reason that half of us are in computing at all is that we see computers as things that we can make beautiful things out of..

OpenSolaris == Linux
Solaris != Linux

Miert lenne jo 150 soros XML fileokat configolgatni + scriptek, amikor ugyanazt tized annyiban meg lehet csinalni. Ez az erv. Ezen kivul a ZFS memoriahasznalata nalatok pl a legjobban hasznalt gepen mennyi? Mutass mar par statisztikat hogy mondjuk egy 4T -s pool mennyit "zabal".

Ha a starthoz execelni a stophoz killelni kell egy processzt akkor valóban elég egy shellszkript és minden más overhead, de általában elvárná az ember hogy ha elcrashel valamiért a cucc akkor induljon újra, ha probléma van vele ne induljon végtelen ciklusban és tudassa az okát is, lehessen több példányt indítani belőle külön konfigurációkkal, a konfigurációkat lehessen snapshotolni, legyen értelmes dependency kezelés, stb.

szerk: és általában nem kell az XML-ekhez nyúlni, svcadm-nak van konfigurációs konzolja.

Az én világképemben vannak függőségek, egy alkalmazás ne írja tele a logokat és ne tűnjön félig működőnek ha a köztudottan nem működhet mondjuk adatbázisszerver nélkül.

Az alkalmazáslogika így lehet egyszerűbb is, nem kell mindenféle retry/reconnect heurisztika, ha meghal, mert megállt egy függősége. Ezt vegye észre az szolgáltatásokért felelős daemon és állítsa le, mielőtt belefárad a próbálkozásba -majd indítsa újra ha ismét működik minden.

Az, hogy egy progi szar, arrol igazabol a rendszergazda nem sokat tehet, viszont azert jo, hogyha a oprendszer kepes arra, hogy alapveto dolgokat lekezeljen. Kulonben meg en jobb szeretem, ha szepen sorrendben indulnak a dolgok, es nem kell mindig fake hibauzeneteket kapnom egy logchecktol csak azert, mert az idiota oprendszernek keptelenseg megmondani, hogy a postfix meg a samba LDAP-fuggo, ugyhogy legyszives.

Es tudod mi a vicc? A fuggosegkezelest nem is olyan nagyon bonyolult lekezelni. Eleg sok jo pont van a fuggosegkezeles oldalan ahhoz, hogy inkabb egy olyan rendszert valasszak, ahol lehet ilyent mintsem olyant, ahol nem.
-- 


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

Tessék, a 44 soros Glassfish indító manifest-em: 


<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type='manifest' name='glassfish'>
<service name='application/glassfish' type='service' version='1'>
 <dependency name='network' grouping='require_all' restart_on='none' type='service'>
  <service_fmri value='svc:/milestone/network:default' />
 </dependency>
 <dependency name='filesystem-local' grouping='require_all' restart_on='none' type='service'>
  <service_fmri value='svc:/system/filesystem/local:default' />
 </dependency>
 <exec_method type='method' name='start' exec='/lib/svc/method/glassfish start' timeout_seconds='120' />
 <exec_method type='method' name='stop' exec='/lib/svc/method/glassfish stop' timeout_seconds='60' />
 <property_group name='general' type='framework'>
  <propval name='action_authorization' type='astring' value='solaris.smf.manage.glassfish' />
  <propval name='value_authorization' type='astring' value='solaris.smf.manage.glassfish' />
 </property_group>
 <instance name='production' enabled='false'>
  <method_context>
   <method_credential user='webservd' group='webservd' />
  </method_context>
  <property_group name='glassfish' type='application'>
   <propval name='domain' type='astring' value='production' />
  </property_group>
 <property_group name='general' type='framework'>
  <propval name='action_authorization' type='astring' value='solaris.smf.manage.glassfish' />
  <propval name='value_authorization' type='astring' value='solaris.smf.manage.glassfish' />
 </property_group>
 </instance>
 <instance name='development' enabled='false'>
  <method_context>
   <method_credential user='webservd' group='webservd' />
  </method_context>
  <property_group name='glassfish' type='application'>
   <propval name='domain' type='astring' value='development' />
  </property_group>
 <property_group name='general' type='framework'>
  <propval name='action_authorization' type='astring' value='solaris.smf.manage.glassfish' />
  <propval name='value_authorization' type='astring' value='solaris.smf.manage.glassfish' />
 </property_group>
 </instance>
 <stability value='Evolving' />
</service>
</service_bundle>

Amint láthatod dependál két másik service-re, beállítja, hogy ne rootként hanem webservd userként futtassa a szolgáltatást, definiál egy domain nevű változót, amit svccfg-vel lehet majd kívülről instance-onként állítani. Majd megadja, hogy a szolgáltatást ki-be kapcsolgathatja majd minden olyan user, aki a "solaris.smf.manage.glassfish" authorization-nel bír (RBAC, ugye - ez is egy kézzel felvett authorizáció).

Mindezt megcsinálja kétszer - egyszer a production, egyszer a development domain-re - megintcsak be lehetne állítani egy külön authorizációt a production domain-re, mint a devre, és akkor userenként lehetne külön állítgatni, hogy kinek melyik domain leállítására/indítására van joga... Egyelőre kicsi cég vagyunk, nincs rá szükség. Bár pl ezzel nagyon szépen lehetne akár hostingot adni delegated adminnal másoknak...

A "scriptek" helyett egyetlen script van: 



#!/sbin/sh
#

getproparg() {
        val=`svcprop -p $1 $SMF_FMRI`
        [ -n "$val" ] && echo $val
}


DOMAIN=`getproparg glassfish/domain`

if [ -z $SMF_FMRI ]; then
        echo "Error: SMF framework variables are not initialized"
        exit $SMF_EXIT_ERR
fi

if [ -z $DOMAIN ]; then
        echo "Error: glassfish/domain property not set"
        exit $SMF_EXIT_ERR_CONFIG
fi

case "$1" in
'start')
        /opt/glassfishv3-prelude/bin/asadmin start-domain $DOMAIN
        ;;

'stop')
        /opt/glassfishv3-prelude/bin/asadmin stop-domain $DOMAIN
        ;;

*)
        echo "Usage: $0 {start|stop}"
        exit 1
        ;;

esac
exit $SMF_EXIT_OK

Légyszives csináld meg tized ennyiben a fentit. Két domain legyen indíható, ne csak a root user tudja őket leállítani és elindítani (nekem Hudson taskokból kell tudni indítani/stoppolni a domain-eket, amik nem privilegizálva futnak, de egy fenti authorizációt azért tudok adni a nem privilegizált usernek).

Utoljára:

"- svc: hanyinger az egesz, de mar ott gazos hogy pl a manifestek XML ben vannak. XML bazmeg ajjjj. brainfuck"

Ezek eléggé egyértelműen tényszerű (objektív) és nem szubjektív kijelentések. Írd oda legközelebb, hogy "Szerény Szakmai Véleményem Szerint", és akkor mindenki pontosan tudni fogja, hogy ezt miként is kezelje.

Másrészt ha a te írásodra akartam volna reagálni, akkor arra reagáltam volna. A topik indítónak akartam válaszolni - látom hiba volt beleírnom, hogy a "A "fúj XML" kifogásnak jó, érvnek nem.", mert ez neked olyan volt, mint a vörös posztó. Ekkor elkövettem azt a hibát, hogy a "Miert lenne jo 150 soros XML fileokat configolgatni + scriptek, amikor ugyanazt tized annyiban meg lehet csinalni." kijelentésedet megcáfolandó mutattam egy 44 soros manifestet + egy 37 soros scriptet (egyet, nem többes szám). Ilyenkor egy szerényebb személyiség valószinűleg önkritikát gyakorolna, és beismerné, hogy igen, túlzás volt a 150 sor, meg túlzás, hogy több scriptet kell írni - sőt akár még scriptet sem kell... Neked úgy látom ez túlságosan megviselné a lelkivilágodat, ezért inkább úgy teszel mint a Raiffeisen reklámban az ügyintéző amikor a böszme családapa a jövedelmét akarja elmondani. Végülis ez is egy stratégia...

124 milestone/multi-user.xml
127 network/shell.xml
129 network/network-routing-setup.xml
131 network/ssh.xml
132 system/auditd.xml
134 system/system-log.xml
138 network/login.xml
144 milestone/single-user.xml
161 system/sysidtool.xml
166 network/smtp-sendmail.xml
168 network/inetd.xml
226 network/forwarding.xml

---
113 nfs-server
118 sysidtool-system
133 sysidtool-net
137 smtp-sendmail
145 svc-mdmonitor
148 fs-usr
148 svc-stosreg
154 ipfilter
184 inetd-upgrade
187 net-init
218 net-routing-setup
250 mpxio-upgrade
267 fs-root
310 net-svc
342 net-physical
404 manifest-import

---

De nezzunk egy egyszeru peldat - sshd:

68 /lib/svc/method/sshd
131 /var/svc/manifest/network/ssh.xml

Aztan meg karikazgatom kell svcadm -l hogy felkapcsoljam a szolgaltatast es hogy ujrainditsam.

--- 8< ---

Nezzuk ezt normalisan, brainfuck nelkul:
(t60 robert 11172)$ grep ssh /etc/rc.conf | wc -l
1

ssh reszek /etc/rc -bol (keygen, sshd):
(t60 robert 11170)$ wc -l ssh
28 ssh

Es mi kell ahhoz hogy restartoljam? pkill -HUP -f sshd

Mégegyszer, hátha "átmegy".

Az SMF ha rossz, akkor nem az XML miatt rossz.
AZ SMF ha jó, akkor nem az XML miatt jó.

Az SMF ha rossz, akkor mondd el, hogy miért rossz, mert az XML csak egy bikeshed.
Az SMF ha jó, akkor szerintem azért jó, mert imperatív jellegű scriptek irogatása helyett deklaratív konfiguráció írássá változtatja a szolgáltatásindítás/leállítás/monitorozás problémakörét -> kevesebb a hibalehetőség, az infrastruktúra adja a naplózást, a többszörös újraindítási próbálkozásokat, a dependencia management-et, a letiltást/engedélyezést (lifecycle management), az ezekhez való hozzáférés management-et, stb.

'zdmeg! Hagyd már abba! Nem látod, hogy nem győződ meg? Szerinte jó, ha csak elindítani, meg leállítani tudod a szkriptet és mást nem tud a dolog, meg hogy nem tudsz különböző szempontok szerinti start-ot/stop-ot deffiniálni és még supervise-olni is a szolgáltatást. Oksi. Örülünk. Ennyi. Van aki meg szeretné, ha a nagyvállalati környezet működne a lehető legautomatikusabban. Azoin meg hogy "szarfosfekáliaszemét" ne akadj ki. Van aki így kommunikál, na.

Egyébként meg pontosan tudom, hogy mikor és hol kell XML-t használni. Pontosan tudom, hogy a legtöbb esetben, amikor használják akkor lehetne helyette valamilyen deklaratív nyelvet (scheme, SML, vagy ami tetszik) használni, és pontosan ugyanott tartanánk - csak a fejlesztők valamiért nem szeretnek interpretert írni, XML parser meg minden platformhoz van.

A service indítás/leállítás egy jól specifikálható domain - adja magát, hogy alkossunk rá egy DSL-t (Domain Specific Language). A Sun az svc-vel lényegében ezt csinálta, a DSL alapja meg egy XML formátum. Lehetne egy Perl API is, vagy bármi ami képes hierarchiát leíró asszociatív tömböket vagy listákat definiálni (LISP, hehe).

Lehetne írni egy olyan toolt is, ami egy más nyelven leírt service definíciót átformál XML-lé és beadja az svccfg-nek. Ekkore eltűnne előled az XML, és mondjuk így kéne leírnod egy service-t

new Service("application/glassfish).setStartMethod("/lib/svc/method/glassfish start).setCreds("webservd","webservd" stb.

Tudom, akkor jönne, hogy fúj Java-ban van leírva. Vagy fúj Ruby-ban. Vagy fúj Python-ban.

Mert valaki mindig meglátja a lényeget...

"OpenSolaris == Linux
wtf? rotfl...

"Ezen kivul a ZFS memoriahasznalata nalatok pl a legjobban hasznalt gepen mennyi?"

A Zfs memóriahasználata hangolható.
Nem mindegy, hogy a zfs eszi meg a ramot, vagy a page cache? A 4T-s pool pedig csak azért használ sok ramot, mert a zfs erőteljesen cache-el. Önmagában a zfs nem jelent több memóriahasználatot. De ha zavar, hogy túl gyors a file rendszer, akkor ki is kapcsolhatod a cachelést.

( syntern | 2009. 03. 19., cs – 12:59 )

részemről két indoka van az opensolaris használatnak: zfs és virtualbox. Nincs más platform, ami tudna ZSF-t vagy hasonló képességű filerendszert stabilan, illetve lenne rá ingyenes és _jó_ virtualizáció. Jah, és Java is fut rajta. Amúgy egy teljesen jó unix. Ez így négy. Ennyi.

Tudtommal nincs jelenleg masik stabil filerendszer, ami olyan beepitett volume managementtel, redundanciaval es live snapshotokkal rendelkezne, mint a ZFS.
VirtualBox es Java is van Linuxra, OS X-re, Windowsra, de ha egyszer Solarison atomstabil, miert szivassa magat az ember.

--
The Net is indeed vast and infinite...
http://gablog.eu

De igen, ezeket értem, de most ezt a párhuzamot nem értem :)
RHEL-t és SLES-t ugyan letöltheted, de utána semmilyen update nem lesz, míg nem perkálsz.
Fedora/Opensuse-nál meg lesz minden hozzá.

Viszont - ebben majd vagy megerősítenek vagy cáfolnak - Solaris-hoz van update, support nélkül is: http://www.sun.com/software/solaris/releases.jsp.

a.

Nehez kovetni, hogy eppen mi az aktualis policy, de support szerzodes nelkul nem minden update erheto el...
Ezt kicsit megfordítanám: ha valami éles helyre kell a rendszer, ahová nem "szabad" support nélkül telepíteni, akkor van jogosultsága az Opensolaris-nak?

Egyébként köszönöm a választ.

Amugy meg 1000 kulonbseg van aktualis Solaris / Opensolaris kozt, kezdve a pkg managementtel...
Szerintem ez annyira nem lehet gond. Az egyes Linux disztibúciók között is van rengeteg különbség, de ezeket meg lehet/kell tanulni. Nem hiszem hogy ez határozná meg, hogy mi lesz telepítve - nem azt írtam, hogy nincs befolyással a döntésre, de nem ez az elsődleges szempont.

Én igazából azt nem látom, mi az a "piaci rés", amit az Opensolaris hivatott betölteni :)
Megjegyzem Opensolarist még nem használtam, Solarist már sok helyen.

Köszi:

a.

Solaris 10 -hez és OpenSolaris -hoz is lehet supportot vásárolni. A kérdés nem ez, hanem ahova "nem szabad" support nélkül telepíteni, ott valószínűleg olyan alkalmazásról beszélünk, ami jelenleg Solaris 10 alatt támogatott.

A másik meg hogyne lenne gond, igen, a Linux disztribúciók közt is van különbség, de "támogatott" disztribúcióból már jóval kevesebb van, stb.. alapvetően az OpenSolaris pkg management ég és föld, és majd valamikor Solaris 11 lesz belőle.

A piaci rést én se látom, kezdve ott, hogy egy grafikus telepítővel indul (ami egyébként jó) és teljes grafikus környezetet telepít, pedig a többi feature-t tekintve végre túltehetnénk magunkat ezen a bloatware-ségen, de csak nem sikerül... Mint a Solaris következő verziója, egyébként igen jó irányba megy.

üdv

Hello,

nem akartam ennyire kihegyezni a supportra a kérdést, többen írták ebben a postban a hozzászólásokhoz, hogy alapvetően a támogatás a különbség. Én inkább arra gondoltam, hogy mennyire tudja helyettesíteni az Opensolaris a Solarist, ha nem "csak egy mailszerver" funkciót kell ellátni, tehát ha valamilyen 3rd-party alkalmazást kell feltenni, amihez van Solaris port (pl. Oracle, SAP).

A másik meg hogyne lenne gond, igen, a Linux disztribúciók közt is van különbség, de "támogatott" disztribúcióból már jóval kevesebb van, stb.. alapvetően az OpenSolaris pkg management ég és föld, és majd valamikor Solaris 11 lesz belőle.
Ezt nem értem: hogy jön ide a támogatott disztribek száma a a különbségekhez? És miért gond, hogy más pl a csomagkezelés? Használat szempontból szerintem tök mindegy - jó, a "berögzült" műveletek nem fognak működni :)
De ezt is meg lehet tanulni. Ha az elérhető "csomagok" száma ezzel csonkul, az egy érv, de nem tudom, hogy erre gondoltál-e valójában.

Én még mindig arra vagyok kíváncsi, hogy megéri-e Opensolarissal foglalkozni, érdemes-e időt belefektetni? Eljön-e valaha az az idő, mikor az Opensolaris releváns, meghatározó rendszer lesz azért, mert többet nyújt mondjuk a Solarisnál?

a.

A Solarishoz kepest sokkal tobb ujat nem fog nyujtani, hiszen feature-k szintjen azonos a ket rendszer.

A kerdes inkabb ugy helyes, hogy meghatarozo rendszer lesz-e valamikor azert, mert tobbet nyujt a Linux-nal.

A valasz viszont kerdeses. Jelenleg egy csomo alkalmazas van, ezek egy resze van tesztelve nem-linux alapu unixon is (bsd, solaris) egy masik resze nincs. Szerintem itt fel fog lepni a cel valaszt eszkozt effektus, vagyis az osol is csak olyan helyre lesz rakva, ahova inkabb valo. Nem hiszem, hogy tomeges elterjedesre szamithatunk peldaul a webszerverek vagy a mailszerverek kozt, tekintve hogy a legtobb alapozo hogyan Linux-ra van megirva, es Solaris-ban azert attol lenyegesen elteroen kell konfigolni eleg sok mindent.
-- 


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

>A Solarishoz kepest sokkal tobb ujat nem fog nyujtani, hiszen feature-k szintjen azonos a ket rendszer.
azert eleg sok dolog van opensolarisba ami nincs vagy onnan lett backportolva sol10 be
ugy zfs is opensolarisba jelent meg
meg ugy crossbow
de nincs kedvem se turelmem se idom most levadaszni az osszes feature-t :)
erdemes itt is szetnezni: http://opensolaris.org/os/projects
TERMESZETESEN van ami EOF EOL SOSEKEZDODOTT_EL stb

es megmegemlitenem ezt: fast reboot

--
HUP@Steam

Mitol lesz valami meghatarozo?

Csak hangos gondolatok:
- egyre több álláshirdetés jelenik meg, mert a cégek elkezdtek átállni (ahogy most relatíve sok Linux/Windows/Solaris hozzáértőt keresnek)
- lesz valami vizsga standard, mint a Solaris esetében pl. vagy az MS-nál (Linuxnál?)
- a 3rd-party cuccokból megjelenik az Opensolaris port (és ahhoz support)

Bár ezek nagyjából valszeg' egyszerre fognak megjelenni.
És igen, a "hany PC-n fut" kérdéssel szoros összefüggésben vannak :)

a.

Egyelore a sol/osol hanyada semmifele modon nem meghatarozo, a publikus szerverek azon resze, mely nem windows alatt fut, jobbara linuxot futtat, egy kisebbreszt meg BSD-t es Solarist.

Visszaterve: ez egy tobb komponensu fogalom, de az, hogy jelenleg az internetet kiszolgalo szerverek aranyaban mennyi a Solaris reszesedese, na az peldaul egy meghatarozo szam.
-- 


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

Termeszetesen van ertelme vele foglalkozni, mar csak azert is, mert elobb-utobb ebbol lesz a Solaris 11 (stb).

Az elerheto 'csomagok' (ez kicsit linuxos szohasznalat) szama no vagy csokken, az open source cuccokbol tobb van (illetve _legalabb mar van_), kereskedelmi szoftverek tamogatottsaga jelenleg kisebb, bar ha ugy nezzuk, valoban Debianra is felreszelik az Oracle-t, szoval igy nezve kompatibilisebb a Solaris-szal, mint az a RHEL-al.

>elerheto 'csomagok'

nem tudom h ismeritek-e a: http://jucr.opensolaris.org/
roviden: .spec filejaidat (aki ismeri JDS-t tudja (bovebben) miez) "alakitja" at IPS formatumba. eloszor jucr.opensolaris.org/pending majd pkg.opensolaris.org/contrib -ba kerulnek a dolgok, beta cucc. de ~hasznalhato

az enyem volt az elso ami atment ezen a dolgokon, lehetoseg van csak elni kell vele, de mint lattuk vOrOnOn es rajtam kivul senki se hasznal rendszeresen opensolarist

--
HUP@Steam

Gyartson valaki ReiserFS supportot ra, es onkent meg dalolva terek at - laptopon. Tetszik a rendszer, meg tetszik a design, csak az nem tetszik, hogy dobni kellene minden adatomat ha migralnek. Jelenleg nincs meg egy diskem, amire kimenthetnem a cuccaimat a migralas idejere.
-- 


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

Nezd, alapvetoen a gond az, hogy nekem mindenkepp szuksegem van az adataimra. Csak siman nem rakhatom fel, mert ugye az adataimat nem erem el a Linuxos fajlrendszeren. Ha meg megse jon be valamiert, akkor megint rangassak ide valakit, hogy lecci megint kene a winyo visszafele migralashoz? Persze, nyilvan, megteszi, ha olyan, de ez azert egy eleg csunya ut. Meg MacOSX-hez is talaltam ReiserFS drivert, akkor Solaris-hoz miert nem lehet fejleszteni? Nem ertem en ezt.
-- 


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

Ahogy gondolod, bár osolarist a szememben pont a zfs tenné vonzóvá.
A reisert bizonyosan be lehet hekkelni osx alá is, de ez kb olyan, mint aki ntfs-en tartja a linuxos homeját.
Dualboot rendszert fenntartani a mérlegelés idejére nem pálya? Jelenlegi rendszeredddel dolgozol, utána próbálgatod osol-t, amire
felmásolod az adataid akkora részhalmazát, ami még elfér a zfs maradék szabad helyén, de elég arra, hogy próbálgasd, milyen lenne élesben.
Én ezt az utat jártam végig. Végül arra jutottam, hogy egy végre tényleg szép gnome témáért, fasza, de otthon valljuk be ritkán használt teljesítménydiagnosztikai toolért, meg egy big-iron vasakra tervezett tényleg fasza fájlrendszerért nem dobom a linux évek alatt kiizzadt hw-supportját, egy olyan osért, amivel még a netbootot sem lehet használni egy mezei intel nic-el (a drivernek kell(ene) a megfelelő állapotot beállítani a vezérlőn leálláskor)
De ki tudja, lehet 2010 mégse a Kapcsolat, hanem a desktop solaris éve lesz :)
A vinyók még kb két hétig nincsenek használatban, addig áll az ajánlatom,)

( vOrOn | 2009. 03. 19., cs – 13:01 )

Szamomra gyenge gepen sokkal egyenletesebb teljesitmenyt ad le OpenSolaris mint FreeBSD. Ertem ez alatt pl. filmnezesi elmenyeket eros ata/sata diszkterheles alatt (torrent). Mindketton hajlamos ilyenkor elcsuszni (kesni) a hang, de OpenSolaris nem produkalja a torpano, kihagyasokkal gyorsulo kepet hozza.
Plusz ahogyan oregszem es lustulok, egyre kevesebb kesztetest erzem programok forditasara.

( znurgl | 2009. 03. 19., cs – 18:43 )

És mi az alapvető különbség az opensolaris és a solaris között?

( janoszen v | 2009. 03. 19., cs – 23:00 )

Tudsz vele SunRay dobozkákat üzemeltetni, ami jó, mert nagyon vékony a kliens és hihetetlenül strapabíró (álmennyezetben, porban, stb és mennek).

( egittologo | 2009. 04. 04., szo – 12:51 )

többhelyütt olvastam hogy opensolaris a laptopokra, netbookokra koncentrál. Ezen felbuzdulva kipróbáltam. Minden jó lett volna, csak hiába kerestem, sehol nem találtam multimédia repókat hozzá. még mp3-at sem volt hajlandó lejátszani. Plusz idegesített, hogy nem tudtam kikapcsolni a gépet. (Errort dobott hogy nem tud olvasni vmilyen fájlt.) Linuxokon már gond nélkül kiismerem magam, de az opensolaris annyira basic telepítést rakott csak fel, hogy kezdőként (és főleg nem informatikusként) nem tudtam konfigurálni...

( bazso | 2009. 04. 14., k – 08:47 )

És iszonyú egységes. Egy vadidegen gép elé le tudok ülni támogatóként, és nem kell felhívnom azt aki telepítette. Nem áll neki széthekkelni a linuxguru rencergizda (bár az opensolaris és a gnome felület óta van aki megörül hogy a szerver grafikus felülettel akár desktop is lehetne, és megpróbál belehekkelni ezt-azt :-(
Az smf tényleg elmegy anyjába, bár értem hogy miért kellett ezt így, és a működése tetszik, de
1. Nem vagyok gép, nekem gáz xml-t olvasni és írni, configparser meg annyi van mint állat, miért nem lehetett azt használni?
2. Miért nincs gyári doksi arról, hogy ha elpusztul és cd-ről boot-olok hogy lesz nekem svm-em, vagy hogy tudok servic-eket kapcsolgatni, elemezni?

Üdv,
BaZso

1) Nem tul nehez az XML-t olvasni azert, ha jol formazott. Es szerintem inkabb kevesebbszer mint tobbszor kerul az ember XML-kozelbe
2) Mert az Open resze szvsz alapvetoen meg mindig ujnak szamit, igy meg nem irtak meg minden doksit hozza. A support biztos tudja ;-)
-- 


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

( kr304 | 2009. 04. 14., k – 22:07 )

Hogyhogy senki sem említi a least privileges (LP) újítást?

( praetor | 2009. 04. 20., h – 03:27 )

Eloszor is a perspektivam: fejleszto vagyok, nativ, es Java alkalmazasokat fejlesztek, amelyek az interneten jelennek meg kulonbozo (jellemzoen nem WEB) formaban. A cegnel ahol dolgozok elottem FreeBSDket hasznaltak, az en tenykedesem eredmenye, hogy egyre tobb a Solaris rendszerunk. Ezeket en terveztem es konfiguraltam, alapveto rendszergazdai tevekenysegeket is ellatok, de erre van egy kulon munkatars is, igy a Solaris ezen aspektusarol keveset tudok elmondani.

Akkor az eddig erintett temakrol szepen sorban:

SMF: nekem nagyon tetszik, sztem kenyelmes dolog az XML alapu konfiguracio. A szolgaltatasok jellegukbol adodoan nagyresz deklarativak (fusson ez meg az, ilyen juzerkent fusson, letezzen ez meg az a file, stb.), es emiatt az XML leirot sokkal jobb megoldasnak tartom mint az init scripteket. Az SMF megbizhatoan kezeli a fuggosegeket, amit en orrba szajba ki is hasznalok, leven az alkalmazasunk szepen retegzett, es igy nehany szolgaltatas osszeomlasat jol tudja kezelni a rendszer. emellett kenyelemes dolog hogy gyujti a STD outputot es az errort minden processztol, illetve hogy az adott szolgaltatas nem trivialis fuggosegeit is szepen validalni tudom vele.
Ha valakinek ez tul sok, akkor ott a SysV init, illetve ha valakinek az is tul bonyolult akkor ott a pkill...

ZFS: kellemes filerendszer, tetszik a viszonylag gyors es olcso snapshot kepessege, es a sok checksum. ha olcso SATA lemezekbol epitunk tarolot, akkor kifejezetten jol jon, a pletykak szerint (silent corruption) SCSI+RAID konfiguracioknal is jol jon. En nem futtattam ilyen tesztet, nem tudom mennyire valos ez a problema, jobb felni, mint megijedni.

Containers/Zones: Alapvetoen ugyan az, mint a BSD Jailek, vagy a Linux Vserverek. A FBSD Jailekhez kepest trivialisan lehet konfiguralni es installalni oket, kenylemesen lehet korlatozni az eroforrasaikat is(FBSD resource controlrol en pl. egyaltalan nem tudok). A Vserverekhez nem volt szemelyesen szerencsem, amennyire en tudom a konfiguracio nem olyan trivialis mint a Zonaknal, bar lehet hogy van olyan disztro ami nyujt a Solarishoz hasonloan mely integraciot, es ezzel egyutt egyszeru hasznalatot. Resource control teren valoszinuleg a Vserver is tud mindent amit a Zonak, esetleg kicsit nehezebben.
Zonakkal kapcsolatban erdemes megemliteni a "branded" zonakat, jelenleg ketto ilyen van: az egyik Solaris 8 kernelt, a masik egy 2.4es Linux kernelt emulal; elobbibe fully flagged solaris 8at, utobbiba tetszoleges Linux 2.4es kernelt tamogato disztribuciot lehet telepiteni. Egyik esetben sem beszelhetunk mar az egyszeru konfiguraciorol, bar a resource control tovabbra is ugyan olyan jol mukodik. A Solaris 8 zona erdekessege, hogy Solaris 8 drivereket is be tud tolteni, ami arra enged kovetkeztetni, hogy a Solaris kernel architekturalisan kristaly tiszta, a Linux 2.4 zona ilyet nem tud. Egyiket sem hasznaltam elesben.
Szinten kellemes feature a live update, ami leklonozza a globalis zonat egy masik zonaba, bebootolja, majd ott telepitgethetem a frissiteseket, es tesztelhetem a rendszert. ha minden mukodik, akkor egy reboot, es atall az egesz rendszer az updatelt OSre.

Package management Solaris 10 alatt: Ez gyakorlatilag egy az egyben a Sys V Unix package management megspekelve a Solaris patch rendszerrel. Hat nyugodtan nevezhetjuk egy rakas szarnak ahhoz kepest amit egy-egy linux disztro felvonultat, ha sokat kell telepitgetnunk/frissitenunk akkor ezzel bizony izzadni fogunk.
Package management Open Solaris alatt: Kitalaltak, hogy kell nekik valami olyan mint az APT, de nem az APT, hanem majd csinalnak egy _jobbat_. En ennek csak egy korai valtozatat probalgattam, zero megelegedessel. Azota sem tudom hogy miert nem kezdtek el csak siman az APTt hasznalni. Allitolag az ujabb verziok mar egeszen hasznalhatok, de belolem tovabbra is csak a WTF erzest valtja ki az egesz rendszer.

Userland Solaris 10 alatt: Ha egy linux disztro userlandje a jelenkor, akkor a default Solaris 10 userland a kozepkor, es csak viszonyitaskepp a FBSD nagyjabol a kokorszak. Kedvenc GNU utiljaink egy resze alapbol a rendszer resze (csak nem a /usr/bin/ -ben), a maradek telepitese kb 10 percet vesz igenybe.
Userland Open Solaris alatt: A szines szagos GNU utilok elore telepitve erkeznek, de ha ragaszkodunk hozza a kozepkori dolgok is elerhetoek meg.

DTrace: Ez a tool onmagaban egy akkora fegyverteny, hogy csak ezert is hajlando lennek Solarist hasznalni. Nezegettem mar osszefoglalokat a DTracerol, de igazabol epp az az egy dolog nem jon at ezekbol ami a DTrace erossege: hogy abszolut mindenre jo. Ha van egy profilered meg tudod mutatni, hogy milyen szep grafikonokat rajzol. Ha van egy uj webszervered megmutatod milyen gyorsan szolgalja ki a klienseket. Ha van egy uj toolod amely felhasznaloi felulete egy parancssori alkalmazas, es problemamegoldasra talaltak ki, baj van: ha eleg trivialis a problema hogy 1 perc alatt felvazold akkor massal is meg tudod oldani, ha nem, akkor meg nem erdemes elmondani. Ennek a toolnak az erejet egyszeruen nem lehet megerezni amig nem szembesulsz a kerdessel, hogy miert nem bir csak 60 queryt kiszolgalni a harom hoston 10 processzben futo alkalmazasod a szukseges 100 helyett.

Least Privilege system: Ez leginkabb akkor mukodik jol, ha az alkalmazasok hasznaljak, de reszben enelkul is ki tudjuk hasznalni. A mi service tier gepeinken olyan apache processzek varjak a kapcsolatokat a 80as porton, majd dobaljak szet az application tierek fele amik mar _semennyire_ nem tudjak elerni a filerendszert(semmi open/mmap/fcntl), nem tudnak forkolni, nem tudnak exec*-elni. Nem vagyok security guru, de amennyire en tudom ezzel a puffer tulcsordulasos tamadasok donto tobbseget kivedtuk nagyjabol fel oranyi konfiguracioval.

Trusted extensions: Ez inkabb csak marketing mint valodi huzoero(bar pl a Least Privilege system innen szivargott le a core Solarisba). Egy trusted extensions-el kemenyitett rendszert mar nem lehet unixnak nevezni. Ennek az volt a celja, hogy a Solaris 7 megszerezzen valami bizonyitvanyt, hogy ezzel lehet raketasilokat vezerelni, es erre tokeletes is. Az persze mas kerdes, hogy erre a biztonsagra ritkan van szuksegunk, a procedure szerinti validacio evekig tart, akarmilyen szoftverek fejlesztei koltsege legalabb a tizszeresere emelkedik, ha _tenyleg_ ki akarjuk hasznalni a trusted extensionst, amihez raadasul nagyon kevesen ertenek (nincs open knowhow a google-on). Persze ha otthon keszit valaki ballisztikus raketat es nem akarja hogy az asszonypajti ki tudja loni azert jol johet.

Konfiguracio: A Solaris 10 alapbol teljesen konfiguralhato NISbol. NISt persze senki nem hasznal, vagy OpenLDAP-ot NIS modullal (es ekkor NISen keresztul beszelgetnek a szerverek az OpenLDAP-al), vagy kis heggesztes utan az OS is tud LDAPpal beszelgetni NIS modul nelkul. Ez egy olyan feature amit nem igazan fog az ember ertekelni amig nincs 40 szervere amire vigyazni kell, de ha mar van, akkor sokat segit. Ugyanakkor tavolrol sem egyedi feature ez a unix vilagban. A Solaris tavoli management tulmutat azon, hogy Van rajta SSHD, be tudsz jelentkezni tavolrol, meg hogy van Nagios, szep GUIs remote management alkalmazassal lehet monitorozni, es kezelni tobb 100 hostot egyszerre konzolos bejelentkezes nelkul. Ha nem 2 geped van, akkor ez eleg sokat segit ha reggel egy ablakban var a report, ami 40 gep aggregalt logjaibol kigyujti az errorokat, warningokat. Persze van a Nagioshoz is web-felulet, de megiscsak kenyelmesebb, ha ez egy turnkey rendszer minden friss installon.

Dokumentacio: Ha valamire szuksegem van, eloszor a docs.sun.com-on keresek, es utana jon csak a Google, de a 2. lepesre az esetek donto tobbsegeben nincs mar szukseg. Rendkivul jol dokumentalt rendszer, tele gyakorlati peldakkal. A linux disztrok atvehetnek... Minden releasehez jon nagyjabol 10 000 - 15 000 oldalnyi PDF doksi, amiben _minden_ benne van. En a Linux vilagbol erkeztem Solarisra, a DTrace mellett a dokumentacio puszta lete a masik fegyverteny ami miatt erosen ezt a rendszert preferalom. A karbantartott dokumentacio a Solaris releasekre(minden feleves updatere is!) vonatkozik, az Open Solaris nem igazan definialt release-ei nem kapnak ilyen atfogo es konzisztens doksit.

Reverse compatibility: Errol annyit tudnek mondani, hogy letezik :-) Futtattam Solaris 6ra forditott OpenGLos alkalmazast Solaris 10en, es ha valamiert megis torne a mecses (amire a LP system miatt sor kerul neha) akkor ott a Solaris 8 Branded zone. Ezt a Sun komolyan veszi, es remelem meg is tartjak jo szokasukat.

SW ellatottsag: Van a sunnak nehany hivatalos binaris csomagja gyakran hasznalt open source toolokhoz, mint GCC, Python, hasonlok. Ha itt nem talaljuk meg ami kell, akkor van ket eleg nagy ingyenes package repository kenyelmes letoltogetos package manager frontenddel. Ha ez sem mukodik, akkor forrasbol nagyjabol minden lefordithato, egyetlen program amit szivesen hasznalnek de tudom, hogy nem mukodik a Valgrind :-(

GUI: Fut rajta Xorg(meg minden sutemeny WM/DE, Flash(kopjetek le, de en szeretek youtubeolni)), vannak hozza jo nvidia driverek, meg hasznalhato intellel is, jonak nem mondanam. A Xorgot evek ota linuxra reszelik, es egyszeruen nem tokeletes Solaris alatt, egy igen combos gepen is latom neha ahogy rajzolgatja az ablakaimat. Ha X terminal kell, akkor inkabb valami mas, a Solaris egyszeruen nem egy kompetitiv Desktop OS, barmit is halandzsazik a Sun.

Hat azt hiszem ennyi, meg egyszer, ez egy szubjektiv maganvelemeny egy Solarist hasznalo fejlesztotol.

Az xml szerintem igencsak távol áll a "szintaktikus cukor" mentalitástól szerintem -- rettenetesen sok benne a strukturális ballaszt, amit ugyan egy xml-szerkesztő elrejt(het), de vi-ban azért eléggé randán mutat :)

A függőségek outputok kezelése és hasonlók jó dolgok, de arra már elég régen ott van a daemontools, a respawn az inittab-ban és hasonlók...

Hat igen, ha valamilyen oknal fogva VI-al kellene szerkesztenem syntax highlight nelkul az eleg kellemetlen volna, en VIM-t hasznalok.

Es persze, eddig is lehetett fuggosegeket kezelni ha az ember akart, az SMF nem vilagmegvalto ujdonsag ami uj tavlatokat nyit az emberiseg elott, csak kenyelmes es egyszeru :-)

+1
Ha egy szolgaltatas cucca jol meg lett irogatva, akkor utana nem kell azt napi szinten piszkalni. Egyszer-egyszer meg ki lehet birni az xml-t. Erdekes, a tomcat is xml alapu konfigokkal dolgozik, megse roja fel neki soha senki, pedig hat az xml ugye allitolag shit. Illetve van meg egy kazal dolog, ami xml, vagy xml-szeru konfigokat hasznal. Ez van, egyutt kell tudni veluk elni. Viszont persze semmit nem kotelezo hasznalni, gentoo-n peldaul viszonylag nem bonyolult az init script rendszer, szolgaltatasok kozti fuggeseket kezel, megsem sokkal tobb, mint egy bash script (illetve tobb, de nem konkretan a nyelv az. amiben tobb).
-- 


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

> Az SMF megbizhatoan kezeli a fuggosegeket, amit en orrba szajba ki is hasznalok,

Csak erre reagalnek: szervizek fuggosegkezeleset a FreeBSD-s rcNG nevu keretrendszer (from NetBSD, ha jol emlekszem) szinten kezeli, sztem legalabb 5 eve. Persze azt is meg kell erteni, hasonloan, mint az SMF-et - amit Zellerhez hasonloan nekem sem sikerult nagyon megszeretni. (DTrace es ZFS is van FreeBSD-n is, mindenki tudja, hogy nem olyan allapotban - nyilvanvaloan.)

Ja es igen, (nagyon sokkal) inkabb vi, mint xml .

Hat akkor szepen sorban.

A szolgaltatasok leirasa 98%ban deklarativ jellegu informacio:
* milyen userkent fusson
* milyen privilegiumokkal fusson
* milyen szolgaltatasokra epul
* a futtatashoz milyen fileok meglete szukseges
* ...
Ezeket az informaciokat kell valahogy rogziteni. Egy tetszoleges shell scriptekkel felturbozott init rendszerben szerencses esetben erre vannak eljarasok, SMFben ezeket szepen egy XMLbe irogatod bele. Elobbi megoldas tobb sebbol verzik: ha szerkeszted az init scriptet konnyen hibat vethetsz, ketszer allithatsz be valamit, esetleg inkonzisztensen, nehez atlatni hogy mit hol allitasz be. Ezen felul altalanos rule of thumb programozoknal, hogy amit lehet deklaraljunk, ne programatikusan oldjunk meg(funkcionalis nyelvek...) ez az elmeleti ok ami miatt az SMFet tartom jobb megoldasnak.
Masfelol egy service rendszer lete tobb elonyt hordoz magaban: tudja gyujteni a kulonbozo processzek std out es error kimeneteit, ami meglehetosen hasznos, ha sajat alkalmazasokkal dolgozik az ember, amik nem loggolnak tokeletesen. Tovabbi elony, hogy osszetett diagnosztikai informaciot tud adni: ha azt latod, hogy 20 szolgaltatas nem fut, akkor nem neked kell elkezdeni logot olvasni, hogy na melyik nem fut, hanem egy paranccsal le tudod kerdezni oket, es ezek kozul melyek amelyek osszeomlottak, es melyek amelyek elegtelen fuggosegek miatt allnak. Szinten konfiguralhato hogyan inditsa ujra a szolgaltatast ha osszeomlik (sehogy, azonnal, maximum 3x, 30mp kesleltetessel, stb...), osszeomlas kezelo eljarassal... ezek mind olyan dolgok amiket nem nekem kell megirni.
Utolso kedvenc SMF featureom hogy meg tudok adni statikus fuggosegeket a szolgaltatasokhoz (pl. hogy mely fileoknak kell letezniuk, hogy esetleg validalja a konfig filet mielott elinditja a szolgaltatast, hasonlok).
Az en gepeimen az SSH tunnelek is servicek, es az azokat hasznalo szolgaltatasok kulon kulon indulnak el, ha a tunnel felallt, es a szolgaltatasok a kulonbozo NFS mountokat is ellenorzik.
Persze persze ezek mind olyan dolgok, amiket egy init script(akar ngRC vagy mas) is meg tud csinalni, ha valaki megirja a gyonyoru 1000 soros initeket. eltolt vele 2 napot, es akkor is egy bughalmaz marad.
Ezek azok a featureok amik megkulonboztetnek egy nagyjabol 1 millio soros C alkalmazast (SMF) egy 80 bourne shell eljarasbol allo eljarasgyujtemenytol (ngRC).

u.i. Nem, az ngRC nem szar, es akinek az tetszik az nem hulye. Mindossze szerintem ezek a dolgok amik miatt az SMF jobb.

hopsz, elfelejtettem: a Solarisnak ketszintu (masneven N-M) thread implementacioja van, aminek a lenyege, hogy a kernel level threadek el vannak valasztva az user level threadektol. Ez azert jo, mert az user level threadek, ha normal mutexen blokkolnak (es nem IOn a kernelben) safety mode task switching nelkul tudnak valtani a processzorokon, ami jelentosen gyorsabb, mint amit a linux vagy a windows kernel nyujt. Jo kis feature masszivan multithread alkalmazasok fejlesztesekor, mert olcso a mutex lock :-) Persze lehetoseg van az user level threadeket kernel level threadhez kotni ha akarjuk, de ennek altalaban nem sok ertelme van.
talan ennyi.

( strangelove | 2009. 04. 21., k – 06:31 )

Hali!

Mert van milax.org (mini-)live disztró. cca 200MB
Ezt még használom is, több-kevesebb rendszerességgel; nemcsak járókelők arcába küldök vele jeleket a 150 millió km-re lévő optikai gerinchálózatról. (Az is sun...)

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

( pink v | 2009. 06. 06., szo – 11:53 )

illetve a default shell bash, meglepetesemben kis tulzassal a terdemen tortem kette a cd-t

- Fura. A solaris-guru kollégáimnak első dolga, hogy login után bash-t indítanak. Pedig nem buta gyerekek, és még csak a linuxos múltra sem lehet fogni az ő esetükben.