October 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307496] return to having no default desktop environment
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Christian Jäger (eet) Feature #307496, revision 1 Title: return to having no default desktop environment openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Christian Jäger (eet) Description: The recent decision that openSUSE needs a default desktop environment must be reverted. * This decision has lead to frictions between the openSUSE sub-communities of GNOME and KDE users which might ultimately result in a drain of supporters of one of these sub-communities to a different distribution. * A default choice during installation gives the wrong impression that even now openSUSE chiefly supports the defaulted desktop environment while the other one is to be used 'at one's own risk' * This decision has acutely affected openSUSE's position as the only distribution which credibly supports both desktop environment * The gains to be had through a 'default desktop environment' are minor to zero, the potential loss and damage to community caused by it is catastrophic -- openSUSE Feature: https://features.opensuse.org/307496

1 10

[openFATE 307065] Terminate DVD image creation and only provide LiveCDs and Net Installs
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Stephen Kellat (skellat) Feature #307065, revision 1 Title: Terminate DVD image creation and only provide LiveCDs and Net Installs openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Stephen Kellat (skellat) Description: The discussion in openFATE #306967 relates to making KDE the default desktop environment for openSUSE. The question of choice arises there. A work-around to this would be to cease creating DVD images for installation and instead focus on LiveCDs and Net Install discs. Parity across desktop environments would be possible in having separate GNOME and KDE LiveCDs while also promoting Xfce into its own LiveCD instead of its obscurity on the DVD. As for Net Install discs, those are intended for experienced users so the rationale being exhibited in #306967 for catering to the needs of new users would not necessarily apply. Net Install discs could keep an expanded desktop environment choice list. Test Case: User desires GNOME experience in openSUSE and downloads the GNOME LiveCD. The kicker at http://software.opensuse.org would make the choice available to the user. Other users desire a KDE experience, an Xfce experience, or an LXDE experience would also be potentially directed by the kicker. ISO naming conventions would have to be adjusted to take into account the variety of LiveCDs possible. Use Case: Building LiveCDs decreases the amount of bandwidth to be consumed by potential users who would otherwise secure the DVD ISO. SUSEStudio could be tied in so that project leaders who were so minded could offer refreshed respins on their own outside the normal distribution cycle. -- openSUSE Feature: https://features.opensuse.org/307065

1 8

[openFATE 307495] GNOME default
by fate_noreply＠suse.de 10 Dec '09

10 Dec '09

Feature added by: Christian Jäger (eet) Feature #307495, revision 1 Title: GNOME default openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Christian Jäger (eet) Description: I propose to make GNOME the default desktop in openSUSE. It has been decided that users are overly challenged by having to decide between the GNOME and KDE desktop environments during the installation procedure. If this is true, such users will be overly challenged by the KDE desktop environment which is now planned to be the default choice. This proposal is meant to solve this problem by changing the default desktop environment for openSUSE to GNOME. These are the reasons why GNOME should be defaulted in openSUSE, not KDE: 1) By default an easy-to-use desktop environment should be installed: The way it is planned now, users who are uncertain about what desktop-environment they want because they are not tech-savvy or who don't know either KDE nor GNOME will end up with KDE because it will be defaulted. This basically means that those users who are most in need of a newbie-friendly desktop will get KDE. This clearly is wrong. KDE is an expert-desktop; it's strength is that its highly configurable. This is not what new and/or non-tech-savvy users want, nor is it what they need. KDE users are usually technically advanced and will know how to click the 'KDE' tickbox, while newbies should get GNOME. 2) Consistency with the NOVELL SUSE LinuxEnterprise Linux releases: Users who have heard about SLED/SLES will expect openSUSE to resemble those enterprise-level distributions. They will feel short-changed if they are presented with the unfamiliar KDE-desktop after an openSUSE install 3) GNOME is the world's standard Linux desktop environment: In order to compete on a global level, we should adopt the world's favored Linux desktop environment. The mainly regionally (Germany/Europe) successful KDE is not the solution for international success but a niche product. All globally successful distributions use GNOME; such as Red Hat Enterprise Linux, Fedora, Debian and most prominently Ubuntu. 4) Ubuntu: We must present a strong alternative to Ubuntu. This can NOT be a KDE desktop as we can see by the relatively low popularity of Kubuntu. KDE can never attract more than a minority of expert users. We must build on the innovations that won SLED awards and popularity. 5) Innovation: To say it outright, KDE had its chance to innovate and failed. KDE 4 was a massive disappointment even to hard-core KDE users in that it produced no enhancement to user-experience nor stability. With the upcoming GNOME 3 release openSUSE has the chance to present revolutionary user experience by the introduction of Gnome-shell as an alternative UI, while still providing more users with the option to continue using the traditional GNOME UI. 6) Attracting developers: What openSUSE already has is an abundance of contributors to KDE. We now urgently need to attract more GNOME developers by focusing on GNOME development and showing commitment to success in our competition with Ubuntu. openSUSE should, of course, also ship and support KDE. So experienced users can choose it. But new users should have GNOME as a default. Please note that I would have preferred if openSUSE had remained with its policy of treating both desktop-environments as equals, but unfortunately, following a request by some KDE-proponents, that policy has been changed to a popularity contest between both DEs by statistics and voting-contests in openFATE. This feature request is nothing but a neccessary reaction to proposal #306967, so that users have a choice to vote for either KDE or GNOME to be defaulted. -- openSUSE Feature: https://features.opensuse.org/307495

