Install Ubuntu on an External Drive

You can, in fact, install, boot, and run Ubuntu completely from a FireWire, USB, or other external drive, but it does require some special steps. This hack walks you through the process from start to finish.
In the process of working on this book, we realized one disadvantage to using a laptop as a primary computer: it is much more difficult to swap out hard drives for test systems. We wanted to set up an Ubuntu system so that we could test various hacks on a vanilla install, but we didn't necessarily want to repartition and install on the main laptop hard drive if we didn't have to. The solution was to install and run Ubuntu from an external USB drive we had; that way, the regular system stayed intact but we could boot Ubuntu whenever we wanted.

Unfortunately, this sort of install does not automatically work without some tweaking due to a few different reasons:
• By default, the initrd (initial ram disk) file that Ubuntu uses does not contain all of the drivers you need to boot from a removable drive. Your BIOS will find the drive fine (provided it supports booting from removable drives), but once the kernel loads, Linux won't be able to see or mount the drive to continue the boot process.
• Even if the initrd has the appropriate drivers, it takes a few seconds for the kernel to load these modules and detect your removable drive before it tries to use it. During this time, the system will likely try to boot and will not be able to find the removable drive because it hasn't finished configuring.
• The Ubuntu installer is very handy in that it tries to detect other OSes you might have installed on the system and will provide GRUB menu entries for each OS. Unfortunately, this means that it will set up any OS you have on the internal hard drive as being on the first BIOS drive, with the removable drive being second (or third or fourth if you have other drives on the system). When the BIOS boots from the removable drive, it will configure it as the first drive on the system, which will confuse GRUB.
In this hack, we discuss how to fix each of these problems so that you can install and boot Ubuntu from a removable drive.
Set Up the Partitions
The first step is to start the Ubuntu install process as you would with any other system, so read through until you get to the section about partitioning a drive. When Ubuntu gets to the disk-partitioning tool, note that by default it will probably pick any internal IDE or SCSI drive currently in the system. If your system uses an IDE drive, you can choose your external drive by selecting the SCSI drive the system has detected. The line will probably refer to a disk called "SCSI (0,0,0) (sda)." If you already have a SCSI hard drive in the system, it will be a bit more difficult to locate the USB drive, but chances are it will be the last SCSI drive on the system.
Be absolutely sure you pick the correct drive in this phase, because Ubuntu will format and repartition the drive you choose and wipe out any data that might have been there. If you are uncertain which drive is the appropriate one, boot from the Ubuntu Live CD and confirm which device names (sda, sdb, etc.) it assigns the different drives on your system.
Install GRUB
Once you choose the correct drive to format, continue with the Ubuntu installation process until it gets to the GRUB bootloader stage. Here, you will be asked whether you want to load GRUB to the MBR of the internal hard drive. You don't want to do this because it will overwrite any bootloader you are currently using on the system. Instead, say no and then specify /dev/sda (or whatever Linux device was assigned to your removable drive) in the next screen that appears in order to install GRUB directly on the removable drive.
Use chroot
Next, complete the Ubuntu installation up until when it prompts you to select Continue to reboot the system. Before you reboot, you will need to make some tweaks to the system. The Ubuntu installer actually provides a basic console you can use to run a few limited commands on the system. Hit Alt-F2 to switch to this console, and then hit Enter to activate it.
Now you need to prepare the removable disk so that you can chroot into it and change some files. The removable drive will actually be mounted under the /target directory, and the first step is to mount the special /proc filesystem within that drive:
# mount -t proc /target/proc


Now you can use the chroot tool to turn the /target directory into the effective / partition on the system. This way, you can run commands as though you had booted off of that drive:
# chroot /target



Tweak initrd
Once inside the chroot environment, the first thing to do is to add the modules Linux uses to make your removable drive accessible to the initrd. The /etc/mkinitramfs/modules file lets you configure extra modules to add to an initrd, so use your preferred console text editor to edit this file. If you don't have a preferred console text editor, just use vim (if you are unfamiliar with vim, check out "Edit Configuration Files" (on next blog) for a vim primer:
# vim /etc/mkinitramfs/modules


Once this file is opened, move to the very bottom of the file and add the following lines and then save and close the file:
ehci-hcd
usb-storage
scsi_mod
sd_mod
If your removable drive is connected via IEEE1394, also add the following lines:
ieee1394ohci1394sbp2

