summaryrefslogtreecommitdiffstats
path: root/TODO
blob: f92d0eca347d6c75d625971f6e7aac399bdf6508 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
General

* Make damn certain our Docbook markup is both _CORRECT_ and
  _CONSISTANT_. There's many places where the <screen> sections
  are very different. They should all be of this form.

<screen>
  <prompt>darkstar:~$ <prompt><userinput>_EVERYTHING_ the user types</userinput>
  Anything the screen prints that the user doesn't type.
</screen>

  I've found several cases where the <command> tag was used inside of a
  <screen> section. This is wrong and must be avoided. When the book
  goes to the publisher, all of those <command> tags will be formatted
  one way for printing and the <userinput> tags could be formatted
  another. Also, wrapping only applications in <command> tags could
  make the reader wonder just how much they are supposed to type.

* Aim to update references to kernel versions and Slackware versions to those 
  used in the most recent release of Slackware. I've seen kernel 2.6.29.4 and 
  Slackware 12.0.0 for instance.

* more extensive CLI apps like v2.0

* no idea where the hell udev is covered in here, but we need to do a bit of
  talk about it.  Nothing too advanced, and we definitely DO NOT want to 
  imply that users should have to do much with udev.  All of the asshattery
  out there with trying to automount shit with udev is, well, asshattery.
  * need to mention that /etc/udev/rules.d/<somefile> overrides an identically
    named file in /lib/udev/rules.d/
  * need to mention persistent rules that are system-generated, especially
    in reference to how the admin might be misled into thinking that they are
    causing breakage...
  * need to point out that the persistent rules themselves are (according
    to upstream) a bad idea - not sure I completely agree, but there is a 
    lot of potential for breakage, it seems...

* Need to mention iptables somewhere - perhaps consolidate some bits from
  my iptables/netfilter presentations?  --rworkman

Chapter 16. Basic Networking Commands

* The various curses mail clients (pine, mutt) should have
"screenshots" for consistency to match other curses programs (in
particular the installer) so new users can get a real feel for how
these tools work.

* Additionally the section on mutt needs to be reworked where it refers
to fetchmail, procmail, formail, etc. These are all seperate tools and
if we refer to them at all it should be as seperate tools with their
own subsections.