Oracle introduceert eerste CBE-release van Solaris

Oracle heeft de eerste Common Build Environment-release van Oracle Solaris 11.4 vrijgegeven. De CBE-releases zijn te beschouwen als pre-releases van Solaris voor onder andere opensourceontwikkelaars.

Met de Common Build Environment-releases wil Oracle nieuwe functies en verbeteringen voor Solaris-versies sneller naar meer systemen brengen. Opensourceontwikkelaars en mensen die het OS voor persoonlijk gebruik in non-productieomgevingen inzetten, kunnen dan aan de slag met actuele versies van de software, zo is de bedoeling.

Volgens Darren Moffat, softwarearchitect bij Oracle, is er behoefte aan een pre-releasebuild van Solaris, omdat het besturingssysteem nu een continuous delivery model van microreleases met Support Repository Updates heeft. "Met die stap zijn veel nieuwe functies die toegevoegd zijn aan Oracle Solaris 11.4 niet meer beschikbaar in een release met een licentie voor non-productiegebruik."

Niet alle fixes van een komende SRU-release zijn onderdeel van een CBE-release, maar omdat het om cumulatieve updates gaat, bevatten ze hoe dan ook alle verbeteringen van voorgaande SRU's. De gebruikers van Oracle Solaris 11.4.0 GA kunnen met een eenvoudige pkg-update overstappen op CBE, belooft Oracle. Dat bedrijf kreeg Solaris in 2009 in handen met de overname van Sun Microsystems.

Oracle Solaris 11.4

Door Olaf van Miltenburg

Nieuwscoördinator

04-03-2022 • 14:34

60

Reacties (60)

60
59
28
1
0
24
Wijzig sortering
Leuk,
Maar volgens mij draait er anno 2022 niemand meer op Solaris 🙈😂
Best jammer. COMSTAR, SMF, ZFS en DTRACE zijn echt wel mooie technieken.
Technisch was het inderdaad best oké. Maar zoals de meeste Unix achtingen zijn ze uit de markt gewerkt door Linux. Linux beheerders zijn nu eenmaal beter te vinden dan Solaris, hpux of AIX beheerders. 😉

Vooral ZFS was de tijd ver vooruit. Ooit 🙈
Wat heeft ZFS dan ingehaald?
Qua technologie is ZFS iets veel geavanceerder dan EXT4. ZFS is een 128-bits bestandssysteem, voor zover ik weet bestaan ​​er maar heel weinig andere 128-bits bestandssystemen. In werkelijkheid heb je, als je een ZFS-systeem (de volledige opslagcapaciteit) volledig wilt benutten, zoveel energie nodig dat de oceanen op aarde door de vrijgekomen warmte meerdere keren verdampen. ZFS is ook een volumemanager en bestandssysteem in één pakket. Ik denk niet dat EXT4 een volumemanager is.

EXT4 heeft ook geen laatste archieftijdstempels, en ook een minder goed controlesommechanisme. Dus ZFS is geavanceerder in termen van functies. Je kunt eigenlijk stellen dat ZFS voor de Cloud en voor databases momenteel geen geavanceerd alternatief heeft dat even betrouwbaar is. (ZFS is het meest stabiele en betrouwbare bestandssysteem dat ooit is ontwikkeld). In feite is gegevensintegriteit belangrijk voor elk systeem met opslag, niet alleen voor servers. Er is momenteel nog steeds geen enkel ander bestandssysteem dat even betrouwbaar is.

Je hebt ook nog een ander belangrijk kenmerk van ZFS: compressie. Bepaalde bestanden kunnen door ZFS worden gecomprimeerd met +- 50% compressie. Waar NTFS slechts +- 15% haalt. Bovendien wordt ZFS sneller wanneer het de gecomprimeerde bestanden gebruikt, waar NTFS gewoon snelheid verliest. Het is dus een geniaal bestandssysteem dat objectief gezien veel beter is dan de beste bestandssystemen van Microsoft en Apple.

EXT4 kan bvb wel sneller zijn in synthetische prestatiebenchmarks. Maar niet altijd. Voor PostgreSQL Read+Write krijg je vaak twee keer zo hoge resultaten op ZFS + FreeBSD in vergelijking met EXT4 + Linux. ZFS op FreeBSD haalt waarschijnlijk ook iets hogere prestaties dan op Ubuntu. Omdat het de default optie is in FreeBSD en nog betere integratie en optimalisatie heeft. Hoewel de integratie in Ubuntu ook al redelijk goed is.
Ik behoor ook tot de kerk van ZFS maar veel van de features zijn ook te vinden in NetApp's WAFL.
Er is dan ook een rechtszaak geweest tussen Oracle en NetApp daarover… ik heb voor Sun en NetApp gewerkt en met een paar mensen gebabbeld. In de beginperiode was iedereen met een bsd Kernel aan het testen… daar ligt de oorsprong van beide.
https://storagegaga.wordpress.com/2011/10/01/ontap-vs-zfs/

Therefore, the ability of ZFS to survive data corruption, metadata deletion is stronger when compared to WAFL .This is not discredit NetApp’s WAFL. It is just that ZFS was built with stronger features to address the issues we have with storing data in modern day file systems.

There are many other features within ZFS that have improved upon NetApp’s WAFL. One such feature is the implementation of RAID-Z/Z2/Z3. RAID-Z is a superset implementation of the traditional RAID-5 but with a different twist. Instead of using fixed stripe width like RAID-4 or RAID-DP, RAID-Z/Z2 uses a dynamic variable stripe width. This addressed the parity RAID-4/5 “write hole” flaw, where incomplete or partial stripes will result in a “hole” that leads to file system fragmentation. RAID-Z/Z2 address this by filling up all blocks with variable stripe width.
Merci! Ik was al bekend met het aanzien van ZFS en bedoelde eigenlijk ook te vragen waarom ZFS dan "ooit" de tijd ver vooruit was, wat suggereert dat het ingehaald zou zijn.
Toch alsnog een heldere uitleg en goede toevoeging :D
ZFS is ook endian agnostisch, ttz je kan een ZFS volume zowel aan een big-endian(RISC,SPARC, Arm,..) als aan een little-endian(x86) mounten om bijvoorbeeld data uit te wisselen in een SAN omgeving - maar niet tegelijkertijd natuurlijk.(daarvoor bestaat immers NFS).
Arm is vanaf big-endian via endian-switchable naar little-endian gegaan. Armv8-A is native little-endian. Solaris is natuurlijk ontstaan op SPARC, dus de historische ondersteuning voor big-endian is begrijpelijk maar irrelevant in 2022. Zelfs RISC-V is little-endian.
Ik ben eigenlijk niet echt een fan van zowel ZFS als ext3/ext4.

ZFS is mooi als concept, maar het vervaagt naar mijn inzien teveel het onderscheid tussen volume management en een filesystem.

Tegelijkertijd bevat ext3 en ext4 fundamentele ontwerp- en implementatiefouten die leiden tot dataverlies. Denk bijvoorbeeld aan iets als een kjournald die op regelmatige tijden actief wordt om (meta)data weg te schrijven, zonder te controleren of het klaar was met de vorige schrijfactie. Daarnaast blijft ext4 read-write wanneer een verminking van de metadata wordt gedetecteerd in plaats van dat het een filesystem read-only maakt, waardoor verdere verminking mogelijk bijft (en welhaast een zekerheid is).

Wat dat betreft zit iets als XFS veel beter in elkaar..
ZFS kun je niet vergelijken met alleen een bestandssysteem. Je zou dan tenminste ook de lvm mee moeten nemen denk ik. ZFS heeft dat ingebouwd min of meer
Zoals je het hier beschrijft klopt het allemaal wel maar tegelijk zie ik waarom ZFS in unix/linux toch een vreemde eend in de bijt is: Het voegt te veel samen!

