Actually that file does still exist. It's here now. Less than a year ago, the package went under massive directory reoganizations. CVS commit comments on the old and the new tell you where things came from and/or went to (and is in the CVS policy). If you want to see one not in the Attic with some age, the README will take you back almost 18 years or so.
BRL-CAD is a very large scale project with over 20 years of history in RCS and CVS. The CVS repository now lives on SourceForge with pretty much the entire revision history preserved (the project only recently released as open source). You can see one of the oldest files, for example here (bool.c). If you look to the end of the file, you'll see something like: Wed Apr 18 02:19:43 1984 UTC (20 years, 9 months ago) by mike
Several years ago, many of the current CVS practices were written down and organized into a rather detailed generic CVS policy. It basically all boils down to being able to guarantee a certain level of functionality, being very careful about naming directories, and coming up with good tag naming conventions. Likewise, depending on how many developers you have and how active development is, more or less control may be required for branches and validation.
Those last two restrictions are mainly due to limitations of CVS -- it does not directly manage directories or maintain history of directory changes, so you're left up to tracking those changes by policy conventions. (It's rather annoying that a CVS checkout does not prune empty directories by default!) If your directory structure is likely to change frequently (e.g. a new large project starting up), then something like SVN may be less painful. that said, BRL-CAD's history has easily endured CVS's inadequacies quite successfully.
The Air Force is great until the battle is on your doorstep. Or would you have them airstrike downtown LA too? Or even podunk, usa near where some honest farmer is hard at work trying to raise his crops, raise his kids, and feed the family. You need ground forces too.
It really depends on what it is you are comparing. BRL-CAD is primarily a solid modeling system, with tools that span a very wide gamut. It is a very powerful system, but is definately not necessarily "super easy to use" any more so than UNIX is (take that however you may). Quite the contrary, many of the tools can be downright cryptic or counter-intuitive.
That said, the power of the system's expressiveness, the performance and fidelity of the ray-trace engine, it's ability to deal with massively complex geometries, and more distinguish it quite a distance from many of the commercial projects. Similarly from a developer's perspective, there's now immediate availability to the sourcecode and interaction with developers to make it into whaever is desired.
The package was never written to be a user-friendly modeler. It was written by computer scientists specifically for the needs of vulnerability and lethality analysts. The tools are very numerical and informative. Many were written in a UNIX-spirit where you can tie tools and inputs/outputs together to achieve some desired end. There is 1 primary graphical tool in BRL-CAD akin to what you'd use in SolidWorks (MGED). There are 400 other command-line tools that do even more.
Now with the project as open source, hopefully the community will step forward and help make it what they want it to be. The US Army has given the community a great heads start.
As another also responded, BRL-CAD is already well established itself in its own niche of survivability and lethality analyses among a few others. These are markets that the commercial packages are not likely to penetrate anytime soon for various reasons (performance, familiarity, fidelity, formats, etc).
While the package is well established though, it is not nearly as polished or user-friendly as the commercial alternatives. There's simply very little incentive to expend tax payers dollars to simplify the user interface way down to some common public denominator. The people that have traditionally used BRL-CAD are trained scientists, engineers, and analysts with well established practices and expertise on hand if anything is not understood. Very specific tasks come up, BRL-CAD is modified to address those needs as efficiently as possible.
Now, of course, there is plenty of opportunity for the Open Source community to get involved with the project and bring it up to the needs and expectations of a wider audience. While it does a lot, in can certainly do a whole lot more still. The CAD open source community, especially the solid modeling community is sorely in need of many of the capabilities that BRL-CAD has provided for a long time now.. Here's your chance to make it as good or better than the other commercial packages.
It is possible they have been using CVS all these years; CVS was publically released in 1896, though I believe they may have alternatively used RCS and migrated to CVS somewhere down the line.
The migration to CVS occured in the mid-90's. It was indeed in RCS before then. Much thanks go out to the SourceForge.net hosts for housing a CVS repository of about half a gigabyte. Much effort has been put into retaining BRL-CAD's history over the years and it continues to pay off.
The oldest files are actually in the Attic (the project has gone through several reorganizations), but to give you an idea here (bool.c) is one of the older files. If you scroll to the bottom of the page you'll see: Wed Apr 18 02:19:43 1984 UTC (20 years, 8 months ago) by mike
The sheer size and complexity of BRL-CAD is often not quite grasped. In that three quarters of a million lines of source code are 16 libraries, over 400 binary applications, loads of historical documents, and a complicated build system. Many of those binaries and especially the libraries could probably serve as a stand-alone project in their own right.
The various licenses apply to the various portions and needs of the project. The binaries are GPL, the libraries are LGPL. The documentation is mostly GFDL. Most of th build system, support files, and scripts are under the BSD license or are in the public domain.
The BRL-CAD libraries are used by several other unreleaseable codes (think national security codes) throughout the US Army and other government agencies hence the usage of the LGPL for libraries.
It's more like having homeowners insurance, boaters insurance, car insurance, fraud and theft insurance, a 401K, and making public donations to your favorite charity.
Volume I covers the basics of what BRL-CAD is, how to obtain it, and how to install it. With BRL-CAD being released as Open Source, most of that is no longer relevant. The build system was recently changed (again in interests of going open source) also further invalidating Volume I's usefulness. The Overview of BRL-CAD document on the website contains the portions of Volume I that remained relevant.
BRL-CAD is very much still in active use and actively developed. Since the very first days of it's inception, BRL-CAD's source code has been available to those who are interested -- just not under an OSI-approved license. The main restriction of that old license agreement that made it different from other OSI-approved licenses is that you were not permitted to redistribute BRL-CAD. Other than that, the terms read very much like other open sources licenses.
The "problem" with that arrangement is that it is very difficult to collaborate with 3rd party developers and the community. You couldn't just go to a website, download, and try the package if you were interested. You filled out the form, faxed it in, and waited several days for a decryption key while a background check ensues and paperwork is shuffled around and people's time is taken up.
Indeed it is running on Mac OS X. It's ran on OS X since the early Public Beta days -- the port took me much less time than it's taking me to write this comment.
BRL-CAD has a long history of running on many systems that range from your average desktop running Linux to Cray supercomputers fully taking advantage of the CPU resources on any of them. Support is presently actively maintained for Mac OS X, Linux, IRIX, and Solaris (*BSD usually just works). Support for Windows is there too, though it's only recently been a focus of development.
Some legacy platforms include the DEC VAX-11 running 4.3 BSD, DECStations running ULTRIX, SGI 4Ds running various versions of IRIX, Sun-3 and Sun-4 Sparcs running SunOS, the Cray 1, X-MP and Y-MP running UNICOS, the Cray 2, DEC Alpha AXP running OSF/1, the Apple MAC II running A/UX, iPSC/860 Hypercube running NX/2, Alliant FX/8, Alliant FX/2800, Gould SEL, PowerNode, the Gould NP1, NeXT, HPPA 9000/700 running HPUX, the Ardent/Stardent, the Encore Multi-Max, and much more...
It's also been compiled on many versions of Linux, BSD, AIX, IRIX, Solaris over the years. Keep in mind just how old the project has been actively maintained. Two decades of supporting the latest and greatest is a lot of varied hardware and operating systems.
While I wouldn't exactly call POVRay a "standard", it is a great rendering package. BRL-CAD's rending purposes have been specifically and purposefully intended for rather different uses than generating "pretty pictures", though. More emphasis is applied to numerical accuracy, repeatability, performance, scaleability, and "correctness". The computations are used in statistical analyses where making sure a rendered image looks like a photo isn't as important as ensuring that an energy transport simulation is suitably representative. BRL-CAD on the whole complements POVRay quite nicely.
There is a linux version of BZEdit. It is in bzflag's cvs as the "bzedit" module. It's got some silly outdated dependancies, so getting it to build and link properly right out of cvs may be non-trivial. Plenty of people have done it, though, including on bsd and os x machines.
That said, there is a complete rewrite of BZEdit currently under development (but held in a svn repository elsewhere). If you're interested in helping out in development, stop by #bzflag or irc.freenode.net.
This is great news for government sites/labs where Kerberos with pre-hardware authentication (SecureID) is standard or even mandated. As it is, many sites have to remove the existing ssh installation, only to install a custom Kerberized version of ssh.
(e.g. http://kirby.hpcmp.hpc.mil/)
Having Kerberos in the default install should ease one of the many headache's government sysadmins have to endure.
Speaking of never having seen one of those things in real life, I just happened to see someone using one of those a couple months ago in Bel Air, MD. I was driving down through and did a double-take as the guy was crossing the road on an intersection crosswalk. Looked like he was leaving from the supermarket (which was rather close -- and he had grocery bags) and he was heading towards a residential area.
I thought to myself "Bastard!" Man was I jealous...
Alas, no floppy, not that it would help much. I did try a net install of both OpenBSD and NetBSD, with no luck. Like I mentioned earlier, there is firmware support for booting a kernel over bootp/tftpd via the built-in network port. The Sparcbook 2 has some proprietary video chipset and firmware, though, that causes the bootstrap of all the kernels to fail.
To meta-quote Apple's guide to interact with Active Directory Services:
"Mac OS X uses the LDAP protocol, not Microsoft's proprietary Active Directory Services Interface (ADSI), to connect to Microsoft's Active Directory. This.. assumes that you have in-depth knowledge of Active Directory, especially the ways in which it need s to be configured to support standard LDAP schema definitions. Because the primary means of accessing Active Directory is ADSI, using LDAP as an alternative implies a thorough working understanding of the use and limitations of the LDAP support provided by Active Directory."
It sounds like someone didn't know Active Directory sufficiently, hence the pain. Otherwise, setting up things on the Mac side is very simple and strait-forward. O'Reilly has a great book "Mac OS X for UNIX Geeks" that goes into great detail on explaining not only what to do, but what is going on behind the scenes.
In this case, I would be Active Directory Services is making things the most difficult for you (and the fact that OS X uses LDAP instead of ADSI).
My, the stories I have on the SparcBook 2! A few years ago, I salvaged two SparcBook 2's from work that had been wiped clean. Neither had their battery, floppy, cdrom -- just a power supply for each. I was curious and destructive, so I completely ripped one apart keeping only the hard drives (they had two) and display for parts(Sorry, no pics), even ditching the extra power supply (it was bulky and heavy) -- that was a mistake.
I kept the other SparcBook with the hopes of reviving it someday. Those suckers fortunately have bootp/tftp boot-loader support built in to their firmware. I got my hands on some ThinkNet -> Ethernet adapters pretty easily, but after attempting to get a bunch of linux and bsd kernels to network boot and only getting failures and panics, I put it back up on a shelf.
I continued to dig for details on the machine, and found quite a load of information. (I have a repository of goodies that I intend to post *some day* like pinout schematics, hardware specs, mailing list info, etc) Still nothing that helped me boot it up..
Last year, I pulled it off the shelf again when I was lucky enough to trade my spare hard drives that I ripped out of the first machine for the original custom Tadpole CDs that someone else had spares of. Now, all I'm missing is a special SCSI adapter they used (I have an old Sparc SCSI CDROM drive) or a machine that can actually boot the old Sun Solaris 1.0.2 discs!
The best part is the day I got the CD's, the power supply died. The SparcBook just happened to be sitting on top of an IBM ThinkPad that I owned. I pulled the plug from the thinkpad and (low and behold) I plugged it in and it worked! After doing some math, the thinkpad adapter was almost the exact same power as the old SparcBooks, not to mention the plug being identical! Now, that was lucky!
So, to this day, the little guy still sits on the shelf waiting to make his presence known.. [sniff]
After having recently run the BRL-CAD Benchmark (a good CPU-bound benchmark based on raytrace performance) suite on both Yellow Dog Linux and Mac OS X 10.2, we found that there is a significant difference between Apple's version of gcc and the gcc you can get "off the shelf".
This guy makes note that he recompiled gcc. I would have liked to have seen results using the same gcc, without recompiling (e.g. use the 3.1 that Apple ships compared with 3.1 on YDL).
When we ran our benchmark, Yellow Dog Linux was approximately 25% slower. That starts to push on a margin of difference that we care about. But, what was even MORE interesting was the fact that compilations took WAY longer with Apple's compiler than on Linux (1.5 hours compared to 22 minutes).
We gladly give up compilation time for run-time performance. But, then, the BRL-CAD Benchmark is almost completely CPU bound, and a good optimization loop will find lots of places in the code to try to optimize.
In either respect, that's a whole lot more time spent optimizing. I wouldn't be surprised that if he didn't recompile the compiler if things didn't work faster on OS X.
Slashdot Mirror
Actually that file does still exist. It's here now. Less than a year ago, the package went under massive directory reoganizations. CVS commit comments on the old and the new tell you where things came from and/or went to (and is in the CVS policy). If you want to see one not in the Attic with some age, the README will take you back almost 18 years or so.
BRL-CAD is a very large scale project with over 20 years of history in RCS and CVS. The CVS repository now lives on SourceForge with pretty much the entire revision history preserved (the project only recently released as open source). You can see one of the oldest files, for example here (bool.c). If you look to the end of the file, you'll see something like: Wed Apr 18 02:19:43 1984 UTC (20 years, 9 months ago) by mike
Several years ago, many of the current CVS practices were written down and organized into a rather detailed generic CVS policy. It basically all boils down to being able to guarantee a certain level of functionality, being very careful about naming directories, and coming up with good tag naming conventions. Likewise, depending on how many developers you have and how active development is, more or less control may be required for branches and validation.
Those last two restrictions are mainly due to limitations of CVS -- it does not directly manage directories or maintain history of directory changes, so you're left up to tracking those changes by policy conventions. (It's rather annoying that a CVS checkout does not prune empty directories by default!) If your directory structure is likely to change frequently (e.g. a new large project starting up), then something like SVN may be less painful. that said, BRL-CAD's history has easily endured CVS's inadequacies quite successfully.
The Air Force is great until the battle is on your doorstep. Or would you have them airstrike downtown LA too? Or even podunk, usa near where some honest farmer is hard at work trying to raise his crops, raise his kids, and feed the family. You need ground forces too.
;-)
(okay downtown LA was a bad example)
It really depends on what it is you are comparing. BRL-CAD is primarily a solid modeling system, with tools that span a very wide gamut. It is a very powerful system, but is definately not necessarily "super easy to use" any more so than UNIX is (take that however you may). Quite the contrary, many of the tools can be downright cryptic or counter-intuitive.
That said, the power of the system's expressiveness, the performance and fidelity of the ray-trace engine, it's ability to deal with massively complex geometries, and more distinguish it quite a distance from many of the commercial projects. Similarly from a developer's perspective, there's now immediate availability to the sourcecode and interaction with developers to make it into whaever is desired.
The package was never written to be a user-friendly modeler. It was written by computer scientists specifically for the needs of vulnerability and lethality analysts. The tools are very numerical and informative. Many were written in a UNIX-spirit where you can tie tools and inputs/outputs together to achieve some desired end. There is 1 primary graphical tool in BRL-CAD akin to what you'd use in SolidWorks (MGED). There are 400 other command-line tools that do even more.
Now with the project as open source, hopefully the community will step forward and help make it what they want it to be. The US Army has given the community a great heads start.
As another also responded, BRL-CAD is already well established itself in its own niche of survivability and lethality analyses among a few others. These are markets that the commercial packages are not likely to penetrate anytime soon for various reasons (performance, familiarity, fidelity, formats, etc).
While the package is well established though, it is not nearly as polished or user-friendly as the commercial alternatives. There's simply very little incentive to expend tax payers dollars to simplify the user interface way down to some common public denominator. The people that have traditionally used BRL-CAD are trained scientists, engineers, and analysts with well established practices and expertise on hand if anything is not understood. Very specific tasks come up, BRL-CAD is modified to address those needs as efficiently as possible.
Now, of course, there is plenty of opportunity for the Open Source community to get involved with the project and bring it up to the needs and expectations of a wider audience. While it does a lot, in can certainly do a whole lot more still. The CAD open source community, especially the solid modeling community is sorely in need of many of the capabilities that BRL-CAD has provided for a long time now.. Here's your chance to make it as good or better than the other commercial packages.
The migration to CVS occured in the mid-90's. It was indeed in RCS before then. Much thanks go out to the SourceForge.net hosts for housing a CVS repository of about half a gigabyte. Much effort has been put into retaining BRL-CAD's history over the years and it continues to pay off.
The oldest files are actually in the Attic (the project has gone through several reorganizations), but to give you an idea here (bool.c) is one of the older files. If you scroll to the bottom of the page you'll see: Wed Apr 18 02:19:43 1984 UTC (20 years, 8 months ago) by mike
The sheer size and complexity of BRL-CAD is often not quite grasped. In that three quarters of a million lines of source code are 16 libraries, over 400 binary applications, loads of historical documents, and a complicated build system. Many of those binaries and especially the libraries could probably serve as a stand-alone project in their own right.
The various licenses apply to the various portions and needs of the project. The binaries are GPL, the libraries are LGPL. The documentation is mostly GFDL. Most of th build system, support files, and scripts are under the BSD license or are in the public domain.
The BRL-CAD libraries are used by several other unreleaseable codes (think national security codes) throughout the US Army and other government agencies hence the usage of the LGPL for libraries.
It's more like having homeowners insurance, boaters insurance, car insurance, fraud and theft insurance, a 401K, and making public donations to your favorite charity.
Volume I covers the basics of what BRL-CAD is, how to obtain it, and how to install it. With BRL-CAD being released as Open Source, most of that is no longer relevant. The build system was recently changed (again in interests of going open source) also further invalidating Volume I's usefulness. The Overview of BRL-CAD document on the website contains the portions of Volume I that remained relevant.
BRL-CAD is very much still in active use and actively developed. Since the very first days of it's inception, BRL-CAD's source code has been available to those who are interested -- just not under an OSI-approved license. The main restriction of that old license agreement that made it different from other OSI-approved licenses is that you were not permitted to redistribute BRL-CAD. Other than that, the terms read very much like other open sources licenses.
The "problem" with that arrangement is that it is very difficult to collaborate with 3rd party developers and the community. You couldn't just go to a website, download, and try the package if you were interested. You filled out the form, faxed it in, and waited several days for a decryption key while a background check ensues and paperwork is shuffled around and people's time is taken up.
Now you can just download it.
Indeed it is running on Mac OS X. It's ran on OS X since the early Public Beta days -- the port took me much less time than it's taking me to write this comment.
BRL-CAD has a long history of running on many systems that range from your average desktop running Linux to Cray supercomputers fully taking advantage of the CPU resources on any of them. Support is presently actively maintained for Mac OS X, Linux, IRIX, and Solaris (*BSD usually just works). Support for Windows is there too, though it's only recently been a focus of development.
Some legacy platforms include the DEC VAX-11 running 4.3 BSD, DECStations running ULTRIX, SGI 4Ds running various versions of IRIX, Sun-3 and Sun-4 Sparcs running SunOS, the Cray 1, X-MP and Y-MP running UNICOS, the Cray 2, DEC Alpha AXP running OSF/1, the Apple MAC II running A/UX, iPSC/860 Hypercube running NX/2, Alliant FX/8, Alliant FX/2800, Gould SEL, PowerNode, the Gould NP1, NeXT, HPPA 9000/700 running HPUX, the Ardent/Stardent, the Encore Multi-Max, and much more...
It's also been compiled on many versions of Linux, BSD, AIX, IRIX, Solaris over the years. Keep in mind just how old the project has been actively maintained. Two decades of supporting the latest and greatest is a lot of varied hardware and operating systems.
While I wouldn't exactly call POVRay a "standard", it is a great rendering package. BRL-CAD's rending purposes have been specifically and purposefully intended for rather different uses than generating "pretty pictures", though. More emphasis is applied to numerical accuracy, repeatability, performance, scaleability, and "correctness". The computations are used in statistical analyses where making sure a rendered image looks like a photo isn't as important as ensuring that an energy transport simulation is suitably representative. BRL-CAD on the whole complements POVRay quite nicely.
There is a linux version of BZEdit. It is in bzflag's cvs as the "bzedit" module. It's got some silly outdated dependancies, so getting it to build and link properly right out of cvs may be non-trivial. Plenty of people have done it, though, including on bsd and os x machines.
That said, there is a complete rewrite of BZEdit currently under development (but held in a svn repository elsewhere). If you're interested in helping out in development, stop by #bzflag or irc.freenode.net.
Cheers!
This is great news for government sites/labs where Kerberos with pre-hardware authentication (SecureID) is standard or even mandated. As it is, many sites have to remove the existing ssh installation, only to install a custom Kerberized version of ssh.
(e.g. http://kirby.hpcmp.hpc.mil/)
Having Kerberos in the default install should ease one of the many headache's government sysadmins have to endure.
Speaking of never having seen one of those things in real life, I just happened to see someone using one of those a couple months ago in Bel Air, MD. I was driving down through and did a double-take as the guy was crossing the road on an intersection crosswalk. Looked like he was leaving from the supermarket (which was rather close -- and he had grocery bags) and he was heading towards a residential area.
I thought to myself "Bastard!" Man was I jealous...
Looked pretty cool.
Alas, no floppy, not that it would help much. I did try a net install of both OpenBSD and NetBSD, with no luck. Like I mentioned earlier, there is firmware support for booting a kernel over bootp/tftpd via the built-in network port. The Sparcbook 2 has some proprietary video chipset and firmware, though, that causes the bootstrap of all the kernels to fail.
To meta-quote Apple's guide to interact with Active Directory Services:
.. assumes that you have in-depth knowledge of Active Directory, especially the ways in which it need s to be configured to support standard LDAP schema definitions. Because the primary means of accessing Active Directory is ADSI, using LDAP as an alternative implies a thorough working understanding of the use and limitations of the LDAP support provided by Active Directory."
"Mac OS X uses the LDAP protocol, not Microsoft's proprietary Active Directory Services Interface (ADSI), to connect to Microsoft's Active Directory. This
It sounds like someone didn't know Active Directory sufficiently, hence the pain. Otherwise, setting up things on the Mac side is very simple and strait-forward. O'Reilly has a great book " Mac OS X for UNIX Geeks " that goes into great detail on explaining not only what to do, but what is going on behind the scenes.
In this case, I would be Active Directory Services is making things the most difficult for you (and the fact that OS X uses LDAP instead of ADSI).
My, the stories I have on the SparcBook 2! A few years ago, I salvaged two SparcBook 2's from work that had been wiped clean. Neither had their battery, floppy, cdrom -- just a power supply for each. I was curious and destructive, so I completely ripped one apart keeping only the hard drives (they had two) and display for parts(Sorry, no pics), even ditching the extra power supply (it was bulky and heavy) -- that was a mistake.
I kept the other SparcBook with the hopes of reviving it someday. Those suckers fortunately have bootp/tftp boot-loader support built in to their firmware. I got my hands on some ThinkNet -> Ethernet adapters pretty easily, but after attempting to get a bunch of linux and bsd kernels to network boot and only getting failures and panics, I put it back up on a shelf.
I continued to dig for details on the machine, and found quite a load of information. (I have a repository of goodies that I intend to post *some day* like pinout schematics, hardware specs, mailing list info, etc) Still nothing that helped me boot it up..
Last year, I pulled it off the shelf again when I was lucky enough to trade my spare hard drives that I ripped out of the first machine for the original custom Tadpole CDs that someone else had spares of. Now, all I'm missing is a special SCSI adapter they used (I have an old Sparc SCSI CDROM drive) or a machine that can actually boot the old Sun Solaris 1.0.2 discs!
The best part is the day I got the CD's, the power supply died. The SparcBook just happened to be sitting on top of an IBM ThinkPad that I owned. I pulled the plug from the thinkpad and (low and behold) I plugged it in and it worked! After doing some math, the thinkpad adapter was almost the exact same power as the old SparcBooks, not to mention the plug being identical! Now, that was lucky!
So, to this day, the little guy still sits on the shelf waiting to make his presence known.. [sniff]
After having recently run the BRL-CAD Benchmark (a good CPU-bound benchmark based on raytrace performance) suite on both Yellow Dog Linux and Mac OS X 10.2, we found that there is a significant difference between Apple's version of gcc and the gcc you can get "off the shelf".
This guy makes note that he recompiled gcc. I would have liked to have seen results using the same gcc, without recompiling (e.g. use the 3.1 that Apple ships compared with 3.1 on YDL).
When we ran our benchmark, Yellow Dog Linux was approximately 25% slower. That starts to push on a margin of difference that we care about. But, what was even MORE interesting was the fact that compilations took WAY longer with Apple's compiler than on Linux (1.5 hours compared to 22 minutes).
We gladly give up compilation time for run-time performance. But, then, the BRL-CAD Benchmark is almost completely CPU bound, and a good optimization loop will find lots of places in the code to try to optimize.
In either respect, that's a whole lot more time spent optimizing. I wouldn't be surprised that if he didn't recompile the compiler if things didn't work faster on OS X.