That's pretty much what I saw as well. (Just got my account approved. Whoohoo!) It looks like the object store is flexible enough to pretend to be a database, so they wrapped it in JDO. Technically, it should be possible to create JDBC drivers for legacy apps as well. Personally, I'm somewhat interested in accessing the object store directly. The API is simple enough to where all the JDO stuff is just cruft when it comes to purpose-built applications. (Good for portability, though.)
I'm surprised that they decreased battery capacity. I thought the reduced battery life was a side effect of the component upgrades. Apparently, that's not the case. Even more surprising is that the DSi mainboard is technically smaller than the DS Lite, but the unit has a larger footprint thanks to an expansion board hanging off the side. The board appears to be the contact points for the system's buttons.
I wonder if the larger footprint was necessitated by the larger screens? One would think that Nintendo would shave off a bit of space from the sides, but perhaps that didn't yield as good of a grip as the DS Lite.
I don't recall anything about not spawning threads being in the servlet spec.
From the spec:
For example, high-end application servers may limit the creation of a Thread object to insure that other components of the container are not negatively impacted.
[...]
It is now a recommendation, instead of a requirement, that the reference to the request and response object should not be given to the object in other threads - based on the requirement from JSR-168. Warnings are added when the thread created by the application uses the objects managed by the container.(2.3.3.3)
You are right, though. I was thinking about the EJB spec, which explicitly disallows threading. With servlets, it's not forbidden but highly discouraged.
Interestingly, the current spec seems to have lightened up on network connections:
Servlets typically run inside multithreaded servlet containers that can handle multiple requests concurrently. Developers must be aware to synchronize access to any shared resources such as files, network connections, and as well as the servlet's class and instance variables.
Back before the complete J2EE spec existed, I recall there being a prohibition on making network connections as part of the servlet itself. Generally, you were supposed to use a service of some sort to accomplish tasks that required networked resources. J2EE, of course, provided a number of the required services.
people do it all the time to talk to their database
The proper way to do this in a J2EE environment is to configure the connection in the Directory Server, then do a lookup to obtain a reference to the connection pool. I don't have docs yet for how Google is doing DB connections (something about JDO is mentioned in the brochure), but I imagine it's similar.
Seriously, did anyone even TRY reading the parent post? I realize it's at -1 flamebait right now, but that's a rather common situation around these parts. Here, I'll reproduce it for you:
Re:Not every tool is right for every application?! (Score:-1, Flamebait) by Razalhague (1497249) on 04-08-09 02:27 PM (#27506929) Homepage "x times cheaper" = current-price - (x * current-price). Duh.
My post was a poke at an obviously ridiculous reply. Nothing more, nothing less.:-)
Can't get very far without these forbidden features...
Incorrect. The Servlet platform imposes those restrictions already, with the container handling all the messy details of threading and networking. It works just fine in 90%+ of the cases.
Even more to the point, it opens the flood-gates for secure webapps. PHP has the advantage of providing a number of great apps off the shelf that all run on cheap hosting providers. The flip-side to those apps is that you're stuck on the upgrade treadmill as security issues pour out of those apps.
No offense to the people writing these apps. The ease of the platform is a double-edged sword. It's not hard to accidentally introduce security holes in the application. Especially on projects with dozens of developers.
The Java platform is built with security as a core concern and thus tends to have fewer security issues. (Note that I said *fewer*. There's no perfect system, and there's no accounting for poor practices.) Deploying Java-based apps could end up being a boon for getting off this breakneck upgrade cycle.
In addition, Java has a much better system for componentization. PHP apps are often deployed as large sets of files. This has its advantages, but it also means that plugins are often achieved by modifying PHP code. The Java platform is a more dynamic platform that allows for components to easily be plugged in. With Java, adding new features to your blog or forums can be as easy as clicking the "install" button in the admin console.
Unfortunately, due to recent findings of illegal copying and online distribution (piracy) of our products, Wizards of the Coast has decided to cease the sales of online PDFs.
Step 1: Point gun at foot and pull trigger.
Wizards of the Coast has instructed us to suspend all sales and downloads of Wizards of the Coast titles. Unfortunately, this includes offering download access to previously purchased Wizards of the Coast titles.'
Step 2: Open yourself up to lawsuits for breach of contract.
(GMSkarka) Typical short-sighted reaction from WOTC, which makes zero sense at all, when you consider the fact that the most widely-spread pirated copies of the 4e products contain printers marks -- which means that their piracy problem pre-dated any purchases.
Speaking as somebody whose entire income is largely dependent on my PDF sales, this really pisses me off.
Step 3: Ignore all evidence and make assumptions in an effort to piss off both the users and the publishers.
Those "12 angry [wo]men" were fed misinformation. (i.e. lies) I don't know about your country, but here that's called a mistrial. And when a mistrial happens, the verdict must be vacated and a new trial begun.
That's what happened in this case. The only catch is that Holder (the head lawyer for the Department of Justice) decided not to retry the case. He's forcing the prosecution to drop all charges due to their misconduct during the first trial. Unless they drop the charges with prejudice, the DoJ can still retry the case at a later date. But for now, there's no case without any prosecution.
In short, the judge did not overstep his bounds. All his did was uphold his responsibilities. It was the decision of the prosecution not to go forward on a retrial.
"Scalability" is a multi-faceted term. Most people think of "vertical scaling of the servers" when they hear the term "scalable". Which is to say that the code can handle a higher transaction load on a beefier server.
But there is quite a bit more to scalability than that. There's horizontal scalability of the servers. i.e. Does the software support plugging more boxes in to handle a greater load? Then there's the development scalability. i.e. Are the concerns of the code separated well enough to where multiple development teams can work in parallel without stepping on each other's toes or creating conflicts over code modules? Finally there's organizational scalability. i.e. Is this system designed to allow the organization to effectively split back-end responsibilities as the application grows. (An example of this would be scaling to meet the demands of a large sales force or distributed fulfillment process.)
The language you chose can have an impact on these larger concerns. Various features of the language can support aspects of these needs more naturally than other languages. But at the end of the day, it's still up to the architect to design a system that meets the needs of organization. The language is merely a small cog in the much larger machination of solving the challenges that face the business.
As the joke I posted above insinuates, Scala runs on top of the Java platform. And unlike Ruby, it focuses on the use of the platform's features. So the platform is more than tested enough. Why they feel the need to use Scala rather than straight-up Java is one of life's great mysteries. But for now, their platform should be fine.
Whether the code they write is scalable and holds up under loads or not is an entirely different topic.
Stevens is way too wealthy and politically connected to be punished for any crime.
Believe it or not, I don't believe those played a factor in the DOJ dropping the case. Apparently, Holder felt it more important to punish the prosecution on this one than nail Senator Tubes. Some of the factors claimed to play into his decision were the facts that Stevens is 85 (unlikely to be able to serve much jail time), no longer a sitting Senator, and that any movement forward on this case would be tainted.
As for whether or not he's innocent or not is irrelevant at this point. He never got a fair trial. And without a fair trial, the justice system cannot prove something one way or another. He'll probably be remembered by the public as a guilty bastard, and never manage anything else for the remainder of his life. He's permanently retired now, which is the worst part that would have come from the conviction. Not the fine or the trip to Club Fed.
Just because you and I believe something to be true doesn't mean that a judge will agree. There will likely be quite a few factors that would play into a judge's decision. e.g. Was the scanning process completely automated or where there manual steps? Were any changes made to the layout or format of the text? Were images and/or the cover remade? Does the digital technology count as creativity added to the work?
These questions and many others would likely play a role in any court case. How the judge decides might very well depend on the judge, the phase of the moon, and which way the wind is blowing. Thus unless you're looking to go to court, you must assume that the work is copyrighted. At least until someone is gutsy enough to prove otherwise.
That would be all well and good if the FireHose really mattered. But as far as I can tell, stories make it to the front page because the editors chose them, not because they get a good score in the FireHose. I've seen more than enough stories get voted up in the FireHose only to be ignored by the editors.
Here's the truth of the situation: The FireHose is intended as a standalone story filtration system for users to go and sift through the pile of stories themselves. In this way, it's like a competitor to Digg. The scores are completely unused save for possibly allowing editors to sift through the submissions a bit easier.
But there should be no problem with someone else downloading the material and reselling it or giving it out or copying it.
It's not quite that easy. The original work goes into the public domain, but only the original work. Republications obtain a new copyright on the version of the work. So if Google scanned in a bunch of public domain books and distributed in their own format, they'd probably have a copyright on those digital files.
I say *probably* because a direct scan is likely to be Yet Another Legal Gray Area(TM). The courts might decide that the digital container is sufficient transformation of the work to warrant a new copyright. Or they might decide that it's merely space shifted and deny copyright protection.
For legal advice, please contact a real lawyer. (I just play on on Slashdot. Which is much more interesting than TV.:-P)
You have them backwards. Hovertank, then Ultima, then Catacomb, then Wolf, then Ken's Laybrinth. I used to make the same mistake since Catacomb and Ken's were so confusing. But Ken's really was last. It was inspired by Wolf3D and eventually lead to the Build Engine used by Apogee (aka 3D Realms).
Easy. To prevent developers from avoiding royalty costs by developing games that target the Linux environment. A potentially far fetched scenario, but one that Sony protects against anyway. (See KallistiOS for an example of the system being reverse engineered and supported by sophisticated homebrew efforts.)
As I recall, there were European tax codes that allowed Sony to pay lower taxes if the machines were imported as computers rather than game consoles. Thus the Linux support.
The SDL stack works, but it's hardly a standard of the industry. OpenGL is better, but it only proves basic competency. There's nothing to differentiate this console to developers. Meanwhile, the other console manufacturers try to supply developers with anything and everything they could possibly need to develop their games in addition to cutting edge technology and a ready-made market.
If you were a game studio looking to make money, which would you choose?
Proof that this works: look how valuable the Halcyon console is.
Bad example. The Halcyon was released with a $2500 price tag. Even if it lost a significant chunk of that value, it would still be one of the most expensive consoles in history.
With the possible exceptions of the Pippin and the Jaguar, nearly every "bad" console has lost significant value over the years. F-Channels are worthless, O^2s can be had for a song, people practically give away 5200s because of the controllers, and 7800s can be found for a very reasonably price.
3DOs and CD-is are barely a sixth of their original cost, Amiga CD32s can be found NEW on eBay for $80, Sega Saturns are a mere $40 or less, and the Brits don't have a bleeding clue what to do with their Amstrad GX4000s.
Slashdot Mirror
That's pretty much what I saw as well. (Just got my account approved. Whoohoo!) It looks like the object store is flexible enough to pretend to be a database, so they wrapped it in JDO. Technically, it should be possible to create JDBC drivers for legacy apps as well. Personally, I'm somewhat interested in accessing the object store directly. The API is simple enough to where all the JDO stuff is just cruft when it comes to purpose-built applications. (Good for portability, though.)
I'm surprised that they decreased battery capacity. I thought the reduced battery life was a side effect of the component upgrades. Apparently, that's not the case. Even more surprising is that the DSi mainboard is technically smaller than the DS Lite, but the unit has a larger footprint thanks to an expansion board hanging off the side. The board appears to be the contact points for the system's buttons.
I wonder if the larger footprint was necessitated by the larger screens? One would think that Nintendo would shave off a bit of space from the sides, but perhaps that didn't yield as good of a grip as the DS Lite.
From the spec:
You are right, though. I was thinking about the EJB spec, which explicitly disallows threading. With servlets, it's not forbidden but highly discouraged.
Interestingly, the current spec seems to have lightened up on network connections:
Back before the complete J2EE spec existed, I recall there being a prohibition on making network connections as part of the servlet itself. Generally, you were supposed to use a service of some sort to accomplish tasks that required networked resources. J2EE, of course, provided a number of the required services.
The proper way to do this in a J2EE environment is to configure the connection in the Directory Server, then do a lookup to obtain a reference to the connection pool. I don't have docs yet for how Google is doing DB connections (something about JDO is mentioned in the brochure), but I imagine it's similar.
Seriously, did anyone even TRY reading the parent post? I realize it's at -1 flamebait right now, but that's a rather common situation around these parts. Here, I'll reproduce it for you:
My post was a poke at an obviously ridiculous reply. Nothing more, nothing less. :-)
Oh, that makes sense. So if an SSD is $20/GB right now, I'd need it to go down by 20 - (3000 * 20).
Or in other words, I'll purchase the SSD when the server manufacturer pays me $59,980/MB.
Hmm... something doesn't seem quite right here...
Incorrect. The Servlet platform imposes those restrictions already, with the container handling all the messy details of threading and networking. It works just fine in 90%+ of the cases.
Even more to the point, it opens the flood-gates for secure webapps. PHP has the advantage of providing a number of great apps off the shelf that all run on cheap hosting providers. The flip-side to those apps is that you're stuck on the upgrade treadmill as security issues pour out of those apps.
No offense to the people writing these apps. The ease of the platform is a double-edged sword. It's not hard to accidentally introduce security holes in the application. Especially on projects with dozens of developers.
The Java platform is built with security as a core concern and thus tends to have fewer security issues. (Note that I said *fewer*. There's no perfect system, and there's no accounting for poor practices.) Deploying Java-based apps could end up being a boon for getting off this breakneck upgrade cycle.
In addition, Java has a much better system for componentization. PHP apps are often deployed as large sets of files. This has its advantages, but it also means that plugins are often achieved by modifying PHP code. The Java platform is a more dynamic platform that allows for components to easily be plugged in. With Java, adding new features to your blog or forums can be as easy as clicking the "install" button in the admin console.
In short, yay for Google! This is great news!
Step 1: Point gun at foot and pull trigger.
Step 2: Open yourself up to lawsuits for breach of contract.
Step 3: Ignore all evidence and make assumptions in an effort to piss off both the users and the publishers.
Step 4: Lose all profits!
Congratulations on spotting the joke.
Those "12 angry [wo]men" were fed misinformation. (i.e. lies) I don't know about your country, but here that's called a mistrial. And when a mistrial happens, the verdict must be vacated and a new trial begun.
That's what happened in this case. The only catch is that Holder (the head lawyer for the Department of Justice) decided not to retry the case. He's forcing the prosecution to drop all charges due to their misconduct during the first trial. Unless they drop the charges with prejudice, the DoJ can still retry the case at a later date. But for now, there's no case without any prosecution.
In short, the judge did not overstep his bounds. All his did was uphold his responsibilities. It was the decision of the prosecution not to go forward on a retrial.
"Scalability" is a multi-faceted term. Most people think of "vertical scaling of the servers" when they hear the term "scalable". Which is to say that the code can handle a higher transaction load on a beefier server.
But there is quite a bit more to scalability than that. There's horizontal scalability of the servers. i.e. Does the software support plugging more boxes in to handle a greater load? Then there's the development scalability. i.e. Are the concerns of the code separated well enough to where multiple development teams can work in parallel without stepping on each other's toes or creating conflicts over code modules? Finally there's organizational scalability. i.e. Is this system designed to allow the organization to effectively split back-end responsibilities as the application grows. (An example of this would be scaling to meet the demands of a large sales force or distributed fulfillment process.)
The language you chose can have an impact on these larger concerns. Various features of the language can support aspects of these needs more naturally than other languages. But at the end of the day, it's still up to the architect to design a system that meets the needs of organization. The language is merely a small cog in the much larger machination of solving the challenges that face the business.
As the joke I posted above insinuates, Scala runs on top of the Java platform. And unlike Ruby, it focuses on the use of the platform's features. So the platform is more than tested enough. Why they feel the need to use Scala rather than straight-up Java is one of life's great mysteries. But for now, their platform should be fine.
Whether the code they write is scalable and holds up under loads or not is an entirely different topic.
Not to be too pedantic, but doesn't that sum up Twitter as a whole?
They should have just used Java. Wait--
Believe it or not, I don't believe those played a factor in the DOJ dropping the case. Apparently, Holder felt it more important to punish the prosecution on this one than nail Senator Tubes. Some of the factors claimed to play into his decision were the facts that Stevens is 85 (unlikely to be able to serve much jail time), no longer a sitting Senator, and that any movement forward on this case would be tainted.
As for whether or not he's innocent or not is irrelevant at this point. He never got a fair trial. And without a fair trial, the justice system cannot prove something one way or another. He'll probably be remembered by the public as a guilty bastard, and never manage anything else for the remainder of his life. He's permanently retired now, which is the worst part that would have come from the conviction. Not the fine or the trip to Club Fed.
Just because you and I believe something to be true doesn't mean that a judge will agree. There will likely be quite a few factors that would play into a judge's decision. e.g. Was the scanning process completely automated or where there manual steps? Were any changes made to the layout or format of the text? Were images and/or the cover remade? Does the digital technology count as creativity added to the work?
These questions and many others would likely play a role in any court case. How the judge decides might very well depend on the judge, the phase of the moon, and which way the wind is blowing. Thus unless you're looking to go to court, you must assume that the work is copyrighted. At least until someone is gutsy enough to prove otherwise.
That would be all well and good if the FireHose really mattered. But as far as I can tell, stories make it to the front page because the editors chose them, not because they get a good score in the FireHose. I've seen more than enough stories get voted up in the FireHose only to be ignored by the editors.
Here's the truth of the situation: The FireHose is intended as a standalone story filtration system for users to go and sift through the pile of stories themselves. In this way, it's like a competitor to Digg. The scores are completely unused save for possibly allowing editors to sift through the submissions a bit easier.
It's not quite that easy. The original work goes into the public domain, but only the original work. Republications obtain a new copyright on the version of the work. So if Google scanned in a bunch of public domain books and distributed in their own format, they'd probably have a copyright on those digital files.
I say *probably* because a direct scan is likely to be Yet Another Legal Gray Area(TM). The courts might decide that the digital container is sufficient transformation of the work to warrant a new copyright. Or they might decide that it's merely space shifted and deny copyright protection.
For legal advice, please contact a real lawyer. (I just play on on Slashdot. Which is much more interesting than TV. :-P)
You have them backwards. Hovertank, then Ultima, then Catacomb, then Wolf, then Ken's Laybrinth. I used to make the same mistake since Catacomb and Ken's were so confusing. But Ken's really was last. It was inspired by Wolf3D and eventually lead to the Build Engine used by Apogee (aka 3D Realms).
Try again. Ever hear of HoverTank 3D, Ultima Underworld, or Catacomb 3D?
Wolfenstien was the first popular FPS.
Easy. To prevent developers from avoiding royalty costs by developing games that target the Linux environment. A potentially far fetched scenario, but one that Sony protects against anyway. (See KallistiOS for an example of the system being reverse engineered and supported by sophisticated homebrew efforts.)
It's all about the $$$.
As I recall, there were European tax codes that allowed Sony to pay lower taxes if the machines were imported as computers rather than game consoles. Thus the Linux support.
The SDL stack works, but it's hardly a standard of the industry. OpenGL is better, but it only proves basic competency. There's nothing to differentiate this console to developers. Meanwhile, the other console manufacturers try to supply developers with anything and everything they could possibly need to develop their games in addition to cutting edge technology and a ready-made market.
If you were a game studio looking to make money, which would you choose?
Bad example. The Halcyon was released with a $2500 price tag. Even if it lost a significant chunk of that value, it would still be one of the most expensive consoles in history.
With the possible exceptions of the Pippin and the Jaguar, nearly every "bad" console has lost significant value over the years. F-Channels are worthless, O^2s can be had for a song, people practically give away 5200s because of the controllers, and 7800s can be found for a very reasonably price.
3DOs and CD-is are barely a sixth of their original cost, Amiga CD32s can be found NEW on eBay for $80, Sega Saturns are a mere $40 or less, and the Brits don't have a bleeding clue what to do with their Amstrad GX4000s.
Soo... bad plan. :-)