Sun heeft 64-bit Solaris-kernel draaiend op Opteron

Zoals hier al werd aangekondigd is Sun bezig met een versie van Solaris voor de Opteron. Inmiddels hebben de specialisten van het bedrijf een 64-bits kernel draaiend op deze processor. Dit is een belangrijke stap voorwaarts voor Sun, dat een grote rol ziet weggelegd voor Solaris op het x86 platform. De kernel draaide tijdens de tests niet alleen, het was mogelijk om in te loggen, programma's te starten en gebruik te maken van het netwerk. Er is echter nog genoeg te doen: een grafische schil is nog niet aanwezig en het is ook nog niet mogelijk om Java-programma's te draaien. Remote is het wel mogelijk om grafische programma's op te starten.

Het ontbreken van een X-Windows-systeem is te wijten aan het feit dat er nog geen 64-bits drivers beschikbaar zijn. Het project ligt nog op schema, in december van dit jaar wil men Solaris 10 volledig beschikbaar hebben voor de Opteron-processor. De verwachting is dat Sun meer informatie zal prijsgeven bij de officiële lancering van Solaris 10 op 17 augustus van dit jaar. Het besturingssysteem zal in werkelijkheid echter pas begin 2005 voor het grote publiek beschikbaar zijn.

Reacties (37)

[silentsnake]

Maar wat is hier het nut nou precies van? Ik bedoel, ik begrijp heus wel dat Sun brood ziet in de x86 markt, maar er zijn al tig Unix varianten ondertussen die op x86 draaien. Sun moet dan wel met iets vernieuwends komen om het echt tot een success te brengen.

Er is echter nog genoeg te doen: een grafische schil is nog niet aanwezig en het is ook nog niet mogelijk om Java programma's te draaien. Remote is het wel mogelijk om grafische programma's op te starten.

En dit is precies waar ze de mist in gaan denk ik.

Ten eerste: wie wil er nou een grafische schil op een productie server? Dat vreet toch alleen maar onnodig veel RAM? Je laat een productie server wel door een specialist beheren, en niet door een thuis-gebruiker (dus iemand die comfortabel is met de console)

Ten tweede: Als ik het goed begrijp willen ze dus standaard java gaan leveren met het OS. Slechte, slechte zet. Er zijn genoeg mensen die java geen prettig platform vinden, dus waarschijnlijk zullen ze dan ook niet voor dit OS kiezen als het daadwerkelijk geintegreerd wordt in het OS.

Ten derde: Tis leuk en aardig dat je remote grafische programma's kan starten, maar op een productie server zet je normaal gesproken geen grafische omgeving, dus is deze "feature" vrij nutteloos.

Kortom, de fout die Sun maakt na mijn mening is dat ze te veel op de grafische kant richten. Het is leuk voor een workstation (kijk naar java desktop), maar op een productie server is het zeer zeker onverstandig naar mijn mening.

[Verwijderd]

Je hebt duidelijk weinig ervaring met servers en de verschillende zaken waarvoor een server gebruikt wordt, maar goed.

Punt 1: Een grafische schil kost vrijwel geen performance en resources als die niet gebruikt wordt. En waarom een "expert" zo nodig met een command line moet werken is voor mij ook een raadsel. Een grafische installatie programma kan er voor zorgen dat er minder fouten gemaakt worden en een programma dus sneller (lees: goedkoper) geinstalleerd kan worden. Een "expert" gebruikt alle tools die beschikbaar zijn en niet alleen maar de tools die cool zijn.

Punt 2: Java. Een bekende toepassing van servers is de Applicatieserver. Hier heeft een bedrijf verschillende opties. Gebruik een in house systeem van een bepaalde fabrikant. Gebruik .net (voor bepaalde toepassingen) of gebruik een java applicatieserver zoals Weblogic, JBoss, BAS enz.
Java is voor een groot deel van de Sun klanten een "must have". Qua performance is ook java goed genoeg voor een hoop taken. Dus een Sun server zonder java: kansloos.

Punt 3: Het starten van remote grafische shells in nutteloos. Tuurlijk jongen. Vandaar dat MS een product als Terminal Server heeft, Citrix nog steeds bestaat, programma's als PC Anywhere goede verkoop cijfers halen enz. Dat deze functie al sinds voor de oertijd in Unix is ingebakken vergeten we ook maar even.

Kortom. Een server is meer dan alleen maar een plaats waar je bestanden parkeert. Voor een hoop van deze taken heb je gewoon bepaalde zaken nodig en een server waarop die basisgereedschappen niet beschikbaar zijn is geen server. Dat is een opvulling van je magazijn. Verkopen zal je hem namelijk niet.

