Hi Tomek,

Allowing the users to create their own infrastructure doesn't mean we will
have many NuttX distros.
It is the opposite the idea is to let them have a lean alternative to
normal OTA.

If we decide to create a BSD like solution we will need to manage it, more
work for a reduced team to take care.

BR,

Alan



On Tue, May 12, 2026 at 5:41 PM Tomek CEDRO <[email protected]> wrote:

> Thanks Alan :-)
>
> This convinces me even more that we should start from documentation in
> the first place, at least:
> * functional specification.
> * architecture.
>
> If we allow "make it easy for anyone to create their own distribution
> system" then we will end up with Linux world with hundreds of
> different and (self)incompatible distributions. I am not sure what is
> the goal here as already anyone can create custom NuttX firmware build
> thus kind of "distribution"? Looks like we need to note down ideas and
> design goals so anyone who want to join will have clear road forward?
> :-)
>
> I would really propose to take BSD approach to provide one central
> RT-OS design that would provide everyone with common and coherent
> working environment. For sure we could add required functionalities
> when needed but the biggest advantage would be to have one common
> central design, so anyone using NuttX RT-OS would have common starting
> point :-)
>
> We do not have to provide binary packages, but something like Ports on
> FreeBSD do is to provide automation for building packages and their
> dependencies. That way anyone who wants "port X" would have exactly
> the same way to build them. It would be then possible to provide
> binary packages for a selected platform by independent players or as
> our dedicated sub-project :-) Packages signatures and verification is
> another story as npm shows recenlty :-P
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Tue, May 12, 2026 at 11:40 AM Alan C. Assis <[email protected]> wrote:
> >
> > Hi Tomek,
> >
> > Thank you for your feedback.
> >
> > Yes, I suggested Aviral submit the PRs early to get more feedback and
> ideas
> > from the community.
> >
> > I think the idea of the NuttX Distribution is not restricted to Linux
> > Distro, but to make it easy for anyone to create their own distribution
> > system.
> >
> > This way they could select which packages will be available on their
> server.
> >
> > We are not thinking of having a central server with compiled packages
> (like
> > OpenWRT for example), not because it is not possible, but because it will
> > require more team efforts (that we don't have at the moment).
> >
> > The idea is to have something between opkg, so the cache will be saved at
> > /var, but we don't have plan to use sqlite (it is too big to use a small
> > MCU), the idea is to use common text file (maybe JSON) it will require
> less
> > resource.
> >
> > BR,
> >
> > Alan
> >
> > On Mon, May 11, 2026 at 11:00 AM Tomek CEDRO <[email protected]> wrote:
> >
> > > Hello world :-)
> > >
> > > As we have fist PR [1] with package manager for NuttX by @aviralgarg05
> > > and this is step towards NuttX RT-OS "distribution" lets talk about
> > > its architecture :-)
> > >
> > > First of all I would like to propose starting from creating
> > > architecture document and then proceed with implementation so we have
> > > clear vision on the road ahead :-) This documentation should be easy
> > > to edit, thus we may use ASF Confluence WIKI?
> > >
> > > As as BSD user I will for sure give FreeBSD as an example because this
> > > is what I found really elegant and future-proof :-)
> > >
> > > Term "distribution" comes from the Linux world and is not well
> > > perceived in the BSD world where FreeBSD or OpenBSD or NetBSD are not
> > > "distributions" but fully featured standalone and complete operating
> > > systems. I would love NuttX to be that way too - that we have NuttX as
> > > one common coherent environment and not many "distributions" competing
> > > with each other. Thus my proposition to stick to the BSD approach and
> > > thus naming like NuttX RT-OS that would resemble RTOS but also
> > > complete coherent and standalonde OS solution.
> > >
> > > Below are my remarks I already put on the PR.
> > >
> > > Regarding RT-OS organization:
> > > * BSD systems are divided into BASE and USERLAND. This may come handy
> > > for NuttX too because BASE could be the static firmware images built
> > > for specific platform, and then USEDLAND would provide packages for
> > > that platform. This clear separation assures clean and elegant
> > > implementations.
> > >   * BASE is located in `/`.
> > >   * USERLAND is mounted at `/usr/local` when BASE is ready.
> > >   * BASE can work without USERLAND.
> > >   * BASE is common to all releases and platforms providing minimal
> > > common feature set.
> > >   * This allows to have static BASE at `/` with USERLAND mounted from
> > > anywhere (i.e. network or separate partition) at `/usr/local`.
> > >   * Breaking USERLAND never breaks BASE, so you can easily fix stuff
> > > when in pinch.
> > >   * This BSD is different approach from Linux where is base and
> > > packages are intermixed, and I would love this approach in NuttX RT-OS
> > > :-)
> > >
> > > Regarding NXPKG:
> > > * I would suggest FreeBSD following `pkg` [2] organization which is
> > > similar in name and functionality (also smaller and simpler than
> > > `apt`, `pacman`, etc). We may use `nxpkg` in place of `pkg` below:
> > >   * Configuration is plaintext at `/etc/pkg/` and then `nuttx.conf`.
> > >   * Package database is in `/var/db/pkg/local.sqlite`.
> > >   * Package cache is in `/var/cache/pkg`.
> > >   * Each package knows its dependency packages, and pkg is able to
> solve
> > > them.
> > >   * There are also "package flavors" that is each package can have
> > > different feature set enabled/disabled, but this is story for future
> > > here, we just need to keep it in mind when designing architecture.
> > > Lets start with small measurable steps.
> > >
> > > This way we would stick to the current approach where BASE is just
> > > custom firmware, while enabling NXPKG would enable USERLAND (or vice
> > > versa).
> > >
> > > If we want NuttX RT-OS then we should consider minimal and common set
> > > of functionalities for BASE.
> > >
> > > Let me know what you think :-)
> > > Tomek
> > >
> > > [1] https://github.com/apache/nuttx-apps/pull/3474
> > > [2] https://man.freebsd.org/cgi/man.cgi?query=pkg
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
>

Reply via email to