Hi, the package 'gutenprint52' in the "Printing" project is no longer maintained by the current community volunteer. Therefore I'm searching for a new maintainer: to bring up this package to latest version, make it buildable on our various distributions, and work on upcoming bugs and adaptions in print system in future. If someone is interrested and thinks he has enough skills to do so, send me a quick e-mail including your buildservice nickname, and I'll change it appropriately. I'm searching for someone with long term maintainance interrests, not for quick fix of a one-time job. Thanks in advance. Regards, Kluas. -- Klaus Singvogel - Maxfeldstr. 5 - 90409 Nuernberg - Germany Phone: +49-911-74053-0 GnuPG-Key-ID: 1024R/5068792D 1994-06-27 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- 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 5:55 AM, Rob OpenSuSE wrote:

...

2009/1/15 :

It's not about "turning them off by default so nobody can use them", it's about turning off services which can be CONFIRMED as unused on the current system.

When you & Larry complained, without making specific examples, via generalised comments, I actually looked into the differences between 10.3 & 11.1. I see reasonable choices, the fact is, I cannot file Bugs that something is loaded and activated on my system when I use it. It would be hugely unfair on developers reputation to allow such unsubstantiated claims go unchallenged. They are in many cases actively working to reduce memory consumption, whilst actually increasing functionality. Actually I was interested to investigating why you had problems, but it may be Power specific, as the systems I tested on, were not showing the problems you saw. In private (I think) you then mentioned an 80KiB wastage thanks to device mapper, and a claimed 0.5s increase on boot time. Ask yourself if that is going to cause performance problems on a typical desktop system, where even small machines, have 512 MiB RAM. Furthermore, and you really deserve a huge flame for this, when the tuneable that frees up memory was suggested to you, which will free up several MB of pages, you dismiss that, despite going after KiB reductions in areas you understand. There seems to be a fixed mindset based on what is a significant performance issue is on an embedded system, despite the fact that openSUSE is a general desktop and server OS. Unless you can come up with specific examples of performance issues, it appears that you're just hand waving and ranting about bloat etc. It is clear that there has been work done in the past to speed up boot times, and folk agree that that is a benefit. However being abusive to ppl who look into what you are saying, and report what they find, suggest that you actually seek sycophants, rather than real information or trouble shooting.

Initrd building - a discussion you're also chipping into on this and another list - is one example of where you build something which only supports the desired drivers on the system. If your system uses pata_via and uhci, then these are put into the initrd so they can be loaded on early boot. This is determined by the state of the running system, and what udev did the last time it booted.

I agree and have pointed out, before in a bug report that this is may prove to be a problem. It is an issue that I have wanted to discuss, rather than file a specific bug report, but so far I have not seen evidence of it causing many problems, which makes it harder to build a solid case. Specific examples are much better than shrill handwaving.

Now, if you do not have LVM2 setup, dm-mod is still loaded and dm-mod is still started on boot. There is no need for this. The service can be deactivated without negative effect until someone needs to set up an LVM2 system.

I am using LVM, so I cannot investigate why device mapper would be erroneously loaded.

rpcbind/portmap is started, even though xinetd is not started and no NFS clients are installed. No other services depend on rpcbind/portmap on my Automatic Configuration-installed system. So why is it still enabled?

When I install nfs-kernel-server and enable xinetd for some service, rpcbind should be pulled in by those as and when it is needed, for the best efficiency of resource usage.

These are good questions, but these services are not the cause of the performance problems, that you complained of. For reasons that have been explained previously. Privately I advised using the possible security undesirability of having these services active (installed) when unecessary, rather than hammer the performance angle.

...

...

And while a few years ago one of the benefits of Linux was that it ran on any old hardware, where Windows was not an option, this is not the case any more.

openSUSE is not Linux, it has always had suggested hardware that was much greater than typical embedded systems, because it is a general purpose server and desktop OS.

It's a testament to how great openSUSE is that it DOES boot and DOES support our 128MB 400MHz board, but the trend seems to be that a generic server or desktop will have many gigabytes of RAM and many thousands of MHz of CPU and extremely fast peripherals. This is not born out by the requirements to install the system - 256MB of RAM (on the Efika we have to build a swap file on a USB key or activate an already existing swap partition).

We realise we are on the shitty end of the stick here, but we've noticed that the trend from 10.x to 11.x is that installation is fine, but the installed system has been gaining more and more hard dependencies on things that the vast majority of people may not even have activated (LVM2 etc.)

Are you filing bug reports, on these specifics? What I have been saying to you is, that on a range of "typical" systems, even quite old Intel ones, they are not causing end user problems. The example of the 128 MiB board, cannot be typical, where a desktop, or FF3 itself is likely to use that amount of RAM alone, despite work by developers made to reduce memory requirements, comparing 10.3->11.1 as I have, when you complain. Don't confuse non-agreement, with not listening. I've actually been the person who investigated claims because I took some interest, as I do test new software pre-release on "small" 256MiB systems and ones with slow CPUs. -- 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:29 AM, Matt Sealey wrote:

