Feature added by: Cornelius Schumacher (cschum)
Feature #309503, revision 1
Title: Beautiful one-click-install
Requested by: Cornelius Schumacher (cschum)
Description:
<!--StartFragment-->Garrett made a great <a href="http://ux.suse.de/~garrett/public/hackweek/oneclick/mockups/oneclick-mockup…">mockup</a> for a much more beautiful one click installer some time ago. It would be great to get this implemented.
I think it could be done with a small Qt application which uses libzyppe or PackageKit or something like that as the backend to do the actual installation.
I won't be able to spend much time on it, but Will said he might be interested. Maybe also one of the YaST guys could join, e.g. Michael Andres.<!--EndFragment-->
--
openSUSE Feature:
https://features.opensuse.org/309503
Feature added by: Iaroslav Andrusiak (pontostroy)
Feature #318841, revision 1
Title: iconv 32-bit libs for x86_64
Requested by: Iaroslav Andrusiak (pontostroy)
Partner organization: openSUSE.org
Description:
Need to do glibc-locale-32bit.x86_64.rpm for x86_64 architecture
Business case (Partner benefit):
openSUSE.org: openSUSE does not provide /usr/lib/gconv/*so libs (glibc-locale) for x86_64, these libraries are needed to Shadow Warrior and maybe for other apps.
--
openSUSE Feature:
https://features.opensuse.org/318841
Feature added by: Sławomir Lach (Lachu)
Feature #318428, revision 1
Title: Add two new function to glib
openSUSE Distribution: Unconfirmed
Priority
Requester: Neutral
Requested by: Sławomir Lach (lachu)
Partner organization: openSUSE.org
Description:
Programmers need two new function: is_stack_alloc and is_heap_alloc.
It are necessary, because some functions frees memory and it can avoid complications, while is_stack_alloc returns true(in this case memory isn't freed).
--
openSUSE Feature:
https://features.opensuse.org/318428
Feature added by: Vinicius B. Rodrigues (viniciusbrbio)
Feature #318922, revision 1
Title: Gnome more elegant and plymouth
openSUSE Distribution: Unconfirmed
Priority
Requester: Desirable
Requested by: Vinicius B. Rodrigues (viniciusbrbio)
Partner organization: openSUSE.org
Description:
I think that GNOME should have a unique green theme, as well as an interesting plymouth and that really works.
OpenSUSE is very robust and stable. Now could invest time in details that make a big difference together.
--
openSUSE Feature:
https://features.opensuse.org/318922
Feature changed by: akash vishwakarma (vish_99)
Feature #305326, revision 20
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
+ openSUSE Distribution: Rejected by akash vishwakarma (vish_99)
+ reject reason: Feature already implemented
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
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: Alex Jordan (strugee)
Feature #318872, revision 1
Title: Allow building reproducible packages in OBS
Buildservice: Unconfirmed
Priority
Requester: Neutral
Requested by: Alex Jordan (strugee)
Partner organization: openSUSE.org
Description:
"Reproducible builds" refers to the idea that packages should have the ability to be built locally and come out bit-for-bit identical to the widely distributed copy. It would be nice if OBS produced reproducible packages in the event that it can easily do so (and when asked to, probably). For more details, see the Tor Project's blog posts on [why this is important][1] and [how they implemented it in the Tor Browser Bundle][2].
[1]: https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and… [2]: https://blog.torproject.org/blog/deterministic-builds-part-two-technical-de…
Business case (Partner benefit):
openSUSE.org: Reproducible builds give packages useful security properties. In particular, in the event that OBS is compromised (probably by a malicious actor, but also possibly by within SUSE, someone associated with upstream, etc.), that fact can be independently caught.
--
openSUSE Feature:
https://features.opensuse.org/318872
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: Sławomir Lach (Lachu)
Feature #318831, revision 1
Title: Transactional filesystem
openSUSE Distribution: Unconfirmed
Priority
Requester: Neutral
Requested by: Sławomir Lach (lachu)
Partner organization: openSUSE.org
Description:
With Btrfs filesystem and subvolumes and copy-on-write it's (probably) possible to create transactional filesystem. How it could work? 1. It should be system call to start new transaction. Transaction would be per-thread. Any created file will be saved to subvolume. Any modified file will be saved to subcvolume. All process performing read opeation will see old version of file. Write operation on modified file could cause one of two thinks: 1) operation would block, 2) Transaction is deleted and process that starts transaction is informed about this. After process call function to end transaction, subvolumes would be megred. 2. It could be also per-file transaction. If process open file with special flag, a file-transaction is started. It works similar like previous transaction type, but only for file, so: 1) If another process open the same file for reading, it sees old version. 2) If process open file for writting, then transactionis rollback or open will block. Changes will be applied (old file will be replaced with new), when process close all fd connected to file in transaction.
Instead of using BTRFS subvolumes and copy-on-wirte you can use some union fs, which saves modification date of file, while opened and comparing modification date, when saving. If date was changed, transaction will rollback.
Use Case:
There's some problem with baddly written tool, like programs, which saves file firstly in /tmp and then moving it to correct location to avoid problems.
Business case (Partner benefit):
openSUSE.org: Unix is great, because it's possible to remove file, when other process using it, but there's no way to change content of file, when process is using it. There's some problem with baddly written tool, like programs, which saves file firstly in /tmp and then moving it to correct location to avoid problems.
With transactional filesystem it's a lot simpler.
--
openSUSE Feature:
https://features.opensuse.org/318831