Mailinglist Archive: opensuse-factory (599 mails)
| < Previous | Next > |
Re: [opensuse-factory] distribution meeting - introduction and agenda
- From: Robert Schiele <rschiele@xxxxxxxxxxxxxxx>
- Date: Wed, 16 Aug 2006 20:16:45 +0200
- Message-id: <20060816181645.GG4811@xxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
"Quidquid latine dictum sit, altum sonatur."
>
> 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@xxxxxxxxxxxxxxx
"Quidquid latine dictum sit, altum sonatur."
| < Previous | Next > |