Category Archives: Uncategorized

I am told there are over 200,000 dead frogs in Colombian museums, and that at least that many frogs were exported to museums in other countries. I hope the days of mass collections are over.

This saddens me. Not that there are 400K dead frogs from Columbia, but that the person who runs that organization, a Ph.D. in biological sciences, does not understand the value of scientific collection.

I tried to reason with him and he just does not get it. The guy has a doctorate, how does he get a doctorate and not grok this? Seriously.

First of all, while the total number may be huge, it is very rare for more than 50 specimens to be collected from a single site, and usually it is more in the order of 20 or so. When large numbers (like 50) are collected, a good many of them are juveniles or tadpoles that would never have reached sexual maturity and been recruited into the adult population. So immediate impact on the population is very minimal, and the long term impact probably isn’t even measurable.

However there is great value in collection of specimens. Collection of specimens allows scientists to better understand the natural history of the species. What the frog eats, typical weight of the frog, pattern variations in the species, common diseases the species had at the time of collection, and ratio of male to female. Many of those things simply can not accurately determined without specimen collection.

Specimen collection for scientific purposes simply does not contribute to the decline of a species. Sure, if someone went up to my Cascades Frog spot that I know about and collected 30 adult specimens, it probably would do it in. That spot however is only vulnerable to extinction from specimen collection because it is already headed for extinction and probably will be extinct within a decade anyway. Populations that can not withstand scientific collection are doomed as it is without help. That’s just the unfortunate reality. If that population was healthy, there would be at least 500 adults living there (probably 50 right now) as well as large numbers in neighboring habitats (probably 0 right now).

Declines are caused by (in no particular order) over-harvesting for food (where thousands are collected yearly), alterations of the watershed (natural or human-caused), introduction of species that out-compete them (natural or human-caused), diseases they are not resilient too, pesticides, and general habitat degradation. Collecting a series for scientific study really has no impact on their decline.

One of the most basic fundamental concepts of biology is survival of the fittest. Survival of the fittest only works when species over-produce. Basically, more young are produced than are needed to replace the adults in a population when the adults die. Unless the species has just arrived in an area, there almost always are far more young produced than the habitat can support. This is especially true with frogs, most frogs are prey species, producing hundreds or even thousands of offspring per breeding adult female per year.

Many of the offspring are consumed by predators. That’s part of the natural cycle, circle of life stuff. Many disperse. Dispersal is where they move from the population they were born in and look for a new place to live. This is how genes flow between populations. A small number of the offspring grow up to join the adult population. The biological term for that is recruitment.

When specimens are collected for scientific study, adults that were collected from a population allow more room for offspring to join the adult population. If a population can not withstand scientific collection then it also can not withstand a drought or a particularly cold winter.

With the Mountain Yellow-legged Frog complex, there are some lakes in the Sierra’s where a particularly bad winter results in every single adult member of the population dying over winter, leaving only tadpoles as survivors. In Contra Costa County during particularly dry winters, I have found desiccated adult California Red-legged Frogs under logs where they were over-wintering, got too dry, and died.

Evolution designed these species to be able to withstand far greater death rates than what happens with scientific collection. Scientific collection simply does not cause or contribute to the extinction of a population.

There are however many advantages not only to scientific collection, but taking a decent sized series (20 to 30 or even more) during that collection.

First of all, a lot can be determined about the natural history of the species. Typical size and weight, stomach contents, sexual dimorphism characteristics, and even what diseases the species lives with.

If specimens of Species A show evidence of a disease in specimens collected in the 90s that is not present in specimens collected in the 70s then we know the disease probably was not present in the 70s and may be a contributing factor to a decline in Species A. Changes in stomach contents can indicate that something is out of whack resulting in dietary change. For example, the introduction of sport fish may alter the availability of some insect prey. The frog may have to travel further from the water to find food, increasing its exposure to predation and contributing to decline.

But there’s another benefit as well.

The Vegas Valley Leopard Frog (Lithobates [=Rana] fisheri) was thought to have gone extinct in 1942. At one point it was abundant in the Las Vegas Valley but another species, (Homo sapiens) thought it would be a fantastically bright idea to build a water thirsty metropolis in the middle of a fricken desert. We capped the natural springs in the Vegas Valley resulting in the extinction of the frog.

Numerous specimens though had been collected for scientific study, including 10 specimens from Tule Springs on January 13, 1942 that were the last recorded specimens of this species.

