March 2011 - openSUSE Features - openSUSE Mailing Lists

[New: openFATE 310897] drop support for /etc/cryptotab
by fate_noreply＠suse.de 17 May '11

17 May '11

Feature added by: Ludwig Nussel (lnussel) Feature #310897, revision 1 Title: drop support for /etc/cryptotab openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Ludwig Nussel (lnussel) Partner organization: openSUSE.org Description: Until 10.2 yast used /etc/cryptotab (note the 'o') to configure loop mounted crypto containers. 10.3 introduced support for /etc/crypttab which is based on dm-crypt. Entries in /etc/cryptotab still worked but were set up using dm-crypt instead. Now, three years later this is still the case. It's time to drop support for the old /etc/cryptotab and use /etc/crypttab only instead. -- openSUSE Feature: https://features.opensuse.org/310897

1 6

[New: openFATE 311177] RE-Evaluate the Kernels Cache Buffers and all Associated Caching Processes
by fate_noreply＠suse.de 15 May '11

15 May '11

Feature added by: Scott Couston (zczc2311) Feature #311177, revision 1 Title: RE-Evaluate the Kernels Cache Buffers and all Associated Caching Processes openSUSE.org: Unconfirmed Priority Requester: Desirable Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description: I am going to try to suggest the unthinkable - so please bear with me. Over a 3 year period I have watched the utilisation of physical RAM on two X64 PC's. One has 8GIG of RAM the other 4GIG of RAM. I'll just copy and paste the information to make it easier. ************************************************* Total memory (RAM): 7.8 GiB Free memory: 4.5 GiB (+ 2.8 GiB Caches) Free swap: 42.6 GiB ************************************************* Total memory (RAM): 4.9 GiB Free memory: 1.6 GiB (+ 2.3 GiB Caches) Free swap: 66.5 GiB ************************************************** Firstly, I am not going to ever suggest that any change be made to ANY caching algorithms or other O/S dependencyâs, that require the utilisation of VM. Virtual RAM comes into play with its own costs of slowing everything down. The notion of needed more Disk I/O's to stop a hungry application from issuing an 'Insufficient Memory" warning is out of the question I believe. Yes the additional Disk I/O's do allow any application to run, but they are done at the expense of competing with Disk I/O's for file retrieving and storage of application executables code and in essence slow everything down! VM is never a desirable situation and competing for Disk I/O slows everything down - Its not rocket science. What I do see over time in the 4GIG of Physical RAM is better utilised in caching algorithms, but none the less leave an enormous pool of Physical RAM available, even under the highest application load. What I see over time in the 8GIG of Physical RAM is a huge pool of available RAM that sits there and never gets utilised. The 8GIG example may as well only have 4GIG as the presence of a higher value of Physical RAM go to waste as it is never used. This pool of available physical RAM is totally wasted, I believe, and offers no performance enhancing characteristics as the abundant pool remains untouched by any caching buffers and their dynamic allocation does not exist. Rather than reinventing the wheel I have the following suggestion which may very well kill this request completely or make it far more difficult to re-invent the wheel. I have had a very long period of exposure to Netwareâs File Servers' dynamic allocation of Physical RAM and its complexities have been well honed over may years. If we can just use the dynamic allocation of caching, turbo FAT, and TTS services we are almost 90% of the way there. I do agree that the Linux TTS Services are already very strong and possible need no attention. The dynamic changes to the utilisation of ALL the Physical RAM on any Linux O/S Kernel could well do to look at how we dynamically respond when there is abundant Physical RAM present.. Your comments are very very very most welcome as I am starkly aware that suggesting this feature is so very very huge and a difficult task at an Annalists point of view let alone the programmers point of acceptance for changes in huge amounts of code. However I am prepared to run it up the flag poll and see who salutes...:-) Lastly I hope my CR stay fast so as to not ruin the layout.. . -- openSUSE Feature: https://features.opensuse.org/311177

1 14

[openFATE 306979] Increase Installing/Update speed (concurrency)
by fate_noreply＠suse.de 15 May '11

15 May '11

Feature added by: Jörn Knie-von Allmen (Phisiker) Feature #306979, revision 1 Title: Increase Installing/Update speed (concurrency) openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Jörn Knie-von Allmen (phisiker) Description: Solution: Download and Installing in separate processes/threads. So, while installing, the download of the next package can be done (or even partially done). Waiting for terminating the intallprocess of the previous package before to download the next package makes no sense. (Every time when upgrading, this ist annoying). -- openSUSE Feature: https://features.opensuse.org/306979

1 3

[openFATE 307620] Parenta Control
by fate_noreply＠suse.de 11 May '11

11 May '11

Feature added by: J Thimm (thimm) Feature #307620, revision 1 Title: Parenta Control openSUSE-11.3: Unconfirmed Priority Requester: Mandatory Package Wishlist: Unconfirmed Priority Requester: Mandatory Requested by: J Thimm (thimm) Description: I would love to see a parental control feature (with GUI) that allows families -- to use the OS by kids. Parental Control features: - easy configurable and usable This should be compulsory -- because how do you want to educate the youngsters to use the interne? Currently parents cannot "easily" administer such features -- one has to be a professional to get this to work!! I would rather let my kids use Windows because of this -- since there are a number of program do do this job! Am I wrong? Thanks -- openSUSE Feature: https://features.opensuse.org/307620

