Okay, the problem here is you didn't get the contract, but some security-clueless developers (let's call them SCD, Ltd.) got it. Let's assume that their solution works, and that the security holes can be fixed. Is the answer to drop the entire solution? SCD probably got the contract because they were able to demonstrate that they can meet the functional requirements, but security somehow got left out of the picture. This is not necessarily reason for the client to break it off with SCD and go with you. Just because you have a clue about security doesn't mean that you are the best developer for their application.
However, you may be able to form a partnership with SCD as a security consultant. Find a way to communicate to SCD that their solution is full of security holes and that you know how to fix them. SCD is likely to be discreet about the whole thing because it looks very bad for them! If they are honest, they will want to contact the client themselves to explain the security issues. They will also want to be able to tell the client, in the same breath, that they already have a solution in the wings provided by an independent security consultant (i.e. hopefully you). So this way there is still some piece of the action for you.
If SCD instead decide to get a clue of their own and fix the problems themselves, at least the security are made known to the client and something is done about them (hopefully).
In the remaining possible scenario, SCD just keep quiet about the security holes. You have done the best you can; the entire moral obligation rests with SCD once they know about the holes. You should forget about the whole thing and not enter into any further communication with anyone at SCD---why get mixed up in a situation in which at least one of the parties is completely unethical? SCD, being capable of anything, is dangerous to any organization who comes in contact with them.
You ask them to reproduce the problem with some known stock version of the codebase, to rule out the bug being caused by the modifications. Or otherwise demonstrate that it's a coding problem that exists in the original codebase. After all, when the fix is found, it will be applied to the development stream which doesn't have the customer's modifications.
Users who are competent enough to extend the code
are usually competent enough to also find bugs and send in reports with patches.
I think that to obtain support for a patched version, the users first have to work with the developer to have those patches incorporated into the software. The patched program then becomes ``official'' from the perspective of the vendor, and is supported as such.
Of course, a support agreement can be worked out regardless. The customer should be able to request assistance with a patched program; but the customer then has to share the patch with the developers, and compensate them for the time spent understanding the patch. This would only make sense when there is a problem with the patch itself; the customer tries to extend the program but dig themselves into a hole, so to speak.
The problem with these is that if you make them too simple, nobody will want to use them. If you make them too complex, they won't be widely implemented. And there isn't really a satisfactory middle ground either, it's more of a fine line. One missing little key feature can make an interface unsatisfactory, if not outright useless.
There exist standard such abstractions for C programming, under the umbrella of POSIX and The Single UNIX Specification. These abstractions are not as widely implemented as, say, the standard C library! We are still not at the point where you can write POSIX code and expect it to work everywhere.
Any interface that is going to be acceptable to a wide range of C++ vendors is going to have to be dumbed down and braindamaged beyond repair.
For example, a standard C++ threading library probably won't be able to have useful POSIX behaviors in it because Microsoft would leave them unimplemented in future generations of Visual C++. So you will end up with some weak interface that caters to the lowest common denominator, and which programmers will soon learn to avoid.
On the other end of the scale, you could end up with a situation in which the powerful, useful systems extensions are are an optional part of the C++ standard, and one that is only implemented properly by people who have a clue, over top of high quality operating systems. And so only developers targetting only these systems will be able to use the interface. Still, it's better than an interface that all programmers avoid.
I suspect that for some time to come, the real tool for portability will be something that is already there: good old preprocessing directives that allow you to roll several similar programs into one.:)
The ultimate solution to the portability problem is to actually have one operating system running everywhere. Portability is achieved with greater ease at the lowest levels, and doing it there provides the greatest leverage for everything else. Example: it's easier to have Linux running on some portable device and recompile existing programs for it, than to port applications to some exotic embedded operating system on the same device! This is particularly true because such devices are increasingly built around standard, advanced architectures that fit the model expected by an advanced operating system. The idea of using the same advanced OS for small and large computing is pretty much here now.
Windows CE teaches us that it's not even enough to merely have a reimplementation of the same system call interface. Anyone who has had to port Win32 sofware to Windows CE will understand! If you port the actual kernel, that's a big difference, because you port every nuance of the behavior behind that interface. It's not possible to specify every such nuance in a document and have everyone implement it exactly, and it's hard to be certain to what extent an application depends on these nuances!
Remember, when Thompson and Ritchie presented C and UNIX to the world circa 1974, it was the portability of the operating system that impressed the world. The portability of C programs rested on the retargettability of the C compiler and porting of the OS, not on writing in a standard language using standard interfaces! Porting C programs to different operating systems came later (and is not really all here yet, nearly thirty years later).
This is what language standardization is really about: a bunch of conflicting big interests bent on preserving their piece of the pie. Nobody wants to come out and admit that there needs to be one *implementation* of one interface running everywhere, because that would mean giving up their proprietary operating systems and interfaces, whose incompatibilities they secretly cherish. Since nonportability of software is caused by secrecy driven by ego and greed, universal portability will only be achieved when we recognize the root causes and do something about them. Right now, with our programming language standardization efforts, we are accepting these causes as immutable givens, and working *around* them to create solutions that are incomplete and unsatisfactory when translated to action in the software development trenches.
The filesystem layer could detect when an MP3 file is being written by looking at the header. If the quality is too great, then it would interfere with the writing process; e.g. cause the WriteFile() system call to fail. Or it could even put a block of zeros into the file.
Taken a step further, the operating system could require special authentication from the software before it allows a file with an MP3 header to be written at all. The authentication could be produced by requesting the app to produce a hash of a region of its machine code, just like what AOL did with their IM client.
Of course, what would happen is that the music sharing community would come up with a trivial way to disguise the MP3 file when it is stored on Windows. MP3 files will simply have to be ``pickled'' for storage on a Windows system. Decoders would read the pickled format as handily as raw MP3 and life goes on.
Because of the easy way to get around the scheme, I doubt it will be implemented. I suspect that this is may be a case of product management leaking their wishful thinking before checking the feasibility with development.:)
Keeping with the topic, it most certainly has avoided the obsolescence issues raised in this article. Even in the absence of the mechanism of temporary keys, users are left high and dry when proprietary software is abandoned by its vendor, or taken in a direction that the users do not want to follow.
The choices for people who want to avoid proprietary software are far from perfect, but are getting better all the time. The long term is looking quite good.
More and more, users that are screwed by the software industry are doing so due to their own ignorance of the choices they have before them. Therefore it is difficult to sympathize with their problems.
CVS is quite suitable for tiny projects. RCS isn't suitable for anything, compared to CVS.
The comments about the disk space requirements of CVS versus RCS are strange and irrelevant in the days of 40GB drives being affordable to consumers.
I use CVS even for things that consist of a small handful of text files and are developed only by me. Even with one developer and a small project, it's useful, for instance, to be able to go back to a release and easily make a bugfix branch.
He's obviously just bitter that his team couldn't develop system software that doesn't crash everytime you sneeze, and whose basic architecture could be preserved as hardware improves.
Consider that UNIX started on machines less powerful than the original Mac. The Mac OS came and went, UNIX is still here.
Wouldn't TeX demonstrate prior art, and hence the invalidity of this pathetic patent? What does the patent specify that Metafont did not do a decade before it? It still blows away most systems for representing and rendering fonts.
You don't need to fork the whole kernel, just make it support ``big iron'' as a configurable feature.
If the same code cannot handle both kinds of machines, then you eventually need both pieces of code in the same codebase, not a fork.
Forking is essential for experimentation. That's why we have tools like CVS which encourage forking for making stable releases and for experimenting with new features.
The SMP support already allows multiple processors to execute much of the kernel code already, except within locks. In principle, any code that is not in a lock and runs on SMP can be made preemptible on a single processor. So this is not a hugely revolutionary step, but rather evolutionary.
I'm glad that someone is taking the effort to actually do this.
The mistake made in the article is that of equating the sysadmin area with all of computing.
Sure, kids from highschool make excellent Windows reboot jockeys. That is more of an indicator of what sysadminning has been reduced to, not an indicator that a university education is not useful.
The fragile networks of PC's have created a large demand for people to act as computer babysitters. The natural result is that bright children can get these jobs.
A sysadmin is basically just a computer user who knows slightly more than the average computer user.
Could these same kids get into a software engineering job? Advertisements for such jobs ask for bachelor degrees, with a hint that a master's degree would be an asset. And there are good reasons for that; you actually have to know something about computing beyond reading the user's manual or online help, plus a couple of books.
These kids are kidding themselves if they think that they are staying ahead of change by working as reboot jockeys. Knowing the user interface layout of the latest network administration tool is not really a form of keeping up with change; it's just a form of accepting software created by those who *make* the change happen.
Natural languages have no bearing on programming languages. The only relationship between C and English is that C uses English keywords. These could be replaced by abstract symbols, which would erase any discernible relationship to English or any other language.
There is a huge gap between the complexity of the structure of programming languages and of natural languages.
Before panicing, be sure that these ports really are open to the world.
Use netstat to see what network they are bound to.
A foreign address of *:* is a bad thing.
A foreign address of 127.0.0.1:* indicates that
the connection is restricted to localhost only. An attacker would have to spoof packets originating from 127.0.0.1 in order to connect to the port.
An article is a copyrighted work attributed to the writer. Inserting endorsements for products, without the author's permission, constitutes making a derived work which distorts the original work. It is not ``fair use'' by any stretch of the imagination. Note that there aren't even any clearly visible mitigating disclaimers that state that the article was modified by the insertion of hyperlinks.
Note that I do not browse Usenet through Deja News, so seeing the links is not what offends me. I do post to Usenet, and I'm appaled by the idea of my text being linked to products and services without my explicit endorsement and permission.
If they are going to do that, I expect to have control over what products I'm connected with, and I expect to get a chunk of the advertizing revenue.
Workers already have to observe the rules of the workplace regarding dress, attendance, behavior, confidentiality and so on. Why worry about their freedoms regarding free software, given that they don't have a whole bunch of other more fundamental freedoms? Moreover, the workers have *chosen* to trade their freedoms for money, and they can also choose to get them back by quitting.
Thus I think that we should not worry whether internal distribution within a corporation counts as distribution for the purposes of interpreting the GPL.
It is only the corporation that suffers if they don't provide their workers with all the materials they need in order to be fully effective! What does it matter to the worker that he or she doesn't have the source code to some proprietary enhancement his or her company made to some free software? Having access to the code would not mean that the worker could give that code to outsiders; it would only mean that the worker could perhaps do his or her job more effectively, in order to make more money for the corporation and make it more competitive. So if the powers that be do not see that, screw them!
If you cannot see the source code, then all the formal design or testing amounts to nothing. At best, you have someone's guarantee that the system is secure.
Also, empirical tests are insufficiently strong to prove anything. You can test the binaries ad nauseum and not find every security flaw.
So basically, this is just another bullshit attack on free software.
The first Apple was a direct ripoff of the Altair. There was nothing innovative about the Apple.
And I suppose the computer you wrote that post on uses toggle switches for input, and stdout is a row of LED's for displaying binary numbers...
Are you trying to insinuate that what makes the Apple II an invention, but the Altair not an invention, is that Wozniak invented the computer keyboard and video display?
Slashdot Mirror
Okay, the problem here is you didn't get the contract, but some security-clueless developers (let's call them SCD, Ltd.) got it. Let's assume that their solution works, and that the security holes can be fixed. Is the answer to drop the entire solution? SCD probably got the contract because they were able to demonstrate that they can meet the functional requirements, but security somehow got left out of the picture. This is not necessarily reason for the client to break it off with SCD and go with you. Just because you have a clue about security doesn't mean that you are the best developer for their application.
However, you may be able to form a partnership with SCD as a security consultant. Find a way to communicate to SCD that their solution is full of security holes and that you know how to fix them. SCD is likely to be discreet about the whole thing because it looks very bad for them! If they are honest, they will want to contact the client themselves to explain the security issues. They will also want to be able to tell the client, in the same breath, that they already have a solution in the wings provided by an independent security consultant (i.e. hopefully you). So this way there is still some piece of the action for you.
If SCD instead decide to get a clue of their own and fix the problems themselves, at least the security are made known to the client and something is done about them (hopefully).
In the remaining possible scenario, SCD just keep quiet about the security holes. You have done the best you can; the entire moral obligation rests with SCD once they know about the holes. You should forget about the whole thing and not enter into any further communication with anyone at SCD---why get mixed up in a situation in which at least one of the parties is completely unethical? SCD, being capable of anything, is dangerous to any organization who comes in contact with them.
See, for instance, http://www.alpcom.it/hamradio/marconi.html.
You ask them to reproduce the problem with some known stock version of the codebase, to rule out the bug being caused by the modifications. Or otherwise demonstrate that it's a coding problem that exists in the original codebase. After all, when the fix is found, it will be applied to the development stream which doesn't have the customer's modifications.
Users who are competent enough to extend the code
are usually competent enough to also find bugs and send in reports with patches.
I think that to obtain support for a patched version, the users first have to work with the developer to have those patches incorporated into the software. The patched program then becomes ``official'' from the perspective of the vendor, and is supported as such.
Of course, a support agreement can be worked out regardless. The customer should be able to request assistance with a patched program; but the customer then has to share the patch with the developers, and compensate them for the time spent understanding the patch. This would only make sense when there is a problem with the patch itself; the customer tries to extend the program but dig themselves into a hole, so to speak.
The problem with these is that if you make them too simple, nobody will want to use them. If you make them too complex, they won't be widely implemented. And there isn't really a satisfactory middle ground either, it's more of a fine line. One missing little key feature can make an interface unsatisfactory, if not outright useless.
:)
There exist standard such abstractions for C programming, under the umbrella of POSIX and The Single UNIX Specification. These abstractions are not as widely implemented as, say, the standard C library! We are still not at the point where you can write POSIX code and expect it to work everywhere.
Any interface that is going to be acceptable to a wide range of C++ vendors is going to have to be dumbed down and braindamaged beyond repair.
For example, a standard C++ threading library probably won't be able to have useful POSIX behaviors in it because Microsoft would leave them unimplemented in future generations of Visual C++. So you will end up with some weak interface that caters to the lowest common denominator, and which programmers will soon learn to avoid.
On the other end of the scale, you could end up with a situation in which the powerful, useful systems extensions are are an optional part of the C++ standard, and one that is only implemented properly by people who have a clue, over top of high quality operating systems. And so only developers targetting only these systems will be able to use the interface. Still, it's better than an interface that all programmers avoid.
I suspect that for some time to come, the real tool for portability will be something that is already there: good old preprocessing directives that allow you to roll several similar programs into one.
The ultimate solution to the portability problem is to actually have one operating system running everywhere. Portability is achieved with greater ease at the lowest levels, and doing it there provides the greatest leverage for everything else. Example: it's easier to have Linux running on some portable device and recompile existing programs for it, than to port applications to some exotic embedded operating system on the same device! This is particularly true because such devices are increasingly built around standard, advanced architectures that fit the model expected by an advanced operating system. The idea of using the same advanced OS for small and large computing is pretty much here now.
Windows CE teaches us that it's not even enough to merely have a reimplementation of the same system call interface. Anyone who has had to port Win32 sofware to Windows CE will understand! If you port the actual kernel, that's a big difference, because you port every nuance of the behavior behind that interface. It's not possible to specify every such nuance in a document and have everyone implement it exactly, and it's hard to be certain to what extent an application depends on these nuances!
Remember, when Thompson and Ritchie presented C and UNIX to the world circa 1974, it was the portability of the operating system that impressed the world. The portability of C programs rested on the retargettability of the C compiler and porting of the OS, not on writing in a standard language using standard interfaces! Porting C programs to different operating systems came later (and is not really all here yet, nearly thirty years later).
This is what language standardization is really about: a bunch of conflicting big interests bent on preserving their piece of the pie. Nobody wants to come out and admit that there needs to be one *implementation* of one interface running everywhere, because that would mean giving up their proprietary operating systems and interfaces, whose incompatibilities they secretly cherish. Since nonportability of software is caused by secrecy driven by ego and greed, universal portability will only be achieved when we recognize the root causes and do something about them. Right now, with our programming language standardization efforts, we are accepting these causes as immutable givens, and working *around* them to create solutions that are incomplete and unsatisfactory when translated to action in the software development trenches.
The filesystem layer could detect when an MP3 file is being written by looking at the header. If the quality is too great, then it would interfere with the writing process; e.g. cause the WriteFile() system call to fail. Or it could even put a block of zeros into the file.
:)
Taken a step further, the operating system could require special authentication from the software before it allows a file with an MP3 header to be written at all. The authentication could be produced by requesting the app to produce a hash of a region of its machine code, just like what AOL did with their IM client.
Of course, what would happen is that the music sharing community would come up with a trivial way to disguise the MP3 file when it is stored on Windows. MP3 files will simply have to be ``pickled'' for storage on a Windows system. Decoders would read the pickled format as handily as raw MP3 and life goes on.
Because of the easy way to get around the scheme, I doubt it will be implemented. I suspect that this is may be a case of product management leaking their wishful thinking before checking the feasibility with development.
Yeah, we see how well that has worked so far.
Keeping with the topic, it most certainly has avoided the obsolescence issues raised in this article. Even in the absence of the mechanism of temporary keys, users are left high and dry when proprietary software is abandoned by its vendor, or taken in a direction that the users do not want to follow.
The choices for people who want to avoid proprietary software are far from perfect, but are getting better all the time. The long term is looking quite good.
More and more, users that are screwed by the software industry are doing so due to their own ignorance of the choices they have before them. Therefore it is difficult to sympathize with their problems.
Demand freely redistributable software with
source code.
If you dedicate yourself to a proprietary, single-vendor development tool, you have this coming to you! And it serves you right.
The thing to do is to create an free clone of HyperCard instead of whining to Apple Computer Inc to support it on this platform or that.
CVS is quite suitable for tiny projects. RCS isn't suitable for anything, compared to CVS.
The comments about the disk space requirements of CVS versus RCS are strange and irrelevant in the days of 40GB drives being affordable to consumers.
I use CVS even for things that consist of a small handful of text files and are developed only by me. Even with one developer and a small project, it's useful, for instance, to be able to go back to a release and easily make a bugfix branch.
I see tons of funny characters in places of punctuation marks such as quotes and apostrophes, which detracts from the reading.
Is this some proprietary Microsoft encoding that's not available in Netscape on Linux or what? I tried switching various encodings to no avail.
Tacit admission: we DON'T build a better product than Linux.
LOL
He's obviously just bitter that his team couldn't develop system software that doesn't crash everytime you sneeze, and whose basic architecture could be preserved as hardware improves.
Consider that UNIX started on machines less powerful than the original Mac. The Mac OS came and went, UNIX is still here.
``Does your search engine move as fast as your business? Click here to download a FREE trial version. AltaVista search engine 3.0''.
How ironic.
I wonder, can still use grep or do I have to pay some asshole who lives off the backs of others?
That quote should be attributed to Donald Knuth, not Abrash.
*CRY*
Wouldn't TeX demonstrate prior art, and hence the invalidity of this pathetic patent? What does the patent specify that Metafont did not do a decade before it? It still blows away most systems for representing and rendering fonts.
You don't need to fork the whole kernel, just make it support ``big iron'' as a configurable feature.
If the same code cannot handle both kinds of machines, then you eventually need both pieces of code in the same codebase, not a fork.
Forking is essential for experimentation. That's why we have tools like CVS which encourage forking for making stable releases and for experimenting with new features.
The SMP support already allows multiple processors to execute much of the kernel code already, except within locks. In principle, any code that is not in a lock and runs on SMP can be made preemptible on a single processor. So this is not a hugely revolutionary step, but rather evolutionary.
I'm glad that someone is taking the effort to actually do this.
The mistake made in the article is that of equating the sysadmin area with all of computing.
Sure, kids from highschool make excellent Windows reboot jockeys. That is more of an indicator of what sysadminning has been reduced to, not an indicator that a university education is not useful.
The fragile networks of PC's have created a large demand for people to act as computer babysitters. The natural result is that bright children can get these jobs.
A sysadmin is basically just a computer user who knows slightly more than the average computer user.
Could these same kids get into a software engineering job? Advertisements for such jobs ask for bachelor degrees, with a hint that a master's degree would be an asset. And there are good reasons for that; you actually have to know something about computing beyond reading the user's manual or online help, plus a couple of books.
These kids are kidding themselves if they think that they are staying ahead of change by working as reboot jockeys. Knowing the user interface layout of the latest network administration tool is not really a form of keeping up with change; it's just a form of accepting software created by those who *make* the change happen.
Natural languages have no bearing on programming languages. The only relationship between C and English is that C uses English keywords. These could be replaced by abstract symbols, which would erase any discernible relationship to English or any other language.
There is a huge gap between the complexity of the structure of programming languages and of natural languages.
Before panicing, be sure that these ports really are open to the world.
Use netstat to see what network they are bound to.
A foreign address of *:* is a bad thing.
A foreign address of 127.0.0.1:* indicates that
the connection is restricted to localhost only. An attacker would have to spoof packets originating from 127.0.0.1 in order to connect to the port.
Free, that is, until someone translates it to binary code, sticks a restrictive license on that binary code, and locks away the source code.
Oops! Where is your public domain now?
Violating an unwritten code, my ass!
An article is a copyrighted work attributed to the writer. Inserting endorsements for products, without the author's permission, constitutes making a derived work which distorts the original work. It is not ``fair use'' by any stretch of the imagination. Note that there aren't even any clearly visible mitigating disclaimers that state that the article was modified by the insertion of hyperlinks.
Note that I do not browse Usenet through Deja News, so seeing the links is not what offends me.
I do post to Usenet, and I'm appaled by the idea of my text being linked to products and services without my explicit endorsement and permission.
If they are going to do that, I expect to have control over what products I'm connected with, and I expect to get a chunk of the advertizing revenue.
Workers already have to observe the rules of the workplace regarding dress, attendance, behavior, confidentiality and so on. Why worry about their freedoms regarding free software, given that they don't have a whole bunch of other more fundamental freedoms? Moreover, the workers have *chosen* to trade their freedoms for money,
and they can also choose to get them back by quitting.
Thus I think that we should not worry whether internal distribution within a corporation counts as distribution for the purposes of interpreting the GPL.
It is only the corporation that suffers if they don't provide their workers with all the materials they need in order to be fully effective! What does it matter to the worker that he or she doesn't have the source code to some proprietary enhancement his or her company made to some free software? Having access to the code would not mean that the worker could give that code to outsiders; it would only mean that the worker could perhaps do his or her job more effectively, in order to make more money for the corporation and make it more competitive. So if the powers that be do not see that, screw them!
If you cannot see the source code, then all the formal design or testing amounts to nothing. At best, you have someone's guarantee that the system is secure.
Also, empirical tests are insufficiently strong to prove anything. You can test the binaries ad nauseum and not find every security flaw.
So basically, this is just another bullshit attack on free software.
And I suppose the computer you wrote that post on uses toggle switches for input, and stdout is a row of LED's for displaying binary numbers...
Are you trying to insinuate that what makes the Apple II an invention, but the Altair not an invention, is that Wozniak invented the computer keyboard and video display?