Saturday, February 18, 2017

Testing OpenSUSE Tumbleweed

It has been a long time since I have tested a new distro, so here I am again, Now trying openSUSE Tumbleweed. I never tried openSUSE for more than a few days, so hopefully this time I willl build my own oppinion. I am going for Tumbleweed, the rolling release, since I am the bleeding edge guy.


I have selected the NET install iso, because I have a decent internet connection, and I like to have a clean desktop, only installing software as needed. The iso is available from .

I have created a bootable usb with the following procedure:

Post Install Issues

After installing a 3rd SDD disk do my desktop computer 2 years ago, installing any OS resulted in a broken boot system. It was no different with Tumbleweed, I just ended on a GRUB2 "No such device". However it was quite easy to fix, OpenSUSE's media has a "Boot from installed system" which detects an existing install, and boot from it. It worked like a charm. Then having some technical background on the issue. With a full booted and functional system, I have installed GRUB to the MBR from all the 3 disks, and it was done. A reboot presented me a nice boot graphical logo to select the system (OpenSUSE Tumbleweed or Windows 10).

I have switched from Gnome (2.0) to Cinnamon for the last couple of years, unfortunately the installer does not have a Cinnamon option for the install type. I have selected "Minimal X Environment" so that I could install cinnamon from the repositories later, that got me into another issue. The Minimal X provided IceWM and YaST «a nice system config management tool», however while attempting to configure the WiFi network, I have found that the system was missing the core packages required for Wifi connectivity (iw; wpa_supplicant), it was kind of blocking since I don't have a wired network. I had to boot into Windows to fetch the packages from:

I have filled a bug report for this issue:

I am currently finishing this blog post from Tumbleweed, hopefully I will report about a more wide experience during next week :)

Thursday, August 25, 2016

Creating a portable Python + VSphere Python SDK for Windows

If you are working with Virtual Center in an enterprise environment, there are high changes that your VC clients are Windows systems running on a secure network (no network access). This article will let you build a portable Python extender the VSphere Python SDK that you can just copy and use from your vcenter client systems.

Get the required packages on a system having network access: 

  • lessmsi from 
  • python*.msi from
  • Python packages from pip:
    • six-1.10.0-py2.py3-none-any.whl, 
    • requests-2.10.0-py2.py3-none-any.whl
    • suds-0.4.tar.gz
    • pyvmomi- 

Create a .bat file that creates the python portable directory:

lessmsi-v1.4\lessmsi x python-2.7.12.amd64.msi python\
cd python\SourceDir
python -m ensurepip
scripts\pip install ../../six-1.10.0-py2.py3-none-any.whl
Scripts\pip install ../../requests-2.10.0-py2.py3-none-any.whl
Scripts\pip install ../../suds-0.4.tar.gz
Scripts\pip install ../../pyvmomi-

Run it, you will get your portable content in the "python" folder


Tuesday, November 1, 2011

More thinking on software bundles for Linux

The post Rethinking the Linux distibution made me revisit some of the ideas which I had in the past trying to address which in my opinion are major limitations in the current main packaging systems:
  • No support for multiple versions of the same software
  • No support for rollbacks
A software bundle composed of the application and all it's "non core" dependencies can  also add some other benefits:
  • Cross Linux distribution delivery
  • Fine grain control of libraries and options used by an application
  • Reduced complexity with the removal of dependencies management
The disadvantages are:
  • Increase on Disk and RAM usage from software containing different versions of common libraries
  • Applying security fixes  on dependencies requires re-creating/re-distributing every affected bundle
Possible approach for implementation:

Adapt an existing source base build system like Arch's "makepkg", with the following changes:
  • Run time prefix must be set to /opt/bbundle
  • Build definitions for dependencies must be contained in the master build definition (this will lead to build definitions redundancy across bundles but will remove the risk of breaking builds by sharing dependencies building rules) 

The bundle file format should be a commonly used archive format, since tar does not provide indexing, .zip is a better option. Having an indexed archive will allow to reduce download sizes by inspecting the bundle  contents prior to the download and skipping the download for common files found at installed bundles. In order to save on-disk space, the bundle installer should check for identical files across bundles and use hard links instead of duplicating files.

Bundles installation should be as simply as extracting the bundle archive into /usr/local/bbundle/bundle_name. A watching service must identify .desktop and other exportable resources and make them available from the host desktop environment.

Thursday, May 12, 2011

Life changes

It has been more than 1 month since I left the Ubuntu community and started exploring other Linux distros. Meanwhile the increasing personal concerns added to the my country's economical situation prompted to re-evaluate where I am investing my life time.

In short, I need to engage in profitable activities otherwise I may fail to support my family.

While I will always be a strong FOSS supporter, because I believe on it's values. I no longer have the time for significant involvement in non profitable projects.
I will continue using and consequentially involved in the Linux ecosystem because it allows me to be more productive, both on my job and on other projects I may get involved with.

Monday, March 14, 2011

Building RPMs vs Building DEBs

Having a large experience with Debian package building it's refreshing to try something else. Last week I have learned the basics of RPM package building.
Here are the differences I have found so far and my opinions about them.

The RPM .spec file package contains both package metadata (description, dependencies, etc) and compile rules while on DEB you have the data split into different files. I remember that on the beginning it was hard to understand the purpose of all those debian/* files, I have found .spec files easier to understand.

The RPM .specs allows conditional building, during build the build target release can be used to dynamically adjust build flags, dependencies etc. While you can achieve this on Debian using some auto generation mechanism (debian/, it is not naturally integrated in the building system, debian/* contains metadata and rules for a specific target system.

Not so important but a nice feature it's the support for translated description/summary on RPM packages.

Saturday, March 5, 2011

Some differences between Fedora and Ubuntu

I have already noted a few technical differences between Fedora and Ubuntu which I am going to comment.

/tmp cleanup
Fedora does not automatically remove /tmp contents on reboot, I prefer Ubuntu's behavior, applications do not rely on tmp contents across reboots and regular users should not be working on /tmp. If there is no other automated cleanup mechanism -did not check yet-, on the long run the user will get a full root file system.

Repository information cache
I don’t have a YUM technical background, so please excuse me if I will write something terribly wrong here.
From an user perspective I have noted that yum does not have an explicit cache mechanism, you don’t need to explicitly update the cache. The good side it automatically gets the required information when a new repository is added and frees the user from a repetitive action. The bad side is that it may introduce some network/time overhead during package management opertions.

Software update policy
I did not read Fedora’s update policy yet but I have noted that they provide regular release upgrades for some software, piding was updated to 2.7.10 from the regular updates repository.

Friday, March 4, 2011

Impressions from Linux Mint 10 Main Edition

Now that I am confident on the Fedora install I could afford to use my other partition and try Linux Mint 10 as suggested by a friend.

The out-of-the box visual experience was one of the best I had so far with a Linux distribution, the menu -mintmenu- seems highly inspired in MS Windows menus, from my reading it's a fork of the SLAB Menu, I really loved the easy navigation and search capability.
Linux Mint 10 is based and compatible with Ubuntu 10.10, the default configuration points to the linux mint repository plus the Ubuntu archives for the usual packages.

Besides the menu they provide their own set of tools, you can easily identify them with ls /usr/bin/mint*, some of them are just wrappers or tiny tools, but it shows they are working not only on cosmetics.

I did not find any documentation about their decision making process or governance in general, but I have sent an email asking for information.

They do care about community feedback, judging from the running poll .
There is a Debian based version (which I did not test yet), and it seems they will be deciding about switching to Debian for other flavors.

I will keep an eye on it, it may be a nice project to join.