(I know that this question might be more reasonable on a kernel list,
but a while back I posted the question twice and got no answers.)
The acct struct is defined in /usr/include/sys/acct.h includes both
ac_io and ac_rw for bytes transferred and blocks read or written,
respectively. Fair and good - works (on paper) similarly to unix,
solaris, hp-ux, etc.
However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw
(blocks) are always set to 0 by these two lines:
ac.ac_io = encode_comp_t(0 /* current->io_usage */);
ac.ac_rw = encode_comp_t(ac.ac_io / 1024);
For most purposes, this probably wouldn't be an issue, but I also do
extensive performance analysis on several platforms and have written a
fairly compresive accounting package (as a wraparound for psacct or as
a standalone) including both an improved acctcom and a built-in
reporter for it.
Does anyone know wby the kernel zero's out the bytes transferred data?
(Overhead comes to mind.) Not that it makes a huge differnce for my
purposes (I had to write some wraparound code to make a
"best-guestimate" about the data I'm missing), but curiosity is bugging
me now. When I compile my program on other OS's I get useful data for
char and block i/o and I'd like to find out whether there is something
obvious that I'm just totally missing here...).
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
I recently made several updates to a Linux version of of acctcom
(actually another accounting add-on package) which I've been using for
several years, and one of the people testing it asked a question which
I cannot answer. I'm hoping that someone on this list can give me some
I have previously (over a year ago) asked on both this and a couple of
kernel lists (several times there) about this issue, but nobody has
ever answered. So if you have any info about this, I'd really
As in many (all?) previous Linux kernels, the struct acct (defined in
/usr/include/sys/acct.h) has members ac_io and ac_rw which are
presumably counts of characters transferred and blocks read/written
However, in the kernel code, the ac_io is set to 0 and the ac_rw gets
set to (ac_io/512) or some such - it is set to 0 as well (and thus
these are always reported as 0 in process accounting records. not good
if you're trying to measure them...).
Does anybody know why this is done that way? A long time ago (IIRC
late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the
kernel code but was not successful (I finally produced a bootable
kernel, but it was unstable. Then I changed jobs, got swamped at work,
and eventually gave up).
As I said above, I have previously asked about this issue without
success, and I have essentially given up changing or "fixing" it.
But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's
just too much work for too little added value), I'd really appreciate
knowing the reason. Curiosity and the cat and all that ...
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
Is there any was to do a grep/search on all of the Fedora .spec files
for a specific release (or devel)? I'd be fine with checking them all
out if there was a way to just the the spec files for a specific release.
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
Christopher Aillon <caillon <at> redhat.com> writes:
> If your first reaction had been to ask for more information instead of
> add complaints, I might have mentioned that the plan is to have this for
> F9 (I think so at least, someone can correct me if I'm wrong?). Not
> sure if that counts as long term...
Even if somebody implements a KDE frontend for the GDM backend, that won't make
KDM go away. There's no way KDM is going away for KDE 4.0 which realistically
will be what F9 will be shipping. (And of course, it's even less likely that
said thing would happen in 3.5. Chances that KDE 4.1 will be anywhere near
ready at F9 release are essentially nil, 4.1 might quite possibly not even make
> It is a reasonable request. Can you accept reasonable answers? Notting
> and jkeating have already replied with technical analysis explaining why
> it is not possible.
I have suggested at least 2 technical solutions, none of which needs any
changes to Anaconda:
1. revert the default login manager in Base X to XDM. As much as you
(plural "you") hate that, it's the most logical solution and some other people
in this thread are defending it too.
2. change the fallback logic to pick KDM over GDM. As I said, I think we can
easily put KDM in a subpackage so it doesn't accidentally get installed by a
dependency on kdebase, kde-redhat used to do that in FC6 times.
There's another one, which is even less invasive (and doesn't change the
behavior for the neither-GNOME-nor-KDE case as 1. nor for the
both-GNOME-and-KDE case as 2., but really only affects KDE-but-not-GNOME which
is what needs fixing), but has to be implemented as a specialized Anaconda
if (! upgrade && KDE selected && ! GNOME selected)
echo 'DISPLAYMANAGER="KDE"' >/mnt/sysimage/etc/sysconfig/desktop
> Besides, we already know it's not going to happen for F8. And F9 we
> could in theory have a better all around solution....
"better" is subjective. If upstream KDE isn't going to drop KDM or recommend
against it, IMHO that fact shouldn't be ignored.
While searching for LTSP 5 for Fedora, I didn't find anything but this
bug report https://bugzilla.redhat.com/show_bug.cgi?id=234048. Also,
I've not found anything regarding LTSP in this list.
So, Is someone working on LTSP 5 support for Fedora? Is there some
repository were pick code from or anything?
I sent the email below to fedora-devel some time ago; there was no
response. Let's try again with some additional info. :-)
I'm the fedora maintainer of pybliographer. The development version of
pyblio (which I would like to push to the devel repo soon) has the
capability to interact with openoffice through the pyuno component.
(Bibus can do the same.) It can add citations and generate reference list
in the document for example.
The openoffice.org-pyuno package installs uno.py and other files
under /usr/lib/openoffice.org/program/, so with the default installations
and settings importing uno.py from external python programs gives an
import error. Program specific patches could be used probably to add this
'strange' path to pythonpath, but wouldn't be better to make available
these moduls for python at the openoffice level? See below what debian
Any thoughts, ideas?
---------- Forwarded message ----------
Date: Wed, 12 Sep 2007 23:18:19 +0200 (CEST)
From: Zoltan Kota <z.kota(a)gmx.net>
Reply-To: Development discussions related to Fedora
To: Fedora devel <fedora-devel-list(a)redhat.com>
Subject: openoffice-pyuno and external python programs
Files from openoffice.org-pyuno are installed under
/usr/lib/openoffice.org2.0. So, 'import uno' from python gives an import
error. How should we support external programs to use this module? Should
we patch the program to import uno.py from this directory
somehow? Or would be better to change the installation path in the
Debian for instance installs
There's been a thread over on fedora-maintainers list for a few weeks
proposing that fedora-maintainers be shut down, as it simply serves
bifurcate discussion between here (devel) and there. All responses
were in favour. Many people didn't respond, probably because they
don't bother reading fedora-maintainers. As an aside, notice how
quickly the discussion about naming F8 moved to devel simply because
people weren't signed up to -maintainers. There has been a lot of
discussion about list reorganization - let's not rehash that. One
uncontentious point seems to be, -maintainers must die.
What is the quickest way of getting this done? Which of the myriad
committees does this need to go through?
[I wanted to prepare a bit more before writing this, but it seems
everyone is asking about the same things at once, so this will have to
I'd like know what people think of setting up a font SIG, and if there
are enough would-be contributors for such a SIG to be viable. Fonts
are a very transversal subject in Fedora, and the initial To: list
reflects this. Please take care to reply on fedora-devel only however.
The situation right now is:
1. we have several font packages in Fedora, but are only scratching
what could be packaged.
2. In particular the art team wants a lot more fonts in for its Art spin
3. I don't believe our font selection is optimal for every locale. It
took a near-revolt by our Greek users to get their situation fixed in
Fedora Core 6, and there are probably many other problem locales,
where users just pass on Fedora or bear their pain silently instead of
telling us about problems.
4. The i18n team is nominally in charge of selecting the best fonts
for each locale, but does not always have the right local contacts to
do so. So far i18n has focused on technical problems : if your locale
needs complex IM methods you have i18n visibility, if your locale
poses no technical challenge but your default fonts are suboptimal the
i18n team may not notice you.
4. The l10n team has local contacts and could provide useful feedback
on font choices, currently packaged font problems, local
foundries/font designers that could be contacted to contribute to the
FLOSS font pool, etc but has mostly focused on translation so far.
5. The desktop team handles our font infrastructure and takes the heat
when a font is badly rendered (since we can not use the patented
freetype autohinter many fonts that work fine under windows do not
6. We already have some font-related material disseminated on our wiki:
- packaging rules,
- licensing rules
7. The font situation is bad enough we have a font exception to our
[for example we ship Luxi even though its licensing forbids
modification, making it non-free
8. There are efforts to drain the font licensing swamp and promote
FLOSS fonts (http://unifont.org/go_for_ofl/), they are aligned with
Fedora general objectives yet Fedora has totally ignored them so far
(cf Liberation licensing choices)
This is a stark contrast with the very active debian font team :
The main part of the OLPC font page is the Debian font list!
I believe there is enough interest in the various Fedora groups to
improve the current situation through a font SIG.
This SIG would be tasked with:
A. providing a single point of entry for Fedora people interested in
fonts, centralizing all our packaging rules or at least indexing them
in a single place
B. completing the existing font packaging documentation
C. helping the i18n team maintain the font install list for each locale
D. identifying fonts worthy of packaging for l10n or art reasons
E. identifying problems in existing font packages and helping relay
the info upstream
F. identifying problems in our font infrastructure, packaging
necessary font tools
G. coordinating and effectively packaging new fonts
As the current maintainer of dejavu, and a co-maintainer of charis and
dejavu-lgc, I am ready to write a commented font spec example (B)
(without legacy core font bits, which IMHO should be optional nowadays
; however I'm sure there are people ready and willing to write this
part as an extension), and package a few fonts (G).
The l10n and i18n groups are naturals for (C). We just have to steal
the Debian receipe of having a font-by-locale table in our wiki.
I think it's pretty obvious the art team is motivated by (E). IMHO the
l10n team should have a role there too. Note that doing the legal
analysis of a potential font is far from easy as font licensing
practices are far less clean than software licensing practices. Also
we should try to build font from sources whenever possible, but font
building is often a mess.
G will demand packagers and reviewers. By nature most of them will be
active in other Fedora forums, so we're not talking of a few full-time
SIG members but a lot of part-time contributors.
I created a mockup wiki page to try to make all this clear
It's far from complete, but I hope it's complete enough to give
everyone an idea of the potential SIG scope.
So, who wants to play? Is Fedora ready for a font SIG or should I ask
again next year?