Re: [opensuse] Re: Beagle frontend



Peter Nikolic wrote:
On Tuesday 14 Jul 2009 20:10:22 Joachim Schrod wrote:

Peter Nikolic wrote:

On Tuesday 14 Jul 2009 16:52:30 Joachim Schrod wrote:

Peter Nikolic wrote:

On Tuesday 14 Jul 2009 14:53:02 Adam Tauno Williams wrote:

Disabling Beagle is well covered at

Lets face it beagle is nothing more than an excuse for a poorly
organised filing system not on the machines behalf but on the side of
the user , IF the user was to have a sensible way of creating storing
and sorting his files in the first place there would be no need for
the unmitigated resource hog in the first place it just allows
people to be lax and untidy

so there is no reason for it to be installed there is on the other
hand a need to teach people to organise the machines .

Are you a troll, do you really believe that sh*t, or are you a
superhuman?


At the risk of putting fuel on the fire instead of dousing the flames, I
would like to say the following, after having followed this thread, as
well as its subject, with interest for some time now.

From the sidelines, it looks to me like two very talented and active
individuals have two entirely different ways of organizing their lives
and their computers. Neither is wrong, and for some people, only one way
will work, while for others, either could be made to work.

Point 1. This is why Beagle (or Nepomuk, or any "breakthrough" new
technology should NOT be automatically turned on at install. However, it
should probably install and be easy to toggle on (or back off, if it is
found not to work for a user). If beagle was truly totally transparent,
that would be different. But it is not -- it uses resources at times
that conflict with the user's needs in some cases.

Disk is relatively cheap, so putting the package(s) on disk at install
time isn't really much of a problem for most people.

If you want to put 11.x on a NEC Multispeed laptop with dual 720K
floppies as its only persistent storage (OK, an exaggeration, but if you
want to put it on a fairly old, barebones system...) then you should be
willing to remove packages you don't need. Once you are in "the long
tail" you should expect to have to do a few things special to get into
the game.

But why not offer an install config document, plus the kind of package
selection that is available for SLES, so that the issue of installing
the software can be handled with a technical, rather than a political,
either-or, solution?

Point 2. No new technology (that is not truly transparent to the end
user) should ever install itself in a way that it is automatically
turned on. The burden should not be on the user to discover and decide
what to do about that new technology. If the devs want it adopted, get
it in the core bundle, but please DO NOT turn it on and make me find it
and turn it off if I don't like it. No matter HOW much you believe I
will benefit from it and/or like it, once (and only after) I am
forcefully exposed to it.

(Yes, I am thinking of KDE4 as well as beagle. Coincidentally, both
serve as pilot packages for new and significant technologies, which may
be what is driving their desire to gain user base by any means. Plasma
and Mono may both be interesting technologies, but some of us may not
want to make the switch for a variety of reasons. Make them compelling
to use, rather than compelling me to use them, PLEASE.)

Point 3. Re: supposed beagle slowness. I can confirm that it was slow on
a Thinkpad T61 at 10.3 even after initial indexing was done. However, as
someone else pointed out, the issue is now reduced to severe slowness
only when doing initial indexing, especially if certain excludes are
configured. BUT, those excludes, if they improve the average user's
experience, should be automatically set at install time, at least as an
clearly defined option.

For years, when forced to use Windoze (as well as several other OS's) in
a business environment, I always disliked having the vendor or dev "do
things for me" that were not necessarilary better for me, instead of
promoting their new way, and letting me decide. Linux and openSuSE in
particular, are no different...do NOT load and turn on things I don't
need just because SOMEONE will benefit from them.

Had beagle (and the hotly debated KDE4) been introduced on a buy-in
basis, instead of being pushed out to meet the needs and/or desires of
the developers, they might not have achieved as much acceptance as
quickly as they have. But on the other hand, there would be a lot less
frustrated users, and probably more people who gave them a real try on
their schedule.

Currently, I have configured certain excludes from beagle, and it is
seldom noticeable as a delayer when I have it running. However, I have
since turned it off, as I seldom need it. But I want it onboard
(installed but not turned on) in case I ever have to locate "all my
knives with blades between 1.5 and 3.5 inches", as a figurative example.

In short, I want it there, but I don't want or need it on all the time.
And I don't want it to run automatically, without having chosen that it
do so.

Form should follow function, and the form of the install should follow
the functional idea that such new things should be easily accessible but
not automatically turned on.

The user should have the first, last, and all final says in what runs on
their machine, and why. Period, no exceptions. That is (to me) precisely
why Linux began and continues to thrive -- it puts control back into my
hands, rather than making me a passenger on someone else's journey to
the future.

And please, don't throw out bug fixes as a counter-example. I am talking
about packages only, and then only those that introduce new techniques
at the expense of configuration and resource demands. They are what I am
talking about when I say that they should be installable (as an option,
preferably), but should NEVER be turned on automatically just because
they are installed.

Right now, Suse is my distro of choice, both because of personal
preference and professional needs. But if it, or any distro, got to
where it was dictating to me what my desktop "should" look like, or how
my data is organized, I would drop it like a hot rock and find a distro
that treats new things as options to be chosen by the user, not pushed
onto the user by the "true believer" devs. That is precisely the reason
I abandoned KDE4 for now, even though initially KDE (3) was my strong
preference.

I dropped it only after several frustrating weeks of trying to get it to
work without problems. No matter how many people it helped, my
experience made it more of a problem than a solution for me. And nothing
I saw during those weeks was enough of a "killer app" to make me want to
rush back to it.

I suspect my experience parallels a sizeable percentage of users who
were "guided onto" KDE4 in order to make it a better product. And no
matter how many other users had no problems, or were able to overcome
them, none of that provided the least bit of comfort to me, as I was
stuck with MY experience of a package that was not ready for use in
anything other than a VM. I can't get my work done on your machine...

I appreciate all the effort that many dedicated devs put into this
distro, and these packages.

But please, let's not forget, as the saying goes "you can catch more
flies with honey than with vinegar". And the easiest way to turn off a
user is to give them headaches trying to work around what you think is
the best thing since toast.

Beagle is a solution to a problem for SOME, not ALL. That is why it
should not be turned on automatically. Didn't anyone remember the
backlash when Microsoft and Google both tried to "slipstream" in desktop
indexing?

I am curious about Nepomuk, but I sincerely believe that the right
decision was made to install it but to leave it off by default, in 11.2.
If only the same type of approach had been done with beagle and with
KDE4, half the dissatisfaction expressed on this list would never have
occurred.

I would have liked to have been one of the early adopters of KDE4 -- but
the experience was too much bleeding edge and too little leading edge,
as first rolled out. So I will still try to be an early adopter of
various packages, as part of my being a "citizen" of the open source
community. But I doubt that KDE will be one of them, based on the way it
was initially presented.

Please, as a community, lets learn from the past, and lets stick to the
principle that the user, not the developer, should decide what is best
for the user -- what is installed, and when to turn it on. Even if that
slows down development.

Sustainable progress cannot be obtained at the expense of costing users
time and effort that they have not signed up for. People contribute in
various ways to open source based on "enlightened altruism", not
unbridled, totally self-less altruism.

As a dev, you may be smarter than the average user. But the only way you
are going to win a base of users is to educate and convince them, not by
corralling them and then hoping that they stick around once you have
them running your package.

That is a sure-fire formula for a way to "fork" the user bases, if not
the code. After all, the ultimate "fork" is to simply find a different
solution, and if you alienate a percentage of the available user base,
you might as well have prompted a fork of the code -- those users are
lost to you, probably for ever, or at least for a long time, and then
only after you give them a compelling argument in the future, in order
to overcome their past unpleasant experiences.

That is why, for example, I now run Gnome after beginning on this distro
with KDE, and after initially thinking that I would stick with KDE. I am
only one user, but surely my experience, and its results, are not unique.

Please, once more, for all its faults, this community is alive and
active, and has lots of talented and committed individuals...let's try
to start doing the things that tend to draw us together, rather than
treating the community as a resource to be tapped when wider usage is
needed by the devs.

I really don't want to leave this distro, and I don't want it to become
a boutique distro that works well out of the box only for the true
believers and the lucky percent that don't hit problems when upgrading.
I hope that this rant helps in some small way to achieve that end.

Build the new tools, get them into the distro, publicize them, and wait
for the user to turn them on, please...no more "we need to get them
using it for their own good" mentality.

--Dan

Notice: This communication, including attachments, may contain confidential or proprietary information to be conveyed solely for the intended recipient(s). If you are not the intended recipient, or if you otherwise received this message in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments, without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is strictly prohibited and may be unlawful.
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx



Relevant Pages

  • Re: Tcl/TK + Linux --> confused newbie
    ... Having been pointed to Ubuntu as a suitable distro I have been following ... _and_ has an excellent set of tcl related packages). ... I recently asked about a "lean" install of Ubuntu. ... A linux version of Tcl just needs a suitable version of GLIBC (libc, ...
    (comp.lang.tcl)
  • Re: Is Linux always so frustating^
    ... Sometimes the choice of a distro is just a subjective matter. ... Perhaps the key question is "How" you tryed to install the stuff... ... The problem is that many packages have dependencies on other packages; ... In the most cases drivers are completely unnecesary. ...
    (Fedora)
  • Re: Linux Vs. FreeBSD
    ... >> has made a lot of effort towards making it easy to install. ... Debian's not a bad distro. ... although packages like this are few and far between. ... since the binary dependencies certainly wouldn't be any ...
    (comp.os.linux.misc)
  • Re: [SLE] Installing other distros RPM packages?
    ... >>that whilst it may be possible to install other distro RPM's on our ... >>those packages from source into a SuSE RPM and then installing it? ...
    (SuSE)
  • Re: Next openSUSE
    ... To fix a thing one has to know the cause AND has to know on HOW to fix it. ... one has to install. ... beagle ... Uninstall the packages found and you'll have no issues with beagle again. ...
    (alt.os.linux.suse)