Verizon's official line is that it is "easier" to work in the Suburbs; possibly true, but in the city, you have 10-50 times the customers for any given block; even if you have to hire 2x the crews to finish the job faster, hire police details, pull more permits...you'd still make your money back faster.
I suppose that one possibility is that Verizon is making shit up. The other possibility is that you're wrong and their number crunchers are right. Running infrastructure in urban areas costs a fortune. A number of companies did it during the dotcom bubble, and most of them are gone now (couldn't begin to recover the costs). When Verizon ran FIOS in my neighborhood they did about 1800 homes in about a week. Most of the fiber was run under grass, and only really had to worry about other utilities when they crossed a street. (Which was done from the grass on the side of the street, no digging.) To do the same in downtown Boston you're going to be cracking pavement, and you're going to be doing that every time you bring a new customer online. (When I got mine they augered a fiber underground from the distribution node in the middle of my block--again, no shovels and no underground utilities on that side of the structure.) The other option is to run it overhead, but everybody hates that, and verizon is trying to lower its maintenance costs with this deployment, not raise them.
Perhaps my circle of regular correspondence is small enough
Perhaps. I get a whole lot of legitimate email, on a wide variety of topics. If you've got a small circle of correspondents with limited interests, then the bayes approach might work (of course, a whitelist would work in that case also, with less overhead).
My points are this: 1) I still don't buy the 'bayes filters have been defeated' argument
So it works for you--whoopy. As a general solution it isn't viable. Whether you "buy" that is immaterial--I've got the spam to prove it.
and more to the point, 2) I think we can agree the proposition by the submitter, that we are all at the mercy of spammers and so must instantly notice any change in tactics or frequency, is certainly FUD.
Nope. I went from about 0 spams in the inbox to 5-10 a day due to image spam almost overnight, and I had to start running an OCR scanner over all my incoming mail. Sounds to me like I had to respond to changing tactics.
Several posts in this thread are making the same claim, that Bayesian filtering has been solved by the spammers. Is there any support for these claims?
I use SpamBayes with Outlook and find it about 99 and 44/100 % effective.
I get approximately 1000 spams per day. At 99.44% I'd get an average of 5.6 spams in my inbox every day. I'm actually doing better than that, but bayesian techniques aren't the reason (the random message spam and the text-pulled-from-gutenburg spam and the image spam is flying right past the bayes filter). I knew when I first saw the bayes technique that it wasn't going to work for long; I'm actually surprised that it took this long for the spammers to begin working around it on a large scale. (greylisting is the next method that's a very short term fix--there's no reason that bot nets can't retry.) If you haven't gotten bayes-avoiding spam yet you're just lucky. That said, the best approach is a blended one--I still get a few messages for which bayesian filtering is the only thing that flags the message as spam.
If you can't get consistent, reliable results out of it, it doesn't work (period).
If that is the case, nothing works. Everything has some rate of failure. If lie detectors are unreliable, all it means is that they will serve as an indication, rather than the be-all-and-end-all of the truth.
"Consistent and reliable" is not the same as completely accurate. It does imply a higher bar than "does something", especially if it isn't possible to distinguish between valid and invalid results.
Your method, if well tested, would come up with about 50% reliability, correct? Since there are two options, and the results are evenly spread, it doesn't even indicate slightly whether or not they are lying.
Yeah, that's the point. Even a random method method will "work" some of the time, but it's still fair to say that the method doesn't work.
If I were to invent a machine for that purpose which I'd call, say, a polygraph, and it had, say, a 75% success rate
Can you point to a valid study which demonstrates that kind of success rate over the success rate of a skilled interrogator without the polygraph?
They do work. Not for everyone in every situation, but it's not enough to say they just don't work, period.
No, that's enough for any sensible conversation. The long version would be: can you point to any scientifically valid study which demonstrates that the results from a so-called "lie detector" are reliable? If you can't get consistent, reliable results out of it, it doesn't work (period). If I design a method to detect whether people are lying, which consists of flipping a coin for each answer and flagging answers corresponding to "heads" as lies, it will certainly correctly identify some lies. I suppose that since it does work, just not for everyone in every situation, you'd argue that it would be unfair to say it doesn't work?
Am I the only one who wishes vendors would just use unambiguous numbers instead of obfuscating their specs with weird acronyms? I'd much rather compare a 1440×900 to a 1600×1024 than a WSXGA to a WSXGA (yes, the vendors aren't so helpful as to use consistent nomenclature). Quick, which is better: QUXGA or WSXGA+? I can't even read video display ads anymore without a secret decoder ring handy.
VDSL will still require fiber from the CO to the curb. Laying all that fiber would be expensive.
The really interesting thing is that FTTP the actually rolling out. I'm now on a 15Mbps fiber connection provided by my local telco. And the theoretical limit of that fiber is a lot higher than 15Mbps, so I'd expect increases as the backbone is upgraded.
While Wifi and WiMAX are what most expect to be the future, how long will it be before small rural towns are 100% accounted for? If the goal is to give EVERYONE the option of having internet access in their town, BPL is probably the most intelligent option.
Not really. First, BPL doesn't exist anywhere, so there's still a lot of early adopter money to be wasted. Wireless solutions have been running in the real world for years now. Second, BPL still requires people to go around in trucks and put equipment up on poles. People seem to think that since it uses existing equipment it must not require any more stuff to be installed--and that's just not true. If someone's going to be up a pole installing something I'd rather it not be a flakey solution that kills the spectrum for other uses.
Really though, what the hell has the internet got to do with the wingflapping guys?
Well see, we have these places where all the planes and bombs are... they are called "air force bases", and at these bases, they do alot of research on, ya know, planes and bombs... and alot of these secrets are very important and held on computers in varying levels of connectivity
And this differentiates the air force from the army or navy--how? I think the original point was that there's no clear reason for this to be an air force mission. If anything, the army has more computing resources than the air force.
Columbus spent a lot of money trying to find a new trade route to the far east and discovered something far more important, America. The sensible thing might have been to stay home but in the end would have cost Spain countless millions in lost revenue from the find.
I'm not sure that's the best example, since the gold Spain looted from the Americas financed the European wars and dynastic conflicts that wrecked the country to the point that they're still feeling the effects. They probably would have been better off not giving Columbus any money.
That was rather my point. If the students couldn't "afford" to pay the tuition, they wouldn't go. But, because there are fixed and variable costs (quite huge, actually) in running a university, if those students can't fork over $30k/year, those universities won't exist. The government subsidies are there not as "easy money," but as an effort to ensure we have an educated population that can increase production.
So the possibility that the university could make its expenses match its revenue doesn't even exist in your world? In the current environment there is no pressure at all for universities to keep their expenses low because students will spend whatever they're asked to, using loans and gov't subsidies to pay for it. There is no forseeable end to the cycle of tuition increases unless there is some pressure (like an end to subsidy increases) to encourage the universities to become more efficient.
And no, there is no good reason that university tuition increases should greatly exceed the inflation rate except that they can.
I'll reply to you since you're the only one who seems to have even read the quoted GP and understood that the subject under discussion was OEMs integrating software (as opposed to the illiterates who thought the subject was computers or cars shipped completely without essential components).
I think your analogy is off by one level. MS isn't the manufacturer, MS is a supplier--like the supplier of the hard disk or a car's steering wheel. The manufacturer/integrator is Dell or HP or whoever puts the OS into the box along with the case and the hard disk. The dealership is the person who sells you the computer. If you go to Best Buy, that's your dealer. The dealer could offer add-ons, but the box they get from the manufacturer would have a complete system. The only difference from the current system would be that one company wouldn't control most aspects of the software configuration that comes in the box, offering the manufacturers greater ability to compete on price or features. In other market segments a supplier doesn't get the kind of deference or control MS does--that's a symptom of a dysfunctional system.
Imagine an OEM having to supply alternatives to all of these things. Buying the replacements from third parties, or including crippled versions of full products, or using opensource alternatives where they exist. Imagine every OEM doing this, and choosing different products. Imagine sitting down infront of a computer and no longer having a guaranteed set of tools to work with - different browser, email client, file explorer etc.
Imaging buying a new car and finding that every manufacturer has slightly different arrangments for the controls. Maybe the radio buttons are different, or the lights, or the windshield wipers. Maybe the window controls are arranged differently, or the cruise control. How would you cope with that? Could consumers figure out how to drive if 90% of the cars on the lot didn't have exactly the same interface?
We tried to come up with a methodology to give people insight into the challenges they might run into before they do an enterprise deployment. In the experiment, you've got the assumptions we started with
In another followup I already explained why your constraints were fundamentally flawed. I guess there's some value in knowing your methodology & assumptions, but since they were poorly chosen there's not all that much value. For all that you want to talk about the importance of methodology the reality is that "a methodology" is insufficient--the methodology must be reasonable.
I guess the key takeaway for me is that given three experienced linux admins we got three really different results.
The takeaway for me is that if you artificially remove the simple and obvious solution (upgrading the OS to a coherent, supported level) you'll get a lot of oddball suboptimal solutions. That's not all that revelatory, in my opinion. Really, what kind of results do you think you'd get from three windows admins told "run this longhorn program on windows xp, and don't even think about upgrading windows (though you can copy files from this longhorn cd)". Is there a chance that you'd get three really different results? Is there a chance that endstate isn't correlated to OS so much as to insane preconditions?
Answer: Good point! The only configuration control issue was that the enterprise wouldn't upgrade the OS version until July 1, 2005. This is mainly based on our experience with companies that don't move to the latest OS version until it has had time to "bake" in the community. At that time, SLES 9 was hot off the compiler.
This is really where you lose all credibility. You set a ridiculous conditition: "run this software without upgrading the OS to a version that it will run on". As much as you try to wrap it in important-sounding ideas of "enterprise configuration control" (should the word "enterprise" make the idea more sacrosanct or something?) the fact remains that it was a stupid, unreasonable condition. You'd run into the exact same problem on a windows machine if you had a piece of software that required windows XP but your "enterprise configuration control" mandated windows 2000. You'll get further on linux by upgrading glibc than you would trying to pick pieces out of XP to upgrade 2000, but the bottom line is that you're trying to do an upgrade without calling it an upgrade. It would be more effective (and no more duplicitous from a configuration-control perspective) to upgrade to suse 9 and change the login banner to make the system claim to be running suse 8. Once you've started ripping out fundamental system libraries you've already destroyed your "enterprise configuration control" and to claim otherwise as a rationalization for rejecting a technically competent solution is intellectually dishonest.
Having written ASN.1 parsers/emitters, I'd have to say this isn't the best example to illustrate an otherwise valid point about sanity-checks.
Given the fact that there have been major parsing errors in common ASN.1 libraries I'd say that it's a very good example.
As a consequence of this, ASN.1 reader/writer code tends to be very 'length-aware' by nature. Buffer overflow exploits are the least of your problems if you get the lengths wrong on ASN elements - the larger problem will be that your ASN.1 file will be unreadable by any ASN.1 parser.
Ah, you're commiting the classic error of "it handles valid input properly, so it must be ok".
We did the space program and got something out of it. If we hadn't done the space program we MIGHT not have got something out of it. 100% chance of something is better than 100% chance of something.
As I said, your position reduces to just about nothing.
It's possible that the money might have been spent on an unknown "X" that is far better than LCD technology. But it's also possible it could have been squandered and nothing beneficial coming out of it at all.
That sword cuts both ways. Can you say with a straight face that government programs never squander money? Can you claim that non-government R&D never produces new products? Your proposition reduces to: "something good came from the space program. other good things came from outside the space program. we don't know what would come if we allocated resources differently, but we almost certainly wasted some of the money." In itself, this chain of logic doesn't lead anywhere. The goal is to allocate resources as efficiently as possible to achieve Good Things, and citing a Good Thing that came from a particular program doesn't explain how to efficiently produce more Good Things.
Reiser solves one of the oldest problems facing the old Unix-style filesystem: the adoption of btree-order performance directory lookups (using Reiser's "dancing trees") without significant loss in other areas of filesystem performance, e.g. directory entry creation and deletion, etc. This is something which was long thought impossible.
In the real world, it turns out to have made the filesystem slower for large file performance. (Which is unsurprising.) reiser4 supposedly addresses that (and since addressing it was a goal, don't try to pretend it's not real) but only time will tell how the balance of the new filesystem works in the real world. I don't expect to see real data on that for another 2-4 years (until it's far enough out of beta for wide deployment).
The problem with Reiser is that it is Reiser, and none of the exisiting filesystems can match its performance in these areas. That means that if you write an application that relies on Reiser's performance, it really RELIES on Reiser, and cannot perform well under normal filesystems without significant engineering
That's mostly true, but not quite for the right reason. The reality is that Reiser (the guy) doesn't really care about having a traditional filesystem. The thing that he's written supports filesystem semantics, but what he really wants is to rip up the traditional model for interacting with a filesystem and have people use new semantics for managing their data. It's not the performance of other filesystems that keeps people from using reiserfs for that, it's the fact that their app would then depend on semantics that don't exist on any other filesystem. The set of people who want to write reiser-only applications is vanishingly small.
In some cases (e.g. databases) this might be worthwhile,
No, for databases it would be useless because databases already have that functionality. There's no win for a database to throw out existing working code and replace it with (buggy, since new) code that only runs on a subset of a single platform for no appreciable gain. Where it might be worthwhile is for desktop type applications (user data management) but that's exactly the kind of app that needs to run on a naive user's computer without requiring their disk to be formatted with an unusual filesystem.
If I want a disc of music on a RIAA member label I make sure I purchase a previously owned CD of it instead of a new one.
That's great, but then the artist doesn't get any money either. I want to pay for music because I want to remward the artist.
The value to me (the justification for parting with my cash) is that I want to reward the artist.
Fine. Take a crisp new dollar bill, put it in an envelope, and send it to the artist. Pay $5 for the used CD. The artist gets at least as much take as he would have from the industry, and you get an extra $14.
Most of us do not make our decisions, especially the fundamental cultural choices that define who we are (and where we live), with a matrix of variables and a calculator. Those of us who live in New Orleans love the city for reasons that would doubtless escape someone as soullessly critical as the parent.
That's all fine--as long as you pay for it yourself.
So, I guess that you'll make an exception and pay real quick like to keep the oil infrastructure disaster coverage federalized?
No, of course not. The oil companies have plenty of financial incentive to rebuild, and the capital to do so.
OK, then, what about the roads, bridges, and rail that lead to the oil refineries? OK, then, what about the destroyed schools that give enough (sometimes, *only* enough) education to local people so that they can work on the oil infrastructure - should the feds not pay to help rebuild that?
Slashdot Mirror
I suppose that one possibility is that Verizon is making shit up. The other possibility is that you're wrong and their number crunchers are right. Running infrastructure in urban areas costs a fortune. A number of companies did it during the dotcom bubble, and most of them are gone now (couldn't begin to recover the costs). When Verizon ran FIOS in my neighborhood they did about 1800 homes in about a week. Most of the fiber was run under grass, and only really had to worry about other utilities when they crossed a street. (Which was done from the grass on the side of the street, no digging.) To do the same in downtown Boston you're going to be cracking pavement, and you're going to be doing that every time you bring a new customer online. (When I got mine they augered a fiber underground from the distribution node in the middle of my block--again, no shovels and no underground utilities on that side of the structure.) The other option is to run it overhead, but everybody hates that, and verizon is trying to lower its maintenance costs with this deployment, not raise them.
I think that says it all. In the science vs mysticism continuum, polygraphs fall on the latter end of the scale.
Perhaps. I get a whole lot of legitimate email, on a wide variety of topics. If you've got a small circle of correspondents with limited interests, then the bayes approach might work (of course, a whitelist would work in that case also, with less overhead).
So it works for you--whoopy. As a general solution it isn't viable. Whether you "buy" that is immaterial--I've got the spam to prove it.
Nope. I went from about 0 spams in the inbox to 5-10 a day due to image spam almost overnight, and I had to start running an OCR scanner over all my incoming mail. Sounds to me like I had to respond to changing tactics.
I get approximately 1000 spams per day. At 99.44% I'd get an average of 5.6 spams in my inbox every day. I'm actually doing better than that, but bayesian techniques aren't the reason (the random message spam and the text-pulled-from-gutenburg spam and the image spam is flying right past the bayes filter). I knew when I first saw the bayes technique that it wasn't going to work for long; I'm actually surprised that it took this long for the spammers to begin working around it on a large scale. (greylisting is the next method that's a very short term fix--there's no reason that bot nets can't retry.) If you haven't gotten bayes-avoiding spam yet you're just lucky. That said, the best approach is a blended one--I still get a few messages for which bayesian filtering is the only thing that flags the message as spam.
"Consistent and reliable" is not the same as completely accurate. It does imply a higher bar than "does something", especially if it isn't possible to distinguish between valid and invalid results.
Yeah, that's the point. Even a random method method will "work" some of the time, but it's still fair to say that the method doesn't work.
Can you point to a valid study which demonstrates that kind of success rate over the success rate of a skilled interrogator without the polygraph?
No, that's enough for any sensible conversation. The long version would be: can you point to any scientifically valid study which demonstrates that the results from a so-called "lie detector" are reliable? If you can't get consistent, reliable results out of it, it doesn't work (period). If I design a method to detect whether people are lying, which consists of flipping a coin for each answer and flagging answers corresponding to "heads" as lies, it will certainly correctly identify some lies. I suppose that since it does work, just not for everyone in every situation, you'd argue that it would be unfair to say it doesn't work?
Am I the only one who wishes vendors would just use unambiguous numbers instead of obfuscating their specs with weird acronyms? I'd much rather compare a 1440×900 to a 1600×1024 than a WSXGA to a WSXGA (yes, the vendors aren't so helpful as to use consistent nomenclature). Quick, which is better: QUXGA or WSXGA+? I can't even read video display ads anymore without a secret decoder ring handy.
The really interesting thing is that FTTP the actually rolling out. I'm now on a 15Mbps fiber connection provided by my local telco. And the theoretical limit of that fiber is a lot higher than 15Mbps, so I'd expect increases as the backbone is upgraded.
Not really. First, BPL doesn't exist anywhere, so there's still a lot of early adopter money to be wasted. Wireless solutions have been running in the real world for years now. Second, BPL still requires people to go around in trucks and put equipment up on poles. People seem to think that since it uses existing equipment it must not require any more stuff to be installed--and that's just not true. If someone's going to be up a pole installing something I'd rather it not be a flakey solution that kills the spectrum for other uses.
I don't recall ever having to justify a request for a book when I was in school. Did you matriculate at Big Brother University?
And this differentiates the air force from the army or navy--how? I think the original point was that there's no clear reason for this to be an air force mission. If anything, the army has more computing resources than the air force.
I'm not sure that's the best example, since the gold Spain looted from the Americas financed the European wars and dynastic conflicts that wrecked the country to the point that they're still feeling the effects. They probably would have been better off not giving Columbus any money.
So the possibility that the university could make its expenses match its revenue doesn't even exist in your world? In the current environment there is no pressure at all for universities to keep their expenses low because students will spend whatever they're asked to, using loans and gov't subsidies to pay for it. There is no forseeable end to the cycle of tuition increases unless there is some pressure (like an end to subsidy increases) to encourage the universities to become more efficient.
And no, there is no good reason that university tuition increases should greatly exceed the inflation rate except that they can.
I'll reply to you since you're the only one who seems to have even read the quoted GP and understood that the subject under discussion was OEMs integrating software (as opposed to the illiterates who thought the subject was computers or cars shipped completely without essential components).
I think your analogy is off by one level. MS isn't the manufacturer, MS is a supplier--like the supplier of the hard disk or a car's steering wheel. The manufacturer/integrator is Dell or HP or whoever puts the OS into the box along with the case and the hard disk. The dealership is the person who sells you the computer. If you go to Best Buy, that's your dealer. The dealer could offer add-ons, but the box they get from the manufacturer would have a complete system. The only difference from the current system would be that one company wouldn't control most aspects of the software configuration that comes in the box, offering the manufacturers greater ability to compete on price or features. In other market segments a supplier doesn't get the kind of deference or control MS does--that's a symptom of a dysfunctional system.
Imaging buying a new car and finding that every manufacturer has slightly different arrangments for the controls. Maybe the radio buttons are different, or the lights, or the windshield wipers. Maybe the window controls are arranged differently, or the cruise control. How would you cope with that? Could consumers figure out how to drive if 90% of the cars on the lot didn't have exactly the same interface?
In another followup I already explained why your constraints were fundamentally flawed. I guess there's some value in knowing your methodology & assumptions, but since they were poorly chosen there's not all that much value. For all that you want to talk about the importance of methodology the reality is that "a methodology" is insufficient--the methodology must be reasonable.
The takeaway for me is that if you artificially remove the simple and obvious solution (upgrading the OS to a coherent, supported level) you'll get a lot of oddball suboptimal solutions. That's not all that revelatory, in my opinion. Really, what kind of results do you think you'd get from three windows admins told "run this longhorn program on windows xp, and don't even think about upgrading windows (though you can copy files from this longhorn cd)". Is there a chance that you'd get three really different results? Is there a chance that endstate isn't correlated to OS so much as to insane preconditions?
This is really where you lose all credibility. You set a ridiculous conditition: "run this software without upgrading the OS to a version that it will run on". As much as you try to wrap it in important-sounding ideas of "enterprise configuration control" (should the word "enterprise" make the idea more sacrosanct or something?) the fact remains that it was a stupid, unreasonable condition. You'd run into the exact same problem on a windows machine if you had a piece of software that required windows XP but your "enterprise configuration control" mandated windows 2000. You'll get further on linux by upgrading glibc than you would trying to pick pieces out of XP to upgrade 2000, but the bottom line is that you're trying to do an upgrade without calling it an upgrade. It would be more effective (and no more duplicitous from a configuration-control perspective) to upgrade to suse 9 and change the login banner to make the system claim to be running suse 8. Once you've started ripping out fundamental system libraries you've already destroyed your "enterprise configuration control" and to claim otherwise as a rationalization for rejecting a technically competent solution is intellectually dishonest.
Man, you must not know many purchasing managers.
Given the fact that there have been major parsing errors in common ASN.1 libraries I'd say that it's a very good example.
Ah, you're commiting the classic error of "it handles valid input properly, so it must be ok".
As I said, your position reduces to just about nothing.
That sword cuts both ways. Can you say with a straight face that government programs never squander money? Can you claim that non-government R&D never produces new products? Your proposition reduces to: "something good came from the space program. other good things came from outside the space program. we don't know what would come if we allocated resources differently, but we almost certainly wasted some of the money." In itself, this chain of logic doesn't lead anywhere. The goal is to allocate resources as efficiently as possible to achieve Good Things, and citing a Good Thing that came from a particular program doesn't explain how to efficiently produce more Good Things.
In the real world, it turns out to have made the filesystem slower for large file performance. (Which is unsurprising.) reiser4 supposedly addresses that (and since addressing it was a goal, don't try to pretend it's not real) but only time will tell how the balance of the new filesystem works in the real world. I don't expect to see real data on that for another 2-4 years (until it's far enough out of beta for wide deployment).
That's mostly true, but not quite for the right reason. The reality is that Reiser (the guy) doesn't really care about having a traditional filesystem. The thing that he's written supports filesystem semantics, but what he really wants is to rip up the traditional model for interacting with a filesystem and have people use new semantics for managing their data. It's not the performance of other filesystems that keeps people from using reiserfs for that, it's the fact that their app would then depend on semantics that don't exist on any other filesystem. The set of people who want to write reiser-only applications is vanishingly small.
No, for databases it would be useless because databases already have that functionality. There's no win for a database to throw out existing working code and replace it with (buggy, since new) code that only runs on a subset of a single platform for no appreciable gain. Where it might be worthwhile is for desktop type applications (user data management) but that's exactly the kind of app that needs to run on a naive user's computer without requiring their disk to be formatted with an unusual filesystem.
Fine. Take a crisp new dollar bill, put it in an envelope, and send it to the artist. Pay $5 for the used CD. The artist gets at least as much take as he would have from the industry, and you get an extra $14.
That's all fine--as long as you pay for it yourself.
No, of course not. The oil companies have plenty of financial incentive to rebuild, and the capital to do so.
Nope, that's local government.