Skip to content

Sunday, 19 July 2020

Dear digiKam fans and users, Just in time to get you into the holiday spirit, we are now proud to release digiKam 7.0.0 final release today. This version is a result of a long development that started one year ago and in which we have introduced new features and plenty of fixes. Check out some of the highlights listed below and discover all the changes in detail. Deep-Learning Powered Faces Management For many years, digiKam has provided an important feature dedicated to detecting and recognizing faces in photos.

Monday, 23 March 2020

This blog post was not easy to write as it started as a very simple thing intended for developers, but later, when I was digging around, it turned out that there is no good single resource online on copyright statements. So I decided to take this stab at writing one.

I tried to strike a good balance between 1) keeping it short and to the point for developers who just want to know what to do, and 2) FOSS compliance officers and legal geeks who want to understand not just best practices, but also the reasons behind them.

If you are extremely short on time, the TL;DR should give you the bare minimal instructions, but if you have just 2 minutes I would advise you to read the actual HowTo a bit lower below.

Of course, if you have about 20 minutes of time, the best way is always to start reading at the beginning and finish at the end.

Where else to find this article & updates

A copy of this blog is available also on Liferay Blog.
Haksung Jang (장학성) was awesome enough to publish a Korean translation.

2021-03-09 update: better wording; more info on how to handle anonymous authors and when copyright is held by employer, © and ASCII, multiple authors; DCO; easier REUSE instructions

2022-10-23 update: more FAQ entries


Use the following format:

SPDX-FileCopyrightText: © {$year_of_file_creation} {$name_of_copyright_holder} <{$contact}>

SPDX-License-Identifier: {$SPDX_license_name}

… put that in every source code file and go check out (and follow) best practices, published by the FSFE.

E.g. for a file that I created today and I released under the BSD-3-Clause license, I would use put the following as a comment at the top of the source code file:

SPDX-FileCopyrightText: © 2020 Matija Šuklje <>

SPDX-License-Identifier: BSD-3-Clause

Introduction and copyright basics

Copyright is automatic (since the Berne convention) and any work of authorship is automatically protected by it – essentially giving the copyright holder1 exclusive power over their work. In order for your downstream to have the rights to use any of your work – be that code, text, images or other media – you need to give them a license to your work.

So in order for you to copy, implement, modify etc. the code from others, you need to be given the needed rights – i.e. a license2 –, or make use of a statutory limitation or exception3. And if that license has some obligations attached, you need to meet them as well.

In any case, you have to meet the basic requirements of copyright law as well. At the very least you need to have the following two in place:

  • attribution – list the copyright holders and/or authors – especially in jurisdictions which recognise moral rights (e.g. most of EU) it is important to keep the names of authors, if they are listed;
  • license(s) – since a license is the only thing that gives anybody other than the copyright holder themself the right to use the code, you are very well advised to have a notice of the the license and its full text present – this goes for both for your outbound licenses and the inbound licenses you received from others by using 3rd party works, such as copied code or libraries.

Inbound vs. outbound licenses

The license you give to your downstream is called an outbound license, because it handles the rights in the code that flow out of you. In turn that same license in the same work would then be perceived by your downstream as their inbound license, as it handles the rights in the code that flows into them.

In short, licenses describing rights flowing in are called inbound licenses, and the licenses describing rights flowing out are called outbound licenses.

The good news is that attribution is a discretionary right that can be exercised by the author should they choose to. And you are obliged to keep the attribution notices only insofar as the author(s) made use of that right. Which means that if the author has not listed themselves, you do not have to hunt them down yourself.

Why have the copyright statement?

Which brings us to the question of whether you need to write your own copyright statement4.

First, some very brief history …

The urge to absolutely have to write copyright statements stems from the inertia in the USA, as it only joined the Berne convention in 1989, well after computer programs were a thing. Which means that before then the US copyright law still required an explicit copyright statement in order for a work to be protected.

Copyright statements are useful

The copyright statement is not required by law, but in practice very useful as proof, at best, and indicator, more likely, of what the copyright situation of that work is. This can be very useful for compliance reasons, traceability of the code etc.

Attribution is practically unavoidable, because a) most licenses explicitly call for it, and if that fails b) copyright laws of most jurisdictions require it anyway.

And if that is not enough, then there is also c) sometimes you will want to reach the original author(s) of the code for legal or technical reasons.

So storing both the name and contact information makes sense for when things go wrong. Finding the original upstream of a runaway file you found in your codebase – if there are no names or links in it – is a huge pain and often includes (currently still) expensive specialised software. I would suspect the onus on a FOSS project to be much lower than on a corporation in this case, but still better to put a little effort upfront than having to do some serious archæology later.

How to write a good copyright statement and license notice

Finally we come to the main part of this article!

A good copyright statement should consist of the following information:

  • start with the © sign;
  • the year of the first publication – a good date would be the year in which you created the file and then do not touch that date anymore;
  • the name of the copyright holder – typically the author, but depending on the circumstances might be their employer or if there is a CLA in place the legal entity or person they transferred their rights to;
  • a valid contact to the copyright owner

As an example, this is what I would put on something I wrote today:

© 2020 Matija Šuklje <>

While you are at it, it would make a lot of sense to also notify everyone which license you are releasing your code under as well. Using an SPDX ID is a great way to unambiguously state the license of your code. (See note mentioned below for an example of how things can go wrong otherwise.)

And if you have already come so far, it is just a small step towards following the best practices as described by by using SPDX tags to make your copyright statement (marked with SPDX-FileCopyrightText) and license notice (marked with SPDX-License-Identifier and followed by an SPDX ID).

Here is now an example of a copyright statement and license notice that check all the above boxes and also complies with both the SPDX and the specifications:

SPDX-FileCopyrightText: © 2020 Matija Šuklje <>

SPDX-License-Identifier: BSD-3-Clause

Now make sure you have these in comments of all your source code files.


Over the years, I have heard many questions on this topic – both from developers and lawyers.

I will try to address them below in no particular order.

If you have a question that is not addressed here, do let me know and I will try to include it in an update.

Why keep the year?

Some might argue that for the sake of simplicity it would be much easier to maintain copyright statements if we just skip the years. In fact, that is a policy at Microsoft/GitHub at the time of this writing.

While I agree that not updating the year simplifies things enormously, I do think that keeping a date helps preserve at least a vague timeline in the codebase. As the question is when the work was first expressed in a medium, the earliest date provable is the time when that file was first created.

In addition, having an easy way to find the earliest date of a piece of code, might prove useful also in figuring out when an invention was first expressed to the general public. Something that might become useful for patent defense.

This is also why e.g. in Liferay our new policy is to write the year of the file creation, and then not change the year any more.

Innocent infringement excursion for legal geeks

17 U.S. Code § 401.(d) states that if a work carries a copyright notice in the form that the law proscribes, in a copyright infringement case the defendant cannot rely on the innocent infringement defense, except if they had reason to believe their use was covered fair use. And even then, the innocent infringer would have to be e.g. a non-profit broadcaster or archive to be still eligible to such defence.

So, if you are concerned with copyright violations (at least in USA), you may actually want to make sure your copyright statements include both the copyright sign and year of publication.

See also note in Why the © sign for how a copyright notice following the US copyright act looks like.

Why not bump the year on change?

I am sure you have seen something like this before:
Copyright (C) 1992, 1995, 2000, 2001, 2003 CompanyX Inc.

The presumption behind this is that whenever you add a new year in the copyright statement, the copyright term would start anew, and therefore prolong the time that file would be protected by copyright.

Adding a new year on every change – or, even worse, simply every 1st January – is a practice still too wide-spread even today. Unfortunately, doing this is useless at best, and misleading at worst. Needless to say, if you do this as part of your build process, this is extra wrong. For the origin of this myth see the short history above.

A big problem with this approach is that not every contribution is original or substantial enough to be copyrightable – even the popular 5 (or 10, or X) SLOC rule of thumb5 is legally-speaking very debatable.

So, in order to keep your copyright statement true, you would need to make a judgement call every time whether the change was substantial and original enough to be granted copyright protection by the law and therefore if the year should be bumped. And that is a substantial test for every time you change a file.

On the other hand copyright lasts at least 50 (and usually 70) years6 after the death of the author; or if the copyright holder is a legal entity (e.g. CompanyX Inc.), since publication. So the risk of your own copyright expiring under your feet is very very low.

