People come up with theories, they get refined, debugged, and eventually tagged as a release candidate.

If the theories seem solid enough, there is a major/product release as something which is solid enough for other people to use in production environments.

As people keep using it, it gets minor patches/revisions. If people find a serious enough flaw/bug, then people start working on creating another major version release (or competing product.)

And, just as in software, if the new version of the theory/science is not backwards compatible to the previous one, there is much wailing and gnashing of teeth.

The change log is a product. It needs to be reviewed, readable to the target customers, and compliant to any necessary contractual, legal, or regulatory disclosures with the appropriate disclaimers. It should not reveal any trade secrets, third party confidential information, violate any vendor NDAs, have any unprofessional remarks about the customers, etc.

It sounds like the problem is you're putting out crap change logs using an automated system to copy things from the issue management system. Do you have policies in place to make sure people don't put crap into the issue management system? Are things being reviewed before the change logs are being put out? Is it being vetted by the necessary product/legal/regulatory folks to make sure nothing is in there that is going to bite you?

If a company published a crap product, then it will get bitten. When a company gets bitten, it's instinctive reaction is to stop putting out change logs to stop getting bitten, because that's the easy, lazy, doesn't take more effort answer. Asking "Whether or not change logs are a good idea?" is the wrong question. The right question is more "Okay, we got bitten because we put out crap change logs. How do we stop putting out crap?"

The answer to that question is generally something called 'Hard Work'. If the company isn't willing to put in the effort to make a good change log (appropriate policies to capture the relevant changes, tech writer/tech doc support to clean it up, manager-level review to vet it for compliance, etc.) Then, yes, it may make more business sense to not publish anything rather than to publish garbage. It's not a matter of whether or not change logs are good or bad -- good change logs are good, bad change logs are bad. The question is: How do you generate good change logs?

Ah, right. Thanks.

Think it was John Brunner's "The Shockwave Runner", which had the phrase: "There are two kinds of fools -- one who says this is old and therefore good, and the other which says this is new and therefore better."

Pity they can't make this work as a captcha -- harnessing the power of all the spammers instead of the gamers to solve the problem.

Maybe. If the $35 if refunded in the full amount to the end user, who is paying for the arbitration service? If the ISP's detection system erroneously flags a few thousand people, and each of the claims has to be considered, some one is going to be paying for the man-hours of the arbitration work. It's not clear who is bearing the risk of the costs of false claims.

While this seems a bit poorly thought out, if (and only if) it makes the parents *legally* responsible for anything objectionable their children might find, not the ISPs, not other websites, etc., but leaves all the responsibility squarely on parental supervision, then I could get behind this. Shielding ISPs and web hosting companies from frivolous lawsuits from stupid, irresponsible parents is actually positive.

If, if (and only if) it puts the 'think of the children' squarely on the responsibility of the parents while offering them the tools/filters/guidance to supervise computer use, that could be good. Less "How could you put that up where children might find it?" and more "Why are you not being responsible for your children's activities? You were warned, given the tools, shown how to watch them. Why are you not responsible?"

If this does not provide any additional legal protections for ISPs or such from stupid parents, then, no. This is worthless.

Uh, what? If he wants to play with the big boys, he ought to be a big boy. That's like saying everyone ought to get a fair shot to be on an Olympic athletic team -- and, in fact, everyone does, but you have to be able to qualify. He cannot even raise $50K in non-corporate donations, and wants to play with the big boys? And is whining on slashdot for help, not to raise contributions, but to whine harder?

It would be more respectable if instead of the misleading headline of "Libertarian Candidate Excluded from Debate for Refusing Corporate Donations", as opposed to "Libertarian Candidate Excluded from Debate because No One Will Donate", and whining, the article instead had been more of a "What is the most efficient/best ways of soliciting/gathering online political contributions for a third party candidate from small/non-corporate donors?" Or perhaps inquiring about the equivalent of a kickstarter site for political candidate, etc.

