Feature added by: Marius Tomaschewski <mt(a)novell.com>
Feature #305356, revision 1, last change by
Title: 802.1x authentication on wired network using YaST via wpa_supplicant
openSUSE-11.2: New
Priority
Requester: Desirable
Requested by: Marius Tomaschewski <mt(a)novell.com>
Partner organization: openSUSE.org
Description:
Some networks using 802.1x authentication on metallic Ethernet and I think it would be cool have a possibility, handle this connection type using YaST.
The major problem to support this is that the wpa_supplicant is in /usr/sbin; it seems also to be difficult to move it to /sbin because of all the libs the wpa_supplicant is using.
What would be required, is to extent the "supported_on_localfs" function to check this and start the interface in remotefs flow when 802.1x is enabled. That is, using remotefs on 802.1x authenticated interfaces would be not possible -- same as with NetworkManager.
--
openSUSE Feature:
https://features.opensuse.org/?rm=feature_show&id=305356
Feature added by: Maciej Pilichowski (truemacias)
Feature #314850, revision 1
Title: Ability to create encrypted partitions without using LVM
openSUSE Distribution: Unconfirmed
Priority
Requester: Desirable
Requested by: Maciej Pilichowski (truemacias)
Partner organization: openSUSE.org
Description:
With no LVM OS installer is too strict when it comes to choose what partitions can be encrypted. From technical POV only /boot partition really has to be left not encrypted but for the rest -- as root, /var, /usr it can be done.
So please provide this option in installer. Current lack of support is strange and limits power of the Linux capabilities.
--
openSUSE Feature:
https://features.opensuse.org/314850
Feature added by: Martin Herkt (lachs0r)
Feature #318813, revision 1
Title: ALSA: Improved dmix defaults for multi-channel audio
openSUSE Distribution: Unconfirmed
Priority
Requester: Desirable
Requested by: Martin Herkt (lachs0r)
Partner organization: openSUSE.org
Description:
For those who still reject PulseAudio in favor of ALSAâs dmix, thereâs a small but significant improvement to the default configuration with regard to multi-channel audio sources. Currently, the default dmix device is limited to stereo sources, which means that playing surround sound sources necessitates exclusive access. Having to make sure nothing else is using the underlying hardware when trying to watch a movie is not nice. Thereâs a relatively trivial solution to this, using the upmix plugin, which is included with the alsa-plugins package. In general, I see no reason not to install this package, seeing as it also includes the Speex resampler (which is used automatically if available, and without which audio quality will be severely degraded for sources that need to be resampled by ALSA first).
The only known case where this does not âjust workâ is when audio hardware exposes channels as multiple stereo pair subdevices instead of a true multi-channel card (e.g. EMU10K1), but this hardware is a special case anyway (and a somewhat rare one these days), and Iâm sure workarounds are possible.
Test Case:
https://github.com/mpv-player/mpv/wiki/ALSA:-Surround-Sound-and-Upmixing
I wrote this article for users of mpv. It contains an example asoundrc. So to test this, make equivalent changes to the default dmix configuration and try playing a surround sound file with e.g. mpv (or use speaker-test) while something else is playing e.g. a stereo stream via the default device. Playback should not fail, and both sources should output sound to the appropriate channels (i.e. the stereo source should be upmixed and mpv should detect the correct channel map automatically, applying downmixing as necessary).
Use Case:
Playing audio from several applications with different channel configurations (e.g. stereo system notifications and a media player playing a surround sound file).
Business case (Partner benefit):
openSUSE.org: For some users, PulseAudio does not solve any problems (and in fact still is the source of some), or they may prefer dmix for other reasons, but with the current default configuration, just watching movies or playing games can be inconvenient, as it would require exclusive access to the sound hardware, and in some cases (e.g. openal-soft) editing configuration files just to get the channel mapping right.
--
openSUSE Feature:
https://features.opensuse.org/318813
Feature added by: Björn Voigt (bjoernv)
Feature #318809, revision 1
Title: Add support for unlocking LUKS root volumes during boot process via SSH
openSUSE Distribution: Unconfirmed
Priority
Requester: Important
Requested by: Björn Voigt (bjoernv)
Partner organization: openSUSE.org
Description:
Unlocking a openSUSE system with full disk encryption is currently done locally on the console with a passphrase input. Systems installed with distributions like Debian and Ubuntu can be unlocked via SSH: https://www.debian-administration.org/article/579/Unlocking_a_LUKS_encrypte… There is a DRACUT module in development for this feature:
https://github.com/haraldh/dracut/pull/39https://bugzilla.redhat.com/show_bug.cgi?id=524727
Use Case:
Servers which are controlled via remote control can be easily unlocked via SSH. The feature simplifies the management of full disk encrypted servers, because starting and restarting servers can be done without local console access.
--
openSUSE Feature:
https://features.opensuse.org/318809
Feature added by: lissa coffey (lissacoffey)
Feature #318808, revision 1
Title: Bibliography management system
Education Li-f-e: Unconfirmed
Priority
Requester: Important
Requested by: lissa coffey (lissacoffey)
Partner organization: openSUSE.org
Description:
a web-based bibliography management system. Its functionality is similar to jabref, but the main advantage is that it allows to share and simultaneously access the bibliography database (which is managed with MySQL) . (http://unitedfilter.com/) The programming language is PHP. I found this system highly desirable to be included at least in openSUSE Life if not in openSUSE distribution
--
openSUSE Feature:
https://features.opensuse.org/318808
Feature changed by: akash vishwakarma (vish_99)
Feature #305326, revision 19
Title: 5 Second Boot
openSUSE-11.2: Rejected by Stephan Kulow (coolo)
reject date: 2009-02-09 15:47:52
reject reason: Sorry to be harsh, but this feature can't be implemented
as asked for.
Priority
Requester: Mandatory
+ openSUSE Distribution: Unconfirmed
+ Priority
+ Requester: Desirable
Requested by: Jared Allen (jpallen)
Product Manager: Michael Loeffler (sprudel24)
Partner organization: openSUSE.org
Description:
The amount of time required to boot up needs to be reduced drastically.
I suggest we consider the work being done in this article:
http://lwn.net/Articles/299483/
as our baseline and strive to make similar adjustments.
Business case (Partner benefit):
openSUSE.org: As we continue to get more involved in the Thin Client
and UMPC markets, boot time becomes increasingly important. Intel's
Moblin project is touting boot time as one of the significant
features/advantages of their Moblin project. There are signs that other
distros are following suit. We have at least one Thin Client partner
that is requesting significant improvements in boot time in order to
remain competitive. In fact, SLETC would have been included on more
thin client hardware shipments to-date had we a faster boot time.
Discussion:
#1: Jared Allen (jpallen) (2008-10-06 17:03:30)
I spoken with both AJ and Michael Meeks regarding this requirement. AJ
suggested that include Coolo in the discussion since it will most
definitely affect the distribution as a whole.
#2: Stephan Kulow (coolo) (2009-01-20 15:18:14)
similiar adjustments? Do you mean the "We had to do a lot of damage to
X," part or the "use xfce" part?
There is a limit on what you can do in a generic system and many of the
low hanging fruits is already done. If you talk about getting a thin
client to boot fast, then making transparent use of suspend & resume is
the way to go IMO. Booting off cold hardware is problematic if you want
more than xfce. There are about 100MB data to read for a pretty
standard KDE session (and I assume GNOME is similiar) - on a pretty
fragmented file system you get ~8MB/s netto - so just reading your
files takes already 12s.
Making preload dynamic on the blocks actually used is something that
was discussed long, long ago, but the kernel still doesn't provide the
infrastructure - so this is one of the TODOs, but possibly Intel got
that ball rolling.
Kernel drivers being quicker with probing would be another TODO, also
listed in the article.
Another urgent TODO is defragmentation because readahead helps only a
little if the next update will scatter the files around your 1TB hard
drive.
#3: Jean-Daniel Dodin (jdd) (2009-02-15 10:28:27)
may be this is plain stupid, forgive me if it is. The install time was
dramatically reduced by the use of "images" of installs. Could it not
be possible to build "images" of the installed system - that is to have
all the necessary files on boot able to read at once. It's not exactly
the same as suspend to disk, of like a suspend to disk with only the
system.
Most computers never change hardware and a new grub entry could be
added: boot with new hardware
#4: Ralph Ulrich (ulenrich) (2009-08-05 23:14:17)
Squashfs could be utilized for that. It would be superior to preload as
it also could do the initrd thing. But every time a /bin/lib is updated
the whole squash-start-image needs to be updated also. Andthere it is
to make sure such an image is not fragmented on disk.
#5: Sławomir Lach (lachu) (2010-06-30 12:23:07)
Already we need to update dependencies of running scripts after adding
a new script. We can create tarbar on this command. Init system may
only checks last modify date for each file in tarbar and compare it
with file outside tarbar.
--
openSUSE Feature:
https://features.opensuse.org/305326