If you want to visually spy on people, you can just use miniature cameras which are available today. No need for funky walls that copy one side to the other. You can hide these cameras in conventional surroundings.
Heck, we already have devices that allow light to pass through in one direction, but not in the other (or very little).
They are called one-way mirrors!
You could be put into a box made of one-way mirrors pointed toward you, and there is your no-privacy cube.
Man, people and their silly reactions to new stuff.
The problem is not the ranking system, but that you care about it. It has no inherent validity except that which is created by your concern over it. The workers' response to the system is what makes it work.
No, selective presentation of facts cannot be used to support any conclusion. For example, it cannot support a conclusion that contradicts one of the facts themselves! A set of facts will always support correct conclusions. If you find some new knowledge that contradicts one of the facts, then it was not really a fact to begin with, but an incorrect assumption. Or perhaps the new knowledge isn't factual. Facts don't contradict each other, nor does a larger set of facts contradict any conclusions that follow from any of its subsets.
The speaker's bias doesn't have any bearing on whether or not something is a fact. Either what he is saying is factual or it is not.
Bias may be used to explain a writer's incorrect reasoning: like when he uses cherry-picked facts which appear to support his desired conclusion, but in fact do not due to faulty logic.
The identification of a bias is not a shortcut toward concluding that a writer is wrong! Nor does it make it more difficult to know that a writer is wrong. It only provides an after-the-fact hypothesis about why he is wrong, namely that he may be deliberately wrong not because his reasoning is faulty, but because his vested interests are leading him to make arguments that are deliberately persuasive of those who are unable to spot the faulty reasoning.
The loss of credibility has already taken place by this point, and doubt of character is beginning to take root.
If you have USB, just plug in an extra keyboard and mouse. This will turn any old application into one where two people can work at the same time, if they just politely hand control over the cursor to each other.
Aegis assumes that when working on a LAN, you will use a networked file system of some sort.
NFS is adequate for this task, and commonly available. By using NFS, there is very little difference between the single-machine case and the multi-machine-case.
This is wishful thinking. To be reliable, version control must be based on some sane client-server protocol.
Visual SourceSafe's reliabilty problems are caused in large part to the use of file sharing rather than a proper protocol. CVS is also known to be unreliable when a repository is accessed via NFS rather than in client-server mode. This practice is loudly discouraged by experts in the CVS mailing list.
NFS implementations differ from one another. As a rule of thumb, NFS works best when you have a matching client and server implementation from the same vendor.
CVS ensures mutual exclusion over an entire tree when you commit, and performs an up-to-date-check which will fail your commit if *any* files, including ones you did not touch, have new revisions that you have not incorporated into your working copy.
Taking advantage of the ``up-to-date check failed'' feature requires that you do a whole-tree commit at some level of the tree structure that you care about---perhaps the project root---rather than doing a selective commit on individual files. Change to an appropriate directory level and execute a ``cvs ci'' without any filename arguments.
The other part of the equation is doing a proper regression test before committing. It would be nice to automate this, but in the real world, that is a pipe dream.
What if your tests have to be executed on something other than your development platform, such as a PDA or embedded system? What if you are targetting several flavors of Unix-like operating systems and Windows?
Your regression test run on Linux does not assure you that you did not break the Win32 version of the program.
That's not to say that there isn't value in running at least *some* automated tests, like for instance exercising the functions of some portable library.
Relax. Those are nothing but noun phrases. The difference is that in the English writing system, we are use spaces to separate the nouns. This makes them easier to unravel, but leads to other ambiguities.
Consider for instance ``Law school entrance requirement examination test score''.
The noun phrase has a root, on the rightmost side, in other words ``score''. The other nouns modify the root, giving it more refined semantics. It's a test score; moreover, it is an examination test score, and so forth.
Now if you were German, you would write lawschoolentrancerequirementexaminationtestscore. Probably with enough practice, you can learn to read this!;)
So what will happen is that the clueless masses will merely become *aware* of the possibility that there need not necessary be a sharp boundary between the programming system and the operating system kernel. Well, that's progress too, I suppose.;)
If the programming language is safe, and special privileges are required to load arbitrary machine code, you can do away with the kernel/user boundary that is enforced by the hardware, and the parameter validation overheads that entails. If a disk-writing function receives a byte array from the application, it can just trust the integrity of that object---that it doesn't contain unmapped pages, etc.
Security credentials can just be an ordinary object that you inspect using an ordinary accessor. The language-level mechanisms ensure that you can't fake credentials, simply because you have no write-accessor to do it, and no way to fake one, not having access to writing raw machine language.
We live in a country where, we, the end users, must suffer a sub-par product because of the power and influence of multi-BILLION dollar companies. None of us can even conceive of that kind of loot. Yet us and the rest of the world get to pay so that a handful of people get unheard of profit. That is not capitalism.
Sorry, yes it is. If you don't like the product, don't use it. I, for one, do not count myself among those to whom you refer as ``we the end users''. I don't own any Microsoft software.
Maybe you have not heard of Linux? BSD? Solaris? Apple Macintosh? Hello, what site are you posting to? What does it run on? What language is it written in? It's not Visual Basic.
Capitalism means the pursuit of unlimited wealth. Who should decide how many billions are enough for someone else? Who will take the excess away and distribute it to others? And what can we call him but a robber?
Face it, you are just a Marxist-Leninist troglodyte. Put your money where your mouth is and relocate to China.
Why should the strong be forced to carry the product of the weak? Is it because the unsuccessful have a *need* for profit? Is it an inalienable right to move product regardless of whether anyone wants it?
I have two words for this: corporate welfare.
If there must be welfare, it should go to some washed up individuals who can't take responsibility for their lives, not to corporations! It's not even humanitarian anymore when you help corporations; it's just plain stupidity. It a form of socialism consisting of empty Marxist principles abstracted away from any kind of meaningful social context that would give them even a trace of a vague justification.
I don't like Microsoft's idiotic, unreliable, inflexible, non-interoperable products any more than the next open source hacker, but this is not the right way. Microsoft, and indeed every software enterprise, should be able to take whatever bit pattern they want, so long as they didn't steal it, stamp it on a CD, and ship it.
Sun had lots more experience developing systems (software *and* hardware) than Microsoft. They did the Microsoft thing to mainframes and minis by developing cheap workstations running Unix. Nobody wanted a fridge-sized Vax after seeing a 32 bit Sun workstation. They had a shot at becoming the number one operating system vendor for personal computers. They are losers: they blew it. Losers should die, not whine and snivel their way into an extension of their existence in some courtroom.
What will we see next? McDonald's restaurants in the USA being forced to hand out coupons for Subway with every meal or sandwich sold?
I hope the people at Sun are happy with their accomplishment---that their product will be carried on the back of a competitor's product by governmental coersion, ending up on the desktops of many people who don't even want it. It must sure feel great to be on the JVM development team at Sun right now!
First you write the program, then you get users. Once you have those two ingredients, only then should you think about a mailing list, a comprehensive project page, public CVS access, registered domain name in the name of the program and so forth.
If you have no talent yourself, forget about attracting those who do in order to assemble a project out of nothing. You can't do that with an empty web site; the usual custom is to start a software company, get some VC, and pay people.
Isn't any of this obvious? But then if you had any brains, you would not ``Ask Slashdot''.
Using free software is yet another way by which the socialist collectivists can take advantage of the labor of the capable producers. There is nothing to cheer about when a government uses free software.
The people who write free that software have jobs too, and they have to pay taxes. Using someone's free program is one thing, but doing that while stealing a portion of his earnings, that is disgusting.
Just looking at a mouse shows striking similarities to a human being. Skeleton with a backbone, pelvis and skull. Two eyes. Brain, nervous system, heart, lungs. A nose with two holes above a mouth, between two eyes. Et cetera.
It's not that astounding that similarities in the genetic code should be found, or even striking ones.;)
A hot new startup in California has announced a technology for encoding color information in black-and-white television broadcasts. The extra signal is encoded such that black-and-white receivers don't notice it, using a proprietary technique referred to as a ``subcarrier''. Millions of Slashdot kiddies are smitten with awe.
Okay, so you have a piece of hardware with a proprietary operating system. So far so good. But now with trusted computing, that system won't load any component that is not signed by a trusted party. It's not about you trusting what you run, but about Microsoft choosing who gets the privilege of writing software for the platform. If Microsoft doesn't like you, for whatever reason, they can just refuse the signature that is needed for your software to load. This is basically where it is headed; it's the one sure way to use your monopoly to crush the competition, in particular open source. Even if some open source developers get Microsoft to approve their program, that signature will be applied to a particular binary release. The users cannot roll their own binary from the sources, because that won't carry the signature of a ``trusted'' certificate. So basically the operating system vendor regains control as the gatekeeper who determines what will run on your machine. What's worse, if the hardware vendors follow suit, then a certificate will be required by an operating system to boot on the hardware. If you are lucky enough to get a signed version of your favorite free kernel, good luck rebuilding it. The developers may be forbidden from giving you the certificate, if they get to d the signing themselves. That key is copyrighted bits, right? Letting everyone have it would be against the DMCA.
Assuming that the difference in TCO is real, who cares why? If it's partially due to Linux admins being more experienced, then so be it; that just suggests that when you run Linux, you attract more qualified people, who contribute to a lower TCO through their increased productivity. Great!Maybe the same people could achieve it with Windows too, but that is only a theoretical conjecture if they don't actually want to.
Say I work on a competing version control system. Why would I care that they want to play sour grapes and deny me (so called) free use of their version control system?
I do work on a version control system, as a matter of fact. And indeed my only reason for installing BK would be to examine its good ideas and try to incorporate them into my program. Not that I care to do this, mind you, but hypothetically speaking.
Thus they are pretty damn right to demand payment for that kind of use of their product which leads to the potential erosion of their business.
And for actual version control, I use my own program, of course! I think that my program is the greatest thing; but not only that, I *must* use it so that I discover and fix bugs, and so that my experience with it grows and leads me to new directions. It would be counterproductive of me to work on this program, but then turn around and use BK or any other version control system. So I could not care less that BK doesn't want me to have free stuff; I have cooked my own dogfood and am eating that, thank you very much!
Also note that their clause works both ways. Suppose that I'm a developer working at Rational on the ClearCase product. BitKeeper could benefit from my experience; I could make contributions to their code if it was truly free. But, alas, they want me to pay for the privilege of sending them bug fixes. Oops; they will just have to lure me away from the competitor entirely. Knowledge flows both ways; what impedes one direction tends to impede the opposite one too.
Transactions are highly overrated, and the lack of them doesn't pose a serious problem to CVS users at all.
When a group of files are commited together, that information is not irretrievably lost. Tools exist which can extract these change sets out of CVS; for example Karl Fogel's cvs2cl perl script. There are some hacks involved, such as looking at ranges of timestamps, but it works.
It's possible that a network failure can interrupt a CVS commit. That isn't much of a problem; you simply reestablish the connection and complete it. This doesn't pose any serious problem to your configuration management process. In principle, CVS could be modified to do commits in two phases; in the first phase, build up the files to be committed, and in the second phase, rename them over top of the original ones, rather than doing this file by file. That would require a lot of extra disk space for large commits, with no real benefit.
I have developed a project which addresses many of the real *semantic* issues of CVS version control, by layering a little bit of clever software on top of the CVS client. Meta-CVS versions the directory structure, symbolic links, execute permissions and property lists attached to objects. See http://www.freshmeat.net/projects/mcvs. Meta-CVS also simplifies branching and merging, handling all the tagging to keep track of what has been merged where. These are the number one and two pains in CVS: lack of support for renaming, and branching that requires the explicit, tedious management of irrelevant details. Add these on top of CVS and you have a pretty decent version control system.
Crackers are criminals who should be punished to the fullest extent of the law in the home region of the computer system where the crime took place. Moreover, the law enforcement agencies throughout the world should cooperate as much as possible to make this happen. If that requires breaking into a cracker's computer, that is fair game.
Complaining about the reverse cracking on part of the police is analogous to complaining about a police officer's use of a firearm against a criminal who is also wielding a firearm. By breaking into other people's computers, you forfeit your right not to have it done to you by those who want to catch you.
It's normal for police officers to use the same tools that are used by criminals: speeding cars, deadly firearms, break and enter tools. The tools go with the territory; the tools alone don't define the moral context of their use.
You start by decoupling the text syntax from the data structure representation of the program. The Lisp language does this. Having this separation, you can continue to use the text notation to code for the data structure which makes up the true source of the program. Or you can write programs that construct that structure, perhaps out of pieces that you codify using the text notation. Or you can do something totally different: make a GUI which lets the user manipulate objects, and have that object manipulation generate data structures which represent programs that are compiled and executed. The technology for doing this has existed for a long time already.
It's been done; for example Lisp represents programs as data structures rather than text. The structures are often obtained by scanning a text notation, but that is not strictly necessary. Sometimes the structure is manufactured by the program itself. Or it could come from some GUI manipulations, whatever. I wonder what Simonyi could be up to in this area that is original? (Original to the entire computing world, that is, not just ignorant pockets thereof).
Slashdot Mirror
If you want to visually spy on people, you can just use miniature cameras which are available today. No need for funky walls that copy one side to the other. You can hide these cameras in conventional surroundings.
Heck, we already have devices that allow light to pass through in one direction, but not in the other (or very little).
They are called one-way mirrors!
You could be put into a box made of one-way mirrors pointed toward you, and there is your no-privacy cube.
Man, people and their silly reactions to new stuff.
The problem is not the ranking system, but that you care about it. It has no inherent validity except that which is created by your concern over it. The workers' response to the system is what makes it work.
No, selective presentation of facts cannot be used to support any conclusion. For example, it cannot support a conclusion that contradicts one of the facts themselves! A set of facts will always support correct conclusions. If you find some new knowledge that contradicts one of the facts, then it was not really a fact to begin with, but an incorrect assumption. Or perhaps the new knowledge isn't factual. Facts don't contradict each other, nor does a larger set of facts contradict any conclusions that follow from any of its subsets.
The speaker's bias doesn't have any bearing on whether or not something is a fact. Either what he is saying is factual or it is not.
Bias may be used to explain a writer's incorrect reasoning: like when he uses cherry-picked facts which appear to support his desired conclusion, but in fact do not due to faulty logic.
The identification of a bias is not a shortcut toward concluding that a writer is wrong! Nor does it make it more difficult to know that a writer is wrong. It only provides an after-the-fact hypothesis about why he is wrong, namely that he may be deliberately wrong not because his reasoning is faulty, but because his vested interests are leading him to make arguments that are deliberately persuasive of those who are unable to spot the faulty reasoning.
The loss of credibility has already taken place by this point, and doubt of character is beginning to take root.
Someone luckily stashed a PDF of this (Copyright 1999 The Onion).
There you go.
If you have USB, just plug in an extra keyboard and mouse. This will turn any old application into one where two people can work at the same time, if they just politely hand control over the cursor to each other.
Multiple people working on one text document is old hat.
For example, CVS: edit locally at will, ``cvs up'' to integrate changes others have committed, resolve any conflicts, continue.
Even Visual SourceSafe supports this to a degree.
In other words, it's amazing what amazes some people.
6.1.3 Multi User, Multi Machine
Aegis assumes that when working on a LAN, you will use a networked file system of some sort. NFS is adequate for this task, and commonly available. By using NFS, there is very little difference between the single-machine case and the multi-machine-case.
This is wishful thinking. To be reliable, version control must be based on some sane client-server protocol.
Visual SourceSafe's reliabilty problems are caused in large part to the use of file sharing rather than a proper protocol. CVS is also known to be unreliable when a repository is accessed via NFS rather than in client-server mode. This practice is loudly discouraged by experts in the CVS mailing list.
NFS implementations differ from one another. As a rule of thumb, NFS works best when you have a matching client and server implementation from the same vendor.
CVS ensures mutual exclusion over an entire tree when you commit, and performs an up-to-date-check which will fail your commit if *any* files, including ones you did not touch, have new revisions that you have not incorporated into your working copy.
Taking advantage of the ``up-to-date check failed'' feature requires that you do a whole-tree commit at some level of the tree structure that you care about---perhaps the project root---rather than doing a selective commit on individual files. Change to an appropriate directory level and execute a ``cvs ci'' without any filename arguments.
The other part of the equation is doing a proper regression test before committing. It would be nice to automate this, but in the real world, that is a pipe dream.
What if your tests have to be executed on something other than your development platform, such as a PDA or embedded system? What if you are targetting several flavors of Unix-like operating systems and Windows?
Your regression test run on Linux does not assure you that you did not break the Win32 version of the program.
That's not to say that there isn't value in running at least *some* automated tests, like for instance exercising the functions of some portable library.
Relax. Those are nothing but noun phrases. The difference is that in the English writing system, we are use spaces to separate the nouns. This makes them easier to unravel, but leads to other ambiguities.
;)
Consider for instance ``Law school entrance requirement examination test score''.
The noun phrase has a root, on the rightmost side, in other words ``score''. The other nouns modify the root, giving it more refined semantics. It's a test score; moreover, it is an examination test score, and so forth.
Now if you were German, you would write lawschoolentrancerequirementexaminationtestscore. Probably with enough practice, you can learn to read this!
So what will happen is that the clueless masses will merely become *aware* of the possibility that there need not necessary be a sharp boundary between the programming system and the operating system kernel. Well, that's progress too, I suppose. ;)
If the programming language is safe, and special privileges are required to load arbitrary machine code, you can do away with the kernel/user boundary that is enforced by the hardware, and the parameter validation overheads that entails. If a disk-writing function receives a byte array from the application, it can just trust the integrity of that object---that it doesn't contain unmapped pages, etc.
Security credentials can just be an ordinary object that you inspect using an ordinary accessor. The language-level mechanisms ensure that you can't fake credentials, simply because you have no write-accessor to do it, and no way to fake one, not having access to writing raw machine language.
Sorry, yes it is. If you don't like the product, don't use it. I, for one, do not count myself among those to whom you refer as ``we the end users''. I don't own any Microsoft software.
Maybe you have not heard of Linux? BSD? Solaris? Apple Macintosh? Hello, what site are you posting to? What does it run on? What language is it written in? It's not Visual Basic.
Capitalism means the pursuit of unlimited wealth. Who should decide how many billions are enough for someone else? Who will take the excess away and distribute it to others? And what can we call him but a robber?
Face it, you are just a Marxist-Leninist troglodyte. Put your money where your mouth is and relocate to China.
Why should the strong be forced to carry the product of the weak? Is it because the unsuccessful have a *need* for profit? Is it an inalienable right to move product regardless of whether anyone wants it?
I have two words for this: corporate welfare.
If there must be welfare, it should go to some washed up individuals who can't take responsibility for their lives, not to corporations! It's not even humanitarian anymore when you help corporations; it's just plain stupidity. It a form of socialism consisting of empty Marxist principles abstracted away from any kind of meaningful social context that would give them even a trace of a vague justification.
I don't like Microsoft's idiotic, unreliable, inflexible, non-interoperable products any more than the next open source hacker, but this is not the right way. Microsoft, and indeed every software enterprise, should be able to take whatever bit pattern they want, so long as they didn't steal it, stamp it on a CD, and ship it.
Sun had lots more experience developing systems (software *and* hardware) than Microsoft. They did the Microsoft thing to mainframes and minis by developing cheap workstations running Unix. Nobody wanted a fridge-sized Vax after seeing a 32 bit Sun workstation. They had a shot at becoming the number one operating system vendor for personal computers. They are losers: they blew it. Losers should die, not whine and snivel their way into an extension of their existence in some courtroom.
What will we see next? McDonald's restaurants in the USA being forced to hand out coupons for Subway with every meal or sandwich sold?
I hope the people at Sun are happy with their accomplishment---that their product will be carried on the back of a competitor's product by governmental coersion, ending up on the desktops of many people who don't even want it. It must sure feel great to be on the JVM development team at Sun right now!
First you write the program, then you get users. Once you have those two ingredients, only then should you think about a mailing list, a comprehensive project page, public CVS access, registered domain name in the name of the program and so forth.
If you have no talent yourself, forget about attracting those who do in order to assemble a project out of nothing. You can't do that with an empty web site; the usual custom is to start a software company, get some VC, and pay people.
Isn't any of this obvious? But then if you had any brains, you would not ``Ask Slashdot''.
Using free software is yet another way by which the socialist collectivists can take advantage of the labor of the capable producers. There is nothing to cheer about when a government uses free software.
The people who write free that software have jobs too, and they have to pay taxes. Using someone's free program is one thing, but doing that while stealing a portion of his earnings, that is disgusting.
Just looking at a mouse shows striking similarities to a human being. Skeleton with a backbone, pelvis and skull. Two eyes. Brain, nervous system, heart, lungs. A nose with two holes above a mouth, between two eyes. Et cetera.
;)
It's not that astounding that similarities in the genetic code should be found, or even striking ones.
A hot new startup in California has announced a technology for encoding color information in black-and-white television broadcasts. The extra signal is encoded such that black-and-white receivers don't notice it, using a proprietary technique referred to as a ``subcarrier''. Millions of Slashdot kiddies are smitten with awe.
Okay, so you have a piece of hardware with a proprietary operating system. So far so good. But now with trusted computing, that system won't load any component that is not signed by a trusted party. It's not about you trusting what you run, but about Microsoft choosing who gets the privilege of writing software for the platform. If Microsoft doesn't like you, for whatever reason, they can just refuse the signature that is needed for your software to load. This is basically where it is headed; it's the one sure way to use your monopoly to crush the competition, in particular open source. Even if some open source developers get Microsoft to approve their program, that signature will be applied to a particular binary release. The users cannot roll their own binary from the sources, because that won't carry the signature of a ``trusted'' certificate. So basically the operating system vendor regains control as the gatekeeper who determines what will run on your machine. What's worse, if the hardware vendors follow suit, then a certificate will be required by an operating system to boot on the hardware. If you are lucky enough to get a signed version of your favorite free kernel, good luck rebuilding it. The developers may be forbidden from giving you the certificate, if they get to d the signing themselves. That key is copyrighted bits, right? Letting everyone have it would be against the DMCA.
A *government* wants to help itself to the fruits of the people's labor without compensating them? Wow, say it isn't so!
Assuming that the difference in TCO is real, who cares why? If it's partially due to Linux admins being more experienced, then so be it; that just suggests that when you run Linux, you attract more qualified people, who contribute to a lower TCO through their increased productivity. Great!Maybe the same people could achieve it with Windows too, but that is only a theoretical conjecture if they don't actually want to.
Say I work on a competing version control system. Why would I care that they want to play sour grapes and deny me (so called) free use of their version control system?
I do work on a version control system, as a matter of fact. And indeed my only reason for installing BK would be to examine its good ideas and try to incorporate them into my program. Not that I care to do this, mind you, but hypothetically speaking.
Thus they are pretty damn right to demand payment for that kind of use of their product which leads to the potential erosion of their business.
And for actual version control, I use my own program, of course! I think that my program is the greatest thing; but not only that, I *must* use it so that I discover and fix bugs, and so that my experience with it grows and leads me to new directions. It would be counterproductive of me to work on this program, but then turn around and use BK or any other version control system. So I could not care less that BK doesn't want me to have free stuff; I have cooked my own dogfood and am eating that, thank you very much!
Also note that their clause works both ways. Suppose that I'm a developer working at Rational on the ClearCase product. BitKeeper could benefit from my experience; I could make contributions to their code if it was truly free. But, alas, they want me to pay for the privilege of sending them bug fixes. Oops; they will just have to lure me away from the competitor entirely. Knowledge flows both ways; what impedes one direction tends to impede the opposite one too.
Transactions are highly overrated, and the lack of them doesn't pose a serious problem to CVS users at all.
When a group of files are commited together, that information is not irretrievably lost. Tools exist which can extract these change sets out of CVS; for example Karl Fogel's cvs2cl perl script. There are some hacks involved, such as looking at ranges of timestamps, but it works.
It's possible that a network failure can interrupt a CVS commit. That isn't much of a problem; you simply reestablish the connection and complete it. This doesn't pose any serious problem to your configuration management process. In principle, CVS could be modified to do commits in two phases; in the first phase, build up the files to be committed, and in the second phase, rename them over top of the original ones, rather than doing this file by file. That would require a lot of extra disk space for large commits, with no real benefit.
I have developed a project which addresses many of the real *semantic* issues of CVS version control, by layering a little bit of clever software on top of the CVS client. Meta-CVS versions the directory structure, symbolic links, execute permissions and property lists attached to objects. See http://www.freshmeat.net/projects/mcvs. Meta-CVS also simplifies branching and merging, handling all the tagging to keep track of what has been merged where. These are the number one and two pains in CVS: lack of support for renaming, and branching that requires the explicit, tedious management of irrelevant details. Add these on top of CVS and you have a pretty decent version control system.
Crackers are criminals who should be punished to the fullest extent of the law in the home region of the computer system where the crime took place. Moreover, the law enforcement agencies throughout the world should cooperate as much as possible to make this happen. If that requires breaking into a cracker's computer, that is fair game.
Complaining about the reverse cracking on part of the police is analogous to complaining about a police officer's use of a firearm against a criminal who is also wielding a firearm. By breaking into other people's computers, you forfeit your right not to have it done to you by those who want to catch you.
It's normal for police officers to use the same tools that are used by criminals: speeding cars, deadly firearms, break and enter tools. The tools go with the territory; the tools alone don't define the moral context of their use.
You start by decoupling the text syntax from the data structure representation of the program. The Lisp language does this. Having this separation, you can continue to use the text notation to code for the data structure which makes up the true source of the program. Or you can write programs that construct that structure, perhaps out of pieces that you codify using the text notation. Or you can do something totally different: make a GUI which lets the user manipulate objects, and have that object manipulation generate data structures which represent programs that are compiled and executed. The technology for doing this has existed for a long time already.
It's been done; for example Lisp represents programs as data structures rather than text. The structures are often obtained by scanning a text notation, but that is not strictly necessary. Sometimes the structure is manufactured by the program itself. Or it could come from some GUI manipulations, whatever. I wonder what Simonyi could be up to in this area that is original? (Original to the entire computing world, that is, not just ignorant pockets thereof).
Remember, it's carbonated, and the pressure will drop. ;)