Linux-Development-Sys Digest #537

2001-03-03 Thread Digestifier

Linux-Development-Sys Digest #537, Volume #8  Sat, 3 Mar 01 05:13:17 EST

Contents:
  Re: Strange 2.4.2 boot error (Michael Mueller)
  Developer Panel Invitation ("Resarch")
  Re: Can linux be trusted? (Chas2K)
  Re: Can linux be trusted? (Paul D. Boyle)
  Re: generic_file_write() --> block allocation (Alexander Viro)
  Re: Can linux be trusted? (James Richard Tyrer)
  Re: Can linux be trusted? (Willam Hughes)
  Any WMA decoder in linux so far? ("Astroboy")
  Re: Transparent versioning for Win clients? ("Darin Many")
  Re: Any WMA decoder in linux so far? (Erik de Castro Lopo)
  Re: http loopback taking 14 minutes (David Efflandt)
  Re: cant get the login screen... (Kasper Dupont)



From: [EMAIL PROTECTED] (Michael Mueller)
Crossposted-To: leviathan.lkml
Subject: Re: Strange 2.4.2 boot error
Date: Fri, 02 Mar 2001 23:32:17 +0100

Hi folks and D. Stimits,

Summary of discussion taken place so far (for linux-kernel people):

D. Stimits noticed he can not boot his kernel from a 1.44MB floppy
created with "make bzdisk". This would lead into a register dump. The
dump does show the boot code tries to read track 80 of the disk.

However mkbootdisk as delivered with a pre-release of the RedHat 7.1
distribution can be used to create a working boot disk using the bzImage
generated by above.

My last question to D. Stimits was:
> > How large is the file ./arch/i386/boot/bzImage?

And he answered
> 1040155 Feb 24 23:28 bzImage
>
> Definitely within 1.44 Mb floppy size.

I see following problem with the bootsector code for bzImage:

Within bootsector the size of the kernel is stored as number of 16 byte
blocks. This gives a number of 0xfdf2 in this case.

Now while loading the kernel the bootsector code calls a helper routine
(in setup[.S]) which does copy 64kByte if available and does nothing
else. This routine does the return the number of 16 byte blocks read.
This number then is a multiple of 1000h. 

So no when a kernel of above size is completely loaded the count of the
16 byte blocks returned by the helper routine wents from f000h into
h due to the 16 bit size of the register ax used. The bootsector
code does then compare h to fdf2h and it is less, so it does
continue loading until it does reach the end of the disk and fails with
a read error.


Malware
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



--

From: "Resarch" <[EMAIL PROTECTED]>
Subject: Developer Panel Invitation
Date: 03 Mar 2001 00:09:03 GMT

Dear Software Developer,
EDC is an independent market research firm specializing in software
development.  We're recruiting developers to complete a survey  and so join
our international panel of developers and enter a drawing to win $500US
CASH.  You can find this survey at:

http://www.evansdata.com/Surveystart.html

Our reports are read by most of the largest development tool companies and
this is your chance to influence them so they can make the tools and
programs YOU want.

Panel members are alerted via e-mail about once a month when we run a survey
and may choose to participate or not.  Everyone who does complete a survey
is automatically entered in a drawing to WIN $500US CASH.

Our surveys are not sponsored by any one company, and all personal
information is held strictly confidential.  The results are aggregated and
turned into reports which influence top development tools companies.  YOUR
PERSONAL INFORMATION IS NEVER GIVEN TO ANYONE UNDER ANY CIRCUMSTANCES.

To take our survey and enter the drawing please go to:

http://www.evansdata.com/Surveystart.html

 We think you'll find it interesting!

The Research Team at Evans Data Corp
http://www.evansdata.com/Surveystart.html



--

From: Chas2K <[EMAIL PROTECTED]>
Crossposted-To: 
comp.lang.c,comp.os.linux.development.apps,comp.sys.mac.programmer.misc,comp.unix.bsd.freebsd.misc,comp.unix.bsd.misc,gnu.gcc,linux.dev.gcc
Subject: Re: Can linux be trusted?
Date: Fri, 02 Mar 2001 19:56:40 -0500
Reply-To: [EMAIL PROTECTED]

