| |||||||||||||
|
| |||||||||||||
An amd64 Debian sarge release in the worksAn amd64 Debian sarge release in the worksPosted Apr 26, 2005 10:13 UTC (Tue) by rahulsundaram (subscriber, #21946)In reply to: An amd64 Debian sarge release in the works by kimunha Parent article: An amd64 Debian sarge release in the works
"If RedHat decide to delay publicizing the source code of security fix by a month then I am in trouble."
Why do you think Red Hat would every do that.
"Important diffrence is that when using Debian, source code of security fix is guarantted to be publicized."
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
Rahul
Red Hat Inc
(Log in to post comments)
An amd64 Debian sarge release in the works Posted Apr 26, 2005 18:14 UTC (Tue) by ewan (subscriber, #5533) [Link] > 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 It's not, of course; you only need to distribute source to people you've distributed the binaries to, so there'd be nothing keeping RH from only releasing the source through RHN. Nothing in the GPL, anyway.
An amd64 Debian sarge release in the works Posted Apr 27, 2005 4:34 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] 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.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. 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.
An amd64 Debian sarge release in the works Posted Apr 27, 2005 9:32 UTC (Wed) by khim (subscriber, #9252) [Link] 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.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"...
An amd64 Debian sarge release in the works Posted Apr 28, 2005 3:16 UTC (Thu) by dvdeug (subscriber, #10998) [Link] Because then you have multiple versions of the package running around, making support much harder.
An amd64 Debian sarge release in the works Posted Apr 27, 2005 8:10 UTC (Wed) by kimunha (guest, #9298) [Link] It is guaranteed that RedHat will publicize its security fix source code (at least to their customer).But, it is not guaranteed the source code of security fix is available immediately after binary of security fix is available. RedHat can DELAY a little, which means serious degrade in the quality of RHEL clones.
I believe in RedHat's devotion to open source philosophy.
Even if RedHat delays the source code a little, I can not blame it.
An amd64 Debian sarge release in the works Posted Apr 28, 2005 17:44 UTC (Thu) by Guhvanoh (subscriber, #4449) [Link] 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.
|
|
||||||||||||