On Fri, May 05, 2000 at 10:52:35AM +0200, Marcus Brinkmann wrote:
> On Fri, 05 May 2000 02:45:50 Colin Watson wrote:
> > And, as a side note, I understand that the reason this is there by
> > default is that the hurd-i386 architecture is using the same source for
> > the base-files packages as othe
On Fri, 05 May 2000 02:45:50 Colin Watson wrote:
> Kalle Olavi Niemitalo <[EMAIL PROTECTED]> wrote:
> >Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
> >> 5)
> >> `which' and `type' don't work correctly
> >> They shows all commands to be /usr/bin/*,
> >> what is wrong, althru will work.
> >
> >Tak
On Thu, 04 May 2000 17:30:51 Tomasz Wegrzanowski wrote:
> > > 4)
> > > Is there any fatfs translator ?
> >
> > I am currently writing one!
>
> I volunteer to test it.
Great. I hope to release it tonight. I got it working for FAT12 so far,
and if I didn't
do a stupid mistake, it should work on a
Kalle Olavi Niemitalo <[EMAIL PROTECTED]> wrote:
>Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
>> 5)
>> `which' and `type' don't work correctly
>> They shows all commands to be /usr/bin/*,
>> what is wrong, althru will work.
>
>Take /usr/bin off your $PATH then.
And, as a side note, I understan
On Thu, May 04, 2000 at 08:55:50PM +0300, Kalle Olavi Niemitalo wrote:
> Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
>
> > KGI is quite portable (some parts needs to be non-preemptive, possible on
> > Mach ?)
>
> Why does it require that -- does it work on multiprocessors at
> all?
It was s
Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
> KGI is quite portable (some parts needs to be non-preemptive, possible on
> Mach ?)
Why does it require that -- does it work on multiprocessors at
all?
> I'm not going to try compiling gnumach in *near* term.
> I had enough bad experience with L
Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
> 5)
> `which' and `type' don't work correctly
> They shows all commands to be /usr/bin/*,
> what is wrong, althru will work.
Take /usr/bin off your $PATH then.
On Wed, May 03, 2000 at 09:54:31PM +0200, Marcus Brinkmann wrote:
> On Wed, May 03, 2000 at 08:35:19PM +0200, Tomasz Wegrzanowski wrote:
> >
> > but why does bash need `mesg' ?
>
> It's part of your login script (/root/.profile)
Thanks, it worked
> > 3)
> > I have problems with networking
> > T
On Thu, May 04, 2000 at 01:39:50PM +0300, Kalle Olavi Niemitalo wrote:
> Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
>
> > Therefore there are these possibile reasons, why it is possible to r/w
> > hardware ports :
> > - I/O Permision Level is way too low
> > but asm(pushfl) says IOPL=0 (ke
Tomasz Wegrzanowski <[EMAIL PROTECTED]> writes:
> Therefore there are these possibile reasons, why it is possible to r/w
> hardware ports :
> - I/O Permision Level is way too low
> but asm(pushfl) says IOPL=0 (kernel only)
> - user programs run in kernel space
> I hope not, no test was done
On Wed, May 03, 2000 at 08:35:19PM +0200, Tomasz Wegrzanowski wrote:
>
> but why does bash need `mesg' ?
It's part of your login script (/root/.profile)
> 3)
> I have problems with networking
> There is no eth, only loopback should be used
> showtrans says /servers/socket/2 is /hurd/pfinet -i=
1)
bash protests that it can't find `mesg' program when I log in
bash is of course right, because there is no `mesg' installed,
and `mesg' is part of sysvinit, so it's corrrect it's not installed
but why does bash need `mesg' ?
2)
Famous I/O problem
I tried to check if VGA registers are the only
12 matches
Mail list logo
