On Wed, Aug 16, 2006 at 04:44:59PM +0200, Andreas Jaeger wrote: > > We have an internal meeting every few weeks called "dist meeting" > that discusses major technical changes in our distribution. > > Since it's not possible for most of you to attend it, I'd like to try > an experiment and share the agenda before the meeting - and the > meeting minutes afterwards with you. I'm asking for your feedback on > the agenda and any comments that you have and will bring those > comments into the meeting and raise the points you've made. Will this > work?
We'll see... ;-) > The planned topics for tomorrow's meeting are: > > * D-Bus 0.91 and PolicyKit/resmgr > > We just switched to D-Bus 0.91 and the question arises whether to > continue to use resmgr or switch to PolicyKit. Not envolved enough to have a personal opinion about that. > * Move to GNOME 2.16 > > The packagers have started already with the first packages, we want > to discuss the timeframe for the move and the move of GNOME to /usr > (from /opt/gnome). I personally like to see as much as possible as soon as possible moved from /opt away into /usr. But since I am not aware of the GNOME specific compatibility problems that arise from that I could not say anything more specific about the GNOME switch. > * SuSEconfig removal > > SuSEconfig is currently run after each package installation by YaST > and is a huge bottleneck. Some scripts have already been removed > and we have to discuss how to move on. Very much appreciated. If you see a specific script problematic to remove you don't have an appropriate solution for you might want to post it here, maybe someone else could provide a solution for this. > * update messages general/conditional (e.g. bind) > > During update of packages they could notify users about changes via > email and/or the SuSEplugger (until 10.0, this is not anymore in > 10.1). Most of these are outdated and not really usefull anymore > and should be removed. The question is how to handle situations > like bind where config files get rewritten and the user should be > informed if this fails. I personally liked the mail variant. > * Dropping UP Kernel on i386/x86-64 > > The proposal by the kernel team is to use only SMP kernels and no UP > kernel. It's already this way on Xen - there is no Xen UP kernel. > > Advantages: > One less kernel rpm. On 64bit there will be only two kernel rpms then, > kernel-default and kernel-xen; and with some luck if paravirt ops > works out as designed we can then later drop kernel-xen too and > only ship a single 64bit kernel. 32bit could go down to two. > Less QA. > Less space on ftp servers. > Less build time. > > Avoids a lot of problems with install kernel being different from > final kernel. The i386 UP kernel e.g. doesn't support advanced APIC > modes, which broke i386 installation of SLES10 on some > systems. We've had quite a lot of bugs in this area over the years. > > Disadvantages: > > Will be slightly slower and bigger on UP systems. Most of the Do you have numbers for that? > performance difference is fixed up by kraxel's LOCK prefix runtime > patch. Memory usage will be up a bit on UP systems We would lose a Do you have numbers including the patch? > few drivers which are BROKEN_ON_SMP. Usually these are long > unmaintained drivers which are broken for other reasons anyways so > it's not a big loss. Also we never had them in the SMP kernel and > most modern systems run SMP kernels. There might be other bugs I suppose the most "famous" drivers with these problems are some of the binary-only drivers anyway. > caused by this, but Fedora has done this before us and they didn't > seem to have regretted it so far. If the numbers don't show a difference that is too hard then I'd definitely like to see that. > * Linker Options and Optimizations > > We plan to use the recently developed linker optimizations for the > GNU hashstyle and use the readonly relocations: > > LDFLAGS="-Wl,-O1 -Wl,--hash-style=both" > (http://lwn.net/Articles/192082/ ) I think this is a very good idea because especially for large C++ applications I can often see the linker consuming _extremely_ much CPU time resolving hash conflicts, especially when templates are used in an extensive way. > LDFLAGS="-Wl,-z relro" > (see http://people.redhat.com/drepper/nonselsec.pdf) I currently can't see a disadvantage of using this one thus unless someone could actually see one I'd go the same way. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED] "Quidquid latine dictum sit, altum sonatur."
pgpxX0ClJkCUN.pgp
Description: PGP signature
