[9fans] what a mess the Unix world has become

[9fans] what a mess the Unix world has become

[Aharon Robbins]

I forward this for the amusement of the list members.  My initial
reply to this question was that the "Unix guru gives up in disgust
and moves to Plan 9."  Would that I could.

Arnold

> Date: Sat, 8 Feb 2003 09:37:50 -0700 (MST)
> Subject: Readable files: a Unix philosophy question for gurus
>
> In "man test", we find this documentation:
>
>        -r FILE
>               FILE exists and is readable
>
> Similar wording appears in vendor man pages, although Compaq OSF/1
> is a bit more precise:
>
>        -r file
>            TRUE if file exists and has read permission.
>
> Consider a file with these permissions:
>
> 	% ls -l foo.xml
> 	-rwSr-Srwx    2 beebe    staff      174440 Feb  8 08:20 foo.xml
>
> created by
>
> 	chmod u+s,g+s,o+rwxt foo.xml
>
> Now look at this:
>
> (1) On the file server:
>
> 	/bin/test -r foo.xml && echo file is readable
> 	file is readable
>
> 	/usr/local/bin/test -r foo.xml && echo file is readable
> 	file is readable
>
> 	/usr/local/bin/test --version
> 	test (GNU coreutils) 4.5.6
> 	...
>
> 	/bin/cat foo.xml > /dev/null
>
> 	echo $?
> 	0
>
> (2) On a [Sun Solaris 2.8] client, where the filesystem is mounted via
>     NFS with the attributes remote/read/write/nosuid/grpid/intr/noquota:
>
> 	/bin/test -r foo.xml && echo file is readable
> 	[no output]
>
> 	/usr/local/bin/test -r foo.xml && echo file is readable
> 	file is readable
>
> 	/bin/cat foo.xml > /dev/null
> 	cat: cannot open foo.xml
>
> 	/usr/local/bin/cat foo.xml > /dev/null
> 	/usr/local/bin/cat: foo.xml: Permission denied
>
> 	echo $?
> 	1
>
> The $65,536 question is: what should test report?  In this case, the
> setuid bit combined with the mount options makes the file unreadable,
> and the Solaris test command reflects that, but the GNU coreutils
> one does not.
>
> Experiments with native test on other systems produced these results:
>
> 	SGI IRIX 6.5:		file is readable, cat fails
> 	Compaq OSF/1 4.0:	no output from test, cat fails
>
> On AIX, my home filesystem is not mounted with special attributes, so
> I could not make the same experiment.
>
> On FreeBSD, chmod would not do g+s or o+t for me, and the file
> remained readable for both test and cat.
>
> My feeling is that the GNU version of test (going back to at least
> sh-utils 2.0.11 on Red Hat 7.2, and likely much earlier), and the IRIX
> version too, are wrong.
>
> I think that one really should be able to do "test -r foo && cat foo"
> without cat failing because of permissions.
>
> Comments?

Re: [9fans] what a mess the Unix world has become

[Mike Haertel]

> I think that one really should be able to do "test -r foo && cat foo"
> without cat failing because of permissions.

This could never be guaranteed to succeed, even with a supposedly
perfect version of "test", because "foo" might get altered between
the "test" and the "cat".

[9fans] mpg123

[Conor Williams]

ne one use mpg123?
I got it compiled but now im getting:
mpg123 107: suicide: sys: fp: division by zero: fppc=0x6389 status=0xb9b4
    pc=0x00006380

when I try and play anything using the command
mpg123 -s pc.mp3 > /dev/audio

any one got Tad Hunts email address - thats the guy who
ported over mpg123 to plan 9?
tx
will551

Re: [9fans] what a mess the Unix world has become

[Douglas A. Gwyn]

Aharon Robbins wrote:
>>I think that one really should be able to do "test -r foo && cat foo"
>>without cat failing because of permissions.

