Category: Netrunner (Page 1 of 2)

Where are the giants?

When approaching this issue I had been thinking about the issue for a while. I had mainly 2 problems: I was rather frustrated with previous Linux-based systems so far and the one I liked didn’t really scale for us. One thing was clear: We had to stand on the shoulder of giants.

• The first one to think about was the N9 SDK (and by extension N900). It used to have a scratchbox-based system that emulated the one on the phone. It was useful for testing the applications locally on the device (although I actually never used that), I think that this one had both cross-compilation toolchain and base system, as well as the host and it used QEmu if a host executable was run. It felt weird because it shoved you in a weird system and you had to pull your code in weird ways to fetch it. Otherwise it worked great. Afterwards, madde came. It’s what I was looking for really and played quite well with cmake, actually when I published the steps on how to develop for the N9 it’s what I used back then, but it probably was too late for it to become a thing I guess. Also many people weren’t too fond of it, as I learned after some time.
• The Android NDK is the other I took into account. I don’t think it would be fair to compare anything we could do with the actual Android SDK, so I’ll limit myself to this one. This one ships the complete cross-compilation toolchain and runs native (similar to the BBX SDK, IIRC).

For the N9 approach, I would have had to concentrate on figuring out technologies that were long dead (and probably should remain). For the Android approach I found 2 big problems: We have to actually work on generating the actual binaries (which means, from any platform to a specific ubuntu-vivid-arm target) plus all the dependencies. This meant, creating a new distro, and we already had debian/ubuntu for that, let’s use debootstrap! Oh, wait…

Old school

For a start, I took what sebas already started, in fact. Using debootstrap to create a chroot jail that could cross-compile the projects into our platform. This started to prove feasible really soon, as 2 or 3 days after working on it (and after fixing some issues that kept arising, mostly on KF5 itself and packaging), I already started to output binaries that could be deployed on the device.

Problems:

• My IDE is outside of the jail, so there isn’t much we can do to integrate at all (we can’t access the build directory, and most of the data in it isn’t too meaningful for the outside anyway). A solution would be to ship and run the IDE from within the SDK though.
• You need to be root. Not only to generate the system, but also to run it.

New school

An idea I wanted to approach was docker. Everyone on the web world is shit-crazy about it and it’s deeply based on traditional Linux, so there’s quite in common already. Doing something similar to the deboostrap there was a piece of cake, and I managed to re-use the set up code I already had for the previous version.

Problems:

• Also everything is inaccessible from the IDE
• I’m less aware of the limitations I’ll find.

Still, this second approach feels lighter and it’s quite fun to investigate something new like that.

Tooling

It seems that the jailed systems are the way to go, at least for now, so the tools I’ve created so far assume that they live in the jail as well. So, what do we have?

• createpkg: Makes it possible to create a deb package that can be sent to the device for testing. It’s much simpler than the simplest deb package ever, but it works. Much better than sending executables over, much better than learning how to package for Debian.
• deploypkg: sends the deb file, installs it and starts the application.
• click-get: Downloads a click file from the Ubuntu Store, it’s harder than you’d think.
• kdev-debdeploy: Does it all, inside your good ol’ IDE.

To be done

• Workflow: Figure out a way to deploy KDevelop within either jail, but then we’ll also be able to use kde-debdeploy, that does mostly the same as these tools, integrated on the IDE.
• Emulation: Testing: QEmu + docker anyone?

One of the most interesting developments I’ve seen recently inside KDE is KAccounts (or Web Accounts, as it used to be called). It’s not even a KDE project, but a project Nokia started some years ago, I’m guessing that on MeeGo days.

Why do I care?

As a developer it’s always very important to know what resources you have available. The more you have, the richer the users’ experience will be. Resources are not only hardware but often just semantically-structured information. For example, KPeople helps us tell apart the contact list and offers us people instead or Solid, that turns the different ways of exposing the hardware information into something easily consumable by front-end applications.

Now we’re talking about identities. We don’t exclusively rely on local data anymore, I think that’s a fact nowadays (and even 5 years ago). Our disks are just another place where we store some of our data. KDE projects must be prepared to easily offer such workflows. One of the important parts to do it properly is authentication:

• We need a list of available services we can use.
• We don’t want our users requested identity authentication all the time.
• We don’t want each application to implement the N authentications algorithms of the N different providers our users will eventually have.

Why do you care? (as a KDE software user)

First of all, you want your developers to have the best tools (GOTO: “Why do I care?”).

board meeting of @kdecommunity in progress pic.twitter.com/rIVojmuyFB

— Lydia Pintscher (@nightrose) April 12, 2015

There’s a more important issue to figure out, more ideological than technical: We ask service and software providers to use standard specifications to improve interoperability, but then in practice we are seldom leveraging it. The case-by-case set up burden makes it hard for users to have everything configured properly. An example for this is ownCloud integration. I know a couple of people running an instance, but they seldom integrate it in Dolphin, but even if they did they’d still need to integrate the rest of provided services, such as calendar, contacts, etc.
We want to tell our software what providers we have available, those providers will provide different services. The software should integrate as much as possible with those services.

How can I help?

• Testing: There’s a lot going on, thorough testing and ideas is important. Both when it comes to making sure everything works as expected as well as what software should adopt KAccounts. It will already be available with KDE Applications 15.04.
• Developing: Make sure your application of choice uses KAccounts to figure out the configured services. Here’s a good place to find documentation: API, and an example use-case.
• Promotion: It’s important to reach out to service providers, make sure they know there’s such possibility and hopefully they can help us work better with their services (hey! by the book example of a win-win situation!).

Nowadays our computation experience is spread among different services and we need to be smart enough to understand how our users will adopt them and make it as transparent as possible.
AccountsSSO and KAccounts are a solid step forward in this direction, let’s get back in control of our data!