I can't tell what he's asking for, or what he actually believes. I think your opinion about what he believes in might be true, but who knows?

I rather thought ABC is a private business, so from a Libertarian point of view, I would think they could decide whatever they want as far as who to include on their own debate?

Or, if you are not accepting corporate donations, why are you interested in going on a debate that is essentially sponsored by a corporation -- i.e. ABC -- and their advertisers?

Unless there is something else here, this sounds a bit petulant.

Okay. So, essentially the same location, so it sounds like you're already familiar with/on top of most of the local issues/regulations/environment, plus you have the Fire Code bit, so... actually sounds like you're in pretty good shape.

Does the IT systems have to be up 24/7 for the CNC rigs? If so, what about UPS/generators/power backup?

You mention security systems, too -- that's another ball of wax. Going with badges, biometrics, security guards, or what?

Fire systems? Are you both the IT guy and the guy in charge of a fire suppression system? In a CNC manufacturing environment? Do you work with hazardous materials on the CNC floor? If so, get an expert.

Hot climate, cold climate? Wet, dry? Flood zone? Likely to get buried in snow zone? Is the new facility out in the middle of nowhere? Middle of a big city? High crime zone? War zone? It sounds like you've got the obvious stuff down, but are asking for the non-obvious, but without a more information, the non-obvious stuff is harder to suggest. (i.e the sort of thing like 'Oh, it's in *that* country/state -- don't do X, because regulation/union/group Y will bite you.') It's hard to 'be in your shoes' without a bit more info.

If the number of links grows linearly, then your performance is going to be poor -- though this may be hidden by over-subscription.

Keep in mind that if your network is actually a tree, there is only one route from any point to any other, so you have no redundancy. (It is also possible the redundancy/network complexity is not directly obvious -- when I was dealing with these matters we had a single IP PVC set up over a frame relay network -- even though it looked like a single IP connection, there were failover paths setup within the frame-relay network, so the network topology was actually a bit more complex than it looked from the IP level -- and more expensive than it looked from the IP level, too.) Most of the IP networks I dealt with at the time had no single point of failure between any interior node, so it was a partial graph.

The costs can be tricky. Occasionally you hit the corner case of 'we want to upgrade from a T1 to a T3 in this location, but that requires a larger router, and there is no more space left in that colocation, so we would have to re-home all the customers to a different colocation.' (Also, if the equipment changes, on-site spares have to be factored in, plus tech training.) If you want another non-linear cost, consider customer support -- if you maintain X support staff per N customers, for every so many support staff, you will probably require an additional manager/human resources/etc. person. That requires a certain number more customers to cover the costs of that position, etc.

It is possible to beat this, no question, but there are an awful lot of small ISPs that tried to become big ISPs that failed that suggest that a lot of folks did not figure out the scaling problems ahead of time. The goal of a business is *profit*, not necessarily *size*. If growing 'larger' would not result in more profit, there is no incentive for the company to build out -- that's pretty basic business. It may depend on the right opportunity/technology to make the growth possible.

(You might do a google search on business 'growing too fast'. Growth is not always a good idea, nor always profitable.)

As far as mergers go, you need to factor in whether or not the merging companies have a 'paid for' network infrastructure, etc. If the two networks are already functional as is, then there is no need to do any expansion or new interconnection -- there is no additional capital expenditure involved. The networks could be run as is. (And of course, it's cheaper to buy out someone who has failed, or at least their equipment, cheap, after they've grown too fast and went bust.)

The problem I am referring to is the build-out stage where you have to invest cap-ex to build out capacity and need to be able to recoup that (before the equipment becomes obsolete.) The bigger/more complex the network is, the more it costs to fiddle with it. (Well, if you want to keep it running, that is. If you toss quality out the window, you can do these things really cheap.) The problem can be beat, but it's not necessarily an easy one.

