NSA: Please Turn off the Lights When You Leave. Nothing to See Here.

Linux Advocate Dietrich Schmitz shows how the general public can take action to truly protect their privacy using GnuPG with Evolution email. Read the details.

Mailvelope for Chrome: PGP Encrypted Email Made Easy

Linux Advocate Dietrich Schmitz officially endorses what he deems is a truly secure, easy to use PGP email encryption program. Read the details.

Step off Microsoft's License Treadmill to FOSS Linux

Linux Advocate Dietrich Schmitz reminds CIOs that XP Desktops destined for MS end of life support can be reprovisioned with FOSS Linux to run like brand new. Read how.

Bitcoin is NOT Money -- it's a Commodity

Linux Advocate shares news that the U.S. Treasury will treat Bitcoin as a Commodity 'Investment'. Read the details.

Google Drive Gets a Failing Grade on Privacy Protection

Linux Advocate Dietrich Schmitz puts out a public service privacy warning. Google Drive gets a failing grade on protecting your privacy.

Email: A Fundamentally Broken System

Email needs an overhaul. Privacy must be integrated.

Opinion

Cookie Cutter Distros Don't Cut It

Opinion

The 'Linux Inside' Stigma - It's real and it's a problem.

U.S. Patent and Trademark Office Turn a Deaf Ear

Linux Advocate Dietrich Schmitz reminds readers of a long ago failed petition by Mathematician Prof. Donald Knuth for stopping issuance of Software Patents.

Showing posts with label LSB. Show all posts
Showing posts with label LSB. Show all posts

Thursday, December 12, 2013

Ignore Linux Standards at Your Own Peril

by Dietrich Schmitz

So, I've been watching the progression of all things Linux for the past few months and noting how many Distributions are falling in line with systemd adoption and those which are not.

Systemd adoption by major Linux Distributions

The freedom to make choices in software design which introduce variation ultimately exacts a cost.  It's not apparent up front but in the long term, introducing 'variation' of any kind into a operating system results in additional complexity.  Only recently has holdout Debian gotten around to recognizing that their sysvinit system is beginning to show its age and 'limitations'.  Uniformity lends to conformity and implied standardization, sometimes in the form of 'de facto' standards.

Today, I am reminding readers of the importance of adhering to standards as the image below shows how being Linux Standard Base compliant can and will lead to lower cost of operation and ongoing maintenance.

Linux Foundation promulgated 'Linux Standard Base'


Does having to adhere to standards stifle creativity and freedom of choice?  


Well, there's room for debate on that question and while to a degree standards compliance does impose a restriction on the respective developer's freedom to deviate, it also results in reducing complexity and to a larger extent fosters an environment in which software vendors and business concerns can reliably make assumptions which utilize those standards, including standard software behaviors, to streamline cost of operation from both consistency and reliability points of view: less complexity, fewer points of failure.  With fewer points of failure, reliability goes up and support costs go down.


Is my preferred Distro 'X' Linux Standard Base compliant?

It's an important question.  Let's take a look at Microsoft Windows for an answer.

Historically, over the past fifteen years preferring to work with Windows has been rightfully perceived by CIOs and CEOs as an implied standard, and despite Microsoft being a Monopoly, every developer knows that they have only one software API to deal with when choosing to code Windows executables on the Windows Legacy x86 platform.  That makes Windows an implied or 'de facto' standard, in lieu of there being any other competitor in a market.  And the choices imposed on Developers are made simple.  There's just one theoretical 'Distro' to think about when it comes to designing a piece of software for a given market.

But, there aren't any 'Distros' in the Windows world.  


Of course, but you see, Distro variation is non-existent, along with the implicit complexity stemming from compiler dialectic variations, differing package management and file hierarchy structure design considerations.  They're all gone and the attendent costs exacted on program development don't pertain in the Windows software development thriving ecosystem.

Should there be fewer Linux Distros?  


I don't argue for fewer Distros.  However, I do maintain that if the designers of Distro X conform to a base standard and not deviate, they will not have compromised their right to creative choice.  One need only look to the richness and diversity of software written to the Windows API to have an answer.

As long as Linux developers continue to clone new Distros and cheerlead the way, all the while ignoring standards, the chance for long-term survival of their work is put at peril.

Big Business Craves Stability

Simply put, Big Business Enterprise cannot afford downtime and thus the reputation of any Enterprise grade software system hinges on its stability and reliability in addition to effectiveness in providing a business solution.

There will not be as many Distros in five years as there are today.  

That fact is a certainty.

By attrition, some Distros will simply fade away into disuse.  The sturdy long-termers will consolidate and survive by adopting common standards and as there will be far fewer Distros, more programming effort will be spread across the few remaining base Linux Distros.  My prediction is there will be no more than six remaining in five years.

But be assured, Linux will continue to endure and survive, flourishing on a base set of LSB-compliant Distributions for many years to come.  -- Dietrich
Enhanced by Zemanta

Monday, May 13, 2013

Running Your Own Railroad

by Dietrich Schmitz

I am beginning to see a pattern in how Canonical operates.  Not to single them out, but I think that to succeed in any business endeavor, a business plan must set objectives with a timeline to their completion.

It seems that Canonical are setting their own priorities.  First came Unity.  Then they targeted X.org a standard for Display management by supporting Wayland.  As Wayland reached its first production release, version 1.0, Canonical immediately took the code and forked it to their own project specification called Mir. (Image credit: inhabit.com)

This is looking less like an open community than any other time I can remember.  Canonical are carefully taking control their code base and removing community involvement.

Then, Canonical developed a new fork called Ubuntu Touch for their planned smartphone division.

Now, they've announced a plan to develop their own package management software, with the 'intention' (cough wink) of using it for their smartphone technology.

This has garnered much attention and the noise level continues to amplify.

What if the plans for this new package manager were more ambitious than Canonical are telling us?  Suppose that package management system would take away the Debian apt/dkpg control?

That would not bode well for Debian, me thinks.  And I've advocated for a unified package manager.  One because it would dramatically ease the burden of programming and two it would reduce costs and allow software written to be packaged and run on all Linux Distros.

That isn't my idea.  Actually, it's been around for years in fact and is part of the Linux Foundation's Linux Standard Base (LSB).  In fact, rpm is the standard which is a 'mandatory' specification to obtain LSB certification.

Debian have resisted support for rpm and LSB which may work ultimately to their disadvantage if they continue to ignore the standard.

Debian is not a commercial Linux Distribution.  So, they can afford to play foot-loose and fancy free by ignoring standards in favor of their own 'de facto' standard.

But how long will that last?  They took two years to roll out Debian 7 Wheezy which still runs on sysvinit, not systemd, although they've made systemd an installable option.  Two years is slow people.  Debian is looking old, stodgy, and resistant to change.  And, as we all know, technology is changing at the speed of light.

So, is Canonical running their own railroad?  Necessarily, to run a business, yes.  They and Red Hat can't afford to play around like Debian and Canonical just might switch away from deb package management entirely to again gain control of another big piece of the Linux Distro puzzle.  Let's hope that Canonical recognize the importance of LSB and support rpm.  -- Dietrich
Enhanced by Zemanta