Mailinglist Archive: opensuse-factory (422 mails)
| < Previous | Next > |
Re: [opensuse-factory] Plan for 11.2?
- From: "Matt Sealey" <matt@xxxxxxxxxxxxxx>
- Date: Thu, 8 Jan 2009 13:21:15 -0600
- Message-id: <b5e2fc790901081121j60521a7dgebb5eecdc6ff38cf@xxxxxxxxxxxxxx>
On Wed, Dec 17, 2008 at 8:25 AM, Birger Kollstrand
<birger.kollstrand@xxxxxxxxxxxxxx> wrote:
I'd be all for this, and also for something like splitting X.org and
KDE into slightly more fine-grained chunks. In the past, installing
KDE apps (and some GNOME stuff for that matter) is a matter of
grabbing huge swathes of stuff whether you want it or not. If you just
want Marble you had to install the entirity of kdeedu. Now it's all
seperate in 11.1. This is awesome because you can pick and choose -
but the damn patterns mean you have to grab nearly all of it by
default.
More fine-grained patterns
radeonhd and unichrome are seperate video drivers, but otherwise
everything is in xorg-x11-drivers-video (including, on platforms like
PowerPC, a ton of drivers which have never been seen in a PowerPC box,
nor probably ever will be - i740, intel i810, vesa (!!) and vbe and
suchlike. While it doesn't waste too much space (on the order of a
couple of megabytes) compared to usual disk sizes as a whole, most
systems only have one graphics card, and if they have two, it's
usually under the same driver.
Perhaps they could be split into xorg-x11-drivers-video-rare, then the
popular types (radeon, sis/xgi, nv, maybe nouveau at some very later
stage like 13.1 :), and when a user is installing, it can be removed
(just like some stuff is added in stage2) after SaX2 has run and
picked the right card. The X.org autoconfiguration system which allows
the X.org to boot without any configuration for a card specifically,
could simply be expanded to run SaX2 or some replacement, which can go
off and grab the right driver from the package repository, then
initialize it properly.
The same goes for xorg-x11-libs which is a behemoth. I filed a bug
report about it not long ago (since the default build extracts EVERY
*.tar.bz2 in /usr/src/packages/SOURCES with wild abandon, which is
nasty if you installed kernel-source.src) and I understand the
maintainer's pain on maintaining ~30 different packages for each
library; however I do think that it can be done, and Fedora (RPM
based), Debian/Ubuntu and the like all manage to keep them seperately.
I think the advantages of only installing what you need is a good one.
There are some weird conceptual decisions here - Xrender is a seperate
library, but Xcomposite is in the -libs monsterpackage, which is odd
since both are enabled by default by the X server.
(btw is EXA going to become some default in the near future, the
performance benefits really are noticable on radeon cards and even
moreso with a post-11.1 driver since David Airlie put in some extra
work on the EXA acceleration).
I'd also be completely condusive to ditching qt3 - when I installed
GNOME last time, somehow I got this package. I don't think it's a hard
dependency on anything here, but I noticed it in KDE4 too, which is
odd since 11.1 was supposed to have "no Qt3 or GTK apps on the default
desktop". If that's true why install it? The Qt3 compatibility library
was installed too.
With regards to KDE, I like SUSE because it has Kickoff, which is a
lovely little menu, but I have since been poking around in GNOME and
noticed the menu there looking ever -so-slightly lovelier. The
applications list is a nice idea, far better than the weird
click-slide heirarchy of the KDE menu. It also means you could replace
the application launcher; KDE still misses the kind of Netbook-style
support that for instance ume-launcher does on Ubuntu (which is a
direct replacement for the GNOME one). It must also be said that the
Qt4 YaST GUI is fugly at best, compared to the launcher-style menu of
the GNOME UI module which matches the GNOME launcher perfectly.
I know some things you just don't want to copy, but in the end,
switching between desktops gives two completely different experiences,
and sometimes simple is best (which is what GNOME is, to a fault
sometimes).
On the contrary, the GNOME package manager UI is f**king awful.
Everything is so squished and ugly. Adding a package squishes it even
more.. by adding larger rows to the right. This means your list of
packages to install pushes out the list of packages you want to search
for! Can't this be moved to some kind of tab like "Install Queue" or
something, like Kuroo had/has?
http://kuroo.org/screenshots.html
(my screen res is 1280x1024 but I don't like to open all my windows
maximized if I don't need to.. sometimes I want to refer to a document
about which packages I need, while I am picking them..)
The other thing is, I absolutely loathe yast2-bootloader for a lot of
reasons. While a neat idea, it seems to have fallen down as a rather
poorly maintained set of hacks for random different bootloader
solutions, to the point that it abstracts everything into a LILO-like
bootloader system which is really really difficult to actually manage.
Adding new bootloaders is some nightmare; and while it supports some
bootloader methods (like PReP zImage), these aren't enabled for
platforms that need it, and supporting it would mean modifying tens of
files by my reckoning. And then fixing lilo-ppc too (which is nothing
to do with or any part of lilo, sigh) - could some effort be put in to
rework the bootloader management such that bootloaders are treated as
native modules, and adding a new bootloader is a simple matter of
accepting a string of commands (add kernel+initrd, return it's index,
set some settings, arguments on each entry) which outputs a new
configuration and runs any update binaries in-place?
(naive request since, the above is what it does, it just goes through
3 levels of abstraction too many IMO when every bootloader is forced
to act like LILO, you may as well just reduce all bootloader support
to pluggable modules which only accept the data LILO could use, and
perform tasks natively. It would also mean that yast2-bootloader would
only include the code you need on YOUR architecture and for YOUR
bootloader, and not the 5 or 6 alternatives..)
See above. More focus in KDE on application launching etc. and
comparable tools to the Ubuntu GNOME stuff would be great.
http://www.freesoftwaremagazine.com/columns/ubuntu_netbook_remix_detailed_explanation
Half of it would be easily implemented in Plasma given the time and developers.
It actually requires a hell of a lot of setup to get a USB key
bootable, more than you could possibly do by shipping a file. I guess
a little Windows installer would be okay that shoved a bootloader on
there, and copied the NET iso stuff there (or even the full DVD) but
that kind of defeats the object of perhaps grabbing a clean system and
installing SUSE from scratch from a USB key. You'd need an existing
system to do it.. which is the computing equivalent IMO of
waterboarding.
--
Matt Sealey <matt@xxxxxxxxxxxxxx>
Genesi, Manager, Developer Relations
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
<birger.kollstrand@xxxxxxxxxxxxxx> wrote:
Hi,
I'm wondering if there is a plan for the 11.2 distribution? It's not
when it's available but more what Novell want's to achieve with it.
There are several important areas that I would like to help out with:
1. vastly reduced size of the core distro and easy setup for addons.
Take out all but core KDE (and Gnome, but I'm a KDE'er so....).
I'd be all for this, and also for something like splitting X.org and
KDE into slightly more fine-grained chunks. In the past, installing
KDE apps (and some GNOME stuff for that matter) is a matter of
grabbing huge swathes of stuff whether you want it or not. If you just
want Marble you had to install the entirity of kdeedu. Now it's all
seperate in 11.1. This is awesome because you can pick and choose -
but the damn patterns mean you have to grab nearly all of it by
default.
More fine-grained patterns
radeonhd and unichrome are seperate video drivers, but otherwise
everything is in xorg-x11-drivers-video (including, on platforms like
PowerPC, a ton of drivers which have never been seen in a PowerPC box,
nor probably ever will be - i740, intel i810, vesa (!!) and vbe and
suchlike. While it doesn't waste too much space (on the order of a
couple of megabytes) compared to usual disk sizes as a whole, most
systems only have one graphics card, and if they have two, it's
usually under the same driver.
Perhaps they could be split into xorg-x11-drivers-video-rare, then the
popular types (radeon, sis/xgi, nv, maybe nouveau at some very later
stage like 13.1 :), and when a user is installing, it can be removed
(just like some stuff is added in stage2) after SaX2 has run and
picked the right card. The X.org autoconfiguration system which allows
the X.org to boot without any configuration for a card specifically,
could simply be expanded to run SaX2 or some replacement, which can go
off and grab the right driver from the package repository, then
initialize it properly.
The same goes for xorg-x11-libs which is a behemoth. I filed a bug
report about it not long ago (since the default build extracts EVERY
*.tar.bz2 in /usr/src/packages/SOURCES with wild abandon, which is
nasty if you installed kernel-source.src) and I understand the
maintainer's pain on maintaining ~30 different packages for each
library; however I do think that it can be done, and Fedora (RPM
based), Debian/Ubuntu and the like all manage to keep them seperately.
I think the advantages of only installing what you need is a good one.
There are some weird conceptual decisions here - Xrender is a seperate
library, but Xcomposite is in the -libs monsterpackage, which is odd
since both are enabled by default by the X server.
(btw is EXA going to become some default in the near future, the
performance benefits really are noticable on radeon cards and even
moreso with a post-11.1 driver since David Airlie put in some extra
work on the EXA acceleration).
I'd also be completely condusive to ditching qt3 - when I installed
GNOME last time, somehow I got this package. I don't think it's a hard
dependency on anything here, but I noticed it in KDE4 too, which is
odd since 11.1 was supposed to have "no Qt3 or GTK apps on the default
desktop". If that's true why install it? The Qt3 compatibility library
was installed too.
With regards to KDE, I like SUSE because it has Kickoff, which is a
lovely little menu, but I have since been poking around in GNOME and
noticed the menu there looking ever -so-slightly lovelier. The
applications list is a nice idea, far better than the weird
click-slide heirarchy of the KDE menu. It also means you could replace
the application launcher; KDE still misses the kind of Netbook-style
support that for instance ume-launcher does on Ubuntu (which is a
direct replacement for the GNOME one). It must also be said that the
Qt4 YaST GUI is fugly at best, compared to the launcher-style menu of
the GNOME UI module which matches the GNOME launcher perfectly.
I know some things you just don't want to copy, but in the end,
switching between desktops gives two completely different experiences,
and sometimes simple is best (which is what GNOME is, to a fault
sometimes).
On the contrary, the GNOME package manager UI is f**king awful.
Everything is so squished and ugly. Adding a package squishes it even
more.. by adding larger rows to the right. This means your list of
packages to install pushes out the list of packages you want to search
for! Can't this be moved to some kind of tab like "Install Queue" or
something, like Kuroo had/has?
http://kuroo.org/screenshots.html
(my screen res is 1280x1024 but I don't like to open all my windows
maximized if I don't need to.. sometimes I want to refer to a document
about which packages I need, while I am picking them..)
The other thing is, I absolutely loathe yast2-bootloader for a lot of
reasons. While a neat idea, it seems to have fallen down as a rather
poorly maintained set of hacks for random different bootloader
solutions, to the point that it abstracts everything into a LILO-like
bootloader system which is really really difficult to actually manage.
Adding new bootloaders is some nightmare; and while it supports some
bootloader methods (like PReP zImage), these aren't enabled for
platforms that need it, and supporting it would mean modifying tens of
files by my reckoning. And then fixing lilo-ppc too (which is nothing
to do with or any part of lilo, sigh) - could some effort be put in to
rework the bootloader management such that bootloaders are treated as
native modules, and adding a new bootloader is a simple matter of
accepting a string of commands (add kernel+initrd, return it's index,
set some settings, arguments on each entry) which outputs a new
configuration and runs any update binaries in-place?
(naive request since, the above is what it does, it just goes through
3 levels of abstraction too many IMO when every bootloader is forced
to act like LILO, you may as well just reduce all bootloader support
to pluggable modules which only accept the data LILO could use, and
perform tasks natively. It would also mean that yast2-bootloader would
only include the code you need on YOUR architecture and for YOUR
bootloader, and not the 5 or 6 alternatives..)
9. availability on new platforms. Specific focus on netbooks.
See above. More focus in KDE on application launching etc. and
comparable tools to the Ubuntu GNOME stuff would be great.
http://www.freesoftwaremagazine.com/columns/ubuntu_netbook_remix_detailed_explanation
Half of it would be easily implemented in Plasma given the time and developers.
10. Default media made for USB key as well as DVD.
It actually requires a hell of a lot of setup to get a USB key
bootable, more than you could possibly do by shipping a file. I guess
a little Windows installer would be okay that shoved a bootloader on
there, and copied the NET iso stuff there (or even the full DVD) but
that kind of defeats the object of perhaps grabbing a clean system and
installing SUSE from scratch from a USB key. You'd need an existing
system to do it.. which is the computing equivalent IMO of
waterboarding.
--
Matt Sealey <matt@xxxxxxxxxxxxxx>
Genesi, Manager, Developer Relations
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
| < Previous | Next > |