Vanuit unix/linux wordt naar msWindows altijd gekeken dat ze daar te veel zaken/taken samen voegen. Small is beautyfull wordt wel eens gezegd. Voor een volume manager als lvm maakt het niet uit welk partitie schema gebruikt wordt of wat voor filesysteem er gebruikt wordt, het kan zelfs zonder. Ook nesten is geen probleem. Met zfs worden die zaken allemaal samengevoegd en is er geen ruimte meer om daar creatief mee om te gaan.
ZFS is beperkt tot één server (al heb je in Solaris wel de optie tot high availability). In die zin is het wellicht ingehaald door gedistribueerde opslagsystemen als Ceph die op een veel grotere schaal functioneren.
TrueNAS-scale is gemaakt om dit soort clustering mogelijk te maken. Om dit te bereiken zullen ze gluster bovenop ZFS gebruiken.

In plaats van nog een server toe te voegen, zou je een schijfplank kunnen krijgen en deze via een sas-kaart met je huidige server kunnen verbinden.

Dus Ceph is meestal een volledig overbodige technologie.
Ik heb zelf een SysAdmin cursus van SUSE (Linux) gevolgd. Ik heb de cursus hoofdzakelijk geleerd van op mijn FreeBSD desktop.

Wat ik toen gemerkt heb was dat 55% van deze SUSE cursus te maken had met Unix commando's die perfect werken op de Almquist Shell. (de standaard shell in FreeBSD)

Dus ik zou zeggen dat mensen met ervaring als Linux beheerder in een paar weken kunnen leren werken met Solaris, HP-UX en AIX.
Dus ik zou zeggen dat mensen met ervaring als Linux beheerder in een paar weken kunnen leren werken met Solaris, HP-UX en AIX.
Absoluut maar het wordt wel frustrerend; Je weet niet hoeveel handige GNU features er mettertijd in je toolset zijn gekropen en hoe vreemd en archaisch de counterparts op andere Unixes wel eens durven te zijn. En sinds wanneer is FreeBSD afgestapt van (t)csh als standaard shell ?
Dat valt eigenlijk wel mee. Ik gebruik al vijf jaar FreeBSD op mijn desktop.
Het enige ding dat archaisch aanvoelt is dat er geen GUI app is om partities te beheren.

Maar ik heb meerdere USB's en SD kaartjes overschreven met nullen en dan geformateerd naar ZFS en de methode is eigenlijk wel simpel en gebruiksvriendelijk als je gewoon bent om met een terminal te werken.

Ik denk dat de Almquist shell de standaard is in veel BSD systmen sinds de jaren 90: https://en.wikipedia.org/wiki/Almquist_shell
Als het om de “gnu-utils” gaat, dan kan je inderdaad ver komen omdat het enkel verschil zitten in de hoeveelheid, aanwezigheid en werking van de opties.

Maar dan ben je er nog niet als het leren kennen van het OS. Want ieder OS heeft ook nog zijn eigen set aan commando’s die niet uitwisselbaar zijn. Dat maakt het leertraject niet gelijkwaardig.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 21:32]

Het leertraject is sowieso niet helemaal 'gelijkwaardig'. Maar mijn punt is dat als je bvb het boek Classic Shell Scripting leest dan kom je al heel ver op eender welk systeem dat op Unix gebaseerd is, inclusief bvb macOS en SUSE. In die cursussen van SUSE leer je ook veel Unix commando's die op de meeste systemen die van Unix afgeleid toepasbaar zijn.

Zie het als een nog veel grotere hulp dan bvb Latijn kennen vooraleer je Italiaans leert. Het helpt enorm. En vaak zijn het dus gewoon exact dezelfde scripts en commando's die je op de verschillende systemen kunt toepassen. Enkel zaken als firewall configuratie verschillen. Maar veel zaken zoals een FTP server configureren zijn opnieuw bijna exact hetzelfde op commerciële Unix systemen en Linux systemen.

