Re: [OT] Joerg Schilling flames Linux on his Blog

Re: [OT] Joerg Schilling flames Linux on his Blog

[jmerkey]

As Linus once commented to me, just let this stuff roll off your back 
and ignore it. 
Patrick, just ignore this smuck.  If this is his opinion, people will 
evaluate it
as such.  Linux speaks for itself, and it's worldwide use speaks for itself.

Jeff

Patrick McFarland wrote:

>As everyone knows, Joerg Schilling has a blog, and he often pushes his 
>pro-Solaris agenda, and flames the LKML about how Linux breaks cdrecord 
>(instead of just admitting cdrecord is broken) or how much more awesome 
>Solaris is compared to Linux.
>
>Well, he just fired yet another salvo at the Linux community: 
>http://schily.blogspot.com/2005/04/value-marketing-and-freedom.html
>
>I commented on his blog entry, but I am afraid of being censored as my views 
>do not align with his, so I am including the text of my comment here:
>
>////
>I suggest people don't read too much into what Schily says. He thinks Solaris 
>is this almighty perfect operating system that crushes all others: The reason 
>Solaris is failing is because more and more people are switching to other 
>operating systems. And yes, Linux just happens to be the one that most are 
>switching to; BSD and QNX are also other choices.
>
>Most of the people switching to Linux are not doing so because its GPL, not 
>because its associated with other Free Software, and not because the source 
>is available. They are switching simply because it is the best product out 
>there at this time; and as I see it, it will continue to be the best product 
>because Linux software developers are not sitting around arguing about what 
>license is better, or what features other operating systems have or don't 
>have.
>
>Linux developers code, OpenSolaris developers sit around and flame Linux 
>developers instead of coding. Which operating system would _you_ choose?
>////
>
>  
>

[OT] Joerg Schilling flames Linux on his Blog

[Patrick McFarland]

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

As everyone knows, Joerg Schilling has a blog, and he often pushes his 
pro-Solaris agenda, and flames the LKML about how Linux breaks cdrecord 
(instead of just admitting cdrecord is broken) or how much more awesome 
Solaris is compared to Linux.

Well, he just fired yet another salvo at the Linux community: 
http://schily.blogspot.com/2005/04/value-marketing-and-freedom.html

I commented on his blog entry, but I am afraid of being censored as my views 
do not align with his, so I am including the text of my comment here:

////
I suggest people don't read too much into what Schily says. He thinks Solaris 
is this almighty perfect operating system that crushes all others: The reason 
Solaris is failing is because more and more people are switching to other 
operating systems. And yes, Linux just happens to be the one that most are 
switching to; BSD and QNX are also other choices.

Most of the people switching to Linux are not doing so because its GPL, not 
because its associated with other Free Software, and not because the source 
is available. They are switching simply because it is the best product out 
there at this time; and as I see it, it will continue to be the best product 
because Linux software developers are not sitting around arguing about what 
license is better, or what features other operating systems have or don't 
have.

Linux developers code, OpenSolaris developers sit around and flame Linux 
developers instead of coding. Which operating system would _you_ choose?
////

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [OT] Joerg Schilling flames Linux on his Blog

[Markus Plail]

Patrick McFarland <pmcfarland@downeast.net> writes:
> As everyone knows, Joerg Schilling has a blog, and he often pushes his
> pro-Solaris agenda, and flames the LKML about how Linux breaks
> cdrecord (instead of just admitting cdrecord is broken) or how much
> more awesome Solaris is compared to Linux.
>
> Well, he just fired yet another salvo at the Linux community:
> http://schily.blogspot.com/2005/04/value-marketing-and-freedom.html
>
> I commented on his blog entry, but I am afraid of being censored as my
> views do not align with his, so I am including the text of my comment
> here:

At least here I can see your comment.

regards
Markus

Re: [OT] Joerg Schilling flames Linux on his Blog

[Matthias-Christian Ott]

Patrick McFarland wrote:
> As everyone knows, Joerg Schilling has a blog, and he often pushes his 
> pro-Solaris agenda, and flames the LKML about how Linux breaks cdrecord 
> (instead of just admitting cdrecord is broken) or how much more awesome 
> Solaris is compared to Linux.
> 
> Well, he just fired yet another salvo at the Linux community: 
> http://schily.blogspot.com/2005/04/value-marketing-and-freedom.html
> 
> I commented on his blog entry, but I am afraid of being censored as my views 
> do not align with his, so I am including the text of my comment here:
> 
> ////
> I suggest people don't read too much into what Schily says. He thinks Solaris 
> is this almighty perfect operating system that crushes all others: The reason 
> Solaris is failing is because more and more people are switching to other 
> operating systems. And yes, Linux just happens to be the one that most are 
> switching to; BSD and QNX are also other choices.
> 
> Most of the people switching to Linux are not doing so because its GPL, not 
> because its associated with other Free Software, and not because the source 
> is available. They are switching simply because it is the best product out 
> there at this time; and as I see it, it will continue to be the best product 
> because Linux software developers are not sitting around arguing about what 
> license is better, or what features other operating systems have or don't 
> have.
> 
> Linux developers code, OpenSolaris developers sit around and flame Linux 
> developers instead of coding. Which operating system would _you_ choose?
> ////
> 
He's maybe a sympathizer of Solaris (remember that the Slab was developed by Sun for Solaris). I don't like Sun, but 
anyway he's right.

Matthias-Christian Ott

Re: [OT] Joerg Schilling flames Linux on his Blog

[Lee Revell]

On Fri, 2005-05-20 at 20:34 +0200, Matthias-Christian Ott wrote:
> He's maybe a sympathizer of Solaris (remember that the Slab was developed by Sun for Solaris). I don't like Sun, but 
> anyway he's right.

I also sympathize with that part of his argument (though it does not
make Schily less of a jerk).  Solaris has had some very cool features
like priority inheritance and fully preemptible kernel for 10 plus years
that Linux either is just getting, or does not have.

Lee

Re: [OT] Joerg Schilling flames Linux on his Blog

