3 ms·

I understand why they did it, though. It's either this (everyone supports NFS, even Windows) or get crucified for vendor lock-in. Just like Github did yesterday

I understand why they did it, though. It's either this (everyone supports NFS, even Windows) or get crucified for vendor lock-in. Just like Github did yesterday (https://news.ycombinator.com/item?id=9343021 https://news.ycombinator.com/item?id=9343021), even when they released their product as an open standard with an open source reference implementation.

ealexhudson 12y ago
Well, indeed, I'm not sure I could offer a different choice I would have preferred - so the criticism definitely isn't constructive in that sense. It does seem, though, that the world is missing a sane cross-platform network system. If there had even been some fuse-based system that used a more robust protocol I'd probably prefer that, although if they can more or less guarantee that the NFS service won't go down (easily) then I suppose most of my qualms would be put aside.
justinsb 12y ago
There's a world of difference between what Github did, and the hypothetical where AWS chose a proprietary protocol to access a filesystem. For AWS, as long as the underlying filesystem was "more or less POSIX", the access mechanism is largely irrelevant to lock-in; it would be as easy to switch from AWS as it would be to move between filesystems. Git was not designed for large files. But what github released yesterday primarily serves to promote github's central-server model for git. Moreover, it seems that it could have been better done within the git protocol itself (modify git to do more sparse pulls, and then try to fetch on a checkout when it is missing blobs, rather than erroring immediately). I suspect AWS chose to use NFS for expedience, the net effect is positive, but I don't think it would have much mattered anyway. Github is trying to inject their own server-model into the git protocol, with an extension that is only half thought through; that is a huge step backwards, open-source or not.
PaulHoule 12y ago
NFS is definitely wonky if you are using cheap tools, but high end systems give astonishing performance.

ealexhudson 12y ago

Well, indeed, I'm not sure I could offer a different choice I would have preferred - so the criticism definitely isn't constructive in that sense. It does seem, though, that the world is missing a sane cross-platform network system. If there had even been some fuse-based system that used a more robust protocol I'd probably prefer that, although if they can more or less guarantee that the NFS service won't go down (easily) then I suppose most of my qualms would be put aside.

justinsb 12y ago

There's a world of difference between what Github did, and the hypothetical where AWS chose a proprietary protocol to access a filesystem. For AWS, as long as the underlying filesystem was "more or less POSIX", the access mechanism is largely irrelevant to lock-in; it would be as easy to switch from AWS as it would be to move between filesystems. Git was not designed for large files. But what github released yesterday primarily serves to promote github's central-server model for git. Moreover, it seems that it could have been better done within the git protocol itself (modify git to do more sparse pulls, and then try to fetch on a checkout when it is missing blobs, rather than erroring immediately). I suspect AWS chose to use NFS for expedience, the net effect is positive, but I don't think it would have much mattered anyway. Github is trying to inject their own server-model into the git protocol, with an extension that is only half thought through; that is a huge step backwards, open-source or not.

PaulHoule 12y ago

NFS is definitely wonky if you are using cheap tools, but high end systems give astonishing performance.