I thought the minimum requirement for installing SUSE was 256MB and pretty much has been for a long, long while. The requirement for running Office apps on a full KDE desktop is 512MB, but there are ways around that (xfce, gnumeric, abiword) which work just as well.

The only "Official" requirement I know of is 256MB for installation. However, I regularly run file servers with 128MB on text, so it is a little annoying having to meet that(which can be gotten around if you already have a swap partition, you just have to activate it)

A typical Netbook system may have 512MB of RAM, but it also has limited provision for swap (or "demand paging area" if you want to call it that) too, if it only has 4GB of total storage. The default install would take ~1.5GB of that as swap. ~1.5GB to install. What's left? One gigabyte for the user. This is not friendly, and also on the current crop of cost effective ML-NAND SSDs, a terrible idea too.

I don't have any netbooks, but I do have systems that can't go to 512MB due to design limits(Thinkpad X21 maxes at 384MB) or hardware issues(Thinkpad A22p has bad RAM slot and only uses 256MB chips). The install requirement came about in 10.1 or 10.2(I think). Before that, I know I installed 10.0 Beta on a PowerMac with 80MB and it ran fairly well. Now, you need at least 256MB to run a desktop. Back in the days of 5.3, I had a P/100 and 32MB RAM. I could install that now and still be pretty productive on many things. You don't need a lot to type or email with a basic web client, especially if you aren't using that bloated openoffice or any of the "pretty" gui emails programs. I know several people who still use 68k Macs on a daily basis. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

T24gVGh1LCBKYW4gMTUsIDIwMDkgYXQgMTI6MzAgUE0sIEJpcmdlciBLb2xsc3RyYW5kCjxiaXJnZXIua29sbHN0cmFuZEBnb29nbGVtYWlsLmNvbT4gd3JvdGU6Cj4gMjAwOS8xLzE1IExhcnJ5IFN0b3RsZXIgPGxhcnJ5c3RvdGxlckBnbWFpbC5jb20+Ogo+PiBJIGtub3cgc2V2ZXJhbCBwZW9wbGUgd2hvIHN0aWxsIHVzZSA2OGsgTWFjcyBvbiBhIGRhaWx5Cj4+IGJhc2lzLgo+Cj4gSSBldmVuIGZpcmUgdXAgbXkgb2xkIEEzMDAwIGV2ZXJ5IG5vdyBhbmQgdGhlbiBqdXN0IGZvciBmdW4sIGJ1dCBub3QKPiBvbiBPcGVuU3VzZSAxMS4xIDotKQoKSXQncyBhIHNoYW1lIG5vYm9keSB3YW50ZWQgdG8gcG9ydCBBUFVTIHRvIGFyY2gvcG93ZXJwYyBvciB5b3UnZCBiZQphYmxlIHRvIHJ1biBPcGVuU1VTRSAxMS4xIG9uIGl0IGlmIEkgaGFkIG15IHdheSA6RAoKSSBkb24ndCBBQ1RVQUxMWSBoYXZlIGFuIEEzMDAwIGFueW1vcmUgKGFuZCBteSBBMTIwMCBkaWVkIGEgaGVsbCBvZiBhCmxvbmcgdGltZSBhZ28sIEkgc29sZCB0aGUgQmxpenphcmRQUEMpIC0gdGhlIEVmaWthIGlzIHRoZSB0cnVlCnN1Y2Nlc3NvciBvZiBBbWlnYSBBUFVTIGFueXdheSA6XQoKPiBGcm9tIG15IHBvaW50IG9mIHZpZXcgaXTCtHMgb2sgdG8gaW5jcmVhc2UgdGhlIHJlcXVpcmVtZW50cyBmb3IgbmV3ZXIKPiBTVy4gSWYgdGhhdMK0cyBub3QgYW4gb3B0aW9uIGZvciBhIHNwZWNpZmljIGNvbmZpZ3VyYXRpb24gdGhlbiBpdAo+IHNob3VsZCByZXZlcnQgdG8gdXNpbmcgb2xkZXIgZGlzdHJvcy9rZXJuZWxzLgoKTmV3ZXIgc29mdHdhcmUgaXMgb25lIHRoaW5nIC0gYWZ0ZXIgYWxsIEtERSBhbmQgR05PTUUgYW5kIENvbXBpeiBhbmQKYWR2YW5jZWQgWDExIGFjY2VsZXJhdGlvbiBzdHVmZiwgbWlnaHQgbmVlZCBhIGxvdCBvZiByZXNvdXJjZXMuIEJ1dAp0aGlzIGlzIGFsbCBzdHVmZiB0aGF0IGNhbiBiZSB0dXJuZWQgb2ZmLiBXaGF0IHRlbmRzIHRvIGhhcHBlbiBpcyBpdCdzCmVuYWJsZWQgYmVjYXVzZSBtb3N0IHBlb3BsZSBoYXZlIEludGVsLCBuVmlkaWEgb3IgQVRJIGdyYXBoaWNzIGNhcmRzLAp1c2UgYmluYXJ5IGRyaXZlcnMgb3IgdGhlIHZlcnkgbGF0ZXN0IHRoaW5nLCBhbmQgdGhlIHJlc291cmNlCnJlcXVpcmVtZW50cyBzcHVyIGRldmVsb3BtZW50IG9uIGFwcGxpY2F0aW9ucyB3aGljaCB3aWxsIG9ubHkgcnVuCndpdGhpbiB0aGUgY29tbW9uIGNvbmZpZ3VyYXRpb24gb2YgdGhlc2Ugc3lzdGVtcy4KClRoaXMgaXMgbm90IHRvIG1lbnRpb24gdGhlIGZhY3QgdGhhdCBzdHVmZiBsaWtlIFZpYSBVbmljaHJvbWUgKHdoaWNoClZpYSBhcmUgc3RpbGwgbWFraW5nIGFuZCBwdXNoaW5nIGZvciB0aGVpciBOYW5vIHBsYXRmb3JtISkgc2ltcGx5CmRvZXNuJ3Qgd29yayByaWdodCwgc2FkZGVyIGV2ZW4gdGhhdCB0aGUgb3JpZ2luYWwgZGV2ZWxvcGVyIG9mIHRoZQpkcml2ZXIgd29ya3MgYXQgTm92ZWxsIDooCgpJbiB0aGUgZW5kIHRoZXNlIGFyZSBwZXJmb3JtYW5jZS1saW1pdGVkIGFuZCByZXNvdXJjZS1jb25zdHJhaW5lZApzeXN0ZW1zLCB2ZXJ5IHNpbWlsYXIgdG8gTmV0Ym9va3Mgd2hpY2ggV0lMTCBiZSB0aGUgYmlnIHB1cmNoYXNlIHRoaXMKeWVhciwgYW5kIGFsbCBvZiB3aGljaCBhcmUgZ2VuZXJhbGx5IHRob3VnaHQgb2YgYXMgIndvbid0IGhhdmUgYSBkcmVhbQpvZiBydW5uaW5nIFZpc3RhLCBzbyB0cnkgYSBzdHJpcHBlZCBkb3duIFhQIiBhbmQgTGludXggaXMgdXNlZCBhcyB0aGUKYWx0ZXJuYXRpdmUgb3B0aW9uLgoKSW4gYWN0dWFsIGZhY3QsIExpbnV4IGlzIGFic29sdXRlbHkgbm8gYmV0dGVyLCBzaW5jZSBpdCBpcyBmb2xsb3dpbmcKVmlzdGEsIGFuZCBubyBMaW51eCBkaXN0cmlidXRpb24gYWN0dWFsbHkgc2NhbGVzIGJhY2sgYXMgZmFyIGFzIHRoZXNlCmJvYXJkcyBhcmUgbWFya2V0ZWQgKG5vbmUgb2YgdGhlIEJpZyBUaHJlZSBhbnl3YXkuIERTTCB3b3VsZCwgRGViaWFuCihub3QgVWJ1bnR1KSB3b3JrcyBwcmV0dHkgd2VsbC4gQnV0IHRoZXkgQVJFIGNvbXBldGl0aXZlIGFuZCB0aGV5IEFSRQpoZXJlLCBhbmQgdGhlIHN1cHBvcnQgaXMgcmVhbGx5IG5vdCB0aGVyZSB3aXRoIGl0LgoKPiBJdCBjYW7CtHQgYmUgZXhwZWN0ZWQgdGhhdCBvbmUgc3lzdGVtIHNoYWxsIHJ1bGUgdGhlbSBhbGwuCgpJZiB5b3UgY2FuIGJ1aWxkIGEgZGlzdHJpYnV0aW9uIHRoYXQgcnVucyB3ZWxsIG9uIGEgTmV0Ym9vaywgaXQgd2lsbApnbGFkbHkgcnVuIGp1c3QgYXMgd2VsbCwgaWYgbm90IGJldHRlciwgb24gbGFyZ2VyIHN5c3RlbXMuIEl0J3MKZGlzdHJpYnV0aW9ucyBsaWtlIFVidW50dSBldGMuIHdoaWNoIGRvIG5vdCBxdWl0ZSAiZ2V0IiB0aGlzIC0gcmF0aGVyCnRoYW4gaW1wcm92ZSB0aGUgbWFpbiBkaXN0cmlidXRpb24gdGhleSBhcmUgbG9va2luZyBhdCB3YXlzIHRvIHJvbGwKb3V0IGEgc3BlY2lhbCBjdXN0b20gcGFjayBvZiBmZWF0dXJlcyB3aGljaCB3b3VsZCBhY3R1YWxseSBiZW5lZml0IGZhcgptb3JlIHBlb3BsZS4KCklmIHlvdSd2ZSBldmVyIHBsYXllZCB3aXRoIHRoZSBOZXRib29rIFJlbWl4IHN0dWZmLCBNYXhpbXVzIGlzIG9uZSBvZgp0aGUgbmVhdGVzdCB0aGluZ3MgSSd2ZSB1c2VkIG9uIGEgZGVza3RvcCBQQyBpbiBhIGxvbmcgdGltZS4KTWF4aW1pemluZyB3aW5kb3dzIGFuZCBrZWVwaW5nIHRoZW0gbWl4ZWQgaW4gYSB0YWIgaXMgZ3JlYXQuIEFsbCBpdApuZWVkcyBpcyBhIGxpdHRsZSBmbGlwLWluIHNpZGViYXIgKEkgZ3Vlc3MgbGlrZSBWaXN0YSBvciBHb29nbGUKR2FkZ2V0cykgc28gdGhhdCB3aW5kb3dzIHRoYXQgYXJlIE5PVCBzdWl0YWJsZSBmb3IgbWF4aW1pemluZyAoUGlkZ2luCmJ1ZGR5IGxpc3QgaXMgYSBnb29kIG9uZSwgYWx0aG91Z2ggYSByZXdvcmtlZCBidWRkeSBsaXN0IHdvdWxkIGJlCmJldHRlcikgY2FuIHNpdCBpbiB0aGVyZSBhbmQgc3RheSBuaWNlIGFuZCBzbGltLiBCdXQgdGhpcyBpcyBhIGdvb2QKZXhhbXBsZSB0b28gb2Ygd2h5IHRoZXkgZG9uJ3QgZ2V0IGl0IC0gbm90IGFsbCBhcHBzIGFyZSBtZWFudCB0byBiZQoxMjgweDgwMCBwaXhlbHMgYmlnLiBOb2JvZHkgaXMgYWN0dWFsbHkgZ2l2aW5nIHRoZSBhcHBzIHRoZW1zZWx2ZXMgYW55CmF0dGVudGlvbiwgdGhleSdyZSBqdXN0IHdyYXBwaW5nIE1PUkUgaW4tZGV2ZWxvcG1lbnQgc3R1ZmYgYXJvdW5kCmV4aXN0aW5nIHByb2JsZW1zLgoKVGhlIGxpdHRsZSBkcmFnIGFuZCBkcm9wIGRlc2t0b3AgaWNvbiBkZWZpbml0ZWx5IG5lZWRzIHRvIGJlIHJvbGxlZAppbnRvIEdOT01FIHByb3BlciBzbyB3ZSBjYW4gZHJhZyB0aGluZ3Mgb3V0IG9mIG91ciBhcHBzIG9udG8gdGhlCiJkZXNrdG9wIiBldmVuIGlmIGl0J3MgaGlkZGVuLiBPbiBLREUsIHRoaXMgaXMgc29ydCBvZiBzb2x2ZWQgYnkgdGhlcmUKYmVpbmcgbm8gcHJvcGVyIGRlc2t0b3AgYW5kIGhhdmluZyBhIFBsYXNtb2lkIGZvciBpdCBhbGwuIEFuZCB0aGUKbGF1bmNoZXIgLSB3ZWxsLCBpdCdzIGZhciBwcmV0dGllciBhbmQgZmFyIG1vcmUgdXNlZnVsIHRoYW4gdGhlCnN0YW5kYXJkIEdOT01FIGxhdW5jaGVyLCB3aGljaCBJIG11c3Qgc2F5IGlzIHN0aWxsIHRvcCBvZiBteSBsaXN0IG9mCmdyZWF0IHRoaW5ncyBpbiBHTk9NRSAodG9wIG9mIGEgbGlzdCBvZiAzLCB0aG91Z2gsIGxldCdzIG5vdCBnbwpvdmVyYm9hcmQgOikKCj4gVGhhdCBzYWlkLCBwbGVhc2Uga2VlcCB1cCB0aGUgZ29vZCB3b3JrIHRvIGF2b2lkIGJsb2F0IQoKLS0gCk1hdHQgU2VhbGV5IDxtYXR0QGdlbmVzaS11c2EuY29tPgpHZW5lc2ksIE1hbmFnZXIsIERldmVsb3BlciBSZWxhdGlvbnMK-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.orgFor additional commands, e-mail: opensuse-factory+help@opensuse.org