>> I think the following change to glibc was a mistake:
>>
>> 1999-07-07 Andreas Schwab <schwab@suse.de>
>>
>> * sysdeps/unix/sysv/linux/getpt.c: Check that /dev/pts is mounted.
>> (_PATH_DEVPTS, DEVPTS_SUPER_MAGIC): New definitions.
>> (_PATH_DEVPTMX): Use _PATH_DEV.
>>
>> Just as with the BSD pty's it is the job of the system administrator
>> to make sure that the nodes for the Unix98 pty slaves exist in the
>> filesystem. This can be done by several means. The canonical way is
> I think you haven't read all the postings in the news about people complainig
> that xterm or ssh or whatever doesn't work, because they have removed the
> /dev/pts entry from fstab ?
> In a perfect Linux world, everbody knows what he is doing and is a perfect
> unix system administrator. In the real world, a lot of people doesn't know
> anything about Unix. They think, I don't know what /dev/pts is, so I don't
> need it and I can remove it.
I seen users who removed proc from there as well and got strange results.
I seen users who removed IPC from kernel and got even strangier results.
Now what ? Let's remove such choice from kernel and add automounting of
/proc ? And so on ? Guess what you'll get in the end ?
> We also have to think on this people,not only on hacker, developer and
> admins.
It's EXACTLY what I *HATE* in Windows: this beast knows what I want to do
far better then I am :-/ When I do /dev/pts handling some non-standard way
(with daemon, for example) I DO NOT want to scan all possible libraries where
Unix98 ptys can be used. To me situation where newcomer can hurt himseft with
removal of /dev/pts from fstab is better then situation where libraries are
using magic to keep working in misconfigured system. You can do quite a few
bad things to make you life horrible (try to remove /dev/null or remove /tmp,
for example :-) and the more magic is added in system the more troubles we'll
get in future.
P.S. There are exist tools to find out such problems (like linuxconf). Glibc
is BAD place to find and fix configuration problems...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/