Eine der jüngsten Fragen bezog sich auf mögliche Gründe für die Verwendung von Solaris auf einem Server. Ich möchte nach dem Gegenteil fragen:
Was wären Gründe, sich auf einem Server von Solaris fernzuhalten?
Das Paket- und Patch-Management fällt mir ein, aber ich bin mir sicher, dass noch mehr dahinter steckt. Sie können auch auf die Vorteile anderer Server-Betriebssysteme gegenüber Solaris hinweisen.
Antworten:
Ich bin (war) ein Solaris-Administrator bis vor ungefähr neun Jahren, von Version 2.5 bis Version 8. Ich hatte ein wenig Kontakt mit Solaris 9 und fast keine mit 10.
Meine Gründe, Solaris zu vermeiden:
Die Hardwareunterstützung ist bei weitem nicht so gut wie bei vielen Linux- oder Windows-Betriebssystemen. Es verbessert sich.
Sie können Solaris kostenlos ausführen, aber Sie können keine kostenlosen Updates erhalten. Nicht einmal Sicherheitsupdates. Nicht einmal 0-Tage-Exploits. Sie müssen pro System einen Supportplan kaufen, der teuer sein kann. Dies bedeutet, dass Sie Updates erhalten, indem Sie auf die nächste "U" -Version warten und zu diesem Zeitpunkt ein Upgrade durchführen.
OpenSolaris ist mir zu auf dem neuesten Stand. Es ändert sich zu oft und die Veröffentlichungen sind für meine Bedürfnisse zu instabil oder unzuverlässig.
Zwischen Solaris und OpenSolaris hat Sun es geschafft, das glückliche Medium zwischen "Willkommen in 2004" und "Ich bin so neu und glänzend, dass ich nicht wirklich 100% arbeite!"
Früher war ich bereit, Solaris häufiger zu verwenden, bevor das Blastwave-Projekt implodierte. Dort konnte ich mit einer relativ einfachen Online-Verwaltung der Tools und Updates neuere Tools erhalten, die besser zur Linux-Methode passen (wo ich 95% meiner beruflichen Zeit verbringe). Sobald sich Blastwave und CSW beruhigt haben, werde ich mir beide Überreste ansehen und entscheiden, ob es sich lohnt, wieder Zeit und Mühe in eines von beiden zu stecken. Der Verlust von Blastwave als vertrauenswürdige Werkzeugquelle war ein schwerer Schlag für die Lebensfähigkeit von Solaris in meinen Kreisen.
Der Hauptgrund für mich ist jedoch, dass ich im Moment nichts tun muss, was Solaris erfordert.
Meine größte Sorge als großer Oracle-Kunde ist, dass sie irgendwann entweder Solaris oder 'Oracle Enterprise Linux' (ihre Neuauflage von RHEL) abschaffen werden.
Natürlich haben beide ihre Vor- und Nachteile, aber ich weiß, dass sie viel mehr OEL-Supportvereinbarungen verkaufen als Sun für Solaris verkauft hat, und natürlich besitzen sie die Entwicklungskosten von Solaris, die OEL-Entwicklungskosten sind dann überhaupt sehr gering.
Wir alle lieben Solaris, aber wenn es sich nicht gut genug verkauft und zu viel kostet, um es zu entwickeln, wird Oracle es sicher einfach "Asset Strip" (ZFS usw. behalten) und an jemand anderen weiterverkaufen. Das wäre mein Hauptanliegen.
Seit 10-15 Jahren besteht die größte Sorge um die Zukunft von Sun und die Zukunft von SPARC. Ich war kurz davor aufzugeben, als sie Solaris 10 herausbrachten, das technologisch einen Sprung nach vorne machte (obwohl es ~ 1 Jahr dauerte, bis es produktionswürdig war). Der kürzlich erfolgte Kauf von Oracle bringt eine Menge kurzfristiger Unsicherheit mit sich, die jedoch (unabhängig vom Ergebnis) ziemlich schnell verschwinden könnte. SPARC scheint immer noch eine verlorene Sache zu sein, obwohl die "neuen" CoolThreads-Prozessoren viel Aufsehen erregen, aber diese sind zu spezialisiert, um breite Akzeptanz zu erlangen.
Es wird interessant sein, Branchentrends zu beobachten ... Vor Jahren habe ich viele Wall Street-Firmen beobachtet, die nicht für Linux, sondern für x86 zu Linux (von Solaris / sparc) strömten. Als Solaris 10 herauskam, gab es definitiv eine teilweise Umkehrung zu Solaris, wieder auf x86.
Das Paket- und Patch-Management sollte keine Sorge sein, es ist eine Frage des Wissens / der Fähigkeiten. Um Ihnen eine andere Perspektive zu bieten, ist mein neuer Job in einer Linux-Umgebung und sowohl das Paket- als auch das Patch-Management machen mir Sorgen. Dies sind alte generische Bedenken, auf die es Antworten gibt.
Ich werde Solaris sehr vermissen, einige Dinge darin können einfach nicht anderswo gefunden werden.
Der einzige Grund, den ich finden kann, ist der "Mangel" an Support / Informationen im Web, wenn Sie kein Experte für Solaris sind (im Vergleich zu Linux oder FreeBSD).
Der Vergleich von Solaris 10 mit Linux ist Äpfel mit Orangen. In erster Linie liegt der Unterschied in der Build-Umgebung, wie jeder bestätigen kann, der Linux-Apps auf Solaris verschoben hat. Ich würde erwarten, dass Oracle sich darauf konzentriert, das Linux-Quell- / Anwendungskompatibilitätsmodell zu entwickeln, anstatt zu versuchen, Solaris als Ersatz für Linux zu positionieren. Linux ist auch kein Ersatz für Solaris!
Für kleine Anwendungen ist Linux in Ordnung, für eingebettete Anwendungen wahrscheinlich besser. Für große Iron-Anwendungen gehört Solaris zu einer anderen Klasse als jede Linux-Distribution. Wenn Sie sich den TCP / IP-Stack von Solaris, die Echtzeitplanung, das Service-Management und die kugelsichere Virtualisierung (Zonen) ansehen, haben Sie im Vergleich zu Linux eine Vielzahl von Funktionen. Wenn Sie ZFS, DTRACE und MULTI-THREAD-ZEITPLAN hinzufügen, befinden Sie sich in einer völlig anderen Betriebssystemklasse.
Linux ist großartig, ich liebe es. Solaris ist großartig, ich liebe es auch. Jeder hat seine Vor- und Nachteile. Oracle wird seine Big-Iron-Produkte wie EXEDATA2 sicherlich nicht auf LINUX bauen, wenn es in Solaris ein überlegenes Produkt für Big-Iron-Umgebungen bietet.
Als mein Shared-Server-Host von BSD zu Open Solaris wechselte, verschwand das FTP-Jailing . Ich weiß nicht, ob FTP-Jailing unter Open Solaris mithilfe eines anderen FTP-Servers oder möglicherweise durch Neukonfiguration des Standard-FTP-Servers verfügbar gemacht werden kann.
Die Autoren der Joyent-Wiki-Seite über das Problem schreiben das Problem getcwd zu .
Ich arbeite seit 2002 (also seit 15 Jahren) an Solaris und alles, was ich sagen kann, ist, dass es für diese ganze Zeit mein "Lieblings" -Betriebssystem war, insbesondere wegen seiner Stabilität und seiner Stabilität bei bekannten kommerziellen Anwendungen wie Networker, Oracle (als es noch Sonne war), Netbackup & so weiter.
Aber es ist mehr eine "Leidenschaft" für Solaris als alles andere.
Nach 15 Jahren waren für mich die "Hauptprobleme" (wenn wir sie Probleme nennen können):
das Fehlen einer Online-Dokumentation im Vergleich zu anderen Betriebssystemen (insbesondere beim Versuch, die Systemleistung zu debuggen), aber es war besser, als Solaris 10 eintraf. Insbesondere für Infrastrukturdienste wie LDAP, Kerberos, NIS2LDAP usw. wurde jedes System separat dokumentiert, aber es konnte nie eine gute Dokumentation mit Personen gefunden werden, die alles auf einmal implementierten.
Patches / Upgrades (mein Unternehmen musste ein eigenes Patching-System für Solaris entwickeln)
das Fehlen kompatibler Tools / Binairies online (wir mussten oft unsere eigenen kompilieren und finden selten vorkompilierte Binairies)
die Schwierigkeiten, Leistungsprobleme zu verstehen, manchmal aufgrund des Mangels an guten Tools (Solaris ist nichts für Anfänger, die versuchen zu verstehen, wie das System funktioniert) und seiner spezifischen Speicherverwaltung (insbesondere in Verbindung mit Oracle-Datenbanken und allem, was gemeinsam genutzten Speicher verwendet)
Auf der anderen Seite ist Solaris aus mehreren Gründen immer noch mein Lieblingsbetriebssystem. Einige davon sind:
Ich habe Solaris 11 noch nie ausprobiert, aber es sieht gut aus und ich hätte nichts dagegen. Ich bin an Solaris 10 gewöhnt (wir verwenden es immer noch stark dort, wo ich arbeite) und RHEL jetzt (was auch großartig ist, aber völlig anders). RHEL ist der einfache Weg ... wenn Sie nicht kämpfen wollen und Sie möchten Lösungen auf Seite 1 von Google finden, wenn Sie Probleme haben.
Solaris ist ziemlich instabil. Das Herumspielen mit POSIX-Nachrichtenwarteschlangen führt zu viel undokumentiertem Verhalten. Andererseits funktioniert Linux wie ein Zauber, überhaupt keine Probleme.
EDIT (nach 1,5 Jahren Forschung und harten Tests): OK, Leute, vielleicht ist Solaris nicht so schlecht. Problem ist, dass errno.h standardmäßig NICHT GEWINDESICHER ist. Somit bekomme ich zufällige Fehler von anderen Threads. Wir müssen also _REENTRANT, _TS_ERRNO oder _POSIX_C_SOURCE - 0> = 199506L definieren, um errno threadsicher zu machen. Beachten Sie, dass errno unter anderen Betriebssystemen standardmäßig threadsicher ist. Dies führt zu Verwirrung.
mq_receive()kehrt zurück ssize_t, NICHT int . Sie sind NICHT gleich. Zweitens gemäß 7.1.3 Reservierte Bezeichner des C-Standards : "Alle Bezeichner, die mit einem Unterstrich und entweder einem Großbuchstaben oder einem anderen Unterstrich beginnen, sind immer für jede Verwendung reserviert." Enduro / X-Code ist reich an reservierten Kennungen. Wenn Sie ein pedantischer Trottel sein wollen, nur weil ein Betriebssystem zufällig einen undokumentierten errnoCode zurückgibt , sollten Sie wahrscheinlich keinen Code schreiben, der nicht den Standards entspricht.