The creative commons license is described in theory and in the reality very different. In the theory, Creative commons licensed images and texts can be modified by anybody, which includes forking of an entire project. According to the theory, a user takes a creative commons photo, puts this in his own version control system, adds some additional colors to the photo and the resulting photo is used in the blog.
The surprising fact is, that this theoretical workflow can't be realized in the reality. The problem is, that Creative commons is not the same like free the content from copyright, but it will start a conflict between the original author of the photo and the user how has reused the image. What does that mean? Suppose the ininformed user has put the modified photo on his homepage. Then the original author will take a look at it and he will check carefully if the Creative commons license is fulfilled. In most cases, the author will come to the conclusion that the secondary user was not allowed to use the photo specifically in a commercial context. The result is conflict between both parties. So creative commons has not simplified the situation but it will produce new problems.
Let us define for which purpose Creative commons and the Gnu public license is a great choice. It's for the read-only mode. If a content is provided under a creative commons license, this will ensure that no paywall will protect the content. That means, CC-BY is equal to “the world has access for free”. What CC-BY and similar licenses (which includes the BSD license) are not solving is the problem of forking content. Which means, that the world is allow to take the content and use it for their own purpose.
The problem is not located in the license itself, but in the copyright law in general. Creating content which is more free than CC-BY-SA content can be realized with neural networks which are producing the content from scratch. Instead of copying existing information the idea is to use a generative grammar which will produce a new kind of work. This new content is not a derivative of the original work, but it's produced by a computer software.
What the user has to proof is, that his picture on his own website is a different picture which was licensed under the CC-BY license. If the pictures are different, then the copyright law is no longer valid. That means, the original author has as no control over the second picture. The second picture can be used for any purpose, which includes commercial applications, forks or whatever.
Basically spoken, CC-BY and the GPL license is protecting content which is the same. if picture1==picture2 then the CC-BY license can be applied. That means the author of picture1 can dictate the rules to the owner of picture2.
Let us describe the situation from a technical perspective. There is file on the harddrive called “image1.jpg”. The author of the file has tagged the file with a CC-BY 4.0 SA license and uploaded it to the internet. A second user uses the “wget /remote/image1.jpg” command to download the file. He opens the picture in the gimp software and puts his individual logo on the picture. The resulting image2.jpg is uploaded to the blog. Such a workflow will produce a lot of work for the lawyer. Even if the original picture was tagged with CC-BY 4.0 license and even if the blog of user2 has the same license (CC-BY 4.0) it's not clear if a copyright violation was there or not. In case of doubt it was a copyright violation. Not because of the CC-BY license but because image1.jpg and image2.jpg is the same.
The reason is, that a unix command like “cp or wget” is producing an exact copy. That means all the pixel information are the same. And pictures and texts as well are created by someone first. He owns the information no matter which license he has choosen for the content. The answer to the problem is, to replace the “cp” command by something which is not producing a copy but something else.
A very simple example for creating an image from scratch is to manual redraw the outline of the picture with a pencil. This is what artists are doing. They take a photograph as template, draw the lines with a pencil and then the colors are put into the drawing. The resulting image2.jpg has nothing in common with the original but it's an image created from scratch. That means, it's not important under which license the original content was licensed, but the image2.jpg can be licensed by the artists by himself.
January 18, 2020
How to overcome the Creative commons license
On the first look, modern licenses like Creative commons, GPL and the MIT license are a here to stay, because they provide more freedom to the user. From the standpoint of spreading information into the world, these licenses have made a great job. Today's it's possible to download the latest Linux version for free and get access to lots of Creative commons pictures in the internet.
The limits of Open Source licenses are visible if someone tries to use the content in it's own product. According to the license itself, it's allowed in doing so. But in the reality nobody tries to do so, because it's a copyright violation. Let us make a simple example. Somebody downloads an photo from Wikipedia and puts the photo on the own homepage. The result is, that he is reused a copyright protected image. The first thing what will happen is, that WIkimedia will recognize the case. They have a special subpage in which all the Wikipedia content is tracked in the Internet. The second thing is, that the user gets perhaps an e-mail to not doing so in the future.
Somebody may assume that WIkipedia doesn't have understand the meaning of the Creative commons license, but it's a general problem. Suppose somebody ignores Wikipedia completely, and tries to re-use software which has a MIT License. That means, he downloads the sourcecode and then he puts the code onto his own homepage. The result is very similar to creative commons licenses. In theory it's maybe allowed in doing so, but in the real world it will create a lots of problems.
The real bottleneck is the not GPL, creative commons or MIT license, but it's the copyright for content. If somebody creates a text, and image or sourcecode from scratch he owns the copyright on this infomration. If a second person is using the content for it's own purpose, it's a copyright issue. The good news is, that it's pretty easy to overcome the problem. In short, a Generative Adversarial Network (GAN) can do the job pretty well.
What does that mean? The first important fact is, that the GPL license, CC-BY and the MIT License are not as free as expected. They are protecting copyright protected information and as the result, it's not possible to modify the content free of any rules. The more elaborated way in handling content is to create it from scratch every time. If content1 is different from content2 no copyright law at all is needed to protect it. Let me give an example: somebody creates an Generative Adversarial Network algorithm which takes as input the images from the WIkipedia. After the learning process, the algorithm is able to generate lots of new images from scratch. They will look different from the original one. That means, these new images are not protected by the Creative commons license, but the user has created the content from scratch. Therefor he is allowed to use them in any possible way.
The conclusion is, that the limits of creative commons license can be overcome easily with modern technology which is a neural network for generating the content from scratch. This will make any copyright regulation (no matter if classical or modern Creative commons licenses) obsolete.
The limits of Open Source licenses are visible if someone tries to use the content in it's own product. According to the license itself, it's allowed in doing so. But in the reality nobody tries to do so, because it's a copyright violation. Let us make a simple example. Somebody downloads an photo from Wikipedia and puts the photo on the own homepage. The result is, that he is reused a copyright protected image. The first thing what will happen is, that WIkimedia will recognize the case. They have a special subpage in which all the Wikipedia content is tracked in the Internet. The second thing is, that the user gets perhaps an e-mail to not doing so in the future.
Somebody may assume that WIkipedia doesn't have understand the meaning of the Creative commons license, but it's a general problem. Suppose somebody ignores Wikipedia completely, and tries to re-use software which has a MIT License. That means, he downloads the sourcecode and then he puts the code onto his own homepage. The result is very similar to creative commons licenses. In theory it's maybe allowed in doing so, but in the real world it will create a lots of problems.
The real bottleneck is the not GPL, creative commons or MIT license, but it's the copyright for content. If somebody creates a text, and image or sourcecode from scratch he owns the copyright on this infomration. If a second person is using the content for it's own purpose, it's a copyright issue. The good news is, that it's pretty easy to overcome the problem. In short, a Generative Adversarial Network (GAN) can do the job pretty well.
What does that mean? The first important fact is, that the GPL license, CC-BY and the MIT License are not as free as expected. They are protecting copyright protected information and as the result, it's not possible to modify the content free of any rules. The more elaborated way in handling content is to create it from scratch every time. If content1 is different from content2 no copyright law at all is needed to protect it. Let me give an example: somebody creates an Generative Adversarial Network algorithm which takes as input the images from the WIkipedia. After the learning process, the algorithm is able to generate lots of new images from scratch. They will look different from the original one. That means, these new images are not protected by the Creative commons license, but the user has created the content from scratch. Therefor he is allowed to use them in any possible way.
The conclusion is, that the limits of creative commons license can be overcome easily with modern technology which is a neural network for generating the content from scratch. This will make any copyright regulation (no matter if classical or modern Creative commons licenses) obsolete.
January 17, 2020
Forking a Wikipedia article
Instead of putting the fork online a more easier to explain version is hold only a local copy. The advantage is, that in such a case no copyright problems can occurs, because downloading information is always allowed, only the upload of information can produce trouble.
In the following tutorial a local fork of the AIMA article https://en.wikipedia.org/wiki/Artificial_Intelligence:_A_Modern_Approach is created. Because it has to do with Artificial Intelligence and the article is not very long, so it's a great choice for experimenting a bit. The first thing to do is to create in a working directory a git project:
git init
Then the AIMA article from 2004-03-31 (an early version of the stub) is copied into the folder and the commit is created.
cp /remote/AIMA-article2004-03-31 aima.txt
git add --all && git commit -m "init"
The file doesn't has a date as a name, but it's simply call aima. The different versions are tracked by the git tool, but not by the programmer. Right now, the git repository contains of a single file which was downloaded from the Wikipedia server.
It's time for forking the file. This isn't done by creating a new git branch, but the fork is managed by the user himself. This provides a greater control of the fork and the upstream version:
cp aima.txt aimafork.txt
gedit aimafork.txt
The aimafork.txt file is edited by the user, he adds a new paragraph with criticism about the book. The user writes down, that the book is too expensive for the normal student.
In the meantime, the users in the Wikipedia project have updated the AIMA article. They are not aware, that in the local fork a new chapter was added, but they are following their own strategy. The updated upstream version is copied into the working directory and overwrites the previous version. It's important that before doing so the git commit command was executed. So that it's possible to go back into the timeline to a a previous point.
git add --all && git commit -m "add chapter criticism"
cp /remote/AIMA-article2004-03-31 aima.txt
git add --all && git commit -m "new upstream version"
The open question is how to merge the upstream version with the forked-version? Merging is equal to concatenate different files:
cat aima.txt >> aimafork.txt
git add --all && git commit -m "cat upstream to fork"
gedit aimafork.txt
git add --all && git commit -m "clean up the fork"
After the upstream and the fork file are combined and all the sections are ordered, the aimafork.txt file is in a great condition.It contains all the latest information from the upstream plus the extra chapter written in the fork. The procedure is repeated over and over again. Which means:
1. download the upstream version into the local repository
2. cat the upstream to the fork
3. clean up the fork
4. improve the fork with new sections
What the user is doing is to maintain two versions in parallel, he has access to the upstream version and to his local fork at the same time. The self created fork is more advanced than the upstream version because it contains of more information. It's the same article about the AIMA book but which was improved by a single user.
In the following tutorial a local fork of the AIMA article https://en.wikipedia.org/wiki/Artificial_Intelligence:_A_Modern_Approach is created. Because it has to do with Artificial Intelligence and the article is not very long, so it's a great choice for experimenting a bit. The first thing to do is to create in a working directory a git project:
git init
Then the AIMA article from 2004-03-31 (an early version of the stub) is copied into the folder and the commit is created.
cp /remote/AIMA-article2004-03-31 aima.txt
git add --all && git commit -m "init"
The file doesn't has a date as a name, but it's simply call aima. The different versions are tracked by the git tool, but not by the programmer. Right now, the git repository contains of a single file which was downloaded from the Wikipedia server.
It's time for forking the file. This isn't done by creating a new git branch, but the fork is managed by the user himself. This provides a greater control of the fork and the upstream version:
cp aima.txt aimafork.txt
gedit aimafork.txt
The aimafork.txt file is edited by the user, he adds a new paragraph with criticism about the book. The user writes down, that the book is too expensive for the normal student.
In the meantime, the users in the Wikipedia project have updated the AIMA article. They are not aware, that in the local fork a new chapter was added, but they are following their own strategy. The updated upstream version is copied into the working directory and overwrites the previous version. It's important that before doing so the git commit command was executed. So that it's possible to go back into the timeline to a a previous point.
git add --all && git commit -m "add chapter criticism"
cp /remote/AIMA-article2004-03-31 aima.txt
git add --all && git commit -m "new upstream version"
The open question is how to merge the upstream version with the forked-version? Merging is equal to concatenate different files:
cat aima.txt >> aimafork.txt
git add --all && git commit -m "cat upstream to fork"
gedit aimafork.txt
git add --all && git commit -m "clean up the fork"
After the upstream and the fork file are combined and all the sections are ordered, the aimafork.txt file is in a great condition.It contains all the latest information from the upstream plus the extra chapter written in the fork. The procedure is repeated over and over again. Which means:
1. download the upstream version into the local repository
2. cat the upstream to the fork
3. clean up the fork
4. improve the fork with new sections
What the user is doing is to maintain two versions in parallel, he has access to the upstream version and to his local fork at the same time. The self created fork is more advanced than the upstream version because it contains of more information. It's the same article about the AIMA book but which was improved by a single user.
How open is the GPL license?
From a theoretical point of view, the Gnu public license is well documented and well known in the public. In contrast to a proprietary license the sourcecode can be redistributed by asking anyone, and it's possible to use the code in the own project if the new project contains of the same GPL license. A possible discussion would read the following way:
user1: Can i copy the Linux kernel and improve it by myself?
user2: Why do you ask?
user1: Because this is not allowed with proprietary code.
user2: I'm not an expert for law, but the GPL license is used by the open source community because it's superior to the plan license which prevents code-redistribution.
This is – in short – the discussion style used by open source advocates. They are proud of the GPL license because it gives them and the world the freedom to share and reuse written code. It's surprising to know that the reality looks a bit different. The legal aspects of coping software are not defined in the literature but what is happen in reality. How many people have copied the Linux sourcecode to their own computer? Not that much. Around the world less than 5 million PCs are running LInux. In contrast, billion of PC are running with Windows. So from a legal aspect, Windows is more legal than Linux. But suppose all the Windows user are not informed, that they can install Linux too. So we have to ask, how many forks of the LInux kernel were created in the past? A fork is a concrete application of the GPL license, it means to use existing sourcecode in the own project. The answer is, that not a single Linux fork is available.
Four years ago, Matthew Garrett (which was involved in the Kernel programming team) has talked about forking the Kernel https://www.zdnet.com/article/matthew-garrett-is-not-forking-linux/ but he hasn't do so. In other projects which are called a fork, a mostly not a real fork, but it's only a patch, which means extra software which can be installed as a plugin to the kernel, similar to writing a mod for a computer game. So the funny question is, why was the Linux kernel never forked? Are the software developers are not informed about the GPL license which explains that this is allowed?
Exactly this is the problem. In the theory, the GPL license allows the programmer to fork the kernel. That means to copy the sourcecode onto the own server and invite other people to modify the content. In the reality, nobody is doing so.
In contrast, normal propiatary software for example BSD Unix is forked very often Apple for example is based on the BSD kernel. It seems, that the GPL license results into a situation in which nobody will fork the code, especially because it's allowed in the license. But what the reason behind it?
Suppose somebody takes the Linux kernel as fulltext, puts it into a git repository and make some changes on it. Then he explains that the fork is licensed under a GPL license and everybody is allowed to download and change the code. The funny thing is, that this user would be the first one in the world who is doing so. That means, it's not sure what will happen next. if Linux is licensed under a GPL License why is no Linux fork available? Open Source activists are explaining to the world that Linux is the future. Ok, which Open Source activist group is powerful enough to fork the Linux kernel and show in reality what will happen?
How open is the GPL license?
Let us explain what the problem with a fork is, if it's done with normal copyright protected software. Suppose somebody takes the sourcecode from the Microsoft windows ooperating system, copies it into a github folder and invites other people to send a commit. The other user will clone the repository, create patches and commit it back to the github folder. From a technical side such a project is a great idea. That means, the programmer will improve the code a lot, fix all the bugs and the end user can download the next release.
Everybody who is familiar with the history of the computer industry knows what the real problem is. It's not the technical problem of create commits and push the result to the server but the problem has to do with the license, the copyright law, and that forking of copyright protected content is a form of redistribution. It's not very complicated to predict that forking the Windows sourcecode will produce a lot of trouble in theory and in reality as well. That is the reason why nobody is doing so.
And now let us imagine the same situation for the Linux kernel. Everybody knows that Linux is a different project. So it's allowed to create a git project publicly and commit changes to the server? I don't know. From a theoretical point of view, it's allowed because this is explained in the GPL license. But in reality, nobody has tried to do so in the past, so it's not clear if it's allowed or not. What we can say for sure, that coping the LInux sourcecode to an online repository and invite other people to commit patches is equal to fork a project. Forking is something which is discussed by the copyright law and if it's not allowed it will produce a lot of trouble.
user1: Can i copy the Linux kernel and improve it by myself?
user2: Why do you ask?
user1: Because this is not allowed with proprietary code.
user2: I'm not an expert for law, but the GPL license is used by the open source community because it's superior to the plan license which prevents code-redistribution.
This is – in short – the discussion style used by open source advocates. They are proud of the GPL license because it gives them and the world the freedom to share and reuse written code. It's surprising to know that the reality looks a bit different. The legal aspects of coping software are not defined in the literature but what is happen in reality. How many people have copied the Linux sourcecode to their own computer? Not that much. Around the world less than 5 million PCs are running LInux. In contrast, billion of PC are running with Windows. So from a legal aspect, Windows is more legal than Linux. But suppose all the Windows user are not informed, that they can install Linux too. So we have to ask, how many forks of the LInux kernel were created in the past? A fork is a concrete application of the GPL license, it means to use existing sourcecode in the own project. The answer is, that not a single Linux fork is available.
Four years ago, Matthew Garrett (which was involved in the Kernel programming team) has talked about forking the Kernel https://www.zdnet.com/article/matthew-garrett-is-not-forking-linux/ but he hasn't do so. In other projects which are called a fork, a mostly not a real fork, but it's only a patch, which means extra software which can be installed as a plugin to the kernel, similar to writing a mod for a computer game. So the funny question is, why was the Linux kernel never forked? Are the software developers are not informed about the GPL license which explains that this is allowed?
Exactly this is the problem. In the theory, the GPL license allows the programmer to fork the kernel. That means to copy the sourcecode onto the own server and invite other people to modify the content. In the reality, nobody is doing so.
In contrast, normal propiatary software for example BSD Unix is forked very often Apple for example is based on the BSD kernel. It seems, that the GPL license results into a situation in which nobody will fork the code, especially because it's allowed in the license. But what the reason behind it?
Suppose somebody takes the Linux kernel as fulltext, puts it into a git repository and make some changes on it. Then he explains that the fork is licensed under a GPL license and everybody is allowed to download and change the code. The funny thing is, that this user would be the first one in the world who is doing so. That means, it's not sure what will happen next. if Linux is licensed under a GPL License why is no Linux fork available? Open Source activists are explaining to the world that Linux is the future. Ok, which Open Source activist group is powerful enough to fork the Linux kernel and show in reality what will happen?
How open is the GPL license?
Let us explain what the problem with a fork is, if it's done with normal copyright protected software. Suppose somebody takes the sourcecode from the Microsoft windows ooperating system, copies it into a github folder and invites other people to send a commit. The other user will clone the repository, create patches and commit it back to the github folder. From a technical side such a project is a great idea. That means, the programmer will improve the code a lot, fix all the bugs and the end user can download the next release.
Everybody who is familiar with the history of the computer industry knows what the real problem is. It's not the technical problem of create commits and push the result to the server but the problem has to do with the license, the copyright law, and that forking of copyright protected content is a form of redistribution. It's not very complicated to predict that forking the Windows sourcecode will produce a lot of trouble in theory and in reality as well. That is the reason why nobody is doing so.
And now let us imagine the same situation for the Linux kernel. Everybody knows that Linux is a different project. So it's allowed to create a git project publicly and commit changes to the server? I don't know. From a theoretical point of view, it's allowed because this is explained in the GPL license. But in reality, nobody has tried to do so in the past, so it's not clear if it's allowed or not. What we can say for sure, that coping the LInux sourcecode to an online repository and invite other people to commit patches is equal to fork a project. Forking is something which is discussed by the copyright law and if it's not allowed it will produce a lot of trouble.
January 16, 2020
Technical experiments wiki-pov fork
The precondition for a successful fork project is, that the fork gets all the patches from the upstream projects. Otherwise the branches are of sync. At the same time, the goal is to not sync the branches so that it make sense to create a fork which looks different. This sounds a bit complicated so let us go into the details of using the git tool for merging different branches.
The first attempt in using only 2 branches was not succesful. The idea was, that the upstream is copied in to the master branch, while the fork is edited in the issue1 branch. The first merge was working fine, but after the second merge some conflicts are the result.
The next next was to use three branches: upstream, master and issue1. This is working much better and it like to explain the idea. The first thing to do is to initialize in a working directory the git repository:
git init
git branch issue1
git branch upstream
git branch
On the screen there are three branches available in which the user can edit. In the upstream branch the snapshot from the wikipedia website are stored. The file article.txt hold the current version which is updated once a month. The upstream is merged into the master branch, and then it's merged into the issue branch. In the issue branch the fork can be edited. Now, the next version of the upstream version is stored in the upstream branch.
And now the magic happens, the user switches to the master branch and executed the following statement:
git merge upstream
git merge issue1
What the git software is doing is to combine the latest upstream version with the fork into a new file. The resulting article.txt contains all the improvements from Wikipedia but it contains also the updates from the fork.
I know, the overall procedure is very complicated because the user has to type in many commands into the terminal. So the prediction is, that some errors will upraise. But in general the idea is to use three branches and merge them into the master branch. In contrast, the upstream branch holds only the upstream version history, which is equal to the timeline of WIkipedia provided in the website.
The chart from the beginning will increase the confusion. What the user needs to know is that he has to copy the latest version of the Wikipedia article into the upstream branch, and commit the changes with “git commit”. It's also important to not delete the branches after merging, because the issue1 branch is the forked version which looks different from the upstream. If the user want's to edit the encyclopedia he is doing so only in the issue1 branch. The master branch is some kind of clearning branch in which the two other branches are combined.
January 15, 2020
POV forking of Wikiipedia
On the first look the git tool and the Wikipedia project are working the same, because they are supporting a version history. The difference is, that the Wikipedia project never was forked in his history, only local copies are created. A fork is technique used heavily at github to bypass the original community and start developing a new branch. The main feature of a fork is it's ability to integrate the updates of the upstream. That means, the fork contains the latest information plus extra content.
The subject overall is very complicated. So i have decided to make a simple experiment to test what will happen in the reality. For the first step, the fork is created only on the local harddrive but not in the Internet, and it's not the entire Wikipedia but only a few files. But it is well documented so that other users can reproduce the steps. It starts by creating a new git project in a working directory:
mkdir wiki-fork
git init
touch readme.txt
git add --all && git commit -m "initial commit"
Then the folder is populated with three files from the original wikipedia, With a copy&paste the latest markup-file is created in the directory. What we need also is a branch:
git add --all && git commit -m "create three files"
git branch issue1
The idea is, that the fork is maintained in the issue1 branch while the original project (upstream) stays in the master branch. The merge is done with the following command:
git checkout master
git merge issue1
git branch -d issue1 // delete branch
The idea is, that in the issue1 branch my own individualized Wikipedia version is available in which only i can edit, similar to a sandbox. The created edits are never send back into the Wikipedia but they are merged on the local harddrive into the master branch. The best visual understanding is a github project in which a fork is created. In theory, this allows to the developer to become independent from the original project.
The open question is, how does it work in reality. I have searched at Google for some information but didn't found something. So i have to test it out. The critical point is, that sometimes the upstream will update their content. That means, if the wikipedia community change one of the three files online, i have to update the content in the master too. The problem is, that the information in the issue1 branch are different from that so there is need to merge. It's unclear how often this is necessary. The hope is that a merge is needed only once a week, and that it can be done automatically. But in case of doubt it will result into a merge conflict and it's unclear how to solve it.
What we can say is, that the git tool is a here to stay. It's the most advanced forking / version control system available and was designed with the desired purpose in mind.
The subject overall is very complicated. So i have decided to make a simple experiment to test what will happen in the reality. For the first step, the fork is created only on the local harddrive but not in the Internet, and it's not the entire Wikipedia but only a few files. But it is well documented so that other users can reproduce the steps. It starts by creating a new git project in a working directory:
mkdir wiki-fork
git init
touch readme.txt
git add --all && git commit -m "initial commit"
Then the folder is populated with three files from the original wikipedia, With a copy&paste the latest markup-file is created in the directory. What we need also is a branch:
git add --all && git commit -m "create three files"
git branch issue1
The idea is, that the fork is maintained in the issue1 branch while the original project (upstream) stays in the master branch. The merge is done with the following command:
git checkout master
git merge issue1
git branch -d issue1 // delete branch
The idea is, that in the issue1 branch my own individualized Wikipedia version is available in which only i can edit, similar to a sandbox. The created edits are never send back into the Wikipedia but they are merged on the local harddrive into the master branch. The best visual understanding is a github project in which a fork is created. In theory, this allows to the developer to become independent from the original project.
The open question is, how does it work in reality. I have searched at Google for some information but didn't found something. So i have to test it out. The critical point is, that sometimes the upstream will update their content. That means, if the wikipedia community change one of the three files online, i have to update the content in the master too. The problem is, that the information in the issue1 branch are different from that so there is need to merge. It's unclear how often this is necessary. The hope is that a merge is needed only once a week, and that it can be done automatically. But in case of doubt it will result into a merge conflict and it's unclear how to solve it.
What we can say is, that the git tool is a here to stay. It's the most advanced forking / version control system available and was designed with the desired purpose in mind.
Alternatives to mediawiki
The mediawiki engine was programmed in the PHP language because of historical reasons. PHP is more advanced than outdated perl scripts but it has major performance problems. The question is which programming language fits more to modern needs? One idea is to use king of programming languages which is C++. C++ is the fastest language available which is supported by independent compilers. It can be used for creating web-applications and outperforms PHP easily. Another alternative is Python which is an easy to use beginner language.
Some wiki systems were written in the C++ language already but they are not used in reality. And python as a language is much slower than PHP. A possible third candidate is https://en.wikipedia.org/wiki/Wiki.js which is working with node.js in the background. In contrast to C++ the Javascript language is accepted widely for web-development. IT's only bottleneck is, that it doesn't provide object oriented features so it can't be used for building larger applications. But is this assumption correct from todays standpoint?
https://www.geeksforgeeks.org/prototype-in-javascript/ describes how to create prototypes in Javascript which are lighter object oriented templates. Recent versions of Javascript are equipped with full blown oop features including inheritance. So it make sense to take a closer look into the WIki-js rendering engine. The advantage is, that the GUI which is shown in the webbrowser and the backend application is written in the same programming language. This provides – in theory – more better user experience than the outdated mediawiki engine written in PHP.
An online demo for “wiki.js” isn't available. What goes into the direction is the visual editor of Wikipedia which is based on node.js. The normal mediawiki backend system was realized in PHP. It seems, that the developers are happy with this idea. One reason is, that PHP was designed as a backend language, while javascript is famous of it's ability to embedded textboxes and forms into the code.
Some wiki systems were written in the C++ language already but they are not used in reality. And python as a language is much slower than PHP. A possible third candidate is https://en.wikipedia.org/wiki/Wiki.js which is working with node.js in the background. In contrast to C++ the Javascript language is accepted widely for web-development. IT's only bottleneck is, that it doesn't provide object oriented features so it can't be used for building larger applications. But is this assumption correct from todays standpoint?
https://www.geeksforgeeks.org/prototype-in-javascript/ describes how to create prototypes in Javascript which are lighter object oriented templates. Recent versions of Javascript are equipped with full blown oop features including inheritance. So it make sense to take a closer look into the WIki-js rendering engine. The advantage is, that the GUI which is shown in the webbrowser and the backend application is written in the same programming language. This provides – in theory – more better user experience than the outdated mediawiki engine written in PHP.
An online demo for “wiki.js” isn't available. What goes into the direction is the visual editor of Wikipedia which is based on node.js. The normal mediawiki backend system was realized in PHP. It seems, that the developers are happy with this idea. One reason is, that PHP was designed as a backend language, while javascript is famous of it's ability to embedded textboxes and forms into the code.
How to fix the rm -f problem
Linux user are confronted with a serious problem. The operating system doesn't ask many questions but it will execute the rm -rf command. The problem is, that all the data are deleted and it's not possible to recover them. To prevent such a mishap it's a good idea to reconfigure the rm command. Perhaps it would make sense if all Linux distributions would do so by default. What the average user want's is to delete files only with the file-manager but not with the rm command.
gedit ~/.bashrc
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
source ~/.bashrc
gedit ~/.bashrc
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
source ~/.bashrc
Subscribe to:
Posts (Atom)