Lint

That was sort of my entire argument in this thread...

Apparently there has been some discussion about getting a new maintainer for splint - if that happens, perhaps it will again become a living project.

Name then and demonstrate the proof.

RedHat for example who publish a lot of FOSS but all their own SW is closed source and IP protected.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

IMO not so rare. Please don't misunderstand, there are great FOSS tools, but I'm also using a lot of products I prefered to pay for because the commercial closed source product was _much_ better and/or simpler to prepare than any FOSS product I found.

Just to mention "embedded" related tools: Compiler for HC08/HC11/HC12, debugging toolchains, schematic and pcb eda tools, diff tools like Beyond Compare or EC Merge.

Oliver

--
Oliver Betz, Munich
despammed.com might be broken, use Reply-To:

Why reinvent the wheel when there are a lot of good static analysis tools out there already

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Commercial does not mean closed source. You can get the source of many commercial products. Also there is a lot of software that is freely available that is not FOSS. There are a lot of free tools about where you don't get the source.

It is not FOSS vs commercial closed source. There are many alternatives to FOSS

It does depend on the field you are working in.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

My company uses almost exclusively open source software for server software. How much money do we save from having Linux instead of a server windows version on our four servers? How much do we save on client access licenses?

We have about a dozen virtual servers running on the bigger server - running windows, each of these would need a license and our workstations would need a set of client access licenses. Then there are the server programs - email server, database servers, file servers, web servers, version control system, etc. Again, with commercial software we'd need licenses for the servers and client licenses.

So on the server side, we save 100% of the software licensing costs. I do the installation and support, so there is no cost there. I realise, of course, that there is a time cost - I think it is significantly lower using the FOSS software than using commercial software. If I want to set up a new database server, I can install a new virtual machine and postgresql server in about half an hour - going the Windows Server + MSSQL server route I'd barely have had time to order new licenses by then, much less figured out the rules and regulations for appropriate CALs.

Of course, we'd also need much more hardware - one of the Linux servers is a 90 MHz pentium with 64 MB ram, which is fine for file servering and print serving, but not much good for a windows server.

I don't have any overview over how much it would have cost to use windows and commercial software instead of Linux and open source software, but it would have been substantial.

The main reason for using Linux for the servers, however, was not the cost. It is simply a better solution (at least for us). It is easier to work with, provides a more stable platform, and has features above and beyond what can be achieved with Windows. If the cost price had been identical to that of windows and windows server applications, I'd have made the same choices (in most cases at least).

On desktops and workstations, we have a mixture of commercial and open source software. Most run windows rather than Linux, but most have open office rather than MS office and Thunderbird for email. For other applications like development tools, there is a wide variety of open and closed software. We use FOSS if it is as good or better than other choices, and pay for commercial software if it is better for the job.

Yes, Red Hat are famous for keeping all their software closed source. In particular, they are very careful to keep their installer, their hardware detection system, and their package manager as closed and secret as possible. That's why it is impossible for other people to make distributions based on Red Hat, starting by merely modifying the trademarked name and logo.

Or perhaps I've got that a little bit wrong...

