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

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

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

...

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 Genesi, Manager, Developer Relations -- 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 wrote:

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

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

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 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

On Fri, Jan 9, 2009 at 5:30 AM, Rob OpenSuSE wrote:

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 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? 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 Sat, Jan 10, 2009 at 12:12 AM, Matt Sealey wrote:

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

On Sat, Jan 10, 2009 at 7:32 AM, Rob OpenSuSE wrote:

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 Genesi, Manager, Developer Relations -- 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 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.

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 Genesi, Manager, Developer Relations -- 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 8:37 PM, Rob OpenSuSE wrote:

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 Genesi, Manager, Developer Relations -- 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 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.

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 Genesi, Manager, Developer Relations -- 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 12:39 PM, Rob OpenSuSE wrote:

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 Genesi, Manager, Developer Relations -- 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 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/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

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

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

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

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

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

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: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. 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 Genesi, Manager, Developer Relations -- 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 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. 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 Genesi, Manager, Developer Relations -- 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 wrote:

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 Genesi, Manager, Developer Relations -- 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

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

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

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

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

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

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

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 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

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

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/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

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:

http://smolts.org/static/stats/stats.html

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

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:

http://smolts.org/static/stats/stats.html

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 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

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, 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 801 849-0213 ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -- 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: Merry Christmas & Happy Holidays from the Yeaux! -- 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 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 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:

http://smolts.org/static/stats/stats.html

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 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

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

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 Wed, Jan 21, 2009 at 14:17, Rafa Grimán wrote:

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. 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 wrote: than to send users to the different upstreams to report bugs. I do not know the particiculars of this case, so I'm talking in general terms here. I rest my case. ne... -- Registered Linux User # 125653 (http://counter.li.org) Now accepting personal mail for GMail invites. Emo Philips - "I was sleeping the other night, alone, thanks to the exterminator." -- 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

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

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

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

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

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

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

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

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

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

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

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

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:

http://smolts.org/static/stats/stats.html

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

On Fri, Jan 9, 2009 at 2:14 AM, Stephan Binner wrote:

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 Genesi, Manager, Developer Relations -- 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 Novell, Inc. -- 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

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

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 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 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