Dus mijn punt is dat veel Linux systeembeheerders relatief snel kunnen leren werken met BSD/Solaris/AIX/HP-UX etc.
Ben geen expert, maar btrfs heb ik nog niet teruggezien om zfs te vervangen, en als ik de kenners mag geloven zal dat ook nooit gebeuren
btrf ... paar keer gedraaid, tot het 'in de soep loopt' was comment op forum daar; installeer ceph (of iets anders) om het te fixen. btrfs draai ik nooit meer
Apple ging ook ZFS gebruiken, maar per ongeluk had de toenmalige CEO van Sun eerder op gehint dat Apple dat ook ging gebruiken, eerder dan Apple's aankondiging.

Apple heeft dat toen teruggedraaid en later is APFS in de plaats gekomen.

https://arstechnica.com/g...lmost-was-until-it-wasnt/
Laten we wel wezen: Het is gnu die hier de zaak heeft overgenomen. En dat deed ze in 1995 ook al heel goed. In die tijd was ik software ontwikkelaar en systeem beheerder SunOS, Solaris, HP-UX en nog een beetje Dec Ultrix. Daar gebruikten wij al de complete GNU software set om alle ontwikkel omgevingen 1 kant op te laten kijken.

Dat Solaris en HP-UX met CDE hun eigen grafische omgeving achter lieten en naar 1 desktop gingen was al heel wat. Maar vooral de gnu omgeving maakte dat het allemaal ook gelijk werkte, ook op SunOS en Dec-Ultrix.

Voor de nieuwsgierigen: Voor msWindows bied cygwin.org die zelfde omgeving voor msWindows, zij het met de beperkingen van dat besturingssysteem.
Gelukkig leven de laatste 2 gewoon nog in bv FreeBSD
Mee eens, maar Solaris an sich is best een mooi OS. CPUs hotswappen.......
HD's kon je ook hotswappen
De beste feature is /etc/system. Als je iets aan de kernel wil veranderen hoef je enkel een parameter in /etc/system aan te passen en een reboot te doen. Je kan bv je data en stack locaties veranderen en nog veel meer. Is een belangrijk kenmerk van een system V OS. Alsook kan je 90% vd kernel kenmerken online veranderen. Alle andere (niet System V derivaten) moeten hun kernel hercompileren.
Toen Sun samen met AT&T hun System V OS (Solaris) aankondigden is er door de competitie (DEC, HP, IBM) de OSF opgericht dat een tegenhanger van SystemV ging worden (stond ook voor Oppose Sun Forever). Toen is Linux (SystemIV lookalike clone) uitgekomen en de rest is geschiedenis, maar de /etc/system functie is nooit overgenomen, weet niet goed welke patenten daar aan vast houden. Oracle heeft via Sun de licentie om hun SystemV aan te passen naar eigen goeddunken, want ze hebben die ooit de rechten gekocht toen Novell de SystemV rechten had.
Toen is Linux (SystemIV lookalike clone) uitgekomen en de rest is geschiedenis, maar de /etc/system functie is nooit overgenomen, weet niet goed welke patenten daar aan vast houden.
Mja er is op Linux toch sysctl voor run time kernel parameter wijzigingen en het configuratiebestand sysctl.conf voor startup.
Dat is natuurlijk wel een voorbeeld van antiek denken. "Je kan je data en stack locaties veranderen". Tja, maar een OS waar dat niet nodig is, is natuurlijk veel handiger.

Linux heeft natuurlijk wel het concept van live aanpasbare OS-parameters in het filesystem, via /proc/. Een heel filesystem is net iets handiger dan alles in één file duwen. Solaris moest heel /etc/system parsen om te zien welke parameter precies veranderd was.
Is /proc niet enkel voor user-land processen ? /etc/system is voor de kernel. modload un unload zijn voor kernel modules. De meeste settings in /etc/system die je gaat vinden veranderen inderdaad dingen aan drivers - aangegeven door de module en een :, gevolgd door de parameter. Meeste van die parameters kan je ook online veranderen, maar kernel aanpassingen zijn wat lastiger. Solaris ondersteund ook hetzelfde als Ksplice.
bhyve is ook een mooie techniek. Linux heeft geen hypervisor die VM's even snel kan laten opstarten, en het laag geheugengebruik bij een beperkt aantal VM's kun je met eender welke Linux hypervisor nog steeds niet evenaren.
Oracle noemt het een zakelijk OS, bedoeld om de Oracle databaseserver op te kunnen draaien. Ze zullen ongetwijfeld de juiste tweaks hebben doorgevoerd in Solaris om hun databasesoftware optimaal te kunnen uitvoeren.
Oracle heeft Unbreakable Linux, waarom zou je dan nog op Solaris willen draaien?
Solaris, illumos en FreeBSD hebben meerdere features die Linux niet heeft.

