From owner-freebsd-current@FreeBSD.ORG Tue Feb 18 07:29:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCF3779E; Tue, 18 Feb 2014 07:29:22 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29E7015F5; Tue, 18 Feb 2014 07:29:21 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id s1I7SLFO087426; Tue, 18 Feb 2014 07:28:21 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id s1I7SLBK087425; Tue, 18 Feb 2014 07:28:21 GMT (envelope-from wkoszek) Date: Tue, 18 Feb 2014 07:28:21 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: BSD XXI Manifesto Message-ID: <20140218072821.GF34282@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-0.4 required=5.0 tests=RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on freebsd.czest.pl X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Tue, 18 Feb 2014 07:28:25 +0000 (UTC) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 07:29:23 -0000 (cross-posted message: eventual discussion let's keep on hackers@) Hello, After being disappointed with the list of submitted FreeBSD ideas, I created my own Machiavellist vision of XXI-century FreeBSD. I paste it below. If you want to add something, it's here: https://wiki.freebsd.org/BSD_XXI_Manifesto GSOC students could use this as an inspiration for their projects. The idea is to invite non-C, non-OS, non-kernel developers to help out with FreeBSD stuff. ============ BSDXXI manifesto For people seeking for inspiration here are some ideas of how FreeBSD of 21st century could operate... - FreeBSD boots from simple USB-stick image or SD card. Image would contain nothing more than HTTP-enabled installer, so that as OS updates are rolled out, the installer doesn't change. It means I can keep the same USB-stick for years, since all packages/installation procedure would actually be fetched from the Internet. - installer is in high-resolution mode with graphical environment started, and my bluetooth/remote-USB mouse/keyboard working OK. Additionally I have an access to the filesystem on USB-stick. I have Wi-Fi access and/or Ethernet access and a browser to do the installation. This all is in case I want to bother to use a keyboard. - installer starts HTTP server in the background. It serves responsive 'FreeBSD installer' website. You can enter this website with your smartphone and perform the whole installation procedure from your mobile device. This HTTP server is getting left of "service partition", so that in case of problems, you can always boot FreeBSD in emergency mode and recover from problems. - installer asks me whether I'd like to use my FreeBSD account or to setup one. FreeBSD is similar to Apple ID or Amazon ID and remembers my preferences, so that in case of installation/backup/recovery I don't have to be asked same questions 10 times. This data is stored in an encrypted form on my disk, and gets imported by all programs that may ever want to ask me about my name/surname etc. This account is used to submit data about hardware which I use too, so that developers see which hardware is popular among users. This account is used for encrypted crashdump reports, bug reporting and others. This is the key to the contact with the FreeBSD developers community. Also as a part of the account users get easy access to 'BSDDEV' environment, which lets them clone, change and contribute back changes by themselves, without asking any commiters/developers for anything. They may later request this change to be pushed back to the FreeBSD. - installer asks me whether I'd like to pick certain profile of installation and install everything in 1 step. This is similar to "1 click buy" on Amazon, and is similar to node.js "npm" manager -- dozens of users contribute their installation profiles to the FreeBSD portal, and FreeBSD accounts have access to these profiles. Everybody sees which installation profile has most "Likes", and based on that users can choose whether to struggle with 100 parameters for the installation, or pick something that expert picked for them. Also desktop users willing to use Flash can pick "freebsd_superflash" installation profile, which will give them Flash working out of the box etc... - Among installation profiles, installer presents me: * mobile installation (cell phone) FreeBSD of XXI century runs on most of mobile devices, and this is one of the types of installation which I can pick for my tablet/smartphone. FreeBSD found great adoption in mobile environments, since BSD license attracted more people than GPLv4 code. FreeBSD has drivers for all sensors, GPSes and GSM/UMTS modules from phones. * laptop This profile installs me all possible optimizations for maximal power and maximal battery life, and minimal noise for any leftover laptops that still have a fan. * desktop This profile installs me everything for a desktop user. * VM (cloud solution: EC2, Rackspace etc) This installation may pick optimized I/O schedulers, so that environments which charge for I/O access, network access etc.. end up being cheap thanks to smart algorithms in FreeBSD. * hosted cloud This is a profile for enterprise users. Hosted installation is something which lets you designate a master, and slaves which connect to the master. Once slaves are connected, from 1 installer you can choose what all nodes will get installed and how they'll work. So e.g.: if you want to have a storage-cloud with 4 servers, you can make them be a redundant storage with 2 servers each, for improved efficiency. If servers are plugged in the same switch, I'd like to see them all in the menu and be able to toggle the ones which I want to be added to the cluster. - FreeBSD is getting setup in less than 5 minutes. All stages are marked with barcodes/URLs, so that in case of problems, user can take a photo of a screen and get immediate helps from FreeBSD community portal. - FreeBSD on 1st boot establishes connection via your FreeBSD ID and submits stuff necessary for improved FreeBSD development. You may choose not to submit stuff, but you'll not get an access to interactive bug database, easy contribution capability etc.. - FreeBSD ID offers to sync my disk with the BSDCloud, and offers me options for storage providers and their prices. - FreeBSD once installed, just works. It includes only the most necessary ports installed as a part of chosen profile. If necessary, users can share their configurations, e.g.: if there's somebody who got Jail/MAC/Capability-enabled environment for Node.Js installed in /jail/nodejs/, I don't really want to keep retyping his commands like a monkey. I just want to get his configuration and 20s is max I can wait for this to happen. This includes things which are popular, but boring, e.g.: HTTP server, SQL server, Mail server etc.. configuration. I'd like to add my 3 domains: koszek.com freebsd.czest.pl something.com to FreeBSD system, pick my HTTP solution, my Mail solution, my SQL solution and have them installed in the most security-hardened way possible with 0 effort. - I keep all of important system actions versioned/logged, so that if I happen to have some problems with ports/packages, I can send the journal of what happened to my system, so that somebody can reproduce it. - in cases of problems with programs, I screen share my terminal with other FreeBSD IDs. I'd like to say: "I want FreeBSD ID 'cognet' to have access to this computer but only for watching", so that I can show the problem to the 2nd FreeBSD developer. It should also be possible to give full-access to the machine to the developer, so that in case of critical problems developer can reproduce exactly what's going on. - FreeBSD rarely asks me to compile anything. FreeBSD.org has powerful BSDCloud configuration which compiles everything for me. So if I want custom kernel configuration, I can mark checkboxes online and BSDCloud will compile the kernel quickly for me, so that I don't have to bother with it. - In case of problems, it's very easily to submit a record. FreeBSD loader, FreeBSD kernel and FreeBSD user-space utilities are all equiped with OCR-enabled/scannable mechanism, which lets me to use my phone to submit a bug report. It should be possible to e.g.: take a photo of a screen, have your phone recognize what the photo is all about and act accordingly via your FreeBSD ID (submit benchmark result, submit bug report, submit security problem etc..) - FreeBSD developers check in stuff to the repository. Upon check-in FreeBSD gets compiled and automatically booted on all possible platforms -- where possible in the BSDCloud, and where it's not possible, it gets booted on real hardware. Developer has access to the BSDCloud, so should the problem happen, the VM is frozen and dev. can login to it and see what's wrong. - Upon each commit FreeBSD regression test suite is run. Test suite tries to make sure FreeBSD is still runnable, and whether any regressions got introduced. Each unit test lets you to start, stop and modify existing VM by typing commands in it and comparing the result the expected one. Users can easily contribute to regression tests by recording their actions and contributing the recorded sessions back: their FreeBSD IDs can submit regression sets to the repository and their tests will be included in the next regression run. - FreeBSD documentation is always up-to-date. Regression suite is basically a specialized Domain Specific Language, that is especially annotated with comments which are an integral part of the code. This code is used to generate the documentation -- upon each action the screenshot is taken and explanation gets inserted. Once regression test is run, and screenshots are obtained, they get glued together for a slide-show (HTML page) or screencast and are being exported to YouTube. - Check-in process gets modified, so that only when all accepted regression sets are run, the check-in is accepted. - Documentation is available in easy-to-modify form for all FreeBSD IDs. Internal format for the documentation doesn't matter, since everything gets edited in the WWW browser anyway. - Once the document is submitted, it gets reviewed and accepted by the FreeBSD developer. Upon commit, all FreeBSD IDs whose users marked 'want to contribute to documentation' get the notification on document change. The ones which speak other languages get a chance to translate the changes right away and earn credits. - submission of regression test/patch/doc change earns FreeBSD ID certain reputation. FreeBSD ID could get tied to FreeBSD forums, so that people who help others a lot also get credits. There's a simple 'acceptance' formula: above X credits you get privileges A, B, C within FreeBSD.org. - FreeBSD development can happen entirely online, via BSDCould. Users and developers can edit files via WWW browser and do it the same way. They compile the system and boot it in VM and later, on the real hardware. - Upon making a change, I select 'users who have device X' and users who marked the checkbox 'Willing to test'. They get the VM which I used for testing available and can clone the VM's configuration to their system with 1 click, boot on their hardware and report the results. - Donation process gets modified so that users who care about certain devices a lot can send their hardware to BSDCloud. Hardware would get plugged in the physical hardware and since then regression tests testing this piece of hardware would be run on each commit. Expensive hardware can get linked with BSDCloud so that the machine stays on the owners side. This box is available via VPN just like any other BSDCloud box, and as long as it's available, regression suite is run on it as well. VPN works across firewall and proxies, so specialized platforms behind the corporate walls can also get tested. - On each commit set of benchmarks is run and visualized in the browser. The configuration can include the VM configurations, but can also involve hardware. So before performing a change, developer can see the impact of the change on the system performance. - On each commit set of power benchmarks is run. Couple of real hardware setups have power measurement attached to them and are able to export power profiling information upon commit. This is crucial for cell phones, which FreeBSD can run. ============ -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/