How do you reckon? My understanding is that they're valid perm positions that legally must be offered to US citizens before they can be filled by anyone else.
it's really, really easy to say that applicants don't meet the requirements, since hiring is sooo subjective. "none of the applicants had 8 years and 2 months experience in this company working on this team, so they won't be able to perform the duties".
or, if they do have a flood of qualified applicants (the point of the website), they can simply not go forward with PERM at this time for their selected candidate. PERM roles aren't new jobs in the sense that the employer is "down" one employee if they don't fill it. PERM roles are simply a status change for an existing employee.
Nominally - although perhaps more often barking and not serious - is if you're a super duper qualified US citizen, you either can find a job there, or, you sue the company for discrimination, either way you get paid. The latter being the part that's highly hypothetical and potentially not realistic.
I definitely wouldn't want to work on your team, if that's how you interpret such an answer. Perfect interview then -- we've both eliminated the other as a viable employee/employer, so that's a win and we got there from just 1 trivial coding question. There's so much more to say here, but this is no longer timely, plus this isn't great forum for such discussion.
FWIW I have never been asked this question or similar, but since it's so famous I do have my own answer at the ready, which is just slightly more complex than the naive solution, but still well within the realm of production-worthy (maintainable, testable, readable) code. We don't really ever see any discussion of such because of course it isn't "interesting".
You're retconning. Brighter headlights (xenon) were invented in '61 and first appeared in '91. By 2000 the tech made its way to less premium cars.
Tesla didn't have the big screen (which heralded the current stupid trend) until 2012, and of course it took a number of years for Tesla and the giant omni screen to be popular. Thumb in the air I'd say 2018-2020.
You want brighter headlights so you can see better and drive more safely. The interior brightness is a separate independently evolved problem.
The horizontal cutoff is a tradeoff that comes with the bright lights (Xenon tech anyway). And there is plenty of low light leakage to reflect off of animal eyes. The problem IMO isn't pure brightness but rather these intensely bright lights (itself a benefit) coupled with poor aiming or poor maintenance of aim. Some states in the US have a mandatory annual vehicle inspection which includes headlight aim checks.
You aren't understanding economy of scale, and peak to average ratios.
The same reason I use cloud compute -- elastic infrastructure because I can't afford the peaks -- is the same reason large service providers "work".
It's funny how we always focus on Cloudflare, but all cloud providers have this same concentration downside. I think it's because Cloudflare loves to talk out of both sides of their mouth.
The "economies of scale" defense of Cloudflare ignores a fundamental reality: 23.8 million websites run on Cloudflare's free tier versus only 210,000 paying customers or so. Free users are not a strategic asset. They are an uncompensated cost, full stop. Cloudflare doesn't absorb this loss out of altruism; they monetize it by building AI bot-detection systems, charging for bot mitigation, and extracting threat intelligence data. Today's outage was caused by a bug in Cloudflare's service to combat bots.
That's AI bots, BTW. Bots like Playwright or Crawl4AI, which provide a useful service to individuals using agentic AI. Cloudflare is hostile to these types of users, even though they likely cost websites nothing to support well.
The "scale saves money" argument commits a critical error: it counts only the benefits of concentration while externally distributing the costs.
Yes, economies of scale exist. But Cloudflare's scale creates catastrophic systemic risk that individual companies using cloud compute never would. An estimated $5-15 billion was lost for every hour of the outage according to Tom's Guide. That cost didn't disappear. It was transferred to millions of websites, businesses, and users who had zero choice in the matter.
Again, corporations shitting on free users. It's a bad habit and a dark pattern.
Even worse, were you hoping to call an Uber this morning for your $5K vacation? Good luck.
This is worse than pure economic inefficiency. Cloudflare operates as an authorized man-in-the-middle to 20% of the internet, decrypting and inspecting traffic flows. When their systems fail, not due to attacks, but to internal bugs in their monetization systems, they don't just lose uptime.
They create a security vulnerability where encrypted connections briefly lose their encryption guarantee. They've done this before (Cloudbleed), and they'll do it again. Stop pretending to have rational arguments with irrational future outcomes.
The deeper problem: compute, storage, and networking are cheap. The "we need Cloudflare's scale for DDoS protection" argument is a circular justification for the very concentration that makes DDoS attractive in the first place. In a fragmented internet with 10 CDNs, a successful DDoS on one affects 10% of users. In a Cloudflare-dependent internet, a DDoS, or a bug, affects 50%, if Cloudflare is unable to mitigate (or DDoSs themselves).
Cloudflare has inserted themselves as an unremovable chokepoint. Their business model depends on staying that chokepoint. Their argument for why they must stay a chokepoint is self-reinforcing. And every outage proves the model is rotten.
hang on, you're reading some kind of cloudflare advocacy in my post. apologies if i implied that. i don't like to come off as a crank is all. IMO cloudflare is an evil that needs to be defeated. i'm just explaining how their business model "works" and why massive economy of scale matters, to support the GP poster.
i don't even think they are evil because of the concentration of power, that's just a problematic issue. the evil part is they convince themselves they aren't the bad guys. that they are saving us from ourselves. that the things they do are net positives, or even absolute positives. like the whole "let's defend the internet from AI crawlers" position they appointed themselves sheriff on, that i think you're referencing. it's an extremely dangerous position we've allowed them to occupy.
> they monetize it
yes, and they can't do this without the scale.
> scale saves money
any company, uber for example, can design their infra to not rely on a sole provider. but why? their customers aren't going to leave in droves when a pretty reliable provider has the occasional hiccup. so it's not worth the cost, so why shouldn't they externalize it? uber isn't in business to make the internet a better place. so yes, scale does save money. you're arguing something at a higher principle than how architectural decisions are made.
i'm not defending economy of scale as a necessary evil. i'm just backing up that it's how cloudflare is built, and that it is in fact useful to customers.
> And one woman, upon being confronted about leaving her cart, declared, “I have really bad vertigo,” before getting behind the wheel and driving away. To be clear: Disabilities deserve accommodation. But if you could push the full cart to your car, why couldn’t you return the empty one?
Because you need the stability of the cart (as a walker aid) itself.
Surprising proposal. Normally I'd review the credentials of the authors but it's late Sunday night so nevermind.
I like the idea in general - an OIDC-like flow without needing any a priori setup. But, the RP has only a signed token with the pubkey in DNS, so this doesn't prove anything about the user unless the RP also verifies against some trusted and known email providers. This is absolutely awful for the Internet and makes sure power stays concentrated. PLEASE don't let this become a thing.
Second, this doesn't improve privacy. Most RPs will send an email right at signup, or soon thereafter. Thus the email provider does learn of the individual's association with that web application.
A last issue that's immediately obvious, is that you have to use a webmail interface.
> The privacy guarantee we are making here is that no one, not even people operating the inference hardware, can see your prompts.
that cannot be met, period. your asssumptions around physical protections are invalid or at least incorrect. It works for Apple (well enough) because of the high trust we place in their own physical controls, and market incentive to protect that at all costs.
> This is how Apple's PCC does it as well [...] and you can audit the code running on those compute machines to check that they aren't doing anything nefarious.
just based on my recollection, and I'm not going to have a new look at it to validate what I'm saying here, but with PCC, no you can't actually do that. With PCC you do get an attestation, but there isn't actually a "confidential compute" aspect where that attestation (that you can trust) proves that is what is running. You have to trust Apple at that lowest layer of the "attestation trust chain".
I feel like with your bold misunderstandings you are really believing your own hype. Apple can do that, sure, but a new challenger cannot. And I mean your web page doesn't even have an "about us" section.
That's a strong claim for not looking into it at all.
From a brief glance at the white paper it looks like they are using TEE, which would mean that the root of trust is the hardware chip vendor (e.g. Intel). Then, it is possible for confidentiality guarantees to work if you can trust the vendor of the software that is running. That's the whole purpose of TEE.
I guess you're unaware that Intel TEE does not provide physical protection. Literally out of scope, at least per runZero CEO (which I didn't verify). But anyway, in scope or not, it doesn't succeed at it.
And I mean I get it. As a not-hardware-manufacturer, they have to have a root of trust they build upon. I gather that no one undertakes something like this without very, very, very high competence and that their part of the stack _is_ secure. But it's built on sand.
I mean it's fine. Everything around us is built that way. Who among us uses a Raptor Talus II and has x-ray'd the PCB? The difference is they are making an overly strong claim.
Everyone likes to dunk on the US, but I doubt you could provide a single example of a country that is certainly a better alternative (to be clear I believe many of the west up in the same boat).
We don't _quite_ have the funding to build out our own custom OS to match that level of attestation, so we settled for attesting to a hash of every file on the booted VM instead.
But (based on light reading, forgive errors) the only way to attest them is to ask _Apple_! It reminds me what i call e2e2e encryption. iMessage is secure e2e but you have to trust that Apple is sending you the correct keys. (There's some recent update, maybe 1-2 years old, where you can verify the other party's keys in person I think? But it's closed software, you _still_ have to trust that what you're being shown is something that isn't a coordinated deception.)
Apple claims to operate the infrastructure securely, and while I believe they would never destroy their business by not operating as rigorously as they claim, OTOH they gave all the data to China for Chinese users, so YMMV. And their OS spams me with ads for their services. I absolutely hate that.
Again, anyway, I am comfortable putting my trust in Apple. My data aren't state secrets. But I wouldn't be putting my trust in random cloud operator based on your known-invalid claim of physical protection. Not if the whole point is to protect against an untrustworthy operator. I would much sooner trust a nitro enclave.
You are not in fact trusting Apple at all. You are trusting some limited number of independent security researchers, which is not perfect, but the system is very carefully designed to give Apple themselves no avenue to exploit without detection.
reply