He'll smoke it later, if he has to. It keeps well frozen, and it's also safer from vermin in the freezer.

I had a fascinating talk last month with a man who lives near a flood plain. Not in it, but the dikes have been overwhelmed enough times in his lifetime that he's seen failures of basic transport and utilities for the area half a dozen times. He uses "surviving a zombie apocalypse" as his guideline for preparedness. So he keeps a plentiful supply of ammo, and practices with his weapons, and loads his own ammo: he also hunts with those and with a bow, and keeps a freezer full of venison. He also keeps quite a large amount of long-term stable food stores, some water and _water testing and purification_ tools. His vehicles are well built, maintained, and he has several small generators, one in the basement (for weather reasons) and one in a vehicle (for portable use).

He's also doing backup fire and rescue duties for his county, and if there's a problem nearby, I want _him_ as one of my first responders.

That's absurd. Learning time-sensitive ordered tasks, such as in music or dance, or alternative ways to express similar ideas, such as language skills, are invaluable to skilled programmers. The ideas of checklists, logical operations, and revising a program on the basis of alternate events, learning about backup and what you can lose without it, are all useful.

I'd be more concerned about what happens with _bad_ programming lessons, being taught to manipulate only GUI based patterns in a teacher expected way or be marked down for not doing it the way an uninformed, underpaid coding monkey wrote to mark the checksheet off their daily tasks and pays no attention to encouraging the children to learn how things work. I'm concerned tht the children will be taught only how to fill out a checklist blindly. I've worked with programmers taught that way, and they can become an active obstacle to good computing, good science, or even good politics.

I'm afraid that a lot of the pre-teen children I've been meeting in public school would be better off, though, with real recess or a daily siesta rather than yet another mandatory lesson that requires sitting in a computer classroom. They're exhausted, and getting their bodies moving is being neglected in conflicting academic policies and goals.

It's been tried. The Fedora and Red Hat build serves were compromised back in 2008, and replaced or scrubbed practically in real time while new GPG signature keys were switched to and published, to avoid the possible installation of binaries whose provenance was compromised.

While correct, this is hardly a kernel specific problem. In many environments, local packages are published without GPG signatures, and installed quite arbitrarily from poorly secured internal repositories and poorly managed third party repositories. Even the most reputable repositories are vulnerable to having their build environments penetrated and signed, but backdoor-enabled packages, published.

Personally, I don't trust Canonical because of their poor attitudes about sending personal system data back to their ad service business. It makes me question their other security practices. Red Hat and the Debian developers have earned my trust through years of thoughtful, public security practice, especially when confronted with security impinging situations.

They've apparently been interfering with open source and free software. (See John Gilmore's notes about the security agency hindered deveopment of IPsec, at http://www.mail-archive.com/cryptography@metzdowd.com/msg12325.html )

This sounds like excellent territory for the Linux based, programmer friendly, free software "One Laptop Per Child" project. The lack of expensive computing power and Windows integration reduces its usefulness for games and expensive or pirated software, they're surprisingly robust, their power consumption is minimal, and their brilliant use of LCD technology makes the batteries last far longer and be far easier to recharge in what is effectively a third world nation.
Quoting from the website for OLPC: "The XO is also designed for constant connectivity. A few children working together under a tree can connect to each other without any other hardware, and a class full of students can share collaborative activities with one another and see what their classmates are doing."

This is exactly the kind of well-designed, robust technology that education and medicine and shopkeepers can use effectively in a third world nation.

According to the original paper at http://cryptome.org/gummy.htm, the gelatin fakes worked quite well as a thin layer over a live finger to defeat the thermal sensors or capacitive sensors designed to detect live fingers. So it's better than older phone apps which did not try to detect "live fingers", but it's vulnerable to precisely the same technology that beat the world's best fingerprint sensors better than 80% of the time, using photocopies of police fingerprint records laid on gelatin, in 2002.

Fingerprint forgery is now a well established technology, with numerous articles such as http://www.stdot.com/pub/ffs_article_asten_akaseva.pdf explaining the basic technology. That publication is 10 years old, and I've seen no evidence of any real improvement in the scanners themselves since then.

Commonplace scanning with the inevitable consumer applications storing it locally, and badly, will unfortunately contribute to the forgery problem by making the replicable fingerprints even more available to thieves and fraudsters. That sidesteps the "digital hash" storage problems, but takes more work to get complete fingerprint scans, such as those stored by the police or military databases for reference matching.

