Linux-Development-Sys Digest #855, Volume #6 Mon, 21 Jun 99 18:14:17 EDT
Contents:
Re: htpasswd for Linux (ellis)
Re: TAO: the ultimate OS (Terry Murphy)
v2.3.7 does not compile, (errors attached :-) (Greg de Freitas)
Re: You can now use Winmodems in Linux!!!!!!! (Kevin Burton)
Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS (void)
DosEmu over terminals ("Peter King")
Re: TAO: the ultimate OS (void)
Re: using C++ for linux device drivers (Nathan Myers)
Re: compiling for a Hitachi SH-3 CPU with gcc ("Peter Gutmann")
Re: using C++ for linux device drivers (Nathan Myers)
Re: How to write SMP Driver for race condition (Peter Pointner)
Re: _libc_fcntl error in RedHat 6.0 (Manickam Umasuthan)
Re: using C++ for linux device drivers (Don Waugaman)
Re: Nagel algorithm?? (bill davidsen)
Run in background (vineet)
Re: TAO: the ultimate OS ("Bill Zimmerly")
Re: TAO: the ultimate OS (Stefaan A Eeckels)
Re: Linux uid limits! (bill davidsen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (ellis)
Subject: Re: htpasswd for Linux
Date: 21 Jun 1999 18:24:38 GMT
In article <[EMAIL PROTECTED]>,
John Straumann <[EMAIL PROTECTED]> wrote:
>Any idea where I can get this? The versions I found on the web for UNIX
>won't compile...
Both Apache and thttpd have it.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 21 Jun 1999 18:26:43 GMT
In article <7kjc4v$gtm$[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>In article <7kj6ua$hjp$[EMAIL PROTECTED]>,
>Terry Murphy <[EMAIL PROTECTED]> wrote:
>>
>>The issue of whether an OS should be mainframe-like or Unix-like
>>is actually pretty interesting.
>
>Why?
I hope it is interesting, as they represent the two antitheses of
system design: should the operating system provide policy or should it
just provide the mechanism? Obviously the decision on this issue has
been made for Linux, but I don't think it has been made for the field
as a whole.
>In fact, having lots of "features" is often a sign of being inflexible:
>because you can't do something naturally, you add yet another feature to
>do the new thing.
Yes, but some problems are well understood, and do not require
flexibility. Enforcing a particular GUI in an operating system is one
thing, but having a standard method for records in the filesystem is
quite another: the requirements for a database system are well known.
Of course there is an inherent trade-off between flexibility and
features. But where do you draw the line? Something like a system
monitor where you type in assembly opcodes would be the most flexible
computer interface, but it would also be least efficient.
What flexibility is needed in systems such that such things as
records in filesystems, ACL's, integrated help systems, standard
error messaging and reporting, and the like, should not be part
of the base system?
Look at ODBC in Windows: because of this additional feature, the
system is suddenly more flexible. You can plug any database backend
into your program without changing a line of code. THAT is flexible.
How could this flexibility be achieved in a system with no notion
of a database?
>The reason UNIX doesn't have all that many features was that the
>fundamental design is flexible. One basic example of this is the notion
>of records in a filesystem: a inherently very non-flexible notion, that
>results in lots of silly utilities that are very specific to some
>things.
I emphatically disagree. BECAUSE Unix does not records in the
filesystem (and more generally, because it does not force much policy),
each program becomes its own point tool, whose data is inaccessible to
any other program. If you implement a database in Unix by write()'ing
and read()'ing struct's, your data is an island: only one program can
acess it (yes, that program CAN be a filter which can interact with the
standard programs, but means you do need a silly utility for each file
format, which you suggest is a bad thing).
If you use an ASCII format for your program, you do have access to the text
utilities, and don't need specialized tools, but there are problems:
the Unix tools are line oriented but complex data will necessitate more
complex formats. AWK or PERL will help here, but that is awfully close
to a "silly utility" for each format, since each format will require
its own script.
And as for systems with records having lots of silly utilities: in VMS
there is exactly one utility to handle records in files.
-- Terry
------------------------------
From: Greg de Freitas <[EMAIL PROTECTED]>
Subject: v2.3.7 does not compile, (errors attached :-)
Date: Mon, 21 Jun 1999 15:38:27 +0100
Reply-To: [EMAIL PROTECTED]
==> /var/tmp/kmake.modules-err <==
file.c:60: `generic_readpage' undeclared here (not in a function)
file.c:60: initializer element for `fat_file_inode_operations.bmap_Rd3abca26' is
not constant
file.c:62: warning: initialization from incompatible pointer type
file.c:63: warning: initialization from incompatible pointer type
file.c:110: `generic_readpage' undeclared here (not in a function)
file.c:110: initializer element for
`fat_file_inode_operations_1024.bmap_Rd3abca26' is not constant
file.c:113: warning: initialization from incompatible pointer type
file.c:145: warning: initialization from incompatible pointer type
file.c:148: warning: initialization from incompatible pointer type
make[2]: *** [file.o] Error 1
make[2]: Leaving directory `/usr/src/kernel/v2.3.7/fs/fat'
make[1]: *** [_modsubdir_fat] Error 2
make[1]: Leaving directory `/usr/src/kernel/v2.3.7/fs'
make: *** [_mod_fs] Error 2
==> /var/tmp/kmake.zlilo-err <==
piix.c: In function `piix_dmaproc':
piix.c:280: warning: implicit declaration of function `ide_dmaproc'
3c509.c: In function `set_multicast_list':
3c509.c:835: warning: unused variable `lp'
/usr/src/kernel/linux/include/linux/blk.h:378: warning: `do_sd' defined but not
used
/usr/src/kernel/linux/include/linux/blk.h:402: warning: `do_sd_request' declared
`static' but never defined
scsi.h:637: warning: `end_scsi_request' defined but not used
file.c: In function `minix_write_one_page':
file.c:64: warning: implicit declaration of function `block_write_one_page'
file.c: At top level:
file.c:107: `generic_readpage' undeclared here (not in a function)
file.c:107: initializer element for `minix_file_inode_operations.bmap' is not
constant
file.c:109: warning: initialization from incompatible pointer type
file.c:110: warning: initialization from incompatible pointer type
file.c:114: warning: initialization from incompatible pointer type
make[3]: *** [file.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_minix] Error 2
make: *** [_dir_fs] Error 2
15:35 uniques:/usr/src/kernel/linux#
..well, the final 2.3.7 was _NOT_ described as _DANGEROUS_ ;-)
I agree, it never gets a chance to do any damage, so it isn't !
..Any Ideas ????
--
Ciao 4 now, Greg.
# Email : mailto:[EMAIL PROTECTED] #
# Email : mailto:[EMAIL PROTECTED] #
# To Live, To Love, To Learn, To Leave A Legacy. #
------------------------------
From: Kevin Burton <[EMAIL PROTECTED]>
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: Mon, 21 Jun 1999 11:06:53 -0700
Cool.. I am for it!
Can we change the name to LinModems?
Medical Electronics Lab wrote:
>
> Darragh wrote:
> >
> > Billy Moon wrote:
> >
> > >
> >
> > > I am currently working on a application that enables winmodems to
> >
> > function
> >
> > > in Linux. Anyone who would like to help test this app please contact me.
> >
> > >
> >
> > >
> >
> > >
> >
> > Please send me the stuff. I would really like my Winmodem to work in Linux!
> >
> > Thanks in return.
>
> Add me to the list!!
>
> Patience, persistence, truth,
> Dr. mike
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Mainframes, Filesystems, Databases... Re: TAO: the ultimate OS
Date: 21 Jun 1999 15:44:30 GMT
On Mon, 21 Jun 1999 14:50:42 +0200, Paolo Torelli <[EMAIL PROTECTED]>
wrote:
>something like "fwrite(char *,int,int,FILE*,int priority)", where writes
>within the different priorities are sorted but not necessarily between
>the same priority??
Hmm, my first thought was something more like providing a unique
identifier to each write, and then allow a write call to specify
dependencies explicitly.
--
Ben
"The world is conspiring in your favor." -- de la Vega
------------------------------
From: "Peter King" <[EMAIL PROTECTED]>
Subject: DosEmu over terminals
Date: Mon, 21 Jun 1999 17:01:25 +0100
How do you set-up Linux to allow connected terminals to run DosEmu.
I have a Red Hat 6 box but if I try and run the DOS command on the terminal
screen it says that you cannot run dos please contact your system
administrator.
------------------------------
From: [EMAIL PROTECTED] (void)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 21 Jun 1999 19:25:46 GMT
On 21 Jun 1999 14:07:35 -0500, Peter Samuelson <[EMAIL PROTECTED]>
wrote:
>
>I think you are missing Linus's point -- when he refers to the OS
>design as flexible, he doesn't mean you can't have things like ODBC.
>He means that ODBC will be a shared library, not a system call.
I think a lot of people these days use the term "operating system" to
refer to the kernel plus all associated/bundled functionality.
I don't see any reason why Linux, or any other unix(-style OS) couldn't
ship with an ODBC-style database API in userland -- this has all the benefits
that come with standardization, without stuffing anything that doesn't
belong into the kernel.
--
Ben
"The world is conspiring in your favor." -- de la Vega
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 12:30:52 -0700
<[EMAIL PROTECTED]> wrote:
>
>The main argument against C++ is still overhead. Even when you turn off
>many of the features, you still have overhead that is greater than C.
This is FUD. Please don't propagate FUD.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: "Peter Gutmann" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.questions
Subject: Re: compiling for a Hitachi SH-3 CPU with gcc
Date: Mon, 21 Jun 1999 22:15:43 +0200
Selious wrote ...
>Aha, you wish to write Windows CE programs on linux ?? Or do you wish to
>port linux to CE ??
>
>Anyway, I am studying the machine-code of it (have to do SH3 project for
>work under CE) and I want to make a small assembler for it !!
>
>Do you program asm too ??
>
I program a little bit for my Ti92 calculatur (68000 CPU), but I'm still
learning. I do know 80x86 asm too, but have never worked very extensively
with it.
Anyway, I'd like to write some programs for a Windows CE device. Porting
Linux to CE devices might be a good idea. Some people had this idea, but I
never found something concrete. Do you have a disassembler for SH3 code?
Peter Gutmann
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 12:42:07 -0700
Andi Kleen <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>>
>> Probably the only real problem will be getting Linus to accept necessary
>> patches to the headers so that the C++ compiler will read them without
>> complaint. Such a request is probably doomed, though not for any rational
>> technical reason. The result is that you will need to maintain your own
>> set of header patches.
>
>How do you know if you didn't try?
I have asked several times on the kernel dev list whether header
patches for C++-clean-ness would be considered. I never saw any
evidence that the question was read by anybody responsible.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: Peter Pointner <[EMAIL PROTECTED]>
Subject: Re: How to write SMP Driver for race condition
Date: Mon, 21 Jun 1999 20:11:55 GMT
robert_c <[EMAIL PROTECTED]> wrote:
> Could someone tell me how to write SMP safe driver? Which kernel supportted
> functions can be used to do that and what is the algorithm? Or does some Web
> site explain that?
You can use spinlocks. I read something about it, but forgot where. Probably
cd /usr/src/linux/Documentation
more `grep -l spinlock *`
helps.
Peter
------------------------------
From: Manickam Umasuthan <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: _libc_fcntl error in RedHat 6.0
Date: Mon, 21 Jun 1999 12:59:23 -0400
I get the following error when I recompile the Khoros 2.1
system under RedHat 6.0. The software worked okay with previous
versions of RedHat Linux.
Could someone PLEASE give me some pointers to solve the problem?
thanks
[EMAIL PROTECTED]
(gdb) backtrace
#0 0x4062a744 in __libc_fcntl ()
#1 0x403a5d9c in __DTOR_END__ ()
#2 0x4038eab8 in kflock (id=3, operation=1) at ktransport.c:638
#3 0x40240c8e in xpm_read (
filename=0x808aefc
"$DESIGN/objects/library/kwidgets/misc/pixmaps/men
#4 0x40159c6d in cvtFilenameToPixmap (display=0x80736e8,
args=0xbfffcd58
num_args=0xbfffcd44, fromVal=0xbfffce9c, toVal=0xbfffce90,
closure_ret=0xbfffcd2c) at converter.c:628
#5 0x40487b68 in CallConverter ()
#6 0x40488048 in _XtConvert ()
#7 0x404a0d18 in GetResources ()
#8 0x404a1431 in _XtGetResources ()
#9 0x4048c231 in xtCreate ()
#10 0x4048c80d in _XtCreateWidget ()
#11 0x4048c87c in XtCreateWidget ()
#12 0x4015fd57 in xvw_create (parent=0x808ac68, transient_parent=0,
manag
name=0x4014d57e "MenuButtonPixmap", class=0x4014d760) at
general.c:55
#13 0x40146a85 in xvw_create_pixmap (parent=0x808ac68,
name=0x4014d57e "MenuButtonPixmap") at Pixmap.c:471
#14 0x40145d38 in Initialize (request=0xbfffe80c, new=0x8088c70,
args=0x0
num_args=0xbfffe720) at MenuButton.c:247
#15 0x4048be68 in CallInitialize ()
#16 0x4048c37d in xtCreate ()
#17 0x4048c80d in _XtCreateWidget ()
#18 0x4048c87c in XtCreateWidget ()
#19 0x4015fd57 in xvw_create (parent=0x808c420, transient_parent=0,
manag
name=0x808c928 "options", class=0x4014d420) at general.c:551
#20 0x40146451 in xvw_create_menubutton (parent=0x808c420,
name=0x808c928 "options") at MenuButton.c:566
#21 0x40068ca6 in xvf_create_menubutton (parent=0x808c420, offset=0x0,
x=
y=0.5, width=9.25, height=1, label=0x808c938 "Options",
name=0x808c928 "options", button_names=0x0, button_num=0,
menu_buttons=0x808992c) at wid_util.c:191
#22 0x40059793 in xvf_create_submenu_sel (selection=0x8089910,
parent=0x808c420) at createwid.c:342
#23 0x40058016 in xvf_create_selection (selection=0x8089910,
parent=0x808
location_flag=6) at createform.c:611
#24 0x400576c4 in xvf_create_mainform (form=0x80897e8, x=-1, y=-1)
at createform.c:205
#25 0x40057411 in xvf_create_form (
filename=0x8083f08
"$DESIGN/objects/xvroutine/craftsman/uis/craftsman
x=-1, y=-1, editable=0) at createform.c:104
#26 0x804a189 in main (argc=1, argv=0xbffff744) at craftsman.c:111
#27 0x4059fcb3 in __libc_start_main (main=0x804a050 <main>, argc=1,
argv=0xbffff744, init=0x80498e0 <_init>, fini=0x805d41c <_fini>,
rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff73c)
---Type <return> to continue, or q <return> to quit---
at ../sysdeps/generic/libc-start.c:78
------------------------------
From: [EMAIL PROTECTED] (Don Waugaman)
Subject: Re: using C++ for linux device drivers
Date: 21 Jun 1999 13:01:50 -0700
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Don Waugaman) writes:
[ my disclaimer snipped ]
>> In article <[EMAIL PROTECTED]>,
>> Frank Sweetser <[EMAIL PROTECTED]> wrote:
>> >"John Burton" <[EMAIL PROTECTED]> writes:
>> >> Frank Sweetser wrote in message ...
>> >> >Justin Vallon <[EMAIL PROTECTED]> writes:
>> >> >> Too bad. All you should need is:
>> >> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
>> >> >> void operator delete(void *p) { free(p); }
>> >> >...which is a higher-overhead version of
>> >> >#define new((x)) malloc((x))
>> >> >#define delete((x)) free((x))
>> >> No it isn't, it is very different. malloc and free don't construct the
>> >> objects
>> >> they just alllocate the memory.
>> >yup. but, then, neither do the versions written as non-inline functions up
>> >above. mine also has this flaw, but at least it ends up as a bit of inline
>> >code rather than another function call on every new/delete...
>> Your '#define' hack given above is rather broken. I'll try to explain
>yes, i know. so are the functions which were mentioned in the post
>previous to mine. read the whole thread. basically, it was "well, you can
>just do new and delete with these two wrapper functions to malloc and
>free!" and i said "well, if you're going to do eye-candy functions like
>that, at least do 'em this way to avoid another function call." i'm well
>aware that in real C++, the new and delete operators are much more involved
>than a simple malloc and delete.
Ahem. I beg to differ, and I have been following the whole thread.
The wrapper functions that were given above - operators new and delete -
should work fine for overloading the built-in versions. They may not be
optimal, but they are at least correct[1].
The #define hacks that you produced are neither correct nor optimal.
Overriding the built-in operator new function to allocate memory is not
just a wrapper, and it's not something you can do with the preprocessor.
Your #define trick is different than what was given before, and not just
because of the function call - it's because the new operator is different
from the operator new function, as explained in my previous posting.
(I make this comment because I was extremely confused about the difference
between the new operator and operator new myself for a while, until I did
some programming when I had to figure out the difference.)
[1] Correct according to my best recollection and the 8-year-old ARM rules,
anyway; I don't have any recently updated books with me at the moment, but
I don't believe there have been major changes to this in recent drafts.
--
- 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..." | <><
All generalizations are false.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.networking
Subject: Re: Nagel algorithm??
Date: 21 Jun 1999 21:00:50 GMT
In article <[EMAIL PROTECTED]>,
Mike Jagdis <[EMAIL PROTECTED]> wrote:
| The no nagle config option no long exists and probably the rogue
| ifdef check should no longer exist either. Nagle is automatically
| turned off on a per socket basis if you set the TCP_NODELAY
| socket option on the socket. Turning nagle off globally is a
| bit drastic in most cases.
I agree that the possibility for shooting yourself in the foot is there,
but in some cases a systemic problem (higher latency) favors a systemic
solution. I wish I could easily turn this on and off on a system wide
basis, I'd love to see what it would do for PPP connections (if
anything). Or perhaps it could be done on an interface basis, where
there are known problems or limitations.
I got about 20% boost in ftp rate, not enough to solve the problem, but
enough to indicate a step in the right direction.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: vineet <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Run in background
Date: 21 Jun 1999 20:30:52 GMT
How do I make my C program to run in background after getting initialised.
I mean that the program should detach from the terminal and should run in
background like a daemon.
Thanks
Vineet
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: "Bill Zimmerly" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Mon, 21 Jun 1999 13:12:44 -0500
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> p.s. finally!! someone with some actual authority & credentials to
post to this thread, hahaha
Not to take any respect away from Linus, who certainly deserves our
respect...
...but you are not going to earn anyone's respect by insulting us like that.
FYI, some of us were designing and writing operating systems, device drivers
and programming languages before Linus was out of kindergarten.
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 21 Jun 1999 21:03:53 GMT
In article <7km053$jn8$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Murphy) writes:
> In article <7kjc4v$gtm$[EMAIL PROTECTED]>,
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>>In article <7kj6ua$hjp$[EMAIL PROTECTED]>,
>>Terry Murphy <[EMAIL PROTECTED]> wrote:
>>>
>>>The issue of whether an OS should be mainframe-like or Unix-like
>>>is actually pretty interesting.
>>
>>Why?
>
> I hope it is interesting, as they represent the two antitheses of
> system design: should the operating system provide policy or should it
> just provide the mechanism? Obviously the decision on this issue has
> been made for Linux, but I don't think it has been made for the field
> as a whole.
The question is in reality:
"Can the OS provide policy, given the wide variety of tasks
a general purpose OS is called to perform?"
>>In fact, having lots of "features" is often a sign of being inflexible:
>>because you can't do something naturally, you add yet another feature to
>>do the new thing.
>
> Yes, but some problems are well understood, and do not require
> flexibility. Enforcing a particular GUI in an operating system is one
> thing, but having a standard method for records in the filesystem is
> quite another: the requirements for a database system are well known.
For a perticular database, maybe (and even then, why would it need
to be in the file system, and not in a system library?). The moment
you'd want to put another type of DBMS on the OS, you'd have to try
to work around the limitations of the FS (if the policy "thou shalt
use the record system and nothing else for databases" is effectively
enforced.
> Of course there is an inherent trade-off between flexibility and
> features. But where do you draw the line? Something like a system
> monitor where you type in assembly opcodes would be the most flexible
> computer interface, but it would also be least efficient.
The UNIX choice is a programmable shell, and bags of bytes. Feel
free to dislike it.
> What flexibility is needed in systems such that such things as
> records in filesystems, ACL's, integrated help systems, standard
> error messaging and reporting, and the like, should not be part
> of the base system?
Nothing of what you mention is impossible to provide on UNIX, without
changing the kernel one iota. It never happened because there is no
central point of control, and each vendor / implementor wrote his
idea of the perfect (or adequate) help system, file system, error
message reporting, system administration tool, etc. UNIX survives
(and thrives) *because* this is possible.
If you can get HP, Sun, SCO, Linus, Compaq et al. to agree on
common standards, then it might even happen (hint: write something
*so* compelling everyone wants to use it).
> Look at ODBC in Windows: because of this additional feature, the
> system is suddenly more flexible. You can plug any database backend
> into your program without changing a line of code. THAT is flexible.
> How could this flexibility be achieved in a system with no notion
> of a database?
Windows has *no* notion of a database. ODBC is a simple DLL (which
like all DLLs resides in Windows/System (or Winnt/System32). That
doesn't make more a part of the OS than the ODBC libraries you can
get for UNIX (in fact, I use one right now on Linux).
>>The reason UNIX doesn't have all that many features was that the
>>fundamental design is flexible. One basic example of this is the notion
>>of records in a filesystem: a inherently very non-flexible notion, that
>>results in lots of silly utilities that are very specific to some
>>things.
>
> I emphatically disagree. BECAUSE Unix does not records in the
> filesystem (and more generally, because it does not force much policy),
> each program becomes its own point tool, whose data is inaccessible to
> any other program. If you implement a database in Unix by write()'ing
> and read()'ing struct's, your data is an island: only one program can
> acess it (yes, that program CAN be a filter which can interact with the
> standard programs, but means you do need a silly utility for each file
> format, which you suggest is a bad thing).
But what you describe doesn't happen. It happens all the time in
Windows, where each new version of Word writes a new, incompatible
dump of its memory contents in lieu of a "save".
It's a fact that there are limits to what you can do with ASCII
text (but I submit that TEX source is a vastly superior document
format that Word's binary drivel), but there are very few programs
in UNIX that write structs to files. Those that do, quite often do
so because they have special requirements (such as proprietaryness)
that in the eyes of their creators precluded an "analyzable" format.
You want the OS to enforce policy --stopping people from writing
the program they want to write, because in *your* opinion they
should not be writing it the way they want. That's silly.
There are decent DBMSes for UNIX. Anyone who wants to use them
for data storage, can. Or do you really want Oracle and Informix
to use a compatible data format, so you can analyze it with
PostgresSQL?
You really want to go back to mainframe days when the only
supplier of tools was the supplier of the OS (and the hardware)?
> If you use an ASCII format for your program, you do have access to the text
> utilities, and don't need specialized tools, but there are problems:
> the Unix tools are line oriented but complex data will necessitate more
> complex formats. AWK or PERL will help here, but that is awfully close
> to a "silly utility" for each format, since each format will require
> its own script.
It's impossible to devise a configuration format that will support the
needs of every conceivable program. Just look at a Windows registry
dump to see what hoops people have to jump through to get complex
configuration entries defined.
> And as for systems with records having lots of silly utilities: in VMS
> there is exactly one utility to handle records in files.
And, not without reason I feel, VMS is a dying OS.
Take care,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: Linux uid limits!
Date: 21 Jun 1999 21:27:18 GMT
In article <7kdiu0$jqg$[EMAIL PROTECTED]>,
Georg Acher <[EMAIL PROTECTED]> wrote:
| On Alpha-Linux, an int is 32bit and a long is already 64bit, so you don't need
| long long there. Sometime x86-coders think that an int are not real 32bit, and
| decide to use long to get 'real, authentic and good' 32bit. This is #2 in the
| TOP10-list of "How to write programs that crash on Alpha". #1 is the assumption
| "sizeof(int)==sizeof(void*)=4" ;-)
Unless I totally misremember the C standard, an int is allowed to be 16
bits, and those of us who worry about portability have gotten into using
long, even on systems which are known not to have 16 bit int, and
applications which are not portable.
I don't think it's x86 people, although applications which might
backport to x86 are certainly common.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
** 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
******************************
