
On Wed, Dec 17, 2008 at 8:25 AM, Birger Kollstrand <birger.kollstrand@googlemail.com> 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_ex... 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@genesi-usa.com> Genesi, Manager, Developer Relations -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org