Linux-Development-Sys Digest #499, Volume #6     Wed, 17 Mar 99 14:14:24 EST

Contents:
  CDR and Adaptec-1505 driver probs. (Frans Grotepass)
  Re: Threads and clone() (Roope Anttinen)
  Re: After Week 1 With Linux -- licking wounds. (Peter Samuelson)
  Re: kernel (Enrique Robledo Arnuncio)
  Re: After Week 1 With Linux -- licking wounds. (Alexander Viro)
  Re: After Week 1 With Linux -- licking wounds. (Peter Samuelson)
  Re: After Week 1 With Linux -- licking wounds. (Johan Kullstam)
  Re: After Week 1 With Linux -- licking wounds. (Mark Tranchant)
  newsgroup for fpk/ppc386 under linux (Thomas)
  Re: After Week 1 With Linux -- licking wounds. (Robert Krawitz)
  Re: Threads and clone() (accoday)
  select_wait (Wlmet)
  Re: kernel won't uncompress when boot from CD (Julian Robert Yon)
  Re: After Week 1 With Linux -- licking wounds. (Robert Krawitz)
  Re: Threads and clone() (Stefan Monnier)
  Re: After Week 1 With Linux -- licking wounds. (Anthony Ord)

----------------------------------------------------------------------------

From: Frans Grotepass <[EMAIL PROTECTED]>
Subject: CDR and Adaptec-1505 driver probs.
Date: Wed, 17 Mar 1999 16:03:52 +0200

I have driver problems it seems with my SCSI CDR.  I have an
adaptec-1505 controlling my 4020 HP CDR and a Connor harddrive. I bootup
on an IDE drive and I am presently running kernel 2.2.3.  I still have
the problems after upgrading from 2.0.36.  The problem arrises that.
when ripping with cdda2wav,  the system will simply hang under certain
circumstances.  The CD usually has a scratch on it and the process will
hang at the scratch.  The whole system dies.  I am not even capable to
access the system through ssh or even telnet.. The machine doesn't even
ping.  Under 2.0.36 I found that the cdda2wav will fall over and the
process willnot be removable from the process list, not even with kill
-9.

If anybody has any idea what is happening.  it would be cool,  since I'm
completely puzzled.   I am going to try cdparanoia again though.

Frans Grotepass



------------------------------

From: Roope Anttinen <[EMAIL PROTECTED]>
Subject: Re: Threads and clone()
Date: 17 Mar 1999 14:03:53 GMT
Reply-To: [EMAIL PROTECTED]

H. Reinecke <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Mike Delaney) writes:
> > Now, what I'd like to know is: Are we going to see the threads start sharing
> > the same PID, as the POSIX draft dictates?
> Errm, to achieve what ?
> I can't really think of a necessity for that, apart from being POSIX
> enslaved.

For example to be able to write some kind of "Task manager" which can tell
the amount of threads inside a process. You could with the recent approach
try to compare the size of processes inside a process family but that's not
very reliable way to identify a thread.

Roope

-- 
MicroSoft? is that some kind of a toilet paper?
PS: Look for address here, not from headers. And remove NOSPAM's
___________________________________________________________________________
   [EMAIL PROTECTED]  /  [EMAIL PROTECTED]
        +358 9 812 7567  /  +358 500 445 565  /  +358 49 445 565
                http://myy.helia.fi/~anttiner/index.html
===========================================================================
   Helsinki Business Polytechnic - Institute of information technology

------------------------------

From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 08:11:29 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>

[Steve Smith <[EMAIL PROTECTED]>]
> Most Windoze users don't read the manual.  (Big surprise, right? :-)
> Also, most Windoze users are not technical types, and are terrified
> of experimentation.  Might mess up the system.

To be fair, they come by it honestly.  Between personal experience and
peer advice, everyone knows that Windoze can get messed up -- freezing
and sometimes needing to be reinstalled -- more or less unpredictably.
And, furthermore, they know that this is not uncommon.  No wonder
Windoze users are gun-shy.

-- 
Peter Samuelson
<sampo.creighton.edu!psamuels>

------------------------------

From: Enrique Robledo Arnuncio <[EMAIL PROTECTED]>
Subject: Re: kernel
Date: Wed, 17 Mar 1999 15:18:13 +0100

Eldhose John wrote:
> 
> Hi,
> I am new comer to Linux. I wanted to find out how the kernel works,
> so I searched through the source code. But it was an unplesent experince
> I could not find any starting point. Please help me to solve the mistory.

