You know, I had the exact same problem just the other day. I went to the railroad community to request help configuring my Subaru to work properly on railroad tracks, and they ranted on about how its Subaru's fault because automobiles are made for highways and not for rail lines... Great, thanks for wasting my time. Also like going to a NG and asking a question about curing an infection with leeches, then being told to use antibiotics. Why sould I have to be forced to buy a locomotive just to be able to use railroad tracks? Why can't those idiots shut up about antibiotics and just answer my leech questions? If I wanted to treat infections with antibiotics, I wouldn't have asked about leeches!
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.
I find that having the source is no help for most things. In fact I know one place that is moving off FOSS to commercial because the programmers spend more time messing about with the source than doing the job they are paid to do.
Also when I did compiler support the vast majority of compiler bugs usually turned out to be the users incorrect understanding of the language or the compiler. Several complained that if they had had the sources they could have fixed the problem.
Thus wasting their employers time and creating an incorrect non-standard compiler.
I have jet to see where having the source is an advantage for most things. (Unless you are actually writing/developing /maintaining the code. )
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
I did a lot of work using VxWorks (which is a closed source OS, but you can get a source license). On a number of occasions I used the source to debug HW problems, and also find problems in the supplied code. Could I have done this without the source? Probably yes, but it would have taken a lot more time. Would a filing an SPR save money? No, because the application was on specific HW, so to solve the issues we would have to get a support engineer at our site, or supply a working target.
So, yes, I am using the sourcecode to debug my system. For a standard application development you can do without the sources, but for embedded development I prefer to have the sourcecode available.
All your arguments previously seems to imply there is a difference between closed source and open source programmers.
I agree. But it does not need to be FOSS. Most of the commercial SW I know where having the source would be useful it is provided.
But the rest of the FOSS brigade seem to thing it is essential.
Not according to many FOSS devotees we get around here. Though strangely the commercial compiler writers I know would agree with you.
I am not convinced. I have seen cases where it was a a hindrance.
There does seem to be an implied line in most of the FOSS rants. They usually claim that commercial pay ware is buggy and thereby imply that Sw Engineers working for these companies are less capable than the FOSS community. This always amuses me especially as many of them are actually paid to write SW for some one else.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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.
What exactly do you doubt? I presume it's the final statement - that there are plenty of people around the world who understand the PGP code. I made that statement on the knowledge that there are cryptography experts around the world, employed in the private sector, employed by governments, and in the academic world. You can't call yourself an expert in cryptography without a solid familiarity with some of the most used algorithms and implementations - programs like GPG, OpenSSH and OpenSSL are known to be among the most secure solutions precisely because there are so many interested and capable people who have studied their source code.
Note that I am not simply repeating the mantra that "with many eyes, all bugs are shallow" - a concept that is only true in specific circumstances.
Again, I must ask what you think is not true. There is overwhelming statistical evidence that serious flaws in major open source software projects are fixed quickly - generally far faster than in comparable closed source projects. There is also little doubt that in a closed source project, it is far easier to hide flaws - if I find a bug in a program I have written, I can simply keep the information secret (perhaps revealing it when I have a fix ready, perhaps never revealing it). When a security researcher finds a flaw in an open source project, everyone can hear about it.
There is a difference in the programming methods - not necessarily a difference in the programmers themselves. Many programmers do both.
I don't think I've made any claims here about licensing - just about the availability of the source, along with the ability to modify and re-compile it yourself. As I say, there are differences in the requirements for embedded tools and for general purpose software. When I am doing embedded development, it is important that *I* can read and change the code running on the target. When I am looking for a trustworthy application for safely accessing the internet, I want to be sure that other experts can read and modify the code, and that I can benefit from that. In the first case, the source license can be more restrictive, while in the second case, a free (as in speech) license is essential.
That sounds like prejudice and overly wide generalisation to me.
There are certainly people who feel that the all software should be open source, and that anything else is evil. And there are people who feel that anyone can use whatever license they want, but that they personally will only use FOSS. There are others who will use FOSS where possible, and closed source when they have to. Personally, I try to pick the best software for the job at the time, taking into account many aspects of "best". Thus I am writing this using Thunderbird, running on Windows, connected to a Linux server. In my work today I have used two open source compilers and one closed source compiler. I have used an open source browser and an open source office suite, and a closed source windows IDE. I mix and match as appropriate. For most programs, being open source is a benefit IMHO, although it is not often the most important reason to chose a particular program.
Any FOSS devotee will understand that it is hard to make successful changes to a compiler or tool of similar complexity (although open source projects are often easier to work with, since they are built as collaborations in the first place). What a FOSS devotee will tell you is that it is important (to them) that making such changes is *possible*.
That goes along with an argument against giving developers fast computers, in case they spend their time playing games instead of working. Giving people more options is only a hindrance if they can't deal properly with making decisions about priorities in their work.
Again, that is blatant prejudice - you've been listening to too many fanatics. I know that some fanatics can be loud (it's the case in any argument), but you are allowed to think for yourself, and to listen to other people. I don't use open source software because it is "morally right", or because closed source software is "evil" or full of bugs. I work as a professional embedded developer, and also as an IT and network manager, and I prefer FOSS over equivalent closed source software in many cases because it helps me do a better job. I hope that my comments here will let you see a little of my reasoning.
In paticular, when a bug is discovered and a patch is issued in OSS, that particular section of code gets an extra thorough going-over by lots of people. This greatly reduces the problem of bug fixes introducing new bugs.
Well, IMO your examples are examples of foul mis-use. Once you have checked that your sources correspond to what you are using, you should simply put it away for emergencies, or possibly for reading to resolve something nebulous. Maybe mark those sources as R/O too.
Yes there is. If nothing else, opensourcers know their code will be examined and criticized, so they pay more attention. The closedsourcers don't really care.
You have absolutely no justification for that statement.It is this sort of remark from FOSS people that proves it is a "religion" and its devotees have no basis in reality
It might be your attitude to programming but the majority of programmers I know take great pride in their work, the majority being closed source.
I have seen some appalling FOSS (as well as some good stuff) likewise with closed source. As it happens some of the best code I have seen was closed source.... but then I do a lot with high reliability and safety critical projects.
In fact I would go so far as to say that the closed source people I know take far more care than the open source people as the closed source people have to get it right. The open source people don't have to bother as the rest of the community will debug it for them....
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
You are both guilty of wild generalisations here, and you are each talking about different sorts of programmers and different sorts of programs.
In the world of commonly used desktop software, the majority of closed source software is very poorly written. This can be seen again and again in both the code (sometimes closed source code is later opened), and in the effects (big, slow, and buggy programs). In most cases, the programmers are paid to get make something that works, and no one places emphasis on the quality of the code.
A substantial proportion of open source software is *also* badly written
- much of it comes from people who have hacked together a program for their own use, and then release it as open source because others might also be interested in it. Some major open source projects also come from a closed source base, and bring that baggage with them (look at the history of the open source release of Netscape - initially, other programmers took a look at the code, laughed a bit, then worked on something else. It took an almost complete re-write to make Mozilla). The act of releasing existing code as open source does not make it good quality.
Where you get *good* open source programming is when the programmers take the project seriously, are working together with many other programmers, and are writing the code knowing that it will be open source. Thus many, but by no means all, open source projects have good code.
And as I said before, many programmers work with both open and closed source. There is no difference in the programmer - but there can be a difference in their priorities when working on different types of code.
What Chris is referring to, on the other hand, is safety-critical embedded systems. In that case it doesn't matter whether it is open or closed - you have no choice but to write good quality code. You have a lot of code reviews, so your code must stand up to scrutiny - your skills are as much on display as they are for an open source coder. It's a different world from the one CB is talking about.
Also the tools I use, mainly closed source, are to the same high quality as the Sw we write.
The problem is that I have seen some absolutely appalling FOSS and in one case it was being actively promoted by the FOSS Devotees over the commercial SW simply because it was FOSS for all the usual reasons... You get the source and can fix bugs, the other costs money etc It is that sort of religious bigotry that gets the FOSS crowd a bad name.
On pure engineering grounds I thought the FOSS application unusable.
The other problem is the irrational hatred of any payware and the supposed incompetence of companies producing this "bug ridden" software. ... I can only assume the FOSS programmers don't actually work in the SW industry. Or are they suggesting that the FOSS they do in their spare time is of a higher standard than their paid work?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
*Some* of the tools will be of similar quality. But much of what you have around those tools, like the operating system on your desktop, is not. And there are few development tools, regardless of the price, that are written to the same high standards as safety-critical embedded systems - to do so would be an absurd waste of time and money. You don't require the same levels of testing, code reviews, and quality control for your IDE as you do for the aeroplane autopilot your are developing with it.
There are times when being open source is an absolute requirement, and poor open source software is then infinitely better than wonderful closed source software. Picking the best tool for the job means weighting your requirements and the available software's features - if you need to have the source available and need to have a free license, then that's your choice for your requirements.
And this obsession with bad open source projects is just as much religious bigotry, and gives the anti-FOSS crowd a bad name.
Please re-read your posts - your appear to have just as irrational a hatred and fear of FOSS as any FOSS fanatic has of closed source software. There are poorly written open source projects out there - no one will deny it. But there are also plenty of exceptionally well written open source projects around, and there are plenty of absolutely appalling closed source programs available too. That's the reality of the software world - just as you can write good and bad programs in any programming language, you can do it with any license and any software development model. If you think that all FOSS is produced by people in their spare time, and is of necessity of a lower standard than closed source software, then you've swallowed the FUD from the likes of MS with an apparently total lack of thought.
Chris has seemed to be consistently and explicitly defensive about selling closed source tools. It may just be a matter of business for him to defend them.
I kind of look at 'open source' as not necessarily free or lacking in ownership and control. Open source can, at times, also be entirely proprietary but 'available.' An example of this from very many years ago was the source code for Digital Equipment's VMS operating system, which I had provided to me (merely as an employee of a company that bought a VAX-11/780) on microfiche. I was able to go though any of the BLISS-32 or MACRO-32 code that I wanted to. Yet the operating system was decidedly proprietary in every way.
One of the advantages of open source regardless of the ownership details, which is simply not provided by closed source, is that in the case of open source no one acts to curtail/limit the number of skilled eyes that may examine it. In the case of more widely used software, this almost certainly guarantees many, many more interested, skilled people will peruse it. In the case of safety-critical software with a narrower base, this may help guarantee access to independent reviews and improved confidence over time. It only takes a single, serious case to be publicly shown in the software, regardless of the lack of an actual experience yet, to help steer everyone around software that shouldn't be in use (which will also encourage the owner of the software to remove the objection or allow anyone to remedy the situation if licensing allows it.)
This is kind of like publication and peer-review in science. A team may patent what they develop, or leave it in the public domain. But regardless, they subject it to peer review and publication and it is part of a generally healthy self-correcting process, over the long haul.
Yes. In the Embedded world it tends to be "most" rather than "some" as poor embedded tools don't last commercially.
The OS is normally Windows and that could be better.
You are not correct in this assumption.
IDe no but the compilers yes. A company that develops a commercial compiler will usually have one process in place for all the project, compiler, linker, librarian, IDE etc. It does not make any sense to lower the standards for just one component.
Such as? Do you mean FOSS or just having the source available? A lot of commercial software does make the source available under nda and licences. But it is not "Open Source"
Absolutely not.
Agreed.
Yes. But as I keep on saying for a all the commercial SW I know where having the source is a requirement the source is available. It is just not available to publish openly.,
Probalby because I am fed up with the complete irrational and religious arguments i see form the FOSS devotees.
Yes.
Not that many as they just don't last commercially. And before you rant at windows it is not that bad in reality. I have had Open Office crash more often that MS office. And both have their problems.
Windows failing is that it tries to do far to much and be all things to everyone.
No I don't believe that any more than I believe that that is lots of bad commercial Sw out there. There used to be going back 20 years but as I keep saying bad commercial Sw does not last. (BTW Windows is not that bad none of my 5 PC systems crash any more than the Mac or Solaris ones.)
Incidentally I have just had a case where having free source code cost the company a fortune. They fixed the bugs themselves and the project manager calculated he could have bought a commercial product (with source) for half the amount the FOSS has cost them in Time/Money the result is still less stable and they are now some weeks behind.
So having the source is not always a good thing. Neither it being able to fix the bugs in it.
As for FOSS being lower quality, some is some is not. A lot is written in peoples spare time but the FOSS devotees keep coming out with a blanket assertion that commercial SW is bug ridden.... Perhaps that is just a reflection of their normal working practices in their day jobs?
I have seen assertions here regarding a particular commercial compiler.... It passes all the usual compiler tests and some of the components are used in several very high end compilers. Yet still I see the blanket condemnation because it is "megabucks" and not FOSS
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.