Is A/UX Mature?

[Jan Purchase]

Recently I installed A/UX 2.0.1 (fortunately, without incident) and
although I am impressed with the system, I am surprised by the number
of niggling bugs which it apparently did not correct. I installed the
ftp'able upgrade, so it might be that the 'bugs' I'm about to cover
are due to defficiences in this upgrade path, or indeed to my lack of
knowledge! However, I'd be very grateful if anyone out there could
give me work-arounds, fixes, say "Oh yeh, I get that too!", or correct
the error of my ways concerning the following problems:


a) Why, after I have used settimezone (as root) to set the system time
zone to "GB-Eire", does the command "at" fail to work properly
although "date" shows the correct time? Typically the argument of "at"
is always interpreted as one hour sooner that it actually is, so that
the command
	% at now + 5 minutes
gives:
	at: too late
whereas:
	% at now + 65 minutes works and schedules a job to execute in
5 minutes time. I realise that I could just tolerate this or use the
timezones GMT and GMT+1 (switching manually in late March and
October), but computers are supposed to make life easier. Other mac
applications also seem to have timezone related problems, print
submission is a prime example. Under GB-Eire, submitting a print job
via PrintMonitor causes it to be queued 1 hour in the future!


b) Why do mail headers express the send-time of a message in the
system time zone in one part and in PDT in the other two? The mixing
of time zones is very confusing. Why is sendmail annotating mail
messages with PDT at all if the system TZ is ":GB-Eire"?

c) Why can one not change the speed of a serial port which does not
have a getty process associated with it (e.g., one connected
to a outgoing only modem)?  commands like:
	stty -n /dev/modem 1200
or:
	stty 1200 < /dev/modem
which are quoted in SVR2 text books have no effect. A/UX just keeps
the line speed at the default 9600 baud.


d) Why does wall refuse to write to terminal devices it cannot read
from? On executing "wall", as a normal user, one gets:
	Will not write to /dev/console, sid
	Will not write to /dev/ttyC1, sid
and your message will not get to user sid. Surely permission to wall
should be granted on write access not read access!

e) Why do talk and write only function if the target terminal device
is world writable? Surely permission should be granted according to an
individuals access to the target device. Hence if the user using
write is a member of group x and the terminal device is group writable
by x then write should work, right? No. It returns:
	Permission denied.
even if the user is root! talk behaves in a similar fashion returning:
	[Your party is not accepting messages]
This is silly. It means that no-one, not even root, may talk or write
to someone unless everybody can.

Point (e) also prevents a wise superuser from setting up a group "tty" to
which all terminal devices belong. This, in conjunction with setting
write and talk sgid tty, means that users may inter-communicate with write
and talk in the normal way (disabling it with mesg if required), but
may not redirect text to each others terminals anonymously (a
favourite trick amongst undergraduates) using ">".

Will A/UX ever lose these "immaturities"? I realise that other
versions of UNIX have bugs too, but I don't believe that they are this
fundamental.


Any help with these questions would be greatly appreciated.
Cheers
Jan.