The starting point is in fact architecture-dependent. You can find that
kind of stuff under arch/xxx/boot. Most of it is asm, some of it is
real-
mode code (for the i386). If you are interested in the detailed startup
files 
sequence, I can give you details for the i386 arch, 2.0.36 kernel
version 
(I don't think there have been any changes). 

But you probably are not interested in the kernel loading process, 
uncompression, etc. The first "c" function you should look at, common
to all the platforms is init/main.c, the start_kernel() function.
This function calls the initialization functions for most parts of 
the kernel.

In some point, the first system call, setup() is called. (man 2 setup)
This routine initialices devices, filesystems, etc.

enjoy!

   Enrique.

-- 
=================================================================
Enrique Robledo Arnuncio
Departamento de Ingeniería Electrónica
ETSI Telecomunciación                   Tlf:     +34 1 5495700
                                                      Ext. 401
Avda. Complutense s/n
Madrid 28040  SPAIN                 mailto: [EMAIL PROTECTED]
=================================================================

------------------------------

From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 09:22:28 -0500

In article <7coa0i$t2k$[EMAIL PROTECTED]>,
Peter Samuelson <[EMAIL PROTECTED]> wrote:
>I think his point was that NT lets you switch to a resolution/refresh
>without logging out, restarting the X server, etc. -- in fact you can
>test one out without committing to it.  It is a valid point.  But not a
>particularly important one, in the grand scheme of things.

RTFM.

$ man -k "video mode"
[snip 5 aliases for rdev]
xvidtune (1x)        video mode tuner for XFree86.
$ man xvidtune
[all f****** details]

See also Ctrl-Alt-+ and Ctrl-Alt-- (or next/prev buttons in xvidtune).
They switch between the modes you have. Yep, no logouts, no restarting the
server, etc.

-- 
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

------------------------------

From: [EMAIL PROTECTED] (Peter Samuelson)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 08:40:41 -0600
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>


  [Peter Samuelson <sampo.creighton.edu!psamuels>]
> > I think his point was that NT lets you switch to a
> > resolution/refresh without logging out, restarting the X server,
> > etc. -- in fact you can test one out without committing to it.  It
> > is a valid point.  But not a particularly important one, in the
> > grand scheme of things.
[Alexander Viro <[EMAIL PROTECTED]>]
> RTFM.
> 
> xvidtune (1x)        video mode tuner for XFree86.

I'm well aware of xvidtune.  It's not the same thing.  Neither is
Ctrl-Alt-+.  XFree86 forces you to have *one* virtual resolution and
*one* bit depth in any given session.  Probably the constraints of the
X protocol have something to do with this.  Also, you cannot *add* a
display setting to your configuration without restarting the X server
-- Ctrl-Alt-+ just lets you cycle through the ones you have already
defined.  Like it or not, the NT model is handier, so long as you are
happy with VESA-standard settings.  (Although of course it is far from
perfect.  Why in the world, for example, do they make display modes
user-configurable but not user-specific?)

-- 
Peter Samuelson
<sampo.creighton.edu!psamuels>

------------------------------

From: Johan Kullstam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 08:26:22 -0500

[EMAIL PROTECTED] (Rupert K. Snoopowitz) writes:

> David M. Cook ([EMAIL PROTECTED]) swallowed a lutefisk whole and belched:
> > On Sat, 13 Mar 1999 13:53:23 -0600, Rupert K. Snoopowitz
> > <[EMAIL PROTECTED]> wrote:
> > 
> > >But Unix is not a modern OS.  
> > 
> > This fetish for modernity is starting to grate on my nerves.  It's simply a
> > fact that Linux outperforms NT is many situations.  I don't know enough to
> > say whether NT is better designed than Linux, but if so it's quite obvious
> > that Microsoft didn't follow through very well in their implementation.
> 
> Unix is not a modern OS, imho, because of its reliance on a command-line 
> interface and the fact that the thinking that went into designing the 
> whole idea of the Unix human interface is 20 years old -- the age of 
> mainframes, before PC's were to come on the scene.  

a command line shell is not an operating system.  it's just an
interface.  you can use a graphical one if you wish.  nothing prevents
throwing the shell out and placing whatever you like in its place.
afaik apple is doing exactly this with macos-x.

on the other hand, a scripting language is a good thing too.  when you
need to duplicate the same or similar task a hundred times, the GUI
becomes hell and you find yourself wishing for a decent programming
language.  the shell also a poor man's programming language.

> A time not too long 
> after the punch-cards.  I would think that we've learned a considerable 
> amount about what makes a good UI (in fact, we have, and there are 
> numerous books written entirely on the subject).  

and sometimes, all that pontificating is worthless.  it depends on
what you are doing and how you like to organize your task.

> Yes, I know about X-
> Windows.  It is NOT a good GUI. ( ... A relative concept, I know.)

X isn't even a GUI.  it's a network capable graphics driver.  no
wonder you are dissappointed.

> I would never claim NT could out perform Linux in terms of internal 
> efficiency and reliability.  I will say this, though:  It took me about a 
> day to set up NT and get it running from scratch.  It took me a week (so 
> far) with Linux and I'm still not done.  I have had no prior experience 
> with either OS prior to the first installation.

fair enough.  although i find myself fiddling incessantly with my NT
box at work too.

-- 
johan kullstam

------------------------------

From: Mark Tranchant <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: Wed, 17 Mar 1999 14:44:48 +0000
Reply-To: [EMAIL PROTECTED]

Alexander Viro wrote:

> In article <7coa0i$t2k$[EMAIL PROTECTED]>,
> Peter Samuelson <[EMAIL PROTECTED]> wrote:
> >I think his point was that NT lets you switch to a resolution/refresh
> >without logging out, restarting the X server, etc. -- in fact you can
> >test one out without committing to it.  It is a valid point.
 
> $ man -k "video mode"
> [snip 5 aliases for rdev]
> xvidtune (1x)        video mode tuner for XFree86.
> $ man xvidtune
> [all f****** details]
> 
> See also Ctrl-Alt-+ and Ctrl-Alt-- (or next/prev buttons in xvidtune).
> They switch between the modes you have. Yep, no logouts, no restarting the
> server, etc.
> 

You can't change colour depth though, which you can with MS-Windows (see
the QUICKRES Power Toy). I use 1024x768 in 8bpp most of the time in
Windows, but occasionally switch to 640x480 in 24bpp for graphics work
(1MB video card, you see).

