Linux-Development-Sys Digest #625, Volume #7 Fri, 25 Feb 00 14:13:20 EST
Contents:
Re: Binary compatibility: what kind of crack are they smoking? (Kari Pahula)
Re: memory allocation . (Fabrice Peix)
Re: RedHat 6.0 (Toby Haynes)
Re: System hanging with SMP-Kernel 2.2.13 (SuSE6.3)? (Greystoke)
Re: memory allocation . (Nilesh Patel)
Re: Does linux support DIRECT I/O? (Pat Kling)
Re: bug: same dir content after changing disks (Ul f Dambacher)
Re: Binary compatibility: what kind of crack are they smoking? (Donovan Rebbechi)
Help needed with printk and klogd (Sergio Murru)
Re: Binary compatibility: what kind of crack are they smoking? (JEDIDIAH)
Re: glibc development language (Kaz Kylheku)
Re: Binary compatibility: what kind of crack are they smoking? (Craig Kelley)
Re: Q: How good is Linux when the computer is suddenly loses power ? (J Bland)
Re: ioremap() and PCI devices (Steve Johnson)
2.2.x SMP and DK440LX issues (Dmitri A. Sergatskov)
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
Re: Binary compatibility: what kind of crack are they smoking? (Mario Klebsch)
----------------------------------------------------------------------------
From: Kari Pahula <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: 25 Feb 2000 14:18:02 GMT
In comp.os.linux.development.system Mario Klebsch <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Donovan Rebbechi) writes:
>>Binary only software should ship with all the required shared libraries.
>The key word here is SHOULD. Linux should include an ABI, but it does
>not. Binaries should be shipped with all required libraries, but they
>are not. :-(
No, Linux should _not_ have an ABI, neither any other OS. ABIs are
Evil, they lead to tons of legacy cruft, which can be avoided with
a simple recompilation from sources. It's much easier to make stable
APIs.
It is then distribution makers' responsibility to compile newest
versions compatible with distribution-specific libraries, if they
choose to do so. Either way, the user is always able to compile the
programs herself.
IMHO the requirement for an ABI is an inherent vulnerability of
proprietary software and I'm glad I can do without it!
------------------------------
From: Fabrice Peix <[EMAIL PROTECTED]>
Subject: Re: memory allocation .
Date: Fri, 25 Feb 2000 15:16:34 +0100
Ralf Render wrote:
>
> Try get_free_pages(GFP_KERNEL, 3).
>
> nilesh patel <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
> [EMAIL PROTECTED]
> > hi ,
> > how do you allocate a 64 K contiguous real memory for PCI
> > devices ?
> >
> > do reply fast ,
> >
> > thanks ,
> > nilesh .
> >
i think it is get_free_pages(GFP_KERNEL, 4). for PAGE_SIZE = 4096 and
get_free_pages(GFP_KERNEL, 3) for PAGE_SIZE = 8192.
------------------------------
From: Toby Haynes <[EMAIL PROTECTED]>
Subject: Re: RedHat 6.0
Date: 25 Feb 2000 09:32:44 -0500
!! "Sake" == Sake <[EMAIL PROTECTED]> writes:
Sake> Hi there, Given the popularity of RedHat Linux, there probably
Sake> should be a RedHat group. Anyway, I'll use this for now.
One thing there is not a shortage of is RedHat newsgroups! Try the
following
linux.redhat
linux.redhat.announce
linux.redhat.axp
linux.redhat.development
linux.redhat.install
linux.redhat.list
linux.redhat.misc
linux.redhat.ppp
linux.redhat.rpm
redhat.announce
redhat.config
redhat.control
redhat.general
redhat.hardware.arch.alpha
redhat.hardware.arch.intel
redhat.hardware.arch.sparc
redhat.hardwareredhat.networking.general
redhat.kernel.general
redhat.networking.general
redhat.rpm.general
redhat.security.general
redhat.servers.general
redhat.test
redhat.x.general
Cheers,
Toby
--
Toby Haynes
The views and opinions expressed in this message are my own, and do
not necessarily reflect those of IBM Canada.
------------------------------
From: Greystoke <[EMAIL PROTECTED]>
Subject: Re: System hanging with SMP-Kernel 2.2.13 (SuSE6.3)?
Date: Fri, 25 Feb 2000 09:58:37 -0500
On Feb 23, Yuan spake the following:
: in the latest development kernels. Can someone confirm this NFS-related
: (in-)stability point in regards of SMP-operations? The hangings appeared freq. if
: NFS-filesystems were intensivly used (~ 200MB data in several sec. over NFS).
NFS is inherently unstable and insecure (wants it's mommy?) and I wouldn't
be suprised if this is what causes your hangs.
Also, I noticed you have 2GB RAM
a) do you have the 2GB fix compiled into the kernel?
b) can you send some to me? <j/k>
Regards,
Greyson
#!/usr/bin/perl
@a=(Lbzjoftt,Inqbujfodf, Hvcsjt); $b="Lbssz Wbmm" ; $b =~ y/b-z/a-z/ ; $c = " Tif ".
@a ." hsfbu wj" ."suvft pg b qsphsbnnfs" . ":\n"; $c =~y/b-y/a-z/; print"\n\n$c ";
for($i=0; $i<@a; $i++) { $a[$i] =~ y/b-y/a-z/; if($a[$i]eq$a [-1]) {print"and $a[$i]."
; }else{ print"$a[$i], "; }}print"\n\t\t--$b\n\n";
------------------------------
From: Nilesh Patel <[EMAIL PROTECTED]>
Subject: Re: memory allocation .
Date: Fri, 25 Feb 2000 20:41:51 +0530
thanks ralf .
Fabrice Peix wrote:
> Ralf Render wrote:
> >
> > Try get_free_pages(GFP_KERNEL, 3).
> >
> > nilesh patel <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
> > [EMAIL PROTECTED]
> > > hi ,
> > > how do you allocate a 64 K contiguous real memory for PCI
> > > devices ?
> > >
> > > do reply fast ,
> > >
> > > thanks ,
> > > nilesh .
> > >
> i think it is get_free_pages(GFP_KERNEL, 4). for PAGE_SIZE = 4096 and
> get_free_pages(GFP_KERNEL, 3) for PAGE_SIZE = 8192.
------------------------------
Subject: Re: Does linux support DIRECT I/O?
From: Pat Kling <[EMAIL PROTECTED]>
Date: 25 Feb 2000 10:05:46 -0500
Robert,
Thank you for the information. This is indeed what I was looking for.
Did the "gods" propose an alternative to this ubiquitous method? Are
you planning on supporting your common sense patch?
The lack of copying achieved by scatter/gather to user space has become
even more important since I'd like to consider 200 MB/s as well.
Pat Kling
[EMAIL PROTECTED] (Robert Kaiser) writes:
>
> In article <[EMAIL PROTECTED]>,
> Pat Kling <[EMAIL PROTECTED]> writes:
> >
> >
> > On Linux, what is the standard way to deal with a
> > stream-like device has must provide many MBs per second
> > (say 25 MB/sec) to a user application through a point-to-point
> > link?
>
> IMHO, there is not a suitable standard way. Stock Linux kernels
> don't support scatter/gather DMA from/to user space which is what
> you'll most likely want for stream-like devices.
>
> This is quite a big surprise for anyone who has written drivers
> for just about any major OS (Solaris, AIX, NT, *BSD, to name a few)
> before, as they _all_ provide this capability. It is even more surprising
> considering how cheap and easy it is to add such a feature (see my patch
> at ftp://ftp.sysgo.de/pub/Linux/).
>
> Nevertheless, when I tried to to get this little patch into the standard
> kernel, the Gods told me that this is "just not the right way", not
> giving any convincing reason though...
>
> I guess the Solaris, AIX, NT and *BSD people must all be idiots then ;-)
>
> Rob
>
> ----------------------------------------------------------------
> Robert Kaiser email: rkaiser AT sysgo DOT de
> SYSGO RTS GmbH
> Klein-Winternheim / Germany
>
>
------------------------------
From: Ul f Dambacher <[EMAIL PROTECTED]>
Subject: Re: bug: same dir content after changing disks
Date: Fri, 25 Feb 2000 16:29:50 +0100
Hi again
I found out that there is a big discussion on the kernel mailing list about
the topic of
not flushing the buffer cache after umount.
Some think it is a feature not having to read everything again after
remount, others
think it is a bug for flexible media
A patch exists, but Alan Cox thinks this has to be done in user space.
Any other information?
bye
Ulf
------------------------------
From: [EMAIL PROTECTED] (Donovan Rebbechi)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: 25 Feb 2000 16:23:39 GMT
On 25 Feb 2000 14:18:02 GMT, Kari Pahula wrote:
>It is then distribution makers' responsibility to compile newest
>versions compatible with distribution-specific libraries, if they
>choose to do so. Either way, the user is always able to compile the
>programs herself.
This assumes that there exist no third party binary only apps. This in
the long term is a dangerous assumption.
BTW, it would be kind of cool if the build system were more failsafe
( like the BSD ports ). BSD ports basically automatically download all
the compile time dependencies, and install them ( trying multiple ftp
sites in case one is down ) , and the software is verified using checksums
that come with the distribution. This way, unattended builds are much simpler.
--
Donovan
------------------------------
From: Sergio Murru <[EMAIL PROTECTED]>
Subject: Help needed with printk and klogd
Date: Fri, 25 Feb 2000 17:21:31 +0100
I'm a newbye kernel module's writer.
I'm trying to have printk() messages directed to the console.
The kernel I use is the 2.2.14.
The printk(KERNEL_EMERG... ) prints on the console
The printk(KERNEL_ALERT... ) prints only in the /var/log/messages file
killing and restarting klogd with the -c option specifing 8 as the
console default level doesn't help.
Any suggestion?
Thank you in avance for your help.
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Fri, 25 Feb 2000 16:40:59 GMT
On 25 Feb 2000 16:23:39 GMT, Donovan Rebbechi <[EMAIL PROTECTED]> wrote:
>On 25 Feb 2000 14:18:02 GMT, Kari Pahula wrote:
>
>>It is then distribution makers' responsibility to compile newest
>>versions compatible with distribution-specific libraries, if they
>>choose to do so. Either way, the user is always able to compile the
>>programs herself.
>
>This assumes that there exist no third party binary only apps. This in
>the long term is a dangerous assumption.
No it doesn't. The concept of 'relink-at-install-time' actually
has some precedent in Unix. As long as the standard system is
considered to have a full build enviroment, this issue should
never really be a problem.
>
>BTW, it would be kind of cool if the build system were more failsafe
>( like the BSD ports ). BSD ports basically automatically download all
>the compile time dependencies, and install them ( trying multiple ftp
>sites in case one is down ) , and the software is verified using checksums
>that come with the distribution. This way, unattended builds are much simpler.
--
|||
Resistance is not futile. / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: glibc development language
Reply-To: [EMAIL PROTECTED]
Date: Fri, 25 Feb 2000 17:06:18 GMT
On Thu, 24 Feb 2000 13:25:55 -0800, tye4 <[EMAIL PROTECTED]> wrote:
>
>Christopher Browne <[EMAIL PROTECTED]> wrote in message
>news:bM0t4.37328$[EMAIL PROTECTED]...
>> Centuries ago, Nostradamus foresaw a time when tye4 would say:
>> >The GNU guidelines in http://www.gnu.org/prep/standards.html
>> >state that it is better to use only C for glibc development.
>> >I've been developing C++ code for glibc. Is this a strict requirement
>> >or is it okay to use C++ for glibc
>>
>> I think you're confused.
>>
>> Only C is used to develop GLIBC, because GLIBC is a C-oriented
>> library. It might be well and nifty to write portions of GLIBC in
>> Intercal or Emacs Lisp; that would *not* be a good thing for anyone
>> that intends to actually deploy GLIBC.
>>
>I'm not confused. C++ can indeed be used to develop libraries for C
>programmers.
>extern "C"
>{
> void c_func1(int foo, int bar);
>}
Now you need a C++ compiler to build it. The GNU libc does not require the user
to have a C++ compiler in order to install
A lot of free software doesn't even require ANSI C, though that has been
rapidly changing in recent years.
>C++ is a standard for all these years. I don't quite understand the
>reluctance in using C++ for system development in Linux.
What? C++ was only standardized like about a year ago or so. It's
hardly been a standard for ``all these years''. Until compilers catch up
with the standard, it is still a moving target.
For years after the ANSI C standard, the free software world continued to
use classic C for maximum portability, and much of it still continues
to do so.
>According to the "Gnu coding standards", the problem with C++ is that
>somebody installing glibc may not have a C++ compiler, thereby making it
>"incovenient" for them to install glibc. That's strange because anybody
>having the GNU gcc compiler is very likely to have the g++ compiler
>installed too.
That is far from true. I have installed GCC many times without any front end
other than C.
Secondly, the GNU libc does not require the GNU compiler. This library supports
systems other than Linux: installations of these systems may not have the GNU
compiler suite, just some bundled compiler.
Note that the GNU libc uses classic ``K&R'' C without prototypes, at least
in the parts that are ported to systems other than Linux.
For example, look at its definition of the fputc() function:
int
fputc (c, fp)
int c;
_IO_FILE *fp;
{
int result;
CHECK_FILE (fp, EOF);
_IO_cleanup_region_start ((void (*) __P ((void *))) _IO_funlockfile, fp);
_IO_flockfile (fp);
result = _IO_putc_unlocked (c, fp);
_IO_funlockfile (fp);
_IO_cleanup_region_end (0);
return result;
}
Also note that the library headers have the __P () wrapper around parameter
list declarations.
And here you are talking about going to C++!
>The "C++ slower than C" argument is quite old - dating back to the early
>nineties. This was when most programming shops had switched from assembly to
>C. However, C++ is quite ubiquitous now. So why is it not used in Linux? I
C++ is used in Linux for application development.
>think it is easier to use an OO language to develop large complex systems
There is next to no need to use an OO language to develop the system interfaces
described by POSIX and The Single UNIX Specification. The abstractions
described by this interface are not inherently object oriented.
>rather than an old structured prog. lang. like C. The "overhead" of C++ is
>in the imagination of the critics and not real.
What is true is that you probably don't pay for what you don't use. But the
overheads are there. If you start using virtual dispatch or templates
frivolously, you can create significant overheads.
>Most programmers use C++ or Java nowadays.
You can't use Java for serious system development, so you can forget about that
one.
------------------------------
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
From: Craig Kelley <[EMAIL PROTECTED]>
Date: 25 Feb 2000 10:09:16 -0700
[EMAIL PROTECTED] (Mario Klebsch) writes:
> Craig Kelley <[EMAIL PROTECTED]> writes:
>
> >[EMAIL PROTECTED] (Mario Klebsch) writes:
>
> >> But in Linux, there is no ABI, and this is the problem.
>
> >True, but it's an industry-wide problem, not inherent to Linux.
>
> ... but in almost every other UNIX variant, it is much better as in
> linux. It does not help at all to se, how great Linux is compared to
> Windows. The ABI is a key concept required for binary software
> distribution, and this is missing in Linux. Windows at least tries to
> offer it.
As does Linux. You'll see packages built for glibc5, glibc2 and
(unfortunately) glibc2.1. If you try to install a package which
requires one or the other, it will (should) kindly tell you to install
it -- and, if you're using apt-get or rpmfind it'll even allow you to
automatically download and install the correct version.
> BTW, your observations of windows programs does not hit the target at
> all. The ABI is not everything, a specific version of an OS does offer
> to its applications, but only a well defined subset. No one can
> guarantee, that an applications uses an interface that is not part of
> the ABI. This seems to be common practis on Windows systems. Before
> blaming Windows for it, you should be sure, the applications failing
> are only requiering the ABI. Of a simple user, this almost is
> impossible, and expert users often cannot do this either.
Then the ABI either wasn't "well defined" or didn't provide the
required function calls. Either way, it's the same problem to the end
user; juggling libraries by hand or with third-party tools.
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: [EMAIL PROTECTED] (J Bland)
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.development.apps,linux.redhat.devel,linux.redhat.development
Subject: Re: Q: How good is Linux when the computer is suddenly loses power ?
Date: 25 Feb 2000 12:17:47 GMT
On Fri, 25 Feb 2000 04:36:35 GMT, Miguel Cruz <[EMAIL PROTECTED]> wrote:
>Markus Wandel <[EMAIL PROTECTED]> wrote:
>> (I have since gotten a longer power cord, eliminating the accidental
>> powerdowns!)
>
>Does that work the same way that a longer garden hose means you have a
>little more water around when the main gets shut off?
>
Maybe the shortness of the cable was causing the powerdowns by being pulled
out of the socket or hanging around in vulnerable places; with a longer
cable you have more freedom to move equipment and can route it around the
office/room better and keep it out the way.
Some of my equipment is right at the end of their 'tether' and a good tug on
a Case or monitor would power them down (if this sounds annoying then tell
my HOD to release funds to GET SOME PROPER EQUIPMENT.)
Shrike
------------------------------
From: Steve Johnson <[EMAIL PROTECTED]>
Subject: Re: ioremap() and PCI devices
Date: Fri, 25 Feb 2000 11:27:17 -0700
Colin Higgs wrote:
> I have a PCI device I want to write a driver for (DAQ board). This is my
> Any ideas or help would be most welcome.
> ...
> Colin.
I am doing pretty much the same in a driver that I am writing, and appear
to be reading/writing OK. (GT64115_reg_map is a register map for a chip)
[Code snippet]:
volatile GT64115_reg_map *p;
/* Map the 4KB Internal Registers region. */
deviceinfo.vaddr=ioremap(deviceinfo.regions[eInternalRegisters].addr,
deviceinfo.regions[eInternalRegisters].size);
p = (GT64115_reg_map *)deviceinfo.vaddr;
p->AddressDecodeError = 0x0;
etc..
I wonder if the problem is that your tmp_read_word isn't volatile and
is being cached?
I don't use the readw() or writew() functions.
--
Steve Johnson | Internet: [EMAIL PROTECTED]
Hewlett-Packard Company | phone: (208) 396-6464
Mopy/Copy Solutions, M/S 272 | Fax: (208) 396-7848
11311 Chinden Blvd, Boise, ID 83714 |
------------------------------
From: [EMAIL PROTECTED] (Dmitri A. Sergatskov)
Crossposted-To: comp.os.linux.hardware
Subject: 2.2.x SMP and DK440LX issues
Date: 25 Feb 2000 18:53:32 GMT
Reply-To: [EMAIL PROTECTED],[EMAIL PROTECTED]
Hello,
I updated multiple dual-CPU computers to RedHat 6.1 and recently
noticed that the computer built around Intel DK440LX (2X 333 MHz P-II)
motherboard has some "problem" in SMP mode. All benchmarks I tried
(MATLAB bench() or custom compiled Fortran code) are running
significantly (almost twice, but varies) slower in SMP mode than in UP
mode. In UP mode the numbers are the same as with similar system built
on 440BX motherboard (also 2X333Mhz) and the same as they used to be
with RedHat 5.2 (and earlier) and 2.0.x kernels.
The simplest "benchmark" I tried is the following trivial loop:
double precision x,y,z,sum
integer i,j,k
sum = 0.0d0
do i = 1, 1000
do j = 1, 1000
do k = 1, 100
sum = sum + real(i)*real(j)/real(k)
end do
end do
end do
write (6,*) sum
end
On LX machine 'time -v' gives: 11.5 sec. user, 5.5 sec. system (18 elapsed)
and approx 100 page faults (in case it matters), on BX the same binary
would result in: 11.5 sec. user, 0.1 sec system (11.5 elapsed)and also
100 page faults.
The difference is even worse for memory intensive code.
If I boot LX machine into SMP mode but with 'noapic' kernel argument it
runs the code as well as BX (but PCI would not work).
I tried 2.2.12 (stock RH6.1 and custom compiled) and 2.2.15(from RH6.2beta)
with identical results.
I do not no if I can easily run 2.0.x kernel on RH6.1 but I will try.
I do not see any error messages in /var/log/messages or elsewhere.
Bogomips or OK (cat
All suggestions and advises would be greatly appreciated.
Sincerely,
Dmitri.
p.s.:
Both computers have 512MB SDRAM and essentially identical CPUs.
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 0
cpu MHz : 333.061631
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr
bogomips : 332.60
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 0
cpu MHz : 333.061631
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr
bogomips : 332.60
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Fri, 25 Feb 2000 18:27:19 +0100
Anders Larsen <[EMAIL PROTECTED]> writes:
>Mario Klebsch wrote:
>> ... but in almost every other UNIX variant, it is much better as in
>> linux. It does not help at all to se, how great Linux is compared to
>> Windows. The ABI is a key concept required for binary software
>> distribution, and this is missing in Linux. Windows at least tries to
>> offer it.
>Oh well, with Linux, distribution of the *source code* of applications
>is certainly encouraged. :-)
>IMHO, that is a Good Thing (tm)
Yes, source code always is a Good Thing (tm)! But having a well
defined ABI for Programs, not distributed in soruce code is a Good
Thing (tm), too!
>If the Windows ABI is really such a "well defined subset", how come
>that's not common knownledge (except, perhaps, within Microsoft, Inc.) ?
The absense of common knowledge about the OSes from Microsoft always
irritated me. After switching from CP/M-80 to MS-DOS, I was loocking
for the manuals describing the interface of the OS for years! They
were included in CP/M, but were missing in MS-DOS. I finally gave up
and til today I did not find those manuals.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Fri, 25 Feb 2000 18:22:36 +0100
Albert Ulmer <[EMAIL PROTECTED]> writes:
>Mario Klebsch wrote:
>> Well, that probably would be Debian GNU/Linux, and there is RatHad,
>> SUSE, Caldera,... They all claim to be Linux, but in fact are
>> different OSes.
>Nonsense, they all cater the diverse needs of various users. In my view
>that's the main point about the whole open source movement: CHOICE! It
>is good to be different!
But not the ABI! A common ABI is required to have binary
distributions. One can argue about them, and I always prefer a source
duistribution, but binary distributions are there and they are making
trouble, unnessesary trouble, if there would be a well defined ABI.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Fri, 25 Feb 2000 18:34:33 +0100
Albert Ulmer <[EMAIL PROTECTED]> writes:
>Mario Klebsch wrote:
>> >If your talking about an operating system,
>> >you should be calling it GNU/Linux, like i.e. Debian does.
>
>> Well, that probably would be Debian GNU/Linux, and there is RatHad,
>> SUSE, Caldera,... They all claim to be Linux, but in fact are
>> different OSes.
>Nonsense, they all cater the diverse needs of various users. In my view
>that's the main point about the whole open source movement: CHOICE! It
>is good to be different!
The absence of the ABI destroys the choice. If you are not running
RedHat or SUSE Linux, you really are in trouble, today. However, the
degree of trouble varies from distribution to distribution.
If we want to keep the choice, we'd better create a well defined ABI
yesterday!
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Mario Klebsch)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.setup
Subject: Re: Binary compatibility: what kind of crack are they smoking?
Date: Fri, 25 Feb 2000 18:30:05 +0100
Kari Pahula <[EMAIL PROTECTED]> writes:
>In comp.os.linux.development.system Mario Klebsch <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Donovan Rebbechi) writes:
>>>Binary only software should ship with all the required shared libraries.
>>The key word here is SHOULD. Linux should include an ABI, but it does
>>not. Binaries should be shipped with all required libraries, but they
>>are not. :-(
>Either way, the user is always able to compile the>programs herself.
So, please tell me, how can I recompile my applix office suite, the
Adabas-D database or acroread? I tried my best, but I was not able to
find the source code.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
** 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
******************************
