I only agree partially. There seems to be a sense that "anything goes" in fantasy, and I think we're on the same page on that.
As for fantasy being sci-fi with "magic" substituted for "technology"; I disagree, but I recognize we can define the categories any way we want. If there is a *meaningful* and *useful* distinction between them, then I think there has to be a difference other than how we label things we don't know how to do in *our* world. That doesn't mean that anything goes in fantasy, it means that the rules are different.
As an extreme example, consider fairy tales. If you have three sons who set out to fulfill a task and the first two fail, the third *must* succeed. He is also expected to do things in a certain different way. The third son is not only "virtuous", his key attribute is open-mindedness. It is an absolute, firm rule that he must be open minded where his brothers are closed minded. He must attempt the way they think impossible; he must accept the advice they reject; he must face what they ignore, be it a strange little man by the side of the road, or the ogre in his lair. It's absolutely, positively *necessary*.
In my view, a true fantasy has to have these kinds of constraints, although they may not be as well established by tradition as the third son succeeds rule.
This is "Bing" all over again. Personally, I hate it, but Microsoft *says* its better, and Bill Gates is the world's richest man so who am I to argue? It hurts, but it *must* be good for me.
No, the use of "positron" was completely technobabble. However, once he used the term, he used it consistently throughout every work in which it appeared. That's the key.
The real innovation was the three laws. There is no *physically* plausible reason that these laws could not be violated by a working positronic brain. One gets the idea that it's just more trouble than its worth to go back to the basic design. Indeed many of the story seem to suggest that there are ways around the three laws for clever humans, so why invent a whole new technology? That's psychologically and economically plausible.
But really the laws themselves are more technobabble, but it's *consistently used*. It is *never* violated. Ever.
And there are good storytelling reasons for this. The three laws are thematically necessary, because otherwise we'd be constantly looking for the standard "rampaging robot" stories and solutions. It adds pleasing complications that readers can anticipate and understand.
Well, for *any* story to entertain, it has to make sense.
Even fantasy.
The problem with technobabble (as you point out) is that it undermines the logic of a science fiction story. When the writer can pull a reverse polarization tachyon burst rabbit out of his main deflector array hat whenever he needs to get the hero out of trouble, he is signaling that he'll resort to anything to get the hero where he wants him by the end of act 3. As a reader, one has to wonder, "why am I bothering to *understand* all this stuff if it can be changed whenever it's expedient?" That problem isn't limited to the purported explanation of the technology; rampant use of technobabble to solve plot dilemmas undermines the characterization and story itself.
Now personally, I don't have any fixed opinions on whether a Deus Ex Machina is a bad thing. Lord of the Rings climaxes with what could be reasonably characterized as D.E.M.: Frodo fails in the quest, and Gollum's treachery allows him to succeed. Now I realize a counter-argument could be asserted that Frodo condemned Gollum to throw himself into the fire when he showed Gollum mercy, but lets set that aside for a bit. LotR *had* to end with Frodo *morally* failing, otherwise the ending would fail to demonstrate Tolkien's entire point. Really, LotR is the last salvo in the Reformation/Counter-Reformation debate: it's about the relationship of good works and grace in salvation. It is the duty of every conscious, moral being to give the last full measure of devotion, and for Frodo that is not a euphemism for "death". It literally means he must give *all* the devotion is capable of giving to his task before grace becomes operative.
The point is, it's not only logically *consistent*; it's *necessary* for the task to exceed Frodo's ability to achieve through his own strength and cleverness. Therefore something like a D.E.M. is *mandated* for that story; it is not *utterly* unconnected to the Frodo's past actions, but that's true in most cases where blatant uses of D.E.M. occur. Having the hero succeed through consequences he is not conscious of violates the particular standards of taste that absolutely ban the use of D.E.M. People who insist on that as a hard and fast rule usually don't like LotR.
So fantasy and science fiction *both* have to be logical. The kind logic is different. When a science fiction character straps on an anti-grav belt, we assume that there is not just the *physics* to back that up -- after all how is that different from magic? We also assume the existence of that device implies a whole bunch of social science we're perfectly familiar with. We assume there is an economic system which produces them according to the same supply and demand rules that drives *our* world to manufacture and market pogo sticks. We assume that there are industrial entities that specialize in various aspects of the belt, from the chemical companies that produce the polymer webbing fabric to the companies that specialize in the switches and knobs. There's probably an industrial designer who figured out what geometry would be most ergonomic for the control pad.
What's more, we assume the belt comes with standard *psychology*. We don't assume the belt works differently depending on the wearer's state of mind -- or if it does, we insist on a consistent sounding explanation (even if it is technobabble, it becomes a *rule* for our universe).
Do people who have fear of heights have trouble using the anti-grav belt? Maybe, or maybe not, but it's a point that has to be dealt with if a character uses it for the first time (we can assume the Galactic Patrol Academy has dealt with those problems as far as its cadets are concerned). Jules Verne brought this very issue up in his book "Robur the Conquerer", which was kind of like 20,000 leagues under the sea but with an airship rather than a submarine. He points out that people with acrophobia by in large *don't* suffer from ascending in a balloon the way they suffer at the edge of a cliff, and
It's not that simple. We *aren't* going to stop using tungsten. What's going to happen is the demand curve is going to shift.
Economics is about marginal behavior. Regimes that don't treat their country as a piggy bank will get a better price for their tungsten. It will reduce the incentive to effect what amounts to a LBO of a country so that the mineral wealth can be liquidated.
Anyhow, Africa having an industrial boom? Are you serious? That would be great, but I'm not holding my breath. Africa being a threat to China or even the US industrially is a pipe dream in the short term. In the long term, it would be *great*, and I for one would be up for a chorus of "Kum Bay Yah" if that ever happened. In the long term, that means richer customers for *our* goods and services.
Personally, I don't think there is any magic wand we can wave and make everything wonderful. We had this debate for decades over South Africa, and eventually it was the strain of going over this stuff over and over and over that finally made the regime crack. It's still not paradise in South Africa, but at least what mess there is is the *people's* mess.
It's instructive to compare the success of economic sanctions in effecting regime change in South Africa (where it worked) and Cuba (where it failed). The Cuban sanctions were much harsher. It makes ironic sense, when you remember that economic behavior is driven by marginal costs and benefits.
Certainly not. If that were true, then Fox News would be an advertising company. *The New Yorker* would be an advertising company.
Like those other companies, Google is a *content* company. The difference is that their flagship product is metadata. The thing that gives them the kill advantage in the content business is scale. Under the covers, they're about storing and distributing vast volumes and varieties of data. Over the covers, their APIs and products are about driving demand for that.
Hardly. You'd have to at least to be able to build the software in order to verity you'd been given the real McCoy.
In any case, even in the scenario you describe, the exact software is not as important as a clear description of what it *does*. The experts would need to provide that at much so that the lawyers and (if necessary) the jury would be able to make some determination of whether the bricking was intentional. I'm assuming there isn't any code in there like this:
// Uncooment the next line to brick jailbroken handsets #define ILLEGALLY_SCREW_OUR_CUSTOMERS 1
Given that some level of analysis is needed to support a legal judgment, then the cat will be out of the bag. There are lots of *very* smart people in the world who'd work out how to bust the thing wide open, just for the challenge.
They all have GPS, touch screens (some have keyboards), 3G, accelerometers blah, blah, blah. So it's not like writing an J2ME midlet and wondering how many buttons the user will have and whether you'll have 100K of RAM to run in.
Android's model is not to be a PC -- that PocketPC Phone Edition. Android is all about moving data around, because that's what business Google is in. That's Google's killer advantage. They're not a search engine company, they're a data management company. It's all about having the information you need at your fingertips.
In an ideal world, you could tether your PC to your android phone. And if Google has its way, that'll be standard.
What Google wants is for the carriers to be in the commodity bandwidth business. That's the reasoning behind Android and Chromium. With the iPhone kicking their smartphone ass, Google's the only game in town for the carriers, and eventually they'll be forced into that business, the way that so many software companies ended up embracing open source because they couldn't make a living at the old business model with a MS monopoly.
I'm a new Droid owner too. I agree about the games, but could not possibly care less.
There are some design issues with Android, particularly on the Droid phone which only has 256MB of built-in storage, and executables for the time being have to be stored there. I've heard game developers complain about this, but what it means is you've got to split out code and data so the data can live on the SD card.
In any case, I have *no* intention of every buying any games for Android. I'm more interested in developing enterprise apps for Android.
I think that'll be the market segmentation in the near future. Media and games will be iPhone territory. "Serious" data management and enterprise apps on Android, where the platform is not controlled by some third party's apparachniks and you can take your java libraries with you to other platforms.
Actually, the goal of saving energy/reducing pollution from energy generation would be better served by taxing energy. You wouldn't have to have a TV set power consumption regulation office, you just take whatever the electric company charges and slap a percentage on top of that. Then you except commercial uses, and give everyone a standard tax rebate so that it's possible for nearly everyone to avoid the the tax by using electricity moderately.
Yes, it's another case of using the tax code to achieve something other than bringing in revenue, but it does the same thing that *regulation* would do, only across *all* uses of electric power, and without forcing anybody to change anything. If you absolutely MUST have that gigantic plasma TV, and absolutely DON'T want to pay without tax, you can go without lights or a refrigerator.
Black and white thinking alert: is the question one of bearing *no* responsibility?
Everything we do in life has a risk. We used to send my late brother, who was mentally retarded, out on a recreation van for field trips like bowling. One day a careless truck driver went through a red light and hit the van, putting my brother into the hospital for over a month.
Now we *knew* that something like that was a possibility when we put him on that van. We made a determination that the statistical risk was worth it, and we lost. Does that mean the truck driver is off the hook?
Choosing to live below sea level is risky, but it is not certain death and destruction over the anticipated lifetime of your residency there. Most of Holland is below sea level. But it is a risk. The question is did somebody unconscionably *alter* that risk?
The customer reaction illustrates that the following is a bad business model: creating a service like Second Life for people who have time to waste on services like Second Life.
Whether or not the "inventor" is capable of producing a device or program is irrelevant. The question is whether he has invented anything.
This is not an easy question. Inventions are almost always composed of previous inventions. Back when mechanical timepieces were being developed to improve navigation, inventors were constantly tinkering with ways to improve them. These were arrangements of preexisting machine parts like levers and springs. So does *every* distinct mechanical watch design amount to an "invention" just because it is unique?
No -- the ability to design (much less build) something is completely unrelated to whether you can invent something.
It seems to me that an *invention* has to embody an original insight into the problem. Lest I be pushing the semantic ambiguity onto a different word, I'll make a stab at what I think "insight" means in the context of invention:
Insight is an idea that leads to a reformulation of a problem, rather than restatements of existing solutions to it.
In mechanical timekeeping, the idea that a *wheel* could act like a pendulum alters the problem. Before that realization the problem would have been how to deal with the mechanical inconvenience of a weighted rod, or how to balance friction and force to get a consistent result without a pendulum.
In this case we have the idea of a sparkgraph, stated in terms of a common design pattern: the observer pattern. If you *have* a sparkgraph in software, you must update it *somehow*; either by manual intervention by the user or by reaction to changes in data. As soon as you decide to make sparkgraphs available to the user, the process of design *forces* you to make the choice one way or the other. You might have the only software package robustly designed enough to give you the option of automatic update, but the choice itself is a generic one forced on you by preexisting design conceptions. You haven't created any *new* way of conceptualizing the software architecture or user interface.
This requirement of insight is, by the way, why I think software patents are a bad idea. It's not that we don't invent things, it's the opposite. We invent things *constantly*. As software designers that's our job, to create new conceptualizations of problems. The problem is that we generate and discard so many potentially useful ideas that it is virtually certain with enough of us working on various problems, somebody has come up with a lot of the same things independently. That's not quite the same as saying the ideas are "obvious". It's quite difficult to come up with a good conceptualization of a problem and not many people can do it. That's what makes working in this field interesting.
So why is software engineering different than other fields of "inventing"? I think it's because the flexibility of computers as a platform for expressing useful creative ideas makes generating many alternative problem conceptualizations worthwhile.
So we *do* invent things all the time in software design. Despite this, an application of an existing design pattern to a useful feature doesn't quality as an "invention".
Webapps don't work if you are going into a disaster zone. You can't count on any infrastructure other than a sat phone, which you can't lug around with you. I've worked with guys tracking emerging diseases in the bush; they have to lug in everything using native porters -- just like in the old Tarzan movies -- and run their diagnostic machinery and serves on solar power.
Believe me, I know what I'm doing with this stuff, at least. You can't assume anything; paper would be ideal in this respect but you want to get the information out faster than it can be faxed and reentered. A team with handhelds sharing a couple of sat phones in a protected place works. Seriously, these guys *literally* have to navigate minefields.
I'm guessing that's part of the strategy here. Just because the apps are "web apps" doesn't mean this has to be a thin client. The apps can run locally an synchronize data when network is available.
In any case, a thin client might not be such a bad thing. Google pretty much has made its business out of succeeding at things others have tried, but getting the details and timing right.
Timing is everything in tech products. You might have the right solution, but unless the other things are aligned, you're spitting into the win. What has changed since the the early 90s when the thin client idea was first floated? Plenty. And plenty has happened in the past several years that makes thin clients -- especially ones that can replicate apps off the net -- attractive. Wifi is ubiquitous, and lots of people are buying data plans for their smart phones -- carriers are even offering bundles with "free" netbooks.
Why is Google doing Android? Because their future depends on a world with ubiquitous, cheap, net-neutral wireless access they can sell services over. With iPhone mopping up the competition in the smartphone arena, Google has an opportunity to sell a phone that is open -- unlike Windows Mobile -- and that reinforces the future it prefers. I'll bet ChromiumOS is aimed at the same problem: enticing the carriers into the commodity bandwidth game.
Think about how nicely something like that would work with GSM. Let's say that where you don't have coverage, it still works though something like Gears. When you do, your data gets backed up to Google. When you drop your Chromium netbook, you take the SIM out and buy a new one for $299; or maybe get a swap replacement as the old one gets fixed. In any case its like nothing happened. If you accidentally delete your thesis, or it is deleted by malware, or of somebody steals your netbook and deletes all your work, a backup is stored on Google's mighty data storage network. That's another key to the puzzle: Google's ability to manage vast amounts of data is one of its competitive advantages, and another reason they prefer a world of cheap networking.
I disagree. The unprofitable applications will be unprofitable on other phones too.
That's not necessarily true. Look at the whole problem with Flash. I understand why Apple doesn't want people deploying virtual machines or interpreters through the App store, because it undermines their monopoly on selling apps to users, but sometimes that's simply the most efficient way to build an app.
I once did a mobile application for humanitarian relief. You wouldn't believe the number of wrinkles involved in something like siting a refugee camp. I would have had *hundreds*, if not *thousands* of screens to test if I did it in the standard VB bound control style. The only way to do it economically was to have a model driven data collection engine. That way I only had fewer than a dozen UI forms to test. It was purely an engineering decision.
Now if I wanted to deploy that app on an iPhone, it very likely would not be allowed. I would have had twenty times the programming and maybe a hundred times the testing to get it working in a way Apple would accept. It would not have been profitable for me to develop an application for the iPhone, even if the result looked exactly the same to the users and every humanitarian relief worker on the planet carried an iPhone.
The only ones to "stick it out" are the ones who are the most likely to profit. This tends to be apps people mostly want.
Speaking as somebody currently living on the proceeds of a software company I sold, this is a naive view.
It's not enough to have an app people want. You have to (a) sell it for enough money to make a profit and (b) keep support costs down enough so your sales profit doesn't disappear.
Right off the bat, when you sell software, it's not a matter of "a lot of people wanting" your product; it's how many want it at the price you set. Let's say you have a product that nobody would be willing to spend much money for, but you could sell it for about the price of a cup of coffee. Let's suppose the product is cheap to make and after you sell it your customers never call you. You can make money with that.
Suppose you come up with a ringtone. It takes you a week to get it into whereever you are selling it, then 5000 customers download it at $1.99, of which you clear $1.00 after the store gets its cut. $5000 for a week of work isn't going to make you rich, but it's a respectable payday. You can live off of that kind of project.
Is this something that people "want"? Well, sure, so long as its priced cheap. The key is that of those 5000 customers, you'll hear from maybe one or two, and you can just pay them $2.00 to go away.
Now suppose you (like I did) develop some kind of mobile data collection app that drives important enterprise decisions. That's pretty damned valuable. You can easily convince a company to pay you $500 *per seat*. The problem is that even if you could wish the software into existence, the customers need more than $500 per seat of support. In fact that's why an open source model works very well for critical systems -- you give the software away and charge for the real expensive parts. In any case, my calculations showed that we broke even on a $10,000 sale, after all was said and done, so we might as *well* have given the software away. We typically sold consulting services at anywhere from $20,000 to $50,000 a pop, which was where we made our money. Believe me, when you've got a team of six engineers, a $20,000 project doesn't look so big.
The point is that the "build a better mousetrap" theory is simply wrong.
Your ringtones and iFarts are bottom feeders in the world of app development. They are profitable for their developers precisely because users don't care very much about them. Price a product like that low enough and you can make money.
The kind of apps that developers garner respect and admiration for developing are a different kettle of fish. It's *hard* to make a profit selling apps that people really care about, because customers demand a relationship with you. That's expensive.
The last thing you need is a third party inserting itself into that expensive and delicate process -- especially an opaque, unpredictable one. You work with your customers and discover they really need some extra functionality. You build it, then have to wait to find out whether you can sell it? That's nuts. You need that like you need a hole in the head.
And this is even worse: you make a portfolio of apps, and then you can't sell them to a different developer? That's a critical exit strategy for many small developers. They have the vision and brains to create an app, but don't have the size to support it. So they develop and market it, and sell it to somebody who is already supporting apps for the main customer base. That's what I did when I sold *my* business. When I had more customers that I could know personally, it wasn't fun anymore so I told one company that if they didn't buy the software I'd sell it their competitor.
Basically, what Apple is telling is that the iPhone is *still* not a platform. It's a music playing phone that can also run toys like iFart.
Sure, but that's supposing you don't count on doing anything very... relational. For simple backing stores of to store and retrieve form data, maybe. But I've run into problems with Access "front ends" that try to optimize stuff on the back end and screw up because the genius in charge of the feature doesn't understand what "null" is supposed to mean, or doesn't know the difference between a candidate key and an unique index (also null related -- most horrible mistakes in RDBMS implementations have misunderstandings about null involved somehow). That's bad enough when you suddenly see duplicate rows retrieved -- but when you update data...
Now you might not run into a problem because of the way you use Access. Good for you. Continue using your Access front ends so long as they work, just check very carefully whenever anything changes (that includes applying patches pushed out by Microsoft Update). Access is to databases what Microsoft Backup was to backing up -- it's fine, just so long as you can live with it not working unexpectedly.
Chances are, if the kinds of things you are doing today aren't problems, they probably won't be problems tomorrow. If simple form backing gets broken in an Access or MSSQL release, somebody is going to notice. But getting *dependent* on Access is not a good thing, because if you ever need to do something more you're going to reach of that tool and get burned. Same goes for MSSQL. Aside from the fact that T-SQL is an non-orthogonal POS (really, whatever optimization benefits it gets from this aren't worth it), strange things happen if you do something they haven't tested, like put a bound parameter in a subquery.
It's easy enough these days to do what Access does with more reliable tools.
What I've seen is that some chargers power any USB powered equipment (including those on my PCs and laptops) and other wall and car chargers only power *some* USB powered equipment. I'm guessing what's going on here is that some equipment (usually expensive thingies) refuse to run off an unregulated supply. I've seen the same thing happen with a battery powered USB charger I whipped up. Some equipment won't recognize it until the batteries are drained a bit. That includes my new droid phone.
With respect to turn-by-turn navigation, I find the GPS is right on, but your mileage may vary with the accuracy of base maps in some locales. The big problem is that the software, while useful, is not really all that polished for car navigation, compared to your basic, cheap sub $100 car GPS unit. That's fine with me, because I *have* a cheap car unit that works well for me, so having one on my phone is just a nice-to-have.
As for Outlook, after years of having a phone that would work beautifully if I wanted to set up an Exchange server, I now have usable integration with my desktop computers via Google plugins to my Linux PIM software. So I'm happy.
As far as the contact sorting business is concerned, I agree this should be last name first, but it hardly matters if you have more than a couple dozen contacts. I second the call for HCI support. I haven't had problem with my Bluetooth headset, and as far as hands-free dialing is concerned it's not an issue for me, as I don't use the phone while I'm driving.
Overall, I'm very happy with this phone, although it could be better. I think the IPhone onscreen keyboard works better, and I miss multi-touch, but I like the openness of the platform. It wouldn't be hard at all to write your own contact application if you wanted to. Thus far I haven't had to struggle with the phone because the manufacturer or the carrier wants me to do things a certain way or to buy or use certain services. That's the way I like it. *It's my damn phone* so I want to use it the way I want. The only other complaint is having to upgrade to a wireless data service when I'd prefer to use only WiFi, but that's pretty standard for now.
I am responding to the asserted need for a "short term scientific stimulus".
The position I am taking is that no such thing is possible, and that attempting it is a bad idea. I don't think that it is inconsistent to agree that employment must lag while maintaining that focusing on short term growth makes that lag worse.
Well, the title of your article is "How to make your 50-MIPS Workstation Run Like a 4.77MHz IBM PC"
Since the CPU in my laptop is rated at over 4000 Vax MIPS, I'll happily throw 1-2% of that away to get the benefits of proven software. Most of the time one or the other of the cores is close to zero utilization anyway.
What I'd like to see is simpler security setup (without sacrificing features or security of course). That's when you say "there has to be an easier way". It's bad when tunneling a protocol through ssh is the *easy* way.
Slashdot Mirror
I only agree partially. There seems to be a sense that "anything goes" in fantasy, and I think we're on the same page on that.
As for fantasy being sci-fi with "magic" substituted for "technology"; I disagree, but I recognize we can define the categories any way we want. If there is a *meaningful* and *useful* distinction between them, then I think there has to be a difference other than how we label things we don't know how to do in *our* world. That doesn't mean that anything goes in fantasy, it means that the rules are different.
As an extreme example, consider fairy tales. If you have three sons who set out to fulfill a task and the first two fail, the third *must* succeed. He is also expected to do things in a certain different way. The third son is not only "virtuous", his key attribute is open-mindedness. It is an absolute, firm rule that he must be open minded where his brothers are closed minded. He must attempt the way they think impossible; he must accept the advice they reject; he must face what they ignore, be it a strange little man by the side of the road, or the ogre in his lair. It's absolutely, positively *necessary*.
In my view, a true fantasy has to have these kinds of constraints, although they may not be as well established by tradition as the third son succeeds rule.
Gee.
Well, I guess that's that, then.
This is "Bing" all over again. Personally, I hate it, but Microsoft *says* its better, and Bill Gates is the world's richest man so who am I to argue? It hurts, but it *must* be good for me.
No, the use of "positron" was completely technobabble. However, once he used the term, he used it consistently throughout every work in which it appeared. That's the key.
The real innovation was the three laws. There is no *physically* plausible reason that these laws could not be violated by a working positronic brain. One gets the idea that it's just more trouble than its worth to go back to the basic design. Indeed many of the story seem to suggest that there are ways around the three laws for clever humans, so why invent a whole new technology? That's psychologically and economically plausible.
But really the laws themselves are more technobabble, but it's *consistently used*. It is *never* violated. Ever.
And there are good storytelling reasons for this. The three laws are thematically necessary, because otherwise we'd be constantly looking for the standard "rampaging robot" stories and solutions. It adds pleasing complications that readers can anticipate and understand.
Well, for *any* story to entertain, it has to make sense.
Even fantasy.
The problem with technobabble (as you point out) is that it undermines the logic of a science fiction story. When the writer can pull a reverse polarization tachyon burst rabbit out of his main deflector array hat whenever he needs to get the hero out of trouble, he is signaling that he'll resort to anything to get the hero where he wants him by the end of act 3. As a reader, one has to wonder, "why am I bothering to *understand* all this stuff if it can be changed whenever it's expedient?" That problem isn't limited to the purported explanation of the technology; rampant use of technobabble to solve plot dilemmas undermines the characterization and story itself.
Now personally, I don't have any fixed opinions on whether a Deus Ex Machina is a bad thing. Lord of the Rings climaxes with what could be reasonably characterized as D.E.M.: Frodo fails in the quest, and Gollum's treachery allows him to succeed. Now I realize a counter-argument could be asserted that Frodo condemned Gollum to throw himself into the fire when he showed Gollum mercy, but lets set that aside for a bit. LotR *had* to end with Frodo *morally* failing, otherwise the ending would fail to demonstrate Tolkien's entire point. Really, LotR is the last salvo in the Reformation/Counter-Reformation debate: it's about the relationship of good works and grace in salvation. It is the duty of every conscious, moral being to give the last full measure of devotion, and for Frodo that is not a euphemism for "death". It literally means he must give *all* the devotion is capable of giving to his task before grace becomes operative.
The point is, it's not only logically *consistent*; it's *necessary* for the task to exceed Frodo's ability to achieve through his own strength and cleverness. Therefore something like a D.E.M. is *mandated* for that story; it is not *utterly* unconnected to the Frodo's past actions, but that's true in most cases where blatant uses of D.E.M. occur. Having the hero succeed through consequences he is not conscious of violates the particular standards of taste that absolutely ban the use of D.E.M. People who insist on that as a hard and fast rule usually don't like LotR.
So fantasy and science fiction *both* have to be logical. The kind logic is different. When a science fiction character straps on an anti-grav belt, we assume that there is not just the *physics* to back that up -- after all how is that different from magic? We also assume the existence of that device implies a whole bunch of social science we're perfectly familiar with. We assume there is an economic system which produces them according to the same supply and demand rules that drives *our* world to manufacture and market pogo sticks. We assume that there are industrial entities that specialize in various aspects of the belt, from the chemical companies that produce the polymer webbing fabric to the companies that specialize in the switches and knobs. There's probably an industrial designer who figured out what geometry would be most ergonomic for the control pad.
What's more, we assume the belt comes with standard *psychology*. We don't assume the belt works differently depending on the wearer's state of mind -- or if it does, we insist on a consistent sounding explanation (even if it is technobabble, it becomes a *rule* for our universe).
Do people who have fear of heights have trouble using the anti-grav belt? Maybe, or maybe not, but it's a point that has to be dealt with if a character uses it for the first time (we can assume the Galactic Patrol Academy has dealt with those problems as far as its cadets are concerned). Jules Verne brought this very issue up in his book "Robur the Conquerer", which was kind of like 20,000 leagues under the sea but with an airship rather than a submarine. He points out that people with acrophobia by in large *don't* suffer from ascending in a balloon the way they suffer at the edge of a cliff, and
It's not that simple. We *aren't* going to stop using tungsten. What's going to happen is the demand curve is going to shift.
Economics is about marginal behavior. Regimes that don't treat their country as a piggy bank will get a better price for their tungsten. It will reduce the incentive to effect what amounts to a LBO of a country so that the mineral wealth can be liquidated.
Anyhow, Africa having an industrial boom? Are you serious? That would be great, but I'm not holding my breath. Africa being a threat to China or even the US industrially is a pipe dream in the short term. In the long term, it would be *great*, and I for one would be up for a chorus of "Kum Bay Yah" if that ever happened. In the long term, that means richer customers for *our* goods and services.
Personally, I don't think there is any magic wand we can wave and make everything wonderful. We had this debate for decades over South Africa, and eventually it was the strain of going over this stuff over and over and over that finally made the regime crack. It's still not paradise in South Africa, but at least what mess there is is the *people's* mess.
It's instructive to compare the success of economic sanctions in effecting regime change in South Africa (where it worked) and Cuba (where it failed). The Cuban sanctions were much harsher. It makes ironic sense, when you remember that economic behavior is driven by marginal costs and benefits.
An advertising company?
Certainly not. If that were true, then Fox News would be an advertising company. *The New Yorker* would be an advertising company.
Like those other companies, Google is a *content* company. The difference is that their flagship product is metadata. The thing that gives them the kill advantage in the content business is scale. Under the covers, they're about storing and distributing vast volumes and varieties of data. Over the covers, their APIs and products are about driving demand for that.
Hardly. You'd have to at least to be able to build the software in order to verity you'd been given the real McCoy.
In any case, even in the scenario you describe, the exact software is not as important as a clear description of what it *does*. The experts would need to provide that at much so that the lawyers and (if necessary) the jury would be able to make some determination of whether the bricking was intentional. I'm assuming there isn't any code in there like this:
#define ILLEGALLY_SCREW_OUR_CUSTOMERS 1
Given that some level of analysis is needed to support a legal judgment, then the cat will be out of the bag. There are lots of *very* smart people in the world who'd work out how to bust the thing wide open, just for the challenge.
Um. You do know what a court order is, don't you? Compliance is not generally viewed as *optional*.
The least common denominator? What would that be?
They all have GPS, touch screens (some have keyboards), 3G, accelerometers blah, blah, blah. So it's not like writing an J2ME midlet and wondering how many buttons the user will have and whether you'll have 100K of RAM to run in.
Android's model is not to be a PC -- that PocketPC Phone Edition. Android is all about moving data around, because that's what business Google is in. That's Google's killer advantage. They're not a search engine company, they're a data management company. It's all about having the information you need at your fingertips.
In an ideal world, you could tether your PC to your android phone. And if Google has its way, that'll be standard.
What Google wants is for the carriers to be in the commodity bandwidth business. That's the reasoning behind Android and Chromium. With the iPhone kicking their smartphone ass, Google's the only game in town for the carriers, and eventually they'll be forced into that business, the way that so many software companies ended up embracing open source because they couldn't make a living at the old business model with a MS monopoly.
I'm a new Droid owner too. I agree about the games, but could not possibly care less.
There are some design issues with Android, particularly on the Droid phone which only has 256MB of built-in storage, and executables for the time being have to be stored there. I've heard game developers complain about this, but what it means is you've got to split out code and data so the data can live on the SD card.
In any case, I have *no* intention of every buying any games for Android. I'm more interested in developing enterprise apps for Android.
I think that'll be the market segmentation in the near future. Media and games will be iPhone territory. "Serious" data management and enterprise apps on Android, where the platform is not controlled by some third party's apparachniks and you can take your java libraries with you to other platforms.
Because their energy use provides employment for state residents.
Actually, the goal of saving energy/reducing pollution from energy generation would be better served by taxing energy. You wouldn't have to have a TV set power consumption regulation office, you just take whatever the electric company charges and slap a percentage on top of that. Then you except commercial uses, and give everyone a standard tax rebate so that it's possible for nearly everyone to avoid the the tax by using electricity moderately.
Yes, it's another case of using the tax code to achieve something other than bringing in revenue, but it does the same thing that *regulation* would do, only across *all* uses of electric power, and without forcing anybody to change anything. If you absolutely MUST have that gigantic plasma TV, and absolutely DON'T want to pay without tax, you can go without lights or a refrigerator.
Black and white thinking alert: is the question one of bearing *no* responsibility?
Everything we do in life has a risk. We used to send my late brother, who was mentally retarded, out on a recreation van for field trips like bowling. One day a careless truck driver went through a red light and hit the van, putting my brother into the hospital for over a month.
Now we *knew* that something like that was a possibility when we put him on that van. We made a determination that the statistical risk was worth it, and we lost. Does that mean the truck driver is off the hook?
Choosing to live below sea level is risky, but it is not certain death and destruction over the anticipated lifetime of your residency there. Most of Holland is below sea level. But it is a risk. The question is did somebody unconscionably *alter* that risk?
Hmmm. Interesting.
I thought it was "hard heads" and "pockets full of dough."
The customer reaction illustrates that the following is a bad business model: creating a service like Second Life for people who have time to waste on services like Second Life.
Whether or not the "inventor" is capable of producing a device or program is irrelevant. The question is whether he has invented anything.
This is not an easy question. Inventions are almost always composed of previous inventions. Back when mechanical timepieces were being developed to improve navigation, inventors were constantly tinkering with ways to improve them. These were arrangements of preexisting machine parts like levers and springs. So does *every* distinct mechanical watch design amount to an "invention" just because it is unique?
No -- the ability to design (much less build) something is completely unrelated to whether you can invent something.
It seems to me that an *invention* has to embody an original insight into the problem. Lest I be pushing the semantic ambiguity onto a different word, I'll make a stab at what I think "insight" means in the context of invention:
Insight is an idea that leads to a reformulation of a problem, rather than restatements of existing solutions to it.
In mechanical timekeeping, the idea that a *wheel* could act like a pendulum alters the problem. Before that realization the problem would have been how to deal with the mechanical inconvenience of a weighted rod, or how to balance friction and force to get a consistent result without a pendulum.
In this case we have the idea of a sparkgraph, stated in terms of a common design pattern: the observer pattern. If you *have* a sparkgraph in software, you must update it *somehow*; either by manual intervention by the user or by reaction to changes in data. As soon as you decide to make sparkgraphs available to the user, the process of design *forces* you to make the choice one way or the other. You might have the only software package robustly designed enough to give you the option of automatic update, but the choice itself is a generic one forced on you by preexisting design conceptions. You haven't created any *new* way of conceptualizing the software architecture or user interface.
This requirement of insight is, by the way, why I think software patents are a bad idea. It's not that we don't invent things, it's the opposite. We invent things *constantly*. As software designers that's our job, to create new conceptualizations of problems. The problem is that we generate and discard so many potentially useful ideas that it is virtually certain with enough of us working on various problems, somebody has come up with a lot of the same things independently. That's not quite the same as saying the ideas are "obvious". It's quite difficult to come up with a good conceptualization of a problem and not many people can do it. That's what makes working in this field interesting.
So why is software engineering different than other fields of "inventing"? I think it's because the flexibility of computers as a platform for expressing useful creative ideas makes generating many alternative problem conceptualizations worthwhile.
So we *do* invent things all the time in software design. Despite this, an application of an existing design pattern to a useful feature doesn't quality as an "invention".
Webapps don't work if you are going into a disaster zone. You can't count on any infrastructure other than a sat phone, which you can't lug around with you. I've worked with guys tracking emerging diseases in the bush; they have to lug in everything using native porters -- just like in the old Tarzan movies -- and run their diagnostic machinery and serves on solar power.
Believe me, I know what I'm doing with this stuff, at least. You can't assume anything; paper would be ideal in this respect but you want to get the information out faster than it can be faxed and reentered. A team with handhelds sharing a couple of sat phones in a protected place works. Seriously, these guys *literally* have to navigate minefields.
OK, have you heard of Google Gears?
I'm guessing that's part of the strategy here. Just because the apps are "web apps" doesn't mean this has to be a thin client. The apps can run locally an synchronize data when network is available.
In any case, a thin client might not be such a bad thing. Google pretty much has made its business out of succeeding at things others have tried, but getting the details and timing right.
Timing is everything in tech products. You might have the right solution, but unless the other things are aligned, you're spitting into the win. What has changed since the the early 90s when the thin client idea was first floated? Plenty. And plenty has happened in the past several years that makes thin clients -- especially ones that can replicate apps off the net -- attractive. Wifi is ubiquitous, and lots of people are buying data plans for their smart phones -- carriers are even offering bundles with "free" netbooks.
Why is Google doing Android? Because their future depends on a world with ubiquitous, cheap, net-neutral wireless access they can sell services over. With iPhone mopping up the competition in the smartphone arena, Google has an opportunity to sell a phone that is open -- unlike Windows Mobile -- and that reinforces the future it prefers. I'll bet ChromiumOS is aimed at the same problem: enticing the carriers into the commodity bandwidth game.
Think about how nicely something like that would work with GSM. Let's say that where you don't have coverage, it still works though something like Gears. When you do, your data gets backed up to Google. When you drop your Chromium netbook, you take the SIM out and buy a new one for $299; or maybe get a swap replacement as the old one gets fixed. In any case its like nothing happened. If you accidentally delete your thesis, or it is deleted by malware, or of somebody steals your netbook and deletes all your work, a backup is stored on Google's mighty data storage network. That's another key to the puzzle: Google's ability to manage vast amounts of data is one of its competitive advantages, and another reason they prefer a world of cheap networking.
I disagree. The unprofitable applications will be unprofitable on other phones too.
That's not necessarily true. Look at the whole problem with Flash. I understand why Apple doesn't want people deploying virtual machines or interpreters through the App store, because it undermines their monopoly on selling apps to users, but sometimes that's simply the most efficient way to build an app.
I once did a mobile application for humanitarian relief. You wouldn't believe the number of wrinkles involved in something like siting a refugee camp. I would have had *hundreds*, if not *thousands* of screens to test if I did it in the standard VB bound control style. The only way to do it economically was to have a model driven data collection engine. That way I only had fewer than a dozen UI forms to test. It was purely an engineering decision.
Now if I wanted to deploy that app on an iPhone, it very likely would not be allowed. I would have had twenty times the programming and maybe a hundred times the testing to get it working in a way Apple would accept. It would not have been profitable for me to develop an application for the iPhone, even if the result looked exactly the same to the users and every humanitarian relief worker on the planet carried an iPhone.
The only ones to "stick it out" are the ones who are the most likely to profit. This tends to be apps people mostly want.
Speaking as somebody currently living on the proceeds of a software company I sold, this is a naive view.
It's not enough to have an app people want. You have to (a) sell it for enough money to make a profit and (b) keep support costs down enough so your sales profit doesn't disappear.
Right off the bat, when you sell software, it's not a matter of "a lot of people wanting" your product; it's how many want it at the price you set. Let's say you have a product that nobody would be willing to spend much money for, but you could sell it for about the price of a cup of coffee. Let's suppose the product is cheap to make and after you sell it your customers never call you. You can make money with that.
Suppose you come up with a ringtone. It takes you a week to get it into whereever you are selling it, then 5000 customers download it at $1.99, of which you clear $1.00 after the store gets its cut. $5000 for a week of work isn't going to make you rich, but it's a respectable payday. You can live off of that kind of project.
Is this something that people "want"? Well, sure, so long as its priced cheap. The key is that of those 5000 customers, you'll hear from maybe one or two, and you can just pay them $2.00 to go away.
Now suppose you (like I did) develop some kind of mobile data collection app that drives important enterprise decisions. That's pretty damned valuable. You can easily convince a company to pay you $500 *per seat*. The problem is that even if you could wish the software into existence, the customers need more than $500 per seat of support. In fact that's why an open source model works very well for critical systems -- you give the software away and charge for the real expensive parts. In any case, my calculations showed that we broke even on a $10,000 sale, after all was said and done, so we might as *well* have given the software away. We typically sold consulting services at anywhere from $20,000 to $50,000 a pop, which was where we made our money. Believe me, when you've got a team of six engineers, a $20,000 project doesn't look so big.
The point is that the "build a better mousetrap" theory is simply wrong.
Your ringtones and iFarts are bottom feeders in the world of app development. They are profitable for their developers precisely because users don't care very much about them. Price a product like that low enough and you can make money.
The kind of apps that developers garner respect and admiration for developing are a different kettle of fish. It's *hard* to make a profit selling apps that people really care about, because customers demand a relationship with you. That's expensive.
The last thing you need is a third party inserting itself into that expensive and delicate process -- especially an opaque, unpredictable one. You work with your customers and discover they really need some extra functionality. You build it, then have to wait to find out whether you can sell it? That's nuts. You need that like you need a hole in the head.
And this is even worse: you make a portfolio of apps, and then you can't sell them to a different developer? That's a critical exit strategy for many small developers. They have the vision and brains to create an app, but don't have the size to support it. So they develop and market it, and sell it to somebody who is already supporting apps for the main customer base. That's what I did when I sold *my* business. When I had more customers that I could know personally, it wasn't fun anymore so I told one company that if they didn't buy the software I'd sell it their competitor.
Basically, what Apple is telling is that the iPhone is *still* not a platform. It's a music playing phone that can also run toys like iFart.
Sure, but that's supposing you don't count on doing anything very ... relational. For simple backing stores of to store and retrieve form data, maybe. But I've run into problems with Access "front ends" that try to optimize stuff on the back end and screw up because the genius in charge of the feature doesn't understand what "null" is supposed to mean, or doesn't know the difference between a candidate key and an unique index (also null related -- most horrible mistakes in RDBMS implementations have misunderstandings about null involved somehow). That's bad enough when you suddenly see duplicate rows retrieved -- but when you update data...
Now you might not run into a problem because of the way you use Access. Good for you. Continue using your Access front ends so long as they work, just check very carefully whenever anything changes (that includes applying patches pushed out by Microsoft Update). Access is to databases what Microsoft Backup was to backing up -- it's fine, just so long as you can live with it not working unexpectedly.
Chances are, if the kinds of things you are doing today aren't problems, they probably won't be problems tomorrow. If simple form backing gets broken in an Access or MSSQL release, somebody is going to notice. But getting *dependent* on Access is not a good thing, because if you ever need to do something more you're going to reach of that tool and get burned. Same goes for MSSQL. Aside from the fact that T-SQL is an non-orthogonal POS (really, whatever optimization benefits it gets from this aren't worth it), strange things happen if you do something they haven't tested, like put a bound parameter in a subquery.
It's easy enough these days to do what Access does with more reliable tools.
What I've seen is that some chargers power any USB powered equipment (including those on my PCs and laptops) and other wall and car chargers only power *some* USB powered equipment. I'm guessing what's going on here is that some equipment (usually expensive thingies) refuse to run off an unregulated supply. I've seen the same thing happen with a battery powered USB charger I whipped up. Some equipment won't recognize it until the batteries are drained a bit. That includes my new droid phone.
With respect to turn-by-turn navigation, I find the GPS is right on, but your mileage may vary with the accuracy of base maps in some locales. The big problem is that the software, while useful, is not really all that polished for car navigation, compared to your basic, cheap sub $100 car GPS unit. That's fine with me, because I *have* a cheap car unit that works well for me, so having one on my phone is just a nice-to-have.
As for Outlook, after years of having a phone that would work beautifully if I wanted to set up an Exchange server, I now have usable integration with my desktop computers via Google plugins to my Linux PIM software. So I'm happy.
As far as the contact sorting business is concerned, I agree this should be last name first, but it hardly matters if you have more than a couple dozen contacts. I second the call for HCI support. I haven't had problem with my Bluetooth headset, and as far as hands-free dialing is concerned it's not an issue for me, as I don't use the phone while I'm driving.
Overall, I'm very happy with this phone, although it could be better. I think the IPhone onscreen keyboard works better, and I miss multi-touch, but I like the openness of the platform. It wouldn't be hard at all to write your own contact application if you wanted to. Thus far I haven't had to struggle with the phone because the manufacturer or the carrier wants me to do things a certain way or to buy or use certain services. That's the way I like it. *It's my damn phone* so I want to use it the way I want. The only other complaint is having to upgrade to a wireless data service when I'd prefer to use only WiFi, but that's pretty standard for now.
I am responding to the asserted need for a "short term scientific stimulus".
The position I am taking is that no such thing is possible, and that attempting it is a bad idea. I don't think that it is inconsistent to agree that employment must lag while maintaining that focusing on short term growth makes that lag worse.
That works great *some* of the time. Not during a recession though, when people are socking away their money in *safe* investments.
When times are good is when you want to tighten your belt and cut taxes, because that's when private sector demand and investment are healthiest.
Well, the title of your article is "How to make your 50-MIPS Workstation Run Like a 4.77MHz IBM PC"
Since the CPU in my laptop is rated at over 4000 Vax MIPS, I'll happily throw 1-2% of that away to get the benefits of proven software. Most of the time one or the other of the cores is close to zero utilization anyway.
What I'd like to see is simpler security setup (without sacrificing features or security of course). That's when you say "there has to be an easier way". It's bad when tunneling a protocol through ssh is the *easy* way.