Multiply the minutes lost by the number of people searching, and we're looking at _lot_ of lost time. Someone else can do the calculation, but even at $10 dollars an hour, that's a lot of money.
The real economic cost of this also includes the lost reputation (good will) to Google as well.
I hope this is incompetence. It could be worse than that.
IBM/Lotus has known about this for a while?
on
ORBZ Shuts Down
·
· Score: 1
The thread in which Ian reported this at Bugtraq has a comment to it saying that the bug had been reported to Lotus in 2000.
"It was reported in vuln-dev list on May, 20 2000 by SMILER in same time with SMTP buffer overflow in Lotus. I wonder why it's not patched yet."
It's two years since the report, so one might expect a fix in Lotus any time now.
Re:Release frequency, release engineering thoughts
on
Linux 2.4.18 Released
·
· Score: 1
I was actually more saying "thanks". I don't pay for most of this software, and what I do pay is a laughable fraction of the cost of development and delivery. I figure that at at least I can say nice things.
This is a marketplace of ideas and technologies -- not a battlefield. And markets require the flow of capital, whether it's based on gold, the faith and credit of the government, on reputation, or on intellectual property.
For what it's worth, I'm not a fan of C++. (Whew, there, I said it!)
Release frequency, release engineering thoughts.
on
Linux 2.4.18 Released
·
· Score: 4, Insightful
There is a natural rhythm to the frequency of a successfully released software system, which is an indescribably complex function of the size of the system, the size of the releasing team, the maturity of the software, the sophistication of the end user, and the cost of making mistakes.
What is an ideal release frequency for one point in this space, is not at another.
At one point I worked at a DOS extender company (Rational Systems, not related to Rational of California), and we released the software every week. The system was small, the team was small, the customers were very sophisticated, and the value of adding new features was very high. We were praised for being responsive. Three years later, the software was much bigger, the release cycle was down to 2 times a year, and the value of not adding new bugs to the old features was very high. We still got good marks for technical support.
Unlike most commercial software, it's hard to point at revenue streams for Linux that justify the midlife software development expenses like full-time, paid-for, this-isn't-fun-but-it-has-to-get-done release engineering. Although there is a large virtual software team for this OS, I strongly suspect that there is less infrastructural support than you get with old fashioned, iron vendor supported systems like Solaris, HP-UX, et al. TANSTAAFL, folks.
Don't get me wrong, I use Linux daily, my servers run on it, and I depend on a variety of other open source software (particularly Python!). I even buy RedHat/KRUD releases just so that some value flows back into the release process from a happy recipient. But I sometimes feel like holding my breath while installing that next kernel release!
TANSTAAFL -- There ain't no such thing as a free lunch. Thanks, RAH, wherever you are!
I was working in a software startup in a 4th floor walkup in the Moleculon building in Tech Square near MIT in the early 80s. Across the landing from me was a small office with two wildly creative guys who were in an educational software startup associated with Seymour Papert. They were busily cutting Lego bricks in half, embedding touch and light sensors, and building systems that used the sensors and motor controls to build really cool robots.
As I recall, all the software was written in a Logo dialect running on an Apple II. The really cool thing was the pilot work they did in schools. I saw video tape of second graders designing and building systems that would sort bricks by colors, or robots that would follow a line drawn on paper. All the things that Mindstorms do now.
At some point company was disbanded, the ideas folded back into the MIT Media lab, and eventually incorporated into the Lego partnership. I don't know what happened to the two guys who did the work.
Have you given any thought to defaults for these scripts which would be task specific>?
"This machine is a pure webserver"
"This machine is my home firewall and family webserver"
"This machine is an internal workstation".
where you could make a coherent set of reccomendations. Security which prevents the work from getting done leads to amateur changes to loosen the security...
Multiply the minutes lost by the number of people searching, and we're looking at _lot_ of lost time.
Someone else can do the calculation, but even at $10 dollars an hour, that's a lot of money.
The real economic cost of this also includes the lost reputation (good will) to Google as well.
I hope this is incompetence. It could be worse than that.
There is a note to that effect on www.security.nnov.ru.
It's two years since the report, so one might expect a fix in Lotus any time now.
This is a marketplace of ideas and technologies -- not a battlefield. And markets require the flow of capital, whether it's based on gold, the faith and credit of the government, on reputation, or on intellectual property.
For what it's worth, I'm not a fan of C++. (Whew, there, I said it!)
What is an ideal release frequency for one point in this space, is not at another.
At one point I worked at a DOS extender company (Rational Systems, not related to Rational of California), and we released the software every week. The system was small, the team was small, the customers were very sophisticated, and the value of adding new features was very high. We were praised for being responsive. Three years later, the software was much bigger, the release cycle was down to 2 times a year, and the value of not adding new bugs to the old features was very high. We still got good marks for technical support.
Unlike most commercial software, it's hard to point at revenue streams for Linux that justify the midlife software development expenses like full-time, paid-for, this-isn't-fun-but-it-has-to-get-done release engineering. Although there is a large virtual software team for this OS, I strongly suspect that there is less infrastructural support than you get with old fashioned, iron vendor supported systems like Solaris, HP-UX, et al. TANSTAAFL, folks.
Don't get me wrong, I use Linux daily, my servers run on it, and I depend on a variety of other open source software (particularly Python!). I even buy RedHat/KRUD releases just so that some value flows back into the release process from a happy recipient. But I sometimes feel like holding my breath while installing that next kernel release!
TANSTAAFL -- There ain't no such thing as a free lunch. Thanks, RAH, wherever you are!
I was working in a software startup in a 4th floor walkup in the Moleculon building in Tech Square near MIT in the early 80s. Across the landing from me was a small office with two wildly creative guys who were in an educational software startup associated with Seymour Papert. They were busily cutting Lego bricks in half, embedding touch and light sensors, and building systems that used the sensors and motor controls to build really cool robots.
As I recall, all the software was written in a Logo dialect running on an Apple II. The really cool thing was the pilot work they did in schools. I saw video tape of second graders designing and building systems that would sort bricks by colors, or robots that would follow a line drawn on paper. All the things that Mindstorms do now.
At some point company was disbanded, the ideas folded back into the MIT Media lab, and eventually incorporated into the Lego partnership. I don't know what happened to the two guys who did the work.
Have you given any thought to defaults for these scripts which would be task specific>? "This machine is a pure webserver" "This machine is my home firewall and family webserver" "This machine is an internal workstation". where you could make a coherent set of reccomendations. Security which prevents the work from getting done leads to amateur changes to loosen the security ...