and for any other devices, simply add the modules they need to this file.
With the correct modules configured, the next step is to set up a initrd so that it will wait a number of seconds before continuing to boot. That way, Linux has time to detect and configure the removable drive. Open /etc/mkinitramfs/initramfs.conf in a text editor:
# vim /etc/mkinitramfs/initramfs.conf


Now add a new configuration option to the very top of the file so that Linux will wait for a few seconds before finishing the boot process:
WAIT=10

In our experience, 10 seconds is enough time for Linux to load a USB drive, but feel free to change this to a longer or shorter value if you need to. Save your changes and close the file.
Now you are ready to re-create an initrd file that incorporates the new settings using the mkinitramfs tool:
# mkinitramfs -o /boot/initrd.img-

2.6.15-16-386

/lib/modules/

2.6.15-16-386



Change the initrd.img and /lib/modules paths to match the kernel version included in your Ubuntu install CD.
Update GRUB
The final step is to change a few settings in the GRUB configuration file. The Ubuntu installer sets up the external device as (hd1) (or second BIOS drive), but you need to change that to (hd0) because the drive will be the first BIOS drive in the system when the BIOS boots from it. Open the GRUB menu.lst file with a text editor:
# vim /boot/grub/menu.lst


and find the lines that refer to the GRUB root device. They will look something like the following:
## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd1,0)

Change the last line to refer to hd0 instead:
## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0,0)


Next, find the section in the file that refers to different Ubuntu kernels. It should look something like the following:
title Ubuntu, kernel 2.6.15-16-386
root (hd1,0)
kernel /boot/vmlinuz-2.6.15-16-386 root=/dev/sda1 ro quiet splash
initrd /boot/initrd.img-2.6.15-16-386
boot

title Ubuntu, kernel 2.6.15-16-386 (recovery mode)
root (hd1,0)
kernel /boot/vmlinuz-2.6.15-16-386 root=/dev/sda1 ro single
initrd /boot/initrd.img-2.6.15-16-386
boot

title Ubuntu, memtest86+
root (hd1,0)
kernel /boot/memtest86+.bin
boot

Now change all of the references to hd1 to hd0:
title Ubuntu, kernel 2.6.15-16-386
root (hd0,0)
kernel /boot/vmlinuz-2.6.15-16-386 root=/dev/sda1 ro quiet splash
initrd /boot/initrd.img-2.6.15-16-386
boot

title Ubuntu, kernel 2.6.15-16-386 (recovery mode)
root (hd0,0)
kernel /boot/vmlinuz-2.6.15-16-386 root=/dev/sda1 ro single
initrd /boot/initrd.img-2.6.15-16-386
boot

title Ubuntu, memtest86+
root (hd0,0)
kernel /boot/memtest86+.bin
boot

If Ubuntu has detected and configured other OSes and you want to be able to choose them as well, simply repeat the same changes to the root config option for each OSonly change hd0 to hd1. Then save your changes and close the file.
Now you can leave the chroot environment, so type exit in the console and then hit Alt-F1 to return to the main Ubuntu install console. Now you can select Continue to reboot the machine into your new install.
Keep in mind that most computers won't boot from a removable drive by default if a CD-ROM or other hard drive is present. Some BIOSes let you configure which device to boot from via a special key at boot time (such as F12). In other BIOSes, you may have to hit Esc, F2, or Del to enter the BIOS and configure the boot device order.

Continue Reading...

XmlLite Reader Programming Overview

XmlLite is implemented as a DLL. There is a header file and a library that comes with XmlLite, but they are there for compiling and linking purposes only; all of the functionality is implemented in the DLL. To use XmlLite, you call methods as appropriate to parse the XML and access the nodes.
Pull vs. Push Parsers
Both XmlLite and SAX2 are non-caching, forward-only parsers. For this type of parser, there are two varieties of programming models:

• Pull programming model. In a pull model, after your application initiates parsing, it calls methods repeatedly to retrieve, or pull, the next node. After retrieving a node, your application can look at the node, including its name, value, attributes, and more. As appropriate, the parser advances so that the next time the application retrieves a node, it gets the next one. XmlLite follows a pull programming model.

• Push programming model. In a push model, your application registers event handlers to receive nodes and information from the parser. After initiating parsing, the parser calls these event handlers, sending (or pushing) nodes to them. The MSXML SAX2 parser follows this programming model.

There are several advantages to the pull programming model:
• It is significantly easier to program for the pull model. Your application takes the form of a loop, where you get the next node, process it, and repeat, until the entire file is processed, or until your application determines that no more processing is required.

• In contrast, the push model requires your application to keep a significant amount of state. Keeping state means that your application needs to keep variables that contain the context of the current node. The combination of implementing a number of event handlers and keeping state means that much more housekeeping is necessary to implement an application.

• If your application is more suitable for a push parser, it is possible to wrap some classes around a pull parser and implement a push programming model. However, the reverse is not true.

Both the push and pull type parsers are significantly different in semantic behavior and performance from the Document Object Model (DOM) programming interface.
You Must Use a Class that Implements IStream
Both the XmlLite reader and writer use a stream object for reading and writing the XML. Therefore, you must either use or implement a class that extends the IStream interface.
After you have created a reader by calling CreateXmlReader , you attach the IStream object to the reader by calling the SetInput method. After you have created a writer by calling CreateXmlWriter, you attach the IStream object by calling the SetOutput method.

If you implement your own class, and if you want to read or write XML directly from another type of stream, you can change the implementation of your IStream class as appropriate. If you want to use a simple in-memory IStream implementation, you can use the function CreateStreamOnHGlobal. If you want to use an IStream implementation that reads from and to a text file, you can use SHCreateStreamOnFile.
For details about programming with the XmlLite reader, see Reading an XML Document Using XmlLite.

For convenience, you can get a default implementation of a simple IStream class from the default IStream implementation. This implementation is the same as that used in many of the XmlLite samples.

XmlLite Is Not an ActiveX Control

XmlLite is not an ActiveX control. It is simply a DLL. As such, it cannot be used from scripting languages, such as JScript or Visual Basic Scripting Edition (VBScript). Like any DLL, XmlLite can be used from C#; however, C# applications would more typically use the XML parsers in System.XML. XmlLite is primarily meant to be used with C++.
XmlLite Is Not Thread Safe
XmlLite is not thread-safe. If you are writing a multi-threaded application, it is up to you to make sure that you use XmlLite in a thread-safe manner. For example, if one of your threads has called the method to retrieve the next node, and that method has not returned, you must programmatically prevent another thread from attempting to retrieve a node.
XmlLite Does Not Provide Access to Typed Content
Unlike the managed System.Xml.XmlReader, the IXmlReader does not provide APIs to access typed content. You can declare that an element is of a certain type, but you cannot retrieve that element as that specified data type. All values are returned as strings, and it is up to the application to convert to types other than string.
Support for Namespaces
XmlLite implements namespaces in compliance with the W3C Namespaces in XML specification. That specification can be found at http://www.w3.org/TR/REC-xml-names.
Capacity
Due to implementation and security constraints, the IXmlReader imposes bounds on some of the XML constructs. For example, consider the following:
text
• All names are limited to 4GB in size. In the example above, nameOfElement and attrName have this limit.
• Attribute values are limited to 2GB in size. In the example above, attrValue has this limit.
• Text values are limited to 4GB in size without chunking, and are unlimited with chunking. To read values with chunking, you use the ReadValueChunk method. For an example of chunking, see Reading an XML Document Using Chunking.
• The number of attributes on an element is limited to 64K.
If any of these limits are exceeded, then XmlLite returns an error.
Special Handling of Nodes
The DOCTYPE node is handled in a special way. When you read a DOCTYPE node, the NodeType is XmlNodeType_DocumentType. The PUBLIC and/or SYSTEM literals are presented as attributes with the names "PUBLIC" and "SYSTEM", respectively. The internal subset can be accessed by using GetValue, and the subset will be returned as a string.
The Xml declaration is also handled in a special way. When you read it, the NodeType is XmlNodeType_XmlDeclaration. The node has no value and has "xml" as the local name. It has no namespace and has up to three attributes: version, standalone, and encoding.
White Space Normalization
All white space in XmlLite is normalized as per the XML 1.0 specification. For more information, see Section 2.10 of the Extensible Markup Language (XML) 1.0 Specification at http://www.w3.org/TR/1998/REC-xml-19980210#sec-white-space.