If science had not collected a single specimen, the frogs in the Vegas Valley would have still gone extinct. Capping the natural springs is what caused the demise of this once extremely common frog. Scientific collection however did allow us to study the frog even after it was extinct, which led to the discovery that a population of frogs in Arizona is the same species. We would never know if it were not for scientific collection, and now the possibility exists that we can restore habitat in the Vegas Valley and possibly re-introduce the frog.

For many years, many scientists though the Vegas Valley Leopard Frog was possibly a subspecies of the Relict Leopard Frog (Lithobates [=Rana] onca), see Stebbins 1985 for example. But we now know that is not the case, and were it not for the scientific collection that took place when this species was still in the Vegas Valley, the lack of data to examine may still have us in the dark.

The Oregon Spotted Frog (Rana pretiosa) and the Columbian Spotted Frog (Rana luteiventris), until somewhat recently it was believed they were the same species. However examination of museum specimens played a large role in determining that in fact they are two distinct species, and knowing that they are two distinct species allowed us to understand that one member of that complex, the Oregon Spotted Frog, is in serious trouble and in desperate need of recovery.

Scientific collection does not contribute to declines and in fact aids in conservation.

I don’t understand how this is a concept that escapes someone with a Ph.D. in biology. I really don’t.

I like the work that savethefrogs.com does, I really do, but they need to address real issues, not non-existent issues.

It appears that many of my dependency issues with perl may be the result of sloppy RPM spec files from the Fedora community. No offense intended to them either.

In my RPM bootstrapping of this LFS build, most of the RPM spec files I carefully wrote myself, so any problems with them are purely mine.

With perl, there are just far too many perl modules. I wrote the base perl spec myself but I was not about to write a spec file for each and every perl module that I need, there are literally hundreds of them. So for perl modules, I took source RPMs from Fedora 18.

It appears that many of the BuildRequires in the Fedora spec files are bogus, meaning they are not actually needed to either build the package or run the package test suite.

I apologize to the perl community for coming to the wrong conclusion about this.

Perl is a scripting language originally written by Larry Wall and still maintained by him, though at this point it has thousands of developers all around the world, just like virtually any successful FLOSS project.

It is a critical component of virtually and GNU operating system, the autoconf tool that is at the heart of virtually every portable code project relies upon Perl.

I hate it. It isn’t so much the language itself that I hate, it’s the damn CPAN bloated module infrastructure that I hate. Virtually every little function is it’s own module that depends upon other modules that depend upon other modules and so on.

The model that the Perl developers have is that you use their cpan tool to install what you need and it grabs everything and manages for you. Unfortunately that model does not work well with a modern FLOSS operating system, one of the advantages of a FLOSS operating system is you can have universal package management that takes care of things like automated dependency resolution. Installing perl modules via the cpan binary, the package manager does not know about them. For cpan modules with binary dependencies, cpan requires that you have the binary dependency including its header files already installed or it can’t build you the module.

This blog is about the extent of the dependency bloat the Perl has. It’s really bad.

Right now I am working on building my own Linux distribution. I like CentOS but a lot of the software in CentOS is rather dated. That’s fine for servers, but not for the desktop. Fedora on the other hand does a lot of things in a way I really don’t like, especially GNOME 3. I could blog forever about my gripes with GNOME3 – the list is very long.

The source is open though, so use it, damnit. I’m currently building my own distribution for the purpose of doing things the way I think they ought to be done. Perl is an essential part of any Linux system, hate it or not you gotta have it. While the vast majority of my RPMs I am writing from scratch, there are just too many perl modules. I certainly do not need them all, but Perl likes to have a dozen plus different modules for the same functionallity that is often within a single library binary library package in C/C++ land.

So I am doing perl in a way that allows me to just take Fedora perl module source RPMs and rebuild them in YellowJacket GNU/Linux. My layout is a bit different, I but binary modules in /usr/lib{32,64}/perl5 and noarch modules in /usr/lib/perl5. Fedora just uses /usr/lib for 32-bit libraries, they don’t have a /usr/lib32, so it puts binary modules in /usr/lib{,64}/perl5 and noarch modules in /usr/share/perl5 – but the different layout is handled automagically by macros in the RPM spec file at build time.

My spec file for perl results in a total of 65 packages (originally 66, soon 66 again), it has to be split up into that many packages because some of the modules have necessary updates that in CPAN and need to upgrade the module as it was distributed in the perl tarball.

Most source tarballs when compiled and packaged in an RPM result in 2 or 3 packages. one for the executables, one for development files (headers and such), and if it has shared libraries, one for the shared libraries.

My system was just about finished being RPM bootstrapped, meaning it was a minimal system where every piece of software installed from source had been replaced by packaged RPM versions of the software. OpenSSL was all that was left. At that time, there were 65 perl RPMs installed from the single source perl RPM.

