BSD XXI Manifesto
Wojciech A. Koszek
wkoszek at freebsd.org
Tue Feb 18 07:29:23 UTC 2014
(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 at FreeBSD.czest.pl
http://FreeBSD.czest.pl/~wkoszek/
More information about the freebsd-hackers
mailing list