Linux-Development-Sys Digest #309, Volume #6 Wed, 20 Jan 99 06:14:13 EST
Contents:
Re: how to get cpu usage, not over top (Bob Tinsley)
Re: disheartened gnome developer ([EMAIL PROTECTED])
Re: 2038 and Linux (Bloody Viking)
Re: WDM Emulator, anyone? ([EMAIL PROTECTED])
Re: poll in a Kernel Driver every second (H. Peter Anvin)
Re: iso9660: time-stamp mismatch/bug? (Villy Kruse)
Non-*nix OS built on linux kernel? ("Sam Robb")
Re: Linux Phase 2: A Consumer Operating System (Christopher Browne)
Re: Linux Sound Engine (Ross Vandegrift)
Re: SysV vs. BSD ps Re: - deprecated - why? (Matthew Hannigan)
----------------------------------------------------------------------------
From: Bob Tinsley <[EMAIL PROTECTED]>
Subject: Re: how to get cpu usage, not over top
Date: Tue, 19 Jan 1999 23:36:45 +0000
Frodo Looijaard wrote:
>
> In <781jkt$hfk$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
> >Hello,
>
> >How can I get the CPU usage. Top isn't good for the job because I can't
> >terminate it from stdin or sterr. It should like w or ps aux. But the Resault
> >isn't so good or I dont know how can I extract it. I've wrote a script that
> >read ps aux, split it and than it show me the CPU usage.I add all values but
> >the resault was not 99% separate it was 200%. I think that's not true.
>
> cat /proc/loadavg
Or, more portably, try vmstat (or sar -- I could have sworn that
my old SlackWare system had sar, but current Red Hat seems to be
lacking...)
Cheers,
-- Bob
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Mon, 18 Jan 1999 15:39:04 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Fri, 15 Jan 1999 16:55:09 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> posted:
> >In article <77h02o$bg6$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >> On Sat, 09 Jan 1999 14:48:45 GMT, [EMAIL PROTECTED]
> >> <[EMAIL PROTECTED]> wrote:
> >> >Red Hat does own the code they create, just like Troll Tech and Microsoft.
> >> >That you have a copy of it under the GPL doesn't mean they can't later
> >> >re-release it under a proprietary license.
> >>
> >> Technically, that's true.
> >>
> >> Unfortunately for such a release, they cannot "de-release" the software
> >> already released under the GPL, which means that the software that they
> >> have written will continue to be freely available (barring *bizarre*
> >> events) and could be maintained, moving forward by others.
> >
> >Sure. Technically :-)
> >Then again, usually when a program with a low "cool factor" like, say,
> >a Tk front end to network configuration gets fropped it often just stays
> >dropped. Even high profile projects like the GIMP had a rough season
> >after the original maintainers dropped it (things a re better now,
thankfully)
>
> Indeed. If nobody cares about the software, if some "catastrophe" strikes,
> no one will notice.
It is very possible that many people care and notice, and still they can't
take it over. Like in the GIMP example. People who use it are mostly not
programmers.
> Red Hat "dropped" some Python/Tk configuration tools, in favor of
> supporting Linuxconf; that happened with barely a whimper, as nobody
> really cared very much, or was terribly inconvenienced by the "loss."
> I have a hard time caring, myself. There are better things to expend
> emotional energy on.
Sure. But that's not dropping, it's replacing.
We were discussing things like "Red Hat goes propietary". In that case,
you don't get linuxconf, you get the old Python/Tk tools and no maintainer.
> >> Troll Tech has a legal arrangement whereby if "disaster strikes," a
> >> scenario similar to the above is invoked. Red Hat has already invoked
> >> the "disaster clause."
> >
> >Not exactly, since the result of that "disaster clause" is not the
> >release under the GPL of the software in Troll tech's case.
>
> A *precise* parallel? No.
>
> Relatively similar? I'd think so. The GPL and BSDL have different
> sorts of restrictiveness; both are commonly regarded as representing
> "free" software. Albeit with some noisy dissenters.
The GPL is "free with strings attached" BSDL is free.
Some people don't care about the strings, some people like the strings, but
there are strings :-)
--
Roberto Alsina (KDE developer, MFCH)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Bloody Viking <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.advocacy,comp.software.year-2000
Subject: Re: 2038 and Linux
Date: 20 Jan 1999 07:06:45 GMT
In comp.os.linux.advocacy Christopher B. Browne <[EMAIL PROTECTED]> wrote:
: Nope. This doesn't cope well with the fact that one of the most major
: places where date stamps of the form time_t are used is for time stamps in
: filesystems.
All the files would after Y2K+38 have wierd-arse dates. One problem is
archiving and purging. This is why backdating is not "elegant".
: Bonus points for the consideration that if /etc/backdate gets nuked, this
: affects dates on other partitions that weren't touched.
Yes, it's a problem. You would basically have files with random dates
after a while. All the apps would have to add a header in the file format
for the backdate so your archiver app knows what's what. That'll get ugly.
: This is *not* a good answer.
Agreed. But 40 years from now, I may well do it if we are still using 32
bit CPUs. This illustrates the complexity of the problem.
:>Method 2: Unsugning time_t. Time_t is a signed integer. You could make it
:>unsigned at least in theory. Anyone try this? An alternative is to make it
:>a double, a floating point double, etc. Slows the system, but nicer than
:>backdating. An unsigned integer only delays the inevitable of having to
:>backdate by some long time.
: This means that you can't represent dates before 1970. My birthday
: disappears. Oops.
So does mine. Ironically, my birth year is Y2K-38! Not a good solution for
historians!
:>Method 3: A perpetual calendar routine. The years repeat themselves every
:>400 years in the Gregorian pattern. You could use Y2K as a reference date
:>and design a routine that backdates as above, but backdates funny at
:>Y2.1K, Y2.2K, and Y2.3K then at Y2.4K reverts to Y2K. Of course, you need
:>that goofy /etc/backdate file to remember the config for apps to use.
:>Again, you can use a goofy cron job.
: Definitely sounds goofy.
At least I admit it's goofy. Plus it has the other backdating problems you
outlined - only worse.
:>Method 4: Use a DEC Alpha or other 64 bit CPU. :) For those of you who
:>have the money, this is the best solution. Those of us on low budgets,
:>it's time to impliment the backdating crap.
: Method 5: The *right* answer is to do the remediation via standardization
: (in C9X) of the representation of 64 bit values. These days, the
: "nonstandard but common" approach is for "long long" to be 64 bits.
: Apparently behaviour is to be standardized in C9X.
: Given standardized behaviour of the data type, we can then have GLIBC use a
: 64 bit value as its time_t, and hopefully fairly rapidly thereafter get that
: functionality to integrate into libraries and filesystems.
: Note that this might also provide a natural route to solution of the "large
: files problem."
: Unlike the other solutions, this *isn't* a "hack." If we can cope with the
: ambiguity until C gets fixed to specifically know 64 bits, then there's no
: need to have hacks that will cause the code to look unclean.
: As a wild prediction, I'll suggest the thought that Linux 2.4 is liable to
: be the point at which 2038 "compliance" should be sought.
Making C recognise 64 bit integers is the best solution. Making C do this
means just a compile. No wierd hacks like the backdate hack. The only hack
needed is in the compiler's code. Even if you did this and PCs were still
in use, look out. There's only one century bit. Guess what that means. The
hardware becomes the problem come Y2.1K. This means that the kernel would
have to backdate and remember where it is in time by /etc/backdate or a
backdate memory card of some kind. It would be trivial to build a backdate
card that'll outlast the 64 bit integer. A backdate card with only 256
bytes of nonvolitile RAM would outlast the universe. :)
--
CAUTION: Email Spam Killer in use. Leave this line in your reply! 152680
T-minus 345 Days, 23 Hours, and 12 Minutes until Y2K and counting.
3434298 bytes of spam mail deleted. http://www.wwa.com/~nospam/
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Wed, 20 Jan 1999 08:22:38 GMT
I wrote:
> Try opening http://www.sid-dis.com/rectos . It is actually an attempt to
> implement a FreeNT (under GNU lic.): they wrote a lot of code in drivers area
> for now.
Lapsus calami! The exact URL of the ReactOS project is
http://www.sid-dis.com/reactos
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: poll in a Kernel Driver every second
Date: 20 Jan 1999 05:06:29 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED] (Dietmar Kling)
In newsgroup: comp.os.linux.development.system
>
> Hello,
>
> how can i check on a regular basis a certain Register of a piece of
> hardware and issue a kernel message then?
>
> Do I need to create a thread, or is there some 'official" way
> in Kernel (poll every 2 seconds would be enough)
>
One way is to hook into the timer interrupt bottom handler. It all
depends on what you need to do.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Subject: Re: iso9660: time-stamp mismatch/bug?
Date: 20 Jan 1999 09:43:51 +0100
In article <782t9d$2vt$[EMAIL PROTECTED]>,
Tony Silva <[EMAIL PROTECTED]> wrote:
>Does the Linux VFAT support not honor the timezone database symlink
>/etc/localtime and thus require the environment variable TZ instead,
>contrary to the strong wishes of the glibc folks? If so, may I be so
>bold as to suggest starting a dialog between the glibc folks and the
>Linux VFAT folks? The information below shows why I believe that the
>problems I'm seeing simply cannot be fixed by reconfiguration that I
>can do myself. I'm pretty sure I've read all of the relevant FAQs and
>man pages, too.
>
>
VFAT support runs entirely in the kernel and has thus no access to glibc
or the timezone handling implemented in glibc or libc5 for that matter.
What is needed is a small utility to set the *kernel* timezone, which is
(was) actually done in some distributionsm but currently not (yet) on
the redhat distribution. Could be this should be a function performed
by hwclock. Once the kernel tz variable is set VFAT will honour this
setting, and so will SMBfs and NCPfs; but not iso9660. The time zone for
iso9660 dates is included as part of the date fields. The interpretation
of this this time zone information is not done correctly, though.
> ....snip
>
> 4.3. When I set the timezone by setting the TZ environment variable
> to EST5EDT things go wrong since glibc computes the wrong time
> from this information.
>
> {UD} The problem is that people still use the braindamaged POSIX method to
> select the timezone using the TZ environment variable with a format EST5EDT
> or whatever. People, read the POSIX standard, the implemented behaviour is
> correct! What you see is in fact the result of the decisions made while
> POSIX.1 was created. We've only implemented the handling of TZ this way to
> be POSIX compliant. It is not really meant to be used.
>
> ...snip
If TZ is set it is supposed to point to one of the files in the directory
/usr/share/zoneinfo and for Eastern US time you can let it point to one of
the following files.
EST5EDT
posix/EST5EDT
posix/SystemV/EST5EDT
right/EST5EDT
right/SystemV/EST5EDT
SystemV/EST5EDT
Ofcourse you could let /etc/localtime be a symbolic link pointing to one
of these files too.
Villy
------------------------------
From: "Sam Robb" <[EMAIL PROTECTED]>
Subject: Non-*nix OS built on linux kernel?
Date: Tue, 19 Jan 1999 20:45:30 -0500
Just curious about this... are there any 'odd', special purpose, or
other (non-unixlike) OS's built on top of the Linux kernel, or any
similar offerings?
I know there are various special-purpose flavors of BSD & Linux
out there, but I'm more interested in finding out if anyone's ever
used the services provided by a Linux/BSD/whatever kernel
specifically to avoid hardware issues.
-Samrobb
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Linux Phase 2: A Consumer Operating System
Reply-To: [EMAIL PROTECTED]
Date: Wed, 20 Jan 1999 02:01:32 GMT
On Tue, 19 Jan 1999 01:09:59 -0800, Vihung Marathe
<[EMAIL PROTECTED]> wrote:
>Destrying Microsoft is not, cannot, and should not be a goal for any serious
>development effort, although it may indeed be a by-product.
>
>Linux is still in its infancy (this is a relative term - you are fee to contradict
>me on this point), and its current state is the direct result of the type of people
>developing on it and using it.
>
>The main goal (as defined by Linus) has been reached - to run a stable, reliable
>and high performance Unix-like system on Intel hardware.
>
>The main goal of the Open Source Movement will also naturally be fulfilled by Linux
>along with products like Apache - to minimise the cost of ownership for
>infrastructure products, and concentrate on gaining commercial benefits from
>providing services.
This neglects the consideration of Linux being an interesting platform
for people who want to learn about OSes to "play with."
That is where the community surrounding Linux came from, and even if
there are new purposes that get added in, the oldest and most
experienced Linux folk are not here because of "minimization of TCO of
infrastructure" or "commercial benefits from providing services."
>Making Linux into a consumer product has two major primary benefits
>
>1. It will expand the Linux platform by targeting a much larger audience
>(by a thousandfold? any guestimates?).
I'll go along with "thousandfold," so long as I can pull in the
(arguably) thousandfold increases in costs that go along with it.
If the Linux community "targets" those that neither understand nor want
to understand computers, this requires that there:
a) Be a clear "Linux community" doing the targeting. That's not the
case, as there's too much diversity for that.
b) Be someone paying the bills to design and deploy service offerings.
Note that if things change such that these changes really do take place,
this will make Linux a much less interesting platform for the people
that are interested in "playing with an OS" for its own sake.
With the result that many of the sorts of folk that made Linux grow into
what it has become are liable to migrate off to other systems that
permit them to "play" again. Whether that's Hurd, Xos, FluxOS, *BSD, or
whatever.
At that point, Linux starts to die. It may continue on for years, but
if the sources of innovation leave, that causes great injury.
--
The real problem with the the year 2000 is that there are too many zero
bits and that adversely affects the global bit density. -- Boyd Roberts
<[EMAIL PROTECTED]>
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/lsf.html>
------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Subject: Re: Linux Sound Engine
Date: Tue, 19 Jan 1999 21:35:41 -0500
Reply-To: [EMAIL PROTECTED]
> The kernel is absolutely no place for such a mixer, really.
I completely agree.
> It can be done almost totally in user-mode. You just write a kernel device
> which pipes data from /dev/leaf into for example /dev/leaf0-9 depending on
> how many processes have opened /dev/leaf. The user-land mixer has opened
> /dev/leaf0 to leaf9 before and is "listening" on those streams, mixing
> them, and writing them to the real /dev/dsp or whatever.
Exactly the kinda thing I was thinking.
> The kernel-mode code required for that wouldn't be much and isn't difficult
> to write.
That is good to hear. I have starte prototyping the user-space mixer.
Hopefully, by the end of the next week or two (mid-terms this week -
won't have too much time), I'll have a program that reads in x files
passed to it via the command line, mixes them, and outputs the result to
another file.
--
Ross Vandegrift | Eric J. Fenderson
alt.binaries.punk: for those of us too
punk to pay money for the music.
------------------------------
From: [EMAIL PROTECTED] (Matthew Hannigan)
Subject: Re: SysV vs. BSD ps Re: - deprecated - why?
Date: 20 Jan 1999 10:54:07 GMT
In article <781gok$elu$[EMAIL PROTECTED]>, Marc Slemko <[EMAIL PROTECTED]> wrote:
>In <77u4f8$1es$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Matthew Hannigan) writes:
>
>>In article <77ljr0$5sm$[EMAIL PROTECTED]>, Marc Slemko <[EMAIL PROTECTED]> wrote:
>>>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Timothy J. Lee)
>writes:
>>>
>>>>On Solaris, use /usr/ucb/ps to get BSD ps behavior.
>>>
>>>...and the sad part is, that /usr/ucb/ps is the _only_ way to do certain
>>>things on Solaris, ie. /usr/bin/ps can't do them.
>
>>Can you be more precise? What exactly can't you get?
>
>The most important for me is the 'w' flag, or 'ww', etc.
Yep, I can see that.
In return, I'll tell you what I like about sysv ps. The
-p option to specify a pid, the -u option to specify a user
and the fact that the everything option (-e) really does
give you everything, in contrast to the BSD ps which gives
your everything but 'interesting processes' and processes with
controlling terminals (can't remember which).
>>>>AIX ps without the - takes BSD options; with the - takes SysV
>>>>options. The man page on Linux ps seems to imply that Linux
>>>>ps will take that approach in the future.
>>>
>>>That is such a stupid solution that I was completely dumbfounded the
>>>first time I read that bit of the man page. Talk about confusing people
>>>who have committed the sin of ever using any other Unix.
>
>>Eh? It's a nice solution. We should be happy its possible.
>
>If you want to give people a way to choose which type of ps they
>want, then give them a way. There are lots of ways other than
>breaking people's fingers and going out of your way to be confusing.
Speaking for myself, when I used SunOS4 I didn't use the '-'
so its just dandy for me.
>And the obvious religious advocacy of requiring people who want
>a sane ps to set "I_WANT_A_BROKEN_PS" has no place. Broken is
>a pretty strong word for one person's preference.
Agreed.
--
-Matt
------------------------------
** 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
******************************