Error Handling
There are three classes of errors in XmlLite:
• Argument errors. These errors are recoverable and further processing can continue. An example of an argument error is passing an incorrect or illegal value for an argument.
• Parsing errors. These errors are not recoverable, but the same instance of the reader can be used by resetting the input source.
• All other errors. All other errors are not recoverable, and the instance of the reader can no longer be reused.
Because some errors are not recoverable and may lead to unexpected behavior in further processing, it is crucial that the application user inspect the error code (HRESULT) returned by each method call before proceeding.
For more information about error codes, see XmlLite Error Codes.
Encoding Detection
There are three places that an encoding can be specified while in the process of parsing an encoded Xml document:
• The encoding can be specified in the document via a Byte Order Mark (BOM). The BOM may appear at the beginning of an XML entity. The BOM is used both to indicate the byte order of the input stream and as a specification of the input encoding.
• The encoding can be specified in the document in the Xml declaration.
• The encoding can be specified programmatically when creating the input stream. This specification can either be mandatory, or as a hint.
If the user of XmlLite specifies a mandatory encoding programmatically, XmlLite ignores the encoding specified in the Xml declaration. The encoding specified in the Xml declaration (or as overridden programmatically) is the desired encoding.
If there is a BOM, and it conflicts with the desired encoding, parsing will fail.
If there is no BOM, and if the encoding hint was specified as TRUE, then XmlLite will try to parse with the desired encoding. If that fails, XmlLite will attempt to automatically detect the encoding of the specified document.
If there is no BOM, and if the encoding hint was specified as FALSE, then XmlLite will try to parse with the desired encoding. If there is no match between the desired encoding and the encoding of the document, XmlLite parsing will fail. In this case, XmlLite will not attempt to automatically detect the encoding of the document.
If automatic detection of the encoding of the document fails, then XmlLite reports an error on line 0.
If there is no BOM, and there is no desired encoding, XmlLite will attempt to automatically detect the encoding of the document.
The following encodings are supported natively:
• UTF-8, UTF-16, and UTF-16BE
• UCS-2 and UCS-4
• ASCII
• SO88591, ISO88592, ISO88593, ISO88594, ISO88595, ISO88596, ISO88597, ISO88598, and ISO88599
• Windows1250, Windows1251, Windows1252, Windows1253, Windows1254, Windows 1255, Windows1256, Windows1257, and Windows1258
For additional encoding support, you can co-create an instance of IMultiLanguage2* and set XmlReaderProperty_MultiLanguage. By default, the value of this property is NULL.
DTD Support
Document Type Definition (DTD) support is limited to entity expansion and default attributes.
When a DTD is used, DTD default attributes are returned just as if they were normal attributes; the only difference is that default attributes return TRUE when the IsDefault method is called.
For example with a DTD:

If the myAttr attribute on the myElement element is not defined in the XML stream, it will be given the default value of 123.
Semantics of String Handling
The following IXmlReader methods return a string pointer: GetLocalName, GetNamespaceUri, GetPrefix, GetQualifiedName, and GetValue.
When calling these methods, be aware that the pointer is only valid until you move the reader to another node. When you move the reader to another node, XmlLite may reuse the memory referenced by the pointer. Therefore, you should not use the pointer after calling one of the following methods: Read, MoveToNextAttribute, MoveToFirstAttribute, MoveToAttributeByName and MoveToElement. Although they do not move the reader, the following two methods will also make the pointer invalid: SetInput and IUnknown::Release. If you want to preserve the value that was returned in the string, you should make a deep copy.

Continue Reading...

J2ME Programmer Vacancy

URGENTLY REQUIRED
J2ME PROGRAMMER (SENIOR/JUNIOR)
QUALIFICATION :

1. Understanding of J2ME (MIDP 2.0, CLDC 1.1)
2. Excellent in Java programming, object-oriented analysis, and design
3. Understanding of Java UI development (SWING, AWT)
4. Familiar with mobile development in several platforms (Symbian, J2ME, Flash Lite, Windows Mobile, etc)
5. Experience in software development processes and life cycle of software products
6. Ability to write clear technical design and specification documents
7. Excellent in the design and administration of databases, especially MySql
8. Well familiar with the open source project e.g. Jakarta project, Eclipse, MySql, PHP,Tomcat etc
9. Good understanding of wireless technologies and enthusiastic to learn new things

Please send your application letter with detailed resume / CV, stating details of qualifications and summary of experiences, present / expected salary, and other documents support, current photograph

source jobsdb.com or
id.jobsdb.com

Continue Reading...