There's a lot that the SUS doesn't define, stuff that's up to us. This is a list
of some of that stuff.

Stuff it doesn't include:
=========================

Tools specifically use for for development. The development tools are, according
to the Guide to the Single Unix Specification, intended for the installation,
not development of debugging. This includes stuff like debuggers, assembly
language tools (like as), and program style tools (like linters). There can
be standards for this sort of thing (things that a linter might want to include,
assembly language definitions like the x86 assembly standard, etc.), but it's
not in the SUS. So, if we want to include any of these, we gotta do 'em
ourselves.

Stuff that isn't "useful to conforming applications"/"from shell scripts or 
typical application programs" This is a lot of user-facing stuff that they'd
use interactively and that can't be used from, like, a shell script and that
isn't useful for any of the goals of the SUS. For example, news and calendar
are listed this way. I definitely want those. I may also include a music player,
assuming I can figure that out. And, of course, other, similar applications,
like web browsers, RSS readers, etc. Stuff that we can just include if we want.

Things that might have been replaced. Specifically, I'm talking about cpio and
tar. Those were removed in favour of pax, but we still probably want those lying
around.

Things that have been subsumed by other applications. Sure, cpp and ld might be
a part of c99, but we probably still want those around separately, even if it's
just breaking the rule ("rule", guideline) that what a program does shouldn't be
determined by how it was invoked. (i.e. We just make c99 behave with linking
flags if started as ld and with compiling C++ flags if started as cpp.)

"Terminal-oriented" or otherwise low-level programs. Things like login, passwd,
chroot, or su. These are things we're gonna need but that the SUS doesn't touch.
(Oh, and wall.)

mknod. It's only excluded for being too implementation-defined, but we still
probably want it.

Graphical interfaces. Curses is part of the SUS, but anything beyond that
(X servers, the actual interfaces that run on said servers) is up to us (at
least to the extent there isn't a standard; we can't just write our own graphics
server and call it X11).

Anything on the system level. XSH defines a lot of interfaces to that system
level stuff, and I think there are a few more utilities that do that interfacing
in XCU, but the kernel level stuff they reference is up to us. This includes
how we do scheduling (niceness notwithstanding), memory allocation (as called
through the malloc family), interrupts, hard disk stuff (including the file
system), and more.

dump, an old backup program. Fun stuff.

Stuff the standard mentions probably needing:
=============================================

Text formatting. I'd put my money on troff, but we could do TeX. The POSIX
standard mentioned work in the area of SGML could help, as this is something
they feel they don't have but need, and the FHS mentioned SGML directories, so
we could do SGML (though I think I'd rather do troff).

More control over printing. Specifically, I think we're gonna have an lpd,
instead of lp just going straight to the printer, so we could have control over
scheduling (and even cancelling) print jobs. We could also probably put in some
stuff to help with formatting print jobs.

Tools for working in other programming langauges besides C and FORTRAN.