I haven't job hunted in five years or so, but leetcode was omnipresent in my local market. I got some offers without leetcode but those jobs paid about half as much as the ones that required leetcoding.
> So let me ask this: How hard is it to create a temporary exit node that is basically a rasberry pi with a sim card or wifi connection say from a cafe, or any other public wifi, ans are online for say na hour or two?
It's not hard at all.
> If we had enough of these scattered around, would it matter?
No. Your relays won't be trusted with significant amounts of traffic until they've been up for a few weeks.
The linked project page [1] claims to be fully homomorphic. Assuming the claim holds (I haven't verified it), then there is provably no way for Google or anyone else to obtain any information from the encrypted data or computation performed on them.
FHE is traditionally horrifically slow, so it's hard to imagine running anything beyond toy models with it. They list some applications on the original article page, but (presumably) they must be dramatically stripped down in order to run within any reasonable time budget. This is not going to run anything like a Sol/Opus any time soon.
Related, I'd seen this blog [0] posted on HN a few years back that gave a nice run down on the "programmable cryptography" space which introduce FHE and a few other neat concepts. Really enjoyed the read and learned some new terms.
> Does this rely on the Trust Me Bro model, or is there some way for the client to verify that the provider actually isn't able to see your inputs?
The point of FHE is that you only ever send encrypted data. So if you trust that Google hasn't broken the encryption algorithm entirely, they never access the plaintext.
Once you have workloads that can't tolerate a power cut + running fsck for a potentially long time, a battery backup becomes an excellent investment. I bought a UPS on eBay for cheap and my home server hasn't gone down since.
No, it's because authentic writing on HN has been drowned out in an ocean of slop, in such quantities that calling it out is becoming an exercise in futility
There was an article yesterday where people were complaining about "AI smell", the author showed up in comments to state clearly and unequivocally that he didn't use AI to write it, and people wouldn't believe him.
AI didn't get its tropes and tics ex nihilo. Some people just write in a way that "smells" like AI to others.
If only there were some way to logically break up large pull requests into smaller pieces... Some way of creating a checkpoint with a diff including your changes, and some kind of message explaining the context behind the change... some way to "commit" a change to the record of the repository...
Part of the idea behind stacked PRs is to keep your commits focused and with isolated changes that are meaningful.
A stacked PR allows you to construct a sequence of PRs in a way that allows you to iterate on and merge the isolated commits, but blocks merging items higher in the stack until the foundational changes are merged.
Stacked PRs tend to encourage a series of well-organized commits, because you review each commit separately, rather than together.
What they do that the single branch cannot is things like "have a disjoint set of reviewers where some people only review some commits", and that property is exactly why it encourages more well-organized commits, because you are reviewing them individually, rather than as a massive whole.
They also encourage amending existing commits rather than throwing fixup commits onto the end of a branch, which makes the original commit better rather than splitting it into multiple that aren't semantically useful on their own.
I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR. The curation of the commits that you'd do for stacked PRs could just as easily be done with commits on a single branch; some of us don't just toss random WIP and fixup commits on a branch and leave it to GitHub to squash at the end. I.e., it's the GitHub UI rather than Git that has been lacking.
(FWIW, I'm dealing with this sort of thing at work right now - working on a complex branch, rewriting history to keep it as a sequence of clean testable and reviewable commits, with a plan to split them out to individual PRs when I finish.)
> I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR.
That's what this feature is, conceptually. In practice, it does seem slightly more cumbersome due to the fact that they're building it on top of the existing, branch-based PR system, but if you want to keep it to one commit, you can (and that's how I've been working with PRs for a while now regardless, honestly).
They confirmed in other comments here that you don't have to use the CLI, just like you don't have to use gh in general to make pull requests, it's just that they think the experience is nicer with it. This is largely a forge-side UI change.
> I think the point the GP was trying to make is that the GitHub UI ought to be able to allow you to submit a branch with multiple well-organized commits and review each commit separately with its own PR
So the point he's trying to make is that Gituhub UI should support Stacked PRs but call them something else because he doesn't like the name?
Not really. Without seeing the entire changeset for a PR, you'd have to mentally keep track of what the current state of everything is unless you're a commit minimalist and presquash.
If we're speaking strictly code review, because you can actually make sense of the changeset for the child PR by not including its unmerged parent's changeset.
I've done this manually by building a big feature branch and asking an LLM to extract out functionality for a portion of it.
For the former, it would seem to split based on frontend/backend, etc. rather than what semantically makes the most sense and for the latter it would include changes I don't want and forget some I do want. But I haven't tried this a lot.
Probably 90% of my coworkers in a US tech company are on a work visa. Now that there is pressure on the H1B program, my company is investing in a permanent engineering team in India. Whether this will pay off for them in the long term is a matter of debate, but it seems like the near-term future of the US engineering team is in serious doubt.
You can't just "dismantle H1B" and expect it not to backfire.
As 75% of a single month fee (25% paid upfront), not too bad either: $46k in total for 4 weeks of work. Expenses were not included (flight was paid for).
What does prep look like now?
reply