[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
pag
> 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 ar
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 bos
;Ward, Garry"
cc:
Sent by: Linux Subject: Re: Messages Manual
on 390 Port
<[EMAIL PROTECTED]
ARIST.EDU>
02/04/02 02:41
[EMAIL PROTECTED] wrote:
> 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 vendor changes are managed,
> and so documentation updates are controllable.
David Goodenough <[EMAIL PROTECTED]> writes:
>At least with a single vendor changes
> are managed,
> and so documentation updates are controllable. This does
> make it a bad
> thing to want to do, just a very difficult one.
My experience is exactly opposite to this. The
to:[EMAIL PROTECTED]]
> Sent: Monday, February 04, 2002 9:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Messages Manual
>
>
> 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 ta
> Idea from the VSE world: IESMSGS & Explain function. Part of the VSE systems
> itself, but each vendor has the ability to add to the IESMSGS file, if they
> follow the rules for message format and use the utility functions for adding
> message.
>
> In the Linux world, doesn't the MAN function pe
D]
Subject: Re: Messages Manual
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 allows me to skip the
documentation at that time th
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 allows me to skip the
documentation at that time then we both have failed. But if he c
Goodenough [mailto:[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
I don't think I've seen anyone on this list pushing the position that a
Linux messages manual is "unwarranted." I and others have said that it
would be very difficult to create and keep updated, given the nature of the
development environment. I haven't seen anyo
a wider question than just messages. Anyone got such an
idea?
Paul Kaufman
cc:
Sent by: Linux Subject: Re: Messages Manual
on 390 Port
<[EMAIL PROTEC
[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
YSABEND dump -- without source
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 st
> 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
> > 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 is
> n't
> understandable then you get to read t
> Oh, come on Nick. How are you going to prevent any operations staff
> with the inclination either downloading the source code to Linux in
> their one time on their own equipment?
I never spoke about prohibit, the question is one of what an auditor does. They
are advisors. It is reasonable for t
> Well, more readable but still sometimes nearly useless!
>
> There are still too many messages that say
>
> contact your system programmer
>
> Yeah, that's me, and I don't know what to do either!
Ah, the joys of being a beginner OS/2 user, at home, alone, especially when Warp
Connect came
> > 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
Gimbrone [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 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"
&
t know it ... yet!)
Good Luck &
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]
> 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
businesses rely on for the daily
operations.
-Original Message-
From: Post, Mark K [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 11:15 AM
To: [EMAIL PROTECTED]
Subject: Re: Messages Manual
Nick,
I understand the reasons for auditors (having been involved in audit
compliance my
<[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[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
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
the Open Source 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
> > 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
messages actually be readable... now, it doesn't always work, but on the w
> 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 would
> recommend, in any case. I think auditors are going to have to change their
> mindset a little in this area.
Auditors exist for business reas
> > 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 pro
> 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.
B
> > 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
> >
> > 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 m
[EMAIL PROTECTED] wrote:
> Adam Thornton <[EMAIL PROTECTED]> said:
> > Now if you want to collect this data and parse it into human-readable
> > reports (or a display on a monitoring app like OpenView or Tivoli or
> > CiscoWorks...), that's another good use of it; but much better (IMHO) to
> > let
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
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
> 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 t
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
Alan Cox <[EMAIL PROTECTED]> writes:
> It would be a good project to add explanations to the kernel errors. The
> challenge (this is one for the perl hackers I guess) is to write a tool
> which can extract the printk/panic and a suitably marked up comment
> following it and output them into a docu
> wouldn't think of running an Enterprise on anything LESS. I've heard =
> time
> and time and time and time again that documentation is NOT necessary =
> for
> Linux because you can always "read the source"! So next time one of =
Thats not quite true. There is indeed a unix critique that rough
> 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
al Message-
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.
> 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
identif
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 on
L PROTECTED]
Subject: 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 groups are
concerned about the lack of a messages manual.
on, D.C. 20224
Voice: (202) 927-4188 FAX: (202) 622-6726
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
-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 mes
>> 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
PROTECTED]]
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 automa
> 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 lo
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
50 matches
Mail list logo
