There is no-one on the faculty who comes to mind as a specialist in O/S research.
FK and others might not have written a complete OS from interrupt handlers through office suites, but it's utterly absurd to say that they don't qualify as "specialists in OS research". Stop being a typical Slashdotter, admit the error, and move on.
With all of the other fanciful storage media (FMD, anyone), we're talking about tiny start-up companies that are throwing (usually) empty promises out about their newest gizmo because, let's face it, they'll do anything to jack the stock price a little.
Feeling bitter, are you? Which of these vaporous companies did you invest half your life savings in?
The way I figure, someone is out there working on the true next generation of optical storage. Whoever it is, they're not likely to be shy about it, so I doubt it's being kept secret in some big company's lab; it's someone we can find out about. Of those I've seen, my money is still on Constellation 3D and their Fluorescent Multilayer Disc (FMD). Why?
They already have the technology running in a corporate lab and are pushing toward productization. This already sets them apart from the companies whose technology only exists on PowerPoint slides.
They've shown a willingness to partner with the big companies, instead of competing with them, and as a result have signed agreements with companies such as Plasmon and WAMO (Warner Advanced Media, a division of AOL Time Warner). For their parts, the big companies have gotten pretty comfortable with outsourcing R&D like this, and they don't want to kill the goose with the golden eggs.
I don't know whether C3D will succeed long-term or not. Even when you already have the technology in the lab you can still hit stumbling blocks making it ready for the big bad real world (Castlewood is an example of this, in the same industry sector). However, I think it's a little unfair to lump them in with companies that lack either real technology or business sense. They still have a real - though perhaps still small - chance of hitting it big.
Disclaimer: I own a couple thousand shares of C3D stock, but it's not like I work for them or anything. It's not even a significant amount of money for me (the stock is under a buck). I bought the stock because I respect the company, not the other way around.
Re:How to be a successful Information Architect
on
Coder or Architect?
·
· Score: 2
I'll translate a few of these, for those who haven't learned to read before the lines.
Clearly define yearly goals. Make sure they're realistic and qualitative, not quantitative
"It's harder to lie about whether you met a goal when it has numbers attached to it."
Touch every project you know of that's related to your work. No need to get heavily involved
"Drive everyone crazy by constantly pestering people for information and/or making useless suggestions based on superficial understanding of the real problems. Come review time, you can claim you helped everyone, and the damage you've inflicted on their schedules will make you look good by comparison."
Write quarterly reports. Trump up any work you've done on popular projects, keep work on politically sensitive projects to a few lines.
"Take credit, avoid blame."
Request at least two weeks of training a year...Request to go to at least two conferences per year
"Spend as much time as possible away from the office so that the people doing real work can't hunt you down and give you that well-deserved kick in the teeth."
if you need some ideas on training and seminars...just go here
Get used to the idea that as an architect you will no longer be able to measure your productivity in terms of lines of code or any similar "objective" measure. When I first started getting more involved in architect-level activities, I saw that my productivity as a coder was declining and I was quite distraught. It took me a long time to reconcile myself to the idea that code was no longer my main contribution, and that I had to find more flexible ways to determine whether I was functioning optimally. This is also a time-management problem, as you become less able to use checkin trails etc. to keep yourself on schedule.
Accept that you cannot escape your responsibility to be a leader, mentor, etc. Think of yourself as a high-level NCO on the battlefield. You're not an officer making command decisions and you're not some paper-pusher who never picked up a gun; those are the executives and managers respectively. Instead, you're in the foxholes with the grunts, fighting the same war they are. Your leadership consists of communicating basic skills and priorities, managing morale and discipline, acting as an advocate, and generally setting a good example. If you're not comfortable doing all of these things, find a different role, perhaps one that concentrates more on specialized technical skills, because nobody is more universally loathed - by superiors, peers, and more junior team members - than a tech lead or architect who doesn't help to "stiffen the backbone" of the organization.
In a similar vein, your new position makes you a target for the climbers and backstabbers in your company. Everything you say will travel further and carry more weight than it did before, with potentially disastrous consequences if you're not careful. A grunt can say almost anything because, basically, nobody will really notice or care. When you're an architect that's not the case. I know it seems political, but it pays to develop "situational awareness" of who you're talking to, what their agendas are, who they're likely to repeat your words to, etc. It's distasteful, but if you want your people or your projects or your principles to prevail then you have to avoid traps and ambushes.
Once you've caught up to MS Office, where are they going to go? Add an AI to write your papers?
The only way that they'd have nowhere to go would be if they have already achieved the pinnacle of office-suite (not just word-processor) functionality, and I don't quite believe that's the case. Here are some fairly random ideas that we could use to start:
Add automatic translation.
Integrate with FrontPage to provide a UserLand-like web content management system.
Turn the current wimpy groupware stuff into full Groove-style collaborative workspaces.
Add deep statistical analysis and cutting-edge 3D data visualization to Excel.
Break out of the "text on a page" metaphor to allow creation of complete integrated presentations comparable to TV programs - text, graphics, computer animation, full-motion video, natural-sounding synthesized speech.
Provide hooks for WebDAV, backup systems, secure document storage, knowledge management,...
Maybe some of those ideas are just totally stupid, but at the same time others could lead to another leap ahead of would-be competitors. I'm sure other people, including those at MS, could think of more. This well is far from tapped out. My point remains that if MS actually perceived a threat they could do something about it...but there's no reason for them to bother yet.
Sure, for example, we don't have an Office killer *currently*,
...and they've been trying for years. Linux attempts to compete with Office have so far not given Microsoft any reason to take them seriously, but if the Linux apps ever did become a serious threat you shouldn't think for a moment that MS will continue to stand still (as I feel they've been doing since at least Office 97). Remember Netscape? MS is perfectly capable of ignoring something for a long time, then suddenly turning their massive firepower on it when they feel the time is ripe to do so. They just haven't felt that the so-called Linux alternatives to Word, Excel, etc. have been worth wasting bullets on...yet.
User starts Word. As the application is loading and initializing and as the user is working
This has been tried, and doesn't actually work as well as you might think. The problem is that all of that prefetching fills the cache with unneeded blocks, to make room for which you had to evict other blocks that you actually might have had a use for. It's really the same problem that the VM system has right now in deciding which blocks to keep and which to throw away, except that when you try to do it at the drive end you have even less information to work with when making these decisions.
The only case where this seems to work is when your available RAM exceeds your total (extended) working set, but at that point you're deriving such tiny marginal value from each additional block's worth of RAM that it's not even worth the low price you paid for that RAM. The principle of a "sweet spot" still applies.
Re:He SHOULD care about the competition...
on
Torvalds Tells All
·
· Score: 2
He certainly has looked at other OSes for ideas on how to do complex things (thread scheduling, FS journalling, memory management)
I suggest that you go back and research both the degree to which Linus was personally involved in those projects and the degree to which their actual leaders made good use of existing knowledge from other systems. To make a long story short, those examples don't demonstrate your point very well.
and is even willing to borrow whole filesystems if they are worthwhile
Remember, "porting X" is not the same as "learning from X".
Re:He SHOULD care about the competition...
on
Torvalds Tells All
·
· Score: 2
I was about to post something very similar. The juxtaposition of "I don't follow..." and "I don't see..." is classic Linus; of course he doesn't see much that's very interesting if he doesn't even look. Even if the goal is to "make Linux better than itself, not others" as Linus claims, it pays to learn from others' mistakes as they have attempted similar things. The "Not Invented Here" syndrome exemplified by Linus and too many of the other main Linux developers has always bugged the hell out of me.
In the end, it's not really about competition at all, it's about making the best use of available knowledge for one's own purposes. It's too bad that so many of the people responding to you focused on the competitive aspect of your comments and totally missed the more important point.
A disk array with a big front-end RAM cache effectively gives you RAM-like access speeds for cache hits. You can basically adjust the amount of cache to get as close as you want to RAM speed overall for your workload, while also taking advantage of rotating media's price and durability advantages. Ideally, either the cache is either battery backed or the array has enough of an internal power reserve to dump cache to disk even when external power is lost. This use of a large but safe RAM cache is the main thing that differentiates a Symmetrix or a Shark or a Lightning from some low-end POS that's really no more than a stack of disks with a plain old PC bolted on the front...and don't even get me started on the abomination that is host-based RAID.
FWIW, I have two of these things - one at work and one at home - for my company-issued Armada M300. I leave both plugged in all the time, and they're barely even lukewarm. The bottom of the laptop itself can get pretty damn hot if I'm doing something CPU-intensive like playing games, but the AC units have never given me any cause to worry.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
This does not affect the order of the problem. It just affects the proportionality constant when translating O(sqrt(N)) into an actual hard number.
That's only true if we assume a rectilinear grid, which I've already shown is ridiculous. For other topologies, you are - yet again - incorrect.
A node, in my previous post, is a *group* of cell phones.
In your feeble mind, you mean. I just checked your previous post - cid #2389118 - and you offer no such definition of "node". It's an absurd definition anyway, which any reasonable person would reject.
You want a more rigorous illustration of why you get congestion? Fine:...
That's no more rigorous than before. It's the same example and analysis that I already showed to be flawed, just worded a little differently. You get another "-1, Redundant" for that, kiddo.
Now do you see where I'm coming from?
Nope. Which planet would that be, again? What color are the skies there?
It doesn't matter, though. I don't care where you're coming from, but I know where you're going - my mental killfile. I give up; your resistance to reason is greater than my ability to explain what should be obvious.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
You are making flawed assumptions about the nature of the network.
Nope. You're the one making invalid assumptions, specifically:
You assume that low range equates to low connectivity.
You assume that nodes are arranged into a grid instead of a generalized mesh.
You assume that everyone's relying entirely on routing between mobile nodes, all the time, even when there are more powerful fixed facilities available.
These assumptions all combine to paint a much uglier than necessary picture, as we'll see. To deal with the most obviously stupid assumption first, consider that connectivity is actually a product of range and node density. Sure, you won't find many neighbor nodes if you have a hundred devices spread across the entire state of Montana. However, if you have several hundred thousand units within the confines of New York City - our original example - you're likely to find hundreds of potential neighbor nodes even if your range is quite small.
This brings us to the grid assumption. You're assuming that nodes are incapable of "skipping" a row or column in your unnecessarily-rectilinear grid, but in reality that's not likely to be the case. If I have a couple of hundred potential neighbors, I'd have to be an idiot to route everything only through the ten nearest; that forces me to take "baby steps" even when traversing long distances. Obviously I should send directly to anyone within range, routing be damned. Less obviously, when I need to communicate with someone who's out of range the logical neighbor to route through would be one relatively far from myself (but still with a stable signal). If you envision your network as a 1000x1000 grid, it's as though each hop can cross 10 rows and/or columns at a time. Even better, a couple of wise guys can create a "wormhole" between the middle of the upper-left quadrant and the middle of the lower-right using fixed access points and high-gain directional antennas. The grid concept starts to break down pretty quickly once you actually start to think about it; when you start making more realistic assumptions about topology and routing, the actual hops per message - congruent to traffic per node - doesn't even approach the figures predicted by your severely flawed theory.
Lastly, let's consider the assumption that you'd always be routing exclusively through other mobile nodes? Why? In any realistic deployment of such a system, there would be a huge variety of both fixed and mobile nodes, representing a vast diversity of capabilities. I'd have to be an idiot to route through a dozen other people's mobile phones when I'm standing right next to a functioning fixed access point. In reality, the "pure peer-to-peer" routing would only be a fallback, in case someone managed to achieve the nearly impossible task of knocking out every one of thousands of fixed home/office access points in the city. In normal operation, the real routing problem consists of how to route to the nearest "non-peer" - i.e. node with superior capabilities, so the idea of a million-node network composed entirely of celphones really doesn't apply. In reality, the size of any network fragment consisting only of celphones is likely to be from a few dozen to a couple of hundred nodes.
It should be clear by now, at least to any objective third party, how ridiculous your grid example/analysis really is. I may not be a network god, but that's hardly necessary to poke gaping holes in the network-slug arguments you've been making.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
I was pointing out that even with perfectly balanced, zero-overhead routing, this system doesn't scale well
Bullshit. Let me refresh your memory regarding the much broader claims you actually made:
Even if almost all of the messages being routed are to phones in the same city, the density of messages at each relay node will be large (total traffic is proportional to the number of nodes talking, and for an even distribution, traffic per node is proportional to the square root of this).
Wrong. Traffic per node in an N-node network is proportional to log(N) - the log base being the average connectivity - not sqrt(N). For a million-node network with average connectivity of four, that's the difference between your figure of 1000 and a correct figure of 10.
I'll let someone with more network expertise than I have describe how nasty things get when your phone can only fit a small routing...
...and then when just such a person does provide just such an explanation, showing why a conclusion different than your admittedly-uninformed one is warranted, you claim that they missed your point. Asshole.
Re:Scaling problems. Very nasty scaling problems.
on
Peer-to-Peer Cellular
·
· Score: 2
...I think that the authours of the article are overlooking a significant problem...
*sigh* -1, Redundant
Exactly the same point was already raised...and answered.
In order for peer to peer mode to work...your phone needs a routing table, and possibly a very large one.
No, it doesn't. Rather than try to explain why not, I suggest you read Ad Hoc Networking by Charles Perkins (editor) or the papers and references from the IETF MANET working group, or some of the stuff from CMU or Cornell. In short, an end-node usually only needs to know about its immediate neighbors, plus a modest amount of information regarding location (either physical or abstract).
Not to mention that all the possible routes need to be sent to every phone.
Absolutely not.
if you send your message to somebody's cell phone, who then leaves the...the message disappears
Wrong again. Both end-to-end and in-network retransmission and acknowledgement can be used to prevent such loss even in the face of multiple failures. That's just basic networking, not even specific to mobile networks.
The problems you mention are real, but don't assume that solutions do not or cannot exist just because you weren't able to see them after a few minutes' worth of independent thought. Some pretty bright people have been working on them for twenty years or more, not without success, and before you assume "it won't work" you owe it to yourself to find out whether you've been proven wrong already.
Same here. However, the AC does have a point. Starting your post with "the userbase having no experience with the subject" and ending it with "better include a CCIE number" is going to piss a lot of people off. The people who design Cisco boxes and the protocols they use probably don't have formal CCIE credentials either; should we not listen to them? The CCIE program is actually very good as such things go, but at the end one is merely competent with regard to administering a particular implementation of the technology. Knowing which switches to flip isn't the same as knowing how the technology actually works or how it might be improved.
That said, I think targeting mdouglas was somewhat unfair. Despite his unfortunate choice of opening and closing remarks, his article was quite informative and technically correct. On this very thread there have been others - e.g. darkonc, cotu - more guilty of the crimes laid at mdouglas's doorstep.
it's also dropping other packets. This is considered bad. This is considered bad.
It's unfortunate that your talent for stating the obvious is not matched by your ability to understand the less obvious.
Under normal circumstances, 'flapping' your route for a short period (the document indicates that BGP has a 30 second minumum) will cause some of those packets to take the 'back' route, and will (hopefully) cause enough of a strain relief on the overloaded router for it to catch up to the (normally transient) overload.
Flapping is undesirable. Period. Any routing protocol that didn't support load balancing across routes, without explicit route changes to flap back and forth, would be laughed out of the standards bodies. Fortunately, BGP is not in fact so poorly designed as you seem to think.
Giving a higher than normal priority to BGP packets...would also break the inherent load-limiting effect of flapping, and generally break the network worse under normal ovarload conditions.
Now you're just totally talking out your ass. Flapping is not an intentional method of limiting load; it's a pathological behavior that routing protocols including BGP try to avoid. "Normal overload" is of course an oxymoron, and even in more common (but still abnormal) overload conditions there's no reason whatsoever to suppose that the incredibly minimal CPU overhead associated with giving BGP a higher priority would have the effect you suggest.
I just don't know where you get that kind of crap from. That kind of buzzword-laden but unconnected-to-reality BS might have dazzled some fresh-out MBAs back at the height of dot-com mania, but don't expect anyone with even a minimal amount of technical knowledge to be fooled.
P.S. Either your web site is down, or your profile contains a broken link. Nice going either way.
I think you missed the point of what I was saying. The problem that the original article talked about was BGP traffic getting dropped due to load. If that's happening, you can't add routes, you can't modify routes, you can't withdraw routes. What I was talking about was using existing facilities that allow you to prioritize traffic by type to ensure that the BGP packets get through even if nothing else does. Once you've done that, you can manipulate routes however you want to adapt to conditions.
What's happening now is like allowing emergency vehicles to get stranded in traffic because they don't have lights and sirens. I say give them lights and sirens, let them zip past the regular traffic so they can do something about the conditions that led to the traffic jam.
These same high-end routers often have traffic shaping/prioritization features. You'd think that they could be configured so that the routing-protocol packets have a very high priority so that they're among the last to be dropped even at high load. If not, someone screwed up.
Designing for the largest possible audience is important, but that point really is not relevant to what we were discussing. I was addressing a specific technical issue: scalability of mobile or other client-based code as a vehicle for complex presentation, compared to the server-centric approach you suggested. In that context, the current situation is a mere historical artifact, inseparably tied to the newness of the technology and this week's performance parameters. It's extremely easy to imagine a world in which support for some form of mobile code is universal. It's also extremely easy to imagine a world in which even the most compact client can be assumed to have enough computational power to perform presentation tasks...not the whole application, just the presentation. In that world it would make absolutely no sense to load the server with presentation-related tasks, or the network with the associated extra traffic. That would be seen, rightly, as a stupid design.
I would further say that the world I describe is not a distant one. It's practically upon us. If you were talking about deploying an application this week maybe your comments would have some merit, but in a general conversation that encompasses even something as close as next year your server-centric bias starts to seem rather pathological. None of the reasons you give for preferring server-side code really stand up to scrutiny; client-side code is going to become a more and more necessary part of serious distributed-application design whether you personally like it or not.
If you're running in non-overcommit mode, without an emergency reserve, and your important program has piss-poor error handling...whose fault is that? The VM-system designer's? Hardly.
Slashdot Mirror
Look at the original statement you made:
FK and others might not have written a complete OS from interrupt handlers through office suites, but it's utterly absurd to say that they don't qualify as "specialists in OS research". Stop being a typical Slashdotter, admit the error, and move on.
Frans Kaashoek might be pretty annoyed to hear you say that.
Feeling bitter, are you? Which of these vaporous companies did you invest half your life savings in?
The way I figure, someone is out there working on the true next generation of optical storage. Whoever it is, they're not likely to be shy about it, so I doubt it's being kept secret in some big company's lab; it's someone we can find out about. Of those I've seen, my money is still on Constellation 3D and their Fluorescent Multilayer Disc (FMD). Why?
I don't know whether C3D will succeed long-term or not. Even when you already have the technology in the lab you can still hit stumbling blocks making it ready for the big bad real world (Castlewood is an example of this, in the same industry sector). However, I think it's a little unfair to lump them in with companies that lack either real technology or business sense. They still have a real - though perhaps still small - chance of hitting it big.
Disclaimer: I own a couple thousand shares of C3D stock, but it's not like I work for them or anything. It's not even a significant amount of money for me (the stock is under a buck). I bought the stock because I respect the company, not the other way around.
I'll translate a few of these, for those who haven't learned to read before the lines.
"It's harder to lie about whether you met a goal when it has numbers attached to it."
"Drive everyone crazy by constantly pestering people for information and/or making useless suggestions based on superficial understanding of the real problems. Come review time, you can claim you helped everyone, and the damage you've inflicted on their schedules will make you look good by comparison."
"Take credit, avoid blame."
"Spend as much time as possible away from the office so that the people doing real work can't hunt you down and give you that well-deserved kick in the teeth."
"I have a financial arrangement with these guys."
Get used to the idea that as an architect you will no longer be able to measure your productivity in terms of lines of code or any similar "objective" measure. When I first started getting more involved in architect-level activities, I saw that my productivity as a coder was declining and I was quite distraught. It took me a long time to reconcile myself to the idea that code was no longer my main contribution, and that I had to find more flexible ways to determine whether I was functioning optimally. This is also a time-management problem, as you become less able to use checkin trails etc. to keep yourself on schedule.
Accept that you cannot escape your responsibility to be a leader, mentor, etc. Think of yourself as a high-level NCO on the battlefield. You're not an officer making command decisions and you're not some paper-pusher who never picked up a gun; those are the executives and managers respectively. Instead, you're in the foxholes with the grunts, fighting the same war they are. Your leadership consists of communicating basic skills and priorities, managing morale and discipline, acting as an advocate, and generally setting a good example. If you're not comfortable doing all of these things, find a different role, perhaps one that concentrates more on specialized technical skills, because nobody is more universally loathed - by superiors, peers, and more junior team members - than a tech lead or architect who doesn't help to "stiffen the backbone" of the organization.
In a similar vein, your new position makes you a target for the climbers and backstabbers in your company. Everything you say will travel further and carry more weight than it did before, with potentially disastrous consequences if you're not careful. A grunt can say almost anything because, basically, nobody will really notice or care. When you're an architect that's not the case. I know it seems political, but it pays to develop "situational awareness" of who you're talking to, what their agendas are, who they're likely to repeat your words to, etc. It's distasteful, but if you want your people or your projects or your principles to prevail then you have to avoid traps and ambushes.
The only way that they'd have nowhere to go would be if they have already achieved the pinnacle of office-suite (not just word-processor) functionality, and I don't quite believe that's the case. Here are some fairly random ideas that we could use to start:
Maybe some of those ideas are just totally stupid, but at the same time others could lead to another leap ahead of would-be competitors. I'm sure other people, including those at MS, could think of more. This well is far from tapped out. My point remains that if MS actually perceived a threat they could do something about it...but there's no reason for them to bother yet.
...and they've been trying for years. Linux attempts to compete with Office have so far not given Microsoft any reason to take them seriously, but if the Linux apps ever did become a serious threat you shouldn't think for a moment that MS will continue to stand still (as I feel they've been doing since at least Office 97). Remember Netscape? MS is perfectly capable of ignoring something for a long time, then suddenly turning their massive firepower on it when they feel the time is ripe to do so. They just haven't felt that the so-called Linux alternatives to Word, Excel, etc. have been worth wasting bullets on...yet.
How fast do you think they'd find themselves black-holed if they tried this? One minute, or two?
This has been tried, and doesn't actually work as well as you might think. The problem is that all of that prefetching fills the cache with unneeded blocks, to make room for which you had to evict other blocks that you actually might have had a use for. It's really the same problem that the VM system has right now in deciding which blocks to keep and which to throw away, except that when you try to do it at the drive end you have even less information to work with when making these decisions.
The only case where this seems to work is when your available RAM exceeds your total (extended) working set, but at that point you're deriving such tiny marginal value from each additional block's worth of RAM that it's not even worth the low price you paid for that RAM. The principle of a "sweet spot" still applies.
I suggest that you go back and research both the degree to which Linus was personally involved in those projects and the degree to which their actual leaders made good use of existing knowledge from other systems. To make a long story short, those examples don't demonstrate your point very well.
Remember, "porting X" is not the same as "learning from X".
I was about to post something very similar. The juxtaposition of "I don't follow..." and "I don't see..." is classic Linus; of course he doesn't see much that's very interesting if he doesn't even look. Even if the goal is to "make Linux better than itself, not others" as Linus claims, it pays to learn from others' mistakes as they have attempted similar things. The "Not Invented Here" syndrome exemplified by Linus and too many of the other main Linux developers has always bugged the hell out of me.
In the end, it's not really about competition at all, it's about making the best use of available knowledge for one's own purposes. It's too bad that so many of the people responding to you focused on the competitive aspect of your comments and totally missed the more important point.
A disk array with a big front-end RAM cache effectively gives you RAM-like access speeds for cache hits. You can basically adjust the amount of cache to get as close as you want to RAM speed overall for your workload, while also taking advantage of rotating media's price and durability advantages. Ideally, either the cache is either battery backed or the array has enough of an internal power reserve to dump cache to disk even when external power is lost. This use of a large but safe RAM cache is the main thing that differentiates a Symmetrix or a Shark or a Lightning from some low-end POS that's really no more than a stack of disks with a plain old PC bolted on the front...and don't even get me started on the abomination that is host-based RAID.
FWIW, I have two of these things - one at work and one at home - for my company-issued Armada M300. I leave both plugged in all the time, and they're barely even lukewarm. The bottom of the laptop itself can get pretty damn hot if I'm doing something CPU-intensive like playing games, but the AC units have never given me any cause to worry.
That's only true if we assume a rectilinear grid, which I've already shown is ridiculous. For other topologies, you are - yet again - incorrect.
In your feeble mind, you mean. I just checked your previous post - cid #2389118 - and you offer no such definition of "node". It's an absurd definition anyway, which any reasonable person would reject.
That's no more rigorous than before. It's the same example and analysis that I already showed to be flawed, just worded a little differently. You get another "-1, Redundant" for that, kiddo.
Nope. Which planet would that be, again? What color are the skies there?
It doesn't matter, though. I don't care where you're coming from, but I know where you're going - my mental killfile. I give up; your resistance to reason is greater than my ability to explain what should be obvious.
Nope. You're the one making invalid assumptions, specifically:
These assumptions all combine to paint a much uglier than necessary picture, as we'll see. To deal with the most obviously stupid assumption first, consider that connectivity is actually a product of range and node density. Sure, you won't find many neighbor nodes if you have a hundred devices spread across the entire state of Montana. However, if you have several hundred thousand units within the confines of New York City - our original example - you're likely to find hundreds of potential neighbor nodes even if your range is quite small.
This brings us to the grid assumption. You're assuming that nodes are incapable of "skipping" a row or column in your unnecessarily-rectilinear grid, but in reality that's not likely to be the case. If I have a couple of hundred potential neighbors, I'd have to be an idiot to route everything only through the ten nearest; that forces me to take "baby steps" even when traversing long distances. Obviously I should send directly to anyone within range, routing be damned. Less obviously, when I need to communicate with someone who's out of range the logical neighbor to route through would be one relatively far from myself (but still with a stable signal). If you envision your network as a 1000x1000 grid, it's as though each hop can cross 10 rows and/or columns at a time. Even better, a couple of wise guys can create a "wormhole" between the middle of the upper-left quadrant and the middle of the lower-right using fixed access points and high-gain directional antennas. The grid concept starts to break down pretty quickly once you actually start to think about it; when you start making more realistic assumptions about topology and routing, the actual hops per message - congruent to traffic per node - doesn't even approach the figures predicted by your severely flawed theory.
Lastly, let's consider the assumption that you'd always be routing exclusively through other mobile nodes? Why? In any realistic deployment of such a system, there would be a huge variety of both fixed and mobile nodes, representing a vast diversity of capabilities. I'd have to be an idiot to route through a dozen other people's mobile phones when I'm standing right next to a functioning fixed access point. In reality, the "pure peer-to-peer" routing would only be a fallback, in case someone managed to achieve the nearly impossible task of knocking out every one of thousands of fixed home/office access points in the city. In normal operation, the real routing problem consists of how to route to the nearest "non-peer" - i.e. node with superior capabilities, so the idea of a million-node network composed entirely of celphones really doesn't apply. In reality, the size of any network fragment consisting only of celphones is likely to be from a few dozen to a couple of hundred nodes.
It should be clear by now, at least to any objective third party, how ridiculous your grid example/analysis really is. I may not be a network god, but that's hardly necessary to poke gaping holes in the network-slug arguments you've been making.
Bullshit. Let me refresh your memory regarding the much broader claims you actually made:
Wrong. Traffic per node in an N-node network is proportional to log(N) - the log base being the average connectivity - not sqrt(N). For a million-node network with average connectivity of four, that's the difference between your figure of 1000 and a correct figure of 10.
...and then when just such a person does provide just such an explanation, showing why a conclusion different than your admittedly-uninformed one is warranted, you claim that they missed your point. Asshole.
*sigh* -1, Redundant
Exactly the same point was already raised...and answered.
No, it doesn't. Rather than try to explain why not, I suggest you read Ad Hoc Networking by Charles Perkins (editor) or the papers and references from the IETF MANET working group, or some of the stuff from CMU or Cornell. In short, an end-node usually only needs to know about its immediate neighbors, plus a modest amount of information regarding location (either physical or abstract).
Absolutely not.
Wrong again. Both end-to-end and in-network retransmission and acknowledgement can be used to prevent such loss even in the face of multiple failures. That's just basic networking, not even specific to mobile networks.
The problems you mention are real, but don't assume that solutions do not or cannot exist just because you weren't able to see them after a few minutes' worth of independent thought. Some pretty bright people have been working on them for twenty years or more, not without success, and before you assume "it won't work" you owe it to yourself to find out whether you've been proven wrong already.
Ad Hoc Networking, by Charles Perkins (editor)
Ad Hoc Mobile Wireless Networks: Protocols and Systems, by C.-K. Toh (not yet published)
Same here. However, the AC does have a point. Starting your post with "the userbase having no experience with the subject" and ending it with "better include a CCIE number" is going to piss a lot of people off. The people who design Cisco boxes and the protocols they use probably don't have formal CCIE credentials either; should we not listen to them? The CCIE program is actually very good as such things go, but at the end one is merely competent with regard to administering a particular implementation of the technology. Knowing which switches to flip isn't the same as knowing how the technology actually works or how it might be improved.
That said, I think targeting mdouglas was somewhat unfair. Despite his unfortunate choice of opening and closing remarks, his article was quite informative and technically correct. On this very thread there have been others - e.g. darkonc, cotu - more guilty of the crimes laid at mdouglas's doorstep.
It's unfortunate that your talent for stating the obvious is not matched by your ability to understand the less obvious.
Flapping is undesirable. Period. Any routing protocol that didn't support load balancing across routes, without explicit route changes to flap back and forth, would be laughed out of the standards bodies. Fortunately, BGP is not in fact so poorly designed as you seem to think.
Now you're just totally talking out your ass. Flapping is not an intentional method of limiting load; it's a pathological behavior that routing protocols including BGP try to avoid. "Normal overload" is of course an oxymoron, and even in more common (but still abnormal) overload conditions there's no reason whatsoever to suppose that the incredibly minimal CPU overhead associated with giving BGP a higher priority would have the effect you suggest.
I just don't know where you get that kind of crap from. That kind of buzzword-laden but unconnected-to-reality BS might have dazzled some fresh-out MBAs back at the height of dot-com mania, but don't expect anyone with even a minimal amount of technical knowledge to be fooled.
P.S. Either your web site is down, or your profile contains a broken link. Nice going either way.
I think you missed the point of what I was saying. The problem that the original article talked about was BGP traffic getting dropped due to load. If that's happening, you can't add routes, you can't modify routes, you can't withdraw routes. What I was talking about was using existing facilities that allow you to prioritize traffic by type to ensure that the BGP packets get through even if nothing else does. Once you've done that, you can manipulate routes however you want to adapt to conditions.
What's happening now is like allowing emergency vehicles to get stranded in traffic because they don't have lights and sirens. I say give them lights and sirens, let them zip past the regular traffic so they can do something about the conditions that led to the traffic jam.
These same high-end routers often have traffic shaping/prioritization features. You'd think that they could be configured so that the routing-protocol packets have a very high priority so that they're among the last to be dropped even at high load. If not, someone screwed up.
Designing for the largest possible audience is important, but that point really is not relevant to what we were discussing. I was addressing a specific technical issue: scalability of mobile or other client-based code as a vehicle for complex presentation, compared to the server-centric approach you suggested. In that context, the current situation is a mere historical artifact, inseparably tied to the newness of the technology and this week's performance parameters. It's extremely easy to imagine a world in which support for some form of mobile code is universal. It's also extremely easy to imagine a world in which even the most compact client can be assumed to have enough computational power to perform presentation tasks...not the whole application, just the presentation. In that world it would make absolutely no sense to load the server with presentation-related tasks, or the network with the associated extra traffic. That would be seen, rightly, as a stupid design.
I would further say that the world I describe is not a distant one. It's practically upon us. If you were talking about deploying an application this week maybe your comments would have some merit, but in a general conversation that encompasses even something as close as next year your server-centric bias starts to seem rather pathological. None of the reasons you give for preferring server-side code really stand up to scrutiny; client-side code is going to become a more and more necessary part of serious distributed-application design whether you personally like it or not.
If you're running in non-overcommit mode, without an emergency reserve, and your important program has piss-poor error handling...whose fault is that? The VM-system designer's? Hardly.