Worst case thought experiment

Let us imagine the worst possible scenario now:

1) you never bump the year in a copyright statement in a file and 2) 50+ years after its initial release, someone copies your code as if it were in public domain. Now, if you would have issue with that and go to court, and 3) the court would (very unlikely) take only the copyright statements in that file into account as the only proof and based on that 4) rule that the code in that file would have fallen under public domain and therefore the FOSS license would not apply to it any more.

The end result would simply be that (in one jurisdiction) that file would fall into public domain and be up for grabs by anyone for anything, no copyright, no copyleft, 50+ years from the file’s creation (instead of e.g. 5, maybe 20 years later).

But, honestly, how likely is it that 50 years from now the same (unaltered) code would still be (commercially) interesting?

… and if it turns out you do need to bump the year eventually, you still have, at worst, 50 years to sort it out – so, ample opportunity to mitigate the risk.

In addition to that, as typically a single source code file is just one of the many cogs in a bigger piece of software, what you are more concerned with is the software product/project as a whole. As the software grows, you will keep adding new files, and those will obviously have newer years in them. So the codebase as a whole work will already include copyright statements with newer years in it anyway.

Keep the Git/VCS history clean

Also, bumping the year in all the files every year messes with the usefulness of the Git/VCS history, and makes the log unnecessarily long(er) and the repository consumes more space.

It makes all the files seem equally old (in years), which makes it hard to identify stale code if you are looking for it.

Another issue might be that your year-bumping script can be too trigger-happy and bump the years also in the files that do not even belong to you. Furthering misinformation both in your VCS and the files’ copyright notices.

Why not use a year range?

Similar to the previous question, the year span (e.g. 1990-2013) is basically just a lazy version of bumping the year. So all of the above-mentioned applies.

A special case is when people use a range like {$year}-present. This has almost all of the above-mentioned issues7, plus it adds another dimension of confusion, because what constitutes the “present” is an open – and potentially philosophical – question. Does it mean:

  • the time when the file was last modified?
  • the time it was released as a package?
  • the time you downloaded it (maybe for the first time)?
  • the time you ran it the last time?
  • or perhaps even the ever eluding “right now”?

As you can see, this does not help much at all. Quite the opposite!

But doesn’t Git/Mercurial keep a better track?

Not reliably.

Git (and other VCS) are good at storing metadata, but you should be careful about it.

Git does have an Author field, which is separate from the Committer field. But even if we were to assume – and that is a big assumption8 – Git’s Author was the actual author of the code committed, they may not be the copyright holder.

Furthermore, the way git blame and git diff currently work, is line-by-line and using the last change as the final author, making Git suboptimal for finding out who actually wrote what.

Token-based blame information

For a more fine-grained tool to see who to blame for which piece of code, check out cregit.

And ultimately – and most importantly – as soon as the file(s) leave the repository, the metadata is lost. Whether it is released as a tarball, the repository is forked and/or rebased, or a single file is simply copied into a new codebase, the trace is lost.

All of these issues are addressed by simply including the copyright statement and license information in every file. best practices handle this very well.

Why the © sign?

Some might argue that the English word “Copyright” is so common nowadays that everyone understands it, but if you actually read the copyright laws out there, you will find that using © (i.e. the copyright sign) is the only way to write a copyright statement that is common in copyright laws around the world9.

Using the © sign makes sense, as it is the the common global denominator.

Comparison between US and Slovenian copyright statements

As an EU example, the Slovenian ZASP §175.(1) simply states that holders of exclusive author’s rights may mark their works with a (c)/© sign in front of their name or firm and year of first publication, which can be simply put as:

© {$year_of_first_publication} {$name_of_author_or_other_copyright_holder}

On the other side of the pond, in the USA, 17 U.S. Code § 401.(b) uses more words to give a more varied approach, and relevant for this question in §401(b)(1) proscribes the use of

the symbol © (the letter C in a circle), or the word “Copyright”, or the abbreviation “Copr.”;

The rest you can go read yourself, but can be summarised as:

(©|Copyright|Copr.) {$year_of_first_publication} {$name_or_abreviation_of_copyright_holder}

See also the note in Why keep the year for why this can matter in front of USA courts.

While the © sign is a pet peeve of mine, from the practical point of view, this is the least important point here. As we established in the introduction, copyright is automatic, so the actual risk of not following the law by its letter is pretty low if you write e.g. “Copyright” instead.

© sign and ASCII

While Unicode (UTF-8, UTF-16, …) is pretty much ubiquitous nowadays, there are places and reasons for when the encoding of source code will have to be limited to a much simpler one, such as ASCII. This could be e.g. in case when the code is written to be put into small embedded devices where every bit counts.

The © character was introduced in 8-bit extended ASCII, but the original 7-bit ASCII does not have it.

So if this is the situation you are in, it is fine to either ommit the copyright sign or replace it with e.g. (C) or Copyright.

Why leave a contact?

A contact is in no way required by copyright law, but from practical reasons can be extremely useful.

It can happen that you need to access the author and/or copyright holder of the code for legal or technical question. Perhaps you need to ask how the code works, or have a fix you want to send their way. Perhaps you found a licensing issue and want to help them fix it (or ask for a separate license). In all of these cases, having a contact helps a lot.

As pretty much all of internet still hinges on the e-mail10, the copyright holder’s e-mail address should be the first option. But anything really goes, as long as that contact is easily accessible and actually in use long-term.

Avoiding orphan works

For the legal geeks out there, a contact to the copyright holder mitigates the issue of orphan works.

There will be cases where the authorship will be very dispersed or lie with a legal entity instead. In those cases, it might be more sense to provide a URL to either the project’s or legal entity’s homepage and provide useful information there. If a project lists copyright holders in a file such as AUTHORS or CONTRIBUTORS.markdown a permalink to that file (in the master) of the publicly available repository could also be a good URL option.

How to handle multitudes of authors?

Here are two examples of what you can write in case the project (e.g. Project X) has many authors and does not have a CAA or exclusive CLA in place to aggregate the copyright in a single entity:

© 2010 The Project X Authors <https://projectx.example/about/authors>

© 1998 Contributors to the Project X <https://git.projectx.example/ProjectX/blob/master/CONTRIBUTORS.markdown>

An an example of when the project is handled by a non-profit NGO legal entity.

© 2020 BestProjectNGO <https://bestprojectngo.example>

Bot to automate contributions

A really interesting project is All Contributors, which specifies how to manage contributions to all – even non-code – contributions to a project. It also includes a CLI tool and offers a GitHub bot to automate this process.

The major downside is that the proscribed format is an HTML table embedded in MarkDown. So not very easy to read or parse in source form.

What if I added code to an existing project?

A major benefit of FOSS is that people collaborate on the same project, so it is inevitable that several people will be touching the same file. If that file already includes a copyright statement, this is a good question.

If there are only a handful of people who wrote that file, it would be fine to just add a new line with your copyright statement, as such:

SPDX-FileCopyrightText: © 2018 Matija Šuklje <>
SPDX-FileCopyrightText: © 2021 Master Hacker <>

But if there are many authors that would need to be added that way, to avoid clutter, it would make sense to instead create an AUTHORS.* or CONTRIBUTORS.* file as described in the question above.

What about public domain?

Public domain is tricky.

In general the public domain are works to which the copyright term has expired11.

While in some jurisdictions (e.g. USA, UK) you can actually waive your copyright and dedicate your work to public domain, in most jurisdiction (e.g. most of EU member countries) that is not possible.

Which means that depending on the applicable jurisdiction, it may be that although an author wrote that they dedicate their work into public domain this does not meet the legal standard for it to actually happen – they retain the copyright in their own work.

Unsurprisingly, FOSS compliance officers and other people/projects who take copyright and licensing seriously are typically very wary of statements like “this is public domain”.

This can be mitigated in two ways:

  • instead of some generic wording, when you want to dedicate something to public domain use a tried and tested public copyright waiver / public domain dedication with a very permissive license, such as 0BSD for code or CC0-1.0 for non-code; and
  • include your name and contact if you are the author in the SPDX-FileCopyrightText: field – 1) because in doubt that will associate you with your dedication to the public domain, and 2) in case anything is unclear, people have a contact to you.

This makes sense to do even for files that you deem are not copyrightable, such as config files – if you mark them as above, everyone will know that you will not exercise your author’s rights (if they existed) in those files.

