Linux-Development-Sys Digest #948, Volume #6 Sat, 10 Jul 99 23:13:52 EDT
Contents:
Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36 (Christopher B.
Browne)
Re: MICROSOFT LINUX DISTRIBUTION (Christopher B. Browne)
Re: "DbgPrint" in Linux? (Michael Meissner)
Re: egcs weaknesses (was idiocy but let's be civil) (Andy Leighton)
[EMAIL PROTECTED] 22000
([EMAIL PROTECTED])
Re: CD-ROM File Time Bug ("Charles Sullivan")
Lucent PCI interface w/16550A problem ([EMAIL PROTECTED])
suse 6.0 + gdb "steps" into ALL functions ("someone")
when will Linux support > 2GB file size??? ([EMAIL PROTECTED])
how to "mount" a distribution ? (Rafael The X-Slasher)
Re: MICROSOFT LINUX DISTRIBUTION (Jim Robertson)
Re: Memory swapper abstraction (RFD) (Sean Walton)
Re: when will Linux support > 2GB file size??? (Byron A Jeff)
Re: when will Linux support > 2GB file size??? (Christopher B. Browne)
Re: MICROSOFT LINUX DISTRIBUTION (Joe Pfeiffer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Filesize larger than 2 GB on Intel machines an Linux 2.0.36
Reply-To: [EMAIL PROTECTED]
Date: Sat, 10 Jul 1999 18:53:52 GMT
On 10 Jul 1999 13:13:15 -0400, Byron A Jeff <[EMAIL PROTECTED]> posted:
>In article <tVRg3.10785$[EMAIL PROTECTED]>,
>Christopher Browne <[EMAIL PROTECTED]> wrote:
>-On 07 Jul 1999 21:50:05 +0200, Andreas Jaeger <[EMAIL PROTECTED]> wrote:
>->>>>>> Christopher B Browne writes:
>->Christopher> The *killer* part isn't a kernel patch; it's the (probably nonexistent
>->Christopher> at this point) GLIBC patch that is needed to support big files.
>->
>->glibc 2.1 has the full LFS interface. It just needs (on ix86) kernel
>->support and some changes. But you can already
>-
>-I stand corrected, and am glad to see such developments in 2.1; this
>-nonetheless leaves the issue that applications must be coded to use
>-LFS.
>
>But since it's such a small subset of applications anyway, this shouldn't be
>a big deal right?
This represents one of the "Enterprise Computing" requirements; as such,
while the incidence of need may be relatively small, those represent
situations invoving expensive/important boxes, which makes it important
out of proportion to the apparent number of boxes.
--
"The problem with the current Lisp Machine system is that nothing ever calls
anything anymore." -- KMP
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Reply-To: [EMAIL PROTECTED]
Date: Sat, 10 Jul 1999 19:44:02 GMT
On Sat, 10 Jul 1999 13:56:49 -0400, John Jacques <[EMAIL PROTECTED]> posted:
>Samuel Brown wrote:
>
>> I had a someone tell me that Microsoft will sell their own linux
>> distribution. Is this true?
>>
>> They said it would have IE 5 and EXPLORER as the window manager
>> and the setup program would be really simple.
>> It will have word and excel 2000 also.
>> Are they taking over LINUX?
>
>Isn't Netware buying out debian linux? I have a linux magazine, (I have
>to find where I placed it), that said Netware cannot depend on M$ (runs
>on top of dos) anymore after this year and is converting their OS to
>work with linux ( I think it said debian?). If this is happening why
>can't M$ buy out a version of linux and do the same thing Netware is
>doing with it?
Netware is a product, so it can't "buy out" anything. You might instead
be thinking about Novell, makers of Netware.
Further fallacies:
- Novell's Netware product provides its own operating system. It does not
need MS-DOS or Linux or anything else in order to function.
- Debian Linux is not a commercial distribution, and thus there is
inherently no way for it to be "bought out."
>Also, the world thinks M$ is the greatest computer people in the world,
>so, what is stopping them from looking at all the various linux sources
>and create a whole new version for themselves. They can say they created
>the whole thing, after all they created dos and windows.
In theory they could do so; there would be some significant costs, not least
of which being the non-tangible cost of essentially admitting that Windows has
failed against Linux. (Explaining the precise meaning of that would be several
pages that I don't feel like writing.)
--
Smith's Test for Artificial Life:
When animal-rights activists and right-to-life protesters are marching outside
your laboratory, then you know you've definitely made progress in your
artificial life research.
-- Donald A. Smith
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
Subject: Re: "DbgPrint" in Linux?
From: Michael Meissner <[EMAIL PROTECTED]>
Date: 10 Jul 1999 15:58:34 -0400
[EMAIL PROTECTED] (Yung-Hsiang Lu) writes:
> Is there anything like Windows NT "DbgPrint" in Linux? It allows
> programmers to print debugging information through a serial cable to
> another computer.
For syslog messages it is simple enough to edit your /etc/syslog.conf file, and
add a line of the form:
# Log everything to ttyS0
*.info /dev/ttyS0
I personally syslog to write messages to /dev/tty6, and then tell inittab not
to spawn a tty on /dev/tty6 (via removing the line in /etc/inittab). That way
I can see the log messages whenever I want by doing control-alt-F6.
For programs, you can write your own syslog messages, or even just write to
stderr, and when starting the program redirect stderr to the serial line.
--
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: [EMAIL PROTECTED] phone: 978-486-9304 fax: 978-692-4482
------------------------------
From: [EMAIL PROTECTED] (Andy Leighton)
Subject: Re: egcs weaknesses (was idiocy but let's be civil)
Date: 9 Jul 1999 20:27:42 GMT
Reply-To: [EMAIL PROTECTED]
On 9 Jul 1999 03:53:28 -0500, Peter Samuelson <[EMAIL PROTECTED]> wrote:
>[Ian Hutchinson <[EMAIL PROTECTED]>]
>> I was depressed by this thread because people seem to be admitting
>> out of the box that egcs produces bigger and slower code than gcc.
>
>You mean "bigger and faster". If small code is important, obviously
>you have to use "-Os".
>
>> I am left with only one possible advantage of egcs versus gcc and
>> that is the integration of g77. All of the other areas sound like
>> losses.
>>
>> Can someone point out some of the benefits I should be getting?
>
>As mentioned already, "C++ that works".
Although not quite there yet.
egcs still doesn't support the entire standard c++ library
however the egcs people are working on it.
--
Andy Leighton => [EMAIL PROTECTED]
"... January is your third most common month for madness" - _Sarah Canary_
------------------------------
From: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED] 22000
Date: Monday, 05 Jul 1999 00:23:47 -0600
Reply-To: [EMAIL PROTECTED]
FREE Email You can Check from any computer connected to the web !
You don't have to be, [EMAIL PROTECTED]
IMAGINE,,,,,,[EMAIL PROTECTED]
SUPER EASY to Remember......
Get [EMAIL PROTECTED]
http://www.MyPersonalEmail.com
Tell a Friend
a)_/NbNJ
------------------------------
From: "Charles Sullivan" <[EMAIL PROTECTED]>
Subject: Re: CD-ROM File Time Bug
Date: Sat, 10 Jul 1999 17:10:32 -0400
Can someone explain what's going on here? Under MS-DOS (Win 98) I copied
two files from a CD to my hard drive, to a floppy disk, and to a ZIP disk.
One file
has a create date in January, the other in July.
I am in the Eastern US time zone. My system clock is presently set to
today's
date (10 July 1999) and time, which is Eastern Daylight Time.
If I boot up into Linux (RH 6.0) and run 'ls -l --full-time ' for each of
the media,
here's what I get for the time. (This is the hour only; min:sec are
identical for
each media and the DOS times were converted to 24 hour time.)
File MS-DOS Linux=> CDROM HDD Floppy ZIP
====== ============= ============ ======= =======
-- ----
Jan 22 17 21 21
21
July 12 8 12 12
12
If I type 'date', Linux responds with the correct date and time, denoted
"EDT".
If I reset my hardware clock to a date in January and reboot Linux, the
'date'
command reports the date I have set, denoted 'EST'. But the file times in
the
various media reported by ls are identical to those shown above.
The difference between UTC and EST is 5 hours; between UTC and EDT is 4
hours.
It looks like Linux is assuming that the CD file are UTC and is figuring
that out
from the DOS date (assumed to be Eastern time). Is this correct?
I don't understand why the difference of one hour in the January file on
the other media. If Linux is reporting the time in my current TZ, then it
ought to
change when I reset my clock to EST.
Any ideas, or is this a bug?
Regards,
Charles Sullivan [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Lucent PCI interface w/16550A problem
Date: Sat, 10 Jul 1999 22:28:10 GMT
The card gets into a state where the modem will
not respond, maybe happens 1 percent of the time.
This is just after the PCI code in the kernel is run.
/proc/pci indicates proper device, etc.
Can I reset some state on the card or what?
Any ideas would be helpful.
------------------------------
From: "someone" <[EMAIL PROTECTED]>
Subject: suse 6.0 + gdb "steps" into ALL functions
Date: 10 Jul 1999 23:27:07 GMT
Hi there,
Till SuSE version 5.3, It was OK for me to use gdb to debug my progs.
But with version 6.0, 'gdb' insists to "step" into functions I didn't write
(printf, read, write...).
How can I prevent GDB to enter those functions ?
Note : I didn't change any args to gcc or in the Makefile between vers.5.3
and 6.0
As I use threaded progs, GDB always stops on signal SIGUSR1 after the
"pthread_create" call. Will solutions for previous problem cure this
ennoying fact too ?
Thanks a lot...
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy
Subject: when will Linux support > 2GB file size???
Date: 10 Jul 1999 16:11:03 -0700
hello every one.
I am using Linux 2.2 kernel. and I see that it still does not support
creating a file > 2GB in size.
Any one knows when Linux might support real large file sizes?
may be in Linux 2.3 ?
thanks,
Mk.
------------------------------
From: Rafael The X-Slasher <[EMAIL PROTECTED]>
Subject: how to "mount" a distribution ?
Date: Sat, 10 Jul 1999 23:54:32 GMT
Anyone knpws any howto/document/tutorial on how to "mount"/create a
linux distribution ?
--
Rafael "The X-Slasher" Pereira
ICQ# 12758282
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Jim Robertson <[EMAIL PROTECTED]>
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: Sat, 10 Jul 1999 22:36:58 GMT
If Novell were to start shipping Linux, it would probably be Caldera. The
Caldera folks are geographically close to them up there in Utah, and I beleive
that there has been some personnel swappage between the two companies. Caldera's
Open Desktop ships with IPX support (the Netware protocol)
And Caldera bought the IP rights to DR DOS from Novell, who used to own them.
John Jacques wrote:
>
> Isn't Netware buying out debian linux? I have a linux magazine, (I have
> to find where I placed it), that said Netware cannot depend on M$ (runs
> on top of dos) anymore after this year and is converting their OS to
...
-- JRob
Sig virus: copy me into your ~/.sig now!
------------------------------
From: Sean Walton <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Memory swapper abstraction (RFD)
Date: Sat, 10 Jul 1999 20:39:33 -0400
Where do I find info? Is it being done in Linux?
-Sean
Kaz Kylheku wrote:
> On Sat, 10 Jul 1999 12:58:23 -0400, Sean Walton <[EMAIL PROTECTED]>
> wrote:
> >[Let's see if I can this posting to stick (I keep getting my messages
> >dropped!).]
> >
> >I have an idea that may be interesting to distributed programmers. How
> >about an abstract memory swapper. Currently, Linux swaps on a local
> >disk or on a remote server (with dedicated swap space). If we were to
> >allow processes to chose where they will swap certain blocks, these
> >blocks may be placed remotely and even shared. The locking/scheduling
> >would simply be an "I got it!" algorithm. Several programs (locally or
> >remotely) can share the same block and pass it around like a hot
> >potato. Additionally, programs may themselves migrate to other, less
> >utilized nodes (assuming the context goes with it).
>
> What you are describing is known as Distributed Shared Memory.
> You might want to brush up on the existing research concerning DSM.
------------------------------
From: [EMAIL PROTECTED] (Byron A Jeff)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 10 Jul 1999 21:10:21 -0400
In article <7m8ju7$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>hello every one.
>
>I am using Linux 2.2 kernel. and I see that it still does not support
>creating a file > 2GB in size.
>
>Any one knows when Linux might support real large file sizes?
>may be in Linux 2.3 ?
If only the kernel needed to be changed to support this, then it would have
been done long ago. There are at least 4 levels of change required:
1) An actual filesystem representation change. The structure of the filesystem
must support large file sizes.
2) Changes in the filesystem code of the kernel to support the changes in (1)
3) Changes and/or additions to the C library to interface to the changes
in (2)
4) Changes/recompilation or additions to applications to support 3.
The biggest problem is that all these changes will probably break a whole
bunch of existing code. The second biggest problem is the fact that only
a very very small percentages of applications require such functionality.
There are few current solutions to look at:
1) True 64 bit support is available for 64 bit machines such as the alpha. All
of the changes required have already been made in the kernel, library, and
applications to support large files.
2) While it's true that no single file in ext2 can be larger than 2GB, that's
not true of the filesystem itself which can extend up to three orders of
magnitude bigger (2TB or larger). Frankly it wouldn't take a whole lot of
work to extend or build an application interface that presents a single large
file to the application and map it into multiple files each less than 2GB
to the filesystem. Then the application can in fact utilize the difference
between the size of a single file and the size of the entire filesystem to
get the required result.
3) You have access to the raw partition and all the C and C++ libraries have
an interface for 64 bit seeks (llseek). So you could in fact write your own
rudimentary filesystem to support your needs.
Simply put most apps don't need 2GB+ files. ext2 and the current library has
hooks to that you can do your own. I have a fear that integrating 64 bit
support into 32 machines may in fact destabilize the filesystem and the
applications that use it.
And lastly the Glib2.1 library has support for 64 bit files. It's now a
matter of getting sufficient kernel and application support to make it go.
So BTW why exactly do you need 2GB+ files?
BAJ
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jul 1999 01:31:04 GMT
On 10 Jul 1999 16:11:03 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
posted:
>I am using Linux 2.2 kernel. and I see that it still does not support
>creating a file > 2GB in size.
>
>Any one knows when Linux might support real large file sizes?
>may be in Linux 2.3 ?
The critical issue for support of >2GB file sizes is for the "generic"
file descriptor structure used to handle opened files (e.g. "FILE *) to be
switched over to the "big" form for the purposes of:
a) Kernel
b) LIBC
c) Applications using LIBC.
In looking at kernel sources for 2.2.8, in /usr/src/linux/fs/ext2/inode.c,
it indeed appears that the default is to treat 64 bits as a 64 bit
architecture thing. I hear there's a patch to change that; I suspect this
affects rather more than one bit of code...
GLIBC 2.1 now supports large files with a "force-to-64-bits" API; see
/usr/include/glob.h and /usr/include/bits/stat.h. That should allow it to
support 64 bit sizes in the kernel, once such a kernel option is deemed
"kosher."
That nonetheless requires that applications be recompiled or (worse still)
modified to be aware of the 64 bit API. After all, if a program has been
compiled with a "traditional" FILE struct, it thinks the structure is of a
different size. That wouldn't be so big a deal if it were *known* LIBC
always manages allocation/deallocation of the structure, but if the program
*ever* manipulates file descriptors directly, the "leave it to LIBC"
assumption breaks very badly...
All three "components" need to be handled in order for this to work well for
applications. The kernel portion is probably the easy part. GLIBC efforts
seem to be under way.
If you want support today, get a CPU with a 64 bit architecture. Big files
are already supported there *today.*
I expect that when the time comes to "go 64 bit," there will be *loud*
trumpeting of much testing and breakage of code on the 'net.
I suspect that the "64 bit support on 32 bit architectures" thing will not
happen quickly or soon. IA-64 should come out fairly soon, which will add
up to *several* 64 bit architectures that should be suitable for those that
really need big files. And that availability should diminish the urgency of
"fixing" the problem on IA-32.
--
"Not me, guy. I read the Bash man page each day like a Jehovah's Witness
reads the Bible. No wait, the Bash man page IS the bible. Excuse me..."
(More on confusing aliases, taken from comp.os.linux.misc)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: Re: MICROSOFT LINUX DISTRIBUTION
Date: 10 Jul 1999 19:39:00 -0600
Bryan <Bryan@[EMAIL PROTECTED]> writes:
>
> but won't they have to release source if they modify a GPL'd product?
Only if they get sued for releasing it as a binary-only.
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
------------------------------
** 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
******************************
