Hi,
I was looking through Bugzilla, and saw that USB ADSL support has been
"Assigned" (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109671)
. I continued to search for more data, but couldn't find anything. The
fedora-devel archives didn't help much either. Most posts were about
the Alcatel Speedtouch USB modem, but my interest lies elsewhere
(Aztech 500U)
Anyway, I was wondering what is the status of development? Is still it being
actively pursued?

Denis Leroy wrote:
>I've seen this happen when the screensaver is in random mode and
>occasionally launches a screensaver plugin that uses xorg hardware
>acceleration. If you have a poorly supported or misconfigured card, it
>might crash the kernel. Check your screensaver, try all available
>plugins...
>
>-d
>
>
It is the sceensaver, however everything is ok when it comes to
configuration, nothing changed except the updates and I never seen this
happen before. Also, the kernel doesn't crash, only X does.
Carlos Rodrigues
--
url: http://crodrigues.webhop.net

hp(a)redhat.com said:
> Dan Reed has some code written that's a bit simpler approach - it just
> rsyncs the homedir periodically.
This would work fine, at least for people with small /home directories,
and it has the distinct advantage that it can be done right now, without
a lot of development. It might be a problem for folks with larger /home
directories, though. On my laptop, I have about 20GB of user files
(images, maps, data, documents) and it takes a few minutes of disk
grinding for rsync just to walk the tree and decide what's changed.
This might be prohibitive (or at least prohibitively annoying) for the
user. It also cuts into the battery life.
Another possible user-space option would be something based on SGI::FAM.
Around here, I use a fam-based intrusion-detection system to monitor
a few system files that are commonly modified by root kits, and send
me a notice when one changes. A similar system could monitor the
directories in /home and, whenever a file changes, queue it up
for synchronization with a remote mirror. This has the advantage of
not needing to walk the whole file tree repeatedly, as you'd need
to do with rsync. I suspect that you might run into problems with
the number of file descriptors or memory use for large /home
directories, though. When I get a chance, I'll whip up a script
and try it out on my laptop.
Moving out of user space, and requiring some of development, you
could have the kernel's VFS layer generate a notice, maybe via DBUS,
whenever a file changes. It'd be nice to be able to turn this on only
for selected filesystems: monitor /home, but don't bother with
/var, for example. A client would watch for changes and queue up
files for synchronization.
Back to my original suggestion of a "RAID 1" mirror composed of
a local disk and a network block device: It seems like you'd need
to make the RAID system smart enough to realize that one device
has much bigger latencies than the other, otherwise you'd get
performance problems. You'd want to preferentially read from
the local disk, for example, and you'd want to queue up writes
to the remote disk instead of waiting for them to complete
synchronously. I don't know if the current software RAID
implementation supports this sort of thing.
Ideas are easy. Coding's hard. Thanks again for pulling together
a lot of disconnected useful ideas into "stateless linux" and
starting to instantiate them in code.
Bryan
--
===============================================================================
Bryan Wright |"If you take cranberries and stew them like
Physics Department | applesauce, they taste much more like prunes
University of Virginia | than rhubarb does." -- Groucho
Charlottesville, VA 22901 |
(434) 924-7218 | bryan(a)virginia.edu
===============================================================================

https://bugzilla.redhat.com/bugzilla/buglist.cgi?component=imap&component...
imap has been a total disaster in the past, and now we provide both
dovecot and cyrus-imapd as robust alternatives. Since FC2, imap was
stripped down to the "c-client" library with no server functionality.
The only reason we keep libc-client, the library portion of imap, is so
php-imap can build.
But why do we keep php-imap? NOTHING we ship uses it. squirrelmail
long ago decided php-imap was unreliable and made their own implementation.
Our forced attempts to get rid of imap in FC2 were done in a confusing
manner which remains both a support burden for us, and a huge point of
frustration to users. [1] To make matters worse, 'libc-client' is a
confusing name which is too similar to 'glibc', and meaningless to all
developers.
Is this really worth more years of headache? Here are two proposals to
deal with this.
Proposed Option #1: Rename libc-client to imap-libs
===================================================
Bug #120873 outlines a workable alternative where
* Package name is no longer misleading.
* Installed in such a way to not conflict in files or deps with imap.
* imap in Extras, completely unsupported by Red Hat.
Pros: Reduced support burden on us as we wont have many more stupid
reports [1] from foolish users complaining that we've taken away their
ability to use an insecure, buggy and slow mail server.
Cons: We still would have responsibility of php-imap, which very few
people use.
Proposed Option #2: Get rid of imap/libc-client completely
==========================================================
* Remove imap and libc-client from all future distributions.
* imap in Extras, completely unsupported by Red Hat.
Pros: No support burden for us.
Foolish users can use it if they really wish.
Cons: Difficult (but not impossible) to build php-imap
Not our problem. Extras can provide this.
I personally would much prefer Option #2 because it reduces the support
burden on Red Hat, for software that NONE of us care about. Any other
opinions?
Warren Togami
wtogami(a)redhat.com
[1]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132928
Some guy complains about imap conflicting with libc-client "for no reason".
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132933
The same guy realizes imap sucks, and says dovecot should Obsolete imap.
I point at Bug #120678 below as an example of why this is a bad idea.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120678
libc-client conflicts with cyrus-imapd (Earlier failed attempt to
forcefully remove imap)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123580
Confusion due to php-imap...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120873
Rename libc-client to imap-libs. This or removal of libc-client are our
best options.

On Thu, 2004-09-30 at 16:25, Enrico Scholz wrote:
> documentation and/or diagnostic. And btw... the nvidia driver are not
> supported by FC ;)
Not sure what you mean by "supported" but
NVIDIA-Linux-x86-1.0-5336-pkg1 works perfectly fine with FC2 for me...
--
Florin Malita <florin.malita(a)glenayre.com>

Hi,
Red Hat engineering is starting a new project we're calling
"stateless Linux" for lack of a better name - some components of this
are already in Rawhide, and others will be appearing shortly.
We've been keeping the project a little bit quiet at first, but now
we've written it up in some detail:
- an overview document, available from
http://people.redhat.com/~hp/stateless/
- a HOWTO document and a couple associated RPMs, available from
http://people.redhat.com/dmalcolm/stateless/
There aren't many new RPMs for this, because stateless Linux isn't a
single codebase or package, it's a set of changes across the
distribution (you might think of it as a "philosophy"). Most of the
changes are already in Rawhide (the highlights are mentioned in the
StatelessLinux.pdf document).
Appreciate feedback, especially from anyone who has time to try out
the HOWTO. We expect the code to change quite a bit as issues and
suggestions come in.
Havoc

As on 9/30 rawhide on system boot when switching to usermode I get:
Making Extra Nodes: cp: can't stat /etc/udev/devices/* no such directory
or files
on my box /etc/udev/devices is empty.
Also, selinux is blocking mlogd from doing anything. On shutdown I get a
bunch of audit messages blocking mlogd.

> i810 DRM not i810 AGP
>
> if you have a radeon card you don't need the i810 DRM driver
Yes I do have a radeon 7500 and I don't need the i810 driver. I have
done more investigating and found if I boot in init 3 and startx I have
direct rendering. If I boot directly into init 5 I have no direct
rendering. The radeon driver is loaded in both cases. Should I put in
bugzilla?
--Louis