[Brian O'Mahoney]

I agree that Joerg Schilling should be entirely ignored; cdrecord is
hopelessly broken writing DVDs and looking at the code, I am not
surprised, it is designed to make you buy the his PRO-DVD product but
fortunately Open Source healed itself, in the usual way.

Solaris is a hostage to the SUN QA group, which is FAR too powerful,
so they argue "keep it out" so vanilla Solaris just sucks, but, within
SUN there is an OS tool-chain group which builds useful tools
and publishes a DVD and runs a download service, This stuff needs
to be pushed into the mainstream. There is NO evidence that SUN
management, increasingly PHB, even understands the issue.

If I need a Python or Ruby platform do I use sun or Linux on X-arc?

This and the failure to see that they must open source Java just
indicate how clueless SUN senior leadership now is.

The real problem is insecure sys admins, throughout the industry, who
resist what developers are trying to do, cos it isnt on the (Solaris)
distribution CDs

Finally SUN should move from the pkg* abortion, written by idiots
at AT&T, some 25 years ago to RPM.

-- 
mit freundlichen Grüßen, Brian.

Re: [OT] Joerg Schilling flames Linux on his Blog

[Adrian Bunk]

On Sat, May 21, 2005 at 01:20:19AM +0200, Brian O'Mahoney wrote:
>...
> Finally SUN should move from the pkg* abortion, written by idiots
> at AT&T, some 25 years ago to RPM.

In my personal experience, the Solaris packages are quite usable.

I don't claim they were perfect, but do you have compelling reasons why 
you call the people who developed it "idiots"?

> mit freundlichen Grüßen, Brian.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [OT] Joerg Schilling flames Linux on his Blog

[Bernd Petrovitsch]

On Sat, 2005-05-21 at 09:38 +0200, Adrian Bunk wrote:
[...]
> In my personal experience, the Solaris packages are quite usable.

Did you ever see Solaris installations without GNU-tools from
sunfreeware.com installed?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [OT] Joerg Schilling flames Linux on his Blog

[Måns Rullgård]

Bernd Petrovitsch <bernd@firmix.at> writes:

> On Sat, 2005-05-21 at 09:38 +0200, Adrian Bunk wrote:
> [...]
>> In my personal experience, the Solaris packages are quite usable.
>
> Did you ever see Solaris installations without GNU-tools from
> sunfreeware.com installed?

That's irrelevant.  The question was about the usability of the
Solaris package system, compared to RPM, not about the software inside
the packages.

-- 
Måns Rullgård
mru@inprovide.com

Re: [OT] Joerg Schilling flames Linux on his Blog

[André Tomt]

Bernd Petrovitsch wrote:
> Did you ever see Solaris installations without GNU-tools from
> sunfreeware.com installed?

Hnngh! Missing dependencies (do the package format support it at all?), 
no splitting (why should I need apache2 for the portability library 
libapr?), odd things like needing sunfreeware gzip instead of the 
solaris one in some packages (something that you don't notice until its 
too late)... its like going way back in time to slackware.

</rant>

-- 
Cheers,
André Tomt
With his rookie Solaris admin hat on.

Re: [OT] Joerg Schilling flames Linux on his Blog

[Brian O'Mahoney]

Adrian Bunk wrote:
> On Sat, May 21, 2005 at 01:20:19AM +0200, Brian O'Mahoney wrote:
> 
>>...
>>Finally SUN should move from the pkg* abortion, written by idiots
>>at AT&T, some 25 years ago to RPM.
> 
> 
> In my personal experience, the Solaris packages are quite usable.
> 
> I don't claim they were perfect, but do you have compelling reasons why 
> you call the people who developed it "idiots"?

The point I made was that SUN do support/use the GNU toolchain
internally, and everyone has used GNU on SUN since they started to
charge for the Solaris C compiler in the 80's. They also have RPM
and it is only recently they integrated Perl and I object to this
attitude whether it comes from SUN or MicroSoft

As to pkg* just look at what is missing/deficient -v- any OpenSource
tool, which was desingned by those that were going to _use_ it not
just tick a check box

It is typical of the period in which AT&T had more Marketeers and Lawers
working on Unix that there were developers. These were the guys who
helped to start the Unix wars.

-- 
mit freundlichen Grüßen, Brian.

Re: [OT] Joerg Schilling flames Linux on his Blog

[Adrian Bunk]

On Sat, May 21, 2005 at 01:41:37PM +0200, André Tomt wrote:
> Bernd Petrovitsch wrote:
> >Did you ever see Solaris installations without GNU-tools from
> >sunfreeware.com installed?
> 
> Hnngh! Missing dependencies (do the package format support it at all?), 

Solaris packages support dependencies.
That's what the "depend" file is for.

> no splitting (why should I need apache2 for the portability library 
> libapr?), odd things like needing sunfreeware gzip instead of the 
> solaris one in some packages (something that you don't notice until its 
> too late)... its like going way back in time to slackware.

Brian complained about the package format and not about specific 
packages.

I've also seen horrible rpm or dpkg packages, but that's irrelevant when 
talking about package formats.

> </rant>
> Cheers,
> André Tomt
> With his rookie Solaris admin hat on.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [OT] Joerg Schilling flames Linux on his Blog

[Adrian Bunk]

On Sat, May 21, 2005 at 06:39:38PM +0200, Brian O'Mahoney wrote:
> 
> 
> Adrian Bunk wrote:
> > 
> > In my personal experience, the Solaris packages are quite usable.
> > 
> > I don't claim they were perfect, but do you have compelling reasons why 
> > you call the people who developed it "idiots"?
> 
> The point I made was that SUN do support/use the GNU toolchain
> internally, and everyone has used GNU on SUN since they started to
> charge for the Solaris C compiler in the 80's. They also have RPM
> and it is only recently they integrated Perl and I object to this
> attitude whether it comes from SUN or MicroSoft
> 
> As to pkg* just look at what is missing/deficient -v- any OpenSource
> tool, which was desingned by those that were going to _use_ it not
> just tick a check box

It was nice if you would name the points why you think Solaris packages 
are that inferior to e.g. RPM or dpkg packages.

E.g. if you know a standard way how to get the same functionality as 
request/pkgask in Solaris packages for RPM packages I'd be glad to hear 
about.

Not that I'd claim that Solaris packages were perfect.

Some examples:
- Solaris packages don't support upgrades of packages.
- I know in neither RPM nor Solaris packages a mechanism similarly 
  powerful to the dpkg diversions.

I'd personally say dpkg is the best of this three package formats. But I 
have to admit that RPM is the one amongst them I know the least, and you 
can correct my statements regarding RPM if you know better.

But altogether, I don't see any of these three package formats being 
hopelessly inferior to the other two.

> It is typical of the period in which AT&T had more Marketeers and Lawers
> working on Unix that there were developers. These were the guys who
> helped to start the Unix wars.

You said:

  Finally SUN should move from the pkg* abortion, written by idiots
  at AT&T, some 25 years ago to RPM.

If you call people "idiots", you should at least be able to give some 
hard facts where exactly they should have done something different based 
on the knowledge that was available at the time they did it.

And it seems you also missed that the Solaris package format has evolved 
over the years.

> mit freundlichen Grüßen, Brian.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [OT] Joerg Schilling flames Linux on his Blog

[Andre Tomt]

Adrian Bunk wrote:
> On Sat, May 21, 2005 at 01:41:37PM +0200, André Tomt wrote:
> 
>>Bernd Petrovitsch wrote:
>>
>>>Did you ever see Solaris installations without GNU-tools from
>>>sunfreeware.com installed?
>>
>>Hnngh! Missing dependencies (do the package format support it at all?), 
> 
> 
> Solaris packages support dependencies.
> That's what the "depend" file is for.

Great, now if sunfreeware would just use it ;-)

Disclaimer: I havn't checked the entire archive.

>>no splitting (why should I need apache2 for the portability library 
>>libapr?), odd things like needing sunfreeware gzip instead of the 
>>solaris one in some packages (something that you don't notice until its 
>>too late)... its like going way back in time to slackware.
> 
> 
> Brian complained about the package format and not about specific 
> packages.
> 
> I've also seen horrible rpm or dpkg packages, but that's irrelevant when 
> talking about package formats.

I was talking about sunfreeware.com packages. Maybe it wasn't clear enough.

-- 
Cheers,
André Tomt

Re: [OT] Joerg Schilling flames Linux on his Blog

[Andrew Haninger]

> ... flames the LKML about how Linux breaks cdrecord
> (instead of just admitting cdrecord is broken)

I've always used cdr-tools on Linux and Windows since it is the
only/best tool for mastering CDs. It takes the installation of Joerg's
library, but after that, it's worked wonderfully. This is even the
tool that is suggested by the HOWTOs that newbies are told to read. It
has always appeared to me that it was the only/best tool.

If it's broken, then surely there's an unbroken drop-in replacement
program that should be used. And surely it works much better than
cdr-tools and is easier to use. However, after a few seconds of Google
searches, I was unable to find it.

So what is the new tool that is suggested to be used? I'd rather not
be using broken software. Thanks.

(This is really only a half-sarcastic reply. I really would like to
know if there's a better tool. However, I'm also trying to point out
that Joerg's software seems to be all that can be used at the moment
and so it's hard for me as a humble end-user to really care if his
software is broken since it works.)

Re: [OT] Joerg Schilling flames Linux on his Blog

[Patrick McFarland]

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

On Saturday 21 May 2005 09:22 pm, Andrew Haninger wrote:
> > ... flames the LKML about how Linux breaks cdrecord
> > (instead of just admitting cdrecord is broken)
>
> I've always used cdr-tools on Linux and Windows since it is the
> only/best tool for mastering CDs. It takes the installation of Joerg's
> library, but after that, it's worked wonderfully. This is even the
> tool that is suggested by the HOWTOs that newbies are told to read. It
> has always appeared to me that it was the only/best tool.

I was refering to the 2.6 permissions bug in cdrecord. It wouldn't work using 
a non-root user, even if they had the correct permissions. 2.6 changed (for 
the better, mind you), and Joerg refused to fix cdrecord. (I don't know if 
its even fixed now). Theres been other cases of cdrecord breaking on Linux 
only, but I can't think of them atm.

> If it's broken, then surely there's an unbroken drop-in replacement
> program that should be used. And surely it works much better than
> cdr-tools and is easier to use. However, after a few seconds of Google
> searches, I was unable to find it.

I really wish someone would build a replacement for cdrecord, but Joerg just 
hasn't pissed off that potential author enough.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [OT] Joerg Schilling flames Linux on his Blog

[Matthias Andree]

On Sun, 22 May 2005, Andre Tomt wrote:

> Great, now if sunfreeware would just use it ;-)

Check http://www.blastwave.org/ - they use the depend file and support
Solaris 8 - 10 on x86 and SPARC IIRC. Don't quote me on the versions
though.

-- 
Matthias Andree

Re: [OT] Joerg Schilling flames Linux on his Blog

[Matthias Andree]

On Sun, 22 May 2005, Patrick McFarland wrote:

