51 replies to this topic

[SpaceRat]

but I didnt know LEDE replace Openwrt. I've seen it now. thank you.

Not officially, there is still OpenWrt around, but most of the former OpenWrt devs are now directly participating in the LEDE project.

[WanWizard]

@daveraver,

 

Don't pay too much attention to Spacerat. He doesn't speak for us, is not a team member, and hasn't got a clue what is going on, what we do, and what we intend to do.

[SpaceRat]

Interesting.

What I was telling about OpenVPN on the box is basically just the same as what Erik Slagter said about it.
You should let him too know about him not having any clue, he might be interested.

BTW: I have absolutely no idea why an increasing number of box vendors has no interest in official image support from such a friendly team as OpenPLi *g*

[WanWizard]

I was responding to your statement
 

Usually, once images go into "stable" state, they are built against the same revision of openembedded for the rest of their life-time.

 
You are very well aware of the issues we've had over the last two years, and the work we're doing to overcome those. We've had this discussion before. No need too be so negative all the time.
 
I also don't know where this nonsense comes from:
 

BTW: I have absolutely no idea why an increasing number of box vendors has no interest in official image support from such a friendly team as OpenPLi

 

care to enlighten me?

 

There will always be vendors that want to make a quick buck, and are very happy that they don't have to put anything into software development because others like OpenATV will do everything for them. We are not interested in their commercial business, we have some basic requirements that vendors need to comply with, like a proper and working driver development team we can communicate with.

 

If vendors don't want to invest in that, fine by us, contrary to some other teams, we're not intrested at all in supporting as many vendors as possible, especially if you can't provide users with proper support because there is no-one that can fix driver bugs.

[SpaceRat]

I was responding to your statement 

Usually, once images go into "stable" state, they are built against the same revision of openembedded for the rest of their life-time.

And what is wrong about that statement?
That's a matter of fact and applies to all image teams.

The core OS (Linux+libs+utils) of OpenATV 5.3 is also (almost) the same as it was when it came out and the same applies to OpenPLi 4.0 (Just that the OpenPLi 4.0 core is even older).
For now, the OpenATV 6.0 (or OpenViX 5.0) core is quite up-to-date, the same applies to OpenPLi 5.0, but why should I lie to the users when it comes to their future?
There is already a newer OpenSSL in the "nextp3" branch for OpenATV, but OpenATV 6.0 is based on "oe-a 4.0" and not "oe-a nextp3", so there is no way I can tell, let alone promise, a user that he gets up-to-date libs.

 

You are very well aware of the issues we've had over the last two years, and the work we're doing to overcome those. We've had this discussion before. No need too be so negative all the time.

I'm not negative, I'm just a realist.
(Sadly) on an E2 box there are other/higher priorities than security.
If an OpenSSL update which appears mandatory from a security point of view would break e.g. CI(+) and/or softcams, any image team would opt for not merging the fix.

That's one of the reasons why an E2 box is only 2nd or 3rd choice when it comes to chosing a proper place for putting an VPN endpoint on (Especially when it comes to fake VPNs that are actually tunnel connections to the internet).
If you want, you can search the OpenATV and OpenViX forums and you will find that I'm telling the users there absolutely the same:
If you have the option to terminate the VPN on a Debian/Raspbian "server" or a decent router, e.g. running LEDE, use that instead of your E2 box.

E2 image teams will always focus on core E2 - live TV/radio, recordings, time shift - working well first, second on major plugins working well and only thirdly or later on any other updates.
That's ok, because the E2 box is a multimedia device ... but then it's also legit to tell the users to better use other devices for other tasks that are better suited for these tasks.

Edited by SpaceRat, 6 March 2017 - 16:00.

[WanWizard]

I'm just referring to the fact that "OpenPLi 4" isn't exactly the best reference, as it should have been retired about 15 months ago.

 

Other than that, I totally agree with your security observations, it has always been the viewpoint of the OpenPLi team that the STB is not a security device, and should not be made to act like one.

[SpaceRat]

I'm just referring to the fact that "OpenPLi 4" isn't exactly the best reference, as it should have been retired about 15 months ago.

Publish OpenPLi 5.0 and I'll instantly stop making statements based on OpenPLi 4.0
I can only comment what's available to the user ...

 

Other than that, I totally agree with your security observations, it has always been the viewpoint of the OpenPLi team that the STB is not a security device, and should not be made to act like one.

So actually there is nothing to disagree on with me ...

[WanWizard]

I wish we could.

 

We can't until all images can be build, there are still some vendors struggling with adapting their BSP to the new OE environment. We will as soon as that is addressed.

 

We're pushing as hard as we can.

[daveraver]

I wish openpli 5 too, since I had a vuplus zero, now formuler f1. gstreamer is 0.10 now, security items....the decision is yours, all images at same time, or all adapted boxes to pli5 now and when it were possible the rest of boxes. it takes too long time from announcing of openpli5 master to be still now on 4. Could you explain why all images at same time? why not progressively? I dont want discuss if its right or wrong, only why. thanks.

Edited by daveraver, 6 March 2017 - 18:11.

[WanWizard]

I think we can be short, we all want that, and we want that for a long time.

 

We don't want to get into a situation where we have to maintain two different codebases. We don't have the people to do that.

 

There is also a rebuild of our development environment planned. The current one is over 10 years old, and one of the issues at the moment is that all image versions are built from the same enigma and the same BSP, this makes making bigger changes, including OE upgrades, very complex and difficult. Also a reason why we can't have a 4 and 5 concurrently, so codebases need to be split, lots of OE recipes need to be adapted, buildservers have to be re-setup, etc.

 

The list is long, and most of the tasks have dependencies to each other, making it very complex. Add to this the fact that we need a group of people, as each has his own skills, at the right time, but everyone works only in his spare time. So from a planning point of view, it's an f'ing nightmare. The last thing we want is to stop building 4, and then get into a situation where we can't finish the rebuilding job, because that would mean no 4 and no 5.

 

So, in sort, it is a lot more complex that it looks from your end. But rest assured, we're working very hard to get out of this!

[daveraver]

ok, I can answer myself, you would leave out some of last models of vu+, I suppose it, and it will be an unrepairable error. greetings.

[daveraver]

I think we can be short, we all want that, and we want that for a long time.

 

We don't want to get into a situation where we have to maintain two different codebases. We don't have the people to do that.

 

There is also a rebuild of our development environment planned. The current one is over 10 years old, and one of the issues at the moment is that all image versions are built from the same enigma and the same BSP, this makes making bigger changes, including OE upgrades, very complex and difficult. Also a reason why we can't have a 4 and 5 concurrently, so codebases need to be split, lots of OE recipes need to be adapted, buildservers have to be re-setup, etc.

 

The list is long, and most of the tasks have dependencies to each other, making it very complex. Add to this the fact that we need a group of people, as each has his own skills, at the right time, but everyone works only in his spare time. So from a planning point of view, it's an f'ing nightmare. The last thing we want is to stop building 4, and then get into a situation where we can't finish the rebuilding job, because that would mean no 4 and no 5.

 

So, in sort, it is a lot more complex that it looks from your end. But rest assured, we're working very hard to get out of this!

I am sorry to have been so insistent, and thank you very much for your hard work, your explanations and for your patience.

greetings

David

Edited by daveraver, 7 March 2017 - 18:57.