On Fri, Jan 3, 2014 at 2:54 PM, Ron Wilson <ronw.m...@gmail.com> wrote:
> On Fri, Jan 3, 2014 at 1:50 PM, Joseph R. Justice <jayare...@gmail.com>wrote: > > Actually... What I was thinking of here was not anything related to >> preparation of the software changes or release package, but instead the >> actual deployment of the software itself into the field, and particularly >> into devices which cannot be reasonably expected to be ubiquitously >> networked and remotely upgradeable. How does one update embedded software >> in a VCR or DVD player, or a refrigerator, or a vehicle (car / ship / >> aircraft)? Or, for that matter, update embedded software used in an >> important industrial process, such as a power plant (nuclear or otherwise), >> a chemical manufacturing or processing facility, etc where failure of the >> process can potentially be catastrophic so you don't *want* it to be easy >> to update the software (to avoid malicious changes by third parties)? >> > > Our products are actually components for products of other businesses, so > the details vary, but they are all designed to require a special program > running on a laptop or tablet to communicate with a "flash loader" program > that is nominally permanently resident in our devices. (It is possible to > update the flash loader, but requires extra steps.) This special program is > specific to the producer of the final product and is normally only > available to authorized service businesses. (And yes, we have variations of > our flash loader for each of the final product producers.) > > To reduce the possibility of unauthorized SW being loaded into our > products, we encrypt the binary images. Our flash loader decrypts the image > as it writes the image to built in "flash ROM". > > How a technician connects the laptop/tablet to the component devices > varies based on the type of the final product and the producers' design > standards. Many such products, especially modern automobiles, have > (possibly hidden) service connectors that allow the service program to > communicate with the products component devices via an internal diagnostic > "network". Other products require the technician to plug directly into the > individual components devices. > > While I don't know much of the details, I do know that many consumer > devices like BluRay players, and even TVs, are Internet enabled, so can be > updated over the Internet. For example, my BluRay player at home has an > obscure menu option to start the player downloading and installing the > latest SW from the producer's website. If the download or installation > fails, it it will automatically retry. Since mine has an Ethernet port, I > can take it anywhere I can get Internet access (If need be, I can use > pocket sized Ethernet to WiFi adapter.) > Oh, sure, I agree with all of that. (Those questions were more of a rhetorical question, not actual inquisitive). What I'm getting at is more... Okay. This URL gives cumulative / YTD sales figures for different car models in the USA through November 2013: http://www.goodcarbadcar.net/2013/12/usa-auto-sales-rankings-by-model-november-2013-ytd.html(scroll down for the chart). You have to get to # 45 on that list to get to a model that has less than 100,000 sales for the year (through Nov 2013). The highest selling model on that list to date has almost 690,000 sales. Pick a vehicle with say 200,000 or more sales to the year. (There's 15 different ones.) Let's say that vehicle needs a firmware change to all instances of it out in the field. Let's say it takes 15 minutes (or 0.25 hours) of a tech's time to perform the change for each vehicle. (I suspect that's a low-ball figure.) Let's say that tech's time costs $20 an hour, inclusive of everything. (Again, low-ball.) 200,000 vehicles * 0.25 hours / vehicle * $20 / hour = $1,000,000 dollars. And that's with low-ball estimates. And it doesn't even take into consideration other costs -- for instance, notifying users that they need to bring in their vehicle for a firmware change. That's not a trivial sum of money. Now, perhaps everything to *get* to the point where you can start deploying the firmware change in the first place costs more than $1,000,000. (Or, perhaps it costs less -- I certainly do not know.) But, we've already established that it's going to cost *at least* a million dollars to deploy that change, at least when considered in isolation, in addition to the cost of creating the change to be deployed. (Perhaps you'll get lucky and can perform it as part of "routine maintenance" provided gratis (e.g. bundled into the up front cost of the vehicle) by the dealership to newly or recently purchased vehicles, in which case you can maybe amortize the technician's time over several things.) If it costs at least $1,000,000 to deploy, the difference in cost (development time, etc) between using a statically linked embedded code copy of a library, vs using a dynamically linked separately maintained and compiled copy of a library is probably going to be immaterial, lost in the noise. (And, further, as you yourself point out, for third party code libraries used by the embedded software, you yourself provide (and are responsible for first level support of, e.g. anything that does not require escalation to the third party vendor) the copy of the library being used; no one else is providing, or even able / permitted to provide, the third party library!) Moreover, you're not going to create and deploy it in the first place unless the benefit you gain from doing this exceeds the $1,000,000 + it will cost you to do it. (Otherwise, why bother doing it? It's a money losing proposition, and businesses are in general not in the business of doing things that lose money, or at least not intentionally doing so.) But, remember, this thread (or at least the sub-part of it I spawned) came up as a response to Dr. Hipp's complaint about Fossil's having to support "--disable-internal-sqlite", e.g. having to support Fossil's *not* requiring the use of the copy of the SQLite amalgamation code that is bundled with the Fossil source code distribution, for the benefit of general purpose FOSS Unix/Linux distributions which do not allow applications to use embedded code copies of libraries provided by the distribution, but instead require the application to use the version of the library provided by the distribution as a shared library, which shared library version might be very different from the embedded code copy of the library shipped with the application. I believe that general purpose FOSS Unix/Linux distributions in general (modulo flavors or variants of a distribution such as the Emdebian one I referred to in a different message) don't care about running as or supporting their being used as platforms for embedded software execution / deployment. (Being used to *develop* embedded software, yes!, but that is a far different situation from being the underlying platform the software runs upon in the field.) As such, the conditions of embedded software which allow much more tolerance of, encourage, or even mandate the use of embedded code copies of software libraries bundled with the source code to the application do not apply. Further, even in an embedded software situation, I do not believe that Fossil the traditional monolithic application is likely to be used as embedded software. (I note that I could well be wrong about this, mind you.) I *will* agree that the Fossil protocols and data formats might well be used in or with embedded software, of course! I will also agree that elements of Fossil-NG (Fossil as a library and as applications using that library) might well be used in or with embedded software as well; the library portion most obviously, but perhaps also certain applications provided as part of Fossil-NG. But, insofar as my assertion that Fossil the traditional monolithic application is not likely or perhaps even suitable for use in an embedded software situation is true (which again I note *is* an assertion, and as such might well be shown to be incorrect), then the reasons for and conditions under which development and execution of embedded software applications tolerate, encourage, or even mandate the use of embedded code copies of software libraries bundled with the application do not apply. However... I understand, and am at least somewhat sympathetic to, Dr. Hipp's complaint that requiring a given version of Fossil to tolerate use of versions of the SQLite library older than the version shipped as an embedded code copy within the source code for the given version of Fossil requires (in Dr. Hipp's words, slightly edited as indicated by myself) "having to add silly work-arounds in the code [for Fossil] to accommodate distributions trying to use an older SQLite with a newer Fossil[, which] impedes progress and introduces bugs [and is] a lose-lose situation". That's one of the consequences of mandating that two things (in this case a given version of Fossil and the version of SQLite that the given version of Fossil uses) not be tightly linked together; there's friction between them. As I noted in another message, one way to deal with this from the POV of the fossil-scm.org developers is to explicitly say, and add code within Fossil to enforce this, that a given released version of Fossil is only supported for use with the released version of the amalgamated SQLite library included as an embedded code copy within the source code for that release version of Fossil. Or alternatively, if they are willing to do so, that a given release version of Fossil is only supported with specific released versions of SQLite where the fossil-scm.org devs explicitly list the versions of SQLite they are willing to support for that release version of Fossil, and update the list (adding and removing versions of SQLite as appropriate) every time a new version of Fossil is released. By doing this, the onus of supporting a given version of Fossil with any random version of SQLite which might be available as a shared system library (which version might be older than or even newer than the version provided with the source for that version of Fossil as an embedded code copy), and the resulting requirement to create and support workarounds within that version of Fossil for such use, and the responsibility for dealing with any bugs which might thereby be introduced, is *moved* from the fossil-scm.org devs to the various Unix/Linux distributions and their respective packagers of Fossil. If the fossil-scm.org devs do not support that usage, it's not their (the Fossil devs) responsibility or problem. If the *distributions* want to support that usage, then it's the *distribution's* problem. I'm pretty sure any reasonable distribution would agree with that point; it is, after all, their reason for being -- integrating disjoint and unconnected software components to form a unified whole. Note that I speak here solely of *released* *versions* of Fossil, and what released version of SQLite each different released version of Fossil support. This, because I am pretty sure that most Unix/Linux distributions will (generally) only care about packaging and distributing released versions of Fossil as opposed to attempting to package and distribute a tip-of-trunk in-development version of Fossil. (As I said before, if there is a very extended period with no released versions of Fossil, they might try to make a defacto release from a development version, but I think this is normally unlikely.) I note that the original poster (Andy Bradford) to this thread was, apparently, *not* trying to compile / use a released version, but instead was trying to compile / use a development version of Fossil with the shared system library version of SQLite provided by the system Mr. Bradford was using (some version of OpenBSD). I'll agree that *this* should not necessarily be supported by the fossil-scm.org devs. I agree with Jan Nijtmans that in this circumstance it makes more sense, at least for anyone not a packager of the software (e.g. someone who is an end-user of Fossil) to use the version of SQLite provided with the development version of Fossil, and further that every version of Fossil should indicate which minimum version of SQLite it requires (and I'll add that for a development / non-release version of Fossil it may well be acceptable to support only the version of SQLite provided as an embedded code copy within Fossil). I also agree with Martin Gagnon that checking in the configure script that the version of SQLite available as a shared system library meets that version of Fossil's minimum requirements when specifying --disable-internal-sqlite seems like a good idea. Thanks for your time. Hope this is of some use, interest. Joseph
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
