Linux-Development-Sys Digest #880, Volume #6 Fri, 25 Jun 99 00:14:40 EDT
Contents:
Accessing Yamaha CRW4416S CD writer causes complete lockup (Carl Kumaradas)
sources for the empeg car player? (Michael Hirsch)
Re: Why we are still holding on to X Windows ([EMAIL PROTECTED])
Benchmarks 2.2.9 vs. 2.3.8 (Robert Krawitz)
Re: Portal software for Linux (Michael Hirsch)
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Terry Murphy)
Re: TAO: the ultimate OS (Terry Murphy)
----------------------------------------------------------------------------
Crossposted-To: comp.os.linux.hardware,comp.os.linux.help
From: Carl Kumaradas <[EMAIL PROTECTED]>
Subject: Accessing Yamaha CRW4416S CD writer causes complete lockup
Date: Fri, 25 Jun 1999 01:26:05 GMT
I'm experiencing complete lockups (even Alt-SysRq.. keys don't work)
when I startup a CD writer program called krabber
(http://members.tripod.com/~fehlfarben). This crash seems to be
repeatable to some extent (will happen maybe 50% of the time).
This is the output from the system log just before the crash:
Jun 24 20:29:51 kelvin kernel: sr0: CDROM not ready. Make sure there is a disc
in the drive.
Jun 24 20:29:51 kelvin kernel: sr0: CDROM not ready. Make sure there is a disc
in the drive.
Jun 24 20:29:51 kelvin kernel: cdrom: open failed.
Jun 24 20:29:51 kelvin kernel: Device not ready. Make sure there is a disc in the
drive.
Jun 24 20:29:51 kelvin kernel: Device not ready. Make sure there is a
disc in the drive.
[[[[[[[[[[[[These 5 lines are repeated once more]]]]]]]]]]]]
Jun 24 20:29:51 kelvin kernel: sr1: CDROM not ready. Make sure there is a disc
in the drive.
Jun 24 20:29:51 kelvin kernel: sr1: CDROM not ready. Make sure there is a disc
in the drive.
Jun 24 20:29:51 kelvin kernel: cdrom: open failed.
Jun 24 20:29:51 kelvin kernel: Device not ready. Make sure there is a
disc in the drive.
[[[[[[[[[[[[These 4 lines are repeated once more]]]]]]]]]]]]
[[[[[[[[[[[[Top 5 lines repeated twice]]]]]]]]]]]]
[[[[[[[[[[[[***crash****]]]]]]]]]]]]
Of course there is no CD in the drive, and I don't know why krabber is
trying to load one at startup (but I can fix this, I think). I just
concerened that this can cause a complete lockup.
I also experienced a complete lockup when I tried to mount the CD
drive (scd0) with a blank CD in it.
I just purchased the CD writer, and I've been experiencing these
lockups since.
My system is as follows:
Dual PentiumPro 200MHz
All SCSI setup as indicated by the bootup messages below.
Linux 2.2.10 (same problem with 2.2.5),Egcs-1.1.2 compiled
Any help would be greatly appreciated.
Regards,
Carl.
# more /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: MICROP Model: 4345NS Rev: P419
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: QUANTUM Model: XP34550S Rev: LXQ1
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: MICROP Model: 4345NS Rev: XN29
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 03 Lun: 00
Vendor: ARCHIVE Model: Python 28388-XXX Rev: 5.AC
Type: Sequential-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 04 Lun: 00
Vendor: YAMAHA Model: CRW4416S Rev: 1.0e
Type: CD-ROM ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 05 Lun: 00
Vendor: TEAC Model: CD-ROM CD-56S Rev: 1.0D
Type: CD-ROM ANSI SCSI revision: 02
# more /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 5.1.17/3.2.4
Compile Options:
TCQ Enabled By Default : Enabled
AIC7XXX_PROC_STATS : Enabled
AIC7XXX_RESET_DELAY : 5
Adapter Configuration:
SCSI Adapter: Adaptec AHA-294X Ultra SCSI host adapter
Ultra Narrow Controller
PCI MMAPed I/O Base: 0xfedfa000
Adapter SEEPROM Config: SEEPROM found and used.
Adaptec SCSI BIOS: Enabled
IRQ: 17
SCBs: Active 0, Max Active 48,
Allocated 60, HW 16, Page 255
Interrupts: 126287
BIOS Control Word: 0x18b6
Adapter Control Word: 0x005e
Extended Translation: Enabled
Disconnect Enable Flags: 0x00ff
Ultra Enable Flags: 0x0007
Tag Queue Enable Flags: 0x0007
Ordered Queue Tag Flags: 0x0007
Default Tag Queue Depth: 16
Tagged Queue By Device array for aic7xxx host instance 0:
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
Actual queue depth per device for aic7xxx host instance 0:
{16,16,16,1,1,1,1,1,1,1,1,1,1,1,1,1}
Statistics:
(scsi0:0:0:0)
Device using Narrow/Sync transfers at 20.0 MByte/sec, offset 15
Transinfo settings: current(12/15/0/0), goal(12/15/0/0), user(12/15/0/0)
Total transfers 48529 (46690 reads and 1839 writes)
< 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
Reads: 37426 194 1224 498 477 6848 23 0
Writes: 681 187 148 788 11 24 0 0
(scsi0:0:1:0)
Device using Narrow/Sync transfers at 20.0 MByte/sec, offset 15
Transinfo settings: current(12/15/0/0), goal(12/15/0/0), user(12/15/0/0)
Total transfers 31542 (29853 reads and 1689 writes)
< 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
Reads: 23969 185 223 970 303 3999 204 0
Writes: 1004 98 182 374 7 24 0 0
(scsi0:0:2:0)
Device using Narrow/Sync transfers at 20.0 MByte/sec, offset 15
Transinfo settings: current(12/15/0/0), goal(12/15/0/0), user(12/15/0/0)
Total transfers 46154 (44796 reads and 1358 writes)
< 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
Reads: 36060 117 1069 355 364 5992 839 0
Writes: 308 28 63 789 150 20 0 0
(scsi0:0:3:0)
Device using Narrow/Sync transfers at 6.67 MByte/sec, offset 15
Transinfo settings: current(32/15/0/0), goal(12/15/0/0), user(12/15/0/0)
Total transfers 0 (0 reads and 0 writes)
< 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
Reads: 0 0 0 0 0 0 0 0
Writes: 0 0 0 0 0 0 0 0
(scsi0:0:4:0)
Device using Narrow/Sync transfers at 8.0 MByte/sec, offset 15
Transinfo settings: current(30/15/0/0), goal(12/15/0/0), user(12/15/0/0)
Total transfers 0 (0 reads and 0 writes)
< 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
Reads: 0 0 0 0 0 0 0 0
Writes: 0 0 0 0 0 0 0 0
(scsi0:0:5:0)
Device using Narrow/Sync transfers at 10.0 MByte/sec, offset 8
Transinfo settings: current(25/8/0/0), goal(12/15/0/0), user(12/15/0/0)
Total transfers 0 (0 reads and 0 writes)
< 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
Reads: 0 0 0 0 0 0 0 0
Writes: 0 0 0 0 0 0 0 0
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: sources for the empeg car player?
Date: 24 Jun 1999 23:16:07 -0400
As I recall, the guy who built the empeg (www.empeg.com) car player
built a custom MB and then put a custom version of linux on it. Since
it is now shipping, the sources to the GPLed parts of the player must
be available.
Does anyone have a pointer for these sources? I couldn't find
anything on the above URL.
Thanks,
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Fri, 25 Jun 1999 03:04:54 GMT
In article <[EMAIL PROTECTED]>,
Michael Gu <[EMAIL PROTECTED]> wrote:
> Subject: Why we are still holding on to X Windows
> Message-ID: <[EMAIL PROTECTED]>
> Sender: Junyang Gu <[EMAIL PROTECTED]>
> Date: Wed, 23 Jun 1999 16:29:17 -0400
> MIME-Version: 1.0
> Lines: 11
> X-Newsreader: Microsoft (R) Exchange Internet News Service Version
5.5.2448.0
> Organization: Silicon Systems, Inc.
> Content-Type: text/plain
>
> If Microsoft is a monopoly, X Windows acts more like a monopoly in the
> Unix world.
>
> 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,
....
> If Linux is going to desktops to compete with Microsoft, it got to
come
> up with something much better then X.
>
> So, why don't we drop the X and innovate?
>
>
I have been using Linux and X with the KDE window manager as my desktop
OS and I am very happy with its performance (and stability).
There is no real need to change X [in my opinion {;-) ]
If you don't like the look of X you can change the way it looks and
feels - unlike Microsoft Windows of any flavour.
In case you are not aware of the available window managers,
you may be interested in having a look at some links ...
KDE (my favourite) www.kde.org
Enlightenment - www.enlightenment.org
and Gnome - www.gnome.org
All of these will totally (drastically) change the look, feel and
functionality of your desktop (X).
I have a Sound Blaster card in my PC and it works fine in X.
Sound events similar to MS Windows sound events can be setup.
Still not convinced, or not enough screen shots ??
you may even be interested in what my own home PC desktop looks like.
I have put together a web page of my main applications that run in X.
have a look at
http://skyscraper.fortunecity.com/graphical/48/linux4endusers.html
Oh - and by the way - all the apps listed on my page are FREE.
Hope this is of some value to you.
Regards.
Ian H
Australia.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Benchmarks 2.2.9 vs. 2.3.8
Date: 24 Jun 1999 12:04:08 -0400
Following are some unscientific benchmarks and comments about the
development vs. release kernel. My system is a C300A o/c 450, 256 MB
CAS-2, 2 fast narrow Barracuda disks and an IBM Deskstar 7200 RPM 18
GB, and a Matrox Millennium 4 MB graphics card. The system runs, and
pages, off the 2 Barracudas (/ and /usr are on different disks, and
there's 1 swap partition on each). The system is running SuSE 6.1.
These tests emphasize low-end performance.
Both kernels were compiled with gcc 2.7.2.
First, hdparm -t (with DMA and 32-bit xfers turned on) against the
Deskstar reported about 13 MB/sec. both ways.
Second, writing and reading back 128 MB (less than memory) showed
2.3.8 possibly writing slightly faster and using less CPU time (on the
order of 12-13.5 MB/sec). Reading back, the difference was really
dramatic; on 2.2.9 the "readback" rate varied between 40 and 80
MB/sec, while 2.3.8 gave upwards of 300 MB/sec. This is faster than
memory copy speed, and it's clear that the new stuff is better here.
Third, my initial desktop startup (running Gnome, with a large
background image) took about 27 seconds with 2.3.8 and 26 with 2.2.9.
This difference may not be significant. It's unacceptably slow both
ways. I've noticed that Solaris 2.3 on a much slower machine starts
up much more quickly. This can be tested by starting even a fairly
vanilla X session on an unprimed machine (the machine has not run X
since boot, so nothing's in RAM yet). In general, any large process
suffers from initially slow startup on Linux, but restarts are very
fast.
Finally, the old Byte benchmark. These are actually old libc4 (!)
static binaries. The two reports follow. Some comments:
1) The arithmetic average number is skewed by the execl throughput
test. The difference there is about 3%, which is likely on the
edge of significance.
2) The pipe-based context switch is also faster in 2.2.9, by about
5%. This is probably marginally sufficient.
3) The shell script tests also show 2.2.9 with a 5%'ish advantage,
particularly with more concurrent scripts.
4) I'm particularly surprised at the difference in the pipe throughput
test in light of my own tests described above.
If I had to guess one thing, it's that context switching is slightly
slower in 2.3.8.
BYTE UNIX Benchmarks (Version 3.11)
System -- Linux rlkppp 2.3.8 #7 Thu Jun 24 08:44:53 EDT 1999 i686 unknown
Start Benchmark Run: Thu Jun 24 10:07:03 EDT 1999
1 interactive users.
Dhrystone 2 without register variables 710650.5 lps (10 secs, 6 samples)
Dhrystone 2 using register variables 710756.3 lps (10 secs, 6 samples)
Arithmetic Test (type = arithoh) 25033552.0 lps (10 secs, 6 samples)
Arithmetic Test (type = register) 123671.1 lps (10 secs, 6 samples)
Arithmetic Test (type = short) 91036.0 lps (10 secs, 6 samples)
Arithmetic Test (type = int) 123786.4 lps (10 secs, 6 samples)
Arithmetic Test (type = long) 123796.9 lps (10 secs, 6 samples)
Arithmetic Test (type = float) 111605.3 lps (10 secs, 6 samples)
Arithmetic Test (type = double) 114647.5 lps (10 secs, 6 samples)
System Call Overhead Test 247176.5 lps (10 secs, 6 samples)
Pipe Throughput Test 244871.9 lps (10 secs, 6 samples)
Pipe-based Context Switching Test 130990.1 lps (10 secs, 6 samples)
Process Creation Test 14893.1 lps (10 secs, 6 samples)
Execl Throughput Test 7383.6 lps (9 secs, 6 samples)
File Read (10 seconds) 883797.0 KBps (10 secs, 6 samples)
File Write (10 seconds) 155461.0 KBps (10 secs, 6 samples)
File Copy (10 seconds) 19067.0 KBps (10 secs, 6 samples)
File Read (30 seconds) 869309.0 KBps (30 secs, 6 samples)
File Write (30 seconds) 150914.0 KBps (30 secs, 6 samples)
File Copy (30 seconds) 12023.0 KBps (30 secs, 6 samples)
C Compiler Test 661.7 lpm (60 secs, 3 samples)
Shell scripts (1 concurrent) 1153.8 lpm (60 secs, 3 samples)
Shell scripts (2 concurrent) 606.8 lpm (60 secs, 3 samples)
Shell scripts (4 concurrent) 309.1 lpm (60 secs, 3 samples)
Shell scripts (8 concurrent) 155.7 lpm (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places no measured results
Recursion Test--Tower of Hanoi 12745.2 lps (10 secs, 6 samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Arithmetic Test (type = double) 2541.7 114647.5 45.1
Dhrystone 2 without register variables 22366.3 710650.5 31.8
Execl Throughput Test 16.5 7383.6 447.5
File Copy (30 seconds) 179.0 12023.0 67.2
Pipe-based Context Switching Test 1318.5 130990.1 99.3
Shell scripts (8 concurrent) 4.0 155.7 38.9
=========
SUM of 6 items 729.8
AVERAGE 121.6
BYTE UNIX Benchmarks (Version 3.11)
System -- Linux rlkppp 2.2.9rlk #3 Tue May 18 21:16:01 EDT 1999 i686 unknown
Start Benchmark Run: Thu Jun 24 08:47:34 EDT 1999
1 interactive users.
Dhrystone 2 without register variables 710588.8 lps (10 secs, 6 samples)
Dhrystone 2 using register variables 710804.1 lps (10 secs, 6 samples)
Arithmetic Test (type = arithoh) 25036458.3 lps (10 secs, 6 samples)
Arithmetic Test (type = register) 123787.2 lps (10 secs, 6 samples)
Arithmetic Test (type = short) 91039.4 lps (10 secs, 6 samples)
Arithmetic Test (type = int) 123806.0 lps (10 secs, 6 samples)
Arithmetic Test (type = long) 123795.2 lps (10 secs, 6 samples)
Arithmetic Test (type = float) 111603.9 lps (10 secs, 6 samples)
Arithmetic Test (type = double) 114671.6 lps (10 secs, 6 samples)
System Call Overhead Test 248141.4 lps (10 secs, 6 samples)
Pipe Throughput Test 261750.5 lps (10 secs, 6 samples)
Pipe-based Context Switching Test 137880.9 lps (10 secs, 6 samples)
Process Creation Test 14671.6 lps (10 secs, 6 samples)
Execl Throughput Test 7586.2 lps (9 secs, 6 samples)
File Read (10 seconds) 891631.0 KBps (10 secs, 6 samples)
File Write (10 seconds) 139356.0 KBps (10 secs, 6 samples)
File Copy (10 seconds) 21275.0 KBps (10 secs, 6 samples)
File Read (30 seconds) 892489.0 KBps (30 secs, 6 samples)
File Write (30 seconds) 139862.0 KBps (30 secs, 6 samples)
File Copy (30 seconds) 15922.0 KBps (30 secs, 6 samples)
C Compiler Test 668.0 lpm (60 secs, 3 samples)
Shell scripts (1 concurrent) 1180.9 lpm (60 secs, 3 samples)
Shell scripts (2 concurrent) 627.4 lpm (60 secs, 3 samples)
Shell scripts (4 concurrent) 322.4 lpm (60 secs, 3 samples)
Shell scripts (8 concurrent) 163.0 lpm (60 secs, 3 samples)
Dc: sqrt(2) to 99 decimal places no measured results
Recursion Test--Tower of Hanoi 12689.0 lps (10 secs, 6 samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Arithmetic Test (type = double) 2541.7 114671.6 45.1
Dhrystone 2 without register variables 22366.3 710588.8 31.8
Execl Throughput Test 16.5 7586.2 459.8
File Copy (30 seconds) 179.0 15922.0 88.9
Pipe-based Context Switching Test 1318.5 137880.9 104.6
Shell scripts (8 concurrent) 4.0 163.0 40.8
=========
SUM of 6 items 770.9
AVERAGE 128.5
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Michael Hirsch <[EMAIL PROTECTED]>
Subject: Re: Portal software for Linux
Date: 24 Jun 1999 23:24:53 -0400
Alessandro Bruciamonti <[EMAIL PROTECTED]> writes:
> Hello all!
>
> I'm searching for "web portal software" under Linux. I need
> informations on every implementation of configurable user
> web interface.
I believe zope has a portal toolkit, or will release it
soon. www.zope.com
--
Michael D. Hirsch Work: (404) 727-7940
Emory University, Atlanta, GA 30322 FAX: (404) 727-5611
email: [EMAIL PROTECTED] http://www.mathcs.emory.edu/~hirsch/
Public key for encrypted mail available upon request (or finger
[EMAIL PROTECTED]).
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Date: 25 Jun 1999 03:30:40 GMT
In article <[EMAIL PROTECTED]>,
Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>"No reason"? I suspect you don't understand the way database systems *or*
>filesystems are implemented.
I thoroughly understand, at least, how filesystems are implemented.
About a year and a half ago, I personally coded the whole block
pointer scheme for a filesystem (i.e. direct blocks, single indirect
blocks, and double indirect blocks).
>Databases are a big hive of pointers. If built atop of a filesystem, which
>is another big hive of pointers, this gives you one big interconnected nest
>of pointers. If one block of the FS goes out, your database is corrupt, and
>the corruption may extend arbitrarily distantly from the deepest level.
>
>In other words, a DB atop a filesystem is not only vulnerable to corruption
>of the file (e.g. - if a buggy program at user level crashes/writes bad
>data), it is also further vulnerable to corruption that comes from
>filesystem bugs, which are somewhat indistinguishable from corruption
>resulting from hardware failures.
>
>In contrast, text files are linear arrays of information atop a single
>FS-level "hive of pointers." If a block blows out, this removes a chunk of
>that linear array, which is obviously still a bad thing, but not as vastly
>corruptive, since there aren't the multifariously-indirected pointers.
I -thouroughly- understand this, and this is exactly what I was talking
about in my last message when I referred to "metadata". I am somewhat
taken aback that you wrote all of the above, actually.
You can implement a registry system with no additional metadata than a
text file, if you use fixed sized records, and don't have additional
indexes, and yet still have all of the advantages of a registry
system. There can be exactly no additional metadata than in a text
file, and thus it is no more subject corruption. If you implement a
full scaled database, yes, there is additional chance of corruption.
But you do not need that to gain the advantages of a registry system.
>And vi includes sorts of functionality that regedit doesn't. A macro
>programming system. Regular expression parser.
I know. I'm not sure what your point is.
If your point is that VI is more functional than REGEDIT in the event
of a system crash because it provides macro programming, well, I
diasagree.
If your point is that VI is bloated and people should use EDLIN
(or ED if using Unix) for this sort of task, well, the typical
registry hater's argument is: "I can just use VI to fix the system)
>It would be rather more fair to compare regedit, weighing in at 71K, with
>something like t.exe, which weighs in at 1K.
I do not know what t.exe is, but assuming it is a small text editor,
there is no reason you could not implement a very small registry
editory, since there are calls to do all of the real work.
At the minimum all you need is code to change a value, see the values,
and get the keys. These are INHERENTLY simpler operations, and could
be implemented with less code than it would take to implement a general
purpose text editor which can perform the operations as efficiently.
>You have to compare apples with apples.
>
>To compare with Oracle, you have to have a version of Oracle that:
>
>a) Removes the lock manager LCK,
>b) Removes the transaction manager CKPT,
>c) Removes the archive logging facility (e.g. - LGWR),
>d) Allows processes to modify database files directly, without locking,
>rather than having to proxy through such things as DBWR,
>e) Implements atop files atop DOS FAT, rather than using raw partitions.
>
>Oracle doesn't just have *one* thing that works to provide a robust system;
>it has a whole host of work processes working together.
My problem with this thinking is that you are only referring to the
Windows implementation of the registry. I am merely advocating
database configuration systems in general, and there's no reason
that one couldn't handle this stuff.
>And it is worth noting that they don't use a database to store the
>system configuration for the database; that is stored in, Surprise,
>Surprise...
> Text files.
This is a good point, but I suspect it is just to fit in with other
Unix tools as far as configuration tools. Does Oracle running on VMS or
Windows also use text files, or just on Unix?
>That is a separate question.
>
>I would promote the use of some common configuration libraries, such as
>libPropList. It was created particularly for use with WindowMaker, and is
>compatible with the property list schemes used in NeXTstep, OPENSTEP, and
>GNUstep. It sets up a structure that may be read, manipulated, written, and
>synchronized with a file, and by providing an opaque data structure in
>between, removes the need for an application to be aware of the form in
>which the data is represented.
>
>Its implementation uses text files, which nobody (other than those that
>apparently worship O(1) or O(log(n)) operations that result in building
>fragile multilayered disk-based pointer hives) seems to complain about.
>
>Note that by using facilities like libPropList, this means that:
>the programmer does *not* need to create:
>a) Yet Another File Format,
>b) Yet Another Parser,
>and debug, and so forth.
I am not familiar with libPropList (one of my favorite features of
WindowMaker, is that it just saves my configuration operations without
me having to mess with text files, so I never much bothered to see what
was going on under the hood), but it sounds like a fine product (from
what you describe). My problem, of course, with this sort of thing, is
that it is non-standard, so only a few tools end up using it.
I hate to sound cynical/close-minded, but the only way to really
impress me with this sort of tool, is for every file/tool on Unix to
use it. The whole fact that the registry is used in everything in
Windows, is the whole essence of its advantage.
>Have you profiled it to establish that parsing is forcibly the cause of
>slowness?
>
>Or are you merely claiming this as a bald fact, devoid of any real evidence
>to back up such claims?
>
>The sources are available. Your mission, if you wish to claim evidence that
>text parsing is the cause of its slowness, is to compile Linuxconf with
>suitable profiling options, collect statistics, and tell us how much of the
>wait times related to text parsing.
OK, that's fair. I'm basing my claim on the fact that the speed is much
worse than for Windows NT when doing the equivalent operations (e.g.
changing the DNS server, or setting up PPP). Anyways, I will not mention
this issue again until I take you up on your challenge.
>Oh, good. Citing sendmail.cf as an example of "why you should use a
>database instead."
OK, I will admit that this was not a good thing to say.
To be more fair, I will say that a GUI read/write editor of /etc/fstab
would be MUCH more complex than would be an editor for the equivalent
information stored in a binary file. True, it would not be too complex,
but it has so much more worries that the editor of the binary file
doesn't have: dealing with user errors, and preserving exactly what the
user inputted are two issues.
-- Terry
------------------------------
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: 25 Jun 1999 03:52:41 GMT
In article <7ksui5$c4k$[EMAIL PROTECTED]>,
Donal K. Fellows <[EMAIL PROTECTED]> wrote:
>OK, provide them.
(I'm sorry, I don't quite know the format for a bibliography on Usenet)
Card, David N., Frank E. McGarry, and Gerald T. Page. July 1987.
"Evaluating Software Engineering Technologies". _IEEE Tranasactions in
Software Engineering_ Incidentally, this was joint research among NASA,
Computer Sceiences Corp., and U. of Maryland.
This is a bit old, and compilers were a bit slow at the time, so it
would be interesting to repeat the research and see how much that
was a factor.
>I suspect that the design->code and edit->compile->test paradigms are
>tuned towards tackling separate problems...
>
>(Has anyone developed a commercial OS yet using a proper formal design
>technique? Or are those only ever used in the safety-critical domain?)
As I said in a different post, VMS was developed this way, assuming it
was designed in the same manner DEC designed all of its other software
(and it feels like it was too) Though it does have a pretty big niche in
the safety-critical domain, so maybe it doesn't count.
-- Terry
------------------------------
** 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
******************************
