OpenSolaris
Collectives
Discussions
Documentation
Download
Source Browser
Free CD
Log-in
|
en
Community Group arc
:
ARC Policies
>
Release Taxonomy
Top Menu
View
:
Comments
Attachments
History
Information
View Source
Print
:
Print preview
Export as PDF
Export as RTF
Export as HTML
Export as XAR
Wiki source code of
Release Taxonomy
Hide line numbers
1: =Release Taxonomy 2: 3: Copyright 1991-2007, Sun Microsystems, Inc 4: 5: ===Policy Synopsis 6: 7: A Release Taxonomy sets forth rules of the road that will help Sun deliver the customer an understandable progression of releases without presenting impediments to the delivery of large amounts of innovation in hardware and software. This memo establishes a logical guide for the formation of staged releases as proposed by the SSBT, It may not be practical to implement all aspects of the proposal immediately; thus, the memo describes a goal to be attained through a series of near-term compromises. 8: 9: This memo is based on work of the Software Development Process Team, plus inputs from members of the Solaris Business Team and many others throughout Sun. 10: 11: This memo has benefited from inputs by many reviewers, and especially from extensive comments by Randy K and Andy H. 12: 13: ===Contents 14: 15: {{toc start=2 depth=2 numbered=false scope=page /}} 16: 17: ===Overview 18: 19: | Gary S. | September 21, 1989 | Initial Publication 20: | Steve. C. | February 1, 1999 | Updated to account for the new release model. Changes are indicated by color 21: | John P | August 15, 2002 | Converted from troff to html. Changes limited to those needed to represent things in html (i.e., changed troff symbol charset usage to notation like "**[must contain]**") 22: 23: = Operating System Release Taxonomy 24: 25: == Introduction and Scope 26: 27: This memo discusses mechanisms and policies for operating system and hardware deliveries via Sun’s traditional //direct sales channel//. Other channels may require a different (in many ways more restrictive) set of guidelines for generating releases. The presentation dwells on issues of concern primarily to the operating system (and other software close to the hardware). The discussions apply, albeit in simpler form, to all other areas of software. 28: 29: The presentation is somewhat heavy at times. It has been difficult to derive rules of the road that are both reasonable and yet easy to describe in all their ramifications. Thus, the presentation attempts to say things in three ways: mathematical notation, prose and tables. Hopefully, the reader will find that points not clear in one form will be better understood in another, and that it is not necessary to understand all forms (especially the math!). 30: 31: All rules presented in this memo are subject to variances based on business requirements. Thus, it is assumed that a responsible body (the Q team) will oversee the application of the rules and granting of variances. However, extensive use of variances will suggest that something is broken, so the reader is encouraged to assess the rules by how well they serve the stated goals and by how (in)frequently they are likely to need variances. 32: 33: A summary of the major concepts can be obtained by reading sections 1, 2 and 3 coupled with careful study of Table 0 and Table 1. 34: 35: == The Release Naming Scheme 36: 37: The term //release level// will be used to designate release content as an abstraction and the term //realization// will be used to designate the actual bits for a particular set of machine architectures and packages. The importance of maintaining a distinction between the abstraction of content and the realizations of content stems from the need to paint an understandable progression of software content for Sun’s customers while maintaining flexibility in the delivery of new products. 38: 39: The major goals are: 40: * any perceived differences between realizations of the same release level must be obvious and direct consequences of differences in the machine implementations, peripherals supported or packaging choice. 41: * the sequence of realizations must avoid surprises or anomalies with respect to the hardware products supported, software features present, and bugs fixed or introduced. 42: * the overall scheme must make sense to customers, end-users, ISVs, OEMs, sales and support. 43: * timing of realizations must take into account a substantial proportion of the installed base of hardware, software, OEM and 3rd party products. 44: * timing of realizations must take into account a substantial proportion of Sun’s shipping hardware products. 45: * there must be a vehicle for timely delivery of new software functionality, hardware platforms and peripherals. 46: 47: These goals are often at odds with one another and will always require careful management. A release naming scheme will not eliminate all problems, but can serve to provide the element of rationality within a framework for delivering a rich, complex and fast-growing product line. 48: 49: A release realization name takes the form: 50: : {{code}}architecture [ / flavors ]{{/code}} 51: : {{code}}product major . minor [ . micro ] package{{/code}} 52: 53: For a given realization, //architecture// indicates what set of application and implementation architectures the realization runs on and the optional qualifier //flavors// indicates that the realization runs on some limited set of configurations. 54: 55: //product// names the base product and //major//.//minor//[.//micro//] names the release level. 56: 57: These two components completely determine the content (or functionality) of the release as an abstract entity. //package// indicates the precise form the realization takes. For example, 58: 59: : Sun-3 OS 5.2.1 ½" 60: 61: names a realization of release level 5.2.1 of the operating system that runs on any Sun-3 and appears on half-inch tape. 62: 63: Note that there can be many realizations of the same //release level// of a given //product//, and the rationale for those realizations must somehow be encoded in the other components of the name, primarily //flavors// and //package//. 64: 65: This is a problem that will require ongoing scrutiny as release plans evolve, and the details on the form of the remainder of the name have been left vague on the assumption that the product team will do the right thing with it. Some of the considerations on the use of //architecture//, //flavors// and //package// components should become apparent on further reading. 66: 67: == Further Definitions and Concepts 68: 69: === Release Families 70: 71: A //minor release family// is the sequence of micro releases having the same minor release prefix. 72: 73: A //major release family// is the sequence of minor and micro releases having the same major release prefix. 74: 75: A new release level or new realization of an existing release level is said to be //against// or //based on// an existing release level if it is derived from that release level by the rules and guidelines in this memo. 76: 77: === Release Realizations 78: 79: The set of realizations scheduled for a release level is well-defined and changes slowly over time to incorporate new (or obsolete old) architectures, machines, configurations and packages (by rules outlined in subsequent sections). This set is referred to as the //reference realizations//. 80: 81: No new release level will ship without a full set of reference realizations. This is because the reference realizations serve as a standard by which other realizations are measured and because the reference realizations form the core set of realizations needed before a release level can be the "preferred choice" in sales situations or strongly recommended for upgrades of existing sites. 82: 83: Additions to the set of reference realizations for a given release level are determined by a set of rules intended to control the amount and type of risk appropriate for major, minor and micro release levels. In general, new entrants to the set of reference realizations must prove that they are ready by first appearing in a //specific realization// (see below). However, there is some flexibility to this rule to allow for business requirements and scheduling realities. 84: 85: Strictly speaking, the set of reference realizations does not grow as a superset with increasing release level or with passing time, but it should tend to do so. 86: 87: === Specific Realizations 88: 89: A //specific realization// is a port of a shipping release level targeted for a limited set of new hardware[1] products; //platform realization// and //platform specific realization// are common alternate terms with the same meaning. A specific realization never creates a new release level. A specific realization introduces new hardware. Typically, new release levels for the reference realizations will require a new specific realization for those release levels until the specific realization is consolidated into the reference realizations. 90: 91: The set of files that may be different between a specific realization and a corresponding reference realization into which it will eventually be subsumed is roughly defined by the contents of ///usr/kvm//[2]. 92: 93: Other rules governing specific realizations (presented in the sections that follow) are intended to insure that they appear to be part of the reference realization in every possible respect. 94: 95: Specific realizations are delivered as a package that upgrades an already existing reference realization, or as a complete installation package. This will be determined by the technical and business requirements. 96: 97: In the naming scheme, the //product// and //release level// components of the specific realization name are the same as the corresponding reference realization. The remaining components of the name differentiate it from the reference realization as appropriate. For example, specific realizations are identified by the //flavors// component; thus, 98: 99: : Sun-3x/555 OS 5.2.1 ½" 100: 101: names a specific realization of release level 5.2.1 of the operating system that runs on Sun-3x model 555’s and appears on half-inch tape. 102: 103: ---- 104: [1] For convenience and economy, the term hardware covers all possible variability in architectures, machines, configurations and packages. 105: 106: [2] The files that may be different are those that are not shared, as long as there is no violation of interfaces. The precise specification of file sharing is available as part of the //SunInstall// design and implementation documents. 107: ---- 108: 109: === Limiting the Variables 110: 111: The most powerful tool for control of release realization schedule is control of content. Thus, the rules presented in this memo are intended in part to regulate content of individual realizations consistently with overall goals. In simplest form, the rule is: 112: 113: : //New software on stable hardware.// 114: : //New hardware on stable software.// 115: 116: However, control must go beyond these rules. For example: 117: * Software deliverables must be required to pass unit tests for quality and performance //before// they are integrated into the release. Software that is not ready to meet the unit test criteria must be delayed to a later release level. 118: * The number of hardware deliverables in a realization must be determined by the overall **Beta** testing requirements and the cumulative schedule risk. Since hardware is often affected by outside factors (such as component availability) and can have significant short-term implications for revenue, it will often make sense to limit risk by partitioning the realizations carefully. 119: * Even when dealing with known entities, such as bug fixes and hardware already shipping on a specific realization, careful assessments must be made of the overall risk of many changes in a single realization. 120: 121: At the other end of the spectrum, the number of realizations supported in the field and the number of realizations under development are also measures of complexity and risk that must be controlled. This issue is addressed by the product Q team. 122: 123: === Release Binding 124: 125: Release binding is the point at which deliverables have been identified for inclusion in a new release level of a product, and the process of loading the train starts. No new deliverables can be accepted after this point, and the set of reference realizations is fixed for the release. 126: 127: Following release binding, and preceding **Beta**, is a closely scheduled period of integration(s), build(s) and test(s). 128: 129: === Beta 130: 131: At Beta, a release must meet all content, quality and performance goals set for FCS, as measured by internal testing procedures. In other words, the engineering of the product is complete. The **Beta** period is intended to test and improve the ability of the remainder of the organization to manufacture, deliver, support, ... the new release level of the product in the field. 132: 133: === Patches, Upgrades and Installs 134: 135: A //patch// is a limited set of files and changes to files, along with scripts to aid in installation of the new files and changes within the context of an existing installed system or network. The individual patches can be installed selectively, as long as precedence requirements are met. 136: 137: A //true upgrade// applies all necessary changes to bring an existing installed system or network to the same state it would be in after a full installation of the release realization being used to do the upgrade. The installation tape used for the upgrade will contain scripts to aid in the upgrade process. 138: 139: Patches and true upgrades occur "in place"; that is, existing user files and administrative data are preserved without requiring backup and restoration. 140: 141: An //install// overwrites an existing installed system, if present. Existing user files and administrative data must be backed up, restored, and possibly converted to carry over into the new release. 142: 143: When discussing compatibility properties from the customer or end-user view-point, the term upgrade is somewhat ambiguous: the term "upgrade" may be used to describe an //install// of a higher release level over an existing lower level release. When a true upgrade could have been done, an install will achieve equivalent results at higher cost; however, there are situations in which this could represent a set-back. This memo attempts to carefully differentiate these situations. 144: 145: == Reference Realizations 146: 147: This section is, for the most part, summarized by the columns labeled //Reference Realizations// in Table 0. 148: 149: In the discussions that follow, the concept of containment (**[must contain]**) relates to the "visible" aspects of software features or hardware support, not to their implementation. The function ReleaseDate( ) yields the release binding date for a release; if only the release level is specified, the date is for the set of reference realizations. 150: 151: === Major Releases 152: 153: ==== Basics 154: 155: 156: **X.0 is a major release** 157: **X.0 [is equivalent to] X.0.0** 158: 159: Major releases always have a 0 as the minor release number. For convenience in discussions, the 0th micro release against a major release is equivalent to the major release. 160: 161: **X.0 [must contain] (X-1).Y.A [when] ReleaseDate(X.0) >= ReleaseDate((X-1).Y.A)** 162: 163: A major release must contain all generic software features in a minor or micro release against the previous major release whenever the major release binding date is later than or the same as that minor or micro release binding date. 164: 165: Furthermore, a major release must contain all patches whose availability date is earlier than or the same as the release binding date. 166: 167: These rules do not apply to obsolescence. 168: 169: ==== Planning Release Content 170: 171: 172: A major release introduces or changes significant software functionality and architectural features. It includes bug fixes that were in previous releases and may include additional bug fixes. Although every attempt is made to provide compatibility for existing applications, some applications may have to be re-released to work at all, and some will have to be re-released to realize the same (or better) performance and integration. 173: 174: A major release may require an install (as opposed to a true upgrade). The administrator will be given tools and instructions for preserving or, where necessary and possible, converting existing "user" files. 175: 176: New hardware can be added to a major release only if it has FCSed on a specific realization before the major release binding date. Note that the time from release binding to FCS for a major release will be much longer than for a minor or micro release. 177: 178: ==== Scheduling the Release 179: 180: 181: Major releases are not scheduled to occur on a regular basis. For the operating system, this probably means a major release less frequently than once every two years. 182: 183: The schedule from release binding to FCS for a major release is not as proscribed as a minor or micro release. The schedule for a major release can only be set as a goal until the release has attained **Alpha** quality, at which point status and plans are reviewed to establish a committed plan. 184: 185: ==== Lifetime 186: 187: 188: The effective lifetime of a major release is long when one considers that it will be used as the basis for many minor and micro releases. The lifetime of the initial release of the family (X.0) is in other respects the same as that of a minor release. 189: 190: Minor, micro and patch releases from the previous major release family may continue availability until deemed no longer necessary. This is because a major release cannot be the preferred shipment until enough unbundled and 3rd party products are available to allow substantial acceptance of the release in the customer base. Supporting multiple major release families will have high logistic and strategic costs; therefore, "hold-out" hardware, unbundled and 3rd party products may have to be pressured into move forward to the new major release family. 191: 192: ==== Obsolescence 193: 194: 195: A major release is a prime opportunity to obsolete software programs or interfaces that are deemed no longer worth maintaining or have been replaced by new programs or interfaces. Major releases can also be used to obsolete hardware support. Obsolescence is allowed only with suitable warning and must include a phase-out or transition period. 196: 197: === Minor Releases 198: 199: ==== Basics 200: 201: 202: **X.Y [when Y > 0 ] [is defined to be] a minor release** 203: **X.Y [is equivalent to] X.Y.0** 204: 205: Strictly speaking, minor releases start numbering from 1; however, since a major release can have minor release content, some discussions will implicitly or explicitly include X.0 as a minor release. 206: 207: For convenience in discussions, the 0th micro release against a minor release is equivalent to the minor release. 208: 209: **X.Y [must contain] X.Y-1 [when] Y >= 1** 210: **X.Y [must contain] X.Y-1.A [when] Y >= 1 [and] ReleaseDate(X.Y) >= ReleaseDate(X.(Y-1).A)** 211: **X.Y [must contain] X-1.Z.A [when] Z >= 0 [and] A >= 0, [and] ReleaseDate(X.Y) >= ReleaseDate(X-1.Z.A)** 212: 213: A minor release must contain all generic software features in a previous minor release against the same major release. 214: 215: A minor release must contain all generic software features in a micro release against the previous minor release whenever the minor release binding date is later than or the same as that micro release binding date. 216: 217: A minor release must contain all generic software features in a minor or micro release against the previous major release whenever the minor release binding date is later than or the same as that minor or micro release binding date. 218: 219: Furthermore, a minor release must contain all patches whose availability date is earlier than or the same as the release binding date. 220: 221: These rules do not apply to obsolescence. 222: 223: ==== Planning Release Content 224: 225: 226: A minor release introduces non-interfering new or extensions to software functionality and architectural features, plus bug fixes. 227: 228: An administrator will have the option of applying a minor release as either a true upgrade or an install. For an install, the administrator will be given tools and instructions for preserving or, where necessary and possible, converting existing "user" files. 229: 230: For an upgrade, no special action will be required to preserve or convert existing "user" files (although backups are recommended). The existing system must already be installed with a release based on the same major release and must be a subset of the upgrading release. In other words: 231: 232: : //X.Z can upgrade X.Y.A// 233: : //if ReleaseDate(X.Z) >= ReleaseDate(X.Y.A) // 234: 235: Violation of this rule could reintroduce a bug or de-support hardware. 236: 237: New hardware can be added to a minor release only if it has FCSed on a specific realization before the minor release binding date. 238: 239: ==== Scheduling the Release 240: 241: 242: Minor releases occur with predictable regularity following the base major release. For the operating system, this probably means a minor release every 9 months. 243: 244: The set of reference realizations for a minor release level will require a full round of regression testing. 245: 246: ==== Lifetime 247: 248: 249: Shipment of the reference realizations for a minor release is discontinued when there are reference realizations for a new micro release within the minor release family. 250: 251: After a new (i.e., higher numbered) major release level is issued, minor releases in the previous major release family can be issued if the analogous bug fixes, feature content or hardware support is made available in the new major release family in a timely fashion. The new major release cannot do a true upgrade of these releases, so there is no danger of re-introducing a bug or de-supporting features or hardware by that path. However, the new major release can be //installed// over a minor release containing the bug fixes, features or hardware support; in the customer’s view, this is analogous to an upgrade and must occur only after careful consideration. 252: 253: ==== Obsolescence 254: 255: 256: Software programs or interfaces and hardware support may be obsoleted at a minor release only after suitable warning and a phase-out or transition period. 257: 258: A major release is the preferred vehicle for obsolescence. 259: 260: === Micro Releases 261: 262: ==== Basics 263: 264: 265: **X.Y.A [when] A > 0 [is defined to be] a micro release** 266: 267: Strictly speaking, micro releases start numbering from 1; however, since a major or minor release can have micro release content, some discussions will implicitly or explicitly include X.0 or X.Y.0 as a micro release. 268: 269: **X.Y.A [must contain] X.Y.(A-1) [when] A > 0** 270: 271: Any micro release must contain everything in a previous micro release against the same minor release. 272: 273: Furthermore, a micro release must contain all patches whose availability date is earlier than or the same as the release binding date. 274: 275: These rules do not apply to obsolescence. 276: 277: ==== Planning Release Content 278: 279: 280: Micro releases incorporate bug fixes, consolidate hardware content from specific realizations, or introduce a limited set of new peripherals. 281: 282: A micro release may introduce non-interfering new software functionality and architectural features or extensions to existing software functionality and architectural features. A micro release does not introduce incompatibilities. Any perceptible difference between the micro release and the base minor release must be a direct and obvious result of a bug fix or the adaptation of the software to the new hardware , or from usage of the new feature or extension . 283: 284: An administrator will have the option of applying a micro release as either a true upgrade or an install. For an install, the administrator will be given tools and instructions for preserving or, where necessary and possible, converting existing "user" files. 285: 286: For an upgrade, no special action will be required to preserve or convert existing "user" files (although backups are recommended). The existing system must already be installed with a release based on the same major release and must be a subset of the upgrading release. In other words: 287: 288: : // X.Z.B can upgrade X.Y.A// 289: : if ReleaseDate(X.Z.B) >= ReleaseDate(X.Y.A) // 290: 291: Violation of this rule could reintroduce a bug or de-support hardware. 292: 293: With limited exceptions, new hardware can be added to a micro release only if it has FCSed on a specific realization before the micro release binding date. 294: 295: ==== Scheduling the Release 296: 297: 298: Micro releases are scheduled as necessary to introduce new hardware or bug fixes into the manufacturing delivery channel. For the operating system, this probably means a micro release every 2 months at minimum, and less frequently if conditions permit. 299: 300: The amount of testing required is a judgment call. In general, the need for extensive regression testing of a micro release is a sign of inappropriate content and will tend to defeat the goal of short turn times for these releases. 301: 302: ==== Lifetime 303: 304: 305: Shipment of the reference realizations for a micro release is discontinued when there are reference realizations for a new micro release within the minor release family. 306: 307: After a new (i.e., higher numbered) minor (major) release level is issued, micro releases in the previous minor (major) release family can be issued if the analogous bug fixes or hardware support is made available in the new minor (major) release family in a timely fashion. The new minor (major) release cannot do a true upgrade of these micro releases, so there is no danger of re-introducing a bug or de-supporting features or hardware by that path. However, the new minor (major) release can be //installed// over a micro release containing the bug fixes or hardware support; in the customer’s view, this is analogous to an upgrade and must occur only after careful consideration. 308: 309: ==== Obsolescence 310: 311: 312: Micro releases are not allowed to obsolete software programs or interfaces. Micro releases can obsolete hardware support after a suitable warning and a phase-out or transition period. 313: 314: === Patch Releases 315: 316: ==== Basics 317: 318: 319: Patches are bug fixes that require special and immediate distribution to the field. 320: Distribution of patches is the responsibility of CSD. 321: 322: Creation of patches is a cooperative effort of the CSD, development, release engineering and testing organizations, as required. 323: 324: Naming issues for patches are complex. A single patch realization could apply to many release realizations so a straightforward extension of the release naming scheme does not apply. Since patch names are not widely visible, issues of naming can concentrate on careful tracking of which patch realizations apply to which release realizations, and, when a patch is applied, insuring that a record is left to show that the patched system now differs from the base release realization. 325: 326: This is a technical problem that needs further resolution. 327: 328: ==== Planning Release Content 329: 330: 331: Patch releases are for bug fixes. A patch may introduce non-interfering new software functionality and architectural features or extensions to existing software functionality and architectural features. In the case of new features it is preferred that they be delivered as new packages instead of as patches to existing packages whenever possible. , except to the extent that a new feature or extension introduces new behavior when used 332: 333: When a patch is applied, no special action will be required to preserve or convert existing "user" files (although backups may be recommended). Dependency relationships among patches is allowed, but they may be otherwise selectively applied. 334: 335: ==== Scheduling the Release 336: 337: 338: Patch releases occur on an as-needed basis. 339: 340: Patch releases should require little testing. The amount of testing required is a judgment call. In general, the need for extensive regression testing of a patch release is a sign of inappropriate content and will tend to defeat the goals of short turn times and low resource consumption. 341: 342: ==== Lifetime 343: 344: 345: Patch releases must be kept until the release realization(s) they target are no longer supported. 346: 347: Patches are consolidated into all release realizations whose binding date is the same as or later than the patch availability date, and are therefore no longer needed for those releases. 348: 349: ==== Obsolescence 350: 351: 352: Patch releases are not allowed to obsolete software programs or interfaces or hardware support. 353: 354: == Specific Realizations 355: 356: === Compatible Hardware 357: 358: No software changes are needed to ship a compatible hardware product. Such products use existing realizations for **Beta** and FCS. Care must be taken to regression test the products against the appropriate realizations in the field and against realizations "in the works". Future software, firmware and hardware efforts will increase the likelihood and desirability of compatible hardware. 359: 360: === Incompatible Hardware 361: 362: A new hardware product requiring a port must target a shipping major, minor or micro release level to port and conduct full **Alpha**, **Beta** and **FCS** on a specific realization of the release level before it is considered for inclusion in subsequent reference realizations. 363: 364: The specific realization must be a faithful rendition of the release level, including bugs. No new software programs, features or interfaces can be introduced. Any perceptible difference between the reference realizations of the release level and the specific realization must be a direct and obvious result of adaptation of the software to the new hardware. These rules are subject to much interpretation; the ultimate determination is the domain of the Q Team for the product. 365: 366: A specific realization, say for hardware A, may enter the market shortly before or after reference realizations of a higher release level and no realization of the higher release level will support hardware A at that time. In that case, a port for hardware A to create a realization of the higher release level may be called for. In any case, hardware A must be incorporated into the reference set within a reasonably short time as these "anomalies" tend to confuse customers and complicate configuration planning. 367: 368: For economy, several hardware products may join to issue a composite realization. 369: 370: === Peripherals 371: 372: Reference realizations of micro releases are permitted to introduce a limited set of peripherals. This rule is specifically intended to permit the efficient introduction of boot and console devices into the product line. The release product team can reject or remove peripherals from the reference release realizations if the number of peripherals being introduced is deemed too large or if the risk factors are felt to be too high. The release product team may require the peripheral product team to conduct a separate realization through beta test as a means of controlling risk. 373: 374: === Upgrade and Patch Properties 375: 376: In software terms (ignoring obsolescence), the release level (//major.minor.micro//) represents monotonically increasing features and fixes; this is seen as an absolutely necessary property of the release scheme. However, release levels are not strictly tied to chronological order, the set of reference realizations does not monotonically superset with release level, and certain release levels may have specific realizations in addition to the reference realizations. These factors combine to make the rules for upgrading or patching one realization with another complex: it cannot be simply a matter of higher release level, as this might undo certain hardware support or bug fixes. This must be presented to the customer, sales person and TSE in an understandable way. 377: 378: Release realization information can be supplied as matrices that give the FCS dates, hardware support, software functionality, and upgrade and patch rules for release level realizations announced, shipping or widely installed. Primitive examples of such matrices are given in Tables [[1>>#TABLE1]], [[2>>#TABLE2]] and [[3>>#TABLE3]], with explanatory text in the following subsection. 379: 380: The exposure for "anomalies" in upgrade or patch rules creating problems for customers wanting a certain combination of hardware, software and bug fixes must be kept small and short. Every effort must be made to educate customers, sales people and TSE’s to make accurate decisions in the purchase of new hardware or the use of new software. As a final measure, the information from the matrices should be encoded into the release realizations and that information used to generate a warning message if the realization upgrades or patches contrary to the rules. 381: 382: === Upgrade and Patch Examples 383: 384: The following examples are constructed for illustrative purposes and do not reflect any known or intended release scenario. Furthermore, the examples are chosen to illustrate extreme cases and should not be construed as a reasonable way to do business. 385: 386: ==== FCS Avaliability of Realizations 387: 388: 389: Table [[1>>#Table1]] illustrates, in matrix form, some of the points made in this section. 390: 391: A sequence of dates for reference realizations of major, minor and micro release levels is shown in the first and second columns. Note that the sequence is sorted by FCS date of the reference realizations, not by release level; hence some release levels appear to be out of sequence. 392: * Hardware#A issued a specific realization of 5.0 that followed 5.0 and 5.0.1 reference realizations; it does not include the bug fixes in 5.0.1. The hardware#A realization of 5.0 finished **Beta** before release binding of release level 5.1 and was accepted into the reference realizations for release level 5.1 and higher release levels. Logically, the 5.0.2 reference realizations could have included hardware#A, but resource constraints and priorities prevented this. 393: * Hardware#B issued a realization of 5.0. It was not accepted into the reference realizations at release binding for release level 5.1; thus, hardware#B also issued a realization of 5.1 shortly after the reference realizations. The 5.1 realization picked up the bug fixes in 5.0.1. Hardware#B was accepted into the reference realizations for 5.1.2 and higher release levels. Logically, the 5.0.2 reference realizations could have included hardware#B, but resource constraints and priorities prevented this. 394: * Hardware#C issued a realization of 5.0.1 sufficiently before release binding for 5.1, and was accepted into the reference realizations for release level 5.1 and higher release levels. It was also accepted into the reference realizations for 5.0.2. 395: * Hardware#D (a peripheral) was accepted into the reference realizations for micro release 5.0.2. It was not accepted into the reference realizations for 5.1 and, because of resource constraints and priorities, chose to never appear in the 5.1 family. It was accepted into the reference realizations for 5.2 and higher release levels. 396: 397: For software features, release level strictly dictates supersetting of content, but chronology does not. This is demonstrated by the situation that occurs between 10/90 and 07/91 with respect to support for feature#P: 398: * Feature#P appears in 5.1, but not in 5.0.2 in a chronologically later release. 399: * Feature#P is in the specific realization 5.1/B, but bugs fixed in feature#P by the 5.1.1 release will not be fixed for hardware#B (cf. Table [[3>>#TABLE3]]). 400: * Hardware#D is in the reference realizations for 5.0.2 on 11/90, but does not appear at all in the 5.1 family; therefore it does not have feature#P until release 5.2 on 07/91. 401: 402: This is consistent with the software properties of release levels, and these apparent anomalies were presumably optimal for the overall business strategy given the constraints present. 403: 404: ==== Upgrade and Patch: Reference Realizations 405: 406: 407: Table [[2>>#TABLE2]] is organized to show whether the release named at the left of a row can upgrade (patch) the release named at the top of the column. 408: 409: Table [[2>>#TABLE2]] illustrates that, although a higher release level can usually upgrade (patch) a lower one, there are exceptions. In particular, release binding for 5.0.2 occurred late with respect to 5.1 and the reference realizations for that release cannot be upgraded by 5.1. Also, release binding for 5.1.3 occurred late with respect to 5.2 and realizations of 5.1.3 cannot be upgraded by 5.2. 410: 411: ==== Upgrade and Patch: Specific Realizations 412: 413: 414: Table [[3>>#TABLE3]] is organized to show whether the release named at the left of the row can upgrade (patch) the release named at the top of the column. 415: 416: Table [[3>>#TABLE3]] illustrates that specific realizations have more restrictive upgrade and patch rules because they do not appear in every family member of a release level and do not automatically receive the benefit of patch releases. 417: 418: Patches may be (perhaps by design) non-interfering with changed portions of a specific release, in which case, a patch release realization from the reference realizations could be applied to a specific release realization, independent of the relative release binding dates. Careful testing must be conducted before taking advantage of these situations. 419: 420: New hardware can expose bugs in portions of the reference realizations not allowed to change for a specific realization. In these cases, the preferred course of action is to leave the bug unfixed in the specific realization, deliver the fix as a patch that can apply to //all// relevant realizations and integrate the fix into the next release level. This mode of operation will result in the cleanest scenario for most support situations. 421: 422: === Client-Server Relationships 423: 424: Client-Server relationships on the network are controlled carefully to preserve compatibility across the 4 types of heterogeneity that may occur singly or in any combination: 425: * application architectures, 426: * implementation architectures, 427: * release levels, and 428: * realizations. 429: 430: Special problems arise for NetDisk (an NFS-based service for diskless machines). While it is possible for NetDisk service to provide full heterogeneity features, this is done at the cost of disk space required to replicate files for commands, libraries, etc. for each possible variant of client and server. When the NetDisk client and server have the same application architecture, same implementation architecture, same release level, and same realization, disk space requirements are reduced by having the client and server share most files from the installation tape. 431: 432: Problems arise when the a NetDisk client and server of the same application and implementation architecture run the same release level but different realizations: that is, either a specific versus a reference realization or two different specific realizations. For purposes of sharing, this case is treated like a machine at the same release level with the same application architecture but with differing implementation architecture; this greatly simplifies the testing, installation, support and upgrade scenarios. 433: 434: === Testing 435: 436: The potential mix of unbundled software, services, architectures, configuration options, release levels and realizations that may appear on a customer’s network makes exhaustive testing of all permutations and combinations costly in real-time, staff and equipment. 437: 438: For a major or minor release, the most extensive testing feasible must be applied. However, for micro releases and specific realizations, thought must be given to reducing real-time, staffing and equipment costs of testing. For example: 439: * Leverage the testing from other releases; 440: limiting the types of changes that are made in a micro release or specific realization is (in part) a step toward maintaining confidence in quality without extensive re-testing. 441: * Use the biggest possible lever;((( 442: consider generating micro releases and specific realizations by changing the fewest possible files in the realization of the baseline minor release - if possible, copy the files directly from the minor release realization rather than regenerate them! 443: ))) 444: * Automate;((( 445: especially for interactive components (i.e., installation), testing should be mechanized where possible. 446: ))) 447: * Subdivide;((( 448: especially for interactive components (i.e., installation), testing of media, user interface and functionality should be separated and mechanized where possible. 449: ))) 450: * Micro-manage potential problem areas;((( 451: certain "critical" components (e.g., compilers, installation tools, ...) should have earlier cut-offs and begin testing before other components. 452: ))) 453: * Find bad problems early;((( 454: test components where problems are likely to require extensive retesting (e.g., compilers, installation tools, ...) as early as possible in the test plan. 455: ))) 456: 457: Many aspects of these suggestions are best implemented as part of the process and infrastructure to support teams generating micro or specific realizations. 458: 459: === Release Team Relationships 460: 461: Release teams operate asynchronously and must talk to each other to insure the rules set forth apply. The Q team resolves difficult questions of procedure or decides business issues. 462: 463: === Feature Tapes 464: 465: Sometimes it is not necessary to create a full realization to introduce a new product. In these cases, a feature tape to be applied to one or more existing releases in the field can be produced. This may prove to be a low-cost way of conducting **Beta**; however, a micro or minor release is still the preferred vehicle for FCS. Carrying feature tapes all the way to FCS would complicate an already overly complex set of considerations for upgrades and patches; any product team using a feature tape for FCS must clear the plans with the parent Q team and present a detailed assessment of the upgrade and patch implications for near past and near future release realizations. 466: 467: === Chunks and Unbundled Products 468: 469: // Encourage more chunking and unbundling as a way of making releases more manageable and as a way of giving ownership to the pieces. "Virtually unbundle" even in cases where there is a decision to bundle for purpose of pricing and delivery. The bundled SunOS product becomes the union of many products (i.e., OS, windows, languages, ....) that can be released on independent schedules of their own.// 470: 471: //Discussion of the implications of this await further research.// 472: 473: == Table 0: Content Rules for Release Realizations 474: 475: |=Content |=Reference Realizations | | |=Specific Realizations 476: | |=Major |=Minor |=Micro|= 477: |Install Required |U |NP |NP |NA[1] 478: |Upgrade Install |D |R |R |NA[1] 479: |Feature Add |P |P |P[5]|NP 480: |Feature Drop |P |U |NP |NP 481: |Generic Bug Fix |P |P |P[2] |NP 482: |H/W Bug Fix |P |P |P |P 483: |Platform Add |P[3] |P[3] |P[2] |P 484: |Platform Drop |P |U |NP |NA 485: |Peripheral Add |P[3] |P[3] |P[2] |P 486: |Peripheral Drop |P |U |NP |NA 487: |=Source Compatibility (application level) | | | | 488: |Forward |D |R |R |R[4] 489: |Backward |D |D |D |R[4] 490: |=Binary Compatibility (application level) | | | | 491: |Forward |D |R |R |R[4] 492: |Backward |D |D |D |R[4] 493: 494: // Key: //**D**//esirable, //**N**//ot //**A**//pplicable, //**N**//ot //**P**//ermitted, //**P**//ermitted, //**R**//equired, //**U**//ndesirable.// 495: 496: For reference realizations, major release rules apply relative to any other release level; minor and micro release rules apply relative to lower release levels within their major release family. 497: 498: For specific realizations, all rules apply relative to the reference release being ported, except as noted. 499: 500: Footnotes: 501: 1. if a specific realization exists for another release level, or if the specific realization is being re-issued, the analogous reference realization rule must also apply between the specific realizations. 502: 1. micro realizations should concentrate on a single theme from: 503: 11. consolidation of platforms and peripherals from specific realizations. 504: 11. introduction of a limited set of peripherals. 505: 11. bug fixing. 506: 1. hardware can only be added if it has FCSed on a specific realization. 507: 1. differences between specific and reference realizations are characterizable within the contents of ///usr/kvm//. 508: 1. Changed from NP as part of Steve C’s revision. 509: 510: == Table 1: First Customer Ship Availability of Realizations 511: 512: |=Release Level |=Reference Set |=Hardware | | | |=Feature | 513: | | |=A |=B |=C |=D |=P |=Q 514: |5.0 |01/90 |05/90 |09/90 | | | | 515: |5.0.1 |04/90 |- |- |06/90 | | | 516: |5.1 |10/90 |<< |11/90 |<< |- |* | 517: |5.0.2 |11/90 |- |- |<< |<< | | 518: |5.1.1 |01/91 |<< |- |<< |- |* | 519: |5.1.2 |04/91 |<< |<< |<< |- |* | 520: |5.2 |07/91 |<< |<< |<< |<< |* |* 521: |5.1.3 |08/91 |<< |<< |<< |- |* | 522: |5.2.1 |10/91 |<< |<< |<< |<< |* |* 523: |5.3 |01/92 |<< |<< |<< |<< |* |* 524: 525: |=Key to Symbols | 526: |=Symbol |=Interpretation 527: |mm/yy |FCS date of realization 528: |- |no applicable realization 529: |<< |incorporated into the reference 530: |* |software feature appears in release 531: 532: == Table 2: Upgrade Rules for Reference Realizations 533: 534: |= |=5.0 |=5.0.1 |=5.0.2 |=5.1 |=5.1.1 |=5.1.2 |=5.1.3 |=5.2 |=5.2.1 535: |=5.0.1 | u | | | | | | | | 536: |=5.0.2 | u | u | | | | | | | 537: |=5.1 | u | u | x | | | | | | 538: |=5.1.1 | u | u | u | u | | | | | 539: |=5.1.2 | u | u | u | u | u | | | | 540: |=5.1.3 | u | u | u | u | u | u | | | 541: |=5.2 | u | u | u | u | u | u | x | | 542: |=5.2.1 | u | u | u | u | u | u | u | u | 543: |=5.3 | u | u | u | u | u | u | u | u | u 544: 545: |=Key to Symbols| 546: |=symbol |=interpretation 547: |u |can be a true upgrade 548: |x |cannot be a true upgrade 549: |- |does not apply 550: 551: == Table 3: Upgrade Rules for Specific Realizations 552: 553: |= |=5.0/A |=5.0/B |=5.1/B 554: |=5.0.1 |- |- | 555: |=5.0.2 |- |- | 556: |=5.1 |u |- | 557: |=5.1/B |- |u | 558: |=5.1.1 |u |- |- 559: |=5.1.2 |u |u |u 560: |=5.1.3 |u |u |u 561: |=5.2 |u |u |u 562: |=5.2.1 |u |u |u 563: |=5.3 |u |u |u 564: 565: |=Key to Symbols| 566: |=symbol |=interpretation 567: |u |can be a true upgrade 568: |x |cannot be a true upgrade 569: |- |does not apply 570:
Search
Collectives
Community Group
Academic and Research
Accessibility
Advocacy
Appliances
Approachability
Architecture Process and Tools
BrandZ
Chinese Users
Community Advisory Board
Databases
Desktop
Device Drivers
Distribution
Documentation
DTrace
Emerging Platforms
Fault Management
Games on OpenSolaris
HA Clusters
HPC Developer
Installation and Packaging
Internationalization and Localization
Laptop
Logical Domains
Modular Debugger (MDB)
Networking
NFS
Observability
OpenSolaris Governing Board (OGB)
OpenSolaris Printing
OS/Net (ON)
Performance
Power Management
PowerPC
Security
Service Management Facility (smf(5))
Software Porters
Solaris Volume Manager
Storage
Systems Administration Community Group
Testing
Tools Home
Unix File Systems (UFS)
Website Community
X Window System
Xen
ZFS
Zones
Project
ADSL Modem Enhancement
ARC Process Definition
ARM Platform Port
Automatic Data Migration
BIND Update
Bluetooth Stack & Drivers
Brocade FC HBA - Initiator
Brocade FC HBA - Target
Brussels - unified network link configuration
Caiman, Solaris Install Revisited
Celeste
Český portál
Chime Visualization Tool for DTrace
CIFS client for Solaris
CIFS Server
Clearview: Network Interface Coherence
Cluster Agent: Informix Dynamic Server
Cluster Agent: OpenSolaris Container
Cluster Agent: OpenSolaris xVM
Cluster Agent: Oracle E-Business Suite
Cluster agent: PostgreSQL
Cluster Agent: Samba
Cluster Agent: Tomcat
CMT
Coarse Data Flow Parallelism
Colorado: Open HA Cluster on OpenSolaris
Command Assistant
Common Array Manager
Companion - /opt/sfw: Free and Open Source software
COMSTAR: Common Multiprotocol SCSI Target
Content
Contest
CPU Observability
Credentials Process Groups
Crossbow: Network Virtualization and Resource Control
Crypto KMS Agent Toolkit
Cryptographic Framework
Data Migration Manager
Data Tethers
Deutsches Portal
Device Detection Tool
Device Driver Utility
Device Manager
Device Mapper
Direct Rendering Infrastructure & 3D drivers
DTrace Guide
Duckwater: Simplified name services management
Easy Tools
Emancipation
Emulex Fibre Channel Device Driver
Emulex Advanced Ethernet Device Driver
Enable/Enhance Solaris support for Intel Platform
Enhance the support of USB webcams
Enhanced SMF Profiles
Enhancements for AMD-based Platforms
Erlang DTrace Integration
Ethernet bridge module for Solaris
Evaluate Conary
Events Registry
Ext3 file system support
F/OSS Package Base
Facilitation
Fibre Channel over Ethernet
Fine Grained Access Policy (FGAP)
Fingerprint Authentication
Flexible Mandatory Access Control
Forensic Tools
Fully Open X Project
Fuse on Solaris
gcore
Generic Machine Check Architecture Improvements
Google SOC
HA-JBoss
HA-MySQL
Hadoop Live CD
Hitachi
HoneyComb Fixed Content Storage
Hotplug Framework
HPC Stack
Image Packaging System
Immutable Service Containers
Improved Performance MIB
Indiana
Innovation Awards
Input Method
Intel Graphics
Internet Key Exchange, version 2
Interrupt Resource Management
IP Datapath Refactoring
IP over Infiniband
IPsec Tunnel Reform
iSCSI Extensions for Remote DMA (iSER)
iSNS Server
JeOS - Just enough Operating System
JKstat - a java binding for libkstat
Journaled File System (JFS)
K Desktop Environment
Kerberos
Kernel Sockets
Kernel SSL Enhancements
Key Management Framework
Korn Shell 93 integration/migration project
Labeled IPsec
LatencyTOP
Layer 2 Filtering
LDoms Manager
Lending
libMicro - portable microbenchmarks
Link Layer Discovery
Live Media: Technologies for distributions running from CD and other media
Locale Data
lofi compression and cryptography support
lx64 brand
Media Management System
Mega_sas
Mexico
MilaX minimal Live Distribution
MIPS Platform Port
Mozilla DTrace
MRSL.NONsharedDevice
Multi-lingual Glossary
Multi-pathing software (MPxIO)
Multiple disk sector size support
Multiple DOI
Muskoka: An open repository for OpenSolaris technical content
Navigator
Nemo: A Framework for High-Performance Networking
Network Auto-Magic
Network Data Management Protocol
Network MIBs
Network Performance Projects
Network Power Management
Network Storage
Network Time Protocol (NTP)
Nevada Globalization
New Design of 4over6 Mechanism Based on OpenSolaris
NFS RDMA transport update and performance analysis
NFS Server in non-Global Zones
NFS version 4.1 pNFS
NFSv4 namespace extensions
Nightingale: Port Songbird to OpenSolaris
NPort ID Virtualization (NPIV)
NUMA
Object Storage Device (OSD) support for Solaris
OHACGE Script Based Plug-in
ON/Nevada (ONNV) Project
Open Development Infrastructure
Open HA Cluster Utilities
Open Sound System
OpenGrok
OpenPegasus CIM Server
OpenRTI
OpenSolaris Busybox
OpenSolaris Desktop
OpenSolaris Hispano
OpenSolaris Security Audit
OpenSolaris support for the QEMU processor emulator: host and guest
PEF: Packet Event Framework
Performance Wrappers
Pkgfactory
Polski Portal
Portail Francophone
Portal Brasil
Portals
Power Management Usability Interfaces
Presto: Automatic Printing Configuration
Printable Many Page Solaris Manuals
Promise SuperTrak RAID HBA Driver
QLogic Converged Network Adapter GLDv3 NIC Driver
Quagga Routing Protocol Suite Integration
RAID Configuration Utility
RBridge (IETF TRILL) support
RDMA Offload Framework
Release Notes
Reno: Login Process Enhancements for Interop
Resource Management
s10brand
SAM/QFS
SCM Migration Project
SCSI RDMA Protocol
SDcard Drivers
Sensor Abstraction Layer
Session Initiation Protocol
SFW
Shell: bourne shell, korn shell, C shell, etc.
Sierra: Intel WiFi Chipsets Support
Simple Panels
SM-HBA Based SAS HBA Management
SMF Documentation
Solaris iSCSI Target
Solaris PowerPC Port
SourceJuicer
Sparks: name service switch/nscd enhancements
Squashfs
Star integration/migration project
Starfish
Starter Kit
Storage Power Management
Sun Security Toolkit
Sun StorageTek Availability Suite
Support for OpenFabrics User Verbs / API on OpenSolaris OS
Support gcc4/GCCfss in Solaris
Suspend/Resume
SVR4 Packaging
Systemz
Tamarack: Removable Media Enhancements in Solaris
Tesla: OpenSolaris Enhanced Power Management
Test Development
Tickless Kernel Architecture
TIPC
Trademarks
Trusted networking interface policy database for Trusted Extensions
Trusted Platform Module support
Use Case
Validated Execution Project
Virtual Console
Virtual Network Machines
Visual Panels
Visualization for HPC
Volo
VRRP: Virtual Router Redundancy Protocol Implementation
VSCAN service
Web Stack
Website
Winchester: Schema mapping and ID mapping for AD Interoperability
Wireless USB Support
Wireless Wide Area Network
X Consolidation
x86 Generic FMA Topology Enumerator
Xen Gate
Xfce: A lightweight desktop environment
X Keyboard Layout
ZFS Boot and Install
ZFS on disk encryption support
Zone Manager
Zone Statistics
Русский портал
البوابة العربية
भारतीय पोर्टल
中国门户
日本ポータル
한국 포탈
User Group
Adelaide
Argentina
Arizona
Atlanta
Baltimore-Washington
Bangalore
Bangkok
Bangladesh
Brasilia
Beijing
Bélem
Berlin
Bhimavaram
Bloomington
Capital Region
Cardiff
Ceara
Charlotte
Chengdu
Chennai
Chihuahua
Chile
Cleveland
Colombia
Columbus
Connecticut
Cracow
Czech
Dallas/Ft. Worth
Danish
Delaware
Edinburgh
Egypt
Finland
Florida
Frankfurt
Front Range
FuZhou
Great Lakes
Greece
Hangzhou
Hawaii
HeFei
Houston
Hong Kong
Hyderabad
Indonesia
Irish
Israel
Istanbul
Italian
Jinan
Jogja
Kabul
Kansas City
Latvia
London
Madrid
Madurai
Manchester
Mato Grosso
Melbourne
Minas Gerais
Minnesota
Montreal
Moscow
Mumbai
Munich
NEA
Netherlands
New England
New York City
New Zealand
NIT Hamirpur
Noroeste
Nuremberg-Erlangen
Oklahoma City
Osnabrück
Peru
Philadelphia
Piaski
Pittsburgh
Porto Alegre
Puget Sound
Pune
Queensland
Rio de Janeiro
Research Triangle Park
Romania
Russia
San Antonio
San Diego
San Francisco
São Paulo
Scottish
Serbia
Shanghai
Shenzhen
Silicon Valley
Singapore
Slovak
South African
Southern Connecticut
St. Louis
Stavanger
Sweden
Switzerland
Sydney
Szczecin
Taiwan
Tecum
Thames Valley
Tokyo
Toronto
Trondheim
Tulsa
Turkey
Ufa
Ukraine
University of Melbourne
Vale do Paraíba
Vancouver
Venezuela
Vladivostok
Welsh - Cymru
Wisconsin
Xi'an
Subsites
Code Reviews
Code Repositories
Package Search
Bugster
Bugzilla
Test Machines
Planet
Mailing Lists
Elections & Polls
ARC Case Logs
Source Juicer
Package Factory
User Authentication
Community Group arc Pages
ARCAgenda
FAQ
Use of the OpenSolaris aliases
ARC Fasttrack Handbook
When should developers interact with the ARC?
What sort of changes need ARC approval?
How do I publish/request an existing Sun ARC Case?
How to succeed with an Architectural review
What is an ARC Review?
Planning for the Architectural Review
ARC Fast-Track Sponsor Duties
General Principles for Requiring Changes to Projects
Announcing the Systems Architecture Process
Glossary
ARC Best Practices
ARC Alias Usage Guidelines
Architecture = Components + Interfaces
Command Lines and arguments
Configuration Files
Device Drivers
Environment Variables
Hardware Platform Dependencies
Internationalization (I18n)
Changes to interfaces
Inter-Project Compatibility
Libraries
Namespace Management and Conventions
Operating System Compatibility
Performance
Signals
Standards Conformance
Administrative and Security Precedents and Policies
Reusable Passwords In Command Line Arguments and Environment Variables
Storing Reusable Passwords on a Filesystem
Adding RBAC Authorizations
When to use setuid -vs- RBAC roles and profiles
Building RBAC Rights Profiles
Security Questions
Caselog
Files
ARC Handbook
ARC Process Proposal
Goals
Introduction to the ARC message for project teams
Responsibilities
Case Publishing Tool Information
Chartering a Consolidation
Template for interface "contract"
Template for ARC Project creation
Template for ARC Opinion
10 Questions
Reference: Sun’s current internal ARC process
ARC Policies
Install Time Security
Network Install-Time Security
Plugable Authentication Modules
Service Management Facility (SMF) usage
Audit Policy
FMA Event Protocol
Recommended Installation Locations for Solaris-compatible Software Components
Interface Taxonomy
Library and Shared Object Requirements
Obsolete and the EOF process
Release Taxonomy
Secure - By Default
Packaging rules for system extensions (Shared and sharable components)
Projects
Testing area for automated scripts
OpenSolaris Developers
OpenSolaris Distros
OpenSolaris Users


| 028:087 Khan | : |
And let them not turn you (O Muhammad SAW) away from (preaching) the Ayat (revelations and verses) of Allah after they have been sent down to you, and invite (men) to (believe in) your Lord [i.e: in the Oneness (Tauhid) of Allah (1) Oneness of the Lordship of Allah; (2) Oneness of the worship of Allah; (3) Oneness of the Names and Qualities of Allah], and be not of Al- Mushrikun (those who associate partners with Allah, e.g. polytheists, pagans, idolaters, those who disbelieve in the Oneness of Allah and deny the Prophethood of Messenger Muhammad SAW). |
| 028:087 Maulana | : |
And let them not turn thee aside from the messages of Allah after they have been revealed to thee, and call (men) to thy Lord and be not of the polytheists. |
| 028:087 Pickthal | : |
And let them not divert thee from the revelations of Allah after they have been sent down unto thee; but call (mankind) unto thy Lord, and be not of those who ascribe partners (unto Him). |
| 028:087 Rashad | : |
Nor shall you be diverted from GOD's revelations, after they have come to you, and invite the others to your Lord. And do not ever fall into idol worship. |
| 028:087 Sarwar | : |
Let them not prevent you from following the revelations of God after they are revealed to you. Call (mankind) to your Lord and do not be a pagan. |
| 028:087 Shakir | : |
And let them not turn you aside from the communications of Allah after they have been revealed to you, and call (men) to your Lord and be not of the polytheists. |
| 028:087 Sherali | : |
And let them not turn thee away from the Signs of ALLAH, after they have been sent down to thee; and call mankind to thy Lord, and be not of those who associate partners with HIM. |
| 028:087 Yusufali | : |
And let nothing keep thee back from the Signs of Allah after they have been revealed to thee: and invite (men) to thy Lord, and be not of the company of those who join gods with Allah. |
Concepts/Themes Covered: أركان الإسلام > التوحيد > الشرك والمشركون > النهي عن الشِرك والوعيد عليه Pillars of Islam> Islamic> Polytheism and the Polytheists> The Inhibition of Polytheisms and the Threat Against it أركان الإسلام > (محمد (صلى الله عليه وسلم > تأييد رسالته Pillars of Islam> The Blessed Muhammad(PBUH)> Supporting his Message أركان الإسلام > (محمد (صلى الله عليه وسلم > مخاطبة الله إياه Pillars of Islam> The Blessed Muhammad(PBUH)> Allah's Address to Him(PBUH)
This tool uses eight English parallel translations for the Holy Quran imported from Mr. Clay Smith. You can also visit Qurany Concepts for browsing the Quran themes or topics. If you want to search the Holy Quran for keywords, please visit Qurany Keywords.


Open this link on your mobile phone or type in http://neat-streak.com/ on your phone's web browser.
You will see the following screen:
Touch the Get Started button. You will see the account creation screen
Type you name into the "What's your name" box
Type your phone number, eg<PHONE_NUMBER>, into the "Your phone number?" box
Hit the Next button
You will see the screen with your name at the top
Type a password into the "create a password" box
Type the same password into the "confirm password" box
Hit the Next button
You now have a CleanSlate account
The dashboard contains the cleaning lists for all your clients. If you have just created an account,
there will be no existing lists.
To create a new list, hit the Create New List item in the dashboard
When you hit Create a New List item in the dashboard screen, you will see a new screen with a section for each room
and for the client's information.
Hit the name of a room to open the default cleaning list for that room
To select which tasks should be done, touch each item you want to include or touch "select all" to include all the items...
A selected item will become highlighted.
To add a new item not listed, go to the text box at the bottom of the list and type a description of the new task.
Then hit the Save button.
Continue on through each room that your client wants you to clean and select the relevant tasks.
Tap the "plus" sign to add another room
To add notes, touch "Notes" and type in your notes in the text box then hit the Save button.
To enter your price, tap "Cost" and enter your price in the text box the hit the Save button.
When all cleaning tasks have been selected, you can send the list to your client by tapping the "Send" button.
If you have not already filled in the client's contact information, you will be brought to the section where you
can fill in that information so that the new list can be sent to the client in a text message.
Fill in your client's name, phone number and address and hit the Save button.
Then return to the bottom of the screen and tap the "Send" button.
The button should change to "Sent!"
You can return to the dashboard where you can see your new list.
When you have sent the list, your client should receive a text message like
the following example with the agreed cleaning list.
When your client clicks on the link, they should see the new list along with your
note, and requested price if you provided any.
Your client can then also click on each room to view the agreed tasks
To delete a cleaning list, go to the dashboard to view your cleaning lists. Hit the minus symbol
to the right of the list you want to delete.
You will see a prompt asking you if you are sure you want to delete this list
Hit OK to delete.
If you already have an account, hit the Sign-In button
You will be taken to the following screen
Fill in your phone number and password then hit Sign-In to go to the dashboard.
If you forgot your password, hit Forgot password at the bottom of the screen.
You will be taken to the following screen
Type in your phone number and hit the Send reset code button.
You will receive a reset code in a text message and see the following screen
Enter the code from the text message and your new password
Enter the same password in the Confirm password box
Hit the Reset button
You will return to the dashboard screen.


| probability_trans {scales} | R Documentation |
Probability transformation
probability_trans(distribution, ...) logit_trans() probit_trans()
distribution |
probability distribution. Should be standard R abbreviation so that "p" + distribution is a valid probability density function, and "q" + distribution is a valid quantile function. |
... |
other arguments passed on to distribution and quantile functions |
plot(logit_trans(), xlim = c(0, 1)) plot(probit_trans(), xlim = c(0, 1))


"Twenty years from now you will be more disappointed by the things that you didn’t do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover." - Mark Twain
"The secret of getting ahead is getting started." - Mark Twain
"...for better is a neighbour that is near than a brother far off." - Proverbs 27:10


Sunny Deol to arrive in Pakistan tomorrow
by Adnan LodhiLAHORE: Bollywood actor Sunny Deol will arrive in Pakistan on Saturday to attend the inauguration ceremony of the Kartarpur Corridor.
Confirmation of the actor’s arrival in Pakistan was also given by Chief Minister Captain Amarinder Singh of India’s Punjab on Thursday, a source informed The Express Tribune.
The actor turned politician is a BJP lawmaker from India’s Gurdaspur district.
Several Indian media outlets also reported that the Indian Prime Minister’s Office has allowed Punjab Congress Leader, Navjot Singh Sidhu, to visit Pakistan and take part in the Kartarpur Corridor opening ceremony.
The leader had sought permission from the external affairs ministry to attend the event, after receiving an invitation by Prime Minister Imran Khan.
Two days ahead of the inauguration of the Kartarpur corridor, India claimed on Thursday that contradictory reports have been coming from Pakistan, with regards to whether Indians will require a passport to visit the Darbar Sahib shrine.
However, the Indian Ministry of External Affairs (MEA) spokesperson, Raveesh Kumar, told India Today that an agreement had been signed between the two countries, finalising the modalities of the visits and added that India will follow suit.
“Conflicting reports are coming from Pakistan. Sometimes they say passport is needed and sometimes they say it is not required. As of now, there is a bilateral agreement which specified required documents,” he said.


Welcome to Epic Goose!
First, you will answer a couple brief questions about yourself and you'll see your personalized story play out in our storybook.
Here are a few things to know about Epic Goose:
If you prepared to see where your path leads within our story, "Goblin Market", continue on below:
"Don't look" cried . ", we mustn't look at goblin men!" taking care to cover her eyes to lest she give in to her own curiosity. ignored 's caution and, in an excited whisper, described to her companion each odd and fantastic creature as it came into view. They were men, of a sort; most were quite small and had animal features rarely seen in those who walked on two legs. Some had tails and others pointed noses, some were plumed in feathers, others covered in quills. In their paws and hands, they carried baskets and shiny plates weighed down with brightly colored and unfamiliar fruit.
What do you do:
Path Left: Run
Path Right: Stay
Horrified, broke and, sticking her fingers in her ears, closed her eyes and ran. too curious to heed the fear of , stretched up onto her toes to better see the troop of merchantmen.

The noisy assemblage slowed to a stop before , throwing glances between themselves and smiling at unknown brotherly pranks. As one, they revealed their wares, placing their baskets on the green moss and hoisting heavy golden plates dripping with brightly colored fruits. Cajoling, each offered their wares.
Path for :
Path left: Speak to the Goblins
Path Right: Stay Silent
Politely, explained that she did not have any money and would not be able to purchase any of the beautiful fruit. With the luck of the sweet-toothed, the goblins suggested a different price:
"You have much wealth upon your head,
Buy from us with a curl."
She clipped a lock and paid in full, after which she, shyly at first, accepted a beautiful . Before long, she was gorging herself on fruit globes beyond description.
Finally, not knowing if it was day or night, tossed aside the empty rinds and, on an impulse, gathered up one of the seed kernels before turning for home.
The sisters met at the gate, concern making 's words harsh. "Where have you been? It's much to late for anyone to be in the woods alone." reminded of the neighbor, Jeanie, who had dallied with the goblin men one day. Engaged to be married, she died a maid obsessed with finding the goblin men ever after.
"Sought them by night and day,
Found them no more, but dwindled and grew grey;
Then fell with the first snow,
While to this day no grass will grow
Where she lies low:"
"Nevermind that," said , ", you will not believe what I have seen!" told of the lovely fruit she had eaten. Even now, in the retelling, hungered for the fruit which only just now left feeling uncomfortably full. Pitying for missing the rare treat, promised to go the next day and bring back some of the fruit to share.
Rising early the next morning, and set to their daily chores. was bright and cheerful in her work, but was distracted, worn, and longing for nightfall. Finally, the day began to wind down just as the two went to fetch water from the reedy brook. The sunset threw shadows on the distant mountain crags, signaling the time for return to home and safety, but loitered and delayed. She was looking for some hint of the customary herd of figures to come racing, whisking, tumbling, hobbling out of the glen, but not a single paw or whisker was to be seen.
Anxious, urged:
"O , come;
I hear the fruit-call but dare not look:
You should not loiter longer at this brook:
Come with me home."
felt cold fall over her as she realized that alone could hear the goblin cry, "Come by our fruits, come buy." Never again would she taste the marvelous fruit and her heart seemed to creak with longing like old wood.
Home again, crawled to bed, but sleep would not come. Long after had fallen into rest, lay awake, tortured with hunger and gnashing her teeth at the memory of need unfulfilled. Each night, traded sleep for tears and every minute would listen for the call that would never come.
One day, recalled the kernel-stone, secreted in her pocket following that feverish feast. In desperation, she placed it in a little pot and watered it with her ever-flowing tears.
"She dream'd of melons, as a traveller sees
False waves in desert drouth
With shade of leaf-crown'd trees,
And burns the thirstier in the sandful breeze."
No longer would tend to her chores or eat, her locks seemed to grey, and her days passed sitting listlessly in the chimney-nook.
Heart aching for her sister, 's distress further increased by the now morning and night cry of the goblins' "Come buy our orchard fruits, Come buy, come buy." Finally, the day came when seemed to be leaving this world and had to act. Pocketing her silver penny, she kissed and set out at twilight to find the market.
"Laugh'd every goblin
When they spied her peeping:
Came towards her hobbling,
Flying, running, leaping"
The -faced and -faced, - and -like, snail-paced in a hurry, and the -voiced surrounded her, stretching up panniers and plates of jewel-like fruits and unearthly delights.
"Good folk," said . Tossing them her silver penny, held out her apron and bid them "Give me much and many, all that my penny will buy." Unlike merchants of the human sort, the goblins did not seem keen to accept 's proposed exchange.  After all, their wondrous fruits were ripe only fleetingly and would rapidly spoil if not presently enjoyed.
Path for :
Left Path: Buy the Fruit
Right Path: Eat the Fruit
"T"hank you," said "But one waits at home alone for me... If you will not sell me any of your fruits, then give me back my silver penny." The once magnanimous smiles and cajoling voices turned hard and sharp, calling her 'proud' and 'uncivil'. Wagging tails and purring transformed into tail lashing and snarls as they began to jostle and crowd her. Claws raked at her and tore her gown, small paws pinching her black as ink, as the horde attempted to force upon her that which they previously tried to beguile.
Having expected no less,
utter'd not a word;
Would not open lip from lip
lest they should cram a mouthful in:
But laugh'd in heart to feel the drip
Of juice that syrrup'd all her face,
The torment went on and on, until the cock crowed his morning warning and, exhausted by her resistance, the goblins flung back her penny and dispersed. Some sank into the ground like worms, some dived into the brook, others flew away on the gale and the last disappeared into the distance.
Aching, limbs stinging, and skin tingling, snatched up her penny and tore through the forest back to . Her heart was so light with joy and hope, as she flew home she laughed inside. "!" she cried as she ran up the garden. Calling for her sister to come and kiss her fruit stained cheek:
Squeez'd from goblin fruits for you,
Goblin pulp and goblin dew.
Horrified, , startled up from her chair and in fear that had doomed herself for the sake of her sister, tore at her greying curls. Crying once again, kissed 's cheeks repeatedly, until her lips began to scorch. The second taste of the fruit was a wormwood feast, and a fire flew through her blood as life returned to . Light danced back into her eyes, the grey fled from her locks, and innocent laughter returned to her voice.
Long years later, when both had children of their own, they would tell the story of the dangers of the woods and how a sister would stand fast in deadly peril to save the other. One cannot prevent the temptations in life, you can't keep the goblins from crying "Come Buy, come buy," but neither must you heed it.
Horrified, broke and, sticking her fingers in her ears, closed her eyes and ran. too curious to heed the fear of , stretched up onto her toes to better see the troop of merchantmen.

The noisy assemblage slowed to a stop before , throwing glances between themselves and smiling at unknown brotherly pranks. As a one, they revealed their wares, placing their baskets on the green moss or hoisting heavy golden plates. Cajoling, each offered their wares.
 Steps heavy with shame and dread she made the long slow walk out of the glen and up the garden path. Seeing her, climbed from her chair, and clutching her wan face with thin hands, called:
“, , have you tasted
For my sake the fruit forbidden?
Must your light like mine be hidden,
Your young life like mine be wasted,
Undone in mine undoing,
And ruin’d in my ruin,
Thirsty, canker’d, goblin-ridden?”—
Upon reaching her, collapsed in her arms, following her sister into tears just as, weeks later, she followed her into the grave. Both were buried at the edge of the woods where, years later a grew. Those who remember the tale of the two sisters say the fruit is cursed and all shun the eating of it.
Clutching her empty apron between her sticky fruit-stained hands, fought back a wave of despair. She had failed to obtain the fruit that would free from the curse that beset her. Unable to return home bereft of that last hope, did not know what to do or where to go. Again, the night breeze carried the cry ”Come buy, come buy” and, turning slowly on her heel, followed it into the dark forest.
Frightened almost past bearing, but loathe to leave her less stalwart sister, , in the path of the eerie procession, marshaled her fear. Tightly entwining her fingers with those of 's she dropped her eyes to the mossy path and half-walked, half-dragged them both toward the safe harbor of home. Curious, but unwilling to vex her sister, , allowed herself to be stolen away, but not without much craning of her neck to spy the assembled crew. , resolutely pledged that she would take care to turn home from fetching water at an earlier hour in days to come.
Whether her shyness grew from her lack of money, or was awe of the strange coterie who addressed her, did not reply. Smiling politely with eyes cast to the edge of the moss at her feet she gave a brief shake of her head. Denying their pretty words and obsequious manners, would not look raise her head nor speak.
As they filed away into the deep forest, the last of their number, a small, -faced goblin, scrabbled upon the uneven bank. One perfect escaped from the basket balanced on his head and rolled down the hill where it came to a stop at 's' foot.
Path for :
Path left: Give Sister Fruit
Path Right: Eat the Fruit
The goblin's song was still echoing in her ears as snatched up the and ran homewards. She reached the end of the woods where her home, lit by lantern and candle, was visible in the deepening twilight. pulled out the fruit and ate it. It was beyond description, this fruit from an unknown orchard; sweeter than honey in the rock and stronger than any wine brewed by man. She savored each bite and then sucked the juices from her fingers. Pocketing the kernel-stone, she brushed back her hair and walked up the garden path to where her sister, awaited her at the gate.
Path for :
Path left: Go home
Path Right: Go away with the Goblins
Returning home through the woods, met her sister at the garden gate, concern making 's' voice harsh. "Where have you been? It's much to late for anyone to be in the woods alone."
"Nevermind that," said ,", you will not believe what I have seen!" She told her sister of of the weirdling men and the lovely fruit she had seen. Pitying for missing the rare treat, offered her the that had rolled from the goblin merchant's pack. She felt magnanimous in gifting the to promising that she would visit the goblin market the next day and bring back more of the fruit to share.
Driven by her desire to help her sister, was afraid to refuse the hospitality of the merchantmen. Reluctance easily mistaken for shyness, she settled carefully onto the soft moss, smoothing her empty apron over her lap. The goblins surrounded her, offering their multitude of wares.
Chattering like ,
Fluttering like ,
Gliding like ,—
...
Stretch’d up their dishes,
Panniers, and plates
She accepted a and, like a swimmer plunges into a chilly lake, bit into the sweet flesh lest she change her mind. That bite led to a second and on and on as her hosts placed their strange harvest before her. Gone were her thoughts of home and , gone was her sense of day and night, stolen away along with her plan to hide a in the folds of her apron. Hands sticky and mouth aching, thought and memory slowly returned and realized she was alone. Her companions were not long departed as she could hear their song in the woods before her.
Path for :
Path left: Return Home
Path Right: Stay with the Goblins
Uuanware of from where the came, and unwilling to refuse the gift of a beloved sister, ate the . The fruit was unparalleled in sweetness, unlike anything had ever eaten.
She never tasted such before,
...She suck’d and suck’d and suck’d the more
Fruits which that unknown orchard bore;
She suck’d until her lips were sore;
Over the course of several days, , became listless, no longer taking joy in simple work. Her eyes dulled, her hair greyed, and food no longer held any interest. As watched, her sister faded in front of her. Fretting that the cause was none other than her gift of the goblins' , she returned each night to the glen at twilight, straining to hear the goblin's cry, "Come buy, come buy!" but it never came.
As the first snow fell, so did , leaving her sister, bereft. On the twilight of day after her sister's death, wept by the brook where, over the rattle of her sobs, she one again caught the familiar tune. Faintly, she could hear the market-call blowing on the new winter breeze: "Come buy, come buy..."


Make Your Own CV
Data Section
Full Name
Address
Contact Number
Email Address
Objective Section
Objective :
Education Section
Matric Board
Year
Program
Inter
Year
Program
Resume
Objective
Education
Inter
:
in
from
Matric
:
in
from
Next


Thymeleaf - Bootstrap Pagination
Home
(current)
About
Services
Contact
ID
Title
Body
id
title
body
Previous
Next


Babies have eyes, nose, ears, skin to sense the world around them.
AI have Camera sensors, Microphones, tactile sensors, etc to sense the world around them.
Input
Data
Learning
Mistakes
Output
Know your AI
What is AI ?
Build your AI
Build your AI
Ethical problems in AI
Will AI take over the world?
Comparing Human
babies and AI


Give us your booking details and we will get in touch with as soon as possible.
2 Schochet St
Parys Industria, Parys
9585
South Africa
Call Anytime
27 56 817 1123
or send us an e-mail
partuma.lodge@gmail.com


In this Mass, the
colour red is used.
ENTRANCE ANTIPHON
I know the one in whom I have believed and I am sure that he, the just judge, the mighty, will keep safe what is my due until that day.
The GLORIA is said. (English, Latin)
COLLECT
Lord God, who in a wondrous way chose the blessed Apostle Paul to preach the Gospel, grant, we pray, that the whole world may be imbued with that faith which he brought before rulers and nations, for the unceasing growth of your Church. Through our Lord Jesus Christ, your Son, who lives and reigns with you in the unity of the Holy Spirit, one God, for ever and ever.
PRAYER OVER THE OFFERINGS
As we celebrate the divine mysteries, O Lord, we pray, may the Spirit fill us with that light of faith with which he constantly enlightened the blessed Apostle Paul for the spreading of your glory. Through Christ our Lord.
Preface of the Apostles I or II
COMMUNION ANTIPHON
I live by faith in the Son of God, who has loved me and given himself up for me.
PRAYER AFTER COMMUNION
Grant lord,
to those refreshed by communion in the Body and Blood of your Son, that Christ himself
may be life to us, that nothing may separate us from his love, and that,
attentive to the teaching of the blessed Apostle Paul, we may walk in charity
with our neighbour. Through Christ our Lord.


Rotation 10: Raspberry Pi
Project Description:
This rotation, we did Rasberry Pi. This was another electronic circut with a bread board and Rasberry Pi but this was more of electronic computing. I found this process more fun than the other ones because of the computer porgrams. Programs like sketch and python are important because they translate the code of the computer into the code of the Rasberry Pi. My favorite porject was coding the Sense Hat into colors and patterns we wanted. I made it scroll my name, made a smiley face, and a checker board. We also made it blink on and off in colors we wanted. I found this specfic process very fun and creative. I also liked the camera because I love taking pictures but unfortunately I missed most of the camera stuff.


3 references to Unknown
System.Management.Automation (3)
engine\NativeCommandProcessor.cs (3)
71
MinishellStream ms = MinishellStream.
Unknown
;
1849
MinishellStream stream = MinishellStream.
Unknown
;
1855
if (stream == MinishellStream.
Unknown
)


 You may go ahead and log in now.
Log in


Title
Body
This is Article Preview This is Article Preview This is Article Preview This is Article Preview This is Article Preview This is Article Preview This is Article Preview This is Article Preview This is Article Preview
confirm
edit


--- title: Slip System Analysis in \(\alpha\)-Alumina last_updated: 05-Oct-2022 sidebar: examples_sidebar permalink: SlipSystemAlumina.html folder: examples toc: false ---
of Materials Engineering, Germany
The following EBSD maps has been measured by Ruben Wagner TUBAF, Institute of Materials Engineering, 2022 within the project SFB 920. It shows an alumina inclusions in 42CrMo4 steel after nanoindentation.
{% highlight matlab %} % set crystal symmetry cs = crystalSymmetry.load('Al2O3-Corundum.cif'); % set plotting convention setMTEXpref('xAxisDirection','east'); setMTEXpref('zAxisDirection','intoPlane'); % import data ebsd = EBSD.load('K1_C_16_EBSD_original_bc.txt',... {'notIndexed',cs,'notIndexed'},'interface','csv','silent'); % rotate the data in the right reference frame rot = rotation.byEuler(90*degree,180*degree,0*degree); ebsd = rotate(ebsd('indexed'),rot,'keepXY'); {% endhighlight %}Looking at the raw data we observe several neighbouring measurements that are exactly 180 degree rotated with respect to each other. This is indicated by color coded grain boundaries. It is suspected that this misorientation occurs as the EBSD system has a hard time to distinguish the Kikuchi pattern of two orientations that differ by a rotation about the c-axis by 180 degree.
In order to correct for this misindexiation we proceed as follows
# Identify grain boundaries due to pseudo symmetry # Merge grains with common pseudo symmetry grain boundaries and compute the dominant orientation of the merged grains # Correct the EBSD data according to the pseudo symmetry
1. Identify boundaries between pseudosymmetric grains
{% highlight matlab %} % all Corundum Corundum boundaries gB = grains.boundary('indexed'); % define the pseudo symmetry pseudoSym = orientation.byAxisAngle(cs.cAxis,180*degree); % allow for a three 3 degree threshold ispseudoBnd = angle(gB.misorientation,pseudoSym)<3*degree; {% endhighlight %}2. Merge grains with common pseudo symmetry grain boundaries This results is two big grains as visualised below
{% highlight matlab %} [grains, parentId] = grains.merge(gB(ispseudoBnd),'calcMeanOrientation',... @(g) updateOri(g,pseudoSym)); plot(grains,cKey.orientation2color(grains.meanOrientation)) {% endhighlight %}3. Correct the EBSD data according to the pseudo symmetry
{% highlight matlab %} % find all EBSD data which differ by the computed grain orientation by % about 180 degree flipPseudo = ~(angle(ebsd.orientations,grains(parentId(ebsd.grainId)).meanOrientation)> 10*degree); ebsd(flipPseudo).orientations = ebsd(flipPseudo).orientations * pseudoSym; cKey.inversePoleFigureDirection = zvector; plot(ebsd,cKey.orientation2color(ebsd.orientations)) {% endhighlight %}We perform some more data cleaning steps including
Next we compute the the active slip system during pressure in z-direction. The possible dominant slip systems in alumina are described in Mao2011 and 2012 as
{% highlight matlab %} n = Miller(1,0,-1,1,cs,'HKIL'); b = Miller(-1,2,-1,0,cs,'UVTW'); sS = slipSystem(b,n) {% endhighlight %} {% highlight plaintext %} sS = slipSystem (Corundum) U V T W | H K I L CRSS -1 2 -1 0 1 0 -1 1 1 {% endhighlight %}Next we determine the Schmid factor for all symmetrically equivalent slip systems.
{% highlight matlab %} % rotate symmetrically equivalent slip systems into specimen coordinates of % each grain sSLocal = grains.meanOrientation * sS.symmetrise('antipodal'); % compute Schmid factor according Z axis sigma = stressTensor.uniaxial(vector3d.Z); SF = abs(sSLocal.SchmidFactor(sigma)); % sort the slips system according to their Schmid factor from largest to % smallest [SF, reorder] = sort(SF,2,"descend"); reorder = sub2ind(size(reorder),repmat((1:size(reorder,1))',1,size(reorder,2)),reorder); sSLocal = sSLocal(reorder); {% endhighlight %}Finally, we plot the trace of the slip planes together with the slip direction in the EBSD map.
{% highlight matlab %} figure(2) cKey.inversePoleFigureDirection = zvector; plot(ebsdS,cKey.orientation2color(ebsdS.orientations)) hold on plot(ebsd, ebsd.bc,'FaceAlpha',0.3) colormap gray % make the image grayscale hold off order = 1; hold on % visualize the trace of the slip plane quiver(grains,sSLocal(:,order).trace,'color','blue','linewidth',5) % and the slip direction quiver(grains,sSLocal(:,order).b,'color','gray','linewidth',5) hold off {% endhighlight %}


This section is for the technical as it concerns setting up Cozmos rather than using it.
Two Modes
It is important to know that Cozmos has two modes of operation:
-
The first is 'standalone'.
This means that Cozmos runs entirely within a servlet container on its own.
Each time a page is edited and there is no history retained for each previous revision.
- The second is in conjunction with a Subversion repository.
It allows for history to be kept (allowing auditing and rollback).
It also allows for offline editing, though perhaps only for the technical amongst us.
Understanding Sitemesh
Once you've read about Sitemesh which is key to Cozmos you
may want to edit the Cozmos Site decorator. It is in the war file in a folder called 'decorators'.
You can't edit it over WebDAV unfortunately. Simply put Sitemesh transforms all pages presented.
At the broadest level it adds a standard header, left edge and footer to each page.
Sitemesh also applies a default style to all pages decorated. The CSS style is inlined in the decorator.
the default decorator refers to some images that are in '/style/images/' if you are interested.
Changing the style should be quite easy for a web developer.
Any CSS based design sould do.
Cozmos Default Look and feel
The default style used for this Cozmos, is available on the internet separately.
Originally found at http://karenblundell.com/templates/Natural_Fluidity/index.html
it was modified by another at http://www.oswd.org/design/preview/id/2959 which is the version we have used.
The default decorator adds 'tabs' to the top of each page.
As shipped with Cozmos, they are pretty pointless, but they could link to something meaningful.
Tabs like 'products' 'services' and 'contact us' are quite usual.
Similarly, the links in the footer might nor be to your taste so should be replaced.


Sign in to start your session
- OR -
Why not buy a new awesome theme?
User Name - Position Member since


--- layout: default parent: "charts" activePage: "apex-charts" pageTitle: "apexcharts" plugins: ["apexcharts"] ---


Tutorials
ChocolateChip-UI version 3.5.3
Event Management
Events are what brings your app to life. Otherwise it would be no better than a print out of your app. ChocolateChip-UI provides a number of ways for you to add events to your app. The most basic events that it provides are:
- $.eventStart
- $.eventMove
- $.eventEnd
- $.eventCancel
Because you will probably start testing your app in a desktop browser, ChocolateChip-UI provides this interface that abstracts out events for desktop and mobile. On deskop $.evenStart
is a mousedown
event, $.eventMove
is a mousemove
, $.eventEnd
is a mouseup
and $.eventCancel
is a mousecancel
. On touch devices these would be equivalent to touchstart
, touchmove
, touchend
and touchcancel
. On Windows 8 and Windows Phone 8, these will be equivalent to MSPointerDown
, MSPointerMove
, MSPointerUP
and MSPointerCancel
.
You use these just like you would use normal events, except you don't enclose them in quotes:
$.('.button').on($.eventStart, function() {
// Do stuff when the user interacts with the button.
});
With this abstraction you can get a mousedown, touchstart and MSPointerDown event depending on which platform you are on.
On mobile devices there is a 45O millisecond delay from the time the user clicks to the execution of the click event. This results in interactions that feel sluggish and annoying. Many developers there prefer to use either touchstart or touchend events registered on buttons and other interactive controls. There is one problem with this approach: scrolling. If you have content in a scrollable container and attach a touchstart or touchend event, as soon as you try to scroll your content and touch an element with these, you could immediately cause the touch event to execute. This makes it extremely hard to scroll interactive content. To get around this problem, ChocolateChip-UI has a gestures module.
ChocolateChip-UI provides the following gestures: tap
, singletap
, doubletap
, longtap
, swipe
, swipeleft
, swipeup
, swiperight
, swipedown
. You use these just as you would any other event:
$('.list li').on('swiperight', function() {
// perform some action with the user
// swipe to the right on a list item.
});
Instead of using a $.eventStart or $.eventEnd event for your controls in scrollable containers, we recommend you use the singletap event.
The singletap event has a delay of 150 milliseconds, this give sthe user enough time to initiate a scroll event and thus prevent any interaction with items in the scrolling container. Actually, navigation lists specifically use singletaps to register their events. This lets you flick your finger to scroll a navigation list without firing a navigation event. But if you touch a navigation list item and do not scroll, a singletap gets registered and navigation occurs.
Look at the gestures demo in the examples to see how to use them.


Top 5 Songs For Cassie
Rank
Artist
Title
Album
1
Kenny Loggins
Danger Zone
2
Ryan Gosling, Emma Stone
City of Stars
3
Post Malone, Swae Lee
Sunflower
4
Adam Lavine
Lost Stars
5
Robert Lopez
Remeber Me


I'm a front-end developer since 2001
Co-organizer of Piacenza WordPress Meetup
Teacher & IT specialist at Scuola MOHOLE Milano, since 2014
🐶 I have two dachsunds 🐶
I'm NOT so good with JavaScript!
Frontity is a open source framework
to create websites using WordPress and React
with REST API, as a SPA
(Single Page Application).
I've started from the Getting Started , checking to have all that needs in my computer (eg node.js) and installing with CLI.
npx frontity create my-app
This command create a directory called as you want, my-app in this case, with all the necessary files for the project, then we compile for an internal node server with the command:
cd my-app
npx frontity dev
the demo website will start in localhost, with the settings file frontity.settings.js configured like this
api: "https://test.frontity.io/wp-json/"
now you have only to change the name of the demo website with the one you want!
api: "https://MY-WORDPRESS-WEBSITE.COM/wp-json/"
The themes are written in JavaScript - React, no PHP templates, and there are some ready to use, the default Mars-theme and Twenty-Twenty very similar to the WordPress PHP theme with the same name.
For my blog fflab.info I use a custom (child theme) Twenty-Twenty. For fflab.dev with Frontity I tried to repeat that style customizations.
This is some code added by me:
/packages/twentytwenty-theme/src/components/styles/global-styles.js
for the colors of header and footer
#site-header,
.footer-nav-widgets-wrapper,
#site-footer{
background-color: #a00e05;
color: rgb(255, 255, 255);
}
Ok, we can install Frontity on our computer just for test, but to publish it we need a server with server-side JavaScript.
I've used Vercel as free hosting and I bought a domain too (I like .dev name!).
Vercel have a CLI to install a Frontity application.
After a free registration in Vercel follow this documentation
Fast tour in my Vercel dashboard
SECURITY: limit REST API access to the node server or exclude /user
THEME: create a personal theme
ADD-ONs: custom post type and widgets
Web slides powered by Reveal.js | https://fflab.github.io/pcmeetup-frontity/
See my post about Frontity (italian) here FFLAB


Supreme Court refuses to hear opioid case involving OxyContin makers
by Sommer BrokawDec. 9 (UPI) -- The U.S. Supreme Court declined to hear a case Monday that accused Purdue Pharma of moving billions of dollars in an effort to shield them from a spate of pending lawsuits over the popular opioid painkiller OxyContin.
The state argued in the suit Purdue and its owners, the Sackler family, has transferred about $6 billion over the past decade, which it says violates a fraud statute.
The high court refused to hear the case without comment.
Purdue Pharma filed for Chapter 11 bankruptcy in September as part of a deal valued at $10 billion and included $3 billion from the Sackler family to settle more than 2,000 opioid lawsuits.
Although a bankruptcy judge granted the Sackler family temporary legal protection, the state argued, it didn't apply to its appeal to the Supreme Court.
Purdue Pharma is facing lawsuits in nearly every state, accused of fueling the U.S. opioid crisis for profit by aggressively marketing the drugs while downplaying the risks.


To crawl the application, Crawljax needs to know which elements it should click.
| The properties for crawling the can be set with CrawlSpecification | CrawlSpecification crawler = new CrawlSpecification("http://www.google.com"); |
| The set HTML elements that Crawljax should click can be set with click() in which the user specifies which tags should be clicked. | crawler.click("a"); |
|
The HTML elements that Crawljax should not click can be set with dontClick(). This set of HTML elements is excluded from the set inferred with click(). |
crawler.click("a").withAttribute("class", "noclick");; |
OptionsThe set of HTML elements that should be included/excluded while crawling can be specified in detail with options. The options specify which criteria the HTML element should satisfy. |
|
The textual content of the elementswithText(String text)Only one text can be specified. |
crawler.click("span").withText("Foo"); |
Attributes of the elementswithAttribute(String attributeName, String value)Multiple attributes can be specified |
crawler.click("a").withAttribute("class", "foo"); crawler.click("div").withAttribute("id", "bar") .withAttribute("class", "navigation");; |
Location of elements.underXpath(String xpathExpression)With this method one can specify that an element should always be under an other element. This is done via specifying the parent element with an xpath expression. If the xpath expression does not return a node, the HTML element is not included. Only one location can be specified. NOTE: specify the tagnames in uppercase and attributes in lowercase |
crawler.click("div").underXPath("//DIV[id='footer']"); |
Conditionswhen(Condition...conditions)Conditions can be specified which should be satisfied at the moment Crawljax wants to click on the element. |
UrlCondition onLoginPage = new UrlConditions("#login"); crawler.when(onLoginPage).click("a").withText("Login"); |
CombinationsDifferent combinations can be used. |
crawler.click("div").underXPath("//DIV[id='footer']") .withText("Info"); crawler.click("button").withText("save") .withAttribute("class", "contactform"); |


Cape Coral offices damaged by vehicle collision Friday morning
by WFTX Digital TeamCAPE CORAL, Fla. -- We're working to find out more about a vehicle versus a building in Cape Coral Friday morning.
It happened on Cape Coral Parkway near Vincennes Street.
That's where a vehicle crashed into the front of a financial services business that faces the street.
There is no word yet on whether there were any injuries, but a sign posted at the site indicates that two front offices are closed due to damages to the building.


Before Change
lengthscale_prior = _deprecate_kwarg(kwargs, "log_lengthscale_prior", "lengthscale_prior", lengthscale_prior)
super(Kernel, self).__init__()
if active_dims is not None and not torch.is_tensor(active_dims):
active_dims = torch.tensor(active_dims, dtype=torch.long)
self.register_buffer("active_dims", active_dims)
self.ard_num_dims = ard_num_dims
self.batch_size = batch_size
self.__has_lengthscale = has_lengthscale
After Change
(i.e. :math:`\Theta` is a constant diagonal matrix).
This is controlled by setting `has_lengthscale=True`.
* ARD: Each input dimension gets its own separate lengthscale
(i.e. :math:`\Theta` is a non-constant diagonal matrix).
This is controlled by the `ard_num_dims` keyword argument (as well has `has_lengthscale=True`).
In batch-mode (i.e. when :math:`x_1` and :math:`x_2` are batches of input matrices), each
batch of data can have its own lengthscale parameter by setting the `batch_size`