The sudden death and eternal life of Solaris
221–230 of 279 posts
Re: The sudden death and eternal life of Solaris
#222Earlier quoted context omitted.
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.
> once upon a time. 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... Do you think of better ways to handle this nowadays? Is it more effective/maintainable to do this in the app layer?
But I don't know, I don't really do this stuff anymore. At Google we certainly have storage and database systems with a lot of non-CRUD features (look at Spanner for example).
Re: The sudden death and eternal life of Solaris
#223Earlier quoted context omitted.
If Lem deserves a place among Gibson, I guess I gotta pick some up
I recommend starting with Solaris. The Futurological Congress is also a lot of fun; it's one of his comedies, a satiric look at futurism. His Master's Voice is advanced level Lem. It's less a novel than a fictional autobiography of a scientist, and while the subject matter is fascinating, it's a bit dry. The Cyberiad is a classic, but very different and not really sci-fi. It's a collection of absurd, surreal fairytal…
Like Blade Runner's relationship to Do Androids Dream of Electric Sheep, it was a lot different than the book, but shares some deep ideas, and stands on its own as a great movie.
The scene in the USC ICT's motion capture studio was riveting, with Robin Wright playing a partly fictionalized version of herself, and Harvey Keitel playing her agent, baring their souls to the giant emotion capturing machine.
https://en.wikipedia.org/wiki/The_Congress_(2013_film)
Re: The sudden death and eternal life of Solaris
#224https://www.theregister.co.uk/2010/12/07/mcnealy_sun_and_ope...
"One of the issues I had with one of the other suitors was there was a complete overlap in what they did and what we did, and I could see 100 per cent of the Sun employees getting fired," McNealy told us. He didn't name names, but he was referring to IBM's bid for Sun. IBM had competed heavily with Sun for decades on processors, servers, Unix, Java tools, middleware, and open source. There weren't too many areas where they didn't overlap.
"At least with Oracle, they weren't in the hardware business, the operating systems business — the places and spaces where I saw chance for some Sun employees to keep their jobs, and that for me was an important consideration," McNealy said.
Re: The sudden death and eternal life of Solaris
#225At the end of the day, Sun/Oracle has to be able to make revenue from Solaris for them to keep paying those peoples' salaries. Is your startup / company deploying on Solaris? Nope of course you aren't - who is?! Pretty much nobody nowadays - w3techs.com shows Solaris at 0.0005% for webservers for example. Everyone talks about how great it is(to be sure there are some small bits that are pretty dang amazing) - yet for…
if a company is using solaris, it likely host a Linux kernel and apache in virtualized containers to serve web content.
Re: The sudden death and eternal life of Solaris
#226Earlier quoted context omitted.
A different OS can solve some of the pain points of the mainstream options. Depending on your business, the features a different OS brings could have a large impact on performance or stability. Potential areas for improvement could be anything from filesystem to process concurrency to virtualization.
I'd see only the pain of migrating applications and learning new administration tools. Solaris was dead long before oracle killed it -- to me.
Things like:
* Java
* PHP
* Perl
* Python
* Ruby
* Apache
* Nginx
* Varnish
* MySqL
* Postgres
* Node.js
* etc
all run just fine on a Solaris-clone. Unless your app is using very specific kernel features it will probably work fine.Re: The sudden death and eternal life of Solaris
#227Earlier quoted context omitted.
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.
I remember being disgusted by the various halt, shutdown, reboot commands and so I learned what the various init run levels could do. That worked until I realized that Redhat and Debian set them up differently. At least init 0 is generally the same...
Re: The sudden death and eternal life of Solaris
#228Earlier quoted context omitted.
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 exp…
As someone working at a company that decided to write most of their SQL code at the application layer, there are definite tradeoffs. Our application performance suffers because of the fear of vendor lock-in and the flexibility others thought that writing code at the application level would provide. The question I pose to anyone consider this type of architecture is, how often do you switch database platforms?
Re: The sudden death and eternal life of Solaris
#229Earlier quoted context omitted.
The answer is almost never because the cost in time is too high for such a switch. It's the same question I posed 10 years ago. My view changed since coming to my current employer. I work for a moderate-sized university. The applications I support require up-to-date information in order to test modifications. They are read-intensive with few writes within the database. We can afford only one test database for the ent…
I understand the cost of switching now. Was Postgres never an option? Do the uptime requirements call for RAC etc.?
Re: The sudden death and eternal life of Solaris
#230Just ran across this: Scott McNealy's answer to "why didn't Sun sell to IBM": https://www.theregister.co.uk/2010/12/07/mcnealy_sun_and_ope... "One of the issues I had with one of the other suitors was there was a complete overlap in what they did and what we did, and I could see 100 per cent of the Sun employees getting fired," McNealy told us. He didn't name names, but he was referring to IBM's bid for Sun. IBM had…