File:  [NetBSD Developer Wiki] / wikisrc / users / jdf.mdwn
Revision 1.31: download - view: text, annotated - select for diffs
Mon Mar 11 21:48:29 2013 UTC (7 years, 7 months ago) by jdf
Branches: MAIN
CVS tags: HEAD
Remove sections done.

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

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