As someone who's never used Solaris or looked into its merits I'm curious: can someone comment on why all the nostalgia for Solaris?
You never really get over your first love.
The sudden death and eternal life of Solaris
91–100 of 279 posts
Re: The sudden death and eternal life of Solaris
#92Earlier quoted context omitted.
The Oracle rdbms was at least for a while unmatched. It had programmability, functionality, and tunability that no other database had. If you needed what it provided, and could afford it, there was no real substitute. Today, Postgres has come a long way, and distributed databases are much more developed. There is probably much less technical justification for using Oracle than there was 10+ years ago. Also many compa…
Uh, doesn't everything you do with a database reduce to CRUD? I understand that sometimes you do the composition of many CRUD operations, but this is still CRUD.
[deleted]
Re: The sudden death and eternal life of Solaris
#93Earlier quoted context omitted.
The Oracle rdbms was at least for a while unmatched. It had programmability, functionality, and tunability that no other database had. If you needed what it provided, and could afford it, there was no real substitute. Today, Postgres has come a long way, and distributed databases are much more developed. There is probably much less technical justification for using Oracle than there was 10+ years ago. Also many compa…
Uh, doesn't everything you do with a database reduce to CRUD? I understand that sometimes you do the composition of many CRUD operations, but this is still CRUD.
Literally everything you do with memory and disks can also be reduced to CRUD, but that is an extreme example to show my point: a DB does a lot more. A well written DB, in this case a good RDBMS, gives you stronger guarantees that data is saved and accessed in certain ways. That by itself is worth using a better one that gives you better guarantees.
But they also provide stronger typing and checking of the data. They provide a programming language neutral way to access the data quickly and efficiently. They index data to make queries on it faster. They do much of this automatically so you think it's all simple CRUD operations, but they also provide ways to explain what they're doing if it isn't working as expected. I can count the number of programs (not DBs) on my hand that I know of that can explain themselves accurately without needing a debugger.
Edit: I don't mean to be annoying. Most people on HN knew this and I'm not assuming you didn't, but while most people just use RDBMS for simple CRUD operations they're losing out on the power that these databases have been designed with.
Re: The sudden death and eternal life of Solaris
#94Earlier quoted context omitted.
I know many people mentioned dtrace, ZFS, mdb.. in describing Solaris' merits but it was not a very good OS in 1997 when I first got my hands on it. It was slow - the SPARC hardware didn't help and ZFS/MDB/Dtrace did not exist back then. But I think back then for Enterprises Solaris was the most easily accessible platform SPARC hardware came with and it had a good run for a short while. It was only when Linux started…
Ha -- isn't that ever the truth! When I came to Sun in 1996, Solaris was really good at only two things: scaling on SMP machines and not crashing while doing it. Morale wasn't necessarily high (the early history of Solaris had been brutal, and it had only been due to the budding success of 2.5 and UltraSPARC that engineers were beginning to feel forward-looking), and it took us several more years just to get the hous…
> scaling on SMP machines and not crashing while doing it
Yep - Only ever had one time when it hosed on us (100 people team, many running JVM based applications and some doing load tests on it - IIRC it was 2.6 days.) And there wasn't a challenger in sight as far as SMP goes(h/w and s/w both).
Re: The sudden death and eternal life of Solaris
#95Earlier quoted context omitted.
The Oracle rdbms was at least for a while unmatched. It had programmability, functionality, and tunability that no other database had. If you needed what it provided, and could afford it, there was no real substitute. Today, Postgres has come a long way, and distributed databases are much more developed. There is probably much less technical justification for using Oracle than there was 10+ years ago. Also many compa…
Uh, doesn't everything you do with a database reduce to CRUD? I understand that sometimes you do the composition of many CRUD operations, but this is still CRUD.
Not at all. RDBMS features were critical in getting performance and scale once upon a time. Sharding, access control, authentication, indexed views, fk relationships and other constraint enforcement, cascading updates and deletes, efficient data management with stored procs, caching, etc etc.
My first job was even writing dynamic web apps entirely in Informix.
Re: The sudden death and eternal life of Solaris
#96Earlier quoted context omitted.
Good old killall!
Which behaves differently on Solaris than Linux, of course. Linux killall kills specific processes but on Solaris it forcefully kills everything on the landscape...
It doesn't shut the machine down though, right? Just kills all the processes? I remember reading somewhere that solaris-killall was only a part of the shutdown process.
I remember having a related problem with an ubuntu cloud server a while back. I'd called 'halt' instead of 'shutdown' - they're not the same, and on this machine 'halt' didn't actually send the 'okay, now power off' bit.
Re: The sudden death and eternal life of Solaris
#97Re: The sudden death and eternal life of Solaris
#98I wouldn't call illumos "thriving". Commit activity[1] is low for a project of this size (compared to e.g. BSDs) and its hardware support is poor. Probably the biggest problem is the fact that all existing distributions are undermaintained and unpolished. SmartOS is the only exception, but it's not a replacement for Solaris which was a general-purpose server OS. SmartOS is merely a bare-metal hypervisor. I really hop…
Hardware support is by far the stupidest complaint that prevails when people talk about operating systems. Choose your hardware for your software, not the other way around. There are so many better things operating system authors have to do than to implement thousands of competing proprietary hardware interfaces. Mature support for even 50% of consumer hardware would take a massive team of full time engineers years to pull off, and would be wasted when that team could have been making huge strides and innovations in the parts of the OS that actually matter.
If your hardware isn't supported and you don't like it, get your ass into the code and build support for it.
Re: The sudden death and eternal life of Solaris
#99> ..employees who had given their careers to the company were told of their termination via a pre-recorded call — “robo-RIF’d” Every single first person or second hand account I've heard about Oracle makes like a terrible place to work... is this just people being hyperbolic, or is is truly that terrible?
> is this just people being hyperbolic, or is is truly that terrible? I'm on the outside looking in and don't have any special internal insight, but they didn't just pull this robo-RIF idea out of their ass spur-of-the-moment. Oracle is the kind of place that maintains a robo-layoff system , which pretty much says all you need to know. "What you think of Oracle is even truer than you think it is. There has been no en…
“We make money” - no truer words have been spoken. Hell, I work for a medical billing company and even our company mission has something about helping patients in it (and literally, our company sends bills and insurance claims to collect revenue).
Re: The sudden death and eternal life of Solaris
#100Earlier quoted context omitted.
Uh, doesn't everything you do with a database reduce to CRUD? I understand that sometimes you do the composition of many CRUD operations, but this is still CRUD.
Literally everything you do with memory and disks can also be reduced to CRUD, but that is an extreme example to show my point: a DB does a lot more. A well written DB, in this case a good RDBMS, gives you stronger guarantees that data is saved and accessed in certain ways. That by itself is worth using a better one that gives you better guarantees. But they also provide stronger typing and checking of the data. They…
Amen to everything you and arnarbi wrote.
However, I've come to dislike building business rules using the proprietary languages of the RDBMS vendors. In particular, I use Oracle and have been making a case with my employer to stop creating ties to Oracle by using PL/SQL as our house language. While it provides some efficiencies and can sometimes make coding easier, it can stifle development as easily.
I'm all for expressing data relationships in the RDBMS and using efficiency mechanisms like indexes and cost-based optimization. However, I now prefer business rules to be expressed outside the database.
[EDIT: Corrected anarbi to arnarbi.]