Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's build an alpha #37

Open
46 of 47 tasks
piranna opened this issue Jun 28, 2014 · 17 comments
Open
46 of 47 tasks

Let's build an alpha #37

piranna opened this issue Jun 28, 2014 · 17 comments

Comments

@piranna
Copy link
Member

piranna commented Jun 28, 2014

I have created a milestione so we can start to focus on develop an initial public release. We can discuss here what things should be added. Please maintain the features to the minimal (it's a first release, after all), and just put here what the idea, but develop them in a new issue.

  • update & improve documentation
  • minimal system
    • ramdisk root filesystem bundle (kernel + node binary packed in a ramdisk image)
    • minit (minimal init for PID 1)
    • boot module (for starting dhcp/getty via asgard)
    • asgard (to run as PID 2) Using forever-starter instead
      • getty replacement written in Node.js (for binding to /dev/console)
    • multiuser (logon + filesystem permissions)
    • OverlayFS-based root filesystem
      • read-only ramdisk root filesystem
    • network support
      • enable/disable network interfaces
      • static IPs
    • command line tools
    • The Big Red Button (script to build everything with just one command)
      • generate images for all platforms at once
      • prepare an empty file system
      • install all system packages (download?)
    • different UIDs & GIDs for each user home folder
      • DevicesManager (/dev filesystem)
    • /proc accesible for everybody
    • fbdev
  • Instalable distro
    • Self-contained source code
      • custom, minimal compiled kernel
      • libraries
    • Multiple architectures
      • x86
      • x86_64
    • Multiple platforms
      • Docker Use Vagga, maybe with Docker compatibility
      • x86 QEmu
      • x86_64 QEmu
    • Run on hardware
      • kernel & initramfs in rootfs images
      • GRUB image (instalable by hand with dd and/or cp/script)
  • no binary executables (only libraries bindings, executables are only Node.js programs)
    • replace /usr/bin/env with Javascript alternative (function? NODE_PATH? patched kernel? script with hard-coded she-bang?)

Minor tasks:

  • Read kernel arguments from /proc (root and home)
  • Allow logon to create new users
  • Move root home to usersfs
  • Make usersfs ownership to root
  • Mount rootfs as read-only
@piranna piranna added this to the 0.1.0 milestone Jun 28, 2014
@groundwater
Copy link
Contributor

groundwater commented Jun 29, 2014

This is great!

Here's what I want to get done, by which I mean actually tested and reliable:

  • minit (minimal init for PID 1)
  • asgard (to run as PID 2)
  • nsh update
  • npkg update

If you want to run on hardware, you also need:

  • getty replacement (for binding to /dev/console)
  • dhcp client (including ability to set ip/rotue/netmask)
  • boot module (for starting dhcp/getty via asgard)

We also need a script to take all these packages and prepare an empty file system.

/bin/node
/etc \
/usr  | stuff for libc
/lib /
/dev  (devfs)
/proc (procfs)
/sys  (sysfs)
/root/
  lib/node_modules/
    mini-init/
    asgard/
    nodeos-boot/
      node_modules/
        getty/
        dhcp-client/
  bin/
    asgard
    mini-init

In principle, this is all described by what modules get installed to /root. Perhaps we can just write an npm package with a bunch of dependencies in it's package.json, and write a npm-user install <PKG> to generate the desired system.

@piranna
Copy link
Member Author

piranna commented Jun 29, 2014

I've updated the head entry with your proposals. Some points:

dhcp client

I've set this as proposed because I think for a minimal first alpha
release we can start working with static IPs, but if you consider it
really necesary and/or there's one already published, we can add it to
that release :-)

boot module (for starting dhcp/getty via asgard)

Can you explain what do you want to achieve here? Is it script like
autoexec.bat launched by minit that starts asgard and register the
dhcp & getty services?

/bin/node
/etc
/usr | stuff for libc
/lib /
/dev (devfs)
/proc (procfs)
/sys (sysfs)
/root/
lib/node_modules/
mini-init/
asgard/
nodeos-boot/
node_modules/
getty/
dhcp-client/
bin/
asgard
mini-init

