Open Source is pretty much the only way to get code reviews for free (and even then, it's not guaranteed). I don't have time to review other peoples' code around here either, except when I already have some other reason to believe there's a problem. And even then sometimes I have to mutter "if it ain't broke, don't fix it."
Believe me, code reviews are only one of a number of Good Ideas that turn additional human time into better code, all of which would be no-brainers if only time were free. It's all just a question of whether or not it's worth it, and that often depends on how critical the code is, in the first place.
My website or sales analysis report or whatever, can't justify expenses quite as well as your avionics system. OTOH it might be more important than your flightsim game's avionics.
Let me guess: when signing up to random forums or other crap, you actually use your email address? Scary.
forumname@mydomain. When you start getting spam at that address: 1) you have a highly-reliable spam rule to add (the addressee) 2) you know who sold you out, so put 'em on your shitlist for whenever you're in naughty moods.
If you are lucky you will be arrested for trespassing. If you are not very lucky, your body will be collected by the coroner.
If you arrest or shoot me in your home, one thing's for sure: I am never going to trust your party invitations again. No one else will, either.
The point being, the whole come-into-home analogy is bullshit. If one person is going to map receiving the signals as equivalent to entering, then it's no less crazy to map broadcast of the signals as equivalent to sending out invitations.
It's not that they listened to the public broadcasts unwittingly, it's that they thought that if a router's owner elected to make their network available to the rest of the world, then it would be available to Google too. They unwittingly thought they were subject to the same reality as everyone else, regardless of their megalithic size which makes people fear and loath them.
People are apparently perfectly fine with showing their network traffic to their neighbors, and to any non-Google wardriver. There's something special about Google in this case, and it's not crazy for Google to have been "unwitting" about that.
Prior to the hunt, you don't always know when you're going to be the witch. Having the contestants be unwitting about what their roles are going to be, is part of what makes the game so fun.
If you look at it the right way (translation: I'm about to break a rule) it's done all the time. It's called RAID0.
But seriously, that tells you why it's not done: because if your really care about performance that much, you can get more performance than a multi-head-set drive and spend less money by using commodity parts. If you make a drive that works this way, no one will buy it. (Except for money laundering purposes.;-)
Yes, I have actually worked in this field. And yes, payroll is more complicated than it seems on the surface. But it's not that complicated. It's not "I can build a dozen F-14s for less" complicated.
The money spent on these types of applications is just obscene. There's gotta be major corruption in the procurement process. And it's everywhere; this isn't just a NYC problem.
why could you not have a distributed social networking standard?
We already have one. It's called the "World Wide Web." And it's actually pretty awesome and in many ways it makes MySpace and Facebook look downright primitive in comparison.
But it does have some perceived failings, depending on what it is that you want, and most of those perceived failings are "solved" by enforced structure and order -- centralization.
And since I'll be doing mostly programming, running virtual machines and just normal PC use (browsing, videos, etc...)
Your server doesn't smell like a server.;-) But fair enough; my Sandy-Bridge-now-always-beats-AMD-on-servers position is pretty prejudiced to certain workloads. YMMV and all that.
My server currently runs on an AMD. For one, it was the lowest energy using quad core I could find (45W).
FWIW I did the same thing. Athlon II 610e: part of 2010's awesomest series of server CPUs. But let's not kid ourselves: if you were building a server from scratch today (not late 2010), you wouldn't use Sandy Bridge? I sure as hell would.
I can see some niches where this Llano stuff fits, though. Not sure if any of these are on my upcoming computer menu, but I've got one particular box where if it suddenly vaporized, I might replace it with Llano. Might.
Do I have a choice? Co-workers/Friends (use the term "friend" losely) get insulted if I don't "like" or comment on their inane ramblings at least 3-4 times a week.
Wow. I know you won't like hearing this, but: did you know that you're part of the problem?
Seriously, you really can just say no. There are no negative consequences to doing that. Really, I promise. Give it a try.
Forget all the nuke sensationalism. LANL had a big wakeup call about a decade ago, concrete doesn't so easily burn, and it's unlikely anything really terrible that the "reporters" want to talk about, is going to happen. It would take a transgovernment level of incompetence; something humanity hasn't seen yet.
OTOH, adios Pajarito. I was there three and a half weeks ago, and when I checked the fire maps last night.. Camp May is totally inside the fire perimeter now. It's been an annual tradition for us to drive up there for Summerfest every year, hike on the ski slopes and watch the bikers, drink nearly all of New Mexico's microbrews, hang out with the Atom Mashers (Los Alamos' version of our Dukes of Ale) and have a good time. Reminisce about a previous year (finally amusing with hindsight) when some ravers scheduled their thing at the same time as Summerfest, so that the forest echoed with techno all night while we tried to sleep off our drunkenness. But now, I think all that is over.
Driving up there, you see the 2000 fire is still a massive scar, a forest of dead trees. That tells me that a decade from now, all of the stuff we're losing right now, will still be gone. Sure, if you take the long view, these fires are inevitable and the forest will always grow back. A lot of good that does me, a mere human without centuries to spare. I'll never see it again.
Bandolier is trashed too. Valles Caldera is at least seriously threatened. Dixon Apples (no 2011 crop anyway) had a damn close call; with pretty much everything surrounding the orchard destroyed. Urban Northern New Mexicans (i.e. the majority of the voting population) are really feeling this one, because this time it's one of our very favorite playgrounds getting burned.
You can see a shift in public attitudes about fireworks. I don't know that fireworks even caused this fire, but reason always said that it was a serious risk, and now the common New Mexican is having the lesson pounded into their hearts regardless of whatever their brains were telling them. They're (mostly) all changing their attitudes, right before my eyes. I think we'll almost certainly see some policy changes as a result.
First, gather your materials. You will need one gallon of emperor penguin blood, and two pounds of dried arctic tundra flowers. And scorpion venom for the base, raw power (almost everything needs scorpion venom these days so I assume you already have a bulk supply.) Reusable materials include a hooded cloak made from a leopard seal pelt and a totem made from a polar bear skull.
You seem to be under the impression that it's hard to transmit information these days.
Huh? No, I'm under the impression it's not totally free, and that idle equipment uses less energy than busy equipment.
It certainly scales better than moving physical objects when it comes to power usage.
I'm not arguing otherwise; I'm saying that since (approx) the 1920s we've had something that scales massively better than both individual streaming and your physical object strawman. That tech is called broadcast. No, it's not always and the right answer for a given application, but when you can use it, it's incredibly efficient and nothing else is in the same league.
The reason you don't think twice about those old techs' vulnerabilities, is that after you think once, you realize that its insecurity is inevitable.
VoIP doesn't have to be insecure; it's actually feasible to do it right, because your "terminal" is so outrageously powerful and capable in a way that couldn't be dreamt of on the 1880s.
This is really is one of those situations that if you aren't doing anything illegal don't worry about it
The reason to worry about it, even if you're not doing anything illegal, is that systems that are deliberately designed to be insecure (specifically, insecure to criminals) are likely to be insecure to others, too. If LE is listening, who else? You remember what happened to the Greek government, right?
Designing this stuff to be deliberately insecure is just plain absurd, and we ought to be thinking of it as very strange and very evil, for new tech to not be all that it can be. So yeah, of course I advocate people "find another tool." That applies to everyone, not just people whose adversarial "brother" happens to be the Big one.
Note: No is saying that minors are not allowed to play these games, only to PURCHASE them.
Limiting purchase is also limiting sale and distribution; the speaker's rights are being infringed. Nobody has come up with a way to limit someone's ability to buy something, which doesn't somehow also limit someone's ability to sell something. And since so much speech today is for-sale speech (i.e. not everyone is handing out pamphlets for free; some people sell books), putting limitations on sales in considered equivalent to putting limitations on publishing.
Imagine a 1776 law saying that Thomas Payne is free to distribute his "Common Sense" pamphlets, but will be punished if he hands them to some particular class of people (e.g. native born American taxpayers, or slaves, or foreigners, or children -- pick your poison, because it doesn't matter), thus needs to check the ids of those to whom he hands copies of "Common Sense." No matter whom you single out as a receiver of speech and how well you argue there are good reasons for government to limit what they receive or how their receive it, you're also harming Payne.
The founders would want to make these sort of laws illegal. So they did. It's up to us to either stay the course on that decision, or have the balls to say the First Amendment was a bad idea.
Just a state may place limits on buying alcohol, pornography and cigarettes
Alcohol and cigarettes don't have explicit clauses in the constitution saying that the government isn't allowed to pass laws against them. Speech is special.
Oh, how I sometimes enjoy reading your stories, mcgrew. But if your mind is unable to sufficiently twist to accommodate this perversion, then, gee, I'm almost disappointed.
I'm surprised that a 'modern' Tivo-type box couldn't use DRAM as its 30 minute buffer.
Cool idea; I think it's just a matter of having the idea. A lot of this stuff was invented back when RAM was more expensive so it wouldn't have been practical at the time.
It would be pretty damn easy to have MythTV use a ramdisk for its live TV buffer (or maybe tmpfs as a compromise; I gotta check out how it handles the live buffer's space management), and MythTV itself wouldn't need to be changed for that. It's just a matter of configuration.
I think I'll try this out the next time I'm screwing around with my mythbackend box.
DVRs are a solution to a problem of inefficient distribution.. The technology exists today (ala Netflix, Youtube, Hulu, etc.) to let people go out and actively watch what they want when they want to.
Good grief, you just substituted one "inefficiency" with something literally a thousand times less efficient.
Broadcast combined with DVRs: information transmitted once.
Netflix/Hulu/Youtube: information transmitted once for each viewer. Your "efficient" approach just multiplied bandwidth usage by several orders of magnitude, and guess what: it's networking hardware (which consumes energy while it's doing it's thing) which ultimately delivers bandwidth. You might not see all this happening, since it's outside your house, but don't think you're not paying for the energy.
There's nothing wrong with your DVR doing its work while you're asleep; whatever you use is going to do its work some time. The complaint is that people are using DVRs which don't themselves go to sleep while they're not working. (Well, that combined with the "live TV" use case many DVRs implement even for people who don't need to use it, which in turn causes it to always be working.)
Because our constitution doesn't permit government to have that kind of power over people's lives.
Eh, just say it's necessary and proper to regulate interstate commerce. Name any conceivable thing any government may ever want to do, which isn't covered by that power.
I think it's actually a bad platitude, because "verify" is always implemented as a nested trust, and that trust often turns out to be serial but the platitude glosses over that.
It goes like this: Is this person authorized to enter the building? Yes, probably, or else why would he be at the door? Well, let's verify: does he have a keycard? Yes, he has a keycard, and we trust the keycard. Why do we trust the keycard? Because only party X has the secret number hidden within it. How do we know that? Because they say so.
If any one of those things that you trust goes wrong, you lose. Not that "trust but verify" is really wrong but it isn't explicit about what "verify" really means, so you can follow the "trust but verify" rule of thumb and still screw up.
I think "Require an amazing conspiracy" is best. That makes what you really need more clear. You want several failure probabilities to get multiplied to determine the probability of the system failing. That's where multi-factor authentication comes in, the concept of "require 3 moderately trusted certs" OpenPGP default comes from, etc.
And almost all of these ideas are ignored in most mainstream "security." *sigh* We use complete reliance on any single CA in https, for example. https, one of the most important things for commerce on the net, and we get it totally wrong. Lame. I can't help but thinking, though, that the dumbfuck who thought it up believed he was doing "trust but verify."
Has the level of abstraction in computer systems reached a point where beginners can't just code something quick without a huge amount of back-story?
The "back-story" was always there, unless you go back to the 1940s or something. The BASIC programmer of 1981 didn't think about things like how does PRINT really work, the garbage collection that kept string variable storage from growing to infinity, etc. The abstraction and (temporary?) ignorance of the back-story is what lets you "just code something quick."
I think the reason things "feel" different now, is just that the back-story is longer and the abstractions are higher. When the 1981 BASIC programmer decided to dig deeper, it wasn't very long before he was working in assembly language, whereas when the 2011 Python programmer digs deeper, he's reading the source code to the library (most of which is itself written in Python) or maybe down in C and learning the OS' API calls. It's a deeper dig before you're thinking about transistors, but I'm not sure that's really important. You've got to start somewhere and really no matter where that is, you're going to start learning new things if you're interested.
Pretty much everyone else is making Linux TVs. People who don't bother to think about the details of what they want/need ("I'm just buying a TV"), are ending up with computers-disguised-as-TVs, running ffmpeg, dlna/upnp clients, etc. "Worst" of all, this stuff is extremely interoperative and allows users to play whatever the hell they feel like playing, without forcing them into using anyone's particular services.
This stuff is quietly creeping into millions of homes, and is rapidly making those little low-power add-on media-player computer systems semi-obsolete. (I wouldn't say completely obsolete, because from what I've seen the TV's software still needs lot of improvement, and playing media is really the only application they run.. for right now. No reason it should be that limited.)
Anyone with an OS agenda to push and who wants to lock users into certain services (e.g. the iTunes store) really ought to be trying to get a piece of that action.
Depending on how you look at it, Apple arguably made these same products several years ago, with some of their iMac models where everything is built into the monitor. They just lacked tuners and HDMI input connectors.;-)
I have an app on both iOS and Android (Find Craft Beer) for 99c. I recently updated it so the iOS is a bit more feature advanced than the Android version, but before the update, when the apps were identical, it was selling about 25 iOS copies to every 1 Android copy.
One of the touchy things about this kind of application is that you're sort of in competition with Google. Sort of.
As far as having (and attempting to monetize) the data itself, it's still yours and you can make a go of it. But the "find a place where condition x" part of the application is something that Google would prefer you use their maps service for. For specialized things like this, right now it is still possible to have a technically superior search than what Google offers, e.g. "Show me where I can get a good IPA within 4 miles of where I am." You can't count on this lasting forever, though, and the last-few-years push for better semantic markup (culminating in schema.org) is only going to hasten things.
If there's an advantage to being an app rather than website, it's that Google can't crawl your data. But that's also a disadvantage too. You're keeping your data out of their searches (so your search capability remains an attractive alternative to theirs) but you're also staying out of the view of the people who use their search.
So the question is: just how unique and special do you really think your data is? All it takes is for a good writer to visit the same microbreweries as you, and no matter how good your data is, it's marginalized.
A related aspect to all this, with regard to Android, is the "Google Experience." As a user I am not even slightly interested in the Google Experience, the gmail integration, etc, but nevertheless it's there and it's getting hawked to users as a feature of the platform. I think Android users are trained to use Google's searching for this kind of thing, so your observation matches predictions -- fewer of them should be paying for an App.
Yog-Sothoth help you if your iPhone users ever remember that they also have a web browser and Google Maps app. When iPhone users get around to rediscovering the web (yes, kids, the web is still there and bigger than ever), it's going to be a major blow to certain app developers.
I think the long-term outlook for these kinds of applications is grim. But good luck to you.
Slashdot Mirror
Open Source is pretty much the only way to get code reviews for free (and even then, it's not guaranteed). I don't have time to review other peoples' code around here either, except when I already have some other reason to believe there's a problem. And even then sometimes I have to mutter "if it ain't broke, don't fix it."
Believe me, code reviews are only one of a number of Good Ideas that turn additional human time into better code, all of which would be no-brainers if only time were free. It's all just a question of whether or not it's worth it, and that often depends on how critical the code is, in the first place.
My website or sales analysis report or whatever, can't justify expenses quite as well as your avionics system. OTOH it might be more important than your flightsim game's avionics.
Apple II. If you think you can duplicate that, ask Franklin.
forumname@mydomain. When you start getting spam at that address: 1) you have a highly-reliable spam rule to add (the addressee) 2) you know who sold you out, so put 'em on your shitlist for whenever you're in naughty moods.
WTF is mailinator and why, in the first place, would I want to find out about its other domains and then ban them?
If you arrest or shoot me in your home, one thing's for sure: I am never going to trust your party invitations again. No one else will, either.
The point being, the whole come-into-home analogy is bullshit. If one person is going to map receiving the signals as equivalent to entering, then it's no less crazy to map broadcast of the signals as equivalent to sending out invitations.
It's not that they listened to the public broadcasts unwittingly, it's that they thought that if a router's owner elected to make their network available to the rest of the world, then it would be available to Google too. They unwittingly thought they were subject to the same reality as everyone else, regardless of their megalithic size which makes people fear and loath them.
People are apparently perfectly fine with showing their network traffic to their neighbors, and to any non-Google wardriver. There's something special about Google in this case, and it's not crazy for Google to have been "unwitting" about that.
Prior to the hunt, you don't always know when you're going to be the witch. Having the contestants be unwitting about what their roles are going to be, is part of what makes the game so fun.
If you look at it the right way (translation: I'm about to break a rule) it's done all the time. It's called RAID0.
But seriously, that tells you why it's not done: because if your really care about performance that much, you can get more performance than a multi-head-set drive and spend less money by using commodity parts. If you make a drive that works this way, no one will buy it. (Except for money laundering purposes. ;-)
Yes, I have actually worked in this field. And yes, payroll is more complicated than it seems on the surface. But it's not that complicated. It's not "I can build a dozen F-14s for less" complicated.
The money spent on these types of applications is just obscene. There's gotta be major corruption in the procurement process. And it's everywhere; this isn't just a NYC problem.
We already have one. It's called the "World Wide Web." And it's actually pretty awesome and in many ways it makes MySpace and Facebook look downright primitive in comparison.
But it does have some perceived failings, depending on what it is that you want, and most of those perceived failings are "solved" by enforced structure and order -- centralization.
Your server doesn't smell like a server. ;-) But fair enough; my Sandy-Bridge-now-always-beats-AMD-on-servers position is pretty prejudiced to certain workloads. YMMV and all that.
FWIW I did the same thing. Athlon II 610e: part of 2010's awesomest series of server CPUs. But let's not kid ourselves: if you were building a server from scratch today (not late 2010), you wouldn't use Sandy Bridge? I sure as hell would.
I can see some niches where this Llano stuff fits, though. Not sure if any of these are on my upcoming computer menu, but I've got one particular box where if it suddenly vaporized, I might replace it with Llano. Might.
Wow. I know you won't like hearing this, but: did you know that you're part of the problem?
Seriously, you really can just say no. There are no negative consequences to doing that. Really, I promise. Give it a try.
Forget all the nuke sensationalism. LANL had a big wakeup call about a decade ago, concrete doesn't so easily burn, and it's unlikely anything really terrible that the "reporters" want to talk about, is going to happen. It would take a transgovernment level of incompetence; something humanity hasn't seen yet.
OTOH, adios Pajarito. I was there three and a half weeks ago, and when I checked the fire maps last night .. Camp May is totally inside the fire perimeter now. It's been an annual tradition for us to drive up there for Summerfest every year, hike on the ski slopes and watch the bikers, drink nearly all of New Mexico's microbrews, hang out with the Atom Mashers (Los Alamos' version of our Dukes of Ale) and have a good time. Reminisce about a previous year (finally amusing with hindsight) when some ravers scheduled their thing at the same time as Summerfest, so that the forest echoed with techno all night while we tried to sleep off our drunkenness. But now, I think all that is over.
Driving up there, you see the 2000 fire is still a massive scar, a forest of dead trees. That tells me that a decade from now, all of the stuff we're losing right now, will still be gone. Sure, if you take the long view, these fires are inevitable and the forest will always grow back. A lot of good that does me, a mere human without centuries to spare. I'll never see it again.
Bandolier is trashed too. Valles Caldera is at least seriously threatened. Dixon Apples (no 2011 crop anyway) had a damn close call; with pretty much everything surrounding the orchard destroyed. Urban Northern New Mexicans (i.e. the majority of the voting population) are really feeling this one, because this time it's one of our very favorite playgrounds getting burned.
You can see a shift in public attitudes about fireworks. I don't know that fireworks even caused this fire, but reason always said that it was a serious risk, and now the common New Mexican is having the lesson pounded into their hearts regardless of whatever their brains were telling them. They're (mostly) all changing their attitudes, right before my eyes. I think we'll almost certainly see some policy changes as a result.
First, gather your materials. You will need one gallon of emperor penguin blood, and two pounds of dried arctic tundra flowers. And scorpion venom for the base, raw power (almost everything needs scorpion venom these days so I assume you already have a bulk supply.) Reusable materials include a hooded cloak made from a leopard seal pelt and a totem made from a polar bear skull.
Huh? No, I'm under the impression it's not totally free, and that idle equipment uses less energy than busy equipment.
I'm not arguing otherwise; I'm saying that since (approx) the 1920s we've had something that scales massively better than both individual streaming and your physical object strawman. That tech is called broadcast. No, it's not always and the right answer for a given application, but when you can use it, it's incredibly efficient and nothing else is in the same league.
The reason you don't think twice about those old techs' vulnerabilities, is that after you think once, you realize that its insecurity is inevitable.
VoIP doesn't have to be insecure; it's actually feasible to do it right, because your "terminal" is so outrageously powerful and capable in a way that couldn't be dreamt of on the 1880s.
The reason to worry about it, even if you're not doing anything illegal, is that systems that are deliberately designed to be insecure (specifically, insecure to criminals) are likely to be insecure to others, too. If LE is listening, who else? You remember what happened to the Greek government, right?
Designing this stuff to be deliberately insecure is just plain absurd, and we ought to be thinking of it as very strange and very evil, for new tech to not be all that it can be. So yeah, of course I advocate people "find another tool." That applies to everyone, not just people whose adversarial "brother" happens to be the Big one.
Limiting purchase is also limiting sale and distribution; the speaker's rights are being infringed. Nobody has come up with a way to limit someone's ability to buy something, which doesn't somehow also limit someone's ability to sell something. And since so much speech today is for-sale speech (i.e. not everyone is handing out pamphlets for free; some people sell books), putting limitations on sales in considered equivalent to putting limitations on publishing.
Imagine a 1776 law saying that Thomas Payne is free to distribute his "Common Sense" pamphlets, but will be punished if he hands them to some particular class of people (e.g. native born American taxpayers, or slaves, or foreigners, or children -- pick your poison, because it doesn't matter), thus needs to check the ids of those to whom he hands copies of "Common Sense." No matter whom you single out as a receiver of speech and how well you argue there are good reasons for government to limit what they receive or how their receive it, you're also harming Payne.
The founders would want to make these sort of laws illegal. So they did. It's up to us to either stay the course on that decision, or have the balls to say the First Amendment was a bad idea.
Alcohol and cigarettes don't have explicit clauses in the constitution saying that the government isn't allowed to pass laws against them. Speech is special.
Oh, how I sometimes enjoy reading your stories, mcgrew. But if your mind is unable to sufficiently twist to accommodate this perversion, then, gee, I'm almost disappointed.
Cool idea; I think it's just a matter of having the idea. A lot of this stuff was invented back when RAM was more expensive so it wouldn't have been practical at the time.
It would be pretty damn easy to have MythTV use a ramdisk for its live TV buffer (or maybe tmpfs as a compromise; I gotta check out how it handles the live buffer's space management), and MythTV itself wouldn't need to be changed for that. It's just a matter of configuration.
I think I'll try this out the next time I'm screwing around with my mythbackend box.
Good grief, you just substituted one "inefficiency" with something literally a thousand times less efficient.
Broadcast combined with DVRs: information transmitted once.
Netflix/Hulu/Youtube: information transmitted once for each viewer. Your "efficient" approach just multiplied bandwidth usage by several orders of magnitude, and guess what: it's networking hardware (which consumes energy while it's doing it's thing) which ultimately delivers bandwidth. You might not see all this happening, since it's outside your house, but don't think you're not paying for the energy.
There's nothing wrong with your DVR doing its work while you're asleep; whatever you use is going to do its work some time. The complaint is that people are using DVRs which don't themselves go to sleep while they're not working. (Well, that combined with the "live TV" use case many DVRs implement even for people who don't need to use it, which in turn causes it to always be working.)
Eh, just say it's necessary and proper to regulate interstate commerce. Name any conceivable thing any government may ever want to do, which isn't covered by that power.
I think it's actually a bad platitude, because "verify" is always implemented as a nested trust, and that trust often turns out to be serial but the platitude glosses over that.
It goes like this: Is this person authorized to enter the building? Yes, probably, or else why would he be at the door? Well, let's verify: does he have a keycard? Yes, he has a keycard, and we trust the keycard. Why do we trust the keycard? Because only party X has the secret number hidden within it. How do we know that? Because they say so.
If any one of those things that you trust goes wrong, you lose. Not that "trust but verify" is really wrong but it isn't explicit about what "verify" really means, so you can follow the "trust but verify" rule of thumb and still screw up.
I think "Require an amazing conspiracy" is best. That makes what you really need more clear. You want several failure probabilities to get multiplied to determine the probability of the system failing. That's where multi-factor authentication comes in, the concept of "require 3 moderately trusted certs" OpenPGP default comes from, etc.
And almost all of these ideas are ignored in most mainstream "security." *sigh* We use complete reliance on any single CA in https, for example. https, one of the most important things for commerce on the net, and we get it totally wrong. Lame. I can't help but thinking, though, that the dumbfuck who thought it up believed he was doing "trust but verify."
The "back-story" was always there, unless you go back to the 1940s or something. The BASIC programmer of 1981 didn't think about things like how does PRINT really work, the garbage collection that kept string variable storage from growing to infinity, etc. The abstraction and (temporary?) ignorance of the back-story is what lets you "just code something quick."
I think the reason things "feel" different now, is just that the back-story is longer and the abstractions are higher. When the 1981 BASIC programmer decided to dig deeper, it wasn't very long before he was working in assembly language, whereas when the 2011 Python programmer digs deeper, he's reading the source code to the library (most of which is itself written in Python) or maybe down in C and learning the OS' API calls. It's a deeper dig before you're thinking about transistors, but I'm not sure that's really important. You've got to start somewhere and really no matter where that is, you're going to start learning new things if you're interested.
Pretty much everyone else is making Linux TVs. People who don't bother to think about the details of what they want/need ("I'm just buying a TV"), are ending up with computers-disguised-as-TVs, running ffmpeg, dlna/upnp clients, etc. "Worst" of all, this stuff is extremely interoperative and allows users to play whatever the hell they feel like playing, without forcing them into using anyone's particular services.
This stuff is quietly creeping into millions of homes, and is rapidly making those little low-power add-on media-player computer systems semi-obsolete. (I wouldn't say completely obsolete, because from what I've seen the TV's software still needs lot of improvement, and playing media is really the only application they run .. for right now. No reason it should be that limited.)
Anyone with an OS agenda to push and who wants to lock users into certain services (e.g. the iTunes store) really ought to be trying to get a piece of that action.
Depending on how you look at it, Apple arguably made these same products several years ago, with some of their iMac models where everything is built into the monitor. They just lacked tuners and HDMI input connectors. ;-)
One of the touchy things about this kind of application is that you're sort of in competition with Google. Sort of.
As far as having (and attempting to monetize) the data itself, it's still yours and you can make a go of it. But the "find a place where condition x" part of the application is something that Google would prefer you use their maps service for. For specialized things like this, right now it is still possible to have a technically superior search than what Google offers, e.g. "Show me where I can get a good IPA within 4 miles of where I am." You can't count on this lasting forever, though, and the last-few-years push for better semantic markup (culminating in schema.org) is only going to hasten things.
If there's an advantage to being an app rather than website, it's that Google can't crawl your data. But that's also a disadvantage too. You're keeping your data out of their searches (so your search capability remains an attractive alternative to theirs) but you're also staying out of the view of the people who use their search.
So the question is: just how unique and special do you really think your data is? All it takes is for a good writer to visit the same microbreweries as you, and no matter how good your data is, it's marginalized.
A related aspect to all this, with regard to Android, is the "Google Experience." As a user I am not even slightly interested in the Google Experience, the gmail integration, etc, but nevertheless it's there and it's getting hawked to users as a feature of the platform. I think Android users are trained to use Google's searching for this kind of thing, so your observation matches predictions -- fewer of them should be paying for an App.
Yog-Sothoth help you if your iPhone users ever remember that they also have a web browser and Google Maps app. When iPhone users get around to rediscovering the web (yes, kids, the web is still there and bigger than ever), it's going to be a major blow to certain app developers.
I think the long-term outlook for these kinds of applications is grim. But good luck to you.