> On Saturday 21 May 2005 09:22 pm, Andrew Haninger wrote:
> > > ... flames the LKML about how Linux breaks cdrecord
> > > (instead of just admitting cdrecord is broken)
> >
> > I've always used cdr-tools on Linux and Windows since it is the
> > only/best tool for mastering CDs. It takes the installation of Joerg's
> > library, but after that, it's worked wonderfully. This is even the
> > tool that is suggested by the HOWTOs that newbies are told to read. It
> > has always appeared to me that it was the only/best tool.
> 
> I was refering to the 2.6 permissions bug in cdrecord. It wouldn't work using 
> a non-root user, even if they had the correct permissions. 2.6 changed (for 

sudo works for me, and I'd rather use that than rely on someone writing
spaghetti code making this safe to use as suid code...

> I really wish someone would build a replacement for cdrecord, but Joerg just 
> hasn't pissed off that potential author enough.

Arrange for funding, find sponsors, and then hire someone.

-- 
Matthias Andree

Re: [OT] Joerg Schilling flames Linux on his Blog

[Alistair John Strachan]

On Sunday 22 May 2005 02:22, Andrew Haninger wrote:
> > ... flames the LKML about how Linux breaks cdrecord
> > (instead of just admitting cdrecord is broken)
>
> I've always used cdr-tools on Linux and Windows since it is the
> only/best tool for mastering CDs. It takes the installation of Joerg's
> library, but after that, it's worked wonderfully. This is even the
> tool that is suggested by the HOWTOs that newbies are told to read. It
> has always appeared to me that it was the only/best tool.
>
> If it's broken, then surely there's an unbroken drop-in replacement
> program that should be used. And surely it works much better than
> cdr-tools and is easier to use. However, after a few seconds of Google
> searches, I was unable to find it.
>
> So what is the new tool that is suggested to be used? I'd rather not
> be using broken software. Thanks.
>

cdrdao
http://cdrdao.sourceforge.net/

Does DAO. Can burn subchannel data. Can burn an audio CD.

dvd+-rw-tools
http://fy.chalmers.se/~appro/linux/DVD+RW/

Burns DVD+/-R, though it does use mkisofs (iirc) which is part of cdrtools. 
Seems to burn DVD+R which I have mixed success with the Mandrake fork of 
cdrtools (no fault of Joerg, necessarily).

Therefore I'd recommend you install an unpatched, Joerg original version of 
cdrtools, burn DAOs and audio CDs with cdrdao, and use dvd+-rw-tools 
exclusively for burning DVDs. This combination has served me well, and since 
mastering it I've had no coaster discs.

Up to date GUI tools like k3b (http://k3b.sourceforge.net/) will make all 
these recommendations and set everything up for you. I don't use it myself, 
but I when I've seen it working, it looked good.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:    CS/CSim Undergraduate
contact:    1F2 55 South Clerk Street,
            Edinburgh. EH8 9PP.

Re: [OT] Joerg Schilling flames Linux on his Blog

[Bernd Petrovitsch]

On Sat, 2005-05-21 at 13:33 +0200, Måns Rullgård wrote:
> Bernd Petrovitsch <bernd@firmix.at> writes:
> > On Sat, 2005-05-21 at 09:38 +0200, Adrian Bunk wrote:
> > [...]
> >> In my personal experience, the Solaris packages are quite usable.
> >
> > Did you ever see Solaris installations without GNU-tools from
> > sunfreeware.com installed?
> 
> That's irrelevant.  The question was about the usability of the
> Solaris package system, compared to RPM, not about the software inside
> the packages.

Sorry, I misunderstand that.

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

Re: [OT] Joerg Schilling flames Linux on his Blog

[Bernhard Rosenkraenzer]

On Sunday 22 May 2005 06:50, Patrick McFarland wrote:
> I really wish someone would build a replacement for cdrecord, but Joerg
> just hasn't pissed off that potential author enough.

Actually it has
http://www.freesoftware.fsf.org/dvdrtools/

It's a fork of the last "free" cdrecord (as in, without #ifdef NOT_MY_VERSION 
printf("Warning, you're using broken crap") and eliminates quite a few 
braindamages, such as the build system, the absence of DVD support, the 
anti-Linux and anti-GNU-Make comments and associated delays, but is otherwise 
still pretty close to the original (help in fixing the rest of the rest is 
welcome!).

LLaP
bero

Re: [OT] Joerg Schilling flames Linux on his Blog

[Nix]

On 20 May 2005, Patrick McFarland suggested tentatively:
> As everyone knows, Joerg Schilling has a blog, and he often pushes his 
> pro-Solaris agenda, and flames the LKML about how Linux breaks cdrecord 
> (instead of just admitting cdrecord is broken) or how much more awesome 
> Solaris is compared to Linux.
> 
> Well, he just fired yet another salvo at the Linux community: 
> http://schily.blogspot.com/2005/04/value-marketing-and-freedom.html

His research sucks.

: Later, the LGPL has been created and parts of the GCC (libgcc) has
: been put under LGPL.

Wrong. It is trivial to check gcc/libgcc*c and observe that libgcc is
*not* LGPLed, but licensed under the GPL plus an exception permitting
unrestricted linkage to proprietary software. (Related exceptions are
used for the libstdc++ headers and the Ada runtime.)

Just before that, he said:

: This acceptance has not been present from the beginning. In the
: beginning, the whole GCC has been published under the GPL and thus could
: not be used to compile software that itself has not been published under
: the GPL. For this reason, there has been an excited discussion about the
: usability of GCC.

Note that in Joerg's worldview, a mistake equals conspiracy. This is a
classic kook's mindview. Jeff's right: the best thing we can do is to
just ignore him.

-- 
`Once again, I must remark on the far-reaching extent of my
 ladylike nature.' --- Rosie Taylor

Re: [OT] Joerg Schilling flames Linux on his Blog

[Brian O'Mahoney]

1__

The GPL says nothing about using a GPL, or non-free tool to create
something else, and cannot since it is a copyright based licence.

2__

He has decided what the answer MUST be ... now the reasoning. Here we
have a Solaris shill!

-- 
mit freundlichen Grüßen, Brian.

Re: [OT] Joerg Schilling flames Linux on his Blog

[Nix]

On Mon, 23 May 2005, Brian O'Mahoney said:
> 1__
> 
> The GPL says nothing about using a GPL, or non-free tool to create
> something else, and cannot since it is a copyright based licence.

The point of libgcc is that it is *linked in* to generated programs, and
thus under the FSF's interpretation might force those programs to be
covered by the GPL. Hence the exception, to make it clear that this is
not the case.

(It is even more necessary for the libstdc++ headers and Ada runtime,
as they are respectively textually included and included in cross-module
inlining...)

> 2__
> 
> He has decided what the answer MUST be ... now the reasoning. Here we
> have a Solaris shill!

Nah, it's not that simple: apparently he flames them, too. I think we
can safely say he is no-one's pansy. (Now he might be impossible to
please, but that's a different matter.)

-- 
`Once again, I must remark on the far-reaching extent of my
 ladylike nature.' --- Rosie Taylor

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>" <7eggert@gmx.de> wrote:

> I just burned a CD on my IDE-burner using mmc_cdr with cdrtools-2.01
> (the one without the hack) on a vanilla 2.6.11.10. I can even scan
> both my SCSI and IDE devices using -dev=ATAPI, but not without -dev.

The unability to give this kind of convenience to cdrecord users is a result
of the refusal of the Linux kernel crew to include the kernel internal 
device instance numbers in the ioctl structures I need to read. Note that the
fields are there but the information is intentionally obscured for come of the 
calls just to make the life of cdrecord useers harder :-(


> (I'm running as user, and cdrecord has no need for suid bits.)

I am frequently reading false claims like this. Usually from people who 
do not have the needed SCSI background knowledge to understand that 
SCSI is a protocol where commands frequently fail by intention in order to
propagate a state or a implementation level to the application.

If you don't call cdrecord as root, you will not be able to lock in memory
and to raise priority in order to prevent buffer underuns. In addition (with 
Linux-2.6.8.1 or newer) you will not be able to send some of the important
SCSI commands mainly related to newer CD or DVD drives. As a result, cdrecord
cannot write DVDs or ultra speed CD-RWs or cannot do other things....


> > If Linux plans to implement incompatible changes, I would expect that
> > "important users" are informed in advance so that it is possible to discuss
> > the problems an to have a planned smooth migration.
>
> While, in the meantime, users can destroy the hardware.

Not true: if only R/W fd would be allowed, no non root program could do that.

>
> <OT>
>
> BTW while talking about destroying hardware: Turning off burnproof so the
> drives that have this feature _for a reason_ will destroy my CD-Rs like
> a outdated CD-recorder would is doubleplusungood, even if it creates
> consistent behaviour across drives. It's like waring no seat belt in
> your car just because curricles didn't have them. ¢¢
>
> </OT>

See above, this false claim is a result of the fact that you miss the background
knowledge on CD/DVD writing. Turning burnproof on degrades the quality of the 
media and writing without burnproof but with the apropriate privilleges just
works fine.


> There are other uses for write access to devices. Disabeling SCSI commands
> for r/o fds would only be a quickfix. (IMHO it could have been introduced
> as a config option and gone away in 2.6.13.)

The good/bad SCSI commands table that is currently used is a really bad and
ugly (incorrect) hack and much worse than my proposal.


> > P.S.: About 10 days ago, I made an attempt to include a workaround for the
> > interface changes in Linux, check cdrtools-2.01.01a03
>
> The fix is wrong: You're asuming root is capable of everything. This
> doesn't need to be true (missing CAP_SYS_RAWIO) and you'll run into a
> loop in that case.

If you are really true, then there is a design problem in Linux.

BTW: If Linux starts introducing fine grained rights manamement like on Solaris, why 
does it miss the apropriate management tools at user level?
On Solaris, I could run cdrecord rootless if I use pfksh as my shell and if
the roles database would include cdrecord with its needed privilleges and me
as a member of the cdwriters role.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Kyle Moffett]

On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
> "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>"  
> <7eggert@gmx.de> wrote:
>> I just burned a CD on my IDE-burner using mmc_cdr with cdrtools-2.01
>> (the one without the hack) on a vanilla 2.6.11.10. I can even scan
>> both my SCSI and IDE devices using -dev=ATAPI, but not without -dev.
>
> The unability to give this kind of convenience to cdrecord users is  
> a result
> of the refusal of the Linux kernel crew to include the kernel internal
> device instance numbers in the ioctl structures I need to read.

There is a specific reason that the numbers are _kernel_internal_!!!   
I set up
my udev so that my green CD burner is /dev/green_burner, and my blue  
CD burner
is /dev/blue_burner.  Please tell me again why exactly I can't just  
give the
option -dev=/dev/green_burner and have it use my green CD burner?   
That's a lot
easier than messing with random groups of 3 numbers and trying to  
remember in
which order I plugged in my burners, and which kernel I'm running, so  
I can
remember the enumeration order, etc.

> Note that the fields are there but the information is intentionally  
> obscured
> for come of the calls just to make the life of cdrecord useers  
> harder :-(

The information is obscured because userspace shouldn't know or care

>> (I'm running as user, and cdrecord has no need for suid bits.)
>
> I am frequently reading false claims like this. Usually from people  
> who
> do not have the needed SCSI background knowledge to understand that
> SCSI is a protocol where commands frequently fail by intention in  
> order to
> propagate a state or a implementation level to the application.

What exactly is false about the claim?

> If you don't call cdrecord as root, you will not be able to lock in  
> memory
> and to raise priority in order to prevent buffer underuns.

I burn CDs fine all the time as a user, and I _don't_ need to lock  
memory or
raise priority, because I have a good scheduler, plenty of RAM, and  
dual CPUs.
It would be nice if you could let me leave on the _hardware_ BurnProof
technology designed to prevent that sort of thing, but it doesn't  
appear to
fit with your ideals of 100% perfect CDs, does it?  Besides, by the  
time we
hit the point where BurnProof would turn on, the disk is either  
completely
dead and useless (no burnproof), or slightly scarred and still  
useable (with
burnproof).  Personally, I'd rather have the latter.

> In addition (with Linux-2.6.8.1 or newer) you will not be able to  
> send some
> of the important SCSI commands mainly related to newer CD or DVD  
> drives. As
> a result, cdrecord cannot write DVDs

I was not under the impression that the free cdrecord could write DVDs.

> or ultra speed CD-RWs or cannot do other things....

Did you try submitting a list of important SCSI commands and their  
functions?
I suspect that if you provide a clear, concise list of harmless  
commands,
they would be included in the available command set.

> Not true: if only R/W fd would be allowed, no non root program  
> could do that.

Uhh, but I don't run cdrecord as root.  My /dev/green_burner device  
is owned
by root, has group "media", and perms rw-rw-r--.  Since this is a  
somewhat public
machine with lots of users in the "media" group, I don't want anybody  
to be able
to turn my drives into bricks.

> See above, this false claim is a result of the fact that you miss  
> the background
> knowledge on CD/DVD writing. Turning burnproof on degrades the  
> quality of the
> media and writing without burnproof but with the apropriate  
> privilleges just
> works fine.

Why can't you just provide an option to leave it on?  My Mac and Windows
computers seem to do just fine with it.  In fact, all modern CD-ROM  
drives
were designed to be able to read such "degraded" media, even "degraded"
media that also has scratches and dents and dings and scars and all  
sorts
of other glitches in the CD surface.

Re: [OT] Joerg Schilling flames Linux on his Blog

[Alexander E. Patrakov]

On Thursday 26 May 2005 05:31, Kyle Moffett wrote:

> Did you try submitting a list of important SCSI commands and their
> functions?
> I suspect that if you provide a clear, concise list of harmless
> commands,
> they would be included in the available command set.

That list would be device-dependent. See two examples below.

1) cdrecord uses some Sony proprietary commands instead of standard MMC ones 
if the drive seems to be made by Sony. What is the effect of those Sony 
commands on non-Sony drives?

2) I have the following DVD-ROM + CD-RW combo drive:

'PHILIPS ' 'CDD5301         ' 'P1.2'

Originally, I bought it with the 'B1.1' firmware revision. This drive with old 
firmware is a security hole by itself: if one calls cdrecord dev=/dev/hdd 
-dao some-image.iso, the drive will enter some strange mode at the end. In 
particular, it will flash its light randomly, will never give the CD back 
(waited 15 minutes), and will prevent communication with /dev/hdc until I 
power off the computer (pressing Reset is not enough). Burning CDs with -raw 
switch instead of -dao works. With newer firmware, -dao doesn't lock up the 
drive, but still results in damaged CDs.

Also this drive always silently produces CDs with a lot of wrong bits (but a 
useless and broken image can still be read with dd or readcd) when BurnFree 
is off.

So this filter, if it is in the kernel, should forbid commands specific to SAO 
burning for this drive _and_ also return a modified list of capabilities for 
this drive (i.e. say that this drive _cannot_ burn in SAO mode).

Isn't this too much knowledge for the kernel?

-- 
Alexander E. Patrakov
P.S. I know that the proper solution would be to replace the drive. I tried 
returning it to the shop, they said "no, it is in order because it works with 
Nero in Windows" and fined me for $25 for their "expertize".

Re: [OT] Joerg Schilling flames Linux on his Blog

[Giuseppe Bilotta]

On Thu, 26 May 2005 09:45:01 +0600, Alexander E. Patrakov wrote:

> That list would be device-dependent. See two examples below.
> 
> 1) cdrecord uses some Sony proprietary commands instead of standard MMC ones 
> if the drive seems to be made by Sony. What is the effect of those Sony 
> commands on non-Sony drives?
> 
> 2) I have the following DVD-ROM + CD-RW combo drive:
> 
> 'PHILIPS ' 'CDD5301         ' 'P1.2'
> 
> Originally, I bought it with the 'B1.1' firmware revision. This drive with old 
> firmware is a security hole by itself: if one calls cdrecord dev=/dev/hdd 
> -dao some-image.iso, the drive will enter some strange mode at the end. In 
> particular, it will flash its light randomly, will never give the CD back 
> (waited 15 minutes), and will prevent communication with /dev/hdc until I 
> power off the computer (pressing Reset is not enough). Burning CDs with -raw 
> switch instead of -dao works. With newer firmware, -dao doesn't lock up the 
> drive, but still results in damaged CDs.
> 
> Also this drive always silently produces CDs with a lot of wrong bits (but a 
> useless and broken image can still be read with dd or readcd) when BurnFree 
> is off.
> 
> So this filter, if it is in the kernel, should forbid commands specific to SAO 
> burning for this drive _and_ also return a modified list of capabilities for 
> this drive (i.e. say that this drive _cannot_ burn in SAO mode).
> 
> Isn't this too much knowledge for the kernel?

Isn't this exactly the knowledge the kernel, not the apps, should
have? What if I wanted to use a different CD burning program? Why
should we have duplicate knowledge about the hardware?

Do you picture every PCI-accessing userland program to have its own
copy of pciids & relative knowledge?

-- 
Giuseppe "Oblomov" Bilotta

"I weep for our generation" -- Charlie Brown

Re: [OT] Joerg Schilling flames Linux on his Blog

[Alexander E. Patrakov]

Bodo Eggert wrote:

>So we can
>
>1) give up and let any application with write access destroy the hardware
>  
>
That won't be a problem if all apps with write access are running as 
root or setuid and thus the list of them is well-controlled by root.

