The future of klik: GPL

[probono]

Update: klik is going GPL (dual license like qt), see next page

I have opened this thread to discuss the future of klik. Thanks to all of you who share your ideas on how klik can be made a killer app.

Before we start discussion, let me share some of my personal views about klik:

* Knoppix (or any other system) is the "base", klik is for supplying (relatively small) add-ons.
This means that klik is not designed as a "package manager" that could or should replace apt. Instead, klik is designed to be the easiest way for the user to add, let's say, RealPlayer (which will not be a part of debian anytime soon). Klik is designed for the dialup user who just wants to download the minimum of what he really needs instead of MBs of apt package descriptions. This also means that each klik recipe will be built for a specific version of Knoppix (or any other system) and is unlikely to run on (very) others. klik shifts the task of "package management" away from the user towards the developer of the klik recipe.

* Each klik recipe installs one "self-contained" application (or set of apps).
This means there will never be "dependencies" between klik packages. klik doesn't *want* to have dependencies. The user should always be free to delete an AppFolder without having to fear that this could break anything else. klik is designed for people to try out many new apps just for fun and then decide whether to keep them or not. In cases where several apps share many common parts (e. g. libraries), these packages should be built into one klik recipe (e. g. mplayer, mencoder, kplayer, kmplayer, kmediagrab could well be in *one* klik recipe).

* klik recipes use server-side PHP includes.
This makes it easy to upgrade code that is common to many klik recipes. Ideally, we would have just one "generic" klik code for a certain type of app (e. g. KDE, Gnome, Wine, Konsole apps). Then making each recipe would be quite easy, as it is today already for KDE apps.

* klik should use, but not require deb meta information.
deb packages contain a lot of useful information (e. g. menu entries, postinstall scripts) that could be used by the klik recipes. However, klik should never be dependent on the deb format, but instead also allow for other packages (e. g. RPMs) to be used. Sometimes, there are no deb packages for a certain app which nonetheless runs fine in Knoppix.

* klik should allow the easy integration of non-free apps.
It is a matter of fact that many users want an easy way to add non-free apps to their desktops. klik should allow for that to happen in a legitimate way. Since klik scripts can download packages from the commercial vendors' servers directly, licensing should not be a problem. klik recipes don't "redistribute" software, they simply tell the client where to obtain and how to unpack packages. (*If* this is in contrast to debian philosophy, klik cannot be integrated into debian. Sorry.)

* klik should have *one* central store that is open to all.
What is the greatest pro of sites such as kde-apps.org? Well, it is that they show all the KDE apps in *one* place. I go there, and I know what exists. All sorted in convenient ways. Wouldn't it be even greater if there was a place like kde-apps where I knew each app I see could be installed on *my* system hassle-free with just one klik? Of course this would be much nicer than having to seek for apps in many different places as it is today. Because of that, we should try our best not to have multiple klik stores but *one* store that would have to be open for all. "Open" means that everyone can use and upload klik recipes BUT there must be some sort of quality control built in. Since klik recipes run on the user's machine, they are potentially dangerous. So I envision a klik store that works similar to shalshdot: Everyone can post klik recipes (and improvements) like in a web forum, but they become klikable only after a moderator has "modded them up".

* The klik store should have a system for users to report their success on different (standardized) systems in an easy way. After each klik installation, there could be a screen in the klik client that asks "worked" or "did not work". THe klik client could submit this information, together with the information about the system it is running on, to the klik store's database. That way, people could easily see "runs with Knoppix 3.3 19-11-2003".

* klik recipes could be autogenerated on the server.
Using apt-get server-side, it should even be possible to auto-generate klik recipes server-side for at least some classes of apps, ot at least minimizing the klik recipe developer's effort through "wizards". It should always be possible, however, to hand-write recipes.

* the klik client source should not be open to everyone.
Otherwise, generations of hackers and dialer programmers could use slightly modified versions of the klik client to do their evil thing. I do not want to help them by providing them with the code of the klik client. No question, every hacker could write a klik client like program on their own, but giving it to them openly would allow every "script kid" to do evil things with it. Therefore, I suggest making everything GPL except for the klik client, which would be released as closed-source freeware. People with a long tradition in open source development would get the source code for inspection, but not the general public. Again, this is just to prevent KDE from becoming a platform for dialers and stuff.

* klik allows for easy "software URLs".
What can you remember better - klik:/RealPlayer8 or http://www.mygreatserver.com/downloads/software/players/realplayer/installation/8/rp.gz?

