
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.
5 comments
I just wish the information on CMake was up to date – it is very tricky to do projects right with it. Especially when it comes to anything more complex than a sample project (using 3rd party libs which are not using CMake, modular projects, cross-platform build options, etc.)
We are working on this. We have created a new infrastructure for “guides” in CMake. This allows tested examples to be included in the documentation. Here is where you can see the most recent versions of them: https://cmake.org/cmake/help/git-master/index.html#guides. This is also a good resource https://crascit.com/professional-cmake/. CMake has certainly changed a lot over the years, and I hope to focus some effort in the next year on cleaning up the documentation to match the new features.
To me that echo’s one of the complaints about C++. We can’t they just make it simple and fix it! I think the same anserws apply, why is C++ still dominate relative to say D or Rust, although Rust is getting bigger, https://fossbytes.com/most-popular-programming-languages/. Sure you can do a “better” CMake and people have but they still have tiny users bases.
Anayway happy 20th, looking forward to the next 20!
I think you are using the wrong tool. CMake is primarily too build software, not to be a complete Build System, or a package manager. For full cross-platform development, look for Buildroot, if you want to work with full images. Yocto may be your choice if you want to deliver packages, instead of full system images. Linux standard distros may be your choice if you want to start from a ready built Linux system, and develop on top of that (for instance, you create your deb packages…). On Windows side, chocolatey for package management, or Build Systems like Conan and VcPkg.
Most of those solutions use CMake, Conan indeed is a python based build system heavily using CMake.
So, you are looking for a Build System. Do not try to write gazillions of CMakeLists.txt, one calling another, to build your whole system. This is the equivalent of writing those big Makefiles to build-it-all, or create a big sln file to build-it-all, and both are not modular and should be avoided for big projects, where modularity improves everything.
Thank you for your post. Valuable information. http://www.unclehouse.org/