Most FOSS companies *do* keep some of their software closed for a variety of reasons. SUSE used to keep their setup tool YAST closed (it's now GPL) to keep it as an advantage for their distribution. Canonical have some of their web applications closed, and Google of course keep a lot secret. Red Hat is perhaps the worst example you could have picked.

Memory management and string handling are examples of library features that are oft replaced by a better implementation of the standard API or by an implementation of a better API.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/

Even if it starts to breathe again, it's got some very fundamental problems. In order to turn it into something useful for checking production code, some of the basic design decisions are going to have to be revisited.

--
Grant Edwards                   grante             Yow! I want to read my new
                                  at               poem about pork brains and
                               visi.com            outer space ...

At a previous employer we had an old application built using Greenhills tools and needed to update. As part of this we needed to get a new compiler license. The new GH tools cost over 8k for a single seat plus annual support, did not handle the old code (totally new assembly language interface) and had several bugs with optimization and inlining for the CPU, which we needed for a couple of features since we weren't updating the hardware (yet).

Since it was not one of their popular CPU's, GH could not give an estimate on when the bugs would be fixed beyond - its not scheduled yet, so at least 6 months. Their solution was to provide the old version of the tools, with no support.

We looked as using GCC, with support from Microcross, which cost approximately the same as the GH support, and included samples of converting from the old GH Assembly interface to GCC and no limit on how many users. Porting took about the same amount of time as the GH update. Code size was marginally larger (less than 2%) when we used the embedded versions of the libraries provided.

When we updated the Hardware we used an ARM CPU, which was better supported by GH, but they wanted another 8K for the tools plus support (we had returned the tools but we were told that the discount for support for multiple CPU's was only 25% on the second support contract. We did find one bug during the port, (also optimization related) and we had a workaround within 2 hours and an updated compiler within 3 days.

With FOSS we did not need to pay for another compiler and the support ended up costing the same (there was an increase for the second CPU type that was offset by a decrease in their standard support cost.

Result - 3 months wasted on initial port because of poor support, (4 weeks porting, 2 weeks identifying the compiler bug, 6 weeks before we were informed that the bug was verified but the fix was not scheduled and the rest trying unsuccesfully to either work around the bug or port the new code to the older compiler). Switching to FOSS did not impact development time or hardware requirements significantly, but saved over 16K on a single small project. Total development costs for the hardware and Software upgrades were approx 100K (probably 30% software) over 6 months (excluding the wasted initial port). In addition the tools were used by 3 different Software developers on several other projects over the same period.

This may not be 50% saving on the development costs for this project, but the overall savings to the company on software tools during this period were significant.

I accept that some of the issues were because of the significant time between the initial development and the update and the resulting change in the compiler, as well as the choice of a less popular CPU, but we were able to find a FOSS support company that knew and understood the CPU and tools, whereas we had no such options with the closed source product.

Because they aren't available in this field, and splint is free, while PC_LINT costs about $350.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

... snip ...

Not so. They publish a good deal under the GPL.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

An excellent rejection of the "only commercial" diatribe. One of the problems is that you don't know, in advance, the penalties involved in the commercial project. At least with FOSS the trial is up to you.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

That's if you're a Windows user. If you can't afford fast/expensive hardware or just don't want to waste the time/money to run Windows, you've got to cough up $1000.

At least the Gimpel product is useful -- even though the pricing for non-windows customers is draconian.

--
Grant Edwards                   grante             Yow! CHUBBY CHECKER just
                                  at               had a CHICKEN SANDWICH in
                               visi.com            downtown DULUTH!

... snip ....

Yes. To me, this is an indication that Gimpel is doing something right (from the point of view of their making money). If splint, or a successor, ever becomes successful and handles C++ I expect to see the price of LINT plummet. I am not holding my breath.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

I spent some time working on splint a few years ago to try to get it to stop complaining about various sorts of obviously correct code without having to disable so many warning categories that it then wouldn't complain about obviously incorrect code. It became obvious to me that splint was too far down the wrong road for it to be turned into something useful. On the mailing list the official maintainers admitted as much and said splint was an academic research project that wasn't ever intended to be useful for checking real programs.

It's too bad, because quite a bit of effort has been put into splint.

--
Grant

I don't see why. Gimpel's PC-lint is one of the least expensive static analysers around. Professionals have no problem with the cost of PC-lint .

Pc-lint along with other static analysers has a proven track record and a Provence for the tool. Jim and Annelise Gimpel have been on the ISO C and C++ panels for years.

Just producing a "static analyser" does not mean anything until it has been shown to be a dependable tool by independent assessment.

The problem with FOSS is there is so much religion and blind faith it will be difficult to get any meaningful answers.

Every time I mention testing GCC all I get it " it has a test suite" from the fanatical. Actually it has a build suite and a fairly flaky one at that. I know some one who assessed it and it fails on several major points.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Sorry, I missed the questionnaire you used to establish that _fact_.

That is a fact

30 years in the business and dealing with many customers and feed back at many trade shows and conferences where I speak on SW quality (sample size around 10,000 people)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I'm a paid-up user of PC-lint, but I'd prefer it if you didn't speak for me.