<?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: Links 19/10/2008: New Linux Kernel, Migrations to GNU/Linux, PCLinuxOS 2009</title>
	<atom:link href="http://techrights.org/2008/10/19/linuxpclinuxos-2009/feed/" rel="self" type="application/rss+xml" />
	<link>http://techrights.org/2008/10/19/linuxpclinuxos-2009/</link>
	<description>Free Software Sentry – watching and reporting maneuvers of those threatened by software freedom</description>
	<lastBuildDate>Tue, 07 Feb 2012 14:00:35 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Roy Schestowitz</title>
		<link>http://techrights.org/2008/10/19/linuxpclinuxos-2009/comment-page-1/#comment-28989</link>
		<dc:creator>Roy Schestowitz</dc:creator>
		<pubDate>Mon, 20 Oct 2008 13:34:49 +0000</pubDate>
		<guid isPermaLink="false">http://boycottnovell.com/2008/10/19/linuxpclinuxos-2009/#comment-28989</guid>
		<description>That&#039;s why legal enforcements (e.g. a policy) requiring open standards and/or Free software are needed and are increasingly adopted.</description>
		<content:encoded><![CDATA[<p>That&#8217;s why legal enforcements (e.g. a policy) requiring open standards and/or Free software are needed and are increasingly adopted.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jose_X</title>
		<link>http://techrights.org/2008/10/19/linuxpclinuxos-2009/comment-page-1/#comment-28987</link>
		<dc:creator>Jose_X</dc:creator>
		<pubDate>Mon, 20 Oct 2008 13:22:08 +0000</pubDate>
		<guid isPermaLink="false">http://boycottnovell.com/2008/10/19/linuxpclinuxos-2009/#comment-28987</guid>
		<description>http://ostatic.com/174660-blog/open-source-is-ideal-open-formats-are-critical

The case made I think is about the superiority of open formats.

I agree partially. In real life, there will be closed source and that is fine if people know what they are getting into. Some businesses just won&#039;t reveal source, but some people may trust these companies anyway. In these cases, it helps to have &quot;open formats&quot;. Such a format may or may not be useful with the products of these closed source companies. It depends, and trust will be a factor in guiding buying decisions.

What I want to stress is that an &quot;open format&quot; is only as open as the implementations &quot;supporting&quot; it actually choose to support it faithfully with no tricks. Of course, some formats allow for undocumented extensions to be created. Buyers that accept this would be wise to realize that this means anything goes for the closed source undocumented extensions even from otherwise honest companies.. a box of chocolate -- you never know whatcha gonna get.

The applications define how the formats are interpreted. There are many ways to be off from the published docs. Small differences might be tolerable but not always, and the vendors can probably implement any extension mechanism they want even within the guidelines of the standard (eg, implementing the extension as comments or cued in through allowed otherwise insignificant whitespace and other variations and possibly in encrypted/nonobvious fashion).

With open source, even different formats need not present a problem because the open source of the app allows converters and filters to be created to a large degree (the issues would be that different subsets of functionalities mean that some information will not be used depending on the application reading/converting the file).

So the short of this is that in a bug-free world with no funny business being carried out by closed source companies and with all extensions by them being fully documented, a common open format allows for interop to a great degree and should be all that is needed from a strictly &quot;end&quot; user pov. In the world we live in, if you go with a closed source product you risk from minor to major incompatibilities.

I want to mention a special case of closed source products. Monopolies have business incentives to be sloppy and secretive so that others cannot interoperate. Failures to interoperate with world+dog benefit the monopolist.</description>
		<content:encoded><![CDATA[<p><a href="http://ostatic.com/174660-blog/open-source-is-ideal-open-formats-are-critical" rel="nofollow">http://ostatic.com/174660-blog/open-source-is-ideal-open-formats-are-critical</a></p>
<p>The case made I think is about the superiority of open formats.</p>
<p>I agree partially. In real life, there will be closed source and that is fine if people know what they are getting into. Some businesses just won&#8217;t reveal source, but some people may trust these companies anyway. In these cases, it helps to have &#8220;open formats&#8221;. Such a format may or may not be useful with the products of these closed source companies. It depends, and trust will be a factor in guiding buying decisions.</p>
<p>What I want to stress is that an &#8220;open format&#8221; is only as open as the implementations &#8220;supporting&#8221; it actually choose to support it faithfully with no tricks. Of course, some formats allow for undocumented extensions to be created. Buyers that accept this would be wise to realize that this means anything goes for the closed source undocumented extensions even from otherwise honest companies.. a box of chocolate &#8212; you never know whatcha gonna get.</p>
<p>The applications define how the formats are interpreted. There are many ways to be off from the published docs. Small differences might be tolerable but not always, and the vendors can probably implement any extension mechanism they want even within the guidelines of the standard (eg, implementing the extension as comments or cued in through allowed otherwise insignificant whitespace and other variations and possibly in encrypted/nonobvious fashion).</p>
<p>With open source, even different formats need not present a problem because the open source of the app allows converters and filters to be created to a large degree (the issues would be that different subsets of functionalities mean that some information will not be used depending on the application reading/converting the file).</p>
<p>So the short of this is that in a bug-free world with no funny business being carried out by closed source companies and with all extensions by them being fully documented, a common open format allows for interop to a great degree and should be all that is needed from a strictly &#8220;end&#8221; user pov. In the world we live in, if you go with a closed source product you risk from minor to major incompatibilities.</p>
<p>I want to mention a special case of closed source products. Monopolies have business incentives to be sloppy and secretive so that others cannot interoperate. Failures to interoperate with world+dog benefit the monopolist.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