Filesystem looks pretty nice :-) I would like to clean / (/bin, /etc
and /lib could be moved to /root/* or have then hidden in the ramdisk,
and the other ones are not mandatory, just interfaces to kernel
structures. Only problematic one is /usr/bin/env, but probably can be
trick someway...), maybe it can be done later.

In principle, this is all described by what modules get installed to /root. Perhaps we can just write an npm package with a bunch of dependencies in it's package.json, and write a npm-user install to generate the desired system.

Like Debian meta-packages? Cool! :-)

@groundwater
Copy link
Contributor

Can you explain what do you want to achieve here? Is it script like
autoexec.bat launched by minit that starts asgard and register the
dhcp & getty services?

The system needs to start services to be useful on boot. We should contain that boot behavior to an npm-style module. It would be easy to create both alternative boot strategies, and upgrade the boot package.

Assuming we use grub as our boot-loader, you would specify the package name in your grub entry. This makes it easy to boot the system in different ways by creating multiple grub entries.

Filesystem looks pretty nice :-) I would like to clean / (/bin, /etc
and /lib could be moved to /root/* or have then hidden in the ramdisk,

Some of this relies on how node is compiled. I'm using the libc from Ubuntu, so we should probably leave everything required in the Ubuntu spot. I'm all for looking into either a static node, or compiling node against some other libc.

Only problematic one is /usr/bin/env, but probably can be
trick someway

This is a minor pain, but if we decide the OS will be all-node, and only node we can hack this easily.

@piranna
Copy link
Member Author

piranna commented Jun 29, 2014

The system needs to start services to be useful on boot. We should contain
that boot behavior to an npm-style module. It would be easy to create both
alternative boot strategies, and upgrade the boot package.

Maybe asgard could store in a file the list of enabled services and
launch them on start-up, similar to what Ubuntu serviced does (when
you do "service start ", it gets started after reboot). Also, it
could collaborate with minit so it doesn't need to be running: when
launching a service, it's managed by minit and a command to a
Javascript file that's the one launched on start, so asgard would be
just a command line administration tool :-)

Assuming we use grub as our boot-loader, you would specify the package name
in your grub entry. This makes it easy to swap boot the system in different
ways by creating multiple grub entries.

+1 to GRUB :-)

Filesystem looks pretty nice :-) I would like to clean / (/bin, /etc
and /lib could be moved to /root/* or have then hidden in the ramdisk,

Some of this relies on how node is compiled. I'm using the libc from Ubuntu,
so we should probably leave everything required in the Ubuntu spot. I'm all
for looking into either a static node, or compiling node against some other
libc.

I should have add this comments to filesystem topic, sorry. It's not a
short term task, but I definitelly like the idea of using a static
node binary to remove all this filesystem garbage (this is why I asked
about make the user believe that "$home is $root").

Only problematic one is /usr/bin/env, but probably can be
trick someway

This is a minor pain, but if we decide the OS will be all-node, and only
node we can hack this easily.

Great ;-) I was also thinking in rewrite it in node and look over the
NODE_PATH, since in a first point it's the only one we would allow to
use...

@piranna
Copy link
Member Author

piranna commented Sep 7, 2014

At this moment I'm using the initramfs as root filesystem and mounting the users filesystem in /home, but don't know if It would be better to use AUFS as Docker does and mount it on /. This is mostly related to how common elements as TTYs should be initiated and managed, since by mounting on / would allow to use /root to install that common things, but also it would shown an asimetry between system users giving more importance to the root user as current system does, and also would means to give more priviledges to him...

@dbkaplun
Copy link

I think #67 git support is crucial, since so many npm packages depend on it! Can we add that under 'minimal system'?

@piranna
Copy link
Member Author

piranna commented Sep 16, 2014

git command line client added to the NodeOS Alpha wish-list due to popular demand

;-)

@groundwater
Copy link
Contributor

I will be presenting node-os along with other interesting node-related systems work at JSConf Asia in Nov. I wonder if we can shoot for a demo that the audience can download from docker and run that is more up to date than my original?

I don't think we need anything that's feature-complete, I think people just want something they can start playing with.

In the talk, I would also like to enumerate all the people who helped get the demo working (especially @piranna).

@piranna
Copy link
Member Author

piranna commented Sep 22, 2014

My pull-request can be moved to master without problems.

P.D.: I've had holidays and later my leg broken the last weeks, that's why I had so much time to work on NodeOS... ;-)

@groundwater
Copy link
Contributor

@piranna 😮

I hope you are okay!

I've freed up time to work on this now. Last month was crazy busy. I'm going to spend the next few days coming up to speed with your changes. Thank you 1000x again. I hope you get better soon!

@piranna
Copy link
Member Author

piranna commented Oct 19, 2014

Hi @groudwater! Yes, my leg is ok since several weeks ago. It sometimes hurts my knee but I'm doing normal life, thank you :-)

I have been having some hard weeks at works, but seems it will get slowly, and in fact I fixed some security issues this weekend :-) I will not have too much time in the next months due to classes but I'll try to find some time for NodeOS :-)

@groundwater
Copy link
Contributor

Hey no problem. I'm going to try getting your pull-request working so I can use that as the final demo. Once I've got that going, I'd like to post working artifacts somewhere so people can quickly try it out.

@piranna
Copy link
Member Author

piranna commented Oct 19, 2014

Seems that I missed an issue with QEmu and it's not starting correctly, needs some investigation. Also would be good to have AUFS or OverlayFS support, but we can left it for a future release to see if OverlayFS gets integrated in linux kernel main code.

@piranna
Copy link
Member Author

piranna commented Oct 21, 2014

I've checked it and the issues were related to some dependencies (my fault, sorry), now it should work flawlessly on QEmu. We should have some automated tests, ideally each night due to this issues on third-party packages... :-/

@piranna
Copy link
Member Author

piranna commented Nov 7, 2014

The code at AUFS branch builds flawlessly, at least for QEmu 32 bits. @groundwater, could you be able to check it again for the demo at JSConf?

@piranna
Copy link
Member Author

piranna commented Jan 15, 2015

NodeOS now cross-compile and run on QEmu x86 32 & 64 bits ^^ Code is on master, needs some fix-ups for launching and testing (they are currently focused only for 32 bits) but are minor ones :-)

@mitsukaki
Copy link
Contributor

Only two more things to go!

@luii luii modified the milestones: 2.0.0, 1.0.0 May 27, 2016
@piranna piranna mentioned this issue May 7, 2017
@luii luii added the roadmap label Jun 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants