Re: Re: [pickup] [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes
- From: David Zeuthen <david fubar dk>
- To: nf <nf2 scheinwelt at>
- Cc: Nautilus mailing <nautilus-list gnome org>
- Subject: Re: Re: [pickup] [RFC/PATCH] Nonotify - A simplistic way to determine directory content changes
- Date: Mon, 21 Jun 2004 15:38:13 +0200
On Mon, Jun 21, 2004 at 02:58:12PM +0200, nf wrote:
> > > And now - my opinion on the drive-locking issue (maybe i am repeating
> > > myself):
> > >
> > > -) Cdroms don't need to get locked, because they are read-only. Locking
> > > only makes sense for read/write devices (To prevent file-system
> > > corruption).
> > True. But a program relying on the cd can crash if it gets removed (if
> > badly written).
>
> Dealing with I/O errors when reading a file is the most basic thing.
> A program that does not handle them properly ... well ...
> And remember: You can only lock CD-Trays - but no other media...
>
Anyone can write an application that behaves badly, such applications need
not be in official GNOME desktop nor in Linux distributions or other
operating systems carrying GNOME and GNOME applications.
> Don't misunderstand me - i'm just calling for a "back to the roots"
> approach: Make things work before adding tons of features. Stay
> consistent with the OS underneath. I'm not a kernel expert, but i
> think a lot of problems of the linux desktop arise from
> feature-fanatism and putting all those layers between the user and
> kernel-"reality" - trying to fix problems at the wrong place.
I disagree, GNOME needs to run on many UNIX-like platforms and going
for the lowest common denominator is just not going to work. Properly
designed abstractions is a good thing in many ways, much better than
packing a lot of features in the kernel. Partly because features
equals policy most of the time and partly because kernel code needs to
be audited helluva lot more than userspace code.
I do agree, however, there are several problems in the Linux kernel
that needs to be resolved before the utopia dream of desktop linux is
reached, but please think of portability.
> Gnome-vfs might be taken as an example for this: Because smbmount
> didn't work properly, they pulled smb-connectivity into gnome-vfs -
> however breaking compatibility with all non-gnome applications...
I also think there's an important free software angle here - it's
dangerous to have too many Linux dependencies in GNOME. It's just not
right, it also makes it more difficult should the interfaces in Linux
change. And if GNOME makes that difficult, the interfaces probably
won't change and we arrive at status quo.
Doing smb in userspace is not that less efficient and it just works on
other operating systems and gives you much more flexibility since you
only have to deal with session-wide issues and not system-wide issues
like getting the kernel to mount a smb share. This is evil, because
you want to keep the policy at the session level at the control of
the user and GNOME software.
Try looking at HAL, here we carefully do a lot of system-wide stuff
such that the session can maintain the policy (like we allow hooks to
maintain /etc/fstab for removable media such that the GNOME session
can do a simple 'mount /dev/sda1').
And hopefully one day we'll get that shiny happy freedesktop.org VFS
layer or something. VFS layers in session-space is a good thing IMHO.
Cheers,
David
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]