These are my personal thoughts. They are not the only way to to klik, but they are how I envisioned klik when I created it. Some people think klik has the potential to make a huge impact for Linux on the desktop. Sure enough, I am unable to actually build all of this on my own. The future of klik is really what you - the GNU/Linux, debian, KDE, Knoppix, ... community - make of it. I will sure do what I can, but I cannot do it all alone.[/b]

[Vick]

Your are starting in a bad move... you know (win win) or (lose lose) or (win lose) deals. Well your are doing a lose lose project, by starting with a closed or semi closed project that shud not be open to all, that is very bad news for all us knoppix dev and users, the place for a project the way you want it to be, is not the good place for it here.

I told you already make a win win move, make it GPL, and start focusing global with knoppix.

If you are to make it non gpl, then go away with your crap far from us, its insulting the community.

On what i'm starting to see you're are not a winner, from now you are profiting from innocent contributers.

I dont know why people dont open there eyes and stop contributing to scrips or programs that are mining or future and closing it bite by bite. Please stop!, stop! and open your eyes.

It is still time to change your plans dont be blinded by false illusionist (Mirage).

The future is open, the future is freedom, the future is us the open source community and dont forget that.

PS: dont forget that all the code you are using come from the open source, you can use it because it's gpl.

What you done is not an innovation, it already exist and used by stupid closed projects.

An innovation is sumting new, creating something out of nothing.

innovation :
1. The act of innovating; introduction of something new, in
customs, rites, etc.

2. A change effected by innovating; a change in customs;
something new, and contrary to ESTABLISHED customs,
manners, or rites.

You want innovation, then do it the gpl way and not like all others STUPID closed, restrictive rules.

[probono]

closed or semi closed project that shud not be open to all

klik *is* open to all! You can contribute recipes, see the recipes others have contributed, download the source code of the klik client, everything. If you are serious about contributing, you can even code the next generation klik store, just drop me a line.


I told you already make a win win move, make it GPL, and start focusing global with knoppix.

I know, and I am still considering it. But there is Open Source besides GPL, and you know that.


The future is open, the future is freedom, the future is us the open source community and dont forget that.

I belivee the same, that's why I did klik :)


What you done is not an innovation, it already exist and used by stupid closed projects.

So why do people want klik so badly then? Because it's *not* commercial, and because it's *open*. (To make it even more open, we need server-side infrastructure that is yet to be built, see my first post in this thread.)

Vick, I think we share the same ideal, but I am not sure which way works best in order to achieve it. What I want to create with klik is "the" open and free point-and-klik software store. This is not neccessarily about "technical innovation" but about "end user experience". I want to bring community effort into an area that is otherwise dominated by, well, companies.

[probono]

http://non-us.cdimage.debian.org/ (...) I would set this up for you on my server (which has > 160GB spare, and 100Mbit/s bandwidth)

Would you allow for GPLd Packages that are not in debain to be hosted on that server? That is essential. The problem is not for files that are already in debian, but for files that are not in debian yet but do exist as, let's say, rpm.


I don't really follow the comment about there being 1001 servers being a bad thing.

You can see this at debian itself: It is inconvenient for the (non-geek) end-user to search sites like www.apt-get.org in order to find essential software (such as decent multimedia players) that is not in "official" debian. One package here, another there, and tomorrow they are all gone or the upgrade breaks compatibility with the rest of my system. Here we can learn from Lindows with their less restrictive policy with regard to what debian purists call "non-free" software.


Why would it be bad for Debian to start adding Klik recipes to official packages

Wouldn't be "bad", but difficult to do and I suppose debian purists wouldn't allow it.


have both the klik repository, and the required snapshots be maintained at, for example http://klik.debian.org/

That would be fine with me, but I am not sure whether debian would allow klik to host recipes for stuff like RealPlayer and Flash even though the binaries wouln't be hosted there. Stuff like RealPlayer and Flash is exactly the reason why I saw a need for klik in the first place.

Where I see more possible synergies is a cooperation with sites like www.kde-apps.org - wouldn't it be awesome to have a klik button next to each app listed there?

[bfree]

That would be fine with me, but I am not sure whether debian would allow klik to host recipes for stuff like RealPlayer and Flash even though the binaries wouln't be hosted there. Stuff like RealPlayer and Flash is exactly the reason why I saw a need for klik in the first place.

Where I see more possible synergies is a cooperation with sites like www.kde-apps.org - wouldn't it be awesome to have a klik button next to each app listed there?

