1) Applications that only run under SCO. Take for example, the two big COBOL (no laughing) run-time environments, MicroFocus and RMCobol. They actively check to make sure that the run-time is SCO.
2) Propritary drivers. The best (and sadest) example of this is Digiboard EP/CX remote serial concentrators. GREAT hardware (ever watch an RS-232 device get hit by lightning and still work afterwards?), but driven by product managers who will not return calls, email, faxes, and even hang up on you when you ask about FreeBSD or Linux drivers. "We only deal with reputable firms".
They're soon not going to not deal with anyone. I've surplused $50k worth of their stuff instead of buying another $100k just because of their inaine driver philosophy. There are enough companies with clues that we don't need to deal with clueless ones.
The whole thing comes down to what one of my friends said after working (and leaving SCO after 18 months) there, their unofficial motto was: "Don't do drugs... in the halls". Their managers have perpetually done drugs and that has made all the difference.
First, the classic book on Multics - The Multics System; An Examination of Its Structure by the late Elliott Irving Organick is a snap-shot of a work in progress. If you've read the book, you'll have a good feeling for what the group was doing, but not particularly of what Multics finally turned out to be.
Second, there is recurring discussion in the USENET news group alt.os.multics about a re-implementation of the Multics hardware environment (including tagged memory) on something like a PCI card. Then use the PC as the I/O system. This, of course, is possible because ASICs and DRAM are perpetually getting less and less expensive. The acutal ownership of Multics will have to be worked out before that can happen. Someone should enourage the present owners to GPL the source and binaries.
It always strikes me sad that Multics is old, but its O/S ideas are, in large part, state of the art. It says something pretty vile about contemporary O/S and architechture research, experimentation and design. VonNeuman CPUs and Unix are not horrible designs (thus they've been successfull), but if we want orders of magnitude improvements now, then it is time to re-evaluate the basics. Seymour Cray came up with the majority of the improvements (hacks if you will) to the Von Neuman architechture in the 1960s and 70s. Intel (et al) has been living off those ideas for two decades. It's time for new ideas (yes, perhaps like the late Intel ipex-432).
Finally, I wish Linus had read about Multics, before he re-implmented Unix. We'd all be in better shape if that were the case. Then Linux could genuinely be said to be state of the art, not just state of the practice.
As someone who has around 60 FreeBSD systems running in commercial and educational service all over the midwest as singles and compute clusters, this 'merger' makes me highly nervous. This smells of some folks wanting to suck from the IPO cow and to hell with the products.
I originally looked at BSDI and thought the product & services were not nearly worth the money. Further, in talking with the people at BSDI I didn't like their tone towards lowly scum customer (me) out here in hicks-ville. That's why I started with FreeBSD slightly before 2.0.0. It's met my needs and my customer's needs very well. Now we have this mess.
It's too early to have a new project called "FREE! FreeBSD", but the dribble in this article may have me registering a few new domain names just in case...
Note here that never is not an option. Greed kills. The old BSDI wasn't IPOable, but this mess probably is because it has the WC cash stream.
Finally, after the IPO and after the 'new economy' has it's correction to sync(2) with the 'real economy' where will this IPOed mess then be? I liked it when the FreeBSD support organization was tangent to a real business not inflated by gross over-expectations of an insane "tech-happy" stock market. This whole thing makes me just sick.
To quote Watergate's 'deep throat', "Follow the money!".
TI isn't a player in PCs and they're unable to effectively make money in the field. Thus SPIN requires them to depreciate the area as unglamorous, "over", etc...
It would be wiser for them to say, "we think there are buckets of money waiting for us (via DSP) in the wireless data marketplace."
Given the DeCSS mess will be resolved in court where excellent (read expensive) lawyers will decide the results (round after round). How well funded are you? Will you need monetary support to robustly and sufficiently defend yourself? If so, how can 'the community' help?
(Perhaps Andover.net could operate a fund for this pariticular case?)
With the death of the Soviet Union, the West has missed the golden opportunity to 'Marshallize' the former Soviet Union.
We simply had no leaders willing to do the work needed to look at the big picture. Now, already, we have dozens of cases where there could have been a non-violent result if there was a viable economic system in place.
My vote for years has been General & Secretary of state George Marshall. His legacy will outlast anything Hitler did. Otherwise one pretty much needs to select Ghandi.
I have from BYTE #5 on, having joined the revolution slightly late.:-)
I thought as soon as McGraw-Hill purchased BYTE there was trouble. Carl Helmers left soon afterwards and the editorial quality began to drift. By the early 1990s (pre the change to 'business' which IMHO was already owned by the likes of ComputerWorld and InfoWorld) there were people writing stories that simply didn't understand where "the small systems journal" had come from. At the same time, they nearly doubled their advertisement rates and poof, 500 page BYTEs were no more. I wrote several letters asking for a return to the good old days and was told that it wasn't economically possible to keep high-skill technical writers writing for BYTE. At that point it was clear it was over.
When CMP purchased them, I went "well maybe" but in the end was even cheated out of the remainder of my subscription. So a POX apon them.
I didn't see any reason that McGraw-Hill couldn't have scaled Byte's readership back and made it back into a highly technical magazine that it started out to be. The M-H folks must just have loaded up all their publications with unbelievable overheads so that wasn't possible.
But hey, we're just the folks that pay the bills. Who gives a damn about us anyway?
One of my biggest bitches about/. is the constant re-invention of the wheel. As a group,/.ers tend to be 'I can do that' hackers while ignoring Science.
Perhaps this review, along with its total bluring of the line between Science and hacking is a good place to discuss this.
Hacking is not science. Science is not hacking. The reason the 'scientific method' came into existence is to eliminate unfounded claims & hucksterism and separate the unfounded from the demonstrably provable./. would be infinitely more useful if those that posted were supporting Science, not 'oh I did that last night so there, huh huh huh.'
I thought this review was crummy. It figuratively lowered one of history's great people into the moras of code hacks. He asked 'why', not "oh isn't this cool." A few more why's eligantly explained would make this a much better place.
Rather than have more wild speculation back here on 'page 2' of reader comments (overload mode being the absolute norm these days), here are two good references, each giving a different perspective. Slashdot could even have a 'see Amazon, give us a kickback' button for such subjects as this...
The Puzzle Palace : A Report on America's Most Secret Agency by James Bamford (c) 1983, ISBN 0140067485 (paper) Viking Press
This is a relatively old (15+ years!) book that gives a functional overview by way of covering the history of how the NSA got to where it is (well at least up to 1983ish). Previous respondents claiming knowledge of NSA's past should read first, then write.
Then to understand the NSA in contemporary times, one should understand the entire US intellgence community. I suggest:
The U.S. Intelligence Community by Jeffrey T. Richelson 4th ed (c) 1999, ISBN: 0813368936 Westview Press
Slashdot's signal to noise ratio on this subject was pretty poor. What can we do to improve the random, groundless, spouting that people seem to be doing? Moderation didn't seem to keep the factless down this time.
Having been working as an engineer (not software for once) for three years where part of the professional code of ethics is "don't bribe public officials", and yet the financial disclosures that all the politicians file in my area show mucho 'contributions' from engineering firms, I've come to the conclusion that codes of ethics pretty much don't work. It isn't important or expediant.
In the world of lawyers, their code of ethics is nearly a total joke. The advent of lawyers that show up on your doorstep 12 hrs after some public disaster is good enough proof of that.
In the world of medicine, people die every day in the USA from doctors that are not interested in care, but instead on the 7.5 minutes they can 'give' each patient in an office visit. Sometimes the problems don't fit in 7.5 minutes... Having just had a relative die of non-care --no one took the time to figure out really what was wrong over 13 days-- while in an Intensive Care Unit, no one cares. As a result codes of ethics mean nothing and are worse than useless as it allows people to hide behind meaningless words created by people who haven't been there nor done that.
As long as there is a 40% unfilled demand for people to drool over keyboards and pretend to be programmers & software engineers, then ethics, morals, and even legality will all mean much less than they should. Just read slashdot comments to see much of the underbelly of the industry.
Codes of Ethics mean something if they are generally agreed apon. At the moment programmers can't even agree on the planet they're on, better yet how to really behave. Maybe someday... Certainly not now.
Nickel-Iron batteries have been around a very long time. They are still available and offer considerable benefit for some kinds of uses. They have VERY long deep-cycle lives (40+ years is typical for daily use) and thus are great for un-interruptable power use. If you are in the USA, you've almost certainly talked on a public phone exchange held up with Ni-Fe cells. They also can be run totally dry and still be recovered far better than any other kind of wet cell.
The down side of such cells is low energy density vs weight, so the volume of the cells is large compared to things like wet NiCads. These also have a higher than NiCad self-discharge rate and consume more water than Lead-Acid or NiCad cells.
Ni-Fe technology uses a highly alkaline electrolite.
So perhaps they've invented a new way to deal with Fe cells, but iron has been in the battery domain a very very long time.
Need more on Ni-Fe batteries? Ask your favorite search engine.
Once apon a time, I used to teach this stuff. Doing it is much more fun.
Design Documents are just part of the whole theme of a well engineered software system. Much depends on the system being constructed and what it needs to interface with. I've written and used extremely detailed design documents (this BIT goes here, that BIT goes there) for a project where all the pieces were being implemented in different geographic locations. When the thing was assembled it even worked! On the other hand, I've been gratefull for a very brief, high-level 'how this fits into the big picture' design statement that described a report system that just sucked from zillions of different data sets that were previously defined elsewhere. So it depends on what the goals of the project are.
In 'open' software, I'd much rather have sections of documentation inline with the code that say things like, "At this point we know XXX and we're now going to YYYY." Tell me the high level story as it is less apt to rot over time compared to the minutia.
Finally, Design Documents that are used will be updated. DD that are just worthless trash from the outset, no one will care if they further get bit rot.
If you have not read Fred Brook's book, "The Mythical Man Month", now would be a good time. Your question certainly is bigger than a ask/. as many other respondents have previously noted.
P.S. Revision control and MS Word documents? Doesn't the constant change of format of MS doc's cause you to worry that your documents will not be readable later in the products life? I'd be using "Plain Old Text" as ISO-Latin1 is not apt to go out of style anytime soon.
There are not a bunch of good books that directly address traffic simulation. This is in part because there is a massive mis-match between the research community and the practitioners doing the work. It is also because there is no general acceptance as to how to do this and how to measure it.
Search Amazon or Barnsandnoble with the keywords "Transportation Planning" or "Intelligent Transportation Systems" for texts.
Finally, because this is a simulation, the lessons taught by: Simulation Modeling and Analysis by Law & Kelton (ISBN 0070366985) must be observed. TranSIMs perhaps needs a refresher in the basic statistics that control all simulations.
It would be very interesting to see Brill's Content spend some research dollars looking at John Markov's (perhaps improper) roll (along with the NYT) in this entire mess.
The AXIS 3-camera server (AXIS 2400) is around (US)$1k without any cameras. But it sounds like this fellow needs six cameras... so $2k for AXIS Servers.
The savings can come with the actual cameras. I have used, with great success the color one (CCDCC-1) from Ramsey Electronics (http://www.ramseyelectronics.com/) in other applications and don't see why this wouldn't work pretty well here too. $200/each (w/cover, power supply & interface board)
So total cost is $2k + (6 * $200) or $3,200 for six cameras +/- cables. So more like $550/camera.
As someone who read the first couple of years, I quit when the style got to overwhelming the substance. The issue that did it for me had purple page numbers on often bright pink/orange pages. Since I (and a measurable percent of the rest of you) am significantly color blind red/green it made the index & 'see page nnn' totally useless. Enough was enough. Reading crack pot ideas now and then was one thing, having to search under hi-intensity light for the damn page numbers was genuinely over-the-top.
Then, later, suckered into the perfect cover of the HAL 9000, that article was a new and very deficient low water mark that finished it's fate.
I too am a manager (and have been in the industry in one form or another since 1972) and I've noted several newer trends.
1) There are an increasing number of 'geeks' that don't have a good background on what they're doing. "I can recompile the XXX kernel and you can't" doesn't cut it when what is really needed it hard core science. I don't need, nor now want, a geek that is very bright, but doesn't know the background in CS. There is no sense in re-inventing zillions of wheels. Engineering does it all the time and we don't have the time in CS to screw around with things that have already been solved. I get a big warning sign from places that "oh we hired him/her straight from high school for this language development project." to which I think, "oh great, no language theory, no background on things that have been tried and failed, no development methodology, no...".
2) Pretend Geeks. I'm now pretty good at flushing what I call 'pretend geeks'. These are not 'Geeks in training', but people who think that they can dress down, be rude, etc but not do the work but enjoy the perks. There are lots of places I've consulted at that have these folk on staff. "lookie, SEE WE HAVE A GROUP OF GEEKS TOO!" Like it was a token minority that they were required to have. I think this comes from the deserved reputation of Geek-dom intermixing with gross scarcity of even vaguey competent computer people. My filter is to switch to Geek (like changing to Spanish!) and find out if the applicant is a real geek or just dressing up like one. Being a former -tea shirt- programmer does have its advantages.
3) Like the previous respondent, being an umbrella that keeps the company crap away is mostly what I do. I also do sanity checking to be sure that the path being followed isn't already understood to be a lemon. A few kind, but rigorous, design reviews tends to keep the 'project killed at the end' moral killers to a minimum. It sill happens, but that's life.
Slashdot Mirror
Simple, two reasons:
1) Applications that only run under SCO. Take for example, the two big COBOL (no laughing) run-time environments, MicroFocus and RMCobol. They actively check to make sure that the run-time is SCO.
2) Propritary drivers. The best (and sadest) example of this is Digiboard EP/CX remote serial concentrators. GREAT hardware (ever watch an RS-232 device get hit by lightning and still work afterwards?), but driven by product managers who will not return calls, email, faxes, and even hang up on you when you ask about FreeBSD or Linux drivers. "We only deal with reputable firms".
They're soon not going to not deal with anyone. I've surplused $50k worth of their stuff instead of buying another $100k just because of their inaine driver philosophy. There are enough companies with clues that we don't need to deal with clueless ones.
The whole thing comes down to what one of my friends said after working (and leaving SCO after 18 months) there, their unofficial motto was: "Don't do drugs... in the halls". Their managers have perpetually done drugs and that has made all the difference.
First, the classic book on Multics - The Multics System; An Examination of Its Structure by the late Elliott Irving Organick is a snap-shot of a work in progress. If you've read the book, you'll have a good feeling for what the group was doing, but not particularly of what Multics finally turned out to be.
Second, there is recurring discussion in the USENET news group alt.os.multics about a re-implementation of the Multics hardware environment (including tagged memory) on something like a PCI card. Then use the PC as the I/O system. This, of course, is possible because ASICs and DRAM are perpetually getting less and less expensive. The acutal ownership of Multics will have to be worked out before that can happen. Someone should enourage the present owners to GPL the source and binaries.
It always strikes me sad that Multics is old, but its O/S ideas are, in large part, state of the art. It says something pretty vile about contemporary O/S and architechture research, experimentation and design. VonNeuman CPUs and Unix are not horrible designs (thus they've been successfull), but if we want orders of magnitude improvements now, then it is time to re-evaluate the basics. Seymour Cray came up with the majority of the improvements (hacks if you will) to the Von Neuman architechture in the 1960s and 70s. Intel (et al) has been living off those ideas for two decades. It's time for new ideas (yes, perhaps like the late Intel ipex-432).
Finally, I wish Linus had read about Multics, before he re-implmented Unix. We'd all be in better shape if that were the case. Then Linux could genuinely be said to be state of the art, not just state of the practice.
I originally looked at BSDI and thought the product & services were not nearly worth the money. Further, in talking with the people at BSDI I didn't like their tone towards lowly scum customer (me) out here in hicks-ville. That's why I started with FreeBSD slightly before 2.0.0. It's met my needs and my customer's needs very well. Now we have this mess.
It's too early to have a new project called "FREE! FreeBSD", but the dribble in this article may have me registering a few new domain names just in case...
I have a new poll question for /.
"When will the 'new' BSDI IPO?"
[ ] 1 month
[ ] 2 months
[ ] 6 months
[ ] 12 months
Note here that never is not an option. Greed kills. The old BSDI wasn't IPOable, but this mess probably is because it has the WC cash stream.
Finally, after the IPO and after the 'new economy' has it's correction to sync(2) with the 'real economy' where will this IPOed mess then be? I liked it when the FreeBSD support organization was tangent to a real business not inflated by gross over-expectations of an insane "tech-happy" stock market. This whole thing makes me just sick.
Yahoo says:h ackers_1.html
http://dailynews.yahoo.com/h/nm/20000208/wr/tech_
and that others were hit.
To quote Watergate's 'deep throat', "Follow the money!".
TI isn't a player in PCs and they're unable to effectively make money in the field. Thus SPIN requires them to depreciate the area as unglamorous, "over", etc...
It would be wiser for them to say, "we think there are buckets of money waiting for us (via DSP) in the wireless data marketplace."
Given the DeCSS mess will be resolved in court where excellent (read expensive) lawyers will decide the results (round after round). How well funded are you? Will you need monetary support to robustly and sufficiently defend yourself? If so, how can 'the community' help?
(Perhaps Andover.net could operate a fund for this pariticular case?)
See the story at cnn.
A good (and getting better) product that lacks much in the land of documentation.
With the death of the Soviet Union, the West has missed the golden opportunity to 'Marshallize' the former Soviet Union.
We simply had no leaders willing to do the work needed to look at the big picture. Now, already, we have dozens of cases where there could have been a non-violent result if there was a viable economic system in place.
My vote for years has been General & Secretary of state George Marshall. His legacy will outlast anything Hitler did. Otherwise one pretty much needs to select Ghandi.
I have from BYTE #5 on, having joined the revolution slightly late. :-)
I thought as soon as McGraw-Hill purchased BYTE there was trouble. Carl Helmers left soon afterwards and the editorial quality began to drift. By the early 1990s (pre the change to 'business' which IMHO was already owned by the likes of ComputerWorld and InfoWorld) there were people writing stories that simply didn't understand where "the small systems journal" had come from. At the same time, they nearly doubled their advertisement rates and poof, 500 page BYTEs were no more. I wrote several letters asking for a return to the good old days and was told that it wasn't economically possible to keep high-skill technical writers writing for BYTE. At that point it was clear it was over.
When CMP purchased them, I went "well maybe" but in the end was even cheated out of the remainder of my subscription. So a POX apon them.
I didn't see any reason that McGraw-Hill couldn't have scaled Byte's readership back and made it back into a highly technical magazine that it started out to be. The M-H folks must just have loaded up all their publications with unbelievable overheads so that wasn't possible.
But hey, we're just the folks that pay the bills. Who gives a damn about us anyway?
Even here there is a rational debunking.
e /0799letters.html
http://www.scientificamerican.com/1999/0799issu
Art Bell or Art Bell guests as a quoted sources? What will be next? The Easter Bunny? Santa? Marvin the Martian?
:-)
One of my biggest bitches about /. is the constant re-invention of the wheel. As a group, /.ers tend to be 'I can do that' hackers while ignoring Science.
/. would be infinitely more useful if those that posted were supporting Science, not 'oh I did that last night so there, huh huh huh.'
Perhaps this review, along with its total bluring of the line between Science and hacking is a good place to discuss this.
Hacking is not science. Science is not hacking. The reason the 'scientific method' came into existence is to eliminate unfounded claims & hucksterism and separate the unfounded from the demonstrably provable.
I thought this review was crummy. It figuratively lowered one of history's great people into the moras of code hacks. He asked 'why', not "oh isn't this cool." A few more why's eligantly explained would make this a much better place.
Rather than have more wild speculation back here on 'page 2' of reader comments (overload mode being the absolute norm these days), here are two good references, each giving a different perspective. Slashdot could even have a 'see Amazon, give us a kickback' button for such subjects as this...
The Puzzle Palace : A Report on America's Most Secret Agency
by James Bamford
(c) 1983, ISBN 0140067485 (paper)
Viking Press
This is a relatively old (15+ years!) book that gives a functional overview by way of covering the history of how the NSA got to where it is (well at least up to 1983ish). Previous respondents claiming knowledge of NSA's past should read first, then write.
Then to understand the NSA in contemporary times, one should understand the entire US intellgence community. I suggest:
The U.S. Intelligence Community
by Jeffrey T. Richelson
4th ed (c) 1999, ISBN: 0813368936
Westview Press
Slashdot's signal to noise ratio on this subject was pretty poor. What can we do to improve the random, groundless, spouting that people seem to be doing? Moderation didn't seem to keep the factless down this time.
Two good sources of further informtation:
David Kahn's book (considered the definitive reference on cryto through the end of WWII):
The Codebreakers
David Kahn
ISBN 0-02-560460-0
MacMillan Publishing Company
(c) 1967
and a newer book (and interesting story):
Between Silk and Cyanide - A Codemaker's War
Leo Marks
ISBN 0-684-86422-3
The Free Press
(c) 1998
Both can be found at your favorite library or book seller.
Having been working as an engineer (not software for once) for three years where part of the professional code of ethics is "don't bribe public officials", and yet the financial disclosures that all the politicians file in my area show mucho 'contributions' from engineering firms, I've come to the conclusion that codes of ethics pretty much don't work. It isn't important or expediant.
In the world of lawyers, their code of ethics is nearly a total joke. The advent of lawyers that show up on your doorstep 12 hrs after some public disaster is good enough proof of that.
In the world of medicine, people die every day in the USA from doctors that are not interested in care, but instead on the 7.5 minutes they can 'give' each patient in an office visit. Sometimes the problems don't fit in 7.5 minutes... Having just had a relative die of non-care --no one took the time to figure out really what was wrong over 13 days-- while in an Intensive Care Unit, no one cares. As a result codes of ethics mean nothing and are worse than useless as it allows people to hide behind meaningless words created by people who haven't been there nor done that.
As long as there is a 40% unfilled demand for people to drool over keyboards and pretend to be programmers & software engineers, then ethics, morals, and even legality will all mean much less than they should. Just read slashdot comments to see much of the underbelly of the industry.
Codes of Ethics mean something if they are generally agreed apon. At the moment programmers can't even agree on the planet they're on, better yet how to really behave. Maybe someday... Certainly not now.
Nickel-Iron batteries have been around a very long time. They are still available and offer considerable benefit for some kinds of uses. They have VERY long deep-cycle lives (40+ years is typical for daily use) and thus are great for un-interruptable power use. If you are in the USA, you've almost certainly talked on a public phone exchange held up with Ni-Fe cells. They also can be run totally dry and still be recovered far better than any other kind of wet cell.
The down side of such cells is low energy density vs weight, so the volume of the cells is large compared to things like wet NiCads. These also have a higher than NiCad self-discharge rate and consume more water than Lead-Acid or NiCad cells.
Ni-Fe technology uses a highly alkaline electrolite.
So perhaps they've invented a new way to deal with Fe cells, but iron has been in the battery domain a very very long time.
Need more on Ni-Fe batteries? Ask your favorite search engine.
Once apon a time, I used to teach this stuff. Doing it is much more fun.
/. as many other respondents have previously noted.
Design Documents are just part of the whole theme of a well engineered software system. Much depends on the system being constructed and what it needs to interface with. I've written and used extremely detailed design documents (this BIT goes here, that BIT goes there) for a project where all the pieces were being implemented in different geographic locations. When the thing was assembled it even worked! On the other hand, I've been gratefull for a very brief, high-level 'how this fits into the big picture' design statement that described a report system that just sucked from zillions of different data sets that were previously defined elsewhere. So it depends on what the goals of the project are.
In 'open' software, I'd much rather have sections of documentation inline with the code that say things like, "At this point we know XXX and we're now going to YYYY." Tell me the high level story as it is less apt to rot over time compared to the minutia.
Finally, Design Documents that are used will be updated. DD that are just worthless trash from the outset, no one will care if they further get bit rot.
If you have not read Fred Brook's book, "The Mythical Man Month", now would be a good time.
Your question certainly is bigger than a ask
P.S. Revision control and MS Word documents? Doesn't the constant change of format of MS doc's cause you to worry that your documents will not be readable later in the products life? I'd be using "Plain Old Text" as ISO-Latin1 is not apt to go out of style anytime soon.
There are not a bunch of good books that directly address traffic simulation. This is in part because there is a massive mis-match between the research community and the practitioners doing the work. It is also because there is no general acceptance as to how to do this and how to measure it.
Search Amazon or Barnsandnoble with the keywords "Transportation Planning" or "Intelligent Transportation Systems" for texts.
Finally, because this is a simulation, the lessons taught by: Simulation Modeling and Analysis by Law & Kelton (ISBN 0070366985) must be observed. TranSIMs perhaps needs a refresher in the basic statistics that control all simulations.
It would be very interesting to see Brill's Content spend some research dollars looking at John Markov's (perhaps improper) roll (along with the NYT) in this entire mess.
The AXIS 3-camera server (AXIS 2400) is around (US)$1k without any cameras. But it sounds like this fellow needs six cameras... so $2k for AXIS Servers.
The savings can come with the actual cameras. I have used, with great success the color one (CCDCC-1) from Ramsey Electronics (http://www.ramseyelectronics.com/) in other applications and don't see why this wouldn't work pretty well here too. $200/each (w/cover, power supply & interface board)
So total cost is $2k + (6 * $200) or $3,200 for six cameras +/- cables. So more like $550/camera.
As someone who read the first couple of years, I quit when the style got to overwhelming the substance. The issue that did it for me had purple page numbers on often bright pink/orange pages. Since I (and a measurable percent of the rest of you) am significantly color blind red/green it made the index & 'see page nnn' totally useless. Enough was enough. Reading crack pot ideas now and then was one thing, having to search under hi-intensity light for the damn page numbers was genuinely over-the-top.
Then, later, suckered into the perfect cover of the HAL 9000, that article was a new and very deficient low water mark that finished it's fate.
I too am a manager (and have been in the industry in one form or another since 1972) and I've noted several newer trends.
/her straight from high school for this language development project." to which I think, "oh great, no language theory, no background on things that have been tried and failed, no development methodology, no...".
1) There are an increasing number of 'geeks' that don't have a good background on what they're doing. "I can recompile the XXX kernel and you can't" doesn't cut it when what is really needed it hard core science. I don't need, nor now want, a geek that is very bright, but doesn't know the background in CS. There is no sense in re-inventing zillions of wheels. Engineering does it all the time and we don't have the time in CS to screw around with things that have already been solved. I get a big warning sign from places that "oh we hired him
2) Pretend Geeks. I'm now pretty good at flushing what I call 'pretend geeks'. These are not 'Geeks in training', but people who think that they can dress down, be rude, etc but not do the work but enjoy the perks. There are lots of places I've consulted at that have these folk on staff. "lookie, SEE WE HAVE A GROUP OF GEEKS TOO!" Like it was a token minority that they were required to have. I think this comes from the deserved reputation of Geek-dom intermixing with gross scarcity of even vaguey competent computer people. My filter is to switch to Geek (like changing to Spanish!) and find out if the applicant is a real geek or just dressing up like one. Being a former -tea shirt- programmer does have its advantages.
3) Like the previous respondent, being an umbrella that keeps the company crap away is mostly what I do. I also do sanity checking to be sure that the path being followed isn't already understood to be a lemon. A few kind, but rigorous, design reviews tends to keep the 'project killed at the end' moral killers to a minimum. It sill happens, but that's life.