Slashdot Mirror

An API call in programming use is something like this:

| return type | |Name of function| ( |arguments given to function| );

In general overview, an API call looks like this:
1. (Do some work / task)

2. (Ask some library to do some work / task for us.) (This is the API call.)

3. (Do some more work / task possibly using the result of the API Call.)

For the in general overview, Java has not copied anything more than C++, Smalltalk, or any other language.

For the actual in programming use however it has copied somethings. This is because of the limited nature of the syntax. Put simply, although you can call a string container object "sighpghpjg234fy3r85q83", and expect people to use it when they need a string container object, that does not mean it makes sense to the programmer, is easy to remember, or maintain. Most programmers would expect a string container object to be some deviation of the word "string". As such many languages wind up coping some portion of the API of other languages with just the names of things. For example
std::string.length() in C++, has an exact copy in Java, String.length(). Both API calls do the same thing, (returns the length of the given string), and therefore is a literal copy. (See: For java and For C++)

Sometimes functionality for a given API call is identical between languages, but with different names depending on the exact language in question. For example: std::string.find() in C++, has an exact copy (functionality wise) in Java's String.indexOf() call. Both calls do the same thing, (return the starting index of a search term in a given string), the only difference is the name of the function itself. (find() VS. indexOf()) (See For java and For C++)

Now of course, to a computer all of this is irrelavent. All a computer sees is some variant of:
(system-defined jump / execution branch opcode) (destination address) (result storage address)

It depends on the system in question, but the overall result is always the same. The system jumps to the given address, executes the code it finds there, and when that code finishes, returns to the instruction that comes after the API call, and continues execution from that point. You could easily call an API function: "fksjfisijf" and the system will not care at all, because all it will see is: "0101010101 01011010 101010101010". The API call is just a human mnemonic for what a given function does so it's easier to remember and use for a programmer.

The only exception to this is when dynamic code is used. As that tends to require a parser at runtime, (a dynamic loader), to locate the API call's starting address in a table so that the program can use it. The program itself must know what API call to refer to, so that the loader can find it. The API library must also remain consistent (i.e. not change the API call) so that the loader can find the starting address for the API call that the program needs. If either of these is not true, the program will crash (due to an invalid address, argument, etc.), or it will not run / compile. (due to a link error.)

