[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