Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
To use ArchiveBot, drop by #archivebot on EFNet. To interact with ArchiveBot, you issue commands by typing it into the channel. Note you will need channel operator permissions in order to issue archiving jobs. The dashboard shows the sites being downloaded currently.
There is a dashboard running for the archivebot process at http://www.archivebot.com.
ArchiveBot's source code can be found at https://github.com/ArchiveTeam/ArchiveBot.
OneGet a unified package management interface component with a set of managed and native APIs, a set of PowerShell cmdlets, and a WMI provider. The component accepts both Microsoft-provided and 3rd party-provided plugins which extend the functionality for a given package type.
The current prototype consists of:
OneGet Core – Provides the unified interface for software discovery, installation and inventory (SDII). Handles the loading and multiplexing of plugins and provides isolation for them. Exposes APIs for package management plugins to access common features. Defines a set of APIs that host applications should implement when consuming the library.
OneGet PowerShell Module– implements a set of PowerShell cmdlets that give users access to the functionality of the OneGet Core.
Prototype Chocolatey Plugin– a prototype plugin for the OneGet Core module that implements a Chocolatey-compatible package manager. This is a from-scratch implementation of the Chocolatey client, and doesn’t share code with the original.
The original Chocolatey project was built as a set of PowerShell functions wrapped up with batch files, and wasn’t built in such a way that could be easily or efficiently adapted to working in the OneGet plugin architecture.
Our prototype implementation of Chocolatey is written from scratch in C#, and offers much tighter integration with OneGet, than would be possible if we just wrapped the existing Chocolatey. This greater degree of integration offers performance benefits, as well as the future ability to expose the functionality via managed and native APIs, along with manageability via WMI. This also gives us the opportunity to deliver security and service improvements to Chocolatey as we proceed.
We're going to work with the Chocolatey project to have one single chocolatey plugin that meets everyone's needs : see Rob's post
The current implementations of Chocolatey has a tight, small-community built up around them, and packages are published by those involved in the community. Certainly it currently has a lot of implicit trust of the package publishers, and as such, could easily be subverted for nefarious purposes. Our goal is to work with the community to drive the design and implementation of Chocolatey and drastically improve the security and verifiability of Chocolatey packages so that consumers are protected from malware.
Today, just Chocolatey. We will certainly be working on more in the future.
Very Soon! Plugins can be written in .NET or PowerShell modules, and shortly after the CTP, we should be prototyping the native bindings which would permit plugins written in any language that can build a .DLL. Wrapping of existing package managers can easily be done by writing a script in PowerShell, and is probably the simplest short-term solution for existing systems.
Part of our work with the community is to develop a central hub for plugins that can be dynamically discovered and installed so that they don't have to ship them in-box. Policies will permit consumers to decide which plugins they allow and for what purposes.
OneGet is designed to be a package-management-manager. It will expose a plugin APIs for third-party package management systems to plug into it, as well as APIs for applications to access diverse package-management systems without having to code for each one. Chocolatey (the original) does support multiple package types (cygwin, ruby, etc), but isn't designed to support WMI, PowerShell, Native and Managed APIs.
OneGet includes a (new) prototype implementation of the Chocolatey package manager.
OneGet should also be shipping with PowerShell, which means that eventually, it should be in-box in future versions of Windows.
