Most definitely.
Long copyrights are counter-productive. For corporations, if you have not realized a business model within 5 years, you should step aside and let someone else. Patent and copyright protection should both be limited to 5 years, except in biotech where it takes longer to develop the technology and do trials.
Once again, Congress is mis-aligned with the preferences of its popular constituents, and aligned instead with corporate interests. Someone should conduct a reliable and credible popular poll, to ask the public whether corporations should have such long-lasting copyright and patent protection.
It depends. E.g., if your software controlled a spacecraft, and there was a mission-critical failure, you would be thinking in terms of hours to find a fix - not weeks.
I agree with many posters (e.g., The_Mystic_For_Real), who point out that these games are not a substitute for real life. In fact, in real life, it is HUMAN INTERACTION that makes all the difference. Those who have good people skills are those who generally become leaders. Playing games does nothing to develop people skills. In fact, one could argue that it stunts one's development. Real life is about understanding others, patience, persistence over a period of years (perhaps decades), attention to detail, and being able to think clearly when idle.
All of the comments here are true and right on the mark.
I would add that the root cause is that Linux is too hard to get onto your computer, if you are a mainstream user.
Linux will not be widely adopted until either:
1. Retailers order it pre-installed; or
2. It can be installed with the same ease as installing an application.
Forget ISO files - most people don't even know what those are. And if there is not built-in driver support for the range of widescreen displays, bluetooth, and wireless hardware, then forget it. In that case, it will stay an early adopter niche, and will not be supported by most vendors.
The reviewer says, "Word needs master documents, since it cannot reliably handle documents longer than about 40 pages."
I have routinely used Word for 800-page documents, and found no difficulties.
I have found no difficulty with OO for these same size documents as well, except that the deficiencies with respect to cross references become unworkable when the document is large and one needs to have many cross references.
In fact, I am an experienced IT professional, and I have only a vague idea what you are talking about. The fact is, I do not spend my time studying the innards of Linux: I have other kinds of issues that I worry about. I am sure I could get a WiFi card working on Linux if I put my mind to it, and edit the right files, find the right drivers, and upgrade the BIOS as required, but I have no inclination to spend the many hours required to learn all those picky details - which I will then forget because I will not use them again. The fact is, if one has to do this, you can kiss Linux goodbye for the typical user. If Linux cannot be made to work with most (like 99%) built-in and third party devices (graphics, WiFi, sound, Bluetooth, etc.) out of the box or with *easily* found drivers - without having to edit files - then it is not a viable desktop for the typical home user. Further, it should be installable from Windows - without having to create an ISO disk and boot. These are far bigger issues than whether the scheduler is "fair" or whether the GUI is KDE or Gnome. Who cares if you can't get it running with an hour of point-and-click effort? It will then never be adopted by the masses, unless manufacturers decide to ship it pre-installed.
I recommend that you join the International Association of Software Architects. The fee is nomial and you will meet others who are in a similar position. (See www.iasahome.org)
Hi.
The rise in income is "economic". That is, it is the arithmetic difference in expected shareholder value (a) without and (b) without the investment in security. Cash income is not the only way to make or lose money: one can lose money by having additional future costs (payments), as well as by having a lower expected future income. Conversely, an investment can pay off by resulting in larger future income than would be the case without the investment. In either situation, the difference is the return on the investment.
Even if we consider an organization that does not retain assets (and hence its shareholder value is based purely on its expected future income streams and debt payments), then future losses represent future payments, or they represent reduced future income.
Thus, investment in security does indeed have an ROI.
For more information, I refer you to the seminal book on risk-based investment, "Investment Under Uncertainty", by Avinash Dixit & Robert Pindyck (1994): http://press.princeton.edu/titles/5474.html
- Cliff
Hi. I disagree. The cost of spending on security is an investment. Any investment has a ROI. The ROI of security is simply the reduction in the expected future losses that will result as a result of investment in more security. For example, if an investment of $100,000 in additional security is expected to result in a reduction of 4 security incidents per year, and each such incident has an expected average loss value of $10,000, then the expected ROI over five years is $200,000/$100,000, or 2, with a payback period of 2.5 years.
To technical users, Linux is already easy to install.
But to the average person, who spends most of their time in things other than the ins and outs of computers, Linux installation is intimidating. The very thought that one might have to edit a file in a text editor is a non-starter. For mass adoption, Linux needs to install at the click of a mouse (from a running XP or Vista window), with minimal risk of problems along the way. This needs to be the case for the broad range of systems, from laptops through desktops, and for nearly all types of displays, sound cards, network cards, and so on.
If this cannot be achieved, Linux will not achieve mainstream status as a desktop system. Period.
That is the challenge, and rather than tinkerking with niceties, this is where effort should focus, IMHO.
This is a thoughtful and intelligent response.
I would add to it though in the following way: What is the VALUE of each of these things?
That is, instead of trying to measure efficiency, or "productivity", it would be more useful to the CIO to measure the actual value of what IT does. For example, if security is increased by X amount as a result of investing Y dollars, then the ROI of that investment is easily calculated and it can be compared with other investments.
Note that to measure security, one must estimate (somehow) the expected future loss per unit of time. Thus, an increase in security means a lower level of expected loss per future time.
The same can be done for other aspects of IT operations, including those you mention above (reliability, response time, etc.). In the end it must be measured against the value to the organization. Productivity is the wrong approach. Value is the right approach.
- Cliff
It is not so that no one is choosing it on the ground. The US government is mandating a move to IP6, and further virtally all of the major backbone providers now implement it. Vista supports it in a huge way. The missing link is that local ISPs have not turned it on, but they will. In a couple of years you will see a very sudden and comprehensive shift to IP6. There are many large business models that depend on it.
This might be an interesting area of research, but I for one do not want my ISP deciding what is legitimate email. E.g., what if I WANT to email someone about vitamins??? I do not want to have the uncertainty that my email will be deleted as spam. That would destroy the usefulness of email as a major form of business and personal communication. If I configure a SPAM filter, or the filter is "advisory", that is fine. But using AI to decide and delete is not advisable IMHO. Going down the AI path seems to me like someone is going to start assuming that an AI filter can be smart enough to make guesses that I do not specifically configure. I do not want that.
The real reason for SPAM is that email systems to not verify the sender. Sender verification is essential so that senders who spam can be blacklisted.
Another problem is that people have global email addresses. What is needed is a unique address for each pair of sender and recipient. That way, if you give out your email address, it is unique to both you and the person you give it to (the person who you "invite" to contact you). This is similar to the concept of a "disposable" email address, except that there is no reason that it has to be disposable: it can be permanent. In effect, it creates a permanent way for an individual to reach you. E.g., you can create an address for person A to reach you as 'personA@mydomain.com'. If your email client then requires such unique sender/receiver addresses for all invited senders and requires sender verification for uninvited senders you have a very effective total anti-spam system.
This is very interesting and encouraging work. One possible difficulty I would like to point to is that their approach requires specialized skills that most developers do not have. Also, as pointed out by one comment here on Slashdot, one often has to access third party libraries that are not fully reliable. Finally, in a business environment, one will have difficulty selling a highly academic methodology that requires a radically different skill set (e.g., formal analysis, predicate calculus, etc.) than what is available.
Their work may be very effective in high-assurance settings that can be very careful about assembling the right team and defining the right process. I can see it being used in military and avionics applications, as they say.
For business application environments, it is probably more practical to take a "best practices" approach, and tackle the problem from a methodological perspective, by adding assurance steps to existing maintstream methodologies, rather than by requiring an enrirely different approach for writing requirements.
I have just written a book about this by the way. See "High-Assurance Design" on Amazon, or look for the article by myself and Scott Ambler which should be out soon.
- Cliff
Slashdot Mirror
After skimming past a few paragraphs and seeing the level of his discourse, I had no confidence in his credibility and stopped reading.
Most definitely. Long copyrights are counter-productive. For corporations, if you have not realized a business model within 5 years, you should step aside and let someone else. Patent and copyright protection should both be limited to 5 years, except in biotech where it takes longer to develop the technology and do trials. Once again, Congress is mis-aligned with the preferences of its popular constituents, and aligned instead with corporate interests. Someone should conduct a reliable and credible popular poll, to ask the public whether corporations should have such long-lasting copyright and patent protection.
It depends. E.g., if your software controlled a spacecraft, and there was a mission-critical failure, you would be thinking in terms of hours to find a fix - not weeks.
I agree with many posters (e.g., The_Mystic_For_Real), who point out that these games are not a substitute for real life. In fact, in real life, it is HUMAN INTERACTION that makes all the difference. Those who have good people skills are those who generally become leaders. Playing games does nothing to develop people skills. In fact, one could argue that it stunts one's development. Real life is about understanding others, patience, persistence over a period of years (perhaps decades), attention to detail, and being able to think clearly when idle.
All of the comments here are true and right on the mark. I would add that the root cause is that Linux is too hard to get onto your computer, if you are a mainstream user. Linux will not be widely adopted until either: 1. Retailers order it pre-installed; or 2. It can be installed with the same ease as installing an application. Forget ISO files - most people don't even know what those are. And if there is not built-in driver support for the range of widescreen displays, bluetooth, and wireless hardware, then forget it. In that case, it will stay an early adopter niche, and will not be supported by most vendors.
The reviewer says, "Word needs master documents, since it cannot reliably handle documents longer than about 40 pages." I have routinely used Word for 800-page documents, and found no difficulties. I have found no difficulty with OO for these same size documents as well, except that the deficiencies with respect to cross references become unworkable when the document is large and one needs to have many cross references.
In fact, I am an experienced IT professional, and I have only a vague idea what you are talking about. The fact is, I do not spend my time studying the innards of Linux: I have other kinds of issues that I worry about. I am sure I could get a WiFi card working on Linux if I put my mind to it, and edit the right files, find the right drivers, and upgrade the BIOS as required, but I have no inclination to spend the many hours required to learn all those picky details - which I will then forget because I will not use them again. The fact is, if one has to do this, you can kiss Linux goodbye for the typical user. If Linux cannot be made to work with most (like 99%) built-in and third party devices (graphics, WiFi, sound, Bluetooth, etc.) out of the box or with *easily* found drivers - without having to edit files - then it is not a viable desktop for the typical home user. Further, it should be installable from Windows - without having to create an ISO disk and boot. These are far bigger issues than whether the scheduler is "fair" or whether the GUI is KDE or Gnome. Who cares if you can't get it running with an hour of point-and-click effort? It will then never be adopted by the masses, unless manufacturers decide to ship it pre-installed.
I recommend that you join the International Association of Software Architects. The fee is nomial and you will meet others who are in a similar position. (See www.iasahome.org)
Hi. The rise in income is "economic". That is, it is the arithmetic difference in expected shareholder value (a) without and (b) without the investment in security. Cash income is not the only way to make or lose money: one can lose money by having additional future costs (payments), as well as by having a lower expected future income. Conversely, an investment can pay off by resulting in larger future income than would be the case without the investment. In either situation, the difference is the return on the investment. Even if we consider an organization that does not retain assets (and hence its shareholder value is based purely on its expected future income streams and debt payments), then future losses represent future payments, or they represent reduced future income. Thus, investment in security does indeed have an ROI. For more information, I refer you to the seminal book on risk-based investment, "Investment Under Uncertainty", by Avinash Dixit & Robert Pindyck (1994): http://press.princeton.edu/titles/5474.html - Cliff
Hi. I disagree. The cost of spending on security is an investment. Any investment has a ROI. The ROI of security is simply the reduction in the expected future losses that will result as a result of investment in more security. For example, if an investment of $100,000 in additional security is expected to result in a reduction of 4 security incidents per year, and each such incident has an expected average loss value of $10,000, then the expected ROI over five years is $200,000/$100,000, or 2, with a payback period of 2.5 years.
To technical users, Linux is already easy to install. But to the average person, who spends most of their time in things other than the ins and outs of computers, Linux installation is intimidating. The very thought that one might have to edit a file in a text editor is a non-starter. For mass adoption, Linux needs to install at the click of a mouse (from a running XP or Vista window), with minimal risk of problems along the way. This needs to be the case for the broad range of systems, from laptops through desktops, and for nearly all types of displays, sound cards, network cards, and so on. If this cannot be achieved, Linux will not achieve mainstream status as a desktop system. Period. That is the challenge, and rather than tinkerking with niceties, this is where effort should focus, IMHO.
This is a thoughtful and intelligent response. I would add to it though in the following way: What is the VALUE of each of these things? That is, instead of trying to measure efficiency, or "productivity", it would be more useful to the CIO to measure the actual value of what IT does. For example, if security is increased by X amount as a result of investing Y dollars, then the ROI of that investment is easily calculated and it can be compared with other investments. Note that to measure security, one must estimate (somehow) the expected future loss per unit of time. Thus, an increase in security means a lower level of expected loss per future time. The same can be done for other aspects of IT operations, including those you mention above (reliability, response time, etc.). In the end it must be measured against the value to the organization. Productivity is the wrong approach. Value is the right approach. - Cliff
It is not so that no one is choosing it on the ground. The US government is mandating a move to IP6, and further virtally all of the major backbone providers now implement it. Vista supports it in a huge way. The missing link is that local ISPs have not turned it on, but they will. In a couple of years you will see a very sudden and comprehensive shift to IP6. There are many large business models that depend on it.
This might be an interesting area of research, but I for one do not want my ISP deciding what is legitimate email. E.g., what if I WANT to email someone about vitamins??? I do not want to have the uncertainty that my email will be deleted as spam. That would destroy the usefulness of email as a major form of business and personal communication. If I configure a SPAM filter, or the filter is "advisory", that is fine. But using AI to decide and delete is not advisable IMHO. Going down the AI path seems to me like someone is going to start assuming that an AI filter can be smart enough to make guesses that I do not specifically configure. I do not want that. The real reason for SPAM is that email systems to not verify the sender. Sender verification is essential so that senders who spam can be blacklisted. Another problem is that people have global email addresses. What is needed is a unique address for each pair of sender and recipient. That way, if you give out your email address, it is unique to both you and the person you give it to (the person who you "invite" to contact you). This is similar to the concept of a "disposable" email address, except that there is no reason that it has to be disposable: it can be permanent. In effect, it creates a permanent way for an individual to reach you. E.g., you can create an address for person A to reach you as 'personA@mydomain.com'. If your email client then requires such unique sender/receiver addresses for all invited senders and requires sender verification for uninvited senders you have a very effective total anti-spam system.
That is an excellent point. A stable program has to be resilient to fialure.
This is very interesting and encouraging work. One possible difficulty I would like to point to is that their approach requires specialized skills that most developers do not have. Also, as pointed out by one comment here on Slashdot, one often has to access third party libraries that are not fully reliable. Finally, in a business environment, one will have difficulty selling a highly academic methodology that requires a radically different skill set (e.g., formal analysis, predicate calculus, etc.) than what is available. Their work may be very effective in high-assurance settings that can be very careful about assembling the right team and defining the right process. I can see it being used in military and avionics applications, as they say. For business application environments, it is probably more practical to take a "best practices" approach, and tackle the problem from a methodological perspective, by adding assurance steps to existing maintstream methodologies, rather than by requiring an enrirely different approach for writing requirements. I have just written a book about this by the way. See "High-Assurance Design" on Amazon, or look for the article by myself and Scott Ambler which should be out soon. - Cliff
Actually, YOUR post is the least informative. If you don't have anything positive, keep silent. I for one found his post useful.