Has ZSI died?

[zaphod]

Or is Zaurus development just slowing down? Perhaps due to the start of a new school year?  Whenever ZSI doesn't change for a long time I worry that the Z is headed for silicon heaven, like the collectable Agenda VR and the stillborn Yopy.  

[dhns]

I also wondered. The backlog is growing and growing. I would assume that the maintainer is in vacation.

I remember there was already some discussion about moving/integrating ZSI/Killefiz into ZUG and some ideas how to improve its operation.

Offroadgeek was in contact with someone wo wanted to do the programming.

One issue to be solved (and which seems to be the reason why there are no updates): such a database needs active quality management, i.e. someone who verifies all changes and approves them. That needs one (or several) trusted volunteers.

-- hns

[omro]

I think incorporating it into the ZUG would be a great idea, you'd also be able to say if the apps were for opie or gpe or platform independent, which ZSI doesn't do.

Also there seems to be a ton of really old, dead links on the ZSI and apps which just aren't worth the effort anymore, so perhaps a usefulness rating from people who've used it would be an idea.

Just a thought.

[dz]

That was me that org was in contact with.  I'm still interested in doing it, even if not to integrate it with the zug, but perhaps just to create a brand new ZSI that's more automated.  That way even if the owner does go away on vacation, people can still update.

If you guys would like, I can start building this.  The only thing we'd need are the owners of the other programs to resubmit their programs.

[dz]

well, my ride to go home for the week has been delayed several hours, so i took it upon myself to just start building a new zsi..  these is what i intend to have, and any input is appreciated:

:: if org wouldn't mind, i would like to incorporate the login on the zsi with the login in the zug..  so that way you wouldn't need two different accounts, and if you uploaded a file in the zsi, it's linked to your account here in the zug.  as well, any subscriptions you have in the zsi, when the project is updated, you get a message here in the zug.

:: when you upload a file, you set these options:
- name
- description
- zaurus model
- which platform they're built for
- what resolution it's meant for

i'd really like to follow the model that freshmeat.net uses.  i think it's excellent how they have their site layed out.  there's only one thing i'm not sure of yet, which i'd like some input on.

should i have the files hosted onsite, or have the files linked?  i have no problem having them hosted on site, but i'd imagine that would fill up and eat tons of bandwidth, and i'm just a college kid so i don't really have the money to pay for all the extra bandwidth.  i could have the files linked to, but as you can see with the current zsi, they can die off quick.

regardless, i'm going to start building the zsi.  if the current zsi comes back on again, than we'll be good.  if not, than we have a backup plan.

[dz]

Ok, after some consideration, I think I've decided that it might be best not to link the accounts here in the ZUG to those of the ZSI.  It creates a central point for all the accounts, so if the ZUG were to randomly go down, then the ZSI will go down and that'd be a mess.

Also, for uploading a file, you also have the option of choosing which license you want.

[offroadgeek]

dz - this souds like as good a time as any to start that project we had spoken about many months ago.

first off, I'll create a forum for this project, so that it doesn't dirupt the other forums (and I'll move this thread there).

i totally agree with the freshmeat model, though I think there could be sections on the main page (list of 15 - 20 recently added apps, list of new projects, etc.)

I haven't thought much about the linked user tables... to see if there would be any benefit.  I'll post back on this.

I would really like to have this automatically update the zug feed (www.zaurususergroup.com/feed), honestly I'm pretty tired of updating it manually.

I think we should host the files locally.  too many of the links on zsi are broken.  we could also host multiple versions (some don't want the newest version, for various reasons)

also, I would be happy to host it.  I'm already paying a pretty penny for bandwidth, why not get good use out of it.  I'm working on setting up the zug as a non-profit organization.  That way we can get donations from companies, etc. to better our community and our sister communities (OE, etc.)

so many thoughts, so little food in my stomach  

offroadgeek

[dz]

Excellent.  Since you will provide the hosting, than that solves the main issue.  Hosting the files on-site is the way to go then.

As far as updating the feed, I don't see why that'd be an issue.  I can add that.

Same goes with multiple versions.  When they add a file, I'll request a version # and the unixname.  That way, the filename will be unixname-version.ipk.  Now you can have multiple versions.

I'll start working on it this week, and I'll report in on my progress.  Meanwhile, if you can think up any ideas, let me know.

Roy

[luimarma]

By the way, noticed that today ZSI database has gone down!!!

[lardman]

:: when you upload a file, you set these options:
- name
- description
- zaurus model
- which platform they're built for
- what resolution it's meant for

A couple of thoughts:

Zaurus model -> the software is more dependant on the ROM than the model (bar the instruction set with which it is compiled. Perhaps saying whether it's ARM4 or ARM5 (or ARM6...etc.) would be a better way to go for this).

Which platform -> What happens when a new version of a ROM comes out? Some stuff might still run, other stuff might not. This would require that each entry be re-checked against the new ROM (and the db would have to be changed/amended to accept the new ROM as an option in the future).

I'm not sure of a way around this; my initial thought was to state the version of libc, state the dependencies (which are required by the control file anyway so they should be easy to add in), then match this against the known libs in various ROMs. The problem with this is that, for example, a pdaXrom 1.0.5 app won't run on pdaXrom 1.1.0 even though the libs are the same afaik. Any thoughts?

I'd be tempted to also make people name their ipks better, before they can submit them (there have been a few threads about this -> adding arm4 or whatever to the name); something else to think about ;-)


Si

[dhns]

  i could have the files linked to, but as you can see with the current zsi, they can die off quick.

Just an idea because storing the files on the ZSI system is something I would not really recommend...

If the ownership is linked to ZUG, you have a great connection if a link dies. And if a link is still valid can be checked e.g. every week by the ZSI system or if someone tries to download.

And if there is no login/response to ZUG in that case within e.g. 4 weeks, the program/link is made invisible

-- hns

[dhns]

I think we should host the files locally.  too many of the links on zsi are broken.  we could also host multiple versions (some don't want the newest version, for various reasons)

Or make it an option. If someone provides a link to his own server (e.g. for making his own download-statistics) - fine. If that link goes down, the program is removed. So, users can choose what they prefer.

[dhns]

Zaurus model -> the software is more dependant on the ROM than the model (bar the instruction set with which it is compiled. Perhaps saying whether it's ARM4 or ARM5 (or ARM6...etc.) would be a better way to go for this).

Which platform -> What happens when a new version of a ROM comes out? Some stuff might still run, other stuff might not. This would require that each entry be re-checked against the new ROM (and the db would have to be changed/amended to accept the new ROM as an option in the future).

I'm not sure of a way around this; my initial thought was to state the version of libc, state the dependencies (which are required by the control file anyway so they should be easy to ...

Hm,
we should keep the scheme on one hand user-friendly (although a developer, I don't know/care which ARM version my Zaurus has and which libc it is using but I know the Zaurus model(s) and the ROM(s) I have tested with) and on the other flexible/expandable.
In my view VersionTracker.com does a pretty good job on that. You can select the main platform (Windows, MacOS 9, MacOS X) and then you have a field where you can specify additional requirements (e.g. OS version, other packages being installed, ...).
Regarding the package naming, there should be a simple yet flexible scheme enforced by the system (and the .ipk being added automatically). And it shouls on one hand enforce uniqueness of the packages (i.e. derive the package name from the program name in a Wiki-like manner: "My This and That-Application" -> MyThisAndThatApplication-SL5500-1.0.5_arm.ipk)

-- hns

[lardman]

MyThisAndThatApplication-SL5500-1.0.5_arm.ipk

Hmm....

But with this naming scheme I could create:

an OZ3.3.6pre1 package which won't run on any other ROM (but will run on all machines running this ROM);

a GPE which is the same as above, but won't run on OZ3.3.6pre1 images with Opie as the GUI;

an OZ3.2 package which will run on other OZ versions (with compat libs), won't run on any other ROM;

a Sharp 2.38 package which will run on anything (but will need compat libs for OZ>=3.3.6pre1).

Also note that there are extra dependencies - for example the Sharp ROMs all need libncurses.so.5 for many command line programs, whereas Cacko has it built in (I think) and is otherwise the same.

Another thing is that the OZ packages will use ar rather than tar.gz so they won't even install on Sharp ROMs.


My suggstion would be to say:- libc version, packaging type (or say whether it's a Sharp/OZ/pdaXrom based ROM), screen size, then specific ROM. However lots of people wouldn't know that a command line app for OZ3.2 will also run on the Sharp ROMs without any issues (bar the packaging and possibly extra libs).


Si

[lardman]

Here's the discussion from zaurus.com:

http://www.zaurus.com/dev/board/index.php?...ic=2968&hl=arm5

Might be worth bringing some of this over before zaurus.com goes down for good.


Si