• 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)

So my blog has been dormant for some time, and in that time I’ve had a variety of hardware failures etc. As such my previous nanoc based site was lost. Thankfully all the content was stored in git so was easy to recover. I thought if I’m going to restart blogging I might as well look at a different platform, and it looks like all the cool kids are using Hugo so here we are.

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

Let’s look at these steps in detail.

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!

Last semester I founded the AG Open Source at our university. We are organizing workshops and hackathons in cooperation with open source projects/ companies. Our students should learn more about open source development and how to contribute. The difference to the Friedrich-Alexander-University and their professorship in open source development is that we want to learn the real practice by professionals.

After 3 months we had a reputation. The AG Open Source should be open for other faculties, too. EFI (electronic – fine mechanics – information technology) has been interested for our events. So students in Computer Science and Electronics are receiving basic courses in Linux and using git. In addition, we create a program which is different every semester. Last semester we had topics like security and the ownCloud hackathon. This semester our focus is on monitoring and docker.

I am the Lead of the AG Open Source. I am educating other students in the student council for different positions in the AG. We need an additional lead. So I have one student as a Junior Lead who is being taught in organization, email writing and publishing by me. Two other students want to become Linux Trainers. They  have to know all about the cooperation with other  AGs in the student council and their processes, too.

Last semester I was the Linux Trainer in all Linux workshops. One (advanced) student supported me with running through the lines and looking for different students. Other students in my semester are interested for this job this semester, too. Last week we received the request for a Linux course for advanced Linux users parallel to the Linux course for beginners. So I am teaching one student to pick up my course for beginners. Next semester we’ll use 2 rooms for this event. I’m planning the course for Advanced Linux Users.

 

Since this week we are responsible for a new task at our university: Linux

support for students

A EFI student stood in the door of our student council for Computer Science and said: „I’m not from this faculty, but I need Linux support by the AG Open Source. Nobody else can help me. I was in the data center. They want to support only Windows. I can’t find anybody at our faculty, too.“

The data center has reconfigured eduroam. That’s the Wifi for students and professors. We need additional entries for Linux systems and a new certificate now. I configured his Wifi and I know: I have to educate Linux Supporters for our AG. On our internal homepage openSUSE and Android are listed as supported operating systems (Linux) by the data center, but our Sysadmins don’t know what to do there. All students are coming to the student council for Computer Science now, because they are receiving Linux workshops by us.

Our AG Open Source is growing, but our responsibilities are growing, too!

 

 

The post AG Open Source and our responsibilities first appeared on Sarah Julia Kriesch.

If you are travelling to Prague to ELCE, and have Nokia N900, N9 or N950, or spare parts for them, please take them with you. I may help you install postmarket os there (https://wiki.postmarketos.org/wiki/Main_Page), can probably charge N900 that does not charge, and spare parts would be useful for me. I have a talk about cameras, and will be around... https://osseu17.sched.com/event/ByYH/cheap-complex-cameras-pavel-machek-denx-software-engineering-gmbh .

Ok, so I have various machines here. It seems only about half of them has working RTC. That are the boring ones.

And even the boring ones have pretty imprecise RTCs... For example Nokia N9. I only power it up from time to time, I believe it drifts something like minute per month... For normal use with SIM card, it can probably correct from GSM network if you happen to have a cell phone signal, but...

More interesting machines... Old thinkpad is running without CMOS battery. ARM OLPC has _three_ RTCs, but not a single working one. N900 has working RTC but no or dead backup battery. On these, RTC driver probably knows time is not valid, but feeds the garbage into the system time, anyway. Ouch. Neither Sharp Zaurus SL-5500 nor C-3000 had battery backup on RTC...

Even in new end-user machines, time quality varies a lot. "First boot, please enter time" is only accurate to seconds, if the user is careful. RTC is usually not very accurate, either... and noone uses adjtime these days. GSM time and ntpdate are probably accurate to miliseconds, GPS can provide time down to picoseconds... And broken systems are so common "swclock" is available in init system to store time in file, so it at least does not go backwards.

https (and other crypto) depends on time... so it is important to know approximate month we are in.

Is it time we handle it better?

Could we return both time and log2(expected error) from system calls?

That way we could hide the clock in GUI if time is not available or not precise to minutes, ignore certificate dates when time is not precise to months, and you would not have to send me a "Pavel, are you time traveling, again?" message next time my mailer sends email dated to 1970.

By Greg Kroah-Hartman, Chris Mason, Rik van Riel, Shuah Khan, and Grant Likely

The Linux kernel ecosystem of developers, companies and users has been wildly successful by any measure over the last couple decades. Even today, 26 years after the initial creation of the Linux kernel, the kernel developer community continues to grow, with more than 500 different companies and over 4,000 different developers getting changes merged into the tree during the past year. As Greg always says every year, the kernel continues to change faster this year than the last, this year we were running around 8.5 changes an hour, with 10,000 lines of code added, 2,000 modified, and 2,500 lines removed every hour of every day.