It's very common practice to have a Visio document with all of your nodes on it, geologically or topologically seperated on different pages within the document, and seperate Visio documents detailing specific layers.
It's not the best way to do it, but it's very common.
Visio is great for network diagrams. Unless you have 1000+ nodes with new ones added every day. For network diagrams, you really need something where the diagram is plotted from the data, not where the data is plotted onto the diagram.
I have to say that I find it amusing that this "think tank" arrives at the conclusion that a de facto homogeneous computing environment is slowing down technical innovation.
God knows things would go a lot slower if you had to develop your software for ten different platforms to be able to gain wide market penetration.
Where exactly do you have that definition from? My dictionaries simply define it as the act of dishonestly taking something that does not belong to you, and keeping it. Nothing about "carrying away". It's not like you can't steal an item without moving away from the scene of the crime.
Oh I'm not confused about the quality of the education or the students. It's the self-perception that I'm going from, since that's what I guess would dictate their behaviour.
You're actually saying that consistently hitting the last line of defence to try to clean up the mess that the lawmakers make is proof that the method of government works?
What this proves is that the system is completely messed up, and that the failsafes that are meant to prevent a total meltdown worked this time around. You really call that a working system?
What amazes me is that 47 lawmakers can unanimously pass a blatantly unconstitutional bill. When the courts have to fix what that many politicians unanimously messed up, it's obvious and undeniable proof that the current method of government just does not work.
What product are you specifically referring to here? This is an entire market, not a single product.
It takes years and millions of dollars to make top quality games. That's a well-established fact. Of course games wouldn't stop being produced. There are lots of games produced today that are completely free to use, with completely open code, which would continue to be produced. The thing is, these games are rarely all that good, and certainly don't often have mass appeal, so yes, the quality would most certainly drop.
Why? Because money gets things done. Snap back into the real world.
"The lack of an open source Opera is exactly what keeps Opera so low in the browser popularity charts."
.. what? How? Where is your supporting evidence of such an absolutely outrageous claim? How can you keep a straight face while claiming that closed source code can't turn a profit? Do you have -any- financial insight into how Opera operates? All Opera seems to do is go forward. Mobile devices, Wii, PC, they aren't losing market share anywhere.
Your personal ideals don't really reflect how the real world operates.
Or perhaps it could be that I simply did not find it likely that you could honestly think that implementing a feature that is described in detail as a completely viable implementation in the RFC, regardless of merit, is somehow not complying with the standard. But than you for making it clear that you apparently do.
As long as there is a case where a client SHOULD set this broadcast bit, the server MUST accept it. It is as simple as that. If the server doesn't accept it, regardless of whether or not it is in fact needed by the client, it constitutes a lack of standards compliance on the part of the server. There is nothing more to it.
I find it absolutely hilarious that you blame Microsoft for making a -completely- viable implementation of DHCP, and claim that servers would need to "go against the RFC" to be compliant with.. the RFC. You're in very, very deep here, grasping at seaweed.
I work for an ISP, and 70% of the time our first line support desk spends talking to customers is spent doing release/renews or repairs on connections. Stuff that has absolutely nothing to do with us, but stuff that we spend time and money on anyway to keep customers happy.
If these people refuse to help their customers on principle, how are they worth anything?
Our other DHCP servers work fine with Vista. Only the ISC DHCPd doesn't play well with it. How would the other servers know how to support this bit, if not from the published standard?
Perhaps they aren't conservative in what they send, but if the ISC DHCPd was any better at being liberal in what they accept, this problem wouldn't exist, so they're both to blame in that respect.
Microsoft don't need to justify their decision to set the bit to what it's set to. One bit that is within standards is certainly not a "huge" fuckup, and since it appears to be supported fine by other DHCP servers, one can only assume that it's a lacking implementation on the part of ISC.
That's part of the RFC definition of "SHOULD". I am well aware of what it means, as I have told you before. Again, I am looking for where this definition is applied. Is it really that difficult to grasp?
Could you perhaps point out where this warning is?
Is it not the responsibility of the server to accomodate clients? As such, is it not the fault of the server for lacking support for an optional client implementation?
"SHOULD" is a recommendation. A recommendation is by logical necessity optional, and relies on the server to follow the standard. A server exists to accomodate clients. Who isn't accepting the bit?
You're making this out to be a Microsoft against the world situation. Our Cisco DHCP server worked fine with Vista, no problems at all. Only when we switched to an ISC DHCP server did we start having problems. In fact, the only DHCP servers I've seen so far having trouble playing nice with Vista have been ISC DHCP servers.
This is a failure on the part of ISC to make their DHCP server standards compliant, regardless of how esoteric you find the Vista client implementation.
As for Microsoft announcing the problems to be with non-Microsoft products - Wow. A corporation denying responsibility for issues it isn't responsible for, and using the failures of competitors to promote their own software. What's next?
That's funny - Our Cisco DHCPd worked fine with Vista, but DHCP3 is choking.
I believe the spirit of RFCs is something like "Be liberal with what you can receive, and conservative with what you send out.", or something to that effect. Vista is adhering to the RFC. The worst you can throw at it is not adhering to the spirit of RFCs, but the problem only exists because the server software, if adhering to the RFC at all, doesn't adhere to the spirit of it, either.
Personally, I'd say that when standards compliant, the burden is on servers to accomodate client implementatins, not clients to accomodate server implementations.
Slashdot Mirror
It's a beta, not a final product.
Is it that challenging to comprehend?
It's very common practice to have a Visio document with all of your nodes on it, geologically or topologically seperated on different pages within the document, and seperate Visio documents detailing specific layers.
It's not the best way to do it, but it's very common.
Visio is great for network diagrams. Unless you have 1000+ nodes with new ones added every day. For network diagrams, you really need something where the diagram is plotted from the data, not where the data is plotted onto the diagram.
I have to say that I find it amusing that this "think tank" arrives at the conclusion that a de facto homogeneous computing environment is slowing down technical innovation.
God knows things would go a lot slower if you had to develop your software for ten different platforms to be able to gain wide market penetration.
Where exactly do you have that definition from? My dictionaries simply define it as the act of dishonestly taking something that does not belong to you, and keeping it. Nothing about "carrying away". It's not like you can't steal an item without moving away from the scene of the crime.
Oh I'm not confused about the quality of the education or the students. It's the self-perception that I'm going from, since that's what I guess would dictate their behaviour.
These traditions are perpetuated by what is supposedly the best that mankind has to offer? Doesn't it seem a little.. infantile?
Is it customary procedure to suffix "(sucks)" whenever referring to things you disagree with at Princeton?
Obviously. Hence the post you replied to.
You're actually saying that consistently hitting the last line of defence to try to clean up the mess that the lawmakers make is proof that the method of government works?
What this proves is that the system is completely messed up, and that the failsafes that are meant to prevent a total meltdown worked this time around. You really call that a working system?
What amazes me is that 47 lawmakers can unanimously pass a blatantly unconstitutional bill. When the courts have to fix what that many politicians unanimously messed up, it's obvious and undeniable proof that the current method of government just does not work.
What product are you specifically referring to here? This is an entire market, not a single product.
It takes years and millions of dollars to make top quality games. That's a well-established fact. Of course games wouldn't stop being produced. There are lots of games produced today that are completely free to use, with completely open code, which would continue to be produced. The thing is, these games are rarely all that good, and certainly don't often have mass appeal, so yes, the quality would most certainly drop.
Why? Because money gets things done. Snap back into the real world.
"The lack of an open source Opera is exactly what keeps Opera so low in the browser popularity charts."
.. what? How? Where is your supporting evidence of such an absolutely outrageous claim? How can you keep a straight face while claiming that closed source code can't turn a profit? Do you have -any- financial insight into how Opera operates? All Opera seems to do is go forward. Mobile devices, Wii, PC, they aren't losing market share anywhere.
Your personal ideals don't really reflect how the real world operates.
Funny you should say that. You're the one who seems to be backpedalling. :)
So when your technical argument falls to the ground, you resort to personal attacks? Who's -really- trolling? :)
Can you even document that Windows Vista handles unicast traffic before being configured with addressing?
Or perhaps it could be that I simply did not find it likely that you could honestly think that implementing a feature that is described in detail as a completely viable implementation in the RFC, regardless of merit, is somehow not complying with the standard. But than you for making it clear that you apparently do.
As long as there is a case where a client SHOULD set this broadcast bit, the server MUST accept it. It is as simple as that. If the server doesn't accept it, regardless of whether or not it is in fact needed by the client, it constitutes a lack of standards compliance on the part of the server. There is nothing more to it.
I find it absolutely hilarious that you blame Microsoft for making a -completely- viable implementation of DHCP, and claim that servers would need to "go against the RFC" to be compliant with.. the RFC. You're in very, very deep here, grasping at seaweed.
I work for an ISP, and 70% of the time our first line support desk spends talking to customers is spent doing release/renews or repairs on connections. Stuff that has absolutely nothing to do with us, but stuff that we spend time and money on anyway to keep customers happy.
If these people refuse to help their customers on principle, how are they worth anything?
Our other DHCP servers work fine with Vista. Only the ISC DHCPd doesn't play well with it. How would the other servers know how to support this bit, if not from the published standard?
Perhaps they aren't conservative in what they send, but if the ISC DHCPd was any better at being liberal in what they accept, this problem wouldn't exist, so they're both to blame in that respect.
Microsoft don't need to justify their decision to set the bit to what it's set to. One bit that is within standards is certainly not a "huge" fuckup, and since it appears to be supported fine by other DHCP servers, one can only assume that it's a lacking implementation on the part of ISC.
That's part of the RFC definition of "SHOULD". I am well aware of what it means, as I have told you before. Again, I am looking for where this definition is applied. Is it really that difficult to grasp?
I am very well aware of what SHOULD in the context of RFCs mean. I was asking for the specific part of the RFC that you're talking about.
Could you perhaps point out where this warning is?
Is it not the responsibility of the server to accomodate clients? As such, is it not the fault of the server for lacking support for an optional client implementation?
"SHOULD" is a recommendation. A recommendation is by logical necessity optional, and relies on the server to follow the standard. A server exists to accomodate clients. Who isn't accepting the bit?
Obvious, yes, but not the one you'd arrive at.
You're making this out to be a Microsoft against the world situation. Our Cisco DHCP server worked fine with Vista, no problems at all. Only when we switched to an ISC DHCP server did we start having problems. In fact, the only DHCP servers I've seen so far having trouble playing nice with Vista have been ISC DHCP servers.
This is a failure on the part of ISC to make their DHCP server standards compliant, regardless of how esoteric you find the Vista client implementation.
As for Microsoft announcing the problems to be with non-Microsoft products - Wow. A corporation denying responsibility for issues it isn't responsible for, and using the failures of competitors to promote their own software. What's next?
That's funny - Our Cisco DHCPd worked fine with Vista, but DHCP3 is choking.
I believe the spirit of RFCs is something like "Be liberal with what you can receive, and conservative with what you send out.", or something to that effect. Vista is adhering to the RFC. The worst you can throw at it is not adhering to the spirit of RFCs, but the problem only exists because the server software, if adhering to the RFC at all, doesn't adhere to the spirit of it, either.
Personally, I'd say that when standards compliant, the burden is on servers to accomodate client implementatins, not clients to accomodate server implementations.