>2) implement a basic filter (common for all deviced) and a device-specific 
>   filter, which can be set by a userspace application.
>  
>
In fact both approaches are used in the kernel.

(1) is used in the usbfs code, and thus SANE and gPhoto2 rely upon it 
(BTW it's still possible for a user to install an old version of SANE 
into /home/user and damage a scanner). Proper filtering in the kernel 
would be probably just too complex in this "usb generic" case.

(2) is used e.g. in DRM code.

What's missing is a clearly stated policy that says which of those two 
approaches should be applied in each particular case.

-- 
Alexander E. Patrakov

Re: [OT] Joerg Schilling flames Linux on his Blog

[Alexander E. Patrakov]

On Thursday 26 May 2005 16:15, Joerg Schilling wrote:

> The problem was that you could send SCSI commands on R/O fds and fixing the
> problem would have been to forbid sending SCSI commands on R/O fds.

Unfortunately, this is not going to work. It would work only if the only app 
that has to send SCSI commands were cdrecord. Then really, a non-setuid 
program just would not be able to get a R/W fd, and setuid ones are assumed 
to be trusted.

The problem is that many CD audio players also send SCSI commands in order to 
extract digital audio data. Are you proposing to make them setuid root? use a 
well-defined setuid helper? other solution?

-- 
Alexander E. Patrakov

Re: OT] Joerg Schilling flames Linux on his Blog

[Bill Davidsen]

Kyle Moffett wrote:
> On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
> 
>> "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>"  
>> <7eggert@gmx.de> wrote:
>>
>>> I just burned a CD on my IDE-burner using mmc_cdr with cdrtools-2.01
>>> (the one without the hack) on a vanilla 2.6.11.10. I can even scan
>>> both my SCSI and IDE devices using -dev=ATAPI, but not without -dev.
>>
>>
>> The unability to give this kind of convenience to cdrecord users is  a 
>> result
>> of the refusal of the Linux kernel crew to include the kernel internal
>> device instance numbers in the ioctl structures I need to read.
> 
> 
> There is a specific reason that the numbers are _kernel_internal_!!!   I 
> set up
> my udev so that my green CD burner is /dev/green_burner, and my blue  CD 
> burner
> is /dev/blue_burner.  Please tell me again why exactly I can't just  
> give the
> option -dev=/dev/green_burner and have it use my green CD burner? 