1 15

[openFATE 308183] Hdd Label
by fate_noreply＠suse.de 06 Dec '09

06 Dec '09

Feature added by: andrea martin (Il_Cjargnel) Feature #308183, revision 1 Title: Hdd Label openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: andrea martin (il_cjargnel) Description: Is posible in yast2-->partitioner make a boxtest for canghe a label of hard disk / partition? Thank's by Andrea -- openSUSE Feature: https://features.opensuse.org/308183

1 1

[New: openFATE 308249] ability of disable IPv6 auto-configuration
by fate_noreply＠suse.de 05 Dec '09

05 Dec '09

Feature added by: Per Jessen (pjessen) Feature #308249, revision 1 Title: ability of disable IPv6 auto-configuration openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Per Jessen (pjessen) Partner organization: openSUSE.org Description: Add a setting in /etc/sysconfig/network/ifcfg-XXXX to specify "Do not auto-configthis interface for IPv6". Business case (Partner benefit): openSUSE.org: It would appear that other distros, e.g. CentOS, have the ability to specify that a network interface should not be auto-configured for IPv6. This is useful when the interface will not be used for IPv6, e.g. for PPPOE. -- openSUSE Feature: https://features.opensuse.org/308249

1 1

[openFATE 306976] Incluir Firefox en qt4 en forma predeterminada
by fate_noreply＠suse.de 03 Dec '09

03 Dec '09

Feature added by: Luis Bodino (luigi_bodino) Feature #306976, revision 1 Title: Incluir Firefox en qt4 en forma predeterminada openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Luis Bodino (luigi_bodino) Description: Propongo que se use la versión qt de firefox para una mejor integración con kde -- openSUSE Feature: https://features.opensuse.org/306976

1 9

[openFATE 307381] Include PDF Mod
by fate_noreply＠suse.de 01 Dec '09

01 Dec '09

Feature added by: Gabriel Burt (gabrielburt) Feature #307381, revision 1 Title: Include PDF Mod openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Gabriel Burt (gabrielburt) Description: PDF Mod is a new tool for doing simple manipulations to PDF documents, including removing, rotating, and extracting pages. -- openSUSE Feature: https://features.opensuse.org/307381

1 10

[openFATE 307613] Add Action Code Fields and Generate Email Texts According to Action Code Field
by fate_noreply＠suse.de 23 Nov '09

23 Nov '09

