Burning music CDs
in [UK Linux]
|
From: Tony Houghton on 29 Jan 2010 10:32 In <7sg7ipFsgrU1(a)mid.dfncis.de>, Joerg Schilling <js(a)cs.tu-berlin.de> wrote: > Looks like you miss the needed skills for psychlogy. The Sun Person > Simon Phipps just did not object for obvious reasons bud made a very > angry face when hearing the nonsense from her. Sun didn't include the controversial "angry face" clause in the final version of the CDDL. -- TH * http://www.realh.co.uk
From: Nix on 29 Jan 2010 16:47 On 29 Jan 2010, Paul Martin stated: > In article <7sg807Fv0lU1(a)mid.dfncis.de>, > Joerg Schilling wrote: > >> - Important features are missing (UDF, CD Cue sheet, raw writing.....) > > UDF support is in the kernel. There's no need to have anything else > provide it. I have UDF-formatted DVD-RAMs which I simply mount and use > like any other drive. Quite so. UDF support in the kernel *used* to be crappy, mind you, but it certainly isn't anymore. (The kernel can also use UDF support directly in the drive if need be.) I've written a *lot* to CD-RWs atop UDF. I've never once even considered using any userspace tool for anything other than making the filesystem in the first place. After creation, access is up to the kernel. Having a userspace program do something like that would feel terribly unpleasant compared to just letting the kernel do it. Filesystem access has to go through the VFS, or it's no use at all, IMNSHO: most programs can't get at it. (This means that e.g. fuse is acceptable.) >> - libcdio is based on a concept that is not feasible for secure >> environments. It is a lib and thus encourages people to use it from a >> GUI. Ad the task it implements is a privileged task, you need to >> run a privileged GUI that cannot be audited for security. > > PARDON?!?!? If you try starting programs using a modern widget set as root, they'll mostly refuse to start, telling you to damn well write something else and use PolicyKit or some other privileged execution layer to handle it. (Certainly true of Gtk.) Complaining because something is hived into a lib with no command-line interface is reasonable: but the failure there is the absence of a command-line interface, not that a library interface is provided. If shared libraries were bad, they wouldn't be the foundation of pretty much every Unix system for at least a decade (even HP-UX has decent shared libraries now). >> Cdrtools on the other side have a clean privilege separation. >> Check Xcdroast+cdrtools for a clean, safe and portable design. > > Well, if you have udev/consoletools, a userland program can talk > directly to /dev/cdrw or /dev/dvd. .... and anyone using Linux on a non-embedded platform these days who isn't a glutton for minimalism will have udev. >> - It recently started to base on "libcdio". Libcdio is in conflict >> with the Copyright law and cannot be legally distributed. > > Explain in detail your reasoning here. Joerg doesn't like it, thus it's illegal. I grasped this part of his reasoning years ago.
From: FP on 29 Jan 2010 17:59 On 28/01/2010 21:07, Nix wrote: > On 28 Jan 2010, Paul Martin told this: > > >>In article <pan.2010.01.28.11.50.28.354511(a)stovell.nospam.org.uk>, >> Phil Stovell wrote: >> >>>On Wed, 27 Jan 2010 22:39:20 +0000, Nix wrote: >> >>>>I can burn them and I can read them for as long as I can read CD-Rs, but >>>>both give up the ghost completely after a few years. Sucky technology. >> >>>CD-Rs I burned in 2002 as backups for digital photos still work perfectly. >> >>I have some Fujifilm CDs (that cost me �2 each) that I burned back in >>1996 that still play back fine. > > > Maybe I'm storing them wrong or something. Storage is definitely important. A colleague of mine tells he he's having problems reading bought, pressed CDs -- not even CD-R or CD-RW -- from 5 years back. I haven't seen that. But I guess the storage temperature and sunlight incidence is lower; he comes from Hungary, I guess they have better weather over there :) Frank
From: FP on 29 Jan 2010 18:01 On 29/01/2010 21:47, Nix wrote: > On 29 Jan 2010, Paul Martin stated: > > >>In article <7sg807Fv0lU1(a)mid.dfncis.de>, >> Joerg Schilling wrote: >> >> >>>- Important features are missing (UDF, CD Cue sheet, raw writing.....) >> >>UDF support is in the kernel. There's no need to have anything else >>provide it. I have UDF-formatted DVD-RAMs which I simply mount and use >>like any other drive. > > > Quite so. UDF support in the kernel *used* to be crappy, mind you, but it > certainly isn't anymore. (The kernel can also use UDF support directly in > the drive if need be.) > > I've written a *lot* to CD-RWs atop UDF. I've never once even considered > using any userspace tool for anything other than making the filesystem > in the first place. After creation, access is up to the kernel. Having a > userspace program do something like that would feel terribly unpleasant > compared to just letting the kernel do it. Filesystem access has to go > through the VFS, or it's no use at all, IMNSHO: most programs can't get > at it. (This means that e.g. fuse is acceptable.) > > >>>- libcdio is based on a concept that is not feasible for secure >>> environments. It is a lib and thus encourages people to use it from a >>> GUI. Ad the task it implements is a privileged task, you need to >>> run a privileged GUI that cannot be audited for security. >> >>PARDON?!?!? > > > If you try starting programs using a modern widget set as root, they'll > mostly refuse to start, telling you to damn well write something else > and use PolicyKit or some other privileged execution layer to handle it. > (Certainly true of Gtk.) > > Complaining because something is hived into a lib with no command-line > interface is reasonable: but the failure there is the absence of a > command-line interface, not that a library interface is provided. > If shared libraries were bad, they wouldn't be the foundation of pretty > much every Unix system for at least a decade (even HP-UX has decent > shared libraries now). > > >>> Cdrtools on the other side have a clean privilege separation. >>> Check Xcdroast+cdrtools for a clean, safe and portable design. >> >>Well, if you have udev/consoletools, a userland program can talk >>directly to /dev/cdrw or /dev/dvd. > > > ... and anyone using Linux on a non-embedded platform these days who > isn't a glutton for minimalism will have udev. > > >>>- It recently started to base on "libcdio". Libcdio is in conflict >>> with the Copyright law and cannot be legally distributed. >> >>Explain in detail your reasoning here. > > > Joerg doesn't like it, thus it's illegal. I grasped this part of his > reasoning years ago. If it's free software, forking it is legal. If forking it is illegal, it's not free software, by definition, because you don't have the freedom to fork it. Joerg says elsewhere that it's free software. I don't understand. Frank
From: unruh on 29 Jan 2010 18:29
On 2010-01-29, Paul Martin <pm(a)nowster.org.uk> wrote: > In article <7sg807Fv0lU1(a)mid.dfncis.de>, > Joerg Schilling wrote: > >> - Important features are missing (UDF, CD Cue sheet, raw writing.....) > > UDF support is in the kernel. There's no need to have anything else > provide it. I have UDF-formatted DVD-RAMs which I simply mount and use > like any other drive. > >> - libcdio is based on a concept that is not feasible for secure >> environments. It is a lib and thus encourages people to use it from a >> GUI. Ad the task it implements is a privileged task, you need to >> run a privileged GUI that cannot be audited for security. > > PARDON?!?!? I think what he is saying is that a library does not have the concept of priviledges. It the program using the library that has the priviledges and can run suid root for example. If that library is slotted into a GUI, then that GUI would have to be suid root, a security hole. On the other hand cdrecord is a program which itself can have privelege levels. Now one could write a wrapper program for the library which would then be called by the GUI. > >> Cdrtools on the other side have a clean privilege separation. >> Check Xcdroast+cdrtools for a clean, safe and portable design. > > Well, if you have udev/consoletools, a userland program can talk > directly to /dev/cdrw or /dev/dvd. Those are links to something. You cannot talk to them. > >> - It recently started to base on "libcdio". Libcdio is in conflict >> with the Copyright law and cannot be legally distributed. > > Explain in detail your reasoning here. > >> What should be a reason for contributing to such software? > > Let me tell you a little tale... Lets see, what you are trying to do is to demonstrate the reasonableness of Schilling's opposition by making up stories? Remember what cdrkit is IS cdrtools with an added dvd writing module. So if this silly story would be anything to go by, those kids retured with George's ball with a new paint job. By the way, Schilling never limited what you can do with cdrtools. If you want to copy your own porno library there is not restriction. But this analogy is silly. How about returning with a reasonable discussion. > > Once upon a time there was a kid playing with a ball in the park. > > Some other kids were passing by, and he called to them, "Hi. I'm > George. I've got a nice ball. Do you want to play with me?" > > The other kids said that they would, that indeed George had a nice > ball, and they started to play with the ball. > > But George said, "This is my ball. So, you can only throw it where I > tell you." > > The other kids objected to that, as it wouldn't be a proper game under > those conditions, but George only shouted louder and refused to let go > of his ball. They soon lost interest in the game and walked away. > > Some time later, the same kids returned to the park with their own > ball. George said, "Why are you playing with that ball? Mine's much > bigger and bouncier. Yours is second hand and has bits falling off > it." > > The other kids replied that this one was their ball and they were > happy with it, and they were not interested in George's ball as he > wouldn't let them play with it properly. > > George then said he'd call his older brother to beat up the other > kids, but never seemed to go to fetch him. Instead he kept bawling > about how good his ball was, and how rubbish everyone else's was. > > |