Written by Breakable the 17 Apr 08 at 10:08.

Ubuntu Brainstorm was updated in January 2009. Since the idea #7159 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 #7159 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 andruk the 16 Feb 09 at 23:14.

Instead of replacing things that already work well (enough), simply work to improve the existing solutions.

Specifically rollbacks:
* Config files (should be handled better with versioning filesystems like zfs, btrfs when they come out)
* Replacing the current config file with the default config file
* Rolling back package upgrades
* Rolling back dist-upgrades.

I would like to see the enhancements in Nix implemented elsewhere, as I think it could help end users solve their own problems (more often).

Instead of replacing things that already work well (enough), simply work to improve the existing solutions. Specifically rollbacks: * Config files (should be handled better with versioning filesystems like zfs, btrfs when they come out) * Replacing the current config file with the default config file * Rolling back package upgrades * Rolling back dist-upgrades. I would like to see the enhancements in Nix implemented elsewhere, as I think it could help end users solve their own problems (more often).

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 Tellur the 25 Oct 09 at 16:16.

The easiest solution is to consistently use the standardized prefixes following the IEC convention, where SI-prefixes get used for powers of 10 and the additional "i" between prefix and the unit-symbol B for binary powers (e.x.: MiB, GiB,...).
Make the standard display style switch-able would be a huge plus.

The easiest solution is to consistently use the standardized prefixes following the IEC convention, where SI-prefixes get used for powers of 10 and the additional "i" between prefix and the unit-symbol B for binary powers (e.x.: MiB, GiB,...). Make the standard display style switch-able would be a huge plus.

Written by andruk the 29 Oct 09 at 15:37.

Consistently use KB, MB, GB, TB, etc. because that's how computers work.

Consistently use KB, MB, GB, TB, etc. because that's how computers work.

Written by hobo14 the 29 Mar 09 at 09:57.

Ubuntu should always immediately flush the buffer to the external disc, so it can be just ripped out without being unmounted manually.

Ubuntu should always immediately flush the buffer to the external disc, so it can be just ripped out without being unmounted manually.

Written by acidicX the 29 Mar 09 at 19:43.

Since a "always flush buffer immediately" function will decrease performance, you should be able to select the drives where you want it on. This selection should be stored (crypted, so no one can say which drives you are using)

I would love to have that option on my thumbdrive, I just typically upload small files (ppt, etc.) on it and remove it very quickly.

But I want to keep the performance of my external drive as high as possible - so I would therefore disable it on this drive.

Since a "always flush buffer immediately" function will decrease performance, you should be able to select the drives where you want it on. This selection should be stored (crypted, so no one can say which drives you are using) I would love to have that option on my thumbdrive, I just typically upload small files (ppt, etc.) on it and remove it very quickly. But I want to keep the performance of my external drive as high as possible - so I would therefore disable it on this drive.

Written by andruk the 30 Mar 09 at 03:59.

This is collected from Akerbos's comment below.

"You could choose not to flush immediately but after a time of inactivity. That would keep performance up while you work and enable you to unplug your drive shortly after you are finished. The length of the timeout interval could be configurabel [sic] and the states ('safe to remove' vs 'busy') could be visualised [sic] by drive icons or in the tray."

I think this would be the correct way to do Solution #2 - have different timeout intervals for different drives. This may be against the Gnome philosophy of "keeping it simply stupid" (sorry, that was a low blow), but I'm not so much interested in philosophy as I am in helping create an operating system that can be used easily, used well, and used often by the masses.

This is collected from Akerbos's comment below. "You could choose not to flush immediately but after a time of inactivity. That would keep performance up while you work and enable you to unplug your drive shortly after you are finished. The length of the timeout interval could be configurabel [sic] and the states ('safe to remove' vs 'busy') could be visualised [sic] by drive icons or in the tray." I think this would be the correct way to do Solution #2 - have different timeout intervals for different drives. This may be against the Gnome philosophy of "keeping it simply stupid" (sorry, that was a low blow), but I'm not so much interested in philosophy as I am in helping create an operating system that can be used easily, used well, and used often by the masses.

Written by Lachu the 30 Mar 09 at 14:49.

As in topic. It can works?

As in topic. It can works?

Written by hobo14 the 1 Apr 09 at 00:43.

I think there's already a mechanism for doing this, it just doesn't happen automatically.
Manually put an entry in /etc/fstab for the removable device according to it's label or id, and use the "sync" option
(and that also means you can't use "default" because that includes "async").
Problem solved - I just wish it was automatic.

I think there's already a mechanism for doing this, it just doesn't happen automatically. Manually put an entry in /etc/fstab for the removable device according to it's label or id, and use the "sync" option (and that also means you can't use "default" because that includes "async"). Problem solved - I just wish it was automatic.

Written by afrodeity the 19 May 09 at 21:53.

Icons are a visual reference which assists the user in remembering what the source represents. A solution which has already been implemented for individual software in Add/Remove and Ubuntu Tweak could be applied to the sources themselves.

Icons are a visual reference which assists the user in remembering what the source represents. A solution which has already been implemented for individual software in Add/Remove and Ubuntu Tweak could be applied to the sources themselves.

Written by afrodeity the 19 May 09 at 21:56.

A utility which would decode your Software Source list and provide meaning and better management by cross-referencing with a central database. Users might upload or share their source files as part of a broader community initiative.

A utility which would decode your Software Source list and provide meaning and better management by cross-referencing with a central database. Users might upload or share their source files as part of a broader community initiative.

