text:
|Publication number
|Publication type
|Application number
|Publication date
|Apr 24, 2007
|Filing date
|Sep 30, 2003
|Priority date
|Sep 30, 2002
|Fee status
|Also published as
|Publication number
|Andrew J. Ogle
|Original Assignee
|Insignia Solutions Plc
|Export Citation
|BiBTeX, EndNote, RefMan
|Patent Citations (11), Referenced by (34), Classifications (24), Legal Events (5)
|External Links: USPTO, USPTO Assignment, Espacenet
This application claims priority from U.S. provisional applications Ser. Nos. 60/415,156, 60/415,157, and 60/415,158, all filed Sep. 30, 2002, the disclosures of which are each incorporated herein by reference.
The present invention relates generally to the field of computer systems, and more specifically to systems and methods for updating a data image stored in a non-volatile memory device, such as a flash memory. In particular, but not exclusively, the present invention pertains to generating and applying an update package to convert an original first binary image into a new second binary image where the update package is an efficient set of instructions based on the differences between the two images.
Recent years have seen the rapid advancement and proliferation of electronic devices, which devices often require the updating of the resident firmware, operating code, applications or other software loaded thereon, collectively, "binary images", or simply "images". Moreover, installing and updating of such binary images is becoming more routine where advancements applicable to a particular device far outpace the rate at which it is desirable to retire the unit and replace it with an entirely new unit.
Moreover, for many devices for which updating the binary image is desirable, these same devices may be remotely located and it is not practical for many reasons to return or collect the device in order that it can be directly connected to a host updating machine or system.
Additionally, with limited memory on the device itself, whether it be a mobile phone, PDA, pager or any other variety of small form factor portable device, delivery of an entire new image is often infeasible due to the capacity limitations of the device. Also, even if the device is not memory or other resource constrained, and thus not limiting the size or application process for installing an update, delivery of a complete new image may still be infeasible because the connection used by the device may be intermittent and/or of a limited capacity.
Also, in applying an update to install a new image, it is not uncommon for power loss or other interruptions to the subject device to occur which leads to failure of the installation. This may result in the installation process having to begin again from the start, or worse, leaving a device disabled or wholly inoperable due to a partial install from which it cannot recover or reinitiate.
Accordingly there is a need for an efficient, effective and reliable system and method for providing an update to a device that does not require the unit to be returned to a service center for update and instead uses an update package that can modify the binary image in-situ, and is significantly smaller than the full image. And, there exists need for a complimentary mechanism or technique to allow for recovery and continued application of an update to such device, even when being updated remotely and without access to a host update or boot rescue system.
A known manner in reducing the size of a new image update is to use a differencing algorithm or binary differencing engine (BDE) which compares the current or existing binary image with the new binary image to produce a list of differences. Such differences, in a general sense, are typically output or expressed as sequences or sets of ADD and COPY operations such that the new image can be created by cobbling together binary strings copied from image sequences resident on the device in the original image and interlacing them with binary sequences from the new image for which a suitable copy string was not available in the old image. The ADD operation specifies a list of bytes that must be copied into the new image at the current location, and the COPY operation specifies a number of bytes to be copied from a given location in the original image to the current update location in the new image.
The efficiency of the high-level BDE can have significant effect on how much of the update can be expressed as COPY operations and how much using ADD operations; in general terms, the more of the new image that can be expressed as COPY operations the smaller the resultant update package will be. Quite naturally, at one extreme, a single add operation comprising the entire new image is too large and does nothing to reduce the size of the update package. Similarly, any new image can be made entirely from copy operations if the copy sequences are short enough, say, ultimately, copying sequences of single bits; however, at that extreme the required number of total operations is prohibitively high and, again, does not benefit the reducing the size of the update package. Moreover, even given an efficient BDE, a space-efficient encoding of the operations is still required to produce small update packages.
The need therefore is for a system that optimizes the size and number of operations to find the most effective and minimized update package size for any given original image and new image.
The present invention has as an object to update a binary image held in non-volatile memory on a device such as a mobile phone by application of an update package to upgrade the image in-situ, rather than have to supply a complete copy of the new image. With the update package delivered to the device, the image can be updated by the device itself without need of a potentially expensive general recall. Thus it is a further object of the invention to be able to add new functionality or resolve problems found after deployment of a device, such as a mobile phone, without being recalled by a manufacturer for modification at a service centre. The ability for the device to reliably apply the update itself and allowing the update package to be provided via over-the-air (OTA) delivery, thus removing the costs associated with a major recall, is a further object of the invention.
A typical embodiment of this invention would be for updating of the flash memory image in a mobile phone where the update package has been delivered to the phone over-the-air (OTA) and is being applied to the flash memory without the subscriber returning the phone to a service centre for update. In this environment the update must complete reliably even though the battery may discharge during the update, or the subscriber may simply turn-off the phone.
Thus, a further and more specific object of the invention is a substantially reduced size of a update package acceptable for OTA delivery, particularly when it would be impractical for a complete copy of the new image to be delivered due to constraints in the communications network utilized or it would also be infeasible due to memory or other performance constraints on the target device. Accordingly, yet a further object of the invention is a space efficient storage of an update package expressing the difference between an original binary image and an updated version of that image. These small update packages may feasibly be transmitted over low speed communications links (e.g. a GSM network), and stored on devices with limited available memory (e.g. a mobile phone).
Moreover, another object of the inventions is to allow for an update package that can be used to perform an in-situ upgrade of a binary image held in flash memory without use of external re-flashing hardware.
And yet a further object of the invention is to allow for reliable flash memory updates within devices that do not have a guaranteed power supply, e.g. mobile phones, PDAs, etc., and without recourse to external power supplies or dedicated additional re-flashing hardware.
As will be evident through further understanding of the invention, any application using binary differencing techniques to store multiple images by use of an original and update packages (rather than simply the raw images themselves) would potentially benefit from reduced storage requirements. This method of generating update packages could be applied to any device using conventional block-structured non-volatile memory such as flash memory; i.e., those with limited additional memory for storage of new images prior to update would benefit by requiring only the space for the much smaller update package to be held instead.
The present invention will be illustrated below in an exemplary wireless communications system utilizing mobile handsets containing flash memory devices; however, the present invention is applicable to any device using a block-structured or partitioned memory device that may need its memory image updated in a reliable way when working in a standalone configuration, and which is perhaps also possible not to have any guarantee that power to the device will not be interrupted during the update. Although particularly well-suited for use in conjunction with a wireless communications system and for updating handsets used in such a system, the invention is not limited to use with such system or types of mobile devices. Use of the term "mobile handset" is in no way intended to limit the application of the present invention from use with a much broader class of client devices which may be mobile or fixed, and which may be the form of a telephone handset but may also be of any number of other form factors or varieties of devices. As such, the term "client device" as used herein means the broadest description possible of a class of computing devices that can be connected to a network (whether by fixed, wireless, intermittent, removably connected or other connection) and which the updating techniques detailed herein may be applied, which includes, without limitation, mobile handsets, PDAs, pagers, personal computers, printers and other peripheral devices. Additionally, the term "communications network" or "communications system" as used herein is used in it most expansive sense and applies to any communications system through which an update package or other information may be transferred to and from a client device, whether by static, active, dynamic communications protocols or otherwise, and includes, without limitation, anything from a single client device connected by fixed wire to a host server or computer system, or to a LAN, WAN, wireless communication networks, conventional telephony, the Internet, etc. Accordingly, the disclosed updating techniques may be used in any number or type or combination of communications systems and client devices having block-structured non-volatile memory devices in which it is desirable to reduce the size of the update package, reduce the number of update operations or otherwise provide more efficient updating of the binary image stored in the device. As used herein "stored" "saved" "reprogrammed" and similar terms all refer to the same process of storing a binary image in a memory device in accordance with the techniques for storing associated with the particular memory device, whether it be non-volatile flash memory, volatile RAM or otherwise, unless specifically described otherwise.
The update server 110 contains, generally, an update generator 112 and update manager 114. While depicted as a single element, update server 110 may alternatively be comprised of a server array or set of distributed computing devices that fulfill the purposes of update server 110. Update generator 112 creates update packages 124 through the use of a binary differencing engine (BDE) 118 and update encoder 116. Update generator 112 maintains, or receives from an external source, an original data image 120 corresponding to the subject client device 150 and is also supplied with or obtains a copy of the new data image 122 for the subject client device. The BDE 118 receives a copy of the original data image 120 and a copy of the new data image to be applied 122 and, through a process of comparisons, generates lists or sets of COPY and ADD operations which are potential candidate operations usable in generating the update package 124. Update encoder 116 communicates with BDE 118 to combine additional encoding information to select instructions from the BDE and incorporate other operations derived from additional information to ultimately create the update package 124. In the preferred embodiment, the update encoder 116 is highly integrated with the functionality of the BDE 118 so as to enhance optimization and speed of selecting and encoding instructions sets. Update generator 112, consistent with the invention herein disclosed, generates the update package 124, which at the appropriate time or interval is supplied to the client device 150 via the update manager 114 through communications network 140.
Generally, to create the update package 124 and set of update instructions (later shown as element 302 in
Referring back now to
In any event, memory device 210, as stated, is a block-structured memory device for which original image 120 is programmed or saved across a first section of memory 220 comprised of a plurality of k blocks shown in
One important element of remainder section 230 relevant to the invention is that there be at least a portion of the remainder section large enough to store the update package 124. Also, in regards to at least one embodiment of present invention for reliably restarting application of an update after power loss (as discussed later), an additional scratch block 232 of memory device 210 need be available that is at least as large as the largest memory block to be updated.
In addition to a scratch block 232 that may be useful in certain embodiments of the invention, a section of scratch memory 252 must be available in RAM device 250 during the processing and application of the update package, which scratch memory 252 must be (in addition to any other amount of RAM being used to process or run the update decoder application in general) at least the size of the largest flash block to be reprogrammed, since, as is described later, each of the k blocks to be updated is first built in RAM and then stored in its appropriate destination memory block location. It is possible that this scratch memory 252 could, alternately be a single block of flash memory dedicated for this purpose, since one of the benefits of flash memory is the high number of rewrites possible which makes this a real possibility; however, in the preferred embodiment scratch memory 252 is RAM memory. Note for purposes of this disclosure and description of the invention, scratch block 232 and scratch memory 252 are meaningfully distinct, as the former is in non-volatile memory device 210 and the latter is in RAM device 250.
Turning now to
Specifically, referring to
In its most simple form, an appropriate update package 124 can be generated by starting at the beginning of the image and working up the address range as for the usual non-flash-memory case. However, three basic changes are required to allow the update package 124 to be applied to block-structured non-volatile memory device, such as a flash memory. First, as mentioned, an ADD or COPY operation where the destination region spans the next block boundary in the new image 122 must be split into two operations at that boundary point (e.g., at 316). Second, when searching for candidate COPY operations, the BDE must use the new image 122 as the source of copy operations that start before the current block that is being processed (e.g., 310 b of
Thus, as shown in
After confirming the need for an update and the verification step 404, the update package 124 is downloaded to the client device. On the client device 150 is a download agent 152 which manages the receipt of the update package at step 406 which update package is next saved at 408 in a portion of non-volatile memory which is not to be reprogrammed by application of the current update, such as in a remainder section 230 of non-volatile memory device 210 which is distinct from the k blocks 220 which will be updated. The download agent may also conduct additional verification steps with the update server to confirm receipt of the correct and complete update package.
Once the update package 124 is received, saved and confirmed complete, the update agent 156, which is comprised of the update decoder 154, is initiated at 410. According to one embodiment, the client device next at 412 steps through a power cycle to deliver control of the microprocessor and client device during the update application process from the resident device OS to the update decoder. At its subsequent point 414 the cycle begins of applying the substantive content of update package 124 by, at step 416, setting or resetting an update block counter to zero (or some other predetermined value that can be meaningful used in conjunction with the counting mechanism used when encoding the update package and update instruction set).
At state 418 begins with the first block X of the k blocks to be updated according to instruction set 302 and at state 420 builds the Xth block of new image 122 in scratch memory 252. Building the content of the Xth block to be reprogrammed is comprised of ADD and COPY operations as directed by the instruction set 302, though it is possible that any Xth block may constitute only a single ADD operation or single COPY operation. Once the new image content for Xth block is complete in scratch memory, then the destination memory block X 312 (also shown as 330 in
At step 426, after each Xth block has been reprogrammed with its new image content, then an update block counter is incremented and the process proceeds to determine at state 428 whether, according to the update block counter, whether all blocks have been updated. If it is determined that still less than the complete k blocks have been updated, then the update application process returns to step 418, whereupon the update decoder moves to the next Xth block+1. This process of updating continues until at query state 428 it is determined that the new image to be updated across the block-structured non-volatile memory has been applied to all k blocks to be updated, at which point the update process returns to state 414 and proceeds to go through a power cycle at 430 to return control of the client device to the client device OS which may include, at least in part, the new image 122 update applied to the client device.
Finally, in addition to the instruction set of various operations (be they COPY, ADD, SETBLOCK, SETCOPYOFFSET, etc.), the resultant update package 124 is further comprised of additional information. In the preferred embodiment, the update encoder 116 also generates information from a status bit array creation process 528 to include and encode in the update package 124 a status bit array 930 that is used in tracking the status of the update process which can then be used to reliably restart the update process in the event of a power loss or other interruption of the update process.
The encoded update instructions can finally be compressed prior to storage in the update package 124 using a suitable binary compression algorithm (e.g. zlib). An improvement to simple compression here is achieved by storing the new data to be added by the ADD (or COPYADD) instructions separately from the ADD, COPYADD and SETCOPYOFFSET instruction stream. Each of these two areas is independently compressed. This generally gives better overall compression than storing the new data together with the associated ADD instruction. The instruction stream tends to compress relatively poorly, however the new image data can contain highly compressible data which benefits from not being intermixed with the instruction stream itself.
In the case of updating a first original image 120 to that of a new image 122 with additional or revised code, whether comprised of bug fixes and/or additions of new functionality, it is frequently the case that a large number of COPY and ADD operations are generated where typically the ADD operations are adding only 1 or 2 bytes, interspersed by COPY operations where anything from a few tens of bytes to thousands of bytes are being copied from the source image 610 which is of a preexisting sequence in the original image 120. Additionally, over large ranges it is often the case that a large portion of the COPY operations will be found to be copying data from source locations at a constant offset 614 to the current update location 618 in new image 122. Efficiently expressing these common case ADD and COPY operations is critical to reducing the size of the resultant update package 124.
The overall size of a typical ADD operation is predominately determined by the size of the data inserted or the "add" data, whether it be 1 or 2 bytes or 100 bytes, because the ADD operation is a combination of the ADD instruction and the "add" data itself, which is of a fixed and often irreducible size. This is unlike a COPY operation, which can express large portions of "copy" data to be used in a new image in only a few bytes (regardless of the size of the amount to be copied) because the COPY operation is simply an instruction to a copy source destination (ie. start address) with a copy length. Accordingly, inserting just a 10 byte string by an ADD operation requires the ADD instruction (say 2 bits to identify the operation) plus the 10 byte length of code, whereas inserting a 10 byte string by a COPY operation can be as little as only 1 or two bytes (simply to identify the operation, the location of the copy source, and the copy length). Because of the nature of these operations, the efficiency gains of encoding COPY operations can be more significant than that of ADD operations, ie. reducing the size of a COPY instruction by a single byte gives a much greater percentage decrease in the overall operation size than for an ADD operation dealing with the same number of bytes of the image.
Thus, in a system seeking to minimize the size of an update package 124 comprised of an instruction set, at a first order of sophistication a BDE 118 and update encoder 116 search to maximize the amount of the new image 122 to be created from COPY operations and hence minimize ADD operations, and in particular to minimize ADDs of large strings of code. However, the number and length of ADD operations is balanced against generating an unacceptably high number and multitude of COPY operations (and hence total operations altogether) which, despite their relative small size, can accumulate to be unacceptably large in great numbers and undermine the goal of a small instruction set and overall update package size.
Bearing the foregoing in mind, the encoding of an update package 124 can be made more efficient and the selection of particular COPY versus ADD operations generated by a BDE can be favorably affected by adopting an encoding system for ADD and COPY instructions that take advantage of the known and frequent use of offset copying, which shall be discussed presently.
Each successive ADD and COPY operation in an instruction set defines a current location in the new image that is being updated. This current location is the destination of the then current ADD or COPY operation being executed. When completed each operation therefore implicitly increments this location by the amount of data added or copied by that operation, thereby setting the current location for the next operation, e.g., the current location is incremented by the length of copy data 602, from 618 a to 618 b (unless a specific address relocation is called for by the next operation.
Accordingly, COPY operations can be expressed as a length of data to be copied plus an offset into the current update location used to express the source location for the copy. The source location is thus calculated as an index into the new image 122 and is used as an index into the original image 120. Thus, a COPY operation is logically expressed as a length, and an offset: COPY(length, copy-offset). The source location of the data to be copied in the original image is calculated by adding the copy-offset value (which may be positive or negative) to the value of the current update location to give an absolute location in the new image; the numeric value of this location is then used as a location in the original image. Because the copy-offset is frequently the same for many COPY operations it is not specified with each COPY operation, but is maintained by the update decoder 154 in a scratch memory location 256 as a copyoffset data field. Thus, the only parameter actually specified with a COPY operation now is its length, i.e. physically a COPY is expressed simply as: COPY(length). This has the effect of, on a percentage basis, greatly reducing the size of the majority of COPY operations.
Because a COPY operation does not specify its own copyoffset value, a new operation is needed to set the required value of the current copy-offset value held within the update decoder 154, i.e., a SETCOPYOFFSET operation. Since many sequences of COPY operation can have the same offset value, SETCOPYOFFSET operation is not required with each COPY operation. Rather, the value of the copy-offset remains unchanged in the copyoffset data field 256 until the next SETCOPYOFFSET operation is encountered and will be used until the copyoffset data field is changed by another SETCOPYOFFSET operation. The SETCOPYOFFSET operation does not itself cause the new image to be updated in any way; it only sets the value used in the calculation of the source data location for all COPY operations occurring between two SETCOPYOFFSET operations.
Referring specifically now to
Furthermore, when using this copyoffset technique, it is preferable to use a combined COPY/ADD operation, one which encodes a COPY operation followed by an ADD operation in a single operation, rather than having a simple COPY operation. When necessary, a simple COPY operation can be expressed as a COPYADD with a zero length ADD if required.
All the COPYADD, ADD, and SETCOPYOFFSET instructions preferably have several encodings available, the most critical of these being the single byte forms of the COPYADD and ADD operations. For example a COPYADD operation using 1 bit to identify it as COPYADD, 5 bits for the length of the COPY operation, and 2 for the length of the ADD can encode a large number of basic image modifications is a simple stream of single byte instructions (excluding the new data required for the ADD operations). A small ADD instruction is also required, for example, using 2 bits to identify the operation and 6 for the length. Wider forms of both COPYADD and ADD are clearly also required and in practice several such 'widths' must be provided, however the encoding of the smallest forms of the instructions are always the most critical for space efficiency. All widths of the COPYADD instruction need only allow 2 bits for the ADD operation length; longer ADDs being expressed by a following ADD instruction where required (see TABLE 1 below)
1 byte form
2 bits to identify operation (e.g.
bits 7 . . . 6 == 10)
6 bits to encode ADD-length
2 byte form
8 bits to identify operation (e.g.
bits 7 . . . 0 of 1st byte == 11111000)
8 bits to encode ADD-length
3 byte form
8 bits to identify operation (e.g.
bits 7 . . . 0 of 1st byte == 11111001)
16 bits to encode ADD-length
1 byte form
1 bit to identify operation (e.g. bit 7 == 0)
5 bits to encode COPY-length
2 bits to encode ADD length
2 byte form
4 bits to identify operation
(e.g. bits 7 . . . 4 of 1st byte == 1110)
10 bits to encode COPY-length
2 bits to encode ADD-length
3 byte form
5 bits to identity operation
(e.g. bits 7 . . . 3 of 1st byte == 11110)
17 bits to encode COPY-length
2 bits to encode ADD-length
A further efficiency gain in the expression of COPY operations is achieved using a 'mode' indicator maintained by updated decoder 154, where the operation either uses the copy-offset values as above, or switches mode to use a zero offset. This 'mode' indicator, as for the copyoffset value, is kept in the client device's RAM memory area 250. This is frequently useful even in images which have been changed extensively, since commonly much of the image will not have moved, even though such regions may contain numerous minor changes. Additional forms of the SETCOPYOFFSET operation are used to switch into and out of this 'switch-mode'.
As for the COPYADD and ADD operations, various 'widths' of the SETCOPYOFFSET operation must be available. In this case it is beneficial to allow different forms of the operation that either set the copy-offset to a given absolute (signed) value, or modify the copy-offset value by addition of a (signed) delta. Single byte forms of the SETCOPYOFFSET instruction must exist to swap between the copy-offset values and switch into and out of zero-offset mode.
TABLE 2 SETCOPYOFFSET 1 byte 5 bits to identify operation forms (e.g. bits 7 . . . 3 == 11000) 3 bits to encode relative offset 8 bits to identify operation (e.g. bits 7 . . . 0 == 11011111) Switches into & out of switch-mode 2 byte 5 bits to identify operation (e.g. forms bits 7 . . . 3 of 1st byte == 11001) 11 bits to encode relative offset 5 bits to identify operation (e.g. bits 7 . . . 3 of 1st byte == 11010) 11 bits to encode absolute offset 3 byte 6 bits to identify operation (e.g. form bits 7 . . . 2 of 1st byte == 110110) 18 bits to encode absolute offset 4 byte & etc . . . larger forms
Three different forms of the SETCOPYOFFSET operation are given above; there are many different possible variations on the above examples, however these operations support the required minimal functionality:
The stream of high-level COPY/ADD operations generated by the BDE is trivially encoded into the required low-level COPYADD, ADD, and SETCOPYOFFSET instructions. The encoder must maintain the two copy-offset values and the zero-mode setting as the encoding progresses, and select the smallest form of each instruction encoding that will express the desired high-level operation. A simple one instruction submit/commit scheme is required to allow high-level COPY/ADD operations to be merged into the low-level COPYADD or COPYADD/ADD instruction sequences.
The overall space efficiency of the encoding is improved if the relative cost of various candidate COPY operations is known to the high-level BDE. This enables an informed choice of operations to be made where multiple possibilities exist at a given point in the image. For example, it may be better to select a COPY which can use the current copy-offset even though it copies fewer bytes than another COPY which must first modify the copy-offset value; this is particularly true where the second COPY requires a large change to the copy-offset value and thus may require significantly more bytes to encode than the first COPY.
Although the above encoding scheme relates mainly to changes in microprocessor instruction streams, it will in general also encode the differences in arbitrary data with a good degree of efficiency. This is useful in that it allows an update package to be prepared and encoded as above for an entire binary image even though some of the data in that image is not in fact microprocessor instructions. This means that the encoding can be applied without any knowledge of the microprocessor concerned or the internal structure of the image with respect to code and data areas. In turn this means that both the encoder and decoder for the update package can be relatively simple and thus in the case of the decoder, can be implemented for devices with relatively slow processors and limited memory availability (e.g. a mobile phone).
In many cases, particularly where new functionality is being added to an image, there is a tendency for large parts of the original image to be moved up the address range of the image as code and/or data is inserted into the image in various places. Depending on the size of this movement the above simple procedure tends to become increasingly inefficient because as each block is updated it destroys some of the source data needed to efficiently express the next block in the new image. For this reason it is often (though not always) beneficial to generate such update packages from the end of the address range downwards as follows.
Within each block the basic procedure remains unaltered; however the BDE starts from the beginning of the last block in the image and works to the end of that block, then steps back to the start of the preceding block and repeats the process until the start of the image is reached. This can be expressed easily by adding a SETBLOCK operation to the basic ADD/COPY pair. The SETBLOCK operation identifies the next block to be updated to the decoder; although not technically required if the direction of processing is known and all blocks are updated, it allows for further optimizations as noted later, for example the ability to remove unchanged blocks from the update package entirely, and also remove trailing COPY operations from a block as demonstrated with specific examples of sample instruction sets relating to
The basic changes to the update package encoding using SETBLOCK operations become:
Except for the requirement to process the SETBLOCK instruction rather than simply move to the next block in sequence, the decoder described for the basic procedure above works unchanged. In fact the SETBLOCK instruction becomes a trivial delimiter for the end of updates related to the current block.
If the BDE can generate update packages using both procedures given above, a simple extension is, for any pair of input images, to generate both update packages and simply discard the larger. Much of the cost in generation time is usually creation of the hashtables—however these are the same in both cases, so caching the tables allows both packages to be generated, and one discarded, in substantially less than double the time taken to generate a single package. If the SETBLOCK instruction is made an intrinsic part of the encoding then the same decoder can be used for either package style without regard to the order in which blocks are updated.
Note that a side effect of the generation mechanism within the BDE is that each flash-block is updated at most once. This is important when considering times required to apply update packages since the time to erase and reprogram a flash-block is typically of the order of 1 second; this erase/reprogram time, once all updated blocks are accounted for, will dominate the time taken to apply a package even when using a slow processor.
One further advantage of use of the SETBLOCK instruction in all encodings is that if any block of the image is updated by a single COPY operation from the same location in the original image then both the COPY and associated SETBLOCK instructions can be removed from the BDE output entirely. This ensures that flash-blocks that are not modified at all will not be pointlessly erased and reprogrammed by the update package. For localized changes this optimisation has a dramatic effect on the time required to apply the update package for the reasons noted above regarding erase/reprogram times of flash blocks.
The use of the SETBLOCK operations in encoding an instruction set will now be address by way of an example set forth in
It should be noted that this trivial example data is designed to show some of the issues discussed; it is not representative of any real data—which might typically comprise images of between 1 and 16 MB (or indeed more) in size. The original and new images in the pair may also differ in size. A typical real flash device might be uniformly divided into 64 KB blocks (though many different possibilities exist).
With reference to
Sample instruction set No. 1
Whether this is the smallest update package possible depends on the binary encoding used to express the operations (e.g. in practice it might well be more efficient to express "COPY 1 @ . . . " as an ADD); however for the purposes of this discussion logical correctness is required so for these examples the update operations in the packages will be shown as follows:
The following Sample Instruction Set No. 2 illustrates the first step in making it feasible to apply the update in an update-in-place, block-structured, manner.
Sample instruction set No. 2 Block 1 COPY 2 @ 22 ADD 1 {00} COPY 2 @ 0 Block 2 ADD 3 {03, 04, 05} COPY 2 @ 5 Block 3 ADD 2 {08, 09} COPY 2 @ 10 COPY 1 @ 14 Block 4 COPY 5 @ 15 Block 5 COPY 3 @ 12 ADD 2 {30, 31}
As Sample Instruction Set No. 2 makes evident the decoder now only deals with a single destination block at a time, and COPY operations where the source data would previously have been overwritten by an earlier part of the update have been replaced by ADD operations. Note that in one instance it is possible to copy data from another part of the image which has itself already been updated. For example, it can be seen that for the third operation (i.e., COPY 2 @ 0) all original content of 'current' block is available for copying while new content is created. Also, the first operation relating to block five (i.e., COPY 3 @ 12) instructs the copying of data from part of image that has already been updated. The basic update here is still sequential from the start of the image to the end (sequential bottom-up); there are no further improvements that can be made to this update package without extending the number of operations that can be expressed within it, i.e., specifically the addition of a SETBLOCK operation as described in the next figure.
Sample Instruction Set No. 3 adds the SETBLOCK operations to explicitly identify which operations relate to which blocks—however all the other operations are exactly as before.
Sample instruction set No. 3 Block 1 SETBLOCK 1 COPY 2 @ 22 ADD 1 {00} COPY 2 @ 0 Block 2 SETBLOCK 2 ADD 3 {03, 04, 05} COPY 2 @ 5 Block 3 SETBLOCK 3 ADD 2 {08, 09} COPY 2 @ 10 COPY 1 @ 14 Block 4 SETBLOCK 4 COPY 5 @ 15 Block 5 SETBLOCK 5 COPY 3 @ 12 ADD 2 {30, 31}
Having added the SETBLOCK operations, it is now clear that block 4 is unchanged by the update and therefore the SETBLOCK and COPY operations that relate to it can simply be removed, thus eliminating the need to reprogram block 4 at all in the instant case. Apart from reducing the package size this also reduces the time required to apply the update on a real flash device since the redundant erase/reprogram cycle will typically take of the order of one second—even though no data has changed. In addition, the final COPY in block 3 is redundant as the decoder can implicitly add such a COPY operation if the explicitly supplied operations account for less than the total length of the block being updated.
Thus, upon inspection, it becomes evident that some operations can be eliminated to gain efficiency without affecting the resulting update. A simplified update package with the redundant and unnecessary operations removed is shown below in Sample Instruction Set No. 4.
Sample instruction set No. 4 Block 1 SETBLOCK 1 COPY 2 @ 22 ADD 1 {00} COPY 2 @ 0 Block 2 SETBLOCK 2 ADD 3 {03, 04, 05} COPY 2 @ 5 Block 3 SETBLOCK 3 ADD 2 {08, 09} COPY 2 @ 10 Block 5 SETBLOCK 5 COPY 3 @ 12 ADD 2 {30, 31}
Specifically, the last operation relating to block 3 (COPY 1 @ 14) can be added implicitly by the update decoder and thus the instruction can be removed. And more obviously, the operations relating to Block 4 can be removed entirely, as the instructions are to copy the same code from and to its current location.
And in a final set of examples, it can be shown how the use of the SETBLOCK operation can generate opportunities for efficiency by allowing updating across blocks in an order other than sequentially up the address range. In this last example shown immediately below as Sample Instruction Set No. 5, the SETBLOCK operation is used to update the blocks in reverse order.
Sample Instruction Set No. 5 Block 5 SETBLOCK 5 COPY 2 @ 10 COPY 1 @ 14 ADD 2 {30, 31} Block 4 SETBLOCK 4 COPY 5 @ 15 Block 3 SETBLOCK 3 COPY 2 @ 7 COPY 3 @ 20 Block 2 SETBLOCK 2 COPY 3 @ 2 COPY 2 @ 5 Block 1 SETBLOCK 1 ADD 3 {23, 24, 00} COPY 2 @ 0
As in Sample Instruction Set No. 4 above, block 4 can be removed from the package. Also evident now, there are only 2 ADD operations, as opposed to the 4 required when updating the blocks in sequential bottom-up order (see Sample Instruction Set No. 4 above). This occurs because a relatively large block of data in the image (the first 12 bytes) has moved up the image (i.e. to a higher offset). This region of the update can now be expressed as simple copies since each block update no longer overwrites source data required for the next block.
However, updating block 1 becomes more expensive since the source data that it made use of in the previous update order has now been destroyed by the time block 1 is updated. Simplified to eliminate unnecessary operations, final Sample Instruction Set No. 6 below shows the minimized operation applicable to the reverse order updating.
Sample instruction set No. 6
Block 5
Block 3
Block 2
Block 1
Now, with the foregoing sample instruction sets in mind relating to sample images 820 and 822, an indication of actual instruction set size and hence update package size can be obtained and compared. Generally assume all COPY and SETBLOCK operations can be encoded in a single byte and that ADD operations require 1 byte for the operation itself and 1 each for each byte being added. In this very simplistic encoding we see that the original instruction set of Sample Instruction Set No. 1 has size 11, whereas sample set No. 2 has size 19. This is the expected increase due to bifurcated operations occurring at block boundaries. It is seen though that among the remaining examples, Sample Instruction Set No. 4 has size 21, and the last, Sample Instruction Set No. 6, has size 18. Thus the update-in-place packages tend to be larger than the non-update-in-place version, but the order in which blocks are updated in is important. In fact, the size of instruction set No. 6 for reverse order updating, including the SETBLOCK operations, is smaller than the forward updating process of sample instruction set No. 2 which does not even have SETBLOCK operation. Thus, the addition of SETBLOCK operation still resulted in a net size reduction in the instruction set. In practice the difference in size between these two differing block update orders is commonly in excess of 50%. Note also that for real image data the overhead of the SETBLOCK operations is completely negligible due to the (typically) 64 KB block size as against the 5 byte block size used here.
Encoding using SETBLOCK operations can be used to update flash blocks in the image in any order without modification to the update decoder. If the update block order was chosen correctly then the package size can be reduced by virtue of minimizing the amount of data overwritten before being able to be used as the source of a COPY operation. Also, importantly, through the use of the SETBLOCK operation, the pool of copy sources is not necessarily fixed, since a different order of updating of memory blocks generates a different set of available block images (both old and new) for use in COPY operations.
A final important point is that although one or other of the two block update orders used in the above examples (sequentially bottom-up, or top-down) commonly gives good results, there are cases where completely different update orders are preferable. In the above cases it is assumed that the BDE simply generates packages using both orders and uses the smaller one, however it isn't feasible to generate packages for every possible update order where there might be a few tens up to a few hundred blocks to update—the processing time required becomes prohibitive. Thus further analysis by the BDE is required to determine if such a non-sequential update order would be the best. However the SETBLOCK operation discussed here allows such non-sequential block update orders to be expressed in the update package and applied by the package decoder with no further modifications.
One further size optimisation can be made to the update package encoding with a minor addition to the decoder on the device. If the last instruction prior to a SETBLOCK is a COPY from the same location in the source image then the COPY instruction can be discarded entirely, provided that the decoder detects blocks where the update instructions do not reach the end of the block, and inserts an appropriate implicit COPY instruction itself.
Making the application of the update package secure against power failure requires a copy of the block X being reprogrammed to be taken and flashed into a pre-allocated scratch block 232 prior to erasing the original block X. One of the benefits of flash ROM over previous forms of non-volatile memories is the high number of rewrites possible that makes this a possibility without appreciable deterioration of the memory device itself. Such power failure recovery also requires additional non-volatile state information, as discussed below. The above decoder procedure can be modified to cope with rebuilding the current block after a power failure immediately following the erase of the original block, by detecting any COPY operation whose source falls in the 'current' block and taking the source data from the scratch block 232. If the copy of original block X is made early enough to the scratch block 232, before the update starts to build the replacement content, the identical algorithm can be used for all blocks independent of whether the content of the actual current block in the image is valid or not (i.e. irrespective of whether a power failure has occurred). This is possible provided that the source of a single COPY operation can never cross into, or out of, the current block. The modifications above for the in-situ update package generation, if taken in full, do guarantee this.
In any event, the process for applying the update package 124 commences at a start state 902 where a client device 150 having a first original image 120 programmed across k blocks of a block structured non-volatile memory device 210 is to have such original image reprogrammed with a new image 122. As will be explained further below, start state 902 may be at a point when an update package 124 is first received and to be installed, or alternatively, when an update package to be applied has been previously received and installation is to re-commence after being interrupted at some point prior to complete installation of the update package. Thus, in either scenario, it is assumed that an update package has already been received and saved to some a location, such as in a data memory block in space 230 of non-volatile memory device 210 on the client device 150 and any authentication or document integrity checking of the update package 124, perhaps analogous to steps 404, 406 and/or 408 has occurred, if it was desirable to do so.
From start state 902, the process initiates by, at step 904, setting or resetting an update block counter 254 to zero or some other predetermined value that can be meaningful used in conjunction with a counting mechanism used when encoding the update package and update instruction set. The upgrade package 124 must contain a count of the number of k memory blocks 220 that will be updated. In the present embodiment, the update package 124 contains an array of status bits 930 that maintains a record of the state of each block to be updated. Each block to be updated, X, has a first status bit 932 and second status bit 934 associated therewith. These bits are generically referenced as X.1 and X.2, respectively. There is a logical mapping that correlates the actual target block to be updated within the non-volatile memory device 210 with each such block listed in the update package 124 as requiring updating, however the specific nature of this mapping function is unimportant to the implementation of the method being described and numerous alternative are available and evident to one skilled in the art.
The first status bit, X.1, 932 for which there is one for each of the k blocks to be updated, correlates to confirming whether the updating process has achieved the intermediary step of erasing the non-volatile scratch block 232 and storing a copy of the current contents of such Xth block therein. The second status bit, X.2, 934 for which there is one for each of the k blocks to be updated, correlates to confirming or denying whether the instant Xth block has been already applied, i.e., the Xth block has been reprogrammed with the new image therfore.
All status bits begin in a first or set state when the update package is first stored on the device and act as switchable status identifiers during the process of updating. By definition these status bits will themselves be present in flash memory (but in a block not in the k blocks to be updated) by virtue of storing the update package after its initial receipt by the client device. Flash memory cells cannot be rewritten with new data without first erasing them, however with the exception that any flash memory cell storing a "1" can be programmed to "0". Accordingly, in the present case each of the block status bits are set to 1 in the upgrade package as initially delivered and stored on the device constituting a first or initial set state for each status bit. Thus, these bits will be updated or switched to a second state when cleared to "0" in-situ during application of the upgrade package.
Certain flash chip architectures may require each status 'bit' to be represented in a more complex fashion. Intel Strata Flash devices for example require use of 2 physical bits per logical bit, where both bits set represents the logical state set, and any other combination signifies the logical state clear. Both physical bits need to be cleared in the same write operation to the bit array. This representation retains the required behavior in terms of update the status bits, its only impact on the method is the increase in the size of the status bit array 930.
Storage of the status bit array 930 in the update package itself has the additional advantage that the code applying the update on the target device is not concerned with allocation or initialization of the array; provided sufficient non-volatile memory is available to store the update package, no further checks or preparation are required. This reduces both the complexity and size of the update agent. Note that even for a relatively large 16 MB flash device divided into uniform 64 KB blocks, the entire status array occupies only 32 bytes and thus its inclusion in the update package imposes no significant size penalty on the package itself.
Continuing, after step 904, query state 906 is reached and the second status bit 934, X.2, for the first of k blocks, is checked. If during the query state 906 it is confirmed that the second status bit is still set (i.e., is still a "1"), then the current block has not been reprogrammed and the update process moves to query state 912. At step 912 the first status bit 932, X.1, is checked. If it is still set (i.e., a "1"), then this indicates that the original contents of block X have not been copied to the scratch block 232. In this situation, the process moves sequentially through steps 914 to 918 where the scratch block 232 is erased, the original contents of block X are copied into the scratch block, and then first status bit 932, X.1, is cleared. A single reserved scratch flash block 232 is required for use during application of the update. For flash devices where the block geometry includes blocks of different sizes this scratch block must be as large as the largest block actually modified by the upgrade. The update method can in fact be implemented provided one or more scratch flash blocks are available that together have a total size as large as, or larger than, the single largest block that is to be updated. The update agent that implements the method must simply be modified to consider the multiple scratch blocks to be a single scratch area for the purposes of the method. Supporting a 'virtual' scratch block split over more than one physical block in this way will slightly increase the complexity of the update agent, but has no impact of the method since it imposes no constraints on the erase and/or write operations in the scratch block. After the first status bit is cleared at step 918, the new image contents of block X are constructed in RAM at 920, block X itself is erased at 922 and reprogrammed with the new content from RAM at 924, and second status bit 934, X.2, is cleared at 926.
This completes the cycle of updating the instant block X, so the process 900 updates the block counter at 908 and queries whether all blocks have been updated according to the block counter at step 910. If all blocks have been updated, the process moves to completion state 928. However, in the event all blocks have not been updated, the process returns to 906 and a normal upgrade proceeds by updating each block in turn. It continues by checking status bits 934 and 932 for each successive X block of the k blocks to be updated (steps 906, 912), and successively copying the original content of each block X to the scratch block, building the target block's new content in RAM, reprogramming the target block from the new content in RAM (steps 914–924), and clearing status bits 932 and 934 at steps 918 and 926, respectively. Clearing of status bits associated with each block can be done without an erase/reprogram cycle given the properties of flash memory devices described above. Update of the status bits in a conventional NOR flash device for example requires reading of the byte that contains the status bit to be cleared, the appropriate bit cleared in the value so read, and the resulting value written back to the same location in the flash device; this update has the required behavior for the method as described. The above block update procedure is repeated, incrementing the update block counter accordingly, until all blocks have been updated, at which point the upgrade is complete.
As may already be evident from inspection of update process 900, it is possible to restart the upgrade procedure following loss of power (or other interruption) during a previous upgrade attempt. The procedure re-starts from the first block as for the normal procedure, but due to one or more status bits having been cleared in the previous update attempt the process has a modified effect as described below.
For example, if at the outset of reaching query step 906 (perhaps in restarting the update process after an interrupt or power loss during a previous update attempt), a cleared second status bit is encountered, the process would move directly to step 908 to increment the update counter 254 and then verify at 910 if all blocks were updated. The process continues to return to step 906 and update counter block 254 at 908 until it is confirmed that all blocks are updated at step 910, or a second status bit is encountered at step 906 that is still set with respect to an Xth block of the k memory blocks to update. In this event, it next proceeds to step 912. If at step 912 it was determined first status bit, X.1, was already clear, this would indicate that the original content of the current Xth block was already saved in the scratch block; in which case the process proceeds to step 920 to construct the new content for block X in RAM, erase block X itself, and reprogram such block with the new content constructed in RAM at 924, and finally update, i.e., clear the second status bit, X.2, for the current block. This cycle would continue until second status bit was encountered at step 906 that was still set, which would send the process over to update the subject Xth block beginning at 912.
|Cited Patent
|Filing date
|Publication date
|Jun 28, 1985
|Mar 31, 1987
|Sequoia Systems, Inc.
|Memory back-up system
|Jun 19, 1992
|May 9, 1995
|Digital Equipment Corporation
|Hybrid lock escalation and de-escalation protocols
|Aug 23, 1993
|Jul 11, 1995
|International Business Machines Corporation
|Digital storage system and method having alternating deferred updating of mirrored storage disks
|Nov 22, 1996
|Nov 3, 1998
|Miller, Call, Plauck And Miller
|Automatic file differencing and updating system
|Jul 31, 1995
|Dec 1, 1998
|Direct logical block addressing flash memory mass storage architecture
|Sep 25, 1996
|Aug 24, 1999
|Allen-Bradley Company, Llc
|Change log historian system for memory shared by multiple workstations
|Mar 30, 1999
|Jul 23, 2002
|Microsoft Corporation
|System and method for upgrading client software
|Aug 17, 1999
|Apr 1, 2003
|Connected Place Ltd.
|Method of and an apparatus for merging a sequence of delta files
|Jan 26, 2000
|Dec 30, 2003
|Fusionone, Inc.
|Data transfer and synchronization system
|Jan 8, 2001
|Aug 10, 2004
|Microsoft Corporation
|Systems and methods for incrementally updating an image in flash memory
|May 13, 2002
|Aug 2, 2005
|Innopath Software, Inc.
|Byte-level file differencing and updating algorithms
|Citing Patent
|Filing date
|Publication date
|Aug 31, 2004
|Feb 17, 2009
|Smith Micro Software, Inc.
|Efficient method and system for reducing update requirements for a compressed binary image
|Feb 10, 2006
|Dec 15, 2009
|Google Inc.
|System and method for dynamically updating a document repository without interrupting concurrent querying
|Aug 20, 2004
|Feb 9, 2010
|Smith Micro Software, Inc.
|Method for reducing binary image update package sizes
|Oct 13, 2006
|May 18, 2010
|International Business Machines Corporation
|System and method of remotely managing and loading artifacts
|Oct 13, 2006
|Jul 20, 2010
|International Business Machines Corporation
|System and method of remotely managing and loading artifacts
|Apr 21, 2005
|Mar 8, 2011
|Hewlett-Packard Develpment Company, L.P.
|Firmware update in electronic devices employing update agent in a flash memory card
|May 27, 2008
|Apr 12, 2011
|Microsoft Corporation
|Dynamic microcode for non-volatile memory
|Sep 8, 2010
|Jul 24, 2012
|Hewlett-Packard Development Company, L.P.
|Systems and methods for data compression
|Nov 14, 2007
|Dec 11, 2012
|Continental Automotive Systems, Inc.
|Systems and methods for updating device software
|Sep 13, 2010
|Apr 2, 2013
|Samsung Electronics Co., Ltd.
|Techniques for resolving read-after-write (RAW) conflicts using backup area
|Dec 12, 2006
|Jun 18, 2013
|Hewlett-Packard Development Company, L.P.
|Initialization and update of software and/or firmware in electronic devices
|Apr 11, 2003
|Jul 2, 2013
|Hewlett-Packard Development Company, L.P.
|Pattern detection preprocessor in an electronic device update generation system
|Dec 6, 2004
|Sep 3, 2013
|Palm, Inc.
|Centralized rules repository for smart phone customer care
|Dec 31, 2004
|Sep 17, 2013
|Intel Corporation
|Manageability extension mechanism for system firmware
|Sep 17, 2004
|Oct 8, 2013
|Palm. Inc.
|Network for updating electronic devices
|Feb 27, 2011
|Nov 5, 2013
|Palm, Inc.
|Updating an electronic device with update agent code
|Nov 1, 2011
|Nov 19, 2013
|At&T Intellectual Property I, L.P.
|Coordinating firmware over-the-air updates for mobile devices utilizing presence information
|Jul 27, 2007
|Jun 10, 2014
|Qualcomm Incorporated
|User experience and dependency management in a mobile device
|Apr 26, 2012
|Nov 18, 2014
|Qualcomm Incorporated
|Device management in a network
|Apr 25, 2014
|Jul 14, 2015
|Qualcomm Incorporated
|User experience and dependency management in a mobile device
|Jan 18, 2005
|Apr 26, 2016
|Qualcomm Incorporated
|Network with broker for device management
|Aug 7, 2012
|Aug 2, 2016
|Microsoft Technology Licensing, Llc
|Initiating update operations
|Aug 31, 2004
|Dec 22, 2005
|Anderson Alison H
|Efficient method and system for reducing update requirements for a compressed binary image
|Aug 20, 2004
|Feb 23, 2006
|Ogle Andrew J
|Method for reducing binary image update package sizes
|Oct 13, 2006
|Apr 17, 2008
|International Business Machines Corporation
|System and method of remotely managing and loading artifacts
|Oct 13, 2006
|Apr 17, 2008
|International Business Machines Corporation
|System and method of remotely managing and loading artifacts
|Dec 31, 2004
|Aug 28, 2008
|Intel Corporation
|Manageability Extension Mechanism for System Firmware
|Nov 14, 2007
|May 14, 2009
|Continental Teves, Inc.
|Systems and Methods for Updating Device Software
|May 27, 2008
|Dec 3, 2009
|Microsoft Corporation
|Dynamic microcode for non-volatile memory
|Sep 8, 2010
|Mar 8, 2012
|Giovanni Motta
|Systems and methods for data compression
|Sep 13, 2010
|Mar 15, 2012
|Samsung Electronics Co. Ltd.
|Techniques for resolving read-after-write (raw) conflicts using backup area
|Nov 1, 2011
|May 2, 2013
|Michael Zubas
|Coordinating Firmware Over-The-Air Updates For Mobile Devices Utilizing Presence Information
|Aug 7, 2012
|Feb 13, 2014
|Microsoft Corporation
|Initiating update operations
|Jul 27, 2016
|Nov 17, 2016
|Microsoft Technology Licensing, Llc
|Initiating Update Operations
|U.S. Classification
|711/162, 711/161, 711/156, 711/100, 717/168, 707/999.204, 707/999.202
|International Classification
|Cooperative Classification
|European Classification
|Feb 28, 2006
Owner name: INSIGNIA SOLUTIONS, PLC, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:OGLE, ANDREW J.;REEL/FRAME:017611/0773
Effective date: 20030930
|Dec 28, 2006
Owner name: SMITH MICRO SOFTWARE, INC., CALIFORNIA
Free format text: SECURITY AGREEMENT;ASSIGNOR:INSIGNIA SOLUTIONS PLC;REEL/FRAME:018689/0872
Effective date: 20061221
Owner name: SMITH MICRO SOFTWARE, INC.,CALIFORNIA
Free format text: SECURITY AGREEMENT;ASSIGNOR:INSIGNIA SOLUTIONS PLC;REEL/FRAME:018689/0872
Effective date: 20061221
|Oct 22, 2010
|Fee payment
Year of fee payment: 4
|Apr 21, 2011
|Surcharge for late payment
|Oct 24, 2014
|Fee payment
Year of fee payment: 8


text:
Zaria V is a Gamma Quadrant planet that is inhabited by the Zarians.
In the year 2370, the Zarians approached the Federation with the intention of establishing Zaria V as a vacation destination for Federation visitors. Benjamin Sisko later sent Kira Nerys there to investigate the possibility, although Kira became involved in the struggle between the Zarian working class and the master class. Taking part in the "Negotiation", Kira won the competition for the working class, which set them on a path to improve their status in Zarian society. (DS9 comic: "Working Vacation")
|This article is a stub relating to a planet, moon or planetoid. You can help our database by expanding on it.
|Gamma Quadrant planets and planetoids
|Alamenta II • Argratha • Bopak III • Brax • Bronis II • Caldonia III • Callinon VII • Dosa II • Eco • Ee • Erabus Prime • Errikang VII • Founders' homeworld • Gaia IV • Hoek IV • Innerol V • Karemma • Keltara • Kendaray • Kigus III • Kurrill Prime • Laertes • Lesurgis XXXII • Merakord II • Meridian • Mundahla • New Bajor • New Founder homeworld • Overne III • Parada IV • Rindamil III • Rintanna • Skrree • T-Rogoran Prime • Tevlin-De • Threska II • Torad V • Torga IV • Vadris III • Vandros IV • Varala • Vanimel • Vhetti Prime • Yadera II • Yadera Prime • Zaria V • unnamed Gamma Quadrant planets and planetoids

subset: commoncrawl


text:
Kwara State College of Education, KWCOE third and fourth admission list for the 2015/2016 academic session is out.
This is to inform all the candidates that participated in the Kwara State College of Education (KWCOE), Ilorin, last post UTME screening exercise but are yet to be admitted that the management of the institution has released the third batch and fourth batch admission list
Kwara State College of Education (KWCOE), Ilorin third and fourth batch admission list contains the names of candidates offered provisional admission into the college various NCE programmes for the 2015/2016 academic session.
Check KWCOE Ilorin 3rd, 4th Admission List.
Go to the college admission status checking portal at http://kwcoeilorin.edu.ng/portal/nce/nce_admission/. Provide your UTME registration number in the required column and then click on view status to check your KWCOE admission status.
MSG Team congratulates candidates that made it to KWCOE third and fourth batch admission list for the 2015/2016 session.


text:
James Rodríguez, Sara Marsh*, Antonio Duke, and Patrick Coyle*
Creative Team:
Megan West*, Mary Shabatura, Lisa Jones, Katie Phillips, Aaron Newman, Alec Lambert, Emily England, Michael James, and Annie Enneking
"...Sam Shepard's purest and most beautiful play." - NY Daily News
The late Sam Shepard's seminal drama about toxic, passionate, star-crossed lovers Eddie and May, a ghostly old man in a rocking chair, and a young gentleman caller. Winner of the Obie Award.
Don't miss this searing, funny, thrilling masterpiece!
"It is as mysterious and unsettling -- now you see it, now you don't -- as spare and, incidentally, as funny as anything [Shepard] has ever done."
- The New Yorker
|James Rodríguez and Sara Marsh. Photo: Melissa Hesse. Hair/MUA: Crist Ballas.
"Fool For Love is certainly one of the best plays of our time." - BackStage
The exciting, intimate company named Best Theater of 2016 by City Pages returns with a unqiue and exciting revival of Sam Shepard's seminal play you won't want to miss.
by City Pages!
"How did tiny upstart Dark & Stormy take the prize? It happened through the dedication of a handful of talented and committed artists who want the very best on stage... Artistic director Sara Marsh has, over the course of a few years, crafted a must-attend company out of a simple desire to put on great shows with great acting."
Dark & Stormy Productions honored by critics in 2015!
by William Mastrosimone
named a Top Ten Production of 2015 by Rohan Preston of the Star Tribune
and Ed Huyck of City Pages!
|From L: James Rodríguez, Emily Bridges, Sara Marsh, & Tracey Maloney in Extremities. Photo by Heidi Bohnenkamp.
- Rohan Preston, Star Tribune
"Dark & Stormy brought audiences into a living room where a young woman fought off her attacker -- and was then forced to decide whether he lived or died. Compelling acting and directing meant we also lived and died with every twist.
- Ed Huyck, City Pages
honored in Lavender Magazine's
Best of 2015 in Theater!
"Best Stage Combat Direction: Annie Enneking, Extremities, Dark & Stormy Productions; Henry IV, Part I, 10,000 Things Theater; The Jungle Book, Children's Theatre Company"
- John Townsend, Lavender Magazine
|Sara Marsh & James Rodríguez in Extremities. Photo by Heidi Bohnenkamp.
"Crème de la crème performances: Sara Marsh, Extremities, Dark & Stormy Productions"
- John Townsend, Lavender Magazine
The Hothouse
by Harold Pinter
named Best Production of 2014-2015 by Sophie Kerman of Minnesota Playlist!
|Clockwise from L: John Catron, Bill McCallum, Mark Benninghofen, Sara Marsh, Robert Dorfman. Not pictured: Bruce Bohne. Photo by Heidi Bohnenkamp.
"This is a "Best of" article, so I realize I need to pick something that was actually the best: I'm giving this one to Dark & Stormy's The Hothouse...Of all of the points that stood out about the shows I mentioned above, The Hothouse had it all for me this year."
Dark & Stormy Productions honored by critics in 2014!
|Clockwise from L: Bill McCallum, John Catron, Mark Benninghofen, Sara Marsh , and Robert Dorfman. Not pictured: Bruce Bohne. Photo by Heidi Bohnenkamp; design by Kevin Cannon.
The Hothouse
by Harold Pinter
Directed by Benjamin McGovern
named a Top Production of 2014 by Ed Huyck of the City Pages!
|Clockwise from L: Bill McCallum, John Catron, Mark Benninghofen, Sara Marsh, Robert Dorfman. Not pictured: Bruce Bohne. Photo by Heidi Bohnenkamp.
"Nothing says Christmas like Harold Pinter and torture, especially when it comes wrapped up with a great cast, direction, and concept that saw the show played out in an echoing atrium."
- Ed Huyck, City Pages
Dark & Stormy Productions honored by critics in 2013!
Speed-the-Plow named a Top Ten Production of 2013 by the Star Tribune:
"Director Ben McGovern teamed with actors Sara Marsh, Bill McCallum and Kris L. Nelson to make David Mamet's 'Speed-the-Plow' a savagely arresting treat in a found space."
- Rohan Preston
The Receptionist named a Top Ten Production of 2013 by City Pages:
"Sally Wingert led a talented four-actor cast through Adam Bock's dark-as-midnight workplace comedy. The experience was intensified by the found location — a recently vacated downtown office space — that seemed to be haunted by the true nature of the Northeast Office's work."
- Ed Huyck
|Harry Waters Jr. in The Receptionist. Photo by Melissa Hesse.
"New theater company Dark & Stormy Productions is really hitting their stride; they've become one of those theater companies I rely on to never let me down. Their fourth production in just under two years continues their tradition of short, intense, real, small-cast, smartly written plays in unusual locations."
- Jill Schafer, Cherry and Spoon
From Star Tribune theater critic Rohan Preston's feature on Dark & Stormy Productions:
"[Speed-the-Plow], which starred Guthrie regulars Kris Nelson and Bill McCallum alongside company founder Sara Marsh, gave a gripping, spittle-laced experience. The drama...was more evidence that small theaters are a big part of what makes the performing arts scene special."
- Rohan Preston, Star Tribune
Read the full article on the Twin Cities' small theaters here!
"Dark & Stormy is a newish company that's come screaming out of the gate with a series of terrifically cast shows, professionally produced and expertly marketed...I've seen three out of four shows...[and] I hope Dark & Stormy continues their level of professionalism and rock-star casting."
- Dominic Orlando, Minnesota Playlist


text:
Home sales and sale prices in Rogers Ranch slipped a bit during the month of March.
This community in North Central San Antonio has seen a decrease of 28.6 percent in the number of homes sold during the 2015 when compared to last year.
During the year, the average sales price saw a 8 percent decrease while the median sales price was unchanged.
Currently there are 36 homes for sale in Rogers Ranch.
The prices range from $335,000 for a 4 bedroom, 2700 sqft home all the way to $785,000 for a 4 bedroom, 5100 sqft home.
Rogers Ranch March Home Sales
Rogers Ranch seen 5 homes that sold during the month of March.
The homes that sold ranged from 4 bedroom, 2800 sqft homes all the way to 5 bedroom homes of over 3800 sqft.
Rogers Ranch March Home Sale Prices
Home sale prices during the month of March in Rogers Ranch, ranged from a low of $330,000 to a top price of over $478,000.
For the month, the average sale price was $408,749 and the median sales price of $392,995.
For the year, the average sale price is $403,103, a decrease of 7.7 percent from 2014, and the median sales price of $412,800, relatively unchanged from 2014.
Rogers Ranch March Days on Market and Absorption Rate
Home sold days on market during the month of March in Rogers Ranch, ranged from a low of 24 days on market to a high of over 515 days on market.
For the month, the average days on market was 195 and the median days on market of 144.
For the year, the average days on market is 145, up 4.3 percent from last year, and the median days on market of 95, an increase of 31.9 percent from 2014.
Rogers Ranch Home Sales by Number of Bedrooms
3 Bedroom Size: 2393 Sqft 4 sold in 2015
Average Sales Price: $364,250 Median Sales Price: $352,750
4 Bedroom Size: 3458 Sqft 6 sold in 2015
Average Sales Price: $419,792 Median Sales Price: $441,876
5 Bedroom Size: 3714 Sqft 5 sold in 2015
Average Sales Price: $414,159 Median Sales Price: $412,800
Rogers Ranch Current Listings
The data relating to real estate on this website comes in part from the Internet Data Exchange (IDX) Program of the San Antonio Board of REALTORS®. IDX information is provided exclusively for consumers' personal non-commercial use and may not be used for any purpose other than to identify prospective properties consumers may be interested in purchasing. All Information Is Deemed Reliable But Is Not Guaranteed Accurate.
What do you think?
Is there any other information you would like? What are your thoughts on how the real estate market is doing in Rogers Ranch? Please let me know what they are in the comments.


text:
Cincinnati Reds MLB City Mesh 9FIFTY Snapback Cap
Made of 90% Polyester, Woven, 7% Viscose, Woven, 3% Spandex, Woven
The Cincinnati Reds MLB City Mesh 9FIFTY Snapback Cap is guaranteed to keep you cool all summer long. Perfect for wearing to a baseball game on a hot day, the mesh back allows air to flow while the gray structured crown and flat visor feature the Cincinnati Reds name in bright, bold letters.
- 20825383
- Color:
- Gray/Black
- Availability:
- In Stock
International shipping available to Canada - info


text:
Tropical Fruit Liqueur
Be the first to review
READY IN: 2160hrs 15mins
Recipe by Alia55
This has a very nice light fruity taste. Very mellow and sweet.
See Discussion:
Ingredients Nutrition
- 1⁄3 cup pineapple
- 1⁄3 cup peach
- 1⁄3 cup mango
- 3 cups vodka
- 2 cups sugar
- 1⁄4 cup water
- 1 teaspoon glycerin (optional)
Directions See How It's Made
- In a quart jar, add fruit, 1 cup sugar, and vodka. (I use frozen berries as the freezing process breaks down the cell walls, allowing you to get more juice).
- Seal jar tightly, and place in a dry, dark place for about 2 weeks.
- After two weeks, strain the liquid using a double layer of cheese cloth. Gently squeeze the fruit, getting as much juice as possible.
- In a fresh quart jar, add the second cup of sugar, glycerin, water to top and the strained liquid. Seal and store again in a dark place until sugar is dissolved.
- Once the sugar has all dissolved, bottle the resulting liqueur in a fresh bottle and let age for roughly 3 months.


text:
Lindsey Graham Gets Beat Up By A Girl In The Senate
You may have missed it at the end of last week, but Senator Professor Warren took to the floor of the Senate andlit a whole bunch of stuff on fire, including the hiring practices of the last two Democratic presidents, and Citigroup. This was something which Senator Huckleberry J. Butchmeup would not put up with. So he put aside his fourth-generation bootleg DVD's of CIA interrogations in Thailand, stopped giggling, wiped away most of the drool, and rose up, such as he can rise up,to respond.
Waiting after Warren's blistering speech was Sen. Lindsey Graham, a deal-making Senate Republican prone to offering unsolicited wisdom to many of his colleagues. He cited comments Warren made during last year's shutdown, and said that his liberal colleague sounded a lot like conservative hardliners who tried - and failed - to defund Obamacare as part of last year's spending bill. "You have every right to vote no and argue to bring the bill down," the South Carolina senator chided her. "If there's something you don't like, welcome to democracy."..."If you follow the lead of the senator of Massachusetts ... people are not going to believe you are mature enough to run the place," Graham said. "Don't follow her lead. She's the problem."
All I want for Christmas is for Huckleberry to engage her publicly on the issues she discussed. There would be nothing left of him but the vapors.


text:
I believe he says that it will be called Infinity of Heaven or some such. Is he not even trying to fool anyone anymore by having Infinity in the title? I believe he said it would be a trilogy, but I know for a fact that WOT was supposed to be a trilogy and we see how that turned out. I guess I will read it, but I won't be happy about it.
American by birth, Southern by the grace of God.


text:
The Humanities are concerned with questions of value as well as of fact. History, biography and genealogy record our personal and communal past; geography studies place. Sociology focuses on the organization and interaction of groups of people, while law and political science deal with the direction of the state. Ethics analyzes mutual obligation; psychology and education the inner life. Philosophy and religion deal with our ultimate concerns. Language and literature form the means of our self-expression.
The browsable stacks are broken up into the open stacks and the local history materials. The open stacks include books on general knowledge such as: religion, psychology, philosophy, law/legal materials, government, literature, history and travel. The local history materials contain reference materials with areas of interest to genealogy and the history of Milwaukee and Wisconsin.
The materials in the closed stacks are available to the public, but a librarian must retrieve those materials.
[Legal Materials brochure] This handout is only for informational purposes regarding the Milwaukee Public Library System's holdings. Anyone with a legal problem or question is strongly advised and encouraged to consult an attorney.
The Humanities Department's main areas of focus are Genealogy and Local History. Many different resources exist to aid the genealogist in the search for their family's history. Humanities has partnered with the Milwaukee County Genealogical Society (MCGS) who have generously provided funding for two important genealogy resources online: Ancestry Library Edition and Heritage Quest.
Resources are available for the beginner in the form of classes run by the MCGS, and materials created by the Humanities Department librarians.
Resources for more advanced genealogy research include:
Vital Records materials
Obituary and Death Notice resources
African-American Genealogy materials
[Wisconsin Military Collections brochure] Information on military service members from Wisconsin.
[Researching the Family Tree brochure] A genealogical resource. The genealogical materials at the library are enhanced by related collections which have been developed for more than a century.
Back to top
The history of Wisconsin in general and Milwaukee in particular is an area of great focus for the Humanities Department. Beyond books on the history of the city (and there are a lot of those!) Humanities has many materials for the researcher of local history.
The department has a copy, either in print or on microfilm of every Milwaukee City Directory and phone book ever published. A number of suburban city directories and telephone books are available as well.
The department also has a stellar map collection. Cartographic materials include Milwaukee fire insurance atlases which cover the time period from the mid-1880s through the 1960s, plat maps and atlases that represent every county in Wisconsin, City of Milwaukee maps from all decades since Milwaukee's founding, and much more.
Many other types of materials are available. A good place to learn more about those materials and their use is to attend one of the Humanities Department's extremely popular programs on House History. The House History program is held a couple of times a year.
[Map Collection brochure] The Milwaukee Public Library's Map Collection includes maps both current and historical with an emphasis on those relating to Milwaukee.
The Humanities Department is home to seven different archives and special collections. These archives are:
City Archives
By City Ordinance and Wisconsin Statute, all records generated by the city must be scheduled and approved by the City Records Committee and certain schedules must also be approved by the Wisconsin Historical Records Board. Original records not microfilmed by the City Records Center are sent to the City Archives. The materials in the City Archives are in a variety of formats, including but not limited to bound consultant reports, correspondence files, department journals and ledger books, soft cover departmental annual reports, and tax records.
Historic Photo Archives
The Historic Photo Archives includes over 50,000 photographs of Milwaukee dating from the late 19th century to the present. The archives includes not only photographs but also collection of approximately 1,000 portraits of Milwaukeeans and national figures who had their pictures taken while visiting Milwaukee. In addition there is a large postcard collection that features more than 2,000 color and black and white postcards of Milwaukee architecture, businesses, bridges, churches, schools, parks, streets, and much more.
[Photo Archives brochure] The Milwaukee Public Library's Photo Archives provide a rich source of images of Milwaukee and the Milwaukee-related places, people, and events.
Manuscript Collection
The Humanities Manuscript Collection contains manuscripts, diaries, correspondence and other primary source material that focus on the City of Milwaukee.
Marine Collection
In affiliation with the Wisconsin Marine Historical Society, the library's Great Lakes Marine Collection includes ship files, log books, vessel plans, wreck reports and much more.
[Great Lakes Marine Collection brochure] The Milwaukee Public Library's Great Lakes Marine Collection includes books, photographs, articles and records that document vessels that sailed the Great Lakes.
The Milwaukee Public Library's Own Archives
MPL has a large collection of historical materials that relates to its own history. Materials include photographs, publications, and miscellaneous documents as they relate to the library's own history.
Milwaukee Road
MPL was designated in 1981 as the official archives of the Milwaukee Road, and has since been receiving historical materials from the Road as well as the Soo Line, which took over the line. The collection has grown to be quite large, with tens of thousands of items – valuable material for historians and train buffs.
When requesting information from the collection, please use the Milwaukee Road Archives Inquiry form. For inquiries about employee records, please fill out and send a waiver form along with your completed inquiry form. Forms should be sent to the address listed at the bottom of the inquiry form
The Wisconsin Architectural Archives was founded in 1975 and is a collection of drawings which record the talent and design styles of architects who shaped much of the appearance and history of Wisconsin. The WAA is dedicated to the acquisition and preservation of architectural drawings and materials.
In addition to its physical holdings, the Humanities Department has also created a number of digital collections and indexes.
The digital collections currently consist of:
Milwaukee Historic Photos
The collection represents the start of the process of making historic photos of Milwaukee available online. The photos from this collection are from the Milwaukee Public Library's historic photograph collection.
Milwaukee Waterways
These photographs are from the Port of Milwaukee, Milwaukee Public Library Historic Photo Collection, and the Great Lakes Marine Collection of Milwaukee Public Library and the Wisconsin Marine Historical Society. A matching grant from the Wisconsin Coastal Management Program helped preserve these photographs and make them available on line.
Remember When
A popular feature of The Milwaukee Journal from 1963 through 1994 prepared by library staff to highlight Milwaukee's past as preserved in the Historic Photo Collection.
The digital indexes currently consist of:
Newspaper clippings
This subject listing of people, places, events, etc. represents newspaper articles clipped by librarians from Milwaukee area newspapers published mainly in the middle to late 20th century.
Information on more than 10,000 Great Lakes vessels dating from 1815 to the present. It is a database of the Great Lakes Marine Collection of the Wisconsin Marine Historical Society and the Milwaukee Public Library.
World War I Military Portraits
A collection of 3,192 photographs of World War I military personnel from Milwaukee County are housed at the Central Library. This index includes the names of individuals in the photograph collection.


text:
American Indian UNC System Faculty Forum
November 11, 2013
8:00 am – 5:00 pm
Friday Institute, Centennial Campus, NC State University
Keynote Address
"Indigenizing the Academy?"
Dr. Bryan Brayboy
Dr. Brayboy is Borderlands Professor of Indigenous Education and Justice and Director of the Center for Indian Education, Arizona State University.
The primary goal of this event is to promote networking and collaboration among American Indian faculty and allies from across the UNC System.
Program Agenda
Official Program Agenda Booklet
- 8:00 – 8:45 Continental Breakfast and Conference Registration
- 8:45 – 9:00 Moment of Silence in Honor of our American Indian Veterans and Active Duty Service Members, followed by Welcome Remarks from Dr. Marcia Gumpertz, NCSU Assistant Vice Provost for Faculty Diversity and Dr. Susan Faircloth, OIED Faculty Liaison and Associate Professor, NCSU College of Education
- 9:00 – 9:30 Opening Remarks by Dr. Karrie Dixon, Senior Associate Vice President for Academic and Student Affairs, UNC General Administration and Dr. Jayne Fleener, Dean of the College of Education, NCSU
- 9:30 – 9:45 Guest Drum by John Richardson (Haliwa-Saponi)
- 9:45 – 10:15 Remarks from Dr. Alfred Bryant (Lumbee), Associate Dean of the School of Education and Director of Southeast American Indian Studies, UNC Pembroke
- 10:15 – 10:45 Remarks from Amy Locklear Hertel (Lumbee/Coharie), Director, UNC Chapel Hill American Indian Center, and Clinical Assistant Professor of Social Work
- 10:45 – 11:00 Morning Break
- 11:00 – 12:15 Keynote address, followed by questions and answers – Dr. Bryan McKinley Jones Brayboy (Lumbee), Borderlands Professor of Indigenous Education and Justice, and Director of the Center for Indian Education, Arizona State University
- 12:15- 1:15 Lunch, with entertainment by Unheard Voices (American Indian Student Vocal Group, UNC Chapel Hill)
- 1:15 – 2:15 Engaging American Indian Communities in Collaborative Research – Dr. Susan Faircloth (Coharie), Associate Professor of Education, NCSU
- 2:15 – 3:15 Talking Circles
- 3:15 -3:30 Afternoon Break
- 3:30-4:30 Reporting out of Discussion/Action Items from Talking Circles/ Formulating an Agenda for Facilitating Increased Networking, Collaboration and Support of American Indian Faculty, Staff and Students
- 4:30 – 5:00 Closing Activity
For additional information, please contact the Office for Institutional Equity and Diversity, NC State University 919-515-3148.


text:
Radio legend Tony Fenton passes away aged 53
Irish radio legend Tony Fenton has passed away today at the age of 53.
The Today FM and former 2FM DJ had been battling cancer for some time.
One of the most respected radio broadcasters in the business, Tony's distinctive voice and bubbly personality made him compulsive listening for fans spanning several decades.
"There will forever be a void on Irish radio that will never be filled," Ronan Keating, who was a close friend of the DJ tweeted.
"He was a pilot of the airwaves," former colleague Dave Fanning said.
"Very, very sad news. Gone too soon," said Brian Kennedy.
"What tragic, heartbreaking news," Niall Breslin commented.
Keith Duffy said: Very sad to hear about the passing of the legend and true music lover Tony Fenton. A sad day. And that voice! Rest easy Tony much love."


text:
Inform yourself — please read these three essays.
Search This Site
FINCANCIAL TYRANNY PERISHES — WE ARE FREE (click the picture)
- 911 Is Now Fully Exposed
- We Need A New Inclusive World Security Architecture
- The Truth About 911 Finally Reaches Main-Stream-Media
- Edward Bernays Helped Guide Our Society Into Lies — Propaganda — and Mindless Consumerism
- Here's Why NASA Never Returned To The Moon
- Public Chemtrail Hearing in Shasta California
- The Total Disintegration Of Tyranny Now Unfolds
- David Icke — A Powerful Interview With Alex Jones
- Nesara
- Karen Hudes Interviewed By Red Ice Radio
- Real News Necessary For Your Further Awakening
- Doomsday — Disinfo — or — Both?
- Rule From the Shadows — The Psychology of Power Part I
- Change Is On The Horizon — Learn The History Leading Up To Our New Paradigm
- Whaddabout THIS — Whaddabout THAT???
- Sybil Edwards Interview By Alex Jones
- Karen Hudes — Able Danger Interview
- Kevin Annett: The Vatican — Pedophilia — and the Royals
- Here We Are
- Rule of Zombies
- An Irreverent Critique of the Apostolic Letter
- The Truth Behind The Smoke Curtain
- The Battle For Our Angel
- Karen Hudes — World Bank Whistleblower
- Snowdon's Father Writes Barack Obama
- The Problem Well Defined — Yet No Suggestions for a Solution
- Gordon Duff: U.S. Dictatorship and its Freefall
- We Are Right At the Edge
- 20 Lies Which Every American Should Know
- Several Bank(st)ers Take the Plunge
- 1776
- Hundreds of Bankers, Brokers, and Traders Arrested Since June
- How To Bring Down America
- The Great Revealing
- Report on James Holmes Has Strange Implications
- The New Paradigm Begins As The Old Drowns In Its Own Corruption
- You were born here to THRIVE
- New Financial System Goes Online
- The Galactic Federation of Light
- Big Shakeup as the Criminals are Exposed
- Balance Lightly
Kadara The Healer
Short Stories, Novels and Some Poetry


text:
Community. Connections. Innovation.
Join our awesome community and make the most out of your stay.At Impact Hub Phnom Penh, every member counts. We are working hard to help you feel at home and be part of a dynamic community. All Hubbers can benefit from the following offers.
Hubbers Events
Events to connect you with our awesome community
Being a Hubber means being part of a vibrant community where everybody matters and the diverse range of experience and networks provides great opportunity for collaboration. We love our Hubber Events, which give members the time for precious moments of sharing and connecting.
Hot Seat Friday One Friday a month at 5.30pm. Take the hot seat and share stories of your work with fellow co-workers, all over a free beer or soft drink! A great way to promote your work and to learn more about what your co-work neighbour is up to.
Coffee Break. Every Monday at 4pm. Close your laptop, grab a coffee and introduce yourself to your neighbour.
Hubber's Night. Once a month. Chill out, grab a beer and enjoy some delicious pizza while mingling with your fellow Hubbers and special VIP guests!
Hubber's 'How To'. Twice a month at 4pm. Hubbers present quick-fire 15 minute sessions to our community – learn something new and exchange tips and tricks!
Hub Coaching
Every great achiever is inspired by a great Coach
All members get a 30% discount for any Hub Coaching Package. Our Coaching program provides 1-on-1 tailored support from our mentor in residence aimed at entrepreneurs developing their business plan or in need of expert advice to maximise their impact.Find out more
Business Clinics
Got a question? Get it answered
Our Business Clinics offers quick 30 minute sessions with our network of industry experts who are here to offer quick and professional advice!Find out more
Hub Passport
Impact has no borders
We have partnered with other Impact Hubs and co-working spaces across the region to provide you with access to other exciting spaces and communities.Find out more
Khmer classes
Learn the local language
We offer free Khmer lessons every Wednesday at 4pm with Pisey from Making It Easy, one of our wonderful members. A great opportunity to really get to know Cambodia. See if you can master the world's longest alphabet!
Discover Impact Hub's partners
With your membership you can have discounts in the nearest café, restaurant and Spa :
$3 at Cambodian Living Arts performances
10% at Will's Brunch
10% at Villa Cambell
10% at Tumkratoei Cambodia
15% at Champei Spa
10% at Making It Easy
10% at Sushi Chef
10% at Namaste India
10% at at Eleven One Kitchen
Up to 20% at Zenith Orthodontic Center


text:
Slender–body theory is used to determine the approximate static shape of a conically ended dielectric drop in an electric field. The shape and the electric–field distribution follow from solution of a second–order, nonlinear ordinary differential equation that can be integrated numerically or analytically. An analytic formula is given for the dependence of the equilibrium cone angle on the ratio of the dielectric constants of the drop and the surrounding fluid. A rescaling of the equations shows that the dimensionless shape depends only on a single combination of and the ratio of electric stresses and interfacial tension. In combination with numerical solution of the equations, the rescaling also establishes that, to within logarithmic factors, there is a critical field Emin for cone formation proportional to (−1)−5/12, at which the aspect ratio of the drop is proportional to (−1)1/2. Drop shapes are computed for E∞ > Emin. For E∞ ≫ Emin the aspect ratio of the drop is proportional to . Analogous results apply to a ferrofluid in a magnetic field.
Royal Society Login
Sign in for Fellows of the Royal Society
Fellows: please access the online journals via the Fellows' Room
Not a subscriber? Request a free trial
Log in using your username and password
Log in through your institution
Pay Per Article - You may access this article or this issue (from the computer you are currently using) for 30 days.
Regain Access - You can regain access to a recent Pay per Article or Pay per Issue purchase if your access period has not yet expired.


text:
Unimac #F607143 Washer COVER FRT T UF135
Buy this commercial Unimac part #F607143 replacement washer COVER FRT T UF135 here online at PWS Laundry the #1 Unimac washer repair parts supplier. We offer shipping specials on all Commercial Unimac Laundry Parts
- Genuine Unimac Part #:F607143
- Laundry Machine Type: Commercial Washer
- Unimac OEM Description: Replacement COVER FRT T UF135
- Unimac Parts
- This part is special order and may not be available for immediate shipment.
- New
Shipping Information
- Item Requires Shipping
- 37.0 lbs.
- W8.0000" x H6.0000" x L8.0000"
- Have a question? Ask the Pros
- Email UsGet answers from the pros
- 800-800-4797 323-490-1900 Mon-Fri 7:00am - 5:00pm PST
- Live ChatChat or Leave a Message
- The PWS Difference
- Laundry Parts ExpertsLaundry experts since 1968!
- Free Shipping On most orders over $50*
Most orders ship the same day
- Largest SelectionOver 120,000 laundry parts online and 20,000 Manuals
- International Shipping


text:
The well proportioned superyacht SOLWAY LASS is a sailing yacht. This 37 metre (121 ft) luxury yacht was manufactured by Bodewes Scheepswerf in 1902. SOLWAY LASS was once called Stina; Adolf; Solway Lass; Bent; Sundeved; Lawedua; Tui-Na-Savu Savu. This balanced boat has been designed with naval architects G. & H. Bodewes.
SOLWAY LASS was originally built in 1902 and was then named Stina. In 1905 she was sold and renamed to "Adolf", while she worked in and around the Baltic and North Sea. In 1915 the yacht was seized as a prize of war by the British and used as a Q-Ship during WWI. At the end of WWI, she worked as a coal, produce and stone carrying vessel between Liverpool and Scottish Ports. In 1924 the yacht was again sold â this time to a Scottish firm in the Solway Firth where she was renamed Solway Lass. When WWII broke out the Germans seized the yacht a s a prize of war where she was used to supply their armed forces. During the war SOLWAY LASS hit a mine and was badly damaged, however the Germans repaired the hull because SL was useful as a sail-powered icebreaker. After WWII she served in the South Pacific as a Cargo Vessel. In 1983 an Australian businessman purchased SOLWAY LASS in Fjii. From 1983 to 1985 the yacht was rebuilt and in 1988 took pride of place in the 1st Fleet re-enactment of the Tall Ships into Sydney Harbour.
The yacht's general design work came from G & H Bodewes. The technical naval architect drawings are the products of G & H Bodewes. Created at Bodewes Scheepswerf this yacht was built in the known yacht building country the Netherlands. She was officially launched in Martenshoek in 1902 before being handed over to the owner. Her main hull was crafted from iron. The sailing yacht superstructure is fabricated largely with wood. The measurement of the luxury yacht on deck is 27.62 (90.6 ft). With a beam of 5.91 metres or 19.4 ft SOLWAY LASS has reasonable size. She has a reasonably shallow draught of 2.5m (8.2ft). She had refit improvement and alteration work carried out by 1986.
The main engine of the SOLWAY LASS produces 189 horse power (or 139 kilowatts). Her total HP is 189 HP and her total Kilowatts are 139. She is driven by a single screw propeller.
This ship has room for around 5 capable crewmembers to run.
Main Engine(s) is one 189 Horse Power / 139 kW Caterpillar. The Model type is 3306 diesel. - Giving the combined power of 189 HP /139 KW. - Potable water capacity: unknown. - Generators: 1 times 30 kilowatts. - Area of Sail: 510 Metres Squared. - Yacht Beam: 5.91m/19.4ft. - LOD: 27.62m/90.6ft. - Waterline Length (LWL): 24.38m/80ft. - Draught at deepest: 2.5m/8.2ft.
Her deck material is predominantly a wood deck.
The luxury yacht SOLWAY LASS displayed on this page is merely informational and she is not necessarily available for yacht charter or for sale, nor is she represented or marketed in anyway by CharterWorld. This web page and the superyacht information contained herein is not contractual. All yacht specifications and informations are displayed in good faith but CharterWorld does not warrant or assume any legal liability or responsibility for the current accuracy, completeness, validity, or usefulness of any superyacht information and/or images displayed. All boat information is subject to change without prior notice and may not be current.
37m (121.4'), 1902, The Netherlands, Bodewes Scheepswerf, G & H Bodewes


text:
Hi….Let me introduce my self as a Proactive & Innovative Audio(Sound)Professional. Presently I am based in Mumbai and keep myself engaged in the film & television world as per my capability and efficiency, which I think is quite at par with the recent trends of the industry. I try to keep my self abreast with the current technological...
Tell me about your project and how I can help, through the 'Contact' button above.
My credits include
Gear highlights
- deva 5.8