a wider question than just messages. Anyone got such an
idea?
Paul Kaufman
paul.kaufman@veTo: [EMAIL PROTECTED]
rizon.com cc:
Sent by: Linux Subject: Re: Messages Manual
:[EMAIL PROTECTED]]
Sent: Monday, February 04, 2002 2:13 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
I am not sure it is that is not warranted, rather that the code comes from
such disparate places that it would be logistically very difficult to
collate and maintain. At least with a single
On Monday, 02/04/2002 at 09:47 EST, Norman Bollinger
[EMAIL PROTECTED] wrote:
Its a matter of programmer discipline and management follow through.
When I
write a message I know
why I am writing it and what it means. It only takes a minite or two to
document that at that moment. If my boss
distributors (RedHat, Suse etc) do write documentation, but not to the
level you are asking for. There is also the Linux Documentation Project,
which I am sure would welcome your contributions.
And the free software foundation likewise
had messages and codes manuals. Our experiences are
[EMAIL PROTECTED] said:
Man is for commands, not the kernel.
BOOTPARAM(7)Linux Programmer's ManualBOOTPARAM(7)
NAME
bootparam - Introduction to boot time parameters of the
Linux kernel
man is for manpages. Anyone including a kernel hacker can write man
products
that run there.
Mark Post
-Original Message-
From: Nick Gimbrone [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
That's going to be pretty tough to do for Linux/390 shops, unless they're
allowed to maim
Please remove me from your mailing list. Thank You.
-Original Message-
From: Post, Mark K [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 9:15 AM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
Nick,
I understand the reasons for auditors (having been involved in audit
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: Messages Manual
R 00,CLPA,APF=02,LNK=45
I can see why you need a manual 8)
While even VM has some messages that are as cryptic as that MVS style
message,
there has been a trend in recent (past 8+ years) versions of VM to make new
I understand the reasons for auditors (having been involved in audit
compliance myself for a while). I wasn't talking about any shortcomings
in the software.
As I understand it you are saying that if the message isn't documented and isn't
understandable then you get to read the source to
Sweet Dreams!
Dennis
Ward, Garry [EMAIL PROTECTED]@VM.MARIST.EDU on 01/31/2002 11:04:42
AM
Please respond to Linux on 390 Port [EMAIL PROTECTED]
Sent by: Linux on 390 Port [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: Messages Manual
Securing source so that only
, January 31, 2002 1:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
I understand the reasons for auditors (having been involved in audit
compliance myself for a while). I wasn't talking about any shortcomings
in the software.
As I understand it you are saying that if the message isn't
That's going to be pretty tough to do for Linux/390 shops, unless they're
allowed to maim their operators by blinding them. :) Not something I woul
d
recommend, in any case. I think auditors are going to have to change their
mindset a little in this area.
Auditors exist for business
Greetings;
For all practical purposes securing source so that only authorized
people can modify it is for all practical purposes the same as
denying all source to everyone. At least for all the open source
software that you use.
For the vast majority of things that execute on your system
code.
- Original Message -
From: Nick Gimbrone [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 31, 2002 5:03 PM
Subject: Re: Messages Manual
Oh, come on Nick. How are you going to prevent any operations staff
with the inclination either downloading the source code
[EMAIL PROTECTED] said:
So, given that _all_ employees of an enterprise are going to have
access to the source of your operating system, and a lot of the other
software that runs on it, the people responsible for those systems
cannot hope for security through obscurity. They will have to
Is there a messages manual for Linux? In going back through the archives,
I see a lively discussion on this subject in 2000. But I have not fund
much since then. Our automation and production support groups are
concerned about the lack of a messages manual. So far, it looks like the
only
Is there a messages manual for Linux? In going back through the archives,
I see a lively discussion on this subject in 2000. But I have not fund
much since then. Our automation and production support groups are
concerned about the lack of a messages manual. So far, it looks like the
only
]]
Sent: Wednesday, January 30, 2002 9:57 AM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
Is there a messages manual for Linux? In going back through the archives,
I see a lively discussion on this subject in 2000. But I have not fund
much since then. Our automation and production support
]
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 11:57 AM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
Is there a messages manual for Linux? In going back through the archives,
I see a lively discussion on this subject in 2000. But I
. When you
have x,000 developers writing programs that wind up running on your system,
the problem gets a little unmanageable.
Mark Post
-Original Message-
From: Paul Kaufman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 11:05 AM
To: [EMAIL PROTECTED]
Subject: Messages Manual
On Wed, 2002-01-30 at 11:57, Alan Cox wrote:
Is there a messages manual for Linux?
Question: What is a messages manual, what does it achieve ?
If Alan Cox doesn't know what a messages manual is, then it's a pretty
sure bet that Linux doesn't have one.
Alan, in the IBM m/f world all messages
Messages and Codes manuals are used to explain in greater detail
what a
message means and what response to take. In the mainframe world we
don't
just have messages (i.e. random text that may or may not mean
something
useful) - we also have codes - ever message has a unique code that
identifies
-
From: Phil Payne [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 12:16 PM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
-snip-
Of course, there are other issues. In enterprise environments code
and operations are separated for audit and control reasons.
I have to say I've wished several times that there was a central
location for message documentation in Linux. Kernel panic? Segfault?
Modprobe diagnostics? I recompiled a kernel and started getting silly
diagnostics about a system map whenever I ran ps. Took me awhile to
figure out,
Alan Cox [EMAIL PROTECTED] writes:
Question: What is a messages manual, what does it achieve ?
Mainframe folks are used to the idea that every distinct message
a program issues has a message identifier as its first token.
These message ids allow you to look the message up in a reference
manual
Another thing you get is automation support. Once you can
recognize specific messages, you can respond to their appearance.
Mainframe systems have lots of software options for analyzing
system message streams (data similar to klogd's and syslogd's),
and for initiating actions based on that
Alan Cox [EMAIL PROTECTED] writes:
Ok now that bit does have an equivalent in its own unix
think. Unix programs
make heavy use of error codes when they exit. Thus you'll find the man
pages fairly religiously document the error codes on exit
That's the same in mainframe environments too
Adam Thornton [EMAIL PROTECTED] said:
And, besides, it's the wrong direction.
What *is* needed is a lightweight, open API for network-aware message
reporting (ARM correlators, for instance), and a strong push to get
a bunch deleted
Now if you want to collect this data and parse it into
Is there a messages manual for Linux? In going back through the archives,
I see a lively discussion on this subject in 2000. But I have not fund
much since then. Our automation and production support groups are
concerned about the lack of a messages manual. So far, it looks like
I have to say I've wished several times that there was a central
location for message documentation in Linux. Kernel panic? Segfault?
Modprobe diagnostics? I recompiled a kernel and started getting silly
diagnostics about a system map whenever I ran ps. Took me awhile to
figure out,
but you might make other choices. I think these are valid, no matter if
they're not, they illustrate the point:
R 00,CLPA,APF=02,LNK=45
I can see why you need a manual 8)
Oh, and there's no nonsense about printers catching fire. All messages
are pertinent to the problem at hand.
Believe
31 matches
Mail list logo
