It’s here again, SUSE’s 16th Hackweek. A week where all of SUSE Engineering is given time away from their regular grind to work on whatever they want. And of course as this is SUSE we’re talking about, a lot of Hackweek involves the openSUSE Community also.

My Plans for Hackweek 0x10

This Hackweek I have a few small things I hope to spend a little bit of time on, and one huge exciting project I intend to throw most of my efforts in

In SUSE’s Nürnberg office there is a rather large, impressive interactive whiteboard/touchscreen for SUSE Engineering to use. However it’s currently running an inferior operating system, but seems to be reasonably hackable with easy access to the Intel-based embedded PC as part of the screen. So I’m keen to grab openSUSE Leap and make the big screen great again.

I also hear a few people will be looking at WeKan as a possible open alternative to Trello. As I’m not a huge fan of Trello, but interested in using Kanban Boards for organising a lot of what I’m doing, I plan on seeing how hard it is to get WeKan running on openSUSE if I have time; Which is unlikely, because..

The Big Idea - Kubic Desktop

These days I’m working on openSUSE Kubic. While the Project is still in its early stages, we have an exciting platform designed to run containers, with a rolling OS, safely and smoothly updated with atomic, transactional updates.

But my hackweek idea is to take these basic attributes of Kubic and repurpose them as a desktop. An Kubic Desktop should be able to provide a nice reliable GNOME environment, which can be reliably and automatically updated.

It could be a perfect way of leveraging all the existing technologies openSUSE has with Tumbleweed, OBS, and openQA to build a linux operating system which might be useful in “Chromebook”-like usecases.

The openSUSE distributions are sometimes criticised as not being suitable for “your grandmothers desktop”, which is often a fair critism and one that openSUSE shouldn’t be ashamed of - it’s not our communities core areas of interest. But a Kubic desktop could be an answer to leverage what we’re best at for that very scenario.

The only obvious problem is going to be “user space” applications. Installing packages is not a trivial task when the OS is locked down like an appliance. So for that, because I’ve already decided Kubic will have a GNOME desktop and it’s closely aligned with my favourite desktop, I’m going to try use Flatpak.

Why not?

Everybody should know that I am not a great fan of Flatpak or similar approaches to containerised application packaging.

But doing stuff that is weird, unusual, new, and sometimes counterinuative to everything you think is ‘right’ is exactly the sort of thing Hackweek is about.

So I’m excited about learning what I’m going to learn over these next days. Whether I learn to love Flatpak or find a new bunch of concerns about such technologies remains to be seen.

Will probably be a few days before I get around to the Flatpak part of the equation - first steps will be setting up a project in OBS and building basic OS images based on Tumbleweed’s GNOME LiveCD’s, but with Kubic’s read-only filesystem and transactional updates.

Expect updates to this blog once I have something fun to share.

Have a lot of fun!

