Quinthar

McDonalds isn't the problem; we are.

Everybody knows obesity is a problem, and that it's inflating medical costs that are gradually bankrupting our nation.  But I think most people have a misguided sense that obesity is the result of fast-food using poor-quality ingredients and somehow tricking people into eating them.  For example, I saw this article on BoingBoing talking about the uproar over the high calorie count in McDonald's new oatmeal.

Basically, it has "as much sugar as a Snicker's bar and as many calories as a hamburger".  That sounds really alarming, but it made me wonder: how many calories does oatmeal normally have?  What could McDonald's have possibly done to take something good and make it bad?  So I did some research on oatmeal, only to eventually find that the BoingBoing commentators had done a lot more.

To make a long story short, the McDonald's oatmeal is totally fine.  The oatmeal itself is mostly normal, and most of "extra" calories really come from them adding a bunch of dried fruit (which is hardly an atrocity) and adding brown sugar and cream by default (which is commonly done at home anyway).  So... false alarm.

Again and again I think people overreact when it comes to the "quality" of fast food.  Yes it's made fast and in high volume, but even with the freshest possible ingredients on hand I think the results would come out looking, tasting, and nourishing about the same.  For example, In-N-Out arguably uses the freshest ingredients of any fast-food burger joint, and to compare:

McDonald's hamburger = 100g serving size, 250 calories, 9g fat
In-N-Out hamburger = 243g serving size, 310 calories, 10g fat

(Incidentally, the standard In-N-Out burger comes with a spread that adds another 80 calories and 9g of fat.  But I'm going with the mustard/ketchup option to compare more equally to McDonald's.)

So the McDonald's burger has 2.5 calories/g, while the In-N-Out burger has only 1.3 calories/g.  But both have about the same fat.  What gives?  My sense is the difference has nothing to do with the quality of the ingredients, and everything to do with In-N-Out putting heavy, water-filled veggies (lettuce, onion, tomato) on while McDonalds doesn't.  I don't have the data in front of me, but I bet if you took all the veggies off the In-N-Out burger (or added an equal amount of veggies to the McDonald's burger) -- basically assembling them the same way -- you'd get largely the same results.

In other words, both use more or less the same quality ingredients, with essentially the same nutrition, despite McDonalds being demonized as the culinary antichrist while In-N-Out being some kind of organic savior.

In my opinion, the problem with McDonald's (or any other fast food chain) isn't that their food is so much higher calorie than if you were to fix it yourself.  Rather, the problem is they cater to a customer base who is actively looking for high-calorie, high-fat food.  Said another way, given a fully-stocked kitchen (and the willpower and expertise to actually cook), I wager most people would basically fix something as bad or worse than McDonald's, intentionally.

This is somewhat reinforced by this study that suggests that NY's "label the calories as big as the price" plan is failing to produce results.  I'll admit, I thought the plan was a good one, and I'm disappointed it didn't work.  This suggests people know they're eating crap food (even if composed of reasonable-quality ingredients), but simply don't care.


