Developer update #1

devupdate

#1

Hello Turris fans.

Welcome to our first developer update. This is suppose to be periodic summary of software development status from Turris team. Our hope is that this will give you look under our hands. Of course you can do that already using our Gitlab but in this format it should be more pleasant to read.

Previous month was a busy one. As you all probably know we revealed our new hardware design called Turris MOX. With beginning of this month we started campaign on Idiegogo with ambitious goal of collecting 250 thousands of USD. We hope that MOX will manage it. If you have use for additional small well network
connected device then give MOX a look.

Software in previous month was in name of 3.10 update. And as you might already know this is a big one. It contains new features we were preparing for almost four months and some of them were in pipeline for even a year. With this update we release all promised and not yet fulfilled stretch goals from Turris Omnia campaign. Well of course some of them are still not yet complete (such as Pakon) but we will continue on improving them.

Now let’s proceed to our developer update. Idea is to give you few sentences to inform you what some developers were doing. Not every developer will be noted here as he might just work on something less interesting, or not yet public, or simply be on holiday. Features and changes described in this topic will most likely not be in next update and they might not be even in later ones. This is real look under our developer’s hands.

@shenek, our Foris developer, is busy with something he calls “denucification”. Just to explain: Nuci is, and in close future was, configuration back-end that was suppose to add network configuration abstraction. But in reality it was just another layer between Foris and the rest of the system. It was designed to be general but for example without support for notifications. Because of that @shenek is replacing Nuci with Foris specific back-end called foris-controller. In RC (Turris OS 3.10) there is already Foris version that no longer uses Nuci for core parts. Lately he is busy with porting plugins (such as OpenVPN).

Michal LupeÄŤka, our web developer, was working hard on Foris Pakon plugin. Using Pakon plugin in Foris you can see where devices from your local network were connecting to. You can already test it now in RC (Turris OS 3.10). He was also working on our new Foris demo. This demo should show people interested in Turris what they can expect to see in Foris web interface and what kind of settings they can easily tweak that way.

@miska developed Foris Storage plugin. Using this plugin you can move LXC containers and Pakon database to external storage so that you won’t damage internal memory with excessive writing. Plugin will format your external storage and with reboot it will move all data in /srv directory on it. We highly recommend you to use it to mitigate possible internal storage wear out. It is going to be part of Turris OS 3.10. On top of Foris Storage plugin @miska was also working on Turris OS 3.10 and far future Turris OS 4.0.

@paja was busy with updating various packages for Turris OS 3.10 and with merging community contributions.

@mpetracek was working on Pakon. He located problem with part of the Linux kernel used by Pakon that was slowing down DNS query. See following topic (unfortunately only in Czech). He created workaround that is going to be part of Turris OS 3.10. On top of that he was also working on Sentinel.

@mprudek added few features to Netmetr such as support for GPS (not used in default configuration on router). But primarily he was working on Sentinel.

Both @mpetracek and @mprudek together with Robin Obůrka and Michal Mládek were heavily working on our new data collection platform called Turris Sentinel. This is going to be a modular system that should allows us to detect threats as fast as detection algorithms allows it. Currently our data analyses are implemented on top of database system. That introduces processing delay and problems with scalability. Turris Sentinel is based on data stream processing and that way shortens delays and allows us to scale whole system up not limiting us to shared database. This is all under heavy development and there is still a lot of work to be done before we release it but it looks promising.

@vojtech.myslivec, our system administrator, was lately preparing and testing deployment for Sentinel. He is using Ansible to manage our servers so he had to implement new roles for it. On top of that he was also working on automated deployment for web applications developed with Django.

I (@cynerd) was mostly working on updater. In Turris OS 3.10 there is change in how updater is invoked. Clunky and old updater.sh script was replaced with python library svupdater and with new python script updater-supervisor. I was also working on updating docker files in OpenWRT so they can build latest Turris OS 3.x.

