I wonder if this is true. We seem to be seeing claims that different people eating exactly the same food will sometimes lose or gain weight. Strictly controlled studies seem to be in their infancy, but the implication seems to imply the opposite: Some people's digestive systems (gut bacteria and all) effectively turn more of the input into digested "food", leading to weight gain and decrease in fecal output, while others digest less of the input and produce more output. The former store the excess as fat; the latter stay thin or lose weight. There's an implication that "efficient" digestion leads to weight gain and decreased fecal output, while inefficiency produces weight loss and increased fecal output. (Mass is generally conserved, right? ;-)

I suspect that it's actually more complex than that. But most of the comments here do seem to be aimed at blaming people for (presumably intentional) weight gain or loss. For us to say anything with scientific validity, we really should dispense with attempting to place blame, and rather try to document the details of just how the whole process works. Once we have better understanding of the scientific details, maybe we'll be able to give people medical advice that actually helps them reach and stay at whatever weight they'd prefer.

In this case, the summary's snide comment about spurious correlation is probably right on. What is generally believed about weight gain/loss is mostly based on mythology (or marketing ;-), not science, and has been proven wrong so often that it's odd that people even pay attention to claims on the topic any more.

Heh. Funny, but probably not at all accurate. If it turns out that gut bacteria really do explain a major part of a person's weight, effective treatment is unlike to be as simple as "eat shit". Rather, the specific species responsible for various factors related to weight gain/loss will be identified and cultured. Then various controlled combinations of the effective species will be combined in capsules ("pills") and sold at part of the treatment. These might be expensive, at least at first while they're covered by patents.

Treating such pills as "shit" is about as accurate as saying that, since animals wastes are a common food source for the plants we eat, eating vegetables or fruit is the same as eating shit. Not exactly, since the plants (and the composting microorganisms) do significant chemical reorganization "(metabolism") between the shit and the consumed plant organs.

One of the more fun examples is the common commercial mushroom, Agaricus bisporus, whose preferred culture medium is decaying feces of the common grazing animals ("bull shit"). This is fairly well known, of course, and jokes are made about the connection. But nobody seriously considers eating such mushrooms the same as eating shit. Some people are even a bit lax about cleaning them, understanding that by the time they're harvested, the growth medium looks (and smells) more like good, rich topsoil that like cattle manure, because that's effectively what it is.

Turning gut bacteria into medical weight-problem treatment tools will be a bit more complicated than just letting the source material compost; it'll entail separating out the micro-organisms, figuring out what effect each has on its human host, and growing the useful ones in cultures. This will take a while, and the end results won't look (or act) much like a "shit sandwich".

But people do make scatological jokes about mushrooms, and they will do so for medical packages of cultured gut bacteria.

Heh. I came here partly to see how long it'd take before someone invoked the bogus restricted definition of "nauseous". Sure didn't take long. ;-)

I've seen a suggestion that we need a list of the common words that trigger this sort of language peevery, for the benefit of those of us who'd like to "misuse" the words at every opportunity. Anyone know of such a collection? Or should I start making one?

We do have a number of lists of the similarly bogus grammatical "errors", generally expressed in such a way as to violate the bogus rules. E.g.: A preposition is a bad thing to end a sentence with. Or my favorite: Don't use commas, which aren't needed. But I haven't seen such lists of bogus definitions.

Nah; a better comparison would be like making a backup dump. Then, if the original hardware (body) dies, you can just configure a new one and restore all its data from the backup.

Maybe that's what a "soul" really is, a backup made continuously in some celestial data vault.

Of course they will, since they'll generally know their creator(s) personally, and they'll be in routine communication.

A very real problem for the religious folks is that their purported creator seems to refuse to communicate with his (her?) creations. True, religious people routinely claim to be talking directly to their god, but they can't demonstrate this communication to the rest of us. The result is that many of us just dismiss them as making it all up (probably for profit), and they're not really communicating with any such beings at all. If they are, why can't they show us the evidence?

Any real AIs wouldn't have this problem, since their creators would be out and about, showing off their creations for all the world to see (and also for profit).

Funny, but also maybe relevant. Boston is one of many cities that resulted from the slow expansion and merger of a group of small towns that were essentially separate communities before the days of modern transportation. It has lots of "centers" that used to be separated by forest and farmland, but are now a continuous urban area.

It's not hard to find other cities that developed this way. Other cities grew from a specific original center, usually a port area, and were never a "merger of equals". I wonder if the study distinguished these two major cases, and has anything to say about what (if any) structural differences we might find between them.

Does this include ads?

I've done a number of demos of what a site can do to you with pre-fetching. I make a page that shows viewers a few pictures, but also has "hidden" links that you don't see to other images, videos, etc. There are several ways of including such links without the browser actually showing them, which I won't waste time with here. I also include at least one link that's visible as an ordinarily link pointing to a large file that takes a while to download. After talking a while about other parts of the page, I tell the person to click on that link -- and observe that the content shows instantly, although it's obvious large and should take a while to download. This gets across the concept of pre-loading, and why it's useful. But I can also explain that it means stuff you never looked at may have also been downloaded.

Then I tell them to take a look at the source (perhaps teaching them how to do that), and point out the hidden links. I invite them to imagine what the pre-loading could have "installed" in their browser's cached without their knowledge. For instance, they could now be on their local government's terrorist or drug dealer or religious heretic or kiddie-porn lists because of what was just pre-loaded, and the evidence is sitting in their cache. I invite them to discover just what those links actually pre-loaded. And no, I won't tell them how to do that, any more than an actual hostile web site will.

