LWN: Comments on "An amd64 Debian sarge release in the works" https://lwn.net/Articles/133448/ This is a special feed containing comments posted to the individual LWN article titled "An amd64 Debian sarge release in the works". en-us Wed, 22 Oct 2025 07:16:38 +0000 Wed, 22 Oct 2025 07:16:38 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net An amd64 Debian sarge release in the works https://lwn.net/Articles/133966/ https://lwn.net/Articles/133966/ Guhvanoh To the best of my knowledge, and I have only been using Redhat since RHL2.1, source rpms and binary rpms are published in the same notification. I have yet to see Redhat allow people to download the binary rpms while refusing access to source rpms.<br> Thu, 28 Apr 2005 17:44:59 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133866/ https://lwn.net/Articles/133866/ dvdeug Because then you have multiple versions of the package running around, making support much harder.<br> Thu, 28 Apr 2005 03:16:59 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133691/ https://lwn.net/Articles/133691/ khim <p>I've contemplated switch to Debian but ended with Gentoo instead. There are solution is trival: each package has status for each architecture. Thus package can be upgraded for x86 and sparc, but not for arm and mips. Why not go this way ? It's only logical, after all...</p> <p>P.S. And no x86 is not "the most current one": some changes are essential for x86-64, but not really important for x86 - in such a case package will be marked as "~x86" and "amd64"...</p> Wed, 27 Apr 2005 09:32:18 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133686/ https://lwn.net/Articles/133686/ kimunha It is guaranteed that RedHat will publicize its security fix source code (at least to their customer).<br> But, it is not guaranteed the source code of security fix is available immediately after binary of security fix is available.<br> RedHat can DELAY a little, which means serious degrade in the quality of RHEL clones.<br> <p> I believe in RedHat's devotion to open source philosophy.<br> I also believe RedHat will keep major contribution to open source community.<br> But if RHEL clones mean serious threat to their sales, they are FORCED to do something.<br> <p> Even if RedHat delays the source code a little, I can not blame it.<br> It is a competition which is so common in free economy.<br> And who in the world support their competitors?<br> Wed, 27 Apr 2005 08:10:54 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133675/ https://lwn.net/Articles/133675/ JoeBuck The GPL does not forbid the entire Red Hat staff from jumping out of an airplane without a parachute, but that doesn't mean it's remotely possible. They aren't going to hoard their fixes, or give them only to their customers. You can't do this as a distro, because you have to work with the upstream, and your own engineers wouldn't put up with something so socially irresponsible. <p> If they were suddenly possessed by the devil and tried to do this, at least one of their customers would provide the source of the security fix to the public; Red Hat's EULA does not and cannot (by the GPL) prevent this. <p> And speaking of holding back security fixes: until recently, Debian had been holding back some security updates for weeks because of delays in getting them built for the Arm architecture. Despite all of the fuss, it will be good for Debian that they are shifting some of their architectures to second-class status post-Sarge, because the alternative is to let their x86 users run with security holes for an extended period. Wed, 27 Apr 2005 04:34:25 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133637/ https://lwn.net/Articles/133637/ ewan <font class="QuotedText">&gt; I believe that its equally guaranteed that Red Hat will make public all </font><br> <font class="QuotedText">&gt; of its changes to any software. After all for GPL license software its </font><br> <font class="QuotedText">&gt; required that you do so anyway </font><br> <br> It's not, of course; you only need to distribute source to people you've <br> distributed the binaries to, so there'd be nothing keeping RH from only <br> releasing the source through RHN. Nothing in the GPL, anyway. <br> Tue, 26 Apr 2005 18:14:49 +0000 Just tried it out last night https://lwn.net/Articles/133576/ https://lwn.net/Articles/133576/ blaz You would probably have the same problems with ia386 sarge because of kernel problems. I couldn't get the 2.6 kernel to work properly with my recent hardware until at least 2.6.10 or so.<br> Tue, 26 Apr 2005 11:24:01 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133545/ https://lwn.net/Articles/133545/ rahulsundaram "If RedHat decide to delay publicizing the source code of security fix by a month then I am in trouble."<br> <p> Why do you think Red Hat would every do that. <br> <p> "Important diffrence is that when using Debian, source code of security fix is guarantted to be publicized."<br> <p> I believe that its equally guaranteed that Red Hat will make public all of its changes to any software. After all for GPL license software its required that you do so anyway<br> <p> Rahul<br> <p> Red Hat Inc<br> Tue, 26 Apr 2005 10:13:02 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133535/ https://lwn.net/Articles/133535/ kimunha It is greate news.<br> <p> Now I have a stable, free(in cost), supported server OS.<br> <p> I use CentOS(Recompiled RHEL) for server but it's depend on RedHat generously publicize the source of security fix.<br> <p> If RedHat decide to delay publicizing the source code of security fix by a month then I am in trouble.<br> <p> <p> Even Debian does not officially support it, CentOS is same that RedHat does not officially support it.<br> <p> Important diffrence is that when using Debian, source code of security fix is guarantted to be publicized.<br> <p> <p> Tue, 26 Apr 2005 02:59:23 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133458/ https://lwn.net/Articles/133458/ avr As I understand it, it is not released as sarge, or more precisely. The AMD64 release will not be part of Debian stable as a supported architecture.<br> The porting team made a huge effort to have it officially included, but it didn't make it. So the porting team decided to make a release parallel to sarge, taking care of the support themselves.<br> <p> This is how I interpret the above combined together with the amd64 discussion on debian-devel.<br> <p> Incidentally, the port now gets to be a guinnee pig for the upcoming unloved architectures of Debian, where the porting teams will be supposed to do their own security support, amongst other things, that up to and including Sarge have been taken care of by Debian.<br> <p> Mon, 25 Apr 2005 20:53:35 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133457/ https://lwn.net/Articles/133457/ jwb Great news. They can hardly have expected AMD64 to remain out of sarge, as even in it's unsanctioned experimental state, it is the second most popular architecture after i386 (according to Popularity Contest). It is three times more popular than PowerPC and 9 times more frequently seen than Alpha. It deserves a Sarge release.<br> Mon, 25 Apr 2005 20:29:30 +0000 An amd64 Debian sarge release in the works https://lwn.net/Articles/133456/ https://lwn.net/Articles/133456/ jebba I wrote a mini-HOWTO in my blog last November about installing debian on AMD64. Perhaps someone will find it helpful...<P> <A HREF="http://jebba.blagblagblag.org/index.php?p=137">http://jebba.blagblagblag.org/index.php?p=137</A> Mon, 25 Apr 2005 20:06:41 +0000 Just tried it out last night https://lwn.net/Articles/133455/ https://lwn.net/Articles/133455/ Ross I tried to install Sarge AMD64 last night. It wasn't able to detect either<br> the onboard SATA or SATA2 controllers though I know there are drivers for<br> both (NVidia and SIL). It also failed to detect either onboard Ethernet<br> card (NVidia and Marvel). Apparently the first is fixed in later kernels,<br> but all the install CDs are using 2.6.8. The latter is strange because the<br> Marvel driver is specifically listed, but if I try to load it it says there<br> is no hardware (yet /proc/pci lists it). Maybe it's just missing some PCI<br> IDs or something.<br> <p> Not a very good experience overall. Hopefully some of these driver issues<br> can be worked out.<br> Mon, 25 Apr 2005 20:05:15 +0000