Things I miss from PostgreSQL

More than a year ago I moved to Dublin and I started to work for another company. In this new company instead of PostgreSQL, which I habe been using for 10 years, they use Microsoft SQLServer. My first feelings were like stepping on a time machine and going back for 6 years. Not much seems to have changed since I used SQL Server 15 years ago. Yeah, sure, some important new features, but the whole thing still has this smell from the Windows 2000 era.

So I miss a lot of features from my beloved PostgreSQL. I have to say that PostgreSQL is probably faster than SQLServer if it runs under Linux or any *nix system. But PostgreSQL probably doesn’t has the best performance under Windows. So I don’t recommend switching over unless you can move the DB to a *nix server.

Well, let’s go to the task!

IF (NOT) EXISTS clause

When you’re used to PostgreSQL, one of the most used and less thought feature is the IF EXISTS / IF NOT EXIST clauses of several commands. Seems stupid, but this does not exist in SQLServer and you have to fallback to If statements and querying the internal schemas. In PostgreSQL you can do:

  • CREATE TABLE IF NOT EXISTS
  • DROP TABLE IF EXISTS
  • ALTER TABLE IF EXISTS
  • ALTER TABLE DROP FIELD IF EXISTS
  • CREATE OR REPLACE FUNCTION
  • ALTER VIEW IF EXISTS
  • ALTER INDEX IF EXISTS

Probably the list is longer, but you get the idea. Simple SQL statements that do what you want. Also the CREATE OR REPLACE FUNCTION is handy, as it can overwrite the previous function (or view) given it is compatible in arguments.

Column dependency tracking

So a function or a view, and it does refer to other tables and its columns. You rename or change the type of those, ¿what happens to your views and functions?

In SQLServer they may fail when called as the old name does no longer exist. You have to remember to update them to keep consistency.

In PostgreSQL this is done automatically, and if not possible, the ALTER command will fail straight away. No inconsistency.

Of course, if you had a function that runs in Python, or a function that starts a query from a text string, those are not translated.

Really renaming fields and tables

This maybe surprising to some people. No, SQLServer does not have capacity to rename fields or tables. It provides some special functions, out of the sql standard, that more or less does the job. But what they do? They copy the data and drop the old one. This means ugly locks and bad performance.

In PostgreSQL, following the SQL standard you have ALTER TABLE xyz RENAME TO ijk. Simple, fast (no rewrite) and almost lock free.

One stupid thing I would like to see on PostgreSQL someday is reordering columns, in such a way that does not affect disk layout. Not very important, but would be convenient sometimes to ensure that “SELECT * FROM x” always returns the same columns in the same order across all your servers, because after several ADD COLUMN the logical layout might look confusingly different.

Datatypes

Oh, this is so 1999 for SQLServer. While it has new types conforming to standards, still somehow manages to favour the old ones. We can see things like WCHAR which comes from Windows Api for Wide Chars (UTF16) (Seriously?) so the regular CHAR is still 8 bytes ASCII. Damn, is this people serious?

No, that’s not how it should be. The SQL Standard talks about characters, not about bytes. PostgreSQL gets this right. Any char/string-alike type is encoding-aware and it supports any character on it. Also has support for many, many encoding and languages for collation. Its default behaviour just works on most languages if not all. And you can set COLLATION per server, per database, per table and per column. This means that is smart enough to compare equally a,á and à given a spanish collation.

Speaking of collation, why the hell SQLServer says that “a” equals to “A”? I would understand it on a LIKE operator (but I don’t agree, PostgreSQL has ILIKE to trigger that), but c’mon, on an equals operator? I have seen people blaming Javascript for far less inconsistency.

