OESF Portables Forum
Everything Else => Embedded Linux Hardware / Software Index => Everything Else => Archived Forums => ELSI General Discussion => Topic started by: zaphod on September 19, 2004, 02:17:23 am
-
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.
-
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
-
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.
-
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.
-
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.
-
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.
-
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
-
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
-
By the way, noticed that today ZSI database has gone down!!!
-
:: 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
-
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
-
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.
-
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
-
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
-
Here's the discussion from zaurus.com:
http://www.zaurus.com/dev/board/index.php?...ic=2968&hl=arm5 (http://www.zaurus.com/dev/board/index.php?showtopic=2968&hl=arm5)
Might be worth bringing some of this over before zaurus.com goes down for good.
Si
-
And here the thread from April on integrating Killefiz/ZSI into ZUG.
https://www.oesf.org/forums/inde...732&hl=killefiz (https://www.oesf.org/forums/index.php?showtopic=3732&hl=killefiz)
There, I had made some proposals. DZ, could you please have a look there?
And an other idea: I think as soon as the new database is running, it could be possible to copy some entries from ZSI to the new one. Maybe, the Killefiz author is even willing to provide his database table scheme for extension.
And one more. Can the new database be made "open source" (on Freshmeat :-) )? It will probably be written in PHP and MySQL - so there would be some developers here who would be interested in downloading and trying out pre-releases on a local host. And probably providing patches. Just an idea where I think DZ must decide if he needs that type of development support (which can slow down development of simple applications but speed up complex ones).
-- hns
-
Ahh, it's good to see community support for this. Ok, if I may answer some questions now:
As far as integrating into the ZUG, I think it'd be ok to integrate a little bit, but not too much. Like I said before, having one central point of failure is never good. One thing I was thinking of though, for example, would be that if you are subscribed to any projects in the ZSI and that project is updated, it'll automatically message your account here on the ZUG and let you know. You simply set in the options of the ZSI your ZUG username and it'll do the rest.
Editing screenshots: that's not a problem.
As far as comments, that was already definately in the pile. User comments definately help when you're trying to choose between a bunch of different programs, so I had already thought of adding those. I never thought of ratings though. Are they actually used? If you guys would actually use them, I have no problem adding them in. To prevent abuse, I'd obviously make it so you have to have an account to vote for a project. An idea I though might work is maybe letting you vote for a project only if you comment on it. Let me know what you guys think of this.
As far as making the zsi open source, I dont see why that would be a problem at all. If you don't mind, I'd like to get a somewhat functional version first and up and running, and then I'll provide it to the world. It's just a lot easier to get something up and running on your own, and have people come in eventually rather than having everyone start it up at the same time.
And finally, the naming conventions. I read the devnet post, and they make a lot of valid points. I'm going to try and save the naming of the file for last, because I think we should all agree on a standard before we implement it. The one I liked most is this one:
<app-name>-<major>.<minor>.<rev>-<build><rom>-<proc>.ipk
I think that includes most everything you need in the filename. Remember, the programs will have their own page where they will be able to list any dependencies they might have, so it doesn't all need to show in the filename. As well, debate this and let me know what you guys think.
If anyone else made any points and I missed them, sorry about that. I started some of the coding last night, and I'll work on it some more tonight. I made sure the whole site will fit in 640x480, for those of us that have the clamshells. I'm also going to try, eventually, to make a version that fits in 320x240 for the zaurus owners with that size screen.
As usual, let me know any ideas you come up with.
Roy
-
With regards to ROM/model compatibility, perhaps there could be an entry for the developer to say what it has been tested with and then when users are giving comments/ratings they can say what ROM/model they are using and the results can be summarised.
It would be good if a list of models and ROMs could be maintained so that developers and users are given a drop down list of ROMs/models to select from for this, instead of a free text box. Then the data would be much more consistent and people could do searches on software that is known to work on their Zaurus model and/or ROM.
-
perhaps there could be an entry for the developer to say what it has been tested with and then when users are giving comments/ratings they can say what ROM/model they are using and the results can be summarised.
It might be good to have a separate section (away from the general comments - "yeah it's great"; "no it's crap", etc.) where the users can say what hardware & ROM they are using and what they had to do to get it to work - that way people won't have to trawl through the comments to work out how to get stuff working on their ROM. Can this be wiki style, as people often make typos, or forget exactly what they had to do and write these things from memory?
Si
-
I like the idea of having to enter what Zaurus / Rom you are using when you enter your comments. I can just have a 'statistics' link at the top of the page where it will break down what models and whatnot have used the program.
Here's a different scenario though: People have been saying I should make it a repository for all kinds of Embedded Applications; not just a Zaurus. Any objections to that, or should I just stick to the Zaurus?
-
As far as allowing developers host their own files I'm not real keen about that.
My biggest reason being if the link gets broke temp or permenently a great piece of software could be lost forever.
This whole idea is great and despiratly needed. IF you need an hand in anything just shout.
Jim
-
Here's a different scenario though: People have been saying I should make it a repository for all kinds of Embedded Applications; not just a Zaurus. Any objections to that, or should I just stick to the Zaurus?
Personally, I'm only interested in a zaurus software repository. In general, I think the overall embedded software repository is a neat idea (this is exactly what Sven, who runs the current zsi was planning on doing), but the scope of that and the eventual cost of supporting this might be more than I can commit to for now.
This narrow mindedness of mine might be due to my general lack of knowledge of the overall embedded space.
-
Have you had a look at http://www.zaurusoft.com/ (http://www.zaurusoft.com/) ? I thought they used to host their own files while the creating company still funded them.
Anyway, I can perfectly understand offroadgeek only wanting to host Zaurus stuff on his home SDSL connection. But how about automatic bittorrent links for all packages over 1MB? I guess the biggest problem with this is most ipks are under 1MB and I don't know how effective bittorrent is with small files since the server has to seed each download with a small chunk to begin with.
-
Best system I've ever used is Aminet (http://ftp.uni-paderborn.de/aminet/), the Amiga software collection. All files are stored on FTP. Submissions are not accepted unless they have an accompanying .readme file that conforms to the template. There are many mirrors, it's very easy to search. It's very much in the KISS (keep it simple, stupid) mentality of design. CDs used to be sold containing the latest submissions.
A version of Aminet for the Zaurus would be ideal. It is a great system.
-
How about a subscription fee to download the files? If Every Zaurus/Linux embedded handheld user subscribed and paid, say 5 dollars (using american cause that's a global currency too) a year, to download as many ipk files as they wanted in that year, wouldn't that theoretically pay for hosting?
5 dollars a year is a pretty minimal investment to make. Any excess could go into open source projects like OE/OZ etc.
Just an idea.
-
Is this still progressing.
Not downloaded/played with much "New" software of late...
-
Is what still progressing?
Work on the ZSI2, or programming for the Zaurus?
-
ZSI seems to have been updated on 11th October - still a lot of stuff in the back end though.
Charlie
-
Hi, I know that you have a which 'platform' category, however, in the case of PDAXROM RC5 all the new stuff that has floating point requires some very specific Kernel functionality to run at all.
I would suggest that we encourage applications posted at least for X distribution to have a direct link to a source file tarball too so that people using XQT or GPE stand a fair chance of getting them up for their systems too.
-
I was referring to updated list of Zaurus apps.
But since ZSI has been updated with a few entries, hopefully, it will be getting back on track as well...
-
<app-name>-<major>.<minor>.<rev>-<build><rom>-<proc>.ipk
I don't think that'll work well, personally...
It's probably better to stick with the current standard <app-name>_<version>_arm.ipk, as the package manager on the Sharp-based ROMs like that naming convention.
Also what if something works on more than one ROM? Long IPK name in that case...
Why not just another file in the control.tar.gz? Something like "compat", and come up with a standard format to look at that file and have all the stats listed.
i.e.
Package Name: foo
Models: SL-5600 (Poodle)
ROMs: Sharp ROM (and compatible)
Processor: ARM5 (Xscale)
Package name just there to make sure it matches the control file's name. Of course it'd probably have more data than just that, but hey, it's just an example.