Live data from Hacker News

The sudden death and eternal life of Solaris

dtrace.org

211–220 of 279 posts

Re: The sudden death and eternal life of Solaris

#211
post #204
post #168

Earlier quoted context omitted.

Oh, but I did preserve the structure. It's OP who doesn't understand how this grammatical construction works, and this particular mistake irritates me so much.

This preserves the structure better: > As someone who's never used Solaris [...] I'm curious: can someone [...] Notice that you left out the subject (I), left out the verb (am), and replaced a colon with a comma!

> Notice that you left out the subject (I), left out the verb (am), and replaced a colon with a comma!

No, I didn't left out anything important to the structure nor did I replace a colon with anything. The thing is that you and I were looking at two different sentences, because OP silently edited his comment (I only noticed that now). The original sentence was "As someone who's never used Solaris or looked into its merits, can someone comment on why all the nostalgia for Solaris?"

Re: The sudden death and eternal life of Solaris

#212

Earlier quoted context omitted.

How does running a different OS than most people can give a company an advantage? Can you elaborate this?

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.

Re: The sudden death and eternal life of Solaris

#213
post #100

Earlier 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?

Never. You have sufficient expertise to make the solution work and enough exposure to the code base to modify core if necessary. Oracle: never an option.

Re: The sudden death and eternal life of Solaris

#214
post #189

Earlier quoted context omitted.

See, once I actually started using pl/pgsql, I found it really powerful and a match for T-SQL. Never used PL/SQL though, so can't compare.

And which PostgreSQL developer editor can match SQL Server Management Studio? Because pgAdmin isn't it, specially after it became an Electron app.

Who actually uses these glorified IDEs? No one I've hired.

Re: The sudden death and eternal life of Solaris

#215
post #119

Earlier quoted context omitted.

I figure the connection is probably more about being from a company named "Sun," since it's a Latin word and the source of the English adjective "solar" for 'pertaining to the sun.'

And illumos is similarly named (Latin for illuminate).

And Eclipse was similarly named, just to annoy Sun.

Re: The sudden death and eternal life of Solaris

#216
post #100

Earlier 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?

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 entire university. We refresh the database from production only once a quarter, at most. My applications would benefit greatly by being able to switch URL's to the production database in order to test a mod. Since our code, written in PL/SQL, gets stored in the database that it runs on, we can't do such a thing without significant effort: dblinks or modifying package names to store in production for testing or a test schema or whatever else you can think up.

Another issue is that PL/SQL is not a robust language for modern development. Its type-system was designed for strictness, which is great in life-critical systems. But, there is no notion of inheritance and no ability to write generic collections.

To mimic inheritance, you can create objects backed by tables and inherit one from the other. It has the feel of being bolted on and yet another tie to Oracle.

One final issue is that PL/SQL is highly subject to the resource management of the Oracle kernel. Often, the kernel is extremely efficient. But, there are times when you need code running in a separate address space, preferably on a separate server. For instance, one application I wrote is a batch system that has a lot of processing rules built into it. Our database is tuned for OLTP. My application is categorized by the DBA's as data warehouse-oriented. Yet my application has to run hourly throughout the day and compete with resources necessary for the OLTP stuff. Putting it onto a separate server, away from Oracle's kernel management, would more than likely help a performance issue we have.

So, the answer to your question is the one you were looking for. But, my concern isn't necessarily switching database vendors.

Re: The sudden death and eternal life of Solaris

#217
post #4

Earlier quoted context omitted.

Soderberghs version is much more reflective of what happened with the emergence of OpenSolaris and Illumos (not to give away any spoilers but apparently forking is a real thing and it lives on). Tarkovskys movie was such a philosophical drivel that I feel asleep. How is the book - is it worth reading? As I understood it neither of films follow the novel very closely.

Stanislaw Lem deserves a much wider readership. Well, I say that but actually he has a wide readership, just not so much in English-language markets. Besides Solaris , his meditations on life and society in The Cyberiad remain some of my favourite science fiction of all time.

Thanks for such an interesting discussion! The Cyberiad is one of my favorites, a great way to get started, and very re-readable.

Michael Kandel was Lem's translator for many books including The Cyberiad -- including some brilliant poetry and plays on words!

He's such an excellent translator, it would be interesting to read other stuff he's translated! Any recommendations?

https://en.wikipedia.org/wiki/Michael_Kandel

Kandel is perhaps best known for his translations of the works of Stanisław Lem from Polish to English. Recently he has also been translating works of other Polish science fiction authors, such as Jacek Dukaj, Marek Huberath and Andrzej Sapkowski. The quality of his translations is considered to be excellent; his skill is especially notable in the case of Lem's writing, which makes heavy use of wordplay and other difficult-to-translate devices.

http://www.art.net/Studios/Hackers/Hopkins/Don/lem/HorribleP...

    Oft, in that wickless chalet all begorn,
    Where whilom soughed the mossy sappertort
    And you were wont to bong --
http://www.art.net/Studios/Hackers/Hopkins/Don/lem/Wonderful...

A love poem, lyrical, pastoral, and expressed in the language of pure mathematics. Tensor algebra mainly, with a little topology and higher calculus, if need be. But with feeling, you understand, and in the cybernetic spirit.

http://www.art.net/Studios/Hackers/Hopkins/Don/lem/Femfatala...

http://www.art.net/Studios/Hackers/Hopkins/Don/lem/Lem.html

Re: The sudden death and eternal life of Solaris

#218
post #93

Earlier quoted context omitted.

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…

>gives you stronger guarantees Your DB either supports ACID or it doesn't. The term "stronger guarantees" is snake oil. It's either guaranteed or is not. That simple.

Yes, but it's made by fallible people, who may make mistakes in previously good software you update to, and it assumes a computer doesn't fail which can still happen (although very rarely now).

Re: The sudden death and eternal life of Solaris

#219
post #2

I always thought Solaris was a beautiful and memorable name for an operating system. Any connection with the Stanislaw Lem novel (or Tarkovsky movie) was always a bit unclear to me... But I guess a book about futile interactions with a planet-sized alien brain that doesn't care about you other than mysteriously experimenting with your memories is a reasonable metaphor for the Unix user experience.

Beautiful name indeed. Happy memories of trying out Solaris 8 x86 on a Celeron with 64MB.

Re: The sudden death and eternal life of Solaris

#220
post #216

Earlier quoted context omitted.

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?

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.?
Post reply on HN