So, given that growth does not always equate to profit (and growing too much or over-extension can lead to an implosion), and that revenue does not scale with costs (network growth is non-linear (even trees), personnel growth is non-linear, etc.) there is a certain pressure not to grow. There has to be a trick that enables the scaling -- better customer support system, new network gear at a cheaper price point, etc. However, if that requires new cap-ex/op-ex to implement, then there has to be a business case to do so.

Also, margins per customer can be really, really important. If you are trying to do a mass market, consumer service with tight margins with the goal of making a profit through volume, you are extremely subject to market prices. (I.e. in an extreme case, if the profit margin per customer is only $1 per customer, with a million customers, then that would be $1 million per month in profit. If anything happens which either raises the cost of business per user by $2, or competitor prices forces the rate down by a $2, then that suddenly becomes $1 million per month loss.) High volume, low margin == volatile. (Or, growing too fast by reducing margins to cover the cost of growth, then getting hit by price pressure/cost changes => business implosion.)

(If the growth is into a 'new market', there may be additional risks/costs that have to be factored in that may not have anything directly to do with the network, either, but that's another issue.)

(Of course, at a certain size, there's always something going wrong *somewhere*. A colocation flooded because of a hurricane. A landlord deciding to remodel a building and giving six months notice that all of the equipment/lines running into the colocation has to be gone. Etc.)

So, I am pretty confident in the original statement that there are certain pressures, capitalism-wise, to be only as large and as fast as necessary -- i.e. the optimum size that produces the most profit for the least risk. These can be beat (successfully) but not always easily. Screwing up growth can be a disaster. If there isn't a clear solution to growing the network *profitably*, then the company won't (and probably shouldn't.)

Mergers are not necessarily 'growing' the network. When the mergers allow the resulting company to lay people off (i.e. sales, etc.) while still maintaining the same customer base on the same networks (i.e. no network investment growth), then the mergers are not 'growing' anything and are in fact improving their margins by laying off people. (Though sometimes the companies claim that their new, more profitable selves can now invest more in the networks.

There is one annoying gotcha to network capacity planning -- network costs tend to increase in a non-linear fashion though the subscriber base (and hence revenue) does.

If you can maintain a pure hub-and-spoke network topology where all user connections connect to the same central point, then the network cost grows in direct proportion to the user count -- each time you add a new user, you add a new spoke. So the total number of network links is the same as the total number of users. As long as the hub is adequate, this works.

The opposite topology (which you almost never see) is that for each point added to the network, you add a link to all existing points, so that each network node has a direct link to every other node. This means the total number of links is, for *n* number of users, is (n*(n-1))/2 -- or, if you prefer, O(N^2) growth. The more users that are added, the more expensive it becomes to add more users. (A crude visualization would be that the user base represents the circumference of a circle, and the network represents (a fraction) of the area of the circle that connects each point on the circumference. The growth of the length of the circumference is linear, but the network growth is squared.)

Realistic networks fall somewhere in between, but that still means that each new user/network node added to the network is slightly more expensive than the previous one in terms of cost. This plays merry hell with trying to juggle network capacity planning verses performance verses revenues verses growth. Even assuming the most altruistic company that is making only a minimal profit, network growth increases costs more than it increases profits, barring the introduction of more efficient technologies. (And the introduction of new technologies (i.e. new vendors) in a large network can be a huge, profit-eating cost in terms of the capital expenditure, and can be a surprising drain on operational expenditures to maintain multiple vendor platforms at once.)

So there is a certain pressure, capitalism-wise, to be only as large and fast as one has to be, and not one penny more.

It is not "We need more applications" -- that is easy enough.

Getting people to create hundreds of (cr)applications for Linux is trivial and is not a solution and may in part be one aspect of the problem.

A somewhat more accurate strawman would be "We need more *good* or *compelling* applications" -- that's challenging. Still only a part of the answer, but closer. It requires answering "What does 'good' or 'compelling' mean in this context?", etc.