I'm not going to go into the story: it's convoluted, but frankly its really not the key to this movie: this is a roller coaster movie with new actors playing parts we love.
Can someone please explain to me how this is NOT a failure?
Star Trek was always known for its strong story telling. Sure, it was sometimes campy and over the top. But the series was built on story. The action was just the frosting.
That was something that Berman never realized. He kept playing down the story in exchange for more action, more outlandish events, more of that adrenaline squeeze. Except that he was bad at it. I mean, really, really bad. Stinking up the screen bad. (Hey look: MACOs! Amazing how those guys never got any screen time, isn't it? Or how about the time Riker used a joystick to save the day? I know, let's have Picard fight himself! Or put 7 of 9 in a fight pit with a WWE wrestler! Yeah, those were great times. *cough*)
Now you're telling me that JJ doesn't suck at it. Therefore it's okay to finish tearing apart the foundations of Star Trek because at least it was a fun ride. Right?
Star Trek stood on its own two feet for 40 years. It was challenged by the networks, challenged by the box office, and challenged by its own actors. Yet the concept survived and is cherished by its fans. The core idea of a better future painted on the rich tapestry of space travel is not something to be ignored. It's something to protect, grow, and find ways to adapt to the changing times. After all, is there any better time to shout out this message than when things seem the darkest?
Instead we have a summer blockbuster. And like all summer blockbusters, it will be forgotten by next summer. It is a sad day for Roddenberry's vision of the future.
You know, that graph is rather amusing. It doesn't portray a crisis, but rather that the industry has been running out of thing to pack on a chip! Over the past 30 years, every generation of processor has meant new features and performance enhancements. For which each generation got hungrier and hungrier for transistors.
Well, now chip design has peaked. Designers have taken all the low-hanging fruit, stripped much of the top of the tree as well, and now are trying to figure out what else to do. Each chip generation still gets optimized more and more, but in many cases they're taking fewer transistors rather than more.
So how does a company with an insane transistor budget keep creating chips that the market will pay a premium for?
Multicore is a bit of a cop-out answer, but an effective one nonetheless. If you've got 2-4x the number of transistors available as your previous generation of chips and nothing to do with it, then multicore is an excellent answer. It has the side effect of stripping value from the high end chips like Xeon, but that can be managed with other marketing tricks. (e.g. Did you notice how long it took for x86-64 support to hit Intel's consumer chips?)
That chart is definitely telling a story. Just not the same story that most viewers would assume.;-)
Letting the RIAA pick the "forensics expert" does absolutely nothing to ensure that a fair and impartial expert is chose
I don't think that's the point. The point is that a trusted expert in the industry is the only one with access to the private information. He can then represents the findings on behalf of the RIAA. The defense needs to find its own expert witness to counter any arguments made by the RIAA's expert witness.
At least, that's my understanding of how the proceedings would work. (IANAL)
Maybe I'm thinking of gravity wave experiments, but didn't the researchers have issues with unforeseen field effects the last time they tried this measurement?
I've seen the 3000 series with 8 procs or so go for prices near that. Plus you can get similarly configured Sun workstations for less money. (I inherited a two processor 4GB Ultra 60 myself.)
encrypted information (short of a one time pad, which is the only way to get true noise)
You said:
By adding encrypted data to structured data, you're making the image LESS structured.
You are correct. I did describe that a bit backwards. The encrypted data would look like anomalies in an otherwise structured file. Detecting them is difficult, but should not be impossible.
I suppose one other point that's coming out of my rant that I should probably vocalize is that the assumption of "randomness" is an assumption made in a vacuum. If you have nothing else to compare the randomized data against, then the data will be invulnerable to an entropy check. The white elephant is that nothing is truly in a vacuum. One can ask the question, "What does typical 'random' data on a hard drive look like? What does this data look like?" If there is any difference in, say, the distribution of the random values or the entropy of particular values, it can be quite easy to detect the encrypted info.
That I guess is what I'm really getting at. The theory assumes a vacuum. There is no vacuum. (Or spoon for that matter.:-P)
Also, maybe I'm just not deep enough, but I don't understand at all what this has to do with information being destroyed or black holes. This is a matter of information being detected, not destroyed.
The point I'm making is that in order for the original information to be undetectable, it must be destroyed. Destroying information is the process of making it non-retrievable. i.e. Completely random. Of course, there's no such thing as completely random in our Universe. There's a probabilistic nature to things, but even the "white noise" from, say cosmic radiation, carries information about its origins. It just happens to aggregate well enough to appear completely random. Then some space traveler interested in the origin of an encrypted packet reads the distribution and uses a database of celestial events to fingerprint Sol vs. Sirius.
The point is, the data is there and it is detectable. My opinion is that we're in an arms race to develop methods of making data appear undetectable in the short term, but unless we can destroy the original data (which we can't without making it unrecoverable) the data will always show structure. Or perhaps more to the point, "random" data on a hard drive is of a particular type of unstructured structure. (Whether it be from cosmic rays or a PRNG used to clear it.) We just need to detect the apparently unstructured data that's structured differently.:-P
We'll see how far they go with it. If their tool works as well as they claim, it wouldn't be the first time engineering has preceded the scientific theories behind them. Obviously testing the tool helps. If it finds TruCrypt data, that's not a good sign for the theoretical randomness of data. Next interesting question is: How far will TruCrypt be able to go to prevent the tool from detecting data? Will we see an arms race of encryption hiding vs. detection? If so, who will win?
My own feeling is that data smaller than the size of the key may be immune to detection. But larger quantities of data is going to show a pattern. The trick to detection is in understanding how, when, and why that pattern shows up. As I mentioned above, Information Theory already offers a pretty compelling answer for the "why".
Or "How I learned that you can't fight information theory".
A few years ago, I recall arguing with someone here on Slashdot about this very issue. My take on it was that stenography could never be completely successful because there would always be a pattern sticking out from the file. The other poster argued that truly encrypted data should be indistinguishable from white noise. I pointed out that a) stenography disrupted the image coloring and therefore should be detectable by looking for irregularities and b) encrypted information (short of a one time pad, which is the only way to get true noise) has an underlying structure in the data operated on. Since the key repeats the transformation for the length of the data, the distribution of the codes cannot be guaranteed.
i.e. Encrypted information will stand out as structured data.
Which only makes sense when you think about it. Information theory doesn't mess around. You cannot destroy information. (The black hole experiments confirmed that.) Thus the structure of the information will remain, no matter how much you try to obscure its existence.
We never reached an agreement, so I guess we'll have to let this article finally settle it. l-)
The difference is that Apple builds hardware. Serious hardware, not mice and keyboards.
I could be mistaken, but my impression has been that Apple builds all their own MotherBoards, Logic Cards, and possibly even some of the systems chips to provide the clean experience you see with an Apple laptop.
Microsoft doesn't have that experience, because they don't build systems. They license software to companies like Dell, who in turn obtain their motherboards from a third party, who in turn obtain the chipset from a chipset provider. Apple does everything up to the last step themselves. Now they want to do the last step.
This is the next generation of optical storage, not hard drives. It's meant to be the follow up to BluRay discs. (Which already contain a simplified version of holographic technology.) $50/disc is too expensive for the short term, but I imagine the idea is to drive the price down through economics of scale. By the time they've got most of the specialty applications out of the way, they can move on to the early adopters. i.e. The people willing to pay $30/movie to watch Spiderman XI on their ED (extreme definition) television sets.
HTML/CSS/JavaScript is an insufficient platform for Rich Internet Applications (RIA).
There's a reason why I specifically mentioned HTML5. Video, Canvas, Audio, SVG, Networking, Storage, multi-threading, etc. The platform meets and even exceeds the Flash and Silverlight platforms.
Ever since Microsoft got away with a slap on the wrist, Oracle has been buying their way to a monopoly. They give excuses for purchasing competitors (some of which might even be true), but their core aim is to be the big fish in the pond.
Oracle may get some benefit out of BEA's product line or they might trash it. Doesn't matter either way. Oracle eliminated a competitor, bought a market, and is looking to reap the rewards of that maneuver. The tech is secondary.
That being said, the Sun purchase is slightly different. Oracle and Sun have been a strong pairing on the high end of database deployments. Oracle needs Sun and their hardware to survive. It doesn't hurt that owning the business gives Oracle enough tools to hit IBM where it hurts...
(I'll have to visit IBM sometime and see how many bloody stains I can find on the walls. There has got to be some serious head banging going on over there.;-))
IMHO, JavaFX has been a solution looking for a problem. Applets aren't coming back (thank God), so stop trying to create an ideal Applet platform. HTML5 is meeting that need well enough, thanks' much. Pulling funding from the JavaFX project would hardly even be noticable.
Project Looking Glass is one of those things I'd hate to see go, but Sun hasn't exactly done much with it. Oracle needs to decide that they'll support it full hog as a core product or just leave the project to the OSS community. This noncommittal attitude has been leaving the project in limbo.
Now Project Glassfish, that's a whole other ball of wax. Oracle screwed up Orion (the BEST J2EE server back in the day) to insane levels of uselessness under the guise of Oracle Application Server. (Hey look! Oracle is almost as good at naming as Sun!) Glassfish (aka Sun Java System Application Server) is modern, scalable, easy to use, and absolutely wicked when deployed. Oracle would do well to give up on OAS and just let Sun keep doing what they're doing with SJSAS/GlassFish.
I always thought the whole idea of SAS was simply shifting and consolodating the effort of creating and servicing software to (hopefully) lower costs. Not eliminate them.
That would be under the pros category.
There are a lot of advantages to having someone else host your data. But there are also risks. Which RMS did put his finger on, but he's far from the first to do so. If anything, he's blowing the whole thing WAY out of proportion. (Thus the mildly sarcastic tone of my post.)
My basic issue with RMS's logic is that he doesn't want to trust anyone. Because if you don't trust anyone, you can't be double-crossed. Right?
The only problem is, society cannot operate without trust. At some point I have to trust someone else to handle a repetitive task, least I needlessly waste my time. Not to mention the myriad of skills I'd need for basic survival!
Think of it this way: Without trust, we would all be too busy farming, hunting, building our own homes, fabbing our own materials, and providing our own healthcare. Technology would go absolutely nowhere, because just one of those items is a full time job. Anyone not skilled enough in any of those trades would probably suffer a horrible death from starvation, disease, exposure, or predators. Even if people share discoveries ala the GPL, who would have time to examine and build upon the discoveries?
Thankfully, we trust each other. At least enough to where I let someone else farm the food, someone else build my house, someone else provide medical attention to myself and family, etc. I pay for those services with the expectation that my food will not be poison, my house is safe to occupy, and my doctor is a skilled medical practitioner. Society has a number of checks and balances to help verify those levels of trust, and thus we arrive at "good enough".
If there's anything I've learned over the years, save for a small percentage of exceptions, "good enough" is many orders of magnitude better than "superior".:-)
...for spotting the major con of software as a service. I'm sure companies and individuals considering the use of such services will now weigh this con against the pros and develop an informed decision about whether or not a given service is right for them.
For services where personal data is kept, I'm sure that concepts like security, trustworthiness, and portability of data are key concerns.
The Atari Mind controller only measured how much you furrowed your brow. In result, it gave the impression that deep concentration had an effect on the game. In reality, it gave most people headaches.:-P
Sounds like you haven't been following MySQL AB very closely. Their interpretation of the license was that any time you paired a MySQL database with an application, you needed a MySQL commercial license. Only if the application supported but was independent of MySQL would you not need to follow the terms of the license.
MySQL even tried to reinforce the idea by purchasing all the third party drivers and changing the licenses to GPL instead of LGPL or otherwise.
While MySQL's licensing info has changed over the years (interestingly not archived by the WayBack Machine...) even their current page on licensing is designed to steer users toward purchasing a commercial license:
Q3: As a commercial OEM, ISV or VAR, when should I purchase a commercial license for MySQL software?
A: OEMs, ISVs and VARs that want the benefits of embedding commercial binaries of MySQL software in their commercial applications but do not want to be subject to the GPL and do not want to release the source code for their proprietary applications should purchase a commercial license from Sun. Purchasing a commercial license means that the GPL does not apply, and a commercial license includes the assurances that distributors typically find in commercial distribution agreements.
For quite a few legal departments I've worked with, "the GPL does not apply" is magic words to their ears. They will instruct the business to grab the commercial license to get around the restrictions. In addition, there is the MySQL libraries issue I referred to above:
Q4: What is Sun's dual license model for MySQL software?
A: Sun makes its MySQL database server and MySQL Client Libraries available under both the GPL and a commercial license. As a result, developers who use or distribute open source applications under the GPL can use the GPL-licensed MySQL software, and OEMs, ISVs and VARs that do not want to combine or distribute the MySQL software with their own commercial software under a GPL license can purchase a commercial license.
The MySQL forking company is going to have to undo all of the anti-GPL ideas they've been riding, and convince companies that they don't need a commercial license. (Since it's not in the forking company's power to provide one.)
They can't terminate the already-outstanding licenses without a breach of terms.
On the flip side, the forking company can't use the same business model as MySQL AB. Since MySQL owned the copyrights, they could see non-GPLed versions of the software under terms that were more palatable to corporations. To a certain degree, it served their purposes to fuel GPL fears.
Now that the forking company is 100% bound by the GPL, they must attempt to undo any misplaced fears about the GPL and seek to convince companies that what they really want is a support licene, additional tools, or trained consultants.
Generally they would be deployed by and secured by the central engine module. Solar winds would keep them well inflated as long as proper stitching or ribbing is used to secure the blown-up shape. Some sort of counter force (e.g. ion engines) would be needed to occasionally reposition the structure.
That's gonna need to be an *awfully* big collector
Nah. I spoke with a space/nuclear engineer on this once. He had worked it out in grad school using a Brayton cycle engine. (i.e. closed loop gas turbine) The engine itself is extremely power dense and would have more mass for cooling than heating. (Think large fins on the dark side, running fluids through to exhaust heat as black body radiation.)
The trick to collecting large amounts of sunlight would be massive mylar sails. The sails would be deployed as large mirrors. These mirrors would reflect the solar energy toward the power-producing engine. This way you could get a massive footprint in space while still having a relatively light launch package.
His idea was better than mine; which was to construct a massive Stirling engine near the sun to absorb 3GW of power at near-failure temperatures.:-P
...that the DLC model was supposed to be modeled after the mod communities for Quake and Unreal. Yet somehow, I have seen almost no sign of anything that looks like post-release modifications. Studios seem to hold back a bit of content, then release that as DLC. Not exactly the original intent. Especially when the game is incomplete without the DLC.
(Interestingly, Mega Man 9 walked a fine line there. Technically, all the "DLC" was already in the executable. Yet the stuff you paid for was truly above and beyond the primary gameplay. Which made it ideal as either Easter Eggs or DLC. Kudos to Capcom for at least getting that right.)
Slashdot Mirror
Can someone please explain to me how this is NOT a failure?
Star Trek was always known for its strong story telling. Sure, it was sometimes campy and over the top. But the series was built on story. The action was just the frosting.
That was something that Berman never realized. He kept playing down the story in exchange for more action, more outlandish events, more of that adrenaline squeeze. Except that he was bad at it. I mean, really, really bad. Stinking up the screen bad. (Hey look: MACOs! Amazing how those guys never got any screen time, isn't it? Or how about the time Riker used a joystick to save the day? I know, let's have Picard fight himself! Or put 7 of 9 in a fight pit with a WWE wrestler! Yeah, those were great times. *cough*)
Now you're telling me that JJ doesn't suck at it. Therefore it's okay to finish tearing apart the foundations of Star Trek because at least it was a fun ride. Right?
Star Trek stood on its own two feet for 40 years. It was challenged by the networks, challenged by the box office, and challenged by its own actors. Yet the concept survived and is cherished by its fans. The core idea of a better future painted on the rich tapestry of space travel is not something to be ignored. It's something to protect, grow, and find ways to adapt to the changing times. After all, is there any better time to shout out this message than when things seem the darkest?
Instead we have a summer blockbuster. And like all summer blockbusters, it will be forgotten by next summer. It is a sad day for Roddenberry's vision of the future.
You know, that graph is rather amusing. It doesn't portray a crisis, but rather that the industry has been running out of thing to pack on a chip! Over the past 30 years, every generation of processor has meant new features and performance enhancements. For which each generation got hungrier and hungrier for transistors.
Well, now chip design has peaked. Designers have taken all the low-hanging fruit, stripped much of the top of the tree as well, and now are trying to figure out what else to do. Each chip generation still gets optimized more and more, but in many cases they're taking fewer transistors rather than more.
So how does a company with an insane transistor budget keep creating chips that the market will pay a premium for?
Multicore is a bit of a cop-out answer, but an effective one nonetheless. If you've got 2-4x the number of transistors available as your previous generation of chips and nothing to do with it, then multicore is an excellent answer. It has the side effect of stripping value from the high end chips like Xeon, but that can be managed with other marketing tricks. (e.g. Did you notice how long it took for x86-64 support to hit Intel's consumer chips?)
That chart is definitely telling a story. Just not the same story that most viewers would assume. ;-)
I don't think that's the point. The point is that a trusted expert in the industry is the only one with access to the private information. He can then represents the findings on behalf of the RIAA. The defense needs to find its own expert witness to counter any arguments made by the RIAA's expert witness.
At least, that's my understanding of how the proceedings would work. (IANAL)
Maybe I'm thinking of gravity wave experiments, but didn't the researchers have issues with unforeseen field effects the last time they tried this measurement?
I've seen the 3000 series with 8 procs or so go for prices near that. Plus you can get similarly configured Sun workstations for less money. (I inherited a two processor 4GB Ultra 60 myself.)
Check out http://www.anysystem.com/ sometime. You can get REALLY cheap Sun hardware there.
Thanks for not reading what I wrote. :-/
You said:
You are correct. I did describe that a bit backwards. The encrypted data would look like anomalies in an otherwise structured file. Detecting them is difficult, but should not be impossible.
I suppose one other point that's coming out of my rant that I should probably vocalize is that the assumption of "randomness" is an assumption made in a vacuum. If you have nothing else to compare the randomized data against, then the data will be invulnerable to an entropy check. The white elephant is that nothing is truly in a vacuum. One can ask the question, "What does typical 'random' data on a hard drive look like? What does this data look like?" If there is any difference in, say, the distribution of the random values or the entropy of particular values, it can be quite easy to detect the encrypted info.
That I guess is what I'm really getting at. The theory assumes a vacuum. There is no vacuum. (Or spoon for that matter. :-P)
The point I'm making is that in order for the original information to be undetectable, it must be destroyed. Destroying information is the process of making it non-retrievable. i.e. Completely random. Of course, there's no such thing as completely random in our Universe. There's a probabilistic nature to things, but even the "white noise" from, say cosmic radiation, carries information about its origins. It just happens to aggregate well enough to appear completely random. Then some space traveler interested in the origin of an encrypted packet reads the distribution and uses a database of celestial events to fingerprint Sol vs. Sirius.
The point is, the data is there and it is detectable. My opinion is that we're in an arms race to develop methods of making data appear undetectable in the short term, but unless we can destroy the original data (which we can't without making it unrecoverable) the data will always show structure. Or perhaps more to the point, "random" data on a hard drive is of a particular type of unstructured structure. (Whether it be from cosmic rays or a PRNG used to clear it.) We just need to detect the apparently unstructured data that's structured differently. :-P
We'll see how far they go with it. If their tool works as well as they claim, it wouldn't be the first time engineering has preceded the scientific theories behind them. Obviously testing the tool helps. If it finds TruCrypt data, that's not a good sign for the theoretical randomness of data. Next interesting question is: How far will TruCrypt be able to go to prevent the tool from detecting data? Will we see an arms race of encryption hiding vs. detection? If so, who will win?
My own feeling is that data smaller than the size of the key may be immune to detection. But larger quantities of data is going to show a pattern. The trick to detection is in understanding how, when, and why that pattern shows up. As I mentioned above, Information Theory already offers a pretty compelling answer for the "why".
"Steganography." Excuse me. I seem to have repeated an error.
Or "How I learned that you can't fight information theory".
A few years ago, I recall arguing with someone here on Slashdot about this very issue. My take on it was that stenography could never be completely successful because there would always be a pattern sticking out from the file. The other poster argued that truly encrypted data should be indistinguishable from white noise. I pointed out that a) stenography disrupted the image coloring and therefore should be detectable by looking for irregularities and b) encrypted information (short of a one time pad, which is the only way to get true noise) has an underlying structure in the data operated on. Since the key repeats the transformation for the length of the data, the distribution of the codes cannot be guaranteed.
i.e. Encrypted information will stand out as structured data.
Which only makes sense when you think about it. Information theory doesn't mess around. You cannot destroy information. (The black hole experiments confirmed that.) Thus the structure of the information will remain, no matter how much you try to obscure its existence.
We never reached an agreement, so I guess we'll have to let this article finally settle it. l-)
The difference is that Apple builds hardware. Serious hardware, not mice and keyboards.
I could be mistaken, but my impression has been that Apple builds all their own MotherBoards, Logic Cards, and possibly even some of the systems chips to provide the clean experience you see with an Apple laptop.
Microsoft doesn't have that experience, because they don't build systems. They license software to companies like Dell, who in turn obtain their motherboards from a third party, who in turn obtain the chipset from a chipset provider. Apple does everything up to the last step themselves. Now they want to do the last step.
This is the next generation of optical storage, not hard drives. It's meant to be the follow up to BluRay discs. (Which already contain a simplified version of holographic technology.) $50/disc is too expensive for the short term, but I imagine the idea is to drive the price down through economics of scale. By the time they've got most of the specialty applications out of the way, they can move on to the early adopters. i.e. The people willing to pay $30/movie to watch Spiderman XI on their ED (extreme definition) television sets.
There's a reason why I specifically mentioned HTML5. Video, Canvas, Audio, SVG, Networking, Storage, multi-threading, etc. The platform meets and even exceeds the Flash and Silverlight platforms.
This ain't your grandma's HTML, boay!
Ever since Microsoft got away with a slap on the wrist, Oracle has been buying their way to a monopoly. They give excuses for purchasing competitors (some of which might even be true), but their core aim is to be the big fish in the pond.
Oracle may get some benefit out of BEA's product line or they might trash it. Doesn't matter either way. Oracle eliminated a competitor, bought a market, and is looking to reap the rewards of that maneuver. The tech is secondary.
That being said, the Sun purchase is slightly different. Oracle and Sun have been a strong pairing on the high end of database deployments. Oracle needs Sun and their hardware to survive. It doesn't hurt that owning the business gives Oracle enough tools to hit IBM where it hurts...
(I'll have to visit IBM sometime and see how many bloody stains I can find on the walls. There has got to be some serious head banging going on over there. ;-))
IMHO, JavaFX has been a solution looking for a problem. Applets aren't coming back (thank God), so stop trying to create an ideal Applet platform. HTML5 is meeting that need well enough, thanks' much. Pulling funding from the JavaFX project would hardly even be noticable.
Project Looking Glass is one of those things I'd hate to see go, but Sun hasn't exactly done much with it. Oracle needs to decide that they'll support it full hog as a core product or just leave the project to the OSS community. This noncommittal attitude has been leaving the project in limbo.
Now Project Glassfish, that's a whole other ball of wax. Oracle screwed up Orion (the BEST J2EE server back in the day) to insane levels of uselessness under the guise of Oracle Application Server. (Hey look! Oracle is almost as good at naming as Sun!) Glassfish (aka Sun Java System Application Server) is modern, scalable, easy to use, and absolutely wicked when deployed. Oracle would do well to give up on OAS and just let Sun keep doing what they're doing with SJSAS/GlassFish.
That would be under the pros category.
There are a lot of advantages to having someone else host your data. But there are also risks. Which RMS did put his finger on, but he's far from the first to do so. If anything, he's blowing the whole thing WAY out of proportion. (Thus the mildly sarcastic tone of my post.)
My basic issue with RMS's logic is that he doesn't want to trust anyone. Because if you don't trust anyone, you can't be double-crossed. Right?
The only problem is, society cannot operate without trust. At some point I have to trust someone else to handle a repetitive task, least I needlessly waste my time. Not to mention the myriad of skills I'd need for basic survival!
Think of it this way: Without trust, we would all be too busy farming, hunting, building our own homes, fabbing our own materials, and providing our own healthcare. Technology would go absolutely nowhere, because just one of those items is a full time job. Anyone not skilled enough in any of those trades would probably suffer a horrible death from starvation, disease, exposure, or predators. Even if people share discoveries ala the GPL, who would have time to examine and build upon the discoveries?
Thankfully, we trust each other. At least enough to where I let someone else farm the food, someone else build my house, someone else provide medical attention to myself and family, etc. I pay for those services with the expectation that my food will not be poison, my house is safe to occupy, and my doctor is a skilled medical practitioner. Society has a number of checks and balances to help verify those levels of trust, and thus we arrive at "good enough".
If there's anything I've learned over the years, save for a small percentage of exceptions, "good enough" is many orders of magnitude better than "superior". :-)
...for spotting the major con of software as a service. I'm sure companies and individuals considering the use of such services will now weigh this con against the pros and develop an informed decision about whether or not a given service is right for them.
For services where personal data is kept, I'm sure that concepts like security, trustworthiness, and portability of data are key concerns.
The Atari Mind controller only measured how much you furrowed your brow. In result, it gave the impression that deep concentration had an effect on the game. In reality, it gave most people headaches. :-P
You mean you have to use your hands? That's a baby's toy!
Sounds like you haven't been following MySQL AB very closely. Their interpretation of the license was that any time you paired a MySQL database with an application, you needed a MySQL commercial license. Only if the application supported but was independent of MySQL would you not need to follow the terms of the license.
MySQL even tried to reinforce the idea by purchasing all the third party drivers and changing the licenses to GPL instead of LGPL or otherwise.
While MySQL's licensing info has changed over the years (interestingly not archived by the WayBack Machine...) even their current page on licensing is designed to steer users toward purchasing a commercial license:
For quite a few legal departments I've worked with, "the GPL does not apply" is magic words to their ears. They will instruct the business to grab the commercial license to get around the restrictions. In addition, there is the MySQL libraries issue I referred to above:
The MySQL forking company is going to have to undo all of the anti-GPL ideas they've been riding, and convince companies that they don't need a commercial license. (Since it's not in the forking company's power to provide one.)
On the flip side, the forking company can't use the same business model as MySQL AB. Since MySQL owned the copyrights, they could see non-GPLed versions of the software under terms that were more palatable to corporations. To a certain degree, it served their purposes to fuel GPL fears.
Now that the forking company is 100% bound by the GPL, they must attempt to undo any misplaced fears about the GPL and seek to convince companies that what they really want is a support licene, additional tools, or trained consultants.
Generally they would be deployed by and secured by the central engine module. Solar winds would keep them well inflated as long as proper stitching or ribbing is used to secure the blown-up shape. Some sort of counter force (e.g. ion engines) would be needed to occasionally reposition the structure.
Nah. I spoke with a space/nuclear engineer on this once. He had worked it out in grad school using a Brayton cycle engine. (i.e. closed loop gas turbine) The engine itself is extremely power dense and would have more mass for cooling than heating. (Think large fins on the dark side, running fluids through to exhaust heat as black body radiation.)
The trick to collecting large amounts of sunlight would be massive mylar sails. The sails would be deployed as large mirrors. These mirrors would reflect the solar energy toward the power-producing engine. This way you could get a massive footprint in space while still having a relatively light launch package.
His idea was better than mine; which was to construct a massive Stirling engine near the sun to absorb 3GW of power at near-failure temperatures. :-P
...that the DLC model was supposed to be modeled after the mod communities for Quake and Unreal. Yet somehow, I have seen almost no sign of anything that looks like post-release modifications. Studios seem to hold back a bit of content, then release that as DLC. Not exactly the original intent. Especially when the game is incomplete without the DLC.
(Interestingly, Mega Man 9 walked a fine line there. Technically, all the "DLC" was already in the executable. Yet the stuff you paid for was truly above and beyond the primary gameplay. Which made it ideal as either Easter Eggs or DLC. Kudos to Capcom for at least getting that right.)