In comp.os.linux.advocacy, Oxford
<colalovesmacs@mac.com>
wrote
on Mon, 08 Oct 2007 15:03:10 -0600
<colalovesmacs-591FE9.15031008102007@mpls-nnrp-02.inet.qwest.net>:
> George Graves <gmgraves2@comcast.net> wrote:
>
>> Could a company like, for instance, Adobe, release a single shrink-wrapped
>> fully compiled version of its applications marked "For Linux" and have it
>> install as easily on ALL modern Linux distributions as it now does on PCs or
>> Macs? If so, then you're right. But that begs another question. If all the
>> distros are that alike, why haven't any of the major software publishers
>> released any of their applications on Linux?.
>
> from my understanding Linux simply doesn't have a modern enough
> foundation to support high level apps like PhotoShop, InDesign, etc.
Does Windows? Windows has Photoshop, InDesign, etc.
I'd like to know what "modern" means in this context,
specifically what is in the foundation of a "modern OS".
For example, one of the selling points of the old Mac
OS was its Resource Fork the general idea was to use a
hierarchical typed container system, which could contain
code, pictures, audio, and stylized text. Windows also
has a Resource Fork, though it's not nearly as widely used
in its software Windows tends to like to put things in
its Registry, instead.
And of course most operating systems have a Graphical User
Interface Windows in particular has Win32 and Mac OSX has
something which I can't properly identify, apart from the
fact that the X Window System (X11) is part of its makeup.
(Mac OS had Quickdraw, but I'm not sure what layer that
was -- API or drivers?)
For its part Linux has none of a Resource Fork, a Registry,
nor a GUI [+]. Clearly, this makes Linux ancient in
design and philosophy -- except that Unix, which is more
or less Linux's precursor, was object-oriented before the
concept even *existed*, though later revs took out some of
the objectuivity (if that's a word) by disallowing open()
on a directory, for example. However, one can still open()
a symbolic link (which results, as it turns out, in opening
the file to which the link points). AFAIK, Mac OS did not
have this concept (not sure it really needed it, but it
does come in handy), and fortunately Mac OSX inherited it
from its Mach/Unix kernel. The Amiga, before it died, had
a concept very akin to a Unix "hard link", a concept rarely
used (though still available) in Unix or Linux today. [*]
Windows has a very befuddled implementation of shortcuts.
And of course X11 carefully implemented client versus
server communications, which effectively made abstract
tokens out of pretty much everything except an XImage,
which was a client-local datastructure. Windows tried
it has things such as a "device-independent bitmap",
or DIB, but that was somewhat later on, if memory serves.
>
> they'd have to do a lot of software kludges to make a Linux versions
> work correctly and since the Linux market is so tiny compared to the Mac
> one in the creative fields they simply can't afford do it.
Or test it. It is a problem until we mimic the entire
functionality list of both Windows and Mac OS/Mac OSX, we
probably won't be able to get good high-quality software
on Linux.
(Spot the flaw.)
>
> Same for all other professional level apps, like Office, iLife, AutoCad,
> etc. Their approach is too fractured and hard to support is the other
> issue. Wish it was different, but unless they "focus", they will never
> be a serious contender.
And what, precisely, should Linux (or a Linux distro, more
properly) focus on?
[+] the GUI in most distros is implemented using a mixture
of Linux for the very base support such as framebuffers
and KGI, the X server, and user-level libraries such
as Qt and Gtk. Utility programs are also available,
which gives one KDE and Gnome -- the entire enchilada,
as it were.
[*] in a soft link, an entry points to another entry by
name that entry can easily be changed. In a hard
link, an entry points to an *object* (identified by
inode), and once made, a hardlink is indistinguishable
from any other reference to that object. In effect,
one has two or more entries for the same object
-- a fact reflected in the link count of the
stat()/lstat()/fstat() call. (Since directories all
contain '.' and '..', the link count for a directory
can be any number greater than or equal to 2, and
depends on the number of directories immediately below.)
In other words:
(create file a)
ln a b
rm a
is indistinguishable from
(create file b)
as far as other tools are concerned, after this
sequence of instructions is done. In a symlink
(ln -s a b above) deleting a would result in a
broken symlink it is still possible to do a create
through that symlink under certain conditions, but
it points to no object prior to that creation.
For its part the Amiga implementation was asymmetrical,
unlike the Unix one, which presumably led to some
interesting quirks. Part of that asymmetry was because
the Amiga did not have inodes as such, and therefore
could not implement the symmetric variant.
--
#191,
ewill3@earthlink.net
Windows. When it absolutely, positively, has to crash.
--
Posted via a free Usenet account from
http://www.teranews.com