[opensuse-factory] Plan for 11.2?
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....). 2. mobility. Moving between networks, WLAN, LAN, GPRS , Bluetooth ++. Suspend/Resume, auto setup of VPN when moving outise the home LAN. Roaming profile/autosyncing of data with server with Unison , iFolder or similar. 3. syncing data with mobile phones 4. VPN client and server config. If so, choose one VPN server variant and support it 100%. (I like OpenVPN :-) ) 5. Home. Easy home server setup in one Yast module for useability. Fileserver, printer server, music server, movie server, picture server. 6. Connectivity from different types of clients, especially Upnp and DLNA compatibility. Windows, Mac and Linux client access to printer and file of cource and also wizards or simmilar to aid users in getting connected on the client machines. (Yes this might involve windows/mac/openSolaris SW) 7. media syncing with hanheld devices like iPod's, media phones, Creative ZEN. Also conversion of media to the hanhelds preferred format without the user needing to set up a complex structure. 8. officially supported game archive, maybe also with commercial games available like Opera/flash etc. is now available. 9. availability on new platforms. Specific focus on netbooks. 10. Default media made for USB key as well as DVD. 11. a standard yast module for server setup of net install of machines. This will aid in testing when there is a lot of machine variants to test. Easy restore to original config would be good also. (All server based :-) ) I have 15+ different computeres that I can test with , but it's to much work going back and forth now so I just use 2. Of course, if I do not make any sense (which often happens) I will be glad to discuss the points. And again, these are all parts I will gladly assist in testing. If some of it is made in Python I will try to assist with code also, but be warned. It's better to keep me as tester! Kind Regards Birger -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2008/12/17 Birger Kollstrand
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....).
Have you tried the Net Install CD? Even X is optional, whilst the defaults may include stuff like AppAmor that you might not use. The Live CD's are copying over a 'typical' package set, for a simple starting point to those confused by choices.
10. Default media made for USB key as well as DVD.
Why not a LIve USB using Kiwi? It may not have the options of the Net or DVD install, but won't it be "ready to go" for more users.
11. a standard yast module for server setup of net install of machines. This will aid in testing when there is a lot of machine variants to test. Easy restore to original config would be good also.
If you have the DVD image, then you can loop back mount it to /srv/openSuSE just export it via NFS and then boot the net install client. /etc/fstab(5) : /dl/openSuSE/openSUSE-10.3-GM-DVD-i386-iso/openSUSE-10.3-GM-DVD-i386.iso /srv/openSuSE auto loop,ro 0 0 /etc/exports : /srv/OpenSuSE *(ro,root_squash,sync,no_subtree_check) Restoring the config of client machines seems like a rather tall order, given that they could have any distro, Windows, Solaris or BSD on them. Do you mean that you want to boot the client machine, then install into some set configuraton eg) take all defaults or something? Or are you expecting to plan for future testing by having swap, /boot and / partitions avialable? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Birger Kollstrand escribió:
1. vastly reduced size of the core distro
Ok, how you suggest we do that ? is 250/300 MB too big for you ?
and easy setup for addons.
Easier than "one click install" eh ?
4. VPN client and server config. If so, choose one VPN server variant and support it 100%. (I like OpenVPN :-) )
A yast module to configure openVPN server, and fix the networkmanager-openvpn support for client will be really nice indeed. -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
On Wednesday 17 December 2008 15:25:27 Birger Kollstrand wrote: [snip]
11. a standard yast module for server setup of net install of machines. This will aid in testing when there is a lot of machine variants to test. Easy restore to original config would be good also. (All server based :-) ) I have 15+ different computeres that I can test with , but it's to much work going back and forth now so I just use 2.
What is missing in yast2-instserver? And for restoring configuration, you can use autoyast Create Profile function and then deploy via autoyast. Stnao -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2008-12-17 at 20:50 +0100, Stanislav Visnovsky wrote:
On Wednesday 17 December 2008 15:25:27 Birger Kollstrand wrote:
[snip]
11. a standard yast module for server setup of net install of machines. This will aid in testing when there is a lot of machine variants to test. Easy restore to original config would be good also. (All server based :-) ) I have 15+ different computeres that I can test with , but it's to much work going back and forth now so I just use 2.
What is missing in yast2-instserver? And for restoring configuration, you can use autoyast Create Profile function and then deploy via autoyast.
Stnao
mentioning autoyast.... I noticed (didn't check bugzille yet) but _IF_ you were wise enough to enable autoyast during software-selection, the "clone-system"-checkbox at the very end of the installation is not greyed-out. However if one chooses to enable this, no data is collected and saved in /root/autoinstall.xml anymore. (checked in B5, RC1) is this solved in the final version??? It produces something diffrent than when creating a reference-profile. Could add some more to the wishlist. I would like to see some cluster-aware tools. like ovirt or lax (from teegee.de). Specially SLES would bennefit from it. ovirt comes from the fedora-boys, while lax is (afaik) opensuse_11.0/sles10sp2 based. hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
theres already a 11.2 schedule discussion on the other list http://lists.opensuse.org/opensuse-project/2008-12/msg00025.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Dec 19, 2008 at 4:05 AM, ab
theres already a 11.2 schedule discussion on the other list http://lists.opensuse.org/opensuse-project/2008-12/msg00025.html
Boy this irritates me:
From: Michael Loeffler
First we talked about July '09 release to come close to an 8 months release cycle. But KDE 4.3 is scheduled for release on June 30th and probably an OpenOffice.org release will be out end of June as well - both wouldn't make it into a July openSUSE 11.2. Therfor we're now thinking about a September release. Beside of getting the most current OpenOffice and KDE in
I asked for a delay for KDE 4.2 and was shot down because of the 6 month cycle. Now they are talking about a 9 month and what I had asked for.......... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2008/12/19 Larry Stotler
On Fri, Dec 19, 2008 at 4:05 AM, ab
wrote: theres already a 11.2 schedule discussion on the other list http://lists.opensuse.org/opensuse-project/2008-12/msg00025.html
I asked for a delay for KDE 4.2 and was shot down because of the 6 month cycle. Now they are talking about a 9 month and what I had asked for..........
Least they're not talking about about releasing in sync with the kernel, every 3 months! The other thread is more about schedule issues and marketing, rather than what can be developed for 11.2. Now I don't really know what the true current state of play is here... Personally I'd actually like to get away from "Releases" all together, just have them as 'snapshots' in time, as on the net, you don't have much choice but to keep relatively current. It's not just because of security patches, but also things like older browsers not working on recent websites and such. But to have something like Factory to be equivalent of Debian "unstable", and then 11.1 being "current" to be replaced by 11.2, with 11.1 getting the "stable" moniker and living on as SLED/SLES; then upgrades have to get major attention during testing and package building. Whilst on forum, some are advocating "zypper dup", those using that to go from 11.0 -> 11.1 are hitting problems with pam, and who knows what else that isn't immediately noticeable? The whole download an iso, for release testing labelled -alpha or -beta, doing fresh install, and then trying to test it, tends to lead to "playing" with the system, rather than really working with it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 19 December 2008, Larry Stotler wrote:
. Now they are talking about a 9 month and what I had asked for..........
MAybe at last someone is seeing sense 9 months is a bit more like it that way the whole world gets a much more stable release with less bugs causing heated exchanges on the list now we just need to get this darn KDE4 distribution stopped till it is at the very least the equal of KDE 3.5.7 or 9 Pete -- SuSE Linux 10.3-Alpha3. (Linux is like a wigwam - no Gates, no Windows, and an Apache inside.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wednesday 17 December 2008 23:05:18 Hans Witvliet wrote:
On Wed, 2008-12-17 at 20:50 +0100, Stanislav Visnovsky wrote:
On Wednesday 17 December 2008 15:25:27 Birger Kollstrand wrote:
[snip]
11. a standard yast module for server setup of net install of machines. This will aid in testing when there is a lot of machine variants to test. Easy restore to original config would be good also. (All server based :-) ) I have 15+ different computeres that I can test with , but it's to much work going back and forth now so I just use 2.
What is missing in yast2-instserver? And for restoring configuration, you can use autoyast Create Profile function and then deploy via autoyast.
Stnao
mentioning autoyast.... I noticed (didn't check bugzille yet) but _IF_ you were wise enough to enable autoyast during software-selection, the "clone-system"-checkbox at the very end of the installation is not greyed-out.
Yes, you need the autoyast code to gather the info.
However if one chooses to enable this, no data is collected and saved in /root/autoinstall.xml anymore. (checked in B5, RC1) is this solved in the final version???
I'm not sure, I will check.
It produces something diffrent than when creating a reference-profile.
No, it does not. The only difference is a set of modules to gather information from. Stano
Could add some more to the wishlist. I would like to see some cluster-aware tools. like ovirt or lax (from teegee.de). Specially SLES would bennefit from it. ovirt comes from the fedora-boys, while lax is (afaik) opensuse_11.0/sles10sp2 based.
hw
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
For 11.2, what about using filesystem capabilities to reduce the number of suid executables, in order to reduce the criticality of security flaws? Ultrich Drepper has blogged a short example that is usable in Fedora 10 - http://udrepper.livejournal.com/20709.html LWN Subsriber only content until 2009/01/14 - http://lwn.net/Articles/313838/ More discussion and info on this, if you can read it. The kernel now uses the filesystem capabilities, and at least the default & commonest filesystems support extended attributes (xattr's). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 08 January 2009, Rob OpenSuSE wrote: Hows about BTRFS for 11.2 it seems it is heading for the kernel now and almost anything has just got to be better than Ext** whatever Pete . -- SuSE Linux 10.3-Alpha3. (Linux is like a wigwam - no Gates, no Windows, and an Apache inside.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Dec 17, 2008 at 8:25 AM, Birger Kollstrand
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
2009/1/8 Matt Sealey
On Wed, Dec 17, 2008 at 8:25 AM, Birger Kollstrand
wrote:
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.
Aw come on, it's far more sensible to install on a "clean" system, when you've got another near by, that you can check up on things, and/or do something useful rather than watch those installer info screens. I think the only time I actually was preoccupied by an install, was with COL2 in 1999, which actually invited you to play ksirtet, whilst it did the work in a rather impressive pipelined manner. How many ppl without internet access via another computer, are going to be fiddling about with USB key, rather than DVD boxset, or a Live CD or DVD image? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 8, 2009 at 2:21 PM, Matt Sealey
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.
The reason that qt3 is loaded is because some of the KDE programs aren't yet qt4, so you need to have that to run those programs. IF all you programs are qt4, you should be abel to remove it tho.
With regards to KDE, I like SUSE because it has Kickoff, which is a lovely little menu,
See, I think it sucks and change it to the old KDE menu immediately. It runs really slow on my older P3 laptop. To each their own tho. openSUSE and Linux's RAM needs have really gotten out of hand lately. I was running 10.2 on a PowerMac 7500/G4/700 with 256MB with no problem. Now I need 512 or it's slow as molasses. Not a good trend IMO. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
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.
Aw come on, it's far more sensible to install on a "clean" system, when you've got another near by, that you can check up on things, and/or do something useful rather than watch those installer info screens. I think the only time I actually was preoccupied by an install, was with COL2 in 1999, which actually invited you to play ksirtet, whilst it did the work in a rather impressive pipelined manner.
How many ppl without internet access via another computer, are going to be fiddling about with USB key, rather than DVD boxset, or a Live CD or DVD image?
Ideally most people would have a PC that does everything they need,
and now that we live in the world of the iPhone, who needs another PC
to browse the web?
Ideally PCs would boot from an HTTP URL but I've only ever seen one
system that could ever do that (OpenFirmware implementation on the
OLPC and the one in development at Genesi :)
Maybe EFI will fix it for the rest of the world so installing an OS is
as much as typing in "get.opensuse.org" or "go.windows.com" and having
it boot something.. security notwithstanding.
Mounting repositories over HTTP would be a great idea too. FUSE has
suitable filesystems.. that would save the ridiculous notion right now
where downloading over the net is a "download, unpack" affair compared
to NFS, local repo on a hard disk or .. I'd like to say DVD, but my
experience is it always "downloaded" them from CD media before
unpacking it. This sort of stuff can double install times.
--
Matt Sealey
Am Donnerstag 08 Januar 2009 21:35:35 schrieb Larry Stotler:
On Thu, Jan 8, 2009 at 2:21 PM, Matt Sealey
wrote: [...] , 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.
The reason that qt3 is loaded is because some of the KDE programs aren't yet qt4, so you need to have that to run those programs. IF all you programs are qt4, you should be abel to remove it tho.
Even parts of YaST still use qt3 with kde3 themes and therefore kdelibs3.
[...]
Herbert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/8 Matt Sealey
Mounting repositories over HTTP would be a great idea too. FUSE has suitable filesystems.. that would save the ridiculous notion right now where downloading over the net is a "download, unpack" affair compared to NFS, local repo on a hard disk or .. I'd like to say DVD, but my experience is it always "downloaded" them from CD media before unpacking it. This sort of stuff can double install times.
That could be pipelined though, so either the rpm install, or the downloads happen for free in parallel with the next time consuming part of the operation. If you're going to have to get the whole file (and you are), then there's not really a big win, processing the header and then blocking. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
openSUSE and Linux's RAM needs have really gotten out of hand lately. I was running 10.2 on a PowerMac 7500/G4/700 with 256MB with no problem. Now I need 512 or it's slow as molasses. Not a good trend IMO.
I don't think this should be a priority for the main distrib. At least a gig of RAM can considered as a requirement these days. For less, something like an embedded distrib would be more appropriate... Erik. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/8 Putrycz, Erik
At least a gig of RAM can considered as a requirement these days. For less, something like an embedded distrib would be more appropriate...
Why? With KDE4 plus Firefox 512MB RAM was perfectly adequate in my testing. In fact it is very hard to get the VM to use swap space at all, without increasing the default value of "swapiness"; which I think shows the default is poorly chosen. I didn't think 256MB RAM was so awful either under i586, the VM system performed reasonably well (Pentium 1.6Hhz CPU system with horriible Rambus RIMM memory Intel tried to foister on market at time of P4's intro, making an inexpensive upgrade harder to find). I did use Net Install, and prepare swapspace once I'd got it booted however. Ideally I'd find an extra compatible RDRAM, but it was alright. Using XFCE or LXDE would be more pleasurable, I think than GNOME or KDE4 if you're going to run applications. Perhaps my experience was better, because I added the KDE4 basics, and may have avoided stuff like nepomuk and beagle, as I had limitted space for /. There's no reason to tell ppl to not use old machines, just because you'ld not spec out such a machine for desktop. 256MB RAM is plenty for many SOHO server applications. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 8, 2009 at 7:02 PM, Rob OpenSuSE
Why? With KDE4 plus Firefox 512MB RAM was perfectly adequate in my testing. In fact it is very hard to get the VM to use swap space at all, without increasing the default value of "swapiness"; which I think shows the default is poorly chosen.
Agreed. Those who make comments like that evidently don't have an older system, or if they do, don't use it. I regularly run on older hardware with few issue. Granted, it's not as fast as my 64bit machines, but why should I spend $$ I don't have to upgrade? The economy is not that great now, and it can be more expensive to upgrade an older system than a newer one.
There's no reason to tell ppl to not use old machines, just because you'ld not spec out such a machine for desktop. 256MB RAM is plenty for many SOHO server applications.
I run a server with 128MB. It don't need much to just serve up files. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday, 8. January 2009 20:21:15 Matt Sealey wrote:
If you just want Marble you had to install the entirity of kdeedu.
Marble was never part of kdeedu3. </nitpick>
Now it's all seperate in 11.1.
Not gnome-games
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.
It was more "no Qt3 based apps running by default on KDE4 desktop" and we admittedly failed to achieve that goal (knetworkmanager). Getting there and having no Qt3 based apps in the default install at all will be one of our goals for next release: http://en.opensuse.org/KDE/Ideas/11.2 Bye, Steve -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 08 January 2009 22:07:06 Herbert Graeber wrote:
Am Donnerstag 08 Januar 2009 21:35:35 schrieb Larry Stotler:
On Thu, Jan 8, 2009 at 2:21 PM, Matt Sealey
wrote: [...] , 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.
The reason that qt3 is loaded is because some of the KDE programs aren't yet qt4, so you need to have that to run those programs. IF all you programs are qt4, you should be abel to remove it tho.
Even parts of YaST still use qt3 with kde3 themes and therefore kdelibs3.
The only part is YaST Control Center, which did not make it to Qt4 yet. But it's a priority for us to move it - you can see a lot of discussions around what to do on that front. But even current control center does not need kdelibs at all. Stano -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 09 January 2009 03:57:09 Larry Stotler wrote:
On Thu, Jan 8, 2009 at 7:02 PM, Rob OpenSuSE
wrote: Why? With KDE4 plus Firefox 512MB RAM was perfectly adequate in my testing. In fact it is very hard to get the VM to use swap space at all, without increasing the default value of "swapiness"; which I think shows the default is poorly chosen.
Agreed. Those who make comments like that evidently don't have an older system, or if they do, don't use it. I regularly run on older hardware with few issue. Granted, it's not as fast as my 64bit machines, but why should I spend $$ I don't have to upgrade? The economy is not that great now, and it can be more expensive to upgrade an older system than a newer one.
There's no reason to tell ppl to not use old machines, just because you'ld not spec out such a machine for desktop. 256MB RAM is plenty for many SOHO server applications.
I run a server with 128MB. It don't need much to just serve up files.
I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts: http://smolts.org/static/stats/stats.html Stano -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/9 Stanislav Visnovsky
On Friday 09 January 2009 03:57:09 Larry Stotler wrote:
I run a server with 128MB. It don't need much to just serve up files.
I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts:
Noone's asked for desktop to be optimised to 256MB RAM, it's the word "requirement" and 1GB figure that looked like a very bad idea to me. Precisely because of SOHO server applications, and least according to most Internet pundits "it will never be the year of Linux on the destkop" so we shouldn't forget non-GUI server side :) Firefox 3 seems to have beneffitted a lot from the work to reduce memory consumption. I've noticed it on a machine with 4GB RAM (despite having AMD dual channel non-FSB memory controller), and the result is much more pleasant, than the flabby feel of the older version. Years ago memory access on first micro I used, was 1 or 2 CPU cycles. Now we have new chips with L3 caches taking 45 cycles, and system memory a lot more (100+?); so the old "memory is cheap and fast" meme doesn't hold so well now, even though memory is cheap, and faster thand it used to be, compared to processing speed increase it has lagged.
openSUSE and Linux's RAM needs have really gotten out of hand lately. I was running 10.2 on a PowerMac 7500/G4/700 with 256MB with no problem. Now I need 512 or it's slow as molasses. Not a good trend
To me Qt4 & KDE4 don't seem to have blown up memory requirements. Firefox 3 is working with less. But I can only compare 10.3 requirements on i686 with 11.1, not 10.2 directly. So am I the only who wonders about an issue under Power arch, or simple configuration issues like desktop search, despite fact that 512MB RAM is clearly a more sensible system size than 256MB? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 3:49 AM, Stanislav Visnovsky
I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts:
Not sure what I'm supposed to do with that site. And, the stats are way off. 19% running 11.1 and 0 running 11.0/i586???? Seems like a lot of people have no idea either. It looks like a Fedora specific site anyway. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 09 janvier 2009, à 09:11 -0500, Larry Stotler a écrit :
On Fri, Jan 9, 2009 at 3:49 AM, Stanislav Visnovsky
wrote: I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts:
Not sure what I'm supposed to do with that site. And, the stats are way off. 19% running 11.1 and 0 running 11.0/i586???? Seems like a lot of people have no idea either. It looks like a Fedora specific site anyway.
See http://en.opensuse.org/Hardware/Smolt It's not fedora-specific and openSUSE started using this with 11.1, so the figures for 11.0 are expected. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 09 January 2009 15:11:09 Larry Stotler wrote:
On Fri, Jan 9, 2009 at 3:49 AM, Stanislav Visnovsky
wrote: I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts:
Not sure what I'm supposed to do with that site. And, the stats are way off. 19% running 11.1 and 0 running 11.0/i586???? Seems like a lot of people have no idea either. It looks like a Fedora specific site anyway.
You should submit your hardware information to it so that we can see what kind of systems our users use. It's started by Fedora but used by openSUSE as well - starting basically with 11.1, so no wonder that there's not much for 11.0. Please read: http://zonker.opensuse.org/2008/12/22/reminder-to-smolt-we-want-your-hardwar... profiles/ http://en.opensuse.org/Smolt Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Friday 09 January 2009, Larry Stotler wrote:
On Fri, Jan 9, 2009 at 3:49 AM, Stanislav Visnovsky
wrote: I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts:
Not sure what I'm supposed to do with that site. And, the stats are way off. 19% running 11.1 and 0 running 11.0/i586???? Seems like a lot of people have no idea either. It looks like a Fedora specific site anyway. With 11.0 we had smolt but very well hidden. With 11.1 everybody is asked to send hw info to smolt. That's why there is such a huge difference between 11.0 and 11.1.
Smolt is at its beginning but it has the power to improve hardware support for Linux in general as its the first place where hw info is displayed publicly based on a very large user base. M -- Michael Löffler, Product Management SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2009-01-09 at 09:11 -0500, Larry Stotler wrote:
On Fri, Jan 9, 2009 at 3:49 AM, Stanislav Visnovsky
wrote: I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts:
Not sure what I'm supposed to do with that site. And, the stats are way off. 19% running 11.1 and 0 running 11.0/i586???? Seems like a lot of people have no idea either. It looks like a Fedora specific site anyway.
You're supposed to use the site to see how many registered installs there are, what hardware is being used, etc. As a user you can submit your hardware profile and actually add comments/tip/tricks/etc to the hardware and also mark items as working with no issue, working with a bit of magic or just not working [0]. There will be a huge difference between 11.0 and 11.1 as openSUSE had only begun talks with Fedora about joining in and helping out after 11.0's release. Yes this is a project that was started by Fedora, but we (the openSUSE project) can see the benefit in it and are happy and willing to join in. There have been multiple posts since last summer about Smolts [0], [1], [2] and as with everything it takes time and effort to get the word spread about something good, unfortunately bad things tend to be known much much faster :-/ A good way to follow what's going on is to keep an eye on PlanetSUSE, most interesting items pop up there ;-) [0] = http://www.wafaa.eu/index.php?/archives/153-Smolt-your-Hardware.html [1] = http://zonker.opensuse.org/2008/12/11/dont-forget-to-smolt/ [2] = http://zonker.opensuse.org/2008/12/22/reminder-to-smolt-we-want-your-hardwar... -- Andrew Wafaa, openSUSE Member: FunkyPenguin. openSUSE: Get It, Discover It, Create It at http://www.opensuse.org awafaa@opensuse.org | http://www.wafaa.eu -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi :) El Friday 09 January 2009, Michael Loeffler escribió:
On Friday 09 January 2009, Larry Stotler wrote:
On Fri, Jan 9, 2009 at 3:49 AM, Stanislav Visnovsky
wrote:
I hope you've sent your hardware profile via smolt. I'm pretty sure the numbers there are the one people will look at when thinking about where to put the optimization efforts:
Not sure what I'm supposed to do with that site. And, the stats are way off. 19% running 11.1 and 0 running 11.0/i586???? Seems like a lot of people have no idea either. It looks like a Fedora specific site anyway.
With 11.0 we had smolt but very well hidden. With 11.1 everybody is asked to send hw info to smolt. That's why there is such a huge difference between 11.0 and 11.1.
Smolt is at its beginning but it has the power to improve hardware support for Linux in general as its the first place where hw info is displayed publicly based on a very large user base.
Does smolt distinguish between two different computers and two installations (reinstallation, for example) of the same computer? I ask this because I have different scenarios: 1.- say you install openSUSE 11.1 and then you reinstall because you goofed up. Would that count as 1 installation and smolt would not resend the info? Or does smolt count that as 2 different systems and resends the info as if it were a different computer? 2.- Say you were a Fedora user and you added your computer to the smolt statistics. A couple of months later you discover openSUSE, get rid of Fedora never to go back and install openSUSE 11.1. Would that also be counted as a new computer? 3.- What if you have a partition with openSUSE 11.0 from which you've already run smolt and decide to upgrade to 11.1? Is that a new computer added to the smolt statistics? 4.- What if you have 1 partition with openSUSE 11.0 with which you sent all the info to smolt web and you install openSUSE 11.1 on another partition and all the info gets sent back to smolt's web. Is that counted as a new/another different computer? Been looking for the answers to these questions on smolt's web but haven't found it. Maybe looking in the wrong place? Any ideas? TIA Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 9:22 AM, Andreas Jaeger
You should submit your hardware information to it so that we can see what kind of systems our users use.
Good idea
It's started by Fedora but used by openSUSE as well - starting basically with 11.1, so no wonder that there's not much for 11.0.
Ah.. However, I can't figure out what I'm supposed to do on that site. It's not very user friendly because I haven;t found a way to add my info...... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2009-01-09 at 10:48 -0500, Larry Stotler wrote:
On Fri, Jan 9, 2009 at 9:22 AM, Andreas Jaeger
wrote: You should submit your hardware information to it so that we can see what kind of systems our users use.
Good idea
It's started by Fedora but used by openSUSE as well - starting basically with 11.1, so no wonder that there's not much for 11.0.
Ah.. However, I can't figure out what I'm supposed to do on that site. It's not very user friendly because I haven;t found a way to add my info......
You shouldn't have to do anything. Upon installation of 11.1, and the subsequent first update, smolt should automatically do the process for you. That's what happened with both of my machines. Did you not see a smolt notification when you did your first system update? -- Bryen Yunashko openSUSE Board Member -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 5:30 AM, Rob OpenSuSE
Noone's asked for desktop to be optimised to 256MB RAM, it's the word "requirement" and 1GB figure that looked like a very bad idea to me. Precisely because of SOHO server applications, and least according to most Internet pundits "it will never be the year of Linux on the destkop" so we shouldn't forget non-GUI server side :)
I could care less about Linux on anyone else's desktop, so long as it works on mine. I gave up trying to enlighten people a long time ago. I just charge them to fix their broken WinDoZe now.
Firefox 3 seems to have beneffitted a lot from the work to reduce memory consumption. I've noticed it on a machine with 4GB RAM (despite having AMD dual channel non-FSB memory controller), and the result is much more pleasant, than the flabby feel of the older version.
I dunno. I do know that on my Thinkpad A22p with a P3/1Ghz and 256MB RAM, that Firefox takes up about 200MB after opening 1/2 a dozen tabs, and that I use about 200MB of my swap. And, the machine has a bad RAM slot. I'm going to try a 512MB chip at some point, but the machine is only supposed to support 256MB modules.
Years ago memory access on first micro I used, was 1 or 2 CPU cycles. Now we have new chips with L3 caches taking 45 cycles, and system memory a lot more (100+?); so the old "memory is cheap and fast" meme doesn't hold so well now, even though memory is cheap, and faster thand it used to be, compared to processing speed increase it has lagged.
Yeah, I've read about that. Adding the L3 isn't the boost that they've tried to make it out to be.
To me Qt4 & KDE4 don't seem to have blown up memory requirements. Firefox 3 is working with less. But I can only compare 10.3 requirements on i686 with 11.1, not 10.2 directly. So am I the only who wonders about an issue under Power arch, or simple configuration issues like desktop search, despite fact that 512MB RAM is clearly a more sensible system size than 256MB?
10.2 ran great on older PowerMacs with 256MB. 11.0 seemed to be slower, but it got better after an upgrade to 512MB. I actually have a gig in my 9600, but it's not being used right now. I have an old PowerBook 3400c that I finally upgraded to the max of 144MB, and a PowerMac 6500 with a max of 128MB. So, I don't expect these lower end systems to work(I wish I could get a PPC version of Damn Small....). However, my 9600 with a G4/700 and 1GB shouldn't be slower than my Dell Dual Xeon 500Mhz with 512MB. However, these old workhorses seem to be getting left behind by the major distros because of all the new "features" being added like the glitz and search tools and stuff. Search tools should NOT be enabled by default. I work at a computer shop, and I am constantly removing google search and all the others because they get install and NEVER used, and they slow the computers down. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 10:54 AM, Bryen
You shouldn't have to do anything. Upon installation of 11.1, and the subsequent first update, smolt should automatically do the process for you. That's what happened with both of my machines. Did you not see a smolt notification when you did your first system update?
No. I've only got 1 machine with a 11.1 install, and I got TinyWM instead of KDE3. So, I haven't bothered to fix it yet. I have a dozen machines running linux, and since I don't intend to use 11.1 as a production version anytime soon, I guess I won't be able to give them my info. That doesn't help to say the least. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 9:54 AM, Rafa Grimán
Been looking for the answers to these questions on smolt's web but haven't found it. Maybe looking in the wrong place? Any ideas?
Their wiki is broken when I try to go there as well. Oh well. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le vendredi 09 janvier 2009, à 10:57 -0500, Larry Stotler a écrit :
On Fri, Jan 9, 2009 at 10:54 AM, Bryen
wrote: You shouldn't have to do anything. Upon installation of 11.1, and the subsequent first update, smolt should automatically do the process for you. That's what happened with both of my machines. Did you not see a smolt notification when you did your first system update?
No. I've only got 1 machine with a 11.1 install, and I got TinyWM instead of KDE3. So, I haven't bothered to fix it yet. I have a dozen machines running linux, and since I don't intend to use 11.1 as a production version anytime soon, I guess I won't be able to give them my info.
You can simply run the smoltGui or smoltSendProfile command. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 11:04 AM, Vincent Untz
You can simply run the smoltGui or smoltSendProfile command.
Had to install it on my server here at work. It had 4 dependencies as well, which I will have to remove now since I only needed them for this one program 1 time.....They need to compact it more. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 9 Jan 2009, Bryen wrote:
On Fri, 2009-01-09 at 10:48 -0500, Larry Stotler wrote:
On Fri, Jan 9, 2009 at 9:22 AM, Andreas Jaeger
wrote: You should submit your hardware information to it so that we can see what kind of systems our users use.
Good idea
It's started by Fedora but used by openSUSE as well - starting basically with 11.1, so no wonder that there's not much for 11.0.
Ah.. However, I can't figure out what I'm supposed to do on that site. It's not very user friendly because I haven;t found a way to add my info......
You shouldn't have to do anything. Upon installation of 11.1, and the subsequent first update, smolt should automatically do the process for you. That's what happened with both of my machines. Did you not see a smolt notification when you did your first system update?
I never have seen any messages, but all my installs have been network
without internet access. The updates come from the update directory I
have on the external 512 GB drive. I plug it in nightly and update it.
--
Boyd Gerber
On Fri, Jan 9, 2009 at 9:55 AM, Larry Stotler
On Fri, Jan 9, 2009 at 5:30 AM, Rob OpenSuSE
wrote: Damn Small....). However, my 9600 with a G4/700 and 1GB shouldn't be slower than my Dell Dual Xeon 500Mhz with 512MB.
Really? I would say it would just nip it. The G4 is a wonderful chip but it's not a server-class SMP system.
workhorses seem to be getting left behind by the major distros because of all the new "features" being added like the glitz and search tools and stuff.
I don't think the glitz OR search tools are too much of a problem. The disk activity goes up, and use some CPU time, and when that's ocurring it's usually during an idle spot. It has some implications for power management - I'm not sure indexing stops when a system is on batteries - what I object to is stuff like Beagle, which is an absolute monster. C# apps take up way too much memory and ran far slower on PowerPC than I would have expected from the fact that Mono has an officially supported runtime. The soaking up memory part is the main point though; having search tools pushing memory usage so much is really infuritating. Especially since absolutely none of them are as good as Google Desktop (to be fair, I didn't install Google Desktop for Linux yet because I don't actually have an x86 Linux box with a desktop to install it to. Even if I did though would I get the same integration into the GNOME menu etc.? Whatever happened to Strigi? That was supposed to be the saving grace of desktop-independent searches. KDE includes it by default now because it needs it.. but I still got Beagle for my troubles. I also thought I saw Strigi was in the plan for 11.1, but I didn't see any reasons why it never got there. Not enough features? I know Novell sponsors Mono, but really.. Beagle sucks.
Search tools should NOT be enabled by default. I work at a computer shop, and I am constantly removing google search and all the others because they get install and NEVER used, and they slow the computers down.
Do you ask your customers before you do this?
I use Google Desktop all the time, in fact I'd not know what to do
without it. I make sure all my systems are reporting to my Google
account, so when I search, it tells me which machine it's actually
on.. I'd be more than pissed off if you removed it from MY computer.
--
Matt Sealey
On Fri, Jan 9, 2009 at 4:30 AM, Rob OpenSuSE
Years ago memory access on first micro I used, was 1 or 2 CPU cycles. Now we have new chips with L3 caches taking 45 cycles, and system memory a lot more (100+?); so the old "memory is cheap and fast" meme doesn't hold so well now, even though memory is cheap, and faster thand it used to be, compared to processing speed increase it has lagged.
I'm not sure I agree with you here. Memory is cheap and fast, but CPU
cycles have gotten shorter. 11 cycles on a QDR 800MHz bus goes much
faster than 2 cycles on a 33Mhz bus, if it was even that. Even 140
cycles to main memory is faster. And once you get over the latency,
the data is burst in and cached for longer.
Access *times* are ~10 to ~100 times better than they were when you
remember. Don't think of them in cycles, because bus speeds change.
Think of them as a proportion of your total CPU speed and against your
total memory bus speed (be it an internal controller or a FSB).
My problem with MY systems is, I have a 128MB box I want to run a
desktop on, and the system is NOT upgradable. However it's nice, fast
DDR2 (but no L2 to back it up, poor little embedded processors..) and
is still a hell of a lot faster doing random memory accesses with
badly formatted data than old micros that did memory accesses in 2
cycles.
--
Matt Sealey
On Fri, Jan 9, 2009 at 2:14 AM, Stephan Binner
On Thursday, 8. January 2009 20:21:15 Matt Sealey wrote:
If you just want Marble you had to install the entirity of kdeedu.
Marble was never part of kdeedu3. </nitpick>
I'm sure it was still part of kdeedu4 on some distributions.
Now it's all seperate in 11.1.
Not gnome-games
...
:D
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.
It was more "no Qt3 based apps running by default on KDE4 desktop" and we admittedly failed to achieve that goal (knetworkmanager).
Yeah I noticed that. Shame. For 11.2 though right?
and having no Qt3 based apps in the default install at all will be one of our goals for next release: http://en.opensuse.org/KDE/Ideas/11.2
So KNetworkManager and YaST2 Control Center need moving across. What
else? I notice it says in the ideas list that "no KDE3 libs in the
default distro, except of" (this is bad english btw :) kdelibs3,
kdebase3-runtime, kdevelop3, quanta. Okay so that's all to support
kdevelop3, because kdevelop4 really isn't ready.. but does that mean
those parts are going to be installed by default, or just in the repo
as dependencies for kdevelop?
I'll throw in some feature ideas at the weekend as I have a ton of
nitpicks about KDE4 stuff in SuSE.. however I realise right now, all
my systems are sitting on GNOME which sort of sucks for verifying
stuff. Are you using that page for lengthy diatrib^H^H^H^H^H umm..
discussion? Or just single lines of "this would be good"?
Is there a GNOME version of that page?
--
Matt Sealey
Il venerdì 09 gennaio 2009, Stephan Binner scrisse:
It was more "no Qt3 based apps running by default on KDE4 desktop" and we admittedly failed to achieve that goal (knetworkmanager). Getting there and having no Qt3 based apps in the default install at all will be one of our goals for next release: http://en.opensuse.org/KDE/Ideas/11.2 I hope that Quanta and K3b will be ready fo that time.. Well, Quanta is not in default installation but k3B... Bye.
-- *** Linux user # 198661 ---_ ICQ 33500725 *** *** Home http://www.kailed.net *** *** Powered by openSUSE *** -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 1:20 PM, Matt Sealey
Really? I would say it would just nip it. The G4 is a wonderful chip but it's not a server-class SMP system.
Why need a server class system? That's a little overkill. faster P3 and G4 systems are still viable machines, especially when running Linux. I write articles for a Mac site(when I have the time), and refurbishing and using older hardware is what it's all about.
I don't think the glitz OR search tools are too much of a problem. The disk activity goes up, and use some CPU time, and when that's ocurring it's usually during an idle spot. It has some implications for power management - I'm not sure indexing stops when a system is on batteries - what I object to is stuff like Beagle, which is an absolute monster. C# apps take up way too much memory and ran far slower on PowerPC than I would have expected from the fact that Mono has an officially supported runtime.
I don't use any of that. Have no need for them. And, when you are on older hardware with older video chips, glitz steals cpu power.
Do you ask your customers before you do this?
Yep. And they are like "what's that?" Haven't had one in 6 months that knew what it was or where it came from.
I use Google Desktop all the time, in fact I'd not know what to do without it. I make sure all my systems are reporting to my Google account, so when I search, it tells me which machine it's actually on.. I'd be more than pissed off if you removed it from MY computer.
But, that makes you the EXCEPTION. Also, I check for activity and install date. If it's never ran, then it's not being used. That's easy enough to determine. Perhaps more people would use it if they really understood what they were installing. It's like all those useless toolbars that get installed if you don't check to see what's being installed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 09 January 2009 11:28:28 am Boyd Lynn Gerber wrote: ...
I never have seen any messages, but all my installs have been network without internet access. The updates come from the update directory I have on the external 512 GB drive. I plug it in nightly and update it.
The smoltGui that is started by updater will not give you a password that you need to change uploaded profile and mark what works and to what extent. See: http://en.opensuse.org/Smolt for details. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 09 January 2009 08:54:44 am Rafa Grimán wrote:
Hi :)
...
Does smolt distinguish between two different computers and two installations (reinstallation, for example) of the same computer?
I ask this because I have different scenarios:
1.- say you install openSUSE 11.1 and then you reinstall because you goofed up. Would that count as 1 installation and smolt would not resend the info? Or does smolt count that as 2 different systems and resends the info as if it were a different computer?
2.- Say you were a Fedora user and you added your computer to the smolt statistics. A couple of months later you discover openSUSE, get rid of Fedora never to go back and install openSUSE 11.1. Would that also be counted as a new computer?
3.- What if you have a partition with openSUSE 11.0 from which you've already run smolt and decide to upgrade to 11.1? Is that a new computer added to the smolt statistics?
4.- What if you have 1 partition with openSUSE 11.0 with which you sent all the info to smolt web and you install openSUSE 11.1 on another partition and all the info gets sent back to smolt's web. Is that counted as a new/another different computer?
Been looking for the answers to these questions on smolt's web but haven't found it. Maybe looking in the wrong place? Any ideas?
When you run smolt it will create unique ID in /etc/smolt . If it is deleted them machine will be counted again. To remedy this as much as possible they count, for statistics page, only last 90 days. The project is still in development and ideas how to work around problems are welcome. See: http://en.opensuse.org/Smolt for details. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/9 Matt Sealey
On Fri, Jan 9, 2009 at 4:30 AM, Rob OpenSuSE
wrote: Years ago memory access on first micro I used, was 1 or 2 CPU cycles. Now we have new chips with L3 caches taking 45 cycles, and system memory a lot more (100+?); so the old "memory is cheap and fast" meme doesn't hold so well now, even though memory is cheap, and faster thand it used to be,
compared to processing speed increase it has lagged.
^^^^^^^^^^^^^ see relative comparision
I'm not sure I agree with you here. Memory is cheap and fast, but CPU cycles have gotten shorter. 11 cycles on a QDR 800MHz bus goes much faster than 2 cycles on a 33Mhz bus, if it was even that. Even 140 cycles to main memory is faster. And once you get over the latency, the data is burst in and cached for longer.
On old systems, bloat was causing a few megabytes of extra memory access, now it can be 100-400MB. And it's no 11 cycles, but CPUs wait 100's on cache misses, never mind if there's a page fault and disk access involved. In relative terms, memory has become slower, so even on systems which never have memory pressure, you don't want your desktop programs to all presume they can use major chunks of physical memory, as if they had system all to themselves. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 9, 2009 at 1:01 PM, Larry Stotler
On Fri, Jan 9, 2009 at 1:20 PM, Matt Sealey
wrote: Really? I would say it would just nip it. The G4 is a wonderful chip but it's not a server-class SMP system.
Why need a server class system?
I never said you needed one. A Dual Xeon was compared to a G4. They're not comparable in the same way you wouldn't compare a Celeron to a Xeon these days.
I don't use any of that. Have no need for them. And, when you are on older hardware with older video chips, glitz steals cpu power.
If you're on older hardware with older video chips the glitz never gets enabled in the first place - certainly nothing like Compiz and if you mean stuff like Plasma does on KDE.. I have that running on a 400MHz G2_LE core with 128MB. It runs pretty well if you trim the system first. This is an extreme case... it requires a hell of a lot of work but it's definitely possible to knock KDE4 down so it's basically featureless (exactly like you want it) with barely anything done on startup except get into X and start networking. Of course it's crippled the moment you start OpenOffice or so..
I use Google Desktop all the time
But, that makes you the EXCEPTION.
I really think more people than me actually use Google Desktop.
--
Matt Sealey
On Fri, Jan 9, 2009 at 8:37 PM, Rob OpenSuSE
2009/1/9 Matt Sealey
: On Fri, Jan 9, 2009 at 4:30 AM, Rob OpenSuSE
wrote: I'm not sure I agree with you here. Memory is cheap and fast, but CPU cycles have gotten shorter. 11 cycles on a QDR 800MHz bus goes much faster than 2 cycles on a 33Mhz bus, if it was even that. Even 140 cycles to main memory is faster. And once you get over the latency, the data is burst in and cached for longer.
On old systems, bloat was causing a few megabytes of extra memory access, now it can be 100-400MB. And it's no 11 cycles, but CPUs wait 100's on cache misses, never mind if there's a page fault and disk access involved.
In relative terms, memory has become slower, so even on systems which never have memory pressure, you don't want your desktop programs to all presume they can use major chunks of physical memory, as if they had system all to themselves.
You're talking a lot of crap, frankly.
You can't possibly think that memory access latency has increased
compared to the processors you used to use. In relative terms, what is
that supposed to mean? Try measuring memory access latency against
clock speed in relative terms. A 1MHz 6502 taking 1 or 2 cycles to
access main memory is not faster relatively than a 1.8GHz Core 2 Duo
taking 14 or 15 cycles to access L2 cache, and still not faster than
taking ~150 to access main memory on the event of a cache miss. And
the result of a cache miss and the overhead involved outside of the
actual access latency is NOT something you can criticize. It gives
far, far more benefits than having no cache at all.
Yes, I agree with you about bloat, but while memory access hasn't
scaled with processor speed, it is certainly not "relative slower"
than it was 10 years ago.
--
Matt Sealey
On Wed, Dec 17, 2008 at 8:25 AM, Birger Kollstrand
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.
I had a thought. Debian, Ubuntu and Mandriva have all adopted "dash"
(Debian Almquist Shell) as their default "sh" for booting and even
have a static version which is absolutely tiny (compare bash which has
many dependencies and the basic binary is 800k, dash statically linked
is the same size, dynamically linked is 120k or less). This does a lot
to speed up booting when used for things like udev and rc.d scripts -
on the proviso that none of these scripts require any bash-specific
scripting. The same might go for complex RPM building :]
Debian is helped here because it's policy to have strictly POSIX
compliant init scripts etc., but I don't know what the SUSE policy
is... does anything in SUSE still absolutely require bash?
On my Efika and Pegasos I've seen boot speed improvements (sorry, lost
the boot charts, and it was ~18 months ago) of something like 3-4
seconds at the *worst* case. Shaving microseconds off I might have
written off but the fact that it is something like 1/10th of the boot
time on my system makes a difference (it still won't boot in 30
seconds, but.. that's what our internal kernel-genesi project is for
:)
What about including the sreadahead patch and tools to efficiently
readahead blocks which are loaded at boot? My system actually boots
FASTER without the traditional "preload" running, plus preloading the
traditional way (entire files) soaks up a hell of a lot of
buffer/cache space, when really all you need is the blocks the boot
process touched.
What about taking a further hint from the Intel "5 second boot" guys
and further optimizing the boot process? It needn't be as frugal as
the one in the EeePC demo, it may still load a splash screen (which
takes ages but.. is pretty. Fedora's splash even got more complicated
and animated..) and do some things here and there, but the idea of a
static /dev which is used to bring the system up, get DBus and GDM/KDM
running, and THEN start hal, udev and the like is a great one. Since X
supports hotplug input devices, the mouse and keyboard will magically
start working at the point the system is ready to log in (at which
point it can start setting up networking - OR perhaps leave that for
AFTER login like Windows does).
Not looking for a 5 or even 10 seconds boot, but a 20 second one to a
usable, and almost-ready login prompt would be awesome.
The other thing would be, and this is a silly feature, why not have a
kernel-vmware or kernel-virtualbox which only included the basic
drivers which these virtual machines support, throws away the io
schedulers (since on a virtual machine with a virtual disk, io
reordering is completely pointless) and other framebuffer drivers
etc.? It's kind of silly to be throwing in every libata driver and
block driver and hundreds of PCI card and PCMCIA card drivers when the
VM is completely fixed function within a very limited number of
configurations - even VirtualBox and VMware share a bunch of emulated
hardware now. About all you need is a set of USB modules, and
everything else can be made static. When you're running on a memory
limited machine (for instance I have a couple boxes with 1GB which I
run 256MB VMs in), saving a couple megabytes on the kernel and initrd
(and boot time because nothing needs to come out of the initrd - a tip
from the 5 second boot guys) might make that tiny bit of difference,
with a view to the fancy new virtual appliance markets, getting
systems back up and running faster on failure, etc.
--
Matt Sealey
2009/1/10 Matt Sealey
On Fri, Jan 9, 2009 at 8:37 PM, Rob OpenSuSE
wrote: 2009/1/9 Matt Sealey
: On Fri, Jan 9, 2009 at 4:30 AM, Rob OpenSuSE
wrote:
You're talking a lot of crap, frankly.
As you've become rude, I'll just suggest you clue up by finding some CPU architecture explanations. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Jan 10, 2009 at 12:12 AM, Matt Sealey
I never said you needed one. A Dual Xeon was compared to a G4. They're not comparable in the same way you wouldn't compare a Celeron to a Xeon these days.
In a way. The Xeon's major advantage is the dual cpus and 100Mhz fsb. However, the G4 is touted as being faster than the P3, so it's not too off. Besides, a dual 500 is comparable to a 750Mhz chip in many ways, so it's not that far off. The big disadvantage is the G4's 50Mhz memory bus.
If you're on older hardware with older video chips the glitz never gets enabled in the first place - certainly nothing like Compiz and if you mean stuff like Plasma does on KDE.. I have that running on a 400MHz G2_LE core with 128MB. It runs pretty well if you trim the system first. This is an extreme case... it requires a hell of a lot of work but it's definitely possible to knock KDE4 down so it's basically featureless (exactly like you want it) with barely anything done on startup except get into X and start networking.
Which shows me it's just not a compelling alternative. The devs seems to have fallen into the "it's there, let's waste it" trap. They have forgotten their roots so to speak. While I don't have a problem targeting new users, I don't think it should be done at the expense of the "old timers" like me. I have seen no real features I care for in KDE4, and KDE3 is more stable. Maybe KDE4 will get there. I have requested that KPersonalizer get ported to qt4 so we can have a way to turn off all those useless(to me) desktop effects.
Of course it's crippled the moment you start OpenOffice or so..
Which is why I don't use it and don't recommend it. KOffice works much better and does everything I need. Heck, I do just fine with Wordpad in WinDoZe.
I really think more people than me actually use Google Desktop.
Never meant that, but my experience has shown that the majority of my customers don't use it even though it got snuck in on them. Same with Windows Search. I disable the install ask, especially on slow systems. If they want it, they can install it. I've seen it and Google Search bring a system to it's knees just like beagle. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/10 Larry Stotler
On Sat, Jan 10, 2009 at 12:12 AM, Matt Sealey
wrote:
of work but it's definitely possible to knock KDE4 down so it's basically featureless (exactly like you want it) with barely anything done on startup except get into X and start networking.
Which shows me it's just not a compelling alternative. The devs seems to have fallen into the "it's there, let's waste it" trap. They have
Actually Qt4 and KDE4 have not increased memory consumption particularly according to my observations. There has been stuff added which is a matter of configuration. 11.1 just has a lot of issues right now, but testing pre-release on even 8 yr old hardware, I had acceptable performance for occasional desktop use. Alot of ppl with much newer machines have complained of performance problems, so I think such a sweeping generalisation as the "it's there, let's waste it" trap comment, is as erroneous as the 1GiB RAM requirement. There's a trend to more power efficient devices, that may be encouraging developers not to use memory naively. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
The other thing would be, and this is a silly feature, why not have a kernel-vmware or kernel-virtualbox which only included the basic drivers which these virtual machines support, throws away the io schedulers (since on a virtual machine with a virtual disk, io reordering is completely pointless) and other framebuffer drivers etc.
This is a great idea, makes lots of sense. Erik. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On old systems, bloat was causing a few megabytes of extra memory access, now it can be 100-400MB. And it's no 11 cycles, but CPUs wait 100's on cache misses, never mind if there's a page fault and disk access involved.
In my experience, it takes 2 generation of software to get things right. These days, you are not going to ask a developer to program in assembler just to get the most optimal memory allocation. The complexity of the desktop environments is going to grow constantly, and this is not a trend one can fight. Same for the underlying technologies, I don't think the devs see too much the memory consumption, many of it is hidden in all the frameworks involved. And often the first generation of a piece of software will focus on functionality and stability, and it takes another generation to profile and optimize. Erik. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jan 11, 2009 at 01:45:27AM -0500, Putrycz, Erik wrote:
The other thing would be, and this is a silly feature, why not have a kernel-vmware or kernel-virtualbox which only included the basic drivers which these virtual machines support, throws away the io schedulers (since on a virtual machine with a virtual disk, io reordering is completely pointless) and other framebuffer drivers etc.
This is a great idea, makes lots of sense.
The kernel-...-base packages are targeted for this use. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/11 Putrycz, Erik
On old systems, bloat was causing a few megabytes of extra memory access, now it can be 100-400MB. And it's no 11 cycles, but CPUs wait 100's on cache misses, never mind if there's a page fault and disk access involved.
In my experience, it takes 2 generation of software to get things right.
Someone has experessed the opinion that memory consumption is escalating.
From what I can see Qt4/KDE4 combo, uses a little less memory than the same OS running Qt3/KDE3. Similarly Firefox 3, is using less memory than FF2.
So actually the developers seem to be doing a good job, they're not going the "Bloaty Vista" route, but trying to keep things efficient, because of experience in previous generation of systems. This has paid off in the fastest growing areas, which are the low power consumption, lower peformance machines. The point about memory being relatively slower than it used to be, means cache misses are relatively greater penalties, and that the optimisation work than went into FF3 for example, is very perceptible even on systems with plenty of RAM. RAM size is not, the only thing that determines good peformance, diminishing returns set in, and IMO the general PC press haven't caught up with that yet. Good code is important. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/11 Marcus Meissner
On Sun, Jan 11, 2009 at 01:45:27AM -0500, Putrycz, Erik wrote:
The other thing would be, and this is a silly feature, why not have a kernel-vmware or kernel-virtualbox which only included the basic drivers which these virtual machines support, throws away the io schedulers (since on a virtual machine with a virtual disk, io reordering is completely pointless) and other framebuffer drivers etc.
This is a great idea, makes lots of sense.
The kernel-...-base packages are targeted for this use.
Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments? It's not clear to me what "targeted for this use" means in this context. When I last looked at this (over a year ago), I actually found it simpler to use a Debian install, and Virtual Box for example, liked HZ to be 100, rather than 250 or 1,000. There may have been a few other tweaks. Since then it's become easier to have a minimal openSUSE install, but also to make a 'spin' of openSUSE that would be tailored to a virtual environment. Perhaps this would be a good area of a 'contrib' project, like the 11.1 KDE 3 LIve CD and USB. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jan 11, 2009 at 04:07:25PM +0000, Rob OpenSuSE wrote:
2009/1/11 Marcus Meissner
: On Sun, Jan 11, 2009 at 01:45:27AM -0500, Putrycz, Erik wrote:
The other thing would be, and this is a silly feature, why not have a kernel-vmware or kernel-virtualbox which only included the basic drivers which these virtual machines support, throws away the io schedulers (since on a virtual machine with a virtual disk, io reordering is completely pointless) and other framebuffer drivers etc.
This is a great idea, makes lots of sense.
The kernel-...-base packages are targeted for this use.
Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments?
Yes, it can be used that way. But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :) But for KVM or Xen, this package should work. If not, please let us know. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 2009-01-11 at 15:56 +0000, Rob OpenSuSE wrote:
2009/1/11 Putrycz, Erik
: On old systems, bloat was causing a few megabytes of extra memory access, now it can be 100-400MB. And it's no 11 cycles, but CPUs wait 100's on cache misses, never mind if there's a page fault and disk access involved.
In my experience, it takes 2 generation of software to get things right.
Someone has experessed the opinion that memory consumption is escalating.
It wasn't me, but i've said it a number of times. I know that the price of mem and cpu is constantly dropping, but that should never be an excuse from a runaway OS-footprint. Some applications need much mem, No problem with that. And if you run a lot of them cocurrently, its your own fault. One of the problems was getting seriously at the 10.1 release, was that a number of nice applications were installed automatically. Thankfully this unrequested eyecandy is dropped, But it always remains a tradeoff between ease of installation for newbees, and the hassle of detecting and removing unwanted stuff. Even more when it is tangled with strange dependencies. Advertising all of the (new) eye-candy is nice, bluntly installing them is something else, not? hw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2009-01-09 at 10:48 -0500, Larry Stotler wrote:
Ah.. However, I can't figure out what I'm supposed to do on that site. It's not very user friendly because I haven;t found a way to add my info......
You should use the Smolt application on your computer to add your
info... if you use 11.1, you're asked to click a button on a
notification to do so upon first online update.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
On Sunday 11 January 2009 05:50:47 pm Kevin Dupuy wrote:
On Fri, 2009-01-09 at 10:48 -0500, Larry Stotler wrote:
Ah.. However, I can't figure out what I'm supposed to do on that site. It's not very user friendly because I haven;t found a way to add my info......
You should use the Smolt application on your computer to add your info... if you use 11.1, you're asked to click a button on a notification to do so upon first online update.
It will open Smolt GUI which will transfer information about hardware, but without information what works and what not. To edit that you need password which GUI doesn't provide yet. See http://en.opensuse.org/Smolt -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Jan 11, 5:50pm, Kevin Dupuy wrote: } Subject: Re: [opensuse-factory] Plan for 11.2?
On Fri, 2009-01-09 at 10:48 -0500, Larry Stotler wrote:
Ah.. However, I can't figure out what I'm supposed to do on that site. It's not very user friendly because I haven;t found a way to add my info......
You should use the Smolt application on your computer to add your info... if you use 11.1, you're asked to click a button on a notification to do so upon first online update.
I have two systems, an i586 Intel and x86_64 AMD, both updated ~weekly from factory since about 10.1 (using smart). I have never seen a request to use smolt until this thread. They're both now on 11.2a0. So I try it, and on both machines get this: (x86-64: bunch of file traces, then) File "/usr/lib64/python2.6/site-packages/urlgrabber/sslfactory.py", line 63, in create_opener return m2urllib2.build_opener(self.ssl_context, *handlers) File "/usr/lib64/python2.6/site-packages/M2Crypto/m2urllib2.py", line 112, in build_opener if inspect.isclass(check): NameError: global name 'inspect' is not defined or (i586: bunch of file traces, then) File "/usr/lib/python2.6/site-packages/urlgrabber/sslfactory.py", line 63, in create_opener return m2urllib2.build_opener(self.ssl_context, *handlers) File "/usr/lib/python2.6/site-packages/M2Crypto/m2urllib2.py", line 112, in build_opener if inspect.isclass(check): NameError: global name 'inspect' is not defined Happens with both gui and shell. I've not had a chance to examine it further. Anybody have a quick clue what might be wrong? Thanks, ~Steve -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 1/11/2009 at 5:38 PM, Greg KH
wrote: On Sun, Jan 11, 2009 at 04:07:25PM +0000, Rob OpenSuSE wrote: Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments? Yes, it can be used that way.
But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :)
Greg, I hope you're kidding ;) We have open-vm-tools KMPs in the distribution, which brings all the drivers for a VMware session you possibly might need. All nicely under GPL. Did I misunderstand your statement? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday, 9. January 2009 19:44:11 Matt Sealey wrote:
Marble was never part of kdeedu3. </nitpick> I'm sure it was still part of kdeedu4 on some distributions.
http://packages.opensuse-community.org/index.jsp?distro=openSUSE_103&searchTerm=marble
It was more "no Qt3 based apps running by default on KDE4 desktop" and we admittedly failed to achieve that goal (knetworkmanager). Yeah I noticed that. Shame. For 11.2 though right?
This follows from the goal of not having Qt3 on the Live-CD at all.
of our goals for next release: http://en.opensuse.org/KDE/Ideas/11.2 KNetworkManager and YaST2 Control Center need moving across. What else?
Read the page? :-)
but does that mean those parts are going to be installed by default, or just in the repo as dependencies for kdevelop?
Of course latter.
stuff. Are you using that page for lengthy diatrib^H^H^H^H^H umm.. discussion? Or just single lines of "this would be good"?
We will discuss them sometime in IRC meeting or on the mailing list.
Is there a GNOME version of that page?
http://en.opensuse.org/GNOME/Ideas and links Bye, Steve -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Dominique Leuenberger wrote:
On 1/11/2009 at 5:38 PM, Greg KH
wrote: On Sun, Jan 11, 2009 at 04:07:25PM +0000, Rob OpenSuSE wrote: Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments? Yes, it can be used that way. But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :)
Greg, I hope you're kidding ;)
We have open-vm-tools KMPs in the distribution, which brings all the drivers for a VMware session you possibly might need. All nicely under GPL.
Did I misunderstand your statement?
Dominique
I had some minor issues with open-vm-tools on 11.1 with VMware Workstation 6.5.1 and ended up having to use the proprietary ones that come with 6.5.1. I haven't had a chance to do the troubleshooting necessary to file a bug yet. But neither the open-vm-tools nor the VMware ones would do Unity mode when the guest was running 11.1 with a Gnome desktop, both of them would do Unity mode when the guest was running 11.1 with an XFCE desktop, but only the VMware-supplied version would do shared files with the host. -- M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM I've never met a happy clam. In fact, most of them were pretty steamed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jan 12, 2009 at 09:24:31AM +0100, Dominique Leuenberger wrote:
On 1/11/2009 at 5:38 PM, Greg KH
wrote: On Sun, Jan 11, 2009 at 04:07:25PM +0000, Rob OpenSuSE wrote: Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments? Yes, it can be used that way.
But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :)
Greg, I hope you're kidding ;)
About the virtualbox drivers? not at all.
We have open-vm-tools KMPs in the distribution, which brings all the drivers for a VMware session you possibly might need. All nicely under GPL.
Ah, sorry, I was confused, it's the vmware "host" side drivers that are still closed source. Those we can not redistribute. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 1/12/2009 at 5:24 PM, Greg KH
wrote: But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :) Greg, I hope you're kidding ;)
About the virtualbox drivers? not at all.
So you had quiet some fun reading them...
We have open-vm-tools KMPs in the distribution, which brings all the drivers for a VMware session you possibly might need. All nicely under GPL.
Ah, sorry, I was confused, it's the vmware "host" side drivers that are still closed source. Those we can not redistribute.
Actually even there I'm not so sure about the entire thing: to my understanding from several discussions (I'm active there a bit, as I'm packaging open-vm-tools, so things like this just raise) seems to be that the host part is almost identical, with very few exceptions. The module set is more or less the same; for Vsock there are other DEFINES used. I'm not sure though if vmware themself is interested in having the modules shipped by default, as their concern is giving 'power of updating' out of the hand. Now, with every release of vmware, they can ship a new module set. Having them upstreamed in the kernel would stop them from doing so (or adding them in the 'update' folder, but then newer kernel would be ignored... I think there is no feature to just load the 'newest' driver. So I'll start a discussion over at vmware, maybe for 11.2 we can actually get the support for the host also in (if license permits of course!) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 1/12/2009 at 4:24 PM, "M. Edward (Ed) Borasky"
wrote: I had some minor issues with open-vm-tools on 11.1 with VMware Workstation 6.5.1 and ended up having to use the proprietary ones that come with 6.5.1. I haven't had a chance to do the troubleshooting necessary to file a bug yet. But neither the open-vm-tools nor the VMware ones would do Unity mode when the guest was running 11.1 with a Gnome desktop, both of them would do Unity mode when the guest was running 11.1 with an XFCE desktop, but only the VMware-supplied version would do shared files with the host.
I would be quiet interested in this 'bug' report in this case. As I'm quiet involved in the packaging of the open-vm-tools, I have a personal interest of offering them 'bug-free'. So in short: Unity is the same with the open-vm-tools and the proprietary ones? Then there is probably no easy fix to them (maybe the latest open-vm-tools could help you... you find them in OBS Virtualization:VMware) And file sharing did not work? How did you try it? Accessing \\.host ? Mounting \\.host using vmhgfs? Drag'n'Drop of files? In which direction? From Host to Guest or vice versa? (All those questions I would also ask when you put it in Bugzilla.. so they are just in advance.. in case you can open a bug ticket of it :) ) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Jan 10, 2009 at 6:02 AM, Rob OpenSuSE
You're talking a lot of crap, frankly.
As you've become rude, I'll just suggest you clue up by finding some CPU architecture explanations.
Oh really? Wow. I didn't know I could spend 11 years designing and
implementing embedded systems on resource-constrained designs, and not
know a thing about how computars works! I will get right onto the
inter-tubes right away and find out more!!
Your little dissertation on how memory access has gotten slower
relative to older processors is naive at best, and wrong if you sat
down with a real chip and looked at it's real performance. A 100 cycle
latency for accessing memory on a cache miss - is not and cannot take
longer on a chip capable of running 3 billion cycles a second compared
to one which may only do 30 million or even 300 million with the same
latency. This is simple math; latency relative to cycles taken has
gone up (from 1 or 2 up to perhaps several hundred in designs like the
Pentium 4) but the data transfer capabilities of the memory
controller, the size of the L2 cache itself on these designs, means
that 1 cycle scaled up would take far longer a percentage.
I really do not see how you could equate, at a stab, a 30MHz processor
taking 20 cycles from a 16MHz, 16-bit memory bus being faster at
accessing memory than a 3GHz processor taking 200 cycles from a
1066Mhz 64-bit (or 128-bit) memory bus, even in relative terms, and
you can poke around with performance counters in x86 and PowerPC
processors and see this proved out in reality.
The "Finnish democoder competition" method of coding where every cycle
counts and everything has to load in 64k really won't make KDE run
faster, nor does it explain why increased USE of memory (which is not
down to the desktop itself, since KDE4 for example uses 10% less
memory here than KDE3, which has "less features") would slow a system
down simply because it has to access more of it. I dare say cache
management algorithms both in hardware and software have advanced
enough that your point is absolutely moot even if it WERE true on a
basic, high-school textbook level.
--
Matt Sealey
On Mon, Jan 12, 2009 at 05:36:32PM +0100, Dominique Leuenberger wrote:
We have open-vm-tools KMPs in the distribution, which brings all the drivers for a VMware session you possibly might need. All nicely under GPL.
Ah, sorry, I was confused, it's the vmware "host" side drivers that are still closed source. Those we can not redistribute.
Actually even there I'm not so sure about the entire thing: to my understanding from several discussions (I'm active there a bit, as I'm packaging open-vm-tools, so things like this just raise) seems to be that the host part is almost identical, with very few exceptions. The module set is more or less the same; for Vsock there are other DEFINES used.
Look at the license of the modules themselves that vmware offers. A number of them recently switched to be: MODULE_LICENSE("GPL"); but at the same time, they introduced 3 new ones that are closed. So the end result is the same, we can't ship them :(
I'm not sure though if vmware themself is interested in having the modules shipped by default, as their concern is giving 'power of updating' out of the hand.
Yeah, that's a horrible excuse. I've been talking with them for a long time about this, and they are finally starting to realize that they need to change this. But they move very slowly, so don't count on any big changes any time soon.
Now, with every release of vmware, they can ship a new module set. Having them upstreamed in the kernel would stop them from doing so (or adding them in the 'update' folder, but then newer kernel would be ignored... I think there is no feature to just load the 'newest' driver.
No, it wouldn't stop them from this at all. It's no different from any other company that ships updated drivers for their products for older kernel releases. vmware is not unique at all, despite what they keep claiming (and wishing...)
So I'll start a discussion over at vmware, maybe for 11.2 we can actually get the support for the host also in (if license permits of course!)
If someone sends me the vmware code, under the GPL, I can get it into the next kernel version with about a days work. It's not hard at all, I don't know why people claim that... thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jan 11, 2009 at 10:38 AM, Greg KH
On Sun, Jan 11, 2009 at 04:07:25PM +0000, Rob OpenSuSE wrote:
2009/1/11 Marcus Meissner
: On Sun, Jan 11, 2009 at 01:45:27AM -0500, Putrycz, Erik wrote: Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments?
Yes, it can be used that way.
But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :)
But for KVM or Xen, this package should work. If not, please let us know.
Hi Greg,
Ignoring for a second the kernel modules required to support host
access, what I was thinking was a kernel that implemented, for
example.. Intel PIIX3/4 ATA, AHCI, Fusion MPT (for VMware), Intel AC97
audio and ES1371 audio, you know.. the hardware that you can pick in
boxes from VMware or VirtualBox or whatever other emulation
environment. The hardware it mimics on it's fake PCI bus etc. :)
vmware-tools, virtualbox kernel drivers, either in weird package forms
built by script, or KMPs, are something you generally have to pull in
once the OS is installed (I've not yet seen any distribution - for
licensing reasons or otherwise - provide any virtualization host-guest
toolkit by default on the installation DVD). This is fine. But for the
basic install and the basic kernel and the built initrd, why include
40 PCI ethernet cards, 10 framebuffer drivers, ATA drivers for every
southbridge on the planet, things like PCI DVB adapters and server
hardware such as Infiniband.. which.. it simply does not provide on
it's virtual PCI bus? Since VirtualBox is based on QEMU and shares a
lot of the physical device emulation, and VirtualBox and VMware tend
to assume a certain subset of drivers are all an emulated system need
have to boot, get through and installer and bring up Windows before
host-guest tools are installed, those decisions in the design of the
emulators would mean a more efficient, leaner kernel could be built
with less drivers, less kernel build time, less boot time, far less
bothersome modules to be "autoloaded" (it's not like you can hotplug a
virtual PCI card in any of them, none of the emulators expose anything
cpufreq can use, etc.)
--
Matt Sealey
On Sat, Jan 10, 2009 at 7:32 AM, Rob OpenSuSE
2009/1/10 Larry Stotler
: On Sat, Jan 10, 2009 at 12:12 AM, Matt Sealey
wrote: of work but it's definitely possible to knock KDE4 down so it's basically featureless (exactly like you want it) with barely anything done on startup except get into X and start networking.
Which shows me it's just not a compelling alternative. The devs seems to have fallen into the "it's there, let's waste it" trap. They have
Actually Qt4 and KDE4 have not increased memory consumption particularly according to my observations.
There has been stuff added which is a matter of configuration. 11.1 just has a lot of issues right now, but testing pre-release on even 8 yr old hardware, I had acceptable performance for occasional desktop use.
Alot of ppl with much newer machines have complained of performance problems, so I think such a sweeping generalisation as the "it's there, let's waste it" trap comment, is as erroneous as the 1GiB RAM requirement.
It runs great in 256MB and 512MB. As well as you could expect any OS
that does that to run in them - which is to say, fairly usable. I
remember back in the days when Windows 2000 was a limited beta and it
would install on a system with 24MB of memory. It ran like crap.
Systems with 32MB of memory - now, you could run Office on those! The
limiting factor was NOT the slow processors (30-60MHz Pentiums) or the
lack of RAM, but that when it DID swap, the ancient IDE controllers
would effectively lock the machine up. If you put a pretty decent
Promise IDE card in there (we're talking ATA66, I still have that
card) the whole thing would just pop to life.
In later betas and the final release they bumped the requirement to
64MB to gain a sort of baseline performance expectation. That is not
to say that it would not run in 24MB anymore (at least it would just
flake out during install because of a requirements check but you could
just swap in 64MB to install, and then go back to a lower size..
easily possible if you're using Ghost or PartitionMagic to push
sysprepped images), but there are many, many things that go with a
system that only has 24MB which limit performance far more.
We can bring this into the future somewhat, and point out that the
only reason the Efika (400MHz G2 PowerPC, no L2 cache, 128MB DDR2)
runs it so badly is because it has no DMA-enabled ATA driver. The
processor is fast, the memory is fast, but lack of fast swap space
really lets it down.
I cannot imagine you would ever have a PC with even 256MB that could
not get by with KDE4 - I actually have KDE4 running on my Via EPIA
M1000 as of last week now, and at 1GHz and with 256MB RAM, it's fine,
fine, fine (my only disappointed moment was when I found the unichrome
driver sucks, as does the unichrome DRI which will not load, so I
could not spin a desktop cube around. But otherwise it was snappy.).
So, KDE4 has reduced memory requirements and Qt4 is far better
optimized and more efficient, so where is the problem? Well, I'd say,
it's avahi-daemon, postfix, powerd, beagle, pick any daemon which
starts up at boot, or before the desktop, which has doubled in number
from 10.3 to 11.1 - I can't nitpick at the accessibility daemons but
the amount of stuff loaded on boot has gotten way out of control.
Let's consider something like the FUSE filesystem. Now, this does not
take too long to load, or take up too much memory, but it is a good
example of the operation. boot.fuse brings this up at boot time, way
before the desktop and way, way after everything has been pulled from
fstab. This may be necessary to, for instance, load the users' Windows
drive and mount it for the desktop. But why not make it so that this
drive's filesystem is only detected, drivers loaded, filesystems
mounted, as and when the user ACTUALLY goes to access it?
When you click a USB stick, it mounts, VFS layers kick in, and FUSE
modules are loaded. Do you really need the kernel driver around for 5
days before a user does this? Can't the module be loaded on-demand,
kept around until memory pressure or something else hits it? The same
would be true of anything else.
Postfix is another example of something which is just too big for its
boots. How many people actually really configure their system so that
SMTP mail goes directly through this daemon? It's only there because
cron needs an SMTP daemon. A user with a Netbook would never care.
Debian etc. use ssmtp which is much smaller, fulfils the requirements
exactly, and does not contain a full SMTP/LMTP compliant mail solution
with filters and scripting and a full mail queue which gets started on
boot and only hangs around waiting for a cron job to fail. It takes
ages to start, and soaks up resources. If someone really does need
postfix, they can grab a postfix pattern, I mean.. why not? Or, what
if they like exim better? Postfix is hard to uninstall once it's there
for a novice who wants to get rid of it :)
I am sure there are plenty of other things which could be deferred as
services (is this even possible with init or any other boot process?)
until really needed, or simply cut out or replaced with
lower-resource-using systems.
The obvious trick is to use memory when you need it, load things when
they're about to be used.. even Windows manages to install a billion
services on a system, but Windows Installer is only started when
you're installing something, Windows Live Communications Platform is
only started when you start Windows Live apps, IMAPI CD burning
doesn't start unless I'm about to burn a CD. VirtualBox doesn't start
it's service until you're loading VirtualBox. And Contrast VMware
which manages to soak up 200MB of auth, nat, disk mounting and dhcp
relay daemons before you even start a VM.. and this is just from
VMware Player (which I have not run since I installed it)
--
Matt Sealey
On Mon, Jan 12, 2009 at 11:36:17AM -0600, Matt Sealey wrote:
I cannot imagine you would ever have a PC with even 256MB that could not get by with KDE4 - I actually have KDE4 running on my Via EPIA M1000 as of last week now, and at 1GHz and with 256MB RAM, it's fine, fine, fine (my only disappointed moment was when I found the unichrome driver sucks, as does the unichrome DRI which will not load, so I could not spin a desktop cube around. But otherwise it was snappy.).
I'm working on resolving this. The SLED11 kernel should have support for this, and so the next updated 11.1 kernel will also get it "for free". You'll have to pull in a different xorg driver package, which I think just got checked in, but I haven't looked to be sure. After SLED11 is released, and you still have problems with this, let me know and I'll be glad to try to work through it, as I have a laptop with this chipset in it too. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jan 12, 2009 at 11:08:55AM -0600, Matt Sealey wrote:
On Sun, Jan 11, 2009 at 10:38 AM, Greg KH
wrote: On Sun, Jan 11, 2009 at 04:07:25PM +0000, Rob OpenSuSE wrote:
2009/1/11 Marcus Meissner
: On Sun, Jan 11, 2009 at 01:45:27AM -0500, Putrycz, Erik wrote: Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments?
Yes, it can be used that way.
But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :)
But for KVM or Xen, this package should work. If not, please let us know.
Hi Greg,
Ignoring for a second the kernel modules required to support host access, what I was thinking was a kernel that implemented, for example.. Intel PIIX3/4 ATA, AHCI, Fusion MPT (for VMware), Intel AC97 audio and ES1371 audio, you know.. the hardware that you can pick in boxes from VMware or VirtualBox or whatever other emulation environment. The hardware it mimics on it's fake PCI bus etc. :)
Doesn't our kernel package today offer this? Yes, it would be nice to somehow only roll a kernel package that contained a limited number of drivers in it, exactly what you specify. Different people have been asking for this for a while, and with the increase usage of openSUSE/SLED on netbooks, we are starting to work on something like this. So be patient, it's on the roadmap, but first we need to get SLED11 out the door. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/12 Matt Sealey
On Sat, Jan 10, 2009 at 6:02 AM, Rob OpenSuSE
wrote: You're talking a lot of crap, frankly.
As you've become rude, I'll just suggest you clue up by finding some CPU architecture explanations.
Your little dissertation on how memory access has gotten slower relative to older processors is naive at best, and wrong if you sat down with a real chip and looked at it's real performance.
You actually appeared to agree, with "realtively slower" a few lines down later in your statement that included the word scaling; which usually applies to capacity and size comparisons not relative performance. Misrepresenting and misquoting is not helpful to a constructiive discussion, nor the sentiment you've shown. Again IMO the same functionality is not generally consuming more memory in newer software, in fact it is clear that many projects are avoiding that for good reasons, despite a large increase in number of 2-4GiB destkop boxes, they've taken steps to reduce memory footprint. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jan 12, 2009 at 11:44 AM, Greg KH
On Mon, Jan 12, 2009 at 11:08:55AM -0600, Matt Sealey wrote:
On Sun, Jan 11, 2009 at 10:38 AM, Greg KH
wrote: On Sun, Jan 11, 2009 at 04:07:25PM +0000, Rob OpenSuSE wrote:
2009/1/11 Marcus Meissner
: On Sun, Jan 11, 2009 at 01:45:27AM -0500, Putrycz, Erik wrote: Do you mean there's a kernel in the kernel-base rpm, that is intented for virtualised environments?
Yes, it can be used that way.
But note, it doesn't have the vmware drivers as they violate the GPL and can not be redistributed, and virtualbox drivers, well, let's just say some of us looked at that code, and ran away screaming :)
But for KVM or Xen, this package should work. If not, please let us know.
Hi Greg,
Ignoring for a second the kernel modules required to support host access, what I was thinking was a kernel that implemented, for example.. Intel PIIX3/4 ATA, AHCI, Fusion MPT (for VMware), Intel AC97 audio and ES1371 audio, you know.. the hardware that you can pick in boxes from VMware or VirtualBox or whatever other emulation environment. The hardware it mimics on it's fake PCI bus etc. :)
Doesn't our kernel package today offer this?
Everything but Fusion MPT I think, sure.
Yes, it would be nice to somehow only roll a kernel package that contained a limited number of drivers in it, exactly what you specify. Different people have been asking for this for a while, and with the increase usage of openSUSE/SLED on netbooks, we are starting to work on something like this.
So be patient, it's on the roadmap, but first we need to get SLED11 out the door.
That's good to know and all I wanted to know :D
--
Matt Sealey
On Mon, Jan 12, 2009 at 12:39 PM, Rob OpenSuSE
2009/1/12 Matt Sealey
: You actually appeared to agree, with "realtively slower" a few lines down later in your statement that included the word scaling; which usually applies to capacity and size comparisons not relative performance. Misrepresenting and misquoting is not helpful to a constructiive discussion, nor the sentiment you've shown.
I said that taking 1 cycle of a 30MHz system does not mean that 300 cycles of a 3GHz system is slower, just because it takes more cycles. Every memory access on the older system will take that amount of time, whereas accesses to L2 on a lot of systems may take 11-14 cycles (using a G4 as a reference, it went up from 11 to 12, then to 14 with ECC enabled on a 7448 vs. 7447A). Access of data already in L1 is practically free (i.e. less time than the instruction, which is usually 1 cycle for 95% of instructions on PowerPC) Looking at a CPU holistically you take into account the sum of it's parts, and the way they interact, and how this affects your code and performance. You are fixated on how many cycles it takes. You're also using it as an argument about using MORE memory. Both of these are wrong.
Again IMO the same functionality is not generally consuming more memory in newer software, in fact it is clear that many projects are avoiding that for good reasons, despite a large increase in number of 2-4GiB destkop boxes, they've taken steps to reduce memory footprint.
And how does some app using more memory for a task somehow reduce it's
performance because memory latencies and access times have increased
over the years?
Using 10MB or 100MB of memory for something makes no difference if
your L2 cache is 256kb - you can never fit all of it in, so it will go
to main memory at some point.. on a system where you have no L2 cache,
you will nearly always be looking at main memory. In these situations
with modern processors, the time taken to perform a miss, fetch the
new data, is still much less in real measurable time, than it was on
older processors with more limited architectures. Every time you swap
from application to application, large swathes of data will need to be
loaded in - and caches effectively flushed so as to make room for the
currently running task and not the previous one. Embedded processors
allow locking code into L1 or L2 for this purpose - for instance
something you need to be there all the time. Linux doesn't bother.
We're not really concerned here with how much time a CPU wastes
accessing main memory. It's pretty clear that no component running on
a desktop Linux is going to entirely fit in there, and in the end,
this makes it a pretty moot point.
What is to be concerned about is how a desktop system that had minimum
requirements of 256MB a couple years back now has requirements - even
with the purported improvements in memory usage for KDE4 for example -
which are upwards of 512MB. These are obviously not the fault of the
desktop itself, but perhaps the new technologies that came with it.
Search tools (like Beagle, which has some enormous resource usage
which may be down to Mono or may not. I know ATI Catalyst Control
Center doesn't do much more than the old ATI Control Panel did on
Windows, but it still takes up 60MB on boot here. That might be a
quarter of the memory in a system, and cause premature use of the
paging file, which shouldn't be too bad on most systems, but on others
(see previous mail about slow hard disks. Contrast speeds of
USB-connected disks or single-level NAND Flash) can cause real
problems. That is a lot of memory for a couple of sliders..)
It has nothing to do with memory access times but of the overall use
of memory. A Linux desktop should boot in 256MB (as the installer
won't install in less) and have a large amount left for applications -
currently it soaks up just about 210MB on my Pegasos and Via EPIA
after login to the GNOME desktop - no Compiz etc. enabled. I think
this is somewhat unacceptable. It's workable but, it could be less.
If you have 4GB or 8GB of memory it is nothing to care about, but
users put in this memory to run applications, not to provide space for
50 boot services which sit idle, most of which are only there to
provide people with large amounts of memory to get things done
quicker. This is not very friendly to those who run in more
constrained environments. I'm not looking for GNOME etc. to run in
128MB (although in 10.3 it did, and I had enough memory left to run
applications before swapping) but reducing the memory footprint of the
basic install would be awesome.
--
Matt Sealey
On Mon, Jan 12, 2009 at 3:02 PM, Matt Sealey
If you have 4GB or 8GB of memory it is nothing to care about, but users put in this memory to run applications, not to provide space for 50 boot services which sit idle, most of which are only there to provide people with large amounts of memory to get things done quicker. This is not very friendly to those who run in more constrained environments. I'm not looking for GNOME etc. to run in 128MB (although in 10.3 it did, and I had enough memory left to run applications before swapping) but reducing the memory footprint of the basic install would be awesome.
This is the same problem that windows has. Too many apps think they are the most important thing you'll never use. Like I said, they'll use it cause it's there and only take into consideration their program and not the fact that every other dev seems to feel the same way(not that I'm accusing the devs here, but it's a problem everywhere). I'm gonna have to go on a hunt to try to remove a lot of unnecessary stuff without breaking anything...... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/12 Larry Stotler
On Mon, Jan 12, 2009 at 3:02 PM, Matt Sealey
wrote:
If you have 4GB or 8GB of memory it is nothing to care about, but users put in this memory to run applications, not to provide space for 50 boot services which sit idle, most of which are only there to provide people with large amounts of memory to get things done quicker. This is not very friendly to those who run in more constrained environments. I'm not looking for GNOME etc. to run in 128MB (although in 10.3 it did, and I had enough memory left to run applications before swapping) but reducing the memory footprint of the basic install would be awesome.
Linux does not swap!!! It's a demand paged virtual memory system. Those "idle" processes, will relinquish their clean pages, to be re-read in on demand by page faults from disk, and anonymous dirty pages can be saved in the (misnamed) swap space by the VM. Unfortunately the value of "swappiness" set, seems to be 60, which according to my tests appears too low, so that even on a 512MiB system, swap space is generally unused, for typical "netbook" like usage. Increasing the value to 95 or 100, did get some pages written to the swap space, thus increasing the memory available for applications and kernel caches.
This is the same problem that windows has. Too many apps think they are the most important thing you'll never use.
Any Specifics? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Jan 13, 2009 at 6:49 AM, Rob OpenSuSE
This is the same problem that windows has. Too many apps think they are the most important thing you'll never use.
Any Specifics?
That's a big list, but here's a couple of examples on WinDoZe: Java Quicktime iTunes Any Search program CD Burning programs that override the Windows default settings when you insert media Instant Messengers(The average at my shop is 3 installed - MSN being the most often seen) Printer utilities that don't need to run Office quickstart programs Hardware utility programs(video, sound, etc) that no one ever tweaks. Advanced Text Servcies and the language bar(which is really only good for east asian users) Firewall(for a desktop on a hardware router, it's pointless. For a laptop that's on different connections it's not). Both Windows and Linux on this one. Also, the Prefetch and Superfetch schemes will preload things like installer programs that you only use one time. If you turn off Superfetch, you can actually use Vista with 1GB RAM. The biggest speed boost in Windows is using msconfig and turning off all of the startup programs and services that don't need to be run. I've even seen where I have uninstalled stuff like Norton and Macafee and FSecure and they still have stuff loaded on startup. That's why Symantec and Macafee have removal tools, and then they still don't get everything. And, just try installing a current version of Norton or Macafee on any machine slower than 2Ghz with 512MB and watch your machine turn into molasses. Fortunately, Linux is nowhere near that bad, but openSUSE still installs a lot of what I fell are unnecessary programs like Beagle, OpenOffice(KOffice is much better and uses less resources if you use KDE), AppArmour, etc. I realize that the devs want to make the install easier and that they choose a specific set of apps to install, but, from my experience, 90% of the people never even use a Desktop search program, so it's just a waste. Also, YaST can make it a pain to uninstall stuff. Try removing OpenOffice, AppAromour or Beagle in 11.0, and you'll get dependency complaints. If the main module of a program is selected for removal, all parts of it should be removed unless they have a dependency elsewhere(which they shouldn't). I haven't tried it in 11.1 yet. The idea of preloading some things for faster startup speed is laudable, but then again, it has huge tradeoffs on slower systems. It's a shame there's not an easy to use tweaking program for Linux. YaST has some things, but they aren't as robust as I would like to see. I'd write one, but I'm not a programmer, so..... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, 2009-01-09 at 12:44 -0600, Matt Sealey wrote:
On Fri, Jan 9, 2009 at 2:14 AM, Stephan Binner
wrote: On Thursday, 8. January 2009 20:21:15 Matt Sealey wrote: Is there a GNOME version of that page?
http://en.opensuse.org/GNOME/Ideas
11.2 editing hasn't started yet, that should kick off with the irc
meeting this week, but feel free to start now.
-JP
--
JP Rosevear
Rob OpenSuSE wrote:
2009/1/12 Larry Stotler
: On Mon, Jan 12, 2009 at 3:02 PM, Matt Sealey
wrote: If you have 4GB or 8GB of memory it is nothing to care about, but users put in this memory to run applications, not to provide space for 50 boot services which sit idle, most of which are only there to provide people with large amounts of memory to get things done quicker. This is not very friendly to those who run in more constrained environments. I'm not looking for GNOME etc. to run in 128MB (although in 10.3 it did, and I had enough memory left to run applications before swapping) but reducing the memory footprint of the basic install would be awesome.
Linux does not swap!!! It's a demand paged virtual memory system. Those "idle" processes, will relinquish their clean pages, to be re-read in on demand by page faults from disk, and anonymous dirty pages can be saved in the (misnamed) swap space by the VM.
I really don't think there is any distinction to be made here. You swap a page in physical memory for one on some backing store. The terminology is naive but correct.
Unfortunately the value of "swappiness" set, seems to be 60, which according to my tests appears too low, so that even on a 512MiB system, swap space is generally unused, for typical "netbook" like usage. Increasing the value to 95 or 100, did get some pages written to the swap space, thus increasing the memory available for applications and kernel caches.
On a 128MB system it gets there pretty fast; on 10.3 we had ~40MB space left (which was then soaked by buffers and caches as is good to do). However loading anything else in started really going at the page file. On a slow disk this is an absolute nightmare. There are two schools of thought on this; one, is that applications should be stored in RAM and RAM only until significant memory pressure arises. The other, is that data should live mostly in swap and only be put into RAM when it's actually used. Windows likes to keep it the second way and there is a kernel developer who likes swappiness set really high (I forget his name.. was it Andrew Morton?). As long as you have enough of a swap cache and a fast enough disk this is awesome. I actually think this is the right way to do it. However, if your disk is slow (USB, NFS, DMA-less ATA), you're pretty much tied to how fast your disk is, which is.. very bad indeed. Couple it with a low amount of memory, and you basically have no way out.
This is the same problem that windows has. Too many apps think they are the most important thing you'll never use.
Any Specifics?
There are none :D Applications should allocate all the memory they'll need and the OS should work out what to do with it. As things like KDE and GNOME create more and more tasks and external applications and rely on more services, the memory consumption of the original tasks may go down, but it is then canceled out by the memory consumption of the extra feature and extra external application, plus any abstraction layered between. We're not talking anymore about "KDE uses too much memory as an application" but "SUSE loads far too much on boot". It's not just the desktop.. it's every service, every module, that is installed by default and enabled by default, which significantly reduces the amount of memory available for future tasks. Since most of them are essential to start other required boot services not much can be done about it, but definitely things like postfix are too big for the job they're meant to do (supply a dependency for cron) and certain boot tasks can be and should be deferred until the actual need arises before being started. Networking need not be brought up - i.e. access to the internet etc., since you need lo set up for a lot of things - until the user is at the desktop. On a Netbook this may be the wireless card, and they may have to pick an SSID first. Imagine that you do this on boot, on a new location - it sits in a console, trying to access an SSID it remembered from the last time. It doesn't exist. It has to scan.. and then fail. If it exists (maybe an unsecured network with a common name such as "NETGEAR", it still has to scan for it then configure and run DHCP over it, and potentially fail. This will increase boot time only so the user can get to a desktop and pick the right SSID and connect to the correct network as they wish. Unless you are booting into a system which does it's user authentication over the network (Active Directory, LDAP, or crazy people who still use YP etc.) then you don't need to bring up the network until they first start an app that needs networking. On openSUSE this may be the Updater app, although it SHOULD sit and wait for something else to access the internet (i.e. notification from NetworkManager that a connection was made and verified up, rather than forcing network access). On demand is definitely a good way to go for anything, as it reduces memory requirements up to the point something needs to be done. If you do not have enough memory to do it at that point, then tough luck.. time to buy new RAM. But if you never use it (Avahi for example, I have no mDNS-compatible devices here) and never go to a share browser or go to print a file, it shouldn't even be loaded.. the moment I do get one of these lovely little printers or a Mac sitting here, I want to be able to use it. Having the stuff on disk is great, loading it at boot and soaking xMB of memory until that point, is wasteful. -- Matt -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Jan 13, 2009 at 10:36 AM, Matt Sealey
On a 128MB system it gets there pretty fast; on 10.3 we had ~40MB space left (which was then soaked by buffers and caches as is good to do). However loading anything else in started really going at the page file. On a slow disk this is an absolute nightmare.
Memory usage was much lower on the 10.x system from my experience as well.
On demand is definitely a good way to go for anything, as it reduces memory requirements up to the point something needs to be done. If you do not have enough memory to do it at that point, then tough luck.. time to buy new RAM. But if you never use it (Avahi for example, I have no mDNS-compatible devices here) and never go to a share browser or go to print a file, it shouldn't even be loaded.. the moment I do get one of these lovely little printers or a Mac sitting here, I want to be able to use it. Having the stuff on disk is great, loading it at boot and soaking xMB of memory until that point, is wasteful.
Agreed. However, since openSUSE is one of those kitchen sink thrown in distros, they have to balance it. I wish that SLICK had panned out. I've looked at SUSE Studio, but since it's still in alpha, you can't get much access to it yet. And, it seems to only have i386 support right now. What I need that for is PPC more than anything else. I have a Powerbook 3400c that maxes at 144MB RAM and a PowerMac 6500 that maxes at 128MB. I don't expect to run a full desktop like KDE or Gnome on them, but it would be nice to be able to run a basic like TinyWM and Firefox. In that case, you don't need much other than the services to start the system, and networking for wired or wireless. I can actually go online with my Thinkpad 380XD P/233/96MB RAM(Maxed out) with Win2k. It's not fast to say the least but it works. That's with FF 2.x. Haven't tired 3.x. And that's with a USB wireless adapter. Of course, I can do more if I use Damn Small Linux and don't expect to run a full modern desktop on hardware that old, but it would be interesting to see how usable such old machines can be. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/13 Matt Sealey
Rob OpenSuSE wrote:
2009/1/12 Larry Stotler
: On Mon, Jan 12, 2009 at 3:02 PM, Matt Sealey
wrote: If you have 4GB or 8GB of memory it is nothing to care about, but users put in this memory to run applications, not to provide space for 50 boot services which sit idle, most of which are only there to provide people with large amounts of memory to get things done quicker. This is not very friendly to those who run in more constrained environments. I'm not looking for GNOME etc. to run in 128MB
Linux does not swap!!! It's a demand paged virtual memory system. Those "idle" processes, will relinquish their clean pages, to be re-read in on demand by page faults from disk, and anonymous dirty pages can be saved in the (misnamed) swap space by the VM.
I really don't think there is any distinction to be made here. You swap a page in physical memory for one on some backing store. The terminology is naive but correct.
Except that as someone of your background knows, that a "swapping" ie. evicting all memory pages of a process, saving them to disk, is a different memory technique, commonly used in past on multi-user systems when physical memory was larger than the logical address space to processes. The point is, those "idle processes" do not sit there, hogging RAM.
However loading anything else in started really going at the page file.
On a slow disk this is an absolute nightmare.
I've seen heavy usage of swap space, on 256MiB system, under KDE4 desktop, FF3 and YaST software management, which really did want nearer 400MiB, than 256MiB. And I actually used the slowest disk I have that actually does UDMA correctly (a 4GB model circa 1999). But what are reasonable expectations in this situation? It is clear that switching between those tasks, that the working set size is exceeded, and a delay is inevitable. The system did not go into a meltdown where, it took minutes rather than seconds to become responsive.
There are two schools of thought on this; one, is that applications should be stored in RAM and RAM only until significant memory pressure arises. The other, is that data should live mostly in swap and only be put into RAM when it's actually used.
Windows likes to keep it the second way and there is a kernel developer who likes swappiness set really high (I forget his name.. was it Andrew Morton?). As long as you have enough of a swap cache and a fast enough disk this is awesome. I actually think this is the right way to do it.
However, if your disk is slow (USB, NFS, DMA-less ATA), you're pretty much tied to how fast your disk is, which is.. very bad indeed. Couple it with a low amount of memory, and you basically have no way out.
It's whether you write dirty pages to swap, which are not backed by files, for instance executable programs. When you look for a new page, it's always faster to throw away a clean or a cache page. The consequence of keeping all written to data pages in memory, and not having them saved by the backing store, is that you never reclaim those pages, from the idle processes, complained about. My test backs up Andrew Morton, without swappiness being set high, swap space is unused, which means the system is doing more page faults than it otherwise would because, it's not able to evict data pages of little used processes in favour of working set of running processes, and OS cache. Where it makes sense to have swappiness set low, is when nightly (luncthime?) batch jobs are run, doing things like index builds for desktop searches, locate or something like a virus scanner, which are done once, and you know that the files they read in won't be reaccessed; though there are ways for applications to hint that they're "read once". That reduces the perceivable lag, when an idle desktop application is used and needs to reclaim memory. Small memory 128MB, slow disk (USB, NFS, PIO-ATA) and running large programs, look like badly specified configuration to me. Not having anon data saved in a swap space isn't going to help things. You still will seek like crazy, servicing page faults.
This is the same problem that windows has. Too many apps think they are the most important thing you'll never use.
Any Specifics?
There are none :D
This is the problem in the thread. I've mentioned specific counter examples, to disagree with certain generalisations, and suggested configuration issues (candidates like nepomuk / beagle). Nothing constructive comes out of generalisations.
We're not talking anymore about "KDE uses too much memory as an application" but "SUSE loads far too much on boot". It's not just the desktop.. it's every service, every module, that is installed by default and enabled by default, which significantly reduces the amount of memory available for future tasks.
The thing is, the system runs fine with 256 MiB, if you're not expecting to both browse and run other applications. These idle processes should only affect boot times. Finally OS provides a "Net Install" which allows fine-grained choices, and you can install a minimal system. If you have a low amount of memory it's unreasonable not to use that option, but expect defaults made for Live CD or a general desktop install to be altered, that inconveniences the less knowledgeable desktop user. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/13 Larry Stotler
On Tue, Jan 13, 2009 at 10:36 AM, Matt Sealey
wrote:
Agreed. However, since openSUSE is one of those kitchen sink thrown in distros, they have to balance it.
I don't expect to run a full desktop like KDE or Gnome on them, but it would be nice to be able to run a basic like TinyWM and Firefox. In that case, you don't need much other than the services to start the system, and networking for wired or wireless.
So have you tried using a netinstall, and then selecting pure X or XFCE? There's also LXDE which you may be able to try out later, from OBS. You have to realise that the memory required to access modern websites is high, so old low memory hardware (now 96MiB and 144MiB) just aren't going to be realistic choices, for general Desktop usage. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Jan 13, 2009 at 9:36 AM, Matt Sealey
But if you never use it (Avahi for example, I have no mDNS-compatible devices here) and never go to a share browser or go to print a file, it shouldn't even be loaded.. the moment I do get one of these lovely little printers or a Mac sitting here, I want to be able to use it. Having the stuff on disk is great, loading it at boot and soaking xMB of memory until that point, is wasteful.
I just had a thought. It there even a way to check for the presence of
a service and then start it under Linux? I thought D-Bus would handle
this kind of thing.. but in the end if you want to, say, make sure
daemons are loaded so you can perform discoveries and connect to
shares or printers, what do you talk to, in order to find out whether
it's running and whether it should be started?
I understand that Avahi can't exactly be killed off if you want it to
work on an mDNS environment - it has to be around so it can accept the
multicasts and then notify of device presence. But it's an example of
something large, which if you are not on this kind of network, is not
needed.
I cannot say the same for hplip or cups. On most desktop systems these
services are started (at least in 11.0 and 11.1) - on most desktop
systems the printer is connected locally so it is not like you need an
active print queue running 100% of the time to accept data. You will
know when you want to print because, something requests to print. Or
that it how it should be. As for hplip, what if you do not even own an
HP printer, scanner or fax? This is the kind of thing where printing
support should be installed, but nothing actually activated until you
first add a printer (and left disabled until you actively want to add
a printer through YaST2 - and if it IS an HP all-in-one, then by all
means start hplip!)
It is commendable for the installer to search for TV cards, ISDN/DSL
and printers, but if none are found, at the very least put the
software in a holding pattern so it needn't be supported. About things
like smartd - I can see this load on my Efika but in older SUSE (not
11.0 since it works there) the smart tools command lines say smart
support is disabled and I need to start it with "-s on" - but it never
worked. The daemon was still running though. This is not sane. I
didn't set up any LVM2 stuff yet but boot.device-mapper still runs and
I get dm-mod in my kernel. This is the sort of thing which should be
there if you ran the GUI to set it up or enabled it at any point in
the installer, but not otherwise (there is no way I can think of that
would require dm-mod to be loaded, where you did not already configure
a LVM2 etc. or not actively in the process of configuring one)
Unfortunately the rc.d dependency system only seems to work within
itself (so a service relies on other services to start), but an
application can't particularly query whether a service is started, or
stopped (except if it publishes itself in D-Bus), or make a request
for it to be started once rc.d stuff is over? I don't think SuSE
manages this at all (using traditional init) although replacements
like upstart, launchd, initng all install a small daemon which can do
service control.. I bet most of them suck.
Now I am looking at it I am really, really disappointed in the state
of affairs of Linux which has been relying on the stupid runlevel
system (which has absolutely no fine-grained service control at all)
since the dark ages and has not come out of it. While Windows only has
3 service states (Automatic, Manual and Disabled), these can be
stopped and started at any time, programmatically, through service
names which are well known to the applications that use them. On any
Linux distribution any of these "services" (let's assume they're all
in rc.d) can be stopped and started but the names change per distro..
there is no registry or namespace like mDNS or D-Bus recommends in
order to get to this stuff.
Sigh. Oh well.
--
Matt Sealey
On Tue, Jan 13, 2009 at 11:45 AM, Rob OpenSuSE
2009/1/13 Larry Stotler
: On Tue, Jan 13, 2009 at 10:36 AM, Matt Sealey
wrote: Agreed. However, since openSUSE is one of those kitchen sink thrown in distros, they have to balance it.
I don't expect to run a full desktop like KDE or Gnome on them, but it would be nice to be able to run a basic like TinyWM and Firefox. In that case, you don't need much other than the services to start the system, and networking for wired or wireless.
So have you tried using a netinstall, and then selecting pure X or XFCE? There's also LXDE which you may be able to try out later, from OBS.
Xfce is better but it's still not "officially" supported by SUSE so the actual integration into the rest of SUSE as a whole is absolutely terrible. No SUSE theming, the boot manager is ugly-as-sin xdm (which is f**king crazy since the installer drags in gdm), all the settings apps are just dumped into a big long menu (mixing Xfce, GNOME and YaST choices which means scrolling 3 pages to find anything), panels are set to their defaults, you can't GET to anything useful or DO anything useful on this desktop. SUSE has traditionally set up the default desktop to at least be windows-alike in nature to make people transitioning more comfortable. Not the case with Xfce, and not because they decided "people like it better that way". And that means, not even a green desktop by default.
You have to realise that the memory required to access modern websites is high, so old low memory hardware (now 96MiB and 144MiB) just aren't going to be realistic choices, for general Desktop usage.
This is not old low memory hardware but specifically designed new
hardware. 128MB was determined a couple years back to be a
cost-effective and pretty usable amount of memory to run something
like Xfce in. Between 10.3 and 11.1 it's changed and while nothing
changed about Xfce (it's still ugly, and useless, but the only thing
that will actually get to desktop without forcing swap usage) the rest
of the system has bloated out past the line. I have nothing left in
11.1 but to have the system swap.
If you imagine the efforts on LTSP etc., a thin client needn't and
definitely shouldn't be specced like a "general desktop". If you
needed a 2GHz dual core and 2GB of RAM in every thin client, what
would the point of having thin clients be? Where is the cost or power
saving? It is a dumb concept, but this is what Linux forces. I
remember we did get a full GNOME desktop with Compiz enabled running
on our hardware;
http://www.powerdeveloper.org/movie/iris
Do you see any huge slowdowns? This is a 400MHz PowerPC, with no L2
cache, 128MB of RAM and a 64MB Radeon 9250 (r200). This demo was built
with Gentoo. You can see it slowing a little at points; but this is
lack of CPU power, and not much else.
--
Matt Sealey
2009/1/13 Matt Sealey
On Tue, Jan 13, 2009 at 11:45 AM, Rob OpenSuSE
wrote: 2009/1/13 Larry Stotler
: On Tue, Jan 13, 2009 at 10:36 AM, Matt Sealey
wrote:
This is not old low memory hardware but specifically designed new hardware. 128MB was determined a couple years back to be a cost-effective and pretty usable amount of memory to run something like Xfce in. Between 10.3 and 11.1 it's changed and while nothing
If you imagine the efforts on LTSP etc., a thin client needn't and definitely shouldn't be specced like a "general desktop". If you needed a 2GHz dual core and 2GB of RAM in every thin client, what would the point of having thin clients be? Where is the cost or power saving? It is a dumb concept, but this is what Linux forces
A thin client needs kernel, X server, and uses a server for applications so it does not require as much RAM or CPU speed as a typical desktop. It does not need all of the features of a desktop OS, so I'd not be making a default openSUSE install in such cases. Now firing up 10.3 and 11.1 on same machine, I saw some increase in memory consumption but not a great one. In my 10.3 KDE 3.5.10 install, beagle and kerry were expunged, as they were initially buggy and caused trouble. The 11.1 install memory increase was simply accounted for by beagle helper, kerry and nepomuk features under KDE4, which so far haven't disturbed me, so I've left them be. Also 11.1 used AMD 64bit with rather than the conservative 10.3 32bit choice, which increases pointer and program size, so adds a little to memory consumption. So checking quickly, I just do not see any evidence to support 11.1 being "bloaty" compared to 10.3. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Jan 13, 2009 at 12:48 PM, Matt Sealey
On Tue, Jan 13, 2009 at 11:45 AM, Rob OpenSuSE
So have you tried using a netinstall, and then selecting pure X or XFCE? There's also LXDE which you may be able to try out later, from OBS.
LXDE is a great idea actually although I wonder how much lighter it
actually is than Xfce... it does look prettier and tends to follow the
"looks more like Windows" thing that KDE and GNOME have gotten over
the years (no weird or funky panel placements etc.)
Integration is always going to be a problem but LXLauncher may just be
exactly the ticket for some applications like Netbooks..
Is it really that stable, that's the problem.. plus it would never get
into 11.2 as a selectable desktop which makes me wary of pushing it to
a production system (we really don't like the idea of having lots of
custom packages around, and developing with it outside of the SUSE
mainline means we get moving target syndrome al over again)
--
Matt Sealey
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2009-01-12 at 08:57 -0800, Greg KH wrote:
On Mon, Jan 12, 2009 at 05:36:32PM +0100, Dominique Leuenberger wrote:
...
Actually even there I'm not so sure about the entire thing: to my understanding from several discussions (I'm active there a bit, as I'm packaging open-vm-tools, so things like this just raise) seems to be that the host part is almost identical, with very few exceptions. The module set is more or less the same; for Vsock there are other DEFINES used.
...
Yeah, that's a horrible excuse. I've been talking with them for a long time about this, and they are finally starting to realize that they need to change this. But they move very slowly, so don't count on any big changes any time soon.
Now that you two are talking about vmware, a quick question; I'm seeing this after starting vmware server: Jan 13 00:15:24 nimrodel kernel: Symbol init_mm is marked as UNUSED, however this module is using it. Jan 13 00:15:24 nimrodel kernel: This symbol will go away in the future. Jan 13 00:15:24 nimrodel kernel: Please evalute if this is the right api to use, and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. Jan 13 00:15:24 nimrodel kernel: /dev/vmmon[27427]: Module vmmon: registered with major=10 minor=165 Jan 13 00:15:24 nimrodel kernel: /dev/vmmon[27427]: Module vmmon: initialized Jan 13 00:15:24 nimrodel kernel: /dev/vmmon[27431]: Module vmmon: unloaded Jan 13 00:25:01 nimrodel kernel: Symbol init_mm is marked as UNUSED, however this module is using it. Jan 13 00:25:01 nimrodel kernel: This symbol will go away in the future. Jan 13 00:25:01 nimrodel kernel: Please evalute if this is the right api to use, and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. Jan 13 00:25:01 nimrodel kernel: /dev/vmmon[27974]: Module vmmon: registered with major=10 minor=165 Jan 13 00:25:01 nimrodel kernel: /dev/vmmon[27974]: Module vmmon: initialized To whom should this be reported? I guess vmware, but if so, I don't know where. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklt78IACgkQtTMYHG2NR9XtOgCfbH2mYpSERsBD97N3GSBNE0wi TOMAnjOte6Vf1HmvEH2upvpKmUNBq+QL =7xzO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Jan 14, 2009 at 02:59:28PM +0100, Carlos E. R. wrote:
On Monday, 2009-01-12 at 08:57 -0800, Greg KH wrote:
On Mon, Jan 12, 2009 at 05:36:32PM +0100, Dominique Leuenberger wrote:
...
Actually even there I'm not so sure about the entire thing: to my understanding from several discussions (I'm active there a bit, as I'm packaging open-vm-tools, so things like this just raise) seems to be that the host part is almost identical, with very few exceptions. The module set is more or less the same; for Vsock there are other DEFINES used.
...
Yeah, that's a horrible excuse. I've been talking with them for a long time about this, and they are finally starting to realize that they need to change this. But they move very slowly, so don't count on any big changes any time soon.
Now that you two are talking about vmware, a quick question; I'm seeing this after starting vmware server:
Jan 13 00:15:24 nimrodel kernel: Symbol init_mm is marked as UNUSED, however this module is using it. Jan 13 00:15:24 nimrodel kernel: This symbol will go away in the future. Jan 13 00:15:24 nimrodel kernel: Please evalute if this is the right api to use, and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. Jan 13 00:15:24 nimrodel kernel: /dev/vmmon[27427]: Module vmmon: registered with major=10 minor=165 Jan 13 00:15:24 nimrodel kernel: /dev/vmmon[27427]: Module vmmon: initialized Jan 13 00:15:24 nimrodel kernel: /dev/vmmon[27431]: Module vmmon: unloaded Jan 13 00:25:01 nimrodel kernel: Symbol init_mm is marked as UNUSED, however this module is using it. Jan 13 00:25:01 nimrodel kernel: This symbol will go away in the future. Jan 13 00:25:01 nimrodel kernel: Please evalute if this is the right api to use, and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion. Jan 13 00:25:01 nimrodel kernel: /dev/vmmon[27974]: Module vmmon: registered with major=10 minor=165 Jan 13 00:25:01 nimrodel kernel: /dev/vmmon[27974]: Module vmmon: initialized
To whom should this be reported?
vmware.
I guess vmware, but if so, I don't know where.
Neither do I, try their forums or support email address. good luck, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rob OpenSuSE wrote:
2009/1/13 Matt Sealey
: On Tue, Jan 13, 2009 at 11:45 AM, Rob OpenSuSE
wrote: 2009/1/13 Larry Stotler
: On Tue, Jan 13, 2009 at 10:36 AM, Matt Sealey
wrote: This is not old low memory hardware but specifically designed new hardware. 128MB was determined a couple years back to be a cost-effective and pretty usable amount of memory to run something like Xfce in. Between 10.3 and 11.1 it's changed and while nothing
If you imagine the efforts on LTSP etc., a thin client needn't and definitely shouldn't be specced like a "general desktop". If you needed a 2GHz dual core and 2GB of RAM in every thin client, what would the point of having thin clients be? Where is the cost or power saving? It is a dumb concept, but this is what Linux forces
A thin client needs kernel, X server, and uses a server for applications so it does not require as much RAM or CPU speed as a typical desktop. It does not need all of the features of a desktop OS, so I'd not be making a default openSUSE install in such cases.
Right, so you're lecturing me on making a thin client now? Thanks, Rob.
Now firing up 10.3 and 11.1 on same machine, I saw some increase in memory consumption but not a great one. In my 10.3 KDE 3.5.10 install, beagle and kerry were expunged, as they were initially buggy and caused trouble. The 11.1 install memory increase was simply accounted for by beagle helper, kerry and nepomuk features under KDE4, which so far haven't disturbed me, so I've left them be. Also 11.1 used AMD 64bit with rather than the conservative 10.3 32bit choice, which increases pointer and program size, so adds a little to memory consumption.
So checking quickly, I just do not see any evidence to support 11.1 being "bloaty" compared to 10.3.
Forget it, Rob. -- Matt -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tuesday 13 January 2009 14:24:42 Larry Stotler wrote: [snip]
Fortunately, Linux is nowhere near that bad, but openSUSE still installs a lot of what I fell are unnecessary programs like Beagle, OpenOffice(KOffice is much better and uses less resources if you use KDE), AppArmour, etc. I realize that the devs want to make the install easier and that they choose a specific set of apps to install, but, from my experience, 90% of the people never even use a Desktop search program, so it's just a waste. Also, YaST can make it a pain to uninstall stuff. Try removing OpenOffice, AppAromour or Beagle in 11.0, and you'll get dependency complaints. If the main module of a program is selected for removal, all parts of it should be removed unless they have a dependency elsewhere(which they shouldn't). I haven't tried it in 11.1 yet.
That's dependency problem of packages, not libzypp (and thus not YaST). Stano -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/14 Matt Sealey
Rob OpenSuSE wrote:
2009/1/13 Matt Sealey
:
If you imagine the efforts on LTSP etc., a thin client needn't and definitely shouldn't be specced like a "general desktop". If you needed a 2GHz dual core and 2GB of RAM in every thin client, what would the point of having thin clients be? Where is the cost or power saving? It is a dumb concept, but this is what Linux forces
A thin client needs kernel, X server, and uses a server for applications so it does not require as much RAM or CPU speed as a typical desktop. It does not need all of the features of a desktop OS, so I'd not be making a default openSUSE install in such cases.
Right, so you're lecturing me on making a thin client now? Thanks, Rob.
Actually, I was agreeing with your point about reduced requirements. You're the person pushing the hardware with 128MiB RAM and 1MB/s disk; it's not suitable for a general default configuration. IMO it is nor reasonable to expect openSUSE to customise the system to meet your requirements.
So checking quickly, I just do not see any evidence to support 11.1 being "bloaty" compared to 10.3.
Forget it, Rob.
Sure will, as facts seem to be a problem and don't support the statements you made. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Jan 14, 2009 at 3:33 PM, Stanislav Visnovsky
That's dependency problem of packages, not libzypp (and thus not YaST).
Huh? I don't see how. If I select openoffice for deletion in YaST, then I expect YaST to know that the MAIN package is selected for removal and that all other packages that depend on it are also then slated to be removed. It works if you do it BEFORE you install. It doesn't on an installed system. Packages have way too many unnecessary dependencies. I'm willing to be that less than 50% of the people who use KOrganizer even have a Palm based device. While having the necessary packages on the disk for it if you need it is one thing, they shouldn't be invoked unless you actually set it up for that device. Package modularity has been abused for far too long. Too many packages require way too many different versions of too many libraries. Then, someone "upgrades" the libraries and you have problems with compatibilty. I ran into that recently with expat. The new version didn't work with a program I needed to run, and I had to hunt for a compatibility package for it. Dependency hell isn't as bad as it used to be on SuSE years ago, but it still has a ways to go. In fact, Linux packaging is such a waste of time, resources, and disk space all the way around. Why anyone thinks that you need to craft a Firefox package not just for each distro, but for each version of each distro is beyond me. That there is the number 1 reason that Windows will continue to rule the desktop. People are used to going to firefox's website to download and install a program. Having tried that and finding it won't work in Linux makes them go elsewhere(that's just an example there are many more). Until v3. you could download and install the same firefox installer for 98, ME, 2k, XP AND Vista. Not so with firefox for Linux. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/15 Larry Stotler
On Wed, Jan 14, 2009 at 3:33 PM, Stanislav Visnovsky
wrote: That's dependency problem of packages, not libzypp (and thus not YaST).
Huh? I don't see how. If I select openoffice for deletion in YaST, then I expect YaST to know that the MAIN package is selected for removal and that all other packages that depend on it are also then slated to be removed. It works if you do it BEFORE you install. It doesn't on an installed system.
Don't you get a warning about unresolved dependencies if you try to remove something that is required by another package? Then a radio box choice of removing a package, keeping or ignoring the problem.
Packages have way too many unnecessary dependencies. I'm willing to be that less than 50% of the people who use KOrganizer even have a Palm based device. While having the necessary packages on the disk for it if you need it is one thing, they shouldn't be invoked unless you actually set it up for that device.
But ppl want "it just to work", not configure things. Are you asking for some kind of stub mechanism that installs features from packages on demand, rather than have library and suport programs on disk, which then are unused, when no Palm is detected? It's not very clear how you expect it should actually work.
Linux packaging is such a waste of time, resources, and disk space all the way around. Why anyone thinks that you need to craft a Firefox package not just for each distro, but for each version of each distro is beyond me.
There are projects which aim to make universal packages, and they are quite interesting. The reason why different distro packages are desired, is because when configuring a source package, you decide on options, that are a matter of policy. That might include compiler options, for say CPU optimisation or stack smashing prevention, or particular library support. In another instance, some distro's try a performance optimisation of loading some key frequently used libraries into a tmpfs filesystem, as part of the boot sequence. That requires the run time linker to know where to look for those libraries, which requires a linker option. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Jan 14, 2009 at 2:33 PM, Stanislav Visnovsky
On Tuesday 13 January 2009 14:24:42 Larry Stotler wrote:
[snip]
Fortunately, Linux is nowhere near that bad, but openSUSE still installs a lot of what I fell are unnecessary programs like Beagle, OpenOffice(KOffice is much better and uses less resources if you use KDE), AppArmour, etc. I realize that the devs want to make the install easier and that they choose a specific set of apps to install, but, from my experience, 90% of the people never even use a Desktop search program, so it's just a waste. Also, YaST can make it a pain to uninstall stuff. Try removing OpenOffice, AppAromour or Beagle in 11.0, and you'll get dependency complaints. If the main module of a program is selected for removal, all parts of it should be removed unless they have a dependency elsewhere(which they shouldn't). I haven't tried it in 11.1 yet.
That's dependency problem of packages, not libzypp (and thus not YaST).
FYI to remove Beagle;
Go into YaST Software Installation and do a search for "beagle". It
will list everything to do with Beagle.
Ctrl-click everything EXCEPT libbeagle - GNOME and KDE have hard
dependencies on this library, so it cannot be removed, but if
libbeagle cannot talk to the daemon, it simply does nothing.
<rant>
One thing I have a serious problem with, which is totally unfixable in
Linux if only because it is too much work on thousands of
applications, is the fact that every dependency has to be a hard one,
enforced at link time of the application.
If you have an image viewer with GIF, JPEG or PNG support, it has to
be linked against these and all of them are pulled in by ldso when the
application is started. It is absolutely no problem on a lot of other
non-Unix operating systems to pull in a shared library if you deem it
necessary at that time - for instance if you are viewing a JPEG, there
is no need to pull in GIF or PNG support until you're about to load
one.
There is a way on Linux etc. (dlopen etc.) but it's simply never used,
nor is any other method. FFMPEG sorely misses this kind of
functionality, and it's a hideous monolithic chunk of code because of
it (to add a single codec you need to update the entirity of
libavcodec and libavfile)
Even systems which are happy to link up other objects dynamically like
Gstreamer, suffer because their primary codec support is through
"gstreamer-ffmpeg".
As an example, I accidentially did rm -rf /usr/lib yesterday (typo in
an RPM spec, and I was having trouble with build so I just did it
through RPM - it's just a single file packaged anyway) and while I
killed it before it did any serious damage, SSH quit working because
it could not open "libopensc". Now, I don't use any smartcards or
other authentication like that, but this library is loaded anyway.
Imagine how much memory this uses, before it's decided it's not being
used and is paged out. There is no way for an application to use that
library as "optional".
</rant> :)
--
Matt Sealey
On Tue, 2009-01-13 at 09:36 -0600, Matt Sealey wrote:
We're not talking anymore about "KDE uses too much memory as an application" but "SUSE loads far too much on boot". It's not just the desktop.. it's every service, every module, that is installed by default and enabled by default, which significantly reduces the amount of memory available for future tasks.
This may be tangential to what you're trying to accomplish, but we're currently looking into lowering the time required to boot SLE 11/openSUSE in general. If you have concrete suggestions on how to achieve this - preferably ones that can be applied to the stock distro and don't compromise on functionality - we'd love to see them in the ideas section of: http://en.opensuse.org/Boottime/Boot_time We're especially interested in benchmarks and areas where we may be doing plain stupid stuff during boot (kernel, system or GNOME desktop). -- Hans Petter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/15 Matt Sealey
On Wed, Jan 14, 2009 at 2:33 PM, Stanislav Visnovsky
wrote:
One thing I have a serious problem with, which is totally unfixable in Linux if only because it is too much work on thousands of applications, is the fact that every dependency has to be a hard one, enforced at link time of the application.
If you have an image viewer with GIF, JPEG or PNG support, it has to be linked against these and all of them are pulled in by ldso when the application is started.
The dynamic linking finds w here the library is, but the code isn't loaded until page fault occur. The VM has to do it's magic with page tables and such, and share physical memory library code amongst many invocations, but it does it by just memory mapping in code, lazily reading it from disk, when it's unavailable. If everything was "pulled in", there'd only be the benefit of shared text pages compared to static linking, and modular updates. Some programs like perl for example, use a pluggable architecture to allow runtime selection of such support, to reduce link time, and allow usage of features without hard dependencies.
It is absolutely no problem on a lot of other non-Unix operating systems to pull in a shared library if you deem it necessary at that time - for instance if you are viewing a JPEG, there is no need to pull in GIF or PNG support until you're about to load one.
There is a way on Linux etc. (dlopen etc.) but it's simply never used, nor is any other method.
But it is where it makes sense! Perl, Python are a couple of examples.
As an example, I accidentially did rm -rf /usr/lib yesterday (typo in an RPM spec, and I was having trouble with build so I just did it through RPM - it's just a single file packaged anyway) and while I killed it before it did any serious damage, SSH quit working because it could not open "libopensc". Now, I don't use any smartcards or other authentication like that, but this library is loaded anyway. Imagine how much memory this uses, before it's decided it's not being used and is paged out. There is no way for an application to use that library as "optional".
Actually it doesn't really use much memory at all! Because it's a demand paged virtual memory system, not one using "swapping", and furthermore those pages can be shared amongst many processes thanks to COW. Just try adding up, all the virtual memory sizes of processes VSZ, RES and compare with the actual memory of the system. Another example is an X server, which often looked like a huge memory hog, when in fact a large part of it's memory consumption is the mapped memory from the graphics card, rather than system RAM. Though I'm not sure that memory is still counted in the current reporting, so I use pat tense. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Actually it doesn't really use much memory at all! Because it's a demand paged virtual memory system, not one using "swapping", and furthermore those pages can be shared amongst many processes thanks to COW.
Sorry Rob, but whether it's in physical memory or in swap it's still
loaded, it's still taking up some part of my address space.
You would nitpick about the term swap. Linux calls it swap, as badly
named as it might be, it's still swap space in this terminology, and a
page pushed out to disk is still a page allocated in the system. If
you have a 4GB address space to use and you have 3GB of it out on
disk, you still only have 1GB left whether you can fit more in
physical memory or not.
--
Matt Sealey
On Thu, Jan 15, 2009 at 9:53 AM, Rob OpenSuSE
2009/1/15 Matt Sealey
: On Wed, Jan 14, 2009 at 2:33 PM, Stanislav Visnovsky
wrote: One thing I have a serious problem with, which is totally unfixable in Linux if only because it is too much work on thousands of applications, is the fact that every dependency has to be a hard one, enforced at link time of the application.
If you have an image viewer with GIF, JPEG or PNG support, it has to be linked against these and all of them are pulled in by ldso when the application is started.
The dynamic linking finds w here the library is, but the code isn't loaded until page fault occur.
It's still parking a page for it.
The library is basically mmap'd in, which takes up no real physical
memory, but for example if you don't have enough virtual address space
to do it, it will fail. This would be an extreme case for it, but
let's give a simple example; when X starts it mmaps the entire
graphics card memory. On our 128MB systems with a 128MB graphics card,
without the swap enabled, it fails absolutely, every time.
And let's be honest here, and remind you, that on our specific system,
disk access is NOT desired because it is so slow. That it's "not
taking up physical memory!!!" is moot when it's taking up space on a
far, far slower medium (not of the order of 100MB/s slow compared to
2GB/s slow, but 1MB/s to 2GB/s slow, perhaps even worse than that
since the disk may also be in use doing something else)
On a thin client with X, it means you have to have enough memory in
the system, plus swap on NFS or so, to map the entire graphics card
memory into the address space of the driver process. Having an 8MB
graphics card on a 128MB system is great, but we can't find those, and
neither can many other people :)
--
Matt Sealey
2009/1/15 Matt Sealey
Actually it doesn't really use much memory at all! Because it's a demand paged virtual memory system, not one using "swapping", and furthermore those pages can be shared amongst many processes thanks to COW.
Sorry Rob, but whether it's in physical memory or in swap it's still loaded, it's still taking up some part of my address space.
You would nitpick about the term swap. Linux calls it swap, as badly named as it might be, it's still swap space in this terminology, and a page pushed out to disk is still a page allocated in the system. If you have a 4GB address space to use and you have 3GB of it out on disk, you still only have 1GB left whether you can fit more in physical memory or not.
Once again!! The program text segment pages are read only, they are not dirty, they are not saved to disk, because they already exist in the file system. Your on-disk copy is memory mapped in. Some embedded providers in past, using Flash or Proms instead of disk, have made kernel alterations, to run from their memory directly, rather than copy the page into RAM. Abuse and patronise me all you like, but some time spent studying VM issues, might help your low RAM system. Increasing the swappiness factor, as per Andrew Morton's view point, will save you some memory. Not huge amounts, but it'll be more signicant than whether the kernel loaded device mapper or not. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 15, 2009 at 10:42 AM, Rob OpenSuSE
Abuse and patronise me all you like, but some time spent studying VM issues, might help your low RAM system.
...
Increasing the swappiness factor, as per Andrew Morton's view point, will save you some memory. Not huge amounts, but it'll be more signicant than whether the kernel loaded device mapper or not.
1) device-mapper was an example - a VERY simple example - of something
which is loaded which has NO explicity dependency set in any other
loaded service, module or toolkit running on the system after an
Automatic Configuration. It only exists on the POSSIBILITY that
someone wants LVM2 at some point. This is inefficient by design, it is
as simple as that. That it saves 80KiB in loading the module - fringe
benefit. I am sure it allocates some more, hooks itself into several
subsystems, and then just hangs around being redundant.
We simply do not do this where I come from. If it's not used, and it
is not a dependency of any required component in the system, it don't
get run.
2) swappiness is STILL not desired on our system because I keep saying
that the disk is so goddamned slow that it actually severely impacts
the responsiveness of the system. It is NOT a solution. How.. many..
times.. do... I .... need.. to... point.. .this.. out?
3) you are not running an Efika, nor a PowerPC, so your "I don't see
it on my 256MB x86 system so I don't believe your claims"-style
statements are invalid anyway. Even with 256MB and a much faster
system (personally I have a Via EPIA, Pegasos 1GHz G4, MPC8641D dual
core 1.5GHz, a 2.4GHz Pentium 4 and a bunch of VirtualBox
installations), resource usage after boot on SUSE 11.1 compared to
10.3 is far, far higher - by something like 70MB just booting GNOME.
It is much easier to give you the example of device-mapper because it
is a service that, without LVM2, is absolutely totally redundant, and
only *needs* to be started as an explicit dependency of LVM2 support
modules (boot.lvm or boot.dmraid) and/or tools. Cups and HPLIP only
*need* to be started as explicit dependencies on *actually having a
printer* (it does not affect udev hotplug of USB printers that cups is
not running!). rpcbind only *NEEDS* to be started if a service using
rpcbind/portmap is started too. The FUSE kernel module only *needs* to
be started when you start using fusemount. Postfix is only there as a
dependency of cron (since cron needs to send mail) and it is bloated
for the purpose, there are much better solutions in use on other
distributions (Debian/Ubuntu use ssmtp).
These are very very simple dependency issues which are not solved at
some fundamental problem in the system of designing init scripts and
their order and status. I do not install systems with LVM2 yet every
system has boot.device-mapper active. This is the simplest to explain
scenario. *WHY* is this the case?
And Rob, I don't even want an answer from you, I want someone who
actually knows what they are doing, actually handles this subsystem in
SUSE, and is paying attention.
--
Matt Sealey
2009/1/15 Matt Sealey
On Thu, Jan 15, 2009 at 10:42 AM, Rob OpenSuSE
wrote:
Increasing the swappiness factor, as per Andrew Morton's view point, will save you some memory. Not huge amounts, but it'll be more signicant than whether the kernel loaded device mapper or not.
1) device-mapper was an example - a VERY simple example - of something which is loaded which has NO explicity dependency set in any other loaded service, module or toolkit running on the system after an
But none of the things you suggested explain the performance problem, you see, which is caused by a system having insufficient RAM.
2) swappiness is STILL not desired on our system because I keep saying that the disk is so goddamned slow that it actually severely impacts the responsiveness of the system. It is NOT a solution. How.. many.. times.. do... I .... need.. to... point.. .this.. out?
You're wrong. It'll allow anonymous pages to be saved to disk, once that you don't use because of these idle daemons, that you don't want to configure out. That'll happen at a slow rate, as part of the page freeing, done by the VM. Once those pages are saved on disk, you have more RAM pages for useful things like running programs and caching data.
3) you are not running an Efika, nor a PowerPC, so your "I don't see it on my 256MB x86 system so I don't believe your claims"-style statements are invalid anyway. Even with 256MB and a much faster system (personally I have a Via EPIA, Pegasos 1GHz G4, MPC8641D dual core 1.5GHz, a 2.4GHz Pentium 4 and a bunch of VirtualBox installations), resource usage after boot on SUSE 11.1 compared to 10.3 is far, far higher - by something like 70MB just booting GNOME.
This says more about you. I looked and made comparisons, I report that I do not see general bloat increase from 10.3 to 11.1 and give some expamples of lowered memory consumption. My message is you need to look elsewhere, not these general statements for solutions. I do believe you have problems, but they don't affect me, nor well specified systems that have more RAM.
modules (boot.lvm or boot.dmraid) and/or tools. Cups and HPLIP only *need* to be started as explicit dependencies on *actually having a printer* (it does not affect udev hotplug of USB printers that cups is
Desktop OS, server most ppl need to print. HPLIP as I told you before are not installed on my system, why don't you ask yourself why it is on yours?
not running!). rpcbind only *NEEDS* to be started if a service using rpcbind/portmap is started too.
Agreed, but it's not causing performance problems.
These are very very simple dependency issues which are not solved at some fundamental problem in the system of designing init scripts and their order and status. I do not install systems with LVM2 yet every system has boot.device-mapper active. This is the simplest to explain scenario. *WHY* is this the case?
And Rob, I don't even want an answer from you, I want someone who actually knows what they are doing, actually handles this subsystem in SUSE, and is paying attention.
Good luck! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
MjAwOS8xLzE1IEhhbnMgUGV0dGVyIEphbnNzb24gPGhwakBub3ZlbGwuY29tPjoKPiBXZSdyZSBlc3BlY2lhbGx5IGludGVyZXN0ZWQgaW4gYmVuY2htYXJrcyBhbmQgYXJlYXMgd2hlcmUgd2UgbWF5IGJlCj4gZG9pbmcgcGxhaW4gc3R1cGlkIHN0dWZmIGR1cmluZyBib290IChrZXJuZWwsIHN5c3RlbSBvciBHTk9NRSBkZXNrdG9wKS4KCkRvZXMgdGhpcyBpbmRpY2F0ZSB0aGF0IEtERSBpcyBub3QgaW50ZXJlc3RpbmcgaW4gdGhpcyBjYXNlPwoKSSBqdXN0IGhhZCBhbiBpbnRlcnN0aW5nIGV2ZW50IHllc3RlcmRheSB3aGVyZSBJIGdvdCBteSBzaGlueSBuZXcgU0xFRApwcmVpbnN0YWxsZWQgSFAgTWluaW5vdGUgd2l0aCBvbmx5IEdOT01FIG9uLCBhbmQgb25seSBHTk9NRSBhdmFpbGFibGUuCgpOb3cgd2UgYXJlIGEgUXQgc2hvcCwgdXNlIEtERSBhbmQgaGF2ZSBmb3IgNyB5ZWFycy4gSXQgc2VlbXMgbW9yZSBhbmQKbW9yZSBsaWtlbHkgdGhhdCB3ZSB3aWxsIGRyb3AgTm92ZWxsIGFzIGl0IGlzIGdldHRpbmcgbW9yZSBhbmQgbW9yZQphcHBhcmVudCB0aGF0IE5vdmVsbCBoYXMgbWFkZSBhIGNob2ljZSBvbiB0aGUgZGVza3RvcC4gVGhpcyBpcyBub3QgdG8KY29tcGxhaW4sIGl0wrRzIHByb2JhYmx5IHNlbnNpYmxlIGZvciBOb3ZlbGwgdG8gZm9jdXNlIG9uIG9uZSBhcmVhIGluCnRoZSBwcm9mZmVzaW9uYWwgbWFya2V0IHBsYWNlICwgYnV0IGl0wrRzIG5vdCBpbiB0aGUgaW50ZXJlc3Qgb2YgbXkKZW1wbG95ZXIuCgpSZWdhcmRzCgpCaXJnZXIK-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.orgFor additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 15, 2009 at 11:21 AM, Rob OpenSuSE
2009/1/15 Matt Sealey
: On Thu, Jan 15, 2009 at 10:42 AM, Rob OpenSuSE
wrote: This says more about you. I looked and made comparisons, I report that I do not see general bloat increase from 10.3 to 11.1 and give some expamples of lowered memory consumption.
We have a very very good SUSE guy at Genesi (Peter Czanik) who did these tests. He runs through Factory, he tests every beta, and compares them to Fedora and Ubuntu too. SUSE uses less memory than the other two, but it is still at 11.1 using far more memory than it used to.
My message is you need to look elsewhere, not these general statements for solutions.
.. right.
I do believe you have problems, but they don't affect me, nor well specified systems that have more RAM.
No shit, sherlock.
modules (boot.lvm or boot.dmraid) and/or tools. Cups and HPLIP only *need* to be started as explicit dependencies on *actually having a printer* (it does not affect udev hotplug of USB printers that cups is
Desktop OS, server most ppl need to print. HPLIP as I told you before are not installed on my system, why don't you ask yourself why it is on yours?
Because I left the installer on Automatic Configuration and somehow it decided to install it, and enable it. I do not have a printer connected on install, let alone an HP one, let alone a multifunction one. This is a decision made by the installer, automatically. Why should I be asking myself why it is installed on my system? I should be asking the SUSE developers. But, if you were paying any attention, you'd notice *this is exactly what I asked for the past 3 days on this list*. Once I have enough information on why this may be happening - because I cannot see or find the procedure in the installer or any other script or package or pattern which makes this happen - I can file a bug report on it because it is obviously absolutely the wrong thing to do. With regards to cups, this is something I could live with; as a result of Avahi being enabled on boot, which autodetects printers by mDNS, it needs something to attach them to, but first of all, I don't use Avahi, so I usually disable it. There is, however, no way to really do this cleanly except pop into a services management tool and manually kill off two services or uninstall it entirely. I would expect, then, that cups is not started since it has nothing dependent on it, no printers set up, etc.. I would also expect that improvements can be made such that Avahi - while detecting printers which may or more prudently may NOT exist on a network - does not actually require the cups daemon to be running idle until a multicast notification for a printer comes in, at which point it will notify something that can and will start up a cups daemon. In such a case, it would be started exactly when it's needed and not before. I know there are problems with FUSE - I do not use it myself so I disable it. If you start fusermount when the kernel module is not loaded, it WILL load it by itself, which is admirable behaviour. However there are quirks with permissions which mean that you cannot load a kernel module as a user (thus defeating the object of FUSE entirely IMO) plus some permissions on /dev/fuse are not set correctly. Thus, it was decided it needs to be started on boot to let people actually use it. I saw distributions looking at this bug in January 2006 and now, some 3 years later, the "let's not break fuse too much" fix is still in effect. Loading the module at boot is the simplest hackiest way to get it working. There must be a better way but since it "works" for everyone, nobody is paying attention, regardless of whether it is the best solution or not.
not running!). rpcbind only *NEEDS* to be started if a service using rpcbind/portmap is started too.
Agreed, but it's not causing performance problems.
It is not a performance issue (although the huge script for loading
rpcbind, and loading rpcbind itself takes time on boot) but a sort of
a moral, ethical issue. Should we be starting services which are
strictly dependencies on other services, for the sake of having them
around just in case they're needed?
FUSE gets used by GNOME and KDE VFS, cups may need to be around for
Avahi, but right now nothing is installed in the default configuration
(through automatic configuration, the default way to install) that
requires rpcbind and if you didn't set up an LVM disk and none were
detected in the installer, device-mapper isn't needed either (I don't
see why you can't start the lvm and device-mapper stuff when the tools
are used as fusermount does.. but oh well). They needn't be started at
all UNTIL the point when you actually need it. In the case of
something like Avahi, isn't this *WAY* past the stage that gdm has
loaded on most default configurations? It needn't be blocking gdm.
--
Matt Sealey
On Thu, Jan 15, 2009 at 07:18:06PM +0100, Birger Kollstrand wrote:
2009/1/15 Hans Petter Jansson
: We're especially interested in benchmarks and areas where we may be doing plain stupid stuff during boot (kernel, system or GNOME desktop).
Does this indicate that KDE is not interesting in this case?
I just had an intersting event yesterday where I got my shiny new SLED preinstalled HP Mininote with only GNOME on, and only GNOME available.
SLED is different from openSUSE, please don't confuse the two.
Now we are a Qt shop, use KDE and have for 7 years. It seems more and more likely that we will drop Novell as it is getting more and more apparent that Novell has made a choice on the desktop. This is not to complain, it´s probably sensible for Novell to focuse on one area in the proffesional market place , but it´s not in the interest of my employer.
No one supports KDE on a "commercial desktop" platform, so I wonder who you will be able to switch to? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 15, 2009 at 12:18 PM, Birger Kollstrand
2009/1/15 Hans Petter Jansson
: We're especially interested in benchmarks and areas where we may be doing plain stupid stuff during boot (kernel, system or GNOME desktop).
Does this indicate that KDE is not interesting in this case?
KDE won't be interesting until 4.3 gets released and it's actually usable as an enterprise desktop and not just a REALLY clever and exciting desktop for people who like the bleeding edge.
Now we are a Qt shop, use KDE and have for 7 years. It seems more and more likely that we will drop Novell as it is getting more and more apparent that Novell has made a choice on the desktop.
Novell has made the choice that KDE have all but abandoned KDE 3.5.x to concentrate on KDE 4.x, but KDE 4.x is just not ready for enterprise. It's a little different for openSUSE. I'm the president of the one-man Qt supporter's department in our company and while I would dearly, dearly love to use KDE and start shipping things built on Qt 4.5, we just can't justify waiting 9 months for something which is currently missing the very basic features of a modern desktop, and which distributions are still implementing odd hacks and workarounds and bundling ancient, unmaintained software with (Qt3 ports..) until the status quo improves. I jumped up and down when Nokia announced they were buying Trolltech, I love the new branding (makes it so much clearer than Trolltech's previous branding mishap :) and the accelerated development, and the new things happening in KDE development because of it. But they still have a year to go before they really do something truly useful with it all.
complain, it´s probably sensible for Novell to focuse on one area in the proffesional market place , but it´s not in the interest of my employer.
Unfortunately even embedded Qt 4.x development is probably going to be
restricted until KDE matures, which is probably not to Nokia's liking,
but is just the facts of life here.
--
Matt Sealey
2009/1/15 Matt Sealey
On Thu, Jan 15, 2009 at 11:21 AM, Rob OpenSuSE
wrote: 2009/1/15 Matt Sealey
: On Thu, Jan 15, 2009 at 10:42 AM, Rob OpenSuSE
wrote: Desktop OS, server most ppl need to print. HPLIP as I told you before are not installed on my system, why don't you ask yourself why it is on yours?
Because I left the installer on Automatic Configuration and somehow it decided to install it, and enable it. I do not have a printer connected on install, let alone an HP one, let alone a multifunction one. This is a decision made by the installer, automatically.
So may be it's something in GNOME that pulls it in then, as I didn't get it with KDE3 + KDE4, and I was doing a quick DVD install, rather than hand picking packages. Next time I install 11.1, I'll see if HPLIP is something I deselected. For a 128 MiB RAM board, just selecting the default automatic configuration, is unlikely to be optimal. You mentioned LTSP for instance, so the application selection would be different from a stand alone machine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 15, 2009 at 1:20 PM, Rob OpenSuSE
2009/1/15 Matt Sealey
: For a 128 MiB RAM board, just selecting the default automatic configuration, is unlikely to be optimal. You mentioned LTSP for instance, so the application selection would be different from a stand alone machine.
Also just an example. LTSP is one place we would have liked to push
these boards but the system requirements were still way too high
simply because of the architecture of LTSP.
I'm personally more used to thin clients running on top of Citrix
Metaframe, or VMWare ESX where all they have to do is connect an RDP
client - LTSP is more like running a full, heavyweight distribution
over NFS and the only benefit is lack of disks. You still need a ton
of memory (128MB is supposed to be the minimum) and a decent graphics
adapter, and enough power to run a lot of things natively, which
semi-defeats the object of having thin clients in the first place as a
cost-saving measure, although it DOES make the server side much, much
cheaper.
As an example of the whole squashfs argument, KIWI-LTSP also builds
squashfs images for the LTSP chroot :D
--
Matt Sealey
On Thu, 2009-01-15 at 19:18 +0100, Birger Kollstrand wrote:
2009/1/15 Hans Petter Jansson
:
We're especially interested in benchmarks and areas where we may be doing plain stupid stuff during boot (kernel, system or GNOME desktop).
Does this indicate that KDE is not interesting in this case?
I just had an intersting event yesterday where I got my shiny new SLED preinstalled HP Mininote with only GNOME on, and only GNOME available.
Now we are a Qt shop, use KDE and have for 7 years. It seems more and more likely that we will drop Novell as it is getting more and more apparent that Novell has made a choice on the desktop. This is not to complain, it´s probably sensible for Novell to focuse on one area in the proffesional market place , but it´s not in the interest of my employer.
I can't really speak for Novell's preload desktop policy - I suppose the vendor's preferences also come into play - however, we'd welcome efforts toward optimizing KDE. I don't have much experience with KDE code myself, though, and the same goes for the others currently involved in the desktop-end optimization. So while we'd be interested in optimized KDE packages, our resources are limited. It's an open project, though, so someone just needs to sign up and do the work (i.e. ideas, planning, implementation and QA). There's nothing stopping you from submitting performance fixes directly to the KDE packages either. -- Hans Petter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/15 Matt Sealey
On Thu, Jan 15, 2009 at 1:20 PM, Rob OpenSuSE
wrote: 2009/1/15 Matt Sealey
: For a 128 MiB RAM board, just selecting the default automatic configuration, is unlikely to be optimal. You mentioned LTSP for instance, so the application selection would be different from a stand alone machine.
Also just an example. LTSP is one place we would have liked to push these boards but the system requirements were still way too high simply because of the architecture of LTSP.
Odd because, at https://help.ubuntu.com/community/Installation/SystemRequirements Low-spec computers (Xubuntu) Recommended minimum requirements 300 MHz processor 256 MB of system memory (RAM) 8 GB of disk space Graphics card capable of 800x600 resolution Fair enough. But then : LTSP thin-client computers If you are intending to use a computer as a thin client (such as a client for an Edubuntu LTSP Terminal Server), only a low-specification computer capable of displaying graphics and connecting to a network is required. Underneath : Absolute minimum installation Absolute minimum graphical installation Intel Pentium 66 MHz processor 48 MB of system memory (RAM) 468 MB of disk space VGA graphics card -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 15, 2009 at 2:32 PM, Rob OpenSuSE
2009/1/15 Matt Sealey
: On Thu, Jan 15, 2009 at 1:20 PM, Rob OpenSuSE
wrote: 2009/1/15 Matt Sealey
: For a 128 MiB RAM board, just selecting the default automatic configuration, is unlikely to be optimal. You mentioned LTSP for instance, so the application selection would be different from a stand alone machine.
Also just an example. LTSP is one place we would have liked to push these boards but the system requirements were still way too high simply because of the architecture of LTSP.
Odd because, at https://help.ubuntu.com/community/Installation/SystemRequirements
Is this Ubuntu-Factory or openSUSE Factory? http://en.opensuse.org/LTSP#What_is_required
Low-spec computers (Xubuntu) Recommended minimum requirements 300 MHz processor 256 MB of system memory (RAM) 8 GB of disk space
Xubuntu? What does this have to do with LTSP? Either way the Efika ships with 400MHz processor, 128MB RAM and a 120GB disk right now.
Absolute minimum installation
Absolute minimum graphical installation Intel Pentium 66 MHz processor 48 MB of system memory (RAM) 468 MB of disk space VGA graphics card
That spec is absolutely bull. There is no way LTSP runs in that with
Xubuntu OR openSUSE 11.x.
--
Matt Sealey
2009/1/15 Matt Sealey
That spec is absolutely bull. There is no way LTSP runs in that with Xubuntu OR openSUSE 11.x.
No it'd be an LTSP set up, not Xubuntu. Reviews of LTSP have emphasised that it runs on older otherwise unusable hardware, so your findings are suprising. It should let you just run an xserver, no desktop, and do remote login, or it's a pointless project. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 15, 2009 at 2:45 PM, Rob OpenSuSE
2009/1/15 Matt Sealey
: That spec is absolutely bull. There is no way LTSP runs in that with Xubuntu OR openSUSE 11.x.
No it'd be an LTSP set up, not Xubuntu. Reviews of LTSP have emphasised that it runs on older otherwise unusable hardware, so your findings are suprising.
Do you follow LTSP at all? :)
It should let you just run an xserver, no desktop, and do remote login, or it's a pointless project.
Even a remote X session uses local resources for bitmap caching and the like.
--
Matt Sealey
On Thu, Jan 15, 2009 at 2:47 PM, Matt Sealey
On Thu, Jan 15, 2009 at 2:45 PM, Rob OpenSuSE
wrote: 2009/1/15 Matt Sealey
: That spec is absolutely bull. There is no way LTSP runs in that with Xubuntu OR openSUSE 11.x.
No it'd be an LTSP set up, not Xubuntu. Reviews of LTSP have emphasised that it runs on older otherwise unusable hardware, so your findings are suprising.
FYI, the real Edubuntu LTSP requirements;
https://help.ubuntu.com/community/HowToCookEdubuntu/Chapters/HardwareRequire...
Note; 48MB of RAM in the client about gets you an xterm. Firefox etc.
run very badly in a remote session because of the way it caches
bitmaps. OpenOffice or any other office client is just as bad. The
LTSP page mentions watching multimedia clips - ha. Good luck.
The recommended specs; we meet them, but this is still barely useful
under LTSP. We actually had the resources to try out a system based on
a Sun T1000 and multiple networked clients;
http://projects.powerdeveloper.org/project/efika/338
Works well enough.
--
Matt Sealey
2009/1/15 Greg KH
On Thu, Jan 15, 2009 at 07:18:06PM +0100, Birger Kollstrand wrote:
2009/1/15 Hans Petter Jansson
: We're especially interested in benchmarks and areas where we may be doing plain stupid stuff during boot (kernel, system or GNOME desktop).
Does this indicate that KDE is not interesting in this case?
I just had an intersting event yesterday where I got my shiny new SLED preinstalled HP Mininote with only GNOME on, and only GNOME available.
SLED is different from openSUSE, please don't confuse the two. Yes I'm aware of that Greg.
Now we are a Qt shop, use KDE and have for 7 years. It seems more and more likely that we will drop Novell as it is getting more and more apparent that Novell has made a choice on the desktop. This is not to complain, it´s probably sensible for Novell to focuse on one area in the proffesional market place , but it´s not in the interest of my employer.
No one supports KDE on a "commercial desktop" platform, so I wonder who you will be able to switch to?
Mandriva. cu
On Thu, Jan 15, 2009 at 11:16:32PM +0100, Birger Kollstrand wrote:
Now we are a Qt shop, use KDE and have for 7 years. It seems more and more likely that we will drop Novell as it is getting more and more apparent that Novell has made a choice on the desktop. This is not to complain, it´s probably sensible for Novell to focuse on one area in the proffesional market place , but it´s not in the interest of my employer.
No one supports KDE on a "commercial desktop" platform, so I wonder who you will be able to switch to?
Mandriva.
Ah, nice, I forgot about them. Best of luck to them and to you, they probably need the customers :) thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/15 Matt Sealey
On Thu, Jan 15, 2009 at 2:47 PM, Matt Sealey
wrote: On Thu, Jan 15, 2009 at 2:45 PM, Rob OpenSuSE
wrote: 2009/1/15 Matt Sealey
: That spec is absolutely bull. There is no way LTSP runs in that with Xubuntu OR openSUSE 11.x.
No it'd be an LTSP set up, not Xubuntu. Reviews of LTSP have emphasised that it runs on older otherwise unusable hardware, so your findings are suprising.
FYI, the real Edubuntu LTSP requirements;
https://help.ubuntu.com/community/HowToCookEdubuntu/Chapters/HardwareRequire...
Note; 48MB of RAM in the client about gets you an xterm. Firefox etc. run very badly in a remote session because of the way it caches bitmaps. OpenOffice or any other office client is just as bad. The LTSP page mentions watching multimedia clips - ha. Good luck.
That page is inline with the previous "low end graphical station",
they recommend a low end machine for it.
Recommended specs
400Mhz with 128MB ram and PXE boot capabilities.
That's more like it and more plausible, so KDE4 likes at least 384 MiB
really, 38Xfce/LXDE need about 256, and LSTP 128.
You're talking about a project that has been going for years, as an
independant distro, has been reviewed frequently and spawned
educational thin client projects, as a way of using old machines.
400Mhz plus 128 MiB was a standard machine in mid 2000. If it was
not lighter than Xfce/LXDE locally, they'd loose one of the reasons to
use it.
2009/1/15 Matt Sealey
That spec is absolutely bull. There is no way LTSP runs in that with Xubuntu OR openSUSE 11.x.
Rather suggested that you thought, that you needed to run a desktop locally.
2009/1/15 Matt Sealey
Also just an example. LTSP is one place we would have liked to push these boards but the system requirements were still way too high simply because of the architecture of LTSP.
The recommendations you've found would imply otherwise. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
On Friday 09 January 2009 08:54:44 am Rafa Grimán wrote:
Hi :)
...
Does smolt distinguish between two different computers and two installations (reinstallation, for example) of the same computer?
I ask this because I have different scenarios:
1.- say you install openSUSE 11.1 and then you reinstall because you goofed up. Would that count as 1 installation and smolt would not resend the info? Or does smolt count that as 2 different systems and resends the info as if it were a different computer?
2.- Say you were a Fedora user and you added your computer to the smolt statistics. A couple of months later you discover openSUSE, get rid of Fedora never to go back and install openSUSE 11.1. Would that also be counted as a new computer?
3.- What if you have a partition with openSUSE 11.0 from which you've already run smolt and decide to upgrade to 11.1? Is that a new computer added to the smolt statistics?
4.- What if you have 1 partition with openSUSE 11.0 with which you sent all the info to smolt web and you install openSUSE 11.1 on another partition and all the info gets sent back to smolt's web. Is that counted as a new/another different computer?
Been looking for the answers to these questions on smolt's web but haven't found it. Maybe looking in the wrong place? Any ideas?
When you run smolt it will create unique ID in /etc/smolt . If it is deleted them machine will be counted again.
To remedy this as much as possible they count, for statistics page, only last 90 days.
There is a problem with this: even if you keep using the same machine and installation for a year, you will be removed from the database, unless you manually update it periodically. Smolt is designed to update this info automatically, but it depends on a cron job: 20 1 1 * * smolt /usr/bin/smoltSendProfile -c > /dev/null 2>&1 and that means that if your machine is not running the first day of the month at 1:20 AM, the profile will not be sent. Worse, the "-c" above means that the program will sleep for a random period of up to three days before it will actually sends the profile: * All this means that the profile for non server machines * * running 7*24, will be automatically removed from the stats * * after 90 days. * I opened a bugzilla so that Novell changes the cron job to /etc/cron.daily/, but it has been dismissed. No, I will not report upstream, this is a packaging problem here, IMO: the /etc/cron.daily/ is a SuSE feature, AFAIK. There is also a /etc/init.d/smolt service, purpose unknown, and dissabled by default. So, the answer to Rafa's question is tha the profile should be removed from the stats after three months if the machine/install is not active, and that it will be counted as many times as you install it in the same machine in that period, because the UUID file is different. As always, statistics will be biassed, but be considered correct. ;-| - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklwdBIACgkQtTMYHG2NR9VWsgCdGO7vajHtTv/q74/HThDxg1+U p4YAn03nFw39i+WJ6YqdtrcVwqRPG//n =n/cb -----END PGP SIGNATURE-----
On Monday 12 of January 2009 04:48:41 Space Case wrote:
So I try it, and on both machines get this:
(x86-64: bunch of file traces, then) File "/usr/lib64/python2.6/site-packages/urlgrabber/sslfactory.py", line 63, in create_opener return m2urllib2.build_opener(self.ssl_context, *handlers) File "/usr/lib64/python2.6/site-packages/M2Crypto/m2urllib2.py", line 112, in build_opener if inspect.isclass(check): NameError: global name 'inspect' is not defined
or (i586: bunch of file traces, then) File "/usr/lib/python2.6/site-packages/urlgrabber/sslfactory.py", line 63, in create_opener return m2urllib2.build_opener(self.ssl_context, *handlers) File "/usr/lib/python2.6/site-packages/M2Crypto/m2urllib2.py", line 112, in build_opener if inspect.isclass(check): NameError: global name 'inspect' is not defined
This is strange. You use a Python from Factory (or OBS), don't you? The 2.6 was splitted and inspect is in python-base package. But a python require python-base, so maybe zypper verify should helps. Be sure that you have a python-base (and python) installed. If it will not work, then bugzilla. Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, Carlos E. R. wrote:
There is a problem with this: even if you keep using the same machine and installation for a year, you will be removed from the database, unless you manually update it periodically. [...] I opened a bugzilla so that Novell changes the cron job to /etc/cron.daily/, but it has been dismissed. No, I will not report upstream, this is a packaging problem here, IMO: the /etc/cron.daily/ is a SuSE feature, AFAIK.
It is not. This is a bug in the handling of smolt. Why wont you report it upstream?
There is also a /etc/init.d/smolt service, purpose unknown, and dissabled by default.
This triggers if data gets sent by smoltSendProfile or not. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-01-16 at 13:40 +0100, Henne Vogelsang wrote:
Hi,
Carlos E. R. wrote:
There is a problem with this: even if you keep using the same machine and installation for a year, you will be removed from the database, unless you manually update it periodically. [...] I opened a bugzilla so that Novell changes the cron job to /etc/cron.daily/, but it has been dismissed. No, I will not report upstream, this is a packaging problem here, IMO: the /etc/cron.daily/ is a SuSE feature, AFAIK.
It is not. This is a bug in the handling of smolt. Why wont you report it upstream?
- Because the people insterested in getting good and reliable stats are the distributors, not the users. - Because I din't find how, I'm not aquainted with fedora, I don't have an account with their bugzilla, and I didn't find it. (1) - It has taken me "years" to become aquainted with Novell's bugzilla, how to express my points, how to argue them. I can't do the same with fedorans, and I will be ignored. - Because I'm not an expert in Smolt, and I find the documentation very lacking (and no, I can not write docs if I'm not an expert). And not being an expert, I can not argue my point with them. - Why do I have to report a problem upstream, when we report all problems found to Novell's Bugzilla? Surely you don't want us to subscribe to the billion bug reporting systems upstream of all packages? And I still think that /etc/cron.daily/ is a SuSE feature, as the /usr/lib/cron/run-crons is "Copyright (c) 1998-2001 SuSE GmbH Nuernberg".
There is also a /etc/init.d/smolt service, purpose unknown, and dissabled by default.
This triggers if data gets sent by smoltSendProfile or not.
Undocumented. Do you mean that if I manually send data somehow it runs insserv on smolt? (1) The link for reporting upstream is https://fedorahosted.org/smolt/report. It says: «Note: See TracReports for help on using and creating reports.» That help text in unintelible for me, almost like programesse. Without 'almost': ]Example: All active tickets, sorted by priority and time ] ] SELECT id AS ticket, status, severity, priority, owner, ] time as created, summary FROM ticket ] WHERE status IN ('new', 'assigned', 'reopened') ] ORDER BY priority, time How on earth am I going to use that? There is also a "Help/Guide" button on top, which takes me to a «The Trac User and Administration Guide». Administration!? Im sorry, but that sent me running for my life, and I'm not going back there. :-/ Just compare to http://en.opensuse.org/Submitting_Bug_Reports and http://en.opensuse.org/Bug_Reporting_FAQ. Home, sweet home! - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklwicEACgkQtTMYHG2NR9VYswCeM4jyZ4W/bPxvw2Lzza5uUJon GYEAn1uLb9ouU/odLn9GjExnTvp2ow3b =ryQa -----END PGP SIGNATURE-----
Hi, Carlos E. R. wrote:
On Friday, 2009-01-16 at 13:40 +0100, Henne Vogelsang wrote:
Carlos E. R. wrote:
There is a problem with this: even if you keep using the same machine and installation for a year, you will be removed from the database, unless you manually update it periodically. [...] I opened a bugzilla so that Novell changes the cron job to /etc/cron.daily/, but it has been dismissed. No, I will not report upstream, this is a packaging problem here, IMO: the /etc/cron.daily/ is a SuSE feature, AFAIK.
It is not. This is a bug in the handling of smolt. Why wont you report it upstream?
- Because the people insterested in getting good and reliable stats are the distributors, not the users. - Because I din't find how, I'm not aquainted with fedora, I don't have an account with their bugzilla, and I didn't find it. (1) - It has taken me "years" to become aquainted with Novell's bugzilla, how to express my points, how to argue them. I can't do the same with fedorans, and I will be ignored. - Because I'm not an expert in Smolt, and I find the documentation very lacking (and no, I can not write docs if I'm not an expert). And not being an expert, I can not argue my point with them. - Why do I have to report a problem upstream, when we report all problems found to Novell's Bugzilla? Surely you don't want us to subscribe to the billion bug reporting systems upstream of all packages?
If you dont want to help then let it be. Then i have to do it...
And I still think that /etc/cron.daily/ is a SuSE feature, as the /usr/lib/cron/run-crons is "Copyright (c) 1998-2001 SuSE GmbH Nuernberg".
Dude. I already told you that this cronjob comes from the smolt project. This has nothing to do with the cron package or its contents. And its not even the cronjobs fault as you noted in you initial report. Its the whole setup that is flawed.
There is also a /etc/init.d/smolt service, purpose unknown, and dissabled by default.
This triggers if data gets sent by smoltSendProfile or not.
Undocumented.
smoltSendProfile -h | grep -A 1 -- -c -c, --checkin this is an automated checkin, will only run if the "smolt" service has been started
Do you mean that if I manually send data somehow it runs insserv on smolt?
No. There is a cronjob that runs "smoltSendProfile -c". It only sends data if there is a specific file (/var/lock/subsys/smolt). The smolt "service" does nothing else than to touch or remove that file.
(1) The link for reporting upstream is https://fedorahosted.org/smolt/report.
It says: «Note: See TracReports for help on using and creating reports.»
That help text in unintelible for me [...] Im sorry, but that sent me running for my life, and I'm not going back there. :-/
You need a login there. Like you need a login in our bugzilla. Nothig that special... https://admin.fedoraproject.org/accounts/user/new Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, Jan 15, 2009 at 6:21 PM, Rob OpenSuSE
2009/1/15 Matt Sealey
: Rather suggested that you thought, that you needed to run a desktop locally.
The X server DOES run locally. That and every bitmap caching part of the server, and any other features that run on the local machine. Having a 64/128MB graphics card - as I previously stated - requires swap space to mmap the memory to get X running in the first place. There's usually not that much memory left if you're running over NFS. Apps like Firefox and so on require far too much memory - OpenOffice is another culprit. Basically anything you wanted to run "on the server" actually just leaves it's processing requirements on the server, but passes everything to do with the display - including heavy memory use and caching - back to the thin client.
2009/1/15 Matt Sealey
: Also just an example. LTSP is one place we would have liked to push these boards but the system requirements were still way too high simply because of the architecture of LTSP.
The recommendations you've found would imply otherwise.
Have you even tried it?
--
Matt Sealey
2009/1/16 Matt Sealey
On Thu, Jan 15, 2009 at 6:21 PM, Rob OpenSuSE
wrote: 2009/1/15 Matt Sealey
: Rather suggested that you thought, that you needed to run a desktop locally.
The X server DOES run locally. That and every bitmap caching part of the server, and any other features that run on the local machine. Basically anything you wanted to run "on the server" actually just leaves it's processing requirements on the server, but passes everything to do with the display - including heavy memory use and caching - back to the thin client.
That's how it's supposed to work.
Apps like Firefox and so on require far too much memory - OpenOffice is another culprit.
The server does need decent amount of RAM, processing for multiple interactive users, though generally they share programs so less would be required overall.
2009/1/15 Matt Sealey
: Also just an example. LTSP is one place we would have liked to push these boards but the system requirements were still way too high simply because of the architecture of LTSP.
The recommendations you've found would imply otherwise.
Have you even tried it?
Not with your hardware. However, I can run OOo remotely, but not disabling encryption and am pleasantly suprised by how well OOo runs, given your comments. Initial delay on menu, is pretty normal. Opening a document is faster, using application server, and writing is not laggy. Spelling check seems instaneous as does typing text. The RES set of the X server is under 12,000 nowhere near what you report. It's an old 64MiB Matrox card. Having supported DTP for years with application servers, this is actually working better straight off, than old black & white over ethernet. Removing encryption layer might be a benefit.. I find nothing to doubt LTSP project claims, nor the reviews. I'd be happy to support a thin client solution on x86. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jan 16, 2009 at 11:12 AM, Rob OpenSuSE
2009/1/16 Matt Sealey
: On Thu, Jan 15, 2009 at 6:21 PM, Rob OpenSuSE
wrote: 2009/1/15 Matt Sealey
: Rather suggested that you thought, that you needed to run a desktop locally.
The X server DOES run locally. That and every bitmap caching part of the server, and any other features that run on the local machine. Basically anything you wanted to run "on the server" actually just leaves it's processing requirements on the server, but passes everything to do with the display - including heavy memory use and caching - back to the thin client.
That's how it's supposed to work.
No shit, sherlock. The problem is your thin client now has a memory burden of a web browser which has memory requirements almost totally made up of bitmap caches - the rendered page, the images on each one. Firefox 3 is a little lighter but it's just not designed for thin client usage. Neither is X in itself.
Apps like Firefox and so on require far too much memory - OpenOffice is another culprit.
The server does need decent amount of RAM, processing for multiple interactive users, though generally they share programs so less would be required overall.
That's not what I meant. The thin client needs an inordinate amount of memory to provide storage for all the data they try and push to the client. Far more than you would really like. It pretty much means a decent LTSP setup with most remote apps requires local swap space (which defeats the principle of a diskless client) or fall back to swap-over-NFS (which isn't bad, in fact it's faster in terms of bandwidth on the Efika, just much higher latency).
2009/1/15 Matt Sealey
: Also just an example. LTSP is one place we would have liked to push these boards but the system requirements were still way too high simply because of the architecture of LTSP.
The recommendations you've found would imply otherwise.
Have you even tried it?
Not with your hardware.
Oh, like that matters. The last time I tried it (using K12) was with x86 clients with 128MB memory. The idea was to use AMD PIC (decTOP) with Geodes in. Those systems ship with 10GB disks but that's by-the-by, I wanted it to work without that. Even with some tuning, it plainly didn't work as well as advertised. The most common LTSP configuration out there is not with thin clients at all, but "PCs from a couple of years ago" which have been deemed "not capable of running Vista and we have no money to upgrade". The average configuration has a lot more RAM (I had a lot of discussions about Via EPIA boards with a cheap 512MB stick, or Atom boards these days, and the end result was a lot of people saying "it's not saving us any money to downgrade the cost difference is $2" - no help at all) Add to that, half the apps you want to run, don't. https://bugs.launchpad.net/ubuntu/+source/nspr/+bug/269188 Quite a lot of developers don't test their apps on terminal server on Windows, and even though X is built to be run by remote (local clients are a modern pleasure! but I would not go back to running a huge SGI or Sun box in the server room for daily work :) Linux/BSD developers rarely work that way or run real graphical apps on the server.
I find nothing to doubt LTSP project claims, nor the reviews.
I really am not talking about you opening OpenOffice from your 8GB dual-core on your other 8GB dual-core. Are you actually running LTSP or have you set any clients up for a test?
happy to support a thin client solution on x86.
I'm sure you would, and I'm sure you'd have greater success, because
most x86 boards have upgradable RAM. However meeting the minimum
specifications these days isn't enough unless you are looking to
basically run xterms.
--
Matt Sealey
On Friday 16 January 2009, Matt Sealey wrote:
No shit, sherlock.
ya got that bit wrong as well .. Noe Schitt-Sherlock but Schitt-Happens Pete . -- SuSE Linux 10.3-Alpha3. (Linux is like a wigwam - no Gates, no Windows, and an Apache inside.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/16 Matt Sealey
That's not what I meant. The thin client needs an inordinate amount of memory to provide storage for all the data they try and push to the client. Far more than you would really like. It pretty much means a decent LTSP setup with most remote apps requires local swap space (which defeats the principle of a diskless client) or fall back to swap-over-NFS (which isn't bad, in fact it's faster in terms of bandwidth on the Efika, just much higher latency).
It's simple, Matt you told me running OOo remotely like that would cause 100MiB system RAM in the X server, and that the hardware RAM would be mapped in swap. I tried it, and the numbers reported were very much lower. OOo behaved very similarly to DTP publishing software I supported using that method. Frankly, if it's all so hopeless, I wonder why you bother with the boards. You're basically telling everyone that they lack the grunt needed to run general purpose openSUSE usefully, even as a thin client now. If you believe 128MiB doesn't suffice, because of X memory requirement, then you are left with IBM 3270 terminal emulation or something. Surely you should be talking the things up! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 16 January 2009 05:48:28 am Carlos E. R. wrote:
So, the answer to Rafa's question is tha the profile should be removed from the stats after three months if the machine/install is not active, and that it will be counted as many times as you install it in the same machine in that period, because the UUID file is different.
As always, statistics will be biassed, but be considered correct. ;-|
Depends what you are looking for. If you know how data are acquired then you will not take numbers of machines as absolute truth, but in any case you will have some data about used hardware, how good it works. Of course there is many ways to improve data collection. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Jan 16, 1:29pm, Michal Vyskocil wrote: } Subject: Re: [opensuse-factory] Plan for 11.2?
On Monday 12 of January 2009 04:48:41 Space Case wrote:
File "/usr/lib/python2.6/site-packages/M2Crypto/m2urllib2.py", line 112, in build_opener if inspect.isclass(check): NameError: global name 'inspect' is not defined
This is strange. You use a Python from Factory (or OBS), don't you? The 2.6 was splitted and inspect is in python-base package. But a python require python-base, so maybe zypper verify should helps.
python-2.6.0-4.1 python-base-2.6.0-4.1 (and a whole bunch other python packages) raid:~ # rpm -V python raid:~ # rpm -V python-base raid:~ #
Be sure that you have a python-base (and python) installed. If it will not work, then bugzilla.
I get python from the development branch: http://ftp-1.gwdg.de/pub/opensuse/repositories/devel:/languages:/python/open... Would that still be legitimate to file a bug against? Thanks, Steve -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi :) El Friday 16 January 2009, Henne Vogelsang escribió:
Hi,
Carlos E. R. wrote:
On Friday, 2009-01-16 at 13:40 +0100, Henne Vogelsang wrote:
Carlos E. R. wrote:
There is a problem with this: even if you keep using the same machine and installation for a year, you will be removed from the database, unless you manually update it periodically.
[...]
I opened a bugzilla so that Novell changes the cron job to /etc/cron.daily/, but it has been dismissed. No, I will not report upstream, this is a packaging problem here, IMO: the /etc/cron.daily/ is a SuSE feature, AFAIK.
It is not. This is a bug in the handling of smolt. Why wont you report it upstream?
- Because the people insterested in getting good and reliable stats are the distributors, not the users. - Because I din't find how, I'm not aquainted with fedora, I don't have an account with their bugzilla, and I didn't find it. (1) - It has taken me "years" to become aquainted with Novell's bugzilla, how to express my points, how to argue them. I can't do the same with fedorans, and I will be ignored. - Because I'm not an expert in Smolt, and I find the documentation very lacking (and no, I can not write docs if I'm not an expert). And not being an expert, I can not argue my point with them. - Why do I have to report a problem upstream, when we report all problems found to Novell's Bugzilla? Surely you don't want us to subscribe to the billion bug reporting systems upstream of all packages?
If you dont want to help then let it be. Then i have to do it...
He's not saying he doesn't want to help nor is he "not helping". At least IMHO he helps quite a lot on the mailing lists. Anyways, getting back to the subject. IMHO, Carlos has a point: - do we have to open bug reports upstream or do we have to open bug reports in Novell's bugzilla? After all, we're openSUSE users. - do you suggest we open bug reports upstream for every package? Then why on Earth would we be using openSUSE, we should be using LFS. IMHO, we use openSUSE because it's our "interface" to the developer Community - Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them. YOU (Novell/SUSE) are our (users) interface to the developer community. - Do we have to subscribe to endless mailinglists of all the packages openSUSE has? No, we don't. I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners), that's why I think Novell/SUSE should be the one that receives our "complaints" and Novell/SUSE forwards them upstream, not us (end users). Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, Jan 21, 2009 at 14:17, Rafa Grimán
Hi :) Anyways, getting back to the subject. IMHO, Carlos has a point:
- do we have to open bug reports upstream or do we have to open bug reports in Novell's bugzilla? After all, we're openSUSE users.
- do you suggest we open bug reports upstream for every package? Then why on Earth would we be using openSUSE, we should be using LFS. IMHO, we use openSUSE because it's our "interface" to the developer Community
- Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them. YOU (Novell/SUSE) are our (users) interface to the developer community.
- Do we have to subscribe to endless mailinglists of all the packages openSUSE has? No, we don't.
I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners), that's why I think Novell/SUSE should be the one that receives our "complaints" and Novell/SUSE forwards them upstream, not us (end users). IOW, we report bugs to _our_ source, in this case openSUSE. Our upstream is openSUSE. This might sound harsh but it has to be said.
ne... -- Registered Linux User # 125653 (http://counter.li.org) Now accepting personal mail for GMail invites. George Burns - "You can't help getting older, but you don't have to get old." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/21 ne...
I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners), that's why I think Novell/SUSE should be the one that receives our "complaints" and Novell/SUSE forwards them upstream, not us (end users).
IOW, we report bugs to _our_ source, in this case openSUSE. Our upstream is openSUSE. This might sound harsh but it has to be said.
We're a community, not paying customers. Sometimes it makes sense for the bug to go upstream, and we can help by following the issue up. At first it may appear (as in this case) like a packaging issue, with a script not adapted from Fedora. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, on 01/21/2009 03:17 PM Rafa Grimán wrote:
El Friday 16 January 2009, Henne Vogelsang escribió:
Carlos E. R. wrote:
- Why do I have to report a problem upstream, when we report all problems found to Novell's Bugzilla? Surely you don't want us to subscribe to the billion bug reporting systems upstream of all packages?
If you dont want to help then let it be. Then i have to do it...
He's not saying he doesn't want to help nor is he "not helping". At least IMHO he helps quite a lot on the mailing lists.
That was not what i was saying. I was saying if he does not want to help _me_ with _this_ then say so and i do it myself.
Anyways, getting back to the subject. IMHO, Carlos has a point:
- do we have to open bug reports upstream or do we have to open bug reports in Novell's bugzilla? After all, we're openSUSE users.
Depends on the bug. If you are unsure i suggest you go first with the the openSUSE bugzilla.
- do you suggest we open bug reports upstream for every package?
What makes you think i would suggest that? See above...
- Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them.
Erm wtf? I don't even know how to respond to that.
YOU (Novell/SUSE) are our (users) interface to the developer community.
You are a very demanding person aren't you? Should i maybe also bring you coffee and your slippers in the morning. Or maybe wash you car? Get real. I simply asked Carlos, who is very much capable of doing so, to report a bug upstream. There is no general rule where to report bugs implied. There is not implied that i don't want to receive bugreports for my packages. I find your mail pretty insulting. Thanks. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi :) El Wednesday 21 January 2009, Henne Vogelsang escribió:
Hi,
on 01/21/2009 03:17 PM Rafa Grimán wrote:
El Friday 16 January 2009, Henne Vogelsang escribió:
Carlos E. R. wrote:
- Why do I have to report a problem upstream, when we report all problems found to Novell's Bugzilla? Surely you don't want us to subscribe to the billion bug reporting systems upstream of all packages?
If you dont want to help then let it be. Then i have to do it...
He's not saying he doesn't want to help nor is he "not helping". At least IMHO he helps quite a lot on the mailing lists.
That was not what i was saying. I was saying if he does not want to help _me_ with _this_ then say so and i do it myself.
Sorry,. I misunderstood what you wrote 0:)
Anyways, getting back to the subject. IMHO, Carlos has a point:
- do we have to open bug reports upstream or do we have to open bug reports in Novell's bugzilla? After all, we're openSUSE users.
Depends on the bug. If you are unsure i suggest you go first with the the openSUSE bugzilla.
- do you suggest we open bug reports upstream for every package?
What makes you think i would suggest that? See above...
As I said, I misunderstood what you wrote.
- Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them.
Erm wtf? I don't even know how to respond to that.
YOU (Novell/SUSE) are our (users) interface to the developer community.
You are a very demanding person aren't you? Should i maybe also bring you coffee and your slippers in the morning. Or maybe wash you car?
I don't drink coffee (in fact, I don't drink any caffeinated drink) nor have a car ;) So, no thanks. No need for that. Regarding the slippers, I like walking barefooted. In any case, thanks for the offering, greatly appreciated :) Anyways, me demanding? Just because I say that Novell/SUSE is our interface to the developer community? I don't get it. If you're saying I'm demanding because I wrote: "Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them." Then take into account: 1.- I said I'm sorry that I misunderstood your previous e-mail 2.- that I also said that I know what it's like, because I have the same response e-mails regarding 3rd party products. It's in the part you omitted: "I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners) [...]"
Get real. I simply asked Carlos, who is very much capable of doing so, to report a bug upstream. There is no general rule where to report bugs implied.
That's why I asked these questions: I misunderstood what you wrote.
There is not implied that i don't want to receive bugreports for my packages.
I find your mail pretty insulting. Thanks.
Mine? At least I don't write "wtf" or "Get real". I was just asking questions. I didn't think you were going to get so upset with my questions. My bad. Have a nice day. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, on 01/21/2009 04:48 PM Rafa Grimán wrote:
El Wednesday 21 January 2009, Henne Vogelsang escribió:
on 01/21/2009 03:17 PM Rafa Grimán wrote:
Carlos E. R. wrote:
If you dont want to help then let it be. Then i have to do it... He's not saying he doesn't want to help nor is he "not helping". At least IMHO he helps quite a lot on the mailing lists. That was not what i was saying. I was saying if he does not want to help _me_ with _this_ then say so and i do it myself.
Sorry,. I misunderstood what you wrote 0:)
Fair enough, no problem :) Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/1/21 ne...
: I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners), that's why I think Novell/SUSE should be the one that receives our "complaints" and Novell/SUSE forwards them upstream, not us (end users).
IOW, we report bugs to _our_ source, in this case openSUSE. Our upstream is openSUSE. This might sound harsh but it has to be said.
We're a community, not paying customers. Sometimes it makes sense for the bug to go upstream, and we can help by following the issue up. At first it may appear (as in this case) like a packaging issue, with a script not adapted from Fedora. They is no doubt that a case can be made for bugs to go directly upstream. However, with the 'dumbing down/easing of use' of Linux, that kinda goes out the window. It is far easier for bugs to be reported in one place for triaging,
On Wed, Jan 21, 2009 at 15:07, Rob OpenSuSE
On Wed, 21 Jan 2009, Rafa Grimán wrote:
- Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them. YOU (Novell/SUSE) are our (users) interface to the developer community.
Nonononononono! If anything, WE as the openSUSE developer/tester/... community are the interface for our users community.
I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners), that's why I think Novell/SUSE should be the one that receives our "complaints" and Novell/SUSE forwards them upstream, not us (end users).
Novell employees are part of the openSUSe developer/tester/... and of course the openSUSE user communities, and an important part of both. However, I most strongly disagree with any assessment that has openSUSE users on one side and Novell on the other in a classic customer-supplier pattern as you seem to describe. Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex
On Thu, 15 Jan 2009, Greg KH wrote:
No one supports KDE on a "commercial desktop" platform, so I wonder who you will be able to switch to?
Uhh? Surely Novell does in case of SLED, and I believe so does Red Hat. Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sunday 01 February 2009 11:46:14 am Gerald Pfeifer wrote:
On Wed, 21 Jan 2009, Rafa Grimán wrote:
- Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them. YOU (Novell/SUSE) are our (users) interface to the developer community.
Nonononononono! If anything, WE as the openSUSE developer/tester/... community are the interface for our users community.
I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners), that's why I think Novell/SUSE should be the one that receives our "complaints" and Novell/SUSE forwards them upstream, not us (end users).
Novell employees are part of the openSUSe developer/tester/... and of course the openSUSE user communities, and an important part of both.
However, I most strongly disagree with any assessment that has openSUSE users on one side and Novell on the other in a classic customer-supplier pattern as you seem to describe.
Gerald
It is more convenient pattern for many using openSUSE. Me (user) complain and then wait until someone offers solution. Me actively debugging takes more time, specially if I'm not familiar with it and all I can do is to execute command and post output. On the other hand, it is good that Rafa posted his view, as it is the very common way people take openSUSE, so dicussing it will be beneficial for everyone. I really appreciate calls for help from Xorg and KDE teams. It can help to develop understanding that resources of SUSE and Novell are not endless and much more can be achived if other jump in and help. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Søndag 01 februar 2009 20:52:16 skrev Gerald Pfeifer:
On Thu, 15 Jan 2009, Greg KH wrote:
No one supports KDE on a "commercial desktop" platform, so I wonder who you will be able to switch to?
Uhh? Surely Novell does in case of SLED, and I believe so does Red Hat.
Sure do, and so do Mandriva, Xandros, PC-BSD, Red Flag, Turbolinux... I can think of only one commercial distribution that _doesn't_ support KDE, and if there's any truth to their announcements that's a temporary situation. (Actually technically Canoncical still support KDE in Ubuntu 6.06 for a few more months). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi :) El Sunday 01 February 2009, Gerald Pfeifer escribió:
On Wed, 21 Jan 2009, Rafa Grim�n wrote:
- Yes, I agree: smolt is NOT a Novell/SUSE project, but you're packaging it. If you don't like receiving mails about those packages: DON'T package them. YOU (Novell/SUSE) are our (users) interface to the developer community.
Nonononononono! If anything, WE as the openSUSE developer/tester/... community are the interface for our users community.
First of all, there was a misunderstanding on my behalf of what Henne wrote. I apologized and Henne seems to agree I messed up so all was settled :) I think we're both saying the same thing: Novell/SUSE is the interface between FLOSS projects and (open)SUSE user base. So I'm glad we both agree :)
I know what it is to work at a vendor and I know what it's like to be the interface between users and 3rd party vendors (aka Partners), that's why I think Novell/SUSE should be the one that receives our "complaints" and Novell/SUSE forwards them upstream, not us (end users).
Novell employees are part of the openSUSe developer/tester/... and of course the openSUSE user communities, and an important part of both.
However, I most strongly disagree with any assessment that has openSUSE users on one side and Novell on the other in a classic customer-supplier pattern as you seem to describe.
I guess I didn't explain myself correctly with the paragraph you quote (which I wrote). What I'm saying is that I know what it's like to work at a sw/hw vendor. You get requests from your user base regarding some of your own products and some products which are not really yours (3rd party) which in this case is smolt (smolt was born under Fedora's "protection", even though it's FLOSS so it's not a Novell/SUSE project originally). I'm not saying Novell works like a "typical vendor". What I meant is that I know what it's like to be "in the middle" or "between" an end user and a product/sw/service/you_name_it which is not yours but you deliver/sell/offer/distribute/you_name_it. What I was trying to say is that since openSUSE is a Novell "product", we (openSUSE/SLES/SLED user base) should not have to report bugs upstream to the original project (be it KDE, GNOME, smolt, kernel, ...). We (openSUSE/SLES/SLED user base) should report bugs to Novell/SUSE. And Novell/SUSE would then either: a) fix those bugs if it's related to Novell/SUSE b) report upstream if it's got nothing to do with Novell/SUSE This way, we get an organized way of reporting bugs, bugs don't get reported twice (mainstream and in Novell's bugzilla), ... That's all. Hope I made myself clear ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, 2009-02-03 at 18:39 +0100, Rafa Grimán wrote:
What I was trying to say is that since openSUSE is a Novell "product", we (openSUSE/SLES/SLED user base) should not have to report bugs upstream to the original project (be it KDE, GNOME, smolt, kernel, ...). We (openSUSE/SLES/SLED user base) should report bugs to Novell/SUSE. And Novell/SUSE would then either: a) fix those bugs if it's related to Novell/SUSE b) report upstream if it's got nothing to do with Novell/SUSE
This way, we get an organized way of reporting bugs, bugs don't get reported twice (mainstream and in Novell's bugzilla), ... That's all.
But then you have to define who is "Novell/SUSE"...
by Novell/SUSE... I would assume you mean people who test and develop
openSUSE... people like you and me. If you're reading and posting on
-factory, I would think that you are able to report a bug in the Novell
Bugzilla, and the upstream one if requested.
What I don't see is you're argument... are you saying that we (meaning
openSUSE testers) should only have to post bugs in Novell's Bugzilla? If
you're willing to help openSUSE, and know how to file bugs, why not file
something upstream if you need to?
If you're talking about the openSUSE *users* (meaning Jane and Joe Smith
who picked up a copy after hearing how good our product is), I don't
really expect them to file bugs at all, instead getting support from the
appropriate channels.
--
Kevin "Yeaux" Dupuy - openSUSE Member
Public Mail:
Hi :) El Tuesday 03 February 2009, Kevin Dupuy escribió:
On Tue, 2009-02-03 at 18:39 +0100, Rafa Grimán wrote:
What I was trying to say is that since openSUSE is a Novell "product", we (openSUSE/SLES/SLED user base) should not have to report bugs upstream to the original project (be it KDE, GNOME, smolt, kernel, ...). We (openSUSE/SLES/SLED user base) should report bugs to Novell/SUSE. And Novell/SUSE would then either: a) fix those bugs if it's related to Novell/SUSE b) report upstream if it's got nothing to do with Novell/SUSE
This way, we get an organized way of reporting bugs, bugs don't get reported twice (mainstream and in Novell's bugzilla), ... That's all.
But then you have to define who is "Novell/SUSE"...
by Novell/SUSE... I would assume you mean people who test and develop openSUSE... people like you and me.
I'll be more specific: the team at Novell that develop SUSE Linux, be it openSUSE, SLES and/or SLED.
If you're reading and posting on -factory, I would think that you are able to report a bug in the Novell Bugzilla, and the upstream one if requested.
Yes. But htat has nothing to do with my point: give the user _one_ interface/bugzilla aka: make life easier for the user.
What I don't see is you're argument... are you saying that we (meaning openSUSE testers) should only have to post bugs in Novell's Bugzilla? If you're willing to help openSUSE, and know how to file bugs, why not file something upstream if you need to?
I don't know whether I didn't manage to explain correctly my point of view, whether you didn't understand it, both, or any other reason. I'll try again ... This is what I wrote: "This way, we get an organized way of reporting bugs, bugs don't get reported twice (mainstream and in Novell's bugzilla), ... That's all." What I mean is that say I post a bug upstream and another user posts the same bug at Novell's bugzilla. Oops, the same bug is reported twice in two different places. This will probably (most likely) get two different developers fixing the same bug: one guy from Novell/SUSE and one guy upstream. It doesn't mean it will happen always, it doesn't mean it's bad, it doesn't mean this is negative. What I'm talking about is making life easier for everyone. Getting organized. Users (whether they're developers or not, advanced admins or not) sometimes are not sure whether to post the bug upstream or at the distro's bugzilla. More things to take into account. Sometimes, the distro adds some patches that are not added upstream. So filing a bug upstream is of no use (openSSL bug in Debian, for example). A user (I don't care whether he's "The Best Developer in the World" or not) would have to know whether the bug he's filing is related to a patch that only appears on that specific distro he's using or not. This makes things more difficult for people that want to report bugs. If the openSUSE/SLES/SLED user report bugs only to Novell's bugzilla, it's easier for the "bug posters". And it's easy for developers/maintainers to keep track of bugs. If it's related to openSUSE/SLES/SLED, then there's no need to post upstream. If it's related upstream, then the openSUSE/SLES/SLED developer/maintainer can check and see if upstream someone's working on it. Maybe even he/she is the maintainer of that package upstream. It would also make his/her life easier. Anyways, I'm not trying to change anything. I'm not saying things are done wrong. I'm not saying anything like that. Just giving MHO on how to make things easier for everyone. That's all. I might be wrong, that's OK with me: I'm not perfect ;)
If you're talking about the openSUSE *users* (meaning Jane and Joe Smith who picked up a copy after hearing how good our product is), I don't really expect them to file bugs at all, instead getting support from the appropriate channels.
I'm not talking about "Mr. Big Cool Developer" or "Joe User". I'm talking about making life easier for both of them: file bugs in one place, not two or three different places. Imagine I'm using KDE (well, don't imagine that, because I AM :). Now I see a bug using Gwenview. I would have to think: - should I post the bug at Novell's site - should I post the bug at KDE's site - should I post the bug at Gwenview's site - should I post the bug at ... It's much easier for me to post the bug at Novell's site. You might say: "Yes, but for the developer/maintainer it's more work." I would answer: "Not necessarily. The Gwenview mantainer at Novell/SUSE is probably in the Gwenview mailing lists, forums, bugzilla, ... whatever and knows better than me if the bug has already been filed (in which case he would close the bug) or whether it's a new bug. If it's a new bug and he can fix it, he'd fix it. If it's a new bug and he can't fix it: he files it upstream. Isn't that how he does things already?" What I'm talking about is giving the end user (whether he is "Developer of the year" or "The New Kid in Town") _one_ interface/bugzilla. Obviously, this is MHO, my point of view, my opinion. You don't have to agree with it, it's OK with me. BTW, I'm not trying to change anybody's way of working, thinking, acting, writing, dancing or drinking beer (or any other activity, be it mental or physical ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/2/4 Rafa Grimán
What I mean is that say I post a bug upstream and another user posts the same bug at Novell's bugzilla.
The discussion about smolt started when an openSUSE user was unhappy to be referred reporting a bug upstream. In general it does make sense to open a bug in Bugzilla, and to accept polite requests to file upstream. How can you verify or test a proposed fix, if the bug does not affect your system? Filing a bug, frequently you are asked to provide information, logs, or run tests and provide output or describe the effects. So what is generally needed is work from a number of independent projects : - Cooperation of End User with bug, info & test runs - Triage & extra information by openSUSE member (community or Novell/SuSE employee) - Cooperation of Upstream, who ideally approve a patch, and include fix into codebase for future releases Restricting reporting to 1 interface, is superficially convenient, but is inherently inefficient. Commercial software companies, don't want their users to talk to anyone else, who might provide the customer with information. This is an open system, no secrets, not a closed one. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi :) El Wednesday 04 February 2009, Rob OpenSuSE escribió:
2009/2/4 Rafa Grim�n
: What I mean is that say I post a bug upstream and another user posts the same bug at Novell's bugzilla.
The discussion about smolt started when an openSUSE user was unhappy to be referred reporting a bug upstream.
I know, and (once again) I jumped in because I misunderstood the answer he got so I SYNed an apology and got ACKed saying it's OK.
In general it does make sense to open a bug in Bugzilla, and to accept polite requests to file upstream.
I know. That's why I'm saying that if the user has 1 interface, it's much easier for him. And yes, if he receives an answer saying: "File upstream", that's OK. I never said we shouldn't do that. In the part you quote, what I'm talking about is two openSUSE/SLES/SLED users see the same bug: - one user files it upstream - the other user files it in Novell's bugzilla Then you've got two times the same bug. If we "train" the user to report bugs first in Novell's bugzilla, then it's much easier.
How can you verify or test a proposed fix, if the bug does not affect your system? Filing a bug, frequently you are asked to provide information, logs, or run tests and provide output or describe the effects.
I know you have to do follow ups. I'm just saying that if the user has 1 interface, we're making his life easier. That's what we want, right? At least that's what I want because that will bring more users :)
So what is generally needed is work from a number of independent projects :
- Cooperation of End User with bug, info & test runs - Triage & extra information by openSUSE member (community or Novell/SuSE employee) - Cooperation of Upstream, who ideally approve a patch, and include fix into codebase for future releases
I don't remember saying the contrary. Once again: my point is one interface to make user's life easier, not what gets done once the bug is filed.
Restricting reporting to 1 interface, is superficially convenient, but is inherently inefficient.
Not necessarily. How many KDE users are there? Imagine all those KDE users filing bugs to KDE's bugzilla: it would be madness for the KDE project. On the other hand. Imagine all those KDE users filing bugs to each of their distros: the distro decides which bugs are up stream and which are distro specific. I'm saying the distros should act as a funnel/filter. For example, how does an end user know whether it's a distro specific bug or whether it's a package specific bug? The easiest thing for the end user is to file the bug in Novell's bugzilla and from there start all the process to fix the bug.
Commercial software companies, don't want their users to talk to anyone else, who might provide the customer with information. This is an open system, no secrets, not a closed one.
I haven't been talking about keeping things secret. I'm talking about _organizing_ the bug submission process. Where did you get the idea that I want to keep things secret? Why did you write the above paragraph? I'm sorry, I don't understand why you wrote it and what it has to do with what I'm saying (making life easier for the user). Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/2/4 Rafa Grimán
In general it does make sense to open a bug in Bugzilla, and to accept polite requests to file upstream.
I know. That's why I'm saying that if the user has 1 interface, it's much easier for him. And yes, if he receives an answer saying: "File upstream", that's OK. I never said we shouldn't do that.
That's what we have. But as openSUSE releases seem to be schedule based, rather than decided on basis of quality and bug counts, the information in Bugzilla isn't well maintained ie. Bug is closed when packager/maintainer thinks it's solved in some development version, not via the release that provides the solution to the user.
So what is generally needed is work from a number of independent projects :
- Cooperation of End User with bug, info & test runs - Triage & extra information by openSUSE member (community or Novell/SuSE employee) - Cooperation of Upstream, who ideally approve a patch, and include fix into codebase for future releases
I don't remember saying the contrary. Once again: my point is one interface to make user's life easier, not what gets done once the bug is filed.
I think you & I are in agreement. The context, makes it appear that you are arguing for change. How does the current process, where any use may file to Novell Bugzilla, differ from your proposal? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El Wednesday 04 February 2009, Rob OpenSuSE escribió:
2009/2/4 Rafa Grim�n
: In general it does make sense to open a bug in Bugzilla, and to accept polite requests to file upstream.
I know. That's why I'm saying that if the user has 1 interface, it's much easier for him. And yes, if he receives an answer saying: "File upstream", that's OK. I never said we shouldn't do that.
That's what we have. But as openSUSE releases seem to be schedule based, rather than decided on basis of quality and bug counts, the information in Bugzilla isn't well maintained ie. Bug is closed when packager/maintainer thinks it's solved in some development version, not via the release that provides the solution to the user.
OK, that makes me change my mind then ;)
So what is generally needed is work from a number of independent projects :
- Cooperation of End User with bug, info & test runs - Triage & extra information by openSUSE member (community or Novell/SuSE employee) - Cooperation of Upstream, who ideally approve a patch, and include fix into codebase for future releases
I don't remember saying the contrary. Once again: my point is one interface to make user's life easier, not what gets done once the bug is filed.
I think you & I are in agreement. The context, makes it appear that you are arguing for change.
Yup, seems so 0:)
How does the current process, where any use may file to Novell Bugzilla, differ from your proposal?
I didn't know what you say about how Novell's bugzilla works. I thought the packager/maintainer would (try to) solve certain bugs. This would then prevent the user from having to go up stream. Thanks for the info :) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2009-02-04 at 10:10 +0100, Rafa Grimán wrote: ...
Imagine I'm using KDE (well, don't imagine that, because I AM :). Now I see a bug using Gwenview. I would have to think: - should I post the bug at Novell's site - should I post the bug at KDE's site - should I post the bug at Gwenview's site - should I post the bug at ...
It's much easier for me to post the bug at Novell's site. You might say:
"Yes, but for the developer/maintainer it's more work."
I would answer:
"Not necessarily. The Gwenview mantainer at Novell/SUSE is probably in the Gwenview mailing lists, forums, bugzilla, ... whatever and knows better than me if the bug has already been filed (in which case he would close the bug) or whether it's a new bug. If it's a new bug and he can fix it, he'd fix it. If it's a new bug and he can't fix it: he files it upstream. Isn't that how he does things already?"
+1 Just my thought. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmJgCYACgkQtTMYHG2NR9XvDwCdHtYmU+cxtnETA+ceRUzBRzeE h+cAnj5TfIQyvtWzvYOjiR9pocz+peUP =fdvV -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Hi,
Carlos E. R. wrote:
On Friday, 2009-01-16 at 13:40 +0100, Henne Vogelsang wrote:
Carlos E. R. wrote:
...
If you dont want to help then let it be. Then i have to do it...
It is not that I do not want, is that I can't, I don't know how, and that I'm not the end user, IMO: it is the distributor who is the end user; ie, you (novell). If you want me to, then you will have to hand-hold me through the process, which will be more wasteful for you, I think. If this is generalized for all bugzilla reporting, I'd have to register to dozens of upstream mailists upstream, and register to dozens of bugzilla systems upstream, for which I don't have the knowledge nor time. I think that it should be the package mantainer in the distro who collects, triages and reports upstream those bugs worth reporting, as he/she is the person that has the most up to date knopwledge of each particular package. If this is the intention for us, then I'l have to stop reporting bugzillas completely.
And I still think that /etc/cron.daily/ is a SuSE feature, as the /usr/lib/cron/run-crons is "Copyright (c) 1998-2001 SuSE GmbH Nuernberg".
Dude. I already told you that this cronjob comes from the smolt project. This has nothing to do with the cron package or its contents. And its not even the cronjobs fault as you noted in you initial report. Its the whole setup that is flawed.
I don't know what "dude" means in this context :-? Yes, the cron job comes from them, but SUSE can change it for the distribution and place a file in /etc/cron.daily/ or /etc/cron.monthly/ instead. AFAIK, Fedora may not have this feature, they might be using anacron for all I know. How will I argue this point to them?
There is also a /etc/init.d/smolt service, purpose unknown, and dissabled by default.
This triggers if data gets sent by smoltSendProfile or not.
Undocumented.
smoltSendProfile -h | grep -A 1 -- -c -c, --checkin this is an automated checkin, will only run if the "smolt" service has been started
Thats the manpage for "smoltSendProfile", not the documentation for "/etc/init.d/smolt". It does this: ] start) ] echo -n $"Enabling monthly Smolt checkin: " ] touch "$lockfile" ] rc_status -v ] ;; ] stop) and I have no idea what that means and does. Again, how could argue this point upstream if I don't know enough about it?
Do you mean that if I manually send data somehow it runs insserv on smolt?
No. There is a cronjob that runs "smoltSendProfile -c". It only sends data if there is a specific file (/var/lock/subsys/smolt). The smolt "service" does nothing else than to touch or remove that file.
Which means that I do not and can not know how smolt really works or is supposed to work, and thus, I can not argue these points upstream. I don't have the knowledge.
(1) The link for reporting upstream is https://fedorahosted.org/smolt/report.
It says: «Note: See TracReports for help on using and creating reports.»
That help text in unintelible for me [...] Im sorry, but that sent me running for my life, and I'm not going back there. :-/
You need a login there. Like you need a login in our bugzilla. Nothig that special...
It is special for me. I may be dumb some times. So? O:-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmJgXIACgkQtTMYHG2NR9UwMQCcCicl669fiMHZ0ySVos0njWzF MigAnRA7ySM/ClpsX1Uxx3kOPVGZC0+n =Grrv -----END PGP SIGNATURE-----
Hi, on 02/04/2009 10:10 AM Rafa Grimán wrote:
It's much easier for me to post the bug at Novell's site. You might say:
"Yes, but for the developer/maintainer it's more work."
I would answer:
"Not necessarily. The Gwenview mantainer at Novell/SUSE is probably in the Gwenview mailing lists, forums, bugzilla, ... whatever and knows better than me if the bug has already been filed
You are mixing up effort and work (the task itself). 1. It's (maybe) less EFFORT for the developer than for the user. 2. It's not less WORK for the developer. Its more work than he had before. Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, on 02/04/2009 12:52 PM Carlos E. R. wrote:
Content-ID:
On Friday, 2009-01-16 at 16:33 +0100, Henne Vogelsang wrote:
If you dont want to help then let it be. Then i have to do it...
It is not that I do not want, is that I can't
Fair enough. Just say so :) Henne -- Henne Vogelsang, openSUSE. Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi :) El Wednesday 04 February 2009, Henne Vogelsang escribió:
Hi,
on 02/04/2009 10:10 AM Rafa Grimán wrote:
It's much easier for me to post the bug at Novell's site. You might say:
"Yes, but for the developer/maintainer it's more work."
I would answer:
"Not necessarily. The Gwenview mantainer at Novell/SUSE is probably in the Gwenview mailing lists, forums, bugzilla, ... whatever and knows better than me if the bug has already been filed
You are mixing up effort and work (the task itself).
1. It's (maybe) less EFFORT for the developer than for the user. 2. It's not less WORK for the developer. Its more work than he had before.
Could be. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mercredi 04 février 2009, à 10:10 +0100, Rafa Grimán a écrit :
Hi :)
El Tuesday 03 February 2009, Kevin Dupuy escribió:
by Novell/SUSE... I would assume you mean people who test and develop openSUSE... people like you and me.
I'll be more specific: the team at Novell that develop SUSE Linux, be it openSUSE, SLES and/or SLED.
Let me repeat: "Nonononononono!" :-) openSUSE is a community project. Sure, it's sponsored by Novell and sure Novell employees are doing a huge part of the work. But it's still a project where everybody can step up. You don't have to be a Novell employee to do the right thing. It doesn't mean you absolutely have to do the right thing, but that you're empowered to do so and you can be part of the interface between the end users and the upstream developers. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El Wednesday 04 February 2009, Vincent Untz escribió:
Le mercredi 04 f�vrier 2009, � 10:10 +0100, Rafa Grim�n a �crit :
Hi :)
El Tuesday 03 February 2009, Kevin Dupuy escribi�:
by Novell/SUSE... I would assume you mean people who test and develop openSUSE... people like you and me.
I'll be more specific: the team at Novell that develop SUSE Linux, be it openSUSE, SLES and/or SLED.
Let me repeat: "Nonononononono!" :-)
openSUSE is a community project. Sure, it's sponsored by Novell and sure Novell employees are doing a huge part of the work. But it's still a project where everybody can step up.
I don't mention openSUSE exclusively, I also mention SLES and SLED ... Don't focus ONLY on openSUSE, I'm not doing that. This thread started with an openSUSE package but, as you may have seen on my previous e-mails: - I'm not focusing/talking about openSUSE solely - I'm not focusing/talking about smolt solely
You don't have to be a Novell employee to do the right thing. It doesn't mean you absolutely have to do the right thing, but that you're empowered to do so and you can be part of the interface between the end users and the upstream developers.
I know. I'm not saying this is: "Novell only, back off". I'm thinking about _ALL_ the openSUSE *AND* SLES *AND* SLED users. I know I can be part of the openSUSE Community. I know the basics of FLOSS, but I'm not talking about that. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le mercredi 04 février 2009, à 14:47 +0100, Rafa Grimán a écrit :
El Wednesday 04 February 2009, Vincent Untz escribió:
Le mercredi 04 f?vrier 2009, ? 10:10 +0100, Rafa Grim?n a ?crit :
Hi :)
El Tuesday 03 February 2009, Kevin Dupuy escribi?:
by Novell/SUSE... I would assume you mean people who test and develop openSUSE... people like you and me.
I'll be more specific: the team at Novell that develop SUSE Linux, be it openSUSE, SLES and/or SLED.
Let me repeat: "Nonononononono!" :-)
openSUSE is a community project. Sure, it's sponsored by Novell and sure Novell employees are doing a huge part of the work. But it's still a project where everybody can step up.
I don't mention openSUSE exclusively, I also mention SLES and SLED ... Don't focus ONLY on openSUSE, I'm not doing that. This thread started with an openSUSE package but, as you may have seen on my previous e-mails: - I'm not focusing/talking about openSUSE solely - I'm not focusing/talking about smolt solely
Well, this is a mailing about openSUSE, so I'm replying to the openSUSE part :-) (not talking about smolt either, btw) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi :) El Wednesday 04 February 2009, Vincent Untz escribió:
Le mercredi 04 f�vrier 2009, � 14:47 +0100, Rafa Grim�n a �crit :
El Wednesday 04 February 2009, Vincent Untz escribi�:
Le mercredi 04 f?vrier 2009, ? 10:10 +0100, Rafa Grim?n a ?crit :
Hi :)
El Tuesday 03 February 2009, Kevin Dupuy escribi?:
by Novell/SUSE... I would assume you mean people who test and develop openSUSE... people like you and me.
I'll be more specific: the team at Novell that develop SUSE Linux, be it openSUSE, SLES and/or SLED.
Let me repeat: "Nonononononono!" :-)
openSUSE is a community project. Sure, it's sponsored by Novell and sure Novell employees are doing a huge part of the work. But it's still a project where everybody can step up.
I don't mention openSUSE exclusively, I also mention SLES and SLED ... Don't focus ONLY on openSUSE, I'm not doing that. This thread started with an openSUSE package but, as you may have seen on my previous e-mails: - I'm not focusing/talking about openSUSE solely - I'm not focusing/talking about smolt solely
Well, this is a mailing about openSUSE, so I'm replying to the openSUSE part :-)
Good point :) But ... SLES and SLED users also read this list and SLES and SLED are based on (derive from) openSUSE ;)
(not talking about smolt either, btw)
Vincent
Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Wed, 2009-02-04 at 14:47 +0100, Rafa Grimán wrote:
I don't mention openSUSE exclusively, I also mention SLES and SLED ... Don't focus ONLY on openSUSE, I'm not doing that. This thread started with an openSUSE package but, as you may have seen on my previous e-mails: - I'm not focusing/talking about openSUSE solely - I'm not focusing/talking about smolt solely
Contributing to openSUSE is contributing to SLE. Because SLE is a *late* branch off openSUSE, not a fork or a new distro. Hub -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El Wednesday 04 February 2009, Hubert Figuiere escribió:
On Wed, 2009-02-04 at 14:47 +0100, Rafa Grimán wrote:
I don't mention openSUSE exclusively, I also mention SLES and SLED ... Don't focus ONLY on openSUSE, I'm not doing that. This thread started with an openSUSE package but, as you may have seen on my previous e-mails: - I'm not focusing/talking about openSUSE solely - I'm not focusing/talking about smolt solely
Contributing to openSUSE is contributing to SLE. Because SLE is a *late* branch off openSUSE, not a fork or a new distro.
I know, that's why I wrote (I copy and paste): "But ... SLES and SLED users also read this list and SLES and SLED are based on (derive from) openSUSE ;)" I'm not saying they're forks nor different distros. What I mean is that you can't focus ONLY on one of them (openSUSE/SLES/SLED) and that you can't focus on only one type of users. And no, being an openSUSE user does not imply you're a SLE[S|D] user and vice-versa. I have a whole bunch of customers that are SLES users but not openSUSE users (as a matter of fact they use Fedora or Ubuntu). And I've got a bunch of buddies that are openSUSE users and have never used SLE[S|D]. Nope, they're not exactly the same. You can get dependency issues if you try to install some openSUSE apps on SLE[S|D] (I've suffered this.) And yes, I had in mind openSUSE versions and SLE[S|D] versions when I tried this. That means that I didn't try to do things such as installing openSUSE 11.1 packages on SLES 9 ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2009/2/4 Henne Vogelsang
You are mixing up effort and work (the task itself).
1. It's (maybe) less EFFORT for the developer than for the user. 2. It's not less WORK for the developer. Its more work than he had before.
And remember decentralising work, by pushing it out as far as possible to the leaves, tends to scale better. For example, some bug I notice, may be trivial for Linus or Aaron Seigo to solve, but if those guys are busy doing something else, then scheduling them to fix it, would not be the greatest decision. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (37)
-
ab
-
Andreas Jaeger
-
Andrew Wafaa
-
Birger Kollstrand
-
Boyd Lynn Gerber
-
Bryen
-
Carlos E. R.
-
Carlos E. R.
-
Cristian Rodríguez
-
Daniele
-
Dominique Leuenberger
-
Gerald Pfeifer
-
Greg KH
-
Hans Petter Jansson
-
Hans Witvliet
-
Henne Vogelsang
-
Herbert Graeber
-
Hubert Figuiere
-
JP Rosevear
-
Kevin Dupuy
-
Larry Stotler
-
M. Edward (Ed) Borasky
-
Marcus Meissner
-
Martin Schlander
-
Matt Sealey
-
Michael Loeffler
-
Michal Vyskocil
-
ne...
-
peter nikolic
-
Putrycz, Erik
-
Rafa Grimán
-
Rajko M.
-
Rob OpenSuSE
-
Stanislav Visnovsky
-
Stephan Binner
-
Vincent Untz
-
wormey@eskimo.com