PostgreSQL has a whole load of types that can be expanded with extensions as well. They are super useful; I’ll put a few examples:

  • bytea: Array of bytes. Save entire files in PostgreSQL, don’t waste an extra single byte on encodings or hexencoding.
  • interval: of time. Oh, I love this “now() + ‘3 days 2 hours’::interval”. Flexible, with tons of useful operators. Datetime pain just is easy in PostgreSQL
  • timestamp with timezone: Old regular datetimes but with TZ info. Self explanatory, just I ask myself why this is not in SQLServer or in Javascript.
  • jsonb: JSON data, but binary stored. Hah, with support indexes to get subkeys and items on arrays, so you can play with NoSQL while retaining the PostgreSQL speed. And tons, huge tons of functions to transform tables from/to, fields, arrays… endless.
  • numeric(x,y): Tired of losing precision for your accounting apps? Try numeric! They have base 10, like our decimal numbers, and they have an astonishing precision. The only downside is, they are mathematically more correct than what some of us would like (if you call that a downside)
  • box, line, point: There are a few geometrical types in standard PostgreSQL. They may serve for range queries but also they are handy when you are dealing with points in space, like GPS locations. Indexes also work on all of them.
  • Arrays: of almost anything. Instead of jumping to your many-to-many table, you can have these list of primary keys on your main table, avoiding you to do extra queries. And guess what… they are indexable as well, you can ask things like “it contains A” or “it does not contain A” or “it has exactly A,B,C”, etc.
  • Range types: of numbers, dates and timestamps. Useful for schedules and calculating overlapping… in an indexed fashion.
  • Enums: The best of two worlds, you ensure that a column only has some possible values, without foreign key/table, and it is efficient as an integer column.

Index Expressions and functions

I was suprised that SQLServer did not come with this highly needed feature. Instead, you create computed columns stored on disk (which waste space) and then index them. PostgreSQL in the other hand has no sense of stored computed columns, but you can roll your own easily with triggers.

But, as for indexing, you can in PostgreSQL index the result of a calculation or the result of a function, given the function is pure and you don’t use any other column that wasn’t on the table.

This is useful, because sometimes you need to recurrently filter a query by an expression, for example stock_qty – reserved_qty <= 0. In PostgreSQL you just index “stock_qty – reserved_qty”.

Speaking of these, let me add the WHERE part of an index, to create a partial index. So if you have billions of rows and your app is concerned about a tiny fraction each time, having an index still means iterating over O(log n) records. But if you do a partial index that matches your WHERE expression, you just skip all the uninteresting rows. Partitioning? I tried that, and compared to partial indexes they give almost zero benefit compared to partial indexes up to 50 million rows. Partial indexes are easier to maintain and create, and you can have as many as you want. Can you partition a table by 6 dimensions at the same time? Does make sense?

Array related functions

Yeah, I wrote before about arrays, and they have functions, right? And they are indexed… fine. But there are a full load of them that they need a special mention. Or at least, there is just two: array_agg and array_to_string.

There is this common case: You are joining the table X to A, B, C and D. They are all one to many relationships from X. And we want just a single row in the output per row in X, and all/some columns of every other table. This is usually done to create nice CSV exports of complex data. How do you aggregate these tables in a way that you don’t lose data? Just concatenate all values in a comma separated string.

In PostgreSQL, just do “SELECT array_to_string(array_agg(a.col1), ‘, ‘) as a_col1” and done!

Now, search to do the same in SQL Server, it is possible, it does work. Seriously, search for the solution, I’ll wait. Now multiply that code for how many tables and columns we want, imagine the result. How many pages long is the resulting SQL?

And I don’t want to end this section without an honorable mention to “unnest”. This is the swiss army knife of the arrays, transforms an array into several rows, and in the recent versions of postgres, it can add the number of the record. You can pack a table into an array or unpack an array into a table and do joins on them.

Why we do want this? well, let me add another array function: generate_series. Somehow close to the range(x) function in Python, returns a set of integers from number to number, counting. So we have a table that contains labels for printing, and we do have a column with the number of copies. We want to produce a query that repeats the row N times depending on this column and get the record number (copy number). With generate_series and unnest, it creates the rows for us, numbered, and ready to consume for any reporting tool.

Conclusion

In which year are you? in 1999 or 2018? Get PostgreSQL and jump 19 years to the future like a boss!

And by the way, this list hasn’t ended yet. Just I thout the post was long enough already.

Stay tuned for more!

Aprendiendo con Kerbal – DeltaV y TWR

Una de las primeras cosas que nos damos cuenta al jugar Ksp es que cuando queremos poner en órbita algo pesado, tiende a fallar o a haber menos combustible del esperado. O en el mejor de los casos, que terminamos con una barbaridad de cohetes para subir la carga al espacio. ¿Porqué pasa ésto?

Hay una relación que se conoce como la ecuación del cohete, que es una fórmula que nos dice cuanto combustible hace falta para subir a órbita una carga con un peso determinado. Y esta relación sube exponencialmente, al tener que empujar el combustible restante para tenerlo disponible, cada vez que agregamos más y más combustible se vuelve más ineficiente.

640px-rocket_mass_ratio_versus_delta-v-svg

Para verlo claro, lo mejor usar el mod Kerbal Engineer Redux (Ker) que nos muestra durante el diseño la cantidad estimada de DeltaV.

¿Y qué es el DeltaV? Sencillo. Para una nave que tengamos, orbitando en el espacio, es la cantidad de velocidad que puede conseguir. Entonces, si nuestra nave tiene un DeltaV de 4000m/s y estamos orbitando a 500m/s, eso significa que podremos acelerar hasta los 4500m/s y nos quedaremos sin combustible. Si aceleramos en dirección contraria entonces solo 3500m/s.

Este número es muy valioso porque nos dice si cierta maniobra o plan es realmente factible. Elimina por completo el peso de la nave y las fuerzas y nos deja solo el dato más importante. El DeltaV equivaldría en los coches a la autonomía en kilómetros. Antes de viajar a Barcelona miramos si hay suficiente combustible, pero no lo vemos en litros, sino en kilómetros que el coche es capaz de hacer. El DeltaV es exactamente lo mismo, pero para naves espaciales. Y en el espacio la autonomía la medimos en metros por segundo (velocidad), ya que para cambiar de una orbita a otra hace falta acelerar hasta cierta velocidad.

Sabiendo esto, y experimentando en kerbal, sabemos que para alcanzar una órbita de forma segura necesitamos un DeltaV de 4200m/s. Este valor sale de la experiencia en el juego pero se puede calcular el mínimo, aunque aquí la idea es ir con algo más de sobra por contar otros factores como la fricción y el error humano.

De vuelta al problema inicial, la cantidad de combustible necesario para poner en órbita una carga crece exponencialmente con el peso de la carga.

Veamos unos ejemplos:

  • Con 100Kg, necesitamos 26.4 toneladas adicionales
    Sin nombre
  • Con 1t (una tonelada), necesitamos 56t adicionales
    Sin nombre
  • Con 10t, necesitamos 328t
    Sin nombre
  • Con 100t, necesitamos 3354t
    Sin nombre
    (Ya casi no me cabe ni dentro del garaje para diseñarlo)

Llega a un punto en el que, aumentar más la carga a poner en óribta se vuelve irrealista. La cantidad de cohetes necesarios y su tamaño ni siquiera cabrían en el “launchpad”. La solución “kerbal” es hacerlos despegar en la pista de aterrizaje, en vertical, simplemente porque es bastante más grande. Pero en la vida real esto es inviable.

Es por esto que cosas como la estación espacial internacional (IIS) a pesar de ser poco más grande que un avión 747, se ha montado a través de muchos lanzamientos en lugar de levantarla con uno solo.

Y con esto quiero comentar también otro dato interesante, el TWR (Thrust-to-Weight-Ratio), que es la fuerza de empuje por unidad de peso del cohete.

