Linux-Development-Sys Digest #886, Volume #6 Fri, 25 Jun 99 17:14:31 EDT
Contents:
Re: TAO: the ultimate OS (Graffiti)
Re: How can I redirect kernel message to a file ? (Peter Pointner)
Re: TAPOs: configurations (void)
Re: using C++ for linux device drivers (Philip Boucherat)
Smallest memory allocation block? (Anand)
Re: TAPOs: configurations (Jonathan Abbey)
Re: Why not C++ (Greg Comeau)
Re: Can Linux Boot and Run without a BIOS? (Chris Hedley)
Re: Why we are still holding on to X Windows (David Fox)
Re: Why not C++ (Don Waugaman)
Re: How can I redirect kernel message to a file ? (Juergen Heinzl)
----------------------------------------------------------------------------
From: Graffiti <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 25 Jun 1999 12:14:17 -0700
In article <[EMAIL PROTECTED]>,
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote:
>Christopher Browne ([EMAIL PROTECTED]) wrote:
>
>: As a common "for instance," in DBMS-oriented applications, I have
>: quite regularly heard users ask for the ability to modify the primary
>: key to a DB table, which is one of those basic things that by
>: necessity *cannot* be fiddled with. I *can't* modify the application
>: to allow what they want; the system *forbids* this, and that was in
>: fact the original intent.
>
>there should be no restriction on this if the new primary key
>is unique, imho. give the user whatever they want that is not
>logically impossible.
He's saying the system forbids it, meaning there was a reason it's
forbidden. i.e. Joe Random Newbie wants to modify the primary key
(the Social Security Number) of a bank account.
Unless you know exactly what kind of situation he was in, it's a good
idea not to make statements such as you did. :-)
>another example: the end user wants to increase the space
>for their linux partition and decrease space on their windows
>partition. without reformatting. how many zillions of hours
>have been spent in this operation by end users? only because
>programmers haven't written the code to move around partitions
>on a hard drive? a clear cut case where programmer convienience
>was chosen at huge sacrifice to user convenience.
No, this is because:
1) Windows doesn't have a concept of a dynamically growing/shrinking
partition. Fooling it is very difficult to do correctly, as you will
have to modify the filesystem either from within Windows/DOS with
defrag to free up space at the end of the partition, or write a Linux
app that will read, fix, analyze, and modify the filesystem (not a very
easy task).
2) Linux doesn't have a concept of dynamically growing/shrinking ext2
file systems. While it can be done (ala Partition Magic's code written
by tytso, soon to be released to the public in source form), you have
to take the filesystem off-line. There is work being done on filesystems
that you can change on the fly, but they're still not production quality.
Remember, programmer convinience isn't always an issue. If enough people
want a feature like this, there's a good chance someone will write it if
it's simple enough to do and *get it right*. The second point is
important. In the case of a utility that will re-size Windoze and Linux
partitions, you have to be able to ensure that you won't corrupt data.
Because of how the FAT-12/16/32, NTFS, ext2, ext, xia, minix, ufs, etc.
are laid out, you have a biiig problem. Do you support only a few
filesystems correctly? (i.e. ext2 and FAT-16). Do you try to support them
all? (UMSDOS, hfs, ffs).
It's not easy writing stuff like this. The difficulty of getting it right
probably keeps people from doing it, too.
>: >but imho it is largely responsibility
>: >of programmer to anticipate what users want without requiring them
>: >to articulate it explicitly. true? the greatest designer gives you
>: >something you didn't even know you wanted!! and you realize, only
>: >upon seeing it, that you can't live without it<g>
>: Clearly the writings of someone who has signed off on a lot of
>: computer system design specifications. Not.
>
>your jab eludes me, sorry..?? what is your point?
If you've ever tried to write software according to "What the customer
wants", you'll find you're in a losing battle.
i.e.:
Customer: "I want an easy to use way to manage my assets."
Developer: "What assets do you have?"
Customer: "All sorts. Basically, anything with value."
Developer: "Okay, this keeps track of $$/hr/foo/bar/baz."
Customer: "No, that's not what I meant. I want to be able to see
What kind of assets I have."
Developer: "You mean a description field and maybe a way to show a
picture of it?"
Customer: "No, I want to manage it."
ad infinutum.
-- DN (Bored at work :-)
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: How can I redirect kernel message to a file ?
Date: Thu, 24 Jun 1999 19:15:29 GMT
Soohyung Lee <[EMAIL PROTECTED]> wrote:
> I want to know the exact time of context switching between some tasks .
> So, I added some printk functions in the kernel source for that purpose.
> But, all the messages are output to the console .
> I want to redirect these messages (by printk) to a file ( like redirection
> of printf messages).
> I don't want to know use /var/log/messages .
Could you tell us why you cannot use /var/log/messages (or some
similar thing using syslogd)?
Peter
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAPOs: configurations
Date: 25 Jun 1999 15:57:00 GMT
On 25 Jun 1999 10:03:35 -0500, Jonathan Abbey <[EMAIL PROTECTED]>
wrote:
>
>Text files are vulnerable to breakage because they can be changed in
>random ways by mistake.. a good configuration database could still be
>corrupted, but at least changes made to it would not suffer from
>spaces instead of tabs, and the like. Having an API that changes go
>through also allows for sanity testing of changes, automatic backups,
>transactions, and many other good things, which can help mitigate
>Christopher Browne's comments on the basic fragility of such systems.
Are you familiar with vipw, or visudo? These are tools for editing text
configuration files -- /etc/passwd and /etc/sudoers, respectively. They
do file locking, spawn the user's editor of choice, sanity-check the results,
and save them back to disk.
--
Ben
"The world is conspiring in your favor." -- de la Vega
------------------------------
From: Philip Boucherat <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: Fri, 25 Jun 1999 16:39:39 +0100
In article <[EMAIL PROTECTED]>, Justin Vallon
<[EMAIL PROTECTED]> writes
>[EMAIL PROTECTED] writes:
>C++ just gives you a bigger gun to shoot yourself in the head.
>
>You might not think twice about:
>
> String s = String("Your name is ") + UserName + ".";
>
>But, would you ever say:
>
> const char *s1 = strdup("Your name is ");
> const char *s2 = malloc(strlen(s1) + strlen(UserName) + 1);
> strcpy(s2, s1);
> strcat(s2, UserName);
> const char *s3 = malloc(strlen(s2) + strlen(".") + 1);
> strcpy(s3, s2);
> strcat(s3, ".");
> free(s1);
> free(s2);
> s = s3;
>
>?
>
I know this is irrelevant, but some Windows NT drivers written in C
appear to have pages and pages of code similar to you second example,
usually in the bit where they're making device names.
--
Philip Boucherat
------------------------------
From: Anand <[EMAIL PROTECTED]>
Subject: Smallest memory allocation block?
Date: Fri, 25 Jun 1999 20:22:30 GMT
What is the smallest amount of memory that Linux allocates? If I do
"malloc(1)" does Linux allocate only 1 byte from its internal free
memory pool or is there a minimum amount of memory that is allocated?
If the amount of memory requested is less than this minimum then is the
remaining memory in the allocated block a waste or is it used for any
purpose?
An answer for any version of Linux kernel is good enough for me.
Thanks
Anand
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Jonathan Abbey)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAPOs: configurations
Date: 25 Jun 1999 11:42:17 -0500
In article <[EMAIL PROTECTED]>,
void <[EMAIL PROTECTED]> wrote:
|
| Are you familiar with vipw, or visudo? These are tools for editing text
| configuration files -- /etc/passwd and /etc/sudoers, respectively. They
| do file locking, spawn the user's editor of choice, sanity-check the results,
| and save them back to disk.
Of course. In fact, I had vipw in the back of my mind as I wrote
that, as a good counterexample. Unfortunately, vipw is by far the
exception when it comes to validating UNIX configuration files.. 99%
of configuration files don't come with any sort of validating process
to mediate changes.
I spent a couple of years writing a system that tried putting
validation, selective permissions, and cross-file integration on top
of traditional NIS source files, and I can say unequivocally that it
sucked. Every file different, each cross-file consistency having to
be maintained with its own custom code, and the whole thing
susceptible to breaking if someone went in and carelessly hand edited
one of the text files. We've run our lab on it for the last 5 years
and it works, but it's hard to maintain, fragile, and butt-ugly
inside.
For the last three and a half years I've been developing a successor
to that system based on an object database with automatic symmetric
link validation and data normalization, and it's been terrific. It's
such a pleasure writing code for the infrastructure and then being
able to re-use that infrastructure code over and over and over again
across different kinds of stored data.
Obviously one can say that our earlier project was ugly because I
wasn't as good a coder or designer then as now, but having spent a
couple years at it, I can tell you I have a firm grasp on some of the
difficulties of manipulating text files to provide a higher level of
validation, security, and consistency.
| --
| Ben
|
| "The world is conspiring in your favor." -- de la Vega
--
===============================================================================
Jonathan Abbey [EMAIL PROTECTED]
Applied Research Laboratories The University of Texas at Austin
Ganymede, a free NIS/DNS management system http://www.arlut.utexas.edu/gash2
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 25 Jun 1999 16:56:30 -0400
Reply-To: [EMAIL PROTECTED]
In article <7kscsl$s0h$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Nathan Myers)
writes:
>Ralph Glebe <[EMAIL PROTECTED]> wrote:
>> Are all the programs in C because: [speculation]
>
>There are quite a lot of C++ projects on Linux. C projects (still)
>outnumber them for several reasons.
>
>1. C is an easier language to learn to use fully, so you may get
> better participation on a C project because you're drawing on
> a larger population.
This is a nit, and one I believe Nathan will agree with, but IMO,
it's not an easier language as much as it's perceived to be an
easier language. I mean, sure, C syntax is definitely smaller than
C++ syntax and such. But C programming involved more than just that
since a C programmer still has to learn general techniques, etc.
Also, even specific to C, I find the average C programmer does not
know C well. Probably fair to say that they more or less know some
subset enough to get by. Anyway, the bottom line is the C is popular
and will remain so.
>2. It takes substantial extra effort to code C++ libraries that are
> binary-compatible from one release to the next, so library version
> problems are incrementally harder.
This is definitely a roadblock, but I wonder how many people actually
realized this when they started out? I would suspect not to many.
Luckily Standard C++ is out and at least for now binary compatible issues
are known and can be addressed by compiler implementors as they upgrade.
Of course, some compilers have done this more than others. :)
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Chris Hedley)
Subject: Re: Can Linux Boot and Run without a BIOS?
Date: 25 Jun 1999 16:48:28 GMT
In article <7kgej7$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Byron A Jeff) writes:
> The problem is the BIOS is usch a generic term that whatever code that sits
> in non-volatile memory and boots the OS can be called a BIOS, whether it's
> a PC, Mac, Alpha, SGI, or Sparc.
>
> How about can Linux be boot without using a IBM compatible PC BIOS? Then yes.
Just musing here, but it would be extremely nice to find a way of booting
an Intel-based system without having the BIOS in the equation. I've noticed
that as hardware has increased in speed, the amount of time taken by the
BIOS to finish faffing around has also paradoxically increased. I think it's
up to about a minute now on my current system, which is a l o n g time to
wait when you're sat in front of it waiting for it to do something.
Chris.
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 25 Jun 1999 09:52:33 -0700
Marcus Sundberg <[EMAIL PROTECTED]> writes:
> > Let's face it. X Windows is a really premitive base for modern GUI,
> > terrible font support breaks GUI all the time, no sound capability, ....
>
> What the hell has sound got to do with GUIs or fonts?
I must say that this thread has changed my mind on this point. X
handles screen output, but it also handles mouse and keyboard input.
Why? Because they are part of the user interface - the "UI" in "GUI",
and the events that are generated need to be coordinated with the
events that generate the screen output. It is now little funny to
hear someone say "What the hell has sound got to do with GUIs..."
Sound is a part of the user interface, graphical or otherwise, and
sound events also need to be integrated into the stream of events
associated with a given application. This is especially important
when you are running applications over the network.
But I still don't think this is any reason to throw away X.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 25 Jun 1999 09:50:23 -0700
In article <[EMAIL PROTECTED]>,
John E. Davis <[EMAIL PROTECTED]> wrote:
>On Sat, 26 Jun 1999 00:53:24 +1200, Bruce Hoult <[EMAIL PROTECTED]>
>wrote:
>>Not true, IMHO. Even such simple things as // comments, declaring
>>variables at first use, inline functions and const instead of #define,
>>structs as type names, references, cleaned-up casting, and default
>>arguments make C++ better than C.
[ some good points deleted, though I would note that gcc's inlining
support is not a feature of the C language but is rather an extension ]
>Now consider references:
>
> int x;
> x = 1;
> some_function (x);
>
>what will be x's value after the call to some_function? Will it be
>altered? In C, I know immediately know the answer to the question and
>do not have to look further. This kind of syntactic sugar disturbs me
>as one who reads a lot of software that I did not write.
Reference semantics can be abused, true. Of course, would you really
feel comfortable reading this code and not knowing a thing about what
some_function() does?
Some C++ programmers adhere to a coding standard of using only const&
parameters, and passing paramters that may be changed by a function by
pointer. I think that this type of coding discipline would meet your
objections above.
>Regarding //, in two keystrokes, my editor puts /* */ at the end of
>the current line and places the cursor in the middle. If the comment
>requires more than one line, I either hit return to continue onto the
>next line, or reformat the comment as text. I claim that very little
>is achieved by using // comments.
Not all of us use your editor. Note that the upcoming C language
standard (C9X, where X > 9 :-)) has added // comments, so the advantage
has been noted by many in the C community, although I would agree that
the // comment form is a fairly trivial enhancement. In particular,
using // comments in code so that one can later comment out larger
sections using /* */ is much worse than using #if 0/#endif pairs to
block out sections of code.
>Please note, I am not arguing that C++ is not a better language than
>C. I am just saying that the reasons that you listed do not make it a
>better language. In my opinion, the only thing that C++ has over C is
>better support for data encapsulation via classes and, possibly,
>exception handling. Other features such as operator overloading I can
>do without because of the potential for abuse.
You should probably look into C++'s support for templates, which I would
argue is at least as important as object encapsulation.
Operator overloading I don't have much of a problem with in general,
as long as care is taken in designing classes to eliminate automatic
type conversions (the latter should be taken out and shot).
I can see your point regarding abuse of language features. Of course, C
offers features that have at least as much potential for abuse than C++ -
here I'm referring to pointer arithmetic/assignment, memory management,
and non-type-safe I/O. You're used to this type of abuse, and you can
spot it pretty quickly in code if you've had much experience in C, but
C++ adds some more gotchas that can give you trouble if you aren't used
to the language. For a beginner, though, learning C++ from no background
at all is easier than learning C, which really takes experience with
assembler to fully grok.
Of course, the point that Bruce was making was that one need not use the
"advanced" C++ features such as templates, exception handling, rtti and
the like to gain the benefits that the language offers. (I would have
added function overloading, stronger argument typechecking (even during
the link step, thanks to name mangling) and the C++ Standard Library,
particularly iostreams, to his list, but it's a solid starting point.)
--
- Don Waugaman ([EMAIL PROTECTED]) O- _|_ Will pun
Web Page: http://www.cs.arizona.edu/people/dpw/ | for food
In the Sonoran Desert, where we say: "It's a dry heat..." | <><
I feel a lot more like I do now than I did a while ago.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: How can I redirect kernel message to a file ?
Date: Fri, 25 Jun 1999 20:44:41 GMT
In article <[EMAIL PROTECTED]>, Peter Pointner wrote:
>Soohyung Lee <[EMAIL PROTECTED]> wrote:
>> I want to know the exact time of context switching between some tasks .
>> So, I added some printk functions in the kernel source for that purpose.
>> But, all the messages are output to the console .
>> I want to redirect these messages (by printk) to a file ( like redirection
>> of printf messages).
>> I don't want to know use /var/log/messages .
>
>Could you tell us why you cannot use /var/log/messages (or some
>similar thing using syslogd)?
Minor note, there is no need to use /var/log/messages, use ...
klogd -f <file>
... it might be enough.
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
** 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
******************************
