Written by cato1986 the 22 Dec 08 at 20:20.

Ubuntu Brainstorm was updated in January 2009. Since the idea #16733 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #16733 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by kenden the 18 Apr 08 at 16:24.

Ubuntu Brainstorm was updated in January 2009. Since the idea #7220 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #7220 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by andrearatto the 2 Mar 08 at 10:22.

Ubuntu Brainstorm was updated in January 2009. Since the idea #2436 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #2436 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by rsimone the 21 Dec 09 at 09:30.

Indeed nowadays the computers have a lot of memory. This would (following the well-known rule) to create a very large swap partition. This leads to a big waste of space and in the future the problem will only get worse.
At times the choice is required, otherwise it can't be exploited the hibernation to disk.
I propose to use (by default) a swap file with dynamic size and give the user the possibility, through advanced choices made in the installation step, of use a swap partition instead a swap file (for example, might come handy when you make multiple installations and you want share the swap partition)

Indeed nowadays the computers have a lot of memory. This would (following the well-known rule) to create a very large swap partition. This leads to a big waste of space and in the future the problem will only get worse. At times the choice is required, otherwise it can't be exploited the hibernation to disk. I propose to use (by default) a swap file with dynamic size and give the user the possibility, through advanced choices made in the installation step, of use a swap partition instead a swap file (for example, might come handy when you make multiple installations and you want share the swap partition)

Written by tuxest the 24 May 12 at 21:12.

Next to the history button in the software centre there could be "Installing windows software" button. When pushing it the user would get three things: information about which are Ubuntu alternatives for windows software (has been proposed before on this site), explained option to use CrossOver and some integrated functionalities of the wine front-end PlayOnLinux. The first section would give information on the most popular Windows software and its alternatives (MS Office and LibreOffice, Photoshop and Gimp, and etc.). The second would explain what is CrossOver, why it is needed and guidelines how to set it up (a button would be even better). Also using virtual machine could be introduced under this section as the common nominator is the “things that solve your problem in exchange for money”. The third would provide user with a free functionalities based on PlayOnLinux. The last option could be accompanied with a message that Ubuntu team advices people to use software from Ubuntu repositories and that the Windows software might not work as well on Ubuntu as it does on Windows. The key is to present the information well and improve accessibility to functions and the right place to do it in Ubuntu is the software centre.

Playonlinux enables to install impressive list of Windows software easily by user just choosing the programme/game from the list and inserting installation media if needed. Some work well and some not that well- the information about that is shared by the community and is visible to user when s/he browses the list. I know that it is not always that rosy experience as I might make it sound but it is a half empty glass and that is a lot for a thirsty.
For an example Ubuntu could at first choose few PlayOnLinux scripts that already work and in return contribute a bit to the development of those scripts how they can. PlayOnLinux would benefit as it would enable to grow their community.

Next to the history button in the software centre there could be "Installing windows software" button. When pushing it the user would get three things: information about which are Ubuntu alternatives for windows software (has been proposed before on this site), explained option to use CrossOver and some integrated functionalities of the wine front-end PlayOnLinux. The first section would give information on the most popular Windows software and its alternatives (MS Office and LibreOffice, Photoshop and Gimp, and etc.). The second would explain what is CrossOver, why it is needed and guidelines how to set it up (a button would be even better). Also using virtual machine could be introduced under this section as the common nominator is the “things that solve your problem in exchange for money”. The third would provide user with a free functionalities based on PlayOnLinux. The last option could be accompanied with a message that Ubuntu team advices people to use software from Ubuntu repositories and that the Windows software might not work as well on Ubuntu as it does on Windows. The key is to present the information well and improve accessibility to functions and the right place to do it in Ubuntu is the software centre. Playonlinux enables to install impressive list of Windows software easily by user just choosing the programme/game from the list and inserting installation media if needed. Some work well and some not that well- the information about that is shared by the community and is visible to user when s/he browses the list. I know that it is not always that rosy experience as I might make it sound but it is a half empty glass and that is a lot for a thirsty. For an example Ubuntu could at first choose few PlayOnLinux scripts that already work and in return contribute a bit to the development of those scripts how they can. PlayOnLinux would benefit as it would enable to grow their community. The idea is not that the Windows programmes should be installed the same way and as easily as the ones from Ubuntu repositories. The idea is that software centre would be a right place where to provide such information and where to integrate already existing solutions.

Written by lukenpi the 20 May 12 at 18:06.

* Use the default location (~/.wine)
* Create a new prefix [ * path choice button * ]
* Use an existing prefix [ * path choice button * ]

[ ] Remember my answer