Al igual que el DeltaV, es un valor importante que elimina muchos factores, como es el peso del cohete y la fuerza realizada, para obtener algo útil, la cantidad de aceleración que el cohete puede generar, comparada con la fuerza de gravedad de Kerbin. Un TWR de 1.00 significa que es capaz de levantar exactamente su propio peso, o dicho de otro modo, que se quedaría estable en el aire sin subir ni bajar. Un TWR de 2.00 quiere decir que el cohete acelerará hacia arriba a 1g. Si el TWR es de 4.00 quiere decir que acelerará 3 veces más que la fuerza de la gravedad. Un pasajero de un cohete notará la misma fuerza de gravedad que TWR tiene el cohete. Esto es, para TWR 4.00, el pasajero notará 4g de fuerza empujando hacia abajo.

Es importante porque, bajo la gravedad, cuanto más tiempo estés bajo sus efectos más combustible desperdicias, por lo que salir rápido también es crucial. Obviamente con un TWR de 1.00 no vas a ningún sitio, porque no te mueves, pero gastas todo el combustible. Con un TWR de 2.00, en el tiempo que tardas en salir (unos 2 minutos), la gravedad de la Tierra o Kerbin (son la misma), se ha comido más de 1000m/s de tu DeltaV, por lo que tendrás que cargar más combustible de la cuenta. En cambio, con un TWR de 4.00, tardas mucho menos (unos 30 segundos) y la cantidad de DeltaV perdida será la cuarta parte, por lo que necesitas menos combustible al final.

Con lo que a más TWR, mejor. Pero para tener un TWR más grande hace falta un motor más pesado, por lo que también rebaja el DeltaV total. Así que con un DeltaV de al menos 2.00 por lo menos se puede salir decentemente.

Con un TWR de 1.06, apenas despegas y se tarda sobre 3 minutos en salir (y porque el TWR sube a medida que se vacía el combustible), y a la gravedad le da tiempo de quitarnos 1500m/s de DeltaV en la subida.

Es por eso que en Kerbal, para aterrizar, muchas veces se utiliza una técnica conocida como Suicide Burn, para minimizar el uso de combustible. Pero de eso hablaré otro día.

 

 

NoSQL databases – what are they good for

From time to time I hear people talk about how NoSQL might be a good fit for their problems. But, most of the time they didn’t have tested properly both Sql and NoSQL products to have a good idea of what is better for their specific needs.

Long story short, NoSQL are good only for very particular problems, while regular Sql is good for almost everything.

First of all, where we should consider NoSQL? If we have to spread data across several servers because it doesn’t fit one, we don’t have a need for ensuring consistency of the data, and we are sure that our data hasn’t a lot of relations, then NoSQL may be a fit, given your problem fits all three criteria.

The main issue on NoSQL is how they are marketed, everyone talks about where they are better than Sql but forgets to comment the shortfalls, or where Sql is just the best tool. This causes people to have a skewed view of them. Also some of the supposed benefits like being schemaless are things that can actually be done in Sql databases.

Let me put this straight: NoSQL is not faster than Sql, does not write faster nor read faster under the same conditions. Schemaless can be partially archieved in Sql, so it can solve most of the problems related. NoSQL indexes and relational searches are poor. Sql syntax is much more powerful than any NoSQL.

So, where is actually NoSQL good?

Indeed there are a lot of use cases where NoSQL is preferred. Let’s talk about a few examples.

Let’s say that we already have a sql database, but, because we’re replicating this database and/or logging all changes and we need this database to be consistent so it is configured to ensure writes on disk. We may want for some new feed of information which is very fast and huge, that does not touch the sql database until preprocessed and/or shrank accordingly. This claims for a new database, but for most products if not all we cannot set different levels of atomicity, logging and replica per database (or is not desirable at all) then our best option is to use a different database server. It could be sql again, but given that’s for just this kind of data, NoSQL databases may be the best fit. (maybe just Redis is enough)

Another common case is when some data requires a different locking policy, a much lighter one. For this scenario NoSQL is better because it is usually optimistically locking. Be careful as usually it is a last write wins scenario.

