On Wednesday 13 November 2002 12:28, Frank Van Damme wrote: > On Wednesday 13 November 2002 03:48, Carlos Carvalho wrote: > > I'm glad to finally see a discussion of this subject. I find the > > structure of CD recording software in Linux quite outdated and > > inadequate for a multi-user environment (note that this isn't a KDE > > problem). The software was clearly conceived to be used by someone > > with root access sitting on the console of the machine, which is > > almost the opposite of what is necessary for a CD-recorder server. > > It's ugly allright... but why does writing cd's need root privilegies? Isn't > it an inadequacy in the kernel? > > > I'd like to have something similar to what we have for scanners: a > > daemon (that may run as root if necessary) waiting for connections > > through the net and operating the device, or interfacing with a > > driver. The user interacts remotely with a client software (of course > > the user may via localhost as well). This approach has many > > advantages: > > Oh no... not another daemon...
If you hate daemons: How about a program started via hotplug(?) when a cd is inserted? >;-) > > a) it removes permissions problems from the scene; > > b) no need for authentication of users, because it's not the user that > > has access, it's the daemon. Access to the daemon is controlled by > > standard methods (firewall, tcp wrappers, etc.); > > Er, maybe. You mean because the daemon runs as root? Then it just places the > permission problem somewhere else: with the daemon. There should always be a > way to go without daemons in any case (if you're just using the writer > locally). Right but a daemon is much more flexible how do deal with authorization and access rights. Having to logout/in from/to X session to activate new group group member ship is something like rebooting Windoof after every software installation. Stupid but necessary (and no: su/ssh etc is no good solution of Mum and Dad). I'm really curious what solution the debian desktop project will develop. > > c) it allows the use of the recorder by users in other machines. This > > way we can have a diskless machine with just a recorder and users > > connect from a login server via the client software. I have here a > > scanner connected to such a machine that also controls the printers > > and works as a X-term, while the login server remains locked in > > another room and users reach it from X-terminals. yes, yes please ;) > > Let me guess: ltsp addon? :-) > > The only thing I can think of that currently comes close is webcdrwriter. > It's > a java applet client-side and a daemon that operates cdrecord server-side. > > > I use this approach for CD readers, floppy drives, scanners, > > printers, zip drives, but I cannot do it for CD recorders :-( :-( > > Floppy drives? without mounting them on the server you mean? how? with floppy:/a and mtools one can work with floppies without mounting them. And for remote access: ds10[1] ~ # apt-cache search floppyd floppyd - Daemon for remote access to floppy drives > > (I burned a few floppy controllers a while ago) > > > I understand that cdrecord and family were written at a time when > > recording a CD was a delicate operation. However with the fast > > machines and network of today the picture has changed completely, and > > it seems to me that a revamp is really necessary. In the process we > > could perhaps get rid of scsi emulation... > > Uh-oh... and now comes the argumentation "today, we all have pretty big > machines so we can afford to make an overhead-producing daemon :-/ > I like cdrecord for its power, flexibility, performance, stability and low > system requirements. Maybe it's better to remove the need for root > privilegies completely (what is a multiuser system worth if you have to do > anything that's useful with root privilegies?) Maybe cdrecord doesn't need to > get trashed, it may be just enough to make it run as a client of that fancy > daemon you're intending to code :-) in a way like now gui clients use > cdrecord. > > /----------------\ /----------\ /--------\ > So: | $kde*cd*burner |=--->| cdrecord |=-->| kernel | > \----------------/ \----------/ \--------/ > > || > \/ > /----------------\ /------------\ /----------\ /--------\ > | $kde_cd_burner |=--->| netCDaemon |=--->| cdrecord |=--->| kernel | > \----------------/ \------------/ \----------/ \--------/ > > > btw, I think freebsd already writes cds without scsi emulation isn't it? linux > 2.5.44 can do it. http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|tags torvalds 1.781.29.3 Remove ide-cd reliance on "struct packet_struct", make it use the native "struct request" fields instead. Simplify and clean up sense data handling. This makes IDE CD-RW burning possible without ide-scsi.c > > The same strategy is used in the Network Audio System (NAS) developed > > by NCD and available in the libaudio-dev package. Next is the camera :-) > > Artsd has network transpareency doesn't it? Yes, but I could not come up with good solution to run artsd on an X-terminal. artsd -> nas daemon is also possible but when I tried ( ~ 1 year ago) the output was horrible. Same sample played several time with a time offset. that was on a 100mb switched network). Does NAS work for someone? Worth to try again? > > > Any volunteers? :-) > > Within a few months maybe ;-) please s/maybe// :) Achim > > Frank > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED]
