klik: point-and-klik software store for Knoppix

Printable View

Show 40 post(s) from this thread on one page

01-29-2004, 12:16 PM
gowator

WOW

This is happening so fast.....

Just a general question from a user perspective as someone coming from the RPM world :D

Am I the only one who finds the shere numbers of deb packages confusing....
Im all for choice, its just the organisation of the packages isn't all that logical from a user perspective....

I have to admit, click n run solves this by the addition the 'aisles' which looking at klik shouldn't be a problem to implement.

Even for me with years of Linux experience and hence knowing more or less what I want its hard to find official debs classified and I rely on pre-knowledge of the package name and the good ole CLI....

What would be really cool are user reviews of the klik packages,
i.e. say you have a 'aisle' email servers then 30 choices a short user experience is a good thing. i.e. qmail-run or qmail or compile from source??? and thats just a single mail server??? - The user perspective on how this is better or worse than sendmail or postfix is important, it might only be the fact that its easier to configure in webmin or it could be it handles >1000 simultaneous users better....

the klik could then have a link to the klik recipee for webmin-qmail (very cool)

The next difficult part is the 'real install' as opposed to the user install in ~. Although the present apps can all be run from ~ not everything can, from servers to themes!!!!

I have a bee in my bonnet about distro's that modify the intended location of files (like KDE) and hence break everything else.

Next question is how to update the apt database with the fact this is installed ??? Again this rests on user/root install.

Obviously connecting and installing as root is a bit silly, so perhaps the klik should install an icon on the desktop which will then sudo to root for an install?

This then means or pre-supposed that a single desktop would need to be run for it to work, fairly obviously KDE at the moment.

This is IMHO tied in with the deps problem,
If the database can't resolve deps or apt comes back with a choice ... or in early stages if that deb isn't yet available in klik!!!!

I have every faith these are surmountable, but I thought better to bring it up now than later!!!
01-29-2004, 07:17 PM
probono

There is now a details page for each app with a screenshot, user comments, and the possibility to see the recipe.

http://klik.berlios.de/
01-29-2004, 08:36 PM
probono

Re: WOW

Quote:

Originally Posted by gowator

Am I the only one who finds the shere numbers of deb packages confusing....
Im all for choice, its just the organisation of the packages isn't all that logical from a user perspective....

That's why the end user will never see any .deb packages if he uses klik. the klik recipes do all that magic stuff in the background. One klik link can, and in fact often does, download several .deb packages, or even .rpm or .tar.gz or whatever.

Quote:

Originally Posted by gowator

I have to admit, click n run solves this by the addition the 'aisles' which looking at klik shouldn't be a problem to implement.

That can be implemented absolutely easily, true. However, we should first try to categorize the software, perhaps using the TROVE software map that was suggested earlier.

Quote:

Originally Posted by gowator

What would be really cool are user reviews of the klik packages

Hey, just that was my priority for today :)

Quote:

Originally Posted by gowator

i.e. say you have a 'aisle' email servers then 30 choices a short user experience is a good thing. i.e. qmail-run or qmail or compile from source??? and thats just a single mail server??? - The user perspective on how this is better or worse than sendmail or postfix is important, it might only be the fact that its easier to configure in webmin or it could be it handles >1000 simultaneous users better....

For the typical klik user, KMail will be just fine ;) qmail compile from source... come on ;)

Quote:

Originally Posted by gowator

The next difficult part is the 'real install' as opposed to the user install in ~. Although the present apps can all be run from ~ not everything can, from servers to themes!!!!

We hope to make just that possible by patching the binaries. Remember, klik is designed to run with live cds. Situation might change with the availability of an overlay fs in Knoppix. But personally I prefer AppFolders... you simply cannot destroy anything on your system using AppFolders. That's great news for all the folks who don't want to fiddle around with "broken packages", "missing libraries" and alike.

Quote:

Originally Posted by gowator

I have a bee in my bonnet about distro's that modify the intended location of files (like KDE) and hence break everything else.

klik will break nothing because it all rests in ~/AppFolder. There are no dependencies allowed between AppFolders, otherwise all the mess would begin again. Each AppFolder has to be "self-contained".

Quote:

