Debian.org domain

2000-05-03 Thread daniel.de.kok
Hi all,

I was wondering why the HURD project has no domainname. It seems hurd.org is 
registered by someone in Istanbul, is he somebody of the HURD people?!?

Regards,
Daniel De Kok



Re: Debian.org domain

2000-05-03 Thread Kalle Niemitalo
On Wed, May 03, 2000 at 09:11:16AM +0200, [EMAIL PROTECTED] wrote:

 I was wondering why the HURD project has no domainname. It seems
 hurd.org is registered by someone in Istanbul, is he somebody of the
 HURD people?!?

This has been asked before.  See the thread at:
http://www.debian.org/Lists-Archives/debian-hurd-9912/msg00073.html



bcopy

2000-05-03 Thread Tomasz Wegrzanowski
1)
Is there any reason bcopy is used in Hurd sources instead of memcpy ?
(I have quite old sources here)

2)
Is it ok to send patch to change it ?



Re: bcopy

2000-05-03 Thread Marcus Brinkmann
Hi,

On Wed, May 03, 2000 at 03:39:08PM +0200, Tomasz Wegrzanowski wrote:
 1)
 Is there any reason bcopy is used in Hurd sources instead of memcpy ?
 (I have quite old sources here)

Well, I don't know if there is such a reason. Probably Thomas spent too
much time in the BSD sources :)

But let me point out that bcopy is equivalent to memmove, not memcpy
(which doesn't handle overlapping regions).

 2)
 Is it ok to send patch to change it ?

I can't answer that for the core developers, however, is there a particular
reason beside cosmetic? Of course, if you bother to find out where memcpy
is sufficient instead memmove/bcopy, it might be a small performance
advantage.

Thanks,
Marcus

PS: Such mails are slightly more appropriate for bug-hurd@gnu.org, where
development of the Hurd is discussed rather than the binary distribution.

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]



Re: Hurd sources distribution

2000-05-03 Thread Marcus Brinkmann
On Tue, May 02, 2000 at 11:02:29PM +0200, Tomasz Wegrzanowski wrote:
 a)
 Are Hurd sources diffs available somewhere ?

Sorry, my omission. I always try to keep the debian directory uptodate in
CVS, and most of the time the rest is unchanged, so I don't package
upstream/diff, but only as a single tar file.

The very few cases I apply patches I will try to remember to put them
somewhere in debian/. Note that I always mention changes explicitly in the
debian changelog, so if it doesn't mention anything, nothing changed from
CVS.

 b) Why Hurd sources hasn't been splited ?
 b1)
 Linux compiles in half an hour on my machine (under Linux),
 and Hurd hasn't finished in 10 hours (under Hurd). I suppose Hurd
 is *much* more memory-consuming (it's 16MB RAM system), or
 I'm doing something very wrong (most of the time I wasn't looking, so
 I don't know what was happening), but it make playing with Hurd
 quite difficult.

Yes, the Hurd is somewhat bigger, and the fact that there are pic libraries
created as well doesn't make it better. Furthermore, native compilation is
always slower than cross compiling from linux (becuase of the general
slowiness of the hurd).

However, what would a split gain you, except that you have to compile
several packages? Maybe when all hurd libraries have versioned symbols a
split might become useful. This is something that will be decided by the
Hurd core when it becomes interesting.
 
 b2)
 Maximal machine power of Hurd machine is very limited.
 It supports 1 processor, 1GB partitions, probably not much
 of other resources (anyone has real numbers),

What other resources are there you care about?

(If someone has a SMP board, please work on SMP support in GNU Mach!
 If you can't, send the board over to someone who can :)

 and
 compilation should be broken to parts that compiles on
 maximal supported machine in very reasonable time.

 It would be more clear which parts of Hurd changed recently,
 if only these ones changed their version.

I should include all changelogs in the package :)

 b4)
 dpkg was invented to support many little packages,
 huge, multi-functional packages aren't very compatible

Actually, huge packages which contain related stuff are much easier to
handle.

For now, please just accept that it is much more convenient for the
developers to keep the whole hurd source in single tree, although it might
this is not the Most Perfect Thing To Everyone.

There is a technical reason, too: The Hurd libraries don't carry versioned
symbols (actually, the latest libthreads does), and the soname is not kept
uptodate in CVS, so you might get obscure problems if you update only parts
of the Hurd and are not careful about it. With split packages, I would end
up to spent most of the packaging time in figuring out the correct
dependencies, and might still fail. This is not a workable solution.

Remember that we are working with development snapshots, as opposed to
released version.

A tip: Keep the build tree around. When updating the source code, the
Makefiles will only build the changed object files, resulting in a much
shorter build time.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]



re: Re: URLs for new developers 20000418

2000-05-03 Thread jfranklin
Hi Jeff,
  Probably best if you handle it for now.  I'm pretty well swamped at work and 
it may be a 
month or two before I come up for air again.  If you could get me write access 
that would be 
great but I will be unable to do anything for awhile.  I am registered as a 
developer at 
sourceforge.net under the handle cykick.  If you could send me some info how to 
register 
myself with the hurddocs project at sourceforge.net I'll go ahead and do that.  
Talk to ya 
later.

Jim


 ** Original Subject: Re: URLs for new developers 2418
 ** Original Sender: Jeff Bailey [EMAIL PROTECTED]
 ** Original Date: Wed, 3 May 2000 07:46:11 -0700

 ** Original Message follows... 


 On Tue, Apr 18, 2000 at 09:40:04AM -0700, Jim Franklin wrote:
 
 Can I get your latest snapshot of this to post on hurddocs?  I'd like to
 call it Development-HOWTO, and have this under a getting started section.
 
 If yes, would you just like me to copy in update, or would you like 
 write access to the document?
 
 Thanks, Jim!
 
  http://www.gnu.org/software/hurd/hurd.html
  http://www.debian.org/ports/hurd/
  http://www.gnu.org/software/devel.html
  http://www.debian.org/Lists-Archives/
  http://www.debian.org/ports/hurd/hurd-install
  http://www.gnu.org/software/hurd/learning-more-about-hurd.html
  http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/publications.html
  http://kt.linuxcare.com/KC/debian-hurd/index.html
  http://www.tamacom.com/tour/hurd/index.html
  http://www.pick.ucam.org/~mcv21/hurd.html
  OSKit:
  http://www.cs.utah.edu/flux/
  
  Mach:
  http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
  http://www.cs.cmu.edu:/afs/cs/project/mach/public/www/doc/books.html
  
  Grub:
  http://www.gnu.org/software/grub/
  
  General OS Books:
  ftp://ftp.cse.ucsc.edu/pub/comp.os.research/93/93-03-14-17-09.47.gz
  
  comp.os.research FAQ:
  http://www.best.com/~bos/os-faq/FAQ-1.html
  
  
  I think Jeff Bailey at hurd.zugzug.com was looking for some help
  documenting and I think it was Bill White  (I may be wrong) who was also
  doing some documentation.
  
  If anyone has any additional info urls please post them with a reply and
  I'll incorporate them in the next URLs for new developers.
  
  Have fun and welcome to the hurd
  Jim
 
 -- 
 There is no sin except stupidity.
  - Oscar Wilde


** - End Original Message --- **

 





Major GNU/Hurd using report

2000-05-03 Thread Tomasz Wegrzanowski
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 ones affected
And no, much more are affected
Here's CMOS reporting program

--- start ---
#include mach/machine/pio.h

int main() {
int i,j;
printf (CMOS content report\n\n);
for (i=0;i0x40;i++) {
  outb (0x70,i);
  j=inb (0x71);
  printf (Cell $%d(0x%x) = %d\n,i,i,j);
}
printf (End of Report\n);
return 0;
}
--- end ---

outb is:

#define outb(port, val) \
({ asm volatile(outb %0, %1 : : a ((unsigned char)(val)) , d ((unsigned 
short)(port))); })

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
- Mach gives default permision to every program to use all hardware ports
  No test was done yet

3)
I have problems with networking
There is no eth, only loopback should be used

telnet doesn't work

tail of syslog - last two days (there was more than 1 run/day) :
--- start ---
May  2 12:40:41 localhost syslogd: restart
May  2 12:40:41 localhost inetd[29]: ftp/tcp: socket: Translator died
May  2 12:40:41 localhost inetd[29]: finger/tcp: socket: Translator died
May  2 12:40:41 localhost inetd[29]: telnet/tcp: socket: Translator died
May  2 12:40:41 localhost inetd[29]: shell/tcp: socket: Translator died
May  2 12:40:42 localhost inetd[29]: login/tcp: socket: Translator died
May  2 12:40:42 localhost inetd[29]: exec/tcp: socket: Translator died
May  2 12:40:42 localhost inetd[29]: ident/tcp: socket: Translator died
May  2 12:40:42 localhost inetd[29]: smtp/tcp: socket: Translator died
May  3 19:04:21 localhost syslogd: restart
May  3 19:04:20 localhost inetd[29]: ftp/tcp: socket: Translator died
May  3 19:04:21 localhost inetd[29]: finger/tcp: socket: Translator died
May  3 19:04:21 localhost inetd[29]: telnet/tcp: socket: Translator died
May  3 19:04:21 localhost inetd[29]: shell/tcp: socket: Translator died
May  3 19:04:21 localhost inetd[29]: login/tcp: socket: Translator died
May  3 19:04:21 localhost inetd[29]: exec/tcp: socket: Translator died
May  3 19:04:21 localhost inetd[29]: ident/tcp: socket: Translator died
May  3 19:04:21 localhost inetd[29]: smtp/tcp: socket: Translator died
--- end ---

Every time I `ls -l /servers/socket'
It prints :
`2 - translator died'
(then normal list)

mc says : `file 2 exists but can't be stated'

showtrans says /servers/socket/2 is /hurd/pfinet -i=rfsd

4)
Is there any fatfs translator ?



Re: Major GNU/Hurd using report

2000-05-03 Thread Marcus Brinkmann
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=rfsd

What shall rfsd be? If this option is not recognised, the translator will
die. Try with 

/hurd/pfinet -i rfsd

at the command line and see if it complains. Try without this option.

settrans /servers/socket/2 /hurd/pfinet
 
 4)
 Is there any fatfs translator ?

I am currently writing one! It can already list the root directory and stat
some files, however, it is hopelessly buggy and no files can be read (I/O
error). However, I did only work for a couple of hours on it, so there is
hope.

I will make the source public in a couple of days, so people can join me.
(Need to clear it up before this, and attach proper copyright notices).

I only aim at read-only without long file names. Long file names might
follow, but I will not be able to implement write support in the near
future. However, FAT12/16/32 will be supported.

Thanks,
Marcus

--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann  GNUhttp://www.gnu.orgfor public PGP Key 
[EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   [EMAIL PROTECTED]



gcc3 evaluation platforms

2000-05-03 Thread Matthias Klose
gcc currently defines release criteria for gcc3. See
http://gcc.gnu.org/gcc-3.0/criteria.html. For ix86 Debian is proposed
as primary evaluation platform. For sparc and alpha, Ben Collins and
Chris Chimelis volunteer to evaluate gcc3. Currently we do not have
feedback from the other architectures (besides ix86). Please have a
look at the debian-toolchain archive for the past discussions, if you
consider to evaluate gcc3 for your platform.