Can you read ASR-33 binary ASCII on punched paper?
My first computer was a coffee can with adhesive tape, paperclips, and a battery. You rotated the can on its axis to run the program. I learned truth tables in 1963 at age nine.
We had parallel track lives in 8080 and Z80 machine code. I did 6502 and other Signetics chips. Wrote UART/USART code that was resold a jillion++ times. Not a big whoop.
The big whoop: raising two kids and four stepkids. Watching 4/6 graduate from college. Two to go.
I'm not impressed-- even by citing IA's five-book trilogy. Snort.
it's buffering, making you, the cust om er wait, you're not hav ing much fun, are you?
Storing/cacheing can't be done (much) because it makes you wait, and you don't want to wait, you want to watch/listen.
And that's my point: torrents raise the noise floor by p2p traffic. Fine; it's not QoS, but it does add to the baseline of traffic, from whence others obtain their data-- or media. Media, however, mandates QoS or fat pipes. QoS prioritizes data, and non-QoS defers to it-- to the detriment of the non-QoS user.
So invent that algorithm. Here are some of the variables:
1) traffic on your own segment; other users attached to your endpoint and perhaps NAT'd connection (e.g. AP, home router, whatever) 2) traffic on the local segment; these are people that are on your own logical collision domain; it's possible there might not be anyone, but there might be 100s of users on it. 3) predict when someone's going to click on something or otherwise generate traffic; please separate those using QoS or other prioritization scheme and those not. 4) know all of the latency between all users, your user using your algorithm, and their destinations, and the congestion and latency between all of those points, as their periodicity shapes the latency variables. 5) predict all of the durations in #4, so that you can calc-up the windows of jitter and latency variables to buffer stuff up sufficiently so as not to introduce objectionable results on the screen of your users.
Ye gawds, people have been trying to do something like this for a long time, but you have a mix of dial-up to fiber users, destinations, activities, periodicity of transactions, and things you cannot know. So, best-effort is all you're going to get on a good day. Once you get a really good one, contact the Fraunhofer Institute in Duisberg and tell them about your invention. They've been spending millions of euros a year trying to achieve what you've speculated about.
We have to disagree. There is a pipe that has capacity for X aggregate packets/sec.
There are two data types, data (including maintenance traffic, acks/naks, etc) and prioritized traffic (QoS, MPLS domains, other kinds of tagging-- each going over various transports that do and do not support prioritization).
The amount of jitter enjoyed by QoS/tagged packets is less, because these packets are prioritized. This implies prioritized to the detriment of other traffic.
Yes, demand is up because we're using more entertainment media, which uses QoS, which requires infrastructure, which costs money, which has to come from *somewhere*.
It is not that I "feel" that the Internet was designed for entertainment in the form of digitized entertainment within isochronous time domains. In fact, it was not. Search up and down this thread for the history and rational. I'm not making this up, not Fox-Newsing it, I was there and have been researching this for about 30yrs.
There are other implications, depending on jurisdiction. Internationally, there are the theories of right-of-way purchase, easement leasing/lets, jurisdictional taxes and other impositions.
FTTH is a wonderful idea, but bottlenecks upstream unless there's a diversity of destinations or unbelievably fast routing, CDN tuning, and so forth.
In the US, there are 43 state public utility regulatory agencies to deal with, then the Feds. Oil is a finite resource, and its price bears no resemblence to supply-- it's a charade and propaganda machine.
Yes, there is dark fiber, but the cost of pulling new cable or fiber through a conduit is roughly the same cost of a totally new run in many places. That's one cost. The next cost are major interconnects, routers, CDN stacks, and so forth.
In an altruistic and ideal world, bandwidth is cheap and there are many providers to choose from. In reality, utilities are supposed to act as a conduit while providing commodity-cost infrastructure. The balance has tipped in favor of the ISPs/telcos and perverts the initial meaning of utility, how its assets are disbursed, by whom, and for how much. Lobbying efforts now mean that the ISPs/telcos get their way, because we desperately need them, as much in a way as basic electricity itself. 'Twould be lovely if we could get one rate that did what we wanted with high quality at a reasonable cost.
A small fraction of users, however, are disproportionate consumers of packets, or need special delivery handling options for those packets. Rather than build their needs into the baseline cost of what we all pay, I say: make them pay.
There are any number of ISP evils; I've seen them do devilish things to data, everything from deep-packet inspection to aperiodic protocol throttling. What if you could plan, rather than expect everything to fall in line? Queue up a movie for playing later tonight. Listen to music - instead of on-demand like Pandora - from your local cache? *VASTLY* fewer demands on infrastructure take place with just a bit of planning.
Instead, designs have to be done for peak loads, and with smartphones, on-demand media (and lots of it possibly *per end node/address*, vast amounts of infrastructure must be put into place.
It's like the plumbing conundrum of the unbelievable load that occurs when everyone flushes at once. Space thing out, queue things up, and the infrastructure is small, because the duty-cycle of transaction is small in engineering terms. Go for the max possible and pipes explode, or expectations are unfulfilled.
I'm NOT a fan of telcos and ISPs. Rather, I understand that their infrastructure faces genuine design issues based on their historical build-out and their capital and regulatory hurdles. Tax those in a hurry. You want first class seats? Pay for them. The rest of us can get by in coach. It's a historical issue that's not easily assuaged, this analog-is-now-digital data. Someone clever might come along and find a better way to mesh things, but not without a massive retrofit, and a costly one.
The caps are both reactive and a way for ISPs to deal with capital outlays, as you imply.
Data that's timed together is the toughest. Think of it like the way that FedEx or postal services have timing gradation in their pricing schedules. You want it overnight by 10am-- I mean you want all of those packets lined up in an uncongested row with less than 45ms latency between them, with no more than 1 in 200 packets missing? Fine. Pay for it. That's my argument.
Datacomm in its early form had little vision for isochronous media an QoS didn't even start to appear as a concern until about 20 years ago. That type of media was broadcast through the air, or delivered through analog coaxial cable-based distribution system pioneered by people not in the US where the Internet was being developed: for DATA.
These days, data can comprise of a myriad different types of consumables. But the one that taxes the living crap out of the DATA infrastructure are QoS apps and those that raise the noise floor like torrents, Skype, and other p2p applications. Except for Skype, and other apps needing respect for isochronicity in one from or another, none of the apps or the users of them, care one whit about a little latency, jitter, rerouting here and there. It doesn't diminish the quality of the experience. Aperiodicity is fine. Not in media transfers, especially fatuous codex relationships with big living zillion colors. Click-outs are fewer these days because the least common denominator speed level and sense of expectation has met the test of better broadband, at least in the US. When I travel to the EU or SE Asia, the net can be finger-snapping fast compared to the dullard DSL we have here. Yet no one says, ok, buddy, you have a slow connection so you're forbidden this type of media download-- but it's ok if it's time-shifted or stored for later consumption.
You see this as a one-dimension problem, and I'm trying to relay that there are at least two: it's not the size of downloads, it's the strain of QoS that is the problem. Torrents don't have much of an effect on QoS. But Hulu does. Listen to people swear when a Youtube video buffers up. That's the whole point: QoS places an enormous isochronous load on CDNs and end-point infrastructure. Tax it.
No, that was putting their foot on the torrent garden hose. QoS generally relates to protocols where data is prioritized by tagging. What you speak of is called admittance control, rather than isochronous flow control. See RSVP protocol for an idea of non-admittance controlled tagging. The issue branches into a whole slew of operational questions, flow control issues, etc. The Internet really wasn't designed for this, except the 224.+ multicasting scenarios initially envisioned for multicast. Doing highly efficient codex for HD "equivalent" realtime user-controlled media wasn't in the picture; it's an afterthought.
Yeah, I know. Bloatware has been around for eons now. But consider that utilities download that stuff at whatever rate is available, even the bloat. If you're watching a streamed movie from Hulu, latency becomes a problem quickly. If you store-and-watch rather than do it in realtime, it's easier. But God Forbid that you have copyrighted movies waiting on your machine to watch at a later time. You might PIRATE THEM, you, you torrent user (said as an epithet).
So all must be watch in a browser in realtime, else some contributing member of the MPAA doesn't get a fat paycheck.
You want to start a threat on bloat? Don't want those Epson printer drivers? What's wrong with you....
Make people that want entertainment QoS pay for it. Leave the rest of us alone. QoS places huge demands on infrastructure, and someone has to pay for it. Not me. Yet demand is going to continue to cause telcos to sink capital into infrastructure to support watching episodes of My Three Sons. Fuck that-- it's an entertainment endeavor that wasn't in the design. Simply charging for bandwidth on the hoof isn't going to cut it anymore-- see other arguments in this thread as to why.
I liked the old model of buy bandwidth, use it or not, but you should get what you pay for in terms of availability.
The problem is the reality of something made amusing in the Broadway show, The Producers. Bandwidth is unbelievably oversubscribed, and the only saviour to this has been diffuse destinations-- meaning that data comes from many places. Just use a script-halting plug in on your favorite browser to learn that a simple web page probably has a dozen or more different sources (and probably destinations, too).
The content farms (CDNs, iTunes, AppStores) suddenly need huge pipes because the constant demand for these sites are huge. They use load balancing to service clientele, sometimes hundreds of thousands of simultaneous streaming clients. If you're Comcast or Verizon, suddenly, you have a bottleneck. That bottleneck has to be assuaged or the congestion starts to become objectionable.
And gosh darn, you're not making hardly any money from that NetFlix and other streaming stuff, so it's in your best interests to charge in a tiered plan. Comcast in my area never used to have a cap. There was a nebulous artificial cap that was referenced, but now it's that 'law'. If you're a node or supernode on a p2p or torrent-ish network, then you're not following the hierarchical model, and many of these users raises the floor of quiescent activity through various daily demand cycles.
So metered data is their obvious solution, as we're not talking rocket scientists here, we're talking companies that want to be utility monopolies in your area-- now building content where they can if they're not outright buying it (hello, NBC).
In the bad old days, we just had data. Now we have data, but also stuff that requires comparatively clear pipes or protocols for isochronous data that have to work to prevent congestion and latency else the desired service becomes objectionable.
My method to fix this remains: let those that need QoS protocol support pay for that. For the rest of us, be it gamers, browser users on Facebook, or other largely aperiodic transaction users, pay less than those that need expensive and clear pipes.
Otherwise, each ISP will have to build infrastructure to the greatest possible denominator of usage profile, and that's not really practical-- ISPs have to make money somehow, monopolistic as they are. So what do you do? Let those that must be entertained or enjoy p2p network infrastructure pay for it. Downstream, ISPs are going to have to build huge networks anyway-- why not let evil telcos get rational funding for it?
Imagine a household with four teenagers, mom and dad (I know, science fiction, right?) that are all streaming content concurrently. One tenth of a GigE might do it if they all stream. Now add up 100 houses in the same subdivision or half of a city square mile. You can start to see how the bandwidth needs climb geometrically, and where the bottlenecks start to occur. Something has to give. The ideal world: in 1980, we deployed 100% fiber to the home and we don't have this problem. But we didn't, and we won't, because we're evilly fragmented and consumers through community governments have become the natural enemy of the utility-turned-monopoly telcos.
It's not that simple. In the old days, data was periodic because it lived in its own time domain. Now, much data is isochronous, so there becomes an aperiodic demand for streams that needed to be timed together so as to allow us to watch videos, listen to music, etc.
100MB of patches from Apple or Microsoft, while important, don't need to happen all at once, breathlessly. But NetFlix needs the timing.
You cite aggregate use over time, while ISPs see torrents, and other data that uses their rails. My solution: charge more for isochronous data. Let those wanting entertainment pay a wee bit more for the privilege. If I want an ISO of the latest operating system goo, then my rate is lower than those wanting to watch a flick- recent theatre release or pr0n.
I used neither word. "Moral" might be a good word to use. In the context of the original post, however, mistreatment of animals is a punishable offense. And for good reason: it's both illegal, and immoral.
If you can't agree that abusing animals isn't right, then we have no further possibility of civil discussion.
They're animals, and deserve to be treated humanely. Beating a dog produces pain; so does beating a cow. Cows are used for meat, it's true, but they don't deserve torture or mistreatment.
Seems like a rather extreme solution, doesn't it? In the US, we have random inspections in many places. Farms with >50 in a herd sound like good candidates.
I think I understand that there are occasional problems, and putting down an animal might look like cruelty when it's not.
There is some weight given, however, to animals that are kept in truly inhuman conditions, mutilated, confined, and unable to live any kind of life associated with its species. This sort of problem lays between what you describe and the other end of zealotry.
Staging evidence, however, is as evil as what it portrays, if not more so. That said, there is no legal pass that's needed to be given to farmers, as they're protected. If they didn't do what's described, then they're defamed. If they did-- they're not. There are mitigating circumstances as you describe. That has to be understood within the context of the litigation at hand. With luck, real evidence is understood within the confines of circumstances.
Defamation only works if the evidence isn't true, just like libel. If they dead beat animals to death, it's the truth, not a de-faming of the accused.
Litigation to sue the activists would certainly fail, unless it was contrived or staged. If it wasn't, then animal cruelty charges apply and I hope they stick.
No one says you can't get up and say "lights on" or have a proximity sensor light your way as you stumble through the house.
I think that Google needs more revenue, so their shiny new hammer needs fresh nails. OTOH, someone needs to get the methodology evolved sufficiently so that others will think of intelligent ways to compete with it for fun and profit.
As far as the hacks go, well, maybe pico networks with tiny or captive transmission systems can do bluetooth-like things to a house net for those that want or need the control. I'm not sure what sustainable methods would work, but it's worth investing time to see what might be effective.
Undoubtedly telcos will screw you, it's part of the definition. But now, SCOTUS reaffirms that the common carrier clause is in effect, and that telcos are still utilities in the old concept of the word, that their wires are to be used for other providers, and those providers can be awesome or worse than the evil that describes the telcos.
It is a good day.
Could a telco screw a third-party? Sure. But I don't think they'll want to. Why? More than likely, what affects one of the third party customers also affects one of theirs. Secondly, most of the states have highly evolved utility regulatory authorities, some of which aren't in the back pockets of the telcos and will gnaw at their legs until they bleed. Gladly.
Slashdot Mirror
Yeah yeah. This isn't a match.
Can you read ASR-33 binary ASCII on punched paper?
My first computer was a coffee can with adhesive tape, paperclips, and a battery. You rotated the can on its axis to run the program. I learned truth tables in 1963 at age nine.
We had parallel track lives in 8080 and Z80 machine code. I did 6502 and other Signetics chips. Wrote UART/USART code that was resold a jillion++ times. Not a big whoop.
The big whoop: raising two kids and four stepkids. Watching 4/6 graduate from college. Two to go.
I'm not impressed-- even by citing IA's five-book trilogy. Snort.
Wh
en
it's buffering, making you, the
cust
om
er wait, you're not hav
ing
much
fun, are you?
Storing/cacheing can't be done (much) because it makes you wait, and you don't want to wait, you want to watch/listen.
And that's my point: torrents raise the noise floor by p2p traffic. Fine; it's not QoS, but it does add to the baseline of traffic, from whence others obtain their data-- or media. Media, however, mandates QoS or fat pipes. QoS prioritizes data, and non-QoS defers to it-- to the detriment of the non-QoS user.
So invent that algorithm. Here are some of the variables:
1) traffic on your own segment; other users attached to your endpoint and perhaps NAT'd connection (e.g. AP, home router, whatever)
2) traffic on the local segment; these are people that are on your own logical collision domain; it's possible there might not be anyone, but there might be 100s of users on it.
3) predict when someone's going to click on something or otherwise generate traffic; please separate those using QoS or other prioritization scheme and those not.
4) know all of the latency between all users, your user using your algorithm, and their destinations, and the congestion and latency between all of those points, as their periodicity shapes the latency variables.
5) predict all of the durations in #4, so that you can calc-up the windows of jitter and latency variables to buffer stuff up sufficiently so as not to introduce objectionable results on the screen of your users.
Ye gawds, people have been trying to do something like this for a long time, but you have a mix of dial-up to fiber users, destinations, activities, periodicity of transactions, and things you cannot know. So, best-effort is all you're going to get on a good day. Once you get a really good one, contact the Fraunhofer Institute in Duisberg and tell them about your invention. They've been spending millions of euros a year trying to achieve what you've speculated about.
I wanna be on the same segment as you. Obviously, you live on a reasonably provisioned one.
We agree about the rights holders conundrum.
Otherwise, buffering is usually object
ction
a
ble
because it promot
es poor quality.
Amen.
Good luck with that. All that.
No. He sells computers and *thinks* he's a geek. He wears a polo shirt with the company logo, but his headset is too tight.
We have to disagree. There is a pipe that has capacity for X aggregate packets/sec.
There are two data types, data (including maintenance traffic, acks/naks, etc) and prioritized traffic (QoS, MPLS domains, other kinds of tagging-- each going over various transports that do and do not support prioritization).
The amount of jitter enjoyed by QoS/tagged packets is less, because these packets are prioritized. This implies prioritized to the detriment of other traffic.
Yes, demand is up because we're using more entertainment media, which uses QoS, which requires infrastructure, which costs money, which has to come from *somewhere*.
It is not that I "feel" that the Internet was designed for entertainment in the form of digitized entertainment within isochronous time domains. In fact, it was not. Search up and down this thread for the history and rational. I'm not making this up, not Fox-Newsing it, I was there and have been researching this for about 30yrs.
There are other implications, depending on jurisdiction. Internationally, there are the theories of right-of-way purchase, easement leasing/lets, jurisdictional taxes and other impositions.
FTTH is a wonderful idea, but bottlenecks upstream unless there's a diversity of destinations or unbelievably fast routing, CDN tuning, and so forth.
In the US, there are 43 state public utility regulatory agencies to deal with, then the Feds. Oil is a finite resource, and its price bears no resemblence to supply-- it's a charade and propaganda machine.
Yes, there is dark fiber, but the cost of pulling new cable or fiber through a conduit is roughly the same cost of a totally new run in many places. That's one cost. The next cost are major interconnects, routers, CDN stacks, and so forth.
In an altruistic and ideal world, bandwidth is cheap and there are many providers to choose from. In reality, utilities are supposed to act as a conduit while providing commodity-cost infrastructure. The balance has tipped in favor of the ISPs/telcos and perverts the initial meaning of utility, how its assets are disbursed, by whom, and for how much. Lobbying efforts now mean that the ISPs/telcos get their way, because we desperately need them, as much in a way as basic electricity itself. 'Twould be lovely if we could get one rate that did what we wanted with high quality at a reasonable cost.
A small fraction of users, however, are disproportionate consumers of packets, or need special delivery handling options for those packets. Rather than build their needs into the baseline cost of what we all pay, I say: make them pay.
There are any number of ISP evils; I've seen them do devilish things to data, everything from deep-packet inspection to aperiodic protocol throttling. What if you could plan, rather than expect everything to fall in line? Queue up a movie for playing later tonight. Listen to music - instead of on-demand like Pandora - from your local cache? *VASTLY* fewer demands on infrastructure take place with just a bit of planning.
Instead, designs have to be done for peak loads, and with smartphones, on-demand media (and lots of it possibly *per end node/address*, vast amounts of infrastructure must be put into place.
It's like the plumbing conundrum of the unbelievable load that occurs when everyone flushes at once. Space thing out, queue things up, and the infrastructure is small, because the duty-cycle of transaction is small in engineering terms. Go for the max possible and pipes explode, or expectations are unfulfilled.
I'm NOT a fan of telcos and ISPs. Rather, I understand that their infrastructure faces genuine design issues based on their historical build-out and their capital and regulatory hurdles. Tax those in a hurry. You want first class seats? Pay for them. The rest of us can get by in coach. It's a historical issue that's not easily assuaged, this analog-is-now-digital data. Someone clever might come along and find a better way to mesh things, but not without a massive retrofit, and a costly one.
The caps are both reactive and a way for ISPs to deal with capital outlays, as you imply.
Data that's timed together is the toughest. Think of it like the way that FedEx or postal services have timing gradation in their pricing schedules. You want it overnight by 10am-- I mean you want all of those packets lined up in an uncongested row with less than 45ms latency between them, with no more than 1 in 200 packets missing? Fine. Pay for it. That's my argument.
Datacomm in its early form had little vision for isochronous media an QoS didn't even start to appear as a concern until about 20 years ago. That type of media was broadcast through the air, or delivered through analog coaxial cable-based distribution system pioneered by people not in the US where the Internet was being developed: for DATA.
These days, data can comprise of a myriad different types of consumables. But the one that taxes the living crap out of the DATA infrastructure are QoS apps and those that raise the noise floor like torrents, Skype, and other p2p applications. Except for Skype, and other apps needing respect for isochronicity in one from or another, none of the apps or the users of them, care one whit about a little latency, jitter, rerouting here and there. It doesn't diminish the quality of the experience. Aperiodicity is fine. Not in media transfers, especially fatuous codex relationships with big living zillion colors. Click-outs are fewer these days because the least common denominator speed level and sense of expectation has met the test of better broadband, at least in the US. When I travel to the EU or SE Asia, the net can be finger-snapping fast compared to the dullard DSL we have here. Yet no one says, ok, buddy, you have a slow connection so you're forbidden this type of media download-- but it's ok if it's time-shifted or stored for later consumption.
You see this as a one-dimension problem, and I'm trying to relay that there are at least two: it's not the size of downloads, it's the strain of QoS that is the problem. Torrents don't have much of an effect on QoS. But Hulu does. Listen to people swear when a Youtube video buffers up. That's the whole point: QoS places an enormous isochronous load on CDNs and end-point infrastructure. Tax it.
No, that was putting their foot on the torrent garden hose. QoS generally relates to protocols where data is prioritized by tagging. What you speak of is called admittance control, rather than isochronous flow control. See RSVP protocol for an idea of non-admittance controlled tagging. The issue branches into a whole slew of operational questions, flow control issues, etc. The Internet really wasn't designed for this, except the 224.+ multicasting scenarios initially envisioned for multicast. Doing highly efficient codex for HD "equivalent" realtime user-controlled media wasn't in the picture; it's an afterthought.
The time-delay view thing is a big problem for those crazy guys at the MPAA. That's why streaming becomes an issue in multidimensional ways.
Yeah, I know. Bloatware has been around for eons now. But consider that utilities download that stuff at whatever rate is available, even the bloat. If you're watching a streamed movie from Hulu, latency becomes a problem quickly. If you store-and-watch rather than do it in realtime, it's easier. But God Forbid that you have copyrighted movies waiting on your machine to watch at a later time. You might PIRATE THEM, you, you torrent user (said as an epithet).
So all must be watch in a browser in realtime, else some contributing member of the MPAA doesn't get a fat paycheck.
You want to start a threat on bloat? Don't want those Epson printer drivers? What's wrong with you....
It's simple, fair, and the wrong answer.
Make people that want entertainment QoS pay for it. Leave the rest of us alone. QoS places huge demands on infrastructure, and someone has to pay for it. Not me. Yet demand is going to continue to cause telcos to sink capital into infrastructure to support watching episodes of My Three Sons. Fuck that-- it's an entertainment endeavor that wasn't in the design. Simply charging for bandwidth on the hoof isn't going to cut it anymore-- see other arguments in this thread as to why.
I liked the old model of buy bandwidth, use it or not, but you should get what you pay for in terms of availability.
The problem is the reality of something made amusing in the Broadway show, The Producers. Bandwidth is unbelievably oversubscribed, and the only saviour to this has been diffuse destinations-- meaning that data comes from many places. Just use a script-halting plug in on your favorite browser to learn that a simple web page probably has a dozen or more different sources (and probably destinations, too).
The content farms (CDNs, iTunes, AppStores) suddenly need huge pipes because the constant demand for these sites are huge. They use load balancing to service clientele, sometimes hundreds of thousands of simultaneous streaming clients. If you're Comcast or Verizon, suddenly, you have a bottleneck. That bottleneck has to be assuaged or the congestion starts to become objectionable.
And gosh darn, you're not making hardly any money from that NetFlix and other streaming stuff, so it's in your best interests to charge in a tiered plan. Comcast in my area never used to have a cap. There was a nebulous artificial cap that was referenced, but now it's that 'law'. If you're a node or supernode on a p2p or torrent-ish network, then you're not following the hierarchical model, and many of these users raises the floor of quiescent activity through various daily demand cycles.
So metered data is their obvious solution, as we're not talking rocket scientists here, we're talking companies that want to be utility monopolies in your area-- now building content where they can if they're not outright buying it (hello, NBC).
In the bad old days, we just had data. Now we have data, but also stuff that requires comparatively clear pipes or protocols for isochronous data that have to work to prevent congestion and latency else the desired service becomes objectionable.
My method to fix this remains: let those that need QoS protocol support pay for that. For the rest of us, be it gamers, browser users on Facebook, or other largely aperiodic transaction users, pay less than those that need expensive and clear pipes.
Otherwise, each ISP will have to build infrastructure to the greatest possible denominator of usage profile, and that's not really practical-- ISPs have to make money somehow, monopolistic as they are. So what do you do? Let those that must be entertained or enjoy p2p network infrastructure pay for it. Downstream, ISPs are going to have to build huge networks anyway-- why not let evil telcos get rational funding for it?
Imagine a household with four teenagers, mom and dad (I know, science fiction, right?) that are all streaming content concurrently. One tenth of a GigE might do it if they all stream. Now add up 100 houses in the same subdivision or half of a city square mile. You can start to see how the bandwidth needs climb geometrically, and where the bottlenecks start to occur. Something has to give. The ideal world: in 1980, we deployed 100% fiber to the home and we don't have this problem. But we didn't, and we won't, because we're evilly fragmented and consumers through community governments have become the natural enemy of the utility-turned-monopoly telcos.
It's not that simple. In the old days, data was periodic because it lived in its own time domain. Now, much data is isochronous, so there becomes an aperiodic demand for streams that needed to be timed together so as to allow us to watch videos, listen to music, etc.
100MB of patches from Apple or Microsoft, while important, don't need to happen all at once, breathlessly. But NetFlix needs the timing.
You cite aggregate use over time, while ISPs see torrents, and other data that uses their rails. My solution: charge more for isochronous data. Let those wanting entertainment pay a wee bit more for the privilege. If I want an ISO of the latest operating system goo, then my rate is lower than those wanting to watch a flick- recent theatre release or pr0n.
Let's see, use nodes to accumulate data for decision support.
Not a single facet of this is patentable. Not that it should be.
I dunno. Let's slap you around a bit and see if you're tender yet.
I used neither word. "Moral" might be a good word to use. In the context of the original post, however, mistreatment of animals is a punishable offense. And for good reason: it's both illegal, and immoral.
If you can't agree that abusing animals isn't right, then we have no further possibility of civil discussion.
They're animals, and deserve to be treated humanely. Beating a dog produces pain; so does beating a cow. Cows are used for meat, it's true, but they don't deserve torture or mistreatment.
Seems like a rather extreme solution, doesn't it? In the US, we have random inspections in many places. Farms with >50 in a herd sound like good candidates.
Charge farmers with murder? Are you kidding?
I think I understand that there are occasional problems, and putting down an animal might look like cruelty when it's not.
There is some weight given, however, to animals that are kept in truly inhuman conditions, mutilated, confined, and unable to live any kind of life associated with its species. This sort of problem lays between what you describe and the other end of zealotry.
Staging evidence, however, is as evil as what it portrays, if not more so. That said, there is no legal pass that's needed to be given to farmers, as they're protected. If they didn't do what's described, then they're defamed. If they did-- they're not. There are mitigating circumstances as you describe. That has to be understood within the context of the litigation at hand. With luck, real evidence is understood within the confines of circumstances.
Defamation only works if the evidence isn't true, just like libel. If they dead beat animals to death, it's the truth, not a de-faming of the accused.
Litigation to sue the activists would certainly fail, unless it was contrived or staged. If it wasn't, then animal cruelty charges apply and I hope they stick.
No one says you can't get up and say "lights on" or have a proximity sensor light your way as you stumble through the house.
I think that Google needs more revenue, so their shiny new hammer needs fresh nails. OTOH, someone needs to get the methodology evolved sufficiently so that others will think of intelligent ways to compete with it for fun and profit.
As far as the hacks go, well, maybe pico networks with tiny or captive transmission systems can do bluetooth-like things to a house net for those that want or need the control. I'm not sure what sustainable methods would work, but it's worth investing time to see what might be effective.
Undoubtedly telcos will screw you, it's part of the definition. But now, SCOTUS reaffirms that the common carrier clause is in effect, and that telcos are still utilities in the old concept of the word, that their wires are to be used for other providers, and those providers can be awesome or worse than the evil that describes the telcos.
It is a good day.
Could a telco screw a third-party? Sure. But I don't think they'll want to. Why? More than likely, what affects one of the third party customers also affects one of theirs. Secondly, most of the states have highly evolved utility regulatory authorities, some of which aren't in the back pockets of the telcos and will gnaw at their legs until they bleed. Gladly.