This is rather a theoretical interest for me for now (what else to do Friday evening) , but I see how it can be used in current dual-licensed mixed open / closed source storage engines MySQL world.

So problem is:

Let’s keep MySQL aside for simplicity and imagine we have fully open-source GPLvX licensed “MoonOffice” software. MoonOffice uses libsupercompress library which also distributed under GPL, and provide two functions: “superCompressFile”, “superDecompressFile”. MoonOffice can be both statically or shared linked with this library. This all fine.

Now imagine one provides library libquickcompress, which is closed sourced, available only in binary formats .so and .la, but the license on it is “use it as you want, link it with whathever you want, distribute it as you want”. Of course library also exports two functions “superCompressFile”, “superDecompressFile”.

Now questions: can we link our GPLed “MoonOffice” with libquickcompress ? Can we distribute binary build of MoonOffce linked with libquickcompress ? What is license of final binary ?

May be it is simple question and answer is obvious, but I am not sure what is correct answer.

---

Entry posted by Vadim | One comment

Add to: | | | |

Wille Faler has created an excellent list of best practices for building scalable and high performance systems. Here's a short summary of his points:

Offload the database - Avoid hitting the database, and avoid opening transactions or connections unless you absolutely need to use them.

What a difference a cache makes - For read heavy applications caching is the easiest way offload the database.

Cache as coarse-grained objects as possible - Coarse-grained objects save CPU and time by requiring fewer reads to assemble objects.

Don’t store transient state permanently - Is it really necessary to store your transient data in the database?

Location, Location - put things close to where they are supposed to be delivered.

Constrain concurrent access to limited resource - it's quicker to let a single thread do work and finish rather than flooding finite resources with 200 client threads.

Staged, asynchronous processing - separate a process using asynchronicity into separate steps mediated by queues and executed by a limited number of workers in each step.

Minimize network chatter - Avoid remote communication if you can as it's slower and less reliable than local computation.