Linux-Development-Sys Digest #698, Volume #6 Mon, 10 May 99 17:14:45 EDT
Contents:
Re: /dev/hda1 has reached maximal mount count, check forced (Mark Tranchant)
Re: 3D Graphics Speed in Linux (Mike Harrison)
Re: Glibc rant ("Gerry S. Hayes")
Re: Reliable (!) nic for 2.2 kernel? (bryan)
Re: Reliable (!) nic for 2.2 kernel? (bryan)
Re: Failed building glibc-2.1.1pre2, please help ([EMAIL PROTECTED])
How to config SOCKS5 server on Redhat to work with ICQ ("Ju")
MCL_FUTURE and mlockall() ("Vladimir G. Stanishev")
Re: Translation of linux to minor languages ("Jürgen Exner")
Re: KDE without gif support (Roope Anttinen)
----------------------------------------------------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: /dev/hda1 has reached maximal mount count, check forced
Date: Mon, 10 May 1999 15:01:43 +0100
Reply-To: [EMAIL PROTECTED]
The time threshold gives a different message, as I found out when
checking my home PC's BIOS for Y2K compatibility.
Mark.
Ishikawa,Chiaki,remove No Spam from the address wrote:
>
> > I know of no other UNIX doing this.
>
> If I recall correctly, Digtal UNIX on MIPS platform such as ds5200
> did this.
>
> I think the trigger for fsck was
> - either the max count reached, or
> - some pre-determined elapsed time since last fsck was reached.
>
> But it was 5 or 6 years ago that I used the machine and so my memory
> is hazy.
>
> --
> Ishikawa, Chiaki [EMAIL PROTECTED] or
> (family name, given name) [EMAIL PROTECTED]
> Personal Media Corp. ** Remove .NoSpam at the end before use **
> Shinagawa, Tokyo, Japan 142-0051
------------------------------
From: [EMAIL PROTECTED] (Mike Harrison)
Subject: Re: 3D Graphics Speed in Linux
Date: 10 May 1999 18:03:25 GMT
You should check out the discussion about this on slashdot.com
http://slashdot.org/articles/99/05/01/1624205.shtml
There is a discussion about this very topic.
michael
: Well XFree86-4.0 will support 3D hardware via a X-extension. As a frontend
: OpenGL will be used. (In general there is no reason why X should be concidered
: slower then i.e. Windows. A command/data pipe is not slower in general then
: sync. library calles from different tasks.)
: Bye,
: Aurel Balmosan.
------------------------------
From: "Gerry S. Hayes" <[EMAIL PROTECTED]>
Subject: Re: Glibc rant
Date: Mon, 10 May 1999 10:25:22 -0400
[I had a long point-by-point discussion, but I've snipped it down
to some core points; apologies if I lost something you think is
important]
Mark Shinwell wrote:
> I think we are confusing terms here; I was thinking of the development
> release as one which has actually been packaged up nicely, and
> released as if it were a release version (up to delving in the readme,
> or whatever)
The release notes specifically stated that it was not a production
stable release. IMO it's like the pre-2.2 linux kernels -- it's meant
for wider testing than the true hackers-only 2.1.x kernel series, but
it's still understood that nothing is final yet.
You need to have these sorts of wider-release betas in order to catch
problems that may not show up on the developer's machines and to get
user feedback. The problem in this case, IMO, was that a lot of people
didn't know that glibc 2.0 was a test release. In all probability, most
of the upgrade-by-hand people did know this -- it's plastered throughout
the FAQ and README, and in any case if you upgrade by hand and don't
read the release notes or README then you don't deserve any sympathy.
The folks who use distributions like Red Hat and Debian may not have.
That's the fault of Red Hat and Debian -- the people who packaged up
glibc as rpms and debs either new that it was a devel release or
were incomprehensibly negligent. People like StarOffice may not have
even known that when they built it on Red Hat 5.0 (or whatever
platform) that they were using a beta glibc. It's exactly that problem
that leads them to release "StarOffice for Red Hat 5.0" rather than
Star Office for Linux. The question becomes, what can we do to
improve things... (continued below)
> Yes, this leads to "cruft build-up", but it is better than
> breaking binary compatibility.
I think it's a trade off. The best way to handle things is to
accumulate cruft as needed to maintain downward compatiblity, attempt
to keep the cruft well-documented, and jettison the cruft every 4 years
or so or when it becomes necessary for some strong reason. When you
do jettision the cruft, bump the major version number and keep the old
shared libraries. Really, there's no reason that Red Hat couldn't be*
shipping with libc4a.out, libc5, and glibc2 binary support. The
problems come when the ABI breaks without bumping the major (as it did
during libc5, causing all kinds of libnetscape_broken_malloc libraries
and similar to be dispatched, and as it did with glibc2.0->2.1).
Hopefully, the symbol versioning in glibc will allow these sorts of
updates without needing entirely different major library versions.
*For all I know, they are. I know they have libc5 shared libs, but I
don't know if they still ship libc4/a.out libs and a.out kernel support
or not.
> And it would encourage more rigorous
> specification in the first place to try to avoid some of the problems.
Again, we come to the question of how to create a perfect specification
the first time around -- developing a workable specification is an
important part of the development cycle, and in an open-source model
it tends to be highly iterative.
I think that we'd be much better served developing APIs and ABIs that
are versioned and updateable (like symbol versioning is supposed to do
-- who knows if it'll work or not) than trying to mandate perfect
designs from day one.
> Forgive me for quoting a passage from earlier in this thread:
>
> > > >My point is that when you're talking about a system library,
> > > >a change should NEVER be the proximal cause of apps breaking.
> > > >It's not a matter of whose fault it is, or who did what with
> > > >the library that they weren't supposed to, etc.
Well, I would agree that a change in a _released_ system library
should never break apps that use the published ABI. Those two
qualifications are apparently where we disagree, and that's a matter
of where to draw the line. I assume that you would have no problems
with breaking an application that opens the C library, seeks to the
locations where it knows printf is (as an absolute offset), and
executes whatever it finds there. In my opinion, using an internal
symbol that isn't documented or intended for external use is just as
broken and apps that do it deserve to die. However, if an application
written to the published API and compiled and linked normally brings
in a symbol, then you have to consider that symbol to be fair game
and support it in a downward compatible way. released/not-released
arguments about glibc2.0 aside, StarOffice (e.g) fits in one of those
two categories, but I don't know which.
And we appear to agree that changes in the midst of a "real"
development cycle (where "real" is undefined for the nonce) are fine.
> Of course not, what I was suggesting is that perhaps someone should
> have spotted that Red Hat (and others - I notice Debian has 2.0.7)
> were using development versions at the testing stage of the
> distribution (sorry, I didn't imply that before) and brought it to
> their attention. Although it escapes me why such versions were ever
> shipped with distributions in the first place.
Ah, yes, and this is the crux of the matter. I'd first and foremost
say that full responsibility for what is in a particular distribution
falls upon the shoulders of the distribution makers. If they use
a glibc release that the glibc developers have said isn't a stable
production release, it's their own damned fault.
Having said that, it would probably be a good thing to waive big
warning signs at Red Hat and Debian if you hear that they're planning to
deploy an unstable libc (or other library or tool with a defined API or
ABI). Clearly in Red Hat's case, their view of the market was that
releasing a glibc 2.0 version was good. Yelling in public might make
the market more reluctant to buy, might make people other than the glibc
packager at Red Hat aware of the issues, or might just be a good heads
up saying "hey, this is a devel release, we're serious about that, and
we already _know_ of problems x, y, and z that are going to force us
to change the ABI in the final release".
> "G. Sumner Hayes" wrote:
> > You seem to think that binary compatibility is the sine qua non of
> > system development
[Actually, I wrote something else. This is version 1.1 of my sentence,
where "sina quo non" has been replaced with "sine qua non" to improve
compliance with ISO-8859-0, the Latin 0 standard. I hope the change
doesn't disrupt people relying on the content of the sentence.]
> No, it may be ideal but it obviously can't always be achieved.
> However, unless a really major change is planned, and people have been
> warned that there will be problems - such as Solaris from SunOS - then
> I think it should be strived for.
Agreed.
--Sumner
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Crossposted-To: comp.os.linux.networking
Date: Mon, 10 May 1999 18:16:52 GMT
if its been up THAT long, then it CANT be running 2.2 kernel. read
the subject line of this posting. I agree that 2.0.36 is rock solid
with tulips.
In comp.os.linux.networking Roope Anttinen <[EMAIL PROTECTED]> wrote:
: In comp.os.linux.development.system bryan <[EMAIL PROTECTED]> wrote:
: > my tulip card is totally unreliable. I can bring it down with an ftp
: > xfer (local lan) at 10 or 100, in a minute or less. network hangs and
: > will NOT be reset by software.
: That's weird. One of the servers I administer has a tulip card and the
: server has been up now for 178 days without any problems. Here's some
: numbers:
: RX packets:104749300 errors:0 dropped:13 overruns:0
: TX packets:71530160 errors:4 dropped:0 overruns:4
: cat /proc/pci reports the card as DEC DC21140 (rev 32).
: Roope
:
: --
: MicroSoft? is that some kind of a toilet paper?
: PS: Look for address here, not from headers. And remove NOSPAM's
: ___________________________________________________________________________
: [EMAIL PROTECTED] / [EMAIL PROTECTED]
: +358 9 812 7567 / +358 500 445 565 / +358 49 445 565
: http://myy.helia.fi/~anttiner/index.html
: ---------------------------------------------------------------------------
: Helsinki Business Polytechnic - Institute of information technology
--
Bryan
------------------------------
From: bryan <[EMAIL PROTECTED]>
Subject: Re: Reliable (!) nic for 2.2 kernel?
Crossposted-To: comp.os.linux.networking
Date: Mon, 10 May 1999 18:16:16 GMT
In comp.os.linux.networking Johan Kullstam <[EMAIL PROTECTED]> wrote:
: bryan <[EMAIL PROTECTED]> writes:
: > its totally repeatable. I wonder if its my SMP that is throwing a
: > monkey wrench into the works? is anyone happy with their tulip in
: > 2.2.7 AND smp??
: i am happy. i have a dec tulip 21140 card in a quad ppro box and it
: seems fine. i use tulip driver v89h (what comes with linux 2.[12].x
: kernels) and have tried v90 as well. i have run big ftp jobs (100's
: of Mb) to move data back and forth between it and my other machine. i
: have a 100Mbps setup through a little 4 port hub. i've got two more
: dec tulips in my uniprocessor box. one 10Mbps 21041 and one 21140.
: i can't recall the minor rev letter/numbers at this time.
: what tests would you have me perform to inflict maximum punishment
: upon these ethercard?
connect two systems with same driver/kernel and a crossover-cable (NO
hub - we want wire-speed (as close as possible) with no delays or
buffering).
ping-flood the system:
# ping -s 1000 -f <target>
1000-byte frames flooded (back-to-back). you should see "." chars and
backspaces as the packet goes out and is acked.
under ideal conditions, each dot will get a backspace, so the line
should not grow across the screen. on my system, it takes a few
seconds for the dots to outnumber the backspaces, meaning packet loss.
then, give it another minute or so and the xmitter or receiver will
lock up and not even a single slow ping will go thru.
--
Bryan
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Failed building glibc-2.1.1pre2, please help
Date: Mon, 10 May 1999 16:31:54 GMT
In article <7h3rt7$5t6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Now I have successfully built it but not installed yet.
And problems continue - after installation EGCS/PGCC and binutils
configure scripts refuse to determine host system type. I checked
config.guess and found the exact place of problem - tiny program
which tries to determine version of glibc. It uses extern __libc_release
and __libc_version and these symbols are undefined when I try to
compile the program. They must be defined in csu/version.c in glibc's
source tree. Could anybody tell, what's wrong now?
Thank you,
Laurynas Biveinis
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
From: "Ju" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.admin,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup
Subject: How to config SOCKS5 server on Redhat to work with ICQ
Date: Mon, 10 May 1999 11:03:44 +0700
I want to setup SOCKS5 server on Linux for ICQ client. I've config
/etc/socks5.conf like this.
set SOCKS5_MAXCHILD 3
set SOCKS5_NOIDENT
set SOCKS5_TIMEOUT 5
interface permithost - eth0
auth permithost - -
permit - - permithost - - - -
deny - - - - - - -
permithost is a Unix dial server host. It use SLIRP. Then all user dial in
to this server'll have same IP,right?
When I finished this and try socks5 -f -s. It seem to work. I try to use
ICQ. And it connect to this Linux Server.... There's some message appear on
terminal screen. But ICQ tell me that "Can't connect to 202......blah blah
blah(sorry I can't remember)"
I think my Linux server can connect to icq.mirabilis.com for sure......
But I don't sure about my configuration. Linux server has 2 LAN card. It's
acting like firewall for some other computer(that's not permithost). Please
tell me what's wrong..... Thanks
Ju
------------------------------
From: "Vladimir G. Stanishev" <[EMAIL PROTECTED]>
Subject: MCL_FUTURE and mlockall()
Date: Mon, 10 May 1999 16:51:05 +0100
I am writing an overview paper on linux and I realize that I am running
out of time. I've been trying to understand how some of the features
are implemented by looking at the source but that takes too long for
me. I understand most of the concepts but I find following the code
rather difficult, so I'll start posting some questions here. If anyone
can help, thank you.
this first question is about mlockall() and the MCL_FUTURE parameter.
The O'reilly book on POSIX.4 describes some of the things that can
happen when the future memory cannot be locked, because the system's out
of memory say. A "nice" system would cause a memory allocation attempt
to fail if the memory couldn't be locked, a not so nice nice system
might send a signal to the process, and a nasty system would perform the
allocation but would not lock the memory down. How is mlockall()
implemented in Linux, is it a "nice" or a nasty system?
:-)
Vladimir
------------------------------
From: "Jürgen Exner" <[EMAIL PROTECTED]>
Subject: Re: Translation of linux to minor languages
Date: Mon, 10 May 1999 13:43:04 -0700
Reply-To: "Jürgen Exner" <[EMAIL PROTECTED]>
Frank v Waveren <[EMAIL PROTECTED]> wrote in message
news:psaZ2.7923$pi1.2620@amsnews...
> due to the GPL nature of most linux apps, it shouldn't be to hard to
change
> all strings in sources and data files... How long this would take depends
on the
> amount of text in the application.
>
> This is of course assuming that
>
> a) you don't use translations that are to long to fit in buffers or in
> precisely measured out screen decorations
>
> b) the program is written neatly.
I am in the software localization business for 3 years now.
Believe me, if a program has not been written with localization in mind from
the very beginning, then a localization is almost as difficult as a complete
rewrite from scratch (although you will have the advantage to know how to
solve the coding problems).
Replacing just the strings in the code has been done 10-15 years ago and has
been proven to be far to expensive, diffcult, and error prone. How do you
know, if the string "Item" shows up in the user interface as a menu item or
is an internal name for a protocol between two components and if you
translate it, it will break everything? Just finding out is almost as
difficult as re-engineering.
Just a few examples:
- dialog resizing is required and takes over 60% of the actual work,
provided you have a good WYSIWYG tool to help you. (the suggestion to use
strings, which are no longer then the EN string doesn't work, don't even
consider it).
- text pieces, which are combined at runtime are a nightmare: "The xxxx
could not be xxxx, because xxxx" can not be translated, because you are
combining e.g. Russian text fragments using English grammar.
- How do you translate directory and file names? You don't? Well, what if
they appear in the UI?
- does passwd accepts Japanese or cyrillic characters (or simply say latin
characters, which are not used in English) as password and/or login name?
Ooops, that means cyrillic and Japanese directory names in /home. Can "ls"
deal with them? And can they be found by e.g. a "find -name"?
And for UNIX you have the additional problem that the output of command line
commands is often used as the input for the next command in a pipe. So if
you translate the output of let's say "ls", then you have to re-engineer all
programs, which possibly read the output of ls and take it as their input.
Sure, it's open software, so it can be done.
But you should expect it to take years (and you will need a team of
experienced experts, otherwise you will repeat all the mistakes made in
software localization in the last 15 years).
jue
--
Jürgen Exner
------------------------------
From: Roope Anttinen <[EMAIL PROTECTED]>
Subject: Re: KDE without gif support
Date: 8 May 1999 18:20:31 GMT
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> Roope Anttinen <[EMAIL PROTECTED]> wrote:
> > You probably have qt > 1.43 ? Due to gif patent issues qt-1.44 has disabled
> > gif support.
> Ahh.. yes, I use 1.44 here. Any suggestions to include it anyway?
I haven't tried it but I've heard in KDE mailing lists that there are some
kind of #define you have to do in qt sources to get gif support compiled in.
Take a look at README's
Roope
--
MicroSoft? is that some kind of a toilet paper?
PS: Look for address here, not from headers. And remove NOSPAM's
___________________________________________________________________________
[EMAIL PROTECTED] / [EMAIL PROTECTED]
+358 9 812 7567 / +358 500 445 565 / +358 49 445 565
http://myy.helia.fi/~anttiner/index.html
===========================================================================
Helsinki Business Polytechnic - Institute of information technology
------------------------------
** 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
******************************
