What I said, in so many words, was that a certificate authority (open source or otherwise) generally locks the closed front door while the back door and all the windows are wide open. If that metaphor is too obtuse, I'll state it more directly: certificate authorities are presently a waste of effort.
I think the whole certificate authority scam is a solution in search of a problem. Yes, there are useful man-in-the-middle attacks where a public key hasn't been independently validated. I won't claim otherwise. I will claim that for nearly every application there are so many avenues of attack with a higher probability of success that worrying about key validation is a little like digging a nuke bunker while terrorists buy plane tickets.
For one thing, you don't have the wherewithal to dig a nuke bunker than allows you to survive more than the most cursory nuclear exchange and you probably won't be near the bunker if it happens anyway. For another, the focus of the attacks which aren't just in your imagination is elsewhere.
Unless you demand perfect encryption in everything, you won't be ready if the attack ever does come. And you won't demand it because you're not prestigious enough for your field of contacts won't put up with your folly. Besides, its the buffer overflows and related software bugs that are going to get you. Until that starts to draw to a close, worrying about key validation is an exercise in futility.
The Digital Performance Right in Sound Recordings Act of 1995 (DPRA) and the Digital Millennium Copyright Act of 1998 (DMCA) granted a performance right in sound recordings for certain digital and satellite transmissions. In exchange for this new right, SRCOs are subject to a compulsory license for the use of their music, provided the user complies with those conditions set forth in the copyright law. SoundExchange was established to administer the collection and distribution of royalties from such compulsory licenses taken by noninteractive streaming services that use satellite, cable or Internet methods of distribution.
For those of you who are caught up in the language, let me make it crystal clear for you: There is a license which artists must grant under law, a compulsory license, which allows certain digital performances. If you record a song, anyone may use it under the terms of that license.
As with the GPL, anyone may accept. Anyone may decline. If you decline, you have no rights to perform the song under the license. You may still acquire an alternate license directly from the copyright owner and do anything the owner authorizes, including perform the song in a manner similar to what is allowed by the compulsory license.
You owe fees to SoundExchange only if you accept the compulsory license and perform the song under those terms and conditions.
Now, SoundExchange doesn't want you to know this. They have very carefully crafted the language in their documentation to lead you to the impression that paying them is the only option. Nevertheless, if you read carefully you'll find that's not what they actually said. And if you read the relevant sections of the DPRA and DMCA, you'll find that's not what the law says either.
Just scratch it out before signing and when you turn it in, say, "Hey, fyi, I scratched out these lines. Please tell me if that's a problem or we need to discuss it further." Nine times out of ten its a form contract and an item on a checklist. The employer doesn't care that you scratched out the lines. Did he sign the contract? Check. Next?
The tenth time you'll have to choose whether or not to walk away. As someone who has walked away, let me tell you: its a tough choice. Its also the right choice. There are plenty of jobs for a smart developer and plenty of companies who won't try to walk over you that way.
Unless the copyright issues are explicitly spelled out in the contract, two things are true:
1. The development house owns the copyrights, not your company. Period. 2. Your company has an implicit non-exclusive license to use, modify, improve and even sell the software if it can be done in a manner consistent with the purposes you discussed with while creating the contract. Note however that they would be entitled to a reasonable portion of the proceeds in any outright sale of the software.
There are a few exceptions that could render those statements false, but they're pretty narrow. A couple of them are:
If their development was an extension of existing work then its a derivative work and the development co-owns the copyrights to the new work with the prior owner, possibly you. There is no you own this part and they own that part. You both own the entire work.
If your and their developers both wrote the software with their developers merely contributing components as specified then it probably eeks in to work-made-for-hire territory, leaving the copyrights firmly in your hand. You'd have to be the primary developer with them contributing components as specified.
Bottom line: if the difference impacts your company's bottom line then you need to invest in a lawyer. If it doesn't, move on and be smarter next time.
Bind's implementation of dynamic dns is... funky at best. It syncs changes to disk infrequently and unpredictably, and it does so by rewriting the entire zone file in the same format as it uses for secondaried zones so that any comments or other organization in the affected file is lost. The security is also relatively coarse: the tools don't allow a particular security key to apply to a particular name -- the key applies to a whole zone. If you have a large number of devices and want to tightly constrict update access, that poses a scalability problem as you need one zone per device.
Dyndns is likely using Bind at the back end, but they've built another layer of security and management on top of it. Biff98 is looking for software that does the whole job out of the box.
I'm not contradicting you. I am, however, trying to understand how anything you said qualifies as something other than the Chewbacca defense.
As near as I can figure, not one word reasonably relates to the observed changes in cost and price half a century ago when transistors superceded vacuum tubes in most consumer electronics. Accordingly, its not relevant to the analogy drawn between that historical occurance and the original question about the price of T1s verus the price other forms of Internet access today.
Actually, most botnet-infected PC's connect to a server on the internet and request instructions rather than waiting for someone to connect to them. If they did the latter, it wouldn't work behind a firewall: botnet authors would be excluding a heck of a lot of machines. That makes them clients in the client-server model.
But now I'm getting a tad pedantic. Suffice it to say that my earlier description was intended to describe behavior authorized by the computer's owner. Hacked computers are way beyond the bounds of the servers/no servers issue.
1. Any T1 equipment not used for Internet service will presently be gobbled by PRIs for plain business telephony and any spare copper pairs will be gobbled for phones and DSL. Ergo no spare supply, even as demand drops. The manufacturers might start to feel a pinch but the phone company won't for some time yet.
2. The primary additive cost associated with a T1 is manpower. T1s are provisioned in an astonishingly manpower-intensive process. Virtually all of the switching is accomplished on wire-wrapping DSX-1 panels and its demuxed from SONET, physically wired and remuxed to SONET at every stop. I'm not talking RJ45 patch cables here; I'm talking individual bare wires wrapped around a metal post.
As a result, not only do T1s cost more to provide than a PON service like FiOS, they're less reliable as well. The only good reason to buy an Internet T1 these days is if you're in a location where you can't get anything better.
Badfrog's question speaks for itself; it needs no rephrasing or clarification.
Your economic theory leaves a little to be desired as well. Cost constricts supply. As price approaches cost, supply dwindles until it stabilizes at a level meeting demand -- above cost. Price might briefly dip below cost in order to exhaust inventory, but T1's are a service: there is no inventory.
Take for example: dirt. Everybody has dirt. Nobody wants dirt. Demand/supply, the price should be zero. So go try to tell the garden department at Home Depot that you want them to give you free dirt. Didn't quite work out that way, did it?
By the same definition you'd have to call a voip phone a server because it can answer an incoming call.
Actually, that depends on the implementation.
Technically, systems like Vonage initate an outbound UDP link to the call manager in order to open a path through the (presumed) NAT firewall so that when a call comes in the packets from the call manager can get back to it. When plugged in, the phone (client) opens a connection to the call manager (server). At some future time, the call manager (server) advises the phone (client) over that connection that a call has arrived. The phone (client) then opens a new connection to the gateway (server) to process the call. And the phone rings.
Its a push technology, like pointcast, but still very much client-server.
And then there's Skype. Skype doesn't work this way; Skype is peer-to-peer. The Skype phone is a server that expects other phones to connect to it and a client that expects to open connections to the other Skype phone servers.
Yeah, it really is. And your email example is bogus too: if I return those emails, I do it by connecting back to an email server. The email server doesn't connect to me.
I don't think there is any good technical or legal definition of what a "client" and "server" computer are.
Try this one: If I can remotely connect to your computer and induce it to perform a non-trivial function at my convenience, its a server.
We firewall jockeys even have a precise technical definition: If your machine accepts a SYN packet and responds with a SYN/ACK, or if your machine expects to receive the first in a series of UDP packets on a particular port, its a server.
If you have an interesting take on a subject that invalidates one of my approaches to problem solving, I'd like to hear that viewpoint in detail so I can modify or if necessary scrap my approach. Meaning no offense, but if that's not a challenge you can rise to then your opinion about the breadth of my horizons matters less to me than the grains of sand stuck in the tread on my shoe.
Vacuum tubes are expensive because its hard to make a vacuum tube that has any degree of reliability. The fact that transistors do the same job and cost dirt has little impact on the difficulty or cost of making vacuum tubes.
T1s are expensive for the same reason. The 15 meg FiOS service at my house actually costs Verizon a lot less to build and maintain than the multiply repeated 1.5 meg T1 that preceeded it.
That's a curious assertion. Describe if you would this process-free cycle of inspiration, hypothesis and experimentation that leads to valid physics theory.
Every endeavor which is neither purely random nor purely subjective can be usefully described in terms of the process it follows. I defy you to offer even a single example of a specific, concrete activity for which this is not true.
You don't have to understand a process to follow it. Most people don't. You can get useful results without every realizing that the way you learned to do things constitutes a process. But if you do understand that you're actually following a process, you can look for divergence and often spot errors which would otherwise be very abstruse.
Consider, for example, a road-bridge problem. Traffic regularly gets snarled with accidents where a particular highway crosses the river, so authorities lower the speed limit on the bridge. But this is exactly the wrong answer. Traffic is a process. The capacity of a highway is the number of lanes times the average speed of the cars. Traffic gets snarled there because the drivers already slow down to cross the bridge, reducing the capacity of the road... which in heavy traffic slows cars behind them, reducing the capacity of that stretch of road, and on back until traffic is sparse enough that the person behind doesn't slow down. Then the accidents happen because the tightly packed traffic offers fewer recovery options as drivers make the normal rate of mistakes.
To improve safety in this situation, authorities should have INCREASED the speed limit just around and on the bridge. That would maintain the road's capacity as it crossed the river so that traffic doesn't snarl, reducing the accident rate to levels normal for other stretches of the road.
You'd never spot that error or find the correct solution without first understanding the process.
The only reference I found in the first couple google pages for "petr beckmann relativity" that wasn't a total fluff piece was this old 1990 article from National Review: http://www.encyclopedia.com/doc/1G1-9046912.html
So if I'm reading this right, one consequence of his assertion is that the time dilation predicted by relativity is a bunch of bunk that doesn't really happen. Correct me if I'm wrong, but hasn't time dilation been verified experimentally?
So, fill me in. What's happened in the last 17 years to confirm or refute Beckmann's claim? And why isn't it the first link on Google?
Computer Science is hardly a good vantage point to judge the rest of science from.
Perhaps, but its a fine vantage from which to judge process-oriented inaccuracy and dishonesty: computers are absolutely ruthless to the purveyors of either so good developers learn how to spot things the computer will choke on.
It is with that eye for process that I look at Quantum Physics and find it wanting.
They neglected to mention the median salary for the positions they're trying to fill. Most reports lamenting the lack of available IT talent do. Perhaps they learned a lesson from the regular complaints about the lack of qualified teachers which are routinely riposted with a complaint about the lack of qualified teacher salaries.
My own background is computer science. In computer science we have basically two categories of software functions: those which produce the correct answer and those which produce a usefully good answer. We consider the difference between the two to be of such pivotal importance that we assign different labels: algorithm and heuristic.
Epicycles was a useful heuristic. Given a timestamp it provided a useful approximation of the position of the planets in the night sky. If Quantum Physics' standard model only offers similarly useful heuristics then perhaps physiscists should label them as such, not elevate them to the same status as Relativity's proven algorithms. Perhaps they should even describe quantum physics in terms of, "These equations offer the best known approximation of reality's observed behavior," instead of the more conceited, "this is what reality is."
Epicycles was the only game in town from the 3rd century all the way through the 16th... until Copernicus came along with the correct explanation for the data and made 1300 years of scholars look like raving lunatics.
How then could Epicycle's proponents have known they were headed down a blind alley? Simple really: instead of proving it outright, each major new dataset required more refinements and additions to the theory -- Epicycles within Epicycles.
Quantum Mechanics has had nearly a century to stabilize in to a theory that each new experiment proves without needing additional refinements. Instead it has added a bazillion particles, spins, counter spins and all sorts of other oddities. It hasn't stabilized and each new addition makes the theory less likely to be correct.
Slashdot Mirror
What I said, in so many words, was that a certificate authority (open source or otherwise) generally locks the closed front door while the back door and all the windows are wide open. If that metaphor is too obtuse, I'll state it more directly: certificate authorities are presently a waste of effort.
The license is compulsory in that the copyright owner is compelled to offer it. No one is required to accept the offer.
I think the whole certificate authority scam is a solution in search of a problem. Yes, there are useful man-in-the-middle attacks where a public key hasn't been independently validated. I won't claim otherwise. I will claim that for nearly every application there are so many avenues of attack with a higher probability of success that worrying about key validation is a little like digging a nuke bunker while terrorists buy plane tickets.
For one thing, you don't have the wherewithal to dig a nuke bunker than allows you to survive more than the most cursory nuclear exchange and you probably won't be near the bunker if it happens anyway. For another, the focus of the attacks which aren't just in your imagination is elsewhere.
Unless you demand perfect encryption in everything, you won't be ready if the attack ever does come. And you won't demand it because you're not prestigious enough for your field of contacts won't put up with your folly. Besides, its the buffer overflows and related software bugs that are going to get you. Until that starts to draw to a close, worrying about key validation is an exercise in futility.
This is from the FAQ:
What licenses does SoundExchange administer?
The Digital Performance Right in Sound Recordings Act of 1995 (DPRA) and the Digital Millennium Copyright Act of 1998 (DMCA) granted a performance right in sound recordings for certain digital and satellite transmissions. In exchange for this new right, SRCOs are subject to a compulsory license for the use of their music, provided the user complies with those conditions set forth in the copyright law. SoundExchange was established to administer the collection and distribution of royalties from such compulsory licenses taken by noninteractive streaming services that use satellite, cable or Internet methods of distribution.
For those of you who are caught up in the language, let me make it crystal clear for you: There is a license which artists must grant under law, a compulsory license, which allows certain digital performances. If you record a song, anyone may use it under the terms of that license.
As with the GPL, anyone may accept. Anyone may decline. If you decline, you have no rights to perform the song under the license. You may still acquire an alternate license directly from the copyright owner and do anything the owner authorizes, including perform the song in a manner similar to what is allowed by the compulsory license.
You owe fees to SoundExchange only if you accept the compulsory license and perform the song under those terms and conditions.
Now, SoundExchange doesn't want you to know this. They have very carefully crafted the language in their documentation to lead you to the impression that paying them is the only option. Nevertheless, if you read carefully you'll find that's not what they actually said. And if you read the relevant sections of the DPRA and DMCA, you'll find that's not what the law says either.
Just scratch it out before signing and when you turn it in, say, "Hey, fyi, I scratched out these lines. Please tell me if that's a problem or we need to discuss it further." Nine times out of ten its a form contract and an item on a checklist. The employer doesn't care that you scratched out the lines. Did he sign the contract? Check. Next?
The tenth time you'll have to choose whether or not to walk away. As someone who has walked away, let me tell you: its a tough choice. Its also the right choice. There are plenty of jobs for a smart developer and plenty of companies who won't try to walk over you that way.
Unless the copyright issues are explicitly spelled out in the contract, two things are true:
1. The development house owns the copyrights, not your company. Period.
2. Your company has an implicit non-exclusive license to use, modify, improve and even sell the software if it can be done in a manner consistent with the purposes you discussed with while creating the contract. Note however that they would be entitled to a reasonable portion of the proceeds in any outright sale of the software.
There are a few exceptions that could render those statements false, but they're pretty narrow. A couple of them are:
If their development was an extension of existing work then its a derivative work and the development co-owns the copyrights to the new work with the prior owner, possibly you. There is no you own this part and they own that part. You both own the entire work.
If your and their developers both wrote the software with their developers merely contributing components as specified then it probably eeks in to work-made-for-hire territory, leaving the copyrights firmly in your hand. You'd have to be the primary developer with them contributing components as specified.
Bottom line: if the difference impacts your company's bottom line then you need to invest in a lawyer. If it doesn't, move on and be smarter next time.
Bind's implementation of dynamic dns is... funky at best. It syncs changes to disk infrequently and unpredictably, and it does so by rewriting the entire zone file in the same format as it uses for secondaried zones so that any comments or other organization in the affected file is lost. The security is also relatively coarse: the tools don't allow a particular security key to apply to a particular name -- the key applies to a whole zone. If you have a large number of devices and want to tightly constrict update access, that poses a scalability problem as you need one zone per device.
Dyndns is likely using Bind at the back end, but they've built another layer of security and management on top of it. Biff98 is looking for software that does the whole job out of the box.
I'm not contradicting you. I am, however, trying to understand how anything you said qualifies as something other than the Chewbacca defense.
As near as I can figure, not one word reasonably relates to the observed changes in cost and price half a century ago when transistors superceded vacuum tubes in most consumer electronics. Accordingly, its not relevant to the analogy drawn between that historical occurance and the original question about the price of T1s verus the price other forms of Internet access today.
Actually, most botnet-infected PC's connect to a server on the internet and request instructions rather than waiting for someone to connect to them. If they did the latter, it wouldn't work behind a firewall: botnet authors would be excluding a heck of a lot of machines. That makes them clients in the client-server model.
But now I'm getting a tad pedantic. Suffice it to say that my earlier description was intended to describe behavior authorized by the computer's owner. Hacked computers are way beyond the bounds of the servers/no servers issue.
And just what does this have to do with the price of tea in China?
Your assumptions are faulty.
1. Any T1 equipment not used for Internet service will presently be gobbled by PRIs for plain business telephony and any spare copper pairs will be gobbled for phones and DSL. Ergo no spare supply, even as demand drops. The manufacturers might start to feel a pinch but the phone company won't for some time yet.
2. The primary additive cost associated with a T1 is manpower. T1s are provisioned in an astonishingly manpower-intensive process. Virtually all of the switching is accomplished on wire-wrapping DSX-1 panels and its demuxed from SONET, physically wired and remuxed to SONET at every stop. I'm not talking RJ45 patch cables here; I'm talking individual bare wires wrapped around a metal post.
As a result, not only do T1s cost more to provide than a PON service like FiOS, they're less reliable as well. The only good reason to buy an Internet T1 these days is if you're in a location where you can't get anything better.
Badfrog's question speaks for itself; it needs no rephrasing or clarification.
Your economic theory leaves a little to be desired as well. Cost constricts supply. As price approaches cost, supply dwindles until it stabilizes at a level meeting demand -- above cost. Price might briefly dip below cost in order to exhaust inventory, but T1's are a service: there is no inventory.
Take for example: dirt. Everybody has dirt. Nobody wants dirt. Demand/supply, the price should be zero. So go try to tell the garden department at Home Depot that you want them to give you free dirt. Didn't quite work out that way, did it?
By the same definition you'd have to call a voip phone a server because it can answer an incoming call.
Actually, that depends on the implementation.
Technically, systems like Vonage initate an outbound UDP link to the call manager in order to open a path through the (presumed) NAT firewall so that when a call comes in the packets from the call manager can get back to it. When plugged in, the phone (client) opens a connection to the call manager (server). At some future time, the call manager (server) advises the phone (client) over that connection that a call has arrived. The phone (client) then opens a new connection to the gateway (server) to process the call. And the phone rings.
Its a push technology, like pointcast, but still very much client-server.
And then there's Skype. Skype doesn't work this way; Skype is peer-to-peer. The Skype phone is a server that expects other phones to connect to it and a client that expects to open connections to the other Skype phone servers.
And it is not just a pedantic point.
Yeah, it really is. And your email example is bogus too: if I return those emails, I do it by connecting back to an email server. The email server doesn't connect to me.
I don't think there is any good technical or legal definition of what a "client" and "server" computer are.
Try this one: If I can remotely connect to your computer and induce it to perform a non-trivial function at my convenience, its a server.
We firewall jockeys even have a precise technical definition: If your machine accepts a SYN packet and responds with a SYN/ACK, or if your machine expects to receive the first in a series of UDP packets on a particular port, its a server.
Didn't Ohio University already have a policy against students placing servers on the Internet? Hello! When you run P2P, you're running a server!
If you have an interesting take on a subject that invalidates one of my approaches to problem solving, I'd like to hear that viewpoint in detail so I can modify or if necessary scrap my approach. Meaning no offense, but if that's not a challenge you can rise to then your opinion about the breadth of my horizons matters less to me than the grains of sand stuck in the tread on my shoe.
Vacuum tubes are expensive because its hard to make a vacuum tube that has any degree of reliability. The fact that transistors do the same job and cost dirt has little impact on the difficulty or cost of making vacuum tubes.
T1s are expensive for the same reason. The 15 meg FiOS service at my house actually costs Verizon a lot less to build and maintain than the multiply repeated 1.5 meg T1 that preceeded it.
That's a curious assertion. Describe if you would this process-free cycle of inspiration, hypothesis and experimentation that leads to valid physics theory.
Every endeavor which is neither purely random nor purely subjective can be usefully described in terms of the process it follows. I defy you to offer even a single example of a specific, concrete activity for which this is not true.
You don't have to understand a process to follow it. Most people don't. You can get useful results without every realizing that the way you learned to do things constitutes a process. But if you do understand that you're actually following a process, you can look for divergence and often spot errors which would otherwise be very abstruse.
Consider, for example, a road-bridge problem. Traffic regularly gets snarled with accidents where a particular highway crosses the river, so authorities lower the speed limit on the bridge. But this is exactly the wrong answer. Traffic is a process. The capacity of a highway is the number of lanes times the average speed of the cars. Traffic gets snarled there because the drivers already slow down to cross the bridge, reducing the capacity of the road... which in heavy traffic slows cars behind them, reducing the capacity of that stretch of road, and on back until traffic is sparse enough that the person behind doesn't slow down. Then the accidents happen because the tightly packed traffic offers fewer recovery options as drivers make the normal rate of mistakes.
To improve safety in this situation, authorities should have INCREASED the speed limit just around and on the bridge. That would maintain the road's capacity as it crossed the river so that traffic doesn't snarl, reducing the accident rate to levels normal for other stretches of the road.
You'd never spot that error or find the correct solution without first understanding the process.
I have no snappy comeback for that bit of folk wisdom. Clearly as a computer scientist I can't possibly tell the diference between good and bad process design in physics.
The only reference I found in the first couple google pages for "petr beckmann relativity" that wasn't a total fluff piece was this old 1990 article from National Review: http://www.encyclopedia.com/doc/1G1-9046912.html
So if I'm reading this right, one consequence of his assertion is that the time dilation predicted by relativity is a bunch of bunk that doesn't really happen. Correct me if I'm wrong, but hasn't time dilation been verified experimentally?
So, fill me in. What's happened in the last 17 years to confirm or refute Beckmann's claim? And why isn't it the first link on Google?
No no... That you're willing to OVERCOME an unbounded amount of bureaucratic b.s. in order to obtain a goal. Very important quality in an applicant.
Computer Science is hardly a good vantage point to judge the rest of science from.
Perhaps, but its a fine vantage from which to judge process-oriented inaccuracy and dishonesty: computers are absolutely ruthless to the purveyors of either so good developers learn how to spot things the computer will choke on.
It is with that eye for process that I look at Quantum Physics and find it wanting.
They neglected to mention the median salary for the positions they're trying to fill. Most reports lamenting the lack of available IT talent do. Perhaps they learned a lesson from the regular complaints about the lack of qualified teachers which are routinely riposted with a complaint about the lack of qualified teacher salaries.
That's an insteresting take on the matter.
My own background is computer science. In computer science we have basically two categories of software functions: those which produce the correct answer and those which produce a usefully good answer. We consider the difference between the two to be of such pivotal importance that we assign different labels: algorithm and heuristic.
Epicycles was a useful heuristic. Given a timestamp it provided a useful approximation of the position of the planets in the night sky. If Quantum Physics' standard model only offers similarly useful heuristics then perhaps physiscists should label them as such, not elevate them to the same status as Relativity's proven algorithms. Perhaps they should even describe quantum physics in terms of, "These equations offer the best known approximation of reality's observed behavior," instead of the more conceited, "this is what reality is."
Quantum Mechanics is the only game in town.
Epicycles was the only game in town from the 3rd century all the way through the 16th... until Copernicus came along with the correct explanation for the data and made 1300 years of scholars look like raving lunatics.
How then could Epicycle's proponents have known they were headed down a blind alley? Simple really: instead of proving it outright, each major new dataset required more refinements and additions to the theory -- Epicycles within Epicycles.
Quantum Mechanics has had nearly a century to stabilize in to a theory that each new experiment proves without needing additional refinements. Instead it has added a bazillion particles, spins, counter spins and all sorts of other oddities. It hasn't stabilized and each new addition makes the theory less likely to be correct.