Fs-Utils: File Systems Access Tools for Userland

Total Page:16

File Type:pdf, Size:1020Kb

Fs-Utils: File Systems Access Tools for Userland Fs-utils: File Systems Access Tools for Userland Arnaud Ysmal ([email protected]) and Antti Kantee ([email protected].fi) September 2009 Abstract consider the connection to the server to be the file sys- tem image. Currently, file system access is done either through File systems can be accessed by kernel drivers (what a kernel driver or a specialized userspace program. we do when using mount) or by userland tools. In this In the former case the file system is mounted with paper, we focus on the latter, or more precisely on user- the mount utility and then accessed with standard land tools using the file system code from the NetBSD userspace tools such as cat. An example of the latter kernel. This principle is implemented on NetBSD and case is the mtools utility suite which allows to access known as RUMP (Runnable Userspace Meta Program) msdos file systems. [1]. We can also use NetBSD kernel code in userspace The NetBSD Runnable Userspace Meta Program on non-NetBSD operating systems, as we show later (RUMP) framework enables the use of kernel file sys- in this paper. tem drivers as part of userspace programs. By building The rest of this paper is organized as follows. The upon RUMP and NetBSD base system utilities such as remainder of this Section will present fs-utils and ex- ls and cp, we have created the fs-utils application suite. plain what we wanted to achieve by creating this new It provides mtools-like file system access without re- set of tools. Section 2 focuses on the way it was de- quiring mount privileges or an in-kernel driver. In con- veloped, discover possible use cases and point out its trast to mtools, fs-utils reuses the kernel file system benefits. Section 3 analyses our approach and Section drivers instead of relying on a userspace reimplemen- 4 presents some common use cases. Section 5 presents tation, supports a total of 12 file systems from NetBSD some recent developments and finally Section 6 con- plus FUSE file systems, and offers the same usage as cludes. the well-known tools (e.g. all of the flags of ls are sup- ported). In addition to running on NetBSD, there has been initial success in running fs-utils on Linux. 1.1 What is fs-utils? This paper explains how these programs were writ- ten and recounts the evolution of the project. It also fs-utils is a set of utilities (including commands like cat, chflags, chmod, cp, du, find, ln, ls, mkdir, mkfifo, shows the benefits and use-cases of fs-utils. mv, rm, rmdir, touch) that give access to a file system image. It was developed on top of RUMP and UKFS libraries. With this, it is possible to use commands 1 Introduction like: $ fsu_ls ffs.img /etc/defaults A file system is a mechanism that allows a user to or- daily.conf pf.boot.conf security.conf ganize his or hers data with files and directories. It monthly.conf rc.conf weekly.conf $ fsu_cat ffs.img /etc/defaults/weekly.conf enables to read a file “foo” in the directory “bar” in- $ echo "foo" | fsu_write ffs.img bar stead of having to remember the block and sector of $ fsu_cat ffs.img bar foo the data. A file system image contains the file system’s in- ternal representation of the file system’s state. A file 1.2 Why fs-utils? system image can either be a regular file or it can be contained on a mass media partition. Additionally, in The aim of this project is to provide a set of tools to the case of NFS or another networked file system, we manipulate file systems, like mtools[2], e2fsprogs[3]. Mtools opens the possibility of accessing and/or and the mountpoint is accessible only within the pro- modifying FAT file systems by offering a set of com- cess which is did the mounting. mands. For instance, it is possible to use the command The following is an example of a program using mdir to list a directory or mren to rename a file. UKFS. It mounts an ffs image, creates a directory fs-utils wants to achieve the same main goal. How- called “dir” and reads 11 bytes from a file. The file ever, unlike mtools, the purpose of fs-utils is to pro- system is then unmounted. vide a generic set of commands which could be used on many different file systems instead of focusing on a fs = ukfs_mount("ffs", "/ffs.img", "/", 0, &args, sizeof(args)); particular one. ukfs_mkdir(fs, "/dir", 0777); ukfs_read(fs, "/a/file", 0, buf, 11); That is why fs-utils has been designed to handle ev- ukfs_release(fs, 0); ery file system supported by RUMP. With this set of tools, anyone can manipulate a file system image he has access to without having to mount 2 Development it. Mounting is, by default, an operation only allowed to root user. However with this type of access, there is 2.1 Origin of fs-utils no need to be root. Possible operations depend on the file system image fs-utils started as a NetBSD project for the Google permissions. The user will be able to read file contents Summer of Code 2008[6]. It was written as a proof and browse directories with read access and modify that file systems servers can work in userland. the files contained in the image if he or she has write permissions to the image. Permissions of files inside the image do not have any effect as the user running 2.2 Development a utility from fs-utils is considered root for operations The first step was to start writing some tools to get in on the file system image. touch with the UKFS library and see what should be added in it to ease its usage. 1.3 RUMP and UKFS Few functions were added, mostly about files status like changing the owner, setting permissions and get- fs-utils was developed on top of the UKFS library ting information. These commands were needed due (User-Kernel File System Library) [4] and RUMP to their use in a large number of commands that were (Runnable Userspace Meta Programs) [5]. planned. The attempt was to write commands completely Regular Standalone Userspace File System File System Using ukfs from scratch. This created problems in terms of main- kernel (runtime) tainability since a new set of commands had to be kernel fs maintained, although it was quite similar to the stan- vfs dards commands. kernel syscall entry While writing these commands, some functions ap- peared to be generic enough to be shared in libraries. user In these functions, we can find file handling and di- application application rectory opening and reading and virtually mounting libukfs and unmounting. It was clear that we needed at least kernel fs two libraries, the first one, called fsu mount, takes care librump of the mounting and unmounting and the second one, called fsu utils, replaces functions from the libc that UKFS is a library which uses RUMP. The UKFS access file systems. interface is based on pathnames and each call is self- After writing both libraries, and doing some exper- contained for ease of use. This means that it is not imentation, the decision to base future versions on ex- necessary to e.g. open a file before reading it. The file isting utility code was made. This means that fs-utils system image is mounted internally within the process mkdir would use the same code as the base system using UKFS. The kernel mount system call is not used, mkdir, and so forth. 2.2.1 fsu mount 2.2.3 Commands fsu mount takes care of everything needed to mount The remaining work was to modify classic programs a file system. It is able to test all supported file sys- to use these libraries. These modifications consist in: tems until it finds one that match the file system used for the current device. The algorithm used to do this • Adding a ukfs declaration is quite simple. It tries to mount the image with each (DECLARE_UKFS(ukfs)) supported file system, one by one, until it find a file and call to the virtual mount system which is able to parse the command line argu- (FSU_MOUNT(argc, argv, ukfs)), ments and mount returns successfully. With this, the provided by the fsu mount library. user does not have to give the file system type of the • Replacing the calls to libc functions to their coun- image. terparts in the fsu utils library or in ukfs: Code needed to mount a file system image with this library: #define stat(path, sb) ukfs_stat(ukfs, path, sb) #include <fsu_mount.h> #define lstat(path, sb) ukfs_lstat(ukfs, path, sb) DECLARE_UKFS(ukfs) • Updating the usage to contain the file system im- int main(int argc, char *argv[]) age path argument { ... FSU_MOUNT(argc, argv, ukfs); These changes were added to the code using ifdef so ... } as to be able to compile the programs with file sys- tem access through RUMP or through libc and system DECLARE_UKFS(ukfs) means that the program calls. will use a struct ukfs which is called ukfs. Then So far, updates of these programs are done manually. FSU_MOUNT(argc, argv, ukfs); will use the standard command line arguments to process the 2.2.4 Installing mount. For example, the arguments “-o ro /dev/wd1a” might be given. This would result in a read-only mount As of now, there are two ways of installing these pro- of /dev/wd1a with the mount handle stored in “ukfs”.
Recommended publications
  • Porting FUSE to L4re
    Großer Beleg Porting FUSE to L4Re Florian Pester 23. Mai 2013 Technische Universit¨at Dresden Fakult¨at Informatik Institut fur¨ Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann H¨artig Betreuender Mitarbeiter: Dipl.-Inf. Carsten Weinhold Erkl¨arung Hiermit erkl¨are ich, dass ich diese Arbeit selbstst¨andig erstellt und keine anderen als die angegebenen Hilfsmittel benutzt habe. Declaration I hereby declare that this thesis is a work of my own, and that only cited sources have been used. Dresden, den 23. Mai 2013 Florian Pester Contents 1. Introduction 1 2. State of the Art 3 2.1. FUSE on Linux . .3 2.1.1. FUSE Internal Communication . .4 2.2. The L4Re Virtual File System . .5 2.3. Libfs . .5 2.4. Communication and Access Control in L4Re . .6 2.5. Related Work . .6 2.5.1. FUSE . .7 2.5.2. Pass-to-Userspace Framework Filesystem . .7 3. Design 9 3.1. FUSE Server parts . 11 4. Implementation 13 4.1. Example Request handling . 13 4.2. FUSE Server . 14 4.2.1. LibfsServer . 14 4.2.2. Translator . 14 4.2.3. Requests . 15 4.2.4. RequestProvider . 15 4.2.5. Node Caching . 15 4.3. Changes to the FUSE library . 16 4.4. Libfs . 16 4.5. Block Device Server . 17 4.6. File systems . 17 5. Evaluation 19 6. Conclusion and Further Work 25 A. FUSE operations 27 B. FUSE library changes 35 C. Glossary 37 V List of Figures 2.1. The architecture of FUSE on Linux . .3 2.2. The architecture of libfs .
    [Show full text]
  • Index Images Download 2006 News Crack Serial Warez Full 12 Contact
    index images download 2006 news crack serial warez full 12 contact about search spacer privacy 11 logo blog new 10 cgi-bin faq rss home img default 2005 products sitemap archives 1 09 links 01 08 06 2 07 login articles support 05 keygen article 04 03 help events archive 02 register en forum software downloads 3 security 13 category 4 content 14 main 15 press media templates services icons resources info profile 16 2004 18 docs contactus files features html 20 21 5 22 page 6 misc 19 partners 24 terms 2007 23 17 i 27 top 26 9 legal 30 banners xml 29 28 7 tools projects 25 0 user feed themes linux forums jobs business 8 video email books banner reviews view graphics research feedback pdf print ads modules 2003 company blank pub games copyright common site comments people aboutus product sports logos buttons english story image uploads 31 subscribe blogs atom gallery newsletter stats careers music pages publications technology calendar stories photos papers community data history arrow submit www s web library wiki header education go internet b in advertise spam a nav mail users Images members topics disclaimer store clear feeds c awards 2002 Default general pics dir signup solutions map News public doc de weblog index2 shop contacts fr homepage travel button pixel list viewtopic documents overview tips adclick contact_us movies wp-content catalog us p staff hardware wireless global screenshots apps online version directory mobile other advertising tech welcome admin t policy faqs link 2001 training releases space member static join health
    [Show full text]
  • Refuse: Userspace FUSE Reimplementation Using Puffs
    ReFUSE: Userspace FUSE Reimplementation Using puffs Antti Kantee Alistair Crooks Helsinki University of Technology The NetBSD Foundation [email protected].fi [email protected] Abstract for using Gmail as a file system storage backend and FUSEPod [5] which facilitaties iPod access and man- In an increasingly diverse and splintered world, agement. interoperability rules. The ability to leverage code Userspace file systems operate by attaching an in- written for another platform means more time and re- kernel file system to the kernel’s virtual file system sources for doing new and exciting research instead layer, vfs [17]. This component transforms incoming of reinventing the wheel. Interoperability requires requests into a form suitable for delivery to userspace, standards, and as the saying goes, the best part of sends the request to userspace, waits for a response, standards is that everyone can have their own. How- interprets the result and feeds it back to caller in the ever, in the userspace file system world, the Linux- kernel. The kernel file system calling conventions originated FUSE is the clear yardstick. dictate how to interface with the virtual file system In this paper we present ReFUSE, a userspace layer, but other than that the userspace file systems implementation of the FUSE interface on top of the framework is free to decide how to operate and what NetBSD native puffs (Pass-to-Userspace Framework kind of interface to provide to userspace. File System) userspace file systems framework. We While extending the operating system to userspace argue that an additional layer of indirection is the is not a new idea [12, 21], the FUSE [2] userspace right solution here, as it allows for a more natural file systems interface is the first to become a veri- export of the kernel file system interface instead of table standard.
    [Show full text]
  • Recycling RAM Content After Reboots
    Wiederverwendung des RAM Inhalts nach Neustarts BACHELORARBEIT zur Erlangung des akademischen Grades Bachelor of Science im Rahmen des Studiums Software & Information Engineering eingereicht von Manuel Wiesinger Matrikelnummer 0825632 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Ao.Univ.Prof. Anton Ertl Wien, 27. Juni 2016 Manuel Wiesinger Anton Ertl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Recycling RAM content after reboots BACHELOR’S THESIS submitted in partial fulfillment of the requirements for the degree of Bachelor of Science in Software & Information Engineering by Manuel Wiesinger Registration Number 0825632 to the Faculty of Informatics at the Vienna University of Technology Advisor: Ao.Univ.Prof. Anton Ertl Vienna, 27th June, 2016 Manuel Wiesinger Anton Ertl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Manuel Wiesinger Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Wien, 27. Juni 2016 Manuel Wiesinger v Acknowledgements First of all, I would like to thank my supervisor Anton Ertl, for his time and ideas, and especially for patiently waiting for me to start writing. My gratitude extends to the people who contributed to the NetBSD project, and to all other free software projects essential for this thesis.
    [Show full text]
  • CYBERSECURITY When Will You Be Hacked?
    SUFFOLK ACADEMY OF LAW The Educational Arm of the Suffolk County Bar Association 560 Wheeler Road, Hauppauge, NY 11788 (631) 234-5588 CYBERSECURITY When Will You Be Hacked? FACULTY Victor John Yannacone, Jr., Esq. April 26, 2017 Suffolk County Bar Center, NY Cybersecurity Part I 12 May 2017 COURSE MATERIALS 1. A cybersecurity primer 3 – 1.1. Cybersecurity practices for law firms 5 – 1.2. Cybersecurity and the future of law firms 11 – 2. Information Security 14 – 2.1. An information security policy 33 – 2.2. Data Privacy & Cloud Computing 39 – 2.3. Encryption 47 – 3. Computer security 51 – 3.1. NIST Cybersecurity Framework 77 – 4. Cybersecurity chain of trust; third party vendors 113 – 5. Ransomware 117 – 5.1. Exploit kits 132 – 6. Botnets 137 – 7. BIOS 139 – 7.1. Universal Extensible Firmware Interface (UEFI) 154– 8. Operating Systems 172 – 8.1. Microsoft Windows 197 – 8.2. macOS 236– 8.3. Open source operating system comparison 263 – 9. Firmware 273 – 10. Endpoint Security Buyers Guide 278 – 11. Glossaries & Acronym Dictionaries 11.1. Common Computer Abbreviations 282 – 11.2. BABEL 285 – 11.3. Information Technology Acronymns 291 – 11.4. Glossary of Operating System Terms 372 – 2 Cyber Security Primer Network outages, hacking, computer viruses, and similar incidents affect our lives in ways that range from inconvenient to life-threatening. As the number of mobile users, digital applications, and data networks increase, so do the opportunities for exploitation. Cyber security, also referred to as information technology security, focuses on protecting computers, networks, programs, and data from unintended or unauthorized access, change, or destruction.
    [Show full text]
  • Puffs - Pass-To-Userspace Framework File System Asiabsdcon 2007 Tokyo, Japan
    puffs - Pass-to-Userspace Framework File System AsiaBSDCon 2007 Tokyo, Japan Antti Kantee [email protected] Helsinki University of Technology Antti Kantee<[email protected].fi> : 1 Talk structure • what is puffs? • why do we care? • puffs architecture overview • kernel and transport mechanism • userspace components • example file systems • measured performance figures • compatibility • future work • conclusions Antti Kantee<[email protected].fi> : 2 Introduction to puffs Pass-to-Userspace Framework File System • passes file system interface to userspace and provides a framework • kernel interface: VFS • userspace interface: almost VFS • userspace library provides convenience functions such as continuation support • NetBSD-current (4.0 will have some support) Why the name puffs? • puff pastry, increases in volume when baked Antti Kantee<[email protected].fi> : 3 Why userspace file systems • fault tolerance and isolation: one error doesn’t bring the system down • easier to program • easier to test • easier to debug, single-step and do iteration • do we really need all the error-prone namespace management for example for procfs in the kernel? • libraries and pre-existing software: most of the time written against POSIX instead of the BSD kernel Antti Kantee<[email protected].fi> : 4 puffs architecture 1. vfs module mar- file server (4) shalls request libpuffs (3) 2. requests are trans- user /dev/puffs (2) vfs module (1) ported to userspace kernel kernel 3. library decodes and dispatches request user syscall application 4. file server handles request • result passed back Antti Kantee<[email protected].fi> : 5 VFS module • attach puffs to kernel like all file systems • interpret incoming requests, convert to transport-suitable format and queue request to file server • police duty making sure file server plays nice • vnode -> file server node -> vnode handled with cookies, file server selects cookie value when it creates a node • short-circuit unimplemented operations • integrate to UBC • snapshot support Antti Kantee<[email protected].fi> : 6 Messaging format • nothing to write a slide about ...
    [Show full text]
  • Flexible Operating System Internals: the Design and Implementation of the Anykernel and Rump Kernels Aalto University
    Department of Computer Science and Engineering Aalto- Antti Kantee DD Flexible Operating System 171 / 2012 2012 Internals: FlexibleSystemOperating Internals: TheDesign andImplementation theofandAnykernelRump Kernels The Design and Implementation of the Anykernel and Rump Kernels Antti Kantee 9HSTFMG*aejbgi+ ISBN 978-952-60-4916-8 BUSINESS + ISBN 978-952-60-4917-5 (pdf) ECONOMY ISSN-L 1799-4934 ISSN 1799-4934 ART + ISSN 1799-4942 (pdf) DESIGN + ARCHITECTURE UniversityAalto Aalto University School of Science SCIENCE + Department of Computer Science and Engineering TECHNOLOGY www.aalto.fi CROSSOVER DOCTORAL DOCTORAL DISSERTATIONS DISSERTATIONS "BMUP6OJWFSTJUZQVCMJDBUJPOTFSJFT %0$503"-%*44&35"5*0/4 &2#&ŗ*,.#(!ŗ3-.'ŗ (.,(&-Ćŗ "ŗ-#!(ŗ(ŗ '*&'(..#)(ŗ) ŗ."ŗ (3%,(&ŗ(ŗ/'*ŗ ,(&-ŗ "OUUJ,BOUFF "EPDUPSBMEJTTFSUBUJPODPNQMFUFEGPSUIFEFHSFFPG%PDUPSPG 4DJFODFJO5FDIOPMPHZUPCFEFGFOEFE XJUIUIFQFSNJTTJPOPGUIF "BMUP6OJWFSTJUZ4DIPPMPG4DJFODF BUBQVCMJDFYBNJOBUJPOIFMEBU UIFMFDUVSFIBMM5PGUIFTDIPPMPO%FDFNCFSBUOPPO "BMUP6OJWFSTJUZ 4DIPPMPG4DJFODF %FQBSUNFOUPG$PNQVUFS4DJFODFBOE&OHJOFFSJOH 4VQFSWJTJOHQSPGFTTPS 1SPGFTTPS)FJLLJ4BJLLPOFO 1SFMJNJOBSZFYBNJOFST %S.BSTIBMM,JSL.D,VTJDL 64" 1SPGFTTPS3FO[P%BWPMJ 6OJWFSTJUZPG#PMPHOB *UBMZ 0QQPOFOU %S1FUFS5SÍHFS )BTTP1MBUUOFS*OTUJUVUF (FSNBOZ "BMUP6OJWFSTJUZQVCMJDBUJPOTFSJFT %0$503"-%*44&35"5*0/4 "OUUJ,BOUFFQPPLB!JLJGJ 1FSNJTTJPOUPVTF DPQZ BOEPSEJTUSJCVUFUIJTEPDVNFOUXJUIPS XJUIPVUGFFJTIFSFCZHSBOUFE QSPWJEFEUIBUUIFBCPWFDPQZSJHIU OPUJDFBOEUIJTQFSNJTTJPOOPUJDFBQQFBSJOBMMDPQJFT%JTUSJCVUJOH NPEJGJFEDPQJFTJTQSPIJCJUFE *4#/ QSJOUFE *4#/
    [Show full text]
  • Kernel Development in Userspace - the Rump Approach
    Kernel Development in Userspace - The Rump Approach Antti Kantee Helsinki University of Technology [email protected].fi Abstract Where the dependencies for desired source code involve kernel code which requires the privileged CPU mode, a In this paper we explore the use of the NetBSD Runnable reimplementation suitable for userspace is provided. Userspace Meta Program (rump) framework for kernel The term ”rump” is also used to describe a userlevel development. Rump enables running kernel components program which uses the rump framework to run kernel in userspace without code modification. Examples in- code in userspace. Additionally, we use the term ”rump clude file systems, the networking stack, and the kernel kernel” to describe the kernel source code and the depen- entry points for a large number of system calls. This dencies reimplemented for userspace. makes it possible to develop, debug and test kernel code Doing kernel development in userspace has numerous as a normal userspace application with all the associated advantages. The main benefit is the light speed testing benefits over work done directly in the kernel. cycle: bootstrapping the rump kernel takes just microsec- This paper describes how, why and when to use rump onds, so testing changes is typically extremely fast. Ad- for kernel development. It does not delve into the secrets ditionally, a kernel panic always means an application of the implementation of the framework or evaluate the core dump on the file system, so examining the state after framework in any other sense apart from its usefulness a crash is straightforward. Unmodified userspace tools in kernel development.
    [Show full text]
  • Rump File Systems: Kernel Code Reborn
    Rump File Systems: Kernel Code Reborn Antti Kantee Helsinki University of Technology [email protected].fi Abstract ming and a more casual development style for userspace. The question stems from the different programming en- When kernel functionality is desired in userspace, the vironments offered by the two choices. Even if code common approach is to reimplement it for userspace in- written for the kernel is designed to be run in userspace terfaces. We show that use of existing kernel file sys- for testing, it is most likely implemented with #ifdef, tems in userspace programs is possible without modify- crippled and does not support all features of kernel mode. ing the kernel file system code base. Two different op- Typical operating system kernels offer multitudes of erating modes are explored: 1) a transparent mode, in tested and working code with reuse potential. A good which the file system is mounted in the typical fashion illustration is file system code, which in the case of most by using the kernel code as a userspace server, and 2) a operating systems also comes with a virtual file system standalone mode, in which applications can use a kernel abstraction [18] making access file system independent. file system as a library. The first mode provides isola- By making kernel file systems function in userspace, tion from the trusted computing base and a secure way existing code can be utilized for free in applications. We for mounting untrusted file systems on a monolithic ker- accomplished this by creating a shim layer to emulate nel. The second mode is useful for file system utilities enough of the kernel to make it possible to link and run and applications, such as populating an image or view- the kernel file system code.
    [Show full text]
  • Freebsd Documentation Release 10.1
    FreeBSD Documentation Release 10.1 Claudia Mane July 12, 2015 Contents 1 &title; 3 1.1 What is FreeBSD?............................................3 1.2 Cutting edge features...........................................3 1.3 Powerful Internet solutions........................................3 1.4 Advanced Embedded Platform......................................3 1.5 Run a huge number of applications...................................3 1.6 Easy to install..............................................4 1.7 FreeBSD is free .............................................4 1.8 Contributing to FreeBSD.........................................4 2 &title; 5 2.1 Introduction...............................................5 3 &title; 15 3.1 Experience the possibilities with FreeBSD............................... 15 3.2 FreeBSD is a true open system with full source code........................... 15 3.3 FreeBSD runs thousands of applications................................. 15 3.4 FreeBSD is an operating system that will grow with your needs..................... 16 3.5 What experts have to say . ........................................ 16 4 &title; 17 4.1 BSD Daemon............................................... 17 4.2 “Powered by FreeBSD” Logos...................................... 19 4.3 Old Advertisement Banners....................................... 19 4.4 Graphics Use............................................... 19 4.5 Trademarks................................................ 20 5 &title; 21 6 &title; 23 6.1 Subversion...............................................
    [Show full text]
  • From Roof to Basement - Netbsd Introduction & Status Report
    From roof to basement - NetBSD Introduction & Status Report - Hubert Feyrer <[email protected]> Contents ● What does NetBSD look like? ● So what is NetBSD? ● Introducing NetBSD: Some Applications & Products ● NetBSD 4 and beyond What does NetBSD look like? NetBSD looks like ... KDE NetBSD looks like ... GNOME NetBSD looks like ... XFCE NetBSD looks like ... Xen So what is NetBSD? NetBSD is ... ● A descendant of 4.4BSD Unix ● A “general purpose” Unix/Linux-like Open Source Operating System ● Not Linux – NetBSD has its own kernel and userland ● A small core system that can be adjusted for many purposes via pkgsrc: Desktop, Web and Database servers, Firewalls, ... ● Secure and Performant, of course! ● Focussed on multiplatform portability Features: Thousands of packages via pkgsrc Many areas of application One Operating System, 1 Source Modern & Vintage Hardware More than fifty Hardware Platforms Introducing NetBSD: Some Applications & Products NetBSD from roof to basement: On Air International Space Station, on-plane systems Roof WaveLAN routers, surveillance cameras, embedded boards Office Highspeed networking, desktop, Embedded development Entertainment Various game consoles and robots Basement Storage solutions, servers “Commodity” Networking: ● Various WLAN-Routers and Access-Points by Allied Telesis, IIJ/Root and Apple: ● Seclarity's SiNic Router-on-a-card ● Avocent KVM Switches ● Surveillance- and Webcams by SGI, Panasonic and Brains Inc. Embedded Boards: PowerPC, MIPS ● MIPS – NetBSD/evbmips ● Malta 4/5kc, Access Cube, AMD Alchemy, Atheros, Meraki Mini ● PowerPC – NetBSD/evbppc ● Virtex-4 ML403 FPGA, Motorola Walnut, Marvell, Plat'Home OpenBlockS Embedded boards: SH3/4, ARM ● Super-Hitachi - NetBSD/sh3 ● CqREEK, Computes 7709, KZ-SH4-01: ● ARM, StrongARM, Xscale – NetBSD/evbarm ● Mesa 4C81, Gumstix + peripherals, Technologic Systems' TS-7200, ..
    [Show full text]
  • Building Products with Netbsd - Thin-Clients ● Stephen Borrill - Precedence Technologies ● [email protected][email protected]
    Building products with NetBSD - thin-clients ● Stephen Borrill - Precedence Technologies ● [email protected][email protected] Stephen Borrill: Building products with NetBSD – thin-clients: [email protected] 1 Contents 1 ● Who am I? ● What is a thin-client? – Client software ● NetBSD: first encounter ● Relevant experience and jobs ● Product history – The End?, A New Hope, Baggage, Brainwave Stephen Borrill: Building products with NetBSD – thin-clients: [email protected] 2 Contents 2 ● Product requirements ● How NetBSD meets requirements ● Problems hit against ● Problems not easily solved ● Future developments ● Changes since September 2007 Stephen Borrill: Building products with NetBSD – thin-clients: [email protected] 3 Who am I? ● Live and work in Cambridge, UK ● Managing Director of Precedence Technologies ● PhD in psychoacoustics (not Computer Science!) ● Citrix Certified Administrator (XenApp/XenServer) ● Citrix Certified Sales Professional ● NetBSD user since 1994 ● NetBSD and pkgsrc developer/committer since Jan 2007 Stephen Borrill: Building products with NetBSD – thin-clients: [email protected] 4 What is a thin-client? ● Small physical size ● No moving parts ● Low/medium performance ● Low power consumption ● Fast start time Stephen Borrill: Building products with NetBSD – thin-clients: [email protected] 5 What is a thin-client? ● No local storage (firmware only) – Small amount for local settings perhaps ● Centrally managed from network – Clients are commodity items that can
    [Show full text]