Take the multi-core uSparc family. There are three viable choices for server CPUs today-- Intel/AMD-something, PPC family, or uSparc. Intel and AMD are fighting each other for margins. The fabless uSparc design is tight and well designed. IBM can't let go of the PPC family for many reasons, but it lags behind the Intel/AMD world vastly.
Java? Nice technology with a crummy marketing plan. The Java Desktop is pretty cool stuff.... and needs lots of sandpaper and varnish to make it work well. Do they have an intelligent developer program? No. Certification/education program? No. They should look to Oracle or even Cisco to learn how to do this right. Sun Press. Think about it.
There are other programs which need to be whacked with a sharp knife. R&D is a very good thing, when you have focus and vision-- and not a chip on your shoulder about how Bill and Steve done-ya-wrong. It's all about understanding your clientele, and avoiding the temptation to involve research in incestuous projects that foster the not-invented-here mentality. Sun needs friends. Sun has enemies. Easy play.
And not one that a hockey player might make.
It's a good thing: time to refresh things
on
Sun to Cut 5000 Jobs
·
· Score: 4, Insightful
Sun's not-invented-here madness has kept them from overcoming the McNeely mindset.... one that pushed SGi recently into Chapter 11. I, for one, believe that both Solaris and uSparc technologies bring a lot to the table.
Their feistyness has been one of their biggest stumbling blocks for years. This gives them a chance to rebuild, cut some of their more insane projects and financial bleeding, and get back into action.
Sun has very goofy, fence-straddling legacy madnesses: Java programs, licensing issues, relationship issues, Microsoft litigation legacies, and all sorts of baggage. The faster they shed the baggage and go with producing assets, the better, IMHO.
It's not going to happen. I'm sorry to burst your bubble.
They're not going to do it. Don't believe their lies.
I'm sorry that I can't improve your situation. But there have been so many bald face liars, guaranteeing some kind of alternative to reality that I've become very jaded. The chances are very very slim that this could happen.
Consider the asset outlay vs return vs the current and future competition already embedded in the scenery of the US. From nothing, these guys propose to lay out literally billions, and give you 384K. It's not going to happen.
It's not going to happen, just like the low orbit blimps, and the satellites with low latency/high speed, just like a bunch of FAT LIES designed to slow down the development of what's really needed: FTTX, high-bit-rate 'WiFi', and other technologies.
Perfectly usable.... today.... if you don't mind waiting for anything with serious graphical content. Those damned to dialup deserve something better. This is like putting your foot on the garden hose, and that's yesterday, not four years from now when the graphical content mix will be a far higher ratio.
Bad idea. Bad cost, and the 95% is a pipe dream-- a pipe full of drugs.
Still another plan that will fail out of the starting gate. How about blimps, covering the horizon? 384k is barely usable. If you want it today, get an EV-DO card from Verizon or Sprint... or maybe an Edge card from Cingular/T-Mobile downstream-- once they can cover more than a few sq mi at a time.
This is not only money down a rat hole, but the announcement is also designed to queer all of the WiFi providers trying to build business cases across the country.
Not going to happen. Worse, it's obfuscation at its pinnacle.
When it quacks like a duck, walks like a duck, it must be a duck.
When there's no evidence that it's a duck, it's delusional. What motivated this late night posting? Perhaps additional delusion.
Not to discount the earnest sentiments of real people, I'll agree that it's a little 'tin-hat' to be taken seriously. But then the medical community has done bad things before, like missing the value of "Lorenzo's Oil" and other odd-but-true associations.
Is it confirmed that Apple closed the kernel? Or is it speculation because they haven't released updated source?
I double dog dare you to find it. They've been leaning in this direction for a while.
Judging by most projects out there, and I'll take gaim for example, the only thing you'll learn about coding by reading the source is how NOT to write good code.
We could prove your point if we could see the source:O
I never said there weren't benefits to OSS, you misread what I said. He said the model sucks and I gave examples of where it does not suck. Your response basically takes my words and twists them saying the OSS model sucks or has no benefits over proprietary closed source.
Which can't be further from what I said.
No, not really. It's my belief that the words uttered are just another round of Microsoft hormonal secretions. I wasn't intentionally trying to twist your words, only demonstrate open vs closed benefits. There is good code and bad code, and closed and open. The benefits to open is that there is peer review, possible meaningful contribution, and perhaps comprehension and good example. None of those are available in closed source. Closed source isn't inherently evil, nor is it inherently good-- just like OSS. But you can see it. That fact is empowering.
1) collaborative third party development and evolution is impossible with closed source, except by a proprietary gatekeeper of some type 2) visible source is easier to fix than invisible source 3) it's impossible to judge application quality and security without seeing source; otherwise it's hearsay 4) open source survives the ills of its progenitors 5) it's still ok to charge for software, even open source, IMHO 6) trade secrets can be encumbered by closed source, and so can lots of copyrights and patents not owned or licensed by its developers 7) you don't learn by reading closed source code (an oxymoron), however, you can learn by reading open source code 8) closed source doesn't actually suck, but it can be used to hide, obfuscate, cajole, and frustrate both developers and users
OS/2 was a technical success and market failure, and took eons to get bug fixes finished. The same can be said for BeOs. Simply building a better mouse trap and thinking that people will flock to you is one of those sweet lies that duped engineers believe. It's simply not so.
And now Apple probably sucks because their microkernel and some of their codebase is now closed. For that, we'll all suffer.
Three guys named Brad and another one named Josh post a fluffy little article on security for wireless, then cover about 1/3rd of the basics, and none of the tough stuff.
In a word, they should be punished. And someone should tape their eyes open while reading WiFoo or another good book on just how many zillion interesting hacks there are for wireless. And then, the site should get the check back-- if they were so silly as to have paid these guys.
And I wonder, how many more airy and light posts will there be, today? Slashdot Lite, less filling, less intelligent-- news for birds.
And these, too, will fail: bad backhaul
on
The New Wireless Wars
·
· Score: 5, Interesting
The bits per hertz problem throttles each and every kind of two-way wireless.
When multiple concurrent instances occur of those ugly, low-frame rate videos with the tiny rasters and 256-bit color, it's going to clog the backhaul. OFDM currently carries the best bit/hertz rate, and you can't make dense enough cells to support what copper or fiber carries.
You can get close, until the public uptake causes backhaul arterial sclerosis. Then you get the same problem you have today with EVDO, EDGE, and all of the other schemes--> unacceptable quality and carriers that have a telco mentality.
More spectrum != better quality, because the network backend hasn't been developed yet that meets future demands. These are all short-term plays with doomed future when they fail or have glaring delivery problems that can't be solved because of the bits/hertz problem. Until a miracle occurs in encoding capabilities, the front end fails; and if the front end works, then the backend infrastructure fails.
And organizations will go willy-nilly to the FCC and pay untold amounts of $$ to get spectra robbed from other services. And their stockholders will pray that it makes a return on the investment. And, like other schemes in the US, there will be bitter disappointment when people learn just how low speed these wireless 'broadband' connections actually are.
Until both the encoding schemes mature, and there's a re-investment in network backhaul, buying spectra isn't the answer, only a new set of problems.
Multiple concurrent instances, even multicast, will choke the backhaul.
I want this show, someone wants to watch another, and someone ordered a movie upstairs. So perhaps there are five instances in my home all by itself. Wireless won't support, that, not even MIMO. Broadcast can, but not full res (or even close) DTV broadcases-- even with the best CODECs.
Then take my neighborhood, and start multiplying the instances. Do the math. It's pretty easy. Along about the tenth home or so, you start filling up an OC12-- even if there were distribution boxes that understood multicasting protocols. Take my block, add up all the other blocks in the city. Make it 9PM, prime time. Mulitple OC192 lambdas running on the best fiber today is going to cave. The backhaul will become clogged, and then the lights go out, running from green to red on somebody's Cisco 12000 in a NOC. Then they start to throttle back traffic by protocol type.
Ok, Mr Wizard-- which ones get throttled? Mail? Port 80? Oh-- IPTV-- it's not critical.
Wait, my set's blooming. All pixelated. Bummer.
For a fact, the implementations-- no matter what the last 100 yards are (even fiber) will clog the backhaul. The only solution is local/regional cacheing.... or using a different way of thinking for broadcasters. The numbers don't work. You either limit raster size, color spectrum, frame rate, or start losing information in the CODEC method, or you have data rates that are huge or are substandard compared to broadcast HDTV (US standard). IPTV has that to compete with. If it can't do it, and must forever mime something ugly like NTSC, PAL, or SECAM, then the game is over and IPTV loses. If, however, you can compete with advanced (and advancing HDTV methods) then there's a chance. To do that, given an isochronous data transport need, requires method that doesn't crack the time domain encapsulating the data stream. Multicasting can't do that but for a few channels at a time. Add VOD and other instances, and the backbone collapses or becomes throttled, impeding the streams-- and blowing their quality to shreds.
Local/regional cacheing is the only solution until everything becomes re-thought in terms of infrastructure-- and the economics are behind it. Until then, IPTV will have ugly, postage-stamp sized rasters at frame rates that can be measured in furlongs per fortnight.
Think of local cacheing farms. You can download the content, then when it's time to broadcast, it emerges from a local/home cache to be played.
Otherwise, there just isn't a way to do IPTV unless broadcasters (think the guys with antennas) figure out an alternate method.
The backpressure put on the Internet will one day be able to handle it. But until multiple lambda inter-regional distribution networks using SDH or equivalent methods become available, even OC192 becomes a bottleneck.
Not but a handful of towers are on buildings. Fewer still are close to where humans habitate. The radiation patterns in the freqs used by GSM diminish rapidly as a function of distance. If you're 100m away from the antenna, you're far less exposed than say, 10m away.
And yes, your search of the phrase turned up the Wikipedia version reveals my mispelling. The intent, however, was clear. Arguing the form is obfuscative. And droll.
One of these days, power lines were going to get modulated. There's no St Elmo's Fire that's going to happen, radiologically. Yes, there's more RF. But there's more RF everywhere. Screw up hams? I don't think so. More mu metal? Probably.
It's only the last hundred meters that's going to get much modulation anyway; most of the backhaul is through alternate means. Sometimes fiber, sometimes twisted pairs, sometimes cellular 2.4/5.8Ghz. The WiFi redistribution/cellular concept is a long way from the most popular amateur bands.
BPL advocates will tell you that it's not fttp. And it's not going to be at cable speeds for a long while, but has lots of possibilities.
But here are the salient positive points:
1) these guys are by their nature, net-neutral and while they're utilities, they don't live behind ancient telco models 2) reliability is a serious culture within the power community; these guys have trucks and know how to use them 3) the electrical utilities have the largest amount of unused communications easements and right-of-ways in the USA 4) the utilities in the EU are riding this wave quickly; they go everywhere, while the old tired fat ex-PTTs slumber 5) more competition keeps the telco and cable companies honest. We need alternatives.
This is what happens when you don't think forward on protocols. The cure, in the form of hundreds of attempts at everything from Baysien filters to source-IP blockers, seem to always fail. Why? Because SMTP, our mail protocol, is based on telnet, 7-bit ASCII, and easily fudged authentication. Worse, 'thinking' filtration systems use a rules basis that appears to work, but can never work because the rules can change, as any successful spammer knows.
Then, we get a bunch of techno-idiots like the US Congress to legislate email relationships, miserably, contributing further to the problem.
The real solution? Simple blockage. Route the bastards to 127.0.0.1. Force authentication of the address and its owner before it can go out of the blocked ACLs. And if it happens again, shunt the address to a different CIDR block. Or re-write SMTP. That's all that's going to work. Nothing is foolproof because fools are so ingenious. Never underestimate the power of a hacker, and locks keep your friends out, your enemies have pick tools.
It's like how it was with LattisNet, then 10BaseT.
Or 802.11g. Everyone's bucking for market share, to be the first ones on the block, to entice you with speed.
-Compatibility? Who knows. -Backwards compatibility with 802.11b/g? Who knows. -Data rates that are what was advertised? Early tests say no way, not even close by b/g standards. -Firmware all nicely baked? Nope. -Non-CardBus capability? Dream on. -Low-power chipsets? Nightmare on. -Test regimens? No. -Test equipment? No. -New cellular distribution capabilities? Who knows? It's not a standard yet. -Requirement that it has even a modicum of internal security like WPA2? Ho ho ho.... -Any open source motherboards? You wish. -Resplendent ubiquitous deployments? Not for years. -Faster than b/g and EV-DO (not EV-DOa)? Probably.
Weren't we here about four years ago? Didn't anyone learn any lessons? Ok, it's about early marketshare. It can't be about anything else.
First, there was the highly enlightening 404, if there was a resolution at all. Then there was the typosquatters. My fav was Micros0ft.com.
But all of those are better than intercepts, which are surprisingly common these days in 'walled gardens'. I'll take a squatter, and if google can make some $$ on them, so much the better.
DNS is primitive, insecure, rife for diddling, and as goofy as SMTP. Yes, these were all good in their day. And yes, they were made out of brittle plastic, not visionary armor. So, google makes a few bucks. Ho fracking hum. More power to them. If I get a wrong phone #, does someone give me a list of alternatives? No, but they're often helpful as in "oh, that's a 6 not a 9" or something. With DNS you get a squat, not found, or a typosquat. How droll.
1. Launch the most expensive product in your history (in terms of development dollars) 2. Try to prevent nearly-free server operating systems from eating your lunch 3. Pay off the EU fine (just a paltry $700 million or so) 4. Launch a new version of your flagship application (Office Vista?) 5. Stem the losses from your flagship gaming appliance (Xbox360) 6. Make your Longhorn into steak 7. Continue to avoid the wrath of various litigation efforts, some which you will lose...
And there are many more, but these are sufficient to need to build a war chest, Google's success notwithstanding.
Slashdot Mirror
Our benchmarks say something completely different.....
Multi-core Itaniums lead, followed closely by multi-core AMDs, followed by uSparc Ts, then the Power family.
This, using Linux 2.6 kernels in minimal/sparse installs, and LMBench3.
Take the multi-core uSparc family. There are three viable choices for server CPUs today-- Intel/AMD-something, PPC family, or uSparc. Intel and AMD are fighting each other for margins. The fabless uSparc design is tight and well designed. IBM can't let go of the PPC family for many reasons, but it lags behind the Intel/AMD world vastly.
Java? Nice technology with a crummy marketing plan. The Java Desktop is pretty cool stuff.... and needs lots of sandpaper and varnish to make it work well. Do they have an intelligent developer program? No. Certification/education program? No. They should look to Oracle or even Cisco to learn how to do this right. Sun Press. Think about it.
There are other programs which need to be whacked with a sharp knife. R&D is a very good thing, when you have focus and vision-- and not a chip on your shoulder about how Bill and Steve done-ya-wrong. It's all about understanding your clientele, and avoiding the temptation to involve research in incestuous projects that foster the not-invented-here mentality. Sun needs friends. Sun has enemies. Easy play.
And not one that a hockey player might make.
Sun's not-invented-here madness has kept them from overcoming the McNeely mindset.... one that pushed SGi recently into Chapter 11. I, for one, believe that both Solaris and uSparc technologies bring a lot to the table.
Their feistyness has been one of their biggest stumbling blocks for years. This gives them a chance to rebuild, cut some of their more insane projects and financial bleeding, and get back into action.
Sun has very goofy, fence-straddling legacy madnesses: Java programs, licensing issues, relationship issues, Microsoft litigation legacies, and all sorts of baggage. The faster they shed the baggage and go with producing assets, the better, IMHO.
Now show me free 384K service.....
It's not going to happen. I'm sorry to burst your bubble.
They're not going to do it. Don't believe their lies.
I'm sorry that I can't improve your situation. But there have been so many bald face liars, guaranteeing some kind of alternative to reality that I've become very jaded. The chances are very very slim that this could happen.
Consider the asset outlay vs return vs the current and future competition already embedded in the scenery of the US. From nothing, these guys propose to lay out literally billions, and give you 384K. It's not going to happen.
It's not going to happen, just like the low orbit blimps, and the satellites with low latency/high speed, just like a bunch of FAT LIES designed to slow down the development of what's really needed: FTTX, high-bit-rate 'WiFi', and other technologies.
It's not going to happen. I'm sorry.
This is the diff between actual EV-DO and 1xRTT.
Perfectly usable.... today.... if you don't mind waiting for anything with serious graphical content. Those damned to dialup deserve something better. This is like putting your foot on the garden hose, and that's yesterday, not four years from now when the graphical content mix will be a far higher ratio.
Bad idea. Bad cost, and the 95% is a pipe dream-- a pipe full of drugs.
Fooey.
Still another plan that will fail out of the starting gate. How about blimps, covering the horizon? 384k is barely usable. If you want it today, get an EV-DO card from Verizon or Sprint... or maybe an Edge card from Cingular/T-Mobile downstream-- once they can cover more than a few sq mi at a time.
This is not only money down a rat hole, but the announcement is also designed to queer all of the WiFi providers trying to build business cases across the country.
Not going to happen. Worse, it's obfuscation at its pinnacle.
When it quacks like a duck, walks like a duck, it must be a duck.
When there's no evidence that it's a duck, it's delusional. What motivated this late night posting? Perhaps additional delusion.
Not to discount the earnest sentiments of real people, I'll agree that it's a little 'tin-hat' to be taken seriously. But then the medical community has done bad things before, like missing the value of "Lorenzo's Oil" and other odd-but-true associations.
That fact still doesn't explain the posting.
I double dog dare you to find it. They've been leaning in this direction for a while.
Judging by most projects out there, and I'll take gaim for example, the only thing you'll learn about coding by reading the source is how NOT to write good code.We could prove your point if we could see the source :O
I never said there weren't benefits to OSS, you misread what I said. He said the model sucks and I gave examples of where it does not suck. Your response basically takes my words and twists them saying the OSS model sucks or has no benefits over proprietary closed source. Which can't be further from what I said.No, not really. It's my belief that the words uttered are just another round of Microsoft hormonal secretions. I wasn't intentionally trying to twist your words, only demonstrate open vs closed benefits. There is good code and bad code, and closed and open. The benefits to open is that there is peer review, possible meaningful contribution, and perhaps comprehension and good example. None of those are available in closed source. Closed source isn't inherently evil, nor is it inherently good-- just like OSS. But you can see it. That fact is empowering.
Let's review:
1) collaborative third party development and evolution is impossible with closed source, except by a proprietary gatekeeper of some type
2) visible source is easier to fix than invisible source
3) it's impossible to judge application quality and security without seeing source; otherwise it's hearsay
4) open source survives the ills of its progenitors
5) it's still ok to charge for software, even open source, IMHO
6) trade secrets can be encumbered by closed source, and so can lots of copyrights and patents not owned or licensed by its developers
7) you don't learn by reading closed source code (an oxymoron), however, you can learn by reading open source code
8) closed source doesn't actually suck, but it can be used to hide, obfuscate, cajole, and frustrate both developers and users
OS/2 was a technical success and market failure, and took eons to get bug fixes finished. The same can be said for BeOs. Simply building a better mouse trap and thinking that people will flock to you is one of those sweet lies that duped engineers believe. It's simply not so.
And now Apple probably sucks because their microkernel and some of their codebase is now closed. For that, we'll all suffer.
And really now, what did you expect him to say? Our model sucks, and please, let me now genuflect in the hotbed of OSS dev?
It's like asking Steve Ballmer to take estrogen.
Three guys named Brad and another one named Josh post a fluffy little article on security for wireless, then cover about 1/3rd of the basics, and none of the tough stuff.
In a word, they should be punished. And someone should tape their eyes open while reading WiFoo or another good book on just how many zillion interesting hacks there are for wireless. And then, the site should get the check back-- if they were so silly as to have paid these guys.
And I wonder, how many more airy and light posts will there be, today? Slashdot Lite, less filling, less intelligent-- news for birds.
The bits per hertz problem throttles each and every kind of two-way wireless.
When multiple concurrent instances occur of those ugly, low-frame rate videos with the tiny rasters and 256-bit color, it's going to clog the backhaul. OFDM currently carries the best bit/hertz rate, and you can't make dense enough cells to support what copper or fiber carries.
You can get close, until the public uptake causes backhaul arterial sclerosis. Then you get the same problem you have today with EVDO, EDGE, and all of the other schemes--> unacceptable quality and carriers that have a telco mentality.
More spectrum != better quality, because the network backend hasn't been developed yet that meets future demands. These are all short-term plays with doomed future when they fail or have glaring delivery problems that can't be solved because of the bits/hertz problem. Until a miracle occurs in encoding capabilities, the front end fails; and if the front end works, then the backend infrastructure fails.
And organizations will go willy-nilly to the FCC and pay untold amounts of $$ to get spectra robbed from other services. And their stockholders will pray that it makes a return on the investment. And, like other schemes in the US, there will be bitter disappointment when people learn just how low speed these wireless 'broadband' connections actually are.
Until both the encoding schemes mature, and there's a re-investment in network backhaul, buying spectra isn't the answer, only a new set of problems.
Multiple concurrent instances, even multicast, will choke the backhaul.
I want this show, someone wants to watch another, and someone ordered a movie upstairs. So perhaps there are five instances in my home all by itself. Wireless won't support, that, not even MIMO. Broadcast can, but not full res (or even close) DTV broadcases-- even with the best CODECs.
Then take my neighborhood, and start multiplying the instances. Do the math. It's pretty easy. Along about the tenth home or so, you start filling up an OC12-- even if there were distribution boxes that understood multicasting protocols. Take my block, add up all the other blocks in the city. Make it 9PM, prime time. Mulitple OC192 lambdas running on the best fiber today is going to cave. The backhaul will become clogged, and then the lights go out, running from green to red on somebody's Cisco 12000 in a NOC. Then they start to throttle back traffic by protocol type.
Ok, Mr Wizard-- which ones get throttled? Mail? Port 80? Oh-- IPTV-- it's not critical.
Wait, my set's blooming. All pixelated. Bummer.
For a fact, the implementations-- no matter what the last 100 yards are (even fiber) will clog the backhaul. The only solution is local/regional cacheing.... or using a different way of thinking for broadcasters. The numbers don't work. You either limit raster size, color spectrum, frame rate, or start losing information in the CODEC method, or you have data rates that are huge or are substandard compared to broadcast HDTV (US standard). IPTV has that to compete with. If it can't do it, and must forever mime something ugly like NTSC, PAL, or SECAM, then the game is over and IPTV loses. If, however, you can compete with advanced (and advancing HDTV methods) then there's a chance. To do that, given an isochronous data transport need, requires method that doesn't crack the time domain encapsulating the data stream. Multicasting can't do that but for a few channels at a time. Add VOD and other instances, and the backbone collapses or becomes throttled, impeding the streams-- and blowing their quality to shreds.
Local/regional cacheing is the only solution until everything becomes re-thought in terms of infrastructure-- and the economics are behind it. Until then, IPTV will have ugly, postage-stamp sized rasters at frame rates that can be measured in furlongs per fortnight.
Not if the pipes get clogged.....
Multiple instances will kill it.
For sure.
No one wants ugly DTV.
Think of local cacheing farms. You can download the content, then when it's time to broadcast, it emerges from a local/home cache to be played.
Otherwise, there just isn't a way to do IPTV unless broadcasters (think the guys with antennas) figure out an alternate method.
The backpressure put on the Internet will one day be able to handle it. But until multiple lambda inter-regional distribution networks using SDH or equivalent methods become available, even OC192 becomes a bottleneck.
Think regional cache. Google, RU listening???
Not but a handful of towers are on buildings. Fewer still are close to where humans habitate. The radiation patterns in the freqs used by GSM diminish rapidly as a function of distance. If you're 100m away from the antenna, you're far less exposed than say, 10m away.
And yes, your search of the phrase turned up the Wikipedia version reveals my mispelling. The intent, however, was clear. Arguing the form is obfuscative. And droll.
This is prima facia evidence. Yes, there are other possibilities. But if you RTFA, the chances of them are evidently low.
To those saying that the causality implication is low, I'd say there's near empirical evidence to the contrary.
One of these days, power lines were going to get modulated. There's no St Elmo's Fire that's going to happen, radiologically. Yes, there's more RF. But there's more RF everywhere. Screw up hams? I don't think so. More mu metal? Probably.
It's only the last hundred meters that's going to get much modulation anyway; most of the backhaul is through alternate means. Sometimes fiber, sometimes twisted pairs, sometimes cellular 2.4/5.8Ghz. The WiFi redistribution/cellular concept is a long way from the most popular amateur bands.
BPL advocates will tell you that it's not fttp. And it's not going to be at cable speeds for a long while, but has lots of possibilities.
But here are the salient positive points:
1) these guys are by their nature, net-neutral and while they're utilities, they don't live behind ancient telco models
2) reliability is a serious culture within the power community; these guys have trucks and know how to use them
3) the electrical utilities have the largest amount of unused communications easements and right-of-ways in the USA
4) the utilities in the EU are riding this wave quickly; they go everywhere, while the old tired fat ex-PTTs slumber
5) more competition keeps the telco and cable companies honest. We need alternatives.
So, I say: party on, BPL!
Block them. Let their owners deal with their infections. Until they're known to have been cleansed
ROUTE THEM TO NULL.
This is what happens when you don't think forward on protocols. The cure, in the form of hundreds of attempts at everything from Baysien filters to source-IP blockers, seem to always fail. Why? Because SMTP, our mail protocol, is based on telnet, 7-bit ASCII, and easily fudged authentication. Worse, 'thinking' filtration systems use a rules basis that appears to work, but can never work because the rules can change, as any successful spammer knows.
Then, we get a bunch of techno-idiots like the US Congress to legislate email relationships, miserably, contributing further to the problem.
The real solution? Simple blockage. Route the bastards to 127.0.0.1. Force authentication of the address and its owner before it can go out of the blocked ACLs. And if it happens again, shunt the address to a different CIDR block. Or re-write SMTP. That's all that's going to work. Nothing is foolproof because fools are so ingenious. Never underestimate the power of a hacker, and locks keep your friends out, your enemies have pick tools.
It's like how it was with LattisNet, then 10BaseT.
Or 802.11g. Everyone's bucking for market share, to be the first ones on the block, to entice you with speed.
-Compatibility? Who knows.
-Backwards compatibility with 802.11b/g? Who knows.
-Data rates that are what was advertised? Early tests say no way, not even close by b/g standards.
-Firmware all nicely baked? Nope.
-Non-CardBus capability? Dream on.
-Low-power chipsets? Nightmare on.
-Test regimens? No.
-Test equipment? No.
-New cellular distribution capabilities? Who knows? It's not a standard yet.
-Requirement that it has even a modicum of internal security like WPA2? Ho ho ho....
-Any open source motherboards? You wish.
-Resplendent ubiquitous deployments? Not for years.
-Faster than b/g and EV-DO (not EV-DOa)? Probably.
Weren't we here about four years ago? Didn't anyone learn any lessons? Ok, it's about early marketshare. It can't be about anything else.
Curse of Lomo? No, Curse of MIMO.
First, there was the highly enlightening 404, if there was a resolution at all. Then there was the typosquatters. My fav was Micros0ft.com.
But all of those are better than intercepts, which are surprisingly common these days in 'walled gardens'. I'll take a squatter, and if google can make some $$ on them, so much the better.
DNS is primitive, insecure, rife for diddling, and as goofy as SMTP. Yes, these were all good in their day. And yes, they were made out of brittle plastic, not visionary armor. So, google makes a few bucks. Ho fracking hum. More power to them. If I get a wrong phone #, does someone give me a list of alternatives? No, but they're often helpful as in "oh, that's a 6 not a 9" or something. With DNS you get a squat, not found, or a typosquat. How droll.
Here are the issues, pick anyone:
1. Launch the most expensive product in your history (in terms of development dollars)
2. Try to prevent nearly-free server operating systems from eating your lunch
3. Pay off the EU fine (just a paltry $700 million or so)
4. Launch a new version of your flagship application (Office Vista?)
5. Stem the losses from your flagship gaming appliance (Xbox360)
6. Make your Longhorn into steak
7. Continue to avoid the wrath of various litigation efforts, some which you will lose...
And there are many more, but these are sufficient to need to build a war chest, Google's success notwithstanding.