Open Search Foundation

June 14, 2020 3 comments

recently I learned about the Open Search Foundation in the public broadcast radio (Bayern 2 Radio Article). That surprised me: I had not heard about OSF before, even though I am active in the field of free software and culture. But this new foundation made it into the mainstream broadcast already. Reason enough to take a closer look.

It is a very good sign to have the topic of internet search in the news. It is a fact that one company has a gigantic market share in searching which is indeed a threat to the freedom of internet users. The key to be found in the web is the key to success with whatever message or service a web site might come up with, and all that is controlled by one enterprise driven by commercial interests. That should be realized by a broad audience.

The Open Search Foundation has the clear vision to build up an publicly owned search index as an alternative for Europe.

Geographical and Political Focus

The whitepaper talks about working on the search machine specifically for Europe. It mentions that there are search indexes in the US, China and Russia, but none rooted in Europe. While this is a geographical statement in the first place, it is of course also a political, because some of the existing services are probably politically controlled.

It is good to start with a focus on Europe, but the idea of a free and publicly controlled project should not be limited to Europes borders. In fact, it will not stop there if it is attractive because it might offer a way to escape from potentially controlled systems.

On the other hand, Europe (in opposite to any single European country alone) seems like a good base to start with this huge effort as it is able to come up with the needed resources.

Organization

The founding members of the Open Search Foundation are not very well known members of the wider open source community. That is good, as it shows that the topics around the free internet do not only concern nerds in the typical communities, but also people who work for an open and future proof society in other areas like academia, research and medicine.

On the other hand, an organization like for example the Wikimedia e.V. might have been a more obvious candidate to address this topic. Neither on the web site nor in the whitepaper I found mentions of any of the “usual suspects” or other organizations and companies who have already tried to set up alternative indices. I wonder if there have been discussions, cooperations or plans to work together?

I am very curious to see how the collaboration between the more “traditional” open data/open source community and the Open Search Foundation will be, as I think it is a crucial part to combine all players in this area without falling into the “endless discussion trap” while not achieving countable results. It is the question of building an efficient community.

Pillars of Success

Does the idea of the OSF have a realistic chance to succeed? The following four pillars might play an important role for the success of the idea to build the free search index of the internet:

1. Licenses and Governance

The legal framework has to be well defined and thought through, so that it will be resilient longer term. As we talk about a huge commercial potential to control this index, parties might wanna try to get into control of it.

Only a strong governance and legal framework can ensure that the idea lasts.

The OSF mentions in the whitepaper that it is one of the first steps to set this up.

2. Ressources

A search index requires big amounts of computing power in the wider sense, including storage, networking, redundancy and so on. Additionally there need to be people who take care on that. For that, there needs to be financial support for staffing, marketing, legal support and all that.

The whitepaper mentions ideas to collect the computing power from academia or from company donations.

For the financial backing the OSF will have to find sources like EC money, from governments and academia, and maybe private fund raising. Organizations like Wikimedia would already have experience with that.

If that will not be enough, the idea of selling better search results for money or offering SEO help for development will quickly come up. This will be interesting discussions that require the strong governance.

3. Technical Excellence

Who will use a search index that does not come up with reasonable search results?
To be able to compete with the existing solutions that even made it into our daily communication habits already, the service needs to be just great in terms of search results and user experience.

Many already existing approaches that use the Google index as a backend have already show that even with that it is not easy to provide a comparable result.

It is a fact that users of the commercial competition trade their personal data against optimal search results, even if they dont do that consciously. It is more difficult for a privacy oriented service, so this is another handicap.

The whitepaper mentions ideas on how to work on this huge task and also accepts that it will be challenging. But that is no reason to not try it. We all know plenty of examples where these kind of tasks were successful even though nobody believed that in the beginning.

4. Community

To achieve all the points a strong community is key factor.

There need to be people who do technical work like administering the data centers, developers who code, technical writers for documentation, translators and much more. But that is only the technical part.

For the financial-, marketing- and legal support there are other people needed, not speaking about political lobby and such.

All these parts have to be built up, managed and kept intact long term.

The Linux kernel, which was mentioned as a model in the whitepaper, is different. Not even the technical work is comparable between the free search index and the Linux kernel.

The long term stable development of the Linux kernel is based on people who work full time on the kernel while being employed by certain companies who are actually competitors. But on the kernel, they collaborate.

This way, the companies share cost for inevitable base development work. There differentiators in the market are not depending on there work on the kernel, but in the levels above the kernel.

How is that for OSF? I am failing to see how enough sustainable business can be based on an open, privacy respecting search index so that companies will be happy to fund engineers working on it.

Apart from that, the kernel has the benefit that it had strong companies like RedHat, SUSE and IBM who pushed Linux in the early times, so no special marketing budgets etc. were needed for the kernel specifically. Also that is different for OSF, as quite some marketing- and community management money will be required to start.

Conclusion

Building a lasting, productive and well established community will be the vital question for the whole project in my opinion. Offering a great idea, which this initiative is without question, will not be enough to motivate people to participate long term.

There has to be an interesting offer for potential contributors at all levels, starting from individuals and companies for contributions, to universities for donating hardware or the governments and the European Community for money. There needs to be some kind of benefit they will gain for their engagement on the project. It is interesting if the OSF can come up with a model that will get that kickstarted.

I very much hope that this gets traction as it would be an important step towards a more free internet again. And I also hope that there will be collaboration on this topic with the traditional free culture communities and the foundations there.

Categories: FOSS, KDE, Opinion Tags:

Welcome PDF Quirk

May 21, 2020 7 comments

How often have you scanned a letter, a certificate or whatever and looked for the right way to call $UTILITY to convert it to a PDF that can be shared via internet?

For this very common use case I could not find a tool to make that really easy for the Linux desktop. Given my mission to help making the Linux desktop more common in the small business world (do you know Kraft?) I spent some time starting this little project.

Please welcome PDF Quirk, the desktop app to easily create PDFs out of images from storage or directly from the scanner!

It is just what this screenshot shows: A one page app to pick images from either the harddisk or from a scanner if configured, and save it right away to a multi page PDF file. The only option is to have either monochrome or color scan. No further scan chi-chi, just nice PDFs within seconds.

Of course I did not want to spend too much time and reinvent the wheel. PDF Quirk uses ImageMagicks convert utility and the command line scan client scanimage of the SANE Project in the background. Both are welknown standard commands on Linux, and serve well for this purpose.

Maybe you find PDF Quirk useful and wanna try it. You find it on Github, or packages on the openSUSE Buildservice.

Contributions and comments are very welcome. It is a fun little project!

Categories: FOSS, KDE, Kraft, Qt Tags: , , ,

Kraft Version 0.90

December 31, 2019 1 comment

This blog is to inform that Kraft, the Qt and KDE based desktop software to manage documents like invoices and quotes in your small company was released in version 0.90 recently.

Followup Documents

A great new feature is the completely reworked handling of so called follow-up documents. Kraft has this feature to help dealing with docs that follow on a certain kind of predecessor doc in the business flow, such as an invoice follows on an offer once the work has been finished.

Document flow exampleTo achieve that and to have all the items of the offer again referenced in the invoice, the Kraft user justs clicks on the menu item “Create Followup Document” on the selected offer, and the new doc is created with all the items of the offer prepared. It is ready to be adjusted to the final invoice details.

Now with version 0.90 this has even improved. Often, the flow is a bit different because a partial invoice is sent while the job is still in progress, for example to cover cost for material. A partial invoice usually has only one item, which is the progress payment the customer should pay.

Kraft users can handle that now very easy: The new UI does not only allow to choose from which predecessor document the final invoice should copy the items (which usually is the offer in the beginning) but it also realises that a partial invoice was sent before, so this amount of payment has to be substracted from the final invoice. Kraft adds an item to the final doc automatically here.

This helps to create high quality documents for your customers even faster, which is exactly the mission of Kraft.

Other Improvements

In addition to that, as usual a lot of other visible and invisible changes have gone into this release. For example, the UI has been simplified again by a clean up of the menu for example. The About Kraft dialog was removed and integrated into the Kraft information page.

Under the hood, we finally added unit tests, which is just a start so far, and ntroduced a new, XML based system to manage the available document types which makes igrations way easier. Last but not least the python based pdf conversion script was ported to python 3 to be ready for the end of python 2.

Community

Last but not least, Kraft got new contributions from the community: A new document type was initiated by a community member, which is a offer like document without showing the price information. Also, the complete app was translated to Dutch by a volunteer, and the translation is now shipped with Kraft by default. Also, other smaller bugfixes went in.

Thank you all for your help to improve Kraft.

Categories: KDE, Kraft, Qt, Release, SMB Tags: , , ,

ownCloud and CryFS

August 17, 2019 5 comments

It is a great idea to encrypt files on client side before uploading them to an ownCloud server if that one is not running in controlled environment, or if one just wants to act defensive and minimize risk.

Some people think it is a great idea to include the functionality in the sync client.

I don’t agree because it combines two very complex topics into one code base and makes the code difficult to maintain. The risk is high to end up with a kind of code base which nobody is able to maintain properly any more. So let’s better avoid that for ownCloud and look for alternatives.

A good way is to use a so called encrypted overlay filesystem and let ownCloud sync the encrypted files. The downside is that you can not use the encrypted files in the web interface because it can not decrypt the files easily. To me, that is not overly important because I want to sync files between different clients, which probably is the most common usecase.

Encrypted overlay filesystems put the encrypted data in one directory called the cipher directory. A decrypted representation of the data is mounted to a different directory, in which the user works.

That is easy to setup and use, and also in principle good to use with file sync software like ownCloud because it does not store the files in one huge container file that needs to be synced if one bit changes as other solutions do.

To use it, the cypher directory must be configured as local sync dir of the client. If a file is changed in the mounted dir, the overlay file system changes the crypto files in the cypher dir. These are synced by the ownCloud client.

One of the solutions I tried is CryFS. It works nicely in general, but is unfortunately very slow together with ownCloud sync.

The reason for that is that CryFS is chunking all files in the cypher dir into 16 kB blocks, which are spread over a set of directories. It is very beneficial because file names and sizes are not reconstructable in the cypher dir, but it hits on one of the weak sides of the ownCloud sync. ownCloud is traditionally a bit slow with many small files spread over many directories. That shows dramatically in a test with CryFS: Adding eleven new files with a overall size of around 45 MB to a CryFS filesystem directory makes the ownCloud client upload for 6:30 minutes.

Adding another four files with a total size of a bit over 1MB results in an upload of 130 files and directories, with an overall size of 1.1 MB.

A typical change use case like changing an existing office text document locally is not that bad. CryFS splits a 8,2 kB big LibreOffice text doc into three 16 kB files in three directories here. When one word gets inserted, CryFS needs to create three new dirs in the cypher dir and uploads four new 16 kB blocks.

My personal conclusion: CryFS is an interesting project. It has a nice integration in the KDE desktop with Plasma Vault. Splitting files into equal sized blocks is good because it does not allow to guess data based on names and sizes. However, for syncing with ownCloud, it is not the best partner.

If there is a way how to improve the situation, I would be eager to learn. Maybe the size of the blocks can be expanded, or the number of directories limited?
Also the upcoming ownCloud sync client version 2.6.0 again has optimizations in the discovery and propagation of changes, I am sure that improves the situation.

Let’s see what other alternatives can be found.

Categories: FOSS, KDE, ownCloud Tags: , , ,

Noisy Workshop

April 28, 2019 3 comments

Usually, in my workshop I am listening to the great radio station Bayern 2 (Yeah for public law media). But sometimes you just need to listen to nice classic english punk music, speed folk or (the one and only) Lemmy and friends.

For that I was looking for a so called boom box to stream to from my mobile, simple, dirty and loud. Good that I was a proud awardee at the HiFiBerry Maker Contest 2017 with my TeakEar build, where I won a nice set of a RaspberryPi Zero with a little HiFiBerry MiniAmp, coming with all what is needed to make that working.
inletThat should be enough to get proper punk sound in the workshop – and escape the
boring normal commercial boom boxes all around.

At a flee market I found a great case for that – exactly one of these that were in the classrooms of my school giving the unbanning gong at the end of each lesson. Nicely with the original non-color textile hiding the speaker and nicely done bended and veneered wood for the elegance.

case

A great fit for my usecase.

Two 3.3 inch Visaton fullrange speaker are mounted in simple closed chassis. The Raspi with the Amp is mounted between them. All is mounted on a back plate that fits the school speaker chassis. Boombox ready.

From a software perspective, it is there is just a Raspbian running that is configured to act as a bluetooth audio device for my mobile.