You do realize that you can?

> That's a lot
> easier than messing with random groups of 3 numbers and trying to  
> remember in
> which order I plugged in my burners, and which kernel I'm running, so  I 
> can
> remember the enumeration order, etc.
> 
>> Note that the fields are there but the information is intentionally  
>> obscured
>> for come of the calls just to make the life of cdrecord useers  harder 
>> :-(
> 
> 
> The information is obscured because userspace shouldn't know or care

So having you see the information to set up your udev is a good use and 
having Joerg use them is bad? If you want to have names mapped into 
"humanspace" why is program use bad? I agree numbers are ugly and 
confusing, but if I wanted someone to make those choices for me I'd run 
another o/s.

The "support is accidental" message pisses me off, because it isn't 
true. Code was added, I'm betting by design.
> 
>>> (I'm running as user, and cdrecord has no need for suid bits.)

Which is fine if you have a system to dedicate to burning CDs. But on a 
loaded system Joerg is right, you get a better burn if you don't have 
the burnfree used. Like any other minor defect it may or may not bite 
you, a lot of them will measurably reduce your CD capacity, which 
actually will bite you if you are trying to use every last byte.
>>
>>
>> I am frequently reading false claims like this. Usually from people  who
>> do not have the needed SCSI background knowledge to understand that
>> SCSI is a protocol where commands frequently fail by intention in  
>> order to
>> propagate a state or a implementation level to the application.
> 
> 
> What exactly is false about the claim?
> 
>> If you don't call cdrecord as root, you will not be able to lock in  
>> memory
>> and to raise priority in order to prevent buffer underuns.
> 
> 
> I burn CDs fine all the time as a user, and I _don't_ need to lock  
> memory or
> raise priority, because I have a good scheduler, plenty of RAM, and  
> dual CPUs.
> It would be nice if you could let me leave on the _hardware_ BurnProof
> technology designed to prevent that sort of thing, but it doesn't  
> appear to
> fit with your ideals of 100% perfect CDs, does it?  Besides, by the  
> time we
> hit the point where BurnProof would turn on, the disk is either  completely
> dead and useless (no burnproof), or slightly scarred and still  useable 
> (with
> burnproof).  Personally, I'd rather have the latter.

See above. It hasn't bitten you, therefore it doesn't bite... it's 
generally safe on a fast unloaded system.
> 
>> In addition (with Linux-2.6.8.1 or newer) you will not be able to  
>> send some
>> of the important SCSI commands mainly related to newer CD or DVD  
>> drives. As
>> a result, cdrecord cannot write DVDs
> 
> 
> I was not under the impression that the free cdrecord could write DVDs.
> 
>> or ultra speed CD-RWs or cannot do other things....
> 
> 
> Did you try submitting a list of important SCSI commands and their  
> functions?
> I suspect that if you provide a clear, concise list of harmless  commands,
> they would be included in the available command set.

Possibly true, didn't work for me.
> 
>> Not true: if only R/W fd would be allowed, no non root program  could 
>> do that.
> 
> 
> Uhh, but I don't run cdrecord as root.  My /dev/green_burner device  is 
> owned
> by root, has group "media", and perms rw-rw-r--.  Since this is a  
> somewhat public
> machine with lots of users in the "media" group, I don't want anybody  
> to be able
> to turn my drives into bricks.

No argument with that.
> 
>> See above, this false claim is a result of the fact that you miss  the 
>> background
>> knowledge on CD/DVD writing. Turning burnproof on degrades the  
>> quality of the
>> media and writing without burnproof but with the apropriate  
>> privilleges just
>> works fine.
> 
> 
> Why can't you just provide an option to leave it on?  My Mac and Windows
> computers seem to do just fine with it.  In fact, all modern CD-ROM  drives
> were designed to be able to read such "degraded" media, even "degraded"
> media that also has scratches and dents and dings and scars and all  sorts
> of other glitches in the CD surface.
> 
There is an option if you would read the manpage. There are legitimate 
complaints, this doesn't seem to be one of them.

Re: OT] Joerg Schilling flames Linux on his Blog

[Kyle Moffett]

On May 26, 2005, at 15:20:32, Bill Davidsen wrote:
>> There is a specific reason that the numbers are  
>> _kernel_internal_!!!   I set up
>> my udev so that my green CD burner is /dev/green_burner, and my  
>> blue  CD burner
>> is /dev/blue_burner.  Please tell me again why exactly I can't  
>> just  give the
>> option -dev=/dev/green_burner and have it use my green CD burner?
> You do realize that you can?

Well, yes, and I do all the time, but the dammed deprecation warning  
is just plain
stupid.  That's not the deprecated method, that's the reasonable method.

> So having you see the information to set up your udev is a good use  
> and having Joerg use them is bad? If you want to have names mapped  
> into "humanspace" why is program use bad? I agree numbers are ugly  
> and confusing, but if I wanted someone to make those choices for me  
> I'd run another o/s.

I don't use the three-number made-up SCSI-over-USB IDs that Joerg was  
complaining
about being unavailable.  I have mine set up based on the UUID of the  
burner.  I'm
sorry for being unclear, but my objection is to his desire to expose  
the SCSI IDs
to userspace as the primary naming scheme, when said SCSI IDs are  
frequently just
made up by the kernel for USB devices, etc.

>>>> (I'm running as user, and cdrecord has no need for suid bits.)
>
> Which is fine if you have a system to dedicate to burning CDs. But  
> on a loaded system Joerg is right, you get a better burn if you  
> don't have the burnfree used. Like any other minor defect it may or  
> may not bite you, a lot of them will measurably reduce your CD  
> capacity, which actually will bite you if you are trying to use  
> every last byte.

Agreed.  My personal gripe is that it screams at me even when I'm  
just doing a
quickie burn of a 60MB debian netinst CD for a one-use-only thing.

> There is an option if you would read the manpage. There are  
> legitimate complaints, this doesn't seem to be one of them.

Ah, crap.  I just realized that some accidental disk corruption took  
a chunk out of
the middle of my copy of the manpage.  A reinstall of the package  
seems to have
fixed the problem.  Sorry about the noise.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------

Re: OT] Joerg Schilling flames Linux on his Blog

[Matthias Andree]

On Thu, 26 May 2005, Kyle Moffett wrote:

> I don't use the three-number made-up SCSI-over-USB IDs that Joerg was
> complaining about being unavailable.  I have mine set up based on the
> UUID of the  burner.  I'm sorry for being unclear, but my objection is
> to his desire to expose  the SCSI IDs to userspace as the primary
> naming scheme, when said SCSI IDs are  frequently just made up by the
> kernel for USB devices, etc.

Given that I know the SCSI IDs of every single device I install, am not
using SCAM, I don't object to using SCSI IDs, unfortunately, SCSI CD or
DVD writers are rare and costly - I'd prefer them over ATAPI every day
since I take one PCI device to connect like half a dozen narrow SCSI
devices. ATAPI is so wasteful. And I have bought SCSI for as long as
somewhat up-to-date devices were available.

Things get interesting though with ATAPI, ATAPICAM, ide-scsi, ide-cd and
all sorts of interfaces since probing various busses is something that
requires user intervention or trial & error to list _all_ devices in
different buses, and drives have unlogical bus numbers (seen these on
FreeBSD), or more generally, when cdrecord tries to coerce a device
numbering scheme on devices that are not enumerated, or devices that are
hotplug with device numbers changing with every plug-in action, or
whatever.

-- 
Matthias Andree

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On May 25, 2005, at 18:46:55, Joerg Schilling wrote:

> > The unability to give this kind of convenience to cdrecord users is  
> > a result
> > of the refusal of the Linux kernel crew to include the kernel internal
> > device instance numbers in the ioctl structures I need to read.
>
> There is a specific reason that the numbers are _kernel_internal_!!!   

So if you really believe this, you should immediately remove all
stuff under /proc.

> I set up
> my udev so that my green CD burner is /dev/green_burner, and my blue  
> CD burner
> is /dev/blue_burner.  Please tell me again why exactly I can't just  
> give the
> option -dev=/dev/green_burner and have it use my green CD burner?   

Try to start with reading the cdrecord manual page. Your question
is answered in there.....but if you issue a command that is only
halfway correct you will never be able to get the full set of features from 
cdrtools. Using UNIX device names for SCSI devices is highly nonportable 
and for this reason not supported by a portable program like cdrecord.

Cdrecord includes the needed features to do what you like, but do not
asume that you will be able to force me to make nonportable and Linux
specific interfaces a gauge for the design of a portable program.
If you read the cdrecord man page, you know that you could
happily call cdrecord dev=green_burner.....


> That's a lot
> easier than messing with random groups of 3 numbers and trying to  
> remember in
> which order I plugged in my burners, and which kernel I'm running, so  
> I can
> remember the enumeration order, etc.

Aha, so you would prefer /dev/ftp.kernel.org also?

Before trying to make inadequate comparisons and before you request
inadequate similarities, it often helps a lot if you first try to look
around and check whether your claims are really a tautology.

>
> > Note that the fields are there but the information is intentionally  
> > obscured
> > for come of the calls just to make the life of cdrecord useers  
> > harder :-(
>
> The information is obscured because userspace shouldn't know or care

If you read the LKML archives, it would be easy for you to prove that this
is not true :-(

The numbers are obscured _only_ in order to prevent me to implement a workaround
for the fact that Linux does not implement _one_ unique interface for sending
generic SCSI commands to all devices that talk SCSI.

I aked for a non obscured interface in 2002 (note that the fields _are_ present
inside the ioctl parameter structure) in order to hide this drawback from Linux
users, but I have been told that the Linux developers don't like nice
and _unique_ interfaces for their users. 

	-	The fields are in the ioctl structures for user land 
		communication.

	-	The kernel knows the numbers that would allow libscg
		to detect duplikate drive appearances when trying to
		implement a global umbrella for all different SCSI
		interfaces in the Linux kernel

	-	The kernel hides the fact only to make it impossible for
		cdrecord to implement  a better user interface.



> > If you don't call cdrecord as root, you will not be able to lock in  
> > memory
> > and to raise priority in order to prevent buffer underuns.
>
> I burn CDs fine all the time as a user, and I _don't_ need to lock  
> memory or
> raise priority, because I have a good scheduler, plenty of RAM, and  
> dual CPUs.

Do you really believe this? It would help a lot if you did a reality check.


> It would be nice if you could let me leave on the _hardware_ BurnProof
> technology designed to prevent that sort of thing, but it doesn't  
> appear to
> fit with your ideals of 100% perfect CDs, does it?  Besides, by the  

Again, try do do some reallity check.... Cdrecord by default uses the
setup that grant best media quality. I asume you are able to read, so 
just read the man page and set up your defaults the way you like them.


> burnproof).  Personally, I'd rather have the latter.

So why do you refuse to read the manual and to setup the parameters
you like?


> Did you try submitting a list of important SCSI commands and their  
> functions?
> I suspect that if you provide a clear, concise list of harmless  
> commands,
> they would be included in the available command set.

Having such a list in inherently wrong. It never could be made correct.

There are a lot of different drives with a lot of overlapping commands
in the vendor unique part of the name space. Cdrecord needs the
vendor unique commands for old writers in order to be able to write at
all, and cdrecord needs the vendor unique commands in order to implement
the nice features people like for their convenience.

Nut even in the non vendor unique part the list in Linux is incomplete.

****
And please note: Cdrecord uses some of the commands that are used for 
firmware upgrade in order to do DMA speed metering........ This is
definitely _not_ a security issue with cdrecord.
In special on Linux, users frequelty did complain about insufficient
DMA speed before I did add this feature. Not cdrecord refuses to write
faster than possible after metering the transfer speed from/to the drive.
****

In case you don't understand this correectly, let me explain:

A security problem may only be correctly dealt with by having a 
coherent and consistent security strategy. The SCSI op code table
is not part of a security strategy but just a bad hack.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Bodo Eggert <7eggert@gmx.de> wrote:

> [...]
> > If you don't call cdrecord as root, you will not be able to lock in memory
> > and to raise priority in order to prevent buffer underuns.
>
> My problem is the speed of the network or the fragmentation of my HD, RT
> privileges won't do the magic needed here[tm]. In fact, even a kernel
> compile while doesn't harm. On a reasonably busy system, I would probably
> have to reconsider.

If you have fragmentation problems, do you use the wrong filesystem type?
I never had any similar problem on a ufs type filesystem.

With network speed, you should set up a sufficiently designed infrastructure.
If you like to write a CD in 32x, you need 5.6 MB/s which easily goes over
a 100 MB/s network connection.


> > In addition (with 
> > Linux-2.6.8.1 or newer) you will not be able to send some of the important
> > SCSI commands mainly related to newer CD or DVD drives. As a result, cdrecord
> > cannot write DVDs or ultra speed CD-RWs or cannot do other things....
>
> If I need them, I'll notice and I can ask for them to be added.-) Your
> patch will just hide this need, but that's what your otherusers will need.

There are many other commands needed by cdrecord.
The initiator of the good/bad SCSI op code table hack claimed to have checked
cdrecord for a list of used commands. If you check the current table, you may
easily find that this cannot be true.


> Maybe the failed command should be stored and printed after burning the 
> CD, so new comands will get added quickly?

Please try to check the cdrecord source in order to understand the background.


> You'll want to grant raw disk access for some databases, which will run as
> a unprivileged user. These databases should not be able to kill HDDs.

A database may kill a hdd in many other ways. It is higly improbable that
a trustworthy database includes the knowwledge to set up a firmware to the
drive that us accepted by the drive but does not work. The same applies for
your kernel. You need to trust your database the same way as you need to trust 
your kernel.


> > The good/bad SCSI commands table that is currently used is a really bad and
> > ugly (incorrect) hack and much worse than my proposal.
>
> Your proposal has it's limitations, see above.

It has less limitations that the good/bad SCSI commands table has, see above.

> > > The fix is wrong: You're asuming root is capable of everything. This
> > > doesn't need to be true (missing CAP_SYS_RAWIO) and you'll run into a
> > > loop in that case.
> > 
> > If you are really true, then there is a design problem in Linux.
>
> No, it's a feature, see man 3 cap_get_proc.

If Linux is designed in a way that needs applications like cdrecord to be 
changed in order to include support for a Linux proprietary new security
mechanism, then the new mechanism should be rethought.


> > BTW: If Linux starts introducing fine grained rights manamement like on Solaris, why 
> > does it miss the apropriate management tools at user level?
>
> Washing dishes is faster than drying them :)

If you go into a restaurant, they wash the dishes before they serve them to you,
but they wait until they did dry before they get them out of the kitchen :-)

It is a matter of style of the kitchen personal whether to serve wet
dishes or not. 

So for the Linux equivalent: don't force users tu use interfaces that are not
yet ready for the public.


> > On Solaris, I could run cdrecord rootless if I use pfksh as my shell and if
> > the roles database would include cdrecord with its needed privilleges and me
> > as a member of the cdwriters role.
>
> There was some discusssion on LKML about non-root access to RT privileges. 
> Maybe there is something in the queue.

So it makes sense for the Linux to have a look at the Solaris implementation.
The database is much simpler to manage than what is present for Linux.

BTW: it would also make sense to implement the new holey file interface 
I designed together with the Solaris kernel crew for star.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: [OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

> On Thursday 26 May 2005 16:15, Joerg Schilling wrote:
>
> > The problem was that you could send SCSI commands on R/O fds and fixing the
> > problem would have been to forbid sending SCSI commands on R/O fds.
>
> Unfortunately, this is not going to work. It would work only if the only app 
> that has to send SCSI commands were cdrecord. Then really, a non-setuid 
> program just would not be able to get a R/W fd, and setuid ones are assumed 
> to be trusted.

If these programs did rely on the named security bug, then these programs
were broken anyway and need to be fixed. Note that the _old_ (non ioctl based)
/dev/sg interface needed write access in order to send SCSI commands.


> The problem is that many CD audio players also send SCSI commands in order to 
> extract digital audio data. Are you proposing to make them setuid root? use a 
> well-defined setuid helper? other solution?

If these programs did ever work before, someone did break them meanwhile.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: [OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Bodo Eggert <7eggert@gmx.de> wrote:

> On Thu, 26 May 2005, Alexander E. Patrakov wrote:
> > Bodo Eggert wrote:
>
> > >So we can
> > >
> > >1) give up and let any application with write access destroy the hardware
>
> > That won't be a problem if all apps with write access are running as 
> > root or setuid and thus the list of them is well-controlled by root.
>
> And if all these apps are guaranteed to have no buffer-overflow or other 
> exploits.

If you cleanly separate the ability to send SCSI commands from the ability
to write to a UNIX block or raw devive, you only need to check the programs
that explicitly need to send SCSI commands.

In former times, Linux did have this kind of clean separation between
e.g. /dev/sd0 and /dev/sg0. Just go back to the clean old model...

This could easily be done: Remove SG_IO from the list of ioctl functions
supported by drivers like /dev/sd0 and /dev/hda fix the bugs in ide_scsi.



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Wakko Warner]

Joerg Schilling wrote:
> Try to start with reading the cdrecord manual page. Your question
> is answered in there.....but if you issue a command that is only
> halfway correct you will never be able to get the full set of features from 
> cdrtools. Using UNIX device names for SCSI devices is highly nonportable 
> and for this reason not supported by a portable program like cdrecord.
> 
> Cdrecord includes the needed features to do what you like, but do not
> asume that you will be able to force me to make nonportable and Linux
> specific interfaces a gauge for the design of a portable program.
> If you read the cdrecord man page, you know that you could
> happily call cdrecord dev=green_burner.....

Portable programs have specifics to each OS that it can be compiled on.  Why
do you think some portatble programs use automake?  Not ever OS defines
variables the same way or uses them the same way as others.

You are going to have to realize that accessing devices directly under
different OSes will require different code.  I've read all the stuff you've
posted and it is apparent that you want all OSes to use the scsi scheme.

I don't use cdrecord much anymore since 1) I have a DVDRW and 2) I burn
DVDs mostly.  It happily uses /dev/<whatever> instead of compilaining that
it's unintentional.

As far as I can see, you can use scsi ioctls on regular devices so why do
you really need to use the 3 numbers?  To find the right /dev/sg and use it? 
Doesn't make sense.  I looked at the eject program one day.  The IOCTL used
to eject a cdrom is different than solaris.  Gee, I guess eject is not
portable.  You should probably write a library that deals specifically with
each OS.  I don't ever see something like this being portable.  Especially
between a Unix environment and a Windows environment.

P.S. This is the first and will be the last time I post on this thread.  I'm
not trying to flame anyone, this is mostly an enduser observation.  The
native OS device usage should be used instead of something supposedly
portable.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: OT] Joerg Schilling flames Linux on his Blog

[Dmitry Torokhov]

On 5/27/05, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Kyle Moffett <mrmacman_g4@mac.com> wrote:
> > I set up
> > my udev so that my green CD burner is /dev/green_burner, and my blue
> > CD burner
> > is /dev/blue_burner.  Please tell me again why exactly I can't just
> > give the
> > option -dev=/dev/green_burner and have it use my green CD burner?
> 
> Try to start with reading the cdrecord manual page. Your question
> is answered in there.....but if you issue a command that is only
> halfway correct you will never be able to get the full set of features from
> cdrtools. Using UNIX device names for SCSI devices is highly nonportable
> and for this reason not supported by a portable program like cdrecord.
> 
> Cdrecord includes the needed features to do what you like, but do not
> asume that you will be able to force me to make nonportable and Linux
> specific interfaces a gauge for the design of a portable program.
> If you read the cdrecord man page, you know that you could
> happily call cdrecord dev=green_burner.....
> 

No, that static mapping is not good. I have an external enclosure that
does firewire and USB. I want to be able to use "sony-dvd" to access
it no matter whether it is onnected to USB bus or Firewire and whether
there are other devices (disks) on USB or firewire. It is possible to
do with udev creating a link to /dev/sony-dvd.

-- 
Dmitry

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > Cdrecord includes the needed features to do what you like, but do not
> > asume that you will be able to force me to make nonportable and Linux
> > specific interfaces a gauge for the design of a portable program.
> > If you read the cdrecord man page, you know that you could
> > happily call cdrecord dev=green_burner.....
> > 
>
> No, that static mapping is not good. I have an external enclosure that
> does firewire and USB. I want to be able to use "sony-dvd" to access
> it no matter whether it is onnected to USB bus or Firewire and whether
> there are other devices (disks) on USB or firewire. It is possible to
> do with udev creating a link to /dev/sony-dvd.

I am not sure what you like to do.....

But what you claim is simply impossible.

As you started to introduce the allegory with the colors, let me make 
an assumption based on your claim:

-	Buy two identical drives and varnish one in red and the other 
	in green.

-	Connect both drives to your computer to let the OS "learn" the
	drives.

-	Do any setup you like

-	Now disconnect the drives and after that, connect the green one
	the way the red one has been connected before. 

-	Connect the red one too.

-	Insert a medium into the green drive

-	Let your software try whether it is able to connect you
	to the green one.

If this always works as expected, then you are a magician!

So let me sum up: Never rely on things that cannot be made 100%
unique in case you like to run security relevent software like cdrecord.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Bodo Eggert <7eggert@gmx.de> wrote:

> > If you have fragmentation problems, do you use the wrong filesystem type?
>
> No, just small writes to random locations in large sparse files on filled 
> disks.

Did you ever try to compare this behavior with UFS?
The last time I did notice fragmentation problems on UFS is more than 15 years
a go when I had full news feed with B-news running on a Sun-3/50 and did a 
higly selective expire.

I am still sure that your problems are a problem of the filesystem 
implementation you use.

> > With network speed, you should set up a sufficiently designed infrastructure.
> > If you like to write a CD in 32x, you need 5.6 MB/s which easily goes over
> > a 100 MB/s network connection.
>
> Mostly it does, but sometimes there are other users on my server.

This is why cdrecord puts itself into the highest priority real time class
on every OS that supports this. If you voluntarily decline on this feature,
please don't blame cdrecord.


> > There are many other commands needed by cdrecord.
> > The initiator of the good/bad SCSI op code table hack claimed to have checked
> > cdrecord for a list of used commands. If you check the current table, you may
> > easily find that this cannot be true.
>
> So we'll need a function to add more commands to the allowed list of each 
> device.

No, the command list was an ungly hack from the beginning and it just is not
suitable for what it is used.

	If you like decent and reliable security, you need privillege separation.

-	Disallow sending SCSI commands via ioctl() on /dev/hd*

-	Tell people that they have to use /dev/sg* in order to send SCSI 
	commands to devices.

-	Introduce a privillege check for /dev/hd* that is suitable for the
	users of a block device interface.

-	Introduce a privillege check for /dev/sg* that is suitable for the
	users of a SCSI pass though interface.

The current problems in Linux are just a result of mixing unrelated interfaces
together.


> > > You'll want to grant raw disk access for some databases, which will run as
> > > a unprivileged user. These databases should not be able to kill HDDs.
> > 
> > A database may kill a hdd in many other ways.
>
> IMO, those should be plugged, too, and I'm sure they will.

See above: the clean solution is privilleges separation.


> > It is higly improbable that
> > a trustworthy database includes the knowwledge to set up a firmware to the
> > drive that us accepted by the drive but does not work.
>
> A database may very well have exploits or provide system access to the 
> database admin. Neither should result in raw SCSI access.

See above: If you have clean privilleges separation (and Linux did have it 
before the unsuited SG_IO ioctl was introduced on /dev/hd*) you don't even come
close to similar problems.

Just give the database an interfase that allows the database to do what a 
database needs to do (reading and writing to a media) but not more.


> > The same applies for
> > your kernel. You need to trust your database the same way as you need to trust 
> > your kernel.
>
> NACK. Databases can't be trusted.

Wunderfull, so you are also a fan of privillege separation. Let us together
vote for removing ioctl(sg_IO) from /dev/hd* and similar devices.


> > > No, it's a feature, see man 3 cap_get_proc.
> > 
> > If Linux is designed in a way that needs applications like cdrecord to be 
> > changed in order to include support for a Linux proprietary new security
> > mechanism, then the new mechanism should be rethought.
>
> You don't need to implement that, but you shouldn't asume root to be more 
> special than other users.

In contrary to many other programs, cdrecord is cleanly written and does not
make such assumptions! It will have no problems as long as the environment
is not contradictive.


> BTW: IIRC, it was ported from solaris. There will probably the same issue.
>
> > So for the Linux equivalent: don't force users tu use interfaces that are not
> > yet ready for the public.
>
> You're not forced to use it, but you might be served non-dirty plates.

It seems that you did not understand this, so let me explain it in a different
way: If you start to implement a new security mechanism, either do it in a way 
that does not affect software that assumes historical UNIX interfaces at all,
or keep it private for developers untill it is suitable for the mass.

> > So it makes sense for the Linux to have a look at the Solaris implementation.
> > The database is much simpler to manage than what is present for Linux.
>
> This is a userspace issue. The kernel doesn't enforce anything.

An OS is the kernel _and_ the user space support software.
Even a "kernel only" subsystem like Linux cannot ignore these facts when
trying to introduce interfaces that need special useland programs in order
to mahe use out of it.

> > BTW: it would also make sense to implement the new holey file interface 
> > I designed together with the Solaris kernel crew for star.
>
> Google gives no good pointers.

If it did, soneone would have ignored his NDA. The current interface is not
yet 100% stable, it will be officially published when it is closer to something
that could be used by anyone. If someone from LKML is really interested in 
implementing the interface soon, I would be willing to give away basic
details that allow to implement 99% if the code. The error handling is 
still in dispute.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Markus Plail]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
>> > Cdrecord includes the needed features to do what you like, but do
>> > not asume that you will be able to force me to make nonportable and
>> > Linux specific interfaces a gauge for the design of a portable
>> > program.  If you read the cdrecord man page, you know that you
>> > could happily call cdrecord dev=green_burner.....
>> > 
>>
>> No, that static mapping is not good. I have an external enclosure
>> that does firewire and USB. I want to be able to use "sony-dvd" to
>> access it no matter whether it is onnected to USB bus or Firewire and
>> whether there are other devices (disks) on USB or firewire. It is
>> possible to do with udev creating a link to /dev/sony-dvd.
>
> I am not sure what you like to do.....

He wants to be able to access his dvd recorder via dev=/sony-dvd. And it
should not matter how it is connected (USB/firewire).

> But what you claim is simply impossible.

No it is not.

> As you started to introduce the allegory with the colors, let me make
> an assumption based on your claim:
>
> -	Buy two identical drives and varnish one in red and the other 
> 	in green.

That is indeed impossible, but as soon as there are two different
drives, it is possible with udev and not possible with a static
assignment.

regards
Markus

Re: OT] Joerg Schilling flames Linux on his Blog

[Dmitry Torokhov]

On Monday 30 May 2005 04:07, Joerg Schilling wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > > Cdrecord includes the needed features to do what you like, but do not
> > > asume that you will be able to force me to make nonportable and Linux
> > > specific interfaces a gauge for the design of a portable program.
> > > If you read the cdrecord man page, you know that you could
> > > happily call cdrecord dev=green_burner.....
> > > 
> >
> > No, that static mapping is not good. I have an external enclosure that
> > does firewire and USB. I want to be able to use "sony-dvd" to access
> > it no matter whether it is onnected to USB bus or Firewire and whether
> > there are other devices (disks) on USB or firewire. It is possible to
> > do with udev creating a link to /dev/sony-dvd.
> 
> I am not sure what you like to do.....
> 
> But what you claim is simply impossible.
> 
> As you started to introduce the allegory with the colors, let me make 
> an assumption based on your claim:
> 
> -	Buy two identical drives and varnish one in red and the other 
> 	in green.
> 
> -	Connect both drives to your computer to let the OS "learn" the
> 	drives.
> 
> -	Do any setup you like
> 
> -	Now disconnect the drives and after that, connect the green one
> 	the way the red one has been connected before. 
> 
> -	Connect the red one too.
> 
> -	Insert a medium into the green drive
> 
> -	Let your software try whether it is able to connect you
> 	to the green one.
> 
> If this always works as expected, then you are a magician!
>

It will not work if drives are absolutely identical, however if there is
something even slightly different about them (serial number, model,
firmware version - anything) you can set up udev to produce "stable" name.

FWIW, my example was about a single drive that can "change" it's X,Y,Z
depending on how and when it was connected.

> So let me sum up: Never rely on things that cannot be made 100%
> unique in case you like to run security relevent software like cdrecord.

Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
Because for the most types of devices out there they don't make any sense
and just provided for compatibility with legacy software.

Also, from a bit different perspective - do you also want users to mount
the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
If not why writing application should use different addressing? 

-- 
Dmitry

Re: OT] Joerg Schilling flames Linux on his Blog

[Måns Rullgård]

Dmitry Torokhov <dtor_core@ameritech.net> writes:

>> So let me sum up: Never rely on things that cannot be made 100%
>> unique in case you like to run security relevent software like cdrecord.
>
> Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
> Because for the most types of devices out there they don't make any sense
> and just provided for compatibility with legacy software.

Like cdrecord.

> Also, from a bit different perspective - do you also want users to mount
> the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
> If not why writing application should use different addressing? 

Let's start referring to files by device and inode number instead.
It's so much easier than using pathnames.  Maybe we can even force
them into a bus,target,lun scheme.  Then the device files and the
corresponding scsi addresses will automatically collapse, and all
problems will be solved.

-- 
Måns Rullgård
mru@inprovide.com

Re: OT] Joerg Schilling flames Linux on his Blog

[Brian O'Mahoney]

This thead has become ultimately boring, Joerg's views are
irreconcilably anti linux and pro Solaris,

there are, fortunately, alternatives to cdrrecord that work,
especially for DVD,

let us just thank Joerg for his work and move on quietly!

-- 
mit freundlichen Grüßen, Brian.

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Bodo Eggert <7eggert@gmx.de> wrote:

> > No, the command list was an ungly hack from the beginning and it just is not
> > suitable for what it is used.
> > 
> > 	If you like decent and reliable security, you need privillege separation.
> > 
> > -	Disallow sending SCSI commands via ioctl() on /dev/hd*
>
> > -	Tell people that they have to use /dev/sg* in order to send SCSI 
> > 	commands to devices.
>
> - Each CD player would have to run suid. I'm talking about programs 
>   running a GUI, peeking in CDDB databases and doing other ugly stuff.

If you don't already have fine grained process permissions ready, you are right.
In the other cases, pfksh or somethign similar would know about the special
rights of a program from checking the databases in /etc/security/ and call
/usr/bin/pfexec to set up only the needed rights and then call the program
in question.

Note that in case you call the ability to send SCSI commands a security
risk, then you need to implement all the consequences.....


> - Each CD player will have permission to erase the firmware on all 
>   installed devices.

As you may not know which SCSI commands are used for a specific device, this
is correct.


> - You've seen how ugly scanning for the correct sg device is, and udev 
>   will make it site-dependant. You are no longer "guaranteed" to find any 
>   /dev/sg* devices.

As it seems that this program called "udev" (if I am right) does some strange
lookup and setup which is basically the same from editing /etc/default/cdrecord
why is this program not implemented to give full support for Linux users and
_does_ edit /etc/default/cdrecord?

I don't know that program but in contrary to the concepts of Solaris where
a similar program (devlinks) that exists since 1992 creates links based only
on information found in the names from /devices, and crerates links to /dev
like this one:

lrwxrwxrwx   1 root     other         45 Jul 14  2003 /dev/scg0 -> ../devices/pci@0,0/pci-ide@7,1/ide@1/scg@0,0:
lrwxrwxrwx   1 root     other         39 Jul 14  2003 /dev/scg1 -> ../devices/pci@0,0/pci1000,f@9/scg@0,0:

it seems that the program udev either has access to private kernel data 
structures (from the definition of the people who like to deny access to 
this information to cdrecord::libscg) or does other strange things.

On Solaris, handling of driver instances is done inside the kernel and used
to set up device names.

You should rethink whether you still believe that udev is a clean program while
cdrecord is not.....

Please note that /etc/default/cdrecord must likely predates udev by many years
and polite authors of such a program would have added support for not only
creating links to /dev but also for adding device aliased into 
/etc/default/cdrecord.



> > In contrary to many other programs, cdrecord is cleanly written and does not
> > make such assumptions!
>
> It does asume not to get permission denied errors after seteuid(0) was 
> successfull.

Wrong: please check the source..... 

It does not make _any_ asumption based on uid values except for the fact that
it still tells you to become root in case something did not work.

So if there was a useful framework for the current attempt to implement 
fine grained process privilleges into Linux, cdrecord would be a candidate 
for testing....


> > It seems that you did not understand this, so let me explain it in a different
> > way: If you start to implement a new security mechanism, either do it in a way 
> > that does not affect software that assumes historical UNIX interfaces at all,
> > or keep it private for developers untill it is suitable for the mass.
>
> It's not new. My manpage is from 1997, and the function was ported from 
> solaris (IIRC).

What are you talking about?


> > An OS is the kernel _and_ the user space support software.
>
> The linux kernel is just the linux kernel. Unlike other systems, no
> special userland is enforced (with minimal exceptions like /sbin/init).
> You can run supervise, busybox, sysvinit, use pam or classic login etc.
> If you like, you can get rid of /dev and put it somewhere else.

If you really make this assumtion, you would not be allowed to implement 
fine grained process privielleges into Linux because you could not support
it at shell level. It just makes no sense to add special (currently) nonstandard
features to a kernel without providing the supporting user land programs.



> > Even a "kernel only" subsystem like Linux cannot ignore these facts when
> > trying to introduce interfaces that need special useland programs in order
> > to mahe use out of it.
>
> If you're developing a monolithic OS, you can hide the interface untill
> you've written the applications, but you can't do that for a standalone 
> kernel. The interface is mostly(?) there, and as soon as somebody starts 
> to care enough, it will be used.

You can do the same for something like Linux. You just need to implement the
interface in a way that does not contradict or influence historical UNIX
practice that made it into POSIX. 

> > If it did, soneone would have ignored his NDA. The current interface is not
> > yet 100% stable, it will be officially published when it is closer to something
> > that could be used by anyone. If someone from LKML is really interested in 
> > implementing the interface soon, I would be willing to give away basic
> > details that allow to implement 99% if the code. The error handling is 
> > still in dispute.
>
> I'm too lazy to implement that, but I'd like an abstract.
> (I suspect it's something like 
> http://www.olafdietsche.de/linux/capability/)

Did you forget what question from you I was replying to?

I see no relation to a holey file interface here.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Dmitry Torokhov <dtor_core@ameritech.net> wrote:

> > So let me sum up: Never rely on things that cannot be made 100%
> > unique in case you like to run security relevent software like cdrecord.
>
> Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
> Because for the most types of devices out there they don't make any sense
> and just provided for compatibility with legacy software.

Well, this is the way most OS on the planet deal with SCSI. 

And please explain me why the Linux kernel internally uses these numbers
for driver instancing? Is the Linux kernel a piece of legacy software?


> Also, from a bit different perspective - do you also want users to mount
> the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
> If not why writing application should use different addressing? 

Using SCSI addresses is just the way that works more universally for
sending SCSI commands. There are several OS that don't support /dev/ names
and all other UNIX like OS do not artificial hide the SCSI addresses 
from userland programs.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Brian O'Mahoney" <omb@khandalf.com> wrote:

> This thead has become ultimately boring, Joerg's views are
> irreconcilably anti linux and pro Solaris,

If you are anti Linux, just try to stay quiet......

This is the first time that I experienced a non insulting
discussion at LKML.....


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily