ftp, svgalib and who/proc problem

ftp, svgalib and who/proc problem

Post by Matthew Ston » Wed, 24 Sep 1997 04:00:00



I seem to be having a problem with my Linux system..  I have two linux
boxes one Redhat, the other Debian hooked together via Ethernet.  The
first problem is that I can't ftp into my Redhat box as a regular.
Whatever I try I always get a bad login.  The othre two problems are with
my Debian box.  when I try and run a program needing the svgalib.. It
doesn't work.  when I run it from a virtual console I get the following
error:
svgalib: cannot get I/O persmissions.

When I try the same program it goes:
[svgalib: allocated virtual console #8] but when I go over to console 8 I
see...
ioctl(VT_WAITACTIVE) Operation not permitted

Now I can run this in root but when I try and run it as a regular user I
can't.  The last problem I am having is in Debia.  I updated the packages
but now my w & who are messed up a bit.  When I do a w my X terminals now
don't show up and if I telnet into my machine it shows up abut when I
logoff and do a who it still says I am there.  It's not updating the utmp
or something.  I did update the procsfs system but still having this
trouble.  Anwyays ideas would be appreciated.

Regards,
Matthew

 
 
 

1. PROPOSAL: /proc standards (was dot-proc interface [was: /proc

Just think about it for a minute.

There are three ways to address "/proc":
 - 100% binary interface
  * human interaction doesn't belong in the kernel - period.
 - optimally formated text
  * not designed for humans, but in human format ("text")
 - human readable
  * thus the entire OS is reduced to "cat" and "echo"

Providing more than one interface/format means code duplication.  It doesn't
matter how much is actually compiled.  Someone has to write it.  Others have
to maintain it.  Suddenly a change in one place becomes a change in dozens
of places.

Personally, I vote for a 100% binary interface. (no surprise there.)  It
makes things in kernel land so much cleaner, faster, and smaller.  Yes,
it increases the demands on userland to some degree.  However, printf/scanf
is one hell of a lot more wasteful than a simple mov.

For my worst case scenerio, answer this:
  How do you tell how many processors are in a Linux box?

The kernel already knows this, but it isn't exposed to userland.  So, one
must resort to ass-backward, stupid shit like counting entries in
/proc/cpuinfo.  And to make things even worse, the format is different for
every arch! (I've been bitching about this for four (4) years.)

And for those misguided people who think processing text is faster than
binary, you're idiots.  The values start out as binary, get converted to
text, copied to the user, and then converted back to binary.  How the hell
is that faster than copying the original binary value? (Answer: it isn't.)

And those who *will* complain that binary structures are hard to work with,
(you're idiots too :-)) a struct is far easier to deal with than text
processing, esp. for anyone who knows what they are doing.  Yes, changes
to the struct do tend to break applications, but the same thing happens
to text based inputs as well.  Perhaps some of you will remember the stink
that arose when the layout of /proc/meminfo changed (and broke, basically,
everything.)

--Ricky

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Voodoo cards in Alpha

3. PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

4. advice about ADSL

5. Matrox Mystique ands X.

6. mandrake 8.1 too buggy to use!

7. /proc/stat description for proc.txt

8. help with 'GRUB hard disk error'

9. /proc/mounts or /proc/mtab

10. what does /proc or proc stand for?

11. /proc/net/tcp and /proc/net/udp

12. /proc/kcore vs. /proc/meminfo

13. /proc/<pid>/stat does not jive with proc(5) man page