3 ms·

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

by ryao 1y ago

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.

hnlmorg 1y ago
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.
- ryao 1y ago
  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/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf https://www.intel.com/content/dam/www/public/us/en/documents... https://www.intel.com/content/dam/doc/manual/pci-pci-x-family-gbe-controllers-software-dev-manual.pdf 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.
  - MonkeyIsNull 1y ago
    Go for it. All that sounds like fun.
  - hnlmorg 1y ago
    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.
    - ryao 1y ago
      I am still considering it.
- gjvc 1y ago
  Won't be big and professional like GNU
  - hnlmorg 1y ago
    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.
    - gjvc 1y ago
      Your comment goes on and on about different variants but fails to see the germ of a good idea. Sorry to say.
      - hnlmorg 1y ago
        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 ;)
        gjvc 1y ago
        >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"
        hnlmorg 1y ago
yjftsjthsd-h 1y ago
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...)
- ryao 1y ago
  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.

by ryao 1y ago

hnlmorg 1y ago

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.

ryao 1y ago
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/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf https://www.intel.com/content/dam/www/public/us/en/documents... https://www.intel.com/content/dam/doc/manual/pci-pci-x-family-gbe-controllers-software-dev-manual.pdf 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.
- MonkeyIsNull 1y ago
  Go for it. All that sounds like fun.
- hnlmorg 1y ago
  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.
  - ryao 1y ago
    I am still considering it.
gjvc 1y ago
Won't be big and professional like GNU
- hnlmorg 1y ago
  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.
  - gjvc 1y ago
    Your comment goes on and on about different variants but fails to see the germ of a good idea. Sorry to say.
    - hnlmorg 1y ago
      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 ;)
      - gjvc 1y ago
        >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"
        hnlmorg 1y ago

yjftsjthsd-h 1y ago

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...)

ryao 1y ago
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.