1. Unity Tweak Tool:
Unity Tweak Tool is the best example of customisation options on Ubuntu as it offers a set of system tweaks for both Ubuntu and Unity desktop. It's packed with full of switches and control and you can configure Unity as however you wish. You can change the GTK theme and icon set without much hassle, adjust launcher size, add or remove workspaces and more. Unity Tweak Tool is available for free at the Software Center.
2. Disk Utility:
This is an awesome utility application which allows easy management of any disk drive in the computer. Users can format, partition and erase hard drives easily and also clone, copy and backup from one disk to another one. It's very helpful for a Ubuntu novice who is not very aware of the formatting and partition requirements in the operating system.
3. Proprietary Drivers:
You must install proprietary drivers which allow hardware to function in a better way than open source drivers, which come with Ubuntu. It depends on your system's hardware, if the drivers can be installed or not. The most common types of hardware which have these drivers available are AMD and NVIDIA graphics cards and Broadcom wireless chipsets. The drivers can be found at Software & Updates utility.
4. Graphical Firewall Config Utility:
Install graphical firewall configuration utility to enable and configure a firewall for your Ubuntu system. Linux is usually immune to viruses but hackers can gain remote access to the systems if there is no firewall which protects network ports. Run the command: sudo apt-get install gufw and configure firewall.
5. WinFF: GUI for FFMPEG:
It provides graphical user interface or GUI for FFmpeg. It also helps convert a video file to any format and WinFF can convert multiple files in multiple formats at one time. There are also a variety of preset conversion settings for common formats and devices in this package.
6. Unity Privacy Indicator:
Privacy is a big issue and Privacy Indicator is a useful tool to help you stay informed about which files, folders and services are getting accessed and logged in your Ubuntu desktop. If you click on the 'eye' icon, you can enable the privacy settings on your system.
7. System Load Indicator:
If you want to keep a tab on apps and your hardware status, then it's an easy job on Linux. There is no dearth of mediums through which you can monitor CPU usage, network traffic or GPU temperature. System Load Indicator is available from the Ubuntu Software Center which has a host of configuration options.
8. Disk Space Visualiser:
In this era of hard drives which have huge storage options, we don't worry much about disk space and all. But if there is smaller SSD and multiple partitions are run and a virtual machine is worked upon with a fixed size virtual disk, then freeing up disk space might become a huge requirement. GNOME Disk Space Visualiser, which comes as default in Ubuntu, is very useful for locating hidden logs, cache files and media files.
Friday, 3 April 2015
Principles For Bug Tracking
1. It's A One-On-One System:
Each bug is a link between two people – one who detects the bug and one who solves the bug. No matter how many people are there in the channel of the bug resolution, the two main characters matter the most and play the lead roles. One who reports the bug should stand with his/her ticket and defend the issue. There might be several discouraging issues for the bug reporter but the bug needs to be kept alive anyhow. Responsibility of the bug solver is to defend the solution. If a bug is assigned to someone to resolve it, then it's the bug solver's job to convince the bug reporter that best solution is in place. In order to create the best solution, bug solver should understand the problem first, probe into all the possible options and then propose the best solution. However, the bug solver has to convince the reporter that the bug is resolved.
2. Close Bug As Soon As Possible:
Bug ticketing is not like any chit-chat session. It's all about closing the bug as soon as possible. When a ticket is assigned to someone, the bug resolver's main focus should be how soon it can be closed. Sooner a bug is closed, it's considered better for the project. If a bug is remained unresolved for a long time, then it might become nightmare for the management. Then it also becomes difficult to track them and control them. If any bug/ticket becomes longer than expected, then it should be closed without any delay.
3. Don't Close It Completely:
Every time a bug is raised, project resources are consumed in some other way. Every bug means there is some amount of money which is spent on the project for finding the problem, reporting it and then finally fixing it. If the bug is closed without solving the problem properly then it means the money is completely misused. As every bug consumes project time and budget resources, there should not be any temporary solution. When the bug is started, there is definitely something in mind. If the bug is closed without solving the problem then same problem may arise again and similar bug will be reported too. If there is actually no issue and the bug was irrelevant, the bug resolver should document it in right way in the source code to prevent any confusion in future.
4. Address Comments For Every Bug:
If a bug resolver posts a message to a bug, then it needs to be addressed to someone. Comments are not only about opinion but they are for communication. A bug, as we know, is nothing but conversation between two people. If the bug is resolved, then the comment should be addressed to the ticket reporter. If any solution is wrong, comments are marked for the assignee. Generic opinions are least required in case of bug resolving and comments should be very specific. Your comments can help the project a lot, remember that.
5. Broken Product Should Always Be Reported:
Every bug is reproducible and nobody can beat this fact. Every time a bug is reported, explanation is required how a product is broken. It's mandatory to prove that the software didn't work as expected, or documentation was not done properly and basic requirements were not satisfied. Every bug should be formatted in a particular way. Even if there is a question then the format should be followed. If there is any question it means there is some problem with project documentation and the reason behind why it is broken will also be known. If there is no proper explanation, then it should also be mentioned on the ticket.
Each bug is a link between two people – one who detects the bug and one who solves the bug. No matter how many people are there in the channel of the bug resolution, the two main characters matter the most and play the lead roles. One who reports the bug should stand with his/her ticket and defend the issue. There might be several discouraging issues for the bug reporter but the bug needs to be kept alive anyhow. Responsibility of the bug solver is to defend the solution. If a bug is assigned to someone to resolve it, then it's the bug solver's job to convince the bug reporter that best solution is in place. In order to create the best solution, bug solver should understand the problem first, probe into all the possible options and then propose the best solution. However, the bug solver has to convince the reporter that the bug is resolved.
2. Close Bug As Soon As Possible:
Bug ticketing is not like any chit-chat session. It's all about closing the bug as soon as possible. When a ticket is assigned to someone, the bug resolver's main focus should be how soon it can be closed. Sooner a bug is closed, it's considered better for the project. If a bug is remained unresolved for a long time, then it might become nightmare for the management. Then it also becomes difficult to track them and control them. If any bug/ticket becomes longer than expected, then it should be closed without any delay.
3. Don't Close It Completely:
Every time a bug is raised, project resources are consumed in some other way. Every bug means there is some amount of money which is spent on the project for finding the problem, reporting it and then finally fixing it. If the bug is closed without solving the problem properly then it means the money is completely misused. As every bug consumes project time and budget resources, there should not be any temporary solution. When the bug is started, there is definitely something in mind. If the bug is closed without solving the problem then same problem may arise again and similar bug will be reported too. If there is actually no issue and the bug was irrelevant, the bug resolver should document it in right way in the source code to prevent any confusion in future.
4. Address Comments For Every Bug:
If a bug resolver posts a message to a bug, then it needs to be addressed to someone. Comments are not only about opinion but they are for communication. A bug, as we know, is nothing but conversation between two people. If the bug is resolved, then the comment should be addressed to the ticket reporter. If any solution is wrong, comments are marked for the assignee. Generic opinions are least required in case of bug resolving and comments should be very specific. Your comments can help the project a lot, remember that.
5. Broken Product Should Always Be Reported:
Every bug is reproducible and nobody can beat this fact. Every time a bug is reported, explanation is required how a product is broken. It's mandatory to prove that the software didn't work as expected, or documentation was not done properly and basic requirements were not satisfied. Every bug should be formatted in a particular way. Even if there is a question then the format should be followed. If there is any question it means there is some problem with project documentation and the reason behind why it is broken will also be known. If there is no proper explanation, then it should also be mentioned on the ticket.
Subscribe to:
Posts (Atom)