Re: another hint of quantum consciousness

On Tue, 17 Sep 2024 04:57:32 GMT, Jan Panteltje <alien@comet.invalid>
wrote:

On a sunny day (Mon, 16 Sep 2024 08:14:49 -0700) it happened john larkin
<JL@gct.com> wrote in <16igejdcnbt2c79g1357ushokss8pt2ugj@4ax.com>:
>

On Mon, 16 Sep 2024 01:21:41 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:
>

On 9/15/2024 12:00 PM, Edward Rawde wrote:

Maybe, but you're likely to find that they attract users who think it will make their lives easier.
Maybe it will at some future time.

>
Few "sizeable" projects are handled by single developers.
VCSs impose order on projects where multiple entities are
examining, correcting and modifying a single document store.
>
This includes provisions to notify folks who happen to be
working with a particular "module" so they are alerted that
someone else has made a change to it; presumably this means
the "new" version now works better (more correctly) than the
version you might be using so its in your best interest to
see what's happened to the module before moving too far
down range.
>
Of course, this only works when there is a discipline imposed on
the development team.  Many people don't like having to play by
"rules" so disdain anything that imposes same.
>
I am tickled when a colleague discovers a problem or an improvement
to a piece of code or a bit of hardware as that saves *me* from
having to make the same discovery (or, worse, risk NOT making it!).
>
It's also an excellent mechanism for rewinding the development
clock to determine where a particular problem crept into the
design.  (We had a problem some years ago when someone made
a presumably simple change to a FET used on one of the boards
that, later, presented problems.  "Why was this change made?
Is the problem because of the change or just brought to light
by it??")
>
It's also a requirement for many structured design policies
(ISO9000, et al.)

>
Software design is different from hardware. Software is less wrecked
by having multiple simultaneous authors.
>
Software is mostly verified by testing and iteration, and is usually
shipped with lots of bugs anyhow. Software bugs are quickly fixable:
hack the code and push out an update. Version 123.17.91b or something.
>
Hardware takes a lot longer to revise and to implement updates in the
field. Much more expensive too. So it's better to have one really good
person be in charge and responsible.
>
The difference is compounded by the trend of having armies of
reasonably skilled programmers around, and precious few decent circuit
designers.

>
At least in my case, with version update of code I wrote,
the new version has more features.
program-0.3 versus program-0.4
or have or support a different target, for example x86 or / and ARM.
Not so many bug fixes...
With hardware itself you may be stuck, but you can bring out a new model :-)
Same as with cars..
>
>
>

We treat a software release package just like any other engineering
document. It has a drawing number and a revision letter.

Why distinguish between a major rev and a minor rev? A change is a
change.