Re: Fedora Core 2 wishlists
by Michael Honeyfield
> > o lighter web server. Apache is too big for basic web services.
> > Candidates : mathopd, thttpd, boa, fnord, ...
>
> This gets my vote as well, with the qualification that the basic web
> server needs to be an option, not a replacement for Apache.
Could the monkey HTTP Daemon be a consideration. It is fairly light weight. I have not used it a great deal, but it covered my basic needs at the time.
http://monkeyd.sourceforge.net
Mike
20 years, 4 months
Re: yum update hell
by Samuel Flory
Neal D. Becker wrote:
> I can't run yum update anymore.
> yum update
> Gathering header information file(s) from server(s)
> Server: Red Hat Linux 1 (i386)
> Server: Fedora Linux / stable for Red Hat Linux 1 (i386)
> Server: Fedora Linux / testing for Red Hat Linux 1 (i386)
> Server: Red Hat Linux 1 (i386) updates
> Server: Fedora Compatible Packages (stable)
> Server: Fedora Compatible Packages (testing)
> Server: Fedora Compatible Packages (unstable)
> Server: Macromedia Flash Player for Red Hat Linux 1
> Finding updated packages
> Downloading needed headers
> Resolving dependencies
> .conflict between gpgme03-devel and gpgme-devel
> [root@rpppc1 nbecker]# rpm --erase gpgme03-devel
> [root@rpppc1 nbecker]# yum update
> Gathering header information file(s) from server(s)
> Server: Red Hat Linux 1 (i386)
> Server: Fedora Linux / stable for Red Hat Linux 1 (i386)
> Server: Fedora Linux / testing for Red Hat Linux 1 (i386)
> Server: Red Hat Linux 1 (i386) updates
> Server: Fedora Compatible Packages (stable)
> Server: Fedora Compatible Packages (testing)
> Server: Fedora Compatible Packages (unstable)
> Server: Macromedia Flash Player for Red Hat Linux 1
> Finding updated packages
> Downloading needed headers
> Resolving dependencies
> .....identical dependency loop exceeded
> package cryptplug needs gpgme = 0:0.3.15 (not provided)
> package cryptplug needs gpgme = 0:0.3.15 (not provided)
>
> Great, now what?
yum upgrade?
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <sflory(a)rackable.com>
20 years, 4 months
FC backup policy was Re: Fedora Core 2 wishlists
by Jef Spaleta
Jesse Keating wrote:
> I would like to see mondo rescue included
> (http://www.mondorescue.org)
> as well as it's tool chain (mindi, afio, buffer, lzo, lzop)
As I've said in other forums. I think any attempt at providing the
average user with an intuitive backup solution as a core feature is a
step in the right direction. In my mind, the second most important
admin policy(behind security issues like the firewall) someone has to
face when admining their own little box is a reasonable data backup
policy. I think it would be a mighty good thing for there to be a
reasonably intuitive backup tool in place in Fedora Core, to help
end-user hobbyists who are admining their own machines. Hell I'd even
go so far as telling people about it via
the graphical 'adverts' in the installer and then again when first boot
runs to encourage them to use the backup tool as soon as possible to
implement a backup scheme. Fedora Core of course can't
force people to follow good backup policy (nor security policy). But I
think there is room here to have Core suggest and encourage users to
think about backups by providing a reasonably intuitive way to interact
with a backup tool. Mondo stands on its own merits as a comprehensive
recovery solution for skilled users. But I would like to see some effort
made to have Fedora Core encourage even the mundane users to setup some
backup scheme, whether the tool of choice is Mondo or some other not so
obvious choice.
-jef
20 years, 4 months
rawhide report: 20031208 changes
by Build System
Updated Packages:
FreeWnn-1.11-40
---------------
* Thu Dec 04 2003 Jens Petersen <petersen(a)redhat.com> - 1.11-40
- apply FreeWnn-1.1.1-fix-x86-64-61907.patch (#61907) [Akira Tagoh]
- make shared library executable [Florian Laroche]
arts-1.1.94-0.1
---------------
* Mon Dec 01 2003 Than Ngo <than(a)redhat.com> 8:1.1.94-0.1
- KDE 3.2 beta2
cdrtools-2.01-0.a19.3
---------------------
* Mon Dec 08 2003 Harald Hoyer <harald(a)redhat.de> 8:2.01-0.a19.3
- added more ATAPI devices letters to scan #111603
dialog-0.9b-20031207.1
----------------------
* Mon Dec 08 2003 Harald Hoyer <harald(a)redhat.de> 0.9b-20031207.1
- version 20031207
rpmdb-fedora-1.90-0.20031208
----------------------------
20 years, 4 months
Re: Fedora Core 2 wishlists
by Michael Honeyfield
> Non US people get no image
> Everyone gets a segfault after they type a host ip and hit return.
>
> Looks like malloc handling errors, which make it a prime candidate IMHO
> to go away, because apps with malloc handling bugs that talk over networks
> dont make happiness
Well, if nobody minds, I will take a look.
Mike
20 years, 4 months
Re: FC backup policy was Re: Fedora Core 2 wishlists
by Keith Lofstrom
Jef Spaleta <jspaleta(a)princeton.edu> writes:
> I think it would be a mighty good thing for there to be a
> reasonably intuitive backup tool in place in Fedora Core, to help
> end-user hobbyists who are admining their own machines.
Ah, but the problem is, which tools? There are many ways to copy data;
there are the "make an archive" types like dump, tar, and (apparently)
mondo, and the "duplicate the image" types exemplified by rsync.
I use the latter, inside jwschultz's "dirvish" perl wrapper, and I am
very pleased with the resulting backups, less so with the documentation,
the metaphor, the recovery tools, etc. I have the logical equivalent
of 90 nightly copies of my complete 85GB network stored on two redundant
200GB hard drives (one live, one in the fireproof safe), and have
proven that I can restore from bare metal with a few minutes of typing
and 2 hours of unattended disk transfer. But! ... the interface is
*not* suitable for newbies. However, IT COULD BE! (for more info on
backups with dirvish, see http:// www.pegasys.ws/dirvish/ or my incomplete
newbie+ backup page at http://www.keithl.com/linuxbackup.html )
In the Wonderful World of the Future, the backup process would be designed
during the install partitioning process (backup strategy helps determine
partition strategy), and the file integrity checking process would be
designed during the package install process (I still use tripwire, but
would love a config process that is aware of rpm). These are all part
of the overall process of maintaining data integrity, one of the ways
Linux/Unix far surpasses the competition. It would be nice to develop
this position of strength to support the newbie user.
If we make backup and restore REALLY REALLY easy, then the whole idea of
trying new bleeding edge distros becomes much less risky. I can load a
rawhide distro, have it smash to bits, and be back to last night's FC1
status quo after a bit of typing and a trip to the movies. Makes
experimenting a lot more attractive. Among other things, it made
experimenting with Alan Cox's IDE hot swap (for the backup drives)
easier, which made backups easier, which made other experiments easier...
So, after all that, I agree with the eventual addition of backup tools
(and restore tools!) as part of an intuitive data integrity toolset for
Fedora Core. However, this will have to wait for the interfaces to
improve, the toolsets to become more complete, and for developers to
become cognizant of the amazing capabilities these toolsets can have.
Keith
--
Keith Lofstrom keithl(a)ieee.org Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
20 years, 4 months
Re: FC backup policy was Re: Fedora Core 2 wishlists
by Jef Spaleta
Ah look someone who hasn't learn not to engage me in long winded
and potentially flame filled rants....
Keith Lofstrom wrote:
> Ah, but the problem is, which tools? There are many ways to copy >
data;
I'm not looking for the perfect end-all-be-all backup solution.
There is of course room for highly flexible and highly configurable
backup solutions as well as something meant and design for the mundane
user. If they can be the same underlying toolset..fine..if not, oh well.
I'm concerned about offering a backup solution meant for the people
outside the 1% who know what they want as a backup solution. I'm
looking for something that can integrate well with the existing config
toolset...cough python cough...and aimed at the same audience.
> If we make backup and restore REALLY REALLY easy, then the whole
> idea of trying new bleeding edge distros becomes much less risky. > I
can load a rawhide distro, have it smash to bits, and be back to > last
night's FC1
Again I'm not looking for a really easy solution to let people
deliberately screw around with their systems and make it easy to
recover. There is a market for that assuredly, I'm looking for something
that provides some rudimentary and basic backup solution
that meets the needs 90% of the userbase and to work that solution into
a policy that the fedora core installation encourages as default effort
at backing up data. If there is a way to make the parition scheme aware
of backup partitions that would be just dandy...but the trade-offs of
trying to do that i would imagine are a high barrier for that feature.
And having had an offlist discussion already... i think i've been
convinced that rdiff-backup would be a good basis for the easybake
backup solution.
http://rdiff-backup.stanford.edu/
Why? its in python..that should make it very easy to integrate with the
existing system-config-* toolset that is in fedora....and perhaps
anaconda if there is a need. AND...little birdies tell me that someone
very clever is working on extending rdiff-backup to be
aware of which files are (un)modified and (un)managed by the rpmdb.
Think about that... why backup files locally that are owned by an rpm
package, when it would be just as easy to just reinstall the rpm.
http://naeblis.cx/blog/.
It's not a full system recovery image creation tool like mondo is, but i
personally think the backup to harddrive(possibly over a network) that
rdiff-backup provides would serve a majority the mundane users well
enough. Wrap a tree view based system-config-gui over it to select which
files are included/excluded from the cronjob run backup..and a similar
gui to do restores..you have a reasonable start at providing an
easy-bake solution to backuping data to a large harddrive parition
either on the lan or locally.
-jef
20 years, 4 months
Re: Fedora Core 2 wishlists
by Nils O. Selåsdal
On Mon, 2003-12-08 at 16:15, Michael K. Johnson wrote:
> http://fedora.redhat.com/participate/schedule/
>
> No dates set yet, but a driving goal or defining characteristic will
> be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
> long to arrive. That is, we'll shorten the schedule to accomodate an
> earlier release of the 2.6 kernel, but not lengthen it to accomodate
> a later release of the 2.6 kernel.
>
> 2.6 is looking good. There's a lot of integration work to do, though.
>
> However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> hear people's wishlists. Not everything will be possible, but it would
> be nice to have a good list from which to pick the possibilities, and
> from which to also pick ideas later for Fedora Core 3.
>
> FWIW, one thing that we're not likely to do is just push the schedule
> out by a week for project foo, another week for project bar, etc. ad
> nauseum.
>
A working,"intergrated" Fedora Extras.
A nice GUI for package management,updates,etc.
What about Blender ? Might be nice to have some 3D software in Fedora
Core.
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
w w w . u t e l s y s t e m s . c o m
20 years, 4 months
Re: Fedora Core 2 wishlists
by Michael Honeyfield
> - Fix or drop apps that just dont work in FC1. If they dont
> work and nobody fixed them then there isnt any point
> continuing to ship them (eg the terminal server client)
Whats broken here? Is tsclient the application you are refering too? I will happily pick this application up and maintian the package is needs be.
Mike
20 years, 4 months
my live cd: beta aviable ...
by Dirk Westfal
Hi,
i've put a first beta version of my cd together (and hopefully took care of
all trademarks and stuff :) :
- kernel 2.4.22-1.2115.nptl (lucky that this one has no logo ...)
- x/kde
- twm
- gdmlogin / most gnome-libs
- config tools
and much more (probably lot's of bugs also ...) .
Documentation (Readme, packagelist.) and download is at:
http://www.linux4all.de/distribution/fc1
The packages included are currently only the basic (kde) applications, and
they're mostly dependency clean (though lacking perl and some other things
to save space) - it's mostly a prove of principle...
Further software will almost surely require a cloop compressed image - this
one is uncompressed. (cloop currently mostly works fine until KDE comes
up... ).
Another thing: x - autoconfiguration may or may not work - something seems
different to redhat 9....
Since the standard fc kernel does not have devfs support, a fallback method
is provided (/dev into tmpfs) .
I think i remember that around redhat 7 devfs was aviable in redhat kernels.
If i'm right, does somebody know why it was thrown out ?
If you test it and you have bugreports/suggestions/improvements etc, please
drop me a line.
If you think it sucks, please let me know also.
(already expecting to get some heat ... )
so long,
Dirk Westfal
--
Dirk Westfal //Admin//RHCE/6.2//QB/DGQ
mailto: root[/livelinux](a)nwst.de
livecd based on Redhat 9.0 :
server / xkde + openmosix : www.nwst.de / www.linux4all.de
livecd based on Fedora CORE : (soon ;-)
20 years, 4 months
