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