But the most common case for going for NoSQL is where your data hardly fits a single computer. If it is 10Tb or more and you expect it to grow a lot, going NoSQL can be easier later when you want to shard the data across several computers. This can be done on some sql databases but still today it is very custom and hard to setup. If you think that will never surpass 100Tb, you could think about using regular sql and add a few disk on your server until you get the capacity you need. Even with postgresql you could partition tables and move them to different NAS servers using the tablespace trick.

Back when NoSQL was introduced, most of ther benefits were almost impossible to get on regular sql database. But nowadays, some of the sql databases do have solutions for most things. PostgreSQL now even has Map & reduce a like behavior where many servers are involved. As I said before, these are still a bit hard to setup, so still NoSQL is a good option for simplicity of configuring sharding.

About speed, every real benchmark that tests the different db’s in the same conditions is going to find that NoSQL is certainly slower in a single node. That’s because the advertised speed from NoSQL comes from not ensuring the writes on disk. So as soon as you configure any sql product to behave as the same, the performance is not only identical, it is actually way better for regular sql databases.

But you may think that as soon as you have a second server things may be different, as you have now twice the processing power. That’s not realistic, as parallelism comes in a cost, as when we do threading, there’s a performance penalty. Until you don’t have about 3-5 servers to parallelize the task you may not be able to see any actual benefit compared against regular sql with just one server, as sql databases are faster, you first have to overcome that before you actually see a reasonable gain.

And, if you care just a bit on your data, you will not want to have your data split in 5 servers with no backup, right? If one fails the disaster would be interesting to say the least. So you may want to duplicate by clustering into other 5 more. So you now have 10 servers to perform better than your single node with a regular sql database.

Most people like the idea of going NoSQL just because they are scared of SQL, and because JSON-alike things seem easier for newcomers than complex CREATE TABLE statements. This is one of the main reasons on why they gain popularity. But SQL is a technology that is well proven, it is very old and has been improving every year, and the SQL products are damn fast.

So I’m not saying that we should not use NoSQL. What I’m saying here is that behind every decision we should do our own tests before and investigate properly each solution before it is too late and we’re stuck with a product that is not appropiate for the task we have.

 

Ejecutar programas como servicios en linux

 

Una tarea bastante común en Linux es hacerse un programa con Bash o Python y querer ejecutarlo o bien dentro de Cron cada cierto tiempo, o como un servicio ejecutándose permanentemente.

En este artículo no voy a describir cómo se hace ninguna de estas dos cosas, ya que la web está llena de tutoriales que explican al detalle cómo hacerlo. En lugar de eso, me quiero enfocar en el error más habitual que aparece: Cuando se ejecuta, parece que no hace nada, o se cierra inesperadamente.

Si habéis agregado servicios al cron o como servicio, es casi seguro que esto os ha pasado. El programa se inicia pero se cierra al rato, o parece que no haga nada de nada. En cambio al ejecutarlo manualmente, funciona.

Vamos a ver una lista de los errores más habituales que causan esto, el porqué, y cómo solucionarlo.

Cambios de usuario

Este error es muy básico y no necesita demasiada explicación. Si el servicio lo va a ejecutar root, deberías comprobar desde la cuenta de root que funcione. Si es un cron para otro usuario, pruébalo con ese usuario y verifica que funcione.

Cambios en la carpeta de trabajo

Muchos programas no se ejecutan correctamente si no están en la carpeta adecuada. Este es otro error de principiante. Muchas veces se prueba el programa en la carpeta que toca, pero no nos damos cuenta que cron o el servicio se inicia desde otra. Hay que verificar que el programa arranque independientemente de en qué carpeta esté.

Adicionalmente, hay que verificar que no estemos jugando con enlaces simbólicos para ejecutar el programa, o si es el caso, comprobar que al ejecutarlo a través del enlace simbólico, desde cualquier carpeta, el programa se ejecutará correctamente. Algunos programas intentan detectar que en qué carpeta están instalados en el momento que se inician, y algunos no están preparados para esta situación.

Con enlaces duros, puntos de montaje con bind y similares, los programas lo tienen casi imposible saber dónde están instalados a no ser que se les indique al arrancar dónde tienen que leer. Dependiendo del programa (hay muchos que no necesitan nada), este tipo de enlaces puede hacer que sea imposible que encuentre sus ficheros.

