Actually, they've done pretty good with one and only ONE item they got... VirtualBox. I'm kind of waiting for the other shoe to drop on that one as well, thought.
Uh... You could've had all the advantages of Java, still remain a 100% Microsoft shop (If everything you're running on is Windows/Microsoft...), and KEEP Java- and had an exit strategy if the Windows stuff didn't work out as well as it could. With.Net, you're mostly stuck with Microsoft. Mono's a nice framework, but it's not the same thing as.Net and it shows in varying ways. If you constrain yourself to Mono, it'd work out pretty well, but you'd limit yourself and you'd invite being left high and dry at the wrong time if Microsoft takes a fancy to suing people over infringing stuff that's clearly within the Mono ecosystem.
Heh... A JIT does not typically keep all the translations cached... It redoes a LOT of them from time to time. It's a virtualized machine. If it does NOT produce a final native code result that's kept and used directly time and time again, there's SOME interpretation that gets done each time the code is executed.
JIT compilers represent a hybrid approach, with translation occurring continuously, as with interpreters, but with caching of translated code to minimize performance degradation. It also offers other advantages over statically compiled code at development time, such as handling of late-bound data types and the ability to enforce security guarantees.
A JIT does a final compilation of select pieces, just in time, but NOT all of the codebase at once- and if you asked an "old-school" computer scientist, they'd tell you it was a hybrid interpreter. It's still interpreting things- just moving heavily used translations into native code as best as it can when it thinks it can do it. It can approach 80 or so percent of peak native code speeds overall- without considering GC loading and similar issues. In short, it's still interpreted, it still has GC related performance issues, etc. It makes for a good business application framework- but not for the higher end server stuff or for things like games or visualization. It's got issues that're non-deterministic and you'd sure not want it GC-ing things when it's in the middle of managing a defibrilator pulse, for example... Might not get enough of one or too much of one depending on when GC kicked in.
Heh... Depends on your demands for a "large distributed" system. If you're talking about something with a high transaction rate, say handling buy/sell bookings for 8 primary securities markets simultaneously, Java or.Net will leave you broken upon the wheel as they can't cope. The garbage collection happening at unpredictable times alone will do that to you- and we won't get into the VM being fine for many things...just not things like that or a game like Rage.;-D
Heh... But the drawbacks there are that there's known issues with Patents that until you've sorted out the whole software patent thing, you're better off NOT using Mono. Seriously. It's difficult to not get bit by one of them because ECMA's part that Microsoft won't sue over is smallish and you can only really make simple programs with it. Anything else gets you off into a high risk area.
So...with that in mind, why even go there when there's other solutions?
Heh... You know...this isn't a new thing, really. It's been an idea in many people's heads since 1978 at the earliest I can remember it...and probably before it.
Biggest problem with ANY of these VM based systems, CLI included, is that you're virtualizing a machine...which adds overhead. Lots of it in varying places, some noticeable, some not so.
For business apps, it's peachy. For high performance apps like games or visualization systems, it's not so hot.
In your case, I've largely found that the story you're telling is very much similar to the Java one- and the discussion does point to this being the next step in J++'s thinking. Not to mention that it's performance is rather similar to that of Java's with a good JVM behind it in many of the cases you'd put it to.
So long as they've got a means to look up your car and do these sorts of things, OnStar can be hacked into and the black hats can do the same things that we're talking about being mis-used.
It's not hard... Don't do anything that's easily remote hackable on the car, whether it's ignition control, door locks (Key fobs are a nifty idea, but are they as secure as they could be?), or the like.
I'm disinclined to buy anything they're putting out, console or otherwise, with this tripe included in the product they're selling. I can't imagine I'm the only one.
And don't kid yourself, you're never offline, you fucking nerds.
1) No, we're not. There's been loads of times where I couldn't do this or that because of limited access to the Internet. Especially out at the Horse Farm I'm trying to get started.
...have much of a better track record? You have fudged data from the last century or so and think you've got a model that shows anything whatsoever? Sorry, not buying it any better than you're buying this guy's statements.
This is not to say AGW proponents are right or wrong- just that they haven't the foggiest as they've not honestly done any science with the subject yet. To say they do have a picture is being dishonest at best- they don't have enough of a sample set for starters...
Uh, that's not the point and if you're being honest, you know that to be the case. This is a "showstopper" bug where most other places would've delayed the release a bit further (yes...in addition to the "delay" you refer to...) or back that change out. Seriously.
Did you miss that it doesn't matter that they had it in the JVM before they took over. They turned it on as a default behavior for the release, didn't check that it broke anything, and then shipped it anyway when they found it out 5 days before the ship date.
No company that cares about quality would've EVER done things like this. Seriously. It's called delay ship or back out the default behavior and document the problem with the optimization flag. They knew within enough time to fix it enough to ship without the issue biting people like it's doing.
Heh... Yeah, we have one of those severity levels in the tracking system too. Simply put, this shows you just what Oracle thinks about "quality", more than anything else.
Ah, but the problem is...Oracle knew about a week before release that this was going on- and did and said nothing about it and shipped it with that problem. Sorry, they're not getting an out just because it was the previous version where it wasn't the default behavior.
Heh... It's a bit more than 1.3%. The wars, etc. go into that bucket along with the operational expenditures (which is where you're getting 1.3%)- but even if you accept your supposition there, it still is tapdancing around the fact that I pointed out NASA's budget (and therefore most of the research spending in space...) is roughly 1-2% of the 18% pecent "Other" bucket there. Of the budget, it's less than 1% of the overall budget and we keep butchering it because it's "unnecessary" when compared to stuff that don't produce anything productive in the overall scheme of things.
Slashdot Mirror
Actually, they've done pretty good with one and only ONE item they got... VirtualBox. I'm kind of waiting for the other shoe to drop on that one as well, thought.
No kidding. Sun couldn't even do that one- even though they tried through their lack of vision for what to do with it.
Uh... You could've had all the advantages of Java, still remain a 100% Microsoft shop (If everything you're running on is Windows/Microsoft...), and KEEP Java- and had an exit strategy if the Windows stuff didn't work out as well as it could. With .Net, you're mostly stuck with Microsoft. Mono's a nice framework, but it's not the same thing as .Net and it shows in varying ways. If you constrain yourself to Mono, it'd work out pretty well, but you'd limit yourself and you'd invite being left high and dry at the wrong time if Microsoft takes a fancy to suing people over infringing stuff that's clearly within the Mono ecosystem.
I can relate. Doing it over and over again makes me feel old too.
Heh... A JIT does not typically keep all the translations cached... It redoes a LOT of them from time to time. It's a virtualized machine. If it does NOT produce a final native code result that's kept and used directly time and time again, there's SOME interpretation that gets done each time the code is executed.
Ah...but it's STILL interpreted. And, if you're thinking it isn't...you might want to learn a little bit about what a JIT really is.
From Wikipedia:
A JIT does a final compilation of select pieces, just in time, but NOT all of the codebase at once- and if you asked an "old-school" computer scientist, they'd tell you it was a hybrid interpreter. It's still interpreting things- just moving heavily used translations into native code as best as it can when it thinks it can do it. It can approach 80 or so percent of peak native code speeds overall- without considering GC loading and similar issues. In short, it's still interpreted, it still has GC related performance issues, etc. It makes for a good business application framework- but not for the higher end server stuff or for things like games or visualization. It's got issues that're non-deterministic and you'd sure not want it GC-ing things when it's in the middle of managing a defibrilator pulse, for example... Might not get enough of one or too much of one depending on when GC kicked in.
Heh... Depends on your demands for a "large distributed" system. If you're talking about something with a high transaction rate, say handling buy/sell bookings for 8 primary securities markets simultaneously, Java or .Net will leave you broken upon the wheel as they can't cope. The garbage collection happening at unpredictable times alone will do that to you- and we won't get into the VM being fine for many things...just not things like that or a game like Rage. ;-D
Heh... But the drawbacks there are that there's known issues with Patents that until you've sorted out the whole software patent thing, you're better off NOT using Mono. Seriously. It's difficult to not get bit by one of them because ECMA's part that Microsoft won't sue over is smallish and you can only really make simple programs with it. Anything else gets you off into a high risk area.
So...with that in mind, why even go there when there's other solutions?
Heh... You know...this isn't a new thing, really. It's been an idea in many people's heads since 1978 at the earliest I can remember it...and probably before it.
Biggest problem with ANY of these VM based systems, CLI included, is that you're virtualizing a machine...which adds overhead. Lots of it in varying places, some noticeable, some not so.
For business apps, it's peachy. For high performance apps like games or visualization systems, it's not so hot.
In your case, I've largely found that the story you're telling is very much similar to the Java one- and the discussion does point to this being the next step in J++'s thinking. Not to mention that it's performance is rather similar to that of Java's with a good JVM behind it in many of the cases you'd put it to.
So long as they've got a means to look up your car and do these sorts of things, OnStar can be hacked into and the black hats can do the same things that we're talking about being mis-used.
Just simply don't do OnStar type idiocies.
It's not hard... Don't do anything that's easily remote hackable on the car, whether it's ignition control, door locks (Key fobs are a nifty idea, but are they as secure as they could be?), or the like.
If you're using Certs, you're using PKI- that's part of that framework.
Epic.
Fail.
PKI's aren't good security, really...especially for something of this nature.
10 Risks of PKI
TLS Renegotiation Attack
MD5 Considered Harmful
And the list goes on and on and on...
It doesn't work over-well when you factor in used sales there...
I'm disinclined to buy anything they're putting out, console or otherwise, with this tripe included in the product they're selling. I can't imagine I'm the only one.
1) No, we're not. There's been loads of times where I couldn't do this or that because of limited access to the Internet. Especially out at the Horse Farm I'm trying to get started.
2) You're on /. Pot. Kettle. Black.
...have much of a better track record? You have fudged data from the last century or so and think you've got a model that shows anything whatsoever? Sorry, not buying it any better than you're buying this guy's statements.
This is not to say AGW proponents are right or wrong- just that they haven't the foggiest as they've not honestly done any science with the subject yet. To say they do have a picture is being dishonest at best- they don't have enough of a sample set for starters...
Uh, that's not the point and if you're being honest, you know that to be the case. This is a "showstopper" bug where most other places would've delayed the release a bit further (yes...in addition to the "delay" you refer to...) or back that change out. Seriously.
To Ellison, it's something to strip mine profits from.
Did you miss that it doesn't matter that they had it in the JVM before they took over. They turned it on as a default behavior for the release, didn't check that it broke anything, and then shipped it anyway when they found it out 5 days before the ship date .
No company that cares about quality would've EVER done things like this. Seriously. It's called delay ship or back out the default behavior and document the problem with the optimization flag. They knew within enough time to fix it enough to ship without the issue biting people like it's doing.
You should do 3 or 4, documenting things in the case of '4'. 1's not acceptable as is 2, really, when you get to brass tacks.
Heh... Yeah, we have one of those severity levels in the tracking system too. Simply put, this shows you just what Oracle thinks about "quality", more than anything else.
Ah, but the problem is...Oracle knew about a week before release that this was going on- and did and said nothing about it and shipped it with that problem. Sorry, they're not getting an out just because it was the previous version where it wasn't the default behavior.
It's thoroughly inappropriate to be doing things like this in secret.
Heh... It's a bit more than 1.3%. The wars, etc. go into that bucket along with the operational expenditures (which is where you're getting 1.3%)- but even if you accept your supposition there, it still is tapdancing around the fact that I pointed out NASA's budget (and therefore most of the research spending in space...) is roughly 1-2% of the 18% pecent "Other" bucket there. Of the budget, it's less than 1% of the overall budget and we keep butchering it because it's "unnecessary" when compared to stuff that don't produce anything productive in the overall scheme of things.