Re: OS/Environment integration [was: wide characters and i18n]

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Thu, 15 Jul 2010 09:28:50 -0400 (EDT)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> > 1. there's a fundamentally nasty problem that UNIX itself has never
> > dealt with in a general way: what's in that file?  Text?  MPEG
> > streams?  JPEG?
> 
> I would disagree that UNIX has never dealt with that problem.  I would
> say that UNIX _has_ dealt with it, by explicitly pushing it off to the
> application layer, and that, indeed, that is where much of its power
> and flexibility comes from.  I regularly do useful things by treating
> data as if it were of a type it originally wasn't intended to be.

I guess that with the advent of FUSE/PUFFS it would not not be too hard
to have an FS-level type layer equiped with a range of libraries for
various formats, such as was used on Amiga for a while (where the OS
itself didn't care, but application level could plug in custom
filesystem and device handlers which the microkernel model made easy).
I've never needed that kind of abstraction personally, but it's not
something that couldn't be done on some unix systems today, IMO.

In a way, I think that huge environments like Gnome have a virtual VFS
library layer to deal with such integration issues (where the file
manager can allow the user inside archives, for instance, and an
integrated viewer can deal with a number of "codec" modules).  Of
course that's not identical to a system where a type metadata tag is
necessary for every file.  But it can auto-detect a-la-file(1),
optionally then store a tag/property for later use as an optimization,
and deal with many file formats at the application/library/environment
level...

And indeed when you do have to deal yourself with the data, the system
won't be an obstacle, because it's not something dealt with by the OS
itself.

> > [...] ... but then I don't use X11 (too many years of using the much
> > more thoroughly integrated MacOS environment has spoiled me - every
> > time I try to use X, I have to work hard to suppress the strong
> > desire to do violence to the people responsible for it).
> [...]
> Also, you may be confusing X with some common window system built on X.
> It would be entirely possible to build a UI as thoroughly integrated as
> the Mac one is atop X.  (I don't know why it hasn't been done, or why
> it hasn't gained wide popularity if it has.)  X is not a window system,
> despite being named as one; it's really a framework for building window
> systems.

KDE and Gnome are getting pretty close, as long as you restrict
yourself to the set of official and recent enough applications for
them.  If that matters to you, of course (I think it's no priority for
you or me).  Similarily on OSX you have to restrict yourself to Cocoa
applications if integration is important...

An area where I think there is lacking integration between the OS and
open source desktop environments is when a removable device is removed
before the buffer cache could be flushed or volume still mounted.

We don't currently ask the user to insert the volume back easily and
resume gracefully.  This is something which AmigaOS could do.  What
helped there was that the hardware (including floppy drives) could
detect insertion/removal, and every file system was tagged with a
volume name and ID.  Since USB/Firewire can detect such events, an
implementation could be possible in the future, though.

Another aspect to this was that on AmigaOS an application could attempt
to open a file and the environment would ask the user to insert the
needed volume.  This also needs volume name support.  Since open
source user GUI environments also support a degree of OS portability,
this is an additional obstacle to such highly OS/GUI coupled
integration (and I'm unsure a HAL-type layer can deal with all of those
differences for so many features, some of which totally lacking on a
system or another).

I honestly don't know if OSX does this, but it certainly is easier to
implement on an operating system which includes its own desktop
environment natively...
-- 
Matt