Yes, that was the intention.  But the question comes into
even sharper focus if you try to test for writability.
What OS facility is there for determining whether a file
would be writable without actually modifying the file?
The answer: access(2).  Not a mere examination of the
mode bits; not a trial write to the file.  When something
like NFS is bolted onto Unix, access(2) is one of the
things that needs to be made to work right; if NFS has
complicated access rules then that is what access() needs
to tap into.  (Better in the filesystem support than in
user-mode utilities.)
VAX/VMS had a "probe" call that, as I recall, checked
whether an operation would succeed but didn't do the
operation.
Of course, all such facilities are somewhat limited in
that the condition of the file might change between a
probe and actually doing the operation.  There are
transaction-oriented filesystems (MUMPS comes to mind)
that cluster requests until a "commit" and implement a
well-defined rollback scheme when the commit is
unsuccessful.

Re: [9fans] what a mess the Unix world has become

[Russ Cox]

> What OS facility is there for determining whether a file
> would be writable without actually modifying the file?

umm, open(2)?  this doesn't handle the AEXEC|AREAD
or AEXEC|AWRITE cases particularly well, and it's not
as fast as traditional access, but it gives good answers.

#include <u.h>
#include <libc.h>

int
access(char *name, int mode)
{
	int fd;
	Dir *db;
	static char omode[] = {
		0,
		OEXEC,
		OWRITE,
		ORDWR,
		OREAD,
		OEXEC,	/* only approximate */
		ORDWR,
		ORDWR	/* only approximate */
	};

	if(mode == AEXIST){
		db = dirstat(name);
		free(db);
		if(db != nil)
			return 0;
		return -1;
	}
	fd = open(name, omode[mode&7]);
	if(fd >= 0){
		close(fd);
		return 0;
	}
	return -1;
}

Re: [9fans] mpg123

[Russ Cox]

try http://pdos.lcs.mit.edu/~rsc/mp3dec.tgz.
it's a (possibly different) port of mpg123
that works well for me.  i don't remember who
did it originally.

RE: [9fans] mpg123

[Nigel Roles]

Because it computes (around ine 170 of layer3.c)

1 - tan(3 * Pi / 4)

which is 0

and then a series of values which involve dividing
by it.

In my experience, most mp3 code available on
lunix is full of this kind of stuff.

It's no wonder that if you port an encoder or decoder
from one platform to another you get a different answer.

It's only because the x86 FPU gives an answer to
tan(3 * PI / 4)

"that is almost, but not quite, entirely unlike"

-1 that this works at all.

Write out 100 times, "floating point numbers
are approximate numbers".

I would guess that row 9 of the table is not used,
so that putting

if (i == 9) continue;

in the loop will fix it.

-----Original Message-----
From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
Of Conor Williams
Sent: 10 February 2003 09:01
To: 9fans@cse.psu.edu
Subject: [9fans] mpg123


ne one use mpg123?
I got it compiled but now im getting:
mpg123 107: suicide: sys: fp: division by zero: fppc=0x6389 status=0xb9b4
    pc=0x00006380

when I try and play anything using the command
mpg123 -s pc.mp3 > /dev/audio

any one got Tad Hunts email address - thats the guy who
ported over mpg123 to plan 9?
tx
will551

RE: [9fans] mpg123

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

The mad player uses fixed point and is quite optimized.
I think the ported version is in our web page.
It's what I use in the bitsy and works properly there
(needless to say on a pc).

