Tuesday, May 20, 2014

Quixey: App Search & Discovery

https://www.quixey.com/search/android

https://play.google.com/store/apps/details?id=com.quixey.android

There are millions of apps and you need the best app search to find the right ones. Quixey allows you to search for apps by describing what you want to do. You no longer need to know an app’s name to get good results.

The clean interface makes app discovery fun and simple. Quixey’s app search has been featured in TechCrunch, VentureBeat, Mashable, Lifehacker, The Next Web, New York Times and The Wall Street Journal.

Product Highlights:
★ Search - App search that works. You don’t need to know an app’s name to get great results. Search for apps by describing what you want to do and we’ll find apps to help.
★ Trending - Check out the latest and greatest apps. No matter who you are - parent, student, teacher, traveler, athlete, gamer, musician - we have the top trending apps picked for you.
★ Browse - We have reinvented the look of categories. Take our browse wheel for a spin to find the perfect app for you (not available on Gingerbread OS).
★ Sample - Curious what types of apps are out there? Check out our sample queries to see what other people are searching for. 

Tips and tricks: How to use Google like never before

http://www.hackcollege.com/wp-content/uploads/2011/11/google.gif

RemoteBox - Manage VirtualBox on Servers

http://remotebox.knobgoblin.org.uk/

What is RemoteBox?

RemoteBox is a VirtualBox client. In essence, you can remotely administer (ie over the network) an installation of VirtualBox on a server, including its guests and interact with them as if they were running locally. VirtualBox is installed on 'the server' machine and RemoteBox runs on 'the client' machine. RemoteBox provides a complete GTK graphical interface with a look and feel very similar to that of VirtualBox's native GUI. If you're familiar with other virtualization software, such as VMWare ESX, then think of RemoteBox as the "poor man's" VI client.

Why is this useful?

VirtualBox is intended to be used as a desktop virtualization solution. That is, you install it on a machine and use VirtualBox locally. This means that the guests on the local machine will consume resources, taking them away from other tasks. Additionally, the guests will not be available to other machines or will be unavailable if the local machine is off. RemoteBox changes this by allowing you to run the guests on another machine (ie the server) but still interfact with them as if they were installed locally. This free's up resources on your local machine, allows you to interact with the same guests from multiple machines (eg a desktop and a laptop) and the guests can continue to run, even when the client machine is off. The guest's can also take advantage of the additonal CPU, memory and storage that a servers tend to have. As VirtualBox and RemoteBox are both cross-platform it allows you to use different operating systems for the client and server. For example, you may prefer to use VirtualBox on a Linux server but wish to interact with the guests from a Mac OS X client machine.

How does it work?

VirtualBox includes a special web service which exposes its API over the network using a protocol called SOAP. RemoteBox also speaks SOAP and communicates with VirtualBox to perform the various tasks such as creating or powering on guests, etc. When guests are 'powered on', they are started up in a mode called headless. This essentially means the guest's display is 'hidden' but is accessible using the Remote Desktop Protocol (RDP). RemoteBox uses an RDP client to show the display of a guest, locally on the client machine and is completely interactive.

What does RemoteBox run on?

The RemoteBox client is known to run on Linux, Solaris, Mac OS X and various modern flavours of BSD. VirtualBox offically runs on Linux, Solaris, Mac OS X and Windows as well as 'unofficially' on FreeBSD. The client and server machines do not need to be running the same operating system. For example, you may have VirtualBox installed on a Windows server but interfact with the guests from a FreeBSD client.

Feature Summary

RemoteBox Window Image
  • Open source VirtualBox client with a graphical (GTK) interface
  • Remote management of VirtualBox and its guests
  • No web server such as Apache or IIS is required to run RemoteBox
  • No compilation is required - written entirely in Perl
  • View and interact with the guest's display via RDP, including sound and clipboard
  • Create and edit guests
  • Configure processor, display, input devices, audio, I/O ports, and shared folders
  • Set the guest BIOS configuration including the BIOS image
  • Set advanced options such as HPET, Page Fusion, Large Pages, CPU Hotplugging, CPU Throttling etc
  • Attach USB devices and set USB device filters
  • Stop, start, pause and save guest states
  • Provision and attach storage including hard disks, CDs/DVDs and floppy disks
  • Configure networking including host only networks with DHCP servers
  • Supports guest snapshots
  • Compatible with VirtualBox running on Linux, Windows, Mac OS X and Solaris
  • RemoteBox runs on Linux, *BSD and Mac OS X
  • And much more...

Adding Static Routes On Various *NIX (Linux,AIX,HP-UX)

Static routes are generally required for  traffic that must not, or should not, go through the default gateway. In this article we will discuss how to add static routes in variox nix.

Scenario : Suppose if you want that all the traffic to network 172.168.102.0/24 should use 172.168.101.1 as gateway. This can be done by adding a static route in the kernel routing table as shown below.

Adding Static Route in Linux from the Command line :


# route add -net 172.168.102.0 netmask 255.255.255.0 gw 172.168.101.1 dev eth0

OR

# ip route add 172.168.102.0/24 via 172.168.101.1 dev eth0

Above Commands will make changes to the routing table temporary and not permanent. Use any of below mention command To check Routing tables in Linux :

# route -n
# netstat -nr

Steps to make the static Route Persistent Across the reboot :


In case of RHEL5.X / CentOS 5.X

Create a file  route file

# vi /etc/sysconfig/network-scripts/route-eth0

172.168.102.0/24 via 172.168.101.1 dev eth0

Save and close the file and  Restart network service

# service network restart

In case of RHEL6.X / CentOS 6.X

# vi /etc/sysconfig/network-scripts/route-eth0

GATEWAY0= 172.168.101.1
NETMASK0=255.255.255.0
ADDRESS0= 172.168.102.0

Save and close the file and  Restart network service

# service network restart


Adding Static Routes in AIX :


Step:1 Go to the SMITTY menu for routes

Step:2 Select Type of route 'net' or 'host' ( if default route then leave set to 'net' )

Step:3 Enter  the destination address.

Step:4 Enter the gateway address ( on the line that “* default GATEWAY Address")

Step:5 If a 'net' or default route , enter the 'Network Mask' , if host  do not set 'Network Mask'

Step:6 Enter the network interface for this route. To select from the list arrow down to the 'Network Interface' line and hit [F4] or [ESC]+ [4]   to display list of available interfaces.

Step:7 Hit [ENTER] TO APPLY . You should recieve a return status of “OK"

Step:8 To exit the smitty , type  [F10] or [0]

Step:9 Verify that your routes have been configured

# netstat -nr | grep UG

Adding Static Route in HP-UX


Step:1 Make a backup copy of '/etc/rc.config.d/netconf'

Step:2 Add a stanza  to /etc/rc.config.d/netconf for the new route . Make sure you use a new array number for the stanza

Example : Replace 'nn' with the next number in the list.

ROUTE_DESTINATION[nn]="IP-of-NewHost"
ROUTE_MASK[nn]=" “
ROUTE_GATEWAY[nn]="IP-of-Router"
ROUTE_COUNT[nn]=""
ROUTE_ARGS[nn]=""

Save  & Close the file

Step:3 Now run the below command to re-read the netconf file and add the route

# /sbin/init.d/net start

Note: Run the above command with start option only because it will add new route without effecting existing network configuration.

Basic Linux Filesystems tutorial : ext2,ext3,ext4,JFS & XFS

The original Linux system used a simple filesystem that mimicked the functionality of the Unix filesystem. In this tutorial we will discuss basic file system used in Linux.

The ext Filesystem

The original filesystem introduced with the Linux operating system is called the extended filesystem (or just ext for short). It provides a basic Unix- like filesystem for Linux, using virtual directories to handle physical devices, and storing datain fixed-length blocks on the physical devices.

The ext filesystem uses a system called inodes to track information about the files stored in the virtual directory. The inode system creates a separate table on each physical device, called the inode table , to store the file information. Each stored file in the virtual directory has an entry in  the inode table. The extended part of the name comes from the additional data that it tracks on each file, which consists of:

  • The file name
  • The file size
  • The owner of the file
  • The group the file belongs to
  • Access permissions for the file
  • Pointers to each disk block that contains data from the file

Linux references each inode in the inode table using a unique number (called the inode number ), assigned by the filesystem as data files are created. The filesystem uses the inode number to identify the file rather than having to use the full file name and path.

The ext2 Filesystem

The original ext filesystem had quite a few limitations, such as limiting files to only 2GB in size. Not too long after Linux was first introduced, the ext filesystem was upgraded to create the second extended filesystem, called ext2 .
As you can guess, the ext2 filesystem is an expansion of the basic abilities of the ext filesystem, but maintains the same structure. The ext2  filesystem expands the inode table format to track additional information about each file on the system.

The ext2 inode table adds the created, modified, and last accessed time values for files to help system administrators track file access on the  system. The ext2 filesystem also increases the maximum file size allowed to 2TB (then in later versions of ext2, that was increased to 32TB) to help  accommodate large files commonly found in database servers.
In addition to expanding the inode table, the ext2 filesystem also changed the way in which files are stored in the data blocks. A common  problem with the ext filesystem was that as a file is written to the physical device, the blocks used to store the data tend to be scattered throughout the device (called fragmentation ). Fragmentation of data blocks can reduce the performance of the filesystem, as it takes longer to search the storage device to access all of the blocks for a specific file.

The ext2 filesystem helps reduce fragmentation by allocating disk blocks in groups when you save a file. By grouping the data blocks for a file, the filesystem doesn't have to search all over the physical device for the data blocks to read the file. The ext2 filesystem was the default filesystem used in Linux distributions for many years, but it, too, had its limitations. The inode table, while a  nice feature that allows the filesystem to track additional information about files, can cause problems that can be fatal to the system. Each time the filesystem stores or updates a file, it has to modify the inode table with the new information. The problem is that this isn't always a fluid action.

If something should happen to the computer system between the file being stored and the inode table being updated, the two would become out  of sync. The ext2 filesystem is notorious for easily becoming corrupted due to system crashes and power outages. Even if the file data is stored just  fine on the physical device, if the inode table entry wasn't completed, the ext2 filesystem wouldn't even know that the file existed!  It wasn't long before developers were exploring a different avenue of Linux filesystems. 

Journaling Filesystems

Journaling filesystems provide a new level of safety to the Linux system. Instead of writing data directly to the storage device and then updating the  inode table, journaling filesystems write file changes into a temporary file (called the journal ) first. After data is successfully written to the storage device and the inode table, the journal entry is deleted.

If the system should crash or suffer a power outage before the data can be written to the storage device, the journaling filesystem just reads through the journal file and processes any uncommitted data left over.

There are three different methods of journaling commonly used in Linux, each with different levels of protection. These are shown in  below Table.

Journaling Filesystem Methods

MethodDescription
Data modeBoth inode and file data are journaled. Low risk of losing data, but poor performance.
Ordered modeOnly inode data written to the journal, but not removed until file data is successfully written. Good compromise between performance and safety.
Writeback modeOnly inode data written to the journal, no control over when the file data is written. Higher risk of losing data, but still better than not using journaling.

Limitation:

The data mode journaling method is by far the safest for protecting data, but it is also the slowest. All of the data written to a storage device must  be written twice, once to the journal, then again to the actual storage device. This can cause poor performance, especially for systems that do a lot  of data writing.  Over the years, a few different journaling filesystems have appeared in Linux. The following sections describe the popular Linux journaling  filesystems available.

The Extended Linux Journaling Filesystems

The same group that developed the ext and ext2 filesystems as part of the Linux project also created journaling versions of the filesystems. These journaling filesystems are compatible with the ext2 filesystem, and it's easy to convert back and forth between them. There are currently two  separate journaling filesystems based on the ext2 filesystem.

 

The ext3 Filesystem

The ext3 filesystem was added to the Linux kernel in 2001, and up until recently was the default filesystem used by just about all Linux distributions. It uses the same inode table structure as the ext2 filesystem, but adds a journal file to each storage device to journal the data written to the storage device.
By default, the ext3 filesystem uses the ordered mode method of journaling, only writing the inode information to the journal file, but not removing it until the data blocks have been successfully written to the storage device. You can change the journaling method used in the ext3 filesystem to either data or writeback modes with a simple command line option when creating the filesystem.

While the ext3 filesystem added basic journaling to the Linux filesystem, there were still a few things it lacked. For example, the ext3 filesystem doesn't provide any recovery from accidental deletion of files, there's no built-in data compressionavailable (although there is a patch that can be  installed separately that provides this feature), and the ext3 filesystem doesn't support encrypting files. For those reasons developers in the Linux project choose to continue work on improving the ext3 filesystem.

The ext4 Filesystem

The result of expanding the ext3 filesystem was (as you probably guessed) the ext4 filesystem. The ext4 filesystem was officially supported in the  Linux kernel in 2008, and is now the default filesystem used in most popular Linux distributions, such as Fedora and Ubuntu.

In addition to support compression and encryption, the ext4 filesystem also supports a feature called extents .Extents allocate space on a storage device in blocks, and only store the starting block location in the inode table. This helps save space in the inode table by not having to list all of the data blocks used to store data from the file.

The ext4 filesystem also incorporates block preallocation . If you want to reserve space on a storage device for a file that you know will grow in size, with the ext4 filesystem it's possible to allocate all of the expected blocks for the file, not just the blocks that physically exist. The ext4 filesystem fills in the reserved data blocks with zeroes, and knows not to allocate them for any other file.

The Reiser Filesystem

In 2001, Hans Reiser created the first journaling filesystem for Linux, called ReiserFS . The ReiserFS filesystem only supports writeback journaling mode, writing only the inode table data to the journal file. Because it writes only the inode table data to the journal, the ReiserFS filesystem is one of the fastest journaling filesystems in Linux.

Two interesting features incorporated into the ReiserFS filesystem are that you can resize an existing filesystem while it's still active, and that it uses a technique called tailpacking , which stuffs data from one file into empty space in a data block from another file. The active filesystem resizing feature is great if you have to expand an already created filesystem to accommodate more data.

The Journaled Filesystem(JFS)

Possibly one of the oldest journaling filesystems around, the Journaled File System (JFS) was developed by IBM in 1990 for its AIX flavor of Unix. However, it wasn't until its second version that it was ported to the Linux environment.

Note  :The official IBM name of the second version of the JFS filesystem is JFS2, but most Linux systems refer to it as just JFS.

The JFS filesystem uses the ordered journaling method, storing only the inode table data in the journal, but not removing it until the actual file data is written to the storage device. This method is a compromise between the speed of the ReiserFS and the integrity of the data mode journaling method.

The JFS filesystem uses extent-based file allocation, allocating a group of blocks for each file written to the storage device. This method provides for less fragmentation on the storage device. Outside of the IBM Linux offerings, the JFS filesystem isn't popularly used, but you may run into it in your Linux journey.

The XFS Filesystem

The XFS journaling filesystem is yet another filesystem originally created for a commercial Unix system that made its way into the Linux world. Silicon Graphics Incorporated (SGI) originally created XFS in 1994 for its commercial IRIX Unix system. It was released to the Linux environment for common use in 2002.

The XFS filesystem uses the writeback mode of journaling, which provides high performance but does introduce an amount of risk because the actual data isn't stored in the journal file. The XFS filesystem also allows online resizing of the filesystem, similar to the ReiserFS filesystem, except XFS filesystems can only be expanded and not shrunk.

Boot All The 5 Classic Ubuntu 14.04 Flavors From A Single Image, Via Ubuntu AIO

Hello Linux Geeksters. As you may know, Ubuntu AIO (all-in-one) DVD is an unofficial Ubuntu image that enables the users to use Ubuntu 14.04 in all its traditional flavors: Unity, GNOME, KDE, XFCE and LXDE, all from a single image.
In order to use Ubuntu AIO, you can either download the Ubuntu AIO Image and place it on an USB, or get all the five ISO images of the components (Ubuntu 14.04, Ubuntu GNOME 14.04, Kubuntu 14.04, Xubuntu 14.04 and Lubuntu 14.04) + the Ubuntu AIO component.
The users choose the Ubuntu flavor from the GRUB, but however, this does not work flawless. While Ubuntu, Kubuntu and Ubuntu GNOME are available only as 64 bit systems, while Xubuntu and Lubuntu are 32 bit systems.
http://i.imgur.com/FFr0Va8.jpg
Another drawback is the fact that Ubuntu AIO’s size is about 4.7 GB, so you will need an 8 GB USB stick to install it, from the Live Image.
As a reminder, Ubuntu 14.04 has been released on the 17th of April and is considered to be Canonical’s best release so far. Also, due to the fact that Ubuntu 13.04 and Ubuntu 12.10 have already reached EOL, while Ubuntu 13.10 has only a few months of support left, many users have migrated to Ubuntu 14.04.
Lubuntu is probably the lightest official flavor of Ubuntu and it’s based on LXDE. It’s been around for quite some time, and it is recommended for older systems.