yrb

I pretty much agree completely.

The place it normally gets interesting with this approach is where exactly do you put the demark, especially in the FTTN world. Since you are going to most likely want the public utility to own the DSLAMs in areas with low/medium (eg, suburbs) population density, because the area covered by a cabinet is so small (because technologies like VDSL2+ have such a small optimal zone) and rack space in cabinets is normally at a high premium.

You are also going to most likely want the public utility to own the fibre backhaul from the cabinets to a central exchange. Because of port density constraints and the fact that the DSLAM is probably going to need to be managed by the public utility to stop access seekers doing silly things that affect other access seekers customers.

Now the public utility is also going to need some Ethernet switches to split this out to the various access seekers. Then you have issues of regional backhaul etc...

The issues are different again with the PON (Passive optical networks) family of technologies, but you can pretty much swap DSLAM for POLT, though the customer densities change the economics a bit.

With ISPs handling regional level aggregation and backhaul would probably be the optimal level in my mind at this point in time. But it is becoming interesting what the ISPs role really is anymore, once you take such a large amount of the infrastructure management off their hands. Since it would seem to be in between a traditional consumer ISP and an ISP that purely does transit.

Except I am not sure it is destined to become a commodity in the near future because of the sky high capital expenditure required to roll out most forms of infrastructure in most places.

Things just really don't work on human time/relationship scales anymore, especially when it comes to internet services. Communications can move in milliseconds now, diagnosing and fixing complex issues is still on the order of hours/years/lifetimes!

It doesn't help that your customers often know about issues you are having before you do. So say ~30min to get notified of an issue (Which is not unrealistic for a non obvious issue that isn't something you actively monitor) - Quick 10min investigation to assess what the scale of the issue is, another 3-5min to post a couple notifications, and that is the better part of a hour gone, and you haven't even got around to trying to come up with a fix.

;) How many "innocent" hurried changes have you seen blow up in production.

I agree with what your saying, just don't know how applicable it is to the class of software we are discussing.

It would appear to me if you ever hit the failure mode of needing a C++ programmer within the hour, to fix a completely unknown codebase. It very much seems to me like you have already lost.

As far as I have seen the verification and testing process before deployment, takes on the order of a months. Let alone how long it takes to really understand a codebase, and the potential ramifications of a change. Also it is not like you can hire any C++ programmer, you need someone versed in the subset and style that is used in these safety critical areas.

Seems like you are optimizing for something that isn't really an issue, and if it ever becomes an issue you are likely to have much bigger problems. If you lose the people with all your domain knowledge, and understanding of how it is build and why. I would argue that language is the least of your issues.

While both represent walled gardens. One by search ranking the other by latency/bandwidth.

It is a lot easier to change/create a search provider since there is nothing that has locked you in as such. But remember you are there because you find their walled garden useful.

However you don't have a choice if your packets are going to traverse AT&T. Also on some level creating a new search engine is a less costly task that rolling out new internet infrastructure. If AT&T shaping was opt-in and they didn't unfairly discriminate against those who haven't opted in ;) but that means you have to trust them to be benevolent.

They can do good with shaping, just like google does good with ranking. However once you grant them this power, you better hope they don't use it in an anticompetitive way.

I am not sure how regulation is really going to help anyone except the black hat SEOs. If anything it will just make things worse by slowing down the ability of google to respond to black hat SEO and creating a more bureaucratic form of whose hand do I grease to get on the first page. I am not sure the author really grasps the scale that they are playing, or maybe he is sick of playing on that scale.

The author states that the only the large players can afford to reverse engineer googles current ranking algorithm.

However I don't see how forcing them to publish the exact algorithms would create any meaningful change for the "better". The big players will still game the system if anything they will be more successful as they will be able to move resources from reverse engineering to exploiting, and will have a larger time frame where an approach is viable due to red tape.

The little guys will probably be just as bad off with roughly the same rule of thumbs they have today.