DOCSLIB.ORG

A Bibliography of Publications About the Fortran Programming Language: Part 3: 1990–Date

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Bibliography of Publications About the Fortran Programming Language: Part 3: 1990–Date A Bibliography of Publications about the Fortran Programming Language: Part 3: 1990{date Nelson H. F. Beebe University of Utah Department of Mathematics, 110 LCB 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 E-mail: [email protected], [email protected], [email protected] (Internet) WWW URL: http://www.math.utah.edu/~beebe/ 28 April 2021 Version 2.164 Title word cross-reference [CHM91]. R3 [MC96]. SU(3) [BW12]. t [Som98]. U(a; x) [GST06a, GST06b]. V (a; x) [GST06a, GST06b]. ' [Koi09]. W (a; x) [GST11]. #55 [Och09]. #59 [Cha09]. -conjugated [KS12]. -D [WKM04, RBS93a]. + [BMV03]. −1=2; 1=2; 3=2; 5=2 [Mac98]. 1 -Dimensional [BCE93, CHM91]. -function [WKM04]. 1=2 [PS08]. $145.00 [Ano98a]. 2 [Jon92b]. -functions [Koi09]. -is [BN96]. [CMV09, RBS93a]. $22.50 -Kutta [GKKL19]. -Lattice [Ano99a, Ano99b]. $24.95 [Eme94, Ano96a]. [GAW96a, GAW96b]. -nets [Lai92a, Lai92b]. 3 [BCE93, Fuj95, SC19]. $50.00 [Ano98b]. -nodes [SG95]. -Percentiles [AS93]. -state $65 [Ano03]. 2 [FGCG94]. 29Si [SSLG91]. [CHM91]. 40Ar [Xu93]. 40Ar; 39Ar [Xu93]. (R) [LS04]. S [Lav91]. α [Jon92b]. AXBT + CXDT = E /Fortran [TBG+02]. /Java [Och09]. [Hop02, GWL+92]. B [Lai92a, Lai92b]. /release [Dig90a]. BR[B ! Xsy] [DGS08]. C1 [Ren04]. D [CHM91]. ` [KTMB02]. F [AS93]. F−− 0 [Gon01, Tay99]. 0-1 [BKK94]. [NSJD98]. L1 [Dem03]. N [Hig93a]. m 0-262-61094-9 [Eme94]. 0-471-95596-5 p1=2+iτ (x) [GST12]. π [KS12]. πps [Air04]. q 1 2 [Gon01]. 0-8493-2016-X [Tay99]. 007R1 3-540-60529-0 [Hop97]. 3-540-60530-4 [W+95, ANS95]. [Hop97]. 3.0 [Ano97c, Bra97c, KaM10, MMEH08]. 1 [Car93, McB91, Sal92]. 1-D [Car93]. 1.1 300/400 [Hew90b]. 3000 [Blu91]. 3090 [BDPW98, OA02]. 10 [Sun05]. 1003.9 [CK90, SSW91]. 3090/VF [CK90]. 32-bit [IEE92a]. 1003.9-1992 [IEE92a]. [Ano92b, Ano93d]. 3772 [Cra93]. 1003.9-1993 [IEE93b]. 1005 [JSY+20]. 3DModel4 [Bak91]. 3L [CA92, CA92]. 3rd 100k [SC19]. 10th [Glo91b, IEE96]. 11i [Rub93]. [TOML04]. 13th [HR92]. 14.9 [SMSY02]. 14/300 [SS93]. 1539-1 [Ame97b, IEC97, 4 [Ein95, Hop97]. 4.0 [PS96]. 40 [PAK+90]. Int97a, Int97b, ISO04a, ISO04b, ISO10]. 4th [CKMU94]. 1539-2 [IEC94, ISO94, Int00]. 1539-3 [IEC99, Int99]. 164 [Tou84]. 16th [FH90]. 5 [Ano97d, Bra97d, DT93, Gon01, HP95b, 186th [Ano95a]. 198x [Ame87]. 1990 KBKT94]. 524 [Bre78]. 528 [FHS78, GG99]. [STVS91]. 1990-12 [IEC90]. 1991 [Bar92]. 5th [Ban93, Fri94, IEE94a, NBC92]. 1992 [AC92, Ame92, HK93a, IEE92a]. 1993 [Hig94a]. 1994 [IEE94f, ISO94]. 1994-12 6.3/03 [Ing90a, Ing90b]. 6000 [IEC94]. 1995 [ANS95]. 1996 [IEE96]. 1997 [Bel90a, Bel90b]. 600Js [WTW90]. 64 [Ame97b, Int97a, Int97b]. 1997-12 [IEC97]. [AAC+04]. 64-bit [YYX+07]. 679 1998 [Int98a, Int98b]. 1998-12 [DDHD90]. 689 [BB91]. 690 [BD91]. 692 [IEC98a, IEC98b]. 1999 [DGL91b]. 6th [BGNP94, HMPT94]. [Int99, Met99c, Met99d]. 1999-02 [IEC99]. 199x [Ame90b]. 1st 703 [CC92a]. 7040/FORTRAN [Anoxx]. [Ano94d, Fer92, Kum94]. 705 [Hop02]. 706 [BE92, Esp98]. 707 [NPB92]. 711 [NS92]. 717 [BGW93]. 720 2 [BRH90, Car91b, Car92, CC95a, DV98, [BCE93]. 724 [AS93]. 725 [Dre93]. 729 Int90e, PAK+90, PGH+90, RBS93b, SS09, [HC94]. 730 [ARS94]. 734 [Hop98]. 751 Sch97]. 2-D [RBS93b]. 2-dimensional [Ren96a, Ren99a]. 752 [Ren96b, Ren99b]. [PT93]. 2.0 [AIS+97, BKMC96, KK01]. 755 [GJU96]. 757 [Mac96a]. 761 2.0.1 [Sun92a]. 2.1 [Wei94]. 2/3 [OC94]. [Aki96, DV00, RB98]. 762 [BLL+96]. 763 2/M [FK95]. 20 [Met99c]. 2000 [Kea96b]. 769 [Hop03]. 77 [Coc03, Int00]. 2001 [ACM01]. 2002 [AL92, Ain90, Ain91, And90, BS91a, BBB00, [Coc03, Smi00]. 2003 BK06, BSV16, BKMC96, Bor91b, Bro90a, [ACM03, AS14, FB12, MRC04, Mor15, Bro92b, Bro92a, CM92, Cha94c, CC90, Rei04, RMX05, RRX+08, RAX10]. CS90a, dCH94, Dem03, Dem06, Dem07, 2003/2008 [Mor15]. 2007 [Bjø08]. 2008 ES93a, Ein95, EKB92, Ins91a, Ell81, Ell90, [Mor15, Sht19]. 20th [Cip00]. 21st Ett90, Ett92, Ett93, Ett96, Ett97, GH18, [ACM94b, Bra03]. 22nd [ACM95b]. 23rd GHN19, GG99, GP97, GST02a, Gil01, Her90, [IEE92b]. 25-27 [Ano94p]. 25-28 [Ano93n]. HB91a, Hop02, KF92d, Lah90, LM90b, 25th [Ano94l]. 26th [Ano95b]. 292pp Lig91a, Lig91b, Manxx, MC94, MC95a, [Gon01]. 2nd Mir90, MA90, MN01, NL92, NL95a, NLN96, [HOP93, DT94, FK95, Yan94b]. O'K93, OPE+95, Pag95, Per93, Pre93a, PTV96, RZ94a, RZ94b, Rou90, Sil92a, 3 [HBG+06, Hop97, KKS+95, vH10]. Sil92b, Spe96a, SWBO93, SOP93, Sil01, 3 SW91, SB92, Spe96b, SF93, Tor91, Tre95, For97, Fur93, Glo91a, Geh95, GK06, GST12, WNO94, Wri91, Yip90, Zim07, ZB94b]. GBDB97, GOT03b, Hah94, Han92, HL94, 77-Programmen [EMR93]. 77-programs Hen95, Hop98, Hud96, HLJ95, HLJ98, IFI93, [EMR93]. 77/386 [CSS90b, CSS91, Zei92]. KLM91, Kea95b, Kea96a, Kea96b, KMR96, 77/90 [Bro92a, Bro92b]. 778 [ZBLN97]. Ker93a, Ker93c, Ker93b, KLM00]. 90 779 [Mac98]. 77D [Cho92, CFH+93]. [Kir02, KS12, KZ94a, KKH10, KH13, KZ94b, 77to90 [Pre93b]. 77toHPF [Van94b]. 780 Lig93, Manxx, MD97, Mai91, MKS+96, [Ham98]. 786 [Smi98]. 787 [AJ98, RFS98]. MHT96, MC95b, McC96, Mei95, Mer92b, 79 [Jam96]. 792 [RB99]. 794 [Wie99]. 796 MR90b, MR91, MR92, Met92a, MRG+93, [DLM99b]. 797 [RR99]. 798 [BM99]. 7ET MR93a, MR94, MR96a, Met99a, Mil04, [Eme94]. 7th [PBG+95]. Mit02, MM98, MS93b, MHdL12, NDS96, NSJD98, NLN96, NL96, NL97a, NL97b, 800 [BBB00]. 801 [WSW00]. 806 Ola93, Ola95, Ort94a, PS08, Pre93a, Pre93c, [MS00a, MS00b]. 809 [MN01]. 811 [LV01]. PA94, PTM96, PTV96, Rat95, Red95, 813 [BMR01]. 814 [Smi01]. 815 Rei92c, Rei92a, Rei92b, Rys95, SS09, Sat97, [FPR01, Has06]. 818 [DV02a]. 819 SS95, SSG+10, SSG+18, SM90, Sch93c, [GST02a]. 821 [HBG02]. 822 [GST02b]. SKM94, Shi98, SM03, Smi95b, Smi01, 828 [Ren03]. 831 [GST04a]. 833 [Ren04]. Som98, SB01, SS10, SSS99, Taq16, Tay97, 837 [ADD04]. 838 [Fab04]. 841 [HD05]. Tho97a, UM93, VCV97a, VCV97b, Wal93b, 842 [FGGL05]. 850 [GST06a]. 854 [BK06]. WD98, WAG98, WMMW97, Dub97, 857 [SMSW06]. 859 [AR06]. 860 GMC96b, GMC96a, GMC96c, GMC96f]. [KR94, McB91, KR95]. 861 [Err06]. 863 90-enhanced [And02]. 90/95 [Dem07]. 865 [GRW07]. 867 [BB07]. 869 [Fah02, MR99, Cha97a, Ein94, MR96a, [ZBW07]. 877 [Kod08]. 879 [LS09]. 881 Tay97, DG08]. 90/95/HPF [Met99a]. [FGG09]. 886 [CMV09]. 891 [RS09a]. 892 90/HPF [FSPC+02]. 900 [Tor10]. 902 [Jon09]. 893 [Ren09]. 894 [Koi09]. 896 [RBD+10]. 903 [CZ10]. 905 [TZW+10]. [LMV09]. 897 [HWS09]. 8th [Hua96]. 8X 9076 [Mra94]. 90D [Ano90b, AO90a, AO90b, AO90c, AKLS88, [BCF+94a, Ano94h, BCFH93, BCF+93a, MR87, MR90a]. BCF+93b, BCF+93c, BCF+94c, BCF+94b, BCF+94d, Cho92, CFH+93, PHHF94a, '90 [IEE90a, WN90, AL92, ABW92, PHHF94b, PH96, Pon94a, Pon94b, Rot93]. ABMS94, Aki99, AFAS99, AR06, And02, 90D/High [BCF+94a]. 90D/HPF Ano92a, Ano93c, Ano93p, Ano94o, Ano95e, [BCFH93, BCF+93b, BCF+93c, BCF+94c, Ano97d, Ano99c, AAK01, Bai94, Bai95, BCF+94b, BCF+94d, Pon94a, Pon94b]. '90s Bai05a, Bai05b, Bak95, Ber91a, BDC+96, [Edg92]. '91 [ACM91, IEE91]. 911 [Smi11]. BRdAHK04, Bla00, BGV94, BGA90, BGA94, 912 [Kod11]. 914 [GST11]. 916 [ZA11]. '92 BGA96, Bra97b, Bra97d, BG94, Bro92a, [IEE92b, IEE92d, KVK92]. 926 [Tho13]. '93 Bro97, Buc94a, Buc94c, CSC+97, Cha95a, [ACM93b, Ano93q, GGK+93, IEE93a, CCL01, CCL04, Cha94c, Cha97a, CC92b, IEE93d, KSW93]. 934 [EC13]. 936 [Kro14]. CS95, Cou91, Cou97, DLLR96, DP96, DP99, 937 [CS14]. '94 DNS98, DG08, DL97c, Del93, DDH+95, [ACM94b, BLT94, BGG+94, CGS94, DW94, DDH+96, DDHW96b, DS94, Cro92, Du 97, Fri94, HMPT94, IEE94b, IEE94f]. DV93, ES93a, Ein94, Ein95, Ein96, EPL94a, 94-VAPP [BV94]. '95 [ACM95b, HAM95b, EPL94b, EPL95, Err06, EC13, FSPC+02, Hua96, IEE95a, ABM+97, Ano94o, Ano98c, 4 Bee01a, Bee01c, Bro03, Cha97a, CS00, [Bra97a, Coc03, Fri96]. ACSL [GOBG+94]. Cou97, DDF10, DV98, DVY00, DV01, ACSL-Model [GOBG+94]. Activation DV02a, DV02b, Ein94, ECS96, FGJB19, [Ano90a]. AD [RP12]. Ada Geh96, GT03, GT07, GRE99, GRW07, [Boo81, BH90, Cha09, FBC96, Gli96, Jon09, KaM10, LS05, MR96a, MRC04, Moo95a, Moo95b, Mor81, Och09, WBS97]. Moo95a, Moo95b, RMX05, RRX+08, Sch99, Adams [Ano98b, GMC96f]. adapted Sch03, Sun05, Tay97, ANS95, vWAH+02, [Lav91]. Adapting [Fat94, Mer92b, GG99]. vH06, vH10, Gen06, Hin06, Iha06, Sch07]. Adaptive [BE92, BCE93, DN09, KK94, 95-007R1 [W+95, ANS95]. 95/2003 Mit02, AES+96, CC94, Esp98, GC03, [MRC04, RMX05, RRX+08]. 9593-1 HMS+95, SPM+94, WKM04]. adaptor [IEC90, ISO90]. 9593-1-1990 [Ame97a]. '96 [BV13, BZ94]. added [CA90]. addendum [ACM96a, ACM96b, IEE96]. 961 [BSV16]. [Hew91b]. Adding [SZAB97]. Additions 9th [IEE95a]. [HMT90]. Address [SSC00, TR96, SJ94]. Addresses [CGL+95b, CGL+93]. Adelaide = [Gom90b, RD91]. [NBC92]. ADF95 [Str05]. ADIFOR [BCC+92, BKMC96]. Adjoint A. [Tsa01]. A.R [Gon01]. A1 [GK06, GRSS02]. Adjoints [NR06]. [Bre78, Bre79]. AASHTO [Cro90]. adjusted [ZMR+91]. ADOL [GJU96]. ABBPACK [MKFB92]. ABD [AR06]. ADOL-C [GJU96]. adoption [NDSG07]. ABDPACK [MKFB92]. Abel [WJ94]. Advanced Aberth [Bin96]. Abilities [WR93]. ability [AMC01, Ben95, CZM94b, CZM94a, Don95, [Cho91, TJ90]. Absoft [Ano96b]. Abstract MKF95, MCAB+02, Tem96, Wil95a, Wil95b, [CS90b, SW94, SKP91, CM91, MKS+96, BLT94, Ben99b, CMZ94b, CMZ94a, SKM94]. Abstracting [Lor19]. FSPC+02, PGH+90, CMZ95, Ano96a]. Abstraction [Sug95, CS90b, RRX+08]. Advances [FHP+12, IEE97, Nic91]. abstracts [Sch93b]. accelerated [iSYS12]. advantage [VKB93]. Advantages accelerating [SIOS02]. Acceleration [Rei92c, Rei92a, Rei92b]. advective [Car93]. [HJ97, HE13]. Accelerators [AC17]. advice [Uni2 ]. Aeroacoustic [NOL97]. Access [Ham93, KNS95b, LP92, LP93, aerodynamic [Con92]. AeroFcn [Con92]. BK89, BxCW01, KNS95a]. accesses aeronautical [Gro91]. aerospace [DSv94]. accessible [BDH+05]. [MZ00, MZ01]. Affine [SSC00]. after accommodate [SW91]. accompany [Met92b]. against [BS91b]. Accomplishments [SZAB98]. [BSPF01, BSB+03, Ste91]. age [HK95]. Accuracy [RB99, Aki96, DV00, Nak90]. ahead [Ano95d]. Aid accurate [PG10, Wal93b]. achieved
Load more

Recommended publications
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra
    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
    [Show full text]
  • Building Performance Measurement Tools for the MINIX 3 Operating System
    Building Performance Measurement Tools for the MINIX 3 Operating System Rogier Meurs August 2006 Contents 1 INTRODUCTION 1 1.1 Measuring Performance 1 1.2 MINIX 3 2 2 STATISTICAL PROFILING 3 2.1 Introduction 3 2.2 In Search of a Timer 3 2.2.1 i8259 Timers 3 2.2.2 CMOS Real-Time Clock 3 2.3 High-level Description 4 2.4 Work Done in User-Space 5 2.4.1 The SPROFILE System Call 5 2.5 Work Done in Kernel-Space 5 2.5.1 The SPROF Kernel Call 5 2.5.2 Profiling using the CMOS Timer Interrupt 6 2.6 Work Done at the Application Level 7 2.6.1 Control Tool: profile 7 2.6.2 Analyzing Tool: sprofalyze.pl 7 2.7 What Can and What Cannot be Profiled 8 2.8 Profiling Results 8 2.8.1 High Scoring IPC Functions 8 2.8.2 Interrupt Delay 9 2.8.3 Profiling Runs on Simulator and Other CPU Models 12 2.9 Side-effect of Using the CMOS Clock 12 3 CALL PROFILING 13 3.1 Introduction 13 3.1.1 Compiler-supported Call Profiling 13 3.1.2 Call Paths, Call and Cycle Attribution 13 3.2 High-level Description 14 3.3 Work Done in User-Space 15 3.3.1 The CPROFILE System Call 15 3.4 Work Done in Kernel-Space 16 3.4.1 The PROFBUF and CPROF Kernel Calls 16 3.5 Work Done in Libraries 17 3.5.1 Profiling Using Library Functions 17 3.5.2 The Procentry Library Function 17 3.5.3 The Procexit Library Function 20 3.5.4 The Call Path String 22 3.5.5 Testing Overhead Elimination 23 3.6 Profiling Kernel-Space/User-Space Processes 24 3.6.1 Differences in Announcing and Table Sizes 24 3.6.2 Kernel-Space Issue: Reentrancy 26 3.6.3 Kernel-Space Issue: The Call Path 26 3.7 Work Done at the Application
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Sealing OS Processes to Improve Dependability and Security
    Sealing OS Processes to Improve Dependability and Safety Galen Hunt, Mark Aiken, Manuel Fähndrich, Chris Hawblitzel, Orion Hodson, James Larus, Steven Levi, Bjarne Steensgaard, David Tarditi, and Ted Wobber Microsoft Research One Microsoft Way Redmond, WA 98052 USA [email protected] ABSTRACT General Terms In most modern operating systems, a process is a Design, Reliability, Experimentation. hardware-protected abstraction for isolating code and data. This protection, however, is selective. Many common Keywords mechanisms—dynamic code loading, run-time code Open process architecture, sealed process architecture, sealed generation, shared memory, and intrusive system APIs— kernel, software isolated process (SIP). make the barrier between processes very permeable. This paper argues that this traditional open process architecture 1. INTRODUCTION exacerbates the dependability and security weaknesses of Processes debuted, circa 1965, as a recognized operating modern systems. system abstraction in Multics [48]. Multics pioneered As a remedy, this paper proposes a sealed process many attributes of modern processes: OS-supported architecture, which prohibits dynamic code loading, self- dynamic code loading, run-time code generation, cross- modifying code, shared memory, and limits the scope of process shared memory, and an intrusive kernel API that the process API. This paper describes the implementation permitted one process to modify directly the state of of the sealed process architecture in the Singularity another process. operating system,
    [Show full text]
  • AD Management Tool Exhaustive Reports on User, Group, Computer, Exchange & GPO
    Stories Firehose All Popular Polls Video Jobs Deals Submit Search Login or Sig2n7 u7p Topics: Devices Build Entertainment Technology Open Source Science YRO Follow us: Follow Slashdot blog updates by subscribing to our blog RSS feed Nickname: Password: 6-20 characters long Public Terminal Log In Forgot your password? Sign in with Google Facebook Twitter LinkedIn Close AD Management Tool Exhaustive Reports on User, Group, Computer, Exchange & GPO GNU Hurd Begins Supporting Sound, Still Working On 64-bit & USB Support (phoronix.com) $0.32/Mbps IP Posted by timothy on Sunday January 31, 2016 @11:22AM from the pretty-soon-big-and-fancy-like-gnu dept. An anonymous reader writes: GNU developer Samuel Thibault presented at this weekend's FOSDEM conference Transit about the current state of GNU Hurd. He shared that over the past year they've started working on experimental IPv6+IPv4 and BGP For Your sound support as their big new feature. They also have x86 64-bit support to the point that the kernel can boot, but not Network in North America and much beyond that stage yet. USB and other functionality remains a work-in-progress. Those curious about this GNU kernel project can find more details via the presentation media. Europe gnu os software → Tiny Pluto Big On Frozen Water Reserves Kentucky Man Arrested After Shooting Down Drone Are We Reaching the Electric Car Tipping Point? Microsoft Is Downloading Windows 10 Without Asking Test Pilot: the F-35 Can't Dogfight Oregon Testing Pay-Per-Mile Driving Fee To Replace Gas Tax Submission: GNU Hurd Begins Supporting Sound, Still Working On 64-bit & USB Support FTDI Driver Breaks Hardware Again GNU Hurd Begins Supporting Sound, Still Working On 64-bit & USB Support 177 More | Reply Login GNU Hurd Begins Supporting Sound, Still Working On 64-bit & USB Support Post Load All Comments S1e5a Fruchll 8257 7A Cbobmremvieantetsd L0o Hg iIdnd/Cenreate an Account C/Soema ments Filter: AScllore: I5nsightful I4nformative I3nteresting F2unny 1The Fine Print: The following comments are owned by whoever posted them.
    [Show full text]
  • MINIX3: a Reliable and Secure Operating System
    MINIX3: A Reliable and Secure Operating System Andrew S. Tanenbaum and a team of students and programmers who actually did all the work Vrije Universiteit Amsterdam, The Netherlands 1 GOAL OF OUR WORK: BUILD A RELIABLE OS Tanenbaum’s definition of a reliable OS: “An operating system is said to be reliable when a typical user has never experienced even a single failure in his or her lifetime and does not know anybody who has ever experienced a failure.” In engineering terms, this is probably mean time to failure > 50 years I don’t think we are there yet 2 THE TELEVISION MODEL 1. You buy the television 2. You plug it in 3. It works perfectly for the next 10 years 3 THE COMPUTER MODEL (WINDOWS EDITION) 1. You buy the computer 2. You plug it in 3. You install service packs 1 through 9f 4. You install 18 new emergency security patches 5. You find and install 7 new device drivers 6. You install antivirus software 7. You install antispyware software 8. You install antihacker software (firewall) 9. You install antispam software 10. You reboot the computer 4 THE COMPUTER MODEL (2) 11. It doesn’t work 12. You call the helpdesk 13. You wait on hold for 30 minutes 14. They tell you to reinstall Windows 5 TYPICAL USER REACTION The New York Times recently reported that 25% of computer users have gotten so angry at their computer that they physically hit it. 6 IS RELIABILITY SO IMPORTANT? • Annoying • Lost work • But also think about – Industrial control systems in factories – Power grids – Hospital operating rooms – Banking and e-commerce servers – Emergency phone centers – Control software in cars, airplanes, etc.
    [Show full text]
  • Sealing OS Processes to Improve Dependability and Security
    MSR-TR-2006-51 This is a draft paper that is under submission. Please contact Galen Hunt for citation information. Sealing OS Processes to Improve Dependability and Security Galen Hunt, Mark Aiken, Paul Barham, Manuel Fähndrich, Chris Hawblitzel, Orion Hodson, James Larus, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill Microsoft Research Abstract On most modern operating systems, a process is a hardware-protected abstraction for executing potentially mutable code and data. Common features of processes include: dynamic code loading, dynamic code generation, access to cross-process shared memory, and a universal API. This paper argues that many of the dependability and security weaknesses of modern systems are exacerbated by this open process architecture. Moreover, this architecture impairs the ability of tools to analyze code statically, to improve its performance or dependability. By contrast, a sealed process architecture prohibits dynamic code loading, prohibits self-modifying code, prohibits shared memory, and replaces a universal API with a process-limited API. This paper describes an implementation of a sealed process architecture in the Singularity operating system, discusses its merits, and evaluates its impact. Among the benefits are: improved static program analysis, strong security guarantees, elimination of OS redundancies found in language runtimes such as the JVM and CLR, and better software engineering. 1. Introduction 1.1. Disadvantages of Open Processes The process, as a recognized operating system Although common, open processes are not “free.” abstraction, debuted in Multics [52] in the 1960s. This architecture has negative consequences for Multics processes included support for dynamic code dependability, correctness, security, and performance.
    [Show full text]
  • Microkernel Operating Systems
    STAYING AWAKE ON FRIDAY AFTERNOON Interactive Session on MINIX 3 ASCI GNARP workshop March 17, 2006 ± Rockanje Jorrit N. Herder Dept. of Computer Science Vrije Universiteit Amsterdam GNARP ©06 Jorrit N. Herder 1 QUIZ ● What operating systems do you use? ● Which one is more dependable? ● Why? ● Would you install my nifty kernel module? ● How about device drivers? ● What other threats do you see? ● How much performance would you be willing to sacrifice? GNARP ©06 Jorrit N. Herder 2 WHERE DID IT GO WRONG? ● Historically, design was guided by performance ● Fundamental design flaws in monolithic kernels – All code runs at highest privilege level (breaches POLA) – No proper fault isolation (any bug can be fatal) – Huge amount of code in kernel (1-20 bugs per 1000 LOC) – Untrusted, 3rd party code in kernel (70% driver bugs) – Complex and hard to maintain (causes bugs) ● Trade-off between performance and dependability ● New, modular design can solve above problems GNARP ©06 Jorrit N. Herder 3 DRAWING EXERCISE ● Volunteer requested to draw the intersection of a ship GNARP ©06 Jorrit N. Herder 4 DESIGN FOR DEPENDABILITY ● user user user MINIX 3 – Reliability – Availability server server server – Security driver driver driver KERNEL GNARP ©06 Jorrit N. Herder 5 CHARACTERISTICS OF MINIX 3 ● Minimal kernel to support user-mode operating system – Stable kernel (~4000 LoC) reduces number of fatal bugs ● User-mode modules are physically isolated by MMU – Memory access must be explicitly granted by other party ● Privileges of each components are strongly restricted – Kernel policies for IPC, kernel calls, I/O, memory, scheduling ● Servers and drivers are carefully monitored – Failures can be detected and often automatically repaired ● TCB is reduced by over two orders of magnitude – Minimal set of servers comprises about 20,000 LoC GNARP ©06 Jorrit N.
    [Show full text]
  • Singularity: Rethinking the Software Stack
    Singularity: Rethinking the Software Stack Galen C. Hunt and James R. Larus Microsoft Research Redmond [email protected] ABSTRACT modern operating systems have not evolved to accommodate the Every operating system embodies a collection of design decisions. enormous shift in how computers are used. Many of the decisions behind today’s most popular operating systems have remained unchanged, even as hardware and 1.1 A Journey, not a Destination software have evolved. Operating systems form the foundation of In the Singularity project, we have built a new operating system, a almost every software stack, so inadequacies in present systems new programming language, and new software verification tools. have a pervasive impact. This paper describes the efforts of the The Singularity operating system incorporates a new software Singularity project to re-examine these design choices in light of architecture based on software isolation of processes. Our advances in programming languages and verification tools. programming language, Sing# [8], is an extension of C# that Singularity systems incorporate three key architectural features: provides verifiable, first-class support for OS communication software-isolated processes for protection of programs and system primitives as well as strong support for systems programming and services, contract-based channels for communication, and code factoring. The sound verification tools detect programmer manifest-based programs for verification of system properties. We errors early in the development cycle. describe this foundation in detail and sketch the ongoing research From the beginning, Singularity has been driven by the following in experimental systems that build upon it. question: what would a software platform look like if it was designed from scratch, with the primary goal of improved Keywords dependability and trustworthiness? To this end, we have Operating systems, safe programming languages, program championed three strategies.
    [Show full text]
  • A Secure Computing Platform for Building Automation Using Microkernel-Based Operating Systems Xiaolong Wang University of South Florida, [email protected]
    University of South Florida Scholar Commons Graduate Theses and Dissertations Graduate School November 2018 A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems Xiaolong Wang University of South Florida, [email protected] Follow this and additional works at: https://scholarcommons.usf.edu/etd Part of the Computer Sciences Commons Scholar Commons Citation Wang, Xiaolong, "A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems" (2018). Graduate Theses and Dissertations. https://scholarcommons.usf.edu/etd/7589 This Dissertation is brought to you for free and open access by the Graduate School at Scholar Commons. It has been accepted for inclusion in Graduate Theses and Dissertations by an authorized administrator of Scholar Commons. For more information, please contact [email protected]. A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems by Xiaolong Wang A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science and Engineering Department of Computer Science and Engineering College of Engineering University of South Florida Major Professor: Xinming Ou, Ph.D. Jarred Ligatti, Ph.D. Srinivas Katkoori, Ph.D. Nasir Ghani, Ph.D. Siva Raj Rajagopalan, Ph.D. Date of Approval: October 26, 2018 Keywords: System Security, Embedded System, Internet of Things, Cyber-Physical Systems Copyright © 2018, Xiaolong Wang DEDICATION In loving memory of my father, to my beloved, Blanka, and my family. Thank you for your love and support. ACKNOWLEDGMENTS First and foremost, I would like to thank my advisor, Dr. Xinming Ou for his guidance, encouragement, and unreserved support throughout my PhD journey.
    [Show full text]
  • System Fundamentals
    System Fundamentals System and Network Administration Revision 2 (2020/21) Pierre-Philipp Braun <[email protected]> Table of contents ▶ What is a server? ▶ UNIX history ▶ Linux distributions ▶ Terminal tips & tricks ▶ Lab: install Slackware Linux Legal notice & guidelines ▶ Originally designed for 3rd year bachelors at Innopolis University ▶ Modified and enhanced since then ▶ Downgraded lab, much easier now ▶ Open and public knowledge – resources in the appendix ▶ This course is practice and industry oriented What’s a server? What’s the difference between a server and a desktop computer? in terms of packaging?… Rackmount - DL380 gen 10 DL380 gen 10 (w/o cover) ==> Enterprise-class ▶ Fault-tolerant storage disks ▶ Fault-tolerant Power Supply Units (PSU) ▶ Out-of-band management (Lights-out) Fault-tolerant storage disks RAID controller there is… RAID-1 DL380 gen 10 top view Fault-tolerant Power Supply Units (PSU) DL380 gen 10 rear slots DL380 gen 10 rear filled Racks More racks Datacenter cooling A self-made PC is fine too, as long as it is dedicated! ▶ low-cost PC with some AMD Ryzen inside same goes for a 500 RUB SoC ▶ TI BBB ▶ RPi4 ▶ Nvidia Jetson Nano Developer Kit ▶ … By the way, who’s selling more desktop computer CPUs, Intel or AMD?… ==> AMD took over end 2020 // hardwaretimes.com Still loosing the laptop market // hardwaretimes.com Lights-Out Management (LOM) ▶ THIS IS NOT ABOUT SSH ▶ Dedicated daughter board –or– ▶ Hardware integrated in the mobo Low-level console Reach it through ▶ Serial console ▶ Java ▶ HTML5 Remote management engines HP ▶ Management Processor (MP) on HP9000 systems ▶ HPE Integrated Lights-Out 2 (iLO2) IBM ▶ Baseboard Management Controller (BMC) ▶ e.g.
    [Show full text]
  • Computer Labs the Minix 3 Operating System 2O MIEIC
    Computer Labs The Minix 3 Operating System 2o MIEIC Pedro F. Souto ([email protected]) September 17, 2015 LCOM Labs I One of the goals of LCOM is that you learn to use the HW-level interface of the most common PC I/O devices CPU-memory bus CPU Bus adapter Main memory I/O bus I/O I/O I/O I/O I/O contr. contr. contr. contr. contr. Keyboard Mouse Monitor Disk Network Application and System Programs Operating System I In most modern computer systems, access to the HW is mediated by the operating system (OS) Application and System Programs Operating System Hardware I I.e. user programs are not able to access directly the HW Parenthesis: Program vs. Process Program Piece of code, i.e. a set of instructions, that can be executed by a processor Process OS abstraction of a program in execution int main(int argc, char *argv[], char* envp[])} args args Arguments passed in the command line stack and environment variables stack Activation records for invoked functions heap Memory region allocated dynamically heap with malloc. data Memory region allocated statically by data the compiller (e.g., a string “Hello, text World!”) 0x0 text Program instructions Application and System Programs Operating System (corrected) I In most modern computer systems, access to the HW is mediated by the operating system (OS) Application and System Programs Operating System Hardware I I.e. user processes are not able to access directly the HW Application and System Programs Access to the HW-level Interface Application and System Programs Operating System Instruction Set Architecture (ISA) Level Lower HW Layers I Most of the HW interface, actually the processor instruction set, is still available to user processes I A few instructions however are not directly accessible to user processes I Thus preventing user processes from interfering with: Other user processes most OSs are multi-process The OS which manages the HW resources I Instead, the operating system offers its own “instructions”, which are known as system calls.
    [Show full text]