The article made little distinction between the free software and open source movements. That's more distinction than one might expect in such a short article, and a growing annual gathering of more than 7000 people for free software in Brazil rivals the largest Linux and UNIX conferences I've attended.

The investment costs for the first set of solar sails equipment to build the first fleet of asteroid recovery recovery ships is very high. But they need not be manned, and they can start a cycle of cheap solar sails guiding quite large asteroids back to earth orbit for mining. The fiscal ROI for any significant sized asteroids returned to LEO, then used for arbitrary manufacture, including spacecraft, is potentially enormous. It take a very long investment cycle: the asteroids will take years to recover from the asteroid belt, or for more predictable mining with high water content tap Saturn's rings. But the ROI, either way, is potentially _enormous_.

Bringing objects to, and from, larger gravity wells such as those of the Earth and Moon is enormously expensive in energy and "delta V". Without launch catapults or skyhooks all that energy and delta V has to come from rocket fuel. For small, limited payload objects, it's expensive but doable, as is demonstrated by the Apollo program.

For larger, ongoing systems like a lunar colony, the costs are literally astronomical. The potential benefits are often astronomical as well, but many of the benefits are achievable in earth orbit, without needing to deal with another gravity well on the Moon. Solar sail based power gathering, solar sail based asteroid or ice belt mining, zero G crystal growth for computer components, foamed metal manufacture, and enhancements in chemical analysis and production without the gravitational "settling" of heavier components could all pay for orbital stations. With those structures in place, it's then much easier to make the trip to the Moon: your spacecraft can be built as true spacecraft, without having to work in Earth's atmosphere or be over-engineered to survive the brutal launch accelerations necessary to efficiently launch from the Earth's surface to orbit.

But manufacturing spacecraft on the Moon seems ludicrous. Build them in orbit, and never even consider putting them in a deep gravity well.

A well-sealed building, that has to be kept clean and maintained, is very much more difficult to maintain than an environment surrounded by miles of vacuum. Security can be vastly tighter, it's trivial to sterilize equipment by putting it outside for a short period and letting it cycle in the sun. Security is much easier to maintain: The spaces are small, and any personnel or equipment brought to them is recorded and measured to the gram to manage fuel and trajectories. And certain research techniques, such as electro-phoresis, are far simpler in zero gee. And if the lab is ever ruined by natural catastraphe, or a profoundly dangerous bioweapon accidentally created, it can be opened wide and left for vacuum and solar radiation to destroy.

The potential cost of mishandling bio-weapons is so great that some extreme expense to allow critical riesearch but reduce the risk to a minimum would be quite justified, especially with the known containment failures at existing bio-labs. I've seen repeated reports of bio-lab containment failures for decades: increasing that margin of safety could be security well invested.

That seems a very sophisticated, enlightened, multi-layered approach. It can be very difficult to implement so broadly if your mail services are in the hands of another corporate group. MS Exchange managers, for example, can become quite concerned and upset if you want to implement greylisting and SPF blacklists before it even reaches their mail servers, but that's where it's most effective.

Merging the SpamAssassin checks into larger but more efficient regexp statements is a useful technique that I'd encourage you to publish, especially if you publish the tools to build those new rules and move aside the old ones.

Thank you for posting that checklist, that's a vital document for any spam planning.

SpamAssassin, executed through procmail on the mail client's email, is indeed resource intensive and does not scale well for an organization. Other people have mentioned other upstream filtering techniques, such as grey listing and DNS blacklists, but those are limited because of the large numbers of zombied Windows clients around the world, which have their resources rented as botnets to send spam from legitimate environments around the world, partly to evade these filters.

My experience is that spam requires management, not silver bullets. Layers of defense such as supporting SPF, which filters very early and cheaply based on DNS records, helps eliminate most forged gmail.com and hotmail.com and other large domain phishing. More powerful, more expensive filters such as SpamAssassin can be applied on the vastly reduced volume of email that gets past the earlier filters. Unfortunately, if you're processing with a local "procmail" by pulling the email from the mail server to your local machine, it's already too late to activate DNS blacklists or SPF, so the increasing burden on SpamAssassin is predictable.

I'm afraid I don't have a great solution for the original poster except tp push the filtering upstream, to the mail server itself, to reduce the load with those lightweight filters such as SPF or blacklists.