--- wikisrc/users/jdf.mdwn 2012/04/07 22:56:13 1.3 +++ wikisrc/users/jdf.mdwn 2013/03/04 00:33:23 1.17 @@ -1,46 +1,169 @@ -[[!toc ]] +**Contents** -# jdf's wiki page - -This is just my wiki page where I want to write down my goals, project ideas, running projects and what I generally want to do. - - -# project ideas - -These project ideas are not sufficient for the [[projects]], perhaps only my own stupid ideas, but what I would like to see for NetBSD. Some of them might be redundant with the official ones, but these are the ones I might personally take care of one day. - -* zfs -- there was an attempt to port zfs to NetBSD, but it stalled. Somebody to take care of zfs being imported to NetBSD, and running smooth, would be *very* nice. -* HAMMER -- I don't know much about it (see DragonFly BSD), but from what you can read, it seems very nice. Looking at the current state of Oracle and zfs, it might be better to care for HAMMER than zfs. On the other hand, zfs is very stable and widely distributed. -* unionfs -- there are some bugs with union I would like to see fixed. Imagine running a live CD by having a root read-only, and then simply mounting a tmpfs writable upon that. -* raidfs -- once unionfs is fixed, it could be possible to integrate a mirror, perhaps some redundancy checks with unionfs to have a flexible raid on vnode basis, not depending on the underlying filesystem or device. -* update -- imho this is being worked on, but I don't remember who it was. Like the freebsd-update tool from FreeBSD, an easy way to update NetBSD base system from binary. Currently, you have to unpack manually and run [[!template id=man section="8" name="etcupdate"]], or use [[!template id=man name="sysinst" section="8"]] for this purpose. Running something that fetches the necessary updates and updates these files would be nice. -* bdutil -- a tool for unified disk editing, and not having to use [[!template id=man name="disklabel" section="8"]], [[!template id=man name="gpt" section="8"]], [[!template id=man name="fdisk" section="8"]], and [[!template id=man name="dkctl" section="8"]] separately, which can be very confusing, would be very nice. This shouldn't be too difficult. The functionality and the code is there, you just had to think of a usage, rewrite the frontend, and provide a compatibility mode for the old tools. -* userwiki -- I know this is a controversary topic... So no matter how and where, but having a place where users can contribute content in an ordered way (i.e., not on a mailing list), would be nice. See below for advocacy. -* sysinst -- there is already a marked project for that, and a GSoC-applicant working on this. Generally improve sysinst, provide partitioning for gpt, etc. Perhaps think about porting [[bsdinstaller.org]]. +[[!toc levels=2 ]] -I won't be working on this, as I'm not really into such low-level things: - -* run NetBSD in a web browser. There was a project which ran Linux in a web browser. If it's possible, NetBSD should run in a web browser, too. - - -# My personal interests - -I'm not into pkgsrc, but for the easy packages I use regularly, I try to help updating them. +# jdf's wiki page -* fixing small userland bugs -* importing and caring for sysutils/fscd (a daemon to check service run state) -* writing mkdumpdisk - a tool to backup the system, including restore -* caring for [[!template id=pkg category="www" name="opera"]] being up-to-date -* caring for [[!template id=pkg category="devel" name="fossil"]] being up-to-date -* keeping the events site up-to-date -* improving [[!template id=man name="sysinst" section="8"]] +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 -# Advocacy +I'm currently trying to migrate the NetBSD guide to the wiki. The relevant +files are these ones: -Imho, NetBSD currently doesn't have a good visibility in the Open Source community. These are my observations (if I knew solutions, I would write or apply them ;-): + * bluetooth + * build + * carp + * ccd + * cgd + * chap-exinst + * cons + * dns + * edit + * fetch + * inetd + * inst-media + * inst + * linux + * lvm + * mail + * misc + * net-intro + * net-practice + * net-services + * pam + * print + * rmmedia + * tuning + +Already done: + + * audio + * boot + * index + * intro + * kernel + * raidframe + * rc + * updating + * upgrading + * veriexec + * x + +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. -* I have seen several smaller software projects which provide compiled binaries on their website, in many cases there was just a reference to "look into your system's package management, it's already there." For nearly all of them, the package is in pkgsrc, but the website doesn't reference it. -* Though NetBSD is represented at most of the larger Open Source events, the advocacy material could be updated. In central Europe, there are already new flyers, badges as giveaways, T-Shirts and badges to sell, but there could be more. If you have ideas, write to netbsd-advocacy (at) NetBSD (dot) org. -* There are many nice projects within NetBSD, but they aren't very visibile from the outside. [[!template id=man name="rump" section="3"]]? [[!template id=man name="npf" section="3"]]? The new [[!template id=man name="apropos" section="1"]]? All the prestigous projects are often kept silent, commited, used, but most people outside the NetBSD community (and especially *BSD) know about them. -* For contributors with "minor" interests like writing small articles, correcting manpages, and providing other types of small patches, it seems extraordinarily difficult to get things done. A user-commitable wiki, and some methods to improve developer-contributor communication, might help here. +Tracking these changes more centrally, and providing a nice way to install and +track a current installation would be a great benefit for NetBSD.