La variable de entorno PATH

Este es de los más comunes. Cuando se ejecuta como servicio o desde cron, la variable de entorno PATH, que es donde se almacenan las distintas rutas donde buscar un ejecutable, cambia respecto a cuando tenemos una shell interactiva.

Las consolas interactivas tienen una variable PATH con muchos directorios para nuestra comodidad, pero cuando se lanza en modo no interactivo o directamente desde otros procesos, la variable PATH suele tener pocos directorios, o a veces, ninguno.

Comprueba que el comando que quieres lanzar funcione aún sin ningún directorio en el PATH.

Otra solución, en el caso de cron y servicios, es especificar una variable PATH para estas llamadas, ya que lo permiten.

Ojo con otras variables de entorno, igual tu programa busca JAVA_HOME o X_DISPLAY y éstas no van a estar definidas.

Programas que conectan a un DISPLAY

Algunos programas tienen modo gráfico, que se puede usar opcionalmente. Otros son parte de una suite más grande y aunque no tengan parte gráfica, las liberías siempre se conectan.

En este caso toca crear un FrameBuffer y conectarlos a él. Dadle un vistazo a Xvfb.

Redirigir las entradas y salidas estándar

Un proceso en Linux tiene tres PIPES: stdin, stdout y stderr. Si alguno de éstos está conectado a otro proceso y éste se cierra, el programa recibirá una petición para cerrarse también. Esto se conoce como SIGHUP.

Para evitar ésto, lo mejor es siempre redirigir todas las entradas y salidas a otros ficheros:

$ programa </dev/null >/tmp/log 2>/tmp/log.err

También podemos juntar las dos salidas de errores y estándar en una sola, pero para depurar es mejor dejarlas independientes si el programa no se mantiene abierto

Evitar SIGHUP

Cuando un proceso se cierra, “cuelga la llamada” a los procesos a los que esté conectado. Esto es lo que hace que en este ejemplo, tail deje de procesar en cuanto grep termina:

$ grep texto * | tail

Pero también es lo que hace que grep deje de procesar en cuanto head ha realizado sus 10 líneas:

$ grep texto | head

Para programas lanzados desde la consola con ampersand al final, se puede usar disown:

$ programa &
$ disown

Para otros programas, se puede usar nohup:

$ nohup programa > log.txt

Si nuestro programa está hecho en Python, podemos consumir la señal SIGHUP e ignorarla:

https://docs.python.org/3.6/library/signal.html (ver ejemplo al final de la documentación)

Desasociar el proceso del proceso padre

En un cron no suele ser habitual pasar el proceso a segundo plano, pero en un servicio es esencial. Cuando ésto pasa, el nuevo proceso aún hereda del padre, y cuando el padre muere, por defecto, se matan todos sus hijos. (Sí, suena fatal, lo sé)

Para evitar esto, hay que conseguir desasociar el nuevo proceso del padre, para que cuando el padre termine, el nuevo proceso pueda seguir corriendo, independientemente.

Esto se consigue con un doble fork. Hay algunas cosas más que tener en cuenta, pero dejo algunas referencias aquí:

http://blog.n01se.net/blog-n01se-net-p-145.html

http://thinkiii.blogspot.com/2009/12/double-fork-to-avoid-zombie-process.html

https://gist.github.com/Jd007/5573672

Pero lo más sencillo es usar las herramientas que vienen en la distribución, ya que al lanzar el nuevo servicio, normalmente hay opciones para que lo “daemonizen” por nosotros. Véase en debian start-stop-daemon con su opción -b:

https://manpages.debian.org/stretch/dpkg/start-stop-daemon.8.es.html

Una solución más sencilla: Supervisor

Todo esto está muy bien, pero es bastante laborioso de depurar. Existe un programa llamado “supervisor” que hace la creación de servicios mucho más sencilla, se le especifican los ficheros de log, la ruta al ejecutable, y se encarga de encender y parar el servicio. Ésto hace que crear servicios para cosas pequeñas (personales) sea mucho más sencillo que escribir un servicio correctamente.