Mark.

------------------------------

Date: Wed, 17 Mar 1999 17:33:07 +0100
From: Thomas <[EMAIL PROTECTED]>
Subject: newsgroup for fpk/ppc386 under linux

Hello,

is there a newsgroup for fpk/ppc386 under linux
or other sources for help with it ?

CU,
 Thomas

------------------------------

From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 09:52:37 -0500

[EMAIL PROTECTED] (Gordon Scott) writes:

> Robert Krawitz ([EMAIL PROTECTED]) wrote:
> : [EMAIL PROTECTED] (Rupert K. Snoopowitz) writes:
> 
> : OK, so do I find all files that are greater than 1 MB in size, that
> : are named something like '*.News.log*', that were modified more
> : than 90 days ago, and don't live in directories named "Preserve"? 
> 
> You forgot to mention that find also allows you to execute a script
> for each file it finds or for all the files it found.

Indeed I did.

> : find . \( -type f -size +2048 -mtime +90 -name '*.News.log*' -print \)
> :     -o -type d -name Preserve -prune
> 
> : OK, it's admittedly a bit hairy
> 
> But then you did deliberately pick a hairy requirement.

But my requirement, such as it was, was fairly realistic.  Change
'*.News.log*' to 'core.*' (which at least some kernels seem to
generate) and it's suddenly a very realistic requirement -- find all
large core files more than 90 days old except for those in Preserve
directories.

-- 
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: accoday <[EMAIL PROTECTED]>
Subject: Re: Threads and clone()
Date: Wed, 17 Mar 1999 07:51:22 -0800

Mike Delaney wrote:
> 
> Now, what I'd like to know is: Are we going to see the threads start sharing
> the same PID, as the POSIX draft dictates?
>
I'd actually like to know when there will be better support for
debugging multi-threaded apps on Linux.  Something the proc-fs on Sparc
would be great.  IMHO, a proc-fs interface for debugging would be better
than ptrace regardless of multi-threading.

-Aaron

------------------------------

From: [EMAIL PROTECTED] (Wlmet)
Subject: select_wait
Date: 17 Mar 1999 18:08:35 GMT

extern inline void select_wait(struct wait_queue ** wait_address, select_table
* p)
{
        struct select_table_entry * entry;

        if (!p || !wait_address)
                return;
        if (p->nr >= __MAX_SELECT_TABLE_ENTRIES)
                return;
        entry = p->entry + p->nr;
        entry->wait_address = wait_address;
        entry->wait.task = current;
        entry->wait.next = NULL;
        add_wait_queue(wait_address,&entry->wait);
        p->nr++;
}

In the above code it seems that p->nr must be multiplied by size of a select
table entry somewhere for the code to work but I don't see this in the code
anywhere. Does anyone know what is going on here?

------------------------------

