[opensuse-factory] Topics dist meeting 2007-05-10
We'd like to discuss the following topics tomorrow. Please send your comments and suggestions as usual so that I can represent them. thanks, Andrea * Smaller systems - what can be done? Goal: A system with 128 MB of space. Challenges are especially: * Languages and localization * documentation - > some packages have documentation split up already * theming -> some packages will be split up so that only one theme is in a package. For languages we discussed previously already the following and will implement this now: The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed. * Shared library policy (posted some time ago on opensuse-packaging, is now in the wiki) * dbus restart Making dbus a special reboot case like the kernel when updating (like other distros - dbus is really not supposed to be restarted). -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ 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 Thu 10 May 2007 05:23:24 NZST +1200, Andreas Jaeger wrote:
We'd like to discuss the following topics tomorrow. Please send your comments and suggestions as usual so that I can represent them.
* Smaller systems - what can be done?
Goal: A system with 128 MB of space.
Challenges are especially: * Languages and localization * documentation - > some packages have documentation split up already * theming -> some packages will be split up so that only one theme is in a package.
Are you talking about 128MB of *disk* space or *RAM* space? Please make and keep this distinction clear! What is the intended/envisaged use of such an installation / system? Do you think a small system which has only 128MB of software storage space (hard disk, flash card, ...) has >=256MB of RAM to run SUSE version-any on? Obviously (to me) we're not talking about a desktop system here, there are none with only 128MB of program storage. So what's the point of a distro which needs twice as much RAM as it does disk space to even install? Obviously: no install -> distro is phhhhhhhhht. Are you thinking people might install on a big computer, then transplant 128MB of storage space into something small? Do gnome, KDE, or languages in this situation have any relevance whatsoever? Why put effort into saving (say) 200MB of disk space when the smallest disk on the market is 40-80GB? I have a commercial application for a small control system running Linux. Must have: kernel, networking, services (web, ftp, ssh, ...), basic package management. Of total non-interest: GUIs, desktop software (no keyboard or mouse attached), languages (users see none of this anyway). Similarly for small servers, firewalls, whatever people can hack up. I'm pretty sure there are quite a few of these applications around, and they will stay firmly Debian. How much stuff SUSE does or does not install on disk is a non-issue when the installer hangs by its neck with a black screen half way through its own startup. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2007-05-10 at 09:16 +1200, Volker Kuhlmann wrote:
On Thu 10 May 2007 05:23:24 NZST +1200, Andreas Jaeger wrote:
We'd like to discuss the following topics tomorrow. Please send your comments and suggestions as usual so that I can represent them.
* Smaller systems - what can be done?
Goal: A system with 128 MB of space.
Challenges are especially: * Languages and localization * documentation - > some packages have documentation split up already * theming -> some packages will be split up so that only one theme is in a package.
Are you talking about 128MB of *disk* space or *RAM* space? Please make and keep this distinction clear!
Disk space.
What is the intended/envisaged use of such an installation / system?
Do you think a small system which has only 128MB of software storage space (hard disk, flash card, ...) has >=256MB of RAM to run SUSE version-any on?
Sure, thin clients do. This requirement is not being pulled out of thin air. Also linux on a usb stick type installations.
Are you thinking people might install on a big computer, then transplant 128MB of storage space into something small? Do gnome, KDE, or languages in this situation have any relevance whatsoever?
No, not thinking this.
Why put effort into saving (say) 200MB of disk space when the smallest disk on the market is 40-80GB?
See above.
-JP
--
JP Rosevear
On Wednesday 09 May 2007 18:14, JP Rosevear wrote:
Do you think a small system which has only 128MB of software storage space (hard disk, flash card, ...) has >=256MB of RAM to run SUSE version-any on?
Sure, thin clients do. This requirement is not being pulled out of thin air.
You mean schools. It would be interesting to have something able to run in 128 MB RAM, not to mention whole base system. I have feeling that many schools would be able to make the best possible recycle effort ie. to bring back in education process computers that are 5-6 years old.
Also linux on a usb stick type installations.
Today 1 GB USB stick is not all that expensive. Taking DSL with its 50 MB for base system it should be possible. That would enable everyone to have his preferred OS and data in the keychain hanger. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu 10 May 2007 11:14:12 NZST +1200, JP Rosevear wrote:
Are you talking about 128MB of *disk* space or *RAM* space? Please make and keep this distinction clear!
Disk space.
Thanks!
What is the intended/envisaged use of such an installation / system?
Do you think a small system which has only 128MB of software storage space (hard disk, flash card, ...) has >=256MB of RAM to run SUSE version-any on?
Sure, thin clients do. This requirement is not being pulled out of thin air. Also linux on a usb stick type installations.
Ok. Sounds very useful. I still think there is a use case for low-RAM systems too. Ubuntu just announced they're wanting to create a version for small/embedded systems, though it looks like to me there's not much ubuntu left when finished. I guess the same hammer doesn't solve every problem ;) Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thu, 2007-05-10 at 09:16 +1200, Volker Kuhlmann wrote:
Obviously (to me) we're not talking about a desktop system here, there are none with only 128MB of program storage. So what's the point of a distro which needs twice as much RAM as it does disk space to even install? Obviously: no install -> distro is phhhhhhhhht.
Not so obviously. Consider (atleast) two options: 1) leightweight desktop (mail, web, im, office) 2) just NX-client (able to connect to appliction server) Both (should) fit on an USB-stick using some niche-distro's. But we rather use SuSE! (Name, stability and so-on..) Hans -- pgp-id: 926EBB12 pgp-fingerprint: BE97 1CBF FAC4 236C 4A73 F76E EDFC D032 926E BB12 Registered linux user: 75761 (http://counter.li.org) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Volker Kuhlmann schreef:
On Thu 10 May 2007 05:23:24 NZST +1200, Andreas Jaeger wrote:
We'd like to discuss the following topics tomorrow. Please send your comments and suggestions as usual so that I can represent them.
* Smaller systems - what can be done?
Goal: A system with 128 MB of space.
Challenges are especially: * Languages and localization * documentation - > some packages have documentation split up already * theming -> some packages will be split up so that only one theme is in a package.
Are you talking about 128MB of *disk* space or *RAM* space? Please make and keep this distinction clear!
What is the intended/envisaged use of such an installation / system?
Do you think a small system which has only 128MB of software storage space (hard disk, flash card, ...) has >=256MB of RAM to run SUSE version-any on?
Obviously (to me) we're not talking about a desktop system here, there are none with only 128MB of program storage. So what's the point of a distro which needs twice as much RAM as it does disk space to even install? Obviously: no install -> distro is phhhhhhhhht.
Are you thinking people might install on a big computer, then transplant 128MB of storage space into something small? Do gnome, KDE, or languages in this situation have any relevance whatsoever?
Why put effort into saving (say) 200MB of disk space when the smallest disk on the market is 40-80GB?
I have a commercial application for a small control system running Linux. Must have: kernel, networking, services (web, ftp, ssh, ...), basic package management. Of total non-interest: GUIs, desktop software (no keyboard or mouse attached), languages (users see none of this anyway). Similarly for small servers, firewalls, whatever people can hack up. I'm pretty sure there are quite a few of these applications around, and they will stay firmly Debian. How much stuff SUSE does or does not install on disk is a non-issue when the installer hangs by its neck with a black screen half way through its own startup.
Volker
It is true, that if one wants to have a small and stable system, fully functional, with a minimal windowmanager, one ends up with Debian (sarge), which still has a base from 300MB, without x-server. 48MB, for an overcomplete OS, (DSL), when one does like cmd... KDE or GNOME, are not usable for these kind of systems. En indeed 128MB Ram or Diskspace? - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.8-03-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.4" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGQvidX5/X5X6LpDgRAnD7AKDUCdZ7XM0COCFXe2d0iUFbKwmDPACg0xqN A8AUoFnHKsFT1icdtkc2lDI= =KxF7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M9. schreef:
Volker Kuhlmann schreef:
On Thu 10 May 2007 05:23:24 NZST +1200, Andreas Jaeger wrote: [snip][snip]
around, and they will stay firmly Debian. How much stuff SUSE does or does not install on disk is a non-issue when the installer hangs by its neck with a black screen half way through its own startup.
Volker
It is true, that if one wants to have a small and stable system, fully functional, with a minimal windowmanager, one ends up with Debian (sarge), which still has a base from 300MB, without x-server. 48MB, for an overcomplete OS, (DSL), when one does like cmd...
KDE or GNOME, are not usable for these kind of systems. En indeed 128MB Ram or Diskspace?
Reacted before reading the rest, sorry. So it is for the 'driveless' machines, the eeprom bussiness. Now we are talking future.. The way it looks now, the whole 'movable' market (laptops thin clients) will get out of hdd-drives as quick as possible: weight, vulnerable, energie, start-uptime, size... Too many factors are positive, too not make the change... (now it is possible to 'flash', and have unlimited space the size of half a matchbox, it will be used, no doubt about that.
- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.8-03-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.4" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGQv03X5/X5X6LpDgRAhmnAJ97ItjM93XEqLPuxo2lOJzngIrQtgCg3GSE 5VOgk0GsiIniePoSE3thiTE= =6h3W -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
The non-OSS repository was fixed yesterday evening and is propagating to the mirrors, but the main OpenSuSE repository for OSS at; http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source... ; is still incomplete. Any idea of an ETA? Jason -- Jason Boissiere Senior QA Engineer Ingres 01753559529 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 10 May 2007 13:28:37 wrote Jason Boissiere:
The non-OSS repository was fixed yesterday evening and is propagating to the mirrors, but the main OpenSuSE repository for OSS at;
http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-sourc e/suse/
; is still incomplete. Any idea of an ETA?
It should go out today, there was a stale lock file stopping it, but this is solved now. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N�rnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Andreas Jaeger wrote: [...]
For languages we discussed previously already the following and will implement this now: The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed.
So, am I right? We want to split every package and every subpackage in language differented packages? We want that result: package-$lang, package-sub1-$lang, package-sub2-$lang, ... Is it goal to split single language files into language subpackages, e.g. a manual page? If not, is it goal to split two language files into language dependend subpackages? etc. :-) What should become the golden rule here? Wouldn't that remove a lot of the clearness in the package system? Wouldn't that result in lot of fragmenation of the installation media? I might want to consider here, that it was a challenge of not having enough space on the installation media in the past, and we had only a selecting of right packages for the single installation media. Doing this additional fragmentation might advance it again. Regards, Klaus. -- Klaus Singvogel SUSE LINUX Products GmbH Maxfeldstr. 5 E-Mail: Klaus.Singvogel@SuSE.de 90409 Nuernberg Phone: +49 (0) 911 740530 Germany 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
Klaus Singvogel
Andreas Jaeger wrote: [...]
For languages we discussed previously already the following and will implement this now: The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed.
So, am I right? We want to split every package and every subpackage in language differented packages? We want that result: package-$lang, package-sub1-$lang, package-sub2-$lang, ...
Is it goal to split single language files into language subpackages, e.g. a manual page? If not, is it goal to split two language files into language dependend subpackages? etc. :-) What should become the golden rule here?
This would be done via rpm magic, no need to do it yourself (like debuginfo today). Autobuild would then merge the different subpackages into a bigger one.
Wouldn't that remove a lot of the clearness in the package system?
This is currently under investigation by some developers.
Wouldn't that result in lot of fragmenation of the installation media?
No, it wouldn't.
I might want to consider here, that it was a challenge of not having enough space on the installation media in the past, and we had only a selecting of right packages for the single installation media. Doing this additional fragmentation might advance it again.
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ 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
participants (9)
-
Adrian Schröter -
Andreas Jaeger -
Hans Witvliet -
Jason Boissiere -
JP Rosevear -
Klaus Singvogel -
M9. -
Rajko M. -
Volker Kuhlmann