OpenSSL installed a script that required the perl(WWW::Curl) module, a module not provided by the core perl system.

Building that module requires the perl(Test::Base) module to test the build of the module. It is very important to run the test suite, if there is a problem in the package, finding it by running the test suite can save you a lot of headaches.

Building perl(Test::Base) required a several other modules, which in turn required several other modules, which in turn required several other modules, and so on.

Right now, looking in my SRPM directory for perm modules I have built in pursuit of getting perl(Test::Base) so that I can build perl(WWW::Curl) there are currently 114 different source RPMs. One hundred and fucking fourteen.

Some of that may be Fedora’s fault. For example, one perl module wanted the Valgrind perl module to build for its test suite. My system is not yet ready for Valgrind, Valgrind has special instructions on how certain libraries are to be stripped, and to be honest, I’m not really that worried about every having Valgrind installed. I know in that particular case, Valgrind really wasn’t necessary for the test suite, so I modified the spec file to not require it. But most of the dependencies are in fact genuine.

In fairness, a users system won’t need all those modules installed to use perl(WWW::Curl), quite a few of those modules (I’m guessing more than half) are only needed to benefit the automated testing of the module after it is built. But it still is fucking way too much.

In the rest of the software world, something like Dejagnu is used for the test suite. Dejagnu requires Expect which requires Tcl. That’s two dependencies the test suite has. Perl on the other hand doesn’t seem to have any kind of standardized test suite, the Perl developers need to write one.

Perl needs a standardized test suite in a single tarball and perl modules that need something else for the test better have a damn good reason to do so.

And enough of this 20 different but closely related modules. That’s just bull shit.

Perl gurus pride themselves on their perl one-liners, how compactly they can do something with Perl. They need to apply that same philosophy to CPAN because right now it is a big fucking bloated mess. The result, I really hate perl.

I guess on the bright side, having built and installed that many modules going through the test process for each one successfully, I guess it’s a good indication my Perl install is working properly…

I have to tip my hat to the Fedora Python maintainer, looks like it is David Malcolm.

I’m currently running a Linux From Scratch system, and I’m in the process of RPM bootstrapping it. Package management is critically important to a *nix system, too many bad things can happen when you run make install as root.

This LFS system does not yet have Python. A Linux system without Python, I know, crazy. Really though, I did not want to install anything that is not required by RPM untill the system is fully RPM bootstrapped. Furthermore, a complete build of Python requires Tk and that requires various GUI libs. So whatever Python implementation I use will need to be rebuilt later when I have Tk installed, and that’s easiest done with RPM.

My LFS system is not multilib, but I want to leave that possibility open for the future. I personally don’t give a shit about being able to run 32-bit software, but some people might (e.g. for Adobe Reader which is only 32 bit on Linux – open source PDF readers are generally better but some things like PDF forms, Adobe’s version may still be needed) so I have {,/usr}/lib64 as a separate directory from {,/usr}/lib.

In the future I can do a multilib toolchain and all will be groovy.

The Python source however is not multilib ready. 64-bit objects should go in /usr/lib64/python2.7 and components that are common to both 64 and 32 bit systems should go in /usr/lib/python2.7 – but the very complex Python build system doesn’t really support that.

That’s where the Fedora Python spec file comes in to play. I’ll be honest, even though I use to be a packager for Fedora project (volunteer, not paid) – a lot of the Fedora spec files are overly complex with numerous patches. While I’m sure each patch solves a very real problem, sometimes the cause issues too. Like that time my hardware failed and I tried to mount my ext2 filesystem on a different distribution only to find out custom extensions had been patched in for features I didn’t even need that caused the other linux system to not be able to mount my drive.

I don’t remember checking a box that said “Make my filesystems in-compatible with other distributions” when I installed the system. But anyway, my philosophy is to stay as close to pristine upstream source as possible unless I have a damn good reason to deviate. With Python I have a damn good reason to deviate because it installs incorrectly for systems where the rpm macro %{_lib} expands to “lib64” instead of “lib”.

I installed Fedora’s source rpm and dreaded looking at it, but I was pleasantly surprised. Their build of Python is far more complex than I want, patches up the wazoo, but each patch is very well documented where it is defined making it easy for me to find the lib64 related patches and glance at the others, discarding those I don’t want.

Anyway, the Python source rpm is an example of how to properly do a complex spec file. Most spec files are simple (basically just %configure; make; make install DESTDIR=%{buildroot}) but when complex builds are done, often the spec files are really messy – the Python spec file from Fedora is an example of a very complex build that is properly done.