Re: What's the story with the "end of XP"?

Chris Hills wrote:
In article <467631bd$0$1455$8404b019@xxxxxxxxxxxxxxx>, David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes
Chris Hills wrote:
In article <4672A842.6F818F44@xxxxxxxxx>, CBFalconer <cbfalconer@xxxxxxxxx> writes
The Real Andy wrote:
Steve wrote:

... snip ...

Net security is best looked at pro-actively, not re-actively.
Block everything coming in using a proper firewall - trying to
get the latest windows updates to patch known holes is a
never-ending battle.

And this differs from linux and Mac exactly how?

To start with, the source is available for Linux. MAC ??
The availability of the source is completely irrelevant.


The availability of the source is only irrelevant to security *if* the people behind the source are so good at their job, so dedicated to the security of the product regardless of functionality, ease-of-use, time, cost, marketing, sales, public image, etc., and so good at secure programming, that no one else would be able to do a better job even with source code access. Thus you could reasonably claim that Opera would not be more secure if the source were available, but the same can't be said for certain other well-known closed source browsers.

Of course, no one (I hope!) thinks that making the source available automatically makes a program secure - it's only one part of the process.

Much similar has been said about crypto Sw.

I have the source for PGP BUT how many people would be able to recognise any whole or flaw in it?

Interestingly I have some customers who buy in some commercial SW where they get the source code. When the found a problem they reported it. The company started to investigate the fix and sent a patch. In the mean time the customers programmers also worked on it. They too produced a patch.

The production of the patch from he end user cost them more in money ( ie paid time for the engineers) than the years support charge. Also whilst they are fixing the bug they were not working on the project they were supposed to be. Finally whilst the fix did fix the bug it caused other problems. The patch supplied did not.

I have never seen any time that having the code available for 3rd party tools was of use to any commercial project.


You are randomly mixing at least two totally different situations here (and in your other recent post in this thread).

Let's look first at crypto software, since you brought it up - it falls in the same categories as browsers and desktop OS software as something that a few people make, and lots of people use with little understanding of how it works.

If you have a completely closed-source product, you must rely entirely on the supplier to find and fix flaws. The security of the product depends on the supplier, and you have no way of checking or controlling it. You simply have to assume that the supplier is honest (normally a fair assumption - but an assumption none the less), diligent (developers normally aim to do the best job they can, but management may not prioritise appropriately), and competent.

With a "source available" product, where you can pay extra for a copy of the source code but you can't release the code to others, you have a bit more power. For most users, the source code is of little use as they are not programmers (or at least, not experts in that particular type of program). But it *does* give you an escape clause - if someone discovers a flaw, and the supplier does not fix it, then you can fix it yourself (or hire someone to do so). It costs time and money, but it's possible - that's certainly important to big customers.

With an open source product, you are much safer. *I* may not understand much of the source code for GPG (an open source alternative to PGP), but I can be confident that there are plenty of people around the world who *do* understand it. If flaws are found, they will be fixed quickly - open source developers can't hide flaws in the same way closed source developers can.


When you are looking at embedded development tools, the situation is a little different - there is a much lower ratio of users to developers, and the users themselves are programmers. Here the source code can be very useful - I've often found source code useful to understand what is going on, or while debugging difficult problems. I'm not too bothered about having source code for a compiler or debugger (though I have modified and otherwise used code from debugger software), but I like to have the source for any libraries or other target code I am running. If I make the software for an embedded system, then I am responsible for the code on it - and I want to have that code available. I am unlikely to read much of the source code, and even less likely to modify it, but I need to know that it is possible.

Looking at your case where the customer attempted to fix the software flaw themselves, there are a number of ways to view it. You could say that the customer made a mistake by trying to fix the compiler themselves - tools like compilers are pretty specialised, and it is hard for an outsider to jump in and make successful changes. But it's important to consider what might have happened, especially if they did *not* have access to the code. The supplier could well have claimed there was no bug, they could have decided that fixing the bug was low priority and would be done in the next version, they could have agreed to fix the bug but taken too long, they could have been bought up by a rival company and stopped all product development - there are any number of plausible scenarios where the customer would have been in big trouble. Having the source code themselves gave them an escape clause - they could always get out of the problem, albeit at a cost. It turns out that in this case, with hindsight, fixing (or trying to fix) the problem themselves cost a lot - but it was perhaps a sensible risk management decision to maximise the chances of having working software in time for delivery. Having the source code available is not a cost or a burden to the customer - it gives them more freedom and more choice.
.

Relevant Pages

  • Re: Pinball 2000 Wizard Block Kits
    ... Obviously somebody still has them and the source code ... Fix the TOTAN jewel thing. ... Games like T2 could get a wizard mode for people who want to spend ... Programmers are gone, the source code is lost, company part numbers ...
    (rec.games.pinball)
  • Re: Pinball 2000 Wizard Block Kits
    ... Fix the TOTAN jewel thing. ... Games like T2 could get a wizard mode for people who want to spend ... there's no money in releasing that source code and devel ... with the skills deciding to sit down and start a fresh devel environment ...
    (rec.games.pinball)
  • Re: Corrupted Fonts
    ... still produce products for which the full set of in-house testers, ... A fix to your problem might ... Any change to the source code, ... > change to the most major, requires a total recompile, as it does with ...
    (microsoft.public.mac.office)
  • Re: C90 IDE+compiler for Windows / educational purposes
    ... who is knowledgeable and determined to fix the problem ... If you need the source code, yes, I agree, in which case Digital Mars may ... problems in an ancient compiler from a museum, ... If one needs the source to make the implementation conform, ...
    (comp.lang.c)
  • Re: Question for developers
    ... until I get a fix from the ... Very seldom is a problem in a component a showstopper. ... it's usually very hard to properly diagnose problem without source code - ... 3rd party component is always 3rd party component, ...
    (borland.public.delphi.thirdpartytools.general)