Patrice Dumas <pertusus <at> free.fr> writes:
I am a small desktop user. For the display managers, there are wdm,
xdm and slim (but they lack integration with consolekit). For the
I think my KDM ConsoleKit patch should be fairly easy to adapt to any
XDM-derived display manager, as KDM is also derived from XDM. The only caveat
is that it includes GPL code derived from GDM, so it will make your display
manager GPLed, and you can't use it if its license isn't GPL-compatible.
(Luckily, the X11 license used in XDM is GPL-compatible.)
to package ivman for automounting, but it turned out to have too
much issues. I have developped halevt to replace ivman, but so far
nobody has packaged it (I don't want to maintain it in fedora since
I am upstream).
I think you should really maintain it in Fedora. Being upstream, you're the one
who knows it best, and you also actively use the package. Moreover, you're
already an experienced Fedora packager, so your case is different from the one
of upstream developers only wanting to get their software into Fedora which you
identify as a possible cause of conflicts of interest (but which IMHO isn't
necessarily bad either).
I'm the upstream maintainer of Quarticurve, the unofficial Qt 4 port of the
Bluecurve widget theme, and I maintain it in Fedora. The situation was much
like yours, Fedora is the first distribution to package it. And I think it's
working out well.
For openoffice, I haven't seen obvious replacements (I tried
to package Ted, but it is a nightmare).
KOffice maybe? Yes, it requires the kdelibs, but it's not anywhere near as
bloated as OO.o is.
If you can live without a full office suite, AbiWord and Gnumeric are also good
To replace firefox, there is dillo, but it lacks functionalities,
promising is links-hacked (I have a spec) or maybe links2.
Hmmm, maybe Konqueror? But then you'll be loading most of KDE into memory
anyway, so why not use KDE in the first place? ;-)
By the way, this isn't that wacky a question, people from KDE and GNOME have
analyzed memory requirements for different setups, and the lightweight WM setup
ended up requiring more memory once they started different apps, because they
all used different libraries or no libraries at all, whereas the full desktop
environments have most of their code shared across applications.