Linux-Misc Digest #384, Volume #18 Mon, 28 Dec 98 17:13:17 EST
Contents:
Security Issue<<<<< (support)
Re: Anti-Linux FUD (Daniel Demus)
Sound problems - still ("Eric Peterson")
Re: Anti-Linux FUD (John Edstrom)
Re: Anti-Linux FUD (Anthony Ord)
Re: Easy UNIX editor (Michal Jaegermann)
Re: cpio-2.4.2 and Linux (F. Heitkamp)
Re: New Problem to Old Solution? (Dwight Hubbard)
Installing two copies of Linux ("Eric Hesselberg")
Installing two copies of Linux ("Eric Hesselberg")
Re: Installing two copies of Linux (Michael Kelly)
Re: Is Microsoft a nasty company ? I'm asking you this question.
([EMAIL PROTECTED])
PPC [Was: Re: Anti-Linux FUD] (Matthew Malthouse)
----------------------------------------------------------------------------
From: support <[EMAIL PROTECTED]>
Subject: Security Issue<<<<<
Date: 28 Dec 1998 19:56:13 GMT
would someone join into my machine and check my security hole please ?
you can login as newuser or visitor
thanks for your help.
------------------------------
From: Daniel Demus <[EMAIL PROTECTED]>
Crossposted-To: alt.destroy.microsoft,comp.os.linux.advocacy,comp.os.os2.advocacy
Subject: Re: Anti-Linux FUD
Date: Mon, 28 Dec 1998 09:20:07 +0100
"[EMAIL PROTECTED]" wrote:
>
> Let me add my $0.02 of opinion here,
>
> On Sat, 26 Dec 1998 15:42:56 GMT, Anthony Ord wrote these
> thought provoking words :
>
> -> >Personally I think they are wonderful, well at least an API is
> -> >wonderful.
> ->
> -> What was wrong with the .INI file API?
>
> I don't know if this is related but I have a book here on the 9x/NT
> registry that states that the maximum size of an .ini file is 64Kb.
> This is why software vendors supplied .ini files of their own before
> the registry was designed.
>
Well, the simple solution to that would be to remove the limit. But then
why does everything other than system information have to be put in
win.ini and system.ini to begin with?
> Because there was such a plethora of ini files all over the system
> there were hierarchical problems associated with this. If the win.ini
> file had a particular setting and an application's .ini file overrode
> that setting, who was responsible and where should a system-wide
> setting that had priority be made?
>
Why not make a directory called, say, Ini, and have .ini files in that?
You could even design an API, that accesses these files based on
executable names or some such. Oh, yeah, applications shouldn't have to
have application specific settings in win.ini and system.ini, apart from
what to run at startup.
> The ini files could easily be edited and tampered with by the
> inexperienced and mistakes could be made. Security was also an issue.
>
Ah, security based on obfuscation, the best kind of security as we all
know.
Disclaimer: I do not claim top have any knowledge on API design. These
are just my layman's comments.
OtherThread: Complaints about the registry disappearing, being
corrupted, etc.
Win95, at least, makes a backup of the registry on startup, so restoring
it should be possible using a bootdisk.
--
Daniel
"Cheese is perfectly possible in a gyrating purple helicopter."
Michael Bruce, rasfwr-j
To reply get rid of the dash.
UIN: 11216730
------------------------------
From: "Eric Peterson" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Sound problems - still
Date: 28 Dec 1998 20:39:51 GMT
Hi All,
I have posted re: this problem before, but still have not gotten my sound
card working.
I began by trying to set up an older card (an ATI Stereo F/X) which is 100%
Sound
Blaster compatible.
cat /dev/sndstat shows all the proper devices
dmesg shows correct initialization
free says I have 12 Megs of free memory (How much fragmentation can there
be in this??)
cat end_of_the_world.au > /dev/audio results in the error:
Sound error: Couldn't allocate DMA buffer.
I have been looking for a solution for 5 weeks now. Everything I have
tried has failed.
I have recompiled sound into the kernel. I have rebooted and tried the
sound test first thing (i.e: before memory fragmentation occurs) I have
tried different IRQ and DMA settings during compile (in case I was
wrong...) I have tried different buffer sizes. I have checked for DMA
and IRQ conflicts.
Finally I bought a used brand name Sound Blaster 16 and repeated all
my efforts. I STILL GET THE SAME ERROR!!!
Surely someone can help me! I have yet to find him (or her)
My system:
Kernel 2.0.33 running on a
486DX2-66 with 20 Megs RAM
Trident 8900 VESA local bus video with 1 Meg
Adaptec 1542CF SCSI controller with 2 drives totalling 600 Megs
Diamond Supra Express 56K modem
WD8013 Network card
1.44 and 1.2 Meg floppies
--
Eric F. Peterson
Politically Incorrect and Proud!
------------------------------
From: [EMAIL PROTECTED] (John Edstrom)
Crossposted-To: alt.destroy.microsoft,comp.os.linux.advocacy,comp.os.os2.advocacy
Subject: Re: Anti-Linux FUD
Date: 28 Dec 1998 20:11:28 GMT
In article <766hi5$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Floyd Davidson) writes:
>
> John Edstrom <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (Floyd Davidson) writes:
...
>>However, with symlink you can store two separate pieces of
>>information, the filename and the fake filename. I'm not sure if that
...
>>One possible advantage that I can see is that the link acts something
>>like an associative array in Perl (key/value pairs) where I don't have
...
>
> Can you provide an example where this "efficiency" is able to be
> exploited? I can't imagine any.
Nope. I don't use this idiom, I just saw it mentioned here and
wondered if I could think of a practical use for it. Its one of
things I like about UNIX... I'm always being invited to learn new ways
to look at and reuse old stuff. It may well be a wasteful or
inefficient to do most things, but its a degree of freedom I can
explore and then use or not use as I choose.
>
> I don't see advantage to the "two values" stored in a symlink,
> because only one of them can be related to the other, and that
> one has to be unique in that relationship. You can point
It would depend on what you are trying to do. For example, you can
test for the existence of the key without recovering its associated
value simply by testing for the existence of the file and ignoring
what its linked to. If you ask 'has "foo" been defined?' a lot and
'what is the value of "foo"?' rarely, I can see where there would be
an advantage to this way of doing things.
> several symlinks at the same nonexistent filename, but finding
> all symlinks related to any given filename is relatively an
> expensive operation. Hence I can't see where a symlink is
> more useful than just an empty file with data embedded in the
> name.
>
Yes, but you don't always want to go the reverse direction.
> And frankly I can't see that as useful either! Any single such
> item alone would be more efficient yes, but what practical use
> is there for single data objects? If a data object has any
> relationship to some other data object or if accessing it
> multiple times is important, then putting them both into one
> file as data makes access far easier and quicker than having
> them in a directory. The more items or the more complex the
> relationship, the more effective a data file(s) is.
>
The more _generally_ effective a data file is. I don't think anyone
was advocating this as a replacement for a general purpose relational
database server. The original point was that for quick retrieval of
simple key/value pairs, this can be a quick, simple, robust method.
> Remember that accessing a directory is arbitrarily difficult,
...
The two relevant factors here are the efficiency of the file system
and the life cycle of the program. I don't know the internals of the
various unix file systems, but I doubt that if the filenames are
looked up via a hash table somehow it would be much slower than a hash
lookup in a database file. There may also be performance benefits by
having the search done at system level filename lookup as opposed to a
user level search in user memory.
It would also make a difference if the application looks up several
key/value pairs or only one in its lifetime. I.e. do many instances
of an application each want one or two key/value pairs, or does one
instance of an application want dozens of key/value pairs at once?
>
> Floyd
>
>
------------------------------
From: [EMAIL PROTECTED] (Anthony Ord)
Crossposted-To: alt.destroy.microsoft,comp.os.linux.advocacy,comp.os.os2.advocacy
Subject: Re: Anti-Linux FUD
Date: Mon, 28 Dec 1998 20:11:40 GMT
On 27 Dec 1998 23:57:57 GMT, [EMAIL PROTECTED] (Floyd
Davidson) wrote:
>John Edstrom <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] (Floyd Davidson) writes:
>>>
<snip>
>>> The only thing stored is a filename for a file which does not
>>> exit, so I'm not sure what value there is in being able to
>>> access it quickly. (And in fact, ls doesn't access it any
>>> faster than it does synlinks to files that do exist... ;-(
>>
>>The idea is to save time on opening, reading and then closing the
>>file, obviously. Creating empty files with 'touch' might work as well
>>I don't know if zero-length files tie up more resources or are slower
>>to read than empty links.
>>
>>However, with symlink you can store two separate pieces of
>>information, the filename and the fake filename. I'm not sure if that
>>would be an advantage though. That is, is there an advantage to
>>reading the directory entry 'foo->bar' as opposed to 'foo_bar'?
>>
>>One possible advantage that I can see is that the link acts something
>>like an associative array in Perl (key/value pairs) where I don't have
>>to read the value part if I don't want to. With the atomic filename I
>>have to read both key and value together and then parse it to
>>disentangle the key from the value. Uniqueness is at the key level
>>for symlinks and at the coarser key/value level for single filenames.
>>I could find symlink 'foo' with just 'ls foo.' To find file 'foo_bar'
>>when I don't know that 'bar' is the value, I'd have to 'ls foo_*',
>>which might be costly.
>
>Can you provide an example where this "efficiency" is able to be
>exploited? I can't imagine any.
>
>I don't see advantage to the "two values" stored in a symlink,
>because only one of them can be related to the other, and that
>one has to be unique in that relationship.
Yes, so you make the unique one the filename, and the ununique [sic]
one the symlink value. No matter how much you screw up, you are
guaranteed an unique filename. Aren't you?
>You can point
>several symlinks at the same nonexistent filename, but finding
>all symlinks related to any given filename is relatively an
>expensive operation.
Of course. Finding all employees called 'Bob' in a personnel database
is an expensive operation unless it is indexed, and who indexes on
first names?
>Hence I can't see where a symlink is
>more useful than just an empty file with data embedded in the
>name.
Because I can have files 'name1_value1'; 'name2_value1';
'name1_value2'; 'name2_value2' simultaneously. In the above example
what is the value of 'name 1'?
>And frankly I can't see that as useful either! Any single such
>item alone would be more efficient yes, but what practical use
>is there for single data objects?
Wallpaper -> RhonaMitra.bmp
>If a data object has any
>relationship to some other data object or if accessing it
>multiple times is important, then putting them both into one
>file as data makes access far easier and quicker than having
>them in a directory.
In UNIX, directories are implemented as files. If the OS in question
cannot open a directory efficiently, then it isn't going to open files
efficiently either.
>The more items or the more complex the
>relationship, the more effective a data file(s) is.
The concept was originally a file-based registry. (i.e. permanent
hierarchial storage). Someone suggested having a thousand files each
with just one value in. The whole idea of the symlink was to have the
value in the 'name', so it could be accessed without the overhead of
opening, reading, and closing a file. Also you'd save one block per
filename.
>Remember that accessing a directory is arbitrarily difficult,
What do you mean by 'arbitrarily difficult'? I take it to mean 'as
difficult as you want to make it' which is surely not what you mean.
>depending on how many entries are in the directory. That is not
>necessarily a function that the accessing program can control.
>On the other hand a data file only needs to be found one time
>(one directory search), and thereafter access is exclusively
>under the control of the program. (Why search a 1000 times
>through a directory with 1000 entries to find one entry, when
>that could be done once, and then the search is 1000 times in a
>file with far fewer entries,
If the directory and the file represent identical things, then they
will have identical numbers of values.
>and which can have a data structure
>designed specifically for fast data retrieval.)
Well I wouldn't have any of the above as a personal preference. The
filesystem based registry is simply not my cup of tea, although I seem
to have come up with an efficient way of implementing it. I would
prefer a human-readable, flat text-file based way of storing
configuration data. The above might be a good implementation, but I
feel the registry concept is a poor API.
> Floyd
Regards
Anthony
--
===============================================================
|'All kids love log!' |
| Ren & Stimpy |
===============================================================
------------------------------
From: [EMAIL PROTECTED] (Michal Jaegermann)
Crossposted-To:
comp.os.linux.networking,comp.os.linux.portable,comp.os.linux.powerpc,comp.os.linux.setup
Subject: Re: Easy UNIX editor
Date: 28 Dec 1998 19:51:01 GMT
Reply-To: [EMAIL PROTECTED]
CSO Visitor ([EMAIL PROTECTED]) wrote:
: > > N. Richard Caldwell wrote:
: > > > Inserting one character is a worst case proposition for vi. Whatever
: > > > time you lose in those rare instances is recouped 1000 times over
: > > > during normal use simply because it's so efficient in most other
: > > > respects.
: > > >
: This is hardly a "rare instance"! I spend a good fraction of my vi
: time doing it.
Then why you are not using one from a long list of non-modal editors?
There are so many to choose from very simple ones, like xedit or pico,
to emacs on a "high end".
--mj
------------------------------
Crossposted-To: comp.unix.misc
From: [EMAIL PROTECTED] (F. Heitkamp)
Subject: Re: cpio-2.4.2 and Linux
Reply-To: [EMAIL PROTECTED]
Date: 28 Dec 1998 12:21:11 GMT
In message <[EMAIL PROTECTED]> - Gary Momarison <[EMAIL PROTECTED]>
writes:
>
>[EMAIL PROTECTED] (F. Heitkamp) writes:
>
>
>No, just use "afio" instead. It's better for tape use
>anyway as it can compress each file before putting it
>in the archive and so can recover from tape corruption
>better than a compressed tar or cpio archive.
I installed afio, but haven't tried it yet. Does it
take basically the same options?
>
>If anyone knows a reason not to use afio, please post it.
I've also been looking for a dump/restore programs like
they use on the big Unix boxes. I've found the src to a
dump program so far.
I had been using tar, but I keep reading tar is bad for
full system backups.
Fred
------------------------------
Date: Mon, 28 Dec 1998 14:08:32 -0600
From: Dwight Hubbard <[EMAIL PROTECTED]>
Subject: Re: New Problem to Old Solution?
[EMAIL PROTECTED] wrote:
> installed, since it's a copy of Red Hat 5.0 off of the Sam's Teach Yourself
> Linux book. In any case, I also tried the mount -t msdos option, and still
If my memory isn't completely gone, RedHat 5.0 didn't have support for the newer
fat32 filesystem that newer versions of windows 95 use. You aren't using Win-95
OSR2 by chance?
------------------------------
From: "Eric Hesselberg" <[EMAIL PROTECTED]>
Subject: Installing two copies of Linux
Date: 28 Dec 1998 15:09:41 -0500
I have Redhat 5.0 and I have installed two copies on different
partitions on my hard drive. The older version will not mount the
hard drive so I get a kernel panic. I have changed fstab file to reflect
the changed but it still does not boot. What other files
reference what drive to boot from? Thanks
Eric Hesselberg
------------------------------
From: "Eric Hesselberg" <[EMAIL PROTECTED]>
Subject: Installing two copies of Linux
Date: 28 Dec 1998 15:11:16 -0500
I have Redhat 5.0 and I have installed two copies on different
partitions on my hard drive. The older version will not mount the
hard drive so I get a kernel panic. I have changed fstab file to reflect
the changed but it still does not boot. What other files
reference what drive to boot from? Thanks
Eric Hesselberg
------------------------------
From: [EMAIL PROTECTED] (Michael Kelly)
Subject: Re: Installing two copies of Linux
Date: Mon, 28 Dec 1998 16:03:10 -0500
On 28 Dec 1998 10:19:30 -0500, "Eric Hesselberg" <[EMAIL PROTECTED]>
wrote:
>I have Redhat 5.0 and I have installed two copies on different
>partitions on my hard drive. The older version will not mount the
>hard drive so I get a kernel panic. I have changed fstab file to reflect
>the changed but it still does not boot. What other files
>reference what drive to boot from? Thanks
>
>
>Eric Hesselberg
Did you run rdev on the kernel after you moved it to the new partition?
Mike
"Genius gives birth, talent delivers."
- Jack Kerouac
(remove NOSPAM from address, if present, to reply)
------------------------------
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Crossposted-To:
alt.destroy.microsoft,comp.os.linux.advocacy,comp.os.os2.advocacy,comp.os.linux.x,gnu.misc.discuss,uk.comp.os.linux
Subject: Re: Is Microsoft a nasty company ? I'm asking you this question.
Date: Mon, 28 Dec 1998 21:54:05 GMT
On 28 Dec 1998 18:06:30 GMT, joseph_a_philbrook__iii
wrote these thought provoking words :
: While I think this thread has a lot of good stuff that I'd hate to see get
: lost in a blast of gratuitous MS bashing, I think the fact that the subject
: line is:
:
: Subject: Re: Is Microsoft a nasty company ? I'm asking you this question.
:
: makes it highly unlikely that we can expect to keep MS vendetta's out of the
: argument<g>
Oops.:-) The thread had really strayed so much off topic that I had
stopped noticing the original subject.
I have found though that bringing microsoft into arguments like these
usually bring flairs of emotion into the picture, and things rapidly
degenerate. It's a breath of fresh air to be able to discuss an issue
solely on principle.
-== Allie ==-
*----------------------*
Allie Martin (Mr.)
<[EMAIL PROTECTED]>
*---------/*\----------*
------------------------------
From: [EMAIL PROTECTED] (Matthew Malthouse)
Crossposted-To: comp.os.linux.advocacy,uk.comp.os.linux
Subject: PPC [Was: Re: Anti-Linux FUD]
Date: Mon, 28 Dec 1998 19:49:05 +0000
In article <[EMAIL PROTECTED]>,
jeramy <[EMAIL PROTECTED]> wrote:
} OOh...a fellow LinuxPPC user. how bout that. IBM does not like people
} like us. There was a quote the other day from them that said AIX is for
} turn-key useres while Linux is for tinkerers. Ive used AIX and I would
} have to say that there view is skewed a bit.
}
} Anyways X should work much better when R5 of LinuxPPC comes out. Debian
} may already be fine.
My first ever experience with Un*x was being throw into the deep end of an
AIX based production system. As a friend says "AIX - smit happens". It
didn't kate much to persuade me that AIX was more trouble than it was worth
and IBM unhelpful.[0]
ObLinux: At some time in the near future I may have some RS6000 350 & 240
machines become redundant.[1] Can anyone provide some pointers to Linux on
these boxes if such is possible?
Matthew
[0] Understatement
[1] Mostly 'cause IBM don't want to make the newer OS's work on older
machines.
--
"Homo sum: humani nihil a me alienum puto"
http://www.calmeilles.demon.co.uk/index.html
------------------------------
** 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.misc) 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-Misc Digest
******************************