My code has a bug. 😭

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x751ba4]
goroutine 58 [running]:
github.com/joeshaw/example.UpdateResponse(0xad3c60, 0xc420257300, 0xc4201f4200, 0x16, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /go/src/github.com/joeshaw/example/resp.go:108 +0x144
github.com/joeshaw/example.PrefetchLoop(0xacfd60, 0xc420395480, 0x13a52453c000, 0xad3c60, 0xc420257300)
        /go/src/github.com/joeshaw/example/resp.go:82 +0xc00
created by main.runServer
        /go/src/github.com/joeshaw/example/cmd/server/server.go:100 +0x7e0

This panic is caused by dereferencing a nil pointer, as indicated by the first line of the output. These types of errors are much less common in Go than in other languages like C or Java thanks to Go’s idioms around error handling.

If a function could fail, the function must return an error as its last return value. The caller should immediately check for errors from that function.

// val is a pointer, err is an error interface value
val, err := somethingThatCouldFail()
if err != nil {
    // Deal with the error, probably pushing it up the call stack
    return err
}

// By convention, nearly all the time, val is guaranteed to not be
// nil here.

However, there must be a bug somewhere that is violating this implicit API contract.

Before I go any further, a caveat: this is architecture- and operating system-dependent stuff, and I am only running this on amd64 Linux and macOS systems. Other systems can and will do things differently.

Line two of the panic output gives information about the UNIX signal that triggered the panic:

[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x751ba4]

A segmentation fault (SIGSEGV) occurred because of the nil pointer dereference. The code field maps to the UNIX siginfo.si_code field, and a value of 0x1 is SEGV_MAPERR (“address not mapped to object”) in Linux’s siginfo.h file.

addr maps to siginfo.si_addr and is 0x30, which isn’t a valid memory address.

pc is the program counter, and we could use it to figure out where the program crashed, but we conveniently don’t need to because a goroutine trace follows.

goroutine 58 [running]:
github.com/joeshaw/example.UpdateResponse(0xad3c60, 0xc420257300, 0xc4201f4200, 0x16, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /go/src/github.com/joeshaw/example/resp.go:108 +0x144
github.com/joeshaw/example.PrefetchLoop(0xacfd60, 0xc420395480, 0x13a52453c000, 0xad3c60, 0xc420257300)
        /go/src/github.com/joeshaw/example/resp.go:82 +0xc00
created by main.runServer
        /go/src/github.com/joeshaw/example/cmd/server/server.go:100 +0x7e0

The deepest stack frame, the one where the panic happened, is listed first. In this case, resp.go line 108.

The thing that catches my eye in this goroutine backtrace are the arguments to the UpdateResponse and PrefetchLoop functions, because the number doesn’t match up to the function signatures.

func UpdateResponse(c Client, id string, version int, resp *Response, data []byte) error
func PrefetchLoop(ctx context.Context, interval time.Duration, c Client)

UpdateResponse takes 5 arguments, but the panic shows that it takes more than 10. PrefetchLoop takes 3, but the panic shows 5. What’s going on?

To understand the argument values, we have to understand a little bit about the data structures underlying Go types. Russ Cox has two great blog posts on this, one on basic types, structs and pointers, strings, and slices and another on interfaces which describe how these are laid out in memory. Both posts are essential reading for Go programmers, but to summarize:

• Strings are two words (a pointer to string data and a length)
• Slices are three words (a pointer to a backing array, a length, and a capacity)
• Interfaces are two words (a pointer to the type and a pointer to the value)

When a panic happens, the arguments we see in the output include the “exploded” values of strings, slices, and interfaces. In addition, the return values of a function are added onto the end of the argument list.

To go back to our UpdateResponse function, the Client type is an interface, which is 2 values. id is a string, which is 2 values (4 total). version is an int, 1 value (5). resp is a pointer, 1 value (6). data is a slice, 3 values (9). The error return value is an interface, so add 2 more for a total of 11. The panic output limits the number to 10, so the last value is truncated from the output.

Here is an annotated UpdateResponse stack frame:

github.com/joeshaw/example.UpdateResponse(
    0xad3c60,      // c Client interface, type pointer
    0xc420257300,  // c Client interface, value pointer
    0xc4201f4200,  // id string, data pointer
    0x16,          // id string, length (0x16 = 22)
    0x1,           // version int (1)
    0x0,           // resp pointer (nil!)
    0x0,           // data slice, backing array pointer (nil)
    0x0,           // data slice, length (0)
    0x0,           // data slice, capacity (0)
    0x0,           // error interface (return value), type pointer
    ...            // truncated; would have been error interface value pointer
)

This helps confirm what the source suggested, which is that resp was nil and being dereferenced.

Moving up one stack frame to PrefetchLoop: ctx context.Context is an interface value, interval is a time.Duration (which is just an int64), and Client again is an interface.

PrefetchLoop annotated:

github.com/joeshaw/example.PrefetchLoop(
    0xacfd60,       // ctx context.Context interface, type pointer
    0xc420395480,   // ctx context.Context interface, value pointer
    0x13a52453c000, // interval time.Duration (6h0m)
    0xad3c60,       // c Client interface, type pointer
    0xc420257300,   // c Client interface, value pointer
)

As I mentioned earlier, it should not have been possible for resp to be nil, because that should only happen when the returned error is not nil. The culprit was in code which was erroneously using the github.com/pkg/errors Wrapf() function instead of Errorf().

// Function returns (*Response, []byte, error)

if resp.StatusCode != http.StatusOK {
    return nil, nil, errors.Wrapf(err, "got status code %d fetching response %s", resp.StatusCode, url)
}

Wrapf() returns nil if the error passed into it is nil. This function erroneously returned nil, nil, nil when the HTTP status code was not http.StatusOK, because a non-200 status code is not an error and thus err was nil. Replacing the errors.Wrapf() call with errors.Errorf() fixed the bug.

Understanding and contextualizing panic output can make tracking down errors much easier! Hopefully this information will come in handy for you in the future.

Thanks to Peter Teichman, Damian Gryski, and Travis Bischel who all helped me decode the panic output argument lists.

Update

From the Go 1.17 release notes:

The format of stack traces from the runtime (printed when an uncaught panic occurs, or when runtime.Stack is called) is improved. Previously, the function arguments were printed as hexadecimal words based on the memory layout. Now each argument in the source code is printed separately, separated by commas. Aggregate-typed (struct, array, string, slice, interface, and complex) arguments are delimited by curly braces. A caveat is that the value of an argument that only lives in a register and is not stored to memory may be inaccurate. Function return values (which were usually inaccurate) are no longer printed.

And from the 1.18 release notes:

Go 1.17 generally improved the formatting of arguments in stack traces, but could print inaccurate values for arguments passed in registers. This is improved in Go 1.18 by printing a question mark (?) after each value that may be inaccurate.

A colleague recently had a crash similar to our example above. The relevant methods looked like this:

func (s *Service) GetCount(repo string) (count int64, errors []error)
func (s *Service) request(method string, url string, body []byte) (status int, response []byte, errors []error)

where s.GetCount(...) calls s.request(...).

The stack trace looked like this:

github.com/example/service.(*Service).request(0x0, {0x118368d?, 0xc000cd9b20?}, {0xc000588180?, 0x1?}, {0x0, 0x0, 0x0})
	/go/src/github.com/example/service/service.go:38 +0xdc
github.com/example/service.(*Service).GetCount(0xc000896700?, {0xc00084bed0?, 0x1ba03c0?})
	/go/src/github.com/example/service/service.go:69 +0xdc

You can see right away that the new output is a big improvement. The aggregated types (strings and slices in this example) are grouped together. Return values are omitted entirely.

Here it is again with my annotations:

github.com/example/service.(*Service).request(
    0x0,                          // *Service receiver, nil pointer (!)
    {0x118368d?, 0xc000cd9b20?},  // method string: pointer and length
    {0xc000588180?, 0x1?},        // url string: pointer and length
    {0x0, 0x0, 0x0}               // body []byte: pointer, length, capacity
)
	/go/src/github.com/example/service/service.go:38 +0xdc

github.com/example/service.(*Service).GetCount(
    0xc000896700?,                // *Service receiver, pointer
    {0xc00084bed0?, 0x1ba03c0?}   // repo string: pointer and length
)
	/go/src/github.com/example/service/service.go:69 +0xdc

Pretty clearly here you can see that the nil *Service receiver in the call to request is the problem. Something on line 38 is trying to dereference it and causing the crash.

But wait. GetCount calls request and its receiver is not nil (0x0). What’s going on?

The release notes above say that the stack trace could include “inaccurate values for arguments passed in registers” and signifies this by putting a question mark after such values.

GetCount does nothing with the receiver value other than passing it along to the request method. This means that when GetCount gets the receiver passed in as a register, it does not need to load it into RAM and we get the potentially inaccurate value in our stack trace.

request does do something with the value – dereferences it – requiring it to be loaded into RAM. That’s why the value is accurate in the request stack frame.

openSUSE Asia Summit was over 2 weeks ago, but i can still feel the euphoria of the summit. It’s unforgettable for me. I am one of the people who interested when Dr. Takeyama-san announcing the next Asia Summit will be held in Japan. I think i should go there. Yeah, i should go abroad!

So, i prepared all of i needed for the summit after it’s announced. I started to make a passport, visa, book a ticket, and ask for permission from my boss and the most important is the material of my talk. Last years, i have specified my talk is “Using Active Directory for Single Sign-On Login using openSUSE” for openSUSE Asia Summit Japan. but in the middle of 2017. I think docker still booming at the time and so many Japan Engineers interested with docker. So, i decided to make a 2 proposal those are “Active Directory” and about “Docker Registry“.

I am so happy when the papers for Asia Summit announced, two of my proposal are got a high score, but i must choose one of the proposals. So,  i decided to choose a Docker Registry (Portus) as My Proposal, and i bring a “Have Fun Claim Control Your Docker Images with Portus“.

Before the summit, i tried to bring my talk for the summit on openSUSE Release Party 42.3 in Bojong. you can see the report here: https://glibogor.or.id/pesta-rilis-opensuse-42-3/. I tried to improve my presentation for the summit in order to not disappoint the audience or committee.

Departure

And the time goes on approaching Summit. I went to Japan on October 19th. I just work half a day in PT. Excellent Infotama Kreasindo. Ask for advice from boss Vavai and said a goodbye to my friends in the office.  After that, i go to home to take my luggage and go to the airport with my special people using Damri (bus to the airport in Indonesia) :-D.

This is my first international speech and journey. Last year, in openSUSE Asia Summit 2016, Yogyakarta. I just become a volunteer and this year, I tried to encourage myself to be a speaker in openSUSE Asia Summit 2017 and go abroad.

I have the same flight with my friends from openSUSE Indonesia. Kakek Yan Arief, Pak Andi Sugandi, Tonny Sabastian and Umul using GA874, it’s take off at 23.35 WIT and arrive in Tokyo on 08.35. It’s faster 2 hours than Indonesia. I was worried about the Typhoon. But luckily, my flight went well and came in Tokyo on time. :-).

Arrived at Tokyo, Yeay!

After arriving at Haneda International Airport, i bought a Pasmo Card for the Accessing Tokyo train, it’s very simple than bought single trip ticket :-D. It’s spending 2000¥. 500¥ for deposit and 1500¥ for balance. Then, i went to the Airbnb House with Umul to joins with my friends from Indonesia who came first from us in near of Hachimanyama Station.

October 20th: Speaker Party!

After arriving at the guest house in near of Hachimanyama Station, I and Umul didn’t have to take a rest because my friends invite me went to Fujiko. F. Fujio Museum and after it, we went straight to the speaker party. So, with a sleepy face, i and Umul go to the museum by train, exit at Noborito station and Walk about 20 minutes to get to the destination. Maybe in Indonesia, i give up because the weather is so hot haha :D.

For some reason, i didn’t feel tired when walking about 20 minutes. The weather in Japan is good and it’s a heaven for pedestrian, i really love it!

After walking about 20 Minutes. Finally, I and my friends arrived at the Museum until 04.00 PM. We really enjoy looking around at the museum. In the main hall we didn’t have to take a picture but in the upstairs, we take a many photos (Indonesian Things).

Finally, i can take a photo one of my favorite cartoon characters, Doraemon!

Okay, after having a lot of fun at the museum. We went to the speaker party. Yeah, this is the first moment we met each other before we take a summit party tomorrow. We went to the UEC by train from Noborito Station and exit in the Chofu Station. It takes about 1 hour.

Evidently, we got ahead of the others (exclude committee).At the party, we have a lot of fun again. Enjoying the food, talk with each other from another country. This is a rare moment i can’t get on Indonesia and it’s improving my English.

I met an another Indonesia speakers, Mr. Edwin, and Estu and i met Dr. Takeyama-san, Hato-chan, Mrs. Sunny, Ben Chou, Max Lin, and Zhao Qiang who also joining last openSUSE Asia Summit on Yogyakarta. I met many great people here. I also met Richard Brown (Chairman of openSUSE), Ludwig Nussel, Andreas, Ana and many other from SUSE/openSUSE and i met with LibreOffice people, Naruhiko Ogasawara, Shinju Enoki, Mohamed Trabelsi, Aschalew Arega and etc. What’s a great moment!

After this, i ask to Dr. Takeyama-san to take a picture together before we return to the lodge :

openSUSE Asia Summit Speakers at the Party

After this, finally. I can take a rest for tomorrow at the lodging. Tomorrow will be a big day for me, i will present my talk :-).

