[Bdi4emc-help] Re: BDI-4.38 suggestions

Fri Dec 30 01:35:00 CET 2005

On Thursday 29 December 2005 15:21, Kent A. Reed wrote:
>Paul, et al.
>
>[<gently ribbing on> What? 4.38? Already?</>]
>
>At least on paper, subversion looks great. If Source Forge is going
> to migrate to it from CVS, then it sounds like your hand will be
> forced soon enough. I lean toward Gene's suggestion that you
> postpone including it until it's needed for updating EMC2 from
> Source Forge, but you know better what including it now or later
> entails.
>
>The recent discussion of features to be included or excluded suggests
> to me that you have some conflicting requirements for the BDI from
> your clientele.
>
>In descending order of priority, my desiderata are (writing EMC/EMC2
> as if they were one animal, which of course they aren't):
>
>1) painlessly install a Linux with real-time extensions on which
>EMC/EMC2 will run
>2) provide the resources to update/maintain this real-time Linux,
>preferably directly via the internet, but indirectly through a
> transfer of packages via CD or flash drive is acceptable if it can
> be managed easily 3) provide an environment in which I can build a
> running copy of EMC/EMC2 from source.
>4) provide the source code for a stable version of EMC/EMC2.

Following up on this train of thought, rather than provide the srcs, 
provide instead a script that will download a known stable version of  
a script to build emc or emc2, which probably is not the current 
cvs/svn.  That way, if a given snapshot builds and runs, then the repo 
is frozen long enough to fine-tune the script, the script is added to 
the wiki, and then the repo is opened up again, what, a  day down the 
log?

Surely this, once a stable bdi install has been done, giving the spare 
room because emc isn't in the iso to include some of our fav editors 
etc in the basic distro iso, and then our choice of whatever is a 
matter of grabbing the right build script from the wiki.  Heck, 
incorporate the script grab right into /etc/rc./rc.local so we'ed have 
the choice of doing it everytime the system was booted.

>5) provide a running copy of EMC/EMC2 "out of the box."

Nice for absolute gnubies, but really, by the time someone comes 
looking for emc, can we not assume they know the basics of building an 
app?  The script itself should be able to handle the dependencies.

Or am I chasing rabbits and barking barking at the moon here?

>Item 1 is the most important for me because I made up my mind early
> on that I don't want to get tangled up in the real-time kernel
> issues and debates.

Neither do I, generally speaking, although this box is always running 
the latest kernel from Linus that will run on this box, currently 
2.6.15-rc7.  Does that place me a cut above the average emc user?  I 
doubt it...

>Item 2 is next most important because there are always updates and
>patches to the kernel and surrounding modules and libraries coming
> down the pike. In principle, my EMC host will never be exposed
> directly to the Internet but it is exposed to the other hosts inside
> my firewall and I like all my hosts to be secure just-in-case.
>
>Item 3 is next most important because it means I can build an running
>copy of EMC/EMC2 from source that might be provided with the BDI or
> that I download / update from Source Forge. Obviously this
> requirement is more important for EMC2 than for EMC since, quoting
> from the Wiki, the latter is "...the old stable version and no major
> improvement will be done here." In any case, I believe you should
> provide an environment that can build the same executables you might
> choose to distribute. This is the essence of the open-source
> movement.
>
>Items 4 and 5 are at the bottom of the list because I can download
> and build a running copy of EMC/EMC2 myself if the system satisfies
> items 1, 2, and 3. It would be nice to be able to exercise EMC/EMC2
> immediately, as I did when I first got hold of BDI-Live a year ago,
> but I don't mind having to build it before I run it, so I ranked the
> provision of source code above the provision of executables, and it
> is included only because then I could build a first working version
> even if the Source Forge servers were temporarily unreachable or the
> EMC/EMC2 source code on the servers were temporarily corrupted, both
> of which have been known to happen.
>
>Based on my list, you can dump anything from the CD that doesn't
>directly support building and running EMC/EMC2. If this gets sticky
>because of the requirements of others (as you put it, "The inclusion
> of subversion in the BDI-4 builds is primarily for the people that
> use BDI-4 for non-EMC development."), then you could push all the
> EMC/EMC2 stuff to a second "application" CD and still meet my needs.
> Indeed, you could simply leave off all the EMC/EMC2 stuff and still
> meet my irreducible need.
>
>Like Gene, I consider all my open-source software and practically
>everything else to be just an Ethernet cable away. The other end of
> that cable is either a cable modem at home or the equivalent of a T3
> service at work, so I don't flinch from downloading what I need (I
> downloaded BDI-4.30 at home without any difficulty and from an
> overseas server to boot).

So did I, as linuxcnc.org wasn't visible that night. 

> Whether or not it all fits on a single CD 
> isn't so terribly important any more, since we're not trying to run
> from it, executing an unattended install from it doesn't seem to be
> a requirement, the discs are cheap, and recording them no longer
> takes all afternoon. From my prespective, a network install of
> everything from a remote server would be fine (but, oh, what a
> headache for the poor guy providing the network servers). After all,
> we're basically doing that now when we install or update EMC/EMC2
> from Source Forge.

Agreed.

>As for editors, I had no problem coping with your solution when I
>installed my BDI. I just downloaded and installed the editor I
> wanted. Between me, my staff, and various visiting professors and
> students, we've tried them all on my systems at work. I never met an
> editor I couldn't complain about :-)

Neither did I, which I guess is the reason I tend to stick with what I 
know on linux, vim.  Or occasionally gvim.  I'd like to see the last 
version of CygnusEd that was published for the amiga ported to linux, 
that was to me, the ideal editor of all editors.  The vi/emacs debate 
would be noise I could cheerfully tune out were this to happen.  
Unforch, a quick check with google fails to even find it for sale to 
run on an amiga today.  Sad state of affairs indeed.

>Just my 2 cents worth. I am already on record as being completely
>satisfied with the effortless install of BDI-4.30 on several
> different cpu/motherboard combinations so all this is in the nature
> of counting how many angels can dance on the head of a pin.

Humm, now thats a question I never felt it was our lot to know the 
answer thereto. :-)

>Regards,
>Kent

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.