Debian has certainly had packages previously which installed external binary non-free software. A debian server won't be able to carry binary non-free data though (afaik) without a struggle (for example binary firmware in the kernel was looked at very seriously). They do already carry the flashplugin-nonfree package in contrib for testing and unstable.

I am however far more concerned about your desires to keep a part of klik itself non-free, the client. I don't think you have thought through some of the ramifications of that decision, and perhaps I can draw some to your attention.

If you have one non-free client, it must support all distributions and releases, not simply Knoppix or else the potential for kde-apps.org to link to you is greatly minimised.

By having a closed section you invite a re-implementation. This could either be that someone simply writes a free compatible client, or else that someone recreates the entire system. I can quickly conjure up half a dozen examples of where people would want their own klik. All this would delay the time before end users see a benefit from this (fractured work).

Some people will not contribute to the project as they fundamentally disagree with placing the control of their work under a non-free licence.

Security through obscurity is no security at all! If you want to protect end users from malicious software, then you should secure the client, not hide it's source! You could use cryptographic signing of the recipies (distro should include a key), include md5sums for all external data, layer the client so that it must remain unaltered as it fetches parts of itself which can in turn fetch further parts (of itself or the recipies).

Why are you suggesting that klik is so useful to hackers? What is special about klik as compared to ssh, wget, bash, perl, etherdump or kppp or ... ?

You have your own focus on klik (kde and knoppix) but others will have different ideas. By keeping the client closed you do not encourage everyone to join in and work on the system to improve it for all, but restrict your system to those who don't mind giving you their code because their exact target is the same as yours.

[probono]

Security through obscurity is no security at all! If you want to protect end users from malicious software, then you should secure the client, not hide it's source!

Well, in principle you are right. But in this case... the "bad guy" could just take my code, strip out all the security stuff and instead insert "bad stuff", and let people install his modified version. What could you do against that - nothing!

Believe me - I would like to make it GPL rather yesterday than tomorrow. Just - will history then bash me for bringing the "bad" to Linux?

I will watch what people are saying about this and if everyone is for GPL- well, then perhaps indeed we will go GPL real quick!


If you have one non-free client, it must support all distributions and releases, not simply Knoppix or else the potential for kde-apps.org to link to you is greatly minimised.

It's the recipes which are written for a specific underlying OS - anyone is free to write recipies for whatever distro he wants. klik works best with live CDs, though, since these have a known set of apps and libs preinstalled. Other systems can use "package managers". Because Knoppix is probably the world's favorite live CD, I personally focus on this, but klik itself isn't restricted on Knoppix.

[bfree]

It's the recipes which are written for a specific underlying OS - anyone is free to write recipies for whatever distro he wants. klik works best with live CDs, though, since these have a known set of apps and libs preinstalled. Other systems can use "package managers". Because Knoppix is probably the world's favorite live CD, I personally focus on this, but klik itself isn't restricted on Knoppix.

Does that mean the client has no dependencies and will work on any distro (e.g. mandrakemove)? If not klik is unlikely to ever be used beyond knoppix (if even there) as the client is not accessible.

Also, I still don't understand what is so special about klik that it needs to be "secured" like this? How is it different to provide the source to the kilk client then to provide the source to konqueror (or anything else really)? What is going to get people to install a modified "bad stuff" version in the first place? How is someone going to be tricked into installing a dodgy klik?

[mrclark1971]

...hey probono...

First, I want to say that I am new to the Linux community. I am not a true, blue linux newbie anymore but I haven't exactly graduated to the next level yet either... :)

Second, I applaud your work with what you and the others have done with klik. I have been wanting to see something like this for a while.

Third, I will put in my two cents worth on why you should place all of klik under the GPL.

