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