68 lines
3.4 KiB
Plaintext
68 lines
3.4 KiB
Plaintext
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. |