I think it is a nice addition to my workshop, with a great ease of use since it auto-connects to my mobile. Does it sound great? Oh no, not ..really. Is it loud? Well, yes, loud enough to not get in trouble with the neighbors. Given it’s size, it is actually impresse.

Surely Lemmy would be fine to play Rock’n Roll through it 🙂

The only downsize of the whole thing is that it disturbs the radio reception quite a bit, so it is really either or. Any hints how to reduce that?

Categories: DIY, Uncategorized, Volumio Tags: , ,

Eighty Percent ownCloud

December 23, 2018 25 comments

Recently the German computer magazin C’t posted an article about file sync solutions (“Unter eigener Regie”, C’t 23, 2018) with native sync clients. The article was pretty positive about the FOSS solution of… Nextcloud! I was wondering why they had not choosen ownCloud’s client as my feeling is that ownCloud is way more busy and innovative developing the desktop client for file synchronization together with community.

lines_changed

Code lines changed as of Nov. 10, 2018

That motivated me to do some investigation what the Nextcloud client actually consists of (at due date Nov. 10, 2018). I was looking into the NC desktop client git repoository grouped the numbers of commits of people that can be associated clearly to either the ownCloud- or Nextcloud project, or to “other communities” or machine commits. Since the number of commits could be misleading (maybe some commits are huge?) I did the same exercise with numbers of changed lines of code.

When looking on the changed lines, the first top six contributors to the Nextcloud desktop client are only active in the ownCloud project. Number seven is an “other community” contributor whos project the client was based on in the beginning. Number eight to eleven go to Nextcloud, with a low percentage figure.

commits

# of commits to the Nextcloud Desktop repository as of Nov. 10, 2018

As a result, far more than 80% of the changed lines of the Nextcloud client is actually work that ownClouders did (not considering the machine commits). In the past, and also today. The number would be even higher if it considered all the commits that go into the NC repo with an NC author, but are actually ownCloud patches where the original author got lost on the way by merging them through a NC branch. It looks like the Nextcloud developers were actually adding less commits to their client than all “other community” developers so far.

No wonder, it is a fork, you might think, and that is of course true. However, to my taste these numbers are not reflecting a “constructive” fork driving things forward when we talk about sync technology.

That is all fine, and I am proud that the work we do in ownCloud is actually stimulating two projects, with different focus areas nowadays. On the other hand, I would appreciate if the users of the technology would take a closer look to understand who really innovates, drives things forward and also fixes the nasty bugs in the stack. As a matter of fairness, that should be acknowledged. That is the motivation that keeps free software contributors busy and communities proud.

Change in Professional Life

November 23, 2018 2 comments

This November was very exciting for me so far, as I was starting a new job at a company called Heidolph. I left SUSE after working there for another two years. My role there that was pretty far away from interesting technical work, which I missed more and more, so I decided to grab the opportunity to join in a new adventure.

Heidolph is a mature German engineering company building premium laboratory equipment. It is based in Schwabach, Germany. For me it is the first time that I am working in company that doesn’t do only software. At Heidolph, software is just one building block besides mechanical and electronic parts and tons of special know how. That is a very different situation and a lot to learn for me, but in a small, co-located team of great engineers, I am able to catch up fast in this interesting area.

We build software for the next generation Heidolph devices based on Linux and C++/Qt. Both technologies are in the center of my interest, over the years it has become more than clear for me that I want to continue with that and deepen my knowledge even more.

Since the meaning of open source has changed a lot since I started to contribute to free software and KDE in particular, it was a noticeable but not difficult step for me to take and move away from a self-proclaimed open source company towards a company that is using open source technologies as one part of their tooling and is
interested in learning about the processes we do in open source to build great products. An exciting move for me where I will learn a lot but also benefit from my experience. This of course that does not mean that I will stop to contribute to open source projects.

We are still building up the team and look for a Software Quality Engineer. If you are interested in working with us in an exciting environment, you might wanna get in touch.

Categories: FOSS, KDE, Opinion, Qt Tags: ,

Kraft Version 0.82

October 19, 2018 5 comments

A new release of Kraft, the Qt- and KDE based software to help to organize business docs in small companies, has arrived.

A couple of days ago version 0.82 was released. It mainly is a bugfix release, but it also comes with a few new features. Users were asking for some new functions that they needed to switch to Kraft with their business communication, and I am always trying to make that a priority.

