Finalizing ArchStats

farphel · 2004-01-07 21:33:33

Hi All,

Thanks to everyone for helping during the beta testing. The final home will be 'archstats.coding-zone.com' (once I set up a vhost for it) and will update the client accordingly. The client will be packaged up and hopefully added to the 'extra' repository for the final release as well.

However, as the poll indicates, I'm looking for feedback now about the client. The original proof-of-concept code was written in python, but I also have a fully functional statically linked client re-written in C. Both clients support the same features/command-line arguments. Here's a list of pros/cons as I see it - please feel free to chime in with other thoughts too.

python client
(+) easier to review client code so users feel more confortable with it.
(+) easier to maintain
(-) has a chain of package dependencies (python - tk - X11)
(-) slower than the C client

C client
(-) harder for users to review the code
(-) harder to maintain
(+) no package dependencies - users would only add the 'archstats' package to particpate
(+) faster than the python client
(-) size of executable - it's statically linked and weighs in at about 1.3M

The C client could be dynamically linked, but then it would have package dependencies for 'mhash', 'curl', and 'zlib'.

So please cast your vote. Backing up your opinion with a post is most appreciated!

NOTE: I know that there are users/developers that do not feel that this project will be useful to AL, however, there are users/developers that believe otherwise. Feel free to post your opinions (of course!), but I'm not going to try and defend the project anymore - so please don't complain about a missing poll option for "scrap it completely"

farphel · 2004-01-07 21:37:09

I'll cast my vote too.

I picked the statically compiled C client. My reason is that I don't like to install software on my systems that I don't use/need. IMHO, if a user wants to participate in ArchStats, they shouldn't be required to install ~15M of software (python, tk, X, etc.) to use it. That same argument holds for the dynamically linked C client too.

However, I'm not 100% sure. The whole privacy/security thing is a big concern and I want users to feel comfortable running code that examines their system and uploads data to a remote server. Even if you're not a programmer, it's much easier to read python code than C code!

What do the rest of you think?

nifan · 2004-01-07 22:04:23

i voted for the c - staticly linked.
the reasons you alredy pointed them , the dependecies issue is important since maybe someone that dont need to use X would go away to never come back. keep up the good work

Arielext · 2004-01-07 22:18:53

staticly linked

If curl is updated and breaks the with an older version you have to recompile and maybe recode parts of the code. Having it staticly solves this, so the users just have to download one simple package

And what is 1.3MB ?? it's just one of those old 3½" discs

contrasutra · 2004-01-08 00:11:23

Are you fixing the kernel version problem?

I voted Python, but just because I like it, no real technical reason.

farphel · 2004-01-08 01:47:20

contrasutra wrote:

Are you fixing the kernel version problem?

The bug that contrasutra is referring to is the sorting of kernel versions on the stats page. The sorting is plain alphanumeric right now and that fails when there are kernel versions containing patches/etc.

For example, if the following kernel versions were submitted:

2.6.0-test11
2.4.22
2.6.0-test2
2.6.0
2.4.24

Currently, they would get sorted least to greatest as:

2.4.22
2.4.24
2.6.0
2.6.0-test11
2.6.0-test2

But the correct order, least to greatest would be:

2.4.22
2.4.24
2.6.0-test2
2.6.0-test11
2.6.0
2.6.0-mm3

Basically, I don't know how to fix it without having to try and special case each EXTRAVERSION text and list them in the "proper" order. If I go that approach, who's to say that the -mm patch takes precedence over the -ck or -ac EXTRAVERSIONS? What if someone compiles their own kernel and adds their own EXTRAVERSION?

Any suggestions?

Arch Linux

#1 2004-01-07 21:33:33

Finalizing ArchStats

#2 2004-01-07 21:37:09

Re: Finalizing ArchStats

#3 2004-01-07 22:04:23

Re: Finalizing ArchStats

#4 2004-01-07 22:18:53

Re: Finalizing ArchStats

#5 2004-01-08 00:11:23

Re: Finalizing ArchStats

#6 2004-01-08 01:47:20

Re: Finalizing ArchStats

Board footer