HN user

canttestthis

843 karma
Posts4
Comments214
View on HN
Images over DNS 10 months ago

There's a lot of stuff the dev team can do that are not strictly business decisions though. Rate limits, QoS, etc.

Hi Peter - I'm on H1-B and not eligible for EB-1/2 or O-1. I filed for EB-5 through an RC and just got my EAD and I want to use that to start a startup in the US. If the underlying EB-5 petition is rejected after the startup is established, do you know if there is a path to re-sponsoring my H1-B through my own startup? I'm trying to understand whether I should wait for a proper green card before going down the startup route.

Try murdering someone like that… well that person might have contingencies in place so that things just start to randomly burn down in your country……………

I don't even know where to start with this. The article portrayed your interaction with the DoD to giving them a Powerpoint presentation and making various attempts to catch their attention. Which you've portrayed here as a 'heavy affiliation'... so heavy that the state conducts special operation behind enemy lines to avenge you.

The only way to have an LLM where data and instruction never meet, in my view, is one that doesn't update in response to prompts (and therefore can't carry on a multi prompt conversation).

Do you mean an LLM that doesn't update weights in response to prompts? Doesn't GPT-4 not change its weights mid conversation at all (and instead provides the entire previous conversation as context in every new prompt)?

Whats the endgame here? Is the story of LLMs going to be a perpetual cat and mouse game of prompt engineering due to its lack of debuggability? Its going to be _very hard_ to integrate LLMs in sensitive spaces unless there are reasonable assurances that security holes can be patched (and are not just a property of the system)

I don't feel like debating the predictability of any individual bug is in the spirit of the argument that I'm making here, which is just that software systems (absent formal verification + running in a completely isolated vacuum) are going to break. Sure, people might have been able to predict it but it still broke systems. Marking the system as 'complete' wouldn't have kept it working.

Bits don't go bad if you neglect them for too long

They do... Other than in the obvious physical sense (bit rot), your assumptions about the environment that the code runs in might change (y2k), the foundation your software is being built on is being actively and continuously updated in ways that may break your code (ipv6, forward incompatible security fixes), the resources your code uses are finite and the constraints around the resource usage may change... Looking at it from just first principles maintaining a Very Large software system in production is immensely complex.

In my experience outside the niche of tech related content Kagi performed significantly worse than Google. Especially for content that was region specific and not just text natch based, like "children clothing stores in Boston"

Tamper-proof packaging is a poor replacement for a first-time boot replacement warning. Not to mention the sheer impracticality of properly implementing tamper proof packaging (the factory would have to cover the packaging in shiny nail polish or something, encrypt and send a high-res picture of that somehow to the final buyer across the supply chain, at which point the final buyer makes sure the glitters align). Much better to do it the way it's currently done

You can use even newer stuff like high grade visualization of the entire program execution which trivializes bug detection, performance enhancement, and system understanding.

Very interesting... what is the gdb-reverse-debugging equivalent for high grade visualizations of, for ex. cpp or python software? Something that's free, open source, generalizable

Llama 2 3 years ago

After having reviewed the relevant material I think it's fair to say that hippos swim, per our conventional understanding of what swimming is.

Time commitments were generally aggressive but reasonable with a 10-20% buffer to account for ramp up (realistically closer to 10 than 20). The reasonable-ness of most things eng-culture related at Amazon is probably a function of the competence of your management chain.

As for my fellow engineers- I don’t know anyone else who did this regularly so I’m not sure

brave souls diving into a strange codebase

As someone who made a career out of being loaned out to other teams as an 'away resource' at Amazon, I've struggled to find a similar level of mental stimulation after leaving for other Big 4 companies. Being a loaner engineer meant something new to work on every few months, no maintenance or oncall burden, making lots of new connections, and just generally there being always something interesting/intense to do.

Facebook was written in PHP. Mark used one language he knew and a $300B company was built on top of it.

This example doesn't further your point at all seeing as they had to over time literally invent an entirely new language to make their PHP codebase scale. And on top of that FB went on to use a whole bunch of uncommon languages (Haskell, Erlang, D, probably a bunch of others I don't know about)