Bitcoin – Money Decentralization

With Bitcoin on the rise recently (currently priced at $900+), I thought I’d share the link to this article – Bitcoin – Money Decentralization – which provides some insight into how Bitcoin works and some core principles behind it.

The article is written more from the Computer Science perspective rather than an economic/financial one, some of the economic details might be oversimplified.

The two main aspects that make Bitcoin different from a modern monetary systems, like US Dollar or Euro, are the following:

  1. Decentralization: There is no central entity that prints (mints) money, but rather the money is being mint by the crowd. This makes Bitcoin a decentralized system.
  2. Anonymity: People who use Bitcoin hope that their identity would not be revealed, in contrast to the usual way we all buy commodity over the internet using our credit card, we have to supply our personal details to be verified against the bank who treats our account.

SC-IM – Spreadsheet Calculator Improvised

Here is an interesting project – SC-IM, or Spreadsheet Calculator Improvised, which is an ncurses spreadsheet program for terminal.  Here are some of the features:

  • UNDO / REDO.
  • 65.536 rows and 702 columns supported. (The number of rows can be expanded to 1.048.576 if wished).
  • CSV / TAB delimited file import and export.
  • XLS / XLSX file import.
  • Key-mappings.
  • Sort of rows.
  • Filter of rows.
  • Cell shifting.
  • 256 color support – screen colors can be customized by user, even at runtime.
  • Colorize cells or give them format such as bold or underline.
  • Wide character support. The following alphabets are supported: English, Spanish, French, Italian, German, Portuguese, Russian, Ukrainian, Greek, Turkish, Czech, Japanese, Chinese.
  • Implement external functions in the language you prefer and use them in SC-IM.
  • Use SC-IM as a non-interactive calculator, reading its input from a external script.
  • More movements commands implemented !
  • Input and Output was completely rewritten.

A combination of interactive and non-interactive interface seems to be particularly useful.

GPL defense issues

A friend sent me a link to this email from Linus Torvalds to the Kernel Summit Discussion mailing list.  The subject of the conversation is the General Public License (GPL) and whether or not it should be enforced in courts.  Read the whole thing – it’s quite interesting.  Here are a few snippets just to get you started:

Let’s be clear about this: lawsuits destroy. They don’t “protect”.

Lawsuits destroy community. They destroy trust. They would destroy all the goodwill we’ve built up over the years by being nice.

And then this:

Because lawsuits – and even threats of lawsuits – makes companies way less likely to see you as a good guy. Even when you’re threatening
somebody else, everybody else around the target starts getting really
really antsy.

I talked to an Oracle lawyer a few months ago, and told him their
lawsuit just makes Oracle look bad. The lawyer was dismissive, and
tried to explain how it’s silly how people take lawsuits personally,
and talked about how layers _understand_ that lawsuits aren’t
personal, and that they are still friends outside the court.

I’m sure a lawyer can “understand” how lawsuits aren’t actually
something personal at all, but lawyers really seem to be the *only*
people who “understand” that.

The fact is, lawsuits (and threats of lawsuits) do not make for
friends. You just look like a bully.

Signs that you’re a bad programmer

Software Engineering Tips shares some tips on how to figure out if you are a bad programmer, and how to remedy that.

Signs that you’re a bad programmer

  1. Inability to reason about code
  2. Poor understanding of the language’s programming model
  3. Deficient research skills / Chronically poor knowledge of the platform’s features
  4. Inability to comprehend pointers
  5. Difficulty seeing through recursion
  6. Distrust of code

If you are not a bad programmer, check if you are mediocre one.

Signs that you are a mediocre programmer

  1. Inability to think in sets
  2. Lack of critical thinking
  3. Pinball Programming
  4. Unfamiliar with the principles of security
  5. Code is a mess

And, finally, here are some signs that you shouldn’t be a programmer.

Signs that you shouldn’t be a programmer

  1. Inability to determine the order of program execution
  2. Insufficient ability to think abstractly
  3. Collyer Brothers syndrome
  4. Dysfunctional sense of causality
  5. Indifference to outcomes

