4 ms·

Neither FreeRTOS nor ThreadX/Azure RTOS can really accept random patches. These systens are certified for use in highly safety critical applications (think rail

Neither FreeRTOS nor ThreadX/Azure RTOS can really accept random patches. These systens are certified for use in highly safety critical applications (think railways, nuclear reactors, chemical plants...). To keep that certification, either the whole OS must be recertified after a change or an impact analysis and extensive testing are performed for each and every minor patch. Most random hackers won't be able to deliver any of that along with their patches. It requires resources few have access to. To give you an example, I had access to the complete ThreadX source code a while ago as my employer back then was a licensee. Making functional changes to that code was a complete no go because that would instantly invalidate its certification and put the onus of recertification on us. And we wouldn't have been able to pull that off at all. Given those restrictions, the actual software license barely matters.

nix23 6y ago
>Neither FreeRTOS nor ThreadX/Azure RTOS can really accept random patches. BS, both have certified "edition" but the "normal" version is not, you can start today send patches for RTOS in. https://github.com/FreeRTOS/FreeRTOS-Kernel https://github.com/FreeRTOS/FreeRTOS-Kernel
- gmueckl 6y ago
  Do you think the certified editions are fundamentally different from the normal ones? Hint: they aren't. Certified means that these are the exact revisions they handed in for certifications. It's just not realistically possible to get full certification for every release in a fast cycle because the time and effort needed is too high. But they still take on full responsibility for each and every patch going into the codebase.
  - nix23 6y ago
    >Do you think the certified editions are fundamentally different from the normal ones? Hint: they aren't Sometimes they are different (FIPS enabled etc), but that does not stop you working on that project. >But they still take on full responsibility for each and every patch going into the codebase. That's how ~every single OSS project works.
    - gmueckl 6y ago
      I've yet to see a certified source code that's different from the non-certified version. I've looked at the ThreadX sources on Github and I see no difference to what I had access to at my previous employer. I've also gone through the Github history of the FreeRTOS project. The only merged PR that I could find that was not made by a FreeRTOS team member and touched the kernel was a series of whitespace changes.

nix23 6y ago

>Neither FreeRTOS nor ThreadX/Azure RTOS can really accept random patches. BS, both have certified "edition" but the "normal" version is not, you can start today send patches for RTOS in. https://github.com/FreeRTOS/FreeRTOS-Kernel https://github.com/FreeRTOS/FreeRTOS-Kernel

gmueckl 6y ago
Do you think the certified editions are fundamentally different from the normal ones? Hint: they aren't. Certified means that these are the exact revisions they handed in for certifications. It's just not realistically possible to get full certification for every release in a fast cycle because the time and effort needed is too high. But they still take on full responsibility for each and every patch going into the codebase.
- nix23 6y ago
  >Do you think the certified editions are fundamentally different from the normal ones? Hint: they aren't Sometimes they are different (FIPS enabled etc), but that does not stop you working on that project. >But they still take on full responsibility for each and every patch going into the codebase. That's how ~every single OSS project works.
  - gmueckl 6y ago
    I've yet to see a certified source code that's different from the non-certified version. I've looked at the ThreadX sources on Github and I see no difference to what I had access to at my previous employer. I've also gone through the Github history of the FreeRTOS project. The only merged PR that I could find that was not made by a FreeRTOS team member and touched the kernel was a series of whitespace changes.