jiveturkey

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.

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.

TFA would be much much better if he'd conducted it across different social/cultural demographics. JP vs EU vs US vs CA for example.

I also didn't see any post-cart interview of people that returned the cart.

As it is I found it a waste of 2 minutes reading time. It's not somewhat scientific at all.

> 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.

> Intel is an American company

Literally.

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.

> Apple actually attests to signatures

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.

<3

> 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.

I'd be surprised if this app has legs but what do I know.

30% is too rich IMO. There's no correct answer so I doubt you'll be able to get one. Given that the co-founder is someone you just met, not a long time acquaintance or friend that you know you can work well with and you know their skills, I would simply look for another co-founder. There is a YC matching program if you want to do that.

it's retail. the margin is 30-50% for sure.

EDIT: their last quarterly was 36%. they lost $3.7bn in 24Q4 -- the christmas quarter. sold to PE in Q1.

Seems to have only basic usefulness as a diagnostic tool.

> Instantly tests SFP and QSFP module health, including Rx/Tx power.

Most SFP modules will fail due to heat, like LED bulbs. So an instant test is of course instantly useful, but not indicative of production-use SFP health.

As a programming tool, of course it's awesome.

Of course, in typical ubiquiti fashion, it's out of stock with no way to backorder.

Curious to know how they chose the survey sample. Because other surveys say 65% of Americans are living paycheck to paycheck in 2025. So, 25% feels low.

fascinating how it's all over the place wrt level of detail. and absolutely unreadable. luckily the layout is simple and reader mode works.

> Hex is base 16

i would argue that someone that understand bases (in the first place), understands what the << operator does (context where base 16 is explained), but doesn't understand what base 16 is, doesn't exist. this is the kind of haphazard approach of this article i'm talking about. even the author's name, 0xkato, is an example of this.

as to the content, i wish it had touched on TPM, PCRs, UEFI secure boot, and ME pre-boot.

i'm forgiving all the actual errors since it is a pretty broad overview.

i'm guessing first-year uni student.

rather amazed a post like this can make it to the #1 spot.

Some entire industries have this problem, eg trucking. There is this shortage of truck drivers. The quiet part is that it's at the rates trucking companies are willing to pay. That rate is based on what they can charge to customers plus a thin profit margin. Because trucking is too easy to get into, companies can't simply raise their rates because other companies will undercut them (in their own desperate bid to survive). This kind of market competition is healthy for the "market", perhaps not healthy for workers.

The depletion of tech workers for Amazon is similar. The part that isn't said is: at the salaries Amazon is willing to pay. Amazon has a different market to worry about, the stock market. They can't just increase their HR spend 25% without taking a hit in the stock market. And I guess they aren't willing to change the work environment to be more attractive. Maybe they can't at their size, as it can be hard to avoid dead weight.

Google doesn't hire in the US for some PAs, for similar reason. Salaries are capped (artificially) by stock market demands. But Google doesn't call it worker depletion.

That's DoQ, RFC 9250.

> The dealership then pays mechanics an hourly wage ($20+, fairly high for well certified master mechanics)

Maybe in Ohio.

I'm not sure that your comment is even directionally correct. TFA is clickbait for blue collar pseudo-car-guys. The example given in the article paints the mechanic as the hero, losing money on every job. In reality book time is insanely exaggerated in the median, and the problem is likely more that mechanics don't like earning a dime for every dollar the boss makes.

Many mechanics (seems that is what the article example is) get paid on book time, not hourly. That is what the guy in the article is complaining about. That their book rate is both too aggressive, and far less than the "customer book time" / rate. The reason mechanics are often paid this way is so that they stay efficient. Warranty jobs are especially aggressive on the mechanic book rate, because cars under warranty are newer with few unexpected problems like rusty parts, stripped bolts, age related issues, etc.

It's a false accusation. The numbers have no meaning. Is that not obviously the point of contention?

It's one thing to say, this is aggregate in the industry (and still be misleading), or say group by MAG7, or AI companies, or some sector. It's another to name Amazon as the ringleader when the data don't show that.

It's quite hilarious to see the top comment thread is the "punch is just a punch" (or now: bell curve meme) unfolding in real time.

Again, however, the data in the article does not show that. The article is attempting to argue this point with facts (hard data), while not presenting said hard data. It's especially egregious because of the naming of specific companies.

Who's forcing? I might have misread TFA I guess. My reading was that the guy attended a conference, enjoyed the storytelling kind of talk (I mean this is a tried and true approach, there are even flash card decks on the story technique), and wrote a blog to capture and crystallize what he liked about it as it applies to his daily activity of writing code. I didn't read anything there claiming it was the one true way and anything else is a bankrupt approach.

If the point is about forcing someone to write commit essays, then yes I did miss it.

I often do this. It's a great way to highlight the areas you want a reviewer to focus on, the areas you are least happy about and want some collab. You can't always get collab pre-review, as you're writing. Plus you want to write it down and move on. Then you can async edit when the feedback comes. Not unlike a prose writing process.

I write intermediate commit messages as notes to self. You don't always work continuously on the same PR. The commit messages are a useful context refresher.

Why advocate against this anyway? If no one reads them, it harms no one. Just like personal blogs. However, the writing of the blog is the useful act, not the reading.

Ironic that you are accusing TFA article of being an expert novice. I don't disagree your take on him / the article, but you are committing the same sin.

HN headline is wrong. AMZN not fined 2.5B, they were fined 1B and have to refund 1.5B to consumers. The original article (at this time anyway) has an accurate headline.

It's really too bad the FTC settled and AMZN gets to admit no fault. What is the incentive for FTC to simply not pursue this to the bitter end? 1B is literally pocket change to the fed government, and is laugh-meme moment for Amazon. $50 back to each user is also not even worth claiming. So the settlement is just FTC not doing their job.

Disclaimer: I willingly use Prime and doubt I'd ever leave.

to save you from loading the pdf:

> This paper presents an empirical investigation of how eSIM adoption affects user privacy, focusing on routing transparency, reseller access, and profile control. We first show how travel eSIMs often route user data through third-party networks, including Chinese infrastructure, regardless of user location. This raises concerns about jurisdictional exposure. Second, we analyze the implications of opaque provisioning workflows, documenting how resellers can access sensitive user data, proactively communicate with devices, and assign public IPs without user awareness. Third, we validate operational risks such as deletion failures and profile lock-in using a private LTE testbed.

I have an ultrasonic knife for reverse engineering. It's wonderful. It's also great for crafting.

I'm highly doubtful it's useful in the kitchen. Sharp knives would seem to do the trick.

not exactly.

https://eclecticlight.co/2024/07/30/nvram-in-apple-silicon-m...

A nearby phone implies a nearby phone user that would presumably understand how to place an emergency call, especially if they are being asked by a frantic five year old.