It may seem a bit of a hassle for something you just released to the public to use however they see fit, without people having to ask you for permission. I get that, I truly do! But do consider that if you already put so much effort into making this wonderful stuff you and donating it to the general humanity, it would be a huge pity that, for (silly) legal details, in the end people would not (be able to) use it at all.

What about minified JS?

Modern code minifiers/uglifiers tend to have an optional flag to preserve copyright and licensing info, even when they rip out all the other comments.

The copyright does not simply go away if you minify/uglify the code, so do make sure that you use a minifier that preserves both the copyright statement as well as the license (at least its SPDX Identifier) – or better yet, the whole REUSE-compliant header.

Transformations of code

Translations between different languages, compilations and other transformations are all exclusive rights of the copyright owner. So you need a valid license even for compiling and minifying.

What is wrong with “All rights reserved”?

Often you will see “all rights reserved” in copyright statements even in a FOSS project.

The cause of this, I suspect, lies again from a copycat behaviour where people tend to simply copy what they so often found on a (music) CD or in a book. Again, the copyright law does not ask for this, even if you want to follow the fullest formal copyright statement rules.

But what it does bring, is confusion.

The statement “all rights reserved” obviously contradicts the FOSS license the same file is released under. The latter gives everyone the rights to use, study, share and improve the code, while the former states that all of these rights the author reserves to themself.

So, as those three words cause a contradiction, and do not bring anything useful to the table in the first place, you should not write them in vain.

Practical example

Imagine12 a FOSS project that has a copy of the MIT license stored in its LICENSE file and (only) the following comment at the top of all its source code files:

# This file is Copyright (C) 1997 Master Hacker, all rights reserved.

Now imagine that someone simply copies one file from that repository/archive into their own work, which is under the AGPL-3.0-only license, and this is also what it says in the LICENSE file in the root of its own repository. And you, in turn, are using this second person’s codebase.

According to the information you have at hand:

  • the copyright in the copied file is held by Master Hacker;
  • apparently, Mr Hacker reserves all the rights they have under copyright law;
  • if you felt like taking a risk, you could assume that the copied file is under the AGPL-3.0-or-later license – which is false, and could lead to copyright violation13;
  • if you wanted to play it safe, you could assume that you have no valid license to this file, so you decide to remove it and work around it – again false and much more work, but safe;
  • you could wait until 2067 and hope this actually falls under public domain by then – but who has time for that.

This example highlights both how problematic the wording of “all rights reserved” can be even if there is a license text somewhere in the codebase.

This can be avoided by using a sane copyright statement (as described in this blog post) and including an unambiguous license ID. ties both of these together in an easy to follow specification.

What if I work for a company, NGO, university?

In many jurisdictions if you are in an employment relationship (at least full employment), your employer would be the one holding the relevant rights.

If the revelant jurisdiction is Slovenian (as an EU example), ZASP §101 (unofficial English translation) says the following:

(1) When copyright work is created by an employee in the execution of his duties or following the instructions given by his employer (copyright work created in the course of employment), it shall be deemed that the economic rights and other rights of the author to such work are exclusively assigned to the employer for the period of ten years from the completion of the work, unless otherwise provided by contract.

(2) On the expiration of the term mentioned in the foregoing paragraph, the rights mentioned in the foregoing paragraph revert to the employee, however, the employer can claim a new exclusive assignment of these rights, for adequate remuneration.

If the relevant jurisdiction is USA this would fall under “work for hire” and the employer would be the copyright holder of any work their employee makes that are within the scope of their employment. There are also other cases where “work for hire” kicks in, but the sloppy rule of thumb is that if the closer the work’s creation was controlled by the employer/hiring party, the more likely it would be the copyright holder.

In any case, if your contract says you are transferring the rights to your employer or the other party, then they would be the copyright holder (e.g. in USA) or at least the exclusive rights holder (e.g. most of EU).

On a similar note, an author / copyright holder / exclusive right holder can transfer the rights they have to another person by written agreement.

What if I want to stay anonymous?

Whether you want to sign your work with your legal name, a pseudonym14 or even not at all is your own decision as author.

But do take into consideration that if you want to stay anonymous, you will have a much harder time proving you are the author of that piece of code later. For this reason, it would make sense to release your anonymous code under a “public-domain-like” license such as CC0-1.0 or Unlicense.

In any case, unless you have good reasons not to (e.g. for your personal safety), it would be really useful to use the copyright tag to at least include a contact. In case you want to just use a pseudonym, that should not be much of an issue. But in the case you want to stay anonymous, the contact could be simply the URL to the project’s homepage and instead of your name you could state the name of the project, or leave it empty.

Anonymity and Git

If you are concerned about anonymity, do take into consideration also that Git stores both author and committer data for each commit. Look into how to keep those records in a way that they cannot be linked to you.

My project uses DCO. Does this conflict with it?

Not at all. Quite the opposite!

When signing the DCO 1.1, you state that you are contributing under the license as stated in the file. If the file you contributed (to), includes an SPDX license tag, that supports the DCO.

While signing the DCO typically requires you to use git commit --signoff when you commit, so it stores your agreement with DCO in the repository history, if a file is copied outside that git repository that information, along with your authorship information is lost. So it makes sense to include your copyright statement and contact in each file even if you sign a DCO.

How do I find out the date of file creation?

If you are creating a new file, this is trivial, as you just need to enter the current year (e.g. with date +Y).

But if you are adding your copyright statements to your existing software, that might indeed be a bit more tricky.

Luckily, if your project uses a VCS and all its history is tracked in it, you can find the date of the first commit for each file. If using Git, the following command will output you the year the file was first authored:

git log --follow --format=%as {$path} | tail -n1 | cut -c-4

Failing that, you could check with your filesystem (e.g. for EXT4), but this can be of very questionable quality, if you know the file landed on your disk at a later date, you changed disks etc.

If even that is not a viable possibility, just use your best judgement.

That is a tricky question, and probably depends on the jurisdiction in question.

This analysis tries to answer those questions from the Slovenian jurisdiction.

hook out → hat tip to the TODO Group for giving me the push to finally finish this article and Carmen Bianca Bakker, Robbie Morrison, as well as the Legal Network for some very welcome feedback

  1. This is presumed to be the author at least initially. But depending on circumstances can be also some other person, a legal entity, a group of people etc. See also this FAQ entry for more info. 

  2. A license is by definition “[t]he permission granted by competent authority to exercise a certain privilege that, without such authorization, would constitute an illegal act, a trespass or a tort.” 

  3. Limitations and exceptions (or fair use/dealings in USA/Canada/UK) in copyright are extremely limited when it comes to software compared to more traditional media. Do not rely on them. 

  4. In USA, the copyright statement is often called a copyright notice. The two terms are used intercheangably. 

  5. E.g. the 5 SLOC rule of thumb means that any contribution that is 5 lines or shorter, is (likely) too short to be deemed copyrightable, and therefore can be treated as un-copyrightable or as in public domain; and on the flip-side anything longer than 5 lines of code needs to be treated as copyrightable. This rule can pop up when a project has a relatively strict contribution agreement (a CLA or even CAA), but wants some leeway to accept short fix patches from drive-by contributors. The obvious problem with this is that on one hand someone can be very original even in 5 lines (think haiku), while one can also have pages and pages of absolute fluff or just plain raw factual numbers. 

  6. This depends from jurisdiction to jurisdiction. The Berne convention stipulates at least 50 years after death of the author as the baseline. There are very few non-signatory states that have shorter terms, but the majority of countries have life + 70 years. The current longest copyright term is life + 100 years, in Mexico. 

  7. The only improvement is that it avoids messing up the Git/VCS history. 

  8. In practice what the Author field in a Git repository actually includes varies quite a bit and depends on how the committer set up and used Git. 

  9. Of course, I did not go through all of the copyright laws out there, but I checked a handful of them in different languages I understand, and this is the pattern I identified. If anyone has a more thorough analysis at hand, please reach out and I will happily include it. 

  10. Just think about it, pretty much every time you create a new account somewhere online, you are asked for your e-mail address, and in general people rarely change their e-mail address. 

  11. As stated before, in most jurisdictions that is 70 years after the death of the author. 

  12. I suspect many of the readers not only can imagine one, but have seen many such projects before ;)

  13. Granted, MIT code embedded into AGPL-3.0-or-later code is less risky than vice versa. But simply imagine what it would be the other way around … or with an even odder combination of licenses. 

  14. A(n identifiable) pseudonym, under copyright law, has basically the same power as a legal name. Think of all the musicians, actors and writers that we know under their pseudonym or stage name. 

Sunday, 1 September 2019

Now it’s the end of Google Summer of Code 2019. As my GSoC project, the port of KDE Connect on macOS has made great progress. You can find and download it in my blog release page.

Note: This post aims at presenting the features of KDE Connect which have been implemented on macOS. If you’d like to know more information, such as compilation of your own KDE Connect binary on macOS, please turn to another post in my post Connect your Android phone with your Mac via KDE Connect. And if you’re interested in what I’ve done during Google Summer of Code, my status report of Google Summer of Code is HERE.


In this chapter, I’d like to give you a preview of all features, as well as how to configure to make some of functions work.

Launch KDE Connect

First, we can click on KDE Connect application - the to open it.

Then, we can open KDE Connect configuration window from the indicator in the tray bar of macOS.

As you can see, this is the main page of KDE Connect. All available plugins are here, you can enable/disable or configure them. In addition, available devices will be listed on the left, you can choose them to pair/unpair with them/it.


Pair notification

When you pair from your Andoid Phone, you should be able to receive a notification that shows the pair request. You can accept or reject it in the KDE Connect configuration window, or you can do it with KDE Connect indicator tray icon, there would be an entry for the pair request as well.

Otherwise, if you change the notification type of KDE Connect to alert in the system preference, you should also be able to do a quick action with the notification itself. Just as I showed in Enable notification plugin in KDE Connect on macOS.

Once paired, you can enjoy your adventure on macOS with KDE Connect!

Clipboard synchronization

The text that you copy on your Mac will be shared to your phone, and those you copy on your phone will be also synchronized to your Mac.

Notification synchronization

With KNotifications support for macOS, you can receive notification from your Android phones and react to them. You can ping your Mac to test whether they are well connected.

Sending file

Sharing your file on your Mac with your Android phone is also a basic feature. You could also send a file from your Android phone, by default, the file will be saved in the Downloads folder in your Mac.

System Volume

You can control the system value of your Mac from your Android Phone remotely.


With my SFTP browser, you can browse files in your Android Phone from your Mac, easily synchronize a file.


Thanks to SMS application of Simon Redman, sending and receiving SMS on your Mac are possible!

Running command

Run command from your Android phone. I believe that using AppleScript, more and more things that KDE Connect can do on macOS, will be discovered, maybe by you!

Mouse and Keyboard

You should be able to use your Android phone as a temporary trackpad and a keyboard. But it needs your permission to allow your Android phone to do it on your Mac. The GIF above shows how to do that.


Except the functions shown above, you can also do these from your Android phone:

  • Keep your Mac awake when your phone is connected
  • Use your phone to control your slides during a presentation
  • Check the battery level of your phone
  • Ring your phone to help find it

And, you may have noticed that, in the screen capture, there are KDE Connect in dark mode and in light mode. Thanks to Qt, we are able to benefit it.

Furthermore, there is no doubt that more functions will be delivered and released in the future. We are all looking forward to them.


There are some issues that we’ve known and we are trying to fix them.

The released application package isn’t notarized and still has some lirary reference issues. So, it requires you to manually open it, if it’s rejected by Gatekeeper(package validator on macOS), like that showed in the image above.

We’ll try to fix all issues and make a release which you can run it without barricade.


Thanks to KDE Community and Google, I could finish this Google Summer of Code project this summer.

Thanks to members in KDE Connect development. Without them, I cannnot understand the mechanism and get it work on macOS so quickly :)


If you have any question, KDE Connect Wiki may be helpful. And you can find a bug tracker there.

