Embedded Systems Conference
Breaking News
Newest First | Oldest First | Threaded View
<<   <   Page 3 / 3
User Rank
That's the free market for you
RyanG_#1   4/22/2014 12:16:33 PM
 People and companies will pick what is best by their own criteria, whether that's software or washing powder.

Cost isn't always going to be the deciding factor, take a look at the web server share going to Apache, the use of free languages like Scala in big corporates like Twitter and various banks etc.

I don't see myself adding a bit of code for an OS like Windows.  Why should I, why would MS let me?
At the high end, this isn't about cheap, it's about leveraging the available talent pool at many different companies, institutions, and other individual developers where all can contribute for the greater good.

As one datapoint, for our latest project - a cloud based commercial offering, there is no closed or paid for code in it.  That's because the free beats it all hollow, technically, published literature, user base, etc.

On the other hand, if I play a computer game, it'll be produced commercially, because they are better currently.

In the end we'll find out what the market thinks on a case by case basis.

User Rank
Article very poor and biased.
ju4n6142   4/22/2014 12:04:06 PM
You confuse freeware, open source with free software. Please, recheck the definition of "free software" before demonising it.

User Rank
Open Source Software is actually quite expensive.
adonoho   4/22/2014 11:50:16 AM


Open Source Software is quite expensive to produce. Just integrate the man hours that goes into something like the Linux kernel or OpenSSL and then multiply by the loaded overhead of an average programmer. You will be shocked at the amount of time-is-money being contributed to OSS efforts.

Yet each contribution is frequently a point patch. They typically solve a problem the patch submitter has. While it is the "job" of the core committers to rationalize all of the patches and move the technology forward in a coherent fashion, there is both little reward for doing so and sometimes deep push back from the user community.

Take, for example, the Python language transition between v2 and v3. There is a deep architectural flaw in how Python v2 misuses strings as byte arrays. We learned this lesson from the C-language. Null terminated strings are a bad idea. Misusing pointers is also the source of many security flaws. Guido and the core committers have tried to fix this flaw in version 3. There is a remarkable amount of pushback from the community. They think their code isn't broken. (It is but they don't run into the problems from international languages fixed in Python v3.) Python v3 is a better language in almost every measure yet after 5 years it only has about 10% uptake. The v2 stubborn mules are making a lot of noise about how Python v3 has failed. I don't believe it has failed. It has started a transition of a 20+ year old technology to a new path. That it has taken 5 years is a testament to the quality and maturity of the engineering team and their respect for the value of legacy code written in Python.

By almost any measure of engineering quality, the Python transition is the model of how architectural flaws should be addressed in open source. It is a testament to the leadership of Guido's team that they persevere. From the independent analyses I've found, it doesn't appear that the OpenSSL has a similar ability to improve their code base. Yet, OpenSSL, as the foundation of e-commerce, is a much more economically important technology than Python.

But in the game of software development, which more frequently ressembles a game of cut-throat, he who invests the least and gets to market the quickest wins. There is little time to justify reengineering "free" software. Just "bolt it on and hope she holds together" is the operating maxim. Well, OpenSSL isn't holding together.

OpenSSL could do with a little bit of corporate stewardship. Google found the problem. (I suspect they found it due to a likely internal audit of every security protocol resulting from NSA having pwned them and everyone else.) Google obviously depends upon OpenSSL for their business. How many Google engineers are in the OpenSSL core committing team? In contrast, how many are in the Linux core committing team?

I hope more companies start funding the development of these critical technologies more directly. Their businesses depend upon it.




User Rank
hsattler222   4/22/2014 11:47:35 AM
..Gents, there is no free lunch, never was, so we should not be surprised by problems.

I think we have to face the future and pay for quality and get rid of dangerous freebies and risky dubious products...

Heinz Sattler - Rio de Janeiro

User Rank
How much more does "non-free" cost
jeremybennett   4/22/2014 11:41:19 AM
hasenmi hits the nail on the head. If this occurred in proprietary code, we'd never know about it.

