Yes, I asked Aviral to include some Documentation explaining the steps to export the applications and how to use the nxpkg to install those apps. :-)
BR, Alan On Tue, May 12, 2026 at 7:17 PM Tomek CEDRO <[email protected]> wrote: > Allright, term "distribution" fits here well in that case :-) > > Would be nice to see some docs describing the concept :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Tue, May 12, 2026 at 9:51 PM Alan C. Assis <[email protected]> wrote: > > > > 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 > > > > > > > > >