(A) [You didn't get here by yourself] Linus and all the Linux programmers, Klaus and the Knoppix community (which you are an important part of...), and the rest of the Linux community have placed millions of lines of code and thousands of programs under the GPL. They thought it was important to do so because they are part of the community. That is the philosophy and spirit of the community. I hope you will make that same decision. Remember the community wants to help you with klik...they are excited about klikk! Please don't smear your own important contributions by trying to hold your code back now.

(B) [You won't achieve your contributions full potential by yourself] If you do choose to keep it closed, then you will fracture some others away from you. By doing that, klik will never achieve it's full potential. Linux is like a raging wildfire just because of it's "openness." I hope that you see that (even though you will be the maintainer of klik) it's about "all of us."

(C) [Don't be like Darl... :twisted: ] Darl, from SCO, is using the same argument in front of Congress right now that you show in your list of concerns. Darl says that Linux, because of the open source model, is a danger to national security. He spews other things as well that you can read on www.groklaw.net at your own pleasure. Despite what Darl says, Linux remains secure. I hope you will not use this as your argument against going under the GPL. [btw, please do not take the above comparison as an insult. I was comparing on your logic not yourself to him... :) ]

I hope you will take the above [along with what others have posted] as reasons to GPL your code. BUT...it is your choice!

P.S. To Vick: Grow Up! Probono is just trying to do what he thinks is right. I don't agree with him but I understand he has some concerns about his code. The linux community should support each other even if one of them is wavering. We shouldn't curse each other! Your posts actually make me sick. If you want Probono to contribute his code to the community, why don't you take the first step and make a positive contribution to this discussion. Your "...The linux community will curse you forever" type post is crap! Take a pointer from bfree. I think he has some very good points! btw, I don't know what type of person you are (I guess I'll find out when you reply) but I hope you take this as constructive criticism so we can get back to the task at hand (ie. help Probono make a good and reflective decision). Anyway...my two cents!

[probono]

Does that mean the client has no dependencies and will work on any distro (e.g. mandrakemove)?

Yes.

[probono]

hi mrclark1971,

your points are all valid. Except for that I don't like to be compared with Darl... :twisted:

Probably I'll ask some of the KDE core developers what they would recommend me to do. If someone with real C and security experience would help me in "securing" the client, that would make me feel better about GPL'ing it.

[mrclark1971]

...hey probono...

LOL! I agree with you... :D I was just trying to shock you back to your "open sourceness."

[paradocs]

Greetings all,

First of all, I favor a main trusted collection of easily downloaded material for the targeted users. I stress trusted because of the mischief a rogue script could produce. A bad experience could be a big set back for this effort. Until there is better security -- like confining the script to one directory -- getting scripts from a trusted source is the only answer.

With trust, innovation and good design klik can compete as open source.
The recent improvements are a step in the right direction. Would calling the project a kiosk or server rather than a store project an image of service?

I am sure probono has a lot on his to-do list -- but now that were are in the "Ideas" section here goes.

In my burn_home project I have experiment with getting and saving the users files from the internet. Could klik have a login user area where the user would be able to down load his own content? The server would keep a TITLE, URL, INSTALL_PATH, and checks for RUN or DOWNLOAD. Perhaps start with say 20 entries. The user would have the files and scripts on his own web space. Each user could have a public and private area into which a user could give others access. Dedicated users would be contacting the site frequently -- increasing loyalty.

Best Wishes
paradocs

[champagnemojo]

I also agree on a single trusted site for now. The way it's set up at this early stage, the "recipes" could do all kinds of damage if not moderated in some fashion. Many users will not look at the scripts and will simply run them trustingly. Also, persons like myself with little linux knowledge could even look at a script and miss an exploit I'm sure.

I get no sense from probono that he doesn't want this to be open source...he's merely being realistic about security. If you want to convince him to make it GPL help him figure out how to secure Klik...don't preach to him about ideals he probably already holds.

[bfree]

If you want to convince him to make it GPL help him figure out how to secure Klik...
Does the following address the main concern?
Step 1: decide who is absolutely trusted, the admins.
Step 2: require user accounts to submit recipies.
Step 3: don't make a recipe installable until an admin has ok'd it!

Now the problem with the above is that it places the burden of adding all recipies on a small group of people, the admins. This is probably fine for now, the initial stages, and in fact may be preferable as a small group will also get to see how people are implementing recipies with a view to improving the system (including perhaps identifying any vectors people are trying to use to create trojans/worms/virus/bad things).

To scale the system up beyond a small core team will require one of:

A: Chefs are given authority, manually by the admins, to publish recipies directly, based on their history.
B: The system monitors recipie submitters and the validity of their recipies (initially determined by admins and any user feedback from installation) to give them scores. These scores can then be used either on their own with a threshold to allow chefs to publish recipes directly, or as a basis for peer moderation, where the chefs become the "admins" for the recipies. All the chefs should be sufficient (and scale correctly) to ensure bad things don't sneak through.
C: The system monitors all recipies, and allows all users to mark them as working/not working/bad. Whether or not a recipie can be installed normally depends on how many moderations/feedback it has, and the ratio of working -> not working and working -> bad. All the users will definetly be sufficient to check the recipies, but are they capable, would user feedback alone be sufficient to trust a recipie?

All of these options require some more intelligence on the part of the server running klik.

The key point is that it is the history of the klik server which will really determine its level of trust, and not the software at all. Whether or not the source is freely available will have a low impact on the risk from bad recipies compared to the diligence of the people involved in verifying recipies.

Of course adding in tracking on the popularity and postive feedback of recipies will also help to guide users away from the potentially riskier recipies. No matter what system is in place, if the system allows a random new user to submit a recipe to the system, which can then be installed by an end user, then the risk is their. Simply forcing people to take an extra step (for example having to save the recipie and inject it into kilk on the command line) to use recipie which have not yet been given a thumbs up by the community is probably the best thing to do to ensure a good balance between free and open development and non-recklessness.

Am I making any sense?

[qa1433]

Could Klick be used on programs that are downloaded to the drive?

Example: Real Player located in my /download director

Good work,
paul

[probono]

Could Klick be used on programs that are downloaded to the drive?

Theoretically yes, but it will be easier for you just to save your home directory along with the apps you have installed.

[probono]

First of all, I favor a main trusted collection of easily downloaded material for the targeted users. I stress trusted

full ack


Could klik have a login user area where the user would be able to down load his own content? The server would keep a TITLE, URL, INSTALL_PATH, and checks for RUN or DOWNLOAD.

You mean the user would upload his own recipes? For sure, that is planned. Recipes below a certain quality threshold would be just _displayed_ (with the option to run them manually), proven ones (by whatever means we come up with) would be _run_ through klik.

[probono]

Step 1: decide who is absolutely trusted, the admins.
Step 2: require user accounts to submit recipies.
Step 3: don't make a recipe installable until an admin has ok'd it!

I share your view, bfree. That's how it should be.

Now the problem with the above is that it places the burden of adding all recipies on a small group of people, the admins. This is probably fine for now, the initial stages, and in fact may be preferable as a small group will also get to see how people are implementing recipies with a view to improving the system (including perhaps identifying any vectors people are trying to use to create trojans/worms/virus/bad things).


To scale the system up beyond a small core team will require one of:(...)

I don't see this for the near future. For now, I think two-layered a system of users=contributors=evaluators plus admins=releasers would be sufficient. Contributed recipes not officially released would be just displayed instead of being run from within klik.


Am I making any sense?

Definitely :)

So, now is the question: whom would we trust as admins=releasers?

[bfree]

So, now is the question: whom would we trust as admins=releasers?
I realise I am sounding like a broken record, but if you are taking the manual approval approach what is the added benefit for security of keeping the klik client closed (I really don't see how keeping the client closed is a security benefit)? I had gooten the impression that you wanted the client closed to make it harder for "bad people" to inject "bad recipies" into the system which could exploit the client. Surely you don't need to "exploit" the client at all, as the client has the power to do just about anything the user can, so as to get software installed. Surely it is the recipies that need to be controlled and not the client? Do you really think that the benefits of having the client open (more eyes to spot problems and make improvements) are outweighed by the benefits of keeping it "closed" (reduced chance of someone finding a security problem in the client to exploit)?

As for who should actually be trusted, I can think of a few people but the question first is who wants to do the work?

[morglum666]

I think some of you code monkeys have stepped away a little from reality.

You need to get your idea up, running, and reliable before you can argue over copyright and open source. The author is absolutely correct; he wants it running smoothly so that modified copies of the client don't show up on the internet and break his invention.

Let that happen.

One of the key differences between huge corporations like microsoft and open source enthusiasts is that corporations need to complete tasks to make money, so they don't screw around as much with mindless debates. If you are building something, help contribute to his invention before begging him to GPL it.

Morglum

[mrclark1971]

...hey guys...

I guess a couple of you guys never understood this forum. It's about the "FUTURE OF KLIK." Now probono ASKED for our ideas (ANY IDEAS) about the future of klik. Now before I posted three issues had already come up.

(1) How to deal with contributors and their recipes?

(2) How to deal with security?

(3) The GPL question about the client?

I am sure other issues will come up but these are the major ones I have seen in the threads. THIS FORUM was started by probono to address these issues and the ones he listed in his first post here.

For myself, I will not be able to help on the first one. For the 2nd issue, I bow before the logic of bfree. Everytime I try to come up with something, he has that plus several more details I didn't consider. bfree, I'm glad you're here. On the 3rd issue, I gave my opinion on how I felt about client being GPLed. As stated before, I am no Linux guru this is just my honest opinion.

Now morglum666 wrote the following:

"I think some of you code monkeys have stepped away a little from reality." "The author is absolutely correct; he wants it running smoothly so that modified copies of the client don't show up on the internet and break his invention." "If you are building something, help contribute to his invention before begging him to GPL it."

I agree with you that probono should have time to get klik up and running. I do not think any of his decisions should be rushed at all. I think that would be a mistake on his part. In fact, if he doesn't want to GPL the client...that's his choice (read my previous post)! But this thread concerns the FUTURE OF KLIK. I only remind you because it seems you have left reality a little bit if you think the GPL issue isn't in the future. And I am not begging him to make it GPL. He asked my opinion (all of ours, in fact) and I gave it to him. Try to make the destinction in the future before slamming someone else's opinion. I respect your's so I hope mine will have the same protection.

[Vick]

....Master server<-(Recipes 1,2,3,4...)....
.........|.....|.........
Client |<->|Slave server
Client |<->|Slave server
Client |<->|Slave server
Client |<->|Slave server

New Declick project :?:

This one is my own invention, innovation 8)

Declick client/server process functions as follows:

The process is made up of five components ? (1) Master Server (2) Slave Servers (3) Clients (4) Recipes (5) md5sums

The Master Server is the controlling process and acts like a traffic cop (the md5sums is made here). Requests are made from the clients and the Master Server divides the workload among the slave servers. The Slave Servers access the Recipes performing the bulk of the work. Once the client process has been assigned the Slave Server, communications is between the client and Slave Server until the request is complete ( recheck the md5sums on client side with Master Server). Clients can be knoppix or any other nix distribution.

The Master Server handles all Declick requests. If a request is made for a Recipe, the Master Server will return the (link ip or http, ftp...) Slave Server to the client. The client will then establish communications with the Slave Server and get the Recipe and run it on the local machine if the md5sums is OK. It is very important that the client be able to get the link that the Master Server returns. There may be multiple Slave Servers running (1001 slaves), only Master Server will assign a Slave Server to a Client.

* All this is nice heu :shock: but i will not help you and the others on this project. I only contribute to FS,GPL projects, sorry about that :cry: . so i will probabely do it myself and released under GPL :?:

good luck!

PS: When enclose (gates) start to grow around, we jump and run away from theme.

[paradocs]

....(Public|Private-Client Data)->Master server<-(Recipes 1,2,3,4...)....
......^V......^V.................................. ...........................V............
......^V...<encrypt>...............................................<certify>......
.......CD Client<->Master Recipe Sv.|Other Recipe Sv.|Content Sv.

Hi Vick and All,
I liked your diagram and logic. Let's keep looking at all the possibilities.
In addition to serving up certified recipes and client recipes, the klik
server could keep special groups of recipes for the private use of a client.

A private client recipe "PCR" could be as simple as "put my unfinished
term paper on my desktop and configure my word processor the way I
like it". This could be automated and done at boot up.

As I suggested in a previous post, the kilk server would not hold the
actual data -- just recipes to fetch data, configuration files, or
add on programs. The CD Client would have to purchase web space for
his documents.

As a business model, the recipes are a "loss leader". These are best
open source and free. However, free (as in freedom and liberty) does
not have to mean there is no charge for an account for the PCR space.

Best Wishes
paradocs
-------------
Posted in my Grandfathers Saloon in German:
Today for Cash, Tomorrow for Free!

[probono]

As a business model, the recipes are a "loss leader". These are best open source and free. However, free (as in freedom and liberty) does not have to mean there is no charge for an account for the PCR space

As long as I am concerned, I don't want to charge anyone for anything. In fact, klik came from the idea to have a free alternative to the lindows.com CNR warehouse. Besides that, it would be copied one day after you started charging for it. No, let's keep this thing "free" as in speech *and* as in beer :) (see below)

[probono]

....Master server<-(Recipes 1,2,3,4...)....
.........|.....|.........
Client |<->|Slave server
Client |<->|Slave server
Client |<->|Slave server
Client |<->|Slave server


Now, besides load balancing, what is thre real advantage of this besides adding complexity? ;) sorry, perhaps I'm too simple-minded, but I don't see why we need so much complexity. Trafic is not a problem at all, especially since the recipes are just a few k in size. Security can best be achieved if we have one trusted "master server".

[probono]

OK, you convinced me.
Thanks for all of your posts that lead me to announce:

=================================================
klik is going GPL (dual license - like qt)
=================================================

I think what we should do next is open up a PHP & MySQL server space where we all can work together on the klik server. As I have never done a collaborative PHP project on this scale, how would we do this best? sourceforge cvs acount perhaps?

Or would it be better to integrate the whole thing into a site like kde-apps.org?

Please drop me a line to probono@myrealbox.com if you want to join.

[gowator]

So am I to assume everyone knocking probono before he went GPL is now busy coding and helping out!!!!

Or have things just gone quiet??

[Fabianx]

OK, you convinced me.
Thanks for all of your posts that lead me to announce:

=================================================
klik is going GPL (dual license - like qt)
=================================================

I think what we should do next is open up a PHP & MySQL server space where we all can work together on the klik server. As I have never done a collaborative PHP project on this scale, how would we do this best? sourceforge cvs acount perhaps?

Or would it be better to integrate the whole thing into a site like kde-apps.org?

Please drop me a line to probono@myrealbox.com if you want to join.

I would prefer a CVS (Berlios should have that) and will be going to submit support for other browsers as first ... ;-)

