On 11/08/2017 04:02 AM, Christian Gagneraud wrote:
On 8 November 2017 at 13:35, Roland Hughes <rol...@logikalsolutions.com> wrote:
Back in the days of the VAX 11/750 all of that microcode (what it was called
I know VACOS (VAcuum Cleaner Operated System) but I do not know VAX, sorry! ;)
This site has a picture, but pretty much everything else they list is wrong.
http://gunkies.org/wiki/VAX-11/750
A bit better write up. The first OS to run on it was VMS. Later there
was Ultrix and other things.
https://en.wikipedia.org/wiki/VAX-11
VMS was and still is the operating system created by God. When it
posolutely absitivly __has__ to work it goes on VMS. VMS clusters (the
only real clusters) now called OpenVMS clusters, have contiguous uptimes
measured in decades. The vast majority of systems written for and still
running on this platform were designed to run correctly long after the
human race is extinct. That's not a joke. Most every nuclear power plant
in the world, vast majority of steel and paper mills, any and every
place a really bad thing will happen if a worthless PC OS was used.
If you search around you can find, it's either the Irish or the British
railway system has been running for over 17 years of contiguous up time.
If you want to know how to program on it, you can find a copy of this:
http://theminimumyouneedtoknow.com/app_book.html
Actually, Dr. Dobb's decided that book is one of the few books which
should be on every programmer's book shelf
http://www.drdobbs.com/tools/developers-reading-list/232500396?pgno=6
then) was on a cassette tape you turned the key to boot from. Whole menu of
diagnostics. Today we see a good number of systems returning to built in
test and calibration code.
Yeah, that completely true. But I see these as "system test", not unit test.
I don't think i want to run my system tests from QtC. Sounds like a click bait.
You could argue, that using Boot2Qt with their qemu stuff, you could
achieve that.
But I still think it's the wrong abstraction level.
A simulated Boot2Qt always runs in a x86 vm. It does boot the same
embedded linux distro but it doesn't boot on the same virtualised
hardware. I guess you could tweak the arch in Yocto, maybe... is it
worth?
Anyway, it's an interesting topic, for example are we talking factory
site auto-tests (eg. flash) or customer site auto-test (eg. remote
update)?
How much HW can you emulate/simulate that will make your tests meaningful?
"All life is sacred" she uttered while eating a steak.
Sorry, your viewpoint reminded me of a snippet of a novel I've returned
to working on and have been serializing in un-edited form on an authors
blog.
http://www.interestingauthors.com/blog/fiction/my-orphan-pt-1/
It will be a few days yet before the characters have the discussion
about "All life is sacred" and humans being forced to eat other things
which were once living, therefore "all" has a rather scoped definition.
Here, your definition of "unit" is rather scoped. It's not your fault.
If you actually went to college for programming (be surprised how many
in this field never did) and you were taught real logic, without PASCAL
as part of the course, you had instructors teaching you each function
required a "unit test." This was college. You were learning and this was
all you had to work with, the single function you had just written.
In there defense, from the 1970s through to the late 1980s, many, many
programmers were writing either for commercial sale, or in-house use,
"library" functions. When C finally came out there were, perhaps
thousands, of C function libraries for sale during days of DOS. Screen
libraries, indexed file IO libraries, "super functions," the list went
on and on. Some of it would still be useful today if the companies which
wrote them hadn't went out of business without OpenSourcing the license.
Other exist only on 5.25" floppies few can even read. "The C-Users
Journal" used to let you purchase 5.25" floppies of all kinds of code
written by staff and contributors. All of it is long since gone. Some of
it would still be useful today.
When it comes to the world of embedded systems, "unit" has a much larger
meaning and for good reason. Take something like a patient monitor. Some
little device which puts a user interface and some control software into
a box which then includes:
1) A blood pressure cuff pump with pressure sensors
2) An SP/O2 finger clip unit with current sensors
3) A temperature unit.
There could be other things in the monitor as well, but let us just
assume this set. Each of these things is a "unit." The bundling of all
of them into one device is also a "unit." Why does this terminology matter?
Unitized parts.
Each "unit" has to endure some, potentially 7+ years long, clinical
trial/testing process in a regulated environment. I don't remember the
exact wording of the FDA training, but, the higher the potential for
"adverse outcome" the more intense and lengthy the testing process.
Putting that in simple terms, a surgical robot goes through way more
testing that a computerized temperature monitor. Policy and procedures
are in place everywhere to cross check wacky temperature, blood
pressure, SP/O2, etc. readings manually which is why hospitals tend to
have half a dozen temperature taking methods and still have scads of
manually operated cuffs for your arm.
What _is_ important about all of this is the concept of "unitized
parts." When assembling your patient monitor you make certain to utilize
a unit for each reading which has already gone through the approval
process. Now your unit, which is a front end for all of these other
units and sends data back to one or more remote systems, just needs to
prove itself and that it doesn't interfere with the other previously
proven units.
Economies of scale are achieved by utilizing the same parts over and
over across different products. You can only do that if each part is a
fully tested unit.
While I will be the first to state:
Professionals Don't Use Microsoft Products
Microsoft attempted to do this with VBX controls. Things you dragged and
dropped into your desktop application then tweaked a few settings on so
they did what you wanted. They were supposed to be trusted units.
Problem was the slipshod coding and AGILE practices turned most of them
into randomly exploding bombs rather than trusted units.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
