4 ms·

You're missing thee point of why at least half of the operating systems (if you can call them that) in your list exist. FreeRTOS and Azure RTOS (formerly Thread

You're missing thee point of why at least half of the operating systems (if you can call them that) in your list exist. FreeRTOS and Azure RTOS (formerly ThreadX) are hard realtime microcontroller operating systems that are designed to squeeze into as little as 32kB Flash and a few kB RAM. Their capabilities are a far cry from what Linux offers. They complement each other instead of competing.

pjmlp 6y ago
Those issues are orthogonal to them not being GPL friendly.
- gmueckl 6y ago
  FreeRTOS is MIT licensed, Zephyr is Apache 2.0 licensed. You just can't get any more GPL friendly in that space.
  - pjmlp 6y ago
    On the contrary, they are non-copyleft, thus no upstreaming required, just as OEMs love to have their free beer OSes.
    - gmueckl 6y ago
      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.

pjmlp 6y ago

Those issues are orthogonal to them not being GPL friendly.

gmueckl 6y ago
FreeRTOS is MIT licensed, Zephyr is Apache 2.0 licensed. You just can't get any more GPL friendly in that space.
- pjmlp 6y ago
  On the contrary, they are non-copyleft, thus no upstreaming required, just as OEMs love to have their free beer OSes.
  - gmueckl 6y ago
    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.