DOCSLIB.ORG

US Department of the Army Civil Disturbance Plan “GARDEN PLOT” 10-September-1968

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
US Department of the Army Civil Disturbance Plan “GARDEN PLOT” 10-September-1968 Description of document: US Department of the Army Civil Disturbance Plan “GARDEN PLOT” 10-September-1968 Requested date: 23-February-2009 Released date: 24-March-2009 Posted date: 09-September-2009 Source of document: U.S. Army Center for Military History 103 Third Ave., Building 35 ATTN: DAMH-FPR Fort McNair, DC 20319-5058 Fax: (202) 685-4593 Note: The DOD Civil Disturbance Plan, nicknamed “GARDEN PLOT”, was superseded after the events of September 11, 2001. The replacement to Garden Plot is Concept Plan (CONPLAN) 2502, also confusingly known as CONPLAN 3502, and is the responsibility of U. S. Northern Command. It may be requested under FOIA by writing to: HQ NORAD USNORTHCOM/CS ATTN: FOIA OFFICER 250 VANDENBERG STREET SUITE B016 PETERSON AFB CO 80914-3804 See following page for other available GARDEN PLOT documents. The governmentattic.org web site (“the site”) is noncommercial and free to the public. The site and materials made available on the site, such as this file, are for reference only. The governmentattic.org web site and its principals have made every effort to make this information as complete and as accurate as possible, however, there may be mistakes and omissions, both typographical and in content. The governmentattic.org web site and its principals shall have neither liability nor responsibility to any person or entity with respect to any loss or damage caused, or alleged to have been caused, directly or indirectly, by the information provided on the governmentattic.org web site or in this file. The public records published on the site were obtained from government agencies using proper legal channels. Each document is identified as to the source. Any concerns about the contents of the site should be directed to the agency originating the document in question. GovernmentAttic.org is not responsible for the contents of documents published on the website. Four GARDEN PLOT-related documents are available from governmentattic.org: 1. US Department of the Army Civil Disturbance Plan “GARDEN PLOT” 10-September- 1968 –– available here: (This document) 2. US Air Force (USAF) Reserve Operations Plan Number 355-10 – Employment of USAF Resources in Civil Disturbances, Nickname: GARDEN PLOT, 15-November-1968 – available here: USAF-ROP355-10_GardenPlot_1968 3. US Department of the Army Civil Disturbance Plan “GARDEN PLOT” prepared for the Department of Defense (DoD), 3 August 1978 – available here: ArmyCivilDisturbPlanGardenPlot_1978.pdf 4. US Department of the Army Department of Defense (DoD) Civil Disturbance Plan, “GARDEN PLOT,” 15 February 1991 – available here: USArmyCivilDisturbPlanGardenPlot_1991.pdf CI-I SSIFIED DEPARTMENT OF THE ARMY CIVIL DISTURBANCE PLAN 10 September 1968 1\/· ."-----" .~------~-_._-----~--~-- Headquarters, Department of the Army Washington, D. C. 203LO PREFACE 1. The titie of this plan is the Department of the Army Civil Disturbance Plan. 2. The nickname applicable to this plan is GARDEN PLOT. For operational consistency, Military Services, Department of Defense (DOD) components, and subordinate commands will use this nickname in civil disturbance plans. 3. The Constitution of the United States and numerous statutes provide the President with authority to intervene with Federal armed forces within the 50 states, District of Columbia, Common­ wealth of Puerto Rico, US possessions and territories, or any political subdivision thereof in case of civil violence or other disturbances to: a. Aid state authorities at the request of the state. b. Enforce the laws of the United States in any state or territory. c. Protect the civil rights of citizens within a state. 4. Authority exists to assist civil authorities with military resources short of Federal military intervention when certain necessary conditions discussed in the body of this plan are met. 5. The Secretary of the Army has been designated the Executive Agent for the Department of Defense in all matters pertaining to the planning for, deployment and employment of military resources in the event of civil disturbances. In addition, a Directorate for Civil Disturbance Planning and Operations (DCDPO), under the Chief of Staff, US Army (CofSA) has been established by the DOD Executive Agent. This Directorate plans for, coordinates and directs the employment of all designated Federal military resources for the DOD Executive Agent in civil distur­ bance operations and serves as the point of contact for DOD in all such matters. DOD components having cognizance over military resources are responsible for supporting the DOD Executive Agent through the DCDPO in matters pertaining to civil disturbances. i FO~ '% ' 'I' .:" UNctAS~:;IFIED-aBlmlCIlt m 6. The provlslons of this plan are applicable in the 50 states, District of Columbia, Commonwealth of Puerto Rico, US possessions, territories, or any political subdivisions thereof. The Panama Canal Zone is exempted from the provisions of this plan. Measures taken by military forces to cope with civil disturbances occur­ ring in the Panama Canal Zone will be under the provisions of Section 35, Title 2, Canal Zone Code, 1962 (CZC35). 7. This plan provides gUidance for development of plans to support civil disturbance operations by the Military Services, unified commands, and other DOD components. 8. This plan bears the overall classification CONFIDENTIAL because of the sensitivity of content and to protect information regarding plans for employment of United States military resources. Dissemination of information contained herein will be on a need-to-know basis. Dissemination of portions of this plan outside of DOD will be in accordance with paragraph 32, AR 380-5 and paragraph 5, AR 345-15, and applicable regulations of other Services. 9. This document contains information affecting the National Defense of the United States within the meaning of the Espionage Laws, Title 18, United States Code, Section 793. The transmission or communication of information contained herein, in any manner, to an unauthorized person is prohibited by law. 10. The propo~ent of this plan is the Director for Civil Distur­ bance Planning and Operations. Recommended changes to this plan will be submitted to the Director for Civil Disturbance Planning and Operations, ATTN: CDPO-PL-IS, Department of the Army, Washington, D. C. 20310. 11. Changes to this plan will normally be furnished in the form of complete page replacements. 12. Department of the Army Civil Disturbance Plan, 1 Feb 68, will be superseded by this plan on order. All messages and other communications pertaining to Civil Disturbance Planning and Operations which predate the date of execution of this plan, and which conflict with provisions of it, will be rescinded. ~d16E8N~ JOP ii1EflfI' J HOD. gyrX ""~.....;... TABLE OF CONTENTS CONTENT PAGE NUMBERS Preface i Thru ii Table of Contents iii Thru vi References vii Thru ix Basic DA Civil Disturbance Plan I Thru 10 Annex A- Task Organization, Forces, and A-l Thru A-S Reaction Times Appendix 1 - Model Units To be published Appendix 2 - Civil Disturbance Condition To be published ( CIDCON) Annex B- Intelligence B-I Thru B-8 Appendix I- Air Recon Request B-I-I Annex C- Concept of Operations C-I Thru C-S Appendix I- Warning Order C-I-I Thru C-I-2 Appendix 2 - Notification of Civil Distur- C-2-1 Thru C-2-2 bance TF Commander's Reconnaissance Appendix 3 - Personal Liaison Officer, C-3-1 Chief of Staff, US Army Appendix 4 - Presidential Proclamation C-4-1 Appendix 5 - Executive Order C-S-I Thru C-S-2 Appendix 6 - CofSA Letter of Instruction C-6-l Thru C-6-11 Appendix 7 - Calling Army and Air NG Units C-7-l Thru C-7-3 Appendix 8 - DA Message Mobilizing Reserve Units C-8-l Thru C-8-2 Appendix 9 - Special Instructions C-9-l Thru C-9-4 Annex D- Logistics D-l Thru D-3 Appendix I- Suggested Accompanying Supply D-l-l Thru D-l-4 and Equipment List Appendix 2 - Resupply Policy D-2-l Thru D-2-3 Appendix 3 - Service Support Guidance D-3-l Thru D-3-S Appendix 4 - Pre-positioned Equipment and D-4-1 Thru D-4-3 Munitions TABLE OF CONTENTS (cont) CONTENT PAGE NUMBERS Annex E- Personnel E-l Thru E-6 Appendix 1 - Medical Support E-l-l Thru E-1-2 Appendix 2 - Detainee Turnover Record E-2-l Thru E-2-2 Annex F- Information F-l Thru F-5 Appendix 1 - Troop Orientation F-l-l Thru F-1-2 Annex G- Communications-Electronics G-l Thru G-8 Appendix 1 - Standard City Wiring Package G-l-l Tab A- List of Prewired Cities G-l-A-l Thru G-l-A-2 Appendix 2 - Leased Communications Circuits G-2-l Thru G~2-2 Appendix 3 - Augmentation C-E Equipment G-3-l Thru G-3-3 Tab A- Items Pre-positioned and Composition of Packets Tab B- Procedures to Obtain C-E G-3-B-l Equipment for Active Army and Called National Guard Tab C- Procedures to Obtain C-E Equipment G-3-C-l State National Guard Appendix 4 - Audio Visual G-4-l Thru G-4-5 Tab A- Audio-Visual Support Centers G-4-A-l Thru G-4-A-5 Tab B- Recommended Team Package G-4-B-l Thru G-4-B-2 Appendix 5 - Communications Support Require­ G-5-l Thru G-5-~ ments (USASTRATCOM) Annex H- Command Relationships H-l Appendix 1 - Command Relationships for H-l-l Planning Appendix 2 - Command Relationships for H-2-l CONUS Deployment and Redeployment Appendix 3 - Command Relationships for Employment H-3-l Annex I- Planning 1-1 Thru 1-4 iv TABLE OF CONTENTS (cont) CONTENT PAGE NUMBERS Appendix 1 - Priority Objective Areas 1-1-1 Thru 1-1-5 Appendix 2 - Format - Civil Disturbance 1-2-1 Thru 1-2-7 Information Planning Packet Tab A- Map Symbols I-2-A-1 Tab B- Distribution of Packets I-2-B-l Appendix 3 - Services, Unified Commands, 1-3-1 USCONARC,
Load more

Recommended publications
  • 1921 Tulsa Race Riot Reconnaissance Survey
    1921 Tulsa Race Riot Reconnaissance Survey Final November 2005 National Park Service U.S. Department of the Interior CONTENTS INTRODUCTION 1 Summary Statement 1 Bac.ground and Purpose 1 HISTORIC CONTEXT 5 National Persp4l<live 5 1'k"Y v. f~u,on' World War I: 1896-1917 5 World W~r I and Postw~r ( r.: 1!1t7' EarIV 1920,; 8 Tulsa RaCR Riot 14 IIa<kground 14 TI\oe R~~ Riot 18 AIt. rmath 29 Socilot Political, lind Economic Impa<tsJRamlt;catlon, 32 INVENTORY 39 Survey Arf!a 39 Historic Greenwood Area 39 Anla Oubi" of HiOlorK G_nwood 40 The Tulsa Race Riot Maps 43 Slirvey Area Historic Resources 43 HI STORIC GREENWOOD AREA RESOURCeS 7J EVALUATION Of NATIONAL SIGNIFICANCE 91 Criteria for National Significance 91 Nalional Signifiunce EV;1lu;1tio.n 92 NMiol\ill Sionlflcao<e An.aIYS;s 92 Inl~ri ly E~alualion AnalY'is 95 {"",Iu,ion 98 Potenl l~1 M~na~menl Strategies for Resource Prote<tion 99 PREPARERS AND CONSULTANTS 103 BIBUOGRAPHY 105 APPENDIX A, Inventory of Elltant Cultural Resoun:es Associated with 1921 Tulsa Race Riot That Are Located Outside of Historic Greenwood Area 109 Maps 49 The African American S«tion. 1921 51 TI\oe Seed. of c..taotrophe 53 T.... Riot Erupt! SS ~I,.,t Blood 57 NiOhl Fiohlino 59 rM Inva.ion 01 iliad. TIll ... 61 TM fighl for Standp''''' Hill 63 W.II of fire 65 Arri~.. , of the Statl! Troop< 6 7 Fil'lal FiOlrtino ~nd M~,,;~I I.IIw 69 jii INTRODUCTION Summary Statement n~sed in its history.
    [Show full text]
  • Performance Study of Real-Time Operating Systems for Internet Of
    IET Software Research Article ISSN 1751-8806 Performance study of real-time operating Received on 11th April 2017 Revised 13th December 2017 systems for internet of things devices Accepted on 13th January 2018 E-First on 16th February 2018 doi: 10.1049/iet-sen.2017.0048 www.ietdl.org Rafael Raymundo Belleza1 , Edison Pignaton de Freitas1 1Institute of Informatics, Federal University of Rio Grande do Sul, Av. Bento Gonçalves, 9500, CP 15064, Porto Alegre CEP: 91501-970, Brazil E-mail: [email protected] Abstract: The development of constrained devices for the internet of things (IoT) presents lots of challenges to software developers who build applications on top of these devices. Many applications in this domain have severe non-functional requirements related to timing properties, which are important concerns that have to be handled. By using real-time operating systems (RTOSs), developers have greater productivity, as they provide native support for real-time properties handling. Some of the key points in the software development for IoT in these constrained devices, like task synchronisation and network communications, are already solved by this provided real-time support. However, different RTOSs offer different degrees of support to the different demanded real-time properties. Observing this aspect, this study presents a set of benchmark tests on the selected open source and proprietary RTOSs focused on the IoT. The benchmark results show that there is no clear winner, as each RTOS performs well at least on some criteria, but general conclusions can be drawn on the suitability of each of them according to their performance evaluation in the obtained results.
    [Show full text]
  • Operating in a New Environment
    EMBEDDED DESIGN OPERATING SYSTEMS lthough the concept of the IoT was Ioated around the turn of the Millennium, it is A only recently that the approach has gathered significant momentum. But, because it is a blanket term, IoT is not only being applied to large and small applications alike, it is also being applied in a wide range of end markets. With such a spread, it will come as no surprise to discover that one size does not fit all when it comes to operating systems. At the high end of the market, companies like Intel are vying to provide a complete solution. Alongside its processor technology, Intel can integrate Wind River’s VxWorks operating system and McAfee security software to create a system capable of handling high levels of complexity. But those developing wearable devices, for example, may not want to take advantage of such a system; they may well be looking for an OS that runs in a very small footprint but, nonetheless, offers a range of Operating in a new necessary features while consuming minimal amounts of power. ARM has had its eyes on the sector for some time and, last year, rolled out environment a significant extension to its mbed programme. Previously, mbed was an embedded development community The Internet of Things is posing challenges to OS developers. with ambitions similar to those of Arduino and Raspberry Pi. But mbed How are they responding? By Graham Pitcher. now has a much bigger vision – the IoT. As part of this approach, it is creating mbed OS (see fig 1).
    [Show full text]
  • RIOT: an Open Source Operating System for Low-End Embedded Devices in the Iot Emmanuel Baccelli, Cenk Gundo¨ Gan,˘ Oliver Hahm, Peter Kietzmann, Martine S
    This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2018.2815038, IEEE Internet of Things Journal 1 RIOT: an Open Source Operating System for Low-end Embedded Devices in the IoT Emmanuel Baccelli, Cenk Gundo¨ gan,˘ Oliver Hahm, Peter Kietzmann, Martine S. Lenders, Hauke Petersen, Kaspar Schleiser, Thomas C. Schmidt, and Matthias Wahlisch¨ Abstract—As the Internet of Things (IoT) emerges, compact low-end IoT devices. RIOT runs on minimal memory in the operating systems are required on low-end devices to ease devel- order of ≈10kByte, and can run on devices with neither MMU opment and portability of IoT applications. RIOT is a prominent (memory management unit) nor MPU (memory protection free and open source operating system in this space. In this paper, we provide the first comprehensive overview of RIOT. We cover unit). The goal of this paper is to provide an overview of the key components of interest to potential developers and users: RIOT, both from the operating system point of view, and from the kernel, hardware abstraction, and software modularity, both an open source software and ecosystem point of view. conceptually and in practice for various example configurations. We explain operational aspects like system boot-up, timers, power Prior work [28], [29] has surveyed the space of operating management, and the use of networking. Finally, the relevant APIs as exposed by the operating system are discussed along systems for low-end IoT devices.
    [Show full text]
  • A Comparative Study Between Operating Systems (Os) for the Internet of Things (Iot)
    VOLUME 5 NO 4, 2017 A Comparative Study Between Operating Systems (Os) for the Internet of Things (IoT) Aberbach Hicham, Adil Jeghal, Abdelouahed Sabrim, Hamid Tairi LIIAN, Department of Mathematic & Computer Sciences, Sciences School, Sidi Mohammed Ben Abdellah University, [email protected], [email protected], [email protected], [email protected] ABSTRACT Abstract : We describe The Internet of Things (IoT) as a network of physical objects or "things" embedded with electronics, software, sensors, and network connectivity, which enables these objects to collect and exchange data in real time with the outside world. It therefore assumes an operating system (OS) which is considered as an unavoidable point for good communication between all devices “objects”. For this purpose, this paper presents a comparative study between the popular known operating systems for internet of things . In a first step we will define in detail the advantages and disadvantages of each one , then another part of Interpretation is developed, in order to analyze the specific requirements that an OS should satisfy to be used and determine the most appropriate .This work will solve the problem of choice of operating system suitable for the Internet of things in order to incorporate it within our research team. Keywords: Internet of things , network, physical object ,sensors,operating system. 1 Introduction The Internet of Things (IoT) is the vision of interconnecting objects, users and entities “objects”. Much, if not most, of the billions of intelligent devices on the Internet will be embedded systems equipped with an Operating Systems (OS) which is a system programs that manage computer resources whether tangible resources (like memory, storage, network, input/output etc.) or intangible resources (like running other computer programs as processes, providing logical ports for different network connections etc.), So it is the most important program that runs on a computer[1].
    [Show full text]
  • Operating Systems & Virtualisation Security Knowledge Area
    Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. This information is licensed under the Open Government Licence v3.0. To view this licence, visit: http://www.nationalarchives.gov.uk/doc/open-government-licence/ When you use this information under the Open Government Licence, you should include the following attribution: CyBOK © Crown Copyright, The National Cyber Security Centre 2018, li- censed under the Open Government Licence: http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels.
    [Show full text]
  • RIOT, the Friendly Operating System for The
    The friendly operating system for the IoT by Thomas Eichinger (on behalf of the RIOT community) OpenIoT Summit NA 2017 Why? How? What is RIOT? Why? How? What is RIOT? Why a software platform for the IoT? ● Linux, Arduino, … bare metal? ● But as IoT software evolves … ○ More complex pieces e.g. an IP network stack ○ Evolution of application logic ● … non-portable IoT software slows innovation ○ 90% of IoT software should be hardware-independent → this is achievable with a good software platform (but not if you develop bare metal) Why a software platform for the IoT? ✓ faster innovation by spreading IoT software dev. costs ✓ long-term IoT software robustness & security ✓ trust, transparency & protection of IoT users’ privacy ✓ less garbage with less IoT device lock-down Why? How? What is RIOT? How to achieve our goals? Experience (e.g. with Linux) points towards ● Open source Indirect business models ● Free core Geopolitical neutrality ● Driven by a grassroot community Main Challenges of an OS in IoT Low-end IoT device resource constraints ● Kernel performance ● System-level interoperability ● Network-level interoperability ● Trust SW platform on low-end IoT devices ● The good news: ○ No need for advanced GUI (a simple shell is sufficient) ○ No need for high throughput performance (kbit/s) ○ No need to support dozens of concurrent applications ● The bad news: ○ kBytes of memory! ○ Typically no MMU! ○ Extreme energy efficency must be built in! SW platform on low-end IoT devices ● Contiki ● mbedOS (ARM) ● ● Zephyr (Intel) ● TinyOS ● LiteOS (Huawei) ● myNewt ● … ● FreeRTOS ● and closed source alternatives Reference: O. Hahm et al. "Operating Systems for Low-End Devices in the Internet of Things: A survey," IEEE Internet of Things Journal, 2016.
    [Show full text]
  • Internet of Things (Iot) Operating Systems Management: Opportunities, Challenges, and Solution
    sensors Editorial Internet of Things (IoT) Operating Systems Management: Opportunities, Challenges, and Solution Yousaf Bin Zikria 1, Sung Won Kim 1,*, Oliver Hahm 2, Muhammad Khalil Afzal 3 and Mohammed Y. Aalsalem 4 1 Department of Information and Communication Engineering, Yeungnam University, 280 Daehak-Ro, Gyeongsan, Gyeongbuk 38541, Korea; [email protected] 2 Zühlke Group, Eschborn, 65760 Hessen, Germany; [email protected] 3 Department of Computer Science, COMSATS University Islamabad, Wah Campus, Wah Cantt 47010, Pakistan; [email protected] 4 Department of Computer Networks, Jazan University, Jazan 45142, Saudi Arabia; [email protected] * Correspondence: [email protected]; Tel.: +82-53-810-4742 Received: 9 April 2019; Accepted: 11 April 2019; Published: 15 April 2019 Abstract: Internet of Things (IoT) is rapidly growing and contributing drastically to improve the quality of life. Immense technological innovations and growth is a key factor in IoT advancements. Readily available low cost IoT hardware is essential for continuous adaptation of IoT. Advancements in IoT Operating System (OS) to support these newly developed IoT hardware along with the recent standards and techniques for all the communication layers are the way forward. The variety of IoT OS availability demands to support interoperability that requires to follow standard set of rules for development and protocol functionalities to support heterogeneous deployment scenarios. IoT requires to be intelligent to self-adapt according to the network conditions. In this paper, we present brief overview of different IoT OSs, supported hardware, and future research directions. Therein, we provide overview of the accepted papers in our Special Issue on IoT OS management: opportunities, challenges, and solution.
    [Show full text]
  • Exploring CTOS@
    -• EXPLORING Edna lIyin Miller, Jim Crook, and June Loy Exploring CTOS@ Edna [lyin Miller, Jim Crook, and June Loy it Prentice Hall, Englewood Cliffs, New Jersey 07632 Library of Congress Cataloging-in-Publication Data Explor1ng CTOS I Un1sys Corp. p. cm. Includes 1ndex. ISBN 0-13-297342-1 1. D1str1buted operat1ng systems (Computers) 2. CTOS. 1. Unlsys Corporat1on. CA76.76.063E954 1991 005.4'3--dc20 90-27131 CIP This book was written, edited, and composed using the CroS-based desktop publishing system, OFIS Document Designer. The system used was a CroS-based 386 workstateion with VGA graphics. The graphics were created in OFIS Graphics, then integrated into the cros Document Designer files. The printer used was an Apple LaserWriter~ Text is New Century Schoolbook. Helvetica is used for headings. Program listings are set in Courier. Cover Design: April Bishop Editing: Carol Collins Production Editing: Antoinette Kohn Illustrations: Jacqueline Mac Millan Page Design: Milena Martin-Arana II © 1991 by Prentice·Hall, Ino = A Division of Simon & Schuster - Englewood Cliffs, New Jersey 07632 The publisher offers discounts on this book when ordered in bulk quantities. For more information, write: Special SaleS/College Marketing Prentice Hall College Technical and Reference Division Englewood Cliffs, New Jersey 07632 All rights reserved. No part of this book may be reproduced, in any form or by any means, without permission in writing from the publisher. Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 ISBN 0-13-297342-1 PRE:-.ITICE-HALL INTERNATIONAL (UK) LIMITED, London PR~:NTIC~:-HALL OF AUSTRALIA PTy.
    [Show full text]
  • Lon Milo Duquette
    \n authuruuiivc exiimiriiitiiin <»f ike uurld’b iiu»st fast, in a cm tl and in^£icul turnc card V. r.Tirfi Stele op Rp.veaung^ gbvbise a>ju ftcviftsc. PART I Little Bits ofThings You Should Know Before Beginning to Study Aleister Crowley’s Thoth Tarot CHAPTER ZERO THE BOOK OFTHOTH— AMAGICKBOOK? 7^ Tarot is apoA^se^^enty-^ght cards. Tfnrt artfoter suits, as tn fnadcrrt fi/ayirtg sards, ^sjhkh art dtrs%ssdfFOm it. Btts rha Court cards nutnbarfour instead >^dsret. In addition, thare are tvsenty^turo cards called 'Truw^ " each c^vJiUh is e symkoik puJure%Atha title to itse^ Atfirst sight one suould stifrpese this arrangement to he arbitrary, but it is not. Je IS necessitated, as vilfappear later, by the structsere ofthe unwerse, stnd inparikular the Sctlar System, as symMized by the Holy Qabaloi. This xotll be explained In due course.' These a« the brilliantly concise opening words of Aldster Crowley's Tbe Book of Tbotb. When I first read them, 1 vm filled with great o^ectations. Atkst, —I thouj^^ the great mysierics of the Thoth Tarot are going to be explained to me "in due course.” At the time, I considered myself a serious student of tarot, havij^ spent three years studying the marvelous works of Paul Foster Case and his Builders ofthe Adytumd tarot and Qabalah courses. As dictated in the B.O.T.A. currictilum, I painted my own deck oftrumps and dutifully followed the meditative exercises out- lined for each of the twenty two cards- Now, vdth Aleister Crowley’s Thoth Tarot and The Book cfThoth in hand, I knew I was ready to take the next step toward tarot mastery and my own spiritual illuminaiion.
    [Show full text]
  • The Friendly Operating System for the Iot!
    The friendly operating system for the IoT! www.riot-os.org AGENDA • Internet of Things: Which OS? • RIOT in a nutshell • RIOT user and developer evolution • Roadmap www.riot-os.org 2 The Internet of Things (IoT) 512 MB 16 KB 1-2 GB > 4GB ~ 2 GB 8 KB 96 KB > 4GB IoT = programmable world www.riot-os.org 3 IoT: The operating system question IoT = programmable world www.riot-os.org 4 RIOT: The friendly IoT operating system IoT = programmable world www.riot-os.org 5 AGENDA • Internet of Things: Which OS? • RIOT in a nutshell • RIOT user and developer evolution • Roadmap www.riot-os.org 6 RIOT: Positioning "If your IoT device cannot run Linux, then run RIOT!" • RIOT requires only a few kB of RAM/ROM, and small CPU • With RIOT, code once & run heterogeneous IoT hardware – 8bit hardware (e.g. Arduino) – 16bit hardware (e.g. MSP430) – 32bit hardware (e.g. ARM Cortex-M, x86) 7 RIOT: Fact sheet • Microkernel architecture (for robustness) – The kernel itself uses ~1.5K RAM @ 32-bit • Tickless scheduler (for energy efficiency) • Deterministic O(1) scheduling (for real-time) • Low latency interrupt handling (for reactivity) • Modular structure (for adaptivity) • Preemptive multi-threading & powerful IPC www.riot-os.org 8 RIOT: IoT development made easy • Open source, community-driven • Write your code in ANSI-C or C++ • Compliant to the most widely used POSIX features such as pthreads and sockets • No IoT hardware needed for debugging – Run & debug RIOT as native process in Linux www.riot-os.org 9 RIOT: Built to connect • RIOT supports several network stacks • RIOT community has a strong commitment to use and promote open standards • e.g.
    [Show full text]
  • RTFM-Core: Language and Implementation
    RTFM-core: Language and Implementation Per Lindgren, Marcus Lindner and Andreas Lindner David Pereira and Luís Miguel Pinho Luleå University of Technology CISTER / INESC TEC, ISEP Email:{per.lindgren,marcus.lindner,andreas.lindner}@ltu.se Email: {dmrpe,lmp}@isep.ipp.pt Abstract—Robustness, real-time properties and resource effi- In this paper we present an alternative approach, based on ciency are key properties to embedded devices of the CPS/IoT a reactive programming model taking the outset of tasks and era. In this paper we propose a language approach RTFM- resources. The generic task/resource model can be summarized core, and show its potential to facilitate the development process as follows: each task is: associated to a priority and a triggering and provide highly efficient and statically verifiable implemen- event; is run-to-completion (without any notion of waiting tations. Our programming model is reactive, based on the for additional events); and may pend other events arbitrarily familiar notions of concurrent tasks and (single-unit) resources. The language is kept minimalistic, capturing the static task, (this can be seen as requesting asynchronous execution of communication and resource structure of the system. Whereas the corresponding task). A resource may be claimed for the C-source can be arbitrarily embedded in the model, and/or duration of a critical section of a task in a LIFO (hierarchical) externally referenced, the instep to mainstream development is manner (i.e., enforcing nested critical sections). minimal, and a smooth transition of legacy code is possible. A prototype compiler implementation for RTFM-core is presented. This model coincides with the notion of tasks and resources The compiler generates C-code output that compiled together used in the context of the Stack Resource Policy (SRP)[1].
    [Show full text]