Tag Archives: linux

Can Anyone Get Rich from Open Source?

Open Source Initiative Logo

Can any company make money from Open Source?  The idea of open source work is like charity – it’s a great service for the community, but it won’t make anyone rich like Bill Gates, Steve Jobs, or Larry Ellison.  That thought may be right and wrong.

One example was MySQL. It was not capable of beating, or even competing, with Oracle Database.  However, it was the cheaper (free) solution to run web sites for bloggers (like this one) or SMBs. Since then, Oracle decided to buy MySQL’s Innobase engine because of the large install base. The same with Java which was once touted by Sun Microsystems as the ideal platform for Enterprise open-source language, was acquired by default when the Oracle bought Sun. No doubt, Larry Ellison had a thought that with this many users, there was a potential revenue to be made.

A decade ago, there was a speculation that an open source operating system like Linux is a possible money maker.  Back then, enterprise customers were still mostly invested in Solaris (Sparc) and Windows (x86) OS.  Red Hat was the biggest name in Linux distribution, and they were making money from providing support for it.  Now, IBM saw the Linux adoption kept going up, so it was only logical for IBM to acquire Red Hat, and the growing customer base along with it.

Linux adoption became bigger when Microsoft decided to include Linux as part of Windows 10 distribution, and contributed a large chunk of their code as open source.  The thinking is that contributing to vibrant and open community brings a sort of likeability to giants like Microsoft.  It’s no surprise Microsoft is touted to be a better technology innovator than Apple, Samsung, IBM, or even Google.

Speaking of likeability, or “coolness” factor, another example is Elastic offering a solid product based on Lucene open source search engine. With customers like Uber and SpaceX adopting their (based-on) open source search engine, Elastic is poised to make plenty of revenue.  So much so, they’re gaining competition from Amazon Web Services offering the same solution based on Elasticsearch open source software. The potential revenue is definitely available for the taking.

Can anyone get rich from Open Source?  Absolutely.  As long as there are mass adoptions, rich use cases, growing libraries, and plenty of community experts, open source is now becoming the standard for technology adoption in Enterprise environments.  The most successful companies will succeed in the open source game, only if they can make a compelling product that works really well and be able to support it. The customers are there – just make them happy!

[EDIT 8/1/2019]: Wired has a nice write-up on how companies should take the “moral” ground and mutual benefits when it comes to licensing open source software. My thought this can be tricky because of the old saying: “It’s just business, nothing personal.” Although it’s nice that we expect people to play nice, making money is a dirty business.

TMUX: A Command Line Must!

When I started with Unix, it was during my college days on a VT-100 terminal, with text command lines. There was even an online chat window using text (remember “talk”?). When a GUI was introduced using X Windows on Sun Microsystem Solaris machines, the experience was so different and it was considered to improve productivity because we get to multitask. However, old habits die hard, so even with a GUI, I would have dedicated X-Term windows for command line stuff. I would run “screen” (aka “Gnu Screen”) to have multiple (and switchable) windows within X-Term.

The advantages of using screen are:

  1. When my SSH connection is broken, the command line sessions are still working. Useful when running shell scripts that take a long time to complete.
  2. Having a shell with command line history, I could review the previous executions, in case I forgot to document something.
  3. Instead of using the mouse to click on a different window, I use the keyboard shortcut Ctrl-A and the number keys, to switch between screens. Way quicker.

With the introduction of Red Hat Enterprise Linux 8, I was introduced (read: forced) to use a new screen replacement called TMUX. Apparently, it’s not a new util but it’s way more powerful – and useful. After using it for a while, I saw these advantages:

  1. Having a vendor managed Firewall, I didn’t have a choice for connection keep-alives. My SSH connections will drop after inactivity. With TMUX, there’s a clock display that forces the connection to send data once a minute. Thus keeping the connection alive – indefinitely. No more dropped connections and reconnecting effort.
  2. Being able to run screen within TMUX window is pretty nifty. I have another layer of switchable window, which is really handy when I have multiple servers representing the different layers for a site (ie. web, JBOSS, database, etc.) This is possible because TMUX’s key bindings for switching window is configurable and by default it’s different than screen’s.
  3. TMUX has window panes, for dashboard like monitoring. Plus, it looks awesome!
My tmux screen with split panes (For demo only. I usually like to see one window at a time)

Most of the Red Hat Enterprise Linux I’m working with is version 6.x, TMUX is not included as part of RHN repository. Thus, I had to build it from source. These are the steps to do it:

  1. Download, compile, and install the latest libevent and ncurses.
  2. Download TMUX and compile using the following configure flags (note, I installed on local home directory):
    CFLAGS="-I$HOME/local/include -I$HOME/local/include/ncurses" LDFLAGS="-L$HOME/local/lib -L$HOME/local/include/ncurses -L$HOME/local/include" CPPFLAGS="-I$HOME/local/include -I$HOME/local/include/ncurses"

If there’s a doubt that command line is important to a sysadmin’s daily work, Microsoft Developers are proud to present an expanded version of Windows OS command prompt. The video below has the full highlights and it looks great!

Windows Terminal: Building a better command line experience for developers

There’s even a trailer that rivals an iPhone launch commercial!

The new Windows Terminal: Trailer

I’m excited that Operating System vendors are now providing more robust terminal tools, making command line a much better experience for all of IT folks!

Moving the Default Docker Data Directory in RHEL 7

Red Hat Docker

In every application, the install directory is set to defaults such as /var, /opt, or /usr/local (even the / root directory) for data and logs.  This is fine for testing purposes. However, for production use, especially when the application becomes really active, those data and log directories can be big.  An alternate storage location, such as LVM or xfs, will be needed that can re-sized for future expansion.

In this example, let’s perform the requirement to move Docker’s default directory into a separate xfs formatted disk. For Red Hat Enterprise Linux 7 installation, this Docker setup is off the RPM repository.  The default is /var/lib/docker for the data files.  In order to change the path into somewhere else, for example /disk2/docker, first change the /etc/sysconfig/docker file to reflect the change:

OPTIONS=’–selinux-enabled –log-driver=journald –signature-verification=false –graph=/disk2/docker –iptables=False –storage-driver=overlay2′

Move the files from /var/lib/docker into the new /disk2/docker directory.  Since SELinux is enabled for production environment, Docker will need the permission to write into the new directory:

semanage fcontext -a -s system_u -t container_var_lib_t ‘/disk2/docker(/.)?’

semanage fcontext -a -s system_u -t container_share_t ‘/disk2/docker/./config.env’

semanage fcontext -a -s system_u -t container_file_t ‘/disk2/docker/vfs(/.)?’semanage fcontext -a -s system_u -t container_share_t ‘/disk2/docker/init(/.)?’

semanage fcontext -a -s system_u -t container_share_t ‘/disk2/docker/overlay(/.)?’semanage fcontext -a -s system_u -t container_share_t ‘/disk2/docker/overlay2(/.)?’

semanage fcontext -a -s system_u -t container_share_t ‘/disk2/docker/containers/./hosts’semanage fcontext -a -s system_u -t container_log_t ‘/disk2/docker/containers/./..log’

semanage fcontext -a -s system_u -t container_share_t ‘/disk2/docker/containers/./hostname’

And finally, restore the file context for /disk2/docker:

restorecon -R /disk2/docker

Start up the Docker service again, and the environment is now ready to use!