<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/30/2012 06:58 PM, Tim Watts
wrote:<br>
</div>
<blockquote cite="mid:1346367503.2513.1020.camel@dellberry"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
It sounds like many projects could use a (SA)BDFL to provide
continuity.<br>
<blockquote cite="mid:1346367503.2513.1020.camel@dellberry"
type="cite">
<pre wrap="">
On Thu, 2012-08-30 at 17:33 -0400, Jim Kinney wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:jdp@algoloma.com"><jdp@algoloma.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thanks for the thoughtful response.
On 08/30/2012 03:58 PM, Lightner, Jeff wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.)
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:Ale@ale.org">Ale@ale.org</a>
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</pre>
</blockquote>
<pre wrap="">
--
--
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
<a class="moz-txt-link-freetext" href="http://electjimkinney.org">http://electjimkinney.org</a>
<a class="moz-txt-link-freetext" href="http://heretothereideas.blogspot.com/">http://heretothereideas.blogspot.com/</a>
_______________________________________________
Ale mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ale@ale.org">Ale@ale.org</a>
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Ale mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Ale@ale.org">Ale@ale.org</a>
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a class="moz-txt-link-freetext" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Jay Lozier
<a class="moz-txt-link-abbreviated" href="mailto:jslozier@gmail.com">jslozier@gmail.com</a></pre>
</body>
</html>