Linux-Development-Sys Digest #139, Volume #7 Wed, 1 Sep 99 22:14:23 EDT
Contents:
Re: TAO: the ultimate OS ("Vladimir Z. Nuri")
Re: POST codes (Peter Pointner)
Re: where are packets created? (Matthew)
Re: TAO: the ultimate OS (EdToy)
Re: Rockwell PCI Modem? (Peter Samuelson)
Re: TAO: the ultimate OS (Graffiti)
GGI vs. framebuffer (J�rgen Hermanrud Fjeld)
Re: Kernel 2.3.15 compilation problem (Peter Samuelson)
Re: PROPOSAL: A secure, simple NIS replacement (Peter T. Breuer)
Re: Linux real-time clock Y2K support (bill davidsen)
Re: Mouse (Peter Samuelson)
Re: GGI vs. framebuffer (Christopher Browne)
Re: The optimization debate (was: why not C++?) (Christopher Browne)
----------------------------------------------------------------------------
From: "Vladimir Z. Nuri" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 20:12:09 GMT
to clarify..
In comp.os.misc Peter T. Breuer <[EMAIL PROTECTED]> wrote:
: It seems to me that the proof works irrespective of sandboxing. What
: would stop the proof would be that every program is run in its own
: sandbox.
exactly. and the function "check a program [y] for whether it could
be a virus" may not be available in a sandbox 'n' whereas it
is available in the higher OS.
there are different ways to define "virus"..
1. a program that when run, does damage the OS
2. a program that can potentially damage the OS when run
now, clearly, (1) seems to require a solution to the
halting problem, i.e. knowing what a program will do
before it does it so to speak. a theoretical impossibility.
but for (2) it is quite possible to create programs that are fully
functional yet have no potential to disrupt the OS.
so by changing the definition of what a virus is slightly, we could
theoretically create a virus-proof OS.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
state of the art OS research email http://www.egroups.com/groups/os-edge/
Tao OS / Taos / the transcendental OS http://www8.pair.com/mnajtiv/tao.html
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: POST codes
Date: Wed, 1 Sep 1999 20:11:39 GMT
Poe_7 <[EMAIL PROTECTED]> wrote:
> I am trying to bring a Debian version of Linux (Slink) up on a
> Pentium II system with a new chipset that is in development (i.e.
> non-stable hardware).
> Right after Linux decompresses the kernel it displays a message
> saying "Now booting the kernel" and locks the bus. Before it totally
> dies it sends out lots of port 80 writes. I'm assuming that they are
> POST codes and not just junk. I'm looking for a resource which
> describes the POST code meanings, either in the source or on a web
> page, etc.
It is junk, the kernel uses that to get small delays.
>From linux/include/asm-i386:
#define __SLOW_DOWN_IO __asm__ __volatile__("outb %al,$0x80")
You get whatever is in %al.
> Also, after the kernel decompression there is the jump to 0x100000 which
> if I'm not mistaken is the kernel starting address. Which equivalent C
> code is being executed at this point?
It's not C code, at least in my 2.0.36 kernel it jumps to
/usr/src/linux/arch/i386/kernel/head.S
I'm not sure if this is still true for 2.2.x, but you can simply look at
your System.map file, find out the symbol, and grep for that.
But you might see if it gets till start_kernel(..) in
/usr/src/linux/init/main.c
You might put in something like
while(1) outb(0xwhatever, 0x80);
there, and see if you get there.
Peter
------------------------------
From: Matthew <[EMAIL PROTECTED]>
Subject: Re: where are packets created?
Date: Wed, 1 Sep 1999 16:59:10 +0100
Hello.
I'm a bit rusty on this subject, but I assume that your packets are
created in the TCP/IP stack inside the kernel. Where abouts I haven't a
clue. The actual applications only need to know about sending data, not
about how to split it up.
I am guessing that the device driver only handles the hardware layer of
the TCP/IP stack, i.e. how to send the actual data across the wire.
Your packet sizes will be dependent on the protocol in use (TCP/IP) and
the maximum transfer unit (MTU) of the network. I think I am right in
saying that the MTU is the maximum a frame can be, so with the TCP/IP
header (46 bytes?), your packet size would be MTU-46. This is probably
completely wrong, but I think it's the general idea. You do really need to
read up on the subject in a big fat book if you want to understand it
more. Why?
If you want to study packet sizes you could always fiddle with the MTU
value, which would give some sort of indication (or write a program to
send packets of a particular size). That's up to you.
Sorry for being so vague.
- Matthew
On 26 Aug 1999, Yung-Hsiang Lu wrote:
>Hi, Everyone,
>
>Where are network packets created? Is this protocol specific?
>
>When I ftp a large file, is it divided into small pieces (I guess so).
>Is this the responsibility of ftp or the device driver? Is there a
>study about optimal packet sizes? What are the typical packet sizes?
>How about http for a large gif file?
>
>Thanks a lot!
>
>--
> Sincerely,
> Yung-Hsiang Lu
> [EMAIL PROTECTED]
>
>
==================================================================
------------------------------
From: [EMAIL PROTECTED](EdToy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Wed, 1 Sep 1999 14:13:55 -0500
In article <7q46c5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> In comp.os.misc EdToy <[EMAIL PROTECTED]> wrote:
> : In article <7ps2vu$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> : says...
>
> : Leaders _do_. False leaders yap. Have you done anything lately? Come
> : back when you implement anything significant of what you think is "the
> : right way". Until then, stop yapping and do something.
>
> paradoxically, I don't consider myself leading anything. that perhaps
> is the problem, for those followers who demand leaders.
>
> for the impatient & surly ones such as yourself, I am happy to announce
> the tangible progress that I now have a few people on a mailing
> list & some modest initial traffic.
> the mailing list is for dicussion of OS advances, not necessarily
> focused on my own agenda. (I'm sure you won't be impressed. save
> yourself the trouble and avoid telling me so.)
>
> imho.. the OS of tens of thousands of lines of code starts
> with but a few posts. <g>
>
> btw.. "contributers _do_. false contributors yap. have you done
> anything lately? come back when you implement anything significant
> of what you think is "the right way". until then, stop yapping and
> do something.
>
> : If you were
> : attempting "a call to labor", forget it--people have wised up since the
> : Linux/GNU debacle.
>
> huh? what linux/gnu debacle are you referring to?
>
> for all those who are not so impatient and willing to give without
> first demanding (as I have done with the essay)..& further interested
> in Taoist principles applied to software development.. sign up below.
> thanks<g>
You have "give me ideas" and "do the work for me" interjected throuhout
your dialog. You're just trolling for suckers. Get a life.
Ed
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Rockwell PCI Modem?
Date: 1 Sep 1999 19:35:31 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Dr. Peer Griebel <[EMAIL PROTECTED]>]
> I just got a new notebook with an internal Rockwell PCI modem (I
> think the vendor id is 127A, device id is 1005).
There is a reason Rockwell PCI modems are referred to as "Winmodems".
They work only under one or more variants of the Windows brand name.
They are a (not so) rare breed known as HCF modems, which means most
modem-y functions like the AT command set have to be emulated somewhere
in software. While this is feasible to do under Linux (some ISDN
modems are similar) -- unlike another class of Winmodems known as HSP
modems, and are even worse -- Rockwell has never to my knowledge given
anyone a clue as to how to control the device at all.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Graffiti <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 1 Sep 1999 13:43:27 -0700
In article <7qk0ob$[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
[snip]
>: The limitations of sandboxes are also well known; either you make the
>: sandbox too limiting, in which case you can't do anything interesting,
>: or you make the sandbox too big, in which case the virus or other
>: hostile code can do too much damage.
>
>I think this is a false dichotomy. I think when a designer runs into
>this quandary it reflects a lack of imagination & engineering
>ingenuity.
Yup. Therefore, you should always design the OS to be so featureful,
so robust, and so stable that you'll never, ever, have to upgrade or
switch to another OS as long as you live, because you'll be familiar with
all the issues that will ever come up and solve it before people realise
it, right?
Out of curiosity, do you have any idea what you're saying?
>yes, that is exactly what I am proposing: a system in which all
>applications run in a sandbox-- even key elements such as drivers.
>I believe this is not only desirable but inevitable.
So you're basically using a microkernel with each service in its own
server, and each application running in a VM?
>let us agree on this then:
>the problems will not go away unless the sandbox is designed in
>an ingenious way that transcends all prior attempts lacking in
>imagination.
Let's not.
>let us also agree that while such a thing may perhaps be
>difficult to achieve, it certainly is not going to create
>itself.
"Perhaps"?
>for those who wish to participate in its construction, plz
>sign up for the mailing list below.
>
>for those who think it is impossible, remember the quote,
>"the impossible just takes longer"... <g>
And longer, and longer, and longer, and longer, and...
By any chance, are you going to use PASM to write the machine-specific
code for this?
-- DN ( o/~ Hazy Shade of Nudd-ster o/~ )
------------------------------
From: J�rgen Hermanrud Fjeld <[EMAIL PROTECTED]>
Subject: GGI vs. framebuffer
Date: Wed, 1 Sep 1999 22:40:23 +0200
Hi!=20
=20
In order for Linux to be a games platform, hardware acceleration in relat=
ion=20
to graphics is necessary. Having read a little about GGI it seems this=20
architecture will support hardware acceleration for graphics adapters, wh=
ereas=20
the fb architecture apparently won't. Is this correct, and if that is the=
case,=20
why not skip the entire fb project and implement the KGI part of GGI into=
the=20
kernel?=20
=20
sincerely=20
J=F8rgen Hermanrud Fjeld=20
=20
[EMAIL PROTECTED]=20
=20
=20
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Kernel 2.3.15 compilation problem
Date: 1 Sep 1999 20:00:10 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Sagar Gordhan <[EMAIL PROTECTED]>]
> I am trying to compile kernel version 2.3.15 with the linux-atm
> version 0.62 patch applied. The 'make dep' works okay, but the 'make
> zImage' fails.
Are you using an SGI Visual Workstation? Your problem seems to be the
two config options
> # CONFIG_VISWS is not set
> CONFIG_X86_VISWS_APIC=y
Use both or neither -- a kernel for VISWS is not currently compatible
with regular x86 computers.
Also some of your other options don't necessarily make sense either.
These won't necessarily build a bad kernel, but you may wish to be more
specific here:
> CONFIG_M386=y
> CONFIG_X86_TSC=y
> CONFIG_MATH_EMULATION=y
> CONFIG_MTRR=y
> CONFIG_SMP=y
Do you have an SMP system? Which CPU? If it's anything but a 386 or a
486SX you won't need CONFIG_MATH_EMULATION. If it's not at least a
Pentium Pro (or its peers in the clone chips) you won't need
CONFIG_MTRR. Also the 386 and 486 shouldn't really use CONFIG_X86_TSC.
> CONFIG_PCI=y
> # CONFIG_PCI_GOBIOS is not set
> # CONFIG_PCI_GODIRECT is not set
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_MCA=y
Do you have PCI or do you have Micro Channel? I have a hard time
believing you have both.
> CONFIG_VIDEO_DEV=m
Useless without specifying any video/audio capture devices....
> CONFIG_SMD_DISKLABEL=y
> CONFIG_SUN_PARTITION=y
Most people don't need these, though they're harmless.
> CONFIG_SOUND=m
See comment under CONFIG_VIDEO_DEV. HTH.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Peter T. Breuer)
Crossposted-To: comp.security.unix
Subject: Re: PROPOSAL: A secure, simple NIS replacement
Date: 2 Sep 1999 00:31:42 GMT
Reply-To: [EMAIL PROTECTED]
David T. Blake ([EMAIL PROTECTED]) wrote:
: It gets a little more complex than that for various reasons.
: Suppose you administer a network for a large research center
: than has some 500 users some of whom are littered across the
: globe. Then suppose some little twerp IP spoofs your NIS
: server and grabs the password file. What are the odds crack
NIS client, surely?
: will find at least one bad password ? Unless you've been
This is the risk in transmitting passwords outside of your network. Why
do you want to do that? If you want to pass NIS across unconnected
segments, you must take precautions, of course, but those precautions
are not particular to NIS, but to the passing of any info at all through
an external net. I don't see any reason to encrypt NIS in particular,
and every reason to encrypt and authenticate your external communications
in general.
You can pass the password file to local NIS masters via secure channels
(e.g rsync --rsh=ssh every half-hour). - you can even send the thing
encrypted over plain connections. Just modify the makefiles in the
/var/yp directories appropriately. I.e. transmit an encrypted
passwd_byuid.crypt instead of passwd.byuid. Just put iit in the
/var/yp. It'll be broadcast by the server, and served to anybody who
asks for it. And be perfectly useless to all but the intended slave,
who has the decryption key. At the slave end, make sure you decrypt
and put it in passwd.byuid (modify the Makefile, and/or the script
for pwupdate in /usr/lib/yp) and it'll be broadcast by the slave,
locally. Firewall nonlocal accesses.
: So you run crack against your own users, and you find 10
: bad passwords. Unfortunately, 5 of them are in Israel, Sweden,
: and the opposite coast of the US. You lock them out and you are
: fired for obstructing their research (the whole reason your
I'd just change the password, tell them to use ssh, and configure
ssh not to need passwd but to accept only public/private key login, and
share a new key in the users two authorized_keys dirs. I.e you do the
donkey work, and tell the users to�se ssh". They get passwordless login
and full security.
: You desperately need some form of encryption for the research
: center other than hashed password files.
I think you have it.
: --
: Dave Blake
: [EMAIL PROTECTED]
--
Peter
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Linux real-time clock Y2K support
Date: 1 Sep 1999 20:14:58 GMT
In article <[EMAIL PROTECTED]>, Ted Pavlic <[EMAIL PROTECTED]> wrote:
| Does anyone know of an application for Linux that will provide protection
| against real-time clocks that are not Y2K-compliant? I know of a DOS TSR
| that sort of acts like a wrapper around the BIOS, if there is a Y2K issue
| with the RTC, and ends up making corrections where necessary. Is there
| anything like this for Linux?
If you run only Linux, you can hack clock.c (/usr/sbin/clock) to just
arbitrarity knock ten years off the date before setting the clock and
add then on when reading it. Most clocks will work fine because the
kernel has a pivot date of 1950 and adds a century to the year.
There are a few broken CMOS clock chips which will only cover the range
1968 to 2000 (five bit counter) but they were used in the early 80s on
early 386's and hopefully are not running Linux today. Okay, my 1986
GV386-16 is still going strong, but the 1.2.13 kernel isn't Y2k
compliant either, so it's going to retire soon.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
"So let it be written, so let it be dumb." Pharaoh Dufus the last...
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Mouse
Date: 1 Sep 1999 20:03:49 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Milan Hampl <[EMAIL PROTECTED]>]
> Please, excuse me to send my nessage to the wrong group. So I
> installed Red had 6.0 with PS2 mouse, next time HDD device with
> installed system was removed to another (similar) computer. This
> computer has only serial mouse. I am sure that some possibility to
> change it without reinstallation exists, but at linuxconf does
> not.
On Debian, edit /etc/gpm.conf and /etc/X11/XF86Config. I do not use
Red Hat but there should be something similar.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: GGI vs. framebuffer
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 01:45:52 GMT
On Wed, 1 Sep 1999 22:40:23 +0200, J�rgen Hermanrud Fjeld
<[EMAIL PROTECTED]> wrote:
>In order for Linux to be a games platform, hardware acceleration in
>relation to graphics is necessary. Having read a little about GGI it
>seems this architecture will support hardware acceleration for
>graphics adapters, whereas the fb architecture apparently won't. Is
>this correct, and if that is the case, why not skip the entire fb
>project and implement the KGI part of GGI into the kernel?
Framebuffer appears to be straightforward to get running, and thereby
provides a *feasible* way of getting graphics to work on a variety of
platforms.
The notable component that this would support is that of text
consoles...
I don't think anybody much cares whether the graphical support for
consoles is accelerated; any hardware more modern than an 8MHz 68000
will provide quite ample performance for the support of text consoles.
--
All syllogisms have three parts, therefore this is not a syllogism.
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: The optimization debate (was: why not C++?)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 02 Sep 1999 01:45:35 GMT
On 1 Sep 1999 16:25:26 GMT, William Burrow <[EMAIL PROTECTED]> wrote:
>On Wed, 01 Sep 1999 04:19:11 GMT,
>Stephen E. Halpin <[EMAIL PROTECTED]> wrote:
>>On Tue, 31 Aug 1999 02:18:04 GMT, [EMAIL PROTECTED] (Christopher Browne)
>>wrote:
>>>Once optimized once, it's harder to optimize the code again.
>>
>>If this werent true, all processes would converge to O(1),
>>and all data sets would compress to a single bit. Ultimately
>>there is a minimum amount of work that has to be done to
>>perform every task, and you cant optimize a process beyond
>>that minimum. Its not unusual or unexpected for this bound
>>to be approached asymptotically. Outside a particular context,
>>you cant generalize this to imply when any optimization may be
>>made to have the best chance to achieve that minimum, and
>>indeed, poor system design can prevent later optimizations
>>from being effective without redesigning the whole system.
>
>Wow, ten lines that basically repeats what was said in one line. Only
>on USENET. ;)
...And I'm typically the one that gets accused of being
long-winded...
--
Een schip op het strand is een baken in zee.
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