https://serversforhackers.com/c/monitoring-processes-with-supervisord

http://supervisord.org/

 

Kerbal Space Program – Un juego para aprender exploración espacial

Hace tiempo que descubrí este increíble juego y sigo completamente enganchado a él. Muchos no lo conocéis y se merece un artículo en mi blog.

Kerbal Space Program (abreviado KSP) es un juego de “simulación” de exploración espacial. Si os gustan los simuladores de aviones o juegos de cazas seguramente os guste. Si os gustaban de pequeño los LEGO o TeNTe, también os gustará.

La premisa de KSP es que hay un sistema solar muy parecido al nuestro, que tiene un planeta con vida inteligente (marcianitos) y nosotros estamos a cargo de su agencia espacial, algo así como la NASA pero extraterrestre. Nuestro objetivo es explorar los distintos planetas, conseguir más datos sobre ellos y investigar nuevas tecnologías con ésta información.

Captura de pantalla -2018-08-26 10-16-52
Centro espacial de Kerbin

Este juego tiene su similitud con Minecraft al no tener realmente un objetivo definido, que se puede jugar como uno prefiera, y siempre se le pueden echar más horas, no tiene final y las posibilidades son infinitas.

Para mí, lo más interesante de KSP no es en sí el jugarlo, sino lo que se aprende con ello. El juego realmente es un simulador físico y orbital, nos permite diseñar nuestras propias naves, cohetes, aviones y rovers; y después lo más divertido es volarlos. En el proceso del juego se aprenden cosas como mecánica orbital y la ecuación del cohete, sin matemáticas, sin conceptos aburridos. Sólo jugando, practicando y a base de matar a los pobres kerbals en el proceso.

El juego está totalmente en clave de humor, los kerbals (la raza que habita en Kerbin) son tratados como seres bastante estúpidos, los pobres no saben dónde se están metiendo. Siempre echas unas risas jugando y leyendo algunas descripciones.

Tiene tres modos distintos para empezar una partida:

  • Sandbox: acceso a todo, para practicar
  • Science Mode: modo ciencia, tienes que recoger datos científicos para poder acceder a las distintas tecnologías
  • Career Mode: modo carrera espacial, donde además de recoger ciencia tienes unos fondos y cumplir con contratos para poder cobrar.

Cada uno tiene lo suyo, pero va en el estilo de cada persona qué modo quieres jugar. El modo de carrera espacial sería el más difícil y completo, y el de Sandbox es el más sencillo. Además tienes dificultades también, para hacer la física más amigable.

¿Alguna vez te has preguntado porqué se tardan años en llegar a Marte? ¡Pruébalo en KSP! ¿Qué es eso de asistencias gravitatorias? ¡Pruebalo en KSP! ¿Porqué se empeñaron en subir la estación espacial a módulos con distintos vuelos? ¿No era más sencillo ponerla en órbita de una vez? ¡Pruébalo!

KSP es mucho más realista de lo que puede parecer a simple vista, incluso con montones de mods de la comunidad instalados, no hay absolutamente nada que sea irreal. Por supuesto algunos mods contienen piezas que son injustamente potentes, pero la gran mayoría son tecnologías reales, con potencias y pesos reales (o en su defecto, son futuras tecnologías teóricamente posibles, siguiendo las mejores aproximaciones que conocemos de cómo serían)

Kerbin (el planeta dónde habitan) es un símil de la Tierra, con una atmósfera y gravedad casi idénticas. Por facilitar las cosas, Kerbin es bastante más pequeño que la Tierra, pero los demás parámetros son idénticos. Otros planetas también tienen sus réplicas:

7eaf3a8696a9ef373e19327de4bcb8d8-d5jjsd8Kerbol sería el Sol, Moho es Mercurio, Eve es Venus, Kerbin es la Tierra, Mun es la Luna, Duna es Marte, Jool es Júpiter, Lathye es Europa, Eeloo es Plutón. Por supuesto no son iguales, no están todos los planetas, ni son todos los que están. En definitiva, si quieres probar en KSP un vuelo tripulado a Marte, tu objetivo será Duna.

El juego vale 40 euros ahora mismo, y vale muchísimo la pena. Diversión asegurada por años. No es un juego de los que le echas 100 horas, lo terminas y ya. Es un juego que en unos meses te va a apetecer abrirlo de nuevo y probar alguna cosa nueva que se te ha ocurrido. Está en Steam y funciona tanto en Linux como en Windows.

Recomiendo mucho seguir el canal de Youtube de Scott Manley, es un entusiasta de la exploración espacial y de Kerbal Space Program. Siempre está explicando las últimas noticias en exploración espacial y muchas veces luego prueba los conceptos en Kerbal Space Program.

Si tienes alguna idea estúpida, muy estúpida, nunca es lo suficientemente estúpida para Kerbal Space Program. Por ejemplo: ¡un aeropuerto volante!

Si os apetece jugarlo, recomiendo mucho instalar mods en él, por lo menos para agregar algo más de información útil en pantalla. De lo contrario, vamos un poco a ciegas intentando adivinar si tenemos suficientes cohetes para entrar en órbita o para llegar a destino.

Para los mods, la aplicación nº1 es CKAN, también funciona tanto en Linux como en Windows: https://github.com/KSP-CKAN/CKAN/wiki

Los mods, yo recomiendo los siguientes, en orden de más necesarios a menos:

  • Kerbal Engineer Redux: Ofrece un montón de información útil, al diseñar nos calcula el Delta-V (aceleración total posible). Al volar nos da información de órbita, Thrust-to-weight ratio (fuerza de los motores) y muchas otras cosas útiles.
  • Transfer Window Planner: Nos planifica los viajes a otros planetas. Los planetas tienen que estar alineados de una forma específica y hay que salir de órbita de una forma determinada. Este mod lo calcula y nos ofrece los costes de salir de Kerbin en cualquier momento, haciéndonos saber cual es la estimación de combustible según el momento de salida y el tiempo de viaje.
  • Kerbal Alarm Clock: Nos avisa cuando un evento está a punto de suceder. Cuando planificas un viaje a otro planeta, éste dura años, y si tienes varios vuelos a la vez (como es habitual) se te puede pasar que tenías otra nave para realizar una maniobra en un momento dado. Este mod ayuda mucho a que no se te pasen.
  • Precise Manuever: Agrega una interfaz para configurar las maniobras con datos y no a mano alzada como es habitual en el juego.
  • SCANSat: Agrega la opción de antenas para satélites que escaneen los planetas. Después de varias pasadas obtienes datos de altimetría y de recursos que puedes minar, por ejemplo.
  • Kerbal Inventory System: Permite equipar cosas a los kerbals y llevar piezas en un contenedor sin que realmente estén en el diseñador.
  • Kerbal Attachment System: Cuando ya tienes instalado el anterior (KIS), éste permite que los kerbals construyan sobre el terreno.
  • TweakScale: Si vais a ir a lo grande, recomendado. Al final faltan piezas para hacer naves enormes, y terminamos usando 20 o 30 motores, haciendo que el juego se ralentice mucho. En lugar de eso, con TweakScale, ponemos un par de motores 4 veces más grandes y a funcionar. Más rápido, más sencillo y funciona mejor. TweakScale considera la masa y las fuerzas de cada pieza para que al aumentarlas o reducirlas sigan teniendo las propiedades adecuadas de cada escala.

Esta selección de mods es bastante buena, ninguno de éstos debería causar ningún problema en el juego. Yo tengo 70 mods instalados ahora mismo y funciona bastante bien.

Hale, os dejo con mi estación de minería y refinado, cuadricóptero eléctrico, funcionando con un motor nuclear:

Captura de pantalla -2018-07-15 08-20-55