The true value of free is not in the dollars spent, but in the openness. When there is a problem it is there for everyone, and being open there are many more eyes looking for the problem. The openness ensures there is rapid pressure to fix the problem.

By comparison, for a proprietary tool such as the Microsoft Crypto API, we have to rely on Microsoft assuring us it does not have such a bug. And just Microsoft engineers looking for bugs. And Microsoft's professionalism in fixing and publicizing any bugs they do find.

Many free and open source projects are very well resourced - think of Linux, Apache and the GNU Compiler Collection. All developed by very large communities of well paid full-time professionals. There is plenty of commercial incentive to resource these projects properly.

But even smaller projects actually look quite good compared to much proprietary software. For example, a lot of proprietary EDA tools are provided by small companies or small departments of larger companies, where the R&D team numbers less than 10, and is doubling up providing second line support. By comparison even small team free software looks pretty good, and you still have the freedom of fixing it yourself - no dependency on the supplier here.

The article is correct that we have to look at the cost of free software. But when we look at all the costs, it often turns out that freedom can deliver much better value than proprietary software.

User Rank
Re: No different than the cost of 'NOT-Free'
Paul.Chow   4/22/2014 11:23:12 AM
And it's easy for everyone to inspect and find those bugs in the "closed" software, right?



User Rank
Open Source quality is demonstrably better
stvw   4/22/2014 11:20:03 AM
Gee - software has bugs. Shocker!

The facts are that Open Software is generally of a higher quality than proprietary software.  From an article just published on 4/16/14 Coverity reported that the defect density for Open Source code was 0.59 while the proprietary code is 0.72.

There were lots of other useful information in the article such as there were 17 times as many defects fixed in proprietary code as in the Open Source code.

So - stop with the soul searching and just get on with it.,

Steve Wilson


User Rank
No different than the cost of 'NOT-Free'
hasenmi   4/22/2014 11:16:14 AM
And of course, this type of buffer issue could never happen with propriatary software, right?

<<   <   Page 3 / 3

Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

March 28 is Arduino Day -- Break Out the Party Hats!
Max Maxfield
Well, here's a bit of a conundrum. I just received an email from my chum David Ashton who hails from the "Unfinished Continent" Down Under. David's message was short and sweet; all he said ...

Bernard Cole

A Book For All Reasons
Bernard Cole
1 Comment
Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...

Martin Rowe

Leonard Nimoy, We'll Miss you
Martin Rowe
Like many of you, I was saddened to hear the news of Leonard Nimoy's death. His Star Trek character Mr. Spock was an inspiration to many of us who entered technical fields.

Rich Quinnell

Making the Grade in Industrial Design
Rich Quinnell
As every developer knows, there are the paper specifications for a product design, and then there are the real requirements. The paper specs are dry, bland, and rigidly numeric, making ...

Special Video Section
After a four-year absence, Infineon returns to Mobile World ...
A laptop’s 65-watt adapter can be made 6 times smaller and ...
An industry network should have device and data security at ...
The LTC2975 is a four-channel PMBus Power System Manager ...
In this video, a new high speed CMOS output comparator ...
The LT8640 is a 42V, 5A synchronous step-down regulator ...
The LTC2000 high-speed DAC has low noise and excellent ...
How do you protect the load and ensure output continues to ...
General-purpose DACs have applications in instrumentation, ...
Linear Technology demonstrates its latest measurement ...
Demos from Maxim Integrated at Electronica 2014 show ...
Bosch CEO Stefan Finkbeiner shows off latest combo and ...
STMicroelectronics demoed this simple gesture control ...
Keysight shows you what signals lurk in real-time at 510MHz ...
TE Connectivity's clear-plastic, full-size model car shows ...
Why culture makes Linear Tech a winner.
Recently formed Architects of Modern Power consortium ...
Specially modified Corvette C7 Stingray responds to ex Indy ...
Avago’s ACPL-K30T is the first solid-state driver qualified ...
NXP launches its line of multi-gate, multifunction, ...
EE Times Senior Technical Editor Martin Rowe will interview EMC engineer Kenneth Wyatt.
Flash Poll