74 replies to this topic

[malakudi]

Please stay on topic. I think any "team" who has contact with VU+ should get an official reply about this "pau" binary. And why there are different versions of it.

[Rob van der Does]

Why do you always cut discussions off when it doesn't suit you?

I don't. I just don't want to go into your provocations, as they serve no purpose. And I want to saty on-topic as much as possible.

 

In this on-topic part I only pointed you to the missing link in the PLi images, that would allow recording and streaming.

Edited by SatKiekerd, 8 January 2015 - 16:54.

[Erik Slagter]

Please stay on topic. I think any "team" who has contact with VU+ should get an official reply about this "pau" binary. And why there are different versions of it.

I've tried this pau binary and yes it works, but I don't think it comes from VU+. That would be a bit silly wouldn't it?

Edited by Erik Slagter, 8 January 2015 - 17:40.

[athoik]

But meta-vuplus belongs to vu! So the meta-bsp misses that and others (eg blind scan)..

[malakudi]

So for OpenPLI it should be added as 3rd-party-plugin maybe?

[Rob van der Does]

So Erik thinks this binary has been invented by a third party

I can assure you it is genuine VU+ and they provided it to overcome exactly the in this thread reported issue.

[Erik Slagter]

(obsolete)

Edited by Erik Slagter, 8 January 2015 - 17:43.

[Erik Slagter]

So Erik thinks this binary has been invented by a third party

I can assure you it is genuine VU+ and they provided it to overcome exactly the in this thread reported issue.

Whatever you say. I still think it would be quite silly. Whatever we get from VU+ is in the BSP and that's it.

[Rob van der Does]

Yeah, silly or not, but it is what it is. I can't change the world, and nor can you (I think). We must simply make the best of it.

[malakudi]

@SatKiekerd: It's more than obvious that it is from VU+, since it "talks" with the driver in a secure way with AES keys which only VU+ would know. But it's also obvious that VU+ tries to not be associated with it, and since it is VU's responsibilty the BSP layer for OpenPLi, they do not deliver this. I guess that they delivered it to OE-Alliance or Blackhole etc because they cannot be directly related to this.

 

However, the whole situation is quite disturbing. Having a tax to all recording capable devices is silly, but VU+ approach to "skip" this is also silly.

[Rob van der Does]

I agree.

But anyway: you can use this silly solution just as other imagage builders do.

 

BTW: You know that for the very same reason some brands have a modem incorporated, so the STB can be sold (or better imported) as modem.

[Huevos]

Y [...]  'accepting code' isn't the same as cooperating.

Agreed, OpenPLi and OE-A "borrow" code from each other... but no joint ventures for the common good. And I for one do contribute quite a bit of code to OpenPLi even though I don't use the image personally.

 

W [...] You know very well why we don't let OE-A dictate how we operate, exactly because of a difference in opinion about standards.

Is this OpenPLi snobbery? You only need to look at the number of reverts on the OpenPLi GiT to know standards aren't as high as they could be. And at least we run a "Dev" branch in E2 so all new code in E2 gets tested before being merged into the "release" branch. Only stuff that goes straight to "release" is bug fixes and code that has already been tested by the Dev team.

[WanWizard]

That is something that bugs us as well.

 

The idea when we switched from releases to nightly's was that only people who were willing to test would update daily, given the unstability of the nightly's. And everyone else only when there is a declared stable situation.

As it turned out, everyone blindly pushes the update button, ignores all the warnings, then shout, complain and moan that their actions leave the box in limbo.

 

Since nobody is willing to understand that, we're currently reviewing the situation, and will probably revert back to only stable releases and a separate, possible non-public, test environment. Non-public, because as things stand, the same people that now ignore all warnings will be installing public unstable images too, which means the moaning and groaning will be here to stay. Not how I would like to see it, but that is how it is. If it is up to me (but it isn't), access to dev images will be by invitation only.

 

My previous remark has nothing to do with snobbery, but with the refusal to introduce dirty hardware specific hacks. It makes a mess of the code, it makes the core unstable and slow, and it doesn't force the vendors to clean up their act. And since E2 is already a horrible undocumented bowl of old spaghetti, you would want to avoid that.

[Huevos]

The refusal to introduce dirty hardware specific hacks. It makes a mess of the code, it makes the core unstable and slow,

When is a hack a hack? And a dirty hack a dirty hack? We are always going to need hardware specific forks in code because different manufacturers and different STBs use different hardware. I can understand your desire to avoid hacks to get around faulty closed source code, but if you want to take full advantage of the receiver it is the only way. For example the Blindscan binary of all manufacturers is only compatible with universal LNBs, so couldn't be used for C-band. It was easier to just sort this out in the Python code than go to every manufacturer and ask them to sort out the binary. And the outcome was we the users (who do this for a hobby) could make better use out of the hardware we purchased.