So where am I going with all this?  I think the solution can't just demonize the quality of fast food ingredients (because they're fine) or emphasize how many calories people are buying (because they don't care).  And it's not enough to highlight the long-term effects of those decisions; those are already pretty apparent and non-motivational.

Rather, we need some way to identify people who are on a bad long-term path and create short-term consequences.  And by "we need" I mean "given that our country is being bankrupt by vast medical insurance programs with out-of-control cost increases driven by health epidemics such as obesity, taxpayers should demand" that something be done to prevent people from taking actions that leave us on the hook for massive medical bills down the road.

Similar to how people with good driving records and safe-driving courses get lower insurance premiums, I think we should do the same for Medicare/Medicaid.  Create programs where people can earn better care by making healthy choices.  Granted, healthy people need less medical care so it doesn't make sense to give them *more* of it as a reward for needing *less* of it.  But what if healthy people got tax credits and prioritized non-emergency care.  Shorter waits, nicer rooms, more choice.  Everybody still gets the same quality of medical attention (for better or worse), but people who actively maintain healthy lifestyles are rewarded with status, convenience, and comfort.

Furthermore -- and this is the most important point -- it should be made very clear to you which "service tier" you're in at all times, creating an *immediate* positive consequence for healthy actions that normally only have long-term effects.  So everybody who does nothing is lumped into the "standard" tier; you needn't do anything special.  But you should be constantly encouraged to upgrade to the "premium" tier by just demonstrating healthy decisions.  How exactly that is done is obviously a big question, but some ideas:

- Get credit for healthy-eating, healthy-lifestyle training courses
- Demonstrate participation in preventative care programs
- Get regular checkups to certify you haven't been abusing drugs
- Wear an electronic patch that measures caloric intake and expenditure
- Join a gym and hire a certified trainer who reports activity to your doctor

And so on.  Every problem has a ton of complications, don't get me wrong.  And it'll be a horribly political process to decide what's "healthy".  But perhaps something like this can start to gradually steer us in the right direction?


Admittedly, that won't be enough.  Not even remotely close to what's needed to actually get things under control.  But it might be a step in the right direction of preparing people to resume individual accountability for their health given we probably have little choice but to vastly scale back coverage (perhaps starting with reducing end-of-life care, which is estimated to take roughly 30% of Medicare's budget), followed by probable rationing of key medical resources.  (Read here for a hyperbolic freakout session about kidney rationing, which obscures a few good ideas under a heap of total garbage.)

Ultimately, I'm all for reducing government involvement in a lot of things.  But it will mean *reducing*, not eliminating.  I think we should provide a *minimum* level of universal healthcare, recognizing that it's simply not possible to give maximum care to everybody.  And we should eliminate barriers that prevent private insurance health plans from operating at maximum competitive effectiveness.

At the end of the day, very expensive or end-of-life treatment is a luxury for the rich, just like helicopters and fast cars.  Whether we like it or not, that's just the way it is.  But like helicopters and fast cars, they're terrible investments on which only the rich should waste their money.  Instead, we should focus on expanding coverage of inexpensive, early-life care to everybody because it's an investment in society that's returns dividends to us all.  And that's what the government is there to help us do.

-david

Egypt's Internet Blackout and How to Build a Decentralized Twitter

So Egypt has its internet back, but I still can't figure out precisely
what was gone when it was gone. Can you help? So far as I can determine:

- Cellular service was only shut off in regions (eg, at the sites of the
major protests) while left on elsewhere in the country.

- Landlines continued functioning everywhere.

- I've seen no sign that domestic internet was affected. For example,
it's possible that all homes and businesses still had live network
connections that simply weren't resolving DNS, or perhaps *were*
resolving DNS internally. It's even possible that local DNS caches were
resolving completely normally -- even for international domains --
except there were no routes to the IP addresses to which they resolved.

- Indeed, even if all ISPs turned off all broadband everywhere, there
would still be large pockets of functioning LANs (universities, housing
complexes, hotels, etc).

- The consequences of total domestic internet blackout are very severe.
I don't see any sign that government and critical services run their
own network (though the military might), nor any sign that the internet
was selectively disabled for only individuals and businesses while
sparing hospitals, police stations, power plants, etc. Furthermore, I
haven't heard that any critical services lost domestic internet or
telephone access, even though I imagine that would be a very interesting
story if true.

I think understanding what actually happened is important such that we
can plan and act in a way that is optimized for the real world, rather
than a (potentially) unreasonable worst-case scenario that never
actually occurs. I'd love your help in fact-checking the above
assumptions by providing evidence (links) to the contrary.

Regardless, none of this really changes my core thesis, which is that
whatever solution built must:

- Somehow become very popular and widely deployed *before* the event,
requiring substantial "added value" even when the internet is accessible.

- Define "added value" in terms that the average person cares about,
which is *not* anonymity, security, privacy, etc. Rather, it needs to
be speed, convenience, reliability, and so on.

- Take an approach of "adding to" rather than "replacing" whatever
more-popular alternatives are already in place (twitter, aim,
bittorrent, skype, etc) so as to ensure users sacrifice nothing by using it.

- Take best, simultaneous advantage of whatever resources are available,
at all times. If there is BlueTooth, use it. If there is a functioning
LAN, use it. If there is a functioning sitewide/domestic/international
WAN, use it. And so on.

- Anticipate the imminent failure of any of these methods at any time by
proactively establishing fallbacks (eg, a DHT in case DNS fails, gossip
in case the DHT fails, sneakernet in case wireless fails, etc.).

- Require no change in user behavior when one or more methods fail. So
the interface used to tweet, fileshare, make a call, etc -- all these
need to work the same for the user (to the greatest possible degree)
irrespective of what transport is used.

- Work on standard, unaltered consumer hardware (no custom firmware, mod
kits, jailbreaks, etc) with standard installation methods (app stores,
web, etc).

- Be incredibly easy for people to use who aren't tech-savvy. This
means spending 10x more time testing and refining the usability of the
system than actually developing sexy esoteric features.

I really do think this is a relatively easy thing to build (at least, in
a minimal form), using existing hardware and proven algorithms. I'd
suggest something like:

1) Start with an open-source twitter application. Google suggests this
one, though I haven't personally used it:
http://getbuzzbird.com/bb/

2) Add a central server, just to make it really easy for nodes to
communicate directly. (We'll replace this with a NAT-penetrating mesh
*after* the much more difficult task of getting this popular and widely
deployed.)