1 4

[New: openFATE 309579] Dependency tree in zypper summary
by fate_noreply＠suse.de 11 May '11

11 May '11

Feature added by: Ján Kupec (jkupec) Feature #309579, revision 1 Title: Dependency tree in zypper summary Requested by: Ján Kupec (jkupec) Partner organization: openSUSE.org Description: Visualize dependencies of packages (from the installation summary or given on command line) using colored (by type of dependency - recommends, requires, etc) ASCII tree/graph. The feature can be enabled in the info command (zypper info --dep-tree package) and in the installation summary prompt (in which case it would show the graph from the requested packages via all the to-be-installed ones, ending with the installed ones). This feature is meant to be kept simple, and leave more complex analysis to other tools (FATE 309572). Business case (Partner benefit): openSUSE.org: Visualization of package dependencies in a tree makes it easier for packagers to spot incorrect/unneeded dependencies and manage systems, save space, or analyze dependency problems for administrators and users. -- openSUSE Feature: https://features.opensuse.org/309579

1 2

[openFATE 306116] Better lock handling in zypper
by fate_noreply＠suse.de 06 May '11

06 May '11

Feature added by: Marek Stopka (m4r3k) Feature #306116, revision 1, last change by Title: Better lock handling in zypper openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Marek Stopka (m4r3k) Description: Currently only two states in locking of packages are available (keep package as is/do not care about package) but I think it would be much more better to have a possibility lock only some parameters of package... For example you have a 64bit machine, but you want keep some package always in i586 version, but you still wanna version updates in this case there should be a possibility to lock only this parameter. Of course there is a lot of options what else can be locked, for example version of package, meaning that you can't change package version, but release number can change... -- openSUSE Feature: https://features.opensuse.org/306116

1 12

[openFATE 307310] Good CJK / East Asian input support (esp. KDE)
by fate_noreply＠suse.de 05 May '11

05 May '11

Feature added by: Markus K (KAMiKAZOW) Feature #307310, revision 1 Title: Good CJK / East Asian input support (esp. KDE) openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Markus K (kamikazow) Description: Setting up CJK support for typing kanji has always been a bitch for me and I always failed -- especially under KDE 4, even though I consider myself an experienced computer user. Wang Hoi developed an applet that should make it all easier. It's currently in KDE-Review. He wrote about it: http://qiacat.blogspot.com/2009/03/as-my-first-post-first-say-hello-to.html http://mail.kde.org/pipermail/plasma-devel/2009-May/005420.html -- openSUSE Feature: https://features.opensuse.org/307310

1 9

[openFATE 307873] Add the uuid-ossp module to postgresql-contrib
by fate_noreply＠suse.de 04 May '11

04 May '11

Feature added by: Reinhard Max (rmax) Feature #307873, revision 1 Title: Add the uuid-ossp module to postgresql-contrib openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Reinhard Max (rmax) Partner organization: openSUSE.org Description: As it has been pointed out in bnc#534050 and in private mail, we are missing the uuid-ossp module from our postgresql-contrib package. The reason for this is, that it depends on the ossp-uuid library, for which we do not yet have an official package in Factory. For 11.3 both, the library package and the contrib modules should be added. Business case (Partner benefit): openSUSE.org: To stay compatible with the PostgreSQL packages of other distributions and with applications that require this module. -- openSUSE Feature: https://features.opensuse.org/307873

1 4

[New: openFATE 310090] Release cycle - guarantied dup - sync with Distros
by fate_noreply＠suse.de 26 Apr '11

26 Apr '11

Feature added by: Ralph Ulrich (ulenrich) Feature #310090, revision 1 Title: Release cycle - guarantied dup - sync with Distros openSUSE-11.4: Unconfirmed Priority Requester: Important Requested by: Ralph Ulrich (ulenrich) Description: openSUSE should have a shorter and synced with Ubuntu/Fedora release cycle. If there is an easy and guarantied way to dist-upgrade like a script working: 1) change repos to newest release 2) "zypper dup -d" # only download 3) save a list of packages installed.list 4) remove all but a openSUSE minimal pattern 5) "zypper dup" 6) reboot and zypper install installed.list Then benefits: * openSUSE more in sync with all over linux development * support needs less workload, patches can be "stolen" * "zypper dup" guarantied successful for openSUSE-minimal pattern -- openSUSE Feature: https://features.opensuse.org/310090

1 5

[openFATE 306471] auto create torrent files for images created
by fate_noreply＠suse.de 20 Apr '11

20 Apr '11

Feature added by: Jigish Gohil (cyberorg) Feature #306471, revision 1, last change by Title: auto create torrent files for images created Buildservice: Unconfirmed Priority Requester: Important Requested by: Jigish Gohil (cyberorg) Description: Currently only metalink is created for the images created on the build service, it would be nice to have torrent files created too at the time of publishing the images. -- openSUSE Feature: https://features.opensuse.org/306471

1 4