Written by andruk the 20 May 09 at 12:22.

It should be possible to restrict the packages for each repo/PPA. A usage case: I install mobloquer by adding it's repository to my list. I only want to get mobloquer (and it dependencies) from that repo/PPA, I want to ignore the updated KDE present in that repo/PPA (I get that from the universe).

The tricky part is figuring out where to get the dependencies. Perhaps for packages installed from the mobloquer repo/PPA (to continue the above example), the same repo/PPA will be searched for the dependencies to mobloquer?

Finally, the specific software the user wants from a repo shoul be shown to the user on the "Third-Party Software" tab of the "Software Sources" window in a separate column.

It should be possible to restrict the packages for each repo/PPA. A usage case: I install mobloquer by adding it's repository to my list. I only want to get mobloquer (and it dependencies) from that repo/PPA, I want to ignore the updated KDE present in that repo/PPA (I get that from the universe). The tricky part is figuring out where to get the dependencies. Perhaps for packages installed from the mobloquer repo/PPA (to continue the above example), the same repo/PPA will be searched for the dependencies to mobloquer? Finally, the specific software the user wants from a repo shoul be shown to the user on the "Third-Party Software" tab of the "Software Sources" window in a separate column.

Written by ncdlek the 8 Jun 09 at 10:04.

Add populer Repositories section which ubuntu communuty uses and recommends. And Show them in a list so new users can add new respositories only one click. (like installing an aplication)

Add populer Repositories section which ubuntu communuty uses and recommends. And Show them in a list so new users can add new respositories only one click. (like installing an aplication)

Written by map84 the 7 Mar 09 at 11:05.

by clicking "empty trash" the shred command should overwrite the files stored in the trash-folder and deletes it afterwards.

by clicking "empty trash" the shred command should overwrite the files stored in the trash-folder and deletes it afterwards.

Written by wouter215 the 7 Mar 09 at 17:28.

use the gutmann method for this, this makes it impossible to "undelete" anything. the gutmann method overwhrits the file(s) 35 times with random data, making it more secure.
(this should be optional as deleting an eg. 4.5 GB .iso file takes a long time to overwhrite 35 times:)
like: right click>
secure delete
-------------------
normal/default delete
-------------------
recover file to:
-------------------
etc.

use the gutmann method for this, this makes it impossible to "undelete" anything. the gutmann method overwhrits the file(s) 35 times with random data, making it more secure. (this should be optional as deleting an eg. 4.5 GB .iso file takes a long time to overwhrite 35 times:) like: right click> secure delete ------------------- normal/default delete ------------------- recover file to: ------------------- etc.

Written by andruk the 8 Mar 09 at 00:49.

If they aren't there already, include Nautilus plugins to do this. That way people who want this can have it, but normal users won't get confused by the intricate differences between "Move to Trash", "Delete from Trash", and "Shred".

If they aren't there already, include Nautilus plugins to do this. That way people who want this can have it, but normal users won't get confused by the intricate differences between "Move to Trash", "Delete from Trash", and "Shred".

Written by andrew.p the 16 Mar 09 at 21:48.

An option to undelete securely could be an advantage of the OS. There should be even a one-time explanation that deleted file can be restored and Ubuntu is the one OS that gives an option to erase file unrestorably. And there of course should be a warning saying that the operation can take a lot of time. I think we should have an option to do this with a single file instead of secure trash emptying because of amount of time the operation takes.
Encrypted partition or ext2 partition are not the solutions because a man can need such function once a year, for example, for one file. And what if he already wants to erase a file but don't have such partition?

An option to undelete securely could be an advantage of the OS. There should be even a one-time explanation that deleted file can be restored and Ubuntu is the one OS that gives an option to erase file unrestorably. And there of course should be a warning saying that the operation can take a lot of time. I think we should have an option to do this with a single file instead of secure trash emptying because of amount of time the operation takes. Encrypted partition or ext2 partition are not the solutions because a man can need such function once a year, for example, for one file. And what if he already wants to erase a file but don't have such partition?

Written by mmxgn the 18 Feb 09 at 15:59.

Use the technology behind Tracker to keep track of the changes in the permissions of the files and keep backups and be able to restore them by using a gui for such reasons.

Use the technology behind Tracker to keep track of the changes in the permissions of the files and keep backups and be able to restore them by using a gui for such reasons.

Written by andruk the 19 Feb 09 at 04:32.

TimeVault is a backup applications similar to Time Machine on the Mac. Simply include this functionality in TimeVault, as the functions coincide. Linux has a good reputation for being stable and secure, but this will greatly help its ability to be user-friendly and safe with the user's data.

These are other TimeVault-related ideas:
Include TimeVault by default: http://brainstorm.ubuntu.com/item/7185/
Improve TimeVault interface: http://brainstorm.ubuntu.com/idea/3282/
Non-invasive System Restore: http://brainstorm.ubuntu.com/idea/1230/

TimeVault is a backup applications similar to Time Machine on the Mac. Simply include this functionality in TimeVault, as the functions coincide. Linux has a good reputation for being stable and secure, but this will greatly help its ability to be user-friendly and safe with the user's data. These are other TimeVault-related ideas: Include TimeVault by default: http://brainstorm.ubuntu.com/item/7185/ Improve TimeVault interface: http://brainstorm.ubuntu.com/idea/3282/ Non-invasive System Restore: http://brainstorm.ubuntu.com/idea/1230/