1: **Contents**
2:
3: [[!toc levels=2 ]]
4:
5: # jdf's wiki page
6:
7: Note: This is not what I'm really working on, it's just a place to gather some
8: notes I took about some topics.
9:
10: ## The new NetBSD guide
11:
12: The NetBSD guide, as well as its contents, is outdated. Of course there's
13: current documentation as well in it, but many parts of it are outdated.
14: The question is: What is the future of the NetBSD guide?
15:
16: Should we continue having something ordered by *book chapters*? Or should we
17: make it completely unordered with many howtos inside a wiki, which is also
18: printable, but not in a useful order?
19:
20: In my opinion, we should continue having a set of articles where the basic
21: subsystems of NetBSD are explained, but in the wiki. It shouldn't be too
22: difficult to create a book from that if you want to.
23: From all these subsystems, imho, the following topics should be covered:
24:
25: System basics:
26:
27: * Installation
28: * Security (CGD, PGP, veriexec, PAM)
29: * Disk handling (GPT, disklabel, MBR), creating filesystems, handling USB
30: flashdrives, automounting, CDs
31: * RAIDs with raidframe
32: * LVM
33: * Audio setup
34: * Keeping a NetBSD installation up-to-date
35: * The rc system, as compared to systemd and SysV
36: * Editing with vi
37: * X setup, graphics drivers, console drivers
38: * Backups with dump/restore and other options
39: * Printing (with cups?)
40:
41: Networking:
42:
43: * Basic network setup
44: * inetd setup
45: * Bluetooth
46: * DNS server setup and related issues
47: * Firewalling (describing *all* or linking guide of others)
48:
49: Building NetBSD:
50:
51: * Building the system with `build.sh`
52: * Configuring the kernel
53: * Fetching sources, staying -current
54:
55: Using extra packages:
56:
57: * Emulating Linux
58: * Using pkgsrc
59: * Using binary packages, using pkgin
60: * Installing a desktop environment
61: * Things to remember (e.g., no mplayer)
62:
63: ## NetBSD flavoured
64:
65: Currently, NetBSD is a very generic operating system, leaving almost all
66: choices up to the user. While some consider this a strength, and it
67: definitely is for people who know what they're doing, it's an obstacle for
68: people who then have to setup *everything* by hand.
69:
70: Creating a *NetBSD flavoured* distribution shouldn't be much work, and require
71: just minor sysinst modifications.
72: It shouldn't be much work to just package distribution sets that already
73: include a list of packages it installs and several preconfigured configuration
74: files, maybe also some additional wrapper scripts.
75: On the other hand, you could also add some package calls to sysinst and just
76: provide a list of packages you consider necessary.
77:
78: My original attempt was to create a range of distributions for different
79: purposes, i.e. one for developers, one for graphic designers, one for servers,
80: etc. I don't know if this is the right way, esp. since some of the applications
81: are *very* specific. You cannot really provide a sane server default
82: installation except for some basic things like installing a vim, but that's all.
83: My current idea is to provide just one, maybe named *NetBSD flavoured*, with at
84: least the following tools on board:
85:
86: * vim
87: * pkgin
88: * git
89: * fossil
90: * subversion
91: * some other important VCSes
92: * light-desktop (i.e., LXDE)
93: * screen (tmux is in base)
94: * some sane X terminal emulators
95: * a browser (Firefox?!)
96: * a mailer (Thunderbird? Claws-mail?)
97: * emacs (maybe too large?)
98: * perl
99: * python
100: * mplayer (when it's possible to pack it up)
101: * pdf viewer
102: * preconfigured bozohttpd running on localhost showing documentation
103:
104: ## NetBSD documentation
105:
106: In [this
107: post](http://mail-index.netbsd.org/netbsd-docs/2012/09/20/msg000295.html)
108: I shared some ideas about what to do with documentation. Though much of it
109: was proven not practical by the replies, I still have one idea: Unify
110: documentation of NetBSD, and provide it all on a NetBSD system.
111:
112: The first step is to merge as much content as possible into the NetBSD wiki.
113: Currently, the NetBSD documentation is very diverse in its distribution form.
114:
115: Then, the Google Code-In produced some nice results, including a CGI for a small
116: markdown wiki to browse the wiki (if it was offline), and maybe even a terminal
117: markdown browser.
118:
119: Finally, ship these two in a pkgsrc package or even with base, and provide a
120: small script which regularly updates the documentation.
121:
122: ## NetBSD website
123:
124: Currently, the NetBSD website is written in HTML and Docbook and requires many
125: tools to be edited and committed. The final goal should be to have just a small
126: homepage with a bit important information, but all the essential technical
127: information should be in the wiki. There's also a separate page for this:
128: [[htdocs_migration]].
129:
130: Though the plan is currently to migrate *all* contents to the wiki, I don't
131: think this is the way to go. A wiki just doesn't leave a good impression.
132:
133: ## NetBSD community and marketing
134:
135: Just some thoughts... I think NetBSD has a very bad way of making technical
136: ecisions which are counterproductive from a marketing point of view, or just are
137: not used for marketing purposes.
138:
139: The world has changed; nowadays, there's a growing *hacker community* which
140: consists of many people with an age below 30. They're just not used to the
141: flexibility of the old tools Unix provides, and to the flexibility you have
142: with a modern Linux.
143:
144: There are repeating questions why NetBSD doesn't use git as its primary VCS, but
145: rather CVS. CVS *is* indeed a very mighty tool, but many people don't know. They
146: like git more because they can explicitly `push` with it (and don't know about
147: hooks in CVS or Subversion).
148: The same holds for many other decisions.
149:
150: NetBSD has a very... oldish view of how a community should be organised. On the
151: one hand, there are the developers, which are coding the project, maintaining
152: the website, maintaining packages, maintaining documentation, organising events,
153: organising NetBSD itself... and on the other hand, there are the users. They're
154: rather consumers than contributors.
155:
156: The few ones which want to contribute are doing so, and after some time becoming
157: developers with the right and possibility to do everything, but there's nothing
158: in between. There's only few community involvement overall, though there are
159: many topics which don't require a developer status.
160: I think breaking with the old habits and providing more community involvement
161: and community support is the way to go, but except for starting with a
162: user-editable wiki, I don't have many ideas how to do so.
163:
164: ## NetBSD current
165:
166: The same problem exists imho with the release cycle. The standard release cycle
167: of NetBSD is too slow for many people who use it privately (just see how
168: wide-distributed Arch Linux got), and tracking current is a rather obscure thing
169: with compiling things on your own, etc. ...
170: And it's not well-documented. There *are* changes, but who knows them? Which was
171: the current version where tmux was imported? Etc.
172:
173: Tracking these changes more centrally, and providing a nice way to install and
174: track a current installation would be a great benefit for NetBSD.
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb