I don't think any JVM based languages other than Java are anywhere near widely used
That depends on how you define matters. Ruby is fairly widely used and has a JVM-based implementation that is less widely used. Ditto Python/Jython. At the moment, though, I suspect neither will run on Dalvik — any interpreted language that generates bytecode on the fly for JIT would need to generate Dalvik bytecode.
and Android has no provisions to execute "bare metal" code
That's probably not strictly true — again, it depends on how you define matters.
It appears there will be two tiers of Android development:
Apps that can run on any Android device have to be written for Dalvik VM and use the Android SDK
If you download the whole Android stack when it's released as open source, you can do what you want, but it's up to you to distribute the modified firmware (e.g., put it on your own hardware) or submit the patches upstream to Android and hope they're accepted
Much of the focus has been on the first of those two, probably because more developers will be working on that tier. However, from the standpoint of hardware manufacturers or hobbyists, you can do bare metal to your heart's content.
Your crypto logic can be implemented in C/C++ just fine, using JNI to bridge into an Android application. While it is true that full applications cannot be written solely in C/C++, that doesn't mean you cannot use C/C++ outright. Admittedly, that FAQ entry is poorly written, but a simple search of the android-developers Google Group shows a fair bit of Android/JNI activity, including posts from Android core team members indicating that JNI is possible.
Android devices are only allowed to have low-resolution QVGA (240x320) resolution displays
I have no idea where you got that idea. Heck, the Android emulators by default launch as 480x320 and support skins with 320x480 and 240x320 resolutions. It's even been hinted in some presentations that Android might run on devices without screens — not that I'm completely certain how that would work (voice recognition only?).
In the future, you will get more efficient responses to your questions by posting them on an Android Google Group, rather than ranting about them on/.
I'm under the impression not all bits are there, but it's enough to get Android running (sometimes poorly) on various HTC handsets, Nokia N8xx devices, etc.
So far we've seen promise of being open falling through to date, we've seen the supposed source of strength of android (the community), hamstringed by Google's own actions.
You keep blaming Google, yet you have supplied no evidence that they're really the ones at fault.
Remember that Android is a product of the Open Handset Alliance. There's a whole lotta firms in that group, including some fairly big names. While it is eminently possible the problem starts and stops with Google, it could be some coalition within Open Handset Alliance that has put the screws to the process, for whatever reason.
That doesn't mean it's not bad. But, if you're going to cast blame at specific firms, it'd be nifty if you had more evidence that the firm is the one truly deserving of the blame.
I've seen promises of 'once the phone is on the market, we'll make good!', but I fail to see why they can't allow the SDK to be in public hands because of that excuse.
Maybe they're worried about the support burden and the subsequent pressure on deadlines — ask any decent-sized open source project about what happens when a highly-publicized update is released. Maybe somebody in the Alliance demanded that updates be curtailed so Alliance developers could get a leg up on getting their own applications built — bad, mind you, but not necessarily Google's idea.
Again, the silence is bad, but it's an annoying sort of bad, not a "the sky is falling! the sky is falling!" sort of bad. Yet. Now, if they miss their 2008 Q4 target, or if they make it and the platform isn't as open as originally proclaimed, then people have a right to get royally pissed, just as they're getting pissed at Apple for throwing its weight around in the App Store more than might seem warranted. Right now is a fine time to be skeptical of whether Android will be as open as we want, but too soon to say it is not going to happen.
CAFE is crap for really reducing emissions; it gave us the SUV as family vehicle (because station wagons, the former family machine, were subject to CAFE as cars, but SUVs, as light trucks, were not).
That's a matter of rewriting the CAFE law. It's not like SUV-as-light-truck is some fundamental constant in the universe.
You want higher fuel efficiency, tax the hell out of gasoline and diesel the way the Europeans do. Simple and easily enforced.
Except:
That gives slow, indirect impetus to car manufacturers to increase the mileage of cars and light trucks. No doubt that, over time, they'll get there. But in the interim, you've sucker-punched the drivers, who are caught with limited alternatives — you can't buy cars that don't exist, and there are only so many hybrids manufactured and Jetta TDIs imported. Raising CAFE in line with gas price increases forces the car manufacturers' hands more quickly and directly, and consumers already have plenty of incentive to buy more fuel efficient cars merely due to rising gas prices.
Raising gas taxes sufficiently to even give slow, indirect impetus to car manufacturers — in line with European taxes, as you note — is political suicide, not just for the candidate, but for the candidate's whole party. Raising CAFE will cause car manufacturer political donations to switch sides, along with the votes of Michigan residents, but otherwise likely will be seen as positive.
If you can figure out a way for fuel taxes to overcome those two problems, that'd be excellent. I'm not exactly a CAFE fan myself. It may be the answer is a hybrid (pun lightly intended) of raising CAFE and increasing gas taxes.
Until we know *MUCH* more about global climate control knee jerk reactions should be kept to a minimum.
Depending on how you define "knee jerk", I disagree.
Reducing overall usage of oil is a good thing for many reasons outside of the potential environmental benefits, including:
Reducing the world's dependency on a non-renewable resource that, depending on who you ask, may be running out (or at least getting increasingly difficult to extract in the desired quantities for reasonable costs)
Reducing the world's dependency on a resource that, in many cases, lies in areas with political turmoil (e.g., Middle East)
For the countries that establish relative expertise, serving as a source of innovation-based new jobs
So, if it's "knee jerk" for the US to ratchet up CAFE requirements (and the equivalents for trucks and trains) so we become best-in-breed at fuel efficient transportation, or for the US to increase investing in alternative energy sources, then I'm all for "knee jerk" reactions.
I disagree with you and agree with the GP — the quoted phrase was poorly written. If I were tech-reviewing the book, it would have gotten a bunch of red ink.
People often use "Silicon Valley" to mean "technology companies," and you have no trouble understanding that they mean the latter as opposed to some geographical region.
Mostly because there is no city named "Silicon Valley", to the best of my knowledge, and so is less likely to be a source for confusion.
The same is true of New York and Los Angeles in the above.
No, it's not.
There is a city named Los Angeles. There is a city named New York. There is no city named Silicon Valley. If you want parallelism, "Madison Avenue" is the nickname for New York's collection of marketing and advertising firms. I'm not quite sure what the corollary would be for LA -- "Hollywood", perhaps, though I'm not sure it fits the context.
Had the quote been: "and their advertising-based business models mean they compete more with Madison Avenue than with their Silicon Valley brethren", it would have passed muster with me as an editor. Had the quote been: "and their advertising-based business models mean they compete more with firms in Los Angeles and New York than with their Silicon Valley brethren", it would have passed muster with me as well.
As written, though, the expression lacks parallelism, and is missing a "with", and would have warranted editing, IMHO.
Those wanting the latest versions of the Android SDK instead of a buggy load of old crap have to sign an NDA that prohibits talking about it, publishing screen shots, or sharing code fragments.
More accurately, those wanting the latest versions of the Android SDK had to be among the 50 winners of the first round of the ADC, for which they earned $25K and get a chance at another $100-275K, with the aforementioned NDA being one of the qualifications for proceeding.
Well, you think you could do it cheaper? Then do it man!
Reading comprehension skills aren't your strong suit.
I don't need to "do it cheaper" — Google is doing it cheaper, as I described. Some keywords they set a $1.00 (or, as I noticed today, a $5.00) floor. Some keywords they have no floor. The cost (in terms of compute cycles, R&D, and overhead) is the same — it's just that for some, they'd rather have no ads. After all, for some of these keywords, it would appear nobody is paying the minimum, as no AdWords ads show up when you search on them.
Now, there are any number of reasons they could be doing this, and I seem to recall reading an article or two on the topic a few years back when the practice first emerged. I don't even care that they are doing it. However, saying that they set selective floors because of "cost" is utter nonsense, as anyone who has taken an accounting class will tell you. I'm not trying to change Google — I'm trying to leave a record, so those who read this thread later on actually have some information that might counter the nonsense you and others are spewing.
That cost gets amortized over every bit of html it injects in.
If it costs them $0.01 in incremental compute cycles/storage/bandwidth to display enough copies of an ad to get a click, and they lose out on a $0.25 click because of a price floor, that's $0.24 they could have had to offset all those fixed costs you mentioned. If they were blocking my ads because they didn't get a good enough click-through rate (so they don't make any incremental profit), that's perfectly understandable, but they're setting a price floor instead.
There are other economic reasons they have for doing what they're doing. Amortizing costs is not one of them, unless you think morons are at the helm at Google, and I for one sure don't.
I am sorry for your predicament, you want the service at a lower price.
Not really. I mean, I wouldn't complain if they scrapped those price floors, but I have no problem that they have these minimums — it just reduces the amount of business I do with them, that's all.
What I do want is for posts modded 4+ on/., like yours, to actually make business sense. But I'm a crazy dreamer that way...
Google has a minimum bid because that is the cost of production for that ad.
And your proof of this assertion is...what, exactly?
I have an ebook on the market for developing applications for the Android platform, with the print edition slated to appear in bookstores any day now. I am trying to run an AdWords campaign to help promote the book. I have 52 keywords set up in AdWords to run my ad against. 51 of them are "inactive for search" because the minimum bid is $1.00, so they won't show up on Google's sites, though it will help them show up on AdSense sites (as I understand it).
So, please explain to me:
How it costs $1.00 to inject three lines of HTML, including one hyperlink, into search results?
How come it costs $1.00 to do that for a search on android documentation but not for android assistance, for which there is no enforced minimum bid?
There may be valid reasons why Google has a $1.00 minimum bid on some Android-related keywords, but I have a very tough time believing that it is related to "cost of production".
And all of them "check" the format, wasting CPU time, memory and cache, then can do nothing but crash (oh, sorry, throw exception for which there is no valid logic to handle) in the impossible case of format being invalid, and doing nothing if the actual data is semantically invalid (because semantic processing is done by a program written by a programmer who knows that it can't verify the data). Validation solves the problem that does not exist, it makes as much sense as accompanying data structures in memory with a CRC -- if it ever does not match, what are you going to do, send a message "Stand by for imminent crash" into the log? It's a completely wrong place for verification unless your application development model is "perma-debugging".
In the world I live in, data is frequently valid, but not always:
Data corruption in a communications link (e.g., this series of tubes we're using)
Data corruption in a storage medium (e.g., hardware hiccup, bit flip due to cosmic ray)
Version differences between sender and receiver conception of the data format
Malware that pretends to be a legitimate sender but, instead, sends invalid data
Many of those can be caught by the general-purpose validators that you decry, and that limits the number of validation routines programmers have to deal with. And your complaints re: CPU, memory, and cache place a value on them that may or may not be proper in every context. Or, as my former business partner put it, "in six months' time, computers will be faster and cheaper, but programmers will be neither".
Most of the data in anything that actually used for some practical purpose is of a "streaming" kind, request-response cycle is more often an exception than a rule. It only became popular because it's easy to implement with crappy tools.
You obviously have a very different definition of "streaming" than I do, as I'd argue virtually nothing uses streaming, from the days of FORTRAN and COBOL to the present day.
By definition, if you don't know semantics, data is meaningless (get it -- semantics, meaning).
Precisely. Decomposable formats, like XML, allow programs to have semantics for part, but not all, of a data structure. Non-decomposable formats, like C structs, require semantics for all of a data structure. In situations where you know 100% of all use cases for a data structure, non-decomposable formats are fine. If, however, you want to allow for what Jonathan Zittrain refers to as "generativity" (i.e., unanticipated uses for existing technology as a means of advancing said technology), decomposable formats can be a benefit.
Take, for example, ODT vs. classic binary Word documents, which are pretty much just a serialization of a big-ass binary structure as I understand it. I've written programs that parse and generate ODT, or, more precisely, the portions of ODT that I need. Frankly, I don't care what the rest of it is, so long as my generated documents work properly. And I didn't need to refer to the ODT documentation on OASIS or anything to write them, as the XML was sufficiently human-readable that, accompanied with experimentation, I was able to determine how to generate valid ODT. With Word, even if there were OOXML-sized documentation for it, I'd have to hand-roll my own parser for the whole damn format, just to pick out the pieces I need to work with. Now, if I worked for Microsoft on the Word team, I wouldn't have that problem, because I'd already have the parser. However, I, like most people, don't work for Microsoft, and even if Microsoft's parsers were available, they might not fit my environment (e.g., won't run on Linux).
Don't get me wrong, XML definitely gets overused. That's a problem with the uses of XML, not XML itself.
Y'know, I usually give low-UID Slashdotters a modicum of respect, but this diatribe is off-the-charts nonsense.
1. Easy parsing by parsers written by people who slept through their compiler classes.
And your evidence of this assertion is...what exactly? Not to mention the minor detail that XML and compilers are orthogonal: you can use XML (or many other data interchange formats) with non-compiled languages, and most compilers know nothing about XML (or many other data interchange formats).
2. Verification in situations when it's impossible to devise a meaningful reaction to a failure (other than either "everything failed, turn off the computers and go home" and "assume the data to be valid anyway because ALL of it will have the same formatting error because the same program generates it")
And your evidence of this assertion is...what exactly? XML-consuming programs that are aware of the data structure can have as detailed a "reaction to a failure" as a JSON-consuming program, or a YAML-consuming program, or a Protocol Buffer-consuming program. XML-consuming programs that are not aware of the data structure can, if the XML supplies it, validate against a DTD or schema, things which are not possible in some other data interchange formats (e.g., JSON, YAML).
3. Dealing with data that arrives in neatly packaged "documents" and "requests", as opposed to being constantly produced and consumed.
All data comes in neatly packaged buckets of varying types. We call them "bytes" and "packets" and "structures" and "records" and "frames" and "rows" and the like. The only way I can interpret your claim in a way that makes sense is to translate it as "XML sucks for streaming audio and video", which is undoubtedly true, and I don't think anyone uses it in that arena.
4. Either communicating between programs that have the same knowledge of message semantics, or preparation of pretty human-readable documents.
On the contrary, this is one of XML's primary strengths — handling cases where programs lack the "same knowledge of message semantics".
With most data interchange formats, from CSV to JSON to Protocol Buffers, either you know everything about the data structure you're receiving, or you're screwed. In other words, there is no discoverability and no standardized means of being able to only deal with a portion of the data. This is particularly true for binary formats, like Protocol Buffers — either you know exactly what structure you received so you can parse it, or you're SOL, since it's just a bunch of bytes.
With XML namespaces, it is entirely possible for Program X to publish data that Program Y has no intrinsic knowledge of in its entirety, but might know in part. If Program Y knows how to handle documents containing Dublin Core elements, for example, it can work with just those elements and ignore the rest of the document.
You're welcome to have any opinion of XML you like. Heck, I even agree that XML tends to be used in places where it's overkill or too verbose. But if you want to convince others that your opinion is the correct one, you'll need to do a better job than this.
Nowadays, outside of some hybrids, you can't find a real-world 40mpg new car.
In the April 2007 issue of Consumer Reports, for example, there is exactly one car listed with greater than 40mpg overall — the Toyota Prius, a hybrid. Now, this is actual miles per gallon from their testing, vs. EPA estimates. But, your financial analysis really should be using actual miles per gallon vs. EPA estimates, anyway, since the EPA probably ain't paying for the gas. In this issue, excluding hybrids, the better compact cars get an actual 32-34mpg, mid-size/large sedans get 24-25mpg, and SUVs get 22-23. And there are plenty much worse than the "better" ones. (BTW, the figures are in the left column of page 12)
Going with 30mpg as the baseline, you get 40 gallons/month = $160/month. This doesn't change your arguments much, but it's a bit more realistic.
Want to make a killer difference in our gas consumption, engineer a way to make the current 500 million cars already on the roads today get 3 more mpg, because I figure 1/3rd of the cars on the road are in the sub 20mpg range.
Since getting my Prius, I've argued that a chunk of the fuel savings comes from the excellent fuel usage data you get from the in-dash display. At any point I can get instantaneous MPG, five-minute average MPG going back in five-minute increments over the past 1/2 hour, and per-tank MPG. This data helps me refine my driving techniques to reduce fuel use. It's entirely possible that a conventional car might still get better mileage just by showing this data to the driver so, for example, they learn to avoid racing up to red lights and mashing on the brakes. Not sure if there's a way to safely retrofit this type of thing into a conventional car, though.
Also, regarding the fuel formula vs. air pressure issue, I keep the air pressure topped off on my tires pretty consistently, and I still get 10% worse mileage in the winter, even last winter, when I didn't encounter much drive time on snow or ice. My presumption is that the "winter gasoline formula" is partly the culprit, plus possibly somewhat more time running the engine to keep the engine temperature up.
The libraries are licensed to lend you the books. They've been granted that right by the copyright holders.
Perhaps in your country, that's true. In the US, that's incorrect.
Libraries buy books no differently than anyone else, except that since they buy in quantity, they usually work with a distributor or "jobber" rather than deal with a zillion publishers individually. Otherwise, there's no real difference — they pay, they get the books, they use the books. It just so happens that "use the books" involves a moderately-constrained lending program.
It is conceivable that there's a clause in copyright law that grants libraries special rights, though I'm not aware of any such clause.
Instead, libraries tend to work on first sale doctrine, AFAIK. They bought the book, so they can lend it, use it to prop up short table legs, or whatever they feel like doing with it. So long as they don't copy the book, there is no copyright infringement.
Comparing a library to the "making available" case is a bit of a stretch, though it is worth noting that there was a similar round of sturm und drang around libraries making coin-op copiers available to patrons, on the grounds that it facilitated copyright infringement. I forget if that made it all the way to a trial verdict or if the plaintiffs just dropped the whole issue.
If you see learning a new language as an issue, please just don't ever call yourself a developer.
Define "issue".
Is the choice of Objective-C a part of the reason why I'm not planning on doing iPhone development any time soon? Yes. Because it's a dead end.
While you can use Objective-C to build Mac applications, you don't need to — there are other languages that run on the Mac that are also commonly available on other platforms. And, outside of OS X and iPhone, there are no platforms I can think of where Objective-C is the "right answer", or even a "likely candidate". It's more like "you're using...what?" or "didn't that language die out a decade ago?"
Now, I'm not above learning a language solely to use a platform — I'm learning Python to play with Google AppEngine, for example. But Python has greater potential utility to me beyond AppEngine, more so than Objective-C does beyond iPhone, and so Python is less of an issue.
If the issue were solely language — say, for example, iPhone was likely to be as open as Android is likely to be — I'd probably overcome it. But, combine the language issue with the other issues, and iPhone just isn't compelling at present. Maybe that will change.
I know you're thinking "cables", but could it also mean the healthcare system?
A neighborhood can only have so many buried cables before they start conflicting with each other, with water/sewer/gas lines, etc., particularly since each cable must reach each house. Talk to a civil engineer sometime about the royal PITA known as "Miss Utility" or "OneCall" or the equivalent.
The same neighborhood can have many healthcare providers without similar conflicts. Healthcare is far less a natural monopoly than is sewer service, or roads, or cables.
It is a wiser course to pursue a "pro-choice" position that seeks to provide multiple choices, and places the power of decision in the hands of the citizen. i.e. A policy that empowers the individual.
In the abstract, you'll get no complaints from me. The question, though, is where the competition lies. Just because some portion of the service is community-owned (e.g., roads) doesn't preclude competition at other levels (e.g., package delivery services). Just because the city owns the water and sewer lines doesn't preclude competition among Roto-Rooter and similar home plumbing franchises. Similarly, just because a town decides to own the physical cabling would not preclude competition among firms wishing to use said cabling to provide communication services.
but one important part of the reality is that it is often enormously expensive to implement a genuinely innovative idea.
And your proof of this assertion is...what, exactly?
Certain ideas, innovative or not, will be intrinsically expensive due to their context. An innovative design for a nuclear power plant, for example, will be "enormously expensive to implement", not because the idea is innovative, but because nuclear power plants are "enormously expensive to implement".
However, there is nothing intrinsic to innovative ideas that make the "enormously expensive to implement". Take Crocs(TM). On the surface, these shoes must be innovative, since there are patents on them (whether those patents make any sense, of course, is a whole 'nuther matter). But it's not like they had to go immediately from patent to worldwide distribution. Instead, they started slowly, a few hundred pairs at a time, until they got the opportunity for wider distribution.
I would love to see a study that takes a look at, say, a few hundred patents, sees which ones were converted into products, and of those, which ones were "enormously expensive to implement".
Innovation therefore only goes into production when huge sums of money support the organization behind it
And your proof of this assertion is...what, exactly?
Remember: things do exist that aren't in your local Wal-Mart. You don't have to have worldwide distribution to create a product. You don't have to outsource to China to get started. Trying to achieve worldwide distribution can be expensive, and trying to get into Wal-Mart can be expensive. But those are business decisions irrespective of the "good ideas".
Individuals with good ideas often cannot realize any rewards for their ideas except through patenting and litigation, since it is notoriously difficult for a individual inventor or innovator to secure a licensing agreement with a producer ahead of the fact.
And your proof of this assertion is...what, exactly?
How about, say, patenting and licensing said patents?
You seem to be under the assumption that inventors are duty-bound to aim to be billionaires and therefore all inventors act accordingly.
In absence of that option, post-facto licensing in the form of patent lawsuits is the only alternative.
I won't even bother asking for your proof of this assertion, as it's obvious nonsense. Pretty much the definition of "patent troll" is a firm who (gasp!) licenses patents and then sues. If patent trolls exist fitting this definition, then "post-facto licensing" of patents by (gasp!) licensing patents is apparently another alternative.
None of us drive Priuses (most of think they are a scam unless you live in a super-densely populated place).
Define "scam". My Prius has gotten 49.6 mpg over its lifetime (as measured by fuel put in; the on-board computer tracks pretty closely), and I don't live in a "super-densely populated place". Also, the PZEV emissions profile isn't strictly tied to population density.
I'm not saying the Prius is for everyone, but "scam" seems a little harsh.
most plant designs aim to achieve $1 per kWh/year (that makes the installed cost about $10/watt)
You lost me on converting the $1 annual KWH running cost to the $10/watt installation cost. If you derived that from construction of other power plants (e.g., coal), I'm not sure how good an estimate that is. Each type of power plant has its own construction peculiarities (coal needs fuel deliveries/storage space and scrubbers, nuclear requires umpteen gazillion safety checks plus nuclear material, solar thermal has big tanks of molten salt) to go along with commonalities (ties to the power grid).
I was refering to the 3 gigawat plant metioned in the article.
Ah, sorry.
The largest solar thermal plant I've heard of being planned was in Australia, somewhere in the outback, but I forget the name and so can't give a link or any stats. How big an individual plant can scale to is definitely a worthwhile question.
but you don't see me making up numbers and adding them to my cost to make it more compelling
The only citation you've provided is Wikipedia (which is routinely described here on/. as not being a citeable source), and there's still no source for your construction cost estimate.
I will stick with the congressional budget, thank you very much.
Which was $500 billion three years into the war, which was three years ago. Looking at the budget allocations, I'm not convinced the war got dramatically cheaper. So even if it isn't to the $1 trillion mark yet, it will be pretty soon. And that's without your "funny numbers", some of which aren't too damn funny if you're the one missing a leg.
Remember, you're the one who said "By comparison the Iraq war has not cost a trillion (unless you do a lot of hand waving and use funny numbers)" and "I will stick with the congressional budget, thank you very much", so you still have some explaining to do.
Our current energy infrastructure cost trillions of dollars to build
Citation, please. Else, don't cite figures.
and solar thermal would be more expensive.
Citation, please. Certainly the article cited in the OP didn't make such claims. I'm not saying you're wrong, but you'll be a whole lot more convincing if you'd provide some citations.
By comparison the Iraq war has not cost a trillion (unless you do a lot of hand waving and use funny numbers).
In 2005, the Congressional Budget Office estimated the cost of the war at $500 billion. That was three years ago. Others put the cost at $1 to $2 trillion in 2006. See this article from The Guardian (UK) for details. If you would like to provide some citations refuting these figures, please do so.
The article does not mention the installed cost of such a system, but it's probably tens of trillions of dollars.
And your basis for this claim is...what, exactly?
More if you factor in the need to store energy overnight and on overcast days.
From the article cited in the OP, "Commercial projects have already demonstrated that CSP systems can store energy by heating oil or molten salt, which can retain the heat for hours." That covers overnight hours. You'd locate the facilities in areas that typically don't have extended periods of overcast days (e.g., US Southwest, as mentioned in the article). Neither will provide 100% coverage, and so you'll probably still need existing power generation facilities, but they can be scaled back in operation the vast majority of time. What isn't discussed and probably needs to be is whether it is more effective to keep those facilities operating at bare minimum levels vs. come up with some other means to deal with extended poor generation periods.
Is it even possible to build one that big?
First, the reference to the 92x92 mile grid says "Solar thermal plants covering the equivalent of a 92-by-92-mile square grid in the Southwest..." You might note that "plants" is plural. So we're not talking a single 92x92 mile plant, but a large number of plants that cover an equivalent area. However, it's unclear how large an individual plant in this scheme would be vis a vis the ones in operation today.
Granted they can be interesting and helpful, they are often written with no editing and read more like "On the Road" than The New York Times.
On a related note, you're missing a "but" or "however" after the comma, highlighting that even the best of us have the occasional problem with grammar. You do get bonus points for citing Kerouac and for capitalizing "The" in "The New York Times" — up until researching it just now, I wouldn't have guessed that "The" is actually part of the newspaper's name.
If you never leave your basement you're not reporting, you're aggregating or spinning.
Or, perhaps, just maybe, adding some value. For example, one could be analyzing, to augment some lightly-sourced corporate (a.k.a., "mainstream") media piece with additional data to augment or refute the original. Or one could be researching new material from "your basement" via interviews, polls, and the like. And, of course, one person's "spinning" is another person's "displaying another perspective" — personally, I tend to reserve the term "spinning" when it involves lying or masquerading the truth.
Do all bloggers do this? Heck no, no more than do all Slashdot posters. It varies by blogger and by subject matter. For that matter, not all #$*($#)@ reporters do a quality job. Too much stuff winds up in print or on TV that is merely regurgitating a PR piece or other slanted bit of original writing.
All sources of information, whether from corporate-backed outlets or from individual bloggers, come as both wheat and chaff. What the world needs is more experience in telling one from the other.
Slashdot Mirror
That depends on how you define matters. Ruby is fairly widely used and has a JVM-based implementation that is less widely used. Ditto Python/Jython. At the moment, though, I suspect neither will run on Dalvik — any interpreted language that generates bytecode on the fly for JIT would need to generate Dalvik bytecode.
That's probably not strictly true — again, it depends on how you define matters.
It appears there will be two tiers of Android development:
Much of the focus has been on the first of those two, probably because more developers will be working on that tier. However, from the standpoint of hardware manufacturers or hobbyists, you can do bare metal to your heart's content.
Your crypto logic can be implemented in C/C++ just fine, using JNI to bridge into an Android application. While it is true that full applications cannot be written solely in C/C++, that doesn't mean you cannot use C/C++ outright. Admittedly, that FAQ entry is poorly written, but a simple search of the android-developers Google Group shows a fair bit of Android/JNI activity, including posts from Android core team members indicating that JNI is possible.
I have no idea where you got that idea. Heck, the Android emulators by default launch as 480x320 and support skins with 320x480 and 240x320 resolutions. It's even been hinted in some presentations that Android might run on devices without screens — not that I'm completely certain how that would work (voice recognition only?).
In the future, you will get more efficient responses to your questions by posting them on an Android Google Group, rather than ranting about them on /.
Undoubtedly a bizarre move, though I have issues with who you probably have as the "they" in that sentence — see below.
You mean, like this?
http://code.google.com/p/android/source/checkout
I'm under the impression not all bits are there, but it's enough to get Android running (sometimes poorly) on various HTC handsets, Nokia N8xx devices, etc.
You keep blaming Google, yet you have supplied no evidence that they're really the ones at fault.
Remember that Android is a product of the Open Handset Alliance. There's a whole lotta firms in that group, including some fairly big names. While it is eminently possible the problem starts and stops with Google, it could be some coalition within Open Handset Alliance that has put the screws to the process, for whatever reason.
That doesn't mean it's not bad. But, if you're going to cast blame at specific firms, it'd be nifty if you had more evidence that the firm is the one truly deserving of the blame.
Maybe they're worried about the support burden and the subsequent pressure on deadlines — ask any decent-sized open source project about what happens when a highly-publicized update is released. Maybe somebody in the Alliance demanded that updates be curtailed so Alliance developers could get a leg up on getting their own applications built — bad, mind you, but not necessarily Google's idea.
Again, the silence is bad, but it's an annoying sort of bad, not a "the sky is falling! the sky is falling!" sort of bad. Yet. Now, if they miss their 2008 Q4 target, or if they make it and the platform isn't as open as originally proclaimed, then people have a right to get royally pissed, just as they're getting pissed at Apple for throwing its weight around in the App Store more than might seem warranted. Right now is a fine time to be skeptical of whether Android will be as open as we want, but too soon to say it is not going to happen.
That's a matter of rewriting the CAFE law. It's not like SUV-as-light-truck is some fundamental constant in the universe.
Except:
If you can figure out a way for fuel taxes to overcome those two problems, that'd be excellent. I'm not exactly a CAFE fan myself. It may be the answer is a hybrid (pun lightly intended) of raising CAFE and increasing gas taxes.
Depending on how you define "knee jerk", I disagree.
Reducing overall usage of oil is a good thing for many reasons outside of the potential environmental benefits, including:
So, if it's "knee jerk" for the US to ratchet up CAFE requirements (and the equivalents for trucks and trains) so we become best-in-breed at fuel efficient transportation, or for the US to increase investing in alternative energy sources, then I'm all for "knee jerk" reactions.
I disagree with you and agree with the GP — the quoted phrase was poorly written. If I were tech-reviewing the book, it would have gotten a bunch of red ink.
Mostly because there is no city named "Silicon Valley", to the best of my knowledge, and so is less likely to be a source for confusion.
No, it's not.
There is a city named Los Angeles. There is a city named New York. There is no city named Silicon Valley. If you want parallelism, "Madison Avenue" is the nickname for New York's collection of marketing and advertising firms. I'm not quite sure what the corollary would be for LA -- "Hollywood", perhaps, though I'm not sure it fits the context.
Had the quote been: "and their advertising-based business models mean they compete more with Madison Avenue than with their Silicon Valley brethren", it would have passed muster with me as an editor. Had the quote been: "and their advertising-based business models mean they compete more with firms in Los Angeles and New York than with their Silicon Valley brethren", it would have passed muster with me as well.
As written, though, the expression lacks parallelism, and is missing a "with", and would have warranted editing, IMHO.
More accurately, those wanting the latest versions of the Android SDK had to be among the 50 winners of the first round of the ADC, for which they earned $25K and get a chance at another $100-275K, with the aforementioned NDA being one of the qualifications for proceeding.
Reading comprehension skills aren't your strong suit.
I don't need to "do it cheaper" — Google is doing it cheaper, as I described. Some keywords they set a $1.00 (or, as I noticed today, a $5.00) floor. Some keywords they have no floor. The cost (in terms of compute cycles, R&D, and overhead) is the same — it's just that for some, they'd rather have no ads. After all, for some of these keywords, it would appear nobody is paying the minimum, as no AdWords ads show up when you search on them.
Now, there are any number of reasons they could be doing this, and I seem to recall reading an article or two on the topic a few years back when the practice first emerged. I don't even care that they are doing it. However, saying that they set selective floors because of "cost" is utter nonsense, as anyone who has taken an accounting class will tell you. I'm not trying to change Google — I'm trying to leave a record, so those who read this thread later on actually have some information that might counter the nonsense you and others are spewing.
If it costs them $0.01 in incremental compute cycles/storage/bandwidth to display enough copies of an ad to get a click, and they lose out on a $0.25 click because of a price floor, that's $0.24 they could have had to offset all those fixed costs you mentioned. If they were blocking my ads because they didn't get a good enough click-through rate (so they don't make any incremental profit), that's perfectly understandable, but they're setting a price floor instead.
There are other economic reasons they have for doing what they're doing. Amortizing costs is not one of them, unless you think morons are at the helm at Google, and I for one sure don't.
Not really. I mean, I wouldn't complain if they scrapped those price floors, but I have no problem that they have these minimums — it just reduces the amount of business I do with them, that's all.
What I do want is for posts modded 4+ on /., like yours, to actually make business sense. But I'm a crazy dreamer that way...
And your proof of this assertion is...what, exactly?
I have an ebook on the market for developing applications for the Android platform, with the print edition slated to appear in bookstores any day now. I am trying to run an AdWords campaign to help promote the book. I have 52 keywords set up in AdWords to run my ad against. 51 of them are "inactive for search" because the minimum bid is $1.00, so they won't show up on Google's sites, though it will help them show up on AdSense sites (as I understand it).
So, please explain to me:
There may be valid reasons why Google has a $1.00 minimum bid on some Android-related keywords, but I have a very tough time believing that it is related to "cost of production".
In the world I live in, data is frequently valid, but not always:
Many of those can be caught by the general-purpose validators that you decry, and that limits the number of validation routines programmers have to deal with. And your complaints re: CPU, memory, and cache place a value on them that may or may not be proper in every context. Or, as my former business partner put it, "in six months' time, computers will be faster and cheaper, but programmers will be neither".
You obviously have a very different definition of "streaming" than I do, as I'd argue virtually nothing uses streaming, from the days of FORTRAN and COBOL to the present day.
Precisely. Decomposable formats, like XML, allow programs to have semantics for part, but not all, of a data structure. Non-decomposable formats, like C structs, require semantics for all of a data structure. In situations where you know 100% of all use cases for a data structure, non-decomposable formats are fine. If, however, you want to allow for what Jonathan Zittrain refers to as "generativity" (i.e., unanticipated uses for existing technology as a means of advancing said technology), decomposable formats can be a benefit.
Take, for example, ODT vs. classic binary Word documents, which are pretty much just a serialization of a big-ass binary structure as I understand it. I've written programs that parse and generate ODT, or, more precisely, the portions of ODT that I need. Frankly, I don't care what the rest of it is, so long as my generated documents work properly. And I didn't need to refer to the ODT documentation on OASIS or anything to write them, as the XML was sufficiently human-readable that, accompanied with experimentation, I was able to determine how to generate valid ODT. With Word, even if there were OOXML-sized documentation for it, I'd have to hand-roll my own parser for the whole damn format, just to pick out the pieces I need to work with. Now, if I worked for Microsoft on the Word team, I wouldn't have that problem, because I'd already have the parser. However, I, like most people, don't work for Microsoft, and even if Microsoft's parsers were available, they might not fit my environment (e.g., won't run on Linux).
Don't get me wrong, XML definitely gets overused. That's a problem with the uses of XML, not XML itself.
Y'know, I usually give low-UID Slashdotters a modicum of respect, but this diatribe is off-the-charts nonsense.
And your evidence of this assertion is...what exactly? Not to mention the minor detail that XML and compilers are orthogonal: you can use XML (or many other data interchange formats) with non-compiled languages, and most compilers know nothing about XML (or many other data interchange formats).
And your evidence of this assertion is...what exactly? XML-consuming programs that are aware of the data structure can have as detailed a "reaction to a failure" as a JSON-consuming program, or a YAML-consuming program, or a Protocol Buffer-consuming program. XML-consuming programs that are not aware of the data structure can, if the XML supplies it, validate against a DTD or schema, things which are not possible in some other data interchange formats (e.g., JSON, YAML).
All data comes in neatly packaged buckets of varying types. We call them "bytes" and "packets" and "structures" and "records" and "frames" and "rows" and the like. The only way I can interpret your claim in a way that makes sense is to translate it as "XML sucks for streaming audio and video", which is undoubtedly true, and I don't think anyone uses it in that arena.
On the contrary, this is one of XML's primary strengths — handling cases where programs lack the "same knowledge of message semantics".
With most data interchange formats, from CSV to JSON to Protocol Buffers, either you know everything about the data structure you're receiving, or you're screwed. In other words, there is no discoverability and no standardized means of being able to only deal with a portion of the data. This is particularly true for binary formats, like Protocol Buffers — either you know exactly what structure you received so you can parse it, or you're SOL, since it's just a bunch of bytes.
With XML namespaces, it is entirely possible for Program X to publish data that Program Y has no intrinsic knowledge of in its entirety, but might know in part. If Program Y knows how to handle documents containing Dublin Core elements, for example, it can work with just those elements and ignore the rest of the document.
You're welcome to have any opinion of XML you like. Heck, I even agree that XML tends to be used in places where it's overkill or too verbose. But if you want to convince others that your opinion is the correct one, you'll need to do a better job than this.
Nowadays, outside of some hybrids, you can't find a real-world 40mpg new car.
In the April 2007 issue of Consumer Reports, for example, there is exactly one car listed with greater than 40mpg overall — the Toyota Prius, a hybrid. Now, this is actual miles per gallon from their testing, vs. EPA estimates. But, your financial analysis really should be using actual miles per gallon vs. EPA estimates, anyway, since the EPA probably ain't paying for the gas. In this issue, excluding hybrids, the better compact cars get an actual 32-34mpg, mid-size/large sedans get 24-25mpg, and SUVs get 22-23. And there are plenty much worse than the "better" ones. (BTW, the figures are in the left column of page 12)
Going with 30mpg as the baseline, you get 40 gallons/month = $160/month. This doesn't change your arguments much, but it's a bit more realistic.
Since getting my Prius, I've argued that a chunk of the fuel savings comes from the excellent fuel usage data you get from the in-dash display. At any point I can get instantaneous MPG, five-minute average MPG going back in five-minute increments over the past 1/2 hour, and per-tank MPG. This data helps me refine my driving techniques to reduce fuel use. It's entirely possible that a conventional car might still get better mileage just by showing this data to the driver so, for example, they learn to avoid racing up to red lights and mashing on the brakes. Not sure if there's a way to safely retrofit this type of thing into a conventional car, though.
Also, regarding the fuel formula vs. air pressure issue, I keep the air pressure topped off on my tires pretty consistently, and I still get 10% worse mileage in the winter, even last winter, when I didn't encounter much drive time on snow or ice. My presumption is that the "winter gasoline formula" is partly the culprit, plus possibly somewhat more time running the engine to keep the engine temperature up.
Well, there's already one book out on Android development and 3-4 others in progress by various authors.
And, in the interests of full disclosure, I wrote the book I linked to above.
Perhaps in your country, that's true. In the US, that's incorrect.
Libraries buy books no differently than anyone else, except that since they buy in quantity, they usually work with a distributor or "jobber" rather than deal with a zillion publishers individually. Otherwise, there's no real difference — they pay, they get the books, they use the books. It just so happens that "use the books" involves a moderately-constrained lending program.
It is conceivable that there's a clause in copyright law that grants libraries special rights, though I'm not aware of any such clause.
Instead, libraries tend to work on first sale doctrine, AFAIK. They bought the book, so they can lend it, use it to prop up short table legs, or whatever they feel like doing with it. So long as they don't copy the book, there is no copyright infringement.
Comparing a library to the "making available" case is a bit of a stretch, though it is worth noting that there was a similar round of sturm und drang around libraries making coin-op copiers available to patrons, on the grounds that it facilitated copyright infringement. I forget if that made it all the way to a trial verdict or if the plaintiffs just dropped the whole issue.
Define "issue".
Is the choice of Objective-C a part of the reason why I'm not planning on doing iPhone development any time soon? Yes. Because it's a dead end.
While you can use Objective-C to build Mac applications, you don't need to — there are other languages that run on the Mac that are also commonly available on other platforms. And, outside of OS X and iPhone, there are no platforms I can think of where Objective-C is the "right answer", or even a "likely candidate". It's more like "you're using...what?" or "didn't that language die out a decade ago?"
Now, I'm not above learning a language solely to use a platform — I'm learning Python to play with Google AppEngine, for example. But Python has greater potential utility to me beyond AppEngine, more so than Objective-C does beyond iPhone, and so Python is less of an issue.
If the issue were solely language — say, for example, iPhone was likely to be as open as Android is likely to be — I'd probably overcome it. But, combine the language issue with the other issues, and iPhone just isn't compelling at present. Maybe that will change.
The Kindle, as I understand it, lacks a monospace font. Monospace fonts are rather useful for code listings and whatnot.
For those of us on the other side of the pond, who haven't a clue who Blake is, let alone his 7: http://en.wikipedia.org/wiki/Blake's_7.
And, for us programming geeks, Scratch is built on Squeak, the open source implementation of Smalltalk.
A neighborhood can only have so many buried cables before they start conflicting with each other, with water/sewer/gas lines, etc., particularly since each cable must reach each house. Talk to a civil engineer sometime about the royal PITA known as "Miss Utility" or "OneCall" or the equivalent.
The same neighborhood can have many healthcare providers without similar conflicts. Healthcare is far less a natural monopoly than is sewer service, or roads, or cables.
In the abstract, you'll get no complaints from me. The question, though, is where the competition lies. Just because some portion of the service is community-owned (e.g., roads) doesn't preclude competition at other levels (e.g., package delivery services). Just because the city owns the water and sewer lines doesn't preclude competition among Roto-Rooter and similar home plumbing franchises. Similarly, just because a town decides to own the physical cabling would not preclude competition among firms wishing to use said cabling to provide communication services.
And your proof of this assertion is...what, exactly?
Certain ideas, innovative or not, will be intrinsically expensive due to their context. An innovative design for a nuclear power plant, for example, will be "enormously expensive to implement", not because the idea is innovative, but because nuclear power plants are "enormously expensive to implement".
However, there is nothing intrinsic to innovative ideas that make the "enormously expensive to implement". Take Crocs(TM). On the surface, these shoes must be innovative, since there are patents on them (whether those patents make any sense, of course, is a whole 'nuther matter). But it's not like they had to go immediately from patent to worldwide distribution. Instead, they started slowly, a few hundred pairs at a time, until they got the opportunity for wider distribution.
I would love to see a study that takes a look at, say, a few hundred patents, sees which ones were converted into products, and of those, which ones were "enormously expensive to implement".
And your proof of this assertion is...what, exactly?
Remember: things do exist that aren't in your local Wal-Mart. You don't have to have worldwide distribution to create a product. You don't have to outsource to China to get started. Trying to achieve worldwide distribution can be expensive, and trying to get into Wal-Mart can be expensive. But those are business decisions irrespective of the "good ideas".
And your proof of this assertion is...what, exactly?
How about, say, patenting and licensing said patents?
You seem to be under the assumption that inventors are duty-bound to aim to be billionaires and therefore all inventors act accordingly.
I won't even bother asking for your proof of this assertion, as it's obvious nonsense. Pretty much the definition of "patent troll" is a firm who (gasp!) licenses patents and then sues. If patent trolls exist fitting this definition, then "post-facto licensing" of patents by (gasp!) licensing patents is apparently another alternative.
Define "scam". My Prius has gotten 49.6 mpg over its lifetime (as measured by fuel put in; the on-board computer tracks pretty closely), and I don't live in a "super-densely populated place". Also, the PZEV emissions profile isn't strictly tied to population density.
I'm not saying the Prius is for everyone, but "scam" seems a little harsh.
You lost me on converting the $1 annual KWH running cost to the $10/watt installation cost. If you derived that from construction of other power plants (e.g., coal), I'm not sure how good an estimate that is. Each type of power plant has its own construction peculiarities (coal needs fuel deliveries/storage space and scrubbers, nuclear requires umpteen gazillion safety checks plus nuclear material, solar thermal has big tanks of molten salt) to go along with commonalities (ties to the power grid).
Ah, sorry.
The largest solar thermal plant I've heard of being planned was in Australia, somewhere in the outback, but I forget the name and so can't give a link or any stats. How big an individual plant can scale to is definitely a worthwhile question.
The only citation you've provided is Wikipedia (which is routinely described here on /. as not being a citeable source), and there's still no source for your construction cost estimate.
Which was $500 billion three years into the war, which was three years ago. Looking at the budget allocations, I'm not convinced the war got dramatically cheaper. So even if it isn't to the $1 trillion mark yet, it will be pretty soon. And that's without your "funny numbers", some of which aren't too damn funny if you're the one missing a leg.
Remember, you're the one who said "By comparison the Iraq war has not cost a trillion (unless you do a lot of hand waving and use funny numbers)" and "I will stick with the congressional budget, thank you very much", so you still have some explaining to do.
Citation, please. Else, don't cite figures.
Citation, please. Certainly the article cited in the OP didn't make such claims. I'm not saying you're wrong, but you'll be a whole lot more convincing if you'd provide some citations.
In 2005, the Congressional Budget Office estimated the cost of the war at $500 billion. That was three years ago. Others put the cost at $1 to $2 trillion in 2006. See this article from The Guardian (UK) for details. If you would like to provide some citations refuting these figures, please do so.
And your basis for this claim is...what, exactly?
From the article cited in the OP, "Commercial projects have already demonstrated that CSP systems can store energy by heating oil or molten salt, which can retain the heat for hours." That covers overnight hours. You'd locate the facilities in areas that typically don't have extended periods of overcast days (e.g., US Southwest, as mentioned in the article). Neither will provide 100% coverage, and so you'll probably still need existing power generation facilities, but they can be scaled back in operation the vast majority of time. What isn't discussed and probably needs to be is whether it is more effective to keep those facilities operating at bare minimum levels vs. come up with some other means to deal with extended poor generation periods.
First, the reference to the 92x92 mile grid says "Solar thermal plants covering the equivalent of a 92-by-92-mile square grid in the Southwest..." You might note that "plants" is plural. So we're not talking a single 92x92 mile plant, but a large number of plants that cover an equivalent area. However, it's unclear how large an individual plant in this scheme would be vis a vis the ones in operation today.
Aw, c'mon, get real — nobody really thinks magic beans produce nuclear power. Everybody knows that beans produce gas.
On a related note, you're missing a "but" or "however" after the comma, highlighting that even the best of us have the occasional problem with grammar. You do get bonus points for citing Kerouac and for capitalizing "The" in "The New York Times" — up until researching it just now, I wouldn't have guessed that "The" is actually part of the newspaper's name.
Or, perhaps, just maybe, adding some value. For example, one could be analyzing, to augment some lightly-sourced corporate (a.k.a., "mainstream") media piece with additional data to augment or refute the original. Or one could be researching new material from "your basement" via interviews, polls, and the like. And, of course, one person's "spinning" is another person's "displaying another perspective" — personally, I tend to reserve the term "spinning" when it involves lying or masquerading the truth.
Do all bloggers do this? Heck no, no more than do all Slashdot posters. It varies by blogger and by subject matter. For that matter, not all #$*($#)@ reporters do a quality job. Too much stuff winds up in print or on TV that is merely regurgitating a PR piece or other slanted bit of original writing.
All sources of information, whether from corporate-backed outlets or from individual bloggers, come as both wheat and chaff. What the world needs is more experience in telling one from the other.