Contributor Auzy

(First note that i'm not talking about implementing the GoboLinux File System Structure, not at all, so this is not a duplicated)

GoboHide module let us hide any folder we want from the view (even in the terminal) and have access to them anyway, Gobo use it for hiding the FHS directories, but one could use it to hide any folder.
If one want to see the folders that have been hidden, then just:
~$ gobohide -l
Use Cases:
Alex have installed Gobo Rootlees on his user, so he see his home folder full of dirs he can't rename to put a dot on them...
~$ ls ~/
Desktop Downloads Pictures System Wallpapers
Documents Files Music Programs Videos

~$ gobohide -h ~/System
~$ gobohide -h ~/Files
~$ gobohide -h ~/Programs

~$ ls ~/
Desktop Downloads Pictures Wallpapers
Documents Music Videos

~$ gobohide -l
Hidden directories:
~/System
~/Files
~/Programs

Now Alex has the posibility to hide those dirs he like, but don't need to see.


[....]

It has become obvious that Grub2 needs some extra programming help, as Grub-legacy will no longer be adding new features and the end of Grub2 is nowhere in sight. Canonical should allocate 1 or 2 programmers for a few months to help complete grub2 quickly, so that X86 support might be complete in time for Interpid Ipex.

One could argue that the boot loader is the most important part of the operating system, because if it doesn't work properly (which it hasn't been for some of us), it can prevent every OS from working on the computer. We should treat it with respect, and help them. Despite grubs importance, programmers generally enjoy working on more exciting projects like Gnome or KDE, which is one reason why development is slow.

Grub2 fixes a lot of previous brainstorm ideas including many booting issues (like mine), so completion would close a lot of bugs, whilst also making Ubuntu more user friendly because Grub2 deals with booting issues better.

Voting for this ensures that Canonical allocates some developers to the Grub2 project, which would be a big win for both Ubuntu and linux in general!

Planned Features for Grub 2
* Rescue mode saves unbootable cases. Stage 1.5 was eliminated.
* Dynamic loading of modules in order to extend itself at the run time rather than at the build time.
* Graphical interface.
* Fix design mistakes in GRUB Legacy, which could not be solved for backward-compatibility, such as the way of numbering partitions.
* Scripting support, such as conditionals, loops, variables and functions.
* Cross-platform installation which allows for installing GRUB from a different architecture.
* Internationalization. This includes support for non-ASCII character code, message catalogs like gettext, fonts, graphics console, and so on.
* Portability for various architectures.
* Modular, hierarchical, object-oriented framework for file systems, files, devices, drives, terminals, commands, partition tables and OS loaders.

[....]

this GUI will help the user to run the right application depended on what hardware the user plugged in or open up

this GUI will NOT be depended on if the application is installed or not installed.

for example:
if i plug or open up my scanner, Ubuntu will pop up a window and recommend to my to install and to run specific scanner tool.
but,if i plug or open up my scanner, and the scanner tool is already installed, Ubuntu will only ask my to run the tool.

the same with: mobile phone, PDA...

why is it good:
- i don't need scanner tool if i don't have scanner
- i don't need PDA tool if i don't have PDA
...
- easy way to use hardware
- those application will have a better from support
- better translations
- new level for hardware support

In OS X if you delete an applications preferences and then run that application, it will automatically create default preferences for you. Too many applications depend on their configuration files already existing for them to work properly and I think it would really smart if the application checks if its configuration files are set correctly, and if they aren't, to offer to reset them. But if the configuration files aren't even their, then it can automatically create them for you without you having to even indicate it to do that. I really think this would be a smart approach to handling problems on a system where the configuration files are either missing or are incorrectly configured.

Samba is a good example of this. If you delete that smb.conf file, then it can't do anything. If it did this, that would be so awesome.

Certain apps that can't have a default configuration, would instead ask the user by going through a wizard of what they should be.

An example is the iptables app, if it noticed it had no preferences, then it would notify the user to go through a wizard to create default preferences again giving the choice of which default configuration they would want to use. One could be wide open, another could be locked down, and a third would be to import preferences from a file. Either way it would prevent an app from running without preferences being there.

For debugging an app without preferences, there could be a universal option such as --nopref and attempt to load the app when there was no preferences. Since obviously developers would know of this option to call and not end users.

It should not be required by the end user to have to manually edit or create any preferences that an application needs if that application can by default recreate default preferences, or if there is more then one default preference to start out with, give the user the choice of which one they would want to start out with.

These 3 steps should be taken:


[....]