Re: DirSync 1.10 released



The following bytes were arranged on 27 Oct 2011 by jeff :

The whole point of RO is that apps can be dropped anywhere. Anywhere.
I'll say it again ANYWHERE.

To have an installer that seems to force a fixed location beggars
belief.

This is indeed a deeply entrenched tradition in RISC OS, and I don't
believe it'll ever change, particularly given the length of time
existing personal hard disc arrangements have had to evolve free of any
restrictions, making changes awkward, counterintuitive, and defying the
supposed 'ease' of a package-based update in the first place - the
experience of running an old version of !DirSync which had not been
removed, thus sparking this whole discussion, being a perfect example.

And why should people change their own arbitrary preferences just so
developers can force their own arbitrary preferences upon them from a
hundred miles away? Packaging works on inferior systems which require
complicated installation procedures and expect to have all applications
registered with a central 'start menu' or near equivalent. It does not
work on RISC OS, with its largely self-contained applications which can
be dragged and dropped to a place at the user's convenience, and run
'out of the box'.

I spent some time working with the RiscPkg system and getting to know
its intricacies in extreme detail eighteen months ago, as a volunteer
for a proposed replacement of ROOL's downloads with packages (which
still hasn't happened), and it was only after I had made a number of
packages myself that I realised just how utterly pointless and
fundementally flawed the whole system was.

Unfortunately, the RiscPkg maintainers seem to be in denial about this.
So-called 'stub' applications sitting in the old place are no more
convincing than a biro cartoon in place of Whistler's mother's head, and
don't alter the fact that somewhere else on the disc is an application
installed where it shouldn't be, at odds with whatever has the
misfortune to surround its chosen location. It might even create its
own directory in the disc root. Until I started messing with RiscPkg, I
had no 'Manuals' directory on my hard disc, so imagine my surprise when
one appeared containing a single PDF file. Another of my computers has
no 'Apps' directory, into which the majority of RiscPkg stuff seems to
go, me having folded it into 'Utilities' some time ago - but then again,
that same computer has no Internet connection (or network card), so
RiscPkg need never trouble it. That's all right, then.

I even suggested a number of remedies which could be made to the
program, within the limits of the existing (primitive) package format,
but my suggestions fell on deaf ears, and the advice from all corners
was that people just need to get used to installing all their software
in locations not of their choice (as users of other systems have to do,
with the latter point made in a tone suggesting it was somehow a good
thing), and once that's happened, they'll automagically forget they ever
used to have more freedom.

Leaving aside the obvious practical impossibility of such a peaceful
state being attained within the decade, as new software releases drip
out and creep across the user base, continually throwing up new
applications which need to be moved, there really is very little need
for it on RISC OS indeed. RiscPkg, on the whole, introduces artificial
complexity where none is required (entire protocols for specifying
system variables and icon sprites, where an entry in the boot 'Look at'
menu would normally suffice, if indeed it was in the least necessary at
all), and defines huge arbitrary rigid data structures and metadata
fields of questionable use, just so it can give off the impression of
doing a lot of important and complicated stuff, while in reality it's
standing with its back to you, waving its hands wildly over an empty
desk and all the while loudly insisting that it's a very tricky job and
you're really getting your money's worth for what it's doing for you.

As others on this thread have previously observed, a RiscPkg archive is,
on the whole, a tiny amount of irrelevant guff (organised into an
intimidating number of subdirectories so as to appear bigger) and the
actual application, which can be perfectly easily installed in the
normal way. RISC OS's application protocol is so well-designed it
rendered packages obsolete before they were even invented.

(A convenient analogy may be found here in the recent mass uptake among
dark side web browsers of this wonderful fancy new concept called
'tabs'. These are a device for holding more than one web page within
the same browser window, with - ludicrously from our perspective - only
one visible at any one time. By default, links set to open 'in new
window' open in a new tab instead. In other words, it's a poor man's
substitute for a properly-written OS window management system.)

Regardless of my misgivings, until recently I remained convinced of the
need for RiscPkg, at least to satisfy the perennial conundrum of easily
installing dependencies for newbies who found themselves having to
download six different things from six different websites. I say "until
recently" because, as some of you may have divined from my apopleptic
rantings on Twitter, I have recently come into possession of a laptop
running a derivative of RedHat Enterprise Linux. There was a whole lot
of stuff I had to install before it behaved almost as I wanted it, and
in the process I made a remarkable discovery of which I had remained
blissfully ignorant before now.

An argument commonly advanced in favour of introducing packaging is that
it has been the standard on Linux for many years now. Well, guess what?
It's a massive heap of shit on Linux too. The noble aim of having one
central software repository holding everything ever written for one's
chosen OS, it turns out, doesn't quite pan out like that once the number
of active developers is pushing double figures. Humans, it is said,
will always find a way to screw everything up.

