Leaderboard

Now there is a solution that can force Photo to use CPU for Face Detection. Github

Hello! TL;DR: We've developed a new loader for v6.2.4/v7+ which contains a way to install custom extensions/drivers/mods. We're looking for feedback of the extension manager & kindly asking for drivers to be made compatible with it. First of all, let us thank you guys for all the driver packages you were always preparing - we used them ourselves. As some of you may be aware we are developing a new loader called RedPill. There's a long thread in the developer's section of the forum: Today we've added a long-awaited functionality of custom drivers. We've chosen to go with a more modular approach rather than offering a clone of Jun's loader functionality of extra.lzma archive. Our solution relies on a simple extension manager which is responsible for downloading and packing drivers automatically. This lets users install only the drivers they need while also mixing-and-matching multiple ones. With "extra.lzma" the limitation was that users either had to build their own packages or choose between having the HBA driver or VirtIO driver... that, in our opinion, was a poor experience. Additionally, the new format allows you to keep a single git repository containing both the metadata for RedPill extension manager and the build environment you use to compile drivers. We would like to collect your opinion on the new extension manager we created and ask you to port your drivers to the new format. We prepared two documents: https://github.com/RedPill-TTG/redpill-load/blob/master/docs/extensions-overview.md (summary of what the extension manager is capable of and how to use it manually) https://github.com/RedPill-TTG/redpill-load/blob/master/docs/extensions-for-devs.md (document intended for people creating extensions/compiling drivers detailing the architecture) In addition, we published two packages, which can serve as an example: https://github.com/RedPill-TTG/redpill-virtio (VirtIO driver) https://github.com/RedPill-TTG/redpill-boot-wait (shell-only package; this will be similar to how e.g. a CPU governor mod can be implemented) There's currently no central way to discover packages but is it planned. For now we're simply collecting links to indexes in a separate git repo - https://github.com/RedPill-TTG/redpill-extensions - you can just toss a link there from the GitHub web UI without cloning the repo. What do you all think? special cc @IG-88 p.s. We didn't post this in the driver's extensions subforum as this topic isn't intended for users. When some drivers are built and the official beta version of RedPill is published we will create a separate thread there.

Well yes... either someone takes over or it or it dies.... All depends if anyone else is skilled enough and willing to put time and effort into this. I have my doubts "they" will be back, makes no sense to disappear in order to focus on a beta-version. My bet is that something personal happened. I really hope "they" will manage and continue on this project. It's nice to see how much more active the forum had become since.

How does it go on with RP if TTG no longer reports. then the project dies .......or someone can continue it?? I hope the guys are fine and they'll be back soon

- Sataportmap - use the defaults, at least until you get another SATA card - M.2 can be used as cache if you use DS918+ platform and add the cache patch (search for it or follow links in my sig) - Any AHCI compatible card is supported, as long as it does not have a SATA multiplexer. Some use LSI controllers in "IT" (non-RAID) mode, but this is more expensive. EDIT: Added link: https://xpenology.com/forum/topic/35882-new-sataahci-cards-with-more-then-4-ports-and-no-sata-multiplexer

Ничего не написано про то, сколько нужно pci-e линий для этого адаптера (NVMe M.2 NGFF interface to Slimline SAS (SFF-8654) adapter card adapter) и каких. Видимо минимум pci-e 3.0, есть подозрение, что в mb 2.0. Поизучайте вопрос, чтобы потом не жалеть о содеянном.

Поставить свитч и проверить теорию вашего друга. А так да, незачем из наса делать коммутатор.

Yep, with the build-in forced extension. Works like a charm.

No Passthrough, PVE uses the nic directly. All my vm's use virtio-vnics. The RP DS918+ DSM7 vm uses the build-in virtio-driver provided by RP. Speed amongst VM's with virtio-vnics on the same PVE host is about 25Gbps. Accross nodes, it is limited by the 10gbps connection.

Absolutely! I think it was mentioned at one point that support issues could be dealt with in another thread/section, but the phrase "that ship's already sailed" was mentioned. I can't speak for them, obviously, but I think TTG's intention was for this thread to be much shorter-lived and lower traffic, with proper support and discussion threads elsewhere on the forum once redpill came out of alpha. Development has maybe been slower than anticipated and this thread has grown way beyond manageable, imho. At 122 pages we can't seriously expect newcomers to read the whole thread and be up to date on procedures and politics (for want of a better word). We need an updated project FAQ at the bare minimum, and separation of development and support threads. But this isn't my project and I don't want to tread on TTG's toes, wherever they are...

just a reminder we are in the section "Developer Discussion Room" - any further questions? about >80% of the posts are offtopic and i'm not counting myself as "developer" because i'm not committing any code to the git in question so ....

here it is

8 -What is the bootloader for, and where is DSM saved when I install it on my machine? How much space does it take? The bootloader mimics an internal chip that is found in real Synology boxes. That internal flash chip contains the firmware (kernel) necessary to boot. When you install DSM thanks to the bootloader, DSM is installed on all drives present in the machine, NOT onto your USB key containing the bootloader. Now let us say you installed DSM and you decided to update DSM. DSM will be updated on all hard drives. If the update also comes with an updated firmware (kernel) then it will also be updated on the USB key. That is basically the only part being copied in the bootloader. That is why in some instances, if you had a running XPEnology box that for some reason broke and you try to reinstall an earlier version of DSM you will not be able to because the kernel contained in the USB key is newer than the one in the .PAT file you are using to reinstall DSM. Now, when you install DSM, two partitions are created. The system partition (~2.4GB) and the swap partition (~2GB) which are in RAID1 (always). Each time you add a new drive to your machine it is initialised and the two partitions are created and DSM installed on the drive. The purpose of all this being that as along as you have one working drive you will be able to boot DSM.