Bvb de 'Zones' feature van Sun Microsystems.
Bvb de kqueue functie van FreeBSD waardoor NginX veel sneller en efficiënter is dan op Linux.
Linux heeft nog altijd geen even goede ZFS integratie als Solaris en FreeBSD.

Commerciële Unix systemen waren vroeger meestal ook ongeveer 10-15% sneller dan Linux en Linux is gemiddeld niet echt sneller geworden dan vroeger.

FreeBSD is ook nog steeds makkelijker te beheren dan Linux systemen, als je er enkele jaren ervaring mee hebt. Linux is een verzameling technologiën die samengeplakt zijn tot één geheel, terwijl FreeBSD nog altijd veel meer een samenhangend geheel is.

Ik weet niet of je dit ooit geweten hebt, maar toen Microsoft overstapte van FreeBSD naar windows voor hun Hotmail servers, toen bleek dat ze meer dan tien keer meer sysadmins nodig hadden. Hierdoor hebben ze bij Microsoft een paar jaar langer FreeBSD moeten blijven gebruiken dat wat ze initieel gehoopt hadden.

FreeBSD heeft trouwens ook nog altijd de snelste network stack van alle besturingssystemen die er bestaan op aarde.
Linux innoveert snel. Zo heeft nu al een tijdje io_uring wat flink helpt met storage en netwerk toepassing. Makkelijker in gebruik dan kqueue. Veel software benut het.
io_uring is niet direct te vergelijken met kqueue omdat het een ander doel heeft.

Veel ontwikkelaars vinden kqueue een geweldige en goed ontworpen API.
Wat ik van io_uring weet is dat het nog lang niet afgewerkt is, en dat veel ontwikkelaar het momenteel te veel moeite vinden om het in een Run-Time System Application te integreren.
io_uring heeft ook nog altijd geen goede documentatie, zolang het dat niet heeft kan ik me niet voorstellen dat veel ontwikkelaars het gaan gebruiken.

Verder denk ik dat de performance van kqueue zo goed is dat io_uring in apps geen merkbare verbeteringen gaat kunnen bereiken.

Linux heeft in de laatste 15 jaar veel meer financiering gekregen dan BSD, maar het heeft nog altijd geen betere bestandssystemen, nog altijd geen betere prestaties in NGINX (de beste webserver), nog altijd geen hypervisor met beter geheugengebruik als bhyve, nog altijd geen betere audio stack dan OSS4, nog altijd geen snellere network stack dan die van FreeBSD, nog altijd niks dat de mogelijkheden heeft van 'Zones' op illumos, etc.

En Docker is trouwens minder goed op gebied van beveiliging dan FreeBSD Jails.

Dus al deze investeringen in Linux zijn grotendeels een grote geldverspilling geweest.

Ik denk dat Linux ook nooit zo goed zal worden als de oude Unix systemen waren, omdat er momenteel geen programmeurs meer zijn die even intelligent zijn als bvb een John McCarthy, Dennis Ritchie, Bjarne Stroustrup, James Gosling, Anders Hejlsberg, Brian Kernighan, William Jolitz, etc.

[Reactie gewijzigd door FateTrap op 25 juli 2024 21:32]

