Re: Release/Revision standard notation?
John Larkin
>Hi all,
>
>Can anyone tell me the format behind "Revision/Release" notation? For
>example: Rev. 1.30.35; which is so common in software (and some hardware).
>Is it an arbitrary system? I've tried searching for it, but come up empty
>handed. I've been able to query on this:
>
>IEEE standard taxonomy for software engineering standards
>
>but, I keep coming up with sites that want me to pay for the article. Not to
>mention the fact that the above article will have way more information that
>I'm looking for. I can't think of what else to search on.
>
>Any help?
>
>Thanks,
>
>Scott
>
>
>
The 4.00.02b notation is crap, and I can't see any patterns in actual
use.
As engineers, we use revision letters for code and for hardware. A
piece of embedded firmware is 28E346 rev A; the next release is B. All
the source files are named in the same pattern... assembly source is
28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
The shippable binary might be 28E346A.ROM.
A hardware top assembly could be 28A346-3B, where -3 is a version
(literally the "dash number") and B is the rev. This is basic
aerospace notation.
Before it defines a product, hardware and firmware documentation is
formally released to the company library, with a genuinely useful
README file, which library is where manufacturing always gets stuff
from. And it's all tested *before* it's released!
We also require that all software tools be identified, version
controlled, and released to the library too. So 10 years from now we
can run one batch file to regenerate the whole build, and know we'll
get exactly the same firmware, byte for byte.
John
Joerg
> On Fri, 5 Dec 2008 16:57:02 -0500, "asdf" <sa...@sdff.com> wrote:
>
>> Hi all,
>>
>> Can anyone tell me the format behind "Revision/Release" notation? For
>> example: Rev. 1.30.35; which is so common in software (and some hardware).
>> Is it an arbitrary system? I've tried searching for it, but come up empty
>> handed. I've been able to query on this:
>>
>> IEEE standard taxonomy for software engineering standards
>>
>> but, I keep coming up with sites that want me to pay for the article. Not to
>> mention the fact that the above article will have way more information that
>> I'm looking for. I can't think of what else to search on.
>>
>> Any help?
>>
>> Thanks,
>>
>> Scott
>>
>>
>>
>
> The 4.00.02b notation is crap, and I can't see any patterns in actual
> use.
>
> As engineers, we use revision letters for code and for hardware. A
> piece of embedded firmware is 28E346 rev A; the next release is B. All
> the source files are named in the same pattern... assembly source is
> 28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
> The shippable binary might be 28E346A.ROM.
>
> A hardware top assembly could be 28A346-3B, where -3 is a version
> (literally the "dash number") and B is the rev. This is basic
> aerospace notation.
>
Yep, same here.
> Before it defines a product, hardware and firmware documentation is
> formally released to the company library, with a genuinely useful
> README file, which library is where manufacturing always gets stuff
> from. And it's all tested *before* it's released!
>
> We also require that all software tools be identified, version
> controlled, and released to the library too. So 10 years from now we
> can run one batch file to regenerate the whole build, and know we'll
> get exactly the same firmware, byte for byte.
>
Then make sure you never use any dongled SW because that could seriously
throw a wrench in there.
--
Regards, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Tim Wescott
I try to be a nice guy, and one of the ways that I try to be a nice guy
is to be sensitive to those times when a vendor really doesn't want me to
be a customer. When a vendor starts throwing out subtle "we don't want
your business" clues, I do my best to find an alternate source, and allow
the grumpy vendor to go on with their business free of an risk of getting
my money.
Dongles are, IMHO, one way that a vendor screams "we don't want your
business, thank you".
--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com
Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Joerg
Complete agreement in this here office :-)
I have never bought dongled SW in over 20 years. Not one.
John Devereux
> A hardware top assembly could be 28A346-3B, where -3 is a version
> (literally the "dash number") and B is the rev. This is basic
> aerospace notation.
How do you define the difference between a "version" and a "revision"?
Are all version 3 products interchangeable, for example?
--
John Devereux
John Mianowski
> John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:
> > A hardware top assembly could be 28A346-3B, where -3 is a version
> > (literally the "dash number") and B is the rev. This is basic
> > aerospace notation.
>
> How do you define the difference between a "version" and a "revision"?
I've seen a lot of different variations between industries, companies
within industries, etc. Sometimes you'll see it expressed as "VxRy"
or some variation that makes it a little easier to visualize.
Basically, there are 3 "levels" of change. The top level represents
basic, fundamental issues such as platform, core, basic features &
capabilities, etc. The next level might represent "secondary"
features, added to the primary ones at the top level. The 3rd level
would be changes based on problem corrections, that don't add any
particular feature or capability.
As an example, a company I used to work for used "V" numbers to define
the core processor & basic architecture generation of the system. V1
was the original, 8080-based system; V2 was 8086-based & fit the same
cabinets, but included some major changes to the inter-processor
communications & disk subsystems. V3 was a complete repackaging, with
upgrades to several subsystems but retention of the same CPU & inter-
processor comm. V4 was a consolidation & downsizing. V5 was another
complete repackaging with several upgrades to subsystems.
Within each Version 'x' were several revisions. Each revision level
introduced some new major features..Within each Revision 'y' were
potentially many lettered "Sub-revisions" that included bug fixes &
sometimes a new, minor feature. Sometimes, a R-level upgrade required
a corresponding hardware and/or firmware upgrade to go with it.
> Are all version 3 products interchangeable, for example?
Maybe, maybe not. In the above example, V2R05A & V3R05A would
represent identical levels of feature enhancements & bug fixes, but
due to the base hardware platform differences between V2 & V3, neither
would run on the other platform. Also, V3R07A might not be backward-
compatible with V3R05C due to an hardware/firmware change(s) somewhere
in the system, to accommodate features in R7 that weren't in R5.
Generally, with a VxRy there was universal compatibility (i.e. you
could go back & forth between V3R8x & V3R8y with no problem other than
the possible reintroduction of bugs; sometimes a subrelease to "fix"
one bug created another, creating a need to accept the lesser bug
temporarily & revert to a prior level). Different "V" levels may also
have different "R" levels as well. Sometimes, a bug appears entirely
due to the change in "top" level so there's no corresponding need to
"fix" it in a prior level, since it doesn't exist there. Also, prior
"top" levels may become obsolete, with both feature enhancements and/
or bug fixes suspended.
The 'xxx.yyy.zzz' notation might represent similar levels, such as
'xxx' = base platform, core feature set, etc.; 'yyy' = feature
additions; 'zzz' = bug fixes. Then again, it might not.
As with so many things, "it depends".
JM
Joerg
> John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:
>
>> A hardware top assembly could be 28A346-3B, where -3 is a version
>> (literally the "dash number") and B is the rev. This is basic
>> aerospace notation.
>
> How do you define the difference between a "version" and a "revision"?
>
Versions are not 100% compatible amongst each other, more geared towards
special uses. Revisions ideally are interchangeable but may, for
example, require firmware adaptations.
> Are all version 3 products interchangeable, for example?
>
Not necessarily, I'd even say usually not. Revisions, however, should be
form-fit-function compatible or one should rather issue a new version.
In med/aero there are very strict rules about this.
Tim Wescott
> On Fri, 5 Dec 2008 16:57:02 -0500, "asdf" <sa...@sdff.com> wrote:
>
>>Hi all,
>>
>>Can anyone tell me the format behind "Revision/Release" notation? For
>>example: Rev. 1.30.35; which is so common in software (and some
>>hardware). Is it an arbitrary system? I've tried searching for it, but
>>come up empty handed. I've been able to query on this:
>>
>>IEEE standard taxonomy for software engineering standards
>>
>>but, I keep coming up with sites that want me to pay for the article.
>>Not to mention the fact that the above article will have way more
>>information that I'm looking for. I can't think of what else to search
>>on.
>>
>>Any help?
>>
>>Thanks,
>>
>>Scott
>>
>>
>>
>>
> The 4.00.02b notation is crap, and I can't see any patterns in actual
> use.
It can be useful if you exercise discipline. There are a number of
different patterns in use. They overlap, so with your attitude you
wouldn't be able to discern them. There are no standards, so any
"pattern of use" is up to the authors of the software.
But as soon as Marketing starts using them, they get pretty close to
crap...
> As engineers, we use revision letters for code and for hardware. A piece
> of embedded firmware is 28E346 rev A; the next release is B. All the
> source files are named in the same pattern... assembly source is
> 28E346A.MAC and the associated FPGA config file might be 28C346A.RBT.
> The shippable binary might be 28E346A.ROM.
>
> A hardware top assembly could be 28A346-3B, where -3 is a version
> (literally the "dash number") and B is the rev. This is basic aerospace
> notation.
>
> Before it defines a product, hardware and firmware documentation is
> formally released to the company library, with a genuinely useful README
> file, which library is where manufacturing always gets stuff from. And
> it's all tested *before* it's released!
>
> We also require that all software tools be identified, version
> controlled, and released to the library too. So 10 years from now we can
> run one batch file to regenerate the whole build, and know we'll get
> exactly the same firmware, byte for byte.
_Any_ revision control system is only as good as the discipline and
integrity of the people running it. If someone in the decision chain
decides to chip rev B even though it's crap and no one can replicate it,
then the "A, B, C" rev system becomes crap. If _everyone_ in the
decision chain decides to do their job right then a "number, dot" system
will work just as well as an "A, B, C" system.
So I don't buy your assertions in the least.
John Larkin
A dash number distinguishes an assembly option. This might be a board
stuffing version, a firmware difference (enabling a feature, for
example) or some other variant.
An assembly drawing might be 22A375 rev B. The product might be sold
with SMB, SMA, or LEMO connectors. So we might sell physical items
22A375-1B, 22A375-2B, and 22A375-3B. If we revise the PC board, the
assembly drawing and the associated products would roll to rev C. Note
that drawings don't have dash numbers, they describe dash numbers.
Physical parts have dash numbers.
A 22A375-3C gadget may well have some features that the 22A375-3B
didn't. We try to keep later revs supersets of older ones, so that
existing customers can buy the newer revs and not have problems.
In the aircraft industry, and odd dash numbered thing (like part
12345-1A) was a part, and the following even dash number 12345-2A was
its mirror image. We don't build airplanes, so we just use sequential
dash numbers to identify versions of a basic assembly.
An assembly or fabrication drawing, unless otherwise noted, assumes
"-1 shown". A flag note on that drawing might say "for -2, drill 0.125
thru, 4 places." For electronic assemblies, dash numbers are usually
just associated with different BOM's (parts lists), so that we can
just release a new parts list to create a new dash number at any time,
without having to revise the released assembly drawing.
We use dash numbers for customer-specific versions, too. 22A375-11B
might be a standard version with an ECO applied.
All the above is pretty much mil/aerospace standard documentation
control.
Lots of people use the next available integer for the drawing number
of anything that's drawn. Then they need some side mechanism, like a
product structure document, to correlate things. We use
22A375 assembly drawing. "22" is our VME series.
A customer might order a "V375" module.
22D375 pc fab ("drill") drawing
22M375 front panel fab. M = mechanical fab dwg
22M376 cover plate fab maybe
22R375 reference drawing, design notes maybe
22E375 embedded firmware. Source is 22E375C.MAC;
obj is 22E375C.ROM
22C375 FPGA design. Config file is 22C375A.RBT
like that. It keeps things together.
Everything is formally released, archived, backed up. 10 years later,
we know exactly what was built when, and can build exact copies if we
need to.
John
John Larkin
What you describe is closer to the fuzzy 2.10.04b software convention.
The mil/aerospace drawing control procedure isn't so much focussed on
functionality or features, but rather in documenting *precisely* what
was built, assuring the we understand the exact configuration of every
unit in the field, and guaranteeing that we can *exactly* replicate,
down to the last byte and tie-wrap, any previously built item.
Anything less can kill people.
John
John Larkin
wrote:
It can be much worse, though.
If someone in the decision chain
>decides to chip rev B even though it's crap and no one can replicate it,
>then the "A, B, C" rev system becomes crap.
Only manufacturing builds and ships stuff. They get their docs only
from the company library. Stuff gets into the library only by formal
release. There are no sneak paths.
If _everyone_ in the
>decision chain decides to do their job right then a "number, dot" system
>will work just as well as an "A, B, C" system.
>
>So I don't buy your assertions in the least.
Most programmers like to simply toss the whole version control issue
into a big automated VCS/SCM/bug tracking database thing. Lots of
programmers are continually checking things in and out, changing
stuff, and at some point marketing/management can't stand it any
longer and spins off a release.
I wonder if the VCS itself can still be run 10 years later. I guess it
doesn't matter, since hardly anybody supports 10-year old software. We
sure as hell have to support 10-year old products, hardware and
firmware included.
One important aspect of our doc control system is that nobody in the
decision chain gets to arbitrarily ship selected code revs on any
given hardware platform. Each shippable item is fully documented and
controlled, and only a formally released ECO, signed by the President,
allows exceptions.
This isn't hard to do. It's easy, considering the confusion that will
result from not doing all this right.
John
Tim Wescott
At your company, perhaps yes.
> If _everyone_ in the
>>decision chain decides to do their job right then a "number, dot" system
>>will work just as well as an "A, B, C" system.
>>
>>So I don't buy your assertions in the least.
>
> Most programmers like to simply toss the whole version control issue
> into a big automated VCS/SCM/bug tracking database thing. Lots of
> programmers are continually checking things in and out, changing stuff,
> and at some point marketing/management can't stand it any longer and
> spins off a release.
At a poorly-run company, yes.
> I wonder if the VCS itself can still be run 10 years later. I guess it
> doesn't matter, since hardly anybody supports 10-year old software. We
> sure as hell have to support 10-year old products, hardware and firmware
> included.
>
> One important aspect of our doc control system is that nobody in the
> decision chain gets to arbitrarily ship selected code revs on any given
> hardware platform. Each shippable item is fully documented and
> controlled, and only a formally released ECO, signed by the President,
> allows exceptions.
>
> This isn't hard to do. It's easy, considering the confusion that will
> result from not doing all this right.
>
> John
So, let's change the venue, and reiterate what you're saying, and analyze
it's validity:
"Apples are picked in the next farm over from me, placed in wicker
baskets and hand carried to the farm stand. I buy them and they taste
delicious."
"Oranges are picked all the way over there in Florida, put into cardboard
crates along with sharp rocks, and are shipped by unsprung trucks on dirt
roads. Then they are tossed off of these trucks into my local
supermarket's produce aisle. I buy them and they are bruised up and
taste terrible."
"Therefore stuff that comes in crates is crap and stuff that comes in
wicker baskets is excellent."
Does that sound like your claim?
So I agree with your _evidence_, but I disagree with your _conclusion_.
You may as well say that because you paint your office blue that only
blue-painted offices can generate high quality work.
If you have a software code base that has more than a couple of dozen
source files and more than one developer, then you simply aren't going to
be able to adequately keep track of modifications with anything other
than a good version control system. The stack-o-floppies works for one
or two source files and one developer, but even then it works if and only
if discipline is exerted in the development and archiving process.
(Note that I _always_ use version control for all my client's projects,
even though I'm the only developer and some of my client's code bases are
only a few files).
Trying to maintain any sort of order in a software development effort
that has multiple source files and multiple developers _without_ a good
version control system is damn near impossible. If your source is
distributed between a dozen people and resides on multiple directories,
floppies, CDs, and memory sticks, then you'll never build the same thing
twice, and you'll never get a coherent handle on what you're doing.
I would contend -- totally opposite of your assertion -- that you cannot
produce high quality software above a certain size _without_ a VCS. But
then, I think that if you tried it with the pile-o-floppy method and the
level of discipline that you rightly require, you'd figure this out
pretty quickly.
What gets you your high quality is the discipline that you exert. The
language of the labeling is as superficial as the color of paint on your
walls.
John Larkin
wrote:
We manage software the same way we manage hardware, with the same
revision control procedures, the same release procedures, the same
rules, the same numbering system. We require that every shipped
product will be exactly reproducable and maintainable for decades.
Since disciplined hardware configuration management has been solidly
successful for 60 years or so, and is mandatory when lives and
gigabucks are involved, why not?
Thank goodness that most embedded product programs don't need an army
of programmers and a VCS to keep them under control.
John
John Mianowski
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> What you describe is closer to the fuzzy 2.10.04b software convention.
No surprise, that's where I come from ;-)
That's also what OP was asking about. I tried to give him an example
where I know with certainty, why it was done the way it was, because I
was heavily involved.
> The mil/aerospace drawing control procedure isn't so much focused on
> functionality or features, but rather in documenting *precisely* what
> was built, assuring the we understand the exact configuration of every
> unit in the field, and guaranteeing that we can *exactly* replicate,
> down to the last byte and tie-wrap, any previously built item.
> Anything less can kill people.
No argument, & I can certainly understand & appreciate the need to do
it that way. I'm always glad such systems are in place when I have to
trust my life to equipment provided by the lowest bidder!
JM
John Devereux
> On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux
> <jo...@devereux.me.uk> wrote:
>
>>John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:
>>
>>> A hardware top assembly could be 28A346-3B, where -3 is a version
>>> (literally the "dash number") and B is the rev. This is basic
>>> aerospace notation.
>>
>>How do you define the difference between a "version" and a "revision"?
>>
>>Are all version 3 products interchangeable, for example?
>
> A dash number distinguishes an assembly option. This might be a board
> stuffing version, a firmware difference (enabling a feature, for
> example) or some other variant.
>
> An assembly drawing might be 22A375 rev B. The product might be sold
> with SMB, SMA, or LEMO connectors. So we might sell physical items
> 22A375-1B, 22A375-2B, and 22A375-3B. If we revise the PC board, the
> assembly drawing and the associated products would roll to rev C.
Do the revision letters *all* get bumped up together for all
"drawings"? For example if you modify the PCB, does the version letter
of the front panel get changed too? (I would assume not). Or just the
assembly drawing and the pc board?
Cool, thanks. (I do need to improve our own procedures, so find this
stuff interesting).
--
John Devereux
John Larkin
<jo...@devereux.me.uk> wrote:
>John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:
>
>> On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux
>> <jo...@devereux.me.uk> wrote:
>>
>>>John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:
>>>
>>>> A hardware top assembly could be 28A346-3B, where -3 is a version
>>>> (literally the "dash number") and B is the rev. This is basic
>>>> aerospace notation.
>>>
>>>How do you define the difference between a "version" and a "revision"?
>>>
>>>Are all version 3 products interchangeable, for example?
>>
>> A dash number distinguishes an assembly option. This might be a board
>> stuffing version, a firmware difference (enabling a feature, for
>> example) or some other variant.
>>
>> An assembly drawing might be 22A375 rev B. The product might be sold
>> with SMB, SMA, or LEMO connectors. So we might sell physical items
>> 22A375-1B, 22A375-2B, and 22A375-3B. If we revise the PC board, the
>> assembly drawing and the associated products would roll to rev C.
>
>Do the revision letters *all* get bumped up together for all
>"drawings"? For example if you modify the PCB, does the version letter
>of the front panel get changed too? (I would assume not). Or just the
>assembly drawing and the pc board?
We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
assembly) together. Not everybody does that, but we find it cleaner.
Some people consider a kluged rev B to be the same as a rev C with the
kluges incorporated.
We don't rev a front panel or a bracket unless it needs to be changed.
So a VME module rev D has pcb fab rev D and pcb assembly D, but may
still call out front panel fab A. That's all on the parts list.
A complex assembly, like a rackmount thing, could have multiple
subassemblies, all at verious revs. In that case, we roll the top
assembly rev letter if the form/fit/function of the main box changes
significantly.
When we test/ship anything, our test department logs all the relevant
rev letters and firmware versions for future reference.
I learned all this from having to do MIL stuff. It must be formally
documented somewhere.
John
John Devereux
[...]
> We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
> assembly) together. Not everybody does that, but we find it cleaner.
> Some people consider a kluged rev B to be the same as a rev C with the
> kluges incorporated.
I suppose the problem with your way is if the "pcb etch" letter
appears on the artwork (so that it ends up printed on the board).
> We don't rev a front panel or a bracket unless it needs to be changed.
> So a VME module rev D has pcb fab rev D and pcb assembly D, but may
> still call out front panel fab A. That's all on the parts list.
>
> A complex assembly, like a rackmount thing, could have multiple
> subassemblies, all at verious revs. In that case, we roll the top
> assembly rev letter if the form/fit/function of the main box changes
> significantly.
>
> When we test/ship anything, our test department logs all the relevant
> rev letters and firmware versions for future reference.
>
[...]
> I learned all this from having to do MIL stuff. It must be formally
> documented somewhere.
>
> John
>
--
John Devereux
Richard Henry
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux
>
Providing that you still have a computer that can read 5.25" disks.
krw
f406e9...@r36g2000prf.googlegroups.com>, pome...@hotmail.com
says...>
Well, genius, most are smart enough to migrate their business
critical data to new systems when the old get replaced.
Phil Hobbs
> On Sun, 07 Dec 2008 12:09:52 -0800, John Larkin wrote:
>> I wonder if the VCS itself can still be run 10 years later. I guess it
>> doesn't matter, since hardly anybody supports 10-year old software. We
>> sure as hell have to support 10-year old products, hardware and firmware
>> included.
>>
>> One important aspect of our doc control system is that nobody in the
>> decision chain gets to arbitrarily ship selected code revs on any given
>> hardware platform. Each shippable item is fully documented and
>> controlled, and only a formally released ECO, signed by the President,
>> allows exceptions.
>>
>> This isn't hard to do. It's easy, considering the confusion that will
>> result from not doing all this right.
> I would contend -- totally opposite of your assertion -- that you cannot
> produce high quality software above a certain size _without_ a VCS. But
> then, I think that if you tried it with the pile-o-floppy method and the
> level of discipline that you rightly require, you'd figure this out
> pretty quickly.
>
> What gets you your high quality is the discipline that you exert. The
> language of the labeling is as superficial as the color of paint on your
> walls.
>
I don't like the Linux-style version numbering either, but it has the
advantage of giving each of probably thousands of builds a unique
identifier.
I use git for version control of everything. I standardized on it a
couple of years ago--previously I used a set of scripts to generate
zipfiles from file lists, which worked fine since almost all my stuff is
done solo. I use it for code, schematics, docs, books, articles, patent
disclosures, drawings, just about everything.
git is amazingly fast and easy to use, runs on most platforms (though
you do need cygwin if you're running Windows), and--crucially--is easy
to debug and back up.
Backing up the tools is a bit more problematical, though--you often need
the right OS revision as well, due to API and library changes. That's
one of the wonders of self-contained, statically linked executables--no
library worries. All my simulation apps are console-based for the same
reason.
Cheers,
Phil Hobbs
Tim Wescott
Good for you. An old employer of mine that I still occasionally work
for treats mechanical design work as real engineering, electrical design
work as slightly mysterious real engineering, and software design work
as strange, wacky black magic that can only be done under the light of a
lunar eclipse with the aid of a freshly dead chicken.
Hence, when a mechanical guy has a preliminary design review everyone
shows up with the expectation that they'll understand what's said, when
an electrical guy has a design review everyone shows up with the
expectation that they'll understand what's said, and when a software guy
has a review only software people show up -- if you can drag them away
from coding long enough to do so.
Drives me up the wall.
> We require that every shipped
> product will be exactly reproducable and maintainable for decades.
Good for you.
> Since disciplined hardware configuration management has been solidly
> successful for 60 years or so, and is mandatory when lives and
> gigabucks are involved, why not?
>
> Thank goodness that most embedded product programs don't need an army
> of programmers and a VCS to keep them under control.
The process that seems to work when you have "big" embedded software is
to use the VCS and the platoon (_not_ army) of developers to generate
release candidates, release the binary image through the same part
numbering system that you speak of, and keep the VCS up to date (through
discipline, again) in the background to insure reproducible code.
Part of this is done by never, ever, letting a developer submit a binary
image for release -- you go out and hire at least one person who knows
how to start a build, but doesn't want to play with the code. Their job
is to build and test software, and to kick the developer in the shins if
it doesn't build or test out. If they can't check code out of the VCS
into a virgin directory, build it and have it work, then the software is
broken -- with no allowance for the developer insisting on special
gyrations to make that particular build work.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
Joel Koltner
news:8f4bbb1b-c188-4ede...@r36g2000prf.googlegroups.com...
"Providing that you still have a computer that can read 5.25" disks."
These days I suspect the best approach to "archiving" a system would be to
create a virtual machine with all the tools installed.
Although as Joerg/Tim point out, there's still a problem if any of it is
dongled.
Where I work our hardware releases are just "vX.YZ" where changes in X refer
to new physical PCBs and changes in Y usually refer to some "significant"
hacks (blue-wires -- or drilling out holes or something for mechanical pieces)
on the board whereas changes and in Z usually refer to component value
changes.
For software, we don't have any real standard, although I've generally a
proponent of just stick a timestamp (full date & time) on the release -- which
can be easily automated with the build tools. This completely eliminates the
very common problem where someone finds a bug, some programmer fixes it (or at
least attempts to), providers a test with a new binary... but the binary still
claims to be the exact same version number as the buggy release. :-(
Richard Henry
> In article <8f4bbb1b-c188-4ede-b2de-
> f406e934a...@r36g2000prf.googlegroups.com>, pomer...@hotmail.com
"Only wimps use tape backup; *real* men just upload their important
stuff on
FTP, and let the rest of the world mirror it ;)" -- Linus Torvalds
RST Engineering (jw)
> I use git for version control of everything. I standardized on it a
> couple of years ago--previously I used a set of scripts to generate
> zipfiles from file lists, which worked fine since almost all my stuff is
> done solo. I use it for code, schematics, docs, books, articles, patent
> disclosures, drawings, just about everything.
>
> git is amazingly fast and easy to use, runs on most platforms (though you
> do need cygwin if you're running Windows), and--crucially--is easy to
> debug and back up.
What is git?
Jim
Paul Carpenter
k...@att.zzzzzzzzz says...
> In article <8f4bbb1b-c188-4ede-b2de-
> f406e9...@r36g2000prf.googlegroups.com>, pome...@hotmail.com
> says...>
> > On Dec 7, 11:46 am, John Larkin
> > <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> > > On Sun, 07 Dec 2008 17:01:23 +0000, John Devereux
> > >
> > > <j...@devereux.me.uk> wrote:
> > > >John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> writes:
> > >
> > > >> A hardware top assembly could be 28A346-3B, where -3 is a version
> > > >> (literally the "dash number") and B is the rev. This is basic
> > > >> aerospace notation.
> > >
> > > like that. It keeps things together.
> > >
> > > Everything is formally released, archived, backed up. 10 years later,
> > > we know exactly what was built when, and can build exact copies if we
> > > need to.
> > >
> > > John
> >
> > Providing that you still have a computer that can read 5.25" disks.
>
> Well, genius, most are smart enough to migrate their business
> critical data to new systems when the old get replaced.
Migrating code for tools no longer manufactured/sold actually means
that the simpler and cost effective solution for some markets is
actually to archive complete computer systems as changing the tools
means revalidation/certification. Even if you could get the new versions
of tools to work with newer computers/operating systems/etc..
Especially if you have last time buy on components even at wafer
level because you are making parts for aircraft, classic examples
would be
Boeing 747
C130 (Hercules in UK)
Nimrod (originally Comet airframe circa late 1950's)
Having recently looked at some testing equipment that has to work for
at least 10 years, I am aware of the issues and multiple paper/CD/network
storage of documents etc..
--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
John Devereux
I use it too.
I agree is it very fast and efficient - so much so that I am
considering adding all my tools to the version control, as well as the
"documents" (source code, schematics etc).
> What is git?
<http://www.google.com/search?&q=git>
--
John Devereux
Phil Hobbs
it at http://git.or.cz/.
Cheers,
Phil Hobbs
krw
@r15g2000prh.googlegroups.com>, pome...@hotmail.com says...>
Once again, RH shows his infinite ignorance.
krw
pa...@pcserviceselectronics.co.uk says...>
No one specified code, though that is a bigger problem. How much
bigger depends on the tools (another vote for VHDL vs. schematic,
IMO).
> Especially if you have last time buy on components even at wafer
> level because you are making parts for aircraft, classic examples
> would be
If you're in a lifetime buy situation the tools don't matter,
however documentation still matters.
> Boeing 747
> C130 (Hercules in UK)
> Nimrod (originally Comet airframe circa late 1950's)
Why single them out?
> Having recently looked at some testing equipment that has to work for
> at least 10 years, I am aware of the issues and multiple paper/CD/network
> storage of documents etc..
Why is test equipment a problem?
Richard Henry
wrote:
> In article <MPG.23a706ae1955768d989...@news.individual.net>,
> k...@att.zzzzzzzzz says...
>
>
>
>
>
> > In article <8f4bbb1b-c188-4ede-b2de-
> <http://www.pcserviceselectronics.co.uk/> PC Services
> <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
> <http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
>
> - Show quoted text -
In my first job, all released documents were paper, even computer
source-code listings which would be impractical to retype and unlikely
to be redone without error. PCB artwork soource documents were hand-
taped vellum.
In my last job, all released documents were electronic files archived
on the local network, backed up on the corporate network across the
country, and periodically archived on "tape" at a local disaster
backup business. Most documents produced were part of the natural
design flow (schematic diagrams, part lists (with some massaging), PCB
artwork "Gerber" files, FPGA source code, etc). The most difficult
and time-consuming documents to produce were Source Control Documents,
a way of assigning our part number to someone else's product, which
usually consisted of a cover sheet followed by pages copied from a
vendor data sheet or catalog.
John Larkin
<jo...@devereux.me.uk> wrote:
>John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:
>
>
>[...]
>
>> We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
>> assembly) together. Not everybody does that, but we find it cleaner.
>> Some people consider a kluged rev B to be the same as a rev C with the
>> kluges incorporated.
>
>I suppose the problem with your way is if the "pcb etch" letter
>appears on the artwork (so that it ends up printed on the board).
That's not a problem, it's a feature!
John
John Larkin
Everything is released to the library server, a big RAID thing. We do
nightly backups to another server and weekly DVD backup, stored in
multiple off-sites.
We submit files to the librarian on floppies or CDs, and after the
files are copied those originals are also stored off-site. We have had
media go obsolete, like tapes, and we always make sure we have good
copies on current-generation media.
We have had a few files corrupted on the server, not many, and it was
easy to recover them from backups. Our inventory database file has
been in continuous use for over 10 years.
I do have some old 8" floppies that might be hard to read.
John
Joerg
[...]
> In the aircraft industry, and odd dash numbered thing (like part
> 12345-1A) was a part, and the following even dash number 12345-2A was
> its mirror image. We don't build airplanes, so we just use sequential
> dash numbers to identify versions of a basic assembly.
>
Then I wonder what the mirror of the Dash-8 was :-)
http://www.airliners.net/aircraft-data/stats.main?id=121
[...]
--
SCNR, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Joerg
You almost have to, at least if there is as much as one little iota in
assembly change cause by the artwork change. With assembly rev changes
the PCB rev does not need to change, and often doesn't in my cases.
[...]
>
> I learned all this from having to do MIL stuff. It must be formally
> documented somewhere.
>
Same in medical. If the federales waltz in for a spot check you have x
minutes to produce a requested document such as a design history for the
inspector. With "x" being single-digit.
--
Regards, Joerg
Michael A. Terrell
I have a couple half height 8" drives in storage. I saved them,
because they were some of the last built, and have all DC motors.
--
http://improve-usenet.org/index.html
aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.
If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm
There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you're crazy.
Joerg
... and pretty much all the clients I work for. Else I would most likely
decline to consult for them. Without a formal release process you'd be
only a few footsteps away from a major lawsuit should something happen.
Because plaintiff's counsel will dig that out.
[...]
John Devereux
Aha. I see!
--
John Devereux
Paul Carpenter
says...
> John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:
>
>
> [...]
>
> > We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
> > assembly) together. Not everybody does that, but we find it cleaner.
> > Some people consider a kluged rev B to be the same as a rev C with the
> > kluges incorporated.
>
> I suppose the problem with your way is if the "pcb etch" letter
> appears on the artwork (so that it ends up printed on the board).
>
I often use two+ digit revisions for circuit etch/revisions
A original etch and circuit match
A1 Etch level A modified to circuit rev A1
B Etch level B rollup match circuit Rev B
To facilitate this the ident layer has etch and circuit rev shown
as letter for etch and white block for circuit rev added as part of
the manufacturing/testing process.
Make sure I keep reference of what revisions are shipped.
--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
Paul Carpenter
There is no point archiving data that is in 90% of the time (or more)
anything other than plain text, without the tools to read it, even if
it is just to print out new copies.
Any archiving is for evaluations and possible modifications later, this
could be many years later, that you need to rebuild then modify code
for software, FPGA or even modelling of circuits or pcbs in electronic
form. In some cases it is to prove again that the design process is
modelled correctly or run scenarios on old simulators first.
> > Especially if you have last time buy on components even at wafer
> > level because you are making parts for aircraft, classic examples
> > would be
>
> If you're in a lifetime buy situation the tools don't matter,
> however documentation still matters.
Yes they do as any part may have to be modified later and
progrrammable parts may need revised coding, even parts on wafer
need alternative packaging requirements for later batches that
then means a new PCB or even heatsink arrangements.
> > Boeing 747
> > C130 (Hercules in UK)
> > Nimrod (originally Comet airframe circa late 1950's)
>
> Why single them out?
They were not singled out, but as it showed above "classic examples".
I could have used many others.
One classic I had about 5 years ago was for an NMR scanner, where
I was looking at replacing a failing part of it, and the EARLIEST
date they could find for the machine was
"...in 1968 it moved to the NEW building.."
>
> > Having recently looked at some testing equipment that has to work for
> > at least 10 years, I am aware of the issues and multiple paper/CD/network
> > storage of documents etc..
>
> Why is test equipment a problem?
Over the last 10 years more and more test equipment and test procedures
are computer controlled so the test equipment, procedures, test
programmes, and ancillary equipment, needs to be documented and archived.
Test equipment and for testing various parts, subsystems, or systems
sometimes requires dedicated testing equipment. This is part of the
manufacturing process. All parts of the procedures and methods from basic
pcb, loading code to test procedures or programme controlled tests, needs
to be archived and maintained. EVEN IF THE UNIT IS THIRD PARTY PURCHASE.
Changes in these also have to be reverified and ecrtified on changes,
some of which are due to equipment changes, others due to testing
modifications.
Four of my designs over the last two years are specialised ASIC
testers, and I have more to do in the pipeline.
John Larkin
<pa...@pcserviceselectronics.co.uk> wrote:
>In article <87oczmf...@cordelia.devereux.me.uk>, jo...@devereux.me.uk
>says...
>> John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> writes:
>>
>>
>> [...]
>>
>> > We roll the rev letter of the "D" drawing (pcb etch) and "A" (pcb
>> > assembly) together. Not everybody does that, but we find it cleaner.
>> > Some people consider a kluged rev B to be the same as a rev C with the
>> > kluges incorporated.
>>
>> I suppose the problem with your way is if the "pcb etch" letter
>> appears on the artwork (so that it ends up printed on the board).
>>
>
>I often use two+ digit revisions for circuit etch/revisions
>
> A original etch and circuit match
> A1 Etch level A modified to circuit rev A1
>
> B Etch level B rollup match circuit Rev B
>
>To facilitate this the ident layer has etch and circuit rev shown
>as letter for etch and white block for circuit rev added as part of
>the manufacturing/testing process.
>
>Make sure I keep reference of what revisions are shipped.
That's not bad at all. Full MIL standards require an ECO to change
something, so your "A1" becomes "assy 12345-1A ECO 1412 ECO 1618",
with labels stuck on the poor thing somehow.
We are rarely forced to revise a drawing but keep it coherent with
other rev B drawings, so we re-issue it as rev B1. This is generally
to correct a drawing error.
John
Joerg
Not so. I once was called to a new client. The new design wasn't what
they tasked me with (but that happened immediately after this initial
job ...). They were way behind schedule, trade show coming up, so the
only avenue to save the bacon was to gussy up an old system. A really,
really old one. So I plunged in. Later in the day I presented my
findings to the CTO. Found out that a math function was completely
"missing" on a board where it definitely should have been. "What?!!" He
turned pale. Now came the real issue. This board hadn't been touched in
a decade or so, the SW guy was long gone but we managed to find him in a
phone book. Whew! Next night he agreed to come in. Luckily he brought a
stone-age compiler and computer that was able to read in the source
code. The reason we couldn't read any of the archives was that it needed
to be done under CP/M. I almost couldn't believe it. If they hadn't
archived those ancient files the trade show would have been gone and the
CEO mad as hell.
> Any archiving is for evaluations and possible modifications later, this
> could be many years later, that you need to rebuild then modify code
> for software, FPGA or even modelling of circuits or pcbs in electronic
> form. In some cases it is to prove again that the design process is
> modelled correctly or run scenarios on old simulators first.
>
>>> Especially if you have last time buy on components even at wafer
>>> level because you are making parts for aircraft, classic examples
>>> would be
>> If you're in a lifetime buy situation the tools don't matter,
>> however documentation still matters.
>
> Yes they do as any part may have to be modified later and
> progrrammable parts may need revised coding, even parts on wafer
> need alternative packaging requirements for later batches that
> then means a new PCB or even heatsink arrangements.
>
>>> Boeing 747
>>> C130 (Hercules in UK)
>>> Nimrod (originally Comet airframe circa late 1950's)
>> Why single them out?
>
> They were not singled out, but as it showed above "classic examples".
> I could have used many others.
>
> One classic I had about 5 years ago was for an NMR scanner, where
> I was looking at replacing a failing part of it, and the EARLIEST
> date they could find for the machine was
>
> "...in 1968 it moved to the NEW building.."
>
ROFL! That is amazing.
John Larkin
wrote:
VCS is OK with me (one of my guys uses one) as long as each formal
release is exported and released as a self-contained package of
sources, scripts, and tools, sufficient to do a full build without the
VCS.
Personally, I can control my revs and versions without one. Sometimes
we pass a file-ownership token between guys. It's a piece of wood with
TOKEN painted on.
John
Paul Carpenter
notthis...@removethispacbell.net says...
Well actually if you think about you have proved my point, that the
customer was lucky that SOMEBODY had archived the tools and systems
otherwise the data was almost useless.
John Larkin
We do archive tools to a server, which gets weekly backups. And we
rolled all our old DOS PADS jobs forward into the newer Windows format
before we retired the DOS machines.
We also release duplicate PDFs of drawings in proprietary formats, so
that anyone can see them, roughly forever.
John
krw
jjla...@highNOTlandTHIStechnologyPART.com says...>
Do test the entire process on every OS release and hardware
upgrade?
> We also release duplicate PDFs of drawings in proprietary formats, so
> that anyone can see them, roughly forever.
That's the minimum that should be done. I'll have to see what
we're doing along those lines. At least there is a manual path
back from "disaster".
Joerg
It would not have been useless. I would have searched and searched until
the old SW tool and a contractor with the necessary skills are found.
Jim Thompson
>Paul Carpenter wrote:
>> In article <C2k%k.6422$hc1....@flpi150.ffdc.sbc.com>,
>> notthis...@removethispacbell.net says...
[snip]
>>
>> Well actually if you think about you have proved my point, that the
>> customer was lucky that SOMEBODY had archived the tools and systems
>> otherwise the data was almost useless.
>>
>
>It would not have been useless. I would have searched and searched until
>the old SW tool and a contractor with the necessary skills are found.
Counting on old SW tools running on a modern PC, with who knows what
variant of Wimpows, is very dangerous.
While I do maintain archives in native SW language, I also archive
device model and symbol libraries (text), netlists (text) and PDF
versions of all schematics.
I would hate to have to re-enter such stuff into a new SW, but I have
done it... like some ancient SDT III stuff for which the symbol
libraries went bye-bye :-(
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona 85048 Skype: Contacts Only | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
I love to cook with wine Sometimes I even put it in the food
John Larkin
No. Whenever the tools change, we dump another set into the M:\TOOLS
folder, where the M-drive is our library server. That's probably
enough to untange the mess if we really need to go back and rebuild an
ancient software product.
All my assembly stuff uses batch files and programs that run under DOS
or the Windows command line. That includes a few homebrew things that
we have the source code for. So far, I've been able to rebuild 10-12
year old stuff with no problems.
I won't let any of my guys use tools that we can't archive and be
reasonably sure we can run a decade or two into the future. If they
use a VCS, each formal release must be a set of clean files, all on
its own, independent of the VCS. And the next rev must start from
those released files, not from what the VCS thought the last formal
release was. KISS.
John
Joerg
> On Tue, 09 Dec 2008 08:04:34 -0800, Joerg
> <notthis...@removethispacbell.net> wrote:
>
>> Paul Carpenter wrote:
>>> In article <C2k%k.6422$hc1....@flpi150.ffdc.sbc.com>,
>>> notthis...@removethispacbell.net says...
> [snip]
>>> Well actually if you think about you have proved my point, that the
>>> customer was lucky that SOMEBODY had archived the tools and systems
>>> otherwise the data was almost useless.
>>>
>> It would not have been useless. I would have searched and searched until
>> the old SW tool and a contractor with the necessary skills are found.
>
> Counting on old SW tools running on a modern PC, with who knows what
> variant of Wimpows, is very dangerous.
>
Nope. All the DOS stuff I still need does run on all machines here. Of
course there is no Vista in this here consulting office.
Other trick: I recently installed Sun VirtualBox. That allows multiple
virtual machines. If the Romans had any operating system even that would
probably run. I tried Linux on it and when clicking that tab the whole
Windows PC feels like a Linux PC. Nice thing is, after some tricks you
can effortlessly scoot back and forth between OS'es and even copy-paste
across platforms.
So far the only thing that presented a bump in the road to backward
compatibility was that old Borland runtime bug. But there is a massaging
routine you can send your *.exe through that will fix it even if you
don't have the source code for a re-compile.
> While I do maintain archives in native SW language, I also archive
> device model and symbol libraries (text), netlists (text) and PDF
> versions of all schematics.
>
Same here.
> I would hate to have to re-enter such stuff into a new SW, but I have
> done it... like some ancient SDT III stuff for which the symbol
> libraries went bye-bye :-(
>
You mean, you "lost" the symbol libraries?
When I have my druthers I might fire up ye olde SDT-III again. It was
one of the best products since sliced bread.
Joel Koltner
news:uh6tj41eru4k0e0l9...@4ax.com...
> I won't let any of my guys use tools that we can't archive and be
> reasonably sure we can run a decade or two into the future.
I think that rules out most Microsoft compilers? :-)
On Windows Vista, nothing prior to Visual Studio 2005 is officially
supported... although it turns out that Visual Studio 6 from 1998 will 99%
work with very minor workarounds. Of course, those workarounds are not found
on Microsoft's web site :-( ...but Google knows where they are.
> If they
> use a VCS, each formal release must be a set of clean files, all on
> its own, independent of the VCS. And the next rev must start from
> those released files, not from what the VCS thought the last formal
> release was. KISS.
That's an entirely reasonable process that I doubt anyone would object to. I
believe in "management by interfaces" -- use whatever tools you feel like, but
when it comes time to release, we have a well-defined "interface" that says
what your code has to do... or, in your case, how the code needs to be built.
---Joel
John Devereux
VirtualBox is great. I use it "the other way round", i.e. linux host,
windows guest(s). I do all my "windows" development and testing on it
(Visual C++). You can also have all the different windows variants
installed as separate images for software testing. When you have
finished testing, just roll it back to the virginal "snapshot" for
next time.
[...]
--
John Devereux
David Brown
I use both Windows and Linux guests in VirtualBox (on a Windows host).
If you've got two Ethernet ports on your host PC, a cunning trick is to
set up a bridge on the host with the second Ethernet port, and connect
the port physically to your network. Then make host interfaces in
VirtualBox and connect them to the bridge, and use them instead of NAT
to your host. It gives you a much more direct networking connection.
John Devereux
> John Devereux wrote:
>> Joerg <notthis...@removethispacbell.net> writes:
>>
[...]
>>>
>>> Other trick: I recently installed Sun VirtualBox. That allows multiple
>>> virtual machines. If the Romans had any operating system even that
>>> would probably run. I tried Linux on it and when clicking that tab the
>>> whole Windows PC feels like a Linux PC. Nice thing is, after some
>>> tricks you can effortlessly scoot back and forth between OS'es and
>>> even copy-paste across platforms.
>>
>> VirtualBox is great. I use it "the other way round", i.e. linux host,
>> windows guest(s). I do all my "windows" development and testing on it
>> (Visual C++). You can also have all the different windows variants
>> installed as separate images for software testing. When you have
>> finished testing, just roll it back to the virginal "snapshot" for
>> next time.
>>
>
> I use both Windows and Linux guests in VirtualBox (on a Windows
> host). If you've got two Ethernet ports on your host PC, a cunning
> trick is to set up a bridge on the host with the second Ethernet port,
> and connect the port physically to your network. Then make host
> interfaces in VirtualBox and connect them to the bridge, and use them
> instead of NAT to your host. It gives you a much more direct
> networking connection.
I have not needed to delve into the networking yet - everything seems
to work fine as it is. I did create a shared folder link so that my
linux home directory appears as a drive letter in VirtualBox.
I was surprised how good the hardware support is. It creats some kind
of "virtual" USB controller, so you can use any USB device with the
manufacturers drivers.
I also use the "headless" mode where you can connect using a remote
desktop ("rdesktop") session. So I can be working in the office, then
move to the "lab" machine and carry on using that same session.
--
John Devereux
David Brown
A networking setup like mine is particularly useful if the host is
windows. Linux has vastly more networking tools, so my VirtualBox setup
lets me run these in a virtual Linux box (the NAT networking can't pass
anything other than UDP and TCP/IP packets - no pings, arpings, or other
protocols). It is also useful if you want to access the virtual machine
directly on the network from other machines.
> I was surprised how good the hardware support is. It creats some kind
> of "virtual" USB controller, so you can use any USB device with the
> manufacturers drivers.
>
I've found it can be a little unstable at times, but apart from that it
is *very* useful using USB devices in the virtual machines. It's
particularly useful if the drivers for the devices are not too great, or
have conflicting versions, or if you want to test installation routines.
Just make a snapshot of the virtual machine before they are connected,
then try it out. If it doesn't work, you can quickly roll back.
John Devereux
[...]
>
> A networking setup like mine is particularly useful if the host is
> windows. Linux has vastly more networking tools, so my VirtualBox
> setup lets me run these in a virtual Linux box (the NAT networking
> can't pass anything other than UDP and TCP/IP packets - no pings,
> arpings, or other protocols). It is also useful if you want to access
> the virtual machine directly on the network from other machines.
>
>> I was surprised how good the hardware support is. It creats some kind
>> of "virtual" USB controller, so you can use any USB device with the
>> manufacturers drivers.
>>
>
> I've found it can be a little unstable at times, but apart from that
> it is *very* useful using USB devices in the virtual machines. It's
> particularly useful if the drivers for the devices are not too great,
> or have conflicting versions, or if you want to test installation
> routines. Just make a snapshot of the virtual machine before they are
> connected, then try it out. If it doesn't work, you can quickly roll
> back.
Also I don't feel the need to run AV software on the Windows VM, or
keep it continuously updated. Although *theoretically* still needed, I
don't do much browsing or read email from Windows (and when I do it is
with firefox). So that in itself speeds things up enormously.
[...]
--
John Devereux