That restriction is not a restriction of the PDF format, but a specification of correct functioning of the PDF, i.e. access controls are a specification of the format. It is a statement that if someone (you) access someone else's (Bob's) document not permitted by the document's permissions, you are violating Bob's copyright.
The statement says nothing about the document format requiring DRM. Anyone is free to create software that produces PDF documents with no DRM. In fact, it protects the specification itself against someone bypassing access permissions and attributing the failure to PDF. The standard cannot authorize you to violate another's legitimately sought copyright.
PDF is a published, documented format. It is copyrighted, but usable royalty-free in any software. From the specification book PDF Reference
third edition
Adobe Portable Document Format
Version 1.4
"Adobe gives anyone copyright permission, subject to
the conditions stated below, to:
Prepare files whose content conforms to the Portable Document Format
Write drivers and applications that produce output represented in the Portable
Document Format
Write software that accepts input in the form of the Portable Document
Format and displays, prints, or otherwise interprets the contents
Copy Adobe's copyrighted list of data structures and operators, as well as the
example code and PostScript language function definitions in the written
specification, to the extent necessary to use the Portable Document Format for
the purposes above
The conditions of such copyright permission are:
Software that accepts input in the form of the Portable Document Format must
respect the access permissions specified in that document. Accessing the document in ways not permitted by the document's access permissions is a violation
of the document author's copyright.
Anyone who uses the copyrighted list of data structures and operators, as stated
above, must include an appropriate copyright notice.
This limited right to use the copyrighted list of data structures and operators
does not include the right to copy this book, other copyrighted material from
Adobe, or the software in any of Adobe's products that use the Portable Document
Format, in whole or in part, nor does it include the right to use any Adobe
patents, except as may be permitted by an official Adobe Patent Clarification
Notice (see the Bibliography)."
Note: I see the irony of not being permitted "to copy this book...in part". However, as I am writing about the book, US Copyright law permits small quotes to be used and attributed.
Four reasons:
High resolution => more info/sq. inch
High contrast => more legibility in ambient light without backlighting = longer battery life
Static image (power only needed to change image) => longer battery life
Light weight (no heavy glass screen or big batteries needed to create image)
Having seen high quality e-paper on a working device, I can say that it looks like the image has been printed on a laser printer. The long battery life means that it's useful when the information changes on the order of minutes, not seconds, and you can carry it around easily because of the light weight.
No, this is not a replacement for an active screen and GIF's and movies are not realistic uses for it.
Good to see!
However, in a lot of places on this planet, cow dung is more available than sunlight!
By the way, DEKA's prices on these machines are in the $2K-3K range, as I recall. That's a price range that allows charitable organizations (think Non-Governmental Organizations) to fund and deploy them.
These designs fit more with the concepts described in Small is Beautiful by E.F. Schumacher.
Dean Kamen's research organization DEKA is using this technology to produce electrical generators already in demonstration projects in Bangladesh where the fuel is the heat generated by animal manure. Instructions read "Just add S#!t" (No kidding!)
Here's his core technology (http://www.dekaresearch.com/coreTech.html).
He's developing technology that can produce energy with 1) available fuel, 2) no supply consumption, and 3) no harmful materials. He also has developed a water purification system that literally can take sewage and produce potable water. He gives a very persuasive presentation on the benefits of the simple and limited capabilities in the vast areas of this planet where neither energy nor clean water is readily available.
If not, the first step is to develop that plan, along with some business metrics. For example, if the business plan is to support MS servers and MS office applications, and to grow the number of seats by 30%/year, maintaining a support ratio of 100/1, then you know what employees need to know to provide company value (training), how your staffing relates to your customers' needs(sales), and when to bring on staff or seek customers(hiring and marketing/sales).
Your company should also have a financial plan to guide the management of assets, cash flow, and the like.
Finally, if you intend to grow, you're going to reach a point where you will need to separate the functions of technical operation and administration. If a customer is having problems, you can't be trying to get out the payroll, and if you've got to calculate and pay the quarterly tax payment, you can't drop that to solve a customer problem.
These are all business problems which successful businesses have gone through, and unsuccessful businesses have neglected. There's probably a business networking or entrepreneur's group in your area that you could link up with that can share insights and lessons learned. Alternatively, there are plenty of savvy business people in non-competing businesses that you could meet by joining the local business and services groups to developed connections, learn who has expertise, and build relationships that might lead to future business arrangements.
Growing a business is a lot like chess: not all moves are equally valuable and not all pieces are equally powerful; it's knowing the right move to make and when to make it that controls the flow of the game.
It seems that you are presuming what I believe. And, you are presuming my response.
Not all scientists are willing to admit their theories are wrong. Sometimes they ignore some of the data as outliers. And there is bias in experimental design, so a scientist pursuing a research topic is not an unbiased individual.
Finally, the use of hyperbole in an argument does not add weight to it.
whether it's religious truth or scientific truth. And both are limited by our capacity to understand and integrate what we perceive as truth (God or evolution) with how we live our lives.
While there may be signs of God's work, and evidence of evolution, neither can be proven by direct observation, but can only be inferred indirectly and conluded by the application of faith.
I, for one, can have faith in God without feeling the need to put him on a human time scale. In that case, I can say that God created evolution as the means of creation. If God can build a universe, he's certainly not working on my scale in physics. Why should he be bound by my perception of time?
And, in a leap of faith, it seems a bit of hubris to believe that man is the top of the food chain, especially in the setting of today's tribalism.
The DRM (Digital Rights Management, I assume you meant) actually was a Requirement that Apple HAD to implement in order to get the media companies to make their artistic properties (music) available in an electronic format. The iPod and iTunes store allows Apple to deliver songs on demand and with the approval of and payment to the "record" companies.
On a final note, the iPod does not IMPOSE DRM, it only MAINTAINS them. If it bothers you, do as I do: buy the CD and rip it into iTunes, which iTunes supports beautifully. Then you are free do keep it in iTunes or move it to any other device, iPod or not, you choose.
On you're first point, it IS possible to patent a connector if it provides new functionality, but the wiring is not patentable. The likely result of this is that other manufacturers of devices will adopt the signal lines used by the iPod.
many people who also think that their ideas are unique, creative, and valuable, just like you do. So what are the challenges and how do you deal with them?
The Golden Rule can provide a lot of guidance to you. Here are some points to consider:
1. Your ideas are valuable. You deserve and should expect (a) respectful hearing of your thoughts, (b) reasoned responses to your ideas, and (c) civil respect whether you make your case or not.
2. How other people behave are the most important determinants of how they are treated. If they are cynical, they will be isolated. If they are judgmental, they will be excluded. If they make personal attacks, they will be avoided. But if they are helpful, they will be sought out. If they are open to other's suggestions, they will get support. And if they are kind, they will be treated with respect.
3.For each of the above observations, switch the "you" and "they" and think if you are applying that rule.
4. Every idea has its time. Maybe it's not now. If you have a great idea, maybe you are thinking too far ahead or from a different perspective. The best way to have your idea accepted is (a) think your idea through from the perspective of the person or people who will be hearing it, (b) prepare them (perhaps over the course of time) to understand the framework, background, and relevance of what you ultimately want them to adopt, (c) listen to them and seek to understand how they view the world and the way your idea will fit into it, (d) prepare your presentation taking into account a-c, (d) listen to criticisms and suggestions (e) be willing to adapt, and (f) don't take it personally. Many of the best ideas take weeks, months, or years for people's thinking to get to where they can be accepted.
5. If you have trouble working for a supervisor, you may also have trouble working with a customer. Both will make demands, at time seem unreasonable, and not always agree with you. And both pay you to listen to them. Be selective with both, and respectful of both.
6. Remember that life is about the people, and not always about being right or wrong. Learning to work with people is a life skill.
7. Make your work a pleasure. People like to work with happy people a whole lot more than working with unhappy people. Do the hard parts with intensity, but take time to enjoy some of what you do, and the people you do it with, every day. While each day will have its negatives, work to create positive moments or interactions whenever and wherever you can.
Having been at both the bottom and top of the ladder you're on, I can say that I have more good memories of the people I've worked with than of the work I've done. And that's because the work and its value changes over time. What was critical is no longer even useful. But I've tried to learn something from and to share something with every person that I've worked for or with or supervised.
HIPAA (Health Insurance Portability and Accountability Act) was created (1) to guarantee that a person, when leaving one insurance provider, could, by maintaining continuous insurance coverage , not be excluded from coverage for "pre-existing illness." It was not uncommon for people to change employers, have to change insurance providers, and then lose coverage and benefits.
As an "opportunity," the pending regulation was expanded to delve into all kinds of IT issues like privacy and security. The challenge of those potential regulations was that there was no current body of practice in the industry. Finance departments set expectations for financial systems, medical records departments handled release of information, and nursing services made patient status available. Having the IT focus caused much consternation among these other departments, which saw the effort as intrusion into their domains. Many departments simply didn't have the staffing or the time to devote to reading and interpreting the huge number of pages of material.
The most significant failure of HIPAA was to create the sense of "standards of privacy and security" as community standards, or measurements against the norm. There were, in fact, few well-defined and well-articulated standards of expectations in the regulations. Obviously, consultants and auditors and lawyers interpreted everything in the most rigorous, least risky manner, and not the community standards. This fact continues to be the most challenging of the regulations to deal with, because it is a moving target among competing healthcare organizations rather than a defined standard to which all are measured.
Ultimately, HIPAA has had little of the effect on personal information privacy in terms of secure electronic information exchange while giving a name(HIPAA - perhaps the most frequently misspelled acronym in the US) and a PERCEPTION that the law actually defined standard expectations.
Most of the complaints are due to irritation and confusion (and some posts on/. reiterate those points) because the regs are baroque, abstruse, and generally hard to understand - as most legalese is to people who have their jobs to do. An admitting clerk, a nurse, or a med tech receives training in HIPAA, but it's guidance, not a recitation of the pages and pages of language that even experts disagree on. And, staff are taught to be more conservative as a risk management approach to privacy.
There are many more important problems in healthcare than this one. More people are killed by the INABILITY to share critical information than are adversely affected by the ABILITY to err in doing so. Think of the loss of medical information for Katrina victims, and the fact that up to 100,000 adverse medical events leading to death occur EACH YEAR, and put those 17,000 complaints in perspective.
Thank you for your explanatory response. I didn't say that *I* held those opinions, only that a large number of the "then resident" experts in database systems held that opinion. The point I was making was that "conventional wisdom" said that the RM would not be practical because the abstractions lost performance information.
Yes, I know that the relational model is a model. I referred to it as such.
and I have a PhD in computer science in database systems...
As I recall, that's the same sentiment expressed about relational databases when the current state of the art was hierarchical and CODASYL databases in the 70's. All it takes is one really good implementation of the new idea to change this perception.
There were huge debates about the "abstract model" of a relational database that didn't make sense in The REAL WORLD (TRW), because "real" problems were more complex than the relational model and performance would suffer.
I don't know that an XML database is "better", but then again, I don't know that it isn't. Maybe I'll learn something!
A summary should give enough information to portray accurately the article's content. This title misrepresents the facts. The article states that most IT projects end successfully and on time. That's a better than 500 batting average.
Second, the article shows some flaws as well. Because 5% reported that they are always on time and budget, the researchers concluded that 95% were not. That's bad science, letting the observed lead to conclusions about the unobserved.
Finally, the larger the project, the harder it is to define an end point. Tweaking a screen to change a color is certainly doable, but may take weeks to get to in the project list. Implementing a major project that requires lots of unknown elements, such as a system conversion, cannot be considered a plan, but an estimate. And when it comes to estimates, it's very hard to get *anyone* to be less than optimistic.
For an interesting read on project planning and estimating, check out Elihu Goldratt's book, Critical Chain, which shows the application of his Theory of Constraints to project management.
Good observation. The same holds true for many open specifications--there are proprietary extensions allowed in the specification, which are not compatible with other (generally older) versions.
It would seem wise for the people deploying such applications (whoever created the form) to be informed and educated about this issue.
Good technology deployment generally entails using current tools, but making the work product accessible to one's potential consumers is also very important. It seems this fact is lost on some technical people when they go to build something. The whole point of the use of technology is to BETTER reach the target audience.
External auditors and corporate attorneys are evaluated not on their business acumen, but the degree to which they can reduce or eliminate risk. It is the business's board and management that then decides how much risk to take by not accepting some of those recommendations.
"To avoid the risk of an car accident, one should not drive a vehicle on a busy street. Compare that to "Don't drive the wrong way down a busy street." The first is a legal but risk averse statement and the second is a statement of illegality and bears a legal penalty. An accident can occur under both circumstances.
As I read their financial announcement, it appears that the numbers are non-zero, but do not affect significantly any major determinants of financial or business viability nor any actions meant to defraud investors. It appears that the effect of the announcement leads to the knee jerk reaction of some investors which leads to a drop in price which leads to law suits which leads to increased expenses which leads to far more financial effect than the original event as investors react to the law suits and their costs.
Regarding snarfer's company's decisions, that probably reflects a more conservative, risk-averse management team. It doesn't directly follow that the company's failure was due to another company's success.
Companies gain competitive advantage by taking risks. They can keep the advantage by delivering products that customers want.
Whoa there. Before you take Step 1, do a little research on who AK is and what he's done.
He is, in essence, the creator of today's graphical user interface and object oriented programming. He was exploring this stuff before microprocessors made them possible for the average person. I'd definitely put that in the "visionary" column.
I once got his PHD thesis by interlibrary loan and read it. He was decades ahead in his thinking.
I think of email as falling into the following classes:
(a) sources I know
(b) sources I don't know but not spam
(c) spam
The difference I note is that the first two people are not deceptive in their point of origin. If there were a Mail Transport Agent that could, upon connection with SMTP, use the from field and Received field to verify that the originating system has the from address on it, and could then mark the mail "Certified", that would go a long way towards giving the control to the recipient to deal with the content.
To implement this would require the efforts of the honest sources, and would let honest sources decide if and when they wanted to deploy. It would also eliminate the deceptive practice of source routing to use a weakly secured system as a reputable source.
I haven't really thought this out in depth, but I think determining the principles by which good sources can certify their emails is the way to go.
Nice generalization. As a "Corp IT exec," I can say that I would love to be on a reliable, secure, easily supportable personal computer environment... *that supports our applications*. Microsoft did a great job of marketing to developers in the early 90's (that's you guys) so now we are limited in our choices.
Suggestion: show more developers how to build great end user applications that are platform independent, or multiplatform capable with minimal effort.
How:
1. Pure HTML apps with ECMAscript (that javascript standard). Look at Konfabulator as an example.
2. Build java apps that run anywhere (don't use the fancy stuff, just the solid, version-independent simple stuff).
3. Build Fat server/thin client applications that are transportable. Build code that has a transportable GUI across platforms that use a well-designed TCP -based protocol.
4. Spend a little time with IT executives to understand better what problems they are paid to solve, then help them solve them.
It is important that you decide whether you are producing a product that your customer buys, or are providing a service that your customer uses, i.e. are you selling them a widget or contracting to build them a house?
In the former case, you retain the rights to the "trade secrets" and proprietary aspects of your product. In the latter case (assuming you are billing them time and materials), you are building something for them and the results of your work is their product.
You can put any language you want in a contract. Just be aware that they have access to lawyers, too, and you can both lose time, opportunity, and money by being unrealistic.
If they have no expertise and capabilities in software and are likely never going to be a competitor of yours, you are probably being overly defensive. On the other hand, if they are paying you for your TIME, then they can argue that you are building THEIR code.
Slashdot Mirror
The statement says nothing about the document format requiring DRM. Anyone is free to create software that produces PDF documents with no DRM. In fact, it protects the specification itself against someone bypassing access permissions and attributing the failure to PDF. The standard cannot authorize you to violate another's legitimately sought copyright.
PDF Reference
third edition
Adobe Portable Document Format
Version 1.4
"Adobe gives anyone copyright permission, subject to the conditions stated below, to:
The conditions of such copyright permission are:
This limited right to use the copyrighted list of data structures and operators does not include the right to copy this book, other copyrighted material from Adobe, or the software in any of Adobe's products that use the Portable Document Format, in whole or in part, nor does it include the right to use any Adobe patents, except as may be permitted by an official Adobe Patent Clarification Notice (see the Bibliography)."
Note: I see the irony of not being permitted "to copy this book...in part". However, as I am writing about the book, US Copyright law permits small quotes to be used and attributed.
Four reasons:
High resolution => more info/sq. inch
High contrast => more legibility in ambient light without backlighting = longer battery life
Static image (power only needed to change image) => longer battery life
Light weight (no heavy glass screen or big batteries needed to create image)
Having seen high quality e-paper on a working device, I can say that it looks like the image has been printed on a laser printer. The long battery life means that it's useful when the information changes on the order of minutes, not seconds, and you can carry it around easily because of the light weight.
No, this is not a replacement for an active screen and GIF's and movies are not realistic uses for it.
Good to see!
However, in a lot of places on this planet, cow dung is more available than sunlight!
By the way, DEKA's prices on these machines are in the $2K-3K range, as I recall. That's a price range that allows charitable organizations (think Non-Governmental Organizations) to fund and deploy them.
These designs fit more with the concepts described in Small is Beautiful by E.F. Schumacher.
Dean Kamen's research organization DEKA is using this technology to produce electrical generators already in demonstration projects in Bangladesh where the fuel is the heat generated by animal manure. Instructions read "Just add S#!t" (No kidding!)
Here's his core technology (http://www.dekaresearch.com/coreTech.html).
He's developing technology that can produce energy with 1) available fuel, 2) no supply consumption, and 3) no harmful materials. He also has developed a water purification system that literally can take sewage and produce potable water. He gives a very persuasive presentation on the benefits of the simple and limited capabilities in the vast areas of this planet where neither energy nor clean water is readily available.
Your company should also have a financial plan to guide the management of assets, cash flow, and the like.
Finally, if you intend to grow, you're going to reach a point where you will need to separate the functions of technical operation and administration. If a customer is having problems, you can't be trying to get out the payroll, and if you've got to calculate and pay the quarterly tax payment, you can't drop that to solve a customer problem.
These are all business problems which successful businesses have gone through, and unsuccessful businesses have neglected. There's probably a business networking or entrepreneur's group in your area that you could link up with that can share insights and lessons learned. Alternatively, there are plenty of savvy business people in non-competing businesses that you could meet by joining the local business and services groups to developed connections, learn who has expertise, and build relationships that might lead to future business arrangements.
Growing a business is a lot like chess: not all moves are equally valuable and not all pieces are equally powerful; it's knowing the right move to make and when to make it that controls the flow of the game.
1. I'm not a religious nutball. I never stated a theologic point, but was discussing the notion of Truth.
2. My point was you are using biasing language as a rational argument, and labeling and then attacking me.
3. You are name-slinging, generalizing, tangential, hyperbolic, and arrogant in your language.
4. Item 3 is not denunciation, just an analysis of your argument. It overwhelms whatever substance you might have intended.
5. I don't know you, and don't presume to know you. But I really get a sense of a lot of hostility from your communication.
Please feel free not to waste your time.
I don't have you confused with anyone. That's a conversion to an ad hominem attack.
Theist... That's a projection, and a wrong one at that. I'm not a theist. Reread my post, and tell me where I said *I* have a monopoly on anything.
You're last paragraph sounds like you're the one pulling the ripcord. Or did I misinterpret the evidence? This conversation seems to upset you alot.
Good logical debate approach there....
It seems that you are presuming what I believe. And, you are presuming my response.
Not all scientists are willing to admit their theories are wrong. Sometimes they ignore some of the data as outliers. And there is bias in experimental design, so a scientist pursuing a research topic is not an unbiased individual.
Finally, the use of hyperbole in an argument does not add weight to it.
But, thanks for reading!
While there may be signs of God's work, and evidence of evolution, neither can be proven by direct observation, but can only be inferred indirectly and conluded by the application of faith.
I, for one, can have faith in God without feeling the need to put him on a human time scale. In that case, I can say that God created evolution as the means of creation. If God can build a universe, he's certainly not working on my scale in physics. Why should he be bound by my perception of time?
And, in a leap of faith, it seems a bit of hubris to believe that man is the top of the food chain, especially in the setting of today's tribalism.
On a final note, the iPod does not IMPOSE DRM, it only MAINTAINS them. If it bothers you, do as I do: buy the CD and rip it into iTunes, which iTunes supports beautifully. Then you are free do keep it in iTunes or move it to any other device, iPod or not, you choose.
On you're first point, it IS possible to patent a connector if it provides new functionality, but the wiring is not patentable. The likely result of this is that other manufacturers of devices will adopt the signal lines used by the iPod.
many people who also think that their ideas are unique, creative, and valuable, just like you do. So what are the challenges and how do you deal with them?
The Golden Rule can provide a lot of guidance to you. Here are some points to consider:
1. Your ideas are valuable. You deserve and should expect (a) respectful hearing of your thoughts, (b) reasoned responses to your ideas, and (c) civil respect whether you make your case or not.
2. How other people behave are the most important determinants of how they are treated. If they are cynical, they will be isolated. If they are judgmental, they will be excluded. If they make personal attacks, they will be avoided. But if they are helpful, they will be sought out. If they are open to other's suggestions, they will get support. And if they are kind, they will be treated with respect.
3.For each of the above observations, switch the "you" and "they" and think if you are applying that rule.
4. Every idea has its time. Maybe it's not now. If you have a great idea, maybe you are thinking too far ahead or from a different perspective. The best way to have your idea accepted is (a) think your idea through from the perspective of the person or people who will be hearing it, (b) prepare them (perhaps over the course of time) to understand the framework, background, and relevance of what you ultimately want them to adopt, (c) listen to them and seek to understand how they view the world and the way your idea will fit into it, (d) prepare your presentation taking into account a-c, (d) listen to criticisms and suggestions (e) be willing to adapt, and (f) don't take it personally. Many of the best ideas take weeks, months, or years for people's thinking to get to where they can be accepted.
5. If you have trouble working for a supervisor, you may also have trouble working with a customer. Both will make demands, at time seem unreasonable, and not always agree with you. And both pay you to listen to them. Be selective with both, and respectful of both.
6. Remember that life is about the people, and not always about being right or wrong. Learning to work with people is a life skill.
7. Make your work a pleasure. People like to work with happy people a whole lot more than working with unhappy people. Do the hard parts with intensity, but take time to enjoy some of what you do, and the people you do it with, every day. While each day will have its negatives, work to create positive moments or interactions whenever and wherever you can.
Having been at both the bottom and top of the ladder you're on, I can say that I have more good memories of the people I've worked with than of the work I've done. And that's because the work and its value changes over time. What was critical is no longer even useful. But I've tried to learn something from and to share something with every person that I've worked for or with or supervised.
I guess that's an "unintended consequence" of Bill Gates donating the Gates Computer Science Building (http://www.microsoft.com/presspass/press/1996/jan 96/stanford.mspx)...
HIPAA (Health Insurance Portability and Accountability Act) was created (1) to guarantee that a person, when leaving one insurance provider, could, by maintaining continuous insurance coverage , not be excluded from coverage for "pre-existing illness." It was not uncommon for people to change employers, have to change insurance providers, and then lose coverage and benefits.
/. reiterate those points) because the regs are baroque, abstruse, and generally hard to understand - as most legalese is to people who have their jobs to do. An admitting clerk, a nurse, or a med tech receives training in HIPAA, but it's guidance, not a recitation of the pages and pages of language that even experts disagree on. And, staff are taught to be more conservative as a risk management approach to privacy.
As an "opportunity," the pending regulation was expanded to delve into all kinds of IT issues like privacy and security. The challenge of those potential regulations was that there was no current body of practice in the industry. Finance departments set expectations for financial systems, medical records departments handled release of information, and nursing services made patient status available. Having the IT focus caused much consternation among these other departments, which saw the effort as intrusion into their domains. Many departments simply didn't have the staffing or the time to devote to reading and interpreting the huge number of pages of material.
The most significant failure of HIPAA was to create the sense of "standards of privacy and security" as community standards, or measurements against the norm. There were, in fact, few well-defined and well-articulated standards of expectations in the regulations. Obviously, consultants and auditors and lawyers interpreted everything in the most rigorous, least risky manner, and not the community standards. This fact continues to be the most challenging of the regulations to deal with, because it is a moving target among competing healthcare organizations rather than a defined standard to which all are measured.
Ultimately, HIPAA has had little of the effect on personal information privacy in terms of secure electronic information exchange while giving a name(HIPAA - perhaps the most frequently misspelled acronym in the US) and a PERCEPTION that the law actually defined standard expectations.
Most of the complaints are due to irritation and confusion (and some posts on
There are many more important problems in healthcare than this one. More people are killed by the INABILITY to share critical information than are adversely affected by the ABILITY to err in doing so. Think of the loss of medical information for Katrina victims, and the fact that up to 100,000 adverse medical events leading to death occur EACH YEAR, and put those 17,000 complaints in perspective.
Yes, I know that the relational model is a model. I referred to it as such.
and I have a PhD in computer science in database systems...
and I post under a user name, not anonymously.
As I recall, that's the same sentiment expressed about relational databases when the current state of the art was hierarchical and CODASYL databases in the 70's. All it takes is one really good implementation of the new idea to change this perception.
There were huge debates about the "abstract model" of a relational database that didn't make sense in The REAL WORLD (TRW), because "real" problems were more complex than the relational model and performance would suffer.
I don't know that an XML database is "better", but then again, I don't know that it isn't. Maybe I'll learn something!
How do YOU know this "little-known" fact. How about citing a reference rather than inciting an argument?
Second, the article shows some flaws as well. Because 5% reported that they are always on time and budget, the researchers concluded that 95% were not. That's bad science, letting the observed lead to conclusions about the unobserved.
Finally, the larger the project, the harder it is to define an end point. Tweaking a screen to change a color is certainly doable, but may take weeks to get to in the project list. Implementing a major project that requires lots of unknown elements, such as a system conversion, cannot be considered a plan, but an estimate. And when it comes to estimates, it's very hard to get *anyone* to be less than optimistic.
For an interesting read on project planning and estimating, check out Elihu Goldratt's book, Critical Chain, which shows the application of his Theory of Constraints to project management.
Good observation. The same holds true for many open specifications--there are proprietary extensions allowed in the specification, which are not compatible with other (generally older) versions.
It would seem wise for the people deploying such applications (whoever created the form) to be informed and educated about this issue.
Good technology deployment generally entails using current tools, but making the work product accessible to one's potential consumers is also very important. It seems this fact is lost on some technical people when they go to build something. The whole point of the use of technology is to BETTER reach the target audience.
External auditors and corporate attorneys are evaluated not on their business acumen, but the degree to which they can reduce or eliminate risk. It is the business's board and management that then decides how much risk to take by not accepting some of those recommendations. "To avoid the risk of an car accident, one should not drive a vehicle on a busy street. Compare that to "Don't drive the wrong way down a busy street." The first is a legal but risk averse statement and the second is a statement of illegality and bears a legal penalty. An accident can occur under both circumstances. As I read their financial announcement, it appears that the numbers are non-zero, but do not affect significantly any major determinants of financial or business viability nor any actions meant to defraud investors. It appears that the effect of the announcement leads to the knee jerk reaction of some investors which leads to a drop in price which leads to law suits which leads to increased expenses which leads to far more financial effect than the original event as investors react to the law suits and their costs. Regarding snarfer's company's decisions, that probably reflects a more conservative, risk-averse management team. It doesn't directly follow that the company's failure was due to another company's success. Companies gain competitive advantage by taking risks. They can keep the advantage by delivering products that customers want.
Whoa there. Before you take Step 1, do a little research on who AK is and what he's done.
He is, in essence, the creator of today's graphical user interface and object oriented programming. He was exploring this stuff before microprocessors made them possible for the average person. I'd definitely put that in the "visionary" column.
I once got his PHD thesis by interlibrary loan and read it. He was decades ahead in his thinking.
I think of email as falling into the following classes:
(a) sources I know
(b) sources I don't know but not spam
(c) spam
The difference I note is that the first two people are not deceptive in their point of origin. If there were a Mail Transport Agent that could, upon connection with SMTP, use the from field and Received field to verify that the originating system has the from address on it, and could then mark the mail "Certified", that would go a long way towards giving the control to the recipient to deal with the content.
To implement this would require the efforts of the honest sources, and would let honest sources decide if and when they wanted to deploy. It would also eliminate the deceptive practice of source routing to use a weakly secured system as a reputable source.
I haven't really thought this out in depth, but I think determining the principles by which good sources can certify their emails is the way to go.
Nice generalization. As a "Corp IT exec," I can say that I would love to be on a reliable, secure, easily supportable personal computer environment... *that supports our applications*. Microsoft did a great job of marketing to developers in the early 90's (that's you guys) so now we are limited in our choices. Suggestion: show more developers how to build great end user applications that are platform independent, or multiplatform capable with minimal effort. How: 1. Pure HTML apps with ECMAscript (that javascript standard). Look at Konfabulator as an example. 2. Build java apps that run anywhere (don't use the fancy stuff, just the solid, version-independent simple stuff). 3. Build Fat server/thin client applications that are transportable. Build code that has a transportable GUI across platforms that use a well-designed TCP -based protocol. 4. Spend a little time with IT executives to understand better what problems they are paid to solve, then help them solve them.
It is important that you decide whether you are producing a product that your customer buys, or are providing a service that your customer uses, i.e. are you selling them a widget or contracting to build them a house? In the former case, you retain the rights to the "trade secrets" and proprietary aspects of your product. In the latter case (assuming you are billing them time and materials), you are building something for them and the results of your work is their product. You can put any language you want in a contract. Just be aware that they have access to lawyers, too, and you can both lose time, opportunity, and money by being unrealistic. If they have no expertise and capabilities in software and are likely never going to be a competitor of yours, you are probably being overly defensive. On the other hand, if they are paying you for your TIME, then they can argue that you are building THEIR code.