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. 5) provide a running copy of EMC/EMC2 "out of the box." 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. 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). 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. 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 :-) 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. Regards, Kent
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.
Hi Kent & Gene On Thursday 29 December 2005 20:21, Kent A. Reed wrote:
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.
If the EMC developers decide to switch to subversion, I fear they will be shooting themselves in the collective foot. Quite a few users and developers are running RH-7.x systems, and there are a considerable number of RH-6.x installations to boot. Whilst there are subversion.rpm packages available for RH-7.x, you have to go digging for them. For the many running RH-6.x boxes, I suspect the situation will be much worse.
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. 5) provide a running copy of EMC/EMC2 "out of the box."
All the above are amply provided for by Debian's apt tools. apt-get manages equally well with networked repositories, or from CDs. Installing a single package from floppy (or flash drive) would probably require the use of dpkg (the back end to apt-get). Even the sources can be downloaded with apt-get along with any prerequisite build dependencies... [note to self: Fix build deps and generate a source package for emc]
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."
I've not done any significant work with the old EMC tree for the best part of two years now. Most of my efforts have been in a branch of emc2 - The EMC version found on the BDI-4 disk is the result. Although both head and bdi-4 branches share much code in common, most of the user space code is identical, as are core parts of the RT modules, the bdi-4 branch does not use the HAL layer. Think of the BDI-4 build as a staging platform for the time when (if ?) emc2 becomes stable enough for widespread use. Although from what I hear, emc3 may be just round the corner. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
On Friday 30 December 2005 06:45, Paul wrote:
Hi Kent & Gene
On Thursday 29 December 2005 20:21, Kent A. Reed wrote:
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.
If the EMC developers decide to switch to subversion, I fear they will be shooting themselves in the collective foot. Quite a few users and developers are running RH-7.x systems, and there are a considerable number of RH-6.x installations to boot. Whilst there are subversion.rpm packages available for RH-7.x, you have to go digging for them. For the many running RH-6.x boxes, I suspect the situation will be much worse.
I have to disagree with this assessment. IF one is to run emc, then the system should be installed as an emc install, and the Brain Dead Install(er) is very good in this regard. If the machine has sufficient drive resources, then a dual boot is quite feasable and I've done it. At one point I was trying to do that between bdi-4.30 and FC4, but FC4 was such a pita that Sarge got installed over it. My last crash wiped that and I haven't edited the menu.lst to re-add the sarge boot back in, but it hasn't been touched in the bdi re-install, and should still be there on the other drive. As for running all the emc stuff on a rh6 box, I wouldn't consider it for more than the second it takes me to recall how insecure 6 was. You wouldn't dare get it within talking distance of an internet connection without a couple of gigabytes of updates to plug holes, starting with bind. So to me at least, this consideration is a non-issue.
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. 5) provide a running copy of EMC/EMC2 "out of the box."
All the above are amply provided for by Debian's apt tools. apt-get manages equally well with networked repositories, or from CDs. Installing a single package from floppy (or flash drive) would probably require the use of dpkg (the back end to apt-get). Even the sources can be downloaded with apt-get along with any prerequisite build dependencies... [note to self: Fix build deps and generate a source package for emc]
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."
I've not done any significant work with the old EMC tree for the best part of two years now. Most of my efforts have been in a branch of emc2 - The EMC version found on the BDI-4 disk is the result. Although both head and bdi-4 branches share much code in common, most of the user space code is identical, as are core parts of the RT modules, the bdi-4 branch does not use the HAL layer. Think of the BDI-4 build as a staging platform for the time when (if ?) emc2 becomes stable enough for widespread use. Although from what I hear, emc3 may be just round the corner.
Regards, Paul.
-- 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.
participants (3)
-
Gene Heskett -
Kent A. Reed -
Paul