----------------------
The first time Wine is run this dialog box will be prompted. Every new prefix created with this gui will be saved and maybe proposed under "use an existing prefix" as a combo box.

* Use the default location (~/.wine) * Create a new prefix [ * path choice button * ] * Use an existing prefix [ * path choice button * ] [ ] Remember my answer ---------------------- The first time Wine is run this dialog box will be prompted. Every new prefix created with this gui will be saved and maybe proposed under "use an existing prefix" as a combo box.

Written by lukenpi the 25 May 12 at 14:36.

as suggested by Ssdg, a good solution could be this right click option (maybe just a simple nautilus extension?).

as suggested by Ssdg, a good solution could be this right click option (maybe just a simple nautilus extension?).

Written by a.s. the 25 May 12 at 10:51.

Full path on mouse hover or on right-click will be very nice.
I guess that preferably on hover to reduce the number of clicks.
And, well, once we are showing something on hover, maybe some more properties (full path and date of last modification may be the most useful in my opinion but we might think in showing all the options the nautilus right-click menu does show --and the path!--)

Full path on mouse hover or on right-click will be very nice. I guess that preferably on hover to reduce the number of clicks. And, well, once we are showing something on hover, maybe some more properties (full path and date of last modification may be the most useful in my opinion but we might think in showing all the options the nautilus right-click menu does show --and the path!--)

Written by cousteau the 25 May 12 at 08:10.

Automatically aliasing `sudo` to `sudo -H` would workaround this problem (the -H option makes sudo change the $HOME variable to /root). This can be done by default by adding an `alias sudo='sudo -H'` line to the default .bashrc

Automatically aliasing `sudo` to `sudo -H` would workaround this problem (the -H option makes sudo change the $HOME variable to /root). This can be done by default by adding an `alias sudo='sudo -H'` line to the default .bashrc

Written by Lachu the 10 Sep 09 at 07:55.

Ubuntu(and other distribution) should provide D-BUS based API for installer/uninstallers. You will get extra points if you integrate it with package database ;-) .

