My company's (a very very large retailer) Cisco engineer has Fedora Core 2 running on his laptop. We've actually had a number of discussions with him about it. From what he said, it's not officially supported at Cisco, but no one had a problem with him experimenting. So far, he's been very happy he switched.
For how he uses a laptop (email, browsing, serial terminal emulation), it suits him just fine. And it's cool.:-) He's got one of the other engineers on my team thinking about installing Linux on his work laptop as well. The word from our PC support team is "you can do it if you like, just don't expect support". I wonder if this is how conversions will happen in large corporations: early adoption (okay, not that early by now) by a select few leading to greater acceptance within the organization.
Even if you care about security, someone else's apathy can lead to your headaches. That's how worms work. Find enough people who don't care and you can create lots of problems (i.e., DDOS from zombie hosts) from those who do. The ones infected may not know or care, but it affects everyone.
From your own link to the Cisco site, doesn't that phone only support Skinny and not SIP?
For the uninitiated: Skinny is a proprietary Cisco protocol which serves many of the same functions as SIP, although I believe it does offer some performance enhancements when compared to SIP. The Cisco CallMangers are their PBX of sorts, which route calls to IP addresses, can integrate with traditional PBXes, etc.
If said webserver is publicly net accessible, you have access to your info in lots of places. Now, perhaps making a desktop machine publically accessible isn't the wisest of ideas, but that's another issue...
Maybe faulty, maybe not. There are a lot of incompatibilities and general "flakiness" with some network auto-negotion interactions. It's a fairly standard precaution in large network environments that servers should not rely on auto-negotiate and instead should have their speed and duplex settings hard-coded.
In reality, the only places where auto-negotiation is important are mobile devices (laptops) which may connect to a variety of network connection types or for the home user "plug-and-play" market. Major datacenter infrastructure isn't the place for auto-negotiating low level network settings any more than it is appropriate to have dynamic IP addressing via DHCP.
Isn't the article poster in favor of include files? He's looking for arguments to go to battle with the vendor. Is there something about using #include which seems stupid to you?
I can't, but my best friend does this quite well. He uses it to add up scores for players turns while playing History of the World. I've tried to master it, but I can't seem to control my fingers well enough to get some of the more awkward numbers.
The World Bridge Federation has since stopped the drug testing. There was an initiative within the bridge community to become recognized by the IOC to potential compete in the Olympic Winter Games. The IOC is considering opening up the Winter Games to 'mental sports' categories, such as bridge, chess, etc. The drug testing was part of the effort to match the IOC requirements for sports testing.
The Bridge World, the leading bridge journal, had a long series of editorials on the subject. I think that their content isn't available publicly, unfortunately. However I can report that the expert bridge community was skeptical about the testing before any of the events happened and outraged by what did happen. For example, cafeine is a drug that is on the IOC's banned list for performance enhancers. Anyone want to guess how much coffee is consumed at a bridge tournament?
The WBF changed these rules on their own whim without really seeing what the players wanted, and the parent's link points to some of the fall out. While the WBF has done some good things for bridge, this one is one of the many blunders by the WBF over the years, and I'm sure it will not be the last.
Disclaimer: I have a silver medal in a WBF world championship, plus many top 10 finishes in North American championship events (including 1 gold), so I have direct experience with these types of events, the WBF and how their events operate.
Disclaimer: I am not an accountant or an options trader. I do know plenty of both though.;-)
Parent is right, here's another way to think about it:
Suppose 1 share of stock X is trading today at $10. I offer you an option to sell a share of stock at $20 anytime within the next 3 months, but I charge you $10 for that right. If you went out and bought 1 share of stock for $10 and sold it to me for $20, you get the $10 profit from the stock sale, but you had to pay me $10 for the option to sell ('put') that stock in the first place. Net profit zero, even though the option itself is worth something today.
Let's change it around a little bit. Now the stock is still selling at $50 today. Now I sell you the right to purchase ('call') a share at $55, also expiring in 3 months for $5. Currently, this seems like a bad deal: I'm charging you $5 for something which you could do better on your own in the open market. Let's say you buy 1 option at the $5 price plus 1 share of stock at $50. Two scenarios: Company X discovers a brand new Widget and the stock price soars up to $100. For the option, you spend $55 plus your original $5 and sell your new share at $100. Total profit: $40. Your share was purchased at $50 and sold for $100, total profit $50. So why would anyone want to buy options? You make less money, right?
Turn to scenario #2: Company X has a major scandal releasing Dihydrogenmonoxoide into the air in mass quantities, causing the stock price to fall to $10. Your option is worthless, so you throw it away. Total loss: $5. Your share of stock was purchased at $50, but now is only worth $10, total loss of $40.
The advantage of options is that there is less risk. The person selling the option must price it appropriately, or they will take on too much risk themselves. The price of an option is an attempt to try to guess what is the likelihood the option will be exercised, plus how much the price differential will be at the time it is exercised.
While what you say is true, unless your UpperlevelProgrammingLanguage is commonly available, there is a lot of complexity in getting said language to install and work on a large number of systems. Using standard high level languages with standard libraries does cut down on the work to make portable servers available to the masses.
The length of code isn't the real issue here, it's the effort required in writing said server and making it available to others.
Do you have common systems with shell access? (telnet, ssh, whatever.) Nothing better than having some 'old school' tools available, plus it gives a nice sandbox environment for learning about *NIX, programming, etc.
Re:Am I the only one who doesn't get it?
on
VOIP Meets Cell Phones
·
· Score: 3, Informative
The target market is people who have unlimited mobile-to-mobile calls, but would have to pay for calls to land lines during business hours. The call you make is to a mobile number, allowing you to effective have unlimited minutes to any number.
Unless these fabricators can create new atomic elements via fission/fusion, there does seem to be the need for raw components. In otherwords, no gold from lead alchemy with this device...some things (gold, silver, platinum, titanium, etc.) would keep their intrinsic value.
Construction from readily available elements (Carbon, Hydrogen, Oxygen, Nitrogen, etc.) would be much easier, of course.
Actually, I think both are acceptable usage. Although the original RFC calls it User Datagram Protocol, I'm not the only one who expands it to Unreliable Datagram Protocol.
Networking is based on different layers of protocols. 'IP' is a layer 3 or 'network' protocol. It's at this layer that routing decisions and the like are made. Competing protocols in this area would be things like IPX (Novell from back in the day), Appletalk, etc.
TCP or UDP are both one layer up, layer 4 or 'transport' layer protocols. This layer deals with the logic in communicating between different IP based devices. TCP [Transmission Control Protocol] enforces 'reliable' communications within the protocol, at the cost of overhead and the like. UDP [Unreliable Datagram Protocol] is much closer to raw traffic. It has minimal checksum information to make sure that the traffic being received is what was sent, but other than that it enforces no preconceived notions on how the communication should check to make sure it's reliable. While one use of UDP is to send traffic where the sender doesn't care if the receiver gets the message (such as syslog), it's not the only. If an application wants to have it's own error checking/receiving verification mechanism with knowledge of the underlying traffic rather than the default generic methods available with TCP, UDP is a fine choice.
Simple because the protocol doesn't enforce reliable connectivity doesn't mean it can't be done with the application. That's like saying HTML is just a simple text file that gets parsed, how could it ever have anything dynamic associated with it.
Slashdot Mirror
My company's (a very very large retailer) Cisco engineer has Fedora Core 2 running on his laptop. We've actually had a number of discussions with him about it. From what he said, it's not officially supported at Cisco, but no one had a problem with him experimenting. So far, he's been very happy he switched.
:-) He's got one of the other engineers on my team thinking about installing Linux on his work laptop as well. The word from our PC support team is "you can do it if you like, just don't expect support". I wonder if this is how conversions will happen in large corporations: early adoption (okay, not that early by now) by a select few leading to greater acceptance within the organization.
For how he uses a laptop (email, browsing, serial terminal emulation), it suits him just fine. And it's cool.
Would you like to put your digital pictures from your recent Chicago vacation on your web site? Oh I'm sorry, those are copyrighted. Too bad.
Georgia has them all.
The wonderful thing about standards is that there are so many to choose from.
Even if you care about security, someone else's apathy can lead to your headaches. That's how worms
work. Find enough people who don't care and you can create lots of problems (i.e., DDOS from zombie hosts) from those who do. The ones infected may not know or care, but it affects everyone.
The book was enjoyable, it wasn't that bad. But I do agree, the movie was (much) better.
From your own link to the Cisco site, doesn't that phone only support Skinny and not SIP?
For the uninitiated: Skinny is a proprietary Cisco protocol which serves many of the same functions as SIP, although I believe it does offer some performance enhancements when compared to SIP. The Cisco CallMangers are their PBX of sorts, which route calls to IP addresses, can integrate with traditional PBXes, etc.
If said webserver is publicly net accessible, you have access to your info in lots of places. Now, perhaps making a desktop machine publically accessible isn't the wisest of ideas, but that's another issue...
Maybe faulty, maybe not. There are a lot of incompatibilities and general "flakiness" with some network auto-negotion interactions. It's a fairly standard precaution in large network environments that servers should not rely on auto-negotiate and instead should have their speed and duplex settings hard-coded.
In reality, the only places where auto-negotiation is important are mobile devices (laptops) which may connect to a variety of network connection types or for the home user "plug-and-play" market. Major datacenter infrastructure isn't the place for auto-negotiating low level network settings any more than it is appropriate to have dynamic IP addressing via DHCP.
Isn't the article poster in favor of include files? He's looking for arguments to go to battle with the vendor. Is there something about using #include which seems stupid to you?
We already do. The first one was in 1972.
There are reasonable alternatives though, such as
Notetab Light, which is totally free, no nagging, no ads, nothing.
Generally, copyright violations require someone to publish or distribute without permission. PA asked /. to host the images here.
I can't, but my best friend does this quite well. He uses it to add up scores for players turns while playing History of the World. I've tried to master it, but I can't seem to control my fingers well enough to get some of the more awkward numbers.
The World Bridge Federation has since stopped the drug testing. There was an initiative within the bridge community to become recognized by the IOC to potential compete in the Olympic Winter Games. The IOC is considering opening up the Winter Games to 'mental sports' categories, such as bridge, chess, etc. The drug testing was part of the effort to match the IOC requirements for sports testing.
The Bridge World, the leading bridge journal, had a long series of editorials on the subject. I think that their content isn't available publicly, unfortunately. However I can report that the expert bridge community was skeptical about the testing before any of the events happened and outraged by what did happen. For example, cafeine is a drug that is on the IOC's banned list for performance enhancers. Anyone want to guess how much coffee is consumed at a bridge tournament?
The WBF changed these rules on their own whim without really seeing what the players wanted, and the parent's link points to some of the fall out. While the WBF has done some good things for bridge, this one is one of the many blunders by the WBF over the years, and I'm sure it will not be the last.
Disclaimer: I have a silver medal in a WBF world championship, plus many top 10 finishes in North American championship events (including 1 gold), so I have direct experience with these types of events, the WBF and how their events operate.
Disclaimer: I am not an accountant or an options trader. I do know plenty of both though. ;-)
Parent is right, here's another way to think about it:
Suppose 1 share of stock X is trading today at $10. I offer you an option to sell a share of stock at $20 anytime within the next 3 months, but I charge you $10 for that right. If you went out and bought 1 share of stock for $10 and sold it to me for $20, you get the $10 profit from the stock sale, but you had to pay me $10 for the option to sell ('put') that stock in the first place. Net profit zero, even though the option itself is worth something today.
Let's change it around a little bit. Now the stock is still selling at $50 today. Now I sell you the right to purchase ('call') a share at $55, also expiring in 3 months for $5. Currently, this seems like a bad deal: I'm charging you $5 for something which you could do better on your own in the open market. Let's say you buy 1 option at the $5 price plus 1 share of stock at $50. Two scenarios: Company X discovers a brand new Widget and the stock price soars up to $100. For the option, you spend $55 plus your original $5 and sell your new share at $100. Total profit: $40. Your share was purchased at $50 and sold for $100, total profit $50. So why would anyone want to buy options? You make less money, right?
Turn to scenario #2: Company X has a major scandal releasing Dihydrogenmonoxoide into the air in mass quantities, causing the stock price to fall to $10. Your option is worthless, so you throw it away. Total loss: $5. Your share of stock was purchased at $50, but now is only worth $10, total loss of $40.
The advantage of options is that there is less risk. The person selling the option must price it appropriately, or they will take on too much risk themselves. The price of an option is an attempt to try to guess what is the likelihood the option will be exercised, plus how much the price differential will be at the time it is exercised.
While what you say is true, unless your UpperlevelProgrammingLanguage is commonly available, there is a lot of complexity in getting said language to install and work on a large number of systems. Using standard high level languages with standard libraries does cut down on the work to make portable servers available to the masses.
The length of code isn't the real issue here, it's the effort required in writing said server and making it available to others.
Do you have common systems with shell access? (telnet, ssh, whatever.) Nothing better than having some 'old school' tools available, plus it gives a nice sandbox environment for learning about *NIX, programming, etc.
The target market is people who have unlimited mobile-to-mobile calls, but would have to pay for calls to land lines during business hours. The call you make is to a mobile number, allowing you to effective have unlimited minutes to any number.
Here here! I was going to post the same question. Seems like a natural match. I loved reading about WW's adventures in the Vegas poker room.
Unless these fabricators can create new atomic elements via fission/fusion, there does seem to be the need for raw components. In otherwords, no gold from lead alchemy with this device...some things (gold, silver, platinum, titanium, etc.) would keep their intrinsic value.
Construction from readily available elements (Carbon, Hydrogen, Oxygen, Nitrogen, etc.) would be much easier, of course.
Actually, I think both are acceptable usage. Although the original RFC calls it User Datagram Protocol, I'm not the only one who expands it to Unreliable Datagram Protocol.
Networking is based on different layers of protocols. 'IP' is a layer 3 or 'network' protocol. It's at this layer that routing decisions and the like are made. Competing protocols in this area would be things like IPX (Novell from back in the day), Appletalk, etc.
TCP or UDP are both one layer up, layer 4 or 'transport' layer protocols. This layer deals with the logic in communicating between different IP based devices. TCP [Transmission Control Protocol] enforces 'reliable' communications within the protocol, at the cost of overhead and the like. UDP [Unreliable Datagram Protocol] is much closer to raw traffic. It has minimal checksum information to make sure that the traffic being received is what was sent, but other than that it enforces no preconceived notions on how the communication should check to make sure it's reliable. While one use of UDP is to send traffic where the sender doesn't care if the receiver gets the message (such as syslog), it's not the only. If an application wants to have it's own error checking/receiving verification mechanism with knowledge of the underlying traffic rather than the default generic methods available with TCP, UDP is a fine choice.
Simple because the protocol doesn't enforce reliable connectivity doesn't mean it can't be done with the application. That's like saying HTML is just a simple text file that gets parsed, how could it ever have anything dynamic associated with it.
I am not particularly a comic book fan, and never have been. I've read the Watchmen. It's excellent. Pick up a copy and give it a try.
Heinlein had a lot of thoughtful ideas, this isn't the only case where one of his story ideas became an actual invention.
Consider, for example, a Waldo.
Smart man Heinlein.