I've started a new thread because this discussion was going to get lost
in the 200+ message thread-o-doom.
So so far we have the introduction of gnome-user-share, which uses an
http process dynamically bound to a port running as the user to share
stuff in a ~/Public file to the world w/out auth. It sounds like
gnome-user-auth will go into core. The restrictions have been put
* Functionality is provided by a package and removed by a package, w/out
* Functionality is controlled by a gconf entry which an admin can set to
mandatory off (or just remove the package)
Some ideas that have floated for this package include:
* Functionality disabled until a file is placed in ~/Public prompting
for a dialog box informing the user that the share is now active, with a
link to more help in this.
* Gnome-panel icon to show state of sharing with a timeout value to stop
the share (configurable)
* Integration with network-manager to enable/disable the share on
Jesse Keating RHCE (geek.j2solutions.net)
Fedora Legacy Team (www.fedoralegacy.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
>From kernel 1432 and 1433 in rawhide my boot process has some serious
delays where my system doesn't seem to do anything and doesn't respond.
This also happens when logining in and starting gnome.
I made a bootchart from the 1426 kernel which runs fine and one form
1433 which suffers from those delays.
Bart Vanbrabant <bart.vanbrabant(a)zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1
I want to install a minimal fedora from rawhide so I downloaded
boot.iso from ftp. Following the instructions, it began to retrieving
stage2.img. I install it on VMware (an evaluation copy), so I can see
the transfer status in the status bar. The transfer stopped after some
time, but the Anaconda installer is not started. I think this is
because our network is not so good, and the stage2.img is not
Can we have a daily built rescue CD which includes stage2.img? That
would make things easier. I have to install fedora 4 use its rescue
CD, because of the network issue above.
Besides this problem I also noticed that different boot.iso can only
match the exact version of stage2.img. I have to download it again and
again these days :( If debian users can install their systems using
any version of boot CD, why cannot we have one...
-----BEGIN PGP SIGNED MESSAGE-----
May I say that I completely agree with your appraisal of RH/Fedora.
Could I just add that there is one other issue of paramount importance:
The community still has no real leverage in change assurance. We do not
yet have access to CVS to apply patches ourselves, and despite things
being argued on lists etc, there is no control over veto, some of which
is explicit, but much of which is implicit in that no action is taken.
There is no recourse to arbitration in any case.
I do not doubt that RH's control of architectural integrity is not only
a good and necessary thing (indeed given the source of funding, it is
only right), but I am not at all convinced the correct balance has been
Unfortunately for us, this represents our greatest business risk.
Distributions such as Ubuntu, where third-party derivatives is a core
strategic component presently offer others much more influence in the
The Fedora community needs to address this because RPM is still the
packaging system par-excellence in my opinion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
I'd like to thank Dave and a few others for a good explanation of
the 4KSTACKS move. Anything that improves reliability for my server
apps is welcome.
I apologize for being less than tactful sometimes. If I'm critical
of RH, it's because I like Linux, Fedora and Red Hat and want to seem
them succeed. If I was commited to, say, Suse, FreeBSD or Open
Solaris, I'd be making waves on their mailing lists, not this one.
Some people are concerned that there's a lot of negative content on
this mailing list, and I think that's correct. We've seen arguments
that boil on for weeks without resolution. I think the problem,
however, is that there isn't a system in place to produce positive
propaganda for Linux and Fedora. Red Hat Magazine is pretty good:
is being updated less infrequently than it was and I wish that
had 3x has much content as it does. I went looking online for
information on 4KSTACKS, and by the limitations of current browsing and
searching interfaces, I found mostly people complaining about how
4KSTACKS broke this or that, and nothing that made it clear that
4KSTACKS has the real benefits that it does.
Fighting a headwind, some Sun employees write good documentation
for OpenSolaris in blog entries, such as
Sun's blog aggregator incorporates a lot of material that's off topic:
but if it had some editorial effort, I could see it becoming a good
system that combines documentation at the user level, kernel developer
level, and technical-friendly marketing in one place.
LKML is great, but it's like drinking from a firehose for people
who have other job responsibilities. There's a lot that can be done to
cure the impedance mismatch between the information that's available and
the information that linux admins need.
Finally, there is an impedance mismatch between Fedora and RHEL --
the connection between them is more intimate than a lot of people
admit. I had bad experiences with RHEL 3 on an x86 and had a lot of
skepticism about the direction RH was going when the Fedora project
started. We was so impressed with FC 3 that we chose RHEL 4 for an
x86_64 server we brought online. If it hadn't been for Fedora, we
might have switched to a different distribution or OS.
(And yes, it's really a miracle that FC and RHEL are as good as
they are on a platform as new as x86_64!)
With better marketing, ISVs might take Fedora a little more
seriously and start testing products on it. We knew well in advance
that RHEL 4 was going to be based on FC 3 and ISVs could have had better
products qualified for RHEL 4 faster if they'd done beta testing against
FC 3. Framing the Fedora discussion from a "half full" rather than
"half empty" perspective could help with this.
I am using kernel-2.6.12-1.1398_FC4.
I tryed to play doom3 with 5.1 Sound and got this Problem:
idAudioHardwareALSA::Write: 4096 frames overflowed and dropped
and hear no sound.
echo 1024 > /proc/sys/dev/rtc/max-user-freq
solves the problem.
Why is this default to 64?
Would (voluntary/realtime) preemt solve this issue too?
If yes why did voluntary preemt dissappeard from the FC kernels?
A few weeks ago we had a 4-way amd64 web server running RHEL 4 that
crashed sporadically -- nothing left in the syslog. up2date didn't find
a new kernel, so I just downloaded and installed the latest kernel from
kernel.org and the system has been stable ever since. I'm not sure if I
could have gone to RH for support because Cornell has a site license,
and even if I had a direct line to RH management, it would take me more
time to explain the problem than it would take to try a mainstream kernel.
Overall, I'm quite happy with the four-digit revision mainstream
linux kernels. We had a crash on our main machine that left a stack
trace, did some research on the web, found that this had been fixed in
2.6.11.something, upgraded the kernel, case closed.
People are willing to pay $$ to get an "enterprise" product which is
reliable, and supported, but this is another case where the generic
product turns out to be more reliable than the branded product, and
looking at what's happening with Fedora, I've got a lot of concern that
RH's pursuit of innovation will always lead to a kernel long on gee-whiz
features and short on reliability. Crashes mean I get calls from the
NOC at 4am, and god forbid that my toddler hears the phone ring or me
walking down the stairs, because I'll need to entertain him while
dealing with the crash and for the rest of the morning. Then a week
later I go to netcraft and they say my uptime is seven days and I feel
like a jerk because the whole world knows about my problems.
I think there are two reasons for the RHEL 4 instability: (i) the
quarterly release cycle means that I have to wait for bug fixes -- and
if you're running a non-x86 architecture, it seems like 2.6 is shaking
out bugs at a high rate, and (ii) RH is aggressively pushing new features.
I really don't know what's in RHEL 4 (it would take me more time to
look at the patches than it would to revert to mainstream) but the
activation of 4KSTACKS in Fedora is one of those changes that reduces
I've been looking, and I've never found out what benefit that
4KSTACKS has for end users. The kernel team is sensible, so I'm sure
that there are some real benefits, but looking at the problem reports
and at the attitudes of some people on this list, I start to wonder if
it's just a vindicitive attempt to put an end to ndiswrappers. (I'd
really love to see an explanation of the benefits of 4KSTACKS)
The real trouble is that 4KSTACKS problems aren't in kernel modules
per se, but really are in the combination of modules that are running.
Yeah, maybe they can get reiserfs running under 4KSTACKS, but what if
you're running an NFSv4 server with all the whizzy options turned on,
and IPv6 with tunneling and it's a reiserfs filesystem and you're using
LVM and RAID and a particularly funky SCSI driver, what then?
By adopting 4KSTACKS early, Fedora has helped shake out problems
with 4KSTACKS, but when 4KSTACKS becomes the main option in the
mainstream kernel, we'll see people dealing with weird problems that
happen sporadically on certain setups for years to come. We seem to
have one of the worst workloads in the world, and the last thing I need
is more crashes.
Can somebody please point me at a good resource for understanding how
exec-shield and memory randomization work?
Specifically, I'm trying to understand the randomize_va_space variable
Is randomize_va_space independent of /proc/sys/kernel/exec-shield? That
is, if I "echo 0 > /proc/sys/kernel/exec-shield", I would have thought
that would also turn off memory randomization, but that doesn't seem to
be the case. Are things supposed to work that way, or am I goofing
Finally, is there a way to disable randomization on a per-binary basis
(with an ELF flag or lack thereof)? I seem have a binary (sbcl) that
doesn't like memory randomization. Rather than turn it off globally, I'd
rather just mark the binary as incompatible with it.
Dave Roberts <ldave(a)droberts.com>
It's very quiet on this list about printing, so I thought it would be a
nice idea to put forward a proposal. I don't know if there are internal
redhat discussions about this subject, but I think I'll find out soon :).
It's a rahter lengthy explanation with a diagram so I put it up here: