[BACK]Return to jdf.mdwn CVS log [TXT] [DIR] Up to [NetBSD Developer Wiki] / wikisrc / users

Diff for /wikisrc/users/jdf.mdwn between versions 1.1 and 1.14

version 1.1, 2012/04/04 11:08:09 version 1.14, 2013/03/02 13:25:55
Line 1 Line 1
 [[!toc ]]  **Contents**
   
   [[!toc levels=2 ]]
   
 # jdf's wiki page  # jdf's wiki page
   
   Note: This is not what I'm really working on, it's just a place to gather some 
   notes I took about some topics.
   
   ## Guide migration
   
   I'm currently trying to migrate the NetBSD guide to the wiki. The relevant
   files are these ones:
   
    * bluetooth
    * build
    * carp
    * ccd
    * cgd
    * chap-exinst
    * chap-intro
    * cons
    * dns
    * edit
    * fetch
    * index
    * inetd
    * inst-media
    * inst
    * kernel
    * linux
    * lvm
    * mail
    * misc
    * net-intro
    * net-practice
    * net-services
    * pam
    * preface
    * print
    * rmmedia
    * tuning
    * upgrading
    * x
   
   Already done:
   
    * audio
    * boot
    * raidframe
    * rc
    * updating
    * veriexec
   
   I started working on it in `guide/`, though the original proposal
   was to store it in `guide/netbsd`. However, whoever wants to change the
   directory can do so.
   
   ## NetBSD flavoured
   
   Currently, NetBSD is a very generic operating system, leaving almost all
   choices up to the user. While some consider this a strength, and it
   definitely is for people who know what they're doing, it's an obstacle for
   people who then have to setup *everything* by hand.
   
   Creating a *NetBSD flavoured* distribution shouldn't be much work, and require 
   just minor sysinst modifications.
   It shouldn't be much work to just package distribution sets that already
   include a list of packages it installs and several preconfigured configuration
   files, maybe also some additional wrapper scripts.
   On the other hand, you could also add some package calls to sysinst and just 
   provide a list of packages you consider necessary.
   
   My original attempt was to create a range of distributions for different 
   purposes, i.e. one for developers, one for graphic designers, one for servers, 
   etc. I don't know if this is the right way, esp. since some of the applications 
   are *very* specific. You cannot really provide a sane server default 
   installation except for some basic things like installing a vim, but that's all.
   My current idea is to provide just one, maybe named *NetBSD flavoured*, with at 
   least the following tools on board:
   
    * vim
    * pkgin
    * git
    * fossil
    * subversion
    * some other important VCSes
    * light-desktop (i.e., LXDE)
    * screen (tmux is in base)
    * some sane X terminal emulators
    * a browser (Firefox?!)
    * a mailer (Thunderbird? Claws-mail?)
    * emacs (maybe too large?)
    * perl
    * python
    * mplayer (when it's possible to pack it up)
    * pdf viewer
    * preconfigured bozohttpd running on localhost showing documentation
   
   ## NetBSD documentation
   
   In [this 
   post](http://mail-index.netbsd.org/netbsd-docs/2012/09/20/msg000295.html)
   I shared some ideas about what to do with documentation. Though much of it 
   was proven not practical by the replies, I still have one idea: Unify 
   documentation of NetBSD, and provide it all on a NetBSD system.
   
   The first step is to merge as much content as possible into the NetBSD wiki. 
   Currently, the NetBSD documentation is very diverse in its distribution form.
   
   Then, the Google Code-In produced some nice results, including a CGI for a small 
   markdown wiki to browse the wiki (if it was offline), and maybe even a terminal 
   markdown browser.
   
   Finally, ship these two in a pkgsrc package or even with base, and provide a 
   small script which regularly updates the documentation.
   
   ## NetBSD website
   
   Currently, the NetBSD website is written in HTML and Docbook and requires many 
   tools to be edited and committed. The final goal should be to have just a small 
   homepage with a bit important information, but all the essential technical 
   information should be in the wiki. There's also a separate page for this: 
   [[htdocs_migration]].
   
   Though the plan is currently to migrate *all* contents to the wiki, I don't 
   think this is the way to go. A wiki just doesn't leave a good impression.
   
   ## NetBSD community and marketing
   
   Just some thoughts... I think NetBSD has a very bad way of making technical 
   ecisions which are counterproductive from a marketing point of view, or just are 
   not used for marketing purposes.
   
   The world has changed; nowadays, there's a growing *hacker community* which 
   consists of many people with an age below 30. They're just not used to the 
   flexibility of the old tools Unix provides, and to the flexibility you have 
   with a modern Linux.
   
   There are repeating questions why NetBSD doesn't use git as its primary VCS, but 
   rather CVS. CVS *is* indeed a very mighty tool, but many people don't know. They 
   like git more because they can explicitly `push` with it (and don't know about 
   hooks in CVS or Subversion).
   The same holds for many other decisions.
   
   NetBSD has a very... oldish view of how a community should be organised. On the 
   one hand, there are the developers, which are coding the project, maintaining 
   the website, maintaining packages, maintaining documentation, organising events, 
   organising NetBSD itself... and on the other hand, there are the users. They're 
   rather consumers than contributors.
   
   The few ones which want to contribute are doing so, and after some time becoming 
   developers with the right and possibility to do everything, but there's nothing
   in between. There's only few community involvement overall, though there are
   many topics which don't require a developer status.
   I think breaking with the old habits and providing more community involvement 
   and community support is the way to go, but except for starting with a 
   user-editable wiki, I don't have many ideas how to do so.
   
   ## NetBSD current
   
   The same problem exists imho with the release cycle. The standard release cycle 
   of NetBSD is too slow for many people who use it privately (just see how 
   wide-distributed Arch Linux got), and tracking current is a rather obscure thing 
   with compiling things on your own, etc. ...
   And it's not well-documented. There *are* changes, but who knows them? Which was 
   the current version where tmux was imported? Etc.
   
   Tracking these changes more centrally, and providing a nice way to install and 
   track a current installation would be a great benefit for NetBSD.
Removed from v.1.1  
changed lines
  Added in v.1.14

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb