[ale] Stable, backward compatible APIs

Fri Aug 31 08:59:52 EDT 2012

Desktops do have to be stable in commercial environments mainly because desktops talk to other servers and services that aren’t necessarily going to be updated any time soon.   Due to some legacy stuff here I have to run a Windows XP virtual guest on my Windows 7 workstation to interface with it.   Even on Windows 7 itself I have to run Java 6 rather than Java 7 because many of the utilities we use simply won’t run in the latter.

What annoyed me several years ago was how many UNIX software vendors (including OS makers like HP for HP-UX)  started requiring Windows desktops for their control apps.

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Jay Lozier
Sent: Thursday, August 30, 2012 7:50 PM
To: ale at ale.org
Subject: Re: [ale] Stable, backward compatible APIs

On 08/30/2012 06:58 PM, Tim Watts wrote:

I'm not so sure the API has to be stable to the point of stagnation in

order to instill trust.  There are disciplined ways of evolving an API

and many FOSS communities have done so successfully.  From what I've

read and seen the problem in the Linux desktop arena has been the

undisciplined evolution driven by the developers/designers.  Deprecating

entire subsystems without advance notice because one of the key

designers thought of a cool new way of doing it over the summer,

regardless of how entrenched or critical the API may be.  (And no,

publishing your intent on your blog before the next release doesn't

count as advance notice.)  I've abandoned a couple small projects

because of stuff like that.

So in short, I find fault more with the personalities involved than the

nature of the enterprise.
It sounds like many projects could use a (SA)BDFL to provide continuity.

On Thu, 2012-08-30 at 17:33 -0400, Jim Kinney wrote:

It _sounds_ good but it's not feasible. For an API to be stable for

years, it must be very simple, very limited and mostly ignored. A

desktop environment fits none of those.

This doesn't work in Mac/Windows land either. Apps that used the

desktop gui are hit-or-miss after an upgrade to a new OS on either of

those. The way they handle this is with long-term support.

Keep in mind that most commercial crap is released when it compiles.

They'll patch later with the upgrades. So hard stuff like API design

for a decade is really not going to happen. In Linux-land, API design

is done by committee, coded up and then a new committee comes in.

Yeah. That works well :-)

On Thu, Aug 30, 2012 at 4:54 PM, JD <jdp at algoloma.com><mailto:jdp at algoloma.com> wrote:

Thanks for the thoughtful response.

On 08/30/2012 03:58 PM, Lightner, Jeff wrote:

Of course this is why RHEL is setup the way it is.   You can put your

Enterprise on it and trust that you don't have to do a complete revamp of

everything every year or so.   (In fact for RHEL5 Redhat announced earlier

this year they were extending its life from 7 years to 10 years even though

RHEL6 has been out for over a year.)

I probably wasn't as clear as I could have been.  I wasn't talking about long

term support for a specific release.  Ubuntu LTS releases have support for 5

yrs, but that isn't really what we need.  Being stuck on old an old OS release

to run an old commercial program is the issue.

Rather we are talking about consumer-level desktop releases that supports

programs over many years. Since I haven't touched anything from RH since 2002, I

can't talk in those terms - but what end-users need and demand is a stable API

across Ubuntu 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 .... with new APIs added, but

old APIs remaining for GUI programs.  Any program that ran on Ubuntu 6.06 should

be able to run unchanged on Ubuntu 14.04.

Backwards compatibility, while not forcing anyone to hold back their desktop OS

revision.

Any Gnome2 program should work under Gnome3. Any KDE3 under KDE4. Just look at

Android v1.6 programs that work under Android 4.1+ and every version in between.

 A few programs are tied to specific hardware but the vast majority of them are

not. They are Android compatible.

On the flip side it means some things on RHEL get a bit long in the tooth.

(e.g. BIND 9.3 is the base RedHat uses on RHEL5)  Redhat does backport

security and bug fixes from later upstream versions into theirs but still it

becomes limited compared to newer things.  But then again for an app like

that you can always forego the RHEL provided package and download/build the

latest from source.

Programs that do not cost SW-CAP to install don't count.  It is the Adobe

programs, the gee-wiz-bang new gaming company and Intuit who need this level of

commitment.  It would help smaller developers too.

Sorry, but until Quickbooks works on a Linux desktop, tens of thousands of small

accounting companies will not switch.  Saying we don't want those end-users,

does them and us a disservice.  Linux desktops should be inclusive, not exclusive.

Building from source is not an option for most commercial offerings on a

desktop.  For example, build Skype from source.

Perhaps the Linux Foundation can lead the effort for a stable API?

I believe that servers are a different animal.  The merits of Linux + GNU with

BSD/MIT/Apache licenses have all but won this market already.

_______________________________________________

Ale mailing list

Ale at ale.org<mailto:Ale at ale.org>

http://mail.ale.org/mailman/listinfo/ale

See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo

--

--

James P. Kinney III

Every time you stop a school, you will have to build a jail. What you

gain at one end you lose at the other. It's like feeding a dog on his

own tail. It won't fatten the dog.

- Speech 11/23/1900 Mark Twain

http://electjimkinney.org

http://heretothereideas.blogspot.com/

_______________________________________________

Ale mailing list

Ale at ale.org<mailto:Ale at ale.org>

http://mail.ale.org/mailman/listinfo/ale

See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo

_______________________________________________

Ale mailing list

Ale at ale.org<mailto:Ale at ale.org>

http://mail.ale.org/mailman/listinfo/ale

See JOBS, ANNOUNCE and SCHOOLS lists at

http://mail.ale.org/mailman/listinfo

--

Jay Lozier

jslozier at gmail.com<mailto:jslozier at gmail.com>

Athena®, Created for the Cause™

Making a Difference in the Fight Against Breast Cancer

How and Why I Should Support Bottled Water!
Do not relinquish your right to choose bottled water as a healthy alternative to beverages that contain sugar, calories, etc. Your support of bottled water will make a difference! Your signatures count! Go to http://www.bottledwatermatters.org/luv-bottledwater-iframe/dswaters and sign a petition to support your right to always choose bottled water. Help fight federal and state issues, such as bottle deposits (or taxes) and organizations that want to ban the sale of bottled water. Support community curbside recycling programs. Support bottled water as a healthy way to maintain proper hydration. Our goal is 50,000 signatures. Share this petition with your friends and family today!

---------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120831/fd0faee5/attachment-0001.html 