good point. counterpoint: it'll catch on with more users in the general public with a shorter, easier name. gpt has to be repeated a few times or possible to make mistakes. gtp? gpd?
That’s what he is saying. Get rid of non h1bs then keep draining people until they leave and then use that as justification to expand h1b positions.
H1b is really not fair. They have virtually no negotiation standing without risking their immigration status. They are underpaid and subsidized, and drive domestic wages down. Among many simple reforms they should execute, a big one would be tonseperate the sponsor company from the visa. Which would allow them to negotiate and have more agency.
> They are underpaid and subsidized, and drive domestic wages down.
This is true in outsourcing companies (such as Wipro, Infosys, etc.), who account for the lions share of H1B visas, but their entire value prop is outsourcing. I think FAANG pay H1Bs pretty well. I have known several who make above the median of their salary band because the comp systems reward good performance.
IOS 18 is at RC now and is scheduled to be released on Monday. Existing apps affected by this behavior change will break or misbehave when users update their devices to iOS 18 next week.
I think that this is kind of an obvious "optimization" for making application generation much more reliable. Just because the models can generate code for one of 1000 different platforms, doesn't mean that you need all of them. Just by narrowing the scope to a particular platform makes it much more feasible to get working applications without needing manual debugging due to out of date library references etc.
I think something like the approach you have demonstrated here will relatively quickly become the standard for "no-code" application development.
Completely agree. It's useful not just for targeting one specific language, but all the other APIs that we have, and things like RAG to search for importable modules on the platform. Duplicating all that across many platforms is a lot of work!
I agree that is a cool feature. I would say it's from its Rails background where such a thing is encouraged (.json or .html (or no extension)) on a resource give you two different outputs
The entire photo is the finish line. Look at the color of the ground -- it's cream, the color of the lines on the track, while the track is blue. Each vertical line of the photo is taken in the same position on that finish line.
The first "line photo" is the right-most column of pixels on that photo. The next photo is the second-to-the-right column, etc. This way the winner can be determined as the line first photo that has the contestant's torso in it.
Also every runner in this photo is showing them at the finish line even tho they appear in the photo to be at different places. It’s why all the runners are leaning forward because they are all crossing the finish line.
Nowhere, the camera takes an image of a single line in time (and what the camera sees is the canonical finish line). The visual finish line isn't where that camera is looking, so it's never captured. The left and right of that camera isn't space, it's time (right is earlier, left is later).
reply