The article also suggests some alternative career paths for you.

Why are browsers so slow?

As a user of Opera browser in the good ol’ days, I share Ilya Birman’s pain

But I am not talking about rendering and scripts. I am talking about everything else. Safari may take a second or two just to open a new blank tab on a 2014 iMac. And with ten or fifteen open tabs it eventually becomes sluggish as hell. Chrome is better, but not much so.

… and this too …

What would you do today if you opened a link and saw a long article which you don’t have time to read right now, but want to read later? You would save a link and close the tab. But when your browser is fast, you just don’t tend to close tabs which you haven’t dealt with. In Opera, I would let tabs stay open for months without having any impact on my machine’s performance.

Wait, but didn’t I restart my computer or the browser sometimes? Of course I did. Unfortunately, modern browsers are so stupid that they reload all the tabs when you restart them. Which takes ages if you have a hundred of tabs. Opera was sane: it did not reload a tab unless you asked for it. It just reopened everything from cache. Which took a couple of seconds.

In fact, maybe it’s a good time to try out Opera browser again.  After all, the two primary reasons I’ve switched from it were:

  • Open Source.  This was back in a day when I was a zealot.  (Yeah, if you think I’m one now, you should have seen me in my 20’s.)  Now  I am much more calm about the licensing.
  • Rendering issues.  That was back when Opera had its own rendering engine and couldn’t quite keep up with all the changes on the Web.  Since then, Opera has dumped its Presto rendering engine in favor of Webkit (the same engine that Google Chrome, Chromium and Safari browsers are using), and then dumped Webkit in favor of Blink, which is like … erm .. new Webkit (?) or something like that.

So maybe it’s good enough in rendering department and I can have my performance and tab management back.  As Ilya mentions, no other browser came close to the tab management of Opera back in a day.  I frequently have a 30+ tabs open, and its only because that’s as much as Chrome can handle on my laptop.

Update: Tried out the latest version of Opera now for about half an hour.  I suddenly remembered another reason for why I’ve switched – fonts.  Default fonts configuration is far from optimal.  For multilingual pages (English and Russian) is more than horrific.  Oh well, I guess, I’ll have to wait some more.

How Linux got to be Linux: Test driving 1993-2003 distros

Here’s a trip down the memory lane – “How Linux got to be Linux: Test driving 1993-2003 distros“.  The article looks at some of the early Linux distributions, remember what was already in and what came later.  Complete with screenshots.

I don’t remember for sure which versions of which distributions I used in the early days, but Slackware, Suse, RedHat and Mandrake were definitely among those.  Slackware was probably my first one, when I found the floppies in the only book on Linux at my college library.  Then, somehow, I found RedHat (I think 5.1 or so) in one of the local computer shops.  Later I tried Mandrake and Suse, cause those were laying around at work.  But RedHat stuck with me ever since.  I think I’ve used pretty much every version, including the move to Fedora, CentOS, and even the Red Hat Enterprise Linux, which we had the licenses for at some of my early work places.

Fun times!

The True Reason Behind The 40-Hour Work Week & Why We Are Economic Slaves

The True Reason Behind The 40-Hour Work Week & Why We Are Economic Slaves” doesn’t really say anything new, but it explains things nice and simple.

We automatically accept a 40-hour workweek with meager hourly pay as normal, even though many work overtime and still struggle to survive. There are also those who make enough to live comfortably but are unable to request less hours—you either work 40 hours a week, or you don’t get to work at all. We submit when told what to wear, when we have to arrive and depart, when we’re allowed to eat, and even when we’re allowed to use the restroom. How is it we have come to allow this?

The 40-hour-work week came about during the Industrial Revolution in Britain when at one point workers were putting in 10 to 16 hour days and began to protest. Working situations for Americans began to worsen as well, and by 1836, labor movement publications were also calling for a 40-hour workweek. Citizens in both situations were so overworked, an eight-hour day was easily accepted. This system is unnecessary now, if it ever was, but we still accept it due to the effects of our capitalist society.