Sometimes I grin and tell them that if they haven't done anything wrong, they have nothing to hide, right? ;-)

Actually, the hidden links generally point to rather innocent stuff, like tourism photos or wikipedia pages or cute cat videos, but they don't know that unless they figure out how to see the hidden content. The most useful is probably a page that simply explains that I could have linked to anything on the Web, and I'll leave it to their imagination what could be in their cache as a result.

Heh. I have a number of friends (acquaintances, colleagues, etc.) who are giving up on IOS, after numerous cases of their apps rejected by Apple, and then in many cases duplicated a month or two later by an Apple app. This tends to lead to a certain amount of what we might call cynicism about the whole process.

I like to remind them (or tell them, if they haven't read their history) that this has always been the story in "cottage industry". You do the work on your own time, and the employer then decides whether what you did deserves pay (and often keeps the rejects rather than returning them to to the worker). Historically, people working in cottage industries have been rather poor, since the employers control the market and take most of the income for their own coffers. In the modern software industry, the employers also normally claim any "intellectual property" that you develop, which of course includes everything that you create if you're a software developer.

But it's nothing new; it's how "unregulated" industries have always worked. Maybe it'll be fun (in a historian sense) to stick around and see how it all plays out in the long run.

Not surprising; your "BBC English" and our "media English" over here in North America are basically artificial dialects developed by the broadcast industries starting back in the 1940s. They even managed to do some fairly scientific testing, assembling listeners with different native dialects, and counting their mistakes when listening to different proposed pronunciations of various words and phrases. Their intent was to to develop dialects that were easily understood by most of their target audiences, and they did a reasonable job of it.

This doesn't help the computers' voice recognition software very much, though, because few customers speak these "standard" artificial dialects well. The software people aren't working on making the customers understand the computer's speech; they're trying to get the computers to understand untrained humans speaking their native dialects. This requires rather different processing than what the broadcasters were trying to do, and is a much more difficult task for us humans, too. It doesn't help that the computers are often listening to humans who aren't totally awake and sober ...

Heh. You obviously haven't work with any of the more expensive ones. I have a small collection of different portable gadgets for web testing, and that statement about buttons definitely isn't true for the various Apple tablets or phones. Thus, there's a little "x" icon whose function is to close the tab/window. I've learned to just start tapping it about twice per second, and maybe by the 3rd or 4th or 6th or 10th tap, it'll close.

Of course, the little monster might know very well that I'm tapping it, but wants to see how serious I am about it.

Of course, Apple's gadgets aren't the only ones like this. They're just one of the worst of a bad lot. And often it's a good idea to not tap too fast, because when the window finally closes, it usually gets replaced with another that'll do something totally unexpected when you tap it in that newly-exposed spot.

Lessee, what might they mean by this? I'm guessing that they set up a committee to review their data-security methods, and have modified them to make it more difficult for the "authorities" to get at the information.

As with political campaigns, when a business uses the word "change" without being specific, you should generally assume that the change will not be to your advantage.

I wonder if any journalist has good information on just what the supposed changes have been. But I wouldn't bet on anything, since it's routine for the PR folks to just make up things that they'd like the journalists to publish.

Well, they can be done recursively, but their usual definitions imply the simpler iterative approach. Using them leads to the problem that you often see, not just with young students, but even with experienced "professional" programmers: They learn that recursion is just a complex, obscure way to do iteration.

If you actually want to get across why recursion is important, you really should use examples in which recursion gives a simpler solution than iteration. One of my favorites, partly because people are usually surprised to discover that it's actually best done recursively, is a task that software does a lot: Given a binary number, generate the decimal representation of the number. The natural (iterative) divide by 10 and output the remainder of each step gives the digits in reverse order. This is fine if you're putting the result in a fixed-width field that you know is wide enough, but it's not fine if you're generating ordinary text with just one space before and after the number or if you don't know how many digits the number will have. To generate the number iteratively in the order we usually say or write the digits requires two passes, one to count the digits, and the other to write them. Or you can generate the digits in little-endian order into a large buffer, then use a second iteration through that buffer to output the digits in big-endian order.

But a faster, more elegant way is to write it recursively, with a routine that saves its remainder digit while it passes the quotient to a recursive call of itself. The bottom-level call finds it has a 1-digit number so it doesn't make the recursive call, but simply outputs its digit, and returns to the caller, which writes the 2nd digit, and so on. Students that understand this now know that recursion can sometimes simplify some (but not all) problems.

There are number of other simple problems that are best solved recursively, but this page's margin is to small to hold the list. ;-)

Well, yeah, they mostly come with most of the pieces you want. But this doesn't help. I've found that trying to find where all the pieces are hidden/renamed in any given distro and then trying to figure out how they've tweaked the config stuff is far too time consuming. While someone else is beating their head against their keyboard over all the frustrations, I can beat them out by downloading the latest stable version of apache and each other package I want, and installing them from scratch. The packages in the repositories tend to not change their UI much, only when they have a good reason to do so. Also, they know that their users will be installing from scratch, so they concentrate in making this easy (which includes being mostly consistent with earlier releases, and providing forums that tend to have useful answers to questions).

So my advice is to just scrap the servers and associated packages that come with the distro. Uninstall them if you can discover how to do that in a reasonable time, or just disable them. Copy the config files from another machine that's close to what you want. You'll get it up in much less time than you'd waste trying to figure out how the distro has tweaked everything.