24 replies to this topic

[neo]

Dreambox continues to develop their own Enigma2 version. They use their own, new kernels as the basis in Enigma2 (OE 2.5, OE 2.6 kernels, etc.).

 

You're mixing up a few things.

 

OE = OpenEmbedded = the basis of the linux distro used by all STB manufacturers and image makers.

 

2.5 etc are old OE version numbers, that do not exist anymore but are stubbornly used, especially in the German scene. OE has been merged into Yocto quite some time ago, and they use codenames for releases. You can find the mapping between the codename and the old versions numbers here: https://wiki.yoctopr...g/wiki/Releases

 

OpenPLi 8.x is based on Zeus (3.0), OpenPLi develop is currently based on Hardknott (3.3), but it hasn't been decided whether that will be the version OpenPLi 9.0 is released on.

 

A linux distro consists of three main components: the Linux kernel, the toolset, and the GUI (optional).

 

In the STB world, the linux kernel version is dictated by the manufacturer, because the hardware drivers are only supplied in binary (the source is under heavy NDA) and therefore compiled against a specific kernel.

 

This is why for example older STB's still run a linux 3.x kernel, the manufacturer never updated. It also means that STB's are inherently insecure, as all those kernel bugs and vulnerabilities are never fixed.

 

Dream, as manufacturer and posessor of the NDA's, can use any linux kernel version they want, as long as they can compile the drivers for it.

[s3n0]

@neo:

 

You don't really have to explain this nonsense to me .

 

If there is an Enigma2 built on the OE 2.5 or OE 2.6 core, then I know that it is a Dreambox, the new original version of the E2 core.

 

And if I write that E2 is built on the basis of the OE 1.6 or 2.0 core, as a developer it is clear to me that this is the classic open source Enigma2 GUI version of the core.

 

And then I know how to build my plugin . It is clear to me that whether it is Enigma2 built on the old core or on the Dreambox core. As a plugin developer, I need to be able to differentiate between core-based Enigma 1.6, 2.0, 2.3, 2.5, 2.6+, etc. ...... but as a developer, I may not be interested in anything more . You know ? The plugin must work always and everywhere.

 

If there are other, specific E2 cores, which are also completely different from the "standard" E2 core (the one based on 2.0), where their own rules are formed (like in VTi, for example), then this is just useless and another chaos. I usually ignore it or I prefer to delete the function from the plugin source code completely so that the plugin works correctly in every Enigma2 distribution.

 

The fact that the creators of the open source Enigma2 came up with their own labeling of the Enigma2 core is of no interest to me personally. The changes are very small and unfortunately do not copy the changes at all (such as from the original OE 2.6 from Dreambox). If compatibility is not maintained, compatibility and universality problems arise when using many plugins (xxxxxx_all).

 

From my perspective as a developer, I know that Enigma2 / OpenPLi, for example, is built on the basis of OE 2.0. And that's what I need to know.

 

If Enigma2 OpenPLi was built on the basis of the OE 2.6 core (OE 2.6 compatibility), then I would not have to modify the plugin so that it works separately in each Enigma2.

 

This is indeed the case, namely that the Enigma2 open source development teams already use their own, new, superior version numbering (4.4 for example) and even new "based" cores, as copied coress from other developers. This creates incredible chaos in the world of Enigma2.

 

Of course, in the case of OE 2.0, it is an always updated and newer  core than the ancient 2.0 (which existed years ago and was maintained by Dreambox). Even if the Enigma2 development teams label it differently, for me it is important that it is an Enigma built on the basis of OE 2.0.

 

Similar opinion also exists in the OS-Windows world. Kernels like 95/98/98SE were virtually identical. The same was true for NT/2000/XP versions, for example. And then came the new kernel of Windows 7/8/8.1/10/11 systems where the kernels are also almost identical. I don't care about code names, I don't care about "what's new", etc. . As a programmer, I was only interested in the fact that it was not even necessary to rewrite the system driver under one compatible kernel... just a few lines and it was done. However, when you wanted to change the system driver intended for Win-98, for example, and transfer it to Win-10, it was an incredibly big problem. Therefore, for me, as a programmer, it is important to know how to distinguish kernels, as a developer. And not like Wikipedia ;-).

 

If you have a detailed list of all changes related to the Enigma2 GUI core by version or by some builds or something... please show it to me. I will be happy if I know concretely all the changes in E2 versions of different builds from different development teams. I will be able to maintain compatibility in the plugin. Thank you in advance.

[neo]

This isn't nonsense. Linking an OE version to an Enigma version is nonsense.

 

For a Plugin to work you need three things:

1. The Python version used in the image to be compatible
2. The Enigma API to be compatible with the requirements of the plugin
3. All dependencies are in place (in particular required python packages)

None of this has any relation to either the Linux kernel version, or the version of OpenEmbedded used.

 

It looks like you've bought into the DMM bullshit, and lack the knowledge to identify it as bullshit.

 

OpenPLi has been independently developing Enigma since 2007 (when we got the first manufacturing samples of the 7025), and Dream Multimedia code has been closed source since 2011.

 

How you can be so naive to think that while everyone has been developing Enigma independently from one another since then can maintain the same versioning and API compatibility is beyond me.

 

Sounds like you're still stuck in the "blue panel" era, where teams didn't do anything to Enigma itself, but bolted everything on with plugins.

Edited by neo, 9 May 2023 - 18:53.

[s3n0]

Oh... so that's why over the course of 3-4 years, I had to deal with such huge inconsistencies in compatibility to make the E2 plugin work everywhere... O.K. ?

 

I only need to know the OE version. I don't need to know its codename, I don't need to know who is the creator of which Enigma2 distribution, like who came up with the new version numbering, ... etc. . I just need to identify the differences between the prehistoric versions of the E2 cores, the current open-source versions and the current Dreambox versions.

 

Try to make a plugin that will be compatible for all Enigma2 and you will understand what I am writing about. Until then, I can't talk to you about plugin compatibility in all Enigmas (their cores).

 

Also there are big differences even in the used SKINs, as the creators of SKINs break the unwritten rules and change everything by themselves . For example, they enforce some font types and sizes... and so on. And similar problems also arise in Enigma2 cores, with some differences. Some Components in Screen classes (layers) do not work exactly the same there. There is a lot that doesn't work properly just because everyone is making up their own Enigma2 distribution. I'd rather not even comment on this. I'd just get mad again, ha ha.

[neo]

You still don't get it.

 

I am not debating that there are differences between the different forks, that is inevitable after all these years, and without access to Dreams codebase.

 

I am only saying that calling a particular version of Enigma "OE <version"> is total and utter bull, as the OE version has nothing to do with the Python application called Enigma that runs on top of it. And that because of the diversion, attempting to assign some fictional version to a particular Enigma codebase is idiotic. There are even people running Enigma on a PC linux distro, where OE doesn't even come into play.

 

If you have a plugin you have made for what you call OE 2.5. and I take our enigma2, branch develop, and I build that using OE 2.5, are you saying your plugin will work automagically? The Enigma code becomes magically compatible with Dreams private code?

 

The obsession in Germany for OE naming comes from Dream Multimedia, who used to release images per OE version. No other image builder does, and never did.

Edited by neo, 9 May 2023 - 22:06.