Johan Kullstam wrote:
> 
> "John Smith" <[EMAIL PROTECTED]> writes:
> 
> > "
> > If you've got a minute, and one of those 'bleeding edge' OSes, try compiling
> > with no optimizations and running this for fun:
> >
> > int main(void)
> > {
> > int a = 60, b = 6, c = 10;
> >
> > printf("%d = %d\n", (int) (((60/6)*0.3) + (10*0.7)), (int) ((( a/b)*0.3) +
> > ( c*0.7)));
> >
> > exit(1);
> > }
> >
> > (BTW the lameness filter defies logic, that was the best I could do 

Linux-Development-Sys Digest #537

1999-03-26 Thread Digestifier

Linux-Development-Sys Digest #537, Volume #6 Fri, 26 Mar 99 20:14:16 EST

Contents:
  Re: How do I run a program ? ("Sridhar Sathya")
  Re: ANNOUNCE: Linux Router ( 3 1/2 " size hardware) (Phil Howard)
  Re: how to load ram disk from LILO? (Phil Howard)
  USENIX Annual Conference, June 6-11,  Monterey CA (Jennifer Radtke)
  Re: ISP Hookup, doesn't work ?? (Phil Howard)
  Re: Devloping Linux apps on NT? ("G. Sumner Hayes")
  Re: How do I run a program ? (Alexander Viro)
  Re: adding a user (note to the t.b guys: this really fits the group) (Emile van 
bergen)
  Re: adding a user (NF Stevens)



From: "Sridhar Sathya" <[EMAIL PROTECTED]>
Subject: Re: How do I run a program ?
Date: Fri, 26 Mar 1999 18:50:12 EST

You may have to change your path.
Try this:
at the command prompt type this (assuming that you are ksh or bash as your
shell).
export PATH=./:$PATH (and then press enter to execute program)
greeting
Wow your program runs.

The Bits <[EMAIL PROTECTED]> wrote in message
news:7d0ft2$r1d$[EMAIL PROTECTED]...
> Yes, yes, you've guessed it - I'm new to Linux. Can someone please tell me
> why my compiled program isn't running.
>
> Here's what I'm doing at the moment :
>
> 1/ Create program in VIM and save as : greeting.c
> 2/ At command line I'm entering :
>
> gcc -o greeting greeting.c
>
> 3/ I type :
>
> greeting (and then press enter to execute program)
>
> Please can someone tell me what I'm doing wrong?
>
> 'We all have to start somewhere'
>
> You can e-mail me at [EMAIL PROTECTED]
>
>
>



--

From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: ANNOUNCE: Linux Router ( 3 1/2 " size hardware)
Date: Fri, 26 Mar 1999 23:47:24 GMT

On Thu, 25 Mar 1999 00:29:38 GMT Christopher Browne ([EMAIL PROTECTED]) wrote:

| This would be useful stuff for building little set-top boxes.
|
| NIC+Motherboard+CPU+FlashDisk+Video gives you a machine that can boot
| and run; if you keep the local storage to a minimum that encourages data
| storage on server, this is a pretty slick configuration. 

I remember back in the very early 1990's when X terminals were popular
(for use with the "big UNIX mainframe") and I had one of these beasts.
They had to get fonts from a font server on the mainframe, too, and I
noticed that this was slowing them down mostly due to network loading.
When I asked why this was not something that was built into the ROM in
the box, it was pointed out that the font data would be very large in
the many megabytes (and now days is even larger).  So what I tought at
the time would have been an interesting solution would have been to put
all the fonts on a CD.

So at this point we're looking at FlashDisk technology vs CDROMs.  But
the two can actually work together for many purposes.  The FlashDisk
would be great for single machine configurations and 20 meg would usually
be plenty for that.  A file server would hold all the data.  And programs
and libraries could then be on the a server and/or the CD (as a desktop,
you might want a 2nd CDROM drive if the first is system mounted)

--
Phil Howard   KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]

--

From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: how to load ram disk from LILO?
Date: Sat, 27 Mar 1999 00:22:15 GMT

On 24 Mar 1999 17:21:00 -0800 david parsons ([EMAIL PROTECTED]) wrote:

| In article <%FxG2.294$[EMAIL PROTECTED]>,
| Phil Howard <[EMAIL PROTECTED]> wrote:
| >This seems to be mentioned in the initrd document, but not actually said
| >in the lilo document.  How do you specify the ram disk image to be loaded
| >by LILO at boot time?
|
|   For me, I 
|   1) Build the kernel with ramdisk and initrd support, of course.
|   2) On the ramdisk image (the floppy), /etc/lilo.conf has
|
|   install = /boot/boot.b
|   vga = normal
|   initrd = /dev/fd
|   ramdisk = 1440  # keep your laser handy
|   root = /dev/ram # major 1, minor 0
|   append = " ramdisk_start=0 prompt_ramdisk=0 load_ramdisk=1"
|
|   image = /boot/BASIC
|   label = INSTALLER
|
| I DON'T do any of the dicking around with an initrd;  I'm only doing
| the initrd tweakery that I need to get my grubbies on the preloaded
| ramdisk.

Apparently there are two ways to load initial ramdisk.  One is that the
kernel does the loading itself based on the starting sector number, which
can be on the initial arguments string, or maybe just stuffed into the right
binary offset like some of the other parameters such as video mode and root
device are done.  The other is that the boot loader gets the image and
through some interface I have not yet disco