File:  [NetBSD Developer Wiki] / wikisrc / users / jdf.mdwn
Revision 1.11: download - view: text, annotated - select for diffs
Wed Feb 27 00:02:45 2013 UTC (7 years, 1 month ago) by jdf
Branches: MAIN
CVS tags: HEAD
Add guide migration status

    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:  * 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: 
   64: ## NetBSD flavoured
   65: 
   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:
   86: 
   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: 
  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 
  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.
  173: 
  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