It is just nerving me that I can't go to klik to see if I can give a friend the infromation to just use klik or not, becuase I'm using mozilla / firebird / or whatever ... :-/

cu

Fabian :-)

[champagnemojo]

I would prefer a CVS (Berlios should have that) and will be going to submit support for other browsers as first ... ;-)

It is just nerving me that I can't go to klik to see if I can give a friend the infromation to just use klik or not, becuase I'm using mozilla / firebird / or whatever ... :-/

cu

Fabian :-)

That would be nice. I don't mind using Konqueror necessarily...but since I generally use Mozilla, it means opening a new app just to check to see if any new packages are available...if I could see them in Mozilla I could bookmark the site and check it more frequently.

[paradocs]

Hi all,

I expect that the code for downloading will
best be perfected for Konqueror. But I agree
that it would be nice to show the list of growing
programs in the other browsers.

Best Wishes
paradocs

[probono]

it would be nice to show the list of growing programs in the other browsers

Done! :)

[Crusader]

As a linux newbie, I don't know how to do this myself, but I would like to see Xlockmore and Nano available on Klik- I tried installing them on Knoppix but they wanted to access the parts of the system that sit on the CD, so I couldn't do it.

[nvgringo]

I tried to install the e mule program but there was a 404 page not found error. I posted a comment.
Maybe there could be some protocol on the klik page for reporting problems.
Maybe another link for requesting new recipes. I would post a request for Gkrellm.
I am new to linux but I did manage to install the live cd to the hard drive of an older computer. Klik is a great application Thanks Probono

[probono]

Fixed. There was a minor upgrade and therefore a version name change in the .deb file. Too bad the klik recipe breaks each time when this happens. Now it should work at least until the next upgrade.

[probono]

As a linux newbie, I don't know how to do this myself, but I would like to see Xlockmore and Nano available on Klik

As a linux _newbie_, why don't you try kate or kwrite as an editor? ;) And instead of Xlockmore you can use the KDE built-in "lock screen" (but you have to set a password first!)

I'll look into your suggested apps later, but right now I am on vacation in France :)

[nvgringo]

Hi again Probono thanks very much for posting a reply.It seems that part of the problem was fixed but it still won't download. I get the following error

--12:34:29-- http://snapshot.debian.net/archive/2004/01/19/debian/pool/main/z/zlib/zlib1g-dev_1.2.1-3_i386.deb
(try: 2) => `zlib1g-dev_1.2.1-3_i386.deb'
Connecting to snapshot.debian.net[218.223.29.46]:80... failed: Connection timed

I want you to know that I am not particularly desperate to download e mule. I think your effort is great. Since I don't know enough to repair the problems at least I can help by pointing one out if I find it.

[probono]

Seems that the debian snapshot server has a problem - unfortunately this affects several of the klik packages. Maybe you just try again later. Is klik so poular that it puts the debian server under extreme traffic? ;)

[Crusader]

Probono: Well, for the work I do at my university, I often need a nice command line text editor... I'm using Kwrite now and when I need the command line I fudge my way through Vim.
And I also use the lock screen function, I just wanted something prettier.

In any case, klik is great.

[Craig2]

Just in case you forgot, this was in the other topic (news):

> Craig2 wrote:


> knoppix@ttyp2[knoppix]$ /home/knoppix//Quanta/wrapper
QGDict::hashKeyString:


>> Thanks for the info, I'll investigate this. Right now, I'm on vacation, but I'll come back to it.<<

A more complete error message is back in the news topic.

No rush. I'm waiting for kde 3.2 anyway.

Any chance that the VPL mode (wysiwyg mode) in Quanta will work once KDE 3.2 is running?

Thanks again.

[Craig2]

If I copy the cd to hard disk using the todisk cheat code (not a debian install), will I still need to use klik to run klik applications? Or will I be able to apt-get them?

Even if apt-get is possible, the ability to install everything to a directory in the user's home folder has its advantages. Even if apt-get works, can klik still be used if todisk cheat code is used?

Thanks again for your efforts Probono!

[nvgringo]

I haven't seen much going on with this progect. Everyone was so worried about GPL open source. ProBono made that happen then the project seemed to stall. Anything new on the horizon? By the way ProBonnno the link on the KliK site for this forum links to the News area not here. Thought you might like to know.

[probono]

Just in case you forgot, this was in the other topic (news):
> Craig2 wrote:
> knoppix@ttyp2[knoppix]$ /home/knoppix//Quanta/wrapper
QGDict::hashKeyString:

I just tried it, Quanta installs and runs fine. Perhaps the debian mirror was down?


Any chance that the VPL mode (wysiwyg mode) in Quanta will work once KDE 3.2 is running?

I'll do my best. Actually, would be anyone interested in KDE 3.2 as a klik download? I think it would be possible...

probono

[probono]

If I copy the cd to hard disk using the todisk cheat code (not a debian install), will I still need to use klik to run klik applications? Or will I be able to apt-get them?

Using the cheatcode is just like using it from CDROM. So you'll still have to use klik.


Even if apt-get is possible, the ability to install everything to a directory in the user's home folder has its advantages. Even if apt-get works, can klik still be used if todisk cheat code is used?

Klik could technically be even used with a HD install, though I don't recommend it and I take no responsibility for it.

[probono]

I haven't seen much going on with this progect.

Well... I was on vacation :)

[Superstoned]

I'll do my best. Actually, would be anyone interested in KDE 3.2 as a klik download? I think it would be possible...

probono

well, I prefer it just naively in knoppix, but its very cool if you could do it... actually I dont really believe you, whouldnt that be very difficult? it's huge, alot can go wrong etc etc?!?!?

[probono]

well, I prefer it just naively in knoppix, but its very cool if you could do it... actually I dont really believe you, whouldnt that be very difficult? it's huge, alot can go wrong etc etc?!?!?

Actually, it's quite easy to write the klik recipe: First, you have to find out which packages to download (using apt-get). Second, you would have to unpack them. Third, you would have to exit X. Fourth, you would have to set some environment variables like KDEDIRS. Finally, you would have to restart X.

But I agree, let's wait until Knoppix incorporates it officially. :)

[probono]

Is it just me or is he describing klik:

"Stand Alone Knoppix Live Net Installer Would Enable Recipe Distro's : This is an excitng idea about how to handle distribution instalation via a Live Net Installer." (...)

http://thelinuxbox.org/Net_installer.html

[Stephen]

Is it just me or is he describing klik:

"Stand Alone Knoppix Live Net Installer Would Enable Recipe Distro's : This is an excitng idea about how to handle distribution instalation via a Live Net Installer." (...)

http://thelinuxbox.org/Net_installer.html

You know that is exactly what I was thinking when I read that last night. I think you should drop him a note about stealing other peoples ideas and not giving them credit.

[1ijack]

hello... can somebody help me. i installed firefox using klik but it wont run. this is the message that i get --->

/home/knoppix/FireFox/firefox/run-mozilla.sh: line 451: 6784 Illegal instruction "$prog" ${1+"$@"}

what should i do to fix this?

thanks in advance

[paradocs]

Hi 1ijack,
Klik works only with Konqueror Web Browser so
please use this to install the klik software.

Then by all means use your favorite browser
for everything else. :)

============edited=============
Sorry, I did not read your post correctly.
You are installing FireFox to use. :oops:

Do you run from a CD boot, and what date version
of KNOPPIX do you have?

Best Wishes
paradocs

[1ijack]

hello again,

yup im running it from cd with a persistent home.. version date is version 3.3-2004-02-16


thanks

[probono]

yup im running it from cd with a persistent home.. version date is version 3.3-2004-02-16

Do you still have this problem? Do other klik installations work? Has anyone else the same problem?

[1ijack]

hello,

yes i still have this problem.. i already tried installing firefox 3 times using klik and i still get the same error message. i also tried using KNOPPIX_V3.3-2004-02-09 still the same error -->

/home/knoppix/FireFox/firefox/run-mozilla.sh: line 451: 6784 Illegal instruction "$prog" ${1+"$@"}

hope u can fix this coz i really like firefox

thanks