Aw: Re: the hell of Maemo repos

Hallo!

As one of the people that had shutdown his own repository as response to mentioned request to consolidate I can assure that such request was very polite, I was never forced and every help was promised (which I did not need) and no timeline was given. We never talked about the actual contents of my repository.

I fact I'm of the opinion that such aproach goes into the direction.

So please wait until the owner of the now closed repository speaks up to clearify.

Note that Nokia regarding this aspect is not Apple.

Please calm down and let the facts speak.

Gruß...
        Tim

2008/11/21 Tim Teulings <rael@edge.ping.de>

>
> Note that Nokia regarding this aspect is not Apple.
>
> Please calm down and let the facts speak.


Ok, Tim. I *really* love your contribution to the Maemo community, and
anderenen repository was one of my *must*... So I really appreciate your
point of view.

But, come on, someone who could tell me where's kismet package... It's
supposed to be in repository.maemo.org ... Dave talked about an ideal
"devel-extra" folder that doesn't exist, at least as detailed in their
webpage <http://repository.maemo.org/> ...

(Very important: I've already got my own copy of kismet package... this rant
is to help the community not myself)

I think you should understand how frustrating is for end-users this kind of
situations... and I must admit that I've learned a *big* lot of Unix admin
since I got my 770. (In fact
these<http://wiki.maemo.org/Booting_from_a_flash_card>
wikis <http://wiki.maemo.org/Partitioning_a_flash_card> are more or less my
own creatures... )

Salut,
Sebas.

On Fri, Nov 21, 2008 at 12:38 PM, Tim Teulings <rael@edge.ping.de> wrote:
> Hallo!
>
> As one of the people that had shutdown his own repository as response to mentioned request to consolidate I can assure that such request was very polite, I was never forced and every help was promised (which I did not need) and no timeline was given. We never talked about the actual contents of my repository.
>

...Which is clearly a bad idea. The details obviously *should* be
worked out and a timeline chosen so that the switchover can happen
smoothly. It can be cooperative rather than dictatorial, but that's
irrelevant to the end-user.

> I fact I'm of the opinion that such aproach goes into the direction.

Of what? It's a bad thing to have seamless transitions?

>
> So please wait until the owner of the now closed repository speaks up to clearify.
>

It doesn't matter how politely Nokia may have asked you to shutdown
your repository any more than it matters how "rudely" someone may
express their discontent about a problem with their device, its OS or
an application. The truth is the truth, regardless of how it's
couched.

> Note that Nokia regarding this aspect is not Apple.
>
> Please calm down and let the facts speak.
>
> Gruß...
> Tim

On the contrary, Nokia is proving to be more unresponsive and
unreasonable than Apple. At least Apple takes responsibility not only
for their hardware devices but for their usability. Nokia apparently
thinks they can just throw their devices out into the wild and their
responsibility ends there.

Mark

2008/11/21 Mark <wolfmane@gmail.com>

>
> Nokia apparently thinks they can just throw their devices out into the
> wild and their responsibility ends there.


;-)

That's exactly how I feel about it...

Salut,
Sebas.

I think Nokia know devices will live on long beyond production.

Having the extras repository on maemo.org is a *good* thing. sure, right now
there could be teething troubles and specific packages might be missing but
in the long-run it will improve.

How long should an independent developer keep his individual maemo app
repository open after he leaves the maemo community?
Do they stay forever or does bitrot occur?

Having applications stored on the maemo.org repository allows developers to
come and go safe in the knowledge that users will *always* be able to get at
their software, even after the developer has left for good.

I know that my package is safely in the hands of maemo experts and will be
looked after and cared for better than if I had created my own repository.

Nokia and its employees and contractors and the good people around
maemo.orgare doing things with the best of intentions and are trying
to build a
distribution free from any kind of crap and hunting for repositories (which
other mainline linux distro needs a repository search?)

the best way to help the community is by being constructive and it saddens
me when bickering like this starts because it degrades the good hard work
people have put in to help others.

gary



On Fri, Nov 21, 2008 at 8:05 PM, sebastian maemo
<sebastian.maemo@gmail.com>wrote:

> 2008/11/21 Mark <wolfmane@gmail.com>
>
>>
>> Nokia apparently thinks they can just throw their devices out into the
>> wild and their responsibility ends there.
>>
>
> ;-)
>
> That's exactly how I feel about it...
>
> Salut,
> Sebas.
>
>
>
>

A couple comments on this subject. First, it doesn't do anyone any good
to attack the messengers or worker bees regardless of what their
involvement with the tablets is. Stuff happens, stuff gets noticed and
brought to attention, stuff gets corrected. No one is intentionally
screwing things up. Most of this is about how everyone in this
community is comes from different perspectives that don't always see
things from everyone else's perspective.

Consolidation -- It's fine with endusers like me if repositories are
consolidated. Perhaps it would help if Nokia offered some sort of
incentive, like low priced/free units and alpha/beta testing for
developers using the Maemo system for their development and repositories.

End-user considerations -- There needs to be a smooth way to redirect
updating of outside repositories to the consolidated/changed
repositories so end users get their updating done smoothly and without
hassles. This would seem to require inclusion of some sort of cleanup
process in App Manager for redirected repositories. Those out of the
'loop' are likely end up with all sorts of abandoned/screwed up
repositories, with negative side effects that don't help anyone.