Edited by Huevos, 9 January 2015 - 00:10.

[WanWizard]

No, it is not the only way.

 

This is why we introduced the BSP layer, and this is why we work very hard with the vendors to make sure all vendor specific stuff moves to the BSP layer. So you can get rid of the complex "if this box then do something special" mess in the code.

Not all vendors move at the same speed, especially VU+ needed a lot of convicing, but even they are slowely getting around.

 

I know it is easier, at least at the short term, to hack your way around instead of trying to convince the vendors they have to do something right, but this is exactly where the problem starts. And we refuse to do that.

 

This complexity, all these workarounds, and all the dependencies and conflicts between them (and this problem extends to the horror that is called a plugin) has caused us all to waste our valuable spare time working on this stuff, instead of on fundamental improvements to the E2 architecture, which is really needed to make better use of the hardware. And the more vendors and the more boxes you want to support, the uglier it gets.

 

This is true not only for E2 itself, but also for additions to it. Take for example the WebIf. How much easier would it be if its developers won't have to deal with all vendor stuff, but the vendor could include it's specific stuff (interface code, RC image, box image, etc) in the BSP. Then the OpenWebIf developers could dedicate their time to making the WebIf more functionally rich and awesome, instead of trying to figure out why the Duo2 has a transcoding icon, but the ET10K doesn't.

 

Don't forget there is a very nasty commercial business behind this all. All these vendors are laughing all the way to the bank that there are some "stupid" hobbyists that spend all their free time increasing their sales margins. Vendors crawl over each other at our front door to have an OpenPLi image for their box, simply because it significantly boosts sales. I'm pretty sure some other popular images see the same.

 

We refuse to play that game. Although for us it's not a commercial business, we want to deliver a product we're happy with, nee proud of, and if we can use the popularity of the OpenPLi brand to make the vendors carry some of the effort too, then we'll end up with a significantly better product, which is good for parties at both sides of the table.

 

And we have to look at ourselfs as well. There are a lot of very good developers out there, but instead of really working on an open source project, they all fork the code, and start re-inventing each others wheels. Which is an enormous waste of time and talent. If we all could come to an understanding that instead of all these forks it would be better to work on a single product, there would be dozens of very talented developers available to make "the E2 product" absolutely awesome.

 

This was our main idea behind going from PLi to OpenPLi and be completely open. And this can only be archieved if we can get rid of all vendor specifics in the code, which has been our main focus for the last year (or so).

 

This requires not only a lot of blood, sweat and tears trying to steer the vendors, it also requires the developers to come up with solutions to move all vendor specifics to the BSP. Like in the example of the WebIf, that will only work if its developers will make the WebIf modular, with a separate class or package for vendor specific stuff, and with a clearly defined interface and implementation, so every vendor can easily add it to their BSP.

[Rob van der Does]

...... And at least we run a "Dev" branch in E2 so all new code in E2 gets tested before being merged into the "release" branch. Only stuff that goes straight to "release" is bug fixes and code that has already been tested by the Dev team.

And this turns out to be using the best of two worlds: fast (daily if you want) public updates of 98% already tested stuff; more complicated stuff goes via testing test-builds from the dev-branch before stuff is committed to the master-branch.

[malakudi]

@WanWizard: I think that a stable release plus an experimental release (like Debian does - actually Debian has 3 of them, stable/testing and experimental) is the best way for development and for the users. But there is no reason for experimental to be "private" for beta testers only. The Debian way has worked well, anyone brave enough can use the experimental release, but he will know that he can't cry out loud for his decision. As it is now, the people are shouting because they do not have the "stable" alternative. For example, let's say I know that image from 1st November is stable. Even if I have it as a backup (because it is no longer available in OpenPLi servers), there is no way to install it and add some kernel modules (USB DVB-T for example) because the development has switched to a newer kernel and old modules do not exist. If people have a "stable" option, they will not shout for experimental.

[Erik Slagter]

Personally I am not a fan of the debian model, because, in practice, it means the "stable" branch could better be named "obsolete". It's something we're still talking about. You'll see how when it's ready

[athoik]

Totally agree, beta/experimental is the best option.

Eg with experimental we can test newer GStreamer like OpenATV does from our work here...

[malakudi]

debian stable also has the backports branch, and most important updates are delivered from testing to stable. I use stable+backports on all the systems I administer and most important software is up to date, maybe not cutting edge, but up to date. For example, stable still has 3.2 kernel but stable+backports is 3.16.