<?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: The Future of Packaging Software in Linux</title>
	<atom:link href="http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/feed/" rel="self" type="application/rss+xml" />
	<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/</link>
	<description>All About GNU/Linux and BSD - reviews, comparisons, articles</description>
	<lastBuildDate>Fri, 24 May 2013 15:34:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Felipe Contreras</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-46298</link>
		<dc:creator>Felipe Contreras</dc:creator>
		<pubDate>Tue, 31 Jul 2007 08:14:50 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-46298</guid>
		<description><![CDATA[I have thought on this for quite some time and I think there’s a lot of things to do. I’ll try to explain why I think so. I might make mistakes, specially with debian packaging system as I’ve barely used it; if I do please ping me back.

&lt;a href=&quot;http://felipec.wordpress.com/2007/07/31/the-future-of-packaging-software-in-linux/#comments&quot; rel=&quot;nofollow&quot;&gt;More here&lt;/a&gt;.]]></description>
		<content:encoded><![CDATA[<p>I have thought on this for quite some time and I think there’s a lot of things to do. I’ll try to explain why I think so. I might make mistakes, specially with debian packaging system as I’ve barely used it; if I do please ping me back.</p>
<p><a href="http://felipec.wordpress.com/2007/07/31/the-future-of-packaging-software-in-linux/#comments" rel="nofollow">More here</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nospam</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-18903</link>
		<dc:creator>Nospam</dc:creator>
		<pubDate>Wed, 07 Mar 2007 08:41:51 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-18903</guid>
		<description><![CDATA[I have been evaluating Linux distro one a year for ten years for use on a family desktop.
On January 2007 the unbilievable happened : I found out that Linux had reached the level of quality I expected from a modern OS on a desktop system (I never questionned the quality of linux on a server system).

However, there are three remaining concerns :
- the software installation mess. Come on, Linux developers. You cannot seriously expect to gain market shares on the desktop if you keep happy with forcing lay people either to ./configure, make, make install, make clean, either to find out or wait for distro-specific rpms, .deb or whatever.
- the copyright issues. One cannot expect acceptance of linux on the family market without a proper, out-of-the-box DVD and various codecs .avi reader.
- the game issue. We need games for Linux.]]></description>
		<content:encoded><![CDATA[<p>I have been evaluating Linux distro one a year for ten years for use on a family desktop.<br />
On January 2007 the unbilievable happened : I found out that Linux had reached the level of quality I expected from a modern OS on a desktop system (I never questionned the quality of linux on a server system).</p>
<p>However, there are three remaining concerns :<br />
- the software installation mess. Come on, Linux developers. You cannot seriously expect to gain market shares on the desktop if you keep happy with forcing lay people either to ./configure, make, make install, make clean, either to find out or wait for distro-specific rpms, .deb or whatever.<br />
- the copyright issues. One cannot expect acceptance of linux on the family market without a proper, out-of-the-box DVD and various codecs .avi reader.<br />
- the game issue. We need games for Linux.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: snoozzzer</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17581</link>
		<dc:creator>snoozzzer</dc:creator>
		<pubDate>Mon, 26 Feb 2007 14:41:05 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17581</guid>
		<description><![CDATA[Just a little thing that&#039;s been bugging me. BSD had ports, and then gentoo used the idea for portage]]></description>
		<content:encoded><![CDATA[<p>Just a little thing that&#8217;s been bugging me. BSD had ports, and then gentoo used the idea for portage</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rene Rebe</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17106</link>
		<dc:creator>Rene Rebe</dc:creator>
		<pubDate>Fri, 23 Feb 2007 09:00:46 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17106</guid>
		<description><![CDATA[In the BSD Port sysem a-like sucessors the &lt;a href=&quot;http://www.t2-project.org&quot; rel=&quot;nofollow&quot;&gt;T2 SDE Project&lt;/a&gt; can be added.]]></description>
		<content:encoded><![CDATA[<p>In the BSD Port sysem a-like sucessors the <a href="http://www.t2-project.org" rel="nofollow">T2 SDE Project</a> can be added.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henrik</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17101</link>
		<dc:creator>Henrik</dc:creator>
		<pubDate>Fri, 23 Feb 2007 08:47:38 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17101</guid>
		<description><![CDATA[This combined with another article here (&lt;a href=&quot;http://polishlinux.org/gnu/five-things-to-know-when-you-switch-to-linux/&quot; rel=&quot;nofollow&quot;&gt;Five things to know when you switch to Linux&lt;/a&gt;) makes for a good first time linux user article.]]></description>
		<content:encoded><![CDATA[<p>This combined with another article here (<a href="http://polishlinux.org/gnu/five-things-to-know-when-you-switch-to-linux/" rel="nofollow">Five things to know when you switch to Linux</a>) makes for a good first time linux user article.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ian</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17100</link>
		<dc:creator>Ian</dc:creator>
		<pubDate>Fri, 23 Feb 2007 08:43:58 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17100</guid>
		<description><![CDATA[I suspect that Linux will end up with two package installation systems. An old native in-house system (APT/YUM/URPMI/YAST/Smart/TGZ/Ports/Portage) used for updates, installation and distro-supported applications.  The other system would be a universal 3rd-party system for vendors to use.  

One possible solution would be being able to compile encrypted source code/byte code.  If that could happen, 3rd parties could distribute the encrypted source (which would be machine-intelligible but human-unintelligible) and an auto-maker/compiler could configure, make and install the software.  But it&#039;s probably an unlikely thought.

A few ideas would be 

A) Settle on where software is to be installed.  Either ask the User or install to a set place determined on install.  (desktop computers could get away with an /Applications file, while servers/business users would may want a /home/User/Appliation for each user.)

B) Discourage loosely linked applications.  Applications should contain all libraries and programs needed to make that application work that doesn&#039;t need an Distro to suprot. (It&#039;s fair to expect someone to be running KDE or be using an ATI card.  Those excitations should be communicated upfront though, like what&#039;s listed on a boxed software&#039;s System Requirements.)  The installer should install all missing/non-exsitant library/program data, skipping over what&#039;s already installed.  The best solution to program dependency is to minimize or eliminate dependencies.

Until the user-base speaks with a super-majority voice asking for one system, unless the top 10 Distos collaborate or Linus or the FSF Use their authority to say &quot;use this universal package manager&quot;, I don&#039;t expect a universal package manager.  I would be nice.]]></description>
		<content:encoded><![CDATA[<p>I suspect that Linux will end up with two package installation systems. An old native in-house system (APT/YUM/URPMI/YAST/Smart/TGZ/Ports/Portage) used for updates, installation and distro-supported applications.  The other system would be a universal 3rd-party system for vendors to use.  </p>
<p>One possible solution would be being able to compile encrypted source code/byte code.  If that could happen, 3rd parties could distribute the encrypted source (which would be machine-intelligible but human-unintelligible) and an auto-maker/compiler could configure, make and install the software.  But it&#8217;s probably an unlikely thought.</p>
<p>A few ideas would be </p>
<p>A) Settle on where software is to be installed.  Either ask the User or install to a set place determined on install.  (desktop computers could get away with an /Applications file, while servers/business users would may want a /home/User/Appliation for each user.)</p>
<p>B) Discourage loosely linked applications.  Applications should contain all libraries and programs needed to make that application work that doesn&#8217;t need an Distro to suprot. (It&#8217;s fair to expect someone to be running KDE or be using an ATI card.  Those excitations should be communicated upfront though, like what&#8217;s listed on a boxed software&#8217;s System Requirements.)  The installer should install all missing/non-exsitant library/program data, skipping over what&#8217;s already installed.  The best solution to program dependency is to minimize or eliminate dependencies.</p>
<p>Until the user-base speaks with a super-majority voice asking for one system, unless the top 10 Distos collaborate or Linus or the FSF Use their authority to say &#8220;use this universal package manager&#8221;, I don&#8217;t expect a universal package manager.  I would be nice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: João Pinto</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17096</link>
		<dc:creator>João Pinto</dc:creator>
		<pubDate>Fri, 23 Feb 2007 08:18:22 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17096</guid>
		<description><![CDATA[People should understand that CNR is just a service/interface, it uses the Debian package forma with APT repositories. The major advantage is the fancy interface and the commercial repository. 
The CNR packages have the same features and problems of the Debian ones.
The news of CNR becoming available for Ubuntu is just marketing, because Linspire will be based on Ubuntu all their packages will need to be Ubuntu (Debian) compatible, not the way around.]]></description>
		<content:encoded><![CDATA[<p>People should understand that CNR is just a service/interface, it uses the Debian package forma with APT repositories. The major advantage is the fancy interface and the commercial repository.<br />
The CNR packages have the same features and problems of the Debian ones.<br />
The news of CNR becoming available for Ubuntu is just marketing, because Linspire will be based on Ubuntu all their packages will need to be Ubuntu (Debian) compatible, not the way around.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew</title>
		<link>http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17084</link>
		<dc:creator>Andrew</dc:creator>
		<pubDate>Fri, 23 Feb 2007 04:27:17 +0000</pubDate>
		<guid isPermaLink="false">http://polishlinux.org/linux/the-future-of-packaging-software-in-linux/#comment-17084</guid>
		<description><![CDATA[The comments on this article are mind numbing.

Everyone who is arguing that this topic isn&#039;t relevant is insane. It will be amazing when Linux has a more standardized package management system. Using Linux applications will be so much easier when you have the option of using packages from anywhere (you trust) rather than choosing a distro based on the packages you need _now_ and having to compile the rest from scratch.

It&#039;s projects to combine the efforts of packaging, desktop tools, and kernel/stability that will really advance Linux. Freeing all of the developers and administrators to work on other cool projects (projects which would be much more focused when they only have to work with a single packaging system/library/standard by the way) to make desktop and server management easier.

Poor &quot;joe user&quot; who is mad because developers tend to be introverts. You can find grouchy people associated with anything. Nobody is going to apologize for you encountering a certain personality -- there&#039;s plenty of room in the open source world for all of them, and at least he&#039;s actually contributing (something that will probably be packaged later by a more &quot;people person&quot;). Not everyone has to care about user needs, plenty of the hard core coding that needs to be done is going to be done by the geeky personality... not to hurt your feelings, you _are_ special!

So, yeah, this is a very relevant topic and focusing on it will be a huge gain for the operating systems that take advantage of it. /rant]]></description>
		<content:encoded><![CDATA[<p>The comments on this article are mind numbing.</p>
<p>Everyone who is arguing that this topic isn&#8217;t relevant is insane. It will be amazing when Linux has a more standardized package management system. Using Linux applications will be so much easier when you have the option of using packages from anywhere (you trust) rather than choosing a distro based on the packages you need _now_ and having to compile the rest from scratch.</p>
<p>It&#8217;s projects to combine the efforts of packaging, desktop tools, and kernel/stability that will really advance Linux. Freeing all of the developers and administrators to work on other cool projects (projects which would be much more focused when they only have to work with a single packaging system/library/standard by the way) to make desktop and server management easier.</p>
<p>Poor &#8220;joe user&#8221; who is mad because developers tend to be introverts. You can find grouchy people associated with anything. Nobody is going to apologize for you encountering a certain personality &#8212; there&#8217;s plenty of room in the open source world for all of them, and at least he&#8217;s actually contributing (something that will probably be packaged later by a more &#8220;people person&#8221;). Not everyone has to care about user needs, plenty of the hard core coding that needs to be done is going to be done by the geeky personality&#8230; not to hurt your feelings, you _are_ special!</p>
<p>So, yeah, this is a very relevant topic and focusing on it will be a huge gain for the operating systems that take advantage of it. /rant</p>
]]></content:encoded>
	</item>
</channel>
</rss>
