So then Gene wrote:
On Thursday 29 December 2005 15:21, Kent A. Reed wrote:
<yada yada yada>
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?
Sure. That's why including source was way down my list.
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.
I was thinking more of the folks who'd like to invest the minimum effort required to take EMC for a test drive. Maybe the BDI-Live is still the answer for them., or maybe just exercising the different user interfaces in a scripted test harness would suffice. I'm old enough to have learned to drive when only stick-shift cars were used by the testers. I was all hands and feet, so to speak. With experience, complicated things, like hand signalling, downshifting, braking, and turning became easy. I think the combination of Linux, EMC, controller hardware, and the machine tool itself presents similar challenges even for folks who have either software or hardware experience but not both. It's comforting to know that major parts of the system already work. Judging from the questions I've seen posted to some of the cnc-oriented groups and to cnczone, I don't believe we'll ever go wrong by assuming the least. I'll bet most parties get interested in EMC because they want to drive a machine tool and not because they're Linux-heads looking for a cool application, so there's no basis for assessment of their computer skills.
Or am I chasing rabbits and barking barking at the moon here?
So what's wrong with that? Surely you've noticed the smile on the hound's face!
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...
I do doubt it. I've seen lots of experienced Linux users never upgrade the kernel that came with their distro even when they religiously run up2date or its equivalent. There's an unspoken fear that they'll screw up the works if they start playing with the kernel. In the old days, this was a realistic fear. These days, the upgrade tools are so well integrated and automated that it seems like a no-brainer to override the default setting not to upgrade the kernel.
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.
Well, I wrote but then deleted a long section in my first reply that argued for inclusion of a vi-compatible editor because of its "greatest common denominator" status over the decades I've played with various Unices and Linux. It's hard to teach an old dog new tricks! If you're a true Amiga fan, why not install "Amiga Forever" on your Linux box to emulate the Amiga OS so you can run CygnusEd :-) I never got into the Amiga fan club but I've got a colleague at work who still hasn't gotten over the forced retirement of his Amiga video toaster.
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. :-)
That's what makes the argument so much fun. Nobody can ever win. Regards, Kent
On Saturday 31 December 2005 15:58, Kent A. Reed wrote:
So then Gene wrote:
On Thursday 29 December 2005 15:21, Kent A. Reed wrote: [...] 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?
Sure. That's why including source was way down my list.
Sp we are on the same page there I think.
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.
I was thinking more of the folks who'd like to invest the minimum effort required to take EMC for a test drive. Maybe the BDI-Live is still the answer for them., or maybe just exercising the different user interfaces in a scripted test harness would suffice.
Well, for newbies just wanting to see how it corners, you are probably correct.
I'm old enough to have learned to drive when only stick-shift cars were used by the testers. I was all hands and feet, so to speak. With experience, complicated things, like hand signalling, downshifting, braking, and turning became easy. I think the combination of Linux, EMC, controller hardware, and the machine tool itself presents similar challenges even for folks who have either software or hardware experience but not both. It's comforting to know that major parts of the system already work.
Automatic transmissions came after me too. But I probably built the first 'stick shifted' hydromatic in eastern Iowa way back when 49 Oldsmobiles were stil pretty fresh used cars. Impressive when you goto pass someone, and when you lift your foot out of the detent at 85 mph cause the valves are about to float, and the tires let out a 2 second howl as 4th locks in. :) A bit hard on motor mounts too I might add, as we found out later that day after I'd coaxed a box stock 49'er into a 16 second 1/4 mile, while it was vapor locking cause the temps were in the low 100's that day. We chewed on the edge of the radiator shound rather obviously. That 324 cid olds v8 was healthy.
Judging from the questions I've seen posted to some of the cnc-oriented groups and to cnczone, I don't believe we'll ever go wrong by assuming the least. I'll bet most parties get interested in EMC because they want to drive a machine tool and not because they're Linux-heads looking for a cool application, so there's no basis for assessment of their computer skills.
Humm, I suppose thats right too Kent, but in the linux business plan, isn't this where they buy a canned solution from an experienced integrator who IS being paid for his knowledge?
Or am I chasing rabbits and barking barking at the moon here?
So what's wrong with that? Surely you've noticed the smile on the hound's face!
Humm, yes, there is that. Old coon hunters have been known to shoot at the moon & miss, but when the 22 is looking right into the left eye, and you pull, and the coon falls out of a tree 25-40 feet behind you, it does get certifiably spooky. We hit the mother lode one night and got 8, but none of them fell out of the tree we were shooting at. We never went near that place again for obvious reasons.
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...
I do doubt it. I've seen lots of experienced Linux users never upgrade the kernel that came with their distro even when they religiously run up2date or its equivalent.
They're afraid of 'make'? Sheesh. OTOH, I first used make probably in 1979, so its an old friend of mine.
There's an unspoken fear that they'll screw up the works if they start playing with the kernel. In the old days, this was a realistic fear. These days, the upgrade tools are so well integrated and automated that it seems like a no-brainer to override the default setting not to upgrade the kernel.
Really, once the initial config to a working kernel has been achieved, building new ones is pretty simple. I could start by downloading the next patch in sequence, unpack it, and then edit 2 scripts for the new numbers, fire them off and have a newly built kernel installed in about 20 minutes here, build time on this box runs around 9-10 minutes depending on what else I may have it slaving away at. The real, bites everybody behind the short hair problem is that the distros do not make it the least bit easy to discover the .config that built the kernel thats actually running. But once thats done, its as simple as copying the current .config into the directory tree that unpacking the next version makes, running 'make oldconfig' and answering any questions it may ask sensibly, followed by a 'make xconfig' to see what is being built thats not applicable to your hardware and fix that as you like. I have a script that does all that so I won't waste any more time on a blow by blow here.
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.
Well, I wrote but then deleted a long section in my first reply that argued for inclusion of a vi-compatible editor because of its "greatest common denominator" status over the decades I've played with various Unices and Linux. It's hard to teach an old dog new tricks!
Yippers! And for exactly those reasons. They are good ones even if it is throwing yet another log on the fire of the vi/emac debates. The only comment I'd make is that the emacs learning curve is considerably steeper than vi/vim, at least to me.
If you're a true Amiga fan, why not install "Amiga Forever" on your Linux box to emulate the Amiga OS so you can run CygnusEd :-) I never got into the Amiga fan club but I've got a colleague at work who still hasn't gotten over the forced retirement of his Amiga video toaster.
They want too much money, and the interface hardware is enough diff to make a working system a lot of work to actually achieve. I have the other freeware emu kit (uae, last release) here, but haven't run it since I discovered it couldn't use my dds2 drive to recover the last full backup of the amiga that I made about 2 weeks before the 30GB drive in it ate itself for lunch. I did get the data on the tapes back, but I used dd and linux to do it.
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. :-)
That's what makes the argument so much fun. Nobody can ever win.
No, but we can sure have a lot of fun with the what ifs... And occasionally, as they say in Nashville on 16th avenue, you hit a lick with one of those what ifs and you "go in style, for a while, on 16th avenue." Rosanne Cash I think that was.
Regards, Kent
Have a better 2006 Kent, later. -- 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.
On Monday 02 January 2006 02:26, Gene Heskett wrote:
Really, once the initial config to a working kernel has been achieved, building new ones is pretty simple.
The real, bites everybody behind the short hair problem is that the distros do not make it the least bit easy to discover the .config that built the kernel thats actually running.
Double checked Fedora, and they, like Debian, install a config-<KVER> in /boot along with the vmlinuz image. The only difficulty is weeding out the multitude of drivers that are not needed.. Even patching is painless as long as you follw the advice of using a virgin tarball from kernel.org. I think the one thing that does trip people up when it comes to patching with RTAI is one or two of the config options. The favorite one is to enable APM and then blame EMC for a ragged output. Don't know about Fedora, but Debian has a make-kpkg script that will clean, configure, and build the kernel, and serve it up as a deb package. A great little tool if you are concerned about being able to purge a kernel image from the system in the future. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
On Monday 02 January 2006 16:18, Paul wrote:
On Monday 02 January 2006 02:26, Gene Heskett wrote:
Really, once the initial config to a working kernel has been achieved, building new ones is pretty simple.
The real, bites everybody behind the short hair problem is that the distros do not make it the least bit easy to discover the .config that built the kernel thats actually running.
Double checked Fedora, and they, like Debian, install a config-<KVER> in /boot along with the vmlinuz image. The only difficulty is weeding out the multitude of drivers that are not needed.. Even patching is painless as long as you follw the advice of using a virgin tarball from kernel.org. I think the one thing that does trip people up when it comes to patching with RTAI is one or two of the config options. The favorite one is to enable APM and then blame EMC for a ragged output.
Don't know about Fedora, but Debian has a make-kpkg script that will clean, configure, and build the kernel, and serve it up as a deb package. A great little tool if you are concerned about being able to purge a kernel image from the system in the future.
One can use mc for the housecleaning if required, and probably quicker. And totally legal in the case of a kernel.org kernel built and installed locally, just delete them from /boot, /lib/modules, and that entry in menu.lst or grub.conf (for rh flavored stuff) menu.lst or grub.conf, depending on your favorite poison, is a text file that doesn't take a rocket scientist to edit. The only thing confusing is that the use of the word 'root' means 2 different things depending on where it is in the file. Lets see if I can clarify this and take a bit of the obtuseness out of this mystery file called menu.lst or grub.conf. Here is the entry I'm presently booted to, out of 24 choices in my grub.conf: --------------- # grub.conf generated by anaconda (yeah sure, years ago) # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img # boot=/dev/hda1 default=5 fallback=4 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz # 5 The above line is a comment, added by me purely for me to keep track of the current position in the list. See the default and fallback entries above. title Fedora Core 2 Linux (2.6.15-rc7) root (hd0,0) The word root (hd0,0) above, means the first drive on the first controller channel. Search its mbr for partition info. kernel /vmlinuz-2.6.15-rc7 ro root=/dev/hda7 elevator=cfq The word root= above means the / partition, in this case, the first drive, 7th partition. It could, and I have done it, point to a different drive for dual boot lashups, as in /dev/hdd3 or whatever, which would be the last (4th) drive on the first controllers second channel, 3rd partition in, is the partition to be mounted as /. initrd /initrd-2.6.15-rc7.img Self explanatory. End of that particular entry. Does this help explain that? Or am I carrying coals to Newcastle. :-)
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