What is AST?

AST (AT&T Software Technology) OpenSource software is a collection of libraries and commands for UNIX and Windows. Included are re-implementations of many POSIX and X/Open APIs and utilities. It provides a portable and efficient environment that behaves consistently across a range of operating system and hardware implementations. portable because one collection of source builds unattended on all target architectures, efficient because the underlying algorithms are continually updated to match best in class performance.

Isn't AST old technology?

Although AST has been around since the mid 80's it has kept up with the times and is actively used and supported both inside and outside AT&T. And even though the world seems to be all about small device Apps, Java, JavaScript, Cloud, etc., support for all that technology basically relies on the software pardigms introduced by AT&T Bell Labs' UNIX and C in the early 70's (.e.g., processing massive data, cheap reliable servers, VM infrastructure.) This is not a swipe at modern software practice, but a recognition that there is still a place for UNIX, C and AST technology in the current software ecology.

Why did we write AST?

Much of AST has its roots in the first releases of ksh88 and nmake in the late 80's. Hardware, UNIX operating system, and C language implementations varied wildly between vendors and System-V vs. BSD. It was very difficult to package software that would be compatible with that rapidly evolving environment. In addition, it had negative impacts on stability between releases of our own code (we do a fine job of destabilizing all by ourselves, thank you very much, so evolving target software seriously compounded the problem.) In addition, AST was being used on very large amounts of data (for the day) and some of the standard libraries were simply not up to par with the requirements (remember, commodity disks were measured in Mi bytes and memory was measured in Ki bytes.) ksh and nmake were pushing space and time boundaries not met by the (at that time de-facto) standard libraries, so we ended up designing and implementing sfio(3), vmalloc(3), and cdt(3), and never stopped.

What benefits do you see in using AST?

Portability and efficiency were early goals of the effort. This has paid off many times over. One of the joys of coding against AST is that once you get a new library or command working on your master build machine you know that, modulo resources, it has a 99% probability of building and running on any AST supported architecture.

What's so great about ``disciplines & methods'' -- isn't that just roll your own C++?

The discipline & method API style is the best concept to arise out of the AST corpus. We wish we could have learned it earlier on. It allows us to design an API once and then evolve it without forcing consumers to recode or retool. The resulting coding style places the public and private parts in the right place in the software hierarchy: algorithms are implemented in private source files, not public headers; private data is hidden in private source files, not public headers; there are no language overloading constructs to affect code readability; old code benefits from new algorithms without being recompiled; methods fit perfectly in the runtime plugin model. So yes, we like it.

Who are the authors of AST?

AST is developed primarly by Glenn Fowler, David Korn, and Phong Vo of AT&T Research. These three have been together from the start. A few of the utilities were built from GNU or BSD source code.

What are the licensing terms for AST?

AST is available under the EPL 1.0 (Eclipse Public License version 1.0) license which is an Open Source License approved by the Open Source consortium. A few utilities use BSD or GPL licenses. All of these are Open Source licenses.

Can closed source applications use AST?

The EPL license does not require you to make your source code available in order to use EPL software. The GPL license requires you to make source code available for any binaries that use GPL code. As long as you do not use any GPL code, you can use AST without making your source code available.

Why isn't AST split into smaller packages?

The decision on what components should go into what packages has always been fairly subjective. We hope that the GIT repository, started mid 2012, will eliminate the need for smaller packages.

What is ast-open package?

The ast-open package contains all of the AST Open Source. Inside AT&T there is also an ast package that contains AT&T proprietary code along with ast-open.

Is AST supported?

Currently AST is unsupported. However since AST is used internally at AT&T, it is actively maintained for internal use. By providing AST under an Open Source license, we are hoping that some organization(s) will eventually provide support for AST.

Where do I report bugs in AST?

There are two mailing groups for AST that you can use for this purpose as well as to get more AST information. ast-users@research.att.com is more general, whereas ast-developers@research.att.com is for users that are developing applications that run using AST. Anyone may read the group archives, but you must join the group before you can post to it. We are happy to receive bug fixes from users and will merge them into our base software.

Does AST conform to the X/Open standards?

The intention is to conform to the latest standards. To the best of our knowledge the documentation notes individual components that stray from the standards. If you find otherwise, send a message to ast-users@research.att.com and it will be addressed.

Which languages have been used to develop AST?

AST is written almost entirely in C and ksh(1). jmake(1), the nmake(1) JAVA component, is written in JAVA.

Why don't you incorporate some user community patches in a timely manner?

Much of AST's leverage has been through its API design. When a patch infringes on the current design, or a future design, it warrants some thought. That thought process typically can't be forced. The hardest problems involve { dgk gsf kpv } and go back and forth, sometimes for weeks. Current issues requiring more thought involve threads and process global resources: critical data structure manipulation, current working directory, signal traps, signal delivery, thread resource recovery, converting standalone commands to thread safe builtins. A guiding principle is to contain as much complexity as possible behind much simpler APIs.

Another timely patch answer:

AST is built on a build farm consisting of different UNIX and Windows systems and different compiler implementations and settings. A patch doesn't make it into a beta release until it builds and tests OK on the farm. Since AST uses the bleeding edge changes for its own build process, additional initial testing is done on the master build system before releasing it to the farm. The worst case scenario here is a patch-introduced bug that affects ksh(1) or nmake(1) and causes the next farm build to crash.