Barrapunto

Personalmente, lo que me limita es el número de columnas simultáneas, así que lo que suelo hacer es almacenar los datos en pestañas, volcarlos a CSV y de ahí importarlos y pegarlos con R donde hago las estadísticas que devuelvo a la hoja de cálculo. Si no hay límites en GNUMERIC empezaré a usarla cuendo esté en Debian stable.

Icaza ya ha aprobado la asignatura "Estructuras de Datos y Algoritmos".

¿Reinvencion de la rueda?
Es bastante mas ligero y rápido que Calc y me dices que es reinvencion, no, es un software dirigido a equipos mas modestos. Abiword + Gnumeric suele ser la elección para escritorios ligeros como Xfce o Lxde.

¿Porque dices que si se alcanza ese límite se debería pensar en Bases de Datos? Dependerá de la razón para rebasar ese límite, por ejemplo:

Imagina que tienes una columna de datos arbitrariamente larga (por ejemplo el resultado de un experimento con una frecuencia de toma de datos y/o duración elevada), y lo único que quieres es hacer un histograma con ellos (consiste simplemente en establecer una serie de grupos contiguos delimitados por un valor superior y otro inferior y contar cuántos datos caen en cada grupo). ¿Porqué debería ser necesaria una base de datos para esa tarea?

gnumeric es anterior a OpenOffice.org, y Staroffice no era libre (ni gratuito, que a mi la versión 4.0 me costó mi dinerillo).

La primera versión de de gnumeric es de septiembre de 1998, se liberó el código fuente de Staroffice en octubre de 2001 (gnumeric iba por la 0.71, a tres meses de la versión 1.0) y el OpenOffice.org 1.0 es del 1 de mayo de 2002 (por aquellas fechas, gnumeric ya iba por la 1.0.6).

Muchos te respondarán que tienen la tira de datos y que por eso les viene bien quitar el límite, pero es que llevas razón: Para almacenar tal cantidad de información lo que vale es una base de datos, que luego puedes conectar vía SQL u otro mecanismo con la hoja de cálculo para hacer el tratamiento necesario (y no siempre, porque los motores de base de datos también son capaces de calcular ciertas cosas).

Esa es la gran ventaja de Excel dentro del mundo de las hojas de cálculo: que es capaz de conectarse a lo que sea como fuente de datos y consolidarlos con todo su armamento matemático,para mostrar los resultados deseados.

Mira, yo me quejaba antes también de ese tipo de limitaciones, pero es que la estrategia era equivocada: Los datos a la hoja de cálculo llegan filtrado, habíendonos quedado con los que nos interesa para analizarlo. Es una "vista" que queremos tener de todo el conjunto de datos. Para contar o hacer suma, cualquier base de datos tiene un buen conjunto de funciones (postgresql [postgresql.org] o mysql [mysql.com]) que puede hacer que el trabajo sucio te lo haga la el motor de base de datos, para que llege a tu hoja para el análisis final más fino.

Al final, todo es encajar el puzzle de herramientas de la manera adecuada para que seas capaz de aprovechar al máximo cada una de ellas. Y, al menos mi experiencia, me dice que usar una hoja de cálculo para gestionar logs de gran tamaño, es ganas de complicarse mucho la vida.

R es el equivalente. Y de hecho no sólo equivalente, sino que a día de hoy ya es el paquete estadístico estándar en gran parte del mundo académico, junto a gnuplot para el dibujado (más para gente de física). Una de las pocas instancias en las que se puede ver dentro del ámbito del software libre.

R es un lenguaje de programación y a los administrativos no se les exige ni programación ni administración de redes.
No hay nada parecido a SPSS en cuanto a las funcionalidades que éste ofrece.
No quiero utilizar gestores de BBDD porque no todo el mundo sabe utilizar SQL y no siempre Access va en la licencia empresarial que se paga o no se puede poner StarBase.
Por ser positivo, ¿eres consciente de todas las posibilidades de Excel? Te permite hacer muchísimas operaciones que se traducen en muy tediosas de base de datos, y favorece un muy rápido EDA.

No es la herramienta estadística per se, pero muchas operaciones básicas se pueden hacer fácilmente con ellas.