Contents

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.

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 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.