The latest release of nsca finally increases the 512 characters message
limitation to 4096 and is backward compatible with older client using
the 512 characters message. This was a long awaited change. The only
limitation is the nsca server needs to be upgraded first.
The update is already in Rawhide and I plan to push this as an update in
all Fedora and EPEL testing repos and keep it there for some time before
pushing to stable so people have a change to catch up.
I believe it is ok to push such a change if correctly documented and
advertised on selected mailing lists. Am I correct ?
I read the list thread concerning a Fedora rolling release distribution,
and I found it interesting enough to compel me to join the list and
First, I think a rolling release Fedora is a fantastic idea. I'm
certain that it's possible, since I've been pulling packages from 15,
16, and Rawhide downstream to Fuduntu which still has a lot of 14 left
at it's core with much success.
Some potential reasons why it would be a good idea.. A lot of us don't
like to risk a major upgrade every 6 months to a year, or reinstall. We
can always save a dump of rpms, and not format /home but still, that's a
lot of unnecessary work. If you aren't in a position to do a full
backup (right or wrong) it becomes even more of a challenge.
It's also very convenient to upgrade to Firefox 9 for example without
having to go to Remi, or spend hours upgrading everything. If it rolls,
everything gets upgraded over time. Huge convenience factor here.
I just pulled LibreOffice 3.4.4 from Fedora 16 down to Fuduntu. I'm
also shipping Firefox 9.
If you were interested in going forward with a rolling release model,
your community is large enough that it doesn't have to be your core
product. It could though be the foundation for your core product.
I'd recommend continuing your release cycle, shifting to rolling Fedora,
and point release from that.
Rawhide IMHO is "rolling", but it's also very unstable, as you all well
The idea thrown out there that discussed using a waterfall repository
method is solid, we have been doing it for over year now.
Development, Rawhide - done.
Testing - Reasonably stable, packages promoted from development when
they are ready.
Stable - After you have tested the packages with a reasonably wide
audience, promote them to stable.
Point in time release from your stable repository as Fedora 17, 18, 19.
This model been working for us for a short while now.
You guys are already set up for success, IMHO much more so than some of
the other distributions out there. That's why I chose to base off of
it. Are we doing some things wrong? Definitely, but we are also doing
some things well enough to know that Fedora would be wildly successful
with a rolling release.
As for the comments about users upset that they suddenly get GNOME 3 via
a rolling upgrade, that's a communications issue and also what spins and
remixes are for.
That is my $.02. I really hope to see Fedora go this route, but if
Fedora decides to stick to the current release model (which is already
excellent) those that want an RPM based rolling release are welcome to
come help out at Fuduntu. :D
I am late to the game but wanted to thank Harald and Kay for their
efforts, and to encourage them to go even further.
History has brought us to a point where there are at least 7 standard
places to put binaries (not counting ~/bin):
plus a handful more locations for libraries.
I accept your premises that the historical reasons for this division
of binaries are no longer compelling, that the present variety of
locations is confusing and works against cross-distro compatibility
and that simplification is a good thing in itself. I encourage you
to simplify things further by merging /usr/sbin into /usr/bin.
While the reasons for the current categorization of binaries are no
longer compelling, I think there is a case to make for a new division
of binaries. Specifically, it is useful to separate those programs
that are managed by a package management system from those that are
not. Additionally, "app" style programs will become more common in
the future, whether on a portable or a desktop. Those "app" style
programs are the only way one can create a central marketplace for
small, easily downloaded and installed, distro-agnostic programs.
Such a marketplace will become increasingly important to the vitality
of any computing platform, including Linux. Keeping "apps" separate
from managed and locally-compiled programs would be useful.
I like the general approach that systemd has taken to configuration
-- putting most of its default configuration in /lib/systemd and
allowing host-specific entries in /etc/systemd to override them. I
would like to see programs (including systemd) adopt a more rigorous
version of that approach -- with all default configuration in /usr.
The result would be that, immediately after installation, /etc would
So here is my suggestion:
/app (host specific "app" style programs -- "drag-and-drop"
programs wholly contained within a single directory
tree with no
dependencies outside that tree -- and which include
can be overriden by configuration in an user's home
/etc (host specific configuration -- overrides all defaults --
package manager cannot write to this directory)
/opt (unmanaged software -- both site and host specific)
/conf (all site or locally-compiled programs would put their
configuration files here)
/usr (managed software -- both distro and site packaged)
/distro (distro default configuration files)
/site (site default configuration -- overrides distro
With this directory structure, as a site administrator I can package
my own site-wide configuration files, put them in a local repo, and
override the distro default configuration. By limiting /etc to host-
specific configuration, I maintain a clean separation of:
+ distro-default configuration files, which are never edited,
and which are updated as distro packages are updated,
+ my site-default configuration files, which are never edited,
and which are updated from my local repo, and
+ host-specific configuration files, which would probably only
be necessary for a handful of programs per host.
This approach also makes backing up easier. There is no need to back
up any part of /usr -- it can be re-installed from repos, if it is
not being mounted from a remote server.
On a server, one would need to back up unmanaged software from /opt,
host-specific configuration from a much slimmed-down /etc, and data
files from /srv and /var.
On a portable or desktop, /opt will probably be empty, /var will be
expendable, and one would just need to back up /app, a much slimmed-
down /etc, and /home, which should contain users data files and user-
specific configuration for apps.
This suggestion creates one new top-level directory, keeps the
confusing historical names for compatibility purposes, and turns at
least 5 current directories into symlinks:
/bin -> /usr/bin
/sbin -> /usr/bin
/lib -> /usr/lib
/usr/local -> /opt
/usr/sbin -> /usr/bin
Bottomline, congratulations Harald and Kay on a good first step to
simplifying and rationalizing the file structure. Now keep going.
The packages containing software from the Globus Toolkit have been
updated to Globus Toolkit version 5.2 in rawhide. The update for Fedora
15 and 16 and EPEL is currently in the testing repo, and buildroot
overrides are also in place for these releases.
Many of the changes implemented by upstream in this release, such as the
removal of the flavour tags in the library names and the support for
standard installation paths, were already present in the Fedora packages
of earlier releases using patches. This update is backwards compatible
and does not introduce any soname bumps.
The most important change is the handling of threads. In earlier
releases the threading model was chosen at compilation time, and the
model used by the libraries in Fedora and EPEL was using pthreads. In
this release the threading model is instead chosen at runtime, either by
using API calls or by setting environment variables. The default model
in the new release is the forking model, but also the pthread model is
In order to preserve the behaviour of applications linked to previous
versions, versioned symbols have been introduced so that the new
libraries will switch to the pthread threading model automatically when
used by applications that were linked to earlier versions.
Upstream's release notes are available here:
If you want to help completing the update to GT 5.2 there are 4 rename
reviews and 3 reviews for new packages that need a reviewer.
New package reviews: