d3Xt3r

If you were looking for answers to such questions 10 years ago, your best resource for finding a thorough, expert-informed response likely would have been one of the most interesting and longest-lasting corners of the internet: Quora.

I disagree, the best place for such answers used to be Reddit, and Stack Exchange for the techy stuff. Quora always felt like cancer for some reason and I never really used it.

The ability to unlock the bootloader is actually irrelevant in this case. I want the source code because it is my right. I might find away to boot custom code or I may not.

And what will you do with it exactly? Without unlocking the bootloader, it's basically useless. You should concentrate your efforts on seeing if you can unlock the bootloader first.

Either way I still want the sources to study at least.

There wouldn't be anything interesting about those sources, except the binary blobs/DTB. Unless you're expecting to find some malware or something. If you're really interested in studying the kernel/Android sources, you can always head to https://source.android.com/ or https://kernel.org/. There are also more interesting sources over at LineageOS and GrapheneOS.

As for streaming services I use Jellyfin so its not a big deal.

Then why did you even bother buying this box? You'd have been better off using a Raspberry Pi or some HTPC, where you could load any opensource distro or even easily compile your own, and have a far greater deal of flexibility and freedom.

Getting the source code is only one piece of the puzzle, before you do that, have you checked if the bootloader is unlockable? Because if you can't unlock the bootloader then there's no point trying to get the kernel sources.

You should also bear in mind that if you unlock the bootloader, you'd be degrading Widevine to L3, which means the video quality of Netflix and other streaming services would be downgraded to SD. One of the main reasons why people buy these TV boxes (instead of using a Raspberry Pior something) is to watch streaming services - but unlocking the bootloader breaks the DRM, which would defeat the whole point (IMO) - unless you don't plan on using those services?

At 700MB, it can no longer be called "damn small", especially considering there are much smaller distributions out there, such as TinyCore @ 23MB and SliTaz @ 43MB (yes, SliTaz is still around).

There's a Dolphin plugin for this: https://github.com/Nyre221/dolphin-quick-view

FWIW, I've had no issues here with my Lenovo ThinkPad Z13 and Fedora 39 (Bazzite).I use my 8BitDo Ultimate Bluetooth controller almost daily as well as my Sony WH1000-XM5 headphones, both work just fine.

I'm on BlueZ v5.72 and kernel v6.6.14

What distro / kernel / BlueZ are you on? If you're not on the latest BlueZ and/or a recent kernel, you should update them.

I think they probably meant the AOSP Camera, or certain Snapdragon camera variants bundled with some LineageOS builds.

Those are some nice improvements! Especially this one:

Creating new files is faster by up to 15%, opening normal files by up to 20%, and opening large files by up to 15%.

Have you not watched the famous Linus Torvalds video on this? If you haven't, here's a nice upscaled version: https://www.youtube.com/watch?v=xPh-5P4XH6o

But yeah, there's a good reason why most of us here avoid nVidia.

It's macOS's graphics API, like how Windows has DirectX and Linux has Vulkan.

The permissions should be mapped to your Linux user account (whilst maintaining any existing NTFS permissions). So by default the drive would be mounted with uid=1000, gid=1000 and umask=0022 - which should result in 0755 for directories and 0644 for files. In plain English, that means you shouldn't have any permission issues.

But yeah I believe the compatdata symlink is still required as wine/proton creates files with :, which won't be allowed if you mount the drive with windows_names.

Just use NTFS for the whole drive. The new NTFS3 kernel driver in Linux has fairly decent performance (waay better than the old ntfs-3g driver), and has been pretty stable since kernel 6.2.

The key thing you'd want to do though is to use the mount options nocase and windows_names in your fstab.

• nocase enables case-insensitive file/folder support similar to the default behavior under Windows with NTFS volumes.

• windows_names prevents the creation of files or directories with names not allowed under Windows. This checks for forbidden characters in the name like /, , :, *, ?, <, >, |, " or ending with a space or a period. There are also other checks for matching the behavior of Windows with this mount option for rejecting file/folder names that may be valid on Linux systems but not under Windows.

These two mount options should solve most of the issues Linux NTFS users may face. Do note that to use the above mount options, you'll need to be on at least kernel 6.2.