...

foooorsyth

857

Karma

2023-03-21

Created

Recent Activity

  • Had so many Boston cabs not show up for rides to the airport growing up. Uber was such a breath of fresh air…until it wasn’t anymore.

  • I’ve said several times before that notifications should be reportable as spam directly to Google/Apple, just like email spam reporting.

    Google tried to tackle this with notification channels, but the onus falls on the developer to actually use them honestly. No company trying to draw attention back to their app with advertisement notifications will willingly name a notification channel “advertisements” or “user re-engagement” or similar — they’ll just interleave spam with all the non-spam. This API from G hasn’t worked.

  • Rockets?

    Seoul is in artillery range of the border.

  • git by itself is often unsuitable for XL codebases. Facebook, Google, and many other companies / projects had to augment git to make it suitable or go with a custom solution.

    AOSP with 50M LoC uses a manifest-based, depth=1 tool called repo to glue together a repository of repositories. If you’re thinking “why not just use git submodules?”, it’s because git submodules has a rough UX and would require so much wrangling that a custom tool is more favorable.

    Meta uses a custom VCS. They recently released sapling: https://sapling-scm.com/docs/introduction/

    In general, the philosophy of distributed VCS being better than centralized is actually quite questionable. I want to know what my coworkers are up to and what they’re working on to avoid merge conflicts. DVCS without constant out-of-VCS synchronization causes more merge hell. Git’s default packfile settings are nightmarish — most checkouts should be depth==1, and they should be dynamic only when that file is accessed locally. Deeper integrations of VCS with build systems and file systems can make things even better. I think there’s still tons of room for innovation in the VCS space. The domain naturally opposes change because people don’t want to break their core workflows.

  • >The biggest problem with Nix is its commit-based package versioning.

    I am naive about Nix, but...

    ...isn't that like...the whole selling point of Nix? That it's specific about what you're getting, instead of allowing ticking time bombs like python:latest or npm-style glibc:^4.4.4

    Odd to attach yourself to Nix then blog against its USP.

HackerNews