Trolling! Is it a viable solution? It doesn't work.;) Really.
Microsoft has decided to use an old workaround as default. It is not forbidden, but you should not use it if you don't have to. WHY do they do that?
It is like MS did in SIS vote on OOXML. It is not forbidden to become a member of the workinggroup, but it is against the intention of the rules. If we have to put rules on everything, because people behave lika Microsoft, then we are heading towards a society none of us want.
There is no excuse for using the Broadcast bit, unless Vista is uncapable to use unicast. Obviously Vista is capable, so they shouldn't use the bit.
It is simple as that. Microsoft messed up, and you are trolling.
The ISP has not monopoly. It is those who bendover for Microsoft that ruin interoperability. Just look at SIS, OOXML and ISO.
Microsoft has made a stupid thing, they have to fix it, and unless their customers demand it, they wont.
They have made an undesired workaround default in their new shiny OS. Why have they done that?
Read RFC-1542
3.1.1 The BROADCAST flag
Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
messages directly to a client using unicast delivery. The IP
destination address (in the IP header) is set to the BOOTP 'yiaddr'
address and the link-layer destination address is set to the BOOTP
'chaddr' address. Unfortunately, some client implementations are
unable to receive such unicast IP datagrams until they know their own
IP address (thus we have a "chicken and egg" issue). Often, however,
they can receive broadcast IP datagrams (those with a valid IP
broadcast address as the IP destination and the link-layer broadcast
address as the link-layer destination).
If a client falls into this category, it SHOULD set (to 1) the
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
messages it generates. This will provide a hint to BOOTP servers and
relay agents that they should attempt to broadcast their BOOTREPLY
messages to the client.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
Slashdot discussion is full of references to this. The RFC is available on Internet.
I cannot see why you have to ask me about this, maybe you are just trolling or are paid by Microsoft or just don't have a clue. What do I know.
rfc 1542
3.1.1 The BROADCAST flag
------
If a client falls into this category, it SHOULD set (to 1) the
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
messages it generates. This will provide a hint to BOOTP servers and
relay agents that they should attempt to broadcast their BOOTREPLY
messages to the client.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
-------
Microsoft has set this flag to 1, without telling anyone and without motivation. When it does not work, you ask other parts, ie others than Microsoft, to go against the RFC to fix it?
And I don't understand what part of "but the full implications should be
understood and the case carefully weighed before choosing a
different course." you don't understand.
From rfc-1542 that regulates the use of the broadcast flag:
a section that defines certain terms, including SHOULD
(also later defined in rfc-2119)
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing a
different course.
Yet, Microsoft decides it is wise to implement this as default in the new version of Windows. That is as smart as thinking that buying a ISO standard will make us like OOXML better than if they tried to fix the problems OOXML have.
;) It means that you should not use the broadcast bit if it is not needed, and it is not in this case. The server is not required to implement it, since it is supposed to help older implementations. Vista is not one of those.
Of course it is not FORBIDDEN to set the bit, but you have to take the consequenses of setting it. Who set the bit?
Actually, Vista is not following the RFC. They SHOULD NOT set the broadcast bit.
Since it is only affecting customers with Vista and only those without a NAT firewall, it is not a widespread problem, and the correct solution should be a patch from Microsoft.
The community version does not need a license key,
but you used the Enterprise trial version.
on the download page you can read
"Please note this is a time-limited trial and by installing the software you are agreeing to our Enterprise Trial license, specifically that you will uninstall it in 30 days if you decide to not purchase the Alfresco Enterprise Network"
If you want open-source, use the community version.
In part, it is as you say, but the truth is also that Vista is not mainstream yet, for example our helpdesk software does not run on Vista, so it is better to wait a few years.
My employer took the decision to migrate from win2k to XP, and we will roll it out this fall. Vista was proposed but we do not consider it ready for use.
My z61p has intel 3945 and it works with a proprietary driver. It also has a ATP FireGL 5200 that is without compiz-support since ATI doesn't support it and it isn't documented for anyone else to support it.
I am disappointed with my nice laptop, I hope that Lenovo learned something, but I will not easily get another one. I complained about it to Lenovo, but got no answer.
At my job, we are doing a major upgrade of the architecture, and one of my criteria is interoperability. All new systems should be accessible from any client, MS, Mac or Linux. That way we can continue with XP on clients, while at the same time, we are able to make it easier to change clients in the future. To be dependent on Excel-macros is a very bad idea, it is a quickfix that make it difficult to manage your IT environment, since it set the rules. Who want to let their architecture be defined by 1 product?
I live in a small town north of Stockholm, Sweden. Our local government also installed a loop of fiber. Now I have bidirectional 100Mbit for 200 SEK (30$). The provider is a small local company, but there are several alternatives using *sdl
Slashdot Mirror
Trolling! Is it a viable solution? It doesn't work. ;) Really.
Microsoft has decided to use an old workaround as default. It is not forbidden, but you should not use it if you don't have to. WHY do they do that?
It is like MS did in SIS vote on OOXML. It is not forbidden to become a member of the workinggroup, but it is against the intention of the rules. If we have to put rules on everything, because people behave lika Microsoft, then we are heading towards a society none of us want.
There is no excuse for using the Broadcast bit, unless Vista is uncapable to use unicast. Obviously Vista is capable, so they shouldn't use the bit.
It is simple as that. Microsoft messed up, and you are trolling.
The ISP has not monopoly. It is those who bendover for Microsoft that ruin interoperability. Just look at SIS, OOXML and ISO. Microsoft has made a stupid thing, they have to fix it, and unless their customers demand it, they wont. They have made an undesired workaround default in their new shiny OS. Why have they done that? Read RFC-1542 3.1.1 The BROADCAST flag Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY messages directly to a client using unicast delivery. The IP destination address (in the IP header) is set to the BOOTP 'yiaddr' address and the link-layer destination address is set to the BOOTP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until they know their own IP address (thus we have a "chicken and egg" issue). Often, however, they can receive broadcast IP datagrams (those with a valid IP broadcast address as the IP destination and the link-layer broadcast address as the link-layer destination). If a client falls into this category, it SHOULD set (to 1) the newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY messages it generates. This will provide a hint to BOOTP servers and relay agents that they should attempt to broadcast their BOOTREPLY messages to the client. If a client does not have this limitation (i.e., it is perfectly able to receive unicast BOOTREPLY messages), it SHOULD NOT set the BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0). DISCUSSION: This addition to the protocol is a workaround for old host implementations. Such implementations SHOULD be modified so that they may receive unicast BOOTREPLY messages, thus making use of this workaround unnecessary. In general, the use of this mechanism is discouraged.
Slashdot discussion is full of references to this. The RFC is available on Internet.
I cannot see why you have to ask me about this, maybe you are just trolling or are paid by Microsoft or just don't have a clue. What do I know.
rfc 1542
3.1.1 The BROADCAST flag
------
If a client falls into this category, it SHOULD set (to 1) the
newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
messages it generates. This will provide a hint to BOOTP servers and
relay agents that they should attempt to broadcast their BOOTREPLY
messages to the client.
If a client does not have this limitation (i.e., it is perfectly able
to receive unicast BOOTREPLY messages), it SHOULD NOT set the
BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
DISCUSSION:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
-------
Microsoft has set this flag to 1, without telling anyone and without motivation. When it does not work, you ask other parts, ie others than Microsoft, to go against the RFC to fix it?
And I don't understand what part of "but the full implications should be understood and the case carefully weighed before choosing a different course." you don't understand.
From rfc-1542 that regulates the use of the broadcast flag:
a section that defines certain terms, including SHOULD (also later defined in rfc-2119)
o "SHOULD"
This word or the adjective "RECOMMENDED" means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications should be
understood and the case carefully weighed before choosing a
different course.
Yet, Microsoft decides it is wise to implement this as default in the new version of Windows. That is as smart as thinking that buying a ISO standard will make us like OOXML better than if they tried to fix the problems OOXML have.
Who is not required to accept it? Who has been warned to set the bit?
;) It means that you should not use the broadcast bit if it is not needed, and it is not in this case. The server is not required to implement it, since it is supposed to help older implementations. Vista is not one of those. Of course it is not FORBIDDEN to set the bit, but you have to take the consequenses of setting it. Who set the bit?
So you think they should honour an obsolete broadcast bit, that Vista SHOULD NOT use according to the RFC. Vista is wrong and so are you ;)
No, Microsoft decided to take us 15 years back in time. ;=) the broadcast-bit is for old implementions, not for new and supposably capable like Vista.
The broadcast bit is in the RFC an it says it SHOULD NOT be used, if you doesn't need it. Vista does NOT need it!
Well if you use Vista in Lund, Sweden, you can't access Internet because Microsoft made a mess of Vista.
Actually, Vista is not following the RFC. They SHOULD NOT set the broadcast bit.
Since it is only affecting customers with Vista and only those without a NAT firewall, it is not a widespread problem, and the correct solution should be a patch from Microsoft.
Monthly fee contract 1 year 3 year 5 year
100 Mbit/s 349 kr 329 kr 299 kr
10 Mbit/s 199 kr 179 kr 159 kr
Taxes included.
7 SEK = 1 $
They probably would click on OK, but it is Microsoft that allows that program to run, on linux it doesnt work.
The community version does not need a license key, but you used the Enterprise trial version. on the download page you can read "Please note this is a time-limited trial and by installing the software you are agreeing to our Enterprise Trial license, specifically that you will uninstall it in 30 days if you decide to not purchase the Alfresco Enterprise Network" If you want open-source, use the community version.
In part, it is as you say, but the truth is also that Vista is not mainstream yet, for example our helpdesk software does not run on Vista, so it is better to wait a few years.
It is mainly because of demand for more simple access to wireless networks.
I have been using Vista for almost a year, and it is not ready for us.
I have been using it for almost a year, and in my opinion it's not ready yet.
My employer took the decision to migrate from win2k to XP, and we will roll it out this fall. Vista was proposed but we do not consider it ready for use.
My z61p has intel 3945 and it works with a proprietary driver. It also has a ATP FireGL 5200 that is without compiz-support since ATI doesn't support it and it isn't documented for anyone else to support it.
I am disappointed with my nice laptop, I hope that Lenovo learned something, but I will not easily get another one. I complained about it to Lenovo, but got no answer.
At my job, we are doing a major upgrade of the architecture, and one of my criteria is interoperability. All new systems should be accessible from any client, MS, Mac or Linux. That way we can continue with XP on clients, while at the same time, we are able to make it easier to change clients in the future.
To be dependent on Excel-macros is a very bad idea, it is a quickfix that make it difficult to manage your IT environment, since it set the rules. Who want to let their architecture be defined by 1 product?
The question is;
Does it run Linux?
Ohh, you are giving us to much credit. It is actually only 7 weeks of vacation. Sorry to disappoint you!
I live in a small town north of Stockholm, Sweden. Our local government also installed a loop of fiber. Now I have bidirectional 100Mbit for 200 SEK (30$). The provider is a small local company, but there are several alternatives using *sdl