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