<?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: Reinventing the Upgrade Wheel</title>
	<atom:link href="http://www.hyperborea.org/journal/archives/2005/06/23/reinventing-the-upgrade-wheel/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.hyperborea.org/journal/archives/2005/06/23/reinventing-the-upgrade-wheel/</link>
	<description>Sci-fi, comics, humor, photos...it&#039;s all fair game.</description>
	<lastBuildDate>Fri, 20 Nov 2009 23:03:41 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Kelson</title>
		<link>http://www.hyperborea.org/journal/archives/2005/06/23/reinventing-the-upgrade-wheel/#comment-40621</link>
		<dc:creator>Kelson</dc:creator>
		<pubDate>Mon, 24 Mar 2008 16:30:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperborea.org/journal/?p=951#comment-40621</guid>
		<description>So how would these severe penalties apply to an open source project that has, say, half a dozen developers but no company?  Are they individually liable?  That would make getting involved in the process a bit risky, wouldn&#039;t it?

And speaking of open-source development, would a project/company be liable for &lt;em&gt;every&lt;/em&gt; release, including unfinished versions pulled off of their publicly-available versioning system?  Or only for &quot;final&quot; versions?

We&#039;d see a lot more perpetual betas, I think.</description>
		<content:encoded><![CDATA[<p>So how would these severe penalties apply to an open source project that has, say, half a dozen developers but no company?  Are they individually liable?  That would make getting involved in the process a bit risky, wouldn&#8217;t it?</p>
<p>And speaking of open-source development, would a project/company be liable for <em>every</em> release, including unfinished versions pulled off of their publicly-available versioning system?  Or only for &#8220;final&#8221; versions?</p>
<p>We&#8217;d see a lot more perpetual betas, I think.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Quirke</title>
		<link>http://www.hyperborea.org/journal/archives/2005/06/23/reinventing-the-upgrade-wheel/#comment-40619</link>
		<dc:creator>Chris Quirke</dc:creator>
		<pubDate>Mon, 24 Mar 2008 13:03:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperborea.org/journal/?p=951#comment-40619</guid>
		<description>The problem is with the &quot;ship it broken, fix it later&quot; mentality.  You have 50 vendor&#039;s sware installed; do you have 50 different updaters?  What about scumbags like Apple, who shovel unwanted software as &quot;updates&quot;?

So you suggest having an OS updater that also pulls updates from an unbounded set of &quot;software vendors&quot;.  What&#039;s wrong with that picture?

The risks of having your code base changed at the whim of software vendors is two-fold.  

First, by definition, a vendor that has to push fixes is a buggy vendor.  If buggy code is pushed out to the whole userbase within 24 hours, the result can be widespread system failures or other DDoS effects.

Second, who is to say what is a &quot;vendor&quot;?  How well do vendors protect their update systems against malware hi-jack?  If malware enters any one vendor&#039;s &quot;update&quot; channel, the result is instant mass infection that drills right through your defenses.

When there&#039;s a single OS update system that accepts &quot;updates&quot; from anything that calls itself a software vendor, the risk increases, because now there&#039;s a single point of possible exploitation.

Nope, the only real answer is to severely penalize software vendors who screw up.  Let them carry the full cost of product recall, rather than get away with popping code on a server and expecting users to pull it down.

That&#039;s the only way you can definitively fix this mess.</description>
		<content:encoded><![CDATA[<p>The problem is with the &#8220;ship it broken, fix it later&#8221; mentality.  You have 50 vendor&#8217;s sware installed; do you have 50 different updaters?  What about scumbags like Apple, who shovel unwanted software as &#8220;updates&#8221;?</p>
<p>So you suggest having an OS updater that also pulls updates from an unbounded set of &#8220;software vendors&#8221;.  What&#8217;s wrong with that picture?</p>
<p>The risks of having your code base changed at the whim of software vendors is two-fold.  </p>
<p>First, by definition, a vendor that has to push fixes is a buggy vendor.  If buggy code is pushed out to the whole userbase within 24 hours, the result can be widespread system failures or other DDoS effects.</p>
<p>Second, who is to say what is a &#8220;vendor&#8221;?  How well do vendors protect their update systems against malware hi-jack?  If malware enters any one vendor&#8217;s &#8220;update&#8221; channel, the result is instant mass infection that drills right through your defenses.</p>
<p>When there&#8217;s a single OS update system that accepts &#8220;updates&#8221; from anything that calls itself a software vendor, the risk increases, because now there&#8217;s a single point of possible exploitation.</p>
<p>Nope, the only real answer is to severely penalize software vendors who screw up.  Let them carry the full cost of product recall, rather than get away with popping code on a server and expecting users to pull it down.</p>
<p>That&#8217;s the only way you can definitively fix this mess.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Apple Software Update: a Simple Solution &#124; K-Squared Ramblings</title>
		<link>http://www.hyperborea.org/journal/archives/2005/06/23/reinventing-the-upgrade-wheel/#comment-40562</link>
		<dc:creator>Apple Software Update: a Simple Solution &#124; K-Squared Ramblings</dc:creator>
		<pubDate>Sat, 22 Mar 2008 01:03:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperborea.org/journal/?p=951#comment-40562</guid>
		<description>[...] single updater for all their Windows software. It&#8217;s nice to consolidate things a bit with the profusion of updaters for what seems like each and every application (sort of like how every mobile device seems to need [...]</description>
		<content:encoded><![CDATA[<p>[...] single updater for all their Windows software. It&#8217;s nice to consolidate things a bit with the profusion of updaters for what seems like each and every application (sort of like how every mobile device seems to need [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