Don’t be hesitated to join our Telegram Group or IRC channel if you’d like to bring more exciting functions into KDE Connect:

  • Telegram
  • IRC (#kdeconnect)
  • (

I wish you could enjoy the seamless experience provided by KDE Connect for macOS and your Android Phone!

Wednesday, 16 November 2016

Μετά από το post μου με τίτλο: "Συναντήσεις μου με famous και λιγότερο famous σε συνέδρια και όχι μόνο", σκέφτηκα να ψάξω και ομαδικές φωτογραφίες από τα συνέδρια του εξωτερικού που έχω συμμετάσχει ως ανάμνηση. Υπάρχουν και τα συνέδρια FOSSCOMM στην Ελλάδα, αλλά ίσως γράψω κάτι όταν πλησιάζει ο καιρός να συμμετάσχω στο επόμενο FOSSCOMM.

Έχουμε και λέμε:


Desktop Summit

Το desktop summit διεξήχθη για τελευταία φορά το 2011 στο Βερολίνο. Είναι η πρώτη φορά που επισκέπτομαι το Βερολίνο. Επίσης είναι η πρώτη φορά που βγαίνω στο εξωτερικό μετά από ένα χρόνο που είχαμε ξεκινήσει την κοινότητα openSUSE στην Ελλάδα μαζί με τον Κώστα.

Desktop Summit Group Picture


Το 2012 συμμετείχα ως εθελοντής στο παγκόσμιο συνέδριο openSUSE στην Πράγα. Συμμετείχαμε πολλοί Έλληνες (δείτε παρακάτω) επειδή την επόμενη χρονιά θα διοργανώναμε στην Θεσσαλονίκη το αντίστοιχο συνέδριο.

Έλληνες στο συνέδριο openSUSE 2012

Η ομάδα των Ελλήνων
Το συνέδριο ήταν συνδιοργάνωση με άλλα 2 συνέδρια.

Συνέδριο openSUSE 2012


Την χρονιά αυτή, το παγκόσμιο συνέδριο openSUSE διοργανώθηκε στην Θεσσαλονίκη. Συμμετείχα ενεργά τόσο στην οργάνωσή του όσο και στην διάρκειά του, με την διαχείριση των μέσων κοινωνικής δικτύωσης.

Συνέδριο openSUSE 2013


Το παγκόσμιο συνέδριο openSUSE διοργανώθηκε στο Dubrovnik στην Κροατία. Έχοντας αποκτήσει εμπειρία, μου ανατέθηκε ο ρόλος των μέσων κοινωνικής δικτύωσης.

υνέδριο openSUSE 2014


Το 2015 συμμετείχα στο συνέδριο ownCloud στο Βερολίνο. Ήταν η χρονιά που είχα κάνει πολλές παρουσιάσεις και αρκετή προώθηση του ownCloud στην Ελλάδα. Είχα κερδίσει την συμμετοχή μου στο συνέδριο μέσω της πλατφόρμας προώθησης που χρησιμοποιούσε εκείνη την εποχή το ownCloud.

Συνέδριο ownCloud 2015


Το 2016 συμμετείχα σε δυο συνέδρια. Ο λόγος ήταν ο διαχωρισμός-διάσπαση σε ownCloud και Nextcloud (είναι δυο διαφορετικές εταιρίες με δυο εντελώς διαφορετικά projects).

Αρχικά ως προσκεκλημένος του ownCloud.

Συνέδριο ownCloud 2016

Στη συνέχεια ως προσκεκλημένος-εθελοντής του Nextcloud.

Συνέδριο Nextcloud 2016


Το 2017 συμμετείχα στο συνέδριο Nextcloud στο Βερολίνο. Ήταν ιδιαίτερη χαρά μου γιατί συμμετείχαν και 2 Έλληνες μαζί μου.

Συνέδριο Nextcloud 2017


FOSDEM, 3 & 4 Φεβρουαρίου, Βρυξέλλες. Συμμετοχή με το Nextcloud...

FOSDEM 2018 με Nextcloud

Συνέδριο Nextcloud, 23 - 30 Αυγούστου, Βερολίνο.

Συνέδριο Nextcloud 2018

Συνέδριο ownCloud, 18 - 21 Σεπτεμβρίου, Νυρεμβέργη.

Συνέδριο ownCloud 2018

Συνέδριο GNU Health, 23 - 25 Νοεμβρίου, Λας Πάλμας.

Συνέδριο GNU Health 2018


Συνέδριο openSUSE, 23-24 Μαΐου 2019 στη Νυρεμβέργη.

openSUSE conference 2019, May 23-24, Nuremberg

Συνέδριο GUADEC, 23-28 Αυγούστου, Θεσσαλονίκη

GUADEC 2019 Θεσσαλονίκη

Συνέδριο Nextcloud, 12-21 Σεπτεμβρίου, Βερολίνο.

Συνέδριο Nextcloud 2019 στο Βερολίνο


FOSDEM, 1 & 2 Φεβρουαρίου, Βρυξέλλες. Συμμετοχή με το Nextcloud...

FOSDEM 2020 with Nextcloud

Σύντομα θα ακολουθήσουν και άλλα...

Friday, 14 October 2016

One afternoon twenty years ago Matthias Ettrich and Martin Konold sat at a stone table in the cafeteria of the university Tübingen and talked computers. They talked Linux and they talked desktop. They talked about making Linux accessible to everyone. This was the moment where KDE was born. This afternoon they walked away with a mission. Matthias went on to write the call to action to found the KDE project, and Martin to create the very first KDE mailing list

On October 14th 1996 the famous announcement arrived on the newsgroups comp.os.linux.development.apps, comp.os.linux.misc, and de.comp.os.linux.misc:

    New Project: Kool Desktop Environment. Programmers wanted!

The new project quickly attracted a group of enthusiastic developers and they pushed out code with a frentic pace. kdelibs-0.0.1 was released in November, containing the first classes KConfig and KApplication. In May 1997 the young project presented at the Linux-Kongress in Würzburg. In August Kalle Dalheimer published the famous article about KDE in the German computer magazine c't which attracted a whole generation of KDE developers to the project. On Jul 12th 1998 KDE 1.0 was done and released. The community had not only implemented a friendly face for Linux but also a bunch of applications while going, including a full web browser.

KDE did hundreds more releases over the years, continuously improving and maintaining the growing number of applications and amount of code. The community grew. It started to do annual conferences such as Akademy or the Desktop Summits and focused developer sprints such as the Osnabrück or the Randa meetings. KDE e.V., the organization behind KDE, which was founded as partner for the KDE Free Qt Foundation, grew with the community to be the corner stone of the organizational structure of KDE, using German association law as its secret superpower (read more about this in the book "20 Years of KDE: Past, Present and Future").

Millions and millions of people used KDE software over the years. Thousands of people contributed. KDE made appearances in Hollywood movies, it was subject of theses and scientific studies, and it won many awards. KDE's founder, Matthias Ettrich even received the German Federal Cross of Merit. The timeline of twenty years of KDE is an impressive demonstration of what Free Software is able to achieve.

Akademy 2014 group photo by Martin Holec (CC-BY)

KDE also was a breeding ground. Many people started their careers there. Hundreds of students went through mentoring programs such as the Summer of Code or the Season of KDE. Whole projects emerged from KDE, such as ownCloud and its sibling NextCloud, Kolab, or KHTML, which turned into WebKit and then Blink, powering most of web browsers on this planet today.

Today Linux has reached world domination in various, sometimes surprising, ways. KDE has contributed its share to that. With Plasma it provides a slick and powerful desktop which does make Linux accessible to everyone. This mission has been accomplished. But there is more. Following KDE's vision of bringing freedom to people's digital life there are amazing projects exploring new areas through Free Software, be it an application such as Krita to bring freedom to digital painters, or a project such as WikiToLearn to create collaborative text books for education. When KDE people meet you can feel the enthusiasm, the openness, and the commitment to change the world to the better just as in the days of the beginning.

I joined KDE in 1999 with my first patch to KOrganizer. I wrote a lot of code, maintained and founded applications, served on the board of KDE e.V. for nine years. Most importantly I found a lot of friends. Neither my personal nor my professional life would be what it is today without KDE. I owe a lot to this community. Thank you for the last twenty years.

Monday, 9 May 2016




On May 5th night, we had a hangout call with our project mentors and other GSoC students of WikiToLearn team.
This is the first hangout call we had with respect to GSoC.

We discussed the following things :

* Having a blog account and keep updating the progress in it. Also to find a way to mirror our blog and WikiToLearn wiki page to keep track of everything.

* Gianluca explained about the need of KDE account, Phabricator.

* All our current source code are hosted on Github, we may move to KDE QuickGit someday soon.

* We discussed our project proposals. We felt it will be a good idea if we inform about our project ideas to upstream contributors, MediaWiki contributors so that they could help us if we have any problem with respect to MediaWiki extension development.

* Make use of WikiToLearn tech channel effectively for every technical problem because we have experienced people there who could help us to solve it.

Things which I have done till now :

* Created an account on KDE identity.

* Got KDE developer access.

* Aggregated my Blog with KDE planet.

* Have an account on Phabricator.

* Have an account on KDE Bugtracking System. (WikiToLearn team doesn’t use it much.)

* Updated my user page on WikiToLearn.

* Created a doc which shows a list of days and hours I’ll be working/taking off.

* Running MediaWiki instance locally in my system.

* Installed and enabled VisualEditor. (Playing with it)

* Spending some amount of time in configuring Parsoid server. (I need to link VisualEditor and Parsoid server so that they talk each other and enables me to create and save wiki pages.)


MediaWiki with VisualEditor

Things I’ll work on next :

* Configure Parsoid server.

* Design workflow scheme for collaborative editor extension.

* Try out some simple VE extensions.


Friday, 22 April 2016


Something I’ve wanted to say for more than a year. Yes! I am a GSoCer now!
This was one among my biggest dreams. 🙂

GSoC – Google Summer of Code is an annual program, in which Google awards healthy stipends to students for contributing to Open Source projects.

All these days, I was spending most of my time fixing bugs on different open source projects. Now I have got the opportunity to work with WikiToLearn,  a proud member of KDE community, for a long period of time, implementing a new feature to wiki editor.

I would like to tell a bit about our WikiToLearnWikiToLearn wants to provide free, collaborative and accessible textbooks to the whole world.
Our philosophy is synthesized in the sentence: “knowledge only grows if shared”. We provide a platform where learners and teachers can together complete, refine and re-assemble notes, lecture notes in order to create textbooks, tailored precisely to their needs so that you can “stand on the shoulders of giants”.

I should thank my mentors Cristian Baldi, Gianluca Rigoletti  and other community members for helping me in reviewing and getting a great project proposal done. I’m really excited to work with them this summer. 🙂

Looking at previous GSOCers like Sayan, Sagar, Vignesh, Parth was always motivating me to contribute to open source and become a GSoCer.
I thank F.S.M.K, DGPLUG, and our GLUG-DSCE which taught me a lot about free/open source technologies.

More love to WikiToLearn  folks for giving me this opportunity to work with them. 🙂


You can have a look at my proposal abstract here.
Soon I’ll push my complete project proposal on GitHub.

The real fun begins now. 🙂

Tuesday, 19 January 2016

Καλώς ήλθες στον μαγικό κόσμο του openSUSE. Δεν είναι μια απλή διανομή που θα σε βοηθήσει να χρησιμοποιήσεις τον υπολογιστή σου. Εκτός του προφανούς, θα βρεις σίγουρα διάφορα εργαλεία να δουλέψεις αλλά και μια κοινότητα ατόμων που θα σε ενθουσιάσει. Αφού επέλεξες την διανομή openSUSE, μάθε λίγο για το πως θα το γράφεις σωστά (openSUSE) καθώς και μια μικρή προϊστορία. Πολλοί είναι οι άσχετοι που λένε ότι θέλουν.

Γιατί επέλεξες την διανομή openSUSE; Μερικοί λόγοι υπάρχουν στον Οδηγό προς ναυτιλομένους νέους χρήστες στο openSUSE.

Αρχικά τι έκδοση επέλεξες; Επέλεξες την σταθερή Leap ή την κυλιόμενη Tumbleweed; Να ξεκαθαρίσω λίγο το τοπίο.

1. Και οι δυο, είναι σταθερές εκδόσεις. Η κυλιόμενη δεν είναι η δοκιμαστική της σταθερής (όπως λανθασμένα πιστεύουν μερικοί). Όσοι έχουν δοκιμάσει άλλες διανομές, ΜΗΝ συγκρίνετε τις άλλες διανομές με την openSUSE.
Η Arch Linux είναι κυλιόμενη διανομή. Δεν αποτελεί δοκιμαστική έκδοση κάποιας άλλης "σταθερής" έκδοσης της διανομής.
Η Ubuntu LTS δεν αποτελεί την ανά 5 χρόνια σταθερή έκδοση του Ubuntu και οι ενδιάμεσες αποτελούν τις δοκιμαστικές. Η κοινότητα Ubuntu τις προωθεί εξίσου. Απλά είναι δυο εκδόσεις με διαφορετικό target group.

2. Η άποψη ότι αν βάλεις μια κυλιόμενη έκδοση να περιμένεις να σου σπάσει το σύστημά σου και μετά να βάλεις Ubuntu, την λένε συνήθως άτομα που δεν γνωρίζουν ή τους έχει πει κάποιος έμπειρος φίλος τους (που δεν έχει χρησιμοποιήσει άλλη διανομή εκτός από Ubuntu). Αρχικά για να έχει επιλέξει μια διανομή να έχει κυλιόμενο κύκλο, σημαίνει ότι τα προγράμματα-πακέτα, τα έχει δοκιμάσει σε ένα δοκιμαστικό αποθετήριο, έχει δοκιμαστεί και εφόσων δεν έχει παρατηρηθεί bug, τότε το βγάζουν στην κυκλοφορία στην "σταθερή" εκδοσή τους. Όσον αφορά το Tumbleweed, πριν μπει το πακέτο στο δοκιμαστικό αποθετήριο, δοκιμάζεται πρώτα από ανθρώπινο χέρι και στη συνέχεια απο μηχανή. Όταν μπει στο δοκιμαστικό αποθετήριο (Factory). Όταν δοκιμαστεί από πολλούς χρήστες και είναι ΟΚ για μαζική χρήση, τότε περνάει από έναν έλεγχο από άτομο και στη συνέχεια από μηχανή και τότε περνάει στο αποθετήριο της κυλιόμενης έκδοσης. Αυτό σημαίνει ότι έχει περάσει από πολλούς ελέγχους πριν βγει σε χρήση. Σε περίπτωση που το σύστημά σου έχει πρόβλημα, το πιο πιθανό είναι να έχεις κάποιο conflict με κάποιο από το hardware σου. Καλό θα είναι να κάνεις bug report για να διορθωθεί με την επόμενη αναβάθμιση.

3. Η διανομή openSUSE είναι ξακουστή για το KDE. Η τελευταία σταθερή έκδοση (που έχει την βάση από το εμπορικό κομμάτι της SUSE), έχει αναφερθεί με προβλήματα στο KDE Plasma 5 (αν το γράφω σωστά). Αντιθέτως το GNOME δουλεύει μια χαρά. Γιατί συμβαίνει αυτό; Μια εξήγηση μπορεί να είναι ότι εμπορική έκδοση SUSE που διατίθεται για desktop υπολογιστές, έχει ως βασικό γραφικό περιβάλλον το GNOME και αυτό έχουν δοκιμάσει και συντηρούν οι υπάλληλοι της SUSE (βέβαια το εμπορικό προϊόν διαθέτει διαφορετική έκδοση GNOME καθώς και μια custom έκδοσή του, σε σχέση με την έκδοση openSUSE Leap). Το KDE από την άλλη δεν το έχει αναλάβει κάποιος υπάλληλος της SUSE να το συντηρεί για το εμπορικό προϊόν SLED.
Αντιθέτως, η έκδοση Tumbleweed παίρνει τις ενημερώσεις επόμενων εκδόσεων, οπότε διορθώνεται πιο γρήγορα ότι bug υπάρχει.
Επομένως, εάν θέλεις να χρησιμοποιήσεις KDE, προτίμησε την Tumbleweed ενώ αν θέλεις GNOME μπορείς να χρησιμοποιήσεις και την Leap. Εάν πάλι θέλεις να χρησιμοποιήσεις άλλο γραφικό περιβάλλον, εξαρτάται εάν θέλεις να έχεις πάντα την τελευταία έκδοση που κυκλοφορεί ή αν σε ενδιαφέρουν μόνο οι ενημερώσεις ασφαλείας.

4. Σε περίπτωση που θέλεις να χρησιμοποιήσεις server, τότε πας καρφωτά σε Leap. Ο λόγος προφανής. Παίρνεις ενημερώσεις ασφαλείας καρφωτά από την SUSE. Ότι παίρνουν οι πελάτες της, παίρνεις και εσύ. Επίσης είναι και μακράς υποστήριξης, οπότε είναι ότι καλύτερο.

5. Πολλοί έχουν διαμαρτυρηθεί γιατί η Leap δεν έχει 32bit έκδοση. Στην χώρα μας έχουμε κατά κύριο λόγο παλιούς υπολογιστές και θα ήταν καλό να χρησιμοποιηθεί μια σταθερή έκδοση με μακρά υποστήριξη, πόσο μάλλον αν αυτά τα παλιά μηχανάκια τα χρησιμοποιούν για μικρο-server. Εδώ υπάρχει ένα δίκιο αλλά η τεχνολογία 32bit έχει παιθάνει. Όλοι προτιμούν την 64bit. Οπότε θα με ρωτήσετε, και εμείς με τα 32bit μηχανάκια, τι θα κάνουμε; Η απάντηση είναι Tumbleweed. Η κυλιόμενη έκδοση βγαίνει και σε 32bit αρχιτεκτονική. Θα βρείτε σε Live μορφή τόσο το KDE όσο και το GNOME. Η αλήθεια είναι ότι για να εκτελέσετε τόσο το KDE όσο και το GNOME θα χρειαστείτε τόσο επεξεργαστική ισχύη όσο και μνήμη. Οι 32bit υπολογιστές δεν διαθέτουν και τα δυο μαζί. Οπότε καλύτερα να επιλέξετε γραφικό περιβάλλον μεταξύ XFCE, LXDE, MATE, Englightenment. Προσωπικά προτιμώ το MATE αν και δεν υπάρχει ως επιλογή στον εγκαταστάτη. Πρέπει να το προσέσετε πριν πατήσετε το κουμπί εγκατάσταση και μετά την επανεκκίνηση να ανοίξετε το YaST και να δηλώσετε το MATE ως γραφικό περιβάλλον. Το Enlightenment είναι αυτό που καταναλώνει την λιγότερη μνήμη.
Παλιότερα υπήρχε ως επιλογή και το αποθετήριο Evergreen, έργο της κοινότητας που είχε στόχο τους servers. Συνήθως κρατούσε ακόμα 1-2 χρόνια μετά τον επίσημο κύκλο ζωής μιας έκδοσης. Τελευταία έκδοση που είχε ανακοινωθεί ήταν η 13.1 αλλά συζητούνται πολλά με την έλευση της Leap.

6. Ο μύθος της μακράς υποστήριξης...
Αυτό είναι μύθος για τους χρήστες. Η μακρά υποστήριξη χρειάζεται ΜΟΝΟ για επαγγελματικό σκοπό. Για server και για κάποιο παραγωγικό μηχάνημα, τα οποία θα σου αποφέρουν χρήματα.
Εγώ που είμαι τελικός χρήστης, θέλω να έχω πάντα το τελευταίο GNOME (μιας και μεταφράζω το GNOME). Παλιότερα χρειαζόταν να βάλω πχ αποθετήρια που είχαν τη νέα έκδοση GNOME και σε αρκετές περιπτώσεις το σύστημά μου χαλούσε. Άλλες φορές χρειαζόταν να κάνω αναβάθμιση σε νέα έκδοση της διανομής. Όσες φορές δοκίμασα σε Ubuntu και Fedora, χρειάστηκε να κάνω φρέσκια εγκατάσταση γιατί το σύστημά μου ήταν υπερβολικά αργό και άλλες φορές δεν άνοιξε καν. Μόνο στο openSUSE κατάφερα να κάνω αναβάθμιση από μια έκδοση σε άλλη χωρίς προβλήματα.
Ας μην πάρουμε εμένα ως παράδειγμα. Δεν έχω δει πολλούς χρήστες που μου λένε θέλω να βάλω την Ubuntu LTS και να την ξεχάσω για τα 5 χρόνια. Στο facebook έχω συναντήσει άτομα που βάζουν την LTS έκδοση την 14.04 την .3 (δηλαδή έχουν βγάλει ένα ενημερωμένο ISO για 3 φορές). Έχω δει μόνο έναν φίλο να έχει εγκαταστήσει την 8.04 στο laptop του και την πήγε τουλάχιστον 4 χρόνια. Η αλήθεια είναι ότι στα 2 χρόνια μέσο όρο, οι περισσότεροι επιλέγουν να κάνουν αναβάθμιση σε νέα έκδοση (είτε αυτή είναι η κανονική, είτε η LTS). Ο λόγος που το κάνουν είναι οι νέες τεχνολογίες και τα προγράμματα που συνήθως δεν έχει η παλιά LTS.
Στο openSUSE, η Leap έχει πάρει τον κύκλο ζωής του SLE. Τώρα είναι η έκδοση 42.1 που σημαίνει ότι συμβαδίζει με το SLE SP1. Όταν βγει το SLE SP2, θα βγει η επόμενη έκδοση 42.2. Αυτό γίνεται συνήθως ανά 3-5 χρόνια.

Αφού διάβασες όλα τα παραπάνω, εγώ αν ήμουν στην θέση σου, αυτές είναι οι επιλογές μου:

- Server: openSUSE Leap
- Παραγωγικό μηχάνημα Desktop: openSUSE Leap με XFCE ή MATE
- Desktop/laptop: openSUSE Tumbleweed 64bit με GNOME ή KDE
- Παλιό 32bit Desktop: openSUSE Tumbleweed 32bit με XFCE, LXDE, MATE ή Enlightenment (εξαρτάται τον χρήστη)

Ότι και να επιλέξεις, μπορείς να ακολουθήσεις έναν οδηγό πρώτων ενεργειών μετά την εγκατάσταση του Leap.

Saturday, 11 January 2014

Ποια είναι η καλύτερη διανομή για νέο χρήστη;

Η παραπάνω ερώτηση ίσως να μην μπορεί να απαντηθεί αντικειμενικά από advanced χρήστες ή ακόμα και απλούς χρήστες ελεύθερου λογισμικού που το χρησιμοποιούν χρόνια. Ο λόγος που δεν μπορεί να απαντηθεί είναι διότι όλοι μας έχουμε κατασταλάξει σε ότι διευκολύνει εμάς, πράγμα που μπορεί να μην διευκολύνει κάποιον που τώρα ξεκινά στον χώρο του Linux. Έτσι, οι σκέψεις που θα αναπτύξω παρακάτω, είναι απλά η εμπειρία μου.

Η παραπάνω ερώτηση μπορεί να διατυπωθεί και ως: Ποια είναι η καλύτερη διανομή σε παραγωγικό περιβάλλον εργασίας;
Ίσως οι 2 (πανομοιότυπες) ερωτήσεις δεν είναι σωστά διατυπωμένες.
* Ίσως η καλύτερη ερώτηση θα ήταν: Ποιο γραφικό περιβάλλον είναι πιο καλό-παραγωγικό για τους χρήστες;
* Επίσης πρέπει να πάρουμε υπόψιν μας και τον παράγοντα εμπειρία. Τι εμπειρία έχει ο χρήστης; Ίσως και από τι λειτουργικό έρχεται (windows-MAC OSX);
* Αυτό που δεν θα ασχοληθώ είναι με τα χαρακτηριστικά του υπολογιστή του χρήστη.

Πριν προχωρήσω στην ανάλυση των σκέψεών μου, θα ήθελα να αναφέρω ότι έχω χρησιμοποιήσει στο παρελθόν τις διανομές kUbuntu, Ubuntu, Fedora, PCLinuxOS, Linux Mint, openSUSE, Arch Linux. Από γραφικά περιβάλλοντα έχω χρησιμοποιήσει 50% Gnome, 20% MATE, 15% Cinnamon, 10% KDE, 5% Unity (τα ποσοστά είναι χρόνος χρήσης). Τέλος, στα δεδομένα που αναφέρω, είναι όπως τα χρησιμοποίησα. Από τότε μπορεί να έχουν αλλάξει-βελτιωθεί.

Θα ξεκινήσω με τα πιο συχνά λάθη που κάνουμε οι χρήστες Linux.

1. Μετά την εγκατάσταση, η διανομή απλά δουλεύει.

Κλασικό λάθος. Μια διανομή Linux δεν πρόκειται να την εγκαταστήσει μόνος του ο "νέος" χρήστης. Ελάχιστες φορές έχω συναντήσει χρήστες που "παιδεύονται" μόνοι τους να εγκαταστήσουν μια διανομή. Πόσο μάλλον να προσπαθήσουν μόνοι τους για dual boot. Μέχρι στιγμής έχω συναντήσει 1-2 άτομα να το κάνουν αυτό. Και πάλι μετά την εγκατάσταση, επικοινώνησαν μαζί μου διότι είτε ήθελαν βοήθεια στην δημιουργία partition, είτε κάποιο υλικό δεν αναγνωρίζεται. ΠΑΝΤΑ εμείς είμαστε που εγκαθιστούμε την διανομή. Το ότι βάζεις Ubuntoειδή διότι βλέπει όλες τις συσκευές, είναι ΜΥΘΟΣ. Εάν τις έβλεπε, δεν θα υπήρχε λόγος ύπαρξης του Jockey (εάν δεν κάνω λάθος). Αφού εμείς θα εγκαταστήσουμε την διανομή, ότι υλικό δεν θα δει, το εγκαθιστούμε.

2. Προτείνουμε την διανομή με την μεγαλύτερη κοινότητα ώστε να υπάρχει υποστήριξη.

Ακόμα ένα κλασικό λάθος. Σε περίπτωση που ο χρήστης αντιμετωπίσει ένα πρόβλημα, ΔΕΝ πρόκειται να ψάξει στο google ή να μπει στο forum (δεν συζητάμε για λίστα ή IRC), ώστε να διατυπώσει το ερώτημά του (άσε που δεν θα ξέρει τι πρόβλημα έχει). Αυτό που θα κάνει είναι να σου τηλεφωνήσει και να σου πει: ΔΕΝ ΔΟΥΛΕΥΕΙ ΤΟ INTERNET. Και εσύ πρέπει να σκεφτείς τι πάει να πει ο ποιητής με την φράση αυτή. Στην Ελλάδα η κοινότητα Ubuntu έχει την μεγαλύτερη βάση δεδομένων σε οδηγούς στο forum, όμως ο χρήστης εσένα θα τηλεφωνήσει.

3. Σε νέο χρήστη (ή πελάτη σου), βάζεις Unity γιατί τα έχει όλα στο launcher.

Αυτό είναι ΤΕΡΑΣΤΙΟ σφάλμα. Ένας χρήστης που έρχεται από windows, έχει συνηθίσει ΕΝΑΡΞΗ (ή εικονίδιο windows)>ΟΛΑ ΤΑ ΠΡΟΓΡΑΜΜΑΤΑ>ΠΡΟΓΡΑΜΜΑ (το οποίο μπορεί να βγάλει και στην επιφάνεια εργασίας για να του έρθει πιο εύκολα ή στην task bar, ως συντόμευση). Επίσης γνωρίζει ότι για να απενεργοποιήσει τον υπολογιστή, θα πάει πάλι στην ΕΝΑΡΞΗ>ΤΕΡΜΑΤΙΣΜΟΣ ΥΠΟΛΟΓΙΣΤΗ. Ο δε χρήστης MAC OSX (στην περίπτωση που θέλει να αντικαταστήσει το MAC OSX), γνωρίζει ότι όλες οι εφαρμογές του είναι είτε στην κάτω μπάρα, είτε στο applications). Για να σβήσει τον υπολογιστή του, απλά πάει επάνω αριστερά, στο μηλαράκι, και το σβήνει. Δεν θα ασχοληθώ πολύ με χρήστες MAC διότι πιστεύω το 99% των χρηστών είτε έχει περάσει πρώτα από windows, είτε έχει χρησιμοποιήσει στο σχολείο, σε φίλο του κλπ.

Ας δούμε λοιπόν τώρα ένα ένα τα γραφικά περιβάλλοντα (διότι δεν παίζει ρόλο η διανομή).

* KDE: Είναι πιο κοντά στα δεδομένα των χρηστών windows. Υπάρχει βίντεο στο YouTube κάποιων που κάνανε "έρευνα" στο δρόμο, λέγοντας σε απλούς ανθρώπους ότι αυτά είναι τα νέα windows και τους ήταν πολύ οικείο το περιβάλλον και τους άρεσε. Έχει λοιπόν το κουμπάκι K (ή το λογότυπο της κάθε διανομής), όπου ο χρήστης ενστικτωδώς θα πατήσει. Εκεί λοιπόν με τον ίδιο τρόπο με τα windows, μπορεί να βρει τα προγράμματα και την απενεργοποίηση. Στην task bar, μπορεί να βλέπει ποια προγράμματα έχει ανοικτά. Τέλος έχει συντομεύσεις στην task bar καθώς και στην επιφάνεια εργασίας.

KDE Plasma

* Cinnamon: Και αυτό είναι αρκετά κοντά στα δεδομένα των χρηστών windows. Αντί για ΕΝΑΡΞΗ, θα δει το Μενού (που φωνάζει: Κάνε κλικ εδώ). Στο μενού που θα εμφανιστεί, μπορεί να ανοίξει τα προγράμματα, να απενεργοποιήσει τον υπολογιστή, να βάλει συντομεύσεις στην task bar καθώς και να έχει αγαπημένα προγράμματα που ξεκινάει πιο συχνά αλλά να βλέπει και ποια προγράμματα έχει ανοικτά. Επίσης και εδώ, μπορεί να έχει συντομεύσεις στην επιφάνεια εργασίας.


* MATE: Το αυθεντικό MATE, ίσως να μπερδέψει λίγο τους χρήστες. Όμως θα δουν την λέξη Εφαρμογές και πατώντας επάνω της, θα εμφανίστούν τα προγράμματα. Εάν είναι "πειραγμένο" με την μπάρα κάτω και το traditional menu, τότε θα είναι πιο εύκολο για τους χρήστες να το παρομοιάσουν με windows. Στο αυθεντικό MATE υπάρχει μια δυσκολία που βρίσκεται το κουμπί απενεργοποίησης. Όλα τα άλλα, είναι πλήρως πραγματοποιήσιμα όπως και τα 2 παραπάνω γραφικά.


* GNOME: Είναι το γραφικό περιβάλλον που χρησιμοποιώ και με βολεύει. Το ατόφιο περιβάλλον δεν είναι πολύ φιλικό για χρήστες windows. Η πρώτη κίνηση θα είναι να πατήσουν στο Δραστηριότητες (ακούγεται λογικό να είναι εκεί τα προγράμματα). Την hot corner ίσως την βρει τυχαία (όταν θα πάει το ποντίκι στο Δραστηριότητες). Όμως πατώντας στις Δραστηριότητες θα δει μόνο τα αγαπημένα στην μπάρα. Πρέπει να τα πατήσει όλα ένα ένα ώστε να του εμφανίσει το τελευταίο (Εμφάνιση Εφαρμογών) για να δει όλα τα εικονίδια των εγκατεστημένων εφαρμογών. Θέλει ρύθμιση για δημιουργία συντομεύσεων στην επιφάνεια εργασίας. Ο σχεδιασμός του GNOME έγινε έτσι ώστε ο χρήστης να εστιάζει σε ένα πρόγραμμα που δουλεύει. Έτσι δεν υπάρχει μπάρα να δει ποια προγράμματα έχει ανοικτά (μόνο εάν πατήσει στο Δραστηριότητες). Οπότε αυτό είναι κάτι που θα μπερδέψει πολλούς χρήστες. Για την απενεργοποίηση επίσης είναι σε δύσκολη θέση (σύμφωνα με αυτά που συνήθισε στα windows). Το όλο σύστημα γίνεται πιο φιλικό με την εγκατάσταση κάποιων extensions αλλά και κάποιων ρυθμίσεων από το gnome-tweak-tool.


* Unity: Εδώ εμφανίζονται στο launcher οι εφαρμογές που θεωρεί ο κατασκευαστής ότι είναι πιο συχνά χρησιμοποιούμενες. Οπότε είναι σαν να τις έχει στην επιφάνεια εργασίας ή στο task bar. Για άλλο πρόγραμμα, πρέπει να σκεφτεί να πατήσει το σηματάκι του Ubuntu (ή της άλλης διανομής, όσες το έχουν), όπως έκανε και στα windows, και εκεί θα του εμφανιστεί ένα πεδίο να γράψει (το ίδιο που γίνεται και στο GNOME). Οπότε δεν είναι στα στάνταρ του. Πόσο μάλλον που τα κουμπιά ελαχιστοποίησης, μεγιστοποίησης, κλείσιμο, βρίσκονται στα αριστερά καθώς και το global menu (θα ψάχνει που είναι το αρχείο, επεξεργασία κλπ). Επίσης, ούτε καν θα καταλάβει ότι τα βελάκια δίπλα στα εικονίδια στο launcher είναι τα προγράμματα που έχει ανοικτά. Τέλος, και εδώ η απενεργοποίηση βρίσκεται σε δύσκολο μέρος.

linux mint unity

Ένα άλλο που ακούω από τους χρήστες windows και δεν ξέρω πως να το εκλάβω είναι:
Δεν εγκαθιστώ-χρησιμοποιώ Linux γιατί είναι δύσκολα, τελείως διαφορετικά, χρειάζεται να διαβάσω, είναι για προγραμματιστές-χάκερς, πρέπει να ξέρεις προγραμματισμό.

Όμως, όταν σε αυτούς τους χρήστες δώσεις να χρησιμοποιήσουν MAC OSX, το μαθαίνουν σε λίγα λεπτά (το MAC είναι πιο κοντά σε δεδομένα του Linux, παρά σε windows).

Φαντάζομαι θα συμφωνήσετε μαζί μου, είναι θέμα marketing...

4. Σε νέο χρήστη βάζεις Ubuntoειδές επειδή έχει Software Center

Μέγα σφάλμα. Ο χρήστης windows έχει συνηθίσει (και αυτό θα κάνει και τώρα), να ψάχνει στο google το πρόγραμμα (ή λειτουργία), να κατεβάζει το πρόγραμμα και να το εγκαθιστά (φίλος κατέβασε το μtorrent.exe για να το εγκαταστήσει). Μετά να ψάχνει το "σπαστήρι" του και να γίνει χάκερ. Δεν ήξερε και από χθες το Software Center. Είτε του δείξεις το Synaptic, είτε το σύστημα του Linux Mint, είτε το YaST, αυτό είναι που θα μάθει και θα χρησιμοποιεί. Μόνο χρήστες MAC OSX το γνωρίζουν (άντε και χρήστες κινητών Android).

Κακά τα ψέματα, ο μέσος χρήστης θέλει:
- Πλήρη υποστήριξη ελληνικών
- Codecs (για να παίζει μουσική, βίντεο) και VLC
- Office (που να αποθηκεύει σε .doc για να μπορεί να τα διαβάζει σε windows)
- Firefox
- CD/DVD burn
- Files (nautilus, dolphin, caja, nemo)
- Skype

Μέχρι τώρα, ίσως η μόνη διανομή που να τα έχει όλα αυτά προεγκατεστημένα είναι η PCLinuxOS (όλα τα extra προγράμματα σε ένα αποθετήριο). Μόνη "ένσταση" είναι στο LiveCD καθώς και μετά την εγκατάσταση πρέπει να το γυρίσεις στα Ελληνικά μόνος σου. Επίσης και το Linux Mint είναι πολύ κοντά στις παραπάνω απαιτήσεις.

Όσον αφορά τον πιο προχωρημένο χρήστη, το openSUSE με το YaST και το PCLinuxOS με το PCC είναι αυτά που θα ικανοποιήσουν τα θέλω του. Από γραφικά περιβάλλοντα, το KDE και το MATE που έχουν πίνακα ρυθμίσεων, είναι αυτά που θα επιτρέψουν στον προχωρημένο χρήστη να παραμετροποιήσει το γραφικό περιβάλλον (έχουν κάτι αντίστοιχο και τα άλλα γραφικά περιβάλλοντα, αλλά πολύ απλά).

Για να καταλήξω σε κάποιο συμπέρασμα, η καλύτερη διανομή και γραφικό περιβάλλον για νέο-αρχάριο χρήστη (facebook, Internet, multimedia) είναι αυτά με τα οποία ξεκινάει την περιήγησή του στον κόσμο του Ελεύθερου Λογισμικού. Για να τα επιλέξει, δείξτε του 2 γραφικά περιβάλλοντα της διανομής που εσείς γνωρίζετε καλύτερα γιατί εσάς θα "πρήξει" με τηλεφωνήματα.