From: Julian Robert Yon <[EMAIL PROTECTED]>
Subject: Re: kernel won't uncompress when boot from CD
Date: Wed, 17 Mar 1999 15:22:50 +0000

Phil Howard wrote:

> Format it with a filesystem.  For most filesystems you can use the appropriate
> variation of mkfs, but you will probably need the -F option to force it to
> ignore that it is not a real device.  For MS-DOS, all I find to do formatting
> is mformat, and I can't get it to work on a file.  So I stored a compressed
> copy of a pre-formatted floppy for that purpose.

Use losetup to associate the file with a loopback device such as
/dev/loop0 (major 7, minor is number of device, ie 0). Then you can use
any tools on this that work on a normal block device.


Julian

=============================
Julian R Yon
LunariX team & PianOS project

Email: [EMAIL PROTECTED]
       [EMAIL PROTECTED]
=============================

------------------------------

From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 17 Mar 1999 09:40:29 -0500

Darin Johnson <[EMAIL PROTECTED]> writes:

> > > The CLI is primative.  This has been proven years ago with the Mac and 
> > > its resulting copy-cat of Windows.  Now, please go postal and stop 
> > > threatening.
> 
> This "proven" thing must be a different definition than in my
> dictionary.
> 
> Anyway, eating food is primitive, sex is primitive, silicon is even
> more primitive, etc.

Perhaps the word "venerable" would serve well here.
-- 
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: Stefan Monnier 
<[EMAIL PROTECTED]>
Subject: Re: Threads and clone()
Date: 17 Mar 1999 12:02:42 -0500

>>>>> "Mike" == Mike Delaney <[EMAIL PROTECTED]> writes:
> Now, what I'd like to know is: Are we going to see the threads start sharing
> the same PID, as the POSIX draft dictates?

I've heard rumors (months ago) of maybe (who knows) at some point potentially
start considering the eventual possibility of perhaps setting up a mailing-list
to decide whether or not someone should take a look at the realizability
of a study that might lead later to a prototype implementation of 32bit PID
split into 16bit processID and 16bit threadID.


        Stefan

------------------------------

From: [EMAIL PROTECTED] (Anthony Ord)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: Wed, 17 Mar 1999 18:40:04 GMT

On Mon, 15 Mar 1999 16:56:04 -0600, Tim Kelley
<[EMAIL PROTECTED]> wrote:

>
>
>jedi wrote:
>> 
>> On Mon, 15 Mar 1999 13:48:35 -0600, Rupert K. Snoopowitz <[EMAIL PROTECTED]> 
>wrote:
>> >Tim Kelley ([EMAIL PROTECTED]) swallowed a lutefisk whole and belched:
>
>> >> Look, the cli has it's place.  For those that bother to learn it is is a
>> >> more efficient and powerful way of computing (you tell the computer what
>> >> to do instead of it asking you what you want).
>> >> The CLI is an experts interface, but it is NOT PRIMITIVE.  If I hear the
>> >> "cli is primitive" shit anymore I'm going postal.
>> >
>> >The CLI is primative.  This has been proven years ago with the Mac and
>> >its resulting copy-cat of Windows.  Now, please go postal and stop
>> >threatening.
>
>Look you nitwit, if you had any idea that computers were used for things
>OTHER than playing with picture files or downloading and viewing porn,
>you would know that the cli has it use.
>Photoshop and Desktop publishing is NOT the summit of computer
>technology.
>
>Try using a GUI/menu system to increase the disk quotas of 10,000 users
>by 10% (to borrow someone else's example on this thread), or to quickly
>change permissions over an entire directory structure selecting only
>certain objects.  How about removing the trailing periods from hundreds
>files within whole directory structure (as I had to do recently)?  What
>if you wanted to do it only on Tuesdays at 4:00PM and every other
>Saturday at 1:00AM?  

How about something easy. Create 15 directories using
explorer and bash. These directories can be called anything
you want. "Dick" "Dave" "Esmerelda"... for an example.

Time yourself.

>Menus/GUIs are hopeless for most admin tasks because they limit the
>choices one can make.  CLI's are for people who want the computer to do
>the work for them.  

CLIs are much better than GUIs when the object you want to
manipulate doesn't exist yet.

>You can't put small things together in a meaningful and new ways unless
>you have cli tools as in unix.  Sorry.  Go play in your MacinToy world,
>please stay away from things you don't understand if you aren't curious.

Regards

Anthony
-- 
=========================================
| And when our worlds                   |
| They fall apart                       |
| When the walls come tumbling in       |
| Though we may deserve it              |
| It will be worth it  - Depeche Mode   |
=========================================

------------------------------


** 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
******************************

Reply via email to