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 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 th
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.
I would rather think businesses would want to label whether or not the produce had any 'patented' genetic modifications applied to them. People ought to be able to know whether or not it might not be legal for them to plant any of the seeds in the produce, after all, if they have not bought a license for the intellectual property in question.
(For the irony impaired, the above comment is intended to contain at 20% of the RDA of iron.)
Not to sound dismissive of the situation, but I have to be kind of curious -- does anyone have the statistics/numbers for how the increasing number of requests to carriers for subscriber data aligns with the increasing number of people using cellular devices (and that some people now have multiple cellular devices)? It would be useful to to understand if the rate of increase of requests is far in excess of the rate of increase in subscriber growth (and perhaps decrease in land-line usage), mimics it, or is smaller than it. (I am assuming it is exceeding the subscriber growth rate considerably, but it would be nice to have the breakdown.)
The effort and cost of designing such a thing is one aspect. *Verifying* that the actual manufactured item is tamper-proof, accurate, etc. is another. For instance, if you have to secure your entire supply chain to make sure none of the components involved might have been compromised or substituted due to cost cutting (keep in mind that this does not have to be someone trying to skew the vote on purpose, it could be someone being cheap or lazy and producing something prone to errors,) then that aspect can take quite a lot of time and effort.
It's not just designing the box. It's designing the box and the entire process such that not only the box but the process of making the box can be audited through out the life-cycle of the box and its operation. (And there might be some level of who audits the auditors, etc. What happens if a part must be replaced by a different part because of a supply chain problem -- does everything need to be re-certified, etc.)
That's not cheap or simple. It's not the design, it's the process and logistics.
Did folks ever get IPv6 multi-homed routing straightened out?
It always felt like conflicting goals at work -- on one hand, people wanted to simplify and shrink the size of the backbone routing tables, but on the other, a purely hierarchical routing space removes redundancy. That is, a tree graph has the property that there is only *one* path between any two nodes, which means a purely hierarchical routing arrangement would mean that the idea of 'routing around censorship' would go into the waste bin because there are no alternative routes possible. (Note that I am differentiating this from redundant *physical* links -- this is a matter of administrative links. If there is no multi-homing and the upstream provider is blocking/filtering/limiting traffic, there is no network route around it, physical redundancy not withstanding.)
So any current best practices for IPv6 multihoming for small ISPs/businesses?
Out of curiosity, If APIs cannot be copyrighted, does this mean they cannot also be covered by the GPL? This would seem to be a fairly major implication of the Oracle vs. Google case. (Speaking strictly about API definitions/header files.)
It must have been a lively debate internally about this. I am sure many inside the companies were pointing out that by removing the physical media component it would destroy the possibility of game resale and the used game market. However, at the same time it kind of shoots their sales channel in the foot -- there's certainly no incentive for retail game stores or other businesses which make their money on having people come in and buy stuff to sell a device which obsoletes all their current sales and also does not provide for any prospects of future game sales.
So, a motherboard with no RAM and no CPU, in the $100 range, I can see. But with Thunderbolt, too? I know the Thunderbolt cables are a bit pricey because of the chips built into those, but are the Thunderbolt controller chips *that* much cheaper than the cable chips?
I must admit, the first thought that came to my mind when reading this is, this sounds like a great setting for some spy thriller or such. I mean, an abandoned military base with launch silos, its own nuclear power, and slowly being destroyed by encroaching ice?
The perfect location to have the mastermind's base located in. At the end, the heroes have to race out of the base as it is finally being destroyed by the ice.
Just where exactly are these 'test servers' in relation to you? What, exactly, was this 'test'? This seems a bit of a worthless test. It's entirely possible your DSL has less than 100 ms latency, but the delay is on the server end or the links in between. This is too vague a scenario to comment on.
My feelings about 'acceptable' latency depend on how much I am paying for it, at what bandwidth, with what level of SLA, and for what purpose.
In some ways, a lot of what is being added to C++ makes me think of Scala, just less readable.
While the additions and extensions certainly make things more interesting and potentially more powerful/easier for the *individual* programmer, I look forward to seeing what sort of interesting train wrecks happen when larger teams try to make use of these features. I certainly hope the debuggers are being updated to be useful when someone's written a template that uses a #define'd macro to specify a closure that is passed through an anonymous function, etc.
This strikes me as the next generation's 'multi-threading' -- where almost every programmer claims they can handle multi-threaded programming, but very few actually do it well. Particularly in teams when interactions require coordination. Going to take a whole new round of winnowing the wheat from the chaff when it comes to finding developers who can actually use these features well without driving their coworkers insane.
Live with the tedium of doing in manually. It sucks, but unless you are going to have to do this exact operation again in the future, don't bother with automating it. Possibly the solution of taking out the hard drive, putting in a drive dock on another computer, and letting that computer back-up and wipe the drive might be slightly less tedious, depending on the situation.
Because, if you listen to what you are asking, you are trying to set up an automated back-up and erase system. Unless you have a Lot Of Time to Test this BEFORE HAND, you could easily end up with an automated screw-up-the-back-up and nuke-everything system. If you successfully manage to create a system that erases several hundred computers without making usable back-ups, that might be a career-limiting move.
You are asking for replacing a single-shot pistol with a high-powered Gatling gun -- this is not unreasonable. However, if you shoot yourself in the foot with such a thing because you are not careful, there will not be a lot of remains left over.
If all the computers are absolutely identical, you might be able to do an automated system, test it against a couple machines, and be able to get it to work. Otherwise, the amount of time you will spend making sure that the automated system does exactly what you need it to do, safely, without ever failing, may end up being as much time as it takes to do it manually.
Oh, you are verifying that your back-ups are usable before nuking the drives, right?
No, *something* is needed so that the other application knows where to send the data to. That identifier does not and should not be a network specific implementation in my opinion.
Then what do you suggest that identifier is? Can't use DNS because there is absolutely no guarantee that a host has correct DNS records (when was the last time you saw a home user create public DNS records for all their workstations?). And even if you could guarantee that the DNS records are correct, it still doesn't help when there is NAT involved since your DNS lookup (or whatever identifier you use) is going to have to resolve to a globally reachable network address, and no such thing exists when machines are hidden behind a NAT on local scope addresses.
Sorry, I already explained how it would be possible to take things like SRV records and deal hostname resolution through NAT. It's certainly possible to do. Now you are dismissing DNS as not usable. I'm not sure if there's going to be fruitful discussion.
You're not talking about network address translation. You're talking about protocol translation, which is rather different. And also isn't really possible to do in the way you're suggesting. Lets look at the IPv4 to IPv6 migration as an example:
Alice is on IPv6, Bob is on IPv4 (12.34.56.78), Charlie is on IPv6.
So Alice wants to connect to Bob. Since they have different protocols, there will need to be a protocol translation system involved (NAT64). As IPv6 has a larger address space than IPv4, a chunk of that address space can be mapped 1:1 to IPv4 addresses. So Alice takes Bob's IPv4 address and shoves the designated NAT64 prefix on it to turn it into an IPv6 address -::ffff:0:12.34.56.78. Alice sends a packet to that address, the NAT64 box gets the packet and translates it into an IPv4 packet. But Alice's address is IPv6 so can't go in the IPv4 packet so the NAT64 box puts its own IPv4 address on the packet and sends it along to Bob. When Bob sends a reply, it goes back to the NAT64 box, which looks up the IPv6 address associated with the connection (Alice) and is then able to translate the packet back to IPv6 and forward it along. So far so good, and all this really does work in practice and is in common use today - it works pretty well for simple client/server protocols such as HTTP.
Now, Alice needs to tell Bob to send some data to Charlie (pretty common in peer to peer applications). Here's where you hit a problem - there's no way that Charlie's address can be encoded within an IPv4 address. This means that no matter how you pass that addressing information within the protocol, when it is eventually translated back into an IP address to connect to, it is nonsensical - Bob has no idea how to connect to Charlie's IPv6 address. It didn't matter whether you passed an IPv6 address within the application's data stream, or a hostname that Bob's OS resolved to an IPv6 address - either way, Bob can't connect.
I'm sure you could invent a protocol extension whereby Bob can know to connect to the NAT64 box when he sees an IPv6 address and somehow hand the NAT64 box Charlie's address. But that requires Bob to know about IPv6, so it pretty pointless - if you're forcing Bob to implement new protocols like that then you may as well force Bob to upgrade to IPv6 properly.
Another option is that you could invent a protocol so that Alice can tell the NAT64 box to expect a connection from Bob and to forward it to Charlie. But now Alice needs to know lots of information about the NAT64 box's addresses (which you claim is always a bad thing), and more importantly, the NAT64 box could well now be subject to having to forward lots of traffic between two third party networks! That's not satisfactory.
Wow. You are very IP address-centric. Have you ever considered that there are other network types out there?
Try this: Alice wants to talk to Bob. She puts a universal i
Counter-argument: That is essentially "Since I don't need X now, I will design so I will never be able to use X in the future." That's a *big* assumption. I disagree with this. You may believe it, but I do not.
Eh? No it isn't. I don't need NAT now so I'll remove it so it doesn't cause problems. No reason why I can't add it back in the future if I either discover I need it for something or I go completely insane.
You can't add it back in if it's just going to break all the applications that continue to depend on knowing more about the network than they need to.
IP packets are not the application's data, no. But the IP addressing information is often needed so that it knows where to send data to. It doesn't matter whether you handle the IP addresses in the kernel or in the application, *something* needs to know where to send the data. If the destination machine is on the other side of a NAT then you're out of luck - you can't trivially send data to it (there are NAT traversal mechanisms but they aren't reliable for a number of reasons that are beyond the scope of this discussion).
No, *something* is needed so that the other application knows where to send the data to. That identifier does not and should not be a network specific implementation in my opinion.
You've now delved into the realms of redesigning NAT from the ground up - that's a silly discussion to have because the whole issue is that we're stuck with protocols that were not designed to cope with the current situation. If we were designing the internet from scratch with the knowledge we now have, we would have a bigger address space and NAT wouldn't be required... oh wait, that's one of the reasons we're migrating to IPv6.
I don't understand why you seem to want to hold onto NAT - I'm not saying "NAT is evil", on the contrary - it serves some very useful purposes. But when we switch to IPv6, most of that usefulness evaporates. Why would we want to hold onto a layer of complexity that is no longer serving a purpose?
The point is when we switch *from* IPv6.
Let's say this guy call FireFury03 is struck with a brilliant idea and comes up with a new version of IP, IPvFF, that is simply *awesome*. It fixes stuff people never thought about, it ends world hunger, it solves privacy issues, etc. It's simply an amazing step forward!
Except, it's not IPv6 compatible.
Now what?
The point of supporting/having NAT is to allow the network to be modular/segmented, so you aren't stuck waiting for a the last few people on the other side of the world to upgrade to the latest protocol, or having to wait for them to upgrade every one of their applications which depends on having 'IP addresses'. It's so people can run what they want on their networks and still use applications that work across heterogeneous networks. It's so people can experiment with IPv6.1.5 in their LANs and still communicate across the network.
It's so people needing really tight performance could use something with a smaller address space for their LAN to minimize wasted bytes, but still get out when they needed to. It's so we there doesn't have to be a single mono-culture network that can be hamstrung by things like the IANA, ICANN, etc.
Part of the value of the digital age has been that data can be translated from one format to another -- speech to text, text to speech, images to bytes, etc. Searched, edited, copied, etc. Nearly every activity of value involves the ability to transform or migrate data -- and things like DRM which prevent that are a nuisance that degrade value. I want to see the ability to translate between protocols supported because I think the ability to adapt old data/protocols to new forms is very useful and important.
And now we're back to redesigning NAT. Redesigning NAT is fundamentally a waste of time because it is not needed any more. You
NAT has its uses, but it also has its problems. If there is no IP address shortage then *most* (not all) NAT suddenly has no use, leaving nothing but the problems. So in these use cases it makes sense to remove NAT since it is no longer doing anything useful and is a potential source of problems. This is not "demonising", this is simply looking at it in an objective way and realising that things can usually be improved by removing NAT from the equation.
Counter-argument: That is essentially "Since I don't need X now, I will design so I will never be able to use X in the future." That's a *big* assumption. I disagree with this. You may believe it, but I do not.
There is a huge difference here. What you're talking about is encapsulation - this does not modify the packets a user's application is sending, it mearly puts them inside other packets. No information is destroyed - you can always get all the original data out by simply unencapsulating them again. And indeed, this is exactly what happens - an application sends an IP datagram and it arrives at the destination unaltered. The application has no need to care what has happened in the middle because any encapsulation that has happened gets undone again before it gets to the recipient. On the other hand, NAT destroys the original addressing information - what the recipient sees is *not* what the sender sent.
The disagreement is whether or not the recipient needs to know *IP* addressing information. Sending application level data across the network 'encapsulates' the data in an IP packet. IP packets are NOT the application. You may disagree. You may think that IP is, in itself, an application. I do not. I view it as transport, just like any other lower layer in the network.
If you feel that the structure and information of an IP datagram is inherently part of the application data, then the IP network design is a lock-in design because the applications are being written to use IP network information. I feel that applications should be separate from the network. You may disagree.
That is fundamentally not true. The protocols you are talking about (SIP is a common example) were specifically designed to do exactly that. It was not a design flaw, it was intentionally done that way because in a network that has end to end connectivity (which is the type of network SIP was designed to be used in) this actually has some big advantages, such as reduced latency requirements (this was a *really* important criteria for the use cases SIP was designed for), reduced infrastructure and bandwidth requirements (you don't need honking great servers forwarding media between peers).
Anyone interpreting these features as "bad design" is demonstrating a lack of understanding of the design goals for these protocols.
Do not get me started on SIP. I've worked with SIP since 1999. It's really bad.
Please note -- if you are serious about VoIP and SIP, IPv6 sucks. The larger header size per packet can really hurt RTP stream bandwith, because it can make a noticeable (10%+) size increase per RTP packet for voice.
Host names don't help. You can't magically route a packet to a host that is behind a NAT by knowing its hostname.
Actually, people could, but they don't. What it would require would be to take something like SRV records. A server behind NAT would have to inform the NAT device that it is offering service X on port Y for domain Z. The NAT server would have to server up a NAT rule for an outside port A to map to the inside server on port Y. Then it handles DNS requests for domain Z and returns SRV records (or similiar) saying that if you want to reach service X for domain Z, connect to the NAT server on port Y.
This isn't an impossible problem.
Lets be clear on this: applications do *not* break if their IPv4 packets get encapsulated within IPv6 packets for part o
Slashdot Mirror
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 th
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.
I would rather think businesses would want to label whether or not the produce had any 'patented' genetic modifications applied to them. People ought to be able to know whether or not it might not be legal for them to plant any of the seeds in the produce, after all, if they have not bought a license for the intellectual property in question.
(For the irony impaired, the above comment is intended to contain at 20% of the RDA of iron.)
Try this reference:
http://en.wikipedia.org/wiki/Voodoo_death
'Psychosomatic death' is probably related to what you are thinking of.
WTF is a "video ring tone company"?
You need to pay the license fee in order to obtain the proprietary information which compromises the patented answer to that question.
These waste management folks might want to look at the Rosetta Disk project:
http://rosettaproject.org/disk/concept/
It's, you know, a disk meant to store information for a very long time.
Not to sound dismissive of the situation, but I have to be kind of curious -- does anyone have the statistics/numbers for how the increasing number of requests to carriers for subscriber data aligns with the increasing number of people using cellular devices (and that some people now have multiple cellular devices)? It would be useful to to understand if the rate of increase of requests is far in excess of the rate of increase in subscriber growth (and perhaps decrease in land-line usage), mimics it, or is smaller than it. (I am assuming it is exceeding the subscriber growth rate considerably, but it would be nice to have the breakdown.)
The effort and cost of designing such a thing is one aspect. *Verifying* that the actual manufactured item is tamper-proof, accurate, etc. is another. For instance, if you have to secure your entire supply chain to make sure none of the components involved might have been compromised or substituted due to cost cutting (keep in mind that this does not have to be someone trying to skew the vote on purpose, it could be someone being cheap or lazy and producing something prone to errors,) then that aspect can take quite a lot of time and effort.
It's not just designing the box. It's designing the box and the entire process such that not only the box but the process of making the box can be audited through out the life-cycle of the box and its operation. (And there might be some level of who audits the auditors, etc. What happens if a part must be replaced by a different part because of a supply chain problem -- does everything need to be re-certified, etc.)
That's not cheap or simple. It's not the design, it's the process and logistics.
Did folks ever get IPv6 multi-homed routing straightened out?
It always felt like conflicting goals at work -- on one hand, people wanted to simplify and shrink the size of the backbone routing tables, but on the other, a purely hierarchical routing space removes redundancy. That is, a tree graph has the property that there is only *one* path between any two nodes, which means a purely hierarchical routing arrangement would mean that the idea of 'routing around censorship' would go into the waste bin because there are no alternative routes possible. (Note that I am differentiating this from redundant *physical* links -- this is a matter of administrative links. If there is no multi-homing and the upstream provider is blocking/filtering/limiting traffic, there is no network route around it, physical redundancy not withstanding.)
So any current best practices for IPv6 multihoming for small ISPs/businesses?
Out of curiosity, If APIs cannot be copyrighted, does this mean they cannot also be covered by the GPL? This would seem to be a fairly major implication of the Oracle vs. Google case. (Speaking strictly about API definitions/header files.)
It must have been a lively debate internally about this. I am sure many inside the companies were pointing out that by removing the physical media component it would destroy the possibility of game resale and the used game market. However, at the same time it kind of shoots their sales channel in the foot -- there's certainly no incentive for retail game stores or other businesses which make their money on having people come in and buy stuff to sell a device which obsoletes all their current sales and also does not provide for any prospects of future game sales.
So, a motherboard with no RAM and no CPU, in the $100 range, I can see. But with Thunderbolt, too? I know the Thunderbolt cables are a bit pricey because of the chips built into those, but are the Thunderbolt controller chips *that* much cheaper than the cable chips?
I must admit, the first thought that came to my mind when reading this is, this sounds like a great setting for some spy thriller or such. I mean, an abandoned military base with launch silos, its own nuclear power, and slowly being destroyed by encroaching ice?
The perfect location to have the mastermind's base located in. At the end, the heroes have to race out of the base as it is finally being destroyed by the ice.
Just where exactly are these 'test servers' in relation to you? What, exactly, was this 'test'? This seems a bit of a worthless test. It's entirely possible your DSL has less than 100 ms latency, but the delay is on the server end or the links in between. This is too vague a scenario to comment on.
My feelings about 'acceptable' latency depend on how much I am paying for it, at what bandwidth, with what level of SLA, and for what purpose.
In some ways, a lot of what is being added to C++ makes me think of Scala, just less readable.
While the additions and extensions certainly make things more interesting and potentially more powerful/easier for the *individual* programmer, I look forward to seeing what sort of interesting train wrecks happen when larger teams try to make use of these features. I certainly hope the debuggers are being updated to be useful when someone's written a template that uses a #define'd macro to specify a closure that is passed through an anonymous function, etc.
This strikes me as the next generation's 'multi-threading' -- where almost every programmer claims they can handle multi-threaded programming, but very few actually do it well. Particularly in teams when interactions require coordination. Going to take a whole new round of winnowing the wheat from the chaff when it comes to finding developers who can actually use these features well without driving their coworkers insane.
Live with the tedium of doing in manually. It sucks, but unless you are going to have to do this exact operation again in the future, don't bother with automating it. Possibly the solution of taking out the hard drive, putting in a drive dock on another computer, and letting that computer back-up and wipe the drive might be slightly less tedious, depending on the situation.
Because, if you listen to what you are asking, you are trying to set up an automated back-up and erase system. Unless you have a Lot Of Time to Test this BEFORE HAND, you could easily end up with an automated screw-up-the-back-up and nuke-everything system. If you successfully manage to create a system that erases several hundred computers without making usable back-ups, that might be a career-limiting move.
You are asking for replacing a single-shot pistol with a high-powered Gatling gun -- this is not unreasonable. However, if you shoot yourself in the foot with such a thing because you are not careful, there will not be a lot of remains left over.
If all the computers are absolutely identical, you might be able to do an automated system, test it against a couple machines, and be able to get it to work. Otherwise, the amount of time you will spend making sure that the automated system does exactly what you need it to do, safely, without ever failing, may end up being as much time as it takes to do it manually.
Oh, you are verifying that your back-ups are usable before nuking the drives, right?
No, *something* is needed so that the other application knows where to send the data to. That identifier does not and should not be a network specific implementation in my opinion.
Then what do you suggest that identifier is? Can't use DNS because there is absolutely no guarantee that a host has correct DNS records (when was the last time you saw a home user create public DNS records for all their workstations?). And even if you could guarantee that the DNS records are correct, it still doesn't help when there is NAT involved since your DNS lookup (or whatever identifier you use) is going to have to resolve to a globally reachable network address, and no such thing exists when machines are hidden behind a NAT on local scope addresses.
Sorry, I already explained how it would be possible to take things like SRV records and deal hostname resolution through NAT. It's certainly possible to do. Now you are dismissing DNS as not usable. I'm not sure if there's going to be fruitful discussion.
You're not talking about network address translation. You're talking about protocol translation, which is rather different. And also isn't really possible to do in the way you're suggesting. Lets look at the IPv4 to IPv6 migration as an example:
Alice is on IPv6, Bob is on IPv4 (12.34.56.78), Charlie is on IPv6.
So Alice wants to connect to Bob. Since they have different protocols, there will need to be a protocol translation system involved (NAT64). As IPv6 has a larger address space than IPv4, a chunk of that address space can be mapped 1:1 to IPv4 addresses. So Alice takes Bob's IPv4 address and shoves the designated NAT64 prefix on it to turn it into an IPv6 address - ::ffff:0:12.34.56.78. Alice sends a packet to that address, the NAT64 box gets the packet and translates it into an IPv4 packet. But Alice's address is IPv6 so can't go in the IPv4 packet so the NAT64 box puts its own IPv4 address on the packet and sends it along to Bob. When Bob sends a reply, it goes back to the NAT64 box, which looks up the IPv6 address associated with the connection (Alice) and is then able to translate the packet back to IPv6 and forward it along. So far so good, and all this really does work in practice and is in common use today - it works pretty well for simple client/server protocols such as HTTP.
Now, Alice needs to tell Bob to send some data to Charlie (pretty common in peer to peer applications). Here's where you hit a problem - there's no way that Charlie's address can be encoded within an IPv4 address. This means that no matter how you pass that addressing information within the protocol, when it is eventually translated back into an IP address to connect to, it is nonsensical - Bob has no idea how to connect to Charlie's IPv6 address. It didn't matter whether you passed an IPv6 address within the application's data stream, or a hostname that Bob's OS resolved to an IPv6 address - either way, Bob can't connect.
I'm sure you could invent a protocol extension whereby Bob can know to connect to the NAT64 box when he sees an IPv6 address and somehow hand the NAT64 box Charlie's address. But that requires Bob to know about IPv6, so it pretty pointless - if you're forcing Bob to implement new protocols like that then you may as well force Bob to upgrade to IPv6 properly.
Another option is that you could invent a protocol so that Alice can tell the NAT64 box to expect a connection from Bob and to forward it to Charlie. But now Alice needs to know lots of information about the NAT64 box's addresses (which you claim is always a bad thing), and more importantly, the NAT64 box could well now be subject to having to forward lots of traffic between two third party networks! That's not satisfactory.
Wow. You are very IP address-centric. Have you ever considered that there are other network types out there?
Try this:
Alice wants to talk to Bob. She puts a universal i
Counter-argument: That is essentially "Since I don't need X now, I will design so I will never be able to use X in the future." That's a *big* assumption. I disagree with this. You may believe it, but I do not.
Eh? No it isn't. I don't need NAT now so I'll remove it so it doesn't cause problems. No reason why I can't add it back in the future if I either discover I need it for something or I go completely insane.
You can't add it back in if it's just going to break all the applications that continue to depend on knowing more about the network than they need to.
IP packets are not the application's data, no. But the IP addressing information is often needed so that it knows where to send data to. It doesn't matter whether you handle the IP addresses in the kernel or in the application, *something* needs to know where to send the data. If the destination machine is on the other side of a NAT then you're out of luck - you can't trivially send data to it (there are NAT traversal mechanisms but they aren't reliable for a number of reasons that are beyond the scope of this discussion).
No, *something* is needed so that the other application knows where to send the data to. That identifier does not and should not be a network specific implementation in my opinion.
You've now delved into the realms of redesigning NAT from the ground up - that's a silly discussion to have because the whole issue is that we're stuck with protocols that were not designed to cope with the current situation. If we were designing the internet from scratch with the knowledge we now have, we would have a bigger address space and NAT wouldn't be required... oh wait, that's one of the reasons we're migrating to IPv6.
I don't understand why you seem to want to hold onto NAT - I'm not saying "NAT is evil", on the contrary - it serves some very useful purposes. But when we switch to IPv6, most of that usefulness evaporates. Why would we want to hold onto a layer of complexity that is no longer serving a purpose?
The point is when we switch *from* IPv6.
Let's say this guy call FireFury03 is struck with a brilliant idea and comes up with a new version of IP, IPvFF, that is simply *awesome*. It fixes stuff people never thought about, it ends world hunger, it solves privacy issues, etc. It's simply an amazing step forward!
Except, it's not IPv6 compatible.
Now what?
The point of supporting/having NAT is to allow the network to be modular/segmented, so you aren't stuck waiting for a the last few people on the other side of the world to upgrade to the latest protocol, or having to wait for them to upgrade every one of their applications which depends on having 'IP addresses'. It's so people can run what they want on their networks and still use applications that work across heterogeneous networks. It's so people can experiment with IPv6.1.5 in their LANs and still communicate across the network.
It's so people needing really tight performance could use something with a smaller address space for their LAN to minimize wasted bytes, but still get out when they needed to. It's so we there doesn't have to be a single mono-culture network that can be hamstrung by things like the IANA, ICANN, etc.
Part of the value of the digital age has been that data can be translated from one format to another -- speech to text, text to speech, images to bytes, etc. Searched, edited, copied, etc. Nearly every activity of value involves the ability to transform or migrate data -- and things like DRM which prevent that are a nuisance that degrade value. I want to see the ability to translate between protocols supported because I think the ability to adapt old data/protocols to new forms is very useful and important.
And now we're back to redesigning NAT. Redesigning NAT is fundamentally a waste of time because it is not needed any more. You
NAT has its uses, but it also has its problems. If there is no IP address shortage then *most* (not all) NAT suddenly has no use, leaving nothing but the problems. So in these use cases it makes sense to remove NAT since it is no longer doing anything useful and is a potential source of problems. This is not "demonising", this is simply looking at it in an objective way and realising that things can usually be improved by removing NAT from the equation.
Counter-argument: That is essentially "Since I don't need X now, I will design so I will never be able to use X in the future." That's a *big* assumption. I disagree with this. You may believe it, but I do not.
There is a huge difference here. What you're talking about is encapsulation - this does not modify the packets a user's application is sending, it mearly puts them inside other packets. No information is destroyed - you can always get all the original data out by simply unencapsulating them again. And indeed, this is exactly what happens - an application sends an IP datagram and it arrives at the destination unaltered. The application has no need to care what has happened in the middle because any encapsulation that has happened gets undone again before it gets to the recipient. On the other hand, NAT destroys the original addressing information - what the recipient sees is *not* what the sender sent.
The disagreement is whether or not the recipient needs to know *IP* addressing information. Sending application level data across the network 'encapsulates' the data in an IP packet. IP packets are NOT the application. You may disagree. You may think that IP is, in itself, an application. I do not. I view it as transport, just like any other lower layer in the network.
If you feel that the structure and information of an IP datagram is inherently part of the application data, then the IP network design is a lock-in design because the applications are being written to use IP network information. I feel that applications should be separate from the network. You may disagree.
That is fundamentally not true. The protocols you are talking about (SIP is a common example) were specifically designed to do exactly that. It was not a design flaw, it was intentionally done that way because in a network that has end to end connectivity (which is the type of network SIP was designed to be used in) this actually has some big advantages, such as reduced latency requirements (this was a *really* important criteria for the use cases SIP was designed for), reduced infrastructure and bandwidth requirements (you don't need honking great servers forwarding media between peers).
Anyone interpreting these features as "bad design" is demonstrating a lack of understanding of the design goals for these protocols.
Do not get me started on SIP. I've worked with SIP since 1999. It's really bad.
Please note -- if you are serious about VoIP and SIP, IPv6 sucks. The larger header size per packet can really hurt RTP stream bandwith, because it can make a noticeable (10%+) size increase per RTP packet for voice.
Host names don't help. You can't magically route a packet to a host that is behind a NAT by knowing its hostname.
Actually, people could, but they don't. What it would require would be to take something like SRV records. A server behind NAT would have to inform the NAT device that it is offering service X on port Y for domain Z. The NAT server would have to server up a NAT rule for an outside port A to map to the inside server on port Y. Then it handles DNS requests for domain Z and returns SRV records (or similiar) saying that if you want to reach service X for domain Z, connect to the NAT server on port Y.
This isn't an impossible problem.
Lets be clear on this: applications do *not* break if their IPv4 packets get encapsulated within IPv6 packets for part o