[packman]

1) Ga ik niet mee akkoord. Een grafische install minder marge voor fouten? 1 keer een server geinstalld is wordt die niet meer aangeraakt, enkel automatische security-updates die gedistribute worden door een centraal-beheer systeem. Leuk hoor zo'n grafische install, maar probeer maar eens op een klein serverparkje - van al is het maar 30 servers eens overal alle software op te installeren? Have fun... Text-oriented is dit perfect automatiseerbaar (op *nix systemen toch) - en een text-based installer kan nog altijd dezelfde functionaliteit hebben als een "grafische" installer, alleen zal je geen superbelangrijke bitmapjes te zien krijgen...

2) Er staat duidelijk dat er NOG geen java-support is.. Tegen de release verwacht ik wel dat die er zal zijn

3) Remote starten van grafische shells is nutteloos op database en file servers, maar er zijn nog wel andere types server. Wij draaien hier een development server waar wel degelijk remote X kan gerunt worden (en ook effectief veel gedaan bij wordt) Nutteloos? Zeker niet.

[Zer0]

Ten eerste: wie wil er nou een grafische schil op een productie server? Dat vreet toch alleen maar onnodig veel RAM? Je laat een productie server wel door een specialist beheren, en niet door een thuis-gebruiker (dus iemand die comfortabel is met de console)

Solaris is niet alleen beperkt tot servers, maar is ook bedoeld voor workstations, waar je wel degelijk een grafische omgeving wil hebben.

Ten tweede: Als ik het goed begrijp willen ze dus standaard java gaan leveren met het OS. Slechte, slechte zet. Er zijn genoeg mensen die java geen prettig platform vinden, dus waarschijnlijk zullen ze dan ook niet voor dit OS kiezen als het daadwerkelijk geintegreerd wordt in het OS.

SUN = java (ongeveer) En er zijn genoeg mensen die java wel waarderen.

Ten derde: Tis leuk en aardig dat je remote grafische programma's kan starten, maar op een productie server zet je normaal gesproken geen grafische omgeving, dus is deze "feature" vrij nutteloos.

Wel eens van het fenomeen terminal server gehoord? Eigenlijk de oorsprong van *nix, een server waarop de applicaties draaien, en de (grafische) uitvoer op een "domme" terminal, een opzet die weer erg in trek is.

[basb]

Oracle gebruikt graag de grafische schil om mee te installeren.

Dus tja dan moet je een grafische schil op je server hebben.

Op afstand is grafische omgeving erg handig, alle clients draaien ook met de grafische omgeving vanaf 1 machine.

[warp]

Oracle gebruikt graag de grafische schil om mee te installeren.

Dus tja dan moet je een grafische schil op je server hebben.

Eh, sorry hoor, maar Oracle is ook prima vanaf de commandline te installeren, dus grafische meuk op je server heb je echt niet nodig (tenzij je zo'n point&click admin bent)

[Verwijderd]

Ten eerste: wie wil er nou een grafische schil op een productie server?

Waarschijnlijk willen ze solaris ook kunnen gebruiken als workstation?

Ten tweede: Als ik het goed begrijp willen ze dus standaard java gaan leveren met het OS.

Mja, Java is nu eenmaal van Sun, dus je kan ze geen ongelijk geven hun product wat te promoten. En je bent natuurlijk niet verplicht het te gebruiken.

Ten derde: Tis leuk en aardig dat je remote grafische programma's kan starten, maar op een productie server zet je normaal gesproken geen grafische omgeving

Kan altijd handig zijn voor mensen die wel liever gebruik maken van een grafische interface. Op die manier kan ook iemand die geen/weinig kennis heeft van de cli inloggen op de server en wat standaard setup werk verrichten. En de X-Server maakt nu eenmaal gebruik van deze mogelijkheid, dus zonder dit geen lokale GUI

[warp]

En de X-Server maakt nu eenmaal gebruik van deze mogelijkheid, dus zonder dit geen lokale GUI

De lokale GUI van een werkstation gebruikt een lokale X server, niet die die van de server. De X binaries van de server worden re-directed naar de X server van je client.

Als je X apps vanaf de server wilt draaien op je eigen werkstation dan moet je toch echt lokaal een X server hebben draaien, die verzorgt nl. de scherm in- en output e.d.

Zie b.v. deze link hoe dat in zijn werk gaat.
http://fusion.gat.com/docview/display.html

Dus.. een X server op de server zelf is wel degelijk overbodig. Alleen de X apps/binaries/libs/etc. hoeven maar op de server te staan.

[Balkz]

Het voordeel van Unix systemen is juist dat de GUI niet in de Kernel zelf geïntegreerd is (wat bij bijvoorbeeld Windows wel het geval is). Dat verhaal van onnodig veel RAM hoeft dus niet persé waar te zijn, als je wilt kun je de GUI namelijk gewoon uitzetten.

Ik wil niet zeggen dat Solaris een fantastisch besturingssysteem is, maar het is zeker niet zo nutteloos als jij beweert, de mensen bij Sun hebben er zeker wel over nagedacht, neem dat nou maar aan.

[Verwijderd]

"neem dat maar aan"

net zoals een gui in een kernel, en dan nog zeker een kernel welke MS beweert Microkernel te zijn....

[zakalwe]

Sun wil gewoon dezelfde functionaliteit leveren als ze in hun andere Solaris producten doen (zowel voor x86-32 en Sparc 32/64). Niks raars aan dus.
En de installatie is natuurlijk vrij configureerbaar, dus als je geen grafische schil wilt...

[Semt-x]

hoe is het mogelijk dat je anno 2004 een grafische schil als overbodig ziet ? kijk om je heen er zijn nog maar enkele systemen zonder grafische schil, het over over grote merendeel is voorzien van een GUI.

Het geheugen wat het inbeslag neemt ( 128 meg? ) is zeker op een server te verwaarlozen en vormt op normale hardware geen bottleneck.

Je stelt je een beetje op als een *nix fundamentalist ( iemand die zich zonder rationele redenen bij zijn standpunt blijft ). een GUI is makkelijk ook voor techies. een plaatje zegt meer dan 1000 woorden. Zo werkt het ook op een server.

[Verwijderd]

Ik heb het nog nooit meegemaakt dat een grafische interface voor iemand met ervaring sneller te gebruiken was dan een console, voor zover het geen dingen zijn die met graphics te maken hebben (voor een DTP pakket is natuurlijk het wel fijn als het grafisch werkt). Dus tenzij jij mij daar een voorbeeld van kunt geven geloof ik het simpelweg niet.

Verder: overhead is overhead, en meer overhead betekent dat je voor dezelfde performance snellere en dus duurder hardware nodig hebt.

Ook zie ik niet in waarom "een plaatje meer zegt dan 1000 woorden" wanneer je bijvoorbeeld een mailserver aan het configureren bent. Wat voor informatie kan er volgens jou in deze context beter grafisch worden overgedragen dan textueel? Volgens mij totaal niets.

Tenslotte: alle niet-Windows systeembeheerders die ik ook maar zijdelings ken geven de voorkeur aan de console boven een GUI. Die is bovendien ook het meest universeel toegankelijk: zelfs via je PDA of smartphone zou je eventueel op een server in kunnen loggen om onderhoud te verrichten of een probleem op te lossen.

[MaVl]

Even een heel klein voorbeeldje:

Een database server met een hoop kolommen, er moet snel een extra regel met de hand ingevoerd worden, want het programma voor invoer werk niet door een foutje.
Wat is sneller?
Dubbelklikken op een venstertje in het programma van de databaseserver en 20 waarden in vakjes invullen, of een sql querry intypen met 20 waarden en rekening houden met quotes, komma's, haakjes en meer van die onzin?
Ik hou ook wel van cli's, maar venstertjes hebben ook hun waarde.

[Verwijderd]

Verder: overhead is overhead, en meer overhead betekent dat je voor dezelfde performance snellere en dus duurder hardware nodig hebt.

Is nu net het voordeel om te werken met een remote GUI; de server wordt enkel belast wanneer het programma aan het draaien is (een deel van het grafische werk wordt zelfs op de client verwerkt).

"een plaatje meer zegt dan 1000 woorden"

Voor mail... grafiekje van het verloop van de mail/virus/spam-traffic op maand/dag/uur-basis? Niet onmiddelijk het configureren van de mail, maar toch nauw verwant ermee, al was het maar om proactief te handelen...

[Verwijderd]

Allebei jullie voorbeelden vereisen geen echte GUI, maar kunnen ook in een textomgeving worden uitgevoerd, bijvoorbeeld met een ncurses interface.
Bovendien hoeft het verwerken van mail statistieken niet per definitie door de mailserver gedaan te worden.
En voor die personen die echt per sé met een GUI willen werken zie ik meer heil in een systeem als NDS of Active Directory dan in een configuratieprogramma dat op de server draait maar op een client wordt weergegeven.

[Verwijderd]

Je vraag was ook niet wat "enkel" in een gui kon voorgesteld worden... maar wat "beter" kon worden voorgesteld. En je moet nu toch toegeven dat een grafiekje toch wel net iets duidelijker is; al was het maar gewoon omdat er meer pixels beschikbaar zijn.

Het verwerken van statistieken hoeft inderdaad niet op de mailserver te gebeuren, maar zal hoogst waarschijnlijk wel op "een" server gebeuren Op een client is het niet zo evident omdat het soms toch wel gepaard kan gaan met een overvloed aan data, wat voor nogal wat traffic zal zorgen.

En wat het vereisen van een echte GUI betreft. Ik denk niet dat er software bestaat waar het echt onontbeerlijk is om ze grafisch te bedienen. Heb zelf enkele jaren met autocad gewerkt, en daarin is het toch echt sneller werken indien je de commando's uit het hoofd kent; alhoewel het met de combinatie gui/cli nog wat sneller werkt.

NDS/AD ... Nadeel ervan is dat je extra client software nodig hebt; bij een remote X omgeving is dit slechts waar bij enkele OS's Onder de meeste (zoniet alle?) unix versies wordt het standaard ondersteunt. Het client programma zelf moet dus beschikbaar zijn voor het OS dat de gui draait; en zoniet moet de interface/protocol naar de service toe beschikbaar zijn.

[packman]

Een database server met een hoop kolommen, er moet snel een extra regel met de hand ingevoerd worden, want het programma voor invoer werk niet door een foutje

Ten eerste - zo'n dingen doe je niet op de server maar op een client. En ten 2de - als je bij ons zoiets uithaalt op een productiesysteem sta je 5 mins later aan de deur. Het zou niet de eerste keer zijn dat door een ondoordachte manipulatie die volledig logisch en ok leek opeens een paar dingen helemaal de soep inliepen (gelukkig dan op testsystemen).

Het grote probleem van de point&click user interface is nog altijd dat je veel makkelijker vergissingen maakt. Effe op de verkeerde colom klikken, op "delete" klikken, ... Als je met zo'n database applicaties werkt dan heb je wel ergens in code de sql-statement staan om dit te doen, en dan moet je dit maar effe eruit halen - en zo uitvoeren, zodat je zeker bent dat het exact is gebeurd zoals de applicatie(s) dit verwacht(en).

[Verwijderd]

hoe is het mogelijk dat je anno 2004 een grafische schil als overbodig ziet ? kijk om je heen er zijn nog maar enkele systemen zonder grafische schil, het over over grote merendeel is voorzien van een GUI.

Ga je kijken naar een groot deel van de servers (mainframes, mid-range e.d) draaien die GUI loos.
Ga je kijken naar de backbones van het internet draaien die GUI loos.
een grafische interface is enkel voor workstation varianten van dit OS.
Voor zover ik weet is Windows het enige OS waarbij je de GUI NIET uit kan zetten. De overige 1500 (schatting) verschillende OS's (incl. Gnu/Linux varianten) hebben wel die optie.

Het geheugen wat het inbeslag neemt ( 128 meg? ) is zeker op een server te verwaarlozen en vormt op normale hardware geen bottleneck.

Ram is vaak niet de bottleneck, veiligheid daarin tegen wel. een X server draait default op poort 6000 (uit me hoofd, correct me if Im wrong) en kan met gebrek aan beveiliging gemakkelijk naar buiten broodkasten. Iemand die het niet geheel snapt loopt het risico deze poort niet dicht te smijten waardoor de machine zelfs door een teletubbie geroot kan worden.

Je stelt je een beetje op als een *nix fundamentalist ( iemand die zich zonder rationele redenen bij zijn standpunt blijft ). een GUI is makkelijk ook voor techies. een plaatje zegt meer dan 1000 woorden. Zo werkt het ook op een server

Ik ben zo'n techie, en geloof me, je wilt een GUI ECHT niet over een klein lijntje tetteren.
het voordeel van character georienteerd remote beheer is dat de lijn minder opklopt. Bovendien zijn er voor character georienteerd remote beheer meer mogelijkheden mbt beheer (zoals het inzetten van Cyclade management consoles)

Voor mail... grafiekje van het verloop van de mail/virus/spam-traffic op maand/dag/uur-basis? Niet onmiddelijk het configureren van de mail, maar toch nauw verwant ermee, al was het maar om proactief te handelen...

zoeiets doe je indd op een client. Denk hieribj aan een mailserver die zijn output in een database spuugt die vanaf een werkplek in combinatie met een rapportage tools (access voor mij part maar Business Objects of cognos zijn veel interessanter hiervoor) die middels SQL de gegevens dan wel agregeerd en ophaalt.

Dat er mensen zijn die grafieken maken op de console van een productie server en ook nog "handmatig" in een database lopen te hacken. (iets wat van nature al erg fout is!!!!!, laat staan op de console van een server!) vind ik echt heel erg triest. sterker nog het maakt mij bang

even over handmatig zaken aanpassen in een productie database: zoeiets doe je domweg niet om de volgende redenen:
1: waar mensen met de hand data aanraken loop je tegen fouten aan. (verkeerte toets enz
2: gegevens worden bevuilt en kunnen als onjuist beschouwt worden.
3: als de directeur je vraagt de resultaten van een financieel systeem iets te manipuleren ga je dat toch niet doen? Wat is dan de betekenis van die data? kerstboomversiering?

[ritsjoena]

Kortom, de fout die Sun maakt na mijn mening is dat ze te veel op de grafische kant richten.

Waar zie je staan dat ze hier een zeer hoge prioriteit aan geven? Dat de grafische aspecten belangrijk zijn dat is duidelijk, maar hun concentratie ligt volgens mij toch vooral op het draaibaar krijgen van ALLE serverprogramma's die hier van toepassing zijn.

Grafische aspecten zijn hierbij belangrijk, misschien niet omdat het niet zonder kan (want dat zal waarschijnlijk niet voorkomen), maar omdat de klant daarom vraagt. De meeste klanten zijn tegenwoordig zo gewend aan grafische shells dat een systeem dat dat niet ondersteund niet echt serieus genomen kan worden.

Een grafische shell maakt het niet alleen makkelijker voor de low-end beheerder om het systeem te beheren, maar ook voor de andere beheerders zijn er hulpapplicaties die het leven eenvoudiger maken.

Verder zijn er ook servertoepassingen die het grafische aspect nodig hebben. Bijvoorbeeld de eerder genoemde terminal systemen. Aangezien dit systemen zijn die meer eisen van de onderliggende systemen dan een file/webserver zullen deze vaker geupgrade moeten worden. En dit is een interessante markt voor Sun.

[Verwijderd]

Maar wat is hier het nut nou precies van? Ik bedoel, ik begrijp heus wel dat Sun brood ziet in de x86 markt, maar er zijn al tig Unix varianten ondertussen die op x86 draaien. Sun moet dan wel met iets vernieuwends komen om het echt tot een success te brengen.

Wat dacht je van Cluster nodes???
Weet je wel niet hoe interassant he tis om Solaris als OS op de Sun fire rack versies te draaien met opteron CPU's erin. lekker sun Fire's erbij Pluggen als je het nodig hebt, ipv weer een Fire 15k erbij kopen en de helft van de kracht niet gebruiken.

Ten tweede: Als ik het goed begrijp willen ze dus standaard java gaan leveren met het OS. Slechte, slechte zet. Er zijn genoeg mensen die java geen prettig platform vinden, dus waarschijnlijk zullen ze dan ook niet voor dit OS kiezen als het daadwerkelijk geintegreerd wordt in het OS.

Dan gebruik je het niet. Het feit dat het erbij is, is alleen maar handig.

Ten derde: Tis leuk en aardig dat je remote grafische programma's kan starten, maar op een productie server zet je normaal gesproken geen grafische omgeving, dus is deze "feature" vrij nutteloos.

Nooit van de oude sparc stations gehoord die Solaris als Workstation OS hadden? denk aan rendering van images e.d.

[Iblies]

Waar ik aan dacht, x86 -> intel. Het zal niet zo moeilijk moeten zijn om van amd naar intel te gaan.
Sun heeft in het verleden al een naam opgebouwd, en heeft nu nog steeds een sterke troef in handen met Java.
Solaris hoeft niet snel te zijn op een opteron, en het hoeft ook niet uit te blinken. Zulke servers worden zelden tot 100% belast, dus die moet het niet geoptimaliseerd OS wel trekken.
Het voornamelijkste zal denk wel het introduceren van solaris en andere sun-producten, met name java, en ze daar mee leren omgaan.

[Bigs]

Solaris bestaat al jaren voor IA32 (32-bit x86 dus), maar toch leuk bedacht hoor

[SKiLLa]

Maar wat is hier het nut nou precies van? Ik bedoel, ik begrijp heus wel dat Sun brood ziet in de x86 markt, maar er zijn al tig Unix varianten ondertussen die op x86 draaien. Sun moet dan wel met iets vernieuwends komen om het echt tot een success te brengen.

Solaris staat bekend als een heel stabiel, veilig en schaalbaar platform. Aangezien Sun z'n hardware divisie aan het afbouwen is, lijkt me dit een logische stap. Geen (erg stoere maar) dure SPARC hardware, maar toch Solaris zodat bestaande enterprise klanten eventueel makkelijk kunnen migreren ...

Vergeet niet dat Sun zich met Solaris ook op de high-end markt bevindt !

Ten eerste: wie wil er nou een grafische schil op een productie server? Dat vreet toch alleen maar onnodig veel RAM? Je laat een productie server wel door een specialist beheren, en niet door een thuis-gebruiker (dus iemand die comfortabel is met de console)

Je hoeft toch geen grafische schil te gebruiken ?
X11 installeren is NIET verplicht lijkt me, maar meestal wel wenselijk. Beheerders vinden het ook wel fijn om met een muis + file explorer te browsen ipv. alleen shells (lokaal) te gebruiken ...

Ten tweede: Als ik het goed begrijp willen ze dus standaard java gaan leveren met het OS. Slechte, slechte zet. Er zijn genoeg mensen die java geen prettig platform vinden, dus waarschijnlijk zullen ze dan ook niet voor dit OS kiezen als het daadwerkelijk geintegreerd wordt in het OS.

Ze zeggen dat Java nog niet werkt, NIET dat het geintregreerd in het OS is (wat het zeker niet zal zijn !!!!, al zal het wel aanwezig zijn). Ook hier geldt, als je het niet wil gebruiken, gebruik je het toch niet ?!? ... Of dacht je dat de kernel van Solaris in Java geschreven was ?

Ten derde: Tis leuk en aardig dat je remote grafische programma's kan starten, maar op een productie server zet je normaal gesproken geen grafische omgeving, dus is deze "feature" vrij nutteloos.

Je snapt het echt niet ? Het OS functioneert dan als Server voor Terminals, die wel met een grafische shell werken, maar het echte 'rekenwerk' aan de server overlaten ...

Kortom, de fout die Sun maakt na mijn mening is dat ze te veel op de grafische kant richten. Het is leuk voor een workstation (kijk naar java desktop), maar op een productie server is het zeer zeker onverstandig naar mijn mening.

Ik kan helaas niet anders concluderen dat je niet veel verstand van Solaris - of Unix servers in het algemeen - hebt. No offense intended, maar als je ergens geen verstand van hebt, lever er dan aub. geen ongegrond commentaar op.

* 786562 SKiLLa

[n4m3l355]

ik denk dat zoals je al aangeeft SUN in de highend markt zit. als je low-end of hetgeen wat ertussen ligt bekend maakt met solaris ze bijv. ook later sneller geneigd zullen zijn om ook in de highend markt over te gaan naar solaris.. en de daarnaast verwante SUN servers. en dat dit dan ook de achterliggende gedachte is van SUN. het gebruik laten maken van solaris als een visite kaartje.

ik vraag me nu wel af of de XEON's die ook i86-64 compatible nu zouden zijn of daar dan deze distro ook op zal werken. een tijdje terug was er deze post van sgi http://www.tweakers.net/nieuws/31515/?highlight=nasa en dacht dat sgi van sun is. dit zou dan bijvoorbeeld heel leuk zijn om geoptimaliseerde xeon clusters te bouwen

[mxcreep]

Ik zie niet snel de opteron als echte vervanger voor de grotere sparc machines, die hebben toch wat features in de vorm van allerlei hot swappable hardware die ik nog niet in het x86 wereldje ben tegengekomen.
Maar vooral bedrijven die al wel dergelijke servers in hun programma hebben kunnen nu de low / mid end servers ook uitrusten met hetzelfde OS zodat je een omgeving krijgt die vertrouwd is voor de beheerders die je hebt lopen...

[Luno]

Er is niets nieuws onder de zon.

Ik denk dat ik een van de weinige op tweakers ben die nog met Sun-OS 386i heb gewerkt in 1989. voordat de Sparc uitkwam. We hadden zo'n Sun 386/25Mhz machine en Sun OS. Zelfs met een optie voor upgrade naar 486 als die uitkwam. De 486 kwam uit en we konden begin zomer upgraden, ivm zomer even gewacht en daarna mocht het niet meer. Sun had toen z'n Sparc processor, en wat erger was de 486 was sneller, en mocht daarom niet meer gebruikt worden. Hetgeen jammer was, want de Sun386 was uitermate stabiel, en kon een MSDOS window zo goed emuleren dat Flight Simulator er in werkte (nou ja niet crashte), maar het Dos Window deed het ook met Novell drivers met een Novell netwrk kon verbinden, Met het gewone SunOS op de 68duizend serie of Sparc daarna kon dat niet zo makkelijk.

Na en jaar hebben we toen uit frustatie Sun aan de kant gezet en vervangen door OS2 machines (die nog steeds doen voor het doel waarvoor we ze hebben aangeschaft).

[sjun]

Een uitstekende zet van SUN maar zou het op tijd zijn. Destijds hebben we met pijn in het hart de te prijzige hardware van SUN in verhouding tot de alternatieven verlaten. IBM bood destijds met OS/2 een stabiel betaalbaar alternatief. IBM biedt intussen allerhande hulp bij migraties van OS/2 naar Windows 200X server, en Linux mogelijk kan Solaris op tijd aansluiten.

Natuurlijk heeft Microsoft flink wat kwaliteit ontwikkeld in de tussenliggende jaren, maar toch... Voor SUN moet er hier toch wat te halen zijn tussen Microsoft en Linux/Novell reclamegeweld. Er zijn alternatieven voor de hardware en er komt bovendien een zeer goed bekend staand besturingssysteem op die betaalbare platforms.

Ik ga dit zeker volgen.

[Zwerver]

Nee, lekker gemotiveerd ook wat jij zegt. Iedereen weet dat? Nou sorry, ik heb Solaris op x86 draaiend gehad, en het is echt niet zo traag als wat jij zegt. Dat verhaal over die traagheid komt nog uit de prehistorie tijden, toen solaris ECHT traag was op x86. En het feit alleen al dat jij zegt dat hun hardware inferieur is zegt meer iets over jou dan over Sun. Iedereen die een beetje verstand heeft van processor architecturen weet dat de x86 architectuur gewoon een "slecht doordachte" architectuur is. Het is goedkoop, dat wel, en het wordt veel gebruikt. Dat Sun daar dus een graantje van wil meepikken is niet meer dan logisch imho.

[Verwijderd]

X86 heeft zeker zijn zwakke punten, maar de performance in de praktijk is gewoon erg goed, in tegenstelling tot SPARC. Bovendien heeft SPARC een roterende register file, misschien wel het allerdomste idee in de geschiedenis van processorarchitecturen. Dat alleen al maakt het tot een waardeloze architectuur waar volstrekt niet normaal mee te werken valt. Multithreading bijvoorbeeld wordt hierdoor praktisch onuitvoerbaar.

Persoonlijk word ik nogal beroerd van al die mensen die menen te kunnen beoordelen dat x86 een slechte architectuur is, puur en alleen omdat ze hem zelf niet goed snappen. Het is inderdaad een architectuur met een lange geschiedenis en een hoop (deels overbodige) bagage, maar de assembly taal is een stuk fijner om mee te werken dan die van RISC CPUs en zeker als je goed kunt optimaliseren is de performance gewoonweg fantastisch.

[packman]

Solaris op x86 heeft idd een "reputatie" - maar vermits Sun meer en meer op het Opteron platform begint te wedden vermoed ik wel dat ze daar serieus werk van hebben gemaakt. Ze kunnen het zich niet permitteren van op bakken die ze zwaar promoten als hun "low-end" servers slechte kritieken te krijgen qua performance...

@Jorden Verwer - de IA64 architectuur van Intel gebruikt ook een rotating register file (allez - mogelijkheid tot het gebruiken als) daar moet dan toch wel een reden voor zijn? X86 heeft gewoon te weinig registers, terwijl een sparc er typisch met 128 of meer zit, dat kan je niet meer 100% laten organiseren door een compiler die vind dat hij alle registers voor zichzelf heeft (zoals op x86), daarom dat er rotating frames gebruikt worden waar er x aantal registers gemapt worden per process. Dat is inderdaad een pak ingewikkelder, en dat is de taak van het OS+CPU - maar voor multitasking en multithreading is dit juist enorm goed.

Ook is sparc zeer stabiel (qua performance dan) bij vele simultane threads/tasks. De performance/tasks verhouding dropt veel minder snel dan bij op een x86 architectuur, er is een reden dat echt grote databases nog steeds oracle + Sun hardware gebruiken.

En in de x86-evolutie zijn door de geschiedenis heen verschillende design-vergissingen begaan - die ons met een hoop onnodige bagage opschepen voor "backwards compatibility". Who the hell wil er nu nog een 8bit XT programma draaien op een P4 of Athlon XP/Opteron? Maar het is wel nog mogelijk...

[Verwijderd]

Tsja, ik kan niet zeggen dat ik IA64 een schoolvoorbeeld vind van hoe het wel moet...

Er is bij x86 een tekort aan registers, dat geef ik grif toe. Maar met register renaming is het in ieder geval nog werkbaar, terwijl register windowing gewoon meer problemen geeft dan het oplevert. Kijk hier maar:
http://www.extremetech.com/article2/0,1558,1158259,00.asp
Mijns inziens had Sun gewoon beter voor 32 altijd zichtbare registers kunnen kiezen, zoals vrijwel elke andere load-store architectuur ook heeft.

Verder: van 8-bit programma's is geen sprake, x86 is van het begin af aan een 16-bit architectuur geweest, ook al was er assembly-level compatibiliteit met de 8080. Het feit dat je de mogelijkheid hebt deelregisters als AH te gebruiken wil niet zeggen dat het een 8-bit architectuur is of is geweest. Er is nooit een echte 8-bits x86 CPU geweest, het enige wat in de buurt komt is de 8088. Maar zelfs de oudere 8086 is volledig 16-bits.

[Verwijderd]

Wat herhalen jullie elkaar veel....

[Verwijderd]

By Silentsnake:
Ten tweede: Als ik het goed begrijp willen ze dus standaard java gaan leveren met het OS. Slechte, slechte zet. Er zijn genoeg mensen die java geen prettig platform vinden, dus waarschijnlijk zullen ze dan ook niet voor dit OS kiezen als het daadwerkelijk geintegreerd wordt in het OS.

Ten derde: Tis leuk en aardig dat je remote grafische programma's kan starten, maar op een productie server zet je normaal gesproken geen grafische omgeving, dus is deze "feature" vrij nutteloos.

Kortom, de fout die Sun maakt na mijn mening is dat ze te veel op de grafische kant richten.

Indien je hem als server gebruikt voor bv SAP dien je op de server de beschikking te hebben over zowel Java als een grafische interface (voor zowel installatie van SAP als mede upgrades voor je plugins)

Oftewel ze maken geen fout en is dus helemaal niet nutteloos.

[silentsnake]

@ SKiLLA XP

Ten eerste, ik ben hier uitgegaan van een server omgeving (denk aan web, ftp en dat soort zaken), aangezien er op een plaatje een server staat afgebeeld dacht ik dat het over servers ging.

Je snapt het echt niet ? Het OS functioneert dan als Server voor Terminals, die wel met een grafische shell werken, maar het echte 'rekenwerk' aan de server overlaten

Ik snap het wel degelijk. Wat jij nou aangeeft is een mogelijkheid wat je met het OS kan doen. Nogmaals, ik ben uitgegaan van web en ftpservers en dat soort zaken, niet als Terminal Server oid.

Ik kan helaas niet anders concluderen dat je niet veel verstand van Solaris - of Unix servers in het algemeen - hebt. No offense intended, maar als je ergens geen verstand van hebt, lever er dan aub. geen ongegrond commentaar op

Fijn dat je even verder leest. Als je beter gelezen stond er dit:

"Het is leuk voor een workstation (kijk naar java desktop), maar op een productie server is het zeer zeker onverstandig naar mijn mening."

Met andere woorden, zodra je _wel_ een grafische schil nodig hebt, is dit wellicht een aantrekkelijk pakket.

Je mag het dan wel oneens zijn met mijn mening, maar je hoeft dat toch niet op zo een manier te laten blijken?

[Verwijderd]

Webserver en ftpserver is nu niet echt de hoofdtaak van Solaris hoor, je hebt er inderdaad geen kaas van gegeten omdat je simpelweg de verkeerde dingen wil doen met het Solaris server OS.

Terminal Services etc. zijn de opties waar solaris veel voor ingezet word, ja dan heb je bestwel een gui nodig voor alle simpele gebruikertjes, of wil je soms dat elke terminal de GUI zelf draait? Worden dure terminalletjes dan.
Heb je in plaats van een monitor, toetsenbord en muis ineens nog een hele pc nodig om je gui tje te draaien. Dat scheelt veel op 20000 systemen, hoe goedkoop je pctjes ook worden dan.