(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 put firefox-trunk SRPM based on current fedora rawhide one at
Notice: this package breaks the dependency against devhelp and yelp.
Janina Sajka <janina(a)rednote.net> wrote:
> Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
> near ready for prime time, but I have a compelling reason to start using
> ff3 fairly soon and would rather install from rpm, of course.
> BTW: My compelling reason is that FF3 will contain a11y support that
> should prove superior to any yet seen on any platform. Fingers crossed,
> etc ...
Linux system administrator and developer
I develop /etc/net project (http://etcnet.org) and my goal is to integrate it
into Fedora Core.
I am a member of ALTLinux Team. /etc/net is already integrated into ALTLinux
development tree and should soon be seen in 3.0 version.
I know that ArchLinux has /etc/net in its repository. IDMS Linux did so too,
but i haven't heard from them for last months.
My skills include 6 years Linux experience, several programming
languages, 5 years of mixed software development and system/network
administration and so on, but I guess it's not related much to my goal now.
I have reviewed current initscripts buglist.
Some bugs are not bugs in /etc/net:
#65114 RFE: ifup-aliases iproute support, ifup/ifup-aliases scop...
#75390 it would be nice to tie bandwidth shaping into the networ...
#129820 initscripts maclist patch
#132252 Request for addition of routing rule config file
#132912 No additional IP addresses at ethX without aliased devices
#132925 initscripts use old ifconfig instead of iproute2
#154348 Adds support for WPA (Wi-Fi Protected Access) to the ifup...
#168990 No ifup-gre/ifdown-gre scripts.
#170884 MTU of ethernet card can't be set before interface is up
#171763 Enhancement to initscripts
Some bugs gave me ideas how to improve /etc/net:
#59114 .d-style scripts for ifup/ifdown
#119952 RFE: Add hook for "local" network initialization
#124045 Support setting a metric on interface routes
The whole process, if we don't face some unexpected problems, should take
3 to 6 months. What I need:
1. Ability to advocate patches (sometimes heavy) to about 10-20 FC packages.
2. Probably some help with documentation.
How can we start?
pub 1024D/6D1844F2 2002-11-11
Key fingerprint = AF2F DDAE 7EB3 4699 09FF F0FC 00B1 6D41 6D18 44F2
uid Denis Ovsienko <linux(a)pilot.org.ua>
uid Denis Ovsienko (http://pilot.org.ua) <pilot(a)altlinux.ru>
sub 2048g/57B7ACBE 2002-11-11
I just checked my laptop which is a core2duo with 1 gig of ram. WinXP
reports PAE but fc6 installed non-PAE kernel. Would the PAE kernel be
better for me or should I stick with the non-PAE? Obviously I don't need
highmem support, will that be to much of a performance hit?
model name : Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
I've built a set of FC6 ia64 ISOs (CD set and DVD) which are available
for download from
(Click on Download on left-hand side, and then the FC6 directory)
These are labelled as FC6GOLD to differentiate them from the broken sets
that Yanmin attempted to release last week. md5sums are provided.
We have verified CD, DVD, NFS, http, ftp installs on various HP & SGI boxes.
Please remember that FC6 ia64 is _unsupported_ by Fedora. You can file
bugs, but be sure to file them against the devel branch of Fedora Core.
Also, add "fedora-ia64" to the "blocks" field of the BZ.
I have updated 3 boxes from FC5->FC6 (x86_64) using anaconda (booted
from a DVD).
All three of them is nothing that can be called a slow machine:
AMD64 3000+ @ 4100+ (2.61ghz)
7200 RPM 2MB Cache IDE Seagate HDD 120GB
Core 2 Duo T7400 2x2.17Ghz 4MB shared L3 Cache
7200 RPM 8MB Cache SATA Hitatchi HDD 80GB
AMD Opteron 170 @ 2x2.7Ghz
2x120GB Hitatchi SATAII HDD 8MB Cache MD RAID0
Update time was ~90-120min depending on the sys.
Why does the update take that long? A reinstall is much faster..
I think that improving this should be a goal for FC7
Also why isn't it possible to install from a md raid partition? Should I
fill a RFE?
Are we still planning to completely replace termcap with
ncurses in Fedora?
While I welcome reducing the number of dupe packages, I'm
worried by the impact of this change on the size and
performance of many core programs.
libncurses is much bigger than libtermcap, and also has
oddly large .bss and .data sections:
bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2
text data bss dec hex filename
319006 56608 3592 379206 5c946 /lib64/libncurses.so.5
10483 788 112 11383 2c77 /lib64/libtermcap.so.2
this is going to impact very negatively on the RSS of several
critical programs such as bash and python.
I'm also worried that the overall time required spent for a
fork may increase considerably.
But maybe ncurses can easily be fixed to avoid global data and
// Bernardo Innocenti - Develer S.r.l., R&D dept.
Okay its come to my attention that the readahead configs have a
difficult time being kept in sync as package updates roll out. For fc6
right now for example readahead is out of sync with firefox libraries.
Can we update readahead's implementation so we can get per package
control of the default configs? Is a readahead.d/ structure
I want to point out that we lose significant value with read-ahead if
we can't ensure that the listings will be in-sync as package updates
are issued. And re-spinning readahead updates periodically to attempt
to sync a centralized config file is horrible inefficient and may
never be perfectly in-sync considering the churn of updates during a
We've recently started working on a project called Linux Hardware
Project or in short LHCP. Goals are:
* Provide a list of working hardware for people wanting to buy a new
* Provide an idea on what hardware our/your distribution in run on
* Provide a list of hardware we need to improve support for
* Provide an interface to all above that allows simple and complicated
* Get the user a list of thing that should work and a way to test that
* Tell the user how good his hardware is supported
There have been several Hardware Compatibility lists from vendors and
other projects in the past, but most of them were limited in one
aspect or another - so we start our own.
To achive this we are building a modular framework to generate, collect,
and analyze information about all components of systems running Linux
and how well each component works.
The project is currently in it's infancy, but following the typical
approach of open source projects ("Release early, release often!") we've
decided to already officially announce it.
Current status is that the basic GUI application for testing is up and
with some test modules. We're now in the process of writing the first real
data collection and test modules and are currently starting to design the
server end of the side.
The home page of the project can be found here:
If you want to take a look at the current source code you can checked it out
using Mercurial in read only mode like this:
hg clone http://hg.fedoraproject.org/hg/hosted/LHCP
For development discussions a mailing list has been set up here:
Although the project is hosted under Fedora we're aiming it to be very
distribution independant, so supporting other distributions should be
do. We have some basic requirements on what is needed on the system for
simply work, but a lot of things will be optional.
Read ya, Phil & Fabi
Philipp Knirsch | Tel.: +49-711-96437-470
Development | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <phil(a)redhat.de>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
Motd: You're only jealous cos the little penguins are talking to me.
Hey guys, smolt is in a state now where it can be released and tested
by the general public. Currently smolt-firstboot has firstboot
integration with opt in/out. My question for the dev's is:
Do we as a community want to include this by default in Fedora 7?
For more information on smolt see:
Current stats can be found at:
You can have your machine send its stats by installing smolt with yum
and typing "smoltSendProfile"
*Note: this is not LHCP, which is going to be a much larger project.
Smolt has a much smaller scope and will ultimately (hopefully) be
replaced by LHCP when it is ready.