Originally Posted by gowator

Next question is how to update the apt database with the fact this is installed ??? Again this rests on user/root install.

klik is completely independent from the apt database. the apt database will not see apps installed through klik, and this is by design. The typical dialup Knoppix user running from CD does not really understand, want or need the apt database.

Quote:

Originally Posted by gowator

Obviously connecting and installing as root is a bit silly, so perhaps the klik should install an icon on the desktop which will then sudo to root for an install?

Why do you want to install as root? klik works completely in userland. klik needs *no* root provileges to install software since it installs everything in the user's home directory. (That way, every user can install what she wants on a multiuser setup.)

Quote:

Originally Posted by gowator

If the database can't resolve deps or apt comes back with a choice ... or in early stages if that deb isn't yet available in klik!!!!

That is also a reason why klik doesn't use the apt database. (The developer of a klik recipe can do so, however, in order to find out which packages his recipe needs to install.)

I hope I could clear up things a bit for you. klik is not designed to install a base system but just to install what is missing for some people on a live CD.
01-29-2004, 09:12 PM
aay

probono,

where do we submit our recipies?
01-29-2004, 10:53 PM
probono

Quote:

Originally Posted by aay

probono,

where do we submit our recipies?

here: http://klik.berlios.de/?contribute=recipe
01-30-2004, 05:31 AM
skyfaller

Please try to avoid KDE dependency

Although I am a happy KDE user, I would also appreciate it if Klik didn't require KDE to work, because as Fabian said it's great how Knoppix can be remastered with different window managers, and there's no reason to leave distros such as Gnoppix out in the cold. I can understand if you personally are more comfortable with KDE stuff, but hopefully others from the community (such as Fabian) will step up to help you out. I would if I could, but I'm just a teenage noob :-D
01-30-2004, 05:52 AM
probono

Re: Please try to avoid KDE dependency

Quote:

Originally Posted by skyfaller

there's no reason to leave distros such as Gnoppix out in the cold

Apps installed through klik are dependent of the underlying applications and libraries(!) that are available on Knoppix. Each klik recipe is built for a specific version of Knoppix. So if anyone would like to run app X on Gnoppix, he would need to make a specific Gnoppixified version of the klik recipe. I myself will go with mainstream Knoppix for now. Remember, this whole project is just a few hours old. It is my priority now to get things rolling so that people can contribute klik recipes. Should there be many people wanting to write klik recipes for Gnoppix, I sure would listen to them at a later point in time.
01-31-2004, 12:12 AM
bfree

Re: Please try to avoid KDE dependency

Quote:

Originally Posted by probono

Apps installed through klik are dependent of the underlying applications and libraries(!) that are available on Knoppix. Each klik recipe is built for a specific version of Knoppix.

The question is what about people running Knoppix on systems with minimal amounts of ram and hence not using KDE? Is there a real reason (i.e. not a factor of implementation and the youth of the project) why kilk isn't accessable from lynx in run-level 2? Now I realise I am pushing the boat out even further than others here, and perhaps I am missing something. What if someone wants to use klik to install software to get an otherwise unsupported video card up and running? Is their any technical reason why klik itself must depend on much more than a browser?

I hope the above doesn't read in any way negatively because it is not my intention in the slightest! I am just trying to point out another potential way it could be used. Also I appreciate that this is an incredibly young project, congratulations on making such a big splash, you deserve it and I hope you get the assistance required to make this work (i.e. to get recipies updated for new releases in a reasonable timeframe)!
01-31-2004, 01:34 AM
probono

Infrared + Pocket PC PDA

The list of apps is growing... now I can sync my Pocket PC with Knoppix on my notebook via infrared... But since I have no other hardware to play with, I need your help on making this work more generally.
01-31-2004, 01:34 AM
probono

Re: Please try to avoid KDE dependency

Quote:

Originally Posted by bfree

Is there a real reason (i.e. not a factor of implementation and the youth of the project) why kilk isn't accessable from lynx in run-level 2?

No.

But a klik so downstripped that would be accessible in run-level 2 would be simply called a "shell script", and it wouldn't give the "user experience" most people, including myself, like.

Show 40 post(s) from this thread on one page