En Docker is trouwens minder goed op gebied van beveiliging dan FreeBSD Jails.
Erger nog: Docker is ontworpen als deployment tool. Niet als een security boundary. Vroeger werden bugs met "escapes" uit een docker container gewoon geclosed als won't fix. Tegenwoordig is dat anders maar security is letterlijk een after thought bij Docker en daarom is het ook nogal messy.
Als je nog budget over hebt wat op moet na het afnemen van de Oracle database ;)
Solaris licensie komt inbegrepen bij een Oracle Server. Voor non-Oracle hardware moet je het apart kopen, maar zover ik weet is het goedkoper dan een RHEL licensie.
Solaris containers / zones. Vele malen eenvoudiger op te zetten dan bijvoorbeeld Linux containers.
Mijn eerste gedachte was inderdaad: "Solaris, bestaat dat nog?"
@Burgertrut
Nog steeds op Sparc Processors alleen nu made by Fujitsu

https://www.fujitsu.com/g...eports/roadmap/index.html
@Burgertrut
Nog steeds op Sparc Processors alleen nu made by Fujitsu

https://www.fujitsu.com/g...eports/roadmap/index.html
Superdegelijk spul, maar wel uit 2017.

Het blijven supporten is slim, want voor sommige bedrijven draait hier software op waar niemand aan mag komen en lastig "even" te migreren is naar Linux..
Hahaha, is er nog steeds iemand die Solaris gebruikt?!

Ik heb het laatst meer dan 25 jaar geleden gebruikt geloof ik.
Het is grotendeels hetzelfde verhaal als met Pascal.

Hoewel Pascal heel oud is en zijn populariteit grotendeels verloren heeft, is Pascal nog altijd een betere all-round programmeertaal als bvb Python en JavaScript.

Niet enkel op gebied van het design van de programmeertaal, maar ook op gebied van prestaties en geheugengebruik.

[Reactie gewijzigd door FateTrap op 25 juli 2024 21:32]

Ik zal niet zeggen dat ik het met je oneens bent maar Pascal heb ik ook niet meer gebruikt sinds de jaren 90.

Waar ik het meest op tegen ben is dat we vandaag de dag achter allerlei "hypes" aanlopen zoals Angular en Vue.js, micro-services en cloud.

Nu gaat iedereen weer richting Rust omdat het energie efficiënter zou zijn. Die JavaScript frameworks blijken processortijd te vreten en dat is slecht voor de klimaatverandering loopt iemand weer te verkondigen.

[Reactie gewijzigd door Godson-2 op 25 juli 2024 21:32]

Node js is inderdaad heel traag. Ik weet niet of JavaScript met iedere interpreter zo traag is, maar de node js interpreter alleszinds wel.

Rust is inderdaad snel, maar het gaat voor veel mensen te complex zijn om te programmeren. Het is een redelijk moeilijke taal, en het heeft ook meer LOC (lines of code) dan sommige andere talen (= lagere productiviteit)

Voor het web, en voor de meeste andere domeinen is Common Lisp waarschijnlijk de beste optie aangezien het één van de allersimpelste talen is om aan te leren:

1) https://www.quora.com/How...than-say-NodeJS-+-Express
2) https://benchmarksgame-te...ormance/spectralnorm.html
3) https://www.reddit.com/r/..._java_rust_julia_dart_in/
Ik heb nog nooit iemand een LISP dialect zien aanpraten als simpel.
De hele tak van de functional languages wordt gemijd voor dezelfde reden.
Persoonlijk heb ik alleen ervaring met Common Lisp, Python en Julia, en ik vond Common Lisp het makkelijkste om aan te leren. Ik weet niet of het per se de meest compacte syntax heeft. Maar de syntax is compact en makkelijk te begrijpen (lezen) en vooral het makkelijkst van deze drie om te gebruiken. Heel het internet staat trouwens vol met mensen die beweren dat het simpel is om te leren en te gebruiken:

https://books.google.be/b...amming%20language&f=false
The syntax of Lisp programs is simple.

