Hacker News 의견

• 팀 일부가 ex-Googler 출신인 것 같지만, 우리가 알고 있는 Piper 기반의 srcfs와는 다름
  비슷한 점은 있지만 세부 정보가 거의 없고, self-hosting 버전도 “Talk to us” 식 가격 정책이라 아쉬움

  • Google이나 Meta가 내부의 magic VFS를 오픈소스로 공개했으면 함. Meta의 EdenFS가 그나마 가장 가까움
  • 이거 정말 익숙하게 느껴짐. commit deadbeef 시점에서 전체 트리를 materialize하지 않고도 monorepo의 일부만 빌드할 수 있었음
    그리고 가격 얘기인데, 수십억 라인짜리 코드베이스를 다루는 팀이라면 “TalkToUs” 가격쯤은 감당 가능하지 않음?
    Linux 같은 오픈소스도 내 노트북에서 잘 돌아감

• 이걸 보니 예전 ClearCase의 MVFS가 떠오름
  빌드 시 open(2), getenv(3) 같은 호출을 가로채서 어떤 툴이 어떤 환경에서 어떤 버전의 파일을 썼는지 모두 기록했음
  동일한 조건이면 기존 결과를 “winked-in” 해서 재사용했고, 파일시스템 수준에서 버전 관리도 가능했음
  예를 들어 file.c@@/trunk/branch/subbranch/3 같은 식으로 접근할 수 있었음

• 제목에 나온 시간 수치가 좀 과장된 느낌임
  혹시 EdenFS나 git fuse류를 제품화하려는 건가 싶음

  • 빌드 단계를 시스템 독립적으로 캐싱한다고 주장함
    “이전과 동일한 빌드 단계는 자동으로 건너뛰고 결과를 재사용한다”는 식인데, 너무 좋아 보여서 오히려 믿기 어려움
  • 결국 빌드 출력 캐싱을 좀 더 확장한 형태로 보임

• 그냥 상업용 콘텐츠 마케팅처럼 느껴짐. 기술적인 디테일이 거의 없음
  예전에 빌드 엔지니어로 일했을 때 효과적이었던 몇 가지 팁을 공유하자면,
  tmpfs에서 빌드하기, 큰 파일은 복사 대신 symlink/hardlink 활용, libeatmydata로 불필요한 I/O 줄이기,
  그리고 교차 컴파일러를 잘 선택하는 것 등이 있었음
  진짜 중요한 건 빌드 시스템을 최적화하고 변하지 않는 중간 산출물 캐싱을 잘 하는 것임

  • 하지만 이런 기본 팁들은 이 제품이 주장하는 문제를 해결하지는 못함

• 안녕하세요, Source.dev 공동창업자 Serban임
  업보트와 토론에 감사함. 초기 스타트업에게 이런 피드백은 정말 큰 힘이 됨
  우리가 만드는 게 진짜로 가치 있다고 느껴져서 기쁨

  • 흥미로워서 묻는데, 혹시 Python의 fabricate처럼 strace로 파일 접근을 추적하는 방식과 비슷한지 궁금함

• “SourceFS로 빌드 속도가 9배 빨라진다”는 문구를 보고 웃음이 나옴
  빌드가 오래 걸릴수록 검술 연습 시간이 늘어나니까, 느린 빌드도 나름 장점이 있음

• 그들의 성능 주장이 내가 써본 분산 Android 빌드 시스템보다 훨씬 앞서 있음
  어떤 비밀 소스가 있는지 궁금함

  • 혹시 그냥 좀 더 화려한 ccache 수준인 건 아닐까 싶음

• 빌드가 “충분히 빠른” 수준에 도달하면, 코드베이스를 이해하기 위한 고통스러운 작업을 할 비즈니스 동기가 사라짐
  이제 10억 라인짜리 코드베이스로 가는 길만 남았음

• 설명을 보면 Android 소스 전용처럼 들림. 왜 그런지, 다른 코드베이스에도 적용 가능한지 궁금함

  • 내 이해로는, 이건 조직이 운영할 수 있는 가장 큰 빌드 머신의 메모리에 코드 전체가 안 들어가는 경우에만 의미가 있음
  • 페이지 자체에 그 이유가 잘 설명되어 있음