592 replies to this topic

[Ev0]

I know that with the current implementation there is no partitioning.

But OpenPLi is talking of a small footprint recovery image, isn't it the goal with this recovery image to create real slots (partition) in the flash?

If not what is the interest of this recovery image?

I'm not aware of it being the goal. Certainly not from the view of OpenBh or OpenVix teams.

If partitioning the flash was the goal, then it would have been easier to just use the bpanther method imo.

 

I thought OpenPLi team just wanted a minimal recovery image, for Slot 0, so the least flash space was being used for this purpose.

[Huevos]

I know that with the current implementation there is no partitioning.

But OpenPLi is talking of a small footprint recovery image, isn't it the goal with this recovery image to create real slots (partition) in the flash?

If not what is the interest of this recovery image?

I not aware of that ever having been the goal. The requirement of the recovery image was only that it is smaller.

 

Neo thinks stripping it is absurd, but it takes just a few seconds to run the OPKG filters and there is no need to do anything in the core or to create an an additional image for each box. Maybe PLi has resources to waste on this but we don't.

[littlesat]

Openpli is already the smallest image… so as it is now you should install openpli in slot 0.
The real goal is to create a kind of real recovery situation. Then you do not need a real enigma2 image in slot 0.
You need just to have something where you can flash online and select a slot.
To ensure the box can be flashed via the manufacturer’s method I think making partitions is not a good idea that should be considered.
And yes to get this really right without work-a-rounds it needs indeed some time and recourses.

Edited by littlesat, 9 June 2023 - 17:00.

[Ev0]

Openpli is already the smallest image… so as it is now you should install openpli in slot 0.
To ensure the box can be flashed via the manufacturer’s method I think making partitions is not a good idea that should be considered.

Manufacturer method is to flash with usb, nothing is stopping you doing that right now with or without a recovery image.

Edited by Ev0, 9 June 2023 - 17:09.

[littlesat]

Yes… but when the flash has partitions it might go wrong… so there might be a danger here?! With the subdir is fine….

[Ev0]

Yes… but when the flash has partitions it might go wrong… so there might be a danger here?! With the subdir is fine….

Nobody is working to add partitions, so why is this even being discussed ?

[Huevos]

Openpli is already the smallest image…

Yes and when you get to Python 3.11 that won't be true any longer.

[littlesat]

Why not?’as openpli8.3 is smaller ?

[Huevos]

Because *.pyc from python 3.11 is almost double the size compared to those from 3.10, due to optimizations for higher speed and more granular debug.

 

Python 3.11 is between 10-60% faster than Python 3.10. On average, we measured a 1.25x speedup on the standard benchmark suite.

 

PEP 657 – Include Fine Grained Error Locations in Tracebacks

 

PEP 657 – Include Fine Grained Error Locations in TracebackPEP 659 – Specializing Adaptive Interpreter

 

*.pyc files are larger than they need to be #99554

[Pr2]

Because *.pyc from python 3.11 is almost double the size compared to those from 3.10, due to optimizations for higher speed and more granular debug.

 

Python 3.11 is between 10-60% faster than Python 3.10. On average, we measured a 1.25x speedup on the standard benchmark suite.

 

PEP 657 – Include Fine Grained Error Locations in Tracebacks

 

PEP 657 – Include Fine Grained Error Locations in TracebackPEP 659 – Specializing Adaptive Interpreter

 

*.pyc files are larger than they need to be #99554

 

But then every images will increase in size too as long as they switch to Python 3.11 too.

[Pr2]

Yes… but when the flash has partitions it might go wrong… so there might be a danger here?! With the subdir is fine….

 

Yes and other team already cover it by backing up the subdirs when flashing slot 0, so why not align with what other teams does?

[rantanplan]

Python has almost no influence on the size of the image.
The size changes by the environment of things used.
Samba version
FFMpeg
GST
gcc/glibc
used are much more important than the simple Python code.

 

[Huevos]

Python has almost no influence on the size of the image.
The size changes by the environment of things used.
Samba version
FFMpeg
GST
gcc/glibc
used are much more important than the simple Python code.

 

Really? So why do we get around 30MB through stripping the python plugins?

[Huevos]

 

Because *.pyc from python 3.11 is almost double the size compared to those from 3.10, due to optimizations for higher speed and more granular debug.

 

Python 3.11 is between 10-60% faster than Python 3.10. On average, we measured a 1.25x speedup on the standard benchmark suite.

 

PEP 657 – Include Fine Grained Error Locations in Tracebacks

 

PEP 657 – Include Fine Grained Error Locations in TracebackPEP 659 – Specializing Adaptive Interpreter

 

*.pyc files are larger than they need to be #99554

 

But then every images will increase in size too as long as they switch to Python 3.11 too.

 

As software evolves it gets bigger. That is a fact of all the base programs we use that are beyond our control. The reason PLi is smaller is because it is about 3-4 versions behind in all the software it uses. Pli is 3 bitbake versions behind OE-A. That itself is worth about 30 MB in the image.

[rantanplan]

Really? So why do we get around 30MB through stripping the python plugins?

 

 

You compare a complete image in a different build environment and conclude that python3 alone is the trigger.
That's wrong.

To make a careful comparison, one should update the version alone.
This would also be possible in the hardknott branch.

[littlesat]

Yes and other team already cover it by backing up the subdirs when flashing slot 0, so why not align with what other teams does?
->
Because this is the work-a-round at least the way it is implemented. Maybe we need to wait for the creator of ofgwrite to include it in there as I think this is a better place to put it in a ‘better stealthy’ way.
It is or having a real recovery mechanism or just give the feeling and behavior for the user that the special slot behaves as a normal slot.
I only want to discuss…. To get agreement… so I put more options on the table. Before something is made….
Making a small image with just what is needed is one idea… and indeed for an image where you just need to flash and select an image you can remove a lot of stuff even when it is enigma2 ‘based’ then you do not need all the python files.
make it as is in a more ‘stealthy’ way is another approach.

Edited by littlesat, 10 June 2023 - 11:44.

[Huevos]

 

Really? So why do we get around 30MB through stripping the python plugins?

 

 

You compare a complete image in a different build environment and conclude that python3 alone is the trigger.
That's wrong.

To make a careful comparison, one should update the version alone.
This would also be possible in the hardknott branch.

 

I didn't say that was the sole reason. We inspected the PLi image and know where the size differences are.

[Huevos]

Yes and other team already cover it by backing up the subdirs when flashing slot 0, so why not align with what other teams does?
->
Because this is the work-a-round at least the way it is implemented. Maybe we need to wait for the creator of ofgwrite to include it in there as I think this is a better place to put it in a ‘better stealthy’ way.
It is or having a real recovery mechanism or just give the feeling and behavior for the user that the special slot behaves as a normal slot.
I only want to discuss…. To get agreement… so I put more options on the table. Before something is made….
Making a small image with just what is needed is one idea… and indeed for an image where you just need to flash and select an image you can remove a lot of stuff even when it is enigma2 ‘based’ then you do not need all the python files.
make it as is in a more ‘stealthy’ way is another approach.

??? We already added code to ofgwrite for kexec.

[littlesat]

When it is in ofgwrite we also should get it…

[Huevos]

When it is in ofgwrite we also should get it…

Kexec has been in ofgwrite since 3 months ago. How else do you think you are using it?

 

https://github.com/o.../commits/master

Edited by Huevos, 10 June 2023 - 20:34.