3) When you start up, connect to this central server. Furthermore,
whenever you see a tweet from anyone else using this client, "subscribe"
to that user via this central server. (Eventually you'd establish a
direct connection here, but we'll deal with that later.)

4) Every time you tweet, also post your tweet to this central server,
which rebroadcasts it in realtime to everyone subscribed to you. Voila:
we've just built an overlay on top of twitter, without the user even
knowing. All they will know is that tweets from other BuzzBird users
for some reason appear instantly. And the next time twitter goes down,
all tweets between buzzbird users will continue functioning as normal.

5) Then start layering features on top of this, focused on making a
twitter client that is legitimately the best -- irrespective of the
secret overlay.

6) For example, add a photo tweeting service. Publicly it'll use
twitpic or instagram or whatever, so all all other users will see your
photos just fine. But buzzbird users will broadcast the photo via this
central server, faster and more reliably than the other services, as
well as locally cached for offline viewing. Repeat for video, files,
phone calls, etc.

7) At some point when you've established that people actually like and
use buzzbird with its very simple and fast central server, THEN start
thinking about P2P. (Seriously, do NOT think about P2P before then as
it'll only slow you down and ensure your project fails.)

8) To start, keep the central server and just use it as a rendezvous
service for NAT penetration. So still centrally managed, but with
direct P2P connections. Then when you come online, you immediately try
to establish NAT-penetrated direct connections with everyone you're
following. This of course immediately presents you with challenges: do
you need to connect to *everyone* you follow? If only some, which? Take
these problems one at a time knowing you can always fall back on the
central server until you perfect it. In other words, the goal is to
remove the central server, but you can take baby steps there by weening
yourself off of it.

9) Similarly, add BlueTooth, ad-hoc wifi, USB hard drive sync (aka
"sneakernet"), etc. These would all be presented to the users in terms
of real world benefit ("Keep chatting while on the airplane!" "Share
huge files with a USB flash drive!" and so on.), while simultaneously
refining the tools that they'll use during a partial or total internet
blackout.

10) Eventually when you've figured out how to move all functions off the
central server -- the nodes start up, establish direct connections to
some relevant subset of each other, build a DHT or mesh network, nodes
that can relay for nodes that can't, etc -- the last function will be
"how does a newly-installed node find its first peer?" This is called
the "bootstrapping" problem, and is typically done with a central
server. But it needn't be done with *your* server. Just use twitter
for this: every time you start, re-watermark your profile image with
your latest IP address (or perhaps put it into your twitter signature
line, or location, or something). This way the moment you do your first
tweet, everybody who sees it will try to contact you (or some subset, so
as to not overload you). Then you can turn off your own central service
and just use twitters.

11) When the "dark days" come and twitter goes offline, your nodes won't
even notice. They'll continue to establish their DHT with whatever
subset of the network is interconnected, relay for each other, etc. If
the internet is totally gone, your users will use bluetooth, wifi,
sneakernets. They'll be ready because you *trained* them to survive on
their own *before* they needed to, rather than just handing them a knife
assuming they'll know how to use it when the time comes.

Really, the biggest challenge in all of this is whoever gets to step (6)
will immediately be acquired by Twitter for an enormous sum of money.
But hopefully that person will, with their new-found wealth, continue on
to (7) and beyond.

This is a doable thing. One person motivated person could do most if
not all of this. Is that person you?

-david

- Jan 2014 (1) - Mar 2012 (1) - Nov 2011 (1) - Oct 2011 (1) - Apr 2011 (1) - Mar 2011 (3) - Feb 2011 (2) - Jan 2011 (9) - Nov 2010 (1) - May 2010 (1) - Mar 2010 (1) - Feb 2010 (1) - Jan 2010 (1) - Dec 2009 (1) - Nov 2009 (1) - Oct 2009 (1) - Sep 2009 (1) - Aug 2009 (2) - Jul 2009 (1) - Jun 2009 (4) - May 2009 (3) - Apr 2009 (3) - Mar 2009 (10) - Feb 2009 (5) - Jan 2009 (3) - Dec 2008 (5) - Nov 2008 (5) - Oct 2008 (5) - Sep 2008 (4) - Aug 2008 (5) - Jul 2008 (11) - Jun 2008 (8) - Feb 2008 (1) - Aug 2007 (1) -