You do realize that the average solar panel requires more energy utilization to make it than it can possibly generate in 5 to 10 years of full sunshine during the day?
Solar's just moving the problem to the manufacturing plant. If you want electricity at night, Solar can't produce enough electricity to manufacture or refurbish the batteries that it would need to accomplish that.
Electric cars, move the problem to the power plant.
Nuclear moves the problem to Yucca Mountain.
Hybrid cars move the problem to the battery plants.
All of these silly "alternative energy" plans all have huge underlying flaws that no one talks about, because we want HOPE that humans aren't defintely going to trash the planet with over-population.
We need to quit being naieve. We will trash the planet.
Want a REAL solution? Stop paying parents to have children. (Tax breaks, higher tax rebates, etc.) No limits like China on number of children, just stop handing parents free money every year for "Dependents".
Re-read that line that says Total Tax Liability on your 1040 this year, and see if you think you got that many dollars worth of something from your government.
Then vote accordingly in every election that will make even a small difference.
Ever considered adding to the experience to give your head something to do? I like to keep a scorecard during most games I attend. It fills in the "down-time" nicely.
Learning how the shorthand used on a baseball scorecard, and developing your own style so you can "read the game back" to yourself later, is an interesting thing to do, and keeps your head in the game... you can start to see how a player is doing that day vs. the last time you saw him play, etc... did he hit to right field more than left? Etc. (Also can be pretty invaluable if you ever find yourself coaching a recreational league team.)
I understand your need for constant action. It goes away as you get older.
A nice baseball game, my scorecard, a brautwurst/hot dog, a beer, and my AM headphones (I like listening to the radio announcers instead of the inane announcers are most stadiums, and you get some other background information on the players)...
And I'll meet you at the ballpark ANYTIME! Take me out to the balllllll-game... heh.
I'll save the "excitement" for the airport.
(I fly small aircraft.)
Now, commercial airlines... THAT's boring! Baseball is FAR more interesting than riding in high speed aluminum tubing stuffed to the gills like the lower levels of the Titanic!
Just think, we live in a country where every single one of us, not just chosen "military" or other priveledged people can fly one of THESE:
Usually if baseball appears boring to someone, it's because they know very little of the nuances of the game. Defense is quite a mental challenge in many situations, but people just see a bunch of guys standing there.
That's not what the players are thinking, however.
In order to learn the nuances and strategies, usually one must have PLAYED on a team, to really get it. Most people don't or have only played in non-competitive softball leagues, and completely miss probably 50%-75% of the real "action" going on.
As far as statistics go... the reason baseball fans find them interesting, isn't so much because they're just fans... you need to know those statistics for strategy on the field, defensively.
Thus, fans that follow stats, aren't doing it because they like stats -- they're doing it because it helps them think about what the players and coaches are thinking when a particular guy takes the batting box.
Baseball can be very subtle when played to its best, and Americans aren't much for subtlety these days. Just like they also don't get real satire.
You're missing the point. "No service" was a bad way to put it.
"Ratty service" or "poor service" isn't ever in Public Safety radio systems. They have to fill ALL of the holes in the jurisdictional coverage area, or it's a SAFETY problem for officers, firefighters, etc.
How that relates to a Federal system that no one wanted anyway? No one knows... but the RF coverage mandates for Public Safety systems are far higher than cellular. Cellular drops calls.
Public Safety can NOT drop calls if at all possible, and the engineers MUST know where the coverage problems are and FILL them. An officer calling for help MUST be heard.
Emergency Services may have light overall traffic requirements (and this changes dramatically when a REAL emergency happens), they have higher coverage needs.
The difference in coverage needed is night and day when you compare things like rural (or even suburban) cellular networks, versus public safety radio systems.
When the cop is knocked down by a bad guy, lying in mud next to the road, with a relatively low powered handheld radio on his down side, the antenna stuffed in the water and mud, no vehicular repeater (a common way to handle HT coverage) and trying to draw his weapon and press his "man down" button on his radio at the same time... the damn thing has to work.
"No service" is NOT an option for public safety radio system (RF) designers.
So the requirements to "cover" the populated areas might have been met, but the system wouldn't be usable by public safety.
That is the REAL problem with D-Block. There is no NEED for a Federally-run national public safety system. Jurisdictions and agencies run their own, or maybe get to regional or statewide cooperative systems, but national? The federal agencies don't WANT shared RF systems.
It is a system looking for a problem to solve that none of the agencies want solved.
C|Net gave the Dish DVR an "Editor's Choice" award over the TiVo for HD content.
I'm about to find out, I guess. Going back to Dish now that I haven't been a "customer" for 6 months, so I can get their deals... since 7 1/2 years of loyal payments for service and one DishMover move weren't enough for them to even give a discount on buying a replacement SD receiver when the NEWEST one I owned, died.
The old one that's close to 8 years old, still works, still got updates, and had a UHF remote... which they took out of the later units.
But the HD-DVR receiver looks a hell of a lot better.
So... give up Dish for 6 months to get a deal on reinstalling the whole damn house? Hell yes.
When the economy is slowing/shrinking, there are more people than there are jobs, almost across the board.
I keep wondering why people find this so hard to figure out.
Seen higher salaries lately? No. Seeing higher prices on everything? Yes.
Okay, economy struggling.
Seen friends calling you talking about their "great new job" lately? No.
Yep... jobs aren't plentiful. No matter what some doofus who SELLS CERTIFICATIONS (Microsoft) IN TECHNOLOGY says and wants to sell more copies of software, more training, more books, more test fees, more more more... there's no jobs.
My cat's cranky. He wouldn't lie next to anyone who was sick. All he does is wait until someone is headed within a three mile radius of the kitchen, and then starts meowing for food.
Somehow I think I'm in the other 2/3's of cat owners who would have no effects.
And the study indicates to me that 1/3 of cats are great, the other 2/3's are a pain in the ass.
With those odds, I'll think I'll stick with petting the dog.
Manager: "I need you to put a 'Next Action' in your trouble tickets every week so they don't show up on the dashboard and drag me into a manager's meeting about them."
Dev/Tech: "Um, the ticket is in 'Pending/Customer Action' status and clearly has notes in it that show we're waiting for the customer to do months of testing our bad code forced upon them when we released a huge patch that touched virtually everything in the software."
Manager: "Yeah, but that doesn't matter. Team, gather around. See all these choices in the drop-down box? They're great but the upper management doesn't even see them on their reports. What the criteria for tickets are is to have a 'Next Action' activity in every ticket every week, no matter what else is in there."
Dev/Tech: "So what you're saying is, just ignore the other data points and drop downs and every activity can be labeled 'Next Action' and no one will care?"
Manager: "Well, it'll keep me from having to go to that meeting and explain your tickets to half the world! I already know you're doing your jobs, but they only have their reports and I'm required to go if the tickets are not done correctly."
Dev/Tech: "Okay we can do that. What about the actual ticket status field? When it says "Pending/Customer Action" shouldn't that be a criteria for their report? It's right there, and we have been using it since we never got any training on the business rules about what to use in this ticket software."
Manager: "Doesn't matter. If you go in on Monday nights and put a 'Next Action' in every ticket you have open, that meets the criteria. We also think you might have to type a space or a period into the ticket description to update the 'Last Updated' date/time field, because it appears that it doesn't update when you add 'Next Action' activities, but we're still checking on that one."
Dev/Tech: "Awesome. Well at least we know. Why did we install this expensive bloatware ticket system that cost the company hundreds of thousands of dollars in consultants just to get it working, when the old system worked fine?"
Manager: "Doesn't matter. You're not management, you don't get to ask those questions."
Dev/Tech: "Doesn't have anything to do with the CEO of the ticket software living in the same neighborhood in California as our CEO, does it?"
Manager: "Really?"
Dev/Tech: "Really. They probably play golf together."
The names have been changed to protect the "innocent", on this one -- of course. And the bloatware is web-based Siebel versus the desktop version. One customized for a giant company, the other customized (very well) for a small one, by managers who knew what data they wanted out of it BEFORE it was deployed.
Fully expecting the "Siebel cleanup task-force" in about a year or two, complete with "representatives" from each department who will be as ignored as they were during the roll-out of THIS version.
We get nice timely updates in e-mail every couple of weeks, sometimes every month, about the four or five little bugs they "worked hard on fixing" in fields only 10 people in the company use... those are nice. They apparently have a whole staff of developers and consultants working on these bugs, forever.
Ticket systems run amok are always my favorite "mangement has no idea what they want" stories... they drive the requirements, spend years making "mock-ups" of the screens and reports, and then seem to find out later that that's NOT HOW THEIR OWN BUSINESS RUNS and never did. Very entertaining, but wastes a lot of time and money...
Oh well. Once someone TELLS you how to manipulate the ticket system the way management wants it manipulated, the game's over. You ignore every other of the 40 or so fields and drop-downs and do your work, make notes, and get things done as usual... the notes tell the story for your 1st level manager, and they're responsible (as always) for your work anyway, so the ticket system's reports are massa
The normal people of the world, who actually need to get shit done with their Linux machines, and know that manufacturers don't get it, and don't give a shit... will continue to use NDISWrapper and ignore it's GPL status or anything else related to it.
They'll happily run native drivers if the kernel devs can ever figure them out, but meanwhile they've got shit to do... and no fiscal or moral reason to care.
The root cause of most of this is that "software" is perceived as "hard" to create and develop correctly. The vast majority of coders don't code to any standards, don't reuse code that's known and TESTED to work correctly, and generally -- act like two year olds when management or users demand better.
They want the title "Software Engineer", but they don't want the RESPONSIBILITY that goes with the title. Civil Engineers put their names on things and are INSPECTED by outside third parties. Bridges and roadways falling down are considered career-limiting moves by a Civil Engineering group. Building codes, and/or other build/design rules are the underpinnings of every other style of "engineering" on the planet... try getting a new aircraft through the FAA's certification process inexpensively, if you think you can -- and these types of safeguards and rules are ALWAYS pooh-poohed by the coddled "software engineers".
They state that these and other legal measures are taken to make sure that most "engineered" products, critical for our daily lives, aren't necessary in software. That they would add cost and no value. But then I read SANS and other security-related trade rags that talk about the constant loss of personal data, bad (very bad) security holes in VERY expensive software packages with no patches or even admission that the problem really exists by the software company, etc.
It's time for the insanity to stop. Engineers that engineer software need to grow up and start acting like computers aren't "mystery" boxes. They're not. GOOD software with few problems CAN be written. There's NOT a need for the weekly "patch merry go-round". People WILL pay for something better... they just don't know it exists because software people continue to make excuses for our profession. It's getting old.
Comcast also has "commercial" levels of service beyond the "residential" services. I have a 6Mb/1Mb guarantee from them at a higher price than residential service, and the "PowerBoost" allows 12Mb/2Mb burst up/down.
I've tested it regularly with large files, and I regularly see higher than 6Mb down continuously.
Desktop application code, you must admit, is is pretty crappy these days... when it comes to security. Name one desktop application that hasn't had MULTIPLE security patches in the last year.
Most security experts also agree that this "patching everything and then patching it again" is killing the real gains found (monetary) by utilizing the technology in the first place. At some point if it was written badly enough to need continuous patching, the support staff required to keep up with patching, internal certification/testing, etc... grows exponentially beyond what most organizations gained by switching to using computers for certain tasks in the first place.
There *are* examples of how to code nearly flawlessly, and procedures around that. They're usually found behind the closed doors of military and defense systems contractors, so they're not publicized much. Same thing for MOST embedded systems where lives are on the line, including transportation systems, satellites, etc.
The software quality in those systems is arguably quite a bit higher than the typical software in the "desktop" computing world, but one could argue that with MORE of us using the desktop environment software for day-to-day life these days, the risks and disadvantages of not treating such software as "mission critical" as embedded systems, is a huge oversight or omission on the part of the "software industry".
How many of us use web browsers (ESPECIALLY WEB BROWSERS) for online banking, command and control of multi-million-dollar systems, and just about everything these days? Isn't a browser then more important to treat the code as if it MUST BE RIGHT THE FIRST TIME (even if it isn't), than just about any other utility piece of software, or any embedded control system?
Zero-bugs may not be possible, but the current number of bugs is far beyond what the industry can bear, long-term. It's simple financials... if desktop computing and the server hardware and add-on software (virus scanners, malware scanners, etc etc etc... and the never-ending treadmill of additional hardware requirements to run all the SCANNERS) continue up in price for organizations, IT is on a never-ending downward spiral that won't stop until computers are locked back down to bare minimum job-handling capability... a dumb terminal...
In fact, systems that never left the dumb terminal environment, have done well throughout the years. Only fairly recently were airline reservations moved from the so-called "archaic" mainframe-based systems and command-line/text-only interfaces, to something slightly more modern. Ever wonder why?
I get the distinct impression that most "desktop application coders" either don't have or don't want the discipline necessary to produce quality software similar to the embedded and life-critical systems mentioned above... even if they could. They would rather whine and make excuses about "find me some bug-free code".
How about we find them some MUCH better quality code, and show them some techniques for writing code like THAT and not the cruddy mess we currently have for "security" on the desktop/utility computing environment?
They act like ANY level of bugs is "acceptable" but that PROVING they're making continuous improvement in LOWERING the number of bugs is too inconvenient. Then you add in the love affair with changing the underlying tools, languages, and IDE's, and it's amazing anyone ever gets anything done, but not a surprise that there's NO MEASURABLE IMPROVEMENT in the number or quality of bugs in almost three decades of popular computing.
It's a machine -- it only does what it's told to. If the software's too complex to debug it correctly, someone made it so. Those "someones" have either been working in the field for that same 30 years, or have been managing the new people incorrectly, and not requiring code re-use and standards to avoid the mistakes they made 20 years ago, when they were coding.
Have the bugs gotten smaller? Nope. Less frequent? Nope. In fact there's bigger holes found every day, and more of them. The code monkeys need to stop, and THINK, and ENGINEER their next solutions.
The wrote the crap code (or borrowed it from somewhere else) in the first place.
Whhhaaaaah... I released GARBAGE with security holes in it and someone else didn't tell me before they released their fix!
Is about what all this amounts to.
STOP WRITING CRAPPY INSECURE CODE, REFUSING TO TEST IT, AND NOT BUILDING TO ANY TYPE OF SAFETY STANDARDS - GROW UP AND BE REAL ENGINEERS... and the problem solves itself.
Slashdot Mirror
You do realize that the average solar panel requires more energy utilization to make it than it can possibly generate in 5 to 10 years of full sunshine during the day?
Solar's just moving the problem to the manufacturing plant. If you want electricity at night, Solar can't produce enough electricity to manufacture or refurbish the batteries that it would need to accomplish that.
Electric cars, move the problem to the power plant.
Nuclear moves the problem to Yucca Mountain.
Hybrid cars move the problem to the battery plants.
All of these silly "alternative energy" plans all have huge underlying flaws that no one talks about, because we want HOPE that humans aren't defintely going to trash the planet with over-population.
We need to quit being naieve. We will trash the planet.
Want a REAL solution? Stop paying parents to have children. (Tax breaks, higher tax rebates, etc.) No limits like China on number of children, just stop handing parents free money every year for "Dependents".
Seriously. Are we that stupid?
Maybe we need some IT-related and sysadmin related "journals" for the academics then, too?
I think you meant "Wipe your ass for you too-sensors", didn't you?
Stop and think...
We pay for all that horseshit process crap.
You think it's worth it?
Re-read that line that says Total Tax Liability on your 1040 this year, and see if you think you got that many dollars worth of something from your government.
Then vote accordingly in every election that will make even a small difference.
Ever considered adding to the experience to give your head something to do? I like to keep a scorecard during most games I attend. It fills in the "down-time" nicely.
Learning how the shorthand used on a baseball scorecard, and developing your own style so you can "read the game back" to yourself later, is an interesting thing to do, and keeps your head in the game... you can start to see how a player is doing that day vs. the last time you saw him play, etc... did he hit to right field more than left? Etc. (Also can be pretty invaluable if you ever find yourself coaching a recreational league team.)
I understand your need for constant action. It goes away as you get older.
A nice baseball game, my scorecard, a brautwurst/hot dog, a beer, and my AM headphones (I like listening to the radio announcers instead of the inane announcers are most stadiums, and you get some other background information on the players)...
And I'll meet you at the ballpark ANYTIME! Take me out to the balllllll-game... heh.
I'll save the "excitement" for the airport.
(I fly small aircraft.)
Now, commercial airlines... THAT's boring! Baseball is FAR more interesting than riding in high speed aluminum tubing stuffed to the gills like the lower levels of the Titanic!
Just think, we live in a country where every single one of us, not just chosen "military" or other priveledged people can fly one of THESE:
http://www.cirrusdesign.com/
And instead, we drive around in minivans on weekends to soccer games. Sad. Teach the kid to fly instead.
Usually if baseball appears boring to someone, it's because they know very little of the nuances of the game. Defense is quite a mental challenge in many situations, but people just see a bunch of guys standing there.
That's not what the players are thinking, however.
In order to learn the nuances and strategies, usually one must have PLAYED on a team, to really get it. Most people don't or have only played in non-competitive softball leagues, and completely miss probably 50%-75% of the real "action" going on.
As far as statistics go... the reason baseball fans find them interesting, isn't so much because they're just fans... you need to know those statistics for strategy on the field, defensively.
Thus, fans that follow stats, aren't doing it because they like stats -- they're doing it because it helps them think about what the players and coaches are thinking when a particular guy takes the batting box.
Baseball can be very subtle when played to its best, and Americans aren't much for subtlety these days. Just like they also don't get real satire.
Damn, I was wondering where you could get Crack from a reliable online source, too. Glad Amazon's mission statement says they'll be working on it.
You're missing the point. "No service" was a bad way to put it.
"Ratty service" or "poor service" isn't ever in Public Safety radio systems. They have to fill ALL of the holes in the jurisdictional coverage area, or it's a SAFETY problem for officers, firefighters, etc.
How that relates to a Federal system that no one wanted anyway? No one knows... but the RF coverage mandates for Public Safety systems are far higher than cellular. Cellular drops calls.
Public Safety can NOT drop calls if at all possible, and the engineers MUST know where the coverage problems are and FILL them. An officer calling for help MUST be heard.
Depends on how tight you wrap the towel.
Oh, did you say over their head? I thought you said around their neck...
My bad. Carry on.
Emergency Services may have light overall traffic requirements (and this changes dramatically when a REAL emergency happens), they have higher coverage needs.
The difference in coverage needed is night and day when you compare things like rural (or even suburban) cellular networks, versus public safety radio systems.
When the cop is knocked down by a bad guy, lying in mud next to the road, with a relatively low powered handheld radio on his down side, the antenna stuffed in the water and mud, no vehicular repeater (a common way to handle HT coverage) and trying to draw his weapon and press his "man down" button on his radio at the same time... the damn thing has to work.
"No service" is NOT an option for public safety radio system (RF) designers.
So the requirements to "cover" the populated areas might have been met, but the system wouldn't be usable by public safety.
That is the REAL problem with D-Block. There is no NEED for a Federally-run national public safety system. Jurisdictions and agencies run their own, or maybe get to regional or statewide cooperative systems, but national? The federal agencies don't WANT shared RF systems.
It is a system looking for a problem to solve that none of the agencies want solved.
Nate
C|Net gave the Dish DVR an "Editor's Choice" award over the TiVo for HD content.
I'm about to find out, I guess. Going back to Dish now that I haven't been a "customer" for 6 months, so I can get their deals... since 7 1/2 years of loyal payments for service and one DishMover move weren't enough for them to even give a discount on buying a replacement SD receiver when the NEWEST one I owned, died.
The old one that's close to 8 years old, still works, still got updates, and had a UHF remote... which they took out of the later units.
But the HD-DVR receiver looks a hell of a lot better.
So... give up Dish for 6 months to get a deal on reinstalling the whole damn house? Hell yes.
Why? Everything he installed is public knowledge everywhere but here on knee-jerk Slashdot.
The ARRL Antenna Manual is probably one of the longest-standing references for antenna and feedline theory.
When the economy is slowing/shrinking, there are more people than there are jobs, almost across the board.
I keep wondering why people find this so hard to figure out.
Seen higher salaries lately? No.
Seeing higher prices on everything? Yes.
Okay, economy struggling.
Seen friends calling you talking about their "great new job" lately? No.
Yep... jobs aren't plentiful. No matter what some doofus who SELLS CERTIFICATIONS (Microsoft) IN TECHNOLOGY says and wants to sell more copies of software, more training, more books, more test fees, more more more... there's no jobs.
My cat's cranky. He wouldn't lie next to anyone who was sick. All he does is wait until someone is headed within a three mile radius of the kitchen, and then starts meowing for food.
Somehow I think I'm in the other 2/3's of cat owners who would have no effects.
And the study indicates to me that 1/3 of cats are great, the other 2/3's are a pain in the ass.
With those odds, I'll think I'll stick with petting the dog.
Actually why was putting them there unwise? Nothing even remotely dangerous -- really dangerous -- about it.
You can bring your M80's up in my PRIVATE aircraft any day of the week. Let's go flying the non-TSA way... come on out to the airport.
The opposite is often true, too:
Manager: "I need you to put a 'Next Action' in your trouble tickets every week so they don't show up on the dashboard and drag me into a manager's meeting about them."
Dev/Tech: "Um, the ticket is in 'Pending/Customer Action' status and clearly has notes in it that show we're waiting for the customer to do months of testing our bad code forced upon them when we released a huge patch that touched virtually everything in the software."
Manager: "Yeah, but that doesn't matter. Team, gather around. See all these choices in the drop-down box? They're great but the upper management doesn't even see them on their reports. What the criteria for tickets are is to have a 'Next Action' activity in every ticket every week, no matter what else is in there."
Dev/Tech: "So what you're saying is, just ignore the other data points and drop downs and every activity can be labeled 'Next Action' and no one will care?"
Manager: "Well, it'll keep me from having to go to that meeting and explain your tickets to half the world! I already know you're doing your jobs, but they only have their reports and I'm required to go if the tickets are not done correctly."
Dev/Tech: "Okay we can do that. What about the actual ticket status field? When it says "Pending/Customer Action" shouldn't that be a criteria for their report? It's right there, and we have been using it since we never got any training on the business rules about what to use in this ticket software."
Manager: "Doesn't matter. If you go in on Monday nights and put a 'Next Action' in every ticket you have open, that meets the criteria. We also think you might have to type a space or a period into the ticket description to update the 'Last Updated' date/time field, because it appears that it doesn't update when you add 'Next Action' activities, but we're still checking on that one."
Dev/Tech: "Awesome. Well at least we know. Why did we install this expensive bloatware ticket system that cost the company hundreds of thousands of dollars in consultants just to get it working, when the old system worked fine?"
Manager: "Doesn't matter. You're not management, you don't get to ask those questions."
Dev/Tech: "Doesn't have anything to do with the CEO of the ticket software living in the same neighborhood in California as our CEO, does it?"
Manager: "Really?"
Dev/Tech: "Really. They probably play golf together."
The names have been changed to protect the "innocent", on this one -- of course. And the bloatware is web-based Siebel versus the desktop version. One customized for a giant company, the other customized (very well) for a small one, by managers who knew what data they wanted out of it BEFORE it was deployed.
Fully expecting the "Siebel cleanup task-force" in about a year or two, complete with "representatives" from each department who will be as ignored as they were during the roll-out of THIS version.
We get nice timely updates in e-mail every couple of weeks, sometimes every month, about the four or five little bugs they "worked hard on fixing" in fields only 10 people in the company use... those are nice. They apparently have a whole staff of developers and consultants working on these bugs, forever.
Ticket systems run amok are always my favorite "mangement has no idea what they want" stories... they drive the requirements, spend years making "mock-ups" of the screens and reports, and then seem to find out later that that's NOT HOW THEIR OWN BUSINESS RUNS and never did. Very entertaining, but wastes a lot of time and money...
Oh well. Once someone TELLS you how to manipulate the ticket system the way management wants it manipulated, the game's over. You ignore every other of the 40 or so fields and drop-downs and do your work, make notes, and get things done as usual... the notes tell the story for your 1st level manager, and they're responsible (as always) for your work anyway, so the ticket system's reports are massa
The normal people of the world, who actually need to get shit done with their Linux machines, and know that manufacturers don't get it, and don't give a shit... will continue to use NDISWrapper and ignore it's GPL status or anything else related to it.
They'll happily run native drivers if the kernel devs can ever figure them out, but meanwhile they've got shit to do... and no fiscal or moral reason to care.
The root cause of most of this is that "software" is perceived as "hard" to create and develop correctly. The vast majority of coders don't code to any standards, don't reuse code that's known and TESTED to work correctly, and generally -- act like two year olds when management or users demand better.
They want the title "Software Engineer", but they don't want the RESPONSIBILITY that goes with the title. Civil Engineers put their names on things and are INSPECTED by outside third parties. Bridges and roadways falling down are considered career-limiting moves by a Civil Engineering group. Building codes, and/or other build/design rules are the underpinnings of every other style of "engineering" on the planet... try getting a new aircraft through the FAA's certification process inexpensively, if you think you can -- and these types of safeguards and rules are ALWAYS pooh-poohed by the coddled "software engineers".
They state that these and other legal measures are taken to make sure that most "engineered" products, critical for our daily lives, aren't necessary in software. That they would add cost and no value. But then I read SANS and other security-related trade rags that talk about the constant loss of personal data, bad (very bad) security holes in VERY expensive software packages with no patches or even admission that the problem really exists by the software company, etc.
It's time for the insanity to stop. Engineers that engineer software need to grow up and start acting like computers aren't "mystery" boxes. They're not. GOOD software with few problems CAN be written. There's NOT a need for the weekly "patch merry go-round". People WILL pay for something better... they just don't know it exists because software people continue to make excuses for our profession. It's getting old.
There *are* satellite broadband services that upload via satellite -- you've fallen behind the times on that one. Hughes and WildBlue are examples.
(Not saying they're cheap, fast, or low-latency... but they're out there.)
Comcast also has "commercial" levels of service beyond the "residential" services. I have a 6Mb/1Mb guarantee from them at a higher price than residential service, and the "PowerBoost" allows 12Mb/2Mb burst up/down.
I've tested it regularly with large files, and I regularly see higher than 6Mb down continuously.
You get what you pay for. Like in everything.
So if everyone switches to OpenDNS, then eventually their service will suck too... how are they planning on handling this growth for free?
But a browser can be coded to NOT respond to things that it isn't intended to receive.
Your argument is invalid.
If you can't predict what you'll be served, you DEFINE what you will RESPOND to, and you don't respond or do ANYTHING with inappropriate input.
Basic programming 101 course material there, man.
Yes it does.
Desktop application code, you must admit, is is pretty crappy these days... when it comes to security. Name one desktop application that hasn't had MULTIPLE security patches in the last year.
Most security experts also agree that this "patching everything and then patching it again" is killing the real gains found (monetary) by utilizing the technology in the first place. At some point if it was written badly enough to need continuous patching, the support staff required to keep up with patching, internal certification/testing, etc... grows exponentially beyond what most organizations gained by switching to using computers for certain tasks in the first place.
There *are* examples of how to code nearly flawlessly, and procedures around that. They're usually found behind the closed doors of military and defense systems contractors, so they're not publicized much. Same thing for MOST embedded systems where lives are on the line, including transportation systems, satellites, etc.
The software quality in those systems is arguably quite a bit higher than the typical software in the "desktop" computing world, but one could argue that with MORE of us using the desktop environment software for day-to-day life these days, the risks and disadvantages of not treating such software as "mission critical" as embedded systems, is a huge oversight or omission on the part of the "software industry".
How many of us use web browsers (ESPECIALLY WEB BROWSERS) for online banking, command and control of multi-million-dollar systems, and just about everything these days? Isn't a browser then more important to treat the code as if it MUST BE RIGHT THE FIRST TIME (even if it isn't), than just about any other utility piece of software, or any embedded control system?
Zero-bugs may not be possible, but the current number of bugs is far beyond what the industry can bear, long-term. It's simple financials... if desktop computing and the server hardware and add-on software (virus scanners, malware scanners, etc etc etc... and the never-ending treadmill of additional hardware requirements to run all the SCANNERS) continue up in price for organizations, IT is on a never-ending downward spiral that won't stop until computers are locked back down to bare minimum job-handling capability... a dumb terminal...
In fact, systems that never left the dumb terminal environment, have done well throughout the years. Only fairly recently were airline reservations moved from the so-called "archaic" mainframe-based systems and command-line/text-only interfaces, to something slightly more modern. Ever wonder why?
I get the distinct impression that most "desktop application coders" either don't have or don't want the discipline necessary to produce quality software similar to the embedded and life-critical systems mentioned above... even if they could. They would rather whine and make excuses about "find me some bug-free code".
How about we find them some MUCH better quality code, and show them some techniques for writing code like THAT and not the cruddy mess we currently have for "security" on the desktop/utility computing environment?
They act like ANY level of bugs is "acceptable" but that PROVING they're making continuous improvement in LOWERING the number of bugs is too inconvenient. Then you add in the love affair with changing the underlying tools, languages, and IDE's, and it's amazing anyone ever gets anything done, but not a surprise that there's NO MEASURABLE IMPROVEMENT in the number or quality of bugs in almost three decades of popular computing.
It's a machine -- it only does what it's told to. If the software's too complex to debug it correctly, someone made it so. Those "someones" have either been working in the field for that same 30 years, or have been managing the new people incorrectly, and not requiring code re-use and standards to avoid the mistakes they made 20 years ago, when they were coding.
Have the bugs gotten smaller? Nope. Less frequent? Nope. In fact there's bigger holes found every day, and more of them. The code monkeys need to stop, and THINK, and ENGINEER their next solutions.
The wrote the crap code (or borrowed it from somewhere else) in the first place.
Whhhaaaaah... I released GARBAGE with security holes in it and someone else didn't tell me before they released their fix!
Is about what all this amounts to.
STOP WRITING CRAPPY INSECURE CODE, REFUSING TO TEST IT, AND NOT BUILDING TO ANY TYPE OF SAFETY STANDARDS - GROW UP AND BE REAL ENGINEERS... and the problem solves itself.