The endless Google shuffle from website to website searching for the
latest crazy dependency has not been eliminated in the least. It has
got much worse. The software scene has schismed a thousand times over,
on at least two different levels. There is no one repository offering
everything. All repositories accept precisely one version of one Linux
distro each, ostensibly to prevent incompatibilities (which are almost
or completely invisible between some distros in any case, not that that
means the repositories are interchangeable), but in practice leading to
duplication of effort on a massive scale.

Most software is only available in a subset of repositories, meaning you
have to have several active at once - and every time you activate an
'unofficial' repository, you are warned that you are potentially
compromising your system's stability. Worse, a lot of stuff depends on
things not available in the same repository, leaving you to go hunting
for that (and any of *its* dependencies) before you can install the
package you requested in the first place. Quick, convenient and
automatic dependency resolution, eh? The only possible justification is
that, largely, once you've set it all up once the likelihood is that
your chosen repositories will provide you with software indefinitely...
but I'd be inclined to save prospective users the bother and tell them
that once they've installed the list of standard software (e.g. C
libraries) which most applications depend on, it's unlikely anything in
the near future will request anything else.

It doesn't end there. Among the other obstacles a new user has to
chicane around are conflicts caused by the very presence of the package
system itself. Apparently, there are two repositories in particular
called EPEL and Repoforge which have a visceral, deep-seated loathing of
each other, and must never ever ever be activated on the same computer,
lest they spontaneously combust and bring your system down with them.
Don't ask me why this is. Is it really supposed to increase flexibility
and ease of use for end users? Maybe EPEL used to pull Repoforge's
pigtails in the playground or something.

Another undesirable aspect of the culture difference between RISC OS and
Linux (and if you think you're going to force that on a disparate gang
of retired teachers and several examples of the peculiarly common
combination of practicing minister/railway volunteer/real ale
enthusiast, think again) is that, rather than distribute each piece of
software separately, certain authors have an unhelpful habit of only
making their programs available in 'convenient' large bundles of other,
loosely-associated, programs (GStreamer being my personal unpleasant
memory), *all* of which you must download, even if you only want one of
them. This, naturally enough, includes all of the dependencies of the
bits you don't want, and you can bet they won't be guaranteed to be
present in the same repository. If the program you were after was the
only set of dependencies you had to satisfy, the whole process might be
ten times quicker, but no, time to go a-hunting round the interwebs
again. Wasn't this the very job package management was supposed to
eliminate?

In short, packaging, in its much-lauded, well-established, widespread
form, has solved not a single one of the problems its proponents promise
it will. It has however, introduced rather a lot more of its very own.
It does have practical advantages on operating systems which require one
to 'install' applications, but not on ones such as RISC OS where an
application is merely part of the filing system furniture, and the
accepted norm is that they generally take care of their 'installation'
themselves (which is typically restricted to creating a Choices
directory and maybe some default options - trivial for any programmer).
Do we want this on RISC OS? Do I want to have to go through this entire
rigamarole all over again, only this time with the added job of having
to manually hunt for applications I'm updating and remove old versions
placed in directories where I could find them? No, I say. Let's
terminate this madness. It can't possibly solve any more support
headaches for developers than it'll cause.

</midnight rant>

PS: http://mobile.twitter.com/swirlythingy/status/127891767541497856
--
__<^>__
/ _ _ \ You always find something in the last place you look.
( ( |_| ) )
\_> <_/ ======================= Martin Bazley ==========================
.



Relevant Pages

  • Errors applying kernel patch 118833-36
    ... install of Solaris 10 11/06. ... However, once the package list is done, I see a worrisome message: ... Below is the complete console output of the patch run. ... Changes for package SUNWnfsskr will not be applied to the system. ...
    (SunManagers)
  • Re: [opensuse] How to create a live CD/DVD of my installed system
    ... medical repository that can be added and also some programs that can be ... The user must setup mysql and then install the programs correctly. ... I was told that this can be done by KIWI. ... and it says something like config.xml file and the package that I want ...
    (SuSE)
  • Re: Dependencies problem with RHEL 6.1 beta
    ... the problem is the differents versions of same package between oficial DVD and oficial repository. ... Setting up Install Process ...
    (RedHat)
  • Re: SmartMenu - was: VRPC on a USB pen
    ... in applications distributed via package systems which are supposed to ... having to get the user to install it, or they could present the user ... Haskell compiler and associated tools (collectively referred to on ... haskell.org as the 'platform' package). ...
    (comp.sys.acorn.misc)
  • Re: Stronghelp - can I change location set by Packman?
    ... it was needed to install a package though. ... RISC OS desktop. ... Simpler for the newbies arriving from Linux, ...
    (comp.sys.acorn.apps)