Re: CD writing in future Linux (stirring up a hornets' nest)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



El Wed, 25 Jan 2006 16:13:46 +0100 (MET),
Jan Engelhardt <[email protected]> escribió:

> There's one kind of not-so-advanced linux newbies that just go to walmart, 
> buy a computer and whack a linux system on it for fun, and they still don't 
> know if their cdrom is at /dev/hdb or /dev/hdc. Looking for dmesg is 
> usually a nightmare for them, and apart that -scanbus lists scsi 
> host,id,lun instead of /dev/hd* (don't comment on this kthx), it is 
> convenient for this sort of users to find out what's available.

Wait - Looking at dmesg is a nightmare for newbies, but cdrecord -scanbus
is not?

Users should be show the available devices in a pretty GUI and for that to
be possible, the kernel needs to provide a unified way to show userspace
the available devices and notify them when they are added/removed - which
happens to be sysfs + udev etc.

libscg seems to want to replace the operative system for some tasks
in the name of cross-platform compatibility. Sorry, but libscg is
not the center of the world. It's fine that cdrecord does what
it does for the apps for all those platforms where -scanbus and friends
has sense, but linux just has SG_IO. libscg wanting to offer access
to the "transport layer below /dev/hd*" looks like a  layering design
violation in operative systems like linux, but it is fine that cdrecord
has it because it _is_ neccesary in other operative system which do
things differently. 

Using the native features of a platform is a Good Thing when writing
cross-platform software, ie: glib provides a "threading emulation" where
threads are not available, but it uses the native pthreads if it's
available. libscg wants to do everything everywhere, and that'd have
sense if SG_IO weren't able to do what cdrecord needs, but AFAIK from the
multiple flamewars I've seen, SG_IO does everything that cdrecord
needs. I've not had a problem with SG_IO in years...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux