...you just need to be patient. This license does appear to address the major concerns that were raised with regard to version 1.0, but there are still smaller issues. Off the top of my head:
1) Cumbersome notification requirements. It has been pointed out that the notification requirement is an obstacle to rapid development-- the model of: "grab a bunch of code, combine it in nifty new ways, and hang it out on the net" becomes: "grab a bunch of code, combine it in nifty ways, check all licenses involved, fill out all necessary virtual paperwork, write all legally required documentation, and hang it out on the net." Much less appealing, but probably necessary for Large Corporate Entities.
2) Non-reciprocal notification requirements. You are required to notify Apple of your modifications, but Apple is not required to share them in turn with others. This violates the spirit, if not the letter of the DFSG/OSD
3) Disclosure required for *deployment*. While I can understand Apple's position here, I think that there are many instances in which a company might internally deploy modified code covered by GPL/XFree/other only so long as the license does not require them to disclose their modifications to any external party. Code covered by GPL/BSD/other licenses fits this requirement, while code covered by the APSL does not. While some might percieve this as making the APSL more open, others will percieve it as making the APSL less free. Both views have merit.
4) The new license has not been accompanied by any indication that Apple might be willing to shift code that they have not substantially altered back to its original BSD license, or in any other way acknowledge the contributors to the BSD project who did the bulk of the work behind the "Darwin" product. There is, by design, no legal obligation to do this, of course, but I think there is a strong moral obligation that has not been addressed.
There are other issues as well, and I encourage you to find them and bring them to light as you consider or debate the points enumerated above.
The article is more of a report on the drug culture in the UK than a report on drug culture in IT. My limited experience says that Brits tend to embrace recreational speed and pharmeceuticals, while Americans are more puritan, often inisisting on "natural" drugs, or cleaving to the insistent "NO." Drugs seem to be a bigger part of youth culture in the UK as well, but this impression of mine may be driven more by media than reality.
This was one of the central notions behind the Max Headroom series-- real time ratings. The blipvert (high-speed advert) seems to have happened already, too-- does anyone else remember how strange it was to watch those first 15-second spots?
Well, I didn't think he was retiring. A couple of things bother me in this most recent ESR piece.
1) The accusation of "Bomb Throwing" levelled against Bruce Perens, RMS, et. al. The points that these people raised were carefully considered and valid. ESR's rebuttals have been largely ad-hominim, and I think he owes these people an apology, rather than the announcement of a planned vacation with his preferred firearm.
2) The dismissal of Slashdot as a forum for "kiddies". Sure, it's a public forum, and it has the disadvantages of such (though moderation may change this). The fact of the matter is that there is a great deal of good thinking to be found in the comments here. Dismissing Slashdot is disingenuous-- if Slashdot just a bunch of kiddies, then why does ESR feel compelled to mention it at all?
Slashdot is widely recognized in the mainstream press as the premier public forum for debate on issues surrounding open source and free software. I think OSI can only be held accountable for their actions by the community that they wish to represent, and they dismiss the prefered forum of that community at their peril.
Yes, ESR deserves our support, and our thanks. He also deserves to be held accountable by those who he is trying to serve.
For N tapes, if you have N tape-writing devices at each end, then writing/reading time will only add a few hours to the drive time, and won't have any more effect than a snowstorm in the rockies or lousy traffic in Chicago.
How about cost per MB/sec? I think a bunch of CD-R on a spindle might be the best bet there.
The article states that Jobs confirmed "discussions" with 3com about buying the Palm division. It also said that there was no comment about licensing the palm technology and issuing an apple-branded Palm, like the IBM Workpad.
These rumors are a little too sparse for me, and the two different possibilies outlined would have very different implications.
A sale would be a little unlike Apple-- they've historicly had an acute case of the old NIH syndrome, though this is changing.
A straight licensing deal would be neat, though-- the masses would really dig an iPalm in 5 fruity flavours.
I'll bet the emial interface still works.
on
InterNIC Redesign
·
· Score: 2
The/. copy for this piece is quite unclear, and needs editing.
I've noticed the changes that Network Solutions have been moving into place, and I can't say I mind terribly-- I do all of my Domain Name registration via email. If you want to bring attention to a really deceptive practice, have a look at www.internic.com, where the unsuspecting can enjoy a 200% markup for domain name registration!
You misread BP, but maybe it is a problem, anyway.
on
RMS on APSL
·
· Score: 2
I don't think Bruce said that the notification clause was a violation of OS-- he just said it's a problem, as in "it could become a great inconvenience to developers."
But I think it is a problem. You are required to notify Apple of your Modifications, but they are not required to make those modifications available to anyone else. The license should require Apple to keep a publicly accessible database of all Modifications (not just those that are folded into later releases). Furthermore, as the license stands, you must notify apple before sharing any Modification with anyone-- otherwise, said sharing will be in violation of the notification clause. There is no "reasonable time" language in the license-- the words "within one week," e.g., could go a long way.
For the APSL to gain more respect, it needs to read more like a contract between Apple and the Free Software community, where both parties have rights and obligations, and less like a set of conditions imposed by Apple on its would-be developers.
Ack, bad formatting, read this instead.
on
RMS on APSL
·
· Score: 1
>1) You can get, use, modify, and compete with >Apple using their own (and others) source, with >some restrictions.
But it would be foolish to do so, since Apple has the right to make modifications without distributing them under APSL, whereas You do not, and Apple is guaranteed to see every proposed modification, whereas You are not.
>2) Apple now has to provide some additional value >added to make money.
Maybe not-- see above. But it is already apparent that Apple will be making money by keeping the source to the upper layers of MacOS X proprietary. If the past is any indication, then the efforts of the Free Software community will go toward cloning the upper layers before any significant contribution is made to the "Darwin" codebase. If that happens, then Apple will face a very tough choice:
some of their options will be:
1. Use patent litigation to slow the cloning effort, thereby earning ill-will in the developer community.
2. Realease the upper layers under an open source license, just as Troll tech changed the license on QT when the Harmony project threatened to make them irrelevant. Profits then have to come from hardware and services.
3. Play Microsoft with their APIs, changing things frequently and leaving large portions undocumented, thereby earning the wrath of third-party software vendors.
4. Release APIs and documentation only under NDA, thereby alienating the computer book publishers, and inconveniencing the small third party developer.
There are many other options, I'm sure, but those are the ones that jumped off the top of my head.
>1) You can get, use, modify, and compete with >Apple using their own (and others) source, with >some restrictions. But it would be foolish to do so, since Apple has the right to make modifications without distributing them under APSL, whereas You do not, and Apple is guaranteed to see every proposed modification, whereas You are not. >2) Apple now has to provide some additional value >added to make money. Maybe not-- see above. But it is already apparent that Apple will be making money by keeping the source to the upper layers of MacOS X proprietary. If the past is any indication, then the efforts of the Free Software community will go toward cloning the upper layers before any significant contribution is made to the "Darwin" codebase. If that happens, then Apple will face a very tough choice: some of their options will be: 1. Use patent litigation to slow the cloning effort, thereby earning ill-will in the developer community. 2. Realease the upper layers under an open source license, just as Troll tech changed the license on QT when the Harmony project threatened to make them irrelevant. Profits then have to come from hardware and services. 3. Play Microsoft with their APIs, changing things frequently and leaving large portions undocumented, thereby earning the wrath of third-party software vendors. 4. Release APIs and documentation only under NDA, thereby alienating the computer book publishers, and inconveniencing the small third party developer. There are many other options, I'm sure, but those are the ones that jumped off the top of my head.
Is it just me, or does the term "beta" seem vaguely inappropriate for open source projects?
"Feature freeze" and "stable snapshot" carry more meaning: "beta" is a _marketing_ term, used, I think, to make the public think that an overdue product is close to release. How long has WinNT 5 been in "beta" now? About as long as I've been reading "reviews" of this OS, I'll wager.
I don't feel any compelling need to come up with new terms to replace "alpha" and "beta"-- the phrases above work well enough for me-- but it's something to think about. Maybe Perens and Raymond could come up with competing terms. That would be fun:).
I work for a record company, and I have had a long discussion with Escient. They are unwilling to change the terms of the license. The compromise you suggest is not possible unless Escient is willing to change. They are not. So there is no choice but to move forward with free alternatives.
I would like to add that the folks at Escient do not appear to be music fans or record collectors. They do not seem to have any respect for the rights of the artists and labels from whose work they seek to profit. And they certainly did not consult with an attorney familiar with the music industry before attempting to execute their business plan.
Escient cannot claim ownership of data you submit if that data is already owned by someone else-- in this case, the data is owned by record companies or artists (depending on contracts).
Technically, the content is the intellectual property of the respective Record Labels or Arists (depending on contract).
This is a good thing, actually-- it can be used to weaken Escient. I work for a Record Company. We've already told Escient to either compete through quality of service rather than restrictive licensing, or remove our intellectual property from their database.
I work for a record company. I've written to Escient and told them to remove all of our intellectual property from their database until they are prepared to compete based on the quality of their service rather than restrictive licensing techniques.
I've also sent copies of my correspondence to other independent record labels, suggesting a similar course of action. The 800 pound gorilla in this game is RIAA-- if they lean on Escient, then Escient will crack. But we all hate RIAA, right??
Intellectual property can be used for good as well as for evil, kids. Think about it.
Jesus. What the hell are we going to do when slashdot gets its first 1000-comment article?
CA Class action a result of Windows refund day?
on
Microsoft-Compaq-BeOS
·
· Score: 1
It isn't stated explicitly, but it looks to me as though the California class action suit was filed after Microsoft/Dell/Compaq/etc. failed to provide refunds on the 15th.
This would make for a better story, but is there any basis in fact?
"Microsoft's Refusal to Provide Refunds Backfires" sure is a nice headline...
There are widely differing assumptions here about what makes a "Graphics Workstation." Me, I think it would be something that an architect or engineer can use to do CAD type stuff, and then manipulate a 3D model of the design in a window.
It would have helped quite a lot if the original poster had mentioned what sort of work was being planned, and what sort of software was to be used.
For work that needs to be done today:
A used SGI indy runs less than $2k these, irix 6.5 and a 1-year service contract will run you around $350. Not a speed demon, but the graphics hardware is dandy, and the applications are readily available.
$1000 and Linux just aren't reasonable yet for building a "Graphics Workstation". Give it a year or two.
There are a lot of folks here saying that the technique was "obvious" to them after they saw the technique used for the first time. Well, sure. That's why they don't give you patents for figuring out how someone else did something. If, on the other hand, you manage to dream up something that no-one has ever seen before, and then make it happen... well, then you probably deserve a patent.
Me, I thought it was fewer cameras, more computers. Nice to see a good analog solution once in a while.
Did you know that Microsoft has a trademark on the word "internet" as well? They didn't enforce it, so it's not valid anymore. Patents are different, of course, but prior art should take care of this one in short order.
On another note, don't pay too much attention to Reardon. He's one of those kids who got high SAT scores and now believes himself to be smarter than everyone else based on the value of his stock options. Most of his coworkers think he's an asshole, and he's probably proud of it. Last time I was at his house, he and his 'friends' were trying to impress each other with their knowledge of wine, measured by the amount one could afford to spend on a bottle. Pathetic.
Buy a modest machine and a good backup device.
on
XP1000 Workstation
·
· Score: 1
A backup device that can handle the average drive size these days is pretty pricey.
I say buy a PC for 1-2 grand and a DDS-3 tape drive for another grand. The tape drive will serve your needs for five years and more, the rest of the system will seem clunky after two.
A CD-RW might work, but I'd go with the tape-- the media can be written a larger number of times, and 600MB for the CD just doesn't compare to the 12 GB on tape.
There are too many students out there who neglect backup entirely.
Oh, and buy a good monitor. Lesser monitors degrade sharply after 2-3 years.
The method is only a hindrance, not a panacea, even if the method is only applied to source code. I think I tried to stress that.
Machine-code trojans would tend to be platform dependant, and would be much harder to implement, especially for a portable, cross-compiling compiler such as gcc.
I assume that by a "machine code implementation" yo mean a trojan that would wait until code had been compiled, and then examine the resultant bits for a particular pattern to replace.
Small changes to the source code could result in such large changes to the object code that this method would only be practical for infecting code that is not expected to change. The exuberant code munger could randomly salt the code with valid but useless statements-- printing to/dev/null, sending a packet to the loopback, etc., that could not be optimised out. This unseemly bloat would monkeywrench trojans expecting a nice predictable chunk of machine code. Going through many generations of this before generating a binary with no "extras" would reduce a trojan's chances of survival.
The problem of recognizing a particular function in a particular program in machine code for many different platforms is on a par with recognizing a particular function in a particular program in source code with arbitrary function/variable/file names. It is certainly soluble, but much more difficult than the example put forward in the paper.
I stand by the assertion that munging would make life harder for the cracker.
The method described depends on regular expressions in general, and on recognizing particualr functions to be compiled in particular. You could do a bit to foil this sort of scheme with the judicious use of sed-- eliminate comments, rename all functions, variables, and macros, salt what's left with whitespace, and rename all files and change your makefiles accordingly. Then compile and rename your executables. It should be very easy to automate this in several different ways-- perl, shell scripts, etc.
This would make it very difficult to produce a trojan that could replace a specific function in a specific program *without* affecting other programs to be compiled.
It is still possible to insert a trojan that will be added to *every* binary compiled, but checking for this is trivial-- the expected machine code for, e.g., hello world can be calculated by hand and compared to the output of your compiler.
Code munging is only a partial protection, probably less effective than bootstrapping, but it would at least give the crackers some headaches.
Slashdot Mirror
...you just need to be patient. This license does appear to address the major concerns that were raised with regard to version 1.0, but there are still smaller issues. Off the top of my head:
1) Cumbersome notification requirements. It has been pointed out that the notification requirement is an obstacle to rapid development-- the model of: "grab a bunch of code, combine it in nifty new ways, and hang it out on the net" becomes: "grab a bunch of code, combine it in nifty ways, check all licenses involved, fill out all necessary virtual paperwork, write all legally required documentation, and hang it out on the net." Much less appealing, but probably necessary for Large Corporate Entities.
2) Non-reciprocal notification requirements. You are required to notify Apple of your modifications, but Apple is not required to share them in turn with others. This violates the spirit, if not the letter of the DFSG/OSD
3) Disclosure required for *deployment*. While I can understand Apple's position here, I think that there are many instances in which a company might internally deploy modified code covered by GPL/XFree/other only so long as the license does not require them to disclose their modifications to any external party. Code covered by GPL/BSD/other licenses fits this requirement, while code covered by the APSL does not. While some might percieve this as making the APSL more open, others will percieve it as making the APSL less free. Both views have merit.
4) The new license has not been accompanied by any indication that Apple might be willing to shift code that they have not substantially altered back to its original BSD license, or in any other way acknowledge the contributors to the BSD project who did the bulk of the work behind the "Darwin" product. There is, by design, no legal obligation to do this, of course, but I think there is a strong moral obligation that has not been addressed.
There are other issues as well, and I encourage you to find them and bring them to light as you consider or debate the points enumerated above.
The article is more of a report on the drug culture in the UK than a report on drug culture in IT. My limited experience says that Brits tend to embrace recreational speed and pharmeceuticals, while Americans are more puritan, often inisisting on "natural" drugs, or cleaving to the insistent "NO." Drugs seem to be a bigger part of youth culture in the UK as well, but this impression of mine may be driven more by media than reality.
This was one of the central notions behind the Max Headroom series-- real time ratings. The blipvert (high-speed advert) seems to have happened already, too-- does anyone else remember how strange it was to watch those first 15-second spots?
Go Network 23!
Well, I didn't think he was retiring. A couple of things bother me in this most recent ESR piece.
1) The accusation of "Bomb Throwing" levelled against Bruce Perens, RMS, et. al. The points that these people raised were carefully considered and valid. ESR's rebuttals have been largely ad-hominim, and I think he owes these people an apology, rather than the announcement of a planned vacation with his preferred firearm.
2) The dismissal of Slashdot as a forum for "kiddies". Sure, it's a public forum, and it has the disadvantages of such (though moderation may change this). The fact of the matter is that there is a great deal of good thinking to be found in the comments here. Dismissing Slashdot is disingenuous-- if Slashdot just a bunch of kiddies, then why does ESR feel compelled to mention it at all?
Slashdot is widely recognized in the mainstream press as the premier public forum for debate on issues surrounding open source and free software. I think OSI can only be held accountable for their actions by the community that they wish to represent, and they dismiss the prefered forum of that community at their peril.
Yes, ESR deserves our support, and our thanks. He also deserves to be held accountable by those who he is trying to serve.
For N tapes, if you have N tape-writing devices at each end, then writing/reading time will only add a few hours to the drive time, and won't have any more effect than a snowstorm in the rockies or lousy traffic in Chicago.
How about cost per MB/sec? I think a bunch of CD-R on a spindle might be the best bet there.
The article states that Jobs confirmed "discussions" with 3com about buying the Palm division. It also said that there was no comment about licensing the palm technology and issuing an apple-branded Palm, like the IBM Workpad.
These rumors are a little too sparse for me, and the two different possibilies outlined would have very different implications.
A sale would be a little unlike Apple-- they've historicly had an acute case of the old NIH syndrome, though this is changing.
A straight licensing deal would be neat, though-- the masses would really dig an iPalm in 5 fruity flavours.
I've noticed the changes that Network Solutions have been moving into place, and I can't say I mind terribly-- I do all of my Domain Name registration via email. If you want to bring attention to a really deceptive practice, have a look at www.internic.com, where the unsuspecting can enjoy a 200% markup for domain name registration!
But I think it is a problem. You are required to notify Apple of your Modifications, but they are not required to make those modifications available to anyone else. The license should require Apple to keep a publicly accessible database of all Modifications (not just those that are folded into later releases). Furthermore, as the license stands, you must notify apple before sharing any Modification with anyone-- otherwise, said sharing will be in violation of the notification clause. There is no "reasonable time" language in the license-- the words "within one week," e.g., could go a long way.
For the APSL to gain more respect, it needs to read more like a contract between Apple and the Free Software community, where both parties have rights and obligations, and less like a set of conditions imposed by Apple on its would-be developers.
>1) You can get, use, modify, and compete with
>Apple using their own (and others) source, with
>some restrictions.
But it would be foolish to do so, since Apple has the right to make modifications without distributing them under APSL, whereas You do not, and Apple is guaranteed to see every proposed modification, whereas You are not.
>2) Apple now has to provide some additional value >added to make money.
Maybe not-- see above. But it is already apparent that Apple will be making money by keeping the source to the upper layers of MacOS X proprietary. If the past is any indication, then the efforts of the Free Software community will go toward cloning the upper layers before any significant contribution is made to the "Darwin" codebase. If that happens, then Apple will face a very tough choice:
some of their options will be:
1. Use patent litigation to slow the cloning effort, thereby earning ill-will in the developer community.
2. Realease the upper layers under an open source license, just as Troll tech changed the license on QT when the Harmony project threatened to make them irrelevant. Profits then have to come from hardware and services.
3. Play Microsoft with their APIs, changing things frequently and leaving large portions undocumented, thereby earning the wrath of third-party software vendors.
4. Release APIs and documentation only under NDA, thereby alienating the computer book publishers, and inconveniencing the small third party developer.
There are many other options, I'm sure, but those are the ones that jumped off the top of my head.
>1) You can get, use, modify, and compete with >Apple using their own (and others) source, with >some restrictions. But it would be foolish to do so, since Apple has the right to make modifications without distributing them under APSL, whereas You do not, and Apple is guaranteed to see every proposed modification, whereas You are not. >2) Apple now has to provide some additional value >added to make money. Maybe not-- see above. But it is already apparent that Apple will be making money by keeping the source to the upper layers of MacOS X proprietary. If the past is any indication, then the efforts of the Free Software community will go toward cloning the upper layers before any significant contribution is made to the "Darwin" codebase. If that happens, then Apple will face a very tough choice: some of their options will be: 1. Use patent litigation to slow the cloning effort, thereby earning ill-will in the developer community. 2. Realease the upper layers under an open source license, just as Troll tech changed the license on QT when the Harmony project threatened to make them irrelevant. Profits then have to come from hardware and services. 3. Play Microsoft with their APIs, changing things frequently and leaving large portions undocumented, thereby earning the wrath of third-party software vendors. 4. Release APIs and documentation only under NDA, thereby alienating the computer book publishers, and inconveniencing the small third party developer. There are many other options, I'm sure, but those are the ones that jumped off the top of my head.
Is it just me, or does the term "beta" seem vaguely inappropriate for open source projects?
:).
"Feature freeze" and "stable snapshot" carry more meaning: "beta" is a _marketing_ term, used, I think, to make the public think that an overdue product is close to release. How long has WinNT 5 been in "beta" now? About as long as I've been reading "reviews" of this OS, I'll wager.
I don't feel any compelling need to come up with new terms to replace "alpha" and "beta"-- the phrases above work well enough for me-- but it's something to think about. Maybe Perens and Raymond could come up with competing terms. That would be fun
I work for a record company, and I have had a long discussion with Escient. They are unwilling to change the terms of the license. The compromise you suggest is not possible unless Escient is willing to change. They are not. So there is no choice but to move forward with free alternatives.
I would like to add that the folks at Escient do not appear to be music fans or record collectors. They do not seem to have any respect for the rights of the artists and labels from whose work they seek to profit. And they certainly did not consult with an attorney familiar with the music industry before attempting to execute their business plan.
Escient cannot claim ownership of data you submit if that data is already owned by someone else-- in this case, the data is owned by record companies or artists (depending on contracts).
Technically, the content is the intellectual property of the respective Record Labels or Arists (depending on contract).
This is a good thing, actually-- it can be used to weaken Escient. I work for a Record Company. We've already told Escient to either compete through quality of service rather than restrictive licensing, or remove our intellectual property from their database.
I work for a record company. I've written to Escient and told them to remove all of our intellectual property from their database until they are prepared to compete based on the quality of their service rather than restrictive licensing techniques.
I've also sent copies of my correspondence to other independent record labels, suggesting a similar course of action. The 800 pound gorilla in this game is RIAA-- if they lean on Escient, then Escient will crack. But we all hate RIAA, right??
Intellectual property can be used for good as well as for evil, kids. Think about it.
Jesus. What the hell are we going to do when slashdot gets its first 1000-comment article?
It isn't stated explicitly, but it looks to me as though the California class action suit was filed after Microsoft/Dell/Compaq/etc. failed to provide refunds on the 15th.
This would make for a better story, but is there any basis in fact?
"Microsoft's Refusal to Provide Refunds Backfires" sure is a nice headline...
That raises a red flag for me-- when did Intel make the IA64 instruction set available to other processor designers?
A 486 running apache can saturate a T1. You only need bogomips if you're serving a lot of dynamic stuff. Like, if you're slashdot, for example.
:).
I wouldn't overclock a server, not even with one of those rock-solid 450a jobs. Overclocking is for gaming (and that's what I use my celeron for
There are widely differing assumptions here about what makes a "Graphics Workstation." Me, I think it would be something that an architect or engineer can use to do CAD type stuff, and then manipulate a 3D model of the design in a window.
It would have helped quite a lot if the original poster had mentioned what sort of work was being planned, and what sort of software was to be used.
For work that needs to be done today:
A used SGI indy runs less than $2k these, irix 6.5 and a 1-year service contract will run you around $350. Not a speed demon, but the graphics hardware is dandy, and the applications are readily available.
$1000 and Linux just aren't reasonable yet for building a "Graphics Workstation". Give it a year or two.
Me, I thought it was fewer cameras, more computers. Nice to see a good analog solution once in a while.
Did you know that Microsoft has a trademark on the word "internet" as well? They didn't enforce it, so it's not valid anymore. Patents are different, of course, but prior art should take care of this one in short order.
On another note, don't pay too much attention to Reardon. He's one of those kids who got high SAT scores and now believes himself to be smarter than everyone else based on the value of his stock options. Most of his coworkers think he's an asshole, and he's probably proud of it. Last time I was at his house, he and his 'friends' were trying to impress each other with their knowledge of wine, measured by the amount one could afford to spend on a bottle. Pathetic.
A backup device that can handle the average drive size these days is pretty pricey.
I say buy a PC for 1-2 grand and a DDS-3 tape drive for another grand. The tape drive will serve your needs for five years and more, the rest of the system will seem clunky after two.
A CD-RW might work, but I'd go with the tape-- the media can be written a larger number of times, and 600MB for the CD just doesn't compare to the 12 GB on tape.
There are too many students out there who neglect backup entirely.
Oh, and buy a good monitor. Lesser monitors degrade sharply after 2-3 years.
The method is only a hindrance, not a panacea, even if the method is only applied to source code. I think I tried to stress that.
/dev/null, sending a packet to the loopback, etc., that could not be optimised out. This unseemly bloat would monkeywrench trojans expecting a nice predictable chunk of machine code. Going through many generations of this before generating a binary with no "extras" would reduce a trojan's chances of survival.
Machine-code trojans would tend to be platform dependant, and would be much harder to implement, especially for a portable, cross-compiling compiler such as gcc.
I assume that by a "machine code implementation" yo mean a trojan that would wait until code had been compiled, and then examine the resultant bits for a particular pattern to replace.
Small changes to the source code could result in such large changes to the object code that this method would only be practical for infecting code that is not expected to change. The exuberant code munger could randomly salt the code with valid but useless statements-- printing to
The problem of recognizing a particular function in a particular program in machine code for many different platforms is on a par with recognizing a particular function in a particular program in source code with arbitrary function/variable/file names. It is certainly soluble, but much more difficult than the example put forward in the paper.
I stand by the assertion that munging would make life harder for the cracker.
The method described depends on regular expressions in general, and on recognizing particualr functions to be compiled in particular. You could do a bit to foil this sort of scheme with the judicious use of sed-- eliminate comments, rename all functions, variables, and macros, salt what's left with whitespace, and rename all files and change your makefiles accordingly. Then compile and rename your executables. It should be very easy to automate this in several different ways-- perl, shell scripts, etc.
This would make it very difficult to produce a trojan that could replace a specific function in a specific program *without* affecting other programs to be compiled.
It is still possible to insert a trojan that will be added to *every* binary compiled, but checking for this is trivial-- the expected machine code for, e.g., hello world can be calculated by hand and compared to the output of your compiler.
Code munging is only a partial protection, probably less effective than bootstrapping, but it would at least give the crackers some headaches.