Contributor flounder

Canonical shouldn't have to host a third party application repository when users already can (and do) add entries for third party application sources to /etc/apt/sources.list on the local machine.

Simply provide a mouse driven interface for adding /etc/apt/sources.list entries. This can pretty much use existing infrastructure with the addition of a mime description and a couple of quick shell scripts. Then Add/Remove programs allows the end user to use applications from selected third party vendors. (for example: the latest version of XEN, Wine, PostgreSQL, MPlayer, OpenOffice, games, etc.) which might not be tracked by Canonical via the backports repository)

This beats the heck out of using dpkg -i and having to manually resolving dependencies, and allows trusted vendors to provide automatic updates. (The digital pgp signing and dpkg maintain state stuff already exists for security).

When it's this easy to do let's make Ubuntu easy to use!

1. There are deeply invasive performance/scalability/latency fixes for CFS regressions (vs. 2.6.24) in the 2.6.25 tree. These fixes are too invasive to be ported to the 2.6.24 kernel without significant risk.

2. Many of the driver updates/new drivers in the kernel-ubuntu package are merged into upstream as of 2.6.25. (This is always true, but the smaller the delta against upstream the better on release day).

3. Fedora 9 is based on 2.6.25 which means that key RH kernel developers are aggressively working to get the feature and performance/scalability regressions vs. 2.6.18 & 22 fixed.

4. The kgdb patch will probably be merged at the start of the 2.6.26 cycle which means the delta vs. 2.6.25 kernel should be pretty manageable. This would be really valuable from an LTS ongoing perspective.

5. The RT patch will be better maintained (and smaller) against 2.6.25. (see #3)

6. Better virtualization and SELinux support (see #3).

Given the life-cycle of an LTS release (especially this one which will finally have a meaningful chance to enter the data center) these considerations are especially important.

Obviously 2.6.25 would have to be in addition to 2.6.24 for the Hardy 8.04 LTS release time-frame, but it does allow the aforementioned benefits to be propagated forward.

Most people aren't even aware of the existence of libsensors-applet-plugin, lm-sensors, hddtemp, libsensors4, smartmontools, etc. People who run Linux tend to be more likely than the average to be interested in the health of their hardware. Therefore these things should be available by default.

(Clarification regarding Hardware Sensor Monitor applet: *available* != *included+configured* in the default desktop)

Suggestion to interested readers:
((hit enter for prompts except for adding "yes" in install modules by default))
$ sudo apt-get install libsensors-applet-plugin0
$ sudo sensors-detect

Then right click on your gnome panel an select "Add to panel"->"Hardware Sensors Monitor" & "CPU Frequency scaling monitor".

My primary complaint is that this sensors monitoring applet is not even available unless you install the aforementioned packages.

Some programs which operate on encrypted partitions create files in /tmp which can expose private data (even if the permissions are secure and the files are deleted afterward).

Furthermore, most applications ignore the $TMP shell variable which would otherwise provide a work around for this exposure.

One easy to provide option would be to allow users - with enough RAM and swapping disabled - to create a common ram based /tmp partition. This also avoids the performance penalty and pass phrase inconvenience of an encrypted /tmp.

(A further enhancement would be to offer an easy to configure chroot environment on a per-user basis which simply mounted a ram based or encrypted /tmp while otherwise providing full access to the system.)

--- related security ideas include: ---
http://brainstorm.ubuntu.com/idea/7436/
http://brainstorm.ubuntu.com/idea/7365/

Caching of file information presents a security hole, performance hole, and a power sink for most users.

1. It is trivial to access meta information regarding the contents of encrypted partitions by simply gaining access to the caches stored by tracker, updatedb, and nautilus. Nautilus can be made smarter by simply using a directory local cache, and asking the user when permissions aren't available if home directory context caching is acceptable. Tracker and locate/updatedb should be disabled unless the user actually selects to enable them through some sort of administrative/package/add/remove type interface. When these things _are_ enabled it should be optional to use a ram based file system cache for this cached data which can not be swapped.

2. All three of these things are awful for performance when you don't need them (and most users don't with the exception of constrained nautilus caching). Furthermore, these components can access networked (samba/nfs/andrewfs/iscsi)/high latency (optical/usb)/limited lifetime (flash) devices. There is nothing that kills the throughput or interactivity of an interactive OS than this kind of random block device access.

3. These components should never be automatically run when the system is running from a battery (UPS or laptop). They all kill the battery life of every power hungry component (CPU/hard drive/chipset/...).

Nautilus file introspection is the worst possible performance sink, and should have some sort of check box in the GUI to be enabled/disabled (per directory?).


--- related security ideas include: ---
http://brainstorm.ubuntu.com/idea/7434/
http://brainstorm.ubuntu.com/idea/7436/

Deleting a file only removes the directory entry, but not the actual file.

This behavior is best for performance (and should remain the default). However, many programs create/delete *temporary* files which contain private data and can't be wipe'd by normal user space solutions.

The fastest and most reliable solution is to patch the kernel ext3fs driver to automatically wipe each deleted file (if this behavior is selected by the user via /proc).

This wipe/delete functionality could be seeded with a source/value (any eight bit value or /dev/urandom for example) combined with a number of passes. In addition to the obvious performance benefits vs. userspace solutions, having a journaling file system makes this important to implement at the kernel FS level. User space solutions (including glibc hacks) can't catch all of the temporary files.

--- related security ideas include: ---
http://brainstorm.ubuntu.com/idea/7434/
http://brainstorm.ubuntu.com/idea/7365/

Problem:

New applications and new versions of applications are released but not available in the Hardy-LTS repository.


The Solution:

Create a Web+Add/Remove click based mechanism for adding additional APT sources for the local machine.


How to implement the solution:

Provide a click only interface to permit the adding of vendor provides apt sources using mime and extension types.

For example: http://randomcompany.com/downloads/sources.list.ubuntu-apt-repo

Where firefox or nautilus will invoke: gnome-app-install --local-apt-repo sources.list.ubuntu-apt-repo

Then the user simply has click to select which specific application/game provided by that company (s)he wants to install via the standard Ubuntu Add/Remove application interface.

*This has the advantages of not requiring _any_ maintenance by Ubuntu, but automatically allows access to updates to the users applications.*

As far as I am aware there are no other OSes with this level of functionality. Not only does this solve the "Difficult to install applications" disadvantage vs. other consumer OSes by getting rid of the monolithic repository problem, it would put Linux ahead of the game thanks to the automatic maintenance mechanism provided to application vendors.

[....]