[Sun has] banned [Java]'s use in any and all internal projects
Typical urban legend. Propagated by a Slashdot troll no less. With Sun pushing up and coming Java projects like Looking Glass, Darkstar, Glassfish, and many others, one would think that people would have figured it out by now. But apparently not.
The real story is that after the introduction of Java, Sun started creating new Solaris components in Java. Unfortunately, they found out at the time that Java wasn't mature enough for what they were doing. So a ban was supposedly implemented on any new Solaris components being written in Java. Which (if the story is even true in the first place) was probably a wise move. I don't know if anyone remembers CDE around here, but having to launch Java just to change the volume was not a good design decision. Sun needed to either make the entire Desktop in Java (in which case most of the performance problems would disappear and the memory hit would be marginalized) or go back to using native components for all the widgets. The idea of a hybrid Desktop just wasn't going to cut it.
As it happens, Sun chose to assist the GNOME project and made that their primary desktop. Then they rebranded it as the "Java Desktop System" in one of the most confusing brand changes in history. And that is where we sit today.
<paul-harvey>And now you know... the rest of the story. Good day!</paul-harvey>
Translation: If you want something now versus tomorrow, it will cost you more.
You mean like how I pay Comcast through the nose so I can get legal downloads like Zelda Retrospective DVD (alt link) NOW, but instead I'm plodding along at 30KB/sec because Comcast is throttling me?
Sorry, poor torrent service is a pet peeve of mine. Otherwise I agree with both of you completely.:-)
Sorry, perhaps I should have been more clear. Today's relational DBMSes can't store non-integer or varchar data with a *bleeping* *bleep* of a *bleep*. The data gets so incredibly bloated and is so incredibly SLOW to access that you're better off creating a custom data interface for storing your CLOBS/BLOBS in flat-file form in the File System.
Or perhaps look into a PDMs like you mentioned. Either way, today's relational DBMSes are not well equipped to handle the data.:)
Or in other words column wise read would be fast but write slow. I could see this being an option within DBs in the future. As it is just a data layout problem not a language problem.
An interesting idea for improving database technology is to actually change the way that database data is mirrored in a disk array. Rather than writing EXACT duplicates of the data, perhaps one set could be written in row-oriented form, while the other set would be written in column-oriented form. This guarantees that the data is always duplicated, but offers a new option to the query engine for retrieving the data.
The primary issue I see is not creating an issue of "the worst of both worlds". Obviously row-oriented data is going to be faster to write. Thus you can't wait for the column oriented data to finish writing. A secondary process will have to manage that in parallel, with the assumption that the database will report the data as "committed" as soon as the row-oriented write is complete.
The fact that you think a Relational Database can only store integers and varchars screams how ignorant you are.
Glad you're paying attention. Not.:-/
The relational model can store just about anything you want. It's just math based on sets. But that's not what I'm talking about. What I'm talking about is that today's *batch* of DBMSes are terrible at storing data that is not an integer or varchar.
In addition, today's DBMSes have no protection against bad data that isn't explicitly engineered into the data model. This provides an opportunity for human error to creep in. Thus you see issues with keys that aren't referenced/restricted, incorrect keys getting inserted because the ID exists in the referenced table, nulls that shouldn't be allowed, transactions that aren't closed in transactions, multiple rows for the same secondary key when it should be unique, data accesses that shouldn't be allowed, etc. There are solutions for nearly all of these in your average DBMS product, but they all require that the Database Administrator play dictator to enforce.
A better solution would be to take the same tack that computer languages and compilers have been taking: Make a mistake impossible as early in the process as possible. Just as modern compilers can catch a variety of errors before the code is even executed, it would be better if our databases offered more up-front protection and solutions for these problems. As a bonus, the database would "know" more about the data and thus be able to plot better data storage and retrieval schemes automatically.
...is dupinghimself and thus Slashdot is duping the stories by extension.
Stonebraker has been pushing the concept of column-oriented databases for quite some time now, trying to get someone, ANYONE, to listen that it's superior. While I think he has a point, I'm not sure if he really goes far enough. Our relational databases of today are heavily based on the ISAM files of yesteryear. Far too many products threw foreign keys on top of a collection of ISAMs and called it a day. Which is why we STILL have key integrity issues to this day.
It would be nice if we could take a step back and re-engineer our databases with more modern technology in mind. e.g. Instead of passing around abstract id numbers, it would be nice if we had reference objects that abstracted programmers away from the temptation of manually managing identifiers. Data storage is another area that can be improved, with Object Databases (really just fancy relational databases with their own access methods) showing how it's possible to store something more complex than integers and varchars.
The demands on our DBMSes are only going to grow. So there's something to be said for going back and reengineering things. If column-oriented databases are the answer, my opinion is that they're only PART of the answer. Take the redesign to its logical conclusion. Let's see databases that truly store any data, and enforce the integrity of their sets.
I don't understand where you're getting the 10,000 year time-frame from. My original post mentioned 10,000 of engineering background of the human race, but I think that any food problem would be slightly more immediate. To that end, nano-anything is the wrong answer. If the problem is a lack of arable land, then creating city-farms that blend with our Urban Centers sounds like the right answer.
NERVA Gas Core is a contradiction in terms. NERVA was a project to develop a solid core nuclear rocket engine. A Gas Core Nuclear Rocket is a completely different beast that hasn't quite made it off the drawing boards. It's an absolutely incredible idea IF we can get it to work. Sadly, not enough funding has been diverted to the concept yet.
But you're right. We could certainly get to Mars much faster if we used nuclear engines.
Specifically, I'm referring to the practice of showing the most dramatic scene of the story during the teaser, then jumping back to the start of the story once the show begins. You then have to plod through the story to reach that dramatic moment again.
This technique makes a lot of sense in some stories. Especially stories that maintain a sense of intrigue by slowly revealing past events through flashbacks. But as of late, it's been abused to no end. Did SG-1 really need to open with the Stargate being zapped away? Did the Enterprise episode "Singularity" really need to open with everyone unconscious?
If the writers can't open the story without framing it up front, then their story probably isn't that interesting. Or at the very least, they're telling it wrong. (ex. Ent. Ep. "Similitude" was very similar to the Voyager episode "Demon". Yet "Demon" did not need to be framed in order to keep the viewer in suspense about the crew members having duplicates.)
"AT&T (T - Cramer's Take - Stockpickr - Rating) shares dropped 2% Wednesday after Apple (AAPL - Cramer's Take - Stockpickr - Rating) made two moves that took a little more sparkle off this summer's heavily hyped smartphone debut. "
We *did* discuss this last time it was mentioned on Slashdot. The engineers are well aware of the issues. That's why the designs have features like a slanted building (looks like a giant Wii its cradle), fiber-optics to pipe sunlight, and solar collector mirrors on nearby rooftops.
Battlestar Galactica or even comedies with cold opens - like The Office - have been pulling this off pretty well lately)
As long as they're not framing the story. Nothing is more annoying to a viewer than overusing framed openings. Star Trek Enterprise did it all the time, which was REALLY annoying. The last season of SG-1 was going that way too. Now BSG is trying to horn in on the action by also forcing "drama" with framed stories.
Note to writers: If you can't build up the suspense by letting the story unfold naturally, you're doing something wrong.
People will knock down some building and plant crops long before they'll starve.
While true, it's unlikely it will ever happen. Barring a collapse of civilization (did someone mention Huns at the door?) humankind will continue to engineer itself forward. Something "complicated" like an Indoor Farm may seem like an overkill, but it does have a lot of advantages over farmland. Not the least of which is control. We've already been engineering our crops and the soil. (Even the "organic" variety still use modern farming techniques.) Thus the next logical step is to engineer the farmland itself to better meet our needs.
Reducing the distance between the farms and the consumers could have a lot of direct benefits. One of which is being able to control and recycle the farm wastes means that open lands are cleaner and better smelling. Future city engineers may even look at ways of pumping filtered CO2 from the city's air into the crops, while pumping the resultant oxygen back to the city.
Lots of possibilities.:)
(And yes, I've been watching too much "Engineering an Empire" off of iTunes. Excellent show!)
they better make sure there is no mic. This could make a fantastic Skype handset.
It seems to me that being tethered by Wifi would eventually convince users that they should upgrade to an iPhone so they can make calls anywhere at any time.
But don't expect the Wing Commander series to be released as freeware any time soon. It's own by EA now.:(
I got me a free copy from a disc that came with PC Gamer. I still have the original, of course, but it was nice to get a Windows-compatible version on CD without paying for the Kilrathi Saga pack.
No. The optical sensors on mice work by shining a light through holes in a wheel. As each hole is passed, a fixed distance known as a "mickey" is reported. The ratio between pixels and mickeys can be tweaked in the control panel of most OSes, but there is no variation in the physical distance of a mickey.
So called "optical" or "laser" mice are a bit different, but work on similar enough principles. A mickey is still a mickey. It doesn't change unless you lift the mouse or have a very poor surface under the mouse.
I don't think you really understand the difficulties posed by the Wii Remote. The problems you mention all are something that can be ocmpensated for at the gun. With the Wii Remote, you have no such luck. Your aim will be different depending on the position of the sensor bar, your distance from the television, your position along the parallel of the sensor bar, how deep of an angle you're firing at vs. moving the remote side to side, the height the remote is currently being held at, etc. Just about every factor you can think of will slightly change the aiming of the remote. So there's very little comparison with wind (a measurably quantity) and weapon warping (something that can be compensated for). It's more like a weapon that kicks a different direction every time you fire it.
Let me put a strong rumble pack on your gun and let's see how well you compensate for it.;-)
There's just one teeny-weeny little problem: The Wii Remote does not actually "point" at the object on the screen. It interpolates a set of coordinates based on the positions of the IR LEDs according to the sensor on the front of the remote. The problem this creates is that the aim is inaccurate. You're really aiming within the field of the sensor bar and NOT within the field of the television. Even worse, you're dealing with polar coordinates to determine Cartesian coordinates. This can slightly warp the aim of the Wii Remote, making it even harder to aim precisely.
When I used the Zapper as a kid, I stood far back from the television. (The first mistake people always made with the zapper was to stand too close to the television.) From there I was able to lift the weapon and fire with pinpoint accuracy at ducks/clay pigeons/gangsters/plates/glass panes/various junk the magician threw/etc. At least among my family and friends, I was a crack shot. You can't do that with the Wii Remote. Every time you heft it as a weapon, you need to orient the reticle before taking the shot. You can get good at aiming the remote fairly close to your target, but there will always need to be that visual feedback loop between the reticle and your aim.
While I have yet to play Metroid, I understand it gets around these issues with a "lock-on" control system that actually corrects your aim for you. So if you can get the reticle close to your target, it's good enough to take the shot. Not very realistic, but certainly a lot more fun.;-)
Now don't get me wrong. The Wii Remote is lightyears ahead of the ultra-fine motor control required to play FPSes with a dual-analog controller. A player can respond faster, shoot quicker, aim more precisely, and otherwise manage to make the controller do what they intend. I think it's an absolutely wonderful update to the venerable gamepad, and wouldn't want to play my console any other way. I'm only pointing out that it has no real advantage over a mouse when it comes to hand/eye coordination skills. In some ways it actually does worse, because the spatial movement of the controller lacks the precision that a mouse's digital-optical sensors can provide. So there is still room for improvement.:)
Here I was wondering how video games could not be involved at a shooting at vTech. It's amazing the lengths of madness Dora the Explorer can send people to. *tsk* *tsk*
his colleagues didn't believe the power to weight ratio claims for the engines.
That's really what was killing him. His initial claims were impressive, but it was easy to see from his hover tests that he wasn't getting quite the power originally promised. In fact, he had to abandon the thrust redirection slats he originally promised, and moved to rotating nacelle design. That, of course, had a direct impact on the stability of the vehicle's hover capabilities.
I remember watching the hover test videos for the first time. Over the loud whine of the engines as they struggled to keep the craft aloft, I kept thinking "those props don't have enough power". Supposedly he recently upgraded the engines on the craft, so we'll see how that goes.
All in all, it's going to be a fancy airplane. You'll still need a pilot's license and you'll still need much of the same clearance as a plane needs. I want to believe that it will be an aircraft that "anyone" can fly, but my gut says it will be a deathtrap for any untrained pilots that dare to attempt to fly the contraption.
Still, best of luck to Mr. Moller. It's great to see a "done" model of this finally arrive!:)
Slashdot Mirror
Typical urban legend. Propagated by a Slashdot troll no less. With Sun pushing up and coming Java projects like Looking Glass, Darkstar, Glassfish, and many others, one would think that people would have figured it out by now. But apparently not.
The real story is that after the introduction of Java, Sun started creating new Solaris components in Java. Unfortunately, they found out at the time that Java wasn't mature enough for what they were doing. So a ban was supposedly implemented on any new Solaris components being written in Java. Which (if the story is even true in the first place) was probably a wise move. I don't know if anyone remembers CDE around here, but having to launch Java just to change the volume was not a good design decision. Sun needed to either make the entire Desktop in Java (in which case most of the performance problems would disappear and the memory hit would be marginalized) or go back to using native components for all the widgets. The idea of a hybrid Desktop just wasn't going to cut it.
As it happens, Sun chose to assist the GNOME project and made that their primary desktop. Then they rebranded it as the "Java Desktop System" in one of the most confusing brand changes in history. And that is where we sit today.
<paul-harvey>And now you know... the rest of the story. Good day!</paul-harvey>
You mean like how I pay Comcast through the nose so I can get legal downloads like Zelda Retrospective DVD (alt link) NOW, but instead I'm plodding along at 30KB/sec because Comcast is throttling me?
Sorry, poor torrent service is a pet peeve of mine. Otherwise I agree with both of you completely.
Sorry, perhaps I should have been more clear. Today's relational DBMSes can't store non-integer or varchar data with a *bleeping* *bleep* of a *bleep*. The data gets so incredibly bloated and is so incredibly SLOW to access that you're better off creating a custom data interface for storing your CLOBS/BLOBS in flat-file form in the File System.
:)
Or perhaps look into a PDMs like you mentioned. Either way, today's relational DBMSes are not well equipped to handle the data.
An interesting idea for improving database technology is to actually change the way that database data is mirrored in a disk array. Rather than writing EXACT duplicates of the data, perhaps one set could be written in row-oriented form, while the other set would be written in column-oriented form. This guarantees that the data is always duplicated, but offers a new option to the query engine for retrieving the data.
The primary issue I see is not creating an issue of "the worst of both worlds". Obviously row-oriented data is going to be faster to write. Thus you can't wait for the column oriented data to finish writing. A secondary process will have to manage that in parallel, with the assumption that the database will report the data as "committed" as soon as the row-oriented write is complete.
Glad you're paying attention. Not.
The relational model can store just about anything you want. It's just math based on sets. But that's not what I'm talking about. What I'm talking about is that today's *batch* of DBMSes are terrible at storing data that is not an integer or varchar.
In addition, today's DBMSes have no protection against bad data that isn't explicitly engineered into the data model. This provides an opportunity for human error to creep in. Thus you see issues with keys that aren't referenced/restricted, incorrect keys getting inserted because the ID exists in the referenced table, nulls that shouldn't be allowed, transactions that aren't closed in transactions, multiple rows for the same secondary key when it should be unique, data accesses that shouldn't be allowed, etc. There are solutions for nearly all of these in your average DBMS product, but they all require that the Database Administrator play dictator to enforce.
A better solution would be to take the same tack that computer languages and compilers have been taking: Make a mistake impossible as early in the process as possible. Just as modern compilers can catch a variety of errors before the code is even executed, it would be better if our databases offered more up-front protection and solutions for these problems. As a bonus, the database would "know" more about the data and thus be able to plot better data storage and retrieval schemes automatically.
...is duping himself and thus Slashdot is duping the stories by extension.
Stonebraker has been pushing the concept of column-oriented databases for quite some time now, trying to get someone, ANYONE, to listen that it's superior. While I think he has a point, I'm not sure if he really goes far enough. Our relational databases of today are heavily based on the ISAM files of yesteryear. Far too many products threw foreign keys on top of a collection of ISAMs and called it a day. Which is why we STILL have key integrity issues to this day.
It would be nice if we could take a step back and re-engineer our databases with more modern technology in mind. e.g. Instead of passing around abstract id numbers, it would be nice if we had reference objects that abstracted programmers away from the temptation of manually managing identifiers. Data storage is another area that can be improved, with Object Databases (really just fancy relational databases with their own access methods) showing how it's possible to store something more complex than integers and varchars.
The demands on our DBMSes are only going to grow. So there's something to be said for going back and reengineering things. If column-oriented databases are the answer, my opinion is that they're only PART of the answer. Take the redesign to its logical conclusion. Let's see databases that truly store any data, and enforce the integrity of their sets.
I don't understand where you're getting the 10,000 year time-frame from. My original post mentioned 10,000 of engineering background of the human race, but I think that any food problem would be slightly more immediate. To that end, nano-anything is the wrong answer. If the problem is a lack of arable land, then creating city-farms that blend with our Urban Centers sounds like the right answer.
NERVA Gas Core is a contradiction in terms. NERVA was a project to develop a solid core nuclear rocket engine. A Gas Core Nuclear Rocket is a completely different beast that hasn't quite made it off the drawing boards. It's an absolutely incredible idea IF we can get it to work. Sadly, not enough funding has been diverted to the concept yet.
But you're right. We could certainly get to Mars much faster if we used nuclear engines.
Specifically, I'm referring to the practice of showing the most dramatic scene of the story during the teaser, then jumping back to the start of the story once the show begins. You then have to plod through the story to reach that dramatic moment again.
This technique makes a lot of sense in some stories. Especially stories that maintain a sense of intrigue by slowly revealing past events through flashbacks. But as of late, it's been abused to no end. Did SG-1 really need to open with the Stargate being zapped away? Did the Enterprise episode "Singularity" really need to open with everyone unconscious?
If the writers can't open the story without framing it up front, then their story probably isn't that interesting. Or at the very least, they're telling it wrong. (ex. Ent. Ep. "Similitude" was very similar to the Voyager episode "Demon". Yet "Demon" did not need to be framed in order to keep the viewer in suspense about the crew members having duplicates.)
Being able to purchase Starbucks music on your iPod/iPhone has to be the daftest feature ever. But I'd be lying if I said I didn't think it was nifty!
http://www.thestreet.com/s/iphone-shift-bruises-ap ple/newsanalysis/techtelecom/10378004.html?cm_ven= CBSM&cm_cat=FREE&cm_ite=NA
"The iPhone buzz is wearing off.
"AT&T (T - Cramer's Take - Stockpickr - Rating) shares dropped 2% Wednesday after Apple (AAPL - Cramer's Take - Stockpickr - Rating) made two moves that took a little more sparkle off this summer's heavily hyped smartphone debut. "
The Zune just squirted itself.
(Sorry, sorry)
We *did* discuss this last time it was mentioned on Slashdot. The engineers are well aware of the issues. That's why the designs have features like a slanted building (looks like a giant Wii its cradle), fiber-optics to pipe sunlight, and solar collector mirrors on nearby rooftops.
As long as they're not framing the story. Nothing is more annoying to a viewer than overusing framed openings. Star Trek Enterprise did it all the time, which was REALLY annoying. The last season of SG-1 was going that way too. Now BSG is trying to horn in on the action by also forcing "drama" with framed stories.
Note to writers: If you can't build up the suspense by letting the story unfold naturally, you're doing something wrong.
While true, it's unlikely it will ever happen. Barring a collapse of civilization (did someone mention Huns at the door?) humankind will continue to engineer itself forward. Something "complicated" like an Indoor Farm may seem like an overkill, but it does have a lot of advantages over farmland. Not the least of which is control. We've already been engineering our crops and the soil. (Even the "organic" variety still use modern farming techniques.) Thus the next logical step is to engineer the farmland itself to better meet our needs.
Reducing the distance between the farms and the consumers could have a lot of direct benefits. One of which is being able to control and recycle the farm wastes means that open lands are cleaner and better smelling. Future city engineers may even look at ways of pumping filtered CO2 from the city's air into the crops, while pumping the resultant oxygen back to the city.
Lots of possibilities.
(And yes, I've been watching too much "Engineering an Empire" off of iTunes. Excellent show!)
I can fix that!
--
10,000 years of incredible human engineering isn't going to end with something as simple as "we've developed all the farmland".
It seems to me that being tethered by Wifi would eventually convince users that they should upgrade to an iPhone so they can make calls anywhere at any time.
...to why it was cancelled is right here:
t ime-for-an-intervention/
. html
http://www.engadget.com/2007/08/21/dear-palm-its-
Palm actually listened as they mentioned in their reply:
http://blog.palm.com/palm/2007/08/thanks-engadget
I got me a free copy from a disc that came with PC Gamer. I still have the original, of course, but it was nice to get a Windows-compatible version on CD without paying for the Kilrathi Saga pack.
No. The optical sensors on mice work by shining a light through holes in a wheel. As each hole is passed, a fixed distance known as a "mickey" is reported. The ratio between pixels and mickeys can be tweaked in the control panel of most OSes, but there is no variation in the physical distance of a mickey.
So called "optical" or "laser" mice are a bit different, but work on similar enough principles. A mickey is still a mickey. It doesn't change unless you lift the mouse or have a very poor surface under the mouse.
I don't think you really understand the difficulties posed by the Wii Remote. The problems you mention all are something that can be ocmpensated for at the gun. With the Wii Remote, you have no such luck. Your aim will be different depending on the position of the sensor bar, your distance from the television, your position along the parallel of the sensor bar, how deep of an angle you're firing at vs. moving the remote side to side, the height the remote is currently being held at, etc. Just about every factor you can think of will slightly change the aiming of the remote. So there's very little comparison with wind (a measurably quantity) and weapon warping (something that can be compensated for). It's more like a weapon that kicks a different direction every time you fire it.
;-)
Let me put a strong rumble pack on your gun and let's see how well you compensate for it.
There's just one teeny-weeny little problem: The Wii Remote does not actually "point" at the object on the screen. It interpolates a set of coordinates based on the positions of the IR LEDs according to the sensor on the front of the remote. The problem this creates is that the aim is inaccurate. You're really aiming within the field of the sensor bar and NOT within the field of the television. Even worse, you're dealing with polar coordinates to determine Cartesian coordinates. This can slightly warp the aim of the Wii Remote, making it even harder to aim precisely.
;-)
:)
When I used the Zapper as a kid, I stood far back from the television. (The first mistake people always made with the zapper was to stand too close to the television.) From there I was able to lift the weapon and fire with pinpoint accuracy at ducks/clay pigeons/gangsters/plates/glass panes/various junk the magician threw/etc. At least among my family and friends, I was a crack shot. You can't do that with the Wii Remote. Every time you heft it as a weapon, you need to orient the reticle before taking the shot. You can get good at aiming the remote fairly close to your target, but there will always need to be that visual feedback loop between the reticle and your aim.
While I have yet to play Metroid, I understand it gets around these issues with a "lock-on" control system that actually corrects your aim for you. So if you can get the reticle close to your target, it's good enough to take the shot. Not very realistic, but certainly a lot more fun.
Now don't get me wrong. The Wii Remote is lightyears ahead of the ultra-fine motor control required to play FPSes with a dual-analog controller. A player can respond faster, shoot quicker, aim more precisely, and otherwise manage to make the controller do what they intend. I think it's an absolutely wonderful update to the venerable gamepad, and wouldn't want to play my console any other way. I'm only pointing out that it has no real advantage over a mouse when it comes to hand/eye coordination skills. In some ways it actually does worse, because the spatial movement of the controller lacks the precision that a mouse's digital-optical sensors can provide. So there is still room for improvement.
Here I was wondering how video games could not be involved at a shooting at vTech. It's amazing the lengths of madness Dora the Explorer can send people to. *tsk* *tsk*
That's really what was killing him. His initial claims were impressive, but it was easy to see from his hover tests that he wasn't getting quite the power originally promised. In fact, he had to abandon the thrust redirection slats he originally promised, and moved to rotating nacelle design. That, of course, had a direct impact on the stability of the vehicle's hover capabilities.
I remember watching the hover test videos for the first time. Over the loud whine of the engines as they struggled to keep the craft aloft, I kept thinking "those props don't have enough power". Supposedly he recently upgraded the engines on the craft, so we'll see how that goes.
All in all, it's going to be a fancy airplane. You'll still need a pilot's license and you'll still need much of the same clearance as a plane needs. I want to believe that it will be an aircraft that "anyone" can fly, but my gut says it will be a deathtrap for any untrained pilots that dare to attempt to fly the contraption.
Still, best of luck to Mr. Moller. It's great to see a "done" model of this finally arrive!
Because it was?
Ok, so it was reported yesterday, but it happened close enough to be reasonable called "yesterday".