By that time there were millions of slaves in the U.S. and as you pointed out, they reproduced and even resulted in a surplus for the larger plantations. There was a lively internal slave trade at that point.

Actually, the war on poverty was working until the GOP insisted on surrendering.

And yes, businesses that mooch on the taxpayer to supplement their inadequate payroll are evil. They know damned well they are mooching off of people with a lot less than they already have.

We don't claim the car thief is blameless if you leave your keys in your car, do we?

As timeOday said, they cost about 10 years wages for an equivalent free worker, so if the owner didn't keep them alive and well at least that long, it was a losing proposition.

So as despicable as the practice was, the modern practice is in some ways worse.

That's the new innovation of forced labor. In the bad old days, slaves were quite expensive so you had to provide food, clothing, shelter, and at least minimal healthcare.

The new improved forced labor lets them pick up the slaves cheap, provide them minimal food and shelter and just let them die from overwork.

I don't think people understand the Unix philosophy. They think it's about limiting yourself to pipelines, but it's not. It's about writing simple robust programs that interact through a common, relatively high level interface, such as a pipeline. But that interface doesn't have to be a pipeline. It could be HTTP Requests and Responses.

The idea of increasing concurrency in a web application through small, asynchronous event handlers has a distinctly Unix flavor. After all the event handlers tend to run top to bottom and typically produce an output stream from an input stream (although it may simply modify one or the other or do something orthogonal to either like logging). The use of a standardized, high level interface allows you to keep the modules weakly coupled, and that's the real point of the Unix philosophy.

I think he's off his meds again.

Both upsides were already easily solvable. Most distro's rc scripts already call a function to start a daemon. That could easily have called a helper program to set up the cgroup and register on dbus to act as a controller for the group.

Meanwhile, at least Debian's rc scripts already had dependencies listed in their headers that could be used to compute a start order. It could as easily be used to compute a makefile to start in parallel.

The problem is, now that the init process will be such a hairball of dependencies, it becomes harder to implement such solutions without seemingly unrelated bits breaking. For example, no reasonable person expects the GUI desktop to break if you switch out init. (and no reasonable person creates such a dependency)

Or, you go with signed routes. That is, you use a public key system to prove that you have the right to broadcast a route for a particular subnet.

In practice, it will probably mean some router upgrades. No more router cpus that were considered a bit underpowered for a calculator in the '90s. However, as an interim measure, it could be used to set some BGP filters to limit the potential damage.

The problem is, we're tipped over into corporatism where the net is controlled by a very few very large legal sictions tha tthe courts insist are somehow people.

You worry about the bad old government censoring the net but forget to worry about the ISPs censoring the net.

I can't imagine why you think the overmetered network protects us from the market cornering legislation and the pompous asses. Without proper net neutrality, we get all of the above and nowhere to turn.

What you're describing is a random number generator with a key to initialize it. Some of the good ones might be good enough (or might not). Anything you can keep in your head is going to be crap and fairly easily breakable. Either way, you're still better off to just exchange regular secret keys at your meeting, which can be concealed in a variety of ways. Even real one time pads can be fairly easily concealed - a "blank" USB key, for example.

You didn't say so, but I'm assuming you're encrypting your message using the book page as a one time pad, then obscuring it using steganography. If someone sufficiently motivated were after your criminals, they could break that. Steganography isn't much protection when someone knows there might be hidden messages. And your one time pad, while one time, isn't random. Book pages have quite a bit of structure.

Any structure in a one time pad makes it vulnerable. To the point where people have gone to great lengths to construct them using the best random numbers obtainable, from devices ranging from antennae monitoring the ionosphere to quantum devices.

One time pads have been, and probably are, used extensively. You send a bunch of random data to someone via some secure method, which is usually very slow (like hopping on an airplane with a DVD full of random numbers on your person). You can then exchange messages securely using a convenient and fast channel, such as e-mail. See the utility there?

It depends on your design goals.

In Asimov's story universe, the Three Laws are so deeply embedded in robotics technology they can't be circumvented by subsequent designers -- not without throwing out all subsequent robotics technology developments and starting over again from scratch. That's one heck of a tall order. Complaining about a corner case in which the system doesn't work as you'd like after they achieved that seems like nitpicking.

We do know that *more* sophisticated robots can designed make more subtle ethical systems -- which is another sign of a robust fundamental design. The simplistic ethics is what subsequent designers get when they get "for free" when they use an off-the-shelf positronic brain to control a welding robot or bread-slicing machine.

Think of the basic positronic brain design as a design framework. One of the hallmarks of a robust framework is that easy things are easy and hard things are possible. By simply using the positronic framework the designers of the bread slicing machine don't have to figure out all the ways the machine might slice a person's fingers off. The framework takes care of that for them.