Feature added by: Scott Couston (zczc2311) Feature #307613, revision 1 Title: Add Action Code Fields and Generate Email Texts According to Action Code Field openFATE: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: Currently we open a new Feature request and the creator is not aware of any other action taken or added to the feature request. If a Feature is Closed due Dupe or invalid the creator is never aware of this. Other changes to the feature become lost to the original author. No one who contributes to the feature request ever gets an auto generated message as in current Bugzilla notifications. If the feature request is closed the author has no idea this has occured. Can we create an Action Code Field in each modification entry of any feature request. Here we can have default actions such as 'NEW' when a feature is created and the authors email added in the same manner as Bugzilla. Each additional comment can have a default Action code of 'ADDED-INFO' and add the authors email to this new entry. Each addition that clarifies or redefined the feature can have a 'CLARIFIED' or REDEFINED' action code field. The generation of messages of anything added to the feature request is subordinate and equal to the level of added entries and action code dependant. For example. The author of the creation of a feature will recieve email notification of ever addition to the feature. Anyone who add a third addition to the feature receives an email message and all subordinate entries back as far as the original author. Action code fields can be via Drop down menu box and the logic of selection of action code must be enforced. For example the First creation of a feature adds a mandatory NEW action code. This action would be the only non greyed out selection from the drop down list. The next entry, if the entry is to suggest 'REDEFINED' by drop down selection, would have 'NEW' greyed out and not accessible and leave 'REDEFINED' or 'CLARIFIED' or 'NEGATED'....etc available from drop down list. Once a new entry has been added to a feature request the previous entry action code field is not accessible. If the feature request gets 'ADDED-FUNCTION' and thereby put into production, no further entry's should be permitted and the feature locked with the exception of an added entry with the action code of 'COMMENT' from the drop down. Again message generation is equal and subordinate to the entry being added. For each and every Branch of comment or test-case a default action code filed should be maintained. Comments Please and I will manually check on this feature request's disposition. Scott -- openSUSE Feature: https://features.opensuse.org/307613

1 5

[openFATE 306512] Web Services for Management (WS-Man) has official port numbers now
by fate_noreply＠suse.de 20 Nov '09

20 Nov '09

Feature added by: Klaus Kämpf (kwk) Feature #306512, revision 1 Title: Web Services for Management (WS-Man) has official port numbers now openSUSE-11.2: New Priority Requester: Desirable Requested by: Klaus Kämpf (kwk) Partner organization: openSUSE.org Description: >From the openwsman-devel list From: A_Venkatachalam(a)Dell.com To: openwsman-devel(a)lists.sourceforge.net Cc: Vivek_Rajendran(a)Dell.com, Girish_Prakash(a)Dell.com, Chandrasekhar_P(a)Dell.com Subject: [Openwsman-devel] Ports for OpenWSMAN Hi Currently OpenWSMAN 2.1 uses 8888 and 8889 as the default HTTPS and HTTP ports respectively. But as per IANA the registered ports for WSMAN are 5985(HTTP) and 5986(HTTPS) http://www.iana.org/assignments/port-numbers wsman 5985/tcp WBEM WS-Management HTTP wsman 5985/udp WBEM WS-Management HTTP wsmans 5986/tcp WBEM WS-Management HTTP over TLS/SSL wsmans 5986/udp WBEM WS-Management HTTP over TLS/SSL We need to update “openwsman.conf” to make use of these ports by default. Already MS Winrm2.0 is making use of these ports. Thanks, Arun Venkatachalam Dell R & D Centre, Bangalore. Extn - 78973 Business case (Partner benefit): openSUSE.org: Be standards compliant, especially in mixed Windows/Linux enivronments. Discussion: #1: Klaus Kämpf (kwk) (2009-06-15 11:51:12) Changing ports in a SP upgrade might be harmful. Being standards-compatible might outweight the downsides. Needs PM decision ;-) #2: Klaus Kämpf (kwk) (2009-06-15 11:51:56) If we decide to change ports, yast-firewall and documentation might need to be adapted. -- openSUSE Feature: https://features.opensuse.org/306512

1 13

[openFATE 306353] add italian ISP on yast DSL providers list
by fate_noreply＠suse.de 20 Nov '09

20 Nov '09

Feature added by: andrea florio (anubisg1) Feature #306353, revision 1, last change by Title: add italian ISP on yast DSL providers list openSUSE-11.2: Unconfirmed Priority Requester: Desirable Requested by: andrea florio (anubisg1) Description: what about to add italian ISP to that list? i can give you all infos needed -- openSUSE Feature: https://features.opensuse.org/306353

1 9