Actually, reversibility is relatively straightforward IF you have hardware trace. However, this a feature that's not uncommon in the embedded world, but nonexistant outside of it. In the absence of trace, don't bother.
ARM has put a ton of pressure on MIPS in the embedded market. Low power consumption is an advantage ARM definitely has over most MIPS cores. Also ARM/Thumb (a mixed 16/32 bit processor mode) gets excellent code compression effects, since you can use 16-bit instructions for code that doesn't need to run as fast. MIPS16 is MIPS's competing solution, but I'm not sure exactly how it stacks up. The real advantage ARM has is that they have some top-notch compiler developers in-house, so the ARM UK compiler is excellent. MIPS relies primarily on third party suppliers for their high-end development tools. (Disclaimer: I work for one of those third parties. We're working on making better MIPS code for embedded systems.)
Let's not forget that a 64-bit MIPS architecture already exists in the form of the MIPS64-5k and MIPS64-20k product lines. This must be some other new 64 architecture.
The retcon'd reasoning behind the name is that XP is like many "Extreme" sports. Certain activities are dangerous enough that you would be loony to attempt them without taking lots of safety precautions. Things like skydiving and rock climbing (on belay) come to mind. Given that safety is such a great concern, enough practices are observed such that accidents become very, very unlikely. XP is the same way. If we are aware of how badly we may fail, and we take the same amount precaution we would with "Extreme" sports, we minimize the chance of failure while still keeping eyes on the prize.
Second, what do you mean? If "coding style and abilties are in no way affected by Extreme Programming" then how would it help any programmers, even the "middling" ones you claim it is good for?
Third, XP seems to work the opposite from the way you claim. It is well to suited to projects where the requirements are likely to change, where timing matters, and where you have a small team with good skills in both programming and design. XP is anything but "a formal, rigid, factory-style coding practice used by mindless drones."
The important point that Kent makes in Extreme Programming Explained is that the practices of XP are interdependant. For example, collective code ownership doesn't work unless you have
coding standards - so people tend to write the same kind of code
extensive unit testing - so that anything that breaks is detected immediately (before it goes in the repository)
and potentially some of the other practices as well (I don't have the book in my office right now, so I forget). Kent specifically says that it is difficult/foolish to adopt some practices without the others.
I agree lots of XP seems like common sense. But how often do these practices actually occur? More often in successful projects?
Also, to reply to specifically to your objection to pair programming, several studies have shown that pair programming has a slight (10%) development time overhead that is more than made up in decreased QA and support time. For example, a 100 person-hour project which is completely separable will usually be completed in 110 person-hours by pair-programmers. However, the code is found to have something like 50% fewer defects, which translates to something like 200 saved hours in QA and support. Yes, it takes a little longer, but better code comes out.
As those who have read Kent Beck's Extreme Programming Explained should know, Extreme was not added for buzzwordness. Kent explains that he takes a number of programming practices known to be beneficial, such as code reviews, testing, incremental development. He views each of these as a dial, since you can do differing amounts of each . Extreme Programming is what results when you turn each of these dials all the way (i.e. "to the extreme"). That's the origin of the name.
BTW, though Kent refers to this as turning the dials to 10, I prefer to think of it as turning them to 11.
The real problem is that Every isn't really talking about OS's in the technical sense of the term. He says,
An operating system is the software that comes with a computer (or OS distribution) that programmers and users need to make themselves productive.
Let's forget about the term OS for a second and just use his definition instead.
For the average user (i.e. non-programmer, since the majority of computer users are non-technical and couldn't tell RAM from ROM or VBScript from C++) is the traditionally command-line driven Unix system sufficient to make them productive? Most likely not. One of the major criticism of command-line based systems is that they are very difficult to learn and to use productively, especially for non-technical people. Thus, I feel that Every's assertion that the traditional Unices are not sufficient to make the average user productive is fairly true.
This is not say that "MacOS Rules!" and modern Unix variants suck. One of the major areas in which Linux is making progress is increased usability and less reliance on knowledge of obscure command line arguments. Ultimately, I believe, it is these types of improvements that will determine the success or failure of Linux on the desktop. I will admit, when I got my first computer (a Mac SE), the fact that it was trivial to learn how to use right out of the box was really important (especially to my parents, who are decidedly non-techical). When I was first introduced to Unix, I really disliked it, because it was difficult to learn. But, I stuck with it, and now I will likely not own another machine without a Unix variant on it. But for my parents, my Debian system would not be sufficient for them to be productive. For me, their Mac would not be.
Every's problem is that tries to use the wrong term, and gets pounced on as a result. I think what he is trying to say is that the 'insanely great' part about MacOS X is not that it is Unix, but that is has a powerful foundation and is aimed at making the average user productive. Whether or not that is true is a separate issue.
In what sense is this copyright violation? I'm not a lawyer, but copyright isn't the applicable protection here. Patenting might be, and if the implementation is patented, then reverse-engineering for purposes of introducing a rival product would be illegal (and unnecessary, since if it were patented, the details would have to be disclosed as part of the patent process). However, if it is not patented, then it would be considered a trade secret which is not protected against reverse engineering. As someone else has pointed out, if I open up the hood of my car and figure out how it works and build another car, there is no legal recourse against me unless something in there is patented. Whether or not it is patentable is a separate question.
No one seems to mentioning a particulrly interesting bit of history here. When the UNIX system first appeared Kerninghan and Thompson pointed out that they could have encoded a nearly undetectible bug into the C compilter that came with the system. Suppose, they said, that whenever the C compiler recognized that it was compiling the login program (a simple enough pattern match) it would insert code that allowed Ken Thompson to login without a password. Further, whenever it complied a C compiler, it would embed code to duplicate this "functionality" in the new compiler (again, not horribly difficult). They showed that since at some point you have to accept a precompiled compiler, this bug is practically undectible. Second, they pointed out that any time you accept a precompiled binary, you are exposing yourself to this kind of security risk.
That, I think, is one of the strongest practical reasons in favor of the open source model. The ability to actually see what a program is doing to the machine you are running it on is a major advantage. A 50,000 line file may not be easy to read, but source code is definitely much easier that a million lines of 1's and 0's.
pridkett is right though. This isn't really an article about open source, its about BO2K. Yet another example of the media trying to generate interest in a topic many don't understand by throwing vaguely connected buzzwords at it.
Actually, the Ninith Circuit's decision had very little to do with privacy. Nearly the entire decision hinged on issues concerning freedom of speech. (Yes, I acutally read the entire court decision. Yes, I'm a legal junky.) Bernstein argued that the source code was in no legitimate way different from a detailed description of the algorithm. The court likened source code to the non-natural language way that mathematicians communicate their work. While the DOJ argued that the functional use of source code made it substantially different, the court rejected that argument. The court argeed that code is sometimes the only way to fully express certain ideas in a suficiently compact manner, and so it was deserving of First Amendment protection. The export restrictions represented an unjustified prior restraint on free speech, and so were rejected.
They got some good stuff on the case over at the EFF for anyone who's interested.
The play Breaking the Code by Lewis(?) Whitehead is based on Turing's life. Derek Jacobi's portrayal of Turing is supposed to be one of the great moments of British theatre. (Jacobi also played Claudius in "I, Claudius", Brother Cadfael in "Cadfael" and Claudius in Kenneth Branuagh's "Hamlet.") I read an article a few weeks ago on BBConline that efforts to raise money to build a memorial to Turing were failing miserably. Any word on that effort? I presume it's related to the Bletchly Park museum.
Slashdot Mirror
Actually, reversibility is relatively straightforward IF you have hardware trace. However, this a feature that's not uncommon in the embedded world, but nonexistant outside of it. In the absence of trace, don't bother.
ARM has put a ton of pressure on MIPS in the embedded market. Low power consumption is an advantage ARM definitely has over most MIPS cores. Also ARM/Thumb (a mixed 16/32 bit processor mode) gets excellent code compression effects, since you can use 16-bit instructions for code that doesn't need to run as fast. MIPS16 is MIPS's competing solution, but I'm not sure exactly how it stacks up. The real advantage ARM has is that they have some top-notch compiler developers in-house, so the ARM UK compiler is excellent. MIPS relies primarily on third party suppliers for their high-end development tools. (Disclaimer: I work for one of those third parties. We're working on making better MIPS code for embedded systems.)
Let's not forget that a 64-bit MIPS architecture already exists in the form of the MIPS64-5k and MIPS64-20k product lines. This must be some other new 64 architecture.
--Paul
I prefer Scott McCloud's definition. Art is anything not purely motivated by survival or reproduction.
The retcon'd reasoning behind the name is that XP is like many "Extreme" sports. Certain activities are dangerous enough that you would be loony to attempt them without taking lots of safety precautions. Things like skydiving and rock climbing (on belay) come to mind. Given that safety is such a great concern, enough practices are observed such that accidents become very, very unlikely. XP is the same way. If we are aware of how badly we may fail, and we take the same amount precaution we would with "Extreme" sports, we minimize the chance of failure while still keeping eyes on the prize.
Second, what do you mean? If "coding style and abilties are in no way affected by Extreme Programming" then how would it help any programmers, even the "middling" ones you claim it is good for?
Third, XP seems to work the opposite from the way you claim. It is well to suited to projects where the requirements are likely to change, where timing matters, and where you have a small team with good skills in both programming and design. XP is anything but "a formal, rigid, factory-style coding practice used by mindless drones."
- coding standards - so people tend to write the same kind of code
- extensive unit testing - so that anything that breaks is detected immediately (before it goes in the repository)
and potentially some of the other practices as well (I don't have the book in my office right now, so I forget). Kent specifically says that it is difficult/foolish to adopt some practices without the others.I agree lots of XP seems like common sense. But how often do these practices actually occur? More often in successful projects?
Also, to reply to specifically to your objection to pair programming, several studies have shown that pair programming has a slight (10%) development time overhead that is more than made up in decreased QA and support time. For example, a 100 person-hour project which is completely separable will usually be completed in 110 person-hours by pair-programmers. However, the code is found to have something like 50% fewer defects, which translates to something like 200 saved hours in QA and support. Yes, it takes a little longer, but better code comes out.
BTW, though Kent refers to this as turning the dials to 10, I prefer to think of it as turning them to 11.
I think that sums it up.
For the average user (i.e. non-programmer, since the majority of computer users are non-technical and couldn't tell RAM from ROM or VBScript from C++) is the traditionally command-line driven Unix system sufficient to make them productive? Most likely not. One of the major criticism of command-line based systems is that they are very difficult to learn and to use productively, especially for non-technical people. Thus, I feel that Every's assertion that the traditional Unices are not sufficient to make the average user productive is fairly true.
This is not say that "MacOS Rules!" and modern Unix variants suck. One of the major areas in which Linux is making progress is increased usability and less reliance on knowledge of obscure command line arguments. Ultimately, I believe, it is these types of improvements that will determine the success or failure of Linux on the desktop. I will admit, when I got my first computer (a Mac SE), the fact that it was trivial to learn how to use right out of the box was really important (especially to my parents, who are decidedly non-techical). When I was first introduced to Unix, I really disliked it, because it was difficult to learn. But, I stuck with it, and now I will likely not own another machine without a Unix variant on it. But for my parents, my Debian system would not be sufficient for them to be productive. For me, their Mac would not be.
Every's problem is that tries to use the wrong term, and gets pounced on as a result. I think what he is trying to say is that the 'insanely great' part about MacOS X is not that it is Unix, but that is has a powerful foundation and is aimed at making the average user productive. Whether or not that is true is a separate issue.
--Paul
In what sense is this copyright violation? I'm not a lawyer, but copyright isn't the applicable protection here. Patenting might be, and if the implementation is patented, then reverse-engineering for purposes of introducing a rival product would be illegal (and unnecessary, since if it were patented, the details would have to be disclosed as part of the patent process). However, if it is not patented, then it would be considered a trade secret which is not protected against reverse engineering. As someone else has pointed out, if I open up the hood of my car and figure out how it works and build another car, there is no legal recourse against me unless something in there is patented. Whether or not it is patentable is a separate question.
That, I think, is one of the strongest practical reasons in favor of the open source model. The ability to actually see what a program is doing to the machine you are running it on is a major advantage. A 50,000 line file may not be easy to read, but source code is definitely much easier that a million lines of 1's and 0's.
pridkett is right though. This isn't really an article about open source, its about BO2K. Yet another example of the media trying to generate interest in a topic many don't understand by throwing vaguely connected buzzwords at it.
They got some good stuff on the case over at the EFF for anyone who's interested.
The play Breaking the Code by Lewis(?) Whitehead is based on Turing's life. Derek Jacobi's portrayal of Turing is supposed to be one of the great moments of British theatre. (Jacobi also played Claudius in "I, Claudius", Brother Cadfael in "Cadfael" and Claudius in Kenneth Branuagh's "Hamlet.") I read an article a few weeks ago on BBConline that efforts to raise money to build a memorial to Turing were failing miserably. Any word on that effort? I presume it's related to the Bletchly Park museum.