BSD XXI Manifesto

(cross-posted message: eventual discussion let's keep on hackers_at_)

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_at_FreeBSD.czest.pl
http://FreeBSD.czest.pl/~wkoszek/