Pages

Search

More DVDs than Debian? - Forums Linux

More DVDs than Debian? - Forums Linux

More DVDs than Debian?

Posted: 22 Sep 2009 12:58 PM PDT

Manuel Rodriguez wrote: 


Difficult task. You can certainly put a LOT onto a 1TB drive. But certainly not all since the beginning. There have been too many distros and too
many versions of distros since 1991.

I do believe Debian is the largest.

Just collecting all of the data could take months.

CUPS admin

Posted: 22 Sep 2009 04:41 AM PDT

On Sep 22, 2:36pm, Unruh <ubc.ca> wrote: 

Now, now: the sudo convention is very handy for keeping users away
from unnecessary use of the 'root' user, especially for shell access.

rose is probably not listed in /etc/sudoers with the appropriate
permissions, while chrisc is.

If you need root shells, and are a member listed in /etc/sudoers, you
can do 'sudo -s -H", which works pretty well.

 

And that's excellent advice. Those 'system authorizaition' menus
basically manage /etc/sudoers. But so far, Magnate didn't say what OS
they're running, nor if their CUPS and in turn their related
ghostscript and other drivers are. So Magnate? If you can give us some
hints about which Linux flavor, and which version of CUPS and in turn
the Epson setup, and look in the /var/log/ directories for information
about what is failing, it might be more helpful overall than simply
getting help with this particular workaround.

Mutiple filename changes

Posted: 21 Sep 2009 08:29 AM PDT

Aragorn schrieb:
 

There exist chances to implement such additional information, similar to
the implementation of the long filenames hack.

 

See above.

 

The *physical* layout of a FAT drive can be FAT12, FAT16 or FAT32, with
the according file *allocation* table format (FAT entries consist of 12,
16 or 32 bits).

The *logical* file *descriptor* format in the directory entries is the
same for all FAT sizes (32 bytes per entry).

VFAT added long filenames to the FAT descriptors, without changing the
specification of the underlying FAT12/16/32 system. The difference
between file descriptors and long filename entries is encoded in the
file attributes bits, so that every VFAT filesystem can be damaged by
the use of older (MS-DOS) tools, which are not aware of the long
filenames hack.


Since every file has a unique starting cluster in the FAT, this number
could be used as the unique inode number of every file. A POSIX system
could build the missing inode descriptors (in detail the exact file
size) from a scan of the filesystem, executed whenever the filesystem is
mounted. Hard links can be implemented by additional file descriptors,
refering to the same start cluster - they would be treated by Windows
systems as corrupt crosslinks, so that a problem, similar to the long
filenames problem, would exist with such hard links, when Microsoft
tools check the filesystem. Perhaps hard links can be hidden from such
unwaware tools by special settings of the file attribute bits, similar
to the implementation of the long filename entries.

Please note: I do not encourage the implementation of hard links this
way, I only want to point out chances for such an implementation.

 

Microsoft has doented the old (8.3) DOS filename as "alternate", i.e.
the primary VFAT filename is the long (UTF-16) version. A POSIX VFAT
implementation should apply the *same* ranking on the filenames, and IMO
this handling already *is* the Linux standard.

A POSIX system can (should?) treat the two names as links to the same
file, and act upon these links according to POSIX rules. I'm not sure
about the best POSIX equivalent, but IMO the long filename is nothing
but a symlink to the (immediately following) file descriptor.

 

As already mentioned, a POSIX filesystem should ignore the alternate
name and only deal with the long name. As long as no long name exists,
the 8.3 name can be used instead, but on a rename a long name with the
new name and spelling should be created.

With regards to the case-insensitive handling of filenames, it only
matters when Windows compatible access is really required. IMO this can
happen only when Windows applications, scripts or doents come into
the play, which want to refer to files in an case-insensitive way.
Normal operation of a POSIX system can respect the case of the
filenames, without breaking anything.

 

The alternate (your primary) filename is stored when a file is created.
There exists no requirement to change that name at any later time.
Alternate filenames can be used as a second chance, when no long
filename matches a search pattern (see my symlink suggestion above).

Windows may update the alternate filename as well, when a file is
renamed *and* the new name is compatible with the 8.3 naming rules. In
this case an eventually existing long filename *may* be removed, just
like a POSIX system would drop one of two identical links to the same
file, in the same directory. But this only is a *behaviour* of the OS,
not a requirement of the file system. Applying different rules, in a
POSIX implementation, will not violate any FAT specs.

The only real requirement for filenames on FAT volumes is, that no
filename entries can exist in a directory at the same time, which *only*
differ in case. POSIX imposes the essentially same restriction,
different only in the handling of case sensitivity (no directory can
contain multiple entries of exactly the same name).

 

You seem to favor an exact emulation of the Windows behaviour on Linux.
I see no need for such a slavish emulation.

Its perfectly sufficient to conform with VFAT specs WRT the *stored*
information only. I also see a chance for mounting options, indicating
how Linux should treat an specific VFAT drive. Then it's up to the user
to enable case sensitive interpretation of filenames, and the
implementation of links and POSIX permissions, as far as possible with
the stored VFAT data structures.

DoDi

Puzzled about KDE or GNOME or what?

Posted: 21 Sep 2009 01:53 AM PDT

On Wed, 23 Sep 2009 03:47:50 +0000, Chris F.A. Johnson wrote:
 

I really thought criticism would smoke Sid out. I'm very disappointed.
C'mon Sid!

--
d.b. cooper

Email server setup

Posted: 20 Sep 2009 10:01 AM PDT

Aragorn wrote: 

Yes, just got it fixed. It was a laptop configuration problem.
 

I agree. But it never really gave an error message, it just
hung after login. But in any case I just got it fixed.

All seems to be working. Way cool.

Roger

Fedora Core 5

Posted: 18 Sep 2009 11:26 PM PDT

On Tuesday 22 September 2009 15:53, someone identifying as *Sydney*
wrote in /comp.os.linux.setup:/
 

What Moe was asking about is whether your wireless device might have
a /native/ driver in Fedora 11. However, /ndiswrapper/ should already
be in FC 5 as well. On this old Mandrake system here, with kernel
2.6.3, it is also already present.

<snip>
 

You need to use the /ndiswrapper/ that came with the kernel you are
using, i.e. this one:

/lib/modules/`uname -r`/kernel/3rdparty/ndiswrapper

*Note:* Those "quotes" in the above path are not apostrophes but rather
what you would in French call an "accent grave". The shell will
substitute the command between these two accent graves by its output.

Hope this helps. ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)

FC11, libusb, HP scanner (G4050)

Posted: 17 Sep 2009 07:10 PM PDT

On Thu, 17 Sep 2009 22:10:14 -0400, K.A. <net> wrote:
 

With my canon mp150 usb scanner/printer, scanimage -l does not show it
either, yet xsane does detect it, and allow it to be selected, along
with my usb webcam.

Try xsane, to see if it is detected.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)