--- wikisrc/users/jdf.mdwn 2012/04/04 11:08:09 1.1 +++ wikisrc/users/jdf.mdwn 2013/03/09 00:16:05 1.26 @@ -1,3 +1,222 @@ -[[!toc ]] +**Contents** + +[[!toc levels=2 ]] # jdf's wiki page + +Note: This is not what I'm really working on, it's just a place to gather some +notes I took about some topics. + +## Guide migration + +I'm currently trying to migrate the NetBSD guide to the wiki. The relevant +files are these ones: + + * chap-exinst + * inst-media + * inst + * mail + * net-intro + * net-practice + * net-services + * print + * rmmedia + +Already done: + + * audio + * bluetooth + * boot + * build + * carp + * ccd + * cgd + * cons + * dns + * edit + * index + * inetd + * intro + * fetch + * kernel + * linux + * lvm + * misc + * pam + * raidframe + * rc + * tuning + * updating + * upgrading + * veriexec + * x + +I started working on it in `guide/`, though the original proposal +was to store it in `guide/netbsd`. However, whoever wants to change the +directory can do so. + +## The new NetBSD guide + +The NetBSD guide, as well as its contents, is outdated. Of course there's +current documentation as well in it, but many parts of it are outdated. +The question is: What is the future of the NetBSD guide? + +Should we continue having something ordered by *book chapters*? Or should we +make it completely unordered with many howtos inside a wiki, which is also +printable, but not in a useful order? + +In my opinion, we should continue having a set of articles where the basic +subsystems of NetBSD are explained, but in the wiki. It shouldn't be too +difficult to create a book from that if you want to. +From all these subsystems, imho, the following topics should be covered: + +System basics: + + * Installation + * Security (CGD, PGP, veriexec, PAM) + * Disk handling (GPT, disklabel, MBR), creating filesystems, handling USB + flashdrives, automounting, CDs + * RAIDs with raidframe + * LVM + * Audio setup + * Keeping a NetBSD installation up-to-date + * The rc system, as compared to systemd and SysV + * Editing with vi + * X setup, graphics drivers, console drivers + * Backups with dump/restore and other options + * Printing (with cups?) + +Networking: + + * Basic network setup + * inetd setup + * Bluetooth + * DNS server setup and related issues + * Firewalling (describing *all* or linking guide of others) + +Building NetBSD: + + * Building the system with `build.sh` + * Configuring the kernel + * Fetching sources, staying -current + +Using extra packages: + + * Emulating Linux + * Using pkgsrc + * Using binary packages, using pkgin + * Installing a desktop environment + * Things to remember (e.g., no mplayer) + +## NetBSD flavoured + +Currently, NetBSD is a very generic operating system, leaving almost all +choices up to the user. While some consider this a strength, and it +definitely is for people who know what they're doing, it's an obstacle for +people who then have to setup *everything* by hand. + +Creating a *NetBSD flavoured* distribution shouldn't be much work, and require +just minor sysinst modifications. +It shouldn't be much work to just package distribution sets that already +include a list of packages it installs and several preconfigured configuration +files, maybe also some additional wrapper scripts. +On the other hand, you could also add some package calls to sysinst and just +provide a list of packages you consider necessary. + +My original attempt was to create a range of distributions for different +purposes, i.e. one for developers, one for graphic designers, one for servers, +etc. I don't know if this is the right way, esp. since some of the applications +are *very* specific. You cannot really provide a sane server default +installation except for some basic things like installing a vim, but that's all. +My current idea is to provide just one, maybe named *NetBSD flavoured*, with at +least the following tools on board: + + * vim + * pkgin + * git + * fossil + * subversion + * some other important VCSes + * light-desktop (i.e., LXDE) + * screen (tmux is in base) + * some sane X terminal emulators + * a browser (Firefox?!) + * a mailer (Thunderbird? Claws-mail?) + * emacs (maybe too large?) + * perl + * python + * mplayer (when it's possible to pack it up) + * pdf viewer + * preconfigured bozohttpd running on localhost showing documentation + +## NetBSD documentation + +In [this +post](http://mail-index.netbsd.org/netbsd-docs/2012/09/20/msg000295.html) +I shared some ideas about what to do with documentation. Though much of it +was proven not practical by the replies, I still have one idea: Unify +documentation of NetBSD, and provide it all on a NetBSD system. + +The first step is to merge as much content as possible into the NetBSD wiki. +Currently, the NetBSD documentation is very diverse in its distribution form. + +Then, the Google Code-In produced some nice results, including a CGI for a small +markdown wiki to browse the wiki (if it was offline), and maybe even a terminal +markdown browser. + +Finally, ship these two in a pkgsrc package or even with base, and provide a +small script which regularly updates the documentation. + +## NetBSD website + +Currently, the NetBSD website is written in HTML and Docbook and requires many +tools to be edited and committed. The final goal should be to have just a small +homepage with a bit important information, but all the essential technical +information should be in the wiki. There's also a separate page for this: +[[htdocs_migration]]. + +Though the plan is currently to migrate *all* contents to the wiki, I don't +think this is the way to go. A wiki just doesn't leave a good impression. + +## NetBSD community and marketing + +Just some thoughts... I think NetBSD has a very bad way of making technical +ecisions which are counterproductive from a marketing point of view, or just are +not used for marketing purposes. + +The world has changed; nowadays, there's a growing *hacker community* which +consists of many people with an age below 30. They're just not used to the +flexibility of the old tools Unix provides, and to the flexibility you have +with a modern Linux. + +There are repeating questions why NetBSD doesn't use git as its primary VCS, but +rather CVS. CVS *is* indeed a very mighty tool, but many people don't know. They +like git more because they can explicitly `push` with it (and don't know about +hooks in CVS or Subversion). +The same holds for many other decisions. + +NetBSD has a very... oldish view of how a community should be organised. On the +one hand, there are the developers, which are coding the project, maintaining +the website, maintaining packages, maintaining documentation, organising events, +organising NetBSD itself... and on the other hand, there are the users. They're +rather consumers than contributors. + +The few ones which want to contribute are doing so, and after some time becoming +developers with the right and possibility to do everything, but there's nothing +in between. There's only few community involvement overall, though there are +many topics which don't require a developer status. +I think breaking with the old habits and providing more community involvement +and community support is the way to go, but except for starting with a +user-editable wiki, I don't have many ideas how to do so. + +## NetBSD current + +The same problem exists imho with the release cycle. The standard release cycle +of NetBSD is too slow for many people who use it privately (just see how +wide-distributed Arch Linux got), and tracking current is a rather obscure thing +with compiling things on your own, etc. ... +And it's not well-documented. There *are* changes, but who knows them? Which was +the current version where tmux was imported? Etc. + +Tracking these changes more centrally, and providing a nice way to install and +track a current installation would be a great benefit for NetBSD.