It should been integrated with PolicyKit, so administrators can give users access to install many kind of software(example software, which no needs setting suid bit and installing in /opt and don't change any files, can be installed by normal user; software which needs install in /sbin or /bin or /usr/bin, /usr/sbin should be installed only by superuser; or whatever).

This API should gives many functions, like copy executable into system directory(/bin), copy executable into superuser directory(/sbin, /usr/sbin or whatever), install user library(/usr/lib), install system-wide library(/lib), change file(delete existing file or writing own in the same place), change group of file, change owner of file, set uid bit, set guid bit, install nonexecutables(data) to /usr/share/*, installing user software(only have access to /opt), start installation.

All this action will be logged and reported. Additionally user may have simple uninstall software by system tools, because all performed operation are logged.

Installer should first call start installer function, so system show message to user like: This program will install software - continue? If user agree, DBUS returns the path, where the installer should unpack all of the files (in /tmp directory). Of course installer should register software name, etc., but it is long term task. If this is a game, it should install in /opt, so it call DBUS API to copy file from unpack folder into specify /opt folder, like copy_file_to_opt(file_name, opt_suffix).

Ubuntu(and other distribution) should provide D-BUS based API for installer/uninstallers. You will get extra points if you integrate it with package database ;-) . It should been integrated with PolicyKit, so administrators can give users access to install many kind of software(example software, which no needs setting suid bit and installing in /opt and don't change any files, can be installed by normal user; software which needs install in /sbin or /bin or /usr/bin, /usr/sbin should be installed only by superuser; or whatever). This API should gives many functions, like copy executable into system directory(/bin), copy executable into superuser directory(/sbin, /usr/sbin or whatever), install user library(/usr/lib), install system-wide library(/lib), change file(delete existing file or writing own in the same place), change group of file, change owner of file, set uid bit, set guid bit, install nonexecutables(data) to /usr/share/*, installing user software(only have access to /opt), start installation. All this action will be logged and reported. Additionally user may have simple uninstall software by system tools, because all performed operation are logged. Installer should first call start installer function, so system show message to user like: This program will install software - continue? If user agree, DBUS returns the path, where the installer should unpack all of the files (in /tmp directory). Of course installer should register software name, etc., but it is long term task. If this is a game, it should install in /opt, so it call DBUS API to copy file from unpack folder into specify /opt folder, like copy_file_to_opt(file_name, opt_suffix). I know is less secure than installing package, but is more secure than giving installer root privileges.

Written by dandart the 10 Sep 09 at 20:43.

Create a format that all distros can use and is easy to implement. Perhaps integrate into Apt/Rpm or have packages that both can understand somehow. Then we can download "Linux" package without having to worry if we want Apt or Rpm.

Create a format that all distros can use and is easy to implement. Perhaps integrate into Apt/Rpm or have packages that both can understand somehow. Then we can download "Linux" package without having to worry if we want Apt or Rpm.

Written by andruk the 11 Sep 09 at 02:12.

The reason apt needs root permissions is because the applications it installs are installed system-wide and therefore affect other users. If we allowed users to install programs to their home directory, then they could run their installed applications without affecting other users, and therefore wouldn't need to give apt root access.

This would have advantages with home users because my Applications menu wouldn't get cluttered when my daughter installs Barbietown to her home directory.

This would have advantages with sysadmins because they can run a piece of software from their home directory to test it out before installing it system-wide.

The system paths would have to be modified to look for libraries and executables in the home directory, but applications like Xournal already support this. This would also require the Applications menu to look in the user's home directory for the menus as well.

The reason apt needs root permissions is because the applications it installs are installed system-wide and therefore affect other users. If we allowed users to install programs to their home directory, then they could run their installed applications without affecting other users, and therefore wouldn't need to give apt root access. This would have advantages with home users because my Applications menu wouldn't get cluttered when my daughter installs Barbietown to her home directory. This would have advantages with sysadmins because they can run a piece of software from their home directory to test it out before installing it system-wide. The system paths would have to be modified to look for libraries and executables in the home directory, but applications like Xournal already support this. This would also require the Applications menu to look in the user's home directory for the menus as well.

Written by Lachu the 12 Sep 09 at 17:59.

Like in solution #3:
The main problem is many application have hardcoded path. There's no way to detect/guess path of specified file. Of course, we can recompile package, but it lack functionality for users.

The solution is simple. Create script scheme for setting environment, where specify files are placed. It should set PATH, LD_LIBRATY_PATH, XDG_HOME, CONFIG_PATH, etc. Script will also checking dependency and fixing it if not satisfied(also using install into directory technology).

Create also library, which allows program to read these setting/environment. Program should don't read file from /etc/program_config, but from $CONFIG_PATH/program_config.
If some environment isn't set, library should return default value.

User will have many scheme of installing application - install in: user home directory, system-wide(/), opt(/opt), custom paths.

And of course -- allow to set flag SUPPORT_PATH_SELECTING for package.

Like in solution #3: The main problem is many application have hardcoded path. There's no way to detect/guess path of specified file. Of course, we can recompile package, but it lack functionality for users. The solution is simple. Create script scheme for setting environment, where specify files are placed. It should set PATH, LD_LIBRATY_PATH, XDG_HOME, CONFIG_PATH, etc. Script will also checking dependency and fixing it if not satisfied(also using install into directory technology). Create also library, which allows program to read these setting/environment. Program should don't read file from /etc/program_config, but from $CONFIG_PATH/program_config. If some environment isn't set, library should return default value. User will have many scheme of installing application - install in: user home directory, system-wide(/), opt(/opt), custom paths. And of course -- allow to set flag SUPPORT_PATH_SELECTING for package.

Written by o-bin-lad3n the 15 Sep 09 at 20:05.

This is much like #2, but why start from scratch?
We could push for better support and integration of autopackage with apt, rpm, etc.
Also, I think the need for root-permissions itself is not the real problem, it's the need to blindly trust the file you just downloaded. Of course, there is always a way to mess with a system, when the user executes your software, but this would be way better than "sudo ./somefileijustdownloaded". Autopackage can run with user rights and install into your home directory. And you can still integrate gpg-keys with this solution.

I'm not suggesting this as THE universal package format, but as a common solution for third party/proprietary software and commercial games.

This is much like #2, but why start from scratch? We could push for better support and integration of autopackage with apt, rpm, etc. Also, I think the need for root-permissions itself is not the real problem, it's the need to blindly trust the file you just downloaded. Of course, there is always a way to mess with a system, when the user executes your software, but this would be way better than "sudo ./somefileijustdownloaded". Autopackage can run with user rights and install into your home directory. And you can still integrate gpg-keys with this solution. I'm not suggesting this as THE universal package format, but as a common solution for third party/proprietary software and commercial games.

Written by darkjavi the 21 Sep 09 at 16:47.

And what about giving to apt/aptitude/synaptic the ability to control/install any software on earth not only deb packages.
apt could run the instalation from is inside and chroot the destination of the files generated by the installer into his own folders, so we can manage all the computer software from a single interface

And what about giving to apt/aptitude/synaptic the ability to control/install any software on earth not only deb packages. apt could run the instalation from is inside and chroot the destination of the files generated by the installer into his own folders, so we can manage all the computer software from a single interface

Written by Lachu the 23 Sep 09 at 17:29.

Create sandbox for installers. It will check selinux context and when it isn't designed for installers, it will change it and fork with exec on executable file! It can't sets UID/GID bits or change any existing file, but can access to system directories.

Create sandbox for installers. It will check selinux context and when it isn't designed for installers, it will change it and fork with exec on executable file! It can't sets UID/GID bits or change any existing file, but can access to system directories.

Written by Afroman10496 the 27 Sep 09 at 02:31.

You all know how Wine works, right: importing an opensource clone of the Windows API. Now, imagine that for the Red Hat YUM/RPM compatibility. It's already opensourced, so you won't have to actually clone it. Also, you already have most of what you need because it's all Linux :>. Just offer it as a regular package and when users click on the .rpm just offer a dialog asking if they want to install it or Alien, showing all the pros and cons.

You all know how Wine works, right: importing an opensource clone of the Windows API. Now, imagine that for the Red Hat YUM/RPM compatibility. It's already opensourced, so you won't have to actually clone it. Also, you already have most of what you need because it's all Linux :>. Just offer it as a regular package and when users click on the .rpm just offer a dialog asking if they want to install it or Alien, showing all the pros and cons.

Written by ratdude747 the 27 Sep 09 at 22:01.

that would fix the rpm issue. beginners seem to get "scared" of the command line, and a gui saves time. that way, no matter whether they download an rpm or a deb, they are covered.

making it the default app for rpm would make it so a beginner wouldn't extract it by accident with archive manager. maybe you could then auto-load the resulting .deb.

that would fix the rpm issue. beginners seem to get "scared" of the command line, and a gui saves time. that way, no matter whether they download an rpm or a deb, they are covered. making it the default app for rpm would make it so a beginner wouldn't extract it by accident with archive manager. maybe you could then auto-load the resulting .deb.

Written by warlock24 the 7 Oct 09 at 17:38.

Do not multiply another installer formats, apis, ect. they only do unnecesary complicity of Ubuntu. Promote DEB packages to become unofficial standard for every linux. Develop visual tools for easy and fast creation of deb files (something like debGLADE?).

Do not multiply another installer formats, apis, ect. they only do unnecesary complicity of Ubuntu. Promote DEB packages to become unofficial standard for every linux. Develop visual tools for easy and fast creation of deb files (something like debGLADE?).

Written by Lachu the 28 Oct 09 at 07:42.

Not create new package format/packaging system, but allow to pack many packages into single archive. Structure will looks like this:

root
|
+definition&scripts
| |
| +deb
| +rpm
| .....
|
+files(must have structure like tar.gz - if in specify distribution one file must be moved into other directory, it's task for script)
|
+common definitions (name of author, license, features - installation into directory, etc.)


How distribution should handle it? In simple way. It will only unpack it into /tmp and handle as normal package(ex. run installation script for this distribution). It can also generate .deb or .rpm.

It should helps users, who like to download software from network. It can also helps game creators, because CD's can be used as repository of software.

Not create new package format/packaging system, but allow to pack many packages into single archive. Structure will looks like this: root | +definition&scripts | | | +deb | +rpm | ..... | +files(must have structure like tar.gz - if in specify distribution one file must be moved into other directory, it's task for script) | +common definitions (name of author, license, features - installation into directory, etc.) How distribution should handle it? In simple way. It will only unpack it into /tmp and handle as normal package(ex. run installation script for this distribution). It can also generate .deb or .rpm. It should helps users, who like to download software from network. It can also helps game creators, because CD's can be used as repository of software. Maybe there can occurs some problems with binaries, but most data of program is a resources, like icons, graphics, etc. Resources are shared, so there is a reason to create hybrid format.

Written by ivo000 the 1 Mar 11 at 20:11.

Integrate Autopackage package installer in Ubuntu Software Center

Integrate Autopackage package installer in Ubuntu Software Center

Written by lauterzsolti the 23 May 12 at 08:42.

It would be great to have a new template for Quickly to create application indicators easier as well.

It would be great to have a new template for Quickly to create application indicators easier as well.

Written by amoalsale the 3 May 12 at 04:52.

a simple notification like
"Installing these updates will require reboot"
should be shown in advance.

a simple notification like "Installing these updates will require reboot" should be shown in advance.

Written by benoyanthony the 15 May 12 at 10:09.

Other than complete reboot, system should initiate service restart with confirmation from user.

Other than complete reboot, system should initiate service restart with confirmation from user.