[-- Attachment #2: Type: message/rfc822, Size: 2753 bytes --]

From: "Nigel Roles" <nigel@9fs.org>
To: <9fans@cse.psu.edu>
Subject: RE: [9fans] mpg123
Date: Mon, 10 Feb 2003 14:14:56 -0000
Message-ID: <HOEHIDJJJINMLFPOLFJCIEKPCKAA.nigel@9fs.org>

Because it computes (around ine 170 of layer3.c)

1 - tan(3 * Pi / 4)

which is 0

and then a series of values which involve dividing
by it.

In my experience, most mp3 code available on
lunix is full of this kind of stuff.

It's no wonder that if you port an encoder or decoder
from one platform to another you get a different answer.

It's only because the x86 FPU gives an answer to
tan(3 * PI / 4)

"that is almost, but not quite, entirely unlike"

-1 that this works at all.

Write out 100 times, "floating point numbers
are approximate numbers".

I would guess that row 9 of the table is not used,
so that putting

if (i == 9) continue;

in the loop will fix it.

-----Original Message-----
From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
Of Conor Williams
Sent: 10 February 2003 09:01
To: 9fans@cse.psu.edu
Subject: [9fans] mpg123


ne one use mpg123?
I got it compiled but now im getting:
mpg123 107: suicide: sys: fp: division by zero: fppc=0x6389 status=0xb9b4
    pc=0x00006380

when I try and play anything using the command
mpg123 -s pc.mp3 > /dev/audio

any one got Tad Hunts email address - thats the guy who
ported over mpg123 to plan 9?
tx
will551

Re: [9fans] mpg123

[Axel Belinfante]

> The mad player uses fixed point and is quite optimized.
> I think the ported version is in our web page.
> It's what I use in the bitsy and works properly there
> (needless to say on a pc).

I used it, took it from your web page, but I found that
there are some mp3's which it doesn't play but which
mpg123 does play.  (something to do with mp3 headers?)

> Because it computes (around line 170 of layer3.c)
> 1 - tan(3 * Pi / 4)     which is 0
> and then a series of values which involve dividing
> by it.

I hacked around this in mpg123  by checking for a
divisor of 0.0 and replacing it by something small
but unequal to zero.  I got away with that but
Nigels solution (which I did not try) looks nicer.

> I would guess that row 9 of the table is not used,
> so that putting
>	 if (i == 9) continue;
> in the loop will fix it.

Axel.

Re: [9fans] mpg123

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 91 bytes --]

You have to compile madplay and not minimad.
Minimad does almost no error recovery at all.

[-- Attachment #2: Type: message/rfc822, Size: 3447 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mpg123
Date: Mon, 10 Feb 2003 15:53:00 +0100
Message-ID: <200302101453.h1AEr0Z20581@zamenhof.cs.utwente.nl>

> The mad player uses fixed point and is quite optimized.
> I think the ported version is in our web page.
> It's what I use in the bitsy and works properly there
> (needless to say on a pc).

I used it, took it from your web page, but I found that
there are some mp3's which it doesn't play but which
mpg123 does play.  (something to do with mp3 headers?)

> Because it computes (around line 170 of layer3.c)
> 1 - tan(3 * Pi / 4)     which is 0
> and then a series of values which involve dividing
> by it.

I hacked around this in mpg123  by checking for a
divisor of 0.0 and replacing it by something small
but unequal to zero.  I got away with that but
Nigels solution (which I did not try) looks nicer.

> I would guess that row 9 of the table is not used,
> so that putting
>	 if (i == 9) continue;
> in the loop will fix it.

Axel.

Re: [9fans] what a mess the Unix world has become

[Ronald G. Minnich]

On Mon, 10 Feb 2003, Douglas A. Gwyn wrote:

>There are
> transaction-oriented filesystems (MUMPS comes to mind)
> that cluster requests until a "commit" and implement a
> well-defined rollback scheme when the commit is
> unsuccessful.

Actually at some point in the 90s NFS became like that on SunOS (well,
minus the rollback system). That was about the time that close could
return an error, meaning "remember those writes you did yesterday? Well,
some of them may not have worked out, so you probably lost data. Have a
nice day."

Needless to say, many programs did not quite grasp the concept.

ron

Re: [9fans] mpg123

[Conor Williams]

it doesnt seem to be on the plan9.bell-labs site?
have u a url?
tx
will551

----- Original Message -----
From: "Fco.J.Ballesteros" <nemo@plan9.escet.urjc.es>
To: <9fans@cse.psu.edu>
Sent: Monday, February 10, 2003 2:34 PM
Subject: RE: [9fans] mpg123


> The mad player uses fixed point and is quite optimized.
> I think the ported version is in our web page.
> It's what I use in the bitsy and works properly there
> (needless to say on a pc).
>

Re: [9fans] mpg123

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 46 bytes --]