It goes over the relationship of inflation, debt and consumerism with a few historical references.  Good reading for anybody wondering why the paycheck-to-paycheck life cycle is difficult to change, no matter what’s the size of the paycheck.

Feature Flags in PHP

Today edition of the “Four short links” from the O’Reilly Radar, brings a quick overview of the different feature flag implementations.  It touches on the following:

  • Command-line flags, with the link to gflags.
  • A/B flags
  • Dynamic flags, which are more difficult
  • More complex systems.

I’ve dealt with feature flags before, but never found an elegant way to scale those.  Some of the issues that I came across were:

  1. Naming conventions.  With more and more features added to the system, naming things becomes more and more difficult.  Especially, when features cross over from one part of the system into another and need to be supported in different sub-modules.  In a way, this reminds me of the old argument in the blogging community about using hierarchical categories vs. flat tags, with categories providing more order and tags providing multiple paths to the destination.
  2. Modularization issues.  Feature flags are often need in the larger applications.  The kind that provides a lot of features (duh!).  But those large applications often consist of smaller parts, or modules.  Deciding whether or not to implement the feature on the application level, and/or on the module level is difficult. Especially if those module features will need to be later grouped into application features.

In terms of implementation, I haven’t used any special tools or libraries.  It was basically a set of configuration files, with feature variables defined per environment and altered during the deployment.

These days, something more robust than that is necessary for some of the projects at work.  Gladly, there are plenty of available tools to choose from – no need to reinvent the wheel.  For a good starting point, have a look at PHP Feature Flags website.  The ones listed so far are:

So, I guess, PHP is well covered when it comes to feature flags tools.  The above cover cookie-based, IP-based, URL-based dynamic features, configuration-based features, and A/B features.

The point now is to actually utilize them in the project.  After all, the lack of feature flags is one of the 5 toxic things for the scalability, as per this page:

  1. Object Relational Mappers (ORMs)
  2. Synchronous, Serial, Coupled or Locking Processes
  3. One Copy of Your Database
  4. Having No Metrics
  5. Lack of Feature Flags

I haven’t decided which library to use yet – will need to try them all and see which one is the most appropriate, but for now I don’t think I’ll dive as deep as cookie/URL/IP based features or A/B testing.  Even the simplest configuration-based implementation will be helpful.

Largest digital survey of the sky mapped billions of stars

Engadget reports:

An international team of astronomers have released two petabytes of data from the Pan-STARRS project that’s also known as the “world’s largest digital sky survey.” Two petabytes of data, according to the team, is equivalent to any of the following: a billion selfies, one hundred Wikipedias or 40 million four-drawer filing cabinets filled with single-spaced text. The scientists spent four years observing three-fourths of the night sky through their 1.8 meter telescope at Haleakala Observatories on Maui, Hawaii, scanning three billion objects in the Milky Way 12 times in five different filters. Those objects included stars, galaxies, asteroids and other celestial bodies.

Wow … this is mind blowing at the very least …

See the image above? That’s the result of half a million 45-second exposures taken over four years. They’re releasing even more detailed images and data in 2017 — for now, you can check out what the team released to the public on the official Pan-STARRS website.

 

HexChat IRC Client

Well, apparently I’ve been leaving under a rock for the last few years.  When it comes down to IRC clients, I’ve been mostly using XChat.  Turns out, XChat has been abandoned for years, and it’s still around mostly because Linux distributions care so much about it that they patch it and ship it.

As with anything in the Linux world, there are plenty of alternatives.  And one of them was right under my nose all these years – HexChat:

HexChat is an IRC client based on XChat, but unlike XChat it’s completely free for both Windows and Unix-like systems. Since XChat is open source, it’s perfectly legal.

HexChat is often shipped right next to where XChat is or used to be.  For Fedora users, it’s as close as “dnf install hexchat“.