October 21th: openSUSE Asia Summit Day 1

The first-day summit is the day where I will present my talk. I arrived at UEC on 09.00 AM then watch an opening for openSUSE Asia Summit by Dr. Takeyama-san. My talk present on 02.30 PM. At the day i feel anxious, nervous and much more. I worried about my English because it is not good :-D. After lunch, finally, i present my talk and…

Oh my god, Richard Brown attend to my class and I’m really nervous hahaha. Seriously!

Watching Muhammad Dhenandi Putra from Indonesia talking about Docker and Portus at @openSUSE Asia pic.twitter.com/Af9LD5AKkj

— Richard Brown (@sysrich) October 21, 2017

In the QA sessions, i have a question from Richard about Kubic and Sakana Max about bug and portus installation.

I have prepared a gift (openSUSE-ID Tshirt) for the lucky one who asked on my talk. But the size doesn’t match with them :-D. Finally, Youngbin Han from Korea ask me and he got limited openSUSE ID Tshirt. But, the size also doesn’t match with him, but he will give it to his friend.

Youngbin Han from Korea

Thank you, god. I have completed my session :-). I realized my English still not good. But, i will enhance it for the next openSUSE Asia Summit :-).

After my session, i go to Richard Brown. We talk about openSUSE and Indonesia. It’s an honor for me can meet and speak with openSUSE Chairman. He’s a good man, i really enjoy speaks with him, and we take a photo and selfie together :D.

Photo Session with Richard Brown after QA Session

After this, i went to another class to take a photo for documentation. i also attend to the great session, i attending to Om Edwin session, Mrs. Sunny. This is my favorite session because it’s present about how we can contribute in open source. Those are enhancing my spirit to contribute :-).

How To Encourage Community by Edwin Zakaria

Open Source is an option of life by Mrs. Sunny

Our fun is not stopped here, after Summit Day 1, we have a party again in UEC restaurant until 9 PM. And we back to the lodge at 11 PM.

Summit Day 1 Party

October 22th: openSUSE Asia Summit Day 2

At the Second days of the summit, i feel peaceful because i have complete my talk. This day, i walking in the around area of openSUSE Asia Summit to take a photo and documentation. I also come to learn about Libre Office and openSUSE. i attending Sendy, Kake Yan, Pak Moko, Pak Ary, Simon Lees, Mrs. Ana and etc.

Photo Session on openSUSE Asia Summit 2017

Yeah, finally i hold geeko on photo session :D.

October 23th: openSUSE Asia Summit One Day Tour

This is the third days of the summit, i and another speaker and committee take a one day tour. We met at Hinode Pier and go together to Asakusa (Sensoji-Temple) by Train.

Strong wind make our hair fly

After it, we lunch in Naritaya Halal Ramen and go again to Tokyo Skytree. This is the higher place i ever visit, i can see Tokyo from 350 m high. Oh my god.

Tokyoooooo!

Take a photo on Skytree Deck

After Skytree, we move to Akihabara using Bus and take the train from Ueno Station. We arrived at Akihabara at 7:00 PM. And said goodbye to each other.

Thank You to …

I have a lot of fun, i can’t describe it. I really happy can be a part of openSUSE Asia Summit. Thank you to openSUSE for Travel Support Program, openSUSE Asia Summit committee for great hard works, all of you do a great job, really appreciated. Om Edwin Zakaria to make it happens, Pak Boss Vavai for great advice and help. My Parents because always supporting me. PT Excellent Infotama Kreasindo, openSUSE Indonesia, GLiB,  and much more. You’re awesome.

Credits

Photo from openSUSE Asia Summit 2017 Flickr Group: Thanks to great all photographers, Om Edwin, Kakek Yan Arief,  Takeyama-san, Hisa_X, Tonny, Richard Brown, and etc.

The post openSUSE Asia Summit 2017 Tokyo Report appeared first on dhenandi.com.

Here is a little Emacs Lisp snippet that I've started using. It makes Emacs pop up a desktop-wide notification when a compilation finishes, i.e. after "M-x compile" is done. Let's see if that keeps me from wasting time in the web when I launch a compilation.

(setq compilation-finish-functions
      (append compilation-finish-functions
          '(fmq-compilation-finish)))

(defun fmq-compilation-finish (buffer status)
  (call-process "notify-send" nil nil nil
        "-t" "0"
        "-i" "emacs"
        "Compilation finished in Emacs"
        status))

Today the OpenStack Summit started in Sydney with the keynotes. This time the keynotes are only on the first day, which is really nice since it's only a 3 days event - more time for the presentations.

• Multicloud requirements and implementations: from users, developer, service providers (Panel, Mon 6 , 2:20pm-3:00pm, step in for Kurt Garloff from T-Systems)
• Email Storage with Ceph (Lightning Talk,  Tue 7 , 9:15am-9:25am)
• Vanilla vs OpenStack Distributions - Update on Distinctions, Status, and Statistics (Presentation, Wed 8 , 9:00am-9:40am)

In the past weeks, we have noticed an increased interest in Plasma Mobile from different sides. Slowly, but surely, hardware vendors have discovered that Plasma Mobile is an entirely different software platform to build products on top of. For people or companies who want to work or invest into Plasma Mobile, it’s always useful to know where upstream is heading, so let me give an overview of what our plans are, what areas of work we’re planning to tackle in the coming months and years, where our focus will be and how it will shift. Let’s talk about Plasma Mobile’s roadmap.

Our development strategy is to build a basic system and platform around our core values first and then extend this. Having a stable base of essentials allows us to focus on an achievable subset first and then extend functionality for more and more possible target groups. It avoids pie-in-the-sky system engineering something that will never be useful and designed for a unicorn market that never existed. Get the basics right first, then take it to the next levels. These levels are:

1. Prototype (already finished)
2. Feature Phone
3. Basic Smartphone
4. Featured Smartphone

Prototype and Product Vision

The first public release of Plasma Mobile was this prototype. It showed a very basic and incomplete-for-daily-use system on actual, modern smartphone hardware. You could make phone calls, start and manage apps, and manipulate some basic system functionality. It showed a smartphone system based on Plasma could be done, and more importantly, it taught us a lot about where we want to take things on a technical level.
Along with the prototype, we developed a product vision for Plasma Mobile, a direction where we want to take it (emphasis added by yours truly):

“Plasma Mobile aims to become a complete software system for mobile devices. It is designed to give privacy-aware users back the full-control over their information and communication. Plasma Mobile takes a pragmatic approach and is inclusive to 3rd party software, allowing the user to choose which applications and services to use. It provides a seamless experience across multiple devices. Plasma Mobile implements open standards and it is developed in a transparent process that is open for the community to participate in.”

Feature Phone

The feature phone milestone is what we’re working on right now. This involves taking the prototype and fixing all the basic things to turn it into something usable. Usable doesn’t mean “usable for everyone”, but it should at least be workable for a subset of people that only rely on basic features — “simple” things.
Core features should work flawlessly once this milestone is achieved. With core features, we’re thinking along the lines of making phone calls, using the address book, manage hardware functions such as network connectivity, volume, screen, time, language, etc.. Aside from these very core things for a phone, we want to provide decent integration with a webbrowser (or provide our own), app store integration likely using store.kde.org, so you can get apps on and off the device, taking photos, recording videos and watching these media. Finally, we want to settle for an SDK which allows third party developers to build apps to run on Plasma Mobile devices.
Getting this to work is no small feat, but it allows us to receive real-world feedback and provide a stable base for third-party products. It makes Plasma Mobile a viable target for future product development.

Basic Smartphone

The basic smartphone extends the feature set of Plasma Mobile to a wider group of target users. The plan is to add personal information management features, such as reading and sending emails, calendaring and reminders. We also want to add file management capabilities in this milestone, because we think that the user should be able to deal with the data in her phone in the most transparant way, and file management is something that allows users to look into the fabric of their data, and that of the phone itself. Another big topic for the Basic Smartphone milestone is extending the app ecosystem through third-party and original applications to allow the user to do more things with the device.

Featured Smartphone

For the featured smartphone, we want to add more system-level integration features such as deeply integrated private cloud storage and have grown our own ecosystem with more apps and of course games. An often requested feature is support for Android apps. Supporting Android apps could give Plasma Mobile a huge boost in terms of possible target groups, since it allows users to switch away from Android more easily, even when they are requiring a few apps and can’t really live without these. Being able to run Android apps on a Plasma Mobile device can ease the transition considerably and it allows us to capture potential target user groups that rely on proprietary services which Plasma Mobile, at first, cannot serve simply because as a smaller player, it’s not an attractive enough platform to have the likes of WhatsApp develop native clients for.

When it’s ready!?

On purpose, we did not add a specific timeline to this roadmap for two reasons: First, Plasma Mobile is a participative project, if you want to see something done, get involved. We’re not running the show all by ourselves. We want to create an open eco system where people who do the work decide on its direction. This means if you get involved, you can help us shape the future of mobile computing instead of being just a code monkey that does what someone else has decided. Secondly, we don’t want to deliver half-assed software just because we set a timeline. We want to create quality software to build products upon. If you or your company want to ship on a specific date, work with us and we’ll plan together. We won’t make promises when something is ready beforehand, but as an upstream project, we want to ship “when it’s ready”. This “when” depends on all our input and hard work. So don’t sit in your armchairs and wait for someone else to do the heavy lifting, but let’s get cracking!