<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: OSDL + FSG = The Linux Foundation: The Q&amp;A</title>
	<atom:link href="http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/feed/" rel="self" type="application/rss+xml" />
	<link>http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/</link>
	<description>because technology is just another ecosystem</description>
	<lastBuildDate>Sun, 13 May 2012 00:23:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: tecosystems &#187; Apt-get Install Ian Murdock: The Q&#38;A</title>
		<link>http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/comment-page-1/#comment-37047</link>
		<dc:creator>tecosystems &#187; Apt-get Install Ian Murdock: The Q&#38;A</dc:creator>
		<pubDate>Mon, 19 Mar 2007 23:20:05 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/#comment-37047</guid>
		<description>[...] says, this hiring would result in some convergence between the two operating systems. One of my stated regrets regarding the original Linux Foundation announcements, in fact, was the unhelpful wedge some of the [...]</description>
		<content:encoded><![CDATA[<p>[...] says, this hiring would result in some convergence between the two operating systems. One of my stated regrets regarding the original Linux Foundation announcements, in fact, was the unhelpful wedge some of the [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon Phipps</title>
		<link>http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/comment-page-1/#comment-17699</link>
		<dc:creator>Simon Phipps</dc:creator>
		<pubDate>Wed, 14 Feb 2007 00:54:03 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/#comment-17699</guid>
		<description>Ted:  Actually your assertion that &quot;relatively few ISV’s have ported to Solaris on Opteron&quot; is wrong. Sun has around 2300 commercial applications supported on Solaris x64 - That&#039;s more even than there are for RHEL. Solaris has come a long way since you last looked!</description>
		<content:encoded><![CDATA[<p>Ted:  Actually your assertion that &#8220;relatively few ISV’s have ported to Solaris on Opteron&#8221; is wrong. Sun has around 2300 commercial applications supported on Solaris x64 &#8211; That&#8217;s more even than there are for RHEL. Solaris has come a long way since you last looked!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Theodore Tso</title>
		<link>http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/comment-page-1/#comment-17352</link>
		<dc:creator>Theodore Tso</dc:creator>
		<pubDate>Mon, 12 Feb 2007 08:17:16 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/#comment-17352</guid>
		<description>The problems with trying to extend the LSB to Solaris and FreeBSD are somewhat different.    As far as FreeBSD is concerned, it&#039;s extremely small deployed base means that it is nearly irrelevant as far as the commercial ISV market is concerned; you don&#039;t see many ISV&#039;s making their products available for FreeBSD.  Hence, FreeBSD doesn&#039;t have much incentive to chage its filesystem layout, its ABI, its packaging system, etc. in order to be LSB compliant.  If it chooses to do so, of course a commercial distributor of FreeBSD could always  try to make FreeBSD LSB compliant and then go through the LSB certification process.  

Solaris has another problem; relatively few ISV&#039;s have ported to Solaris on Opteron, but Solaris has many, many more ISV&#039;s shipping products on its highly expensive, Sparc platform.  ABI compatibility on the Intel platform with Linux could threaten long-term ISV commitment to the Solaris platform, and at the very least would make it easier for customers to transition from Solaris to Linux, and for more ISV&#039;s to support Linux, which is not in Sun&#039;s long-term interest.    Whether it is for these or other reasons, Sun has never been particularly interested in the LSB, and I don&#039;t see any likelihood of that changing.  Of course, if Solaris wants create a Linux compatibility layer and then try to get it certified as an LSB-compliant environment, it is welcome to do that.

At the end of the day, I think what this article is missing is that in order for a standard to be useful, it has to define a platform which applications can target, and ship binaries that will Just Work.   Posix never met that goal because (a) it was a source standard, and (b) in order to  be as applicable as possible to a wide range of OS&#039;s, it watered itself down by allowing multiple different behaviors so that no Unix flavors would &quot;lose out&quot;.   But by being broad, it became much, much less useful to application programs, who still needed to make their applications flexible enough to support the Solaris way of doing Posix, the AIX way of implementing Posix, the Digital Unix way of implementing Posix, etc., etc.   So the LSB is standardizing the Linux way of doing things.  Period.   That makes it much more useful than if it did the politically correct thing by saying, &quot;Well, we like the FreeBSD and Solaris ways of doing things too; they&#039;re OK by us!&quot;    It&#039;s politically correct, but not very useful as a run-time ABI standard.   So instead, we take a different tack: the FreeBSD and Solaris ways of doing things are just fine, but if they want to run Linux application binary from Oracle or SAP, they need to provide a compatibility layer which is LSB compliant.  We&#039;ll tell Sun and FreeBSD what they need to provide in that compatibility layer, but we&#039;re not going to force the application to simultaneously be able to call out to via either the Linux system call interface or the Solaris system call interface.   Because, you know, that would be crazy.</description>
		<content:encoded><![CDATA[<p>The problems with trying to extend the LSB to Solaris and FreeBSD are somewhat different.    As far as FreeBSD is concerned, it&#8217;s extremely small deployed base means that it is nearly irrelevant as far as the commercial ISV market is concerned; you don&#8217;t see many ISV&#8217;s making their products available for FreeBSD.  Hence, FreeBSD doesn&#8217;t have much incentive to chage its filesystem layout, its ABI, its packaging system, etc. in order to be LSB compliant.  If it chooses to do so, of course a commercial distributor of FreeBSD could always  try to make FreeBSD LSB compliant and then go through the LSB certification process.  </p>
<p>Solaris has another problem; relatively few ISV&#8217;s have ported to Solaris on Opteron, but Solaris has many, many more ISV&#8217;s shipping products on its highly expensive, Sparc platform.  ABI compatibility on the Intel platform with Linux could threaten long-term ISV commitment to the Solaris platform, and at the very least would make it easier for customers to transition from Solaris to Linux, and for more ISV&#8217;s to support Linux, which is not in Sun&#8217;s long-term interest.    Whether it is for these or other reasons, Sun has never been particularly interested in the LSB, and I don&#8217;t see any likelihood of that changing.  Of course, if Solaris wants create a Linux compatibility layer and then try to get it certified as an LSB-compliant environment, it is welcome to do that.</p>
<p>At the end of the day, I think what this article is missing is that in order for a standard to be useful, it has to define a platform which applications can target, and ship binaries that will Just Work.   Posix never met that goal because (a) it was a source standard, and (b) in order to  be as applicable as possible to a wide range of OS&#8217;s, it watered itself down by allowing multiple different behaviors so that no Unix flavors would &#8220;lose out&#8221;.   But by being broad, it became much, much less useful to application programs, who still needed to make their applications flexible enough to support the Solaris way of doing Posix, the AIX way of implementing Posix, the Digital Unix way of implementing Posix, etc., etc.   So the LSB is standardizing the Linux way of doing things.  Period.   That makes it much more useful than if it did the politically correct thing by saying, &#8220;Well, we like the FreeBSD and Solaris ways of doing things too; they&#8217;re OK by us!&#8221;    It&#8217;s politically correct, but not very useful as a run-time ABI standard.   So instead, we take a different tack: the FreeBSD and Solaris ways of doing things are just fine, but if they want to run Linux application binary from Oracle or SAP, they need to provide a compatibility layer which is LSB compliant.  We&#8217;ll tell Sun and FreeBSD what they need to provide in that compatibility layer, but we&#8217;re not going to force the application to simultaneously be able to call out to via either the Linux system call interface or the Solaris system call interface.   Because, you know, that would be crazy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James  Governor</title>
		<link>http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/comment-page-1/#comment-12745</link>
		<dc:creator>James  Governor</dc:creator>
		<pubDate>Mon, 29 Jan 2007 16:44:54 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/#comment-12745</guid>
		<description>great stuff stephen. you add a lot. fine signal to noise.</description>
		<content:encoded><![CDATA[<p>great stuff stephen. you add a lot. fine signal to noise.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Once More unto the Breach</title>
		<link>http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/comment-page-1/#comment-12513</link>
		<dc:creator>Once More unto the Breach</dc:creator>
		<pubDate>Fri, 26 Jan 2007 04:40:57 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/#comment-12513</guid>
		<description>&lt;strong&gt;Repeating History:  The OSDL and Free Standards Group Merge...&lt;/strong&gt;

[Update (2007 Jan 25, 20:35): Stephen O&#039;Grady and I are generally complementary in our thinking, but more aligned. Here&#039;s his excellent analysis. I think I&#039;m showing my age.] Monday saw the announcement of the creation of the Linux Foundation by...</description>
		<content:encoded><![CDATA[<p><strong>Repeating History:  The OSDL and Free Standards Group Merge&#8230;</strong></p>
<p>[Update (2007 Jan 25, 20:35): Stephen O'Grady and I are generally complementary in our thinking, but more aligned. Here's his excellent analysis. I think I'm showing my age.] Monday saw the announcement of the creation of the Linux Foundation by&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Comay</title>
		<link>http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/comment-page-1/#comment-12486</link>
		<dc:creator>David Comay</dc:creator>
		<pubDate>Fri, 26 Jan 2007 00:52:33 +0000</pubDate>
		<guid isPermaLink="false">http://redmonk.com/sogrady/2007/01/25/osdl-fsg-the-linux-foundation-the-qa/#comment-12486</guid>
		<description>Thoughtful post, as usual, Stephen.  I clearly disagree with James Zemlin&#039;s two-horse race characterization and your point about packaging is right-on.  Working together on that aspect of software development benefits the end-user who wishes to install, upgrade, patch and eventually remove that software but it also benefits the developers and distributions who are working to publish the software in the first place.  And in the case of open-source software which behaves pretty much the same regardless of OS platform type, providing a consistent view of it from a packaging standpoint especially makes sense for producers and consumers alike.</description>
		<content:encoded><![CDATA[<p>Thoughtful post, as usual, Stephen.  I clearly disagree with James Zemlin&#8217;s two-horse race characterization and your point about packaging is right-on.  Working together on that aspect of software development benefits the end-user who wishes to install, upgrade, patch and eventually remove that software but it also benefits the developers and distributions who are working to publish the software in the first place.  And in the case of open-source software which behaves pretty much the same regardless of OS platform type, providing a consistent view of it from a packaging standpoint especially makes sense for producers and consumers alike.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Object Caching 314/316 objects using xcache

Served from: redmonk.com @ 2012-05-26 08:05:06 -->
