From: R. Steve McKown Date: Wed, 16 Dec 2009 15:49:35 +0000 (-0700) Subject: Clean up the text on the oss web pages. X-Git-Url: https://oss.titaniummirror.com/gitweb?p=oss-web.git;a=commitdiff_plain;h=d848b801a6fa1fad501fb8b58a7ed8dd3dc5e359 Clean up the text on the oss web pages. --- diff --git a/in/aptrepo.md b/in/aptrepo.md index 95f905b..a505740 100644 --- a/in/aptrepo.md +++ b/in/aptrepo.md @@ -16,16 +16,17 @@ Karmic. ## Step 1 - Add the backports repository -Ubuntu Hardy users need to activate the hardy-backports repository to use our -`cp210x-module-dkms` package. Ubuntu Karmic users can skip this step. Note, -you can also activate hardy-backports from the GUI. +Ubuntu Hardy users need to activate the hardy-backports repository, as our +`cp210x-module-dkms` package requires a newer dkms than is available otherwise. +Ubuntu Karmic users can skip this step. You can also activate hardy-backports +from the GUI. sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak cat <<+EOF+ | sudo tee -a /etc/apt/sources.list deb http://us.archive.ubuntu.com/ubuntu hardy-backports main restricted universe multiverse +EOF+ -## Step 2 - Adding the TMI repository to sources.list.d +## Step 2 - Adding the TMI repository to the sources list cat <<+EOF+ | sudo tee /etc/apt/sources.list.d/tmi.list # TMI repository @@ -36,9 +37,8 @@ you can also activate hardy-backports from the GUI. ## Step 2 - Adding the TMI package key -When you issued `apt-get update` above, you saw a key warning. We solve this -by installing a package from the TMI repository that contains our packaging -key. +When you issued `apt-get update` above, you saw a key warning. Resolve future +key related warning messages by installing `tmi-keyring`. sudo apt-get install --yes --allow-unauthenticated tmi-keyring @@ -46,12 +46,14 @@ You should now verify the installed key. Run the `sudo apt-key list | less` and look for the following two lines, ensuring your output matches that below: pub 1024D/E9BE0373 2009-12-08 - uid TMI Packages + uid TMI Packages + +The email address above is 'com dot titaniummirror at pkgs', in reverse. ## Step 3 - Install packages You can now install packages from the TMI repository. For example: -* Install our [[cp210x]] driver: `sudo apt-get install cp210x-module-dkms` - * Install our [[tinyos]] development suite: `sudo apt-get install tinyos` + +* Install our [[cp210x]] driver: `sudo apt-get install cp210x-module-dkms` diff --git a/in/cp210x.md b/in/cp210x.md index e3ac958..e6b1f76 100644 --- a/in/cp210x.md +++ b/in/cp210x.md @@ -9,24 +9,22 @@ Repositories: [cp210x](http://repo/gitweb/?p=cp210x.git;a=summary), [[aptrepo]]. [Silicon Labs](http://www.silabs.com) sells a single-chip USB to UART bridge, the [cp210x](http://www.silabs.com/products/interface/usbtouart/Pages/default.aspx). -For windows platforms, Silicon Labs offers manufacturing support, in the form -of a DLL and a small utility, to set the various USB descriptor fields, port -configurations, etc. They also offer a DLL and example programs showing how -to manipulate the GPIO pins available on the cp2103 part. +For windows platforms, Silicon Labs offers manufacturing support for setting +the various USB descriptor fields, port configurations, etc. They also offer a +DLL and example programs showing how to manipulate the GPIO pins available on +the cp2103 part. -With approval from Silicon Labs, TMI has modified their reference Linux driver -to support all of the features their Windows DLLs and utilities provide. This -is accomplished via extended ioctl() calls from the kernel cp210x driver, and -various utilities and sample code. This code is really invaluable for those -working on hardware device designs using the cp2103. The code is released +With support from Silicon Labs, TMI has modified their GPLv2 licensed reference +Linux driver to support all of the features their Windows DLLs and utilities +provide. This is accomplished via extended ioctl() calls from the kernel +cp210x driver, and various utilities and sample code. This code is invaluable +for those working on hardware designs using the cp2103. The code is released under the GPLv2. -TMI sent the modified code back to Silicon Labs, who supposedly had someone -in-house (or contracted) who regularly works with the maintainer of the cp210x -(formerly cp2101) driver in the mainline Linux kernel. That was over a year -ago, and the code hasn't shown up. We will be working with the maintainer -directly to get this code available. In the mean time, it is available -[as source](http://repo/gitweb/?p=cp210x.git;a=summary) and from our -[[aptrepo]]. The `cp210x-module-dkms` package in the APT repository has been -tested on Ubuntu Hardy and Karmic systems with both 32 and 64 bit x86 -(Intel/AMD) processors. +TMI completed these driver changes of a year ago and has since been maintaining +it. Silicon Labs was to push these changes through to the mainline kernel, but +this clearly has not happened yet. TMI will be working directly with the kernel +cp210x maintainer to investigate incorporating our changes. Meanwhile, TMI +will continue to maintain its branch of the cp210x driver. The +`cp210x-module-dkms` package in the APT repository has been tested on Ubuntu +Hardy and Karmic systems with both 32 and 64 bit x86 (Intel/AMD) processors. diff --git a/in/firmware.md b/in/firmware.md index fcc13b0..d688f37 100644 --- a/in/firmware.md +++ b/in/firmware.md @@ -8,7 +8,8 @@ Tarball: [gpl](http://www.titaniummirror.com/gpl). TMI has developed a fault tolerant internetworking platform composed of a set of proprietary cluster, event and web management applications running atop a GNU/Linux open source platform core. Essentially, the core represents a -customized Linux distribution geared specifically for network appliances. TMI's -proprietary code does not link with any GPL components of the core. Some -minor changes have been made to the core components. Those changes are -available [here](http://www.titaniummirror.com/gpl). +customized Linux distribution geared specifically for network appliances. The +proprietary code developed by TMI does not link with any GPL components of the +core and honors the terms of the license. Some minor changes have been made +to the core components. Those changes are available +[here](http://www.titaniummirror.com/gpl). diff --git a/in/git-utils.md b/in/git-utils.md index 31e8f22..fa2068c 100644 --- a/in/git-utils.md +++ b/in/git-utils.md @@ -13,15 +13,15 @@ Read about [GIT](http://git-scm.com) here. Over time, TMI is starting to collect a number of small utilities for git. These are available from our [git-utils](TBD) repository. Each utility has -a man page describing its operation, so we'll only highlight the basics here. +a man page describing its operation. * git-empty-branch. Create an empty branch in a local git repository. -* git-local. Store local branches temporarily in a shared git repository, - probably hosted on a server used by the local development team. git-local - offers upload, download, remove and list operations. +* git-local. Store local branches in a shared git repository under a private + namespace. git-local provides upload, download, remove and list operations. + We use this tool to backup up local commits not yet suitable for pushing into + a local shared branch. -* git-publish-branch. A shell version of a ruby script created by William +* git-publish-branch. A shell version of the ruby script created by William Morgan. See his [git utilities page](http://git-wt-commit.rubyforge.org). - This has been a locally popular utility, and we did not want to see ruby - effectively become yet another pre-requisite for git. + We did not want to have to install ruby just for this one little utility. diff --git a/in/index.md b/in/index.md index a4e999e..f8a75d6 100644 --- a/in/index.md +++ b/in/index.md @@ -5,17 +5,16 @@ ctime: 2009-12-15 # Introduction [Titanium Mirror, Inc.](http://www.titaniummirror.com) (TMI) is a successful -small business in part because we have can leverage the development work of -other talented professionals who have opted to release the product of their -labors as Open Source Software (OSS). Over time, we have made our own changes -to support our business and customers. We publish our work to this website in -case others find our contributions useful. - -Of course, we make an effort to contribute patches to the relevant upstream -maintainers. But it takes time for patches to migrate upstream, and there is -no guarantee that something we find useful is general enough to be incorporated -into an upstream project. For these reasons, we publish this website. +small business in part because we can leverage the development work of other +talented professionals who have opted to release the fruits of their labors as +Open Source Software (OSS). Over time, we have made our own changes to support +our business and customers. On this website, we publish our work in case +others find our contributions useful. # The Projects Select a project to browse from the Navigation panel on the left. + +# News + +This website has not yet been released to the public. diff --git a/in/msp430.md b/in/msp430.md index d342112..e967758 100644 --- a/in/msp430.md +++ b/in/msp430.md @@ -10,9 +10,9 @@ Repositories: [[aptrepo]]. TMI maintains an msp430 toolchain, including [[Ubuntu packages|aptrepo]], which -work with newer members of the msp430 family, such as the popular -MSP430F2618 part and is properly patched for use in -[[TinyOS]] development. The official TinyOS distribution -provides an older msp430 toolchain that does not support some of the newer -msp430 parts. The msp430 toolchain is composed of: binutils, gnu compiler, +works with newer members of the msp430 family including the popular MSP430F2x1x +parts such as the MSP430F2618. This toolchain is properly patched for use in +[[TinyOS]] development. At the time of this writing, the official TinyOS +distribution uses an older msp430 toolchain that does not support these newer +msp430 parts. The msp430 toolchain is composed of binutils, gnu compiler, and libc. diff --git a/in/oss-web.md b/in/oss-web.md index 6b4da20..64caec0 100644 --- a/in/oss-web.md +++ b/in/oss-web.md @@ -5,5 +5,4 @@ ctime: 2009-12-15 Repositories: [oss-web](http://repo/gitweb/?p=oss-web.git;a=summary). -This website is statically generated using [[Webber]] from the source code -link above. +This website is statically generated from the repository using [[Webber]]. diff --git a/in/ovzbpc.md b/in/ovzbpc.md index abfc7c1..9f5bdbe 100644 --- a/in/ovzbpc.md +++ b/in/ovzbpc.md @@ -7,102 +7,28 @@ Repositories: [backuppc](http://repo/gitweb/?p=backuppc.git;a=tree), [ovz](http://repo/gitweb/?p=ovz.git;a=tree), [esata](http://repo/gitweb/?p=esata.git;a=tree). -# OpenVZ - -TMI hosts its compute resources on DELL PE1800 servers configured as a cluster -of [OpenVZ](http://www.openvz.org) Hardware Nodes (HN's), which host multiple -OpenVZ Virtual Environments (VE's). Open VZ VE's are virtual machines -virtualized at the operating system. The downside is that all VE's must be -Linux instances capable of running on the OpenVZ kernel. The upside is that -far more OS virtualized instances can reside on a given set of hardware -compared to virtualizers like VMWare and Xen, which (para-)virtualize hardware. - -# BackupPC - -TMI uses [BackupPC](http://backuppc.sourceforge.net) for backup services across -our company, including notebooks, workstations and servers (OpenVZ VE's). We -are especially happy with BackupPC and how it is integrated into our server -environment. Each HN is backed up as a separate host, but none of the data -for any VE's it may be hosting. Each VE is also backed up, each as a separate -host. Our HN's use LVM, and our add-on scripts allow for backup of any VE with -minimal downtime. The scripts actually shut down the VE, create a snapshot of -the HN volume on which the VE's filesystem is stored, restarts the VE, -completes the over-the-net BackupPC backup operation, then removes the snapshot. -By shutting down the VE, we ensure the integrity of the backup without -requiring application specific tools like database hotcopy scripts. By using -LVM, the VE downtime is typically less than 90 seconds. We backup every system -every evening. - -# Off-site backups - -BackupPC maintains an on-disk archive of de-duplicated backups for all hosts. -We maintain off-site backups by cloning the BackupPC archive to removable -eSATA disks. For fastest recovery, we run BackupPC in a VE within our -server infrastructure, so what we clone to an external disk is the entire -BackupPC VE filesystem. We also keep a second partition on each removable -disk, which contains, essentially, our HN operating system. eSATA connections -make this backup operation very fast. And because a human must connect an -external drive prior to the backup, that person can also provide the necessary -key that allows the external drive filesystems to be cryptographically secure. -We clone the BackupPC archive once per week, and rotate several external -drives through the off-site location. - -# Recovery - -A word about recovery: great. This combination of technologies allows the -recovery of any system, directory, or file stored within the BackupPC archive -over the network. The data need not be recovered to the same machine from -which it was backed up, nor does it need to be placed in the same directory. -Restore operations are done via a web interface, and the interface does not -have to be accessed from the machine to which the data are to be restored. - -Disaster recovery is also a big plus. The entire TMI infrastructure can be -reconstructed onto new hardware from just one off-site archive drive. - -# TMI code - -TMI maintains a number of code repositories containing scripts, etc. for -integrating OpenVZ and BackupPC. Please be aware that these are formulated -somewhat specifically for our environment. But if you have a similar setup, -they should be usable with minimal massaging. Someday, someone here will take -the time to merge this stuff into a single repo and document it better. - -# BackupPC scripts - -The [BackupPC scripts repository](http://repo/gitweb/?p=backuppc.git;a=tree) -includes: - -* BackupPC_ovz. Installed on an HN, it allows BackupPC to backup from and - restore to any VE hosted on any HN in the cluster. When VE's are migrated - between HN's, the backup configuration does not need to change. - -* Holger Parplies' BackupPC_verifyPool. - -* See the [README](http://repo/gitweb/?p=backuppc.git;a=blob;f=README;hb=HEAD) - in the repository for more information. - -# OpenVZ scripts - -The [OpenVZ scripts repository](http://repo/gitweb/?p=ovz.git;a=tree) -includes: - -* bpcdump. Similar in concept to vzdump. Although fairly general in nature, - we use it only for backing up the BackupPC VE, whose filesystem is on a - private LVM LV (logical volume), to an eSATA drive. - -* bpcbackup. A script that runs from crontab on one or more HN's to launch - the bpcdump program. Since all our HN's are configured the same, each has - an eSATA port and can be used to perform a backup of the BackupPC VE. - -* See the [README.recover](http://repo/gitweb/?p=ovz.git;a=blob;f=README.recover;hb=HEAD) - file for mroe information. - -# eSATA scripts - -The [eSATA scripts repository](http://repo/gitweb/?p=esata.git;a=tree) -contains the esata script, which wraps the `scsiadd` utility for properly -handling esternal drives on the Dell PE1800 and PE1900 platforms. Newer -hardware and better Linux kernel support should someday make scripts like this -unnecessary. See the included -[README](http://repo/gitweb/?p=esata.git;a=blob;f=README;hb=HEAD) file for -more information. +# TMI backup strategy + +TMI hosts its compute resources in [OpenVZ](http://www.openvz.org) Virtual +Environments (VE) running on a cluster of Dell PE1800 servers. The contents +of each VE, as well as the servers hosting them, are backed up using +[BackupPC](http://backuppc.sourceforge.net). Periodically, a clone of the +BackupPC disk archive is made on one of a pool of external eSATA drives, which +are rotated off-site for disaster recovery. TMI has authored a few program +scripts which integrate these backup components. + +* [BackupPC_ovz](http://repo/gitweb/?p=backuppc.git;a=blob;f=README;hb=HEAD) + allows an OpenVZ VE to be backed up and restored via BackupPC without + special configuration of the VE, nor with BackupPC being told on which + hardware node the VE is running. + +* bpcdump and friends support cloning the BackupPC VE to a removeable eSATA + drive for disaster recovery. See [README.recover](http://repo/gitweb/?p=ovz.git;a=blob;f=README.recover;hb=HEAD) + for more information. + +* The [esata](http://repo/gitweb/?p=esata.git;a=tree) wraps the `scsiadd` + utility for properly handling eSATA drives on Dell PE1800 and PE1900 + platforms. Newer hardware and better Linux kernel support will someday make + scripts like this unnecessary. See the included + [README](http://repo/gitweb/?p=esata.git;a=blob;f=README;hb=HEAD) for more + information. diff --git a/in/tinyos.md b/in/tinyos.md index 1046095..03414bb 100644 --- a/in/tinyos.md +++ b/in/tinyos.md @@ -6,17 +6,16 @@ ctime: 2009-12-07 Repositories: [tinyos](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary), [[aptrepo]]. -TMI uses [TinyOS](http://www.tinyos.net) for various data acquisition -applications, and we maintain a modified tree that supports certain features -not available in the official tree. We maintain a -[repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary) containing -our TinyOS tree, in which we also maintain a cogent patchset against the -official tree. +TMI maintains a [TinyOS](http://www.tinyos.net) branch containing certain +features not available in the official tree. The TMI repository contains +code imported from CVS upstream, our internal working branches, and tags +marking a series commits that are a clean patch series of the TMI enhancements +against an official upstream release. * Current patchset tag: patchset/2.1.0-3 -* Build from official release tag: tinyos/2.1.0 -* View the patchset [here](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.0-3). +* Derived from official release tag: tinyos/2.1.0 +* View the latest patchset [here](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.0-3). -Our TinyOS requires a newer [[msp430]] toolchain. A complete TinyOS +The TMI TinyOS code requires a newer [[msp430]] toolchain. A complete TinyOS development environment including a newer toolchain is available for installation from our [[APT repository|aptrepo]]. diff --git a/in/tinyospkgs.md b/in/tinyospkgs.md index f81d415..f6a5240 100644 --- a/in/tinyospkgs.md +++ b/in/tinyospkgs.md @@ -6,75 +6,49 @@ ctime: 2009-12-10 Repositories: [tinyos](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary), [[aptrepo]]. -## Package versioning +# Package versioning The TinyOS packages are built from the TMI [TinyOS repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary). The package version number is of the form `tosver-tmiver`, where `tosver` is the official TinyOS release version on which the code is based, and `tmiver` is the -version of the modifications applied by TMI. - -These version numbers are present in the -[repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary) in the form -of release and patchset tags. For example, the code from which package version -`2.1.0-3` is built is tagged `release/2.1.0-3`. This code is based on the -upstream version `2.1.0`, which is tagged in the repository as `tinyos/2.1.0`. -A clean patchset is tagged `patchset/2.1.0-3`, where the commits between these -two tags represent a clean set of patches that apply the TMI modifications to -the upstream version. - -## Git/CVS issues - -Because CVS and git tags are fundamentally incompatible, we cannot guarantee -that a git repo using `git-cvs` and tracking the upstream CVS repository will -result in the exact same checkout tree state at each tag. We resolve this -issue as follows: - -* TMI tracks the upstream CVS in a git mirror repository updated periodically - via a script using `git-cvsimport`. - -* When TMI wants to rebase its local modifications on a newer version of - upstream TinyOS, it pulls changes in from this mirror git repo into the - [TMI TinyOS repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary) - onto the `upstream` branch. Release tags, such as `release_tinyos_2_1_0_0` - from CVS are also pulled. - -* In git, a new release branch is created at the release tag. In this example, - release tag `release_tinyos_2_1_0_0` is the branch point for the new branch - `release/2.1.0`. - -* The tag `tinyos/2.1.0` is the tag of git tree along the `release/2.1.0` - branch where the checkout of git at `tinyos/2.1.0` exactly matches the - checkout of upstream CVS at `release_tinyos_2_1_0_0`. - - * If the git and CVS tags checkout trees that match at tag - `release_tinyos_2_1_0_0`, then `tinyos/2.1.0` tags that same commit. - - * If the git and CVS checkouts diverge, then the first commit along the new - `release/2.1.0` branch contains the changes necessary to sync git with CVS - at the release tag. This is accomplished by using `git_load_dirs`. This - new commit to the release branch is tagged `tinyos/2.1.0`. - -## Multiple source trees - -TMI TinyOS packages allow for the installation of multiple TinyOS source trees. -This allows us to maintain older programs built against older versions of -TinyOS while simultaneously working on new applications. It also allows us to -compile code against the official TinyOS releases in addition to the TMI -enhanced releases. - -This is accomplished by altering how TinyOS source is installed. The standard -convention is for the TinyOS source tree to be installed on a development -workstation at `/opt/tinyos-2.x`. The TMI packages install the source trees -at `/opt/tinyos/VER`. For example, the official TinyOS 2.0.2.2 source tree -would install at `/opt/tinyos/2.0.2.2`, and the TMI enhanced TinyOS 2.1.0-3 -tree installs at `/opt/tinyos/2.1.0-3`. A sourceable script, -`/opt/tinyos/tinyos.sh`, is used to set which source tree is used by the -TinyOS development tools and build system. The script is also sourced in -the user's profile to provide persistence of settings across logins and reboots. - -Each TinyOS source tree has its own package. Here are the currently available -trees as of this writing: +version of the modifications applied by TMI. Released APT package versions are +associated with tags in the source code repository. Consider the latest +package version, 2.1.0-3, for which these tags exist in the repository: + +* `debian/2.1.0-3-2tmi` is the tag of the 'debianized' code from which the APT + packages version 2.1.0-3-2tmi were built. + +* `release/2.1.0-3` is the tag of the TinyOS code of which + `debian/2.1.0-3-2tmi` is a superset, the latter containing the debian + packaging files. + +* `tinyos/2.1.0` is the official upstream release on which `release/2.1.0-3` is + based, the difference being the TMI enhancements. + +* `patchset/2.1.0-3` is the head of a string of commits from the + `tinyos/2.1.0` tag that represent a clean patch series that applies the + TMI enhancements to the official upstream release. + +# Multiple source trees + +Often it is impractical to maintain an older application by porting it forward +to the latest TinyOS version. The TMI approach allows multiple TinyOS trees +to be installed simultaneously, thereby allowing different applications to be +compiled against different TinyOS versions. + +The official TinyOS installs the source tree at /opt/tinyos-2.x. The TMI +version installs source trees at /opt/tinyos/VER. For example, the latest TMI +tree is installed at /opt/tinyos/2.1.0-3. TMI also maintains in its repository +the last few official source trees. At least one must be installed, and the +developer may install others as needed. When installing or upgrading TMI +TinyOS packages via APT, the latest TMI tree package is automatically installed. +Source the script `/opt/tinyos/tinyos.sh` to set the three you wish to use. +Source this script from your login profile with no argument to ensure that your +tree selection is persistent across logins. + +This is the currently available trees as of this writing. You can use the +command shown below to at any time view the available source trees. $ sudo apt-cache search tinyos-source tinyos-source - TinyOS source meta package @@ -83,15 +57,9 @@ trees as of this writing: tinyos-source-2.1.0 - TinyOS source code tree tinyos-source-2.1.0-3 - TinyOS source code tree -At least one tree must be installed, and the latest tree is installed each time -the tinyos packages are installed or upgraded. However, the developer may -keep multiple trees installed if necessary. The APT package upgrade -mechanisms work properly. - -## Installing TinyOS +# Installing TinyOS -To install TinyOS, perform the steps above to configure the TMI repository on -the workstation, then type: +To install TinyOS, perform the steps shown for the [[aptrepo]], then type: sudo apt-get install tinyos diff --git a/in/tmicore.md b/in/tmicore.md index cadbaa5..b599118 100644 --- a/in/tmicore.md +++ b/in/tmicore.md @@ -1,5 +1,4 @@ -title: TMIcore -linktitle: tmicore +title: tmicore parent: TOP ctime: 2009-12-02 @@ -8,9 +7,14 @@ Repositories: [tmicore](TBD). TMI has developed an [[msp430]] target board for low power data acquisition. Its design is not complete yet, but it is (SOON) available under an open source license. The design was created using [Eagle](http://www.cadsoft.de). +It provides a breakout of all uC pins, incorporates a Lithium Ion/Poly charger, +and a USB interface for communications and programming. -We call our target board TMIcore. In actuality, the board shown in the design -is the TMIrws board, which contains at its core the TMIcore design. The PCB -design shows where it can be 'cut' to build a stand-alone TMIcore board. -The full TMIrws board is the heart of a solar powered remote weather station -that reports its observations to an internet server via the cellular network. +The actual design files are for the tmirws board, which is a superset of the +tmicore design. One can trivially derive the tmicore design by simply cutting +the board layout at the inner rectangle. The tmirws design is the heart of an +off-grid solar powered remote weather station that reports its observations to +an internet server via the cellular network. + +TMI enhanced [[tinyos]] contains platform support for both the tmicore and +tmirws variants of this design.