Here's proof that while the Internet might not be SOPA-proof, it might have some resistance legal hacks by the US Govt.

Here's a list of IP addresses for various popular sites.

BTW, write this down -- scripting.com is at 50.16.40.64.

Now all we have to do is have a distributed database that's not owned by the US Govt that lies offshore. I can't imagine what that might look like.

PS: For more motivation, from a political standpoint, check out today's earlier piece.

PPS: SOPA has the fantastic side-effect that it gets people thinking about the architecture of the Internet.

 1/3/2012; 7:27:42 PM.   .

People say I'm an optimist for thinking the Internet will always exist, even though there's an Unternet. But I think I'm a realist. Here's why.

1. They will Disnify the protocols we now think of as The Internet. I don't think it's a matter of probability, it's a certainty.

2. What that means is that using the net will become more like going to the movies or watching TV. A programmed experience. Your choice is which channel to watch, but all the channels will have the same stuff, so it's not actually a choice.

But then Dave, you say, isn't that the Unternet snuffing out the Internet?

To which I would say is that there will have to be a new protocol. That's all.

There was the equivalent of the Internet in Soviet Russia and there is one in China today. People find a way not only to have seditious thoughts, but to share them. No matter what the barriers are.

The people of the United States are spoiled. They think if it's hard to be free then we won't be free. But they don't know.

When we need to communicate directly, person to person, instead of through corporate media, we will find a way to do it.

That doesn't mean the ride is going to be easy. But if you think it hasn't taken a lot of hard work and hail mary's to get to where we are with the net today, as it is, you don't understand how we got here.

That will certainly continue.

 1/3/2012; 2:53:05 PM.   .

An observation I haven't seen anywhere else.

As you develop complex software you identify pieces of code that appear in lots of places, and you factor it. You create one piece of code that can be called from lots of places so you don't have to keep writing it over and over, and so you can maintain the code more easily. It's how you make progress in software.

An example. A bit of code that displays the contents of a log database. I have lots of software that throw messages onto a log so that someone wanting to see what the software is doing can do so quickly. There's a routine called log2.view that takes the address of a log and returns an HTML table that can be inserted into a web page. Screen shot.

Of course the table has styles, and those styles must have default values, and this is where we run into trouble.

If you include the default values with the table text they can't be overridden. That means these must be the styles for every log table.

But what if you've included the log in an app that has a blue theme but the log is designed to display in a red theme. Of course the app developer should be able to do that.

So now the guy who's working on the log displayer code has a tough problem. He can no longer include the styles with the table he generates, because those would be the last ones the browser sees and any efforts the app developer took to override them would be ineffective.

I don't think there's anything to be done about it. It's a fallout of the design of CSS.

I've found two ways to work with this limit -- here's the first:

1. While the core code is in development, include the styles with the code you generate. This makes it easy to tweak the defaults and get it so that it will work in most cases without any overriding at all.

2. Later, when the core code has been deployed and is being used in a few apps, the pattern of use should be established and the things that must be specified are known, and these cannot be overridden.

3. The others are not specified, you accept the browser defaults, or the defaults of the toolkits the app is using (jQuery, Bootstrap, etc).

4. Find a way to publish sample styles that give developers who might use your toolkit an idea of some values that create an attractive interface. But they have to include those styles in the overall stylesheet for their work.

The second way of dealing with it is at the code level. Let the code that invokes the log viewer include parameters to the call that specify values for the crucial styles. And you can bake those into the HTML. So you're not using the cascading-ness of CSS, but you are still providing a way to override the defaults. Now the very highest level code is controlling the styles that are inserted along with the HTML code that's being generated. Of course the parameters will have defaults. But it isn't always practical because often there is no code that's calling a library routine, or it is fairly far away from the place where styles for the app are stored.

BTW, see section 2.3 of this critique of Pascal written by Brian Kernighan in 1981. Seems to be the same problem. "Related program components must be kept separate."

 1/3/2012; 9:28:56 AM.   .