Your ISP made promises of a certain amount of bandwidth at a certain price based on how much they expected the average user to use during peak times.
And instead of putting those usage levels into some sort of wording in the contract, they took the levels, multiplied by some value, built the network to that level (we hope), and then advertised "unlimited"...
Net neutrality legislation would not allow ISPs to a: shift costs onto content providers who are changing average usage rates
No way. The ISP doesn't get to charge the guy 6 hops away. I pay my bill (to an ISP), Google pays their bill to their ISP. All of the ISPs in the middle have their own peering arrangements. The ISP next to Google's would have a cause to charge Google's ISP more based on the volume of traffic coming from Google's ISP. Not because Google specifically is handling more traffic, but simply because of Google's ISP handling more traffic.
As you have presented it, yes you are "wrong" under the definition of net neutraility that I prefer. (It seems you prefer the definition of pass all bits equally, which is probably an equally reasonable definition of net neutrality.) They're being source and destination agnostic, and doing traffic prioritization based on protocol. What you haven't said they're doing is prioritizing their own VoIP over general VoIP. That would be non-neutral.
SIP/Asterisk gets pretty cool for this. You could have your asterisk box route all hidden caller id calls directly to voicemail. Or to an IVR menu which asks for a password (and if that fails, voicemail). Continuing with this, "bad" caller id numbers can be immediately dropped, "good" caller id passes through unchanged.
Two weeks? My RRoD took them 2 months. First their online system lost my repair request. Then I called them and got the email that says my repair's been registered, but never got the shipping label to send them my unit. Then we arranged to have them ship me a box, which didn't arrive. Then a second box which finally did arrive.
No, no, no. Opt-in is the way it should work. It's only opt-out because of the hassle it takes to actually opt-out, and it depends on the general ignorance of the people that they won't be properly informed that they're even paying this extra tax and that it's possible to opt-out. With these two issues, they would get a huge "sign-up' to this scheme.
That's only one end of the scale. What are the other reference points for Fahrenheit? For Celsius, you have 0 == freezing, 100 == boiling for pure water. For Fahrenheit you have 0 == freezing saltwater, 32 == freezing pure water, and 212 == boiling pure water. According to Wikipedia, that isn't even the original Fahrenheit scale.
Exactly. I'm always amazed by people who think that writing impenetrable code is "advanced". Any jackass can write something convoluted and obscure that nobody else can understand (or maintain) -- what takes actual talent is condensing complicated logic into code that's simple enough a ten year old would understand it.
I'm reminded of two quotes.
One from Einstein: "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
The second from Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
So if you initially cooperate, you can no longer claim 5th amendment protections? Hmm... you "initially cooperated" with the police when you said what your name was. You can no longer claim the 5th amendment. Slippery slope anyone? (Good thing I'm not American)
Here's a challenge: try to run a Windows program that ran on Windows NT on the DEC Alpha on your beautiful, shiny Windows 2000/XP/Vista. Can't do it? Hm. Weird.
Yep.. The three byte MAC address prefix may be an otherwise unused vendor in the network, plus there may be MAC-based ACLs on the switch ports. (Although a 73+ port switch is kinda big... I guess they could be two stacked 48-port switches...)
Every CPU cycle that the "OS" uses is stealing cycles from processes that could be doing productive work for me. So yes, OSes can be slimmer. Regardless of how much memory or CPU exists. The attitude of "eh, we've got 4 GB of RAM" is why we have such bloated OSes and applications to begin with.
As for your suggestion about a distribution with all settings in a database. It's called the Windows Registry, and we all know how well _that_ works.
I mean the TFA that in essence claims that because an expert may be wrong, any probability the expert assigns to a risk can be ignored and inflated by as much you feel like it. Talk about bias.
Bias? Hype, maybe. Actually, this does make some sense, IMO. Say I was offering to shoot an apple off the top of your head and I told you I'd calculated there was only a 1 in 1 million chance of the bullet hitting you instead. Now if you knew (somehow) that there was a 1 in 10 chance I'd gotten the calculation wrong, you're going to look at it as more of a 1 in 10 chance of getting hit... or at least way more than one in 1 million.
Not necessarily. That's only a 1 in 10 chance that I'd gotten the calculation wrong. What's the probability that the "error" that I made meant that the probability of you getting hit is now 1 in 10 million?
Because the government is requiring the broadcasters to stop using analog? This isn't voluntary on the part of the broadcasters. Because if it was, theoretically some would continue to broadcast in analog to service those users remaining, which would leave a choice for people. The government is requiring a path that has no choice.
Sure... but take this to the logical conclusion (yeah, I know... logic + law = NaN), if there's a problem with surreptitious photos being taken by a device that doesn't look like a camera, what about surreptitious video? And what if I shoot a video that happens to only be 1 frame long? And why restrict it to cell phones? Why not anything that doesn't look like a camera? Then again, what does a camera look like? To some people, a cell phone looks like a camera too.....
Does this apply to _all_ cameras? Security cams, webcams, etc? What about cell phones taking videos? Do they now have to play a whirring sound so that people know that the video camera is running (and then back to security cams, web cams, etc)?
3) Microsoft spends one hour fixing bug (assuming documentation and source control and test of fix)
You forgot steps 4+ which involve days of work with marketing and other departments in order to communicate with customers and the actual deployment of the fix. Plus other intangibles
Now lets look at that timeline with TDD:
1) Microsoft writes method (let's say one hour again)
Bzzt. Wrong. You write the test first.
2) Microsoft writes test for method. Test includes random dates but not December 31st, 2008. One hour.
Another problem. You write the test to cover all of the edge cases. There are no real random dates in there. The rest of your points just don't happen. Unless you fouled up writing your tests in the first place. So let's assume 2 hours.
Many TDD proponents would write the test first, and then code to it - which is just the kind of thinking that lets you relax when you should be at your most vigilant, actually writing the code that does the work.
You're supposed to write the tests first. However this allows you to write code without the concern of not missing critical functionality. If it were critical, there would be a test for it.
I find it a lot easier to consider possibilities when I am staring at a piece of code that does some work as opposed to compiling and coding a list of potential issues into a test.
Known as coding by the seat of your pants. One point of TDD is that one considers what the code is supposed to be doing first, then expressing it. Not trying to figure it out as you go.
Another potential issue is that tests tend to be written by the programmer who produced the original code,
Ahem. TDD is that you're supposed to have the tests before the code, not after. And if you're attempting to apply this to code which isn't built with TDD, then you may write some tests to cover the current behaviour (not necessarily the code), and then write new tests to exercise whatever new functionality and/or but that has been discovered.
and of course the natural urge is to produce tests that fit the code as is, since the general thinking is to prevent bugs from future changes. I'm a huge believer (from experience) in the value of having a QA department that does nothing but write test code and makes sure the code always passes that. It works far better than programmers managing code and really produces quality efforts. Unfortunately it has the same ossifying effect where refactoring is harder as you go along because tests must be altered along with code.
Yep... QA is good. And hopefully populated with people who have a knack for and/or enjoy writing test code. We've got a guy who if he looks at the computer wrong your program explodes. And much like our QA processes, the guy who claims a bug is fixed cannot be the person to verify it's fixed. Same here, the guy writing the functionality shouldn't be the guy writing the tests.
Slashdot Mirror
Your ISP made promises of a certain amount of bandwidth at a certain price based on how much they expected the average user to use during peak times.
And instead of putting those usage levels into some sort of wording in the contract, they took the levels, multiplied by some value, built the network to that level (we hope), and then advertised "unlimited"...
Net neutrality legislation would not allow ISPs to a: shift costs onto content providers who are changing average usage rates
No way. The ISP doesn't get to charge the guy 6 hops away. I pay my bill (to an ISP), Google pays their bill to their ISP. All of the ISPs in the middle have their own peering arrangements. The ISP next to Google's would have a cause to charge Google's ISP more based on the volume of traffic coming from Google's ISP. Not because Google specifically is handling more traffic, but simply because of Google's ISP handling more traffic.
As you have presented it, yes you are "wrong" under the definition of net neutraility that I prefer. (It seems you prefer the definition of pass all bits equally, which is probably an equally reasonable definition of net neutrality.) They're being source and destination agnostic, and doing traffic prioritization based on protocol. What you haven't said they're doing is prioritizing their own VoIP over general VoIP. That would be non-neutral.
SIP/Asterisk gets pretty cool for this. You could have your asterisk box route all hidden caller id calls directly to voicemail. Or to an IVR menu which asks for a password (and if that fails, voicemail). Continuing with this, "bad" caller id numbers can be immediately dropped, "good" caller id passes through unchanged.
And for some of us, we get paid to play. I'm a programmer/designer/etc for fun, as well as being paid for it.
Two weeks? My RRoD took them 2 months. First their online system lost my repair request. Then I called them and got the email that says my repair's been registered, but never got the shipping label to send them my unit. Then we arranged to have them ship me a box, which didn't arrive. Then a second box which finally did arrive.
DOS 5... our last, best hope for peace...
No, no, no. Opt-in is the way it should work. It's only opt-out because of the hassle it takes to actually opt-out, and it depends on the general ignorance of the people that they won't be properly informed that they're even paying this extra tax and that it's possible to opt-out. With these two issues, they would get a huge "sign-up' to this scheme.
RealMedia? People still use RealMedia?
That's only one end of the scale. What are the other reference points for Fahrenheit? For Celsius, you have 0 == freezing, 100 == boiling for pure water. For Fahrenheit you have 0 == freezing saltwater, 32 == freezing pure water, and 212 == boiling pure water. According to Wikipedia, that isn't even the original Fahrenheit scale.
Exactly. I'm always amazed by people who think that writing impenetrable code is "advanced". Any jackass can write something convoluted and obscure that nobody else can understand (or maintain) -- what takes actual talent is condensing complicated logic into code that's simple enough a ten year old would understand it.
I'm reminded of two quotes.
One from Einstein: "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
The second from Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
"Longest running", or "Longest consecutive running"? Dr. Who has the total episode count, Stargate has the # of consecutive episodes.
Have you read "I, Robot"? There's a story in there that specifically talks about emotional harm...
Probably not since both parties would have to initial the amendment.
We already have that. See botnets.
Naw... I've got a Charter of Rights and Freedoms that protects that. And the way this is going.. are you sure _you_ have that right?
So if you initially cooperate, you can no longer claim 5th amendment protections? Hmm... you "initially cooperated" with the police when you said what your name was. You can no longer claim the 5th amendment. Slippery slope anyone? (Good thing I'm not American)
Here's a challenge: try to run a Windows program that ran on Windows NT on the DEC Alpha on your beautiful, shiny Windows 2000/XP/Vista. Can't do it? Hm. Weird.
Yep.. The three byte MAC address prefix may be an otherwise unused vendor in the network, plus there may be MAC-based ACLs on the switch ports. (Although a 73+ port switch is kinda big... I guess they could be two stacked 48-port switches...)
Every CPU cycle that the "OS" uses is stealing cycles from processes that could be doing productive work for me. So yes, OSes can be slimmer. Regardless of how much memory or CPU exists. The attitude of "eh, we've got 4 GB of RAM" is why we have such bloated OSes and applications to begin with. As for your suggestion about a distribution with all settings in a database. It's called the Windows Registry, and we all know how well _that_ works.
Apparently it's so private that nobody knew about it.
I mean the TFA that in essence claims that because an expert may be wrong, any probability the expert assigns to a risk can be ignored and inflated by as much you feel like it. Talk about bias.
Bias? Hype, maybe. Actually, this does make some sense, IMO. Say I was offering to shoot an apple off the top of your head and I told you I'd calculated there was only a 1 in 1 million chance of the bullet hitting you instead. Now if you knew (somehow) that there was a 1 in 10 chance I'd gotten the calculation wrong, you're going to look at it as more of a 1 in 10 chance of getting hit ... or at least way more than one in 1 million.
Not necessarily. That's only a 1 in 10 chance that I'd gotten the calculation wrong. What's the probability that the "error" that I made meant that the probability of you getting hit is now 1 in 10 million?
Because the government is requiring the broadcasters to stop using analog? This isn't voluntary on the part of the broadcasters. Because if it was, theoretically some would continue to broadcast in analog to service those users remaining, which would leave a choice for people. The government is requiring a path that has no choice.
Sure... but take this to the logical conclusion (yeah, I know... logic + law = NaN), if there's a problem with surreptitious photos being taken by a device that doesn't look like a camera, what about surreptitious video? And what if I shoot a video that happens to only be 1 frame long? And why restrict it to cell phones? Why not anything that doesn't look like a camera? Then again, what does a camera look like? To some people, a cell phone looks like a camera too.....
Does this apply to _all_ cameras? Security cams, webcams, etc? What about cell phones taking videos? Do they now have to play a whirring sound so that people know that the video camera is running (and then back to security cams, web cams, etc)?
3) Microsoft spends one hour fixing bug (assuming documentation and source control and test of fix)
You forgot steps 4+ which involve days of work with marketing and other departments in order to communicate with customers and the actual deployment of the fix. Plus other intangibles
Now lets look at that timeline with TDD:
1) Microsoft writes method (let's say one hour again)
Bzzt. Wrong. You write the test first.
2) Microsoft writes test for method. Test includes random dates but not December 31st, 2008. One hour.
Another problem. You write the test to cover all of the edge cases. There are no real random dates in there. The rest of your points just don't happen. Unless you fouled up writing your tests in the first place. So let's assume 2 hours.
Many TDD proponents would write the test first, and then code to it - which is just the kind of thinking that lets you relax when you should be at your most vigilant, actually writing the code that does the work.
You're supposed to write the tests first. However this allows you to write code without the concern of not missing critical functionality. If it were critical, there would be a test for it.
I find it a lot easier to consider possibilities when I am staring at a piece of code that does some work as opposed to compiling and coding a list of potential issues into a test.
Known as coding by the seat of your pants. One point of TDD is that one considers what the code is supposed to be doing first, then expressing it. Not trying to figure it out as you go.
Another potential issue is that tests tend to be written by the programmer who produced the original code,
Ahem. TDD is that you're supposed to have the tests before the code, not after. And if you're attempting to apply this to code which isn't built with TDD, then you may write some tests to cover the current behaviour (not necessarily the code), and then write new tests to exercise whatever new functionality and/or but that has been discovered.
and of course the natural urge is to produce tests that fit the code as is, since the general thinking is to prevent bugs from future changes. I'm a huge believer (from experience) in the value of having a QA department that does nothing but write test code and makes sure the code always passes that. It works far better than programmers managing code and really produces quality efforts. Unfortunately it has the same ossifying effect where refactoring is harder as you go along because tests must be altered along with code.
Yep... QA is good. And hopefully populated with people who have a knack for and/or enjoy writing test code. We've got a guy who if he looks at the computer wrong your program explodes. And much like our QA processes, the guy who claims a bug is fixed cannot be the person to verify it's fixed. Same here, the guy writing the functionality shouldn't be the guy writing the tests.