On Tue, Apr 03, 2012 at 11:26:01AM -0500, Bruce Dubbs wrote: > Ken Moffat wrote: > > I suppose I should build gnome in /opt/gnome to check it out. I've been > trying out Ubuntu on a new box lately and find the user interface > terrible (I switched it to KDE). > It's not so much the poor UI I dislike as the general dumbing-down of the applications (simple examples - a few versions ago, gcalctool had memories for storing and recalling values. Now, I have to open multiple instances and paste the item I would prefer to store. Or gucharmap - the explanatory text (e.g. on many 'exotic' lowercase latin letters, telling you which languages they are used in, and sometimes extra details such as preferred alternatives [ s with cedilla, s with comma ] or occasionally where the corresponding uppercase letter can be found) is truncated even if you expand the window.). So, my overall view is that gnome is disappointing.
> On ubuntu there is: > > /etc/gnome > defaults.list menus.blacklist > /etc/gnome-app-install > packages-whitelist > /etc/gnome-settings-daemon > xrandr/ (empty) > /etc/gnome-vfs-2.0 > modules/ > default-modules.conf extra-modules.conf > > There is also ~/.gnome2 > So, /etc/gnome and /etc/gnome-app-install appear to be for packaging. Their gnome-settings-daemon has sysconfdir=/etc - my own has the similar structure at /etc/gnome/gnome-settings-daemon. I can't see the gnome-vfs-2.0 anywhere (I'm back on my new box) - might be packaging, or might indicate that some parts of gnome are 2.30 or 2.32. I did notice the other day that one of the packages in ubuntu seems to be stuck at a 2.9x (i.e. development leading to 3.0) version. > For kde, there is nothing in /etc, but there is in ~/.kde. > > > > > 1.2 I suppose we could stress that anyone not building in /usr && > > /etc needs to provide symlinks in /etc/xdg if they want to use gdm ? > > That seems a logical thing to do. > OK > > 2. The bootscript is old-style. Works, but not in the current > > Provides/Required-Start/... style. If I was motivated, I could > > probably come up with something, but whether it would have the > > correct names for the variables is anybody's guess. I still think > > the old scripts were better because they were easy to understand - > > no doubt there is a key somewhere explaining things such as > > "$network", but I suspect it is in a locked drawer in a room marked > > "beware of the leopard" ;-) > > Not really: http://wiki.debian.org/LSBInitScripts > Thanks - I never noticed a reference in the earlier discussions. > I can update the script easily enough if the commands are still current, > Are they basically still: > > start) loadproc gdm ;; > stop) if [ -f $pidfile ]; then loadproc gdm-stop; fi ;; > reload) loadproc gdm-safe-restart ;; > restart) loadproc gdm-restart ;; > Yes. > > 3. The default gnome session installed by gdm (i.e. without d-bus) > > reports an error, something along the lines of failing to find the > > clock applet. Since D-Bus is *required* for gnome (e.g. GConf needs > > d-bus glib bindings), we could either overwrite the inadequate > > version it supplies, or perhaps better (to retain the translations - > > see attachment) sed Exec= and TryExec= to use the book's > > preferences. Either way, the sentence "If you have D-BUS installed > > and you want to start the session D-BUS daemon..." needs to be > > reworded. I suspect the suggestion to use gdm without D-Bus is just > > historical baggage, > > It is required for build. daemon/main.c has an unconditional > #include <dbus/dbus-glib.h>. > > > but I don't understand why gdm ships a version > > that can't find everything. Maybe something else is in the wrong > > place ? > > Perhaps we could find the search locations from the source? > It looks like you can toggle debug messages with the signal USR1. > Perhaps, but I'm insufficiently motivated at the moment (I would have to reinstate the old file so that I could make a note of what the exact error was, and I suspect the search will be difficult). For any regular application, strace would be the way to go. But trying to strace a dm seems too painful. > > 4. For many of the PAM files in /etc/pam.d we chmod them to 644 > > after root has created them, but for a couple of newer ones the > > chmod is not mentioned. Looking at my results, they are 644 - > > should be keep the chmod in case people have weird settings, and > > therefore do it for all these files, or can we just assume > > everything will be ok ? > > It really depends on umask. I'd say we need to be consistent. OK, consistency will rule, I'll add it. > > > I'll also note that something about the gdm window (probably the > > buttons - they seem a bit OS9, i.e 1990s mac) offends my sense of > > taste: usually I don't particularly care, and the striped blue > > background looks ok if you like that sort of thing, but I do wonder > > where they are going with this. Perhaps it looks better on more > > powerful hardware which doesn't use the fallback - even the Sandy > > Bridge i3/i965 I bought last week doesn't fit the bill for > > gnome-shell, so who knows. > > I think it's the video hw, not the cpu. Correct, that's why I mentioned the i965 part, although the kernel lumps it in with other intel videos in i915: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Giga-byte Technology Device d000 Flags: bus master, fast devsel, latency 0, IRQ 40 Memory at f7800000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Mesa (7.11.2) has given me both i915_dri.so and i965_dri.so, so I was expecting dri2 to work here. No matter, in December I stripped out most gnome packages from my normal desktop, and I don't see them coming back anytime soon. > > > I still plan to look at the gnome dependencies (to reduce what we > > list by removing implicit deps), and I guess I can tag gdm as tested > > in 7.0 - subject to agreement on dealing with the consequences of > > not building in /usr and /etc. But for the remaining points above, > > I'm not sure. > > If it basically works, then it works. If we need to go back and add > some configuration issues later, than it sill works. > > -- Bruce Thanks for the comments. I'll do some tidying. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
