Linux-Development-Sys Digest #646, Volume #7 Thu, 2 Mar 00 21:13:13 EST
Contents:
Re: Absolute failure of Linux dead ahead? (Grant Edwards)
Re: clone() and shared library heap allocations ("Frank V. Castellucci")
Moving our product line to Linux ("Edward Balassanian")
Re: Absolute failure of Linux dead ahead? (Mark Robinson)
Re: Absolute failure of Linux dead ahead?
Unable to Compile linux-2.3.48 (Young4ert)
Re: Absolute failure of Linux dead ahead? ("Paul D. Smith")
Re: Absolute failure of Linux dead ahead? (mlw)
'file' command source ("Mark Barlow")
Re: Absolute failure of Linux dead ahead? (David T. Blake)
Re: Q: Find Sound Mixing Tool. (Young4ert)
Re: Struct size and allocate problem! need help. (Charles Bryant)
Re: Moving our product line to Linux ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: grant@nowhere. (Grant Edwards)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 02 Mar 2000 21:25:36 GMT
In article <[EMAIL PROTECTED]>, Edward Rosten wrote:
>Linux is fully 64-Bit on systems that are fully 64-Bit. So, on systems
>that are designed for proper performance, it gives proper performance. I
>am not a fan of the i86 and think that it is faintly ridiculous that
>intel are still persuing the 32 bit line, (by jacking up the [MG]Hz) and
>trying to get more performance out of an inherently limited design.
The x86 architecture was lame when it came out 20 years ago,
and its gone down hill ever since. All this pain and agony
based on the theory that if you design the 8086 as a bloated
8080, then a few CP/M programmers can auto-magically translate
8080 assembly language. I'd bet money that the whole automatic
asm translation thing never panned out anyway.
--
Grant Edwards grante Yow! Yow! Are we wet yet?
at
visi.com
------------------------------
Date: Wed, 01 Mar 2000 08:28:27 -0500
From: "Frank V. Castellucci" <[EMAIL PROTECTED]>
Subject: Re: clone() and shared library heap allocations
Ulrich Weigand wrote:
>
> "Frank V. Castellucci" <[EMAIL PROTECTED]> writes:
>
> >No, it is rather involved. BUT, I even added a debug string in the method that is
> >being called in the real code, and it is never output! This makes me think that the
> >rtl heaps between shared libs, and multiple threads has some kind of quirk. If you
> >need a more detailed code example, I can post it.
>
> This does *not* work. If you use clone() directly, libc is not aware
> that multiple threads are running, and does not protect against
> re-entrancy. Note that even if you compile with -D_REENTRANT,
> this is still true, because in this case, libc tries to protect its
> critical sections with pthreads synchronization mechanisms; but as
> you don't link with libpthread, those routines are not present, and
> thus the synchronization calls are silently omitted.
>
Ulrich,
Don't later versions of rtl INCLUDE LinuxThreads and respective support?
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
------------------------------
From: "Edward Balassanian" <[EMAIL PROTECTED]>
Subject: Moving our product line to Linux
Date: Thu, 2 Mar 2000 15:25:43 -0800
I work for BeComm Corporation, a startup in Redmond Washington. We've spent
the past 6 months doing feasibility studies on porting our flagship product,
Strings, to Linux. We have the software up and running and are convinced
it is the right platform for us (please forgive us for spending the prior 3
years on Windows ). We are now committed to making Linux support a major
initiative at the company. Our software is a highly distributed OO
environment where small software objects called Beads, are dynamically
loaded into a matrix of other objects. As the system runs, these objects
are strung together on the fly (hence the name Strings for the product) to
handle anything from displaying HTML files, to video conferencing or
performing network address translation.
This poses several challenges that I hoped to get some clarification on:
1) we create a ton of threads. My concern is that the thread packages
available on Linux will not be lightweight enough to handle our needs. I
speak a bit out of ignorance here so any clarification would be greatly
appreciated. We have our own scheduler so writing our own thread package is
not out of the question.
2) Many of our Beads manage end devices such as screens, disks, mouse,
keyboard etc.... On Windows we have interface libraries that abstract the
underlying platform api from us so we can stay device independent. We use
api such as DirectX for screen access, NDIS for mac access, Wav for audio,
TAPI for telephony. I don't expect that equivalents for all of these are
available on Linux, but primarily we are concerned with the screen and the
network drivers. What facilities are available on Linux to talk directly to
underlying hardware without having to go through a highlevel API?
3) Finally, yes I will probably get flamed for asking this, we are investing
heavily in Linux and want to build a worldclass team to not only integrate
Strings onto Linux, but to also optimize both the kernel and device drivers
to support our architecture. What is the best venue for finding top Linux
system/kernel developers?
Any suggestions, pointers or references will be greatly appreciated.
Edward Balassanian
BeComm Corporation
------------------------------
From: Mark Robinson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 02 Mar 2000 23:51:59 GMT
Jon wrote:
> On 2 Mar 2000 19:53:00 GMT, [EMAIL PROTECTED]
> (Wolfgang Weisselberg) wrote:
>
> > On Thu, 02 Mar 2000 17:52:16 GMT,
> > Jon <[EMAIL PROTECTED]> wrote:
> > > On Thu, 02 Mar 2000 08:20:02 -0500, mlw <[EMAIL PROTECTED]>
> > > wrote:
> >
> > [2038]
> > > > I am not sure that I care about this one, it is 37 years away. In 37
> > > > years, 64 bit computers will be obsolete.
> >
> > > This is precisely the logic that *created* the Y2k problem.
> >
> > Yep, but it's not applicable ...
> >
> > > Thinking that the problem will go away by itself due to software
> > > or hardware obsolesence is a huge mistake.
> >
> > How many machines do *you* know that are in active use today
> > *and* were so 15,20,30 years ago?
>
> 2 that I've worked with personally. There are thousands of
> others... witness the demand for Cobol programmers that occured
> in 1999.
>
> > Also the 2038-problem differs because it is Not There on 64bit
> > machines with any semi-well written software (which uses the time
> > struct). Thus, repair means just a recompile on a 64bit machine.
> > Since you'll have to recompile anyway, there's no problem.
>
> This assumes the hardware will be replaced. This is not always
> true. Take XYZ Corp. who just invested $UmpteenMillion in their
> new WhizBang5000 Unix-based computer system. There's a *very*
> good chance that system will still be there in 2038, operating
> all of XYZ Corp.'s critical accounting and MRP functions. Why
> replace it? It cost a whole lotta cash and it still works just
> fine. Beside that, how would XYZ explain to their investors that
> they need to spend $UmpteenMillions times 2 to buy an all new
> system, just because their old multimillion dollar machine can't
> figure out what year it is?
>
> Jon
This assumes the that the WhizBang5000 is not already 64bit+. If it's not
they were ripped off. If it is they'll be fine.
Mark
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 2 Mar 2000 19:10:47 -0500
Anders Larsen <[EMAIL PROTECTED]> spewed this unto the Network:
>[EMAIL PROTECTED] schrieb:
>>
>> In article <[EMAIL PROTECTED]>,
>> [EMAIL PROTECTED] wrote:
>>
>> [snip]
>>
>> > Wait, wait! There are other scary items forthcoming:
>> >
>> > a) Resolution of the 2038 problem. 2^31-1 seconds from Jan 1, 1970
>> > happens to be in 2038. Stuff Will Break Then.
>> >
>> > This is the end-of-epoch that is the UNIX equivalent to the "Year
>> > 2000 cliff" that everyone worried last year about.
[snip]
>It might be true that in 2038 most people don't care about what happened
>before 2000-01-01, but the *transition* would be tough anyway.
>
>One could, however, perhaps consider changing time_t from signed to
>unsigned - that would add another 68 years to the life-time of the
>32-bit time_t.
However, it would no longer be possible for time_t-returning functions
to return -1 in the event of an error.
Another way to expand the lifetime of the 32-bit time_t is to make it
64-bits long by declaring it as 'long long'.
--
Have you re-installed your operating system today?
------------------------------
From: Young4ert <[EMAIL PROTECTED]>
Subject: Unable to Compile linux-2.3.48
Date: Thu, 02 Mar 2000 13:23:54 -0500
Hi,
I have just downloaded the patch-2.3.48 and applied to the existing
linux-2.3.47 kernel. I reconfigured the kernel and tried to recompile
with the following error:
+++++
cc -D__KERNEL__ -I/home/local/src/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce
-DCPU=586 -DCONFIG_SOUND_AD1848 -DCONFIG_SOUND_MPU_EMU
-DCONFIG_SOUND_SBDSP -DCONFIG_SOUND_UART401 -DEXPORT_SYMTAB -c ad1848.c
ad1848.c: In function `ad1848_prepare_for_output':
ad1848.c:1132: `timer_installed' undeclared (first use this function)
ad1848.c:1132: (Each undeclared identifier is reported only once
ad1848.c:1132: for each function it appears in.)
ad1848.c: In function `ad1848_prepare_for_input':
ad1848.c:1246: `timer_installed' undeclared (first use this function)
ad1848.c: In function `adintr':
ad1848.c:2147: `timer_installed' undeclared (first use this function)
ad1848.c: In function `ad1848_tmr_install':
ad1848.c:2685: `timer_installed' undeclared (first use this function)
make[3]: *** [ad1848.o] Error 1
make[3]: Leaving directory `/home/local/src/linux/drivers/sound'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/home/local/src/linux/drivers/sound'
make[1]: *** [_subdir_sound] Error 2
make[1]: Leaving directory `/home/local/src/linux/drivers'
make: *** [_dir_drivers] Error 2
+++++
Why the compilation complained that "timer_installed" is undeclared?
--
[EMAIL PROTECTED]
PS> Remove the "4" from e-mail address to respond.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 02 Mar 2000 19:09:49 -0500
Reply-To: [EMAIL PROTECTED]
%% [EMAIL PROTECTED] (Jon) writes:
>> Also the 2038-problem differs because it is Not There on 64bit
>> machines with any semi-well written software (which uses the time
>> struct). Thus, repair means just a recompile on a 64bit machine.
>> Since you'll have to recompile anyway, there's no problem.
j> This assumes the hardware will be replaced. This is not always
j> true. Take XYZ Corp. who just invested $UmpteenMillion in their
j> new WhizBang5000 Unix-based computer system. There's a *very*
j> good chance that system will still be there in 2038, operating
j> all of XYZ Corp.'s critical accounting and MRP functions. Why
j> replace it?
Why indeed?
A very common misconception, that you have to have a 64-bit computer to
deal with 64-bit numbers. That's not true at all. Plenty of 16-bit
systems deal with 32-bit numbers, eh?
What you need is a compiler for the WhizBang5000 that supports the "long
long" type, which is mandated to be at least 64 bits and is now part of
the current ISO C standard. Then you need a version of the WhizBang5000
OS which has been updated to have time_t be a 64-bit value (long long
instead of the current long). Then you need the source code to your
apps.
Then you recompile them, and they work.
You _did_ write the code correctly, and not so it relied on the
underlying size of the time_t type, right?
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Thu, 02 Mar 2000 19:21:05 -0500
Jon wrote:
>
> On Thu, 02 Mar 2000 08:20:02 -0500, mlw <[EMAIL PROTECTED]>
> wrote:
>
> > > > a) Resolution of the 2038 problem. 2^31-1 seconds from Jan 1, 1970
> > > > happens to be in 2038. Stuff Will Break Then.
> > > >
> > > > This is the end-of-epoch that is the UNIX equivalent to the "Year 2000
> > > > cliff" that everyone worried last year about.
> >
> > I am not sure that I care about this one, it is 37 years away. In 37
> > years, 64 bit computers will be obsolete.
>
> This is precisely the logic that *created* the Y2k problem.
> Thinking that the problem will go away by itself due to software
> or hardware obsolesence is a huge mistake. Anything you write
> today that will break in 2038 and happens to have your name on it
> will generate a following of People Who Curse Your Name in 37
> years. Corporations have a nasty tendency to buy/invest only
> once and hire consultants to fix things later on. This results
> in much longer than expected lifespans for hardware and software.
>
> Jon
So what, exactly, was the problem with Y2K? I still don't get that one.
You do the numbers, is it cheaper to maintain or rebuild? Sometimes it
is cheaper to rebuild and sometimes it is cheaper to maintain. Clearly,
in retrospect, waiting 'till the last minute to fix the Y2K 'bug' was a
wise decision. A boost to the economy and public hysteria fueled tax
breaks for the development work. IMHO there was no downside to the Y2K
issue. Everyone made lots of money, no laws were broken, and no one got
hurt, a wonderful thing. In previous generations, we would have had to
have a small war to get that kind of economic stimulation.
Right now, as we write, we need >2G files on Linux. End of story.
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com
------------------------------
From: "Mark Barlow" <[EMAIL PROTECTED]>
Subject: 'file' command source
Date: Fri, 3 Mar 2000 00:50:34 -0000
Don't suppose anyone knows which file contains the source for the 'file'
command which uses a magic file to guess filetypes??
I tried having a look myself but failed. If anyone is in the know it would
save me a lot of time looking for it!
Cheers
Mark
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 3 Mar 2000 00:26:36 GMT
Reply-To: [EMAIL PROTECTED]
Edward Rosten <[EMAIL PROTECTED]> wrote:
> I am not a fan of the i86 and think that it is faintly
> ridiculous that intel are still persuing the 32 bit line, (by
> jacking up the [MG]Hz) and trying to get more performance out of
> an inherently limited design.
There is one and only one reason that x86 still exists.
Microsoft.
If they were capable and willing to port Windows to another
platform, another platform would be worthwhile for a major
chip manufacturer for home PCs.
Of course, they are not. Look at the Mac instead. There, they
changed the chip instruction sets and built software interpreters
for legacy cruft - essentially allowing better chip design to
allow better computing speeds, and maintaining backward
compatibility at slower speeds.
Microsoft would rather force ALL major PC chipmakers to make
ridiculous designs using outdated instruction sets than rewrite
Windows. The REAL reason McKinley and other 64 bit chips will
NEVER become very common, at least until Windows dies.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Date: Thu, 2 Mar 2000 13:36:31 -0500
From: Young4ert <[EMAIL PROTECTED]>
Subject: Re: Q: Find Sound Mixing Tool.
"Kim, Hui Jin" wrote:
>
> Hi there.
>
> These days, I am trying to develop Sound mixing program.
> For Example, the program can make one wav file that mixed with two wav
> file.
> anybody know program like this?
> Or anybody can tell me about some kind of way to develop this program.
>
> Have a nice day!
Check http://sourceforge.net database and I believe you will find
something similar ones.
--
[EMAIL PROTECTED]
PS> Remove the "4" from e-mail address to respond.
------------------------------
From: Charles Bryant <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,comp.os.linux.development.apps,comp.unix.sco.misc,comp.unix.sco.programmer,comp.unix.unixware.misc,tw.bbs.comp.linux
Subject: Re: Struct size and allocate problem! need help.
Date: 3 Mar 2000 01:47:12 -0000
In article <[EMAIL PROTECTED]>,
Anders Larsen <[EMAIL PROTECTED]> wrote:
>Charles Bryant wrote:
>> In article <[EMAIL PROTECTED]>,
>> Jaron <[EMAIL PROTECTED]> wrote:
>> >
>> > struct a {
>> > unsigned char a1;
>> > unsigned char a2;
>> > unsigned short a3
>> > unsigned short a4
>> > unsigned long a5;
>> > };
>> >
>> >the structure size must be 10
>>
>> No. It can be any value greater than or equal to five.
>
>How do you arrive at that figure?
>The C language definition clearly and unambigously state that a short be
>*at least* 16 bits and a long *at least* 32 bits of length.
There's no inconsistencey. All of char, short, and long can be 32
bits, in which case sizeof(long)==sizeof(short)==sizeof(char)==1.
This gives a minimum size of 5 for the struct (2*sizeof(char) +
2*sizeof(short) + sizeof(long)). Any size, X, bigger than 5 appears,
for example, if sizeof(short)==1 and sizeof(long)==X-4. Obviously
larger sizes may be possible in different ways.
--
Eppur si muove
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Moving our product line to Linux
Date: Fri, 03 Mar 2000 01:55:22 GMT
On Thu, 2 Mar 2000 15:25:43 -0800 Edward Balassanian <[EMAIL PROTECTED]> wrote:
| I work for BeComm Corporation, a startup in Redmond Washington. We've spent
| the past 6 months doing feasibility studies on porting our flagship product,
| Strings, to Linux. We have the software up and running and are convinced
| it is the right platform for us (please forgive us for spending the prior 3
| years on Windows ). We are now committed to making Linux support a major
I will forgive you for spending the prior 3 years NOT on Linux if you spend
the next 3 years NOT on Windows just to make it fair and even the playing
field. :)
So you've been in business for 3 years and just now decided Linux was worth
considering? I always thought it was the big corporations that ignored all
the new cool stuff.
| 1) we create a ton of threads. My concern is that the thread packages
| available on Linux will not be lightweight enough to handle our needs. I
| speak a bit out of ignorance here so any clarification would be greatly
| appreciated. We have our own scheduler so writing our own thread package is
| not out of the question.
|
| 2) Many of our Beads manage end devices such as screens, disks, mouse,
| keyboard etc.... On Windows we have interface libraries that abstract the
| underlying platform api from us so we can stay device independent. We use
| api such as DirectX for screen access, NDIS for mac access, Wav for audio,
| TAPI for telephony. I don't expect that equivalents for all of these are
| available on Linux, but primarily we are concerned with the screen and the
| network drivers. What facilities are available on Linux to talk directly to
| underlying hardware without having to go through a highlevel API?
The facilities exist with root access, but one does not want to have to be
running as root to use new tools. Consider X Windows. It runs as root to
access the video card directly. It's running as a server and applications
connect to it. The APIs are well known and quite mature.
| 3) Finally, yes I will probably get flamed for asking this, we are investing
| heavily in Linux and want to build a worldclass team to not only integrate
| Strings onto Linux, but to also optimize both the kernel and device drivers
| to support our architecture. What is the best venue for finding top Linux
| system/kernel developers?
Will you be providing your optimizations as source code back to the open
source community? This is, afterall, what Linux is all about. If you don't
want to do that, you won't get much acceptance from the community. Few
people will want to integrate your changes if it means they lose control
over their own computer (e.g. I want to be able to freely upgrade my own
kernel to another version without worrying that it breaks your software).
Lots of things in the UNIX world run as libraries that would in the Microsoft
run as who knows what. Consider making as much as possible, if not all, of
your system run in user address space. Then if you still need to get into
deeper levels to optimize it, make two separate versions, one that is, and
one that is NOT, an "invasive" application or system.
--
| Phil Howard - KA9WGN | for headlines that | Just say no to absurd patents |
| [EMAIL PROTECTED] | really matter: | Boycott Amazon.Com (AMZN) |
| Dallas - Texas - USA | linuxhomepage.com | Shop http://bn.com/ instead |
------------------------------
** 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
******************************