The most visible feature is a light rework of the calculation dialog that allows users to do price calculations for templates. It was cleared up, superflous elements were finally removed and the remaining ones now work as expected. The distinction between manual price and calculated price should be even more clear now. Time calculations can now not only done in the granularity of minutes, as this was to coarse for certain usecases. The unit for a time slice can now be either seconds, minutes or hours.

Kraft 0.82

New calculation dialog in 0.82

Apart from that, for example sending documents per email was fixed, and in addition to doing it through thunderbird, Kraft can now also utilize the xdg-email tool to work with the desktop standard mail client, such as KMail.

Quite a few more bugfixes make this a nice release. Check the full Changelog! Update is recommended.

Thanks for your comments or suggestions about Kraft!

Categories: FOSS, KDE, Kraft, Release Tags: , , ,

Kraft Version 0.81 Released

June 17, 2018 1 comment

I am happy to announce the release of Kraft version 0.81. Kraft is a Qt based desktop application that helps you to handle documents like quotes and invoices in your small business.

Version 0.81 is a bugfix release for the previous version 0.80, which was the first stable release based on Qt5 and KDE Frameworks5. Even though it came with way more new features than just the port, it’s first release has proven it’s stability in day-to-day business now for a few month.

Kraft 0.81 mainly fixes building with Qt 5.11, and a few other installation- and AppStream metadata glitches. The only user visible fix is that documents do not show the block about individual taxes on the PDF documents any more if the document only uses one tax rate.

Thanks for your suggestions and opinions that you might have about Kraft!

Categories: KDE, Kraft, Release Tags: , ,

Kraft Version 0.80 Released

April 3, 2018 3 comments

I am happy to announce the release of the stable Kraft version 0.80 (Changelog).

Kraft is desktop software to manage documents like quotes and invoices in the small business. It focuses on ease of use through an intuitive GUI, a well choosen feature set and ensures privacy by keeping data local.

After more than a dozen years of life time, Kraft is now reaching a new level: It is now completely ported to Qt5 / KDE Frameworks 5 and with that, it is compatible with all modern Linux distributions again.

KDE Frameworks 5 and Qt5 are the best base for modern desktop software and Kraft integrates seamlessly into all Linux desktops. Kraft makes use of the great KDE PIM infrastructure with KAddressbook and Akonadi.

In addition to the port that lasted unexpectedly over 12 months, Kraft v. 0.80 got a whole bunch of improvements, just to name some examples:

More Flexible Addressbook Integration

As Akonadi is optional now, Kraft can be built without it. Even if it was built with, but Akonadi for whatever reason is not working properly, Kraft still runs smoothly. In that case it only lacks the convenience of address book integration.

The Address book access was also nicely abstracted so that other Addressbook backends can be implemented more easily.

GUI Improvements

Even though the functionality and GUI of Kraft was not changed dramatically compared to the last stable KDE 4 version, there were a few interesting changes in the user interface.

  • A new, bigger side bar simplifies navigation.
  • In the timeline view, a click on years and month in the treeview show summaries of the selected time span, ie. the number of documents with financial summaries per month or year.
  • A filter allows to limit the view on the current week or month.

Reduction of dependencies

Kraft makes broad use of the core Qt5 libraries. The required KDE dependencies were reduced to a bare minimum. Akonadi libraries, which enable KDE PIM integration are now optional. The former dependency on heavyweight web browser components were completely removed and replaced by the far more simple richtext component of Qt.

These changes make it not only easier and more transparent to build Kraft but allow make a port to other platforms like MacOSX more easy in the future.

Under the Hood

A countless number of bugfixes and small improvements went in. Also updates to the newer C++ concepts where applicable make the rather mature code base more modern and better maintainable.

The Reportlab based PDF document creation script was updated and merged with a later version for example.

Deployment

Installing Kraft is still a bit complicated for unexperienced users, and distributions sometimes haven’t made a good job in the past to provide the latest version of Kraft.

To make it easier to test, there is an AppImage of Kraft 0.80 available that should be runable on most modern distributions. Just download a single file that can be started right away after having added the executable permissions.

Linux packages are already built for openSUSE (various versions) or Gentoo.

Kraft’s website will contain a lot more information.

Categories: KDE, Kraft, openSUSE, Qt, Release Tags: , , , ,