One of kernel developers, Marek BehĂşn, is at the moment pushing support for Turris MOX to upstream u-boot (see: https://lists.denx.de/pipermail/u-boot/2018-April/326394.html). Together with @brill they both work hard with adding support for new Turris MOX to kernel and u-boot.

This is new format for us. Please leave a feedback if you like it or not. Also this update is little bit special as it’s the first one. It’s expected that all subsequent won’t be so long.


Bricked Omnia. How is it even possible, and how should one proceed in such a situation?
#2

Thank you for this thread, it’s great to see what’s happening.
Btw. is there any public roadmap? I can understand it’s difficult to commit some deadlines officially not to be chased for delays but at least very rough schedule of upcoming updates?
Thank you…


#3

Useful thread - where is the Czech version? :wink:
I would also welcome the roadmap (at least with the indicative deadlines).


#4

I’d rather prefer to get a rough planning (like “quarter 1/2018: …, quarter 2/2018: …” etc) now that most of the stretch goals are delivered. Maybe including percentage of completion if you want to show progress on specific threads of your development.


#5

Awesome. I love it :slight_smile:


#6

Thank you for this thread!

@updater: When you will release updater change, please, dont forget to add instruction for us, which did manual updates so far (and automatic ones turned off) into release notes :slight_smile:




#7

@blbeczech82, @Yearling and @ssdnvv: Putting together some kind of roadmap is hard for us as at the moment we have a lot of more or less internal rewrites lined up and projects that can’t have hard deadlines because we are not fully sure how long they are going to take. It is all around mox at the moment. But we will talk about how to put some roadmap together.

@Jirka: As I already wrote you. It’s refactoring. There is no need for some instructions. Simply when you update to 3.10 then updater.sh will tell you that it’s obsoleted and that you should use pkgupdate instead. And that is all you have to do. I still don’t understand what exactly you want from me.
Also I don’t understand why you still have automatic updates disabled. I understand that approvals were initially clunky but at the moment there is no reason to not use them.
Also as I wrote multiple times already. It’s not in our powers to support update from every single version. If you skip some fixup release then you can encounter problems as you are in not tested area. Just a reminder.


Mdadm package seriously outdated!
Mdadm package seriously outdated!
#8

Hm… OK, agreed, no quarterly planning.
But a roadmap with a status on your goals would still be preferable in my eyes.


#9

What is the “Plan B” if Indiegogo MOX campaign failed?


#10

What is the point in a goal (even with progress meter) without a target date to actually achieve the goal?


#11

It’s just to show on which topics(=goals) developers are working atm. (as there are no other real (stretch) goals anymore I think those goals might undergo several changes :wink: )


#15

This has gone very quite indeed… Would it not be a good time for update #2 and perhaps some insight of the

?


#16

Update #2 is here:


#17

Uhum right, beg your pardon for my senility…

If the update cycle is something like monthly than perhaps #3 is in the pipeline? Considering

the TO users might interested how things are progressing for that device.


#18

We are planning #3 but we intentionally not stated that it is some periodic thing. Plan is to release them when we have something to report from our development status. And thanks to final exams, summer, new born children and other reasons we don’t have whole a lot of to report. But be assured that we are planning to release more developer updates.


#19

It might be better to explicitly state that somewhere, say at the first post of a new topic “Developer updates” to better manage the expectancies :wink:
Congratulations to the new children though!


#21

The last update been in May 2018 - that is 4 months in the past

That implies that for the 4 past months there is 0 development?

And when that might be? With no improvement on the package maintenance of TOS 3.X and no news (roadmap) on TOS 4.X the outlook of ever escaping this status quo appears rather bleak.


#22

Hi,

I must to revive this topic as I found your comment really impolite.

Please bear in mind that developer updates are posts we prepare voluntarily on irregular basis just to approach our work to the users. We are trying to prepare the next update(s) but the code is on first place for us.

There is no correlation between amount of work done and developer update frequency.

Please moderate your emotion in future comments as these posts do not bring anything good. If you have any constructive feedback we will, of course, welcome it.

Thanks


#23

Yet another such bland statement. What exactly is impolite about it, if you may be so kind to elaborate?
The 2 forum members having liked the post must be impolite by association then.

No emoticon used, nothing else about even a whiff of emotion:

1 is a question
2 another question
3 and yet another question supplemented by my (user of your product) impression about the development status/transparency/outlook

How is that an emotional moderation?

Improve the package maintenance. Oh wait, I mentioned that repeatedly and being shunted for it. And thus maybe that is not sufficiently constructive, my bad entirely.


#24

Claiming that there is zero development while repeatedly proven wrong and even having some feature request fulfilled despite providing zero effort to contribute.