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: * bluetooth
16: * build
17: * carp
18: * ccd
19: * cgd
20: * chap-exinst
21: * chap-intro
22: * cons
23: * dns
24: * edit
25: * fetch
26: * index
27: * inetd
28: * inst-media
29: * inst
30: * kernel
31: * linux
32: * lvm
33: * mail
34: * misc
35: * net-intro
36: * net-practice
37: * net-services
38: * pam
39: * preface
40: * print
41: * rmmedia
42: * tuning
43: * upgrading
44:
45: Already done:
46:
47: * audio
48: * boot
49: * raidframe
50: * rc
51: * updating
52: * veriexec
53: * x
54:
55: I started working on it in `guide/`, though the original proposal
56: was to store it in `guide/netbsd`. However, whoever wants to change the
57: directory can do so.
58:
59: ## NetBSD flavoured
60:
61: Currently, NetBSD is a very generic operating system, leaving almost all
62: choices up to the user. While some consider this a strength, and it
63: definitely is for people who know what they're doing, it's an obstacle for
64: people who then have to setup *everything* by hand.
65:
66: Creating a *NetBSD flavoured* distribution shouldn't be much work, and require
67: just minor sysinst modifications.
68: It shouldn't be much work to just package distribution sets that already
69: include a list of packages it installs and several preconfigured configuration
70: files, maybe also some additional wrapper scripts.
71: On the other hand, you could also add some package calls to sysinst and just
72: provide a list of packages you consider necessary.
73:
74: My original attempt was to create a range of distributions for different
75: purposes, i.e. one for developers, one for graphic designers, one for servers,
76: etc. I don't know if this is the right way, esp. since some of the applications
77: are *very* specific. You cannot really provide a sane server default
78: installation except for some basic things like installing a vim, but that's all.
79: My current idea is to provide just one, maybe named *NetBSD flavoured*, with at
80: least the following tools on board:
81:
82: * vim
83: * pkgin
84: * git
85: * fossil
86: * subversion
87: * some other important VCSes
88: * light-desktop (i.e., LXDE)
89: * screen (tmux is in base)
90: * some sane X terminal emulators
91: * a browser (Firefox?!)
92: * a mailer (Thunderbird? Claws-mail?)
93: * emacs (maybe too large?)
94: * perl
95: * python
96: * mplayer (when it's possible to pack it up)
97: * pdf viewer
98: * preconfigured bozohttpd running on localhost showing documentation
99:
100: ## NetBSD documentation
101:
102: In [this
103: post](http://mail-index.netbsd.org/netbsd-docs/2012/09/20/msg000295.html)
104: I shared some ideas about what to do with documentation. Though much of it
105: was proven not practical by the replies, I still have one idea: Unify
106: documentation of NetBSD, and provide it all on a NetBSD system.
107:
108: The first step is to merge as much content as possible into the NetBSD wiki.
109: Currently, the NetBSD documentation is very diverse in its distribution form.
110:
111: Then, the Google Code-In produced some nice results, including a CGI for a small
112: markdown wiki to browse the wiki (if it was offline), and maybe even a terminal
113: markdown browser.
114:
115: Finally, ship these two in a pkgsrc package or even with base, and provide a
116: small script which regularly updates the documentation.
117:
118: ## NetBSD website
119:
120: Currently, the NetBSD website is written in HTML and Docbook and requires many
121: tools to be edited and committed. The final goal should be to have just a small
122: homepage with a bit important information, but all the essential technical
123: information should be in the wiki. There's also a separate page for this:
124: [[htdocs_migration]].
125:
126: Though the plan is currently to migrate *all* contents to the wiki, I don't
127: think this is the way to go. A wiki just doesn't leave a good impression.
128:
129: ## NetBSD community and marketing
130:
131: Just some thoughts... I think NetBSD has a very bad way of making technical
132: ecisions which are counterproductive from a marketing point of view, or just are
133: not used for marketing purposes.
134:
135: The world has changed; nowadays, there's a growing *hacker community* which
136: consists of many people with an age below 30. They're just not used to the
137: flexibility of the old tools Unix provides, and to the flexibility you have
138: with a modern Linux.
139:
140: There are repeating questions why NetBSD doesn't use git as its primary VCS, but
141: rather CVS. CVS *is* indeed a very mighty tool, but many people don't know. They
142: like git more because they can explicitly `push` with it (and don't know about
143: hooks in CVS or Subversion).
144: The same holds for many other decisions.
145:
146: NetBSD has a very... oldish view of how a community should be organised. On the
147: one hand, there are the developers, which are coding the project, maintaining
148: the website, maintaining packages, maintaining documentation, organising events,
149: organising NetBSD itself... and on the other hand, there are the users. They're
150: rather consumers than contributors.
151:
152: The few ones which want to contribute are doing so, and after some time becoming
153: developers with the right and possibility to do everything, but there's nothing
154: in between. There's only few community involvement overall, though there are
155: many topics which don't require a developer status.
156: I think breaking with the old habits and providing more community involvement
157: and community support is the way to go, but except for starting with a
158: user-editable wiki, I don't have many ideas how to do so.
159:
160: ## NetBSD current
161:
162: The same problem exists imho with the release cycle. The standard release cycle
163: of NetBSD is too slow for many people who use it privately (just see how
164: wide-distributed Arch Linux got), and tracking current is a rather obscure thing
165: with compiling things on your own, etc. ...
166: And it's not well-documented. There *are* changes, but who knows them? Which was
167: the current version where tmux was imported? Etc.
168:
169: Tracking these changes more centrally, and providing a nice way to install and
170: track a current installation would be a great benefit for NetBSD.
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb