Re: OT] Joerg Schilling flames Linux on his Blog

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Patrick McFarland wrote:

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

Well, it seems that you are uninformed about the facts :-(

So let me quote a mail I send to LKML on Aug 17 13:14:59 2004:
/*--------------------------------------------------------------------------*/
If Linux believes that there should be enhanced security similar to Solaris and  
if Linux is a true open Source business, then I would expect that there is  
cooperation. If I change things in e.g. mkisofs or cdrecord that could result 
in problems for my "users", I send a notification mail to the XCDRoast & k3b  
authors early enough. 
 
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. As this did not happen, the  
change needs to be called a bug. This is even more obvious if we take into  
account that cdrtools curently is in code freeze state as a 2.01-final will  
come the next days. 
 
For this reason, I would recommend that Linux immediately goes back to the old 
behavior and informs "important users". A change that has effects that are as 
widely as this one should not be tried again within the next 3 months. Then  
there is a change to have a smooth migration...... 
 
BTW: I try to inform my "important users" more than a year before I introduce 
important changes. 
/*--------------------------------------------------------------------------*/

Note that this was a few days before cdrtools-2.01 final have been published
(after nearly two years of planned work on a new version).

The changes to Linux did neither fix the problem (just check the mailings on 
LKML from last year) nor has there been a need for introducing incompatible 
changes. If the cause for the change really was the "security problem" caused 
by the fact that Linux did allow to send SCSI commands on R/O file descriptors
it would have been sufficient to require R/W permissions on the fd. After
this putative small change, the supposed problem would have been fixed and 
cdrtools as well as other users of the interface did work as before.

What the change on Linux did was not to fix a problem but to break cdrtools.

I am not unwilling to fix cdrecored, as a non broken program does not need
a fix. I was even willing to add a workaround for the incompatible interface 
change. But this may obviously not happen in a code freeze state.

Sorry - The problems between cdrtools and Linux is only a result of the 
missing will for cooperation from the Linux kernel crew.


BTW: Due to missing time (I like to see a good cooperation between my work
and the support code in an OS, so I am now actively working on OpenSolaris
and I am very busy...). My planned OpenSolaris based UNIX distribution
"SchilliX" should be available soon after the public availability of the
OpenSolaris source in Q2/2005 which is only a few days from now. Fortunately,
I believe that I will be able to boot my first "SchilliX from scratch" 
compiled CD today.

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


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 09:15:33, Joerg Schilling wrote:
> If Linux believes that there should be enhanced security similar to  
> Solaris and
> if Linux is a true open Source business, then I would expect that  
> there is
> cooperation. If I change things in e.g. mkisofs or cdrecord that  
> could result
> in problems for my "users", I send a notification mail to the  
> XCDRoast & k3b
> authors early enough.

There was a security hole in the CD burner support.  The Linux Kernel  
developers
fixed it quickly.  They were not planning to wait 6 months for you to  
get an
updated version of cdrecord out the door in any case.  If you want more
information on the Linux Kernel security policy, please see a recent  
copy of the
linux kernel for the file Documentation/SecurityBugs.  To quote the  
relevant
part:  "It is reasonable to delay disclosure ... or for vendor  
coordination.
However we expect these delays to be short, measurable in days, not  
weeks or
months."  Part of this policy includes "we'd like to know when a  
security bug is
found so that it can be fixed and disclosed as quickly as possible."   
This seems
to imply that the security team is not likely to wait 6 months to fix  
a critical
hardware-damaging vulnerability.

> If the cause for the change really was the "security problem"  
> caused by the
> fact that Linux did allow to send SCSI commands on R/O file  
> descriptors it
> would have been sufficient to require R/W permissions on the fd.  
> After this
> putative small change, the supposed problem would have been fixed  
> and cdrtools
> as well as other users of the interface did work as before.

I will not debate this issue with you.  Please see the copious  
quantities of
emails when this issue was brought up a while ago.

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

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On May 25, 2005, at 09:15:33, Joerg Schilling wrote:
> > If Linux believes that there should be enhanced security similar to  
> > Solaris and
> > if Linux is a true open Source business, then I would expect that  
> > there is
> > cooperation. If I change things in e.g. mkisofs or cdrecord that  
> > could result
> > in problems for my "users", I send a notification mail to the  
> > XCDRoast & k3b
> > authors early enough.
>
> There was a security hole in the CD burner support.  The Linux Kernel  
> developers
> fixed it quickly.  They were not planning to wait 6 months for you to  
> get an
> updated version of cdrecord out the door in any case.  If you want more
> information on the Linux Kernel security policy, please see a recent  
> copy of the
> linux kernel for the file Documentation/SecurityBugs.  To quote the  
> relevant

Looks like you did not read the mail from me you were replying to.

The best way to fix a problem is to fix the problem and not to do something 
else and to change the interface.

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.

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

[Bill Davidsen]

On Thu, 26 May 2005, Joerg Schilling wrote:


> Looks like you did not read the mail from me you were replying to.

Let's start a technical discussion with a personal attack...
> 
> The best way to fix a problem is to fix the problem and not to do something 
> else and to change the interface.

When possible, correct.
> 
> 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.

IT DOESN'T WORK THAT WAY. You *can't* disallow sending commands, that's
how you do a read on a SCSI device, by sending commands like "seek" and
"read." What is needed is to limit the commands allowed to be sent, and
pass only known appropriate commands depending on access.

It is true that the first implementation didn't have all the legitimate
commands in the table of allowed commands. But once the idea of doing bad
things to a CD by sending evil commands was well-known, it was important
to have protection in place quickly.

It is true that some developers have been very unhelpful, and replied with
canned "you don't have permission" messages to reports that legitimate
commands aren't in the allowed table.

It is true that the implementation is overly complex, instead of using
only read and write, other things are checked, resulting in some
unexpected behaviour, like blocking programs being setuid.

What is NOT TRUE is that any of this was done just to piss you off. That
was just a fringe benefit to fixing the security issue quickly. AFAIK all
of the commands for burning single session CD/DVD are working as intended.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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

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

[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

[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

[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?
>////
>
>  
>

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

[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

[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

[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

[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

[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

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

[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, 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

[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

[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

[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