http://plan9.escet.urjc.es/ or just google :-)

[-- Attachment #2: Type: message/rfc822, Size: 2173 bytes --]

From: "Conor Williams" <connorwilliamsie@aol.com>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] mpg123
Date: Mon, 10 Feb 2003 15:53:16 -0000
Message-ID: <011001c2d11c$8685f290$4d4a800a@will551>

it doesnt seem to be on the plan9.bell-labs site?
have u a url?
tx
will551

----- Original Message -----
From: "Fco.J.Ballesteros" <nemo@plan9.escet.urjc.es>
To: <9fans@cse.psu.edu>
Sent: Monday, February 10, 2003 2:34 PM
Subject: RE: [9fans] mpg123


> The mad player uses fixed point and is quite optimized.
> I think the ported version is in our web page.
> It's what I use in the bitsy and works properly there
> (needless to say on a pc).
>

Re: [9fans] mpg123

[Tad Hunt]

I seem to remember something along these lines.  Try
running it like this:

	mpg123 < pc.mp3 > /dev/audio

I think there should be a README with the patch that
describes some crash like this.  Unfortunately I haven't
had time to touch any plan9 stuff for about two years.

-Tad

In message <017201c2d0e2$e7273d50$4d4a800a@will551>, you said:
;ne one use mpg123?
;I got it compiled but now im getting:
;mpg123 107: suicide: sys: fp: division by zero: fppc=0x6389 status=0xb9b4
;    pc=0x00006380
;
;when I try and play anything using the command
;mpg123 -s pc.mp3 > /dev/audio
;
;any one got Tad Hunts email address - thats the guy who
;ported over mpg123 to plan 9?
;tx
;will551

Re: [9fans] what a mess the Unix world has become

[Douglas A. Gwyn]

Ronald G. Minnich wrote:
> Actually at some point in the 90s NFS became like that on SunOS (well,
> minus the rollback system). That was about the time that close could
> return an error, meaning "remember those writes you did yesterday? Well,
> some of them may not have worked out, so you probably lost data. Have a
> nice day."

Unix has always been like that.  Write() would succeed if
a kernel buffer received the data, without waiting for the
actual transfer to the device.  This has been known to
cause great fun with terminal lines.

Re: [9fans] mpg123

[Conor Williams]

thanks Nigel
Heard my first plan9 mp3 late last night!
I ended up subtracting 0.001 from that eqation and let
it run the 1 -> 16 loop! doesnt seem to have warped it 2
much!
Russ & co - maybe set the default irq for a sb16 card to
5 as thats what it is out of the box!
l8r
will551

----- Original Message -----
From: "Nigel Roles" <nigel@9fs.org>
To: <9fans@cse.psu.edu>
Sent: Monday, February 10, 2003 2:14 PM
Subject: RE: [9fans] mpg123


> Because it computes (around ine 170 of layer3.c)
>
> 1 - tan(3 * Pi / 4)
>
> which is 0
>
> and then a series of values which involve dividing
> by it.
>
> In my experience, most mp3 code available on
> lunix is full of this kind of stuff.
>
> It's no wonder that if you port an encoder or decoder
> from one platform to another you get a different answer.
>
> It's only because the x86 FPU gives an answer to
> tan(3 * PI / 4)
>
> "that is almost, but not quite, entirely unlike"
>
> -1 that this works at all.
>
> Write out 100 times, "floating point numbers
> are approximate numbers".
>
> I would guess that row 9 of the table is not used,
> so that putting
>
> if (i == 9) continue;
>
> in the loop will fix it.
>
> -----Original Message-----
> From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu]On Behalf
> Of Conor Williams
> Sent: 10 February 2003 09:01
> To: 9fans@cse.psu.edu
> Subject: [9fans] mpg123
>
>
> ne one use mpg123?
> I got it compiled but now im getting:
> mpg123 107: suicide: sys: fp: division by zero: fppc=0x6389 status=0xb9b4
>     pc=0x00006380
>
> when I try and play anything using the command
> mpg123 -s pc.mp3 > /dev/audio
>
> any one got Tad Hunts email address - thats the guy who
> ported over mpg123 to plan 9?
> tx
> will551
>
>

Re: [9fans] what a mess the Unix world has become

[Geoff Collyer]

Checking close() return values after writing on a descriptor is good
hygiene, but as I recall, NFS made error detection harder by not
necessarily reporting write errors (even synchronous ones like ENOSPC)
via either write() or close(); one had to use fsync() just before the
close() to force any write errors to be reported.

 From code I wrote in the late 1980s:

/*
 * nfclose(stream) - flush the stream, fsync its file descriptor and
 * fclose the stream, checking for errors at all stages.  This dance
 * is needed to work around the lack of Unix file system semantics
 * in Sun's NFS.  Returns EOF on error.
 */

#include <stdio.h>

int
nfclose(stream)
register FILE *stream;
{
	register int ret = 0;

	if (fflush(stream) == EOF)
		ret = EOF;
	if (fsync(fileno(stream)) < 0)		/* may get delayed error here */
		ret = EOF;
	if (fclose(stream) == EOF)
		ret = EOF;
	return ret;
}

Re: [9fans] mpg123

[nigel]

> thanks Nigel
> Heard my first plan9 mp3 late last night!
> I ended up subtracting 0.001 from that eqation and let
> it run the 1 -> 16 loop! doesnt seem to have warped it 2
> much!

That's almost bound to be a bad decision. It will warp
all the values, rather than just the one which I suspect
is not used.

You forced me to get my copy of 11172-3 off the shelf.

These tables are used for intensity coding, e.g. the left
channel has the intensity of the frequency bucket,
the right channel the pan ratio.

Given that the equation is

ratio = tan(pos * pi / 12)
L' = L * ratio / (1 + ratio)
R' = R * 1 / (1 + ratio)

which can be rewritten as

ratio = tan(pos * pi / 12)
R = ratio/(1 + ratio)
L' = L * R
R' = L * (1 - R)

R = 0 pans fully to the right, and increasing values
tend towards the left. When R hits 1, it is fully
panned to the left.

The tan function tends to infinity at 90 degrees, or
PI/2 radians. Thus is makes no sense for pos to
take a value > 6. In fact, 6 itself is special. You can
interpret it as meaning R = 1.

The spec. indicates that pos == 7 disables the panning
effect.

So I contend that encoders will only generate values
from 0 - 7, even though the field can be 4 bits, only
3 are used for intensity coding. Thus my fix will
trash one row of the pow[] table which is generated
in the same loop, which does use 4 bits.

If you look at mad (libmad/layer3.c), you will see that
it confirms this. The implementor of mad clearly
thought about what this part of 11172-3 is supposed
to achieve.

A better fix is therefore:


  for(i=0;i<16;i++) {
    double r;

    if (i < 6) {
	double t = tan( (double) i * M_PI / 12.0 );
	r = t / (1.0 + t);
    }
    else
	r = 1.0;

    tan1_1[i] = r;
    tan2_1[i] = 1.0 - r;
    tan1_2[i] = M_SQRT2 * r;
    tan2_2[i] = M_SQRT2 * (1.0 - r);

Re: [9fans] mpg123

[Conor Williams]

nice 1 Nigel - that worked a peach.
There wasnt any noticable change warping wise
really...
I still like my 0.001 hack!

Tad & Russ - maybe incorporate the change
below into layer3.c on those 2 ports of mpg123.
l8r
will551
----- Original Message -----
From: <nigel@9fs.org>
To: <9fans@cse.psu.edu>
Sent: Tuesday, February 11, 2003 11:26 AM
Subject: Re: [9fans] mpg123


> > thanks Nigel
> > Heard my first plan9 mp3 late last night!
> > I ended up subtracting 0.001 from that eqation and let
> > it run the 1 -> 16 loop! doesnt seem to have warped it 2
> > much!
>
> That's almost bound to be a bad decision. It will warp
> all the values, rather than just the one which I suspect
> is not used.
>
> You forced me to get my copy of 11172-3 off the shelf.
>
> These tables are used for intensity coding, e.g. the left
> channel has the intensity of the frequency bucket,
> the right channel the pan ratio.
>
> Given that the equation is
>
> ratio = tan(pos * pi / 12)
> L' = L * ratio / (1 + ratio)
> R' = R * 1 / (1 + ratio)
>
> which can be rewritten as
>
> ratio = tan(pos * pi / 12)
> R = ratio/(1 + ratio)
> L' = L * R
> R' = L * (1 - R)
>
> R = 0 pans fully to the right, and increasing values
> tend towards the left. When R hits 1, it is fully
> panned to the left.
>
> The tan function tends to infinity at 90 degrees, or
> PI/2 radians. Thus is makes no sense for pos to
> take a value > 6. In fact, 6 itself is special. You can
> interpret it as meaning R = 1.
>
> The spec. indicates that pos == 7 disables the panning
> effect.
>
> So I contend that encoders will only generate values
> from 0 - 7, even though the field can be 4 bits, only
> 3 are used for intensity coding. Thus my fix will
> trash one row of the pow[] table which is generated
> in the same loop, which does use 4 bits.
>
> If you look at mad (libmad/layer3.c), you will see that
> it confirms this. The implementor of mad clearly
> thought about what this part of 11172-3 is supposed
> to achieve.
>
> A better fix is therefore:
>
>
>   for(i=0;i<16;i++) {
>     double r;
>
>     if (i < 6) {
>     double t = tan( (double) i * M_PI / 12.0 );
>     r = t / (1.0 + t);
>     }
>     else
>     r = 1.0;
>
>     tan1_1[i] = r;
>     tan2_1[i] = 1.0 - r;
>     tan1_2[i] = M_SQRT2 * r;
>     tan2_2[i] = M_SQRT2 * (1.0 - r);
>
>
>
>

Re: [9fans] what a mess the Unix world has become

[Ronald G. Minnich]

On Mon, 10 Feb 2003, C H Forsyth wrote:

> i don't quite see how they could provide a `commit' effect unless they finally
> added a Close operation to the clunky protocol.

that was the joy of it. NFS was a very informal business. Close turned to
a set of operations that were in essence a commit of cached writes. These
could fail ...

ron

Re: [9fans] what a mess the Unix world has become

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 129 bytes --]

i don't quite see how they could provide a `commit' effect unless they finally
added a Close operation to the clunky protocol.

[-- Attachment #2: Type: message/rfc822, Size: 2625 bytes --]

From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] what a mess the Unix world has become
Date: Mon, 10 Feb 2003 08:20:07 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0302100818320.23236-100000@carotid.ccs.lanl.gov>

On Mon, 10 Feb 2003, Douglas A. Gwyn wrote:

>There are
> transaction-oriented filesystems (MUMPS comes to mind)
> that cluster requests until a "commit" and implement a
> well-defined rollback scheme when the commit is
> unsuccessful.

Actually at some point in the 90s NFS became like that on SunOS (well,
minus the rollback system). That was about the time that close could
return an error, meaning "remember those writes you did yesterday? Well,
some of them may not have worked out, so you probably lost data. Have a
nice day."

Needless to say, many programs did not quite grasp the concept.

ron