text:
SCons / FromMakeToScons
The SCons wiki has moved to https://github.com/SCons/scons/wiki/FromMakeToScons
Table of Contents
- The SCons wiki has moved to https://github.com/SCons/scons/wiki/FromMakeToScons
- Make looks fine on the surface
- More Make problems
- Conclusion on Make
- Make alternatives
- Build systems
- More Make alternatives: script based build tools
- More build related tools
- General conclusion
Evolution is a slow process. Getting rid of old bad habits is never easy. This article is a critique of the Make build tool. We list its shortcomings and we suggest a few more modern alternatives.
Make looks fine on the surface
The Make build tool is with us for about 20 years. It is somewhat a sad thing to see today complex new projects considering Make as their only choice. I often get the question "What is wrong with Make?". So often that the obvious answer to the question becomes "First wrong thing is the people ignorance about Make limitations with respect to their requirements". As a matter of facts, I will start my critique as a list of wrong beliefs around this classic tool.
Myth 1: Make-based builds are portable
Several Make clones are open-source C software and all build platforms have a Make preinstalled. Make-based builds are known to be portable and they really are compared to some IDE solutions. The problem is that the Make tool, as it was originally implemented, has to rely on shell commands and on features of the file system. These two, the shell and the file system, are notorious sources of platform incompatibilities. By consequence the fact that every system has a Make is probably true but not relevant. The statement "Every system has a shell" is also true. That doesn't mean that shell scripts are portable and nobody claims that. Another problem is the fact that the original Make was lacking some fundamental features and later clones added the missing features in different ways. The obvious example is the if-then-else construct. It is not really possible to build real-life projects without if-then-else. One has to use workarounds. They are based on either the "include" directive or on the conditional macro expansion. In the best case you do get to the desired functionality but you lose the readability of the build description. Anyway, Make-based builds are not portable. They rely too much on features of the surrounding system and Make clones are incompatible with each other.
Myth 2: Make based builds are scalable
Many of us have the experience of expanding a given code base by adding a few source files or by adding a static library. In carefully designed builds, it is not a lot of work to make the new code part of the final product. You just add a short new Make-file in a new directory and rely on recursive call of Make. The problem comes when the project gets really big. In such big projects, keeping the build fast enough is a challenging task. Also changing the binary deployment of the product becomes a complex task, much more complex than what it needs to be. With typical recursive Make, the architecture of the software product is nailed down in the directory structure. Adding or removing one single piece is still OK but other restructuring is much more disruptive. A sad side effect of this is that, over time, developers come to think about the software not as a set of abstract components and their interfaces but as a set of source directories with source code and that builds up even more resistance to change. The speed issues in large builds are well documented in Peter Miller's seminal article: "Recursive Make Considered Harmful" (http://aegis.sourceforge.net/auug97.pdf). When using recursive Make, there is no simple way to guarantee that every component is visited only once during the build. Indeed, the dependency tree is split in memory between several processes that don't know very much about the others. This makes it hard to optimize for speed. Another problem is that Make uses just one namespace and recursion is never easy with only one global namespace. If you want to configure sub targets differently (meaning to pass parameters to Make processes started by Make), you'll get an error prone build set-up. But recursive Make is not the only way to implement Make. You may wonder, if it is harmful, why is it so widely used? One argument that people mention is that recursive Make is easier to set up. This is not a very solid argument. For example, John Graham Cumming demonstrates in a recent DDJ article (http://www.electric-cloud.com/resources/DDJCrossPlatformBuilds.pdf) a simple non-recursive Make system. There is also a more subtle argument in favor of recursive Make. The fact is that it allows developers to use their knowledge about the project to easily start only a smaller part of the build. In non-recursive systems, you can start a smaller part but the system will usually "collect" first all the build descriptions which is slower or has undesired side-effects or both. It is also possible to design and implement systems that are somewhere in between. Some homegrown Make-based systems use clever checks outside Make to avoid starting new Make processes when there is nothing to be built and then act recursively for the rest of the cases. Anyway, for good or bad reasons, the fact remains that Make-based builds scale up painfully.
Myth 3: Make tool is simple and easy
Make tool paradigm is elegant and powerful. I have seen nice experts systems implemented only with Make-files. People like things that are elegant and powerful. Unfortunately, Make implementation is poor and dirty by today standards. Make-files syntax is obscure and, by way of consequence, more difficult then you may think. Make wins hands down the contest for the messiest namespace in all programming tools I have ever seen. File targets and command targets (also known as phony targets) share the same namespace making it close to impossible to build files with certain names. Also the environment shell variables and the Make macros share the same namespace. Make macros are covering both variable and function concepts (like in functional programming languages). Macros can be defined inside the Make-file or on the command line. All these make up for complex scope rules and for some bad surprises for both the novice user and the expert user. Make based builds heavily rely on shell environment variables and this has a lot of other shortcomings as well. The most known is the fact that the build is difficult to reproduce for another user on another build machine. A more subtle issue is that it is difficult to document the build. Most modern systems allow you to ask which are the parameters of the build and which are their meaningful values? Make doesn't help you to provide this feature despite the fact that Make-based builds definitely need it. Even without several sources for variables, one single namespace is still too messy. One namespace means that target platform-wide variables, build machine-wide variables, project-wide variables and individual user customizations are altogether next to each other. Without solid naming conventions, you certainly don't know what you can change without endangering the entire build. Another area of misleading simplicity is the fact that many Make macro's have one letter names. Many Make clones improved on that by introducing more understandable aliases for those names. Of course they did that in incompatible ways so that you cannot take profit of the improvement if you want to keep portability of the build description across Make clones.
Myth 4: Make is fast
Make and many of its clones are implemented using the C/C++ programming languages. They are speed-efficient implementations. Indeed, correctly designed Make based builds show little overhead while building. But, before you enjoy too much the raw speed of Make, you have to remember that fast is not safe and safe is not fast. Because of this fundamental contradiction, you should look suspicious to anyone claiming an amazing speed. Indeed, Make achieves some of its speed by performing only superficial checks. This kind of speed gain strikes back because you'll feel more often the need for complete builds from scratch. There is another way in which Make appears to be fast. Make expects you to know how to build a smaller part of the project that you are currently working on. This strikes back when more time is spent in the product integration across several developers.
More Make problems
Next to the characteristics described above, often considered strong points of Make, there are also a few characteristics that are acknowledged shortcomings of Make. Here is a short list of them.
Reliability issues
Make-based builds are not safe and nobody claims that they are safe. The main reason for this problem is the fact that Make relies on time stamps and not on content signatures in order to detect file changes. In the local area networks, it is frequent that several computers having their own clock device are sharing the file system containing the sources for the build. When those clocks get out of sync (yes, that happens) you may get inaccurate builds, especially when running parallel builds. Moreover, Make takes the approach of not storing any stamp between builds. This is a very bad choice because it forces Make to use risky heuristics for change detection. This is how Make fails to detect that the file changed to another one older than previously (which happens quite often in virtual file systems). Not using content signatures is especially painful when an automatically generated header file is included in all the sources (like config.h in the GNU build system). Complex solutions involving dummy stamp files have been developed in order to prevent Make tool to rebuild the entire project when that central header file was regenerated with the same content as before. An even more insidious safety issue is the fact that Make does not detect changes in the environment variables that are used or in the binary executables of the tool chain that is used. This is usually compensated with proprietary logic in homegrown Make systems, which makes the build more complex and more fragile.
Implicit dependencies
One cannot criticize the Make mechanism for implicit dependencies detection for a good reason: Make doesn't have such mechanism. In order to deal with the header file inclusion in C sources several separate tools exist as well as special options to some compilers. High-level tools wrapping Make use them in order to provide a more or less portable "automatic dependencies" feature. Despite the efforts and the good will of those higher-level tools, Make is blocking good solutions for automatic dependencies for the following two reasons:
- In the first place, Make doesn't really support dynamic many-to-one relationship. It does support many-to-one but not if the "many" part changes from one build to the next one. For example, Make will not detect if a new dependency has been added if that dependency is new in the list but old on disk (meaning older than the target according to its timestamp). By the way, make also lacks the support for dynamic one-to-many, which makes it in appropriate for Java builds (because with Java one single file can produce a variable number of outputs).
- Secondly, Make doesn't really support using automatic dependencies and updating those automatic dependencies in one run. This forces you to yield multiple Make calls for a complete build (did you ever wonder why the ubiquitous sequence "make depend; make; make install" has never been folded into just one Make call?).
Limited syntax
The lack of portable if-then-else was already mentioned. There are many other idiosyncrasies in the Make-file syntax. Some of them have been fixed in later Make clones (in incompatible ways, as you may expect). Here is a list:
- First, space characters are significant in a painful way. For example, spaces at the end of the line (between a macro value and the comment sign following the macro definition) are kept. This always generated and still generates very hard to track bugs.
- Secondly, in the original Make there was no way to print out something at parsing time. Moreover, Make has a bad habit to silently ignore what it doesn't understand inside the Make-file. The combination of the two (no print and silent ignore) is a killer. It happened to me in the past to stare for a while at some Make-file code not working as expected just to discover that the incriminated code was silently and entirely ignored because of a typo somewhere above.
- In the third place, there are no "and"/"or" operators in logical expressions. This is forcing you to deeply nest the non-portable if-then-else or those portable but unreadable equivalent constructions. All this is annoying but it is far less serious compared to Make decision to rely on the shell syntax when describing the executable part of a rule. Decent build tools gained, over the years, libraries of rules to support various tool chains. Not so with the Make tool. Make has instead a hard coded set of rules rarely used in real-life sized projects. Actually, the make hard coded set of rules hampers accountability more than doing anything else. One of those rules may and sometimes do trigger by accident when the make file author doesn't intend that. Lack of good support for portable library of rules is, in my opinion, the biggest shortcoming of Make and its direct clones.
Difficult debugging
The inference process of Make may be elegant but its trace and debug features are dating back to the Stone Age. Most clones improved on that. Nevertheless, when the Make tool decides to rebuild something contrary to the user expectation, most users will find the time needed to understand that behavior not worth the effort (unless it yields an immediate fatal error when running the result of the build, of course). From my experience, I noticed that Make-file authors tend to forget the following:
- How rules are preferred when more than one rule can build the same target.
- How to inhibit and when to inhibit the default built in the rules.
- How the scope rules for macro work in general and in their own build set up. While not completely impossible, Make-based builds are tedious to track and debug. By way of consequence, Make-file authors will continue to spend too much time fixing their mistakes or, under high time pressure, they will just ignore all behavior that they don't understand.
What about generated Make-files?
You may argue that all the discussion about the syntax of Make-files is pointless today and that would be fair. Indeed, today many Make-files in existence are automatically generated from higher-level build descriptions and the manual maintenance burden is out. So, with these new level tools, can I forget about those Make problems and just use it? Yes and no. Yes for the syntax related problems, yes for the portability problems (to some extent) and definitely no for all the rest: reliability issues, debugging problematic builds, etc. see also the discussion on build systems below to understand how the shortcomings of Make are affecting the tools built on top of it.
Conclusion on Make
The Make build tool was and still is a nice tool if not stretched beyond its limits. It fits best in projects of several dozen source files working in homogeneous environments (always the same tool chain, always the same target platform, etc.). But it cannot really keep up with today requirements of large projects.
After I tell people what is wrong with the Make tool, the next question is always the same: "if it is so awkward, then how comes that it is so widely used?". The answer does not pertain to technology; it pertains to economy. In short, the reason is that workarounds are cheaper than complete solutions. In order to displace something, the new thing has to be all that the old thing was and then some more (some more crucial features not just some more sugar). And then it has to be cheaper to top it. Despite the difficulty of being so much more, in my humble opinion, today the time of retreat has come for the Make tool. Let's look at the alternatives.
Make alternatives
Almost like text editors, build tools are a large population. You can find many of them cataloged at the Free Software Foundation (http://directory.fsf.org/devel/build), at DMZ (http://dmoz.org/Computers/Software/Build_Management/Make_Tools) or at Google (http://directory.google.com/Top/Computers/Software/Build_Management/Make_Tools). You can also find many build tools by digging in well-known open-source repositories like SourceForge (http://sourceforge.net/softwaremap/trove_list.php?form_cat=46) or Tigris (http://construction.tigris.org/) but it is much more difficult to spot what you are looking for on those sites. I will discuss here a small selection. This selection is highly subjective. And the coverage is biased towards open source tools. I have grouped the tools in several categories to help you get a better overview.
Make clones
The tools in this category are not really alternatives. They are what people currently understand as Make (virtually nobody is using today the original BSD UNIX Make). I mention three tools in this category: GNU Make, Opus Make and NMake. They all share some compatibility with the format of the original Make-files.
Opus make
This tool is not widely used today but, in my opinion, Opus make is the best Make clone ever made. It has a few outstanding features that set it apart from the crowd. It has the richest set of directives allowed in the Make-file (including its own "cd", "echo", "copy", "delete" and other frequent shell commands). Even more important, these directives can take effect at parsing time or at rule execution time. The latest makes up for more portable execute part in rules, greatly reducing the dependence on the shell underneath. Opus make always had logical operators in condition expressions, regular expression substitutions, possibility to trace the parsing, to stop on lines not understood and many more. With its "inference restart" command, it has support for one-pass build, a feature rarely seen around. Next to its comprehensive set of native features, Opus make also has a fair set of emulations for other Make tools. Unfortunately, its development seems to have stop back in 1998 (http://www.opussoftware.com/). A version of it is still distributed today with the IBM Rational ClearCase SCM tool.
GNU Make
GNU Make (http://www.gnu.org/software/make/make.html) is very likely the most widely used build tool. Being available as open-source and being an integral part of the GNU tool set made it a popular choice on many Unix-like platforms. This tool is actively maintained (last version, 3.80, came out in October 2002). The GNU Make is a vast improvement over the original Make, especially by its large set of new macros. Over the last 10 years it gained some important features (that should have been available from the beginning): print out at parsing time, stop parsing and exit, force the build, define new function-like macros, case insensitive file name comparisons on some platforms, etc. Unfortunately GNU Make also kept most of the problems of the original Make and much of the criticism that you'll hear around for Make is actually directed to the GNU Make.
AT&T NMake
NMake (http://www.research.att.com/~gsf/nmake/nmake.html) originates at and is maintained by the AT&T laboratories. The large set of open source tools coming from AT&T (Korn shell, graphviz, etc.) is built with it. NMake is open source itself. There is a commercial version from Lucent as well (http://www.bell-labs.com/project/nmake). The AT&T style source distribution packages rely on NMake and their own configuration tool, iffe. This build system from AT&T is very much Unix-centric, exactly like the GNU build system. Note that Microsoft also has a Make-clone called "nmake" bundled with their development environments (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcug98/html/asug_overview.3a.nmake_reference.asp). Take care, they are incompatible; don't expect a Make-file wrote for one to work OK with the other.
Make evolutions
The tools in this category move away from the old syntax of Make-files but didn't break with the Make tool spirit. That is, they are still developed in C or C++ and they are still using some kind of text file located close to the sources to describe what has to be built. I will mention 2 tools in this category: Jam and Cook.
Jam is a build tool maintained and promoted by the people providing the perforce SCM tool (http://www.perforce.com/jam/jam.html). Perforce is commercial software but Jam is fully open-source. Despite some small issues with its syntax, Jam files are expressive enough for the Jam tool to come standard with a decent database of rules. Jam was so influent that it generated a set of clones (FTJam, Boost.Jam, Boost.Jam.v2). The most interesting is Boost.Jam (http://www.boost.org/tools/build/v1/build_system.htm) from the maintainers of the Boost C++ library. This one introduces quite some syntax extensions compared to the original tool. You can tell by those extensions that the authors were C++ programmers (for example, the scoping of variables looks like C++ namespaces). Boost.Jam is not the only or the first attempt to raise the level of the build description but, more than other Make evolutions, Boost.Jam focus on real build issues. For example, it provides canned variant builds, it provides dynamic loading library abstraction for Unix and MS Windows target platforms, it cares about testing the result of the build, etc. If you ever used Make for a real-life sized project, you had to provide such things by your own effort and you will immediately understand what savings this approach of Boost.Jam brings. Unfortunately, Jam doesn't take the jump to content signatures and to command line signatures. The problems related to the weak timestamp heuristic are still present.
Cook (http://miller.emu.id.au/pmiller/software/cook/) is a build tool designed by Peter Miller with quite a long history. Like Jam, cook is open-source and support parallel builds. Like Jam, it avoids recursion. Like GNU Make and unlike Jam, it relies on a separate tool, c_incl, to get implicit dependencies in C code. The build description syntax used by Cook take some of Make-file and quite some of LISP. As a matter of facts, quite some build tools chose a LISP-like syntax. There is a good reason for that: manipulating lists (i.e. lists of dependencies) is a frequent task when describing a build. Cook can use content signatures ("fingerprints" in its parlance).
I cannot express a clear preference in this category. Boost.Jam and Cook come close. But I can say that I prefer any of them over the GNU Make. The reason is that they allow you to focus on build design and forget some of the low-level, build implementation details. Unfortunately, they didn't encounter the wide spread that they deserve. May be because they are not part of a more comprehensive build system like GNU Make is.
You may argue that my preference does not make a lot of sense. Indeed, both Cook and Jam (the original) rely on the GNU build system to get themselves built which in turn relies on GNU Make. So it is not a matter of preference, you'll have to have GNU Make. This gives me the opportunity to introduce a thorny issue: the bootstrapping. The question is how do you build when you don't have the build tool, in particular how do you build the build tool itself? One solution is to cross compile and then distribute binaries for the new platform. Another solution is to go back to shell scripts for the build description of the build tool itself (like Boost.Jam does). Or you can just rely on "good old GNU Make" like many self-proclaimed modern build tools eventually do.
Some build tools are able to generate automatically shell scripts from their native build descriptions. Of course, the generated scripts don't have the full functionality of the build tool: they are usually able to do a build from scratch and nothing more. And they usually require manual set up of the shell environment. Nevertheless, those generated shell build scripts help a lot with the bootstrapping issue.
Build systems
The build tool is always just a piece in the larger software development system. Let us define more precisely the terms used below. The build tool reads a build description and then directly starts other tools to actually produce a result of the build: a report, a compiled file, etc. A build system is a set of tools, including a build tool (by the way, a good build system will support several competing build tools). A build system may produce or adapt the build descriptions before they are used by the build tool. A build system may manage in some way the build result (for example it may post on a web site the summary of an automatic build). Next to the build tool, the other important tool in a build system is the configuration tool. We call the configuration tool that one that adapts or generates automatically the build descriptions used by the build tool.
To understand the paradigm shift introduced by the build systems, it is important to first know the new requirements addressed by build systems: software distribution as a package of sources. The typical usage scenario for a build tool is C source code development. There the genuine input changes frequently and locally. Avoidance is a crucial feature in this use case. How building works elsewhere is less important. Also the addition of new components to a build has to be easy. By contrast, for software distribution, the crucial need is the possibility to customize the software. It has to be adapted to new build platforms, to new run-time platforms, to site-wide conventions, etc. The builds are far less frequent; avoidance is not really a requirement, for example. The difference in requirements had an influence on the evolutions of the build tools (some being used mostly from within build systems and some being used mostly stand alone).
The key advance with build systems is the fact that they put some executable code in the source code distribution of the software to be built. We name the executable part in the source distribution the configuration tool. This changes the nature of the source code distribution; now it is more like an installer package. "Installer" is a term stolen from binary distributions (For software distributed in binary form, it is a long-time established practice that the package has to "execute" on the system that receives the software distribution). Because now you are supposed to execute some program delivered with the sources before you start the build, the source distribution gets a chance to adapt itself to the current build machine. This is what makes build systems so helpful with source code portability. The configuration tool may change build descriptions or source code or both. Sometimes the configuration tool evolved in a complex interactive tool (see the several tools available to configure the Linux kernel compilation).
The configuration tool inspects the build platform in small steps, individual checks for one feature. Hereafter, we will call these steps probes. How results of probes are represented differs from one tool to another but most of them have a caching mechanism in place so that you don't need to run a probe each time you need the result of that probe. Probes can have various granularities, can be independent or can be dependent on the result of other probes. Roughly speaking, the available set of probes is the way a configuration tool represents its knowledge about the platform it needs to adapt to. And the result of the entire set of probes defines de facto a model for a given platform. Which hunts on the planes of operating systems (OS), with more or less support from those OSes maintainers. Given the diversity of platforms to cover (yes, the world is a mess and we cannot change that by tomorrow), the configuration tools in general take on a tremendous job. This unavoidably generates frustation in different places and at different levels. Try to be positive and not judge a configuration tool only by its failures in some cases.
Before we look to some more Make alternatives, let us first compare a few build systems.
The GNU build system (GBS)
This is the system of choice in the open-source community. It is based on the GNU Make as build tool. It has a few remarkable features that greatly help with software portability (http://sources.redhat.com/autobook). The configuration tool of GBS is a shell script named "configure". That script inspects the build platform and then produces build descriptions for GNU Make as well as C source code (actually one central header file, to be included by the C source files).
What makes GBS so successful? Certainly not the fact that it was the first attempt or the only attempt. Long before it, the IMake (http://www.oreilly.com/catalog/imake2/index.html) tool introduced higher-level build descriptions. IMake comes from the C code base of the XWindows system. IMake higher-level make files made the build description both more portable and easier to write. Yet IMake was never as successful as GBS. It is probably due to the way the knowledge about the platform was implemented for the IMake tool.
The configuration tool of GBS, meaning the "configure" shell script, is automatically generated by a tool named "autoconf" (http://www.gnu.org/software/autoconf/manual/autoconf.pdf). As you see, autoconf is not a build tool, it is a script compiler. In my opinion, autoconf is the most valuable part of GBS and it is largely responsible for GBS success. The script produced by autoconf is made very portable (it doesn't have heavy requirements on the underlying system). This makes that, unlike with IMake, with GBS you have a fair chance to successfully build on a platform that was never seen by the author of the software you build.
Equally important, the authors of GBS were the first to seriously consider the bootstrapping issue. Indeed, it is possible to use GBS to build parts of GBS. After a few iterations, you'll get a complete new version of GBS. It is not an easy process but at least it is possible. You may wonder "What is the big deal? I can already use Make to build Make!". The big difference is that, in order to build Make with Make, a version of Make has to be installed on your build machine first. By contrast, you can build autoconf with GBS on a build machine where autoconf was never installed before.
If GBS is so smart then why is not everybody using it? One reason is that GBS is very UNIX centric and C/C++ dedicated. And even if you build C programs on UNIX, GBS only works effectively if your source code complies with the GNU coding guidelines. This is a showstopper if you have a large body of code with its own coding guidelines (for example not using the central header file config.h but some other code, may be automatically generated as well).
Another reason why GBS is not used everywhere is some of the price it pays for its portability. For example, the probes of autoconf are encoded as M4 macros. M4 is a powerful text processor but its syntax is pretty low level and difficult. Difficult enough to make this a major obstacle for extending the reach of GBS. While being a god gift for less capable platforms, GBS has a much harder time to win the favor of developers on the mainstream platforms. People simply don't want to give up their convenience (when writing probes) for the sake of some obscure platform nobody heard of. Yes, I know this is not a technical argument but the world is so that non-technical arguments are sometimes more important (http://osx.freshmeat.net/articles/view/889).
Another thorny issue is the weak support for the embedded software development and the associated issues. In the embedded world, everybody is cross-compiling; the build platform and the run-time platform are separate and very different in nature. In that case, automatic inspection of the build platform before the build will not get you very far. In the embedded world, some kind of database holding the characteristics of the different platforms, turns out better. The database is painful to maintain but is the only solution that works. Autoconf has later on added some features to support cross-compilation.
Last but not least, one issue with GBS is the fact that it uses GNU Make and nothing else than GNU Make as a build tool. If you didn't get my point by now, that means that you will frequently have inconsistent builds, that you will have a hard time to debug an inconsistent or a broken build, that you will not be able to build a program called "clean" or "install", etc. All these issues with GNU Make undermine the important achievements of autoconf.
Alternative configuration tools
The need to configure the sources before compilation is quite old and solutions have grown in time in almost all large C/C++ code bases, many being ad-hoc solutions. Some code bases have been migrated to GBS, some kept their own because of some isolated advantages or just by lack of resources for migration. Many build tools evolved to provide some form of source configuration either as an add-on or as a part of the same tool. For example, Boost.Jam has its "feature normalization", SCons has its Configure, etc. I would like to mention here 2 stand alone solutions used with Make, iffe and metaconfig.
If you are familiar with the AT&T labs open source software you met iffe (http://www.research.att.com/~gsf/man/man1/iffe.html). This is the configuration tool of their source distribution packages. Like configure in GBS, iffe is a shell script and is distributed with the C source code. Unlike, configure, iffe is not generated. Another important difference is that iffe doesn't focus on build descriptions. It generates only source files (precisely it generates header files that your C files are supposed to include). It does that by processing input files named feature test files. The feature test files are written in a specific language that is interpreted by iffe to generate header files. Because in one configuration process several headers are generated according to your decisions to group probes in feature test files, iffe author claims that their system is more flexible than GBS and they are probably right. In the end, the fundamental mechanism to adapt the source code is the same: conditional compilation with the help of the C preprocessor.
If you are familiar with the Perl (http://www.perl.org) software source distribution you met metaconfig and the dist package (http://packages.debian.org/testing/devel/dist). Metaconfig is a shell script compiler, older than autoconf, and the configuration tool it generates is called Configure. Unlike the one generated by autoconf, Configure is mainly an interactive tool. The probes used by metaconfig are called units. These units are shell code snippets. Metaconfig was probably the very first tool to do a decent job scanning the source code base to automatically detect points of customization. By comparison, autoconf still has to rely on a helper tool, autoscan, to do this with more or less success. Automatic scanning of source code is great but it requires complying consistently with some coding guidelines decided by the configuration tool. That may not be the case for existing code.
Alternative build systems
There are several other alternatives to GBS available today, both commercial products and open-source programs. I would like to mention two of them: CMake (http://www.cmake.org) and Qmake (http://doc.trolltech.com/3.0/qmake.html). Do not to be misled by their name, they are no replacement for the Make tool, they are Make-file generators. Also do not confuse the Qmake tool from TrollTech with the qmake tool from the Sun GridEngine (http://gridengine.sunsource.net/unbranded-source/browse/~checkout~/gridengine/source/3rdparty/qmake/qmake.html) which is just a parallel GNU Make.
Like for GBS, the main issue addressed by these tools is the portability of the build description. CMake and Qmake have a lot in common in their design and in their spirit. They are both open-source and they are both implemented in C++ (Qmake had a predecessor, tmake, implemented in Perl). They both support more than one build tool. Most notably, they support the classic Make as well as the Microsoft IDE. They have to provide a dynamic linking library abstraction to cover both UNIX .so files and Microsoft .DLL files. They are both introducing their own high-level format for the build description. They both take basically the same approach to hierarchical builds as the original Make. Not betraying their high-level nature, both tools provide support for generating also some source code (wrappers or mock objects). My preference goes to the CMake tool. It supports a wider set of build tools and it offers a choice among command-line and graphical user interfaces.
For both these tools, you have to distribute the binary executable of the tool with the source code package and this raises a bootstrapping issue. Also, in my opinion, having the knowledge embedded in C++ classes as in CMake is a shortcoming. I certainly agree that C++ classes are much better then M4 macros, yet C++ will limit the number of contributions from the community . People who can write good C++ and want to support new toolchains are required to contribute back their changes in a consistent and systematic way. Otherwise, over time, we will get several incompatible versions floating around for the executable of the tool. Storing the knowledge about the toolchains in some kind of configuration files so that additions doesn't require C++ recompilation may out weight the disadvantage of a more complex distribution of the tool (a set of files to distribute instead of a monolithic executable). Finally, like GBS, these two build systems share the disadvantages of the build tools they use. As already mentioned, that is mainly poor checking that results in high chances to get inconsistent builds during the active development of the software.
More Make alternatives: script based build tools
My point out of the previous chapter is that, despite what some people hoped, a good build system will not spare you the need for a good build tool. It is certainly helpful but if the build tool is weak the build system would have a hard time to hide it. Fortunately, the community of developers was not only busy making smarter build systems but also better build tools. In the following I would describe another category of build tools. I would call this category "script based" build tools but it is not easy to find a name that will adequately describe them in two words. It is important to understand the new paradigm shift introduced by this category of tools. The approach taken by their authors says "Let's not invent a new syntax. We are not in the business of writing text parsers. Others already did that and they did it better then we will do it in a fraction of our time". They also say "Let's not write and maintain the portability layer for our build tool. Let us reuse some virtual machine already available". So these people focus on the build design and on build design related issues. This seems to me a sound choice when one aims to provide a better build tool. I will mention only two tools in this category: Ant and SCons. But you have to know that there are many others.
The Ant build tool (http://ant.apache.org/manual/index.html) is well on the way to become the next Make. It is an open-source project from the Apache developer community. Ant is a Java program and it uses XML for the build descriptions. It spread quite fast because it faced no competition (certainly not from the old Make). Too much Java centric at the beginning, Ant has grown today into a mature build tool that can put to shame many of its competitors. One sign that a piece of software is mature and fulfills a real need is the number of new projects that are taking that software as a base. And there are many software projects based on Ant. There are:
- commercial products like OpenMake (http://www.openmake.com/products.html),
- extensions to address new builds (set of new tasks in Ant parlance, like http://ant-contrib.sourceforge.net which includes support for C/C++ builds),
- extensions to allow higher level descriptions (antworks, previously centipede(http://antworks.sourceforge.net)),
- extensions to provide integration in graphical IDEs, etc. As a matter of facts, no other build tool is gathering together so much development efforts today. This gives an important head start to Ant in the race for the next Make.
Like the original Make, Ant was the primary source of inspiration for a set of new build tools like Nant (http://nant.sourceforge.net) and, more recently, MSBuild (http://channel9.msdn.com/wiki/default.aspx/MSBuild.HomePage). They don't aim at file compatibility for build descriptions but their spirit is the same: describe the build as a set of tasks to carry out, each task coded as an XML element.
Of course, Ant is no silver bullet. Ant without extensions has a scalability problem. A lot of it comes from the choice of XML as a file format. XML is verbose. XML does not have a convenient way to include a file in another file (the XML Fragments standard is not really supported by XML parsers, XML entities includes work but have limitations, etc.). You need some kind of inclusion because you want to factor out common parts in several build descriptions. Of course, an application using XML files is free to add "include" semantics to one chosen XML element (and that is what Ant finally did with the "import" task in version 1.6).
Also XML is not really a programming language. You may want to have the content of one XML element computed from sibling elements (computed strings occurs so often in build descriptions, see Make macros). Or you may want one element to be taken from the parent or the parent if not found at some place (what would correspond to variable scoping in programming languages). I say "you may want" but for projects of real-life size you will need that. Otherwise the build description grows very big and redundant. This is not a hard limitation; the Ant tool does give you the power to express whatever you want. It is just the fact that you have to go back and forth between a purely descriptive part of the build specification (the build.xml) and a purely procedural part (the Ant tasks implementation) that I don't like very much. People contributed Ant tasks like <if> but this will not turn XML into a programming language overnight.
Another issue is that Ant has a noticeable overhead for startup and initial XML processing. This is an important psychological factor in the case of null builds (builds where everything is up-to-date and nothing has to be done). The Make tool was fast in such builds. Make was fast for a bad reason but the fact remains that people have a philosophical problem today to accept that the build is slow when nothing is to be done. Like for other build tools in this category, it would be nice to have the possibility to "compile" the build description, may be the entire dependency tree, into a speed-efficient format.
SCons (http://www.scons.org) is a build tool that uses Python (http://www.python.org) for the syntax of the build descriptions. The origin of SCons is Cons, a similar tool using Perl syntax for the build descriptions. That older tool is also available (http://www.dsmit.com/cons). SCons is my preferred tool in this category and also my preferred build tool overall. It comes preconfigured with a fair set of rules ("builders" in SCons parlance). Even more compelling, it can be extended in an easy and natural way. Unlike Ant, the build description and the extensions use the same syntax, in this case Python. SCons allows flexibility in the compromise speed versus safety (by using either content signatures or time stamps). It detects changes on the command line used to build something and this makes it outstandingly reliable compared to its competitors. There are many other features I like in SCons: the transparent use of code repositories, the wink in from cached binaries, the possibility to accurately document the build, the support for extraction of snapshots of the code and, finally, the promise to grow in a better build system (autoconf-style probes, ability to generate projects files for IDE, etc.).
Because perfection doesn't exist in the real world, you probably expect to hear also about the shortcomings of SCons. To start with, SCons is a young piece of software, at least when compared with some other tools mentioned above. Another issue is that, despite not being recursive, SCons is slow. This seems to be a price to pay when focusing on high-level build design issues. A time will come when the authors of SCons will focus on speed optimizations. Like with Perl and Java, Python allows moving later on the speed-critical parts to a native compiled code implementation (when the software is stable enough).
From another perspective, despite the fact that Python has a clear syntax, some people perceive SCons as being too low level. It is perfectly possible for the release engineer to describe the build of a 50-developer project for several target platforms in only a few dozen lines of SCons code. The release engineer will find this a great time saver but the average developer will find that code cryptic, like shell code in the early UNIX days or worse. The developers will soon ask for easier ways to add new components to the build.
More build related tools
An overview of build tools in one article has to be a limited one. We didn't even mention all the area where build tools needed and got improvements.
One such area is better integration with the SCM tools. This is important because it addresses directly a long-standing issue: the reliability of the build. There are quite some SCM tools providing improved build tools, both commercial (Omake in IBM Rational ClearCase, http://www.agsrhichome.bnl.gov/Controls/doc/ClearCaseEnv/2003.06/ccase/doc/win/cc_omake/wwhelp/wwhimpl/js/html/wwhelp.htm) and open-source software (Vesta, http://www.vestasys.org). But comparing the build tools integrated with the SCM systems goes far out of the scope of this discussion.
Another area we didn't touch is the automation and reporting of the build (CruiseControl (http://cruisecontrol.sourceforge.net) and Dart (http://public.kitware.com/Dart) as open source tools, VisualBuilder (http://www.visualbuild.com) and FinalBuilder (http://www.finalbuilder.com) as MS Windows commercial software). Yet another area not discussed here is the acceleration of the build when parallel build machines are available (distcc and ccache (http://distcc.samba.org) as open source tools, IncrediBuild (http://www.xoreax.com) and ElectricCloud (http://www.electric-cloud.com) as commercial software.
Finally, there is one last area that we don't want to discuss here: the software distribution tools. Many tools today allow you to connect as a client to some software repository, download the software you want, download automatically other needed parts and install everything on your system while building locally parts that need building. Those systems include a build tool or act as a build tool when needed. They have to act as a configuration tool too. Also, they have to do some form of dependency tracking, much like build tools do. The best known is probably Ports of the BSD OS (http://www.freebsd.org/ports) and its followers like Gentoo Portage (http://www.gentoo.org/index-about.html). Take a look at the A-A-P tool web site (http://www.a-a-p.org) for a list of such systems.
General conclusion
The final conclusion is up to you. The considerations in this paper reflect only my experience. But I hope that you have now some useful background to choose the build tool and the build system that best fit your own requirements.
- -- AdrianNeagu, April 2005


text:
If you're like most sport enthusiasts, you're convinced that a commitment to the psychological dimension of your game will not only enhance your performance but also bring you closer to reaching your potential no matter what your current level of competition.
If you are also like most people, you may begin a mental skills program highly enthused and motivated for the first couple of weeks but if you don't see dramatic results "immediately" you may be tempted to revert back to practice that only includes three of the four pillars of peak performance. In some ways, mental skills training is like the familiar New Years Resolution to "get in shape." Unfortunately, data indicates that 50% of the people who start an exercise and fitness program drop out within the first six months. Our culture has sold us on the idea of quick fixes and immediate change. Instead of thinking of mental preparation as a "magic pill" think of it as a "steady diet." You will see results only if you commit to it in the same way you do the technical, tactical and physiological aspects, namely consistent and prolonged effort over time.
If so many top level athletes and coaches extol the benefits of mental training for peak performance, then why do a relatively small percentage of teams and individuals commit to practicing and refining this critical part of performance? Listed are the top four reasons for discontinuation. Check to see if any of your reasons are included:
The second concern people have is acquiring the proper knowledge base. Well, if you're reading this article then you are already on your way in developing the requisite knowledge and skill. There are excellent books and journal articles available concerning mental training for sport. Whether you compete in golf, soccer, baseball, basketball or any other, much has been written on how to get the competitive edge and how to use it to your best advantage. Attend clinics, listen to respected athletes and coaches discuss their techniques at conferences or workshops and by all means, keep reading the eteamz site!
The final two excuses could best be explained by reminding yourself that mental skills are just like physical skills, they respond best to practice and repetition. All of us are born with varying levels of a host of qualities from mental toughness, to competitive drive to perseverance after failure. No matter how much or little you possess of any one characteristic, almost all psychological skills respond positively to sustained and appropriately focused efforts at improvement. Years ago, few athletes sought professional advice on personal training and fitness and yet today, that practice is commonplace. Years ago, few people understood the role that diet played in enhancing peak performance in sport. Science, research and technology have made incredible advances in our understanding of what psychological skills are best targeted to enhance performance and what principles to utilize to see those positive results.
© Dr. Colleen Hacker
eteamz, a part of Active Network, LLC, is the leading Web Site building resource for parents, coaches, and league administrators. We're the biggest, we've been around the longest, so it's no surprise we've been able to help millions of teams, leagues and organizations get online. So come on, there's always room for more.

subset: commoncrawl


text:
Skip hire Doncaster
UNFORTUNATELY WE DON'T CURRENTLY OFFER SKIP HIRE IN Doncaster.
If you wish to be notified of new skip hire services in Doncaster when they become available, please fill out the 'register for area alert' form.
Wheatley Skip Hire DN2 Bentley Skip Hire DN5 New Rossington Skip Hire DN11 Grasby Skip Hire DN38 Wootton Skip Hire DN39
Proskips is a leading skip hire company. We offer skip hire to both private customers and businesses across much of the UK, but focus on the East Midlands area.
Based in Raynes Park, London, we have depots in and around the DN1 area, which gives us unrivalled coverage for all your skip hire needs.
We have a range of skip sizes available for hire, from four yards to 16 yards. For further information about the size and capacity of skip you need, please get in touch.
Our competitively-priced skip hire service and experienced team have made us the skip hire company of choice in the UK. Working with homeowners, small builders and larger construction firms, our aim is always to meet and exceed your service expectations.
In addition to skip hire, we offer a waste management and recycling service. Our work in this sector led to us being named 'Construction Recycler of The Year 2009-2010' at the National Recycling Awards. Proskips is part of Prowaste Management Services, and we adhere to the recycling standards set out by the company. We are also a proud supporter of the Halving Waste to Landfill scheme. Our commitment to recycling and safe waste disposal gives our customers peace of mind that all waste will be dealt with responsibly.
Our Doncaster waste recycling and skip hire service secured investment from Deborah Meaden and Duncan Bannatyne of BBC Two's Dragons' Den.
Even though we don't currently offer skip hire in Doncaster, we do operate a skip hire service in the nearby areas of Wheatley, Bentley, New Rossington, Grasby and Wootton.
Read more in our blog
Getting Ready to Move House
But don't despair. Moving house doesn't need to be that stressful. With good preparation and a thorough purge of your belongings, you can have a stress-free move and save some money to boot – after all, the less you have to move, the cheaper it will be. Here are our favourite stress-reducing tips for moving house: Be Ruthless Get rid of everything you don't need. Work through your property methodically, and go through all your stuff. Separate it into piles for the charity shop, car boot sale, rubbish dump – and items to be packed, of course. And we mean it when w…
Skip Hire Epsom - Hook Road
Proskips would like to thank the Steve Holloway Building company for booking their skip hire in epsom in the busy time leading upto Christmas 2012. The scope of works can be described as the completion of a small extension at the rear of the property. The business needed skip hire in epsom to collect all the waste materials from the project. The waste was predominantly bricks and soil. Any companies needing skip hire in epsom can call the team at Proskips on 0800 612 20 27. We can provide: 4 Yard Skips in Epsom 6 Yard S…
Housebuilding pledge reaffirmed in Queen's Speech
The UK's construction industry has reacted positively to measures outlined in The Queen's Speech, welcoming a renewed commitment to housebuilding, sustainable construction methods, and the HS2 extension project. The Federation of Master Builders (FMB) had previously raised concerns that Brexit might lead to a shortage of skilled EU construction workers coming to the UK, which could plunge construction projects currently in the pipeline into jeopardy. The industry has continually asked the government to safeguard the rights of EU workers in the UK post-Brexit.…


text:
Available ebook formats: epub mobi
"His stories are a treasure trove of riches that will touch your heart while making you think." --Robert J. Sawyer, Hugo Award-winning author
"One of Canada's most original writers of speculative fiction." --Library Journal
"A great storyteller with a gifted and individual voice." --Charles de Lint
Douglas Smith is an award-winning author of speculative fiction, with over a million words of fiction published in thirty countries and two dozen languages.
He has won Canada's Aurora Award three times and has been a finalist for the international John W. Campbell Award, Canada's juried Sunburst Award, the CBC Bookies award, and France's juried Prix Masterton and Prix Bob Morane.
Doug's book length works include:
THE WOLF AT THE END OF THE WORLD (Lucky Bat Books, 2013) - Urban fantasy novel
CHIMERASCOPE (ChiZine, 2010) - Finalist for the Sunburst Award, Aurora Award, and CBC Bookies Award
IMPOSSIBILIA (PS Publishing, 2008) - Finalist for the Aurora Award
LA DANSE DES ESPRITS (Dreampress, 2011) - Finalist for France's Prix Masterton and Prix Bob Morane
In 2010, an independent film producer released a multi-award winning short film based on Doug's story "By Her Hand, She Draws You Down." Films based on his stories "A State of Disorder" and "Memories of the Dead Man" are also in the works.
Website: www.smithwriter.com
Twitter: smithwrtr
"Smith's writing, evocative yet understated, gracefully brings to life his imagined realms." -- Quill and Quire *Starred Review*
"Smith paints his worlds so well that you are transported within a paragraph or two and remain in transit until the story ends." --Broken Pencil, The Magazine of Zine Culture and the Independent Arts
"Echoes of Stephen King, Richard Matheson, and Clive Barker haunt the halls of Smith's work, but the end result is completely original, and always enthralling." --Cory Redekop
"Douglas Smith is an extraordinary author whom every lover of quality speculative fiction should read." --Fantasy Book Critic
"Smith is definitely an author who deserves to be more widely read." --Strange Horizons
"I've yet to read a work of his that wasn't beautifully written, but more than that, his stories resonate with a deep understanding of the human condition as well as a characteristic wry wonder... Stories you can't forget, even years later." --Julie Czerneda, award-winning author and editor
"An ambitious and adventurous new writer." --Gardner Dozois, author and editor
"Smith is a master of beginnings ... some of the most well-crafted hooks you'll find anywhere: deft introductions to the characters and their not-quite-familiar worlds packed into just a sentence or two that draw the reader in. As for the endings ... Smith's tendency is to forego the shocking twist for endings that feel satisfying and right, a trade-off that I'll take any day." --Canadian Science Fiction Reviews


text:
Tyler Firefighters Plan to 'Turn Tyler Pink' on Tuesday for Breast Cancer Awareness
October is National Breast Cancer Awareness month and Tyler firefighters are asking for your help. They're asking the entire city of Tyler and surrounding areas to wear pink tomorrow to show your support for breast cancer awareness. Tomorrow, October 9, is the third annual 'Turn Tyler Pink' event in Downtown Tyler.
The event takes place from 5 pm- 8 pm at the T.B. Butler Plaza fountain downtown. The event is specifically designed to raise funds for cancer research, as well as to bring awareness to the disease. While the event is only three hours long, residents of East Texas are encouraged to wear pink all day.
Events attendees will be treated to music, food, fun & games, screenings and more as you help raise money to find a cure. You can get your picture taken with the one of a kind "turn Tyler Pink' firetrucks as well. Also Tuesday, firefighters also plan to give away a commemorative quilt from past Tyler Fire Fighters CARE shirts.
Pink event shirts can be purchased for $15 each at Tyler's Gallery Main Street, 110 W. Erwin St. and Holiday Inn South Broadway, 5701 S. Broadway Ave.
Tickets are $5 each or five for $20 and may be purchased from Tyler firefighters, Turn Tyler Pink Ladies Auxiliary, Gallery Main Street and Citizens State Bank, 3915 SSW Loop 323.
The first year they did this event, firefighters sold t-shirts and raised $12,000 to support a fellow firefighter who's wife had been diagnosed with breast cancer. The event has since expanded to downtown Tyler, and most recently donated over $17,000 for breast cancer research.


text:
If you ask young prisoners what got them behind bars, many will point to negative role models and peer pressure.
To raise awareness among teens and help them steer clear of bad choices, the Maryland Correctional Institution in Hagerstown (MCI-H) runs the Prisoners Against Teen Tragedy (PATT) program.
PATT sponsors an annual essay contest for a $500 scholarship and arranges prison tours for young people.
Essay winner
Tomi Dare, a 17-year-old student at Hagerstown Community College in Maryland, came across a contest announcement a few months ago while browsing through the college website.
"I said, 'Oh, I want that,'" she recalls. "So I looked into it. All what you do is write an essay. And it was about peer pressure and why you feel you don't do drugs."
In her essay, Dare focused on her own experience as an African-American girl growing up with an interest in sports, especially basketball.
"Drugs and alcohol not only slow a person down, it doesn't make you feel you are a winner," she says."It doesn't make you feel you are the best. As an athlete, I'm 6-2 [6 feet, 2 inches tall], so I feel that I should be above peer pressure because I'm bigger than anybody around. So I was talking about that. I was also talking about how I consider myself a queen. And if I am a royalty, I need to not put substances in my body. Drugs and alcohol are not what a queen should be taking."
Sal Mauriello, a case specialist at MCI-H, was one of the judges on the committee that chose Dare's essay as this year's winning entry.
"Just reading her essay, you can tell she was speaking from her heart," he says. "We discussed each essay and we chose this one because it seemed like she really meant what she was talking about."
Prison tours
PATT began in 1988 and it gives young people a chance to learn valuable life lessons from inmates at the facility. At the end of each prison tour, the teens sit down for an open discussion with some of the inmates. < /p>
"We have a group of 11 inmates who are in the PATT program," he says."They tell the youth what they went through as a child, what their crimes consist of. They teach them about peer pressure and bad choices."
Sharing personal accounts like those can save lives, says Mark Vernarelli, MCI-H spokesman.
"These inmates in the PATT program are just heartwarmingly sincere," he says. "They pour out their heart and soul into these young people."
What most teens understand after these sessions, he says, is that a small mistake in judgment, one bad decision, can have big consequences.
"A lot of men and women serving life in prison in the State of Maryland didn't pull a trigger or plunge a knife into anybody," he explains. "They were accessories to a crime. They drove a getaway car. They were with the perpetrator who did the main part of the crime. Yet, they got the life sentence as well. A lot of these young people don't realize there are a lot of people in prison serving life who didn't kill anybody. It's a very eye opening experience to hear these inmates."
Life lessons
PATT is one of Maryland's oldest programs designed to keep young people from a life of crime, but it's not the only one.
"We found that girls really need special sit down sessions sometimes more than boys, so we have a program for girls only," he says. "We have a program that travels across the state. That's called 'Choices,' which is a very graphic program that talks about the dangers of gang affiliation. We have an excellent program called 'Impact' where the inmates actually lead a tour and they have children eat a meal in prison cafeteria with the inmates and do all kinds of activities that are - I don't want to say shocking - but eye opening for the kids."
Vernarelli believes the inmates who participate in the Prisoners Against Teen Tragedy program also benefit. By keeping young people from following in their footsteps, as well as sponsoring an annual scholarship, he says they can feel proud that they are paying society back for the crimes they committed.


text:
Editor's Note: Elizabeth Bintliff, Vice President for Heifer's Africa Program, presented a keynote address at the April 2012 8th African Dairy Conference and Exhibition held by the East and Southern Africa Dairy Association last week. Elizabeth also spoke at a second event, which was attended the president of Kenya. Below is the first of her speeches; I'll share her second tomorrow. Though they are long, they illuminate the work that has been done and that is still to be done to grow the dairy industry in East Africa.
I'm delighted and honored to be here today to address the East and Southern Africa Dairy Association.
I want to begin my remarks by telling you about my own history with dairy. In order for you to understand this history, I must tell you that I am West African. I was born and raised in Cameroon. You all know, I'm sure, that there is virtually no dairy industry in West Africa. If there were, this forum is likely to have been called the East, Southern and West Africa Dairy Association. So I grew up in Cameroon where few people have access to fresh milk. I grew up drinking powdered milk, most of it imported in tins from Europe. We would mix it up with room temperature water in a bowl and then pour our cereal into it and that over twenty years, I still pour my milk in a bowl and warm it up slightly in the microwave before adding my cereal to it and eating. It drives my American husband crazy. He likes his milk ice cold, because that is how he grew up with it. In the US, milk is not something that is necessarily associated with cows. Rather, it is associated with supermarkets. On the other hand, in West Africa, milk is associated with tin cans. But in East and Southern Africa, thankfully, milk is still associated with cows.
I tell you this story today because I think it serves as a great preamble- a great preface- for the scope of maturity of the dairy industry in different parts of the world. It defines, in a small anecdote, what progress the dairy industry in this region has made, and what opportunities lay ahead for it.
The theme of this years' event is "Driving Competitiveness through Technology." In thinking about this theme, I realized that I would need to look to the past, the present and then the future, in order to frame this talk - the past for lessons learned, the present to analyze the current situation, and the future to envision what we need to get to our goal of a healthy, productive, and thriving African dairy industry. When we talk about driving competitiveness through technology it is not about any technology. It's about having the appropriate technology – proper hygiene, aluminum pails versus plastic containers, the right size of chilling plants for the different milk sheds, liquid nitrogen to make artificial insemination more viable, veterinarians with access to a reliable cold chain for veterinary medicines, research on cattle breeds, diseases and treatments.
Essentially, we are looking at avenues for improving productivity and efficiency within the dairy sector. It is a challenge that we at Heifer International have grappled with for many years of our existence. It is a challenge that we have paid particular attention to during the four year-old life of the East Africa Dairy Development project, or EADD. EADD is a $42 million project funded by the Bill and Melinda Gates Foundation and implemented by Heifer International in Kenya, Rwanda and Uganda. Within this project, the goal was to double the incomes of 179,000 families, the equivalent of one million people, through investments in smallholder dairy farming. The theory we had in the design of this project, is that Dairy Farmer Business Associations (DFBAs) can benefit farmer incomes and livelihoods through the establishment of chilling plants as aggregating channels from which farmers can access the benefits of economies of scale. DFBA benefits are two-fold: 1) it is a cooperative bulking and selling point for milk; 2) and a platform for farmers to access services, and inputs including advisory and extension, information, artificial insemination for their animals and financing. We believe that these farmer-owned dairy cooling plants, and 68 active sites in East Africa, have evolved to not only transform individual farmers' lives through income, but also transform whole communities in rural areas as centres of development.
Among the things that the East Africa Dairy Development grant has allowed Heifer to do is to test a theory on scale and its relationship with impact, to test the viability of public/private partnerships as a strategy to benefit the poor, to assess whether the profitability of the profit pillar in the dairy value chain is zero-sum. What we have learned is significant. We've learned that higher aggregated income for farmers plus regular supply and sale of productive services and inputs soon spirals into ever-growing demand and supply of quality goods and services - education, better healthcare, nutrition and gradual unlocking of value for factor assets such as land, housing, livestock and labor. The DFBA model also spurs grassroot business and community leadership that builds social capital enhancing cohesion, goodwill, fellowship, mutual sympathy and social interaction, creating a virtuous cycle that in turn generate wealth and enhances well-being for all.
The intention of EADD is to explore scalable, replicable interventions in the dairy industry in developing countries which can become a model for success elsewhere as a viable alternative for building sustainable livelihoods for smallholder farmers. As an organization, our mission revolves around the wellbeing of all families, but particularly around the wellbeing of farm families. Our singular priority is the ending of poverty and hunger. You see, the history of Heifer is really the history of a cup of milk. Our founder, Dan West, was a volunteer in the Spanish civil war in 1944, where he handed out cups of powdered milk to women and children on both sides of the war. As rations grew smaller, he was instructed to give milk to people who looked like they were most likely to survive, in order not to waste scarce resources. Dan West came back from the war changed by the experience of having to make decisions about the life and death of people, and with the conviction that what made sense – what was more sustainable – was for people to be able to produce their own food. What they needed, was not a cup, but a cow. Out of this idea, Heifer International was born.
We've looked to the past, and examined the present. Now I want to look to the future to see where we're headed together. There are three main elements that we need to consider, in order to be successful: (1) Technology and services (2) Partnerships (in a multitude of sectors) and (3) Inclusion of Women.
The world has changed a lot since 1944. Our way of working has evolved. But our mission and our priorities remain the same. The projection of an increasingly growing middle class indicates that demand for food will stretch to its limits. For dairy, that means that the opportunity for smallholder farmers will grow as well. Yet, the challenges for smallholder dairy farmers remain significant, and therefore, so do the challenges for other actors along the dairy value chain. It is imperative that if we are going to make dairy farming more sophisticated, more efficient and more profitable in this region, we need to address the challenges from the farm level and all the way up the value chain. The farming community needs to be market driven and to meet the needs of the market with investment and professionalism. Their product needs to be of quality, consistent, safe and priced competitively. We know that connecting these communities with FAIR markets is a sustainable and long-term solution to poverty for these communities.
Last year, Kenya's dairy production totaled more than 546 million liters of milk, up from 2010's 515 million liters, becoming the fastest growing sector in the country. This growth was driven by small-scale farmers. Organizing them, coordinating them and mobilizing them could have a similar impact on the dairy sectors of other countries in the region.
Heifer is an organization that has deep expertise in mobilizing dairy farmers so that the farming communities prosper and are sustainable and competitive. In EADD as in other projects worldwide, we support and encourage the farming communities to form appropriate institutions such as companies, co-ops and other community based systems to ensure farmers capture a FAIR share of the created values in the dairy supply chain. The goal is to create a FAIR system that allows the farming families to live a life of dignity and security.
When you take a look at the sector today, you see that it is challenged at many levels. We are not yet fully harnessing breed performance to its full potential. Farmers do not have the capacities and the knowledge needed to improve their production levels and to meet the quality standards of the markets. We need to make extension services more accessible and more reliable. We need to improve mechanisms for transporting milk from the farm gate to the chilling plant or the market both for the sake of maintaining quality and as a possible source of income and employment for young people in removed communities. But that is only the first mile. We need governments to create policies that respond to the needs of the sector, opening it up for competitiveness. We need to invest in the infrastructure and technologies – chilling plants, storage facilities, roads to market, information access, water, and electricity. We need the private sector to invest in linking the farm and the market with fewer barriers in between the producer and the consumer. There is opportunity for prosperity in the dairy industry in East and Southern Africa. How we tap this opportunity is up to all of us. Collectively. Fairly.
We need to take a reverse look at the Profit Pillar. If you take the price of a certain dairy product in the market and work backwards along the value chain adjusting for purchasing power parity, you will find that the farmer makes the least amount of profit…and that is who is producing the milk! Unfortunately, this approach of profiteering still exists in some pockets. We have learned through the EADD project that farmers now possess the savvy to circumvent that profiteering. Profiteering in the sector is addressed through collective ownership. By joining cooperatives, farmers gain as producers or as investors. We believe that their role in the sector has to be strengthened.
At Heifer International our Theory of Change is founded on the idea/belief that smallholder farmers, especially women, can attain sustainable and socio-economically viable livelihoods if their capacity is enhanced to increase income, access adequate food and practice agro-ecologically friendly farming. We have to address the role of women not just from a moral or ethical standpoint. We have to address it from a pragmatic perspective. Women still represent a significant proportion of smallholder farmers on the African continent. We are the curators of family nutrition, the wards of the household, the custodians of community and culture. Our numbers are large and our impact is ever growing. To ignore us is to ignore a substantial amount of labor, of manpower or shall I say womanpower that is critical to the development of this industry and in fact this continent. And speaking particularly of my own gender, I have to say that the role of women in this chain must not, cannot and should not be ignored.
In order for us to reach our vision for a robust, effective, efficient and profitable dairy industry in East and Southern (and maybe one day even West) Africa, it is imperative for all sectors to work together, there is room for everyone to profit. We need the right set of policies, we need a private sector with an inclusive agenda, and we need research. The usefulness of research is in its application. We need technology. The need for appropriate technology to enable increased productivity on limited resources. Again, here I stress the word "appropriate." The road to development on the African continent is unfortunately strewn with good but often misguided intentions. The question for all sectors - public, private, policy and civil society to answer is how can smallholder dairy meet the demands of a growing population without compromising the well-being of the earth and of rural communities. That is our challenge for the future, and it will make the sector more efficient and effective for all players and help milk meet its ultimate purpose, which is to nourish the hungry.
Technology. Partnerships. Women. All of these are crucial elements for our success down the road. Our success will further be realized by encouraging the farming community (this goes beyond the farmers themselves, it includes vets, transportation, banking, etc.) to diversify their customer base and include the local markets. Next year, Heifer International hopes to launch Phase II of the East Africa Dairy Development project in Kenya, Rwanda, Uganda, Tanzania and Ethiopia. Maybe one day in the future, we can see this same model replicated in places beyond East Africa, maybe to southern Africa. And perhaps even to West Africa. We know from Europe's experience that there is tremendous value to farmers and to consumers of producing at an artisanal level.
The end game is not necessarily sophisticated supermarkets such as exist in the United States. At Heifer, our mission continues the dream of our founder from seventy years ago…we want families to have access to a cup of milk to feed themselves.
East Africa is changing fast – much faster than we can imagine. From its inauspicious beginnings as a cottage industry, dairy production could play no small part in the transformational changes which lie ahead. The 14 member-states of the COMESA region today consume approximately 20 Million tons of milk, and produce about 21M tons.
What is at stake here is the value proposition to transform the livelihoods of East and Southern Africa's dairy farmers with each addition liter of milk. The statistics are telling: in 2010 alone Kenya's 28 Microfinancegranted US $1.2 Billion in loans to 1.2 Million borrowers – an average of US$1,000 per borrower. On the other hand, the value of dairy offtake in 2011 is estimated at US $121 Billion - an average of US 121,000/person for the 179,000 families engaged in small dairy farming project I mentioned earlier.
Imagine an African common market –twenty years from now- stretching from Cape Town to Cairo and teeming with the free flow of goods and services and capital. In that future, milk consumption per capita would increase from 181Kg/person/year as we see in Sudan today and probably reach 240Kg/person/year as we see in many developed countries in the West. The opportunity exists for East and Southern Africa to produce not just for the region, but also to address the growing demand for fresh milk in other parts of the continent. Carrying on the vision of Heifer International's founder, I dare to dream that it is possible, that one day soon children in West Africa will have options for milk that don't have to come out of a tin can from Europe like I grew up with, but that they too have access to and can consume a cup of fresh milk.
Ladies and gentlemen, we have plenty of work to do. So let's get to it. Thank you and enjoy the convention.
- http://chartsbin.com/view/1489
- http://www.mixmarket.org/mfi/country/Kenya
- http://www.igad-lpi.org/publication/docs/IGADLPI_WP03_11.pdf
- Ivey Business Journal, Oded Shenkar, March 2011


text:
State Flags
A U.S. state flag from Carrot-Top is a wonderful way to show off your state pride! More than a symbol—a state flag tells your state's unique story. We have all 50 U.S. state flags for sale as well as U.S. territory flags such as the Puerto Rico flag. Constructed of our exclusive Beacon® nylon or Patriarch® polyester material, our outdoor state flags are quality-made with the industry's best guarantee. We also carry the best in U.S. state flags and U.S. territory flags for indoor use.
For more information about each U.S. state flag, click on one of the images below to filter down your choices by state or territory. For more information about our U.S. state flags, scroll all the way down to the bottom of this page.
2 Items
- Outdoor Texas FlagsStarting At: $12.50
- Texas Field FlagStarting At: $535.00
2 Items
U.S. State Flags and U.S. Territory Flags from Carrot-Top
More than just a symbol—a state flag represents your state's heritage and tells your state's unique story! U.S. state flags from Carrot-Top Industries come in both indoor and outdoor models. Both are constructed of the finest materials and feature the best guarantee in the industry. Sizes span from mini flags to giant 8' x 12' flags to suit a variety of needs and settings. We also stock a great selection of U.S. state flag pins to help show your state pride on the go!
Our outdoor state flags are made of our exclusive flag fabrics, Beacon® nylon and Patriarch® polyester. Our Patriarch® polyester flags are tough and stand up to high winds for long periods of time. These flags feature a beautiful textured appearance, similar to that of cotton. Our Beacon® nylon flags are both lightweight and durable, quick-drying, and easy-to-fly—even in slight wind.
Indoor U.S. State Flag Sets
There are a variety of options to choose from with indoor U.S. state flag sets from Carrot-Top! Our telescopic sets can be adjusted from 5' to 9' and come in wood-grained, gold, and chrome to match your décor. We also carry an indoor jointed-oak finish in 8' and 9', which work with 3' x 5' and 4' x 6' indoor U.S. state flags.
Looking to display all 50 U.S. state flags indoors? Don't miss our 50 State Flag Sets, perfect for schools, businesses, government offices, national parks, and more! For desk display, we also offer a smaller option in the Mini U.S. State Flags Set as well as a polyester set with a base.
Pair your state flag with one of our magnificent U.S. flags, a U.S. city flag, a military flag, or a custom flag of your choice! At Carrot-Top, we not only specialize in flags, we also offer everything you need to complete your flag display—from flagpoles to indoor flag sets, to flag pole accessories. For questions, or to place your order, give us a call at 800-628-3524 to speak with a friendly and knowledgeable customer service representative today.


text:
The Dynamic Edition of the Law Digest is an exclusive benefit of membership in the New York State Bar Association.
If you are a NYSBA member and have not logged in, you will be prompted to do so. VIEW THE DYNAMIC VERSION NOW
Nonmembers, join now and start reading the Law Digest today! JOIN NOW TO VIEW THE DYNAMIC VERSION
Virtually all state court
practitioners, no matter their particular specialties, have one thing in
common: they have to navigate the vagaries of state practice and
procedure. The New York State Law Digest
publishes significant procedural developments, whether they come from
important decisions of the Court of Appeals or other New York state (or
federal) courts, statutory or rule amendments or particular local practice
issues. The Law Digest keeps NYSBA members updated on issues that
impact their everyday practices of law. Edited by David L. Ferstendig, the Law Digest is published monthly and distributed to members free
of charge, as a benefit of membership.
About the Editor
Reprint Permission
Disability Accommodations
The New York State Law Digest is copyrighted by the New York State Bar Association. The copying, reselling, duplication, transferring, reproducing, reusing, retaining or reprinting of this publication is strictly prohibited without permission.© New York State Bar Association. All rights reserved. ISSN 2379-1225 (print) ISSN 0028-7636 (online)
For NYSBA members only! This electronic version of the NYSBA Law Digest allows the user to easily navigate through the Law Digest and includes the ability to access live links and to search past issues. It can be accessed at www.nysba.org/NYSBALawDigest. Members will need to log in to the NYSBA website. If you need login help, please call our Member Resource Center at 800-582-2452, or contact the Member Resource Center by email at firstname.lastname@example.com.


text:
KoobFace Loves Its Hosting Service
Okay, so you've heard about KoobFace, the new piece of malware that is infecting Facebook users this week.
The thing that burns me up about KoobFace and things like it is that they would barely matter if hosting companies were better regulated and occasionally policed.
Here's what we know. KoobFace, like most pieces of malware, tries to redirect users away from their intended destination to a site loaded down with more malware, or designed to fool you into downloading a fake antivirus product, etc etc.
KoobFace, in what many would consider an ironic act, is reportedly re-pointing users towards Geocities.com sites.
It is no secret that the malware manufacturers rely on hosting companies either implicitly (please abide by your SLA and ensure you don't remove our server from the net for at least 48 hours even if requested to do so) or explicitly (we know what you're doing and we like your money).
Let's call it as it is: Without a destination to redirect users to, many crimeware writers don't have a business.
Robert Sandilands recently blogged about the dramatic effect of closing down one bad hosting company in California. Spam dropped globally by a remarkable percentage - just from closing that one company.
Recommendation: Hosting companies should immediately be forced by the DHS to adopt a KYC, or "Know Your Customer" policy similar to the one that banks use when they sign up a new customer.
I personally think that would help greatly. At a minimum, there should be more similar policing actions like the one taken in California.
I guarantee you that if hosting companies were suddenly made responsible for the malware sitting on their servers - or at the very least, for checking that the folks renting them are not criminals - things would get easier for IT guys to control, and we could start building a safer online world based on certified and proven safe destinations - and responsible hosting companies.


text:
The Controversial Rise in Manimony
Samantha London was a pretty, 24-year-old secretary when she met her future husband. He was in his 50s, a charming and successful businessman, making a half-million dollars a year. When she was 26, they began dating. When she was 28, they got married. It was her first marriage, his fifth. London could easily have enjoyed the good life as a trophy wife, but she had ambitions beyond cocktail parties and going to the gym. While they were dating, she quit her $35,000-per-year secretary job and landed a sales position at a real estate firm. She worked hard - and she had the touch. Her first year, she earned $100,000. The next year, her take was $500,000. Soon, she says, she was topping $1 million.
As her career soared, her husband's company faltered, then folded. But for the first time in his life, he was married to a woman who worked. So he didn't rush to find another job. He kicked back, dabbled in real estate, and earned enough to pay a few bills but not much else. While she was working 15- and 16-hour days, he could be found at home, noodling on the computer. Within three years, her resentment grew so overwhelming that she asked to end the marriage. But for that to happen, London, now 38, had to agree to pay her 66-year-old ex-husband an out-of-court settlement of $200,000.
It's a rueful milestone in our inexorable march to equality: Across the nation, divorce courts are increasingly ordering women to pay "manimony" (called "maintenance" or "support" in some states) to their ex-husbands. According to the U.S. Census Bureau, men represented just over 2 percent of the 448,000 Americans who received alimony in 2000. Nine years later (the latest year for which statistics are available), that figure had quadrupled. "I probably had three cases involving women paying maintenance over the past five years. Now I have three cases at the same time," says Marta Papa, a St. Louis divorce attorney.
Since in most states alimony awards are based on nothing but cold, hard economics - the one who makes the most money pays - it is, without a doubt, one more mark of women's achievements in the professional world that so many more are shelling out manimony to their exes. But ask any woman who's had to write that check how she feels about it, and brace yourself for some serious blowback. "Women having to pay spousal support are the most difficult clients to represent because they are so damn angry," observes Lisa Helfend Meyer, a family law attorney in Los Angeles. "They are offended by the notion that they would have to continue to pay for an able-bodied man."
Especially when that able-bodied man likely kicked in very little around the house. Helfend Meyer cites the resentment among her successful female clients who insist that, even as they tended to their demanding careers - fielding calls at all hours, working weekends - they still managed to, as she puts it, "do everything" when it came to the kids and the household. Good luck finding a male exec who could rattle off the names of his kids' teachers, coaches, and pediatricians the way Mom can, even as Mom runs a multimillion-dollar business.
"My guess is a lot of the anger is because they were pulling more than their weight in the marriage," says lawyer Linda Hirshman, author of Get to Work: A Manifesto for Women of the World. Not just earning more money, she stresses, but "bearing the lion's share of the domestic labor." Add to that the fact that in many so-called no-fault divorce states, such as California and New York, the reason for the breakup can't be used in determining alimony. "He can be a serial cheater and she still has to pay support," says Helfend Meyer. "I see cases like that all the time."
And just as men have long griped that alimony condemns them to stifling careers just to support their ex-wives' Neiman Marcus habits, some women find it galling that their financial obligations to their exes limit their lifestyle choices. Papa, the St. Louis divorce attorney, is currently mediating a case involving a 40-something couple with school-age children. The wife, a corporate bigwig, earns about $500,000 per year in salary and bonus. The husband stopped working early in the marriage to become their children's primary caregiver. Now he wants alimony for life, claiming his stay-at-home-dad status has irrevocably damaged his career. She's thinking of scaling back, maybe even remarrying, and doesn't want to be locked in to her demanding job just to pay alimony.
"Her argument is, 'Look, I work 100 hours a week. I'm burning out. I want to quit my job, but I can't if I have to pay you maintenance,'" says Papa, who isn't sure how the case will work out. After all, she notes, if the roles were reversed, any judge would tell the man: too bad. "They would say, 'You have a family to support.' I've seen them say that to men for so long. Now there's been a huge shift in the way courts are treating women during divorce."
That's the situation Liane Bruno-Bathey, 43, of La Jolla, California, finds herself in today. Every two weeks, she writes her unemployed ex-husband a check for $2,727 in alimony and child support, even though their two teens are with her most days. But that's not all. About half-way into their 15-year marriage, Bruno-Bathey started a business - a record-keeping firm for IRA accounts. Her husband had nothing to do with the endeavor. Still, under California law he was entitled to half the value of it when they divorced. She now owes him about $1 million, which she will pay out in several lump sums over the next five years.
"It's difficult to swallow," Bruno-Bathey says, though she concedes that she's in a better position than the countless divorcées who are financially dependent on their exes. "It does, in a sense, give you a feeling of success and empowerment. I'm able to take care of myself, my children - and my ex-husband, for whatever that's worth," she says. According to their divorce decree, Bruno-Bathey's ex can't seek any more money, even if her business suddenly takes off. There is solace in this. "It does give me a little more motivation to make my business more successful than what it was during my marriage," she adds with a sly laugh.
Meantime, the rest of her life is back on track. She's since remarried - to "an amazing man," she says. "So this story will have the ultimate happy ending in December 2015" - the date of her last alimony payment.
Reprinted with Permission of Hearst Communications, Inc. Originally Published: The Controversial Rise in Manimony


text:
Lafayette Parish School Bus And Car Collide On Highway 90
Louisiana State Police Troop I Spokesman Stephen Hammons tells KPEL that four people in a passenger car have died after colliding with a Lafayette Parish School bus.
Lafayette Parish School System spokesperson Angela Morrison says several students on the bus sustained minor injuries, while a coach on the bus is being treated for severe injuries.
The Lafayette High baseball team was traveling to Berwick to play a game when the crash happened.
A car that was traveling in the opposite direction had a tire blowout, and the car crashed the median crashing into the bus.
Assistant Superintendent Sandra Billeadeau and Transportation Director Damon Evans have been in touch with state police and local hospitals and are coordinating the district's response.
Morrison says as in all accidents involving LPSS buses, the driver will be tested for alcohol or other substances, but at this time we have no reason to believe the bus driver to have been at fault.
Morrison says in fact, state police have indicated to them that her actions likely prevented greater injury to her passengers.
The four people in the passenger car died at the scene.
The crash happened in the 8000 block of the Hwy 90 E. Frontage Road which is in the Centerville area.
The school system quote says, ""At this time, we are working to obtain more information and confirm the status of those taken to area hospitals. We are deeply saddened by this tragic loss of life and our hearts go out to the family of the victims."


text:
FPA necesitaba un nuevo diseño de página web y lanzó un concurso de diseño en 99designs.
Un ganador ha sido elegido entre 29 diseños de 6 diseñadores freelance.
Foreign Policy Association
The Foreign Policy Association is the oldest non-profit in the U.S. dedicated to educating Americans about world affairs. Founded in the 1918, the FPA is fiercely independent and community driven. We provide major services to the international affairs community, such as career development, job postings, event listings and networking opportunities.
Our target audience is made up, broadly, of the international affairs community - including students and foreign affairs professionals. More specifically, our audience is made up of: High School Students; Graduate Students in International Affairs, Development Workers, Diplomats, Journalists, Non-Profit employees and Think Tank employees.
Our current design is better suited to an information heavy site for an older audience.
We want to move our focus from delivering long form content to delivering service information (job listings, event listings, career alerts, video) to a 30 something audience. We are looking for an updated web 2.0, clean design with plenty of white space, that moves toward a magazine style layout with rich user interface elements. The incorporation of media blocks, intro blocks and some large typography elements could be a plus too. Some form of data grid display is required to be incorporated.
The attached content wireframe will provide an idea of what information we would like to communicate on the homepage. Do not feel like you need to follow the layout in the wireframe, we will leave it up to you as to how we can most efficiently get across this information in a clean updated light design which is attractive to a 30 something audiences.


text:
Reed Hastings, CEO of US video streaming company Netflix, says that the current state of cloud computing is akin to the era before compilers took some of the heavy lifting away from coding.
Netflix started its move to Amazon's cloud in late 2009, and according to Hastings, who addressed the AWS re:Invent customer conference in Las Vegas, 95 per cent of the company's computation and storage is provided by Amazon Web Services.
"We've got some remaining low value systems that we haven't yet converted but we hope by the end of next year to be the largest business in the world that's 100 per cent on AWS outside Amazon retail," Hastings said.
Hastings said that Netflix was ahead of its time when it started to shift to the cloud, but it had little choice due to extraordinary growth. "So streaming at that time in 2008 was about a million hours a month and now it's about a billion hours a month," Hastings said. "So we've had this thousandfold ramp up in computational resources necessary over just four years ... and so we had to take some risks.
"And doing that kind of build up of your own data centres was going to be challenging. And it's worked out great for us." The agility of cloud computing and the cost curve, with AWS dropping prices as more customers move to the cloud, had both worked in Netflix's favour.
However, Hastings added that cloud computing was still in its early days, likening it to programming in assembler.
"As fundamentally fantastic as AWS is, we're really still in the first, very primitive, first assembly language kind of phase of cloud computing. And when you have to pick individual instance types — m1, m2, m3 — you know something's wrong, right.
"You as a developer shouldn't have to be picking the individual instance types. And it reminds me a lot [of] when I first started in computing and register allocation was the big deal and how you allocated register made a huge difference in performance; and when you loaded and unloaded them.
"And then this magical thing compilers came along and the compilers did an awfully good job at register allocation and then only on occasion would you have to drop into assembly code and do your own register allocation... So we're kind of at that stage before the compiler and over next five or 10 years things will happen to make cloud computing much easier, when you don't have to do things like pick instance types."
Hastings said he was anticipating the ability to move running live instances, which will be "the next stage of virtualization for all the cloud providers", letting providers find the best type of instance for a customer's cost profile.
Rohan Pearce traveled to AWS re:Invent as a guest of Amazon.
Rohan Pearce is the editor of Techworld Australia and Computerworld Australia. Contact him at rohan_pearce at idg.com.au.
Follow Rohan on Twitter: @rohan_p


text:
In 30 games as the Houston Astros centerfielder this season, Jordan Schafer hit .245 with one home run and six RBI. In one night as the driver of a 2008 Land Rover in Tampa yesterday, Schafer hit one joint and kept additional marijuana "in a plastic container and in three peanut butter cups."
Police: Major League Baseball player arrested for smoking pot in front of officers [ABC Action News] (H/T Eric G.)
Jordan Schafer [Astros]