The part I find ironic about this article (most of which I agree with) is that some of the world first viruses were written for, and designed to run on, UNIX.
At least the early work by Dr. Fred Cohen was certainly done on a variety of boxes, and UNIX figured prominently.
The shell viruses were particularly interesting to me.
His book A Short Course in Computer Viruses, ASP Press (1991) is a fantastic read, even for it's age.
I think most good change management system should be tweakable to do decent job of request management. I think someone already mentioned Bugzilla.
The company I work for makes a commercial CM solution that we use internally for IT request management (as well as bug and code feature management), though it was never explicity designed to do so. Some of our customers also use it in this manner.
The feeling I get is that not a lot of companies actually do any company-wide IT request management, so we tried to make the tool as generic as possible,
May as well chip in with my 2 fractional money units.
Just applied this update to my Quicksilver 933, and all went reasonably well, though on reboot the keyboard and mouse was unresponsive. Mouse pointer just sat in the upper-left corner, unmoving.
I had to pull the Apple Display cable out of the back of the unit to reset the USB hub in the display to get the keyboard and mouse attached to work. No biggie, I guess.
Perhaps it was the DLink USB Bluetooth adapter in the keyboard hub?
If I'd heard about this a few weeks back, I'd be so ready with the ol' Nelson "HA-HA!".
Unfortunately, I found a real old bug in our app on some UNIX boxes. It turns out that our implemention of getpass() was eating the letter "c" on some platforms.
I wonder what the result would be if the 'standards' of the various genres were used as weighted samples.
I wondered about this, as well. It would be interesting to hear what the result set(s) would be if they analyzed streams of data from other sources. Like shortwave broadcasts from the middle-east or Africa. I mean, the stream currently produced is still somewhat recognizable as 4/4. The voices have an English flavour. There is an overall major-scale feel. What happens if you introduce odd (to western music) time signatures and scales? I wonder what a selection of modal free-jazz would end up sounding like? More free-form modal jazz?
I think it would interesting to mix it up a little. I'm sure I'm not the only one who's had this idea. I expect we'll be hearing more from this Eigen-experiment over time.
That's all well and good, but what if more than half of those stations happen to be playing music that sucks?
Thought there aren't a lot of details on the web site, I'm guessing that this is kind of the point. The first paragraph sounds like a subtle dig at musical conformity (however one wishes to define that) in a way that suggests that if you want to produce "optimal" product, you can go about it in a purely statistical manner.
Or something.
In some ways, this is similar to the "cut-up" technique used by Burroughs, et al, in the late '50s to come up with novel work using found sounds and words. It also reminds me a bit of Negativeland.
I'm pretty sure these guys are having fun. Serious fun, but fun nonetheless. I mean, check out the titles of the tracks they've created!
I work for a medium sized software company. We certify against Red Hat for our US customers and SuSE for our German customers. We certify against specific releases. For our customers, Linux is either Red Hat or SuSE, and they (and us) refer to those distros' version numbers, not the kernel.
We simply couldn't gurantee things like version changes to glibc might break the small amount of native libraries we ship. PAM is a mess across various distros (so far, each distro needs to be documented separately for PAM setup of our app) and we've even found problems with consistent Java support.
Getting the software to work, and coding smart s only one part of the problem. The fact is that corporate customers expect their product to be QA'd, and QA takes time and money. They also expect technical support, and the time and cost to solve "what distro are you using" problems people may call in with is just not worth it. Maintaining a matrix of distro-patches-kernel-tweaks-hardware issues for any and all distro would be nigh on impossible to do properly. We've have to offer half-assed support and QA if we supported more than a handful of specific distros.
Then there are the services. We have to keep things like LDAP and NIS in a known state, and each distro has it's own disitinct flavour. And the third-parties. We depend on some third-party apps, and these must be certified, at the right level, for each distro, for these exact same reasons. Most enterprise solutions do not exist in a vacuum; most depend on a whole slew of third-party app and integrations into services and devices. Open standards can only go so far in the real world (we've found).
Sorry; I love Linux, but corporate customer have far different needs than I do in my cubicle at work, or on my play box at home. There are just too many unknowns to risk fubarring our customers world. These unknowns exist whether or not an app is well-designed and properly robust.
This is not to say we won't support Debian or Gento or whatever. It just means that until you come along and ask us to support one of those distros or platforms, we will not certifiy it with our app suite. We've done it for FreeBSD for one single customer. We need a business case to proceed with a new platform, and we've found that each distro can behave as if it was just another UNIX platform for us: it needs to be smoke-tested and QA'd, or it will break at the exact wrong moment for our customers.
I wonder what the legal rights of the authors of GPL'd software would be if the GPL was rendered invalid?
Any laywers present? Would all that tasty code revert to the public domain? Would ownership fall to the principle authors (good luck determining that gor something like gcc or difflib)?
Though I appreciate your sentiment, I think the main argument is that SCO isn't just using GPL'd software.
They are modifying, re-releasing and selling GPL'd software. All of which is perfectly fine (under the GPL) but which is contradictory to statements made by their CEO.
That is, they support and exploit the GPL as long as it benefits them for their business model. In the case of Samba, to be free of the GPL they'd have to engineer their own SMB solution, and in such a way that it was not "tainted" by the GPL (i.e., they cannot just steal from the Samba team).
Since this is not likey to happen, SCO has made the choice to charge money for a product that includes a great long list of GPL'd software (which supposedly adds a a lot of value to their OpenServer product) and yet their fearless leader claims that the GPL "destroys value".
I'm thinking this is the part that rankles most with the Samba team.
AV software should be mandatory and it should immediately and automatically clean and/or quarantine all suspicious files without allowing anything less than and administrator to override it.
I generally agree, except that some users must be able to disable real-time scanning. Anyone who works with computers in any technical capacity (R&D, QA, Technical Support, etc.) must sometimes be allowed to disable these types of services for all kinds of reasons.
The fact is that none of the currently available network virus scanners are 100% guaranteed not to interfere with other apps, or cause problems with installs.
Our IT group locks down the global virus scanning stuff for a subset of our employees. Other folks (who are assumed to be more clueful) can disable the service when trying to isolate a problem, or to install a new app to use/test/integrate with/investigate. If someone who is supposed to know better allows something bad to slip through, then so be it. Before we had system-wide guards setup, I once managed to loose an old Microsoft "scrapfile" worm I found on a network drive upon our world (it had logic to copy itself to any SMB drive it could find, apparently, and it was missed during a cleanup). The sudden increase of disk and network activity prompted me to pull the network cable. This is probably the biggest difference between users like me, and "users" as sometimes referred to by IT.
One must balance security with convenience; total security means near-zero convenience. In that case, we should all go back to typewritten memos, snailmail and spiral-bound notebooks.
Having a monolithic app has it's drawbacks, but Apple has to offer a one-stop app for what is probably their median user group. Digital photography use among most computer users is exploding, and it would be wrong for Apple not to provide a slick single interface aimed directly at these users.
The UNIX guy in me agrees with the notion that large apps can be a pain, in principle. Many small apps that do one or two things extremely well can often be more satisfying to use than a single monolithic app that is a pain to navigate, offers features you don't need and hides the ones you do.
Well, I would have agreed that iPhoto is perhaps overkill until I got a digital camera and hooked it up to my G4. Having an app that catalogs and organizes my photos, like iTunes (or any other digital music app) was so useful, I never looked back. The fact that it has facilities for smart backup to DVD, and other features I haven't even explored is just gravy. The UI fills me with a warm fuzzy, as well.
I'd have to say that iPhoto is one of those rare apps that manages to give most of us just about what we need, but no more. Between iPhoto and Photoshop Elements, this amateur photog (and recent convert from film cameras for holiday snaps and the like) has all he needs.
What? "Eat it" as in like "shred" or "destroy"? What kind of crap is that? What possible reason would there ever be for even making a ballot tabulation machine capable of destroying ballots? Where do you get your "understanding"? Got any links?
These are only a few references I've run across, but I'm most familiar with Palast's reporting of what happened in Florida (and perhaps other states). You can also try a Google search on "voting machines problems".
The implication is clear: some districts can adjust the voting machines so that more improperly marked votes can be considered spoiled, and are not counted. As in "destroyed". Other districts can set things up to give the voter another chance so that the vote is counted. The real crime appears to be that these districts can be sharply statistically defined in terms of race or party affiliation.
But this is just the kind of "spoiling" that can be accomplished long after the ballot is actually cast.
Furthermore, it is my understanding that the voting machines used can be set to either reject a vote if it is spoiled (and let the voter try again), or to silently eat it. One of the main criticisms of the the Florida debacle was that there is evidence that the machines in certain areas were tuned to silently eat marginal votes. In effect, some counties threw away votes, where others allowed the voter another chance.
Just as a digital system is no guarantee of voter security, it is obvious that the current system is also open to abuse. As you state, even the current voting system is vulnerable even if we are sure the votes are actually "good".
The difference is current systems have problems that are (probably) well-known. This new digital system looks like a recipe for disaster unless security and fail-over is built in from the start.
One of my biggest objections to high-end audiophilia is that the subjects more often than not refuse to try double-blind tests concerning the difference between two products.
Absolutely. One of my favourite past reviews is from an audiophile mag (I forget which one) which compared speaker wire. This was the beginning of the super-deluxe-hyperbole-infused speaker interconnect industry, so the magazine used double-blind tests to see if the $500/ft (and up) products were worth it.
The results: Radio Shack 14AWG lamp cord was deemed the overall best.
Listening is a highly subjective activity, and listening to music even more subjective. I'm all for an increase in proper analysis techniques and a decrease in hyperbole when discussing things like digital music formats.
one of my friends is an A$$isntant Manager of a apple store. He bought one of the great G something or other with the 17" flat monitor. Well he was showing off his Mac and 10 times in 1/2 hour he had to keep cold shutdowns and restarts cuz it kept on crashing... Yeah PCs crash too, but at least with Micro$oft W2K there is no vulnability of someone coming up to it and getting in thru the screen saver.
No offense meant, but do you mean "strait" as in "Strict, rigid, or righteous" or is this an unintentional misspelling of "straight"? I'm assuming you did not mean any of the other definitions of the word.
I'm asking because the the former is an archaic use of the word "strait", which could be totally appropriate in this case.
I agree that the role of the super-unbeatable Terminator character requires mostly poker-faced acting. These are single-minded brutes, after all.
No matter how good the tools, you can never escape from the command-line for complex systems.
Agreed.
I work for a company that makes "enterprise" client-server apps, and out customers demand we have a complete command-line interface, along with a standard GUI and an API interface. All interfaces are actually running the same client commands, so we have some kind of interface parity. (No, our GUI is not a wrapper around the CLI! The "client" is abstract, and can only be accessed via your choice of interface.)
Customers always seem to want a scriptable and fast interface, even if it is ugly and outmoded. Everyone knows command-lines (by and large) suck. Everyone also knows we need 'em, at least for some apps and some users.
For now, anyway. Maybe when all the old-timers die (hmm, I wonder if this means me, as well), the CLI will die.
My apologies. I had assumed you were the OP. I generally browse threads with all AC comments disabled, but must have turned that back on during moderation.
As for the statement you take umbrage with, I still stand by the exact quote. Perhaps my opinion is slanted because I mostly maintain code for a living.
I never run out of bugs to fix or features to implement between major releases, and have seen a few products age beyond their useful life until a complete rewrite is warranted. Between maturing customer needs and ever-changing hardware, I just don't see that changing much in the near future, especially in the enterprise client-server world. No matter how hot your coders are, and how well the project managers do at managing the project, there is always post-release maitenance. This is my specialty, and it has served me well.
As we've discussed, there are a lot of exceptions to this. I've been out of embedded market for some time, but was once involved in the planning stages for an aerospace project. The specs on that one changed almost daily, and we had one chance to get it right.
However, it is unlikely that PHP will ever go to space in the near future, and PHP is what got us this far into this discussion. Very odd.
Note that these are CompSci theories. In the Real World, software development rarely works out so cleanly.
Obviously, there are a variety of ways to approach software development, and for cases like embedding software in bodies, space craft and remote industrial devices, we have to take these practices with a grain of salt. I said as much in my last comment.
However, the exception does not make the rule.
This did not start with a talk about embedded systems. This started with your comments about software names in general and PHP 5 in the specific. It is unlikely we are going to send PHP into space any time soon. There are other more tried and tested technologies we use for that purpose.
I was responding to those comments, wherein you suggested that it was misleading that PHP 5 might no longer be "PHP" simply because it has gone through 3 public major releases, and the language has changed somewhat incrementally over the years. My response was simply, "that is what software does".
Honestly, I found your orignal comments confused and misguided, and many of your assumptions lacking in logic or not based on real experience. I still think you've missed my main points which I've carefully and neutrally discussed over the length of this thread.
So, I'm going to assume your last comment was a joke; even if it wasn't, you can consider this next comment of mine as humour, also.
You are entitled to your opinion, as we all are. The entitlement, however, does not make you "right" in any sense of the word. I disagree that your are correct about your original comments in any way until you are able to argue your case clearly and logically, without any ad hominem attacks or straw-man arguments.
<span class="old-timer"> My advice is to get a little education and experience under your belt before making sweeping judgements about software life-cycle management.
</span>
Some currency now has a "hologram" printed on it which appears to use the same principle.
For example, some of the newer Canadian bills have a hologram in the corner that was introduced to foil counterfeiters. My understanding is that these were created by crushing up the stuff used to make laser-cut holographic images and applying it to the paper as a printing process.
This process sounds similar to the one described in the article.
Slashdot Mirror
The part I find ironic about this article (most of which I agree with) is that some of the world first viruses were written for, and designed to run on, UNIX.
At least the early work by Dr. Fred Cohen was certainly done on a variety of boxes, and UNIX figured prominently.
The shell viruses were particularly interesting to me.
His book A Short Course in Computer Viruses, ASP Press (1991) is a fantastic read, even for it's age.
I think most good change management system should be tweakable to do decent job of request management. I think someone already mentioned Bugzilla.
The company I work for makes a commercial CM solution that we use internally for IT request management (as well as bug and code feature management), though it was never explicity designed to do so. Some of our customers also use it in this manner.
The feeling I get is that not a lot of companies actually do any company-wide IT request management, so we tried to make the tool as generic as possible,
May as well chip in with my 2 fractional money units.
Just applied this update to my Quicksilver 933, and all went reasonably well, though on reboot the keyboard and mouse was unresponsive. Mouse pointer just sat in the upper-left corner, unmoving.
I had to pull the Apple Display cable out of the back of the unit to reset the USB hub in the display to get the keyboard and mouse attached to work. No biggie, I guess.
Perhaps it was the DLink USB Bluetooth adapter in the keyboard hub?
If I'd heard about this a few weeks back, I'd be so ready with the ol' Nelson "HA-HA!".
Unfortunately, I found a real old bug in our app on some UNIX boxes. It turns out that our implemention of getpass() was eating the letter "c" on some platforms.
So, the appropriate Simpson's reference is now:
I wondered about this, as well. It would be interesting to hear what the result set(s) would be if they analyzed streams of data from other sources. Like shortwave broadcasts from the middle-east or Africa. I mean, the stream currently produced is still somewhat recognizable as 4/4. The voices have an English flavour. There is an overall major-scale feel. What happens if you introduce odd (to western music) time signatures and scales? I wonder what a selection of modal free-jazz would end up sounding like? More free-form modal jazz?
I think it would interesting to mix it up a little. I'm sure I'm not the only one who's had this idea. I expect we'll be hearing more from this Eigen-experiment over time.
Thought there aren't a lot of details on the web site, I'm guessing that this is kind of the point. The first paragraph sounds like a subtle dig at musical conformity (however one wishes to define that) in a way that suggests that if you want to produce "optimal" product, you can go about it in a purely statistical manner.
Or something.
In some ways, this is similar to the "cut-up" technique used by Burroughs, et al, in the late '50s to come up with novel work using found sounds and words. It also reminds me a bit of Negativeland.
I'm pretty sure these guys are having fun. Serious fun, but fun nonetheless. I mean, check out the titles of the tracks they've created!
I work for a medium sized software company. We certify against Red Hat for our US customers and SuSE for our German customers. We certify against specific releases. For our customers, Linux is either Red Hat or SuSE, and they (and us) refer to those distros' version numbers, not the kernel.
We simply couldn't gurantee things like version changes to glibc might break the small amount of native libraries we ship. PAM is a mess across various distros (so far, each distro needs to be documented separately for PAM setup of our app) and we've even found problems with consistent Java support.
Getting the software to work, and coding smart s only one part of the problem. The fact is that corporate customers expect their product to be QA'd, and QA takes time and money. They also expect technical support, and the time and cost to solve "what distro are you using" problems people may call in with is just not worth it. Maintaining a matrix of distro-patches-kernel-tweaks-hardware issues for any and all distro would be nigh on impossible to do properly. We've have to offer half-assed support and QA if we supported more than a handful of specific distros.
Then there are the services. We have to keep things like LDAP and NIS in a known state, and each distro has it's own disitinct flavour. And the third-parties. We depend on some third-party apps, and these must be certified, at the right level, for each distro, for these exact same reasons. Most enterprise solutions do not exist in a vacuum; most depend on a whole slew of third-party app and integrations into services and devices. Open standards can only go so far in the real world (we've found).
Sorry; I love Linux, but corporate customer have far different needs than I do in my cubicle at work, or on my play box at home. There are just too many unknowns to risk fubarring our customers world. These unknowns exist whether or not an app is well-designed and properly robust.
This is not to say we won't support Debian or Gento or whatever. It just means that until you come along and ask us to support one of those distros or platforms, we will not certifiy it with our app suite. We've done it for FreeBSD for one single customer. We need a business case to proceed with a new platform, and we've found that each distro can behave as if it was just another UNIX platform for us: it needs to be smoke-tested and QA'd, or it will break at the exact wrong moment for our customers.
If you set that to music, I will buy you a beer.
I wonder what the legal rights of the authors of GPL'd software would be if the GPL was rendered invalid?
Any laywers present? Would all that tasty code revert to the public domain? Would ownership fall to the principle authors (good luck determining that gor something like gcc or difflib)?
I'll pretend that I did that on purpose. Stupid Dell keyboard.
I'm thinking "smpler" is prounounced like "stapler" in "Office Space".
Though I appreciate your sentiment, I think the main argument is that SCO isn't just using GPL'd software.
They are modifying, re-releasing and selling GPL'd software. All of which is perfectly fine (under the GPL) but which is contradictory to statements made by their CEO.
That is, they support and exploit the GPL as long as it benefits them for their business model. In the case of Samba, to be free of the GPL they'd have to engineer their own SMB solution, and in such a way that it was not "tainted" by the GPL (i.e., they cannot just steal from the Samba team).
Since this is not likey to happen, SCO has made the choice to charge money for a product that includes a great long list of GPL'd software (which supposedly adds a a lot of value to their OpenServer product) and yet their fearless leader claims that the GPL "destroys value".
I'm thinking this is the part that rankles most with the Samba team.
Ow! My head! Shut up, brain, or I'll stab you with a Q-Tip again.
I know it was a smple typo, but I love the word "infringle" you've invented.
I generally agree, except that some users must be able to disable real-time scanning. Anyone who works with computers in any technical capacity (R&D, QA, Technical Support, etc.) must sometimes be allowed to disable these types of services for all kinds of reasons.
The fact is that none of the currently available network virus scanners are 100% guaranteed not to interfere with other apps, or cause problems with installs.
Our IT group locks down the global virus scanning stuff for a subset of our employees. Other folks (who are assumed to be more clueful) can disable the service when trying to isolate a problem, or to install a new app to use/test/integrate with/investigate. If someone who is supposed to know better allows something bad to slip through, then so be it. Before we had system-wide guards setup, I once managed to loose an old Microsoft "scrapfile" worm I found on a network drive upon our world (it had logic to copy itself to any SMB drive it could find, apparently, and it was missed during a cleanup). The sudden increase of disk and network activity prompted me to pull the network cable. This is probably the biggest difference between users like me, and "users" as sometimes referred to by IT.
One must balance security with convenience; total security means near-zero convenience. In that case, we should all go back to typewritten memos, snailmail and spiral-bound notebooks.
Having a monolithic app has it's drawbacks, but Apple has to offer a one-stop app for what is probably their median user group. Digital photography use among most computer users is exploding, and it would be wrong for Apple not to provide a slick single interface aimed directly at these users.
The UNIX guy in me agrees with the notion that large apps can be a pain, in principle. Many small apps that do one or two things extremely well can often be more satisfying to use than a single monolithic app that is a pain to navigate, offers features you don't need and hides the ones you do.
Well, I would have agreed that iPhoto is perhaps overkill until I got a digital camera and hooked it up to my G4. Having an app that catalogs and organizes my photos, like iTunes (or any other digital music app) was so useful, I never looked back. The fact that it has facilities for smart backup to DVD, and other features I haven't even explored is just gravy. The UI fills me with a warm fuzzy, as well.
I'd have to say that iPhoto is one of those rare apps that manages to give most of us just about what we need, but no more. Between iPhoto and Photoshop Elements, this amateur photog (and recent convert from film cameras for holiday snaps and the like) has all he needs.
These are only a few references I've run across, but I'm most familiar with Palast's reporting of what happened in Florida (and perhaps other states). You can also try a Google search on "voting machines problems".
The implication is clear: some districts can adjust the voting machines so that more improperly marked votes can be considered spoiled, and are not counted. As in "destroyed". Other districts can set things up to give the voter another chance so that the vote is counted. The real crime appears to be that these districts can be sharply statistically defined in terms of race or party affiliation.
Furthermore, it is my understanding that the voting machines used can be set to either reject a vote if it is spoiled (and let the voter try again), or to silently eat it. One of the main criticisms of the the Florida debacle was that there is evidence that the machines in certain areas were tuned to silently eat marginal votes. In effect, some counties threw away votes, where others allowed the voter another chance.
Just as a digital system is no guarantee of voter security, it is obvious that the current system is also open to abuse. As you state, even the current voting system is vulnerable even if we are sure the votes are actually "good".
The difference is current systems have problems that are (probably) well-known. This new digital system looks like a recipe for disaster unless security and fail-over is built in from the start.
Absolutely. One of my favourite past reviews is from an audiophile mag (I forget which one) which compared speaker wire. This was the beginning of the super-deluxe-hyperbole-infused speaker interconnect industry, so the magazine used double-blind tests to see if the $500/ft (and up) products were worth it.
The results: Radio Shack 14AWG lamp cord was deemed the overall best.
Listening is a highly subjective activity, and listening to music even more subjective. I'm all for an increase in proper analysis techniques and a decrease in hyperbole when discussing things like digital music formats.
... and then this one time, at band camp...
Don't you mean Kernel Sanders?
No offense meant, but do you mean "strait" as in "Strict, rigid, or righteous" or is this an unintentional misspelling of "straight"? I'm assuming you did not mean any of the other definitions of the word.
I'm asking because the the former is an archaic use of the word "strait", which could be totally appropriate in this case.
I agree that the role of the super-unbeatable Terminator character requires mostly poker-faced acting. These are single-minded brutes, after all.
Agreed.
I work for a company that makes "enterprise" client-server apps, and out customers demand we have a complete command-line interface, along with a standard GUI and an API interface. All interfaces are actually running the same client commands, so we have some kind of interface parity. (No, our GUI is not a wrapper around the CLI! The "client" is abstract, and can only be accessed via your choice of interface.)
Customers always seem to want a scriptable and fast interface, even if it is ugly and outmoded. Everyone knows command-lines (by and large) suck. Everyone also knows we need 'em, at least for some apps and some users.
For now, anyway. Maybe when all the old-timers die (hmm, I wonder if this means me, as well), the CLI will die.
My apologies. I had assumed you were the OP. I generally browse threads with all AC comments disabled, but must have turned that back on during moderation.
As for the statement you take umbrage with, I still stand by the exact quote. Perhaps my opinion is slanted because I mostly maintain code for a living.
I never run out of bugs to fix or features to implement between major releases, and have seen a few products age beyond their useful life until a complete rewrite is warranted. Between maturing customer needs and ever-changing hardware, I just don't see that changing much in the near future, especially in the enterprise client-server world. No matter how hot your coders are, and how well the project managers do at managing the project, there is always post-release maitenance. This is my specialty, and it has served me well.
As we've discussed, there are a lot of exceptions to this. I've been out of embedded market for some time, but was once involved in the planning stages for an aerospace project. The specs on that one changed almost daily, and we had one chance to get it right.
However, it is unlikely that PHP will ever go to space in the near future, and PHP is what got us this far into this discussion. Very odd.
Quote from my very last response:
Obviously, there are a variety of ways to approach software development, and for cases like embedding software in bodies, space craft and remote industrial devices, we have to take these practices with a grain of salt. I said as much in my last comment.
However, the exception does not make the rule.
This did not start with a talk about embedded systems. This started with your comments about software names in general and PHP 5 in the specific. It is unlikely we are going to send PHP into space any time soon. There are other more tried and tested technologies we use for that purpose.
I was responding to those comments, wherein you suggested that it was misleading that PHP 5 might no longer be "PHP" simply because it has gone through 3 public major releases, and the language has changed somewhat incrementally over the years. My response was simply, "that is what software does".
Honestly, I found your orignal comments confused and misguided, and many of your assumptions lacking in logic or not based on real experience. I still think you've missed my main points which I've carefully and neutrally discussed over the length of this thread.
So, I'm going to assume your last comment was a joke; even if it wasn't, you can consider this next comment of mine as humour, also.
You are entitled to your opinion, as we all are. The entitlement, however, does not make you "right" in any sense of the word. I disagree that your are correct about your original comments in any way until you are able to argue your case clearly and logically, without any ad hominem attacks or straw-man arguments.
<span class="old-timer">
My advice is to get a little education and experience under your belt before making sweeping judgements about software life-cycle management.
</span>
'nuff said.
Some currency now has a "hologram" printed on it which appears to use the same principle.
For example, some of the newer Canadian bills have a hologram in the corner that was introduced to foil counterfeiters. My understanding is that these were created by crushing up the stuff used to make laser-cut holographic images and applying it to the paper as a printing process.
This process sounds similar to the one described in the article.