Google's service was offered free to their users, and it can be revoked at any time, just like all the other free Google services. Google users used the free service. The Infinite SMS application made it easy for them to do so.
It costs Slashdot money to run these servers. Are you a thief to access their web pages?
It costs Google money to host Gmail, or perform your searches. Is Firefox enabling theft because it makes Google searches easy?
Of course not. The argument seems to be that popularity, i.e., heavy use in the way it was intended to use, means that the service was being abused, is specious.
I'll second recommendations to read "Peopleware" and "Mythical Man Month". Both give a lot of insight here.
Hopefully, your team is a profit center, and not a cost center. If your team is generating the profit, then the people who make the products are Kings. All stars. You should have the goal of making the finest systems possible -- under your constraints of time and budget.
Expect the developers to keep learning; "We don't have expertise in that," should be replaced with, "we should explore XYZ".
Plan on three versions of any important system: Force them to develop prototypes; demand basic functionality within a month of starting. Then revise and replace that prototype with another, better prototype. Then plan on a final version (The Third System) that discards the stuff you didn't need.
Work to avoid heavy-weight programming. I was once hired at $240/hour to write code for a company that had a large team of developers already. I knew only slightly more about the domain than they did. Their problem: this company had allowed the developers to just examine everything to death. They hired me to help because I could actually deliver within rough deadlines.
I disagree with the concept of hiring junior programmers, unless they're just apprentices. Do you want to hire a junior surgeon to do your operation? Or hire a junior Engineer to build the bridge your wife drives? No: senior people do important work. Junior people learn how, and do less critical, separate projects.
Good, adult programmer/engineers don't need much managing, but you need them to make the product. They do need somebody to help them see the bigger picture -- but any team of two engineers can do that for each other in turn. So you're really there to service them.
Fire the jerks. Develop some standard of productivity -- even if it's lines of code + group source code reviews -- and fire the people who are clearly not fitting in.
Sorry, dmayle: a business case is more than just features and advantages. A business case should include an estimate of the costs, and some estimate of the revenues.
The problem for ISPs is that the costs are quite high, but these alleged features and advantages have almost no value because they bring almost no revenue.
The problem for users is that the costs are high (in terms of time and effort) but the advantages are, heretofore, nil. There's nothing I could do with IPv6 that I actually want to do that I can't do with IPv4.
That's exactly the point. If I have agreed to forward those packets for you, then I should definitely stick by that. We already have a judicial system capable of enforcing contracts, and I'm all for that.
Why do we need another law?
Unnecessary laws weaken necessary laws, as Blaise Pascal said.
One by one, standard router configuration commands are getting attacked as undemocratic. The "consumer advocates" wanted to argue that if you're somehow connected to my router, I should be prevented from configuring my router as I see fit!
Don't I own my own router? Why should I be forced to forward packets that I don't want to forward? Why should I be forced to prioritize or not prioritize if I don't want to?
AT&T, and every other big LEC, buys one of everything. They've got equipment and software from thousands of vendors, and this probably isn't the first filtering system they've developed.
To paraphrase an ex-Baby-Bell engineer I worked with: AT&T will probably ride this horse as far as it can, decide it's not the right horse, shoot it, then walk back to find another horse.
Sure, you can buy plenty of tape drives, but are you going to get them to work? To read the right block size? To decode the file format used by the backup tool? To possibly even deal with EBCDIC?
This archive was probably split across several tapes. I've worked with several tape systems, mostly SCSI on Linux. It's remarkably hard to get things to work consistently, even when using the simplest tools, or when using some of the nicest. By "work consistently", I mean: consistently restore files when needed. ("Nobody cares about backup. Everybody cares about restore." -- Benjy Feen)
Unless it's an exceptionally disciplined thief, I'd bet cookies to doughnuts that the tape is going to be useless. Sure, there are tape readers are out there, but the use of tape itself is almost an obfuscation technique in itself. You'd have to be a pretty-determined attacker to round up a tape machine, make it work, and figure out the encoding technique on the tape.
I'd like to suggest some other considerations related to the lid. Of course, the in many toilets, the lid-seat system requires the seat to be lowered for the lid to be lowered. So any any scenario where the seat is up, the lid is up.
The cost of distributing contamination by flushing with the lid up. Charles Gerba from the University of Arizona is well known for comments on this; here's a popular media link to an article about this phenomenon: http://www.abc.net.au/science/k2/moments/s1143577. htm
The resultant affect of contamination on public health, worker ailments, and absenteeism and reduced productivity.
The cost of household pets flushing the toilet repeatedly to watch the action. This can incur significant cost for the use of water.
http://www.youtube.com/v/WofFb_eOxxA
You're right -- it's a particular way of doing it. But the Verizon way of doing it certainly isn't the only way to do VoIP. For example, if you study the judge's "Claim Construction" (cached here, and available through the U.S. District Court "PACER" system), it's clear that the IP address of the called user's VoIP device must be returned to the calling party. But in many VoIP systems, that IP is not returned to the calling device.
Most of the RBOCs (Baby Bells) that do traditional telephony and Internet tend to separate the two when it's convenient, and merge when it's not.
This is based on my understanding, not being a lawyer, but working up close with these companies: Of course, they sell their services as bundled, but when it comes to VoIP or ISP services, that's handled by the non-regulated side.
The regulated side deals with the FCC, appears before the Public Utility Commission (mutatis mutandis for any given state), and has to report certain outages. Most people think of this as the "common carrier" side as well. Sometimes, the regulated side just makes facilities available to the non-regulated side; e.g., DS3s.
The non-regulated side is just like any other company; they can do whatever they want. They can cancel your service or slow it down if they dislike you; they can search your email for contact with competitors.
Researchers can always be sloppy, or misleading to show what they want to believe, and rarely do they even have to lie. Scientific honesty is very rare; few rise to that standard. Most would rather just publish a paper, or make a presentation, than to find the Actual Real True Facts.
There are lots of advantages to keeping it small. It looks like the Windows Vista project is suffering many of the same maladies documented in OS/360 in Brooks' The Mythical Man Month. It's no real surprise that having lots of minds involved in the design of a project requires lots of communication and coordination to make it work.
Software really is tough. Large software is much tougher. As the "largest concerted project" ever, Windows Vista is pushing the limits of human capabilitity for coordination and communication. Each new module, and its attendant interfaces, adds new communication.
As communication increases, total overhead increases. In some cases, it increases in a combinatorial way. If we estimate the "efficiency" of a component as the value-it-brings (in terms of work saved elsewhere in the code) divided by the ( development-time + communication-overhead ), you always want this efficiency to be well over 1.
Is it less than 1 already? If so, can you really ever complete a project this way?
As a professional it's *your job* to find BetaCo
on
The Living Dilbert?
·
· Score: 1
This is a good point about the extremes, and about priorities -- but sometimes BetaCo isn't nameless. If you're responsible for selecting the best product, it's *your job* to find BetaCo. Often, BetaCo can be fairly successful, not because they have a huge marketing budget or an established brand name, but because their products work well, and because responsible technical people seek out the good products instead of defaulting to the brand names.
An example:"Telica" was a small company that made telephone switches, including one of the first reliable boxes that could connect the PSTN (with SS7) to VoIP networks with SIP and MGCP. They had a few patents, and a respectable marketing force. But they didn't have a huge established brand name, like Lucent, Nortel, or Siemens.
Lucent, Nortel, and Siemens are all large companies, and they've all made products that were supposed to compete with the Telica. But people who actually had to make VoIP networks work learned that their products weren't that good. And these companies have so many fish in the fryer that it's hard to get their attention to fix things -- like illegal SIP behavior. This is examples of large companies doing things worse.
These large companies have find some buyers for their gear -- by virtue of their large brand name. But responsible, hard-working, professional, skeptical engineers still continued to seek out the products that would actually work -- not just the products that were promised to work. So Telica continued to find success.
Yes, yes, Lucent bought Telica. In fact, the Telica technology has flourished somewhat, but Lucent has lost some of the key people who made Telica products and support great.
Big Companies Do Things Worse.
on
The Living Dilbert?
·
· Score: 3, Insightful
I'm a technical consultant, and I get to see inside a good many companies. Big Companies Do Things Worse. I don't really know why; maybe it's because small companies have to work hard and succeed to survive, whereas large companies are profitable enough to afford to be bad at what they do. Smaller organizations with fewer people involved in making things happen seem to make more things happen. Large companies with more time to think it through, and more people to have input, seem to have more meetings and think of more risks, and ultimately seem to get much less done.
In my experience, a small company is the best place to focus on the work at hand, rather than the overhead. It's also easier to get permission to do things, because there aren't as many people to have turf wars. Plus, at smaller companies, you'll see more of the mechanitions of real business decisions, rather than the fodder of low-competence managers and colleagues.
Of course you can fax with VoIP -- it's called T.38. It works very well because it's engineered well.
T.38 is an example of the Grown Up approach to telephony. Vonage is not the Grown Up approach.
But anytime voice works with vonage, you just got lucky. They're depending on *luck* to be sure you get low-enough, consistent-enough latency to handle the telephone call. Many new VoIP service providers are trying the luck route, instead of engineering a network with something like Diffserv.
Of course, if the "Net Neutrality" folks get their way, it'll be illegal to use Diffserv to deliver prioritized service necessary to do VoIP. So it'll be back to BellSouth/AT&T/Verizon/Ameritech/etc TDM-based service for all of us!
Slashdot Mirror
It costs Slashdot money to run these servers. Are you a thief to access their web pages?
It costs Google money to host Gmail, or perform your searches. Is Firefox enabling theft because it makes Google searches easy?
Of course not. The argument seems to be that popularity, i.e., heavy use in the way it was intended to use, means that the service was being abused, is specious.
Hopefully, your team is a profit center, and not a cost center. If your team is generating the profit, then the people who make the products are Kings. All stars. You should have the goal of making the finest systems possible -- under your constraints of time and budget.
Expect the developers to keep learning; "We don't have expertise in that," should be replaced with, "we should explore XYZ".
Plan on three versions of any important system: Force them to develop prototypes; demand basic functionality within a month of starting. Then revise and replace that prototype with another, better prototype. Then plan on a final version (The Third System) that discards the stuff you didn't need.
Work to avoid heavy-weight programming. I was once hired at $240/hour to write code for a company that had a large team of developers already. I knew only slightly more about the domain than they did. Their problem: this company had allowed the developers to just examine everything to death. They hired me to help because I could actually deliver within rough deadlines.
I disagree with the concept of hiring junior programmers, unless they're just apprentices. Do you want to hire a junior surgeon to do your operation? Or hire a junior Engineer to build the bridge your wife drives? No: senior people do important work. Junior people learn how, and do less critical, separate projects.
Good, adult programmer/engineers don't need much managing, but you need them to make the product. They do need somebody to help them see the bigger picture -- but any team of two engineers can do that for each other in turn. So you're really there to service them.
Fire the jerks. Develop some standard of productivity -- even if it's lines of code + group source code reviews -- and fire the people who are clearly not fitting in.
The problem for ISPs is that the costs are quite high, but these alleged features and advantages have almost no value because they bring almost no revenue.
The problem for users is that the costs are high (in terms of time and effort) but the advantages are, heretofore, nil. There's nothing I could do with IPv6 that I actually want to do that I can't do with IPv4.
I had forgotten Apple even sold a server. Unfortunately, so did they.
That's exactly the point. If I have agreed to forward those packets for you, then I should definitely stick by that. We already have a judicial system capable of enforcing contracts, and I'm all for that.
Why do we need another law?
Unnecessary laws weaken necessary laws, as Blaise Pascal said.
First, the net-neutrality folks attacked the policy-map command and the whole idea if Differentiated Services (i.e., IETF DiffServe). policy-map lets you configure prioritization or other special treatment of packets.
Now they're attacking the rate-limit and traffic-shape commands that let me control how many packets I forward of a particular type.
Don't I own my own router? Why should I be forced to forward packets that I don't want to forward? Why should I be forced to prioritize or not prioritize if I don't want to?
Donating money to to political campaigns is considered "free speech". By the same logic, shouldn't it be "freedom of the press" for me to decide which packets I want to forward through a router that I own?
AT&T, and every other big LEC, buys one of everything. They've got equipment and software from thousands of vendors, and this probably isn't the first filtering system they've developed.
To paraphrase an ex-Baby-Bell engineer I worked with: AT&T will probably ride this horse as far as it can, decide it's not the right horse, shoot it, then walk back to find another horse.
"The real tiger is never a match for the paper one, unless real use is wanted." -- FP Brooks, The Mythical Man Month
IPv4 is sooooooo 1984.
Sure, you can buy plenty of tape drives, but are you going to get them to work? To read the right block size? To decode the file format used by the backup tool? To possibly even deal with EBCDIC? This archive was probably split across several tapes. I've worked with several tape systems, mostly SCSI on Linux. It's remarkably hard to get things to work consistently, even when using the simplest tools, or when using some of the nicest. By "work consistently", I mean: consistently restore files when needed. ("Nobody cares about backup. Everybody cares about restore." -- Benjy Feen)
Unless it's an exceptionally disciplined thief, I'd bet cookies to doughnuts that the tape is going to be useless. Sure, there are tape readers are out there, but the use of tape itself is almost an obfuscation technique in itself. You'd have to be a pretty-determined attacker to round up a tape machine, make it work, and figure out the encoding technique on the tape.
You're right -- it's a particular way of doing it. But the Verizon way of doing it certainly isn't the only way to do VoIP. For example, if you study the judge's "Claim Construction" (cached here, and available through the U.S. District Court "PACER" system), it's clear that the IP address of the called user's VoIP device must be returned to the calling party. But in many VoIP systems, that IP is not returned to the calling device.
Most of the RBOCs (Baby Bells) that do traditional telephony and Internet tend to separate the two when it's convenient, and merge when it's not.
This is based on my understanding, not being a lawyer, but working up close with these companies: Of course, they sell their services as bundled, but when it comes to VoIP or ISP services, that's handled by the non-regulated side.
The regulated side deals with the FCC, appears before the Public Utility Commission (mutatis mutandis for any given state), and has to report certain outages. Most people think of this as the "common carrier" side as well. Sometimes, the regulated side just makes facilities available to the non-regulated side; e.g., DS3s.
The non-regulated side is just like any other company; they can do whatever they want. They can cancel your service or slow it down if they dislike you; they can search your email for contact with competitors.
Researchers can always be sloppy, or misleading to show what they want to believe, and rarely do they even have to lie. Scientific honesty is very rare; few rise to that standard. Most would rather just publish a paper, or make a presentation, than to find the Actual Real True Facts.
Software really is tough. Large software is much tougher. As the "largest concerted project" ever, Windows Vista is pushing the limits of human capabilitity for coordination and communication. Each new module, and its attendant interfaces, adds new communication.
As communication increases, total overhead increases. In some cases, it increases in a combinatorial way. If we estimate the "efficiency" of a component as the value-it-brings (in terms of work saved elsewhere in the code) divided by the ( development-time + communication-overhead ), you always want this efficiency to be well over 1.
Is it less than 1 already? If so, can you really ever complete a project this way?
An example:"Telica" was a small company that made telephone switches, including one of the first reliable boxes that could connect the PSTN (with SS7) to VoIP networks with SIP and MGCP. They had a few patents, and a respectable marketing force. But they didn't have a huge established brand name, like Lucent, Nortel, or Siemens.
Lucent, Nortel, and Siemens are all large companies, and they've all made products that were supposed to compete with the Telica. But people who actually had to make VoIP networks work learned that their products weren't that good. And these companies have so many fish in the fryer that it's hard to get their attention to fix things -- like illegal SIP behavior. This is examples of large companies doing things worse.
These large companies have find some buyers for their gear -- by virtue of their large brand name. But responsible, hard-working, professional, skeptical engineers still continued to seek out the products that would actually work -- not just the products that were promised to work. So Telica continued to find success.
Yes, yes, Lucent bought Telica. In fact, the Telica technology has flourished somewhat, but Lucent has lost some of the key people who made Telica products and support great.
In my experience, a small company is the best place to focus on the work at hand, rather than the overhead. It's also easier to get permission to do things, because there aren't as many people to have turf wars. Plus, at smaller companies, you'll see more of the mechanitions of real business decisions, rather than the fodder of low-competence managers and colleagues.
Of course you can fax with VoIP -- it's called T.38. It works very well because it's engineered well.
T.38 is an example of the Grown Up approach to telephony. Vonage is not the Grown Up approach.
But anytime voice works with vonage, you just got lucky. They're depending on *luck* to be sure you get low-enough, consistent-enough latency to handle the telephone call. Many new VoIP service providers are trying the luck route, instead of engineering a network with something like Diffserv.
Of course, if the "Net Neutrality" folks get their way, it'll be illegal to use Diffserv to deliver prioritized service necessary to do VoIP. So it'll be back to BellSouth/AT&T/Verizon/Ameritech/etc TDM-based service for all of us!