No. A battery voltage absolutely don't follow the law of a capacitor voltage. On a battery, the voltage drop no so much as long as the chemical process is still producing charges. Depending on the chemistry of the battery, some components might change over time, over temperature, over chemical contamination, or current flow, and this result on a drop of voltage from the nominal one. Anodes stability in for example a critical component in many battery chemistry.

Take time to read datasheet of some batteries and play attention to there voltage discharge curve.

In Switzerland, the Law on Road Traffic sets pedestrians priority on vehicles. So, vehicles have to be very careful in any situations involving pedestrians, and the noise of the vehicles play a less important role to the safety. The effect of the rule has proved to be a success to lower the number of accidents, even if a few fanatic periodically attack it. The fact is that pedestrians includes vulnerable groups of peoples like children and seniors that can't be required to have a license to cross roads.

There is still embedded systems running Linux that use ISA bus. My company maintain one such system that run every day in a public transportation system. At the time (around 2005) the system was designed (by a now defunct company), it was a fast project that reused schematics from previous successful projects to lower the risk.

You can find a photo of the system CPU board in this manual: support.elmark.com.pl/advantech/pdf/SOM-4481man.pdf

Please moderate parent up to the max.
This is the only interesting factual post on this thread.

Pure speculation: maybe this part of the message was more oriented for the tablets and smartphones than for PC.

* Users want Android because there fell confident that this allow them to be at the same level as others users.
* Developers want Android because there fell confident that this allow them to spread there application to the maximum of users.
* Manufacturers want Android because users and developers want Android.
Now the drawback of this situation is that Google take too much control of Android. Most users and developers don't have any problem with that, but this is certainly not the case for many manufacturers that basically only have there brand name and distributors channels to compete, as the mid range hardware tend to normalize across all this industry.

Tizen is actually only an OS. The interesting experiment is to use Open Mobile’s ACL Technology to add the Android market on the Tizen OS. This is a long move. If successful, it can split the Android dominance into two parts: the Android apps market and the Android OS. Google will probably keep control of the Android OS, but there will be an increasing pressure to take some control of the Android apps market from Google.

It will be interesting to see how Google will react to "OpenMobile World Wide" in case there product start to gain a substantial market share. Will be open or evil ?

PTP is mainly designed to work well on LAN. While it can be used on WAN, there is currently no equivalent to the large quantity of open NTP servers on the internet. Thanks to the open NTP servers, NTP bring service comparable to GPS regarding time synchronization source, something that PTP is unable to do if you don't have access to particular master PTP node, usually connected to a GPS or a NTP server.

Maybe one day PTP will have a range of open master node on the internet, but AFAIK this actually not the case. It should be noted that when used over WAN, PTP is not better that NTP from the precision point of view.

Finally PTP don't solve all issues. To have a reliable actual time and time processing capabilities everywhere around the world, NTP, GPS and PTP should be extended to broadcast the updated historic leap second table and the updated timezone database, as well as the UT1 frequency offset. With all the additional information, any devices could use the right time for his purpose.

This fully depend on the goal of the people that setup the AI machine. If the goal is set to destruct a population, the AI machine could be very efficient at doing the job...

I think that the last time I used a composite video signal was about 10 years ago to playback the video from a camera recorder with a magnetic tape.

Having application maintaining there own libraries is more like an loosely workaround than a solution. Some libraries of one application could share information with others applications that maintain an other version of the libraries, resulting in a inflating code and complexity to support old formats or resulting on unsupported situations. The Linux way of packaging libraries require constant support from the application providers, but the advantage is a fast evolving ecosystem, small footprint, and stable operations.

I have to see an OS that can link any libraries for any language to any application. I known that the GObject introspection project dream to bring something close to that: http://helgo.net/simon/introsp... . AFAIK, Vala (a kind of C + GObject) is the most advanced experiment in that direction with automatic binding in a number of languages already functional: https://github.com/antono/vala... . But here the OS have very little to do as the hard part of the linking process is done by the GObject introspection library of each language. Please note that GObject is able to work so well precisely because the naming schema is well defined.

It's actually popular to introduce a few new languages each year and to write a lot of libraries for each languages that do almost the same job. At some point in the future, so many choices will make more problems than it solve, mainly because of the dilution of the efforts and lack of support where the community is too small. C has a big community for good reason, but C in not used for some projects for others good reasons. Some basic object programming features is probably the most obvious one, especially when observing that many C projects organize there code like objects if not directly using GObject or similar libraries. Given the today situation, I think that C could evolve in a cleaver way without making any harm.

I completely agree with the first half of your message.

Yes inheritance imply function pointer, a very used feature in C so I don't understand why you find it so crazy.

Yes new C features will be developed in a fork like in every project. Maybe one of the fork will be interesting enough to get accepted by a large part of the community and be merged into the standard. Actually a lot of projects have some basic construction that look like objects, but each is different. There is GObject, but it's still confined to a small subset of projects.

I think that highly optimized standard libraries is the key for high level programming for any language. In a ideal world all languages would use the same libraries and only the syntax would change, but actually, using a language that have libraries that support most of the needs for your application make a lot of sense. PHP for example was one of the early web server language that provided a library complete enough to make web server programming easy and this proved to be a hit, despite the fact that the language was still in a early stage and evolved a lot over the first decade.

Developers see mangling fiasco as soon as there try to mix libraries from different compilers or languages and you seem to agree on that. The fact that a lot of C projects use basically the same idea to organize there code to look like object could be standardized in C. No need to use C++ to do that.

Using C++ just to get a few objects is fun only until you get stuck at one of the overlong cryptic unintelligible error messages from the compiler.

C++ since 1989 is not as simple as you describe. But even before C++ 2.0 some dramatic choice make it a over complex language. The most obvious problem from my point of view is the lack of a standard and direct naming schema between class and his elements and methods that started the name mangling fiasco. If you look to numbers of big C projects, you will find far simpler implementation of something that look like objects.

Thanks for the JIT link, it very interesting.

I agree to your concerns: C must only integrate features that have proved to be widely approved, simple, clean, useful, and efficient.

Take for example the dynamic table allocation on stack or the dynamic initialization of a struct. Those features don't break existing code, but make new code more simpler to write and bring to the compiler a more direct indication of the goal of the code. I am certain that some useful features of a simple object programming model would be useful if introduced the same way in C. Don't get me wrong, I am not talking about a complex crap like C++ !

I disagree that this will remove flexibility. For example dynamic table allocation on stack or the dynamic initialization of a struct have not removed flexibility. There have standardized features highly desirable without forcing anyone to use them. After many decades of object programming evolution, I am certain that some basic OO features could now be safely integrated into C.

I agree that Java and C# have a cleaner and simpler object programming model than C++, but there are not popular (if even suitable) to write low level code. C is very successful because it usability span from the smallest microcontroller to very big projects. Support for almost all silicon is almost exclusively done in C and it's very unlikely to change quickly. I think that adding a pragmatic simple object model to C will make a lot of sense.