https://news.ycombinator.com/item?id=8016974
No. Lisp is actually the simplest programming language, and has no syntactic cruft. While it wasn't designed to be “easy to learn” like Swift, Python, Ruby, or Basic, there is less overall to learn and you will be writing real, useful programs in Lisp sooner than you could with other languages."

https://www.quora.com/Wha...isp-Is-Lisp-easy-to-learn
If you never programmed, Lisp would probably be easier to learn than most any other language due to its extremely simple syntax.

https://www.quora.com/Is-...ge-even-simpler-than-LISP

https://www.reddit.com/r/...ing_language_make_easier/
Lisp repl is way superior (specially in Common Lisp). You can write a function, compile it (that's right, compile one function, with C-c C-c in Emacs&Slime), have a feedback (a warning, or a debugger that pops up), and then try it in the REPL. Whereas in Python, you first need more tooling (flycheckers etc), you must have a way to run your code (a main function if it isn't a script), add a breakpoint if you want to stop in the middle of your program, and re-run it when you change the code. When an error occurs in Python, search for it manually, or improve your tooling (compilation mode in Emacs,…). In Slime, press v in the debugger and you get dropped on the line.

It's faster and less boring to develop in Lisp :)

Also, Lisp is a compiled language, so we can build an executable for any type of application, even a web app that ships its webserver, making it straightforward to deploy. Whereas in Python, you can sometimes but generally not.

https://carcaddar.blogspo...st-language-to-learn.html
Lisp's syntax is a great advantage because it is so simple to learn and has so few special cases. The interactive, iterative development style and real late-binding means you can build programs in parts and add to them as you go. The presence of real metaprogramming means you always have the ability to look at any part of your program and its state to find out what it's doing/what's wrong. The HyperSpec and Common Lisp The Language are two of the best programming language reference manuals ever written.

Persoonlijk denk ik dat Pascal, Common Lisp (SBCL) en Julia het beste evenwicht bieden op gebied van simpele leercurve voor basiskennis van de taal, productiviteit en prestaties.

Common Lisp is meestal iets sneller dan Java, maar kan in sommige situaties zelfs Rust en C aftroeven: http://gpbib.cs.ucl.ac.uk/gecco2006/docs/p957.pdf

Common Lisp is faster than C for large value sets.

At 25000 values, Common Lisp is 4.1 times as fast as the C version, and the compilation time is
88% of the total evaluation time.

[Reactie gewijzigd door FateTrap op 25 juli 2024 21:32]

Als je terug kijkt naar het artikel over de overname van Sun (uit 2009): Java en MySQL zijn sterk vercommercialiseerd. De Sun hardware (Sparc processor) is gemarginaliseerd, als daar nog wat van over is. En ja, Solaris, daar blijkt nu toch weer leven in te zitten.
Solaris zit mooi in elkaar, maar Linux heeft de strijd al lang gewonnen.

De laatste SPARC processor is in 2017 aangekondigd en Solaris 12 is dat jaar ook geschrapt.

Het is nu nog een beetje blijven ondersteunen wat er nog draait en de licenties en vendor lock-in zo lang mogelijk uitmelken.

Deze release heeft mogelijk nog wat PR waarde, maar de Solaris kennis in de wereld is zo schaars aan het worden dat het zo relevant is als betamax.
Solaris was toch voor Sparc processors? Waar draait het nu dan op?
Solaris is bij de weinige OS'en die zowel op little as big endian systemen werken. (en Linux natuurlijk ook). Nog AIX of HP-UX zijn beschikbaar voor little-endian (x86) architecturen.
Voor diegene die het niet wisten, een ZFS file systeem kan je zowel mounten op een little als een big endian systeem en laat dus toe om HD te wisselen tussen een SPARC en x86 systeem,
Sun verkocht later ook ook x86 😉
Ze hadden mooie bakken met een berg 64bit power van jewelste als je ze een halve ton gaf 😇
Dat is via een simpele Google-query vast te achterhalen ...
Nog steeds, op zowel Sparc als Intel: https://www.oracle.com/servers/

Op dit item kan niet meer gereageerd worden.