Comment Re:Surprised? (Score 1) 186
Not quite, you would definitely be able to tell if that lens was on the field as it would be like CowboyNeal attached to a tripod.
Are you calling CowboyNeal fat?
Comment Commented too early! (Score 1) 123
Volunteer reviewers will be required to have some connection to the broadband industry, although the volunteers will have to comply with rules from NTIA parent agency the U.S. Department of Commerce on conflicts of interest and confidentiality, the NTIA document said. Reviewers must have "significant expertise and experience" in either designing and building broadband networks, educating or training consumers about broadband, or working in programs to increase demand for broadband, the NTIA document said.
This is a lot more reassuring, though reading further on below this part of TFA, they make a valid point in that who would volunteer their time for this, with no personal gain involved? I think that quite a few people would because I would hope that people feel passionate about helping to disseminate broadband to their communities, however people are naturally elusive in regards to their time spent away from their families/friends/moms, especially people in a long work day intensive industry like Telecommunications, and I think the point is valid that not enough people will volunteer much time to something that has no personal benefit.
Comment I hope they take into consideration (Score 1) 123
That there truly is a certain level of knowledge and expertise that should be a requirement for the "volunteers" to participate. I would hate to think someone like my dad, who is the technological equivalent of a sloth, would have any kind of say over this kind of issue.
I do understand that just the knowledge of the opportunity to volunteer would gleen out quite a large portion of the people you wouldn't want making these kinds of decisions, but all the same, it would be frightening if there was no over-sight involved with these decisions by civilians.
Comment I punch a Pepperoni through it (Score 1) 310
and it seems to stay up just fine
Comment Re:Paper? (Score 0, Offtopic) 310
Oh for the Mod points I just wasted back.......
Comment If it doesn't have to be in a single rack (Score 1) 495
Then you could always farm out a petabyte into multiple units that would add up to it and then weight wouldn't be an issue (though dealing with multiple units would be)
Submission + - Exploit Site milw0rm Suddenly Closes (209.85.229.132)
loteck writes: Popular exploit website milw0rm was taken down by its owner on Wednesday. Citing a lack of time to properly keep up with the site, 'str0ke', as he was known in the security community, has apparently removed all access to the milw0rm repository of exploits and security information. Google has a cache of the 'goodbye header' posted, where str0ke writes: 'I wish I had the time I did in the past to post exploits, I just don't :('.
Comment MOD PARENT UP!!!!!!! (Score 1) 192
That is probably the most insightful comment I have seen on this site in years!
Throw more corporations on *nix boxes, or have more *nix boxes running on top of bank/stock/credit card company dBs, and you would see a huge amount of *nix exploits.
It's kinda like wondering why you can't find any mechanics who specialize on the Chevy Nova, no one drives em, so no one fixes em.......and they esplode
Submission + - Monkeys show language recognition (examiner.com)
mmmscience writes: http://www.examiner.com/examiner/x-1242-Science-News-Examiner~y2009m7d8-Monkeys-show-language-recognition The cotton-top tamarin monkeys can apparently tell the difference between suffixes and prefixes. They will turn to face the direction of recorded words when they hear the nonsense syllables "bi-shoy" change to "shoy-bi." The lead author, Ansgar Endress, suggests that this is just like how human infants learn language, by tracking the beginning and ends of words.
Comment Re:cut the frickin guy some slack, he has a point (Score 0, Offtopic) 267
Don't be so absolutely ridiculous.
you're ridiculous
shall we venture further into childishness or can we stop now?
Comment Re:cut the frickin guy some slack, he has a point (Score 0, Offtopic) 267
You're not proving your point. Just give it up. Some people want to read this -- me for instance. Complain to the site admins, not the site readers. You've thrown this discussion way off course. I saw you claim "If you don't like what I've written, don't complain to me, lest you're a hypocrite." Well, honestly, how can anyone NOT read your crap seeing that you've taken up 3/4 of the god damn discussion. Suddenly this entire topic became about YOU and YOU alone.
you mean kinda like the frontpage of Slashdot has become about the RIAA, and the RIAA alone?
Comment OMG PONIES!......oh wait it's turning into text! (Score 1) 134
Just kidding
I think this is actually going to be a REALLY big deal. Especially if they can prove that the eye signatures are truly one of a kind in regards to individuals specific patterns. If this is along the same vain as fingerprints in relation to scarcity, then you may now be reading of what could eventually make things like the need for encryption, or even some forms of basic information security obsolete. That is a BIG frickin deal, and may in fact be of such importance that you may see security/encryption companies try to squash this before it could ever become something more than just an idea.
I think this is definetly something worth keeping an eye on (sorry for the pun)
Comment Re:cut the frickin guy some slack, he has a point (Score 1) 267
AN RIAA shill! ha
And 9/11, well I've been accused of it before....
I just don't understand why these things happen here now, there USED to be integrity in regards to people's opinions and thoughts, there used to be thoughful discussion and if someone disagreed with your view, they would debate you, not flame you and get their buddies with MOD points to mod you into -10 hell, but that was long ago, now a new generation of knuckleheads are flaming/trolling this site, or incorrectly modding people they disagree with into oblivion, and everyone somehow thinks that is OKAY, because instead of you being "RA RA I HATES THE RIAAS TOO AND WANT THEM TO SUX IT AND ALSO OMG PONIES!!!" you merely mention that the mundane minuate detail reporting on this subject being splased all over the front page becomes meddlesome, you get called a "shill" and berated, I had to step up for that, and to say to all the kiddies who type before they think, there is always going to be more KOOl-AID for you to drink, so just keep chugging!
I find it interesting to be kept abreast of this issue as well, but to see it being soooo readily picked apart, and studied, and discussed, while there are other MAJOR things going on, well it just seems a bit silly, I mean FARK outdid SLASHDOT in regards to discussions on how the Internet was making an impact on the IRAN conflict....well that's just whacked........
Comment cut the frickin guy some slack, he has a point (Score 1) 267
I concur with your thought process, and also, in reading the thread down through, think it is a good idea to give the RIAA it's own section. Then you can allow the RIAA-phites to get their daily fix, while keeping the front page diverse.
I understand the whys of how it is always being reported on, but don't understand the thought process behind the editors of this site frequently populating the front page with articles related to an agency that is well known/hated on this site, and promotes the same conversations, from the same people, promoting the same ideals and moralities, through almost identicle threads with the same monotony of names sprouting the same party line b.s that was spouted 6 stories back.
YOU.....ARE.....PREACHING.........TO......THE......CHOIR!
We get it, and we all understand the importance of fighting against the RIAA, but to verbally attack whiledo for simply stating that this dead horse has been flogged enough, well, I thought we were supposed to be intellectuals (thus the "News for NERDS" byline) who discussed a wide variety of ("STUFF THAT MATTERS")
It reminds me of when I first started coming here, and the M$ (nostalgia is the only reason for the "$" sign btw) bashing was going full force! then shifted gears to fights over KDE vs. GNOME, then bashings over the 2000 and 2004 elections (which was awesome)....but one thing happened, those discussions were had, and then STOPPED. However I'm pretty sure discussions regarding the RIAA/MPAA/copyright law/software piracy was still talked about a lot THEN......how can you not see the Parent's point?
Submission + - Book Review: Why New Systems Fail (bfwa.com)
bfwebster writes: "Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level customizable off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon's book is not only useful, it is important.
Phil Simon has written a long-needed and long-overdue book. Most risks-and-pitfalls book in the IT category focus primarily on projects where actual software engineering is the principal activity. However, many of the large, expensive and often spectacular IT project failures over the past 20 years have little to do with software design and development. Instead, they involve a given organization selecting and implementing — or trying to implement — a commercial off-the-shelf (COTS) software package to replace existing legacy systems, either homegrown or also commercial. The reasons for such a move can be many: standardizing IT and data management across the enterprise, seeking new functionality, retiring systems that are no longer supported or supportable, and so on. By so doing, the firm (usually rightly) thinks to avoid the risks and expense of from-scratch custom software development. However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch. A quick search on the terms "ERP" and "lawsuit" shows just how mistaken that idea can be.
Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project. He covers the complete lifecycle of such projects, starting with the typical expectations by upper management ("Fantasy World") and following it through system selection, implementation, and production, along with a final section on how to maximize the chances of success. Along the way, he uses several real-word case studies (with names changed), as well as a few hypothetical ones, to demonstrate just how such efforts go wrong.
What Simon writes is spot on. For roughly 15 years now, my primary professional focus has been on why IT projects fail. I do that both as a consultant (brought in to review troubled projects to get them back on track) and as a consulting or testifying expert (brought in to review troubled or failed projects now in litigation). I have reviewed hundreds of thousands of pages of project documentation and communication; I have likewise traced or reconstructed project histories for many major IT projects, including enterprise COTS projects. It's clear that Simon knows exactly what he's talking about and knows where all the bodies are buried.
The book itself is very readable. Simon's tone is conversational and a bit humorous; he occasionally dives into technicalities that would be lost on upper management, but always comes back to basic principles. The real-world and hypothetical case studies will have those of us who have been on such projects nodding our heads even as we occasionally wince or shudder. His coverage is exhaustive (and at times a bit exhausting), but his goal appears to be to give those managing and overseeing such projects the information they need to navigate the shoals. He goes into detail about COTS pitfalls such as project estimation, vendor selection, use of consultants, group responsibility, integration with legacy systems, data conversion, and report generation.
The first section of the book covers how and why firms decide to initiate a major COTS project. Besides the "Fantasy World" section that compares management expectations to what really happens, the book also covers why firms hold onto legacy systems, why they buy new (replacement) systems, and how they can (or should) make the decision among building a custom system, buying a COTS system, and "renting" enterprise software via a web-based software-as-a-service (SaaS) vendors such as Workday and Salesforce.
The second section covers COTS system selection. The book divides current ERP and COTS vendors into four different tiers based on company size and use (e.g., SAP, Oracle and BaaN are all Tier 1) and warns of the, ah, enthusiasm of vendor salespersons. (Old-but-still-timely joke: What's the difference between a used car salesman and a software salesman? The used car salesman knows how to use his own product and knows when he's lying.) The book then raises up front an issue often left (by customers) until much later: how will business processes change as a result of the COTS system we're acquiring? It then talks about selecting, if necessary, a consulting firm to help with the installation and project management.
The third section covers the actual COTS implementation process, including the overall strategy, roles and responsibilities, providing the necessary environments, data migration, testing, reports, and documentation. This section is a bit exhausting at times, but it is critical for exactly that reason: far too many firms launch into a major COTS acquisition without fully realizing just what it will take to get the system into production.
The fourth section briefly deals with life after implementation. In theory, one of the reasons a firm buys a COTS system is to avoid doing its own maintenance and support; the reality is that the firm often doesn't like paying those large annual maintenance fees and instead goes off on its own path, which is seldom a good idea.
The fifth and final section talks about how to maximize the chance of success in a large COTS implementation. This section builds upon the rest of the book, which has provided suggestions along the way. In particularly, it talks about how to deal with a troubled project mid-course in order to get it back on track.
Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All. Again, those of us who have been on major IT projects, particularly those involving COTS implementations, will recognize both sets of categorization and the risks they entail.
While Simon is himself a consultant, he is also quite frank about the role consultancies can play in COTS project failures. In particularly, he notes the tendency of consulting firms to underestimate project duration and cost in order to win business, as well as the frequent unwillingness to point out risks and pitfalls to the client, particularly if they represent something the client wants to do.
My few complaints with Why New Systems Fail are mostly production-related. Simon self-published the book; as such, the book's internal layout and graphic design leaves something to be desired. Likewise, his organization and prose could use a bit of editing in spots; he has a propensity for throwing in terms and abbreviations without clarification, and the technical level can vary within a given chapter. Almost all of his footnote references come from Wikipedia; his bibliography is small (just four books) and cites only Brooks from the cadre of authors listed above. None of this makes the book's content any less important or useful, but some of the very people who should be reading this book might well skip or skim it for those reasons. My understanding is that Simon is working on finding a publisher for the book, which will likely solve all those problems.
In the meantime, if you or someone you love is about to embark on an enterprise-level COTS project, get this book; I've added it to my own short-list of recommended readings in software engineering. ..bruce.."
Phil Simon has written a long-needed and long-overdue book. Most risks-and-pitfalls book in the IT category focus primarily on projects where actual software engineering is the principal activity. However, many of the large, expensive and often spectacular IT project failures over the past 20 years have little to do with software design and development. Instead, they involve a given organization selecting and implementing — or trying to implement — a commercial off-the-shelf (COTS) software package to replace existing legacy systems, either homegrown or also commercial. The reasons for such a move can be many: standardizing IT and data management across the enterprise, seeking new functionality, retiring systems that are no longer supported or supportable, and so on. By so doing, the firm (usually rightly) thinks to avoid the risks and expense of from-scratch custom software development. However, the firm (usually wrongly) thinks that such a project comprises nothing more than installing the software, training some users, converting some data, and turning a switch. A quick search on the terms "ERP" and "lawsuit" shows just how mistaken that idea can be.
Simon's book is far more informative and instructive than a Google search and should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise COTS project. He covers the complete lifecycle of such projects, starting with the typical expectations by upper management ("Fantasy World") and following it through system selection, implementation, and production, along with a final section on how to maximize the chances of success. Along the way, he uses several real-word case studies (with names changed), as well as a few hypothetical ones, to demonstrate just how such efforts go wrong.
What Simon writes is spot on. For roughly 15 years now, my primary professional focus has been on why IT projects fail. I do that both as a consultant (brought in to review troubled projects to get them back on track) and as a consulting or testifying expert (brought in to review troubled or failed projects now in litigation). I have reviewed hundreds of thousands of pages of project documentation and communication; I have likewise traced or reconstructed project histories for many major IT projects, including enterprise COTS projects. It's clear that Simon knows exactly what he's talking about and knows where all the bodies are buried.
The book itself is very readable. Simon's tone is conversational and a bit humorous; he occasionally dives into technicalities that would be lost on upper management, but always comes back to basic principles. The real-world and hypothetical case studies will have those of us who have been on such projects nodding our heads even as we occasionally wince or shudder. His coverage is exhaustive (and at times a bit exhausting), but his goal appears to be to give those managing and overseeing such projects the information they need to navigate the shoals. He goes into detail about COTS pitfalls such as project estimation, vendor selection, use of consultants, group responsibility, integration with legacy systems, data conversion, and report generation.
The first section of the book covers how and why firms decide to initiate a major COTS project. Besides the "Fantasy World" section that compares management expectations to what really happens, the book also covers why firms hold onto legacy systems, why they buy new (replacement) systems, and how they can (or should) make the decision among building a custom system, buying a COTS system, and "renting" enterprise software via a web-based software-as-a-service (SaaS) vendors such as Workday and Salesforce.
The second section covers COTS system selection. The book divides current ERP and COTS vendors into four different tiers based on company size and use (e.g., SAP, Oracle and BaaN are all Tier 1) and warns of the, ah, enthusiasm of vendor salespersons. (Old-but-still-timely joke: What's the difference between a used car salesman and a software salesman? The used car salesman knows how to use his own product and knows when he's lying.) The book then raises up front an issue often left (by customers) until much later: how will business processes change as a result of the COTS system we're acquiring? It then talks about selecting, if necessary, a consulting firm to help with the installation and project management.
The third section covers the actual COTS implementation process, including the overall strategy, roles and responsibilities, providing the necessary environments, data migration, testing, reports, and documentation. This section is a bit exhausting at times, but it is critical for exactly that reason: far too many firms launch into a major COTS acquisition without fully realizing just what it will take to get the system into production.
The fourth section briefly deals with life after implementation. In theory, one of the reasons a firm buys a COTS system is to avoid doing its own maintenance and support; the reality is that the firm often doesn't like paying those large annual maintenance fees and instead goes off on its own path, which is seldom a good idea.
The fifth and final section talks about how to maximize the chance of success in a large COTS implementation. This section builds upon the rest of the book, which has provided suggestions along the way. In particularly, it talks about how to deal with a troubled project mid-course in order to get it back on track.
Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All. Again, those of us who have been on major IT projects, particularly those involving COTS implementations, will recognize both sets of categorization and the risks they entail.
While Simon is himself a consultant, he is also quite frank about the role consultancies can play in COTS project failures. In particularly, he notes the tendency of consulting firms to underestimate project duration and cost in order to win business, as well as the frequent unwillingness to point out risks and pitfalls to the client, particularly if they represent something the client wants to do.
My few complaints with Why New Systems Fail are mostly production-related. Simon self-published the book; as such, the book's internal layout and graphic design leaves something to be desired. Likewise, his organization and prose could use a bit of editing in spots; he has a propensity for throwing in terms and abbreviations without clarification, and the technical level can vary within a given chapter. Almost all of his footnote references come from Wikipedia; his bibliography is small (just four books) and cites only Brooks from the cadre of authors listed above. None of this makes the book's content any less important or useful, but some of the very people who should be reading this book might well skip or skim it for those reasons. My understanding is that Simon is working on finding a publisher for the book, which will likely solve all those problems.
In the meantime, if you or someone you love is about to embark on an enterprise-level COTS project, get this book; I've added it to my own short-list of recommended readings in software engineering.
