Christopher Aillon <caillon <at> redhat.com> writes:
If your first reaction had been to ask for more information instead of add complaints, I might have mentioned that the plan is to have this for F9 (I think so at least, someone can correct me if I'm wrong?). Not sure if that counts as long term...
Even if somebody implements a KDE frontend for the GDM backend, that won't make KDM go away. There's no way KDM is going away for KDE 4.0 which realistically will be what F9 will be shipping. (And of course, it's even less likely that said thing would happen in 3.5. Chances that KDE 4.1 will be anywhere near ready at F9 release are essentially nil, 4.1 might quite possibly not even make F10.)
It is a reasonable request. Can you accept reasonable answers? Notting and jkeating have already replied with technical analysis explaining why it is not possible.
I have suggested at least 2 technical solutions, none of which needs any changes to Anaconda: 1. revert the default login manager in Base X to XDM. As much as you (plural "you") hate that, it's the most logical solution and some other people in this thread are defending it too. 2. change the fallback logic to pick KDM over GDM. As I said, I think we can easily put KDM in a subpackage so it doesn't accidentally get installed by a dependency on kdebase, kde-redhat used to do that in FC6 times.
There's another one, which is even less invasive (and doesn't change the behavior for the neither-GNOME-nor-KDE case as 1. nor for the both-GNOME-and-KDE case as 2., but really only affects KDE-but-not-GNOME which is what needs fixing), but has to be implemented as a specialized Anaconda hack. Pseudocode: if (! upgrade && KDE selected && ! GNOME selected) echo 'DISPLAYMANAGER="KDE"' >/mnt/sysimage/etc/sysconfig/desktop
Besides, we already know it's not going to happen for F8. And F9 we could in theory have a better all around solution....
"better" is subjective. If upstream KDE isn't going to drop KDM or recommend against it, IMHO that fact shouldn't be ignored.
Kevin Kofler
On Wed, 31 Oct 2007 18:49:55 +0000 (UTC) Kevin Kofler kevin.kofler@chello.at wrote:
I have suggested at least 2 technical solutions, none of which needs any changes to Anaconda:
- revert the default login manager in Base X to XDM. As much as you
(plural "you") hate that, it's the most logical solution and some other people in this thread are defending it too. 2. change the fallback logic to pick KDM over GDM. As I said, I think we can easily put KDM in a subpackage so it doesn't accidentally get installed by a dependency on kdebase, kde-redhat used to do that in FC6 times.
Both of these changes take time to do, and time to recompose trees to make the release out of, and likely would lead to a slip of the Fedora 8 release.
On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
I have suggested at least 2 technical solutions, none of which needs any changes to Anaconda:
May add one more possible solution: what about dropping Base X group from anaconda altogether and why not to treat it as a library, which is required by another components (do we have a group for glibc)?
By reading the most of the previous messages (and there was a lot of them), it seems to me that actually nobody wants „Base X“ group for its own sake. Either there are people who want „Plain old X as seen in Project Athena many years ago“ (BTW, Project Athena @ MIT switched to Gnome as default) or some lightweight window manager (which one?). IMHO, the answer to the first request is that whoever wants it is such a weirdo, that he should be required to install appropriate packages just via yum (maybe with package xorg-x11-plain-old-environment or something) and doesn't deserve a place in anaconda.
The other group is much more interesting. I really don't like a tendency of Fedora moving with its system requirements somewhere close to the one of Windows Vista (yes, we would have to fix anaconda first, but that's another issue, let's keep this X specific). It would be nice if people who are interested in this created some group of packages (with their own desktop manager? -- is there anything else than [gkx]dm?) so that we could fourth environment (even though this would be probably very virtual not consisting from packages originally intended to be part of one environment) besides Gnome, KDE, and XFCE. Are there any friends of WindowMaker around here (that would be nice for higher degree of compatibility with Mac OS X)? Or IceWM?
On xdm theme -- if anybody is interested in this; well, xorg-x11-xdm src.rpm is 400k -- it shouldn't be unfathomable for interested geek to fix it and maintain it (and I would be glad to meet you, because xdm bugs in bugzilla are always for me, desktop team bugmaster, kind of nightmare).
What do you think?
Matěj
On Mon, Nov 05, 2007 at 12:32:40AM +0100, Matej Cepl wrote:
On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
I have suggested at least 2 technical solutions, none of which needs any changes to Anaconda:
part of one environment) besides Gnome, KDE, and XFCE. Are there any friends of WindowMaker around here (that would be nice for higher degree of compatibility with Mac OS X)? Or IceWM?
I am a small desktop user. For the display managers, there are wdm, xdm and slim (but they lack integration with consolekit). For the desktop (in fact window managers), fvwm, fluxbox, icewm, WindowMaker pekwm and other I forgot about. Among the file managers, there is gentoo (although it should be better inegrated with xdg-open use), and rox-filer could be packaged (I have a spec). I wanted 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). There are many dockaps packaged, but more wouldn't hurt. For openoffice, I haven't seen obvious replacements (I tried to package Ted, but it is a nightmare). To replace firefox, there is dillo, but it lacks functionalities, more promising is links-hacked (I have a spec) or maybe links2. Last xpdf/gv are much lighter than evince.
So there are many pieces in place, but still some lacking parts or missing features. In any case, I don't think that a comps group would be useful for 3 reasons: * there is a lot of diversity, * this sets of packages are more geared toward power users, * minimal usable set is very small (a display manager, a window manager)
On xdm theme -- if anybody is interested in this; well, xorg-x11-xdm src.rpm is 400k -- it shouldn't be unfathomable for interested geek to fix it and maintain it (and I would be glad to meet you, because xdm bugs in bugzilla are always for me, desktop team bugmaster, kind of nightmare).
What do you think?
I could look at the packaging part (in some future, though), but not at the code.
-- Pat
Patrice Dumas wrote: 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 don't understand that logic. Why wouldn't you want to maintain it in Fedora just because you are upstream?
Rahul
On Mon, Nov 05, 2007 at 07:31:20AM +0530, Rahul Sundaram wrote:
Patrice Dumas wrote: 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 don't understand that logic. Why wouldn't you want to maintain it in Fedora just because you are upstream?
Because I think that being upstream and the primary maintainer of a package in fedora (or any distro) is not a very good idea. If there are conflict of interest between upstream and the distro (think about name space, install paths, quality), I think that having a maintainer who is not the primary upstream maintainer is a good thing. Having upstream co-maintain, or even do the packaging work is a good idea, but I think that upstream should not have the last saying for the package.
-- Pat
On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
Because I think that being upstream and the primary maintainer of a package in fedora (or any distro) is not a very good idea. If there are conflict of interest between upstream and the distro (think about name space, install paths, quality), I think that having a maintainer who is not the primary upstream maintainer is a good thing. Having upstream co-maintain, or even do the packaging work is a good idea, but I think that upstream should not have the last saying for the package.
Well, I would be bothered with stuff like this for some huge packages (OOo), but I don't think (with all due respect to your utility) one reasonable guy should IMHO be able to keep two hats on his head. And you wouldn't be the first one (by far).
Matěj
On Mon, Nov 05, 2007 at 10:44:05AM +0100, Matej Cepl wrote:
On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
Because I think that being upstream and the primary maintainer of a package in fedora (or any distro) is not a very good idea. If there are conflict of interest between upstream and the distro (think about name space, install paths, quality), I think that having a maintainer who is not the primary upstream maintainer is a good thing. Having upstream co-maintain, or even do the packaging work is a good idea, but I think that upstream should not have the last saying for the package.
Well, I would be bothered with stuff like this for some huge packages (OOo), but I don't think (with all due respect to your utility) one reasonable guy should IMHO be able to keep two hats on his head. And you wouldn't be the first one (by far).
I have seen a lot of reviews where this issue shows up, upstream being willing to put an app in fedora, but not for fedora, in order to gain a wider audience. Those conflicts were easily seen. I don't want to be in that situation. If my app is good enough somebody else will package it (and I will gladly review it).
-- Pat
On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
Because I think that being upstream and the primary maintainer of a package in fedora (or any distro) is not a very good idea. If there are conflict of interest between upstream and the distro (think about name space, install paths, quality), I think that having a maintainer who is not the primary upstream maintainer is a good thing. Having upstream co-maintain, or even do the packaging work is a good idea, but I think that upstream should not have the last saying for the package.
Well, I would be bothered with stuff like this for some huge packages (OOo), but I don't think (with all due respect to your utility) one reasonable guy should IMHO be able to keep two hats on his head. And you wouldn't be the first one (by far).
I maintain two (I think) packages for which I am upstream. I suspect I wasn't the first, either.
MatÄj
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Mon, Nov 05, 2007 at 07:08:36AM -0600, Jon Ciesla wrote:
I maintain two (I think) packages for which I am upstream. I suspect I wasn't the first, either.
No, you are not the first since when I said in the past that it was not a good idea to be primary maintainer in fedora and upstream several people already said they were and some other people also said that it was fine to be upstream and primary maintainer in fedora. In any case this is primarily my opinion, not anything official, and I will happily review a package whose upstream is submitting to fedora. Since I disagree with this practice, however, I will avoid to do it myself.
-- Pat
On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
Because I think that being upstream and the primary maintainer of a package in fedora (or any distro) is not a very good idea.
Moreover, you hope that your utility will be used by other distros, right? Then you will get peer review and feedback from your package maintaining colleagues.
Matěj
On Mon, Nov 05, 2007 at 10:45:14AM +0100, Matej Cepl wrote:
On Mon, 05 Nov 2007 10:26:36 +0100, Patrice Dumas scripst:
Because I think that being upstream and the primary maintainer of a package in fedora (or any distro) is not a very good idea.
Moreover, you hope that your utility will be used by other distros, right? Then you will get peer review and feedback from your package maintaining colleagues.
Not if they don't contact me, and this doesn't change the issue. Conflict of interest are better ruled if the last word is for the distro. And so far halevt is not in any distro (that I know of). It was proposed to debian but the submitter withdrawed his submission.
I have seen signs that show that a few people (at least 2) use it.
-- Pat
On Mon, 05 Nov 2007 02:02:39 +0100, Patrice Dumas scripst:
I am a small desktop user. For the display managers, there are wdm, xdm and slim (but they lack integration with consolekit).
davidz? How complicated is to fix that? Does {wdm,slim} use PAM?
For the desktop (in fact window managers), fvwm, fluxbox, icewm, WindowMaker pekwm and other I forgot about.
I would suspect, that here is the answer -- just pick one (although WindowMaker means much more than just a window manager, I guess).
(I don't want to maintain it in fedora since I am upstream).
As other people noted already, this in itself is not the reason. You may be swamped in other work too much anyway, so you won't bother with Fedora clueless users, but there are many upstream maintainers/authors who maintain their packages in Fedora as well.
For openoffice, I haven't seen obvious replacements
I think, just don't go there -- although KOffice friends will hate me for saying this, if you need compatibility with MS Office or full-blown office suite, you need OO.o. Period. Others are just not there (yet?).
And of course, when you say OO.o, don't say "lightweight" in the same sentence, or you will be laughed out. I guess that for now, people using your virtual DE will have to settle on Google Apps or something of that sort. I know, Google Apps are not free, but for now (until some free web apps will develop?), it is used I guess by people who don't use full- blown office suite anyway.
To replace firefox, there is dillo, but it lacks functionalities, more promising is links-hacked (I have a spec) or maybe links2.
Actually, I think firefox is probably bigger problem than Openoffice.org. If you want to use Google Apps as your "producitivty applicationis" (or whateever is the current buzzword for this kind of programs) then probably things like links are not good enough. Is there anything from http://en.wikipedia.org/wiki/List_of_web_browsers#Gecko-based_browsers or http://en.wikipedia.org/wiki/List_of_web_browsers#KHTML_and_WebKit- based_browsers which would be useful for you? Just from browsing Wikipedia, Atlantis http://www.akcaagac.com/index_atlantis.html looks pretty nice. I don't know how good its Javascript/AJAX support is though.
So there are many pieces in place, but still some lacking parts or missing features. In any case, I don't think that a comps group would be useful for 3 reasons:
Certainly not now, until dust settles a little bit on your ideas. But then it could be a good place to organize and coordinate the effort, and tool to promote and organize community developing the DE.
However, one more question came to my mind while thinking about this post -- "Why not XFCE"? We already have something marked as a lightweight environment. Why not to join their effort?
- there is a lot of diversity,
that shouldn't be problem -- just follow your heart and be open to change the groups whenever you are persuaded that you made a mistake. It's better to have one real thing, than a mess lightweight environment is now.
- this sets of packages are more geared toward power users,
And? Why only newbies should have a toolbox ready to use?
- minimal usable set is very small (a display manager, a window manager)
I am not sure about it. You just have to look wider I suppose.
Best,
Matěj
On Mon, Nov 05, 2007 at 10:08:59AM +0100, Matej Cepl wrote:
On Mon, 05 Nov 2007 02:02:39 +0100, Patrice Dumas scripst:
I am a small desktop user. For the display managers, there are wdm, xdm and slim (but they lack integration with consolekit).
davidz? How complicated is to fix that? Does {wdm,slim} use PAM?
Yes they use pam. They just need to pass the right pam environment variables to pam_ck_connector, but lately I have seen the following in the consolekit changelog: * Add new helper for getting tty from DISPLAY (William Jon McCann) so I was hoping everything could be automatic, I asked for an explanation on the hal list, and directly to David, so far no answer.
For the desktop (in fact window managers), fvwm, fluxbox, icewm, WindowMaker pekwm and other I forgot about.
I would suspect, that here is the answer -- just pick one (although WindowMaker means much more than just a window manager, I guess).
What else?
(I don't want to maintain it in fedora since I am upstream).
As other people noted already, this in itself is not the reason. You may be swamped in other work too much anyway, so you won't bother with Fedora clueless users, but there are many upstream maintainers/authors who maintain their packages in Fedora as well.
See my answer to Rahul for why I find it bad.
For openoffice, I haven't seen obvious replacements
I think, just don't go there -- although KOffice friends will hate me for saying this, if you need compatibility with MS Office or full-blown office suite, you need OO.o. Period. Others are just not there (yet?).
I know.
And of course, when you say OO.o, don't say "lightweight" in the same sentence, or you will be laughed out. I guess that for now, people using your virtual DE will have to settle on Google Apps or something of that sort. I know, Google Apps are not free, but for now (until some free web apps will develop?), it is used I guess by people who don't use full- blown office suite anyway.
I don't think that it is a real replacement. Since it is server-side you have to have internet, trust the server... But indeed it can be of help.
To replace firefox, there is dillo, but it lacks functionalities, more promising is links-hacked (I have a spec) or maybe links2.
Actually, I think firefox is probably bigger problem than Openoffice.org. If you want to use Google Apps as your "producitivty applicationis" (or whateever is the current buzzword for this kind of programs) then probably things like links are not good enough. Is there anything from
Indeed. It may be for browsing with simple javascript (there is currently no css suppport).
http://en.wikipedia.org/wiki/List_of_web_browsers#Gecko-based_browsers or http://en.wikipedia.org/wiki/List_of_web_browsers#KHTML_and_WebKit- based_browsers which would be useful for you? Just from browsing Wikipedia, Atlantis http://www.akcaagac.com/index_atlantis.html looks pretty nice. I don't know how good its Javascript/AJAX support is though.
Indeed, looks cool. Seems that WebCore has javascript support.
So there are many pieces in place, but still some lacking parts or missing features. In any case, I don't think that a comps group would be useful for 3 reasons:
Certainly not now, until dust settles a little bit on your ideas. But then it could be a good place to organize and coordinate the effort, and tool to promote and organize community developing the DE.
I don't think that dust will settle. The desktop is a moving target, with kde/gnome/xfce ruling freedesktop and having resources put by vendors in these efforts (redhat is a good example of a company pushing the desktop innovations which also means breaking existing apps). So things change a lot (fonts, handling, hal/ConsoleKit, utf8), while there is no resources (that is paid developpers) put for light DE. I also think that light DE developers may be reluctant to add new features (only a guess, though). As a result light DE will always be catching up, with doing things as root needed, ugly workaround for things to work. To put things clearly before somebody misinterpret my words, I am not complaining about those breakages. But they happen a lot and big desktop developpers don't care about compatibility with existing stuff or helping light DE to have backward compatibility -- still not a complaint, but a remark.
However, one more question came to my mind while thinking about this post -- "Why not XFCE"? We already have something marked as a lightweight environment. Why not to join their effort?
I help with xfce packaging when I can (I reviewed thunar, for example, and see ristretto review). And xfce related applications are light, in general (thunar, for example is a lightweight file manager). I used xfce in the past (fedora 3, maybe 4?) but then it became to take time to launch, and then I switched to fluxbox.
- there is a lot of diversity,
that shouldn't be problem -- just follow your heart and be open to change the groups whenever you are persuaded that you made a mistake. It's better to have one real thing, than a mess lightweight environment is now.
Right.
- this sets of packages are more geared toward power users,
And? Why only newbies should have a toolbox ready to use?
Power usres knwo what to install and have precise choices, so a group won't be of much use for them. It would be interesting for newbies who want something light. But also a trap for them, they'll have to mount manually their usb sticks as root by looking at the bottom of dmesg...
- minimal usable set is very small (a display manager, a window manager)
I am not sure about it. You just have to look wider I suppose.
Nothing more is necessary for lightweight DE. Of course there are lots of apps that can be optional but are suited for lightweight DE (dockapps, gmrun, xdvi, xfig, conky, gv and many others...).
-- Pat
On 2007-11-05, 09:59 GMT, Patrice Dumas wrote:
I would suspect, that here is the answer -- just pick one (although WindowMaker means much more than just a window manager, I guess).
What else?
Well, it's confusing (at least for me) to distinguish between WindowMaker and GNUStep -- at least in Debian (which I used before coming to RedHat) WM tend to develop a list of wm-* packages almost as long as g* and k* packages. I am not sure which one of them would qualify as parts of GNUStep and which ones are just addons on WM, but there are plenty of them all over the place.
Indeed, looks cool. Seems that WebCore has javascript support.
Sure it has -- and konqueror (using KJS which is what WebCore JS support is based upon) works with GMail, AFAIK.
I don't think that dust will settle. The desktop is a moving target, with kde/gnome/xfce ruling freedesktop and having resources put by vendors in these efforts (redhat is a good example of a company pushing the desktop innovations which also means breaking existing apps).
Well, then probably point is to keep the list packages in DE just as long as you and people who will be on it with you will be able to maintain. Moreover, it seems to me that (under the influence of server guys, I think) many core changes in Fedora (thinking pulseaudio, policykit, packagekit, and hopefully now even NetworkManager) will be much more open to non-{Gnome,KDE} environments.
I used xfce in the past (fedora 3, maybe 4?) but then it became to take time to launch, and then I switched to fluxbox.
Jus to make sure, that I understand -- you claim, that XFCE is not as lightweight as it used to be, or in other words, that their effort to build lightweight equivalent of Gnome failed?
- minimal usable set is very small (a display manager,
a window manager)
I am not sure about it. You just have to look wider I suppose.
Nothing more is necessary for lightweight DE. Of course there are lots of apps that can be optional but are suited for lightweight DE (dockapps, gmrun, xdvi, xfig, conky, gv and many others...).
I don't know -- would you allow some email client, for example (I heard a lot of good things about Sylpheed in this respect) or do you expect most of the apps to be console ones running in xterm/rxvt/whatever?
Matěj
On Mon, Nov 05, 2007 at 01:01:13PM +0100, Matej Cepl wrote:
On 2007-11-05, 09:59 GMT, Patrice Dumas wrote:
Well, it's confusing (at least for me) to distinguish between WindowMaker and GNUStep -- at least in Debian (which I used before coming to RedHat) WM tend to develop a list of wm-* packages almost as long as g* and k* packages. I am not sure
Ok, I don't know about that. Maybe a relevant comps group could be something like gnustep desktop.
I don't think that dust will settle. The desktop is a moving target, with kde/gnome/xfce ruling freedesktop and having resources put by vendors in these efforts (redhat is a good example of a company pushing the desktop innovations which also means breaking existing apps).
Well, then probably point is to keep the list packages in DE just as long as you and people who will be on it with you will be able to maintain. Moreover, it seems to me that (under the influence of server guys, I think) many core changes in Fedora (thinking pulseaudio, policykit, packagekit, and hopefully now even NetworkManager) will be much more open to non-{Gnome,KDE} environments.
I hope that too, but currently this is not the trend I am seeing. That is the server/light DE will catch up, but then there will be a newer breaking.
I used xfce in the past (fedora 3, maybe 4?) but then it became to take time to launch, and then I switched to fluxbox.
Jus to make sure, that I understand -- you claim, that XFCE is not as lightweight as it used to be, or in other words, that their effort to build lightweight equivalent of Gnome failed?
It is much lighter than gnome, but heavier than fluxbox.
Nothing more is necessary for lightweight DE. Of course there are lots of apps that can be optional but are suited for lightweight DE (dockapps, gmrun, xdvi, xfig, conky, gv and many others...).
I don't know -- would you allow some email client, for example (I heard a lot of good things about Sylpheed in this respect) or do you expect most of the apps to be console ones running in xterm/rxvt/whatever?
sylpheed seems to have a good record, but I personally use mutt.
Maybe what could be more interesting than a comps group which doesn't seems to fit very well in my opinion, because of the diversity and optionality, a spin with the most used light apps could be done. I dream of that since a lot of time, but I don't think it is worth it as long as the integration isn't good enough. Moreover I am not persuaded that it would be useful, even though it should be fun.
-- Pat
On 2007-11-05, 09:59 GMT, Patrice Dumas wrote:
Atlantis http://www.akcaagac.com/index_atlantis.html looks pretty nice. I don't know how good its Javascript/AJAX support is though.
Indeed, looks cool. Seems that WebCore has javascript support.
It seems like being non-free research/education project. I wonder if maintainer could be persuaded to relicense under some open source license when somebody from big distr would take an interest.
Matěj
Matej Cepl <mcepl <at> redhat.com> writes:
Wikipedia, Atlantis http://www.akcaagac.com/index_atlantis.html looks pretty nice. I don't know how good its Javascript/AJAX support is though.
Unfortunately, Atlantis is not Free Software.
Kevin Kofler
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 options.
To replace firefox, there is dillo, but it lacks functionalities, more 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.
Kevin Kofler
On Tue, Nov 06, 2007 at 07:10:53PM +0000, Kevin Kofler wrote:
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.)
Why don't you use libck-connector.so or even simplier pam_ck_connector?
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
I am ready to comaintain the package, and as I already said, even do all the work of packaging. But a maintainer in fedora should be there to have the final word.
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).
Conflict of interest may arise after the import.
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 options.
Indeed, it is much less heavy than OO.
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.
I could have a look, but I doubt a lot that in my use case it is true.
It would mean that some xterms, some with vi + xpdf + firefox + mutt + fluxbox consumes more memory than some gterm + gedit + evince + firefox + evolution (or maybe something lighter I don't know) + gnome
I can check, but I doubt so much. Do you want that I check, and in that case do you have an explanation on how to measure the footprints?
-- Pat
Patrice Dumas <pertusus <at> free.fr> writes:
Why don't you use libck-connector.so or even simplier pam_ck_connector?
I looked at how GDM does things, found their code fairly easy to port to KDM and did just that.
I can check, but I doubt so much. Do you want that I check, and in that case do you have an explanation on how to measure the footprints?
Tracking down the original articles might be a good starting point. Here's the memory benchmark Luboš Luňák from KDE has made in 2006: http://ktown.kde.org/~seli/memory/desktop_benchmark.html I know there have been earlier measurements done, also by the GNOME developers. Maybe there's also newer ones.
Kevin Kofler
On Tue, Nov 06, 2007 at 07:10:53PM +0000, Kevin Kofler wrote:
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
I have looked at both and, even though maybe kdm is derived from xdm they have diverged too much. Using libck-connector allows to achieve what the kdm consolekit does, however. And there is an equivalent of d->serverVT in xdm which would allow to set the X display device like
sprintf(device, "/dev/tty%d", d->serverVT);
However doing things like that seems very odd and non portable to me. In fact there is no reason why the display manager would know the X display device since X is all about hiding the hardware. I am currently discussing that with the xdm upstream maintainer, did you contact the kde upstream for the patch inclusion?
-- Pat
On Thu, 2008-01-10 at 19:43 +0100, Patrice Dumas wrote:
On Tue, Nov 06, 2007 at 07:10:53PM +0000, Kevin Kofler wrote:
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
I have looked at both and, even though maybe kdm is derived from xdm they have diverged too much. Using libck-connector allows to achieve what the kdm consolekit does, however. And there is an equivalent of d->serverVT in xdm which would allow to set the X display device like
sprintf(device, "/dev/tty%d", d->serverVT);
Eew. Don't do it that way.
atropine:~% xprop -root | grep VT XFree86_VT(INTEGER) = 7
- ajax
On Thu, Jan 10, 2008 at 02:29:00PM -0500, Adam Jackson wrote:
On Thu, 2008-01-10 at 19:43 +0100, Patrice Dumas wrote:
Eew. Don't do it that way.
atropine:~% xprop -root | grep VT XFree86_VT(INTEGER) = 7
And the device? How can it be obtained from the X server?
-- Pat
On Thu, Jan 10, 2008 at 02:29:00PM -0500, Adam Jackson wrote:
Eew. Don't do it that way.
atropine:~% xprop -root | grep VT XFree86_VT(INTEGER) = 7
Also looking at the xdm code, looks like it does about that: prop = XInternAtom(d->dpy, "XFree86_VT", False); XGetWindowProperty(d->dpy, DefaultRootWindow(d->dpy), prop, 0, 1, False, AnyPropertyType, &actualtype, &actualformat, &nitems, &bytes_after, &buf)
-- Pat
Patrice Dumas <pertusus <at> free.fr> writes:
device since X is all about hiding the hardware. I am currently discussing that with the xdm upstream maintainer, did you contact the kde upstream for the patch inclusion?
Yes: http://bugs.kde.org/show_bug.cgi?id=147790
The KDM maintainer rejected it. :-( For pretty unconvincing reasons at that: he doesn't agree with the design (but it's the one which is advocated by the ConsoleKit developers and which would allow implementing true fast user switching in KDM later) and he doesn't want GPL (as opposed to X11-licensed) code in the KDM backend (which makes no sense because the frontend is already GPL and because merges back to XDM aren't going to happen anyway, because as you said, the code has diverged a lot). (Part of the code is GPL because it's derived from the GDM implementation.)
That said, several other distributions picked it up, for example in OpenSUSE, it was applied to their packages by none other than Dirk Müller, the upstream KDE release manager.
Kevin Kofler
On 01/10/2008 09:57 PM, Kevin Kofler wrote:
Patrice Dumas <pertusus <at> free.fr> writes:
device since X is all about hiding the hardware. I am currently discussing that with the xdm upstream maintainer, did you contact the kde upstream for the patch inclusion?
Yes: http://bugs.kde.org/show_bug.cgi?id=147790
The KDM maintainer rejected it. :-( For pretty unconvincing reasons at that: he doesn't agree with the design (but it's the one which is advocated by the ConsoleKit developers and which would allow implementing true fast user switching in KDM later) and he doesn't want GPL (as opposed to X11-licensed) code in the KDM backend (which makes no sense because the frontend is already GPL and because merges back to XDM aren't going to happen anyway, because as you said, the code has diverged a lot). (Part of the code is GPL because it's derived from the GDM implementation.)
That said, several other distributions picked it up, for example in OpenSUSE, it was applied to their packages by none other than Dirk Müller, the upstream KDE release manager.
This makes me feel all warm and tingly about KDE...
On Thu, Jan 10, 2008 at 08:57:07PM +0000, Kevin Kofler wrote:
Patrice Dumas <pertusus <at> free.fr> writes:
device since X is all about hiding the hardware. I am currently discussing that with the xdm upstream maintainer, did you contact the kde upstream for the patch inclusion?
Yes: http://bugs.kde.org/show_bug.cgi?id=147790
The KDM maintainer rejected it. :-( For pretty unconvincing reasons at that: he doesn't agree with the design (but it's the one which is advocated by the ConsoleKit developers and which would allow implementing true fast user switching in KDM later) and he doesn't want GPL (as opposed to X11-licensed) code in the KDM backend (which makes no sense because the frontend is already GPL and because merges back to XDM aren't going to happen anyway, because as you said, the code has diverged a lot). (Part of the code is GPL because it's derived from the GDM implementation.)
I think he is right on one point, libck-connector should be used instead of picking the gdm code, it is under the MIT, and it is better to use a lib to reuse code instead of cut and paste. gdm should certainly also use libck-connector.
-- Pat
On Mon, 05 Nov 2007 00:32:40 +0100 Matej Cepl mcepl@redhat.com wrote:
May add one more possible solution: what about dropping Base X group from anaconda altogether and why not to treat it as a library, which is required by another components (do we have a group for glibc)?
You can get the X libraries and not have an X server. You can do an install with gnome/kde that is set up to be used remotely on other X servers, without actually installing a local X server. The Base X group is the group that adds a local X server (and all the appropriate fonts/drivers/etc...) so that X can be used locally on the system.
On Sun, 04 Nov 2007 20:59:44 -0500, Jesse Keating scripst:
You can get the X libraries and not have an X server. You can do an install with gnome/kde that is set up to be used remotely on other X servers, without actually installing a local X server. The Base X group is the group that adds a local X server (and all the appropriate fonts/drivers/etc...) so that X can be used locally on the system.
And both of these are probably such corner cases, that I would gladly not bother 95% of all users of anaconda with them (causing confusion about xdm among other things). Whoever wants them, will have to fiddle with the configuration manually so much anyway, that one more 'yum install' probably won't hurt.
Fedora -- All my bits are free, are yours?
Ehmm, although I suspect I know the answer, I cannot resist -- swfdec or gnash? ;-)
Matěj
On Mon, 2007-11-05 at 00:32 +0100, Matej Cepl wrote:
On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
I have suggested at least 2 technical solutions, none of which needs any changes to Anaconda:
May add one more possible solution: what about dropping Base X group from anaconda altogether and why not to treat it as a library, which is required by another components (do we have a group for glibc)?
The major problem with this is there's almost nothing in the distro that requires the X server itself at the rpm level. The various X drivers do, but nothing requires them besides the xorg-x11-drivers metapackage. rhpxl and compiz require Xorg, but it's quite possible to want a system without them, so you don't want to have just those two be responsible for pulling in the X server.
The base-x group in comps is actually pretty minimal on its own. I'd be happy with trimming it down to the bare minimum, marking it non-visible, and having the various desktop groups depend on it (in comps, not in their packaging).
Of course this is predicated on comps having a groupreq mechanism, which it doesn't.
The other group is much more interesting. I really don't like a tendency of Fedora moving with its system requirements somewhere close to the one of Windows Vista (yes, we would have to fix anaconda first, but that's another issue, let's keep this X specific). It would be nice if people who are interested in this created some group of packages (with their own desktop manager? -- is there anything else than [gkx]dm?) so that we could fourth environment (even though this would be probably very virtual not consisting from packages originally intended to be part of one environment) besides Gnome, KDE, and XFCE. Are there any friends of WindowMaker around here (that would be nice for higher degree of compatibility with Mac OS X)? Or IceWM?
I would say something here about senseless duplication of effort, but it's not likely to convince anybody.
That said, if someone wanted to have a WindowMaker Desktop group in comps, that'd be fine; it should depend on base-x though.
On xdm theme -- if anybody is interested in this; well, xorg-x11-xdm src.rpm is 400k -- it shouldn't be unfathomable for interested geek to fix it and maintain it (and I would be glad to meet you, because xdm bugs in bugzilla are always for me, desktop team bugmaster, kind of nightmare).
Please, just pretend xdm doesn't exist.
I wish we had a way to mark packages as actively deprecated. I don't want to orphan xdm, I want that no one work on it ever again.
- ajax
On Mon, Nov 05, 2007 at 09:21:35AM -0500, Adam Jackson wrote:
I would say something here about senseless duplication of effort, but it's not likely to convince anybody.
I guess that I am bised, but it seems to me that, at least, fvwm, fluxbox and icewm are not duplicate, and don't duplicate xfce/gnome/kde either. And dockapps based desktop don't duplicate big desktop either. I don't know WindowMaker, though.
Please, just pretend xdm doesn't exist.
I personally am interested in having xdm maintained, since wdm is based on it. To be honest, I have asked the wdm maintainer to rebase on latest xdm, but he still hasn't done it. But in any case wdm suits my needs much better than gdm (at least starts infinitely faster). I agree that xdm itself is a bit too minimalistic, especially since there is no simple way to change the session if I recall well.
-- Pat
On 2007-11-05, 14:21 GMT, Adam Jackson wrote:
The major problem with this is there's almost nothing in the distro that requires the X server itself at the rpm level.
OK, sorry that's remnants of my Debianist thinking -- I used to install from minimal install of Debian to almost fully loaded system just by
aptitude install lyx kontact
being quite certain that most of the stuff needed will be there.
No, that's not criticism of Red Hat, just forgot that fully defined dependencies are not present everywhere.
The base-x group in comps is actually pretty minimal on its own. I'd be happy with trimming it down to the bare minimum, marking it non-visible, and having the various desktop groups depend on it (in comps, not in their packaging).
Sure, that would be perfect for me.
I would say something here about senseless duplication of effort, but it's not likely to convince anybody.
Read my question „Why do you not use XFCE“ later in the thread.
Please, just pretend xdm doesn't exist.
I would sometimes wanted to hear the explanation (remember I was talking about fixing and maintaining xdm), but for the purposes of this discussion you can quite happily
s!xdm!simple display manager w/o Gnome and KDE libs!
I just wasn't sure there are alternatives to [xgk]dm.
I wish we had a way to mark packages as actively deprecated. I don't want to orphan xdm, I want that no one work on it ever again.
Yes, please, I am always lost with xdm bugs ... :-)
Matěj
"MC" == Matej Cepl mcepl@redhat.com writes:
MC> aptitude install lyx kontact
MC> being quite certain that most of the stuff needed will be there.
MC> No, that's not criticism of Red Hat, just forgot that fully MC> defined dependencies are not present everywhere.
If those packages require an X server then something is rather wrong with the dependencies, unless by "fully defined dependencies" you mean "has way more dependencies than actually needed".
You can install those things on a headless server and run them over the network. No X server is needed on the machine where they're installed.
- J<
Jason L Tibbitts III <tibbs <at> math.uh.edu> writes:
If those packages require an X server then something is rather wrong with the dependencies, unless by "fully defined dependencies" you mean "has way more dependencies than actually needed".
You can install those things on a headless server and run them over the network. No X server is needed on the machine where they're installed.
They're using soft dependencies, where the admin can decide to treat these as hard dependencies or ignore them. There's 2 levels of soft dependencies, Recommends and Suggests, where the first defaults to be treated like a hard dependency and the second defaults to be ignored.
There's proposals for adding these to RPM too, but that hasn't happened yet. Once added to RPM, the proponents will also have to convince Fedora that using them in Fedora is a good idea if they want those features to get actively used.
Kevin Kofler
On Mon, 2007-11-05 at 00:32 +0100, Matej Cepl wrote:
On 2007-10-31, 18:49 GMT, Kevin Kofler wrote:
I have suggested at least 2 technical solutions, none of which needs any changes to Anaconda:
May add one more possible solution: what about dropping Base X group from anaconda altogether and why not to treat it as a library, which is required by another components (do we have a group for glibc)?
The problem is that its components *aren't* libraries. If they were, they'd be appropriately required by packages and thus automatically pulled in. So where do you propose putting those packages so that they get installed on the system?
Jeremy
Matej Cepl (mcepl@redhat.com) said:
May add one more possible solution: what about dropping Base X group from anaconda altogether and why not to treat it as a library, which is required by another components (do we have a group for glibc)?
group dependencies don't currently exist.
Bill
devel@lists.stg.fedoraproject.org
-
Adam Jackson -
Bill Nottingham -
Christopher Aillon -
Jason L Tibbitts III -
Jeremy Katz -
Jesse Keating -
Jon Ciesla -
Kevin Kofler -
Matej Cepl -
Patrice Dumas -
Rahul Sundaram