Announce - Open Source CNC website

According to Guy Fawkes :

[ ... ]

So -- if you are basing it on open source software, why are you requiring a *proprietary* archive format, RAR? I had to do a Google search to even find out what it is, and it appears to originate in the Windows world.

I've found free downloads of compiled object code for both Solaris 10 and OpenBSD, but no source code -- totally at odds with the Open Source goal which you have stated.

And those free downloads are only for programs to *extract* the files, not to *create* them, so you are requiring people to buy software to contribute to an open source site? I see no mention of any other formats being acceptable.

What is wrong with tar? That is pretty freely available source, and works well with the linux machines on which a lot of the open source CNC machines are hosted.

Just some first-glance impressions.

Enjoy, DoN.

see, that's PRECISELY why the open source ethos works so well.... the consensus view wins and many eyes see all the problems quickly.

I also say nothing is written in stone, so you've proposed tar I believe? if a consensus follows around that archive format, or indeed around 3 or 4 basic ones, it's not the slightest problem to make that happen.

I feel a poll coming on, see the site.... poll now on home page on the right

cheers

Perhaps you haven't looked at

that site pretty well covers the spectrum of CNC from homebuilt to commercial.

Pete C.

According to Guy Fawkes :

Hmm ... some comments on the poll and its choices -- aside from it apparently requiring registration and login, which I normally avoid if possible (Obviously, I would have to register and login if I wanted to submit something, but while browsing a site, I tend to opt to not register.):

1) tar, alone, builds archives (collections of files in a single file), but has no compression. 2) gzip (GNU zip) is compression *only*, of a single file at a time. 3) So -- a combination of tar and gzip will produce a compressed file holding many files. (And, it can be done with a "-z" option to GNU's version of tar, for convenience.) This combination is so common, that it has acquired its own name. It is called a "tarball". 4) An alternative compression format, "bzip2", can offer slightly greater compression, and can be invoked by the option "-j" fed to GNU's tar instead of "-z".

gzip is more commonly found, so it would probably be the best combined with tar if only a single format were to be used.

So -- your survey needs "combinations of ..." as well as "a choice of".

5) A choice is common on many source archive sites -- tar combined with gzip and tar combined with bzip2 being the most common for unix sources.

"Uncompressed" tends to be infrequently used -- usually for the sources for the compression programs (like gzip) themselves. These tend to be small programs, so the extra system load for the downloading is relatively minor. For large program suites, such as EMC, compressed versions should be all that is available. (Set a size limitation above which compression is mandatory.)

Perhaps add a choice of something common in Windows which does not require proprietary software to create on unix systems. A version of "zip" is frequently found on modern unix systems, and is in freely available source format as well.

Ideally -- you should have links to the open source code sites for each *required* format, so nobody is forced to buy a package (like RAR) to submit a program.

6) Perhaps have an option to submit in one of several formats, and scripts on the site to expand these and then re-join them using the other formats? 7) ARJ and ACE are two others with which I am not familiar. I don't think that I will bother with a Google search on those at this time, however. 8) While we're about it -- documentation should avoid proprietary formats, such as Microsoft Word. Plain ASCII is a good choice, or if you need something with fancy formatting, make it PDF format. (Yes, I know that you have to pay Adobe to have their program able to create PDF files -- but we've got other options as well for that, since Ghostscript can also create PDF files, and that is available in Open Source form.

Just some thoughts.

Enjoy, DoN.

On 31 Dec 2005 16:09:09 -0800, with neither quill nor qualm, "Guy Fawkes" quickly quoth:

Now program/link it so it's -live, not just text and graphics, Guy.

Put me down for 2-3 options, ZIP and GZ.

=========================================================== Save the Endangered Bouillons from being cubed!

Hilarious T-shirts online ===========================================================

Give it a couple of years and they'll agree a file format. Next will come the tricky decision on what the logo should be.

.tar works great, because winrar opens them right up. :)

littered with adverts and promotional material and more particularly it doesn't specialise in open source.

participants get a vote, it's just a filter.

I'd put money on this coming out in a week or so

Good point, noted.

cheers

Fantastic idea and more importantly follow-through. Already book marked.

What are the top ten needs/wants?

What is the programming language of choice? I am assuming c++ or java for cross-platform compiling, but?

A happy and prosperous 2006 for you also.

Uncle George

==========================

Java? Man, I hope not. C++ is almost acceptable, but I would think C, python, or perl would be most widely accepted.

--Donnie

According to Cliff :

As I indicated a bit farther down -- that combinations of the protocols would work nicely.

DoN.

According to Cliff :

Compress (based on the Lempel-Ziv algorithm) had fallen out of favor because the algorithm was patented, and the holder of the patent (Unisys) was insisting on charging royalties for any use of it (after it had been open source for a time) -- with no exceptions for open-source freely-distributed programs. I *think* that the patent has now expired, so it is freely available again, but gzip and bzip2 are so much more efficient that there seems to be little likelihood that the older compress will come back into common usage.

I note that it does come with Sun's Solaris -- at least from SunOs 4.1.4 all the way up to Solaris 10. (Though I remember the days when I had to compile it to use it.)

As for "compact" -- that may be truly antique, as I don't have any examples of it.

The first three pages of Google hits for "compact program source" offered nothing of any apparent relevance.

I do remember one program which I got from the OS-9 user's group library (Microware's OS-9, not the recent Macintosh one) which was a bit more configurable than most -- and as a result, it was the only one which worked on a BBN C70 (mostly v7 unix like), because that machine had 10-bit bytes, 20-bit words, and 40-bit longs. While "compress" worked well enough on plain text files, it totally blew up on binaries.

This program, however, could be configured to the byte size, so it worked quite well on that system.

Enjoy, DoN.

P.S. I may not see your replies, because I normally have you killfiled to keep away from the political discussions. I happened to follow a couple of thread branches into your comments (which were marked as already read, but I knew that I had *not* read them, just to see what they contained.

According to F. George McDuffee :

Good CAD/CAM packages in the open source world. Commercial packages have an extreme price for unix systems compared to windows. There are reasonable CAD packages, but the companion CAM, for converting the drawing files into G-code seems to be harder to come by.

My own preference is plain c, not c++, and not java. (Java may have freely downloadable source (after signing up with Sun), but it is not Open Source -- Sun keeps tight rein on it.

Enjoy, DoN.

For some things, perl is not bad -- but it has the disadvantage of being an interpreted language, so slow for large tasks compared to a truly compiled program.

I've never done anything in python, so I can't speak to that.

But -- I do use C quite a bit, and have for many years.

If you really want to push the envelope, try Ada, which is now available as part of the gcc package. I've never done anything in it, nor have I gotten the necessary tools to compile that part of the gcc package, but I would consider it a step up from C++.

For math-intensive work, something like APL, but I think that would be awkward for most of what would be done relative to CNC work. And -- it is a pain to compile and install on most systems, thanks to its required weird character set.

Enjoy, DoN.

and

Both are great options for a lot of smaller programs, like simple things that generate g-code to do basic but repetitive operations that might just have different dimensions. Python can even be good for slightly larger programs that require a GUI (or not). If memory serves it gets byte-compiled and thus is only really "interpreted" the first time you run it, and from then on is pretty fast. Certainly not C fast, but...

Certainly the single best option for larger programs, I think.

Agreed. But then again, I'd agree anything is a step up from C++. :-)

Yep. C. Just do C. You can't go wrong with C. Did I mention C? C is good. :-)

--Donnie

What's wrong with OCCAM?