Hacker News Reader

Comment by ryao | Hacker News Reader

It is interesting, although the lack of multiuser support is unfortunate. I really hope that the author reconsiders his stance on multiuser support, even if it is merely to allow things like chmod/chgrp to set file ownership to other users and groups. That would open the door to hosting a NFS server.

View on HN

Its file system compatibility story is a bigger hurdle there.

To be honest, you’re much better off with a battle hardened platform for your use case. Tilck is meant to be educational, not secure in either the InfoSec nor data robustness sense.

Upon seeing this, thoughts keep occurring to me such as:

  * “It could be fun to be the author of a block layer, VFS and an AHCI driver for SATA. NCQ support is a must if I do.”
  * “It could be fun to port ZFS: ztest and zdb, plus the userland version of the driver into which they hook need pthreads, but the important userland utilities do not. Having to statically link everything would be a pain. I would probably have to reimplement the entire SPL for this to work and that would probably be at least 10,000 lines of code.”
  * “If I port ZFS, a NFS server needs to follow so ZFS has an application. This will need support for setting/getting user/group ownership and mode bits. If I rewrite the VFS, I could maybe sneak that feature into it for a NFS server to use while preserving the documented syscall behavior that requires everything be root. If I port the NFS server from illumos, it could share the SPL code with ZFS. NFSv4 permissions will be needed to make it fully happy. Beyond that, I will need a network stack.”
  * “It could be fun to port a network stack. Maybe LwIP could be used.”
  * “It could be fun to write an e1000 driver.”

I have already found the documentation I need if I actually were to implement AHCI and e1000 drivers:

https://www.intel.com/content/dam/www/public/us/en/documents...

https://www.intel.com/content/dam/doc/manual/pci-pci-x-famil...

If I were to do all of this, I would likely try my best to make it a production platform. The purpose would be fun.

Anyway, I wonder if these thoughts will continue if I sleep on them.

Go for it. All that sounds like fun.

If you're serious and the maintainer is willing to accept these contributions, then go for it.

It's a lot of work but definitely rewarding stuff. And you'll learn a lot along the way too.

I am still considering it.

Won't be big and professional like GNU

Different era then.

Your options were basically just:

- GNU: which didn't have a kernel

- BSD: which had massive question marks over ownership

- Minix: which wasn't free back then

- or a commercial Unix

These days you have a dozen BSDs, Darwin, several OpenSolaris forks, hundreds of Linux distros as well as non-commercial licenses for many commercial Unixes. Minix is free. Free reimplementations of BeOS too. And that's before you count the plethora of free non-POSIX systems like Plan 9, ReactOS, and so on and so forth.

And, ironically, there's now less of a need for competition in this space because web engines have replaced OS kernels for a lot of common use cases and WASM is fast becoming the new ABI.

To be clear, I'm not saying this project has no merit. Nor am I saying there is zero chance this project might evolve into something big. I'm just saying that quoting Linus like you have is extremely simplistic.

Your comment goes on and on about different variants but fails to see the germ of a good idea. Sorry to say.

Oh I see the good idea. I also read their readme, which is how i know it's not yet ready to work as a file server ;)

>Oh I see the good idea. I also read their readme, which is how i know it's not yet ready to work as a file server ;)

this is called "judging a book by its cover"

> this is called "judging a book by its cover"

So you think they're lying about not having implemented block devices nor a network stack...? Or are you suggesting that NFS doesn't need network nor file system support?

Please calm down.

Could probably just record user:group in the filesystem and ignore it at runtime except when serving clients? Ex. a Linux file server running as root can still check permissions and ownership without having to change its own user. (Although as an interesting thought experiment, forking per session and switching to the client user would give you file permissions for "free" by way of the kernel imposing them on you...)

As long as the VFS permits those calls to go to the filesystem driver, that is doable. A casual inspction of the documentation suggests that doing this will return an error from the syscall. I am not sure what a kernel driver calling the VFS can do in terms of getting/setting these yet.

Reply on news.ycombinator.com