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