Archief - Opensolaris

Heeft er iemand al eens met OpenSolaris gespeeld? Solaris is het OS waar oa. gsm operatoren gebruik van maken omdat het zo stabiel is...
Maar het dient niet alleen als server, maar ook als desktop.

(En het bestaat al 10 jaar langer dan de linux kernel en het is échte unix, geen kloon)

En het is blijkbaar ook opensource...
Ik ben het al aan het downloaden in ieder geval.

gebruikt de Sun Java Desktop dus hoe is het met de snelheid?

Zo ver ben ik nog niet
Maar draait java niet native op solaris? Zonder virtual machine?
Als het niet meer moet worden geïnterpreteerd door een ander programma buiten de kernel, gaat dat wel wat sneller draaien denk ik...

Java draait bij mijn weten steeds via een Virtual Machine - ook op Solaris dus (ttz, je hebt wel native Java compilers en JIT uiteraard).

Maar 'k heb OpenSolaris nog niet getest, als Solaris x86 onder Xen kan draaien zou ik 't wel eens durven proberen.

Om even mijn persoonlijke frustraties met Solaris en Java hier te lozen

- (Open)Solaris komt imho by default met gnome en Sun Java Desktop als optie, hoewel ik er geen idee van heb hoe die desktop er uit ziet (wij hangen daar geen schermen aan).

- Java moet nog steeds onder een JVM draaien unless het native compiled is, maar de code die een een doordeweekse Java developer schrijft (bij ons toch) is niet zomaar even native compileerbaar.

- Hoe ge het ook keert, Solaris en/of Java is en blijft oertraag, en het word enkel maar erger als ge het op Sparc64 runned (zelf een V440 (het rechtse model op hun site) is imho zijn geld niet eens waard).

- Het bestaat inderdaad al VEEL langer dan 10 jaar, maar ze zijn daar persies nog steeds blijven steken ... voor mij heeft het dus NIKS te bieden, en zeker als desktop niet. (ok, ze hebben eindelijk een -h switch bij df !)

Er is btw al een fork van OpenSolaris (shillix) die wel te compilen valt met een open compiler etc.

Merk op dat Solaris en Opensolaris echt wel eerder op de servermarkt toegespitst is dan op de desktopmarkt. Sun heeft ook een desktop-editie, maar dat is eigenlijk een refurbished Suse. Bottom line, probeer opensolaris niet als desktop, je gaat vermoedelijk niet tevreden zijn, en een verkeerde indruk hebben.

Het eeuwige argument dat Java traag is, en dat de JVM crap is, is echt wel achterhaald. Indien goed geinstalleerd, op een machine met genoeg geheugen, is java niet trager of sneller dan een ander programma.

@sick`, je onvrede van solaris en je indruk dat het oertraag is en in 1995 is blijven steken vind ik ongegrond; ik zou wel eens willen weten waarop je dat basseerd. Een V440 is best wel een degelijke machine, en sparc64+solaris is nog altijd rock-solid te noemen.

bash-3.00# prtconf | grep Mem
Memory size: 8192 Megabytes

bash-3.00# prtfru |grep _CPU_
/ManR/Fru_Shortname: A42_CPU_1.064GHZ
/ManR/Fru_Shortname: A42_CPU_1.064GHZ
/ManR/Fru_Shortname: A42_CPU_1.064GHZ
/ManR/Fru_Shortname: A42_CPU_1.064GHZ

En nog vind ik het traag, de integer performance is zelf om te schreeuwen.
De Niagara zou veelbelovender zijn, maar om de prijs van een wagen neer
te tellen voor een machine die amper sneller kan decrypten dan mijn
desktop ... nee dank u.

De reden waarom deze machines gebruikt worden is omdat Solaris tot hiertoe (buiten Solaris 10) backward compatible bleven. En omdat de hardware zeer eenvoudig in een ontwikkel omgeving te gebruiken is (LOM, ALOM, Serial Console) en te jumpstarten valt, enja, onze omgeving nu gewoonweg helemaal rond Solaris draaid en er op voorzien is. Plus dan nog eens voor Oracle RAQ support etc. En het support contract natuurlijk, hoewel ik het erg vind dat bvb een V210 maar een jaar support had by default en dan plots een voeding het begeeft.

*edit*

En 128MB voor een simpel java process is een beetje teveel van het goede, hier draaien er van 800MB met een eenvoudige functionaliteit. Ik vind het om te schreeuwen als ik zie dat een bepaald product zelf niet eens meer op een ultra 10 te starten valt (voor enkel een domme test op te doen. eg: surfen via een proxy).

Als je number crunching wil doen (integer performance), dan moet je inderdaad andere CPU's nemen (en dus een andere machine ). Verder is er weinig op te merken over IO, scheduling, tuning die je kan doen...

De support contracten die verlopen liggen volledig in je eigen handen, Sun heeft mogelijkheden om support te krijgen op stokoude machines, en jaren aan een stuk (okee, het wordt dan wel vrij duur, maar ...). En dit probleem is niet sun/solaris-gebonden hé.

Een simpele applicatie die 800MB (zelfs in java) inneemt, is slecht geschreven, of is geen simpele applicatie. Verder moet je erop letten dat meerdere JVM's vrij veel libs delen, en dat je dus moet kijken naar de eigen memory footprint, en niet naar de gehele.

Als ik me niet vergis is de ultra 10 een machine van '95. Ik weet niet wat je erop wil testen, maar deze zou toch nog vrij veel moeten kunnen.

Ik moet echter ook wel zeggen dat ik niet fanatiek voorstander ben van Solaris. Maar voor server-applicaties en stabiliteit is het enorm prachtig en stabiel. Desktop en zo is echter minder aan te raden...

Mwa, zelf voor een RISC is er een wereld van verschil tussen een PA-RISC 2.0 en een UltraSparc-IIi/e. Met simpel verwijs ik eerder naar niet complex (een mobile proxy/gateway met wat caching en verschillende componenten en een boel CORBA en RMI rommel), ik ben nu geen Java developer, maar ik kan er ook met men kop niet bij waarom dat zoveel geheugen nodig heeft. Een ander project heeft zelf een embedded toestel met 1 Java toepassing dat met de volle 128MB ram van het toestel ging lopen. Het zal zeker niet zoveel geheugen MOETEN hebben, tenzij het deftig zal moeten draaien (voor availability en persistentie dan). Wat ik maar wil zeggen is dat dit allemaal beter in C of Perl tot zen recht was gekomen en ik zo op dit moment nog steeds op een ultra 10 simpele testen kon uitvoeren (een website bezoeken of een CLI commando oproepen die even zen eigen JVM opstart is blijkbaar teveel gevraagd). Wat mij dwars zit is dat het op zoveel manieren beter zou kunnen worden gemaakt, maar de combinatie van alle component zeer hard tegen steekt (hardware + os + jvm) .. van stabiliteit kan ik niet klagen, hoewel ik /tmp in memory filesystem als default absoluut geen goed idee vind. Ik wil hier geen Java/Solaris/Sparc flame ofzo starten, maar en zijn zeker en vast voor alle drie de componenten beter methoden om een product op de markt te brengen. En dat mijn Java gedreven gsm zo traag is en om de 2 maand crashed stelt mij nog meer teleur in die technologie ... waar is de tijd van ASM en C?

De tijd van pure C en optimalisaties in Assembler ligt ver achter ons (tenzij je video drivers ontwikkelt lijkt me ). Gelukkig, want ik denk dat, als er enkel maar C/ASM zou zijn, dat we bijlange niet zouden staan waar we nu staan. Dat alles niet 100% is zoals het zou moeten, en dat er veel verbeteringen mogelijk zijn (niet enkel aan Solaris/Java...) ga ik echter niet ontkennen.

Merk op dat je "simpele" applicatie ook met het oog op threading en zo moet geschreven zijn, een enkele loop zal nooit sneller lopen op een multiproc machine, dan een single proc. Goede applicaties bestaan maar als het OS, de machine en de software een beetje op elkaar afgestemd zijn...

Voor zware en belaste servers, die veel en lang online moeten zijn, zou ik nog eerder zweren bij een Solaris/sun dan bij een Linux/Dell (of, god forbid, Win32/whatever).

Maar genoeg hierover... de thread ging over Opensolaris en dat eens testen... Mijn antwoord is: test het wat je wil, maar denk eraan voor welke machines en welke applicaties het geschreven is. High end machines, high end toepassingen, high availability (en dus niet Desktop ), en backwards compat...

Het is moeilijk om mij bij deze ######## kalm te houden (buiten het fijt van die threading dan, maar daar word ook hevig gebruik van gemaakt), maar ik ga het toch doen om de topic van deze persoon met zijn beste bedoelingen niet te verzieken...