CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
- From: "Andy Kosela" <andy.kosela@xxxxxxxxx>
- Date: Wed, 11 Jun 2008 22:50:34 +0200
On Wed, Jun 11 2008, Robert Watson wrote:
On Wed, 11 Jun 2008, Paul Schmehl wrote:
From a security standport, backporting fixes to previous versions of ports
creates a difficulty. It's much harder to tell, for example, if a RedHat
"port" is vulnerable or not, because RedHat uses their own proprietary
versioning system to define "where" a particular "port" is at.
So, while your system might *say* it's running php version 5.2, it's really
*not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm
just making that up.)
If this idea ever gets off the ground, I *hope* the folks involved with find
a rational, logical way to define the versioning so that it's not
hieroglyphics to the average person.
Egyptian hieroglyphics was a very noble system the secret of which was,
in the days of old, in the possession only of the Hierogrammatists, or
initiated
Egyptian priests. Many occult alphabets and ciphers derived its origin from
egyptian sacred ciphers, as also everything we know as cryptography today.
I guess our english alphabet would be equally strange and uknown to them.
But reading widely available documentation on Redhat's versioning system
would definetly help in understanding its details.
Everything after second - (dash) like in ftp-0.17-33 is Redhat's release
version. In this case this is thirty third release or patch. It is similar to
FreeBSD's naming convention.
You can check changelog and see what has changed since release 1
by issuing:
$ rpm -q --changelog <package>
So the system is very clear and precise, just like FreeBSD system.
The only difference is that upstream version of the package changes
a lot more often than on redhat/centos.
We already do this for some
ports, in that the people involved in adapting and maintaining some of the
larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others,
spend vast amounts of time ensuring that things work well, but largely without
the help of revision control in the ports tree. I'm not proposing we
incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we
could better present the choices reflected there. That doesn't help users of
random tiny software packages, and I'm not sure anything can, but perhaps we
can provide a smoother incremental maintenance path for some key packages.
I think that most system administrators who maintain many FreeBSD servers in
data center environments do not really care about "X.org, KDE, Gnome" and
other desktop applications having those -SECURITY patches backported.
The real concern here is about common server applications. I think that
cutting edge users who run FreeBSD on their workstations are perfectly
aware that things can sometimes break, and to a degree they accept that
risk. But system administrators running mission critical nonstop systems 24/7
cannot accept such risk with the server ports they are using. So if anything
can be improved in ease of upgrading, backporting etc. this is the main
area to investigate, so as to make FreeBSD the most stable and reliable
Unix operating system out there.
--
Andy Kosela
ora et labora
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
- Next by Date: PureComponents Ultimate Suite V2008.1 - 79 .NET WinForms Components for $79
- Previous by thread: Areca Raid 6 ARC-1231 Raid 6 Slow LS Listing Performance on large directory
- Next by thread: PureComponents Ultimate Suite V2008.1 - 79 .NET WinForms Components for $79
- Index(es):
Relevant Pages
|
