Initial commit

notes/stuff we gotta do ourselves

@@ -0,0 +1,68 @@
+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.