I do not buy the argument against AES. On both ARM and x86 you have side-channel secure hardware implementations of AES.
ChaCha20 would be the right choice here, not SPECK.
[deleted]
TFS: A file system built for performance, space efficiency, and scalability
31–40 of 126 posts
Re: TFS: A file system built for performance, space efficiency, and scalability
#32Good luck. There is long road ahead. Both ZFS and Btrfs were initially developed by really high caliber people and experts with good track record. ZFS had five years for full time development until release, next five years to get close to the features and stability that ZFS has now. Btrfs started 10 years ago and it's still trying to catch up.
Exactly, BcacheFS, HAMMER2 are other file-systems that are being worked on by some REALLY good programmers for years and years to come. It seems like a file-system takes longer to stabilize than a kernel.
Re: TFS: A file system built for performance, space efficiency, and scalability
#33I do not buy the argument against AES. On both ARM and x86 you have side-channel secure hardware implementations of AES.
Salsa20 and ChaCha20 are faster on modern hardware than built-in AES instructions. AES is just old and complex. As Salsa family and other modern ciphers have shown you don't have to use complex function to achieve security.
Re: TFS: A file system built for performance, space efficiency, and scalability
#34Good luck. There is long road ahead. Both ZFS and Btrfs were initially developed by really high caliber people and experts with good track record. ZFS had five years for full time development until release, next five years to get close to the features and stability that ZFS has now. Btrfs started 10 years ago and it's still trying to catch up.
Exactly, BcacheFS, HAMMER2 are other file-systems that are being worked on by some REALLY good programmers for years and years to come. It seems like a file-system takes longer to stabilize than a kernel.
> It seems like a file-system takes longer to stabilize than a kernel.
For good reason in my opinion. An unstable kernel will cause application glitches, unnecessary slowness or OS crashes. They are annoying but not persistent (ie a reboot and you can carry on for a bit). However an unstable file system are persistent and thus could destroy all of your data forcing you to recover from backups (assuming you're diligent enough to keep tested backups).
Plus file systems still have to deal with buggy consumer hardware and other similar edge cases (eg storage devices, power failures, etc) just like a kernel would.
Re: TFS: A file system built for performance, space efficiency, and scalability
#35Earlier quoted context omitted.
So you have to add “fs” or “filesystem“ to your search queries, or not even that if the rest of the query gives sufficient context. Everyone makes name conflicts in independent domains to be a much bigger problem than they are in reality. There’s Amazon rainforest, Amazon the ecommerce website, and Amazon the cloud company. How often do you have any problem differentiating between them?
Well.. let's google it... "TFS" .. hmm, abbridged lead in to the wikipedia article at the top... And though I'm not a systems programmer likely to implement, or support the code for a filesystem, I am A programmer, and work in IT... And systems operators are also likely to come accross TFS (Team Foundation Server) in terms of supporting a deployment of it. Though, they've started to refer to the source control protoc…
For what it's worth, I think you should have taken the advice of the guy you're replying to. The first result for "TFS file system" is https://github.com/redox-os/tfs.
Re: TFS: A file system built for performance, space efficiency, and scalability
#36Earlier quoted context omitted.
So you have to add “fs” or “filesystem“ to your search queries, or not even that if the rest of the query gives sufficient context. Everyone makes name conflicts in independent domains to be a much bigger problem than they are in reality. There’s Amazon rainforest, Amazon the ecommerce website, and Amazon the cloud company. How often do you have any problem differentiating between them?
Well.. let's google it... "TFS" .. hmm, abbridged lead in to the wikipedia article at the top... And though I'm not a systems programmer likely to implement, or support the code for a filesystem, I am A programmer, and work in IT... And systems operators are also likely to come accross TFS (Team Foundation Server) in terms of supporting a deployment of it. Though, they've started to refer to the source control protoc…
If you’re looking for Java and the first result is the Wikipedia article on the island[1] do you just switch programming languages?
I hear C is very search engine friendly. Probably why it’s so popular.
Re: TFS: A file system built for performance, space efficiency, and scalability
#37I do not buy the argument against AES. On both ARM and x86 you have side-channel secure hardware implementations of AES.
ChaCha20 would be the right choice here, not SPECK.
Or if they really want a lightweight cipher with a small block size, they should consider SPARX, especially since a Rust implementation is readily available: https://github.com/jedisct1/rust-sparx
Re: TFS: A file system built for performance, space efficiency, and scalability
#38"Team Foundation Server" (Microsoft's version control server) is what goes through my mind... poor choice of naming...
It's more than just a bad VCS. It's a bad bug tracker, a bad build system and a bad workflow system as well.
But yeah, if I wanted a set of three letters than suggested quality and reliability, TFS would be near the bottom of my list.
Re: TFS: A file system built for performance, space efficiency, and scalability
#39I wonder would it be possible to use it somehow with Linux (in kernel space, not with fuse, because fuse has work slower because of necessary context switches from kernel to user space). I mean it is interesting can a wrapper kernel module be written for interfacing with Rust code, or there are some obstacles that would prevent from doing it efficiently.
[deleted]
Re: TFS: A file system built for performance, space efficiency, and scalability
#40While there are many good arguments to be made against AES in favor of ARX construction ciphers, the choice of SPECK for this is not okay. The correct choice of an ARX cipher would have been something like ChaCha20 or Salsa20.