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:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."