GMail: más espacio del que podemos usar

Acabo de leer a Alvy de Microsiervos haciendo referencia a un post de Jasp sobre el tamaño de las cuentas de GMail. Ya comenté yo en su día que había más espacio del que utilizaba.

De hecho, es posible que así sea en la mayoría de los casos. De acuerdo que hay inventos por ahí que utilizan el espacio de GMail para otros casos, pero si nos restringimos a un uso convencional (simplemente como cuenta de correo) creo que la mayoría de gente no recibe correo al mismo ritmo que crece su cuenta.

Veamos en mi caso... tengo 1367 correos en la cuenta de GMail. La utilizo prácticamente sólo para suscribirme a listas y allí donde tenga que aparecer el email de manera pública. Me marca ocupados 22 MiB, así que me sale una aproximación bastante burda de 16,48 KiB por mensaje.

Según comentarios del post referido, si tomamos 30 bytes/segundo tenemos unos 2,47 MiB de espacio adicional diariamente, así que eso me da para más de 150 mensajes aproximadamente.

Así que también podemos decir que GMail nos da espacio para guardar 150 nuevos mensajes al día. Y si no contamos el spam, es mucho correo cada día (creo que yo no recibo eso dejando de lado el spam)

Y yo no creo que el crecimiento del tamaño de los mensajes sea exponencial. Desde hace muchos años el tamaño medio del mensaje no habrá crecido mucho. Incluso en mi caso el cálculo ha arrojado un tamaño medio bastante alto porque muchas listas de correo utilizan HTML pese a que es malo para el correo. Pero la mayor parte de los mensajes que llegan a mis buzones personales son mucho menores ya que son texto llano.

Previniendo ataques al puerto SSH

Llevo una buena temporada bastante molesto con los intentos de acceso al servicio SSH del servidor de la empresa. Molesto aunque no preocupado porque se que está bien configurado: no permitimos el acceso a root, sólo permitimos acceso a ciertos nombres de usuario que han de poder entrar y además mantenemos totalmente al día en tema de actualizaciones de seguridad.

Pero es muy molesto encontrar avisos del sistema de monitorización de logs cada dos por tres de obvios casos de script kiddies que lanzan ataques de barrido sobre diversos servidores.

Hacia tiempo que me rondaba la idea de mirar de limitar el número de intentos erróneos antes de bloquear la IP durante un tiempo, pero ya que OpenSSH no dispone de esa opción por ahora, lo había postpuesto para un estudio más detallado el dia que tuviera tiempo (ja!).

Pero no ha hecho falta, la gente de debian-administrator.org vienen a la carga con un artículo exactamente sobre eso.

JSP 2.1 y JSTL 1.2

Siguiendo con las novedades en las especificaciones J2EE Web Tier, las especificaciones de JSP y JSTL no presentan prácticamente ninguna novedad salvo adecuarse al nuevo documento de especificación del lenguaje EL.

En esta parte es donde si han habido cambios, ya que se han incorporado al EL cambios que ya había adoptado JSF.

Para empezar, ahora las expresiones no son sólo ${} sino también #{} aunque en la especificación se indica que ambas son equivalentes y que la diferencia depende del entorno en el que se utilicen (por ejemplo Faces utiliza #{} para expresiones con evaluación diferida).

Se ha ampliado bastante la sintaxis básica. Anteriormente (con JSP 2.0) el EL sólo permitia producir rvalues. O sea, expresiones que devuelven un valor. Ahora es posible indicar también rvalues y métodos. Un ejemplo tomado de la propia especificación (ejemplo de JSF):

<h:form>
<h:inputtext
id="email"
value="#{checkOutFormBean.email}"
size="25" maxlength="125"
validator="#{checkOutFormBean.validateEmail}"/>
</h:form>

En este ejemplo #{checkOutFormBean.email} es un rvalue ya que no representa un valor sino una propiedad del bean a la que ha de darse valor según el campo de formulario. En el caso de #{checkOutFormBean.validateEmail} hace referencia a un método que se invocará para validar ese campo.

Realmente un cambio centrado en el EL que lo va a convertir en una herramienta aún más util.