[Hamara-devel] the different cabals and how we suffer for it.

shirish shirish at hamaralinux.org
Wed Sep 23 17:12:38 BST 2015


Hi all,

I had written few weeks to a month about cabals and some people had 
shared that it's all in my head. A cabal is basically some people 
grouping and at times being secret about their intentions, at other 
times just doing from a narrow, personal gain perspective.

While I'm supposed to be writing documentation, felt this was important 
to hence sharing it.

The first is Debian's move away from LSB . For those who are knew, LSB 
is/was the brain child of something called the Linux Foundation.

I saw this news in changelog ( I have this bad habit of reading 
changelogs and NEWS most of the times )

lsb (9.20150826) unstable; urgency=low

   * Drop all the LSB compatibility packages besides lsb-release and 
lsb-base
     - Drop packages-availability checking in lsb-release
     - Truncate README.Debian to a minimum
     - Document this in lsb-base.NEWS.Debian
   * Change the versioning number to avoid any ambiguity; use joeyh's
     version.date, with version being Debian next stable's

  -- Didier Raboud <odyx at debian.org>  Wed, 26 Aug 2015 12:00:00 +0200

This is/was with the latest lsb-release.


Now I was taken aback a bit as Debian is known to be very pro-community 
folks and this seemed to go against the grain a bit. I had known about 
the LSB issue quite a bit but had forgotten. The above news lead me to 
dig a bit.

Thankfully, didn't have to investigate too deep and the reasons were 
pretty much there on the LSB page on Wikipedia.

https://en.wikipedia.org/wiki/Linux_Standard_Base#Reception

See this part

While the LSB is a standard and without a competitor, it is followed 
only by few Linux distributions. For instance, only 21 distribution 
releases (versions) are certified for LSB version 4.0, notably Red Flag 
Linux Desktop 6.0, Red Hat Enterprise Linux 6.0, SUSE Linux Enterprise 
11, and Ubuntu 9.04 (jaunty);[11] even fewer are certified for version 4.1.

The LSB has been criticized[12][13][14][15] for not taking input from 
projects, most notably the Debian project, outside the sphere of its 
member companies.

I actually went through all the links which have been cited and sure 
enough, it isn't just Debian that suffers from it, it's whole lot of 
different communities. Especially the autopackage article should have 
given lot of insight to Vikas and team as to why there isn't a 
distribution neutral package manager, this was thought, asked in the 
past. For most commercial entities having app. or apps on a container is 
good enough.


The second is for application developers as they get shafted by the 
various different toolkits and changes in them all the time.

See https://trac.transmissionbt.com/ticket/3685 in its entirety as well 
as https://trac.transmissionbt.com/ticket/3685#comment:3 which actually 
also talks of a pain point in respect of different Desktop environments.

While this is an example, the issue runs quite deep and excuses given by 
most desktop environments on security are a eye-wash. At least in 
today's world, you could design the environments so they have randomized 
memory offsets if so desired but on some basic things there should be 
some consensus.

If somebody asks why we are always talking about 'The Year of GNU/Linux 
desktop is coming' and doesn't come, these are the issues.

While at the moment, while we wouldn't be able to do anything about 
either of the things, but just being aware and whenever we get chances 
if we are able to shift things even in a point percentage from where 
they are, it would be a contribution.

Look forward at how people read it and what they think can and should be 
done.

-- 
Regards,
Shirish Agarwal,
Community Lead,
Hamaralinux.org


More information about the Hamara-devel mailing list