If appXXXX is moved from repo YYY to reop ZZZ, app manager needs to be
able to sort this out without dragging endusers too deep into the
wonderful world of maemo/debian linux hunting down moved repos and
apps. As it is, App Manager seems a rather crude work in progress that
displays the crudest information during the updating process -- it
doesn't even say what repository catalog is being updated during the
update process.

Tim Teulings wrote:
> Hallo!
>
> As one of the people that had shutdown his own repository as response to mentioned request to consolidate I can assure that such request was very polite, I was never forced and every help was promised (which I did not need) and no timeline was given. We never talked about the actual contents of my repository.
>
> I fact I'm of the opinion that such aproach goes into the direction.
>
> So please wait until the owner of the now closed repository speaks up to clearify.
>
> Note that Nokia regarding this aspect is not Apple.
>
> Please calm down and let the facts speak.
>
> Gruß...
> Tim

> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.9.9/1803 - Release Date: 11/21/2008 9:37 AM
>
>

On Fri, Nov 21, 2008 at 2:51 PM, lakestevensdental
<lakestevensdental@verizon.net> wrote:
> Consolidation -- It's fine with endusers like me if repositories are
> consolidated. Perhaps it would help if Nokia offered some sort of
> incentive, like low priced/free units and alpha/beta testing for
> developers using the Maemo system for their development and repositories.
>
> End-user considerations -- There needs to be a smooth way to redirect
> updating of outside repositories to the consolidated/changed
> repositories so end users get their updating done smoothly and without
> hassles. This would seem to require inclusion of some sort of cleanup
> process in App Manager for redirected repositories. Those out of the
> 'loop' are likely end up with all sorts of abandoned/screwed up
> repositories, with negative side effects that don't help anyone.
>
> If appXXXX is moved from repo YYY to reop ZZZ, app manager needs to be
> able to sort this out without dragging endusers too deep into the
> wonderful world of maemo/debian linux hunting down moved repos and
> apps. As it is, App Manager seems a rather crude work in progress that
> displays the crudest information during the updating process -- it
> doesn't even say what repository catalog is being updated during the
> update process.
>

I also have to point out that the maemo site is always incredibly
slow, which can't possibly help any of these situations. It doesn't
matter whether I'm on my home desktop, my N800 on WiFi, or a school
machine on a very fast network, it always takes forever for pages on
the maemo site to be served, and frequently it times out first. Even
when pages do load, frequently there are elements missing. If the
repositories are similarly affected, that could create havoc with
anyone trying to update them.

Mark

lakestevensdental wrote:
> As it is, App Manager seems a rather crude work in progress that
> displays the crudest information during the updating process -- it
> doesn't even say what repository catalog is being updated during the
> update process.

Some weeks ago, my App Manager (OS2007, N800) suddenly started to tell
me it was "unable to refresh the list" when I clicked on Check for
Updates. It rapidly downloaded something and then said "Unable to
refresh list. Last refreshed list is shown."

It's the kind of error that sounds like a permissions or space problem
(although I have loads of space and I've never been anywhere near any
permissions -- that I'm aware of).

Unfortunately, it doesn't say what list it was trying to update, or
where it is, or why it had a problem with it, so I have no way to
conduct a further diagnosis.

Until this point, it was all working fine, and all installs and upgrades
functioned as expected. Even now, I installed the Mauku Twitter client
OK, after clicking through assorted error message about not being able
to update and refresh things.

Has anyone any idea where to start?

///Peter

Mark wrote:
> I also have to point out that the maemo site is always incredibly
> slow, which can't possibly help any of these situations. It doesn't
> matter whether I'm on my home desktop, my N800 on WiFi, or a school
> machine on a very fast network, it always takes forever for pages on
> the maemo site to be served, and frequently it times out first. Even
> when pages do load, frequently there are elements missing. If the
> repositories are similarly affected, that could create havoc with
> anyone trying to update them.

I must admit I don't have this problem, either at home or at work.

///Peter

Mark wrote:
> I also have to point out that the maemo site is always incredibly
> slow, which can't possibly help any of these situations. It doesn't
> matter whether I'm on my home desktop, my N800 on WiFi, or a school
> machine on a very fast network, it always takes forever for pages on
> the maemo site to be served, and frequently it times out first. Even
> when pages do load, frequently there are elements missing. If the
> repositories are similarly affected, that could create havoc with
> anyone trying to update them.
Ditto on the observation of poor Maemo server speed.

There's the likely reality that the most common device accessing the
Maemo site is an internet tablet, which has a modestly limited speed of
browsing and downloading compared to the average box. 1000 internet
tablets accessing a site are probably are the equivalent load of perhaps
3000 or more regular machines on reasonably equal internet lines. It
would be nice if the tablet came with a user installable speed
upgrade... The ASUS eee and netbooks in general have gone from .6 to
1.6Gs, while internet tablets poke along at .4G. Fast a couple years
ago, slow now.

Plus, everyone gets a nice blinking screen icon when there's an repo
update to download, which drives a lot of folks to do downloads around
the same time period, bogging the system down...

The server stuff would seem to be relatively fixable with mirror sites
and larger server pipes... If there's the will to upgrade to improve
service.