Linux-Development-Sys Digest #647, Volume #7 Fri, 3 Mar 00 00:13:10 EST
Contents:
Re: Absolute failure of Linux dead ahead? (Michael Sawyer)
Re: Moving our product line to Linux ("Edward Balassanian")
Re: Absolute failure of Linux dead ahead? (Christopher Browne)
..^^SAY A PRAYER FOR THE INNOCENT VICTIMS OF BLACK VIOLENCE AND LAWLESSNESS!...^^^
([EMAIL PROTECTED])
Re: unresolved Symbols in modules (nilesh patel)
Re: 'file' command source (Kent Robotti)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Michael Sawyer)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 3 Mar 2000 02:10:20 GMT
On 02 Mar 2000 19:09:49 -0500, Paul D. Smith <[EMAIL PROTECTED]> wrote:
>
[...]
>You _did_ write the code correctly, and not so it relied on the
>underlying size of the time_t type, right?
There's a problem here which seems largely overlooked in this
discussion.
Joe Programmer writes a program, and does the "Right Thing," using
sizeof(time_t) anywhere he has to know the actual size of the type.
The program he's writing needs to keep some data on disk, which is not
at all an uncommon request. He's choosen to keep them in binary
files, to save storage space. Thus, he's got some structure
struct WHATEVER {
time_t modification_time;
int some_data;
int some_other_data;
char some_more_data[80];
} ;
This structure now gets written to disk.
Now, time_t gets promoted to 64 bits, and he goes to read his data
back from his disk file. We have a problem here, and there's not an
obvious solution. He's got three choices as I see it: Demote all of
his time_t's in the structure saved to disk to 32 bits, and have some
magic code to re-promite it to 64 bits when it gets read in and
written out, which has the means the file format never changes, but
the first field in the struct is no longer *really* time_t, but
something else. He can also provide a little additional program to
reformat the files once he compiles with a 64-bit time_t, which is
probably an acceptable solution if he's the only one using the
program, but if it is a widely distributed thing, it's not good to ask
every user to have to do that also. Finally, he can make his program
smart enough to tell when 32-bit time_t's are used instead of 64 bit
ones, and rewrite the file for the user if it discovers it.
Should he have just used 64 bits for the time structure to begin with,
forseeing this change? Perhaps, BUT that's a Bad Thing, since it
locks in a bit-size for a structure instead of using the OS-defined
size, which is what everyone is trying to promote. At the same time,
he's got to have some logic in the program (which can be done as part
of Configure or in #ifdefs, true) which determines the size of time_t
and sppropriately fills out the struct with zeros if it's only 32 bit.
"Don't write binary files. They are expected to break." That's an
acceptable argument, in some cases (though for BIG data files, going
binary may well be the only choice), but still doesn't fully solve the
problem. If you write out a time_t with printf() to save the files in
ASCII, you need to know whether to use "%ld" or "%lld" in the
formatting string. Again, you can use tests for that, but if the code
was written 10 years ago, you could get away with just assuming time_t
would print with %ld.
More risky, though, is the reading of the ASCII time back into
time_t. If you use scanf(), you HAVE to know whether time_t is 32 or
64; just using %lld all the time will be in error if time_t is only 32
bits long, and will trash memory. Falling back to atol() to do the
conversion for you, at least here you can get away with using atoll()
all the time, if the original programmer thought to use it.
Of course, these are exactly the issues filesystem developers are
running into in going to a 64 bit time_t, as I understand it.
In other words, you can't always expect a change in the size of time_t
to work, even if the programmer went to some degree of effort to
always use sizeof(time_t) instead of just assuming 32 bits. Once the
data gets out of the program, some assumptions HAVE to be made, like
it or not, and that's where we are going to see problems, IMHO.
Mike
------------------------------
From: "Edward Balassanian" <[EMAIL PROTECTED]>
Subject: Re: Moving our product line to Linux
Date: Thu, 2 Mar 2000 18:53:20 -0800
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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.
>
The technology is meant to run on a variet of platforms. We currently
support Windows(98/NT/CE) and VxWorks. We started evaluating linux about a
year ago and actually have Strings up and running on Linux, but we need to
do a fair bit of work to make it work better. Truth is, being based in
Redmond Washington, literally in the shadow of Big Bill, has made us more
than paranoid about being tied to a platform that is responsible for
proliferation of more buildings around our humble offices than I can count.
>
> | 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.
>
As I understand it, X provides a shared memory facility that is effectively
like writing direct to the frame buffer. This would be ideal for us. What
we don't want is a ton of layering between us and a device since we are
focused on high-bandwidth multimedia rendering.
>
> | 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).
>
Sure. We understand that. Our goal is to work with the Kernel to not only
support our platform but to make it more condusive to multimedia/networking.
Examples would be porting our EDF scheduler or thread manager to the kernel.
This is not work that we want to hoard so yes, it would be given back to the
open source community.
> 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.
>
Understood.
> --
> | 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
|
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 03 Mar 2000 03:15:09 GMT
Centuries ago, Nostradamus foresaw a time when Jon would say:
>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.
*Somewhat* fair comment. A couple of caveats:
a) Are there PCs being made now that will likely still be made in 37
years? Realistically, I don't think so.
b) The usual availability of source code to software means that there
are realistic ways to remedy problems. Fix the library, recompile,
and things (hopefully) work.
This is in stark contrast with the mainframe situation where in
many cases people are running, today, hardware that is emulating,
complete with old bugs, the same software that was compiled 20
years ago.
Linux has had a couple of "incompatibility cliffs" already that
have mandated recompiling things from scratch, thereby resolving
incompatibilities with old environments, namely:
i) The a.out-to-ELF object code format change,
ii) The libc5-to-GLIBC2 change.
Painful though these two things have been, they have underlined the
importance of starting with source code.
For the most part, little effort was required beyond recompiling
with new compilers/libraries in order to resolve the issues.
As a result, if there's a Debian source .deb or a source RPM, or a
BSD Ports package available, the issue is largely moot. It seems
reasonable to expect that if anyone cares enough about the
software, remedies will be made.
c) It may very well be that the "2038 problem" will get solved
concurrently with the (also-about-32-bit-limits) problem that NFS
and filesystems and applications and libraries tend to be
restricted to 2GB files.
*THAT* issue is biting people, which is likely to justify the
efforts required to change libraries and filesystems to move things
up to 64 bit limits (or similar).
It makes sense to jump off both cliffs at once, as it were...
d) While it may be unwise to simply *ignore* the issue as being "37
years away," it would be *equally* unwise to take the position that
we must "hack" a "patch" into place *instantly.*
I'd prefer to see this issue resolved within the next five years,
but would not have any problem with waiting even that long.
e) I could even go along with the idea of waiting ten years, and
allowing time to sweep the majority of systems on to 64 bit
platforms, where neither 32-bit-isms bite them.
At *that* point, moving things over to have Linux emulate 64
operations on 32 bit platforms becomes an option; performance gets
hurt, but if AMD/Intel are still making 32 bit chips in ten years,
they'll be rather faster than they are now, thus making the loss a
bit more acceptable.
I think it's more realistic to expect that file/date ops will move to
being 64 bit operations on IA-32 some time over the next couple of
years.
--
"I visited a company that was doing programming in BASIC in Panama
City and I asked them if they resented that the BASIC keywords were in
English. The answer was: ``Do you resent that the keywords for
control of actions in music are in Italian?''" -- Kent M Pitman
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED]
Subject: ..^^SAY A PRAYER FOR THE INNOCENT VICTIMS OF BLACK VIOLENCE AND
LAWLESSNESS!...^^^
Date: Fri, 03 Mar 2000 04:01:51 GMT
It's interesting to see how selective the black community can be when it comes to what
they get outraged about.
-
A couple of recent examples:
-
1) A four-year-old white boy was dragged 4 miles to his death by a black man when the
automobile his mother was driving got car-jacked. The child was attached to a
seatbelt, hanging out the side of the car, clearly visible to the perpetrator. The
mother frantically pleaded for the life of her son to no avail. Some other motorists
watching this horror unveil eventually subdued the driver. According to bystanders and
police, the man was completely remorseless.
-
Tell me something... How is this man any less of an animal than the 3 rednecks that
dragged a black man to his death behind a pickup truck last year? So, where is all the
public outrage and cries of racism here?
-
2) Yesterday, a black man went on a firing rampage, shooting 5 white people - killing
2 and leaving 1 in critical condition with a bullet lodged in his brain. When asked
why he did it, he told a neighbor and police that he just wanted to kill as many white
people as he could. Again, completely remorseless.
-
Again, where is all the public outrage and cries of racism here?
-
Whenever incidents of this type occur, there is a defining silence coming from the
black community. The double standard that seems to apply, suggests that it's OK for
black criminals to victimize whites but not the other way around and has led to a well
deserved lack of credibility for black's when it comes to criminal justice.
-
Americans (law-abiding blacks and whites alike) have finally decided not to allow this
double standard and racial bias to infect the judicial system any further and this was
at the rudiment of the judge's decision to move the Diallo trial out of The Bronx.
-
And since no discussion on this subject would be complete without a comment on the
Diallo verdict;
-
For the record, I didn't agree with this verdict. At a minimum, I think these cops
should have been charged with extreme reckless indifference to human life and they
should have been punished.
-
This was not murder however... It was incompetence... If these cops set out to murder
this guy, then would have done it quietly in a back alley or other such place and they
would have quietly gotten away with it.
-
The real culprit here is the culture of young, black, African American males, which
engender an atmosphere of fear and lawlessness wherever they congregate!
-
These neighborhoods to which the NYPD Street Crimes Unit are assigned, are some of the
most dangerous in New York City. Kids pull handguns on cops all the time and many
policemen have been shot, killed and maimed.
-&
In this highly charged, hair-trigger environment, no cop is going to risk his or her
life if he or she believes someone is about to pull out a gun.
-
No degree of sensitivity training, weapons regulations, political pressure, threats,
or other feel-good expedients is going to change a thing until the black community
starts to take responsibility for their children and their communities.
-
In a strange sort of way, one might consider the final outcome of this trial payback
for the O.J. verdict.
-
-
-
-
-
-
-
.....................................................................................................................
The following is an encoded message to the Tri-Lateral Commission:
.....................................................................................................................
Ekm a rr kesy egb
leow fnsr odes bi?
Zlipk lpru pdf klq pes
qle ifo opekxy lmvzz
ko ilts jfyat pouf
mdeu tfsdnn lxrd vclbyr tees
lbwe caw egti rkkr.
Xdkey fke lgym oavx ivk psu
gner psmtka gedwlk pnfns a lysb yv.
Sebee uslksl rqrmfno kiti yueb
szt ztkss lcsuix y fiefr kxb ilk?
Lmpre amc orc sgm sfimpf sdroi
re feig a fd ecku
febr udig vvh uuni brbae.
Rbzskl cnh ufrmj uimfs mtnln
kns jf ityl ffe hxtq
pkyw sskm usn ypkn rufl apil
edyyz mtiln ioxal bofdi sbazc
gmj enemiz fyms rsqy iiir ma
cnr gtce jce xwt fus i zb
akjju ufrpmt npi enlry i lnelnnk op!
Hstfv fzases nns tdak y uyerm
ssps kte elt odd lm?
Uluuzn keeme nlol cflk
mlcafw rrkn grdekl lpy gclulkp gm
arhdc fpelj lposy pejg npo lrcrl
hlmykwp cyc llcq ponerc ufkqu bsia
ikrkjg fhbm cuvdorr nnm deryd
dktbok lssiz pyvl bsba
to slmk by li eu?
I ms unlps kxm a ogok mfv
ibe kyfse wrsi ttf
geyskn vcr uuyfe dflp
acsp leers o npoik raa
ha lteb rusl a cbff rce
oplri dmf fgbswp vp?
Flbeiyrp irqa eser keidbft ts
cuea yrsb bilm lrz eslt ksyco
tie a lpyh skeb jlekp.
O ekec tefp nl io slbsh pmn.
I nhgy o chsg mql cap le!
Lwlsosue pbho yilneim ub o obe lrnw
eheena fsxdpvt efiuudv mn
tsys tloek pptht lob ils tltof
efd fas sd rzuu i kf
sxj iiobd fso cdelle psm.
A bed kwnmk mcw ifna wwbu wsr.
------------------------------
From: nilesh patel <[EMAIL PROTECTED]>
Subject: Re: unresolved Symbols in modules
Date: Fri, 03 Mar 2000 09:59:09 +0530
Mathias Waack wrote:
> Paul Goossens wrote:
> Hi,
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
>
> Signing a common news posting is IMO waste of bandwidth.
>
> > ALL the adresses. I know, it sounds strange to me also, but if anyone
> > knows more about this, please tell us!
>
> It sounds really strange. Unresolved symbols in modules come from 4 sources:
>
> 1. the programmer forgot to define __KERNEL__ and MODULE.
> These symbols are used by a lot of header files to insert kernel specific stuff
Yes this was what I forgot.
Actually I have a multifile module and I was Defining them in only one file.
Thank You
>
> 2. the programmer forgot to give the gcc the commandline switch -O2
> The gcc starts inlining at this tuning level. Inlining is needed to eleminate some
> unused symbols in the code
> 3. the user try to insmod a module for a another kernel then the module was compiled
>for.
> 4. the programmer forget to define some symbols which she declared before
>
> I wouldn't recommand you using switches higher then O2. The compiler may inline some
> functions which shouldn't be inlined and the error rate of the comiler raises
> exponentiell (thats my humble experience)
>
> Mathias
------------------------------
From: Kent Robotti <[EMAIL PROTECTED]>
Subject: Re: 'file' command source
Reply-To: [EMAIL PROTECTED]
Date: 3 Mar 2000 00:00:08 -0500
Mark Barlow <[EMAIL PROTECTED]> wrote:
> 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!
Look for file-3.28.tar.gz.
------------------------------
** 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
******************************
