tbingmann

KPI #1: actually know something about your technology

Interesting. I have a theory that most historic shifts are mainly due to some technological advancement or invention, and not mainly due to politics. For example, Nazi Germany may have been the result of the invention or mass distribution of the radio as a method of influencing a nation. It is known that the Romans conquered Europe due to military strategy and superior iron weapons. The list goes on and on, however, history books tend to focus only on the sociological or political story.

There is (at least) one important missing: the Simplex Algorithm, or more generally algorithms for solving linear programs (LPs). These are used every day to optimize highly complex problems in real world economics.

Sorry, but this is another really bad comparison to Venice. These cities have nowhere near the history of Venice as a medieval trade metropolis, nor are they actually built on islands in a lagoon. If you must compare a city with lots of canals to a European counterpart, at least take Amsterdam.

Whenever I read something like this I have a bad feeling about it. They are trying to get "C/C++" performance in Java by bypassing all the JVM's management and garbage collection. They even basically reimplemented malloc() for memory heap management. Why not just ditch Java itself?

Best ask them first via email.

Slack, Zulip, this feels like we are back in 1999, when the internet was divided by ICQ, AOL Instant Messanger, Windows Live Messanger, and Yahoo Messanger. (Instant/Live was a plus back then). And the only innovation over IRC was a backlog and buddy list. I wonder when the Trillian of Slack+Zulip will come out. I hope Trillian (which still exists) is already working on it.

Looks like a list of familiar titles. I already read 19 of the 32, do I have to worry? They were very good books, though.

It has electrolytes!

The article is completely by side the point. He's basically ranting about how they can't test systemd on all distros, because every distro does things differently. How to fix it? Virtualize distros, yay. That may fix your problem, but no one else's.

The real point is that, due to distro fragmentation, Linux gives the casual user an inconvenient shared library linkage experience. At the same time the distros are really good as packaging software, which gives us the "one-click install" experience we're so use to. But they do so, at the price of compatibility, so we have the current distro lock-in situation.

Anyway, as an upstream software developer, I see the medal from the side of library linkage: when my program starts, the dynamic linker resolves this big list of symbols that my program contains and finds me matching libraries. You can extend this paradigm to icons, locale, and other support files as well.

So who tells the dynamic linker which symbols to match? Well, the contents of the shared libraries, and these already contain versioned symbols (e.g. this memcpy@1.0 does this, memcpy@1.1 doesnt do that anymore). The easiest solution to the matching problem is static linking. But that's not what we really want, because we may actually want to replace symbols with better versions (due to security fixes, faster implementations, super-set of features, etc).

And who versions symbols? Well, usually the upstream developers of the important libraries do. And they do that somewhat remarkably well already, but it could be better. If your program uses an upstream that doesnt version things, well, bad choice, static linking is probably the best solution here.

So what I would propose, is to move the problem down to a linkage problem, with better consensus between binary creators and upstream authors on how to version symbols. And if my system currently doesnt have a matching symbol installed? Just download it from the distro's well-versioned repositories, maybe not the whole gtk+ library, but a diff of it to another version.

We would then in the end not have a package installer, but a fetcher-of-missing-versioned-symbols-for-a-binary installer. But this model is pretty far fetched, since the current method of compiling code into monolithic shared libraries is much simpler. On the other hand, the linux dynamic linker is already very intelligent, maybe it's time for the large distros to cooperate on this level.

I made a video of how the algorithm works: http://youtu.be/NjcSyD7p660

To make it I needed a C++ version with iterators, which I though would be faster. But it is still about 20% slower than stable_sort for the default random input test. It probably also stays the same for other inputs.

In a nutshell: to keep an index into an array of size n requires log_2(n) bits. Thus any algorithm, which keeps even just one index into the input takes Omega(log n) space. Yay for pedantic asymptotics.