From a practical stand point, there is not (or rather shouldn't be) an issue. As the whole debate over coping an API call "design" or "expression" is entirely a human concept. Once again, although dynamic code can be used in a program, the computer itself does not care what you call it so long as the call does not change.

From an "Artistic" standpoint, you can't change the "expression of the idea" for an API call and expect it to work. (A computer DOES care about this.) You *could* create a new language every single time you needed to write a program, but you would have difficulty making it u

Standard disclaimers apply: I am not a lawyer and this should not be construed as legal advice.

First, you don't steal titles from an existing work. Stealing has a very specific legal definition and in the context of law commentary, it's very important that you don't fuck it up.

Second, yes, using the same titles is, in fact, okay.

Third, that specific licenses allow you to use interfaces or not explicitly is irrelevant. Copyright enforces the wishes of the copyrighter in how distribution works. Unless you have some evidence that the Java platform is licensed in this way, this point is completely irrelevant. And it seems to me that you might be hoisted upon your own petard.

Fourth, what does it take to be a standard in your mind? What is your opinion on the Java platform documentation? Because it seems pretty well-specified to me. Java also has a language and VM spec that are published specifications. How do "oversight organization" and "corporate entity" automatically differ?

Instead, they chose the more sophisticated approach of type erasure - which added a lot of complexity, limitations, and even introduced the concept of compile-time warnings in the Java language - not because of backwards compatibility (adding new kinds of bytecode to the JVM is OK and it happens occasionally), but because they wanted indefinite interoperability between old code (which would see the collection objects “raw”) and new code (which would see the very same objects “generified”).

Now academics universally despise type erasure, but back then at least half of them thought that it was a good idea and you can still see it today if you search the web for their blog posts of the time, where they explained the tricks that they used to overcome the limitations of type erasure and why type erasure wasn't so bad after all.

Lists use At(). Hashmaps use Get().

Uh... what? https://docs.oracle.com/javase...

> I mean intuitively shouldn't toString() on a stream get back a string?

Yes it should return a String (enforced by polymorphism) but not the String you imply.

From the API

Returns a string representation of the object. In general, the toString method returns a string that "textually represents" this object. The result should be a concise but informative representation that is easy for a person to read.

So your String should be a description of the InputStream, not its contents.

For example: "InputStream for URL: http://google.com/" or whatever satisfies the concise informative representation that is easy for a person to read.

And if you want to pay for it, Oracle has been doing it already, too.

Microsoft is doing what they always do, try to catch up by buying out some tech. Too bad it was RR, some of their stuff was nice and it probably means their free contributions will be EOL-ed.

I don't think so. They have only just added lambdas in Java 8 (which is something that C# has first got in 2.0 in 2005, and in the form more or less equivalent to what Java has, in 3.5 in 2008). And even then some of the stuff that goes along with it is hilariously bad, like their insistence on type erasure for generics, and the associated requirement to have dozens of interfaces to cover the most basic function types for the most common primitive types. In the meantime, C# is still actively evolving, gaining feature such as "dynamic" (opt-in duck typing) in 4.0, and async/await syntactic sugar for callbacks in 5.0.

Oracle has features like Edition-Based Redefinition for this job. They are a lot more work for the simple job of transactional DDL.

There's an old but accurate at the time page comparing this feature across databases at Transactional DDL in PostgreSQL: A Competitive Analysis.

What I hear you saying is that if I buy a coffee maker from a company and the company goes out of business, the company actually still exists because the coffee maker still exists.

Almost. In your story the key thing isn't that the coffee maker still exists but that it's still being sold in some form using the old brand name.. At the moment that the coffee maker is no longer being sold, the brand disappears, and the coffee maker exists only on somebody's shelf or in a museum, the coffee maker company truly is defunct.

A good example of this is Studebaker, which morphed into American Motors, which morphed into Chrysler, which morphed into Daimler Benz, which morphed back into Chrysler. You can still find Studebakers in garages and museums and maybe even on the road, but "Studebaker" certainly is defunct.

In any event, the meaning of words is just a matter of semantics. YMMV.

Here's an example of the sort of thing I'm talking about that indicates (to me, at least) that Sun is far from defunct.

Oracle bought it. Still surprised?

Not only that, but Oracle bought it on July 21, 2011. The current version of Ksplice? Released on July 28, 2011. The major feature of the current release? The changelog says the only change was "Removed unnecessary zlib detection from configure." But now only Oracle Linux is supported.

It's still available through source code, which you can find with a bit of digging (you can't navigate to it from the top level page, as far as I can tell... Ksplice isn't listed as a project). I think the amount of investment and effort put in that site makes it clear what Oracle's stance is.

At least Microsoft extends before they extinguish....

Well, if you consider a 5-year public SPARC roadmap from both Oracle and Fujitsu "committed" then clearly they appear fully committed to SPARC. I doubt either company would put their reputations on the line publicly if they didn’t have serious investments to back it up. Could you imagine the repercussions should they not release what they state in here? http://www.oracle.com/us/produ... http://www.fujitsu.com/global/... And of course, theres many other SPARC developers still developing: www.SPARC.org, many of which are based on OpenSPARC http://www.oracle.com/technetw... Intel never released a long term public roadmap for Itanium and once HP stopped/slowed down paying Intel, was just a matter of time before it died off.

Well, if you consider a 5-year public SPARC roadmap from both Oracle and Fujitsu "committed" then clearly they appear fully committed to SPARC. I doubt either company would put their reputations on the line publicly if they didn’t have serious investments to back it up. Could you imagine the repercussions should they not release what they state in here? http://www.oracle.com/us/produ... http://www.fujitsu.com/global/... And of course, theres many other SPARC developers still developing: www.SPARC.org, many of which are based on OpenSPARC http://www.oracle.com/technetw... Intel never released a long term public roadmap for Itanium and once HP stopped/slowed down paying Intel, was just a matter of time before it died off.

SPARC T5 is 6% faster/core and with more cores, that means more powerful CPU. But, I think at the end of the day, its not how many threads, how many cores, or even how much cache, but how well does the CPU and especially system perform, how much does it cost to buy and run and how much does it cost to manage over its lifecycle. Sure, SPARC may have "more" cores that some say are "simpler" (I disagree), but the architecture is what matters and SPARC T5 with 16-cores and 8-threads per core, on a per CPU basis, delivers about 70% faster performance socket to socket vs x86 and therefore you need smaller SPARC system with fewer CPUs to deliver equivalent performance. And when you look at the management and lifecycle costs, that’s when SPARC shows its true advantages. Heres a decent report from an analyst I found highlighting this value. http://www.oracle.com/us/produ...

java script developer expert

Are you referring to import javax.script.*

This way you'll get a feel as to whether there's a hope that they can at least make a start at adapting the right library to your needs. You can even do it with her as the other part of a "pair"; this way, you can discuss the thinking behind her decisions at any point and then maybe discuss other solutions, or how she would attack other problems. You also get a feel as to whether the candidate is a good fit with your other people.

The Dell server is actually running a Sybase product, which is 98% slower than the SPARC benchmark. It is the newest entry on the list.

If you want an inexpensive database, you might look at Oracle XE, which is free. However, it has some rather tight constraints and limitations, and it only runs on x86.

"Free". Unless you have plans to upgrade to full blown Oracle at some point in the future, I see no reason why you shouldn't be using Postgres instead.

The Dell server is actually running a Sybase product, which is 98% slower than the SPARC benchmark. It is the newest entry on the list.

If you want an inexpensive database, you might look at Oracle XE, which is free. However, it has some rather tight constraints and limitations, and it only runs on x86.

Most of Java's problems lie with the fact that the designers of its original API made some unbelievably bad decisions early in its development. Like:

* specifying arguments as int or String values, instead of enums... so every method you called that explicitly needed UTF8 had to be surrounded with try/catch (just in case you couldn't remember whether Java wanted you to call it "UTF-8", "UTF_8", or "UTF8" & threw an UnsupportedEncodingException). This particular thorn in my side was FINALLY fixed as of JDK 7.

Before anyone points out that enum is a semi-recent addition to Java, I'd like to remind everyone that even in 1996, you could declare a class with a private constructor, then use it to declare public static final constants of itself that were defined by their own declarations (which, I believe, is what 'enum' actually does behind the scenes, anyway)

* Pre-JDK8, Java's handling of nearly everything related to the concept of a Date/Time (parsing, printing, calculating, the works) was completely fucked. -- http://www.oracle.com/technetw...

* Swing (Enough said. It speaks for itself... and does it almost as loudly and proudly as AWT.)

Even MORE tragic, though, is the way Android's API architects perpetuated the EXACT SAME anti-patterns (string/int constants as args) with the Android API... including brand new framework classes that didn't exist until Android did & had NO REASON to be that way.

Disclaimer: The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

TL;DR: I am an Oracle employee. It's an awesome place to work with above market pay, superb benefits, and a demanding but rewarding engineering culture. Virtualbox is one project in a large and growing virtualization team, creating and improving some truly amazing cutting-edge technologies that make your virtualization life better.

I'm going to share some facts as I see them, and let you draw your own conclusions instead of drawing them for you.

1. The Oracle VM and Oracle VM Virtualbox teams are one and the same within Oracle. There's a lot of cross-pollination of ideas and effort, and the virtualization team is frakking huge: HUNDREDS of developers. Not "4", as some have asserted here!
2. There's a ton of stuff happening in virtualization at Oracle: https://blogs.oracle.com/virtu...
3. There's a substantial line-up of products that are demo'd to customers as part of "Virtualbox Appliances". Virtualbox demos are a key strategy for introducing many of our products to customers. http://www.oracle.com/technetw... .
Corrollary: I manage a lot of ZFS appliances. I like them; they make my job easier, particularly at the kind of scale at which one begins measuring one's storage in exabytes. You should download the Virtualbox-based Oracle ZFS Storage Simulator and check it out. Hint: Dig into the REST interfaces and ECMAscript workflows concepts. This kind of thing is Stored Procedures for enterprise-grade storage appliances with absolutely blistering scale, reliability, and performance, and if you don't yet understand how powerful that idea is, you might be insufficiently experienced in high-end storage and databases.
4. Wim Coekaerts is a smart, friendly, and communicative dude. He also happens to be SVP over our Linux & Virtualization efforts. If you're really interested in the details of virtualization development at Oracle, you should check out his blog: https://blogs.oracle.com/wim/

Next, my opinions. No longer facts!

VirtualBox is a mature, stable product that's doing its job and -- as a GPL project -- seems to me like more a vehicle for showcasing Oracle technology than a revenue generator in its own right. That doesn't mean development has ceased! It just means that, in general, Oracle engineering teams are laser-focused on how we can make money so we can stay employed so we can keep creating really unique and useful products for our customers. Responsibilities on teams shift as need demands, and with such an enormous knowledge base in virtualization on our Engineering staff, there's no question that if a product needs a feature to benefit customers, and a good case can be made that it'll pay off, it gets the engineering resources it needs to give it a try.

The Sun transition was tough for some employees. In advance of the merger, a lot of old-timers split. A lot of younger engineers went looking for somewhere hipper and younger to work than what would become a Fortune 500 company. Many Sun managers, sensing the change in the wind as Oracle's intensely results-oriented management team integrated with them, split for positions elsewhere.

I know and work with the survivors of the merger every day. And overwhelmingly, those who've integrated into Oracle culture, shown they belong here through their productivity and attitude, and produce results consistently have built success upon success, and are valued and rewarded.

They're also a bunch of brainiacs who routinely blow my mind with deep insights into operating systems, hardware, and performance optimization.

Those who don't deal well with rapid change, high expectations, and a dogged focu

Disclaimer: The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

TL;DR: I am an Oracle employee. It's an awesome place to work with above market pay, superb benefits, and a demanding but rewarding engineering culture. Virtualbox is one project in a large and growing virtualization team, creating and improving some truly amazing cutting-edge technologies that make your virtualization life better.

I'm going to share some facts as I see them, and let you draw your own conclusions instead of drawing them for you.

1. The Oracle VM and Oracle VM Virtualbox teams are one and the same within Oracle. There's a lot of cross-pollination of ideas and effort, and the virtualization team is frakking huge: HUNDREDS of developers. Not "4", as some have asserted here!
2. There's a ton of stuff happening in virtualization at Oracle: https://blogs.oracle.com/virtu...
3. There's a substantial line-up of products that are demo'd to customers as part of "Virtualbox Appliances". Virtualbox demos are a key strategy for introducing many of our products to customers. http://www.oracle.com/technetw... .
Corrollary: I manage a lot of ZFS appliances. I like them; they make my job easier, particularly at the kind of scale at which one begins measuring one's storage in exabytes. You should download the Virtualbox-based Oracle ZFS Storage Simulator and check it out. Hint: Dig into the REST interfaces and ECMAscript workflows concepts. This kind of thing is Stored Procedures for enterprise-grade storage appliances with absolutely blistering scale, reliability, and performance, and if you don't yet understand how powerful that idea is, you might be insufficiently experienced in high-end storage and databases.
4. Wim Coekaerts is a smart, friendly, and communicative dude. He also happens to be SVP over our Linux & Virtualization efforts. If you're really interested in the details of virtualization development at Oracle, you should check out his blog: https://blogs.oracle.com/wim/

Next, my opinions. No longer facts!

VirtualBox is a mature, stable product that's doing its job and -- as a GPL project -- seems to me like more a vehicle for showcasing Oracle technology than a revenue generator in its own right. That doesn't mean development has ceased! It just means that, in general, Oracle engineering teams are laser-focused on how we can make money so we can stay employed so we can keep creating really unique and useful products for our customers. Responsibilities on teams shift as need demands, and with such an enormous knowledge base in virtualization on our Engineering staff, there's no question that if a product needs a feature to benefit customers, and a good case can be made that it'll pay off, it gets the engineering resources it needs to give it a try.

The Sun transition was tough for some employees. In advance of the merger, a lot of old-timers split. A lot of younger engineers went looking for somewhere hipper and younger to work than what would become a Fortune 500 company. Many Sun managers, sensing the change in the wind as Oracle's intensely results-oriented management team integrated with them, split for positions elsewhere.

I know and work with the survivors of the merger every day. And overwhelmingly, those who've integrated into Oracle culture, shown they belong here through their productivity and attitude, and produce results consistently have built success upon success, and are valued and rewarded.

They're also a bunch of brainiacs who routinely blow my mind with deep insights into operating systems, hardware, and performance optimization.

Those who don't deal well with rapid change, high expectations, and a dogged focu

Disclaimer: The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

TL;DR: I am an Oracle employee. It's an awesome place to work with above market pay, superb benefits, and a demanding but rewarding engineering culture. Virtualbox is one project in a large and growing virtualization team, creating and improving some truly amazing cutting-edge technologies that make your virtualization life better.

I'm going to share some facts as I see them, and let you draw your own conclusions instead of drawing them for you.

1. The Oracle VM and Oracle VM Virtualbox teams are one and the same within Oracle. There's a lot of cross-pollination of ideas and effort, and the virtualization team is frakking huge: HUNDREDS of developers. Not "4", as some have asserted here!
2. There's a ton of stuff happening in virtualization at Oracle: https://blogs.oracle.com/virtu...
3. There's a substantial line-up of products that are demo'd to customers as part of "Virtualbox Appliances". Virtualbox demos are a key strategy for introducing many of our products to customers. http://www.oracle.com/technetw... .
Corrollary: I manage a lot of ZFS appliances. I like them; they make my job easier, particularly at the kind of scale at which one begins measuring one's storage in exabytes. You should download the Virtualbox-based Oracle ZFS Storage Simulator and check it out. Hint: Dig into the REST interfaces and ECMAscript workflows concepts. This kind of thing is Stored Procedures for enterprise-grade storage appliances with absolutely blistering scale, reliability, and performance, and if you don't yet understand how powerful that idea is, you might be insufficiently experienced in high-end storage and databases.
4. Wim Coekaerts is a smart, friendly, and communicative dude. He also happens to be SVP over our Linux & Virtualization efforts. If you're really interested in the details of virtualization development at Oracle, you should check out his blog: https://blogs.oracle.com/wim/

Next, my opinions. No longer facts!

VirtualBox is a mature, stable product that's doing its job and -- as a GPL project -- seems to me like more a vehicle for showcasing Oracle technology than a revenue generator in its own right. That doesn't mean development has ceased! It just means that, in general, Oracle engineering teams are laser-focused on how we can make money so we can stay employed so we can keep creating really unique and useful products for our customers. Responsibilities on teams shift as need demands, and with such an enormous knowledge base in virtualization on our Engineering staff, there's no question that if a product needs a feature to benefit customers, and a good case can be made that it'll pay off, it gets the engineering resources it needs to give it a try.

The Sun transition was tough for some employees. In advance of the merger, a lot of old-timers split. A lot of younger engineers went looking for somewhere hipper and younger to work than what would become a Fortune 500 company. Many Sun managers, sensing the change in the wind as Oracle's intensely results-oriented management team integrated with them, split for positions elsewhere.

I know and work with the survivors of the merger every day. And overwhelmingly, those who've integrated into Oracle culture, shown they belong here through their productivity and attitude, and produce results consistently have built success upon success, and are valued and rewarded.

They're also a bunch of brainiacs who routinely blow my mind with deep insights into operating systems, hardware, and performance optimization.

Those who don't deal well with rapid change, high expectations, and a dogged focu

Disclaimer: The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

TL;DR: I am an Oracle employee. It's an awesome place to work with above market pay, superb benefits, and a demanding but rewarding engineering culture. Virtualbox is one project in a large and growing virtualization team, creating and improving some truly amazing cutting-edge technologies that make your virtualization life better.

I'm going to share some facts as I see them, and let you draw your own conclusions instead of drawing them for you.

1. The Oracle VM and Oracle VM Virtualbox teams are one and the same within Oracle. There's a lot of cross-pollination of ideas and effort, and the virtualization team is frakking huge: HUNDREDS of developers. Not "4", as some have asserted here!
2. There's a ton of stuff happening in virtualization at Oracle: https://blogs.oracle.com/virtu...
3. There's a substantial line-up of products that are demo'd to customers as part of "Virtualbox Appliances". Virtualbox demos are a key strategy for introducing many of our products to customers. http://www.oracle.com/technetw... .
Corrollary: I manage a lot of ZFS appliances. I like them; they make my job easier, particularly at the kind of scale at which one begins measuring one's storage in exabytes. You should download the Virtualbox-based Oracle ZFS Storage Simulator and check it out. Hint: Dig into the REST interfaces and ECMAscript workflows concepts. This kind of thing is Stored Procedures for enterprise-grade storage appliances with absolutely blistering scale, reliability, and performance, and if you don't yet understand how powerful that idea is, you might be insufficiently experienced in high-end storage and databases.
4. Wim Coekaerts is a smart, friendly, and communicative dude. He also happens to be SVP over our Linux & Virtualization efforts. If you're really interested in the details of virtualization development at Oracle, you should check out his blog: https://blogs.oracle.com/wim/

Next, my opinions. No longer facts!

VirtualBox is a mature, stable product that's doing its job and -- as a GPL project -- seems to me like more a vehicle for showcasing Oracle technology than a revenue generator in its own right. That doesn't mean development has ceased! It just means that, in general, Oracle engineering teams are laser-focused on how we can make money so we can stay employed so we can keep creating really unique and useful products for our customers. Responsibilities on teams shift as need demands, and with such an enormous knowledge base in virtualization on our Engineering staff, there's no question that if a product needs a feature to benefit customers, and a good case can be made that it'll pay off, it gets the engineering resources it needs to give it a try.

The Sun transition was tough for some employees. In advance of the merger, a lot of old-timers split. A lot of younger engineers went looking for somewhere hipper and younger to work than what would become a Fortune 500 company. Many Sun managers, sensing the change in the wind as Oracle's intensely results-oriented management team integrated with them, split for positions elsewhere.

I know and work with the survivors of the merger every day. And overwhelmingly, those who've integrated into Oracle culture, shown they belong here through their productivity and attitude, and produce results consistently have built success upon success, and are valued and rewarded.

They're also a bunch of brainiacs who routinely blow my mind with deep insights into operating systems, hardware, and performance optimization.

Those who don't deal well with rapid change, high expectations, and a dogged focu

https://cloud.oracle.com/

or you can just buy it from oracle. they have 2 types of kit. one has a wheelmouse, the other has a 3 button mouse:

https://shop.oracle.com/pls/os...

ipadm doesn't do DNS.

SMF does, and it's obnoxiously bad for just setting DNS.
http://docs.oracle.com/cd/E238...

Seriously, what's the big news here?

They have been pushing out bundled security patches every quarter for years with their Critical Patch Update program. This is just another CPU.

Since it seems to be something of a secret to most people, I remind folks that if you want clean Java updates that are free of Ask-toolbar bundles, get them from the developers page here (end user would probably just want the JRE download):

http://www.oracle.com/technetwork/java/javase/downloads/index.html

I've known of this link for years and only ever download Java updates from it, to the point where I was totally confused for a long time with people complaining about bundled toolbars that I never ever saw.

Here you go: http://www.oracle.com/technetwork/systems/opensparc/index.html. Not HDL, or even the CPU: https://github.com/open-power. Free graphics is another thing, but wasn't there a GPL FPGA based display controller somewhere?

For what it's worth, I always get my Java updates from here:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

I learnt about this link because I needed the JDK, but you can get the end-user JRE here as well. The benefit of this link is the installers don't have the Ask toolbar. I've been getting them from here for so long that I honestly didn't understand what people were complaining about regarding some toolbar that I never encountered.

Huh OK. Do you have a link?

I'ts called 'priority queue.' Every java object has a hash and equals method that can be overridden. And it's not like I love Java.

Java's unicode support is a bit half-arsed - they started out making all characters take two bytes because back then that was enough to cover all unicode characters, but then the standard changed and they got stuck having to shoehorn wider characters into their system in a way that usually works but is sometimes blunder-prone. That said, it's certainly miles better than what C / C++ have to offer (which is almost nothing natively.... std::string("köttur")[5] is "u", not "r", and the same happens with char*).

I know nothing about .NET.

Python 2 was bloody awful, it gives you just enough rope to hang yourself. Python 3 is a big improvement, fairly tolerable.

FYI Java 8 includes a new date library, so that problem is fixed.

Reading the blog, he would not have been fired for using the gendered pronoun, but for refusing to accept it being changed.

It's important. If you don't think it is, try looking for any gendered pronoun in (say) the Eclipe Documentation (Think IBM) or in the Java Tutorial (think Oracle).

And no, I haven't looked at it in depth, but I trust both IBM and Oracle to use gender neutral pronouns (except for the rare cases when they want to specify the gender of a person, as in "Alice" or "Bob"). What is good enough for IBM and Oracle (and every other corporation out there) is good enough for Joyent.

Wikipedia's comparison of RDMS's

Oracle's comparison of MySQL and the Oracle database

Can't get much clearer than that.

As to performance, I'd say it varies by application/configuration. I don't use Oracle myself, but last I heard, MySQL performed better in low-resource scenarios.

It's kind of tough to define "SCO" in a way that predates 1988, but okay.

Yes, Android implements both the Java Language Specification and some lower level stuff (is a copy of Java, arguably) .
So let's have a look at the license related to that:
https://docs.oracle.com/javase...

Note it says you may not implement the spec because that would be copying Java, you may make copies of the documentation for certain purposes.

Linux implements part of POSIX. Have a look at that license.

Disclaimer: I work for Oracle but not in sales nor in any branch related to this product.

At the office (where I work as a senior iOS / OS X native app developer), we have Oracle SSO running on all of our internally-deployed apps, including web sites, desktop apps, mobile.

OP talks of holy grail of IT so, while I dont know of alternatives, based on my experience, it's quite possible to have a decent single sign-on system.

Obviously, Oracle's offering is not free (as in beer speech) at 85$ a seat. It's best to contact the sales rep to see if any bulk or student pricing apply (I do not know as I'm not in sales).

In which case a nanny process restart is useless. Thanks for making my point, idiot.

Your logic is flawed. Random bit flips sometimes happen. They don't necessarily take down the whole machine.

Do the police employ oracles or futurologists?

It certainly seems so.

Actually, so far...I've not found any jobs that required any Oracle DBA certification as a requirement for work. Maybe for starting out, but for me, job resume experience is what sells you.

I've never been certified, I've taken the classes in the past, but never got around to taking the actual exam, and I've never found it to be a job requirement, nor pay amount factor.

I'm pretty much contracting only these days, so maybe the more beginner W2 jobs value this more, but for now, I find that in general, Oracle Certs are about as worthless as MS certified engineer credentials. You just don't need them really.

Oracle Partners jobs require certs. This is of course all marketing, but marketing is lucrative.

All you need to do is take a couple of upgrade exams, and pink unicorns will bombard you from the sky with suitcases of sparkly cash.

See the alternate method at the bottom of this doc.

Java also has a decimal type, though without operator overloading it isn't as pleasant to work with.

http://docs.oracle.com/javase/...

You're falling into a nasty human nature trap of self importance there.

You claim that anybody without the same math degree as you must be a fool because they do not know everything you know. Here's a hint: they aren't idiots and you don't know everything that they know either. Does that make you a fool to them in their eyes? Or just some arrogant tool?

Instead of insulting people (let's call them natural sciences grad students) perhaps try to educate them about the nature of floating point calculations by pointing them to documents like this:

http://docs.oracle.com/cd/E199...

Calling them idiots indicates that you don't know the difference between ignorance and stupidity. Ignorance can be cured by education and the ignorant person may in fact be much smarter than you are, they just need to be taught about this particular trivia.

And the best way is to open up an Excel spreadsheet and demonstrate to them a particular calculation with a simple analytical answer where Excel gets it badly wrong. Even if they learn nothing about the underlying FPU and all they come away from it with is "Excel sucks use Matlab instead" it's a win. Show them the sore thumb. Write a blog post about it and you could become famous like the OP.

Perhaps XKCD already has one.

I applaud the fine examples and explanation in your post, the manner of delivery could sure use some work though. (there's an oblig. XKCD for that too)

All other major unix server vendors ditched sysv init for the same reasons as I state long ago.

That's interesting. I looked up AIX, and it looks like they still have init with an inittab. And So does Solaris. From what I can tell, your claim that major Unix vendors have moved on from the traditional init system is also false.

Those Solaris documents linked relate to Solaris 9, which is pretty much EOL by now (goes mostly end of support thios month).

Solaris 10 included SMF (Service Management Framework) when it was released nearly ten years ago, and unfortunately SMF is an init system replacement.

Except that RC init wasn't fine. More than a few times over the years I've had a service that wouldn't start right on a server that actually prevented boot! Whether it was some stuck PID file that wasn't properly erased on boot, or some other race condition (often a network condition, or a chicken/egg problem),

...it was actually an init script problem, and not a problem with sysvinit at all. Your init script must not assume that /tmp has been cleared before run. When it finds a PID file, it must not blindly trust it. This sort of problem would be readily solved by simply unifying init scripts based on some sort of well-crafted template, but instead we have a daemon to fix the problem.

Ideally none of this should ever happen, but it did. Bugs are there.

Explain how systemd prevents bugs.

Combine that with the fact that init scripts are huge, fragile, hacks

Let's take a look at your three claims.

First claim, init scripts are huge. No, most init scripts are quite small. Sometimes they source a library, but there's nothing wrong with that. The replacement (systemd+unit files+required libraries) is still larger than (sysvinit+init scripts+script libraries). So this claim is clearly false.

Second claim, init scripts are fragile. Init scripts are not fragile. Some people are very lazy scripters. Some init scripts are well-written and they are fault-tolerant. Some init scripts are not well-written, and distribution maintainers should have remodeled them after ones which were. Distributions should have solved this problem by unifying init scripts. I have made the point elsewhere that a simple hashbang and shell script-based processor could permit using unit files as shell scripts, at least for long-running daemons. So this claim is also false.

Third claim, init scripts are hacks. Shell scripting is a central feature of Unix. Therefore, init scripts are not hacks. This claim is also false.

Everything you have claimed about init scripts is false.

As a system administrator I'd far rather mess with a simple ini file to create services than hack a huge bash script,

As a system administrator I'd far rather mess with a simple script file than have to debug the system that's supposed to interpret the unit files. With a shell script, I can simply run the script with -x and see precisely what is happening, even if all I have is a command line and 80x25. With a daemon interpreting a file, I may be lucky enough to get useful information out of strace, or I may have to load a debugger to actually see why my daemon isn't starting.

All other major unix server vendors ditched sysv init for the same reasons as I state long ago.

That's interesting. I looked up AIX, and it looks like they still have init with an inittab. And So does Solaris. From what I can tell, your claim that major Unix vendors have moved on from the traditional init system is also false.

Systemd has been in production a fairly long time now, and I see no issues at all brought up about it in actual practice.

Either you haven't been following the discussions here on Slashdot on this subject, or you are a liar. There have been numerous examples in these threads by actual systems administrators who have encountered actual problems with systemd. So while your claim might be true, it points only to your ignorance due to inexperience and lack of investigation.

Uselessd is a validation of the systemd approach. They clearly also believe that init is broken, or they wouldn't be working on the uselessd fork.

This is also false. They believe that systemd is broken, which is why t

With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.

You can do this with Java too.

I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion.

Why crash when you can catch such errors and recover?

In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz.

I thought you said sane C++ doesn't leak resources?

With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.

You can do this with Java too.

I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion.

Why crash when you can catch such errors and recover?

In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz.

I thought you said sane C++ doesn't leak resources?

With a sanely written C++ program (merely sticking to the modern approaches) memory and resource leaks are a thing of the past, but you still get the completely predictable and deterministic resource management of C.

You can do this with Java too.

I'm sadly working with Java services now, and we have a seriously problem in that there's no reasonable way to tell that a Java program is getting close to crashing due to memory exhaustion.

Why crash when you can catch such errors and recover?

In C++, you can just monitor heap size, and alarm based on values and trends and all that good predictive jazz.

I thought you said sane C++ doesn't leak resources?

You know that you can do that with the PhantomReference, SoftReference, WeakReference classes?
http://docs.oracle.com/javase/...
clear() Clears this reference object.

By my reading of the try-with-resources thing is you still have to type out that block. It's more lines of code you have to type that the compiler can do for you in C++.

Sure you can remember to do try-with-resoruces, just like you can remember to call fclose(). But every special case you have to remember and every line you have to type is another source for bugs to creep in.

Personally I like it in C++ that I can open an iostream safe in the knowledge that the compiler will make sure I don't mess up and forget to close it.

And for fuck sake, Java has build in support for multithreading, a mutex is not acquired by a constructor nor is it released by a destructor, for that we have a keyword: synchronized. Since Java 0.7 I believe.

Ah and so it is decreed then. No one could possibly want or use mutexes in Java then. I guess the current owners of Java are wrong about it too.

http://www.oracle.com/technetw...

So apparently you are mistaken. Since locks do exist in java in addition to monitors (apparently, it is not my knowledge that is outdated):

http://docs.oracle.com/javase/...

So, are you now going to recant your absurd claims?