Posts by chewitt

    I am after true 4k or as close to true 4k as I can get in Linux.

    4K is nothing more than the dimensions of the image. Both GLES and GL support 4K output. Current LE releases use GLES and there is nothing wrong with GLES. Future LE images will probably switch to GL, and there's nothing wrong with that either. Two different code-paths that use slightly different technologies to basically achieve the same thing.

    If you mean 'HDR' output? HDR is only supported on GBM images (Generic) not X11 (Generic Legacy); and it is supported whether the image is LE12 (GLES) or LE13 (could be GLES or GL) as the rendering method isn't important.

    what's the chance to get it transformed in to a "zombi" machines? To be used it by others for something "bad"?

    I've also dropped a couple of LE devices with default passwords into deception/honeypot type environments where red-team staff and/or real attackers are active. Both gained access to the system(s) using password dictionary lists; the attackers were faster than the red-team staff who took some time to figure out what the device was (and thus guessed the password correctly first time) but the attackers using a dictionary list were noisier and easily detected. The red-team folks poked around, but perhaps knowing what the distro was didn't bother to do much. The real attackers dropped exploit tools into /tmp and then failed to do anything because the tools assume Debian or RHEL and fail because a) we're neither of those, b) most of the filesystem is read-only. The attackers spent a little time trying to tweak their scripts based on some wrong assumptions but quickly gave up and moved onto more-promising targets in the environment.

    Now, obscurity is not security, but unless someone explicitly writes exploit tools that work on LE, the default (and automated) tools that most attackers use don't work, and LE is niche enough that I doubt someone will make the effort to write ones that do: as the total number of exploitable devices (visible to any attacker with a shodan account) means the 'ROI' of the effort is poor. The possible exception is a nation-state actor who might take the time to develop unique tooling for a campaign. However if you're a person-of-interest for those folks, you're fcuked anyway, and the insecure LE box in your network is the least of your problems. So the real-world risk for the small number of users dumb enough to expose their box to the public internet; is someone deleting some/all of their Kodi config and/or whatever media files exist on /storage.

    @Yasai-san I've submitted PR's to update the patch we use for the XU4 defconfig in LE13 (2025.04) and LE12 (2024.01). I've not boot tested either defconfig but the problem and fix are obvious (hopefully). The LE12 change can be cherry-picked for Lakka to resolve the issue for Lakka v6.x too.

    Thanks for the report and the detective work. I guess it slipped through the net as a) few people use the XU4 image with LE these days, and b) the few that do use the XU4 image probably first-installed an older release with working u-boot and then updated to newer OS versions over time, and updates don't touch the u-boot version.

    EDIT: I've not seen your patch until after I've submitted the PR's to our repo. It's better to regenerate the whole patch against the upstream u-boot source as u-boot make periodic "resync" changes that change/move items around in the file. This time I also made some cosmetic changes to the XU3 defconfig too; the idea being that future resync changes might cause the XU3 patch hunks to break and thus flag the need for the patch to be updated again (although it's a long-shot).

    I won't be suprised if there's a bug in profiles as it's a neglected/unloved and not well maintained part of Kodi's vast codebase. It is known to be imperfect and need work, but until someone volunteers themselves for the task that's how it remains. It's best you post the bug report in Kodi forums as it won't be an LE specific issue and it's not something LE can fix.

    Please (re)post the PVR issue in the Kodi forum. Provide English text (Deepl) and the original German text to ensure the context is correctly understood (the main developer who needs to read it is German).

    Kodi has some changes for speaker placement markings. The presentation will probably correct itself over the next couple of weeks as the bugs are ironed out. Ignore that when posting in the Kodi forum - focus on the main issue.

    These machines usually are connected to internet

    That's not correct. Most machines are in a home LAN behind a NAT router so unless the user explicitly port-fortwards or configures a VPN which results in the device having a secondary (external) IP address they are not exposed. Only a tiny percentage of our active userbase have devices exposed. I periodically check shodan scan results and the number of exposed systems is small, stable, and has been slowly declining over time.

    Devices need to use passwords when connecting and/or reauthenticating to the network. This happens in normal use. It happens a lot more frequently when signal/connectivity is poor; and RPi boards generally have poor(er) connectivity before we place them into cases that reduce it further. So the short answer is "nobody knows" (could be any and all of the items you've listed) but if the issues reduce when moving boxes closer to the router, it's probably the normal issues seen with RPi boards, and the solution(s) are moving things closer, using an external wifi dongle with better connectivity, using ethernet instead of wifi, etc. etc.